A Fully Automated Approach to Discovering Nondeterminism in State ...

2016 10th International Conference on the Quality of Information and Communications Technology

A Fully Automated Approach to Discovering Nondeterminism in State Machine Diagrams

Opeyemi O. Adesina, Timothy C. Lethbridge, Stéphane S. Somé School of Electrical Engineering and Computer Science University of Ottawa, 800 King Edward Avenue, ON K1N 6N5, Ottawa, Canada [email protected], [email protected], [email protected] potentially conflicting pairs of transitions, formally specify invariants based on these transitions, and analyze the resulting system to identify false positives (i.e. conflict-free pairs) and generate execution traces leading to nondeterminism (i.e. conflicting pairs). Various solutions have been reported to discover and manage nondeterminism. Heimdahl and Leveson [3] and Faghih and Day [7] developed automated approaches to discover and resolve nondeterminism. The shortcomings of these solutions include the inability to: 1) analyze infinite state systems, and 2) filter false positives among the set of conflicting transitions. A false positive is a pair of transitions conflicting statically but which is dynamically conflict-free. The latter means that in the global state-space there is no situation where both transitions execute simultaneously or their execution can be overridden by priority semantics [8]. The contributions of our work are to resolve these issues. In resolving conflicting transitions, false positives are rarely discussed, but ignoring them may have major consequences. For example, the simplest case involves a pair of transitions with the same source state but logically different guards whose evaluations never interfere during execution of the SUD. In particular, we say guards are logically the same whenever they evaluate to the same value (including overlaps). A complex case may involve an outgoing transition of a parallel region and an internal transition of another parallel region both within an orthogonal state and enabled simultaneously; but their destination states are reachable in the next micro-step. The discovery of these cases may be infeasible statically (most importantly when guard conditions involve infinite domains), so the system must be explored dynamically or analyzed formally. Eliminating any of these transitions prematurely may be expensive to fix or misinform the overall design. To simplify this paper, we limit discussion to a subset of state machines relevant to our work. We focus on the analysis of finite and infinite-state systems.

Abstract—We present a fully automated technique to detect nondeterminism in state diagrams. Although nondeterminism is a tool often adopted by requirement engineers for specification of a system under development (SUD), it is normally undesirable in actual implementation. Discovering nondeterminism manually is infeasible for industrial-sized systems. Solutions in the literature lack the capability to analyze infinite-state systems. We leverage the nuXmv model checker to analyze unbounded domains and implement an algorithm that systematically computes a minimal set of comparable transitions for the SUD yet eliminates false positives by model checking. To validate our approach, we analyze a real-world system and report discovered cases of nondeterminism. We employ Umple’s capability to convert state machines to nuXmv. Keywords-model-driven engineering; requirements; Umple; model checking; verification and validation; state machines.

I. INTRODUCTION We present an automated approach to detect nondeterminism in state diagrams. We transform state diagrams expressed in Umple [1] to nuXmv [2], compute a minimal set of conflicting transitions, and delegate analysis of the resulting system to the nuXmv model checker. The cost of correcting errors introduced at an early stage of design of real-world systems is huge compared to the cost of dealing with errors introduced at later stages [3]. Nondeterminism is a technique often adopted by requirement engineers for the purpose of understanding the SUD but may violate safety if shipped mistakenly in the actual implementation. Thus, discovering these flaws becomes critical. The increasing complexity of software systems makes such discovery infeasible when performed manually [4]. To minimize failures that may result from nondeterminism, requirements engineers must be supported by tools that match increasing complexity by increasing the use of abstraction with rigorous mathematical underpinnings. Model-Driven Engineering (MDE) [5] provides the necessary abstraction to represent components of software systems. We combine MDE with formal methods such that MDE provides necessary abstractions while formal methods provide well-founded theories. Our goal for the aspect we reported in this paper is to certify that state machines are free of nondeterminism. We use state machines expressed in Umple, which follows UML semantics (except for and-cross transitions which follow Harel’s state chart semantics [6]). We translate state machines to the input language of the nuXmv model checker [2], systematically compute a minimal set of

978-1-5090-3581-6/16 $31.00 © 2016 IEEE DOI 10.1109/QUATIC.2016.19

II.

BACKGROUND

We outline the technologies required to understand this work: Umple and nuXmv. Both have many more capabilities that we will not discuss. To ease readability of code in Listings 1, 2, simple state names are in green; composite state names are in red, and keywords are in blue. A. Umple Umple is a model-oriented programming technology for the development of real-world software systems. It supports model-code duality by representing software models as

73

Figure 1. Visual representation of the telephone dialing state machine

of top-level states, ∈ is the initial state (i.e. “waitForDial”), = { |1 ≤ ≤ 4} is a finite set of labels, is a finite set of variables (or attributes) and ⊆ × × defines a transition relation on . = {Dialing, Dialer, waitForDial, DialDigits, Let Redialer, waitForRedial, RedialDigits} be the universal set contains all the states of the model at of states of a SUA. any level. Let = |1 ≤ ≤ 7 be the set of all labels in the SUD and be the universal set of transitions of the SUD × × . such that ⊆ is a name and Let be a set of pairs 〈 , 〉, where ∈ is a type of a given variable ∈ (e.g. 〈 , 〉), such that = {integer, boolean, real}. We consider as a set of triples 〈 , , 〉, such that is a finite set of guards, is a finite set of nonparameterized environmental events, and is a finite set of actions. Let ∶ → , such that ∈ . is a partial function that map an element of to an event. We also define → such that ( , , ) = . : Given any state s ∈ S , we define a mapping function : → to map any given state, s to its number of direct sub-state machines; such that ∀ ∈ β(s) = 0, 1, n when s is simple (e.g. “RedialDigits”), nonorthogonal composite (e.g. “Redialer”) and orthogonal composite (e.g. “Dialing”) states respectively where n 1. We say is a simple state machine if and only if ( ) = 0 and it is hierarchical ∃ ∈ , such that ∀ ∈ β(s) ≥ 1 . To facilitate the specification of hierarchical structures, we introduce a binary relation ⊑ on , such that is the set of all sub-state machines (including the root). If , , ∈ then ⊑ specifies as a direct ancestor or a parent state machine of . ⊑ is the reflexive closure of ⊑ on W. Where ⊑ defines as a sub-state machine of , such that is ancestrally-related to . We introduce a such that ( ) = , partial mapping function ∶ → being the state corresponding to M. Hence, we say Z is a root state machine iff ( ) is undefined. On the other hand, for any nonroot state machine M , ( ) is defined. In particular, there can only be a sub-state machine if and only if being a set of states of state machine , ∃ ∈ , ( ) = and ⊑ . Recall that is an orthogonal state iff ( ) ≥ 2 . In essence, there are at least two sub-state machines for . We introduce the relation ⊑|| to define parallelism between any two orthogonal state machines, such ⊑|| iff ∃ ∈ , ( ) = ( ) = and ⊑ , ⊑ . We define a binary relation 〈∼, 〉 such that ∼ whenever is a direct

diagrams and also in a textual form structured just like common programming languages [1]. Umple allows developers to model dynamic views (e.g. state diagrams) of software systems and automatically generates code for languages such as Java, C++, Ruby, and Php. Umple achieves this by providing constructs and environments to express a rich subset of Unified Modeling Language (UML) [9]. In the following, we will discuss the formal syntax semantics of a subset of Umple state machines relevant to our work, since our goal is to discover truly conflicting transitions of state diagrams expressed in Umple. LISTING 1. PHONE DIALING STATE MACHINE IN UMPLE 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

class Telephone { Boolean dial_d, redial, out_d, dialDigitLp1, dialDigitPCplus1; Integer c, lp, d, p, lengthOfP; phoneDialingMachine { Dialing { Dialer { WaitForDial { [dial_d & !redial & c < 10] -> /{ c++; lp = lp * 10 + d; out_d = true; } WaitForDial; //t1 [dial_d & redial & c == 0] -> /{ lp = d; c = 1; out_d = true; } DialDigits;//t2 } DialDigits { [dial_d & c < 10] -> /{ c++; lp = lp * 10 + d; out_d = true; } DialDigits; //t3 [c == 10] -> WaitForDial; //t4 }} || Redialer { WaitForRedial { [redial & c == 0] -> /{ p = lp; dialDigitLp1 = true; } RedialDigits; //t5 } RedialDigits { [c < lengthOfP] -> /{ dialDigitPCplus1 = true; } RedialDigits;//t6 [c == lengthOfP] -> WaitForRedial; //t7 }}}}}

Listing 1 is a telephone dialing hierarchical state machine adapted from [10] but expressed textually in Umple. The equivalent visual representation of this state machine is presented in Figure 1. We associate a unique identifier with each transition and guard in Figure 1 to facilitate readers’ comprehension of Listing 2 (which shows the equivalent in nuXmv). Actions are omitted to facilitate comprehensive presentation. This state machine will be used to illustrate Umple constructs because it contains a subset relevant to our work. A state machine in Umple, say , is a 6-tuple 〈 , , , , , 〉 ; such that is the name (e.g. “…Dialer”), = {waitForDial, DialDigits} is a finite set 74

child sub-state of where is the universal set of states of and a transitive closure 〈≅, 〉 such the SUD, , ∈ that for a pair of elements , ∈ ≅ , implies is ancestrally related to . Let be the universal set of transitions of the SUD such that if is a root state machine, . Let , ⊆ × such that ( , ) and = ( , ) where , ⊆ defines set of from (source) and next (destination) states of respectively.

LISTING 2. PHONE DIALING TRANSITION SYSTEM IN NUXMV 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83

B. nuXmv nuXmv is a new symbolic model checking tool for the verification of fair finite- and infinite-state synchronous systems [2]. It is an extension of NuSMV [11]. nuXmv adopts the basic verification techniques of NuSMV and extends its native language with unbounded integer and real types for the specification of infinite domains. For the verification of the newly supported domains, it integrates Satisfiability Modulo Theories (SMT [12]) algorithms. Performance results show that nuXmv is highly competitive among model checking tools [2]. We summarize nuXmv input language (i.e. SMV) relevant to our discussion through Listing 2. An nuXmv model is a collection of at least one module. The “main” module (see lines 79-83 of Listing 2) is the entry point of execution of the nuXmv model. A module encapsulates a “body” and may have any number of formal parameters. A body of a module (see lines 2-52 of Listing 2) is composed from at least a module element. These elements are state variables, input variables, define declarations, assign constraints, invariance specification and so on. The state variables (e.g. lines 2-6 of Listing 2) can take values only from the domain of its type and the variables of enumerated types can take only values from the type specified during declaration. These variables are encapsulated by the "VAR" paragraph (see lines 2-6 of Listing 2). For the purpose of modularity and conciseness, a define declaration paragraph may be associated with a common expression. A variable declared in this paragraph can be seen as a macro. In essence, identifiers in this paragraph do not contribute to the state space of the SUA. A macro binds the identifier with the expression type and value on its righthand side. The paragraph must be preceded with the keyword “DEFINE” (see lines 7-20 of Listing 2). SMV allows assignment of values to state variables within an assign paragraph. In an assign paragraph (or constraint), a variable is assigned initial and next values with the keywords “init” (see line 22 of Listing 2) and “next” (see lines 23-26 of Listing 2) respectively. The “case” statement models the possible conditions (on the left hand side) and values (on the right hand side) to be assigned to the variable at any given step. To constrain the entire model to fulfil some special properties, SMV provides "INVARSPEC" keywords. For example, on lines 44-46 of Listing 2 a constraint stating that whenever transitions and executes simultaneously that in the next micro-step, dialer should assume "WaitForDial" and "DialDigits". The violation of such constraint will produce a counterexample. However, if there is no possibility of simultaneous executions of these transitions (e.g. different guard conditions) the engine returns TRUE.

75

MODULE PhoneDialingMachine( dialer, redialer ) VAR state : { Dialing , null }; event : { autotransition , null }; dial_d, redial, out_d, dialDigitLp1, dialDigitPCplus1 : boolean; c, lp, d, p, lengthOfP : integer; DEFINE sm_stable := !( event = autotransition ); t1 := event = autotransition & dialer.state = WaitForDial & g1; t2 := event = autotransition & dialer.state = WaitForDial & g2; ... t7 := event = autotransition & redialer.state = RedialDigits & g7; g1 := dial_d & !redial & c < 10; g2 := dial_d & redial & c = 0; g3 := dial_d & c < 10; g4 := c = 10; g5 := redial & c = 0; g6 := c < lengthOfP; g7 := c = lengthOfP; ASSIGN init( state ) := Dialing; next( state ) := case t4 | t3 | t5 | t1 | t2 | t7 | t6 : Dialing; TRUE : state; esac; init( event ) := null; next( event ) := case sm_stable : { autotransition }; TRUE : null; esac; init( dialDigitLp1 ) := FALSE; next( dialDigitLp1 ) := case t5 : TRUE; TRUE : dialDigitLp1; esac; ... init( lp ) := 0; next( lp ) := case t1 | t3 : lp * 10 + d; t2 : d; TRUE : lp; esac; INVARSPEC (t1 & t2 -> next(dialer.state = WaitForDial & dialer.state = DialDigits)) INVARSPEC (t3 & t4 -> next(dialer.state = DialDigits & dialer.state = WaitForDial)) INVARSPEC (t6 & t7 -> next(redialer.state = RedialDigits & redialer.state = WaitForRedial)) MODULE Dialer ( sm ) VAR state : { WaitForDial, DialDigits, null }; ASSIGN init( state ) := null; next( state ) := case sm.t1 | sm.t4 : WaitForDial; sm.t2 | sm.t3 : DialDigits; sm.state = Dialing & state = null : WaitForDial; TRUE : state; esac; MODULE Redialer ( sm ) VAR state : { WaitForRedial, RedialDigits, null }; ASSIGN init( state ) := null; next( state ) := case sm.t7 : WaitForRedial; sm.t5 | sm.t6 : RedialDigits; sm.t7 : WaitForRedial; sm.t5 | sm.t6 : RedialDigits; sm.state = Dialing & state = null : WaitForRedial; TRUE : state; esac; MODULE main VAR phoneDialingMachine : PhoneDialingMachine( dialer, redialer ); dialer : Dialer( phoneDialingMachine ); redialer : Redialer( phoneDialingMachine );

transition versus high-level transition. We illustrate these diagrammatically in Fig. 2. a) Physically-Same Source Transitions In Fig. 2, we present the notion of physically samesource transitions. In the example, associated with vertex are two outgoing edges , . may be simple or composite = . In state and edges , are transitions such that , this case, a pair 〈 , 〉 is added to the universal set of potentially conflicting transitions whenever the triggering events for both transitions are the same (i.e. ( ) = ( )).

III. OUR WORK We overview our approach to formulate algorithm for computing a minimal set of conflicting transitions. We present the two broad cases resulting in nondeterminism based on our approach. The following are the definitions of basic concepts to facilitate ease of understanding. Definition 1. Embedded Sub-State Given a composite state ∈ , a state such that ≅ is an embedded sub-state of s. This implies that there are substate machines X and such that ( ) = , with ∈ and ⊑ . Definition 2. High-Level Transition A transition is a high-level transition if defined on a composite state. Any high-level transition defined on a composite state, say (i.e. ( ) ≥ 1 ) such that , ( , ) ⟹ whenever ≅ . In other words, is executable in any of the embedded sub-states of s. Definition 3. And-Cross Transition Given an orthogonal composite state, say (i.e. ( ) ≥ 2) and M, N as two parallel sub-state machines of ( ( ) = ( ) = and ⊑|| ); O, P such that ⊑ ∧ ⊑ ; , embedded states such that ∈ , ∈ ; any transition t such that there are ( , ) , ( , ) with and is an and-cross transition. Definition 4. Embedded Transition Given a composite state, say such that is a nonempty set of embedded states of and ≅ , ∈ . Let be a be the finite set state machine such that s ∈ S and is an embedded transitions of . Then transition ∈ transition of iff ( ) = . Definition 5. Outgoing Transition Given an orthogonal state , such that ( ) ≥ 2 and an such embedded transition of . If there exist state ∈ that ( ) = and ≇ then is an outgoing transition of state . Definition 6. External Transition Given an orthogonal state , such that ∈ . If there exist parallel sub-state machines , such that ⊑|| ⊑ then transition is external to if and only if ( ) = such that ≅ and ∈ . Definition 7. State Machine Configuration A state machine configuration of is a triple ⊆ × × such that is the set of sub-state machines (including the root) forming , is a set of execution steps. Let there such that given be a mapping function : × → ( , ) = where is the state machine, ∈ and is the current state of m when 〈 , , 〉 is a configuration.

Figure 2. Logically same-source transition example

b) High-level transition versus embedded transition In Fig. 2, we present the notion of logically same-source transitions. In the example, associated with a composite state are two embedded states , (i.e. simple or composite). The outgoing edges , are embedded transitions of state . A high-level transition . In this case, pairs 〈 , 〉, 〈 , 〉 are added to the universal set of potentially conflicting transitions whenever the triggering events for transitions { : 1 ≤ ≤ 3} are the same (i.e. ( ) = ( ) = ( )). 2) Region-Cross Transitions In this category, we will discuss pairable transitions whose sources are embedded states of an orthogonal composite state. The notion of region-cross involves not only and-cross transitions but also outgoing transitions of the host orthogonal state. We illustrate these cases by example in the Fig. 3. a) And-cross transition versus external transition In Fig. 3, we present a case to illustrate the concept under discussion. Transition is an and-cross transition from region enclosed by state to the region enclosed by states , . The set of external transition to is set { , }. In this case, pairs 〈 , 〉, 〈 , 〉 are added to the universal set of potentially conflicting transitions whenever the triggering events for transitions , and are the same (i.e. ( ) = ( ) = ( )). b) Outgoing transition versus external transition

A. Cases of Nondeterminism We present two major categories of nondeterminism fundamental to our approach. These include same-source and region-cross transitions. We consider various kinds of state machine transitions (including those with overlapping guard conditions). 1) Same-Source Transitions In this category, we discuss pairable transitions whose sources are physically and logically the same. A physically same-source pair of transitions involves transitions originating from the same source states; while a logically same-source pair of transitions involves embedded

Figure 3. Region-cross transition example

In Fig. 3, transition is an outgoing transition for state . However, the source region of is enclosed by . Hence, transitions and are external to the region . In this case, pairs 〈 , 〉, 〈 , 〉 are added to the universal set of potentially conflicting transitions whenever the triggering

76

events for transitions , ( ) = ( ) = ( )).

and

Listing 3) then every element of the range is compared to an element of the domain. On the other hand, an element at index ' ' in the range is compared to element { | + 1 ≤ ≤| |} in the domain. To minimize duplication, we added a constraint that filters every entry such that pairs 〈 , 〉 ≡ 〈 , 〉 and pairs with same destination states are removed. In particular, pair 〈 , 〉 is added to the set of potentially conflicting transitions if and only if ( ) ≠ . On lines 36, 42 of 'Listing 3' we applied this constraint to prevent duplicate pairs in the pairable set ' '.

are the same (i.e.

B. The match-making algorithm We present the match-making algorithm (Listing 3) for the construction of potentially conflicting pairs of transitions for any given state machine (simple or hierarchical). Operators: (s), ( ), ∇( ), and ∆( ) define a finite set of embedded states, and-cross transitions, external transitions, and embedded transitions respectively for a given state . The input is an Umple state machine and the output is a finite set of pairs of potentially conflicting transitions. It systematically explores all the top-level states of the input state machine. This involves the extraction of embedded states of each top-level state (see lines 6-49 of Listing 3). The transitions under consideration are those in the parent state machine of the given state. For example, suppose ∈ such that is the parent state machine of then the transitions under consideration are those associated with . The match(...) procedure takes two sets (i.e. domain and range) as input and matches their elements. For example, suppose domain and range are not equivalent (see line 31 of

C. Discovering Nondeterminism We note that the resulting set of pairs are statically computed and may contain some false positives. Readers should note that the elimination of false positives in the pair of potentially conflicting transitions is practically infeasible statically. In particular, the problem of guard equivalence is undecidable whenever they involve infinite-state variables (i.e. integer and real). To deal with these issues, we transform an Umple state machine to SMV (see Listing 2) using UmpleOnline [13] and construct an invariant to constrain the overall model for every element of the resulting set of pairs of potentially conflicting transitions. These invariants are of the form: INVARSPEC (t & t → next( X(t ) & X t )) (1) The implication of (1) is that in the global state-space, whenever transitions , executes simultaneously the global configuration should be consistent with the next states of the transitions. A violation of any invariant implies the presence of nondeterminism and otherwise, the presence of false positives. The requirement engineer can analyze the counterexample for the purpose of diagnosis. For example, lines 44-52 of Listing 2 are invariant specifications for the pairs of transitions computed from the model presented in Figure 1. The resulting set includes pairs: 〈 , 〉, 〈 , 〉, 〈 , 〉. These are candidate pairs for nondeterminism computed statically. For example, elements of pair 〈 , 〉 differ by guard conditions. Hence, analysis shows that the pairs are false positives since there is no violation of any of the invariants. The results are straightforward and can be understood from Figure 1 just by analyzing the guards.

LISTING 3. THE MATCH-MAKING ALGORITHM 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

〉 Input: =〈 , , , , , 〈 〈 〉 〉 Output: = , Forall ∈ k = 0; embeddedStates = ( s ); // embedded states While k < | embeddedStates | outgoingEdges = ∅; state = embeddedStates.get( k ); H = state.getStateMachine(); If ( state ) == 0 //simple state Forall ∈ If F(t) == state outgoingEdges.add( t ); End-If End-Forall match(outgoingEdges,outgoingEdges,L) End-If If ( state ) >= 1 //composite state highLevelEdges = ∅; embeddedEdges = ∅; Forall ∈ If F(t) == state highLevelEdges.add( t ); End-If Forall e ∈ ∆( state )//embedded transition If F(e) == state embeddedEdges.add( e ); End-If End-Forall End-Forall match(highLevelEdges,embeddedEdges,L) If ( state ) > 1 //orthogonal states Forall ∈ ( state ) // and-cross trans Forall ∈ ( state ) //external trans If (t) == (x) and {〈 , 〉, 〈 , 〉} ∉ L and X(t) != X(x) L.add( 〈 , 〉 ) End-If End-Forall Forall ∈ highLevelEdges//external trans If (y) == (t) and {〈 , 〉, 〈 , 〉} ∉ L and X(t) != X(y) L.add( 〈 , 〉 ) End-If End-Forall End-Forall End-If End-If k++; End-While End-Forall Return L;

IV. INITIAL VALIDATION We present the case study of a heating system [14] to demonstrate how we can discover nondeterminism. Our choice is based on the following criteria: simple-tounderstand and characterized with finite and infinite domain variables, false positive and cases of nondeterminism. The system models behaviors of house and furnace subsystems executing concurrently. The house combines subsystems room and controller, both executing concurrently. There are three buttons: on, off, and reset. The controller coordinates all sub-systems via these buttons. The on and off buttons switch the entire system on and off. A system may be faulty or functional. A faulty system puts the controller in error mode. In this mode, whenever the user reset button is pressed the controller is turned off and the furnace is reset simultaneously. We model hierarchical state machine of this system with Umple (see [15]) and translate it to SMV using Umple2SMV [13]. Transition and guard labels can be displayed by selecting relevant options. We represent 77

not discover nor manage nondeterminism. STATEMATE [16] adopts case statement of the SMV [19] to resolve nondeterminism.

internally-generated events using Boolean variables, such that when the event is generated, the variable is assigned 'true'. Whenever the event is to be consumed by the system, we include it in the guard of the concerned transition. We used our algorithm to compute potentially conflicting pairs of transitions for the heating system. The universal set of transitions of the system is defined as | 1 ≤ ≤ 24 . For this analysis, we adopted the IC3 method implemented by the nuXmv model checker.

VI. CONCLUSION AND FUTURE WORK We presented our approach to discovering nondeterminism in finite- and infinite-state systems. Our algorithm computes a minimal set of potentially conflicting transitions. We observed the presence of false positives in the set of potentially conflicting transitions whose premature elimination may be difficult to fix or misinform the overall design. The analysis of a real-world system was presented to validate our work. Our long-term goal is to apply our approach to industrial-strength applications and improve Umple to automatically work with action statements and discover race conditions.

TABLE 1. ANALYSIS RESULT (T - TRUE, F– FALSE, C1.1 – PHYSICALLY SAME-SOURCE, C1.2 – HIGH-LEVEL VS. EMBEDDED TRANSITION). PAIRS 〈 , 〉 〈 , 〉 〈 , 〉 〈 , 〉 〈 , 〉 〈 , 〉 〈 , 〉

RESULT F T F T T T T

TYPE C1.1 C1.1 C1.1 C1.1 C1.1 C1.1 C1.1

PAIRS PAIRS 〈 , 〉 T 〈 , 〉 T 〈 , 〉 T 〈 , 〉 T 〈 , 〉 T 〈 , 〉 T 〈 , 〉 T

TYPE C1.1 C1.2 C1.1 C1.1 C1.1 C1.1 C1.1

REFERENCES

Table 1 presents results obtained by analyzing comparable pairs of transitions. These are real candidates of nondeterminism found in the model by our algorithm. The error rate of the algorithm is 0% and the model checker dynamically discovers the actual candidates. The 'T' cases correspond to the false positives and the 'F' cases correspond to actual nondeterminism in the case study. 100% of the pairs are same-source type of transitions. 7.15% are high level vs embedded and 92.86% are physically same-source transition pairs. The implication of this result is that only 14.29% are true positives and 85.71% are false positives.

[1] [2]

[3] [4] [5]

V. RELATED WORK Other approaches to analyze state diagrams for nondeterminism include BSML [7], RSML [3], STATEMATE [16], SCR [17] and SMUML[18]. BSML [7] detects conflicting transitions based on Esmaeisabzali's semantics framework with model checking. Transitions , can execute simultaneously whenever they are consistent with small-step consistency and pre-emption structural aspects. These are: any two simple transitions originating from a source; simple transitions with transitions in its source parts; Or-state cross transitions with the same source; and-cross transitions within a scope. Our work differs by flagging false. Similarly, a sub-state machine is handled as a black box, hence minimizing the total number of comparisons. RSML [3] discovers nondeterminism by statically analyzing the SUD based on functional composition, whose key concepts include union, serial and parallel composition. The union approach constrains the system so no two transitions of a simple state execute simultaneously; serial approach constrains SUD such that a transition generating an event executes before the transition consuming the event executes; the parallel approach focuses on simultaneous execution of pair wise orthogonal transitions. Guard conditions are evaluated using and/or tables. The limitations of this include: inability to track and-cross cases of nondeterminism; state-space explosion for complex conditions and infinite state domains; and inability to flag false positives. SMUML [18] facilitates the discovery of nondeterminism but the detail of its approach is not given. SCR [17] assumes that the SUD is deterministic, hence does

[6] [7] [8] [9] [10] [11] [12] [13]

[14] [15] [16] [17] [18] [19]

78

O. Badreddin, “A manifestation of model-code duality: facilitating the representation of state machines in the umple model-oriented programming language,” 2012. R. Cavada, A. Cimatti, M. Dorigatti, A. Griggio, A. Mariotti, A. Micheli, S. Mover, M. Roveri, and S. Tonetta, “The NUXMV Symbolic Model Checker,” 26th Int. Conference on Computer Aided Verification, 2014, pp. 334–342. M. P. E. Heimdahl and N. G. Leveson, “Completeness and consistency in hierarchical state-based requirements,” IEEE Trans. Softw. Eng., 22:6, pp. 363–377, 1996. O. Adesina, “Integrating formal methods with model-driven engineering,” 18th MODELS 2015 Doctoral Symposium, pp. 6–10. A. Rodrigues Da Silva, “Model-driven engineering: A survey supported by the unified conceptual model,” Comput. Lang. Syst. Struct., vol. 43, pp. 139–155, 2015. D. Harel, “Statecharts: A visual formalism for complex systems,” Sci. Comput. Program., 8:3, pp. 231–274, 1987. F. Faghih and N. A. Day, “Mapping Big-Step Modeling Languages to SMV,” Technical Report CS-2011-29, 2011. Omg, “OMG Unified Modeling Language: Version 2.5,” Document Number: ptc/2013-09-05, p. 786, 2013. J. Rambaugh, I. Jacobson, and G. Booch, Advanced Praise for The Unified Modeling Language Reference Manual, 2nd ed. Toronto: Addison-Wesley, 2004. S. Esmaeilsabzali, N. A. Day, J. M. Atlee, and J. Niu, “Deconstructing the semantics of big-step modelling languages,” Requir. Eng., 15:2, pp. 235–265, 2010. A. Cimatti, E. Clarke, and E. Giunchiglia, “Nusmv 2: An opensource tool for symbolic model checking,” Int. Conf. on Computer Aided Verification, 2002, vol. 2404, pp. 359–364. L. De Moura and N. Bjørner, “Satisfiability modulo theories: An appetizer,” LNCS 5902, pp. 23–36, 2009. CRUiSE, “UmpleOnline: Generate Java, C++, PHP, or Ruby from Umple code,” UmpleOnline: Generate Java, C++, PHP, or Ruby from Umple code, 2016. [Online]. Available: http://cruise.eecs.uottawa.ca/umpleonline/. Y. Lu, J. M. Atlee, N. A. Day, and J. Niu, “Model Checking Template-Semantics Specifications,” Technical Report: CS-2004-20 2004. CRUiSE, “The home heating system case study.”[Online]. Available: try.umple.org/?example=HomeHeater&diagramtype=state. E. M. Clarke and W. Heinle, “Modular translation of statecharts to SMV,” Technical Report: CMU-CS-00-XXX, 2000. C. L. Heitmeyer, R. D. Jeffords, and B. G. Labaw, “Automated consistency checking of requirements specifications,” ACM Trans. Softw. Eng. Methodol., 5:3, pp. 231–261, 1996. J. Dubrovin and T. Junttila, “Symbolic model checking of hierarchical UML state machines,” 8th Int. Conf. on Application of Concurrency to System Design, 2008, pp. 108–117. A. A. Mir, S. Balakrishnan, and S. Tahar, “Modeling and Verification of Embedded Systems Using Cadence SMV,” CCECE. 2000, vol. 1, pp. 179–183.