M5: The Rebirth of the Milestone

• Create your Software Architecture and Trust Boundaries
• Identify your Application and Utility Objects (those new objects specifically developed for the design. You do not have to say which are which, just id the ones that were added from the domain analysis) This should be easy, as all classes that were not identified with a CRC card will be in this category. You can annotate them on the class diagram, or you can list them separately.
• Add necessary CRC Cards and any new scenarios needed (for newly discovered domain classes if any). If you have no new classes, and nothing to fix from your TA meeting, then you may not have anything for this point. In that case you will receive the points for "free" as a reward for doing a good job the first time.
• Submit a UML Class diagram of your refined design (shows all domain and application/utility objects)
• Submit 2 UML Sequence diagrams that shows your full design handling one or more scenarios. You should make your scenarios interesting so these diagrams help you.
• Submit screen mockups that show your preliminary user interface. These screens can either be hand-drawn, or prototyped with the VW Painter and then captured.
• Submit a written contract (1 per person on the team) for an object or method in the design
• Submit a short paragraph on your error handling and exception handling design strategy.

• Architecture/Trust Boundaries.............. 10
• Application/Utility Class Identification .....10
• Updated CRC Cards...............................5
• Updated Scenarios................................5
• UML Class Diagram...............................20
• UML Sequence Diagrams.......................20
• User Interface Screen Prototypes...........15
• Contract .......................................... 10
• Exception Handling Strategy ................ 5

• We recommend that you all work extremely hard on this section. The UML class diagram is like the foundation of your project so it should be done with great care as it not wise to try and change it once you have started development.
• We also recommend that you do this as a group and not divide up the work. The reason being is that as a group you all can better identify potential errors or flaws and if something does go wrong you all can fix it collectively.

Link to this Page

• Team SXSI last edited on 8 December 2008 at 10:37 pm by lawn-128-61-24-229.lawn.gatech.edu