Download - Behavioral Modeling with UML2 Superstructure
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
<<K2Action>>OCLExp29
JoinNode
type20[mult39]
<<K2Action>>OCLExp31
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]
<<K2Action>>OCLExp20
<<K2Action>>OCLExp21
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
Action Semantics, Executable UMLAction Semantics, Executable UMLand UML Model Compilersand 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.
Action Semantics, Executable UMLAction Semantics, Executable UMLand UML Model Compilersand UML Model Compilers
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
StatechartsStatecharts
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: ExamplesState Machines: 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