Software Engineering

Lecture 8

Modeling using UML

Overview: modeling with UML

¨ What is modeling?
¨ What is UML?
¨ Use case diagrams
¨ Class diagrams
¨ Sequence diagrams
¨ Activity diagrams
What is modeling?

¨ Modeling consists of building an abstraction of reality.

¨ Abstractions are simplifications because:
 They ignore irrelevant details and
 They only represent the relevant details.
¨ What is relevant or irrelevant depends on the purpose of the
model.
Why model software?

Why model software?

¨ Software is getting increasingly more complex

 Windows XP > 40 million lines of code
 A single programmer cannot manage this amount of code in its
entirety.
¨ Code is not easily understandable by developers who did not
write it
¨ We need simpler representations for complex systems
 Modeling is a means for dealing with complexity
UML: First Pass

¨ You can model 80% of most problems by using about 20%

UML
¨ We teach you those 20%
UML First Pass
¨ 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
¨ State diagrams
 Describe the dynamic behavior of an individual object
UML Core Conventions

¨ All UML Diagrams denote graphs of nodes and edges

 Nodes are entities and drawn as rectangles or ovals
 Rectangles denote classes or instances
 Ovals denote functions

• Names of Classes are not underlined

• SimpleWatch
• Firefighter
• Names of Instances are underlined
• myWatch:SimpleWatch
• Joe:Firefighter
• An edge between two nodes denotes a relationship between
the corresponding entities
 UML first pass: Use case diagrams
Classifier
Use Case

Actor

System boundary

se case diagrams represent the functionality of the syst

from user’s point of view
 UML first pass: Class diagrams

Association
Class

Multiplicity
SimpleWatch
1 1 1 1
2 1 2 1
PushButton Display Battery Time

Class diagrams represent the structure of the system

 UML first pass: Class diagrams
Class diagrams represent the structure of the system

Association
Class

Multiplicity Watch
1 1 1 1
2
1 2 1
PushButton
state LCDDisplay Battery Time
blinkIdx Load Now
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking()
Operations
Attribute referesh()
 UML first pass: Sequence diagram

Actor Message Object Lifeline

:WatchUser :Watch :LCDDisplay :Time
pressButton1() blinkHours()
pressButton1()
blinkMinutes()
pressButton2()
incrementMinutes()
refresh()
pressButton1and2()
commitNewTime()
stopBlinking()
Activation

Sequence diagrams represent the behavior of

a system
 UML first pass: Statechart diagrams
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

Represent behavior of a single object with

interesting dynamic behavior.
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; 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
Actors
¨ A model for an external entity which
interacts (communicates) with the system:
 User
 External system (Another system)
 Physical environment (e.g. Weather)
¨ Has unique name and an optional description
Passenger ¨ Examples:
 Passenger: A person in the train Optional
 GPS satellite: An external systemDescription
that provides
the system with GPS coordinates.

Name
Use Case
• A class of functionality provided by the
system
• Described textually, with a focus on the
event flow between actor and system
• The textual use case description consists of
6 parts:
1. Unique name
PurchaseTicket 2. Participating actors
3. Entry conditions
4. Exit conditions
5. Flow of events
6. Special requirements.
Textual Use Case Description Example
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 money, at
least the amount due
¨ Passenger stands in front of
4. Ticket Distributor returns
ticket distributor change
¨ Passenger has sufficient 5. Ticket Distributor issues
money to purchase ticket ticket
6. Special requirements: None
4. Exit condition:
¨ Passenger has ticket
 Uses Cases can be related: <<extends>>
<<extends>> models exceptional
or seldom invoked cases
 Exceptional event flows are
Passenger factored out of the main event
flow for clarity
 Direction is to the extended use
case
PurchaseTicket  Can extend more than one use
case.
<<extends>>

<<extends>>
<<extends>>
OutOfOrder <<extends>> TimeOut

Cancel NoChange
Uses Cases can be related: <<includes>>
<<includes>> represents
common functionality needed
in more than one use case
Passenger  Behavior factored out for
reuse, not because it is an
exception
PurchaseMultiCard
 Direction is to the using use
PurchaseSingleTicket case (unlike the direction of
<<includes>> the <<extends>> relationship).
<<includes>>

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

NoChange Cancel Cancel

Class Diagrams

¨ Represent the structure of the system

¨ Used 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)
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
¨ Class name is the only mandatory information
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”).
Associations

TarifSchedule TripLeg

Enumeration getZones() Price

* * Zone
Price getPrice(Zone)

¨ Denote relationships between classes

¨ Multiplicity of an association end denotes how many objects
the instance of a class can legitimately reference
1-to-1 and 1-to-many Associations

Country 1 1 City

name:String capitalname:String

1-to-1 association

Point
Polygon
* x: Integer

y: Integer
draw()

1-to-many association
Aggregation vs. Composition
¨ Aggregation (diamond): 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
TicketMachine diameter diameter

3
ZoneButton

¨ Composition (solid diamond): strong form of aggregation.

¨ Aggregation means one object is the owner of another
object. Composition means one object is contained in another
object
Inheritance

Button

CancelButton ZoneButton

¨ Another special case of an association denoting a “kind-of”

hierarchy
¨ Simplifies analysis model by introducing a taxonomy
¨ Children classes inherit attributes and operations of parent
class
Packages

¨ Organize UML models to increase their readability

¨ Organize classes into subsystems

Account

Bank Customer

¨ Any complex system can be decomposed into subsystems,

where each subsystem is modeled as a package.
 Object Modeling in Practice

Foo

Amount
CustomerId

Deposit()
Withdraw()
GetBalance()

s Identification: Name of Class, Attributes and Methods

oo the right name?

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()
Object Modeling in Practice: More classes

Account

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

1) Find new classes

2) Review names, attributes and methods
Object Modeling in Practice: Associations

Account

* Amount
AccountId * Customer
Bank CustomerId
AccountId owns
1..* Name
Name Deposit() CustomerId
Withdraw()
GetBalance()

1) Find new classes

2) Review names, attributes and methods
3) Find Associations between Classes
4) Label generic associations
5) Determine multiplicity of associations
6) Review associations
 TicketMachine
Sequence Diagrams Focus on zone2price
selectZone()
control flow
insertCoins()
pickupChange()
pickUpTicket()
TicketMachine
Passenger

selectZone()
¨ Used during analysis
 to refine use case descriptions
 to find additional objects
(“participating objects”)
insertCoins()
¨ Used during system design
 to refine subsystem interfaces
¨ Instances are represented by
pickupChange() rectangles. Actors by sticky figures
¨ Lifelines are represented by dashed
lines
pickUpTicket() Messages are ¨ Messages are represented by arrows
Operations on ¨ Activations are represented by narrow
participating Object rectangles.
Sequence Diagrams can also model the Flow of Data

ZoneButton TarifSchedule Display

Passenger

selectZone()
lookupPrice(selection)

price
displayPrice(price)
Dataflow

¨ Source of an arrow indicates activation which sent the

message
¨ Horizontal dashed arrows indicate data flow, for example
return results from a message
 Sequence Diagrams: Iteration & Condition

ChangeProcessor CoinIdentifier Display CoinDrop

Passenger

* insertChange(coin)
lookupCoin(coin)

price
Iteration displayPrice(owedAmount)

[owedAmount<0] returnChange(-owedAmount)
Condition

¨ Iteration denoted by a * preceding the message name

¨ Condition denoted by Boolean expression in [ ] before
message name
 Creation and Destruction

ChangeProcessor
Passenger Creation of Ticket
createTicket(selection)

Ticket
print()

free()
Destruction of Ticket

¨ Creation denoted by a message arrow pointing to object

¨ Destruction 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.
Sequence Diagram Properties

¨ Behavior in terms of interactions

¨ How objects interact to get the job done
¨ Useful to identify or find missing objects
¨ Time consuming to build, but worth the investment
¨ Complement the class diagrams (which represent static
structure)
Activity Diagrams

¨ Useful to depict the workflow in a system (analogous to

flowcharts)
¨ Activities are of the system, not the user!

Handle Document Archive

Incident Incident Incident
Activity Diagrams allow to model Decisions

Decision

[lowPriority]
Open Allocate
Incident Resources

[fire & highPriority]

[not fire & highPriority]

Notify
Fire Chief

Notify
Police Chief
Activity Diagrams can model Concurrency

¨ Synchronization of multiple independent activities

¨ Splitting the flow of control into multiple threads

Allocate
Splitting Resources Synchronization

Open Coordinate Archive

Incident Resources Incident

Document
Incident
Activity Diagrams: grouping

¨ May be grouped into swimlanes to denote object or subsystem

that implements the activities.

Allocate Dispatcher
Resources

Open Coordinate Archive

Incident Resources Incident

FieldOfficer
Document
Incident