01-2 bock behavioral modeling tutorial

8/8/2019 01-2 Bock Behavioral Modeling Tutorial

1/155


2/155


3/155

Behavioral Modeling with UML 3

Tutorial Series! Lecture 1: Introduction to UML:

Structural and Use Case Modeling! Lecture 2: Behavioral Modeling with

UML! Lecture 3: Advanced Modeling with UML

[Note: This version of the tutorial series is based onOMG UML Specification v. 1.4, UML Revision Task Force recommended final draft,OMG doc# ad/01-02-13.]


4/155


Tutorial Goals! What you will learn:

! what the UML is and what is it not!

UMLs basic constructs, rules and diagramtechniques! how the UML can model large, complex systems! how the UML can specify systems in an

implementation-independent manner! how UML, XMI and MOF can facilitate metadata

integration! What you will not learn:

! Object Modeling! Development Methods or Processes! Metamodeling


5/155


! The UML is a graphical language for! specifying! visualizing! constructing! documenting

the artifacts of software systems! Added to the list of OMG adopted technologies in

November 1997 as UML 1.1! Most recent minor revision is UML 1.3, adopted in

November 1999!

Next minor revision will be UML 1.4, planned to beadopted in Q2 2001! Next major revision will be UML 2.0, planned to be

completed in 2002

Quick Tour


6/155


UML Goals! Define an easy-to-learn but semantically rich visual

modeling language! Unify the Booch, OMT, and Objectory modeling

languages! Include ideas from other modeling languages! Incorporate industry best practices! Address contemporary software development issues

! scale, distribution, concurrency, executability, etc.! Provide flexibility for applying different processes! Enable model interchange and define repository

interfaces


7/155


OMG UML Evolution

UML 1.1

UML 1.2

UML 1.3

UML 1.4

UML 2.0

Q3 1997(OMG AdoptedTechnology)

Q2 1998

Q3 1999

Q3 2000(planned minor revision)

2001(planned major revision)

Editorial revisionwith no significanttechnical changes.

ISO PubliclyAvailable

Specifications(PAS)

Other relevantstandards TBA

Unification of majormodeling languages,including Booch, OMTand Objectory


8/155


OMG UML 1.3 Specification! UML Summary! UML Semantics! UML Notation Guide! UML Standard Profiles

! Software Development Processes! Business Modeling

! UML CORBAfacility Interface Definition! UML XML Metadata Interchange DTD! Object Constraint Language


9/155


Tutorial Focus: the Language! language = syntax + semantics

! syntax = language elements (e.g. words)are assembled into expressions (e.g.phrases, clauses)

! semantics = the meanings of the syntacticexpressions

! UML Notation Guide defines UMLsgraphic syntax

! UML Semantics defines UMLssemantics


10/155


11/155


Language Architecture! Metamodel architecture! Package structure


12/155


Metamodel Architecture

MOF Meta-metamodel

UML Metamodel

User Model

:Foo

Meta-Metamodel Layer(M3): Specifies meta-metaclasses for theUML metamodel

Metamodel Layer (M2):Specifies metaclassesfor the UMLmetamodel, such asClass

Model Layer (M1): Specifiesclasses for the UML usermodels, such asPassenger, Ticket,TravelAgency

User Objects Layer (M0):User objects that areinstances of UML usermodel classes, such asinstances of Passenger,Ticket, TravelAgency

:Bar :Baz


13/155


Package Structure

UML

ModelManagement

BehavioralElements

Foundationpackage

dependency


14/155


Package Structure

Collaborations State Machines Activity Graphs

Behavioral Elements

Model

Management

Foundation

Use Cases

CommonBehavior


15/155


Behavioral Modeling! Part 1: Interactions and Collaborations! Part 2: Statecharts! Part 3: Activity Diagrams


16/155


Interactions! What are interactions?! Core concepts! Diagram tour! When to model interactions! Modeling tips! Example: A Booking System


17/155


What are interactions?! Interaction: a collection of

communications between instances,including all ways to affect instances,like operation invocation, as well ascreation and destruction of instances

! The communications are partiallyordered (in time)


18/155


Interactions: Core Elements

name

attr values

Instance(object,data value,componentinstanceetc.)

An entity with a unique identity andto which a set of operations can beapplied (signals be sent) and whichhas a state that stores the effects of the operations (the signals).

Action A specification of an executablestatement.A few different kinds of actions arepredefined, e.g. CreateAction,CallAction, DestroyAction, andUninterpretedAction.

Construct Descr iption Syntax

textual


19/155


Interaction: Core Elements(contd)

Stimulus A communication between twoinstances.

Operation A declaration of a service that can

be requested from an instance toeffect behavior.


textual

A specification of an asynchronousstimulus communicated between

instances.

Signal SignalName

parameters


20/155


Interaction: Core Relationships

Link A connection between instances.

Attr ibute Link A named slot in an instance, whichholds the value of an attribute.


textual


21/155


Example: Instance

triangle : Polygon

center : Point = (2,2)vertices : Point* = ((0,0), (4, 0), (2,4))borderColor : Color = black fillColor : Color = white

triangle : Polygon

triangle

: Polygon

underlined name

attribute links


22/155


Example: Instances and Links

Joe : Person Jill : Person

: Family

husband wife


23/155


Operation and Method

Triangle

+ move ( in dist : Point)+ scale ( in factor : Real)

foreach v in vertices do

v.x := v.x + dist.x;v.y := v.y + dist.y

foreach v in vertices dov.x := factor * v.x;v.y := factor * v.y


24/155


Interaction Diagram Tour! Show interactions between instances in

the model! graph of instances (possibly including links)

and stimuli! existing instances! creation and deletion of instances

! Kinds!

sequence diagram (temporal focus)! collaboration diagram (structural focus)


25/155


Interaction Diagrams

x y z

Sequence Diagram

a

b

c

Collaboration Diagram

x y

z

1.1: a1.2: c

1.1.1: b


26/155


Sequence Diagram

name : Classobject symbol

lifeline

activation

other

stimulus

name ()

return

: Class

create

new ()

delete


27/155


Arrow Label

predecessor sequence-expression return-value := message-name argument-list

3.7.4: move (5, 7)

A3, B4 / C3.1: res := getLocation (fig)

predecessor sequence numberreturn value message name argument list

move (5, 7)

3.7 *[1..5]: move (5, 7) iteration

3.7 [ z > 0 ]: move (5, 7) condition


28/155


Different Kinds of Arrows

Procedure call or otherkind of nested flow of

control

Flat flow of control

Explicit asynchronousflow of control

Return

UML 1.4: Asynchronous

UML 1.4: Variant of async


29/155


Example: Different Arrows

caller exchange callee

Flat Flow

lift receiver

dial tone

dial digit

dial digit

ringing tone ringing signal

lift receiver

teller : Order : Article

Nested Flow

getValue

price

getName

appl err handl alarm

Asynchronous Flow

unknown

alarm

UML 1.4: Asynchr onous flowUML 1.4: Alternative notat ionfor async flow


30/155


Recursion, Condition, etc.

calculator filter value

[ x < 0]: transform ()

[ x > 0]: getValue ()

getValue ()

iterate ()


31/155



redisplay ()stimulus

1: displayPositions (window)

1.1 *[i := 1..n]: drawSegment (i)

: Controller : Window

wire :Wire {new}: Line

left : Bead right : Bead

1.1.1a: r0 := position () 1.1.1b: r1 := position ()

wire

local line

contents {new}

window

self

window parameter

1.1.2: create (r0, r1)1.1.3: display (window)

1.1.3.1 add (self)

object symbol link symbol

standard stereotype

standard stereotype

standard stereotype

standard constraint

standard constraint


32/155


When to Model Interactions! To specify how the instances are to

interact with each other.! To identify the interfaces of the

classifiers.! To distribute the requirements.


33/155


Interaction Modeling Tips! Set the context for the interaction.! Include only those features of the instances

that are relevant.! Express the flow from left to right and from

top to bottom.! Put active instances to the left/top and

passive ones to the right/bottom.! Use sequence diagrams

! to show the explicit ordering between the stimuli!

when modeling real-time! Use collaboration diagrams

! when structure is important! to concentrate on the effects on the instances


34/155


Example: A Booking System


35/155


Use Case Description: Change Flt Itinerary

! Actors: traveler, client account db, airlinereservation system

! Preconditions: Traveler has logged in! Basic course:

! Traveler selects change flight itinerary option! System retrieves travelers account and flight itinerary from client account

database! System asks traveler to select itinerary segment she wants to change;

traveler selects itinerary segment.! System asks traveler for new departure and destination information;

traveler provides information.! If flights are available then !

! System displays transaction summary.

! Alternat ive course:! If no flights are available then


36/155


Sequence Diagram: Change Flight Itinerary

: Booking SystemTraveler Airline Reservation System

change flight itinerary

get customer account

get itinerarypresent itinerary

select segment

present detailed info

update informationavailable flight

::

Client Account DBMSClient Account DBMS


37/155


Collaboration Diagram: Change Flt Itinerary

Traveler Client Account DBMS

Airline Reservation System

: Booking System

7: update information

2: get customer account3: get itinerary

4: present itinerary

8: available flight

1: change flight itinerary5: select segment

6: present detailed info

C ll b i


38/155


Collaboration! What is a collaboration?! Core concepts! Diagram tour! When to model collaborations! Modeling tips! Example: A Booking System

Wh t i ll b ti ?


39/155


What is a collaboration?! Collaboration: a collaboration defines

the roles a set of instances play when

performing a particular task, like anoperation or a use case.! Interaction:an interaction specifies a

communication pattern to be performedby instances playing the roles of acollaboration.

C ll b i C El t


40/155


Collaborations: Core Elements

Collaboration A collaboration describes how anoperation or a classifier, like ause case, is realized by a set of classifiers and associations usedin a specific way.

The collaboration defines a set of roles to be played by instancesand links, possibly including acollection of interactions.


Name

An interaction describes acommunication pattern betweeninstances when they play theroles of the collaboration.

Interaction

C ll b i C El t ( d)


41/155


Collaborations: Core Elements(contd)

Collaboration-Instance

A collection of instances whichtogether play the roles declaredin a collaboration.


Name

A collection of stimuliexchanged between instancesplaying specific roles accordingto the communication pattern of an interaction.

Interaction-Instance

All new in UML 1.4

C ll b i C El t ( d)


42/155


Collaborations: Core Elements(contd)

ClassifierRole

A classifier role is a specific roleplayed by a participant in acollaboration. It specifies a restrictedview of a classifier, defined by whatis required in the collaboration.

Message A message specifies onecommunication between instances.It is a part of the communicationpattern given by an interaction.


/ Name

label

C ll b ti Core Relationships


43/155


Collaborations: Core Relationships

AssociationRole An association role is a specificusage of an association neededin a collaboration.

Generalization A generalization is a taxonomicrelationship between a moregeneral element and a morespecific element. The morespecific element is fully consistent

with the more general element.


Classifier Instance Role Trichotomy


44/155


Classifier-Instance-Role Trichotomy

! An Instance is anentity with behaviorand a state, and hasa unqiue identity.

! A Classifier is adescription of anInstance.

! A Classifier Roledefines a usage (anabstraction) of anInstance.

id

ClassName

/ RoleName

originates from

conforms to

view of

Classifier Instance Role Trichotomy( td)


45/155


Classifier-Instance-Role Trichotomy(contd)

ClassifierRoleClassifier

Operation-1 ()Operation-2 ()Operation-3 ()

Attribute-1Attribute-2Attribute-3

Instance

AttributeValue-1

AttributeValue-2AttributeValue-3

Operation-1 ()Operation-3 ()

Attribute-1Attribute-2

originates from conforms to

The attribute values of an Instance corresponds to the attributes of itsClassifier.

All attributes required by the ClassifierRole have corresponding attributevalues in the Instance.All operations defined in the Instances Classifier can be applied to theInstance.All operations required by the ClassifierRole are applicable to the Instance.

Different Ways to Name a Role


46/155


Different Ways to Name a Role

/ ClassifierRoleName : ClassifierName

A role name is preceeded by a /

/ Parent : PersonExample: / Parent : Person

instanceName / ClassifierRoleName : ClassifierName

Charlie / Parent Charlie / Parent : Person

Charlie : PersonExample: : Person Charlie

A classifier name is preceeded by a :

Association and Association Role


47/155


Association and Association Role

Class-1 Class-2

view of view ofview of

0..5

3..4

{changeable}

{frozen} / Role-1 / Role-2

An Association Role specifies the required

properties of a Link used in aCollaboration.The properties of an AssociationEnd maybe restricted by a AssociationEndRole.

AssociationClass Class

AssociationRoleClassifierRole ClassifierRole

Example: A School


48/155


Example: A School

/ Teacher : Person / Student : Person

: Faculty : Course

position : Text program : Text1 tutor student *

faculty member *

faculty 1

1 lecturer

given course *participant *

taken course *

Role Model vs Class Model


49/155


Role Model vs. Class Model

The Classes give the complete description while theRoles specify one usage.


: Faculty : Course

position : Text program : Text

Person

Faculty Course

name : Textposition : Textprogram : Text

1 *

1

* 1

* *

*

0..1

*

* **1

*

0..1

Extra attribute

Resulting multiplicity

Resulting multiplicity

Role Model Class Model

A Collaboration and Its Roles


50/155


A Collaboration and Its Roles

CollaborationName

Classifier-1 Classifier-2

roleName-1roleName-2

roleName-3

A Collaboration

and how its rolesare mapped ontoa collection of Classifiers andAssociations.

Patterns in UML


51/155


Patterns in UML

Observer

CallQueue SlidingBarIcon

Subject Handler

queue : List of Callsource : Object

waitAlarm : Alarmcapacity : Integer

reading : Realcolor : Color

range : Interval

Handler.reading = length (Subject.queue)Handler.range = {0..Subject.capacity}

Constraint that must be fulfilled in each instanceof this pattern.

Generalization Between Collaborations


52/155


Generalization Between Collaborations

ObserverCallQueue SlidingBarIconSubject Handler

SupervisorManagedQueue ControllerManagerSubject

All roles defined in the parent are presentin the child.

Some of the parents roles may beoverridden in the child.An overridden role is usually the parent of the new role.

Collaboration Diagram Tour


53/155


Collaboration Diagram Tour! Show Classifier Roles and Association

Roles, possibly together with extra

constraining elements! Kinds

! Instance level Instances and Links! Specification level Roles

! Static Diagrams are used for showing

Collaborations explicitly

Collaboration Diagram at Specification Level


54/155


Collaboration Diagram at Specification Level


: Faculty : Course

position : Text program : Text

1 tutor student *

faculty 1

faculty member * 1 lecturer

given course * * taken course

* participant

UML 1.4: The diagram shows the contents of a Collaboration

Collaboration Diagram at Instance Level


55/155


Collaboration Diagram at Instance Level

John / Teacher

Alice / Student

Bob / Student

Sara / Teacher

: Faculty

English : Course

faculty member

faculty member

faculty

faculty

lecturer

tutor

tutor

student

student

given course

taken course taken course

participant

participant

UML 1.4: The diagram shows the contents of aCollaborationInstance

Collaborations including Interactions


56/155


g

x y z

Sequence Diagram

a

b

c


x y

z

1.1: a1.2: c

1.1.1: b

UML 1.4: The diagrams show the contentsof a CollaborationInstance with anInteractionInstance superposed

Roles on Sequence Diagrams


57/155


q g

/ X / Y / Z

Sequence Diagram

a

b

c

UML 1.4: The diagram shows the contents of aCollaboration with an Interaction superposed

Collaboration Diagram with Constraining Elements


58/155


g g

/ Generator : Printer Device

: Laser Printer : Line Printer

Constraining Element (A Generalization is not an AssociationRole )

Static Diagram With Collaboration and Classifiers


59/155


g

ObserverCallQueue SlidingBarIconSubject Handler

SupervisorManagedQueue ControllerManagerSubject

When to Model Collaborations


60/155


! Use Collaborations as a tool to find theClassifiers.

!

Trace a Use Case / Operation ontoClassifiers.! Map the specification of a Subsystem

onto its realization (Tutorial 3).

Collaboration Modeling Tips


61/155


g! A collaboration should consist of both

structure and behavior relevant for the

task.! A role is an abstraction of an instance,

it is not a class.! Look for

! initiators (external)!

handlers (active)! managed entities (passive)


62/155


Example: A Booking System

Use Case Description: Change Flt Itinerary


63/155


! Actors: traveler, client account db, airlinereservation system

! Preconditions: Traveler has logged in! Basic course:

! Traveler selects change flight itinerary option! System retrieves travelers account and flight itinerary from client account

database! System asks traveler to select itinerary segment she wants to change;

traveler selects itinerary segment.! System asks traveler for new departure and destination information;

traveler provides information.! If flights are available then ! ! System displays transaction summary.

! Alternat ive course:! If no flights are available then

Booking System: Change Flt Itinerary Collaboration


64/155


: Traveler : Client Account DBMS

: Airline Reservation System

/ Flight Itinerary Modifier

/ ARS Protocol

/ Flight Itenerary Form / DBMS Protocol

/ Itinerary / Account

6: get itinerary

7: get itinerary1: change flight itinerary

10: present2: create modifier

5: create 8: create

3: get customer account

4: get customer account

9: display

Wrap Up: Interactions & Collaborations


65/155


! Instances, Links and Stimuli are usedfor expressing the dynamics in a model.

! Collaboration is a tool for! identification of classifiers! specification of the usage of instances! expressing a mapping between different

levels of abstraction! Different kinds of diagrams focus on

time or on structure

Behavioral Modeling


66/155


! Part 1: Interactions and Collaborations! Part 2: Statecharts! Part 3: Activity Diagrams

Overview


67/155


! Basic State Machine Concepts! Statecharts and Objects! Advanced Modeling Concepts! Case Study!

Wrap Up

Automata


68/155


ONONON

! A machine whose output behavior is not onlya direct consequence of the current input, butof some past history of its inputs

! Characterized by an internal state whichrepresents this past experience

ONONONONONON ONONON

OFFOFFOFF

State Machine (Automaton) Diagram


69/155


off

on

! Graphical rendering of automatabehavior

Lamp OnLamp OnLamp On

Lamp OffLamp OffLamp Off

offon

Outputs and Actions


70/155


! As the automaton changes state it cangenerate outputs:

on

off

Lamp Onprint(on)Lamp OnLamp Onprint(on)print(on)

Lamp

Off

LampLamp

OffOff

off

on

Moore automaton

on

off

LampOn

LampLampOnOn

Lamp

Off

LampLamp

OffOff

off

on/ print(on)print(on)

Mealy automaton

Extended State Machines


71/155


! Addition of variables (extended state)

off

on

Lamp OnLamp OnLamp On

Lamp OffLamp OffLamp Off

offon/ ctr := ctr + 1

ctr : Integerctrctr : Integer: Integer

A Bit of Theory


72/155


! An extended (Mealy) state machine is definedby:

! a set of input signals (input alphabet)! a set of output signals (output alphabet)! a set of states! a set of transitions

! triggering signal! action

! a set of extended state variables!

an initial state designation! a set of final states (if terminating automaton)

Basic UML Statechart Diagram


73/155


top

ReadyReadyReady

stop

/ctr := 0 stop

State State State

Trigger Trigger Trigger

Action Action Action

Initial pseudostate

Initial Initial pseudostate pseudostate

Transition Transition Transition

Final state Final Final state state

DoneDoneDone

top state top state top state


74/155

Event-Driven Behavior


75/155


! Event = a type of observable occurrence! interactions:

! synchronous object operation invocation (call event)! asynchronous signal reception (signal event)

! occurrence of time instants (time event)! interval expiry! calendar/clock time

! change in value of some entity (change event)! Event Instance = an instance of an event

(type)! occurs at a particular time instant and has no

duration

The Behavior of What?


76/155


! In principle, anything that manifestsevent-driven behavior

! NB: there is no support currently in UMLfor modeling continuous behavior

! In practice:! the behavior of individual objects! object interactions

! The dynamic semantics of UML state

machines are currently mainly specifiedfor the case of active objects


77/155


Basic State Machine Concepts

Statecharts and Objects Advanced Modeling ConceptsCase Study

Wrap Up

Object Behavior - General Model


78/155


! Simple server model:

HandleRequestHandleHandle

RequestRequest

InitializeObject

InitializeInitializeObjectObject

TerminateObject

TerminateTerminateObjectObject

Wait forRequestWait forWait forWait forRequestRequestRequest

void:offHook ();{busy = true;obj.reqDialtone();

};

Handling depends on

specific request type

Handling depends onHandling depends on

specific request typespecific request type

Object Behavior and State Machines


79/155


! Direct mapping:

HandleHandleEventEvent

InitializeInitialize

ObjectObject


Wait forWait forEventEvent

on

off

LampOnLampLamp

OnOn

LampOff

LampLampOffOff

off

on/print(on)

stop

Object and Threads


80/155


HandleRequest

HandleHandleRequestRequest

InitializeObject


TerminateObject


Wait forRequest

Wait forWait forRequestRequest

HandleRequest


InitializeObject


TerminateObject


Wait forRequest

Wait forWait forRequestRequest

Passive objects: depend on external power (threadof execution) Active objects: self-powered (own thread of execution)

Passive Objects: Dynamic Semantics


81/155


Encapsulation does not protect the object fromconcurrency conflicts!Explicit synchronization is still required

HandleRequest


InitializeObject


TerminateObject


Wait forRequest

Wait forWait for

RequestRequest

Active Objects and State Machines


82/155


anActiveObjectanActiveObject

##currentEventcurrentEvent : Event: Event

+ start ( )+ start ( )+ poll ( )+ poll ( )+ stop ( )+ stop ( )

! Objects that encapsulate own thread of execution

created

ready

start/^master.ready()

poll/^master.ack()

stop/

poll/defer

ready

created

start start/^master.ready() ready

Active Objects: Dynamic Semantics


83/155


Run-to-completion model:

serialized event handlingeliminates internal concurrencyminimal context switching overhead

ActiveObject:

The Run-to-Completion Model


84/155


Active1Active1Active1 Active2Active2Active2

! A high priority event for (another) activeobject will preempt an active object that ishandling a low-priority event

hihi

lo


85/155


Basic State Machine ConceptsStatecharts and Objects

Advanced Modeling ConceptsCase Study

Wrap Up

State Entry and Exit Actions


86/155


! A dynamic assertion mechanism

LampOnLampOnLampOnentry/lamp.on();

exit/lamp.off();

e1e1

e2e2

Order of Actions: Simple Case


87/155


Resulting action sequence: printf(exiting);

printf(to off);lamp.off();

Resulting action sequence:Resulting action sequence: printf printf (exiting);(exiting);

printf printf

(to off);(to off);

lamp.off();lamp.off();

! Exit actions prefix transition actions! Entry action postfix transition actions

printf(exiting); printf(needless);

lamp.off();

printf printf (exiting);(exiting); printf printf (needless);(needless);

lamp.off();lamp.off();

off/ off/ printfprintf(needless);(needless);

off/ off/ printfprintf(to off);(to off);LampOffLampOffLampOff

entry/lamp.off();entry/lamp.off();

exit/ exit/ printfprintf(exiting);(exiting);

LampOnLampOnLampOnentry/lamp.on();entry/lamp.on();


Internal Transitions


88/155


! Self-transitions that bypass entry andexit actions

LampOffLampOffLampOffentry/lamp.off();entry/lamp.off();


off/null;

Internal transitiontriggered byan off event

Internal transitionInternal transitiontriggered bytriggered byan off eventan off event

State (Do) Activities


89/155


ErrorErrorError

entry/ entry/ printfprintf(error!)(error!)

! Forks a concurrent thread that executesuntil:

!

the action completes or! the state is exited through an outgoing

transition

do/while (true) alarm.ring();

do activitydo activitydo activity

GuardsC di i l i f i i


90/155


! Conditional execution of transitions! guards (Boolean predicates) must be side-effect free

SellingSellingSelling

UnhappyUnhappyUnhappy

HappyHappyHappy

bidbid [(value >= 100) & (value < 200)] /sell /sell

bidbid [value >= 200] /sell /sell

bidbid [value < 100] /reject /reject

Static Conditional Branching

l h l h f


91/155


! Merely a graphical shortcut forconvenient rendering of decision trees

[(value >= 100) & (value < 200)] /sell /sell

[value >= 200] /sell /sell

[value < 100] /reject /reject



HappyHappyHappy

bidbid

Dynamic Conditional Branching

Ch i d d l d


92/155


bid / gain := calculatePotentialGain(value)



HappyHappyHappy

! Choice pseudostate: guards are evaluated atthe instant when the decision point is reached

[(gain >= 100) & (gain < 200)] /sell /sell

[gain >= 200] /sell /sell

[gain < 100] /reject /reject

Dynamicchoicepoint

DynamicDynamicchoicepointchoicepoint

Hierarchical State Machines

G d d k l i


93/155


! Graduated attack on complexity! states decomposed into state machines

LampFlashingLampFlashingLampFlashingflash/ flash/

1sec/ 1sec/ 1sec/ 1sec/

FlashOffFlashOffFlashOffentry/lamp.off()entry/lamp.off()

FlashOnFlashOnFlashOnentry/lamp.on()entry/lamp.on()off/ off/

LampOffLampOffLampOffentry/lamp.off()entry/lamp.off()

LampOnLampOnLampOnentry/lamp.on()entry/lamp.on()

on/ on/

on/ on/

on/ on/

Stub Notation

N t ti l h t t ti


94/155


! Notational shortcut: no semanticsignificance

LampFlashingLampFlashingLampFlashingflash/ flash/

on/ on/

FlashOnFlashOn

FlashOffFlashOff

off/ off/



on/ on/ on/ on/

Group Transitions! Hi h l l t itiD f lt t iti t

Defa lt transition toDefault transition to


95/155


LampFlashingLampFlashingLampFlashing

1sec/ 1sec/ 1sec/ 1sec/

FlashOffFlashOffFlashOffentry/lamp.off()entry/lamp.off()

FlashOnFlashOnFlashOnentry/lamp.on()entry/lamp.on()off/ off/



on/ on/

! Higher-level transitions

flash/ flash/

on/ on/

Default transition tothe initial pseudostateDefault transition toDefault transition to

the initial pseudostatethe initial pseudostate

Group transitionGroup transitionGroup transition

Completion Transitions! Triggered by a completion event


96/155


! Triggered by a completion event! generated automatically when an immediately

nested state machine terminates

CommittingCommittingCommitting

Phase1Phase1Phase1

Phase2Phase2Phase2CommitDoneCommitDoneCommitDone

completiontransition (no trigger)

completioncompletiontransition (no trigger)transition (no trigger)

Triggering Rules! Two or more transitions may have the same


97/155


LampFlashingLampFlashingLampFlashing

off/ off/ FlashOffFlashOffFlashOff

FlashOnFlashOnFlashOn

! Two or more transitions may have the sameevent trigger

! innermost transition takes precedence! event is discarded whether or not it triggers a

transition

on/

on/

Deferred Events! Events can be retained if they do not


98/155


! Events can be retained if they do nottrigger a transition

off/ off/


on/ on/


off/deferoff/defer

Deferred eventDeferred eventDeferred event

Order of Actions: Complex Case! Same approach as for the simple case


99/155


! Same approach as for the simple caseS1

exit/exS1

S1S1

exit/exS1exit/exS1

S11exit/exS11S11S11

exit/exS11exit/exS11

S2

entry/enS2

S2S2

entry/enS2entry/enS2

S21entry/enS21S21S21

entry/enS21entry/enS21

initS2initS2E/ E/ actEactE

Actions execution sequence:

exS11 " exS1 " actE " enS2 " initS2 " enS21

History! Return to a previously visited hierarchical


100/155


suspend/ suspend/

Return to a previously visited hierarchicalstate

! deep and shallow history options

DiagnosingDiagnosingDiagnosing

Diagnostic1Diagnostic1Diagnostic1

Step11Step11Step11

Step12Step12Step12

Diagnostic2Diagnostic2Diagnostic2

Step21Step21Step21

Step22Step22Step22resume/ resume/ H*H*H*

Orthogonality! Multiple simultaneous perspectives on the


101/155


Multiple simultaneous perspectives on thesame entity

ChildChild

AdultAdult

RetireeRetiree

ageage

PoorPoor

RichRich

financialStatusfinancialStatus

Orthogonal Regions! Combine multiple simultaneous descriptions


102/155


Combine multiple simultaneous descriptions

ChildChild

AdultAdult

RetireeRetiree

ageage

PoorPoor

RichRich


PoorPoor

RichRich


ChildChild

AdultAdult

RetireeRetiree

ageage

Orthogonal Regions - Semantics! All mutually orthogonal regions detect the


103/155


OutlawOutlawOutlaw

LawAbidingLawAbidingLawAbiding PoorPoorPoor

RichRichRich

financialStatusfinancialStatuslegalStatuslegalStatus

All mutually orthogonal regions detect thesame events and respond to them

simultaneously ! usually reduces to interleaving of some kind

robBankrobBank / / robBankrobBank / /

Interactions Between Regions! Typically through shared variables or


104/155


Catch22Catch22Catch22sanityStatussanityStatus flightStatusflightStatus

Typically through shared variables orawareness of other regions state changes

(flying)/ (flying)/

Crazyentry/sane := false;

CrazyCrazyentry/sane := false;entry/sane := false;

Saneentry/sane := true;

SaneSaneentry/sane := true;entry/sane := true;

requestrequestGrounding/ Grounding/

Flyingentry/flying := true;

FlyingFlyingentry/flying := true;entry/flying := true;

Groundedentry/flying := false;

GroundedGroundedentry/flying := false;entry/flying := false;

(sane)/ (sane)/

(~sane)/ (~sane)/

sane : Booleansane : Booleansane : Boolean

flying : Booleanflying : Booleanflying : Boolean

Transition Forks and Joins! For transitions into/out of orthogonal


105/155


For transitions into/out of orthogonalregions:

StaffMember

StaffStaffMemberMember

employeeemployee

ChildChildChild AdultAdultAdult RetireeRetireeRetiree

ageage

ManagerManagerManager

Common Misuse of Orthogonality! Using regions to model independent objects


106/155


Using regions to model independent objects

ChildChild

AdultAdult

RetireeRetiree

ChildChild

AdultAdult

RetireeRetiree

Person1Person1 Person2Person2

Person1Person1 Person2Person2

B i S M hi C


107/155



Advanced Modeling ConceptsCase StudyWrap Up

Case Study: Protocol Handler! A multi-line packet switch that uses the


108/155


line card 1line card 1

line card Nline card NEnd user End user

unreliable telecom lines

A multi line packet switch that uses thealternating-bit protocol as its link protocol

SWITCHSWITCH

.

.

.

ABsender

ABreceiver

End user

End user

ABsender

ABreceiver

AB protocolAB protocolAB protocol

Alternating Bit Protocol (1)! A simple one-way point-to-point packet


109/155


packetizer unpacker ReceiverSender

A simple one way point to point packetprotocol

data(1)

ackA

pktAdata(1)

ack

ack

data(2)

ackB

pktBdata(2)

ack

ack

etc.

AB protocolAB protocolAB protocol

Alternating Bit Protocol (2)! State machine specification


110/155


p

ackB/âckdata/^pktA

ackA/âck data/^pktB

timeout/^pktB

timeout/^pktA

Sender SM

AcceptPktA

WaitAckA

AcceptPktB

WaitAckB

pktA/^dataack/âckA

pktB/^dataack/âckB

timeout/âckB

timeout/âckA

RcvdPktA

WaitPktB

RcvdPktB

WaitPktA

Receiver SM

Additional Considerations! Support (control) infrastructure


111/155


pp ( )

SWITCHSWITCH

ABABreceiverreceiver

ABABsendersender

operatoroperatorinterfaceinterface

DBDBinterfaceinterface

SystemSystemoperatoroperator

DBaseDBase

AB linesAB linesmanagermanager

Control

The set of (additional) mechanisms and ti i d t b i t i t th


112/155


actions required to bring a system into the desired operational state and to maintain it in

that state in the face of various planned and unplanned disruptions

For software systems this includes:system/component start-up and shut-downfailure detection/reporting/recoverysystem administration, maintenance, andprovisioning(on-line) software upgrade

Retrofitting Control Behavior


113/155


AcceptPktA

WaitAckA

AcceptPktB

WaitAckB

Failed

JustCreated Hardware Audit

GettingData

ReadyToGo

Analysing

Failure

The Control Automaton! In isolation, the same control behavior

appears much simpler


114/155


appears much simpler

Failed

JustCreated

Hardware Audit

GettingData

ReadyToGo

Analysing

Failure

OperationalOperational


115/155

Analysing

Exploiting Hierarchical States

AbstractController


116/155


Failed

JustCreated

Hardware

Audit

GettingData

ReadyToGo

AnalysingFailure

OperationalOperational

AbstractController

Sender

B i S M hi C


117/155



Advanced Modeling ConceptsCase StudyWrap Up

Wrap Up: Statecharts! UML uses an object-oriented variant of Harels statecharts


118/155


! adjusted to software modeling needs!

Used to model event-driven (reactive)behavior! well-suited to the server model inherent in the

object paradigm! Primary use for modeling the behavior of

active event-driven objects! systems modeled as networks of collaborating

state machines! run-to-completion paradigm significantly simplifies

concurrency management

Wrap Up: Statecharts (contd)! Includes a number of sophisticated featuresthat realize common state-machine usage


119/155


that realize common state machine usagepatterns:

! entry/exit actions! state activities! dynamic and static conditional branching

! Also, provides hierarchical modeling fordealing with very complex systems! hierarchical states! hierarchical transitions! orthogonality

Behavioral Modeling! Part 1: Interactions and Collaborations

P t 2 St t h t


120/155


! Part 2: Statecharts!

Part 3: Activity Diagrams

Activity Diagram Applications! Intended for applications that need controlflow or object/data flow models


121/155


flow or object/data flow models ! ... rather than event-driven models like state

machines.! For example: business process modeling and

workflow.! The difference in the three models is how

step in a process is initiated, especially withrespect to how the step gets its inputs.

Control Flow! Each step is taken when the previous onefinishes


122/155


! regardless of whether inputs are available,accurate, or complete (pull).

! Emphasis is on order in which steps aretaken.

Not UMLNotation! Chart CourseChart Course Cancel TripCancel Trip

Analyze Weather InfoAnalyze Weather Info

Weather InfoStart

Object/Data Flow! Each step is taken when all the required inputobjects/data are available


123/155


! and only when all the inputs are available(push).

! Emphasis is on objects flowing between steps.Design ProductDesign Product

ProcureMaterialsProcure

Materials

Acquire CapitalAcquire Capital

Build

Subassembly 1

BuildSubassembly 1

Build

Subassembly 2

BuildSubassembly 2

FinalAssembly

FinalAssembly

Not UMLNotation

State Machine! Each step is taken when events aredetected by the machine


124/155


detected by the machine ! using inputs given by the event.! Emphasis is on reacting to environment.

Ready To StartReady To Start

CoinDeposited

Ready For OrderReady For OrderSelectionMade

DispenseProduct

DispenseProduct

ReturnChange

ReturnChange

Cancel ButtonPressed

Not UMLNotation

Activity Diagrams Based on State Machines

! Currently activity graphs are modeledas a kind of state machine.


125/155


as a kind of state machine.! Modeler doesn't normally need to be

aware of this sleight-of-hand ...! ... but will notice that "state" is used in

the element names.! Activity graphs will become independent

of state machines in UML 2.0.


126/155

Action (State)

Action


127/155


! An action is used for anything that does notdirectly start another activity graph, likeinvoking an operation on an object, orrunning a user-specified action.

! However, an action can invoke an operationthat has another activity graph as a method(possible polymorphism).

Subactivity (State)

Subactivity


128/155


! A subactivity (state) starts another activitygraph without using an operation.

! Used for functional decomposition, non-polymorphic applications, like many workflowsystems.

! The invoked activity graph can be used bymany subactivity states.

Example

POEmployee.sortMail Deliver Mail


129/155


POEmployee

sortMail() Check OutTruck

Put MailIn Boxes

Deliver Mail

Activity Graph as Method

POEmployee.sortMail POEmployee.deliverMail


130/155


POEmployee

sortMail()

! Application is completely OO when all action statesinvoke operations! All activity graphs are methods for operations.

deliverMail()

realize

Check OutTruck

Put MailIn Boxes

PO Employee Deliver Mail Method

Dynamic concurrency

Action/Subactivity *


131/155


! Applies to actions and subactivities.! Not inherited from state machines.! Invokes an action or subactivity any number of times in parallel,

as determined by an expression evaluated at runtime.Expression also determines arguments.

! Upper right-hand corner shows a multiplicity restricting thenumber of parallel invocations.

! Outgoing transition triggered when all invocations are done.

! Currently no standard notation for concurrency expression orhow arguments are accessed by actions. Attach a note asworkaround for expression. Issue for UML 2.0.

Object Flow (State)

Class[State]


132/155


! A special sort of step (state) that representsthe availability of a particular kind of object,perhaps in a particular state.

! No action or subactivity is invoked andcontrol passes immediately to the next step(state).

! Places constraints on input and outputparameters of steps before and after it.

Object Flow (State)

Order[Taken]Take Order Fill Order


133/155


! Take Order must have an output parametergiving an order, or one of its subtypes.

! Fill Order must have an input parametertaking an order, or one of its supertypes.! Dashed lines used with object flow have the

same semantics as any other state transition.

Coordinating Steps! Inherited from state machines


134/155


! Initial state

! Final state

! Fork and join

! Decision point and merge ( ) areinherited from state machines.

Coordinating Steps


135/155


! For modeling conventional flow chartdecisions.

Calculate

Cost

Charge

Account

GetAuthorization

[cost < $50]

[cost >= $50]


136/155

Convenience Features (Synch State)

! Forks and joins do not require compositestates.S h t t b itt d f th


137/155


! Synch states may be omitted for the common

case (unlimited bound and one incoming andoutgoing transition).

BuildFrame

InstallFoundation

InstallElectricity

in Foundation

Put

OnRoof

InstallElectricityIn Frame

InstallElectricity

Outside

InstallWalls

Inspect

Activity diagram notation

Convenience Features (Synch State)

! Object flow states can be synch states


138/155


Obj

[S2]

A11 A12 A13

A21 A22 A23

Convenience Features! Fork transitions can have guards.

EvaluateImpact

RevisePlan

[ priority = 1]


139/155


Register

Bug

p

FixBug

Release

FixTestFix

RegisterBug

EvaluateImpact

FixBug

RevisePlan

ReleaseFix

TestFix

[ priority = 1]

[else]

! Instead of doing this:

Convenience Features! Partitions are a grouping mechanism.! Swimlanes are the notation for partitions.! They do not provide domain-specific semantics.


140/155


They do not provide domain specific semantics.!

Tools can generate swimlane presentation fromdomain-specific information without partitions.

RegisterBug

EvaluateImpact

FixBug

RevisePlan

ReleaseFix

TestFix

[ priority = 1]

Management

Support

Engineering

Convenience Features! Signal send icon

Signal

Wake Up


141/155


CoffeePot

Get Cups

Turn on Coffee Pot

Coffee Done

Drink Coffee

Signal

! translates to a transitionwith a send action.

! Signal receipt icon

! translates to a wait state (astate with no action and asignal trigger event).

d y

partition

Submission Team Task Force

Revision Task Force

Issue RFPDevelop

technology

action state control flow

Begin

initial state

fork of control


142/155


C a s e

S t u d

yIssue RFP

Evaluate initialsubmissions

Submitspecification

draft

Collaborate withcompetitivesubmitters

technologyspecification

RFP[issued]

[optional]

Finalizespecification

Specification[initial

proposal]

input value

object flow

join of control conditional fork

Specification[final

proposal] A d a p

t e d f r o m

K o

b r y n ,

U M L 2 0 0 1

C o m m u n

i c a

t i o n s o f

t h e

A C M

O c

t o b e r

1 9 9 9

d y

Evaluate initialsubmissions

Evaluate finalsubmissions

Finalize

specificationSpecification

[finalproposal]

Collaborate withcompetitivesubmitters


143/155


C a s e

S t u d

A d a p

t e d f r o m

K o

b r y n ,

U M L 2 0 0 1

C o m m u n

i c a

t i o n s o f

t h e

A C M

O c

t o b e r

1 9 9 9

submissions

Vote torecommend

Enhancespecification

Implementspecification

Revisespecification

Specification[adopted]

Recommend

revision

Specification[revised]

[NO][YES]

[else] [Enhanced]

decision

final state

guard

When to Use Activity Diagrams

! Use activity diagrams when thebehavior you are modeling ...! does not depend much on external events


144/155


! does not depend much on external events.! mostly has steps that run to completion,rather than being interrupted by events.! requires object/data flow between steps.! is being constructed at a stage when youare more concerned with which activities

happen, rather than which objects areresponsible for them (except partitionspossibly).

Activity Diagram Modeling Tips

! Control flow and object flow are notseparate. Both are modeled with statetransitions


145/155


transitions.! Dashed object flow lines are also

control flow.!

You can mix state machine andcontrol/object flow constructs on thesame diagram (though you probably do

not want to).


Customer Telesales WarehouseAccountingFrom UMLUser Guide:


146/155


RequestReturn

Get ReturnNumber

Ship Item

Item[returned]

ReceiveItem

RestockItem

Credit

Account

Item

[available]


147/155

Activity Diagram Modeling Tips!

Activity diagrams inherit from state machines therequirement for well-structured nesting of compositestates.


148/155


! This means you should either model as if compositestates were there by matching all forks/decisions witha correspond join/merges

! or check that the diagram can be translated to onethat is well-nested.

! This insures that diagram is executable under statemachine semantics.


149/155

Not well-nested:



150/155


Apply structured coding principles. (Be careful with gotos!)


Can be translated to well-nesteddiagram on earlier slide:


151/155


Wrap Up: Activity Diagrams!

Use Activity Diagrams for applications that areprimarily control and data-driven, like businessmodeling

rather than event driven applications like


152/155


! rather than event-driven applications likeembedded systems.

! Activity diagrams are a kind of state machine untilUML 2.0

! so control and object/data flow do not haveseparate semantics.

! UML 1.3 has new features for business modeling thatincrease power and convenience. Check it out andgive feedback!

Preview - Next Tutorial

! Advanced Modeling with UML! Model management! Standard elements and profiles


153/155


Standard elements and profiles! Object Constraint Language (OCL)

References

! [UML 1.3]OMG UML Specification v. 1.3 ,OMG doc# ad/06-08-99

! [UML 1 4]OMG UML Specification v 1 4 UML


154/155


! [UML 1.4]OMG UML Specification v. 1.4, UMLRevision Task Force recommended final draft,OMG doc# ad/01-02-13.

Further Info! Web:

!

UML 1.4 RTF:www.celigent.com/omg/umlrtf ! OMG UML Tutorials:www.celigent.com/omg/umlrtf/tutorials.htm! UML 2.0 Working Group:

www.celigent.com/omg/adptf/wgs/uml2wg.htm! OMG UML Resources:www omg org/uml/


155/155


! OMG UML Resources:www.omg.org/uml/! Email

! [email protected]! Contributors:

! Gunnar vergaard: [email protected]! Bran Selic: [email protected]! Conrad Bock: [email protected]! MorganBjrkander: [email protected]

! Conferences & workshops! UML World 2001, New York, June 11-14, 2001! UML 2001, Toronto, Canada, Oct. 1-5, 2001! OMG UML Workshop 2001, San Francisco, Dec. 3-6, 2001

01-2 bock behavioral modeling tutorial

Documents