9_Use_Case_Diagrams

1 .Lecture 9 : Use Case Diagrams Use Case Diagrams 1 Learning Goals Define and distinguish between User Stories and Use Cases Describe a set of use-cases and use-case scenarios given an application Give examples of use-cases for a given system Draw a Use Case Diagram for a system Differentiate between include , generalize , and extend relationships © Paul Davies, C. Antonio Sanchez. Not to be copied, used, or revised without explicit written permission from the copyright owner.

2 .User Stories and Use Cases Use Case Diagrams 2 Capture the functional requirements of a system Describe interactions between actors and the system Actor : a person or thing that has a “goal” in the system (e.g. User, Organization, Software System) Not necessarily a single individual, so sometimes referred to as roles Goal : a purpose, or something to be achieved through interaction User Stories take the viewpoint of an actor and list it’s goals Use Cases describe all the actors and their goals in detail

3 .User Stories User Story: “As a <role>, I want to be able to <some goal> so that <some reason>” Use Case Diagrams 3 http://dilbert.com/ Often used in the planning stage, each “story” describing one feature of the software.

4 .Example User Stories – Video Rental Library Use Case Diagrams 4

5 .Use Cases Use Case Diagrams 5 Use Cases explore each User Story, analyze the requirements and how they can be achieved in terms of interactions between the actor and system. What data goes in/out (the interaction) What effect this has on the system What the benefit to the user is (the objective) Describes the sequence of interactions to accomplish a specified, identifiable task, from a high-level perspective, and is written in plain language .

6 .Checking out a book for loan. Checking in a returned book. Checking if a book is in stock and where to find it. Reserving a book that is currently out on loan. Dealing with payment of overdue fines. Adding new members to the library. Deleting old members from the library. Dealing with changes of members details e.g. name address etc. Use Cases: Library System Use Case Diagrams 6 Library Use cases

7 .Use Cases: Library System Use Case Diagrams 7 Checking out a book for loan . What needs to take place for this to occur? Benefit: Interaction: Effects: Member identifies him/herself with id, indicates which book If user is allowed and book is available, lend book for a specified period Update records of loan and availability Member’s loan record updated to reflect loaned books Library’s loan record updated to show book availability Member goes home with a book

8 .Use Cases: Library System Use Case Diagrams 8 Use-Case: Borrow Book The member identifies him/herself to the librarian using membership identification card. The member presents one or more books to the Librarian. The Librarian checks the books to make sure they can be loaned. The Librarian checks the membership card to make sure it is valid. The Librarian looks up the member’s records and checks for any due fines and that the number of loaned books will be less than 6 (the maximum). The Librarian refuses to loan books to members with overdue fines. If acceptable, each book is stamped with the appropriate return date (2 weeks from today). The Librarian updates the member’s loan details by entering it into the loan library.

9 .Use Cases: ATM Use Case Diagrams 9 Withdraw Cash Request Balance Request Statement Request Cheques ATM Use cases Withdraw Cash Benefit: - User goes home with cash money Interaction: - User identifies him/herself - Requests amount - System checks balance and limits - If valid, dispenses cash, debits account - Asks user if would like receipt Effects: - User’s account balance updated - ATM’s available cash updated By Richard001 (Own work) [Public domain], via Wikimedia Commons

10 .Use Cases: ATM Use Case Diagrams 10 Use-Case: Withdraw Cash The user inserts their ID card into the system. The system reads the card’s chip to identify the user & account . The system prompts the user to enter their PIN . The user enters their PIN. The system contacts the banks central computer to verify the PIN account details. If PIN is authenticated the user is prompted for the amount of the withdrawal. If not, the card is returned to the user with an appropriate failed identification message. The system prompts for the amount of the cash withdrawal. The user enters the amount of the cash withdrawal. The system checks with the banks central computer to ensure that the user has sufficient funds. If there are sufficient funds, the cash is dispensed and the customer’s account at the Bank Central Computer is debited accordingly, otherwise an appropriate “ insufficient funds ” message is displayed The card is returned to the user and a receipt is printed.

11 .Use Cases Use Case Diagrams 11 What to write and how much detail is necessary? There are no explicit rules or syntax. It must capture everything the system should do, otherwise the feature may be missed. Capture all the interactions you expect will be played out, the benefits to the user or actor, and the effect it has on the system. Should focus on the “ what’s ”, not the “how’s”, i.e. should not go into the underlying details required to get the functionality to work.

12 .Use Case Scenarios Use Case Diagrams 12 Specific instance of a use case that is played out. What could happen? What do we do in that case? What if the users PIN is incorrectly entered? What if the user has insufficient funds in their account? What if the cash dispenser cannot read the? What if the cash dispenser is out of money? What if the bank central computer is off-line? ATM: Each scenario addresses one of path of interation , but are all part of the same Use Case. They are not errors , since they may reflect important logic or business operation.

13 .Use Case Scenarios Use Case Diagrams 13 Often documented using structured pseudo-code , but keep it simple , unambiguous and clear to others. Start of Primary scenario/transaction The user inserts their ID card into the system. The system reads the magnetic strip from the card. If the system cannot read the card then << Scenario 1 >> The system contacts the banks central computer to request the PIN number for the card and their account details. If bank central computer cannot access users account then << Scenario 2 >> The system prompts the user for their PIN. The user enters their PIN. If PIN cannot be authenticated << Scenario 3 >> The user is prompted for the amount of the withdrawal. The user enters the amount of withdrawal. The system checks with the banks central computer If the user has insufficient funds << Scenario 4 >> The cash is dispensed and the customer’s account at the Bank Central Computer is debited with the withdrawal amount. The card is returned to the user and a receipt issued . End-Of-Transaction Scenario 1: The users card is returned. End-of-Transaction Scenario 2: The users card is returned. End-of-Transaction Scenario 3: The user is given two more attempts to enter a correct PIN. If this fails the card is kept and the transaction ends. Otherwise resume primary scenario. Scenario 4: The user is given the opportunity to enter a lesser amount or cancel the transaction. If cancel is chosen, the card is returned and the transaction ends. If the lesser amount is acceptable then resume primary scenario.

14 .Use Case Diagrams Use Case Diagrams 14 Very simple diagram involving two symbols: “actors” and “use-cases”. ATM Use-Case Diagram Withdraw Cash

15 .Use Case Diagrams Use Case Diagrams 15 Each oval represents a unique use-case, with a high-level label. All use-cases must be initiated by an actor. Use cases are documented elsewhere, with a detailed description of the interactions. Use Case

16 .Use Case Diagrams Use Case Diagrams 16 An actor is an external entity we are modelling. They could be users, other systems, hardware, etc. They initiate one or more use-cases. Not all people (or entities) involved in execution is an actor. Actors must initiate a use-case and gets some measureable benefit from the interaction, not just someone/something that happens to be involved.

17 .Use Case Diagrams Use Case Diagrams 17 Withdraw Cash We may show other actors that are involved if it is important to the use-case . In UML, we refer to “actors” who do not initiate a use-case as a secondary actor . The initiator is the primary actor .

18 .Use Case Diagrams Use Case Diagrams 18 Withdraw Cash There may be multiple primary actors in your system. e.g. the Bank’s Central Computer requests all transactions be uploaded, or a technician runs a diagnostics check

19 .Use Case Diagrams Use Case Diagrams 19 Why bother with such simple diagrams? They show the big-picture without getting bogged down by the details of design and implementation Focuses on what needs to be done, useful for organizing tasks Useful for communicating with customer, relating use-cases to major objectives Helps reduce missed or misunderstood features or functionality during analysis Developers can immediately asses required functionality , asses risks and identify any potential challenges

20 .Use Case Diagrams: Includes Use Case Diagrams 20 Sometimes commonality exists between steps, e.g. each operation at an ATM requires an identification step using a bank card and pin. Rather than duplicate the common interaction within each use-case, we extract into a “mini use-case” which can be included in the others. THIS IS NOT BREAKING DOWN INTO FUNCTIONS! The included mini use-case should still involve some interaction between actor and system, with benefits and effects . Ask: is this important from a big-picture perspective, or only an implementation detail?

21 .Use Case Diagrams: Includes Use Case Diagrams 21 Customer Verify User with Main Computer Get Balance of Account <<include>> <<include>> <<include>> NOT really Use-cases If a use-case does not contain any user-interaction OR , does not lead to any direct, measurable benefit for the user, then it is NOT a use-case, it is simply functionality.

22 .Documenting Includes Use Case Diagrams 22 Start of Primary scenario/transaction Include Identify User (a prerequisite or precondition for the execution of this use-case) If identification fails << Scenario 1 >> The system contacts the banks central computer to request the PIN number for the card and their account details. If bank central computer cannot access users account <<Scenario 2>> If PIN cannot be authenticated <<Scenario 3>> The user is prompted for the amount of the withdrawal. The user enters the amount of withdrawal. The system checks the account balance with the banks central computer If the user has insufficient funds <<Scenario 4>> The cash is dispensed and the customer’s account at the Bank Central Computer is debited with the withdrawal amount. The card is returned to the user and a receipt issued . End-Of-Transaction Scenario 1: The users card is returned. End of Transaction Scenario 2: The users card is returned. End of Transaction Scenario 3: The user is given two more attempts to enter a correct PIN. If this fails the card is kept and the transaction ends. Otherwise resume primary scenario. Scenario 4: The user is given the opportunity to enter a lesser amount or cancel the transaction. If cancel is chosen, the card is returned and the transaction ends. If the lesser amount is acceptable then resume primary scenario.

23 .Use Case Diagrams: Generalzation Use Case Diagrams 23 When two or more use-cases achieve the same goal . e.g. Unlocking an iphone: passcode, OR fingerprint, OR face recognition . The outcome/benefits are the same, but interaction is different. ‘Finger Print Scan’, ‘Retina Scan’ and ‘Card and Pin’ are all ‘kinds of’ use case that identify the user Withdraw Cash

24 .Use Case Diagrams: Generalization Use Case Diagrams 24 base use-case derived use-cases The base (or root) use-case should be documented in very general terms. “ Identify the user ” obtain their account details from the bank central computer The details are then described in the derived use-cases. Generization is about isolating common objectives and expressing that commonality in the use-base case.

25 .Use Case Diagrams: Extends Use Case Diagrams 25 Allow for extensions of use-cases. Model optional behaviour involving user-or actor- interaction . Customer Request Cash <<extends>> Receipt Needed? Choose $$$ Notes <<extends>> Use-Case Request Cash . . . . . . If( users wants to chose type of $ notes) Extend use case : Choose $$$ Notes If user chooses to have a receipt Extend use case : Print Receipt . . . . . . The card is returned to the user and a receipt is issued . End-Of-Transaction

26 .Use Case Diagrams: Summary Use Case Diagrams 26 User stories are used to develop and analyze the list of functional requirements Use-Cases describe the details of the interactions , can include multiple scenarios leading to different interaction procedures. Descriptions do not have a specific syntax, but must capture requirements in a way that analysists and customers can understand . Use-Cases can include other use-cases, can sometimes be generalized – having multiple derived use-cases, and can extend other use-cases adding optional interactions. Note the arrow types in the diagrams!! Both the style and direction .