DD1363, Mjukvarukonstruktion
Aktuell kursomgång: period 2-4
07/08
Kursledare: Rand Waltzman
Datorpostadress(er): rand@nada.kth.se
Homework 4
Solutions
See Homework page for general information.
1. The minimal guarantees are the fewest promises the system makes to the stakeholders, particularly when the primary actor’s goal cannot be delivered. They hold when the goal is delivered, of course, but they are of real interest when the main goal is abandoned for some whatever reason. Write the minimal guarantee for withdrawing money from our famous ATM for each of the following three stakeholders: (1) customer, (2) bank and (3) oversight agency.
2. The success guarantee states what interests of the stakeholders are satisfied after a successful conclusion of the use case, either at the end of the main success scenario or at the end of a successful alternative path. Write the success guarantee for withdrawing money from the ATM.
3. Critique
the following use case:
Use Case: Login
This use case describes the process by which users log in to the
order-processing system. It also sets up
access permissions for various categories of users.
Main Scenario:
1. The use case starts when the user starts the application.
2. The system will display the Login screen.
3. The user enters a username and password.
4. The system will verify the information.
5. The system will set access permissions.
6. The system will display the Main screen.
7. The user will select a function.
8. While the user does not select Exit, loop.
9. If the user selects Place Order,
Use Place Order.
10. If the user selects Return Product, Use Return Product.
11. If the user selects Cancel Order,
Use Cancel Order.
12. If the user selects Get Status on
Order, Use Get Status.
13. If the user selects Send Catalog, Use Send Catalog.
14. If the user selects Register
Complaint, Use Register Complaint.
15. If the user selects Run Sales
Report, Use Run Sales Report.
end if
16. The user will select a function.
end loop
17. The use case ends.
Solution 1:
The easiest way to find the minimal guarantee is to ask, “What would make a stakeholder unhappy?” The stakeholders are the customers, the bank, and the banking oversight agency.
The customers will be unhappy if they don’t get their cash, but that is not expected in the minimal guarantee. Let’s assume that they don’t get their cash. In that case they’ll be unhappy if they are debited for the transaction. In fact they’ll be unhappy anytime they are debited for more than the cash they receive. They also want a log of all transactions, so they can defend themselves against fraud.
The bank will be unhappy if the customer gets more cash than the amount debited. It also wants a log to protect itself, probably a special kind of log that says how far the transaction got in case of catastrophic failure so it can sort out any errors.
Te oversight agency wants to see that guidelines are being followed, so it is mostly interested that a log of all transactions is produced.
As a result, we have a minimal guarantee that the amount debited equals the amount dispensed, with a micro-log of how far the transaction handling got in case of catastrophic failure. Also, each transaction is logged.
Solution 2:
The success guarantee is that the account is debited the amount dispensed (not the amount requested – check failure conditions!), the card is returned, the machine is reset, and a log is made of the transaction.
Solution 3:
The use case contains three kinds of mistakes. The first thing to catch is that the use case is not about logging in regardless of what the use case name and description say. It is about using the order-processing system. The real use case here is a summary use case. The first six steps are about logging in, but that is at a different goal level entirely and should be separated out. Once we do that, we notice that the user logs into this system but never logs out!
While the user does not select Exit loop, end if, and end loop are programmer constructs that will not make sense to the users reviewing the use case. The continual if statements clutter the writing. The steps describe the user interface design. All of these should be fixed.
The use case starts when … and The use case ends when … are stylistic conventions preferred by some. There is nothing particularly wrong with them. They are simply ornamentation, which I don’t find necessary. Most people naturally assume that the use case starts with step 1 and ends when the writing stops.
The other style to note is the phrasing, User … Use Place Order. The “use” in that phrase refers to the includes relation of UML (formerly called the uses relation). I find it clutters rather than clears the writing, and so I prefer User … places the order. You will probably follow whatever convention your project team sets up for referring to other use cases.
In the end, we find two use cases to pull apart: Use the Order Processing System, and the sub-function, Logs In. I include Use the Order Processing System below. You can write the Logs In use case on your own. Note that the links to other use cases are underlined.
Use the Order Processing System:
1. User logs in.
2. System presents the available functions. User selects and does one of:
a. Place
Order
b. Cancel
Order
c. Get
Status
d. Send
Catalog
e. Register
Complaint
f.
Run Sales Report
3. This repeats until the user selects to exit.
4. System logs user out when user selects to exit.
Upp till Nadas kurser.
Sidansvarig: <rand@nada.kth.se>
Tekniskt stöd: <webmaster@nada.kth.se>