Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Team Mouse Trap - M3
For M3, we were asked to make a detailed plan that our group would use if designing and implementing Milestones 4 through 7. This plan was to include:
- Scenarios that touch on every class in the system.
- CRC card analysis through M7.
- Test Plan based in identification of equivalence classes in the input.
- UML class diagram for the final system with descriptions for each class.
- Description of what each team member is going to be responsible for.
- Internal group timeline with dates and milestones.
Since it took us a while to get together and actually have a meaningful meeting, we had but only three days to finish the entire design. In addition, we were not able to agree on any decent design for the genealogy program. Therefore, we subdivided the project so that no one person depended on any other person. In particular, one person did the scenarios since they dealt with what the user does and not with how the program works; this was possible since all the program requirements were already given. Another person did the CRC card analysis and the UML class diagram with descriptions since those two things dealt with program specifics like class names and which object deals with which object. The third person did the Test Plan since blackbox testing, the kind we used, does not require any knowledge of the code itself, just the program requirements. Finally, the last person did the descriptions of each memberís responsibilities and the group timeline.
Taking M1 design of one of the members, we connected it to another object that acted as the Controller. This object was created by the GenealogyMap class through another class that acted as a UI menu. The Controller communicated with all the classes that perform operations like network connections and family tree comparisons depending on the user commands received from the GenealogyMap. GenealogyMap itself was connected to all of the UI objects that take input and display output to the user.
The main problem with the design was an overly dependence on the Controller object to act as a manager for the entire program since it was the one to communicate with all the main classes. This problem was later solved by getting rid of the Controller object all together and connecting the GenealogyMap UI to all the objects that it requires to perform operations.
Our process for creating the design is a textbook example of what not to do. Too much time was wasted on procrastination and each member ended up working by himself with little input from others. Nevertheless, the results were excellent and all parts complied fully with the requirements. It seems that by working individually on a small part, each member was able to focus on making that particular part as good as possible.
UML class diagram [NOTE: remove ".x" from end of filename]