Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Summer 2005 Milestone 3
This time you should take the time to do a careful design for the rest
of the system that you know about – that is, for M4. You may design
your classes and messages however you desire to meet the basic
requirements of the system. Just keep in mind good Smalltalk style
for message names and overall design principles. Your design is
worth 20% for the milestone, so don't hack and don't
shortchange your analysis. If the requirements do not specifically
state something, you are free to implement and design however you
want. This is a design class, and we want to see what you come up
Your design will surely change over the following weeks, but we want
to see that you've gone through the process and made a plan up front.
Make a plan! The following pieces must be included, but otherwise
it is free form.
Specification for Two Denizens
You must include a description of your two new denizens. Write down
enough information about what they do that you could hand it to a
random software team and have a reasonable expectation that they
implement what you wanted.
You should write scenarios that touch on all major functions of the
assignment, including Milestone 2, from the user's point of view. See
CRC cards analysis
You should turn in photocopies of your CRC cards from your OOA for M2
UML class diagram
Turn in a class diagram of what you plan to implement. You may use other
UML diagrams in addition to class diagrams if you want to further plan
and describe your system.
Remember the design criteria you have seen already:
- Don't have a god class that controls everything. Spread responsibility and data across many classes.
- Don't represent data multiple times. Find a way to put it in one place and have everyone who needs it get access to it.
- Don't repeat functionality in multiple classes. Find a way to capture common behavior, perhaps using subclasses.
- It should be clear what each class represents, and its methods and attributes should be consistent. Don't give the Clock class a "position" attribute that has nothing to do with clocks.
Some of these rules are contradictory. Strive for a balance
Make sure that your scenarios are all covered. Step through each one
in your diagrams the way we did with the VCR example in class.
Your test plan should describe how you plan to check that your system
works. You should include tests based on blackbox test criteria. You
should document when and how you will perform your tests. Not all of
your tests need to be SUnit-based – be creative.
See About Test Plans.
Team Member Responsibilities
Write down what each team member is going to be responsible for. Be
thorough. Can you tell who will implement which classes and methods
from your class diagram? If something fails, will you be able to
figure out whose responsibility it was?
You should have a group timeline. It should include when you will
finish each piece of functionality. Don't forget to schedule time for
group meetings and for integration. You might consider
scheduling group hack sessions.
The easy part. :) Please include on your cover page:
- the group's name
- your TA
- the team members, including their gt#
- what milestone this is for
If you would like to see good examples of project plans, check out the
Cases page to see what other groups in past semesters have done.
Double check the list so that you don't leave anything out. Many
groups lose 10 points here and there because they left out a component
- 10% scenarios
- 10% CRC card analysis
- 10% test plan
- 20% UML
- 20% quality of the design
- 10% team member responsibilities
- 10% timeline
- 10% cover page
Link to this Page