UML Review

Overview: modeling with UML

 What is modeling?
 What is UML?
 Use case diagrams
 Class diagrams
 Sequence diagrams
 Activity diagrams
 Statechart 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?

 Software is getting increasingly more complex

 Windows XP > 40 mio 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 mean for dealing with complexity
What is UML?

 UML (Unified Modeling Language)

 An emerging standard for modeling object-oriented software.
 Resulted from the convergence of notations from three leading
object-oriented methods:
 OMT (James Rumbaugh)
 OOSE (Ivar Jacobson)
 Booch (Grady Booch)
 Reference: “The Unified Modeling Language User Guide”,
Addison Wesley, 1999.
 Supported by several CASE tools
 Rational ROSE
 TogetherJ
UML Core Conventions

 Rectangles are classes or instances

 Ovals are functions or use cases
 Instances are denoted with an underlined names
 myWatch:SimpleWatch
 Joe:Firefighter
 Types are denoted with non underlined names
 SimpleWatch
 Firefighter
 Diagrams are graphs
 Nodes are entities
 Arcs are relationships between entities
Use Case Diagrams

 Used during requirements

elicitation to represent external
behavior

 Actors represent roles, that is, a

type of user of the system
Passenger  Use cases represent a sequence of
interaction for a type of
functionality
 The use case model is the set of
all use cases. It is a complete
description of the functionality of
the system and its environment
PurchaseTicket
Actors

 An actor models an external entity which

communicates with the system:
 User
 External system
 Physical environment
 An actor has a unique name and an optional
Passenger description.
 Examples:
 Passenger: A person in the train
 GPS satellite: Provides the system with GPS
coordinates
 Use Case

A use case represents a class of

functionality provided by the system as
an event flow.

A use case consists of:

PurchaseTicket  Unique name
 Participating actors
 Entry conditions
 Flow of events
 Exit conditions
 Special requirements
System Boundary

TicketSystem

Passenger PurchaseTicket

A system boundary rectangle separates the ticket system from the

external actors
 The <<extends>> Relationship
 <<extends>> relationships
represent exceptional or seldom
invoked cases.
 The exceptional event flows are
Passenger factored out of the main event
flow for clarity.
 Use cases representing exceptional
flows can extend more than one
PurchaseTicket use case.
 The direction of a <<extends>>
<<extends>> relationship is to the extended use
case
<<extends>>
<<extends>>

OutOfOrder <<extends>> TimeOut

Cancel NoChange
 The <<includes>> Relationship

 <<includes>> relationship
represents behavior that is factored
Passenger
out of the use case.
 <<includes>> behavior is
factored out for reuse, not because
PurchaseMultiCard it is an exception.
PurchaseSingleTicket  The direction of a <<includes>>
<<includes>>
relationship is to the using use
case (unlike <<extends>>
<<includes>> relationships).

CollectMoney
<<extends>> <<extends>>

NoChange Cancel
Use Case Diagrams: Summary

 Use case diagrams represent external behavior

 An Actor is a role of an object or objects outside of a system

that interacts directly with it as part of a coherent work unit (a
use case)
 <<includes>> and <<extends>> allow common fragments of
use cases to be pulled out into a separate use cases
 <<includes>> is like a “use case subroutine”
 <extends>> is an alternative course of action
Class Diagrams

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

 Class diagrams represent the structure of the system.

 Used
 during requirements analysis to model problem domain concepts
 during system design to model subsystems and interfaces
 during object design to model classes.
Classes
TarifSchedule
Table zone2price
Enumeration getZones()
Name Price getPrice(Zone)

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

 A class represent 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.
Instances

tarif_1974:TarifSchedule
zone2price = {
{‘1’, .20},
{‘2’, .40},
{‘3’, .60}}

 An instance represents a phenomenon.

 The name of an instance is underlined and can contain the class of the
instance.
 The attributes are represented with their values.
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 source
object can legitimately reference.
1-to-1 and 1-to-many Associations

Country capital

name:String name:String

One-to-one association

Point
Polygon
* x: Integer

y: Integer
draw()

One-to-many association
Many-to-Many Associations

Lists
StockExchange * * Company

tickerSymbol

StockExchange * Lists
tickerSymbol
1
SX_ID
Company

qualifier
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
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();
};
public class Company
{
public int m_tickerSymbol;
private Vector m_StockExchange = new Vector();
};
 Aggregation
 An aggregation is a special case of association denoting a “consists of”
hierarchy.
 The aggregate is the parent class, the components are the children class.

Exhaust system Exhaust system

1 0..2 1 0..2
Muffler Tailpipe Muffler Tailpipe

diameter diameter diameter diameter

 A solid diamond denotes composition, a strong form of aggregation where

components cannot exist without the aggregate.

TicketMachine

3
ZoneButton
Inheritance

Button

CancelButton ZoneButton

 The children classes inherit the attributes and operations of the

parent class.
 Inheritance simplifies the model by eliminating redundancy.
Class Relationships
Our class diagram has three kinds of relationships.
 association -- a relationship between instances of the two classes. There is an
association between two classes if an instance of one class must know about the
other in order to perform its work. In a diagram, an association is a link
connecting two classes.
 aggregation -- an association in which one class belongs to a collection. An
aggregation has a diamond end pointing to the part containing the whole. In our
diagram, Order has a collection of OrderDetails.
 generalization -- an inheritance link indicating one class is a superclass of the
other. A generalization has a triangle pointing to the superclass. Payment is a
superclass of Cash, Check, and Credit.
Composition and aggregation
 Associations in which an object is part of a whole are aggregations.
Composition is a strong association in which the part can belong to only one
whole -- the part cannot exist without the whole. Composition is denoted by a
filled diamond at the whole end.
 This diagram shows that a BoxOffice belongs to exactly one MovieTheater.
Destroy the MovieTheater and the BoxOffice goes away! The collection of
Movies is not so closely bound to the MovieTheater.
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.
An example
Account
Bank Customer

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

Savings Checking Mortgage

Account Account Account

Withdraw() Withdraw() Withdraw()

UML sequence diagrams

 Used during requirements analysis

TicketMachine  To refine use case descriptions
Passenger
 to find additional objects
selectZone() (“participating objects”)
 Used during system design
 to refine subsystem interfaces
insertCoins()  Classes are represented by
columns
 Messages are represented by
arrows
pickupChange()
 Activations are represented by
narrow rectangles
 Lifelines are represented by
pickUpTicket() dashed lines
Nested messages

ZoneButton TarifSchedule Display

Passenger

selectZone()
lookupPrice(selection)

price
displayPrice(price)
Dataflow
…to be continued...

 The source of an arrow indicates the activation which sent the message
 An activation is as long as all nested activations
 Horizontal dashed arrows indicate data flow
 Vertical dashed lines indicate lifelines
 Iteration & condition
…continued from previous slide...

ChangeProcessor CoinIdentifier Display CoinDrop

Passenger

*insertChange(coin) lookupCoin(coin)

price
Iteration displayPrice(owedAmount)

[owedAmount<0] returnChange(-owedAmount)
Condition
…to be continued...

 Iteration is denoted by a * preceding the message name

 Condition is denoted by boolean expression in [ ] before the message
name
 Creation and destruction
…continued from previous slide...

ChangeProcessor
Passenger
Creation
createTicket(selection)

Ticket
print()

free()
Destruction

 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.
Sequence Diagram Summary

 UML sequence diagram represent behavior in terms of

interactions.
 Complement the class diagrams (which represent structure).
 State Chart Diagrams
Event Initial state State
[button2Pressed]
[button1&2Pressed]
BlinkHours IncrementHrs

Transition
[button1Pressed]

[button1&2Pressed] [button2Pressed]
BlinkMinutes IncrementMin.

[button1Pressed]

[button1&2Pressed] [button2Pressed]
BlinkSeconds IncrementSec.

StopBlinking
Final state

Represent behavior as states and transitions

Activity Diagrams

 An activity diagram shows flow control within a system

Handle Document Archive
Incident Incident Incident

 An activity diagram is a special case of a state chart diagram in

which states are activities (“functions”)
 Statechart Diagram vs. Activity Diagram
Statechart Diagram for Incident (similar to Mealy Automaton)
(State: Attribute or Collection of Attributes of object of type Incident)
Event causes
State transition

Active Inactive Closed Archived

Incident- Incident- Incident-
Handled Documented Archived

Activity Diagram for Incident (similar to Moore

(State: Operation or Collection of Operations)

Handle Document Archive

Incident Incident Incident

Triggerless
Completion of activity Transition
causes state transition
Activity Diagram: Modeling Decisions

[lowPriority]
Open Allocate
Incident Resources

[fire & highPriority]

[not fire & highPriority]

Notify
Fire Chief

Notify
Police Chief
Activity Diagrams: Modeling 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
Activity Diagrams: Swimlanes

 Actions may be grouped into swimlanes to denote the object or

subsystem that implements the actions.

Allocate Dispatcher
Resources

Open Coordinate Archive

Incident Resources Incident

FieldOfficer
Document
Incident
Deployment Diagram Example

:HostMachine
<<database>>
meetingsDB

:Scheduler

:PC

:Planner
UML Summary

 UML provides a wide variety of notations for representing

many aspects of software development
 Powerful, but complex language
 Can be misused to generate unreadable models
 Can be misunderstood when using too many exotic features

 For now we concentrate on a few notations:

 Functional model: Use case diagram
 Object model: class diagram
 Dynamic model: sequence diagrams, statechart and activity
diagrams
Problems with UML

 Semi-formal
 Go directly to the class/objects – a low level.
 Not good at express temporal information – StateChart