1. Introduction to UML
Use Case Diagrams

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

3. What is UML? Unified Modelling Language3
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?

4. Useful material There are many good books on UML, such as4
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 are also a lot of websites with suitable materials, such as
Tools for UML
ArgoUML, argouml.tigris.org
Commercial software, e.g. Microsoft Visio & IBM Rational Rose
A list of open-source & free UML editors:

5. Structural modelling diagrams
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

6. Behavioural modelling diagrams
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

7. Use case diagrams Use Cases: When to use?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. 

8. 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

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

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

11. 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

12. Use Case
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
PurchaseTicket

13. Scenarios
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

14. Textual description for the ‘Borrow’ use case
USE CASE: Borrow
GOAL: To borrow a library book
ACTORS: Borrower, System
Main Success Scenario:
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:
3a. Borrower already has borrowed maximum number of books
The loan cannot happen

15. 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

16. 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 .
Potential exceptions:
the credit card authorization might fail…
Other extensions:
a regular customer doesn't need to input shipping & credit card info… 16

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

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

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

20. 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 CD
borrow book
borrower
Borrower : books and CDs
Borrower : books only

21. 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

22. A Simplified Automatic Teller Machine
The ATM is associated with only one bank
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 transaction

23. A Simplified Automatic Teller Machine (cont. 1)
The card contains
an ID number
an expiration date
a secret code
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
Keyboard and screen, with menus
The customer may cancel the current transaction at meaningful points

24. A Simplified Automatic Teller Machine (cont. 2)
The connections with the bank are kept to a minimum
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
From time to time an employee manually
empties the machine and/or fills it with bank notes
supplies consumables and does any maintenance that may be needed

25. 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…

26. Identifying System Boundaries Identifying Actors
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!

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

28. 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

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

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

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

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

33. 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

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

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

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

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

38. Note Don’t get too involved with the diagrams
The textual description is more important.
You will see slight variations in the use of use cases
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

39. 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.

40. An example of application of Object-Oriented Analysis and Design40