UML 2.

0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 1 - Introduction
Prof. Dr. Harald Strrle

University of Innsbruck

mgm technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

1 - Introduction
History and Predecessors

The UML is the lingua franca of

software engineering.

It subsumes, integrates and

consolidates most predecessors.

Through the network effect, UML has a

much broader spread and much better
support (tools, books, trainings etc.)
than other notations.

The transition from UML 1.x to UML

2.0 has
resolved a great number of issues;
introduced many new concepts and
notations (often feebly defined);
overhauled and improved the
internal structure completely.

While UML 2.0 still has many problems,

it is much better than what we ever had
before.

current version (the standard)

formal/05-07-04 of August 05
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

1 - Introduction
Usage Scenarios

UML has not been designed for specific, limited usages.

There is currently no consensus on the role of the UML:
Some see UML only as tool for sketching class diagrams
representing Java programs.
Some believe that UML is the prototype of the next generation of
programming languages.
UML is a really a system of languages (notations, diagram types)
each of which may be used in a number of different situations.
UML is applicable for a multitude of purposes, during all phases of
the software lifecycle, and for all sizes of systems - to varying
degrees.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

1 - Introduction
Usage Scenarios

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

1 - Introduction
Diagram types in UML 2

(v4)

UML is a coherent system of languages rather than a single language.

Each language has its particular focus.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

1 - Introduction
Diagram types also depend on their usage

(v4)

Each diagram type may be used in

a multitude of settings, for each of
which different rules and best
practices may apply.
For instance, class diagrams may
be used during analysis as well as
during implementation.
During analysis, this class diagram
is bad, or at least suspicious.
During implementation, it is bad if
and only if it does not correspond
to the code (or other structure) it
is used to represent.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

1 - Introduction
Internal Structure: Overview

The UML is structured using a metamodeling approach with four layers.

The M2-layer is called metamodel.
The metamodel is again structured into rings, one of which is called
superstructure, this is the place where concepts are defined (the
metamodel proper).
The Superstructure is structured into a tree of packages in turn.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

1 - Introduction
Internal Structure: Layers

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

1 - Introduction
Internal Structure: Layers

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

1 Introduction
Internal Structure: Rings

(v4)

10

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

1 - Introduction
Internal Structure: Packages

(v4)

11

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

1 - Introduction
Diagrams and models

12

diagram name
(pragmatic)
diagram kind

diagram

(concrete syntax)

represent

present

datastructure,
instance of the metamodel

model

(abstract syntax)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

1 - Introduction
UML is not (only) object oriented

(v4)

13

A popular misconception about UML is that it is object oriented by

heart whatever that means.
It is true that
UML defines concepts like class and generalization;
UML is defined using (mainly) a set of class models;
UML 2.0 rediscovers the idea of behavior embodied in objects.
However, UML 2.0
also encompasses many other concepts of non- or pre-OO origin
(Activities, StateMachines, Interactions, CompositeStructure, );
may be used in development projects completely independent of
their implementation languages (Java, Cobol, Assembler, );
is not tied to any language or language paradigm, neither by
accident nor purpose.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

1 - Introduction
UML 1.x vs. UML 2.0
UML 1.x
Collaboration diagram
ActivityGraph is a StateMachine

14

UML 2.0
Communication diagram
Activity is a Behavior (Petri-like)
New features in UML 2.0
Activities: exceptions, streams,
structured nodes,
traverse-to-completion
Timing diagram
interaction overview diagram
composite structure diagram
interaction operators
collaborations
Other novelties
Detail changes everywhere
New overall structure
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

1 - Introduction
UML 1.x vs. UML 2.0

15

UML 2.0 has several advantages over UML 1.x:

many powerful new concepts
much better definitions (i.e. semantics)
improved internal structuring
However, even though UML 2.0 is much better defined than UML 1.5, the
state is still not satisfying, e.g.
syntax
overloaded notation: too many synonyms, too much sugaring,
lack of notational orthogonality, some people dont even want this,

semantics

lack of precise semantics: informal, unclear and contradictory definitions,

pragmatics

lack of methodological basis such as model consistency conditions, usage types etc.

Still, its the best comprehensive (unified) modeling language we ever had.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

1 - Introduction
Wrap up

16

UML is the lingua franca of software engineering.

It has many problems, yet it is better than anything we had before.
It may be used during the whole software lifecycle. UML may help to
plan, analyze, design, implement, and document software.
The UML is structured
by a 4-layer metamodeling approach

(M0: system, M1: model, M2: meta model, M3: meta meta model),

the metamodel is structured into 3 rings

(infrastructure, superstructure, extensions),

the superstructure is organized as a tree of packages.

(e.g. Actions, Activities, Common Behaviors, Classes, )

UML is not object oriented by heart.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 2 Classes and packages
Prof. Dr. Harald Strrle
University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2 Classes and packages

A first glimpse

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

History and predecessors

Structured analysis and design

Entity-Relationship (ER) diagrams (Chen 1976)
Semantic nets
Conceptual structures in AI (Sowa 1984)
Object-oriented analysis and design
Shlaer/Mellor (1988)
Coad/Yourdon (1990)
Wirfs-Brock/Wilkerson/Wiener (1990)
OMT (Rumbaugh 1991)
Booch (1991)
OOSE (Jacobson 1992)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Usage scenarios

Classes and their relationships describe the vocabulary of a system.

Analysis: Ontology, taxonomy, data dictionary,
Design: Static structure, patterns,
Implementation: Code containers, database tables,
Classes may be used with different meaning in different software
development phases.
meaning of generalizations varies with meaning of classes
Analysis
Concept

Design

Implementation

Type
Set of objects

Code

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2 Classes and packages

Analysis class diagram (1)

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Classes

Classes describe a set of instances with common features (and

semantics).
Classes induce types (representing a set of values).
Classes are namespaces (containing named elements).
Structural features (are typed elements)
properties

commonly known as attributes

describe the structure or state of class instances
may have multiplicities (e.g. 1, 0..1, 0..*, *, 2..5)
(default: 0..* = *, but 1 for association ends)

Behavioral features (have formal parameters)

operations
services which may be called
need not be backed by a method, but may be
implemented otherwise

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Associations

Associations describe sets of tuples whose values refer to typed

instances.
In particular, structural relationship between classes
Instances of associations are called links.
reading
direction

association name

qualified end (fh per date)

ternary association

Association ends are properties.

correspond to properties of the opposite class
(but default multiplicity is 1)

Association ends may be navigable.

in contrast to general properties
navigable not navigable
association end
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Association classes

Association classes combine classes with associations.

not only connect a set of classifiers but also define a set of
features that belong to the relationship itself and not to any of
the classifiers
equals association name

each instance of Booking has one passenger and one flight

each link of Booking is one instance of Booking
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Data types and enumerations

Data types are types whose instances are identified by their value.
Instances of classes have an identity.
may show structural and behavioral features
compartments for attributes
and operations suppressed
enumeration literals

Enumerations are special data types.

instances defined by enumeration literals

denoted by Enumeration::EnumerationLiteral or #EnumerationLiteral

may show structural and behavioral features

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2 Classes and packages

Analysis class diagram (2)

(v4)

10

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Inheritance (1)

11

Generalizations relate specific classes to more general classes.

instances of specific class also instances of the general class
features of general class also implicitly specified for specific class
{ abstract } class
(no direct instances,
only specializations
may have instances)

if decorated with { root }: no superclass

if decorated with { leaf }: no subclass

does not imply substitutability (in the sense of Liskov & Wing)
must be specified on specific class separately by { substitutable }

Generalizations also apply to

associations.
as both are Classifiers

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Inheritance (2)

12

Generalization sets detail the relation between a general and more

specific classifiers.
{ complete }
(opposite: { incomplete })
all instances of general classifier are instances of one of the specific
classifiers in the generalization set

{ disjoint }

(opposite: { overlapping })

no instance of general classifier belongs to more than one specific classifier

in the generalization set

default: { disjoint, incomplete }

name of generalization set

several generalization sets may be applied to a classifier

useful for taxonomies

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Constraints

13

Constraints restrict the semantics of model elements.

constraints may apply to one or more elements
no prescribed language
OCL is used in the UML 2.0 specification
also natural language may be used

user defined constraint

UML predefined constraint

(owner is either a person or a company)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Packages (1)

14

Packages group elements.

Packages provide a namespace for its grouped elements.
Elements in a package may be
public (+, visible from outside; default)
private (-, not visible from outside)

Access to public elements by qualified names

e.g., Flights::MilesAccount

Notational variants

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Packages (2)

15

Package imports simplify qualified names.

private ElementImport

public PackageImport

public ElementImport

renaming private ElementImport

Package

Element

Visibility

private

separate private element import

(otherwise public overrides private)

public

all remaining visible elements of B

public

public import

public

default visibility

private

private import, renaming

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Packages (3)

16

Package mergings combine concepts incrementally.

but use with care
The receiving package
defines the increment.
The receiving package
is simultaneously the
resulting package.
Merging is achieved
by (lengthy)
transformation rules
(not defined for
behavior).
Package merging is
used extensively in
the UML 2.0
specification.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2 Classes and packages

Metamodel

(v4)

17

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2 Classes and packages

Design class diagram

(v4)

18

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Features

19

belong to a namespace (e.g., class or package)

Visibility kinds (no default)
visible to elements
+ public

that can access owning namespace

(by membership, import, or access)

protected

with generalization to owning namespace

package

in the same package as the owning namespace

private

in owning namespace only

are redefinable (unless decorated by { leaf })

in classes that specialize the context class
can be defined on instance or class level
isStatic

default value
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Properties
Aggregation kinds (default: none)

none

reference

shared

undefined (!)

composite

value

/ ({ derived })
{ readOnly }
{ union }
{ subsets }

{ ordered } { unique }

Collection type

OrderedSet

Sequence

Set (default)

Bag

20

can be computed from other information (default: false)

can only be read, not written (default: false = unrestricted)
union of subset properties (implies derived)
which property this property is a subset of
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Behavioral features

21

are realized by behaviors (e.g., code, state machine).

{ abstract } (virtual) behavioral features declare no behavior
behavior must be provided by specializations

Exceptions that may be thrown can be declared

Limited concurrency control

{ active } classes define their own concurrency control

active class (with own behavior which
starts on instance creation)
in passive classes:
Call concurrency kinds (no default)
{ sequential }

no concurrency management

{ guarded }

only one execution, other invocations are blocked

{ concurrent } all invocations may proceed concurrently

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Operations (1)

22

An operation specifies the name, return type, formal parameters,

and constraints for invoking an associated behavior.
pre / post

precondition constrains system state on operation invocation

postcondition constrains system state after operation is completed

{ query }: invocation has no side effects

body: body condition describes return values

{ ordered, unique } as for properties, but for return values

exceptions that may be thrown can be declared
Parameter direction kinds (default: in)
in

one way from caller

out

one way from callee

inout

both ways

return

return from callee (at most 1)

parameter name
parameter type

parameter multiplicity
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Operations (2)

23

Several semantic variation points for operations

What happens, if a precondition is not satisfied on invocation?
When inherited or redefined
invariant, covariant, or contravariant specialization?
How are preconditions combined?

No predefined resolution principle for inherited or redefined

operations

The mechanism by which the behavior to be invoked is determined from

an operation and the transmitted argument data is a semantic variation
point.
a single-dispatch, object-oriented resolution principle is mentioned
explicitly in the UML 2.0 specification

Operation invocations may be synchronous or asynchronous.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Signals and receptions

24

A signal is a specification of type of send request instances

communicated between objects.
Signals are classifiers, and thus may carry arbitrary data.
A signal triggers a reaction in the receiver in an asynchronous
way and without a reply (no blocking on sender).
A reception is a declaration stating that a classifier is prepared to
react to the receipt of a signal.
Receptions are behavioral features and thus are realized by
behavior (e.g., a state machine).

Reception

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Interfaces

25

Interfaces declare a set of coherent public features and obligations.

i.e., specify a contract for implementers (realizers)

features to be offered

Several notations for client/provider relationship

client

lollipop

joint

provider
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Templates

26

subtype polymorphism vs. parameteric polymorphism

exposed parameterable elements

Template class
(ParameterableElement)

template parameters
template binding

Bound class
(TemplateableElement)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Object diagram
InstanceSpecification

27

InstanceValue

link

Slot with
ValueSpecification

underlining and association end adornments are optional

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2 Classes and packages

Instances specifications

(v4)

28

UML metamodel

user model
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

UML 1.x vs. UML 2.0

29

Most changes from UML 1.x to UML 2.0 on the technical side
Metamodel consolidated in UML 2.0
categorization of elements by their properties
NamedElement, PackageableElement, RedefineableElement

only one level of modeling

InstanceSpecification (in contrast to Instance in UML 1.x), ValueSpecification

association ends are properties

clarification of template mechanism

Only few new modeling elements in UML 2.0

properties ({ unique, union, }) of properties
generalization sets (and powertypes)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2 Classes and packages

Wrap up

Classifiers and their Relationships describe the vocabulary of a

system.

Classifiers describe a set of instances with common Features.

StructuralFeatures (Propertys)
BehavioralFeatures (Operations, Receptions)
Associations describe structural relationships between classes.
Association ends are Propertys.

30

Generalizations relate specific Classifiers to more general Classifiers.

Packages group elements

and provide a Namespace for grouped elements.

InstanceSpecifications and links describe system snapshots.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 2a Object Constraint Language
Prof. Dr. Harald Strrle
University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2a Object Constraint Language

A first glimpse

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

History and predecessors

Predecessors
Model-based specification languages, like
Z, VDM, and their object-oriented variants; B

Algebraic specification languages, like

OBJ3, Maude, Larch

Similar approaches in programming languages

ESC, JML
History
developed by IBM as an easy-to-use formal annotation language
used in UML metamodel specification since UML 1.1
current version: OCL 2.0
specification: formal/06-05-01

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Usage scenarios

Constraints on implementations of a model

invariants on classes
pre-/post-conditions for operations
cf. protocol state machines

body of operations
restrictions on associations, template parameters,
Formalization of side conditions
derived attributes
Guards
in state machines, activity diagrams
Queries
query operations
Model-driven architecture (MDA)/query-view-transformation (QVT)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Language characteristics

Integration with UML

access to classifiers, attributes, states,
navigation through attributes, associations,
limited reflective capabilities
model extensions by derived attributes
Side-effect free
not an action language
only possibly describing effects
Statically typed
inherits and extends type hierarchy from UML model
Abstract and concrete syntax
precise definition new in OCL 2.0

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Simple types

Predefined primitive types

Boolean
Integer
Real
String

true, false
-17, 0, 3
-17.89, 0.0, 3.14
Hello

Types induced by UML model

Classifier types, like
Passenger

no denotation of objects, only in context

Status

Status::Albatros, #Albatros

Enumeration types, like

Model element types

OclModelElement, OclType, OclState

Additional types
OclInvalid
OclVoid
OclAny

invalid (OclUndefined)
null
top type of primitives and classifiers
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Parameterized types

Collection types
Set(T)
sets
OrderedSet(T)
like Sequence without duplicates
Bag(T)
multi-sets
Sequence(T)
lists
Collection(T)
abstract
Tuple types (records)
Tuple(a1 : T1, , an : Tn)
Message type
OclMessage
for operations and signals
Examples
Set{Set{ 1 }, Set{ 2, 3 }} : Set(Set(Integer))
Bag{1, 2.0, 2, 3.0, 3.0, 3} : Bag(Real)
Tuple{x = 5, y = false} : Tuple(x : Integer, y : Boolean)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Type hierarchy

Type conformance (reflexive, transitive relation )

OclVoid, OclInvalid T
for all types T
Integer Real
T T C(T) C(T)
for collection type C
for collection type C
C(T ) Collection(T )
generalization hierarchy from UML model
B OclAny
for all primitives and classifiers B
Counterexample
(Set(OclAny) OclAny)
Casting
v.oclAsType(T )
if v : T and (T T or T T )
upcast necessary for accessing overridden properties
but are (still) forbidden in the specification

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Expressions

Local variable bindings

let x = 1 in x+2
Iteration
c->iterate(i : T; a : T = e | e)
source collection
iteration variable
(bound to current value in c)

iteration expression
(using variables i and a)

accumulator with initial value e

(gathers result, returned after iteration)

Example:
Set{1, 2}->iterate(i : Integer; a : Integer = 0 | a+i) = 3

Many operations on collections are reduced to iterate

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Expressions: Standard library (1)
Operations on primitive types
operations without () are mixfix

OclAny

10

(written: v.op())

=, <>, oclIsTypeOf(T), oclIsKindOf(T),

Boolean and, or, xor, implies, not

Integer +, -, *, /, div(i), mod(i),
Real

+, -, *, /, floor(), round(),

String

size(), concat(s), substring(l, u),

Operations on collection types

(written: v->op())

Collection size(), includes(v), isEmpty(),

Set

union(s), including(v), flatten(), asBag(),

OrderedSet append(s), first(), at(i),

Bag

union(b), including(v), flatten(), asSet(),

Sequence

append(s), first(), at(i), asOrderedSet(),

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Expressions: Standard library (2)
Finite quantification
c->forAll(i : T | e)
c->exists(i : T | e)

Selecting values
c->any(i : T | e)
c->select(i : T | e)

Collecting values
c->collect(i : T | e)
c.p

11

= c->iterate(i : T; a : Boolean = true | a and e)

= c->iterate(i : T; a : Boolean = false | a or e)
some element of c satisfying e
all elements of c satisfying e
collection of elements with e applied to
each element of c
collection of elements v.p for each v in c
(short-hand for collect)

C.allInstances()

all current instances of classifier C

o.oclIsInState(s)

is o currently in state machine state s?

v.oclIsUndefined()

is value v undefined (null) or invalid?

v.oclIsInvalid()

is value v invalid?

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Evaluation

12

Strict evaluation with some exceptions

(if (1/0 = 0) then 0.0 else 0.0 endif).oclIsInvalid() = true
(1/0).oclIsInvalid() = true

Short-cut evaluation for and, or, implies

(1/0 = 0.0) and false = false

true or (1/0 = 0.0) = true
false implies (1/0 = 0.0) = true
(1/0 = 0.0) implies true = true
if (0 = 0) then 0.0 else 1/0 endif = 0.0

In general, OCL expressions are evaluated over a system state.

e.g., represented
by an object diagram

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Connection to UML

13

Import of classifiers and enumerations as types

Properties accessible in OCL
Attributes
p.milesCard

(with p : Passenger)

Association ends

p.flight, p.booking, p.booking[flight]

{ query } operations
Representation of multiplicities
a[1] : T

a:T

a[0..1] : T

a : Set(T) or T

a[m..n] : T

a : Set(T)

a[*] : T { unordered }

a : Set(T)

a[*] : T { ordered }

a : OrderedSet(T)

a[*] : T { bag }

a : Bag(T)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Invariants
context classifier

14

boolean expression

context Passenger
inv: ma.statusMiles > 10000 implies
status = Status::Albatros

Notational variants

explicit self (refers to instance of discourse)

context Passenger
inv statusLimit: self.ma.statusMiles > 10000 implies
self.status = Status::Albatros
optional name

context p : Passenger
inv statusLimit: p.ma.statusMiles > 10000 implies
p.status = Status::Albatros
replacement for self

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Semantics of invariants

15

Restriction of valid states of classifier instances

when observed from outside
Invariants (as all constraints) are inherited via generalizations
but how they are combined is not predefined
One possibility: Combination of several invariants by conjunction
context C
inv: I1
context C
inv: I2

context C
inv: I1 and I2

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Pre-/post-conditions

16

In UML models, pre- and post-conditions are defined separately

not necessarily as pairs
precondition and postcondition as constraint stereotypes

context Passenger::consumeMiles(b : Booking) : Boolean

pre: ma->notEmpty() and
ma.flightMiles >= b.flight.miles
context Passenger::consumeMiles(b : Booking) : Boolean
post: ma.flightMiles = [email protected] and
result = true
Some constructs only available in post-conditions

values at pre-condition time

result of operation call
whether an object has been newly created
messages sent

p@pre
result
o.oclIsNew()
o^op(), o^^op()
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Semantics of pre-/post-conditions

17

Standard interpretation

A pre-/post-condition pair (P, Q) defines a relation R on system states

such that (, ) R, if P and (, ) Q.
system state on operation invocation
system state on operation termination (Q may refer to by @pre).

Thus (P, Q) equivalent to (true, P@pre and Q).

Meyers contract view

A pre-/post-condition pair (P, Q) induces benefits and obligations.

benefits and obligations differ for implementer and user
obligation
user satisfy P
implementer if P satisfied, establish Q

benefit
Q established
P established
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2a Object Constraint Language

Combining pre-/post-conditions

(v4)

18

Standard interpretation

joining pre- and post-conditions conjunctively

context C::op()
post: Q1
pre: P1
context C::op()
post: Q2
pre: P2

context C::op()
pre: P1 and P2
post: Q1 and Q2

Alternative interpretation
case distinction
(like in protocol state machines)
only useful for pre-/post-condition pairs
context C::op()
post: Q1
pre: P1
context C::op()
post: Q2
pre: P2

context C::op()
pre: P1 or P2
post: (P1@pre implies Q1)
and (P2@pre implies Q2)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

Messages
context Subject::hasChanged()
post: observer^update(self)

19

in calls on hasChanged,
some update message with argument
self will have been sent to observer

context Subject::hasChanged()
post: observer^update(? : Subject)

the actual argument

does not matter

context Subject::hasChanged()
post: let messages : Set(OclMessage) =
all those
observer^^update(? : Subject)
messages
in messages->notEmpty() and
messages->forAll(m |
m.result().oclIsUndefined() and
result of message call
m.hasReturned() and
whether it has finished
m.subject = self)
its actual parameter value

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2a Object Constraint Language

Initial values and derived properties

(v4)

20

Initial values

fix the initial value of a property of a classifier

package Booking
context Passenger::status
init: Status::Swallow
endpackage

-- which package
-- which property
-- initial value

{ derived } properties

define how the value of a property is derived from other information

context Passenger::currentFlights : Sequence(Flight)
derive: self->collect(booking)
->select(date = today()).flight->asSequence()

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2a Object Constraint Language

Query bodies and model features

(v4)

21

Bodies of { query } operations

define the value returned by a query operation
can be combined with a precondition
context TravelHandling::delay() : Minutes
body: tsh.delay->sum()

Definition of additional model features

defined for the context classifier
context TravelStageHandling
def: isEarly() : Boolean = self.delay < 0
context TravelHandling
def: someEarly() : Boolean = tsh->exists(isEarly())

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2a Object Constraint Language

UML/OCL 1.x vs. UML/OCL 2.0

22

Improvements in OCL 2.0

Model extensions by definitions

Explicit flattening of collections
Clarification of type hierarchy
Precise abstract and concrete syntax
Formal semantics

but only as a non-normative appendix

New features in OCL 2.0

Specification of initial values, derived attributes

Specification of messages

(still) Open problems

semantics of definitions
inheritance, recursion

semantics of pre-/post-conditions

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2a Object Constraint Language

Wrap up

(v4)

23

Formal language for specifying

invariants
pre-/post-conditions

query operation bodies

initial values
derived attributes
modeling attributes and operations

context C inv: I
context C::op() : T
pre: P post: Q
context C::op() : T body: e
context C::p : T init: e
context C::p : T derive: e
context C def: p : T = e

Side-effect free
Typed language
OCL specifications provide
verification conditions
assertions for implementations
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 2b Profiles

Dr. Harald Strrle

University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2b Profiles
A first glimpse

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2b Profiles
Usage scenarios

Metamodel customization for

adapting terminology to a specific platform or domain
adding (visual) notation
adding and specializing semantics
adding constraints
transformation information
Profiling
packaging domain-specific extensions
domain-specific language engineering

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2b Profiles
Stereotypes (1)

Stereotypes define how an existing (UML) metaclass may be

extended.
optional
extension

Stereotypes may be applied textually or graphically.

lower-case initial

The UML specification does not tell how to define a

visual stereotype.
Visual stereotypes may replace original notation.

But the element name should appear below the icon

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2b Profiles
Stereotypes (2)

(v4)

Stereotypes may define meta-properties.

commonly known as tagged values
Stereotypes can be defined to be required.
Every instance of the extended metaclass has to be extended.
If a required extension is clear from the context it need not be
visualized.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2b Profiles
Profiling

(v4)

Profiles package extensions.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2b Profiles
Metamodel

Based on infrastructure library constructs

Class, Association, Property, Package, PackageImport

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2b Profiles
Metamodeling with Profiles

Profile extension mechanism imposes restrictions on how the UML

metamodel can be modified.
UML metamodel considered as read only.
No intermediate metaclasses, no meta-associations
As part of a profile, it is not possible to have an association
between two stereotypes or between a stereotype and
metaclass.
Stereotypes metaclasses below UML metaclasses.
How to introduce meta-associations between stereotypes?
1. Add constraints specializing some existing associations
2. Extend metaclass Dependency by a stereotype and define
specific constraint on this stereotype
Access to stereotypes in OCL via v.stereotype

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2b Profiles
UML 1.x vs. UML 2.0
UML 1.x

UML 2.0

String-based extension
mechanism
Stereotypes
Tagged values

Stereotypes are metaclasses

Tagged values replaced by
meta-properties

Required extensions
Packaging of extensions into
profiles

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2b Profiles
Wrap up

10

Metamodel extensions
with stereotypes and meta-properties
for restricting metamodel semantics
for extending notation
Packaging of extensions into profiles
for declaring applicable extensions
domain-specific language engineering

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 2c Systems Modeling Language
(SysML)
Prof. Dr. Harald Strrle
University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2c SysML
SysML as an example for a UML profile

(v4)

Nowadays very much talked

about: Systems Modeling
Language (SysML).
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

2c SysML
SysML vs. UML
Protracted struggle between two
competing proposals fueld by
massive commercial interests.

(v4)

outside of what can be

described with UML means?

New standard ptc/06-05-04

finally adopted by OMG just now
(May 2006).
Apart from mere customization to
match systems engineering
standards and terminology, it also
introduces some physical aspects:
continuous flows,
handling of physical items.
official OMG diagram

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2c SysML
Diagram tpes of SysML
significant new aspects:
-item flow
-continuous variables
-activation disabling
- control operators

class diagram

assembly diagram
official OMG diagram

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

2c SysML
Wrap up

Tries to extend UML towards systems engineering, i.e.

physical/continuous systems.
Probably the most talked about and largest UML profile.
After a long and fierce debate, now finally OMG approved.
Semantics completely unclear, seems to go even more into the
direction of Petri-nets.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 3 - Use Cases
Prof. Dr. Harald Strrle
University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

3 - Use Cases
A first glimpse

(v4)

Displayed aspects
System boundary and context of system
Users and neighbor systems
Functionalities
Relationships between functionalities (calling/dependency, taxonomy)
Functional requirements
Some non-functional (quality) requirements as comments/annotations
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

3 - Use Cases
History and predecessors

(v4)

1970s
Structured methods (SADT etc.) use top-level DFD as context
diagram
Structured methods use function trees
1980s
Jacobson (Objectory) introduces the concept of use case as an aid
for communicating with domain experts
1997
UML 1.3 encompasses Use Cases

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

3 - Use Cases
Usage scenarios

Use case inventory/ domain architecture

complete catalog of all subdomains and (groups of)
business processes and business functions
overview of systems (domain) capabilities
Classical use cases
illustrate context of individual functionality
useful in design/documentation of business processes
(i.e. analysis phase and reengineering)
Use Case / Test case table
schematic detail description of business
process/function/test case
Function tree
describe functional decomposition of system behavior
useful for non-OO construction and for re-architecting
pre-OO systems

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

3 Use Cases
Types of use cases

(v4)

The UML provides only the concept of use case. In many

applications, however, there are two fundamentally different kinds of
use cases:
business processes (processes)

white box, large scale, long running (suspendable), customized processes

either dialogue or batch processes
directly support the business or domain of the system, create or destroy value
are subject to rearrangement when business changes
may contain some manual steps and business functions

business functions (services)

black box, small(er) scale, short(er) running, atomic, reusable function

small recurring functionality, plausibility, user dialogue, interface call, . . .
implements stable functionality likely not to be affected by business changes
is executed fully automatic
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

3 - Use Cases
Main concepts (concrete syntax)

Class (also possible: Component)

Actor

UseCase
extends
(is a Dependency)

Association
includes
(is a Dependency)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

3 - Use Cases
Inclusion & extension

(v4)

Inclusion
plain old call
directed from caller to callee
may occur once or many times

Extension
covers variant or exceptional
behavior
relationship is directed from
exception to standard case
may or may not occur
occurs at most once

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

3 - Use Cases
Extension points
An extension occurs at a (named)
ExtensionPoint, when a specific
condition is satisfied.

ExtensionPoint

In a way, ExtensionPoints are

similar to user exits or hooks.

In real world systems, there are

many ExtensionPoints, most of
which are poorly documented.

UseCase with ExtensionPoint,

alternative syntax suitable for
large numbers of ExtensionPoints

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

3 - Use Cases
Any level of abstraction is ok

(v4)

A use case represents an individual

functionality of a system.
Systems exist on every level of
granularity.
Thus, use cases may be used for
functionality of any granularity :
from high level business
processes,
via (web) services,
to individual methods or
functions.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

3 - Use Cases
Emulating function trees

(v4)

10

Structured methods relied on

functional decomposition.
Although this is not state of the art
these days, and UseCases have
been introduced in an attempt to
get away from it:
many systems out there are
constructed using these
principles,
many people out there have
this mindset.
For e.g. reengineering purposes, it
is frequently helpful to be able to
represent function trees.
This can be done using UseCases
and Includes-Relationships.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

3 - Use Cases
Generalization

(v4)

11

As for all Classifiers, UseCases

may be arranged in taxonomic
hierarchies.
This is particularly useful for
catalogues of functionalities.

From methodological point of

view, abstract use cases are similar
to functional subsystems.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

3 - Use Cases
Semantics

(v4)

12

Use cases have no semantics in UML.

There are many consistency conditions in conjunction with other
models, but thats methodology, and beyond the scope of this
tutorial.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

3 - Use Cases
UML 1.x vs. UML 2.0

(v4)

13

no changes conceptually
slight adaptations in the metamodel

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

3 - Use Cases
Wrap up

14

Use cases may be used to represent a high-level view of

functionality, as in
functionality overview / domain architecture
detail description of context of individual use case
function tree (particularly for reengineering and documentation
purposes)
The UML still does not come with a (textual) schema for describing
use cases.
Basically, use cases in UML 2.0 are the same as in UML 1.x.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 4 - Architecture
Prof. Dr. Harald Strrle
University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

4 - Architecture
A first glimpse

Context & domain architecture

Composite structure
(assembly) diagrams

Deployment
Collaboration

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

4 - Architecture
History and Predecessors

Context and domain architecture diagram

1970s: SADT et al. use top level DFD as context diagram
1988: Shlaer/Mellor introduce domain chart
Part/port/connector-concepts, composite structure (assembly) diagram
1976: SDL
(block/gate/channel)
1978: SARA
(module/socket/interconnection)
1993: RAPIDE
(module/type/binding)
1994: ROOM
(actor/port/connector)
1999: UML/RT, (capsule/port/connector)
2000: UML 1.3
(subsystem/-/-)
collaboration
1997: Catalysis (DSouza, Wills)
computing system structure diagram (deployment)
traditional
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Usage Scenarios / Architectural views

Context diagram
define the systems boundaries in terms of its users and neighbor
systems
define names/abbreviations for systems and neighbor systems

Domain architecture
provide overview of high-level domain components
define names/abbreviations for subsystems

Composite structure diagram (system assembly diagram)

define ports (system interfaces) with names and abbreviations
define connections between interfaces

Composite structure diagram (class assembly diagram)

as above on fine level of granularity
define (programming language) interfaces for ports, too

Collaboration
document design decisions (patterns) on any level of granularity

System structure diagram

physical nodes and connections between them

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Main concepts: Composite structure diagrams

(v4)

better name: assembly diagrams

Actor
Port
with visual
stereotype

Part
with visual
stereotype

Part
a system as a
Class or a
Component

Port
interface
of a Part

Connector
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Usage: Stepwise refinement

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Usage: Quantity structures

(v4)

Quantity structures are

indispensable for the dimensioning
of large systems:
numbers of (concurrent) users,
amount of data traffic on a
given interface,
availability, MTBF,
number of (collaborating)
systems or components
(dynamic architectures).
Quantity structures are not
covered directly in UML so we need
to use comments (but thats no
problem).

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Usage: Plumbing components together

(v4)

Connecting Ports amounts to

delegate/call-Dependencies.

Using the joint-notation reveals

details about the number and
direction of connections.
From left to right:
two connectors, one in each
direction
one connector with direction
and one connector without
direction.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Components

(v4)

UML 1.x components were just binaries. In UML 2.0, components are
defined much more comprehensively.
A component represents a modular part of a system that
encapsulates its contents and whose manifestation is replaceable
within its environment.
A component defines its behavior in terms of provided and
required interfaces. As such, a component serves as a type,
whose conformance is defined by these provided and required
interfaces (encompassing both their static as well as dynamic
semantics). One component may therefore be substituted by
another only if the two are type conformant. []
A component is modeled throughout the development life cycle
[].
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

4 - Architecture
Metamodel: Parts and ports

10

dashed outlines:
defined in another package
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Collaboration

(v4)

11

The purpose of collaborations is to

abstractly describe a form of
linkage without being specific.
Declared as the way to describe
design and analysis patterns.
Might help in early stages of
architectural design.
Could also be used to describe
global constraints.
May be nested and composed.
Methodologically, Collaborations
are the structural equivalent to
UseCases.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

4 - Architecture
System structure
Node

12

CommunicationPath
is a kind of
Association

Comment
for quantitative information

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Stereotyping

(v4)

13

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

4 - Architecture
Deployment

14

A Deployment is a mapping of
artifacts to system nodes.
Artifacts may include

Artifact

binaries
component instances

System nodes may include

hardware (Device)
software (ExecutionEnvironment)

Formally, a deployment is a
Deployment Relationship.
It may be presented either as
placing the deployed items or their
names on the deployment target.

Node may be specialized to either

Device or
ExecutionEnvironment
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Metamodel: Deployment

dashed outlines:
defined in another package

(v4)

15

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

4 - Architecture
Semantics

16

Mappings from assemblies to Architecture Description Languages

(ADLs) or SDL should be possible. Is it much use? Can there be a
uniform semantics for all kinds of ADLs?
Collaborations seem to have no formal semantics.
System structures may be mapped to quantitative models for
analytical purposes.
Deployments might be turned into deployment descriptors of
application servers.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

4 - Architecture
UML 1.x vs. UML 2.0
UML 1.x

UML 2.0

system boundary

Parts/Ports

17

artifacts
components are binaries

components are life cycle units

patterns as templates

patterns (=collaborations) are now

first class citizens

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

4 - Architecture
Wrap up

(v4)

18

Popular concepts of architectural modeling (capsule/actor, port)

have finally been included into UML. The metamodeling is a little
dodgy, though.
Deployments, artifacts and related concepts have been extended,
and they are now first-class citizens.
Components have finally got a decent definition as life cycle units,
artifacts and deployments are now first-class citizens.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 5 - Activities

Prof. Dr. Harald Strrle

University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 - Activities
A first glimpse

(v4)

Activity diagrams present all kinds of control flow and data flow.
They are kind of dual to state machines: focus is on actions rather than
states.
The UML 1.x notation has been kept (with a different meaning), and much
extended.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 - Activities
History and predecessors

1962
Petri-nets
1969
Flow charts (IBM, ISO)
1970s
Nassi-Shneiderman-diagrams
1980s
Structured Methods (SADT etc.) introduce data flow diagrams
Methodologies like IDEF are based on these notations
1990s
event process chains (particularly in BPR & SAP R/3 context)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 - Activities
Usage scenarios

Activity diagrams have applications throughout the whole

software life cycle for many purposes.
Analysis
design or document processes in the application
domain (business processes)
Design
design or document processes as compositions of
preexisting elements like manual tasks or automated
jobs
Implementation
document existing programs (i.e. functions, services, )
design algorithmic processes with an intention of
turning them into implementation language code
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 - Activities
Main concepts

InitialState
ObjectNode

ActivityNode

ObjectFlow
ActivityEdge

ForkNode

DecisionNode

MergeNode
JoinNode

Partition

FinalState
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 - Activities
Main concepts

stereotyped
ObjectNode

Partitions
may be represented
explicitly

refined Activity

FlowFinal

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 - Activities
Pins

Data flow may be represented

explicitly,
by dataflow nodes attached to control flow,
by Pins on Activities, or
as combinations.
Pin

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 - Activities
Activity parameters

(v4)

Pins act as parameters for Activities.

ActivityParameter

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 - Activities
Pin types

(v4)

Pin type
a) streaming
b) streaming
c) exception
d) unidirectional
e) collection data
ParameterSet may be used to define applicable sets of parameters
Parameter sets
a) {x, y}
b) {x}, {y}
c) {x}, {x, y}

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 - Activities
Data flow details

(v4)

10

Data flow defines the transport of

data items between buffers by
activities.
Buffers may have capacities and
orderings.

Apart form the transport as such,

data flow may also define
selection of a particular data
item, and
transformation of data items.
It is often useful to denote the
state of a data item in a buffer.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 Activities
Streaming

(v4)

11

Streaming means that data is

processed pipeline-style.
Streaming-like behavior was not
expressible in UML 1.x.
Streaming is expressed by
solid black pins
explicit annotation at pins
black arrowhead arcs, or
stream mode at expansion
regions.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 - Activities
Exceptions

12

ExceptionEdge

unhandled
Exception

handler Activity

Exception
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 - Activities
Raising exceptions

13

InterruptibleActivityRegion

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 - Activities
Expansion regions for mass data processing

(v4)

14

Activities are often used to specify

processing of mass data (batch
runs) rather than individual items.
UML offers ExpansionRegions to
support this usage scenario.

An expansion region declares a

portion of an activitiy as applicable
to a whole bunch of items.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 - Activities
Expansion Regions
An

15

expansion region may be processed in one of three modes

iterative,
concurrent,
stream.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 - Activities
Structured nodes

(v4)

16

Structured nodes for

sequence,
loop,
conditional.
No/insufficient syntax (let alone semantics) defined by standard.
Were probably best of with a Nassi-Shneiderman-like notation.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 - Activities
Metamodel

(v4)

17

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 Activities
Semantics

(v4)

18

The standard declares Petri-like

semantics. The naive approach is
intuitive for simple control and
data flow
reasonable for structured
nodes
technically difficult for
exceptions
a little awkward for streams
and ExpansionRegions.
There are a number of semantical
problems, though, and integrating
the bits and pieces is a challenge.
Still, it is the most convincing
approach so far.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 Activities
Semantics: Petri-net vs. CCS

e
h
t
t
o
p
S

19

!
r
ro
r
e

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 Activities
Problem 1: Scope of exceptions

(v4)

20

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 Activities
Problem 2: Accidental synchronization of streams

21

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 Activities
Problem 3: Traverse-to-completion

(v4)

22

Transforming an Activity into a Petri-net following the naive

approach results in artificial places that have no direct equivalent in
the underlying Activity.
The UML, however, disallows buffering in control nodes.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

5 - Activities
Semantics

(v4)

23

The standard declares that activities have a Petri-like semantics,

but lacks a formal definition of what that means.
A straight-forward approach of mapping activities to Petri-nets soon
runs into a semantic quagmire.
Other algorithmic target languages (e.g. BPEL or Workflow Execution
Languages), and other formalisms (e.g. CCS) would encounter the
same problems, plus their own.
Abstract descriptions using special-purpose logics are only at the
beginning.
Many open questions that will trouble us for some time to come.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 Activities
UML 1.x vs. UML 2.0
UML 1.x

ActivityGraph subclass of StateMachine

thus implicit rtc-semantics

24

UML 2.0

Activity on same level as StateMachine

new Petri-like semantics

Many new concepts

Exceptions

InterruptibleActivityRegion
ExceptionEdge, ProtectedNode

StructuredNodes
FlowFinal
Streaming
Collection data
ActivityParameters

Many new notations

Pins, attached dataflow
notation,
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

5 - Activities
Wrap up

25

Presents control flow and data flow for analysis, design, and implementation
level models.
Not a special kind of StateMachine any more.
Petri-net inspired semantics, though currently not entirely clear.
Many new concepts and notations, including
Exception handling
Data streaming
Collection data handling
Structured nodes (loops, expansion regions)
Pin-notation for dataflow.
Overall: Activity diagrams are now the algorithmic description language
not only within the UML.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 6 State machines
Dr. Harald Strrle
University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
History and predecessors

(v4)

1950s: Finite State Machines

Huffmann, Mealy, Moore
1987: Harel Statecharts
conditions
hierarchical (and/or) states
history states
1990s: Objectcharts
adaptation to object orientation
1994: ROOM Charts
run-to-completion (RTC) step
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Usage scenarios

Object life cycle

Behavior of objects according to business rules
in particular for active classes
Use case life cycle
Integration of use case scenarios
Alternative: activity diagrams
Control automata
Embedded systems
Protocol specification
Communication interfaces
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
States and transitions

State machines model behavior

using states interconnected
with transitions triggered
by event occurrences.
initial Pseudostate

simple State

trigger (CallEvent)

Transition

guard (Constraint)

effect (CallAction)

FinalState

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Relation to class diagrams

(v4)

State machines are defined in the context of a BehavioredClassifier.

Context
defines which
events can
occur
features are
available

Operation
corresponding CallEvent
CallAction
called Operation

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Triggers and events (1)

(v4)

SignalEvent

deferred
event

TimeEvent

(relative)

completion
event
(no explicit
trigger)

ChangeEvent

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Triggers and events (2)

CallEvent
receipt of a (a)synchronous Operation call
triggering after Behavior of Operation executed

SignalEvent
receipt of an asynchronous Signal instance
reaction declared by a Reception for the Signal

TimeEvent
absolute reference to a time point (at t)
relative reference to trigger becoming active (after t)

presumably meaning relative to state entry

ChangeEvent
raised each time condition becomes true

may be raised at some point after condition changes to true

could be revoked if condition changes to false
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Triggers and events (3)

completion event
raised when all internal activities of a state are finished
do activity, subregion
no metamodel element for completion events

dispatched before all other events in the event pool

deferred events
events that cannot be handled in a state but should be kept in
the event pool
reconsidered when state is changed
no predefined deferring policy

internal transitions
are executed without leaving and
entering their containing state

normally, on transition execution states are left and entered

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Behaviors

(v4)

exit Behavior
(on exiting a state)
do activity Behavior
(concurrently while
in state, may be
interrupted)

entry Behavior
(on entering a state)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
How state machines communicate
event pool

during
run-to-completion (RTC)

(v4)

10

event pool

network

starts new RTC-step

signals: asynchronous (no waiting)

calls: asynchronous or synchronous (waiting for RTC of callee)
No assumptions are made on timing between
event occurrence, event dispatching, and event consumption.
Event occurrences for which no trigger exists may be discarded
(if they are not deferred).
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Hierarchical states (1)

(v4)

11

Hierarchical states allow to encapsulate behavior and facilitate reuse.

However, they are rarely used this way.
UML 2.0 provides concepts supporting this usage.
entry and exit points

composite State
Transition triggering is prioritized inside-out, i.e., transitions deeper in the hierarchy
are considered first.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Hierarchical states (2)

12

detailed
(non-orthogonal)
composite State
default entry
Region
substates

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Orthogonal regions

13

Simple State: containing no Region

Composite State: containing at least one Region
- simple composite State: exactly one
- orthogonal composite State: at least two

orthogonal Regions,
both active if
Client/Server active

orthogonal states are concurrent as a single event may trigger a transition

in each orthogonal region simultaneously

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Forks and joins
all Regions must be
entered simultaneously

14

all Regions are left

simultaneously

(if FinalStates are reached)

join Pseudostate

(restrictions dual to forks)

fork Pseudostate

(one incoming, at least two outgoing Transitions;

outgoing Transitions must target States in different Regions of an orthogonal State)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Entry and exit points (1)

15

Entry and exit points (Pseudostates)

provide better encapsulation of composite states
help avoid unstructured transitions
exit point (on border of state machine
diagram or composite state)

entry
point
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Entry and exit points (2)

(v4)

16

Notational alternatives

Semantically equivalent

unstructured transitions
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
History states

(v4)

17

History states represent the last active

substate
(shallow history), or
configuration (deep history)
of a region.
shallow history Pseudostate
(enter last State in this Region)

deep history Pseudostate

(enter last States in this Region
and all sub-Regions)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Metamodel

(v4)

18

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Run-to-Completion Step: Overview

(v4)

19

Choose an event from the event pool (queue)

Choose a maximal, conflict-free set of transitions enabled by the event
Execute set of transitions
exit source states (inside-out)
execute transition effects
enter target states (outside-in)
thereby generating new events and activities
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Run-to-Completion Step: Preliminaries (1)

(v4)

20

Active state configuration

the states the state machine currently is in
forms a tree

if a composite state is active, all its regions are active

Least-common-ancestor (LCA) of states s1 and s2

the least region or orthogonal state (upwards) containing s1 and s2

bold: active state configuration

bold: LCA of states A1 and A2

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Run-to-Completion Step: Preliminaries (2)

(v4)

21

Compound transitions
transitions for an event are chained into compound transitions
eliminating pseudostates like junction, fork, join, entry, exit
this is not possible for choice pseudostates where the guard of outgoing
transitions are evaluated dynamically (in contrast to junctions)

several source and target states

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
Run-to-Completion Step: Preliminaries (3)

(v4)

22

Main source / target state m of compound transition t

Let s be LCA of all source and target states of t

If s region: m = direct subvertex of s containing all source states of t
If s orthogonal state: m = s
Similarly for main target state
All states between main source and explicit source states are exited, all
state between main target and explicit target states are entered.

Conflict of compound transitions t1 and t2

intersection of states exited by t1 and t2 not empty
Priority of compound transition t1 over t2
si deepest source state of transition ti
s1 (direct or transitive) substate of s2
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Run-to-Completion Step (1)

23

RTC(env, conf )
event fetch()
step choose steps(conf, event)
if step = event deferred(conf )
then defer(event)
fi
for transition step do
conf handleTransition(env, conf, transition)
od
if isCall (event) event deferred(conf )
then acknowledge(event)
fi
conf
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Run-to-Completion Step (2)

24

steps(env, conf, event)

transitions enabled(env, conf, event)
{step | (guard, step) steps(conf, transitions) env guard }
steps(conf, transitions)
steps {(false, )}
for transition transitions do
for (guard, step) steps(conf, transitions \ {transition}) do
if inConflict(conf, transition, step)
then if higherPriority(conf, transition, step)
then guard guard guard(transition) fi
else step step {transition}
guard guard guard(transition) fi
steps steps {(guard, step)} od od
steps
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Run-to-Completion Step (3)

25

handleTransition(conf, transition)
for state insideOut(exited(transition)) do
uncomplete(state)
for timer timers(state) do stopTimer(timer) od
execute(exit(state))
conf conf \ {state}
od
execute(effect(transition))
for state outsideIn(entered(transition)) do
execute(entry(state))
for timer timers(state) do startTimer(timer) od
conf conf {state}
complete(conf, state)
od
conf
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Semantic variation points

26

Some semantic variation points have been mentioned before.

delays in event pool
handling of deferred events
entering of composite states without default entry
Which events are prioritized?
Completion events only
All internal events (completion, time, change)
Which (additional) timing assumptions?
delays in communication
time for run-to-completion step
zero-time assumption

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

6 State machines
State machine refinement
State machines are
behaviors and may thus
be refined.

no refinement possible

(v4)

27

not refined
(may be omitted)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Protocol state machines

28

Protocol state machines specify which behavioral features of a

classifier can be called in which state and under which condition and
what effects are expected.
particularly useful for object life cycles and ports
no effects on transitions, only effect descriptions

precondition
specified operation
postcondition
ProtocolTransition
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Protocol state machines

29

Several operation specifications are combined conjunctively:

context C::op()
pre: inState(S1) and P1
post: Q1 and inState(S3)
context C::op()
pre: inState(S2) and P2
post: Q2 and inState(S4)
results in
context C::op()
pre: (inState(S1) and P1) or (inState(S2) and P2)
post: (inState@pre(S1) and P1@pre) implies (Q1 and inState(S3))
and (inState@pre(S2) and P2@pre) implies (Q2 and inState(S4))
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
UML 1.x vs. UML 2.0

30

Consolidated metamodel
introduction of regions instead of composite states only
no transitions between regions of an orthogonal state
the more esoteric case of UML 1.x

New encapsulation means

entry and exit points
Protocol state machines
side-effect free
Clarification of semantic variation points
but, still, no formal semantics

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
How things work together

31

Static structure
sets the scene for state machine behavior
state machines refer to
properties
behavioral features (operations, receptions)
signals

Interactions
may be used to exemplify the communication of state machines
refer to event occurrences used in state machines
OCL
may be used to specify guards and pre-/post-conditions
refers to actions of state machines (OclMessage)
Protocols and components
state machines may specify protocol roles
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

6 State machines
Wrap up

32

State machines model behavior

object and use case life cycles
control automata
protocols
State machines consist of
Regions and
(Pseudo)States (with entry, exit, and do-activities)
connected by Transitions (with triggers, guards, and effects)
State machines communicate via event pools.
State machines are executed by run-to-completion steps.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 7 - Interactions
Dr. Harald Strrle

University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
A first glimpse

(v4)

sequence diagram

communication
diagram

all three are

semantically
equivalent

timing diagram

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Interactions
History and predecessors

simple sequence diagrams

1990s

Message Sequence Charts (MSCs) used in TelCo-industry

several OO-methods use sequence diagrams

complex sequence diagrams

1996: Complex MSCs introduced in standard MSC96
1999: Life Sequence Charts (LSCs)

communication diagrams
1991: used in Booch method
1994: used in Cook/Daniels: Syntropy

timing diagrams
traditionally used in electrical engineering
1991: used in Booch method
1993: used in early MSCs

interaction overview
1996: high-level MSCs (graphs of MSCs as notational alternative)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Interactions
Usage scenarios

Class/object interactions
design or document message exchange between objects
express synchronous/asynchronous messages, signals
and calls, activation, timing constraints
Use case scenarios
illustrate a use case by concrete scenario
useful in design/documentation of business processes
(i.e. analysis phase and reengineering)
Test cases
describe test cases on all abstraction levels
Timing specification/documentation
Interaction overview
organize a large number of interactions in a more visual
style
defined as equivalent to using interaction operators
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Interactions
Syntactical variants

Sequence diagram
traditional sequence diagrams + interaction operators
focuses on exchanging many messages in complex patterns
among few interaction partners

Communication diagram
collaboration diagram in UML 1.x
focuses on exchanging few messages between (many)
interaction partners in complex configuration

Timing diagram
new in UML 2.0, oscilloscope-type representation, not
necessarily metric time
focuses on (real) time and coordinated state change of
interaction partners over time

Interaction overview diagram

looks like restricted activity diagram, but isnt
arrange elementary interactions to highlight their interaction

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Simple Interactions
Main concepts

Interaction
partner
Lifeline

OccurrenceSpecification
aka. EventOccurrence

reply

call

asynchronous signal

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Simple Interactions
Message types

instantiation Event

termination Event

lost & found Messages

(i.e.: very slow messages)

non-instantaneous
Message

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Simple Interactions
Activation

external
Event
activation bar
activation
suspended

warp lines
(non-UML)

nested activation
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Usage: Use case scenarios

(v4)

Interaction participants
are actors and systems
rather than classes and
objects.
May be refined
successively.
Useful also for specifying
high-level non-functional
requirements such as
response times.
All kinds of interaction
diagrams may be applied,
depending on the
circumstances.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Usage: Class interactions

(v4)

10

Interaction participants are

classes and objects rather
than actors and systems.
Again, successive refinement
may be applied in different
styles:
break down processing of
messages
break down structure of
interaction participants.
All kinds of interaction
diagrams may be applied,
depending on the
circumstances.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Interactions
Usage: Test cases

11

Like any other interaction, but with a different intention.

Typically accompanied by a tabular description of purpose, expected
parameters and result (similar to use case description).

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Usage: Timing specification

(v4)

12

For embedded and real-time

systems, it may be important to
specify absolute timings and state
evolution over time.

This is not readily expressed in

sequence diagrams, much less
communication diagrams.

UML 2.0 introduces timing

diagrams for this purpose.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Abstraction in timing diagram

(v4)

13

An alternative syntax presents

states not on the vertical axis but
as hexagons on the lifeline.
Timing diagrams present the
coordination of (the states of)
several objects over (real) time.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Interactions
Usage: Interaction overview

14

Organize large number of interactions in a more visual style

Defined as equivalent to using interaction operators

sequence probably
equivalent to seq

choice/merge
equivalent to alt/opt

also allowed: fork/join

(said to be equivalent to par, but )
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Complex interactions

(v4)

15

A complex interaction is like a functional expression:

an InteractionOperator,
one or several InteractionOperands (separated by dashed lines),
(and sometimes also numbers or sets of signals).
Interaction
Operator
Interaction
Fragment
Interaction
Operand

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Interactions
Interaction operators (overview)

strict
operand-wise sequencing
seq
lifeline-wise sequencing
loop
repeated seq

par
interleaving of events

region (aka. critical)

suspending interleaving

consider
restrict model to specific messages
i.e. allow anything else anywhere
ignore
dual to consider

ref
macro-expansion of fragment

alt
alternative execution
opt
optional execution
syntactic sugar for alt
break
abort execution
sometimes written as brk

16

assert
remove uncertainty in specification
i.e. declare all traces as valid
neg
declare all traces as invalid
( three-valued semantics)
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Main concepts (metamodel)

(v4)

17

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Interactions
Semantics
The meaning of an interaction is
a set of valid traces, plus
a set of invalid traces.
(ignore the latter for the time being)

Traces are made up of occurrences

of events such as
sending/receiving a message,
instantiating/terminating an
object, or
time/state change events.
Two types of constraints determine
the valid traces:
1) send occurs before receive,
2) order on lifelines is definite.

a
b

d
e

18

This diagram contains the following

seven constraints:
1) ad, eb, fc
2) ab, bc, de, ef
The set of resulting traces is:
{ a.d.e.b.f.c, a.d.e.f.b.c }.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Interaction operators seq & strict

(v4)

19

seq
compose two interactions sequentially lifeline-wise (default!)
strict
compose two interactions sequentially diagram-wise

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Interactions
Interaction operator loop

20

loop
repeated application of seq
loop(P, min, max)
= seq(P, loop(P, min-1, max-1))
loop(P, 0, max)
= seq(opt(P), loop(P, 0, max-1))
loop(P, *)
= seq(opt(P), loop(P, *))
for some interaction
fragment P

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Interaction operators: interleaving

(v4)

21

par
shuffle arguments
region
execute argument atomically, i.e. disallow interleaving

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Interaction operators alt, opt, brk: choice

(v4)

22

alt
alternative complete execution of one of two interaction
fragments
opt
optional complete execution of interaction fragment:
opt(P) = alt(P, nop)
break
execute interaction fragment partially, skip rest, and jump to
surrounding fragment

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Interaction operators: abstraction

(v4)

23

ignore, consider
dual way of expressing:

allow the ignorable messages (!) anywhere

present only those messages that are to be considered
ignore(P,Z) = shuffle(P, Z*)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 Complex Interactions
Interaction operator ref & parameters

(v4)

24

ref
refers to a fragment defined elsewhere (macro-expansion)
Formal and actual parameters (bindings) are declared in the
diagram head.
declaration

call

Signals to the containing classifier appear as arrows form the

diagram border.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

7 - Interactions
Interaction operators: negation

(v4)

25

The semantics of neg and assert is unclear.

In contrast to that the other operators, they refer not just to the
positive traces, but to invalid and inconclusive traces as well.

neg
declare all valid traces as invalid
inconclusive traces: unknown
assert
remove uncertainty by declaring all inconclusive traces as invalid
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 - Interactions
UML 1.x vs. UML 2.0
UML 1.0

UML 2.0

collaboration diagram

communication diagram

26

timing diagram
interaction overview diagram
complex interaction
Lifeline is now a first-class citizen

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

7 Interactions
Wrap up

27

Complex interactions like high-level MSCs added.

New diagram types:
timing diagrams (like oscilloscope), and
interaction overview (similar to restricted activity diagram)
renamed collaboration diagram to communication diagram
Completely new metamodel.
Almost formal three-valued semantics of valid, invalid and
inconclusive interleaving traces of events.
Some semantical problems are yet to be solved.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 8 Tools

Dr. Harald Strrle

University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

8 Tools
Overview
UML 2.0 modeling tools
subjective selection for test
not an evaluation
What has been covered
UML 2.0 diagrams
UML 2.0 metamodel
import/export
special features
There are many more, like
Omondo: Omondo for Eclipse
Sparx Systems: Enterprise Architect

Rhapsody
TAU
MagicDraw
Software
Modeler
Poseidon
Together
Architect

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

8 Tools
I-Logix: Rhapsody

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

8 Tools
I-Logix: Rhapsody

Tested version: Rhapsody V6.0 in C++

mainly targeted on embedded systems design and real-time
operation systems
Fair UML 2.0 support
but sometimes deviating terminology
Nice features
code generation based on templates
mainly for state machines

support for structured analysis/design

www.ilogix.com
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

8 Tools
Telelogic: TAU/Developer

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

8 Tools
Telelogic: TAU/Developer

(v4)

Tested version: TAU V2.4

Fair UML 2.0 support
import from XMI (Rose, Together)
Nice features:
code generation based on libraries
continuous consistency checks
some messages not overly instructive

UML 2 textual syntax

www.telelogic.com
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

8 Tools
NoMagic: MagicDraw

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

8 Tools
NoMagic: MagicDraw

Tested version: MagicDraw 11.5 Enterprise

Very good UML 2.0 support
sometimes deep nesting of property sheets
export as XMI 2.1, EMF
Nice features
OCL syntax check
but not more

metamodel-based model comparison

model metrics

www.nomagic.com
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

8 Tools
IBM: Rational Software Modeler

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

8 Tools
IBM: Rational Software Modeler

10

Tested version: Rational Software Modeler Trial

Good UML 2.0 support
some features are deep down in property sheets
export as UML2 (XMI 2.0), EMF,
Nice features
Integrated into Eclipse
ensures consistency by selection from available features and
drawing restrictions
but not for constraints

www.ibm.com/rational
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

8 Tools
Gentleware: Poseidon

(v4)

11

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

8 Tools
Gentleware: Poseidon

12

Tested version: Poseidon 4.2.1 community edition

professional versions include code generation, version control,
Eclipse integration,
Good UML 2.0 support
but no templates, composite structures,
export as XMI 1.2
Nice features
UML 2.0 diagram interchange
Community edition for free
www.gentleware.com
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

8 Tools
Borland: Together Architect

(v4)

13

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

8 Tools
Borland: Together Architect

14

Tested version: Together Architect 2006, version 8.0

Fair UML 2.0 support
export as XMI 2.0
Nice features
Eclipse integration
Good OCL support

OCL-based model transformations

ECore API

www.borland.com
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

8 Tools
Comparison (1)
Rhapsody

TAU/
Developer

Magic
Draw

Software
Modeler
Trial

Poseidon
CE

Together
Architect

Class

Composite
structure

Component

Object

Deployment

Package

15

good (all important features present)

average (some important features missing)

not available
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

8 Tools
Comparison (2)
Rhapsody

TAU/
Developer

Magic
Draw

Software
Modeler
Trial

Poseidon
CE

Together
Architect

Activity

Use case

State machine

Sequence

Communication

Interaction
overview

Timing

16

good (all important features available)

average (some important features missing)

not available
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

8 - Tools
Which one is best for me?

17

Many tools claim to support UML (or even UML 2.0), but few do
justice to this claim.
Of those that come anywhere close to UML 2.0, there is no single
best tool.
If you want to select a tool for you, your company, or your
organization, go ahead as follows.

Make a short list of 3-6 candidate tools following crude criteria like
price, platform, size of tool manufacturer, previous experience, and
expert advice.
Determine evaluation criteria like required notations, input/output file
formats, reporting/printing capabilities, code generation facilities and so
on.
Evaluate all candidate tools a UML expert will be able to do a
reasonable (superficial) analysis of any tool in half a day.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

Unified Modeling Language 2.0

Part 9 - Best Practices for the
management of large models
Dr. Harald Strrle
University of Innsbruck
MGM technology partners

Dr. Alexander Knapp

University of Munich

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

9 - Best practices
Management of large models

Creating and handling small models presents some challenges.

But managing large models is a problem in its own right, which
comes in addition to all of these:
versioning, diff/patch, merge
migration between tool platforms
long term maintenance of models
round-trip with manual interference
measures, queries, checks, analysis of models
simulation, code generation
reporting
Today, we dont have appropriate tool support for the majority of
these tasks, and it is very cumbersome to do it by hand.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 - Best practices
What exactly means large for a model?

(v4)

Project size (only model-related activites!)

Manpower:
5-100 Persons (rather: Person-equivalents)
Duration:
1-10 Years
Budget/Cost:
1-50 Mio
Number of model elements (population)
200-5.000
classes (times 10-20 attributes)
100-1.000
business processes (times 10-20 functions, steps)
5-10/10-20/20-50 systems/subsystems/segments
50-200
interfaces
Compare with large scale software systems, e.g. SAP R/3
over 100 Mio LoC, more than 33.000 database tables
14 systems, 35 subsystems, ca. 32.000 programs
ca. 2.500 interfaces
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Probleme and gaps in large modeling projects

(v4)

Characteristics of large projects

Specific for modeling projects

overal situation
often extremly political environment
inhomogeneous, large organisation
long and critical previous project history
very long project duration
extreme expectations, big
dissappointments
hostile competitors involved
(Mehrfrontenkrieg)

Tools
inappropriate tools previous decisions
Untaugliche Werkzeuge gesetzt
berhaupt keine Werkzeuge verfgbar
Versionsverwaltung/Diff selten
Releases, Auslieferung, Sicherung

structuring of models and method

the usual suspects are insufficient

Qualifications
Customer
Colleagues
oneself

Work organisation
several companies and organisations
involved
distribution over several places

Quality of models
what does it mean in the first place?
consistency
coherene and validity
clear focus (big picture)
adherance to conventions

many gaps

but each gap is also a starting point!

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Starting points in large modeling projects

Model structure and methodology

no/few established standards thus
much leeway
impact on almost all other areas
requires intensive training and
coaching (Navigation overview)

Model design
Layout, naming conventions
Guidelines for model sizes and
levels of abstractions
Change markers
Plan header
Attribute states (open questions,
defaults, errors)

(v4)

Conviction
large and demotivated teams must be
convinced and activated
support for standards such as
poster of model inventory
navigation overview
coaching (less useful: trainings)
handzettel mit Arbeitsanleitungen

Automatisation / Integration
XMI (e.g. Modelbridge)
self-made tools, e.g.
naming conventions
measures for size/complexity
reporting
generating

Organisation of project
Quality assurance criteria
Distributed work
Process of modeling, tasks

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

9 Best practices
Model, Diagram, Plan

XMI, MDL, ADL,

UML, EPK, ERD,
projectspecific

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

9 Best practices
Model, Diagram, Plan

Model
A Modell is an abstract entity, existing e.g. in a data structure
Parts of models may be modles again
standardised (XMI) or proprietary (MDL, ADL, )
Diagram
a diagram is a either

the visual presentation of a model,

or an informal sketch.

A diagram defines a model: the one consisting of those model

elements that are presented visually.
Plan
A plan is a diagram in a frame of reference.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 - Best practices
Model information

(v4)

Title
Name
pragmatic type
Text field
Author/Manager
Customer/Project
date/version
view, phase, intention
scale, section, unit
QA status
Legend
Stereotypes

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Role model civil architecture: detail section of a plan

(v4)

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Role model civil architecture: plan header (DIN 6771)

(v4)

10

other relevant ISO standards

ISO 128:1996 Technical Drawings (in 29 parts)
ISO 3098:1997 Lettering (in 7 parts)
ISO 7200:1984 Technical drawings Title blocks
ISO 5455:1979 Scales
ISO 5457:1999 Drawing sheet formats for technical documentation
ISO 13567:1998 Technical product documentation Organization and
naming of layers for CAD
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

11

9 Best practices
Role model civil architecture: plan header real life example

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Role model civil architecture: plan header in tools

(v4)

12

Administrative informationen of
this kind should be presented
(partially) in a plan header.
Filling slots like predefined Values
and state transitions should be
supported.
Reports on qa-status, version,
model type etc. are important.
If ther is no support for model
headers (almost always the case)
use comment boxes: more effort
but feasible and better than
nothing.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Contents of a legend

(v4)

13

legend
Depending on the audience,
one might need descriptions of
the complete notation
stereotypes only
colour coding of model
changes
change marker
Lists of added, removed, and
modified modell elements

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Putting a legend in a plan

(v4)

14

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Change markers

(v4)

15

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Change markers

(v4)

16

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

9 Best practices
States of attributes

17

attribute state
check
unchecked

checked
modify
modified
??

unchanged

ok

<Value>

work in
progress
submitted
for approval

open question
empty
filled

partially
approved

qa approved

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Alternatives for model storage Pros/cons
File
e.g. Magic Draw, Rose

Repository/database
e.g. StP, Adonis

storage in a single file

size
conflicting access
distributed work

storage in tool-repository
distributed work
versioning
back up

storage in redundant files

consistency

structuring facilities
of the tool
grouping / tree

storage of non-overlapping parts

in a directory tree
references
integration

(v4)

18

of the modeling language

packages, classes

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Versioning the problem

(v4)

19

Only very few tools have appropriate functionality. Marketing is

often more advanced than reality.
It is possible to store your models in a CM tool, but
Some tools are DB-based (e.g. StP, Adonis), so that models must
be extracted/exported first (often manually), which is error prone
and tedious.
The extraction format may be (that is, in reality it always is)
difficult to interpret and process (e.g. diff of XMI files including
diagrams).
Even if the modell is well structured, this does not guarantee that
the modell-Dump is well structured, too.
So, probably there is no model version control system available
when you want it!
Therefore, you need to resort to the poor mans repository.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 Best practices
Versioning - Alternatives

(v4)

20

Case 1: a small group of modellers

versioning only by backups
coordination directly (bilaterally) between all people involved
may become critical under spatial distribution
Case 2: model structure similar to project structure
The whole model is structured in 1 overarching part and n more
specific parts, depending only on the overarching part.
Each of these n+1 parts is created and modified by exactly one
group (everybody else may read). Within each group, case 1
applies.
The groups are coordinated by a special group, e.g. formed by
the group leaders.
Case 3: Chaos
Get a new job.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 - Best practices
Creating good diagrams

(v4)

21

Naming conventions
There must be conventions for names and abbreviations.
There must be a glossary to describe the terminology of the project,
including domain-specific names.
Graphic design conventions
The graphic of a diagram (layout, color, size, pen etc.) is essential for
the usability of the model it represents, e.g.:

discussing and modeling,

presentation,
quality assurance,
implementation.

Thus, a good graphical design is an essential part of the model, equally

important than the contents itself.
Bad diagrams often indicate bad models, for modeling errors are less
apparent when there are many other errors around.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 - Best Practices
Creating good diagrams: Names

(v4)

22

A name should express what an element is about. Good names are

important!
The same things should follow a consistent naming schema, so that
the name already hints at what an element is supposed to be.
system/subsystem/group of use cases: noun, gerund + noun,
e.g. Payment
business process: gerund + noun, e.g. awarding Miles
business function: verb noun, e.g. select flight
class/attribute: noun, e.g. passenger number, flight, booking

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

9 - Best Practices
Creating good diagrams: Names
Subsysteme
Noun | Nounphrase
(also substantivised verb)
Names of previously used
systems (abbreviations!)
Document management
Order book
Invoice
Schnittstellen
From - To
fixed and well known names
DS052
DMS-BInfo

23

Business process and functions

Verb Nounphrase
file application
assess payment according to

law XY and check solvency

(manually)

Conditions
[Nounphrase] (Adjective |
Adverb)
tax identification code

present
done

Adherence of conventions
Glossary
Automated checker
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

9 - Best Practices
Creating good diagrams: Layout

24

A model should be complete, non-redundant, clear, and adequate.

Completeness
All relevant facts are contained in the model and displayed according to
their importance.
Non-redundancy
No part of a model is displayed more than once except there is a good
reason.
Clarity
There should be around 72 (main) elements per screen/paper page.
If necessary, split diagrams or introduce abstractions. If the resulting
system of diagrams is a tree, the tree should be balanced.
Adequacy
know your audience: what aspect is particularly interesting for this
audience?
What is the purpose of this diagram, why do I draw it in the first place? Is
this goal achieved?
Is there a better way to achieve this goal, such as using another diagram
type, another layout altogether, or something else?
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

9 - Best Practices
Creating good diagrams: Layout

25

Observe the Gestalt-laws

present similar things similarly

Things presented differently will be perceived as different things.

uniform size, color, orientation, alignment

Things of similar importance should be present in approximately the same size.

Things presented in the same way will be perceived as similar.

Non-uniform presentation transports (unwanted) information

Observe reading order
left right, top bottom (at least in the west)
clockwise arrangement for states
Layout
Avoid crossings, strive for clarity

Further aspects
Use colors, pen sizes, fonts, etc. very sparingly (consider printability)
If you do use them, use them carefully, and make sure who youre
talking to.
(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

(v4)

9 - Best Practices
Industrial experiences

26

Contrary to common belief, many domain experts are quite happy

when confronted with UML diagrams - analysis level only, of course.
With UML 2, many things may now be captured, which were difficult
to capture before.
The tool support is not yet sufficient, however, partly due to the
enormous complexity of the UML.
Bottom line: its a step ahead, but were not yet there.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp

UML 2.0 Tutorial

9 - Best Practices
A look into the crystal ball

(v4)

27

Its very likely, that a version UML 2.1 will be coming to sort out the
problems that are currently contained in the UML.
There might also be UML 2.2 and UML 2.3 but will there be a UML
3.0?
There can only be one unified modeling language, though there will
probably be simpler modeling languages.
Domain-specific languages are neither unified, nor (usually) simpler
than UML, and hard evidence of their other claimed benefits are
nowhere to be seen.

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knapp