UML for Use Cases, Jan 4/5 2006 Introduction to UML and Use Case Diagrams Richard Hopkins [e-mail] NeSC Training Team Member

1
UML for Use Cases, Jan 4/5 2006Introduction to
UMLandUse Case DiagramsRichard Hopkins
rph_at_nesc.ac.ukNeSC Training Team Member
2
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

3
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

4
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 90s)
• Grady Boochs OOD Object-Oriented Design
• James Rumbaughs OMT Object-oriented Modelling
  and Design
• Ivar Jacobsons OOSE Object-Oriented Software
  Engineering
• Competing Methodologies
• Rather improbably
• Rumbaugh joined Booch, with intention of merging
  their methods
• They bought out Jacobsonns company Objectory
• These three aimed for a single Unified Method

5
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 Xs notation
• with methodology appropriate to context
• Strong reasons for using the same notation
• Concept of Unified Method, changed to Unified
  Modelling Language

6
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 -

7
An Overall Development Process
e.g example scenarios
Partially articulated requirements
Capture Requirements
Use Case Diag.
Requirements

Construct Model of Overall system
Class Diag.
Structure

Behaviour

• These diagram types, and the process can be used
  both for
• Designing a new system
• Understanding an existing system

8
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

9
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

10
Simple Use Cases
Update Catalogue
BookBorrower
Librarian

• 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
11
Use Case Documentation
Use Case Documentation

• Use Case Borrow copy of book.
• Summary
• Actors BookBorrower
• Stakeholders .
• The bookBorrower presents a book.
• 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.

Borrow Copy of book
BookBorrower
Update Catalogue
Librarian

• Not a very rich diagram
• Needs more explanation associated documentation
• Our previous Use Case description could be
  anything

12
Just a list of Use Cases?
BookBorrower

• Likely to be commonality between these Use Cases
• Counter-productive to repeat the common steps
• Have relationships between Use Cases
• Extension
• Inclusion
• Specialisation

13
Use Case Relationships (A)
show clerk sometimes involved, sometimes
not system might record which clerk
Return Copy
Clerk
Book Returner
Notify lost Copy
ltltextendgtgt an interuption of the indicated
base case
ltltincludegtgt
ltltincludegtgt
Pay fine
Defer fine
ltltextendgtgt
Note Participant Inheritance BookReturner
Clerk implicitly involved in Return Overdue
Copy Pay Fine needs to be specific about
participants
ltltincludegtgt allows common sub-structure to be
factored out.
Pay fine by credit card
Generalisation /Specialisation a special case
of. Everything that happens in the general case
also happens in the special case
14
Specialisation vs Extension
Specialisation vs Extension Distinction not
clear-cut (some say UML should not have
both) For extension base case can document the
conditions for the extension case (extension
point) One possible decider - Generalisation
is when user unilaterally chooses a
variant Extension is when system detects the
condition, or needs to check whether it is OK
testing internal system state
Return Copy
ltltextendgtgt
Return Overdue Copy
ltltincludegtgt
Pay fine
Defer fine
ltltextendgtgt
Pay fine by credit card
15
Use Case - Variants
Library
Reserve book personally
Book Reserver
Clerk
Show system boundary With system
name Particularly when A sub-system of A larger
model
Book Reserver
Reserve Book electronically
Reserve Book
Authenticate User
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
16
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

17
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 object-oriented design
• Keep focus on requirements documentation
• Include what is important for understanding
  system functionality

18
Questions
19
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

20
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 Groups 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

21
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