Executing UML State Machines Bericht-Nr. 2006-4
Thomas Santen Dirk Seifert santen,
[email protected] M¨arz 2006
ISSN 1436-9915
Executing UML State Machines Thomas Santen Dirk Seifert Technische Universit¨at Berlin, Softwaretechnik Sekr. FR 5-6, Franklinstr. 28/29, 10587 Berlin {santen,seifert}@cs.tu-berlin.de
Abstract We present a formal operational semantics for UML state machines. This semantics is implemented in Teager, a tool suite supporting test automation. This report focuses on defining the way events are processed and firing transitions are determined and executed. Furthermore the UML semantics provides variation points to allow for domain specific specializations. We clearly identify those variation points and thereby make the parameters of the semantics explicit.
1
Introduction
The Unified Modeling Language [UML04] nowadays is the de facto standard for modeling object-oriented systems. The language comprises various types of models describing the system structure or the behavior of components. Generally speaking the UML is a semiformal modeling language with a precisely defined syntax and static semantics. The dynamic semantics, however, is defined only informally. In the UML, class diagrams specify the general structure of a system. Additionally each class has an optional state machine associated to it, which describes the discrete behavior (behavioral state machine) or the usage protocol (protocol state machine) of that class. In the following we interpret state machines as behavioral state machines. The formalism of state machines is a variant of Statecharts [Har87, HN96, PS91, HG97] whose semantics has been adapted to the special requirements of object-oriented systems in general and the UML in particular. The formalism is based on finite state-transition systems and the basic idea is that of state decomposition. As a consequence of integrating them with the object-oriented paradigm, state machines have many extensions caused by features to model the communication between objects. These are, for example, several different types of events modeling synchronous or asynchronous message processing, timing and other properties of object communication. As another consequence, the behavior of state machines, in particular the way events are processed and firing transitions are determined, also differs from the behavior of classical Statecharts. In this report, we concentrate on models describing the discrete behavior of state machines, that means, on the way they process events and determine firing transitions. We disregard the complexity added by different types of messages and the data they may carry. We particularly focus on the interesting conceptual issues of non-determinism.
1
Therefore, we restrict the syntax to the basic features of state machines which are hierarchically structured states, parallelism and multi-level transitions. As a consequence, we do not consider history, final, fork and join states, restrict events to signal events and do not consider call, time and change events. We treat neither object creation and destruction, nor compound transitions. We also abstract from all data, that means, actions do not carry any data (parameters) and entry, activity and exit actions are not considered. However, integrating of most of these features is straightforward or does not essentially influence the semantics presented here. In Section 6 we discuss some extensions we plan to address in the future. Most attempts to formalize UML state machines aim at model checking [LP99a, LMM99a, LMM99b, BBK+ 04]. With our formalization we aim at conformance testing, that means, checking the consistency between a state machine specification and a system under test. Therefore we wish to execute a state machine specification and analyze the observable behavior. This is the basis to generate test cases that stimulate and observe the system under test. The semantics definition we describe conforms to the UML 2.0 Superstructure specification [UML04]. Our semantics also draws from other work on defining semantics for object-oriented state machines [BBK+ 04, LP99a, LMM99b]. We assume the reader to be familiar with UML state machines [UML04] and to have basic knowledge of the Z notation [Z00, Spi92, PST91, WD96]. The remainder of this report is structured as follows. In Section 2 we give an example of a UML state machine. In Section 3 we describe the abstract syntax and in Section 4 we describe the semantics of state machines. We conclude this section by defining a semantical step of a state machine. In Section 5 we give examples to illustrate our definitions and motivate the decisions leading to them. In Section 6 we present an overview of possible extensions which could be added to broaden our approach. Finally, in Section 7, we discuss some related work.
2
An Example State Machine
This section provides an intuitive understanding of state machines and the way they work. As our running example we use the simple fictitious state machine shown in Figure 1. This state machine which contains all aspects we need to explain our formalization. We call states which are atomic simple states and states which contain other states composite states. Further we distinguish between simple composite states and orthogonal states. For simple composite states only one of its substates is active at a time. For orthogonal states all substates are active at a time. Graphically we depict the substates within the enclosing state, and dashed lines separate the different parts or regions of an orthogonal state. We mark states in which the state machine resides by default with an arrow originating from a filled circle. Example 1 (Example State Machine). The state Example State Machine is the root state of the state machine in Figure 1. The root state of a state machine is by definition a simple composite state. Example State Machine contains two substates, A and B. The orthogonal state A is subdivided into C and D. The simple composite state C is subdivided into the simple composite state E, which contains the three simple states H, I and K. The simple composite state D is subdivided into the simple composite state F, which contains the simple states L and M, and the simple state G. A consequence of the
2
Example State Machine A
C
E
F
D
H
L
t1
t2
I
K
t6
t4
t7
B
M t3 t8
t5
G
Figure 1: An Example State Machine hierarchical and concurrent structuring of states is that a state machine can be in multiple states at the same time. Initially the state machine is in states Example State Machine, A, C, D, E, H and G. Note that L is also an default state. But in state D the default state is G and not F. So state L is not active initially. 2 Taking transitions is the basic reaction of a state machine to external stimuli. While taking a transition the state machine can change from one state to another. Graphically we depict a transition as a labeled arrow starting from the source state and ending at the target state. The label of a transition comprises two parts.1 The first part gives the signal event e which triggers, i.e., which enables, the transition. In contrast to a call event (a method invocation), a signal events represents the receipt of an asynchronous signal instance and may cause the state machine to trigger a transition. The second part is optional. If present, it contains an effect, which in our formalization is a sequence of actions that is executed when the transition is taken. An action triggers a new signal event. Example 2 (Transition Label). A transition labeled with e / a1 ; a2 is taken under the event occurrence e and executes the actions a1 followed by a2 , i.e., it triggers the two signal events a1 and a2 . 2 The hierarchical and concurrent structuring of states induces a state hierarchy which we illustrate as a tree of states starting from the single root state down to individual simple states at the leaves. Figure 2 shows the tree representation of the example state machine in Figure 1. Doubled circles denote default states and the substates of orthogonal states are combined with a semi-circle expressing that the state machine is in all direct substates of the orthogonal state at the same time. Dashed arrows denote the transitions of the state machine. They are labeled with the transition name. We call transitions crossing state borders, such as t8, or – equivalently – levels in the tree representation – multi-level transitions. 1
For simplicity reasons, Figure 1 shows only names but not the labels of transitions.
3
Example State Machine A
B
C
t4
D
t3 t5
E
H
I
F
t6
K
L
G M
t8
t7
t1 t2
Figure 2: Tree Representation Taking a transition comprises leaving the source state and entering the target state after executing all actions. Note that leaving one orthogonal part of a state due to a multi-level transition comprises leaving all orthogonal parts of that state, and that entering one part of an orthogonal state directly causes the state machine to enter all default states in the remaining parts. Example 3 (Firing a Transition). Taking transition t1 in Figure 1 means to leave state H and to enter state I whereas taking transition t3 means to leave A and all of its active substates and to enter state B. On the other hand taking transition t4 causes the state machine to leave state B and to enter the states A and D, F and L in the right-hand side orthogonal part, and C, E and H in the left-hand side orthogonal part. 2 In the following we present a formalization for a subset of UML state machines. This subset is suitable for basic state machine execution and therefore for generating test cases from state machine specifications. In Section 3 we present the abstract syntax we use for state machines and in Section 4 we present a formal operational semantics.
3
Abstract Syntax
A state machine SM == ((S , H ), E , T , D) is a structure consisting of four components. (S , H ) denotes a state hierarchy, E denotes a finite set of events, T denotes a finite set of transitions, and D ⊆ S denotes the set of default states. The state hierarchy (S , H ) consists of a finite set S of states and a substate relation H ⊆ S × S . Definition 1 (Type). Given a state machine SM == ((S , H ), E , T , D), the function type : S → {simple, simple composite, orthogonal} determines the type of each state s ∈ S in the state hierarchy H . 2 The UML standard [UML04] uses three attributes to specify the type of a state. The attribute isSimple stores whether a state is a simple state, the attribute isComposite stores whether a state is decomposed into substates and the attribute isOrthogonal stores
4
whether a state contains orthogonal substates. These attributes correspond to Definition 1 as follows: if s.isSimple, simple type(s) = simple composite if ¬ s.isSimple ∧ s.isComposite ∧ ¬ s.isOrthogonal , orthogonal if ¬ s.isSimple ∧ s.isComposite ∧ s.isOrthogonal . Using the typing function type(s) avoids unnecessary redundancy, because all combinations of attribute values that do not correspond to a type are not allowed. We call a state s a composite state if type(s) is either simple composite or orthogonal. Additionally we require that S contains a unique and distinguished root state, which is the only state which is not a substate of another state, which is a simple composite state, which is neither the source nor the target of a transition, and which is a default state. Constraint 2 (Root State). Given a state machine SM == ((S , H ), E , T , D), there exists a distinguished state r ∈ S which has no parent. We call this state the root state of SM and refer to it with root. type(root) = simple composite ∀ t : T • root 6= source(t) ∧ root 6= target(t) root ∈ D where root == µ s : S • s ∈ / ran H .
(1) (2) (3) 2
To describe the structural relations between states we define three functions. The function substates : S →F S yields the finite set of all immediate substates of a state. The functions substates + → F S and substates ∗ → F S yield the finite set of all transitive substates and the finite set of all transitive-reflexive substates, respectively. Definition 3 (Substates). Given a state machine SM == ((S , H ), E , T , D), the finite sets of substates are defined as follows. substates(s) == {s 0 : S | s 7→ s 0 ∈ H } +
0
0
(1)
+
substates (s) == {s : S | s 7→ s ∈ H } ∗
(2)
+
substates (s) == {s} ∪ substates (s)
(3)
where H + denotes the transitive closure of H .
2
If s2 ∈ substates ∗ (s1 ), we say that s1 is an ancestor of s2 and that s2 is a descendant of s1 . If s2 ∈ substates + (s1 ), we say that s1 is a strict ancestor of s2 and that s2 is a strict descendant of s1 . If s1 is either an ancestor or a descendant of s2 , we say that s1 and s2 are ancestrally related [Har87]. Note that for a state s both applies: s is an ancestor and a descendant of itself. It also applies that the root state is an ancestor of every state s ∈ S and that every state, except the root state, has a single parent. Thus, the hierarchy relation arranges the states of a state machine in a tree.
5
Constraint 4 (Hierarchy Relation). Given a state machine SM == ((S , H ), E , T , D), the state hierarchy must form a finite tree rooted at root and with the simple states of S as its leafs. ∃1 r ∈ S • r ∈ / ran H ∀ s : S \ {root} • ∃1 s 0 ∈ S • s 0 → 7 s∈H
(1) (2) 2
Definition 5 (Container). Given a state machine SM == ((S , H ), E , T , D), the partial function container : S → 7 S yields the parent state of each state s ∈ S \ {root}. The parent state exists and is unique (cf. Constraint 4). container (s) == µ s 0 : S | s 0 7→ s ∈ H
(1) 2
Constraint 6 (States). Given a state machine SM == ((S , H ), E , T , D), for every state s ∈ S the following constraints must hold. type(s) = simple type(s) = orthogonal
⇒ substates(s) = ∅ (1) ⇒ #substates(s) ≥ 2 ∧ (2) ∀ s 0 : substates(s) • type(s 0 ) = simple composite ∧ substates(s) ⊆ D
type(s) = simple composite ⇒ #substates(s) ≥ 1 ∧ ∃1 s 0 : substates(s) • s 0 ∈ D
(3) 2
Constraint 6.1 requires that a simple state has no direct substate. Constraint 6.2 requires that for an orthogonal state the number of substates must be greater than or equal to two, that all substates of an orthogonal state must be of type simple composite, and that all direct substates are default states. Thus we yield a unique representation for state machines. Constraint 6.3 requires that an simple composite state has at least one direct substate and that exactly one direct substate is a default state. A transition t in T ⊆ S × E × seq E × S consists of four parts. To access these parts we define four projections. The projection source : T → S yields the source state of a transition t.1. The projection trigger : T → E yields the trigger of a transition t.2. The projection effect : T → seq E yields the effect of a transition t.3, i.e., a sequence of actions, and finally the projection target : T → S yields the target state of a transition t.4. Constraint 7 (Transition). Given a state machine SM == ((S , H ), E , T , D), for every transition t ∈ T the following constraints must hold. type(source(t)) = simple composite ⇒ type(container (source(t))) 6= orthogonal (1) type(target(t)) = simple composite ⇒ type(container (target(t))) 6= orthogonal (2) 2
6
The Constraints 7.1 and 7.2 require that neither the source state nor the target state of a transition is a direct substate of an orthogonal state. Direct substates of orthogonal states are only used as containers, i.e., for structuring and naming different parts of orthogonal states. In addition, note that it is impossible to start or to end an arrow of a transition at only one part of an orthogonal state. In the UML standard a simple composite state contains one (so called) region and an orthogonal state is decomposed into two or more orthogonal regions. Each region has a set of mutually exclusive disjoint substates and a set of transitions [UML04]. In our semantics definitions we do not need the meaning of regions, instead we allow, as we described above, only simple composite states as direct substates of orthogonal states. Also remember that the root state of a state machine neither is the source nor the target state of any transition (cf. Constraint 2).
4
Semantics
This section states an operational semantics of state machines. First we define a semantical state of a state machine. Then we characterize how to identify a set of transitions which fire within a step, and finally, we define a semantical step of a state machine in more detail. State machines communicate by sending events to each other. While executing, a state machine generates events which will be sent to other objects, and it receives events generated by other objects. Among the set of evens E we distinguish a set of events ESM which contains all events that can possibly be sent to the state machine. The events a state machine receives are stored for further processing within the state machine. The UML standard does not specify in detail the way of storing and dispatching events. Instead the user has to define a management policy within a so-called semantic variation point: semantic variation points explicitly identify the areas where the semantics are intentionally under specified to provide leeway for domain-specific refinements of the general UML semantics (e.g., by using stereotypes and profiles) [UML04]. Concerning the management policy the following abstract description of event processing is given in the standard: Events are often generated as a result of some action either within the system or in the environment surrounding the system. Upon their occurrence, events are placed into the input pool of the object where they occurred (. . . ). An event is dispatched when it is taken from the input pool and either directly causes the occurrence of a behavior or are delivered to the classifier behavior of the receiving object for processing. At this point, the event is considered consumed and referred to as the current event. A consumed event is no longer available for processing. (. . . ) Event occurrences are detected, dispatched, and then processed by the state machine, one at a time. The order of dequeuing is not defined, leaving open the possibility of modeling different prioritybased schemes [UML04]. In most practical applications a priorized queue is used for storing events. We stay a little more abstract and rely on an abstract data type Q to describe the event management policy. This data type meets all requirements of the UML standard and does not constrain possible realizations. The function enqueue : Q × seq ESM → Q adds a sequence of events into a queue. The function dequeue : Q → ESM × Q dispatches an event from the queue, yielding the current event and the input queue with the current event removed. The boolean function empty : Q → B describes whether a given queue is empty or not.
7
Definition 8 (Queue Operations). Given a state machine SM == ((S , H ), E , T , D), the function enqueue and the function dequeue are defined as follows. enqueue(Q, es) == Q 0 , where Q 0 == Q ⊕ es dequeue(Q) == (e, Q 0 ), where Q 0 == Q e
(1) (2) 2
Defining the two functions ⊕ and instantiates a further semantic variation point and thus specifies a concrete queue data type. Definition 9 (Active State Configuration). Given a state machine SM == ((S , H ), E , T , D), an active state configuration or configuration C : F S of a state machine is the set of all active states at a time, i.e., the set of all states in which the state machine resides at that point in time. It must satisfy the following conditions. root ∈ C ∀ s : C | type(s) = simple composite • ∃1 s 0 : substates(s) • s 0 ∈ C ∀ s : C | type(s) = orthogonal • ∀ s 0 : substates(s) • s 0 ∈ C
(1) (2) (3)
The initial configuration must additionally satisfy the following constraint. C ⊆D
(4) 2
Constraint 9.1 requires root to be a member of every configuration, which is natural. Constraint 9.2 requires that exactly one direct substate of an active simple composite state is active. Constraint 9.3 requires that all direct substates of an active orthogonal state are active. This explains why simple composite states are also referred to as xor states and why orthogonal states are also referred to as and states. If the type of a state s is simple composite, substates(s) is an exclusive or-decomposition of s, i.e., the state machine is in exactly one of its immediate substates at a time. If the type of a state s is orthogonal, substates(s) is an and-decomposition of s, i.e., the state machine simultaneously is in all of its immediate substates at a time. Additionally Constraint 9.4 requires for the initial configuration that every state also is a default state. Note that the initial configuration is different from the set of all default states. The reason is that a member of the set of default states D becomes active if its container becomes active. However, not every container is active initially. On the basis of a configuration we can also form a tree structure starting at the root state. This structure (C , C / H ) is a restriction of the state hierarchy of the state machine (S , H ), and it is well-formed due to Constraint 6. Now we can characterize the status of a state machine by an active state configuration and an event queue. Definition 10 (Status). Given a configuration C : F S and an event queue Q : Q, each status of a state machine consists of a pair [[C , Q ]]. The initial status of a state machine consists of the initial configuration and an empty queue. 2
8
4.1
Event Processing – The Run-To-Completion Step
The execution semantics of state machines is defined in the UML standard in terms of a hypothetical machine. This machine consists of three key components. The first component is an event queue which holds incoming events2 until they are dispatched. The second component is an event dispatch mechanism for selecting and dispatching events. And the third component is an event processor which executes the state machine in a so-called run-to-completion step: The semantics of event occurrence processing is based on the run-to-completion assumption, interpreted as run-to-completion processing. Run-to-completion processing means that an event occurrence can only be taken from the pool and dispatched if the processing of the previous current occurrence is fully completed [UML04]. Thus events are detected, dispatched and processed one at a time. Within a run-tocompletion step the state machine moves from one status to the next status. When an event is dispatched, one or more transitions may become enabled for firing. If no transition is enabled, the event occurrence is discarded and the run-to-completion step is completed – which is also referred to as stuttering. Definition 11 (Enabled Transition). Given a state machine SM == ((S , H ), E , T , D) and a status [[C , Q ]], the boolean function enabled : T × ESM × F S → B signifies whether a transition t is enabled w.r.t. an event e and a configuration C . A transition is said to be enabled if and only if the source state is in the current configuration and the trigger is equal to the current event. ( true if source(t) ∈ C ∧ trigger (t) = e (1) enabled (t, e, C ) == false otherwise where (e, Q 0 ) == dequeue(Q).
2
If several transitions are enabled they may be in conflict with each other. Some conflicts can be resolved based on a transition priority. This priority is defined by the relative position of the source states of the transitions in the state hierarchy. In a state machine, a transition originating from a substate has priority over a conflicting transition originating from any of the containing states of that substate. The transition selection algorithm determines which of the enabled transitions actually fires. In Figure 1, for example, transition t1 and t2 are in conflict; only one can fire at a time to reach a new well-formed configuration. Definition 12 (Consistent and Conflicting Transitions). Given a state machine SM == ((S , H ), E , T , D), transitions t1 , t2 ∈ T are called consistent, denoted t1 k t2 , if they do not have a common state to be left. Otherwise, these transition are in conflict, denoted t1 ∦ t2 . t1 k t2 ⇔ exits(t1 ) ∩ exits(t2 ) = ∅
(1) 2
2
In the object oriented terminology it is better to speak of event occurrences since we observe the occurrence of an event instance. Anyway we use the term event for simplicity reasons.
9
To allow transitions to cross levels in the state hierarchy, so-called inter-level transitions, we take the scope of a transition into account. Taking transition t3 in Figure 1 does not only cause the machine to leave state G but also the entire state A. Therefore the scope Example State Machine of transition t3 must indicate the subtree of the state hierarchy which is affected when firing a transition. The scope is determined from the source and the target state of a transition. Definition 13 (Scope of a Transition). Given a state machine SM == ((S , H ), E , T , D), the function scope : T → S yields the scope (or least common ancestor ) of the source state and the target state of a transition. It is the (uniquely defined) smallest composite state which contains the source state and the target state. scope(t) == µ s : S |source(t) ∈ substates + (s) ∧ target(t) ∈ substates + (s) ∧ 0
0
(1)
+
(∀ s : S | s ∈ substates (s) • +
0
(2) +
0
¬(source(t) ∈ substates (s ) ∧ target(t) ∈ substates (s ))) (3) 2 Two states are orthogonal if they are not ancestrally related and their scope is an orthogonal state. For every set R of states, we say that the set R is consistent if and only if every two states s1 , s2 ∈ R either are ancestrally related or orthogonal. On the basis of the scope we define the main source and the main target of transition t. It follows from Definition 4 and Definition 13 that the main source and the main target of a transition exist and are unique. Definition 14 (Main Source and Main Target). Given a state machine SM == ((S , H ), E , T , D), the main source and the main target are defined as follows. µ s : substates(scope(t)) | source(t) ∈ substates ∗ (s) if type(scope(t)) = simple composite (1) mainSource(t) == scope(t) if type(scope(t)) = orthogonal µ s : substates(scope(t)) | target(t) ∈ substates ∗ (s) if type(scope(t)) = simple composite mainTarget(t) == (2) scope(t) if type(scope(t)) = orthogonal 2 Based on the main source and the main target of a transition we define the set of states which will be left when firing this transition as follows. Definition 15 (States to be Left). Given a state machine SM == ((S , H ), E , T , D) and a status [[C , Q ]], the function exits : T → F S yields the set of states which will be left when taking a transition t ∈ T . exits(t) == substates ∗ (mainSource(t)) ∩ C
(1) 2
10
As previously mentioned some conflicts can be resolved by priorizing transitions. The priority is based on the relative position of the source states in the state hierarchy. A transition originating from a substate has priority over a conflicting transition originating from any of its containing states. Definition 16 (Priority of Transitions). Given a state machine SM == ((S , H ), E , T , D), the priority relation ≺: T × T relates two transitions. A transition t2 ∈ T has priority over a transition t1 ∈ T , if and only if t1 ≺ t2 . t1 ≺ t2 ⇔ source(t2 ) ∈ substates + (source(t1 )) 2 The reflexive closure of the priority relation is a partial order. With this priority scheme we can resolve some of the possible conflicts between enabled transitions but not all of them. For example in Figure 1, both transitions t1 and t2 leave state H but none of them has priority over the other. If both are enabled, the machine must – nondeterministically – select one transition for firing. In general, a transition selection algorithm selects a set Tk ⊆ T of transitions for firing. For this set – the firing transition set – the following constraints must hold. Constraint 17 (Firing Transition Set). Given a state machine SM == ((S , H ), E , T , D) and a status [[C , Q ]], the following constraints must hold for every firing transition set Tk . ∀ t : Tk • enabled (t, e, C ) ∀ t1 , t2 : Tk | t1 6= t2 • t1 k t2 ¬ (∃ t 0 : T \ Tk | enabled (t 0 , e, C ) • ∀ t : Tk • t k t 0 ∨ t ≺ t 0 ) where (e, Q 0 ) == dequeue(Q)
(1) (2) (3) 2
Constraint 17.1 requires that all transitions in Tk are enabled, which means that the trigger of each transition is equal to the current event. Constraint 17.2 requires that all transitions in Tk are mutually consistent. Constraint 17.3 requires that there is no transition outside Tk which is consistent with all transitions in Tk or with priority over a transition in Tk . Precisely, with t k t 0 we ensure that the set contains the maximal number of consistent transitions. With t ≺ t 0 we ensure that we select transitions with the highest priority. If there is more than one set fulfilling Constraint 17 the state machine is said to be non-deterministic, because we are free to – arbitrarily – choose one set. Defining a specific selection strategy instantiates a further semantic variation point and thus defines a concrete transition selection algorithm. Definition 18 (States to be Entered). Given a state machine SM == ((S , H ), E , T , D), the function enters : S × S → F S applied to the main target and to the target of a transition t ∈ T yields the set of states which will be entered when
11
firing the transition.
enters(s, target) ==
{s} if type(s) = simple [ enters(s 0 , target) {s} ∪ s 0 ∈substates(s)
if type(s) = orthogonal {s} ∪ enters(s 00 , target) if type(s) = simple composite where s 00 == µ s 000 : substates(s) | target ∈ substates ∗ (s 000 ) ∨ (s 000 ∈ D ∧ target ∈ / substates + (s)) 2 Starting from the main target of a transition we calculate the set of states to be entered. If the given state s is a simple state only this state is entered. If the given state s is an orthogonal state all substates are entered since all substates also become active if the container becomes active (cf. Constraint 6.2). If the given state is a simple composite state we distinguish two alternatives. Either we enter the direct substate s 000 which contains the target state – target ∈ substates ∗ (s 000 ). Then we are on the way down from the main target to the target state. Or we enter the default state s 000 if the target state is not a substate of the current state – s 000 ∈ D ∧ target ∈ / substates + (s). The latter case also covers the explicit entering of orthogonal parts. In that case we are on the way down and have already reached the target state, or we are on the way down and have to enter an orthogonal part which the transition does not enter explicitly.
4.2
Semantical Step
A semantical step is the transition from one status to the next status and comprises executing all transitions in the firing transition set. This contains determining the set of firing transitions w.r.t. the current event, followed by firing each transition. Firing a transition t consists of leaving all states in exits(t), executing all actions of effect(t) and entering all states in enters(t). The next status comprises the resulting configuration and the resulting queue which is build from dequeuing the current event, enqueuing generated events and events received from the environment. For the definition of a semantical step we further partition the state machine’s event set pub ESM ⊆ E into two disjoint sets: the set of public events ESM contains all events which prv the environment can generate; the set of private events ESM contains all events which only a state machine instance itself can generate. Ein ,Eout
Finally we define a semantical step [[C , Q ]] −−−−−→ [[C 0 , Q 0 ]] whereas we distinguish two situations. First, if the current queue is empty, the state machine is stuttering and thus does not change the current configuration. Second, if we can dispatch the current event, the state machine moves from the current status to the next status as described above.
12
Definition 19 (State Machine Step). Given a state machine SM == ((S , H ), E , T , D), a status [[C , Q ]] and a sequence of incoming events seq Ein (where pub Ein ⊆ ESM ) which were generated by the environment during the step. The following pub rules define the status transition relation −→: status × seq ESM × seq (E \ ESM ) × status. ¬ empty(Q) (e, Q 00 ) = dequeue(Q) Tk ⊆ T ∧ Tk Constraint 17 0 C = (C \ exits(Tk )) ∪ enters(Tk )
empty(Q) Q = enqueue(Q, Ein )
Eint = a/Xint ∧ Xint ∈ perm({t : Tk • effect(t) ESM }) Eout = a/Yout ∧ Yout ∈ perm({t : T • effect(t)) (E \ ESM )}
0
k
Q = enqueue(Q , Eint a Ein ) 0
Ein ,∅
00
Ein ,Eout
[[C , Q ]] −−−−−→ [[C , Q 0 ]]
[[C , Q ]] −−−−−→ [[C 0 , Q 0 ]]
whereas we denote the sequence of outgoing events by Eout : seq (E \ ESM ) and the sequence of all internal events by Eint : seq ESM . 2 Note that the set of outgoing events Eout will be sent to the environment, precisely to the appropriate objects. The function perm : F seq E → F seq seq E yields for a set of event sequences the set of all permutations of these sequences. The function a/ : seq seq E → seq E flattens an event sequence (distributed concatenation). In this definition we have two further semantic variation points. The first semantic variation point leaves open the order of the transitions which will fire during the step. The transition selection algorithm only selects a set of transitions for firing (cf. Section 5). The second semantic variation point leaves open how to enqueue events generated during the step by the state machine instance and events received from the environment. In our formalization we choose to treat a step to be atomic and enqueue events received from the environment at the end of the queue. Different solutions are possible.
5
Discussion
In the following we present some annotations and examples to illustrate our definitions. With these additional explanations we aim to help the reader to understand the particular formulation of our definitions.
5.1
Firing Transitions
When firing a transition we need to determine which states will be left and which states will be entered. For flat transition systems, i.e., for transition systems without state decomposition, this is straightforward: the source state of the transition will be left and the target state will be entered. But in the presence of hierarchically structured states, parallelism and transitions crossing state borders, things become more complicated.
13
The solution is to start at the source state of the transition and to move upwards in the state hierarchy, i.e., in the tree representation, and search for the least state (the first when moving upwards) which contains the target state of the transition. We call this state the scope of the transition. The scope gives us the root state of the sub-tree which is affected by the transition. All states which will be left and all states which will be entered when firing the transitions are below this state. Example 4. In Figure 3 the least common ancestor of both transition t1 and transition t2 is state E. For example, in the right-hand part of the figure, starting at H, the first composite state containing source and target of transition t1 is E. For transition t6, starting at state E the least composite state containing both source and target is A since we leave state A when taking transition t6 and re-enter state A (see below). 2 If we want to determine the set of states which will be left when firing a transition we could intersect the current configuration with the set of all states of the transition’s scope. But if we have a closer look at transition t1 and t6 we notice that this procedure is not correct. For example, for transition t1, there is no reason to leave the scope itself. Leaving state E and reentering state E would indeed result in a well-formed active state configuration but this would unnecessarily leave and enter state E. This is a problem if actions need to be executed upon leaving or entering states. When firing transition t6 the left orthogonal part of A will be left and the right orthogonal part will be entered. But what happens to the left part or to a possible third orthogonal part? Will the former also be entered? Will the latter be left? In this case, we must leave the complete orthogonal state A and re-enter A: transition t6 enters the orthogonal part D explicitly and all other orthogonal parts implicitly. This distinction leads to the definition of main source and main target of a transition. They depend on the type of the scope. For simple composite states we use direct substates to define main source and main target and for orthogonal states we use the scope itself (cf. Definition 14). To the best of our knowledge the only situation in which the least common ancestor is an orthogonal state arises if a transition leaves an orthogonal part and reenters an orthogonal part of the same orthogonal state. Example 5. Since E is a composite state, the main source of transition t2 is state H and the main target is K. There is no reason to leave or to enter another state. However, A is an orthogonal state, and the main source and the main target of transition t6 are A. 2 For determining the set of states to be left when firing a transition t we intersect the active state configuration with the set of substates of the main source of t. Example 6. Given an active state configuration C = {ExampleStateMachine, A, C, D, E, G, H}, when firing transition t1 we leave states {H}, since {ExampleStateMachine, A, C, D, E, G, H} ∩ {H} = {H}, where {H} = substates ∗ (H). When firing transition t6 we leave states {A, C, D, E, G, H}, since {ExampleStateMachine, A, C, D, E, G, H} ∩ {A, C, D, E, F, G, H, I, K, L, M} = {A, C, D, E, G, H}, where {A, C, D, E, F, G, H, I, K, L, M} = substates ∗ (A) and mainSource(t6 ) = A. 2
14
Example State Machine A
C
E
F
Example State Machine
D A
H
L
t1
t2
I
K
t6
t7
t4
B
C
t4
D
t3 t5
M
E
t8
H
G
I
F
t6
t3 t5
B
K
L
t1
G M
t8
t7 t2
Figure 3: Example State Machine from Figure 1.
Determining the set of states to be entered when firing a transition is a little bit more complicated. The definition of enters is intuitive for simple and orthogonal states (cf. Definition 18). For simple composite states we give some explanations in the following. The definition is complicated by the fact that simple composite states can be substates of orthogonal states. It is possible to have the target of a transition within one orthogonal part of a state and so the simple composite states of the other parts are not directly affected. Consider firing transition t4. The target of transition t4 is state F. After leaving all corresponding states we have to enter all appropriate states starting at the main target A. Starting at state A, we enter D, F, L in the right sub-tree and C, E, H in the left sub-tree. Definition 18 says: {s} if type(s) = simple [ enters(s 0 , target) {s} ∪ enters(s, target) == s 0 ∈substates(s) if type(s) = orthogonal {s} ∪ enters(s 00 , target) if type(s) = simple composite where s 00 == µ s 000 : substates(s) | target ∈ substates ∗ (s 000 ) ∨ (s 000 ∈ D ∧ target ∈ / substates + (s)) In state D – which is a simple composite state – we enter F since the target F is in the substates of D (first alternative). We do not enter G. Indeed G is an default state but the target state is in the substates of D (second alternative). With substates ∗ (s 0 ) we select this substate to enter which leads us to the target state, with substates + (s) we ensure that initial states are entered only if we are not on the way down to the target state. This happens in exactly two situations. The first situation arises if we reach the target state and need to enter the appropriate states below the target. When entering F there is no substate from which we can reach the target state (first alternative), so we choose the initial substate since the target also is not a substate of F. The second situation is
15
that we need to enter a further orthogonal part like for state C. Here we enter in each case the initial state E and H (second alternative). Note, in the first alternative we have a predicate over a concrete substates, in the second alternative we have a predicate over all substates. This is needed to precisely distinguish between the way down to the target state and entering all initial states.
5.2
Firing Transition Sets
When determining the sets of firing transitions we search for all largest sets of transitions fulfilling Constraint 17. Therefore we use co-induction. Starting with the set of all enabled transitions we check whether the required constraints hold. If this is the case we stop and the resulting set contains only this set of all enabled transitions. If this is not the case we remove an arbitrary transition and check the constraints again. If the constraints still do not hold we choose another transition. If we have removed every transition once, then we repeat this procedure for two (three, four, . . . ) transitions. Once we have found a consistent set of transitions, we add it to our result set (of sets of transitions). In order to get all largest consistent sets of transitions, we continue this computation until we have removed and checked all possible subsets with the same cardinality as the consistent set of transitions we found first. By starting with the set of all enabled transitions (which is by default the largest possible set of firing transitions) and reducing the number of considered transitions step by step we ensure that we get a greatest fix-point. By testing all possible subsets we ensure that we get all greatest fix-points, which means all maximal consistent sets of firing transitions. The following definition describes an algorithm for calculating Tk . Definition 20 (Transition Selection Algorithm). 1. Build the set of all enabled transitions Tenabled ⊆ T by searching for enabled transitions. Start at every simple state in the current configuration and work upwards in the state hierarchy. Terminate the search once a transition originating from such a state is enabled3 . 2. Determine all maximal consistent sets of enabled transitions: Tk = {Tk : P Tenabled | Constraint 17.2 ∧ Constraint 17.3} 3. Choose one firing transition set Tk ∈ Tk . 2
5.3
Non-determinism
In the following we present the three major sources of non-determinism in state machines.
Several firing transition sets. If transitions are in conflict with each other, i.e., firing them all would lead to an ill-formed configuration, then the transition selection 3 This is implemented using a flag in the containing composite state signaling that an enabled transition was found.
16
algorithm produces several consistent firing transition sets. Only one of them is selected for firing, but the semantics does not prescribe which one. Example 7. Given a active state configuration C = {ExampleStateMachine, A, C, D, E, G, H} and the two enabled transitions t1 and t2. Both transitions are in conflict with each other since both leave state H. Thus the transition selection algorithm yields the set {{t1}, {t2}} as result. We are free to choose one set. 2
Order of firing transitions. The order of firing transitions from the selected transition set is arbitrary, too. The particular order when firing transitions from the firing transition set determines the order of observable events produced by the actions of those transitions, and therefore it influences the observable behavior of the state machine. Example 8. Given a active state configuration C = {ExampleStateMachine, A, C, D, E, F, H, L} and the two enabled transitions t1 and t7 . The transition selection algorithm yields as result the set {{t1, t7}}. When selecting this set we are free to choose to fire t1 followed by t7 or t7 followed by t1. 2
Order of event processing. The actions associated with transitions produce internal events that can enable transitions in subsequent steps. Those events and the ones incoming from the environment are processed asynchronously. They are queued into the event queue that also stores incoming events. That queue is part of the “state” of the state machine, but it is not directly observable. Because the order of firing transitions is chosen non-deterministically and may not be observable, the environment can only speculate about the state of the event queue.
6
Extensions
To enable some further studies in test case generation and execution we plan to extend the formalization in some interesting points. In the following we give some ideas and ways how to incorporate these ideas into our framework.
Completion Transitions. The UML standard allows allows triggerless transitions in state machines. Such transitions, called completion transitions, have an implicit trigger, the completion event, which is generated when the last step finishes, i.e., when its transition’s effects, the entry actions and the state activities in the currently active state configuration are completed. Furthermore completion events are special because they have priority over all other events. Thus they influence the event queue data type, i.e., the event management policy. The integration could be done by internally assigning a special completion trigger to such transitions and extending the definition for the queue type. Furthermore we need to adapt the definition of a step to generate such events at the right time.
17
Compound Transitions. Transitions in the UML can have more than one source state or more than one target state. In the first case, namely the join transitions, all source states have to be in the current configuration. In the latter case, namely the fork transitions, all target states will be entered explicitly. This is especially useful, for example, if we want to explicitly enter or leave states in some or every part of an orthogonal state.
Data Variables. Further we plan to integrate data into state machines to admit entry, activity and exit actions, and data manipulation when firing transitions. For the latter case we would also admit guards to have a fine grained control over transition selection. For the integration of data variables in our formalization we especially need to refine the definition of a step. There, we have to define the order in which states will be left and entered, because the order now influences the data variable’s values. Additionally there is a new source of non-determinism, since it is not defined whether orthogonal states will be entered or left in a breadth-first or in a depth-first manner.
7
Related Work
Formalizing UML State Machines for Model Checking [LP99a, LP99b]. Lilius and Paltor give in their paper a formalization of UML state machines which can be used as a basis for code-generation, simulation and verification, and which is implemented in the vUML tool for model-checking UML models. The formalization is done in two steps. In the first step the structure of a state machine is translated into a term-rewriting system. This transformation is standard in the way the syntax is interpreted. Furthermore they present transformations for some extensions of the state machine syntax, for example, for initial states, join and fork vertices and junction vertices. In the second step the operational semantics is defined on the basis of the term rewriting system also using a hypothetical machine. The run-to-completion step presented includes different types of actions and their execution. Namely exit actions, entry actions, activities and actions denoted at transitions. Finally, they present extensions to handle collaborations of objects. The formalization addresses all relevant aspects of UML state machines. The presented run-to-completion-step describes in detail the steps which have to be done during firing the selected transitions. Nevertheless, some definitions are missing or assumed to be too simple to be presented and we used a more understandable and easier to implement representation of the definitions.
Towards a Formal Operational Semantics of UML Statechart Diagrams [LMM99b]. The formal operational semantics presented in this paper bases on Kripke structures and the authors follow the approach proposed by Mikk. First they map state machines to an intermediate format, namely a slightly modified variant of extended hierarchical automata. Then they define the operational semantics according to these representation based on a Kripke Structure. In these Kripke structures states are called statuses and the relation among these states is called the STEP relation. The relation is defined by means of a deduction system and the authors address both cases: that the environment can be manipulated from outside the system – an open system semantics – and that this manipulation is not allowed – a closed system semantics.
18
The set of properties used is rather small and the representation as hierarchical automata seems to be too complicated for our intentions. Also, we do not need the decomposition into sequential automata and so the effort to translate, for example, multi-level transitions is of no benefit.
What is in a Step: On the Semantics of Statecharts [PS91]. The authors present in this paper an improved formal semantics for the originally proposed statecharts notation and semantics by David Harel [Har87]. The used semantics differs substantial from the one used in the UML standard. But the discussions concerning the synchrony hypothesis, causality, priorities and consistency are worth to be mentioned. An extensive comparison of different Statecharts semantics and a discussion of problems of the different formalisms can be found in [VdB94]. The synchrony hypothesis assumes that the system is infinitely faster than the environment and thus can always finish computing its responses before the next stimulus arrives from the environment. Consequently, the response to an external stimulus is within the step – it is simultaneous with the stimulus. Generally speaking, it is an abstraction – simultaneity abstraction – that limits the interference of stimuli and responses. UML state machines process events asynchronously thus not all applies to state machines. The principle of causality requires that there is a clear causal ordering among the transitions taken in a step. It requires that no transition t relies for its activation on events generated by transitions appearing later than t in the causal ordering. In the used semantics a set of events trigger the next step of the statechart. To express priorities of responses, which is standard for real-time and reactive systems, negation is used. In the UML events are processed one at a time. Thus a priorization of events triggering a step in not necessary. Global consistency requires that not only the sequence of transitions taken in a micro steps is locally consistent but also the whole step to be consistent. This is, for example, violated if a transition in one micro step requires an event not to be present while a in a subsequent micro step a transition requires the same event to be present. Since we do not consider micro steps in our semantics definition we do not need to regard this.
Interactive Verification of UML State Machines [BBK+ 04]. In the first part of the paper the authors present a formal operational semantics of UML state machines which is used in an interactive formal verification process. The formalization supports the main features of state machines and, among others, a rich action language. The semantics definitions are alike to our semantics. By contrast a step of a state machine is described in a different way. Here, all (compound) transitions of a step are executed simultaneously, while first deactivating all states to be left during the step in an inside-out manner (including the execution of all exit actions), and, after gathering and executing the effect of the step, all states to be entered are activated in an outside-in manner (including the execution of all entry actions) and the completion events are generated. But neither a detailed definition of a strategy to leave and enter states is given, nor a conflict resolution strategy, arising when firing a set of transitions. Due to the (inherent) non-determinism of state machines different strategies are imaginable. Finally the definition of the set of states to be entered seems to be wrong, since it refers to the current configuration which
19
does not offer all information needed to calculate this set.
References [BBK+ 04] M. Balser, S. B¨ aumler, A. Knapp, W. Reif, and A. Thums. Interactive Verification of UML State Machines. In J. Davies, W. Schulte, and M. Barnett, editors, Formal Engineering Methods (ICFEM’04), LNCS 3308, pages 434– 448. Springer, 2004. [Har87]
D. Harel. Statecharts: A Visual Formulation for Complex Systems. Science of Computer Programming, 8(3):231–274, 1987.
[HG97]
D. Harel and E. Gery. Executable Object Modeling with Statecharts. IEEE Computer, 30(7):31–42, 1997.
[HN96]
D. Harel and A. Naamad. The STATEMATE Semantics of Statecharts. ACM Transactions on Software Engineering and Methodology, 5(4):293–333, 1996.
[LMM99a] D. Latella, I. Majzik, and M. Massink. Automatic Verification of a Behavioural Subset of UML Statechart Diagrams Using the SPIN Model-checker. Formal Aspects of Computing, 11(6):637–664, 1999. [LMM99b] D. Latella, I. Majzik, and M. Massink. Towards a Formal Operational Semantics of UML Statechart Diagrams. In Formal Methods for Open Object-Based Distributed Systems (FMOODS’99), page 465. Kluwer, 1999. [LP99a]
J. Lilius and I. P. Paltor. Formalising UML State Machines for Model Checking. In R. France and B. Rumpe, editors, The Unified Modeling Language (UML’99), LNCS 1723, pages 430–445. Springer, 1999.
[LP99b]
J. Lilius and I. P. Porres. The Semantics of UML State Machines. Technical Report TUCS-TR-273, Turku Centre for Computer Science, Finland, 1999.
[PS91]
A. Pnueli and M. Shalev. What is in a Step: On the Semantics of Statecharts. In Theoretical Aspects of Computer Software (TACS’91), pages 244– 264. Springer, 1991.
[PST91]
B. Potter, J. Sinclair, and D. Till. An Introduction to Formal Specification and Z. Prentice-Hall, 1991.
[Spi92]
M. Spivey. The Z Notation: A Reference Manual. Prentice Hall, 2nd edition, 1992.
[UML04]
The Unified Modeling Language 2.0: Superstructure FTF convenience document (ptc/04-10-02). Object Management Group, 2004. www.uml.org.
[VdB94]
M. Von der Beeck. A comparison of statecharts variants. j-LECT-NOTESCOMP-SCI, 863:128–148, 1994.
[WD96]
J. Woodcock and J. Davies. Using Z. Specification, Refinement, and Proof. Prentice-Hall, 1996.
[Z00]
International Organisation for Standardization. Information technology — Z Formal Specification Notation — Syntax, Type System and Semantics, 2000. Reference number: ISO/IEC 13568:2002.
20
