Introduction to UML Use Case Diagrams Today we

Introduction to UML Use Case Diagrams

Today we will cover Unified Modelling Language (UML) Use Case Diagram

What is UML? 3 Unified Modelling Language A language for specifying, visualising & constructing the descriptive diagrams and documentation of software systems Industry standard for object-oriented modelling Helps in designing and describing software systems Communicate & understand ideas “A picture is worth 1000 words”, We’re aiming for a well-designed, robust & maintainable object-oriented system which meets the users’ requirements What does the user require? Which classes should there be? What responsibilities should each class have? How should objects interact?

Useful material 4 There are many good books on UML, such as “Teach Yourself UML in 24 hours” by Joseph Schmuller Stevens P. with Pooley, R. (2000) Using UML: Software Engineering with Objects and Components, Addison. Wesley, Harlow, Essex, UK “UML Distilled Third Edition” by Martin Fowler There also a lot of websites with suitable materials, such as http: //bdn. borland. com/article/0, 1410, 31863, 00. html http: //www. agilemodeling. com/essays/uml. Diagrams. htm Tools for UML Argo. UML, argouml. tigris. org Commercial software, e. g. Microsoft Visio & IBM Rational Rose A list of open-source & free UML editors:

UML Diagrams 5 Structural modelling diagrams Class diagrams Describe the static structure of the system: Objects, Attributes, and Associations. Object diagram Describe a set of objects and their relationships Component diagram Describe the various components in a system and their dependencies Deployment diagram Shows the physical relationships among software and hardware components in the delivered system

UML Diagrams Behavioural modelling diagrams Use Case diagrams Describe the functional behavior of the system as seen by the user. Sequence diagrams Describe the dynamic behavior between actors and the system and between objects of the system State Machine Diagrams Show system states and events that cause transition from one state to another

Use case diagrams 7 Use Cases: Technique for capturing functional requirements of a system Describe typical interactions between users of a system and the system itself When to use? Use cases are used in almost every project. They are helpful in exposing requirements During the initial stage of a project most use cases should be defined, but as the project continues more might become visible.

Use case diagrams A scenario is a sequence of steps describing an interaction between a user and a system Scenarios model the goal of the user (an actor) An actor is a role that a user plays with respect to the system A use case is a set of scenarios tied together by a common user goal

Use case diagram for library join reserve book borrower borrow book return book add stock librarian remove stock Here’s an example of a use case diagram showing the use cases for a library

Use case diagram notation ACTOR SYSTEM BOUNDARY LINK borrower borrow book USE CASE

Actors An actor indicates a role played by an external person or system which is involved in a use case The same person or system may play the role of more than one actor, depending on the context E. g. maybe a librarian is also a borrower An actor may be involved in more than one use case Actors initiate and/or respond to use cases e. g. Sales representative logs call Driver starts car Alarm system alerts duty officer Timer triggers email

Use Case Purchase. Ticket 12 A use case represents a class of functionality provided by the system as an event flow. A use case consists of: Unique name Participating actors Pre-conditions Entry conditions (triggers) Flow of events Exit conditions (success ‘guarantees’) Special requirements

Scenarios 13 A Scenario is a sequence of steps describing an interaction between a user and a system Each use case is likely to have several scenarios The ideal or “happy” scenario is when the process works as normal E. g. money is withdrawn from ATM book is borrowed from library “Unhappy” scenarios, or “extensions” are when things don’t go so well. E. g. wrong pin number entered member has maximum number of books out already

Textual description for the ‘Borrow’ use case USE CASE: Borrow GOAL: To borrow a library book ACTORS: Borrower, System Main Success Scenario: 1. 2. 3. 4. 5. Provide card with membership bar code Provide book with bar code System checks membership System records loan to borrower for 3 weeks Borrower leaves with the book Extensions: 3 a. Borrower already has borrowed maximum number of books 1. 14 The loan cannot happen

Notes on the description The borrower is the actor that initiates the loan The inputs to the use case are identified The book code, the membership code The outcomes are identified The borrower leaves with the book, the loan is recorded in the system The exceptions are identified & alternative outcomes are given The borrower already has 6 books out : loan refused This use case is adequate for the users to agree that it is accurate, without becoming a design The cheapest place to sort out errors in the requirements is at this stage 15

One more example A Web-based on-line store Buy a Product scenario: The customer browses the catalog and adds desired items to the shopping basket. When the customer wishes to pay, the customer describes the shipping and credit card information and confirms the sale. The system checks the authorization on the credit card and confirms the sale both immediately and with a follow-up e-mail. Potential exceptions: the credit card authorization might fail… Other extensions: a regular customer doesn't need to input shipping & credit card info… 16

USE CASE: Buy a Product GOAL: To buy a product ACTORS: Customer, System Main Success Scenario: 1. Customer browses catalogue and selects items to buy 2. Customer goes to check out 3. Customer fills in shipping information (address; next-day special delivery, or 1 st class delivery) 4. System presents full pricing information, including shipping 5. Customer fills in credit card information 6. System authorises purchase 7. Systems confirms sale immediately 8. System sends confirmation e-mail to customer Extensions: 3 a. Customer is regular customer 1. System displays current shipping, pricing and billing information 2. Customer may accept or override these defaults, returns to MSS at step 6 6 a. System fails to authorise credit card purchase 1. Customer may re-enter credit card information, or may cancel There is no standard way to write the content of a use case 17

Use cases : include (used to be ‘uses’) Some use cases may share one or more common steps Reserve book <<includes>> Check membership borrower <<includes>> Borrow book 18

Use cases : extend An extension is a significant exception to the normal case Borrowing refused borrower <<extend>> borrow book 19

Use cases: generalisation Actors and use cases can be generalised, showing that one is simply a special case of the other This is like inheritance in object-oriented design Suppose that to borrow a CD, users must have additional registration and pay per CD. borrow book Borrower : books only borrower borrow CD Borrower : books and CDs 20

ATM Requirements Capture A simplified Automatic Teller Machine Which requirements are to be captured? The activities in Requirement capture Identification of system boundaries: actors and use cases Diagramming use cases Elaborating scenarios Diagramming scenarios

A Simplified Automatic Teller Machine The ATM is associated with only one bank 22 It gives access to all the accounts the customer owns in the bank Several types of transactions can be chained in a single session Withdrawal, deposit, transfer between the customer’s own accounts, consulting an account The customer may obtain a printed receipt for each

A Simplified Automatic Teller Machine (cont. 1) The card contains The card must be verified by the ATM The customer cannot make more than 3 attempts to enter the correct code, otherwise the card is swallowed Interface 23 an ID number an expiration date a secret code Keyboard and screen, with menus The customer may cancel the current transaction at meaningful points

A Simplified Automatic Teller Machine (cont. 2) The connections with the bank are kept to a minimum From time to time an employee manually 24 When a session is opened, a connection makes it possible to known all the accounts the customer owns Every night, the information about the current day transactions are transferred to the bank empties the machine and/or fills it with bank notes supplies consumables and does any maintenance that may be needed

Which requirements are to be captured? Functional requirements Modeled as Use Cases Non functional requirements Some are specific to one use case Some relate to technical issues addressed by implementation diagrams and models Other in some supplementary documents, out of the UML scope…

Identifying System Boundaries Identifying Actors are anything which interact with the system People, other systems, hardware, software, networks… They are roles, not necessarily full-fledged objects Actors are not part of the system They are just at the boundary (external to the system) They won’t produce code!

Identifying System Boundaries Identifying Actors (cont. ) ATM example Customer using the teller machine Bank Maintenance technician Customer Bank Technician

Identifying System Boundaries Identifying Use Cases Use cases describe the services the system must perform from the point of view of the actors Functional description From a usage point of view

Diagramming Use Cases Top Level Use Case Diagram system boundary Handle Session Customer Bank Transfer Daily Maintain Technician 29

Diagramming Use Cases Stereotyped Dependencies « include » Verify Card Handle Session « include » Authenticate Customer « include » Get Customer Information 30 Handle Transaction « extend » Deliver Receipt

Diagramming Use Cases Stereotyped Dependencies « include » The included use case is a mandatory part of the including one Included « include » Including « extend » The extending use case is an optional part of the extended one (functionality-wise, not actor-wise) Extending « extend » Extended

Diagramming Use Cases Generalization Handle Transaction Handle Deposit Handle Consult 32 Handle Withdrawal Handle Transfer

Elaborating scenarios Use Case and Scenarios Use cases classify the ways of using the system To each use case correspond many possible usage scenarios Thus scenarios are instances of use cases specify use cases Each use case has generally a primary scenario, possibly several (a few) several secondary (more exceptional) scenarios

Elaborating Scenarios for Use Cases Use Case: Handle Session Precondition: the ATM is free Primary Scenario 1. The Customer inserts the card into the ATM. 2. The ATM verifies the card validity. 3. The Customer authenticates with the ATM. 4. The ATM gets the Customer information from the Bank. 5. The Customer selects a transaction. 6. The Customer quits. 7. The ATM ejects the card. Postcondition: the ATM is free 34 Handle Session « include » Verify Card « include » Handle Transaction « include » Authenticate Customer Get Customer Information

Elaborating Scenarios for Use Cases Alistair Cockburn’s style (2) Use Case: Handle Session Precondition: the ATM is free Primary Scenario 1. The Customer inserts the card into the ATM. 2. The ATM verifies the card validity. 3. The Customer authenticates with the ATM. 4. The ATM gets the Customer information from the Bank. 5. The Customer selects a transaction. 6. The Customer quits. 7. The ATM ejects the card. Postcondition: the ATM is free 35 Variants 2 a The card is invalid; the ATM swallows it; this ends the session. 3 a The Customer fails to authenticate; the ATM swallows the card; this ends the session. 4 a The connection with the Bank is impossible or interrupted; the ATM ejects the card; this ends the session. 5 a The Customer may quit immediately. 6 a The Customer chooses to perform another transaction; goto step 5. * The Customer may cancel the session; the ATM ejects the card.

Elaborating scenarios Primary Scenario 36 Use Case: Handle Session Scenario: Primary (typical) 5. Precondition: the ATM is free 1. The scenario starts when the customer inserts the card 2. The card is accepted 3. The customer enters the secret code correctly 4. The ATM gets the customer information from the bank 6. The customer performs a transaction When the transaction is finished, the customer may ask for another transaction (go to 5) or quit 7. The scenario is finished when the customer decides to quit; the card is ejected Postcondition: the ATM is free

Elaborating scenarios Example of Secondary Scenarios Use Case: Handle Session Scenario: Secondary (customer interrupt) Precondition: the ATM is free 1. The scenario starts when the customer inserts the card 2. The card is accepted 3. The customer enters the secret code correctly 4. The customer cancel the session 37 The card is ejected and the scenario is finished Postcondition: the ATM is free 5.

Note Don’t get too involved with the diagrams You will see slight variations in the use of use cases The textual description is more important. due to different use and versions of UML There is no one right answer to any question associated with design There is no right or wrong design There can be good or bad design

Exercise Draw a use case diagram for a voting machine, on which voters can see a list of candidates and select one to vote for. The machine should check that each voter is eligible to vote. The electoral registrar will also want to print a summary of the total votes for each candidate. The electoral registrar will also want to see a list of voters who have voted and a list of those who haven’t. in case of a dispute, the machine should also list a complete record of who voted for whom, but only a judge can use this function.

An example of application of Object-Oriented Analysis and Design 40 http: //www. cs. gordon. edu/courses/cs 211/ATMExample/index. ht ml