UML (Use Case and

Activity Diagrams)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

 What is UML?

 Unified Modeling Language

• OMG Standard, Object Management Group
• Based on work from Booch, Rumbaugh, Jacobson
 UML is a modeling language to express and
design documents, software
• Particularly useful for OO design
• Not a process, but some have been proposed
using UML
• Independent of implementation language

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 2

 Why use UML?
 Open Standard, Graphical notation for
• Specifying, visualizing, constructing, and documenting
software systems
 Language can be used from general initial design to
very specific detailed design across the entire
software development lifecycle
 Increase understanding/communication of product to
customers and developers
 Support for diverse application areas
 Support for UML in many software packages today
(e.g. Rational, plugins for popular IDE’s like NetBeans,
Eclipse, ArgoUML, etc.)
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 3
 Brief History of UML
 Inundated with methodologies in early 90’s
 Booch, Jacobson, Yourden, Rumbaugh
 Booch, Jacobson merged methods 1994
 Rumbaugh joined 1995
 1997 UML 1.1 from OMG includes input from
others, e.g. Yourden
 UML v2.0 current version

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 4

 Systems, Models and Views
 A model is an abstraction describing a subset of a
system
 A view depicts selected aspects of a model
 A notation is a set of graphical or textual rules
for depicting views
 Views and models of a single system may overlap
each other
 Examples:
• System: Aircraft
• Models: Flight simulator, scale model
• Views: All blueprints, electrical wiring, fuel system
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 5
 UML Models, Views, Diagrams
 UML is a multi-diagrammatic language
• Each diagram is a view into a model
• Diagram presented from the aspect of a particular
stakeholder
• Provides a partial representation of the system
• Is semantically consistent with other views

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 6

 UML Models, Views, Diagrams

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 7

 Use Cases

 What is a Use Case

 A formal way of representing how a
business system interacts with its
environment
 Illustrates the activities that are
performed by the users of the system
 A scenario-based technique in the UML
 A sequence of actions a system performs that
yields a valuable result for a particular actor.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 8

Use Case Symbols

Use Case
 Actor

Boundary

 Connection

Include relationship
<<include>>

Extend relationship

<<extend>>

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 9

 Use Case Analysis

 What is an Actor?
• A user or outside system that interacts
with the system being designed in order to
obtain some value from that interaction
 Use Cases describe scenarios that describe
the interaction between users of the system
(the actor) and the system itself.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 10

 Actors

 An Actor is outside or external the

system.
 It can be a:
• Human
• Peripheral device (hardware)
• External system or subsystem
• Time or time-based event
 Represented by stick figure

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 11

 Questions for Identifying People
Actors
 Who is interested in the scenario/system?
 Where in the organization is the
scenario/system be used?
 Who will benefit from the use of the
scenario/system?
 Who will supply the scenario/system with this
information, use this information, and remove
this information?
 Does one person play several different roles?
 Do several people play the same role?
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 12
 Use Cases
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
PurchaseTicket
 Entry conditions
 Flow of events
 Exit conditions
 Special requirements
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 13
 Use Cases

 Use case diagrams describe what a system

does from the standpoint of an external
observer. The emphasis is on what a system
does rather than how.

 Use case diagrams are closely connected to

scenarios.
 A scenario is an example of what happens
when someone interacts with the system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 14

 Use Case Diagram: Example
 Name: Purchase ticket  Event flow:
 Participating actor: 1. Passenger selects the
Passenger number of zones to be
traveled.
Entry condition:
2. Distributor displays


• Passenger standing in the amount due.

front of ticket
3. Passenger inserts
distributor.
money, of at least the
• Passenger has sufficient
amount due.
money to purchase
ticket. 4. Distributor returns
change.
 Exit condition:
5. Distributor issues
• Passenger has ticket.
©Ian Sommerville 2004 ticket.
Software Engineering, 7th edition. Chapter 4 Slide 15
 Use Case Components
 The use case has three components.
 The use case task referred to as the use case
that represents a feature needed in a
software system.
 The actor(s) who trigger the use case to
activate.
 The communication line to show how the actors
communicate with the use case.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 16

 Use-Case Diagram: Example

A use case diagram is a collection of actors, use cases, and

their communications. Software Engineering, 7th edition. Chapter 4
©Ian Sommerville 2004 Slide 17
 Use Case Diagram

 Other Types of Relationships for Use

Cases

• Generalization
• Include
• Extend

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 18

 Components of Use Case Diagram

 Generalization Relationship
• Represented by a line and a hollow arrow
• From child to parent

Child use case Parent use case

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 19

 Use Case Diagram

 Include Relationship
• Represents the inclusion of the
functionality of one use case within
another
• Arrow is drawn from the base use case to
the used use case
• Write << include >> above arrowhead line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 20

 Use Case Diagram

 Extend relationship
• Represents the extension of the use
case to include optional functionality
• Arrow is drawn from the extension use
case to the base use case
• Write << extend >> above arrowhead
line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 21

 Example of Relationships

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 22

 Use Case Template
Use Case ID:
Use Case Name:
Created By: Last Updated By:
Date Created: Date Last Updated:

Actor:
Description:
Preconditions:
Postconditions:
Priority:
Frequency of Use:
Normal Course of Events:
Alternative Courses:
Exceptions:
Includes:
Special Requirements:
Assumptions:
Notes and Issues:
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 23
 Use Case for ATM system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 24

 Activity Diagram

 Activity Diagrams consist of activities, states

and transitions between activities and states
 Activity Diagrams describe
• how activities are coordinated to provide a
service
• the events needed to achieve some operation
• how the events in a single use case relate to one
another
• how a collection of use cases coordinate to create
a workflow for an organization
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 25
 Activity Diagram Vs Use Case Diagram
 Use case diagrams are useful at very early phase of
product development where requirements collection is
in progress,
 It is required to identify different use cases and
establish the relation between actors and use cases.
 Activity diagrams are used in much later stage of
product development where it is required to
represent flow of activities involved in a
process/scenario.
 Where an activity is a particular operation of the
system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 26

 Activity Diagram Vs Use Case Diagram
 The purpose of activity diagram is similar to flow
chart, but activity diagrams are much more richer in
syntax than flow chart.
 Use case diagram looks at the system being developed
as a BLACK BOX and addresses WHAT the system
does and how it interacts with OUTSIDE
systems/actors.
 The activity diagram looks at the system being
developed as a WHITE BOX,
 and addresses HOW the system does the things
described in the use case diagram and shows how the
elements INSIDE the system interact with each
other as well as with the external systems/actors.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 27
 Activity Diagram
 Model business workflows
 Identify candidate use cases, through the
examination of business workflows
 Identify pre- and post-conditions for use
cases
 Model workflows between/within use cases
 Model complex workflows in operations on
objects
 Model in detail complex activities in a high
level activity diagram
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 28
 Notation

2. Transition

Activity1()c Activity2()

1. Activities

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 29

 Notation - 2

[x>0]
[x>0]

Activity1()c
[x=0] [x=0]
[x<0] [x<0]

3. Decision Diamond

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 30

 Notation - 3

4.1 Synch. Bar (Join) 4.2 Splitting Bar (Fork)

{AND}
{OR}
{XOR}

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 31

 Notation - 3

Start Marker Stop Marker

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 32

 Notation - 4

Developers Testers Markers

Swimlane Swimlane Swimlane

Application/Department/Group/Role Boundaries

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 33

 Example: Business Level Activity Diagram of the Library

member Librarian

[borrower]
Find book on shelf

[returning]
[returner]
Wait in queue
[borrowing]

Record return Put book back of shelf

Record borrowing

Prepare for next

member

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 34

 Forking and Joining

 Use a synchronization bar to specify

the forking and joining of parallel flows
of control
 A synchronization bar is rendered as a
thick horizontal or vertical line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 35

 Fork
 A fork may have one incoming transitions and
two or more outgoing transitions
• each transition represents an independent
flow of control
• conceptually, the activities of each of
outgoing transitions are concurrent
• either truly concurrent (multiple nodes)
• or sequential yet interleaved (one node)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 36

 Join

 A join may have two or more incoming

transitions and one outgoing transition
• above the join, the activities associated with
each of these paths continues in parallel
• at the join, the concurrent flows synchronize
• each waits until all incoming flows have reached
the join, at which point one flow of control
continues on below the join

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 37

 Fork

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 38

 Activity Diagram:

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 39

 Swimlanes
 A swimlane specifies a locus of activities
 To partition the activity states on an activity
diagram into groups
• each group representing the business
organization responsible for those activities
• each group is called a swimlane
 Each swimlane is divided from its neighbor by a
vertical solid line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 40

 Swimlanes
 Each swimlane has a name unique within its
diagram
 Each swimlane may represent some real-
world entity
 Each swimlane may be implemented by one or
more classes
 Every activity belongs to exactly one
swimlane, but transitions may cross lanes

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 41

 Activity Diagram

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 42