UML 2.0 Tutorial

8/12/2019 UML 2.0 Tutorial

1/244

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

UML 2.0 Tutorial (v4) 1

Unified Modeling Language 2.0Part 1 - Introduction

Prof. Dr. Harald StrrleUniversity of Innsbruckmgm technology partners

Dr. Alexander KnappUniversity of Munich


2/244


UML 2.0 Tutorial (v4) 21 - IntroductionHistory and Predecessors The UML is the lingua franca ofsoftware engineering. It subsumes, integrates and

consolidates most predecessors. Through the network effect, UML has amuch broader spread and much bettersupport tools, books, trainings etc.)than other notations. The transition from UML 1.x to UML2.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 hadbefore.

current version (the standard)

formal/05-07-04 of August 05


3/244


UML 2.0 Tutorial (v4) 31 - IntroductionUsage 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 diagramsrepresenting 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 ofthe software lifecycle, and for all sizes of systems - to varying

degrees.


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

UML 2.0 Tutorial (v4) 41 - IntroductionUsage Scenarios



UML 2.0 Tutorial (v4) 51 - IntroductionDiagram types in UML 2UML is a coherent system of languages rather than a single language.Each language has its particular focus.



UML 2.0 Tutorial (v4) 61 - IntroductionDiagram types also depend on their usage Each diagram type may be used ina multitude of settings, for each ofwhich different rules and best

practices may apply. For instance, class diagrams maybe used during analysis as well as

during implementation. During analysis, this class diagramis bad, or at least suspicious. During implementation, it is bad ifand only if it does not correspondto the code or other structure) it

is used to represent.

2 0 l ( )



UML 2.0 Tutorial (v4) 71 - IntroductionInternal 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 calledsuperstructure, this is the place where concepts are defined themetamodel proper).

The Superstructure is structured into a tree of packages in turn.

UML 2 0 T t i l ( 4) 8



UML 2.0 Tutorial (v4) 81 - IntroductionInternal Structure: Layers

UML 2 0 Tutorial (v4) 9



UML 2.0 Tutorial (v4) 91 - IntroductionInternal Structure: Layers




UML 2.0 Tutorial (v4) 101 IntroductionInternal Structure: Rings




UML 2.0 Tutorial (v4) 111 - IntroductionInternal Structure: Packages



12/244


UML 2.0 Tutorial (v4) 121 - IntroductionDiagrams and modelsdiagram name

(pragmatic)

diagram kind

model(abstract syntax)

diagram(concrete syntax)

represent present

datastructure,instance of the metamodel



13/244


UML 2.0 Tutorial (v4) 131 - IntroductionUML is not only) object oriented A popular misconception about UML is that it is object oriented byheart 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 oftheir implementation languages (Java, Cobol, Assembler, );

is not tied to any language or language paradigm, neither by

accident nor purpose.



14/244


( )1 - IntroductionUML 1.x vs. UML 2.0UML 1.x Collaboration diagram ActivityGraph is a StateMachine

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 collaborationsOther novelties Detail changes everywhere New overall structure



15/244


1 - IntroductionUML 1.x vs. UML 2.0 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, thestate 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.



16/244


1 - IntroductionWrap up 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 toplan, 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.



17/244


Unified Modeling Language 2.0Part 2 Classes and packages

Prof. Dr. Harald StrrleUniversity of InnsbruckMGM technology partners




18/244


2 Classes and packagesA first glimpse



19/244


2 Classes and packagesHistory 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)



20/244


2 Classes and packagesUsage scenarios

Implementationesignnalysis

odeet of objectsype oncept

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 softwaredevelopment phases. meaning of generalizations varies with meaning of classes



21/244


2 Classes and packagesAnalysis class diagram (1)



22/244


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 beimplemented otherwise

2 Classes and packagesClasses Classes describe a set of instances with common features (andsemantics).

Classes induce types (representing a set of values).

Classes are namespaces (containing named elements).



23/244


2 Classes and packagesAssociations Associations describe sets of tuples whose values refer to typedinstances.

In particular, structural relationship between classes

Instances of associations are called links.

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 navigableassociation end

association namereadingdirection

ternary associationqualified end (fh per date)



24/244


2 Classes and packagesAssociation classes Association classes combine classes with associations.

not only connect a set of classifiers but also define a set offeatures 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



25/244


2 Classes and packagesData 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

Enumerations are special data types. instances defined by enumeration literals

denoted by Enumeration::EnumerationLiteral or #EnumerationLiteral

may show structural and behavioral features

compartments for attributesand operations suppressed

enumeration literals



26/244


2 Classes and packagesAnalysis class diagram (2)



27/244


2 Classes and packagesInheritance (1) 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

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

Generalizations also apply toassociations. as both are Classifiers

{ abstract } class(no direct instances,only specializations

may have instances)

if decorated with { root }: no superclass

if decorated with { leaf }: no subclass



28/244


Generalization sets detail the relation between a general and morespecific classifiers. { complete } (opposite: { incomplete })

all instances of general classifier are instances of one of the specificclassifiers 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 }

several generalization sets may be applied to a classifier

useful for taxonomies

2 Classes and packagesInheritance (2)

name of generalization set



29/244


2 Classes and packagesConstraints 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)



30/244


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

2 Classes and packagesPackages (1)

Notational variants



31/244


Package imports simplify qualified names.

2 Classes and packagesPackages (2)private ElementImport public ElementImport

public PackageImport renaming private ElementImport

public importpublicXB

default visibilitypublicQBprivate import, renamingprivateRB

public

private

Visibility

all remaining visible elements of BQA

separate private element import

(otherwise public overrides private)

XA

Elementackage



32/244


Package mergings combine concepts incrementally. but use with care

2 Classes and packagesPackages (3)

The receiving packagedefines the increment.

The receiving packageis simultaneously the

resulting package.

Merging is achievedby (lengthy)transformation rules

(not defined forbehavior).

Package merging isused extensively in

the UML 2.0specification.



33/244


2 Classes and packagesMetamodel



34/244


2 Classes and packagesDesign class diagram

UML 2.0 Tutorial (v4) 192 Classes and packages


35/244


are redefinable (unless decorated by { leaf }) in classes that specialize the context class

Features

visible to elements

in owning namespace only

in the same package as the owning namespace

with generalization to owning namespace

that can access owning namespace

(by membership, import, or access)

private

package

protected

public

Visibility kinds (no default)

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

can be defined on instance or class levelisStatic default value



36/244


Properties

Set (default)Bag

Sequence

Or der edSet

Collection type{ unique }{ ordered }

/ ({ derived }) can be computed from other information (default: false)

{ readOnly } can only be read, not written (default: false = unrestricted)

{ union } union of subset properties (implies derived)

{ subsets } which property this property is a subset of

undefined ( )sharedvaluecomposite

referencenone

Aggregation kinds (default: none)



37/244


Behavioral features 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

in passive classes:

all invocations may proceed concurrently{ concurrent }

only one execution, other invocations are blocked{ guarded }

no concurrency management{ sequential }

Call concurrency kinds (no default)

active class (with own behavior whichstarts on instance creation)



38/244


Operations (1) 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

both waysinout

return from callee (at most 1)return

one way from calleeout

one way from callerin

Parameter direction kinds (default: in)

parameter name

parameter type

parameter multiplicity



39/244


Operations (2) 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 redefinedoperations The mechanism by which the behavior to be invoked is determined from

an operation and the transmitted argument data is a semantic variationpoint.

a single-dispatch, object-oriented resolution principle is mentionedexplicitly in the UML 2.0 specification

Operation invocations may be synchronous or asynchronous.



40/244


Signals and receptions A signal is a specification of type of send request instancescommunicated between objects.

Signals are classifiers, and thus may carry arbitrary data.

A signal triggers a reaction in the receiver in an asynchronousway and without a reply (no blocking on sender).

A reception is a declaration stating that a classifier is prepared toreact to the receipt of a signal. Receptions are behavioral features and thus are realized by

behavior (e.g., a state machine).

Reception



41/244


Interfaces Interfaces declare a set of coherent public features and obligations.

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

client

provider

features to be offered

Several notations for client/provider relationship

lollipopjoint



42/244


Templates

template parametersexposed parameterable elements

template binding

Template class

(ParameterableElement)

Bound class(TemplateableElement)

subtype polymorphism vs. parameteric polymorphism



43/244


Object diagram

Slot withValueSpecification

underlining and association end adornments are optional

InstanceSpecification InstanceValue

link



44/244


Instances specificationsUML metamodel

user model



45/244


UML 1.x vs. UML 2.0 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)



46/244


Wrap up Classifiers and their Relationships describe the vocabulary of asystem. Classifiers describe a set of instances with common Features.

StructuralFeatures (Propertys)

BehavioralFeatures (Operations, Receptions)

Associations describe structural relationships between classes. Association ends are Propertys.

Generalizations relate specific Classifiers to more general Classifiers. Packages group elements

and provide a Namespace for grouped elements.

InstanceSpecifications and links describe system snapshots.



47/244


Unified Modeling Language 2.0Part 2a Object Constraint Language

Prof. Dr. Harald StrrleUniversity of Innsbruck

MGM technology partners



48/244

UML 2.0 Tutorial (v4) 32a Object Constraint Language


49/244


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



50/244


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)



51/244


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



52/244


Simple types Predefined primitive types

Bool ean t r ue, f al se

I nt eger - 17, 0, 3

Real - 17. 89, 0. 0, 3. 14

St r i ng Hel l o

Types induced by UML model Classifier types, like

Passenger no denotation of objects, only in cont ext Enumeration types, like

Status St at us: : Al bat r os, #Al bat r os

Model element types

Ocl Model El ement , Ocl Type, Ocl St at e

Additional types Ocl I nval i d invalid (Ocl Undef i ned)

Ocl Voi d null

Ocl Any top type of primitives and classifiers



53/244


Parameterized types Collection types

Set ( T) sets

Or der edSet ( T) like Sequence without duplicates

Bag( T) multi-sets

Sequence( T) lists

Col l ect i on( T) abstract

Tuple types records) Tupl e( a

1: T

1, , an : Tn)

Message type Ocl Message

for operations and signals

Examples Set {Set { 1 }, Set { 2, 3 }} : Set ( Set ( I nt eger ) )

Bag{1, 2. 0, 2, 3. 0, 3. 0, 3} : Bag( Real )

Tupl e{x = 5, y = f al se} : Tupl e( x : I nt eger , y : Bool ean)



54/244


Type hierarchy Type conformance reflexive, transitive relation

Ocl Voi d, Ocl I nval i d T for all types T I nt eger Real

TT C( T) C( T) for collection type C C( T ) Col l ect i on( T) for collection type C generalization hierarchy from UML model B Ocl Any for all primitives and classifiers B

Counterexample (Set ( Ocl Any) Ocl Any)

Casting v. ocl AsType( T) if v : T and (TT or T T)

upcast necessary for accessing overridden properties

but are (still) forbidden in the specification



55/244


Expressions Local variable bindings

let x = 1 in x+2

Iterationc- >i t er at e( i : T; a : T = e |e)

source collection

iteration variable

(bound to current value in c)

accumulator with initial value e(gathers result, returned after iteration)

iteration expression(using variables i and a)

Set {1, 2}- >i t er at e( i : I nt eger ; a : I nt eger = 0 | a+i ) = 3Example:

Many operations on collections are reduced to i t er at e



56/244


Operations on primitive types (written: v.op( ) ) operations without ( ) are mixfix

Operations on collection types (written: v- >op( ) )

Expressions: Standard library 1)

si ze( ) , concat ( s) , subst r i ng( l, u) , St r i ng

=, , ocl I sTypeOf ( T) , ocl I sKi ndOf ( T) , Ocl Any

+, - , * , / , f l oor ( ) , r ound( ) , Real

+, - , * , / , di v( i) , mod( i) , I nt egerand, or , xor , i mpl i es, notBool ean

append( s) , f i r s t ( ) , at ( i) , asOr der edSet ( ) , Sequence

si ze( ) , i ncl udes( v) , i sEmpt y( ) , Col l ect i on

uni on( b) , i ncl udi ng( v) , f l at t en( ) , asSet ( ) , Bag

append( s) , f i r s t ( ) , at ( i) , Or der edSetuni on( s) , i ncl udi ng( v) , f l at t en( ) , asBag( ) , Set



57/244


Expressions: Standard library 2) Finite quantification

c- >f or Al l ( i : T |e) = c- >i t er at e( i : T; a : Bool ean =t r ue |aande)

c- >exi st s( i : T |e) = c- >i t er at e( i : T; a : Bool ean =f al se |aore)

Selecting values c- >any( i : T |e) some element of c satisfying e

c- >sel ect ( i : T |e) all elements of c satisfying e

Collecting values c- >col l ect ( i : T |e) collection of elements with e applied to

each element of c

c.p collection of elements v.p for each v in c(short-hand for col l ect )

is value v undefined (null) or invalid?v. ocl I sUndef i ned( )is value v invalid?v. ocl I sI nval i d( )

is o currently in state machine state s?o. ocl I sI nSt at e( s)

all current instances of classifier CC. al l I nst ances( )



58/244


Evaluation Strict evaluation with some exceptions

( if ( 1/ 0 = 0) then 0. 0 else 0. 0 endif) . ocl I sI nval i d( ) = t r ue

( 1/ 0) . ocl I sI nval i d( ) = t r ue

Short-cut evaluation for and, or, implies ( 1/ 0 = 0. 0) andf al se = f al se

t r ue or ( 1/ 0 = 0. 0) = t r ue

f al se implies ( 1/ 0 = 0. 0) = t r ue

( 1/ 0 = 0. 0) implies t r ue = t r ueif ( 0 = 0) then 0. 0 else 1/ 0 endif = 0. 0

In general, OCL expressions are evaluated over a system state.e.g., representedby an object diagram



59/244


Connection to UML Import of classifiers and enumerations as types Properties accessible in OCL

Attributes

p. milesCard (withp : Passenger)

Association ends p. flight,p. booking, p. booking[ flight]

{ query } operations

Representation of multiplicities

a : Bag( T)a[*] : T { bag }

a : Or deredSet ( T)a[*] : T { ordered }

a : Set ( T)a[*] : T { unordered }

a : Set ( T)a[m..n] : Ta : Set ( T) or Ta[0..1] : T

a : Ta[1] : T

UML 2.0 Tutorial (v4) 142a Object Constraint LanguageInvariants


60/244


context Passengerinv: ma. statusMiles > 10000 implies

status = Status: : Albatros

boolean expression

context Passengerinv st at usLi mi t : sel f . ma. statusMiles > 10000 implies

sel f . status = Status: : Albatros

context p : Passengerinv st at usLi mi t : p. ma. statusMiles > 10000 implies

p. status = Status: : Albatros

optional name

replacement for sel f

Notational variants

context classifier

explicit sel f (refers to instance of discourse)

UML 2.0 Tutorial (v4) 152a Object Constraint LanguageSemantics of invariants


61/244


context C

inv: I1

context C

inv: I2

context C

inv: I1and I2

Restriction of valid states of classifier instances when observed from outside

One possibility: Combination of several invariants by conjunction

Invariants as all constraints) are inherited via generalizations but how they are combined is not predefined

UML 2.0 Tutorial (v4) 162a Object Constraint LanguagePre-/post-conditions


62/244


context Passenger: : consumeMiles( b : Booking) : Bool eanpre: ma- >not Empt y( ) and

ma. flightMiles >= b. flight. miles

context Passenger: : consumeMiles( b : Booking) : Bool eanpost: ma. flightMiles = ma. flightMiles@pr e- b. flight. milesand

r esul t = t r ue

Some constructs only available in post-conditions values at pre-condition time p@pr e

result of operation call r esul t

whether an object has been newly created o. ocl I sNew( )

messages sent o op( ) , o^ op( )

In UML models, pre- and post-conditions are defined separately not necessarily as pairs

precondition and postcondition as constraint stereotypes

UML 2.0 Tutorial (v4) 172a Object Constraint LanguageSemantics of pre-/post-conditions


63/244


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 @pr e).

Thus (P, Q) equivalent to (true, P@pr eandQ).

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

benefits and obligations differ for implementer and user

P establishedif P satisfied, establish QmplementerQ establishedsatisfy Pser

benefitbligation

UML 2.0 Tutorial (v4) 182a Object Constraint LanguageCombining pre-/post-conditions


64/244


Standard interpretation joining pre- and post-conditions conjunctively

Alternative interpretation case distinction (like in protocol state machines)

only useful for pre-/post-condition pairs

context C: :op( )

pre: P1 post: Q

1

context C: :op( )

pre: P2 post: Q2

context C: :op( )

pre: P1or P

2

post: ( P1@pr e implies Q

1)

and( P2@pr e implies Q2)

context C: :op( )

pre: P1 post: Q1

context C: :op( )

pre: P2 post: Q

2

context C: :op( )pre: P

1and P

2

post: Q1and Q

2

UML 2.0 Tutorial (v4) 192a Object Constraint LanguageMessages


65/244


context Subject: : hasChanged( )

post: let messages : Set ( Ocl Message) =observer^ update( ? : Subject)

in messages- >not Empt y( ) andmessages- >f or Al l ( m |

m. r esul t ( ) . ocl I sUndef i ned( ) andm. hasRet ur ned( ) andm. subj ect = sel f )

context Subject: : hasChanged( )post: observer update( sel f )

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

in calls on hasChanged,some update message with argumentsel f will have been sent to observer

the actual argumentdoes not matter

all thosemessages

result of message callwhether it has finished

its actual parameter value

UML 2.0 Tutorial (v4) 202a Object Constraint LanguageInitial values and derived properties


66/244


Initial values fix the initial value of a property of a classifier

package Booking

context Passenger: : statusinit: 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: sel f - >col l ect ( booking)- >sel ect ( date =today( ) ) . flight- >asSequence( )

UML 2.0 Tutorial (v4) 212a Object Constraint LanguageQuery bodies and model features


67/244


Bodies of { query } operations define the value returned by a query operation

can be combined with a precondition

context TravelHandling: : delay( ) : Minutesbody: tsh.delay- >sum( )

context TravelStageHandling

def: i sEar l y( ) : Bool ean = sel f.delay < 0

context TravelHandlingdef: someEar l y( ) : Bool ean = tsh- >exi st s( i sEar l y( ) )

Definition of additional model features defined for the context classifier

UML 2.0 Tutorial (v4) 222a Object Constraint LanguageUML/OCL 1.x vs. UML/OCL 2.0


68/244


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

UML 2.0 Tutorial (v4) 232a Object Constraint LanguageWrap up


69/244


Formal language for specifying invariants context Cinv: I

pre-/post-conditions context C: :op( ) : T

pre: Ppost: Q query operation bodies context C: :op( ) : Tbody: e

initial values context C: :p : Tinit: e

derived attributes context C: :p : Tderive: e

modeling attributes and operations context Cdef: p : T = e

Side-effect free Typed language OCL specifications provide

verification conditions

assertions for implementations



70/244


Unified Modeling Language 2.0Part 2b Profiles

Dr. Harald StrrleUniversity of Innsbruck



UML 2.0 Tutorial (v4) 22b ProfilesA first glimpse


71/244


UML 2.0 Tutorial (v4) 32b ProfilesUsage scenarios


72/244


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

UML 2.0 Tutorial (v4) 42b ProfilesStereotypes 1)


73/244


Stereotypes define how an existing UML) metaclass may beextended.optional

Stereotypes may be applied textually or graphically.

The UML specification does not tell how to define avisual stereotype.

Visual stereotypes may replace original notation.

But the element name should appear below the icon

extension

lower-case initial

UML 2.0 Tutorial (v4) 52b ProfilesStereotypes 2)


74/244


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.

UML 2.0 Tutorial (v4) 62b ProfilesProfiling


75/244


Profiles package extensions.

UML 2.0 Tutorial (v4) 72b ProfilesMetamodel


76/244


Based on infrastructure library constructs Class, Association, Property, Package, PackageImport

UML 2.0 Tutorial (v4) 82b ProfilesMetamodeling with Profiles


77/244


Profile extension mechanism imposes restrictions on how the UMLmetamodel 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 andmetaclass.

Stereotypes metaclasses below UML metaclasses. How to introduce meta-associations between stereotypes?

1. Add constraints specializing some existing associations2. Extend metaclass Dependency by a stereotype and define

specific constraint on this stereotype

Access to stereotypes in OCL via v. st er eot ype

UML 2.0 Tutorial (v4) 92b ProfilesUML 1.x vs. UML 2.0


78/244


UML 1.x String-based extension

mechanism Stereotypes

Tagged values

UML 2.0 Stereotypes are metaclasses

Tagged values replaced bymeta-properties

Required extensions Packaging of extensions intoprofiles

UML 2.0 Tutorial (v4) 102b ProfilesWrap up


79/244


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



80/244


Unified Modeling Language 2.0Part 2c Systems Modeling Language

(SysML)Prof. Dr. Harald StrrleUniversity of Innsbruck



UML 2.0 Tutorial (v4) 22c SysMLSysML as an example for a UML profile


81/244


Nowadays very much talkedabout: Systems Modeling

Language (SysML).

UML 2.0 Tutorial (v4) 32c SysMLSysML vs. UML


82/244


Protracted struggle between twocompeting proposals fueld bymassive commercial interests. New standard ptc/06-05-04finally adopted by OMG just nowMay 2006). Apart from mere customization tomatch systems engineeringstandards and terminology, it alsointroduces some physical aspects:

continuous flows, handling of physical items.

outside of what can bedescribed with UML means?

official OMG diagram

UML 2.0 Tutorial (v4) 42c SysMLDiagram tpes of SysML


83/244


official OMG diagram

class diagram

significant new aspects:-item flow-continuous variables-activation disabling- control operators

assembly diagramassembly diagram

UML 2.0 Tutorial (v4) 52c SysMLWrap up


84/244


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 thedirection of Petri-nets.



85/244


Unified Modeling Language 2.0Part 3 - Use Cases




UML 2.0 Tutorial (v4) 23 - Use CasesA first glimpse


86/244


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

UML 2.0 Tutorial (v4) 33 - Use CasesHistory and predecessors


87/244


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

UML 2.0 Tutorial (v4) 43 - Use CasesUsage scenarios


88/244


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-architectingpre-OO systems

UML 2.0 Tutorial (v4) 53 Use CasesTypes of use cases


89/244


The UML provides only the concept of use case. In manyapplications, however, there are two fundamentally different kinds ofuse 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

UML 2.0 Tutorial (v4) 63 - Use CasesMain concepts (concrete syntax)


90/244


Actor

Class (also possible: Component)

extends(is a Dependency)

UseCase

includes

(is a Dependency)

Association

UML 2.0 Tutorial (v4) 73 - Use CasesInclusion extension


91/244


Inclusion plain old call

directed from caller to callee

may occur once or many times

Extension covers variant or exceptional

behavior

relationship is directed fromexception to standard case

may or may not occur occurs at most once

UML 2.0 Tutorial (v4) 83 - Use CasesExtension points


92/244


An extension occurs at a (named)ExtensionPoint, when a specificcondition is satisfied. In a way, ExtensionPoints aresimilar to user exits or hooks.

In real world systems, there arem ny ExtensionPoints, most ofwhich are poorly documented.

UseCase with ExtensionPoint,alternative syntax suitable forlarge numbers of ExtensionPoints

ExtensionPoint

UML 2.0 Tutorial (v4) 93 - Use CasesAny level of abstraction is ok


93/244


A use case represents an individualfunctionality of a system. Systems exist on every level of

granularity. Thus, use cases may be used forfunctionality of any granularity :

from high level businessprocesses,

via (web) services,

to individual methods orfunctions.

UML 2.0 Tutorial (v4) 103 - Use CasesEmulating function trees


94/244


Structured methods relied onfunctional decomposition. Although this is not state of the art

these days, and UseCases havebeen introduced in an attempt toget away from it: many systems out there are

constructed using these

principles, many people out there have

this mindset.

For e.g. reengineering purposes, itis frequently helpful to be able torepresent function trees. This can be done using UseCasesand Includes-Relationships.

UML 2.0 Tutorial (v4) 113 - Use CasesGeneralization


95/244


As for all Classifiers, UseCasesmay be arranged in taxonomichierarchies. This is particularly useful forcatalogues of functionalities.

From methodological point ofview, abstract use cases are similarto functional subsystems.

UML 2.0 Tutorial (v4) 123 - Use CasesSemantics


96/244


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 thistutorial.

UML 2.0 Tutorial (v4) 133 - Use CasesUML 1.x vs. UML 2.0


97/244


no changes conceptually slight adaptations in the metamodel

UML 2.0 Tutorial (v4) 143 - Use CasesWrap up


98/244


Use cases may be used to represent a high-level view offunctionality, 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 describinguse cases.

Basically, use cases in UML 2.0 are the same as in UML 1.x.



99/244


Unified Modeling Language 2.0Part 4 - Architecture




UML 2.0 Tutorial (v4) 24 - ArchitectureA first glimpseContext & domain architecture Composite structure

(assembly) diagrams


100/244


Context & domain architecture Composite structure(assembly) diagrams

Collaboration

Deployment

UML 2.0 Tutorial (v4) 34 - ArchitectureHistory and Predecessors Context and domain architecture diagram

1970 SADT t l t l l DFD t t di


101/244


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

UML 2.0 Tutorial (v4) 44 - ArchitectureUsage Scenarios / Architectural views Context diagram

define the systems boundaries in terms of its users and neighbor


102/244


define the system s boundaries in terms of its users and neighborsystems

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

UML 2.0 Tutorial (v4) 54 - ArchitectureMain concepts: Composite structure diagramsbetter name: assembly diagrams


103/244


Part

Port

interfaceof a Part Connector

Actor

a system as aClass or a

Component

Partwith visualstereotype

Portwith visualstereotype

UML 2.0 Tutorial (v4) 64 - ArchitectureUsage: Stepwise refinement


104/244


UML 2.0 Tutorial (v4) 74 - ArchitectureUsage: Quantity structures Quantity structures are


105/244


indispensable for the dimensioningof large systems: numbers of (concurrent) users,

amount of data traffic on agiven interface,

availability, MTBF,

number of (collaborating)

systems or components(dynamic architectures).

Quantity structures are notcovered directly in UML so we needto use comments but thats noproblem).

UML 2.0 Tutorial (v4) 84 - ArchitectureUsage: Plumbing components together Connecting Ports amounts to

delegate/call-Dependencies


106/244


delegate/call Dependencies.

Using the joint-notation revealsdetails about the number anddirection of connections.

From left to right:

two connectors, one in eachdirection one connector with direction and one connector withoutdirection.

UML 2.0 Tutorial (v4) 94 - ArchitectureComponents UML 1.x components were just binaries. In UML 2.0, components are


107/244


defined much more comprehensively. A component represents a modular part of a system that

encapsulates its contents and whose manifestation is replaceablewithin 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 requiredinterfaces (encompassing both their static as well as dynamicsemantics). One component may therefore be substituted by

another only if the two are type conformant. []

A component is modeled throughout the development life cycle[].

UML 2.0 Tutorial (v4) 104 - ArchitectureMetamodel: Parts and ports


108/244


dashed outlines:defined in another package

UML 2.0 Tutorial (v4) 114 - ArchitectureCollaboration The purpose of collaborations is toabstractly describe a form of


109/244


linkage without being specific.

Declared as the way to describedesign and analysis patterns. Might help in early stages ofarchitectural design. Could also be used to describeglobal constraints. May be nested and composed. Methodologically, Collaborationsare the structural equivalent to

UseCases.

UML 2.0 Tutorial (v4) 124 - ArchitectureSystem structureN d

CommunicationPathis a kind ofAssociation


110/244


Node

Commentfor quantitative information

Association

UML 2.0 Tutorial (v4) 134 - ArchitectureStereotyping


111/244


UML 2.0 Tutorial (v4) 144 - ArchitectureDeployment A Deployment is a mapping ofartifacts to system nodes.


112/244


Artifacts may include

binaries component instances

System nodes may include

hardware (Device) software (ExecutionEnvironment)

Formally, a deployment is aDeployment Relationship.

It may be presented either asplacing the deployed items or theirnames on the deployment target.

Artifact

Node may be specialized to eitherDevice or

ExecutionEnvironment

UML 2.0 Tutorial (v4) 154 - ArchitectureMetamodel: Deployment


113/244


dashed outlines:defined in another package

UML 2.0 Tutorial (v4) 164 - ArchitectureSemantics Mappings from assemblies to Architecture Description LanguagesADLs) or SDL should be possible. Is it much use? Can there be a


114/244


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 ofapplication servers.

UML 2.0 Tutorial (v4) 174 - ArchitectureUML 1.x vs. UML 2.0UML 1.x UML 2.0


115/244


system boundary

components are binaries patterns as templates

Parts/Ports artifacts components are life cycle units patterns =collaborations) are nowfirst class citizens

UML 2.0 Tutorial (v4) 184 - ArchitectureWrap up Popular concepts of architectural modeling capsule/actor, port)have finally been included into UML. The metamodeling is a little


116/244


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.



117/244


Unified Modeling Language 2.0Part 5 - Activities

Prof. Dr. Harald StrrleUniversity of InnsbruckMGM technology partners


UML 2.0 Tutorial (v4) 25 - ActivitiesA first glimpse


118/244


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 muchextended.

UML 2.0 Tutorial (v4) 35 - ActivitiesHistory and predecessors 1962

Petri-nets


119/244


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)

UML 2.0 Tutorial (v4) 45 - ActivitiesUsage scenarios Activity diagrams have applications throughout the wholesoftware life cycle for many purposes.


120/244


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 automatedjobs

Implementation document existing programs (i.e. functions, services, )

design algorithmic processes with an intention ofturning them into implementation language code

UML 2.0 Tutorial (v4) 55 - ActivitiesMain concepts


121/244


Partition

InitialState

FinalState

ActivityEdge

ObjectNode

ActivityNode

MergeNode

DecisionNode

JoinNode

ForkNode

ObjectFlow

UML 2.0 Tutorial (v4) 65 - ActivitiesMain concepts


122/244


FlowFinal

stereotyped

ObjectNode

refined Activity

Partitionsmay be representedexplicitly

UML 2.0 Tutorial (v4) 75 - ActivitiesPins Data flow may be represented

explicitly,


123/244


by dataflow nodes attached to control flow,

by Pins on Activities, or

as combinations.

Pin

UML 2.0 Tutorial (v4) 85 - ActivitiesActivity parameters Pins act as parameters for Activities.


124/244


ActivityParameter

UML 2.0 Tutorial (v4) 95 - ActivitiesPin typesPin typea) streaming


125/244


) gb) streaming

c) exceptiond) unidirectionale) collection data

Parameter setsa) {x, y}

b) {x}, {y}c) {x}, {x, y}

ParameterSet may be used to define applicable sets of parameters

UML 2.0 Tutorial (v4) 105 - ActivitiesData flow details Data flow defines the transport ofdata items between buffers by


126/244


activities.

Buffers may have capacities andorderings.

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 thestate of a data item in a buffer.

UML 2.0 Tutorial (v4) 115 ActivitiesStreaming Streaming means that data isprocessed pipeline-style.


127/244


Streaming-like behavior was notexpressible in UML 1.x.

Streaming is expressed by solid black pins

explicit annotation at pins

black arrowhead arcs, or

stream mode at expansionregions.

UML 2.0 Tutorial (v4) 125 - ActivitiesExceptionsExceptionEdge


128/244


handler ActivityException

unhandled

Exception

UML 2.0 Tutorial (v4) 135 - ActivitiesRaising exceptionsInterruptibleActivityRegion


129/244



5 - ActivitiesExpansion regions for mass data processing Activities are often used to specifyprocessing of mass data batchruns) rather than individual items.


130/244


UML offers ExpansionRegions tosupport this usage scenario.

An expansion region declares aportion of an activitiy as applicableto a whole bunch of items.


5 - ActivitiesExpansion Regions An expansion region may be processed in one of three modes

iterative,

concurrent


131/244


concurrent,

stream.


5 - ActivitiesStructured nodes Structured nodes for

sequence,

loop


132/244


loop,

conditional.

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


5 - ActivitiesMetamodel


133/244



5 ActivitiesSemantics The standard declares Petri-likesemantics. The naive approach is

intuitive for simple control anddata flow


134/244


data flow

reasonable for structured

nodes technically difficult for

exceptions

a little awkward for streams

and ExpansionRegions.

There are a number of semanticalproblems, though, and integratingthe bits and pieces is a challenge. Still, it is the most convincingapproach so far.


5 ActivitiesSemantics: Petri-net vs. CCS


135/244


Spot

the

error!


5 ActivitiesProblem 1: Scope of exceptions


136/244



5 ActivitiesProblem 2: Accidental synchronization of streams


137/244



5 ActivitiesProblem 3: Traverse-to-completion Transforming an Activity into a Petri-net following the naiveapproach results in artificial places that have no direct equivalent inthe underlying Activity.


138/244


The UML, however, disallows buffering in control nodes.


5 - ActivitiesSemantics The standard declares that activities have a Petri-like semantics,but lacks a formal definition of what that means.


139/244


A straight-forward approach of mapping activities to Petri-nets soonruns into a semantic quagmire.

Other algorithmic target languages e.g. BPEL or Workflow ExecutionLanguages), and other formalisms e.g. CCS) would encounter thesame problems, plus their own.

Abstract descriptions using special-purpose logics are only at thebeginning.

Many open questions that will trouble us for some time to come.


5 ActivitiesUML 1.x vs. UML 2.0UML 1.x ActivityGraph subclass of StateMachine

UML 2.0 Activity on same level as StateMachine


140/244


thus implicit rtc-semantics new Petri-like semantics Many new concepts

Exceptions

InterruptibleActivityRegion

ExceptionEdge, ProtectedNode

StructuredNodes FlowFinal

Streaming

Collection data

ActivityParameters

Many new notations Pins, attached dataflow

notation,


5 - ActivitiesWrap up Presents control flow and data flow for analysis, design, and implementationlevel models. StateMachine


141/244


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 t algorithmic description language not only within the UML.



142/244


Unified Modeling Language 2.0Part 6 State machines

Dr. Harald StrrleUniversity of InnsbruckMGM technology partners



6 State machinesHistory and predecessors 1950s: Finite State Machines

Huffmann, Mealy, Moore


143/244


1987: Harel Statecharts conditions

hierarchical (and/or) states

history states

1990s: Objectcharts adaptation to object orientation

1994: ROOM Charts run-to-completion (RTC) step


Object life cycle Behavior of objects according to business rules

in particular for active classes

6 State machinesUsage scenarios


144/244


Use case life cycle Integration of use case scenarios

Alternative: activity diagrams

Control automata Embedded systems

Protocol specification Communication interfaces


6 State machinesStates and transitions State machines model behavior

using states interconnected

with transitions triggered


145/244


simple State

trigger (CallEvent) guard (Constraint)initial Pseudostate

FinalStateeffect (CallAction)Transition

by event occurrences.


Context

6 State machinesRelation to class diagrams State machines are defined in the context of a BehavioredClassifier.


146/244


defines which events canoccur

features areavailable

Operation

corresponding CallEvent

called Operation

CallAction


6 State machinesTriggers and events 1)SignalEvent


147/244


ChangeEventTimeEvent

(relative)

completionevent(no explicittrigger)

deferred

event


6 State machinesTriggers and events 2) CallEvent

receipt of a (a)synchronousOperation call

triggering after Behaviorof Operation executed


148/244


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


6 State machinesTriggers and events 3) completion event

raised when all internal activities of a state are finished do activity, subregion

no metamodel element for completion events


149/244


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


6 State machinesBehaviors

exit Behavior


150/244


entry Behavior

(on entering a state)

e t Behavior(on exiting a state)

do activity Behavior(concurrently whilein state, may be

interrupted)


6 State machinesHow state machines communicateevent pool event pool


151/244


networkstarts new RTC-step

signals: asynchronous no waiting)calls: asynchronous or synchronous waiting for RTC of callee)

during

run-to-completion (RTC)

No assumptions are made on timing betweenevent occurrence, event dispatching, and event consumption.Event occurrences for which no trigger exists may be discarded

(if they are not deferred).


6 State machinesHierarchical states 1) 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


152/244


composite State

entry and exit points

Transition triggering is prioritized inside-out, i.e., transitions deeper in the hierarchyare considered first.


6 State machinesHierarchical states 2)

detailed


153/244


(non-orthogonal)composite State

Region

substates

default entry


154/244


6 State machinesForks and joinsall Regions must beentered simultaneously

all Regions are leftsimultaneously(if FinalStates are reached)


155/244


fork Pseudostate(one incoming, at least two outgoing Transitions;outgoing Transitions must target States in different Regions of an orthogonal State)

joinPseudostate(restrictions dual to forks)


Entry and exit points Pseudostates) provide better encapsulation of composite states

help avoid unstructured transitions

6 State machinesEntry and exit points 1)

exit point (on border of state machine


156/244


entrypoint

exit point (on border of state machine

diagram or composite state)


6 State machinesEntry and exit points 2)Notational alternatives


157/244


Semantically equivalent

unstructured transitions


6 State machinesHistory states History states represent the last active substate (shallow history), or

configuration (deep history)


158/244


shallow history Pseudostate(enter last State in this Region)

deep history Pseudostate(enter last States in this Regionand all sub-Regions)

of a region.


6 State machinesMetamodel


159/244



6 State machinesRun-to-Completion Step: Overview


160/244


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


6 State machinesRun-to-Completion Step: Preliminaries 1) 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


161/244


Least-common-ancestor LCA) of states s1 and s2 the least region or orthogonal state (upwards) containing s

1ands

2

bold: active state configuration bold: LCA of states A1 and A2


6 State machinesRun-to-Completion Step: Preliminaries 2) 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 outgoingtransitions are evaluated dynamically (in contrast to junctions)


162/244


transitions are evaluated dynamically (in contrast to junctions)

several source and target states


6 State machinesRun-to-Completion Step: Preliminaries 3) 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


163/244


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 t

1and t

2not empty

Priority of compound transition t1 over t2 si deepest source state of transition ti s

1(direct or transitive) substate of s

2


6 State machinesRun-to-Completion Step 1)RTC(env, conf )

eventf et ch()

step choose steps(conf, event)step = event deferred(conf )


164/244


if step eventdeferred(conf)then def er (event)fifor transitionstep doconf handleTransition(env, conf, transition)od

if isCall (event) eventdeferred(conf)then acknowl edge(event)ficonf


6 State machinesRun-to-Completion Step 2)steps(env, conf, event)

transitionsenabled(env, conf, event){step | (guard, step) steps(conf, transitions) env guard }


165/244


steps(conf, transitions) steps {(false, )}for transitiontransitions do

for guard, step) steps(conf, transitions \ {transition}) doif inConflict(conf, transition, step)then if higherPriority(conf, transition, step)

then guardguard guard(transition) fielse stepstep {transition}guardguardguard(transition) fi

stepssteps {(guard, step)} od odsteps


6 State machinesRun-to-Completion Step 3)handleTransition(conf, transition) for stateinsideOut(exited(transition)) do

uncompl et e(state)

for timertimers(state) do st opTi mer (timer) od


166/244


execut e(exit(state))confconf\ {state}

odexecut e(effect(transition))

for stateoutsideIn(entered(transition)) doexecut e(entry(state))

for timertimers(state) do st ar t Ti mer (timer) odconfconf {state}compl et e(conf, state)

odconf


6 State machinesSemantic variation points Some semantic variation points have been mentioned before.

delays in event pool

handling of deferred events

entering of composite states without default entry


167/244


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


6 State machinesState machine refinement

not refined(may be omitted)

State machines arebehaviors and may thusbe refined.


168/244

(c) 2005-2006, Dr. H. Strrle, Dr. A. Knappno refinement possible


6 State machinesProtocol state machines Protocol state machines specify which behavioral features of aclassifier can be called in which state and under which condition andwhat effects are expected.

particularly useful for object life cycles and ports


169/244


precondition

postcondition

specified operation

ProtocolTransition

no effects on transitions, only effect descriptions


6 State machinesProtocol state machinesSeveral operation specifications are combined conjunctively:

context C: :op( )

pre: i nSt at e( S1) and P

1

post: Q1and i nSt at e( S

3)


170/244


context C: :op( )

pre: i nSt at e( S2) and P

2

post: Q2and i nSt at e( S

4)

results incontext C: :op( )

pre: ( i nSt at e( S1) and P1) or ( i nSt at e( S2) and P2)

post: ( i nSt at e@pr e( S1) and P

1@pr e) implies ( Q

1and i nSt at e( S

3) )

and ( i nSt at e@pr e( S2) and P

2@pr e) implies ( Q

2and i nSt at e( S

4) )


6 State machinesUML 1.x vs. UML 2.0 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


171/244


New encapsulation means entry and exit points

Protocol state machines side-effect free

Clarification of semantic variation points but, still, no formal semantics


6 State machinesHow things work together Static structure

sets the scene for state machine behavior

state machines refer to properties

b h i l f ( i i )


172/244


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 (Ocl Message) Protocols and components

state machines may specify protocol roles


6 State machinesWrap up State machines model behavior

object and use case life cycles

control automata

protocols


173/244


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.



174/244


Unified Modeling Language 2.0Part 7 - Interactions

Dr. Harald StrrleUniversity of InnsbruckMGM technology partners



7 - InteractionsA first glimpse

sequence diagram


175/244


communicationdiagram

timing diagram

all three aresemantically

equivalent


7 - InteractionsHistory and predecessors simple sequence diagrams

1990s Message Sequence Charts (MSCs) used in TelCo-industry several OO-methods use sequence diagrams

complex sequence diagrams1996: Complex MSCs introduced in standard MSC961999 Lif S Ch t (LSC )


176/244


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)


7 - InteractionsUsage scenarios Class/object interactions

design or document message exchange between objects express synchronous/asynchronous messages, signals

and calls, activation, timing constraints

Use case scenariosill t t b t i


177/244


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 o

UML 2.0 Tutorial

Documents