1. Use Case Model

2. C-S 5462 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

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

4. C-S 5464 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

5. C-S 5465 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

6. C-S 5466 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

7. C-S 5467 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

8. C-S 5468 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

9. C-S 5469 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”

10. C-S 54610 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 “ >” –example : “withdraw” includes “update account”

11. C-S 54611 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 “ >” Notice that the arrow is reversed –example : “withdraw” is extended by “check for privileged customer”

12. C-S 54612 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

13. C-S 54613 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

14. C-S 54614 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

15. C-S 54615 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

16. C-S 54616 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

17. C-S 54617 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

18. C-S 54618 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

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

20. C-S 54620 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

21. C-S 54621 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

22. C-S 54622 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”); }

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

24. C-S 54624 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