Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007
M5 - Application Design
M5 Requirements
- 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.
S/w Architecture & Trust Boundaries:
UML Class Diagram
ClassDiagram11-2.jpg
Sequence Diagram
Sequence Diagram1.jpg
Sequence Diagram2.jpg
Scenarios
Scenarios.doc
Screen Mockups
prototype.doc
Contract
Contracts.doc
Exception Handling
For exception handling, we have a divided strategy. For all user
generated exceptions we will handle the exceptions by spitting out a
message to the user and demand him/her to correct his mistake. If the
exception is generated from a collision of random events, then we will
have a dominant event which will supersede the "recessive" event and our
exception will effectively make our recessive event not happen. If there
is a failure in our design then we kick the player back out of the
instance of the game and say what is wrong and suggest a fix through the
exception.
Some examples:
A player offers to trade an amount of item they don't have.
We would plan on stopping the player from doing this by limiting
the number of items they can offer using the user interface. The user interface
will know from the domain, how much of an item the user actually.
Loading an invalid file.
If the game trys to open an invalid save file, The program will tell the
user that the file loaded was invalid and that they need to make another selection that is
the valid file type, while also bringingback up the model window.
Player is dead but the program wants to give them a sickness at the same time
For this exception we plan on making the death event supercede the sickness event.
Recommendations:
- M5 is one of the longest parts of the project, so make sure to start as soon as possible
- Make sure that in your architecture there is no cycle among dependencies of classes, also only one class, the simulation engine, should communicate with the application model. Try this class to be the brain of the project
- You will find out that you will most likely add new classes, which is quite normal.
- The more time you put into your UML design the less you will have to work in future milestones
Link to this Page