OO/UML 1

The world is filled with Knowledge;

it is almost empty of Understanding.
- Louis Sullivan, Chicago architect

Object-Oriented Analysis and

Design with UML
Dr. O.S. van Roosmalen
Object-Oriented Software Engineering
Training and Consultancy
O.S.vanRoosmalen@chello.nl

December, 2001
OO/UML 2

Contents

• Part 1: Introduction to Object Orientation

• Part 2: UML Overview
• Part 3: Modeling with UML
– Class Modeling
– Use-Case modeling
– Object-Interaction modeling
– Object-Behavior modeling
• Part 4: Small Workshop
OO/UML 3

Part 2

UML Overview

December, 2001
OO/UML 4

UML

This is how the UML developers see their brain child:

"The Unified Modeling Language (UML) provides

system architects working on object analysis and design
with one consistent language for specifying,
visualizing, constructing,
constructing and documenting the artifacts
of software systems,
systems as well as for business modeling."
OO/UML 5

UML Diagrams
User-System Logical structure
interaction State
State
Diagrams
Object interaction Class
Diagrams
Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
Diagrams
Sequence Diagrams
Diagrams
Diagrams

Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams Models Component
Diagrams
Diagrams Diagrams

Implementation
Scenario Component structure
Scenario
Diagrams
Component
Diagrams
Deployment
Activity
Diagrams Diagrams
Diagrams Diagrams
Statechart
Diagrams
Dynamic
DynamicView
View Static View
Object behavior
OO/UML 6

4+1 Views
Concepts Topology
Relations Usage Distribution
Behavior Delivery

Logical View Deployment View

Use Case View

Process View Component View

Performance Packaging
Scalability Versioning
Throughput Assembly
OO/UML 7

Contents
• UML History
• UML Diagrams
• UML Language Specification
OO/UML 8

Part 3

Modeling with UML

December, 2001
OO/UML 9

Contents

• Class and Object modeling

• Use-Case modeling
• Object-Interaction modeling
• Object-Behavior modeling
• Finishing an analysis
OO/UML 10

Contents

• Class and Object modeling

– Software modeling perspective
– Domain analysis perspective
OO/UML 11

Contents

• Class and Object modeling

– Software modeling perspective
– Domain analysis perspective
• Purpose of analysis
• Object modeling
OO/UML 12

The Object-Oriented Paradigm

• Object-oriented modeling is a way of decomposing problems

• A system is viewed as a collection of loosely connected
entities, called objects.
• Each object is responsible for performing specific tasks.
• Objects can request services (tasks) from each other.
• System behavior emerges from the chaining of such service
requests.
• Each object has structure and behavior
• Every object is an instance of some class (i.e. type). The
behavior of an object is dictated by this class.
• All instances of a class will behave in a sufficiently similar
fashion in response to a similar request.
OO/UML 13

Class Modeling steps

• Identify classes of objects in the problem domain
– Find nouns in the problem description
– Extract class candidates
– Identify actors (from Use Cases)
• Identify relations between these classes
– First model the aggregation hierarchies
– Begin with the root class (system to be realized)
– Identify relevant parts of this system
– Identify interesting associations
• Give meaningful names to associations
– Identify specializations/generalizations
OO/UML 14

Overview of the lift system

The software-controlled lift system consists of 8 lifts and shafts for a hospital building of ten floors. At each floor
(except the top and bottom floors) there are two buttons for requesting lifts, one for going up and one for going down.
These are called Lift Request Buttons. Requests can be serviced by any of the eight lifts. Once pressed, the Lift
Request Buttons are lit at the back to indicate that a request is pending. When a lift arrives to service the request the
button light is switched off and a chime signal is produced to indicate availability of the lift. The Lift Request Buttons
are enabled for new lift-requests when the button light is off. If the button is pressed when a lift cage is at a floor and
the doors are not completely closed, the chime will sound, the doors will open again and the door closure time is
reset (see the paragraph about opening and closing doors).

Each lift cage contains a set of buttons corresponding to the available floors. These are called Floor Request
Buttons. Once pressed the Floor Request Buttons will be back-lit to indicate that a request is pending. When the lift
arrives at a floor for which a request is pending, the back light of the corresponding button is switched off, the chime
inside the cage sounds and the doors open. Again the Floor Request Buttons are enabled for receiving new requests
when the back light is off.

Each lift cage has two sliding half doors that match two sliding half doors for that shaft at each floor. At a particular
floor these doors will open and close simultaneously, the floor doors being coupled to the cage doors by mechanical
means. When the doors open a closure timeout period starts. When this period expires the doors start closing. If an
obstruction is detected in the doorway after expiration of the timeout period, the doors open completely and the
closure timeout period is restarted. The lift cage can only start its motor and move to another floor when doors are
completely closed. In each cage there are two extra buttons for opening and closing the doors. The button for
opening the door will cause the doors to open but only when the lift is still at a floor and has not started moving. The
door closure timeout period is reset. Pressing the close button will have the same effect as ending the door closure
timeout period. The doors start to close but open again if an obstruction is detected.

The floor requests and lift requests are serviced in a way that guarantees optimal transportation of people. Since the
criteria for optimal control may change depending on circumstances the allocation of lifts to requests must flexible
and adaptive
OO/UML 15

Classification of Nouns
Problem related nouns General Actors
lift system signal obstruction
lift paragraph people
shaft means
building period
floor
motor control
button expiration
lift request buttons circumstance
floor request buttons allocation
close button
open button
button light (back light)
chime
cage door
floor door
closure time
request
floor requests
lift requests
OO/UML 16

Aggregations
Building

1
LiftSystem

10
8
Floor
floorNumber : int Shaft

8 1 Motor
FloorDoor CageDoor LiftCage
raise()
lower()

LiftRequestButton 10 2 1
pressed : boolean
DoorDetector FloorRequestButton DoorButton Chime

sound()

1 1
ButtonLight

on()
off()
OO/UML 17

Associations
Building

RequestLiftUp 0..1 1
LiftSystem
RequestLiftDown
0..1
10
*
Floor 8

floorNumber : int Shaft

*
RequestToServiceFloor
*

8 * 1 Motor
FloorDoor Door CageDoor LiftCage
raise()
1 1
Door lower()

2 open()
close()
LiftRequestButton
10 2 1
pressed : boolean
FloorRequestButton DoorButton Chime
DoorDetector
sound()

1 1
ButtonLight

on()
off()
OO/UML 18

Contents

• Class and Object modeling

• Use-Case modeling
OO/UML 19

Purpose of Use-Case modeling

• Through Use-Case modeling basic needs of an actor are identified and it is
described how these needs are satisfied by the system.
– Who are the users of the system: Actors
– Why do they use the system
– How is each actor interacting with the system: the Use Cases

• The Use Cases describe the functions to be performed by the system from the
perspective of certain actors

• The Use-Cases capture the requirements and help to trace the realization of the
requirements during development
OO/UML 20

Actor
• An actor is a role played by an object outside of a system that interacts directly
with the system
• A single object may play several roles and therefore be represented by several
actor symbols in the model
• Actors either actively or passively participate in one or more Use-Cases

Staff Visitor
OO/UML 21

Use Case

• A Use-Case is the description of the interaction between an actor and a system

that helps to fulfil an actors needs
• A Use-case is a step-by-step description of the interaction between an actor and
a system to yield one specific result (out of many),
• The description can be formal or informal
• The Use Case descriptions are used to communicate with the Stakeholders of
the system. They serve as a contract between the Stakeholders.

ChangeFloor
OO/UML 22

Describe the Use Case

• Define normal flow of events

– How and when the use case begins and ends (including which actor initiates it)
– When the use case will interact with the actors and what is exchanged with them
– How and when the use case will need data stored in the system, or will store data in
the system
• Exceptional events
– Are there any exceptional events that may start an alternative flow of events
• Pre-conditions
– Describes the conditions that must be met before the use case can start
• Post-conditions
– Defines the main conditions that are fulfilled at the end of the flow of events defined in
this use case
OO/UML 23

Use-Case Description (RUP Template)

Document Sections
1. Use Case Name
1.1 Brief Description

2. Flow of Events
2.1 Basic Flow
2.2 Alternative Flows
2.3 Exceptional Flows

3. Special Requirements [Non-functional requirements]

3.1 < First special requirement >

4. Pre-Conditions
4.1 < Pre-condition One >

5. Post-Conditions
5.1 < Post-condition One >

6. Extension Points
6.1 <name of extension point>
OO/UML 24

Description of Cockburn’s Template

Use Case
Name: <the name should be the goal as a short active verb phrase>
Context of use: <a longer statement of the goal, if needed, its normal occurrence conditions>
Scope: <design scope, what system is being considered black-box under design>
Level: <one of: Summary, User-goal, Sub-function>
Primary Actor: <a role name for the primary actor, or description>
Stakeholders & Interests: <list of stakeholders and key interests in the use case>
Precondition: <what we expect is already the state of the world>
Minimal Guarantees: <how the interests are protected under all exits>
Success Guarantees: <the state of the world if goal succeeds>
Trigger: <what starts the use case, may be time event>

Main Success Scenario:

Put here the steps of the scenario from trigger to goal delivery, and any cleanup afterwards.
<step #> <action description>

Extensions
Put here there extensions, one at a time, each referring to the step of the main scenario.
<step altered> <condition>: <action or sub-use case>
<step altered> <condition>: <action or sub-use case>

Technology and Data Variations List

Put here the variations that will cause eventual bifurcation in the scenario.
<step or variation # > <list of variations>
<step or variation # > <list of variations>

Related Information
<whatever your project needs for additional information>
OO/UML 25

Use-Case Description: Example

Main success scenario of “Change Floor”
This Use Case describes the situation in which any person using the hospital lift intends to change from floor k (0 k<N)
to floor m (0m<N, mk).
1 The person pushes a lift-request button: the person is at floor k and requests a lift for going up or down depending
on m>k or m<k.
2 A lift cage Arrives At Floor k: after a while a lift cage with the appropriate direction arrives
2.1 The lift decelerates and stops
2.2 The chime sounds and the button light extinguishes.
2.3 The door opens.
3 The person enters the lift cage possibly together with other persons
4 The person pushes a floor-request button for floor m.
5 Lift cage Departs From Floor k
5.1 The door closes: after a certain amount of time passes, the door closes automatically.
5.2 The lift accelerates until it reaches its normal speed
6 Lift cage Arrives At Floor m
7 User exists the lift cage.
Often, steps 1 and 4 can be omitted because the buttons where already pressed by other actors. Also a lift may
already have arrived when the person arrives. Step 4 can be done any time between steps 3 and 6.
OO/UML 26

Details of Use Case

• A Use-Case description focuses on the view of an actor and not on the ideas
and needs of the (software) engineer.

• A Use Case should be as detailed as needed to understand how the system is

used, i.e. a Use Case does not have to contain all details
– Use Case ChangeFloor does not have to specify how long it will take before the
doors will close again or how fast they close; yet, this needs to be specified
somewhere
• A Use Case only models how the user perceives the system under study, it
should not contain any details of the ‘implementation’
– Use-case model does not specify how are the doors operated, if lights are visible, how
the system knows that it has reached the required floor, etc; but again, also this
needs to be specified somewhere
– The terminology of the user should be sufficient to describe the Use Cases
OO/UML 27

Relationships

• Actors are classes. They have the same relationships as classes

– Specialization/Generalization
– Associations
• Actors are involved in the execution of Use Cases
– This is indicated by associations
– The actor initiates the use case

ChangeFloor
Visitor
– The use case triggers the actor

VerifyCard
Bank
OO/UML 28

Use-Case Relationships
• Use Case are related through dependencies. There are two standard
dependency-stereotypes:
– An include dependency from Use Case A to Use Case B indicates that the Use
Case A refers to and includes the behaviour as specified by B
• This is used to separate often occurring sub-Use-Cases
<<include>>

ChangeFloor ExitLiftCage
– An extend relationship from Use Case A to Use Case B indicates that the Use Case
B may optionally be extended with the behaviour specified by A. The description of B
does not refer to A, A refers to B and indicates at what extension point it is to be
inserted in A
• This is used to separate important optional parts of a Use-Case that are best described
separately
<<extend>>

ExitLiftCage OpenDoor
OO/UML 29

Include
• An include relationship between two Use Cases means that the base Use Case
explicitly incorporates the behavior of another Use-case at a location specified in
the base Use Case
– Used to avoid describing the same flow of events several times
– Used when similar behavior recurs across more than one use case

<<include>>
RequestLiftCage

<<include>>
ChangeFloor

Base use case

EnterLiftCage
Inclusion use case
OO/UML 30

Extend
• An “extend” relation between Use Cases means that the base Use Case may
incorporate the behavior of the extension Use Case at the extension point(s)
defined in the base Use Case but only if the possible condition is fulfilled
– An extension Use-case is not necessarily a separately executable Use Case.

Extension Points
a1 <<extend>>(a1)[condition]

C
Base use case

Extension use case

OO/UML 31

Use-Case Description: Example

Extensions
On sub-Use-Case Arrive At Floor:
2.3a As long as the door is open the person can Request the door to Close.
2.3a.1 Person pressing the close button
2.3a.2 The door starts closing immediately
On sub-Use-Case Depart From Floor:
5.1a As long as the door is closing something may Obstruct the Door.
5.1a.1 The obstruction interacts with the door
5.1a.2 The door opens completely immediately.
5.1b As long as the door is closing the person can Request the door to Open. Pressing the
button, the door starts opening immediately.
5a The lift can make several Intermediate Stops after departure
5a.1 The lift cage Arrives At Floor intermediate between departure and destination floor.
5a.2 Other persons enter the lift cage
5a.3 The lift cage Departs From the intermediate Floor
OO/UML 32

Use-Case Relationships

• Use Cases have also generalization and specialization relationships

– In a more specialized Use Case more specific choices are made for some actions

Pay

Pay Cash Pay with Check

OO/UML 33

Example UCD

system name
actor
use case
actor-use case
communication

use case name

system boundary
OO/UML 34

Part of a Model

Request
<<extend>> Catalog

Place
Order

<<include>>

<<include>>
<<include>>
Arrange
Payment

Supply
Customer Order
Data Product

Pay Arrange
Cash Credit
OO/UML 35

Use-Case Modeling

• Steps:
– Find the actors
– Define the main Use Cases
– Look for sub-Use-Cases
– Find the Use-Case relationships
– Describe each Use Case in a Use-Case Specification document
OO/UML 36

Find the Actors

• Which people or systems are interacting with the system in one way or
another
– Which user employ the system’s most obvious main functions
– Which users employ the secondary functions, such as system maintenance
and administration?

• The Vision document identifies stakeholders and actors.

• Actors are stakeholders, but not all stakeholders are actors

• Example: name some actors for the hospital-lift case

OO/UML 37

Actors in the Lift-Case

• Actor
– Visitor
– Patient
– Staff Person

• Doctor
• Nurse
• Warden
• Lift mechanic

Visitor Patient

Staff
OO/UML 38

Actors and the Vision Document

• Users of the hospital lift system
Name Description Stakeholder
Warden Care taker of the building Hospital principal
Patient Person treated in hospital Hospital principal
Visitor Acquaintance of the patient Hospital principal
Nurse A patients care taker Hospital principal
Doctor Diagnoses and treats the patients Hospital principal
Maintainer Diagnoses and cares for the lift system Maintenance department

• Example user’s profile

Patient
Representative Hospital principal
Description A person being treated in hospital
Type CASUAL USER without any technical background.
Responsibilities As a real patient his wishes with respect to floor movements are entered via a nurse
Success Criteria Painless transportation
Involvement Not involved
Deliverables None
Comments / Issues No problems expected
OO/UML 39

Define Use Cases

• For each Actor that has been identified ask the following questions:
– What are the primary tasks that the Actor wants the system to perform?
– Will the Actor create, store change, remove or read data in the system?
– Will the Actor need to inform the system about sudden, external changes?
– Does the Actor need to be informed about certain occurrences in the
system?
• Name each Use Case in the list and define its scope

• Exercise: name some Use Cases for the hospital-lift case for each
identified actor
OO/UML 40

Make Use-Case Model

• Draw actors and main Use Cases

– Show the direction of the associations between them
• Define sub-Use-Cases with sufficient granularity to see how actors are involved
and what are the major forms of interaction between the actors and the system
• Indicate the relationships
• Check that the model is in accordance with the Use-Case descriptions

• Example: Make a Use-Case model for the lift system

OO/UML 41

Use Case Model: Lift Case

Request Close

<<extend>>

<<include>> <<include>>
Arrive At Floor

<<extend>>

Change Floor Intermediate Stop

Person
<<include>>
<<include>>

Depart From Floor

<<extend>> <<extend>>

Obstruct Door Request Open

OO/UML 42

Review the Use-Case model

• Review the Use-case model against other existing system models:

– Analysis Object model

• Review the Use-case model against the Stakeholder Requests and the Vision
OO/UML 43

Prioritizing the Use-cases

• Not all Use Cases should be implemented in the elaboration phase

– To identify the architecture it is important to not drown in too many details
• The architecture can be based on a simpler version of the system

• Setting priorities may help select the Use Cases that should be addressed in
each iteration
– The degree of support of the architecture for extensibility can be “tested” by adding
Use Cases in later iterations
OO/UML 44

Sequence Diagram: Example

• Simple messages

John : User : ATM : Bank : Consortium

insert card
verify card
verify account

account not ok
reject card

remove card
OO/UML 45

Sequence Diagram: Example

• Mixed messages (asynchronous and call messages)

liftRequestUpButton[i] : LiftSystem : LiftCage

: LightedButton
: Visitor
press( )
visitUp(i)
allocateCage()

visit(i)

– Call message: caller waits for answer before he continues

– Asynchronous message: caller continues after sending message
– Synchronous message: caller blocks until callee is ready to receive
• Rendez-vous
• Buffered communication
OO/UML 46

Use-Case Description: Example

Main success scenario of “Change Floor”
This Use Case describes the situation in which any person using the hospital lift intends to change from floor k (0 k<N)
to floor m (0m<N, mk).
1 The person pushes a lift-request button: the person is at floor k and requests a lift for going up or down depending
on m>k or m<k.
2 A lift cage Arrives At Floor k: after a while a lift cage with the appropriate direction arrives
2.1 The lift decelerates and stops
2.2 The chime sounds and the button light extinguishes.
2.3 The door opens.
3 The person enters the lift cage possibly together with other persons
4 The person pushes a floor-request button for floor m.
5 Lift cage Departs From Floor k
5.1 The door closes: after a certain amount of time passes, the door closes automatically.
5.2 The lift accelerates until it reaches its normal speed
6 Lift cage Arrives At Floor m
7 User exists the lift cage.
Often, steps 1 and 4 can be omitted because the buttons where already pressed by other actors. Also a lift may
already have arrived when the person arrives. Step 4 can be done any time between steps 3 and 6.
OO/UML 47

Realizing Use Case “Change Floor”

liftRequestUpButton floor1 : Floor : Door floorRequestButton : : LiftSystem : LiftCage : Motor

: LightedButton LightedButton
: Person
press( )
visitUp()
visitUp(floor1)
allocateCage()

visit(floor1)

setDestination(floor1)

justBelow(floor1)

arriveAt(floor1)
open( )

enter lift cage

OO/UML 48

Implementing the Use Case

liftRequestUpButton floor1 : Floor : Door floorRequestButton : : LiftSystem : LiftCage : Motor
: LightedButton LightedButton
: Person
press( )
visitUp()
visitUp(floor1)

allocateCage()

visit(floor1)

setDestination(floor1)

justBelow(floor1)

arriveAt(floor1)
open( )

enter lift cage

OO/UML 49

Transform diagram ...

Building

1 10
RequestedLiftUp
LiftSystem 0..1 Floor
*
floorNumber : int
visitUp() *
0..1
visitDown() RequestedLiftDown
*

8 * RequestedToServiceFloor
LiftCage
2
visit()
LightedButton
arriveAt() 10
doorIsClosed()
clear()
press()
OO/UML 50

… removing Floor class

LiftSystem liftRequestUpButton
floor : int LightedButton

visitUp() liftRequestDownButton floor

floor : int
visitDown() floorRequestButton clear()
press()

*
LiftCage floor : int
currentFloor

visit()
arriveAt()
doorIsClosed()
OO/UML 51

Requesting Lift
liftRequestUpButton[i] : Door : LiftSystem : LiftCage : Motor
: LightedButton

: Person
press( )
visitUp(i)
allocateCage()

visit(i)

setDestination(i)

justBelow( )

arriveAt(i)
open( )

enter lift cage

OO/UML 52

Go To Destination Floor
: Door floorRequestButton[j] : : LiftCage : Motor
LightedButton
: Person

press( )
visit(j)
setDestination(j)

Close()

doorIsClosed ()

raise( )

justBelow( )

arriveAt(j)

open( )

exit lift cage

OO/UML 53

Final class model Button

Building
press()
enable()
disable()

*
LiftSystem liftRequestUpButton
floor : int LightedButton

visitUp() liftRequestDownButton floor

floor : int theButtonLight
visitDown() floorRequestButton clear()
ButtonLight
press()
* on()
DirectionLight
LiftCage floor : int off()
direction isOn()
currentFloor
1..2 isOff()
floor : int on()
visit()
off() OpenButton
arriveAt()
doorIsClosed() theDoor theDoor
Door press()
closureTimeOut
Motor theDoor CloseButton
destination open()
floor close()
press()
theMotor stopClosing()
1
raise() DoorDetector
Chime
lower()
justAbove()
sound() theDetector enable()
justBelow()
disable()
setDestination()
detectObstruction()