UML Basics

Grady Booch & Ivar Jacobson

Representing System Architecture

Logical Implementation
View View
End-user Programmers
Functionality Software management

Use Case
View
Process Deployment
View
System integrators View System engineering
Performance System topology
Scalability Delivery, installation
Throughput Communication

Conceptu Physical
al
Relation Between Views

Logical view Component view

Process view
β

Deployment view
 What is the UML?
 General-purpose OO modeling language
- convergence of a number of popular OO
methods
UML
OMT 1.4
(Rumbaugh et al)
Mar. 1999
1996

Booch UML UML

0.9 1.1
Nov. 1997

OOSE
(Jacobson et al)
Catalysis ROOM etc.
The Value of the UML
 Is an open standard
 Supports the entire software development
lifecycle
 Supports diverse applications areas
 Is based on experience and needs of the
user community
 Supported by many tools
Contributions to the UML
Harel
Meyer Gamma, et al
Statecharts
Before and after Frameworks and patterns,
conditions
HP Fusion
Booch
Operation descriptions and
Booch method message numbering

Embley
Rumbaugh
Singleton classes and
OMT
high-level view

Jacobson Wirfs-Brock
OOSE
Responsibilities

Shlaer - Mellor Odell

Object lifecycles Classification

Overview of the UML
 The UML is a language for
- visualizing
- specifying
- constructing
- documenting

the artifacts of a software-intensive system

UML is a standard modeling language for
software blueprints
Building Blocks of UML
 Modeling elements
 Relationships
 Extensibility Mechanisms
 Diagrams
 Rules
Modeling Elements
 Structural elements
- class, interface, collaboration, use case,
active class, component, node

 Behavioral elements
- interaction, state machine

 Grouping elements
- package, subsystem

 Other elements
- note
The Object Paradigm
 A synergistic combination of various proven
techniques including:
- encapsulation
- inheritance
- polymorphism/genericity

 Salient characteristic: a software system is

rendered as a structure of collaborating parts
⇒ the object paradigm is inherently structural
Relationships
 Dependency
 Association
 Generalization
 Realization
Extensibility Mechanisms
 Stereotype
 Tagged value
 Constraint
Rules
Rules are required to derive well-formed
models that are semantically consistent and
in harmony with related models

 Names – for things, relationships, diagrams

 Scope – context that gives meaning to name
 Visibility – way names can been seen/used
 Integrity – how things relate to each other
 Execution – run/simulate a dynamic model
Structure

 The individual parts of a system and their

run-time topological relationships
 Fundamental structural relationship types:
- Containment (strong and weak)
composition aggregation
(strong) (weak)

- Layering

- Communication (links)
Objects
 Entities that model some physical or
conceptual entity
- a unique identity (dedicated memory)
 the conceptual becomes physical!
- a public interface
- a hidden (encapsulated) implementation
methods
public
attributes Telephone1: void:offHook ();
{busy = true;
public +busy : boolean …
reqDialtone();

operations };
+offHook()
+onHook ()
+ring()
Conceptual Objects
 Not all objects necessarily require a physical
underpinning
 For example, the “telephone call” object:

Telephone1 Telephone2

Telephone Call
Telephone Call Object

abortCall ()
addParty (t:Telephone)
reportDuration ()
Classes and Instances
 Design-time specifications for one or more
distinct objects with a common form
(structure and behavior)
instance
(run time)
class phone1:Telephone
(design time)
busy = true
offHook()
onHook ()
Telephone ring()
phone2:Telephone
busy : boolean
busy = false
offHook()
onHook () offHook()
ring() onHook ()
ring()
Object Behavior
 Simple basic reactive server model:
Initialize
Object

Handling depends on Wait for

specific request type Request
and object state

void:offHook (); Handle

{busy = true;
obj.reqDialtone(); Request
…
};
Invokes
operations on
other objects Terminate
Object
Programming Model
 Combining objects into object structures

CallProc:

3.sendTone()
2.call()

PhoneIF: ToneGen:

1.offHook()

4.dialtone()
Object “Engines”
 Passive objects: depend on external motive
power (e.g., “main” program thread)
 Active objects: self-powered (own thread
of execution)
Initialize Initialize
Object Object

Wait for Wait for

Request Request

Handle Handle
Request Request

Terminate Terminate
Object Object
Inheritance and Polymorphism
 Generalization and re-use mechanisms
TelephoneClass

busy : boolean
Generalization
offHook()
(inheritance)
onHook ()
dialDigit() association

TouchTone RotaryDial
TelephoneClass TelephoneClass
busy : boolean Polymorphism: busy : boolean
offHook() an operation offHook()
onHook () implemented onHook ()
dialDigit() differently in dialDigit()
playTone() different classes
 Models, Views, and Diagrams
model is a complete
escription of a system
om a particular
State
erspective State
Diagrams
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

Scenario Component
Scenario
Diagrams
Component
Diagrams
Deployment
Statechart
Diagrams Diagrams
Diagrams Diagrams
Activity
Diagrams
Diagrams
 A diagram is a view into a model
- Presented from the aspect of a particular
stakeholder
- Provides a partial representation of the system
- Is semantically consistent with other views

 In the UML, there are nine standard

diagrams
- Static views: use case, class, object,
component, deployment
- Dynamic views: sequence, collaboration,
statechart, activity
Key Concept : Actor

An actor defines a coherent set of roles

that users of the system can play when
interacting with it. A user can either be
an individual or an external system.
Key Concept : Use Case

<Insert your
description here>

Use Case

A use case defines a set of use-case

instances, where each instance is a
sequence of actions a system performs
that yields an observable result of value to
Use cases focus on WHAT the system does, not HOW it
a particular
does it. actor.
Example : Use Case Diagram

View Report Card

(from Use Cases)

Student

Regist er For Course

Course Catalog
(from Use Cases)

Login Submit Grades

Professor
(from Use Cases) (from Use Cases)

Maintain Professor Info

(from Use Cases)

Maintain Student Info

Registrar
(from Use Cases)

Clos e Registration
Billing System
(from Use Cases)
Key Concept : Use Case Relationships
 Include
- To factor out common
behavior.
 Extend <<include>>
- To factor out optional or
exceptional parts of a
use case.
<<extend>>
 Generalization
- To share purpose,
structure, and behavior.
Use Case Diagram
 Captures system functionality as seen by
users
Use Case Diagram (contd.)
 Captures system functionality as seen by
users
 Built in early stages of development
 Purpose
- Specify the context of a system
- Capture the requirements of a system
- Validate a system’s architecture
- Drive implementation and generate test cases
 Developed by analysts and domain experts
 Super and Sub-ordinate Systems
<<super-ordinate system>>
S Actor3
<<subsystem>> <<subsystem>>
<<subsystem>>
sub-a sub-b
sub-c
X

Y
Actor1 <<subsystem>>
Z c
Actor2 Yc

<<subsystem>> <<subsystem>> Zc
a b
Actor3
Xb Sub b
Xa

Actor1 Sub a Yb
Ya

Zb
Based upon Software Reuse, Jacobson et al - 1997
Actor2
 Use Case Anatomy
<<super-ordinate system>>
S

<<include
<<include >>
>>
<<subsystem>>
<<subsystem>> b
a

X
X b
a

Based upon Software Reuse, Jacobson et al - 1997

 Use Case View Realization
<<view>>
<<super-ordinate system>> logical
S

X
X <<realisat
ion>>

<<view>>
implementation
<<realisat
ion>>
X
<<realisat <<realisat
ion>> ion>>
<<view>>
<<view>> deployment
process

X
X

Based upon Software Reuse, Jacobson et al - 1997

 Logical View Realization
<<super-ordinate system>>
S

<<view>>
logical

<<realisat :Sub :Sub

ion>> Actor3 a b

Based upon Software Reuse, Jacobson et al - 1997

 Implementation View Realization
<<super-ordinate system>>
S

<<view>>
Implementation

<<realisat
ion>> b
a 2
1

b b
1 3

Based upon Software Reuse, Jacobson et al - 1997

Class Diagram
 Captures the vocabulary of a system
Class Diagram (contd.)
 Captures the static design view
 Built and refined throughout development
 Purpose
- Name and model concepts in the system
- Specify collaborations
- Specify logical database schemas

 Developed by analysts, designers, and

implementers
Object Diagram
 Captures instances and links
Object Diagram (contd.)

 Shows instances and links

 Built during analysis and design
 Purpose
- Illustrate data/object structures
- Specify snapshots

 Developed by analysts, designers, and

implementers
Component Diagram
 Captures the physical structure of the
implementation
Component Diagram (contd.)

 Captures the physical structure of the

implementation
 Built as part of architectural specification
 Purpose
- Organize source code
- Construct an executable release
- Specify a physical database

 Developed by architects and programmers

Deployment Diagram
 Captures topology of a system’s hardware
Deployment Diagram (contd.)
 Captures the topology of a system’s
hardware
 Built as part of architectural specification
 Purpose
- Specify the distribution of components
- Identify performance bottlenecks

 Developed by architects, networking

engineers, and system engineers
 Process View Realization
<<super-ordinate system>>
S

<<view>>
Process

<<realisat :Proc :Proc :Proc

ion>> 1 2 3

Based upon Software Reuse, Jacobson et al - 1997

 Deployment View Realization
<<super-ordinate system>>
S

<<view>>
Deployment

<<realisat
ion>>
<<Processor> <<Processor>
> >
Laptop Server
Proc 1 Proc 3
Proc 2

Based upon Software Reuse, Jacobson et al - 1997

Sequence Diagram
 Captures dynamic behavior (time-oriented)
Sequence Diagram (contd.)

 Captures dynamic behavior, an interaction

that emphasizes time-ordering of
messages
 Purpose
- Model flow of control
- Illustrate typical scenarios
- Objects and messages sent/received by them
Collaboration Diagram

 Captures dynamic behavior (message-

oriented)
Collaboration Diagram (contd.)
 Captures dynamic behavior (message-
oriented)
 Purpose
- Model flow of control
- Illustrate coordination of object structure and
control
Statechart Diagram
 Captures dynamic behavior (event-
oriented)
Statechart Diagram (contd.)

 Captures dynamic behavior (event-

oriented)
 Purpose
- Model object lifecycle
- Model reactive objects (user interfaces,
devices, etc.)
Architecture and the UML

Design Implementation
View View

Classes, interfaces,
collaborations Components
Use cases

Use Case
View
Process Deployment
View View

Active classes Nodes

Organization Dynamics
Package, subsystem
Interaction
State machine
Active Objects in the UML
 Concurrent incoming events are queued and
handled one-at-a-time regardless of priority
- run-to-completion (RTC) execution model

ActiveObject:
RTC and Concurrency
 Eliminates need to write complex and error-
prone synchronization code
- if all passive objects encapsulated by an active
object, only a single thread can pass through
each passive object
ActiveObject: passive
encapsulated
objects
(protected
The event attributes)
handler is an
implicit critical
region
RTC Semantics
 RTC step semantics must not be confused with
uninterruptibility or unpre-emptabilty
- interrupts do not have to be blocked
- an active object can be pre-empted by another active
object responding to a higher-priority event
- priority inversion only occurs when an active object
blocks itself (i.e. it cannot block any other active
object)
 The effectiveness of this is supported by the
following empirical results
- most event handling is trivial
- in computer terms, events occur infrequently
Signals
 Used for asynchronous communication
- specified by a special type of class
- can be organized into class hierarchies
«signal»
Alarm

severity : integer

«signal» «signal»
FireAlarm MedicalEmergency

severity : integer severity : integer

address : Address type : EmergencyType
Activity Diagram
 Captures dynamic behavior (activity-oriented)
Activity Diagram (contd.)
 Captures dynamic behavior (activity-oriented)
 Purpose
- Model business workflows
- Model operations
Modeling Real Time Systems
 This complexity requires focussed
modeling support in at least the following
areas:
- Architectural modeling
- Timeliness and performance modeling
- Time-aware communication models
- Concurrency management
- Resource modeling
- Distributed system modeling
- Fault-tolerance techniques
RT Architectural Specifications
 Example telecom system architecture
Structure

Channel1

TerminalA TerminalB

Application Layer
Channel2

Services Layer Behavior

Architectural Component Design

Library
System1
Channel1

Terminal
TerminalA TerminalB

Channel2
Channel

System2
Terminal
Tester Terminal
TerminalA
Tester
Refining Architectures (Reuse)

Channel1

TerminalA TerminalB

Channel1

TerminalA TerminalB

Channel2
Approach and Method
 The necessary architectural modeling capabilities can
be found in ROOM
 Express the architectural modeling concepts of ROOM
using standard UML
 Real-time specific library of UML stereotypes

Business Software ...

UML for
Modeling Process Real-Time
Library Library Library

UML Modeling Concepts

 Real-Time Object-Oriented Modeling
(ROOM)
 Real-time-specific concepts for modeling
- dynamic high-level structures
- reactive behavior (ROOMcharts)

 Executable (formal) models

 Full automatic code generation
 Field proven in a large number (>100) of large-
scale industrial projects
 Tool support available (ObjecTime Limited and
Rational Software)
Capsules: Architectural Objects
 Active objects
Encapsulation
shell

Ports
Capsules: Behavior
 Optional hierarchical state machine
(signal handler with run-to-completion
semantics) transitionS1toS2:
{int x;
x = 0;
p2.send(s1);
p3.send(s2);
S1 …
};

S2 S3
Capsules: UML Modeling
 Stereotype of Class concept («capsule»)
with specialized (executable) semantics
 Class diagram representation:

«capsule»
CapsuleClassX

#counter : int
#x : char
ports
+portB : ProtocolA::master
#portC : ProtocolB
Protocols: Contractual Behavior Patterns

 Interaction contracts between capsules

- e.g., operator-assisted call
Caller Operator Callee
call

ack

number
call

ack
transfer
talk
time
Protocol Specifications
 A special form of collaboration

Alice Bob
caller OperatorAssisted callee
Call

protocol state machine

significant sequences
caller operator callee operator
initial

Charlie
Dexter
connecting

connected
Protocol Roles
 Specifies one party in a protocol
significant sequences
Incoming signals
caller operator callee

signal source
call caller
number caller
ack callee
OperatorRole
Outgoing signals role state machine
signal target
call callee initial

transfer caller
connecting
ack caller
connected
Protocol Refinement
 Using inheritance

Incoming signals Incoming signals

signal source signal source

call caller
OperatorRole call caller
number caller number caller
ack callee ack callee
reply caller

Outgoing signals Outgoing signals

signal target signal target

call callee Extended call callee
OperatorRole transfer caller
transfer caller
ack caller ack caller
query caller
Protocols: UML Modeling
 Collaboration stereotype: «protocol»
 Classifier Role stereotype: «protocolRole»
1 «protocolRole»
caller
«protocol»
incoming
OperatorAssisted ack
Call transfer

outgoing
call
number
talk

1 1
«protocolRole» «protocolRole»
operator callee
Ports: Boundary Objects
 Fully isolate a capsule’s implementation
from its environment (in both directions)

Capsule

S1
Environment
S2
Ports and Protocols
 Each port realizes a single protocol role
(type)
- Multiple ports with same type possible

«capsule»
CapsuleClassX

ports
+portA : ProtocolA::master
#portB : ProtocolB
+portC : ProtocolB~
Ports: Collaboration Diagram Notation

 Shorthand notation for capsule instances

- iconified form

portA : ProtocolA::master
«capsule»
anX:CapsuleClassX
1 «port»
portA:ProtocolA::master
Combining Capsules
 Using connectors

remote : FaxProt
«capsule» «capsule»
sender : Fax receiver : Fax
remote : FaxProt

Connector

Connectors model communication channels

Each connector supports a single protocol
Static typing rules apply (compatible protocols)
Modeled as association classes in UML
 Capsule Composition
Structural Patterns as (Reusable) Dynamic Components

Relay
sendCtrl : Control port receiveCtrl : Control

c : Control c : Control

remote:FaxProt
«capsule» «capsule»
sender:Fax receiver:Fax
Remote:FaxProt

FaxCall
 Composite Capsule Semantics
 Run-time assertion: the complete internal
structure of a composite is automatically
created (recursively, if necessary) when the
capsule is created
f1 := create(FaxCall);

«capsule» «capsule»
sender:Fax receiver:Fax

f1:FaxCall
Benefits of Run-Time Assertion
 Architectural enforcement: only explicitly prescribed
architectural structures can be instantiated
- it is not possible to bypass (corrupt) the
architecture by low-level programming

 Simplification: low-level program code that

dynamically creates (destroys) components and the
connections between them is eliminated
- in some systems this can be as much as 35% of
all code

 Major net gain in productivity and reliability

 End Ports: Structure & Behavior meet
 Ports directly connected to the state
machine
Implementation
c : SystemControl
Public End Port
End Port

capsule state machine

senderCtrl : Control~ receiveCtrl : Control~

initial

connecting
c : Control connected c : Control

«capsule» «capsule»
sender:Fax receiver:Fax
Decomposition : Class Diagram View
 Alternative representation
- More abstract

1 «capsule»
sender Fax
1 receiver
«capsule»
FaxCall
Summary (1)

 Complex real-time systems phenomena require

specialized modeling support
 The ROOM language has industry-proven
support for modeling complex real-time
architectures
 The benefits of both UML and ROOM are gained
by expressing the ROOM constructs as UML
stereotypes
- UML for Real Time (UML-RT): a UML extension for the
complex real-time domain
Summary (2)
 Only four UML stereotypes are sufficient
(include formally defined constraints that ensure
consistency/executability)

Stereotype UML Metaclass

«protocol» Collaboration
«protocolRole» ClassifierRole
«port» Class
«capsule» Class

⇒ supplemented by an optional custom

notation
Bibliography
 Real-time architectural modeling
whitepaper by B. Selic and J. Rumbaugh:
- http://www.objectime.com

 OMG’s UML 1.1 standard

- http://www.rational.com

 ROOM
- B. Selic, G. Gullekson, and P. Ward, “Real-
Time Object-Oriented Modeling”,
- John Wiley & Sons, NY, 1994.
Future
 UML 1.4 and Beyond
 ADL: Architecture Description Languages
- UML, UniCon, LILEAnna, P++, LEAP, Wright,
µRapid
 Standardization of concepts
- IEEE Working Group on Architecture
- INCOSE Working Group on System
Architecture
 Systematic capture of architectural patterns
References (Architecture)
 Len Bass, Paul Clements & Rick Kazman, Software Architecture in
Practice, Addison-Wesley, 1998.
 Frank Buschmann, Régine Meunier, Hans Rohnert, Peter Sommerlad,
and Michael Stahl, Pattern-Oriented Software Architecture - A System
of Patterns, Wiley and Sons, 1996.
 Christine Hofmeister, Robert Nord, Dilip Soni, Applied Software
Architecture, Addison-Wesley 1999.
 Eric Gamma, John Vlissides, Richard Helm, Ralph Johnson, Design
Patterns, Addison-Wesley 1995.
 Philippe Kruchten, “The 4+1 View Model of Architecture,” IEEE
Software, 12 (6), November 1995, IEEE.
- http://www.rational.com/support/techpapers/ieee/

 Eberhardt Rechtin, Systems Architecting: Creating and Building

Complex Systems, Englewood Cliffs NJ, Prentice-Hall, 1991.
References (Architecture)
 Eberhardt Rechtin & Mark Maier, The Art of System
Architecting, CRC Press, 1997.
 Recommended Practice for Architectural Description, Draft 2.0 of
IEEE P1471, May 1998
- http://www.pithecanthropus.com/~awg/

 Mary Shaw, and David Garlan, Software Architecture—

Perspectives on an Emerging Discipline, Upper Saddle River,
NJ, Prentice-Hall, 1996.
 Bernard I. Witt, F. Terry Baker, and Everett W. Merritt, Software
Architecture and Design—Principles, Models, and Methods,
New York NY, Van Nostrand Reinhold, 1995.
 The World-wide Institute of Software Architects
- http://www.wwisa.org
References (UML)
 http://www.omg.org/technology/uml/
 http://www.cetus-links.org/oo_uml.html (top UML portal !)
 http://www.rational.com/uml/resources/whitepapers/index.jsp
 http://www.celigent.com/uml/
 Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified
Modeling Language User Guide, Addison-Wesley, 1999.
 Applying UML and Patterns, An Introduction to Object-Oriented
Analysis and Design, Craig Larman, Pearson Education, LPE
 Real-Time UML, Second Edition, Developing Efficient Objects
for Embedded Systems, Bruce Power Douglas, AW Series
 Mastering UML with Rational Rose, Wendy Boggs and Michael
Boggs, bpb publications
References (Process)
 Barry Boehm, “A spiral model of software development and
enhancement,” IEEE Computer, May 1998.
 Barry Boehm, “Anchoring the software process,” IEEE
Software, July 1996.
 Grady Booch, Object Solutions, Addison-Wesley, 1995.
 Philippe Kruchten, “A Rational Development Process,”
CrossTalk, July 1996.
- http://www.rational.com/support/techpapers/devprcs/

 Philippe Kruchten, The Rational Unified Process - An

Introduction, Addison-Wesley, 1999.
 Rational Unified Process 5.0, Rational, Cupertino, CA, 1998
 Walker Royce, Software Project Management: a Unified
Framework, Addison-Wesley, 1998
 The Software Program Manager’s Network
- http://www.spmn.com