Lecture - 2

Introduction to
Unified Modeling
Language
 Introduction
• Concepts of modeling in general and object-oriented modeling.

• Use case diagrams

• Class diagrams
• Sequence diagrams
• Statechart diagrams
• Activity diagrams
 Introduction
• Functional model: represented by use case diagrams  describes the
functionality of the system from the user’s point of view.

• Object model: represented by class diagrams  describes the structure of the

system in terms of objects, attributes, associations, and operations.

• Dynamic model: represented by interaction diagrams, state machine

diagrams, activity diagrams  describes the internal behavior of the system.
 Introduction
• 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.
 Use Case Diagrams
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.
 Use Case Diagrams
• Used during requirements elicitation and analysis to represent the
functionality of the system.

• Focuses on the behavior of the system from an external point of view.

• Describes a function provided by the system that yields a visible result for an
actor.

• Identification of actors and use cases results in the definition of the boundary
of the system.
 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)
• An actor has a unique name and an
Passenger optional description Optional
• Examples: Description
• Passenger: A person in the train
• GPS satellite: An external system that
Name provides the system with GPS
coordinates.
 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.
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
• Passenger has sufficient 4. Ticket Distributor returns
change
money to purchase ticket
5. Ticket Distributor issues
ticket
4. Exit condition: 6. Special requirements:
• Passenger has ticket None.
 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.
 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
 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>>
<<extends>>

NoChange Cancel Cancel

Use Case Diagrams
 Class Diagrams
• Used to describe the structure of the system.

• Classes are abstractions that specify the common structure and behavior of a
set of objects.

• Objects are instances of classes that are created, modified, and destroyed
during the execution of the system.

• An object has state that includes the values of its attributes and its links with
other objects.
 Class Diagrams

• 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)
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

 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)
 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)

Associations denote relationships between classes.

The 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 name:String

1-to-1
association
Point
Polygon
* x: Integer

y: Integer
draw()

1-to-many
association
 Many-to-Many Associations

Company

StockExchange * * tickerSymbo
l
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 : A stock exchange lists many companies.
Each company is identified by a ticker
Statement
symbol
Class
Diagram:StockExchang * * Compan
e Lists y
tickerSymbo
l

Java Code
public class StockExchange
{
private Vector m_Company = new Vector();
Associations
};
are mapped to
public class Company
{ Attributes!
public int
private Vector m_StockExchange = new Vector();
m_tickerSymbol;
};
 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
 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.
Qualification: Another Example

Company

StockExchange * Lists
* tickerSymbo
l

StockExchange
*
tickerSymbol
Lists 1
* Company
 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.
 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.
 Object Modeling in Practice

Foo

Amount
Is Foo the right name?
CustomerId

Deposit()
Withdraw()
GetBalance()

Class Identification: Name of Class, Attributes and

Methods
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
Customer
Id Name
Name Deposit() Customer
Withdraw()
GetBalance() Id

1) Find New
Classes
2) Review Names, Attributes and
Methods
Object Modeling in Practice: Associations

Account

? * Amount
AccountId * own
Customer
Bank ha CustomerId
Account
s Id s Name
Deposit() 2
Name CustomerId
Withdraw()
GetBalance()

1) Find New
Classes
2) Review Names, Attributes and
Methods
3) Find Associations between
4) Label Classes
the generic
5) Determine the multiplicity of the
assocations
assocations
6) Review
associations
Practice Object Modeling: Find
Taxonomies
Account
Bank Customer

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

Savings Checking Mortgage

Account Account Account

Withdraw() Withdraw() Withdraw()

Practice Object Modeling: Simplify,
Organize
Account

Amount Show Taxonomies

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

Saving Checki Mortga

s ng ge
Accou Accoun Accoun
nt t t

Withdra Withdra Withdra

w() w() w()
 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

 Class Diagrams
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()
 Sequence Diagrams

• Used to formalize the dynamic behavior of the system and to

visualize the communication among objects.

• Useful for identifying additional objects that participate in the

use cases.

• Objects involved in a use case are called participating objects.

• Sequence diagrams represent the interactions that take place

among these objects.
Sequence Diagrams Focus on
Controlflow

• Used during analysis

TicketMachine • To refine use case descriptions
Passenger
• to find additional objects
selectZone()
(“participating objects”)
• Used during system design
TicketMachine • to refine subsystem interfaces
zone2price
insertCoins() • Instances are represented by Messag
selectZone() rectangles. Actors by sticky Operatio
insertCoins() figures participatin
pickupChange() • Lifelines are represented by
pickUpTicket()
pickupChange()
dashed lines
• Messages are represented by
arrows
pickUpTicket() • Activations are represented
by narrow rectangles.
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
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
 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.
 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).
 Sequence Diagrams
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

as messages (“interactions”) between different objects
 State Machines

• Describes the dynamic behavior of an individual object as a

number of states and transitions between these states.

• A state represents a particular set of values for an object.

• Given a state, a transition represents a future state the object

can move to, and the conditions associated with the change of
state.
 State Machines
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.

 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.
Activity Diagrams can model
Concurrency
• Synchronization of multiple activities.
• Splitting the flow of control into multiple threads.

Splitting Synchronization
 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

Field
Document Officer
Incident