1 / 78

Behavioral Modeling with UML2 Superstructure

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

ismael
Download Presentation

Behavioral Modeling with UML2 Superstructure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Behavioral Modeling with UML2 Superstructure Jacques Robin

  2. 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

  3. UML2 Superstructure: Behaviors

  4. 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

  5. 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

  6. 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

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

  8. Common Behaviors Side-effect free encapsulated built-in computation to be provided by underlying platform

  9. Common Behaviors: Parameters

  10. Common Behaviors: Concurrency Modeling

  11. 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

  12. Event Hierarchy

  13. Common Behaviors: Modeling Time

  14. Time Modeling Examples

  15. Activities: Basic Nodes

  16. Activities: Edges

  17. Activity Diagrams: Partitions

  18. Activity Diagrams: Concrete Syntax

  19. Activity Diagrams: Concrete Syntax

  20. 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

  21. Activity Diagram: Examples

  22. Activity Diagram: Examples

  23. Activity Diagram: Examples

  24. Activities: Structured Nodes

  25. RecursiveActivity: Example

  26. Atomic Behaviors: Actions

  27. Atomic Behaviors: Basic Actions

  28. Atomic Behaviors: Object Actions

  29. Atomic Behaviors: Feature Actions

  30. Atomic Behaviors: Link Actions

  31. Atomic Behaviors: Variable Actions

  32. 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

  33. 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.

  34. 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.

  35. StateMachines:Overview

  36. Statecharts

  37. Statecharts

  38. Statecharts

  39. 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

  40. State Machines: State Examples

  41. State Machines: Examples

  42. State Machines: Examples

  43. State Machines: Examples

  44. State Machines: Example

  45. State Machines: Redefinitions

  46. State Machines: Redefinition Example

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

  48. Protocol State Machines

  49. 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

  50. Protocol State Machines: Examples

More Related