Softw Syst Model (2007) 6:415435 DOI 10.

1007/s10270-006-0042-8

R E G U L A R PA P E R

UML vs. classical vs. rhapsody statecharts: not all models are 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 statecharts or state machine diagrams, are an important formalism for behavioural modelling. According to the research literature, the most popular statechart formalisms appear to be Classical, UML, and that implemented by Rhapsody. These three formalisms seem to be very similar; however, there are several key syntactic and semantic differences. These differences are enough that a model written in one formalism could be ill-formed in another formalism. Worse, a model from one formalism might actually be well-formed in another, but be interpreted differently due to the semantic differences. This paper summarizes the results of an informal comparative study of these three formalisms with the help of several illustrative examples. We present a classication of the differences according to the nature of potential problems caused by each difference. In addition, for each difference we discuss how translation between formalisms can be achieved, if at all.

1 Introduction Model driven development (MDD) is a software development process that has been gaining in popularity in recent years. MDD focuses on the models, or abstractions of the software system, rather than on the nal programs [30]; these models are transformed, automatically or manually, into code. Executable models are a
Communicated by Dr. Lionel Briand. M. L. Crane (B) J. Dingel School of Computing, Queens University, Kingston, ON, Canada e-mail: crane@cs.queensu.ca

key component of MDD, as well as such concepts as automatic transformation of models, validation of models, and standardization to enable interoperability of different MDD tools (e.g., OMGs Model Driven Architecture initiative). Within MDD, state machines are a popular way of modelling the behaviour of systems. With respect to state machines, the most popular formalisms, as represented in the research literature, are UML state machine diagrams (as specied in UML 2.0 [28]), Classical Harel statecharts (implemented in Statemate [12, 14]), and a newer object-oriented version of Harels statecharts (implemented in Rhapsody [11]). These three formalisms appear to be very similar. For instance, at rst glance, a model written in one formalism could be easily ported to one of the other two formalisms. However, there are some subtle syntactic and semantic differences between the formalisms that can lead to pitfalls. Consider, for example, the state machines shown in Fig. 1. The two machines are identical, except for the notation used to represent static choice. Figure 1a makes use of a junction (small lled circle); this machine is well-formed in the Classical and UML formalisms. Figure 1b shows a condition construct (circled C), which is used by both the Classical and Rhapsody formalisms. Ignoring the notation difference for a minute, this model is well-formed in all three formalisms. However, the behaviour exhibited by the state machine is different for all three. When the state machine rst starts, it moves to state A, at which point the variable x = 0. All three formalisms agree on this point. Where they disagree is on what happens when event e occurs. In the Classical formalism, the state machine moves to state D. In the UML formalism, the state machine moves to state B. Finally, in the Rhapsody formalism, the state machine moves to state C.

416

M. L. Crane, J. Dingel

[x<1] x:=0
A

[x<1] x:=0
A C

e/x:=1 e

[x>=1]

e/x:=1 e

[x>=1]

(a)

(b)

Fig. 1 Ignoring notation differences, this model is well-formed in all three formalisms, but is interpreted differently in all three. The classical state machine moves to D because the priority of conicting transitions is handled differently (see Sect. 4.3). In UML, the junction is a static choice, i.e., the guards are evaluated with the information available at the beginning of the entire transition. Here, x = 0, so the state machine moves to B. In Rhapsody, the conditional 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 evaluated at the beginning of each microstep. x = 1 when the conditional is reached and the state machine moves to C. State machine inspired by [11]. a Junction (small lled circle) used for static choice. Model is well-formed in Classical and UML formalisms. b Conditional (circled C) used for static choice. Model is well-formed in Classical and Rhapsody formalisms

The fact that there can be three distinct interpretations of one state machine indicates that there is a lack of consistency between the three formalisms. It also indicates that the task of translating, or porting, a model from one formalism to another may not be straightforward. Therefore, it is worthwhile to study the syntactic and semantic differences between the most popular formalisms. In this paper, we present a detailed comparison of these three formalisms, including several illustrative examples. Our results are of interest to modellers, customers, and tool developers because they summarize the differences between the three most popular formalisms and thus help to avoid the pitfalls of incorrectly interpreted models. On the one hand, modelling and transformation tools must correctly implement the syntax and semantics of a formalism (or more than one, if the tool is expected to import/export models). On the other hand, the modellers and customers who make use of models to communicate must also be conversant in these details in order to communicate effectively. This paper is organized as follows: Sect. 2 briey describes state machines and the three formalisms. Section 3 discusses the kinds of problems that can be caused by inconsistencies between the formalisms, as well as the concepts of behavioural equivalence and simple translation. Section 4 contains a detailed comparison of syntactic constructs and semantic concepts that differ between the three formalisms, including a discussion of the feasibility of translating between formalisms. Sections 5 and 6 provide tabular summaries of the detailed information presented in Sect. 4. Section 7 discusses related work. Finally, Sect. 8 contains the conclusion and contributions of this work, while Sect. 9 discusses future work.

2 State machines, statecharts and state machine diagrams A nite state machine (FSM) is a model of computation that species the sequence of states an object goes 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, an input alphabet of events and a transition function mapping current states and event symbols to next states [15]. The term nite state machine refers to the model of computation but not the diagram representing it; instead, the traditional name for a diagram representing a FSM is state diagram or state transition diagram. FSMs are very useful for representing reactive systems, more so than linear or textual representations, which are typically more suitable for representing transformational systems [16]. Ostensibly, an FSM produces output only when it reaches a nal state; however, there are many variations, such as Mealy and Moore machines. Mealy machines can produce output along any transition [16], while Moore machines can produce output at any state [8]. The FSMs that we refer to in this context are Mealy-Moore machines, a combination of these two variants. Figure 2 shows part of a simple nite state machine with three states and ve transitions. If the state machine were in state A, an event b would cause it to move to state B, while an event c would cause it to move to state C. Similarly, if the machine were in state B, event a would cause it to move to state A and event d would cause it to move to state C, etc.

UML vs. classical vs. rhapsody statecharts

D

417

b b

B
c b B

d
C

Fig. 2 Example nite state machine from [8] Fig. 3 Example classical Harel statechart showing use of hierarchy, from [8]. This statechart is behaviourally equivalent to the nite state machine shown in Fig. 2

In the late 1980s Harel dened a visual formalism for describing states and transitions in a modular fashion, enabling clustering, orthogonality, and renement, and encouraging zoom capabilities...between levels of abstraction [8]. These new statecharts were essentially state transition diagrams with the addition of hierarchy (also known as depth), orthogonality (also known as concurrency) and broadcast communications [8, 21]. Other publications by Harel and other authors quickly followed, dening a preliminary semantics for the statecharts formalism [13, 29]. Far from being a nal product, the statecharts formalism evolved over the years, spawning many variants. In fact, as of 1994, there were at least 20 variants of these statecharts [34]. In 1996, Harel revisited the formalism, modifying some of the previous semantics [9, 12]. These statecharts are often referred to in the research literature as simply statecharts, Harel statecharts, or classical statecharts. Because of the fact that the semantics of statecharts has evolved over the years, and the fact that there are so many variants, it is necessary to dene unambiguously which statecharts we refer to. For the purposes of this paper, the term Classical statecharts will be used to represent Harels original statecharts syntax with the newest semantics, as documented in [9, 12, 14]. Although Harel himself states that there is no ofcial semantics for his statecharts [12], Classical statecharts are actually implemented in I-Logixs Statemate tool [20], to which Harel has contributed. Figure 3 shows a classical statechart fragment from [8]. It demonstrates how the use of hierarchy (implemented with an OR state) can simplify a nite state machine; this statechart is in fact behaviourally equivalent to the nite state machine shown in Fig. 2. The Unied Modeling Language (UML) has become the de facto industry standard for general-purpose modelling; it can be used for specifying, constructing and documenting the artifacts of a system [27, Part I]. The UML is a visual modelling language; different diagram types (sub-languages) can be used to model various

parts of the system under consideration. These diagram types can be sub-divided into structural and behavioural views. In addition, behavioural diagrams can be further sub-divided into inter-object and intra-object behavioural views. UML state machine diagrams1 are one diagram type that can be used to model intra-object behaviour, i.e., how individual model elements behave. A state machine diagram is used to represent a state machine. The syntax and semantics of UML state machines have remained reasonably consistent throughout UMLs history, although there are occasionally minor modications. We concern ourselves with the latest version of the UML 2.0 Superstructure specication [28]. UML state machine diagrams are an object-based variant of Classical statecharts [28, 26, 7]. An alternative object-based variant is one to which Harel himself has contributed: the statechart formalism implemented in ILogixs Rhapsody tool [19]. This formalism was created after the introduction of UML 1.1. Actually, the Rhapsody formalism is more closely related to the UML formalism than to its Classical ancestor. In fact, there was cooperation between the Rhapsody and UML development teams, resulting in cross-pollination between the two formalisms [10, 31]. For instance, [11] states that the UML developers have essentially adopted the underlying semantics of Rhapsody as described in [10] and that Rhapsody itself can be considered a tool that captures the executable kernel of UML. For the purposes of this paper, we concern ourselves with Rhapsody as it is documented in [10, 11]. It should be noted that these three formalisms are not necessarily located at the same level of abstraction.
As of UML 2.0, these diagrams are called state machine diagrams. Previous versions called these diagrams statechart diagrams.
1

418

M. L. Crane, J. Dingel

While UML and Rhapsody are both object-based variants of Classical statecharts, Rhapsody can be viewed as both inspiration and implementation of UML [11] as discussed above. Based on the research literature, it is easy to become confused as to the relationships between these formalisms and the differences between them. It will become evident that Rhapsody is not a faithful implementation of UML. Not only do Rhapsody statecharts fail to implement some features specied by UML, but in some ways, Rhapsody statecharts can be more expressive than those in UML. In addition, both the Classical and UML formalisms are capable of modelling concepts that neither of the other two formalisms can. Although the main source of information for this paper was published academic research, where necessary, we have tested our examples against the Statemate [20] and Rhapsody [19] implementations.

3.1 Effects of differences The syntactic and semantic differences between formalisms can be divided into three categories, based on the type and severity of errors that they can cause when translating statecharts from one formalism to another. Note that a particular syntactic construct or semantic concept can result in differences in more than one category. Notation A construct may be common to all three formalisms and yet be represented with alternative notation. For example, a nal state in UML is represented as a circle surrounding a smaller solid lled circle [28], while the Classical and Rhapsody formalisms make use of a circled T. This category is the least critical; after a simple notation translation, a model would be compatible with the target formalism(s). Well-Formedness Differences in this category are more important; they result in models that are well-formed in one or two formalisms, but not in all three. For instance, a construct may not be available in a particular formalism, or a formalism may enforce additional or different constraints on a common construct. A model could be checked for compatibility with simple syntax or wellformedness checking. Translation and re-working of a model may make it compatible with the target formalism(s); however, not all models can be made fully compatible with all formalisms. Executable behaviour This is the most critical category of differences, and the most insidious. A model may be well-formed in more than one formalism and yet not behave exactly the same. This type of incompatibility would not be found by simple syntax or well-formedness checking. In essence, an incompatible model would compile, but its executable behaviour would be other than expected, sometimes the opposite of the intended behaviour.

3 Differences between formalisms In general, all three formalisms are similar. Basically, statecharts2 are directed graphs, consisting of states and transitions between them. Transitions may have labels of the form event[guard]/action. All three formalisms support both orthogonal (AND) and sequential (OR) composite states. These basic similarities aside, there are several syntactic and semantic differences between the three formalisms. The syntactic differences concern how various syntactic constructs are represented and their well-formedness constraints, while the semantic differences are caused by variations in the semantic interpretation of basic concepts, such as priority of conicting transition, handling of simultaneous events, etc. Our approach to studying the differences between these three formalisms is three-fold. We explore the nature of each difference, with examples. This exploration includes a discussion about the feasibility of simple translation between formalisms. Then, we classify each difference, based on the types of problems that can arise when the differences are not taken into account during translation. Finally, we tabulate the results of the translation discussions, distinguishing between differences that can be easily translated from those than cannot.

3.2 Behavioural equivalence In general, state machines are composed of states (simple,3 orthogonal composite, sequential composite), pseudostates (initial, nal, fork, join, junction, choice) and transitions. A state machine is in a stable state conguration when there are no enabled transitions to be
3

In the interests of simplicity, we refer to the diagrams of all three formalisms as statecharts and use the term state machine when referring to the model of computation.

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

UML vs. classical vs. rhapsody statecharts

419

followed. A compound transition is a sequence of transition segments, connected by pseudostates, between a source state and a target state. Movement through a state machine occurs as follows: the state machine is in a stable state conguration; one or more events occur, resulting in zero or more compound transitions becoming enabled; one or more compound transitions are followed, leaving the state machine in a stable state conguration. A state machine never stops on the edge of a composite state, on a pseudostate, or in the middle of a transition segment. The study of behavioural equivalence of FSMs, state transition systems, etc. is a mature eld. This results in different denitions of behavioural equivalence, depending on the application. For our purposes, we make use of the notion of bisimulation [1] to dene behavioural equivalence. Essentially, two state machines are bisimilar (behaviourally equivalent) if each can simulate the behaviour of the other. Two state machines SM1 and SM2 (with the same input alphabet I) are behaviourally equivalent if there is a binary relation relating simple states of SM1 to simple states of SM2 , such that (s1 , s2 ) implies that: 1) if there is a compound transition t1 between states s1 and s1 in SM1 , then there is a compound transition t2 between states s2 and s2 in SM2 and (s1 , s2 ) and 2) if there is a compound transition t2 between states s2 and s2 in SM2 , then there is a compound transition t1 between states s1 and s1 in SM1 and (s1 , s2 ) . In the standard denition of bisimulation, t1 = t2 ; however, in our case, we do not require that the two compound transitions be identical, just that their results are. For instance, if t1 is a single transition, we permit t2 to be two transition segments, connected by a pseudostate, as long as the inputs to the two compound transitions are identical, the guards are equivalent, and the resulting actions/outputs are the same and are executed in the same order. We employ this notion of equivalence because it is simple and intuitive. By using bisimulation to dene behavioural equivalence, we demand that the simple states of the source state machine be matched with simple states of the target state machine and vice versa. A key consequence of this pairing is that equivalent state machines will move between matched stable state congurations in the same number of steps.

statechart in one formalism in order to produce a behaviourally equivalent statechart in another formalism. We call a manipulation shallow when it does not require a deep understanding of the statechart. For example, it is possible to require some shallow knowledge of the underlying model, e.g., a list of all possible events. However, it is not permitted to require a modellers understanding of the model, e.g., the purpose of the model, or the desired outcome in the case of nondeterministic choice, etc. We employ this notion of translation because it is easy to automate. All of the simple translations suggested involve either the addition or deletion of transition segments or pseudostates or the addition of sequential composite states for grouping. We have dened fairly strict criteria for our simple translations. Loosening some of these criteria by, for instance, relaxing the denition of behavioural equivalence or dropping the shallowness requirement, would allow additional translations. For example, for some of the differences listed in the paper, a translation could be dened that requires a thorough understanding of the entire statechart. However, we will not consider these more complex and powerful translations in this paper, because they are much harder to automate. The purpose of the paper is to provide an informal, comparative study of the differences between state machine formalisms, as well as a rst, preliminary, informal discussion of how some of these differences can be overcome by automatic means. The above denitions sufce for this purpose. A more comprehensive study of additional automatic and user-assisted translations is outside the scope of this paper and must be left for future work. However, in a few cases, we will also discuss the possibility of non-simple translations, namely: translations that might be possible if a different notion of behavioural equivalence were used translations that might be possible if we were to permit additional manipulations translations that might be possible if a deep understanding of the underlying model were available.

4 Detailed comparison We now examine several syntactic constructs and semantic concepts in detail. We start with the semantic concepts because, in general, they affect multiple constructs and the overall understanding of the models. Several of the more interesting syntactic constructs are then examined.

3.3 Simple translations We will now use behavioural equivalence to introduce the notion of simple translations. We informally dene a simple translation as a shallow manipulation of a

420

M. L. Crane, J. Dingel

The results of this examination are summarized in Table 1 in Sect. 5. In addition, while discussing each syntactic construct and semantic concept, we examine specic cases of statecharts that are not well-formed or do not behave identically in all three formalisms. Where possible, we demonstrate by example how to translate these cases. The results of this research are summarized in Sect. 6. 4.1 Synchrony hypothesis 4.1.1 Synchrony and zero time The (perfect) synchrony hypothesis [2] states that a system must react immediately to external events and that the corresponding output must occur at the same time [34]. The zero-time assumption follows from the synchrony hypothesis and implies that transitions take zero time to execute [26]. In general, Classical statecharts support both the synchrony hypothesis and the zero-time assumption [34, 26].4 In UML, a transition may take time [26], although no assumptions are actually made, allowing for models with either zero- or xed-execution time [28, Sect. 13.3.30]. The Rhapsody formalism mirrors that of UML in that a step does not necessarily take zero time [11]. Therefore, with respect to the zero-time assumption, it is theoretically possible that both the UML and Rhapsody formalisms adhere to the synchrony hypothesis. 4.1.2 Synchrony and simultaneous events By the synchrony hypothesis, Classical statecharts must be able to react immediately to external events. They can do so, supported by the fact that different events may occur simultaneously, and be acted upon simultaneously, in Classical statecharts [24]. However, neither the UML nor Rhapsody formalisms support the synchrony hypothesis in this regard. Instead, both formalisms adhere to the concept of run-to-completion (RTC), which means that each event is handled completely before the next event is processed.5 It is thus impossible in a UML or Rhapsody statechart for different events to be handled simultaneously.6
4

A e1 B

e2 D

Fig. 4 Statechart with potentially simultaneous events

For example, consider the statechart in Fig. 4. Assume that the state machine is currently in states A and C and that events e1 and e2 occur simultaneously. If this were a Classical statechart, then both events would be handled simultaneously (since they do not conict) and the machine would move to states B and D in one step. However, in the other two formalisms, only one event can be handled at a time. Therefore, the state machine would 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 is the only one that permits the handling of simultaneous events, i.e., two or more events being handled at the same time. There does not appear to be a simple way to translate a statechart handling simultaneous events into one that does not. It may be possible to translate a Classical statechart with simultaneous events into, for instance, a UML statechart that mimics the behaviour of the Classical statechart in a satisfactory way. However, such a translation would require a deeper understanding of possibly the entire model and a bigger manipulation than allowed by simple translations. For example, it may be possible to mimic the results of simultaneous events by making use of an additional orthogonal region where the occurrence of two consecutive events triggers the issue of a new (composite) event. 4.2 Conjunction, disjunction and negation of events All three formalisms offer different levels of exibility in terms of the combination of event triggers on transitions. Classical statecharts offer the most exibility, allowing the conjunction, disjunction and negation of events. UML is less exible, offering only the disjunction of events as triggers. Rhapsody is the least exible

Note that Classical statecharts semantics, as implemented in Statemate, supports two time models: asynchronous and synchronous. Only the asynchronous time model supports zero-time transitions [12]. In UML, event occurrences are detected, dispatched, and then processed...one at a time [28, Sect. 15.3.12]. In Rhapsody, events are handled one by one, in order [10]. It is however, possible for the same event to be handled simultaneously in different regions of an orthogonal composite state.

UML vs. classical vs. rhapsody statecharts

e OR f
A B

421
a OR b OR c OR d OR f
A B

Fig. 5 Statechart with disjunction of events. This statechart is well-formed in Classical and UML, but not in Rhapsody
e
A B

Fig. 8 Translation of statechart in Fig. 7, removing the negation but assuming that disjunction is permitted. This statechart is wellformed in Classical and UML, but not in Rhapsody. To make this statechart well-formed in Rhapsody, simply remove the disjunction as discussed in Case 2 above. Note that the state machine will not move to state B if no event occurs
a OR b OR c OR d OR f
A B

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

of all three formalisms, allowing only single events as triggers. 4.2.1 Translation between formalisms In terms of translation between the formalisms, there are some techniques that could be used to translate from a more exible formalism to a less exible one. Case 2: Disjunction of events A transition triggered by the disjunction of n events can be replaced by n transitions, each with one event trigger. A simple translation can be used to accomplish this. For example, the statechart in Fig. 5 contains a transition triggered by the disjunction of two events. The statechart in Fig. 6 removes the disjunction by replacing the transition with two transitions, each triggered by exactly one event. Case 3: Conjunction of events The Classical formalism is the only one that permits transitions triggered by the conjunction of events. There does not seem to be a simple way to translate a statechart using the conjunction of events into one that does not. It may be possible to translate a Classical statechart using the conjunction of events into, for instance, a UML statechart that mimics the behaviour satisfactorily. However, such a translation would require a deeper understanding of possibly the entire model and a bigger manipulation than allowed by simple translations. For example, it may be possible to mimic the conjunction of events by making use of an additional orthogonal region where the occurrence of two consecutive events triggers the issue of a new (composite) event.
NOT e
A B

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

Case 4: Negation of events If the universe of events is known, then a simple translation can be used to remove the negation of events on a transition. In this case, the translation would consist of simply replacing the transition with a negated event trigger with transitions triggered by every other event. For example, consider the statechart in Fig. 7 and assume that the universe of possible events is {a, b, c, d, e, f }. Then, the statechart in Fig. 8 represents the same behaviour. Note that, in the case of the Classical statecharts implemented by the Statemate tool, a transition triggered by the negation of an event is also triggered by a nil, or empty, event. In other words, the statechart in Fig. 7 will move from state A to B when any event other than e occurs, or if no event occurs. In this case, the translated statechart also requires an additional transition, one triggered by no event, as shown in Fig. 9. Note that Fig. 9 assumes that disjunction is possible. 4.3 Priorities of conicting transitions It is possible in all three formalisms to have conicting transitions, i.e., a set of enabled transitions that cannot all be red due to conict in their results. For example, consider the state machine in Fig. 10. Assume that the machine is currently in state B and that event e is generated. The two transitions enabled by this event are considered to be in conict because their effects conict. For instance, if the transition into state D is taken, the state machine moves to state D, and the transition into state C cannot be taken. One of the most serious differences between the UML/Rhapsody and Classical formalisms is the han-

Fig. 7 Statechart with a transition triggered by the negation of an event. This statechart is well-formed in Classical but not in UML or Rhapsody

422
TOP

M. L. Crane, J. Dingel

e/x:=x+1; y:=x*5

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

B e C
e

Fig. 10 Statechart with conicting transitions

dling of conicting transitions. In Classical statecharts, the scope of a transition is the lowest OR-state neither exited nor entered by that transition [12, 24]. Priority is given to the transition with the highest scope. In the case of the statechart in Fig. 10, the scope of the transition from B to C is state A, while the scope of the transition from A is D is the state TOP. Since priority is given to the transition with the highest scope, the latter event is handled; therefore, the state machine moves to state D. In UML, a transition originating from a substate has higher priority than a conicting transition originating from any of its containing states [28, Sect. 15.3.12]. In Rhapsody, lower level states also get priority [10]. In this case, the transition from B to C originates from state B, which is a substate of state A, the origin of the transition from A to D. Since priority is given to the substates, the former event is handled; therefore, the state machine moves to state C in both UML and Rhapsody. The rationale behind the different priority schemes is not particularly well-documented, although it has been suggested that the lowest-rst priority scheme espoused by both UML and Rhapsody is more object-oriented. In other words, this priority scheme allows substates to override superstates in a way that is similar to how subclass operations/methods can override those of the superclass [11]. 4.3.1 Translation between formalisms Case 5: Top-down priority and Case 6: Bottom-up priority The Classical formalism employs a top-down priority scheme, while the other two formalisms employ a bottom-up priority scheme. Thus, the priority scheme requires no translation between UML and Rhapsody. However, there does not seem to be a simple way to translate a statechart from one priority scheme to an other. It may be possible to translate from a statechart from the Classical priority scheme to the UML/

Rhapsody priority scheme, or vice versa. For instance, there may be a way to make use of guards to force certain transitions to be taken in order to conform to a particular priority scheme. In UML/Rhapsody, to force a 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 that these transitions should only be enabled if there are no inner transitions (e.g., the transition from state B to state C) that are enabled. In Classical, to force a UML/ Rhapsody priority, for every event, guards would have to be placed on inner transitions stating that these transitions should only be enabled if there are no outer transitions that are enabled. Keeping in mind that any pre-existing guards have to be taken into account, and that the entire nesting hierarchy of a statechart needs to be considered, these possible translations would not be simple. 4.4 Order of execution of actions In all three formalisms, is it possible to list multiple actions on a transition between two states, as shown in Fig. 11. Assume that the state machine is in state A, x = 0, and event e occurs. In Classical statecharts, actions on a transition are executed in parallel, rather than in sequence [12]. Therefore, at state B, x = 1 and y = 0, because both actions were executed in parallel.7 In UML however, the behaviour expression may be an action sequence comprising a number of distinct actions and behaviors are executed in sequence following their linear order [28, Sect. 15.3.14]. Similarly, in Rhapsody, actions are guaranteed to be performed in sequential order [11]. For both UML8 and Rhapsody therefore, at state B, x = 1 and y = 5. 4.4.1 Translation Between Formalisms Case 7: Parallel execution and Case 8: Sequential execution Here, again, we have a fundamental semantic difference between the three notations. Classical state7

This means that the value of x used in executing x := x + 1 and y := x 5 is the value that x had at the beginning of the transition [12].

Typically, the semi-colon ; implies sequential composition. This example assumes an underlying action language for the model that is consistent with this interpretation.

UML vs. classical vs. rhapsody statecharts

423

charts permit the parallel execution of actions, while by default, UML and Rhapsody do not. In general, parallel execution cannot be easily translated to sequential execution. With a deep understanding of the underlying model, it may be possible to create translations, e.g., if the variables referenced in two statements are independent, then whether or not these statements are executed sequentially, or in parallel, may be irrelevant. 4.5 Fork and join Fork and join constructs are common to all three formalisms, although the notation is slightly different in Classical/Rhapsody than in UML. Published work on the Classical and Rhapsody formalisms show forks and joins as simply arrows with either multiple sources or multiple targets. The UML specication, as well as the Rhapsody 6.0 tool itself, show separate fork and join constructs, which break the transitions into incoming and outgoing transitions. In addition to the notational differences between the formalisms, there are several well-formedness differences. For example, actions (or any labelling) are not permitted on the outgoing transitions of a fork in Rhapsody. Thus, the UML statechart in Fig. 12 would be illformed in Rhapsody, even with the alternate notation taken into account. As another example, the Classical statechart in Fig. 13 would be ill-formed in both UML and Rhapsody. In the rst place, Rhapsody does not allow the labelling of transitions leaving a fork. UML does allow the placement of actions on these transitions, but not event triggers. However, there is a much more fundamental semantic difference between the Classical and the other two formalisms. In the Classical formalism, the fork transi-

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

/a1

/a2

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

/a1 e /a2

Fig. 12 This UML fork would be ill-formed in Rhapsody but well-formed in Classical
e1/a1 e

tion would only be taken if all three events e, e1 and e2 were to occur simultaneously, which is possible since the Classical formalism allows for simultaneous events. On the other hand, both UML and Rhapsody adhere to the RTC assumption; therefore, only one event can be handled at a time. The Classical statechart in Fig. 14 would be ill-formed in UML because UML does not allow for event triggers after the join pseudostate. In addition, the obvious solution of simply moving the event trigger to the incoming transitions would not work; UML does not allow for event triggers incoming to join pseudostates. In fact, joins are not explicitly triggered in UML; they are only used with completion events [31], i.e., leaving the last state in each region of an orthogonal state. Finally, the UML statechart in Fig. 15 would be ill-formed in Rhapsody, since Rhapsody does not allow for any labels on transitions coming into a join. In addition, Rhapsody cannot support joins from more than two orthogonal regions. This is a low-level implementation limitation based on requirements imposed by the Motor Industry Software Association (MISRA) [18, p. 430]. Because this is a low-level tool limitation, we will not be considering it further, but mention it for the sake of completeness. 4.5.1 Translation between formalisms Case 9: Actions after fork In UML, it is possible to have actions on transitions leaving a fork pseudostate, as seen in Fig. 12. This case is also permitted in Classical statecharts, albeit with a slight notation difference. The actual pseudostate is simply replaced by joined transitions, as in Fig. 16.

e2/a2

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

424

M. L. Crane, J. Dingel

/a1 e
e/a1;a2

/a2

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

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

The purpose of the fork is to pass ow of control to multiple regions of an orthogonal state, i.e., to start concurrency. In that case, it can be argued that because both actions a1 and a2 in Fig. 12 will be executed, they could be moved to the transition segment before the fork, as shown in Fig. 17. In this case, the actions will not be performed in parallel, but sequentially, as discussed in Sect. 4.4. However, this translation does not conform to our interpretation of behavioural equivalence because the actions along the transition are not executed in the same order. Case 10: Events after fork As discussed in Sect. 4.1.3, there does not appear to be a simple way to translate a statechart handling simultaneous events into one that does not. Therefore, the Classical statechart in Fig. 13 cannot be simply translated to either UML or Rhapsody. It may be possible to translate a Classical statechart making use of events after a fork into, for instance, a UML statechart that mimics this behaviour satisfactorily. However, such a translation would require a deeper understanding of possibly the entire model, or a different interpretation of behavioural equivalence. In any case, such a translation would require a bigger manipulation than that allowed by simple translations. Case 11: Event after join As seen in Fig. 14, it is possible in Classical and Rhapsody for a transition leaving a join to be labelled with an event. In other words, this transition would be taken if and when that event occurred. However, this case is not possible in UML as transitions leaving pseudostates may not be labelled with events. As discussed above, the only way to trigger a join transition is with a completion event. Therefore, there does not seem to be a simple way to translate this case to the UML formalism. On the other hand, a translation might be possible if we were to relax our denition of behavioural equivalence. Specically, if we allowed the creation of simple states in the target statechart, we could dene a translation that produces the statechart in Fig. 18. Case 12: Actions before join The UML statechart in Fig. 15 can be translated to Classical by replacing the join pseudostate with joined transitions, as shown in Fig. 19.

Fig. 18 Possible UML statechart translation of Classical/Rhapsody statechart in Fig. 14. Note that this translation requires a notion of behavioural equivalence that allows the introduction of simple 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 to Rhapsody. Because the actions will be performed sequentially, not concurrently, this translation does not conform to our denition of behavioural equivalence

The purpose of the join is to pass ow of control from multiple regions of an orthogonal state to a single state, i.e., to end concurrency. In that case, it can be argued that because both actions a1 and a2 in Fig. 15 will be executed, they could be moved to the transition segment after the join, as shown in Fig. 20. In this case, the actions will not be performed in parallel, but sequentially, as discussed in Sect. 4.4. However, as discussed in Case 9, this translation does not preserve behavioural equivalence. 4.6 History The Classical and UML formalisms both support deep and shallow history, while the Rhapsody formalism only supports deep history.

UML vs. classical vs. rhapsody statecharts Fig. 21 UML statechart with deep history Fig. 23 UML statechart with shallow history

425

H*

Fig. 22 Statemate and Rhapsody translation of UML statechart in Fig. 21

H*

Fig. 24 Statemate translation of UML statechart in Fig. 23

4.6.1 Translation Between Formalisms Case 13: Deep history All three formalisms support deep history; however, both Rhapsody and the Statemate interpretation of Classical statecharts require a slight modication of notation. For example, consider the UML statechart in Fig. 21. No initial pseudostate/transition is required; the history pseudostate points to the default state to be entered when the composite state is rst entered. However, this statechart causes compilation errors in the Statemate and Rhapsody tools, even though, theoretically, there is nothing wrong with the notation. Therefore, when translating a UML statechart to either of these two formalisms, it is necessary to add an initial pseudostate, as shown in Fig. 22. Case 14: Shallow history Although both Classical and UML both support shallow history, there is a slight notation difference between UML and the Statemate interpretation of Classical statecharts. As discussed above, the Statemate tool requires the use of an initial pseudostate; therefore, the UML statechart in Fig. 23 would be translated to the Statemate statechart in Fig. 24. On the other hand, Rhapsody does not support shallow history; this is counterintuitive, since shallow history is essentially a subset of deep history. The difference between shallow and deep history is as follows: With shallow history, the top-level composite state entered remembers the last simple state it was in; but none of the contained composite states remember. With deep history, this memory extends all the way down to the lowest composite state entered. While in some cases it may be possible to translate a UML or Classical statechart with shallow history into a Rhapsody statechart that mimics the behaviour of the original in a satisfactory way, we cannot suggest a general way of performing such a translation. 4.7 Junction Junction constructs are common to all three formalisms, although there are some well-formedness differences. For example, the Classical statechart in Fig. 25 is ill-formed in UML because no events are permitted after pseudostates. In addition, the Classical statechart in Fig. 26 is ill-formed in both UML and Rhapsody. UML does not allow for event triggers on transitions outgoing from a pseudostate, while Rhapsody does not allow for more than one outgoing transition from a junction. 4.7.1 Translation between formalisms Case 15: Event after junction The statechart in Fig. 25 can be translated to UML, using a simple translation, by moving the event trigger to the transition segments

426

M. L. Crane, J. Dingel

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

e1 e2

Fig. 30 Rhapsody translation of statechart in Fig. 29

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

[g1] C [g2]

Fig. 31 Conditional construct supported by Classical and Rhapsody formalisms

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

e1

lation, by removing the junction altogether and replacing it with two transitions. Figure 28 shows the resulting UML statechart. For Rhapsody, since only one outgoing transition is permitted for a junction (i.e., a junction is only a merge), the statechart in Fig. 28 would also be the translation. Case 17: Junction as merge/split Because Rhapsody does not allow for more than one transition leaving a junction, the Classical and UML statechart in Fig. 29 is not well-formed in that formalism. To translate this statechart, using a simple translation, we remove the junction altogether and replace it with multiple transitions, as shown in Fig. 30. 4.8 Conditional Classical and Rhapsody statecharts support a specic conditional construct, as shown in Fig. 31. This construct simply represents a static choice, i.e., the guards on the outgoing transitions are evaluated before the transition is taken. 4.8.1 Translation between formalisms Case 18: Conditional construct The conditional construct no longer exists in UML,9 but its semantics can be mimicked with the standard junction pseudostate, as shown in Fig. 32.

e2

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

coming into the junction, as shown in Fig. 27. The Classical statechart is already compatible in Rhapsody technically, but when drawing such a statechart, the Rhapsody tool actually moves the event to the transition segments coming into the junction. Case 16: Multiple events after junction The statechart in Fig. 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

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

UML vs. classical vs. rhapsody statecharts

427

[g1] C [g2]

x:=0 [x<1]
A B

e/x:=1
C

[x>=1]

Fig. 32 UML supports the same static choice by using the junction pseudostate

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

x:=0 [x<1]
A B

e/x:=1 [x>=1]
C

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

4.9 Choice UML does allow for a dynamic choice pseudostate, which is not equivalent to the Classical/Rhapsody conditional construct. Consider the UML statechart in Fig. 33. When the state machine starts, it moves to state A and x = 0. When event e occurs, the action on the transition is executed before the guards on the outgoing transitions are evaluated. The state machine will thus move to state C. 4.9.1 Translation between formalisms Case 19: Choice construct Although neither the Classical nor Rhapsody formalisms support a dynamic choice construct, it is possible to simulate it in Rhapsody and to dene an appropriate simple translation. Consider the Rhapsody statechart in Fig. 34. In this case, the fact that Rhapsody makes use of microsteps [11] comes into play. The default, or initial, transition is considered a microstep. Attributes are assigned their values at the beginning of each microstep, so the assignment x := 1 is executed as the state machine enters the composite state. Once the conditional is reached, x = 1, so the state

machine would move to state C. On the other hand, in the Statemate implementation of Classical statecharts, the state machine in Fig. 34 would move to state B. Therefore, there is no way to simulate dynamic choice in Classical statecharts. It is very important to note that even if the conditional in Fig. 34 were replaced by UMLs static choice construct (junction), as in Fig. 35, the state machine would not behave identically in UML. UML does not make use of microsteps, and the action along the transition will not be considered when the guards are evaluated [31]. If the state 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, but these transition compositions are constrained for practical purposes in UML state machines [26] and Rhapsody statecharts. Therefore, there are some Classical statecharts that cannot be simply translated to UML. Consider, for example, the statecharts below. These two equivalent statecharts are well-formed in the Classical formalism but neither of them is well-formed in UML or Rhapsody. Figure 36a shows a compound transition between two states. Both transitions are labelled with an event trigger and an action. In the Classical formalism, the transition coming into the junction cannot be executed without also executing the transition coming out of the junction [12]. Therefore, this compound transition is equivalent to the single transition in Fig. 36b, which is labelled with the conjunction of two events, and a pair of resultant actions. 4.10.1 Translation between formalisms Case 20: Compound transition with event/action on each segment Neither of the equivalent statecharts in Fig. 36 would be well-formed in UML or Rhapsody. On the one hand, the statechart in Fig. 36b is ill-formed because neither UML nor Rhapsody allows for the conjunction

x:=0 [x<1]
A B

e/x:=1
C

[x>=1]

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

428
e1/a1 e2/a2 e1 and e2/a1;a2

M. L. Crane, J. Dingel

(a)

(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 is also ill-formed because UML does not allow for triggers on transitions leaving a pseudostate [28, Sect.15.3.14] and Rhapsody does not allow for any label on the transition leaving the junction. Therefore, there does not appear to be a general simple translation from these Classical statecharts to equivalent UML or Rhapsody versions.

statechart in Fig. 14 cannot be simply translated into an equivalent UML statechart. Finally, differences in execution behaviour are the most serious of all. This is not because they imply a model cannot be translated to another formalism, but because a model designed with constructs/concepts from this category can be well-formed in more than one formalism and yet behave differently in each. The statecharts in Fig. 1 are prime examples of this particular pitfall. Obviously, problems caused by well-formedness differences can also cause problems in execution behaviour. For example, a UML statechart with deferred events10 would be ill-formed in the other two formalisms. However, if the deferred events were simply removed, the state machine would not behave as expected. In this case, the execution behaviour problem would not be indicated in Table 1, since the well-formedness problem itself alerts modellers of the mismatch and thus encourages them to ensure that a ported model is well-formed and behaves as expected. Instead, the behavioural problems indicated in Table 1 are in addition to any notational or well-formedness problems for that construct/concept, and not caused by them. Not only does this table present a comprehensive summary of the differences between the three formalisms, but it also brings to light several facts, such as: Rhapsody is much syntactically and semantically closer to UML than to its Classical ancestor, especially with respect to behavioural semantics. This means that models can be more easily translated between UML and Rhapsody than between either of these formalisms and Classical statecharts. UML is the only formalism that allows for dynamic choice. Many of the well-formedness and execution behaviour differences are indirectly caused by the fact that

5 Comparison summary Table 1 summarizes the ndings of the previous section with respect to the constructs and concepts available in each formalism, as well as the nature of problems that differences between formalisms can cause. The left-hand columns of the table summarize the syntactic and semantic differences between UML 2.0, Classical statecharts and Rhapsody statecharts. UML 2.0 is used as the baseline, with Classical and Rhapsody both being compared to it. The left-most column lists most of the features of UML 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 potential problem categories each construct and concept fall: The notation category indicates differences which can be easily managed, i.e., a model in one formalism can be easily translated to the other formalisms with a simple notation translation, e.g., replacing a conditional pseudostate in Classical/Rhapsody with a junction pseudostate in UML. Differences in the well-formedness category are more serious. Sometimes it is possible to dene a simple translation (as dened in Sect. 3.3), e.g., the UML statechart in Fig. 32 represents the Classical/ Rhapsody statechart in Fig. 31. Unfortunately, not all models can be made compatible, e.g., the Classical

10

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

UML vs. classical vs. rhapsody statecharts

429

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

UML and Rhapsody do not support simultaneous events or actions, e.g., with respect to do-activities, forks, joins, junctions, and event triggers. Although the priority scheme between the Classical and UML/Rhapsody formalisms is inverted, it does

not cause any notation or well-formedness problems with the syntactic constructs. In other words, the fact that a model would behave differently due to the opposite priority schemes would not be found by a syntax or well-formedness checker.

430

M. L. Crane, J. Dingel
Classical

6 Translation between formalisms In Sect. 5, we summarized how well each of our three formalisms supports several syntactic constructs and semantic concepts, as well as what types of problems could arise when translating statecharts. While discussing these constructs and concepts in detail in Sect. 4, we demonstrated how certain cases could be simply translated from one formalism to another. Tables 2 and 3 summarize the results of this research. Table 2 provides a summary of the cases explored in Sect. 4, indicating which specic cases are supported by each formalism. For each in the table, indicating that a case is not supported by a particular formalism, we have examined the feasibility of a simple translation for that case. The nal results are presented in Table 3. Where possible, the detailed case discussion in Sect. 4 provides the rules of translation by example, or informal discussion about the infeasibility of such a translation. 6.1 Relative expressiveness of the formalisms In general, it can be said that the Classical formalism is the most expressive, as it offers the most exibility, e.g., simultaneous events; simultaneous actions; conjunction, disjunction and negation of events; shallow and deep history. Similarly, Rhapsody can be considered the least expressive formalism: only single events as triggers, no shallow history, no simultaneous events or actions. These claims are supported by Table 2. Keeping in mind that cases 5/6 and 7/8 are mutually exclusive, i.e., a formalism supports either one or the other, the Classical formalism supports most of the cases detailed in Sect. 4. Similarly, Rhapsody supports the least. Consider the Venn diagram in Fig. 37. It shows how each of the cases from Table 3 relates to the three formalisms. The white sections of the diagram, i.e., those portions of the Venn diagram with no overlap, indicate cases that are supported by exactly one formalism. For instance, Cases 1, 3, 4, 5, 7, 10, 16, 20, are supported only by the Classical formalism. The lightly-shaded sections of the diagram (overlap between two circles) show those cases supported by two formalisms. For example, Cases 6 and 8 are supported by both UML and Rhapsody. Finally, the heavily-shaded section (overlap between all three circles) show exactly one case, 13, which is the only case that is supported by all three formalisms. In addition, the diagram indicates whether or not translation of particular cases between formalisms is possible. An arrow pointing to the right indicates that the specic case can be translated to Rhapsody. Similarly, an arrow pointing down indicates that the specic case can be translated to UML. Notice that there are
1

4 7 16 10 14 13 8 2 20 9 6 17 12 5 RHAPSODY 18 11 21 15

19

UML

Fig. 37 Venn diagram showing which cases are supported by each formalism, as well as which cases can be translated. White sections indicate cases that are supported by exactly one formalism. Lightly-shaded sections indicate cases that are supported by two formalisms. The heavily-shaded section indicates one case that is supported by all three formalisms. Arrows pointing to the right indicate that translation to Rhapsody is possible. Arrows pointing down indicate that translation to UML is possible. There are no arrows pointing up, indicating that there are no cases that can be translated to Classical

no arrows pointing up, i.e., there are no cases supported only by UML and/or Rhapsody that can be translated to Classical. It should be noted that there is not a strict ordering among the formalisms in terms of expressiveness. Classical supports the most cases (18), followed by UML (9), followed by Rhapsody (7). However, there are several cases supported by Rhapsody that are not supported by UML, i.e., Cases 11, 15, 18, 21 are supported by both Classical and Rhapsody, but not by UML. In addition, two of these cases, 11 and 21, have no simple translation to the UML formalism. 6.2 Complexity of translations As implied by the symbols used in Table 3, we distinguish between two types of simple translation. Trivial simple translations Those mappings marked with indicate that both the source and target formalism support the specic case under consideration, albeit it with a minor notation change. For example, converting the joined lines in Classical to a join or fork pseudostate in UML (Cases 9 and

UML vs. classical vs. rhapsody statecharts

431

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

12). Another example would be necessity of adding an initial pseudostate to Classical and Rhapsody when using a history pseudostate (Case 13). These are very simple mappings and can most denitely be automated. Simple translations Those mappings marked with indicate that the specic case in question can be simply translated from the source to the target formalism, where a simple translation conforms to our denition in Sect. 3.3. These translations are slightly more complicated than simply swapping out one notation for another, but do not involve any more manipulations than the addition/deletion of transition segments, addition/deletion of pseudostates, or addition of sequential composite states for grouping. It should be quite possible to automate these types of translation.

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

these translations are straightforward since they only deal with pure syntax or well-formedness constraints. On the other hand, the semantic concepts are much harder to translate. Take, for instance, the fact that the priority scheme in Classical vs. UML/Rhapsody is reversed makes it extremely difcult, if not impossible, to dene a rule that could be used to automatically translate a statechart from one formalism to another. As another example, consider the fact that Classical statecharts permit the handling of events simultaneously, as well as the triggering of events by the conjunction of events. There does not appear to be a simple way to translate statecharts using these concepts while maintaining our denition of behavioural equivalence, requirement for no deep understanding of the underlying model, and restrictions on permitted manipulations. In other words, translating these types of statecharts could require a complete redrawing of the statechart in the target formalism. 7 Related work The UML 2 Semantics Project [32] is an international collaboration including IBM (Canada, Germany, Israel), Queens University (Canada), the Technical University

432 Table 3 For each specic case identied in Table 2, this table indicates whether or not simple translation between formalisms is possible. A simple translation is dened as a shallow manipulation of a statechart in the source formalism in order to produce a behaviourally equivalent statechart in the target formalism. Other

M. L. Crane, J. Dingel translations may be possible, but they would require a different notion of behavioural equivalence, a deep understanding of possibly the entire underlying model, and/or a relaxing of the manipulations permitted during translation. Abbreviations of formalisms: C for Classical, U for UML, and R for Rhapsody

of Munich (Germany), and the Technical University of Braunschweig (Germany). The purpose of this project is to dene a formal semantics of UML 2.0. Under the auspices of this project, we have initiated an effort to survey, categorize and compare semantic approaches for formalizing state machine behaviour [4]. In order to critique these approaches, we needed a detailed understanding of the syntax and intended semantics of state machines. During our literature review, it became apparent that Classical, UML and Rhapsody statecharts could not be considered equivalent, even though at rst glance, they appear almost identical.

Unfortunately, although there is much research relating to these formalisms, there is no denitive comparison between them. The most detailed comparison is a bulleted list in an older UML specication [26, Sect. 2.12.5.4], which is not even included in the new UML 2.0 specication. Other sources offer one- or two-line highlevel comparisons between Classical and UML statecharts, without going into great detail. The bulk of the research presented in this paper is thus a result of detailed inspection of the UML specication [28], as well as key documents relating to the Classical [8, 9, 12, 14] and Rhapsody [10, 11] formalisms.

UML vs. classical vs. rhapsody statecharts

433

In addition, two other documents [34, 24] were invaluable, as they offered an outsiders perspective to understanding Classical statecharts. [34] was particularly useful as background material in that it examined some twenty variants of Harels original statecharts formalism. The variants were compared along many dimensions, including adherence to the synchrony hypothesis, zero-time transitions, simultaneous events, priority scheme, etc.

8 Conclusion In the research literature, there are currently three popular formalisms for modelling state machines: UML state machine diagrams, Classical statecharts and Rhapsody statecharts. Modellers may adhere to MDD without being restricted to one particular formalism. In general, the similarities between Classical statecharts, UML state machine diagrams, and the statecharts implemented by the Rhapsody tool are often enough to imply to the non-expert that a state machine modelled in one formalism can be interpreted in the other formalisms. Unfortunately, this is not necessarily the case; there are enough syntactic and semantic differences between the formalisms to cause problems when sharing models. Some problems are caused by simple notation differences and can be solved with a translation. Some problems cause well-formedness issues; occasionally, these problems can be solved with translation or re-working of the model. Occasionally, these problems cannot be solved, but at least their presence can be identied by syntax or well-formedness checks. Finally, some problems cannot be identied by such checks; these are the most insidious problems and result in well-formed models which behave differently in different formalisms. The results of this research are of interest to modellers, tool developers, and end users of statecharts and state machine diagrams for the following reasons:

leading to a modeller/customer disconnect, which may not be noticed. Similarly, models might be shared between modellers, or ported from one modelling environment to another. If the participants are not aware of the potential problems of notation, well-formedness and execution behaviour, these models cannot be shared or ported accurately. Finally, tool developers should also be aware of these differences and potential problems in order to gear their tools to particular formalisms. Tool developers may also offer import/export capabilities; our work indicates the parts of a model that must be translated or otherwise modied. In addition, the development of syntax and well-formedness checkers can benet from knowledge of these differences.

9 Future work The following areas could be considered fertile ground for future work:

Modellers should be aware of how their models will be interpreted in different formalisms. This is especially important with respect to execution behaviour issues, where a modeller might be expecting a different behaviour than that exhibited by a model. In the same vein, statecharts can be used as a communication medium between modellers and their customers, or end users. Users may interpret these models differently, based on an alternate formalism with which they are familiar. Indeed, the users may not even be aware that their interpretation is different,

Using the specic cases described in Sect. 4, identify necessary requirements for a statechart to be considered portable between the various formalisms. This could take the form of a list of constraints that create a core statechart that would be compatible with two or three of the formalisms. Due to the nature of the differences between the three formalisms, there could be two levels of portability: Portability between Classical and UML/Rhapsody. Many of the problems in porting between Classical and the other two formalisms are caused by Classicals use of simultaneous events, simultaneous actions, and the inverted priority of conicting transitions. Therefore, the constraints for portability at this level would be quite stringent, for instance: one event trigger per transition, one action per transition, no conicting transitions, etc. Portability between UML and Rhapsody. On the other hand, these two formalisms are actually quite similar; their major differences are due to notation or well-formedness. Constraints could include: no labels after fork pseudostates, no labels before join pseudostates, no choice points, etc. In addition, care would have to be taken when porting Rhapsody statecharts using conditional pseudostates enclosed in composite states, as discussed in Sect. 4.9.

434

M. L. Crane, J. Dingel

Using the requirements for portability listed above and the translations informally explained in Sect. 4, create algorithms and perhaps tool support for porting statecharts between formalisms. As it stands, only about half of the cases summarized in Table 3 could be automatically translated by a tool. The rest of the cases could require deep understanding, and even extensive refactoring, of the underlying source model. For those cases in Sect. 4 for which there does not appear to be a simple transition, investigate the feasibility of more complex translations, perhaps including a deeper understanding of the underlying model, or creating translations based on different interpretations of behavioural equivalence. If applicable, formally argue that such translations are impossible. The results documented in this paper are not formally derived; they were obtained by careful examination of academic research and exploration of examples. It would be interesting to map each formalism to the same semantic domain and formally compare the results of these mappings. Although there exist many mappings of the Classical (e.g., [5], [17], [21], [25], [22], [23], [33]) and UML (see [4] for a discussion of two dozen approaches) statechart formalisms to particular semantic domains, we would map to a semantic domain (as yet unpublished) currently being developed by the UML 2 Semantics Project [32].

Acknowledgements We would like to acknowledge the invaluable assistance of Bran Selic from IBM Rational Software Canada. We would also like to thank the reviewers for their insightful comments and questions. This research is supported by the Ontario Graduate Scholarship program and the IBM Centers for Advanced Studies.

References
1. Alur, R., Benedikt, M., Etessami, K., Godefroid, P., Reps, T., Yannakakis, M.: Analysis of recursive state machines. ACM Trans. Program. Languages Systems 27(4), 786818 (2005) 2. Berry, G., Gonthier, G.: The ESTEREL synchronous programming language: design, semantics, implementation. Sci. Comput. Program. 19, 87152 (1992) 3. Booch, G., Rumbaugh, J., Jacobson, I.: The Unied Modeling Language User Guide. Addison-Wesley (1999) 4. Crane, M.L., Dingel, J.: On the semantics of UML state machines: Categorization and comparison. Technical Report 2005-501, School of Computing, Queens University (2005) 5. Damm, W., Josko, B., Hungar, H., Pnueli A.: A compositional real-time semantics of STATEMATE designs. In: Compositionality: The Signicant Difference, Lecture Notes in Computer Science, vol. 1536, pp. 186238. 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: a formal semantics using graph transformations. In: Proceedings of the Workshop on Precise Semantics for Modelling Techniques (PSMT98), pp. 5572. Technische Universitt Mnchen, TUM-I9803 (1998) 8. Harel, D.: Statecharts: a visual formalism for complex systems. Sci. Comput. Program. 8(3), 231274 (1987) 9. Harel, D.: Some thoughts on statecharts, 13 years later. In: Proceedings of the 9th International Conference on Computer Aided Verication (CAV97), Lecture Notes in Computer Science, vol. 1254, pp. 226231. Springer, Heidelberg (1997) 10. Harel, D., Gery, E.: Executable object modeling with statecharts. Computer 30(7), 3142 (1997) 11. Harel, D., Kugler H.: The Rhapsody semantics of statecharts (on, on the executable core of the UML) (preliminary version). In: SoftSpez Final Report, Lecture Notes in Computer Science, vol. 3147, pp. 325354. Springer, Heidelberg (2004) 12. Harel, D., Naamad, A.: The STATEMATE semantics of statecharts. ACM Trans. Soft. Eng. Methodol. (TOSEM), 5(4), 293333 (1996) 13. Harel, D., Pnueli, A., Schmidt, J.P., Sherman R.: On the formal semantics of statecharts. In: Proceedings of the 2nd IEEE Symposium on Logic in Computer Science, pp. 5464. Computer Society Press of the IEEE (1987) 14. Harel, D., Politi M.: Modeling Reactive Systems with Statecharts: 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 choices in the semantics of statecharts. Inform. Process. Lett. 37(4), 205213 (1991) 17. Huizing, C., Gerth, R., de Roever, W.P.: Modelling Statecharts behaviour in a fully abstract way. In: CAAP 88: 13th Colloquium on Trees in Algebra and Programming, Lecture Notes in Computer Science, vol. 299, pp. 271294. Springer, Heidelberg (1988) 18. I-Logix: Rhapsody 6.2 User Guide 19. I-Logix: Rhapsody. http://www.ilogix.com/sublevel.aspx? id=53 20. I-Logix: Statemate. http://www.ilogix.com/sublevel.aspx? id=74 21. Lttgen, G., von der Beeck, M., Cleaveland, R.: A compositional approach to statecharts semantics. In: Proceedings of the 8th ACM SIGSOFT International Symposium on Foundations of Software Engineering, pp. 120129. ACM Press (2000) 22. Maggiolo-Schettini, A., Peron, A.: A graph rewriting framework for statecharts semantics. In: Proceedings of the International Conference on Graph Grammars (GRAGRA), Lecture Notes in Computer Science, vol. 1996, pp. 107121. Springer, Heidelberg (1996) 23. Maggiolo-Schettini, A., Peron, A., Tini, S.: A comparison of statecharts step semantics. Theor. Comput. Sci. 290(1), 465 498 (2003) 24. Mikk, E.: Semantics and Verication of Statecharts. PhD thesis, Christian-Albrechts University of Kiel, 2000. Bericht Nr. 2011 25. Mikk, E., Lakhnech, Y., Siegel M.: Hierarchical automata as model for statecharts. In: Proceedings of the Asian Computing Science Conference (ASIAN 97), Lecture Notes in Computer Science, vol. 1345, pp. 181196. Springer, Heidelberg (1997)

UML vs. classical vs. rhapsody statecharts 26. OMG. UML specication. Document formal/03-03-01, Object Management Group, Version 1.5 (2003) 27. OMG. UML 2.0 infrastructure specication. Document ptc/03-09-15, Object Management Group (2004) 28. OMG. Unied Modeling Language: Superstructure version 2.0. Document formal/05-07-04, Object Management Group (2005) 29. Pnueli, A., Shalev M.: What is in a step: On the semantics of statecharts. In: Proceedings of the International Conference on Theoretical Aspects of Computer Software (TACS91), Lecture Notes in Computer Science, vol. 526, pp. 244264. Springer, Heidelberg (1991) 30. Selic, B.: The pragmatics of model-driven development. IEEE Softw. 20(5), 1925 (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 for statecharts using labeled transition systems. In: Proceedings of Concurrency Theory (CONCUR 94), Lecture Notes in Computer Science, vol. 836, pp. 217. Springer, Heidelberg (1994) 34. von der Beeck, M.: A comparison of statecharts variants. In: Formal Techniques in Real-Time and Fault-Tolerant Systems (FTRTFT94), Lecture Notes in Computer Science, vol. 863, pp. 128148. Springer, Heidelberg (1994) 35. von der Beeck, M.: A structured operational semantics for UML-statecharts. Softw. Systems Modeling 1(2), 130 141 (2002)

435 Juergen Dingel received an M.Sc. from Berlin University of Technology in Germany and a Ph.D. in Computer Science from Carnegie Mellon University (2000). Since 2000, he has been on the faculty of the School of Computing at Queens University where he leads the Applied Formal Methods Group. His research interests include the formal specication, verication and analysis of software systems in general, and software model checking, model-based testing and the foundations of modeldriven development in particular.

Authors Biography
Michelle L Crane obtained her B.Comm, with a specialization in Management Information Systems, from the University of Ottawa, Canada, in 1992. She spent a decade in the Canadian Forces, retiring in 2000 to pursue graduate studies in Computer Science. She completed her M.Sc. at Queens University, Canada in 2003 and is currently pursuing her Ph.D. at the same university. Her research interests include state machines, formal semantics, light-weight formal methods, and the Unied Modeling Language, specically actions and activity diagrams.