Object-Oriented Design

Modeling with UML

Overview: modeling with UML

 What is modeling?
 What is UML?
 Use case diagrams
 Class diagrams

Next lecture
 Sequence diagrams
 Activity diagrams

Knight Object-Oriented
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.

Knight Object-Oriented
Example: street map

Knight Object-Oriented
Why model software?

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

Knight Object-Oriented
Systems, Models and Views

 A model is an abstraction describing a subset of a system

 A view depicts selected aspects of a model
 A notation is a set of graphical or textual rules for depicting views
 Views and models of a single system may overlap each other

Examples:
 System: Aircraft
 Models: Flight simulator, scale model
 Views: All blueprints, electrical wiring, fuel system

Knight Object-Oriented
Systems, Models and Views

Flightsimulator
Blueprints
Aircraft
Model 2
View 2
View 1
System
View 3

Model 1

Electrical
Wiring
Scale Model

Knight Object-Oriented
Models, Views and Systems (UML)

* *
System Model View
Described by Depicted by

Airplane: System

Scale Model: Model Flight Simulator: Model

Blueprints: View Fuel System: View Electrical Wiring: View

Knight Object-Oriented
Concepts and Phenomena

Phenomenon
 An object in the world of a domain as you perceive it
 Example: The lecture you are attending
 Example: My black watch
Concept
 Describes the properties of phenomena that are common.
 Example: Lectures on software engineering
 Example: Black watches
Concept is a 3-tuple:
 Name (To distinguish it from other concepts)
 Purpose (Properties that determine if a phenomenon is a member
of a concept)
 Members (The set of phenomena which are part of the concept)

Knight Object-Oriented
Concepts and phenomena

Name Purpose Members

Clock A device that

measures time.

 Abstraction
 Classification of phenomena into concepts
 Modeling
 Development of abstractions to answer specific questions about a set of
phenomena while ignoring irrelevant details.

Knight Object-Oriented
Concepts in software: Type and Instance

 Type:
 An abstraction in the context of programming languages
 Name: int, Purpose: integral number, Members: 0, -1, 1, 2, -2, . . .
 Instance:
 Member of a specific type
 The type of a variable represents all possible instances the
variable can take

The following relationships are similar:

 “type” <–> “instance”
 “concept” <–> “phenomenon”

Knight Object-Oriented
Abstract Data Types & Classes
 Abstract data type
 Special type whose implementation is hidden Watch
from the rest of the system.
time
 Class: date
 An abstraction in the context of object-
SetDate(d)
oriented languages
 Like an abstract data type, a class
encapsulates both state (variables) and
behavior (methods)
 Class Vector CalculatorWatch

 Unlike abstract data types, classes can be calculatorState

defined in terms of other classes using EnterCalcMode()
inheritance InputNumber(n)

Knight Object-Oriented
Application and Solution Domain

 Application Domain (Requirements Analysis):

 The environment in which the system is operating

 Solution Domain (System Design, Object Design):

 The available technologies to build the system

Knight Object-Oriented
Object-oriented modeling

Application Domain Solution Domain

Application Domain Model System Model
UML Package
TrafficControl SummaryDisplay MapDisplay

TrafficController FlightPlanDatabase
Aircraft

FlightPlan Airport TrafficControl

Knight Object-Oriented
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

Knight Object-Oriented
UML: First Pass

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

UML
 We teach you those 20%

Knight Object-Oriented
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 actors and the system and
between objects of the system
 Statechart diagrams
 Describe the dynamic behavior of an individual object (essentially a
finite state automaton)
 Activity Diagrams
 Model the dynamic behavior of a system, in particular the workflow
(essentially a flowchart)

Knight Object-Oriented
 UML first pass: Use case diagrams

Package Use case

Watch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

ChangeBattery

e case diagrams represent the functionality of the syste

om user’s point of view
Knight Object-Oriented
 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 LCDDisplay Battery Time
state blinkIdx load now
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking()
referesh()

Attribute
Operations

Knight Object-Oriented
 UML first pass: Sequence diagram
Actor Object

:Watch :LCDDisplay :Time

:WatchUser

pressButton1() blinkHours()
pressButton1() blinkMinutes()

Message pressButton2() incrementMinutes()

refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Activation Lifeline

equence diagrams represent the behavior as interaction

Knight Object-Oriented
 UML first pass: Statechart diagrams for objects
with interesting dynamic behavior
Event State
Initial state
[button1&2Pressed] [button2Pressed]
BlinkHours IncrementHrs

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

[button1Pressed]

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

StopBlinking Final state

Represent behavior as states and transitions

Knight Object-Oriented
Other UML Notations

UML provide other notations that we will be introduced in

subsequent lectures, as needed.

 Implementation diagrams
 Component diagrams
 Deployment diagrams
 Introduced in lecture on System Design
 Object constraint language
 Introduced in lecture on Object Design

Knight Object-Oriented
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

Knight Object-Oriented
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

Knight Object-Oriented
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

Knight Object-Oriented
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

Knight Object-Oriented
Use Case Diagram: Example

Name: Purchase ticket Event flow:

1. Passenger selects the number of
Participating actor: Passenger zones to be traveled.
2. Distributor displays the amount
due.
Entry condition:
3. Passenger inserts money, of at
 Passenger standing in front of
least the amount due.
ticket distributor.
4. Distributor returns change.
 Passenger has sufficient money to
purchase ticket. 5. Distributor issues ticket.

Exit condition:
Anything missing?
 Passenger has ticket.

Exceptional cases!
Knight Object-Oriented
 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
Knight Object-Oriented
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 it is an
PurchaseMultiCard exception.
PurchaseSingleTicket  The direction of a <<includes>>
<<includes>>
relationship is to the using use
case (unlike <<extends>>
<<includes>> relationships).

CollectMoney
<<extends>> <<extends>>

NoChange Cancel
Knight Object-Oriented
Use Case Diagrams: Summary

 Use case diagrams represent external behavior

 Use case diagrams are useful as an index into the use cases
 Use case descriptions provide meat of model, not the use case
diagrams.
 All use cases need to be described for the model to be useful.

Knight Object-Oriented
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.

Knight Object-Oriented
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.

Knight Object-Oriented
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.

Knight Object-Oriented
Actor vs Instances

 What is the difference between an actor , a class and an

instance?
 Actor:
 An entity outside the system to be modeled, interacting with the
system (“Passenger”)
 Class:
 An abstraction modeling an entity in the problem domain, must be
modeled inside the system (“User”)
 Object:
 A specific instance of a class (“Joe, the passenger who is purchasing
a ticket from the ticket distributor”).

Knight Object-Oriented
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.

Knight Object-Oriented
1-to-1 and 1-to-many Associations

Country Has- City

*capital
name:String name:String

One-to-one association

Point
Polygon
* x: Integer

y: Integer
draw()

One-to-many association

Knight Object-Oriented
Many-to-Many Associations

Lists
StockExchange * * Company

tickerSymbol

StockExchange *
tickerSymbol
Lists 1
SX_ID
Company

Knight Object-Oriented
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

Knight Object-Oriented
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();
};
Knight Object-Oriented
 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. (Bill of Material)
TicketMachine

3
ZoneButton
Knight Object-Oriented
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.

Knight Object-Oriented
Inheritance

Button

CancelButton ZoneButton

 The children classes inherit the attributes and operations of the

parent class.
 Inheritance simplifies the model by eliminating redundancy.

Knight Object-Oriented
Object Modeling in Practice: Class Identification

Foo

Betrag
CustomerId

Deposit()
Withdraw()
GetBalance()

Class Identification: Name of Class, Attributes and Methods

Knight Object-Oriented
Object Modeling in Practice:
Encourage Brainstorming

“Dada” Foo

Betrag Betrag
CustomerId CustomerId

Deposit() Deposit()
Withdraw() Withdraw()
GetBalance() GetBalance()
Account

Betrag
CustomerId

Deposit()
Naming is important! Withdraw()
Is Foo the right name? GetBalance()

Knight Object-Oriented
Object Modeling in Practice ctd

Account

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

1) Find New Objects

2) Iterate on Names, Attributes and Methods

Knight Object-Oriented
Object Modeling in Practice: A Banking System

Account

Betrag
Bank AccountId
CustomerId
AccountId
* Has
Customer

Name
Name Deposit() CustomerId
Withdraw()
GetBalance()

1) Find New Objects

2) Iterate on Names, Attributes and Methods
3) Find Associations between Objects
4) Label the assocations
5) Determine the multiplicity of the assocations
Knight Object-Oriented
Practice Object Modeling: Iterate, Categorize!
Account
Bank Customer

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

Savings Checking Mortgage

Account Account Account

Withdraw() Withdraw() Withdraw()

Knight Object-Oriented
Packages
 A package is a UML mechanism for organizing elements into
groups (usually not an application domain concept)
 Packages are the basic grouping construct with which you may
organize UML models to increase their readability.

DispatcherInterface

Notification IncidentManagement

 A complex system can be decomposed into subsystems, where

each subsystem is modeled as a package

Knight Object-Oriented
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

Knight Object-Oriented
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

Knight Object-Oriented
 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

Knight Object-Oriented
 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.

Knight Object-Oriented
Sequence Diagram Summary

 UML sequence diagram represent behavior in terms of

interactions.
 Useful to find missing objects.
 Time consuming to build but worth the investment.
 Complement the class diagrams (which represent structure).

Knight Object-Oriented
 State Chart Diagrams
Event Initial state State

[button1&2Pressed] [button2Pressed]
BlinkHours IncrementHrs

Transition
[button1Pressed]

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

[button1Pressed]

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

StopBlinking
Final state

Represent behavior as states and transitions

Knight Object-Oriented
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”)
 Two types of states:
 Action state:
 Cannot be decomposed any further
 Happens “instantaneously” with respect to the level of abstraction
used in the model
 Activity state:
 Can be decomposed further
 The activity is modeled by another activity diagram

Knight Object-Oriented
 Statechart Diagram vs. Activity Diagram
atechart Diagram for Incident (similar to Mealy Automaton)
tate: 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
Knight Object-Oriented
Activity Diagram: Modeling Decisions

[lowPriority]
Open Allocate
Incident Resources

[fire & highPriority]

[not fire & highPriority]

Notify
Fire Chief

Notify
Police Chief

Knight Object-Oriented
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

Knight Object-Oriented
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

Knight Object-Oriented
What should be done first? Coding or Modeling?

 It all depends….

 Forward Engineering:
 Creation of code from a model
 Greenfield projects
 Reverse Engineering:
 Creation of a model from code
 Interface or reengineering projects
 Roundtrip Engineering:
 Move constantly between forward and reverse engineering
 Useful when requirements, technology and schedule are changing
frequently

Knight Object-Oriented
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

Knight Object-Oriented