Object-Oriented Software Engineering

Using UML, Patterns, and Java

Chapter 2,
Modeling with UML, Part 2
Outline of this Class

• What is UML?
• A more detailed view on
 Use case diagrams
 Class diagrams
 Sequence diagrams
 Activity diagrams

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
2
 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://
http://www.ivarjacobson.com www.booch.com/
UML Basic Notation: First Summary

• UML provides a wide variety of notations for

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

• Now we go into a little bit more detail…

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
4
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
5
 UML Use Case Diagrams
Used during requirements elicitation and
TicketSystem
analysis to represent external behavior
(“visible from the outside of the system”)
An Actor represents a role, that is, a
Passenger type of user of the system
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 functionality
of the system.
PurchaseTicket

what is being described? (system),

who is using the system? (actors)
what do the actors want to achieve? (use cases),
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
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
Description
• Examples:
• 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
7
 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
• The textual use case description
consists of 6 parts:
PurchaseTicket
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
8
Textual Use Case
Description Example PurchaseTicket
Passenger

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

1. Passenger selects the
number of zones to be
2. Participating actor:
traveled
Passenger
2. Ticket Distributor displays
the amount due
3. Entry condition: 3. Passenger inserts
• Passenger stands in front money, at least the
amount due
of ticket distributor
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
9
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
10
 The <<extends>> Relationship
• <<extends>> relationships
model exceptional or seldom
invoked cases
• The exceptional event flows
Passenger are factored out of the main
event flow for clarity
• The direction of an
<<extends>> relationship is to
PurchaseTicket 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
11
 The <<includes>> Relationship
• <<includes>> relationship
represents common
functionality needed in more
than one use case
Passenger
• <<includes>> behavior is
factored out for reuse, not
PurchaseMultiCard because it is an exception
• The direction of a
PurchaseSingleTicket
<<includes>> relationship is
<<includes>>
to the using use case (unlike
<<includes>> the direction of the
<<extends>> relationship).

CollectMoney
<<extends>>
<<extends>>

NoChange Cancel
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
Use Case Models can be packaged
Classifier (System Boundary)
Use Case

Actor.

System boundary

TUTORIAL VIDEO: Use Case Analysis using Visual Paradigm -

https://www.youtube.com/watch?v=KeMgPqLCkuo
Lesson-1
Bernd Brueggeto
& Lesson-5
Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
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: Price
Price getPrice(Zone)

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
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
16
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
• 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
17
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 phenomenon

• 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
18
Associations

TarifSchedule TripLeg

Enumeration getZones() Price

* * Zone
Price getPrice(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
19
1-to-1 and 1-to-many Associations

Country 1 1 City

name:String name:String

1-to-1 association

3..* 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
20
 Many-to-many Associations

StockExchange * * Company
Lists tickerSymbol

• A stock exchange lists many companies.

• Each company is identified by a ticker symbol

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
Examples of Multiplicity

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
22
From a Simple Problem Statement To Class
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
23
From Scenario To Class Diagram

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
24
Class Diagram for Warehouse on Fire Scenario

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
25
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
26
 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
27
 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 own (“the whole controls/destroys the
parts”) TicketMachine

3
ZoneButton
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
28
Aggregation Examles

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
29
Aggregation vs Association

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
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
31
Inheritance & Associations Together

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
32
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
33
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
34
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
35
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
36
Object Modeling in Practice: Associations

Account

? * Amount
AccountId * owns
Customer
Bank has CustomerId
AccountId
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
37
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
38
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
39
Practice Object Modeling: Simplify, Organize
Account
Bank Customer

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

Use the 7+-2 heuristics

or better 5+-2!

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

• Used during analysis

TicketMachine • To refine use case descriptions
Passenger

selectZone() • to find additional objects

(“participating objects”)
• Used during system design
TicketMachine
• to refine subsystem interfaces
insertCoins()
zone2price Messages ->
• Instances are represented by
selectZone()
rectangles. Actors Operations
by sticky on
insertCoins()
figures participating Objec
pickupChange()
pickupChange() • Lifelines are represented by
pickUpTicket()
dashed lines
• Messages are represented by
pickUpTicket()
arrows
• Activations are represented
by narrow rectangles.
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
41
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
42
 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
43
 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
44
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
45
Outline of this Class

• What is UML?
• A more detailed view on
 Use case diagrams
 Class diagrams
 Sequence diagrams
 Activity diagrams

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
46
UML 2 Activity Diagrams

• An activity diagram consists of nodes and edges

• There are three types of activity nodes
• Control nodes
• Executable nodes
• Most prominent: Action
• Object nodes
• E.g. a document
• An edge is a directed connection between nodes
• There are two types of edges
• Control flow edges
• Object flow edges

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
47
 Example: Simple Acitivity Diagram for Incident

• Activity diagrams are hierarchical:

• an activity is made out of either an action or a graph of
subactivities and their associated object flow.

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
48
Example: Open Incident – Control Nodes

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
49
Example: Open Incident – Fork & Join

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
50
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
51
Control Nodes in an Activity Diagram

• Initial node
• Final node
• Activity final node
• Flow final node
• Fork node
• Join node
• Merge node
• Decision node

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
52
Activity Diagram Example
Fork Join Merge
node node node
Initial
node

Final
node

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
53
Example of a Activity Diagram with a Frame

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
54
The Activity Diagram without Frame

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
55
Activity Diagram: Activity Nodes & Edges

• An activity diagram consists of nodes and edges

• There are three types of activity nodes
Control nodes
• Executable nodes
• Most prominent: Action
• Object nodes
• E.g. a document
• An edge is a directed connection between nodes
• There are two types of edges
• Control flow edges
• Object flow edges

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
56
Action Nodes and Object Nodes

• Action Node
Action
Name

• Object Node
Object
Name

Write Review
Thesis Thesis Thesis

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

Action
Object
node

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

Control
flow

Object
flow

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
59
 Summary: Activity Diagram Example
Fork Join Merge
node node node
Initial
node

Control
flow Final
node

Action
Object
node Object
flow

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
60
State Chart Diagrams vs Activity Diagrams
• An activity diagram that contains only activities
can be seen as a special case of a state chart
diagram
• Such an activity diagram is useful to describe the
overall workflow of a system

Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
61
Statechart Diagram vs Activity 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 dataflow in a system)

Completion of activity
causes state transition Triggerless
transition
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
62
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
63
Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java
64