View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007

The Dream Team M5

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. These are all the classes that don't fit into the domain, like data structures, network and thread classes, database access classes, UI classes, data validation classes, and any other classes necessary for this to run on a computer, but are not really part of the domain itself (and thus don't have CRC cards).
-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. Remember that the contract is basically the pre and post conditions of the method, or guarantees of the object as a whole.
-Submit a short paragraph on your error handling and exception handling design strategy.

Criteria Breakdown:

-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

Comments
For this milestone we had to start thinking about the actual architecture of the program. Using our CRC cards we developed the trust boundaries diagram below. These trust boundaries were used while coding to insure secure code and to prevent exceptions from occurring due to faulty data. The trust boundary and system architecture diagram is a very simple image that just shows trusted and untrusted connections. With our architecture we considered all connections between our main objects of store, supplier, and central, to be untrusted while connections within these main objects were considered trusted.

INSERT TRUST BOUNDARIES

Using our general understanding of the requirements for the application, we then created a UML class diagram. This diagram shows the style of connections that are formed between our pieces of code. For example we decided there will be many stores but each store will have only one inventory. Decisions like this and how to associate various classes came down to group discussions with differing ideas of the system architecture. The class diagram helps to give you an idea of how the system will look at the start of the application. Each item within the class diagram is a class with the classes name, attributes, and methods detailed within its box.

INSERT CLASS DIAGRAM

Sequence diagrams take the class diagram and put it into action. Each sequence diagram follows a particular simulation from start to finish and details all the objects involved, the methods called, and the results returned. Here you slowly walk through your code and are able to determine from the start if there are going to be issues with your system architecture. This step will also help in next phase when you are actually coding as you'll have already experienced your code on paper.

INSERT SEQUENCE DIAGRAM

In this sequence diagram we detailed the process of shutting down the system. This entire idea was later scraped when we came up with a much simpler system for saving but it did get us thinking. The sequence diagram shows the central requesting a database save from the store and supplier. Store and supplier then do a database save and return their databases. Central then saves its own database with all the database stores within it, and then shuts down the application.

note-swiki says upload limit reached?

Link to this Page