10/30/2012

1
Prof. Dr. Harald Strrle
Danmarks Tekniske Universitet (DTU)
DTUcourse02264
AppendixA:
SyntaxoftheUnifiedModelingLanguage2
AppendixA
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
2

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Agenda
Abstract
ThisAppendixisbasedonatutorialbyH.StrrleandA.Knapp,andthetwo
booksUML2frStudenten(Pearson,2005),andUML2erfolgreich
einsetzen(AddisonWesley,2005)byH.Strrle.
Thetutorialhasbeenheldinternationallyfor5times,withwelloverahundred
participantsaltogether.
Contents
1. Introduction
2. StaticStructure
3. UseCases
4. Architecture
5. Activities
6. StateMachines
7. Interactions
10/30/2012
2
Prof. Dr. Harald Strrle
Danmarks Tekniske Universitet (DTU)
DTUcourse02264
AppendixA.1:
Introduction
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
4
ExecutiveSummary
1. TheUMListhelinguafrancaofsoftwareengineering,
subsumingintegratingandconsolidatingmostofitspredecessors.
1. Originallyavision*,today,everypracticingSoftwareEngineermustatleast
understandUML,preferablyalsospeakit.
2. Throughthenetworkeffect,UMLhasamuchbroaderspreadand
muchbettersupport(tools,books,trainingsetc.)thanallother
SoftwareEngineeringorModelingnotationstogether.
3. WhileUML2stillhasmanyproblems,itismuchbetterthanwhat
weeverhadbefore.
1. ThetransitionfromUML1.xtoUML2.0hasbeenasignificantmilestoneand
resolvedmanyissues,yetplentyofworkremainstobedone.
2. Thecurrentversionofthesuperstructure(thestandard)is2.4.1
(documentformal/20110806 releasedAugust2011).

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
*BranSelic atthebanquetofthe
UMLconference,2001inYork
10/30/2012
3
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
5

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
UML Past,Present,Future
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
6

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
UsageScenarios
UMLhasnotbeendesignedforspecific,limitedusages.
ThereiscurrentlynoconsensusontheroleoftheUML:
SomeseeUMLonlyastoolforsketchingclassdiagramsrepresentingJava
programs.
SomebelievethatUMListheprototypeofthenextgenerationof
programminglanguages.
UMLisreallyasystemoflanguages(notations,diagram
types)eachofwhichmaybeusedinanumberofdifferent
situations.
UMLisapplicableforamultitudeofpurposes,duringallphases
ofthesoftwarelifecycle,andforallsizesofsystems tovarying
degrees.
10/30/2012
4
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
7

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
DiagramtypesinUML2
UMLisacoherentsystemoflanguagesratherthanasinglelanguage.
Eachlanguagehasitsparticularfocus.
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
8

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
InternalStructure:Overview
TheUMLisstructuredusingametamodelingapproachwithfourlayers.
TheM
2
layeriscalledmetamodel.
Themetamodelisagainstructuredintorings,oneofwhichiscalled
Superstructure,thisistheplacewhereconceptsaredefined(themetamodel
proper).
TheSuperstructureisstructuredintoatreeofpackages inturn.
10/30/2012
5
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
9

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
InternalStructure:Layers
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
10

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
InternalStructure:Rings
10/30/2012
6
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
11

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
InternalStructure:Packages
Prof. Dr. Harald Strrle
Danmarks Tekniske Universitet (DTU)
DTUcourse02264
AppendixA.2
StaticStructure
10/30/2012
7
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
13

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Mainconceptsofclassmodels
Class
Inheritance
Package
Association
Property
Operation
Constraint
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
14

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Classesandassociations
Class
describes set of
instances with
common features
Structural features
properties (aka. attributes)
Behavioral features
operations and receptions
association name reading
direction
qualified end (fh per date)
Association
structural relationship
association ends
are properties
association end
enumeration literals
Data type
identified by value
10/30/2012
8
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
15

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Generalization(Inheritance)
{ abstract } class
(no direct instances,
only specializations
may have instances)
if decorated with { root }: no superclass
if decorated with { leaf }: no subclass
Generalization for subtype polymorphism
inheritance of features
for associations
also Classifiers
name of generalization set
Generalization sets
for taxonomies
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
16

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
InterfacesandPackages
Packages
group elements into
namespaces
features to be offered
Interfaces
define contracts for
implementers
client
provider
lollipop joint
10/30/2012
9
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
17

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Templates for parametric polymorphism
Templatesandobjects
Slot with
ValueSpecification
InstanceSpecification InstanceValue
link
template parameters
exposed parameterable elements
template binding
Template class
(ParameterableElement)
Bound class
(TemplateableElement)
Object diagrams
Prof. Dr. Harald Strrle
Danmarks Tekniske Universitet (DTU)
DTUcourse02264
AppendixA.3
UseCases
10/30/2012
10
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
19

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
MainconceptsofUseCases
Actor
Class (also possible: Component)
extends
(is a Dependency)
UseCase
includes
(is a Dependency)
Association
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
20

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Extensionpoints
Anextensionoccursata(named)
ExtensionPoint,whenaspecific
conditionissatisfied.
Inaway,ExtensionPointsaresimilarto
userexits orhooks.
Inrealworldsystems,therearemany
ExtensionPoints,mostofwhichare
poorlydocumented.
AsforallClassifiers,UseCasesmaybe
arrangedintaxonomichierarchies.
ExtensionPoint
10/30/2012
11
Prof. Dr. Harald Strrle
Danmarks Tekniske Universitet (DTU)
DTUcourse02264
AppendixA.4
Architecture
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
22

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Compositestructurediagrams
Part
Port
interface
of a Part
Connector
Actor
a system like a
Class or a
Component
Part
with visual
stereotype
Port
with visual
stereotype
better name: assembly diagrams
10/30/2012
12
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
23

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Plumbingcomponentstogether
ConnectingPortsamountsto
delegate/calldependencies.
Usingthejointnotationreveals
detailsaboutthenumberand
directionofconnections.
Fromlefttoright:
twoconnectors,oneineach
direction
oneconnectorwithdirection
andoneconnectorwithout
direction.
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
24

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Collaborations
Thepurposeofcollaborationsisto
abstractlydescribeaformoflinkage
withoutbeingspecific.
Declaredasthewaytodescribe
designandanalysispatterns.
Mighthelpinearlystagesof
architecturaldesign.
Couldalsobeusedtodescribe
globalconstraints.
Maybenestedandcomposed.
Methodologically,Collaborations
arethestructuralequivalentto
UseCases.
10/30/2012
13
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
25

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Systemstructure
Node
Comment
for quantitative information
CommunicationPath
is a kind of
Association
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
26

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Deployment
ADeploymentisamappingof
artifactstosystemnodes.
Artifactsmayinclude
binaries
componentinstances
Systemnodesmayinclude
hardware(Device)
software(ExecutionEnvironment)
Formally,adeploymentisa
DeploymentRelationship.
Itmaybepresentedeitheras
placingthedeployeditemsortheir
namesonthedeploymenttarget.
Artifact
Node may be specialized to either
Device or
ExecutionEnvironment
10/30/2012
14
Prof. Dr. Harald Strrle
Danmarks Tekniske Universitet (DTU)
DTUcourse02264
AppendixA.5
Activities
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
28

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
MainconceptsofActivities
Partition
InitialState
FinalState
ActivityEdge
ObjectNode
ActivityNode
MergeNode
DecisionNode
JoinNode
ForkNode
ObjectFlow
10/30/2012
15
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
29

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
MainconceptsofActivities
FlowFinal
stereotyped
ObjectNode
refined Activity
Partitions
may be represented
explicitly
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
30

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Pins
Dataflowmayberepresented
explicitly(arrowsbetweenActionsandObjectNodes),
bydataflownodesattachedtocontrolflow,
byPinsonActivities,or
ascombinationsthereof.
Pin
10/30/2012
16
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
31

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Exceptions
ExceptionEdge
handler Activity
Exception
unhandled
Exception
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
32

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Expansionregions
Activitiesareoftenusedtospecify
processingofmassdata(batchruns)
ratherthanindividualitems.
UMLoffersExpansionRegionsto
supportthisusagescenario.
Anexpansionregiondeclaresa
portionofanactivitiyasapplicable
toawholebunchofitems.
10/30/2012
17
Prof. Dr. Harald Strrle
Danmarks Tekniske Universitet (DTU)
DTUcourse02264
AppendixA.6
StateMachines
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
34

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Statesandtransitions
simple State
trigger (CallEvent) guard (Constraint) initial Pseudostate
FinalState
effect (CallAction)
Transition
Statemachinesmodelbehavior
usingstatesinterconnected
withtransitionstriggered
byeventoccurrences.
10/30/2012
18
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
35

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Triggersandbehaviors
ChangeEvent
TimeEvent
(relative)
completion
event
(no explicit
trigger)
SignalEvent
deferred
event
entry/exit
Behavior
do activity
Behavior
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
36

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Hierarchicalstates
detailed
(non-orthogonal)
composite State
Region
substates
default entry
10/30/2012
19
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
37

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Entryandexitpoints(Pseudostates)
providebetterencapsulationofcompositestates
helpavoidunstructuredtransitions
Entryandexitpoints
entry
point
exit point (on border of state machine
diagram or composite state)
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
38

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Orthogonalregions
orthogonal Regions,
both active if
Client/Server active
Simple State: containing no Region
Composite State: containing at least one Region
- simple composite State: exactly one
- orthogonal composite State: at least two
orthogonal states are concurrent as a single event may trigger a transition
in each orthogonal region simultaneously
10/30/2012
20
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
39

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Protocolstatemachines
precondition
postcondition
specified operation
ProtocolTransition
Protocolstatemachinesspecifywhichbehavioralfeaturesofa
classifiercanbecalledinwhichstateandunderwhichcondition
andwhateffectsareexpected.
particularlyusefulforobjectlifecyclesandports
noeffectsontransitions,onlyeffectdescriptions
Prof. Dr. Harald Strrle
Danmarks Tekniske Universitet (DTU)
DTUcourse02264
AppendixA.7
Interactions
10/30/2012
21
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
41

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
ThreetypesofInteractions
sequence diagram
communication
diagram
timing diagram
all three are
semantically
equivalent
Well,four,really,but
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
42

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
MainconceptsofInteractions
Lifeline
Interaction
partner
call
asynchronous signal
reply
OccurrenceSpecification
aka. EventOccurrence
termination Event
non-instantaneous
Message
lost & found
Messages
instantiation Event
10/30/2012
22
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
43

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Activation
activation bar
activation
suspended
nested activation
warp lines
(non-UML)
external
Event
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
44

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Complexinteractions
Interaction
Operator
Interaction
Fragment
Interaction
Operand
Acomplexinteractionislikeafunctionalexpression:
anInteractionOperator,
oneorseveralInteractionOperands(separatedbydashedlines),
(andsometimesalsonumbersorsetsofsignals).
10/30/2012
23
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
45

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Interactionoperators(overview)
strict
operandwisesequencing
seq
lifelinewisesequencing
loop
repeatedseq
par
interleavingofevents
region(aka.critical)
suspendinginterleaving
consider
restrictmodeltospecificmessages
i.e.allowanythingelseanywhere
ignore
dualtoconsider
ref
macroexpansionoffragment
alt
alternativeexecution
opt
optionalexecution
syntacticsugarforalt
break
abortexecution
sometimeswrittenasbrk
assert
removeuncertaintyinspecification
i.e.declarealltracesasvalid
neg
declarealltracesasinvalid
(threevaluedsemantics)
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
46

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
UsingInteractionsfortiming
Forembeddedandrealtime
systems,itmaybeimportantto
specifyabsolutetimingsandstate
evolutionovertime.
Thisisnotreadilyexpressedin
sequencediagrams,muchless
communicationdiagrams.
UML2.0introducestimingdiagrams
forthispurpose.
Orrather:itreintroducesthe
notationabolishedinOMT2.
10/30/2012
24
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
47

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Abstractionintimingdiagram
Analternativesyntaxpresents
statesnotontheverticalaxisbutas
hexagonsonthelifeline.
Timingdiagramspresentthe
coordinationof(thestatesof)
severalobjectsover(real)time.
DTUcourse(02264)
RequirementsEngineering
AppendixA:UML
48

2
0
0
9
,

P
r
o
f
.

D
r
.

H
.

S
t

r
r
l
e
Prof. Dr. Harald Strrle
Software Engineering Section
Department of Informatics and Mathematical Modelling
Technical University of Denmark
Richard Petersens Plads
Building 322, Room 024
DK-2800 Kgs. Lyngby
hsto@imm.dtu.dk
www.imm.dtu.dk/~hsto