uml vs. classical vs. rhapsody state charts not all models are created equal

Softw Syst Model (2007) 6:415–435DOI 10.1007/s10270-006-0042-8

REGULAR PAPER

UML vs. classical vs. rhapsody statecharts: not all modelsare created equal

Michelle L. Crane · Juergen Dingel

Received: 30 January 2006 / Revised: 2 August 2006 / Accepted: 7 December 2006 / Published online: 23 January 2007© Springer-Verlag 2007

Abstract State machines, represented by statechartsor state machine diagrams, are an important formalismfor behavioural modelling. According to the research lit-erature, the most popular statechart formalisms appearto be Classical, UML, and that implemented by Rhap-sody. These three formalisms seem to be very similar;however, there are several key syntactic and semanticdifferences. These differences are enough that a modelwritten in one formalism could be ill-formed in anotherformalism. Worse, a model from one formalism mightactually be well-formed in another, but be interpreteddifferently due to the semantic differences. This papersummarizes the results of an informal comparative studyof these three formalisms with the help of several illus-trative examples. We present a classification of the differ-ences according to the nature of potential problemscaused by each difference. In addition, for each differ-ence we discuss how translation between formalisms canbe achieved, if at all.

1 Introduction

Model driven development (MDD) is a software devel-opment process that has been gaining in popularity inrecent years. MDD focuses on the models, or abstrac-tions of the software system, rather than on the finalprograms [30]; these models are transformed, automat-ically or manually, into code. Executable models are a

Communicated by Dr. Lionel Briand.

M. L. Crane (B) · J. DingelSchool of Computing, Queen’s University,Kingston, ON, Canadae-mail: [email protected]

key component of MDD, as well as such concepts asautomatic transformation of models, validation of mod-els, and standardization to enable interoperability ofdifferent MDD tools (e.g., OMG’s Model Driven Archi-tecture initiative). Within MDD, state machines are apopular way of modelling the behaviour of systems.

With respect to state machines, the most popular for-malisms, as represented in the research literature, areUML state machine diagrams (as specified in UML2.0 [28]), Classical Harel statecharts (implemented inStatemate [12,14]), and a newer object-oriented ver-sion of Harel’s statecharts (implemented in Rhapsody[11]). These three formalisms appear to be very similar.For instance, at first glance, a model written in one for-malism could be easily ported to one of the other two for-malisms. However, there are some subtle syntactic andsemantic differences between the formalisms that canlead to pitfalls. Consider, for example, the state machinesshown in Fig. 1. The two machines are identical, exceptfor the notation used to represent static choice. Fig-ure 1a makes use of a junction (small filled circle); thismachine is well-formed in the Classical and UML for-malisms. Figure 1b shows a condition construct (circled‘C’), which is used by both the Classical and Rhapsodyformalisms. Ignoring the notation difference for a min-ute, this model is well-formed in all three formalisms.However, the behaviour exhibited by the state machineis different for all three. When the state machine firststarts, it moves to state A, at which point the variablex = 0. All three formalisms agree on this point. Wherethey disagree is on what happens when event e occurs.In the Classical formalism, the state machine moves tostate D. In the UML formalism, the state machine movesto state B. Finally, in the Rhapsody formalism, the statemachine moves to state C.

416 M. L. Crane, J. Dingel

A

D (a) (b)

B

C

x:=0

e/x:=1

e

[x<1]

[x>=1] A

D

B

C

Cx:=0

e/x:=1

e

[x<1]

[x>=1]

Fig. 1 Ignoring notation differences, this model is well-formed inall three formalisms, but is interpreted differently in all three. Theclassical state machine moves to D because the priority of con-flicting transitions is handled differently (see Sect. 4.3). In UML,the junction is a static choice, i.e., the guards are evaluated withthe information available at the beginning of the entire transition.Here, x = 0, so the state machine moves to B. In Rhapsody, theconditional is also a static choice, but the fact that it is enclosed in a

composite state causes it to behave as a dynamic choice (see Sect.4.9). The initial transition is a ‘microstep’; variables are evaluatedat the beginning of each microstep. x = 1 when the conditional isreached and the state machine moves to C. State machine inspiredby [11]. a Junction (small filled circle) used for static choice. Modelis well-formed in Classical and UML formalisms. b Conditional(circled ‘C’) used for static choice. Model is well-formed in Clas-sical and Rhapsody formalisms

The fact that there can be three distinct interpreta-tions of one state machine indicates that there is a lack ofconsistency between the three formalisms. It also indi-cates that the task of translating, or porting, a modelfrom one formalism to another may not be straightfor-ward. Therefore, it is worthwhile to study the syntacticand semantic differences between the most popular for-malisms. In this paper, we present a detailed comparisonof these three formalisms, including several illustrativeexamples. Our results are of interest to modellers, cus-tomers, and tool developers because they summarizethe differences between the three most popular formal-isms and thus help to avoid the pitfalls of incorrectlyinterpreted models. On the one hand, modelling andtransformation tools must correctly implement the syn-tax and semantics of a formalism (or more than one,if the tool is expected to import/export models). Onthe other hand, the modellers and customers who makeuse of models to communicate must also be conversantin these details in order to communicate effectively.

This paper is organized as follows: Sect. 2 brieflydescribes state machines and the three formalisms. Sec-tion 3 discusses the kinds of problems that can be causedby inconsistencies between the formalisms, as well as theconcepts of behavioural equivalence and simple transla-tion. Section 4 contains a detailed comparison of syntac-tic constructs and semantic concepts that differ betweenthe three formalisms, including a discussion of the feasi-bility of translating between formalisms. Sections 5 and 6provide tabular summaries of the detailed informationpresented in Sect. 4. Section 7 discusses related work.Finally, Sect. 8 contains the conclusion and contribu-tions of this work, while Sect. 9 discusses future work.

2 State machines, statecharts and state machinediagrams

A finite state machine (FSM) is a model of compu-tation that “specifies the sequence of states an objectgoes through during its lifetime in response to events,together with its responses to those events” [3, Chap. 2].An FSM consists of a set of states, an initial state, aninput alphabet of events and a transition functionmapping current states and event symbols to next states[15]. The term ‘finite state machine’ refers to themodel of computation but not the diagram represent-ing it; instead, the traditional name for a diagram rep-resenting a FSM is ‘state diagram’ or ‘state transitiondiagram’.

FSMs are very useful for representing reactive sys-tems, more so than linear or textual representations,which are typically more suitable for representing trans-formational systems [16]. Ostensibly, an FSM producesoutput only when it reaches a final state; however, thereare many variations, such as Mealy and Moore machines.Mealy machines can produce output along any transi-tion [16], while Moore machines can produce output atany state [8]. The FSMs that we refer to in this contextare Mealy-Moore machines, a combination of these twovariants.

Figure 2 shows part of a simple finite state machinewith three states and five transitions. If the state machinewere in state A, an event b would cause it to move to stateB, while an event c would cause it to move to state C.Similarly, if the machine were in state B, event a wouldcause it to move to state A and event d would cause it tomove to state C, etc.

UML vs. classical vs. rhapsody statecharts 417

A

B

C

bb

a

d

c

Fig. 2 Example finite state machine from [8]

In the late 1980s Harel defined a “visual formalismfor describing states and transitions in a modular fash-ion, enabling clustering, orthogonality, and refinement,and encouraging ‘zoom’ capabilities...between levels ofabstraction” [8]. These new statecharts were essentiallystate transition diagrams with the addition of hierar-chy (also known as depth), orthogonality (also knownas concurrency) and broadcast communications [8,21].Other publications by Harel and other authors quicklyfollowed, defining a preliminary semantics for the state-charts formalism [13,29]. Far from being a final prod-uct, the statecharts formalism evolved over the years,spawning many variants. In fact, as of 1994, there were atleast 20 variants of these statecharts [34]. In 1996, Harelrevisited the formalism, modifying some of the previoussemantics [9,12]. These statecharts are often referredto in the research literature as simply statecharts, Harelstatecharts, or classical statecharts. Because of the factthat the semantics of statecharts has evolved over theyears, and the fact that there are so many variants, itis necessary to define unambiguously which statechartswe refer to. For the purposes of this paper, the termClassical statecharts will be used to represent Harel’soriginal statecharts syntax with the newest semantics, asdocumented in [9,12,14]. Although Harel himself statesthat there is no official semantics for his statecharts [12],Classical statecharts are actually implemented in I-Log-ix’s Statemate tool [20], to which Harel has contributed.

Figure 3 shows a classical statechart fragmentfrom [8]. It demonstrates how the use of hierarchy(implemented with an OR state) can simplify a finitestate machine; this statechart is in fact behaviourallyequivalent to the finite state machine shown in Fig. 2.

The Unified Modeling Language (UML) has becomethe de facto industry standard for general-purpose mod-elling; it can be used for “specifying, constructing anddocumenting the artifacts of a system” [27, Part I]. TheUML is a visual modelling language; different diagramtypes (sub-languages) can be used to model various

A

B

C

b

a

d

D

c

Fig. 3 Example classical Harel statechart showing use of hierar-chy, from [8]. This statechart is behaviourally equivalent to thefinite state machine shown in Fig. 2

parts of the system under consideration. These diagramtypes can be sub-divided into structural and behavio-ural views. In addition, behavioural diagrams can befurther sub-divided into inter-object and intra-objectbehavioural views. UML state machine diagrams1 areone diagram type that can be used to model intra-objectbehaviour, i.e., how individual model elements behave.A state machine diagram is used to represent a statemachine. The syntax and semantics of UML statemachines have remained reasonably consistent through-out UML’s history, although there are occasionallyminor modifications. We concern ourselves with thelatest version of the UML 2.0 Superstructure speci-fication [28].

UML state machine diagrams are an object-basedvariant of Classical statecharts [28,26,7]. An alternativeobject-based variant is one to which Harel himself hascontributed: the statechart formalism implemented in I-Logix’s Rhapsody tool [19]. This formalism was createdafter the introduction of UML 1.1. Actually, the Rhap-sody formalism is more closely related to the UML for-malism than to its Classical ancestor. In fact, there wascooperation between the Rhapsody and UML develop-ment teams, resulting in cross-pollination between thetwo formalisms [10,31]. For instance, [11] states that theUML developers have essentially adopted the underly-ing semantics of Rhapsody as described in [10] and thatRhapsody itself can be considered a tool that “capturesthe executable kernel of UML.” For the purposes ofthis paper, we concern ourselves with Rhapsody as it isdocumented in [10,11].

It should be noted that these three formalisms arenot necessarily located at the same level of abstraction.

1 As of UML 2.0, these diagrams are called state machinediagrams. Previous versions called these diagrams statechartdiagrams.


While UML and Rhapsody are both object-based vari-ants of Classical statecharts, Rhapsody can be viewedas both inspiration and implementation of UML [11]as discussed above. Based on the research literature,it is easy to become confused as to the relationshipsbetween these formalisms and the differences betweenthem. It will become evident that Rhapsody is not afaithful implementation of UML. Not only do Rhapsodystatecharts fail to implement some features specified byUML, but in some ways, Rhapsody statecharts can bemore expressive than those in UML. In addition, boththe Classical and UML formalisms are capable of mod-elling concepts that neither of the other two formalismscan.

Although the main source of information for thispaper was published academic research, where neces-sary, we have tested our examples against the Statemate[20] and Rhapsody [19] implementations.

3 Differences between formalisms

In general, all three formalisms are similar. Basically,statecharts2 are directed graphs, consisting of states andtransitions between them. Transitions may have labelsof the form event[guard]/action. All three formalismssupport both orthogonal (AND) and sequential (OR)composite states.

These basic similarities aside, there are several syn-tactic and semantic differences between the three for-malisms. The syntactic differences concern how varioussyntactic constructs are represented and their well-form-edness constraints, while the semantic differences arecaused by variations in the semantic interpretation ofbasic concepts, such as priority of conflicting transition,handling of simultaneous events, etc.

Our approach to studying the differences betweenthese three formalisms is three-fold. We explore thenature of each difference, with examples. This explora-tion includes a discussion about the feasibility of simpletranslation between formalisms. Then, we classify eachdifference, based on the types of problems that can arisewhen the differences are not taken into account duringtranslation. Finally, we tabulate the results of the transla-tion discussions, distinguishing between differences thatcan be easily translated from those than cannot.

2 In the interests of simplicity, we refer to the diagrams of allthree formalisms as statecharts and use the term state machinewhen referring to the model of computation.

3.1 Effects of differences

The syntactic and semantic differences between formal-isms can be divided into three categories, based on thetype and severity of errors that they can cause whentranslating statecharts from one formalism to another.Note that a particular syntactic construct or semanticconcept can result in differences in more than one cate-gory.

Notation A construct may be common to all three for-malisms and yet be represented with alternative nota-tion. For example, a final state in UML is represented as“a circle surrounding a smaller solid filled circle” [28],while the Classical and Rhapsody formalisms make useof a circled ‘T’. This category is the least critical; after asimple notation translation, a model would be compati-ble with the target formalism(s).

Well-Formedness Differences in this category are moreimportant; they result in models that are well-formed inone or two formalisms, but not in all three. For instance,a construct may not be available in a particular formal-ism, or a formalism may enforce additional or differentconstraints on a common construct. A model could bechecked for compatibility with simple syntax or well-formedness checking. Translation and re-working of amodel may make it compatible with the target formal-ism(s); however, not all models can be made fully com-patible with all formalisms.

Executable behaviour This is the most critical categoryof differences, and the most insidious. A model may bewell-formed in more than one formalism and yet notbehave exactly the same. This type of incompatibilitywould not be found by simple syntax or well-formed-ness checking. In essence, an incompatible model would‘compile’, but its executable behaviour would be otherthan expected, sometimes the opposite of the intendedbehaviour.

3.2 Behavioural equivalence

In general, state machines are composed of states (sim-ple,3 orthogonal composite, sequential composite),pseudostates (initial, final, fork, join, junction, choice)and transitions. A state machine is in a stable state con-figuration when there are no enabled transitions to be

3 A simple state is a state that does not have any substates, i.e., itis not a composite state.


followed. A compound transition is a sequence of tran-sition segments, connected by pseudostates, between asource state and a target state. Movement through astate machine occurs as follows: the state machine is ina stable state configuration; one or more events occur,resulting in zero or more compound transitions becom-ing enabled; one or more compound transitions arefollowed, leaving the state machine in a stable state con-figuration. A state machine never “stops” on the edgeof a composite state, on a pseudostate, or in the middleof a transition segment.

The study of behavioural equivalence of FSMs, statetransition systems, etc. is a mature field. This resultsin different definitions of behavioural equivalence,depending on the application. For our purposes, wemake use of the notion of bisimulation [1] to definebehavioural equivalence. Essentially, two state machinesare bisimilar (behaviourally equivalent) if each can sim-ulate the behaviour of the other.

Two state machines SM1 and SM2 (with the sameinput alphabet I) are behaviourally equivalent if thereis a binary relation β relating simple states of SM1 tosimple states of SM2, such that (s1, s2) ∈ β implies that:1) if there is a compound transition t1 between statess1 and s′

1 in SM1, then there is a compound transitiont2 between states s2 and s′

2 in SM2 and (s′1, s′

2) ∈ β and2) if there is a compound transition t2 between states s2and s′

2 in SM2, then there is a compound transition t1between states s1 and s′

1 in SM1 and (s′1, s′

2) ∈ β. In thestandard definition of bisimulation, t1 = t2; however,in our case, we do not require that the two compoundtransitions be identical, just that their results are. Forinstance, if t1 is a single transition, we permit t2 to betwo transition segments, connected by a pseudostate, aslong as the inputs to the two compound transitions areidentical, the guards are equivalent, and the resultingactions/outputs are the same and are executed in thesame order.

We employ this notion of equivalence because it issimple and intuitive. By using bisimulation to definebehavioural equivalence, we demand that the simplestates of the source state machine be matched with sim-ple states of the target state machine and vice versa. Akey consequence of this pairing is that equivalent statemachines will move between matched stable state con-figurations in the same number of steps.

3.3 Simple translations

We will now use behavioural equivalence to introducethe notion of simple translations. We informally definea simple translation as a shallow manipulation of a

statechart in one formalism in order to produce abehaviourally equivalent statechart in another formal-ism. We call a manipulation shallow when it does notrequire a deep understanding of the statechart. Forexample, it is possible to require some shallow knowl-edge of the underlying model, e.g., a list of all possibleevents. However, it is not permitted to require a mod-eller’s understanding of the model, e.g., the purpose ofthe model, or the desired outcome in the case of non-deterministic choice, etc.

We employ this notion of translation because it is easyto automate. All of the simple translations suggestedinvolve either the addition or deletion of transition seg-ments or pseudostates or the addition of sequential com-posite states for grouping.

We have defined fairly strict criteria for our simpletranslations. Loosening some of these criteria by, forinstance, relaxing the definition of behavioural equiva-lence or dropping the shallowness requirement, wouldallow additional translations. For example, for some ofthe differences listed in the paper, a translation could bedefined that requires a thorough understanding of theentire statechart. However, we will not consider thesemore complex and powerful translations in this paper,because they are much harder to automate. The purposeof the paper is to provide an informal, comparative studyof the differences between state machine formalisms, aswell as a first, preliminary, informal discussion of howsome of these differences can be overcome by automaticmeans. The above definitions suffice for this purpose.A more comprehensive study of additional automaticand user-assisted translations is outside the scope of thispaper and must be left for future work. However, in afew cases, we will also discuss the possibility of non-sim-ple translations, namely:

• translations that might be possible if a differentnotion of behavioural equivalence were used

• translations that might be possible if we were to per-mit additional manipulations

• translations that might be possible if a deep under-standing of the underlying model were available.

4 Detailed comparison

We now examine several syntactic constructs and seman-tic concepts in detail. We start with the semantic con-cepts because, in general, they affect multiple constructsand the overall understanding of the models. Several ofthe more interesting syntactic constructs are then exam-ined.


The results of this examination are summarized inTable 1 in Sect. 5. In addition, while discussing eachsyntactic construct and semantic concept, we examinespecific cases of statecharts that are not well-formed ordo not behave identically in all three formalisms. Wherepossible, we demonstrate by example how to translatethese cases. The results of this research are summarizedin Sect. 6.

4.1 Synchrony hypothesis

4.1.1 Synchrony and zero time

The (perfect) synchrony hypothesis [2] states that asystem must react immediately to external events andthat the corresponding output must occur at the sametime [34]. The zero-time assumption follows from thesynchrony hypothesis and implies that transitions takezero time to execute [26]. In general, Classical state-charts support both the synchrony hypothesis and thezero-time assumption [34,26].4

In UML, a transition may take time [26], althoughno assumptions are actually made, allowing for mod-els with either zero- or fixed-execution time [28, Sect.13.3.30]. The Rhapsody formalism mirrors that of UMLin that a “step does not necessarily take zero time” [11].Therefore, with respect to the zero-time assumption, it istheoretically possible that both the UML and Rhapsodyformalisms adhere to the synchrony hypothesis.

4.1.2 Synchrony and simultaneous events

By the synchrony hypothesis, Classical statecharts mustbe able to react immediately to external events. Theycan do so, supported by the fact that different eventsmay occur simultaneously, and be acted upon simul-taneously, in Classical statecharts [24]. However, nei-ther the UML nor Rhapsody formalisms support thesynchrony hypothesis in this regard. Instead, both for-malisms adhere to the concept of run-to-completion(RTC), which means that each event is handled com-pletely before the next event is processed.5

It is thus impossible in a UML or Rhapsody state-chart for different events to be handled simultaneously.6

4 Note that Classical statecharts semantics, as implemented inStatemate, supports two time models: asynchronous and synchro-nous. Only the asynchronous time model supports zero-time tran-sitions [12].5 In UML, “event occurrences are detected, dispatched, and thenprocessed...one at a time” [28, Sect. 15.3.12]. In Rhapsody, eventsare handled “one by one, in order” [10].6 It is however, possible for the same event to be handled simul-taneously in different regions of an orthogonal composite state.

A

B

C

D

e1 e2

Fig. 4 Statechart with potentially simultaneous events

For example, consider the statechart in Fig. 4. Assumethat the state machine is currently in states A and Cand that events e1 and e2 occur simultaneously. If thiswere a Classical statechart, then both events would behandled simultaneously (since they do not conflict) andthe machine would move to states B and D in one step.However, in the other two formalisms, only one eventcan be handled at a time. Therefore, the state machinewould next move to either states A and D or B and C,depending on which event was handled.

4.1.3 Translation between formalisms

Case 1: Simultaneous events The Classical formalism isthe only one that permits the handling of simultaneousevents, i.e., two or more events being handled at thesame time. There does not appear to be a simple wayto translate a statechart handling simultaneous eventsinto one that does not. It may be possible to translatea Classical statechart with simultaneous events into, forinstance, a UML statechart that mimics the behaviour ofthe Classical statechart in a satisfactory way. However,such a translation would require a deeper understandingof possibly the entire model and a bigger manipulationthan allowed by simple translations. For example, it maybe possible to mimic the results of simultaneous eventsby making use of an additional orthogonal region wherethe occurrence of two consecutive events triggers theissue of a new (composite) event.

4.2 Conjunction, disjunction and negation of events

All three formalisms offer different levels of flexibilityin terms of the combination of event triggers on tran-sitions. Classical statecharts offer the most flexibility,allowing the conjunction, disjunction and negation ofevents. UML is less flexible, offering only the disjunc-tion of events as triggers. Rhapsody is the least flexible


A Be OR f

Fig. 5 Statechart with disjunction of events. This statechart iswell-formed in Classical and UML, but not in Rhapsody

A B

e

f

Fig. 6 Translation of statechart in Fig. 5, removing the disjunc-tion. This statechart is well-formed in all three formalisms

of all three formalisms, allowing only single events astriggers.


In terms of translation between the formalisms, there aresome techniques that could be used to translate from amore flexible formalism to a less flexible one.

Case 2: Disjunction of events A transition triggered bythe disjunction of n events can be replaced by n tran-sitions, each with one event trigger. A simple transla-tion can be used to accomplish this. For example, thestatechart in Fig. 5 contains a transition triggered bythe disjunction of two events. The statechart in Fig. 6removes the disjunction by replacing the transition withtwo transitions, each triggered by exactly one event.

Case 3: Conjunction of events The Classical formalismis the only one that permits transitions triggered by theconjunction of events. There does not seem to be a sim-ple way to translate a statechart using the conjunctionof events into one that does not. It may be possible totranslate a Classical statechart using the conjunction ofevents into, for instance, a UML statechart that mimicsthe behaviour satisfactorily. However, such a translationwould require a deeper understanding of possibly theentire model and a bigger manipulation than allowedby simple translations. For example, it may be possibleto mimic the conjunction of events by making use ofan additional orthogonal region where the occurrenceof two consecutive events triggers the issue of a new(composite) event.

A BNOT e

Fig. 7 Statechart with a transition triggered by the negation of anevent. This statechart is well-formed in Classical but not in UMLor Rhapsody

A B

a OR b OR c OR d OR f

Fig. 8 Translation of statechart in Fig. 7, removing the negationbut assuming that disjunction is permitted. This statechart is well-formed in Classical and UML, but not in Rhapsody. To make thisstatechart well-formed in Rhapsody, simply remove the disjunc-tion as discussed in Case 2 above. Note that the state machine willnot move to state B if no event occurs

A B

a OR b OR c OR d OR f

Fig. 9 Translation of statechart in Fig. 7, removing the negationand assuming that disjunction is permitted. This statechart is well-formed in Classical and UML, but not in Rhapsody. To make thisstatechart well-formed in Rhapsody, simply remove the disjunc-tion as discussed in Case 2 above. Note that the state machine willmove to state B if no event occurs

Case 4: Negation of events If the universe of events isknown, then a simple translation can be used to removethe negation of events on a transition. In this case,the translation would consist of simply replacing thetransition with a negated event trigger with transitionstriggered by every other event. For example, considerthe statechart in Fig. 7 and assume that the universe ofpossible events is {a, b, c, d, e, f }. Then, the statechart inFig. 8 represents the same behaviour.

Note that, in the case of the Classical statechartsimplemented by the Statemate tool, a transition trig-gered by the negation of an event is also triggered bya nil, or empty, event. In other words, the statechart inFig. 7 will move from state A to B when any event otherthan e occurs, or if no event occurs. In this case, thetranslated statechart also requires an additional transi-tion, one triggered by no event, as shown in Fig. 9. Notethat Fig. 9 assumes that disjunction is possible.

4.3 Priorities of conflicting transitions

It is possible in all three formalisms to have conflictingtransitions, i.e., a set of enabled transitions that cannotall be fired due to conflict in their results. For exam-ple, consider the state machine in Fig. 10. Assume thatthe machine is currently in state B and that event e isgenerated. The two transitions enabled by this event areconsidered to be in conflict because their effects conflict.For instance, if the transition into state D is taken, thestate machine moves to state D, and the transition intostate C cannot be taken.

One of the most serious differences between theUML/Rhapsody and Classical formalisms is the han-


DB

C

A TOP

e

e

Fig. 10 Statechart with conflicting transitions

dling of conflicting transitions. In Classical statecharts,the scope of a transition is the lowest OR-state neitherexited nor entered by that transition [12,24]. Priority isgiven to the transition with the highest scope. In the caseof the statechart in Fig. 10, the scope of the transitionfrom B to C is state A, while the scope of the transitionfrom A is D is the state TOP. Since priority is given tothe transition with the highest scope, the latter event ishandled; therefore, the state machine moves to state D.

In UML, a “transition originating from a substate hashigher priority than a conflicting transition originatingfrom any of its containing states” [28, Sect. 15.3.12]. InRhapsody, lower level states also get priority [10]. In thiscase, the transition from B to C originates from state B,which is a substate of state A, the origin of the transitionfrom A to D. Since priority is given to the substates, theformer event is handled; therefore, the state machinemoves to state C in both UML and Rhapsody.

The rationale behind the different priority schemes isnot particularly well-documented, although it has beensuggested that the lowest-first priority scheme espousedby both UML and Rhapsody is more object-oriented.In other words, this priority scheme allows substatesto override superstates in a way that is similar to howsubclass operations/methods can override those of thesuperclass [11].


Case 5: Top-down priority and Case 6: Bottom-up pri-ority The Classical formalism employs a top-down pri-ority scheme, while the other two formalisms employa bottom-up priority scheme. Thus, the priority schemerequires no translation between UML and Rhapsody.However, there does not seem to be a simple way totranslate a statechart from one priority scheme to another. It may be possible to translate from a statechartfrom the Classical priority scheme to the UML/

A Be/x:=x+1; y:=x*5

Fig. 11 Transition with a list of actions [12]

Rhapsody priority scheme, or vice versa. For instance,there may be a way to make use of guards to force cer-tain transitions to be taken in order to conform to aparticular priority scheme. In UML/Rhapsody, to forcea Classical priority, for every event (e.g., e in Fig. 10),guards would have to be placed on outer transitions(e.g., the transition from state A to state D) stating thatthese transitions should only be enabled if there areno inner transitions (e.g., the transition from state B tostate C) that are enabled. In Classical, to force a UML/Rhapsody priority, for every event, guards would haveto be placed on inner transitions stating that these tran-sitions should only be enabled if there are no outertransitions that are enabled. Keeping in mind that anypre-existing guards have to be taken into account, andthat the entire nesting hierarchy of a statechart needsto be considered, these possible translations would notbe simple.

4.4 Order of execution of actions

In all three formalisms, is it possible to list multipleactions on a transition between two states, as shownin Fig. 11. Assume that the state machine is in stateA, x = 0, and event e occurs. In Classical statecharts,actions on a transition are executed in parallel, ratherthan in sequence [12]. Therefore, at state B, x = 1 andy = 0, because both actions were executed in paral-lel.7 In UML however, the behaviour expression “maybe an action sequence comprising a number of distinctactions” and “behaviors are executed in sequence fol-lowing their linear order” [28, Sect. 15.3.14]. Similarly,in Rhapsody, “actions are guaranteed to be performedin sequential order” [11]. For both UML8 and Rhapsodytherefore, at state B, x = 1 and y = 5.

4.4.1 Translation Between Formalisms

Case 7: Parallel execution and Case 8: Sequential exe-cution Here, again, we have a fundamental semanticdifference between the three notations. Classical state-

7 This means that the value of x used in executing x := x + 1 andy := x ∗ 5 is the value that x had at the beginning of the transition[12].8 Typically, the semi-colon “;” implies sequential composition.This example assumes an underlying action language for the modelthat is consistent with this interpretation.


charts permit the parallel execution of actions, while bydefault, UML and Rhapsody do not. In general, paral-lel execution cannot be easily translated to sequentialexecution. With a deep understanding of the underlyingmodel, it may be possible to create translations, e.g., ifthe variables referenced in two statements are indepen-dent, then whether or not these statements are executedsequentially, or in parallel, may be irrelevant.

4.5 Fork and join

Fork and join constructs are common to all three for-malisms, although the notation is slightly different inClassical/Rhapsody than in UML. Published work onthe Classical and Rhapsody formalisms show forks andjoins as simply arrows with either multiple sources ormultiple targets. The UML specification, as well as theRhapsody 6.0 tool itself, show separate fork and joinconstructs, which break the transitions into incomingand outgoing transitions.

In addition to the notational differences between theformalisms, there are several well-formedness differ-ences. For example, actions (or any labelling) are notpermitted on the outgoing transitions of a fork in Rhap-sody. Thus, the UML statechart in Fig. 12 would be ill-formed in Rhapsody, even with the alternate notationtaken into account.

As another example, the Classical statechart in Fig. 13would be ill-formed in both UML and Rhapsody. In thefirst place, Rhapsody does not allow the labelling of tran-sitions leaving a fork. UML does allow the placementof actions on these transitions, but not event triggers.However, there is a much more fundamental seman-tic difference between the Classical and the other twoformalisms. In the Classical formalism, the fork transi-

e/a1

/a2

Fig. 12 This UML fork would be ill-formed in Rhapsody butwell-formed in Classical

e

e1/a1

e2/a2

Fig. 13 This Classical fork would be ill-formed in both UML andRhapsody

e

Fig. 14 This Classical join would be ill-formed in UML but well-formed in Rhapsody

/a1

/a2

Fig. 15 This UML join would be ill-formed in Rhapsody but well-formed in Classical

tion would only be taken if all three events e, e1 ande2 were to occur simultaneously, which is possible sincethe Classical formalism allows for simultaneous events.On the other hand, both UML and Rhapsody adhere tothe RTC assumption; therefore, only one event can behandled at a time.

The Classical statechart in Fig. 14 would be ill-formedin UML because UML does not allow for event trig-gers after the join pseudostate. In addition, the obvioussolution of simply moving the event trigger to the incom-ing transitions would not work; UML does not allow forevent triggers incoming to join pseudostates. In fact,joins are not explicitly triggered in UML; they are onlyused with completion events [31], i.e., leaving the laststate in each region of an orthogonal state. Finally, theUML statechart in Fig. 15 would be ill-formed in Rhap-sody, since Rhapsody does not allow for any labels ontransitions coming into a join. In addition, Rhapsodycannot support joins from more than two orthogonalregions. This is a low-level implementation limitationbased on requirements imposed by the Motor IndustrySoftware Association (MISRA) [18, p. 430]. Becausethis is a low-level tool limitation, we will not be consid-ering it further, but mention it for the sake of complete-ness.


Case 9: Actions after fork In UML, it is possible to haveactions on transitions leaving a fork pseudostate, as seenin Fig. 12. This case is also permitted in Classical state-charts, albeit with a slight notation difference. The actualpseudostate is simply replaced by joined transitions, asin Fig. 16.


e

/a1

/a2

Fig. 16 Classical statechart representation of statechart in Fig. 12

The purpose of the fork is to pass flow of controlto multiple regions of an orthogonal state, i.e., to startconcurrency. In that case, it can be argued that becauseboth actions a1 and a2 in Fig. 12 will be executed, theycould be moved to the transition segment before thefork, as shown in Fig. 17. In this case, the actions will notbe performed in parallel, but sequentially, as discussed inSect. 4.4. However, this translation does not conform toour interpretation of behavioural equivalence becausethe actions along the transition are not executed in thesame order.

Case 10: Events after fork As discussed in Sect. 4.1.3,there does not appear to be a simple way to translatea statechart handling simultaneous events into one thatdoes not. Therefore, the Classical statechart in Fig. 13cannot be simply translated to either UML or Rhap-sody. It may be possible to translate a Classical state-chart making use of events after a fork into, for instance,a UML statechart that mimics this behaviour satisfacto-rily. However, such a translation would require a deeperunderstanding of possibly the entire model, or a differ-ent interpretation of behavioural equivalence. In anycase, such a translation would require a bigger manipu-lation than that allowed by simple translations.

Case 11: Event after join As seen in Fig. 14, it is possiblein Classical and Rhapsody for a transition leaving a jointo be labelled with an event. In other words, this tran-sition would be taken if and when that event occurred.However, this case is not possible in UML as transitionsleaving pseudostates may not be labelled with events.As discussed above, the only way to trigger a join tran-sition is with a completion event. Therefore, there doesnot seem to be a simple way to translate this case to theUML formalism. On the other hand, a translation mightbe possible if we were to relax our definition of behavio-ural equivalence. Specifically, if we allowed the creationof simple states in the target statechart, we could definea translation that produces the statechart in Fig. 18.

Case 12: Actions before join The UML statechart inFig. 15 can be translated to Classical by replacingthe join pseudostate with joined transitions, as shownin Fig. 19.

e/a1;a2

Fig. 17 Possible translation of statechart in Fig. 12 or Fig. 16 toRhapsody. Because the actions will be performed sequentially, notconcurrently, this translation does not conform to our definitionof behavioural equivalence

e

e

Fig. 18 Possible UML statechart translation of Classical/Rhap-sody statechart in Fig. 14. Note that this translation requires anotion of behavioural equivalence that allows the introduction ofsimple states

/a1

/a2

Fig. 19 Classical statechart representing the statechart in Fig. 15

/a1;a2

Fig. 20 Possible translation of statechart in Fig. 15 or Fig. 19 toRhapsody. Because the actions will be performed sequentially, notconcurrently, this translation does not conform to our definitionof behavioural equivalence

The purpose of the join is to pass flow of control frommultiple regions of an orthogonal state to a single state,i.e., to end concurrency. In that case, it can be arguedthat because both actions a1 and a2 in Fig. 15 will beexecuted, they could be moved to the transition segmentafter the join, as shown in Fig. 20. In this case, the actionswill not be performed in parallel, but sequentially, as dis-cussed in Sect. 4.4. However, as discussed in Case 9, thistranslation does not preserve behavioural equivalence.

4.6 History

The Classical and UML formalisms both support deepand shallow history, while the Rhapsody formalism onlysupports deep history.


Fig. 21 UML statechart withdeep history

A

B

H*

Fig. 22 Statemate andRhapsody translation of UMLstatechart in Fig. 21 H*

A

B

4.6.1 Translation Between Formalisms

Case 13: Deep history All three formalisms support deephistory; however, both Rhapsody and the Statemateinterpretation of Classical statecharts require a slightmodification of notation. For example, consider theUML statechart in Fig. 21. No initial pseudostate/tran-sition is required; the history pseudostate points to thedefault state to be entered when the composite state isfirst entered. However, this statechart causes compila-tion errors in the Statemate and Rhapsody tools, eventhough, theoretically, there is nothing wrong with thenotation. Therefore, when translating a UML statechartto either of these two formalisms, it is necessary to addan initial pseudostate, as shown in Fig. 22.

Case 14: Shallow history Although both Classical andUML both support shallow history, there is a slightnotation difference between UML and the Statemateinterpretation of Classical statecharts. As discussedabove, the Statemate tool requires the use of aninitial pseudostate; therefore, the UML statechart inFig. 23 would be translated to the Statemate state-chart in Fig. 24.

On the other hand, Rhapsody does not support shal-low history; this is counterintuitive, since shallow historyis essentially a subset of deep history. The differencebetween shallow and deep history is as follows: Withshallow history, the top-level composite state entered

Fig. 23 UML statechart withshallow history

A

B

H

Fig. 24 Statematetranslation of UML statechartin Fig. 23

A

B

H

“remembers” the last simple state it was in; but noneof the contained composite states remember. With deephistory, this memory extends all the way down to thelowest composite state entered. While in some cases itmay be possible to translate a UML or Classical state-chart with shallow history into a Rhapsody statechartthat mimics the behaviour of the original in a satisfac-tory way, we cannot suggest a general way of performingsuch a translation.

4.7 Junction

Junction constructs are common to all three formal-isms, although there are some well-formedness differ-ences. For example, the Classical statechart in Fig. 25is ill-formed in UML because no events are permittedafter pseudostates. In addition, the Classical statechartin Fig. 26 is ill-formed in both UML and Rhapsody. UMLdoes not allow for event triggers on transitions outgoingfrom a pseudostate, while Rhapsody does not allow formore than one outgoing transition from a junction.


Case 15: Event after junction The statechart in Fig. 25can be translated to UML, using a simple translation,by moving the event trigger to the transition segments


e

Fig. 25 This Classical junction can be made compatible to UML

e1

e2

Fig. 26 This Classical junction would be ill-formed in UML andRhapsody

e

e

Fig. 27 UML statechart translation of Classical statechart inFig. 25

e1

e2

Fig. 28 Translation of statechart in Fig. 26, well-formed in bothUML and Rhapsody

coming into the junction, as shown in Fig. 27. The Classi-cal statechart is already compatible in Rhapsody techni-cally, but when drawing such a statechart, the Rhapsodytool actually moves the event to the transition segmentscoming into the junction.

Case 16: Multiple events after junction The statechart inFig. 26 could be converted to UML, using a simple trans-

Fig. 29 This statechart is well-formed in both UML and Classical,but not in Rhapsody

Fig. 30 Rhapsody translation of statechart in Fig. 29

C

[g1]

[g2]

e

Fig. 31 Conditional construct supported by Classical andRhapsody formalisms

lation, by removing the junction altogether and replac-ing it with two transitions. Figure 28 shows the resultingUML statechart. For Rhapsody, since only one outgoingtransition is permitted for a junction (i.e., a junction isonly a merge), the statechart in Fig. 28 would also be thetranslation.

Case 17: Junction as merge/split Because Rhapsodydoes not allow for more than one transition leaving ajunction, the Classical and UML statechart in Fig. 29is not well-formed in that formalism. To translate thisstatechart, using a simple translation, we remove thejunction altogether and replace it with multiple transi-tions, as shown in Fig. 30.

4.8 Conditional

Classical and Rhapsody statecharts support a specificconditional construct, as shown in Fig. 31. This constructsimply represents a static choice, i.e., the guards on theoutgoing transitions are evaluated before the transitionis taken.


Case 18: Conditional construct The conditional con-struct no longer exists in UML,9 but its semantics canbe mimicked with the standard junction pseudostate, asshown in Fig. 32.

9 The conditional construct was removed from UML 1.3, since itis equivalent to a junction [6, Sect. 3.4.3].


C

[g1]

[g2]

e

Fig. 32 UML supports the same static choice by using the junc-tion pseudostate

A

B

C

x:=0

e/x:=1[x<1]

[x>=1]

Fig. 33 UML supports dynamic choice. This state machine willmove to state C

4.9 Choice

UML does allow for a dynamic choice pseudostate,which is not equivalent to the Classical/Rhapsody condi-tional construct. Consider the UML statechart in Fig. 33.When the state machine starts, it moves to state A andx = 0. When event e occurs, the action on the transitionis executed before the guards on the outgoing transi-tions are evaluated. The state machine will thus move tostate C.


Case 19: Choice construct Although neither the Classi-cal nor Rhapsody formalisms support a dynamic choiceconstruct, it is possible to simulate it in Rhapsody andto define an appropriate simple translation. Considerthe Rhapsody statechart in Fig. 34. In this case, the factthat Rhapsody makes use of microsteps [11] comes intoplay. The default, or initial, transition is considered amicrostep. Attributes are assigned their values at thebeginning of each microstep, so the assignment x := 1is executed as the state machine enters the compositestate. Once the conditional is reached, x = 1, so the state

A

B

C

x:=0

e/x:=1[x<1]

[x>=1]

C

Fig. 34 Dynamic choice can be simulated in Rhapsody. This statemachine will move to state C. In classical, however, this statemachine moves to state B

A

B

C

x:=0

e/x:=1[x<1]

[x>=1]

C

Fig. 35 Rhapsody statechart from Fig. 34 will not behave iden-tically in UML. In UML, this state machine will move to state B

machine would move to state C. On the other hand, inthe Statemate implementation of Classical statecharts,the state machine in Fig. 34 would move to state B.Therefore, there is no way to simulate dynamic choicein Classical statecharts.

It is very important to note that even if the conditionalin Fig. 34 were replaced by UML’s static choice construct(junction), as in Fig. 35, the state machine would notbehave identically in UML. UML does not make use ofmicrosteps, and the action along the transition will notbe considered when the guards are evaluated [31]. If thestate machine in Fig. 35 were to be evaluated in UML,it would move to state B.

4.10 More on compound transitions

In Classical statecharts, any composition of pseudostates,simple transitions, guards and labels is permitted, butthese transition compositions are constrained for prac-tical purposes in UML state machines [26] and Rhap-sody statecharts. Therefore, there are some Classicalstatecharts that cannot be simply translated to UML.Consider, for example, the statecharts below. These twoequivalent statecharts are well-formed in the Classicalformalism but neither of them is well-formed in UMLor Rhapsody. Figure 36a shows a compound transitionbetween two states. Both transitions are labelled with anevent trigger and an action. In the Classical formalism,the transition coming into the junction cannot be exe-cuted without also executing the transition coming outof the junction [12]. Therefore, this compound transitionis equivalent to the single transition in Fig. 36b, which islabelled with the conjunction of two events, and a pairof resultant actions.


Case 20: Compound transition with event/action on eachsegment Neither of the equivalent statecharts in Fig. 36would be well-formed in UML or Rhapsody. On theone hand, the statechart in Fig. 36b is ill-formed becauseneither UML nor Rhapsody allows for the conjunction


A Be1/a1 e2/a2

(a)

A Be1 and e2/a1;a2

(b)

Fig. 36 Sample compound transition from Classical statecharts and its equivalent single transition (with conjunction of events) [12] (a)Compound Transition. (b) Conjunction of Events

of events. On the other hand, the statechart in Fig. 36a isalso ill-formed because UML does not allow for triggerson transitions leaving a pseudostate [28, Sect.15.3.14]and Rhapsody does not allow for any label on the tran-sition leaving the junction. Therefore, there does notappear to be a general simple translation from theseClassical statecharts to equivalent UML or Rhapsodyversions.

5 Comparison summary

Table 1 summarizes the findings of the previous sectionwith respect to the constructs and concepts available ineach formalism, as well as the nature of problems thatdifferences between formalisms can cause. The left-handcolumns of the table summarize the syntactic and seman-tic differences between UML 2.0, Classical statechartsand Rhapsody statecharts. UML 2.0 is used as the base-line, with Classical and Rhapsody both being comparedto it.

The left-most column lists most of the features ofUML 2.0 behavioural state machines as documented in[28]. The following features are not included:

• submachines and entry/exit pseudostates• terminate pseudostates• object creation/destruction• state machine extension.

The right-hand columns indicate in which potentialproblem categories each construct and concept fall:

• The notation category indicates differences whichcan be easily managed, i.e., a model in one formal-ism can be easily translated to the other formalismswith a simple notation translation, e.g., replacing aconditional pseudostate in Classical/Rhapsody witha junction pseudostate in UML.

• Differences in the well-formedness category aremore serious. Sometimes it is possible to define asimple translation (as defined in Sect. 3.3), e.g., theUML statechart in Fig. 32 represents the Classical/Rhapsody statechart in Fig. 31. Unfortunately, not allmodels can be made compatible, e.g., the Classical

statechart in Fig. 14 cannot be simply translated intoan equivalent UML statechart.

• Finally, differences in execution behaviour are themost serious of all. This is not because they implya model cannot be translated to another formalism,but because a model designed with constructs/con-cepts from this category can be well-formed in morethan one formalism and yet behave differently ineach. The statecharts in Fig. 1 are prime examples ofthis particular pitfall.

Obviously, problems caused by well-formednessdifferences can also cause problems in execution behav-iour. For example, a UML statechart with deferredevents10 would be ill-formed in the other two formal-isms. However, if the deferred events were simplyremoved, the state machine would not behave asexpected. In this case, the execution behaviour problemwould not be indicated in Table 1, since the well-form-edness problem itself alerts modellers of the mismatchand thus encourages them to ensure that a ported modelis well-formed and behaves as expected. Instead, thebehavioural problems indicated in Table 1 are in addi-tion to any notational or well-formedness problems forthat construct/concept, and not caused by them.

Not only does this table present a comprehensivesummary of the differences between the three formal-isms, but it also brings to light several facts, such as:

• Rhapsody is much syntactically and semanticallycloser to UML than to its Classical ancestor, espe-cially with respect to behavioural semantics. Thismeans that models can be more easily translatedbetween UML and Rhapsody than between eitherof these formalisms and Classical statecharts.

• UML is the only formalism that allows for dynamicchoice.

• Many of the well-formedness and execution behav-iour differences are indirectly caused by the fact that

10 Normally, when an event occurs, it either matches the eventtrigger on some transition and is handled, or it does not match anytrigger and is ignored. However, the use of deferred events allowsthe state machine to recognize certain events (which do not triggertransitions) and postpone responding to them [28, Sect. 15.3.11].


Table 1 Summary of differences between Classical, UML and Rhapsody statechart formalisms. Left-hand columns summarize syntacticand semantic differences. Right-hand columns indicate the severity of problems caused by these differences

UML and Rhapsody do not support simultaneousevents or actions, e.g., with respect to do-activities,forks, joins, junctions, and event triggers.

• Although the priority scheme between the Classicaland UML/Rhapsody formalisms is inverted, it does

not cause any notation or well-formedness prob-lems with the syntactic constructs. In other words,the fact that a model would behave differently dueto the opposite priority schemes would not be foundby a syntax or well-formedness checker.


6 Translation between formalisms

In Sect. 5, we summarized how well each of our three for-malisms supports several syntactic constructs andsemantic concepts, as well as what types of problemscould arise when translating statecharts. While discuss-ing these constructs and concepts in detail in Sect. 4, wedemonstrated how certain cases could be simply trans-lated from one formalism to another. Tables 2 and 3summarize the results of this research.

Table 2 provides a summary of the cases exploredin Sect. 4, indicating which specific cases are supportedby each formalism. For each ⊗ in the table, indicatingthat a case is not supported by a particular formalism,we have examined the feasibility of a simple translationfor that case. The final results are presented in Table 3.Where possible, the detailed case discussion in Sect. 4provides the rules of translation by example, or informaldiscussion about the infeasibility of such a translation.

6.1 Relative expressiveness of the formalisms

In general, it can be said that the Classical formalism isthe most expressive, as it offers the most flexibility, e.g.,simultaneous events; simultaneous actions; conjunction,disjunction and negation of events; shallow and deephistory. Similarly, Rhapsody can be considered the leastexpressive formalism: only single events as triggers, noshallow history, no simultaneous events or actions. Theseclaims are supported by Table 2. Keeping in mind thatcases 5/6 and 7/8 are mutually exclusive, i.e., a formalismsupports either one or the other, the Classical formalismsupports most of the cases detailed in Sect. 4. Similarly,Rhapsody supports the least.

Consider the Venn diagram in Fig. 37. It shows howeach of the cases from Table 3 relates to the three for-malisms. The white sections of the diagram, i.e., thoseportions of the Venn diagram with no overlap, indicatecases that are supported by exactly one formalism. Forinstance, Cases 1, 3, 4, 5, 7, 10, 16, 20, are supported onlyby the Classical formalism. The lightly-shaded sectionsof the diagram (overlap between two circles) show thosecases supported by two formalisms. For example, Cases6 and 8 are supported by both UML and Rhapsody.Finally, the heavily-shaded section (overlap between allthree circles) show exactly one case, 13, which is the onlycase that is supported by all three formalisms.

In addition, the diagram indicates whether or nottranslation of particular cases between formalisms ispossible. An arrow pointing to the right indicates thatthe specific case can be translated to Rhapsody. Simi-larly, an arrow pointing down indicates that the specificcase can be translated to UML. Notice that there are

20

1

2

3

4

7

89

10

11

12

1314

15

16

17

18

19

5

6

Classical

RHAPSODY

UML

21

Fig. 37 Venn diagram showing which cases are supported by eachformalism, as well as which cases can be translated. White sec-tions indicate cases that are supported by exactly one formalism.Lightly-shaded sections indicate cases that are supported by twoformalisms. The heavily-shaded section indicates one case that issupported by all three formalisms. Arrows pointing to the rightindicate that translation to Rhapsody is possible. Arrows pointingdown indicate that translation to UML is possible. There are noarrows pointing up, indicating that there are no cases that can betranslated to Classical

no arrows pointing up, i.e., there are no cases supportedonly by UML and/or Rhapsody that can be translated toClassical.

It should be noted that there is not a strict orderingamong the formalisms in terms of expressiveness. Clas-sical supports the most cases (18), followed by UML (9),followed by Rhapsody (7). However, there are severalcases supported by Rhapsody that are not supported byUML, i.e., Cases 11, 15, 18, 21 are supported by bothClassical and Rhapsody, but not by UML. In addition,two of these cases, 11 and 21, have no simple translationto the UML formalism.

6.2 Complexity of translations

As implied by the symbols used in Table 3, we distinguishbetween two types of simple translation.

• Trivial simple translations Those mappings markedwith � indicate that both the source and target for-malism support the specific case under consider-ation, albeit it with a minor notation change. Forexample, converting the joined lines in Classical toa join or fork pseudostate in UML (Cases 9 and


Table 2 Summary of specific cases discussed in Sect. 4. See Table 3 for information about whether or not a simple translation is possiblebetween formalisms

12). Another example would be necessity of add-ing an initial pseudostate to Classical and Rhapsodywhen using a history pseudostate (Case 13). Theseare very simple mappings and can most definitely beautomated.

• Simple translations Those mappings marked with� indicate that the specific case in question can besimply translated from the source to the target for-malism, where a simple translation conforms to ourdefinition in Sect. 3.3. These translations are slightlymore complicated than simply swapping out onenotation for another, but do not involve any moremanipulations than the addition/deletion of transi-tion segments, addition/deletion of pseudostates, oraddition of sequential composite states for grouping.It should be quite possible to automate these typesof translation.

As can be seen from Table 3 and Fig. 37, about halfof the cases can be easily translated to the target for-malism(s). For the most part, these translations are rela-tively simple, such as moving events from one transitionsegment to another (Case 15) or duplicating transitionsin order to remove a junction pseudostate (Cases 16and 17). The simulation of dynamic choice in Rhapsody(Case 19) is the most complicated translation. In general,

these translations are straightforward since they onlydeal with pure syntax or well-formedness constraints.

On the other hand, the semantic concepts are muchharder to translate. Take, for instance, the fact thatthe priority scheme in Classical vs. UML/Rhapsody isreversed makes it extremely difficult, if not impossi-ble, to define a rule that could be used to automaticallytranslate a statechart from one formalism to another. Asanother example, consider the fact that Classical state-charts permit the handling of events simultaneously,as well as the triggering of events by the conjunctionof events. There does not appear to be a simple wayto translate statecharts using these concepts whilemaintaining our definition of behavioural equivalence,requirement for no deep understanding of the underly-ing model, and restrictions on permitted manipulations.In other words, translating these types of statechartscould require a complete redrawing of the statechart inthe target formalism.

7 Related work

The UML 2 Semantics Project [32] is an internationalcollaboration including IBM (Canada, Germany, Israel),Queen’s University (Canada), the Technical University


Table 3 For each specific case identified in Table 2, this tableindicates whether or not simple translation between formalismsis possible. A simple translation is defined as a shallow manipula-tion of a statechart in the source formalism in order to produce abehaviourally equivalent statechart in the target formalism. Other

translations may be possible, but they would require a differentnotion of behavioural equivalence, a deep understanding of possi-bly the entire underlying model, and/or a relaxing of the manipu-lations permitted during translation. Abbreviations of formalisms:C for Classical, U for UML, and R for Rhapsody

of Munich (Germany), and the Technical University ofBraunschweig (Germany). The purpose of this projectis to define a formal semantics of UML 2.0. Under theauspices of this project, we have initiated an effort tosurvey, categorize and compare semantic approachesfor formalizing state machine behaviour [4]. In order tocritique these approaches, we needed a detailed under-standing of the syntax and intended semantics of statemachines. During our literature review, it became appar-ent that Classical, UML and Rhapsody statecharts couldnot be considered equivalent, even though at first glance,they appear almost identical.

Unfortunately, although there is much research relat-ing to these formalisms, there is no definitive comparisonbetween them. The most detailed comparison is abulleted list in an older UML specification [26, Sect.2.12.5.4], which is not even included in the new UML 2.0specification. Other sources offer one- or two-line high-level comparisons between Classical and UML state-charts, without going into great detail. The bulk of theresearch presented in this paper is thus a result ofdetailed inspection of the UML specification [28], as wellas key documents relating to the Classical [8,9,12,14]and Rhapsody [10,11] formalisms.


In addition, two other documents [34,24] were invalu-able, as they offered an outsider’s perspective to under-standing Classical statecharts. [34] was particularlyuseful as background material in that it examinedsome twenty variants of Harel’s original statechartsformalism. The variants were compared along manydimensions, including adherence to the synchronyhypothesis, zero-time transitions, simultaneous events,priority scheme, etc.

8 Conclusion

In the research literature, there are currently three pop-ular formalisms for modelling state machines: UMLstate machine diagrams, Classical statecharts and Rhap-sody statecharts. Modellers may adhere to MDD with-out being restricted to one particular formalism. Ingeneral, the similarities between Classical statecharts,UML state machine diagrams, and the statecharts imple-mented by the Rhapsody tool are often enough to implyto the non-expert that a state machine modelled in oneformalism can be interpreted in the other formalisms.Unfortunately, this is not necessarily the case; there areenough syntactic and semantic differences between theformalisms to cause problems when sharing models.

Some problems are caused by simple notation differ-ences and can be solved with a translation. Some prob-lems cause well-formedness issues; occasionally, theseproblems can be solved with translation or re-workingof the model. Occasionally, these problems cannot besolved, but at least their presence can be identified bysyntax or well-formedness checks. Finally, some prob-lems cannot be identified by such checks; these are themost insidious problems and result in well-formed mod-els which behave differently in different formalisms.

The results of this research are of interest to model-lers, tool developers, and end users of statecharts andstate machine diagrams for the following reasons:

• Modellers should be aware of how their models willbe interpreted in different formalisms. This is espe-cially important with respect to execution behaviourissues, where a modeller might be expecting a differ-ent behaviour than that exhibited by a model. In thesame vein, statecharts can be used as a communica-tion medium between modellers and their custom-ers, or end users. Users may interpret these modelsdifferently, based on an alternate formalism withwhich they are familiar. Indeed, the users may noteven be aware that their interpretation is different,

leading to a modeller/customer disconnect, whichmay not be noticed.

• Similarly, models might be shared between mod-ellers, or ported from one modelling environmentto another. If the participants are not aware of thepotential problems of notation, well-formedness andexecution behaviour, these models cannot be sharedor ported accurately.

• Finally, tool developers should also be aware ofthese differences and potential problems in order togear their tools to particular formalisms. Tool devel-opers may also offer import/export capabilities; ourwork indicates the parts of a model that must betranslated or otherwise modified. In addition, thedevelopment of syntax and well-formedness check-ers can benefit from knowledge of these differences.

9 Future work

The following areas could be considered fertile groundfor future work:

• Using the specific cases described in Sect. 4, identifynecessary requirements for a statechart to be consid-ered portable between the various formalisms. Thiscould take the form of a list of constraints that cre-ate a ‘core’ statechart that would be compatible withtwo or three of the formalisms. Due to the nature ofthe differences between the three formalisms, therecould be two levels of portability:• Portability between Classical and UML/Rhap-

sody. Many of the problems in porting betweenClassical and the other two formalisms arecaused by Classical’s use of simultaneous events,simultaneous actions, and the inverted priorityof conflicting transitions. Therefore, the con-straints for portability at this level would bequite stringent, for instance: one event triggerper transition, one action per transition, no con-flicting transitions, etc.

• Portability between UML and Rhapsody. Onthe other hand, these two formalisms are actu-ally quite similar; their major differences aredue to notation or well-formedness. Constraintscould include: no labels after fork pseudostates,no labels before join pseudostates, no choicepoints, etc. In addition, care would have to betaken when porting Rhapsody statecharts usingconditional pseudostates enclosed in compositestates, as discussed in Sect. 4.9.


• Using the requirements for portability listed aboveand the translations informally explained in Sect.4, create algorithms and perhaps tool support forporting statecharts between formalisms. As it stands,only about half of the cases summarized in Table 3could be automatically translated by a tool. The restof the cases could require deep understanding, andeven extensive refactoring, of the underlying sourcemodel.

• For those cases in Sect. 4 for which there does notappear to be a simple transition, investigate thefeasibility of more complex translations, perhapsincluding a deeper understanding of the underly-ing model, or creating translations based on differ-ent interpretations of behavioural equivalence. Ifapplicable, formally argue that such translations areimpossible.

• The results documented in this paper are not for-mally derived; they were obtained by careful exam-ination of academic research and exploration ofexamples. It would be interesting to map each for-malism to the same semantic domain and formallycompare the results of these mappings. Althoughthere exist many mappings of the Classical (e.g., [5],[17], [21], [25], [22], [23], [33]) and UML (see [4] for adiscussion of two dozen approaches) statechart for-malisms to particular semantic domains, we wouldmap to a semantic domain (as yet unpublished) cur-rently being developed by the UML 2 SemanticsProject [32].

Acknowledgements We would like to acknowledge the invalu-able assistance of Bran Selic from IBM Rational Software Canada.We would also like to thank the reviewers for their insightful com-ments and questions. This research is supported by the OntarioGraduate Scholarship program and the IBM Centers forAdvanced Studies.

References

1. Alur, R., Benedikt, M., Etessami, K., Godefroid, P., Reps, T.,Yannakakis, M.: Analysis of recursive state machines. ACMTrans. Program. Languages Systems 27(4), 786–818 (2005)

2. Berry, G., Gonthier, G.: The ESTEREL synchronous pro-gramming language: design, semantics, implementation. Sci.Comput. Program. 19, 87–152 (1992)

3. Booch, G., Rumbaugh, J., Jacobson, I.: The Unified ModelingLanguage User Guide. Addison-Wesley (1999)

4. Crane, M.L., Dingel, J.: On the semantics of UML statemachines: Categorization and comparison. Technical Report2005-501, School of Computing, Queen’s University (2005)

5. Damm, W., Josko, B., Hungar, H., Pnueli A.: A compositionalreal-time semantics of STATEMATE designs. In: Composi-tionality: The Significant Difference, Lecture Notes in Com-puter Science, vol. 1536, pp. 186–238. Springer, Heidelber(1998)

6. Douglass, B.P.: Real Time UML. Object Technology Series.3rd edn. Addison-Wesley (2004)

7. Gogolla, M., Parisi-Presicce F.: State diagrams in UML: aformal semantics using graph transformations. In: Proceed-ings of the Workshop on Precise Semantics for ModellingTechniques (PSMT’98), pp. 55–72. Technische UniversitätMünchen, TUM-I9803 (1998)

8. Harel, D.: Statecharts: a visual formalism for complexsystems. Sci. Comput. Program. 8(3), 231–274 (1987)

9. Harel, D.: Some thoughts on statecharts, 13 years later. In:Proceedings of the 9th International Conference on Com-puter Aided Verification (CAV’97), Lecture Notes in Com-puter Science, vol. 1254, pp. 226–231. Springer, Heidelberg(1997)

10. Harel, D., Gery, E.: Executable object modeling with state-charts. Computer 30(7), 31–42 (1997)

11. Harel, D., Kugler H.: The Rhapsody semantics of statecharts(on, on the executable core of the UML) (preliminary ver-sion). In: SoftSpez Final Report, Lecture Notes in ComputerScience, vol. 3147, pp. 325–354. Springer, Heidelberg (2004)

12. Harel, D., Naamad, A.: The STATEMATE semanticsof statecharts. ACM Trans. Soft. Eng. Methodol. (TO-SEM), 5(4), 293–333 (1996)

13. Harel, D., Pnueli, A., Schmidt, J.P., Sherman R.: On the for-mal semantics of statecharts. In: Proceedings of the 2nd IEEESymposium on Logic in Computer Science, pp. 54–64. Com-puter Society Press of the IEEE (1987)

14. Harel, D., Politi M.: Modeling Reactive Systems with State-charts: The STATEMATE Approach. McGraw-Hill (1998)

15. Howe, D. (ed.): The free on-line dictionary of computing.http://www.foldoc.org/

16. Huizing, C., de Roever, W.P.: Introduction to design choicesin the semantics of statecharts. Inform. Process. Lett. 37(4),205–213 (1991)

17. Huizing, C., Gerth, R., de Roever, W.P.: Modelling State-charts behaviour in a fully abstract way. In: CAAP ’88: 13thColloquium on Trees in Algebra and Programming, LectureNotes in Computer Science, vol. 299, pp. 271–294. Springer,Heidelberg (1988)

18. I-Logix: Rhapsody 6.2 User Guide19. I-Logix: Rhapsody. http://www.ilogix.com/sublevel.aspx?

id=5320. I-Logix: Statemate. http://www.ilogix.com/sublevel.aspx?

id=7421. Lüttgen, G., von der Beeck, M., Cleaveland, R.: A composi-

tional approach to statecharts semantics. In: Proceedings ofthe 8th ACM SIGSOFT International Symposium on Foun-dations of Software Engineering, pp. 120–129. ACM Press(2000)

22. Maggiolo-Schettini, A., Peron, A.: A graph rewriting frame-work for statecharts semantics. In: Proceedings of the Inter-national Conference on Graph Grammars (GRAGRA),Lecture Notes in Computer Science, vol. 1996, pp. 107–121.Springer, Heidelberg (1996)

23. Maggiolo-Schettini, A., Peron, A., Tini, S.: A comparison ofstatecharts step semantics. Theor. Comput. Sci. 290(1), 465–498 (2003)

24. Mikk, E.: Semantics and Verification of Statecharts. PhD the-sis, Christian-Albrechts University of Kiel, 2000. Bericht Nr.2011

25. Mikk, E., Lakhnech, Y., Siegel M.: Hierarchical automata asmodel for statecharts. In: Proceedings of the Asian Comput-ing Science Conference (ASIAN ’97), Lecture Notes in Com-puter Science, vol. 1345, pp. 181–196. Springer, Heidelberg(1997)


26. OMG. UML specification. Document formal/03-03-01,Object Management Group, Version 1.5 (2003)

27. OMG. UML 2.0 infrastructure specification. Documentptc/03-09-15, Object Management Group (2004)

28. OMG. Unified Modeling Language: Superstructure version2.0. Document formal/05-07-04, Object Management Group(2005)

29. Pnueli, A., Shalev M.: What is in a step: On the semantics ofstatecharts. In: Proceedings of the International Conferenceon Theoretical Aspects of Computer Software (TACS’91),Lecture Notes in Computer Science, vol. 526, pp. 244–264.Springer, Heidelberg (1991)

30. Selic, B.: The pragmatics of model-driven development. IEEESoftw. 20(5), 19–25 (2003)

31. Selic B.: Personal Communication (Email dated 4 Mar 05)(2005)

32. UML 2 Semantics Project. http://www.cs.queensu.ca/ Estl/internal/uml2

33. Uselton, A.C., Smolka, S.A.: A compositional semantics forstatecharts using labeled transition systems. In: Proceedingsof Concurrency Theory (CONCUR ’94), Lecture Notes inComputer Science, vol. 836, pp. 2–17. Springer, Heidelberg(1994)

34. von der Beeck, M.: A comparison of statecharts variants. In:Formal Techniques in Real-Time and Fault-Tolerant Systems(FTRTFT’94), Lecture Notes in Computer Science, vol. 863,pp. 128–148. Springer, Heidelberg (1994)

35. von der Beeck, M.: A structured operational semanticsfor UML-statecharts. Softw. Systems Modeling 1(2), 130–141 (2002)

Author’s Biography

Michelle L Crane obtainedher B.Comm, with a special-ization in Management Infor-mation Systems, from theUniversity of Ottawa, Canada,in 1992. She spent a decadein the Canadian Forces, retir-ing in 2000 to pursue graduatestudies in Computer Science.She completed her M.Sc. atQueen’s University, Canada in2003 and is currently pursu-ing her Ph.D. at the same uni-versity. Her research interestsinclude state machines, formalsemantics, light-weight formal

methods, and the Unified Modeling Language, specifically actionsand activity diagrams.

Juergen Dingel received anM.Sc. from Berlin Universityof Technology in Germanyand a Ph.D. in Computer Sci-ence from Carnegie MellonUniversity (2000). Since 2000,he has been on the facultyof the School of Computingat Queen’s University wherehe leads the Applied FormalMethods Group. His researchinterests include the formalspecification, verification andanalysis of software systems ingeneral, and software model

checking, model-based testing and the foundations of model-driven development in particular.

uml vs. classical vs. rhapsody state charts not all models are created equal

Documents