Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Fall 2003 M3: Design everything
(Group, Due 10/07)
It's now time to plan, analyze, and design your system. This milestone is much more open ended than M1 and M2. 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 half your grade 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, we want to see what you come up with!
Goal:
- Plan, Analyze and Design the Entire System
Questions on Fall 2003 Milestone 3
Requirements:
The Squeak Guide is an application designed to communicate to new users how to complete a variety of different tasks in Squeak. The Guide can communicate how to complete a particular task in at least two ways: walking the user, step-by-step, through text instructions, and actually demonstrating to the user how to complete a particular task.
Your application will embody the Guide through a combination of 2D and 3D graphics. You will implement a 3D avatar for the Guide that can wander around the screen and point out various aspects of Squeak's interface. You will also provide 2D elements that allow the user to communicate with the guide (e.g. asking for help on a particular topic, asking for the next step in the instructions) and the guide to communicate with the user (e.g. telling the user how the guide accomplished a particular subtask, such as displaying the World Menu.
Because creating a demonstration engine that allows your Guide to demonstrate any part of Squeak is infeasible in the time alloted, you'll instead by designing your engine around a subset of the possible tasks. To determine your initial subset, choose 5 tasks from the list provided by the instructor. Design your system so that you can help users complete those tasks, using the requirements of Milestones 4-7 to drive your design. Keep in mind that your system will need to be flexible enough to handle 5 additional tasks supplied by the instructor for milestone 7, so don't just design your system to support your 5 tasks.
Subsequent Milestones
Look at milestones 4 through 7, which are your actual programming milestones. Along with the information in this milestone, you should then have enough information to design the entire system. Each milestone represents the LATEST time that functionality can be provided. At each milestone, we will only grade the functionality required to be present at that milestone. Basically you can view milestones as your latest acceptable delivery date. You may, of course, create the desired functionality earlier if it will help your project succeed.
"Demonstrating" your design to your TA
10% of your grade will depend on talking to your TA half-way through this milestone, getting feedback from them, and using that feedback to improve your design. Since you have 3 weeks for this milestone, "half-way" means sometime during the week of Sept. 22-26. We've extended this deadline to Sept. 30, but you must have demoed by then to get full credit. Note that you must have created enough of a preliminary design that your TA can actually give you constructive feedback.
Regression Testing
At each milestone we will quickly regression test your old code to ensure you have not broken anything. This is where SUnit can really help you. By having unit tests already coded, you just hit the run test button and verify that your test bar is still green. Whenever you find a "bug" in the system that was not caught by SUnit, you should add an SUnit test that would have caught it. That way, you can be sure that old bugs do not get reintroduced into your code base.
Note about CVS
There is no requirement that your team has to use CVS or any other version control system. Configuration control systems do make code exchange and work easier. I do recommend you look at using CVS with the Squeak interface DVS as a good way to work with your team in controlling and exchanging code. Check the class lecture where the DVS tutorial link is provided.
Turn-in
Teams must turn in a detailed group plan for each milestone THROUGH THE REST OF THE CLASS (i.e. through M7). This should include:
- SCENARIOS (About Scenarios) that touch on EVERY CONCRETE CLASS IN YOUR SYSTEM.
- CRC card analysis for ENTIRE system (through M7).
- TEST PLAN (About Test Plans) that corresponds to the CRC card analysis, based on blackbox test criteria (i.e equivalence or boundary conditions).
- UML class diagram for the ENTIRE system with descriptions for each class. You may use any other UML diagrams in addition to a class diagram that you would like in order to describe your system.
- DESCRIPTION of what each team member is going to be responsible for
- Internal group TIMELINE with dates and milestones
Each team will submit a joint document with cover page. The cover page should show the team name, the team members by name and gt# and their grading TA. It should also have the date submitted and the Milestone number clearly shown.
For this milestone, each team must also turn in hardcopy of the step-by-step instructions for the 5 tasks they chose.
Obviously, the design will change over the following weeks, but we want to see that you've thought through everything UP FRONT.
Note: 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.
Grading:
- 10% Good, believable scenarios that touch on every class in the system.
- 10% Good CRC Card Analysis: Reasonable names, understandable and clearly defined responsibilities, good exploration of other class names
- 10% Good test plan: equivalence classes clearly identified, test cases clearly defined.
- 10% "Demonstrating" your design to your TA half-way through this milestone and incorporating their feedback.
- 20% Good UML class diagram and descriptions:
- Correct usage of notation (10%)
- Detailed and understandable descriptions and names (10%).
- 20% Quality of the design, including step-by-step instructions
- 10% Clear definition of team member responsibilities: Can you tell who will do which pieces of system (as defined in UML and descriptions)? Will you be able to figure out whose part failed if there's a failure?
- 10% Believable and detailed group timeline: Could someone figure out from this what they're supposed to be doing each week? Can a team member figure out what they're supposed to have done each week from this?
Links to this Page