Ontologies Reasoning Components Agents Simulations Behavioral Modeling with UML2 Superstructure Jacques Robin

OntologiesReasoningComponentsAgentsSimulations

Behavioral Modeling Behavioral Modeling with UML2 with UML2

SuperstructureSuperstructure

Jacques Robin

OutlineOutline

UML2 superstructure UML2 behavioral meta-model structure Common and concurrent behaviors:

Events, triggers, signals, messages and time Activities Atomic behavior: actions State machines

Behavioral state machines Protocol state machines

Interactions Sequences Interaction overviews Communications

Use Cases Linking behavioral and structural model elements

UML2 Superstructure: BehaviorsUML2 Superstructure: Behaviors

States, Transitions, Lifecycles,States, Transitions, Lifecycles,Events and TriggersEvents and Triggers

Objects, component instances and system instances have states Externally visible states defined by the particular values of their

public properties (attributes, links) at one point of its lifecycle Internally encapsulated states define the particular values of all

their properties (attributes and links) at one point of its lifecycle The lifecycle consists of the all the transitions from one state to

another an object, component or system goes through Externally, a transition from a visible state to the next is triggered

by an external event such as a condition become true (ex, a user entering a command), an operation call, the reception of a message or a time-out.

Internally, a transition from an encapsulated sub-state to the next is triggered by the execution of sub-operations that recursively form the body of a higher-level operation

Roles of Behavioral DiagramsRoles of Behavioral Diagrams

Behavioral state machine: Specify the complete (external and internal) lifecycle of objects,

components and systems Specify the recursive decomposition of operations into lower-level

operations within the reactive computing paradigm until reaching atomic operations to be provided as built-in by the underlying platform

Protocol state machine: Specify the externally visible lifecycle of an encapsulated classifier

Activity diagram: Specify organizational workflows (business process) for early

requirements Specify the realization of a use case in terms of several objects calling

each other’s operations, with emphasis on the actions performed Specify the recursive decomposition of operations into lower-level

operations within the imperative computing paradigm until reaching atomic operations to be provided as built-in by the underlying platform

Roles of Behavioral DiagramsRoles of Behavioral Diagrams

Sequence diagram: Specify the temporal sequencing of messages between generic objects (i.e.,

class instances) that realize a use case or an operation Capture equivalent information than the activity diagram, but from a time-

centered, reactive view, instead of a action-centered, imperative view Interaction overview diagram:

Specify the workflow between sequence diagram fragments in black-box, encapsulated view

A hybrid incorporating workflow nodes and edges from the activity diagram and black-box fragments from sequence diagrams, which internals are elaborated in separate, lower-level sequence diagrams

Communication diagram: Specify the message passing patterns between generic objects (i.e., class

instances) that realize a use case or an operation Capture equivalent information than the sequence diagram, but from an

object-centered (reactive) view instead of a time-centered (but also reactive) view

Use case diagram: Specify the various ways that a system or component can be used, the

commands and command sequences at the disposal of the user

Choosing between Activity and Choosing between Activity and Interaction DiagramsInteraction Diagrams

Equivalent information, choice based on visual clarity of particular instance

With appropriate diagram conversion tools, only one shall be manually elaborated from which to automatically generate the others as mere alternative views

Choice heuristics: Many actions, few objects, few calls, shallow calls: activity

diagrams Few actions, few objects, many calls, deep calls: sequence

diagrams Few actions, many objects, many calls, deep calls: communication

diagrams

Common BehaviorsCommon Behaviors

Side-effect free encapsulatedbuilt-in computation to be provided

by underlying platform

Common Behaviors: ParametersCommon Behaviors: Parameters

Common Behaviors: Common Behaviors: Concurrency ModelingConcurrency Modeling

Common Behaviors: Common Behaviors: Events, Triggers and MessagesEvents, Triggers and Messages

Synchronous Communication: CallerStays Idle While Waiting for Answer

AsynchronousCommunication:

Caller Sends Signalto Receptor’s Queue,

then Switchs toOther Activity

Event HierarchyEvent Hierarchy

Common Behaviors: Modeling TimeCommon Behaviors: Modeling Time

Time Modeling ExamplesTime Modeling Examples

Activities: Basic NodesActivities: Basic Nodes

Activities: Edges Activities: Edges

Activity Diagrams: PartitionsActivity Diagrams: Partitions

Activity Activity DiagramsDiagrams

: : Concrete Concrete SyntaxSyntax

Activity Diagrams: Activity Diagrams: Concrete SyntaxConcrete Syntax

Prototypical Activity Diagram with Prototypical Activity Diagram with OCL ExpressionsOCL Expressions

<<K2Activity>>A1

[OCLExp23]

[else]

<<K2Action>>OCLExp24

ExpressionInOCL

<<K2RcvSignal>>OCLExp25

(ActivPart4)

(ActivPart3)

InitialNode

type20[mult39] ActivityParameterNode

InputPin

ObjectFlow<<K2Action>>

OCLExp19OpaqueAction

type20[mult29] OutputPin

[OCLExp22]

[else]

<<K2SubActiv>>A1

type21[mult40]

DecisionNode

CallBehavior

Action


JoinNode

type20[mult39]


type20[mult39]

ControlFlow

MergeNode

[OCLExp30]

[else]

FlowFinalNode

<<K2SendSignal>>OCLExp27

<<K2SignalSent>>OCLExp28

ObjectFlow

ObjectFlow

SendSignalAction

ObjectNode(of Type Signal)

(ActivPart1)ActivityPartition

(ActivPart2)

ActivityPartition

<<K2RcvSignal>>OCLExp32

ActivityFina

lNode

AcceptEventAction

InterruptibleActivityRegion

type20[mult39]



ForkNode

<<K2Except>>OCLExp26

type22

ExceptionHandler

Activity Diagram: ExamplesActivity Diagram: Examples

Activity Activity Diagram: Diagram: ExamplesExamples

Activity Diagram: ExamplesActivity Diagram: Examples

Activities: Activities: Structured Structured

NodesNodes

RecursiveRecursiveActivity: Activity: ExampleExample

Atomic Behaviors: ActionsAtomic Behaviors: Actions

Atomic Behaviors: Basic ActionsAtomic Behaviors: Basic Actions

Atomic Behaviors: Object ActionsAtomic Behaviors: Object Actions

Atomic Behaviors: Feature ActionsAtomic Behaviors: Feature Actions

Atomic Atomic BehaviorBehaviors: Link s: Link

Actions Actions

Atomic Behaviors: Variable ActionsAtomic Behaviors: Variable Actions

Action Semantics, Executable UMLAction Semantics, Executable UMLand UML Model Compilersand UML Model Compilers

Action package of UML2 meta-model defines general purposeAction Semantics (AS) within the object-oriented imperative paradigm

Together with recursively structured activity diagrams, AS is one big step towards Executable UML Model Specifications: i.e., platform independent, fully refined procedural specification of

all the bodies of all the operations in a class diagram from which full code for a variety of implementation platforms

could be automatically generated by Executable UML Model Compilers


But much remain to be done: No standard concrete syntax currently available (neither textual

nor visual) to instantiate the meta-model elements in an application model

The practical utility of a platform is derived more from the built-in services (libraries, APIs) available on it than from its language

No standard PIM model currently available that abstracts the generic common services provided by the most widely used platforms i.e., Java, C#, C++

No available standard PIM model yet that abstracts the advanced services of specific applications ex, web-based information systems, e-business, graphics, AI, etc.


What are the today’s options to come close to a fully refined PIM with potential to serves as the basis for fully automated code generation?

Model the body of each operation by a set of activity diagrams Use OCL expressions to describe the semantics of atomic

actions Hybrid, imperative-functional object-oriented paradigm OCL is declarative whereas action semantics is procedural:

OCL is more concise; OCL is more conceptually distant to mainstream platforms with

large community of programmers and a very extensive catalog of high-level built-in services to reuse through available APIs;

Generating code for such platforms that support practical reuse is thus more indirect from an OCL specification than from an AS one.

StateStateMachines:Machines:OverviewOverview

StatechartsStatecharts



State Machines State Machines vs.vs. Activities Activities

State Machine: States of both activity/action

execution and activity/action result on nodes

Optional activities or actions on nodes

Optional transitions among sub-states on nodes

Signals on transitions or nodes Input and output objects of

actions as parameters in action expressions and thus on either nodes or transitions

Activity: No events on edges, only

guards: transition always triggers automatically upon completion of activity/action at preceding node, provided that the (optional) guard on the edge is satisfied

Activities/actions on nodes Only states of executing an

action or activity on nodes Signals on nodes or transitions Input and output objects of

activities/action on nodes only, either dedicated object nodes or pins on activity/action nodes

State Machines: State ExamplesState Machines: State Examples

State Machines: ExamplesState Machines: Examples



State Machines: ExampleState Machines: Example

State Machines: RedefinitionsState Machines: Redefinitions

State Machines: Redefinition State Machines: Redefinition ExampleExample

State Machines with OCL ExpressionsState Machines with OCL Expressions

context Bottleinv: (self.oclInState(capped) or self.oclInState(full))

implies contents = capacity inv: (self.oclInState(empty) implies contents = 0 inv: self.oclInState(capped) implies myCap->notEmpty() inv: self.oclInState(partiallyFilled) implies myFiller->notEmpty()

Protocol State MachinesProtocol State Machines

Protocol vs. Behavioral State Protocol vs. Behavioral State MachinesMachines

Protocol State Machine Specify operation pre and post

conditions in a state-dependent and/or time-constrained manner

Specify only externally visible transitions

Associated directly to an interface or indirectly to an encapsulated classifier through a port

No history or deep history pseudo-state

States: no entry, exit or do activities

Transitions: no action Protocol state machine pairs

associated to connected ports must be conformant

Behavioral State Machine Specify all lifecycle transitions,

including externally visible and internally encapsulated transitions

Associated to an operation of a behaviored classifier

May have history and deep history pseudo-states

States: may have entry, exit and do activities

Transitions: may have action

Protocol State Machines: ExamplesProtocol State Machines: Examples

Interactions: Meta-ModelInteractions: Meta-Model

Interactions: Meta-ModelInteractions: Meta-Model

MessagesMessages

Interaction FragmentsInteraction Fragments

Interaction Fragment: ExampleInteraction Fragment: Example

Sequence DiagramsSequence Diagrams

Timeline oriented view of interactions

Graphical notation for the full interaction meta-model packages

SequencSequence e

DiagramsDiagrams

Sequence Diagrams: ExamplesSequence Diagrams: Examples Timeline oriented view of interactions Graphical notation for the full interaction meta-model packages

Gate

Sequence Diagrams: ExamplesSequence Diagrams: Examples

Add new operation to LoyaltyProgram

addTransaction(accNr: integer,pname: string, serviceID: integer,amount: real,date: Date)

Operation body modeled as a sequence diagram

Sequence Sequence Diagrams with Diagrams with

OCL ExpressionsOCL Expressions

addTransaction Sequence Diagram w/ OCLaddTransaction Sequence Diagram w/ OCL

OCL constraints insuring coherence of instance expressions for each lifeline:lp.partners->includes(pp) and pp.name = pName, pp.deliveredServices->includes( s ) and s.serviceNr = servIdlp.Membership->includes( m ) and m.account.number = accNr

addTransaction: addTransaction: Alternative Modeling in Pure OCLAlternative Modeling in Pure OCL

context LoyaltyProgram::addTransaction( accNr: Integer, pName: String, servId: Integer, amnt: Real, d: Date)post: let acc : LoyaltyAccount = Membership.account->select(a | a.number =

accNr), newT : Transaction = partners-> select(p | p.name =

pName) .deliveredServices -> select(s | s.serviceNr = servId) .transactions -> select(date = d and amount = amnt),

card : CustomerCard = Membership -> select(m | m.account.number = accNr).card

in acc.points = acc.points@pre + newT.points and newT.oclIsNew() and amnt 0 implies newT.oclIsTypeOf(Burning) and amnt 0 implies newT.oclIsTypeOf(Earning) and acc.transactions - acc.transaction@pre = Set{newT} and card.transactions - card.transaction@pre = Set{newT}

Extension with guards in OCLExtension with guards in OCL

Interaction Interaction Overview Overview DiagramsDiagrams

Mix elements of activity and sequence diagrams

Communication DiagramsCommunication Diagrams

Layout variant (object-centered instead of time-centered) of a restricted class of sequence diagrams without: Recursive structuring through reusable fragments (ref) Overtaking in message sequencing (all messages arrive in the same order

than they were sent) Roughly corresponding to the UML 1.x sequence diagrams

Comparative Case Study in Comparative Case Study in Behavior Modeling: Multi-Agent SimulationBehavior Modeling: Multi-Agent Simulation

Model

Percept

Actionag env

AgentModel

+state: AMStateKind

2 1

Agent

+state: AgStateKind

+init()+receive(): Percept+update(p:Percept)+choose(): Action

+update(ac:Action)+send(ac:action)

Environment

+state: EnvStateKind

+init()+send(p:Percept,ag:Agent)+receive(ag:Agent): Action

+effects(ag:Agent,ac:Action)+ramifications()

+percept(ag:Agent): Percept

<<enumeration>>AgStateKind

emptyinitialized

perceptReceivedupdateddecided

rememberedactionSent

Simulation

+state: SimStateKind

+run()+stop()

<<enumeration>>EnvStateKind

emptyinitialized

perceptsSentactionsReceived

effectedramified

perceptsDerived

<<enumeration>>SimStateKind

stoppedrunning

EnvironmentModel

+state: EMStateKind

<<enumeration>>AMStateKind

initialupdatedFromPercepts

updatedFromAction

<<enumeration>>EMStateKind

initialeffectedramified

add createoperations

send shouldbe stereotypedby <<signal>>

percept shouldstereotyped by<<signal>>

ag2:Agent

init() init() init()e:Environment[state initialized]

ag1:Agent[state initialized]

ag2:Agent[state initialized]

ag1:Agent

update(a1,a2)e:Environment[state updated]

e:Environment

e:Environment[state perceptsSent]

reason(p1) reason(p2)ag1:Agent[state decided]

ag2:Agent[state decided]

p2:Perceptp1:Perceptag2:Agent

[state perceived]ag1:Agent

[state perceived]p1:Percept p2:Percept

e:Environment[state actionsReceived]

ac1:Action ac2:Actionag1:Agent

[state actionSent]ag2:Agent

[state actionSent]ac2:Actionac1:Action

env.create()ag.create() ag.create()a1:Agent

[state empty]ag2:Agent

[state empty]e:Environment[state empty]

run()

stop

Behavior as ActivityBehavior as Activity

s:Simulation

Behavior as ActivityBehavior as Activity

update(p)

choose()_:Agent

[state decided]

update(ac)

ac:Action

_:Agent[state remembered]

_:Environment[state effected]

ramifications()_:Environment[state ramified]

_:Environment[state perceptsDerived]

_:AgentModel[state updatedFromPercepts]

_:AgentModel[state updatedFromAction]

_:EnvironmentModel[state effected]

p:Percept

reason(p)

a:Action

update(ac)

ac:Action

p:Percept

effects(ac)Parallel

_:EnvironmentModel[state ramified]

Parallelpercepts(ag)

p:Percept

ac:Action_:Agent[state updated]

stop()

Behavior as State TransitionBehavior as State Transition

empty

/ create()

a:Agent

:Simulationinitialized

/ init()perceived

receive():p:Percept

updated decided

/ update(p:Percept) / choose()

remembered

/ update(ac:Action)

reasoning

running

stopped

run()

actionSent

empty/ create()

e:Environment

initialized

/ init()

perceptsSent

effected ramified/ ramifications()

updating

actionsReceivedag1:Agent^send(p1:Percept)

ag2:Agent^send(p2:Percept)

ac1 = receive(ag1:Agent)

ac2 = receive(ag2:Agent)

/ effects(ac1:action)

/ effects(ac2:action)

p1 = percept(ag1:Agent)

p2 = percept(ag2:Agent)perceptsDerived

e:Environment^send(ac:Action)

send(p:Percept) send(ac:Action)

created()

stop()

run() stop()

link send(p:percept) to history node inside a:agent machineto avoid repeating passing through empty, initialized

stop()

Behavior Behavior as as

Message Message SequenceSequence

ss

s:Simulation

e:Environment

ag1:Agent

ag2:Agent

env.create()

ag.create()

ag.create()

init()

p1:Perceptpar

p2:Percept

ref AgentReasoning

ac1:Actionpar

ac2:Action

ref EnvironmentUpdating

loop

par

par env.destroy()

ag.destroy()

init() init()

ag.destroy()

ref AgentReasoning

s:Simulation

run()

env.create()

ag1.create()

ag2.create()

same thingfor stop

Behavior as Message SequencesBehavior as Message Sequences

e:Environment a:Agent

update(p)

sd:EnvironmentUpdating

par

effects(ac:ac1)

effects(ac:ac2)

ramifications()

par

percepts(ag:ag1):p1

percepts(ag:ag2):p2

sd:AgentReasoning

choose():ac

update(ac)

p1:Percept

ac1:Action

ac2:Action

Behavior as Object Communication PatternBehavior as Object Communication Pattern

p1:Percept

ac1:Action

am1:AgentModel

ag1:Agent e:Environment

s:Simulation

em:EnvironmentModel am2:AgentModel

ag2:Agent

p2:Percept

ac2:Action

1.1.a. create()2a. destroy() 1b. create()

2b. destroy()

1c. create()2c. destroy()

1.1a. init()1.2.1a. update(p1)1.2.2a. choose()1.2.3a. update(ac1)

1.1c. init()1.2.1b. update(p2)1.2.2b. choose()1.2.3b. update(ac2)

1.1b. init()1.2.4.1a. effects(ac1)1.2.4.1.b. effects(ac2)1.2.4.2 ramifications()1.2.4.3a percepts(ag1)1.2.4.3b percepts(ag2)

1.2a. send(p1)

1.2.4a. send(ac1))

1.2b. send(p2)

1.2.4b. send(ac2)

1. run()2. stop()

propagatechangesgreat

Use Cases: GoalsUse Cases: Goals

Provide a visual, non-technical blueprint for functional requirements The main modeling item for communication with users and clients

Provide basis for testing sub-process Provide basis for delimiting iterations in spiral development

processes In an MDA approach:

The entities that mentioned in each use case (i.e., actors, input-output data) must be defined in detail in an associated class diagram

The system or component behavior that each use case synthesizes must be further elaborated by activity or sequence diagrams

OCL constraints must formalize the pre and post-conditions of each use case

Use Cases: Meta-ModelUse Cases: Meta-Model

Use Cases: Use Cases: DiagramsDiagrams

Use Cases: ExamplesUse Cases: Examples

Use Case: RelationshipsUse Case: Relationships

Includes: basic, cut and paste reuse “as is” Generalizes: reuse with part redefinition like any other

behavior Extends: reuse with parts added in specific points

Useful for modeling requirement variations across a product line Useful for modeling initial versions with partial functionalities

Use Use Cases: Cases:

ExamplesExamples

Documents

Ontologies Reasoning Components Agents Simulations Behavioral Modeling with UML2 Superstructure Jacques Robin