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

Milestone 3 - The Design

Requirements

Spring2004 M3 - Design the whole thing

Complications

The design had to be done in Spring 2004 Ectropic Design, so this meant learning another new tool.

Phase 1 - Analysis

Reuse

The group started with domain analysis. A project very similar to this one had been done a few years ago, so the first thing to do was go through the other cases and see which ones we had the most to gain from. We found a project on the cases pages that looked like it had a lot of what we wanted to do: The CS Majors - The Genealogy Application.

The CS Majors had managed to write some beautiful morphic code for displaying genealogical information. Our team lacked the ability to program morphic well, so this was a godsend.

ECoDE

We also took a week just to play with ECoDE and try to work out the kinks before we put anything definite into it.

CRC

We met at Table 14 in the CoC and each of us wrote down CRC cards for a few classes we thought we'd need. We passed them around, and the next person would go over what we'd written and make changes. During this time, we would also ask questions of each other about how we wanted the design. When one person made a change to our card that we disagreed with, this brought up design discussion. We benefitted here because all of the kinks were worked about how the design would come together. We could make decisions and make sure everybody was on the same page about what we were doing.

The cases pages were also a big help here. The other projects had all approached many problems in the domain, so we had a good idea of the domain when we first started making CRC. This helped minimize questions like "What is a genealogy?", "How might one show genealogy information?" Each of us had seen how it was done many times over, so we could focus on what we believed should be our way to do it. This information was very good to have, and I suggest that any group make sure they really have seen the field before even starting to write down classes.

Phase 2 - Design

Use Case Diagram

The next step was to make a use case diagram for the activities that the user would take in the system. This was mostly a drawing of the major activities we were going to be graded on. We did not use this diagram often, but the list we wrote there was translated almost directly into our scenarios, so it helped keep the focus on what we were being graded on.

Class Diagram

Next we designed the relationships between the classes. These initial drawings served as a good guide for us. As the event notification system changed in the code, the class diagram didn't change, because the underlying notification system didn't change the relationships. Making this correct the first time made it a lot easier to keep updating in throughout the milestones.

Scenarios & Test Plans

The group split up the scenarios and test plans by milestones and we worked on them individually. Then we verified them by swapping them around again.

ECoDE

Keyur and David handled putting all of what the group had done into ECoDE.

Conclusions

The Good

Splitting up the work while collaborating at the same time was a great decision. The design was huge, and passing it around while still focusing on our portion made us "experts" in our subsystem while still knowing the whole project. This became invaluable later when turnin time was coming and I didn't have time to update the design docs, but I could describe what I changed to somebody else in the group and they would know how to update the design.

The Bad

Our major mistakes here were misunderstanding ECoDE. We should have put more time into it.

Files


Back to Table 14

Link to this Page