






Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007
Milestone 5-Application Design
Grading Criteria:
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
Application design was undoubtedly the most interesting phase of the project development. It was during
this process that we figured out with precise detail what our code would look like. It was important to
get acquainted with a UML drawing software so used Microsoft Visio to create most of our documents.
An advantage of using a software to create UML diagrams is that the diagrams can be edited/changed with ease
during the later stages of development.
Class Diagrams
The most important thing about class diagrams is that they are a static view of the system. Classes don’t exist
at runtime, only objects. A class diagram tells us about the structure of a system. What are the classes in the
system, how are they related and what are their interfaces (public methods and attributes).
Remember that design occurs at many levels. An analysis (or conceptual) model, shows the main classes in the domain
and how they are related. An implementation model, shows a refinement of the conceptual model to include the private
methods and attributes and the relation-ships in the model are transformed to actual decisions about storage mechanisms.
Classes are extended with lower-level helper classes that have nothing to do with the domain being modeled.
The most important symbol in a class diagram is the class box. It is divided into three sections:
Class name
Class attributes
Class methods.
Sequence Diagrams
Sequence diagrams are semantically equivalent to Collaboration Diagrams.
They serve the following purposes:
• Dynamic Model relating use cases (scenarios) and class diagrams
• Shows time ordering of interactions
• Generally a set of messages between collaborating objects
• Ordering of objects not significant, ordering of messages is.
• Sequences start with a trigger (usually an external actor).
Our Architecture

Scenario 1
POS Aspect.
A customer wants to buy 10 iPods from a POS of BestBuy located in Atlanta but the POS has only 4 iPods left.
The manager starts the application which displays the Main UI. He selects the specific POS from the list
and enters the password. The Interface sends the data to the database which holds the list of POS locations.
The data is compared to the POS data in the Database. If it matches, a POS UI containing the specific information
is displayed. Since the number of required items is greater than the items in the POS’ inventory, the customer
buys only 4 items. However, the POS sends an Invoice to the POS Queue to purchase new items since number of items
in Inventory is below Reorder Point. The POS Invoice Handle checks POSQueue for new Invoices. If the POS Invoice
Handler finds a new Invoice, it checks the Database for a Supplier that contains the item i.e. iPods that are required.
The POS invoice handler sends it to the Supplier which sends it straight to the SupplierQueue. If there are new
Invoices to be processed, it would process the Invoice containing the Items requested and send a Shipment to the
\POS. The Supplier Invoice Handler consistently checks the Supplier Queue for processed Invoices. When it finds a
processed Invoice, it checks the Database for the original POS and sends the Invoice to the POS. The POS updates its
Inventory. The scenario ends.
Sequence Diagram 1

Scenario 2
Supplier Aspect
Due to growing demand for personal robots and absence of personal robots in the inventory of all POS, the CEO of
Best Buy decides to add a supplier for robots and add it to the list of suppliers for further business. He also
wants to load the changes to the database and save them. The manager starts the application which displays the
Main UI. He selects the option to open Supplier UI and selects Add Supplier. He enters the name and the attributes
of the Supplier. The Interface sends the data to the database to add the supplier to the list of existent suppliers
and updates the lists of Suppliers. The supplier randomly generates items and creates an inventory. The Interface then
loads the changes onto it and saves it. The Supplier now appears in the list of Suppliers on the Supplier UI with its
attributes. The scenario ends
Sequence Diagram 2

Link to this Page