UML for Use Cases, Jan 4/5 2006
Introduction to UML
and
Use Case Diagrams
Richard Hopkins
rph@nesc.ac.uk
NeSC Training Team Member
Goals and Overview
Goals –
To explain the context and overall approach
for UML and its Use Case diagrams
Overview
UML History and concepts
Use Case Diagrams
Practical
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
2
History of UML
Use of diagrams
In any discipline for the construction of complex artefacts
Need to use diagrams, as tools for
 Thinking
 Communicating
As discipline matures, diagrams become  Standardised –
For effective communication between all practitioners
 Stylized –
Specialised technical language for compact representation
UML – M is for Models
A diagram is a model of the (proposed) system
A partial representation of some aspect of the system
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
3
History of UML
Historically
A variety of stylised diagram languages
Each associated with a design methodology

A formalised Process for arriving at a design
E.g., for Object-oriented design (early 90’s)



Grady Booch’s OOD – Object-Oriented Design
James Rumbaugh’s OMT – Object-oriented Modelling and
Design
Ivar Jacobson’s OOSE – Object-Oriented Software
Engineering
Competing Methodologies
Rather improbably –

Rumbaugh joined Booch, with intention of merging their
methods

They bought out Jacobsonn’s company – Objectory

These three aimed for a single Unified Method
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
4
Methodology vs Notation
Generally need different methodologies for different
contexts
Small application in four weeks by single programmer
Large system in four years by 200-strong
development organisation
Often “use of X methodology” was actually
use of “X’s” notation
with methodology appropriate to context
Strong reasons for using the same notation
Concept of Unified Method, changed to Unified Modelling
Language
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
5
Methodology vs Notation
UML is NOT a methodology
UML is a notation for recording the results of
A requirements gathering / design process
Carried out using some methodology – maybe!
Any kind of diagram can be used for any purpose that is
useful
Sufficiently general that could be used with any
imaginable O-O methodology
A typical Methodology -
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
6
An Overall Development Process
Partially articulated
requirements
e.g example
scenarios
Capture
Requirements
…
Use Case Diag.
Requirements
Sequence Diag.
Construct
Model of
Overall system
Class Diag.
Sequence Diag.
Structure
… Behaviour
These diagram types, and the process can be used both for
Designing a new system
Understanding an existing system
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
7
Goals and Overview
Goals –
To explain the context and overall approach
for UML and its Use Case diagrams
Overview
UML History and concepts
Use Case Diagrams
Practical
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
8
Introducing the Library Example
A computer system for a university library;
The purposes include
Keeping track of when items are borrowed/returned
Allowing users to search for an item and check availability
The library has two kinds of members –
Staff
Students
The library contains two kinds of items Books


possibly several copies of each book
Some books are for short-term loan only –
only students can do short-term loans
Journals

Only staff may borrow journals
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
9
Simple Use Cases
Borrow Copy
of book
Return Copy
Update
Catalogue
BookBorrower
Librarian
Notify Lost
Copy
An Actor –
a user of the system, in a particular role
“BookBorrower” is a role played by library members
Usually a person, but could be another system
An entity outside the system being modelled
A Use Case –
An example of the behaviour of the system – more
general than our previous formulation
“Borrow Copy of Book” describes the successful outcome
– there will be variants for the exception cases This Actor participates in this Use Case
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
10
Use Case Documentation
Use Case Documentation
Borrow Copy
of book
Use Case: Borrow copy of book.
Summary: …
Actors: BookBorrower …
Stakeholders: ….
Return Copy
• The bookBorrower presents a book.
Notify Lost
Copy
BookBorrower
Update
Catalogue
Librarian
• The system validates that the potential
borrower is a member of the library,
• The system validates that s/he does not
already have the maximum permitted number
of books on loan. ( The maximum is 6 unless
the member is a staff member, in which case it
is 12.)
• The system records that this library member
has this copy of the book on loan.
Not a very rich diagram
Needs more explanation – associated documentation
Our previous Use Case description – could be anything
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
11
Just a list of Use Cases?
Borrow Copy
Notify Lost Copy
Notify Lost Copy,
paying fine
by credit card
Notify Lost Copy,
deferring fine
BookBorrower
Return Copy
Return Overdue Copy
Return Overdue
copy, paying fine
by credit card
Return
Overdue Copy,
deferring fine
Likely to be commonality between these Use Cases
Counter-productive to repeat the common steps
Have relationships between Use Cases
Extension
Inclusion
Specialisation
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
12
Use Case Relationships (A)
Return Copy
Clerk
Book
Returner
<<extend>>
Notify lost
Copy
Return Overdue
<<include>> Copy
<<include>>
Pay fine
<<extend>>
Defer fine
Note – Participant
Inheritance
BookReturner & Clerk
implicitly involved in
Return Overdue Copy
Pay Fine needs to be
specific about
participants
UML for Use Cases, 4/5 Jan 2006
Pay fine by
credit card
show clerk –
sometimes involved,
sometimes not
system might record
which clerk
<<extend>>
– an “interuption”
of the indicated
base case
<<include>>
– allows common
sub-structure to
be factored out.
Generalisation /Specialisation– a special case of.
Everything that happens in the general case also
happens in the special case
UML Intro & Use Case Diagrams
13
Specialisation vs Extension
Specialisation vs Extension
Return Copy
Distinction not clear-cut
(some say UML should not have both)
<<extend>>
Return Overdue
<<include>> Copy
For extension base case can document the
conditions for the extension case
(“extension point”)
One possible decider -
Pay fine
<<extend>>
Defer fine
Generalisation is when user unilaterally
chooses a variant
Pay fine by
credit card
UML for Use Cases, 4/5 Jan 2006
Extension is when system detects the
condition, or needs to check whether it is OK
– testing internal system state
UML Intro & Use Case Diagrams
14
Use Case - Variants
Library
Reserve book
personally
Book
Reserver
Book
Reserver
Clerk
Reserve
Book
electronically
Reserve
Book
Authenticate
User
Show system boundary
With system name
Particularly when
A sub-system of
A larger model
The actor can be another system (a class) –
In this case a library enquiry and reservation system
Which is modelled as a separate system
Electronic vs Personal reservation have different requirements
E.g. user authentication is inside vs outside the system
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
15
Use Case Diagrams - Usage
Identification of Actors and functionalities
Requirements feed-back
To communicate to the clients what the providers have
understood a being the requirements
DANGER –
 generalisations, extensions and inclusions
 make the diagrams too complex and technical for the clients to
understand properly
Test Case generation
Do Design Walk-throughs (sequence diagrams) of all Use
Cases
Implementation tests for all Use Cases
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
16
Use Case Diagrams - Usage
Identification of Actors and functionalities
Requirements feed-back
Test Case generation
To drive the system design (not a good use!)
Producing one module of code for each use case.
 Leads to top down, function-oriented system
 Loses the maintainability and flexibility benefits of objectoriented design
Keep focus on requirements documentation
Include what is important for understanding system
functionality
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
17
Questions
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
18
Goals and Overview
Goals –
To explain the context and overall approach
for UML and its Use Case diagrams
Overview
UML History and concepts
Use Case Diagrams
Practical
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
19
Practical –
Use Case Elaboration
Objective – to arrive a Use Case diagram for a collection of Use
Cases which employ the relationships
 Generalisation / Inclusion / Extension
and have the potential for communication between several
actors (systems)
Can use as any combination of
Your Use Case from previous practical
?? Another Group’s Use Case from previous practical ??
One or more of the Use Cases provided
 organised into sets of related Use Cases
Invented variants to illustrate the relationships
1. Choosing base Use Case(s) for rest of practicals
30 mins in total, e.g.
15 mins – look at provided use case
15 mins – decide which one(s) to use
make a second choice
report to me which you are doing
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
20
Practical –
Use Case Elaboration
2. Individually Draw A, using either
Word document template
Visual Paradigm for UML
10 mins
3. Use Case Structures
90 mins in total
Work out alternatives to the chosen base Use Case(s)
Structure them using the extends etc. relationships
Draw the Use Case diagram
Document each use case variant –
 using VP-UML notes or separate documents – up to you
4. Swap – look at two other groups’ outputs
45 mins
UML for Use Cases, 4/5 Jan 2006
UML Intro & Use Case Diagrams
21