Download
1 / 78
790 likes | 992 Views
Behavioral Modeling with UML2 Superstructure. Jacques Robin. Outline. 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
E N D
Behavioral Modeling with UML2 Superstructure Jacques Robin
Outline • 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
States, Transitions, Lifecycles,Events 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 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 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 Interaction 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 Behaviors Side-effect free encapsulated built-in computation to be provided by underlying platform
Common Behaviors: Events, Triggers and Messages Asynchronous Communication: Caller Sends Signal to Receptor’s Queue, then Switchs to Other Activity Synchronous Communication: Caller Stays Idle While Waiting for Answer
type20[mult39] ActivityParameterNode (ActivPart4) (ActivPart1) InitialNode ExceptionHandler Activity Partition <<K2Except>> OCLExp26 ObjectFlow <<K2Action>> OCLExp19 OpaqueAction InputPin <<K2RcvSignal>> OCLExp25 <<K2RcvSignal>> OCLExp32 type22 Activity Fina lNode AcceptEventAction type20[mult29] OutputPin Activity Partition ForkNode <<K2Action>> OCLExp21 ExpressionInOCL <<K2Action>> OCLExp20 [OCLExp23] <<K2Action>> OCLExp24 type20[mult39] [else] [OCLExp22] DecisionNode [else] JoinNode (ActivPart2) ObjectFlow Call Behavior Action <<K2SubActiv>> A1 Merge Node <<K2Action>> OCLExp29 <<K2SignalSent>> OCLExp28 type21[mult40] Interruptible Activity Region ObjectNode (of Type Signal) Object Flow <<K2Action>> OCLExp31 (ActivPart3) <<K2SendSignal>> OCLExp27 Flow Final Node type20[mult39] Control Flow SendSignalAction [OCLExp30] [else] type20[mult39] Prototypical Activity Diagram with OCL Expressions <<K2Activity>> A1
Action Semantics, Executable UMLand 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 UMLand 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 UMLand 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.
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 vs. Activities
State Machines with OCL Expressions context Bottle inv: (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 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 vs. Behavioral State Machines
