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


To design and plan the structure of the rest of our GenealogyMap.

For designing our Genealogy Map for the rest of the milestones, we took into account the purpose of each milestone. First, we sat together as a group and listed the objectives and details of each milestone. Using this information, we then made a UML diagram of how each class relates to the others. The following is the UML diagram that we had for Milestone 3. Although we tried our best to make a good design for our project, there were still many flaws in this design which we corrected in later milestones. The following is the UML design that we originally had for milestone 3.

Uploaded Image: M3-uml.jpg

This milestone was great because it forced us to really think about our design for the rest of the project. Although it was kind of hard to think about each of the future milestones without actually knowing the details of them and how they function, our group was very satisfied with our design, especially the fact that our implementation of the GUI was unique compared to that of other groups. Most of the groups used text boxes consisting of the names of each family member, while ours had a headMorph with a mouseOver balloonText containing the information about the person. Some problems and questions that we came up with during our design was:
1) would our headMorphs be hard to implement and create other problems which will deter the purpose of our genealogy map?
2) for the menus, if the user clicks on a menu option, the window that pops up forces the user to choose another option or else he will not be able to perform other functions in the program.
3) how will we deal with merging and unmerging and incorporate this into our headMorphs and GUI side of our program?

The following are the files that we submitted to our TA.

We also submitted a UML diagram, which is already included in the above.

Comments from our TA regarding these files:

1)The class diagram is pretty good. Don't, however, draw solid lines for every place one class talks to another one. Solid lines are for long-term has-a relationships. Use dotted lines if you want to represent talks-to, or just leave them out.

2)The scenarios are excellent! Keep them in mind and they should be
very useful at your design meetings.
One small problem about these scenarios is that they are mentioning UI
details. The UI as a part of the design should be left to be filled in later.

3)The CRC cards are good, but the class names should not mention "object" or "info" and "every" class should hold info and have instances that are objects. Also, don't use verbs for class names! Be wary of classes that are just actions. You can often make these into methods of existing classes.

4)The test plan is good, though it is on the skimpy side. Also, don't just divide into invalid and valid; partition the data however seems reasonable. For example, having nil as an attribute is an interesting partition, and shouldn't really be folded into a generic "valid" category.

5) The design is excellent.

[Home] | [Milestone4]

Link to this Page