White Papers
Abstract
This is a white paper that explains the differences between IBM Rational Rhapsody 8.0.x Statecharts and UML 2.4.1 Behavior State Machine.
Content
Authors: Shinji Kanai, Moria Abadi
OMG UML and IBM Rational Rhapsody have been evolving in parallel, and some differences were created and expanded over time. Not all graphical notations that are defined in UML specification are supported by Rhapsody. There are certain patterns of transitions you cannot draw due to restrictions imposed deliberately, but not necessarily limited by UML specification. Some of UML features such as deferred event and do-activity are not natively supported today. This document covers such gaps that are found between UML specification and Rhapsody implementation, aiming to help you design statechart more effectively and enable easier interchange of statecharts among UML-based modeling tools.
This documentation is created based on differences that are found between Rhapsody 8.0.x Statechart and OMG UML 2.4.1 Superstructure Specification (UML spec). The content is believed to be accurate at the time of publication. Use this documentation at your own risk as it might contain some incompleteness and imprecision. |
|---|
Table: Graphical Notations and Naming comparison
| UML2.4.1 Concept: | Behavior state machine element or capability as it is named in OMG UML 2.4.1 Superstructure Spec. |
| Section in spec: | The section describing the element in UML spec. |
| In Rhapsody: | The corresponding name and graphical notation of UML concept that is used in Rhapsody. |
| Note: | Additional comments to help understand the specific concept better. |
| UML2.4.1 Concept | Section in spec | In Rhapsody | Note | |
| 1. | Entry Point | 15.3.1 | EnterExitPoint | (*) Visualization using a rectangular symbol is not supported (*) Not supported for composite states (See NO. 36). |
| 2. | Exit Point | 15.3.1 | EnterExitPoint | (*) Visualization using a rectangular symbol is not supported (*) Not supported for composite states, only for submachine states |
| 3. | Final State | 15.3.2 | Termination State | |
| 4. | Initial Pseudostate | 15.3.8 | Default Connector | |
| 5. | Deep History Pseudostate | 15.3.8 | History Connector | |
| 6. | Shallow History Pseudostate | 15.3.8 | Shallow History Connector | (*) Code Generation is supported in v8.0.6. See technote 1668548 for more information. |
| 7. | Join Pseudostate | 15.3.8 | Join Sync Bar | |
| 8. | Fork Pseudostate | 15.3.8 | Fork Sync Bar | |
| 9. | Junction Pseudostate | 15.3.8 | Junction Connector | (*) Used only for merge. Only one outgoing transition is permitted |
| 10. | Static Conditional Branch | 15.3.8 | Condition Connector | (*) Only one incoming transition is allowed. (*) Realized by way of the condition connector. |
| 11. | Terminate Pseudostate | 15.3.8 | termination Connector | |
| 12. | State List | 15.3.8 |  | (*) This is an additional representation for transition from the junction having a history as target. the regular representation can be used instead. |
| 13. | Region | 15.3.10 | Region | |
| 14. | Simple State | 15.3.11 | Simple State | |
| 15. | Composite State | 15.3.11 | Composite State | |
| 16. | Submachine State | 15.3.11 | Sub-statechart | |
| 17. | Entry Behavior | 15.3.11 | Action on Entry | |
| 18. | Exit behavior | 15.3.11 | Action on Exit | |
| 19. | Behavior in state (do-activity) | 15.3.11 |  | (*) Can be implemented using entry and exit actions. See appendix (*2) for additional information. |
| 20. | Deferred events | 15.3.11 |  | (*) Can be modeled by customizing the framework. See appendix (*3) for additional information. |
| 21. | State Redefinition | 15.3.11 | State Redefinition | (*) Class inheritance causes inheritance of statecharts. the inherited statechart can redefine its inherited states. |
| 22. | State Machine extension | 15.3.12 | State machine extension | (*) through class inheritance |
| 23. | Time event | 15.3.13 | Time event | (*) First option tm(<expression>), where<expression> is the number of time units. Second option Accept time event. |
| 24. | Transition | 15.3.14 | Transition | (*) A transition cannot be associated with more than one trigger. Separate transitions for each trigger need to be used. (*) See appendix (*4) for the list of known transaction patterns that are forbidden by Rhapsody. |
| 25. | Internal transition | 15.3.14 | Reaction in state | |
| 26. | Completion transition | 15.3.14 | Null transition | |
| 27. | Completion event | 15.3.14 | Null event | |
| 28. | Transition redefinition | 15.3.14 | Transition redefinition | (*) Class inheritance causes inheritance of statecharts. the inherited statechart can redefine its transitions, except the source state and the trigger. |
| 29. | Signal receipt | 15.3.14 | Accept Event Action | |
| 30. | Signal sending | 15.3.14 | Send Action | |
| 31. | Action sequence notation | 15.3.14 |  | |
| 32. | Local transition | 15.3.15 |  | |
| 33. | Choice Pseudostate/Dynamic Conditional Branch | 15.3.8 |  | (*) Can be simulated for example by using an additional state with guarded outgoing null transitions. See attachment (*1) in appendix. |
| 34. | Final Notation | 15.3.8 |  | (*) {final} means that the state cannot be redefined (such as, extended). |
| 35. | Entry/Exit Point as part of submachine state graph | 15.3.11 |  | |
| 36. | Entry/Exit Point on composite state | 15.3.8 |  | |
| 37. | "Bracket" Entry/Exit Point notation  | 15.3.1 |  | |
| 38. | Referenced/Reused submachine state | 15.3.11 |  | (*) Creation of submachine is supported, but cannot be reused/referenced elsewhere. |
| 39. | Multiple triggers for a transition | 15.3.14 |  | |
| 40. | Extended Notation | 15.3.11 |  | (*) Similar effect is achievable but need to extend a whole class containing a state machine using generalization. |
Appendix:
All source code or binaries attached to this document are referred to here as "the Program". IBM is not providing program services of any kind for the Program. IBM is providing the Program on an "AS IS" basis without warranty of any kind. IBM WILL NOT BE LIABLE FOR ANY ACTUAL, DIRECT, SPECIAL, INCIDENTAL, OR INDIRECT DAMAGES OR FOR ANY ECONOMIC CONSEQUENTIAL DAMAGES (INCLUDING LOST PROFITS OR SAVINGS), EVEN IF IBM, OR ITS RESELLER, HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. |
|---|
(*1) Dynamic Conditional Branch
DynamicBranch74orHigher.zip(*2)
there is a risk that is involved to support an execution of an action that is being performed while the owning object is in a certain state. For example, there is a state "WaitForInput" with Do Action reading an input from the console in the background. Now an event comes to trigger a transition - a need arose to interrupt the operation of reading the input - but there is no generic way to do such things for all operations unless the action is being performed in a different thread and kill this thread. this solution seems risky for embedded systems and considered inefficient.
(*3)
Rhapsody does not support deferred events, but there is an easy way to catch an event, which is not consumed, and process it according to your need. OMReactive class contains handleNotConsumed() virtual function, which can be overridden in your reactive class. This function is always called when event is not consumed.
(*4)Transactional Restrictions - List of known transaction patterns that are forbidden by Rhapsody
| Multiple outgoing transitions from Exit Point |  |
| Transition to Condition Connector from Entry/Exit Point having multiple incoming transitions |   |
| Direct transition from Junction to Condition Connector |  |
| Indirect transition from Junction to Condition Connector by way of Entry/Exit Point |  |
| Direct transition from Join Bar to Junction |  |
| Direct transition from Junction to Fork Bar |  |
| Multiple incoming transition to Condition Connector |  |
| Set a trigger on a transition that is originated from Exit Point |  |
Related Information
Product Synonym
Rational Rhapsody
Was this topic helpful?
Document Information
Modified date:
27 May 2022
UID
swg27040251