Behavioral Modeling with UML

8/14/2019 Behavioral Modeling with UML

1/138

Behavioral Modeling

Behavioral Modeling with UML 1


2/138


Behavioral Modeling

Part 1: Interactions andCollaborations

Part 2: Statecharts

Part 3: Activity Diagrams


3/138


Interactions

What are interactions?

Core concepts

Diagram tour

When to model interactions Modeling tips

Example: A Booking System


4/138


What are interactions?

Interaction: a collection ofcommunications betweeninstances, including all ways toaffect instances, like operation

invocation, as well as creation anddestruction of instances

The communications are partially

ordered (in time)


5/138


Interactions: Core Elements

name

attr values

Instance

(object,

data value,

componentinstance

etc.)

An entity with a unique identity and

to which a set of operations can be

applied (signals be sent) and which

has a state that stores the effects ofthe operations (the signals).

Action A specification of an executable

statement.

A few different kinds of actions arepredefined, e.g. CreateAction,

CallAction, DestroyAction, and

UninterpretedAction.

Construct Description Syntax

textual


6/138


(contd)

Stimulus A communication between two

instances.

Operation A declaration of a service that can

be requested from an instance to

effect behavior.


textual

A specification of an asynchronous

stimulus communicated betweeninstances.

Signal SignalName

parameters


7/138Behavioral Modeling with UML 7

Relationships

Link A connection between instances.

Attribute Link A named slot in an instance, which

holds the value of an attribute.


textual



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



Example: Instances and Links

Joe : Person Jill : Person

: Family

husband wife



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 do

v.x := factor * v.x;

v.y := factor * v.y



Interaction Diagram Tour

Show interactions betweeninstances 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)



Interaction Diagrams

x y z

Sequence Diagram

a

b

c

Collaboration Diagram

x y

z

1.1: a

1.2: c

1.1.1: b


13/138


Sequence Diagram

name : Classobject symbol

lifeline

activation

other

stimulus

name ()

return

: Class

create

new ()

delete


14/138


Different Kinds of Arrows

Procedure call or otherkind of nested flow of

control

Flat flow of control

Explicit asynchronous

flow of control

Return

UML 1.4: Asynchronous

UML 1.4: Variant of async


15/138


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: Asynchronous flowUML 1.4: Alternative notation

for async flow


16/138


Recursion, Condition, etc.

calculator filter value

[ x < 0]: transform ()

[ x > 0]: getValue ()

getValue ()

iterate ()


17/138



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 symbollink symbol

standard

stereotype

standard

stereotype

standardstereotype

standard

constraint

standard

constraint


18/138


When to Model Interactions

To specify how the instances are tointeract with each other.

To identify the interfaces of theclassifiers.

To distribute the requirements.


19/138


Interaction Modeling Tips Set the context for the interaction.

Include only those features of the instancesthat are relevant. Express the flow from left to right and from

top to bottom.

Put active instances to the left/top andpassive 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


20/138


21/138


Use Case Description: Change Flt Itinerary

Actors: traveler, client account db, airline reservationsystem 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.

Alternative course: If no flights are available then


22/138


Itinerary

: Booking SystemTraveler Airline Reservation System

change flight itinerary

get customer account

get itinerary

present itinerary

select segment

present detailed info

update information

available flight

:

:

Client Account DBMSClient Account DBMS


23/138


Itinerary

Traveler Client Account DBMS

Airline Reservation System

: Booking System

7: update information

2: get customer account

3: get itinerary

4: present itinerary

8: available flight

1: change flight itinerary

5: select segment

6: present detailed info


24/138


Collaboration

What is a collaboration?

Core concepts

Diagram tour

When to model collaborations Modeling tips


h i ll b i


25/138


What is a collaboration?

Collaboration: a collaborationdefines the roles a set of instancesplay when performing a particulartask, like an operation or a use

case. Interaction:an interaction specifies

a communication pattern to be

performed by instances playing theroles of a collaboration.

l


26/138


Elements

Collaboration A collaboration describes how

an operation or a classifier, like a

use case, is realized by a set of

classifiers and associations used

in a specific way.

The collaboration defines a set

of roles to be played by instances

and links, possibly including a

collection of interactions.


Name

An interaction describes a

communication pattern between

instances when they play the

roles of the collaboration.

Interaction


27/138


(contd)

Collaboration-

Instance

A collection of instances which

together play the roles declared

in a collaboration.


Name

A collection of stimuliexchanged between instances

playing specific roles according

to the communication pattern of

an interaction.

Interaction-Instance

All new in UML 1.4


28/138


Collaborations: Core Elements(con

Classifier

Role

A classifier role is a specific role

played by a participant in a

collaboration. It specifies a restricted

view of a classifier, defined by whatis required in the collaboration.

Message A message specifies one

communication between instances.

It is a part of the communication

pattern given by an interaction.


/ Name

label

R l ti hi


29/138


Relationships

Association

Role

An association role is a specific

usage of an association needed

in a collaboration.

Generalization A generalization is a taxonomic

relationship between a more

general element and a more

specific element. The more

specific element is fully consistentwith the more general element.



30/138


Trichotomy

An Instance is an

entity withbehavior and astate, and has aunqiue identity.

A Classifier is adescription of anInstance.

A Classifier Roledefines a usage (anabstraction) of anInstance.

id

ClassName

/ RoleName

originates from

conforms to

view of

- -


31/138


- -(contd)

ClassifierRoleClassifier

Operation-1 ()

Operation-2 ()

Operation-3 ()

Attribute-1

Attribute-2

Attribute-3

InstanceAttributeValue-1

AttributeValue-2

AttributeValue-3

Operation-1 ()

Operation-3 ()

Attribute-1

Attribute-2

originates from conforms to

The attribute values of an Instance corresponds to the attributes of

its Classifier.All attributes required by the ClassifierRole have correspondingattribute values in the Instance.All operations defined in the Instances Classifier can be applied tothe Instance.All operations required by the ClassifierRole are applicable to theInstance.

R l


32/138


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 :

R l


33/138


Role

Class-1 Class-2

view of view ofview of

0..5

3..4

{changeable}

{frozen}/ Role-1 / Role-2

An Association Role specifies therequired properties of a Link used in aCollaboration.The properties of an AssociationEndmay be restricted by a

AssociationEndRole.

AssociationClass Class

AssociationRoleClassifierRole ClassifierRole

E l A S h l


34/138


Example: A School

/ Teacher : Person / Student : Person

: Faculty : Course

position : Text program : Text

1 tutor student *

faculty member *

faculty 1

1 lecturer

given course *

participant *

taken course *

R l M d l Cl M d l


35/138


Role Model vs. Class Model

The Classes give the complete description while the

Roles specify one usage.


: Faculty : Course


Person

Faculty Course

name : Text

position : Text

program : Text

1 *

1

* 1

* *

*

0..1

*

* *

*1

*

0..1

Extra attribute

Resulting multiplicity

Resulting multiplicity

Role Model Class Model

A C ll b ti d It R l


36/138


A Collaboration and Its Roles

CollaborationName

Classifier-1 Classifier-2

roleName-1roleName-2

roleName-3

A Collaboration

and how its roles

are mapped onto

a collection ofClassifiers and

Associations.

Patterns in UML


37/138


Patterns in UML

Observer

CallQueue SlidingBarIcon

Subject Handler

queue : List of Call

source : ObjectwaitAlarm : Alarm

capacity : Integer

reading : Real

color : Colorrange : Interval

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

Constraint that must

be fulfilled in each instance

of this pattern.

C ll b ti


38/138


Collaborations

ObserverCallQueue SlidingBarIcon

Subject Handler

SupervisorManagedQueue Controller

ManagerSubject

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

Collaboration Diagram Tour


39/138


Collaboration Diagram Tour

Show Classifier Roles andAssociation Roles, possiblytogether with extra constrainingelements

Kinds Instance level Instances and Links

Specification level Roles

Static Diagrams are used forshowing Collaborations explicitly


40/138


Level


: Faculty : Course


1 tutor student *

faculty 1

faculty member *1 lecturer

given course * * taken course

* participant

UML 1.4: The diagram shows the contents of a Collaboratio

L l


41/138


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 contentsof a CollaborationInstance

Interactions


42/138


Interactions

x y z

Sequence Diagram

a

b

c


x y

z

1.1: a

1.2: c

1.1.1: b

UML 1.4: The diagrams show thecontents of a CollaborationInstancewith an InteractionInstance

superposed

Roles on Sequence Diagrams


43/138


Roles on Sequence Diagrams

/ X / Y / Z

Sequence Diagram

a

b

c

UML 1.4: The diagram shows the contentsof a Collaboration with an Interactionsuperposed

Collaboration Diagram with Constraining


44/138


g gElements

/ Generator : Printer Device

: Laser Printer : Line Printer

Constraining Element

(A Generalization is not

an AssociationRole )


45/138


Static Diagram With Collaboration and Classifiers

ObserverCallQueue SlidingBarIcon

Subject Handler

SupervisorManagedQueue ControllerManagerSubject

When to Model Collaborations


46/138


When to Model Collaborations

Use Collaborations as a tool to find

the Classifiers.Trace a Use Case / Operation onto

Classifiers.

Map the specification of aSubsystem onto its realization(Tutorial 3).

Collaboration Modeling Tips


47/138


Collaboration Modeling Tips

A collaboration should consist of

both structure and behaviorrelevant 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)


48/138



U C D i ti Ch Flt Iti


49/138


Use Case Description: Change Flt Itinerary

Actors: traveler, client account db, airline reservationsystem

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.

Alternative course: If no flights are available then


50/138

Collaborations


51/138


Collaborations

Instances, Links and Stimuli are

used for expressing the dynamics ina 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


52/138


Behavioral Modeling

Part 1: Interactions and

Collaborations Part 2: Statecharts



53/138

Automata


54/138


ONONONON

Automata

A machine whose output behavior is not

only a direct consequence of the currentinput, but of some past history of itsinputs

Characterized by an internal state whichrepresents this past experience

ONONONONONONONON ONONONON

OFFOFFOFFOFF

Diagram


55/138


off

on

Diagram

Graphical rendering of automata

behavior

Lamp OnLamp OnLamp OnLamp On

Lamp OffLamp OffLamp OffLamp Off

off

on

Outputs and Actions


56/138


Outputs and Actions

As the automaton changes state it

can generate outputs:on

off

Lamp OnLamp On

print(on)print(on)

Lamp OnLamp On

print(on)print(on)

LampLamp

OffOff

LampLamp

OffOff

off

on

Moore automaton

on

off


LampLampOffOffLampLampOffOff

off

on/print(on)print(on)

Mealy automaton


57/138

A Bit of Theory


58/138


A Bit of Theory

An extended (Mealy) state machine is

defined by: 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)

Diagram


59/138


top

Diagram

ReadyReadyReadyReady

stop

/ctr := 0stop

StateStateStateState

TriggerTriggerTriggerTrigger

ActionActionActionAction

InitialInitialpseudostatepseudostate

InitialInitialpseudostatepseudostate

TransitionTransitionTransitionTransition

FinalFinal

statestate

FinalFinal

statestate

DoneDoneDoneDone

top statetop statetop statetop state

What Kind of Behavior?


60/138


What Kind of Behavior?

In general, state machines are

suitable for describing event-driven, discrete behavior inappropriate for modeling continuous

behavior

timetime

thresholdthreshold

Event-Driven Behavior


61/138


Event Driven Behavior

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


62/138


63/138


Basic State Machine Concepts

Statecharts and Objects

Advanced Modeling Concepts

Case StudyWrap Up

Model


64/138


Model

Simple server model:

HandleHandle

RequestRequest

HandleHandle

RequestRequest

InitializeInitialize

ObjectObject

InitializeInitializeObjectObject

TerminateTerminate

ObjectObject

TerminateTerminate

ObjectObject

Wait forWait for

RequestRequest

Wait forWait for

RequestRequest

void:offHook ();

{busy = true;

obj.reqDialtone();

};

Handling depends onHandling depends on

specific request typespecific request typeHandling depends onHandling depends on

specific request typespecific request type

Machines


65/138


Machines

Direct mapping:

HandleHandle

EventEvent


ObjectObject

TerminateTerminate

ObjectObject

Wait forWait for

EventEvent

on

off


LampLamp

OffOff

LampLamp

OffOff

off

on/print(on)

stop

Object and Threads


66/138


HandleHandle

RequestRequest

HandleHandle

RequestRequest



ObjectObject

TerminateTerminate

ObjectObject

TerminateTerminate

ObjectObject

Wait forWait for

RequestRequest

Wait forWait for

RequestRequest

HandleHandle

RequestRequest

HandleHandle

RequestRequest



ObjectObject

TerminateTerminate

ObjectObject

TerminateTerminate

ObjectObject

Wait forWait for

RequestRequest

Wait forWait for

RequestRequest

Object and Threads

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

Semantics


67/138


Semantics

Encapsulation does not protect the object from

concurrency conflicts!

Explicit synchronization is still required

HandleHandle

RequestRequest

HandleHandle

RequestRequest


ObjectObject


ObjectObject

TerminateTerminate

ObjectObject

TerminateTerminate

ObjectObject

Wait forWait for

RequestRequest

Wait forWait for

RequestRequest

Machines


68/138


anActiveObjectanActiveObject

#currentEvent : Event#currentEvent : Event

+ start ( )+ start ( )

+ poll ( )+ poll ( )

+ stop ( )+ stop ( )

Machines

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

Semantics


69/138


Semantics

Run-to-completion model:serialized event handlingeliminates internal concurrencyminimal context switching overhead

ActiveObject:

The Run-to-Completion Model


70/138


Active1Active1Active1Active1 Active2Active2Active2Active2

p

A high priority event for (another) active

object will preempt an active object thatis handling a low-priority event

hi

hi

lo


71/138





Case StudyWrap Up

State Entry and Exit Actions


72/138


y

A dynamic assertion mechanism

LampOnLampOnLampOnLampOn

entry/lamp.on();

exit/lamp.off();

e1e1

e2e2

Order of Actions: Simple Case


73/138


Resulting action sequence:Resulting action sequence:

printf(exiting);printf(exiting);printf(to off);printf(to off);

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

Resulting action sequence:Resulting action sequence:

printf(exiting);printf(exiting);

printf(to off);printf(to off);


p

Exit actions prefix transition

actions Entry action postfix transition

actions


printf(needless);printf(needless);



printf(needless);printf(needless);


off/printf(needless);off/printf(needless);

off/printf(to off);off/printf(to off);LampOffLampOffLampOffLampOff

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

exit/printf(exiting);exit/printf(exiting);


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


Internal Transitions


74/138


Self-transitions that bypass entry

and exit actions

LampOffLampOffLampOffLampOff

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


off/null;

Internal transitionInternal transition

triggered bytriggered byan off eventan off event

Internal transitionInternal transitiontriggered bytriggered by

an off eventan off event

State (Do) Activities


75/138


ErrorErrorErrorError

entry/printf(error!)entry/printf(error!)

( )

Forks a concurrent thread that

executes until: the action completes or

the state is exited through an

outgoing transition

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

do activitydo activitydo activitydo activity

Guards


76/138


Conditional execution of transitions

guards (Boolean predicates) must be side-effect free

SellingSellingSellingSelling

UnhappyUnhappyUnhappyUnhappy

HappyHappyHappyHappy

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

bidbid [value >= 200] /sell/sell

bidbid [value < 100] /reject/reject

Static Conditional Branching


77/138


g

Merely a graphical shortcut for

convenient rendering of decisiontrees

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

[value >= 200] /sell/sell

[value < 100] /reject/reject




bidbid

Branching


78/138


bid /gain := calculatePotentialGain(value)




g

Choice pseudostate: guards are

evaluated at the instant when thedecision point is reached

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

[gain >= 200] /sell/sell

[gain < 100] /reject/reject

DynamicDynamic

choicepointchoicepointDynamicDynamic

choicepointchoicepoint

Hierarchical State Machines


79/138


Graduated attack on complexity states decomposed into state

machines

LampFlashingLampFlashingLampFlashingLampFlashingflash/flash/

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

FlashOffFlashOffFlashOffFlashOff

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

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




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

on/on/

on/on/on/on/

Stub Notation


80/138


Notational shortcut: no semantic

significance

LampFlashingLampFlashingLampFlashingLampFlashingflash/flash/

on/on/

FlashOnFlashOn

FlashOffFlashOff

off/off/





on/on/on/on/

Group Transitions


81/138


LampFlashingLampFlashingLampFlashingLampFlashing

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



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





on/on/

p

Higher-level transitions

flash/flash/

on/on/

Default transition toDefault transition to

the initial pseudostatethe initial pseudostate

Default transition toDefault transition to

the initial pseudostatethe initial pseudostate

Group transitionGroup transitionGroup transitionGroup transition

Completion Transitions


82/138


Triggered by a completion event generated automatically when an

immediately nested state machineterminates

CommittingCommittingCommittingCommitting

Phase1Phase1Phase1Phase1

Phase2Phase2Phase2Phase2

CommitDoneCommitDoneCommitDoneCommitDone

completioncompletion

transition (no trigger)transition (no trigger)completioncompletion

transition (no trigger)transition (no trigger)

Triggering Rules


83/138


LampFlashingLampFlashingLampFlashingLampFlashing

off/off/


FlashOnFlashOnFlashOnFlashOn

Two or more transitions may have the

same event trigger innermost transition takes precedence

event is discarded whether or not it triggersa transition

on/

on/

Deferred Events


84/138


Events can be retained if they do

not trigger a transition

off/off/



on/on/



off/deferoff/defer

Deferred eventDeferred eventDeferred eventDeferred event

Case


85/138


Same approach as for the simple

caseS1S1

exit/exS1exit/exS1S1S1

exit/exS1exit/exS1

S11S11

exit/exS11exit/exS11S11S11

exit/exS11exit/exS11

S2S2

entry/enS2entry/enS2S2S2

entry/enS2entry/enS2

S21S21

entry/enS21entry/enS21S21S21

entry/enS21entry/enS21

initS2initS2E/actEE/actE

Actions execution sequence:

exS11 exS1 actEenS2 initS2 enS21

History


86/138


suspend/suspend/

Return to a previously visited

hierarchical state deep and shallow history options

DiagnosingDiagnosingDiagnosingDiagnosing

Diagnostic1Diagnostic1Diagnostic1Diagnostic1

Step11Step11Step11Step11


Diagnostic2Diagnostic2Diagnostic2Diagnostic2


Step22Step22Step22Step22resume/resume/ H*H*H*H*

Orthogonality


87/138


Multiple simultaneous perspectives on

the same entity

ChildChild

AdultAdult

RetireeRetiree

ageage

PoorPoor

RichRich

financialStatusfinancialStatus


88/138

Semantics


89/138


OutlawOutlawOutlawOutlaw

LawAbidingLawAbidingLawAbidingLawAbiding PoorPoorPoorPoor

RichRichRichRich

financialStatusfinancialStatuslegalStatuslegalStatus

All mutually orthogonal regions detect

the same events and respond to themsimultaneously usually reduces to interleaving of some kind

robBank/robBank/ robBank/robBank/

Interactions Between Regions


90/138


Catch22Catch22Catch22Catch22

sanityStatussanityStatus flightStatusflightStatus

Typically through shared variables or

awareness of other regions statechanges

(flying)/(flying)/

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

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

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

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

requestrequestGrounding/Grounding/

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

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

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

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

(sane)/(sane)/

(~sane)/(~sane)/

sane : Booleansane : Booleansane : Booleansane : Boolean

flying : Booleanflying : Booleanflying : Booleanflying : Boolean

Transition Forks and Joins


91/138


For transitions into/out of

orthogonal regions:

StaffStaff

MemberMember

StaffStaff

MemberMember

employeeemployee

ChildChildChildChild AdultAdultAdultAdult RetireeRetireeRetireeRetiree

ageage

ManagerManagerManagerManager

Orthogonality


92/138


Using regions to model independent

objects

ChildChild

AdultAdult

RetireeRetiree

ChildChild

AdultAdult

RetireeRetiree

Person1Person1 Person2Person2

Person1Person1 Person2Person2


93/138

Case Study: Protocol Handler


94/138


line card 1line card 1

line card Nline card NEnd userEnd user

unreliabletelecom lines

A multi-line packet switch that

uses the alternating-bit protocol asits link protocol

SWITCHSWITCH

.

.

.

AB

sender

ABreceiver

End user

End user

AB

sender

ABreceiver

AB protocolAB protocolAB protocolAB protocol

Alternating Bit Protocol (1)


95/138


packetizer unpacker ReceiverSender

A simple one-way point-to-point

packet protocol

data(1)

ackA

pktAdata(1)

ack

ack

data(2)

ackB

pktBdata(2)

ack

ack

etc.

AB protocolAB protocolAB protocolAB protocol


96/138

Additional Considerations


97/138


Support (control) infrastructure

SWITCHSWITCH

ABABreceiverreceiver

ABABsendersender

operatoroperatorinterfaceinterface

DBDBinterfaceinterface

SystemSystem

operatoroperator

DBaseDBase

AB linesAB linesmanagermanager

Control


98/138


The set of (additional) mechanisms and

actions required to bring a system into thedesired operational state and to maintain itin that state in the face of various plannedand 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


99/138


AcceptPktA

WaitAckA

AcceptPktB

WaitAckB

Failed

JustCreated HardwareAudit

GettingData

ReadyToGo

AnalysingFailure

The Control Automaton


100/138


In isolation, the same control behavior

appears much simpler

Failed

JustCreated

HardwareAudit

GettingData

ReadyToGo

AnalysingFailure

OperationalOperational

Exploiting Inheritance


101/138


Abstract control classes can

capture the common controlbehavior

AbstractController

Sender Receiver . . .

Exploiting Hierarchical States


102/138


Failed

JustCreated

HardwareAudit

GettingData

ReadyToGo

AnalysingFailure

OperationalOperational

AbstractController

Sender


103/138





Case StudyWrap Up

Wrap Up: Statecharts


104/138


UML uses an object-oriented variant of

Harels statecharts adjusted to software modeling needs Used to model event-driven (reactive)

behavior

well-suited to the server model inherent inthe object paradigm

Primary use for modeling the behavior ofactive event-driven objects

systems modeled as networks ofcollaborating state machines run-to-completion paradigm significantly

simplifies concurrency management

Wrap Up: Statecharts (contd)


105/138


Includes a number of sophisticated

features that realize common state-machine usage patterns: 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


106/138


Part 1: Interactions and

Collaborations Part 2: Statecharts


Activity Diagram Applications


107/138


Intended for applications that need

control flow or object/data flow models

... rather than event-driven models likestate machines.

For example: business process modelingand workflow.

The difference in the three models is

how step in a process is initiated,especially with respect to how the stepgets its inputs.

Control Flow


108/138


Each step is taken when the previous

one finishes regardless of whether inputs are

available, accurate, or complete(pull).

Emphasis is on order in which steps aretaken.

Not UMLNotation! Chart Course

Chart CourseCancel TripCancel Trip

Analyze Weather InfoAnalyze Weather Info

Weather InfoStart

Object/Data Flow


109/138


Each step is taken when all the required input

objects/data are available and only when all the inputs are available

(push).

Emphasis is on objects flowing between steps.

Design ProductDesign Product

ProcureMaterials

ProcureMaterials

Acquire CapitalAcquire Capital

BuildSubassembly 1

BuildSubassembly 1

BuildSubassembly 2

BuildSubassembly 2

FinalAssembly

FinalAssembly

Not UMLNotation

State Machine


110/138


Each step is taken when events

are 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 OrderSelection

Made

DispenseProduct

DispenseProduct

ReturnChange

ReturnChange

Cancel ButtonPressed

Not UMLNotation

Machines


111/138


Currently activity graphs are

modeled 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 usedin the element names.

Activity graphs will become

independent of state machines inUML 2.0.

Diagrams


112/138


Just like their state machine counterparts (simple state

and submachine state) except that ... ... transitions coming out of them are taken when the

step is finished, rather than being triggered by a externalevent, ...

... and they support dynamic concurrency.

Action Action (State)

Subactivity Subactivity (State)

Action (State)


113/138


An action is used for anything that does

not directly start another activity graph,like invoking an operation on an object,or running a user-specified action.

However, an action can invoke an

operation that has another activitygraph as a method (possiblepolymorphism).

Action

Subactivity (State)


114/138


A subactivity (state) starts anotheractivity graph without using anoperation.

Used for functional decomposition, non-polymorphic applications, like many

workflow systems. The invoked activity graph can be used

by many subactivity states.

Subactivity

Example


115/138


POEmployee.sortMail Deliver Mail

POEmployee

sortMail() Check OutTruck

Put MailIn Boxes

Deliver Mail

Activity Graph as Method


116/138


POEmployee

sortMail()

Application is completely OO when all actionstates invoke operations

All activity graphs are methods for operations.

POEmployee.sortMail POEmployee.deliverMail

deliverMail()realize

Check OutTruck

Put MailIn Boxes

PO Employee Deliver Mail Method

Dynamic concurrency


117/138


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 atruntime. Expression also determines arguments.

Upper right-hand corner shows a multiplicity restrictingthe number of parallel invocations.

Outgoing transition triggered when all invocations aredone.

Currently no standard notation for concurrencyexpression or how arguments are accessed by actions.Attach a note as workaround for expression. Issue for

UML 2.0.

Action/Subactivity *

Object Flow (State)


118/138


A special sort of step (state) that

represents the availability of a particularkind of object, perhaps in a particularstate.

No action or subactivity is invoked and

control passes immediately to the nextstep (state).

Places constraints on input and output

parameters of steps before and after it

Class

[State]

Object Flow (State)


119/138


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.

Order

[Taken]Take Order Fill Order

Coordinating Steps


120/138


Initial state

Final state

Fork and join

Inherited from state machines

Coordinating Steps


121/138


Decision point and merge ( ) are

inherited from state machines. For modeling conventional flow

chart decisions.

CalculateCost

ChargeAccount

GetAuthorization

[cost < $50]

[cost >= $50]

Coordinating Steps


122/138


Synch state ( ) is inherited from state

machines but used mostly in activitygraphs.

Provides communication capabilitybetween parallel processes.State machine

notation

InspectInstall

Foundation

Build

Frame

Install

Electricity

in Foundation

PutOn

Roof

Install

Electricity

In Frame

Install

Electricity

Outside

Install

Walls

* *

State)


123/138


Forks and joins do not require

composite states. Synch states may be omitted for the

common case (unlimited bound and oneincoming and outgoing transition).

Build

Frame

Install

Foundation

Install

Electricity

in Foundation

Put

On

Roof

Install

Electricity

In Frame

Install

Electricity

Outside

Install

Walls

Inspect

Activity diagram

notation

State)


124/138


Object flow states can be synch

states

Convenience Features


125/138


Fork transitions can have guards.

Register

Bug

Evaluate

Impact

Fix

Bug

Revise

Plan

Release

Fix

Test

Fix

[ priority = 1]

RegisterBug

Evaluate

Impact

Fix

Bug

Revise

Plan

ReleaseFix

Test

Fix

[ priority = 1]

[else]

Instead of doing this:



126/138


Partitions are a grouping mechanism.

Swimlanes are the notation for partitions. They do not provide domain-specific

semantics.

Tools can generate swimlane presentation

from domain-specific information withoutpartitions.

Register

Bug

Evaluate

Impact

Fix

Bug

Revise

Plan

Release

Fix

Test

Fix

[ priority = 1]

Management

Support

Engineering



127/138


Signal send icon

Signal

Coffee

Pot

Wake Up

Get Cups

Turn on Coffee Pot

Coffee Done

Drink Coffee

Signal

translates to a transitionwith a send action.

Signal receipt icon

translates to a waitstate (a state with noaction and a signal triggerevent).

partition

Submission Team Task Force Revision Task Force

action state control flowinitial state


128/138


Cas e

Stu

dy Issue RFP

Evaluate initial

submissions

Submit

specification

draft

Collaborate with

competitive

submitters

Develop

technology

specification

RFP[issued]

[optional]

Finalize

specification

Specification[initial

proposal]

input value

Begin

object flow

join of control

conditional

fork

fork of control

Specification[final

proposal]

Adaptedfro

m

Kobryn,UML2001

Communicationsofth

eACM

October19

99

Evaluate initial

submissions

Collaborate withcompetitive

submitters


129/138


Stud

y

Adaptedfro

m

Kobryn,UML2001

Communicationsofth

eACM

October19

99

Evaluate final

submissions

Vote to

recommend

Enhance

specification

Implement

specification

Revise

specification

Finalize

specification

Specification[final

proposal]

Specification[adopted]

Recommend

revision

Specification

[revised]

[NO][YES]

[else] [Enhanced]

decision

final state

guard

Diagrams


130/138


Use activity diagrams when the behavior youare modeling ... 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 you aremore concerned with which activities happen,rather than which objects are responsible forthem (except partitions possibly).


131/138

Tips


132/138


RequestReturn

Get ReturnNumber

Ship Item

Item[returned]

ReceiveItem

RestockItem

CreditAccount

Item[available]

Customer Telesales WarehouseAccountingFrom UML

User Guide:

Customer Telesales WarehouseAccounting


133/138


Activity

Mo

delingT

ips

RequestReturn

Get ReturnNumber

Ship Item

Item

[returned]

ReceiveItem

RestockItem

CreditAccount Item

[available]


134/138

Tips


135/138


Well-nested:

Tips


136/138


Not well-nested:

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

Tips


137/138


Can be translated to well-nesteddiagram on earlier slide:

Wrap Up: Activity Diagrams


138/138

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

rather than event-driven applications likeembedded systems.

Activity diagrams are a kind of state machineuntil UML 2.0

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

UML 1.3 has new features for businessmodeling that increase power and

Behavioral Modeling with UML

Documents

Transcript of Behavioral Modeling with UML