Object-Oriented Software Engineering

Using UML, Patterns, and Java

Chapter 2,

DIAGRAMS
Modeling with UML
Overview: modeling with UML

• What is modeling?
• What is UML?
• Use case diagrams
• Class diagrams

Next step:
• Sequence diagrams
• Activity diagrams

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2
Application and Solution Domain

• Application Domain (Requirements Analysis):

• The environment in which the system is operating

• Solution Domain (System Design, Object

Design):
• The available technologies to build the system

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4
We use Models to describe Software
Systems
• System model: Object model + functional
model + dynamic model

• Object model: What is the structure of the system?

• UML Notation: Class diagrams
• Functional model: What are the functions of the system?
• UML Notation: Use case diagrams
• Dynamic model: How does the system react to external
events?
• UML Notation: Sequence, State chart and Activity diagrams

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5
Overview of UML Diagrams
Behavioral
Structural
: behavioral features of a system / business
process
: element of spec. irrespective of time
• Activity
• State machine
• Class
• Use case
• Component
• Interaction
• Deployment
• Object
• Composite structure
Interaction
: emphasize object interaction
• Package
• Communication(collabe
ration)
• Sequence
• Interaction overview
• Timing
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6
Another view on UML Diagrams

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7
Outline of the Diagrams

• Use case diagrams

• Describe the functional behavior of the system as seen
by the user
• Class diagrams
• Describe the static structure of the system: Objects,
attributes, associations
• Sequence diagrams
• Describe the dynamic behavior between objects of the
system
• Statechart diagrams
• Describe the dynamic behavior of an individual object
• Activity diagrams
• Describe the dynamic behavior of a system, in
particular the workflow.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9
 What is UML? Unified Modeling Language
• Convergence of different notations used in object-
oriented methods, mainly
• OMT (James Rumbaugh and collegues), OOSE (Ivar
Jacobson), Booch (Grady Booch)
• They also developed the Rational Unified Process,
which became the Unified Process in 1999

Developed the
Booch method
25 year at GE Research, At Ericsson until 1994, (“clouds”), ACM
where he developed OMT, developed use cases and the Fellow 1995, and
joined (IBM) Rational in CASE tool Objectory, at IBM IBM Fellow 2003
1994, CASE tool OMTool Rational since 1995, http://www.booch.
http://www.ivarjacobson.com com/
 UML
• Generic standard for modeling systems
• Current Version: UML 2.5.1
• Information at the OMG portal http://www.uml.org/
• Commercial tools:
• Rational (IBM),Together (Borland), Visual Architect (Visual
Paradigm), Enterprise Architect (Sparx Systems)
• Open Source tools http://www.sourceforge.net/
• ArgoUML, StarUML, Umbrello (for KDE), PoseidonUML
• Example of research tools: Unicase, Sysiphus
• Based on a unified project model for modeling,
collaboration and project organization
• http://unicase.org
• http://sysiphus.in.tum.de/

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12
UML: First Pass

• You can solve 80% of the modeling problems by

using 20 % UML
• We teach you those 20%
• 80-20 rule: Pareto principle

Vilfredo Pareto, 1848-1923

Introduced the concept of Pareto
Efficiency,
Founder of the field of microeconomics.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13
UML First Pass (covered in Last Lecture)
• Use case diagrams
• Describe the functional behavior of the system as seen
by the user
• Class diagrams
• Describe the static structure of the system: Objects,
attributes, associations
• Sequence diagrams
• Describe the dynamic behavior between objects of the
system
• Statechart diagrams
• Describe the dynamic behavior of an individual object
• Activity diagrams
• Describe the dynamic behavior of a system, in
particular the workflow.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14
UML Basic Notation: First Summary

• UML provides a wide variety of notations for

modeling many aspects of software systems
• In the first lecture we concentrated on:
• Functional model: Use case diagram
• Object model: Class diagram
• Dynamic model: Sequence diagrams, statechart

• Now we go into a little bit more detail…

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15
 STATIC UML MODELS

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16
 UML
USE CASE DIAGRAM

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17
UML Use Case Diagrams
Used during requirements elicitation
and analysis to represent external
behavior (“visible from the outside of
the system”)
An Actor represents a role, that
is, a type of user of the system
Passenger
A use case represents a class of
functionality provided by the system

Use case model:

The set of all use cases that
PurchaseTicket completely describe the
functionality of the system.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18
Use cases diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 19
Actors
• An actor is a model for an external
entity which interacts
(communicates) with the system:
• User
• External system (Another system)
• Physical environment (e.g. Weather)

Passenger • An actor has a unique name and an

optional description Optional
• Examples: Description

• Passenger: A person in the train

Name • GPS satellite: An external system that
provides the system with GPS
coordinates.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 20
 Use Case
• A use case represents a class of
functionality provided by the
system
• Use cases can be described
textually, with a focus on the
event flow between actor and
system
PurchaseTicket • The textual use case description
consists of 6 parts:
1. Unique name
2. Participating actors
3. Entry conditions
4. Exit conditions
5. Flow of events
6. Special requirements.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 21
Textual Use Case
Description Example PurchaseTicket
Passenger

1. Name: Purchase ticket 5. Flow of events:

1. Passenger selects the
2. Participating actor: number of zones to be
traveled
Passenger
2. Ticket Distributor displays
the amount due
3. Entry condition: 3. Passenger inserts
• Passenger stands in front money, at least the
of ticket distributor amount due
4. Ticket Distributor returns
• Passenger has sufficient change
money to purchase ticket
5. Ticket Distributor issues
ticket
4. Exit condition: 6. Special requirements:
• Passenger has ticket None.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 22
Review of Use Case Diagrams:
3 Important Terms
Used during requirements elicitation and
analysis to represent behavior visible from
the outside of the system
An actor represents a role, that
is, a type of user of the system
Student A use case represents a class of
functionality provided by the system

Use case model:

The set of all use cases that
completely describe the
DoHomework functionality of the system.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 23
Actor
• An actor is a model for an external
entity which interacts with the
system:
• EndUser, Administrator
• External system (Another system)
• Physical environment (e.g. Weather)
• An actor has a unique name and an
optional description
Student Optional
• Examples: Description
• Student: A studying person
• Teaching Assistant: Member of
teaching staff who supports the
Name instructor.
• Random Number generator

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 24
Use Case
• A use case represents a class of
functionality provided by the
system
• Use cases can be described
textually, with a focus on the
event flow between actor and
system
DoHomework • The textual use case description
consists of 6 parts:
1. Unique name
2. Participating actors
3. Entry conditions
4. Exit conditions
5. Flow of events
6. Special requirements.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 25
Textual Use Case
Description Example Student

1. Name: DoHomework 5. Flow of events: DoHomework

1. Student fetches the
2. Participating actor: exercise sheet
Student 2. Student reads through
the assignments
3. Student processes the
3. Entry condition: assignments and types
• Student received exercise the solution in his
sheet Computer.
4. Student prints out the
• Student is in good health solution
5. Student delivers the
4. Exit condition: solution in the following
exercise
• Student delivered solution
6. Special requirements:
None.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 26
Use Case Model
Classifier
Use Case

Actor.

System boundary

Use case diagrams represent the functionality of the system

from user’s point of view
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 27
Uses Cases can be related

• Extends Relationship
• To represent seldom invoked use cases or exceptional
functionality

• Includes Relationship
• To represent functional behavior common to more than
one use case.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 28
 The <<extends>> Relationship
• <<extends>> relationships
model exceptional or seldom
invoked cases
• The exceptional event flows
Passenger are separated from the main
event flow for clarity
• The direction of an
<<extends>> relationship is
PurchaseTicket towards the extended use case
• Use cases representing
<<extends>> exceptional flows can extend
more than one use case.
<<extends>>
<<extends>>
OutOfOrder <<extends>> TimeOut

Cancel NoChange
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 29
 The <<includes>> Relationship

• <<includes>> relationship
represents common
functionality needed in more
than one use case
Passenger
• <<includes>> behavior is
separated for reuse, not
PurchaseMultiCard because it is an exception
PurchaseSingleTicket
• The direction of a
<<includes>> relationship is
<<includes>>
to the using use case (unlike
<<includes>> the direction of the
<<extends>> relationship).

CollectMoney
<<extends>> <<extends>>
<<extends>>

NoChange Cancel Cancel

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 30
 The <<extend>> Relationship
• <<extend>> relationships
model exceptional or seldom
invoked cases
• The exceptional event flows
Student are factored out of the main
event flow for clarity
• The direction of an
<<extend>> relationship is to
DoHomework the extended use case
• Use cases representing
<<extend>> exceptional flows can extend
more than one use case.
<<extend>>
<<extend>>
FetchLostSheet <<extend>> Party

DrinkCoffee Sleep
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 31
The <<include>> Relationship

• <<include>> relationship
represents common
DoHomework functionality needed in more
than one use case
Student
• <<include>> behavior is
factored out for reuse, not
HoldExercise because it is an exception
GiveLecture • The direction of a
<<include>> relationship is
<<include>>
to the using use case (unlike
<<include>> the direction of the
<<extend>> relationship).

AskQuestion
<<extend>> <<extend>>
<<extend>>

NoAnswer WrongAnswer SillyQuestion

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 32
Use cases diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 33
Use cases diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 34
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 35
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 36
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 37
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 38
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 39
Use Case Diagrams: Summary -short

• Use case diagrams represent external

behavior

• Use case diagrams are useful as an index into

the use cases

• Use case descriptions provide meat of model,

not the use case diagrams.

• All use cases need to be described for the model

to be useful.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 40
 UML
COMPONENT DIAGRAM

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 41
Component Diagram

• A component diagram displays the structural

relationship of components of a software
system.
• These are mostly used when working with
complex systems with many components.
• Components communicate with each other using
interfaces.
• The interfaces are linked using connectors.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 42
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 43
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 44
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 45
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 46
 UML
CLASS DIAGRAM

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 47
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 48
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 49
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 50
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 51
Class Diagrams

• Class diagrams represent the structure of the

system
• Used
• during requirements analysis to model application
domain concepts
• during system design to model subsystems
• during object design to specify the detailed behavior
and attributes of classes.

TarifSchedule Trip
Table zone2price
zone:Zone
Enumeration getZones()
Price getPrice(Zone)
* * Price: Price

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 52
Classes Type
TarifSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)

TarifSchedule
zone2price Attributes Signature
getZones()
getPrice()
Operations TarifSchedule

• A class represents a concept

• A class encapsulates state (attributes) and behavior
(operations)
Each attribute has a type
Each operation has a signature

The class name is the only mandatory information

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 53
Instances

tarif2006:TarifSchedule :TarifSchedule
zone2price = { zone2price = {
{‘1’, 0.20}, {‘1’, 0.20},
{‘2’, 0.40}, {‘2’, 0.40},
{‘3’, 0.60}} {‘3’, 0.60}}

• An instance represents a real world object

• The attributes are represented with their values
• The name of an instance is underlined
• The name can contain only the class name of the instance
(anonymous instance)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 54
Actor vs Class vs Object

• Actor
• An entity outside the system to be modeled, interacting
with the system (“Passenger”)
• Class
• An abstraction modeling an entity in the application or
solution domain
• The class is part of the system model (“User”, “Ticket
distributor”, “Server”)
• Object (instance)
• A specific instance of a class (“Joe, the passenger who
is purchasing a ticket from the ticket distributor”).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 55
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 56
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 57
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 58
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 59
Associations

TarifSchedule TripLeg

Enumeration getZones() Price

Price getPrice(Zone)
* * Zone

Associations denote relationships between classes

The multiplicity of an association end denotes how many

objects the instance of a class can legitimately reference.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 60
1-to-1 and 1-to-many Associations

Country 1 1 City

name:String name:String

1-to-1 association

Point
Polygon
* x: Integer

y: Integer
draw()

1-to-many association
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 61
Many-to-Many Associations

Company

StockExchange * * tickerSymbol

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 62
From Problem Statement To Object Model

Problem Statement: A stock exchange lists many companies.

Each company is uniquely identified by a ticker symbol

Class Diagram:

StockExchange * * Company
Lists
tickerSymbol

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 63
From Problem Statement to Code
Problem Statement : A stock exchange lists many companies.
Each company is identified by a ticker symbol

Class Diagram:
StockExchange * * Company
Lists tickerSymbol

Java Code
public class StockExchange
{
private Vector m_Company = new Vector();
Associations
};
are mapped to
public class Company
{ Attributes!
public int m_tickerSymbol;
private Vector m_StockExchange = new Vector();
};
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 64
 Aggregation
• An aggregation is a special case of association denoting a
“consists-of” hierarchy
Exhaust system
• The aggregate is the parent class,
the components are the children classes

1 0..2

Muffler Tailpipe
diameter diameter

A solid diamond denotes composition: A strong form of

aggregation where the life time of the component instances
is controlled by the aggregate. That is, the parts don’t exist
on their won (“the whole controls/destroys the parts”)
TicketMachine

3
ZoneButton
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 65
Part-of Hierarchy (Aggregation)
Computer

I/O Devices CPU Memory

Cache ALU Program

Counter

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 66
 Qualifiers

Without qualification
1 * File
Directory
filename

With qualification
1 0..1
Directory filename File

• Qualifiers can be used to reduce the multiplicity

of an association

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 67
Qualification: Another Example

Company

StockExchange * Lists
* tickerSymbol

StockExchange
*
tickerSymbol
Lists
*
1 Company

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 68
Inheritance

Button

CancelButton ZoneButton

• Inheritance is another special case of an

association denoting a “kind-of” hierarchy
• Inheritance simplifies the analysis model by
introducing a taxonomy
• The children classes inherit the attributes and
operations of the parent class.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 69
Packages
• Packages help you to organize UML models to
increase their readability
• We can use the UML package mechanism to
organize classes into subsystems

Account

Bank Customer

• Any complex system can be decomposed into

subsystems, where each subsystem is modeled as
a package.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 70
Object Modeling in Practice

Foo

Amount
CustomerId

Deposit()
Withdraw()
GetBalance()

Class Identification: Name of Class, Attributes and Methods

Is Foo the right name?

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 71
Object Modeling in Practice: Brainstorming

“Dada” Foo

Amount Amount
CustomerId CustomerId

Deposit() Deposit()
Withdraw() Withdraw()
GetBalance() GetBalance()
Account

Amount
CustomerId
Deposit()
Withdraw()
Is Foo the right name? GetBalance()

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 72
Object Modeling in Practice: More classes

Account

Amount Customer
Bank AccountId
CustomerId
Name
Name Deposit() CustomerId
Withdraw()
GetBalance()

1) Find New Classes

2) Review Names, Attributes and Methods

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 73
Object Modeling in Practice: Associations

Account

? * Amount
AccountId * Customer
Bank has CustomerId
AccountId owns
Name
Deposit() 2
Name CustomerId
Withdraw()
GetBalance()

1) Find New Classes

2) Review Names, Attributes and Methods
3) Find Associations between Classes
4) Label the generic assocations
5) Determine the multiplicity of the assocations
6) Review associations
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 74
Practice Object Modeling: Find Taxonomies
Account
Bank Customer

Name
* Amount * Has Name
AccountId
CustomerId
AccountId
Deposit()
Withdraw()
GetBalance() CustomerId()

Savings Checking Mortgage

Account Account Account

Withdraw() Withdraw() Withdraw()

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 75
Practice Object Modeling: Simplify,
Organize
Account

Amount Show Taxonomies

AccountId
CustomerId
AccountId
separately
Deposit()
Withdraw()
GetBalance()

Savings Checking Mortgage

Account Account Account

Withdraw() Withdraw() Withdraw()

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 76
Practice Object Modeling: Simplify,
Organize
Account
Bank Customer

Name
* Amount * Has Name
AccountId
CustomerId
AccountId
Deposit()
Withdraw()
GetBalance() CustomerId()

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 77
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 78
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 79
 DYNAMIC UML MODELS

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 80
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 81
 UML
SEQUENCE DIAGRAM

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 82
 Sequence diagram: Basic Notation
Lifeline

Execution
Specification

Message

Sequence diagrams represent the behavior of a system

as messages (“interactions”) between different objects.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 83
Lifeline and Execution Specification

• A lifeline represents an individual participant

(or object) in the interaction
• A lifeline is shown using a symbol that consists
of a rectangle forming its “head” followed by a
vertical line (which may be dashed) that
represents the lifetime of the participant
• An execution specification specifies a
behavior or interaction within the lifeline
• An execution specification is represented as a
thin rectangle on the lifeline.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 84
Messages

• Define a particular communication between

lifelines of an interaction
• Examples of communication
• raising a signal
• invoking an operation
• creating or destroying an instance
• Specify (implicitly) sender and receiver are
shown as a line from the sender to the receiver
• Form of line and arrowhead reflect message
properties

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 85
Message Types

• Asynchronous
• Synchronous
• Call and Object creation
• Reply
• Lost
• Found

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 86
Sequence Diagrams Focus on
Controlflow

• Used during analysis

TicketMachine
Passenger • To refine use case descriptions
selectZone() • to find additional objects
(“participating objects”)
• Used during system design
• to refine subsystem interfaces
TicketMachine
insertCoins() zone2price
• Instances are represented
Messages ->by
selectZone()
rectangles. ActorsOperations
by stickyon
insertCoins()
figures participating Object
pickupChange()
pickupChange() • Lifelines are represented by
pickUpTicket()
dashed lines
• Messages are represented by
arrows
pickUpTicket()
• Activations are represented
by narrow rectangles.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 87
Sequence Diagrams can also model the
Flow of Data

ZoneButton TarifSchedule Display

Passenger

selectZone()
lookupPrice(selection)

price
displayPrice(price)
Dataflow
…continued on next slide...

• The source of an arrow indicates the activation which sent

the message
• Horizontal dashed arrows indicate data flow, for example
return results from a message

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 88
 Sequence Diagrams: Iteration & Condition
…continued from previous slide...

ChangeProcessor CoinIdentifier Display CoinDrop

Passenger

*insertChange(coin) lookupCoin(coin)

price
Iteration displayPrice(owedAmount)

[owedAmount<0] returnChange(-owedAmount)
Condition
…continued on next slide...

• Iteration is denoted by a * preceding the message name

• Condition is denoted by boolean expression in [ ] before
the message name

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 89
 Creation and destruction
…continued from previous slide...

ChangeProcessor
Passenger
Creation of Ticket
createTicket(selection)

Ticket
print()

free()
Destruction of Ticket

• Creation is denoted by a message arrow pointing to the object

• Destruction is denoted by an X mark at the end of the
destruction activation
• In garbage collection environments, destruction can be used to
denote the end of the useful life of an object.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 90
Sequence Diagram Properties

• UML sequence diagram represent behavior in

terms of interactions
• Useful to identify or find missing objects
• Time consuming to build, but worth the
investment
• Complement the class diagrams (which
represent structure).

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 91
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 92
 UML
ACTIVITY DIAGRAM

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 93
Activity Diagrams
• An activity diagram is a special case of a state
chart diagram
• The states are activities (“functions”)
• An activity diagram is useful to depict the
workflow in a system

Handle Document Archive

Incident Incident Incident

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 94
Activity Diagrams allow to model Decisions
Decision

[lowPriority]
Open Allocate
Incident Resources

[fire & highPriority]

[not fire & highPriority]

Notify
Fire Chief

Notify
Police Chief

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 95
Activity Diagrams can model Concurrency

• Synchronization of multiple activities

• Splitting the flow of control into multiple threads

Allocate
Splitting Resources Synchronization

Open Coordinate Archive

Incident Resources Incident

Document
Incident

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 96
Activity Diagrams: Grouping of Activities

• Activities may be grouped into swimlanes to

denote the object or subsystem that implements
the activities.

Allocate Dispatcher
Resources

Open Coordinate Archive

Incident Resources Incident

FieldOfficer
Document
Incident

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 97
 Activity Diagram vs. Statechart Diagram
Statechart Diagram for Incident
Focus on the set of attributes of a single abstraction (object, system)
Event causes
state transition

Active Inactive Closed Archived

Incident- Incident- Incident-
Handled Documented Archived

Activity Diagram for Incident

(Focus on workflow in a system)

Handle Document Archive

Incident Incident Incident

Triggerless
Completion of activity transition
causes state transition
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 98
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 99
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 100
 UML
STATE CHART DIAGRAM

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 101
 UML Statechart diagram
Event Initial state
button1&2Pressed button2Pressed
Blink Increment
Hours Hours

Transition button1Pressed

button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes
State
button1Pressed

button2Pressed
Stop Blink Increment
Blinking Seconds Seconds

Final state
Represents behavior of a single object with interesting
dynamic behavior.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 102
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 103
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 104
UML Summary

• UML provides a wide variety of notations for

representing many aspects of software
development
• Powerful, but complex
• UML is a programming language
• Can be misused to generate unreadable models
• Can be misunderstood when using too many exotic
features
• We concentrated on a few notations:
• Functional model: Use case diagram
• Object model: class diagram
• Dynamic model: sequence diagrams, statechart and
activity diagrams

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 105
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 106