Use Case Model

1. Use Case Model

2. Use case model • describes what the user expects the system to do • functional requirements • may describe only the functionalities that are visible to the user • requirements view • may include additional functionalities to elaborate those in the previous step • design view • consists of use case diagrams and textual descriptions C-S 546

3. Elements of a Use Case diagram System dependency Use case Use case association generalization association Use case Use case dependency actor C-S 546 actor

4. Definitions • System • a black box that describes the system or subsystem that is modeled • example: ATM system, account verification subsystem • represented optionally as a rectangle in the use case diagram, but generally not shown • Actor • a role played by an external entity that interacts with the system • One object may play multiple roles in a context in which case there will be multiple actors • example: bank manager as a customer C-S 546

5. Definitions (continued) • Primary actor • an actor who initiates the major, main or important use cases in the system • example : a customer in a banking system • Secondary actor • an actor who is involved with one or more use cases but does not initiate the use cases • example : database • The concepts of primary and secondary actors will be useful in ranking the roles played by the actors C-S 546

6. Definitions (continued) • Generalization between actors • one actor can be a specialization of another actor • based on the same concept as the specialization relationship between classes • example : preferred customer in a bank is a specialization of a customer C-S 546

7. Definitions (continued) • Use case • an important functionality to be implemented and is visible to the actors • an interacting behavior between an actor and the system • Must yield an observable result to the actor • example: “deposit” in a banking system C-S 546

8. Definitions (continued) • Association • an interaction between an actor and a use case • represented by an arrow between an actor and a use case • unidirectional associations must be represented by arrows • direction of arrow indicate information flow • bi-directional associations can be represented by double-sided arrows or straight lines C-S 546

9. Definitions (continued) • Generalization between use cases • based on the same concept as generalization between classes; uses the same symbol • one use case can be designated as a specialization of another use case • example: “withdraw with overdraft protection” is a specialization of “withdraw” C-S 546

10. Definitions (continued) • “include” dependency • one use case may include another use case • if use case A includes a use case B, B must be implemented in order to implement A • based on the same concept as modular programming • represented as a dashed arrow from A to B with a label “<<include>>” • example : “withdraw” includes “update account” C-S 546

11. Definitions (continued) • “extend” dependency • one use case may be extended by another use case • if use case A is extended by a use case B, then both A and B can be independently implemented and used • A will occasionally use B depending on some constraints • based on the same concept as modular programming • represented as a dashed arrow from B to A with a label “<<extend>>” • Notice that the arrow is reversed • example : “withdraw” is extended by “check for privileged customer” C-S 546

12. Constraints in a Use Case model • every use case must be connected to an actor or be included in another use case or extends another use case • every use case connected to an actor must return an observable result to the actor • may be data or confirmation of termination of an action C-S 546

13. How to find actors? • those that interact with the system (provide input, observe results, provide control information, …) • primary actors • those that are used by the system but external to the system • secondary actors such as data stores • information about actors can be found in the problem description • generally, users of the system are primary actors C-S 546

14. How to find use cases? • every requirement is a use case • every functionality that supports the implementation of a requirement is a use case • design issue • found when the first (abstract) use case model is refined to express a design C-S 546

15. How to find use case relationships? • extracted from the application domain • must be justifiable from the application domain or from the designer’s choice • examples • “withdraw” includes “update account” is justifiable from application domain • “withdraw” is extended by “withdraw with overdraft protection” is a designer’s choice • designer can always implement two different versions of withdrawals C-S 546

16. Use case narrative • not part of UML notation • textual descriptions of a use case • important for design and implementation of use case • most OO tools provide a mechanism to add use case narratives • see Rational Rose for example • may include additional information and constraints on the use cases • pre and post-conditions C-S 546

17. Use case instance • a particular situation of a use case • generally described using an activity diagram (to be discussed later) • shows the algorithmic version of a use case • there can be several instances of the same use case, each having a different result • examples • Successful withdrawal • “withdraw” denied because of insufficient balance • “withdraw” denied because of overdraft violation C-S 546

18. Case Study - ATM • Model only the transactions • Customer accounts assumed to exist • Opening and closing of accounts is handled by another portion of the system • Include operations “deposit”, withdraw”, “check balance”, “transfer” • If balance is zero or less than the amount to be withdrawn, then withdrawal should fail C-S 546

19. Login Logout Deposit customer Withdraw Check balance Database Transfer All dependency relationships are of type <<include>> C-S 546

20. Use case narratives - ATM • Deposit • Using this functionality, a user will be able to add some money to his/her account • Account identification and amount to be deposited must be input • Upon completion, the balance in the account will be updated to include the additional amount • Check balance • A user can check the balance in an account using this functionality • Account identification must be input and the balance in the account will be output • The account remains unchanged upon completion C-S 546

21. Use case narratives – ATM (continued) • Write the narratives for “withdraw” and “transfer” • The narratives more or less reflect the requirements as written in a requirements document • A requirements document may also be referred with a cross reference in each requirement pointing to the appropriate use case in the use case diagram C-S 546

22. Use case instance – “deposit” Deposit (ACCOUNT_IDENTIFIER acct, MONEY amount) { if (validate_account (acct)) { account = retrieve_account (acct); account.balance = account.balance + amount; write_account (account); // update the database } else display (“Invalid account identifier”); } C-S 546

23. Login Logout Validate account Deposit customer Withdraw Update account Check balance Database Transfer All dependency relationships are of type <<include>> Use case diagram for ATM - revisited C-S 546

24. ATM - Exercises • Write the narratives for the revised version of ATM use case diagram • Enhance the diagram to include the following: • A manager can open an account • A manager can close an account • An account may come with overdraft protection during withdrawal C-S 546