Hotspots: Admin Pages | Turn-in Site |
Current Links: Case Final Project Summer 2007
Team Shiny Milestone 5
Team Shiny
Milestone 5
Back to Home
Team Shiny Project Description
You will continue your design by moving from the Domain-level model to the actual
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. 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.
Architecture/Trust Boundaries
We chose this particular type of architecture in order to kill two birds with one stone. It not only shows
the type of each class, but also, each "layer" is a different trust boundary.
Application/Utility Class Identification
The application and Utility classes are:
CCS UI
POS UI
Supplier UI
SupplyChainAppModel
Simple Dialog
Updated CRC Cards
So these are the official updated cards. The changes are failry obvious (things crossed out, multiple
people's handwriting) and we also added a clas, Invoice.
Updated Scenarios
1. Bob is using the management system to add newly opened POS that needs to order an entire stock of items for its opening celebration. And yes there will be balloons.
2. After a few years of working with Bob, one of the stores has recently decided to sell their items in a different fashion. Bob needs to change the sale policy of the POS and work with the seller to make sure stock doesn’t run out as such.
3. Bob gets an invoice from a POS that they are running out of x-boxes. Bob then works with the supplier to get more x-boxes, but the supplier is out and backorders must be made.
4. A large group of cheerleaders come in and buy all of the apples from a grocery store and an emergency order must be made or else all the suburban housewives will go on strike. Bob must quickly order apples from the supplier.
5. Bob is trying to merge with another company and needs to be able to present his ideas at a board meeting. Using his system he needs to print out multiple charts related to the data he deals with
6. Bob is hiring a new secretary and needs to be able to show her where all the invoices need to be handled on the CCS.
7. A supplier goes out of business and is bought out by a different supplier. The items need to be transferred from one to the other and adjusted in the central system.
8. As part of a holiday promotion, one of the companies that Bob deals with is putting all their items at 20% off. Bob must adjust the sell price of the items to show changes in the report.
9. The nearby Shoes-R-Us recently went out of business and their entire stock is being bought out by Shoes-R-U. Bob must make the appropriate adjustments to all stock items.
10. Noah was recently set on fire and needs new clothes. The store Noah goes to doesn’t stock this item, but contacts Bob to try and get him what he needs. Bob, feeling sorry for him, finds the store he needs.
11. After the fire scenario, Noah realizes he lost one in his specific collection of yellow sponges. He contacts Bob to try and find these yellow sponges of a specific lot number.
User Interface Prototypes
UML Class Diagram
Important Note:
We did not realize that UI classes should be included on the Class Diagram. They are, in fact, an essential
part of the diagram. If you do not include them you will lose a substantial amount of points.
However, beyond that glaring oversight, this is a decent class diagram.
UML Sequence Diagrams
Contracts
Contracts can be done on either methods or entire classes, as shown here. These contracts show a good layout
by providing pre-conditions, post-conditions, and the actual effect. These are obvious in the cases of methods,
but are more subtle for classes.
Exception Handling Strategy
The most likely source of an error condition in our application would
be desynchronization of data - if a user deletes a particular
supplier, for instance, and then places an order with that supplier
from an area of the application that has an out-of-date copy of the
supplier list. We can resolve this either by having the various
program components keep references to, rather than copies of, each
others' data, or - more securely - give the components references to
each other and send notification messages around when the data they
maintain changes. Other errors might come from bad user input -
strings for number fields, invalid (<1) quantities in an order, that
kind of thing - and will be addressed with appropriate checks for such
conditions.
Milestone 5 Grading Ruberic
-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
Team Shiny Milestone 6
Team Shiny
Links to this Page
