Due: Wednesday, October 29 in the Distribution Center
| Name: | YOUR NAME |
|---|---|
| Student ID: | YOUR ID NUMBER |
Consider this description of credit card processing. (Note: this example is much simpler than real credit card processing.)
A. Draw a UML class diagram that represents the situation as precisely and completely as possible. Include, classes and/or interfaces, attributes, operations, associations, and generalizations and/or realizations. Specify association multiplicity and aggregation, but not navigability. Do not include visibilities. Note important constraints in English. This is a design diagram that will be used by a programmer to guide implementation of the system.
USE ArgoUML OR Rational Rose TO MAKE A DIAGRAM, PRINT IT, AND STAPLE IT TO THESE PAGES.
B. Draw a UML state diagram for a transaction. Specifically, model how transaction change states from a new attempt to an authorized, settled, finalized, declined, or reversed purchase.
USE ArgoUML OR Rational Rose TO MAKE A DIAGRAM, PRINT IT, AND STAPLE IT TO THESE PAGES.
C. Draw a UML state diagram for an account. Specifically, clarify the meaning of "good standing" and other states that are not in good standing. Use transitions with guard conditions to express the ways that an account can change standing. Express your guard conditions in terms of attributes you defined in part A.
USE ArgoUML OR Rational Rose TO MAKE A DIAGRAM, PRINT IT, AND STAPLE IT TO THESE PAGES.
D. Draw a sequence diagram that explain how the "out-of-town purchase" use case could be implemented. The system consists of three communicating components: (1) a point-of-sale payment terminal, (2) the merchant's payment processing server, and (3) the payment authorization and settling system at the cardholder's bank. Label your diagram with messages that invoke operations you defined in part A.
USE Rational Rose TO MAKE A DIAGRAM, PRINT IT, AND STAPLE IT TO THESE PAGES. (ArgoUML cannot be used for sequence diagrams at this time.)
E. This problem specification may not be complete. By working through the design, you may realize that information is missing from the requirements. Now that you have worked through the design, list one to four questions that you have uncovered about the requirements.
TYPE YOUR ANSWER HERE: 1-4 SHORT PARAGRAPHS
A. Describe two types of software product where prototyping would not be useful.
TYPE YOUR ANSWER HERE: 2 PARAGRAPHS
B. Imagine that your team produced a throw-away prototype for a system that will be used inside your company. Your boss sees the prototype and realizes that the system was a bad idea in the first place. He decides to cancel the project and reassign developers to other projects. Is that a successful or failed use of prototyping, and why?
TYPE YOUR ANSWER HERE: 1 PARAGRAPH
A. Write in the suggested axioms for this algebraic specification of a stack data structure.
Hints: Algebraic specification deal with mathematical equations, not sequences of commands or assignments. You can use nested operations on both sides of the equals sign. You do not need any if-statements for this specification.
A stack is a list where items are both added to and removed from the same end of the list. The operations are:
| Comment | Operation |
|---|---|
| New -> Stack | Create a new stack |
| Empty(Stack) -> Boolean | True if the stack is empty |
| Push(Stack, Elem) -> Stack | Pushes an element onto the stack |
| Top(Stack) -> Elem | Return the top-of-stack without removing it |
| Drop(Stack) -> Stack | Remove the top-of-stack and return the modified stack |
| Swap(Stack) -> Stack | Switch the top-most and second-to-top element and return the modified stack, otherwise no effect |
The axioms are:
| Axiom | Comment |
|---|---|
| Empty(New) = True | A new stack is empty |
| Empty(Push(s, x)) = False | Any stack with anything pushed onto it is not empty |
| Top(New) = Undefined | The top of a new stack is undefined |
| WRITE YOUR AXIOM HERE | The top of the stack is the item most recently pushed |
| WRITE YOUR AXIOM HERE | Dropping an item from a stack that had an item pushed is the same as the stack before the push |
| WRITE YOUR AXIOM HERE | Dropping an item from a new stack is undefined |
| WRITE YOUR AXIOM HERE | The result of swapping a stack with x and y pushed onto it is the same as the stack with y and x pushed. |
| WRITE YOUR AXIOM HERE | Swapping a new stack that had one item, x, pushed onto it should return the same stack with x still there. |
| Swap(New) = New | Swapping a new stack is still a new stack |
B. How does writing an algebraic specification help your team implement and integrate an overall system? How could it help you test the stack module?
WRITE YOUR ANSWER HERE: 2 PARAGRAPHS
example use case templatesample test plan templateProject plan template