Ontologies Reasoning Components Agents Simulations Agent Behavioral Modeling with UML2 Jacques...

OntologiesReasoningComponentsAgentsSimulations

Agent Behavioral Agent Behavioral Modeling with UML2Modeling with UML2

Jacques Robin

OutlineOutline

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 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: Common Behaviors: Concurrency ModelingConcurrency Modeling

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

Interface Semantics,Generally but not always

Synchronous Communication

PayloadSemantics,

AsynchronousCommunication:

Caller Sends Signalto Receptor’s Queue,

then Switchs toOther Activity

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.

Activities: Basic NodesActivities: Basic Nodes

Activities: Edges Activities: Edges

Activities: PartitionsActivities: Partitions

Sub-ActivitiesSub-Activities

*

Behavior 1

Action local post-conditionAction local post-condition

Activity Activity DiagramsDiagrams

: : Concrete Concrete SyntaxSyntax

Activity Diagrams: Activity Diagrams: Concrete SyntaxConcrete Syntax

Prototypical Activity Diagram with Prototypical Activity Diagram with OCL ExpressionsOCL Expressions

A1

[OCLExp23]

[else] OCLExp24

ExpressionInOCL

OCLExp25

(ActivPart4)

(ActivPart3)

InitialNode

type20[mult39] ActivityParameterNode

InputPin

ObjectFlow

OCLExp19CallOperation

Action

type20[mult29] OutputPin

[OCLExp22]

[else]

A1

type21[mult40]

DecisionNode

CallBehavior

Action OCLExp29

JoinNode

Type21[mult40]

OCLExp31

type21[mult40]

ControlFlow

MergeNode

[OCLExp30]

[else]

FlowFinalNode

OCLExp27

OCLExp28

ObjectFlow

ObjectFlow

SendSignalAction

ObjectNode(of Type Signal)

(ActivPart1)ActivityPartition

(ActivPart2)

ActivityPartition

OCLExp32Activity

FinalNode

AcceptEventAction

InterruptibleActivityRegion

type20[mult39]

OCLExp20OCLExp21

ForkNode

OCLExp26

type22

ExceptionHandler

RecursiveRecursiveActivity: Activity: ExampleExample

StateStateMachinesMachines

::OverviewOverview

StatechartsStatecharts

StatechartsStatecharts

<transition> ::= [<trigger> [‘,’ <trigger>]* [‘[‘ <guard-constraint>’]’] [‘/’ <behavior-expression>]]<trigger> ::= e<guard-constraint> ::= g<behavior-expression> ::= a

State Machines: State ExamplesState Machines: State Examples

State Machines: ExamplesState Machines: Examples

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

Filler

Bottle

Protocol State MachinesProtocol State Machines

Prototypical Protocol State MachinePrototypical Protocol State Machine

S1

[pre1] op1 / post1

S2

[pre2] op2 / post2

S3

[pre3] op3 / post3

PSM.interface = I0 {protocol}

[pre4] op4 / post4

[pre5] op5 / post5 [pre6] op6 / post6

ProtocolStateMachine

ExpressionInOCL

ProtocolStateMachine.name Interface.name

ExpressionInOCL

State

or

PseudoState

FinalState

ProtocolTransition

ExpressionInOCL

Operation

created

create()

add state invariants

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: [precondition] operation / postcondition

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: trigger [guard] / action

animate

Interactions: Meta-ModelInteractions: Meta-Model

MessagesMessages

Interaction FragmentsInteraction Fragments

Sequence DiagramsSequence Diagrams

Timeline oriented view of interactions

Graphical notation for the full interaction meta-model packages

Interaction Fragment: ExampleInteraction Fragment: Example

SequencSequence e

DiagramsDiagrams

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

Gate

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

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

Prototypical Use Case DiagramPrototypical Use Case Diagram

<<include>>

<<K2Actor>>Actor1

<<K2Actor>>Actor2

<<K2UseCase>> Uc1

<<K2UseCase>> Uc3

<<K2UseCase>> Uc2

<<K2UseCase>> Uc4

<<include>>

<<K2UseCase>> Uc5

<<K2Actor>>Actor3

mult24mult25

mult31

mult30mult29

mult28

mult27

mult26

Actor

UseCase

Include

Association

Generalization

Generalization

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

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

Model

<<signal>>Percept

<<signal>>Action

ag env

AgentModel

+state: AMStateKind

2

Sim

+state: SimStateKind

+run()+stop()

<<enumeration>>AgStateKind

emptyinitialized

perceptReceivedupdateddecided

rememberedactionSent

<<enumeration>>EnvStateKind

emptyinitialized

perceptsSentactionsReceived

effectedramified

perceptsDerived

<<enumeration>>SimStateKind

stoppedrunning

EnvironmentModel

+state: EMStateKind

<<enumeration>>AMStateKind

initialupdatedFromPercepts

updatedFromAction

<<enumeration>>EMStateKind

initialeffectedramified

Env

+state: EnvStateKind

<<create>> +create()+init()

+send(p:Percept,ag:Agent)<<signal>> +send(ac:action)

<<signal>> +stop()+effects(ag:Agent,ac:Action)

+ramifications()+percept(ag:Agent, out p:Percept)

Agent

+state: AgStateKind

<<create>> +create()+init()

<<signal>> +send(p:Percept,ag:Agent)<<signal>> +stop()+update(p:Percept)

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

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(out ac)_: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, out:p)

p:Percept

ac:Action_:Agent[state updated]

Behavior as State TransitionBehavior as State Transition

empty

create()

a1:Agent

initializedinit() perceived

[lastPercept = p1]send(p1:Percept,self)

updated

update(p1:Percept) update(ac1:Action)

reasoning [lastPercept = p1]

actionSent[actionSent = ac1]

emptycreate()

e:Env

initialized

init()

perceptsSent

effected ramifiedramifications()

updating [ag1LastAction = ac1 and ag2LastAction= ac2]

actionsReceived[ag1LastAction = ac1

and ag2LastAction= ac2]

[ag.name = ag1] / ag.send(p1:Percept)

send(ac2:Action)

effects(ac1:Action)

effects(ac2:Action)

percept(ag1:Agent, out p1:Percept)perceptsDerived

send(ac1:Action)

create()

stop()

create() stop()

stop()

decided[lastAction = ac1]

send(p1:Percept)

stop() stop()

choose(out ac1:Action)

stop()

send(ac1:Action)stop()

:Sim

running

stopped

run()

ag.create()

env.create()

[ag.name = ag2] / ag.send(p2:Percept)

send(ac1:Action)

remembered

percept(ag2:Agent, out p1:Percept)

Behavior Behavior as as

Message Message SequenceSequence

sse: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()

s:Simulation

run()

stop()

ref AgentReasoning

Behavior as Message SequencesBehavior as Message Sequences

e:Environment a1:Agent

update(p:p1)

sd:EnvironmentUpdating

par

effects(ac:ac1)

effects(ac:ac2)

ramifications()

par

percept(ag:ag1, out p:p1)

percept(ag:ag2, out p:p2)

sd:AgentReasoning

choose(out ac:ac1)

update(ac:ac1)

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.1a. create()1.1b. create()

1.1c. create()

1.1a.1 init()1.1c.1 init()

1.1b.1 init()

1.1b.2a send(p1)

1.1a.5 send(ac1,ag1)

1.1b.2b send(p2)

1.1c.5 send(ac2,ag2)

1. run()

1.1a.2 update(p1)

1.1a.3 choose(out ac1)

1.1a.4 update(ac1)

2. stop()

2.1a. destroy()2.1b. destroy()

2.1c. destroy()

1.1c.2 update(p2)

1.1c.3. choose(out ac2)

1.1c.4 update(ac2)

1.1b.2a effects(ac1)1.1b.2b effects(ac2)1.1b.3 ramifications()1.1b.4a percepts(ag1, out p1)1.1b.4b percepts(ag2, out p2)

Ontologies Reasoning Components Agents Simulations Agent Behavioral Modeling with UML2 Jacques...

Documents

Transcript of Ontologies Reasoning Components Agents Simulations Agent Behavioral Modeling with UML2 Jacques...