View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Untitled Group

Group Members

The Project

The Guidelines

What We Done Did




This portion of the project was individual. We used the M1 submission prepared by Michael Natkovich when constructing our future submissions.

Michael says: "Milestone 1 was probably overall as hard for me as any of the milestones, even though looking back, it is one of the easiest. What makes the milestone difficult is that apart from doing the coding, you are also learning the language and programming environment. Expect to make mistakes when coding the first time that are due to straight up ignorance. Don't foreget as well that this milestone is worth just as much as any of the group ones, so do a good job. Plus, if you do, your code will be used in later milestones and that saves you time in having to read and learn someone else's."



During our semester, milestone 2 was where we got acquainted with the gui elements of squeak. For us it was a critical milestone in term of laying the groudwork. While we were told that this gui would be thrown out for later milestones, it turned out to be the gui we built on to. So again, the fact that we did a good job on this part, we were not forced to redesign and redo a new interface for later milestones, but rather we were able to add on to it.

There were several options in what we could use for our gui. You could use morphic, pre-fab, or bob's ui. We went with bob's ui. I don't know why we chose it, but I know that we stuck with it because it was simple and straight forward to use. Bob's ui is quite limiting, but if you can work within the limitations and do what you need, I recommend it. Morphic is more powerful. With great power comes a really long time in trying to figure out how to use it. Pre-fab is also supposed to be easier than morphic and more powerful than bob's ui. I don't know much about it, but there are several tutorials on the case's page from every semester.



For our design, we were required to use ECoDE, a pet project of one of the TA's. ECoDE tries to assist the design process by forcing consistency between scenarios, CRC cards, UML, and other tools. Though it was an interesting concept, it was buggy and supported only "a subset" of UML. Also, due to the heavy integration between features, minor design changes often had to be review ed in three places. Although ECoDE is still in development, and future versions are likely to improve, we would suggest doing design using more traditional tools. (Pencil, index cards, and a drawing program.)
Design was very important in our development process. While the first couple of milestones there was lots of time for, the later milestones are harder and all seem to have less and less time alotted for them. Thus the better the initial design, the less revision had to occur later. In addition, if you don't use any tools that do integration, I know we didn't, then you need to have your classes be fairly independent, meaning no god classes that everyone in the group needs to edit to get their stuff to work. The more seperate the classes are the more delineated everyone's responsibilities are as well. If a person is given a vague assignment like code the parser, they might not know if they do just the parser, the gui interface for the parser or any other extra stuff. However, if you tell everyone which classes they are responsible for as well as a general purpose of their part such as the parser, then everything will flow smoother. We had to learn these lessons the hard way.

Don't forget that design is usually worth half of each milestone, and you turn in pretty much the same thing for all the milestones after the design milestone. Thus if you do a good job the first time, you'll never have to modify the design and you'll reap the benefits on all proceeding milestones. Now if you don't give milestone 3 its proper time, then you will be stuck updating for all the following milestones, like we were. It is a huge pain to have to go back and change up scenarios, because once you do that, you have to change up the crc cards and then the UML and finally the testplan. You'll hate yourself, as we did, when you have to do this.



Our GEDCOM importing system is not integrated with the rest of our classes. This was not a deliberate decision. The system we (ahem) appropriated from the cases page included its own person-family-etc. classes, which were not compatible with ours. This should serve as a useful lesson for anyone intending to "save time" by re-using someone else's code: be very clear on exactly how you intend to integrate theirs with yours. It might have been useful to create "translator" or "wrapper" classes to facillitate integration without having to modify unfamiliar code too much. Another lesson learned is don't integrate on the last day, because you might find out that the code you've been handed, while doing its duty, is utterly useless.



Our biggest problem with regards to parsing are inconsistencies in the formatting of the results returned by the web servers. Some genealogical websites allow for extraneous information in their records; this information makes parsing very difficult. In the future, I would suggest trying to make things easier by picking web sites that use a consistent format for things like names and dates. Although many different genalogical sites exist, very few were available at no cost. (Also annoying are the multitude of sites that rely on CGI scripts or ASP to conduct searching. These require an HTTP-POST request, not a simple URL-style HTTP-GET. Frankly, I don't know how to do that.)



What can I say about merging. It's hard. If you don't write a good system up to this point, it will be difficult to do. I say this, because we had a tough time getting this to work.




If you are reading this section of our cases page that means you may be having some questions regarding SUnit. While the name sounds like JUnit and is quite similiar to JUnit, which you've probably used in CS2335, it is actually simpler to use in Squeak than in Java. Just as with JUnit, SUnit is employed to perform unit tests of testable methods for every class. Whether you like using SUnit for testing or not, it is a requirement for every milestone. Thus, it is better to embrace SUnit and utilize than to half-heartedly put it together and waste your time.

While I never found much use for JUnit while taking CS2335, I have come to embrace it more and more as the milestone wore on. Unlike in CS2335, where you make a design and then proceed to code everything at once, in this course, you start with a foundation and build the rest of the program on top of it. Meaning it is critical to make sure the foundation is working before you add on something new. With every additional milestone, I was forced to either add on to previous classes. My constant fear was that by adding something new, I had broken something from before. With SUnit, I was able to alleviate my worries by simply running my tests for all the previously established functionality.

How To SetUp SUnit

When doing M1, I had no clue initially now to setup the SUnit tests, because it was late at night and there wasn't much mentioned in class. I had to resort to looking through the case pages and just downloading someone else's SUnit tests and copying what they did. For that reason I decided to do a little SUnit tutorial to help the clueless, like myself, during M1.

I'm assuming you have some classes written by the time you want to start your testing. They should look something similiar to the FooBar class and helloWorld method I have in my example.

Uploaded Image: 1.JPG

Add an additional category for the corresponding tests if you would like, or simply add the classes on to the already existing category you have. It doesn't make a difference one way or another, but for this example I'm going to have them in seperate categories.

Uploaded Image: 2.JPG

Select a name for you category, or simply skip this step if you're going to just stick in with a pre-existing category.

Uploaded Image: 3.JPG

Make sure to sublclass from TestCase, instead of Object. Name your SUnit testing class whatever it used to be called with Test appended at the end i.e. FooBar –> FooBarTest.

Uploaded Image: 4.JPG

Now you are ready to create your test modules. You need to have a setUp and tearDown methods in your test class. You don't have to have anything in them, but you must have them. I typically used setUp as my initialization class for the instance variables I would be using throughout the testing. On the otherhand, tearDown I never used. Make sure to have your method names start with test i.e. helloWorld –> testHelloWorld. When writing the tests, the two methods I tended to use were deny: and assert:. If the two items being compared are equal, then assert will evaluate to true, but if the two items being compared are not equal, then deny would evaluate to true. So in the example below, assert is true when 3 = 3, and deny is true because 3 != 2.

Uploaded Image: 5.JPG

When you've written your tests and want to run them to see if everything is working or not working, just open up your workspace and type "TestRunner open." and select "do it".

Uploaded Image: 6.JPG

The gui below will pop up (although without the green). Select a test case and press "Run" or hit "Run All". If everything evaluates properly the gui will say that you passed and turn green as it does below. On the other hand if it doesn't pass, due to your tests not passing, it will turn red.

Uploaded Image: 7.JPG

Well that is my tutorial. Hopefully, if you have read this far, my tutorial has been of some assistance to you. If not . . . well . . . sorry.

Link to this Page