On Requirements Verification for ModelRefinements

Carlo Ghezzi∗, Claudio Menghi∗, Amir Molzam Sharifloo∗, and Paola Spoletini†∗ DeepSE Research Group,

Dipartimento di Elettronica e Informazione,Politecnico di Milano, Italy

{ghezzi,menghi,molzam}@elet.polimi.it† Universita dell’Insubria, Varese, Italy

paola.spoletini@uninsubria.it

Abstract—Conventional formal verification techniques rely onthe assumption that a system’s specification is completely avail-able so that the analysis can say whether or not a set of propertieswill be satisfied. On the contrary, modern development lifecyclescall for agile—incremental and iterative—approaches to tamethe boosting complexity of modern software systems and reducedevelopment risks. We focus here on requirements verificationperformed in the early exploratory stages on high-level modelsand we discuss how this can be integrated into an agile approach.We present a new technique to model-check incomplete high-levelspecifications against formally specified requirements. We do thisin the context of incomplete hierarchical Statecharts, verifiedagainst a variation of CTL properties. Our approach supportsstep-wise specification and refinement verification. Verificationcan be incremental, that is alternative refinements may beseparately explored and verification is only replayed for themodified parts. The results are presented by introducing theformalisms, the model-checking algorithm, and the tool we haveimplemented.

Index Terms—Software Modeling, Statecharts, Agile Develop-ment, Formal Verification, Model Checking, Incremental Verifi-cation.

I. INTRODUCTION

Modern software systems are often developed in an agilefashion, through different iterations and increments leadingto new releases that add features to an existing system.Development approaches of this kind aim at taming theboosting complexity of modern software systems and reducedevelopment risks.

Formal verification via model checking is a rigorous ap-proach to assuring that certain properties hold for the systemunder development. The main idea is to explore the statespace of a program or operational model, and ensure thatthe properties of interest are satisfied by considering allpossible behaviors. In this work, we are interested in thepossible use of model checking when high-level models ofthe system are built to explore possible alternative designs andthe impact of the different alternatives on the satisfaction ofsystem requirements has to be assessed. Specifically, we wishto support a stepwise development of models and separateverification of the refinement steps.

Although there have been surprising improvements that ledto the development of efficient model checkers, the avail-

able mainstream techniques are not directly applicable toincomplete and evolving specifications in which some partsmay change over time. They require that the system to beverified should be fully specified. Moreover, after any change,the verification has to be performed from scratch, withoutleveraging any previous verification knowledge. Because veri-fication techniques are expensive in terms of time and resourceusage and complexity explodes quite rapidly, the developmentof incremental verification approaches becomes crucial forthe adoption of formal verification into practical softwaredevelopment, especially in an iterative context.

In this paper, we present AGAVE, an agile verificationenvironment that enables developers to use model checkingas they refine their models. The methodology deals with in-complete specifications, where some parts are left unspecifiedand may later be further elaborated at development time, oreven may be left as components dynamically deployable atrun time. Following this approach, the verification not onlyis able to check whether or not a specification can satisfy agiven property but also generates a set of sub-properties forthe missing components to ensure satisfaction of the globalproperty. In the next iterations and when the developer isready to elaborate the missing components, one only needsto care about the sub-properties of the components and notthe system’s global properties. This is a great advantage thatsimplifies modeling, encourages exploration and verificationof alternative designs, supports decision making based onrigorous analysis, and drastically reduces the verification cost.AGAVE can be very useful to define the expected propertiesthat must be exhibited by off-the-shelf components (COTS) tobe hired from a third party, following a design by contractapproach [14].

AGAVE consists of an incremental process model throughwhich the verification is decomposed and performed in it-erative steps. To take the advantage from this approach, wedecided to apply AGAVE to Statecharts. This paper explainshow the Statecharts language can be equipped with incre-mental verification by providing a model-checking algorithm.Our model-checking algorithm is an evolution of LOVER, ourprevious initial exploration of iterative refinement verifications,

978-1-4673-5765-4/13/$31.00 c© 2013 IEEE RE 2013, Rio de Janeiro, BrasilResearch Track

62

which was done in the simpler context of models described aslabeled transition systems [22].

The paper is organized as follows. Section II presents anoverview of the proposed approach. Modeling formalisms aregiven in Section III. Section IV explains how the verificationprocedure works, which is followed with our running examplein Section V. Section VI reports on the implementation ofthe approach, and provides some experimental results on theperformance concerns. Section VII summarizes the relatedwork exisiting in the literature. Finally, the conclusion andfuture work are presented in Section VIII.

II. AN OVERVIEW ON THE APPROACH

Incremental development consists of a series of develop-ments of partial (incomplete) system models, where additionaldetails are progressively added. A typical way is to progressthrough subsequent refinement steps, which allow engineers todevelop a complete and detailed system model starting from ahigh-level abstract model and progressing through refinementswhere a more detailed structure is given, down to the desiredlevel of detail.

Formal verification normally requires a complete specifica-tion. In an incremental setting, this means that verification canonly be performed in the last stage of development, when theentire formal model is given. Moreover, if we want to explorethe effect of different choices at different development stages,the entire verification must be replayed, even though onlylimited portions of the model were affected by the changes.

The AGAVE methodology is intended to support the it-erative and incremental development of system models, byproviding an analysis method that can be applied incrementallywhile the model is built. The overall idea is to use a state-basedmodeling formalism to specify the system and to proceed withincremental steps. First, the system is represented as a modelM , in which all its most significant components and theirinteractions are represented. Together with the system, theset Φ of properties the system under analysis should meetare specified. At this stage, the components that need to befurther detailed are represented as simple states, marked witha T to indicate that they will be specified later with a state-based model as well1. Then model M is verified against eachproperty in Φ. This form of delayed and separate specificationcan be used to support both progressive knowledge acquisitionand also to manage the separate exploration of possible designalternatives.

If a system is fully specified, verification either succeedsor it fails. However if it contains unspecified components,it generate a set of properties that they must satisfy to getthe property holds in the whole system. This way, oncethese components are specified, the verification algorithm doesnot check again the whole specification, but just their newspecifiecation against the properties previously generated. Thisprocedure is recursively repeated every time an unspecifiedstate is refined.

1Since a state can represent both a system state and a component, in thepaper we will use states and components as synonyms.

The overall approach is exemplified in Figure 1. The level 1of model M is verified against a high-level requirementformalized by a property ϕ. M includes two unspecified com-ponents C1 and C2. As a result of verification, the algorithmproduces a set of properties that have to be satisfied by C1

and C2. In the second step, once C1 and C2 are specified,their models are checked against the properties derived in theprevious step. Notice that, while in the figure it seems thata single property is derived for each component, the set maycontain more than one property for each state. At level 2,the model that refines C2 does not contain any unspecifiedcomponents, and hence it is verified by classic model-checkingtechniques, while the model that refines C1 is analyzed by ap-plying the AGAVE approach, which computes the propertiesthat must be satisfied by the model that eventually will refinethe unspecified state C11.

Derived property P2 Derived property P1

C2C1

II. AN OVERVIEW ON THE APPROACH

In general, the design phase consists in a series of subse-quent refinement steps, that allows the designer to model thesystem starting from an high level of abstraction, in which ageneral structure of the model is given, to the a level ofdetail, that describes the behavior of all the componentsof the system. If a verification technique is used duringthe design, this incremental approach requires to verify thesystem every time a new component is specified or to applyan assume-guarantee method [?], that need the designerto add assumption to its system. Both the approach areinconvenient: the first can be extremely expensive in termsof time and the second can be unfeasible in this contextsince the different components are not know at each levelof refinement.

To cope with these limitations, we propose XXX, amethodology for supporting the design phase of complexsystems, by providing an analysis method that can be appliedincrementally while the model is built.

EG('1 ) '2)Outline• Incremental modeling consists in specifying systems

refining them with subsequent steps of refinement (ateach step the introduced components are unknown andnot detailed)

• Our proposal is an approach to incremental modelingand verifying systems. The approach consists on model-ing a level of abstraction identifying those componentsthat need to be further specified (transparent states).Then the model is checked with a modified modelchecking algorithm (LOVER) that check the modelagainst a property, generating the properties that thetransparent states must satisfied for the original prop-erty to be true in the model. This process is repeatedon the model of the transparent states (once theyare specified) against the properties generated in theprevious step. If the model contains transparent state,new constraints, that will be checked on the model,once it is specified.

• advantages from the modeling point of view (differentlevels of abstraction help to focus to the big picture butalso to the details) and from the verification point ofview (more efficient, no need to re-run the verificationon the flat model at each refinement)

• formalisms used: statechart and CTL (explain whystatechart is suitable for incremental verification)

• generalization: analogously to what happen for incre-mental modeling, when an adaptive systems is specifiedsome components are unknown and are known only atruntime

• further generalization: verification of statechart (hierar-chical state are seen as transparent and the verificationbecomes more efficient).

III. MODELING FORMALISMS

A. Statecharts

Statechart is a structured graphical formalism used todescribe reactive systems, such as communication protocols,digital control unit and aboard software systems. Statechartsextend finite state machines considering hierarchy, concur-rency, and communication, that allow the designer to modelcomplex systems in a more compact way. In particular,hierarchy is used to model the system at different level ofgranularity by redefining states through a (sub)statechart orthe composition of (sub)statecharts. Concurrency describesthe possible parallel behaviors of two or more statechartsrunning in parallel at the same time; such behaviors aresynchronized through communication.

In this paper, we consider the original definition of Stat-echarts which includes its most popular features, ignoringsome elements, such as time actions, history, special events(e.g., events generated when a state is entered or exited) andspecial actions (e.g., start action, history clear, deep clear)1.

Figure 1. Statechart example

B. Syntax

Given a set of atomic propositions AP , the two subsetsE and I partition it. They represent the environmental andinternal propositions, respectively. Intuitively, If a system isdefined over AP , E are propositions of which the truth valuecannot be controlled, while E are controlled. A condition cover I is defined as c ! i | ¬c | c ^ c, while anaction a has the form a ! i = 0 | i = 1 | neg(i),where i 2 I and neg is an operator that negate the truthvalue of i. C and A are a fine set of conditions and ofactions over I , respectively. Formally, a statechart is a tupleS = hQ, Q0, St, ⇢,E ,C ,A, ⌧i, where

• Q is a finite set of states that can be themselvesStatecharts, often call chart-states [9];

• ⇢2 is the hierarchical relation, used to decompose statesinto sub-states;

1[Paola: because . . .]2[Paola: Ho do you define it? ✓ Q ⇥ }(S)? How the relation specify

the kind of hierarchy? Moreover the set of sub charts should be part of thetuple... am I wrong?]

C11

YES NO

……..……..

Level 1

Level 2

Level 3

Original property P

Developer

Developer Developer

Developer

Fig. 1. An overview of the AGAVE methodology.

AGAVE provides advantages both from the modeling andthe verification viewpoints. Indeed, from the modeling aspect,working at different abstraction levels helps progressivelydelving into details that need to be explored. Concerningverification, AGAVE supports dealing with incremental ver-ification. Alternative refinements can be separately verifiedwithout flattening the entire specification and completely re-analyzing it, even if a change has only been made in refinementstep.

The AGAVE methodology is conceptually independentof the details of the specific state-machine based modelingformalisms and property languages. To be practically usableand effective, however, AGAVE is further developed forStatecharts and Path-qCTL property language.

Statecharts [9] are a structured graphical formalism used todescribe reactive systems, such as communication protocols,digital control units, and software systems. It is a state-basedformalism that is well-suited for incremental modeling, due

63

to its hierarchical structure. Path-qCTL is a temporal logiclanguage obtained by adding a temporal operator, which allowsto predicate on finite sequences of atomic propositions, toqualitative CTL (qCTL) [23]. qCTL, in turn, is a proper subsetof CTL, which does not include the Next operator.

The idea is that the input Statechart model is preprocessedand all the composite states, i.e. the state that representthemselves a Statechart, are seen as transparent, ignoring thatthey are already present in the model. AGAVE is appliedon the transformed model and this process is recursively re-iterated on the Statecharts using the properties derived byAGAVE in the previous steps. The iterative process terminateswhen the verification is performed on all the composite states.

Similarly to what happens in incremental modeling, inwhich the details of some components are known only in asecond stage, when an adaptive system [15], [2] is specifiedsome components are unknown and become known only atruntime. This suggests that AGAVE can be adopted also insuch cases, in which the derived properties are then verifiedat run time.

III. MODELING FORMALISMS

In this section we introduce the main formalisms used inAGAVE: the modeling language Statecharts, used to incre-mentally specify the system, and the temporal logic Path-qCTL, used to express the requirements to be checked for thesystem in the verification phase.

A. Statecharts

Statecharts are an extension of finite state machines, en-riched with hierarchy and concurrency. The former is used tomodel the system at different levels of abstraction by refiningstates through a sub-Statechart or the composition of sub-Statecharts. The latter supports the definition of two or moreStatecharts running in parallel, synchronized through the use ofglobal controlled variables. Given their structured and parallelnature, Statecharts are a suitable tool for modeling complexsystems in a compact way.

Since the original work by Harel [9], which introduced Stat-echarts informally, the increasing popularity of the formalismover the years prompted different definitions of the semanticsand proposals for extensions [10], [12], [13]. In this paper,we consider the basic elements of the original definition ofStatecharts which include its most popular features, ignoringtime actions, history, special events (e.g., events generatedwhen a state is entered or exited) and special actions (e.g.,start action, history clear, deep clear) and we refer to theSTATEMATE semantics, proposed by Harel [10]. Notice thatour methodology can be easily adapted for any other seman-tics. In the following, we summarize the needed definitions,introducing the notation that will be used in the rest of thepaper.

Before formally introducing Statecharts, some preliminarydefinitions are needed. Given a set of atomic proposition

AP , a condition c and an action a, over AP , are defined,respectively, as

c → p | ¬c | c ∧ c,a → p = false | p = true | neg(i),

where p ∈ AP and neg is an operator that negates the truthvalue of p. C(AP ) and A(AP ) are the set of conditions andactions over AP , respectively.AP is, in general, partitioned in two subsets: E, represent-

ing events, and I , representing the internal controlled proposi-tions of the system i.e., AP = E ∪ I and E ∩ I = ∅. A Stat-echart over AP is defined as a tuple S = 〈Q, q0, qF , St, ρ, τ〉,where• Q is a finite set of states that can be themselves State-

charts, also called chart-states [27];• q0 ∈ Q is the initial state;• qF ∈ Q is the final state;• St is a finite set of Statecharts;• ρ ⊆ (Q−{q0, qF })×{AND,OR}×℘(St) is the hierar-

chical relation, used to decompose states into sub-states(℘(St) denotes the power set of St). More precisely, eachstate of S can be decomposed through an and- or an or-decomposition of one or more Statecharts;

• τ : (Q−{qF })×E×C(I)→ (Q−{q0})×A(I) is thetransition relation that associates a triple composed of astate in Q, an event e ∈ E, and a condition c over I witha pair composed of a state in Q and an action over I .Each transition is represented by a directed arc betweenstates and is labeled with an ECA rule (event, condition,and action—these will be defined below).

Given a state q ∈ Q and a ρ-related Statechart s ∈ St, q iscalled parent of s (and of the states in s), and s is the childof q. The ρ-related Statechart is also called a sub-Statechart.States that are not ρ-related with any Statecharts are calledbasic states, and all the others are called composite. As definedin the ρ relation, composite states can be refined into and-or or-decomposition of Statecharts. The root states are thosestates that belong to a Statechart with no parents; they can besimple or composite. By definition, initial and final states arebasic and they do not have incoming and outgoing transitions,respectively. The former is often represented as a simple largedot and the latter as an encircled dot.

A Statechart transition is labeled with an ECA rule, definedas a triple: event e, condition c, action a. The event e is anelement of the set E ⊆ AP , and represents an environmentalproposition that has to be true to enable the transition tofire. Since elements in E are events, they are true only whenexplicitly indicated, and their truth value cannot be controlled.The condition c and the action a are elements of C(I) andA(I), respectively, and are built as defined above. Informally,c is a boolean expression on propositions in I ∈ AP , whichas to be true for the transition to be enabled, and a representsthe set of changes actuated if the transition is performed. Asa shortcut in the graphical notation, either the event or thecondition, as well as the action can be missing.

64

Basically, Statecharts are finite state automata, in which theexecution starts from the initial state by firing a transition.Transitions are triggered by an event and are guarded by acondition on the internal propositions. Once a transition toa new state is executed, the action indicated on the firedtransition is performed, modifying the values of some internalproposition.

The composite states represent the components that arehierarchically specified through decomposition. If the currentstate s is or-decomposed, being in s means being in one ofthe states of the refining sub-Statechart. In addition, outgoingtransitions from s become active only when the execution ofthe sub-Statechart is over; that is, it has reached its final state.If the state s is and-decomposed state, s is refined by a setof two or more sub-Statecharts, that become active when s isthe current state. Similarly to the case of or-decomposition,outgoing transitions from s become active only when all thesub-Statecharts in the decomposition have reached their finalstate.

More formally, the STATEMATE semantics describes thebehavior of a system as a sequence of configurations. Aconfiguration c describes a snapshot of the system (i.e., thecurrent state(s), the values of the internal variables, and theactive events). Since the current state may be a compositestate, the configuration should also include the configurationof the executing sub-Statecharts. Formally, the set cs of activestates must satisfy the following rules:

• cs must contain the root state of the Statechart thatcontains the current basic state(s);

• If cs contains an or-decomposition, it must also containexactly one state of the sub-Statechart 2;

• If cs contains an and-decomposition, it must also containone state for each sub-Statechart;

The initial configuration c0 contains the initial state q0 asactive state and the initial values of the internal propositionsare all set to false, if they are not explicitly initialized.

If the system configuration is c, the system may evolve byfiring a transition. A transition is triggered by an external eventand by the satisfaction of its condition. All the transitions out-going the set of basic current states in the current configurationare executable once triggered. As for the transitions outgoinga composite current state, we need to distinguish between thecase of an or-decomposition or an and-decomposition. In theformer case, the outgoing transition from the composite statecan be executed only if the sub-Statechart is in the final state.In the latter case, it can be executed only if all sub-Statechartsare in a final state.

Moreover, the STATEMATE semantics regulates the se-quence of configurations following these assumptions:

• The changes that occur during a transition can be sensedonly after its completion. This means that if an action a isperformed during the transition between configuration n

2According to STATEMATE, or-decomposition has an exclusive seman-tics.

and configuration n+1, the result of the action is visiblein configuration n+ 1.

• The occurrence of an event is visible only for the durationof the transition in which it happens. If an event e occursin configuration n and causes a transition to configurationn+1, the event is no longer visible in configuration n+1.

• In each configuration a maximal subset of non-conflictingtransitions is always executed, i.e., given the currentconfiguration, the maximal number of enabled transitionsis fired.

B. Path-qCTL

Path-qCTL is a qualitative computational temporal logic,obtained by adding to qualitative CTL (qCTL) a temporaloperator that allows to predicate also on finite sequences ofevents. qCTL is a simplified version of CTL that does notinclude the Next operator.

The syntax of the language is formally defined as follows:

φ→ φ ∧ φ | ¬φ | E φ U φ | E G φ | Ep G φ | p

where p ∈ AP (defined above), EU and EG are the CTLoperators, whose semantics is briefly recalled below, and EpGis a new temporal operator, that indicates that its argumentholds at least in a possible scenario starting from the presentuntil the end of the system behavior, i.e, the final state.Informally, the path quantifiers E and Ep mean “exists apath” and “exists a path form the initial to the final state”,while the temporal operators U and G stand for “until” and“always”. Notice that, as in CTL, each path quantifier has tobe associated with a temporal operator and vice versa.

Path-qCTL’s semantics should be formally defined by show-ing how to interpret formulae over the states and paths ofa Statechart. For space reasons, hereafter we just describe itinformally. Given a state s of the Statechart, the evaluationof the formula E ϕ1 U ϕ2 is true if there exists a pathfrom s where in a later state s′ ϕ2 holds and ϕ1 holds forall the previous states of the initial finite prefix. Note that theformula is true if ϕ2 holds in the initial state of the path. Theformula EG ϕ is true if there exists an infinite path froms where ϕ is always true. The formula EpG ϕ is true ifthere exists a (finite) path ending in the final state where ϕ isalways true; hence, it is a special case of EG. The classicalboolean connectives (∨,⇒ and⇔) and the temporal operatorsAU , AG, EF , and AF can be derived as abbreviation fromthe above sets of operators. Informally, the path quantifiersA means “for all paths” and the temporal operators F means“eventually”.

IV. VERIFICATION METHOD

This section describes how formally specified requirementscan be verified by AGAVE for system models describedthrough Statecharts. We discuss verification in the context ofan iterative and agile development style, where some states canbe temporarily left unspecified and where the designer canquickly explore alternative decompositions to evaluate their

65

possible impact on requirements satisfaction. We assume thatthe Statechart may contain basic states, composite states, andunspecified states, that are states whose internal structure iscurrently unknown and will be specified later. Composite andunknown states are called transparent. If a transparent state isrefined by a sub-Statechart, this is allowed to have transparentstates to support partial specification at all levels.

Together with the Statechart specification M , we provide aset of properties Φ expressed in Path-qCTL, which describethe requirements the specification is expected to satisfy. Mis verified against every ϕ ∈ Φ using the Algorithm 1. Theverification, however, may not yield a definite result (TRUEor FALSE), since the result may depend on the yet unknownbehavior of transparent states. In this case, the algorithmcalculates the set of constraints for the future refinement ofthe transparent states to guarantee the satisfaction of the initialproperty. The algorithm behaves in the same way for unknownand composite states, but in the latter case, the constraintsproduced by the algorithm, can be immediately checked onthe sub-Statechart. Hence, this technique allows the developernot only to verify partially specified systems, but also todeal efficiently with the verification of completely definedStatecharts, by splitting the verification in multiple levels.

This approach performs the exploration of possible differentrefinements efficiently in an incremental manner that onlyanalyzes the alternative refinements.

Algorithm 1 Statechart Verification1: function CHECK(M , ϕ)2: ilts = transformSC2Ilts(M )3: result = verify(ilts, ϕ)4: if result.isUnconditional() = T then5: return result;6: end if7: for (trans state,sub p) in extract(result.cons) do8: if trans state is composite then9: subSC = load subSc(trans state, M )

10: sub result = CHECK(subSC, sub p)11: if sub result.isUnconditional() = F then12: result = update(result, sub result)13: end if14: end if15: end for16: return result17: end function

Algorithm 1 works through a number of steps. First (line2), the model M, which represents a particular level of theStatechart, is translated into the equivalent labeled transitionsystem (ILTS). This ILTS is verified against the property ϕand the verification outcome is returned as result. If noconstraint is generated (result.isUnconditional equals true),the algorithm exits.

Otherwise, result.cons contains the set of constraints thatshall be satisfied by the unknown components to make theproperty hold, and the rest of the algorithm iteratively ex-

tracts and analyzes each of these constraints (line 7–15). Theconstraint (sub p) of each transparent state (trans state) ischecked by recursively invoking the same algorithm, feedingthe generated constraint and the corresponding StatechartsubSC. The verification result is updated and gradually com-pleted with the outcomes of these inner verifications.

A. Statecharts-to-ILTS Transformation

Hereafter, we discuss how to transform Statecharts (withtransparent states) into an equivalent ILTS representation.To do that, we first need to apply two preprocessing steps.The first step eliminates transparent states by mapping eachof them onto two basic states connected by an unlabeledtransition, similarly called transparent transition. A transparenttransition represents the internal behavior of the correspondingtransparent state. The set of incoming transitions that reach theoriginal transparent state are connected to the source state ofthe transparent transition, while the outgoing transitions departfrom the destination state, as shown in Figure 2.

... ...

S1

t i1

t i2

t ik

t o1

t o2

t ok

... ...

S 1

t i1

t i2

t ik

t o1

t o2

t ok

S 1

tt11 2

Fig. 2. Replacing transparent states with transparent transitions

The second preprocessing regards and states. and statesrefine a state into two or more sub-Statecharts that are executedin parallel. Our algorithm replaces these sub-Statecharts witha single Statechart whose set of states is the Cartesian productof the sets of states of the sub-Statecharts, and transitionsrepresent all possible interleavings. Transparent transitions inthe source Statecharts remain transparent also in the generatedtarget Statechart3.

At this point, we can generate an equivalent ILTS throughtwo basic steps: producing the graph and labeling the ILTSstates.

To produce the ILTS graph structure, each transition of theStatechart is transformed into an ILTS state. If the transition istransparent, the generated state is also transparent and labeledwith T . Since ILTS states represent transitions of the originalStatecharts, two states are connected in the ILTS only if thecorresponding transitions can be executed sequentially, oneafter the other, in the original Statechart. The algorithm alsocreates two additional ILTS states: the initial and the final one,respectively connected to all the ILTS states that representtransitions of the original Statechart connected to the initialand final state of the Statechart. Figure 3 shows a Statechart

3Further optimizations are possible, and will be described in future work.

66

fragment and the corresponding target ILTS structure (drawnwith dashed lines)4.

S1 S2

S3

S4

12t 23t

24t

Fig. 3. Transforming transitions into states

Once the structure is created, we need to perform the (pos-sibly incomplete) labeling of ILTS states. We recall that thelabels of ILTS states describe the set of propositions that aretrue in the states, if they are known. The labeling is performedaccording to the following procedure. First, each state inthe target ILTS is labeled with the events that trigger thecorresponding transition in the source Statechart. Concerningthe actions associated with a Statechart transition, since theycan modify the values of a set of atomic propositions, the onesthat are true are used to label the corresponding ILTS state (letus call it s).

At this stage, we need to perform further labeling of s, sincewe only took into account the actions, which tell us whichatomic propositions changed by performing the correspondingStatechart transition and this may obviously not include all thepropositions true in s. To complete the labeling, we also needto add the propositions in the previous states (the ones whoseoutgoing transitions lead to s) that must be propagated to sbecause they did not change during the transition. Notice that,in general, since a state may be reached with different paths,after the labeling, it may contain contradictory propositions(e.g., one may contain p and another ¬p). In this case, weneed to replace the state with the duplicate states s11 and s21,one including label with p and the other including ¬p. Thesuccessor states of s are then connected to s11 and s21 andpossible further propagation with state duplication may thenoccur.

Finally, we need to consider the case of an ILTS transparentstate st. For simplicity, let us first assume that the possiblerefinements of transparent states in the source Statechart donot modify the truth value of propositions. This assumptiondoes not mean that the transitions of the sub-Statechart cannotmodify such values, but just requires that after its completionthe propositions are set back to their initial values.

Let us further assume that there is only one ILTS state(si1), whose outgoing transition leads to the transparent ILTSstate st. Then, all the basic ILTS states so2, so3, . . . , son thatdirectly follow the transparent state st are labeled with theset of atomic propositions that are true in si1, with the obvi-ous exception of the propositions modified by the Statecharttransitions associated with the ILTS states so2, so3, . . . , son.

4Note that in the example, the initial and the final states are not createdsince they are not present in the original Statechart.

If we now consider the case when more than one ILTS state(si1, si2,. . . , sin) preceeds st, as for the non transparent ILTSstate, contradictory situations have to be considered. If forexample, si1, si2,. . . ,sin contain contradictory propositions,we need to duplicate st and handle this case similarly tothe propagation case described earlier. It is also possible torelax the first assumption, considering the case in which thetransparent transition can modify the value of some atomicproposition. To sketch the approach consider the case, wherea transparent ILTS state st, associated with the transparenttransition tt of the original Statechart and connected to thestate so2, can modify the value of the atomic proposition p.Then so2 is split in two states: s1o2 where p is true, and s2o2where p is false. This splitting is motivated by the need forconsidering all the possible value of p after the execution ofthe component in st, since this value is not a priori known.

After all states have been fully labeled, we need one finalstate to take into account the effect of the condition of theoriginal Statechart’s transitions. For each transition t of theoriginal Statechart, represented as a state in ILTS (s), wecheck the labeling of the previous ILTS states (say si1). If thislabeling is consistent with the condition of the transition t, thenthe connection between si1 and s is kept. If this is not the case,the connection is removed. If all the incoming connections toa state are removed, the state itself is also removed.

B. ILTS/Path-qCTL Verification

The model-checking algorithm verifies the Path-qCTL prop-erties against the ILTS previously generated. The Path-qCTLproperties could be the one derived by a previous step of theverification or the original stated in Φ. Notice that, even if theproperties in Φ were stated on the Statechart and not on theILTS, they do not need to be changed, since the paths on theILTS are equivalent to the possible sequences of configurationin the original Statechart.

The model-checking algorithm follows the steps of thestandard CTL algorithm, but differentiates between the regularand transparent states. First, the CTL formula is parsed andits parsing tree is derived. The leaves of this tree representthe set of atomic propositions, while the inner nodes connectthese propositions using boolean and temporal operators.

A bottom-up approach is applied to the tree to calculatethe satisfactory states for each sub-formula, starting from theleaves. For each node of the tree, the set of the states inwhich the sub-formula holds is calculated. However, due tothe existence of transparent states, we compute and attachconstraints to those states – regular or transparent – of whosesatisfaction depends on the behavior of transparent states. Wehave designed an algorithm to deal with each operator of qCTLformulae to tackle the transparent states and generate the con-straints step-by-step. The algorithm terminates by generatinga set of constraints for ILTS transparent states expressed asPath-qCTL formulas. 5.

5More details on the verification algorithm can be found in [22].

67

Because of the and-decomposition of Statecharts, that areresolved by performing the Cartesian product, and the du-plication caused by the splitting in the labeling procedure, atransparent state s in the original Statechart may be representedby different transparent states in the ILTS. In order to check thederived property for the transparent component on the correctelement, the algorithm must aggregate the constraints of theseILTS transparent states, generating a single constraint for theoriginal Statechart state s. Basically the aggregation consistsin a disjunction of the generated constraints, simplified byremoving the duplicated constraints.

V. RAILWAY CROSSING SYSTEM

In this section, we describe the application of our approachthrough an extension of the classic Railway Crossing System(RCS) [16]. The main goal of RCS is to control trains andgates, such that a train never crosses a gate when it is open(a high-level is shown in Fig. 4). This requirement is a safetyproperty, whose violation may lead to accidents.

There are three sensors (A, B, and C) placed on the trackto detect when a train approaches, crosses and leaves the gate.Another property that shall be satisfied is that the train cancross the gate only if it obtains permission from a centralauthority (”central station”). The central station manages therailway lines, and it has its own policies to regulate thedispatching of permissions. For example, if an emergencysituation is detected and the train is approaching, the centralstation will not give to the train the permission to cross, andthe train has to stop.

Sensor A Sensor B Sensor C

Fig. 4. Railway Crossing System

The high-level modeling of this system leads to the first-level Statechart in Figure 5, which consists of two concur-rent components: gate and train, which interact together viatransponders. The gate may be in one of two states s4 ands5. The gate can switch between these two states by actingon the variable open, and according to the modes of the train.If the train is switched to approaching mode, transition t4 isactivated and the gate can be closed. When the train returnsto traveling mode, transition t5 is activated and the gate canbe opened.

The train modes are represented by three boolean variables:traveling, approaching and crossing, which change as the threesensors are passed. At the beginning, the train is in travelingmode (state s1). When the train passes sensor A, event e1 isgenerated, and the train moves to approaching mode (state s2).Analogously, when sensor B is passed, it generates event e2and the train switches to crossing (state s3). This transition isperformed only when the gate is closed. Finally, when event e3

RCS

Train

s1

Gate

s2

s3

t1: e1[traveling]/approaching

¬traveling

t2:e2[approaching

¬open]/crossing

¬approaching

t3: e3[crossing]/

travelling¬crossing

s4

s5

t5: [traveling]/

open

t4: [approaching]/

¬open

s7

t6:[]/

askPermit

s9

t10:Timeout

[¬permit]/

t8:e4[]/

permit

Level 1

Level 2

t7:[]/

askPermit

s8t9:

[permit]/ackToCentralStation

e1: sensor A passede2: sensor B passede3: sensor C passede4: permission received from the central station

t11

T

Ts10

t11:e5[]/

failure

t12:[]/

¬failure

t13:[]/

alarm

Fig. 5. The Statecharts of RCS

is generated, the train has completely crossed the gate, and themode is changed back to traveling. State s2 is considered asa transparent state, since its refinement is postponed to nextmodeling phase. In fact, when the train starts approaching,different operations can be executed and different componentcan be activated.

In our case, the train, once approaching, must com-municate with the central station to receive the permis-sion before crossing the gate. This requirement can be ex-pressed by two Path-qCTL ϕa = AF (crossing) and ϕ′a =¬E(¬permit U crossing), where AF stands for all patheventually and EU stands for exists a path until. The former isa liveness property stating that in any case the train will crossthe gate, while the latter is a safety property stating that thereis no behavior in which the train crosses without receivingthe permission. Furthermore, we consider another reliabilityrequirement which guarantees that the system recovers fromany failure. This property can be expressed in Path-qCTL asϕb = ¬ EF (EG failure). Due to lack of space, we onlyfocus on ϕ′a and ϕb in the rest of the paper.

To reduce development risks and anticipate possible require-ments violations in an early development stage, we wouldlike to check if the high-level specification (though incom-plete) satisfies these requirements. The algorithm describedin the previous section transforms the first-level Statechartshown in Fig. 5, into the ILTS illustrated in Fig. 6. TheILTS is checked against the property ϕ′a and ϕb. The firstproperty leads to the following constraints for state s2: ϕ′a1 =¬E(¬permit U crossing) and ϕ′a2 = ¬(EpG(¬permit)).ϕ′a holds in the Statechart only if both of these constraintsare satisfied by a further refinement of s2. The verification ofthe second property ϕb = ¬ EF (EG failure) reproducesthe same property for s2, which means that its satisfaction isguaranteed if the property holds in s2.

State s2 represents a component that is in charge ofcontrolling the train when it is approaching. In the secondrefinement, s2 is elaborated as the second level of the behavior

68

S2

S2¬open,

approaching

¬open,approaching

open,approaching

open,traveling

open,traveling ¬open,

approaching

¬open,crossing

¬open,traveling

Fig. 6. The ILTS for the first refinement of the running example

shown in Fig. 5. First, the train requests the central stationfor permission to cross the gate (t6). If it is granted, evente4 is generated, and transition t8 is executed. The systemmoves to state s8, from which an acknowledge message issent to the central station (transition t9). Instead, if the centralstation does not grant the permission before a timeout, thesystem moves to the state s9, a transparent state that will belater refined. One may say that the train has to stop until thepermission is issued by the central station, but it could be aninvalid assumption. Thus the refinement is postponed to furtherrequirements elicitations.

Once the second level of the Statechart in Fig. 5 is specified,we check whether it satisfies the system requirements: ϕ′a andϕb. AGAVE does not check again the whole Statechart, butchecks only s2 against the derived constraints. The verificationof ϕ′a1 and ϕ′a2 against the corresponding ILTS of s2 (shown inFig. 76) results in reproducing respectively the same propertiesfor s9. ϕ′a requires both of these properties to be satisfied.On the contrary, the verification of the reliability propertyϕb = ¬ EF (EG failure) returns false because there isthe possibility that the system infinitely remains in the failuremode.

permit

S9 timeout¬permit,timeout

permit,ack

¬permit,askPermit

¬permit,failure

¬permit,failure,alarm

¬permit,¬failure

¬permit,askPermit

Fig. 7. The ILTS for the second refinement of the running example

6For the lack of space, only the labels that are relevant to the propertiesare shown.

VI. EXPERIMENTAL EVALUATION

AGAVE is supported by a prototype verification tool, as aJava standalone application 7. The tool takes as input two XMLfiles, one representing the model of the system (a Statechart)and one representing the property to verify (in Path-qCTL).The tool supports the syntax and semantics described inSection III, and follows the steps of the algorithm presentedin Section IV. The output of each verification task is either“true”, “false”, or “conditional”. In the conditional case, a setof constraints on transparent states is reported as well.

To grasp a better understanding of how the incrementalapproach is supported by AGAVE can reduce the verificationtime, we provide the result of an experiment. We assumed thatRCS example (Section V) is extended through more refinementsteps by providing specifications for each transparent state.We use the first level of the RCS Statechart introduced asrefinement at each stage.

All the experiments have been carried out on a machinewith the following characteristics: CPU 2.53GHz, RAM 4GB,and operating system Windows 7.

Figure 8 shows the total time required to verify the newmodels introduced at each refinement. To demonstrate theadvantage of the incremental approach, Figure 8 also showsthe time needed for the traditional verification (one may callintegrative), which considers the whole integrated specifi-cation at the end of each refinement. As the number of therefinement levels increases, the time of traditional approachrapidly grows (note that the scale is logarithmic). In particular,it reaches 1,93 minutes when a six-level Statechart is analyzed,while AGAVE requires only 328 milliseconds. The mainreason of this difference is that the traditional approach at eachstep verifies the whole integrated specification, while AGAVEonly checks the sub-Statecharts of the composite states againstthe constraints generated by the previous verifications (Figure9). Notice that our tool is a prototype and the result can beimproved by applying further optimizations, which will be thegoal of future work.

1!

10!

100!

1000!

10000!

100000!

1000000!

1 ! 2 ! 3 ! 4 ! 5 ! 6 !

Verifi

catio

n tim

e [m

s]!

Statechart Level!

AGAVE! Integrative Approach!

Fig. 8. The verification time required for each level of the Statechart

7Available at https://sites.google.com/site/amirsharifloo/tool-agave.

69

0!

100!

200!

300!

400!

500!

600!

1! 2! 3! 4! 5! 6!

Verifi

catio

n sp

ace !

[Num

ber o

f sta

tes]!

Statechart Level!

AGAVE! Integrative Approach!

Fig. 9. The number of states analyzed for each level of the Statechart

VII. RELATED WORK

Modeling evolvable specifications is studied by Sampathet al. [20], in which a new formalism called StructuredTransition Systems is presented to ease the evolutionary re-quirements modeling and refinement. On the contrary, weexploit the application of an existing formalism like Statechartsas a widely known formalism that comes with nice featuressupporting modularity and incremental refinement. Shaker etal. [21] propose a feature-oriented approach to specifyingthe requirements of Software Product Lines (SPL) in orderto facilitate the process of adding new features to existingspecifications. This way the specification of SPL is moreflexible to possible changes. However, the approach still lacksthe support for any analysis.

Analyzing models with unknown elements during devel-opment lifecycle has been studied in the past years. Salayet al. [18] addresses the problem of expressing uncertaintyin requirements specifications. In particular, they study thisproblem for early stage specification e.g. i* models and classdiagrams, and propose an approach grounded upon a previouswork on partial modeling [6], [19] to reason on the models.They describe how to construct partial models from possibledesign alternatives. The main idea is to annotate the elementsof models, that exist in only some of alternative, with Maybetags and then to apply SAT-based analysis techniques to checkFirst-Order Logic properties. The analysis output producesthree possible values: True, False, and Maybe.

Uchitel et al. [25] discuss how scenarios can be viewed aspartial models of system behaviors that can be incrementallyadded during the development iterations. Moreover, they de-scribe how to detect enabled, prescribed, and unknown systembehaviors by merging various system scenarios. Enabled be-haviors are the behaviors that system is supposed to perform,while the prescribed behaviors are prohibited. The unknownbehaviors do not violate any conditions but are not declaredand cannot be inferred from the specification. To specifysuch behaviors, PLTL (Partial LTL) is used to describe thesystem specification. In [24], the authors take a further step

by synthesizing scenarios and safety properties to constructbehavioral models in the form of Modal Transition Systems.

Bianculli et al. [3] present an approach to deriving for-bidden behaviors of external services given a requirementsspecification. More precisely, they use a behavioral model,that describes the set of traces that leads to error state, andgiven a set of external services and their fine-grain operations,they provide a heuristic technique to produce the behaviors,in terms of LTS, that external services shall avoid.

There have been many work addressing the verification ofStatecharts [5], [27], [16], [8]. However, to the best of ourknowledge, there is no work in the literature dealing withverification of incomplete specification of Statecharts. Zhaoand Krogh [27] discuss the verification of CTL properties byintroducing StateChart Kripke Structure as the underlying an-alyzable model that is derived from StateCharts. The states aremarked by considering the values of variables. The approachexplores all execution paths and applies MATLAB Simulinkfor the analysis.

There exist approaches to transform Statecharts to hierarchi-cal automata and then apply different verification techniques[5], [8]. Gnesi et al. [8] presents an approach through whichStatecharts are mapped on hierarchical automata and then amodel checking environment, called Jack, is used to checkACTL properties. Dong et al. [5], [26] transforms Statechartsinto Extended Hierarchical Automaton (EHA) to check Linear-time Temporal Logic (LTL) properties.

Clark et al. [4] present an approach to verifying Statechartsby using SMV. Although the approach uses the notion of mod-ules in SMV to have a straight-forward mapping, the analysisdoes not take into account any compositional and reusableverification. Alur and Yannakakis [1] study the verificationreuse of hierarchical state machines to avoid redoing the wholeverification when some state machines change. This approachhas similarities with our proposal in this paper (AGAVE);however, they take a bottom-up approach and calculate theverification results starting from the lately-specified compo-nents that show up at the end of refinements. On the contrary,AGAVE can be viewed as a kind of assume-guarantee method[11], [7], [17], applied to high-level models and incompleterefinements.

However, the existing assume-guarantee methods view asystem as a collection of cooperating components, each ofwhich has to guarantee certain properties. A component isverified independently from the others assuming a certainbehavior of the components it is interacting with [17]. Dif-ferently our approach considers the whole specification as thesystem behavior and employes the model-checking techniques,which produces constraints for unspecified components of thespecification through the development.

VIII. CONCLUSION

This paper presents AGAVE, a methodology that aims tosupport developers in the iterative and incremental systemspecification. AGAVE offers a technique to verify temporal

70

logic properties of incomplete models, expressed in state-based formalisms (e.g., Statecharts), where some parts areunspecified. These unspecified parts may be later refined andelaborated during the development or left as componentsdynamically deployable at run time.

The methodology exploits the hierarchy of the model,applying the verification iteratively. At each stage, a set ofproperties are deduced that have to be satisfied by the refine-ments to guarantee the satisfaction of the original property.AGAVE has been implemented for Statecharts and Path-qCTLtemporal logic. We have evaluated it through a case studyand demonstrated the benefits of such approach by performingstate space and performance analysis.

As for the future work, we plan to study a couple ofoptimizations both in the algorithms and implementation. Inparticular, alternative treatments for and-decomposition willbe investigated, since the naive cartesian product can be anoverhead for the approach. Furthermore, we aim at building aset of benchmark models to carry out a more comprehensiveperformance evaluation.

The natural extension of our work is to apply AGAVEto other modeling formalisms and property languages. Forexample, our approach can be of interest for different UMLdiagrams and stochastic models that are widely used in model-ing early requirements and system behaviour. Other temporalproperties such as LTL and PCTL are the first candidates inthis direction.

Moreover, we are exploring a symbolic implementation toreduce the verification time and memory demand.

ACKNOWLEDGMENT

We thank the reviewers for their constructive and use-ful comments. This paper is partially funded by the Euro-pean Commission, Programme IDEAS-ERC, Project 227977-SMScom.

REFERENCES

[1] R. Alur and M. Yannakakis. Model checking of hierarchical statemachines. ACM Transactions on Programming Languages and Systems(TOPLAS), 23(3):273–303, May 2001.

[2] L. Baresi, E. D. Nitto, and C. Ghezzi. Toward open-world software:Issue and challenges. Computer, 39(10):36–43, 2006.

[3] D. Bianculli, D. Giannakopoulou, and C. S. Pasareanu. Interfacedecomposition for service compositions. In Proceedings of the 33rdInternational Conference on Software Engineering (ICSE), pages 501–510, 2011.

[4] E. Clarke and W. Heinle. Modular translation of statecharts to smv. InTechnical Report CMU-CS-00-XXX Carnegie Mellon University Schoolof Computer Science, 2000.

[5] W. Dong, J. Wang, X. Qi, and Z.-C. Qi. Model checking uml statecharts.In Proceedings of the 8th Asia-Pacific Software Engineering Conference(APSEC), pages 363 – 370, dec. 2001.

[6] M. Famelis, R. Salay, and M. Chechik. Partial models: Towardsmodeling and reasoning with uncertainty. In Proceedings of the 34thInternational Conference on Software Engineering (ICSE), pages 573–583, june 2012.

[7] C. Flanagan and S. Qadeer. Assume-guarantee model checking. Tech-nical report, Microsft Research, 2003.

[8] S. Gnesi, D. Latella, and M. Massink. Model checking uml statechartdiagrams using jack. In Proceedings of the 4th IEEE InternationalSymposium on High-Assurance Systems Engineering, pages 46 –55,1999.

[9] D. Harel. Statecharts: a visual formalism for complex systems. Scienceof Computer Programming, 8(3):231 – 274, 1987.

[10] D. Harel and A. Naamad. The statemate semantics of statecharts.ACM Transactions on Software Engineering and Methodology (TOSEM),5(4):293–333, Oct. 1996.

[11] T. Henzinger, S. Qadeer, and S. Rajamani. You assume, we guarantee:Methodology and case studies. In Proceedings of the InternationalConference on Computer Aided Verification, volume 1427, pages 440–451. Springer Berlin / Heidelberg, 1998.

[12] D. Latella, I. Majzik, and M. Massink. Towards a formal operationalsemantics of uml statechart diagrams. In Proceedings of the 3rdInternational Conference on Formal Methods for Open Object-BasedDistributed Systems (FMOODS), pages 465–, 1999.

[13] F. Maraninchi. Operational and compositional semantics of synchronousautomaton compositions. In Proceedings of the International Conferenceon Concurrency Theory, pages 550–564. Springer-Verlag, 1992.

[14] B. Meyer. Applying ’design by contract’. Computer, 25(10):40–51,1992.

[15] P. Oreizy, M. M. Gorlick, R. N. Taylor, D. Heimbigner, G. Johnson,N. Medvidovic, A. Quilici, D. S. Rosenblum, and A. L. Wolf. Anarchitecture-based approach to self-adaptive software. IEEE IntelligentSystems, 14(3):54–62, May 1999.

[16] C. Prashanth and K. C. Shet. Efficient algorithms for verification of umlstatechart models. Journal of Software, 4(3):175–182, 2009.

[17] C. S. Pasareanu, M. B. Dwyer, and M. Huth. Assume-guarantee modelchecking of software: A comparative case study. In Proceedings of the5th and 6th International SPIN Workshops on Theoretical and PracticalAspects of SPIN Model Checking, pages 168–183, 1999.

[18] R. Salay, M. Chechik, and J. Horkoff. Managing requirements uncer-tainty with partial models. In Proceedings of the 20th IEEE InternationalRequirements Engineering Conference (RE), pages 1 –10, sept. 2012.

[19] R. Salay, M. Famelis, and M. Chechik. Language independent re-finement using partial modeling. In Proceedings of the 15th interna-tional conference on Fundamental Approaches to Software Engineering(FASE), pages 224–239, Berlin, Heidelberg, 2012. Springer-Verlag.

[20] P. Sampath, S. Arora, and S. Ramesh. Evolving specifications formally.In Proceedings of the 20th IEEE International Requirements Engineer-ing Conference (RE), pages 5–14, 2012.

[21] P. Shaker, J. Atlee, and S. Wang. A feature-oriented requirements mod-elling language. In Proceedings of the 20th International RequirementsEngineering Conference (RE), pages 151–160, 2012.

[22] A. M. Sharifloo and P. Spoletini. Lover: Light-weight formal verificationof adaptive systems at run time. In Proceedings of the 9th InternationalSymposium on Formal Aspects of Component Software, pages 170–187,2012.

[23] W. Thomas. Computation tree logic and regular -languages. In J. Bakker,W.-P. Roever, and G. Rozenberg, editors, Linear Time, Branching Timeand Partial Order in Logics and Models for Concurrency, volume 354of Lecture Notes in Computer Science, pages 690–713. Springer BerlinHeidelberg, 1989.

[24] S. Uchitel, G. Brunet, and M. Chechik. Synthesis of partial behaviormodels from properties and scenarios. IEEE Transactions on SoftwareEngineering, 35(3):384 –406, may-june 2009.

[25] S. Uchitel and M. Chechik. Merging partial behavioural models. InProceedings of the 12th ACM SIGSOFT twelfth international symposiumon Foundations of software engineering, SIGSOFT ’04/FSE-12, pages43–52, 2004.

[26] J. Wang, W. Dong, and Z.-C. Qi. Slicing hierarchical automata formodel checking uml statecharts. In Proceedings of the 4th InternationalConference on Formal Engineering Methods: Formal Methods andSoftware Engineering (ICFEM), pages 435–446. Springer-Verlag, 2002.

[27] Q. Zhao and B. H. Krogh. Formal verification of statecharts usingfinite-state model checkers. IEEE Transactions on Control SystemsTechnology, 14(5):943–950, 2006.

71