Differences between Rational Rhapsody 8.0 Statecharts and UML 2.4.1 Behavior State Machine

White paper


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.


Disclaimer

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:

Disclaimer

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

UML 2.4.1 Superstructure
Enhancement for Do Activity
Enhancement for Dynamic Condition Connector
Enhancement for Shallow History Connector
Enhancement Deferred Event

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Rational Rhapsody
Documentation

Software version:

7.5, 7.5.0.1, 7.5.1, 7.5.1.1, 7.5.2, 7.5.2.1, 7.5.3, 7.5.3.1, 7.5.3.2, 7.5.3.3, 7.6, 7.6.0.1, 7.6.1, 7.6.1.1, 7.6.1.2, 7.6.1.3, 7.6.1.4, 8.0, 8.0.1, 8.0.2, 8.0.3, 8.0.4, 8.0.5, 8.0.6

Operating system(s):

Linux, Windows

Reference #:

7040251

Modified date:

2014-06-26

Translate my page

Machine Translation

Content navigation