brics · submitted papers the programme committee selected 9 papers and 1 tool demonstration for...

167
BRICS NS-01-4 Brinksma & Tretmans (eds.): FATES’01 Proceedings BRICS Basic Research in Computer Science Proceedings of the Workshop on Formal Approaches to Testing of Software FATES’01 Aalborg, Denmark, August 25, 2001 Ed Brinksma Jan Tretmans (editors) BRICS Notes Series NS-01-4 ISSN 0909-3206 August 2001

Upload: others

Post on 06-Jul-2020

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

BR

ICS

NS

-01-4B

rinksma

&Tretm

ans(eds.):

FAT

ES

’01P

roceedings

BRICSBasic Research in Computer Science

Proceedings of the Workshop on

Formal Approaches to Testing of Software

FATES’01

Aalborg, Denmark, August 25, 2001

Ed BrinksmaJan Tretmans(editors)

BRICS Notes Series NS-01-4

ISSN 0909-3206 August 2001

Page 2: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Copyright c© 2001, Ed Brinksma & Jan Tretmans(editors).BRICS, Department of Computer ScienceUniversity of Aarhus. All rights reserved.

Reproduction of all or part of this workis permitted for educational or research useon condition that this copyright notice isincluded in any copy.

See back inner page for a list of recent BRICS Notes Series publications.Copies may be obtained by contacting:

BRICSDepartment of Computer ScienceUniversity of AarhusNy Munkegade, building 540DK–8000 Aarhus CDenmarkTelephone: +45 8942 3360Telefax: +45 8942 3255Internet: [email protected]

BRICS publications are in general accessible through the World WideWeb and anonymous FTP through these URLs:

http://www.brics.dkftp://ftp.brics.dkThis document in subdirectory NS/01/4/

Page 3: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Ed Brinksma and Jan Tretmans (Eds.)

Formal Approaches toTesting of Software

FATES’01A Satellite Workshop of CONCUR’01Aalborg, Denmark, August 25, 2001Proceedings

Page 4: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

ii

Page 5: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Preface

Testing is an important technique for validating and checking the correctness of soft-ware. However, effective and efficient testing turns out to be difficult, expensive, la-borious, error-prone and time consuming. Formal methods are a way of specifyingand verifying software systems by applying techniques from mathematics and logic.This enables the analysis of systems and the reasoning about them with mathematicalprecision and rigour. Formal methods and testing used to be a difficult combination.Formal methods aim at verifying and proving correctness, while testing can only showthe presence of errors. Validation in practice is most often performed by testing, whileacademic research was concentrated on formal verification.Recently, there is an increasing interest in the use of formal methods in software test-ing. It is recognized that formal methods and testing are complementary techniqueswhich can, and should be used in combination. The use of formal methods can helpin alleviating some of the challenges of software testing. In particular, a formal, andformally verified specification provides a more precise, more consistent and more com-plete starting point for the testing process and the obtained tests can be formally val-idated whether they test what should be tested. Moreover, the use of formal methodsallows automating the generation of tests from formal specifications, thus leading to afaster, cheaper and less error-prone testing process. And finally, formal testing turnsout to be a good starting point for introducing formal methods in software develop-ment.The aim of the workshop FATES — Formal Approaches to Testing of Software — is tobe a forum for researchers, developers and testers to present ideas about and discussthe use of formal methods in software testing. Topics of interest are formal test theory,test tools and applications of testing based on formal methods, including algorithmicgeneration of tests from formal specifications, test result analysis, test selection andcoverage computation based on formal models, and all of this based on different formalmethods, and applied in different application areas.

This volume contains the papers presented at FATES’01 which was held in Aalborg(Denmark) on August 25, 2001, as an affiliated workshop of CONCUR’01. Out of 18submitted papers the programme committee selected 9 papers and 1 tool demonstrationfor presentation at the workshop. Together with the keynote presentation by David Leefrom Bell Labs Research China they form the contents of these proceedings.The papers present different approaches to using formal methods in software testing.The main theme is the generation of an efficient and effective set of test cases froma formal description. Different formalisms are used as the starting point, such as fi-nite state machines, Z, Statecharts, SDL, constraint languages, grammars and timed

iii

Page 6: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

automata, and different algorithms are discussed for the generation process, rangingfrom formalization of the manual testing process to the (re)use of techniques frommodel checking.The papers give insight in what has been achieved in the area of software testing withformal methods. Besides, they give clear indications of what has to be done before wecan expect widespread use of formal techniques in software testing. The prospects forusing formal methods to improve the quality and reduce the cost of software testing aregood, but still more effort is needed, both in developing new theories and in makingthe existing methods and theories applicable, e.g., by providing tool support.

We would like to thank the programme committee and the additional reviewers fortheir support in selecting and composing the workshop programme, and we thank theauthors for their contributions without which, of course, these proceedings would notexist.Last, but not least, we thank Brian Nielsen and Arne Skou for arranging all localmatters of organizing the workshop, Aalborg University for giving the opportunity toorganize FATES’01 as a satellite of CONCUR’01, BRICS for supporting the printingand distribution of these proceedings, and Jan Feenstra en Rene de Vries for setting upthe FATES’01 web page.

Enschede, August 2001Ed BrinksmaJan Tretmans

iv

Page 7: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Programme committee

Ed Brinksma (University of Twente, The Netherlands), co-chairRocco De Nicola (Universita degli Studi di Firenze, Italy)Marie-Claude Gaudel (Universite de Paris-Sud, France)Jens Grabowski (Universitat Lubeck, Germany)Robert Hierons (Brunel University, United Kingdom)Thierry Jeron (INRIA Rennes, France)Doron Peled (Bell Laboratories, USA)Alexandre Petrenko (CRIM, Canada)Jan Tretmans (University of Twente, The Netherlands), co-chairAntti Valmari (Tampere University of Technology, Finland)Carsten Weise (Ericsson Eurolab Deutschland GmbH, Germany)

Referees

Timo AaltonenAxel BelinfanteMachiel van der BijlSergiy BorodayPedro R. D’ArgenioMichael EbnerJan FeenstraStefan Heymer

Ilkka KokkarinenMieke MassinkBrian NielsenVlad RusuIna SchieferdeckerMichael SchmittArne SkouRene G. de Vries

Organization

Brian Nielsen,Arne Skou,Aalborg University,Denmark

v

Page 8: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

vi

Page 9: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Contents

1 Efficient Algorithms for Test Sequence Selection . . . . . . . . . . . 1David Lee, Ruibing Hao

2 Tool Demonstration Proposal: UML Validation Suite . . . . . . . . . 9Marc Lettrari, Jochen Klose, Udo Brockmeyer

3 Automatic Test Generation from Statecharts using Model Checking . 15Hyoung Seok Hong, Insup Lee, Oleg Sokolsky, Sung Deok Cha

4 Automatic Generation of Tests from Statechart Specifications . . . . . 31Simon Burton, John Clark, John McDermid

5 Classical Search Strategies for Test Case Generation with ConstraintLogic Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Alexander Pretschner

6 Towards Formal Test Purposes . . . . . . . . . . . . . . . . . . . . . 61Rene G. de Vries, Jan Tretmans

7 Complexity Issues of Connectivity Testing . . . . . . . . . . . . . . . 77Jens Chr. Godskesen

8 A Simple Approach to Testing Timed Systems . . . . . . . . . . . . . 93Sebastien Salva, Eric Petitjean, Hacene Fouchal

9 Test Case Characterisation by Regular Path Expressions . . . . . . . . 109Ralf Lammel, Jorg Harm

10 Using SDL Tools to Test Properties of Distributed Systems . . . . . . 125Hesham Hallal, Alex Petrenko, Andreas Ulrich, Sergiy Boroday

11 A Formal Approach to Practical Test Selection . . . . . . . . . . . . . 141Tibor Csondes, Balazs Kotnyek

vii

Page 10: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

viii

Page 11: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Efficient Algorithms for Test Sequence Selection

(Extended Abstract)

David Lee and Ruibing HaoBell Labs Research China, Beijing, China

Abstract:We study the test sequence selection problem. Given a large number oftests for a protocol system, we want to select a subset of tests so that the number of testsis reduced yet the test coverage is not sacrificed. We discuss the complexity of the testselection problem and propose a class of algorithms for different protocol systeminformation requirements, test coverage criteria, and cost. This article is an extendedabstract of [LH], and we refer the interested readers to the full paper for a detailed study andexperimental results.

1. INTRODUCTION

With advanced computer technology protocol systems are getting larger to fulfil complicatedtasks. However, they are also becoming less reliable. Testing is an indispensable part of systemdesign and implementations; yet it has proved to be a formidable task for complex systems.Because of its practical importance and theoretical interest, there have been a lot of activities onprotocol system testing. There are conformance testing, interoperability testing, andperformance testing. Conformance testing is to test conformance of system implementations totheir specifications [Br, LY1, PBG]. Interoperability testing tends to uncover faults whendifferent system components are interoperating or interfacing with each other [GHLS, KK].Conformance and interoperability testing are designed to check the correctness of systembehaviors whereas performance testing is related to the system performance, such as itstransmission rate.

For certain complicated legacy protocol systems, such as 5ESS (AT&T/Lucent No. 5Electronic Switching System), tests have been generated and applied to the systems over theyears at different development stages and by different test engineers. There are thousands of testsequences in the available test set. To test such systems, it is impractical to generate tests fromscratch, since it is often impossible to model the systems because they are too complex.Therefore, we want to use the available test set accumulated over years. However, we do notwant to execute all of them, since there are too many and to run each test takes a substantialamount of time. A natural solution in practice is to select test sequences among the available testset.

The test selection problem was studied in [LPB] based on the valuations of the testsequences to be selected, and it was reduced to an optimisation problem over Boolean algebra.For testing in context, the problem was studied in [YCL]. An important issue of test selection isthe possible loss of coverage. This problem was investigated in [LPB] for partially specifiedmachines and also in [CV, VC, ZV] with an elegant metric of coverage. The selection criteriaand their notations were studied in [Pa].

1

Page 12: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

In this paper, we study the following test selection problem. We have a large set of testsequences, and we want to select a minimal subset of tests to execute without sacrificing thefault coverage. For a formal study, we use extended finite state machine to model protocolsystems. We discuss the complexity of the problem and propose efficient algorithms for the testsequence selection.

After describing an extended finite state machine model and its reachability graph, weformulate a problem of test sequence selection, discuss the coverage criteria, and study theproblem complexity. We then discuss efficient algorithms for the test selection.

A finite state machine contains a finite number of states and produces outputs on statetransitions after receiving inputs. It is often used to model control portions of protocol systems.However, data portions of protocols include variables and operations based on their values;ordinary finite state machines are not powerful enough to model in a succinct way the physicalsystems any more. Extended finite state machines (EFSM), which are finite state machinesextended with variables, have emerged from the design and analysis of communicationprotocols [LY1]. For instance, IEEE 802.2 LLC [ANSI] is specified by 14 control states, anumber of variables, and a set of transitions (pp. 75-117). For a formal definition of EFSM andthe related concepts, see [LY1].

Each combination of a state and variable values is called a configuration. An EFSM usuallyhas an initial state s0 and all the variables have an initial value xinit; we have the initialconfiguration (s0,xinit). A reachability graph consists of all the configurations and transitions,which are reachable from the initial configuration. It is a directed graph where the nodes andedges are the reachable configurations and transitions, respectively. Obviously, a control statemay have multiple appearances in the nodes (along with different variable values) and eachtransition may appear many times as edges in the reachability graph.

For a path from the initial node (configuration) of the reachability graph, the input/output(I/O) labels on the transitions of the path provide an I/O sequence. Conversely, if an I/Osequence corresponds to a unique path from the initial node in the reachability graph, then theunderlying EFSM is deterministic. Otherwise, it is non-deterministic. For clarity, in this paperwe only consider systems, which are modelled by deterministic EFSM’s. Our approaches can bemodified to handle non-deterministic EFSM’s, as we shall comment in the conclusion of thepaper.

Given an input sequence, there is at most one path from the initial node in the reachabilitygraph such that the transitions on the path are labelled with the input sequence, since themachine is deterministic. If such a path exists, then the given input sequence is valid. Otherwise,it is invalid. Obviously, a valid input sequence corresponds to a unique I/O sequence, which arethe labels on the corresponding unique path from the initial node.

We first study the test selection problem, assuming that the underlying system reachabilitygraph is available. We then relax the problem with an assumption that only the EFSMspecification of the underlying system is available. Finally, we present algorithms for a generalcase when no information of the underlying system is available for test selection.

2

Page 13: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

2. TEST SEQUENCE SELECTION PROBLEM AND ITS COMPLEXITY

A test sequence (or a scenario) is valid input sequence of a protocol system that is modelledby an EFSM. Since the system is deterministic, there is a one-to-one correspondence betweentest sequences and paths in the reachability graph from the initial configuration. In practice, atest sequence usually consists of an I/O sequence; the input sequence is applied to the systemunder test, and the output sequence is to be observed from the system response. Therefore, a testsequence can be represented by a valid input sequence, a valid I/O sequence, or a path from theinitial configuration in the reachability graph of the underlying protocol system. Forconvenience, we shall use these terms interchangeably.

Informally, the test sequence selection problem is: Given a set of test sequences S, selectfrom S a subset of tests S* with a desirable fault coverage. Fault coverage is essential for testing.However, it is often specified differently from different system models and practical needs.

A commonly used criterion of fault coverage is to test each edge in the reachability graph atleast once. It has been a well-accepted criterion in practice, and we first consider this criterion.Formally, given an EFSM M, let G be its reachability graph with an initial configuration v0,

which corresponds to the initial state of M and the initial variable values. A test sequence of Mis a path in G from v0. A covering test set is a set of test sequences such that each edge of G iscovered by at least one of the test sequences. We want to select a subset of tests such that it isstill a covering test set and contains a minimal number of tests:

Problem 1. Test selection with a reachability graph. Given the reachability graph of anEFSM and a covering test set S, select a subset of test sequences S* from S, such that S* is acovering test set with a minimal cardinality.

The problem is NP-hard [LH]. Therefore, it is hard to obtain an optimal solution for testselection in general. We discuss heuristic methods next.

3. TEST SEQUENCE SELECTION

We first consider the case that the underlying system reachability graph is available, andthen study the more general case without such reachability graphs.

3.1. Test Sequence Selection with a Reachability Graph

We consider the following greedy method. We first find a test sequence in S that covers amaximal number of uncovered edges of the reachability graph, and add this test to S*. We thenrepeat the process until all the edges of the reachability graph are covered. Formally,

3

Page 14: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Algorithm 1.input: reachability graph G and a covering test set Soutput: a covering test set S*, which is a subset of S

1. mark all edges in graph G as uncovered;2. S* = Λ; /* an empty set */3. repeat4. find a test sequence s in S that covers a maximal number of

uncovered edges of the graph G, and mark these edges as covered;5. S = S – {s}, S* = S* ∪{s};6. until all edges in G are covered7. return S*

Figure 1. Algorithm 1

A routine analysis shows that Algorithm 1 takes time O(MN) to select a covering test setwhere M and N are the total length and number of all the test sequences in the given coveringtest set.

To reduce the cost we may want to avoid examining all the tests in the set. We can conductthe following preprocessing and variations of Algorithm 1.

We first sort the tests in S according to their lengths in a descending order, and then examinethem in that order. The rationale is: longer tests correspond to longer paths in the reachabilitygraph and may cover more edges of the graph. Furthermore, if we have found a test, whichcovers k uncovered edges, then there is no need to examine tests of length k or less. Since thereare N tests in the set, the added cost of sorting is O(NlogN), which is negligible since it isdominated by O(MN).

Randomisation often helps. We can select each test sequence to be examined from Suniformly at random.

Another variation is that we sort the test sequences by their input symbols alphabeticallyrather than their lengths, remove all the tests which are a proper prefix of other tests, and thenapply Algorithm 1. Obviously, this pre-processing reduces redundant tests and we have fewertests to process. We shall further discuss this variation in the next section.

3.2. Test Sequence Selection without a Reachability Graph

Often we only have a test set available but do not have the corresponding reachability graphof the underlying system or it is too costly to construct such a graph. The problem becomesharder since we do not know whether a selected test set covers all the edges in the reachabilitygraph.

Suppose we have the underlying system specification EFSM yet without its reachabilitygraph. We have:

Problem 2. Test selection with an EFSM. Given an EFSM and a covering test set S, selecta subset of test sequences S* from S, such that S* is a covering test set with a minimalcardinality.

4

Page 15: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Similar to Problem 1, the test selection problem 2 is NP-hard. Therefore, it is hard to obtainan optimal solution for test selection in general.

We can use the following heuristic procedure. We examine all the test sequences in S, traceeach sequence in the EFSM, and record all the edges covered in the corresponding reachabilitygraph. We then select test sequences in S until all the recorded edges are covered. The selectionprocedure is similar to Algorithm 1, and the variations of Algorithm 1 also apply here. Note thatwe do not construct the reachability graph explicitly.

Algorithm 2.input: EFSM M and covering test set Soutput: a covering test set S*, which is a subset of S

1. E = Λ; /* identify all edges of reachability graph; E is an empty edge set */2. for each test sequence si in S, i = 1, …, N3. u=u0=< s0 xinit > ; /* u0 is the initial configuration of M */4. for j = 1, …, ki /* ki is the number of transitions in si */5. trace transition tij in M and determine next configuration v;6. if corresponding edge in reachability graph (u,v)∉E7. E = E ∪ {(u,v)};8. u =v;9. set all edges in set E as uncovered; /* find a covering subset S* */10. S* = Λ; /* an empty set */11. repeat12. find a test sequence s in S that covers a maximal number of uncovered

edges in set E, and mark these edges as covered;13. S = S – {s}, S* = S* ∪{s};14. until all edges in E are covered15. return S*

Figure 2. Algorithm 2

Algorithm 2 takes time O(MNlogM) to select a covering test set where M and N are the totallength and number of all the test sequences in the given covering test set.

Algorithm 2 is for a more general test selection Problem 2 where there is no reachabilitygraph and also no need to construct one. However, there is an extra price to pay in terms of therun time, i.e., a factor of logM.

Often in practice the underlying system model may not be available, especially for thoselegacy systems, and we only have a set of tests to select. This is the most general case of the testselection problem:

Problem 3. Test selection without any information of the underlying protocol system.Given a covering test set S for a protocol system, for which there is no information available,select a subset of test sequences S*, such that S* is a covering test set.

Different from Problem 1 and 2, in general it is impossible to select a minimal covering testset since there is no information of the underlying protocol system.

For this problem we only consider the following redundancy criterion. Let s and s* be twotest sequences where s* is a prefix of s. Let p and p* be the corresponding paths from the initialconfiguration in the reachability graph, which we do not know. Since the corresponding EFSM

5

Page 16: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

is deterministic, p* is a prefix of p as paths in the reachability graph, and we can remove s* fromthe test set without sacrificing the coverage. Consequently, if S is a covering test set, the testsubset S*, selected by discarding all the prefixes, is still a covering test set. As a matter of fact,in the worst case, we cannot reduce the tests anymore. Consider the following reachabilitygraph. It consists of separate paths from the initial node. For test selection, we can only discardthe paths (tests), which are a proper prefix of another path; any further reduction will lose thecoverage.

The above observations lead to the following algorithm. Consider the alphabet set of all theinput symbols. We sort all the input sequences in S alphabetically and then remove all the inputsequences (test sequences), which is a prefix of another input sequence.

Algorithm 3.input: test sequence set S and alphabet set of all the input symbols Σoutput: subset S* of S with redundant tests removed

1. sort all input sequences of S alphabetically;2. S* = Λ; /* an empty set */3. for i = 1, …, N-1 /* N is the cardinality of S */4. if si is not a prefix of si+1

5. S* = S* ∪{si};6. S* = S* ∪{sN};7. return S*

Figure 3. Algorithm 3

Given a test set S, Algorithm 3 removes redundant tests and selects a subset of tests S*. If Sis a covering test set of the reachability graph of the underlying protocol system, then S*

remains a covering test set.

Note that Algorithm 3 may select test sequences that are redundant in terms of covering thereachability graph since we do not have its information. Therefore, the resulting number of testsmay be larger than that from Algorithm 1 and 2.

It takes time O(MlogN) to select tests using Algorithm 3 where M and N are the total lengthand number of all the test sequences in the given test set.

The cost of the test selection of Algorithm 3 is dominated by sorting the test sequences. Wenow discuss another method, using trees. It is optimal in terms of run time; it takes timeproportional to the total lengths of the test sequences to be selected.

We grow a tree as follows. Initially, we have a root node v0. Each edge is labeled with aninput symbol. For each input sequence (test), we walk down the tree as follows. At a node u ofthe tree with an input symbol a in the sequence, if there is an outgoing edge from u labeled witha, then we walk down along that edge, arrive at the end node v, and process the input symbol inthe test sequence after a. However, if there are no outgoing edges labeled with a, then we add atree edge (u,v) from u, label it with a, walk down along (u,v), and continue processing from v asbefore. Each test requires a tree walk. After all the tests have been processed, we can obtain theselected tests as follows. We only have to select the tests (or paths) from the root to a leaf node;all the other tests (paths) a prefix of these selected tests. Note that each step of the tree walktakes a constant time (if we have a bitmap at each node to keep track of the labels of all the

6

Page 17: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

outgoing edges). Therefore, it takes time proportional to the length of a test sequence to process.Hence the total cost is O(M).

It takes time O(M) to select tests using Algorithm 4 where M is the total length of all the testsequences in the given test set.

Obviously, Algorithm 4 removes the prefixes and selects the same test set as Algorithm 3. Itis more efficient but involves an on-line tree construction process. Again, if the given test set isa covering set then the selected subset is also a covering. But it may contain redundant tests interms of covering the reachability graph, of which we have no information.

Algorithm 4.input: test sequence set S and alphabet set of all the input symbols Σoutput: subset S* of S with redundant tests removed

1. V = {v0}; /* V is node set of tree T; each node keeps track of all inputsymbols of its outgoing edges by a bitmap, */

2. for i =1, …, N /* N is the number of test sequences in S */3. u = v0; /* a tree walk from initial node v0 */4. for j = 1, …, ki /* ki is number of input symbols in sequence si */5. let tij be transition of si under examination with input tij->a;6. if (u.bitmap(a)=0) /* not recorded yet */7. initialize a new node v;8. construct a new tree edge (u, v);9. u.bitmap(a) =1; /* record this input symbol at u */10. u =v; /* walk down tree to v along newly constructed edge */11. else /* input has been recorded and tree edge exits for a walk */12. u=v;13. S* = Λ; /* an empty set */14. for each leaf node v of tree T;15. let s be test sequence corresponding to path from v0 to v;16. S*=S*∪{s};17. return S*

Figure 4. Algorithm 4

4. CONCLUSION

In this paper, we have discussed the test sequence selection problem. Given a test sequenceset, we want to select a subset of tests; without sacrificing the coverage we want to minimize thenumber of the selected tests to reduce the test execution time. We have proposed severalalgorithms with different required information and coverage, at different costs, and withdifferent redundancy of the selected tests.

So far we assume that the underlying protocol system is deterministic, and in this case, avalid test sequence corresponds to a unique path in the reachability graph. If the system is non-deterministic, then a valid test sequence may correspond to multiple paths in the graph. Sincethe execution sequence is non-deterministic, the coverage of the edges in the reachability graphis probabilistic. While the union of all the possible paths, which are associated with a valid testsequence, is considered for coverage, we can only claim in a probabilistic sense.

7

Page 18: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

ACKNOWLEDGEMENTS

Kun Du from Peking University implemented some of the algorithms. Our thanks go to thereviewers of PSTV-FORTE’2001 for their constructive comments and suggestions.

REFERENCES

[ANSI] International standard ISO 8802-2, ANSI/IEEE std 802.2, 1989.

[Br] E. Brinksma, A Theory for the Derivation of Tests, Proc. PSTV, pp. 63-74, 1988.

[BTV] E. Brinksma, J. Tretmans and L. Verhaard, A Framework for Test Selection, Proc. PSTV, pp. 233-248, 1991..

[CV] J. A. Curgus and S. T. Vuong, A Metric Based Theory of Test Selection and Coverage, Proc. PSTV,1993.

[GJ] M. R. Garey and D. S. Johnson, Computers and Intractability: a Guide to the Theory of NP-Completeness, W. H. Freeman, 1979.

[GHLS] N. Griffeth, R. Hao, D. Lee, and R. Sinha, Integrated System Interoperability Testing withApplications to VoIP, Proc. FORTE/PSTV, pp. 69-84, 2000.

[KK] S. Kang and M. Kim, Interoperability Test Suite Derivation for Symmetric CommunicationProtocols, Proc. FORTE/PSTV, 57-72, 1997.

[LH] D. Lee and R. Hao, Test Sequence Selection, Proc. PSTV-FORTE, 2001.

[LY1] D. Lee and M. Yannakakis, Principles and Methods of Testing Finite State Machines - a Survey,The Proceedings of IEEE, Vol. 84, No. 8, pp. 1089-1123, 1996.

[LY2] D. Lee and M. Yannakakis, Optimization Problems from Feature Testing of CommunicationProtocols, Proc. ICNP, pp. 66-75, 1996.

[LPB] G. Luo, A. Petrenko, and G. v. Bochmann, Selecting Test Sequences for Partially SpecifiedNondeterministci Finite State Machines, Proc. IFIP 7th Int. Workshop on Protocol Test Systems, 1994.

[Mo] E. F. Moore, Gedanken-experiments on sequential machines, Automata Studies, Annals ofMathematics Studies, Princeton University Press, no.34, pp.129-153, 1956.

[Pa] J. Pachl, A Notation for Specifying Test Selection Criteria, Proc. PSTV, pp. 71-84, 1990.

[PY] C. H. Papadimitriou, M. Yannakakis, Optimization, Approximation and Complexity Classes, J.Comp. Sys. Sc., 43(3), 425-440, 1991.

[PBG] A. Petrenko, S. Boroday, R. Groz, Confirming Configurations in EFSM, Proc. FORTE/PSTV, 5-24, 1999.

[VC] S. T. Vuong and J. A. Curgus, On Test Coverage Metrics for Communication Protocols, Proc.IWTCS, 1991.

[YCL] N. Yevtushenko, A. Cavalli, L. Lima, Test Suite Minimization for Testing in Context, Proc.IWTCS, pp. 127-145, 1998.

[ZV] J. Zhu and S. T. Vuong, Generalized Metric Based Test Selection and Coverage Measure forCommunication Protocols, Proc. PSTV, pp. 299-314, 1997.

8

Page 19: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� � � � � � � � � � � � � � � � � � � � � � !

# $ & ' � � � * � � � � . 0 � � �

3 4 6 8 9 : < < 6 4 6 > ? 4 A C E G 8 I : A L M G O : Q 4 A C S C G U 6 G 8 W X : Y : 6 Z

[ \ ^ ^ ` a c d e g i k l mn o l p r e g u p v m y z \ { | e l � � g � � � e � k g v i e l v y z � y i � � v e g a � p e l � e

� \ ^ ^ ` a a m u v e i u k l | � y l u � { v p l � d i � � c d e g i k l me � i k p { � � i k g � � { e v v g k g p c � y � � e l � � { y u e � � p l z y g i k v p � � � l p � y { | e l � � g � � | e

� g y � � i e m e g � y � u � � � | e

� � �   ¡ ¢ £ ¥ ¦   ¨ ¢ �

© > O < 6 > « ¬ < : C 6 : 4 M ­ < > X : 8 G X ° ¬ < : 6 O Y O < : X O 4 6 : ± : 6 Y 8 G X ° M : ³ 4 A C > A < 6 > A O > 8 4 M M Y C > µ ­¶ 8 ¬ M < < G O ° : 8 > µ Y 4 A C > X ° M : X : A < 8 G 6 6 : 8 < M Y ¹ º A : 8 4 ¬ O : > O < I : M 4 8 W G µ 4 C : ½ ¬ 4 < :X : < I G C O 4 A C < G G M O < G C : 4 M ¾ > < I < I > O 8 G X ° M : ³ > < Y ¹ ¿ I : ¬ O : G µ S 3 9 µ G 6 C : ± : M G ° ­> A Á O ¬ 8 I O Y O < : X O > O Á 4 > A > A Á X G 6 : 4 A C X G 6 : 4 < < : A < > G A « G < I µ 6 G X 6 : O : 4 6 8 I 4 A C> A C ¬ O < 6 Y ¹

È X 4 É G 6 Á G 4 M > A C : ± : M G ° > A Á O ¬ 8 I O Y O < : X O > O 4 ± 4 M > C 4 < > G A < I 4 < < I : C : O > Á Aµ ¬ M ¶ M M O 8 : 6 < 4 > A ° 6 G ° : 6 < > : O ¹ È M < I G ¬ Á I < I : 6 : 4 6 : O G X : 4 ° ° 6 G 4 8 I : O ¾ > < I < I : Á G 4 M G µ4 µ G 6 X 4 M ° 6 G G µ G µ < I : 8 G 6 6 : 8 < A : O O G µ 4 C : O > Á A Í Î Ï Ð Ñ Ï < : O < > A Á O < > M M ° M 4 Y O 4 C G X > A 4 A <

6 G M : ¹ ¿ I : 6 : 4 O G A O 4 6 : < I : M > X > < : C 4 ° ° M > 8 4 « > M > < Y G µ < I : X : < I G C O ¾ I > 8 I O < 6 > ± : µ G 64 µ G 6 X 4 M ° 6 G G µ Ò

Ó Ô ¬ M M Y 4 ¬ < G X 4 < > 8 X : < I G C O Ö X G C : M 8 I : 8 W > A Á Ø 8 4 A G A M Y « : 4 ° ° M > : C < G O X 4 M MC : O > Á A O 4 A C O > X ° M : ° 6 G ° : 6 < > : O ¹

Ó Û : X > ­ 4 ¬ < G X 4 < > 8 Ö ¾ > < I < I : I : M ° G µ < I : G 6 : X ° 6 G ± : 6 O Ø G 6 X 4 A ¬ 4 M ° 6 G G µ O 4 6 :G µ < : A ± : 6 Y C > Þ 8 ¬ M < 4 A C 6 : ½ ¬ > 6 : O > Á A > ¶ 8 4 A < W A G ¾ M : C Á : 4 A C : ³ ° : 6 > : A 8 : ¹

ß G A ± : A < > G A 4 M < : O < > A Á G A < I : G < I : 6 I 4 A C > O : 4 O > : 6 < G C G Ï « ¬ < C G : O A G < A : 8 : O O 4 6 > M Y¬ A 8 G ± : 6 4 M M : 6 6 G 6 O > < ¬ 4 < > G A O ¹ ¿ I : 6 : µ G 6 : 4 µ ¬ O > G A G µ < I : µ G 6 X 4 M ± : 6 > ¶ 8 4 < > G A 4 A C

< : O < > A Á 4 ° ° 6 G 4 8 I : O ° 6 G X > O : O < G > X ° 6 G ± : < I : ± 4 M > C 4 < > G A G µ O G µ < ¾ 4 6 : ¹ â : 6 : ¾ :° 6 : O : A < 4 S ã Û Ö S 3 9 ã 4 M > C 4 < > G A Û ¬ > < : Ø < G G M µ G 6 < : O < > A Á S 3 9 X G C : M O C : O > Á A : C¾ > < I < I : ä I 4 ° O G C Y < G G M G µ å ­ 9 G Á > ³ Ï å A 8 ¹ ç : 4 C C O : X 4 A < > 8 6 > Á G 6 < G < I : ä I 4 ° O G C Y

Û : ½ ¬ : A 8 : © > 4 Á 6 4 X O Ö Û © O Ø 4 A C ¬ O : < I : X < G X G A > < G 6 G 6 C 6 > ± : < I : > A < : 6 4 8 < > ± :O > X ¬ M 4 < > G A G µ < I : S 3 9 X G C : M ¹

¿ I > O ° 6 G ° G O 4 M > O G 6 Á 4 A > é : C 4 O µ G M M G ¾ O Ò ç : O < 4 6 < ¾ > < I < I : µ G 6 X 4 M µ G ¬ A C 4 < > G AG µ Û : ½ ¬ : A 8 : © > 4 Á 6 4 X O > A O : 8 < > G A ê Ï µ G M M G ¾ : C « Y 4 ½ ¬ > 8 W G ± : 6 ± > : ¾ G µ < I : µ : 4 < ¬ 6 : OG µ < I : S ã Û < G G M 4 A C I G ¾ > < 8 4 A « : > A < : Á 6 4 < : C > A < G < I : C : O > Á A ° 6 G 8 : O O > A O : 8 < > G Aì ¹ ç : 8 G A 8 M ¬ C : ¾ > < I > A µ G 6 X 4 < > G A 4 « G ¬ < < I : > X ° M : X : A < 4 < > G A G µ < I : < G G M > A Û : 8 < ¹

Ð ¹

í î ï ð ¥ ï � ¦ ï ñ ¨ ò ó ¡ ò ô õ

¿ I : Û : ½ ¬ : A 8 : © > 4 Á 6 4 X O ¾ : 4 6 : 8 G A O > C : 6 > A Á I : 6 : 4 6 : 4 A : A I 4 A 8 : C ± : 6 O > G A G µ < I :G A : O G ö : 6 : C « Y < I : ä I 4 ° O G C Y < G G M 4 < < I : X G X : A < ¹ å A < I : 8 G A < : ³ < G µ X G A > < G 6 > A Á4 A C C 6 > ± > A Á 4 A S 3 9 C : O > Á A ¾ : A : : C X G 6 : : ³ ° 6 : O O > ± : A : O O < I 4 A < I 4 < ° 6 G ± > C : C

9

Page 20: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

« Y < I : S 3 9 O < 4 A C 4 6 C ¹ Ô G 6 < I > O 6 : 4 O G A ¾ : I 4 ± : 4 C C : C 4 µ : 4 < ¬ 6 : ¾ I > 8 I ¾ : µ : : M> O : O O : A < > 4 M µ G 6 < I > O 4 ° ° M > 8 4 < > G A 4 6 : 4 Ò < I : 8 4 ° 4 « > M > < Y < G O ° : 8 > µ Y ¾ I : A 4 O 8 : A 4 6 > GC : O 8 6 > « : C > A 4 Û © O I G ¬ M C « : 4 8 < > ± 4 < : C Ï > ¹ : ¹ ¾ I : A O I G ¬ M C ¾ : O < 4 6 < < G X G A > < G 6

< I : O Y O < : X G 6 Á : A : 6 4 < : 8 : 6 < 4 > A > A ° ¬ < O � ¿ I : O > X ° M : O < ° G O O > « > M > < Y ¾ G ¬ M C « : < GG A M Y 8 G A O > C : 6 � � � � � � Û © O Ï > ¹ : ¹ < I G O : ¾ I > 8 I 4 6 : 4 8 < > ± 4 < : C 4 < O Y O < : X O < 4 6 < ¹ ¿ I > O > O8 M : 4 6 M Y < G G 6 : O < 6 > 8 < > ± : Ï O > A 8 : ¾ : 4 M O G ¾ 4 A < < G « : 4 « M : < G ¬ O : O 8 : A 4 6 > G O ¾ I > 8 I 4 6 :4 8 < > ± : X G 6 : < I 4 A G A 8 : ¹ ç : < I : 6 : µ G 6 : > A < 6 G C ¬ 8 : < I : 8 G A 8 : ° < G µ � � � � � � � � � � � �

¾ I > 8 I 8 4 A « : : > < I : 6 � � � � � � G 6 � � � � � � � � Ï ¾ I : 6 : < I : O : 8 G A C 8 I G > 8 : > A C > 8 4 < : O < I 4 << I : Û © 8 4 A « : 4 8 < > ± 4 < : C O : ± : 6 4 M < > X : O Ï ¾ I : A : ± : 6 < I : 4 8 < > ± 4 < > G A 8 G A C > < > G A > O < 6 ¬ :C ¬ 6 > A Á 4 6 ¬ A G µ < I : O Y O < : X 4 A C < I : Û © > O A G < 4 M 6 : 4 C Y 4 8 < > ± : ¹ Ô G 6 < I : > < : 6 4 < > ± : 8 4 O :4 A G < I : 6 µ : 4 < ¬ 6 : > O A : : C : C Ï ¾ I > 8 I 4 M M G ¾ O ¬ O < G O ° : 8 > µ Y ¾ I : A : ³ 4 8 < M Y < I : Û © O I G ¬ M C

« : 4 8 < > ± 4 < : C ¹ â : 6 : ¾ : ¬ O : 4 A � � � � � � � � � � � � � � � � � Ï 4 U G G M : 4 A : ³ ° 6 : O O > G A ¾ I > 8 I8 I 4 6 4 8 < : 6 > é : O < I : O < 4 < : G µ < I : ä I 4 ° O G C Y C : O > Á A ¾ I : A < I : O 8 : A 4 6 > G O I G ¬ M C O < 4 6 < ¹U G < I < I : 4 8 < > ± 4 < > G A X G C : 4 A C 8 G A C > < > G A ¾ : I 4 ± : 4 C G ° < : C µ 6 G X & � � � ) � , . � � � �

1 2 � � 4 Ö 9 Û ß O Ø Í 5 Ñ ¾ I > 8 I 4 6 : < I : µ G 6 X 4 M « 4 O : G µ < I : S ã Û < G G M ¹

7 7 7 7 7 7 7

8 8 8 8 8 8 8 8

9 9 9 9 9 9 9 9 9

: : : : : : : :: : : : : : : :; ; ; ; ; ; ; ;; ; ; ; ; ; ; ;

< < < < < < <

= == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == == =

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

??????????????????????????????????

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

B B B B B B B BB B B B B B B BC C C C C C C CC C C C C C C C

Y.itsLine:Line Y:TelephoneX : TelephoneX.itsConnection

X.itsLine:Line Connection

OffHook()

DialTone()

Dial(nr=Y.nr)

Dial(nr=Y.nr)

evRing()

Dial(nr=Y.nr)

evRing()

Activation Condition: TRUEActivation Mode: Initial

ENV

D E G I K I a e L � e l � e | p k � g k i e N k i � { e a � P

Ô > Á ¬ 6 : 5 O I G ¾ O 4 A : ³ 4 X ° M : Û © Ï ¾ I : 6 : 4 8 G A A : 8 < > G A « : < ¾ : : A < ¾ G < : M : ° I G A : O > OO : < ¬ ° ¹ ¿ I : : A ± > 6 G A X : A < > A µ G 6 X O < I : < : M : ° I G A : O Y O < : X < I 4 < < I : 6 : 8 : > ± : 6 I 4 O

« : : A M > µ < : C G ö < I : I G G W Ï < I : A < I : C > 4 M < G A : > O I : 4 6 C > A < I : 6 : 8 : > ± : 6 ¹ S G ¾ < I :8 4 M M : 6 C > 4 M O < I : < : M : ° I G A : A ¬ X « : 6 G µ < I : 8 4 M M : : ¾ I > 8 I > O ° 6 G ° 4 Á 4 < : C < I 6 G ¬ Á I < I :O Y O < : X ¹ å A < I : : A C < I : 8 4 M M : : T O ° I G A : 6 > A Á O ¹¿ I : µ G 6 X 4 M O : X 4 A < > 8 O µ G 6 G ¬ 6 Û © O > O Á > ± : A « Y 4 A 4 ¬ < G X 4 < G A ¾ I > 8 I 6 : ° 6 : O : A < O 4 M M< I : 8 G X X ¬ A > 8 4 < > G A O : ½ ¬ : A 8 : O 4 M M G ¾ : C « Y < I : Û © µ 6 G X ¾ I > 8 I > < > O 8 G A O < 6 ¬ 8 < : C ¹¿ I : 4 M Á G 6 > < I X µ G 6 C : 6 > ± > A Á < I > O 4 ¬ < G X 4 < G A µ 6 G X 4 A Û © > O 4 Á 4 > A < 4 W : A µ 6 G X < I :9 Û ß ¾ G 6 M C Ö O : : Í ì Ñ µ G 6 4 C : < 4 > M : C C : O 8 6 > ° < > G A Ø ¹

È A : 6 6 G 6 > O > A C > 8 4 < : C « Y < I : S ã Û < G G M ¾ I : A < I : G 6 C : 6 C : ¶ A : C > A < I : Û © > O± > G M 4 < : C « Y < I : O > X ¬ M 4 < > G A 6 ¬ A Ï > ¹ : ¹ ¾ I : A 4 A : ± : A < G 6 X : < I G C 8 4 M M > O G « O : 6 ± : C4 < < I : ¾ 6 G A Á < > X : ¹ ß G A O : ½ ¬ : A < M Y < I : G A M Y ° : 6 X > O O > « M : G 6 C : 6 G µ < I : X : O O 4 Á : O > O

< I : G A : O I G ¾ A > A < I : Û © ¹ È < < I > O ° G > A < 4 M O G < I : 4 8 < > ± 4 < > G A G µ 4 A Û © 8 G X : O > A < G

10

Page 21: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

° M 4 Y Ï O > A 8 : 4 A : 6 6 G 6 8 4 A G A M Y « : C : < : 8 < : C ¾ I : A < I : 8 G 6 6 : O ° G A C > A Á Û © I 4 O « : : A4 8 < > ± 4 < : C ¹

� � ï   � ¢ £ ¢ � ¢ ó �

¿ I : < Y ° > 8 4 M S 3 9 C : ± : M G ° X : A < ° 6 G 8 : O O Ö : ¹ Á ¹ ä 4 ° > C º « É : 8 < ­ G 6 > : A < : C � 6 G 8 : O O µ G 6 X « : C C : C Û Y O < : X O Ö ä º � Û Ø Í ê Ñ Ø > O > < : 6 4 < > ± : Ï O < 4 6 < > A Á ¾ > < I 4 A : 4 6 M Y Ï µ 4 > 6 M Y4 « O < 6 4 8 < ± : 6 O > G A 4 A C ° 6 G Á 6 : O O > A Á < G X G 6 : 4 A C X G 6 : 8 G A 8 6 : < : ° 6 G < G < Y ° : O ¹ ¿ I :

¶ 6 O < ± : 6 O > G A ¾ > M M G µ < : A « : > A 8 G X ° M : < : I 4 ± > A Á O G X : 8 M 4 O O : O ¾ I > 8 I 4 6 : 4 M 6 : 4 C Y ¾ : M MC : ± : M G ° : C 4 A C G < I : 6 O ¾ I > 8 I 4 6 : É ¬ O < : X ° < Y O I : M M O Ï > ¹ : ¹ < I : 8 M 4 O O : O : ³ > O < < G Á : < I : 6

¾ > < I < I : > 6 Ö > A 8 G X ° M : < : Ø O : < G µ : ± : A < O 4 A C X : < I G C O ¾ I > 8 I 4 6 : A G < > X ° M : X : A < : CY : < ¹ È A 4 ° ° 6 G ° 6 > 4 < : ± 4 M > C 4 < > G A < : 8 I A > ½ ¬ : I 4 O < G O ¬ ° ° G 6 < O ¬ 8 I 4 C : ± : M G ° X : A <° 6 G 8 : O O ¾ I > 8 I > O G µ < : A A G < < I : 8 4 O : ¹

¿ I : 6 : µ G 6 : ¾ : 4 > X 4 < 4 A 4 ° ° 6 G 4 8 I ¾ I > 8 I O ¬ ° ° G 6 < O ± 4 M > C 4 < > G A < I 6 G ¬ Á I G ¬ << I : ¾ I G M : C : ± : M G ° X : A < ° 6 G 8 : O O ¹ ç : ¬ O : Û : ½ ¬ : A 8 : © > 4 Á 6 4 X O 4 O 4 Á 6 4 ° I > 8 4 M M 4 A ­Á ¬ 4 Á : < G C : O 8 6 > « : 8 : 6 < 4 > A µ ¬ A 8 < > G A 4 M 4 A C 6 : 4 M ­ < > X : ° 6 G ° : 6 < > : O ¹ ç : « : M > : ± : < I 4 <

Û : ½ ¬ : A 8 : © > 4 Á 6 4 X O 4 6 : ¾ : M M O ¬ > < : C µ G 6 O ¬ 8 I 4 < : O < > A Á ° 6 G 8 : O O « : 8 4 ¬ O : G µ O : ± : 6 4 M6 : 4 O G A O Ï : ¹ Á

Ó Û © O 4 6 : ¬ O : C : 4 6 M Y > A < I : C : ± : M G ° X : A < ° 6 G 8 : O O < G 8 4 ° < ¬ 6 : < I : 6 : M : ± 4 A < ¬ O :8 4 O : O G µ < I : C : O > 6 : C O Y O < : X ¹ ¿ I : 6 : µ G 6 : < I : < : O < > A Á ° 6 G 8 : O O 8 4 A 6 ¬ A > A ° 4 6 4 M M : M¾ > < I < I : C : ± : M G ° X : A < ° 6 G 8 : O O ¾ I > 8 I 4 M M G ¾ O : 4 6 M Y C : < : 8 < > G A G µ µ ¬ A 8 < > G A 4 M G 6< > X > A Á : 6 6 G 6 O ¹

Ó ¿ I : Á 6 4 ° I > 8 4 M µ 4 O I > G A G µ Û © O : 4 O : O < I : 8 G X X ¬ A > 8 4 < > G A « : < ¾ : : A ¬ O : 6 O Ï C : ± : M ­G ° : 6 O 4 A C < : O < : A Á > A : : 6 O ¹ ¿ I : 6 : µ G 6 : < I : 4 8 8 : ° < 4 A 8 : G µ < I : C : ± : M G ° : C O Y O < : X O¾ > M M > A 8 6 : 4 O : ¹

Ó 3 G O < G µ < I : 8 G X X G A 6 : 4 M ­ < > X : ° 6 G ° : 6 < > : O Ö : ¹ Á ¹ 6 : O ° G A O : < > X : O Ø 8 4 A « : : ³ ­° 6 : O O : C ¬ O > A Á Û © O ¹

ç : O I G ¾ < I : 4 ° ° M > 8 4 < > G A G µ G ¬ 6 < : O < > A Á 4 ° ° 6 G 4 8 I 4 < ì < Y ° > 8 4 M O < 4 Á : O > A < I :C : ± : M G ° X : A < ° 6 G 8 : O O ¾ I : 6 : ¾ : > A 8 6 : X : A < 4 M M Y 8 6 : 4 < : : 4 6 M Y ° 6 G < G < Y ° : O Ö < : O < > A ÁC ¬ 6 > A Á C : O > Á A Ø Ï 4 ¶ 6 O < µ ¬ M M Y > X ° M : X : A < : C C : O > Á A Ö ¬ A > < < : O < > A Á Ø 4 A C 4 A : A I 4 A 8 : CC : O > Á A Ö 6 : Á 6 : O O > G A < : O < > A Á Ø ¹

Ó Û ¬ ° ° G O : ¾ : I 4 ± : 4 O Y O < : X ¬ A C : 6 8 G A O < 6 ¬ 8 < > G A ¾ I : 6 : ¾ : ¾ 4 A < < G < : O < < I :4 M 6 : 4 C Y > X ° M : X : A < : C 8 M 4 O O : O ¹ ¿ I > O > O ° G O O > « M : « Y C : O > Á A 4 < > A Á < I : > A 8 G X ° M : < :8 M 4 O O : O 4 O 4 � . 4 > A < I : Û © Ö O Ø 4 A C M : < < > A Á < I : < : O < < G G M < 4 W : G ± : 6 < I : > 6 « : ­I 4 ± > G 6 ¹ ¿ I : O < ¬ « « : C 8 M 4 O O : O I 4 ± : < G ° 6 G ± > C : 4 < M : 4 O < < I G O : > A < : 6 µ 4 8 : G « É : 8 < O

Ö G ° : 6 4 < > G A O 4 A C : ± : A < ? 6 : 8 : > ° < O Ø ¾ I > 8 I 4 ° ° : 4 6 > A < I : Û © ¹ ¿ I : C > ö : 6 : A 8 : « : ­< ¾ : : A X G A > < G 6 > A Á 4 A C < : O < > A Á 4 Û © > O < I : ¾ 4 Y < I : : A ± > 6 G A X : A < > O < 6 : 4 < : C ¹å µ ¾ : ¾ 4 A < < G X G A > < G 6 4 Û © Ï < I : A ¾ : G A M Y G « O : 6 ± : > µ 4 M M C : O 8 6 > « : C : ± : A < O4 A C X : < I G C 8 4 M M O G 8 8 ¬ 6 > A < I : 6 > Á I < G 6 C : 6 4 A C ¾ > < I > A < I : 6 > Á I < < > X : > A < : 6 ­± 4 M M O ¹ å µ ¾ : ¾ 4 A < < G < : O < 4 Û © Ï < I : A < I : : ± : A < O 8 G X > A Á µ 6 G X < I : : A ± > 6 G A X : A <

Ö 4 A C < I : G A : O µ 6 G X O < ¬ « « : C > A O < 4 A 8 : O Ø 4 6 : Á : A : 6 4 < : C 4 ¬ < G X 4 < > 8 4 M M Y 4 < < I :4 ° ° 6 G ° 6 > 4 < : ° G > A < O > A < > X : Ï 4 A C 4 M M G < I : 6 X : O O 4 Á : O 4 6 : X G A > < G 6 : C ¹

[ a p � l k { u p l o � � v e g i p l y { y � m �

11

Page 22: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

RhapsodyGenerated App.

InputScenarios

OutputScenarios

Stimuli Back Animation Data

"Simulator"

Scenario-basedTest Generator

TestDefintion

Stimuli Back Animation Data

COM API SD API

ExecutionControl

RhapsodyTOM API

UVS

D E G I � I � y i i � l p � k v p y l � e v � e e l o � a k l | � � k � u y | m

Ó å A M 4 < : 6 > < : 6 4 < > G A O 4 O < I : C : O > Á A « : 8 G X : O X G 6 : 4 A C X G 6 : 8 G X ° M : < : < I :O < ¬ « « : C Û © > A O < 4 A 8 : O 8 4 A « : < 6 4 A O µ G 6 X : C > A < G 6 : Á ¬ M 4 6 G A : O 4 O < I : ¬ A C : 6 M Y > A Á8 M 4 O O : O « : 8 G X : X G 6 : 8 G X ° M : < : ¹ å A Á : A : 6 4 M Ï Û © O ¾ I > 8 I I 4 ± : « : : A O ° : 8 > ¶ : C> A : 4 6 M > : 6 > < : 6 4 < > G A O 8 4 A « : ¬ O : C µ G 6 6 : Á 6 : O O > G A < : O < > A Á > A < I : M 4 < : 6 ° I 4 O : O Ï

< I : 6 : « Y « : 8 G X > A Á > A ± 4 6 > 4 A < O G µ < I : X G C : M ¹ È A G < I : 6 > X ° G 6 < 4 A < 4 O ° : 8 < G µ6 : ¬ O > A Á Û © O > O < I : ° G O O > « > M > < Y < G ° 4 6 4 X : < : 6 > é : < I : X ¹ U Y ¬ O > A Á ° 4 6 4 X : < : 6 OO ¬ 8 I 4 O � � 4 A C � � � 4 O G « É : 8 < A 4 X : O G A Û © > A O < 4 A 8 : O 4 M M 8 G X « > A 4 < > G A O G µG « É : 8 < O G µ < I : 8 G 6 6 : O ° G A C > A Á 8 M 4 O O : O 8 4 A « : < 6 : 4 < : C > A G A : Û © ¹ å µ ¾ : ¾ 4 A << G ¬ O : O ¬ 8 I 4 A Û © µ G 6 X G A > < G 6 > A Á G 6 < : O < > A Á Ï ¾ : I 4 ± : < G > A O < 4 A < > 4 < : < I : O :° 4 6 4 X : < : 6 O ¾ > < I 8 G A 8 6 : < : G « É : 8 < O G µ < I : O Y O < : X ¹

Ó å A : 4 8 I A : ¾ > < : 6 4 < > G A < I : : ³ > O < > A Á Û © O 8 4 A « : O ¬ ° ° M : X : A < : C « Y A : ¾ G A : O¾ I > 8 I O ° : 8 > ¶ 8 4 M M Y < : O < < I G O : µ : 4 < ¬ 6 : O ¾ I > 8 I I 4 ± : « : : A 4 C C : C > A < I > O > < : 6 4 ­< > G A 8 Y 8 M : ¹ º µ 8 G ¬ 6 O : Ï ¾ I : A > A O : 6 < > A Á A : ¾ µ ¬ A 8 < > G A 4 M > < Y > A < G 4 C : O > Á A Ï G < I : 6µ ¬ A 8 < > G A O O I G ¬ M C A G < « : 4 ö : 8 < : C ¹ ¿ G < : O < < I > O Ï ¾ : 8 4 A ¬ O : < I : Û © O µ 6 G X < I :° 6 : ± > G ¬ O > < : 6 4 < > G A O µ G 6 6 : Á 6 : O O > G A < : O < > A Á ¹

å A G ¬ 6 : ³ 4 X ° M : ¾ : 4 M ¾ 4 Y O ¬ O : C G A M Y G A : Û © O 4 < 4 < > X : µ G 6 < : O < > A Á Ï « ¬ < G ¬ 64 ° ° 6 G 4 8 I 4 M O G 4 M M G ¾ O 8 G X ° M : ³ < : O < O 8 G A O > O < > A Á G µ O : ± : 6 4 M Û © O ¾ I G O : 4 8 < > ± 4 < > G A8 4 A « : 8 G A < 6 G M M : C : > < I : 6 > X ° M > 8 > < M Y « Y < I : > 6 4 8 < > ± 4 < > G A X G C : 4 A C 4 8 < > ± 4 < > G A 8 G A ­C > < > G A G 6 : ³ ° M > 8 > < M Y « Y 4 A G 6 C : 6 > A Á Á > ± : A « Y < I : ¬ O : 6 ¹ 4 8 I < : O < 8 4 A 8 G A O > O < G µ4 6 « > < 6 4 6 Y X 4 A Y > A O < 4 A 8 : O G µ Û © O Ï ¾ I > 8 I 4 6 : Û © O ¾ > < I > A O < 4 A < > 4 < : C ° 4 6 4 X : < : 6 O ¹¿ I > O 4 M M G ¾ O < I : C : ¶ A > < > G A G µ ± : 6 Y 8 G X ° M : ³ < : O < O ¾ I : 6 : X : O O 4 Á : O 8 4 A « : O : A < > A

° 4 6 4 M M : M G 6 O : ½ ¬ : A < > 4 M M Y < G < I : 4 ° ° M > 8 4 < > G A Ï ¾ I : 6 : 4 O X 4 A Y X G A > < G 6 O 8 4 A G « O : 6 ± :< I : « : I 4 ± > G ¬ 6 G µ < I : 4 ° ° M > 8 4 < > G A ¹

� � ô � � ï ô ï �   ò   ¨ ¢ �

È < ° 6 : O : A < Ï < I : S ã Û < G G M > O « : > A Á > A < : Á 6 4 < : C > A < G ä I 4 ° O G C Y 4 A C > < ¾ > M M « : ° 4 6 <G µ < I : A : ³ < 6 : M : 4 O : ¹ å A < I > O O : 8 < > G A ¾ : « 6 > : � Y G ¬ < M > A : < I : O G µ < ¾ 4 6 : 4 6 8 I > < : 8 < ¬ 6 :G µ < I : S ã Û 4 A C > < O > A < : 6 4 8 < > G A ¾ > < I ä I 4 ° O G C Y ¹

È ° 6 : 6 : ½ ¬ > O > < : G µ G ¬ 6 A G < > G A G µ < : O < > A Á > O < I : ° G O O > « > M > < Y < G > A < : 6 4 8 < ¾ > < I < I :O Y O < : X ¬ A C : 6 < : O < ¹ Ô G 6 G ¬ 6 4 ° ° 6 G 4 8 I > < > O > X ° G 6 < 4 A < < I 4 < < I : < : O < : 6 > O > A µ G 6 X : C

12

Page 23: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

4 « G ¬ < : ± : 6 Y : ± : A < 4 A C X : < I G C 8 4 M M ¾ I > 8 I > O C : O 8 6 > « : C > A < I : 8 G A O > C : 6 : C Û © O ¹

Ô ¬ 6 < I : 6 X G 6 : < I : < : O < : 6 X ¬ O < I 4 ± : < I : ° G O O > « > M > < Y < G O : A C : ± : A < O < G < I : O Y O < : X¬ A C : 6 < : O < ¹ ¿ I : O : 8 4 ° 4 « > M > < > : O 8 4 A « : 6 : 4 M > é : C > A C > ö : 6 : A < ¾ 4 Y O Ö : ¹ Á ¹ 8 G C : > A ­O < 6 ¬ X : A < 4 < > G A Ï X G C : M : ³ : 8 ¬ < G 6 : < 8 ¹ Ø ¹ Ô > Á ¬ 6 : ê O I G ¾ O I G ¾ S ã Û 4 A C ä I 4 ° O G C Y> A < : 6 4 8 < ¾ > < I : 4 8 I G < I : 6 ¹ ¿ I : S ã Û X 4 A 4 Á : O < I : C : ¶ A > < > G A G µ < I : < : O < 8 4 O : O 4 A C8 G A < 6 G M O < I : < : O < : ³ : 8 ¬ < > G A O : A C > A Á O < > X ¬ M > ¾ I : A 6 : ½ ¬ > 6 : C 4 A C G « O : 6 ± > A Á < I :4 8 < > G A O < 4 W : A > A < I : O > X ¬ M 4 < G 6 ¹

ç : I 4 ± : > A < : Á 6 4 < : C < I : ¾ I G M : < : O < : A ± > 6 G A X : A < C > 6 : 8 < M Y > A ä I 4 ° O G C Y ¹ Ô G 6: 4 8 I ° 6 G É : 8 < < I : ¬ O : 6 8 4 A C : ¶ A : 4 6 « > < 6 4 6 > M Y X 4 A Y < : O < O ¾ I > 8 I 4 6 : 4 ¬ < G X 4 < > 8 4 M M YO < G 6 : C < G Á : < I : 6 ¾ > < I < I : ° 6 G É : 8 < ¶ M : O ¹ Ô G 6 : 4 8 I < : O < > < 8 4 A « : O ° : 8 > ¶ : C ¾ I > 8 I

Û © O > < O I G ¬ M C 8 G A < 4 > A Ï I G ¾ < I : ° 4 6 4 X : < : 6 O O I G ¬ M C « : > A O < 4 A < > 4 < : C 4 A C ¾ I > 8 I

Û © O O I G ¬ M C 6 ¬ A > A ° 4 6 4 M M : M G 6 O : ½ ¬ : A < > 4 M M Y ¹ © ¬ 6 > A Á < I : : ³ : 8 ¬ < > G A G µ < I : < : O < < I :¬ O : 6 > O > A µ G 6 X : C 4 « G ¬ < ¾ I > 8 I ° 4 6 < O G µ < I : < : O < « : I 4 ± : 4 O : ³ ° : 8 < : C 4 A C ¾ I > 8 IA G < ¹ å µ 4 A : 6 6 G 6 ¾ 4 O C : < : 8 < : C Ï 4 Û © > O Á : A : 6 4 < : C 4 ¬ < G X 4 < > 8 4 M M Y < G ± > O ¬ 4 M > é : < I :

: 6 6 G 6 ¹ä I 4 ° O G C Y Á : A : 6 4 < : O > A O < 6 ¬ X : A < : C 8 G C : Ï ¾ I > 8 I 8 G X X ¬ A > 8 4 < : O ¾ > < I 4 O > X ¬ ­

M 4 < > G A > A < : 6 µ 4 8 : Ö ¿ º 3 È � å Ø C ¬ 6 > A Á 6 ¬ A < > X : ¹ ç I : A : ± : 6 6 : M : ± 4 A < < I > A Á O G 8 8 ¬ 6¾ > < I 6 : Á 4 6 C < G < I : 8 G A O > C : 6 : C Û © O Ï < I : O > X ¬ M 4 < > G A > A < : 6 µ 4 8 : > A µ G 6 X O < I : < : O < > A Á< G G M 4 « G ¬ < < I : X ¹ U 4 O : C G A < I : O : A G < > ¶ 8 4 < > G A O < I : < : O < > A Á < G G M C : < : 8 < O ° G O O > ­« M : : 6 6 G 6 O G 6 Á : A : 6 4 < : O : ± : A < O 4 ¬ < G X 4 < > 8 4 M M Y ¾ I > 8 I 8 4 A « : O : A C « 4 8 W < G < I :> X ° M : X : A < 4 < > G A < I 6 G ¬ Á I < I : O > X ¬ M 4 < > G A > A < : 6 µ 4 8 : ¹

� ï � ï ¡ ï � ¦ ï õ

P � � � � k i i k l | � � � k g e { � � a � u � � g e k v � p l � � p z e p l v y � e u u k � e a e L � e l � e � � k g v u � ` l� � � � � � � � � � � � � � � � � # % � ( * , . � 0 2 4 , 0 6 2 * : 0 6 < � : 0 = 4 , 4 0 A 4 : 0 � : , D 6 < � 4 2 ( : . G = : ,

I 4 0 K M 4 A 2 P Q 6 G 4 . � * G 2 , * K T 2 4 . � V G 2 4 D G c P X X X �Y � � g � � e Z � � y � � { k u u � � : * 0 [ ] 6 , . � * D 4 � _ | | p u y l � � e u { e m c P X X X �

a � b y � � e l c { y u e k l | � k g v i � v � p v v � e � _ l _ � v y i k v k � k u e | � e � g e u e l v k v p y l y z � p r e a e L � e l � e� � k g v u � ` l g p h p k l k � k g � k g p k k l | � k l � k p c e | p v y g u c � , : A 4 4 . * 0 [ G : = � n � n � o p p % c l � i � e gY r a P p l � s � a � a � g p l � e g � e g { k � c Y r r P �

v � � p e � y � k v e { { k c ` u v r k l � k p � h p � c k l | � p e � e � k u u p l � � g y � k g | u k z y g i k { y � e g k v p y l k { u e i k l v p � uy z � i { u v k v e � � k g v | p k � g k i u � ` l x , . � 0 2 4 , 0 6 2 * : 0 6 < � : 0 = 4 , 4 0 A 4 : 0 � : , D 6 < � 4 2 ( : . G = : , I 4 0

K M 4 A 2 P , * 4 0 2 4 . � * G 2 , * K T 2 4 . � V G 2 4 D G c � e � v � g e s y v e u p l � y i � � v e g a � p e l � e � c { � � e g _ � k | e i p �Z � � { p u � e g u c P X X X �

| � b y � k l � p { p � u k l | ` r k l Z y g g e u Z k { v y g � ^ y g i k { p u p l � � i { u v k v e i k � � p l e u z y g i y | e { � � e � � p l � �` l � � ^ g k l � e k l | � � � � i � e c e | p v y g u c ~ � � � � � P � ( 4 ~ 0 * � 4 . � : . 4 < * 0 [ � 6 0 [ T 6 [ 4 � Q 4 V : 0 .

2 ( 4 � 2 6 0 . 6 , . c l � i � e g P � Y a p l � e � v � g e s y v e u p l � y i � � v e g a � p e l � e � a � g p l � e g � � e g { k � c P X X X �

13

Page 24: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

14

Page 25: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� � � � � � � � � � � � � � � � � � � � � � � � � # � � � � & � � � * � � � . 0 � 3 � 5 7 & � � ; � � .

= > @ A B D E F @ H = @ B D J L B N A P Q F F J T V F D E @ H @ V N H >[ \ ] ^ _ ` b \ e ` g h j g b ] l ` \ _ ^ e n o e h g _ b ^ ` r g e u w r \ e w \

y e r z \ _ | r ` } g h ~ \ e e | } � z ^ e r ^� � | � g e � � � \ \ � | g � g � | � } � � | ^ l � � w r | � l ] \ e e � \ n l

E A B D � F @ H � � �[ r z r | r g e g h j g b ] l ` \ _ u w r \ e w \ ^ e n � o � _ w

[ \ ] ^ _ ` b \ e ` g h � � \ w ` _ r w ^ � � e � r e \ \ _ r e � ^ e n j g b ] l ` \ _ u w r \ e w \� g _ \ ^ � n z ^ e w \ n o e | ` r ` l ` \ g h u w r \ e w \ ^ e n � \ w � e g � g � }

w � ^ � | ^ � b g | ^ � � ^ r | ` � ^ w � � _

¤ ¥ ¦ § © ª « §¬ ­ ® ¯ ± ² ± ³ µ ¶ ® ¯ · ¹ ¯ ¯ ³ ¯ º ­ ³ ² ± ± » ® · ² º ® ¼ ½ ¼ ¾ ¿ ¼ ¶ ³ » · ­ ³ ·  ® ½ à º ¼ º ³ ¯ º à ³ ½ ³ µ ² º ® ¼ ½ ¾ µ ¼ ¿ ¯ ± ³ · ® Ä · ² º ® ¼ ½ ¯ Æ µ ® º º ³ ½ ® ½

¯ º ² º ³ · ­ ² µ º ¯ Ç È ³ · ¼ ½ ¯ ® ¶ ³ µ ² ¾ ² ¿ ® » Ê ¼ ¾ · ¼ Ë ³ µ ² à ³ · µ ® º ³ µ ® ² Ì ² ¯ ³ ¶ ¼ ½ º ­ ³ Í ¼ Æ ¼ ¾ · ¼ ½ º µ ¼ » ² ½ ¶ ¶ ² º ² ® ½ ¯ º ² º ³ · ­ ² µ º ¯² ½ ¶ ¾ ¼ µ ¿ ¹ » ² º ³ º ­ ³ ± µ ¼ Ì » ³ ¿ ¼ ¾ º ³ ¯ º à ³ ½ ³ µ ² º ® ¼ ½ ² ¯ Ä ½ ¶ ® ½ à · ¼ ¹ ½ º ³ µ ³ Ñ ² ¿ ± » ³ ¯ ¶ ¹ µ ® ½ à º ­ ³ ¿ ¼ ¶ ³ » · ­ ³ ·  ® ½ à ¼ ¾¯ º ² º ³ · ­ ² µ º ¯ Ç ¬ ­ ³ ² Ì ® » ® º Ê ¼ ¾ ¿ ¼ ¶ ³ » · ­ ³ ·  ³ µ ¯ º ¼ · ¼ ½ ¯ º µ ¹ · º · ¼ ¹ ½ º ³ µ ³ Ñ ² ¿ ± » ³ ¯ ² » » ¼ Æ ¯ º ³ ¯ º à ³ ½ ³ µ ² º ® ¼ ½ º ¼ Ì ³² ¹ º ¼ ¿ ² º ® · Ç

¬ ¼ ® » » ¹ ¯ º µ ² º ³ ¼ ¹ µ ² ± ± µ ¼ ² · ­ Ò Æ ³ ² µ ³ Ì ² ¯ ³ ¶ ¼ ½ º ­ ³ º ³ ¿ ± ¼ µ ² » » ¼ Ã ® · Ó ¬ Ô ² ½ ¶ ® º ¯ ¯ Ê ¿ Ì ¼ » ® · ¿ ¼ ¶ ³ » · ­ ³ · Â ³ µÕ Ö × Ç È ³ ¶ ³ ¯ · µ ® Ì ³ ­ ¼ Æ º ¼ º µ ² ½ ¯ » ² º ³ ¯ º ² º ³ · ­ ² µ º ¯ º ¼ ® ½ ± ¹ º ¯ º ¼ Õ Ö × ² ¾ º ³ µ ¶ ³ Ä ½ ® ½ Ã º ­ ³ ¯ ³ ¿ ² ½ º ® · ¯ ¼ ¾ ¯ º ² º ³ Ø

· ­ ² µ º ¯ ® ½ º ³ µ ¿ ¯ ¼ ¾ Ù µ ® ± Â ³ ¯ º µ ¹ · º ¹ µ ³ ¯ Ç È ³ Ò º ­ ³ ½ Ò ¶ ³ ¯ · µ ® Ì ³ ­ ¼ Æ º ¼ ³ Ñ ± µ ³ ¯ ¯ Ë ² µ ® ¼ ¹ ¯ · ¼ Ë ³ µ ² Ã ³ · µ ® º ³ µ ® ² ® ½ Ó ¬ Ô² ½ ¶ ¯ ­ ¼ Æ ­ ¼ Æ Õ Ö × · ² ½ Ì ³ ¹ ¯ ³ ¶ º ¼ Ã ³ ½ ³ µ ² º ³ ¼ ½ » Ê ³ Ñ ³ · ¹ º ² Ì » ³ º ³ ¯ º ¯ Ç

Ú Û Ü Ý Þ ß à á â Ý ã ß Ü

ä å æ ç è é è ê ë é ì ì ë ê ç ç ê ç í å ê è ë î ï ð ê ñ î ó í ê ç í ô ê õ ê ë é í æ î õ ó ë î ñ ç í é í ê ø å é ë í ç ù ú û ü í å é í å é ý ê ï ê ê õ þ æ ì ê ð � � ç ê ì ó î ëç è ê ø æ ó � æ õ ô ë ê é ø í æ ý ê ç � ç í ê ñ ç � � í é í ê ø å é ë í ç ø é õ ï ê ë ê ô é ë ì ê ì é ç ê í ê õ ì ê ì � õ æ í ê ç í é í ê ñ é ø å æ õ ê ç � � � � � í å é íç � è è î ë í í å ê å æ ê ë é ë ø å æ ø é ð é õ ì ø î õ ø � ë ë ê õ í ç í ë � ø í � ë ê î õ ç í é í ê ç é õ ì í å ê ø î ñ ñ � õ æ ø é í æ î õ ñ ê ø å é õ æ ç ñ í å ë î � ô å

ê ý ê õ í ï ë î é ì ø é ç í æ õ ô � � ñ î õ ô ç ê ý ê ë é ð ý é ë æ é õ í ç î ó ç í é í ê ø å é ë í ç ø î õ ç æ ì ê ë ê ì æ õ í å ê ð æ í ê ë é í � ë ê ù û ü � þ ê ø î õ ø ê õ í ë é í êî õ í å ê � ä � ä � � � ä � ç ê ñ é õ í æ ø ç ó î ë ç í é í ê ø å é ë í ç ù ú # ü � % � ë é è è ë î é ø å � å î þ ê ý ê ë � ø é õ ï ê æ ñ ñ ê ì æ é í ê ð � é è è ð æ ê ì í îî í å ê ë ý é ë æ é õ í ç î ó ç í é í ê ø å é ë í ç ç ê ñ é õ í æ ø ç � ó î ë ê é ñ è ð ê � í å ê + � , ç í é í ê ø å é ë í ç ù û . ü �

� ç í é í ê ø å é ë í ç è ê ø æ � ø é í æ î õ í � è æ ø é ð ð � é ð ð î þ ç é õ æ õ � õ æ í ê õ � ñ ï ê ë î ó ê ê ø � í æ î õ ç é õ ì å ê õ ø ê ê å é � ç í æ ý ê í ê ç í æ õ ôæ ç æ ñ è î ç ç æ ï ð ê � þ å æ ø å ë ê 4 � æ ë ê ç é ð ð í å ê è î ç ç æ ï ð ê ê ê ø � í æ î õ ç ï ê è ê ë ó î ë ñ ê ì � ä å ê è ë ê ý é ð ê õ í í ê ç í æ õ ô è ë é ø í æ ø ê æ ç í îø î õ ç í ë � ø í é í ê ç í ç � æ í ê � í å é í æ ç � é � õ æ í ê ç ê í î ó í ê ç í ç ê 4 � ê õ ø ê ç é ø ø î ë ì æ õ ô í î ø ê ë í é æ õ ø î ý ê ë é ô ê ø ë æ í ê ë æ é � � î ë í ê ç íø î ý ê ë é ô ê � þ ê é ì é è í í å ê õ î í æ î õ ç î ó ø î õ í ë î ð : î þ é õ ì ì é í é : î þ ø î ý ê ë é ô ê � ç ê ì í ë é ì æ í æ î õ é ð ð � æ õ ç î ó í þ é ë ê é õ ì

è ë î í î ø î ð í ê ç í æ õ ô í î ç í é í ê ø å é ë í ç � � î ë í ê ç í ô ê õ ê ë é í æ î õ � þ ê è ë ê ç ê õ í é õ é è è ë î é ø å í å é í æ õ ý î ð ý ê ç í å ê é è è ð æ ø é í æ î õ î óí å ê í ê ñ è î ë é ð ð î ô æ ø < ä , ù = ü é õ ì æ í ç ç � ñ ï î ð æ ø ñ î ì ê ð ø å ê ø > ê ë � � @ ù û ú ü í î ç í é í ê ø å é ë í ç �

� õ î ý ê ë ý æ ê þ î ó î � ë é è è ë î é ø å æ ç ç å î þ õ æ õ � æ ô � ë ê ú � ä å ê è ë î ï ð ê ñ î ó í ê ç í ô ê õ ê ë é í æ î õ æ ç ó î ë ñ � ð é í ê ì é ç é < ä ,ñ î ì ê ð ø å ê ø > æ õ ô è ë î ï ð ê ñ � � ô æ ý ê õ ø î ý ê ë é ô ê ø ë æ í ê ë æ î õ æ ç ê è ë ê ç ç ê ì é ç é è é ë é ñ ê í ê ë æ C ê ì ø î ð ð ê ø í æ î õ î ó ó î ë ñ � ð é çæ õ < ä , í å é í é ë ê æ õ ç í é õ í æ é í ê ì ó î ë é ô æ ý ê õ ç í é í ê ø å é ë í ç ç è ê ø æ � ø é í æ î õ � � é ø å ó î ë ñ � ð é ì ê ç ø ë æ ï ê ç é í ê ç í ç ê 4 � ê õ ø ê æ õé ï ç í ë é ø í í ê ë ñ ç æ õ ç � ø å é þ é � í å é í í å ê ó î ë ñ � ð é æ ç í ë � ê æ ó é õ ì î õ ð � æ ó é ç í é í ê ø å é ë í ç è ê ø æ � ø é í æ î õ ì î ê ç E G I é ð ð î þ

í å ê í ê ç í ç ê 4 � ê õ ø ê � J ó í å ê í ê ç í ç ê 4 � ê õ ø ê ì ê ç ø ë æ ï ê ì ï � í å ê ó î ë ñ � ð é ø é õ ï ê è ê ë ó î ë ñ ê ì ï � í å ê ç è ê ø æ � ø é í æ î õ � ñ î ì ê ðø å ê ø > æ õ ô þ æ ð ð ó é æ ð é õ ì í å ê í î î ð þ æ ð ð ô ê õ ê ë é í ê é ø î � õ í ê ë ê é ñ è ð ê ô æ ý æ õ ô é õ ê ê ø � í æ î õ ç ê 4 � ê õ ø ê í å é í ê è ð é æ õ ç þ å �

í å ê ó î ë ñ � ð é ø é õ õ î í ï ê ç é í æ ç � ê ì � ä å æ ç ø î � õ í ê ë ê é ñ è ð ê æ ç ê é ç æ ð � ñ é è è ê ì æ õ í î í å ê í ê ç í ç ê 4 � ê õ ø ê ï � è ë î K ê ø í æ õ ôæ í î õ í î í å ê î ï ç ê ë ý é ï ð ê ê ý ê õ í ç î ó í å ê ç è ê ø æ � ø é í æ î õ �

ä å ê ø î õ í ë æ ï � í æ î õ ç î ó í å æ ç è é è ê ë ø é õ ï ê ç � ñ ñ é ë æ C ê ì é ç ó î ð ð î þ ç � M ê ô æ ý ê é ó î ë ñ é ð ç ê ñ é õ í æ ø ç ó î ë ç í é í ê ø å é ë í çø î õ ç æ ç í ê õ í þ æ í å í å ê � ä � ä � � � ä � æ õ ó î ë ñ é ð æ õ í ê ë è ë ê í é í æ î õ � M ê é è è ð � é ó é ñ æ ð � î ó ø î õ í ë î ð Q : î þ é õ ì ì é í é Q

15

Page 26: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

SMV program

CTLformulas

tran

slat

e

criteriontest coverage

Statechartsspecification

test suiteSMV

inst

antia

te

� æ ô � ë ê ú � % ý ê ë ý æ ê þ î ó í ê ç í ô ê õ ê ë é í æ î õ

: î þ ø î ý ê ë é ô ê ø ë æ í ê ë æ é í î ç í é í ê ø å é ë í ç é õ ì ô æ ý ê é < ä , ø å é ë é ø í ê ë æ C é í æ î õ î ó ê é ø å ø î ý ê ë é ô ê ø ë æ í ê ë æ î õ � � æ õ é ð ð � �

þ ê ì ê ñ î õ ç í ë é í ê å î þ í î � ç ê � � @ � é õ î � Q í å ê Q ç å ê ð ó < ä , ñ î ì ê ð ø å ê ø > æ õ ô í î î ð � ó î ë í å ê è � ë è î ç ê î ó é � í î ñ é í æ ø

ô ê õ ê ë é í æ î õ î ó í ê ç í ç � æ í ê ç ó ë î ñ ç í é í ê ø å é ë í ç �

� � � � � � � � � � M æ ì ê ð � Q � ç ê ì ñ î ì ê ð ç ó î ë ë ê é ø í æ ý ê ç � ç í ê ñ ç æ õ í å ê í ê ç í æ õ ô ð æ í ê ë é í � ë ê æ õ ø ð � ì ê � õ æ í ê ç í é í ê ñ é Q

ø å æ õ ê ç � � � � � ê ç è ê ø æ é ð ð � æ õ å é ë ì þ é ë ê é õ ì è ë î í î ø î ð ø î õ ó î ë ñ é õ ø ê í ê ç í æ õ ô � � � � Q ï é ç ê ì í ê ç í æ õ ô ñ ê í å î ì ç è ë æ ñ é ë Q

æ ð � ó î ø � ç î õ í å ê ø î õ í ë î ð Q : î þ î ë æ ê õ í ê ì í ê ç í ô ê õ ê ë é í æ î õ ç � ø å é ç í ë é õ ç æ í æ î õ í î � ë � � õ æ 4 � ê Q æ õ è � í Q î � í è � í ç ê 4 � ê õ ø ê �

ì æ ç í æ õ ô � æ ç å æ õ ô ç ê 4 � ê õ ø ê � é õ ì ø å é ë é ø í ê ë æ C æ õ ô ç ê 4 � ê õ ø ê ç ê ê ù # � û � ü ó î ë ç � ë ý ê � � � J õ è ë î í î ø î ð ø î õ ó î ë ñ é õ ø ê í ê ç í æ õ ô �

í å ê ç ê ñ ê í å î ì ç å é ý ê ï ê ê õ ê í ê õ ç æ ý ê ð � é è è ð æ ê ì í î ó î ë ñ é ð ì ê ç ø ë æ è í æ î õ í ê ø å õ æ 4 � ê ç ù ú � ü ç � ø å é ç � � , é õ ì � ç í ê ð ð ê �

é õ ì é õ � ñ ï ê ë î ó é � í î ñ é í ê ì í î î ð ç å é ý ê ï ê ê õ ì ê ý ê ð î è ê ì ç ê ê ù � ü ó î ë ç � ë ý ê � � �

� � � � ç ê í ê õ ì � � � ç þ æ í å ý é ë æ é ï ð ê ç í î ç � è è î ë í í å ê ç � ø ø æ õ í ç è ê ø æ � ø é í æ î õ î ó ì é í é Q ì ê è ê õ ì ê õ í ï ê å é ý æ î ë ç �

J ó í å ê ç í é í ê ç è é ø ê î ó é õ � � � � æ ç � õ æ í ê � î õ ê ø é õ î ï í é æ õ í å ê ê 4 � æ ý é ð ê õ í � � � ï � � õ ó î ð ì æ õ ô í å ê � � � � � ä å � ç

í ê ç í æ õ ô ï é ç ê ì î õ � � � � ç þ æ í å � õ æ í ê ç í é í ê ç è é ø ê æ ç ë ê ì � ø ê ì æ õ è ë æ õ ø æ è ð ê í î í ê ç í æ õ ô ï é ç ê ì î õ î ë ì æ õ é ë � � � � ç �

ä å æ ç é è è ë î é ø å � å î þ ê ý ê ë � ç � � ê ë ç ó ë î ñ í å ê þ ê ð ð Q > õ î þ õ ç í é í ê ê è ð î ç æ î õ è ë î ï ð ê ñ þ å æ ø å ñ é > ê ç í ê ç í ô ê õ ê ë é í æ î õ

î ó í ê õ æ ñ è ë é ø í æ ø é ð � � ý ê õ þ å ê õ í ê ç í ô ê õ ê ë é í æ î õ æ ç ó ê é ç æ ï ð ê � í å æ ç é è è ë î é ø å æ ç î ó í ê õ æ ñ è ë é ø í æ ø é ð ï ê ø é � ç ê î ó í å ê í ê ç í

ê è ð î ç æ î õ è ë î ï ð ê ñ � æ � ê � � í å ê õ � ñ ï ê ë î ó ø î õ ç í ë � ø í ê ì í ê ç í ç ñ æ ô å í ï ê í î î å � ô ê í î ï ê é è è ð æ ê ì í î æ ñ è ð ê ñ ê õ í é í æ î õ ç

� õ ì ê ë í ê ç í �

� è ë î ñ æ ç æ õ ô é ð í ê ë õ é í æ ý ê æ ç í î é è è ð � ø î õ ý ê õ í æ î õ é ð ç î ó í þ é ë ê í ê ç í æ õ ô í ê ø å õ æ 4 � ê ç í î í å ê ô ê õ ê ë é í æ î õ î ó í ê ç í ç

ó ë î ñ � � � � ç � J õ í å æ ç é è è ë î é ø å � é õ � � � � æ ç í ë é õ ç ó î ë ñ ê ì æ õ í î é : î þ ô ë é è å í å é í ñ î ì ê ð ç í å ê : î þ î ó ï î í å

ø î õ í ë î ð é õ ì ì é í é î ó í å ê � � � � é õ ì í å ê õ í ê ç í ç é ë ê ô ê õ ê ë é í ê ì ï � æ ì ê õ í æ ó � æ õ ô ø î õ í ë î ð é õ ì ì é í é : î þ æ õ ó î ë ñ é í æ î õ

ç � ø å é ç ì ê � õ æ í æ î õ ç é õ ì � ç ê ç î ó ý é ë æ é ï ð ê ç æ õ í å ê : î þ ô ë é è å ù û � ü � ä å ê : î þ Q ô ë é è å í ê ç í ô ê õ ê ë é í æ î õ ñ ê í å î ì æ ç

é ð ç î é è è ð æ ê ì í î ç í é í ê ø å é ë í ç ù ú � ü � ä å æ ç é è è ë î é ø å é ï ç í ë é ø í ç ó ë î ñ í å ê ý é ð � ê ç î ó ý é ë æ é ï ð ê ç é õ ì å ê õ ø ê æ í ø é õ ï ê

é è è ð æ ø é ï ð ê ê ý ê õ æ ó í å ê ç í é í ê ç è é ø ê æ ç æ õ � õ æ í ê � ä å ê é è è ë î é ø å � å î þ ê ý ê ë � ë ê 4 � æ ë ê ç è î ç í ê ë æ î ë é õ é ð � ç æ ç ç � ø å é ç

ç � ñ ï î ð æ ø ê ê ø � í æ î õ î ë ø î õ ç í ë é æ õ í ç î ð ý æ õ ô í î ì ê í ê ë ñ æ õ ê í å ê ê ê ø � í é ï æ ð æ í � î ó í ê ç í ç é õ ì ó î ë í å ê í å ê ç ê ð ê ø í æ î õ î ó

ý é ë æ é ï ð ê ý é ð � ê ç þ å æ ø å ñ é > ê í ê ç í ç ê ê ø � í é ï ð ê �

ä å ê é è è ë î é ø å þ ê é ì ý î ø é í ê å ê ë ê æ ç ï é ç ê ì î õ í ë é õ ç ð é í æ õ ô ç í é í ê ø å é ë í ç æ õ í î � ë æ è > ê ç í ë � ø í � ë ê ç é õ ì é ð ç î ç � � ê ë ç

ó ë î ñ í å ê ç í é í ê ê è ð î ç æ î õ è ë î ï ð ê ñ � ! î þ ê ý ê ë � í å ê ó î ë ñ � ð é í æ î õ î ó í ê ç í ô ê õ ê ë é í æ î õ é ç ñ î ì ê ð ø å ê ø > æ õ ô æ õ î � ë

é è è ë î é ø å ê õ é ï ð ê ç í å ê � ç ê î ó ç � ñ ï î ð æ ø ñ î ì ê ð ø å ê ø > æ õ ô ù � ü � é í ê ø å õ æ 4 � ê í å é í å é ç ï ê ê õ è ë î ý ê õ ç � ø ø ê ç ç ó � ð ó î ë

ø î õ í ë î ð ð æ õ ô í å ê ç í é í ê ê è ð î ç æ î õ è ë î ï ð ê ñ � � ê ø î õ ì � î � ë é è è ë î é ø å î ý ê ë ø î ñ ê ç í å ê í ê ç í ê è ð î ç æ î õ è ë î ï ð ê ñ ï � � ç æ õ ô

í å ê : î þ æ õ ó î ë ñ é í æ î õ î ó ï î í å ø î õ í ë î ð é õ ì ì é í é ð æ > ê í å ê : î þ Q ô ë é è å é è è ë î é ø å � � æ õ é ð ð � � î � ë é è è ë î é ø å ø é õ ï ê

ç ê ê õ é ç ø î ñ è ð ê ñ ê õ í é ë � í î í å ê : î þ Q ô ë é è å é è è ë î é ø å � % õ í å ê î õ ê å é õ ì � : î þ ô ë é è å ç ø é õ ï ê ø î õ ç í ë � ø í ê ì ó î ë

ç � ç í ê ñ ç í å é í é ë ê õ î í � õ æ í ê Q ç í é í ê � % õ í å ê î í å ê ë å é õ ì � î � ë é è è ë î é ø å å é ç í å ê é ì ý é õ í é ô ê í å é í î õ ð � ê ê ø � í é ï ð ê

í ê ç í ç é ë ê è ë î ì � ø ê ì �

# ê ø ê õ í ð � ø î õ õ ê ø í æ î õ ç ï ê í þ ê ê õ í ê ç í ô ê õ ê ë é í æ î õ é õ ì ñ î ì ê ð ø å ê ø > æ õ ô å é ç ï ê ê õ ø î õ ç æ ì ê ë ê ì æ õ í å ê ð æ í ê ë é í � ë ê �

� í î î ð í å é í � ç ê ç í ê ç í ô ê õ ê ë é í æ î õ é ð ô î ë æ í å ñ ç æ õ ç è æ ë ê ì ï � ñ î ì ê ð ø å ê ø > æ õ ô é ð ô î ë æ í å ñ ç æ ç ì ê ç ø ë æ ï ê ì æ õ ù ú = ü �

ä ê ç í ô ê õ ê ë é í æ î õ � ç æ õ ô ø î � õ í ê ë ê é ñ è ð ê ç ø î õ ç í ë � ø í ê ì ï � ñ î ì ê ð ø å ê ø > ê ë ç å é ç ï ê ê õ é è è ð æ ê ì æ õ ç ê ý ê ë é ð ø î õ í ê í ç �

� � í é í æ î õ é õ é ð � ç æ ç æ ç � ç ê ì æ õ í å ê é è è ë î é ø å î ó ù ú ü � J õ ù $ ü � í ê ç í ô ê õ ê ë é í æ î õ æ ç è ê ë ó î ë ñ ê ì ó ë î ñ � ç ê ë Q ç è ê ø æ � ê ì

í ê ñ è î ë é ð ó î ë ñ � ð é ç � þ å æ ð ê æ õ ù ú � ü í ê ç í æ õ ô è � ë è î ç ê ç é ë ê � ç ê ì í î ô ê õ ê ë é í ê í ê ç í ç � % î ø î õ ç æ ì ê ë é í æ î õ æ ç ô æ ý ê õ í î

ø î ý ê ë é ô ê ø ë æ í ê ë æ é � � î ñ ê ø î õ í ë î ð Q : î þ ø î ý ê ë é ô ê ø ë æ í ê ë æ é é ë ê ø î õ ç æ ì ê ë ê ì æ õ ù ú ú ü � M ê é ë ê õ î í é þ é ë ê î ó é õ � þ î ë >

í å é í ø î õ ç æ ì ê ë ç í å ê ñ î ì ê ð ø å ê ø > æ õ ô é è è ë î é ø å í î ì é í é Q : î þ î ë æ ê õ í ê ì í ê ç í ô ê õ ê ë é í æ î õ �

' � ( � + - / � - � + � 2 3 � 4 � 4 � � � � ê ø í æ î õ û ë ê ý æ ê þ ç ç í é í ê ø å é ë í ç é õ ì < ä , ñ î ì ê ð ø å ê ø > æ õ ô � � ê ø í æ î õ # ô æ ý ê ç é ó î ë Q

ñ é ð ì ê � õ æ í æ î õ î ó í å ê � ä � ä � � � ä � ç ê ñ é õ í æ ø ç � � ê ø í æ î õ . æ õ í ë î ì � ø ê ç ç ê ý ê ë é ð õ î í æ î õ ç ë ê ð ê ý é õ í í î ç è ê ø æ � ø é í æ î õ Q

16

Page 27: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

ï é ç ê ì í ê ç í æ õ ô þ æ í å ç í é í ê ø å é ë í ç � � ê ø í æ î õ � é õ ì $ ì ê ç ø ë æ ï ê é ó é ñ æ ð � î ó ø î ý ê ë é ô ê ø ë æ í ê ë æ é é õ ì é í ê ç í ô ê õ ê ë é í æ î õ

ñ ê í å î ì � ë ê ç è ê ø í æ ý ê ð � � � æ õ é ð ð � � � ê ø í æ î õ � ø î õ ø ð � ì ê ç í å ê è é è ê ë þ æ í å é ì ê ç ø ë æ è í æ î õ î ó ó � í � ë ê þ î ë > �

� � Þ � � ã � ã Ü � Þ ã � �ä å æ ç ç ê ø í æ î õ è ë î ý æ ì ê ç é ï ë æ ê ó æ õ í ë î ì � ø í æ î õ í î ç í é í ê ø å é ë í ç é õ ì < ä , ñ î ì ê ð ø å ê ø > æ õ ô �

� � E � � � F � � � � � N

� � I � I � � ! � $ I æ ç é í � è ð ê & ( * � , � . � 0 � 1 � þ å ê ë ê * � , � . � é õ ì 1 é ë ê ç ê í ç î ó ç í é í ê ç � ê ý ê õ í ç � ý é ë æ é ï ð ê ç � é õ ì

í ë é õ ç æ í æ î õ ç � 0 æ ç é õ æ õ í ê ë è ë ê í é í æ î õ î ó . þ å æ ø å é ç ç æ ô õ ç í î ê é ø å ý é ë æ é ï ð ê æ í ç æ õ æ í æ é ð ý é ð � ê � ä î ì ê ñ î õ ç í ë é í ê í å ê

ñ é æ õ ó ê é í � ë ê ç î ó ç í é í ê ø å é ë í ç � þ ê � ç ê é ç í å ê ë � õ õ æ õ ô ê é ñ è ð ê í å ê ç í é í ê ø å é ë í ç å î þ õ æ õ � æ ô � ë ê û � þ å æ ø å ç è ê ø æ � ê ç

é ç æ ñ è ð ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê � ä å ê ý é ë æ é ï ð ê 8 æ õ � æ ô � ë ê û æ ç î ó æ õ í ê ô ê ë ç � ï ë é õ ô ê ù � � ú � ü é õ ì æ í ç æ õ æ í æ é ð ý é ð � ê

æ ç ì ê � õ ê ì ï � 0 8 � ( � �

; < >

?

@ A

B?

@ A

B

C D EF G GD

I JK

L

MN O P R T V X Y [ T ]^ _ ` a c d [ T ]e P f gN h P R T V X Y [ T j^ _ ` a c d [ T jF lI J

; F G G n nC D E

o p r nDI J

K s t u vDI J

KEN w P x T j X X y e z g |^ } d ~ Y d � � X x

� N � P � T ] X ^ } d T R> F l n vC D E

n > � � vDI J

K l F � n > � � vDI J

KL

N � P ` ] x y e � � g | ^ e P f e � �

MN � P � X x y e z � | ^ e P f e � �

EN � P ` ] x ^ e P f �� N � P � X x y e f � | ^ e P f g

� æ ô � ë ê û � � é ñ è ð ê î ó � í é í ê ø å é ë í ç ç è ê ø æ � ø é í æ î õ

% õ ê î ó í å ê ñ é æ õ ó ê é í � ë ê ç î ó ç í é í ê ø å é ë í ç æ ç í å ê å æ ê ë é ë ø å æ ø é ð é õ ì ø î õ ø � ë ë ê õ í ç í ë � ø í � ë ê î õ ç í é í ê ç � � ç í é í ê æ ç

ê æ í å ê ë ï é ç æ ø î ë ø î ñ è î ç æ í ê � � ø î ñ è î ç æ í ê ç í é í ê æ ç ø ð é ç ç æ � ê ì é ç ê æ í å ê ë % # Q ç í é í ê î ë � % � Q ç í é í ê � � õ % # Q ç í é í ê å é ç

ç � ï ç í é í ê ç ë ê ð é í ê ì ï � ê ø ð � ç æ ý ê Q î ë Q ë ê ð é í æ î õ é õ ì å é ç ê é ø í ð � î õ ê ì ê ó é � ð í ç � ï ç í é í ê � � î ë ê é ñ è ð ê � í å ê % # Q ç í é í ê� � � æ õ � æ ô � ë ê û ø î õ ç æ ç í ç î ó � � � é õ ì � � þ æ í å � � � é ç æ í ç ì ê ó é � ð í ç � ï ç í é í ê � � ê æ õ ô æ õ � � � æ ñ è ð æ ê ç ï ê æ õ ô æ õ � � �î ë æ õ � � � ï � í õ î í æ õ ï î í å � � õ � % � Q ç í é í ê å é ç ç � ï ç í é í ê ç ë ê ð é í ê ì ï � é õ ì Q ë ê ð é í æ î õ � � ê æ õ ô æ õ í å ê � % � Q ç í é í ê � �æ ñ è ð æ ê ç ï ê æ õ ô æ õ � � � � � � é õ ì � � � � � é í í å ê ç é ñ ê í æ ñ ê � ä å ê ë ê æ ç é � õ æ 4 � ê ç í é í ê ø é ð ð ê ì í å ê $ G G I é í í å ê å æ ô å ê ç í

ð ê ý ê ð î õ í å ê ç í é í ê å æ ê ë é ë ø å � � ç é � � � � �

� î ë é ç í é í ê ¡ � ì ê � õ ê � ! ¢ £ ¤ $ � E ¡ � é ç í å ê ç ê í î ó ç � ï ç í é í ê ç î ó ¡ é õ ì � ! ¢ £ ¤ $ � E ¥ é ç í å ê ë ê : ê æ ý ê Q í ë é õ ç æ í æ ý ê ø ð î ç � ë ê

î ó � ! ¢ £ ¤ $ � E � � î ë í þ î ç í é í ê ç ¡ § é õ ì ¡ © � ¡ § æ ç é õ � E � � � I G $ î ó ¡ © æ ó ¡ © « � ! ¢ £ ¤ $ � E ¥ ¡ § � � J ó � æ õ é ì ì æ í æ î õ � ¡ § ­( ¡ © �

þ ê ç é � í å é í ¡ § æ ç é � I $ ¢ � I � E � � � I G $ î ó ¡ © �

� � G E ¯ ° ± $ � I ¢ G E æ ç é ñ é æ ñ é ð ç ê í î ó ç í é í ê ç æ õ þ å æ ø å é ç � ç í ê ñ ø é õ ï ê ç æ ñ � ð í é õ ê î � ç ð � � ² ë ê ø æ ç ê ð � � ³ ´ * æ ç

ø é ð ð ê ì é ø î õ � ô � ë é í æ î õ æ ó æ � ³ ø î õ í é æ õ ç í å ê ë î î í ç í é í ê ¶ æ æ � ó î ë ê ý ê ë � � % � Q ç í é í ê ¡ � ê æ í å ê ë ¡ é õ ì é ð ð ç � ï ç í é í ê ç

î ó ¡ é ë ê æ õ ³ î ë í å ê � é ë ê é ð ð õ î í æ õ ³ ¶ æ æ æ � ó î ë ê ý ê ë � % # Q ç í é í ê ¡ � ê æ í å ê ë ¡ é õ ì ê é ø í ð � î õ ê ç � ï ç í é í ê î ó ¡ é ë ê

17

Page 28: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

æ õ ³ î ë ¡ é õ ì é ð ð ç � ï ç í é í ê ç î ó ¡ é ë ê õ î í æ õ ³ � � é ø å ø î õ � ô � ë é í æ î õ ø é õ ï ê � õ æ 4 � ê ð � ø å é ë é ø í ê ë æ C ê ì ï � æ í ç ï é ç æ ø

ç í é í ê ç � J õ � æ ô � ë ê û � þ ê å é ý ê í å ê ó î ð ð î þ æ õ ô ø î õ � ô � ë é í æ î õ ç þ æ í å � � � � � é ç í å ê æ õ æ í æ é ð ø î õ � ô � ë é í æ î õ�

� � � � � �

� � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �

M ê è é ë í æ í æ î õ í å ê ç ê í , î ó ê ý ê õ í ç æ õ í î í å ë ê ê ì æ ç K î æ õ í ç � ï ç ê í ç , � � , � é õ ì , � ø î ñ è ë æ ç æ õ ô ¢ E � ± I � £ G � � £ �

é õ ì G ± I � ± I ê ý ê õ í ç � ë ê ç è ê ø í æ ý ê ð � � ä å ê î ø ø � ë ë ê õ ø ê î ó æ õ è � í ê ý ê õ í ç æ ç ì ê í ê ë ñ æ õ ê ì ï � í å ê ê õ ý æ ë î õ ñ ê õ í î ó é

ç � ç í ê ñ þ å æ ð ê ð î ø é ð é õ ì î � í è � í ê ý ê õ í ç é ë ê ô ê õ ê ë é í ê ì ï � í å ê ç � ç í ê ñ æ í ç ê ð ó � , î ø é ð ê ý ê õ í ç é ë ê � ç ê ì ó î ë æ õ í ê ë õ é ð

ø î ñ ñ � õ æ ø é í æ î õ ç é õ ì é ë ê é ç ç � ñ ê ì í î ï ê æ õ ý æ ç æ ï ð ê í î í å ê ê õ ý æ ë î õ ñ ê õ í � J õ è � í é õ ì î � í è � í ê ý ê õ í ç é ë ê ý æ ç æ ï ð ê

í î í å ê ê õ ý æ ë î õ ñ ê õ í é õ ì ø î õ ç í æ í � í ê í å ê G � � � $ � � � £ � � î ó é ç í é í ê ø å é ë í � J õ � æ ô � ë ê û � þ ê å é ý ê , � ( � � G � � $ � G E �

� G � � $ � G � � G � � � ¤ G E � � ¢ E � � � , � ( � ¤ � � � � é õ ì , � ( � £ ¢ ° ! I � G E � £ ¢ ° ! I � G � � I � $ I � � I G � � �

� í ë é õ ç æ í æ î õ & æ ç é í � è ð ê � G ± $ � � & � � I $ ¢ ° ° � $ & � ° ± � $ ¤ & � � � � I ¢ G E & � � I � $ ° � I & � � þ å ê ë ê � G ± $ � � & � � I � $ ° � I & � « * �

I $ ¢ ° ° � $ & � æ ç é è ë ê ì æ ø é í ê î õ , � ° ± � $ ¤ & � æ ç é è ë ê ì æ ø é í ê î õ . � � � I ¢ G E & � ø î õ ç æ ç í ç î ó é ç ê í î ó é ç ç æ ô õ ñ ê õ í ç í î . �

ì ê õ î í ê ì ï � � � � ¢ ° E * � E I � & � � é õ ì é ç ê í î ó ê ý ê õ í ç æ õ , � , , � � ì ê õ î í ê ì ï � ° � E � $ � I � ¤ & � �

� î ë é í ë é õ ç æ í æ î õ & � ì ê � õ ê / 1 ¢ I � & � ë ê ç è � / E I � $ � & � � é ç í å ê ç ê í î ó ç í é í ê ç í å é í é ç � ç í ê ñ ê æ í ç ë ê ç è � ê õ í ê ë ç �

î õ í é > æ õ ô í ë é õ ç æ í æ î õ & � � î ë ê é ñ è ð ê � þ ê å é ý ê í å é í / 1 ¢ I � & § � ( � � � � � é õ ì / E I � $ � & § � ( � � � � � � � � � � � � � � � �

� � � � � � � � � � � � ä å ê ó î ë ñ é ð ì ê � õ æ í æ î õ ó î ë / 1 ¢ I � & � é õ ì / E I � $ � & � ø é õ ï ê ó î � õ ì æ õ ù � ü � ä å ê � � G � � î ó é

í ë é õ ç æ í æ î õ & � ì ê õ î í ê ì ï � � � G � � & � � æ ç ì ê � õ ê ì é ç í å ê ð î þ ê ç í % # Q ç í é í ê æ õ í å ê ç í é í ê å æ ê ë é ë ø å � í å é í æ ç é è ë î è ê ë

é õ ø ê ç í î ë î ó ï î í å � G ± $ � � & � é õ ì I � $ ° � I & � � � î ë ê é ñ è ð ê � � � G � � & © � ( � � � é õ ì � � G � � & 9 � ( � � � � � � � ä þ î

í ë é õ ç æ í æ î õ ç & é õ ì & ; � G E < ¢ � I æ ó � � G � � & � æ ç é õ é õ ø ê ç í î ë î ó � � G � � & ; � � � � î ë ê é ñ è ð ê � & © é õ ì & 9 ø î õ : æ ø í ï ê ø é � ç ê

� � � æ ç é õ é õ ø ê ç í î ë î ó � � � � � � �

� � ? Q A @ C F V � � F � H E B D

� � ñ ï î ð æ ø ñ î ì ê ð ø å ê ø > æ õ ô ù � ü æ ç é è ë î ý ê õ ç � ø ø ê ç ç ó � ð í ê ø å õ æ 4 � ê ó î ë í å ê é � í î ñ é í æ ø ý ê ë æ � ø é í æ î õ î ó � õ æ í ê ç í é í ê

ç � ç í ê ñ ç � � þ æ ì ê ð � Q � ç ê ì í ê ñ è î ë é ð ð î ô æ ø ó î ë ç � ñ ï î ð æ ø ñ î ì ê ð ø å ê ø > æ õ ô æ ç í å ê ï ë é õ ø å æ õ ô í æ ñ ê í ê ñ è î ë é ð ð î ô æ ø

< ä , ù = ü � , ê í F H ï ê í å ê � õ ì ê ë ð � æ õ ô ç ê í î ó é í î ñ æ ø è ë î è î ç æ í æ î õ ç � ä å ê ç � õ í é ó î ë < ä , æ ç ì ê � õ ê ì ï � í å ê

ó î ð ð î þ æ õ ô ô ë é ñ ñ é ë�

I� �

( J L M I L I O I ; L Q R I L F R I L Q ù I T I ; ü L F ù I T I ; ü

þ å ê ë ê J « F H é õ ì I X I ; ë é õ ô ê î ý ê ë < ä , ó î ë ñ � ð é ç � ä å ê ë ê ñ é æ õ æ õ ô í ê ñ è î ë é ð î è ê ë é í î ë ç é ë ê ì ê � õ ê ì ï � í å ê

ê 4 � æ ý é ð ê õ ø ê ë � ð ê ç�

Q Y I [ Q ù & \ ^ _ T I ü ¶ F Y I [ F ù & \ ^ _ T I ü ¶ Q b I [ M F Y M I � ¶ F b I [ M Q Y M I � �

ä å ê ç ê ñ é õ í æ ø ç î ó < ä , æ ç ì ê � õ ê ì þ æ í å ë ê ç è ê ø í í î é e $ ¢ � f � � I $ ± � I ± $ � h ( i X i j X k X m � þ å ê ë ê i æ ç é � õ æ í ê

ç ê í î ó ç í é í ê ç ¶ i j ´ i æ ç í å ê ç ê í î ó æ õ æ í æ é ð ç í é í ê ç ¶ k�

i n û p q æ ç í å ê ç í é í ê Q ð é ï ê ð æ õ ô ó � õ ø í æ î õ ¶ é õ ì m ´ i s iæ ç í å ê ç ê í î ó í ë é õ ç æ í æ î õ ç � � ç ê 4 � ê õ ø ê v j � v § � v © � � � � î ó ç í é í ê ç æ ç é � � I ! æ ó v w X v w y § � « m ó î ë é ð ð { | � � � è é í å }æ ç é v Q è é í å æ ó } � � ( v � ä å ê ç é í æ ç ó é ø í æ î õ ë ê ð é í æ î õ L ( æ ç æ õ ì � ø í æ ý ê ð � ì ê � õ ê ì é ç ó î ð ð î þ ç

~ v L ( J æ � J « k v � ¶ v L ( M I æ � M v L ( I � ¶ v L ( I O I ; æ � v L ( I é õ ì v L ( I ; ¶

~ v L ( Q R I ë ê ç è � F R I � æ � ó î ë ç î ñ ê ë ê ç è � é ð ð � v Q è é í å } � } ú � L ( I ¶

~ v L ( Q ù I T I ; ü ë ê ç è � F ù I T I ; ü � æ � ó î ë ç î ñ ê ë ê ç è � é ð ð � v Q è é í å } � í å ê ë ê ê æ ç í ç { | � ç � ø å í å é í } { � L ( I ;é õ ì } � � L ( I ó î ë é ð ð � � � � { �

� � @ ù û ú ü æ ç é ç � ñ ï î ð æ ø ñ î ì ê ð ø å ê ø > ê ë ó î ë < ä , þ å æ ø å ë ê è ë ê ç ê õ í ç í å ê ç í é í ê ç è é ø ê é õ ì í ë é õ ç æ í æ î õ ë ê ð é í æ î õ î ó

� ë æ è > ê ç í ë � ø í � ë ê ç � ç æ õ ô % � � � ç ù . ü � � õ � � @ è ë î ô ë é ñ ø î õ í é æ õ ç é ç ê í î ó ý é ë æ é ï ð ê ì ê ø ð é ë é í æ î õ ç í î ì ê í ê ë ñ æ õ ê

æ í ç ç í é í ê ç è é ø ê é õ ì ì ê ç ø ë æ è í æ î õ ç î ó í å ê æ õ æ í æ é ð ç í é í ê ç é õ ì í ë é õ ç æ í æ î õ ë ê ð é í æ î õ � é ç þ ê ð ð é ç é ð æ ç í î ó < ä , ó î ë ñ � ð é ç

í î ï ê ø å ê ø > ê ì � � æ ý ê õ é ç � ç í ê ñ ñ î ì ê ð é õ ì é < ä , ó î ë ñ � ð é � � � @ é � í î ñ é í æ ø é ð ð � è ë î ý æ ì ê ç ê æ í å ê ë é ø ð é æ ñ í å é í

í å ê ó î ë ñ � ð é æ ç ç é í æ ç � ê ì æ õ í å ê ç � ç í ê ñ ñ î ì ê ð î ë ê ð ç ê é ø î � õ í ê ë ê é ñ è ð ê ó é ð ç æ ó � æ õ ô í å ê ó î ë ñ � ð é �

, ê í . ï ê é ç ê í î ó ý é ë æ é ï ð ê ç � M ê ø é ð ð � ; é ç í å ê è ë æ ñ ê ì ý ê ë ç æ î õ î ó é ý é ë æ é ï ð ê � « . é õ ì � ç ê . ; í î ì ê õ î í ê

í å ê ç ê í î ó è ë æ ñ ê ì ý ê ë ç æ î õ ç î ó é ð ð ý é ë æ é ï ð ê ç æ õ . � M ê ì ê � õ ê é � � � � $ G ° $ � * é ç é í � è ð ê . � � E ¢ I � � $ � E � � þ å ê ë ê

. æ ç é � õ æ í ê ç ê í î ó ý é ë æ é ï ð ê ç ¶ � E ¢ I æ ç é è ë ê ì æ ø é í ê î õ . ¶ é õ ì � $ � E � æ ç é è ë ê ì æ ø é í ê î õ . , . ; � , ê í � . � ï ê í å ê

ç ê í î ó é ð ð æ õ í ê ë è ë ê í é í æ î õ ç î ó . � � � � @ è ë î ô ë é ñ . � � E ¢ I � � $ � E � � ì ê � õ ê ç í å ê � ë æ è > ê ç í ë � ø í � ë ê i � i j � k � m �

ç � ø å í å é í i ( � . � ¶ i j ( � � « � . � L � L ( � E ¢ I � ¶ k � � ( � � ( � � � L � « . � � ó î ë ê é ø å � « � . � ¶ � X � ; �

« m æ ó é õ ì î õ ð � æ ó � � X � ; � L ( � $ � E � � þ å ê ë ê � � X � ; � æ ç í å ê æ õ í ê ë è ë ê í é í æ î õ í å é í é ç ç æ ô õ ç � � � í î � « . é õ ì � ; � �

í î � ; « . ; �

18

Page 29: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� � � ß Þ � � � � � � Ü ã Ý ã ß Ü ß � Ý � � � � � � � � � � � Ü Ý ã â �

ä å æ ç ç ê ø í æ î õ ó î ë ñ é ð ð � ì ê � õ ê ç é ç í é í ê ø å é ë í é ç é � ë æ è > ê ç í ë � ø í � ë ê ï é ç ê ì î õ í å ê � ä � ä � � � ä � ç ê ñ é õ í æ ø ç � M êø é ð ð ê é ø å ê ð ê ñ ê õ í æ õ i î ó é � ë æ è > ê ç í ë � ø í � ë ê i � i j � k � m � é ° £ G � � £ � I � I � í î ì æ ç í æ õ ô � æ ç å æ í ó ë î ñ é ç í é í êî ó � í é í ê ø å é ë í ç � � æ ñ æ ð é ë ð � þ ê ø é ð ð ê é ø å ê ð ê ñ ê õ í æ õ m é ç é ° £ G � � £ I $ � E � ¢ I ¢ G E � ä å ê ó î ë ñ é ð æ C é í æ î õ æ ç � ç ê ì é ç

í å ê ç ê ñ é õ í æ ø ó î � õ ì é í æ î õ î ó í å ê í ê ç í ø î ý ê ë é ô ê ø ë æ í ê ë æ é é õ ì í ê ç í ô ê õ ê ë é í æ î õ ñ ê í å î ì è ë ê ç ê õ í ê ì æ õ í å ê ó î ð ð î þ æ õ ôç ê ø í æ î õ ç �

ä å ê � ä � ä � � � ä � ç ê ñ é õ í æ ø ç � ç ê ç í å ê ç ê í î ó õ î õ õ ê ô é í æ ý ê æ õ í ê ô ê ë ç � é ç í å ê í æ ñ ê ì î ñ é æ õ é õ ì è ë î ý æ ì ê çí þ î ñ î ì ê ð ç î ó í æ ñ ê � ç � õ ø å ë î õ î � ç é õ ì é ç � õ ø å ë î õ î � ç � ä å ê ñ é æ õ õ î í æ î õ î ó í å ê � ä � ä � � � ä � ç ê ñ é õ í æ ø ç æ ç éç í ê è � � ç í ê è ë ê è ë ê ç ê õ í ç í å ê ë ê ç è î õ ç ê î ó é ç � ç í ê ñ í î í å ê æ õ è � í ê ý ê õ í ç ô ê õ ê ë é í ê ì ï � í å ê ê õ ý æ ë î õ ñ ê õ í î ë í å êð î ø é ð ê ý ê õ í ç ô ê õ ê ë é í ê ì ï � í å ê ç � ç í ê ñ æ í ç ê ð ó � � î í å í æ ñ ê ñ î ì ê ð ç é ç ç � ñ ê í å é í í å ê ê ê ø � í æ î õ î ó é ç í ê è í é > ê çC ê ë î í æ ñ ê é õ ì ì æ � ê ë æ õ í å ê þ é � î ó å î þ í æ ñ ê æ ç é ì ý é õ ø ê ì ë ê ð é í æ ý ê í î í å ê ê ê ø � í æ î õ î ó ç í ê è ç � J õ í å ê ó î ë ñ ê ëñ î ì ê ð � í æ ñ ê æ ç æ õ ø ë ê ñ ê õ í ê ì ï � î õ ê í æ ñ ê � õ æ í é ó í ê ë í å ê ê ê ø � í æ î õ î ó ê é ø å ç í ê è � ä å æ ç í æ ñ ê ñ î ì ê ð æ ç ñ é æ õ ð �� ç ê ì ó î ë å æ ô å ð � ç � õ ø å ë î õ î � ç ç � ç í ê ñ ç ç � ø å é ç ç � õ ø å ë î õ î � ç ø æ ë ø � æ í ç � J õ í å ê ð é í í ê ë � ç ê ý ê ë é ð ç í ê è ç é ë ê é ð ð î þ ê ìí î í é > ê è ð é ø ê þ æ í å æ õ é ç æ õ ô ð ê è î æ õ í æ õ í æ ñ ê é õ ì í æ ñ ê æ ç æ õ ø ë ê ñ ê õ í ê ì î õ ð � þ å ê õ í å ê ç � ç í ê ñ ï ê ø î ñ ê ç ç í é ï ð ê �J õ í � æ í æ ý ê ð � � ç í é ï æ ð æ í � ñ ê é õ ç í å é í ó � ë í å ê ë ç í ê è ç é ë ê æ ñ è î ç ç æ ï ð ê þ æ í å î � í õ ê þ æ õ è � í ê ý ê õ í ç � ä å æ ç è é è ê ë ó î ø � ç ê çî õ í å ê é ç � õ ø å ë î õ î � ç í æ ñ ê ñ î ì ê ð �

� � � � 4 � � � � M ê ô æ ý ê é ç ê í î ó ë � ð ê ç í å é í æ ì ê õ í æ ó � ê é ø å ø î ñ è î õ ê õ í î ó é � ë æ è > ê ç í ë � ø í � ë ê ó ë î ñ é ô æ ý ê õç í é í ê ø å é ë í � � æ ë ç í þ ê ë ê è ë ê ç ê õ í í å ê ç í é í ê ç è é ø ê î ó é ç í é í ê ø å é ë í & ( * � , � . � 0 � 1 � � ç æ õ ô í å ê ó î ð ð î þ æ õ ô ç ê í î óô ð î ï é ð ç í é í ê ç �

i ( � G E ¯ ° s � . � s û � s û " �

þ å ê ë ê � G E ¯ ° æ ç í å ê ç ê í î ó é ð ð ø î õ � ô � ë é í æ î õ ç î ó & � � . � æ ç í å ê ç ê í î ó é ð ð æ õ í ê ë è ë ê í é í æ î õ ç î ó . � é õ ì % 1 æ ç í å êç ê í î ó æ ñ è ð æ ø æ í í ë é õ ç æ í æ î õ ç þ å æ ø å ç å é ð ð ï ê ì æ ç ø � ç ç ê ì æ õ í å ê õ ê í ç ê ø í æ î õ � ä å ê ç ê í i î ó ô ð î ï é ð ç í é í ê ç ø é è í � ë ê ç

í å ê ó î ð ð î þ æ õ ô æ õ ó î ë ñ é í æ î õ é ï î � í é ç í é í ê ø å é ë í � æ � í å ê ç í é í ê ç æ õ þ å æ ø å é ç � ç í ê ñ æ ç ¶ æ æ � í å ê ý é ð � ê ç î ó ý é ë æ é ï ð ê ç ¶ æ æ æ � í å ê ê ý ê õ í ç ô ê õ ê ë é í ê ì ¶ æ ý � í å ê í ë é õ ç æ í æ î õ ç í é > ê õ �

ä å ê ç ê í î ó æ õ æ í æ é ð ô ð î ï é ð ç í é í ê ç æ ç ì ê � õ ê ì é ç ó î ð ð î þ ç � ³ j X � j X Q j X ' j � « i j æ ó ³ j æ ç í å ê æ õ æ í æ é ð ø î õ � ô � ë é í æ î õ �� j ( 0 � Q j « , � � é õ ì ' j ( ) � ä å æ ç ì ê � õ æ í æ î õ ç í é í ê ç í å é í î õ ð � æ õ è � í ê ý ê õ í ç ø é õ ï ê ô ê õ ê ë é í ê ì é õ ì õ î

í ë é õ ç æ í æ î õ ç é ë ê í é > ê õ è ë æ î ë í î í å ê ç � ç í ê ñ æ õ æ í æ é ð æ C é í æ î õ �

ä å ê ì ê � õ æ í æ î õ î ó í å ê ð é ï ê ð î ó ê é ø å ô ð î ï é ð ç í é í ê ³ X � X Q X ' � æ ç ç í ë é æ ô å í ó î ë þ é ë ì �

k ³ X � X Q X ' � � ( { + ³ � , � � ( � � � L � « . � , Q , '

þ å ê ë ê { + ³ � æ ç é ç ê í î ó è ë î è î ç æ í æ î õ ç ì ê � õ ê ì é ç � { + ¡ � L ¡ « ³ � �

- � � + � - - � + � � � � - � + � J õ í å ê é ç � õ ø å ë î õ î � ç í æ ñ ê ñ î ì ê ð � æ õ è � í ê ý ê õ í ç ø é õ ï ê æ õ í ë î ì � ø ê ì í î é ç � ç í ê ñ î õ ð �þ å ê õ í å ê ç � ç í ê ñ ï ê ø î ñ ê ç ç í é ï ð ê � % õ ø ê æ õ è � í ê ý ê õ í ç é ë ê æ õ í ë î ì � ø ê ì � é ç ê 4 � ê õ ø ê î ó ç í ê è ç æ ç ê ê ø � í ê ì � õ í æ ð í å êç � ç í ê ñ ï ê ø î ñ ê ç ç í é ï ð ê é ô é æ õ � � ô ð î ï é ð ç í é í ê ³ X � X Q X ' � æ ç � I � � £ � æ ó í å ê ë ê ê æ ç í ç õ î ô ê õ ê ë é í ê ì æ õ è � í î ë ð î ø é ðê ý ê õ í � æ � ê � � Q 0 , � , , � � ( ) � é õ ì í å ê ë ê ê æ ç í ç õ î í ë é õ ç æ í æ î õ í å é í ñ é � î ø ø � ë é í í å é í ç í é í ê �

M ê ë ê è ë ê ç ê õ í í å ê í ë é õ ç æ í æ î õ ë ê ð é í æ î õ î ó é ç í é í ê ø å é ë í ï � í å ê ç ê í î ó ô ð î ï é ð í ë é õ ç æ í æ î õ ç m ( m § , m © � þ å ê ë êê é ø å ô ð î ï é ð í ë é õ ç æ í æ î õ æ õ m § ë ê ç è � m © � æ ç ø é ð ð ê ì � I � � ë ê ç è � I ¢ � f � � � ç í ê è í ë é õ ç æ í æ î õ ç í é ë í ç ó ë î ñ é õ î õ ç í é ï ð êô ð î ï é ð ç í é í ê é õ ì ñ é õ æ è � ð é í ê ç ø î õ � ô � ë é í æ î õ ç � ý é ë æ é ï ð ê ç é õ ì ð î ø é ð é õ ì î � í è � í ê ý ê õ í ç � þ å æ ð ê é í æ ø > í ë é õ ç æ í æ î õç í é ë í ç ó ë î ñ é ç í é ï ð ê ô ð î ï é ð ç í é í ê é õ ì ñ é õ æ è � ð é í ê ç æ õ è � í ê ý ê õ í ç �

2 � 3 + - - � + 5 � 7 , ê í ³ X � X Q X ' � é õ ì ³ ; X � ; X Q ; X ' ; � ï ê ô ð î ï é ð ç í é í ê ç � ³ X � X Q X ' � � ³ ; X � ; X Q ; X ' ; � � æ ç é � I � �

I $ � E � ¢ I ¢ G E æ ó é õ ì î õ ð � æ ó ú � ³ X � X Q X ' � æ ç õ î í ç í é ï ð ê ¶ û � ³ ; ( ³ 9 : < > ? @ Q B { & ¡ & � � , : < > ? @ Q + & _ \ ¡ & � ¶ # � � ;

( E � � X þ å ê ë ê E ( : < > ? @ � � � ¢ ° E * � E I � & � ¶ . � Q ; ( : < > ? @ ° � E � $ � I � ¤ & � ¶ � � ê é ø å í ë é õ ç æ í æ î õ & « ' ; æ ç ê õ é ï ð ê ìé í ³ X � � � æ � ê � � � G ± $ � � & � « ³ é õ ì � L ( ° ± � $ ¤ & � � é õ ì æ ç í ë æ ô ô ê ë ê ì ï � Q � æ � ê � � I $ ¢ ° ° � $ & � ê ý é ð � é í ê ç í î í ë � ê ó î ë Q ¶

õ î í þ î í ë é õ ç æ í æ î õ ç æ õ ' ; ø î õ : æ ø í ¶ é õ ì ' ; æ ç ñ é æ ñ é ð � æ � ê � � ê é ø å í ë é õ ç æ í æ î õ õ î í æ õ ' ; ï � í í ë æ ô ô ê ë ê ì ï � Q é õ ìê õ é ï ð ê ì é í ³ X � � ø î õ : æ ø í ç þ æ í å ç î ñ ê í ë é õ ç æ í æ î õ æ õ ' ; �

2 � 3 + - - � + 5 � F , ê í ³ X � X Q X ' � é õ ì ³ ; X � ; X Q ; X ' ; � ï ê ô ð î ï é ð ç í é í ê ç � ³ X � X Q X ' � � ³ ; X � ; X Q ; X ' ; � � æ ç é I ¢ � fI $ � E � ¢ I ¢ G E æ ó é õ ì î õ ð � æ ó ³ X � X Q X ' � æ ç ç í é ï ð ê ¶ ³ ; ( ³ ¶ � ; ( � ¶ Q ; ´ , � ¶ ' ; ( ) �

19

Page 30: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

J õ í � æ í æ ý ê ð � � é ç í ê è í ë é õ ç æ í æ î õ ³ X � X Q X ' � � ³ ; X � ; X Q ; X ' ; � � ø î ë ë ê ç è î õ ì ç í î í å ê ê ê ø � í æ î õ î ó í å ê í ë é õ ç æ í æ î õ ç æ õ

' ; � � í æ ø > í ë é õ ç æ í æ î õ ø î ë ë ê ç è î õ ì ç í î í å ê æ õ í ë î ì � ø í æ î õ î ó æ õ è � í ê ý ê õ í ç í î é ç � ç í ê ñ �

� � + � � � � - + - � � � � ç í é í ê ø å é ë í & æ ç ¤ � I � $ * ¢ E ¢ � I ¢ � æ ó ê é ø å õ î õ Q ç í é ï ð ê ô ð î ï é ð ç í é í ê å é ç î õ ð � î õ ê ç � ø ø ê ç ç î ë �

% î í ê í å é í ç í é ï ð ê ô ð î ï é ð ç í é í ê ç ñ é � å é ý ê ñ î ë ê í å é õ î õ ê ç � ø ø ê ç ç î ë ï ê ø é � ç ê í æ ø > í ë é õ ç æ í æ î õ ç ø î ë ë ê ç è î õ ì í î í å ê

æ õ í ë î ì � ø í æ î õ î ó æ õ è � í ê ý ê õ í ç � J õ í å æ ç è é è ê ë � þ ê ø î õ ç æ ì ê ë í ê ç í ô ê õ ê ë é í æ î õ î õ ð � ó î ë ì ê í ê ë ñ æ õ æ ç í æ ø � í é í ê ø å é ë í ç �

� ê ø í æ î õ � ì æ ç ø � ç ç ê ç é þ é � í î ê í ê õ ì î � ë é è è ë î é ø å í î õ î õ Q ì ê í ê ë ñ æ õ æ ç í æ ø � í é í ê ø å é ë í ç �

J õ î ë ì ê ë í î ë ê ç î ð ý ê ø ê ë í é æ õ ø ð é ç ç ê ç î ó õ î õ ì ê í ê ë ñ æ õ æ ç ñ � í å ê � ä � ä � � � ä � ç ê ñ é õ í æ ø ç è ë î ý æ ì ê ç é è ë æ î ë æ í �

ç ø å ê ñ ê ï é ç ê ì î õ í å ê ç ø î è ê î ó í ë é õ ç æ í æ î õ ç � , ê í & é õ ì & ; ï ê í ë é õ ç æ í æ î õ ç ø î õ : æ ø í æ õ ô ê é ø å î í å ê ë � J ó � � G � � & � æ ç é

ç í ë æ ø í é õ ø ê ç í î ë î ó � � G � � & ; � � í å ê õ & å é ç è ë æ î ë æ í � î ý ê ë & ; � J ó � � G � � & � æ ç ê 4 � æ ý é ð ê õ í í î � � G � � & ; � � & é õ ì & ; å é ý ê í å ê

ç é ñ ê è ë æ î ë æ í � � � î ë ê é ñ è ð ê � æ õ � æ ô � ë ê û & © å é ç è ë æ î ë æ í � î ý ê ë & 9 � & � � & � � & � � & � é õ ì & � þ å æ ð ê & � é õ ì & å é ý ê í å ê

ç é ñ ê è ë æ î ë æ í � � M æ í å í å æ ç è ë æ î ë æ í � ç ø å ê ñ ê � í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê ç ï ê ø î ñ ê ç ì ê í ê ë ñ æ õ æ ç í æ ø þ æ í å ë ê ç è ê ø í

í î � � � G � � $ � G E � � � ¢ E � � � � � G � � $ � G � � G � � � � ï ê ø é � ç ê õ î þ þ ê å é ý ê � � £ ¢ ° ! I � G E � � ) � � £ ¢ ° ! I � G � � é ç í å ê î õ ð � è î ç ç æ ï ð ê

î � í è � í ç ê 4 � ê õ ø ê �

� � � â ã � â � Ý ã ß Ü � � � � � à � � Ý ã Ü � � ã Ý � Ý � Ý � â � Þ Ý �

� � + � � , ê í & ( * X , X . X 0 X 1 � ï ê é ç í é í ê ø å é ë í � � õ é æ ý ê é è è ë î é ø å í î ø å é ë é ø í ê ë æ C æ õ ô í å ê ï ê å é ý æ î ë î ó é

ç í é í ê ø å é ë í æ ç í î � ç ê é ð ð í å ê � õ æ í ê è é í å ç î ó æ í ç � ë æ è > ê ç í ë � ø í � ë ê h & � � ä å æ ç é è è ë î é ø å � å î þ ê ý ê ë � æ ç î ó ð æ í í ð ê � ç ê

ï ê ø é � ç ê é è é í å ê õ ì æ õ ô é í é õ î õ ç í é ï ð ê ô ð î ï é ð ç í é í ê ñ é � õ î í è ë î ý æ ì ê í å ê æ õ ó î ë ñ é í æ î õ î ó í å ê î � í è � í ç ê 4 � ê õ ø ê

í å é í æ ç ç � è è î ç ê ì í î ï ê ô ê õ ê ë é í ê ì é ç í å ê ë ê ç è î õ ç ê í î é õ æ õ è � í ç ê 4 � ê õ ø ê � ä å ê ë ê ó î ë ê þ ê é ë ê ø î õ ø ê ë õ ê ì é ï î � í

î õ ð � � õ æ í ê è é í å ç ê õ ì æ õ ô é í é ç í é ï ð ê ô ð î ï é ð ç í é í ê � þ å æ ø å þ ê ø é ð ð $ ± E � � � æ ô � ë ê # ç å î þ ç é ë � õ î ó í å ê ø î � ê ê ý ê õ ì æ õ ô

ñ é ø å æ õ ê æ õ þ å æ ø å ì î � ï ð ê ë ê ø í é õ ô ð ê ç ë ê è ë ê ç ê õ í ç í é ï ð ê ô ð î ï é ð ç í é í ê ç � ä å ê ë � õ ø î ë ë ê ç è î õ ì ç í î í å ê ê ê ø � í æ î õ î ó

í å ê í ë é õ ç æ í æ î õ ç ê 4 � ê õ ø ê & § � & � � & 9 � & æ õ � æ ô � ë ê û �

� � O P � � F G G � Ò e f g Ò � R T V X Y [ T ] � Ò ! #

L} d X R

� � h P � � o p r n $ n > � �v

� Ò e f g Ò � _ ` a c d [ T ] � Ò � N O � #

L d ` x &

� � w P � � o p r n $ n > � �v

� Ò e f g Ò � ` ] x � Ò ! #

L} d X R

� � � P � � o p r n $ l F � n > � �v

� Ò e f � Ò ! Ò � N � � #

L d ` x &

� � � P � � o p r n $ l F � n > � �v

� Ò e f � Ò � x T j X X � Ò ! #

L} d X R

� � � P � �

s t u v$ n > � �

v� Ò e f � Ò � } d ~ Y d + � X x � Ò � N w � #

L} d X R

� � � P � �

s t u v$ n > � �

v� Ò e f g Ò ! Ò � N � � #

� æ ô � ë ê # � � ë � õ ó î ë í ê ç í ç ê 4 � ê õ ø ê � � G � � $ � G E � � � ¢ E � � � � � G � � � - � £ ¢ ° ! I � G E � � ) � � � I � $ I �

� ç � ï ç ê 4 � ê õ ø ê ³ w X � w X Q w X ' w � � � � � � ³ / X � / X Q / X ' / � î ó é ë � õ ³ j X � j X Q j X ' j � � � � � � ³ 2 X � 2 X Q 2 X ' 2 � æ ç é � ± � � $ � I � �æ ó ³ w 4 § X � w 4 § X Q w 4 § X ' w 4 § � æ ç ç í é ï ð ê � ³ 7 X � 7 X Q 7 X ' 7 � æ ç õ î í ç í é ï ð ê ó î ë { � 9 � � � é õ ì ³ / X � / X Q / X ' / � æ ç ç í é ï ð ê �

20

Page 31: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

M ê ë ê ó ê ë í î Q w é ç í å ê æ õ è � í î ó í å ê ç � è ê ë ç í ê è é õ ì , � 0 : w�

7 � / Q 7 é ç í å ê î � í è � í î ó í å ê ç � è ê ë ç í ê è � � î ë

ê é ñ è ð ê � í å ê ó î ð ð î þ æ õ ô ç å î þ ç í å ê í å ë ê ê ç � è ê ë ç í ê è ç æ õ � æ ô � ë ê # �

¯ ¹ ± ³ µ ¯ º ³ ± ® ½ ± ¹ º ¼ ¹ º ± ¹ º

� � O Ò � � h � R T V X Y [ T ] � � _ ` a c d [ T ] �� � w Ò � � � � ` ] x � !

� � � Ò � � � Ò � � � � x T j X X � � } d ~ Y d �

- � � � � � � � + � � � � M ê ë ê ó ê ë í î é � õ æ í ê þ î ë ì � { ( { § � � � { 2 î ý ê ë û � é ç ¢ E � ± I � � � ± � E � � é õ ì é � õ æ í ê þ î ë ì �� (

� § � � � � 2 î ý ê ë û � � é ç G ± I � ± I � � � ± � E � � � M ê ç é � í å é í é è é æ ë î ó æ õ è � í é õ ì î � í è � í ç ê 4 � ê õ ø ê ç � þ ë æ í í ê õ é ç � { - �� � æ ç é

I � � I � � � ± � E � � æ ó í å ê ë ê æ ç é ë � õ ç � ø å í å é í { / é õ ì � / é ë ê í å ê æ õ è � í é õ ì î � í è � í î ó í å ê � Q í å ç � è ê ë ç í ê è î ó í å ê ë � õ �

ë ê ç è ê ø í æ ý ê ð � � % î í ê í å é í ç æ õ ø ê þ ê ø î õ ç æ ì ê ë î õ ð � ì ê í ê ë ñ æ õ æ ç í æ ø ç í é í ê ø å é ë í ç � í å ê ë ê æ ç î õ ð � î õ ê î � í è � í ç ê 4 � ê õ ø ê

ø î ë ë ê ç è î õ ì æ õ ô í î ê é ø å æ õ è � í ç ê 4 � ê õ ø ê � J õ í � æ í æ ý ê ð � é í ê ç í ç ê 4 � ê õ ø ê � { - �� ì ê ç ø ë æ ï ê ç í å ê ê è ê ø í ê ì î ë ë ê 4 � æ ë ê ì

ë ê ç è î õ ç ê �� î ó æ ñ è ð ê ñ ê õ í é í æ î õ ç � õ ì ê ë í ê ç í í î í å ê æ õ è � í ç ê 4 � ê õ ø ê � { � M ê ç é � í å é í é I � � I � ± ¢ I � æ ç é ç ê í î ó í ê ç í

ç ê 4 � ê õ ø ê ç � � î ë ê é ñ è ð ê � þ ê å é ý ê í å ê í ê ç í ç ê 4 � ê õ ø ê � � G � � $ � G E � � � ¢ E � � � � � G � � � - � £ ¢ ° ! I � G E � � ) � � � I � $ I � ó ë î ñ í å ê

ë � õ æ õ � æ ô � ë ê # �

� � - + � � � � M ê ø î ñ è é ë ê í å ê õ é í � ë ê î ó í ê ç í ç ê 4 � ê õ ø ê ç ó î ë ë ê é ø í æ ý ê ç � ç í ê ñ ç þ æ í å í å î ç ê ó î ë í ë é õ ç ó î ë ñ é í æ î õ é ð

ç � ç í ê ñ ç � � î ç í î ó é õ é ð � ç æ ç é õ ì í ê ç í æ õ ô ñ î ì ê ð ç ó î ë í ë é õ ç ó î ë ñ é í æ î õ é ð ç � ç í ê ñ ç � ê � ô � � : î þ ô ë é è å ç ù ú . ü é õ ì è ë î ô ë é ñ

ì ê è ê õ ì ê õ ø � ô ë é è å ç ù ú � ü � ø î õ í é æ õ é ì æ ç í æ õ ô � æ ç å ê ì õ î ì ê ø é ð ð ê ì ê æ í õ î ì ê í î ñ î ì ê ð í å ê í ê ë ñ æ õ é í æ õ ô ï ê å é ý æ î ë î ó

ç � ø å ç � ç í ê ñ ç � ä ê ç í ç ê 4 � ê õ ø ê ç æ õ ç � ø å ô ë é è å ç é ë ê õ é í � ë é ð ð � ì ê � õ ê ì æ õ í ê ë ñ ç î ó è é í å ç þ å î ç ê � ë ç í õ î ì ê æ ç í å ê

ê õ í ë � õ î ì ê é õ ì ð é ç í õ î ì ê æ ç í å ê ê æ í õ î ì ê î ó í å ê ô ë é è å ç � % õ í å ê î í å ê ë å é õ ì � í å ê ë ê æ ç õ î ø î ë ë ê ç è î õ ì æ õ ô õ î í æ î õ

æ õ ë ê é ø í æ ý ê ç � ç í ê ñ ñ î ì ê ð ç � ï ê ø é � ç ê í å ê ï ê å é ý æ î ë î ó ë ê é ø í æ ý ê ç � ç í ê ñ ç æ ç ø å é ë é ø í ê ë æ C ê ì ï � í å ê æ ë õ î õ Q í ê ë ñ æ õ é í æ õ ô

ø î ñ è � í é í æ î õ ç �

M å ê õ ì ê � õ æ õ ô í ê ç í ç ê 4 � ê õ ø ê ç ó î ë ç í é í ê ø å é ë í ç � þ ê ì î õ î í è � í é õ � ø î õ ç í ë é æ õ í î õ æ õ è � í ç ê 4 � ê õ ø ê ç é õ ì í å � ç

é ð ð î þ í å ê ê ê ø � í æ î õ î ó í ê ç í ç ê 4 � ê õ ø ê ç ñ é � ê õ ì é í é õ � ç í é ï ð ê ô ð î ï é ð ç í é í ê � ä å é í æ ç � þ ê ë ê ô é ë ì ê é ø å ç í é ï ð ê

ô ð î ï é ð ç í é í ê é ç é è ç ê � ì î Q ê æ í õ î ì ê � ä å ê ë ê é ë ê � å î þ ê ý ê ë � ñ î ë ê ê ð é ï î ë é í ê é è è ë î é ø å ê ç í î ì ê � õ æ õ ô ê æ í õ î ì ê ç �

� þ æ ì ê ð � � ç ê ì é è è ë î é ø å æ õ � � � � Q ï é ç ê ì í ê ç í æ õ ô æ ç í î ë ê 4 � æ ë ê í å é í í å ê ê ê ø � í æ î õ î ó í ê ç í ç ê 4 � ê õ ø ê ç ê õ ì é í é õ

æ õ æ í æ é ð ç í é í ê ó ë î ñ þ å æ ø å é õ î í å ê ë í ê ç í ç ê 4 � ê õ ø ê ø é õ ï ê é è è ð æ ê ì � J õ ô ê õ ê ë é ð � í ê ç í ê ë ç ñ é � þ é õ í í î ì ê ç æ ô õ é í ê é õ

é ë ï æ í ë é ë � ç í é í ê é ç é õ ê æ í õ î ì ê � � õ æ õ í ê ë ê ç í æ õ ô õ î í æ î õ æ ç ñ é ë > ê ë ç í é í ê æ õ í å ê ç � è ê ë ý æ ç î ë � ø î õ í ë î ð í å ê î ë � ï �

# é ñ é ì ô ê é õ ì M î õ å é ñ ù û û ü � ä å æ ç í å ê î ë � ì æ ç í æ õ ô � æ ç å ê ç í å ê è é í å ç ê õ ì æ õ ô é í é ç í é í ê ì ê ç æ ô õ é í ê ì é ç é ñ é ë > ê ë

ó ë î ñ î í å ê ë ç é õ ì æ õ í ê ë è ë ê í ç ç � ø å è é í å ç é ç ø î ñ è ð ê í ê ì í é ç > ç î ó í å ê ñ î ì ê ð ê ì ç � ç í ê ñ � � î ë ê é ñ è ð ê � é í ê ç í ê ë ñ é �

þ é õ í í î ì ê ç æ ô õ é í ê í å ê ø î õ � ô � ë é í æ î õ � � � � � � � � � � � é ç é ñ é ë > ê ë ó î ë í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê é õ ì ë ê 4 � æ ë ê

í å é í í å ê ê ê ø � í æ î õ î ó ê ý ê ë � í ê ç í ç ê 4 � ê õ ø ê ê õ ì é í í å ê ñ é ë > ê ë � J õ í å æ ç ø é ç ê � í å ê æ õ è � í ç ê 4 � ê õ ø ê ç æ õ � æ ô � ë ê #

é õ ì ø é õ ï ê ê í ê õ ì ê ì þ æ í å � ¤ G E � � í î ô � é ë é õ í ê ê í å é í í å ê ñ é ø å æ õ ê ê õ ì é í í å ê ñ é ë > ê ë �

- � � - + ( � � - � � � � + � � � % ó í ê õ þ ê õ ê ê ì í î í ê ç í í å é í í å ê ç � ç í ê ñ ì î ê ç E G I è ë î ì � ø ê é õ � î � í è � í æ õ ë ê ç è î õ ç ê í î

ç î ñ ê æ õ è � í � � î ë ê é ñ è ð ê � í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê æ õ ø î õ � ô � ë é í æ î õ � � � � � � � � � � � þ å ê õ 8 ( � ì î ê ç õ î í

ë ê ç è î õ ì í î æ õ è � í � � G � � � ç æ ñ è ð � ï ê ø é � ç ê í å ê ë ê é ë ê õ î ê õ é ï ð ê ì í ë é õ ç æ í æ î õ ç æ õ í å ê ø î ë ë ê ç è î õ ì æ õ ô ô ð î ï é ð ç í é í ê �

! î þ ê ý ê ë � æ ó þ ê þ é õ í í î ô ê õ ê ë é í ê é í ê ç í ó î ë ç � ø å 4 � æ ê ç ø ê õ í ï ê å é ý æ î ë � ç æ õ ô í å ê ç é ñ ê í ê ø å õ æ 4 � ê é ç ó î ë î ï ç ê ë ý é ï ð ê

ï ê å é ý æ î ë ç � þ ê õ ê ê ì í î ñ é > ê í å ê é ï ç ê õ ø ê î ó î � í è � í ê è ð æ ø æ í � � î ë í å æ ç � þ ê ê í ê õ ì í å ê ç ê í î ó í ë é õ ç æ í æ î õ ç î ó í å ê

ç í é í ê ø å é ë í þ æ í å ¢ * � £ ¢ � ¢ I I $ � E � ¢ I ¢ G E � � J ñ è ð æ ø æ í í ë é õ ç æ í æ î õ ç é ë ê é ð þ é � ç ç ê ð ó Q ð î î è ç þ æ í å í å ê ê ñ è í � ç ê í î ó î � í è � í

ê ý ê õ í ç � ä å ê ó î ð ð î þ æ õ ô ç å î þ ç í å ê æ ñ è ð æ ø æ í í ë é õ ç æ í æ î õ ç ó î ë í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê �

{ & § ( { & � � � � � G � � $ � G � ( � � � � � G � � $ � G � I $ ± � � ) � � � � �

{ & © ( { & � � � � � G � � � ( � � � � � G � � � I $ ± � � ) � � � � �

{ & 9 ( { & � � � � ¤ G E � � ( � � � � ¤ G E � � I $ ± � � ) � � � � �

{ & � ( { & � � � � ¢ E � � ( � � � � ¢ E � � I $ ± � � ) � � � � �

{ & � ( { & � � � � ¤ � � � ( � � � � ¤ � � � I $ ± � � ) � � � � �

{ & � ( { & � � � � G � � $ � G E � ( � � � � G � � $ � G E � I $ ± � � ) � � � �

{ & ( { & � � � � � � G � � � ( � � � � � � G � � � M 8 � � � � ) � � � � � �

{ & ( { & � � � � � � G � � � ( � � � � � � G � � � I $ ± � � ) � � � � � �

{ & � ( { & � � � � � ¤ G E � � ( � � � � � ¤ G E � � I $ ± � � ) � � � � � �

21

Page 32: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

{ & § j ( { & � � � � � � � � ¢ E � � ( � � � � � � � � ¢ E � � M 8 � ú � � � ) � � � � � � � � �{ & § § ( { & � � � � � ¤ � � � ( � � � � � ¤ � � � I $ ± � � ) � � � � � �{ & § © ( { & � � � � � � � � ¤ � � � ( � � � � � � � � ¤ � � � M 8 � ú � 8 ( ú � � ) � � � � � � � � �

� õ æ õ è � í ç ê 4 � ê õ ø ê � { æ ç � 1 � £ ¢ � ¢ I æ ó í å ê ë ê ê æ ç í ç é í ê ç í ç ê 4 � ê õ ø ê � { - �� ç � ø å í å é í ê é ø å ç í ê è í ë é õ ç æ í æ î õ î ó æ í ç

ë � õ ø î ë ë ê ç è î õ ì ç í î í å ê ê ê ø � í æ î õ î ó é õ ê è ð æ ø æ í í ë é õ ç æ í æ î õ � % í å ê ë þ æ ç ê � æ í æ ç ¢ * � £ ¢ � ¢ I � � î ë ê é ñ è ð ê � í å ê æ õ è � í

ç ê 4 � ê õ ø ê � � � G � � $ � G E � � � ¢ E � � � � � G � � � � æ ç ê è ð æ ø æ í ç ê ê � æ ô � ë ê # � � þ å æ ð ê � � � G � � $ � G E � � � � G � � � � æ ç æ ñ è ð æ ø æ í

ï ê ø é � ç ê í å ê ç í ê è í ë é õ ç æ í æ î õ � ¡ 9 X � ¡ � � æ õ � æ ô � ë ê . ø î ë ë ê ç è î õ ì ç í î í å ê ê ê ø � í æ î õ î ó { & �

� � O P � � F G G � Ò e f g Ò � R T V X Y [ T ] � Ò ! #

L} d X R

� � h P � � o p r n $ n > � �v

� Ò e f g Ò � _ ` a c d [ T ] � Ò � N O � #

L d ` x &

� � w P � � o p r n $ n > � �v

� Ò e f � Ò � x T j X X � Ò ! #

L} d X R

� � � P � � o p r n $ n > � �v

� Ò e f g Ò ! Ò � � N � � #

� æ ô � ë ê . � � ë � õ ó î ë í ê ç í ç ê 4 � ê õ ø ê � � G � � $ � G E � � � � G � � � - � £ ¢ ° ! I � G E � � )

� � + 2 � � � � + � � � � æ õ é ð ð � þ ê è ë ê ç ê õ í é ø î õ ó î ë ñ é õ ø ê ë ê ð é í æ î õ ï ê í þ ê ê õ ç è ê ø æ � ø é í æ î õ ç þ ë æ í í ê õ æ õ ì ê í ê ë ñ æ õ ç æ í æ ø

ç í é í ê ø å é ë í ç é õ ì æ ñ è ð ê ñ ê õ í é í æ î õ ç � õ ì ê ë í ê ç í � � î ë é ç í é í ê ø å é ë í & é õ ì æ ñ è ð ê ñ ê õ í é í æ î õ % � þ ê þ ë æ í ê & � � { � é õ ì

% � � { � ó î ë í å ê î � í è � í ç ê 4 � ê õ ø ê ç î ó & é õ ì % í î é õ æ õ è � í ç ê 4 � ê õ ø ê � { � ë ê ç è ê ø í æ ý ê ð � � M ê ç é � í å é í % � � � f £ � � G E � G $ * �í î & æ ó & � � { � ( % � � { � � ó î ë é ð ð ê è ð æ ø æ í æ õ è � í ç ê 4 � ê õ ø ê ç � { � M ê ç é � í å é í % � I $ G E ° £ � � G E � G $ * � í î & æ ó & � � { � ( % � � { � �ó î ë é ð ð æ õ è � í ç ê 4 � ê õ ø ê ç � { �

� � Ý � ß � Þ � � � � Þ ã Ý � Þ ã � � ß Þ � Ý � Ý � â � Þ Ý �

� í é í ê ø å é ë í ç ç è ê ø æ ó � í å ê ë ê 4 � æ ë ê ì ï ê å é ý æ î ë î ó æ ñ è ð ê ñ ê õ í é í æ î õ ç � õ ì ê ë í ê ç í ï � ì ê ç ø ë æ ï æ õ ô í å ê è î ç ç æ ï ð ê ç ê 4 � ê õ ø ê ç

î ó æ õ è � í é õ ì î � í è � í ê ý ê õ í ç æ õ í ê ë ñ ç î ó ø î õ í ë î ð é õ ì ì é í é ì ê è ê õ ì ê õ ø æ ê ç ï ê í þ ê ê õ í å ê ê ý ê õ í ç � � è ê ø æ � ø é í æ î õ Q ï é ç ê ì

í ê ç í æ õ ô þ æ í å ç í é í ê ø å é ë í ç é æ ñ ç é í ì ê í ê ë ñ æ õ æ õ ô þ å ê í å ê ë é õ æ ñ è ð ê ñ ê õ í é í æ î õ ê ç í é ï ð æ ç å ê ç í å ê ì ê ç æ ë ê ì : î þ î ó ï î í å

ø î õ í ë î ð é õ ì ì é í é ê è ë ê ç ç ê ì æ õ æ í ç ç è ê ø æ � ø é í æ î õ �

� � � � @ B � � @ V � V @ � T � E F B � F C � @ � F � � D F � � E � F � E �

% ï ý æ î � ç ð � í å ê ç í ë î õ ô ê ç í í ê ç í ø î ý ê ë é ô ê ø ë æ í ê ë æ é æ ç � � I ! � G � � $ � ° � þ å æ ø å ë ê 4 � æ ë ê ç í å é í é ð ð í å ê ë � õ ç î ó é ç í é í ê ø å é ë í

ï ê í ë é ý ê ë ç ê ì � î ë ê 4 � æ ý é ð ê õ í ð � é ð ð í å ê æ õ è � í ç ê 4 � ê õ ø ê ç î ó í å ê ç í é í ê ø å é ë í ï ê é è è ð æ ê ì í î æ ñ è ð ê ñ ê õ í é í æ î õ ç � õ ì ê ë

í ê ç í � � ê ø é � ç ê í å ê ë ê æ ç é õ æ õ � õ æ í ê õ � ñ ï ê ë î ó æ õ è � í ç ê 4 � ê õ ø ê ç � þ ê õ ê ê ì í î å é ý ê ç � ç í ê ñ é í æ ø ø î ý ê ë é ô ê ø ë æ í ê ë æ é

í å é í ç ê ð ê ø í é � õ æ í ê é õ ì ë ê é ç î õ é ï ð ê õ � ñ ï ê ë î ó í ê ç í ç ê 4 � ê õ ø ê ç ç é í æ ç ó � æ õ ô ø ê ë í é æ õ ø î õ ì æ í æ î õ ç � ä å æ ç è é è ê ë è ë ê ç ê õ í ç

é ó é ñ æ ð � î ó í ê ç í ø î ý ê ë é ô ê ø ë æ í ê ë æ é ï é ç ê ì î õ í å ê : î þ æ õ ó î ë ñ é í æ î õ î ó ï î í å ø î õ í ë î ð é õ ì ì é í é æ õ ç í é í ê ø å é ë í ç �

M ê ç é � í å é í é í ê ç í ç ê 4 � ê õ ø ê � { - �� ø î ý ê ë ç é ç í é í ê ¡ ë ê ç è � ø î õ � ô � ë é í æ î õ ³ é õ ì í ë é õ ç æ í æ î õ & � æ ó æ í ç ë � õ ø î õ í é æ õ ç

ô ð î ï é ð ç í é í ê ³ w X � w X Q w X ' w � ç � ø å í å é í ¡ « ³ w ë ê ç è � ³ ( ³ w é õ ì & « ' � �

� � � � � � � � � ( � � � í ê ç í ç � æ í ê H ç é í æ ç � ê ç � I � I � � G � � $ � ° � æ ó ê é ø å ç í é í ê æ ç ø î ý ê ë ê ì ï � é í ê ç í ç ê 4 � ê õ ø ê æ õ H �

22

Page 33: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� � + 3 ( � � � - � + � � � � � � ( � � � ç í ë î õ ô ê ë ø ë æ í ê ë æ î õ í å é õ ç í é í ê ø î ý ê ë é ô ê ñ é � ï ê ì ê � õ ê ì þ å æ ø å ë ê 4 � æ ë ê ç í å ê

í ë é ý ê ë ç é ð î ó ê é ø å ø î õ � ô � ë é í æ î õ � � í ê ç í ç � æ í ê H ç é í æ ç � ê ç � G E ¯ ° ± $ � I ¢ G E � G � � $ � ° � æ ó ê é ø å ø î õ � ô � ë é í æ î õ æ ç ø î ý ê ë ê ì

ï � é í ê ç í ç ê 4 � ê õ ø ê æ õ H �

- � � + � - - � + � � � � � � ( � � � í ê ç í ç � æ í ê H ç é í æ ç � ê ç � � � f I $ � E � ¢ I ¢ G E � G � � $ � ° � æ ó ê é ø å ê è ð æ ø æ í í ë é õ ç æ í æ î õ æ ç ø î ý ê ë ê ì

ï � é í ê ç í ç ê 4 � ê õ ø ê æ õ H � � í ê ç í ç � æ í ê H ç é í æ ç � ê ç � I $ G E ° I $ � E � ¢ I ¢ G E � G � � $ � ° � æ ó ê é ø å ê è ð æ ø æ í é õ ì æ ñ è ð æ ø æ í

í ë é õ ç æ í æ î õ æ ç ø î ý ê ë ê ì ï � é í ê ç í ç ê 4 � ê õ ø ê æ õ H �

� � � � � � � V @ � T � E F B � F C � @ � F � � D F � � E � F � E �

M ê é ì î è í í å ê ó î ð ð î þ æ õ ô ø î õ ý ê õ í æ î õ þ å æ ø å ø ð é ç ç æ � ê ç ê é ø å ý é ë æ é ï ð ê î ø ø � ë ë ê õ ø ê î ó é í ë é õ ç æ í æ î õ é ç ï ê æ õ ô é ì ê � Q

õ æ í æ î õ � ø î ñ è � í é í æ î õ � ç ê ø Q � ç ê � � é õ ì è ë ê ì æ ø é í ê � ç ê è Q � ç ê � � , ê í � ï ê é ý é ë æ é ï ð ê é õ ì & ï ê é í ë é õ ç æ í æ î õ � � æ ç

¤ � ¯ E � ¤ é í & æ ó � � � ¢ ° E * � E I � & � æ õ ø ð � ì ê ç é õ é ç ç æ ô õ ñ ê õ í í å é í ì ê � õ ê ç � ¶ � æ ç � � ± � � ¤ é í & æ ó � � � ¢ ° E * � E I � & � æ õ ø ð � ì ê ç

é õ é ç ç æ ô õ ñ ê õ í í å é í ë ê ó ê ë ê õ ø ê ç � ¶ � æ ç � � ± � � ¤ é í & æ ó ° ± � $ ¤ & � ë ê ó ê ë ê õ ø ê ç � � M ê ì ê õ î í ê ï � ¤ � � � � � � � ± � � � � � é õ ì

� � ± � � � � í å ê ç ê í ç î ó í ë é õ ç æ í æ î õ ç í å é í ì ê � õ ê � ø Q � ç ê � é õ ì è Q � ç ê � � ë ê ç è ê ø í æ ý ê ð � � J õ í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê �

þ ê å é ý ê ¤ � � 8 � ( � & § X & � X & � X & X & � � � � ± � � 8 � ( � & � X & � � � � ± � � 8 � ( � & 9 X & � X & X & � �

, ê í & é õ ì & ; ï ê í ë é õ ç æ í æ î õ ç é õ ì � ¡ j � � � � � � ¡ 2 ï ê é ë � õ � � � è è î ç ê í å é í í å ê ç í ê è í ë é õ ç æ í æ î õ ç � ¡ w � � ¡ w y § � é õ ì

� ¡ / � � ¡ / y § � ç � ø å í å é í � � { � � � + ø î ë ë ê ç è î õ ì í î í å ê ê ê ø � í æ î õ î ó & é õ ì & ; � ë ê ç è ê ø í æ ý ê ð � � ä å ê ë � õ æ ç é

¤ � ¯ E ¢ I ¢ G E � � £ � � $ $ ± E þ æ í å ë ê ç è ê ø í í î � ó ë î ñ & í î & ; æ ó ê é ø å ç í ê è í ë é õ ç æ í æ î õ � ¡ 7 � � ¡ 7 y § � ì î ê ç õ î í ø î ë ë ê ç è î õ ì í î

í å ê ê ê ø � í æ î õ î ó é õ � í ë é õ ç æ í æ î õ é í þ å æ ø å � æ ç ì ê � õ ê ì � ó î ë { � 9 � � �

M ê ì ê � õ ê é ç ç î ø æ é í æ î õ ç ï ê í þ ê ê õ ì ê � õ æ í æ î õ ç é õ ì � ç ê ç î ó é ý é ë æ é ï ð ê é ç ó î ð ð î þ ç � é í � è ð ê � X & X & ; � æ ç é ¤ � � � � � ± � �

� � � G � ¢ � I ¢ G E ë ê ç è � ¤ � � � � � ± � � � � � G � ¢ � I ¢ G E � æ ó & « ¤ � � � � � & ; « � � ± � � � � ë ê ç è � & ; « � � ± � � � � � � é õ ì í å ê ë ê ê æ ç í ç é

ì ê � õ æ í æ î õ Q ø ð ê é ë ë � õ þ æ í å ë ê ç è ê ø í í î � ó ë î ñ & í î & ; � � ¤ � � � ± � � � � � G � ¢ � I ¢ G E æ ç ê æ í å ê ë é ì ê ó Q ø Q � ç ê é ç ç î ø æ é í æ î õ î ë

ì ê ó Q è Q � ç ê é ç ç î ø æ é í æ î õ � ä é ï ð ê ú ç å î þ ç í å ê ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ ç ó î ë í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê � � î ë ê é ñ è ð ê �

ø î õ ç æ ì ê ë í å ê ì ê ó Q è Q � ç ê é ç ç î ø æ é í æ î õ 8 X & � X & 9 � � ä å ê ì ê � õ æ í æ î õ î ó 8 é í & � ø é õ ë ê é ø å í å ê � ç ê î ó 8 é í & 9 í å ë î � ô å

í å ê ì ê � õ æ í æ î õ Q ø ð ê é ë ë � õ ç å î þ õ æ õ � æ ô � ë ê # � J õ ô ê õ ê ë é ð � í å ê ë ê é ë ê í å ë ê ê í � è ê ç î ó é ç ç î ø æ é í æ î õ ç ï ê í þ ê ê õ ì ê � õ æ í æ î õ ç

é õ ì � ç ê ç æ õ ç í é í ê ø å é ë í ç � ä å ê � ë ç í í � è ê æ õ ø ð � ì ê ç é ç ç î ø æ é í æ î õ ç þ å æ ø å î ø ø � ë þ æ í å æ õ é õ % # Q ç í é í ê � ê � ô � � 8 � & � � & � � �

� ç ç î ø æ é í æ î õ ç î ø ø � ë ë æ õ ô æ õ î ë ì æ õ é ë � � � � � ç ï ê ð î õ ô í î í å æ ç í � è ê � ä å ê ç ê ø î õ ì í � è ê æ ç ø é � ç ê ì ï � í å ê å æ ê ë é ë ø å æ ø é ð

ç í ë � ø í � ë ê î õ ç í é í ê ç � ê � ô � � 8 � & § � { & � � ä å ê í å æ ë ì í � è ê æ ç ø é � ç ê ì ï � í å ê ø î õ ø � ë ë ê õ í ç í ë � ø í � ë ê î õ ç í é í ê ç � ê � ô � �

8 � & � � & 9 � �

ä é ï ð ê ú � ä å ê ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ ç ó î ë í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê

¶ ³ ¾ Ø · Ø ¹ ¯ ³ ² ¯ ¯ ¼ · ® ² º ® ¼ ½ ¯ ¶ ³ ¾ Ø ± Ø ¹ ¯ ³ ² ¯ ¯ ¼ · ® ² º ® ¼ ½ ¯

� e Ò N � Ò N � # � e Ò N � Ò N w # Ò � e Ò N � Ò N � # Ò � e Ò N � Ò N � #

� e Ò N � Ò N � # Ò � e Ò N � Ò N � # � e Ò N � Ò N w # Ò � e Ò N � Ò N � # Ò � e Ò N � Ò N � #

� e Ò N � Ò N � # Ò � e Ò N � Ò N � # � e Ò N � Ò N w # Ò � e Ò N � Ò N � # Ò � e Ò N � Ò N � # Ò � e Ò N � Ò N � #

M ê é ð ç î é ø ø î � õ í ó î ë í å ê ì é í é : î þ ø é � ç ê ì ï � æ ñ è ð æ ø æ í í ë é õ ç æ í æ î õ ç � � ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ ó î ë é ý é ë æ é ï ð ê �

æ ç ø é ð ð ê ì ¢ * � £ ¢ � ¢ I æ ó � æ ç ë ê ó ê ë ê õ ø ê ì ï � í å ê ô � é ë ì î ó é õ æ ñ è ð æ ø æ í í ë é õ ç æ í æ î õ � % î í ê í å é í î õ ð � è Q � ç ê ç é ë ê è î ç ç æ ï ð ê

ó î ë æ ñ è ð æ ø æ í í ë é õ ç æ í æ î õ ç � J õ í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê � þ ê å é ý ê í å ê ó î ð ð î þ æ õ ô æ ñ è ð æ ø æ í ì ê ó Q è Q � ç ê é ç ç î ø æ é í æ î õ ç �

8 X & § X { & � � 8 X & � X { & § j � � 8 X & X { & � �

M ê ç é � í å é í é í ê ç í ç ê 4 � ê õ ø ê � { - �� ø î ý ê ë ç é ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ � X & X & ; � æ ó æ í ç ë � õ æ ç é ì ê � õ æ í æ î õ Q ø ð ê é ë ë � õ

þ æ í å ë ê ç è ê ø í í î � ó ë î ñ & é õ ì & ; �

� � � � � 2 � � � � � � ( � � � í ê ç í ç � æ í ê H ç é í æ ç � ê ç � � � f � £ £ � ¤ � � � G � � $ � ° � æ ó ó î ë ê é ø å ý é ë æ é ï ð ê � é õ ì ê é ø å í ë é õ ç æ í æ î õ

& ç � ø å í å é í & « ¤ � � � � � ç î ñ ê ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ � X & X & ; � æ ç ø î ý ê ë ê ì ï � é í ê ç í ç ê 4 � ê õ ø ê æ õ H � � í ê ç í ç � æ í ê H

ç é í æ ç � ê ç � I $ G E ° � £ £ � ¤ � � � G � � $ � ° � æ ó ó î ë ê é ø å ý é ë æ é ï ð ê � é õ ì ê é ø å í ë é õ ç æ í æ î õ & ç � ø å í å é í & « ¤ � � � � � ç î ñ ê ê è ð æ ø æ í

ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ � X & X & ; � î ë æ ñ è ð æ ø æ í ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ � X & X { & � æ ç ø î ý ê ë ê ì ï � é í ê ç í ç ê 4 � ê õ ø ê æ õ H �

� � � � � � � � � � � � � ( � � � í ê ç í ç � æ í ê H ç é í æ ç � ê ç � � � f � £ £ � ± � � � G � � $ � ° � æ ó ó î ë ê é ø å ý é ë æ é ï ð ê � é õ ì ê é ø å í ë é õ ç æ í æ î õ

& ç � ø å í å é í & « ¤ � � � � � ê é ø å ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ � X & X & ; � æ ç ø î ý ê ë ê ì ï � é í ê ç í ç ê 4 � ê õ ø ê æ õ H � � í ê ç í ç � æ í ê H

23

Page 34: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

ç é í æ ç � ê ç � I $ G E ° � £ £ � ± � � � G � � $ � ° � æ ó ó î ë ê é ø å ý é ë æ é ï ð ê � é õ ì ê é ø å í ë é õ ç æ í æ î õ & ç � ø å í å é í & « ¤ � � � � � ê é ø å ê è ð æ ø æ í

ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ � X & X & ; � é õ ì æ ñ è ð æ ø æ í ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ � X & X { & � æ ç ø î ý ê ë ê ì ï � é í ê ç í ç ê 4 � ê õ ø ê æ õ H �

� � � � Ý � � Ü � Þ � Ý ã ß Ü � � Ý ß à � ß Þ � Ý � Ý � â � Þ Ý �

ä å æ ç ç ê ø í æ î õ ç å î þ ç í å é í í ê ç í ô ê õ ê ë é í æ î õ ó ë î ñ ç í é í ê ø å é ë í ç ø é õ ï ê é � í î ñ é í æ ø é ð ð � è ê ë ó î ë ñ ê ì ï � � ç æ õ ô í å ê � � @ � ç

é ï æ ð æ í � í î ø î õ ç í ë � ø í ø î � õ í ê ë ê é ñ è ð ê ç � � ë æ ê : � í å ê ô ê õ ê ë é í æ î õ î ó é í ê ç í ç � æ í ê ó ë î ñ é ç í é í ê ø å é ë í é õ ì é í ê ç í

ø î ý ê ë é ô ê ø ë æ í ê ë æ î õ ø î õ ç æ ç í ç î ó í å ê ó î ð ð î þ æ õ ô ç í ê è ç �

~ � õ � � @ è ë î ô ë é ñ æ ç ø î õ ç í ë � ø í ê ì ó ë î ñ í å ê ç í é í ê ø å é ë í �

~ � ç ê í î ó < ä , ó î ë ñ � ð é ç æ ç ø î õ ç í ë � ø í ê ì ó ë î ñ í å ê ø ë æ í ê ë æ î õ �

~ � í ê ç í ç � æ í ê æ ç ø î õ ç í ë � ø í ê ì ï � ñ î ì ê ð Q ø å ê ø > æ õ ô í å ê < ä , ó î ë ñ � ð é ç é ô é æ õ ç í í å ê � � @ è ë î ô ë é ñ é õ ì è ë î Q

K ê ø í æ õ ô í å ê î ï í é æ õ ê ì ø î � õ í ê ë ê é ñ è ð ê ç î õ í î í å ê î ï ç ê ë ý é ï ð ê ê ý ê õ í ç �

� � � E � � � F � � � � � N � N E A � � � @ D � � N

� ê ø é � ç ê þ ê � ç ê í å ê ç � ñ ï î ð æ ø ñ î ì ê ð ø å ê ø > ê ë � � @ � þ ê ì î õ î í ê õ � ñ ê ë é í ê � ë æ è > ê ç í ë � ø í � ë ê ç ê è ð æ ø æ í ð � ï � í

ê õ ø î ì ê í å ê ñ ç � ñ ï î ð æ ø é ð ð � � ç æ õ ô é ç ê í î ó ý é ë æ é ï ð ê ç é õ ì è ë ê ì æ ø é í ê ç � ä å é í æ ç � þ ê í ë é õ ç ð é í ê é ç í é í ê ø å é ë í æ õ í î é

� � @ è ë î ô ë é ñ � þ å æ ø å æ ç é ç � ñ ï î ð æ ø ë ê è ë ê ç ê õ í é í æ î õ î ó � ë æ è > ê ç í ë � ø í � ë ê � ï � ê õ ø î ì æ õ ô í å ê ç ê ñ é õ í æ ø ç ô æ ý ê õ æ õ

� ê ø í æ î õ # æ õ í ê ë ñ ç î ó ý é ë æ é ï ð ê ç é õ ì è ë ê ì æ ø é í ê ç � � ì ê í é æ ð ê ì ì ê ç ø ë æ è í æ î õ î ó í å ê í ë é õ ç ð é í æ î õ æ ç ç í ë é æ ô å í ó î ë þ é ë ì

ï � í í ê ì æ î � ç é õ ì æ ç î ñ æ í ê ì å ê ë ê ì � ê í î í å ê ç è é ø ê ð æ ñ æ í � � � ð ð ì ê í é æ ð ç � é ð î õ ô þ æ í å é ø î ë ë ê ø í õ ê ç ç è ë î î ó � ø é õ ï ê

ó î � õ ì æ õ ù ú $ ü �

� � ë æ õ ô í å ê í ë é õ ç ð é í æ î õ � þ ê æ õ í ë î ì � ø ê ç ê ý ê ë é ð è ë ê ì æ ø é í ê ç í å é í é ë ê � ç ê ì æ õ í å ê < ä , ó î ë ñ � ð é ç ê è ë ê ç ç æ õ ô í å ê

ø î ý ê ë é ô ê ø ë æ í ê ë æ é � � î ë ê é ø å ç í é í ê ¡ î ó é ç í é í ê ø å é ë í � þ ê ì ê � õ ê è ë ê ì æ ø é í ê { + ¡ � þ å æ ø å æ ç í ë � ê æ õ é ô ð î ï é ð ç í é í ê æ ó

æ í ø î ë ë ê ç è î õ ì ç í î é ø î õ � ô � ë é í æ î õ í å é í ø î õ í é æ õ ç ¡ � � è ë ê ì æ ø é í ê � I � � £ � æ ç í ë � ê æ õ ç í é ï ð ê ô ð î ï é ð ç í é í ê ç � � æ õ é ð ð �

í å ê ó î ð ð î þ æ õ ô è ë ê ì æ ø é í ê ç é ë ê � ç ê ì í î ê õ ø î ì ê í å ê æ õ ó î ë ñ é í æ î õ î õ ì ê � õ æ í æ î õ ç é õ ì � ç ê ç î ó é ý é ë æ é ï ð ê � �

¤ � � � � ( � < > � � � � � � &

± � � � � ( � < > � � ± � � � � �" � � ± � � � � � &

¢ * � ± � � � � ( � w < > ¢ * � £ ¢ � ¢ I � � � ± � � � � � { &

� î ë ê é ñ è ð ê � þ ê å é ý ê ¤ 8 � � � ( & § � & � � & � � & � & � ± 8 � � � ( & 9 � & � � & � & � é õ ì ¢ * � ± 8 � � � ( { & � { & § j � { & § ©

ó î ë í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê �

� � � @ � F � � D F � � E � F � E � � N � ? Q � @ � A V � N

� é ø å ø î ý ê ë é ô ê ø ë æ í ê ë æ î õ æ ç ë ê è ë ê ç ê õ í ê ì é ç é ç ê í î ó < ä , í ê ñ è ð é í ê ç � � î ë é ô æ ý ê õ ç í é í ê ø å é ë í � í å ê ç ê í î ó í ê ñ è ð é í ê ç

æ ç æ õ ç í é õ í æ é í ê ì æ õ í î é ç ê í î ó < ä , ó î ë ñ � ð é ç þ æ í å í å ê è ë ê ì æ ø é í ê ç ì ê � õ ê ì ó î ë í å ê ç í é í ê ø å é ë í � ä å ê ë ê ç � ð í æ õ ô ç ê í

î ó < ä , ó î ë ñ � ð é ç ø é è í � ë ê ç ê é ø í ð � í å ê ø î ý ê ë é ô ê ø ë æ í ê ë æ î õ ó î ë í å ê ô æ ý ê õ ç í é í ê ø å é ë í �

� � F � 7 � - � � � � � � � � � 2 � � � � + � � � � � � � � � � � � � ( � � � - � � - �

M ê ï ê ô æ õ þ æ í å í å ê ç í é í ê ø î ý ê ë é ô ê ø ë æ í ê ë æ é þ å æ ø å ë ê 4 � æ ë ê ç í å é í ó î ë ê é ø å ç í é í ê ¡ î ó é ç í é í ê ø å é ë í � í å ê ë ê ê æ ç í ç

é í ð ê é ç í î õ ê ë � õ ø î ý ê ë æ õ ô ¡ � ä å ê � ë æ è > ê ç í ë � ø í � ë ê ø î ë ë ê ç è î õ ì æ õ ô í î é ç í é í ê ø å é ë í å é ç é ë � õ ø î ý ê ë æ õ ô ¡ æ ó é õ ì

î õ ð � æ ó æ � í å ê ë ê ê æ ç í ç ô ð î ï é ð ç í é í ê � ¡ w þ å æ ø å æ ç ë ê é ø å é ï ð ê ó ë î ñ é õ æ õ æ í æ é ð ô ð î ï é ð ç í é í ê � ¡ j é õ ì é í þ å æ ø å { + ¡ �

æ ç ç é í æ ç � ê ì é õ ì æ æ � í å ê ë ê ê æ ç í ç é ô ð î ï é ð ç í é í ê � ¡ / þ å æ ø å æ ç ë ê é ø å é ï ð ê ó ë î ñ � ¡ w é õ ì é í þ å æ ø å � I � � £ � æ ç ç é í æ ç � ê ì

ç ê ê � æ ô � ë ê � � � M ê ê è ë ê ç ç í å ê ë ê 4 � æ ë ê ñ ê õ í é ç í å ê < ä , ó î ë ñ � ð é Q Y { + ¡ � O Q Y � I � � £ � � �

% î þ þ ê í é > ê í å ê õ ê ô é í æ î õ î ó í å ê é ï î ý ê ó î ë ñ � ð é é õ ì ë � õ � � @ é ô é æ õ ç í í å ê õ ê ô é í ê ì ó î ë ñ � ð é M Q Y { + ¡ � O

Q Y � I � � £ � � ï ê ø é � ç ê þ ê é ë ê æ õ í ê ë ê ç í ê ì æ õ ô ê õ ê ë é í æ õ ô ë � õ ç ø î ý ê ë æ õ ô ¡ æ õ ç í ê é ì î ó ø å ê ø > æ õ ô í å ê ç é í æ ç � é ï æ ð æ í � î ó

í å ê î ë æ ô æ õ é ð ó î ë ñ � ð é � J ó í å ê ë ê ê æ ç í ç é ë � õ ø î ý ê ë æ õ ô ¡ � � � @ ô ê õ ê ë é í ê ç é ø î � õ í ê ë ê é ñ è ð ê þ å æ ø å ø î ë ë ê ç è î õ ì ç í î

é ë � õ ø î ý ê ë æ õ ô ¡ � % í å ê ë þ æ ç ê � � � @ è ë î ý æ ì ê ç í å ê ë ê ç � ð í î ó I $ ± � � ä å ê ë ê é ë ê í þ î ø é ç ê ç æ õ þ å æ ø å � � @ è ë î ý æ ì ê ç

24

Page 35: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

@? A B� � �

E� � �

E @ ? A B� � �

� � � � # E� � �

E @ ? A B� �

X � ` d

� æ ô � ë ê � � � í ê ç í ç ê 4 � ê õ ø ê ø î ý ê ë æ õ ô ç í é í ê v

I $ ± � é ô é æ õ ç í í å ê õ ê ô é í ê ì ó î ë ñ � ð é � � æ ë ç í � í å ê ô ð î ï é ð ç í é í ê � ¡ w æ ç õ î í ë ê é ø å é ï ð ê ó ë î ñ é õ � æ õ æ í æ é ð ô ð î ï é ð ç í é í ê �

æ � ê � � Q Y { + ¡ � æ ç õ î í ç é í æ ç � ê ì � � ê ø î õ ì � é ç í é í ê ø å é ë í ø é õ õ î í ë ê é ø å é ô ð î ï é ð ç í é í ê é í þ å æ ø å � I � � £ � æ ç ç é í æ ç � ê ì �

æ � ê � � Q Y � I � � £ � æ ç õ î í ç é í æ ç � ê ì � � î ë ê é ñ è ð ê � ø î õ ç æ ì ê ë M Q Y { + � � O Q Y � I � � £ � � þ å î ç ê è � ë è î ç ê æ ç í î ø î ý ê ë í å ê

ç í é í ê � æ õ � æ ô � ë ê $ � � ð í å î � ô å � æ ç ë ê é ø å é ï ð ê ó ë î ñ é õ æ õ æ í æ é ð ô ð î ï é ð ç í é í ê � í å ê ë ê æ ç õ î ë � õ ø î ý ê ë æ õ ô � ï ê ø é � ç ê

í å ê ë ê æ ç é õ æ õ � õ æ í ê ç ê 4 � ê õ ø ê ø î õ ç æ ç í æ õ ô î ó î õ ð � ç í ê è í ë é õ ç æ í æ î õ ç

� � � X 8 ( ú X � � � X ) � X � � � X 8 ( ú X � � � X � & § � � X � � � X 8 ( ú X � � � X � & © � � � � � �

é õ ì å ê õ ø ê í å ê ç í é í ê ø å é ë í ø é õ õ î í ë ê é ø å é ç í é ï ð ê ô ð î ï é ð ç í é í ê �

CL

�DI JK

EN O P � ^ � � e P f �� N h P � y e f � | ^ � sDI J

K

� æ ô � ë ê $ � � õ î õ Q í ê ë ñ æ õ é í æ õ ô ç í é í ê ø å é ë í

� ç ñ ê õ í æ î õ ê ì ï ê ó î ë ê � æ í ñ é � ï ê ë ê 4 � æ ë ê ì í å é í ê é ø å ë � õ ê õ ì é í é õ æ õ æ í æ é ð ç í é í ê î ë é õ é ë ï æ í ë é ë � ç í é í ê

ñ é ë > ê ì ï � í ê ç í ê ë ç � , ê í � 1 ¢ I ï ê é è ë ê ì æ ø é í ê ì ê � õ ê ì é ç � I � � £ � æ ó í å ê ë ê æ ç õ î ñ é ë > ê ë � é õ ì � I � � £ � O { + ³ � æ ó³ æ ç é ø î õ � ô � ë é í æ î õ ì ê ç æ ô õ é í ê ì é ç é ñ é ë > ê ë � M ê ø é õ ç æ ñ è ð � ê è ë ê ç ç í å ê ë ê 4 � æ ë ê ñ ê õ í î ó ñ é ë > ê ë ç � ç æ õ ô

Q Y { + ¡ � O Q Y � 1 ¢ I � �

, ê í � * ´ * ï ê í å ê ç ê í î ó ï é ç æ ø ç í é í ê ç � M ê õ î í ê í å é í é í ê ç í ç � æ í ê ø î ý ê ë æ õ ô é ð ð ï é ç æ ø ç í é í ê ç é ð ç î ø î ý ê ë ç

é ð ð î í å ê ë ç í é í ê ç ï ê ø é � ç ê î ó í å ê å æ ê ë é ë ø å � � ä î ô ê õ ê ë é í ê í ê ç í ç ê 4 � ê õ ø ê ç ç é í æ ç ó � æ õ ô ç í é í ê ø î ý ê ë é ô ê � þ ê � ç ê í å ê

ó î ð ð î þ æ õ ô ç ê í î ó < ä , ó î ë ñ � ð é ç �

� � � � � � � � � ( � � � M Q Y { + ¡ � O Q Y � 1 ¢ I � L ¡ « � * �

M ê ø é õ ì ê � õ ê í å ê < ä , ó î ë ñ � ð é ç ó î ë î í å ê ë ø î õ í ë î ð Q : î þ î ë æ ê õ í ê ì ø ë æ í ê ë æ é æ õ é ç æ ñ æ ð é ë þ é � �

� � + 3 ( � � � - � + � � � � � � ( � � � M Q Y { + � � O Q Y � 1 ¢ I � L � « � G E ¯ ° �

� � � � � � + � - - � + � � � � � � ( � � � M Q Y & O Q Y � 1 ¢ I � L & « 1 �

� � � + ( � � + � - - � + � � � � � � ( � � � M Q Y & O Q Y � 1 ¢ I � L & « 1 � , � M Q Y { & O Q Y � 1 ¢ I � L { & « % 1 �

� � F � F � - � � � � � � � � � 2 � � 2 � � � � � � � � � � � � ( � � � - � � - � �

ä å ê ë ê 4 � æ ë ê ñ ê õ í ó î ë é ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ � X & X & ; � ø é õ ï ê ç í é í ê ì é ç ó î ð ð î þ ç � æ � í å ê ë ê ê æ ç í ç é ô ð î ï é ð ç í é í ê � ¡ w

þ å æ ø å æ ç ë ê é ø å é ï ð ê ó ë î ñ é õ æ õ æ í æ é ð ô ð î ï é ð ç í é í ê � ¡ j é õ ì é í þ å æ ø å & æ ç ç é í æ ç � ê ì ¶ æ æ � í å ê ë ê ê æ ç í ç é è é í å � ¡ w y §� � � � ¡ / 4 § þ å æ ø å ç í é ë í ç ó ë î ñ é ç � ø ø ê ç ç î ë î ó � ¡ w é õ ì ø î õ í é æ õ ç õ î ì ê � õ æ í æ î õ î ó � � õ í æ ð � ¡ / é í þ å æ ø å & ; æ ç ç é í æ ç � ê ì ¶ æ æ æ � í å ê ë ê ê æ ç í ç é ô ð î ï é ð ç í é í ê � ¡ 7 þ å æ ø å æ ç ë ê é ø å é ï ð ê ó ë î ñ í å ê ô ð î ï é ð ç í é í ê � ¡ / é õ ì é í þ å æ ø å � 1 ¢ I æ ç ç é í æ ç � ê ì

ç ê ê � æ ô � ë ê � � � M ê ê è ë ê ç ç í å æ ç ë ê 4 � æ ë ê ñ ê õ í é ç Q Y & O Q R Q ù M ¤ � � T & ; O Q Y � 1 ¢ I � ü � �

M ê ì ê í ê ë ñ æ õ ê þ å ê í å ê ë ê é ø å í � è ð ê � X & X & ; � ç � ø å í å é í & « ¤ � � � � é õ ì & ; « ± � � � � æ ç é ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ

î ë õ î í ï � é ç ç î ø æ é í æ õ ô í å ê õ ê ô é í æ î õ î ó í å ê é ï î ý ê ó î ë ñ � ð é M Q Y & O Q R Q ù M ¤ � � T & ; O Q Y � 1 ¢ I � ü � þ æ í å í å ê

25

Page 36: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

@?

AB� � �

E� � �

E @?

AB

N� � �

E @?

AB� � � � O

� � � � #

E� � �

E @?

AB� � � O

� � � � #

E @?

AB� �

N �E

� � �

E @?

AB� �

X � ` d

� æ ô � ë ê � � � í ê ç í ç ê 4 � ê õ ø ê ø î ý ê ë æ õ ô ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ � X & X & ; �

í � è ð ê � J ó � � @ ô ê õ ê ë é í ê ç í å ê ë ê ç � ð í î ó I $ ± � é ô é æ õ ç í í å ê õ ê ô é í ê ì ó î ë ñ � ð é � í å ê í � è ð ê æ ç õ î í é ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ �

% í å ê ë þ æ ç ê � í å ê ø î � õ í ê ë ê é ñ è ð ê ô ê õ ê ë é í ê ì ï � � � @ ø î ë ë ê ç è î õ ì ç í î é ë � õ ø î ý ê ë æ õ ô í å ê ì ê ó Q � ç ê é ç ç î ø æ é í æ î õ

� X & X & ; � �

� � � � � � � � � 2 � � � � � � ( � � � M Q Y & O Q R Q ù M ¤ � � T ± � � O Q Y � 1 ¢ I � ü � L � « . X & « ¤ � � � � �

� � � + ( � � � � � 2 � � � � � � ( � �

� M Q Y & O Q R Q ù M ¤ � � T ± � � � ¢ * � ± � � � O Q Y � 1 ¢ I � ü � L � « . X & « ¤ � � � � �

� � � � � � � � � � � � � � � � � ( � �

� M Q Y & O Q R Q ù M ¤ � � T & ; O Q Y � 1 ¢ I � ü � L � « . X & « ¤ � � � � X & ; « ± � � � � �

� � � + ( � � � � � � � � � � � � � ( � �

� M Q Y & O Q R Q ù M ¤ � � T & ; O Q Y � 1 ¢ I � ü � L � « . X & « ¤ � � � � X & ; « ± � � � � , ¢ * � £ ¢ � ¢ I � � � ± � � � � �

� � � ? F N � D F B F � � � E @ B � N A @ C F V � � F � H E B D

� é ø å ó î ë ñ � ð é æ õ í å ê ç ê í ë ê è ë ê ç ê õ í æ õ ô í å ê ø î ý ê ë é ô ê ø ë æ í ê ë æ î õ ó î ë é ç í é í ê ø å é ë í æ ç ñ î ì ê ð ø å ê ø > ê ì é ô é æ õ ç í í å ê

� � @ è ë î ô ë é ñ î ó í å ê ç í é í ê ø å é ë í � J ó í å ê ó î ë ñ � ð é æ ç ó é ð ç ê � � � @ è ë î ì � ø ê ç é ø î � õ í ê ë ê é ñ è ð ê þ å æ ø å � è ë î K ê ø í ê ì

î õ í î í å ê æ õ è � í é õ ì î � í è � í ê ý ê õ í î ó í å ê ç í é í ê ø å é ë í � � æ ê ð ì ç é í ê ç í ç ê 4 � ê õ ø ê í î ï ê æ õ ø ð � ì ê ì æ õ é í ê ç í ç � æ í ê � J ó í å ê

ó î ë ñ � ð é æ ç í ë � ê � õ î ø î � õ í ê ë ê é ñ è ð ê æ ç è ë î ì � ø ê ì þ å æ ø å æ ñ è ð æ ê ç í å é í í å ê ë ê æ ç õ î í ê ç í ç ê 4 � ê õ ø ê ó î ë í å ê ø î ý ê ë é ô ê

ê è ë ê ç ç ê ì ï � í å ê ó î ë ñ � ð é �

� î ë ê é ñ è ð ê � ø î õ ç æ ì ê ë í å ê ó î ë ñ � ð é M Q Y & 9 O Q Y � I � � £ � � ó ë î ñ í å ê í ë é õ ç æ í æ î õ ø î ý ê ë é ô ê ø ë æ í ê ë æ î õ ó î ë ñ � ð é

ç ê í ó î ë í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê � � î ì ê ð ø å ê ø > æ õ ô î ó í å æ ç ó î ë ñ � ð é è ë î ì � ø ê ç í å ê ø î � õ í ê ë ê é ñ è ð ê ç å î þ õ

æ õ � è è ê õ ì æ � � ä å ê ø î � õ í ê ë ê é ñ è ð ê æ ç í å ê ç � ñ ï î ð æ ø ë ê è ë ê ç ê õ í é í æ î õ î ó í å ê ë � õ æ õ � æ ô � ë ê # é õ ì ø î ý ê ë ç í å ê

í ë é õ ç æ í æ î õ & 9 � M å ê õ ô ê õ ê ë é í æ õ ô ø î � õ í ê ë ê é ñ è ð ê ç � � � @ ì ê ç ø ë æ ï ê ç é õ æ õ æ í æ é ð ç í é í ê ï � è ë î ý æ ì æ õ ô í å ê ý é ð � ê ç î ó é ð ð

ý é ë æ é ï ð ê ç é õ ì è ë ê ì æ ø é í ê ç � ä å ê î í å ê ë ç í é í ê ç é ë ê ì ê ç ø ë æ ï ê ì æ õ í ê ë ñ ç î ó î õ ð � í å ê ý é ð � ê ç í å é í é ë ê ø å é õ ô ê ì ó ë î ñ î õ ê

ç í é í ê í î í å ê õ ê í � ä å ê ø î � õ í ê ë ê é ñ è ð ê æ ç ñ é è è ê ì æ õ í î í å ê í ê ç í ç ê 4 � ê õ ø ê � � G � � $ � G E � � � ¢ E � � � � � G � � � - � £ ¢ ° ! I �

G E � � ) � � � I � $ I � � ä ê ç í ç � æ í ê ç ó î ë í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê þ æ í å ë ê ç è ê ø í í î ç ê ý ê ë é ð ø î ý ê ë é ô ê ø ë æ í ê ë æ é é ë ê ç å î þ õ

æ õ � è è ê õ ì æ � �

� � ß Ü â � á � ã ß Ü � � Ü à � á Ý á Þ � � ß Þ �

M ê å é ý ê è ë ê ç ê õ í ê ì é ñ î ì ê ð ø å ê ø > æ õ ô é è è ë î é ø å í î é � í î ñ é í æ ø í ê ç í ô ê õ ê ë é í æ î õ ó ë î ñ ç í é í ê ø å é ë í ç � ä ê ç í ç � æ í ê ç é ë ê

ô ê õ ê ë é í ê ì é ø ø î ë ì æ õ ô í î é ç ê í î ó þ æ ì ê ð � � ç ê ì ø î ý ê ë é ô ê ø ë æ í ê ë æ é ï é ç ê ì î õ í å ê : î þ î ó ø î õ í ë î ð é õ ì ì é í é � � é ø å

ø î ý ê ë é ô ê ø ë æ í ê ë æ î õ æ ç ê è ë ê ç ç ê ì é ç é ç ê í î ó ó î ë ñ � ð é ç æ õ í å ê í ê ñ è î ë é ð ð î ô æ ø < ä , � � é ø å ó î ë ñ � ð é ì ê � õ ê ç î õ ê

í ê ç í ç ê 4 � ê õ ø ê æ õ ç � ø å é þ é � í å é í í å ê ó î ë ñ � ð é æ ç ç é í æ ç � ê ì ï � é ç í é í ê ø å é ë í æ ó é õ ì î õ ð � æ ó í å ê í ê ç í ç ê 4 � ê õ ø ê æ ç

æ õ ó ê é ç æ ï ð ê æ õ í å ê ç è ê ø æ � ø é í æ î õ � % í å ê ë þ æ ç ê � í å ê ñ î ì ê ð ø å ê ø > ê ë è ë î ì � ø ê ç é ø î � õ í ê ë ê é ñ è ð ê ó î ë í å ê ó î ë ñ � ð é � ä å ê

ø î � õ í ê ë ê é ñ è ð ê � è ë î K ê ø í ê ì î õ í î í å ê î ï ç ê ë ý é ï ð ê ê ý ê õ í ç î ó í å ê ç í é í ê ø å é ë í � � æ ê ð ì ç é í ê ç í ç ê 4 � ê õ ø ê � ä å ê ñ é æ õ

é ì ý é õ í é ô ê î ó í å ê é è è ë î é ø å æ ç í å é í î õ ð � ó ê é ç æ ï ð ê î ë ê ê ø � í é ï ð ê í ê ç í ç ê 4 � ê õ ø ê ç é ë ê ô ê õ ê ë é í ê ì � þ å æ ø å î ï ý æ é í ê ç

í å ê õ ê ê ì î ó è î ç í ê ë æ î ë é õ é ð � ç æ ç ç � ø å é ç ç � ñ ï î ð æ ø ê ê ø � í æ î õ î ë ø î õ ç í ë é æ õ í ç î ð ý æ õ ô �

26

Page 37: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� � � � � � - � � � � ä å æ ç è é è ê ë ì î ê ç õ î í ø î õ ç æ ì ê ë ç ê ý ê ë é ð æ ñ è î ë í é õ í ó ê é í � ë ê ç î ó ç í é í ê ø å é ë í ç ç � ø å é ç é ø í æ î õ ç é ç ç î Q

ø æ é í ê ì þ æ í å ç í é í ê ç � í ë é õ ç æ í æ î õ ç þ æ í å ñ � ð í æ è ð ê ç î � ë ø ê é õ ì í é ë ô ê í ç í é í ê ç � ø î ñ è î � õ ì í ë é õ ç æ í æ î õ ç � å æ ç í î ë æ ê ç � é õ ì

ë ê é ð Q í æ ñ ê ø î õ ç í ë � ø í ç ç � ø å é ç í æ ñ ê î � í ê ý ê õ í ç é õ ì ç ø å ê ì � ð ê ì é ø í æ î õ ç � ! î þ ê ý ê ë � æ í æ ç ó é æ ë ð � ç æ ñ è ð ê í î ê í ê õ ì î � ë

í ê ç í ô ê õ ê ë é í æ î õ ñ ê í å î ì î õ ø ê þ ê å é ý ê é ó î ë ñ é ð ì ê � õ æ í æ î õ ó î ë í å ê ç ê ó ê é í � ë ê ç æ õ í ê ë ñ ç î ó � ë æ è > ê ç í ë � ø í � ë ê ç �

� é õ � ý é ë æ é õ í ç î ó ç ê ñ é õ í æ ø ç å é ý ê ï ê ê õ è ë î è î ç ê ì ó î ë ç í é í ê ø å é ë í ç ù û ü � � ê ñ é õ í æ ø ì æ � ê ë ê õ ø ê ç é � ê ø í î õ ð � í å ê

í ë é õ ç ð é í æ î õ ñ ê í å î ì ó ë î ñ ç í é í ê ø å é ë í ç æ õ í î æ õ è � í ç í î é ñ î ì ê ð ø å ê ø > ê ë � J õ ó é ø í � î � ë ó î ë ñ é ð æ C é í æ î õ î ó ø î ý ê ë é ô ê

ø ë æ í ê ë æ é é ç ø î ð ð ê ø í æ î õ ç î ó < ä , ó î ë ñ � ð é ç æ ç ð é õ ô � é ô ê Q æ õ ì ê è ê õ ì ê õ í é õ ì æ ç é è è ð æ ø é ï ð ê þ æ í å ñ æ õ î ë ñ î ì æ � ø é í æ î õ ç

í î é õ � > æ õ ì î ó ç è ê ø æ � ø é í æ î õ ð é õ ô � é ô ê ç ï é ç ê ì î õ � � � � ç � ê � ô � � � � , î ë � ç í ê ð ð ê �

' 3 � � � � � � � � ( � � � - � � - � � � õ � ñ ï ê ë î ó î í å ê ë ø î ý ê ë é ô ê ø ë æ í ê ë æ é ï é ç ê ì î õ ø î õ í ë î ð é õ ì ì é í é : î þ é õ é ð � ç æ ç

å é ý ê ï ê ê õ è ë î è î ç ê ì æ õ í å ê ç î ó í þ é ë ê í ê ç í æ õ ô ð æ í ê ë é í � ë ê ç ê ê � ó î ë ê é ñ è ð ê � ù û # ü � � � î ñ ê î ó í å ê ç ê ø î ý ê ë é ô ê ø ë æ í ê ë æ é

ø é õ õ î í ï ê å é õ ì ð ê ì � ç æ õ ô � � @ � ï ê ø é � ç ê í å ê æ ë < ä , è ë î è ê ë í æ ê ç ø î õ í é æ õ � õ æ ý ê ë ç é ð è é í å 4 � é õ í æ � ê ë ç � � î ë ê é ñ è ð ê �

é ð ð Q ì � Q è é í å ç ø î ý ê ë é ô ê ø ë æ í ê ë æ î õ ë ê 4 � æ ë ê ç í å é í é ð ð ì ê � õ æ í æ î õ Q ø ð ê é ë ë � õ ç ó î ë é ì ê � õ æ í æ î õ Q � ç ê è é æ ë ï ê í ë é ý ê ë ç ê ì �

ä î ô ê õ ê ë é í ê í ê ç í ç ó î ë í å æ ç ø ë æ í ê ë æ î õ ø î ë ë ê ø í ð � � � � @ þ î � ð ì å é ý ê í î è ë î ì � ø ê é ð ð ø î � õ í ê ë ê é ñ è ð ê ç í î ê é ø å < ä ,

ó î ë ñ � ð é æ õ ç í ê é ì î ó î õ ð � î õ ê � � � ø å ø î ý ê ë é ô ê ø ë æ í ê ë æ é ø é õ ï ê å é õ ì ð ê ì ï � ê í ê õ ì æ õ ô � � @ í î è ë î ì � ø ê ñ � ð í æ è ð ê

ø î � õ í ê ë ê é ñ è ð ê ç î ë ï � � ç æ õ ô é ì æ � ê ë ê õ í ñ î ì ê ð ø å ê ø > ê ë í å é í å é ç í å æ ç ó é ø æ ð æ í � �

� � + � � � � - + - � � � J õ í å ê ø é ç ê î ó õ î õ Q ì ê í ê ë ñ æ õ æ ç í æ ø ç í é í ê ø å é ë í ç � í å ê ë ê ñ é � ï ê ñ î ë ê í å é õ î õ ê è î ç ç æ ï ð ê

î � í è � í ç ê 4 � ê õ ø ê ó î ë é ô æ ý ê õ æ õ è � í ç ê 4 � ê õ ø ê � J õ í å æ ç ç æ í � é í æ î õ � é ç æ õ ô ð ê ø î � õ í ê ë ê é ñ è ð ê è ë î ì � ø ê ì ï � í å ê

ñ î ì ê ð ø å ê ø > ê ë æ ç õ î í ê õ î � ô å ó î ë í å ê æ õ è � í ç ê 4 � ê õ ø ê � ç æ õ ø ê æ í þ æ ð ð æ ì ê õ í æ ó � î õ ð � î õ ê î � í è � í ç ê 4 � ê õ ø ê é ñ î õ ô

é ð ð è î ç ç æ ï ð ê î õ ê ç � � è î ç ç æ ï ð ê ç î ð � í æ î õ í î í å æ ç è ë î ï ð ê ñ æ ç í î í ë ê é í í å ê ø î � õ í ê ë ê é ñ è ð ê é ç è ë ê ç ø ë æ ï æ õ ô î õ ð �

í å ê ¢ E � ± I ç ê 4 � ê õ ø ê � � õ ê í ë é ç í ê è æ ç í å ê õ õ ê ê ì ê ì í î � õ ì é ð ð î � í è � í ç ê 4 � ê õ ø ê ç ø î ë ë ê ç è î õ ì æ õ ô í î í å æ ç æ õ è � í

ç ê 4 � ê õ ø ê � J ó þ ê å é ý ê é ñ î ì ê ð ø å ê ø > ê ë í å é í è ë î ì � ø ê ç ñ � ð í æ è ð ê ø î � õ í ê ë ê é ñ è ð ê ç í î é ó î ë ñ � ð é � é ç ì æ ç ø � ç ç ê ì æ õ

í å ê è ë ê ý æ î � ç è é ë é ô ë é è å � þ ê ø é õ ê è ë ê ç ç í å ê æ õ è � í ç ê 4 � ê õ ø ê é ç é < ä , ó î ë ñ � ð é é õ ì ô æ ý ê æ í ç õ ê ô é í æ î õ í î í å ê

ñ î ì ê ð ø å ê ø > ê ë � ä å ê ç ê í î ó ø î � õ í ê ë ê é ñ è ð ê ç è ë î ì � ø ê ì ï � í å ê ñ î ì ê ð ø å ê ø > ê ë þ æ ð ð ø î õ í é æ õ é ð ð ó ê é ç æ ï ð ê î � í è � í

ç ê 4 � ê õ ø ê ç �

' 4 - � - / � - � + � � % ó í ê õ í å ê í ê ç í ç � æ í ê ø î õ ç í ë � ø í ê ì ï � î � ë é è è ë î é ø å þ æ ð ð ø î õ í é æ õ ë ê ì � õ ì é õ í í ê ç í ç � � î ë ê é ñ Q

è ð ê � æ õ í å ê í ë é õ ç æ í æ î õ ø î ý ê ë é ô ê í ê ç í ç � æ í ê ó î ë í å ê ø î � ê ê ý ê õ ì æ õ ô ñ é ø å æ õ ê � í å ê í ê ç í ç ê 4 � ê õ ø ê í î ø î ý ê ë í ë é õ ç æ í æ î õ

& � � � G � � $ � G E � � � ¢ E � � � � ¢ E � � � � ¤ � � � - � £ ¢ ° ! I � G E � � ) � ) � ) þ æ ð ð é ð ç î ø î ý ê ë í ë é õ ç æ í æ î õ ç & § X & � � é õ ì & � � J í æ ç � í å ê ë ê ó î ë ê �

õ ê ø ê ç ç é ë � í î å é ý ê å ê � ë æ ç í æ ø ç í î ñ æ õ æ ñ æ C ê í å ê õ � ñ ï ê ë î ó ô ê õ ê ë é í ê ì í ê ç í ç þ æ í å î � í ç é ø ë æ � ø æ õ ô í å ê ø î ý ê ë é ô ê í å ê �

è ë î ý æ ì ê �

� � � � Þ � Ü â � �

ù ú ü ² � � ñ ñ é õ õ � ² � � ð é ø > � é õ ì M � � é K � ë ç > æ � � + ç æ õ ô � î ì ê ð < å ê ø > æ õ ô í î � ê õ ê ë é í ê ä ê ç í ç ó ë î ñ � è ê ø æ � ø é í æ î õ ç � �æ õ � $ G � � � ¤ ¢ E ° � G � � E ¤ � / / / � E I � $ E � I ¢ G E � £ � G E � � $ � E � � G E � G $ * � £ / E ° ¢ E � � $ ¢ E ° � � I ! G ¤ � � è è � . $ Q � . � ú � � = �

ù û ü � � ý î õ ì ê ë � ê ê ø > � � � < î ñ è é ë æ ç î õ î ó � í é í ê ø å é ë í ç @ é ë æ é õ í ç � � æ õ � G $ * � £ � � � ! E ¢ � ± � � ¢ E � � � £ � � ¢ * � � � ± £ I �

� G £ � $ � E I � � � I � * � � , ê ø í � ë ê % î í ê ç æ õ < î ñ è � í ê ë � ø æ ê õ ø ê � @ î ð � = $ # � è è � ú û = Q ú . = � � è ë æ õ ô ê ë Q @ ê ë ð é ô � ú � � . �

ù # ü � � ý � � î ø å ñ é õ õ é õ ì � � ² ê í ë ê õ > î � � ² ë î í î ø î ð ä ê ç í æ õ ô � # ê ý æ ê þ î ó � ê í å î ì ç é õ ì # ê ð ê ý é õ ø ê ó î ë � î ó í þ é ë ê

ä ê ç í æ õ ô � � æ õ � $ G � � � ¤ ¢ E ° � G � I ! � � � � � � E I � $ E � I ¢ G E � £ � � * � G � ¢ ± * G E � G � I � � $ � � � � I ¢ E ° � E ¤ � E � £ � � ¢ � � è è �

ú � � Q ú û . � ú � � . �

ù . ü # � � � � ë � é õ í � � � ë é è å Q � é ç ê ì � ð ô î ë æ í å ñ ç ó î ë � î î ð ê é õ � � õ ø í æ î õ � é õ æ è � ð é í æ î õ � � � / / / � $ � E � � � I ¢ G E � G E

� G * � ± I � $ � � @ î ð � < Q # � � % î � $ � è è � $ � � Q $ � ú � � � ô � ú � = $ �

ù � ü � � # � � � ë ø å � � � � � < ð é ë > ê � � � , � � ø � æ ð ð é õ � � � , � � æ ð ð � é õ ì � � ! þ é õ ô � � � � ñ ï î ð æ ø � î ì ê ð < å ê ø > æ õ ô � ú �© j

� í é í ê ç é õ ì � ê � î õ ì � � æ õ � $ G � � � ¤ ¢ E ° � G � I ! � � ¢ � I ! � E E ± � £ � � * � G � ¢ ± * G E � G ° ¢ � ¢ E � G * � ± I � $ � � ¢ � E � � � ú � � � �

ù $ ü � � < é ð ð é å é õ � � � � ø å õ ê æ ì ê ë � é õ ì � � � é ç í ê ë ï ë î î > � � � è ê ø æ � ø é í æ î õ Q ï é ç ê ì ä ê ç í æ õ ô + ç æ õ ô � î ì ê ð < å ê ø > æ õ ô � �æ õ � $ G � � � ¤ ¢ E ° � G � � � � $ � � � ' ) G $ f � ! G � � é ð ç î ä ê ø å õ æ ø é ð # ê è î ë í % � � � Q J @ @ Q � $ Q � û û � M ê ç í @ æ ë ô æ õ æ é + õ æ Q

ý ê ë æ ç í � � ú � � $ �

27

Page 38: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

ù � ü M � < å é õ � # � � � � õ ì ê ë ç î õ � ² � � ê é ñ ê � � � � � ë õ ç � � � � î ì � ô õ î � � � % î í > æ õ � é õ ì � � � � # ê ê ç ê � � � î ì ê ð < å ê ø > æ õ ô, é ë ô ê � î ó í þ é ë ê � è ê ø æ � ø é í æ î õ ç � � � / / / � $ � E � � � I ¢ G E � G E � G � I � � $ � / E ° ¢ E � � $ ¢ E ° � @ î ð � û . � % î � � � è è � . � = Q � û � �

� � ð � ú � � = �

ù = ü � � � � < ð é ë > ê � � � � � � ñ ê ë ç î õ � é õ ì � � ² � � æ ç í ð é � � � � í î ñ é í æ ø @ ê ë æ � ø é í æ î õ î ó � æ õ æ í ê Q � í é í ê < î õ ø � ë ë ê õ í � � ç í ê ñ ç+ ç æ õ ô ä ê ñ è î ë é ð , î ô æ ø � è ê ø æ � ø é í æ î õ ç � � � � � � $ � E � � � I ¢ G E � G E � $ G ° $ � * * ¢ E ° � � E ° ± � ° � � � E ¤ � � � I � * � � @ î ð �

= � % î � û � è è � û . . Q û $ # � � è ë � ú � = $ �

ù � ü # � � ç ç î � ð æ � � � � é ð ê å � � � � ï î � ð å é ñ æ ì � � � � õ Q % î � é é ë � � é õ ì < � � î � ë å � ë � � ä ê ç í � ê ý ê ð î è ñ ê õ í ó î ë < î ñ ñ � Q

õ æ ø é í æ î õ ² ë î í î ø î ð ç � í î þ é ë ì ç � � í î ñ é í æ î õ � � � G * � ± I � $ ' � I � G $ f � � @ î ð � # ú � @ î ð � ú � � è è � ú = # � Q ú = � û � ú � � � �

ù ú � ü � � � õ ô ê ð ç � , � � ê æ K ç � é õ ì � � � é � þ � � ä ê ç í � ê õ ê ë é í æ î õ ó î ë J õ í ê ð ð æ ô ê õ í % ê í þ î ë > ç + ç æ õ ô � î ì ê ð < å ê ø > æ õ ô � � æ õ� $ G � � � ¤ ¢ E ° � G � � � � � � � � � � , ê ø í � ë ê % î í ê ç æ õ < î ñ è � í ê ë � ø æ ê õ ø ê � @ î ð � ú û ú � � è è � # = . Q # � = � � è ë æ õ ô ê ë Q @ ê ë ð é ô �

ú � � � �

ù ú ú ü � � � é ë ô é õ í æ õ æ é õ ì < � ! ê æ í ñ ê � ê ë � � + ç æ õ ô � î ì ê ð < å ê ø > æ õ ô í î � ê õ ê ë é í ê ä ê ç í ç ó ë î ñ # ê 4 � æ ë ê ñ ê õ í ç � è ê ø Q

æ � ø é í æ î õ ç � � æ õ � $ G � � � ¤ ¢ E ° � G � I ! � � G ¢ E I � I ! / ± $ G � � � E � G � I � � $ � / E ° ¢ E � � $ ¢ E ° � G E � � $ � E � � � E ¤ � I ! � � �

� � � � � � � E I � $ E � I ¢ G E � £ � � * � G � ¢ ± * G E � G ± E ¤ � I ¢ G E � G � � G � I � � $ � / E ° ¢ E � � $ ¢ E ° � è è � $ Q ú � � ú � � � �

ù ú û ü � � ! é ë ê ð � � � í é í ê ø å é ë í ç � é @ æ ç � é ð � î ë ñ é ð æ ç ñ ó î ë < î ñ è ð ê � � ç í ê ñ ç � � � � ¢ � E � � G � � G * � ± I � $ � $ G ° $ � * * ¢ E ° �

@ î ð � = � è è � û # ú Q û � . � ú � = � �

ù ú # ü � � ! é ë ê ð é õ ì � � % é é ñ é ì � � ä å ê � ä � ä � � � ä � � ê ñ é õ í æ ø ç î ó � í é í ê ø å é ë í ç � � � � � � $ � E � � � I ¢ G E � G E � G � I �

� � $ � / E ° ¢ E � � $ ¢ E ° � E ¤ � � I ! G ¤ G £ G ° ¢ � � � @ î ð � � � % î � . � è è � û � # Q # # # � % ø í � ú � � $ �

ù ú . ü � � � � ! ê ø å í � � £ G � � E � £ � � ¢ � G � � G * � ± I � $ � $ G ° $ � * � � � ð ç ê ý æ ê ë % î ë í å Q ! î ð ð é õ ì � ú � � � �

ù ú � ü ! � � � ! î õ ô � � � � � � æ ñ � � � � � < å é � � � ! � � é ê � é õ ì ! � + ë é ð � � � ä ê ç í � ê 4 � ê õ ø ê � ê ð ê ø í æ î õ � ê í å î ì ó î ë� í é í ê ø å é ë í ç � � � G ± $ E � £ G � � G � I � � $ � � � � I ¢ E ° � � � $ ¢ ¯ � � I ¢ G E � � E ¤ � � £ ¢ � � ¢ £ ¢ I � � @ î ð � ú � � % î � . � è è � û � # Q û û � �

� ê ø � û � � � �

ù ú $ ü ! � � � ! î õ ô � J � , ê ê � % � � î > î ð ç > � � é õ ì � � � � < å é � � � � í î ñ é í æ ø ä ê ç í � ê õ ê ë é í æ î õ ó ë î ñ � í é í ê ø å é ë í ç + ç æ õ ô� î ì ê ð < å ê ø > æ õ ô � � ä ê ø å õ æ ø é ð # ê è î ë í � � Q < J � Q � ú Q � � � � ê è é ë í ñ ê õ í î ó < î ñ è � í ê ë é õ ì J õ ó î ë ñ é í æ î õ � ø æ ê õ ø ê �

+ õ æ ý ê ë ç æ í � î ó ² ê õ õ ç � ð ý é õ æ é � û � � ú � � ý é æ ð é ï ð ê é í � � � � � � � � � � � � � � � ! � # $ $ � # ' ! � � # � � + # � - + � � � � � . / �

ù ú � ü J ä + Q ä � # ê ø î ñ ñ ê õ ì é í æ î õ 1 � � � . Q J õ ó î ë ñ é í æ î õ ä ê ø å õ î ð î ô � Q % è ê õ � æ ç í ë æ ï � í ê ì ² ë î ø ê ç ç æ õ ô Q # ê ó ê ë ê õ ø ê� î ì ê ð � � ë ø å æ í ê ø í � ë é ð � ê ñ é õ í æ ø ç � � ê ø � ú � � � �

ù ú = ü ä � � ê ë î õ é õ ì ² � � î ë ê ð � � ä ê ç í � ê õ ê ë é í æ î õ � ê ë æ ý ê ì � ë î ñ � î ì ê ð < å ê ø > æ õ ô � � æ õ � $ G � � � ¤ ¢ E ° � G � � � � � � � �

, % < � ú $ # # � è è � ú � = Q ú û ú � ú � � � �

ù ú � ü � � � î ë ê ð � � ä å ê ² ë î ô ë é ñ � ê è ê õ ì ê õ ø ê � ë é è å æ õ � í é í æ ø ² ë î ô ë é ñ ä ê ç í æ õ ô � � � E � G $ * � I ¢ G E � $ G � � � � ¢ E ° � � I I � $ � �

@ î ð � û . � è è � ú � # Q ú � = � � é õ � ú � = � �

ù û � ü � � , ê ê é õ ì � � � é õ õ é > é > æ ç � � ² ë æ õ ø æ è ð ê ç é õ ì � ê í å î ì ç î ó ä ê ç í æ õ ô � æ õ æ í ê � í é í ê � é ø å æ õ ê ç Q � � � ë ý ê � � �

� $ G � � � ¤ ¢ E ° � G � I ! � � / / / � @ î ð � = . � % î � = � è è � ú � � � Q ú ú û # � � � ô � ú � � $ �

ù û ú ü � � , � � ø � æ ð ð é õ � � � * � G £ ¢ � � G ¤ � £ � ! � � f ¢ E ° 9 � E � � � $ G � � ! I G I ! � � I � I � / 1 � £ G � ¢ G E � $ G � £ � * � � ð � þ ê ë � ø é Q

ì ê ñ æ ø ² � ï ð æ ç å ê ë ç � ú � � # �

ù û û ü ² � � � # é ñ é ì ô ê é õ ì M � � � M î õ å é ñ � � � � è ê ë ý æ ç î ë � < î õ í ë î ð î ó é < ð é ç ç î ó � æ ç ø ë ê í ê � ý ê õ í ² ë î ø ê ç ç ê ç � � � � � �

� G ± $ E � £ G � � G E I $ G £ � E ¤ � I ¢ * ¢ 5 � I ¢ G E � @ î ð � û � � % î � ú � è è � û � $ Q û # � � � é õ � ú � = � �

ù û # ü � � # é è è ç é õ ì � � � � M ê � � > ê ë � � � ê ð ê ø í æ õ ô � î ó í þ é ë ê ä ê ç í � é í é + ç æ õ ô � é í é � ð î þ J õ ó î ë ñ é í æ î õ � � � / / / � $ � E � �

� � I ¢ G E � G E � G � I � � $ � / E ° ¢ E � � $ ¢ E ° � @ î ð � � � Q ú ú � % î � . � è è � # $ � Q # � � � � è ë � ú � = � �

ù û . ü � � # � ñ ï é � ô å � � � � î î ø å � é õ ì J � � é ø î ï ç î õ � � ! � 7 � � � � � � $ � E � � � ± ¢ ¤ � � � ì ì æ ç î õ M ê ç ð ê � , î õ ô ñ é õ � ú � � � �

ù û � ü ! � + ë é ð � � � � é ð ê � é õ ì � � M æ ð ð æ é ñ ç � � ä ê ç í � ê õ ê ë é í æ î õ � é ç ê ì î õ < î õ í ë î ð é õ ì � é í é � ê è ê õ ì ê õ ø æ ê ç þ æ í å æ õ� � ç í ê ñ � è ê ø æ � ø é í æ î õ ç æ õ � � , � � � G * � ± I � $ � G * * ± E ¢ � � I ¢ G E � � @ î ð � û # � è � $ � � Q $ û � � û � � � �

28

Page 39: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� � â ß á Ü Ý � Þ � � � � � � � � ß Þ M Q Y � & 9 O Q Y � I � � £ � �

� � � � � � � � � � � � � � � � � � � " � � � � � % & � ' � � � � & � �� � � � * � + � � � � , � � � * % - � / � � � & & � 0 � � 1 � 2 � � 3 � � � � � � 5 3 � � � �� � � � � 6 7 6 :� � � % & � < =

> ? @ < � � � > A � � � � < � * & � @ A B � C < � + � -� � � � � � � + � - < = � � � � + � - < = � � � + � � � - < = � � � % 3 � - < = � � � � * & � < = � � � � � � � � � < = � � � � � < = � � � � � � < 6 � � � � D + < 6

+ < = � 0 � , � � � < 6 � 0 � , � � � � < = � � � � � � < = * � � � < = � � � < = * � � < = & � 1 / � � � � < = & � 1 / � � � � � < = � � � , � < = � � � < =

� � � � & � � � � � F < = � � � � & � � � � � G < = � � � � & � � � � � H < = � � � � & � � � � � I < =� � � � & � � � � � J < = � � � � & � � � � � < = � � � � & � � � � � K < = � � � � & � � � � � 6 < =

+ � - � � � 3 , � � F < = + � - � � � 3 , � � G < = + � - � � � 3 , � � H < = + � - � � � 3 , � � I < =+ � - � � � 3 , � � J < = + � - � � � 3 , � � < = + � - � � � 3 , � � K < = + � - � � � 3 , � � 6 < 6� 6 < = � K < = � < = � J < = � I < = � H < = � G < = � F < =

� � 6 < = � � K < = � � < = � � J < = � � I < = � � H < = � � G < = � � F < = � � M < = � � 6 = < = � � 6 6 < = � � 6 K < =

� � � � � 6 7 K :� � � % & � < 6

> ? @ < � � � � � � + � - < 6 � � � + � � � - < 6 � � � � * & � < 6 � � � � � � � � � < 6 � � � � � < 6 � � � � � � < = � 0 � , � � � < = & � 1 / � � � � < 6 + � - � � � 3 , � � 6 < = � 6 < 6

� � � � � 6 7 :� � � % & � < = � � � < 6 & � 1 / � � � � < = + � - � � � 3 , � � I < 6 � 6 < =

� � � � � 6 7 J :� � � % & � < 6 @ A B � C < � � � � + � - � � � � � � � + � - < 6 � � � � + � - < = � � � < = + < 6 + � - � � � 3 , � � I < = � I < 6

� � � � � 6 7 I :� � � % & � < = � � � � � � < 6 + � - � � � 3 , � � < 6 � I < =

� � � � � 6 7 H :> A � � � � < % 3 � - � � � % 3 � - < 6 � � � � * & � < = � � � � � � < = * � � < 6 � � � , � < 6 + � - � � � 3 , � � F < 6 + � - � � � 3 , � � < = � < 6

� � � � � 6 7 G :� � � % & � < 6 @ A B � C < � + � - � � � � � � � + � - < = � � � � + � - < 6 + < = * � � < = � � � , � < = + � - � � � 3 , � � F < = � < = � F < 6

, � � � 3 , � � � 3 � � * :3 � � , � � + � : = 7 H � T � - � � � + � � + � : = 7 = �W X X � � * � � � & & � � � � � * : 6 J = G =W - � � � � & & � � � � � * : 6 G H K I HW X X � � * � � , � , � � � � � � � 1 � , � � � � � � � � , � & � � � � � : J J M H ] H

� � � Ý � á ã Ý � � � ß Þ Ý � � ß ^ � � ` � Ü à ã Ü � � � â ã Ü �� � � � � � � � � ( �

¯ º ² º ³ µ ³ ¯ ¹ » ºF G G ! ^ !o p r n � R T V X Y [ T ] � ^ � _ ` a c d [ T ] �

s t u v� R T V X Y [ T ] � Ò � ` ] x � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò ! Ò � } d ~ Y d �n > � �

v� R T V X Y [ T ] � ^ � _ ` a c d [ T ] �l F � n > � �

v� R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � ^ � _ ` a c d [ T ] � Ò ! Ò !

� � + 3 ( � � � - � + � � � � � � ( �

¯ º ² º ³ µ ³ ¯ ¹ » º� F G G � ! ^ !� o p r n $ n > � �

v� � R T V X Y [ T ] � ^ � _ ` a c d [ T ] �

� o p r n $ l F � n > � �v

� � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � ^ � _ ` a c d [ T ] � Ò ! Ò !�

s t u v$ n > � �

v� � R T V X Y [ T ] � Ò � ` ] x � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò ! Ò � } d ~ Y d �

�s t u v

$ l F � n > � �v

� � R T V X Y [ T ] � Ò � ` ] x � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò ! Ò � } d ~ Y d �

29

Page 40: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� � � + ( - � � + � - - � + � � � � � � ( �

º µ ² ½ ¯ ® º ® ¼ ½ µ ³ ¯ ¹ » º

N O � R T V X Y [ T ] � ^ � _ ` a c d [ T ] �N h � R T V X Y [ T ] � Ò � R T V X Y [ T j � ^ � _ ` a c d [ T ] � Ò � _ ` a c d [ T j �N w � R T V X Y [ T ] � Ò � ` ] x � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò ! Ò � } d ~ Y d �N � � R T V X Y [ T ] � Ò � ` ] x � Ò � x T j X X � Ò � � T ] X � ^ � _ ` a c d [ T ] � Ò ! Ò � } d ~ Y d � Ò � } d T R �N � � R T V X Y [ T ] � Ò � ` ] x � ^ � _ ` a c d [ T ] � Ò !N � � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � ^ � _ ` a c d [ T ] � Ò ! Ò !N � � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � � X x � ^ � _ ` a c d [ T ] � Ò ! Ò ! Ò !N � � R T V X Y [ T ] � Ò � ` ] x � Ò � � X x � ^ � _ ` a c d [ T ] � Ò ! Ò !� N O � R T V X Y [ T j � ^ !� N h � x T j X X � ^ !� N w � � T ] X � ^ !� N � � ` ] x � ^ !� N � ` ] � X ~ } ` � _ X

� N � � R T V X Y [ T ] � Ò � R T V X Y [ T ] � ^ � _ ` a c d [ T ] � Ò !� N � � R T V X Y [ T ] � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò !� N � � R T V X Y [ T ] � Ò � ` ] x � Ò � x T j X X � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò ! Ò � } d ~ Y d � Ò !� N � � R T V X Y [ T ] � Ò � � T ] X � ^ � _ ` a c d [ T ] � Ò !� N O

�� R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � ^

� _ ` a c d [ T ] � Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò !� N O O ` ] � X ~ } ` � _ X

� N O h ` ] � X ~ } ` � _ X

� � � + ( � � � � � � � � � � � � � ( �

º ¹ ± » ³ µ ³ ¯ ¹ » º

� e Ò N O Ò � N � # � R T V X Y [ T ] � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò !� e Ò N � Ò N w # � R T V X Y [ T ] � Ò � ` ] x � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò ! Ò � } d ~ Y d �� e Ò N � Ò N � # � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � ^ � _ ` a c d [ T ] � Ò ! Ò !� e Ò N � Ò N � # � R T V X Y [ T ] � Ò � ` ] x � Ò � � X x � ^ � _ ` a c d [ T ] � Ò ! Ò !� e Ò N � Ò N w # � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò ! Ò ! Ò � } d ~ Y d �� e Ò N � Ò N � # � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � ^ � _ ` a c d [ T ] � Ò ! Ò ! Ò !� e Ò N � Ò N � # � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � � X x � ^ � _ ` a c d [ T ] � Ò ! Ò ! Ò !� e Ò N � Ò � N O

�# � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � ^

� _ ` a c d [ T ] � Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò ! Ò !� e Ò N � Ò N w # � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � � X x � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò ! Ò ! Ò ! Ò � } d ~ Y d �� e Ò N � Ò N � # � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � � X x � Ò � ` ] x � ^ � _ ` a c d [ T ] � Ò ! Ò ! Ò ! Ò !� e Ò N � Ò N � # � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � ` ] x � Ò � � X x � Ò � � X x � ^ � _ ` a c d [ T ] � Ò ! Ò ! Ò ! Ò ! Ò !� e Ò N � Ò N � # � R T V X Y [ T ] � Ò � ` ] x � Ò � ` ] x � Ò � � X x � Ò � � X x � ^ � _ ` a c d [ T ] � Ò ! Ò ! Ò ! Ò !� e Ò N � Ò � N � # � R T V X Y [ T ] � Ò � ` ] x � Ò � � X x � Ò � x T j X X � ^ � _ ` a c d [ T ] � Ò ! Ò ! Ò !

J õ ó ê é ç æ ï ð ê é ç ç î ø æ é í æ î õ ç � 8 � & § � & 9 � � 8 � & § � & � � � 8 � & § � & � � 8 � & § � & � � 8 � & § � { & § j � � 8 � & § � { & § © � � 8 � & � �

& � � 8 � & � � { & � � 8 � & � � { & § j � � 8 � & � � { & § © � � 8 � & � � & � � 8 � & � � { & � � 8 � & � � { & § © � � 8 � & � { & � � 8 � & � { & § j � �

8 � & � { & § © � � 8 � & � & 9 � � 8 � & � & � � � 8 � & � & � � 8 � & � & � � 8 � & � { & § j � � 8 � & � { & § © � �

30

Page 41: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Automatic generation of tests from Statechart specifications

Simon Burton, John Clark, John McDermid

Department of Computer Science.University of York, Heslington, York. YO10 5DD, England.fSimon.Burton, John.Clark, [email protected]

Abstract

This paper describes how formal methods can be exploited in the automatic generation of testsfrom Statechart specifications, and in a manner that can be extended to other graphical and tabularnotations. Intermediate formal representations of both the specification and the testing conditionsare generated. Based on these formalisations, properties of the specification and the tests areanalysed and a combination of constraint solvers and automated theorem proving tools are usedto generate the tests. The paper also summarises experience in applying the techniques to anindustrially relevant case study.

1 Introduction

Graphical notations such as Statecharts [13], SDL [35] and UML [9] and tabular notations suchas the SCR method [16] are becoming increasingly popular as a means of specifying softwaresystems. Noteworthy applications of these techniques are telecommunication systems and embed-ded controllers for safety-critical systems. The functional correctness of such systems is crucialto ensure their safe and/or economic operation. Testing is the primary means of verifying thesesystems at present. However, the methods currently employed by industry are expensive, timeconsuming and error prone. A more reliable and automated approach to testing systems designedusing graphical and tabular specifications is therefore required.

Formal methods can greatly benefit the testing process. They allow for a precise and unam-biguous representation of the system specification and are amenable to rigorous and automatedanalysis. However, formal methods have still to gain widespread use in the software industry. Oneof the perceived barriers to the acceptance of formal methods is their reliance on mathematicalnotations that are not well accepted by the domain engineers who are typically not from a com-puter science background. There is a need, as Ould [27] put it, to “disguise” the formality so thatan impractical amount of formal methods skill is not a pre-requisite to effective V&V. Graphi-cal and tabular specification notations are one means of bridging the “semantic gap” between theengineers and the formal methods.

This paper describes how combining graphical and tabular notations with formal methodscan facilitate rigorous and automated testing. The paper presents the results of an industriallysponsored research program to develop a framework of automated testing techniques that can beapplied to a number of graphical and tabular notations. The framework consists of the following3 elements. An intermediate formal representation of the specification is automatically generatedbased on an understanding of the semantics of the source notation. Testing heuristics (both parti-tioning and fault-based) are also formalised using the same intermediate notation. This allows test

31

Page 42: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[UnstowedSensor

=False]/

Id le

ThrustLimi tat ion

Inadver tentDeploy

Unstowed

LockDetect OnGroundDetec t

Wa i t

Locked

InAir

OnGround

InadvertentDeploy/

LimitThrust:=True

[Thrott leReq<=FwdIdle]/

RestowComplete;

LimitThrust:=False

[UnstowedSensor

=True/ [Timer>10]

[Thrott leReq<=FwdIdle

AND OnGround=True] /

LimitThrust:=False

T1

T2

T3

T4T5

T6T8

T9

T10

[T imer<=10]/

T imer :=Timer+1

T11

Awai tLock

Timer:=0

T7

Figure 1: Example Statechart - Thrust Limitation

cases to be automatically generated that are correct through construction with respect to the orig-inal specification and testing heuristics. Where the specification includes reference to a persistentdata state, the test cases are sequenced to allow the initial state for a test to be set and the effects ofa test on the state to be verified. The formalisation also allows for properties of the specificationsand testing heuristics to be analysed. The notions of weak and strong detectability, normally as-sociated with program-based mutation testing, are described in the context of specification-basedtesting. Weak and strong fault detection conditions are used to assess the testability of the specifi-cations and to select appropriate testing strategies. Automation is achieved through the integrationof a number of constraint solving and theorem proving technologies. By using the same interme-diate notation, the techniques can be re-used across a number of source notations. The frameworkis illustrated in this paper by describing its application to the Statechart notation. In addition tothe use of non-Statechart specific testing techniques, this paper differs from others which discusstest generation from Statecharts in the testing methods used. For example, Bogdanov et al. [4]assume that transition operations are independently testable while Hong et al. [18] apply data flowanalysis to derive test sequences.

In sections 2 to 4 we show how specifications written in a subset of Statecharts can be for-malised, how testing heuristics can be formalised and how constraint solvers and theorem proverscan be used to generate the test case instances. Section 5 describes experience in applying thetechniques to realistic systems and the paper concludes with a summary of the key contributionsof the work, a discussion of further applications of the techniques and directions for future work.

2 Formalising Statechart transitions

A subset of the Statecharts [13] notation was adopted for the study that was sufficient to model theapplications of interest (aerospace control systems) yet restrictive enough to allow a straightfor-ward formalisation. The semantics of the subset were taken from Harel and Naamad’s definition[15] and are also implemented by the STATEMATE tool [14] which was used in the productionof the case study material. The example Statechart in Figure 1 is typical of those specified in thetarget domain and describes a portion of the software in an Electronic Engine Controller (EEC).The Statechart describes the cancellation of a thrust limiting mechanism following an inadvertentdeployment (e.g. due to a mechanical fault) of the engine thrust reverser doors.

Statecharts are an extension of finite state machines that include concurrency, state hierarchyand data. States in the system can be OR-states, AND-states or basic states. When an OR-stateis active, one and only one of its immediate sub-states is active (where the hierarchy is enforced

32

Page 43: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

through diagrammatic inclusion). The OR-states in Figure 1 are ThrustLimitation, LockDetect,AwaitLock and OnGroundDetect. AND-states are used to model concurrency and allow sets oftransitions to be simultaneously enabled. Whenever an AND-state is active, all of its immediatesub-states are active. InadvertentDeploy is the only AND-state in the example and its sub-states(LockDetect and OnGroundDetect) are partitioned using the dotted line. A basic state is a statewith no sub-states. The basic states of Figure 1 are Idle, Unstowed, Wait, Locked, InAir andOnGround.

At any point in time, a set of states in the Statechart is active, known as a configuration. Theset of valid configurations (VC ) is restricted by the semantic definition of OR and AND-states.Control is passed between configurations via transitions. Each transition is labeled with an eventexpression, a guarding condition and an action, each of which is optional. Event expressionsconsist of predicates defining the presence or absence of internal or external events. Guardingconditions are formed by predicates over input parameters and internal variables, which in thesubset discussed here may take boolean, integer or enumerated types. Actions consist of a combi-nation of event broadcast expressions and assignments to output parameters and internal variables.If more than one action is associated with a transition, all actions are considered to be taken si-multaneously. The syntax used for forming transition labels is as follows:

EventExpression [GuardCondition]/Actions

The semantics of a label can be described as follows:

EventExpr(I ;V ) ^ GuardCond(I ;V )) Action(I ;V ;V 0;O)

where I ;V ;V 0;O represent possible combinations of the individual input parameters, internal

variables, updated internal variables and output parameters respectively.1 EventExpr returns trueif the currently active input or internal events satisfy the event expression. GuardCond returnstrue if the present values of the input parameters and internal variables satisfy the guard condition.Action defines the relation between the input parameters, internal variables, updated internal vari-ables and the output parameters as defined in the transition actions. Each OR-state has a defaulttransition used to set the initially active sub-state on entry to the OR-state (unless the enteringtransition explicitly terminates at a sub-state). The default transitions of Figure 1 are T1, T4, T7and T9.

The computation that is performed by the Statechart is represented by a series of statuses and atrace of input and output parameters. A status consists of a set of currently active states, the set ofinternal events generated in the last computation step and the values of all internal variables. Thesynchronous time model was chosen for the subset and specifies that the system executes a singlestep every time unit, reacting to changes made in the status or to the parameters since the last step.The changes to the status caused by the transitions enabled by the current inputs are processed inthe next step along with the values of any input parameters that may have been altered during theexecution of the step.

The Statechart semantics impose constraints on the behaviour which are left implicit in thediagrams. However, in order to mechanically derive accurate and complete tests using generic testautomation techniques, this behaviour must be made explicit in any formal notation on which thetest generation techniques will be based. Generic tools can then be used that do not require anunderstanding of the semantics of the notation from which the formal specification was generated.For the subset of Statecharts under consideration, this implicit behaviour occurs in the followingfour situations.

1For example, I is defined as (I1�I2�: : :�In), where I1; : : : In represent the types of each of the input parameters.

33

Page 44: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� Transitions terminating at a non-basic state. If a transition terminates at a non-basic state,the transition is composed with the default transition of the target state. The composition iscontinued until a default transition terminates at a basic state. Example transitions of thiskind in Figure 1 are T2 and T5.

� Transitions originating from non-basic states. If a transition originating at a non-basicstate is active, then it must be possible to take the transition if any one of the sub-states of itssource state is enabled. The transition is partitioned such that each newly created transitionoriginates at a distinct basic state that is a descendent of the original transition’s source state.T6 is the only transition of this kind in Figure 1.

� Priority resolution mechanism. If two conflicting transitions are enabled simultaneously,the transition with the higher scope is given priority. The scope of a transition is definedas the lowest common OR-state that is an ancestor of all its source and target states. Theguard of the lower priority transition is updated by conjoining with it the negation of theguard of the higher priority transition. In the example, transition T3 would take priorityover transitions T6 and T10.

� Completeness assumption. The semantics of Statecharts specify that if a state is activeand no transitions are enabled in a step, events generated in the previous step are consumedand the active state is maintained. Additional transitions are added to explicitly define thisbehaviour.

Once the above semantic issues have been resolved, the resulting transitions are translated intoZ schemas using the following template:

StepTemplate

�Status

Parameters

SourceCon�guration � ActiveStates

EventExpression

GuardingCondition

Actions

TargetCon�guration � ActiveStates 0

Status is a schema used to store the currently active states (configuration), internal eventsgenerated in the last step and the values of internal variables. Status also contains an invariantthat ensures the set of active states conform with the semantics of the Statechart. Parameters isa schema defining the input and output parameters (as events or data-items). EventExpression,GuardingCondition and Actions are derived from the transition label elements, updated appropri-ately to resolve transition priorities. �Status is used to specify that the contents of the status areupdated by the operation and the “ ’ ” decoration is used to refer to the updated values of the status.Based on this template, the transition T3 would be specified as in Figure 2.2 Feasible combinationsof concurrently active transitions are represented by sets of transitions whose Z representations,when conjoined, do not conflict.

The automatic generation of the Z specification was acheived using an Application Program-ming Interface (API) to the STATEMATE tool. A program was written that extracts a model ofthe Statechart, performs the semantic resolution steps described above and writes out the full Zspecification including operations based on the step template. Several other variants of Statecharts

2where ? and ! are standard Z convention for labeling inputs and outputs respectively.

34

Page 45: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

T3

�Status

Parameters

fThrustLimitation; InadvertentDeploy ;

LockDetect ;OnGroundDetect ;AwaitLock ;

Lockedg � ActiveStates

ThrottleReq? � FwdIdle

RestowComplete! = Present

LimitThrust ! = False

fThrustLimitation; Idleg � ActiveStates 0

T3BVA1

�Status

Parameters

fThrustLimitation; InadvertentDeploy ;

LockDetect ;OnGroundDetect ;AwaitLock ;

Lockedg � ActiveStates

ThrottleReq? < FwdIdle � 1

ThrottleReq? � FwdIdle

RestowComplete! = Present

LimitThrust ! = False

fThrustLimitation; Idleg � ActiveStates 0

T3BVA2

�Status

Parameters

fThrustLimitation; InadvertentDeploy ;LockDetect ;OnGroundDetect ;AwaitLock ;

Lockedg � ActiveStates

ThrottleReq? = FwdIdle � 1

ThrottleReq? � FwdIdle

RestowComplete! = Present

LimitThrust ! = False

fThrustLimitation; Idleg � ActiveStates 0

T3BVA3

�Status

Parameters

fThrustLimitation; InadvertentDeploy ;LockDetect ;OnGroundDetect ;AwaitLock ;

Lockedg � ActiveStates

ThrottleReq? = FwdIdle

ThrottleReq? � FwdIdle

RestowComplete! = Present

LimitThrust ! = False

fThrustLimitation; Idleg � ActiveStates 0

Figure 2: Z specification for transition T3 and boundary value analysis partitions

(MATLAB/Stateflow [31], PFS Statecharts [11]) have been formalised in a similar way, as wellas a tabular notation (PFS tables [11]) used for specifying the reactive components of aerospacecontrol software. The same subset of Z was used to represent all of these notations. This allowedthe test generation toolset described in Section 4 to be re-used for all of the source notations.Predicates in the Z subset consist of combinations of logical, relational and arithmetic operatorsand the � operator used to constrain state configurations. The following sections now describetechniques that are not particular to Statecharts but have been developed for the subset of Z usedto model the above mentioned set of notations.

3 Formalising testing heuristics

3.1 Equivalence class testing

Testing techniques that have been developed for model-based notations such as Z (e.g. [1, 10, 30,17, 29]) are typically based on the principle of equivalence classes [12]. Equivalence classes areformed by partitioning the input domain into sets of data that, for testing purposes, exhibit thesame behaviour. Based on the uniformity hypothesis only one test point need be selected fromeach equivalence class to verify the implementation against the specification. In the methodology

35

Page 46: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

described here, equivalence classes are identified using testing heuristics. A partitioning heuristicpartitions the specification into equivalence classes that completely cover the input space of thespecification and can be based on the signature (variable type declarations) or predicate part of thespecification. Selecting data from each subdomain is then assumed to reveal a certain class of faultsin the implementation. A fault-based heuristic identifies an equivalence class in the specificationwhich contains those values that reveal a particular hypothesised fault.

Automatically applying testing heuristics to the specification requires a method of describingthe heuristics. In a high integrity process it should also be possible to demonstrate that the resultingtest cases accurately represent the testing heuristic and maintain conformance with the originalspecification. It may also be desirable to compare the various fault-finding abilities of differentheuristics (e.g. partitioning vs. fault-based heuristics) in order to optimise the set of heuristicsthat must be applied to each specification for a particular fault coverage. Formally specifying theheuristics allows all of these issues to be addressed.

3.2 Partitioning heurisitcs

Partitioning heuristics can be formally specified as follows, where the input space defined bypredicate P is partitioned into the subdomains P1; :::;Pn and Vars(P) represents the declarationsof all variables in the predicate to be partitioned:

8Vars(P) � P , P1 _ ::: _ Pn

A boundary value analysis partitioning heuristic based on the integer � operator could thereforebe defined as follows:

8A;B : Z � A � B , (A < B � 1) _ (A = B � 1) _ (A = B)

Applying this heuristic to the Z schema representation of transition T3 would result in the threetest cases shown in Figure 2, where the equivalence class defining each test case is highlighted andthe operands to the partitioned predicate (ThrottleReq? and FwdIdle) have been substituted forthe generic values A and B in the testing heuristic. If a partitioning heuristic can be shown,through proof, to be complete and result in disjoint sub-domains, test cases based on this templatewill inherit these properties. An automated method of applying the heuristics that guarantees thatthese properties is described in Section 4.1.

3.3 Fault-based heuristics

Fault-based (or mutation) testing can be an effective means of assessing other testing strategies,such as partition testing. A test set can be evaluated against a number of hypothesised faultsthat are considered representative of a large proportion of the actual faults likely to appear in theimplementation. The effectiveness of the target test set at detecting these faults is then used as ameasure of test effectiveness or completeness. Performing this evaluation using mutations of thespecification allows such an analysis to be performed much earlier in the life-cycle as it does notrely on the pre-existence of an implementation. Fault-based testing can also be an effective meansof generating the test set itself based on the intuition that if a test is adequate to detect a slightvariation in the correct behaviour, that part of the system is being exercised adequately [2]. Dueto the large number of potential mutations, this approach may lead to an infeasibly large numberof test cases. However, selective (program-based) mutation testing studies [23, 22, 25] suggestthat a relatively small number of mutations can lead to the detection of a large class of faults.Automation may allow significant examination of similar results applied to specification-basedmutants.

36

Page 47: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

If a fault in the implementation can reveal itself as a mutation of the sub-expression E to E0 inthe specification, then the necessary condition for detecting the fault can be generically describedas follows (based on a definition by Kuhn [24]):

9Vars(E ); Vars(E 0) � E 6= E0

Informally, there exists a set of values for the variables in E and E0 such that E and E

0

evaluate differently. Selecting values from this set will ensure that the fault reveals itself in theevaluation of the sub-expression. By allowing the sets Vars(E ) and Vars(E 0) to differ, the classof faults covered by variable replacement can also be modelled. If no values can be found tosatisfy the necessary condition, the fault does not reveal itself and can therefore be classed as anequivalent mutant. As an example, the following heuristic defines the fault condition for a variablereplacement mutation applied to an addition expression:

9A;B ;C : Z � A+ B 6= A+ C

This heuristic can be instantiated with variables from Figure 1 to detect a mutation of transitionT11 where Timer is incremented by itself rather than 1. The instantiation would result in thefollowing fault detection condition:

9Timer : Z � Timer + 1 6= Timer + Timer

Any number of such generic fault-based heuristics can be defined, limited only by the subset ofthe notation used to specify the system under test. A hypothesised fault can be shown to be weaklydetectable if the formalisation of the necessary condition can be shown to be a valid premise.That is, some values can be found that reduce the expression to true. The fault is said to be weaklydetectable because there is no guarantee that other expressions in the system will not mask the faultat the outputs. However, the probability of detecting the fault is strongly increased if the necessarycondition is satisfied. The manner in which faults in the implementation reveal themselves asmutations of the specification will depend on the refinement (between specification and code).Examination of this relationship may therefore point towards more testable implementations ofthe specifications. Fault-based heuristics can also be used to generate the abstract test cases in asimilar fashion to partitioning heuristics. The parameters are instantiated with the operands of theexpression containing the hypothesised fault. The resulting predicate then defines the equivalenceclass of the test.

The formulation of necessary fault detection conditions can be used to assess the fault de-tection ability of various partition and fault-based heuristics and therefore be used to identify anefficient set of heuristics for a particular subset of Z (based on the possible mutations of specifi-cations written in that subset). For example, a partitioning heuristic that results in the subdomains(P1; :::;Pn ) weakly detects the mutation of E to E 0 if:

(P1 ) :(E , E0)) _ ::: _ (Pn ) :(E , E

0))

The results of such an analysis applied to mutants of A _ B and the partitioning strategyA _ B , (A ^ B) _ (A ^ :B) _ (:A ^ B) are summarised in Table 1. The analysisdemonstrates that the partitioning strategy is not adequate to detect certain mutations that includeadditional or replaced expressions (C ).

In order to guarantee detection of a fault in situations where monitoring the evaluation of allsub-expressions in the implementation is not possible, the sufficient condition must be constructed.Whereas the necessary condition restricts the range of values of the variables to those that distin-guish between the original and mutated expression, the sufficient condition must restrict the valuesof the inputs to those that can distinguish between the original and mutated relation between the

37

Page 48: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Mutated form of A _ B Detected byA :A ^ B

B A ^ :B

A ^ B A ^ :B , :A ^ B

A XOR B A ^ B

:(A _ B) A ^ B , :A ^ B , A ^ :B

A _ C Not necessarily detectedC _ B Not necessarily detectedA _ B _ C Not necessarily detected (never by this heuristic)A _ B ^ C Not necessarily detected

Table 1: Effectiveness of the disjunction partitioning heuristic

controllable inputs and observable outputs. The sufficient condition is constructed using the fol-lowing pattern:

9 Inputs Outputs(P) � :(P , P 0)

where P denotes the original predicate part of the operation and P’ denotes the predicate part ofthe schema with the mutation applied and Inputs Outputs(P) represents the controllable inputsand observable outputs of P . If the sufficient condition can be satisfied, the fault is said to bestrongly detectable.

The number of possible solutions to the sufficient conditions can be used as a measure of howtestable an implementation is against faults that reveal themselves as mutations in the specification.The larger the number of solutions to the sufficient conditions, the higher the probability that oneof these solutions would be selected during standard (e.g. random or partition) testing procedures.The construction of sufficient test data may involve solving greatly more complicated constraintsthan for necessary conditions. Therefore in some cases, the use of necessary conditions may bepreferred as a trade-off between confidence in the test results and the effort required to generatethe test data.

The formulation of sufficient conditions for state-based systems is complicated by the factthat updated internal variables are typically not referenced until a later operation. Under thesecircumstances, the sufficient condition as presented above may not be satisfiable. Testing underthese conditions involves finding sequences of operations that are sufficient to detect mutations ofthe system state. This is the implicit assumption behind many of the the FSM-based test sequencegeneration techniques such as the W-Method [7] and the UIO method [28]. However, for ExtendedFinite State Machine (EFSM) based notations such as Statecharts, the system state may consist ofa combination of state (in the classic FSM definition of the term) and internal variables and events.A fault in the system state can be said to be strongly detectable in n steps if the sufficient conditionfor detecting the fault requires a sequence of no more than n operations.

4 Automatically generating tests

This section describes how a combination of techniques have been used to generate test casesand sequences from the subset of Z used to model the specifications of interest. The generationprocedure follows three steps. Partitioning and fault-based test cases are first generated from theZ specification using an automated theorem prover. If the specification includes a persistent stateand faults in the state are only strongly detectable in n-steps, an abstract finite state machine isconstructed from the test cases and used to derive checking sequences for equivalence classes

38

Page 49: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

of the system state that are not directly observable at the testing interface. A combination ofconstraint solvers is then used to populate the test cases and sequences with test data.

4.1 Applying testing heuristics

The formalised testing heuristics are automatically applied to the specification using the generalpurpose theorem prover CADiZ. CADiZ [32, 34] is a Z type checker and theorem prover that al-lows a user to interactively browse, type check and perform proofs upon a Z specification. CADiZalso allows proof tactics to be written in a lazy functional notation [33]. The tactic language in-cludes parameterisation and pattern matching facilities to enable generic tactics to be written forimplementing particular proof patterns. When such a tactic is applied, the parameters are instan-tiated with the currently selected parts of the specification (or typed input from the user). Genericproof tactics were used to automate the generation of test cases based on the formal specificationof the testing heuristic.

Testing heuristics are specified as named “lemmas” and stored in a separate Z file that isincluded within the scope of any specifications being tested. Completeness, disjointness and satis-fiability properties of these heuristics can be proven using the CADiZ interactive proof mode. Thecorresponding proofs can be recorded as proof tactics to be replayed at a later date (for example,by a new user who is as yet unconvinced of the heuristics’ validity). A proof tactic was writtenthat, given an expression in the specification and the name of a testing heuristic, instantiates thegeneric parameters of the chosen heuristic with the operands of the expression and conjoins theresult with the predicate part of the operation under test (this is a valid proof step if the heuristichas been previously proven to be a tautology). The result is then simplified to produce a newZ schema for each test case. Testing heuristics can be repeatedly applied in order to generate ahierarchy of test cases for an operation based on a number of different testing hypotheses. If all(hypothesised) faults are strongly detectable in 1 step, these test cases can be used to verify theimplementation against the set of testing hypotheses. Otherwise, the test cases must be sequencedto detect faults in the system state.

4.2 Test sequences

4.2.1 Constructing the abstract finite state machine

Dick and Faivre [10] proposed the construction of an abstract finite state machine (AFSM) asa means of sequencing test cases derived from and specified using the VDM-SL notation [21].Murray et al. [26] have since shown how the technique can be applied to Z specifications. Thesetechniques are extended here to include abstraction of the inputs and outputs and to apply stan-dard FSM-based test sequence generation techniques to the resulting AFSM. States in the AFSMcorrespond to the equivalence classes to be tested in the system state, identified using partitioningand fault-based heuristics, as described earlier in this paper. The operations in the specification areused to calculate the transitions between the abstract states by defining the transformation of thesystem state from one equivalence class to another. Particular equivalence classes in the systemstate can be indirectly tested by finding sequences through the AFSM that cover and check theabstract states corresponding to the equivalence classes of interest.

Assuming that the elements of Status are not controllable or observable in the testing envi-ronment, the abstract states for the specification described in Section 2 would be based on the preand postconditions in the test cases projected on to the elements of Status. The abstract states arecalculated by finding the minimal partition of these predicates. For any overlapping predicates,the minimal partition is calculated using the following partitioning strategy [10] (automated usingthe method described above):

A _ B , (A ^ B) _ (:A ^ B) _ (A ^ :B)

39

Page 50: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

As an example, the post-condition of transition T5 from Figure 1 (conjoined with T7 duringthe translation to Z) would result in the following equivalence class for Status :

AbstractStatenStatus

fThrustLimitation; InadvertentDeploy ;LockDetect ;

OnGroundDetect ;AwaitLock ;Lockedg � ActiveStates ^ Timer = 0

A similar abstraction is applied to each of the input and output parameters resulting in theset of disjoint combinations of the equivalence classes of the parameters. The AFSM is specifiedin terms of the abstract states, inputs and outputs using the following tuple and definitions. AnAFSM M is represented by the tuple (S ; s0;X ;Y ; Æ; �) where:

� S is the set of abstract states, where s0 is the initial state derived from the post-condition ofthe initialisation operation,

� X is the input language (minimal partition of the input predicates),

� Y is the output language (minimal partition of the output predicates),

� Æ is the non-deterministic state transfer relation, X � S $ S ,

� and � is the non-deterministic output relation, X � S $ Y .

The elements of the Æ relation are calculated by checking, for each combination of states Si

and Sj (including equivalent states) and input Xi , whether there exists an operation Op such thatthe following predicate is true:

Xi ^ Si ^ S 0

j^ Op

Similarly, the elements of the � function are calculated by checking, for each combination ofstate Si , input Xi and output Yi , whether there exists an operation Op such that the followingpredicate is true:

Xi ^ Si ^ Yi ^ Op

Two possible approaches to modeling concurrency in the models were considered. The simpleabstraction described above results in forming the product machine of any orthogonal components(such as InadvertentDeploy in Figure 1). However, this can lead to state explosion and greatlyreduces the efficiency of the test sequence generation techniques. Instead, concurrency is mod-elled using a system of communicating finite state machines. If references to shared state canbe assumed to be restricted to a single writer, multiple reader relationship, the communicationsbetween the components can be represented as references to the other component’s abstract state(constraints) in the pre-condition of the transitions. The definitions of Æ and � are updated asfollows:

� Æ = X � S � C1 � :::�Cn $ S

� � = X � S � C1 � :::� Cn $ Y

40

Page 51: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

for n orthogonal components where Cj represents the set of abstract states for each AFSM j

(i 6= j ) that are referenced in the pre-condition of the transition. Testing the system based on theset of testing hypotheses used in selecting the partitioning and fault-based heuristics reduces tocovering each abstract state and transition. In order to ensure strong detectability of faults in thesystem state, the value of the abstract state must be checked after the execution of each transition.

The derivation of the AFSM may introduce non-determinism. However, this will typically onlyapply to a subset of the state variables that are used to form the abstract state. Several approacheswere explored for resolving this non-determinism, including the use of a model checker (see be-low) for generating concrete feasible sequences based on those derived from the non-deterministicAFSM.

4.2.2 Generating test sequences

State checking sequences can be generated from the AFSMs using traditional FSM-based tech-niques [7, 28, 36]. The authors chose to use the Unique Input/Output (UIO) sequence algorithm[28]. The algorithm attempts to find, for each state, a sequence of inputs and outputs that is uniqueto that state. Such a sequence can then be used to distinguish that state from all others. UIO se-quences are generated for each AFSM separately. A sequence is said to be output distinguishablefrom another if the sequences produce different traces of outputs. The UIO sequence generationalgorithm is applied to each state si in turn and can be summarised as follows:

1. Set the length (l) of the current sequence to 1.

2. For all sequences of length l originating at state si check for output distinguishability againstall sequences that can be triggered by the same trace of inputs and constraints originatingat all states sj , where sj 6= si . If the sequence is output distinguishable against all thesesequences, it is the UIO sequence for state si .

3. If no output distinguishing sequence is found of length l , increase l by 1 and repeat steps2-3.

The use of shared outputs (more than one orthogonal component writes to the same output)complicates the calculation of output distinguishability as the output may have been produced bythe transition under examination or an orthogonal component in the system. Such shared outputscould be removed from the output abstraction and therefore not used in the calculation of distin-guishable transitions. However, this may result in no UIO sequences being generated for certaincomponents that wrote to only shared outputs. Therefore, the outputs are still used to generatethe UIO sequences and the SMV model checker (see below) was used to validate whether othercomponents could update the shared output at the same point in the sequence.

Model checking is a technique for verifying properties of state-based systems. A computationtree of a model of the system is enumerated and checked against a specification of the propertiesto be verified. If the model violates a property, a counter-example showing a sequence that leadsto a state that does not satisfy the property is generated. The ability to generate counter-examplesmakes model-checking a convenient means of generating test sequences from finite state machines.The finite state machine is defined as the model and the negation of the path constraint for thedesired test sequence is defined as a liveness property to be checked against the model [6]. Themodel checker will then attempt to find a counter-example to this property that corresponds toa test sequence satisfying the path constraint. Model checking also has the advantage that testsaccording to different criteria can be generated by simply varying the property to be checkedagainst the model. This results in a similar level of flexibility as the pattern-based operation testingtechniques described earlier.

41

Page 52: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

The model checker SMV [3] was used to explore the possiblities of model checking-based testsequence generation. Each AFSM is specified as a SMV module. A module consists of a numberof variables which are used to represent the inputs, outputs and state variables of the AFSM.The Æ and � functions are implemented as a pair of case statements over pairings of S and X .Each case statement defines the next value of S and Y respectively. The specification propertyplaces constraints on the abstract states, inputs and outputs. Test sequences can be generated byfinding counter-examples to the negated specification of the desired properties of the sequence.This approach to test sequence generation was found useful in generating initialisation sequences,validating UIO sequences (particularly dependencies between orthogonal components that maymake the sequence infeasible) and to generate sequences based on a partial specification of theordering of certain inputs, outputs or states. The SMV model was automatically generated basedon the same XML (eXtensible Markup Language) [8] specification of the AFSM as was used togenerate the UIO sequences (where the minimal partition of the inputs and outputs was calculatedautomatically). The generation of the XML specification from the Z specification is yet to beautomated but is considered feasible given an extension of the current tool set. XML is becomingincreasingly popular as a common interchange format for different modelling tools. Future workaims to capitalise on the standardisation of these interchange formats to extend the applicability ofthe toolset described here to a wider range of commercial modelling tools and notations.

4.3 Constraint solvers

A number of constraint solvers were used to generate the test data. The CADiZ built in constraintsolvers (a linear constraint solver, simulated annealing optimisation-based constraint solver andthe SMV model checker) were used wherever possible. In unit testing situations or for reactivecomponents where no test sequences were needed, the test data was generated directly from thetest case descriptions. This was achieved by writing a proof tactic that automatically selects theconstraint solver applicable to the particular constraint being solved. Using an API to CADiZ theprocess of generating test data for unit tests was automated by writing a program to apply the testdata generation tactic to each of the test case specifications in a particular Z file and write theresults out as an AdaTEST [20] test script. After some transformation of the resulting script toincorporate refinement, the script could then be run against the programs under test. In some casesa non-linear constraint solver was required, for these predicates, the stand-alone constraint solverLingo [19] was found to be very effective.

The test sequence generation techniques result in sequences of constraints over the inputs andoutputs described as sequences of abstract inputs and outputs. Where the concrete values were nottrivial to calculate, the same set of constraint solvers as described above were used to generate thetest data.

5 Results

The techniques described in this paper were evaluated as part of a case study to develop an EECsoftware application using model-based specifications. Z specifications were automatically gen-erated from approximately 100 pages of Statecharts, reactive tabular requirements and supportingtext. These were then used as the basis for automatically validating the completeness and deter-minism of the specifications (described in more detail in [5]). Tests were then generated fromthese validated specifications. Objectives of the case study included evaluating the efficiency ofthe automated test generation, assessing the testability of the specifications and evaluating theeffectiveness of standard testing heuristics.

The case study specifications consisted of 9 Statecharts (48 states, 112 transitions) and 34reactive specification tables. These were translated into 146 Z operation schemas from which 499

42

Page 53: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

test cases were generated using boundary value analysis and disjunction partitioning heuristics.These test cases were automatically populated with test data and converted into AdaTEST [20]test scripts to be run against the implementation as part of unit testing. This process was almostfully automated and the large majority of the effort involved selecting the testing heuristics toapply to each Z schema (a process that also has the potential for automation). The automaticgeneration of test sequences (for integration testing) was not as fully automated as the productionof unit tests and the XML specification of the AFSMs was produced by hand based from the Zspecification of the test cases. However, once this XML specification was written, the generationof UIO sequences and the SMV model was fully automatic.

For many of the Statecharts studied, no UIO sequences were found for at least one abstractstate. The length and feasibility of the test sequences were found to be a good measure of thetestability of the specifications. Factors that affected the testability of the Statecharts are thoughtto be a combination of ratios of the inputs and states to the outputs, corresponding to the domain torange ratio of the Æ and � functions of the AFSMs. The higher the ratios, the longer the sequencestended to be and the greater the probability that no sequences were found. The Statecharts usedin the case study were not designed with testability in mind and the information was useful indefining guidelines for future Statechart specifications and also justifying the expense of currentunit testing practices. Due to these limitations, integration testing was mainly limited to scenariostyle testing using sequences generated from the SMV model and use cases derived from thehigh level requirements of the system. Work is continuing to investigate the factors affecting thetestability of the specifications.

Part of the code was subjected to mutation analysis as a means of assessing the effectivenessof the partitioning heuristics used. The mutation adequacy of the test set ranged from 82.98% to91.3% based on different versions of the program. Two versions of the program were written byhand using alternative refinement patterns and three versions of the program were automaticallygenerated from the Z specification with varying levels of optimisation using an experimental tooldeveloped by other members of the research group. The fault detectability of the partitioningheuristics was also evaluated based on the formalised partitioning heuristics and fault detectionconditions (as described in Section 3.3). This analysis confirmed the empirical results and sug-gests that traditional decision coverage and MCDC coverage approaches to unit testing should beaugmented with additional tests for better fault coverage.

6 Conclusions and further work

This paper has described how tests can be automatically generated from Statechart specificationsusing an intermediate formal representation and a formal approach to specifying testing heuristics.The toolset is applicable to a number of graphical and tabular notations due to the common inter-mediate formal notation and makes use of theorem provers and constraint solvers to generate thetests. The use of graphical and tabular notations is intended as a means of bridging the gap betweenspecialist domain engineers and formal methods. Therefore, future work will investigate how theautomated Z-based testing techniques described in this paper can be presented to the engineersin a way such that the flexibility (in terms of testing heuristics) of the methods are maintained,while not requiring the engineers to work directly with the Z representation of the specifications.This work may include the specification, and subsequent automatic translation to Z, of testingheuristics in similarly intuitive notations to Statecharts and the presentation of the results of thetest generation process using similar notations (e.g. test sequences could be presented as messagesequence charts).

Formalising both the specifications and the testing heuristics facilitated a high degree of au-tomation and a rigorous method of analysing the testability of the specifications and the compar-ative fault finding abilities of different testing heuristics. Section 5 discussed how the techniques

43

Page 54: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

were applied to an industrially relevant case study. The techniques resulted in not only the largescale automation of test cases and (to a lesser extent) sequences but also the identification of factorsthat affect the testability of Statechart specifications and highlighted the shortcomings of severalcommonly used testing heuristics. The formal definition of the the testing heuristics and fault de-tection conditions also allowed this latter analysis to be performed formally as well as empirically.Ongoing work is looking to generate conditions that will enhance the range of faults detected bythese heuristics and investigate in more detail the factors affecting the testability of Statecharts.

UIO sequences can only be used to detect operation and state transfer faults. The detectionof additional states in the implementation cannot be gauranteed. Therefore as part of future work,alternative approaches, such as the W-method should be investigated. Furthermore, a better under-standing of how faults in the implementation can reveal themselves as mutations of specificationand the relationship of this mapping to the method of refinement into code will provide a moreinformed choice as to which testing methods are most suitable for a particular application.

Future work also aims to better integrate the different areas of automation, in particular, ex-tending the range of integrated constraint solvers to handle non-linear constraints and automatingthe generation of the abstract finite state machine from the formal specification of the test cases.The applicability of the techniques to a wider range of graphical notations (such as SDL and UML)and other application domains is also under consideration.

7 Acknowledgements

This work was funded by the High Integrity Systems and Software Centre, Rolls-Royce Plc.

References

[1] Nina Amla and Paul Ammann. Using Z specifications in category partition testing. Proceed-ing of COMPASS 1992, Seventh Annual Conference On Computer Assurance, pages 3–10,1992.

[2] P. Ammann, P. Black, and W. Majurski. Using model checking to generate tests from speci-cations. December 1998.

[3] Sergey Berezin. The SMV web site. http://www.cs.cmu.edu/ modelcheck/smv.html/, 2000.The latest version of SMV and its documentation may be downloaded from this site.

[4] K. Bogdanov, M. Holcombe, and H. Singh. Automated test set generation for statecharts. InProceedings International Workshop on Current Trends in Applied Formal Methods, 1998.

[5] Simon Burton, John Clark, Andy Galloway, and John McDermid. Automated V&V for highintegrity systems, a targeted formal methods approach. In Proceedings of the 5th NASALangley Formal Methods Workshop, June 2000.

[6] J. Callahan, F. Schneider, and S. Easterbrook. Automated software testing using modelchecking. In Proceedings 1996 SPIN Workshop, August 1996. Also WVU Technical ReportNASA-IVV-96-022.

[7] Tsun S Chow. Testing software design modeled by finite-state machines. IEEE TransactionsOn Software Engineering, SE-4(3):178–187, May 1978.

[8] World Wide Web Consortium. eXtensible Markup Language. http://w3c.org/XML/.

[9] Rational Cooperation. Unified modeling language. Rational Software Cooperation. UnifiedModeling Language. Available at http://www.rational.com, 1999.

44

Page 55: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[10] J. Dick and A. Faivre. Automating the generation and sequencing of test cases from model-based specifications. FME’93:Industrial Strength Formal Methods. LCNS 670, pages 268–284, April 1993.

[11] Andy Galloway, Trevor Cockram, and John McDermid. Experiences with the applicationof discrete formal methods to the development of engine control software. Proceedings ofDCCS ’98. IFAC, 1998.

[12] John B. Goodenough and Susan L. Gerhart. Towards a theory of test data selection. IEEETransactions On Software Engineering, 1(2):156–173, June 1975.

[13] David Harel. Statecharts: A visual formalism for complex systems. Science of ComputerProgramming, 8:231–274, 1987.

[14] David Harel, Hagi Lachover, Amnon Naamad, Amir Pnueli, , Michael Politi, Rivi Sherman,Aharon Shtull-Truaring, and Mark Trakhenbrot. Statemate, a working environment for thedevelopment of complex reactive systems. IEEE Transactions On Software Engineering,16:403–414, 1988.

[15] David Harel and Amnon Naamad. The Statemate semantics of statecharts. IEEE Transac-tions On Software Engineering And Methodology, 5(4):293–33, Oct 1996.

[16] Kathryn L. Heninger. Specifying software requirements for complex systems: New tech-niques and their applications. IEEE Transactions on Software Engineering, 6(1), 1980.

[17] R. M. Hierons. Testing from a finite state machine: Extending invertibility to sequences. TheComputer Journal, 40(4):220–230, 1997.

[18] Hyong Seok Hong, Young Gon Him, Sun Deok Cha, Doo Hwan Bae, and Hasan Ural. Atest sequence selection method for statecharts. Software testing, verification and reliability,10:203–227, 2000.

[19] LINDO Systems Inc. Lingo. http://www.lindo.com, 2001.

[20] Information Processing Ltd., Bath, UK. AdaTEST 95 User Manual, June 1997.

[21] The International Organization for Standardization. Information technology – Programminglanguages, their environments and system software interfaces – Vienna Development Method– Specification Language – Part 1: Base language. International Standard ISO/IEC 13817-1,December 1996.

[22] J.Offut, A.Lee, G. Rothermel, R.H. Untch, and C. Zapf. An experimental determinationof sufficient mutant operators. ACM Transactions on software engineering methodology,5(2):99–118, April 1996.

[23] J.Offut, G. Rothermel, and C. Zapf. An experimental evaluation of selective mutation. Pro-ceedings of the 15th International Conference on Software Engineering, pages 100–107,May 1993.

[24] D. Richard Kuhn. Fault classes and error detection capability of specification-based testing.ACM Transactions on Software Engineering and Methodology, 8(4):411–424, October 1999.

[25] E.S. Mresa and L. Bottaci. Efficiency of mutation operators and selective mutation strategies:an empirical study. The Journal of Software Testing, Verification and Reliability, 9(4):205–232, December 1999.

45

Page 56: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[26] L. Murray, D. Carrington, I. MacColl, J. McDonald, and P. Strooper. Formal derivation of fi-nite state machines for class testing. Technical Report 98-03, Software Verification ResearchCentre, School of Information Technology, The University of Queensland, Brisbane 4072,Australia, February 1998.

[27] Martyn Ould. Testing - a challenge to method and tool developers. Software EngineeringJournal, 39:59–64, March 1991.

[28] Krishan Sabnani and Anton Dahbura. A protocol test generation procedure. Computer Net-works And ISDN Systems, 15:285–297, 1988.

[29] Harbhajan Singh, Mirko Conrad, Gottfried Egger, and Sadegh Sadeghipour. Test case de-sign based on Z and the classification-tree method. First IEEE International Conference onFormal Engineering Methods, November 1997.

[30] Phil Stocks and David Carrington. Test template framework: A specification-based casestudy. Proceedings Of The International Symposium On Software Testing And Analysis (IS-STA’93), pages 11–18, 1993.

[31] The MathWorks. Stateflow. http://www.mathworks.com/products/stateflow/.

[32] Ian Toyn. Formal reasoning in the Z notation using CADiZ. 2nd International Workshop onUser Interface Design for Theorem Proving Systems, July 1996.

[33] Ian Toyn. A tactic language for reasoning about Z specifications. In Proceedings of the ThirdNorthern Formal Methods Workshop, Ilkley, UK, September 1998.

[34] Ian Toyn. The CADiZ web site. http://www.cs.york.ac.uk/ ian/cadiz/, 2000. The latestversion of CADiZ and its documentation may be downloaded from this site.

[35] International Specifications Union. Itu-t recommendations Z.100, specification and descrip-tion language, 1994.

[36] Hasan Ural. Formal methods for test sequence generation. Computer Communications,15(5):311–325, June 1992.

46

Page 57: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Classical search strategies for test case generation

with Constraint Logic Programming�

Alexander Pretschner

Institut f�ur Informatik, Technische Universit�at M�unchen, Germany

www4.in.tum.de/~pretschn

Abstract

Test case generation for concurrent reactive systems on the grounds of symbolic execution

basically amounts to searching their state space. As in the case of model checkers, di�erent

search strategies (depth-�rst, breadth-�rst, best-�rst, tabu) together with di�erent strategies

for storing visited states have a signi�cant impact on the performance of the generation

algorithm. We present experimental data for the performance of di�erent search strategies

and discuss the results, taking into account counter examples as generated by model checkers.

Keywords. CASE, Model Checking, State Representations, Symbolic Execution.

1 Introduction

Usually, errors in early software development design phases result in disproportionately high costs

if they have to be corrected. This is due to the increasing number of implications of each design

decision: the earlier a decision is made, the more implications it involves.

One commonly accepted solution to this problem is an incremental approach to software/

hardware development. The idea is to get possibly executable pieces of software (or models

of hardware) in early phases that can be used for validation by interacting with a respective

customer, and for veri�cation w.r.t. given speci�cations (properties).

The focus of this paper is on reactive (embedded) systems, and we thus concentrate on behavior

models. In order to get executable behavior models of such a system, a suitable high-level,

preferably graphical, speci�cation formalism is needed. Finite state machines have been identi�ed

as a practically usable candidate. With adequate CASE tools, systems can be built, simulated,

and veri�ed. Simulation not only helps the developer in understanding the system and detecting

errors, but can also be used for customer interaction (validation). Veri�cation and validation

are usually achieved by testing, e.g., checking if, given a certain input, the system's output

corresponds to the desired one.

Testing is, however, incomplete. Besides semi-automatic proof systems, model checkers aim at

guaranteeing that the system satis�es a certain property. Basically, they exhaustively search the

system's state space. This necessarily requires �nite state spaces (e.g., SMV or SPIN) or built-in

abstractions (e.g., Uppaal or HyTech for a restricted class of hybrid systems). The problem with

state space explosion is obvious.

Along side these practical considerations, the concept of model checkers is such that they focus

on verifying properties of models. Not only in the area of embedded systems the system model is

just one step in the development process: the system has to be implemented after the speci�cation

(or model, respectively) has been validated. The implementation process may introduce errors

that have to be detected. One instance of conformance testing amounts to showing that the

behaviors of the implementation constitute a subset of the behaviors of the speci�cation.

With this article, we continue a series of papers [21, 22, 26, 27, 28, 29] on model based test

case generation for reactive systems speci�ed with the CASE tool AutoFocus. The idea is to

use the system model (a network of hierarchic components with associated behaviors) for the

�Supported by the DLR (project MOBASIS) and the DFG (project KONDISK/IMMA; ref.no. Be 1055/7-2).

47

Page 58: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

generation of test cases that later on, are fed into the actual implementation (hardware). Note

that test cases can also be used for validating the system model itself, but this induces the lack

of an instance that decides whether or not the behavior as exhibited by the test case is a correct

one{when testing the implementation, the model plays the role of this instance.

Our tool prototype takes an AutoFocus system description, translates it into Constraint

Logic Programming (CLP) and symbolically executes the resulting system. This sometimes

involves, however, a guessing procedure for the next transition to be taken. It is this guessing

procedure that makes up the di�erence between search strategies such as breadth-�rst, depth-

�rst, or best-�rst. In this paper, we re-examine an example from earlier work, apply di�erent

search strategies for the test case generation procedure, and compare them quantitatively.

Its contribution consists of a number of statistics that indicate the superiority of best-�rst

search. If no suitable �tness function can be de�ned, random depth-�rst search with global state

storage when deployed in a competitive parallel setting is a good choice. Furthermore, the paper

discusses some conceptual di�erences between search strategies for model checkers with strategies

for test case generation.

Related work. Incremental SW development processes include the Rapid Prototyping, the

spiral (meta) model, Extreme Programming/Modeling [3, 4], and, more geared towards reactive

systems, the Cleanroom Reference model (CRM, [30]). The bene�t of models is particularly

acknowledged in the Rational Uni�ed Process [20] and the CRM. The embedding of model based

testing in incremental processes is discussed in [27]. A theory of formal testing is tackled in [16, 5].

They share the commonality of de�ning an observational congruence (\selection hypotheses") on

systems. Similar relations are used in [32, 31] to compute whether or not a system (model)

conforms to its speci�cation. We di�er from this approach in that we do not want to prove such a

conformance relation but rather approximate its proof as done in traditional testing. (Constraint)

Logic Programming for test case generation has been used in [24, 7, 23]; our approach di�ers

(1) in the class of systems we consider, (2) in the input language with a concept of interface

and a combined approach to behavior speci�cations with automata and functional de�nitions

on transitions, and (3) in the thereby induced necessity for powerful constraint handlers on the

grounds of Constraint Handling Rules (CHR, [15]). Lutess [12] is a tool for the generation of test

cases for Lustre (as is Gatel [23], see above). The di�erence with our approach is the use of model

checkers or random number generators for the generation of test cases as well as a restriction to

boolean data types.

Code generation on the grounds of CLP is, for various non-modular [25] automata considered

in [17, 14]. The relationship of Model Checking and (C)LP with possibly tabled resolution

procedures is discussed (and used) in [10, 13, 9]. Bounded Model Checking with propositional

solvers for test case generation is considered in [33].

Test case generation on the grounds of mutation analysis is, among others, treated in [2]. In

the context of mutation testing, constraints for the generation of test cases for transformational

systems are used in [11]. The idea is to formulate constraints that approximate criteria for killing

mutants.

[6] uses a mixture of BDDs and Presburger constraints for the representation of sets of states

in reactive systems. [1] uses linear constraints on real numbers for model checking hybrid systems.

Clearly, the focus is on model checking. The di�erence with our approach is that (1) we are mixing

enumerative and symbolic techniques rather than computing �xed points on sets of constraints

and (2), again, use CHR with constraint solvers on arbitrary domains (e.g., FD) for allowing

convenient interactions and user-de�ned speci�cations of test cases.

Overview. The remainder of this paper is organized as follows. In the next section, we give

a brief overview of the speci�cation concepts of the CASE tool AutoFocus and introduce an

example, taken from [28], that is used for assessing the di�erent search strategies: a smart card

for inhouse access control.

In the main part of this paper, in Section 3, we then present our approach to test case

generation on the grounds of CLP. Several search strategies and state storage algorithms are

discussed and assessed. We also examine the relationship between search strategies for test case

48

Page 59: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

generation and for model checking. Section 4 concludes with an outlook on current and future

work.

We assume familiarity with the basic concepts of CLP, �nite state machines, and those of

depth-�rst, breadth-�rst, and best-�rst search strategies.

Terminology. The terminology in this paper is that of [22]. A test sequence is a sequence of

input/output event tuples. A test case describes a set of test sequences by imposing constraints

on unbound variables in the I/O tuples. A test case speci�cation is the formalization of a test

purpose (e.g., \ensure coverage criterion C"); the aim of test case generation is to �nd test

cases/sequences that satisfy a certain test case speci�cation. Note that this may include the test

of \unspeci�ed" parts of the system's behavior.

2 AutoFocus

In this section, we brie y present the modeling concepts of the CASE tool AutoFocus (http://

autofocus.in.tum.de, [18]) and present an example from earlier work that we will use as a basis

for the generation of test cases with CLP.

AutoFocus. Similar to the UML-RT, systems are modularly speci�ed by di�erent views. The

architectural view shows the system structure that consists of possibly hierarchic components

interconnected by typed and directed channels. Typing is achieved by prede�ned or user-de�ned

data types; possibly recursive types are de�ned by means of a Gofer-like functional language.

The bottom level component of each hierarchic component is equipped with an extended �nite

state machine, and each such machine can access the component's local variables. Transitions are

equipped with a guard that accesses local variables as well as, by means of pattern matching, input

channels of the respective component. The language of guards is the same functional language as

mentioned above; it is thus possible not only to de�ne functionality by means of state machines

but also by means of possibly recursive functions. If the guard holds true, the transition may

�re, resulting in an update of the component's local variables as well as the change of the current

control state. Initial states are marked with a black dot; there is no such thing as an acceptance

condition. If more than one transition can �re, one is selected non-deterministically; if none can,

the system idles, i.e., remains in its current state.

Components are timed by a global clock, and they all perform their computations (�ring

transitions) simultaneously. Communication is synchronous (asynchronous communication is im-

plemented by explicit bu�er components).

In addition to the architecture, behavior, and data view, AutoFocus makes use of sequence

charts. Even though we do not consider them further here, they play an important role in the

development process: for speci�cation, de�nition of test cases, and for the graphical representation

of simulation results.

AutoFocus is equipped with code generators for Java, C, Prolog, and ADA. Furthermore, it

is connected to a plethora of external tools. These include model checkers such as SMV or �cke

as well as the propositional solver SATO, ATTOL/UnitTest for coverage measurements of test

cases for generated ADA code, and DOORS for requirements tracing.

Example. Our example is the model of a smart card that may be used for inhouse access.

After inserting the card and a personal identi�cation number (PIN) into a terminal, the terminal

may or may not, according to the rights a user owns, grant access to a particular door. This

involves running authentication/identi�cation protocols between card and terminal. A PIN may

be blocked if the authentication process fails several times, and it can be unblocked if a corre-

sponding personal unblocking key (PUK) is being entered. This example is part of an industrial

case study we carried out in order to assess practical applicability of our tool prototype, and it

is discussed in more detail in [28].

The card part of the system we consider consists of a single component that accepts commands

on the input channel. These commands are provided by the terminal, and they include commands

for authentication/identi�cation, reading/writing data on the card, etc. The output is a signal

49

Page 60: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Reset

any possible command

AuthA

AuthB

AuthA

AuthA

AuthA

AuthA

AuthA

AuthB AuthB

AuthB

AuthB

AuthB

noAuth1noAuth4

((AS == GotChallange) && (K4C > 0)):read?MutAuth_F:OK!Present:K4C = (K4C - 1); AS = Ready

any possible command

any possible commandany possible command

any possible command

any possible command

any possible command

noAuth2noAuth5

noAuth3

AuthCh

noAuthCh(K6C > 0):read?Verify_Ch:OK!Present:K6C = (K6C - 1)

MF0

DF00 Init

DF01 Admin DF02 User

DF03 User

DF04 Admin

DF05 User

SelectB

ResetResetReset

Reset

Reset

Reset

Auth3Key4 Auth1Key1

PIN1Key2

PIN2Key5PUKKey4

Auth3 Auth1Auth3

Auth3

Auth3

Auth1

Auth1

Auth1

Auth2Key3

SelectB

SelectB

SelectB

SelectB

SelectB

Figure 1: Inhouse Card [28]

that signi�es whether or not the input command is a legal one. Its behavior is depicted in Fig. 1.

Roughly speaking, the di�erent states correspond to di�erent access right levels to several parts

of the card's data. The state is changed by an adequate authentication process. If this process

fails, the respective counter (one for each state except for MF00) is decremented by one, and the

card is locked if one of the counters reaches zero. By providing the corresponding PUK, it can

be unlocked.

The test cases we will consider concern those that drive the card, for di�erent counters, into

the corresponding locked state. cnt6 is the counter associated with state DF04Admin with initial

value 15; cnt4 is the counter associated with state DF00Init with initial value 14. The diÆculty

in �nding a sequence that decrements cnt4 to zero lies in the fact that between two decrements,

a well-de�ned sequence of three transitions needs to be executed.

Note that this example contains a control state that is encoded by an internal variable. It

stores the current status of the authentication process (three possible values). This re ects the

experience that �nite state machines alone quickly become too complicated.

3 Test case generation with CLP

In this section we �rst describe our algorithm for the computation of test cases based on symbolic

execution with CLP. As mentioned before, this approach amounts to searching the system's state

space. In our implementation, the part of the program that is concerned with implementing

the search strategy is held rather orthogonal from its rest. We can thus modify the search

50

Page 61: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

strategy without altering the rest of the code that is automatically generated from anAutoFocus

speci�cation. A user interface for specifying the search strategy to be employed is the subject of

current work; thus far, a strategy with interleaved choice of transitions is generated automatically

(see below).

After the description of the principal ideas, we discuss and assess several search strategies:

(1) bounded depth �rst with (1a) naive left-right choice of transitions, (1b) interleaved choice,

(1c) global and (1d) local state storage, and (1e) best-�rst choice of transitions. We also brie y

discuss (2) breadth �rst search. In addition, we take into account the possibility of storing sets

of states by means of constraints.

Code generation for CLP is presented in more detail in [21]; interleaving transitions in our

setting has �rst been described in [27]. The use of constraints is described in [22]; the advantages

of using constraints are more thoroughly discussed in [26].

(Constraint) Logic Programming. In Logic Programming, problems are speci�ed as sets of

�rst order predicates (disjunctions with at most one positive literal|implications). Common LP

languages such as Prolog then interpret (\solve") these predicates in a procedural manner (reso-

lution); backtracking mechanisms are built-in. In our context, the possibility of function inversion

plays a crucial role: Under certain circumstances, given the result of a function application, one

can infer the function's arguments (or a set of them). This is achieved by binding free variables

and backtracking until these desired arguments are found.

However, there are some pitfalls in LP. On the one hand, solutions of programs (models of

logical formulae) are always based on the same carrier set, a term universe (the so-called minimal

Herbrand model). On the other hand, in implementations of LP languages, there is a certain

order in which predicates are evaluated (in the procedural sense, see above) which may result in

in�nite evaluations even though the succeeding predicate could prevent in�nite backtracking by

imposing constraints that its preceding predicate can only satisfy in a �nite number of ways. This

led to the idea of merging Constraint Languages with LP into Constraint Logic Programming

(CLP) languages [19]. These languages allow for the formulation of constraints that are checked

for satis�ability in every step of the evaluation of a set of logical formulae (expansion of a node

in the resolution tree), and they hence necessitate mechanisms for delaying subexpressions. This

yields the possibility of a priori cutting the evaluation tree of these formulae; the \generate and

test" paradigm of LP languages is modi�ed to \constrain and generate". On the other hand,

with CLP, one can calculate in domains other than the Herbrand universe, for instance �nite

(integer) domains FD, or rational or real numbers Q and R (one crucial point in the latter two

domains is to calculate on �nitely representable intervals.) One can, for instance, formulate Linear

Programming Problems with a set of unknown variables, and if the CLP language is equipped with

suitable constraint solvers (e.g., Simplex), the desired optimal results can be found by binding

variables to the corresponding rational numbers or intervals. LP is an instance of CLP with

constraints being equations over terms, or �nite trees, respectively.

Even though there are many constraint solvers available, it turned out that sometimes people

do not want to calculate on one speci�c domain but rather a mixture of di�erent domains, and

that there sometimes is a need to create new domains and constraint handlers. This led to

the development of Constraint Handling Rules (CHR [15]), a meta language that allows for the

de�nition of new constraint handlers (solvers) that, subsequently, can be translated into the

corresponding target language, CLP in our case.

Idea. Test case generation is achieved by running CLP code automatically generated from spec-

i�cations. Since CLP allows for unbound variables as arguments, we run an ordinary simulation,

but we do not specify inputs at all moments of time. In fact, by not restricting the system at all,

we get an enumeration of all possible system traces.

Each bottom level component (components with associated behaviors) is translated into a

set of predicates each of which models one particular transition. The predicates' heads include

thus not only source and destination states as well as the name of the transition, but also formal

parameters for histories of local variables, and for those input and output channels that are

connected to the component.

51

Page 62: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Bottom level components (or rather the predicates that implement them) are run by a driver

predicate that corresponds to the component that contains those bottom level components. Chan-

nels between components are modeled by local variables (existential quanti�cation). This simple

translation scheme can be applied recursively, and the driver predicates thus re ect the hierarchy

of AutoFocus components.

In terms of function and data type de�nitions used for guards and postconditions, they are

translated into constraint handlers or Prolog code and integrated into the model [21, 22].

As mentioned above, test case generation is done by simulating the system w.r.t. constraints

as imposed by the test case speci�cation. These constraints may refer to structural{such as

\all transitions should be �red at least once" or \all control states are to be visited once"{or

functional criteria (such as \�nd a trace that makes output o1 happen and then output o2" or

\�nd a trace that includes input i and exhibits nothing but outputs from a set O"). These

constraints are formulated by appropriate constraint handlers for Booleans or enumerative types

(�nite domains). In practice, this is, however, not enough for an adequate formalization of

test purposes. User-de�ned constraint handlers based on Constraint Handling Rules [15] are a

powerful tool for specifying test cases with prede�ned as well as user-de�ned constraint handlers,

and they are integrated into our system.

While the possibility of a-priori-pruning the search tree is one advantage of using constraints,

we consider the possibility of restricting the model to be the key to scalability: Often, designers

know that for a particular functional test case, certain parts of the model are irrelevant; constraints

allow to ad-hoc slice the model without actually altering it [26]. This also leaves room for

techniques widely used in program analysis.

A further advantage of using constraints is that they allow for reducing the number of traces.

As an example, consider a transition with a guard i(t) = c1 _ i(t) = c2 _ : : : _ i(t) = cn for input

channel i at time t and commands cj (elements of a data type \Command"). In a naive attening

Prolog translation of this fragment, n transitions need to be tried: i has to be bound to each cj .

Using constraints, we are happy with one single member constraint: fi(t) 2S

n

j=1cjg.

In this way, a computed test case may represent a set of test sequences (those with i(t) 2Sn

j=1cj which might have been strengthened in the further computation). When testing the actual

implementation, we need fully instantiated traces; how to perform this instantiation intelligently

is, however, not the focus of this paper.

Naive !. The simplest possible search strategy is a naive left-right-choice of transitions. As

stated above, transitions are encoded by predicates that contain, among other things, the source

and the destination state of a transition in their head. Choosing a transition can then be left to

the evaluation mechanism of CLP: the transition predicate that occurs �rst is tried �rst, then the

second, and so on. However, this approach is rather ineÆcient for it (1) revisits states that have

been visited before and (2) is likely to run into cycles (see below).

Interleaving. In previous papers [27, 26], we have described our implementation based on a

bounded depth-�rst search with an interleaved choice of transitions. This means that when a state

is revisited, its outgoing transitions are not tried in exactly the same order as before; the list of

transitions is rather shifted by one. If Trs;i =< T1; T2; : : : ; Tn > is the sequence of transitions that

are tried in that order from state s for the ith time, then Trs;i+1 =< T2; T3; : : : ; Tn; T1 > is the

respective sequence when s is visited the i+1st time. This simple mechanism, though imposing a

little overhead, usually results in signi�cant performance gains in terms of time since it decreases

the likelihood of running into (control state) loops (Fig. 2 (a); with a naive left-to-right choice of

transitions, the dashed ones are never taken.)

Storing states globally. One problem with naive bounded depth-�rst search is that states

may be visited more than once. A state here refers to the cross product of tuples of data and

control states for each component (one in the case of our example; the role of I/O as well as

internal communication channels is discussed below). The obvious solution is to store each state

once it has been visited. However, there is a price to pay: With this approach, the maximum

52

Page 63: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

(a) (b) (c) (d)

Figure 2: Search strategies

depth of the search tree becomes more important. In Fig. 2 (b), the black state that makes a trace

satisfy the corresponding test case speci�cation, is not reached (the horizontal line indicates the

maximum depth). The reason is that the dashed transition is not taken for its destination state

has already been visited and thus stored, indicating that it is not to be considered for further

search. This is even though the black state could, on backtracking, be reached in fewer steps than

the maximum depth. Note that for testing purposes, it is not even always desirable to exclude

states from being visited twice; this re ects the strange kind of errors where something goes well

n times, but not n+ 1.

Storing states locally. This motivates another search strategy. States are prevented from

being revisited only when the depth at the moment of their storage is below the depth of the

new visit (Fig. 2 (c) where the right transition from the initial state may be taken even though

the corresponding destination state has already been visited). The problem with this approach is

that it necessitates the storage of a large number of additional states; its bene�t is that it usually

allows for detecting shorter traces than the ones detected by strategies that store states globally.

However, for our examples of decremented counters, no performance gains could be achieved.

Since the number of possible traces increases with this local storage algorithm, the performance

is rather signi�cantly reduced.

Note that for structural test purposes such as \�nd a transition tour" the approach of storing

states is not applicable. In Fig. 2 (d) the dashed transitions result in unsuccessful traces since

the initial state has already been visited. A transition tour cannot be computed in this way. Also

note that it depends on both the test case speci�cation and the system whether or not the stored

states need to include information about input and output channels.

Storing sets of states. The use of CLP enables one to store sets of states by simply storing

the constraints that describe this set. Deciding whether or not a stored state entails a potentially

reachable one is then crucial for deciding whether or not the respective transition needs to be

taken. This issue is the subject of future work; [10] contains a discussion in the setting of deductive

model checking with CLP.

To illustrate the idea, we consider a naive �rst implementation. Rather than storing each state

s = (ctl ; auth stat ; c1; : : : ; c6) (control state, data state for authentication process, six counters)

separately, we look if there is already a stored state s0 that di�ers from s in exactly one component.

Say that the di�erence occurs in the control component, i.e., s0 = (ctl 0; auth stat ; c1; : : : ; c6) with

ctl 0 6= ctl . We now delete s from the database and replace it by (fctl ; ctl 0g; auth stat ; c1; : : : ; c6).

If later on, we run into a state s00 which again, di�ers from s and s

0 in nothing but the �rst

component, we delete the corresponding entry from the database and replace it by (fctl ; ctl 0; ctl 00g,auth stat ; c1; : : : ; c6), and so on. Doing so for all components, this simple strategy results in a

reduced need for memory: all components of the vectors except for the �rst just need to be stored

just once.

Since storing sets of states is not the central issue of this paper, we do not go into further

detail here. Two remarks are, however, in order. It is easy to see how the simple strategy can

be made more powerful: Rather than restricting the search for already visited states to one

component, we could look for the projection onto two or even more of them and update the

database accordingly. This does require some further intelligence though: While di�erent entries

in the database correspond to a disjunction of states, the components of a state vector correspond

to conjunctions: Consider a stored vector (fctl1 ; ctl2 ; ctl3g; auth stat ; c1; : : : ; c6) and a newly

53

Page 64: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

SP = sorted shortestPaths(s)

forall p 2 SP

Tp[1] = trans(p[1 ]; p[2 ])

for i = 1 ::kSPk

if SP [i] 6= p then Tp[1] = Tp[1] Æ trans(p[1 ]; (SP [i ])[1 ])

return

Sp2SP

Tp[1]

Figure 3: Transition ordering for best-�rst

visited state (ctl1 ; auth stat0; c1; : : : ; c6) with auth stat

0 6= auth stat . Clearly, we cannot simply

coalesce both entries into (fctl1 ; ctl2 ; ctl3g; fauth stat ; auth stat0g; c1; : : : ; c6). We can, on the

other hand, combine sets of states when it is sound to do so, but this requires eÆcient comparisons

of sets of sets with the above mentioned suitable de�nition of entailment|obviously, we are

looking for generalizations of Binary Decision Diagrams to domains other than the Booleans.

The second remark aims in the same direction. We will later see how an implementation of the

above idea does indeed result in considerable reduction of allocated memory. This implementation

stores states in the above mentioned manner but does not use them for the computation of traces

itself. This would enable one to compute with sets of states rather than single states, something

that is referred to as the \collecting semantics" in the literature on abstract interpretation (e.g.,

[8]). Knowledge of this computed collecting semantics may turn out to be a good starting point

for the de�nition of an abstract semantics that can, in turn, be used for an actual abstract

interpretation.

Best-�rst. As we will undermine quantitatively in the following, the ordering in which tran-

sitions from a given (control) state are taken is crucial for the performance of the test case

generation. This issue becomes increasingly important when there are many transitions from

that state. In some cases, it is possible to de�ne a �tness function that w.r.t. a test case speci-

�cation computes the (approximately) best transition to be taken. In the case of control states

to be reached or transitions to be taken, this �tness function is comparatively easy to de�ne:

From each control state c 2 S, we compute the shortest path pc to reach the desired destination

state s. We then implement a best-�rst search by de�ning the transition ordering for state c as

follows. Transitions that connect c with the second state in pc are tried �rst. For the remaining

transitions emanating from c, we choose those that lead to a state d satisfying the requirement

that there is no d0 where the length of pd0 is strictly shorter than that of pd.

Iterating this procedure leads to a transition ordering that �rst tries transitions from c that

are on pc. It then tries those transitions that lead to states with minimum shortest paths to s,

then those that lead to states with the second minimum paths, etc. This algorithm works because

each subpath of an optimal path is itself optimal.

More formally, in Fig. 3, SP with length kSPk is the sequence of shortest paths (sequences

of control states) from all states s0 2 S to s. It is assumed to be sorted with the shortest

path occurring �rst (this could be the path from s to itself; thus modeling the idle transition).

Furthermore, it does not contain duplicates. For a sequence q, q[i] denotes the ith element of

q, and for sequences p; q; p Æ q denotes their concatenation. Tp[i] is the transition sequence that

should be taken in this order when state p[i] is to be left. trans(s1; s2) returns a sequence of all

transitions from s1 to s2 in arbitrary order. The existence of idle transitions prevents trans from

returning the empty sequence in Fig. 3. Note that if there is no path from a state to s, it does not

occur as the �rst element of a sequence in SP . This implies that transitions that lead to states

that cannot reach s are (safely) ignored.

In our example, we are interested in optimal orderings w.r.t. reaching state DF00Init for

decrementing cnt4 , and to reaching DF04Admin in order to decrement cnt6 . This is because

transition noAuth4 is responsible for decrementing cnt4 , and transition noAuthCH is responsible

for decrementing cnt6 . We thus use the algorithm for reaching states as one that is capable of

�nding good transition orderings for reaching transitions; as a further step, we move transitions

noAuth4 and noAuthCH in front of the respective transition sequences.

Note that this simple heuristics is, in general, applicable only to control states for the number

of data states may be too large. When the system contains data states, it is only a heuristic.

54

Page 65: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Table 1: cnt6 ! 0

cmax states time mem [MB] len/succ

30 i 1982 14.8 3.0 30

! 3348 36.1 3.5 {

r 934-2424-4160 3.9-23.7-457.3 2.6-3.1-3.8 1/10

bf 21 0.0 2.1 21

40 i 1442 8.3 2.8 40

! 7137 157.6 5.0 {

r 2149-5239-8399 18.0-91.3-209.5 3.0-4.2-5.4 4/10

bf 21 0.0 2.1 21

50 i 1375 7.9 2.7 50

n 10520 316.2 6.3 50

r 1884-8183-14626 13.7-236.3-596.4 4.4-6.2-7.8 7/10

bf 21 0.0 2.1 21

100 i 4789 65.7 4.1 100

! 1346 7.7 2.7 100

r 731-7860-15571 2.8-233-595.8 2.5-5.2-8.2 10/10

bf 21 0.0 2.1 21

150 i 197 0.2 2.3 150

! 1528 9.2 2.8 150

r 446-7866-26714 1.2-285.8-1552.4 2.3-4.9-12.3 10/10

bf 21 0.0 2.1 21

200 i 518 1.2 2.4 200

! 1468 8.6 2.8 200

r 3426-21279-62565 39.7-1542.6-6821 3.4-10.3-21.3 10/10

bf 21 0.0 2.1 21

250 i 535 0.7 2.4 250

! 2704 26.6 3.3 250

r 359-13977-43397 0.4-744.6-3304.4 2.2-7.5-18.8 10/10

bf 21 0.0 2.1 21

500 i 1518 4.6 2.8 281

! 705 1.1 2.5 500

r 5171-43030-115563 65.6-5289.2-20452.1 4.1-20.5-46.5 10/10

bf 21 0.0 2.1 21

1000 i 1884 6.9 2.9 281

! 900 0.9 2.6 739

bf 21 0.0 2.1 21

This is the case in our example.

Breadth-�rst. The desire to get the shortest possible traces makes breadth-�rst search come

into the game for it guarantees traces of minimum length. However, breadth �rst search severely

su�ers from memory explosion (at least if we do not employ symbolic representations such as

BDDs). For the sake of a smaller memory allocation, we did not store the traces in the experiment.

It is noteworthy that the architecture of our system does not necessitate the implementation of

a naive meta interpreter (as usually done in breadth-�rst implementations in Prolog).

Experiments. We now give some experimental data, measured on a Pentium III with 850MHz

and 256MB of memory. The CLP implementation we use is Eclipse (www.icparc.ic.ac.uk/

eclipse) As mentioned above, we consider two functional test case speci�cations, namely decre-

ment counters cnt4 and cnt6 . Since a naive interleaving strategy without storing states as well

as the strategy with local state storage resulted in prohibitive amounts of time needed, we omit

mentioning the respective numbers here.

Concerning the test case that decrements cnt6 to zero, Tab. 1 summarizes resource allocation

for a strategy with globally storing states for interleaving (i), naive left-to-right (!), random

55

Page 66: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Table 2: cnt4 ! 0

cmax states time [s] mem [MB] len/succ

300 i 986 2.0 2.6 300

! 13138 420.2 7.3 300

r 326-21488-56444 0.3-2146-7600.3 2.2-10.3-23.8 10/10

bf 43 0.0 2.1 44

400 i 512 0.6 2.4 325

! 34715 3284.6 15.4 400

r 328-1319-6286 0.3-10.9-86.0 2.3-2.7-4.6 10/10

bf 43 0.0 2.1 44

500 i 512 0.5 2.4 325

! 22251 1386.4 10.7 500

r 445-892-3397 0.5-3.5-27.4 2.4-2.6-3.5 10/10

bf 43 0.0 2.1 44

1000 i 512 0.5 2.4 325

! 1188 1.8 2.7 846

r 383-604-1176 0.4-782-2120 2.4-2.4-2.7 10/10

bf 43 0.0 2.1 44

(r) and best-�rst (bf) choice of transitions. For random choice, ten simulations have been run;

the respective entries consist of min-mean-max triples. The �rst column shows the number of

(globally) stored states, the second the time needed to �nd the �rst sequence satisfying the test

case speci�cation, the third the required memory (including 2.1MB required for the runtime

system and the code), and the fourth the length of the respective trace (or, in the case of random

choice, the number of runs that led to a successful trace). Since we consider bounded depth-�rst

search in this case, we give data for several values of the maximum depth, cmax . Tab.2 contains

the respective data for cnt4 .

Tab. 3 contains some data on breadth-�rst-search. Since the considered test cases lead to

sequences longer than the maximum depth of 12, we just show the cumulative amounts of time

and memory needed to proceed up to the speci�ed depth.

In conjunction with breadth-�rst search, an implementation of the above mentioned simple

approach to storing sets of states allows us, under the given resources, to enumerate states up

to a depth of 14 rather than 12 (for a depth of 15, the virtual memory of 750MB gets again

exhausted).

The last experiment we conducted consisted of manually slicing the model by prohibiting the

system of �ring those transitions that lead to decrements of the other four counters. This is

done by means of constraints rather than by altering the model itself. The results are almost

identical to those of best-�rst-search. However, the approach of imposing additional constraints

is, in a sense, more general than using a best-�rst search: It may not always be possible to de�ne

a suitable �tness function. Slicing by constraints does, on the other hand, necessitate detailed

knowledge of the system under consideration. We also used the approach of interactive slicing in

the original study [28].

Discussion. As mentioned above, local state storage increases performance, but in our exam-

ples, the necessary resources still were too high as to consider this strategy a serious candidate.

Its advantage lies is in potentially detecting shorter sequences.

Not surprisingly, breadth-�rst search results in an explosion of memory requirements. It is,

however, a serious candidate for deductive model checking when storing sets of states by means

of constraints together with approximation procedures as proposed in [10] are taken into account.

The experiments with depth-�rst search with global storage exhibit the commonality of �nding

rather long sequences (which is usual for depth-�rst search). As suspected, the choice of the

ordering of transitions is crucial w.r.t. performance of the algorithms. This becomes evident with

the results on random choice of transitions where the minimum and maximum performance in

terms of time di�ers as much as four orders of magnitude. Storing states may lead to unsuccessful

56

Page 67: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Table 3: Enumerating states

depth time [s] mem [KB]

6 0.0 57

7 0.2 160

8 0.7 529

9 2.3 1,879

10 8.9 6,870

11 33.7 23,476

12 127.8 86,792

13 >600 >750,000

runs for a given maximum search depth even though in principle, the test case speci�cation could

be satis�ed by a trace shorter than this maximum depth.

According great importance to the transition ordering is consistent with the data on best-�rst

search. This strategy is able to compute short sequences with negligible overhead. In fact, it was

able to compute traces of minimum length; regardless of of cmax , resource allocation remained

constant. A simpler version of the �tness function that simply consists of always trying transitions

noAuth4 or noAuthCH, respectively, �rst, and not caring about the ordering of the remaining

transitions, leads to sequences that are a little longer, but can be found with comparable resources.

It is likely, however, that this �nding does not generalize when systems with more control states

are to be tested. In fact, if a second version [28] of the model that replaces a data state by a

set of additional control states (for the authentication protocols) is used for test case generation,

the di�erences between the two �tness functions result in performance gains of one order of

magnitude for the �tness function that is based on shortest paths. Furthermore, the automaton

in this paper is heavily interconnected which explains why depth-�rst search with interleaving

comparably eÆciently produces traces for large maximum depths. In these cases, the larger the

maximum depth, the more likely it is to quickly �nd a trace. In [27] we noticed that the choice

of cmax has an important in uence on the performance. Good heuristics for �nding suitable

maximum depths remain to be found.

An interleaving choice of transitions is usually preferable to an arbitrary �xed ordering; the

advantage becomes negligible with growing cmax . This is due to the nature of depth-�rst search

in highly interconnected graphs when augmented by a strategy that stores states.

With these �ndings, the numbers for random choice of transitions with a stunningly high stan-

dard deviation are easily explained. In the optimal cases (minimum requirements), the random

choice is such that it is favorable for �nding the particular test sequence.

These results suggests that if it is easy to de�ne a �tness function, one should consider using

a best-�rst strategy. If it is not, one should instead try a random choice of transitions (states

globally stored) and perform several computations simultaneously. An additional process should

use an interleaving choice. The �rst process to terminate successfully then kills the others.

In our examples, that multiplies the minimum requirements by 11 (plus a little overhead for

process scheduling), but this seems to be reasonable when taking into account the rather small

requirements for the optimal solutions.

Finally, while our example is not a concurrent one, the encoding into CLP that keeps di�erent

components separate, is likely to assure that the results also hold in a concurrent setting. This

claim remains to be veri�ed; we are planning a new study with smart card systems that can best

be modeled by concurrent components.

Model Checking. The resemblance of many issues discussed in this paper with model checking

is eye-catching. This is for several reasons. Firstly, using the capability of model checkers to

produce counterexamples for test case generation is an old idea. In fact, at least when they are

reasonably short, they are used for localizing errors in speci�cations. Second, the problem of

identifying a suitable search strategy does constitute large parts of work done in areas such as

non-symbolic on-the- y model checkers like SPIN. Thirdly, and maybe less obviously, the main

57

Page 68: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

problem consists of computing (approximations of) �xed points or subsets thereof. We will brie y

address these issues in the remainder of this section.

Model checkers, at least without built-in abstraction capabilities as found in Uppaal or

HyTech, are inherently restricted to small �nite systems. A CLP based approach to test case gen-

eration like ours is not. This is because we explicitly construct parts of the state space on-the- y

rather than �rst constructing and then computing �xed points on it as done in symbolic checkers.

Constraints{in a sense, a generalization of boolean formulae encoding transition relations and

encoded by BDDs{are useful in at least two ways. Firstly, they allow for storing possibly in�nite

sets of states (see also [10, 13], the latter of which notes that the boundary between traditional

model checkers and CLP systems has become blurry, as in the case of HyTech). Secondly, power-

ful self-de�ned constraint handlers like CHRs can be used for interactively slicing the model [26].

Again, we consider this a key to scalability of our approach.

The problem of �nding suitable search strategies is very similar in non-symbolic model check-

ing. In fact, as bounded depth-�rst search has become an option in available tools, our approach

is not really di�erent. At least conceptually, there is a slight di�erence between model checking

and generating test cases for the latter always tries to �nd a witness. Model checkers usually aim

at proving a property of an entire system. This di�erence allows us to adopt the search strategy

w.r.t. a given test case speci�cation (note that this is also principally possible for on-the- y model

checkers, but this requires exact knowledge of the respective search algorithm). It is noteworthy

that in testing, one is mainly interested in existentially path-quanti�ed properties. The approach

of �rst generating the entire state space may thus not be the prime solution in this context.

Again, the use of constraints can help in storing possibly in�nite sets of states which, in con-

junction with a suitable concept of entailment, may lead to more powerful search strategies. This

claim remains to be veri�ed empirically. Note that partial reduction, as used in SPIN, is unlikely

to yield performance gains for AutoFocus systems are inherently synchronous. However, we

consider it interesting to apply partial reduction to test case generation for discretized mixed

discrete-continuous (or hybrid) systems.

Finally, CLP with suitable memoing techniques can be used directly for model checking [9, 10].

Results from the area of deductive databases (e.g., bottom-up evaluation with magic templates)

may prove powerful also for model checking reactive systems. The idea is to generate �xed points

or approximations thereof in a bottom-up manner. This results in deductive model checking

procedures for possibly in�nite systems (by means of widening/narrowing operators). While thus

far we have concentrated on test case generation, our existing infrastructure directly provides

an experimentation platform for deductive model checking (e.g., with the post-� calculus and

appropriate query logics).

To summarize, model checking and test case generation (on the grounds of CLP) are di�erent

w.r.t. their purpose, and it seems reasonable to advocate a complementary use of them. While

they are quite similar in terms of problems related to search strategies, the use of constraints may

prove a powerful tool to handle complex systems.

4 Conclusion

We have presented experimental data for several search strategies implemented in our CLP-based

tool prototype for generating test cases from AutoFocus system speci�cations. An example

from an earlier feasibility study was used to identify circumstances under which certain strategies

are likely to perform better than others. Furthermore, we have discussed the relationship of

model checking with our approach that is based on symbolic execution with constraints. The

main di�erences are grounded on the handling of in�nite (or large) state spaces as well as the

opportunity of using constraints to naturally slice models (without actually having to alter them).

There is a plethora of future work to be done in this area. The need for research in the area

of good �tness functions for di�erent system topologies and/or properties to be tested is obvious.

In addition, we consider eÆcient strategies for storing sets of states as a prerequisite for handling

very large systems, too. In the following, we pick some additional aspects from a recent position

paper [26].

One issue is the use of our approach to generating test cases for mixed discrete-continuous

58

Page 69: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

systems [29]. Storing sets of states as well as partial order reduction techniques seem promising

candidates to successfully tackle this particularly diÆcult class of systems.

The exact relationship between a set of test cases and the system to be tested is not entirely

clear. Rather than de�ning a congruence on traces and use this congruence to generate tests, we

generate tests and are interested in how they relate to the system (or speci�cation) to be tested.

This is likely to result in the de�nition of a suitable approximation order on �nite state machines

(classical notions of re�nement/abstraction with chaos completion pose problems when lifting

traces to systems and being concerned with resulting input-enabled nondeterministic systems;

the role of idling{or Æ [32]{transitions makes such systems diÆcult to embed in a re�nement

context).

In addition, suitable input languages for test case speci�cations are needed. One might con-

sider message or live sequence charts, but they would require an intuitive notation for and se-

mantics of negation.

The problem of �nding good heuristics for instantiating test cases into test sequences has been

mentioned above. For numeric values, one can use limit analyses, e.g., instantiating an interval

to three single values.

This example also leads to a notion of \bad test cases". Experience shows that speci�cations

are incomplete (while a simulation semantics, in particular with idle transitions, suggests com-

pleteness), and that errors tend to occur where designers forgot to specify some special cases

(e.g., a missing else-branch in an if-statement). Test case generators should be able to compute

test cases that test these cases; this is related to (a) the role of idle transitions and (b) the def-

inition of suitable coverage metrics. For state machines with functional de�nitions as allowed in

AutoFocus, such metrics do not, to the author's knowledge, even exist.

Furthermore, generating large sets of test cases to satisfy some coverage metrics only makes

sense if the generated test cases on the level of models can be lifted to the implementation

level (i.e., generated code, or hand-written code when generators produce inadequate code) by

maintaining the respective coverage criterion. On the implementation level, such test cases are

used by certi�cation authorities to verify conformance with a given standard (e.g., DO-178B for

aircraft).

With a component-oriented speci�cation language, we consider a compositional approach to

test case generation promising: Generating test cases for (simple) components and combining

them into test cases for larger systems. The problem is that a test case for one component may

(and often will) be a forbidden behavior of the composed system.

Finally, a model-based development process and automatic test case generation needs to pay

o�. Some of our industrial partners in the area of safety-critical systems seriously consider

implementing such a process which will provide an opportunity to assess bene�ts and problems.

Acknowledgment. The tool prototype is developed together with Heiko L�otzbeyer whose con-

tributions are gratefully acknowledged. Oscar Slotosch built the original model [28].

References

[1] R. Alur, C. Courcoubetis, N. Halbwachs, T. Henzinger, P. Ho, X. Nicollin, A. Olivero, J. Sifakis, andS. Yovine. The algorithmic analysis of hybrid systems. Theoretical Computer Science, 138(1):3{34,February 1995.

[2] P. Ammann and P. Black. Test Generation and Recognition with Formal Methods. In Proc. 1st Intl.

workshop on Automated Program Analysis, Testing, and Veri�cation (WAPATV'00), pages 64{67,2000.

[3] K. Beck. Extreme Programming Explained: Embrace Change. Addison Wesley, 1999.[4] M. Boger, T. Baier, F. Wienberg, and W. Lamersdorf. Extreme modeling. In Proc. Extreme

Programming and Flexible Processes in SW Engineering (XP'00), 2000.[5] E. Brinksma. A theory for the derivation of tests. In Proc. 8th Intl. Conf. on Protocol Speci�cation,

Testing, and Veri�cation, pages 63{74, 1988.[6] T. Bultan. Automated symbolic analysis of reactive systems. PhD thesis, University of Maryland,

1998.[7] A. Ciarlini and T. Fr�uhwirth. Using Constraint Logic Programming for Software Validation. In 5th

workshop on the German-Brazilian Bilateral Programme for Scienti�c and Technological Coopera-

tion, K�onigswinter, Germany, March 1999.

59

Page 70: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[8] P. Cousot and R. Cousot. Abstract Interpretation: a uni�ed lattice model for static analysis ofprograms by construction or approximation of �xpoints. In Proc. 4th ACM symp. on Principles of

Programming Languages (POPL'77), pages 238{252, 1977.[9] B. Cui, Y. Dong, X. Du, K. Narayan Kumar, C. Ramakrishnan, I. Ramakrishnan, A. Roychoudhury,

S. Smolka, and D. Warren. Logic programming and model checking. In Proc. PLILP/ALP, SpringerLNCS 1490, pages 1{20, 1998.

[10] G. Delzanno and A. Podelski. Model Checking in CLP. In Proc. Tools and Algorithms for Con-

struction and Analysis of Systems (TACAS'99), pages 223{239, 1999.[11] R. DeMillo and A. O�utt. Constraint-Based Automatic Test Data Generation. IEEE Transactions

on Software Engineering, 17(9):900{910, 1991.[12] L. du Bousquet and N. Zuanon. An overview of lutess, a speci�cation-based tool for testing syn-

chronous software. In Proc. 14th IEEE Intl. Conf. on Automated SW Engineering, October 1999.[13] L. Fribourg. Constraint logic programming applied to model checking. In Proc. 9th Int. Workshop

on Logic-based Program Synthesis and Transformation (LOPSTR'99), LNCS 1817, Venice, 1999.Springer Verlag.

[14] L. Fribourg and M. Veloso-Peixoto. Automates Concurrents �a Contraintes. Technique et Science

Informatiques, 13(6):837{866, 1994.[15] T. Fr�uhwirth. Constraint Handling Rules. In Constraint Programming: Basics and Trends (LNCS

910), pages 90{107. Springer Verlag, 1995.[16] M. Gaudel. Testing can be formal, too. In Proc. Intl. Conf. on Theory and Practice of Software

Development (TAPSOFT'95), LNCS 915, pages 82{96, Aarhus, Denmark, May 1995.[17] G. Gupta and E. Pontelli. A Constraint-based Approach to Speci�cation and Veri�cation of Real-

time Systems. In Proc. IEEE Real-time Symposium, pages 230{239, San Francisco, December 1997.[18] F. Huber, B. Sch�atz, and G. Einert. Consistent Graphical Speci�cation of Distributed Systems. In

Industrial Applications and Strengthened Foundations of Formal Methods (FME'97), LNCS 1313,pages 122{141. Springer Verlag, 1997.

[19] J. Ja�ar and M. Maher. Constraint Logic Programming: A Survey. J. Logic Programming, 20:503{581, 1994.

[20] P. Kruchten. The Rational Uni�ed Process - An Introduction. Addison Wesley, 2000.[21] H. L�otzbeyer and A. Pretschner. AutoFocus on Constraint Logic Programming. In Proc. (Constraint)

Logic Programming and Software Engineering (LPSE'2000), London, July 2000.[22] H. L�otzbeyer and A. Pretschner. Testing Concurrent Reactive Systems with Constraint Logic Pro-

gramming. In Proc. 2nd workshop on Rule-Based Constraint Reasoning and Programming, Singa-pore, September 2000.

[23] B. Marre and A. Arnould. Test Sequence Generation from Lustre Descriptions: GATEL. In Proc.

15th IEEE Intl. Conf on Automated Software Engineering (ASE'00), Grenoble, 2000.[24] C. Meudec. ATGen: Automatic Test Data Generation using Constraint Logic Programming and

Symbolic Execution. In Proc. 1st Intl. workshop on Automated Program Analysis, Testing, and

Veri�cation, Limerick, 2000.[25] O. M�uller and T. Stauner. Modelling and veri�cation using Linear Hybrid Automata. Mathematical

Computer Modeling of Dynamical Systems, 6(1), March 2000.[26] A. Pretschner and H. L�otzbeyer. Model Based Testing with Constraint Logic Programming: First

Results and Challenges. In 2nd ICSE Intl. Workshop on Automated Program Analysis, Testing, and

Veri�cation (WAPATV'01), May 2001. To appear.[27] A. Pretschner, H. L�otzbeyer, and J. Philipps. Model Based Testing in Evolutionary Software De-

velopment. In Proc. 11th IEEE Intl. Workshop on Rapid System Prototyping (RSP'01), June 2001.To appear.

[28] A. Pretschner, O. Slotosch, H. L�otzbeyer, E. Aiglstorfer, and S. Kriebel. Model Based Testing forReal: The Inhouse Card Case Study, 2001. Submitted to FMICS'2001.

[29] A. Pretschner, O. Slotosch, and T. Stauner. Developing Correct Safety Critical, Hybrid, EmbeddedSystems. In Proc. New Information Processing Techniques for Military Systems, Istanbul, October2000. NATO Research and Technology Organization.

[30] S. Prowell, C. Trammell, R. Linger, and J. Poore. Cleanroom Software Engineering. Addison Wesley,1999.

[31] V. Rusu, L. du Bousquet, and T. J�eron. An Approach to Symbolic Test Generation. In Proc.

Integrated Formal Methods, 2000.[32] J. Tretmans. Test generation with inputs, outputs and repetitive quiescence. Software{Concepts

and Tools, 17(3):103{120, 1996.[33] G. Wimmel, H. L�otzbeyer, A. Pretschner, and O. Slotosch. Speci�cation Based Test Sequence

Generation with Propositional Logic. J. Software Testing, Validation, and Reliability, 10(4):229{248, 2000.

60

Page 71: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Towards Formal Test Purposes

Rene G. de Vries and Jan Tretmans ∗

University of TwenteFormal Methods and Tools group, Department of Computer Science

P.O. Box 217, 7500 AE Enschede, The Netherlands{rdevries, tretmans}@cs.utwente.nl

Abstract

This paper proposes a framework to formalize test purposes. It introduces the notionof exhibition and the concept of observation objectives. Observation objectives are relatedto test purposes, and are used for test selection. The framework gives means for reasoningabout observation objectives, test suites and test results based on observation objectives. Weinstantiate the presented framework with the ioco conformance test theory and present analgorithm to derive an e-complete and sound test suite. Finally, we discuss some ideas on howto put observation objectives into practice.

1 Introduction

In this paper we consider conformance testing of reactive systems. A reactive system is a systemthat interacts with its environment by accepting inputs and producing outputs. Conformancetesting is the activity of checking whether a system is correctly implemented according to its func-tional specification. Such a specification typically prescribes the interactions between the systemand its environment. Testing performance, robustness, etc., although important, are outside ourscope.

Testing consists of doing experiments with a system in a controlled way. Where the systemnormally interacts with its environment, the tester now pretends it is the environment. The testerstimulates and observes the system. The experiment carried out by the tester is defined by a testscenario, often referred to as a test case. Conformance testing involves black box testing, i.e.,testing without knowing the internals of the system. We can only interact with the system byusing the available, external interfaces.

Testing is laborious, error-prone and expensive, hence it is preferably automated as far as pos-sible. This concerns both the generation of tests from a specification and the subsequent executionof these tests. Automation of test generation is only feasible if the specification is amenable toautomatic processing by a test generation tool. This implies that it should be expressed in someformal language. Many theories have been developed for automatic derivation of tests from formalspecifications, e.g., [LY96, Tre96].

A problem with automatic test generation is that it may result in large and unstructured testsuites. Test generation algorithms can produce large, or even infinite numbers of test cases. Theresult is that the execution of such a test suite is not feasible within reasonable time limits – oreven impossible, when it is infinite. Moreover, the relation between a test case and the specificationrequirement that it tests, i.e., its test purpose, gets lost. To overcome this problem we have toreduce the test suite by making a selection from the set of all possibly generated tests. Moreover,for each selected test its purpose should be clear. We refer to this activity as test selection.

∗This research was supported by the Dutch Technology Foundation STW under project STW TIF.4111: Cotede Resyste – COnformance TEsting of REactive SYSTEms.

61

Page 72: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Test selection can be done at random, but the purpose of a randomly selected test casewill be difficult to establish. The random approach is the one currently taken in the test toolTorX [BFV+99]. A second approach is having criteria or heuristics added to the test generationalgorithm so that it produces only a subset of all possible tests. A third approach to test selectionis to have a test person specifying criteria, strategies or objectives to steer the generation of tests.Examples of such criteria are a particular coverage to be reached by the generated tests, or someparticular behaviour, in terms of sequences of inputs and outputs of the system under test, thata test person would like to see during the testing process. This approach is taken in the test toolsTGV [JM99] and Autolink [SEK+98]; the test tool user has to specify a test purpose which is asequence of possible interactions, for which the tools then derive a corresponding test case. Inthis paper we will pursue this third approach, and we refer to such criteria, strategies, purposesor objectives as observation objectives.

Observation objectives are very much related to test purposes. Different descriptions of whata test purpose is exist, both informally and formally. In the formal framework [ISO96] a testpurpose is a set of models of implementations (P ⊆ MODS). In the informal setting of [ISO91]a test purpose is a prose description of the goal of what is being tested by a particular test case,referring to a particular conformance requirement. Other uses of the concept of a test purposeinclude automata [JM99], traces [SEK+98] or syntactic restrictions on a specification [Hol99]. In[DRS+00], which uses test purposes in the automata sense of TGV [JM99], it is concluded that aprecise notion of a test purpose on the theoretical and methodological level is needed.

In this paper we propose such a precise notion of a test purpose. We try to formalize testpurposes in the vein of [ISO96] and consistent with their use in tools like TGV and Autolink.Since, to our opinion, the word test purpose is already overloaded with many different meanings,we use the term observation objective instead.

The first point, when using observation objectives to steer the test generation process, is thatwe need a formal way of specifying an observation objective. By the nature of our black box testingapproach, we can only make observations of the interactions of a system with its environment.Hence, the observations that we can make during testing will form the basis for defining anobservation objective. Secondly, we need a clear and precise notion of how an observation objectiveis related to a test suite. This will be the basis to decide whether a particular test case will beselected. Thirdly, we must know how to interpret the results of test execution with respect toan observation objective, i.e., there must be a notion of satisfying, or reaching, an observationobjective. The formal elaboration of these concepts in Section 3 constitutes the main part of thispaper.

It is important to note the difference between conformance and observation objectives. Confor-mance expresses the notion of formal correctness: if during testing any non-conforming behaviouris observed, then this is sufficient to reject the implementation. It is a decision about correctnessbased on purely formal arguments. On the other hand, an observation objective describes desiredbehaviour which we wish to observe but which is not directly related to required behaviour orcorrectness. If this desired behaviour is actually observed then it may contribute to increasedconfidence in the implementation’s correctness. If the observations described in the observationobjective are not actually observed then no definite conclusion can be based solely on this informa-tion. Additional information from outside the realm of formal reasoning is necessary to interpreta missed observation objective.

Consider as an example a coffee machine which is specified to produce coffee after a coin hasbeen inserted, but which, e.g., due to lack of cups, may also respond with a red light after acoin has been inserted. An example of an observation objective is that a test person wishes to seecoffee being supplied after a coin has been inserted. If after several test runs the machine each timeresponds with the red light this observation objective is certainly not satisfied. However, there isalso no reason to declare the machine non-conforming since the red light response constitutes validbehaviour according to the specification. In the terminology of [ISO91] this test would get theverdict inconclusive. The decision whether this implementation is acceptable, is outside the formaldomain. It depends on the context, the test person and/or future users whether a machine whichhas never exhibited the ability to supply coffee can be put into operation. On the other hand,

62

Page 73: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

suppose the coffee machine would produce tea after insertion of the coin then a formal argumentsuffices to decide that the machine is non-conforming and should be rejected. In Section 3 we willformally elaborate this orthogonality between conformance and observation objectives. We willsee that the coffee machine above passes the test but misses the observation objective.

As the basis for the formalization of observation objectives we take the framework FormalMethods in Conformance Testing [ISO96] and related frameworks [Tre99]. Section 2 recalls themain concepts of them. Then Section 3 presents the formalization of observation objectives as anextension of this framework. The concepts of exhibiting and revealing an observation objective,hitting an observation objective by a test case, the objective verdicts hit andmiss and the relationbetween conforming and revealing implementations are discussed. Subsequently, we instantiatethese concepts within the ioco-based, transition system conformance test theory of [Tre96]. First,Section 4 recalls the basics of this theory. Then Section 5 develops ioco-based observation objec-tives and ioco-based exhibition. This leads to a test derivation algorithm which derives, from agiven specification and an observation objective, an ioco-sound test case with the ability to hitthat observation objective. Finally, Section 6 gives some concluding remarks, including a briefdiscussion about putting the observation objective ideas into practice.

2 Formal Framework for Testing

This section presents the formal framework for conformance testing [BAL+90, ISO96, Tre99] whichforms the basis for the formalization of observation objectives in the next section. The presentationin this section is taken from [Tre99]. The presented framework can be used for testing of animplementation with respect to a formal specification of its functional behaviour. It introduces,at a high level of abstraction, the concepts used in a formal conformance testing process and itdefines a structure which allows to reason about testing in a formal way. The most importantpart of this is to link the informal world of implementations, tests and experiments with theformal world of specifications and models. To this extent the framework introduces the conceptsof conformance, i.e., functional correctness, testing, observations, sound and exhaustive test suites,and test derivation.

Conformance For talking about conformance we need implementations and specifications. Thespecifications are formal, so a universe of formal specifications denoted SPECS is assumed. Im-plementations are the systems that we are going to test, henceforth they will be called IUT,implementation under test, and the class of all IUT’s is denoted by IMPS . So, conformance couldbe introduced by having a relation conforms−to ⊆ IMPS × SPECS with IUT conforms−to sexpressing that IUT is a correct implementation of specification s.

However, unlike specifications, implementations under test are real, physical objects, such aspieces of hardware or software; they are treated as black boxes exhibiting behaviour and interactingwith their environment, but not amenable to formal reasoning. This makes it difficult to give aformal definition of conforms−towhich should be our aim in a formal testing framework. In orderto reason formally about implementations, we make the assumption that any real implementationIUT ∈ IMPS can be modeled by a formal object iIUT ∈ MODS , where MODS is referred to as theuniverse of models. This assumption is referred to as the test hypothesis [Ber91]. Note that thetest hypothesis only assumes that a model iIUT exists, but not that it is known a priori.

Thus the test hypothesis allows to reason about implementations as if they were formal objects,and, consequently, to express conformance by a formal relation between models of implementationsand specifications. Such a relation is called an implementation relation imp ⊆ MODS × SPECS[BAL+90, ISO96]. Implementation IUT ∈ IMPS is said to be correct with respect to s ∈ SPECS ,IUT conforms−to s, if and only if the model iIUT ∈ MODS of IUT is imp-related to s: iIUT imp s.

Observation and testing The behaviour of an implementation under test is investigated byperforming experiments on the implementation and observing the reactions that the implementa-

63

Page 74: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

tion produces to these experiments. The specification of such an experiment is called a test case,and the process of applying a test to an implementation under test is called test execution.

Let test cases be formally expressed as elements of a domain TESTS . Then test executionrequires an operational procedure to execute and apply a test case t ∈ TESTS to an implemen-tation under test IUT ∈ IMPS . This operational procedure is denoted by exec(t, IUT). Duringtest execution a number of observations will be made, e.g., occurring events will be logged, or theresponse of the implementation to a particular stimulus will be recorded. Let (the formal inter-pretation of) these observations be given in a domain of observations OBS , then test executionexec(t, IUT) will lead to a subset of OBS . Note that exec is not a formal concept; it captures theaction of “pushing the button” to let t run with IUT. Also note that exec(t, IUT) may involvemultiple runs of t and IUT, e.g., in case nondeterminism is involved.

Again, since exec(t, IUT) corresponds to the physical execution of a test case, we have to modelthis process of test execution in our formal domain to allow formal reasoning about it. This isdone by introducing an observation function obs : TESTS ×MODS → P(OBS ). So, obs(t, iIUT)formally models the real test execution exec(t, IUT).

In the context of an observational framework consisting of TESTS , OBS , exec and obs , it cannow be stated more precisely what is meant by the test hypothesis:

∀IUT ∈ IMPS ∃iIUT ∈ MODS ∀t ∈ TESTS : exec(t, IUT) = obs(t, iIUT) (1)

This could be paraphrased as follows: for all real implementations that we are testing, it is assumedthat there is a model, such that if we would put the IUT and the model in black boxes and wouldperform all possible experiments defined in TESTS , then we would not be able to distinguishbetween the real IUT and the model. Actually, this notion of testing is analogous to the ideasunderlying testing equivalences [DNH84, DN87].

Usually, we like to interpret observations of test execution in terms of being right or wrong.So we introduce a family of verdict functions verd t : P(OBS ) → {fail,pass} which allows tointroduce the following abbreviation:

IUT passes t =def verd t(exec(t, IUT)) = pass (2)

This is easily extended to a test suite T ⊆ TESTS : IUT passes T ⇔ ∀t ∈ T : IUT passes t.Moreover, an implementation fails test suite T if it does not pass: IUT fails T ⇔ IUT /passes T .

Conformance testing Conformance testing involves assessing, by means of testing, whetheran implementation conforms, with respect to implementation relation imp, to its specification.Hence, the notions of conformance, expressed by imp, and of test execution, expressed by exec,have to be linked in such a way that from test execution an indication about conformance isobtained. So, ideally, we would like to have a test suite Ts such that for a given specification s

IUT conforms−to s ⇐⇒ IUT passes Ts (3)

A test suite with this property is called complete; it can distinguish exactly between all conformingand non-conforming implementations. Unfortunately, this is a very strong requirement for practi-cal testing: complete test suites are usually infinite, and consequently not practically executable.Hence, usually a weaker requirement on test suites is posed: they should be sound, which meansthat all correct implementations, and possibly some incorrect implementations, will pass them;or, in other words, any detected erroneous implementation is indeed non-conforming, but not theother way around. Soundness corresponds to the left-to-right implication in (3). The right-to-leftimplication is called exhaustiveness; it means that all non-conforming implementations will bedetected.

To show soundness (or exhaustiveness) for a particular test suite we have to use the formalmodels of implementations and test execution:

∀i ∈ MODS : ( i imp s ⇐⇒ ∀t ∈ T : verd t(obs(t, i)) = pass ) (4)

64

Page 75: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Once (4) has been shown it follows that:

IUT passes Tiff (∗ definition passes T ∗)

∀t ∈ T : IUT passes tiff (∗ definition passes t ∗)

∀t ∈ T : verd t(exec(t, IUT)) = passiff (∗ test hypothesis (1) ∗)

∀t ∈ T : verd t(obs(t, iIUT)) = passiff (∗ completeness on models (4) applied to iIUT ∗)

iIUT imp siff (∗ definition of conformance ∗)

IUT conforms−to s

So, if the completeness property has been proved on the level of models and if there is ground toassume that the test hypothesis holds, then conformance of an implementation with respect to itsspecification can be decided by means of a testing procedure.

3 Observation Objectives in the Formal Framework

Our aim in this section is to extend the framework of the previous section with observationobjectives.

An observation objective describes the observations that we wish to see from the implemen-tation during the test. Whether an implementation is able to show these observations is calledexhibition: an implementation exhibits an observation objective if it has the possibility to showthe observations described in the observation objective. In the next paragraph this concept of ex-hibition is elaborated completely analogous to the concept of conformance in the previous section.

The next task is to test for exhibition. Given an observation objective (and a specification),a test case should be derived such that it allows the implementation to show the observationsdescribed in the observation objective. Preferably, the derived test case should be such that alland only all implementations that have the possibility to show the observations will indeed do so.Analogous to completeness in the previous section this will be called e-completeness.

Finally, in the last paragraph, the orthogonality between conformance and exhibition is furtherelaborated.

Exhibition and observation First we introduce the formal notion of a observation objective.An observation objective is a formal specification of the behaviour that we would like to observeexplicitly during testing. The universe of observation objectives is called TOBS . We introducea relation that relates an observation objective with all implementations that are able to exhibitthat observation objective. Exhibition of an observation objective by an implementation expressesthat an implementation can possibly manifest the behaviour specified by the observation objective.When we execute a well chosen set of experiments, the implementation will show behaviour that isspecified by the observation objective. The notion of showing the specified behaviour is determinedby this relation. We call the relation exhibits ⊆ IMPS × TOBS .

To formally reason about exhibition, we have to link the informal, experimental world andthe formal world. Analogous to the definition of conforms−to, we need a relation of exhibitsin the formal domain in order to reason about exhibition of an observation objective and todecide whether experiments would be able to challenge an implementation to exhibit the requestedobservations. We make again the assumption of the test hypothesis. We call this relation the revealrelation rev ⊆ MODS × TOBS. So the implementation IUT ∈ IMPS satisfies an observationobjective e ∈ TOBS , if and only if the model iIUT ∈ MODS of IUT is rev-related to e: iIUT rev e.

To decide whether an implementation exhibits an observation objective, we use testing and in-terpret the gained observations obtained by the experiments. Recalling the introduced observation

65

Page 76: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

and testing framework and its formalisms, we use a verdict function that relates the observationswith respect to an observation objective resulting in a verdict whether we have seen evidence ofexhibition. We call such a function the hit-function He : P(OBS ) → {hit,miss}. Here hit is theverdict that expresses that we have found such evidence during experimenting. We introduce thefollowing abbreviation, where te is a test case related to an observation objective e, i.e. developedbased on e.

IUT hits e by te =def He(exec(te, IUT )) = hit

This is extended to a test suite Te and we abbreviate IUT hits e by Te =def

He(⋃{exec(t, IUT ) | t ∈ Te}) = hit. Note that this abbreviation differs from the

IUT passes T abbreviation. An implementation misses a test suite Te if it does not hit:IUT misses e by Te =def ¬ (IUT hits e by Te).

Exhibition testing Exhibition testing is the process of deciding whether an implementation isrev-related to its observation objective, by means of experimentation. We need to relate the testexecution and rev, aiming at getting a verdict from the test execution such that we obtain anindication about exhibition of the observation objective. Ideally we would like to have a test suiteTe such that:

IUT exhibits e ⇐⇒ IUT hits e by Te (5)

Analogous to conformance testing, we can introduce notions of completeness, ex-haustiveness and soundness. We call a test suite of Equation 5 e-complete. Sucha test suite can distinguish among all exhibiting and non-exhibiting implementations.A test suite is e-exhaustive when it only can detect non-exhibiting implementations(IUT exhibits e implies IUT hits e by Te). A test suite is e-sound when it only can detectexhibiting implementations (IUT exhibits e if IUT hits e by Te).

To reason whether a test suite is able to challenge an implementation to exhibit an obser-vation objective and to detect all exhibiting implementations we have to show e-soundness ande-completeness of such a test suite. For this we use the formal models of implementation and testexecution:

∀i ∈ MODS : ( i rev e iff He(⋃

{obs(te, i) | te ∈ Te}) = hit ) (6)

Once (6) has been shown it follows that:

IUT hits e by Te

iff (∗ abbreviation hits e by Te ∗)He(

⋃{exec(te, IUT) | te ∈ Te}) = hit

iff (∗ test hypothesis (1) ∗)He(

⋃{obs(te, iIUT) | te ∈ Te}) = hit

iff (∗ e-completeness on models (6) ∗)iIUT rev e

iff (∗ definition of exhibition ∗)IUT exhibits e

We can now decide whether an implementation exhibits an observation objective by means oftesting, provided that this completeness property has been proven and it is plausible that the testhypothesis holds.

Combining conformance and exhibition We return to the test selection problem, where wecombine exhibition and conformance for the derivation of a test suite. The observation objectiveis used as a criterion for the selection: we aim at obtaining a test suite that is e-complete andsound. We want e-soundness so that we can conclude that an implementation exhibits, based on

66

Page 77: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

the test results. Furthermore we require e-exhaustiveness, because we want to be able to find allimplementations that are able to exhibit. The soundness property provides us with the ability todetect erroneous implementations. So the test derivation process can be reformulated as given anobservation objective e and a specification s, find a test suite Ts,e such that Ts,e is sound withrespect to imp and Ts,e is e-complete with respect to rev.

When we apply observation objectives for conformance testing, it appears that not everyobservation objective is feasible. As said, we use the test results of exhibition to support theconfidence of correctness of an implementation. Ideally, we try to detect by experimentation allimplementations IUT that pass and hit, i.e. for some Ts,e : {IUT ∈ IMPS | IUT passes Ts,e

and IUT hits e by Ts,e}. This gives some restrictions on the specification of an observationobjective. We study this in the domain of formal models of the implementations.

Consider Figure 1. Let i imp s be the set with all conforming models of implementations, andi passes T , the models that pass a sound test suite of T . The set i rev e is the set of models thatexhibit observation objective e. Notice that this set corresponds to the set of implementationsIUT hits e by Te with Te being an e-complete test suite. We distinguish four different scenariosof intersection of i rev e and i passes T . These are visualized in Figure 1a-d.

(d)

(c)

(b)

(a)

i passes T

i rev e

i rev e

i imp s

i passes T

MODS

MODS

MODS

MODS

i imp s

i rev e

i imp s

i passes T

i imp s

i passes T

i rev e

Figure 1: Scenarios of choosing an observation objective

Figure 1(a) visualizes the empty intersection. This means that there exists no implementationthat exhibits and that will be passed as a correct implementation. A test suite for this situation isinfeasible, since for all exhibiting implementations, we will get a fail verdict during execution ofthe test suite. In Figure 1(b), we have chosen a test suite where we detect (following a (pass,hit)verdict) implementations that exhibit but that are incorrect (not in i imp s). This situation isnot desirable. Fortunately, we can check during test derivation whether these situations (a) and(b) occur (based on our formal models and formal relations), and decide not to derive such testsuites.

The ideal situation is depicted in Figure 1(d) (this might also include the situationi rev e ⊇ i passes T ). Here all correct implementations also exhibit. However, this wouldin general make it very complicated to specify an observation objective. It would imply that

67

Page 78: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

observation objectives would be restricted to the ones with the property {i ∈ MODS | i rev e}⊇ {i ∈ MODS |i imp s}. This is hard to prove taking all nondeterminism and complexity ofa specification into account. So we loosen such a requirement and in practice we try to developa test suite that is visualized in Figure 1(c). We have the most confidence in the correctness ofan implementation that conforms and exhibits (verdict (pass,hit)). However, we still might findan implementation that is correct, but does not exhibit (which corresponds to the notion of theinconclusive verdict [ISO91]), or an implementation that is incorrect and exhibits.

Summarizing all, we can formulate our practical approach to conformance testing using exhi-bition. We choose an observation objective e such that:

{i | i rev e} ∩ {i | i imp s} �= ∅ (7)

From such an observation objective and formal specification we derive a test suite Ts,e thatis e-complete and sound. After execution of Ts,e we reject an implementation that gives a failverdict. We have an increased confidence in the correctness when the test results evaluate to a(pass,hit) verdict. An experiment that evaluates to a (pass,miss) verdict has not found anyevidence of non conformance of the implementation, but has also not detected any behaviour thatsupports our confidence in the correctness of the implementation.

4 Testing with ioco

We will instantiate the discussed framework with the ioco based conformance testing theory, c.f.[Tre96]. In this section we recall the basics of the ioco theory and its related notation.

Labelled transition systems Labelled transition systems provide a formalism to specify,model, analyse and reason about system behaviour. A labelled transition system descriptionis defined in terms of states and labelled transitions between states.

Definition 4.1A labelled transition system is a 4-tuple 〈S,L, T, s0〉 where

◦ S is a non-empty set of states ;◦ L is a finite set of labels ;◦ T ⊆ S × (L ∪ {τ})× S is a set of triples, the transition relation;◦ s0 ∈ S is the initial state.

The labels in L represent the observable interactions of a system. The special label τ �∈L represents an unobservable, internal action. We denote the class of all labelled transitionsystems over L by LTS(L). Transition systems without infinite paths of transitions with onlyinternal actions are called strongly converging. For technical reasons we restrict LTS(L) to stronglyconverging transition systems.

A trace is a finite sequence of observable actions. The set of all traces over L is denoted byL∗, with ε denoting the empty sequence. If σ1, σ2 ∈ L∗, then σ1·σ2 is the concatenation of σ1 andσ2. Some additional notations and properties are introduced in Definitions 4.2 and 4.3.

Definition 4.2Let p = 〈S,L, T, s0〉 be a labelled transition system with s, s′ ∈ S, and let µ(i) ∈ L∪{τ}, a(i) ∈ L,

68

Page 79: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

σ ∈ L∗, and n ≥ 0.

s ε−→ s′ =def s = s′

s µ−−→ s′ =def (s, µ, s′) ∈ Ts µ1·...·µn−−−−−−→ s′ =def ∃s0, . . . , sn : s = s0 µ1−−→ s1

µ2−−→ . . . µn−−→ sn = s′

s µ1·...·µn−−−−−−→ =def ∃s′ : s µ1·...·µn−−−−−−→ s′

sµ1·...·µn−−−−−−−→/ =def not ∃s′ : s µ1·...·µn−−−−−−→ s′

sε=⇒ s′ =def s τ ·...·τ−−−−→ s′

sa=⇒ s′ =def ∃s1, s2 : s ε=⇒ s1

a−→ s2ε=⇒ s′

sa1·...·an======⇒ s′ =def ∃s0 . . . sn : s = s0

a1==⇒ s1a2==⇒ . . .

an==⇒ sn = s′

sσ=⇒ =def ∃s′ : s σ=⇒ s′

=�⇒ =def ¬ ∃s′ : s σ=⇒ s′✷

We will not always distinguish between a labelled transition system and its initial state: ifp = 〈S,L, T, s0〉, then we will identify the labelled transition system p with its initial state s0, andwe write, for example, p σ=⇒ instead of s0

σ=⇒ .

Definition 4.3Let p be a (state of a) labelled transition system and let P be a set of states.1. init(p) =def { µ ∈ L ∪ {τ} | p µ−−→ }2. init(P ) =def

⋃{ init(p) | p ∈ P }

3. traces(p) =def { σ ∈ L∗ | p σ=⇒ }4. p after σ =def { p′ | p σ=⇒ p′ }5. P after σ =def

⋃{ p after σ | p ∈ P } ✷

A labelled transition system can also be denoted by a process-algebraic behaviour expression.We introduce a (for this paper) limited set with syntax:

B =def stop | α;B | B +B | ΣB

Here α ∈ L and B is a countable set of behaviour expressions. The semantics are defined bythe following inference rules and axioms:

� stop α−−→/ , α ∈ L ∪ {τ}� α;B α−−→B

B1α−−→B′

1, α ∈ L � B1 +B2α−−→B′

1

B2α−−→B′

2, α ∈ L � B1 +B2α−−→B′

2

B α−−→B′, B ∈ B, α ∈ L � ΣB α−−→B′

Input-output transition systems We assume that the label set L can be partitioned intoinput actions LI and output actions LU : L = LI ∪ LU and LI ∩ LU = ∅. Moreover, we considersystems which always accept any input. In terms of transition systems: all inputs, i.e., all actionsin LI , are enabled in any reachable state of the transition system. Such transition systems arecalled input-output transition systems. In input-output transition systems, inputs of one systemcommunicate with the outputs of the other system, and vice versa, (cf. IOA [LT89]).

Definition 4.4An input-output transition system p is a labelled transition system in which the set of actions Lis partitioned into input actions LI and output actions LU (LI ∪ LU = L,LI ∩ LU = ∅), and forwhich all inputs are enabled in any reachable state:

whenever pσ=⇒ p′ then ∀a ∈ LI : p′ a=⇒

The class of input-output transition systems with input actions in LI and output actions in LU isdenoted by IOTS(LI , LU ) ⊆ LTS(LI ∪ LU ).

69

Page 80: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Implementation relation We will use the relation ioco as implementation relation. Thisrelation assumes that the specification is expressed as a labelled transition system in which inputsand outputs can be distinguished (not necessarily IOTS), and that the implementation behavesas, i.e., can be modeled by, an input-output transition system (cf. test hypothesis Section 2):ioco ⊆ IOTS(LI , LU )× LTS(LI ∪ LU ).

An implementation i ∈ IOTS(LI , LU ) is ioco-correct with respect to the specification s ∈LTS(LI ∪ LU ) if i can never produce an output which could not have been produced by s inthe same situation, i.e., after the same specification trace. Moreover, i may only stay silent, i.e.,produce no output at all, if s can do so. The absence of outputs is called quiescence and is denotedby a special label δ (δ �∈ L ∪ {τ}), cf. [Vaa91].

To formalize this notion of conformance ioco we first define quiescence as the absence ofoutputs. Then we extend traces of actions with the special action δ. Occurrence of δ in a statep, denoted by p δ−→ , expresses that state p cannot produce any output. Since no ‘normal’ actionin p is executed in that case, p cannot move to another state, so always p δ−→ p′ implies p′ = p.Traces in which both normal actions in L and the special action δ may occur are called suspensiontraces. To denote suspension traces the notations µ−−→ and σ=⇒ (Definitions 4.1, 4.2 and 4.3) areextended to Lδ = L∪{δ}, and to traces in L∗

δ, respectively. Note that this overlapping of notationdoes not introduce conflicts.

Definition 4.5Let p ∈ LTS(LI ∪ LU ).

1. A state q of p is quiescent, denoted by q δ−→ q, if ∀µ ∈ LU ∪ {τ} : q µ−−→/2. The suspension traces of p ∈ LTS(LI ∪ LU ) are:

Straces(p) =def { σ ∈ (L ∪ {δ})∗ | p σ=⇒},where σ=⇒ is as in Definition 4.2 extended with δ-transitions q δ−→ q.

We can now define the possible outputs out( p after σ ) of a process p after a suspension traceσ. The action δ may occur in out( p after σ ) as a special action indicating that after σ it ispossible to observe no outputs at all, i.e., quiescence. Using out( p after σ ) the definition of iocois now straightforward by requiring that after any suspension trace of the specification any possibleoutput of the implementation should be a possible output of the specification.

Definition 4.6Let p be a (state of a) labelled transition system, and let P be a set of states; let i ∈ IOTS(LI , LU )and s ∈ LTS(LI ∪ LU ), then

1. out(p) =def { x ∈ LU ∪ {δ} | p x−−→ }2. out(P ) =def

⋃{ out(p) | p ∈ P }

3. i ioco s =def ∀σ ∈ Straces(s) : out( i after σ ) ⊆ out( s after σ )✷

Test generation In order to present the test derivation algorithm we first define a test caseand a test suite. We use the special label θ �∈ LI ∪ LU to represent the observation of quiescence.Furthermore Lθ = L ∪ {θ}. The notation σ represents replacement of δ-actions by θ-actions andvice versa, i.e. the action that models quiescence is replaced by the action that observes quiescence.

Definition 4.71. A test case t is a labelled transition system 〈S,LI ∪ LU ∪ {θ}, T, s0〉 such that

◦ t is deterministic and has finite behaviour;◦ S contains the terminal states pass and fail, with init(pass) = init(fail) = ∅;◦ for any state t′ ∈ S of t, t′ �= pass, fail: init(t′) = {a} for some a ∈ LI or init(t′) =LU ∪ {θ}.

The universe of all test cases of LI and LU is denoted as TEST (LU , LI).2. A test suite T is a set of test cases: T ⊆ TEST (LU , LI).

70

Page 81: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Algorithm 4.8Let s be a specification with initial state s0. Let S be a non-empty set of states, with initiallyS = s0 after ε . Then a test case t is obtained from S by a finite number of recursive applicationsof one of the following three cases:

1. (∗ terminate the test case ∗)t := pass

2. (∗ give a next input to the implementation ∗)t := a ; t′ , if a ∈ init(S)where a ∈ LI , and t′ is obtained by recursively applying the algorithm for S′ := S after a .

3. (∗ check the next output of the implementation ∗)t := Σ{α; fail | α ∈ LU ∪ {δ} and α �∈ out(S)}

+ Σ{α; tα | α ∈ out(S)}where tα is obtained by recursively applying the algorithm for S′ := S after α .

This algorithm was proved in [Tre96] to produce only sound test cases, i.e., test cases whichnever produce fail while testing an ioco-conforming implementation. Moreover, it was shownthat any non-conforming implementation can always be detected by a test case generated withthis algorithm. For more details about the relation ioco, for a rationale for its use, and for moregeneric definitions we refer to [Tre96].

5 Observation Objectives in IOTS

In this section we instantiate the framework presented in Section 3 with the ioco theory of Sec-tion 4. We start with an example to clarify the introduced concepts.

coffee

milk coffee

milk

coin

sugar tea

tea sugar

coin

coffee

milk

milkcoffee

(a) (b)

Figure 2: Coffee machines

Example 5.1Consider the specification s of a simple coffee machine in Figure 2(a), with LI = {coin} and LU ={milk, coffee}. This coffee machine provides a user with coffee with milk after the insertion of a coin.We want to test an implementation for conformance. However, we will not do this exhaustively,but we are interested in only those experiments that will challenge the system to provide coffee.If we find during testing no evidence of non conformance and we will observe coffee, than weassume that the implementation is correct. The specification of the coffee machine describestwo traces of interactions that let the machine provide coffee. These two traces are capturedin the observation objective, since during the experiments we might observe these sequences ofinteractions. So we choose the formal observation objective e={coin·coffee·milk, coin·milk·coffee}.Furthermore we define the hit-function as He(O) = hit iff O ∩ e �= ∅; if we observe any test runthat is included in the observation objective, we conclude that the system exhibits. Note that here

71

Page 82: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

TOBS is the power set of a set of traces of the specification with label set L = {coffee,coin,milk}(TOBS = P(L∗)). Now let Ts,e be a sound en e-complete test suite for s and e. When duringtesting using test suite Ts,e, we observe either coin·coffee·milk or coin·milk·coffee as a test run weconclude that IUT exhibits e.

Reveal relations We instantiate the presented framework of Section 3 with the ioco theory.We inherit TESTS = TEST (LU , LI), OBS = (LI ∪LU ∪{θ})∗ and MODS = IOTS(LI , LU ). Wefirst consider singular observation objectives. A singular observation objective can be exhibitedby one observation of a test case execution. The used observation objective in Example 5.1 isa singular observation objective. For singular observation objectives it would be sufficient tospecify it by a set of traces which consists of all potential observations that will lead to exhibitionduring testing. We take as the specification of the observation objective a set of traces from L∗

δ ,i.e. the counterpart of a subset of OBS (δ versus θ). So TOBS = P(L∗

δ) and we instantiaterev ⊆ IOTS(LI , LU )× P((LI ∪ LU ∪ {δ})∗). We define the reveal input output singular relationrios for the singular case. This relation relates formally all models of implementations that arepotentially able to exhibit a singular test objective to that observation objective. A model of animplementation exhibits the singular test objective if one of its suspension traces is an elementof the observation objective. So a hit-function He for a singular observation objective evaluatesto hit if one of the prefixes of an observation (test run, i.e. trace from L∗

θ) is included in theobservation objective.

Definition 5.2Let i ∈ IOTS(LI , LU ) be an implementation, O ⊆ L∗

θ a set of observations and e ⊆ L∗δ a singular

observation objective, then1. prefix(O) = {σ1 | σ1·σ2 ∈ O with σ2 ∈ L∗

θ}2. i rios e =def Straces(i) ∩ e �= ∅3. Hrios

e (O) = hit =def prefix(O) ∩ e �= ∅✷

For example, reconsider Figure 2(a) as an implementation i after making it input complete.Then i rios { coin · milk, coin · coffee · milk } holds. This observation objective insists on theobservation of milk.

With a singular observation objective we can only require the exhibition of one trace fromthat observation objective. This is a limited expressiveness of an observation objective. We wantto specify more than one trace that should be exhibited during the experiment. We can do thiswith plural observation objectives. A plural observation objective is composed out of singularobservation objectives, which all should be individually exhibited during the execution of the testsuite in order to satisfy the composed (plural) observation objective. The following example showsan application of this.

Example 5.3Consider the coffee machine in Figure 2(b), with LI = {coin} and LU = {milk, coffee, tea, sugar}.During testing we want to observe evidence that the machine can deliver coffee with milk andtea with sugar. We specify this by a plural observation objective and choose the set of singularobservation objects E = {{ coin · coffee · milk, coin · milk · coffee }, { coin · tea · sugar, coin ·sugar · tea }}. The hit-function is defined by HE(O) = hit iff ∀e ∈ E : O ∩ e �= ∅.

In ioco terms a plural observation objective is a set which is an element of TOBS = P(P(L∗δ))

and the reveal relation rev ⊆ IOTS(LI , LU )×P(P(L∗δ)). The exhibition of a plural test objective

E requires in general more than one observation during testing, since seldom⋂{e | e ∈ E} �= ∅,

which can be satisfied by just one observation. We can, analogously to, the singular case definethe reveal input out plural relation riop and the hit-function Hriop

E (O).

72

Page 83: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Definition 5.4Let i ∈ IOTS(LI , LU ) be an implementation, O ⊆ L∗

θ a set of observations and E ⊆ P(L∗δ) a

plural observation objective then:1. i riop E =def ∀e ∈ E : i rios e2. Hriop

E (O) = hit iff ∀e ∈ E : Hriose (O)

For example, consider Figure 2b as an implementation i after making it input complete. Theni riop {{ coin · milk, coin · coffee · milk }, { coin · tea, coin · sugar · tea }} holds. This pluralobservation objective insists on the observation of milk and tea.

Test generation We first consider the singular case. We have a formal definition of the revrelation and of the imp-relation, which are respectively rios and ioco. We want to generate a testsuite that is sound and e-complete. Furthermore we restrict our observation objective such that{i ∈ MODS |i rios e} ∩ {i ∈ MODS |i ioco s} �= ∅ (c.f. Section 3 Equation 7). Proposition5.5 shows that it is sufficient to choose the test objective as a subset of the suspension traces ofthe specification to satisfy this constraint.

Proposition 5.5Let s ∈ LTS(LI ∪ LU ) be a specification and let e ∈ P(L∗

δ) be an observation objective.

if e ⊆ Straces(s) then {i ∈ IOTS(LI , LU ) | i rios e} ∩ {i ∈ IOTS(LI , LU ) | i ioco s} �= ∅

The restriction of an observation objective to a subset of the suspension traces of the specifi-cation is a sufficient condition to guarantee a non empty intersection of conforming and exhibitingimplementations. This restriction excludes observation objectives that challenge implementationsto react on inputs that are not specified by the specification. Since our goal is to test for con-forming implementations it makes no sense to check for exhibition of non-specified behaviour.From now on we choose singular and plural observation objectives such that e ⊆ Straces(s), andE ⊆ P(Straces(s)), respectively. From practical point of view, a test engineer might want tospecify an observation objective in a less strict way, i.e. including traces which are not in the spec-ification. Then we take as semantics for the observation objective, the intersection of Straces(s)and the specified traces.

We present a simple algorithm to derive a test suite from an observation objective and aspecification.

Algorithm 5.6Let s ∈ LTS(LI ∪ LU ) be a specification, and let e ⊆ Straces(s) ⊆ L∗

δ be a singular observationobjective. Then a test suite T ⊆ TEST (LU , LI) can be generated, by adding a test case tε,σ to Tfor every trace σ of e, i.e. T = {tε,σ | σ ∈ e}. The test case tε,σ is obtained by application of thefollowing rules:

1. tρ,ε := pass2. tρ,a·σ′ := a; tρ·a,σ′ with a ∈ LI

3. tρ,x·σ′ := Σ{α; fail | α ∈ LU ∪ {δ} and α �∈ out( s after ρ )}+ Σ{α;pass | α ∈ out( s after ρ )\{x}}+ x; tρ·x,σ′ , with x ∈ LU ∪ {δ}

Proposition 5.7

1. A test suite obtained with Algorithm 5.6 is sound with respect to s and ioco.2. A test suite obtained with Algorithm 5.6 is e-sound with respect to rios and e.3. A test suite obtained with Algorithm 5.6 is e-exhaustive with respect to rios and e.

73

Page 84: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

As a consequence of Proposition 5.7 the obtained test suite is e-complete. The next exampleshows a resulting test suite produced by the algorithm.

Example 5.8The test cases depicted in Figure 3 will be generated when we apply Algorithm 5.6 for the spec-ification s in Figure 2a, using the singular observation objective { coin · milk · coffee, coin ·coffee }, expressing that we wish to see evidence of delivery of coffee. Note that now TOBS =P(({coin,coffee,milk,δ})∗). For clarity we marked the states where the observation objective isexhibited with hit. Notice that this can only be done with singular observation objectives, sincein general we need more than one observation before we can conclude that a plural observationobjective exhibits.

coin

milkcoffee

milkcoffee

coin

coffeemilk

δ

δ

pass fail fail

pass fail

δ

failpass passhit

hit

hit

Figure 3: Test suite for a singular observation objective

In order to judge if we have found evidence whether an implementation exhibits the observationobjective, we gather all the observations during testing, i.e. a set of test runs. By applying thehit-function Hrios

e we get the exhibition verdict.

The test generation of test suites for plural observation objectives is straightforward. Weflatten the set of singular observation objectives to one set and apply Algorithm 5.6. So, lets ∈ LTS(LI ∪ LU ) be a specification and E ⊆ P(Straces(s)) be a plural observation objective.Then a test suite T ∈ TEST (LU , LI) for testing can be obtained by applying Algorithm 5.6 withe =

⋃E. To obtain a verdict of exhibition of a plural observation objective, we evaluate Hriop

E

for the obtained set of test runs during execution of the test suite.

The presented algorithm is not optimized for efficiency. For instance, one might combine severaltraces of a singular observation objective to generate one test case instead of the generation of onetest case for every trace. In the case of Figure 3 we can reduce the test suite to only the leftmosttest case.

During testing, it is possible that we do not detect that an implementation exhibits a plural ob-servation objective, but only some of the composing singular observation objectives are exhibited.This can be due to many reasons like nondeterministic behaviour of the implementation, limitedexecution time etc. It is possible to define a measure to see how much of a plural observationobjective has been exhibited during the test execution. This can be done in a straightforward wayby counting how many elements of the observation objective have been hit. We call this coverageexhibition coverage.

74

Page 85: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Definition 5.9Let E ⊆ P(L∗

δ) be a plural observation objective and let O ⊆ L∗θ be a set of observations. Then

the exhibition coverage γE is defined as:

γE =def|{e ∈ E | Hrios

e (O) = hit}||E|

6 Concluding Remarks

In this paper we have proposed a formal framework for observation objectives and we have shownhow to use it as means for test selection in the field of conformance testing. The major contributionof this framework is that we have a clear and precise notion of what an observation objective is,when it is satisfied and how test results based on observation objectives should be interpreted.Furthermore we have instantiated the framework with ioco-based testing theory and we havepresented an e-complete and sound test derivation algorithm.

One of the major questions is how to represent and specify an observation objective. As weshowed by our examples, a test engineer can specify a test object by explicitly writing down aset of suspension traces. However, in practice we would like to put a level above that and useobservation objectives as a semantic object for traditional test purposes. Given a specificationand a TGV like test purpose, i.e. an automaton, or a regular expression over traces (Autolink), wewould like to automatically translate this to an observation objective. Another idea is to representa test purpose by a property of a specification in a logic, e.g. LTL, and define the semantics interms of observation objectives.

However, observation objectives give not only means to represent test purposes that some-how are related to the specification, but can also be used to specify strategies. Examples ofthese are maximum execution length in terms of number of observations, or specifying an outputeager observation strategy. The latter might be expressed by a regular expression over traces:((LI ·(L∗

U )·δ)∗).Another issue is the combination of several observation objectives. As an example one might

think of a combination of a test purpose together with a pragmatic (often applied) strategy. Havingthe formal framework, with the formal semantics, we can define a logic over observation objectivesto facilitate these combinations.

Currently we have already implemented the basics of the observation objectives approachin the on-the-fly test derivation and execution tool TorX [BFV+99]. An observation objectiveis represented by a labelled transition system, which is again represented by a process algebra(LOTOS) and offers a functionality to specify a strategy for the test derivation instead of onlyrandomness. The first experiments are promising, in the sense that we indeed succeed in steeringthe test derivation process.

Acknowledgement

The authors would like to acknowledge Lex Heerink, Axel Belinfante, Jan Feenstra and the anony-mous reviewers for their constructive comments.

References

[BAL+90] E. Brinksma, R. Alderden, R. Langerak, J. van de Lagemaat, and J. Tretmans. A formalapproach to conformance testing. In J. de Meer, L. Mackert, and W. Effelsberg, editors,Second Int. Workshop on Protocol Test Systems, pages 349–363. North-Holland, 1990. Also:Memorandum INF-89-45, University of Twente, The Netherlands.

75

Page 86: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[Ber91] G. Bernot. Testing against formal specifications: A theoretical view. In S. Abramsky andT.S.E. Maibaum, editors, TAPSOFT’91, Volume 2, pages 99–119. Lecture Notes in ComputerScience 494, Springer-Verlag, 1991.

[BFV+99] A. Belinfante, J. Feenstra, R.G. de Vries, J. Tretmans, N. Goga, L. Feijs, S. Mauw, andL. Heerink. Formal test automation: A simple experiment. In G. Csopaki, S. Dibuz, andK. Tarnay, editors, 12th Int. Workshop on Testing of Communicating Systems. Kluwer Aca-demic Publishers, 1999.

[DN87] R. De Nicola. Extensional equivalences for transition systems. Acta Informatica, 24:211–237,1987.

[DNH84] R. De Nicola and M.C.B. Hennessy. Testing equivalences for processes. Theoretical ComputerScience, 34:83–133, 1984.

[DRS+00] L. Du Bousquet, S. Ramangalahy, S. Simon, C. Viho, A. Belinfante, and R.G. de Vries. Formaltest automation: The conference protocol with TGV/Torx. In H. Ural, R.L. Probert, and G. v.Bochmann, editors, IFIP 13th Int. Conference on Testing of Communicating Systems(TestCom2000). Kluwer Academic Publishers, 2000.

[Hol99] M. Hollenberg. Test templates for test generation. In K. Tarnay G. Csopaki, S. Dibuz, editor,12th Int. Workshop on Testing of Communicating Systems, pages 167–178. Kluwer AcademicPublishers, 1999.

[ISO91] ISO. Information Technology, Open Systems Interconnection, Conformance Testing Method-ology and Framework. International Standard IS-9646. ISO, Geneve, 1991. Also: CCITTX.290–X.294.

[ISO96] ISO/IEC JTC1/SC21 WG7, ITU-T SG 10/Q.8. Information Retrieval, Transfer and Manage-ment for OSI; Framework: Formal Methods in Conformance Testing. Committee Draft CD13245-1, ITU-T proposed recommendation Z.500. ISO – ITU-T, Geneve, 1996.

[JM99] T. Jeron and P. Morel. Test generation derived from model-checking. In Computer AidedVerification CAV’99. Lecture Notes in Computer Science, Springer-Verlag, 1999.

[LT89] N.A. Lynch and M.R. Tuttle. An introduction to Input/Output Automata. CWI Quar-terly, 2(3):219–246, 1989. Also: Technical Report MIT/LCS/TM-373 (TM-351 revised), Mas-sachusetts Institute of Technology, Cambridge, U.S.A., 1988.

[LY96] D. Lee and M. Yannakakis. Principles and methods for testing finite state machines – a survey.The Proceedings of the IEEE, 84(8):1090–1123., August 1996.

[SEK+98] M. Schmitt, A. Ek, B. Koch, J. Grabowski, and D. Hogrefe. – Autolink – Putting SDL-basedTest Generation into Practice. In A. Petrenko and N. Yevtushenko, editors, 11th Int. Workshopon Testing of Communicating Systems, pages 227–243. Kluwer Academic Publishers, 1998.

[Tre96] J. Tretmans. Test generation with inputs, outputs and repetitive quiescence. Software—Concepts and Tools, 17(3):103–120, 1996. Also: Technical Report No. 96-26, Centre for Telem-atics and Information Technology, University of Twente, The Netherlands.

[Tre99] J. Tretmans. Testing Concurrent Systems: A Formal Approach. In J.C.M. Baeten and S. Mauw,editors, CONCUR’99 – 10th Int. Conference on Concurrency Theory, volume 1664 of LectureNotes in Computer Science, pages 46–65. Springer-Verlag, 1999.

[Vaa91] F. Vaandrager. On the relationship between process algebra and Input/Output Automata. InLogic in Computer Science, pages 387–398. Sixth Annual IEEE Symposium, IEEE ComputerSociety Press, 1991.

76

Page 87: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Complexity Issues of Connectivity Testing

Jens Chr. Godskesen

The IT University of Copenhagen

Abstract

This paper deals with complexity issues of con-

nectivity testing, an approach put forward for

testing embedded systems. Instead of testing

the conformance of a system against its speci-

�cation, which often turns out to be infeasible,

in connectivity testing only the composition of

the software and the hardware in which the soft-

ware is embedded is tested. The testing frame-

work is based on the notion of a fault model,

that is a model which formally captures errors

in the interface between the hardware and the

software. A complete test suite for a fault model

is a test suite that detects the faults of the model

with 100 % coverage. We prove the problem

of computing a smallest complete test suite to

be NP-hard. Therefore we devise approximative

polynomial time algorithms computing minimal

complete test suites.

1 Introduction

Connectivity testing is a testing framework cen-

tered around testing of embedded systems, it

has previously been presented in the papers

[10, 7, 9, 8]. Embedded systems are dedicated

systems like mobile phones, hi-� equipment, re-

mote controls etc., with a very limited user in-

terface, for instance a few push buttons, and a

simple display, where the software, typically a

�nite state machine (FSM), is embedded in the

hardware.

Testing of embedded systems has become more

and more diÆcult because the advances in pro-

cessor speed and memory size at a low cost have

made the manufacturing of sophisticated embed-

ded systems feasible. Also, because products are

often manufactured in large scale testing should

have high focus in order to avoid a cumbersome

an expensive updating of errors in the products.

Traditionally the problem of testing a system

correct with respect to a speci�cation is often re-

ferred to as conformance testing. The goal is to

derive, hopefully automatically, a set of tests, a

test suite, from the speci�cation that may help to

ensure the conformance of the system behaviour

against the speci�cation. That is, the goal is to

check whether the behaviour of the implemen-

tation is the one of its speci�cation. The test

suite should at least enjoy the property that if

the system does not pass all the tests in the test

suite then it is not in conformance with its spec-

i�cation. A formal framework for conformance

testing has been outlined in [3, 17].

The problem with conformance testing in general

however is the size of the test suites, which may

turn out to be in�nite. Therefore the outcome of

applying a �nite number of tests in a test suite

may only approximate a full conformance test.

As a consequence conformance testing may be

practically infeasible.

For speci�cations being FSM's it has been shown

although that test suites need not be in�nite.

In [5] it was proven that conformance between

a speci�cation S and its implementation I can

be tested by a test suite that is polynomial in

the size of the number of states and the num-

ber of input symbols in S, given that I is an

FSM with the same input alphabet and the same

number of states as S, and that S can be reset

77

Page 88: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

to its initial state at any time. 1 A polynomial

time algorithm for constructing the test suite was

outlined in [5].Unfortunately, ifI has more states

than S then the size of the test suite is expo-

nential. Occasionally even stronger assumptions

about S may be taken and in that case other

methods can be applied, for instance the Rural

Chinese Postman Tour [2] (for an overview see

e.g. [11] and [13]).

For industrial sized examples it may often be

however that S contains so many states and in-

put symbols that even if S and I are of equal size

the conformance testing problem is intractable,

either because the test generation procedure is

too time consuming or because the test suite is

too large.

Connectivity testing is an alternative, although

still formally rooted, approach for testing embed-

ded systems. The idea being that the focus is on

testing the composition of the two system com-

ponents: the embedded software and the hard-

ware in which the software is embedded. Hence,

in contrast to conformance testing, our goal is

not to test conformance between the behaviour

of the system speci�cation and the behaviour of

its implementation. Instead we want to test for

errors that may be detected as faults in the in-

terface between the two composed components.

We de�ne that kind of errors by means of fault

models.

A test suite that detects the faults de�ned by a

fault model with 100 % coverage is said to be

complete. In turns out however that the prob-

lem of generating a smallest complete test suite

is NP-hard. We therefore provide approximative

and greedy polynomial time algorithms for com-

puting minimal complete test suites. A minimal

complete test suite is complete, albeit not neces-

sarily a smallest one, but no test may be removed

from it in order to maintain it complete.

1Recently this approach has been carried out in a

timed setting in [16] and [4]. The results in [16] is mainly

of theoretical interest because of its double exponential

test generation algorithm, and the ideas in [4] has been

shown useful for speci�cation with a little more than 100

states.

���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

a

b

c

d

e

1

2

3

0

Hardware

softwareEmbedded

Figure 1: Embedded systems.

The rest of the paper is organized as follows. In

Sec. 2 we motivate our approach. In Sec. 3 we de-

�ne notions and terminology related to FSM's.

Fault models are introduced in Sec. 4 and test

suites in Sec. 5. The existence of minimal com-

plete test suites as well as the NP-hardness of

computing a smallest such one is addressed in

Sec. 6. In Sec. 7 we show that minimal complete

test suites may be computed in polynomial time.

Sec. 8 is the conclusion. Proofs can be found in

the appendix.

2 Motivation

Conceptually an embedded system may be re-

garded as depicted in Fig. 1. That is, an embed-

ded system consists of embedded software en-

capsulated by hardware. Notably all communi-

cations between the system environment and the

embedded software pass through the hardware.

In Fig. 1 this is visualized by letting the inputs

from the system environment to the software

(a; b; c; d; e) pass through the hardware towards

the software via connections (the unlabeled ar-

rows). Similarly, the outputs (0; 1; 2; 3) gener-

ated by the software have to pass via connections

through the hardware in order to emerge at the

system environment.

Each connection is assumed to be related to pre-

cisely one input or output. This assumption im-

78

Page 89: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

���������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

a

b

c

d

e

1

2

3

0

Hardware

softwareEmbedded

Figure 2: A faulty embedded systems.

plicitly implies that there is a one to one cor-

respondence between external inputs to the sys-

tem and the inputs to the embedded software,

likewise there is a one to one correspondence be-

tween the outputs from the software and the out-

puts from the system. Connections are consid-

ered to be abstract notions, they may have no

direct physical counterpart.

Ideally it should be ascertained that the spec-

i�cation of the software component is correct.

For instance, it may have been veri�ed by some

FSM veri�cation technique. Then exploiting the

ability to automatically generate executable code

from speci�cations and assuming a careful con-

struction of such compilers it would be reason-

able to expect the generated code to be correct

with respect to the speci�cation, that is the two

perform the same FSM behaviour.

In the composition of the two system compo-

nents it then follows that the hardware (and

probably drivers managing the interaction be-

tween the hardware and the software) may be

the only error prone part. Therefore in order

to manage the multitude of potential errors we

shall make an abstraction and regard the hard-

ware (and the drivers) as a black box interfacing

the embedded software through the connections.

As a consequence system errors may now only

be referred to in terms of the connections.

Given these assumptions and in order to con-

clude that the system is correct it should be

tested that there are no errors manifested as

faults in the connections between the hardware

component and the embedded software. In the

system in Fig. 1 a fault could for instance be

that one of the connections is missing as shown

in Fig. 2 where the b-input is disconnected. In

the physical world, say a mobile phone, this may

correspond to the situation where some button

of the system is not connected such that the soft-

ware will never receive the input, and therefore

the pressing of the button will cause no e�ect. In

order to make sure the faults are testable they

are assumed to be permanent, that is no con-

nection may alter between being connected and

disconnected.

Testing in order to detect the kind of faults ad-

dressed in this paper is a matter of providing

sequences of inputs that will reveal the miss-

ing connections. If say the b-input connection

in Fig. 1 is missing this may be revealed by an

input sequence containing b. The fault may be

revealed directly if the system on input b immedi-

ately is expected to return some output, because

the erroneous system displays no output. The

fault may be exposed indirectly if the system af-

ter input b eventually is expected to return some

output and it turns out that this output is dis-

tinct from the one actually shown by the faulty

system.

Following the ideas outlined above we outline in

the remaining part of this paper a framework

for testing embedded systems by means of fault

models. It is assumed that embedded software

behaves as FSM's. We introduce one type of

fault models for disconnected inputs.

The notion of a fault model has appeared else-

where in the literature. In particular, fault mod-

els has been used for test generation for embed-

ded systems in [15, 14]. However, although simi-

lar their notion of a fault model is in the setting

of conformance testing. Another signi�cant dif-

ference is that they consider the embedded com-

ponent to be the erroneous part. In the hard-

ware community structural fault models, like for

79

Page 90: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

instance the \stuck at" model, has for decades

been used for circuit testing (see e.g. [1]).

3 Finite state machines

We consider a variant of deterministic �nite state

machines (FSM's) where a set of outputs (possi-

bly the empty one) is produced on each input.

De�nition 1 An FSM, M , with input type E is

a �ve tuple (S; E ;; �; sM ) where S is a �nite set

of states, E is a �nite set of inputs, is a �nite

set of outputs, and � is a transition function,

� : S � E ! S � 2. sM 2 S is the initial state.

In the remaining part of this paper we presup-

pose for any FSM, that the sets S, E and are

ranged over by s, �, and ! respectively. Also we

let o range over 2 and we let � range over E�,

including the empty sequence �. If �0 is a pre�x

of � we write �0 � �. j�j is the length of �. The

notation �#� denotes � where all occurrences of

� are removed, that is

�#� =

8<:

� if � = �

�0#� if � = �0�

(�0#�)�0 if � = �0�0, � 6= �0

For a transition function � we write s�=o�! s0 and

s� for s0 if �(s; �) = (s0; o). If si+1 = si�i for i =

1; : : : ; n we write s� for sn+1 where � = �1 : : : �n.

Whenever s = sM� for some � we say that s is

reachable. Often we shall regard a state s as a

function s : E� ! 2 de�ned by

s(�) =

(; if � = �

o if � = �0�, s�0 �=o�! s�

We generalize this notion to machines and write

M(�) for sM (�).

De�nition 2 Let M and M 0 be two (not neces-

sarily distinct) FSM's with the same input type

and let s and s0 be states in M and M 0 respec-

tively. Then s �i s0 if s(�) = s0(�) for all � with

j�j � i. s � s0 if s �i s0 for all i. M � M 0 if

sM � sM 0.

b/1

d

ec/1,2

a

b/1,3

a/0,2b/1,3

a/0,2b/1c/1,2

s0 s1 s2

s3 s4 s5

Figure 3: An FSM with initial state s0.2

Suppose in the following two FSM's M and M 0

with the same input type E and with disjoint

state sets S and S 0 respectively. Similarly to the

proof of Theorem 10-2 in [12] on may prove that:

Lemma 3 Let m = jSj + jS 0j. Then s 6� s0 i�

s 6�i s0 for some i < m.

Let A� � S � S 0 be de�ned by

A� = f(s; s0) js(�) 6= s0(�)g

For any i = 1; 2; : : : de�ne the set Ai � S � S 0

inductively by

A1 =[�2E

A�

Ai+1 = f(s1; s2)j9�:(s1�; s2

�) 2 Aig

Let Bi = Ai [ Ai�1 for i = 1; 2; : : :. Then the

proof of inequivalence being characterized as de-

scribed by the following lemmas follows directly

from the de�nition of Bi.

Lemma 4 s 6�i s0 i� (s; s0) 2 Bi.

In order to help de�ning fault models in Sec. 4

we introduce a syntactic convention for de�ning

mutations of FSM's.

De�nition 5 M [�] is M where any transition

s�=o�! s0 in M is replaced by s

�=;�! s.

2Empty outputs and transitions to the same state with

empty output are left out.

80

Page 91: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Letting M denote the machine in Fig. 3, M [b]

is the machine in Fig. 4. One interpretation of

M [�] is that the input � has no longer any ef-

fect in M [�] because the machine remains in its

state and generates no output. This intuition is

represented by the lemma and corollary below:

Lemma 6 M [�](��0) = M(��0#�) if � 6= �0.

Corollary 7 M(�) = M [�](�) if � = �#�.

We end this section with a characterization of

when an FSM mutation, M [�], is inequivalent to

its origin M . First however, some terminology is

introduced.

De�nition 8 s is �-active if s(�) 6= ;. s is �-

distinguishable (of degree i) if s 6�i s�. M is �-

active (�-distinguishable) if it contains a reach-

able �-active (�-distinguishable) state. M is �-

sensitive if it is �-active or �-distinguishable.

From the de�nition above it follows that M

is �-active if M(��) 6= ; for some � and M

is �-distinguishable if M(�1��2) 6= M(�1�2)

for some �1 and some distinguishing sequence

�2. As an example, in Fig. 3 it turns out

that s1 and s5 are the only a-active states, s4is d-distinguishable of degree 1, and s5 is e-

distinguishable of degree 2.

The characterization as to whether a mutation is

equivalent or not to its origin are stated by the

lemma below.

Lemma 9 M 6�M [�] i� M is �-sensitive.

d

ec/1,2

a

a/0,2

a/0,2

c/1,2

s0

s3 s4

s1 s2

s5

Figure 4: The FSM in Fig. 3 with input b re-

moved.

4 Fault models

As already touched upon in Sec. 2 the purpose

of a fault model is to capture the errors that are

manifested as disconnections between the hard-

ware and the software components. For instance,

we would like that the fault shown in Fig. 2

where the b-input is disconnected can be han-

dled by a fault model. Importantly, a fault model

should be the formal basis for the generation of

test suites.

The fault in Fig. 2 implies that the input b never

will occur as input to the embedded software.

Recalling that we stipulated the embedded soft-

ware to be correct relative to its FSM speci�ca-

tion, it then follows that at the speci�cation level

we may choose to model a fault as a modi�ca-

tion of the original speci�cation. If for instance

the speci�cation of the embedded software is the

FSM in Fig. 3 then the error prone version of

that FSM where input b has no e�ect is the mu-

tation in Fig. 4. We therefore may choose to let

a fault relative to some M be any mutation of

M , say M0, such that M 6� M

0 and we may let

a fault model be a set of such modi�ed FSM's.

In general we de�ne a fault model as follows

De�nition 10 A fault model for M is a set of

FSM's MM each with the same input type as M

such that M 6�M0 for all M 0 2MM .

The fault models for disconnected inputs are ex-

pected to capture faults as the one described at

the beginning of this section where the b-input is

disconnected, that is they should cover the faults

that arise when input connections are disrupted.

A fault like this occurs for instance when the

pressing of a button on a mobile phone does not

cause any e�ect because the input corresponding

to the button is disconnected.

A single disconnection fault can be modeled by

the mutation M [�] because it speci�es that the

input � has no behavioural e�ect. The fault

models for disconnected inputs consists of sets

of such speci�cations. Let E 0 � E where E is the

81

Page 92: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

input type for someM . Then, ifM is �-sensitive

for any � 2 E 0, a fault model for disconnected in-

put for M may be de�ned by

MME 0 = fM [�] j� 2 E

0g

This fault model represents any one implemen-

tation in which precisely a single input � is dis-

connected for some � 2 E 0, but otherwise the

implementation behaves as speci�ed by M . If

we for instance let M denote the FSM in Fig. 3

then

MMfa;b;c;d;eg (1)

is an input fault model for M containing a mu-

tation of M for each of its inputs. For instance

it contains the FSM de�ned in Fig. 4.

We letMME range over the set of fault models for

M where E is a subset of the input type of M .

Note that any fault model MME

is �nite because

the input type is �nite for any M .

5 Tests

The system to be tested obviously is a non-

formal object. Hence often when developing a

formal testing framework some assumption that

allows for regarding the system as a formal ob-

ject is taken. This step is traditionally referred

to as the testing hypothesis. 3

Recall the conceptualization of embedded sys-

tems put forward in Sec. 2 and in particular

the one to one correspondences between exter-

nal and internal inputs and outputs. In our

testing framework we shall adopt the convention

that the names for the external inputs to (out-

puts from) the embedded system are identical to

the names for the inputs to (outputs from) the

embedded software. This assumption, together

with the overall assumption of embedded soft-

ware being correctly compiled from some FSM

speci�cation, facilitates that the embedded sys-

tem to be tested can be considered an FSM with

the same input type as its software speci�cation.

3See for instance [17, 4].

Taking advantage of this testing hypothesis we

may now formally de�ne the notions related to

tests and how to apply a test to a system.

De�nition 11 Let E be a set of inputs. A test

is a �nite sequence of inputs � 2 E�. A test suite

T � E� is a �nite set of tests.

Given a set of tests T we would like to �lter out

those tests in T with the maximal respectively

minimal length, so let

max (T ) = f� 2 T j8�02 T: j�j � j�

0jg

and let

min(T ) = f� 2 T j8�02 T: j�j � j�

0jg

We let the size of a set of tests T be de�ned by

jT j = ��2T j�j.

For a family of sets of tests hTiii2I we let, when

it is clear from the context, hTiii2I denote the

set of set of tests such that T 2 hTiii2I if T =

f�i j i 2 Ig with �i 2 Ti for all i 2 I. That is, T

contains a test from each member of the family

hTiii2I and any test in T belongs to a member

of the family.

De�nition 12 Let E be a set of inputs. Let

� 2 E, T � E�, and let Ti � E� for all i 2 I.

The cover of � with respect to a family hTiii2I ,

�(hTiii2I), is de�ned by

�(hTiii2I) = fi 2 I j9�0� �: �

02 Tig

The cover of T with respect to hTiii2I is

T (hTiii2I) =S

�2T �(hTiii2I).

That is, a test covers a family member of hTiii2Iif it contains a pre�x that belongs to the member.

A set of tests covers a family member if one of

its tests does. For instance, it is obvious that

T (hTiii2I) = I for all T 2 hTiii2I .

LetM andM 0 be two FSM's with the same input

type E . 4 The application of a test � 2 E� and

4E.g.M may be the speci�cation of the software in the

embedded system M 0.

82

Page 93: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

a set of tests T � E� respectively to M 0with

respect to M is de�ned by

applyM (M 0; �) =�pass if 8�0 � �: M(�0

) = M 0(�0

)

fail otherwise

applyM (M 0; T ) =�pass if 8� 2 T: applyM (M 0; �) = pass

fail otherwise

Knowing how to apply tests we introduce the

notions of sound, exhaustive, and complete for

sets of tests.

De�nition 13 T is sound for MM

Eif for any

� 2 T there exists some M 0 2 MM

Esuch that

applyM (M 0; �) = fail . T is exhaustive for MM

E

if for all M 0 2MM

E, applyM (M 0; T ) = fail . T is

complete for MM

Eif it is sound and exhaustive

for MM

E.

That is, a set of tests T is sound for a fault model

if any � 2 T is guaranteed to detect some fault of

the model, and T is exhaustive for a fault model

if any fault of the model is detectable by some

� 2 T .

Complete test suites for the fault models of dis-

connected inputs can be obtained by means of

sets of tests that characterize the faults in the

models. A characterization of M [�] can be de-

�ned by TM� = T1 [ T2 where

T1 = f�� jM(��) 6= ;g

and

T2 = f��0 jM(��0) 6= M(��0 # �); �0 6= �g

Hence a test for M [�] may be �� for some �

where � takes sM to an �-active state. Or, a

test for M [�] may be ��0for some � and �0

where �0 6= � such that M does not produce

the same output on ��0and the test constructed

by removing all �'s from ��0. For instance, if

M is the FSM in Fig. 3, then faa; ab; acg �

TMa , fab; aab; acdbg � TM

b, fac; acdcg � TM

c ,

facda; acdcg � TM

d, and facdeaa; acdebbg �

TMe.

Notice, that a characterizing set may in general

be in�nite. Actually all the characterizing sets

mentioned in the examples above are in�nite.

In order to prove that these characterizations can

be applied for the construction of complete test

suites we use the following:

Lemma 14 Let E be the input type of M . Then

for all � 2 E, applyM(M [�]; �) = fail i� 9�0 2

TM� : �0 � �.

Corollary 15 If T 2 hTM� i�2E 0 for some E 0 � E

then T is sound for MM

E.

Corollary 16 The cover of T wrt. hTM� i�2E is

E i� T is exhaustive for MM

E.

From Corol. 15 and 16 it follows that a complete

test suite can be de�ned as shown below.

Theorem 17 If T 2 hTM� i�2E , T

0 � T , and the

cover of T 0wrt. hTM

� i�2E is E then T 0is complete

for MM

E.

Notice, no complete test suite for a fault

model MM

Ineeds to contain more tests than

the number of faults in MM

I. As an ex-

ample, letting MM

Ebe as de�ned by Eqn. 1

then T3 = faa; ab; ac; acda; acdeaag and T4 =

fab; ac; acda; acdeaag are complete for MM

Ebe-

cause they belong to hT�i�2E . However, also the

subset fab; acdeaag is complete forMM

Ebecause

its cover with respect to hTM� i�2E is fa; b; c; d; eg.

6 Minimal complete test suites

As indicated at the end of the previous section

some complete test suites for a fault model con-

tain fewer tests than other complete test suites

for the same fault model. Clearly, in practice one

83

Page 94: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

would be interested in complete test suites that

are as small as possible. Ideally, for some fault

model MME , it would be preferable to construct

a smallest complete test suite T for MME . That

is, a test suite T where jT j � jT 0j for any test

suite T 0that is complete for MM

E . However,

Theorem 18 The problem of computing a

smalles complete test suite for some fault model

MME is NP-hard.

Hence we settle with an easier problem. The

problem we want to solve is to �nd a test suite

that is complete for a fault model and which does

not contain genuine subsets that are also com-

plete for the same fault model. Such a test suite

we call minimal complete.

De�nition 19 A test suite T is minimal com-

plete for MME if T is complete for MM

E and if

no T 0 � T is complete for MME .

Because any test in a minimal complete test suite

T for a fault modelMME detects at least one fault

in MME it holds that T contains no more tests

that the number of faults in MME .

Given a fault model MME and given a test suite

T 2 hTM� i�2E , the problem of determining a min-

imal complete test suite can, due to Th. 17, be

rephrased as a set-covering problem. That is, we

have to cover the set E by sets in

f�(hTM� i�2E ) j� 2 Tg

and in particular we have to cover E by as few of

these sets as possible. In other words, we have

to �nd a smallest possible subset of T with a

cover E . The set-covering problem however is

known to be NP-complete, although approxima-

tive methods for computing set-covers exists (see

e.g. [6]). Our contribution in the remaining part

of this section may be regarded as an approx-

imative and greedy method for computing set-

covers in that we outline a general procedure for

obtaining minimal complete test suites. In Sec. 7

the procedure is shown to have polynomial time

complexity. First however we need some termi-

nology.

De�nition 20 Let hTiii2I be a family of sets of

tests. Then �hTiii2I is the smallest set of sets of

tests satisfying that T 2 �hTiii2I if T 2 hTiii2Iand if

8� 2 T: 9i 2 I: T \min(Ti) = f�g (2)

That is, T 2 �hTiii2I if any Ti has a test in T

and if any test in T uniquely among the tests in

T belongs to the smallest tests in some Ti. If

T 2 �hTiii2I we say that T is minimalized with

respect to the family hTiii2I .

For a family of non-empty set of tests hTiii2Ia minimalized set of tests may be constructed

by �rst selecting a set T 2 hmin(Ti)ii2I . Then

tests in T not satisfying Eq. 2 are iteratively re-

moved from T one at a time until the remaining

tests in T satisfy the equation. For instance, let

M be the FSM de�ned in Fig. 3 and let T be

the test suite faa; ab; ac; acda; acdeaag then T

belongs to hTM� i�2fa;b;c;d;eg, but T does not be-

long to �hTM� i�2fa;b;c;d;eg because faa; ab; acg 2

min(TMa ) and therefore Eq. 2 is not satis�ed by

aa. It turns out that fab; ac; acda; acdeaag is

minimalized with respect to hTM� i�2fa;b;c;d;eg.

If T 2 hmin(Ti)ii2I we let �hTiii2I(T ) denote a

minimalized subset of T with respect to hTiii2I .

�hTiii2Ican be considered a function

�hTiii2I: hmin(Ti)ii2I ! �hTiii2I

because the resulting set of tests can be con-

structed deterministically as outlined above if we

presuppose some lexicographical ordering on the

set of tests according to which tests are consid-

ered for removal.5

For any family of set of tests hTiii2I we next de-

�ne the functions HhTiii2I, GhTiii2I

, and FhTiii2I

that are used for computing minimal complete

test suites.

5In this paper we do not consider the problem of com-

puting a smallest minimalized subset of T 2 hmin(Ti)ii2I

with respect to hTiii2I .

84

Page 95: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

De�nition 21 De�ne for Ti � E�, i 2 I the

function HhTiii2I: hmin(Ti)ii2I ! 2

E� by

HhTiii2I (T ) =

�; if T = ;

T 0 otherwise

where T 0= �hTiii2I0

(max (T )) and where I 0 =

fi 2 I j9� 2 max (T ): � 2 min(Ti)g.

That is, HhTiii2I(T ) returns a minimalized set

of tests with respect to the family to which

the largest tests in T belong. For instance, if

M is the FSM de�ned in Fig. 3 and if T is

the test suite faa; ab; acg that belongs to the

family hmin(TM� )i�2fa;b;cg then HhT�i�2fa;b;cg

(T )

equals fab; acg. If T is faa; ab; ac; acda; acdeaag

that belongs to hmin(TM� )i�2fa;b;c;d;eg then

HhT�i�2fa;b;c;d;eg(T ) is facdeaag.

De�nition 22 De�ne for Ti � E�, i 2 I the

function GhTiii2I : hmin(Ti)ii2I ! 2E� by

GhTiii2I (T ) =

�; if T = ;

T 00 otherwise

where T = f�i j i 2 Ig, T 0= HhTiii2I (T ), and

T 00= f�i j i 2 I n T 0

(hTiii2I)g.

That is, on input f�i j i 2 Ig 2 hmin(Ti)ii2Ithe function GhTiii2I returns a subset of this

set. The tests not returned are those that be-

long only to family members which are cov-

ered by T 0. T 0

is a minimalized set with re-

spect to the family to which the largest tests

in f�i j i 2 Ig belongs. As an example, let-

ting M be the FSM de�ned in Fig. 3, if T is the

test suite faa; ab; ac; acde; acdeaag that belongs

to hmin(TM� )i�2fa;b;c;d;eg then GhT�i�2fa;b;c;d;eg(T )

equals fabg. The reason why is, as shown

above, that HhT�i�2fa;b;c;d;eg(T ) is facdeaag and

because the cover of acdeaa with respect to

hT�i�2fa;b;c;d;eg is fa; c; d; eg as shown in the pre-

vious section.

The following lemma ensures that the function

FhTiii2Ide�ned below is well de�ned.

Lemma 23 GhTiii2I (T ) 2 hmin(Ti)ii2I0 where

I 0 = I n (HhTiii2I(T ))(hTiii2I).

De�nition 24 De�ne for Ti � E�, i 2 I the

function FhTiii2I: hmin(Ti)ii2I ! 2

E� induc-

tively by

FhTiii2I (T ) =

�; if T = ;

T 0 [ FhTiii2I0(T 00

) otherwise

where T 0= HhTiii2I (T ), T 00

= GhTiii2I (T ), and

I 0 = I n T 0(hTiii2I).

The functions may as results give minimal com-

plete test suites.

Theorem 25 If T 2 hmin(TM� )i�2E then

FhTM� i�2E

(T ) is minimal complete for MME.

Intuitively, a minimal complete test suite for a

fault model is constructed by �rst selecting a set

of tests T containing a smallest test for each fault

in the fault model. The test for a fault is selected

from the set of tests that characterizes the fault.

Secondly, all the longest tests in T are collected

and among those some tests may be eliminated

resulting in a minimalized set of tests T 0that

will be contained in the resulting test suite. All

faults in the model that may be detected by at

least one of the tests in T 0are disregarded and

not considered further in the computation. The

process is repeated for the faults still to be dealt

with until no fault in the model needs consider-

ation.

For instance, letting M be as de�ned in Fig. 3

and let T be faa; ab; ac; acda; acdeaag, then

whenever I = fa; b; c; d; eg

FhTM

i ii2I(T )

= HhTM

i ii2I(T ) [ F

hTMi ii2fbg

(GhTM

i ii2I(T ))

= facdeaag [ FhTM� i�2fbg

(fabg)

= fab; acdeaag

that is, �rst acdeaa is selected as the longest test

and since the cover of acdeaa is fa; c; d; eg the re-

cursive call only has to consider the fault M [b].

85

Page 96: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

( 1) For each s 2 S; associate (�s; j�sj) to s where �s

is a shortest test such that s = sM�s .

The unreachable states are removed from S.( 2) For all � 2 E 0 and s 2 S; if s is �-active then

associate (�s�; j�s�j) to �.( 3) For each � 2 E 0; walk through the pairs associated

to �, select one (��; i�) where i� � i for any pair(�; i) associated to �. If for some � 2 E 0 no pairs

are associated to � let (��; i�) be (�;1). Let ~Tbe f(��; i�; �) j� 2 E 0g.

( 4) Compute B1. For each (s; s0) 2 B1 associate a pair(�; 1) such that s(�) 6= s

0(�).( 5) For i = 2; : : : ; 2jSj � 1 compute Bi. If (s1; s2) 2 Bi

and no pair is associated to (s1; s2) then associate(��; i) to it for some � where (�; i� 1) is associatedto (s1�; s2�) 2 Bi�1.

( 6) For all � 2 E 0 and s 2 S; if some (�; i) is associated

to (s; s�) and if j�sj+ 1 + i < i0 where (�0; i0; �) 2 ~T

then replace (�0 ; i0; �) by (�s��; j�sj+ 1 + i; �).

( 7) If i = 1 for some (�; i; �) 2 ~T then terminate withan error.

( 8) Compute a partition ~Tl1 ; : : : ;~Tln of ~T where ~Tli is

f(�; li; �) j(�; li; �) 2 ~Tg and l1 < l2 < : : : < ln.(9) For i = n; : : : ; 1; compute

(a) Ei = f� j9�: (�; li; �) 2 ~Tlig, and

(b) Tli = �hTM�

i�2Ei(f� j9�: (�; li; �) 2 ~Tlig),

(c) and remove from each ~Tlj where lj < li all

(�; j; �) if � 2 Tli(hTM

�i�2E0 ).

(10) Return Tl1 [ : : : [ Tln .

Figure 5: A polynomial time algorithm for com-

puting minimal complete test suites.

7 Complexity

In this section we argue that the problem of com-

puting a minimal complete test suite has poly-

nomial time complexity. The correctness of the

algorithms is due to Theorem 25, although the

family of sets of tests that characterizes fault

in the fault model is never explicitly computed,

only a smallest test in each family member is

searched for. Recall that in general it would be

impossible to compute a set that characterizes a

fault because the set may be in�nite.

The algorithm is presented in Fig. 5. Its input is

an FSM M = (S; E ;; �; sM ) and a set of inputs

E 0 � E . In the �rst part on the algorithm (line

1-6) it computes a set ~T such that whenever M

is �-sensitive for all � 2 E 0 then

T = f� j9�; i: (�; i; �) 2 ~Tg

belongs to hmin(TM� )i�2E 0 . If M is not �-

sensitive for some � 2 E 0 then an error is re-

ported in line 7 and the algorithm terminates,

otherwise (line 8-10) FhTM� i�2E0

(T ) is computed.

The reason why T 2 hmin(TM�)i�2E 0 if M is

�-sensitive for all � 2 E 0 is as follows. For all

� 2 E 0, if there exists �-active states in S then

after line 1-3 ~T contains (��; j��j; �) where �

is a smallest test from sM to an �-active state.

Then in line 4-5, all inequivalent pairs of states

are associated with a shortest test that distin-

guishes them. It is obvious that if (s1; s2) 2 Bi

for some i and if no pair is associated to (s1; s2)

then (s1; s2) 62 Bj for all j < i. Hence s1 �j s2for all j < i due to Lem. 4, so the test associated

to (s1; s2) indeed is shortest possible. Note that

according to Lem. 3 at most 2jSj � 1 iterations

are needed in order to �nd a shortest test that

distinguishes any two inequivalent states.

The information computed in line 4-5 is used in

line 6 where ~T may be updated. Updating takes

place whenever (�0; i0; �) 2 ~T but for some s,

(s; s�) is associated with a test � such that j�sj+

1 + j�j < i0. Hence updating takes place in case

there exists an �-distinguishable state s where s

and s� are distinguishable by some test � such

that �s�� is shorter that the current test kept

with � in ~T . If updating takes place then the

last event in �s�� cannot be �. 6

Formally, in order to conclude that � 2

min(TM

�) for any (�; i; �) 2 ~T we take advan-

tage of the following lemma.

Lemma 26 min(T1) = min(T2) whenever

T1 = f��0 jM(��0) 6= M(��0#�); �0 6= �g

and

T2 = f�1��2�0 j

M(�1��2�0) 6= M(�1�2�

0); �0 6= �g

6Updating takes place only if M(�s��) 6= M(�s�).

Suppose in order to obtain a contradiction that �s�� =

�s��0� for some �0. Then either sM

�s��0

or sM�s�

0

is an

�-active state. However then �s�� would not be shorter

than the current test kept with � in ~T .

86

Page 97: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

From Lem. 26 it then follows that min(TM� ) may

be de�ned as min(T1 [ T2) where T1 = f�� j

M(��) 6= ;g and T2 is f�1��2�0 jM(�1��2�

0) 6=

M(�1�2�0); �0 6= �g. That is, any � 2 min(TM� )

either is a shortest test to an �-active state to

which � is appended (as computed in line 1-3)

or a concatenation ���0 where � is a shortest

test from sM to an �-distinguishable state s and

where �0 is a shortest test, not ending with �,

that distinguishes s and s� (as computed in line

4-6).

The total time complexity of the algorithm

is O(jSj3jEj + jSj2jEjjj + jSjjE 0j2jj) (see Ap-

pendix A.8).

8 Conclusion

In this paper we have outlined the framework,

connectivity testing, for the testing of embed-

ded systems. In contrast to for instance con-

formance testing the approach is focused on de-

tecting errors manifested as faults in the inter-

face between the two system components: the

hardware and the embedded software. Since we

assume the software to be fault free the errors

we address belong to the hardware, or probably

software drivers not being part of the software

model. Formally we choose to model errors by

means of a fault model for disconnected inputs.

A test suite is complete if it detects all faults in

the fault model, and if no test in the suite is use-

less. We have proven that the problem of com-

puting a smallest possible complete test suite is

NP-hard. Therefore we devised approximative

greedy polynomial time algorithms that com-

putes minimal complete test suites. A test suite

is minimal complete if all its tests are needed

in order to make it complete. Importantly, the

test suites contain no more tests than the num-

ber of faults in the fault model and the length

of any test in a test suites is bounded by twice

the number of states in the FSM speci�cation

of the software (in practice the length may be

much smaller of course as demonstrated by the

experiments carried out).

Other types of fault models than the ones re-

ported in this paper may be of interest. For

instance, the single-fault fault models presented

here may be generalized to multi-fault fault mod-

els. This kind of fault model are dealt with in

[7], although no algorithms for test generation

is provided there. Fault models and algorithms

dealing with redirected inputs and outputs are

presented in [9] and [8]. Mixing input and out-

put faults is yet another research topic.

A Appendix

A.1 Proof of Lem. 6

Let M be an FSM with state set S. Let S 0 be

the set of states in M [�]. By de�nition of M [�]

there exists a 1 : 1 mapping f : S ! S 0, such

that f(sM) = sM [�] and whenever � 6= �0 then

s�0=o�! s0 is a transition in M only if f(s)

�0=o�!

f(s0) is a transition in M [�].

We prove that if � 6= �0 then s(��0#�) =

f(s)(��0) for all s 2 S. Hence in particular

sM(��0#�) = sM [�](��0) if � 6= �0 and therefore

M(��0#�) = M [�](��0) if � 6= �0. The proof is

by induction in the length of �.

Let �0 be some event such that � 6= �0 and let

s 2 S.

Basis: (� = �) Consider s�0=o�! s0. Then f(s)

�0=o�!

f(s0) so s(�0) = f(s)(�0) and since �0#� = �0 it

follows that s(�0#�) = f(s)(�0).

Step: Suppose that s(��0#�) = f(s)(��0) for all

� with j�j � n (IH). Let � = �00�0 for some �00

and some �0 with j�0j = n.

If �00 = � then ��0#� = �0�0#� so s(��0#�) =

s(�0�0#�). Then by IH we obtain s(�0�0#�) =

f(s)(�0�0). Moreover, since f(s)�00

= f(s) by

de�nition of M [�] it follows that f(s)(��0) =

f(s)(�0�0) and therefore s(��0#�) = f(s)(��0).

87

Page 98: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

If �00 6= � then consider s�00

. Due to the property

of f , f(s)�00

= f(s�00

). Then by IH, s0(�0�

0#�) =

f(s0)(�0�

0) and therefore s(��0#�) = f(s)(��0).

A.2 Proof of Lem. 9

(If) Suppose M is �-sensitive. If M is �-active

then M(��) 6= ; for some �. However, since

M [�](��) = ; then M 6� M [�]. If M is �-

distinguishable then for some �, sM� 6� sM

��.

Suppose, in order to obtain a contradiction, that

M �M [�]. Then sM � sM [�], so sM

� � sM [�]

�,

and sM�� � s

M [�]��. By de�nition of M [�],

sM [�]

� = sM [�]

�� and then, since � is an equiv-

alence relation, sM� � sM

��. Hence we obtain

a contradiction.

(Only if) Suppose M is not �-sensitive. That

is, M is neither �-active nor �-distinguishable.

Let f be the mapping introduced in Sec. A.1. It

is suÆcient to prove for all s 2 S that s(�) =

f(s)(�) for all �. The proof is by induction in

j�j � 1.

Basis: (j�j = 1) Let s be any state and let

� = �0 for some �

0. If �0 6= � then due to

the properties of f , s(�0) = f(s)(�0). If �0 = �

then because M is not �-active it follows that

s(�0) = ;. From the de�nition of M [�] we con-

clude that also f(s)(�0) = ;.

Step: Assume for all s and for all � with j�j <

n + 1 that s(�) = f(s)(�) (IH). Let s 2 S and

let � = �0�

0 for some �0 and some �0 with j�0j =

n. If �0 6= � then due to the property of f ,

f(s)�0

= f(s�0

). Hence, since s(�) = s�

0

(�0) and

since by IH s�

0

(�0) = f(s�0

)(�0), it follows that

s(�) = f(s)(�). If �0 = � then because M is

not �-distinguishable it must be that s � s�

0

.

From the de�nition of M [�] we infer that f(s) =

f(s)�0

. It then follows that s(�) = s(�0) and that

f(s)(�) = f(s)(�0). Hence, since by IH s(�0) =

f(s)(�0), we conclude that s(�) = f(s)(�).

A.3 Proof of Lem. 14

Suppose applyM(M [�]; �) = fail . Then for some

�0 � �, M(�0) 6= M [�](�0). Hence from Corol-

lary 7 it follows that �0 6= �0#�, so �

0 must con-

tain at least one �. Therefore �0 can be par-

titioned into �1��2 for some �1 and �2 where

�2 = �2#�. Then, if �2 = � it must be that

M(�1�) 6= ; because M [�](�1�) = ;. Hence,

�0 2 T

M

�. If �2 6= � then since M [�](�1��2) =

M(�1��2#�), due to Lem. 6, it follows that

�1��2 2 TM

�.

Suppose �0 � � for some �0 2 T

M

�. If �0 = �1�

andM(�1�) 6= ; then clearlyM(�0) 6= M [�](�0),

so applyM(M [�]; �) = fail . Otherwise, �0 = �1�0

and � 6= �0 such that M(�0) 6= M(�0#�), but

then since M [�](�0) = M(�0#�), due to Lem. 6,

it follows that applyM(M [�]; �) = fail .

A.4 Proof of Lem. 23

Follows from the de�nitions of the functions

GhTiii2IandHhTiii2I

, and the de�nition of a cover

of a set of tests with respect to a family hTiii2I .

A.5 Proof of Th. 25

Let MM

E 0be a fault model and let T belong to

hmin(TM

�)i�2E 0 . The proof is by induction in the

size of E 0.

Basis: If E 0 = ; the theorem holds vacuously.

Step: Let E 0 6= ;. Assume for all E 00 �

E 0 that whenever T0 2 hmin(TM

�)i�2E 00 then

FhTM� i�2E00

(T 0) is minimal complete forMM

E 00(In-

duction Hypothesis).

Soundness is preserved by subsets. Hence sound-

ness of FhTM� i�2E0

(T ) follows because T is sound

due to Theorem 17 and because FhTM� i�2E0

(T ) �

T .

In the rest of the proof we let T0 =

HhTM� i�2E0

(T ), T00 = GhTM� i

�2E0(T ), and E 00 =

88

Page 99: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

E 0 n T 0(hTM� i�2E 0). Due to Lem. 23 if followsthat T 00 2 hmin(TM� )i�2E 00 .

In order to prove exhaustiveness let M [�] 2

MM

E 0 . Hence � 2 E 0. Then either � 2 E 00 or� 2 T 0(hTM� i�2E 0). In the latter case, for some� 2 T 0 there exists �0 � � with �0 2 TM� , soapplyM(M [�]; �) = fail for some � 2 T 0 due toLem. 14. In the former case M [�] 2 MM

E 00 andbecause T 00 2 hmin(TM

�)i�2E 00 it follows by in-

duction that FhTM� i�2E00

(T 00) is exhaustive, hence

for some � 2 FhTM� i�2E00

(T 00) it must be that

applyM(M [�]; �) = fail

Finally, we prove minimality. The proof is bycontradiction.

Assume for some T0 � FhTM� i�2E0

(T ) that T0

is complete for MM

E 0. Moreover, let �0 2

FhTM� i�2E0

(T ) n T0. Since �0 2 FhTM� i�2E0

(T ) itfollows by the de�nition of FhTM� i

�2E0that either

�0 2 T 0 or �0 2 FhTM� i�2E00

(T 00). We prove thatboth cases leads to a contradiction.

Suppose �0 2 T 0. Then because T 0 2

�hTM� i�2E1 , where E1 is

f� 2 E 0 j9� 2 max (T ): � 2 min(TM� )g

it follows that T 0 \ min(TM� ) = f�0g for some� 2 E1. Since T0 is assumed to be com-plete there must exists �1 2 T0 such thatapplyM(M [�]; �1) = fail . Hence for some �2 �

�1, �2 2 TM� . Then j�0j � j�2j because �0 2

min(TM� ), but also j�0j � j�1j because �1 2 T

and �0 2 max (T ). Therefore �1 = �2 andj�0j = j�1j. Since T0 � FhTM� i

�2E0(T ) it must

be that either �1 2 T 0 or �1 2 FhTM� i�2E00

(T 00).

However, �1 62 T 0 because T 0\min(TM� ) = f�0g.Also, �1 62 FhTM� i

�2E00(T 00) because �1 2 max (T )

and max (T ) \ FhTM� i�2E00

(T 00) = ;. Hence weobtain a contradiction.

If �0 2 FhTM� i�2E00

(T 00), let M be

fM 0 2MM

E 00 japplyM (M 0; �0) = failg

Then in order for T0 to be exhaustive, it mustbe that for all M 0 2 M, there exists �M 0 2 T0

such that applyM(M 0; �M 0) = fail . Because ofLem. 14 and the de�nition of E 00 if follows that�M 0 62 T 0 for all M 0 2 M. Hence, since T0is assumed to be exhaustive, it must be thatfor all M 0 2 M, �M 0 2 FhTM� i

�2E00(T 00). But

then we have a contradiction since by induc-tion FhTM� i

�2E00(T 00) is minimal complete since

T 00 2 hmin(TM� )i�2E 00 .

A.6 Proof of Lem. 26

Let T1 = f��0 jM(��0) 6= M(��0#�); �0 6= �g

and let

T2 = f�1��2�0 j

M(�1��2�0) 6= M(�1�2�

0); �0 6= �g

It is suÆcient to prove that min(T1) � T2 andthat min(T2) � T1.

7

We �rst prove that min(T1) � T2. If T1 = ; weare done so suppose T1 6= ;. Let � 2 min(T1).Then � = �0�0 for some �0 and �0 where � 6= �0.Also, � = �1��2�

0 for some �1 and �2 because� 6= �#� since M(�) 6= M(�#�). Suppose, inorder to obtain a contradiction, that � 62 T2.ThenM(�) = M(�1�2�

0) for all �1 and �2 where� = �1��2�

0. Now, let �1 and �2 be suchthat � = �1��2�

0. Obviously, �#� = �1�2�0#�

so M(�#�) = M(�1�2�0#�). But then, since

M(�) 6= M(�#�), it follows that M(�1�2�0) 6=

M(�1�2�0#�). However, then �1�2�

0 2 T1 andwe obtain a contradiction because j�1�2�

0j < j�j.

Next we prove that min(T2) � T1. If T2 = ; weare done so suppose T2 6= ;. Let � 2 min(T2).Then � = �1��2�

0 for some �1, �2, and �0 where� 6= �0. If �#� = �1�2�

0 it follows by the def-inition of T2 that M(�) 6= M(�#�) and hence� 2 T1. Suppose instead that �#� 6= �1�2�

0. Let

7That for any two sets of tests T and T 0, min(T ) � T0

andmin(T 0) � T implies min(T ) = min(T ) can be shown

as follows. Let min(T ) � T0 and let min(T 0) � T . Sup-

pose, min(T ) 6= min(T ). Hence, without loss of gener-

ality, there exists � 2 min(T ) such that � 62 min(T 0).

However, since � 2 T0 it must be that there exists

�0 2 min(T 0) such j�0j < j�j. But, then since �0 2 T

and because � 2 min(T ) we obtain a contradiction.

89

Page 100: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

�1 = �11��12� : : : ��1m for some �11; : : : ; �1m,

where �1i = �1i#� for i = 1; : : : ;m. Let

�2 = �21��22� : : : ��2n for some �21; : : : ; �2n,

where �2i = �2i#� for i = 1; : : : ; n. Since ei-

ther �1 6= �1#� or �2 6= �2#� it must be that

either m > 1 or n > 1. Next, let

�0

0 = �11�12 : : : �1m�21�22 : : : �2n�0

�0

1 = �11��12 : : : �1n�21�22 : : : �2n�0

...

�0

n+m�2 = �11��12� : : :

: : : ��1n�21��22� : : : ��2n�0

that is, �0iis �1�2�

0 where the last n+m� i� 2

�'s have been removed. Note that �00 = �#�

and that �0n+m�2 = �1�2�

0. Since j�0ij < j�j

and because � 2 min(T2) it must be that

M(�0i) = M(�0

i�1) for all i = 1; : : : ; n +m � 2.

Hence M(�00) = M(�0n+m�2) and consequently

M(�#�) =M(�1�2�0). Therefore, sinceM(�) 6=

M(�1�2�0), M(�) 6=M(�#�) and hence � 2 T1.

A.7 Proof of Th. 18

The proof consists of establishing a polyno-

mial deterministic time reduction from the NP-

complete Directed Hamiltonian-Cycle problem

(see e.g. [6]). Actually, the reduction is to the de-

cision problem: Does MM

E have a smallest com-

plete test suite of size k? However, since if it is

easy to compute a smallest complete test suite

then it is also easy to determine the size of such

a test suite, and hence to decide the decision

problem. Or the other way around, if the deci-

sion problem is NP-hard then so is the problem

of determining a smallest complete test suite.

Let G = (V;E) be a directed graph. Let E =

f�v j v 2 V g such that if u 6= v then �u 6= �v.

Construct G0 by modifying G such that all edges

(u; v) are labelled �v. Hence any edge entering

a node v is labelled by �v . Also, for any ver-

tices u and v if (u; v) 62 E then add an edge

from u to u labelled by �v. Choose some vertex

vG

00 2 V and let fe1; : : : ; eng be the edges in G0

that enter vG

00 and that are labelled by �vG00. Let

= f!1; : : : ; !ng. Let G00 be G0 where e1; : : : ; en

are labelled by f!1g; : : : ; f!ng respectively and

where all other edges are labelled by the empty

set. Observe that G00 = (V;E00) may be consid-

ered an FSM MG00 = (V; E ;; E00

; vG00).

Clearly, G00 can be constructed from G in poly-

nomial deterministic time. The correctness of

the reduction follows from Lem. 27.

Lemma 27 G contains a Hamilton-cycle i�

there exists a smallest complete test suite for

MMG00

Eof size jV j.

Proof: SupposeG contains a Hamilton-cycle cy-

cle v1; v2; : : : ; vjV j; v1. Assume (without loss of

generality) that v1 = vG00 . Then in G00 (leaving

out the output labels)

v1

�0

1

�! v2

�0

2

�! : : : vjV j

�0

jV j

�! v1

for some events �01; �

02; : : : ; �

0jV j

. Due to the

construction of G00, E = f�01; : : : ; �0jV jg. Let

� = �01�

02 : : : �

0jV j

. Then � 2 TMG00

�0jV j

because

vG

00(�) 6= ; since �0jV j

= �0vG00

. Also, because

edges in G00 that are labelled by �v

G00 all are

labelled by distinct outputs or the empty out-

put it turns out that for all � 2 E , if � 6= �0jV j

then vG00(�) 6= vG00(�#�). Hence � cover E wrt.

hTMG00

� i�2E so according to Lem. 16 MMG00

Eis a

fault model. From Theorem 17 it follows that

f�g is complete for MMG00

E. Clearly, f�g is a

smallest complete test suite because all � 2 E

must occur in a test in order for a test suite to

be complete.

Suppose MMG00

Eis a fault model with a smallest

test suite T of size jV j. Then T covers E wrt.

hTMG00

� i�2E due to Lem. 16. Hence for all � 2 E

there is a test in T containing �. Then since

jT j = jEj and because only the event �vG00 may

cause output T contains only one test �. Finally,

in order for � to contain all � 2 E it must be that

� visits all vertices inG00, so therefore G contains

a Hamilton-cycle.

90

Page 101: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

A.8 Complexity

Consider the algorithm in Fig. 5. Line 1 is

O((jSj+ j� j) lg jSj) if a modi�ed version of Dijk-

stra's single-source shortest paths algorithm (see

e.g. [6]) is applied. Recall the functionality of

� , then the complexity of line 1 can be rewrit-

ten as O(jSjjEj lg jSj). Line 2 is O(jSjjE 0jjj)and both line 3 and 6 are O(jSjjE 0j). Line 4

is O(jSj2jEjjj) because s(�) 6= s0(�) is O(jj).For i > 2, computing Bi is O(jSj2jEj), hence line5 is O(jSj3jEj). Clearly, line 7, 8 and 10 are

O(jE 0j). The minimalizations in line 9 can be

performed as follows: For each (�; li; �) 2 ~Tli in

turn, remove it if �0 2 TM� for some other triple

(�0; li; �0) 2 ~Tli . Checking �

0 2 TM� is O(li+ jj)

because we have to check if M(�0) 6= ; and

�0 = �00� for some �00 or if �0 6= �00� for some �00

and M(�0) 6= M(�0#�). Hence the complexity of

all the minimalizations is O(�ni=1(jTli j

2(li+jj)))which is O(�n

i=1(jTli j2(jSj + jj))) becase li is

O(jSj). Then because O(�ni=1(jTli j

2)) = O(jE 0j2)it turns out that the complexity of the min-

imalizations is O(jE 0j2(jSj + jj)). The cover

of Tli is O(lijTli jjE0jjj): for each � 2 Tli and

� 2 E 0 we must check for all �0 where �0� � �

whether M(�0�) 6= ; and we must check for

all �0 where �0�0 � � and � 6= �0 whether

M(�0�0) 6= M(�0�0#�). Hence the complexity of

computing all the covers is O(�ni=1lijTli jjE

0jjj)which is O(jSjjE 0j2jj). All the removals are

O(�ni=1�

i�1j=1j

~Tlj j) which is O(jE 0j2). Hence the

complexity of line 9 is O(jSjjE 0j2jj). The total

complexity of the algorithm thus is O(jSj3jEj +jSj2jEjjj+ jSjjE 0j2jj).

References

[1] M. Abramovici, M.A. Breuer, and A.D. Fried-man. Digitial System Design and Testable De-

sign. Computer Science Press, 1990.

[2] A.V. Aho, A.T. Dahbura, D. Lee, and M.UUyar. An optimization technique for protocolconformance test generation based on uio se-quences and rural chinese postman tours. IEEETrans. on Comm., 39(11):1604{1615, Nov. 1991.

[3] E. Brinksma, R. Alderen, R. Langerak, J. van deLagemaat, and J. Tretmans. A formal approachto conformance testing. 2th Int. Workshop on

Protocol Test Systems, pages 349{363. ElsevierScience Publishers B.V., 1990.

[4] R. Cardell-Oliver and T. Glover. A practicaland complete algorithm for testing real-time sys-tems. FTRTFT'98, volume 1486 of LNCS, Lyn-gby, Denmark, Sep. 1998. Springer{Verlag.

[5] T.S Chow. Testing software desing models by�nite-state machines. IEEE Transactions on

Software Engeneering, 4(3):178{187, 1978.

[6] T.H. Cormen, C.E. Leiserson, and R.L. Rivest.Introduction to Algorithms. MIT Press, 1997.

[7] J.C. Godskesen. Fault models for embedded sys-tems. CHARME'99, volume 1703 of LNCS, BadHerrenalb, Sep. 1999. Springer{Verlag.

[8] J.C. Godskesen. Test generation for embeddedsystems with redirected inputs. Proc. of WS-

EST'99, NIST, Gaithersburg, USA, Nov. 1999.

[9] J.C. Godskesen. Test generation for embeddedsystems with redirected outputs. In Proceedings

of HLDVT'99, San Diego, November 1999.

[10] J.C. Godskesen. Two algorithms for generatingtests for embedded systems. In Proceedings of

ISCIS'99, Kusadasi, October 1999.

[11] G.J. Holzmann. Design and Validation of Com-

puter Protocols. Series in Computer Science.Prentice{Hall, Englewood Cli�s, NJ, 1991.

[12] Z. Kohavi. Switching and Finite Automata The-

ory. McGraw-Hill, 1978.

[13] D. Lee and M. Yannakakis. Principles and meth-ods of testing �nite state machines{ a survey.Proceedings of the IEEE, 84(8), August 1996.

[14] A. Petrenko and N. Yevtushenko. Fault detec-tion in embedded components. 10th Int. Work-

shop on Testing of Comm. Systems, Cheju Is-land, Korea, Sep. 1997. Chapman & Hall.

[15] A. Petrenko, N. Yevtushenko, G. v. Bochmann.Fault models for testing in context.FORTE/PSTV'96, Univ. of Kaiserslautern,Dept. of Inform., Oct. 1996. Chapman & Hall.

[16] J.G. Springintveld, F.W. Vaandrager, P.R.D'Argenio. Testing timed automata. Tech. Rep.CSI-R9712, Univ. of Nijmegen, Aug. 1997.

[17] J. Tretmans. A Formal Approach to Con-

formance Testing. PhD thesis, University ofTwente, 1992.

91

Page 102: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

92

Page 103: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

A Simple Approach to Testing Timed Systems

Sébastien Salva Eric Petitjean Hacène Fouchal

LERI-RESYCOM

Université de Reims Champagne-Ardenne,

UFR Sciences Exactes et Naturelles,

Moulin de la Housse, BP 1039,

51687 Reims Cedex 2, France

e-mail:{Sebastien.Salva, Eric.Petitjean, Hacene.Fouchal}@univ-reims.fr

Abstract

Conformance testing of timed systems is still a new �eld even it could help many

designer since a long time. This study presents an new approach to testing com-

plex systems having timing constraints. This technique aims to prove if any timed

system implementation respects some properties described by timed test purposes.

The region graph model (generated from timed automata model) is used for the

speci�cation of timed systems. The kernel of this method is the extraction of exe-

cutable timed test cases from the user timed test purposes. Then, these test cases

will be submitted to the implementation, by means of a speci�c architecture, and

the implementation reactions indicate us whether the implementation achieves the

timed test purpose or not.

Key-words : Timed automata, region graph, conformance testing, real-time

systems, test purpose, test execution.

1 Introduction

The design of complex and critical systems becomes more and more di�cult and

very expensive. Before industrial development, systems need to be tested. A large

part of the development e�ort is spent in this last step. For the near future, the main

challenge is to provide a solid theoretical framework as well as a useful, practical

and automated tools dedicated to testing systems (especially with their behavioral

and temporal aspects). In the last decade, some studies and tools have been used in

practice [BFG+00, CH96], but most of them are only used for academic experiments

[CKM92, CGPT95].

This paper copes with the conformance testing of complex timed systems. Con-

trary to many other studies on timed testing, we use the region graph model [AD94].

The main disadvantage is the generation of a region graph which is a hard task (ex-

ponential complexity on the number of clocks). But we prefer to use it since it has a

high expression power for timed systems and can be used in practice if the number

of clocks is low. We believe that real systems can be speci�ed by a reduced num-

ber of clocks [DY96]. Then, we extract executable timed test cases from timed test

purposes. A timed test purpose is a sequence of events required by a designer with

his own timing constraints. The extraction of timed test cases is performed by a

synchronous product between the test purpose and the speci�cation. The main aim

of this product is to select the periods of the test purpose which can be found on

93

Page 104: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

the speci�cation for the execution of an action. We show the execution of the timed

test cases on the implementation. This step is performed by building an execution

tree on which we highlight the set of actions to execute, the set of actions to observe

and their appropriate sets of moments. Our main care is to cover the entire region

where an action has to be submitted to the implementation, then the action will be

submitted at the starting moment of the region graph and at the ending moment

of the region. All these steps (except the execution) are being implemented in a

prototype timed testing tool.

This paper is structured as follows: the main works about the timed testing �eld

are cited in Section 2. In this section, we present also the usual models on timed

systems. Section 3 details all the main aspects about the derivation of timed test

cases. Section 4 is dedicated to the execution of test cases on the implementation.

The complexity of this methodology is expressed in section 5. Section 6, gives the

conclusion and some ideas about future works.

2 Background

The conformance testing on timed systems is still a new �eld. We will give a brief

overview on some studies of this area. We will talk about two models for timed

systems used since a decade.

2.1 Related work

There are many works dedicated to the veri�cation of timed automata [ACH94,

DOY94, DY95]. Some tools [DOTY95, BLL+98] have been developed for this pur-

pose. But some other studies proposed various testing techniques for timed systems.

[Kon95] deals with an adaptation of the canonical tester for timed testing and it has

been extended in [LC97]. In [CL97], the authors derive test cases from speci�cations

described in the form of a constraint graph. They only consider the minimum and

the maximum allowable delays between input/output events. [SVD01] gives a gen-

eral outline and a theoretical framework for timed testing based of the adaptation

of the classical testing techniques to timed systems. [ENDKE98] presents an adap-

tation of the Wp-method [FBK+91] to timed systems to a reduced model of timed

automata (grid automata). [COG98] presents a speci�c testing technique which sug-

gests a practical algorithm for test generation. [RNHW98] gives a particular method

for the derivation of the more relevant inputs of the systems. [PF99a] suggests a

technique for translating a region graph into a graph where timing constraints are

expressed by speci�c labels using clock zones. The last study [NS01], suggests a

selection technique of timed tests from a restricted class of dense timed automata

speci�cations. It is based on the well known testing theory proposed by Hennessy

in [DNH84]. As we can notice, there are di�erent ways to tackle the problem of

timed testing. All of these studies focuss on reducing the speci�cation formalism in

order to be able to derive test cases feasible in practice. In contrast to these studies,

we use thw region graph model but we don't extract all possible test cases we only

consider test cases derived from test purposes given by the user.

94

Page 105: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

2.2 Timed system models

2.2.1 Timed automata model

Timed automata [AD94] are graphs representing timed systems during their exe-

cutions. To represent time in a timed system, a set of clocks is associated to the

automaton. Each clock is represented by a real value (dense time representation)

and grows strictly monotonically. All clocks are set to 0 in the initial state. Clocks

can be reset on any transition. To execute a transition, all the clocks of the system

must satisfy the transition constraints.

Timed Input Output Automata (TIOA) are extended timed automata where

actions are divided into input ones and output ones.

A transition Si?x�! Sj, labeled by the input action "?x" models an input action

submitted by the environment. A transition Si!x�! Sj, labeled by the output action

"!x", represents an output action generated by the implementation.

An example of TIOA is illustrated in Figure 1.

S1 S2

S4

?b

!e?a

x<2y:=0

x<2x<2

S3

S5

?cy<2y:=0

!ax=2x:=0

?d x>=2

!e

Figure 1: An example of timed automaton

2.2.2 Region graph model

This model has been formally de�ned in [AD94]. A Region Graph is an equivalent

representation of a timed automaton where a state collects all the moments where

the system has the same behaviour. Clearly, a region graph state is composed of a

timed automaton state (representing the system behaviour) and a clock region (it is

a polyhedron representing the inequations of the state timing constraints). Finally,

we can say that in region graphs the timing constraints are moved to states. The

transformation algorithm of timed automata into region graphs is de�ned in [AD94].

The theoretical framework about this model is detailed in [AD94].

De�nition 2.1 (A region graph ) A region graph RG is a tuple

(�RG; SRG; s0

RG; RRG; CRG; ERG) where �RG is the set of actions, SRG is the set of

states, s0RG is the initial state, RRG is the set of clock regions of RG, CRG is the set

of clocks, ERG is the transition relation de�ned as:

� (s; s0; a) from state s to state s0, labeled with the symbol a. s is a tuple (x;R)

where x is a state of the initial timed automaton and R is the clock region

during which a can be executed. s0 is a tuple (x0; R0) where x0 is a state of the

initial timed automaton and R0 is the reached clock region.

95

Page 106: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� (s; s0; Æ) from state s to state s

0, representing the elapse of time, needed to

reach the clock region R0 from R.

De�nition 2.2 (A state clock region) Let RG a region graph as de�ned below.

Let s a state of RG. There exists only one clock region, denoted CReg(s), associated

with this state.

In order to reduce the state explosion problem, some works have focused on the

reduction and the minimization of the region graph model [YL93, ACH+92, SV96].

The aim of [YL93, ACH+92] is to generate the portion of the minimized region graph

that is reachable in polynomial time. That is, all clock regions, in which the same

actions can be executed, are gathered into one clock region, i.e., the state number is

strongly reduced, what decreases validation costs.

3 Test cases derivation

In the classical conformance testing techniques (in the protocol engineering area),

there are two main techniques :

� the automatic test case generation methods which are able to derive all the

possible test cases of the whole system (the Unique Input/Output technique

[SD88], the W technique [Cho78], ...). Here, systems are in general described

by the Input/Output Finite State Machine model (IOFSM).

� the test purpose based methods which derive test cases from the test purpose

given by the designer. But here, systems are usually speci�ed by the Labeled

Transition System model (LTS) [Bri87, Tre96].

In the present study, we suggest a testing technique based on timed test purposes.

We will de�ne the concept of Timed Test Purpose (TTP), which will express the

user needs. And then, we will show how to extract test cases by using a timed

synchronous product between the speci�cation and the test purpose.

3.1 Timed test purpose

In classical (untimed) test purpose based methodologies, a test purpose is an abstract

description of the speci�cation. It helps the designer to choose behaviours to test

and then to reduce the speci�cation exploration. A test purpose is a graph where

�nal states may be either accepting states (the purpose is reached) or refusing states

(behaviour parts which would be rejected). It must contain events which should be

found on the speci�cation.

For timed systems, test purposes must also contain timing properties. We de�ne

such a purpose as a Timed Test Purpose (TTP).

De�nition 3.1 (A Timed Test Purpose) A timed test purpose TTP is de�ned

as a tree. Each path from the root expresses a partial trace on the speci�cation.

The nodes do not need to have the same labels than the speci�cation ones.

An example of a timed test purpose required on the system described in Figure

1 is given in Figure 2. We should notice that timed test purposes are not parts of

the speci�cation, but are sequences containing behaviour and timing properties of

the speci�cation.

96

Page 107: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

S1 S2 Accept!a !e

x=2x:=0

x<1

Figure 2: A Timed Test Purpose

Among many works dealing with automatic test purpose generation we can cite

[CCKS95, CGPT95, PLC98]. No one deals with the region graph model, and most

of them do not consider the time aspect.

3.2 Testing hypothesis

The following assumptions about the speci�cation and the IUT must be satis�ed for

our methodology.

� Since we will use the region graph model, we should deal carefully with the

clock regions. Then the clock regions to use in test purpose will be built with

the same clocks than the speci�cation ones. But the test purpose clock regions

have not to be as the speci�cation ones. So, the speci�cation and the IUT

must have the same number of clocks.

� The speci�cation must be timed deterministic on the set of alphabet. That is,

from any state, we cannot have two outgoing transitions labeled with the same

symbol, whose timing constraints are satis�ed simultaneously.

� From any state, we cannot have an outgoing transition, labeled with an input

action and an outgoing transition, labeled with an output action, whose timing

constraints are satis�ed simultaneously.

3.3 Test case generation

Test cases, containing a timed test purpose and satisfying the speci�cation will be

generated in order to be applied to the IUT.

Test cases are generated from a kind of intersection of the timed test purpose

TP and the speci�cation S, de�ned as a timed synchronous product between TP

and S. This operation generates a graph including TP and respecting the timing

and the behaviour properties of S.

The di�erent steps of this methodology are presented more precisely below. The

speci�cation S and the test purpose TP are modelled by the timed automata model:

� The whole speci�cation is not necessary, since the designer checks only a part of

it. So, transition sequences of S, containing all the actions of the test purpose,

in the same order, are �rst extracted and named TS1(S); :::; TSn(S). If this set

is empty, the process terminates and the following steps cannot be performed.

� All the sequences TS1(S); :::; TSn(S) and TP are translated into region graphs

named respectively RG(TS1(S)); :::; RG(TSn(S)) and RG(TP ).

� Each region graph is then minimized, using the algorithm described in [ACH+92],

and named RGMin(RG(TS1(S))); :::; RGMin(RG(TSn(S))) and

RGMin(RG(TP )).

� Each minimized region graph is synchronized with the timed test purpose. The

de�nition of the timed synchronous product is given in section 3.4.

97

Page 108: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� From each synchronous product we extract all the possible paths which are

transformed in timed test cases.

From the timed automaton illustrated in �gure 1, we obtain, before the syn-

chronous product, a sequence of transitions which generates the clock regions on

Figure 3 and the corresponding region graph is given on Figure 4.

R4

R3

R5

R6

2

2

R1

R2

Figure 3: Clock regions obtained from the speci�cation

S1R1

S2R1

S2R2

?b δ S3R3

S2R1

!a ?c S4R1

!e

Figure 4: The speci�cation region graph

In the same way, we obtain from the test purpose, illustrated in Figure 2, the

clock regions of Figure 5 and the region graph of Figure 6.

R3R2R1

210

Figure 5: Clock regions obtained from the test purpose

3.4 Timed Synchronous Product

The timed synchronous product between two transitions s1A�! s2 (of a part of the

speci�cation S) and s0

1

A�! s

0

2(of the timed test purpose TP ), labeled with the same

symbol A, can generate di�erent synchronized clock regions, depending on CReg(s1)

and on CReg(s0

1).

The di�erent types of synchronized clock regions are:

� PASS region:

The clock region Rpass gathers clock valuations satisfying the execution of

the speci�cation action A, and the test purpose constraints, that is, the clock

valuations which belong to RS and RTP . And if an action is executed at

98

Page 109: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

S1R1

S1R2

S1R3

S2R1

!aAccept

!eδδ

Figure 6: Region graph obtained from the test purpose

clock valuations of the PASS region, then the implementation conforms either

to the speci�cation or to the test purpose. If the PASS region is empty, an

INCOHERENT one will be obtained.

� INCONCLUSIVE region:

The clock region Rinconclusive represents clock valuations which satisfy the exe-

cution of A in the speci�cation, but not the execution of A in the test purpose.

If, A is executed in this region, the implementation respects the speci�cation,

but its behaviour does not match with the test purpose. Rinconclusive con-

tains clock valuations of RS except clock valuations of Rpass, and is denoted

RS=Rpass.

� FAIL region:

This region represents all of the clock valuations which do not satisfy the

execution of A in the speci�cation. In this case, if A is executed, in this region,

the implementation is faulty.

� INCOHERENT region:

This is a sub-region of the FAIL region. It represents the clock valuations

satisfying the execution of A in the test purpose, but not in the speci�cation.

This region is INCOHERENT since the IUT is still faulty while it satis�es the

execution of A in the test purpose. This happens if we synchronize two clock

regions in the situation that no clock valuation belongs to both clock regions

simultaneously. This region is represented by RTP=RS .

��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

��������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������

������������������������������������������������������������������������

������������������������������������������������������������������������

��������������������

��������������������

��������������������

��������������������

������������������������������

Pass Region

Inconclusive Region

Incoherent Region

Fail Region

Figure 7: The regions obtained from a timed synchronous product

Figure 7 shows an example of regions which can be generated from a timed syn-

chronous product of two clock regions with two clocks. The Timed synchronous

product between a part of the speci�cation S and a test purpose TP , is inspired by

the de�nition of the product of two ETIOSM (Extended Timed Input Output State

Machine which are Timed automata with non-temporal variables) [Lau99, PLC98].

In the following, we will consider two region graphs, a part of the speci�cation

(named S) and the test purpose (named TP ). The resulting product is called SP .

We will show in the following how to derive all the paths of this synchronous product.

99

Page 110: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Algorithm

INPUT:

TP(test purpose), S(speci�cation part), PTP (set of TP paths), PS(set of S paths)

OUPUT:

SP(set of paths of the synchronous product)

BEGIN:

countSP := 0

FOR countTP = 0 TO LENGTH(PTP)

/* computation of all TP paths */

currentTP := PTP[countTP]

Spaths:= search (currentTP, S)

1. FOR countpath=0 TO LENGTH(Spaths)

path:=Spaths[countpath]

countTR:=0

2. FOR countTR=0 TO LENGTH(path)

tp[countTR].Label := path[countTR].Label

tp[countTR].pass := CReg(path[countTR].StartingState)

tp[countTR].inconclusive := ;

ENDFOR

lengthTP:=countTR

countTR:=0

3. FOR count=0 TO LENGTH(currentTP)

label:=currentTP[count].Label

4. WHILE (label different tp[countTR].Label) countTR := countTR + 1

tp[countTR].inconclusive := tp[countTR].pass / CReg(currentTP[count].StartingState)

tp[countTR].pass := tp[countTR].pass \ CReg(currentTP[count].StartingState)

ENDFOR

SP[countSP].length := lengthTP

SP[countSP].tp := tp

countSP := countSP + 1

ENDFOR

ENDFOR

This algorithm can be commented as follows:

1. The tp path is a partial path of the speci�cation, then we extract in this loop

all the speci�cation paths containing a tp path;

2. The tp is �rst set with the transition from the speci�cation path. Each transi-

tion is labeled by a tuple (label; pass; inconclusive). label is deduced from the

transition ts of the speci�cation. pass is the region of the starting state of ts.

inconclusive is set to the empty set.

3. This loop looks for the common transitions between tp and the speci�cation.

Here the pass region is set to the intersection between the speci�cation region

and the test purpose region. The inconclusive region is set with the speci�ca-

tion region less the test purpose one.

4. This loop provides to skip the transitions which are found on the test purpose

since the test purpose is a partial path of the speci�cation path.

Finally, test cases are all the paths of the synchronous product.

100

Page 111: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

We should mention that, the synchronous product may also generate a test case

where the regions R1 and R2 of two successive states s1 and s2 are not time successor.

In this case, it could be di�cult to test any action in R2: this clock region is not

always reachable by the system clocks. This aspect is illustrated by the synchronous

product of the �gure 9 between the two timed automata of the �gures 4 and 6.

R4

R3

R5

R6

R1

1

1

2

2

R1’

R2

Figure 8: The obtained clock regions from the synchronous product

S1R1

S2R1

S2R2

?b δ S3R3

S2R1’

!a ?cAccept

!e

PASS(R1)I(0)

PASS(R2)I(0)

PASS(R3)I(0)

PASS(R1’)I(R1 / R1’)

Figure 9: The obtained test case

4 Test Execution

4.1 Test Architecture

In order to apply the test cases on the implementation, a speci�c architecture for

timed systems is described in [PF99b].

In this architecture, no assumption is done about how time is modeled inside

the IUT (Implementation Under Test). The tester is composed of two parts, com-

municating with one another : the clock part, which contains the clocks appearing

in the speci�cation, and the behaviour part, whose role is to communicate with the

implementation through the single PCO (Point of Control and Observation), i.e. to

send inputs to the IUT and receive outputs from it.

The behaviour part of the tester may ask the clock part at any time for the value

of one or more clocks and receive instantaneously the answer, this communication

is internal to the tester.

On the other hand, the actions to be performed on the clocks, i.e the resets, do not

involve the implementation anymore. The tester performs the resets independently

from the IUT. During the testing process, temporal and behaviour properties of the

implementation are checked, by means of test cases. These ones contain actions

101

Page 112: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

which must be checked in the PASS region. Unfortunately, clock regions are dense

representation of time, which contain in�nite tuples of values. Therefore, we cover

the time space by the application of the following three rules:

� Let "?A" be an input action, a PASS region R, and let vinit 2 R be the �rst

clock valuation reached by the clocks. We propose that the tester sends "A"

to the IUT as soon as possible and the latest possible, that is for vinit and the

last clock valuation reached by the clocks vfinal 2 R. In order to reach vfinal,

an elapse of time (denoted wait) is necessary and it must be computed on the

�y during the test, on account of the dynamic behavior of the IUT.

� Let "!A" be an output action to test, R a PASS region and R0an INCON-

CLUSIVE region. The tester waits the reception of the symbol "A" from the

IUT. If it is done in the region R, then the IUT respects the speci�cation and

the test purpose. But if it is done only in the INCONCLUSIVE region, the

speci�cation is respected but not the test purpose.

� For an elapse of time "Æ", allowing to reach the next clock region, no test is

needed. However, the tester must compute on the �y the duration of Æ and

must wait as long as this duration (section 4.2.1 for its calculation)

Consequently, we consider that input actions are checked for two clock valuations

within the PASS region. So, a test case must be applied to the IUT 2ntimes with n

the number of input actions. To express all of these cases, we develop the execution

of the test case into a tree, called Execution Tree.

4.2 Execution Tree

We suppose that we have a test sequence obtained from the synchronous product

of two region graphs. The following algorithm transforms such a sequence into an

Execution Tree. This tree is composed of states and the edges of the graph region:

� send(A) represents the sending of the input symbol ?A by the tester,

� recv(A) represents the sending of the output symbol !A by the IUT,

� wait represents the time needed to reach vfinal by the IUT clocks in a clock

region,

� Æ represents the elapse of time needed to reach the next clock region.

102

Page 113: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Algorithm

Const-tree(SEQ,sA;PASS(R);INCONCLUSIV E(R0)�����������������������!

Rts

0)

IF A=Æ /* Elapse of time Æ

THEN

(Add

�! s

0

Cons-tree(SEQ,next transition of SEQ)

IF A=?I /* Input action

IF two clock valuations can be reached by the tuple of clocks

THEN

8>>>>><>>>>>:

Add a branch�!

wait��!

send(I)����!

Rts

0

Cons-tree(SEQ,next transition of SEQ)

Add a second branch�!

send(I)����!

Rts

0

Cons-tree(SEQ,next transition of SEQ)

ELSE

(Add

�!

send(I)����!

Rts

0

Cons-tree(SEQ,next transition of SEQ)

IF A=!O /* Output action

THEN

8<: Add a branch

recv(O);PASS(R);INCONCLUSIV E(R0)��������������������������!

Rts

0

Cons-tree(SEQ,next transition of SEQ)

Finally, each branch of this tree can be given to the tester. The elapse of time

wait and Æ are computed as follows:

4.2.1 The calculation of Æ and wait

Consider the sequence s1A;R1

���!

Rts2

�! s3

B;R2

���!

Rts4. We need to calculate the elapse of

time needed to reach R2 from any clock valuation vinit = (v1; :::; vn), reached after

executing the action "A", that is the minimal value d such as vinit + d 2 R2.

R1

R2

Reachable Vfinal

Time elapsing

Vinit

Figure 10: Reaching another clock region in vfinal from vinit

As, the clocks grow with the same manner and strictly monotonically, they take

103

Page 114: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

as values the solutions of the equation

8<:

x1 � x2 = v1 � v2

:::

xn�1 � xn = vn�1 � vn

So, vfinal, reached by the clocks in R2, is unique and is obtained by resolving

the system of inequations

� =

8>><>>:

Inequations of R2

x1 � x2 = v1 � v2

:::

xn�1 � xn = vn�1 � vn

Finally, the elapse of time Æ equals to the di�erence between vinit and the minimal

solution vfinal of �, minus the time value �, necessary for the resolution of the

previous system of inequations. The example given in Figure 10 illustrates this

aspect.

In the same manner, we can compute the elapse of time needed to reach a clock

valuation of a clock region, denoted wait.

5 Complexity

In this section, we will analyze the complexity of each step of our technique. These

calculations are di�cult to express with accuracy since they depend on the number

of states, actions and clocks of the the timed system.

� Extraction of speci�cation parts: The complexity to obtain sequences of

the speci�cation, including the test purpose is proportional to M �K (M : the

number of states of the test purpose, K: the number of transitions of the test

purpose). In the worst case, it is necessary to build a tree on S which contains

all the transitions of S.

� Region graph generation: The complexity to build region graphs depends

mainly on the number of states, the number transitions and the number of

clocks of the timed automata. Each sequence SEQ, obtained with the previous

step, have at most M states, K transitions and C = card(CS) clocks. So,

according to [AD94], for each sequence, the complexity to build a region graph

is proportional to (M +K) � 2Æ(SEQ)

and where the number of clock regions is

proportional to (2Æ(SEQ)

) and where Æ(SEQ) is the number of clock constraints

of SEQ. In the worst case, we will have K sequences, so the complexity to

generate all of the region graphs is proportional to (M +K) �K � 2Æ(SEQ)

.

� Synchronous product: The complexity to synchronize two region graphs

depends on the maximal number of transitions in both of them and on the

number of clocks used during the resolution of the system of inequations to

produce the PASS region. The number of transitions is still at mostK�2Æ(SEQ)

,

so the complexity of the synchronous product is proportional toK�2Æ(SEQ)

�C.

At most, we have K region graphs, thus the complexity to synchronize theses

ones with the test purpose is proportional to K2� 2

Æ(SEQ)� C.

� Execution tree: The complexity to build execution trees depends on the

length and the number of test cases. Timed automata have at most K �2Æ(SEQ)

transitions, the length of one test case, obtained from it, equals to K �2Æ(SEQ)

.

If test cases contains only input actions, for each one, two branches are added at

the tree, thus the complexity to build all of the execution trees is proportional

to 2K�2Æ(SEQ)

�N , with N the number of test cases.

Consequently, the global complexity of the methodology depends mainly on the

number of clock regions generated in the second step. The number is exponential,

104

Page 115: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

the main complexity is exponential. However, the minimization of region graphs

strongly reduces this number, but the number ofminimized clock regions is di�cult

to know before the minimization step.

6 Conclusion

We presented a practical technique to testing timed system based on timed pur-

poses. It insures to check user properties (behavior and temporal aspects) on an

implementation. These properties are speci�ed as a tree of partial traces to �nd on

the speci�cation. We performed a synchronous product between the speci�cation

and the test purpose. This product selects pertinent clock regions where the testing

process is possible. This last step allows to reduce the time space where the test has

to be executed. Then, we extracted timed test cases from the synchronous product.

Finally, we have shown how to execute these test cases on the implementation.

The originality of this study is to deal with the entire region graph deduced from

the timed automaton describing any timed system. We considered the complete

cycle from the speci�cation to the execution of test cases.

Recently, we had developed a prototype tool accepting a timed automaton as a

system speci�cation and a test purpose as well. It executes the synchronous product

and extracts the timed test cases. But this tool does not deal with more than two

clocks.

Our main limitation is the use of only two clocks for the speci�cation of timing

constraints. We have not present any conformance relation between the speci�cation

and the implementation since we do not perform an total fault coverage of the

implementation. Our purpose is only to detect errors by applying selected test

purposes of the use.

References

[ACH+92] R. Alur, C. Courcoubetis, N. Halbwachs, D. Dill, and H. Wong-Toi.

Minimization of timed transition systems. In R. Cleaveland, editor,

Proceedings CONCUR 92, Stony Brook, NY, USA, volume 630 of Lec-

ture Notes in Computer Science, pages 340�354. Springer-Verlag, 1992.

[ACH94] R. Alur, C. Courcoubetis, and T.A. Henzinger. The observational

power of clocks. In B. Jonsson and J. Parrow, editors, Proceedings

CONCUR 94, Uppsala, Sweden, volume 836 of Lecture Notes in Com-

puter Science, pages 162�177. Springer-Verlag, 1994.

[AD94] R. Alur and D. Dill. A theory of timed automata. Theoretical Computer

Science, 126:183�235, 1994.

[BFG+00] M. Bozga, J.C. Fernandez, L. Ghirvu, C. Jard, T. Jéron, A. Kerbrat,

P. Morel, and L. Mounier. Veri�cation and test generation for the sscop

protoocl. Science of Computer Programming, 36(1):27�52, 2000.

[BLL+98] J. Bengtsson, K.G. Larsen, F. Larsen, P. Petterson, W. Yi, and

C. Weise. New Generation of UPPAAL. In Proceedings of the Interna-

tional Workshop on SOftware Tools and Technology Transfer (Aalborg,

Denmark, July 12-13), July 1998.

[Bri87] E. Brinksma. A theory for the derivation of tests. In S. Aggarwal,

editor, Proceedings of the Eighth International Conference on Protocol

Speci�cation, Testing and Veri�cation. North-Holland, 1987.

105

Page 116: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[CCKS95] R. Castanet, C. Chevrier, O. Koné, and B. Le Saec. An Adaptive TestSequence Generation Method for the User Needs. In Proceedings of

IWPTS'95, Evry, France, 1995.

[CGPT95] M. Clatin, R. Groz, M. Phalippou, and R. Thummel. Two approacheslinking a test generation tool with veri�cation techniques. In Proceed-

ings of IWPTS'95, Evry, France, 1995.

[CH96] J.Y. Choi and B.K. Hong. Generation of Conformance Test Suitesfor b-isdn Signaling Relevant to Multi_party Testing Architecture. InB. Baumgarten, H.-J. Burkhardt, and A. Giessler, editors, Proceed-ings of the 8th International Workshop on Test of Communicating Sys-

tems IWTCS'96 (Darmstadt, Germany), pages 316�330, Amsterdam,september 1996. North-Holland.

[Cho78] T.S. Chow. Testing software design modeled by �nite-state machines.IEEE Transactions on Software Engineering, SE-4(3):178�187, 1978.

[CKM92] Ana Cavalli, Sung Un Kim, and Patrick Maigron. Automated ProtocolConformance Test Generation Based on Formal Methods for LOTOSSpeci�cations. In North Holland, editor, Proceedings of the 5th In-

ternational Workshop on Protocol Test System IWPTS'92 (Montreal,

Canada), October 1992.

[CL97] D. Clarke and I. Lee. Automatic generation of tests for timing con-straints from requirements. In Proceedings of the Third International

Workshop on Object-Oriented Real-Time Dependable Systems, NewportBeach, California, February 1997.

[COG98] R. Cardel-Oliver and T. Glover. A practical and complete algorithmfor testing real-time systems. In Proc. of the 5th. Formal Techniques in

Real-Time and Fault-Tolerant Systems, volume 1486 of Lecture Notesin Computer Science, pages 251�261. SpringerVerlag, 1998.

[DNH84] R. De Nicola and M. Hennessy. Testing equivalences for processes.Theoretical Computer Science, 34:83�133, 1984.

[DOTY95] C. Daws, A. Olivero, S. Tripakis, and S. Yovine. The tool Kronos. InR. Alur, T.A. Henzinger, and E.D. Sontag, editors, Hybrid Systems III,volume 1066 of Lecture Notes in Computer Science, pages �. Springer-Verlag, 1995.

[DOY94] C. Daws, A. Olivero, and S. Yovine. Verifying ET-LOTOS programswith kronos. In D. Hogrefe and S. Leue, editors, Proceedings of

the 7th International Conference on Formal Description Techniques,

FORTE'94, pages 207�222. North-Holland, 1994.

[DY95] C. Daws and S. Yovine. Two examples of veri�cation of multirate timedautomata with kronos. In Proceedings of the 1995 IEEE Real-Time

Systems Symposium, RTSS'95, Pisa, Italy. IEEE Computer SocietyPress, 1995.

[DY96] C. Daws and S. Yovine. Reducing the number of clock variables oftimed automata. In Proceedings of the 1996 IEEE Real-Time Systems

Symposium, RTSS'96, Washington DC, USA. IEEE Computer SocietyPress, 1996.

[ENDKE98] A. En-Nouaary, R. Dssouli, F. Khendek, and A. Elqortobi. Timed testcases generation based on state characterization technique. In 19th

IEEE Real Time Systems Symposium (RTSS'98) Madrid, Spain, 1998.

106

Page 117: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[FBK+91] S. Fujiwara, G. von Bochmann, F. Khendek, M. Amalou, andA. Ghedamsi. Test selection based on �nite-state models. IEEE Trans-

actions on Software Engineering, 17(6):591�603, June 1991.

[Kon95] O. Koné. Designing test for time dependant systems. In Proceedings of

the 13th IFIP International Conference on Computer Communication

Séoul, South Korea, 1995.

[Lau99] P. Laurençot. Integration du temps dans les tests de protocoles de com-

munication. PhD thesis, Univ. of Bordeaux 1, January 1999.

[LC97] Patrice Laurencot and Richard Castanet. Integration of Time inCanonical Testers for Real-Time Systems. In International Workshop

on Object-Oriented Real-Time Dependable Systems, California. IEEEComputer Society Press, 1997.

[NS01] Brian Nielsen and Arne Skou. Automated Test Generation from TimedAutomata. In T. Margaria and W. Yi, editors, Proceedings of the

Workshop on Tools and Algorithms for the Construction and Analysis

of Systems, Genova, Italy, volume 2031 of Lecture Notes in Computer

Science, pages 343�357. Springer-Verlag, April 2001.

[PF99a] Eric Petitjean and Hacène Fouchal. From Timed Automata to TestableUntimeed Automata. In 24th IFAC/IFIP International Workshop on

Real-Time Programming, Schloss Dagstuhl, Germany, 1999.

[PF99b] Eric Petitjean and Hacène Fouchal. A Realistic Architecture for TimedSystems. In 5th IEEE International Conference on Engineering of

Complex Computer Systems, Las Vegas, USA, pages 109�118, 1999.

[PLC98] O. Koné P. Laurencot and R. Castanet. On the Fly Test Generationfor Real Time Protocols. In International Conference on Comnputer

Communications and Networks, Louisiane U.S.A, 1998.

[RNHW98] P. Raymond, X. Nicollin, N. Halbwatchs, and D. Waber. Automatictesting of reactive systems, madrid, spain. In Proceedings of the 1998

IEEE Real-Time Systems Symposium, RTSS'98, pages 200�209. IEEEComputer Society Press, December 1998.

[SD88] K. Sabnani and A. Dahbura. A protocol test generation procedure.Computer Networks and ISDN Systems, 15:285�297, 1988.

[SV96] J. Springintveld and F. Vaandrager. Minimizable timed automata. InB. Jonsson and J. Parrow, editors, Proceedings of the 4th International

School and Symposium on Formal Techniques in Real Time and Fault

Tolerant Systems, Uppsala, Sweden, volume 1135 of Lecture Notes in

Computer Science, pages �. Springer-Verlag, 1996.

[SVD01] J. Springintveld, F.W. Vaandrager, and P. R. D'Argenio. Timed Test-ing Automata. Theoretical Computer Science, 254(254):225�257, 2001.

[Tre96] J. Tretmans. Conformance testing with labelled transition systems:Implementation relations and test generation. Computer Networks and

ISDN Systems, 29:49�79, 1996.

[YL93] M. Yannakakis and D. Lee. An e�cient algorithm for minimizing real-time transition systems (Extended abstract). In C. Courcoubetis, edi-tor, Proceedings of the 5th International Conference on Computer Aided

Veri�cation, Elounda, Greece, volume 697 of Lecture Notes in Com-

puter Science, pages 210�224. Springer-Verlag, 1993.

107

Page 118: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

108

Page 119: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� � � � � � � � � � � � � � � � � � � �

� � � � ! " � $ � � � ' $ � � � � � � � �

+ , - / 1 2, 4 4 6 - 7 9 ; , < > @ 2C D F H , D 4 I

J K L M O P R T R V W X Z [ ] _ Z O a c d f ] Z ] h V i k l m o q s t ku v q w x o z { w | o q l w m o w m O � o V W o � o � t t { f ] � f t O a c d f ] � f � v i k l m o q s t k

� � d � � l m o k l O s o � w l � � l m o k � t � l h � M O c t s o k t { { � W � o { � f d � � O � d � � � � Z � t k � � q �� � � � � � � � � � � � � �   ¡ � £ � t { s ¤ ¥ � ¦ § � ¨ � ¦ � � © ª « ¬ « © � � « � ­ �

¯ ° ² ´ µ ¶ · ´ ¸ i l w � { t m � q o d º t q t k o m q w » ¼ l t � � o { o q w » ¿ À q t k o Á W q  À W q m o l m » t l o » � t q t » m o q w l t m w W { Ot { s s o Ä { w m w W { W À m o l m l o m » W | o q t � o » q w m o q w t w l s o | o � W º o s R � � o l w � { t m � q o k w � � m » W q q o l º W { s m W tº q W � q t k k w { � � t { � � t � o l � { m t X O m � o À W q k t m W À t s t m t l m q � » m � q o O t » W k º � m t m w W { t � W q l o k t { m w » t �l m q � » m � q o O o R � R O À W q s o q w | t m w W { l O º q W W À m q o o l O W q » W { m q W � d Æ W Á � q t º � l R � o l m l o m » � t q t » m o q w l t m w W { w l� t l o s W { q o � � � t q o X º q o l l w W { l s o l » q w � w { � º t m � l À W q m o q k l W | o q m � o l w � { t m � q o t m � t { s R a o » o l l t q �t { s » W { | o { w o { m º q W º o q m w o l À W q m o l m l o m » W | o q t � o » q w m o q w t » t { � o » W { » o w | o s w { m � o À q t k o Á W q  R� � o À q t k o Á W q  w l l w k º � o w { m � o l o { l o m � t m w m w l l W � o � � � t l o s W { m o q k t � � o � q t l t { s � t l w »

q o � � � t q � t { � � t � o m � o W q � R � � o l º o » w Ä » t m w W { l w { m � o À q t k o Á W q  » t { � o o Ì o » m w | o � � � l o s À W q» W | o q t � o t { t � � l w l O t { s À W q m o l m » t l o t { s m o l m l o m � o { o q t m w W { R

Í Î Ï Ð Ñ Ò Ó Ô Õ Ð Ö Ò Ï

× Ø Ù Ø Ú Û Ü Ý Þ ß à á Ý ß Ø â ß Ø ã ß Û Ù ä å 6 , D 6 æ < ç 6 D 6 è ç 6 > æ < è é 6 ê æ ë ê , ç æ C < - , < F ì , F 6 è , < > ç C C - æ < F æ < í C - í 6 > æ < , ì îç C 4 , ç 6 > ç 6 è ç æ < F C / è C / ç ï , D 6 , < > è é 6 ê æ ë ê , ç æ C < è ñ å 6 D 6 - , ç 6 ç 6 è ç ê , è 6 ê ò , D , ê ç 6 D æ è , ç æ C < è , < > ê C í 6 D , F 6ê D æ ç 6 D æ , 6 æ ç ò 6 D > æ D 6 ê ç - ó ç C ç ò 6 é D C F D , 4 è , < > è é 6 ê æ ë ê , ç æ C < è ç ò 6 4 è 6 - í 6 è ô C D ç C ç ò 6 ê C D D 6 è é C < > æ < F ê C 4 î

é ì ç , ç æ C < , - ô æ 4 é - 6 4 6 < ç , ç æ C < , - C D è 6 4 , < ç æ ê , - 4 C > 6 - è ñ õ ò 6 / ì < > , 4 6 < ç , - ê C < ç D æ ö ì ç æ C < C / ç ò 6 é D 6 è 6 < ç, D ç æ ê - 6 æ è ç ò , ç ï 6 è 6 ç ì é , / C D 4 , - ç 6 è ç æ < F / D , 4 6 ï C D ÷ ï ò æ ê ò æ è ä Ø Ù Ø Ú Û Ü ï ñ D ñ ç ñ ç ò 6 , ê ç ì , - è ó < ç , ø ô / C D 4 , ç

C D 4 C > 6 - ñ ù - - ï ò , ç ï 6 , è è ì 4 6 æ è ç ò 6 / C - - C ï æ < F ú

û ü < 6 ê , < 6 ø ç D , ê ç , è æ F < , ç ì D 6 þ / D C 4 ç ò 6 ê C < ê D 6 ç 6 ç 6 è ç æ < F è ê 6 < , D æ C ñû õ ò 6 è æ F < , ç ì D 6 æ è ì è 6 / ì - ç C ê ò , D , ê ç 6 D æ è 6 ç 6 è ç ê , è 6 è ö ó D 6 F ì - , D 6 ø é D 6 è è æ C < è / C D ç ò 6 è ê 6 < , D æ C ñû õ 6 D 4 è C í 6 D þ , D 6 D 6 - , ç 6 > ç C ç 6 è ç > , ç , / C D ç ò 6 è ê 6 < , D æ C æ < , < 6 � 6 ê ç æ í 6 4 , < < 6 D ñ

õ ò 6 è 6 é D 6 ê C < > æ ç æ C < è , D 6 4 6 ç ö ó 4 , < ó ç 6 è ç æ < F è ê 6 < , D æ C è ï ò 6 D 6 æ < è C 4 6 è 6 < è 6 , F D , 4 4 , D ô C D ,F D , é ò î C D ç D 6 6 î - æ ÷ 6 è ç D ì ê ç ì D 6 æ è , é D æ 4 , D ó , D ç æ / , ê ç ô < , 4 6 - ó æ < ê C 4 é æ - 6 D ç 6 è ç æ < F � ê / ñ � � ì D � � ô , < >ç D , > æ ç æ C < , - é D C F D , 4 ç 6 è ç æ < F � ê / ñ � � ó 6 � � ô � 6 æ � � � ñ � ì ê ò , - æ < ÷ æ è < C ç C ö í æ C ì è / C D ç 6 è ç æ < F ê 6 < ç 6 D 6 >, D C ì < > C ö è 6 D í , ö - 6 ö 6 ò , í æ C ì D ô 6 ñ F ñ ô æ < ç 6 è ç æ < F ç D , < è æ ç æ C < è ó è ç 6 4 � � õ � � � ñ � < ç ò 6 F 6 < 6 D æ ê / D , 4 6 ï C D ÷ ô

C < 6 ê , < ê ò , D , ê ç 6 D æ è 6 ç 6 è ç ê , è 6 è , < > > 6 ë < 6 ê C í 6 D , F 6 ê D æ ç 6 D æ , / C D ç 6 è ç è 6 ç è ô , < > C < 6 ê , < é 6 D / C D 4ê C í 6 D , F 6 , < , - ó è æ è / C D ç 6 è ç è 6 ç è ô , < > F 6 < 6 D , ç æ C < C / ç 6 è ç ê , è 6 è , < > ç 6 è ç è 6 ç è ñ õ ò 6 / D , 4 6 ï C D ÷ æ è ö , è 6 >

C < D 6 F ì - , D - , < F ì , F 6 ç ò 6 C D ó ç C > 6 , - ï æ ç ò é , ç ò è / C D ç 6 D 4 è C í 6 D þ ñ õ ò 6 D 6 , D 6 ê C í 6 D , F 6 ê D æ ç 6 D æ , ï ò æ ê òï 6 D 6 F 6 < 6 D æ ê , - - ó , é é D C í 6 > ç C 4 6 6 ç í , - ì , ö - 6 é D C é 6 D ç æ 6 è - æ ÷ 6 ê C 4 é - 6 ç 6 < 6 è è ñ õ ò 6 / D , 4 6 ï C D ÷ 6 < / C D ê 6 è, < 6 � 6 ê ç æ í 6 è ç ó - 6 C / è é 6 ê æ ë ê , ç æ C < è / C D ç 6 è ç ê , è 6 è , < > ç 6 è ç è 6 ç è ô ç ò , ç æ è ô ç ò 6 D 6 6 ø æ è ç è æ 4 é - 6 , - F C D æ ç ò 4 è

ç C é 6 D / C D 4 ê C í 6 D , F 6 , < , - ó è æ è ô ç 6 è ç ê , è 6 F 6 < 6 D , ç æ C < ô , < > ç 6 è ç è 6 ç F 6 < 6 D , ç æ C < ñ

� Ø ã ß Û Ù ä Ý � Ú à ä Ú Ý á 1 6 ç ì è > æ è ê ì è è , / 6 ï è ê 6 < , D æ C è ï ò 6 D 6 ï 6 ï , < ç ç C F 6 < 6 D , ç 6 ç 6 è ç > , ç , / D C 4 ,é D C F D , 4 � ç C ç 6 è ç ç ò æ è í 6 D ó é D C F D , 4 ô C D ï 6 ï , < ç ç C , è è 6 è è , F æ í 6 < ç 6 è ç è 6 ç / C D � ñ ù è , < , è æ > 6 ôæ < ö C ç ò ê , è 6 è ô ï 6 , D 6 ê C < ê 6 D < 6 > ï æ ç ò ï ò æ ç 6 î ö C ø ç 6 è ç æ < F ñ � ì é é C è 6 � æ è , # D C - C F é D C F D , 4 ñ � 6 í 6 D , -è ê 6 < , D æ C è ï æ ç ò > æ � 6 D 6 < ç 6 ø ç D , ê ç 6 > è æ F < , ç ì D 6 è þ , D 6 ê C < ê 6 æ í , ö - 6 ô 6 ñ F ñ ú

û 1 6 ç ì è ê ò C C è 6 ç ò 6 è ê 6 < , D æ C ç ò , ç ï 6 ï , < ç ç C F 6 < 6 D , ç 6 ç 6 è ç > , ç , � è , ó D C C ç è C / é D C C / ç D 6 6 è C /ç ò 6 F C , - ê - , ì è 6 C / � ï ò æ ê ò 6 ø 6 D ê æ è 6 ç ò 6 ê - , ì è 6 è C / � æ < , ê 6 D ç , æ < ï , ó ô < , 4 6 - ó , - - ê - , ì è 6 è, D 6 , é é - æ 6 > æ < , - - é C è è æ ö - 6 ê C < ç 6 ø ç è ñ å 6 ê ò C C è 6 ç ò 6 è ÷ 6 - 6 ç C < C / � � æ ñ 6 ñ ô ç ò 6 ê - , ì è 6 è ï æ ç ò ç ò 6

é , D , 4 6 ç 6 D è è ç D æ é é 6 > , ï , ó ô , è þ ñ õ ò 6 F 6 < 6 D æ ê / D , 4 6 ï C D ÷ æ 4 4 6 > æ , ç 6 - ó é D C í æ > 6 è , è ì æ ç , ö - 6

109

Page 120: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

ê C í 6 D , F 6 ê D æ ç 6 D æ C < ô < , 4 6 - ó ê C < ç 6 ø ç î > 6 é 6 < > 6 < ç ö D , < ê ò ê C í 6 D , F 6 ñ å 6 é 6 D / C D 4 ç 6 è ç è 6 ç F 6 < 6 D , ç æ C <æ < ç ò 6 F 6 < 6 D æ ê / D , 4 6 ï C D ÷ , ê ê C D > æ < F - ó ñ õ ò 6 D 6 ö ó ô ï 6 C ö ç , æ < , è 6 ç C / ç 6 D 4 è C í 6 D þ ñ � < ç ò æ è è ê 6 < , D æ C ô, ç 6 D 4 C í 6 D þ ê C D D 6 è é C < > è D C ì F ò - ó ç C , é D C C / ç D 6 6 è ÷ 6 - 6 ç C < � ï ò 6 D 6 ç ò 6 é , D , 4 6 ç 6 D è , D 6 < C çê C < è ç D , æ < 6 > ñ � , é é æ < F ö , ê ÷ è ì ê ò , ç 6 D 4 ç C ç ò 6 # D C - C F ê C < ç 6 ø ç 4 6 , < è ç ò , ç ï 6 < 6 6 > ç C 6 ø 6 ê ì ç 6

ç ò 6 é D C F D , 4 � æ < , ï , ó ç C 6 < / C D ê 6 , é D C C / ç D 6 6 ï ò æ ê ò 4 , ç ê ò 6 è ç ò 6 F æ í 6 < é D C C / ç D 6 6 è ÷ 6 - 6 ç C < ñõ ò æ è ê , < ö 6 > C < 6 ö ó ê C < ç D C - - æ < F ç ò 6 é D C F D , 4 6 ø 6 ê ì ç æ C < í æ , , 4 6 ç , î é D C F D , 4 æ < ç 6 D é D 6 ç 6 D � ê / ñ

� � 6 < � � � ñ � < ï C D è ç ê , è 6 ô ï 6 ê , < < C ç ê C 4 é - 6 ç 6 ç ò 6 F æ í 6 < é D C C / ç D 6 6 è ÷ 6 - 6 ç C < æ < ç C , é D C C / ç D 6 6 ñ

û ù - ç 6 D < , ç æ í 6 ê ò C æ ê 6 è / C D þ , D 6 ç ò 6 è ç D ì ê ç ì D 6 C / é D C C / ç D 6 6 è / C D � ô ç ò 6 è ç D ì ê ç ì D 6 C / � 1 � > 6 D æ í , ç æ C < è/ C D � ô ç ò 6 / ì < ê ç C D è ì è 6 > / C D > , ç , D 6 é D 6 è 6 < ç , ç æ C < è æ < � ô ç ò 6 æ < ç 6 D / , ê 6 / C D - æ ö D , D ó / ì < ê ç æ C < , - æ ç ó

ì è 6 > æ < � ô C D è C 4 6 è æ F < , ç ì D 6 C / > 6 ö ì F F æ < F ç D , ê 6 è / C D � ñ ù - - ç ò 6 è 6 ê ò C æ ê 6 è , D 6 ì è 6 / ì - / C D è C 4 6è ê 6 < , D æ C C / ç 6 è ç æ < F ñ å 6 < 6 6 > ç C 6 4 é - C ó ô / C D 6 ø , 4 é - 6 ô ç ò 6 è ç D ì ê ç ì D 6 C / é D C C / ç D 6 6 è / C D � � æ < è ç 6 , >

C / ç ò 6 è ÷ 6 - 6 ç C < C / � , ö C í 6 æ / ï 6 ï , < ç ç C ê C < è ç D , æ < ç ò 6 é , D , 4 6 ç 6 D è C / é D 6 > æ ê , ç 6 è æ < è C 4 6 ï , ó

C D , < C ç ò 6 D ô 6 ñ F ñ ô æ / ï 6 ï , < ç ç C 6 < / C D ê 6 ç ò , ç , ê 6 D ç , æ < > 6 é ç ò C / < 6 è ç æ < F æ è 6 ø 6 D ê æ è 6 > æ < è C 4 6é , D , 4 6 ç 6 D é C è æ ç æ C < C / � ñ

ù è , < , è æ > 6 ô 6 ø ç D , ê ç æ < F þ / D C 4 , ç 6 è ç æ < F è ê 6 < , D æ C æ è ì è ì , - - ó è æ 4 é - 6 ñ � , é é æ < F ö , ê ÷ ç 6 D 4 è ç C ç ò 6ç 6 è ç æ < F è ê 6 < , D æ C C / ç 6 < æ < í C - í 6 è ê C 4 é ì ç , ç æ C < , - ô è 6 4 , < ç æ ê , - , < > æ 4 é - 6 4 6 < ç , ç æ C < , - 4 C > 6 - è , è æ < ç ò 6, ö C í 6 è ê 6 < , D æ C ï ò 6 D 6 é D C C / ç D 6 6 è ÷ 6 - 6 ç C < è ò , > ç C ö 6 ê C 4 é - 6 ç 6 > ç C é D C C / ç D 6 6 è ñ � < ç ò 6 é D 6 è 6 < ç , D ç æ ê - 6 ôï 6 / C ê ì è C < ç ò 6 F 6 < 6 D æ ê é , D ç ô ç ò , ç æ è ô ç ò 6 ê ò , D , ê ç 6 D æ è , ç æ C < C / ç 6 è ç ê , è 6 è , < > ê C í 6 D , F 6 ê D æ ç 6 D æ , ï ñ D ñ ç ñ, è æ F < , ç ì D 6 þ ñ

� Ø ã ß Û Ù ä Ý � Ú à ä Ú Ý á Ý ä Ý Û Ù ã ß Ý ã � Ø Ü Û � Ü Ý ß Û à Ù � / ï 6 ô / C D 6 ø , 4 é - 6 ô ç , - ÷ , ö C ì ç , é D C F D , 4 4 æ < F - , < F ì , F 6� ô ç ò 6 è æ F < , ç ì D 6 þ 4 æ F ò ç ê C D D 6 è é C < > ç C ç ò 6 ê C < ê D 6 ç 6 C D , ö è ç D , ê ç è ó < ç , ø C / � ô ç C , - æ ö D , D ó è æ F < , ç ì D 6 ô

ç C , < æ < ç 6 D 4 6 > æ , ç 6 / C D 4 , ç ô C D ç C , > 6 D æ í 6 > / C D 4 , ç � 6 ñ F ñ ô / C D ê C < ç D C - î � C ï , < > > , ç , î � C ï , < , - ó è æ è ñ1 6 ç ì è ê C < è æ > 6 D ç ò 6 è æ 4 é - 6 ê , è 6 ç ò , ç ï 6 ï , < ç ç C ç 6 è ç ç ò 6 / D C < ç 6 < > æ 4 é - 6 4 6 < ç , ç æ C < � è , ó é , D è 6 D

C / ç ò 6 - , < F ì , F 6 � ô , < > ç ò , ç , F D , 4 4 , D è é 6 ê æ ë ê , ç æ C < � æ è , í , æ - , ö - 6 / C D � ñ õ ò 6 è æ F < , ç ì D 6 þ æ è ç ò 6 <è æ 4 é - ó 6 ø ç D , ê ç 6 > / D C 4 � ñ � ó ç ò æ è ô ï 6 ê , < é ì D è ì 6 ç 6 è ç è 6 ç F 6 < 6 D , ç æ C < C D ê C í 6 D , F 6 , < , - ó è æ è æ < ç ò 6

F 6 < 6 D æ ê / D , 4 6 ï C D ÷ ñ � / ï 6 æ < > 6 6 > F 6 < 6 D , ç 6 ç 6 è ç ê , è 6 è ô ï 6 ê , < 6 , è æ - ó 4 , é ç ò 6 4 ö , ê ÷ ç C ç ò 6 ç 6 è ç æ < Fè ê 6 < , D æ C ô ç ò , ç æ è ô ç 6 D 4 è C í 6 D ç ò 6 6 ø ç D , ê ç 6 > þ ò , í 6 ç C ö 6 D 6 é ò D , è 6 > , è ï C D > è æ < ç ò 6 - , < F ì , F 6 � ñ� ì ö è 6 � ì 6 < ç - ó ô ï 6 ê , < / 6 6 > ç ò 6 C ö ç , æ < 6 > è ç D æ < F è ç C ç ò 6 / D C < ç 6 < > ç C é 6 D / C D 4 ö - , ê ÷ î ö C ø ç 6 è ç æ < F C / ç ò 6

/ D C < ç 6 < > æ 4 é - 6 4 6 < ç , ç æ C < , F , æ < è ç ç ò 6 F D , 4 4 , D è é 6 ê æ ë ê , ç æ C < � ñ ù è / C D ç ò 6 é ì D é C è 6 C / ç 6 è ç æ < F ô ï 64 æ F ò ç ï , < ç ç C ç 6 è ç / C D ê C 4 é - 6 ç 6 < 6 è è C / ö ó 6 ø 6 D ê æ è æ < F , - - - , < F ì , F 6 ê C < è ç D ì ê ç è , > 4 æ ç ç 6 > ö ó � ô C Dï 6 > 6 , - ï æ ç ò è ç D 6 è è ç 6 è ç æ < F ñ � < ó 6 ç , < C ç ò 6 D ê , è 6 ô , ç 6 è ç è ì æ ç 6 / C D ç ò 6 æ 4 é - 6 4 6 < ç , ç æ C < 4 æ F ò ç ö 6, í , æ - , ö - 6 ô , < > ï 6 ï , < ç ç C , è è 6 è è æ ç ç C > 6 ê æ > 6 æ / ç ò 6 è ì æ ç 6 , ê ò æ 6 í 6 è ê C í 6 D , F 6 C / ç ò 6 è é 6 ê æ ë ê , ç æ C < �

, ê ê C D > æ < F ç C , ê D æ ç 6 D æ C < , > C é ç 6 > / D C 4 ç ò 6 F 6 < 6 D æ ê / D , 4 6 ï C D ÷ ñ

� Ø ã Ø Ý Ú Ü � Ü à Ù ß Ø � ß � < ï ò æ ç 6 î ö C ø ç 6 è ç æ < F / C D é D C F D , 4 è C / , ê 6 D ç , æ < - , < F ì , F 6 � ô C < 6 ê , < ì è 6 > æ � 6 D î6 < ç è ç D ì ê ç ì D , - é D C é 6 D ç æ 6 è � ê / ñ � � ó 6 � � ô � 6 æ � � � ô 6 ñ F ñ ô / C - ÷ - C D 6 é D C é 6 D ç æ 6 è è ì ê ò , è è ç , ç 6 4 6 < ç C D é , ç òê C í 6 D , F 6 ñ ü < 6 ê , < , - è C ç D ó ç C ì è 6 4 C D 6 , ö è ç D , ê ç , è é 6 ê ç è - æ ÷ 6 ç ò 6 > , ç , � C ï æ < , é D C F D , 4 � ê / ñ

� + å � � ô å � � � ñ " í 6 < æ / ç ò 6 > 6 D æ í , ç æ C < C / , > , ç , î � C ï � C D , ê C < ç D C - î � C ï F D , é ò æ < í C - í 6 è ç ò 6 è 6 î4 , < ç æ ê è C / � ô ç ò 6 F D , é ò æ è ë < , - - ó , F , æ < , è ç D ì ê ç ì D 6 ï ò æ ê ò , > 4 æ ç è ç 6 è ç æ < F ê C < ê 6 é ç è è æ 4 æ - , D ç C ç ò C è 6

/ C D , ö è ç D , ê ç è ó < ç , ø ç D 6 6 è ñ H 6 < ê 6 ô ç ò 6 D 6 , D 6 è 6 í 6 D , - ê , < > æ > , ç 6 è / C D ç ò 6 è æ F < , ç ì D 6 þ ô < , 4 6 - ó ç ò 6 , ö îè ç D , ê ç C D ê C < ê D 6 ç 6 è ó < ç , ø C / � ô ç ò 6 è ç D ì ê ç ì D 6 C / ê C < ç D C - î � C ï F D , é ò è C D > , ç , î � C ï F D , é ò è ñ ü ì D F 6 < 6 D æ ê

/ D , 4 6 ï C D ÷ æ è ç ò 6 D 6 è ì - ç C / , < , ç ç 6 4 é ç ç C , ö è ç D , ê ç / D C 4 ç ò 6 , ê ç ì , - è ç D ì ê ç ì D 6 C / , ç 6 è ç æ < F è ê 6 < , D æ C ô, < > ç C è ç ì > ó ç 6 è ç æ < F < C ç æ C < è C < ê 6 , < > / C D , - - æ < , - , D F 6 - ó F 6 < 6 D æ ê 4 , < < 6 D ñ ü < ç ò 6 C ç ò 6 D ò , < > ô ï 6

ï 6 D 6 > D æ í 6 < ö ó ç ò 6 æ < ç D æ F ì æ < F � ì 6 è ç æ C < æ / ç ò 6 D 6 æ è è C 4 6 ì < æ ë 6 > è ç ó - 6 / C D ç 6 è ç ê , è 6 ê ò , D , ê ç 6 D æ è , ç æ C <, < > / C D ê C í 6 D , F 6 ê D æ ç 6 D æ , / C D > æ � 6 D 6 < ç ÷ æ < > è C / è é 6 ê æ ë ê , ç æ C < è - æ ÷ 6 è ó < ç , ø > 6 ë < æ ç æ C < è ô , ç ç D æ ö ì ç 6 F D , 4 î

4 , D è ô , - F 6 ö D , æ ê è é 6 ê æ ë ê , ç æ C < è ô , < > - C F æ ê é D C F D , 4 è ñ � ì ê ò , ì < æ ë 6 > è ç ó - 6 ê C ì - > ö 6 ò 6 - é / ì - ç C ê C 4 é , D 6ê C í 6 D , F 6 ê D æ ç 6 D æ , ô , < > ç C D 6 , - æ è 6 ç ò 6 é C ç 6 < ç æ , - / C D , > > æ ç æ C < , - ê D æ ç 6 D æ , ñ � C / , D ô ê C í 6 D , F 6 ê D æ ç 6 D æ , ï 6 D 6> 6 ë < 6 > æ < , D , ç ò 6 D è é 6 ê æ ë ê ê C < ç 6 ø ç ñ õ ò 6 è 6 4 æ < , - é , é 6 D ö ó # ì D > C 4 � # ì D � ' ö � > 6 ë < 6 è , ê C í 6 D , F 6 ê D æ î

ç 6 D æ C < / C D D ì - 6 ê C í 6 D , F 6 C / , ê C < ç 6 ø ç î / D 6 6 F D , 4 4 , D ô , < > , - F C D æ ç ò 4 è / C D ç 6 è ç è 6 ç F 6 < 6 D , ç æ C < , D 6 F æ í 6 < ñ� < - C F æ ê é D C F D , 4 4 æ < F ô è C 4 6 ê C í 6 D , F 6 ê D æ ç 6 D æ , ò , í 6 ö 6 6 < è ç ì > æ 6 > � ê / ñ � � 6 < � � ô @ , ê � * � ï ò æ ê ò è 6 6 4

ç C ò , í 6 , ì è 6 / ì - æ < ç 6 D é D 6 ç , ç æ C < / C D C ç ò 6 D / C D 4 è C / è é 6 ê æ ë ê , ç æ C < è , < > é D C F D , 4 è ô ç C C ñ � < ç ò 6 ê C < ç 6 ø ç

C / - , < F ì , F 6 æ 4 é - 6 4 6 < ç , ç æ C < ô ç ò 6 é D C ö - 6 4 C / F 6 < 6 D , ç æ < F ç 6 è ç è 6 ç è / D C 4 í , D æ C ì è ÷ æ < > C / F D , 4 4 , D è

110

Page 121: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

ò , è ö 6 6 < è ç ì > æ 6 > 6 ø ç 6 < è æ í 6 - ó � ê / ñ � � + � � � � ô � � > � ' ô H � � � ô + æ 6 � ' � ñ � C è ç , é é D C , ê ò 6 è è ì F F 6 è ç 6 > æ < ç ò 6- æ ç 6 D , ç ì D 6 , D 6 < C ç , è / C D 4 , - , è # ì D > C 4 � è , é é D C , ê ò ô ç ò , ç æ è ô ç ò 6 ó , D 6 ò , D > - ó ö , è 6 > C < , / C D 4 , -ê C í 6 D , F 6 ê D æ ç 6 D æ C < ñ � < è ç 6 , > ô ò 6 ì D æ è ç æ ê è ô 4 ì ç , ç æ C < ô , < > D , < > C 4 æ � , ç æ C < , D 6 6 4 é - C ó 6 > ñ D , 4 4 , D è , D 6

C / ç 6 < æ < è ç D ì 4 6 < ç 6 > æ < , é D , F 4 , ç æ ê 4 , < < 6 D ñ � < � � + � � � � � ô / C D 6 ø , 4 é - 6 ô , è é 6 ê æ , - F D , 4 4 , D / C D 4 , - îæ è 4 � ï æ ç ò , ê ç æ C < è ï C D ÷ æ < F C < ç ò 6 æ < ç 6 D < , - > , ç , è ç D ì ê ç ì D 6 è C / ç ò 6 ç 6 è ç è 6 ç F 6 < 6 D , ç C D æ è ì è 6 > ñ ùè ì D í 6 ó C < ç 6 è ç è 6 ç F 6 < 6 D , ç æ C < / C D ê C 4 é æ - 6 D ç 6 è ç æ < F æ è F æ í 6 < æ < � � ì D � � ñ + 6 ê 6 < ç - ó ô ï 6 ê C < ç D æ ö ì ç 6 > , é îé D C ø æ 4 , ç æ C < ê C í 6 D , F 6 / C D , ç ç D æ ö ì ç 6 F D , 4 4 , D è � ê / ñ � H 1 � � � ô , < > ê C < ç 6 ø ç î > 6 é 6 < > 6 < ç ö D , < ê ò ê C í 6 D , F 6

/ C D è ó < ç , ø > 6 ë < æ ç æ C < è � ê / ñ � 1 2, 4 � � � ñ � < ç ò 6 F 6 < 6 D æ ê / D , 4 6 ï C D ÷ ô ï 6 / , í C ì D D 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < è

C < ç 6 D 4 è C í 6 D , è æ F < , ç ì D 6 , è ç ò 6 / C D 4 , - ç C C - / C D ê ò , D , ê ç 6 D æ è æ < F ç 6 è ç ê , è 6 è , < > ê C í 6 D , F 6 ê D æ ç 6 D æ , ñ� < ê 6 D ç , æ < , é é - æ ê , ç æ C < > C 4 , æ < è D 6 - , ç 6 > ç C ç 6 è ç æ < F ô è C 4 6 ÷ æ < > C / é , ç ò 6 ø é D 6 è è æ C < è , - è C ò , í 6 ö 6 6 <

ì è 6 > ô 6 ñ F ñ ô / C D � ì 6 D ó æ < F F D , é ò î 4 C > 6 - è C / , > , ç , ö , è 6 , < > / C D � ì 6 D ó æ < F è 6 4 æ î è ç D ì ê ç ì D 6 > > , ç , � ê / ñ� ù ö æ � � � ô C D / C D ç 6 è ç æ < F C / � H � 1 é D C F D , 4 è ö , è 6 > C < ê C < ç D C - î � C ï é , ç ò è � ê / ñ � � � � � ñ ü ì D , ö è ç D , ê ç

, < > ì < æ ë 6 > è ç ó - 6 æ < > 6 6 > , - - C ï è ì è ç C ê C 4 é , D 6 ê C í 6 D , F 6 ê D æ ç 6 D æ , ô , < > ç C 6 < / C D ê 6 F 6 < 6 D , - é D C é 6 D ç æ 6 è- æ ÷ 6 ê C 4 é - 6 ç 6 < 6 è è ñ � < � å 6 ó � � � ô æ < / C D 4 , - D 6 � ì æ D 6 4 6 < ç è / C D ê C í 6 D , F 6 ê D æ ç 6 D æ , , D 6 è ç , ç 6 > , < > D 6 í æ 6 ï 6 > ñ� ó ê C < ç D , è ç ô ç ò 6 é D 6 è 6 < ç , D ç æ ê - 6 ê C < ç D æ ö ì ç 6 è , / C D 4 , - 4 C > 6 - / C D ê C í 6 D , F 6 ê D æ ç 6 D æ , ñ

� ß Ú Þ Ü ß Þ Ú Ø à � ß � Ø Ý Ú ß Û Ü � Ø � < � 6 ê ç æ C < ' ô è C 4 6 < C ç , ç æ C < / C D > 6 , - æ < F ï æ ç ò D 6 F ì - , D 6 ø é D 6 è è æ C < è , < > ç 6 D 4 èæ è è é 6 - - 6 > C ì ç / C D ê C < í 6 < æ 6 < ê 6 ñ � < � 6 ê ç æ C < � ô , / C D 4 , - / D , 4 6 ï C D ÷ / C D ç 6 è ç ê , è 6 ê ò , D , ê ç 6 D æ è , ç æ C < æ è> 6 í 6 - C é 6 > ñ õ 6 è ç ê , è 6 è , ê ê C D > æ < F ç C , è æ F < , ç ì D 6 þ , D 6 6 è è 6 < ç æ , - - ó ê ò , D , ê ç 6 D æ è 6 > ö ó D 6 F ì - , D 6 ø é D 6 è è æ C < è

C í 6 D ç ò 6 é , ç ò è / C D ç 6 D 4 è C í 6 D þ ñ � < � 6 ê ç æ C < ô ç 6 è ç è 6 ç ê ò , D , ê ç 6 D æ è , ç æ C < , è C é é C è 6 > ç C è æ 4 é - 6 ç 6 è çê , è 6 ê ò , D , ê ç 6 D æ è , ç æ C < æ è , ê ê C 4 é - æ è ò 6 > ñ õ ò 6 ê C D D 6 è é C < > æ < F è 6 ç è C / ê - , è è 6 è C / é , ç ò è , D 6 è ì ö � 6 ê ç ç C, < ì 4 ö 6 D C / é D C é 6 D ç æ 6 è ô 6 ñ F ñ ô 4 æ < æ 4 , - æ ç ó , < > ê C 4 é - 6 ç 6 < 6 è è ô ì - ç æ 4 , ç 6 - ó - 6 , > æ < F ç C ç ò 6 < C ç æ C < C / ,

é D C é 6 D ê C í 6 D , F 6 ê D æ ç 6 D æ C < ñ ù è / C D ç ò 6 6 � 6 ê ç æ í 6 < 6 è è C / ç ò 6 è é 6 ê æ ë ê , ç æ C < è ô ï 6 D 6 - ó C < ö , è æ ê D 6 F ì - , D- , < F ì , F 6 ç ò 6 C D ó ñ � < � 6 ê ç æ C < � ô , < ì 4 ö 6 D C / ê C í 6 D , F 6 ê D æ ç 6 D æ , , D 6 > 6 í 6 - C é 6 > ñ å 6 è ç , D ç / D C 4 C / , <, ö è ç D , ê ç æ C < C / D ì - 6 ê C í 6 D , F 6 � # ì D � ' ö � ñ õ ò 6 < ô , < ì 4 ö 6 D C / 4 C D 6 æ < í C - í 6 > ê D æ ç 6 D æ , , D 6 > 6 ë < 6 > ñ ù

4 C D 6 6 - , ö C D , ç 6 > , D ç æ ê - 6 � ï æ ç ò é D C C / è ô 4 C D 6 6 ø , 4 é - 6 è ô , < > ò æ < ç è C < , é é - æ ê , ç æ C < è æ è ì < > 6 D ç ò 6 ï , ó ñ

� Ü � Ù à � � Ø â ä Ø á Ø Ù ß � � o t � m � W q l t q o w { s o � m o s m W h � w s W L t » � l k � m � À W q � o � º w { � � l Á w m � m � o w k º � o k o { m t m w W {W À m � o w s o t l À W q k t � w l o s w { m � o t q m w » � o R L o � l o s m � o � � i � m w � w m w o l � a W W Z _ � � h o q m x t { | t { a W W q s W { m W ºW À � L M d P q W � W � � L w o ] ] � � # t { L w o � o k t  o q m W w k º � o k o { m m � o À q t k o Á W q  ¼ Á w m � � q o t m º � o t l � q o ¿ R � � o Á W q ÂW À m � o Ä q l m t � m � W q Á t l l � º º W q m o s O w { º t q m O � � m � o � � m » � q o l o t q » � W q � t { w l t m w W { % ' ) O w { m � o º q W x o » m

+ , . 0 . 3 4 6 8 : 0 : = ? 3 : B 3 4 D E 3 4 0 H = : 3 D 4 6 8 : 0 M O H 6 . D H Q R

R S Ñ T U Ö V Ö Ï W Ñ Ö T Y

� Ø Ú á Ý � ä Ø Z Ú Ý ã ù è æ F < , ç ì D 6 þ æ è é , æ D [ ] ^ _ ` ô ï ò 6 D 6 ] æ è , ë < æ ç 6 è 6 ç C / è C D ç è ô , < > _ æ è , ë < æ ç 6 è 6 ç C // ì < ê ç æ C < ç ó é 6 è C / ç ò 6 / C D 4 a ú c 7 e g g g e c i k c m ô n o � ñ H 6 D 6 ô a æ è , / ì < ê ç æ C < è ó 4 ö C - ô , < > ç ò 6 c p, D 6 è C D ç è æ < ] ñ å 6 > 6 < C ç 6 ç ò 6 , D æ ç ó n C / a , è Ý Ú Û ß s � a ñ C D ê C < í 6 < æ 6 < ê 6 ô ï 6 , - è C è C 4 6 ç æ 4 6 è ï D æ ç 6a t _ ô æ ñ 6 ñ ô ï æ ç ò C ì ç F æ í æ < F ç ò 6 ç ó é 6 C / a ñ å 6 ì è 6 u v � þ ç C > 6 < C ç 6 ç ò 6 è 6 ç C / F D C ì < > C D í , D æ , ö - 6 î / D 6 6

ç 6 D 4 è C / è C D ç c æ < ç ò 6 ê C 4 4 C < ç 6 D 4 î , - F 6 ö D , æ ê è 6 < è 6 ñ å 6 , è è ì 4 6 ç 6 D 4 æ < , ç 6 > ç 6 D 4 , - F 6 ö D , è æ < ç ò 6è 6 < è 6 C / ê C < ç 6 ø ç î / D 6 6 F D , 4 4 , D è ô ç ò , ç æ è / C D , - - c t ] æ ç ò C - > è ç ò , ç u v � þ wx y ñ å 6 , - è C , è è ì 4 6 ç ò , ç

/ ì < ê ç æ C < è ó 4 ö C - è , D 6 < C ç C í 6 D - C , > 6 > ñ õ ò 6 è 6 D 6 è ç D æ ê ç æ C < è , D 6 6 , è ó ç C - æ / ç ñ

� Ø ä Þ � Ý Ú Ø � � Ú Ø ã ã Û à Ù ã å 6 , è è ì 4 6 / , 4 æ - æ , D æ ç ó ï æ ç ò ö , è æ ê D 6 F ì - , D - , < F ì , F 6 ç ò 6 C D ó � ê / ñ � H { � � ô ù � { � * � ñå 6 ì è 6 ë < æ ç 6 è ç , ç 6 , ì ç C 4 , ç , � � ù è ç C í æ è ì , - æ è 6 D 6 F ì - , D - , < F ì , F 6 è ñ å 6 ì è 6 ç ò 6 ê C 4 4 C < < C ç , ç æ C <

/ C D D 6 F ì - , D 6 ø é D 6 è è æ C < è ñ � 6 - C ï ô ï 6 é D C í æ > 6 , < æ < > ì ê ç æ í 6 > 6 ë < æ ç æ C < C / ç ò 6 > C 4 , æ < | ~ � C / D 6 F ì - , D6 ø é D 6 è è æ C < è C í 6 D è C 4 6 è 6 ç C / ç 6 D 4 æ < , - è � ñ

û � t | ~ � / C D � t � � ç 6 D 4 æ < , - è

û � ^ � � t | ~ � � � � � t | ~ � � ê C < ê , ç 6 < , ç æ C <

û � ^ � � t | ~ � � � � � � t | ~ � � , - ç 6 D < , ç æ í 6 è

û � t | ~ � � � � t | ~ � � ê C 4 é - 6 4 6 < ç

û � t | ~ � � � � t | ~ � � è ç , D î < C ç , ç æ C <

û � t | ~ � � � � t | ~ � � é - ì è î < C ç , ç æ C <

111

Page 122: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

ì D ç ò 6 D 4 C D 6 ô ï 6 ì è 6 è C 4 6 - 6 è è ê C 4 4 C < < C ç , ç æ C < / C D è ç , D î , < > é - ì è î < C ç , ç æ C < ç C ê C < è ç D , æ < ç ò 6< ì 4 ö 6 D C / æ ç 6 D , ç æ C < è ú

û � t | ~ � ^ � ^ � t � m ^ � � � � � � � � t | ~ �û � t | ~ � ^ � ^ � t � 7 ^ � � � � � � � � t | ~ �

õ ò 6 æ < ç 6 < > 6 > 4 6 , < æ < F C / � � � � , < > � � � � æ è ç ò , ç ç ò 6 < ì 4 ö 6 D C / æ ç 6 D , ç æ C < è æ è , ç - 6 , è ç � , < > , ç 4 C è ç � ñ� m , < > � 7 , D 6 ç ò 6 < , ç ì D , - è è ç , D ç æ < F / D C 4 � C D � ô D 6 è é 6 ê ç æ í 6 - ó ñ � � , < > � � , D 6 , ö ö D 6 í æ , ç æ C < è / C D � �

, < > � � ô D 6 è é 6 ê ç æ í 6 - ó ñ õ ò 6 è 6 ç C / ç 6 D 4 æ < , - è ç D æ < F è F 6 < 6 D , ç 6 > ö ó , D 6 F ì - , D 6 ø é D 6 è è æ C < � æ è > 6 < C ç 6 >ï æ ç ò � � � � � ñ å 6 , - è C 4 æ F ò ç ö 6 æ < ç 6 D 6 è ç 6 > æ < ç 6 D 4 æ < , - è ç D æ < F è F 6 < 6 D , ç 6 > ö ó , D 6 F ì - , D F D , 4 4 , D è ç , D ç æ < F/ D C 4 C < 6 C / æ ç è < C < ç 6 D 4 æ < , - è ñ õ ò 6 ç 6 D 4 æ < , - è ç D æ < F è F 6 < 6 D , ç 6 > / D C 4 ç ò 6 < C < ç 6 D 4 æ < , - n , ê ê C D > æ < Fç C � æ è > 6 < C ç 6 > ö ó � � n � � ñ � < F 6 < 6 D , - ô ï 6 ê , < , - è C ê C < è æ > 6 D ç ò 6 ç 6 D 4 æ < , - è ç D æ < F è � � � � � F 6 < 6 D , ç 6 >ö ó , D 6 F ì - , D 6 ø é D 6 è è æ C < ï ò æ ê ò ê C < ç , æ < è < C < ç 6 D 4 æ < , - è ñ � / � æ è C ö í æ C ì è / D C 4 ç ò 6 ê C < ç 6 ø ç ô ï 6 C 4 æ ç� æ < � � � � � ñ æ < , - - ó ô ï 6 > 6 ê - , D 6 , ê C < í 6 < æ 6 < ç , ö ö D 6 í æ , ç æ C < ô ç ò , ç æ è � � � � ñ � ç è æ < ç 6 < > 6 > 4 6 , < æ < F æ è

� � � � � � � � x � � ñ ù è è ì 4 æ < F � x � � 7 ^ � � � ^ � i � ô ï 6 ê , < 6 , è æ - ó F æ í 6 , D 6 F ì - , D 6 ø é D 6 è è æ C < > 6 ë < æ < F � � � � ô< , 4 6 - ó � � � � x � � 7 � g g g � � i � ñ

" # T Y Ð Õ W Y T Õ $ W Ñ W Õ Ð T Ñ Ö Y W Ð Ö Ò Ï

ù è æ F < , ç ì D 6 þ æ < > ì ê 6 è , ê - , è è C / é , ç ò è / C D ç 6 D 4 è C í 6 D þ ñ 7 ü ö í æ C ì è - ó ô , ç 6 D 4 ê , < ö 6 D 6 F , D > 6 > , è , è 6 çC / é , ç ò è ñ õ 6 è ç ê , è 6 è ê , < ö 6 ê ò , D , ê ç 6 D æ è 6 > ö ó D 6 F ì - , D 6 ø é D 6 è è æ C < è æ < ç 6 < > 6 > ç C 4 C > 6 - ê - , è è 6 è C / é , ç ò è ñå 6 ò , í 6 ê ò C è 6 < , è æ 4 é - 6 / ì < ê ç æ C < , - - , < F ì , F 6 , è ç ò 6 D ì < < æ < F 6 ø , 4 é - 6 ñ å 6 ï , < ç ç C ê ò , D , ê ç 6 D æ è 6è C 4 6 é D C F D , 4 è æ < ç ò æ è - , < F ì , F 6 ñ

% & ( * + - . /

å 6 > 6 ë < 6 , D 6 F ì - , D F D , 4 4 , D 1 3 � þ ï ò æ ê ò 4 C > 6 - è ç ò 6 é , ç ò è / C D ç ò 6 ç 6 D 4 è , ê ê C D > æ < F ç C , F æ í 6 <è æ F < , ç ì D 6 þ ñ õ 6 ê ò < æ ê , - - ó ô 1 3 � þ æ è > 6 ë < 6 > ç C F 6 < 6 D , ç 6 è 6 - 6 ê ç C D è 6 � ì 6 < ê 6 è ç C > 6 è ê 6 < > æ < ç C ç 6 D 4 è ñõ ò 6 è 6 è 6 - 6 ê ç C D è 6 � ì 6 < ê 6 è , D 6 ê , - - 6 > é , ç ò è æ < ç ò 6 è 6 � ì 6 - ñ

5 6 7 9 ; - ; < 9 ( & 1 3 � þ â Ø Ù à ß Ø ã ß � Ø þ î é , ç ò è F D , 4 4 , D � Û ß � Ý � Ù Û ß Ø ã Ø ß à � Ù à Ù ß Ø Ú á Û Ù Ý � ã ? A Ý � Ù Û ß Øã Ø ß à � ß Ø Ú á Û Ù Ý � ã � A ? B � x y A Ý Ù â Ý � Ù Û ß Ø ã Ø ß à � � Ú à â Þ Ü ß Û à Ù ã � D ? Ý Ù â � Ý Ú Ø â Ø � Ù Ø â Ý ã � à � � à � ã F

? x ]� x � a � a t _ � I � � ^ � � � ^ á Ý � � � Ý Ú Û ß s � a � a t _ ^ Ý Ú Û ß s � a K � � �

L à Ú Ý � � a ú c 7 e g g g e c i k c m t _ ß � Ø Ú Ø Ý Ú Ø ß � Ø � à � � à � Û Ù ä Ú Þ � Ø ã Û Ù � F

û n x � F c m k aû n K � F c m k a � c 7

g g gc m k a n c i

ù ê ê C D > æ < F ç C ç ò 6 > 6 ë < æ ç æ C < ô ç ò 6 / ì < ê ç æ C < è ó 4 ö C - è / D C 4 _ , D 6 D 6 F , D > 6 > , è ç 6 D 4 æ < , - è æ < 1 3 � þ ô, < > ç ò 6 D 6 , D 6 è é 6 ê æ , - ç 6 D 4 æ < , - è ê C D D 6 è é C < > æ < F ç C é , D , 4 6 ç 6 D é C è æ ç æ C < è � ^ ' ^ � � � 4 C > 6 - - æ < F è 6 - 6 ê ç æ C <

C / è ì ö ç 6 D 4 è ñ C D 6 , ê ò ê C < è ç , < ç è ó 4 ö C - æ < _ ç ò 6 D 6 æ è , ç D æ í æ , - D ì - 6 æ < 1 3 � þ ñ C D 6 , ê ò / ì < ê ç æ C <è ó 4 ö C - a t _ ï æ ç ò Ý Ú Û ß s � a K � ô ç ò 6 D 6 æ è C < 6 D ì - 6 é 6 D é , D , 4 6 ç 6 D é C è æ ç æ C < C / a æ < 1 3 � þ ñ # , ç ò è, D 6 ê C 4 é - 6 ç 6 é 6 D > 6 ë < æ ç æ C < ô æ ñ 6 ñ ô ç ò 6 ó , D 6 ç 6 D 4 æ < , ç 6 > ï æ ç ò , ê C < è ç , < ç è ó 4 ö C - ñ

M � Ý á � � Ø N D 1 6 ç ì è ê C < è æ > 6 D , è ó < ç , ø > 6 ë < æ ç æ C < C / , è æ 4 é - 6 / ì < ê ç æ C < , - - , < F ì , F 6 ô , < > ç ò 6 ê C D D 6 îè é C < > æ < F F D , 4 4 , D C / é , ç ò è ñ õ ò 6 D 6 , D 6 ç ò D 6 6 / C D 4 è C / 6 ø é D 6 è è æ C < è ô < , 4 6 - ó í , D æ , ö - 6 è � ê / ñ P R + S ôT î , ö è ç D , ê ç æ C < è � ê / ñ P + V W Y + ô , < > / ì < ê ç æ C < , é é - æ ê , ç æ C < è � ê / ñ + [ [ P \ ñ ì D ç ò 6 D 4 C D 6 ç ò 6 D 6 , D 6 ç ï C

J ^ _ ` a ` d e e h i d e j d k l ` i o e d a a _ a l r s d i u a d a l s s l a _ w i l a _ i a l r s d i u a r l | i u _ a d j _ l r d a ` � � _ a i � � _ i _ | � � � l e l � h � ^ _� � e e e d i _ | u d � _ i l o l � a � w _ | a _ i a l r o e d a a _ a l r s d i u a � � � r d o i � a _ i a l r a _ i a l r s d i u a w l _ a � l i a l ` � w � _ | h d s s _ d e � � � �

112

Page 123: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

/ C D 4 è C / ç ó é 6 6 ø é D 6 è è æ C < è ô < , 4 6 - ó ç ó é 6 î í , D æ , ö - 6 è � ê / ñ - R + S , < > , D D C ï ç ó é 6 è � ê / ñ + S S < � ñ å 6 ì è 6

< , ç ì D , - è ç C D 6 é D 6 è 6 < ç T î í , D æ , ö - 6 è , < > ç ó é 6 í , D æ , ö - 6 è ñ

� � �

� � � � � � � � � �

� � � � � � � " $ & � ) " � � � � � � �

- - � . � � � � " � � � � � � �

0 � � � � � � $ & � )

� � 4 5 � $ & � ) " $ & � ) � $ & � )

9 : � 4 � � � �

? @ A A � � � � � �

B C D � � F �

� � � � � � � 7 � �

� � � � � � � � 7 � �

� � � � � � � � ; $ & � )

� � � � � � � � I � � �

� � � � - - � . 7 � � �

� � � � - - � . ; � � �

$ & � ) � 0 � � 7 � �

$ & � ) � � � 4 5 7 $ & � )

$ & � ) � � � 4 5 ; $ & � )

� � � 9 : � 4

� � � ? @ A A 7 � �

# , ç ò è C / è C D ç M � � , D 6 D 6 é D 6 è 6 < ç 6 > , è , < � ù æ < æ F ì D 6 � ñ õ C ç ò æ è 6 < > ô ç ò 6 , ö C í 6 D 6 F ì - , D F D , 4 4 , Dæ è ç D æ í æ , - - ó ç D , < è / C D 4 6 > æ < ç C , < � ù ñ õ C ö 6 é D 6 ê æ è 6 ô ç ò 6 � ù , ê ê 6 é ç è ç ò 6 D 6 F ì - , D - , < F ì , F 6 � � M � � � � ñ

0

3 2 1

4 5 7

6

lvar

lambda

apply

1

succ

zero

3

1

2

tvar

arrow

{1, 2}

{1, 2}

M N O ¸ P ¸ � � o � � i t » » o º m w { � � � Q R S

ù ç 6 D 4 ê , < ö 6 , è è C ê æ , ç 6 > ï æ ç ò ç ò 6 è 6 ç C / , - - æ ç è é , ç ò è æ < , < , ç ì D , - ï , ó ñ � ì ê ò , 4 , é é æ < F æ è C ö í æ C ì è - ó

ì è 6 / ì - ç C > 6 ê æ > 6 æ / , F æ í 6 < ç 6 D 4 6 ø 6 D ê æ è 6 è , F æ í 6 < è 6 ç C / é , ç ò è � 4 6 , < ç ç C ê ò , D , ê ç 6 D æ è 6 , ç 6 è ç ê , è 6 ñ

õ ò 6 > 6 ê æ è æ C < ï C ì - > ö 6 è æ 4 é - ó ö , è 6 > C < , ç 6 è ç / C D < C < î 6 4 é ç ó æ < ç 6 D è 6 ê ç æ C < ñ

5 6 7 9 ; - ; < 9 T & � � Ø è 6 ç � � � � � U � � c � � C / é , ç ò è C / ç ò 6 ç 6 D 4 � C / è C D ç c Û ã â Ø � Ù Ø â Ý ã � à � � à � ã F

� � � � � xV � a � ^ � à Ú � x a

Wip X 7 � a Y Z � Z t � � � p � � � ^ � à Ú � x a � � 7 ^ � � � ^ � i ^ n o �

M � Ý á � � Ø [ D � C < è æ > 6 D ç ò 6 / C - - C ï æ < F ç 6 D 4 C / è C D ç M � � C í 6 D ç ò 6 è æ F < , ç ì D 6 / D C 4 " ø , 4 é - 6 � ú

+ [ [ P \ � P R + S � \ 6 S < ^ + [ [ P \ � P R + S � \ 6 S < ^ P R + S � / ^ _ _ � \ 6 S <

õ ò 6 è 6 ç C / é , ç ò è / C D ç ò æ è ç 6 D 4 æ è ç ò 6 / C - - C ï æ < F ú

� + [ [ P \ � P R + S � \ 6 S < ^+ [ [ P \ ' + [ [ P \ � P R + S � \ 6 S < ^+ [ [ P \ ' + [ [ P \ ' P R + S � / ^ _ _ � \ 6 S < �

113

Page 124: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

% & T � 6 � ^ P + S [ + - . 6 � [ S 6 / / ; < 9 /

å 6 ì è 6 D 6 F ì - , D 6 ø é D 6 è è æ C < è C í 6 D ç ò 6 ç 6 D 4 æ < , - è , < > < C < ç 6 D 4 æ < , - è C / 1 3 � þ ç C è é 6 ê æ / ó ê - , è è 6 è C /é , ç ò è ô ò 6 < ê 6 ï 6 ê , - - ç ò 6 4 D 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < è ñ � ì ê ò è 6 ç è ê ò , D , ê ç 6 D æ è 6 ç ò 6 ÷ æ < > C / ç 6 D 4 è ô ç ò , çæ è ô ç ò 6 ç 6 è ç ê , è 6 è ï ò æ ê ò ï 6 , D 6 æ < ç 6 D 6 è ç 6 > æ < ñ + 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < è è 6 D í 6 , è ê C < í 6 < æ 6 < ç ë < æ ç 6D 6 é D 6 è 6 < ç , ç æ C < è C / é C ç 6 < ç æ , - - ó æ < ë < æ ç 6 è 6 ç è C / é , ç ò è ñ { è ì , - - ó ô ï 6 ê C < è æ > 6 D é , ç ò è C / , ê 6 D ç , æ < è C D ç c ñù D 6 F ì - , D 6 ø é D 6 è è æ C < � ô ï ò æ ê ò C < 6 ï D æ ç 6 è > C ï < æ < ç ò 6 ë D è ç é - , ê 6 ô æ è C / ç 6 < 4 C D 6 é D C > ì ê ç æ í 6 ô , < >

ò 6 < ê 6 ô � � � � � ò , è ç C ö 6 D 6 è ç D æ ê ç 6 > ç C é D C é 6 D é , ç ò è � C / è C D ç c ö ó æ < ç 6 D è 6 ê ç æ C < ï æ ç ò � � c � � ñ õ C 6 ø é D 6 è è C ì Dæ < ç 6 < ç æ C < ç ò , ç � è ò C ì - > ê ò , D , ê ç 6 D æ è 6 é , ç ò è C / è C D ç c ô ï 6 ì è 6 > 6 ê - , D , ç æ C < è C / ç ò 6 / C D 4 � ú c ñ � æ < ê 6D 6 F ì - , D - , < F ì , F 6 è , D 6 ê - C è 6 > ì < > 6 D æ < ç 6 D è 6 ê ç æ C < ô ç ò 6 D 6 è ç D æ ê ç æ C < C / � ç C é D C é 6 D é , ç ò è C / è C D ç c æ èè C - 6 - ó é 6 D / C D 4 6 > , ç ç ò 6 - 6 í 6 - C / D 6 F ì - , D - , < F ì , F 6 è ñ

5 6 7 9 ; - ; < 9 % & � U � � Û ã Ý è 6 ç C / é , ç ò è C / è C D ç c Û � � U � � c � � D × Û � Ø Ù Ý ã à Ú ß Ý Ù Ù à ß Ý ß Ø â Ú Ø ä Þ � Ý Ú � Ý ß �

Ø � � Ú Ø ã ã Û à Ù � ú c A � Ø Þ ã Ø � � � ú c � � x � � � � � B � � c � � ß à â Ø Ù à ß Ø ß � Ø è 6 ç C / é , ç ò è C / è C D ç c ê C D D 6 è é C < > æ < F ç C� D � ß Ø Ú á � t u v � þ 6 ø 6 D ê æ è 6 è ç ò 6 è 6 ç � à � � Ý ß � ã à � ã à Ú ß c Û � � B � � � � � wx y D

M � Ý á � � Ø � D � C < è æ > 6 D , F , æ < ç ò 6 - , < F ì , F 6 è ó < ç , ø æ < ç D C > ì ê 6 > æ < " ø , 4 é - 6 � ñ å 6 ï , < ç ç C ê ò , D , ê îç 6 D æ è 6 é , ç ò è / C D < 6 è ç 6 > / ì < ê ç æ C < , é é - æ ê , ç æ C < è ñ õ ò 6 / C - - C ï æ < F D 6 F ì - , D 6 ø é D 6 è è æ C < é D C í æ > 6 è , è ì æ ç , ö - 6ê ò , D , ê ç 6 D æ è , ç æ C < / C D é , ç ò è ï æ ç ò é D 6 ê æ è 6 - ó Y o � < 6 è ç 6 > / ì < ê ç æ C < , é é - æ ê , ç æ C < è ú

Ý � � � s p x � � + [ [ P \ � � + [ [ P \ � � � ' � � + [ [ P \ � �

ü ì D æ < ç 6 < ç æ C < æ è ç C ê C < è æ > 6 D 6 ø é D 6 è è æ C < è C < - ó ô ò 6 < ê 6 ï 6 , < < C ç , ç 6 Ý � � � s p ï æ ç ò ç ò 6 è C D ç M � � ñ õ ò 6 � ù , ê ê 6 é ç æ < F ç ò 6 - , < F ì , F 6 � � Ý � � � s

; ú M � � � � x � � Ý � � � s; � � B � � M � � � � æ è è ò C ï < æ < æ F ì D 6 ' ñ ù è , < , è æ > 6 ô

ç ò 6 6 ø , 4 é - 6 æ < è ç , < ç æ , ç 6 è , è æ 4 é - 6 è ê 6 < , D æ C ï ò æ ê ò ï 6 C / ç 6 < ë < > æ < ç 6 è ç æ < F é , D è 6 D è C D - , < F ì , F 6é D C ê 6 è è C D è ô ç ò , ç æ è ô è ç D 6 è è ç 6 è ç æ < F ñ { è æ < F , - , D F 6 D Y æ < ç ò 6 , ö C í 6 è é 6 ê æ ë ê , ç æ C < ô , < > , é é - ó æ < F ç 6 è çè 6 ç F 6 < 6 D , ç æ C < ç C æ < ò , ö æ ç ç ò 6 ê C D D 6 è é C < > æ < F è 6 ç C / é , ç ò è ô ï 6 ê , < 6 < / C D ê 6 ê C 4 é - 6 ø ç 6 D 4 è / C D è ç D 6 è è

ç 6 è ç æ < F ñ

0

9

10 8 7 6

3 2 1

4 5 11

lambda

apply

3

{1, 2}

lambda

apply {1, 2}

apply

lvar

lambda

1

succ

zero

3

1

2

tvar

arrow

{1, 2}

M N O ¸ ¸ � � o � � i À W q � � 4 S S � O u �Q R S

� C ç 6 ç ò , ç æ ç > C 6 è < C ç D 6 , - - ó 4 , ÷ 6 , > æ � 6 D 6 < ê 6 æ / ï 6 è , ó ç ò , ç , ç 6 D 4 � 6 ø 6 D ê æ è 6 è

û , < , < < C ç , ç 6 > D 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < � ú c ô C D ,

û ê - , è è � U � � C / é , ç ò è C / è C D ç cè æ < ê 6 ç ò 6 ê - , è è C / é , ç ò è ê C D D 6 è é C < > æ < F ç C � ú c æ è ç D æ í æ , - - ó C ö ç , æ < 6 > ö ó � � g � � ñ � < ç ò 6 è 6 � ì 6 - ô ï 6 ï æ - -, è è ì 4 6 ç ò 6 ê C < í 6 < ç æ C < ç ò , ç D 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < è ê , < ö 6 ì è 6 > ï ò 6 < 6 í 6 D ê - , è è 6 è C / é , ç ò è , D 6, é é D C é D æ , ç 6 ñ õ ò æ è ï æ - - è æ 4 é - æ / ó C ì D é D 6 è 6 < ç , ç æ C < ñ

M � Ý á � � Ø � D õ ò 6 è , 4 é - 6 ç 6 D 4 F æ í 6 < æ < " ø , 4 é - 6 ' 6 ø 6 D ê æ è 6 è ç ò 6 Y î æ < > 6 ø 6 > 6 ø é D 6 è è æ C < è Ý � � � s p ú M � �/ C D < 6 è ç 6 > / ì < ê ç æ C < , é é - æ ê , ç æ C < è ê ò , D , ê ç 6 D æ è 6 > æ < " ø , 4 é - 6 � , è / C - - C ï è ú

# , ç ò Y æ < Ý � � � s p ú M � �

+ [ [ P \ � P R + S � \ 6 S < �+ [ [ P \ ' + [ [ P \ � P R + S � \ 6 S < '

+ [ [ P \ ' + [ [ P \ ' P R + S � / ^ _ _ � \ 6 S < '

114

Page 125: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

% & % � 6 + / ; W ; P ; - \ + 9 Y [ S < Y ^ _ - ; R ; - \

å 6 , D 6 ò , D > - ó æ < ç 6 D 6 è ç 6 > æ < D 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < è ï ò æ ê ò > C < C ç , > 4 æ ç , < ó é D C é 6 D é , ç ò ñ õ ò 6 ó, D 6 è C 4 6 ï ò , ç ì è 6 - ì è è æ < ê 6 ç ò 6 ó ê , < < C ç ö 6 6 ø 6 D ê æ è 6 > ñ � ó ê C < ç D , è ç ô ï 6 4 C è ç - ó / , í C ì D / 6 , è æ ö - 6 D 6 F ì - , D

é , ç ò 6 ø é D 6 è è æ C < è ô ç ò , ç æ è ú

5 6 7 9 ; - ; < 9 � & � � Ø ã à Ú ß Ý Ù Ù à ß Ý ß Ø â Ú Ø ä Þ � Ý Ú � Ý ß � Ø � � Ú Ø ã ã Û à Ù � ú c Û ã / 6 , è æ ö - 6 Û � � � � ú c � � wx y D

ù < 6 ø é D 6 è è æ C < � ú c ê , < ö 6 æ < / 6 , è æ ö - 6 / C D > æ � 6 D 6 < ç D 6 , è C < è ñ ù / ì < ê ç æ C < è ó 4 ö C - 4 æ F ò ç ö 6 ì è 6 > ï æ ç òç ò 6 ï D C < F , D æ ç ó ô C D ç ò 6 é , ç ò 6 ø é D 6 è è æ C < æ è æ < ê C 4 é - 6 ç 6 ñ å 6 4 æ F ò ç > æ è ê - C è 6 è ì ê ò 6 ø é D 6 è è æ C < è ö ó ,è ç , ç æ ê ï 6 - - î / C D 4 6 > < 6 è è ê ò 6 ê ÷ / C D 6 ø é D 6 è è æ C < è ñ õ ò æ è æ è < C ç é ì D è ì 6 > æ < ç ò 6 , D ç æ ê - 6 ñ ü ç ò 6 D D 6 , è C < è

/ C D æ < / 6 , è æ ö æ - æ ç ó , D 6 4 C D 6 - æ ÷ 6 , < æ < > æ ê , ç æ C < ç ò , ç é , ç ò è C / ç ò 6 è é 6 ê æ ë 6 > ÷ æ < > > C < C ç 6 ø æ è ç > ì 6ç C D 6 , ê ò , ö æ - æ ç ó , D F ì 4 6 < ç è ñ 6 , è æ ö æ - æ ç ó æ è , / ì < > , 4 6 < ç , - D 6 � ì æ D 6 4 6 < ç ñ õ ò 6 D 6 æ è , D 6 - , ç 6 > é D C ö - 6 4 ñ

ü < 6 4 æ F ò ç ï , < ç ç C D 6 � ì æ D 6 ç ò , ç , - - è ì ö 6 ø é D 6 è è æ C < è æ < , D 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < � ô 6 è é 6 ê æ , - - ó , - -, - ç 6 D < , ç æ í 6 è , < > , - - è ç , D è , < > é - ì è 6 è æ < � ô ê C < ç D æ ö ì ç 6 ç C � � � ú c � � � , < > < C ç � ì è ç ç C � � 6 � � ñ å 6 ê , - - ç ò , ç

é D C é 6 D ç ó � Ú à â Þ Ü ß Û � Û ß s ñ õ ò 6 é D C é 6 D ç ó ê C ì - > ö 6 6 < / C D ê 6 > ö ó , è ç , ç æ ê é D C > ì ê ç æ í æ ç ó ê ò 6 ê ÷ ô ç C C ñ

M � Ý á � � Ø � D õ ò 6 / C - - C ï æ < F 6 ø é D 6 è è æ C < è > 6 , - ï æ ç ò ç ò 6 è æ F < , ç ì D 6 æ < " ø , 4 é - 6 � ñ

� 7 x P + V W Y + �

� ; x P + V W Y + � P R + S � � � �

� I x � � � � P + V W Y + � � � �

� � x � � � � P + V W Y + � � � � � + S S < � � � � �

1 6 ç ì è 6 ø , 4 æ < 6 ç ò 6 è 6 6 ø é D 6 è è æ C < è ï æ ç ò D 6 F , D > ç C / 6 , è æ ö æ - æ ç ó , < > é D C > ì ê ç æ í æ ç ó ñ õ C ç ò æ è 6 < > ô ï 6è 6 - 6 ê ç ê 6 D ç , æ < è C D ç è ç C , < < C ç , ç 6 ç ò 6 6 ø é D 6 è è æ C < è ñ � 7 ú M � � æ è < C ç / 6 , è æ ö - 6 ö 6 ê , ì è 6 � 7 æ è C ö í æ C ì è - ó

æ < ê C 4 é - 6 ç 6 ô ç ò , ç æ è ô æ ç æ è < C ç ç 6 D 4 æ < , ç 6 > ï æ ç ò , ê C < è ç , < ç è ó 4 ö C - ñ � ; ú M � � æ è < C ç / 6 , è æ ö - 6 / C D è æ 4 é - 6ç ó é 6 , D F ì 4 6 < ç è ñ õ ò 6 è ó 4 ö C - P R + S æ è C / è C D ç M � � , è C é é C è 6 > ç C ç ò 6 ë D è ç é , D , 4 6 ç 6 D é C è æ ç æ C < C /P + V W Y + ï ò æ ê ò æ è C / è C D ç � Ý ß ñ � I ú � s � Ø æ è < C ç / 6 , è æ ö - ó / C D D 6 , ê ò , ö æ - æ ç ó D 6 , è C < è ô ç ò , ç æ è ç ò 6 / ì < ê ç æ C <è ó 4 ö C - P + V W Y + æ è C / è C D ç M � � ö ì ç 6 ø é D 6 è è æ C < è , D 6 < C ç D 6 , ê ò , ö - 6 C < é , ç ò è C / è C D ç � s � Ø ñ õ ò 6 ë D è ç, - ç 6 D < , ç æ í 6 C / � � ú � s � Ø æ è < C ç é D C > ì ê ç æ í 6 ö 6 ê , ì è 6 æ ç æ è 6 � ì , - ç C ç ò 6 æ < / 6 , è æ ö - 6 � I ñ

T Ð Y Ò � Ð T Y Ð Õ W Y T Y

ù è æ < F - 6 D 6 F ì - , D 6 ø é D 6 è è æ C < � æ è ì è ì , - - ó è ì ê æ 6 < ç ç C é D C í æ > 6 , < , ö è ç D , ê ç > 6 è ê D æ é ç æ C < C / , ç 6 è ç ê , è 6C D , ê - , è è C / ç 6 è ç ê , è 6 è ñ � / ï 6 ï , < ç ç C ê ò , D , ê ç 6 D æ è 6 , ç 6 è ç è 6 ç ô ï 6 , - è C < 6 6 > ç C D 6 è C D ç ç C , è 6 ç � C /D 6 F ì - , D 6 ø é D 6 è è æ C < è ñ " , ê ò 6 ø é D 6 è è æ C < æ < è ì ê ò , è 6 ç ê C D D 6 è é C < > è ç C , > æ � 6 D 6 < ç ê - , è è C / ç 6 è ç ê , è 6 è ñ C D è æ < F - 6 6 ø é D 6 è è æ C < è ô ï 6 ê C < è æ > 6 D 6 > / 6 , è æ ö æ - æ ç ó , < > é D C > ì ê ç æ í æ ç ó ñ C D è 6 ç è C / 6 ø é D 6 è è æ C < è ô è 6 í 6 D , -

C ç ò 6 D é D C é 6 D ç æ 6 è , D 6 < , ç ì D , - - ó > 6 ë < 6 > ô 6 ñ F ñ ô 4 æ < æ 4 , - æ ç ó , < > ê C 4 é - 6 ç 6 < 6 è è ñ { - ç æ 4 , ç 6 - ó ô ç ò 6 è 6 ê ç æ C <é D C í æ > 6 è D 6 � ì æ D 6 4 6 < ç è / C D è 6 ç è C / D 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < è ç C > 6 < C ç 6 , é D C é 6 D ê C í 6 D , F 6 ê D æ ç 6 D æ C < ñ

� & ( � 6 - / < � S 6 � ^ P + S [ + - . 6 � [ S 6 / / ; < 9 /

õ ò 6 / C - - C ï æ < F > 6 ë < æ ç æ C < é D C í æ > 6 è , ÷ æ < > C / 6 ø , 4 é - 6 / C D è 6 ç è D 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < è ñ � ç æ < ç D C > ì ê 6 èç ï C ö , è æ ê è 6 ç è C / 6 ø é D 6 è è æ C < è ñ õ ò 6 è 6 ç � �

�4 C > 6 - è ê C í 6 D , F 6 C / , - - ê C < è ç , < ç è ó 4 ö C - è æ < þ ñ õ ò 6 è 6 ç

L ��

4 C > 6 - è ê C í 6 D , F 6 C / , - - C ç ò 6 D / ì < ê ç æ C < è ó 4 ö C - è a æ < þ � æ ñ 6 ñ ô Ý Ú Û ß s � a K � ñ

5 6 7 9 ; - ; < 9 � &� �

� ú c x � Ü à Ù ã ß � � � t _ ^ Ý Ú Û ß s � � x � � � � Ø Ú Ø Ü à Ù ã ß � x � � � � �

L �� ú c x � � Þ Ù Ü � � a t _ ^ Ý Ú Û ß s � a K � ! � � Ø Ú Ø � Þ Ù Ü � x � � � � a � � � �

� C ç 6 ç ò , ç æ ç æ è 6 è è 6 < ç æ , - ç C ê C < è æ > 6 D è 6 ç è C / D 6 F ì - , D é , ç ò 6 ø é D 6 è è æ C < è æ < C D > 6 D ç C 6 � 6 ê ç æ í 6 - ó è 6 é , D , ç 6ç ò 6 ê - , è è 6 è C / ç 6 è ç ê , è 6 è ñ ü < 6 4 æ F ò ç / 6 6 - ç 6 4 é ç 6 > ç C > 6 ë < 6 ç ò 6 è 6 è 6 ç è , è , - æ è ç C / , - ç 6 D < , ç æ í 6 è ì è æ < Fç ò 6 D 6 F ì - , D C é 6 D , ç C D # � % ô 6 ñ F ñ ô / C D L �

� � ú M � � ú

� � � � P R + S � � � � � � � � � P + V W Y + � � � � � g g g � � � � � / ^ _ _ � � � �

115

Page 126: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� < , ê ê C D > , < ê 6 ç C � 6 ë < æ ç æ C < � ô æ ç ï C ì - > ö 6 è ì ê æ 6 < ç ç C 6 ø 6 D ê æ è 6 C < 6 , - ç 6 D < , ç æ í 6 ç C 6 ø 6 D ê æ è 6 ç ò 66 < ç æ D 6 6 ø é D 6 è è æ C < ñ õ ò æ è æ è æ < ê C < � æ ê ç ï æ ç ò ç ò 6 > 6 è æ D 6 > 4 6 , < æ < F C / L �

� � ú M � � ç C ê ò , D , ê ç 6 D æ è 6 , è 6 ç

C / , > æ � 6 D 6 < ç ê - , è è 6 è C / ç 6 è ç ê , è 6 è ñ õ C 6 ø 6 D ê æ è 6 , è 6 ç C / ê - , è è 6 è C / é , ç ò è ô æ < F 6 < 6 D , - ô ï 6 4 æ F ò ç , - è C< 6 6 > , è 6 ç C / ç 6 D 4 è D , ç ò 6 D ç ò , < � ì è ç , è æ < F - 6 ç 6 D 4 ñ 1 6 ç ì è F 6 < 6 D , - æ è 6 � 6 ë < æ ç æ C < � , ê ê C D > æ < F - ó ñ

5 6 7 9 ; - ; < 9 � & � U 1 � � � Û ã Ý è 6 ç C / ê - , è è 6 è C / é , ç ò è C / è C D ç c Û � Ø � Ø Ú s � t � Û ã Ý ã Ø ß à � � Ý ß � ã à �ã à Ú ß c D × Û � Ø Ù Ý ã à Ú ß Ý Ù Ù à ß Ý ß Ø â ã Ø ß à � Ú Ø ä Þ � Ý Ú Ø � � Ú Ø ã ã Û à Ù � ú c A � Ø Þ ã Ø � � � ú c � � x � � � � � � B � � c � � � � t � �ß à â Ø Ù à ß Ø ß � Ø è 6 ç C / ê - , è è 6 è C / é , ç ò è C / è C D ç c ê C D D 6 è é C < > æ < F ç C � D � � Ø ã Ø ß � U u v � þ à � ß Ø Ú á ãØ � Ø Ú Ü Û ã Ø ã ß � Ø ã Ø ß � à � Ü � Ý ã ã Ø ã à � � Ý ß � ã à � ã à Ú ß c Û � � à Ú Ý � � Ü � Ý ã ã Ø ã � t � ß � Ø Ú Ø Ø � Û ã ß ã Ý ß Ø Ú á � t �

ã Þ Ü � ß � Ý ß � Ø � Ø Ú Ü Û ã Ø ã � D

� C < è æ > 6 D ç ò 6 ê , è 6 ç ò , ç > æ � 6 D 6 < ç è 6 ç è C / è C D ç î , < < C ç , ç 6 > D 6 F ì - , D 6 ø é D 6 è è æ C < è è ò C ì - > ö 6 ê C 4 é , D 6 > ñ ù <æ < ç 6 D 6 è ç æ < F � ì 6 è ç æ C < æ è æ / C < 6 ê , < > 6 ë < 6 , é D 6 î C D > 6 D C < è 6 ç è / C D ç ò 6 è , 4 6 è C D ç c ñ � ì ê ò , é D 6 î C D > 6 Dê C ì - > 4 C > 6 - æ / C < 6 è 6 ç C / 6 ø é D 6 è è æ C < è æ è 4 C D 6 ê ò , - - 6 < F æ < F ç ò , < ç ò 6 C ç ò 6 D æ < ç ò 6 è 6 < è 6 ç ò , ç , - - ç 6 è çè 6 ç è / C D ç ò 6 / C D 4 6 D , - è C 6 ø 6 D ê æ è 6 ç ò 6 - , ç ç 6 D ñ � < / , ê ç ô æ < � 6 ê ç æ C < � ï 6 ï æ - - 6 ø , 4 æ < 6 è 6 í 6 D , - ê C < ê D 6 ç 6ê C í 6 D , F 6 ê D æ ç 6 D æ , æ < ç ò æ è D 6 è é 6 ê ç ñ

5 6 7 9 ; - ; < 9 � & × Û � Ø Ù ß � à ã Ø ß ã � Ý Ù â � � à � Ü � Ý ã ã Ø ã à � � Ý ß � ã à � ã à Ú ß c A � � Û ã Ü Ý � � Ø â Ý Ú Ø � Ù Ø á Ø Ù ß à �� � Ù à ß Ý ß Û à Ù � � � Û � � à Ú Ý � � � U u v � þ Û ß � à � â ã ß � Ý ß � Ø � Ø Ú Ü Û ã Ø ã � � Û á � � Û Ø ã � Ø � Ø Ú Ü Û ã Ø ã � D � � Ý Ù â� Ý Ú Ø 6 � ì æ í , - 6 < ç � Ù à ß Ý ß Û à Ù � � � � Û � Z à ß � � � � Ý Ù â � � � D

� & T * S < [ 6 S - ; 6 /

C D è æ < F - 6 6 ø é D 6 è è æ C < è � C D ê - , è è 6 è C / é , ç ò è ï 6 ê C < è æ > 6 D 6 > ç ò 6 é D C é 6 D ç æ 6 è C / / 6 , è æ ö æ - æ ç ó , < > é D C > ì ê îç æ í æ ç ó ñ 6 , è æ ö æ - æ ç ó ê , < ö 6 ç D æ í æ , - - ó - æ / ç 6 > / C D è 6 ç è ñ + 6 F , D > æ < F , è 6 ç C / 6 ø é D 6 è è æ C < è � ú c ô æ ç 4 æ F ò çö 6 ç ò 6 ê , è 6 ç ò , ç è C 4 6 C / ç ò 6 ê C D D 6 è é C < > æ < F è 6 ç è C / ê - , è è 6 è ê C æ < ê æ > 6 æ < � � � ú c � � ñ å 6 ê , - - � 6 D , è æ < Fæ < ç ò , ç ê , è 6 ñ ü < 6 ê C ì - > , - è C è , ó ç ò , ç � æ è < C ç é D C > ì ê ç æ í 6 æ < ç ò æ è ê , è 6 ñ ü / ê C ì D è 6 ô � æ è , - è C < C çé D C > ì ê ç æ í 6 æ / è C 4 6 6 ø é D 6 è è æ C < è æ < � , D 6 < C ç é D C > ì ê ç æ í 6 C < ç ò 6 æ D C ï < ñ

5 6 7 9 ; - ; < 9 � & � � Ø ã Ø ß � à � Ü � Ý ã ã Ø ã Û ã / 6 , è æ ö - 6 Û � y wt � D � ú c Û ã Ü Ý � � Ø â 6 D , è æ < F Û � � � � K � � � � ú c � � � D

1 æ ÷ 6 / C D æ < / 6 , è æ ö æ - æ ç ó ô , < 6 D , è æ < F è 6 ç C / 6 ø é D 6 è è æ C < è � 4 æ F ò ç æ < > æ ê , ç 6 , è é 6 ê æ ë ê , ç æ C < 6 D D C D ô C D æ ç4 æ F ò ç � ì è ç ö 6 æ 4 é - æ 6 > ö ó ç ò 6 ê C < ê D 6 ç 6 è æ F < , ç ì D 6 , ç ò , < > ñ � C ç 6 , - è C ç ò , ç æ / ç ï C C D 4 C D 6 ê - , è è 6 è , D 6< C ç / 6 , è æ ö - 6 æ < � � � ú c � � ô � æ è < 6 ê 6 è è , D æ - ó 6 D , è æ < F ñ

M � Ý á � � Ø � D � C < è æ > 6 D ç ò 6 / C - - C ï æ < F ç D æ í æ , - è æ F < , ç ì D 6 þ � � � ï æ ç ò ç ò 6 / ì < ê ç æ C < è ó 4 ö C - è a ú " ; k " 7 ô

% ú " I k " ; ô ( ú k " I ñ ü < 6 ê , < ê ò 6 ê ÷ ç ò , ç L �� + - - ú " 7 æ è 6 D , è æ < F ö 6 ê , ì è 6 � � � Þ Ù Ü � ú " 7 � � x � � � Þ Ù Ü 0 ú " 7 � � ô

æ ñ 6 ñ ô a , < > % , - ï , ó è # F C ç C F 6 ç ò 6 D % ñ C D , è æ F < , ç ì D 6 þ 2� 4 ô ï ò æ ê ò æ < , > > æ ç æ C < ç C þ � � � , - è C ê C < ç , æ < è

a � ú " ; k " 7 , < > % � ú " I k " ; ô L �� 7 9 : ú " 7 æ è < C ç 6 D , è æ < F ñ

1 6 ç ì è ê C < è æ > 6 D 4 C D 6 æ < ç 6 D 6 è ç æ < F é D C é 6 D ç æ 6 è C / è 6 ç è C / ê - , è è 6 è C / é , ç ò è ô 6 ñ F ñ ô ê C 4 é - 6 ç 6 < 6 è è � æ ñ 6 ñ ô , - -é D C é 6 D é , ç ò è , D 6 æ < è C 4 6 ê - , è è ô , < > 4 æ < æ 4 , - æ ç ó � æ ñ 6 ñ ô < C ê - , è è C / é , ç ò è æ è ê C 4 é - 6 ç 6 - ó è ì ö è ì 4 6 > ö ó, < C ç ò 6 D ñ

5 6 7 9 ; - ; < 9 ; & < Ø ß � Z Ø Ý ã Ø ß à � Ü � Ý ã ã Ø ã à � � Ý ß � ã à � ã à Ú ß c � D Ú D ß D Ý ã Û ä Ù Ý ß Þ Ú Ø þ D � � Ø ê C 4 é - 6 4 6 < ç� C / � Û ã â Ø � Ù Ø â Ý ã � � c � � ? W � D A Ø ã Ý s ß � Ý ß ß � Ø ã Ø ß � à � Ü � Ý ã ã Ø ã Û ã

û ê C 4 é - 6 ç 6 Û � � x y A

û 4 æ < æ 4 , - Û � w C � ^ � � t � � � D � � A

û > æ è � ì < ê ç æ í 6 Û � w C � ^ � � t � � � wx � � F � B � � wx y D

õ ò 6 D 6 , D 6 è C 4 6 è æ 4 é - 6 C ö è 6 D í , ç æ C < è ï C D ç ò 4 6 < ç æ C < æ < F ú

û � / � æ è 4 æ < æ 4 , - ô ç ò 6 < � æ è / 6 , è æ ö - 6 ñ

û � / � æ è > æ è � ì < ê ç æ í 6 , < > / 6 , è æ ö - 6 ô ç ò 6 < æ ç æ è 4 æ < æ 4 , - ñ

û � / � æ è ê C 4 é - 6 ç 6 ô ç ò 6 < � I � � æ è ê C 4 é - 6 ç 6 / C D , - - � � ñ

û � æ è , é , D ç æ ç æ C < æ < F C / � � c � � ô æ � æ ç æ è / 6 , è æ ö - 6 ô ê C 4 é - 6 ç 6 , < > > æ è � ì < ê ç æ í 6 ñ

116

Page 127: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� & % � 6 _ < R 6 S \ < � � 6 + / ; W ; P ; - \ � V ; 9 ; V + P ; - \ � _ < V [ P 6 - 6 9 6 / /

� < ç ì D < è C ì ç ç ò , ç ç ò 6 è é 6 ê æ ë ê , ç æ C < è C < 6 ï D æ ç 6 è > C ï < æ < ç ò 6 ë D è ç é - , ê 6 ô , D 6 æ < æ ç æ , - - ó ò , D > - ó < C < î6 D , è æ < F ô / 6 , è æ ö - 6 , < > 4 æ < æ 4 , - ô , < > è C 4 6 ç æ 4 6 è ç ò 6 ó , D 6 < C ç ê C 4 é - 6 ç 6 ñ å 6 ï æ - - 6 < ê C ì < ç 6 D è ì ê ò

è æ ç ì , ç æ C < è æ < � 6 ê ç æ C < � ï ò 6 < ï 6 > 6 ë < 6 ê 6 D ç , æ < ê C í 6 D , F 6 ê D æ ç 6 D æ , ñ 6 , è æ ö æ - æ ç ó ô 4 æ < æ 4 , - æ ç ó ô , < > ê C 4 îé - 6 ç 6 < 6 è è ê , < ö 6 D 6 ê C í 6 D 6 > ö ó ç ò 6 / C - - C ï æ < F C é 6 D , ç C D è ú

5 6 7 9 ; - ; < 9 ( � &< Ø ß � Z Ø Ý ã Ø ß à � Ü � Ý ã ã Ø ã à � � Ý ß � ã à � ã à á Ø ã à Ú ß c D

� � Ø ã Ø ß ã � � � A � � Ý Ú Ø â Ø � Ù Ø â Ý ã � à � � à � ã F

� � � x � � ? � � ��

� t � ^ � � x � � � t � � � � D � � � ? � y �

� � xV � ^ Û � � x y

� I � � ! ^ à ß � Ø Ú � Û ã Ø

å 6 4 æ F ò ç , - è C , é é - ó � g � , < > � g ç C è 6 ç è C / 6 ø é D 6 è è æ C < è ï æ ç ò C ì ç / ì D ç ò 6 D < C ç æ ê 6 ñ õ ò 6 > 6 ë < æ ç æ C < C /

� � / C D ê C 4 é - 6 ç æ < F � æ è è ç D , æ F ò ç / C D ï , D > ô ç ò , ç æ è ô ê C 4 é - 6 ç æ C < æ è > C < 6 ö ó æ < ê - ì > æ < F , < C ç ò 6 D è 6 ç C /

é , ç ò è æ < � ê C D D 6 è é C < > æ < F ç C ç ò 6 ê C 4 é - 6 4 6 < ç C / � ç ò 6 ì < æ C < C / , - - è 6 ç è æ < � ñ õ ò 6 > 6 ë < æ ç æ C < C / � � � ç C4 æ < æ 4 , - æ è 6 � æ è 4 C D 6 æ < í C - í 6 > ñ C D 6 í 6 D ó � t � ç ò 6 è ì ö è 6 ç � ? W � � æ è é D 6 è 6 D í 6 > , è , ê - , è è ñ H 6 D 6 ô � �> 6 < C ç 6 è , - - ê - , è è 6 è � � ï ò æ ê ò , D 6 é D C é 6 D è ì ö è 6 ç è C / � ñ õ ò ì è ô æ < , è 6 < è 6 ô ï 6 é D 6 è 6 D í 6 F D 6 , ç 6 è ç è ì ö è 6 ç è C /

� < C ç ê C í 6 D 6 > ö ó � � ñ õ ò 6 C é 6 D , ç C D è 4 6 6 ç è C 4 6 ê C < í 6 < æ 6 < ç é D C é 6 D ç æ 6 è è ì 4 4 , D æ � 6 > æ < ç ò 6 / C - - C ï æ < Fç ò 6 C D 6 4 ñ ù - - ç ò 6 è 6 é D C é 6 D ç æ 6 è , D 6 6 , è æ - ó é D C í 6 > ñ

� . 6 < S 6 V ( & L à Ú Ý � � ã Ø ß ã � A � � à � Ü � Ý ã ã Ø ã à � � Ý ß � ã à � ã à á Ø ã à Ú ß c F

N D � � � Û ã á Û Ù Û á Ý � D[ D � � Ø à � Ø Ú Ý ß à Ú � g � Û ã Û â Ø á � à ß Ø Ù ß D� D � � Û ã Ü à á � � Ø ß Ø D

� D � � Ø à � Ø Ú Ý ß à Ú � g Û ã Û â Ø á � à ß Ø Ù ß D� D � � � � x � � � � D� D � � � Û ã á Û Ù Û á Ý � A ß � Ø Ù � � Û ã Ý � ã à á Û Ù Û á Ý � D

� D � � � Û ã Ü à á � � Ø ß Ø A ß � Ø Ù � � � Û ã Ý � ã à Ü à á � � Ø ß Ø D� D W � x W � � � D� D � � � � D

N D � � � DN N D � � � " � I � � $ D

� ç æ è æ < è ç D ì ê ç æ í 6 ç C ê C < è æ > 6 D ç ï C ê , < > æ > , ç 6 è / C D è æ 4 é - 6 D > 6 ë < æ ç æ C < è / C D � g � ñ õ ò 6 è 6 > 6 ë < æ ç æ C < è , D 6

, é é 6 , - æ < F , ç , ë D è ç F - , < ê 6 ú

� ñ � � t � � � wx y F w C � � t � � � D � � � � D 6 , ç 6 è ç 6 - 6 4 6 < ç è ' ñ � � t � � � wx y F w C � � t � � � � wx y F � � D � � � � 4 , - - 6 è ç 6 - 6 4 6 < ç è

� < ç ò 6 ë D è ç / C D 4 ì - , ç æ C < ô ç ò 6 è 4 , - - 6 D 6 - 6 4 6 < ç è > C < C ç ê C < ç D æ ö ì ç 6 è 6 é , D , ç 6 ê - , è è 6 è ñ � < ç ò 6 è 6 ê C < >

/ C D 4 ì - , ç æ C < ô ç ò 6 , > > æ ç æ C < , - é , ç ò è ê C í 6 D 6 > ö ó ç ò 6 - , D F 6 D 6 - 6 4 6 < ç è > C < C ç ê C < ç D æ ö ì ç 6 ñ C D ö C ç ò

/ C D 4 ì - , ç æ C < è ô ç ò 6 í , - ì , ö - 6 é D C é 6 D ç ó � � ñ æ < õ ò 6 C D 6 4 � æ è æ < í , - æ > ñ C D ç ò 6 è 6 ê C < > / C D 4 ì - , ç æ C < ô < C ç

6 í 6 < � � ñ æ è í , - æ > , < ó 4 C D 6 ñ

� / ï 6 , D 6 / , ê 6 > ï æ ç ò æ < / 6 , è æ ö æ - æ ç ó ô < C < î 4 æ < æ 4 , - æ ç ó ô , < > æ < ê C 4 é - 6 ç 6 < 6 è è ô � g � , < > � g è ò C ì - > < C ç

ö 6 , é é - æ 6 > ö - æ < > - ó / C D ç ò 6 è , ÷ 6 C / 4 æ < æ 4 , - æ ç ó , < > ê C 4 é - 6 ç 6 < 6 è è ñ å 6 è ò C ì - > ì < > 6 D è ç , < > ï ò , ç

ê , ì è 6 è < C < î 4 æ < æ 4 , - æ ç ó , < > æ < ê C 4 é - 6 ç 6 < 6 è è æ < 6 , ê ò é , D ç æ ê ì - , D ê , è 6 ñ � < / , ê ç ô ç ò 6 D 6 , D 6 è C 4 6 ç æ 4 6 è

F C C > D 6 , è C < è ï ò ó è C 4 6 C / ç ò 6 > 6 è æ D , ö - 6 é D C é 6 D ç æ 6 è > C < C ç ò C - > ñ å 6 æ - - ì è ç D , ç 6 ç ò æ è é D C ö - 6 4 æ < ç ò 6

/ C - - C ï æ < F ç ò 6 C D 6 4 , < > ç ò 6 ê C D D 6 è é C < > æ < F é D C C / ñ

� . 6 < S 6 V T &

N D � �� ú c Û ã â Û ã & Þ Ù Ü ß Û � Ø Ý Ù â Ü à á � � Ø ß Ø Z Þ ß Ù à ß Ù Ø Ü Ø ã ã Ý Ú Û � s � Ø Ý ã Û Z � Ø � à Ú Ý � � þ A c D

[ D L �� ú c Û ã Ù Ø Û ß � Ø Ú Ù Ø Ü Ø ã ã Ý Ú Û � s � Ø Ý ã Û Z � Ø A Ü à á � � Ø ß Ø A á Û Ù Û á Ý � A Ù à Ú â Û ã & Þ Ù Ü ß Û � Ø � à Ú Ý � � þ A c D

117

Page 128: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� Ú à à � D

� ñ � � æ è > æ è � ì < ê ç æ í 6 ö 6 ê , ì è 6 ê C < è ç , < ç è C < - ó C ê ê ì D , è é , ç ò ç 6 D 4 æ < , ç C D è ô æ ñ 6 ñ ô , é , ç ò ê , < < 6 í 6 Dê C < ç , æ < ç ï C � > æ � 6 D 6 < ç ê C < è ç , < ç è ñ õ ò 6 D 6 ö ó ô ç ò 6 ê - , è è 6 è C / é , ç ò è / C D ç ò 6 í , D æ C ì è ê C < è ç , < ç è , D 6> æ è � C æ < ç ñ � � 4 æ F ò ç æ < > 6 6 > ê C < ç , æ < ç ò 6 6 4 é ç ó è 6 ç æ / ê 6 D ç , æ < è C D ç è , < > ç ò 6 D 6 ö ó ê C < è ç , < ç è C / ç ò , çè C D ç , D 6 < C ç D 6 , ê ò , ö - 6 / D C 4 ç ò 6 F æ í 6 < c ñ � � æ è ê C 4 é - 6 ç 6 ö 6 ê , ì è 6 , - - ê C < è ç , < ç è , D 6 6 ø ò , ì è ç 6 >

ö ó æ ç ô , < > C ç ò 6 D ï æ è 6 ç ò 6 é , ç ò è , D 6 < C ç ê C < è ç D , æ < 6 > ñ' ñ L � 4 æ F ò ç æ < > 6 6 > ê C < ç , æ < ç ò 6 6 4 é ç ó è 6 ç æ / ê 6 D ç , æ < è C D ç è , < > ç ò 6 D 6 ö ó è ó 4 ö C - è C / ç ò , ç è C D ç , D 6 < C ç

D 6 , ê ò , ö - 6 / D C 4 ç ò 6 F æ í 6 < c ñ L �� ú c æ è æ < ê C 4 é - 6 ç 6 æ / ç ò 6 D 6 , D 6 < C C ç ò 6 D / ì < ê ç æ C < è ó 4 ö C - è C / è C D ç

c ö ì ç ê C < è ç , < ç è ó 4 ö C - è ñ L �� ú c æ è < C ç > æ è � ì < ê ç æ í 6 ñ H 6 D 6 æ è , < 6 ø , 4 é - 6 ú � C < è æ > 6 D L �

� � ú M � � ñ

ü ö í æ C ì è - ó ô � Þ Ù Ü - - � . ú M � � , < > � Þ Ù Ü

� � � � ú M � � ò , í 6 è C 4 6 é , ç ò è æ < ê C 4 4 C < ñ õ ò æ è D 6 � 6 ê ç èç ò , ç ç ò 6 D 6 , D 6 é , ç ò è æ < ï ò æ ê ò ö C ç ò + [ [ P \ , < > P + V W Y + C ê ê ì D ñ ù è / C D < C < î 4 æ < æ 4 , - æ ç ó ô ï 6 è 6 6ç ò , ç � Þ Ù Ü

� � � ú M � � è ì ö è ì 4 6 è � Þ Ù Ü - - � . ú M � � , < > � Þ Ù Ü

� � � � ú M � � ô è æ < ê 6 , < ó 6 ø é D 6 è è æ C < C /è C D ç M � � < 6 ê 6 è è , D æ - ó ò , è ç C 6 ø 6 D ê æ è 6 ç ò 6 è ó 4 ö C - P R + S ñ

õ ò 6 è 6 ê ç æ C < æ è ê C < ê - ì > 6 > ï æ ç ò ç ò 6 ì - ç æ 4 , ç 6 > 6 ë < æ ç æ C < C / , ê C í 6 D , F 6 ê D æ ç 6 D æ C < ñ � ç æ è ê 6 D ç , æ < - ó > 6 è æ D , ö - 6ç ò , ç , é D C é 6 D ê C í 6 D , F 6 ê D æ ç 6 D æ C < � 4 6 6 ç è ê C 4 é - 6 ç 6 < 6 è è ô ç ò , ç æ è ô 6 í 6 D ó é C è è æ ö - 6 é , ç ò æ è ê C < ç , æ < 6 >æ < è C 4 6 ê - , è è æ < � ñ � < ç ò 6 / C - - C ï æ < F > 6 ë < æ ç æ C < ô ï 6 , - è C é C è ç ì - , ç 6 4 æ < æ 4 , - æ ç ó ñ ü ì D 6 ø é 6 D æ 6 < ê 6 ï æ ç ò> 6 ë < æ < F ê C í 6 D , F 6 ê D æ ç 6 D æ , æ < > æ ê , ç 6 è ç ò , ç ç ò 6 D 6 � ì æ D 6 4 6 < ç / C D 4 æ < æ 4 , - æ ç ó æ è é C è è æ ö - ó > 6 ö , ç , ö - 6 ñ å 6> 6 ë < æ ç 6 - ó > C < C ç æ < è æ è ç C < > æ è � ì < ê ç æ í 6 è 6 ç è è æ < ê 6 ç ò 6 è é 6 ê æ ë ê , ç æ C < è C < 6 ï D æ ç 6 è > C ï < æ < ç ò 6 ë D è ç

é - , ê 6 ò , D > - ó 4 6 6 ç ç ò æ è D 6 � ì æ D 6 4 6 < ç ñ � < / , ê ç ô ç ò 6 , ö C í 6 é D C C / æ - - ì è ç D , ç 6 è ç ò , ç < C < î > æ è � ì < ê ç æ í 6 è 6 ç èC / ê - , è è 6 è 4 æ F ò ç ö 6 è 6 < è æ ö - 6 ñ ù < C é 6 D , ç C D / C D D 6 ê C í 6 D ó C / > æ è � ì < ê ç æ í 6 è 6 ç è æ è ê C < ê 6 æ í , ö - 6 ñ

5 6 7 9 ; - ; < 9 ( ( & � ã Ø ß � à � Ü � Ý ã ã Ø ã à � � Ý ß � ã à � ã à Ú ß c Û ã Ý é D C é 6 D ê C í 6 D , F 6 ê D æ ç 6 D æ C < Û � � Û ã á Û Ù Û á Ý �

Ý Ù â Ü à á � � Ø ß Ø D

ù - ç ò C ì F ò ç ò 6 > 6 ë < æ ç æ C < ç , - ÷ è , ö C ì ç è 6 ç è C / ê - , è è 6 è C / é , ç ò è D , ç ò 6 D ç ò , < è 6 ç è C / D 6 F ì - , D é , ç ò 6 ø é D 6 è îè æ C < è ô ï 6 ï æ - - ì è ì , - - ó D 6 , è C < , ö C ì ç ê C í 6 D , F 6 ê D æ ç 6 D æ , 4 , æ < - ó , ç ç ò 6 - 6 í 6 - C / ç ò 6 é , ç ò 6 ø é D 6 è è æ C < è ñ

� � Ò � T Ñ W � T Õ Ñ Ö Ð T Ñ Ö W

å 6 > 6 í 6 - C é í , D æ C ì è ê C í 6 D , F 6 ê D æ ç 6 D æ , è ç , D ç æ < F / D C 4 , < , ö è ç D , ê ç / C D 4 C / D ì - 6 ê C í 6 D , F 6 ÷ < C ï < / C Dê C < ç 6 ø ç î / D 6 6 F D , 4 4 , D è ñ õ ò 6 è ì ö è 6 � ì 6 < ç ê D æ ç 6 D æ , , D 6 C D æ F æ < , - ê C < ç D æ ö ì ç æ C < è C / ç ò 6 , D ç æ ê - 6 ñ

� & ( � S + 9 _ . _ < R 6 S + � 6

� � , < > L � / D C 4 � 6 ë < æ ç æ C < � é D C í æ > 6 ç ò 6 ö , è æ è / C D , è æ 4 é - 6 ê C í 6 D , F 6 ê D æ ç 6 D æ C < ê , - - 6 > Z Ú Ý Ù Ü � Ü à � Ø Ú

Ý ä Ø ñ õ ò æ è ê D æ ç 6 D æ C < ê C D D 6 è é C < > è ç C D ì - 6 ê C í 6 D , F 6 ï ò 6 < , é é - æ 6 > ç C ê C < ç 6 ø ç î / D 6 6 F D , 4 4 , D è � # ì D � ' ö � ñ� D , < ê ò ê C í 6 D , F 6 � � � æ è , è ì æ ç , ö - 6 ç 6 D 4 ö 6 ê , ì è 6 F æ í 6 < , è C D ç ô ç ò 6 í , D æ C ì è / ì < ê ç æ C < è ó 4 ö C - è C /è C D ç é D C í æ > 6 ç ò 6 , - ç 6 D < , ç æ í 6 è ç C ê C < è ç D ì ê ç ç 6 D 4 è C / è C D ç ñ � � 6 < / C D ê 6 è ç ò , ç , - - è ó 4 ö C - è C / , - -è C D ç è , D 6 6 ø 6 D ê æ è 6 > ñ õ ò ì è ô ï 6 4 æ F ò ç è , ó ç ò , ç , - - ö D , < ê ò 6 è , D 6 ê C í 6 D 6 > ñ

5 6 7 9 ; - ; < 9 ( T & � ��

â Ø Ù à ß Ø ã ß � Ø ö D , < ê ò ê C í 6 D , F 6 ê D æ ç 6 D æ C < / C D þ F

� �� ú c x � � �

� I L ��

M � Ý á � � Ø � D � C < è æ > 6 D ç ò 6 / C - - C ï æ < F ç ï C ç 6 D 4 è ú

û + [ [ P \ � P + V W Y + � \ 6 S < ^ - R + S � \ 6 S < ^ P R + S � \ 6 S < ^ P R + S � / ^ _ _ � \ 6 S <

û + [ [ P \ � P R + S � \ 6 S < ^ P R + S � \ 6 S <

õ ò 6 ë D è ç ç 6 D 4 6 ø 6 D ê æ è 6 è � � M � � ö 6 ê , ì è 6 æ ç ê C í 6 D è , - - / ì < ê ç æ C < è ó 4 ö C - è C / ç ò 6 è æ F < , ç ì D 6 / D C 4" ø , 4 é - 6 � ñ � < è ç 6 , > C / ç ò æ è - , D F 6 ç 6 D 4 ô ï 6 ê C ì - > , - è C / , í C ì D è 4 , - - 6 D ç 6 D 4 è ê C í 6 D æ < F ç ò 6 í , D æ C ì è

/ ì < ê ç æ C < è ó 4 ö C - è æ < è 6 é , D , ç æ C < ñ õ ò 6 è 6 ê C < > ç 6 D 4 , ö C í 6 æ è ç ò 6 è 4 , - - 6 è ç ç 6 D 4 � æ < ç 6 D 4 è C / ç ò 6< ì 4 ö 6 D C / / ì < ê ç æ C < è ó 4 ö C - è æ < í C - í 6 > ê C í 6 D æ < F + [ [ P \ ñ

118

Page 129: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� . 6 < S 6 V % &

N D � �� ú c Û ã Ý � Ú à � Ø Ú Ü à � Ø Ú Ý ä Ø Ü Ú Û ß Ø Ú Û à Ù � à Ú Ý � � þ A c D

[ D � �� ú c � �

� ú c A L ��

� ��

� à Ú Ý � � þ A c D

� D � � Ø Ú Ø Ø � Û ã ß ã þ A c ã Þ Ü � ß � Ý ß � �� ú c w� � �

� ú c A L �� ú c w� � �

� ú c D

� Ú à à � D

� ñ � C 4 é - 6 ç 6 < 6 è è / C - - C ï è / D C 4 ç ò 6 ì < æ C < ï æ ç ò � ��

ï ò æ ê ò æ è ê C 4 é - 6 ç 6 C < æ ç è C ï < ñ' ñ � 4 é - æ 6 > ö ó � � � ñ æ < õ ò 6 C D 6 4 � ñ

� ñ H 6 D 6 , D 6 6 ø , 4 é - 6 è 6 ø é - C D æ < F ç ò 6 , > > æ ç æ C < , - 6 ø é D 6 è è æ í 6 < 6 è è F , æ < 6 > ö ó � ��

ê C 4 é , D 6 > ç C � ��

, < > L �� ú � C < è æ > 6 D , F , æ < ç ò 6 è æ F < , ç ì D 6 / D C 4 " ø , 4 é - 6 � ñ å 6 ò , í 6 ç ò , ç � �

� � ú M � � w� � �� � ú

M � � ö 6 ê , ì è 6 P R + S � \ 6 S < 6 ø 6 D ê æ è 6 è � �� � ú M � � ô ö ì ç < C ç � �

� � ú M � � ñ å 6 , - è C ò , í 6 ç ò , çL �

� � ú M � � � � �� � ú M � � ö 6 ê , ì è 6 , - - ç 6 D 4 è < 6 ê 6 è è , D æ - ó 6 ø 6 D ê æ è 6 ç ò 6 C < 6 , < > C < - ó ê C < è ç , < ç

\ 6 S < ñ ù è è ì 4 6 ç ò , ç ï 6 , > > , < C ç ò 6 D ê C < è ç , < ç ; 9 - ú k ß s � Ø ç C þ � D 6 è ì - ç æ < F æ < , < 6 ø ç 6 < > 6 >è æ F < , ç ì D 6 þ � � ñ õ ò 6 < ô ï 6 ê , < è ò C ï ç ò , ç L �

� � � ú M � � w� � �� � � ú M � � ö 6 ê , ì è 6 ç ò 6 D 6 , D 6 ç 6 D 4 è

6 ø 6 D ê æ è æ < F L �� � � ú M � � ï æ ç ò C ì ç ì è æ < F ; 9 - ô 6 ñ F ñ ú

+ [ [ P \ � P + V W Y + � \ 6 S < ^ + S S < � � - R + S � \ 6 S < ^ - R + S � \ 6 S < ^ P R + S � \ 6 S < ^ P R + S � / ^ _ _ � \ 6 S <

� & T * < / ; - ; < 9 _ < R 6 S + � 6

ù 4 æ < C D F 6 < 6 D , - æ è , ç æ C < C / ö D , < ê ò ê C í 6 D , F 6 æ è ç C ç , ÷ 6 é , D , 4 6 ç 6 D é C è æ ç æ C < è C / ç ò 6 / ì < ê ç æ C < è ó 4 ö C - èæ < ç C , ê ê C ì < ç ñ å 6 ê , - - ç ò æ è F 6 < 6 D , - æ è , ç æ C < é C è æ ç æ C < ê C í 6 D , F 6 � � � ñ ù è æ ç ï æ - - ç ì D < C ì ç ô � � æ è < C ç ,é D C é 6 D D 6 ë < 6 4 6 < ç C / � � ô ö ì ç � � , < > � � , D 6 è æ 4 é - ó 6 � ì æ í , - 6 < ç ñ H 6 < ê 6 ô ï 6 ê C < è æ > 6 D � � , è , <æ - - ì è ç D , ç æ í 6 6 ø , 4 é - 6 ñ

5 6 7 9 ; - ; < 9 ( % & � ��

â Ø Ù à ß Ø ã ß � Ø é C è æ ç æ C < ê C í 6 D , F 6 ê D æ ç 6 D æ C < / C D þ F

� �� ú c x " � �

� I � � à ã �9 p � a t _ ^ � � Y � Ý Ú Û ß s � a ! $ � � Ø Ú Ø � à ã �

9 p x � � � � a Y � � � �

� . 6 < S 6 V � &

N D � � � à ã �9 p ú c � � U � � � Þ Ù Ü � ú c � � � à Ú Ý � � þ A c A a A Y � � Ø Ú Ø � � Y � Ý Ú Û ß s � a D

[ D � � � D � � � Û Ù N D Û � Ý Ú Û ß s � a K � D

� D � � Ø Ú Ø Ø � Û ã ß þ A c ã Þ Ü � ß � Ý ß � � �� ú c � � � � �

� ú c � D

� D � Ø � Ø Ú Ü Û ã Ø ã � � � Þ Ù Ü � ú c � � � � Ø � Ø Ú Ü Û ã Ø ã � � � à ã �9 p ú c � � � à Ú Ý � � þ A c A � t u v � þ D

� D � �� ú c � � �

� ú c � à Ú Ý � � þ A c D

� Ú à à � D

� ñ � Þ Ù Ü � æ è è ì ö > æ í æ > 6 > æ < ç C ç ò 6 í , D æ C ì è � à ã �9 p ñ

' ñ ü ö í æ C ì è ñ � H 6 < ê 6 ô C < 6 4 æ F ò ç ç ò æ < ÷ ç ò , ç � � æ è 4 C D 6 ë < 6 î F D , æ < 6 > ç ò , < � � ñ � ñ ü ö í æ C ì è ñ � � ç æ - - ô C < 6 4 æ F ò ç ç ò æ < ÷ ç ò , ç � � æ è 4 C D 6 ë < 6 î F D , æ < 6 > ç ò , < � � ñ

ñ ù < ó ç 6 D 4 ï æ ç ò , < , é é - æ ê , ç æ C < C / a < 6 ê 6 è è , D æ - ó 6 ø 6 D ê æ è 6 è ç ò 6 í , D æ C ì è é , D , 4 6 ç 6 D é C è æ ç æ C < è C / a ñ

H 6 < ê 6 ô ç ò 6 D 6 , D 6 é , ç ò è æ < � � � � � ï ò æ ê ò > C < C ç 6 ø 6 D ê æ è 6 , ê 6 D ç , æ < é , D , 4 6 ç 6 D é C è æ ç æ C < Y C / a ô ö ì çç ò 6 D 6 , D 6 < 6 ê 6 è è , D æ - ó C ç ò 6 D é , ç ò è ï ò æ ê ò > C ñ

� ñ � æ D 6 ê ç - ó æ 4 é - æ 6 > ö ó ñ

� & % � < 9 - 6 � - � Y 6 [ 6 9 Y 6 9 - W S + 9 _ . _ < R 6 S + � 6

1 6 ç ì è ê C < è æ > 6 D , 4 C D 6 æ < í C - í 6 > ê D æ ç 6 D æ C < ñ å 6 ï , < ç ç C ê ò , D , ê ç 6 D æ è 6 é , ç ò è ï ò 6 D 6 , / ì < ê ç æ C < è ó 4 ö C -

% æ è ì è 6 > C < ç ò 6 Y î ç ò é , D , 4 6 ç 6 D é C è æ ç æ C < C / , < C ç ò 6 D / ì < ê ç æ C < è ó 4 ö C - a ñ � / ï 6 ê C < è æ > 6 D , - - é C è è æ îö - 6 ê - , è è 6 è ô ï 6 C ö ç , æ < æ < , è 6 < è 6 , ê C < ç 6 ø ç î > 6 é 6 < > 6 < ç í 6 D è æ C < C / � � ñ õ ò ì è ï 6 ê , - - æ ç Ü à Ù ß Ø � ß

â Ø � Ø Ù â Ø Ù ß Z Ú Ý Ù Ü � Ü à � Ø Ú Ý ä Ø � � � � � ñ

119

Page 130: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

5 6 7 9 ; - ; < 9 ( � & � � � ��

â Ø Ù à ß Ø ã ß � Ø ê C < ç 6 ø ç î > 6 é 6 < > 6 < ç ö D , < ê ò ê C í 6 D , F 6 ê D æ ç 6 D æ C < / C D þ F

� � � �� ú c x

���� � �� I �� � � Û Ù � �

9 p 90

������

a ú c 7 e g g g e c i k c m t _ ^

% ú g g g k c p t _ ^

� � Y � n

� ��

� � Ø Ú Ø � Û Ù � �

9 p 90 x � � � � a Y % � � � � D

� C ç 6 ò C ï ç ò 6 ç ó é 6 è C / a , < > % , D 6 ê C < è ç D , æ < 6 > æ < ç ò 6 > 6 ë < æ ç æ C < ç C 6 < / C D ê 6 ï 6 - - î / C D 4 6 > 6 ø é D 6 è è æ C < è ôç ò , ç æ è ô % � è D 6 è ì - ç è C D ç æ è ç ò 6 è , 4 6 , è a � è Y î ç ò é , D , 4 6 ç 6 D è C D ç ñ

� . 6 < S 6 V � &

N D � � � �� ú c Û ã Ý � Ú à � Ø Ú Ü à � Ø Ú Ý ä Ø Ü Ú Û ß Ø Ú Û à Ù � à Ú Ý � � þ A c D

[ D � ��

� � � ��

� à Ú Ý � � þ A c D

� D � � Ø Ú Ø Ø � Û ã ß þ A c ã Þ Ü � ß � Ý ß � �� ú c w� � � � �

� ú c D

� Ú à à � D ü 4 æ ç ç 6 > ñ õ ò 6 è ê ò 6 4 6 C / ç ò 6 é D C C / / C D õ ò 6 C D 6 4 � ê , < ö 6 D 6 ì è 6 > ñ

M � Ý á � � Ø � D õ ò 6 è 6 , D 6 , - - ê C 4 ö æ < , ç æ C < è C / / ì < ê ç æ C < è ó 4 ö C - è ô é , D , 4 6 ç 6 D é C è æ ç æ C < è ô , < > / ì < ê ç æ C <è ó 4 ö C - è C < ç ò 6 - , ç ç 6 D é C è æ ç æ C < è / C D ç ò 6 è æ F < , ç ì D 6 þ

�/ D C 4 " ø , 4 é - 6 � ú� � � � � � � � �� � � � � � � � �� � " $ & � � � � � �� � " $ & � � � � � �� � " $ & � ) + � � �� � " $ & � ) � � � � /� � " $ & � 1 � � � �� � " $ & � 1 � � " $ & �

� � " $ & � 1 � 5 5 � 8� 5 5 � 8 � � � � �� 5 5 � 8 � � � " $ & �� 5 5 � 8 � � 5 5 � 8� 5 5 � 8 ) � � � �� 5 5 � 8 ) � � " $ & �� 5 5 � 8 ) � 5 5 � 8+ � � � � � � � �

+ � � � � � � � �� � � � / � + � � �� � � � / � � � � � /� � � � / ) + � � �� � � � / ) � � � � /� � � � � � � � �� � � � � � � � �ù è ï 6 , D F ì 6 > / C D ö D , < ê ò ê C í 6 D , F 6 æ < " ø , 4 é - 6 � ô ï 6 4 æ F ò ç / , í C ì D 6 æ ç ò 6 D è 4 , - - ç 6 è ç ê , è 6 è 6 ø 6 D ê æ è æ < F

ç ò 6 è 6 ê C 4 ö æ < , ç æ C < è ô C D - , D F 6 D ç 6 è ç ê , è 6 è ê C í 6 D æ < F 4 C D 6 C / ç ò 6 ê C 4 ö æ < , ç æ C < è , ç C < ê 6 ñ C D ö D 6 í æ ç ó ô ï 6> C < C ç æ < ê - ì > 6 , < � , - D 6 , > ó è C 4 6 ï ò , ç - , D F 6 D ç 6 è ç è 6 ç 6 ø 6 D ê æ è æ < F � � � � / C D ç ò 6 D ì < < æ < F 6 ø , 4 é - 6 ñ

� < æ F ì D 6 � ô C < 6 é , D ç æ ê ì - , D è 6 ç ê C < ç D æ ö ì ç æ < F ç C � � � �� � ú M � � æ è è ò C ï < ô < , 4 6 - ó ç ò 6 ê - , è è ï ò æ ê ò

> 6 , - è ï æ ç ò , T î , ö è ç D , ê ç æ C < C < ç ò 6 ë D è ç é , D , 4 6 ç 6 D é C è æ ç æ C < C / , / ì < ê ç æ C < , é é - æ ê , ç æ C < ñ

� & � � 6 + _ . + W ; P ; - \ _ < R 6 S + � 6

õ ò 6 D 6 æ è , D , ç ò 6 D C ö í æ C ì è ï , ó ò C ï ê C < ç 6 ø ç î > 6 é 6 < > 6 < ç ê C í 6 D , F 6 ê , < ö 6 F 6 < 6 D , - æ è 6 > ñ � � � � æ èè ì ê æ 6 < ç ç C 6 ø 6 D ê æ è 6 , - - é C è è æ ö - 6 / ì < ê ç æ C < è ó 4 ö C - è æ < , - - > æ D 6 ê ç ê C < ç 6 ø ç è ô ç ò , ç æ è æ < é , D , 4 6 ç 6 D

é C è æ ç æ C < è C / / ì < ê ç æ C < è ó 4 ö C - è C / , è ì æ ç , ö - 6 è C D ç ñ å 6 ê , < , - è C - C C ÷ / C D D 6 4 C ç 6 é , æ D è C / / ì < ê ç æ C <è ó 4 ö C - è ñ � C < ç 6 ø ç î > 6 é 6 < > 6 < ç ö D , < ê ò î ê C í 6 D , F 6 C < - ó D 6 - , ç 6 è , > � , ê 6 < ç è ó 4 ö C - è æ < ç 6 D 4 è ñ

5 6 7 9 ; - ; < 9 ( � & � ��

â Ø Ù à ß Ø ã ß � Ø D 6 , ê ò , ö æ - æ ç ó ê C í 6 D , F 6 ê D æ ç 6 D æ C < / C D þ F

� � ú c x

���� � � � �� I �� � Ú Ø á à ß Ø �

9 p 90

������

a ú c 7 e g g g e c i k c m t _ ^

% ú g g g k c �m t _ ^

� � Y � n ^ c �m wx c p

� ��

� � Ø Ú Ø Ú Ø á à ß Ø �

9 p 90 x � � � � a Y � � � � % � � � � D

õ ò 6 6 ø é D 6 è è æ C < Ú Ø á à ß Ø �9 p 9

0 ê ò , D , ê ç 6 D æ è 6 è é , ç ò è ï ò 6 D 6 % æ è D 6 , ê ò , ö - 6 / D C 4 a í æ , ç ò 6 Y î ç ò é , D , 4 6 ç 6 Dé C è æ ç æ C < C / a ñ å 6 D 6 è ç D æ ê ç ç ò 6 ç ó é 6 è C / a , < > % æ < , ï , ó ç ò , ç % ê , < < C ç > æ D 6 ê ç - ó ö 6 , é é - æ 6 > C < ç ò 6Y î ç ò é , D , 4 6 ç 6 D é C è æ ç æ C < C / a ö 6 ê , ì è 6 ç ò æ è ê , è 6 æ è ò , < > - 6 > ö ó � � � � , < ó ï , ó ñ � C ç 6 , - è C ç ò , ç , 4 C D 6ê C , D è 6 î F D , æ < 6 > / C D 4 ì - , ç æ C < C / � � æ è ê C < ê 6 æ í , ö - 6 ô ï ò 6 D 6 % ç C ö 6 D 6 , ê ò , ö - 6 / D C 4 a æ è < C ç D 6 è ç D æ ê ç 6 >

ç C , ê 6 D ç , æ < é , D , 4 6 ç 6 D é C è æ ç æ C < Y C / a ñ

120

Page 131: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

0

8 7 4

2

1

3

5 11

6 9

10

apply

lambda

2

1

apply

lambda

1

2

3

zero

succ

1

tvar

arrow

{1, 2}

lambda

lvar

apply

{1, 2}3

M N O ¸ � ¸ � � o � � i t » » o º m w { � � � � 8 0 � ¶ � � � � J � ¶ � ° � ¶ �Q R S

� . 6 < S 6 V � &

N D � �� ú c Û ã Ý � Ú à � Ø Ú Ü à � Ø Ú Ý ä Ø Ü Ú Û ß Ø Ú Û à Ù � à Ú Ý � � þ A c D

[ D � � � ��

� ��

� à Ú Ý � � þ A c D� D � � Ø Ú Ø Ø � Û ã ß þ A c ã Þ Ü � ß � Ý ß � � � �

� ú c w� � �� ú c D

� Ú à à � D ü 4 æ ç ç 6 > ñ õ ò 6 è ê ò 6 4 6 C / ç ò 6 é D C C / / C D õ ò 6 C D 6 4 � ê , < ö 6 D 6 ì è 6 > ñ

� � æ è é C ç 6 < ç æ , - - ó 6 D , è æ < F æ < ç ò 6 è 6 < è 6 ç ò , ç , ê C < è æ > 6 D , ö - 6 , 4 C ì < ç C / ê - , è è 6 è æ è - æ ÷ 6 - ó ç C ö 6 æ < / 6 , è æ ö - 6 ôæ ñ 6 ñ ô ê 6 D ç , æ < ê C 4 ö æ < , ç æ C < è C / / ì < ê ç æ C < è ó 4 ö C - è ê , < < C ç C ê ê ì D æ < ç ò 6 F æ í 6 < C D > 6 D æ < , é , ç ò ñ õ ò æ èæ < è æ F ò ç ç D æ F F 6 D è ç ò 6 � ì 6 è ç æ C < æ / � � ê C ì - > 4 , ó ö 6 ö 6 / C D 4 ì - , ç 6 > æ < , 4 C D 6 í 6 D ö C è 6 è ç ó - 6 è C ç ò , ç C < - ó

/ 6 , è æ ö - 6 ê - , è è 6 è , D 6 æ < ê - ì > 6 > ñ � < é D æ < ê æ é - 6 ô ç ò æ è æ è é C è è æ ö - 6 è æ < ê 6 ï 6 ê , < ê C < è ç D , æ < ç ò 6 ê C 4 ö æ < , ç æ C < èö ó D 6 , ê ò , ö æ - æ ç ó , D F ì 4 6 < ç è ñ õ ò 6 D 6 æ è D C C 4 / C D / ì ç ì D 6 ï C D ÷ ç C è ì F F 6 è ç , < ì - ç æ 4 , ç 6 è ç ó - 6 C / ç ò 6> 6 ë < æ ç æ C < C / ê C í 6 D , F 6 ê D æ ç 6 D æ , è C ç ò , ç / 6 , è æ ö æ - æ ç ó C D C ç ò 6 D é D C é 6 D ç æ 6 è , D 6 4 C D 6 - æ ÷ 6 - ó ç C ò C - > ñ

� & � � 9 � < P Y ; 9 � _ < R 6 S + � 6

õ ò 6 ê C í 6 D , F 6 ê D æ ç 6 D æ , è C / , D > æ > < C ç , > > D 6 è è D 6 ê ì D è æ C < æ < ç ò 6 ì < > 6 D - ó æ < F ç 6 D 4 , - F 6 ö D , ñ ù è é 6 ê æ ë êç D 6 , ç 4 6 < ç C / D 6 ê ì D è æ C < æ è è 6 < è æ ö - 6 æ < ç ò 6 è , 4 6 ï , ó , è è é 6 ê æ , - D ì - 6 è > C 6 ø æ è ç / C D ç 6 è ç æ < F - C C é è , < >

D 6 ê ì D è æ í 6 / ì < ê ç æ C < è æ < æ 4 é 6 D , ç æ í 6 é D C F D , 4 è ñ å 6 é D 6 è 6 < ç , ê C í 6 D , F 6 ê D æ ç 6 D æ C < 6 < / C D ê æ < F , ê 6 D ç , æ << ì 4 ö 6 D C / D 6 ê ì D è æ í 6 ì < / C - > æ < F è / C D , ë ø 6 > è C D ç ñ õ C ç ò æ è 6 < > ô ï 6 , - è C < 6 6 > ç C æ < ç D C > ì ê 6 , < æ < > ì ê ç æ í 6è ê ò 6 4 6 / C D ç ò 6 > 6 ë < æ ç æ C < C / è 6 ç è C / D 6 F ì - , D 6 ø é D 6 è è æ C < è ñ 1 6 ç ì è è ç , D ç ï æ ç ò � �

� 9 � 9 m ê ò , D , ê ç 6 D æ è æ < F, - - é , ç ò è < C ç , ç , - - D 6 è ç D æ ê ç 6 > D 6 F , D > æ < F é C è è æ ö - ó D 6 ê ì D è æ í 6 C ê ê ì D D 6 < ê 6 è C / è C D ç ú

� �� 9 � 9 m ú c x � � � � � �

å 6 > 6 ë < 6 > � �� 9 � 9 m , è , è 6 ç C / 6 ø é D 6 è è æ C < è D , ç ò 6 D ç ò , < , è æ < F - 6 6 ø é D 6 è è æ C < / C D ê C < / C D 4 æ ç ó ö 6 ê , ì è 6

ç ò 6 è ì ö è 6 � ì 6 < ç � �� 9 � 9 p , D 6 é D C é 6 D è 6 ç è C / 6 ø é D 6 è è æ C < è ñ � �

� 9 � 9 7 6 ø ò , ì è ç è , - - è ó 4 ö C - è C / è C D ç , ç- 6 , è ç C < ê 6 ú

� �� 9 � 9 7 ú c x � � � � � a � � � � � a ú g g g k t _ �

121

Page 132: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

õ ò 6 ê C D D 6 è é C < > æ < F è 6 ç C / ê - , è è 6 è æ è é C ç 6 < ç æ , - - ó æ < ê C 4 é - 6 ç 6 è æ < ê 6 ç ò 6 D 6 4 æ F ò ç ö 6 é , ç ò è ï ò 6 D 6 < C/ ì < ê ç æ C < è ó 4 ö C - C / è C D ç æ è æ < í C - í 6 > ñ � æ < ê 6 ï 6 , D 6 è C - 6 - ó æ < ç 6 D 6 è ç 6 > æ < D 6 ê ì D è æ í 6 ì < / C - > æ < F è C /

è ó 4 ö C - è C / è C D ç ô ï 6 ê , < , ê ê 6 é ç ç ò æ è æ < ê C 4 é - 6 ç 6 < 6 è è ñ � C < î 4 æ < æ 4 , - æ ç ó ê , < ò , é é 6 < æ < ç ò 6 è , 4 6

ò , D 4 - 6 è è ï , ó , è / C D L ��

ñ õ ò 6 < 6 ø ç - 6 í 6 - C / D 6 ê ì D è æ í 6 ì < / C - > æ < F æ è 4 C > 6 - - 6 > ö ó ç ò 6 / C - - C ï æ < F è 6 ç ú

� �� 9 � 9 ; ú c x � � � � � a � � � � % � � � � � a ^ % ú g g g k t _ �

� C ç 6 ç ò , ç ï 6 ê , < < C ç ì è 6 è ç , D î < C ç , ç æ C < � � è ì ö è ê D æ é ç 6 > ï æ ç ò , < Y / C D ç ò 6 < ì 4 ö 6 D C / D 6 ê ì D è æ í 6

ì < / C - > æ < F è ç C > 6 ë < 6 � �� 9 � 9 p ñ õ ò 6 é D C ö - 6 4 æ è ç ò , ç ï 6 D 6 - ó C < , < 6 ï í , D æ , ö - 6 / C D î è C D ç 6 > / ì < ê ç æ C <

è ó 4 ö C - è / C D 6 , ê ò < 6 ï - 6 í 6 - C / D 6 ê ì D è æ í 6 ì < / C - > æ < F ñ � < è ç 6 , > ô , < æ < > ì ê ç æ í 6 è ê ò 6 4 6 æ è ê C < í 6 < æ 6 < ç / C Dç ò 6 > 6 ë < æ ç æ C < C / � �

� 9 � 9 p ñ

5 6 7 9 ; - ; < 9 ( � & � � � �� 9 � 9 p � â Ø Ù à ß Ø ã ß � Ø ì < / C - > æ < F ê C í 6 D , F 6 ê D æ ç 6 D æ C < / C D þ ï æ ç ò Y ì < / C - > æ < F è C /

è C D ç � � Ø Ú Ø

� �� 9 � 9 p ú c x

V � � � � � � ^ � à Ú Y x �

� � � � � a � � a ú g g g k t _ ^ � t � �� 9 � 9 p

7 � ^ � à Ú Y K �

{ < / C - > æ < F ê C í 6 D , F 6 æ è < C ç , D 6 ë < 6 4 6 < ç C / , < ó C ç ò 6 D ê C í 6 D , F 6 ê D æ ç 6 D æ C < > æ è ê ì è è 6 > è C / , D ñ � ç æ è ô / C D6 ø , 4 é - 6 ô > æ � 6 D 6 < ç / D C 4 L � ô � � ô , < > � � ö 6 ê , ì è 6 ï 6 > C < C ç , ç ç 6 4 é ç ç C 6 ø 6 D ê æ è 6 , - - è ó 4 ö C - è ö ì ç

C < - ó è ó 4 ö C - è C / ç ò 6 > æ è ç æ < F ì æ è ò 6 > è C D ç ñ � ç ï C ì - > ö 6 é C è è æ ö - 6 ç C > 6 D æ í 6 � � / D C 4 , < C ç ò 6 D ê D æ ç 6 D æ C < ñ

å 6 / , í C ì D ç ò 6 è ç , ç ì è C / � � ç C ö 6 è C - 6 - ó ê C < ê 6 D < 6 > ï æ ç ò ç ò 6 ê C í 6 D , F 6 C / D 6 ê ì D è æ í 6 ì < / C - > æ < F è ñ õ ò 6

C é 6 D , ç C D �g

æ è ì è 6 > ç C D 6 ê C í 6 D ê C 4 é - 6 ç 6 < 6 è è ñ � C ç 6 ç ò , ç æ < , - - C ç ò 6 D > 6 ë < æ ç æ C < è C / ê C í 6 D , F 6 ê D æ ç 6 D æ , ô

ï 6 C < - ó ò , > ç C D 6 ê C í 6 D 4 æ < æ 4 , - æ ç ó ö 6 ê , ì è 6 ç ò 6 ê C 4 é - 6 ç 6 � � ï , è ì è 6 > , è , è ç , D ç æ < F é C æ < ç ñ

� � Ò Ï Õ U Ô Ó Ö Ï � Ñ T V W Ñ � Y

� á � � Ø á Ø Ù ß Ý ß Û à Ù õ ò 6 D 6 , D 6 ç ï C æ 4 é C D ç , < ç ì è 6 è C / ç 6 è ç ê , è 6 ê ò , D , ê ç 6 D æ è , ç æ C < , < > ç 6 è ç è 6 ç ê C í 6 D , F 6

ê D æ ç 6 D æ , ô < , 4 6 - ó ê C í 6 D , F 6 , < , - ó è æ è , < > ç 6 è ç è 6 ç F 6 < 6 D , ç æ C < ñ � C ç ò ì è 6 è , D 6 6 , è ó ç C , ê ê C 4 é - æ è ò ì è æ < Fö , è æ ê D 6 F ì - , D - , < F ì , F 6 ç ò 6 C D ó � ê / ñ � H { � � ô ù � { � * � , < > ê C D D 6 è é C < > æ < F ç C C - è ì é é C D ç ñ

ù è / C D ê C í 6 D , F 6 , < , - ó è æ è ô ï 6 , D 6 æ < ç 6 D 6 è ç 6 > æ < ç ò 6 ê C í 6 D , F 6 C / , ç 6 è ç è 6 ç � ï ñ D ñ ç ñ , ê D æ ç 6 D æ C <

4 C > 6 - - 6 > ö ó è C 4 6 è 6 ç � ñ æ D è ç ô ï 6 , ê ê ì 4 ì - , ç 6 , - - é , ç ò è æ < > ì ê 6 > ö ó ç ò 6 ç 6 è ç > , ç , ñ � 6 ê , ì è 6 ç ò 6

ê - , è è 6 è � C / é , ç ò è æ < > ì ê 6 > ö ó , ê C í 6 D , F 6 ê D æ ç 6 D æ C < , D 6 ì è ì , - - ó æ < ë < æ ç 6 ô ç ò 6 í , D æ C ì è ê - , è è 6 è æ < � , D 6

D , ç ò 6 D D 6 é D 6 è 6 < ç 6 > ö ó D 6 F ì - , D 6 ø é D 6 è è æ C < è C D F D , 4 4 , D è ñ õ ò 6 < ô , - - ç ò 6 é , ç ò è æ < � , D 6 � ì è ç é , D è 6 >

ö ó ç ò 6 � ù è ê C D D 6 è é C < > æ < F ç C � ñ � / , ê 6 D ç , æ < � ù , ê ê 6 é ç è è C 4 6 é , ç ò ô ç ò 6 ê C D D 6 è é C < > æ < F ê - , è è æ è

ê C í 6 D 6 > ñ ù - ç 6 D < , ç æ í 6 - ó ô � ê , < , - è C ö 6 D 6 F , D > 6 > , è , D 6 F ì - , D - , < F ì , F 6 ñ ù ê - , è è æ < � æ è ê C í 6 D 6 > æ / ç ò 6

æ < ç 6 D è 6 ê ç æ C < ï æ ç ò ç ò 6 D 6 F ì - , D - , < F ì , F 6 ê C D D 6 è é C < > æ < F ç C � æ è < C < î 6 4 é ç ó ñ

ù è / C D ç 6 è ç è 6 ç F 6 < 6 D , ç æ C < ô ï 6 , D 6 æ < ç 6 D 6 è ç 6 > æ < ç ò 6 F 6 < 6 D , ç æ C < C / ç 6 è ç è 6 ç è , ê ò æ 6 í æ < F ê C í 6 D , F 6

ï ñ D ñ ç ñ , ê C í 6 D , F 6 ê D æ ç 6 D æ C < 4 C > 6 - - 6 > ö ó è C 4 6 è 6 ç � C / ê - , è è 6 è C / é , ç ò è ñ ù - - é C è è æ ö - 6 ç 6 è ç > , ç , ê , <

ö , è æ ê , - - ó ö 6 6 < ì 4 6 D , ç 6 > ö 6 ê , ì è 6 ç ò 6 ç 6 D 4 è C / , ç 6 D 4 , - F 6 ö D , ê , < ö 6 6 < ì 4 6 D , ç 6 > ñ C D 6 í 6 D ó ç 6 D 4

� ô ï 6 ê ò 6 ê ÷ æ / æ ç 6 ø 6 D ê æ è 6 è C < 6 C / ç ò 6 ê - , è è 6 è æ < � ñ � / ç ò æ è æ è ç ò 6 ê , è 6 ô ï 6 , > > � ç C ç ò 6 ç 6 è ç è 6 ç ô , < >

� æ è D 6 4 C í 6 > / D C 4 � / C D ç ò 6 D 6 è ç C / ç ò 6 F 6 < 6 D , ç æ C < é D C ê 6 è è ñ õ ò æ è é D C ê 6 è è ï æ - - ç 6 D 4 æ < , ç 6 è æ < ê 6 , - -

ç ò 6 ê - , è è 6 è æ < � , D 6 / 6 , è æ ö - 6 ñ õ ò 6 6 ê æ 6 < ê ó C / ç ò 6 ö , è æ ê F 6 < 6 D , ç æ C < , - F C D æ ç ò 4 ê , < ö 6 í 6 D ó 4 ì ê ò

æ 4 é D C í 6 > æ / ç ò 6 F 6 < 6 D , ç æ C < C / ç 6 D 4 è æ è > D æ í 6 < ö ó � D , ç ò 6 D ç ò , < è C - 6 - ó ö ó ç ò 6 ì < > 6 D - ó æ < F è æ F < , ç ì D 6 ñ

ù è ï 6 ï æ - - è 6 6 ö 6 - C ï ô ç ò 6 ö C ç ç - 6 < 6 ê ÷ � æ / , < ó C / ç ò 6 , é é D C , ê ò æ è < C ç ç ò 6 F 6 < 6 D , ç æ C < ö ì ç ç ò 6 ê - , è è

4 æ < æ 4 , - æ è , ç æ C < ñ

� Ú à à � à � Ü à Ù Ü Ø � ß � C 4 6 / 6 , è æ ö æ - æ ç ó 6 ø é 6 D æ 4 6 < ç è ò , í 6 ö 6 6 < é 6 D / C D 4 6 > ñ å 6 ê C < è æ > 6 D 6 > ô / C D 6 ø , 4 é - 6 ô

ê C < ç 6 ø ç î > 6 é 6 < > 6 < ç ö D , < ê ò ê C í 6 D , F 6 / C D / ì - - # , è ê , - ñ õ ò 6 6 ø é 6 D æ 4 6 < ç æ è è ì 4 4 , D æ � 6 > æ < æ F ì D 6 ñ

å 6 > 6 D æ í 6 > , - - � ù è / C D ç ò 6 � � � � ê - , è è 6 è / C D ç ò 6 è ç , D ç è ó 4 ö C - C / ç ò 6 # , è ê , - F D , 4 4 , D ñ å 6 , - è C4 æ < æ 4 , - æ è 6 > ç ò 6 ê - , è è 6 è í æ , �

g� ñ æ < , - - ó ô ï 6 , - è C F 6 < 6 D , ç 6 > , ç 6 è ç è 6 ç , ê ò æ 6 í æ < F ê C í 6 D , F 6 ñ õ 6 è ç è 6 ç

F 6 < 6 D , ç æ C < ê C < è æ è ç è C / ç ï C é ò , è 6 è ñ æ D è ç ô é , ç ò è , D 6 > 6 D æ í 6 > / D C 4 ç ò 6 , ì ç C 4 , ç , / C D ç ò 6 í , D æ C ì è

ê - , è è 6 è ñ õ ò 6 < ô ç ò 6 é , ç ò è , D 6 ê C 4 é - 6 ç 6 > ç C ê C 4 é - 6 ç 6 ç 6 D 4 è ö , è 6 > C < è ò C D ç 6 è ç ê C 4 é - 6 ç æ C < è � # ì D � ' ö � ñ

ù - - ç ò 6 ê C 4 é ì ç , ç æ C < è ï 6 D 6 é 6 D / C D 4 6 > æ < � å � î # D C - C F � å æ 6 � � � D 6 - ó æ < F C < ç ò 6 � ù ì ç æ - æ ç æ 6 è � � C C � � � ñ

õ ò 6 è ó è ç 6 4 ï 6 ì è 6 > ï , è , � ì < { - ç D , � ñ � ç ç ì D < è C ì ç ç ò , ç ç ò 6 é 6 D / C D 4 , < ê 6 / C D ê C 4 é ì ç æ < F ç ò 6

122

Page 133: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

K t m o � W q � � w � � q oh q t k k t q » W { l m q � » m W q l f [ �� m t m o l � � i À W q � � f [ fh o { o q t m w W { m w k o � � i À W q � � � l o »

� � � �

a � k � o q W À » � t l l o l � Z �� m t m o l À W q � � i W À � t q � o l m » � t l l f � �h o { o q t m w W { W À t � � t � m W k t m t � k w { w { w k t � w l t m w W { m w k o � �P t m � � o { o q t m w W { � k w {P t m � » W k º � o m w W { _ k w {

M N O ¸ ¸ K t l o l m � s � À W q P t l » t �

� ù è / D C 4 , � � � � æ è , ê ê 6 é ç , ö - 6 ñ � C í 6 D , F 6 , < , - ó è æ è , < > ç 6 è ç è 6 ç F 6 < 6 D , ç æ C < > C 6 è , - è C < C ç é C è 6é 6 D / C D 4 , < ê 6 é D C ö - 6 4 è ñ � æ < æ 4 , - æ è , ç æ C < æ è é D C ö - 6 4 , ç æ ê ï ò æ ê ò æ è < C ç ç C C 4 ì ê ò C / , è ì D é D æ è 6 > ì 6 ç C

ç ò 6 � ì , > D , ç æ ê / C D 4 ì - , ç æ C < C / �g

� ñ å 6 , - D 6 , > ó ò , > ç C ì è 6 , è æ 4 é - 6 ò 6 ì D æ è ç æ ê / C D gD

g C < � ù è ç C è é 6 6 >ì é ç ò 6 ê C 4 é ì ç , ç æ C < C / �

g� ñ � < ç ò æ è ò 6 ì D æ è ç æ ê ô ï 6 ë D è ç ê ò 6 ê ÷ g

Dg

/ C D ç ò 6 , - é ò , ö 6 ç è C / ç ò 6 � ù è ñ õ ò 6ê ò , - - 6 < F æ < F � ì 6 è ç æ C < æ è æ / ç ò 6 , é é D C , ê ò ï æ - - è ê , - 6 ì é / C D 6 í 6 < - , D F 6 D F D , 4 4 , D è ô , < > C ç ò 6 D ê C í 6 D , F 6ê D æ ç 6 D æ , ç ò , < � � � � ñ õ ò 6 é D C ö - 6 4 ï æ ç ò ç ò 6 ê C 4 é - 6 ø æ ç ó C / ç ò 6 4 æ < æ 4 , - æ è , ç æ C < 6 < ê C ì D , F 6 > ì è ç C

ç ò æ < ÷ C / C ç ò 6 D ï , ó è ç C , é é D C í 6 ê C í 6 D , F 6 ê D æ ç 6 D æ , ñ � æ < ê 6 C < 6 æ è C ö - æ F 6 > ç C , é é D C í 6 < C < î 4 æ < æ 4 , - æ ç ó, < ó ï , ó ô , < C ö í æ C ì è � ì 6 è ç æ C < æ è ô æ / ï 6 ê , < > æ è ê æ é - æ < 6 ç ò 6 > 6 ë < æ ç æ C < C / ê C í 6 D , F 6 ê D æ ç 6 D æ , , < ó / ì D ç ò 6 Dè C ç ò , ç 4 æ < æ 4 , - æ ç ó æ è , ê ç ì , - - ó F ì , D , < ç 6 6 > ñ õ ò æ è æ è , ç C é æ ê / C D / ì ç ì D 6 ï C D ÷ ñ

× Ø Ù Ø Ú Û Ü ß Ø ã ß Û Ù ä ß Ø Ü � Ù à � à ä s å 6 6 < í æ è æ C < ç ò , ç ç ò 6 > æ è ê ì è è 6 > / D , 4 6 ï C D ÷ ê C < ç D æ ö ì ç 6 è ç C F 6 < 6 D æ ê ç 6 è ç æ < Fç 6 ê ò < C - C F ó ç C / C D 4 , < æ < ç 6 F D , - é , D ç C / F 6 < 6 D æ ê - , < F ì , F 6 ç 6 ê ò < C - C F ó � � ì è ç æ < ç ò 6 è , 4 6 ï , ó , è < C ï , î> , ó è é , D è 6 D F 6 < 6 D , ç C D è ô ç D 6 6 î ï , - ÷ 6 D è ô ê C > 6 F 6 < 6 D , ç C D è , < > C ç ò 6 D è > C ñ � æ 4 æ - , D æ > 6 , è , D 6 é ì D è ì 6 > æ <

� � + å � * � ö ì ç C < - 6 è è / C D 4 , - F D C ì < > è ñ ù ê ê C D > æ < F ç C ç ò 6 F 6 < 6 D , - ç C < 6 æ < � H � � � ô , ç 6 è ç æ < F / D , 4 6 ï C D ÷/ C D , - , < F ì , F 6 æ è ó 6 ç , < C ç ò 6 D ç C C - ç C ö 6 > 6 D æ í 6 > / D C 4 ç ò 6 / C D 4 , - - , < F ì , F 6 > 6 ë < æ ç æ C < � 4 , ó ö 6 6 < îD æ ê ò 6 > ö ó æ < F D 6 > æ 6 < ç è è é 6 ê æ ë ê ç C ç 6 è ç æ < F ñ 6 < 6 D æ ê - , < F ì , F 6 ç 6 ê ò < C - C F ó 6 < D æ ê ò 6 > ö ó F 6 < 6 D æ ê ç 6 è ç æ < F

ç 6 ê ò < C - C F ó ï C ì - > ö 6 ö 6 < 6 ë ê æ , - æ < ç ò 6 / C - - C ï æ < F ê C < ç 6 ø ç è ú

û � 6 è æ F < C / > C 4 , æ < î è é 6 ê æ ë ê - , < F ì , F 6 è ú õ C F 6 ç , ê � ì , æ < ç 6 > ï æ ç ò , - , < F ì , F 6 ì < > 6 D > 6 í 6 - C é 4 6 < ç ôç 6 è ç ê , è 6 F 6 < 6 D , ç æ C < æ è ò 6 - é / ì - ñ ü < 6 ê C ì - > è æ 4 é - ó > 6 D æ í 6 , ê C 4 é - 6 ç 6 é D C F D , 4 / D C 4 , é , D ç æ ê ì - , Dé , ç ç 6 D < , ç ò , < > ñ � C í 6 D , F 6 , < , - ó è æ è æ è ì è 6 / ì - ç C , é é D C í 6 ç ò 6 ê C 4 é - 6 ç 6 < 6 è è C / , ç 6 è ç è ì æ ç 6 / C D, < � 6 í C - í æ < F - , < F ì , F 6 ñ õ ò 6 - æ < ÷ ö 6 ç ï 6 6 < ç 6 è ç æ < F , < > - , < F ì , F 6 > 6 è æ F < ò , è ë D è ç ö 6 6 < é C æ < ç 6 >

C ì ç æ < � + æ 6 � ' � ñ å 6 4 æ F ò ç , - è C æ < ê - ì > 6 æ < ç 6 D 4 6 > æ , ç 6 , < > 6 ø ê ò , < F 6 / C D 4 , ç è ô , < > , - è C í æ D ç ì , -4 , ê ò æ < 6 è æ < C ì D > æ è ê ì è è æ C < � ê / ñ � � � � � � ñ 1 , < F ì , F 6 > 6 è æ F < æ è , ê ò , - - 6 < F æ < F , é é - æ ê , ç æ C < > C 4 , æ <

/ C D ç 6 è ç æ < F ö 6 ê , ì è 6 C < 6 æ è 4 , ó ö 6 < C ç è , ç æ è ë 6 > ï æ ç ò è ó < ç , ê ç æ ê , - - ó ê C D D 6 ê ç ç 6 è ç é D C F D , 4 è ô ö ì ç ç ò 6F 6 < 6 D , ç 6 > é D C F D , 4 è è ò C ì - > , - è C ö 6 è ç , ç æ ê , - - ó ê C D D 6 ê ç ñ � < � H 1 � � � ô ï 6 è ò C ï æ < , è é 6 ê æ ë ê è 6 ç ç æ < Fò C ï ç ò æ è ê , < ö 6 , ê ê C 4 é - æ è ò 6 > ñ

û ù ì ç C 4 , ç 6 > è C / ç ï , D 6 D 6 < C í , ç æ C < ú õ 6 è ç ê , è 6 ê ò , D , ê ç 6 D æ è , ç æ C < ê , < ö 6 ì è 6 > / C D � ì 6 D ó æ < F è C ì D ê 6ê C > 6 � ê / ñ � # # � ô � " + � � � ç C , é é D C í 6 ç D , < è / C D 4 , ç æ C < D ì - 6 è æ < , ì ç C 4 , ç 6 > è C / ç ï , D 6 D 6 < C í , ç æ C <

� � � � � ô � � � � � � ñ ù - è C ô ê C í 6 D , F 6 , < , - ó è æ è ê , < ö 6 ì è 6 > ç C ö , ê ÷ ì é , è è ì 4 é ç æ C < è æ < ç ò 6 D 6 < C í , ç æ C <ç C C - è ñ ü < 6 é , D ç æ ê ì - , D ç 6 ê ò < æ � ì 6 æ è ç C 4 æ < æ 4 , - æ è 6 , F D , 4 4 , D , ê ê C D > æ < F ç C , ê C > 6 ö , è 6 , ç ò , < > ñ

õ 6 è ç æ < F ê C < ê 6 é ç è , D 6 , - è C ì è 6 / ì - / C D ç ò 6 4 6 D 6 D 6 ê C í 6 D ó C / ç ò 6 F D , 4 4 , D è < 6 6 > 6 > æ < è C / ç ï , D 6D 6 < C í , ç æ C < æ / è ó < ç , ø î ö , è 6 > ç C C - è , D 6 6 4 é - C ó 6 > � / C D ç ò 6 D 6 - 6 í , < ç - , < F ì , F 6 è æ < ç ò 6 ê C > 6 ö , è 6 ñå 6 ê , - - ç ò 6 ê C D D 6 è é C < > æ < F > æ è ê æ é - æ < 6 F D , 4 4 , D D 6 î 6 < F æ < 6 6 D æ < F C D F D , 4 4 , D D 6 ê C í 6 D ó � 1 � � � � ñ

� C í 6 D , F 6 , < , - ó è æ è ô ê C í 6 D , F 6 í æ è ì , - æ è , ç æ C < ô , < > ç 6 è ç è 6 ç F 6 < 6 D , ç æ C < ê C < è æ > 6 D , ö - ó ò 6 - é è ç C í , - æ > , ç 6ç ò 6 ê C D D 6 ê ç < 6 è è , < > ê C 4 é - 6 ç 6 < 6 è è C / , D 6 ê C í 6 D 6 > F D , 4 4 , D � ê / ñ � 1 2, 4 � � � ñ

� T � T Ñ T Ï Õ T Y

� i � w Z _ � R i � w m o � W � � R � o q � w { � � o k w d � m q � » m � q o s � t m t R M { � R a R i À q t m w t { s P R � W � t w m w l O o s w m W q l O � 4 6 4 � 4 H .E � . : 3 O � � � � E � � � � � 6 � � 0 6 . 3 0 4 6 8 : 0 4 � � : 0 = . 3 . 0 " . O { � k � o q f f � $ w { c a K � O º t � o l f % f � O � o � º � w O

h q o o » o O � % f ] # t { � t q � f Z Z _ R � º q w { � o q d v o q � t � R

123

Page 134: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

� i � z � $ i R v R i � W O � R � o m � w O t { s # R � R z � � k t { R � : D S 8 � . 3 H � S 3 8 0 " 8 S � . H � 6 . " � 0 8 � � . H � 6 : : � H R i s s w l W { d L o l � o � O

f Z � $ R

� V o w Z ] V R V o w � o q R M : = 6 � 4 3 . E . H 6 8 0 B E . " � 0 8 � � . H R v t { a W l m q t { s � o w { � W � s O a o Á W q  O � { s o s w m w W { O f Z Z ] R

� V � s � � � R V t � � w » � w t { s M R � º t s t À W q t R i { i � m W k t m w » h o { o q t m W q À W q K W k º w � o q � o l m w { � R � Q Q Q E 3 4 0 H �

4 " 6 8 : 0 H : 0 M : = 6 � 4 3 . Q 0 B 8 0 . . 3 8 0 B O � ¼ [ ¿�

� [ � % � � � O # � � � f Z � � R

� V � v ] ] R h R # R | t { s o { V q t { s O R P R i R � o � � w { Â O t { s K R v o q � W o À R h o { o q t m w W { W À K W k º W { o { m l À W q � W À m Á t q o

� o { W | t m w W { � t » m W q w o l À q W k K W { m o X m d À q o o h q t k k t q l R M " 8 . 0 " . : = � : D S � 6 . 3 ? 3 : B 3 4 D D 8 0 B O � $ ¼ � %

� ¿�

� ] Z % � $ $ O � ] ] ] R

� V � ] ] � R V q w { Â l k t t { s # R � q o m k t { l R � o l m w { � � q t { l w m w W { � � l m o k l�

i { i { { W m t m o s V w � � w W � q t º � � R M {

� R K t l l o � O K R # t q s O V R � W � W � O t { s R � � t { O o s w m W q l O M � D D . 3 M " � : : � � ) � Q ? � � � � � : � . � � 8 0 B4 0 � � . 3 8 � " 4 6 8 : 0 : = ? 4 3 4 � � . � ? 3 : " . H H . H O º t � o l [ [ % � ] O a t { m o l O # � � � � ] ] ] R

� V � q Z [ K R # R V � q � o l l R � � o i � m W k t m o s h o { o q t m w W { W À � o l m K t l o l À W q K W k º w � o q l R M : = 6 � 4 3 . E . H 6 8 0 B �� . 3 8 � " 4 6 8 : 0 4 0 � � . � 8 4 � 8 � 8 6 O O [ ¼ � ¿

�� f % Z Z O x � { f Z Z [ R

� K K Z ] � R # R K � w  W À l  � t { s # R � R K q W l l R � o | o q l o o { � w { o o q w { � t { s s o l w � { q o » W | o q ��

i m t X W { W k � R � Q Q Q

M : = 6 � 4 3 . O _ ¼ f ¿�

f � � f _ O f Z Z ] R

� K � v � ] i R K o � o { m t { W O � R K R � o � � o � � w O P R � R v w � { t O K R h � o � � w O h R h q t { t m t O t { s � R � t | W q o m m w R K W k º w � o q

� o l m w { � � l w { � t � o { m o { » o h o { o q t m W q R M : = 6 � 4 3 . � ? 3 4 " 6 8 " . 4 0 � Q R S . 3 8 . 0 " . O f ]�

� Z _ % Z f � O f Z � ] R

� � o { Z f � R � o { { o � R � o l m d K t l o h o { o q t m w W { À q W k P q W � W � d V t l o s � º o » w Ä » t m w W { l R � Q Q Q M : = 6 � 4 3 . O � ¼ � ¿�

[ Z % � _ O

t q » � f Z Z f R

� � � L Z $ P R � R � o | t { � � O � R � R � W l o { � � � k O t { s i R c R L W � À R h o { o q t m w { � � o l m w { � t { s i { t � � l w l � W W � l Á w m �

i q w t R # � � E 3 4 0 H 4 " 6 8 : 0 H : 0 M : = 6 � 4 3 . Q 0 B 8 0 . . 3 8 0 B 4 0 � � . 6 � : � : � : B O O � ¼ f ¿�

[ � % $ � O # t { � t q � f Z Z $ R

� � L � � P R h R � q t { Â � t { s � R # R L o � � Â o q R i { i º º � w » t � � o � t k w � � W À � t m t � � W Á � o l m w { � K q w m o q w t R � Q Q Q

E 3 4 0 H 4 " 6 8 : 0 H : 0 M : = 6 � 4 3 . Q 0 B 8 0 . . 3 8 0 B O f [ ¼ f ] ¿�

f [ � � % f [ Z � O T » m W � o q f Z � � R

� � � ] ] # R � o o q w { � t { s P R � � w { m R � o k t { m w » l W À º q W � q t k k w { � � t { � � t � o l�

i m W W � d W q w o { m o s t º º q W t » � R # � �

M � , ? % # % % : 6 8 " . H O � � ¼ � ¿�

� Z % [ � O t q » � � ] ] ] R

� � c ] ] # R � t q k t { s � R c &t k k o � R � Á W d s w k o { l w W { t � i º º q W X w k t m w W { K W | o q t � o R � 0 = : 3 D 4 6 8 " 4 O � [ ¼ � ¿ O � ] ] ] R

� � � � Z L w � � w t k � W k o q t { s � w » � t q s � » � W W � o q R M { s o º o { s o { m m o l m w { � W À » W k º w � o q º � t l o l � l w { � t m o l m » t l o

� o { o q t m W q R M : = 6 � 4 3 . � ? 3 4 " 6 8 " . 4 0 � Q R S . 3 8 . 0 " . O f Z ¼ f ¿� � � % $ � O # t { � t q � f Z � Z R

� � z � ] # R � W º » q W À m t { s # R z � � k t { R � 0 6 3 : � � " 6 8 : 0 6 : # � 6 : D 4 6 4 E � . : 3 O � % 4 0 B � 4 B . H � 4 0 � � : D S � 6 4 6 8 : 0 R

i s s w l W { d L o l � o � O a R � o t s w { � O i O f Z � ] R

� # t » Z $ T R # t » Â R M : = 6 � 4 3 . E . H 6 8 0 B = : 3 � : 0 * . 0 6 8 : 0 4 � 4 0 � % : B 8 " ? 3 : B 3 4 D D 8 0 B R a � k � o q f ] w { P q W � q t k d

k w { � K W k º � o X � � l m o k l R L t � m o q s o h q � � m o q O V o q � w { O f Z Z $ R

� c &t k ] f � R c &t k k o � R h q t k k t q � o l m w { � R M { ? 3 : " + : = - � 0 � 4 D . 0 6 4 � # S S 3 : 4 " � . H 6 : M : = 6 � 4 3 . Q 0 B 8 0 . . 3 8 0 B0 - # M Q 1 � 3 3 6 O { � k � o q � ] � Z w { c a K � R � º q w { � o q d v o q � t � O � ] ] f R

� c v ] f � R c &t k k o � t { s K R v o q � W o À R � o k w d t � m W k t m w » h q t k k t q � o » W | o q � R � � � k w m m o s 7 i | t w � t � � o t m

8 © © 9 ; = =       � �   ¡ � £ � = ? ¦ � � � = O # � � � � ] ] f R

� � � Z Z � � i a � M { m o q { t m w W { t � c w k w m o s R � . * : � * . B H . 3 , � 8 � . O t � f Z Z Z R M l l � o _ R

� � o _ Z h R # R � o q l R E � . # 3 6 : = M : = 6 � 4 3 . E . H 6 8 0 B R L w � o � d M { m o q l » w o { » o O a o Á W q  O f Z _ Z R

� a W W Z _ h R | t { a W W q s R � � i z m w � w m w o l�

i � W W � � W X m W t { w º � � t m o � w { w m o d � m t m o i � m W k t m t R M { # � 6 : D 4 6 4� D S � . D . 0 6 4 6 8 : 0 O { � k � o q f � $ ] w { c a K � R � º q w { � o q d v o q � t � O f Z Z _ R

� P P Z [ � R P t � � t { s i R P q t  t l � R � � º º W q m w { � � o q w o l W { � W � q » o K W s o�

i � W q k t � � q t k o Á W q  R � 0 6 . 3 0 4 �

6 8 : 0 4 � G : � 3 0 4 � : = M : = 6 � 4 3 . Q 0 B 8 0 . . 3 8 0 B 4 0 � H 0 : � � . � B . Q 0 B 8 0 . . 3 8 0 B O [ ¼ � ¿�

� � � % � [ � O f Z Z [ R

� P � q _ � t P R P � q s W k R � q q t m � k� + i � o { m o { » o h o { o q t m W q À W q � o l m w { � P t q l o q l Q � V M � P ¼ � ¿ O f Z _ � O º R � _ � R

� � E O f � ¼ [ ¿� � Z � % � Z � O f Z _ � R � o o � P � q _ � � R

� P � q _ � � P R P � q s W k R i l o { m o { » o � o { o q t m W q À W q m o l m w { � º t q l o q l R � � E O f � ¼ � ¿�

� $ $ % � _ � O f Z _ � R � o o � P � q _ � t R

� � w o Z � h R � w o s o Á t � s R � � o c � c � c t { � � t � o � o | o � W º k o { m c t � W q t m W q � R M { z R � t l m o { l t { s P R P À t � � o q O

o s w m W q l O � : D S 8 � . 3 � : 0 H 6 3 � " 6 8 : 0 � L 6 � � 0 6 . 3 0 4 6 8 : 0 4 � � : 0 = . 3 . 0 " . � � � � � � � ? 4 � . 3 � : 3 0 � , . 3 D 4 0 O O

{ � k � o q $ [ f w { c a K � O º t � o l � � % Z [ R � º q w { � o q d v o q � t � O T » m W � o q f Z Z � R

� � L � � � R � t º º l t { s � R # R L o � � Â o q R � o � o » m w { � � W À m Á t q o � o l m � t m t z l w { � � t m t � � W Á M { À W q k t m w W { R � Q Q Q

E 3 4 0 H 4 " 6 8 : 0 H : 0 M : = 6 � 4 3 . Q 0 B 8 0 . . 3 8 0 B O f f ¼ [ ¿�

� $ _ % � _ � O i º q w � f Z � � R

� � V Z Z � R h R � w q o q t { s V R a R V o q l � t s R z l w { � P q W s � » m w W { h q t k k t q l w { � W À m Á t q o � o l m w { � R M { ? 3 : " . . � 8 0 B H: = 6 � . � 0 � � : 0 = . 3 . 0 " . : 0 � : D 4 8 0 � M S . " 8 � " % 4 0 B � 4 B . H O º t � o l f % f [ O V o q  o � o � O K i O T » m W � o q � % �

f Z Z Z R z � � a M M i l l W » w t m w W { R

� v � Z � � R v o k � q w t { s � R � t � � t { t q t k t { R h o { o q t m w W { W À s o l w � { | o q w Ä » t m w W { m o l m l À q W k � o � t | w W q t � v � � c

º q W � q t k l � l w { � º t m � o { � k o q t m w W { t { s » W { l m q t w { m º q W � q t k k w { � R E 3 4 0 H + � % M � M O H 6 . D H O ��

� ] f %

� f [ O f Z Z � R

� L o � � Z � R # R L o � � Â o q R M { � o À o { l o W À K W | o q t � o K q w m o q w t R M { ? 3 : " . . � 8 0 B H : = 6 � . 6 6 6 � � 0 6 . 3 0 4 6 8 : 0 4 � � : 0 �

= . 3 . 0 " . : 0 M : = 6 � 4 3 . Q 0 B 8 0 . . 3 8 0 B O º t � o � $ f O t � f Z � Z R

� L w o ] ] # R L w o � o k t  o q R � L M d P q W � W � � R [ O � o À o q o { » o t { � t � R z { w | o q l w m � W À i k l m o q s t k O � o º m R W À � W » w t �

� » w o { » o M { À W q k t m w » l ¼ � L M ¿ O � ] ] ] R

124

Page 135: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Using SDL Tools to Test Properties of Distributed SystemsHesham Hallal1, Alex Petrenko1, Andreas Ulrich2, Sergiy Boroday1

1 Centre de Recherche Informatique deMontreal (CRIM),550 Sherbrooke West, Suite 100Montreal, H3A 1B9, Canada{hallal, petrenko, boroday}@crim.ca

2 Siemens AG, CT SE 1,Otto-Hahn-Ring 6,D-81730 Munich, [email protected]

AbstractWe present an ongoing project on reasoning on properties of distributed systems basedon monitoring of their executions. The proposed approach uses SDL to model anexecution trace of the system under test and an existing model checker to perform theanalysis of properties of interest specified in the SDL-like language GOAL. For thispurpose, we use the available ObjectGEODE tool set. We describe how SDL models arebuilt from collected traces, and show how the desired properties are specified. Anexample is used to illustrate the approach. The proposed methodology can be applied totest distributed systems and to diagnose their faults.

1 IntroductionRecent technological advances, especially in communications, triggered a growing needfor distributed systems. However, the cost of developing such applications is gettingever higher. In fact, the main characteristics of distributed systems, which includeasynchrony and absence of a global timing reference, add to the complexity of theirdesign and test. In addition, development of distributed systems rarely yields formalspecifications of their behavior that would make formal methods fully applicable in thetesting phase. A number of tools that ease the development problems in the debuggingand testing phase have been developed, both in the academia and industry. Such toolsusually rely on other tools that provide monitoring of distributed systems and producelog files of execution traces. Debugging tools offer various levels of automation oftesting activities, from visualization of traces to property verification. There exists alarge body of work on developing various tools to visualize traces, see, e.g., [2, 15, 19].Their goal is to facilitate efforts of the designer or tester for locating and correcting bugsby filtering out unrelated data and properly visualizing executions of his concern. Theanalysis is performed manually either online (simultaneously with the system execution)or post mortem. The other group of tools targets the analysis phase by offering means toautomatically verify whether the system under test exhibits certain properties [8, 9, 13].It is the task of the tester to formally specify the “suspected” property of the system.Such property verification is based on execution traces using specially developed modelchecking mechanisms.

Developing a tool for testing properties in execution traces, one usually faces a choiceof either to elaborate algorithms and to implement them in a specialized tool for aspecific class of properties or to reuse an off-the-shelf model checker. In the first

125

Page 136: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

scenario, one faces the daunting task of implementing from scratch all the phases of theapproach, i.e., modeling the system, specifying the properties of interest, and, mostimportantly, building a model checker. Realizing difficulties inherent to this approach,the work in [13] proposes to reuse an existing model checker in the last step of theanalysis. However, we are not aware of any attempt to apply commercial or researchmodel checkers to the whole process of property verification even in the post mortemmode. Reuse of these tools allows the developers of debugging tools to rely on reliableand highly sophisticated products, in which many years of research and experience havebeen invested.

In this paper, we report on an ongoing research project that has the goal to evaluate theapplicability of a commercial model checking environment to automate the process ofpost-mortem property testing in a recorded execution trace of a distributed system undertest. We decide to use the Specification and Description Language (SDL) to model theaspects of the system under test. SDL was chosen because of its ability to modeladequately communicating systems as well as its user friendliness. In addition, theexistence of commercial design and analysis tools that support the language is a majorpoint in favor of SDL. We selected ObjectGEODE (OG) from Verilog (now Telelogic).This tool allows not only modeling systems in SDL but also performing simulation andmodel checking. The OG tool set provides the SDL-like language GOAL (GEODEObject Automata Language) to specify the desired properties, which simplifies the taskof the user by relieving him from the burden of mastering temporal logic [1]. This, infact, adds greatly to the practicality of the tool.

The main issue in our project — automating the process of performing trace-basedanalysis of distributed systems — can be detailed as follows: Given a system under test(SUT), an executed trace that was collected by monitoring the SUT's behavior before,and a set of properties (certain characteristics of interest), we need to verify within theOG environment whether the SUT's behavior represented by the trace exhibits therequired properties. To do so, we build an SDL model of the system based on therecorded trace, specify the properties of interest in GOAL, and use the OG modelchecker to verify whether the specified properties are present or missing in the trace.

The remainder of this paper is organized as follows. The next section summarizesrelated work. In Section 3, we describe our approach to solve the trace-based analysisproblem in distributed systems. We detail the approach and discuss the basic conditionsfor its validity and consistence. In Section 4, we discuss some important properties forthe trace-based verification of distributed systems. Then in Section 5, we illustrate theapproach and the use of the tools through an example. Finally, we conclude the paper inSection 6.

2 Related WorkDifferent approaches exist for modeling properties of distributed systems. In [16], anapproach is devised to allow a debugger to halt the execution of the system at somespecified breakpoints that are defined as predicates of system’s events. However, theexpression power of the linked predicates is limited. In addition, the local state of each

126

Page 137: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

process needs to be known which is not always feasible, especially in the case ofdistributed systems.

Much work on trace based analysis was done in the field of intrusion detection. Thework in [14] shows such an approach that targets intrusion detection in network systemsand models intrusion patterns using Colored Petri-Nets. The approach can begeneralized to cover a wider range of properties, but it still lacks an implementation thatshows its efficiency. In [8], flow graphs are used to represent potential communicationsbetween the processes of a distributed system. Properties, meanwhile, are representedusing quantified regular expressions (QRE). This approach requires deep knowledge oftiny details in the processes of the tested system. This approach is not feasible all thetime and defies the advantage of using execution traces to test the system’s behavior.The approach in [18] describes the tool GrIDS to detect large scale intrusion attacks onnetwork systems. The concept is to build activity graphs of the executions of the variousprocesses in the system by monitoring them individually and to analyze them based onsome reference rules to decide on an intrusion. The approach requires heavy means toprotect the GrIDS modules themselves against attacks.

The papers [2] and [19] present an approach to visualize the collected traces. [9] and[13] describe an approach, centered on the concept of the lattice, to perform tracechecking in distributed systems. Following this approach, a lattice is built, based on themonitored events and the relations between them, to represent the system under test.The lattice is then used in a model-checker to verify the behavior of the system against adesired property. In a recent work [15], a method of specifying abstraction hierarchiesto define level-wise views of a distributed message-based system is outlined. Thismethod utilizes event-pattern mappings and complex events to represent a system'sbehavior.

Similar to the approach in [13], we base our model on the concept of the lattice.However, we suggest going further. We describe in SDL each component of the SUTinvolved in the given trace as a state machine, and we let the SDL simulator in OG buildthe composite (global) machine of the system (an SDL state graph) that represents thesame interleavings as the lattice. This is done at runtime when the model checkerverifies the given property (pattern). We believe that our approach steps further in thedirection of full automation of the process especially by means of a front-end tool thatbuilds the SDL models from the collected trace and helps the user specify the propertiesof interest in the GOAL language.

3 The Proposed Approach

3.1 OverviewWe base our work on two fundamental concepts that reflect concurrency incommunicating systems: a partially ordered set (poset) of events, where the partial orderis the traditional "happens before" relation [3], and the corresponding lattice. In fact,these two concepts are at the heart of the main existing approaches to analyze traces ofdistributed systems. For example, the approach of [13] considers building the lattice of

127

Page 138: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

the poset of the collected events and performing the verification of a pattern on thelattice using existing model checking techniques. Similar to this approach, we considerusing an existing tool, rather than relying on home developed algorithms and methodsfor model checking. In our post mortem analysis approach, we first build an SDL modelof a system from a collected trace (the trace is completed, i.e., we do a post mortemanalysis of a performed system run). Then we use the model checker, i.e., theObjectGEODE simulator, to perform the checking of a given property.

In detail, an SDL model of the tested system that relies on a given trace reflects thefollowing aspects: structure, behavior, communication, and data. The structure of thesystem can be modeled using the hierarchy of system/block/process/procedurestatements in SDL. In our case, it is sufficient to define a system with a single block thatis composed of several processes. The overall behavior of the system is modeled by thejoint behavior of a set of communicating processes in SDL. These processes correspondto entities of the real system whose behaviors are recorded in the trace; thus makingeach of the processes linear, as in most cases we cannot identify any two states of it, sono cycles can be deduced. The representation of a process can be obtained by projectingthe collected trace into the set of events it executes: send, receive, and local events andsubsequently inserting states in between communication events, while representing localevents as SDL tasks. The asynchronous communication between processes is achievedvia signals with optional signal parameters (that represent exchanged data) andchannels. Input signals to a process are stored in a queue before reading them. Thus,unknown delays in real communication channels of the distributed system arerepresented by those of input queues, associated to each SDL process. This means thatin our framework, the whole communication media of the system is simply modeledwith individual queues of SDL processes.

The property to be checked (the pattern) is expressed as an observer [10] in the GOALlanguage. A GOAL observer implements in fact a finite automaton with accepting states[1]. GOAL is similar to SDL, but has some syntactic and semantic differences [1].Observers are usually described in terms of entities (objects, signals etc.) of the testedsystem, e.g., they can be associated to the SDL system. This makes communicationsignals directly accessible for observation while other model data, e.g., variables andstates, are accessible to observers using probes. The latter represent pointers to SDLentities. In addition, GOAL allows the declaration of two types of designated states:success states and error states. Entering success states (error states) indicates that thesystem respects (violates) the property expressed in the observer. The use of thesuccess/error convention is completely up to the user and has no formal meaning.

Once the representation of the distributed system and the property is complete, theObjectGeode model checker can be employed to verify whether the system satisfies theproperty. This is achieved in the so-called exhaustive simulation mode, when the toolperforms all the possible executions of the system and builds a state graph of the SDLsystem.

The state graph represents all the possible interleavings of events in the collected trace.To perform model checking, the tool builds the synchronous product of the observer andthe specification of the system. The OG simulator outputs a report of the number of

128

Page 139: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

errors and successes encountered, and presents the scenarios that lead to the observererrors and successes.

The approach based on the use of the OG environment can be summarized in the formof a workflow shown in Figure 1. As it is clear from this figure, the implementationefforts are reduced to building just a front-end to OG containing the three main blocks:1. System specification tool that builds an SDL specification from the collected trace.2. Pattern specification tool that eases the process of writing the patterns for

verification.3. A user interface module that allows the operator to control the whole process.

Figure 1: The diagram of the workflow.

In order to model the behavior of the SUT in SDL, as it is recorded in the executiontrace, we have to:

a) Match each receive event with its corresponding send event.b) Preserve in the SDL system’s behavior the local order of events in each process.

GOAL Observer

Trace

Distributed system of processes

Monitoring Tool

ObjectGEODETool

SDL Model

SystemSpecification

PatternSpecification

UserInterface

Operator

Model checking results:1. Pattern present or not2. Scenarios

EventEvent

Front-End to OG

...

129

Page 140: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

3.2 Matching Receive with Send EventsThe problem of matching receive and send events is crucial to determine the partialorder of events and eventually build an adequate (SDL) model from the recorded trace.Much depends on how the distributed system is instrumented and what exactly ismonitored. In this paper, we assume that each event in the trace collected by themonitoring system carry the following information:1. Name and type of the event: Send, Receive, or Local.2. ID of the issuing process.3. The local ordinal number of the event in the process.4. The source process (for Receive).5. The destination process(es) (for Send).6. The message parameters of the event: a list of typed parameters that includes a

message name and other message attributes (for Send and Receive events).7. The local parameters of the issuing process: a list of typed parameters that reflect its

current state.

We assume that in a pair of source and destination processes, each Receive eventmatches with a single Send event in the sense that the values of all the messageparameters coincide. Moreover, we take for granted that in the given trace, each Sendevent matches with at least one Receive event. The local ordinal number of eventsallows us to compute a total order of events in each process. Such total order has to bepreserved in the partial order of the events in the whole system.

3.3 Preservation of the Event OrdersTo illustrate a potential problem that is related to the violation of a local order by anSDL model directly deduced from a given trace, we consider the trace represented bythe MSC in Figure 2. Process P1 issues a "Send" event S1, which reflects sending themessage m1 to P2. Upon receiving the message, process P2 issues the "Receive" eventR1. Similar events are generated when P3 sends the message m2 to P2. Notice thatevents S1 and S2 are independent while R1 and R2 depend on S1 and S2, respectively.The trace indicates that R1 occurs before R2 regardless of the order between S1 and S2.In other words, it can be easily deduced from the trace that S1 ≤ R1, S2 ≤ R2, R1 ≤ R2,where ≤ is the "happened before" relation.

Figure 2: MSC of the sample trace.

P1 P2 P3

S1 S2R1

R2

m1 m2

130

Page 141: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

A simple SDL process corresponding to P1 should just output a single output signal m1.The same applies to P3. P2 in turn should just receive two signals, namely, m1 followedby m2. When the OG simulator executes such SDL system, it treats S1 and S2 asconcurrent events, i.e., firing them in all possible orders ([S1, S2] and [S2, S1]). Thismeans the OG simulator reaches a global state where the queue of P2 contains thesignals m2 and m1 received in the reversed order, i.e., m2 precedes m1, contrary to whatthe trace prescribes. In this state, the SDL specification of P2 foresees the reception ofm1 only; this process considers m2 as an implicit input and discards it. The resultingglobal state graph would then contain an execution that violates the local orderperceived by P2.

It turns out that SDL offers a simple, elegant solution to this problem. To prevent asignal loss, SDL contains the SAVE construct that prohibits the process in its currentstate from consuming the declared signals from the queue. The saved signal is kept forfuture consumption. In our example, the use of SAVE in the state with the input ofsignal m1 would prevent the SDL process from consuming m2 first and thus preventsthe OG simulator from building executions that contradict to the given trace.

Therefore, we use the SAVE construct in each state of each SDL process to store all theunexpected signals that the OG simulator may try to put into the queue. Adding Savecompletes the construction of the model of the system that can be obtained from thegiven trace. The resulting SDL model allows us to verify any system property that canbe specified in the Goal language.

4 Properties in Execution TracesHere, we discuss the properties of distributed systems that can be verified with theapproach. To address this issue we turn to the properties that are believed to be mostlyused in practical applications. The existing research in the field has explored a widerange of properties that can be sought in distributed systems. These properties can beclassified into two types: state based and event based.

Event based patterns allow detecting simple atomic or composite events in the behaviorof the SUT. State based patterns, on the other hand, formulate assertions on the statevariables of the processes in the SUT. The work of Dwyer et al. at Kansas StateUniversity to build a repository of specification patterns (similar to design patterns) [7],[11] shows an effort to cover both types of properties. For our project, we plan toeventually build a repository of typical and frequently used specification propertytemplates in GOAL.

To make the specification of patterns portable, a mapping to several formalisms (LTL,CTL, GIL, QRE, and INCA Queries) has already been provided in [11]. There are twoclasses of patterns in the repository:1. Occurrence patterns. They include patterns that express universality, existence,

absence, and bounded existence of an event (or state) or sequence of events (orstates).

131

Page 142: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

2. Order patterns. These express relations between events (or states) or sequences ofevents (or states); and they include precedence, response, chain precedence, andchain response.

Each pattern is defined over a scope that expresses the extent of the execution, overwhich the pattern must hold. Five basic kinds of scopes exist in the repository. A scopeof a pattern can be: global (the complete execution), before (up to a given state/event inthe execution), after (the part of the execution after a given state/event), between (anypart of the execution from one given state/event to another given state/event), or after-until (like between but the designated part of the execution continues even if the secondstate/event does not occur). In the repository, each scope is determined by specifyingstate/event delimiters for the pattern: the scope consists of all states/events beginningwith the starting state/event and up to but not including the ending state/event [11].

We present here two illustrative examples, the universality and existence properties.

Universality: We consider the global universality of a predicate P, where P representsan assertion on events or state formula. This pattern can be stated in CTL as: AG(P).The corresponding observer is shown in Figure 3.

Figure 3: Observer for global universality.

To check that the property P holds in a given system, we should detect whether thenegation of P ever occurs in it. In the case of events, the negation would mean theoccurrence of any event other than in P (P might be a disjunction of events). In the caseof a state formula, the negation of the Boolean predicate P is required. Thecorresponding observer in GOAL uses the WHEN construct to describe the universalityproperty. The property holds if the observer does not terminate in the error state s2.

Existence: Here, we also consider the global existence of P. This pattern is stated inCTL as: AF(P). The corresponding observer is shown in Figure 4.

Clearly, this observer has to verify P on all the paths of the state graph built from thetrace. To do so, we let the observer watch for P while concurrently checking thetermination of the involved processes using assertions on the state of each process.

event observer universality

error state s2;

s1

s1

not P

s2s2

132

Page 143: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

When all the processes reach their final states, and P has not been detected yet, theobserver enters an error state. Note that the negation of the predicate itself should holdtrue when the processes reach the final states to account for the case when P holds in thefinal state of any of the processes.

Figure 4: Observer for global existence of P.

The presented examples confirm that GOAL allows the expression of a wide range ofpatterns.

5 ExampleWe use an example to further illustrate our approach. Figure 5 shows an event sequencediagram deduced from a hypothetical trace. Here we do not discuss its structure to keepthe example simple and transparent. In this trace, the two processes communicatebetween each other and issue local events. All Send, Receive and Local events areconsidered to be observable by the monitor.

Figure 5: The event sequence of the collected trace, where hanging arrows correspond to localevents, and sloped arrows to communications.

observer existence global

error state s3;

s1

P

s2

(probe1! state = probe1!final) and(probe2! state = probe2!final).... and ( not P)

s3

s2

s3

pr1

pr2n2=6

n1=3

n2=4

n1=4 n1=5

n2=2

rm1-pr2

sm1-pr2

sm2-pr1

rm2-pr1

rm3-pr1

sm3-pr2

133

Page 144: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

The two processes pr1 and pr2 have local variables n1 and n2, respectively, that areupdated during the execution of the two processes. The values of these variables aresent in Local events only. From the trace in Figure 5, the representation of bothprocesses can be extracted as a sequence of events belonging to either process.

Process pr1 is represented in the trace by the following event sequence:1. Local event with n1 instantiated to 3, n1=3.2. Receive event, denoted sm1_pr2, this indicates that the message #1 is received; it is

a message from pr2.3. Local event n1=4.4. Send event, denoted sm2_pr1, this indicates that the message #2 is sent by pr1 to

pr2.5. Receive event, denoted rm3_pr2, this indicates that the message #3 is received; it is

a message from pr2.6. Local event n1=5.

Similarly, the second process pr2 is represented in the trace by the following eventsequence:1. Local event n2=6.2. Send event sm1_pr2.3. Local event n2=4.4. Send event sm3_pr2.5. Receive event rm2_pr1.6. Local event n2=2.

The block diagram and the corresponding processes of the SDL model are shown inFigures 6, 7, and 8, respectively. Communication between the two processes is carriedout through a two-way channel. Note that, in Figures 7 and 8, we model the Localevents of each process using the TASK construct of SDL. On the other hand, we use themessage names to represent the communication events in the SDL model.

Figure 6: Block diagram of the system model in SDL.

block Block1

Channel[ m1, m2] [m3]

pr1 pr2

134

Page 145: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Figure 7: The SDL model for the first process.

Figure 8: The SDL model for the second process.

The OG simulator returns the state graph with 27 states and 40 transitions described intextual representation. The lattice itself is shown in Figure 9.

The transitions are labeled with the names of the corresponding events. As for the states,they express local states of the processes and the corresponding values of the variables.Here, we only show the local variables of the processes. We use them to formulate thepatterns we would like to recognize with the model checker and to demonstrate that theyare eventually identified correctly. The sign "?" indicates the fact that the value of thecorresponding variable is unknown in the corresponding state as there was no reportfrom the process on the value of this variable yet. As a result, the detection of a patternformulated in terms of both variables cannot be accurately performed in any of the fiveglobal states, where the value of either variable is still unknown. Note that the OGsimulator assumes zero values for these variables by default.

process pr1

dcl n1 integer ;

n1:= 3

s1

s6

*

*

s3

true

m2

s4

m3

s5

s1

m1

s2

true

n1:= 4

s3

s5

true

n1:=5

s6

process p2

dcl n2 integer;

n2:=6

s1

s6

s3

true

m3

s4

s5

true

n2:=2

s6

s2

true

n2:=4

s3

*

*

s1

true

m1

s2

s4

m2

s5

135

Page 146: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Figure 9: The lattice of the collected trace of events. (sm1_pr2 stands for send m1 by process pr2,and rm1_pr2 stands for receive m1 from process pr2, and local events are indicated by the variables

and their values)

To fix this problem, we introduce two auxiliary Boolean variables in the SDL models ofthe processes that act as flags. After the first assignment on a variable (n1 or n2) isdone, the corresponding flag is set. This amounts to modifying only the transitions thatfirst affect the variables. The modified transitions of pr1 and pr2 are shown in Figure 10a) and b), respectively. The settings of the flags are then used in order to initialize anyobservers that watch the values of the variables.

n 2=4

n 1=3

n 1=3

n1=3

n1=3

n2=4

n2=4

n2=4

n2=4

n 1=4

n 1=4

n1=4

rm1_

pr1

rm2_ pr2

n2=2

n2=2

n2=2

n 1=5

n1=5

n1=5

rm2_

pr2

rm2_ pr

2

rm1_

pr1

rm1_

pr1

sm2_ pr 2

sm2_

pr2

sm2_ pr2

sm2_

pr2

sm2_

pr2

sm1 _p

r 1

sm1_

pr1

sm1_

pr1

rm1_

pr2

rm1_

pr2

rm1_

pr2sm

1_pr

2

sm1_

pr2

?,6

?,6

?,4

?,4

3,6

3,6

3,4

3,44,6

3,6

4,6

3,4

3,44,4

4,44,4

4,4

4,44,4

5,4

5,4

5,2

4,2

4,24,4

n2=6

n2=6

n 1=3

?,?

3,?

136

Page 147: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Figure 10: The modified transitions of pr1 (a) and pr2 (b).

For our example, we consider the following two patterns. The patterns use the values ofthe two variables, n1 and n2.

Pattern 1: It is possible that the variable n2 exceeds the variable n1 by 2 or more, i.e.,n2 ≥ n1 + 2, and later n1 exceeds n2 by 2 or more, i.e., n1 ≥n2 + 2.

Note that the pattern expresses a temporal property. It can be thought of as aninstantiation of the existence pattern with scope "after". We check the occurrence of thestate formula P = (n1 ≥ n2 + 2) after the state formula Q = (n2 ≥ n1 + 2). By directinspection of the graph in Figure 9, one can check that this pattern is present. Clearly,there are five adjacent global states of the system (shown in bold frames), where thecondition Q holds. From either state, the system can reach the other three states (alsoshown in bold frames) where P holds.

In order to illustrate a pattern that is not present in the given trace, we reverse the orderof the two predicates in Pattern 1.

Pattern 2: It is possible that the variable n1 exceeds the variable n2 by 2 or more, i.e.,n1 ≥ n2 + 2, and later n2 exceeds n1 by 2 or more, i.e., n2 ≥ n1 + 2.

Obviously, this pattern is not in the observed behavior of the system.

We build two GOAL observers that monitor the values of n1 and n2, and implement thepatterns. The two observers for Pattern 1 and Pattern 2 are shown in Figure 11 on theleft and right side, respectively. Note how the flags are used to initialize the observers.The observation of the values of the variables does not begin until the flags are set.

The exhaustive simulation of the SDL models together with the observers allows us toverify each property in the trace. The results of the exhaustive simulation (Figure 12)show that there are three scenarios that verify the existence of Pattern 1. On the otherhand, Pattern 2 is not detected in the collected trace; no scenario leads to the successstate of the observer. These results could be verified by inspecting Figure 9.

n1:= 3

fl1:= true

s1

n2:=6

fl2:=true

s1

(a) (b)

137

Page 148: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Figure 11: The observer for patterns 1 (left) and 2 (right).

Number of states : 44Number of transitions : 64Maximum depth reached : 13duration : 0 mn 1 sNumber of exceptions : 0Number of deadlocks : 4Number of stop conditions : 0Transitions coverage rate : 100.00 (0 transitions not covered)States coverage rate : 100.00 (0 states not covered)Basic blocks coverage rate : 100.00 (0 basic blocks notcovered)Number of errors : 0Number of success : 3 observer ant1: 0 errors, 3 success observer ant2: 0 errors, 0 success

Figure 12: Verification results for the two patterns.

6 ConclusionsWe proposed an approach to property verification of execution traces from distributedsystems that is based on SDL and uses the commercial off-the-shelf model checker, theObjectGEODE simulator. The approach assists in checking whether the distributedsystem satisfies certain properties and in pinning down errors to their origins.

The suggested approach takes into account the usual lack of formal designspecifications in practice. It requires merely that the aspects of the distributed systemthe designer or tester is interested in be modeled as patterns. The approach relies on theavailability of a tracing and monitoring tool that must be integrated with the distributedsystem to obtain an execution trace as the basis for analysis. It turns out that in practicethis requirement is not hard to meet since developers usually implement their owntracing mechanisms to help them debug the system. Moreover, non-intrusive methods

event observer pattern1

success state s3;

s0

s0

obp1!fl1 = true and obp2!fl2 =true

s1

obp1!n1 >= obp2!n2+2

s2

obp2!n2>= obp1!n1+2

s3

s3

event observer pattern2

success state s3;

s0

s0

obp1!fl1 = true and obp2!fl2 =true

s1

obp2!n1 >= obp1!n1+2

s2

obp1!n1>= obp2!n2+2

s3

s3

138

Page 149: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

exist already for a number of operating systems that do not require changes of theoriginal source code to collect trace data.

The validity of our approach depends on two main factors: correct matching ofcommunication events and preservation of the local orders of events as stated in thecollected traces. Concerning the first factor, we stated the required assumptions on thetrace to guarantee correct matching. As for the second factor, we use the SDL specialconstruct "SAVE" to preserve the local orders of events.

In addition, we have considered the problem of specifying the desired properties. Forthis purpose, we used a repository of specification patterns [9], and we demonstratedhow typical patterns are mapped into GOAL observers. Moreover, an example has beenused to illustrate the approach.

Finally, this ongoing work includes implementing the front-end tool that automates theprocess of extracting the SDL models and supports the specification of properties inGOAL. Currently, the finished parts of the tool allow us to build SDL models fromexecution traces of real systems.

Acknowledgements. Siemens AG, Germany, financially supports this research project.Fruitful discussions on observers and Goal language with R. Groz and D. Vincent aregreatly appreciated.

References[1] B. Algayres, Y. Lejeune, E. Hugonnet, "GOAL: Observing SDL behaviors with

GEODE", in SDL’95 with MSC in CASE (ed. R. Braek, A. Sarma), Proc. of the 7th

SDL Forum, Oslo, Norway, September, 1995, Elsevier Science Publishers B. V.(North Holland), pp. 359-372.

[2] J. P. Black, M. H. Coffin, D. J. Taylor, T. Kunz, A. A. Basten, “LinkingSpecifications, Abstraction, and Debugging”, CCNG Technical Report E-232,Computer Communications and Network Group, University of Waterloo,November 1993.

[3] K. M. Chandy, L. Lamport, “Distributed Snapshots: Determining Global States ofDistributed Systems”, ACM Transactions on Computing Systems 3(1), pp. 63-75,February 1985.

[4] S. Cheung, K. Levitt, “A Formal-Specification Based Approach for Protecting theDomain Name System”, In Proc. of the Workshop on Depend Despite MaliciousFaults, New York, June 2000.

[5] P. Dauphin, M. Kienow, A. Quick, “Model-Driven Validation of Parallel ProgramsBased on Event Traces”, In Proc. of Programming Environments for ParallelComputing, Edinburgh, 1992.

[6] F. Dietrich, X. Logean, S. Koppenhoefer, J.-P. Hubaux, “Testing Temporal LogicProperties in Distributed Systems”, In Proc. of the 11th International Workshop onTesting of Communicating Systems, Tomsk, Russia, August 1998.

139

Page 150: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[7] M. Dwyer, G. Avrunin, and J. Corbett, “Patterns in Property Specifications forFinite-state Verification”, In Proc. 21st International Conference on SoftwareEngineering, May 1999.

[8] M. Dwyer, L. Clarke, “Data Flow Analysis for Verifying Properties of ConcurrentPrograms”, In Proc. of ACM SIGSOFT’94, New Orleans, LA, USA, 1994.

[9] E. Fromentin, M. Raynal, V. Garg, and A. Tomlinson, “On the Fly Testing ofRegular Patterns in Distributed Computations”, Internal Publication # 817,IRISA, Rennes, France, 1994.

[10] R. Groz, "Unrestricted Verification of Protocol Properties on a Simulation Usingan Observer Approach", Protocol Specification, Testing and Verification, VI,Montréal, Canada, North-Holland, 1986, pp. 255-266.

[11] http://www.cis.ksu.edu/santos/spec-patterns.[12] C. E. Jackl, “Event-Predicate Detection in the Debugging of Distributed

Applications”, Master’s Thesis. Department of Computer Science, University ofWaterloo, 1996.

[13] C. Jard, T. Jeron, G. V. Jourdan, and J. X. Rampon, “A General Approach toTrace-checking in Distributed Computing Systems”, In Proc. IEEE Int. Conf. onDistributed Computing Systems, Poznan, Poland, June 1994.

[14] S. Kumar, E. Spafford, “An Application of Pattern Matching in IntrusionDetection”, Technical Report 94-013, Purdue University, Department ofComputer Sciences, March 1994.

[15] D. C. Luckham and B. Frasca, "Complex Event Processing in DistributedSystems", Stanford University Technical Report CSL-TR-98-754, March 1998, 28pages.

[16] B. Miller, J. Choi, “Breakpoints and Halting in Distributed Programs”, In Proc. ofthe 8th IEEE Int. Conf. on Distributed Computing Systems, San Jose, July 1988.

[17] S. Staniford-Chen, S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoaglan. K.Levitt, C. Wee, R. Yip, D. Zerkle, “GrIDS- A Graph Based Intrusion DetectionSystem for Large Networks”, In Proc. of National Information Systems SecurityConference, Baltimore, MD, October 1996.

[18] S. Staniford-Chen, S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoaglan. K.Levitt, C. Wee, R. Yip, D. Zerkle, “The Design of GrIDS: A Graph-BasedIntrusion Detection System”, Technical Report, Department of Computer Science,University of California at Davis, January 1999.

[19] P. A. S. Ward, "A Framework Algorithm for Dynamic Centralized Dimension-Bounded Timestamps", In Proc. of CASCON 2000, Mississauga.

140

Page 151: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

A formal approach to practical test selection

Tibor Csondes∗

[email protected] Lab, Ericsson Hungary Ltd.,1037 Budapest, Laborc u. 1., Hungary

Balazs [email protected]

London School of Economics and Political Science

Abstract

This paper presents a formal approach to the practical test selection problemthat arises in conformance test laboratories when the question is which test casesfrom a given test suite should be executed. The existing standard ([1]), whichprovides a formal framework to conformance testing, does not deal with thisaspect, although it is an important part of the test laboratories’ activity. Ourgoal is to work out a theoretical background to formal methods tackling the testselection problem. To this aim, we define the relevant notions unambiguously.

Keywords: Telecommunication Systems, Conformance Testing, Test Selection,Formal Approach

1 Introduction

The reduction of the time or effort put into conformance testing while keeping thetest coverage under control is very important for those who perform conformancetesting, usually in a test laboratory. If the time for conformance testing is limited,i.e., there is no time to execute all the test cases, then testers have to select the mostefficient test cases from the whole test suite in order to make testing possible withina shorter period of time. A good selection has important economic advantages. Testlaboratories can complete testing faster or they can achieve higher coverage in agiven time. Therefore, a method which can help them in making the selection moreefficient has considerable practical advantages.

Such a method should be efficient, it should make the test process faster bylosing only a relatively small part of coverage. It also has to be applicable to different

∗Corresponding author. Fax: +36 1 437 7767

141

Page 152: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

types of real-life protocols as the laboratories have to test several implementations ofdifferent vendors. The method has to be flexible, meaning that special preferences ofthe test laboratories and their knowledge of the specific protocol can be incorporated.An important requirement of any kind of testing is that it has to be reproducible,that is, the selection can be repeated if it is needed and the same input data shouldresult in the same selected test set, to ensure objective decisions.

To satisfy these requirements formal methods have to be used. But formal meth-ods need formal notations. The main purpose of this paper is to present a formaldescription of the test selection problem by introducing a mathematical model. Wefirst define the notions and relations relevant to test selection formally, then usingthese definitions we translate the test selection to two optimization problems.

The existing methods do not handle the problem from the practical point ofview. Their aim is either to find efficient test generation methods (see e.g. [2]),the purpose of which is to produce an optimal test suite, or to provide a genericframework to test selection. The most elaborated method of this latter approach isdue to Tretmans ([3]), which bases on the Labeled Transition System description ofprotocols. Another theoretical test selection method is the metric based selection ([4,5, 6]), which uses execution sequences to describe the protocol’s behaviour. Despitethe unarguable theoretical advantages of these methods (including test generation),their main drawback is that they cannot easily be applied in real-life situations. Thisis mainly because they use formal notations that are not available (and cannot beexpected that they will be available in the near future) for any real protocol.

Our approach, however, follows the practice by selecting test cases from theAbstract Test Suite (ATS) of a protocol. Besides the fact that it is the ATS thatis used in test laboratories, another advantage of using it as a basis for selection isthat it is the only available standardized form in conformance testing. To achieveminimal testing time for a given lower bound of coverage or maximal coverage for anupper bound of the cost, our method determines which test cases have to be selectedfor execution. The method is protocol independent, so it can be used in the testingof any protocol.

In what follows, we give a short introduction to conformance testing, listingthe most important notions that are relevant to test selection. Then, in Section 3,we define these notions formally, and introduce a new concept, the subpurposes.Section 4 presents the mathematical model of test selection. In Section 5 we showhow the theory can be put in practice.

2 Conformance testing

Conformance testing is an important step in the life-cycle of telecommunicationprotocols ([7]). Its purpose is to check whether the implemented protocol is conformto standards, and by that to increase the probability that different implementationsare able to interwork. Conformance testing involves verifying that the external

142

Page 153: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

behaviour of the implementations comply with the requirements contained in theirrelevant protocol specifications ([8]).

As a background to our method, in this section we introduce the most importantand relevant notions of conformance testing:

Conformance requirements During conformance testing, a protocol is testedto ensure that it meets the conformance requirements contained informally in therelevant protocol specification ([8]). Basically, a protocol specification is made up ofthe conformance requirements.

Test purposes, test cases The standard ([9]) defines a Test Purpose (TP) as“a prose description of a well defined objective of testing, focusing on a single con-formance requirement or a set of related conformance requirements as specified inthe appropriate OSI specification (e.g.: verifying the support of a specific value of aspecific parameter)”.

Standardization institutes collect the conformance requirements of a protocolspecification and produce test purpose documents. These standardized documentscontain several test purposes in a well-defined form. Different standardization in-stitutes use different forms. For example, within ETSI this task is described in the“Test Purpose style guide” ([10]), guiding the document writers in preparing a testpurpose document.

A test purpose is usually based on a single conformance requirement. In practice,however, test purposes may well concern a set of conformance requirements. The“Test Purpose style guide” lists the following cases when this is allowed: Whenthe test case concerns an aspect specific to a profile, or when the size of the ATSdemands a limitation in the number of test purposes ([10]).

Based on the test purpose document, Test Cases (TCs) are derived: one testcase for each test purpose. This derivation can be done automatically or manually.The automatic test case derivation is based on test generation methods (see e.g.:[2]). The manual test case writing focuses on the protocol specification and theinformally given conformance requirements collected in the test purpose document.

The Abstract Test Suite In order to get a reliable and repeatable verdict ofconformance testing, a standardized test suite, the Abstract Test Suite (ATS) hasto be used. The ATS contains a considerable number of test cases, which focus onthe specific parts of the protocols’ behaviour described in their purposes, and whichcan be executed independently from each other. The test suite is called abstractbecause it is independent from the implementation. This implies that an ATS is notdirectly executable, as it needs further parameterization and compilation.

Ideally, an ATS should be complete, that is, an implementation passes it if andonly if the implementation is correct. Since it is generally not possible to construct

143

Page 154: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

a finite complete test suite, an ATS is required to be sound, meaning that all imple-mentations that do not pass it are not correct. A sound test suite is complete if andonly if it is also exhaustive; that is, if all passing implementations are conforming([1]).

Tree and Tabular Combined Notation (TTCN) Test suites must be specifiedaccording to a test notation. A good test notation is well-defined, independent ofthe implementation, and is generally accepted. The standard ISO 9646 recommendsa semi-formal language, the Tree and Tabular Combined Notation (TTCN).

TTCN can be given in two forms: a graphical form, denoted as TTCN.GR, anda machine-processable form, denoted as TTCN.MP. The graphical form is definedusing tabular proformas, thus it is suitable for human reading or visual interpreta-tion and it is easy to understand. TTCN.MP is suitable for transmission of TTCNdescriptions between different machines and is possibly suitable for other automatedprocessing. Consequently, TTCN is defined in such a way that its automatic execu-tion is possible. In fact, the two different representations of an ATS in graphical andmachine processable format are equivalent. Moreover, using a commercial TTCNeditor, it is easy to convert a TTCN.GR to TTCN.MP and vice versa ([7, 9, 11]).

Test selection The methodology of conformance testing ([9]) defines test selec-tion as a selection process of test cases from an Abstract Test Suite based on specificparameter values contained in the Protocol Implementation Conformance Statement(PICS) and the Protocol Implementation eXtra Information for Testing (PIXIT).The test laboratory selects the set of test cases the corresponding protocol behaviorof which are actually implemented in the IUT. This is usually an automatic selec-tion and keeps the mandatory capabilities, as well as the optional and conditionalcapabilities in view during the selection process ([7]).

In this paper, however, we will use the phrase test selection in a different context.In our terms, and in this we follow [3], test selection means selecting test casesfrom a given test suite in order to get a test set which is executable within limitedresources. During the conformance testing process, the preparation for testing andthe test operation is time intensive and expensive. For this reason, test laboratoriesusually have to omit some test cases and execute only certain ones ([12]). By thisselection, the soundness of the test suite is kept, though its error-detecting capabilitymay decrease.

Coverage The coverage ([1]) is a widely used, though not exactly defined, metricto measure the completeness of a set of test cases with respect to checking theconformance of a protocol. Generally speaking, the coverage of a test suite quantifiesthe percentage the protocol behaviour is ‘covered’. In other words, the coverage isa measurement of the error-detecting capabilities of a test suite. The coverage canbe used to compare test suites; high coverage expresses high quality test suite.

144

Page 155: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

As the whole ATS is usually not complete, the requirements it tests may notcover the entire behaviour of the protocol. However, since the task is to select testcases of a given ATS, the coverage of a set of test cases can be viewed as its relativecompleteness with respect to the whole ATS. That is, it measures how much therequirements of the test suite are covered by the selected test cases. In other words,we can assume the coverage of the whole ATS to be 100%.

3 Formal description

In the previous sections we outlined conformance testing and introduced the test se-lection problem. We listed the requirements an efficient test selection method has tofulfill: it has to be efficient and reproducible. Furthermore, an efficient test selectionmethod has to stand alone, as in that it has to involve as little human interventionas possible. These requirements need the automation of the test selection process.On the other hand, as we are going to apply a mathematical model to test selection,we have to formalize it.

In this section we give a formal description of the basic notations of confor-mance testing presented previously, and introduce a new notation: the subpurposes.They are mathematically well defined parts of a protocol which are automaticallydetectable in the ATS. Finally, we present how the data elements can be used in thetest selection method.

3.1 Definition of subpurposes

Let us suppose that the standardized test suite TS = {t1, t2, . . . , tn} consisting of testcases t1, t2, . . . , tn and the set of corresponding test purposes TP = {p1, p2, . . . , pn}are given. As we explained in Section 2, there is a one-to-one connection betweenthe test cases and test purposes: pi corresponds to ti (i = 1, 2, . . . , n ).

Let REQ = {r1, r2, . . . , rm} denote the set of conformance requirements. Asdefined in Section 2, test purposes are related to a set of conformance requirements,and a test case is written to check the requirements involved in the correspondingtest purpose. The following relation describes this connection between the test casesand the conformance requirements:

ti check rjdef⇔ ti is able to check rj (1)

Although test purposes describe conformance requirements, this description isprose and informal. To apply formal methods, we need a formal representation oftest purposes. To this aim, let us introduce the abstract test purpose Pti for eachtest case ti as a set of conformance requirements that the test case is able to check:

Ptidef= {r ∈ REQ | ti check r} (i = 1, 2, . . . , n) .

145

Page 156: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Note that in the ETSI terminology ([10]) “formal test purpose” is used to de-note a special format of test purposes. This format is a structured description, butit is not suitable for automated processing. On the other hand, conformance re-quirements, which describe the basic features of the protocol behaviour that have tochecked to ensure the conformance of the protocol, are not given in an appropriate,automatically processable or even formal format.

Hence, neither the test purposes nor the conformance requirements are availablein a format that is suitable for automated test selection. That is why we introducesubpurposes.

Definition 1. The subpurposes are automatically detectable approximations of theconformance requirements.

Figure 1 illustrates the relationship between conformance requirements, test pur-poses and subpurposes. Test purposes are made up of conformance requirements,while the requirements can be associated with a set of subpurposes.

��

����

���� �

���

����

��������

����

���� ��������

������

RequirementTest Purpose

Subpurposes

p1 r1

r2

r4

s1

p2r3

s2

s3

sk

Figure 1: Requirements, test purposes and subpurposes

Conformance requirements provide a subdivision of the protocol behaviour: ev-ery relevant aspect of the protocol is described with one or more requirements.Subpurposes provide another subdivision. As both the entire set of conformancerequirements and the subpurposes cover the protocol behaviour, the building blocksof the original subdivision (the conformance requirements) can be described by thebuilding blocks of the second subdivision (the subpurposes).

To formulate this relationship, let SP = {s1, s2, . . . , sk} be the set of subpurposesand for each requirement we associate a subset of SP :

rj #−→ SPrj ⊆ SP for j = 1, 2, . . . ,m (2)

146

Page 157: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

We can extend relation check to subpurposes by defining the set of subpurposesthat are checked by test case ti (i = 1, 2, . . . , n ):

ti #−→ Sti ⊆ SP where Stidef= {s ∈ SP | ∃ r ∈ REQ, r ∈ Pti , s ∈ SPr}

ti check sjdef⇔ sj ∈ Sti

(3)

So far we have described the theoretical way of introducing subpurposes anddefining sets of Sti . In practice, the requirements and therefore the sets Pti arenot given, so we have to define the sets Sti directly and skipping the associationdescribed in (2). We discuss this method in the next section.

As a summary, we classified the most important notions of test selection withrespect to their properties (Table 1). Test cases and test purposes are available instandardized test documents, while subpurposes and requirements are usually not.The difference between requirements (given or not given) and subpurposes is thatsubpurposes are automatically detectable by definition.

Table 1: The classification of the most important notions of test selection

Automatically detectable Not automatically detectableGiven test case test purposeNot given subpurpose requirement

3.2 Determination of subpurposes

In the previous section we introduced subpurposes as automatically detectable partsof the protocol behaviour which can approximate the conformance requirements. Inthis section we present a possible way to determine subpurposes.

The conformance requirements have four components ([13]):

• Messages and their parameters

• Time periods

• States

• Protocol mechanisms

Furthermore, according to the standard ([9]), OSI protocol specifications definedynamic conformance requirements in terms of Protocol Data Units (PDUs) andAbstract Service Primitives (ASPs), that is, data elements.

On the other hand, messages and their parameters from the list above, in otherwords the data, play an increasingly important role in recent protocols. Take for

147

Page 158: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

example the modern WWW protocols (HTTP1.1), or the latest internet protocol(IPv6).

For these reasons, we make the data elements equivalent with the subpurposes.That is, we relate the purpose of a test case to the set of data elements sent orreceived in the test case. Of course, this way we get only an approximation of thereal purpose of the test case but as experimental results show, this approach can bejustified.

On the other hand, data elements used in a test case can be detected automati-cally with the help of the TTCN machine processable format of an ATS.

To make it formal, let DATA = {d1, d2, . . . , dq} be the data elements used bythe protocol. To every test case ti we assign the protocol data elements sent orreceived in ti:

Dtidef= {d ∈ DATA | d used in ti}

Now, as mentioned above, let us map the data elements onto subpurposes, i.e.,SP := DATA by identifying the set of subpurposes checked by a test case with theset of data elements used in it:

Sti := Dti , (i = 1, 2, . . . , n) (4)

3.3 Abstract data levels

Data elements are not well-defined notions in conformance testing, for differentreasons. First, because protocols are different with respect to data content. Thereare protocols where the data have much more importance than the behaviour controlpart, while in other protocols there is more emphasis on the control. In this lattercase, the variety of data is usually poor and its characterizing part lies ‘deeper’, forexample, in the parameters of the messages.

Secondly, different standardization institutes and test suite writers issue ATSswritten in different ways. One prefers to use few, highly parameterized ASPs andPDUs, while the other employs more ASP and PDU constraints.

To get a generic view of data elements, let us now examine what is commonin the data of every ATS. Evidently, there is always a hierarchy in data elements.There are data elements on higher or lower level. Thus, let us define the abstractdata levels as a generic frame to describe this hierarchy. A simple possible set ofabstract data levels is the following:

1. level of data type

2. level of data

3. level of data parameter

148

Page 159: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

This model is the simplest possible one, as further levels, such as the level of theparameters’ parameters can be included, depending on the structure of the data.

To determine the subpurposes, we have to decide which level is the most impor-tant in the ATS. The level which expresses most of the protocol behaviour will playthe role of subpurposes. This decision is made intuitively, based on the protocol andthe way the ATS was written.

If the ATS is written in TTCN, the data levels are the following:

1. ASP and/or PDU type level

2. ASP and/or PDU constraint level

3. parameters of ASPs and/or PDUs: simple types, structured types, etc...

In 2000, ETSI standardized the new version of TTCN (TTCN version 3 [14]).The TTCN-3 does not distinguish between ASP and PDU types, so it is necessaryto change the above structure:

1. message type level

2. template level

3. parameters of template level

Naturally, by the abstract data levels this hierarchy can be applied to any othertesting language.

4 Mathematical model for test selection

In the previous section we gave formal definition of the relations relevant to testselection. Now we show that using this formal description, a mathematical modelof the test selection problem can be developed. In that we will use the theory ofmathematical programming by introducing two optimization problems. We alsoformally define the cost and the coverage of a test set.

We partly presented these ideas in [15], [17] and [18]. Here we show how theformal description of the previous section helps in unambiguous definitions.

4.1 Problem formulation

Let us recall that TS = {t1, t2, . . . , tn} and SP = {s1, s2, . . . , sk} denote the set oftest cases and subpurposes related to a test suite. We define a positive cost functionc : TS → R+ measuring the amount of resources the execution of a test case requires.The relative importance of the subpurposes with respect to the correct behaviour ofthe protocol is represented by the weight function w : SP → R+ . In Section 5.2 wewill discuss how these functions can be determined.

149

Page 160: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

In (3) we defined Sti , the subset of subpurposes test case ti is able to check. Fromanother point of view, a subset of test cases, Tsi is associated with each subpurposesi (i = 1, 2, . . . , k) containing the test cases which are able to check the subpurpose:

Tsi

def= {t ∈ Ts | t check si} (i = 1, 2, . . . , n) .

We will call these tests related to the subpurpose. For the sake of simpler no-tations, let bi denote the number of test cases related to subpurpose si, namely letbi = |Tsi | for each subpurpose.

Following the definitions presented above, we can define the subpurpose-testcase incidence matrix which we will denote as A. Subpurposes (s1, s2, . . . , sk)are placed in the rows, test cases (t1, t2, . . . , tn) are placed in the columns. MatrixA has the following entries:

A (si,tj) ={

1 if tj check si0 otherwise

Let T be an arbitrary set of the test cases, T ⊆ TS. The cost of this test set isdefined as the sum of the costs of the test cases belonging to T :

c(T ) =∑t∈T

c(t) (5)

Let cov(T ) denote the coverage of test set T , that is cov(T ) measures how large partof the protocol is tested by T (below, in (8), we give a formal definition as well).

Two optimization problems can be defined according to our purposes and limi-tations.

Minimal cost problem: Given a lower bound (K) for the coverage. Find the setof test cases that satisfies this bound with minimal cost.

min c(T )subject to cov(T ) ≥ K

T ⊆ TS(6)

Maximal coverage problem: Given an upper bound (L) for the cost. Find thesubset of test cases the cost of which is not more than L and checks as largepart of the protocol (i.e. has as big coverage) as possible.

max cov(T )subject to c(T ) ≤ L

T ⊆ TS(7)

150

Page 161: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Subpurposes represent separate parts of the protocol behaviour and their impor-tance is denoted by their weights. This implies that the coverage of a test set canbe expressed as the weighted sum of the individual coverages of the subpurposes.

cov(T ) =∑

si∈SP

w(si) · purpcov(si, T ) (8)

where purpcov(si, T ) measures in what proportion T covers the basic conformancefeature represented by subpurpose si. Naturally, 0 ≤ purpcov(si, T ) ≤ 1 for allsi ∈ SP and T ⊆ TS. It is assumed that purpcov(si, T ) is a function of the numberof test cases that are related to si and belong to test set T :

purpcov(si, T ) = fi(|Tsi ∩ T |) (i = 1, 2, . . . , k)

for some fi : {0, 1, . . . , |Tsi |} → [0, 1]. The exact values of these functions depend onthe methodology the construction of the test suite followed. We presented possiblealternatives in [15], where we called them coverage models as they determine thecoverage of a test set. We will use this name in this paper too.

5 Test selection process

In this section we show how the theory can be turned into practice. We give apossible approach to the test selection process using the previously presented math-ematical apparatus.

OPTIMIZATION TESTER

weight

optimization problemcoverage model

TTCN.MP CREATION OFTHE MATRIX

inc. matrix

cost

bound

test setselected

Figure 2: The process of selection

Figure 2 illustrates the main phases of the test selection process. Its steps are:

1. Creating the subpurpose-test case incidence matrix manually or automatically.

2. Determining the cost and weight functions (c and w), deciding which optimiza-tion problem (minimal cost or maximal coverage) and coverage model will beused, inputting the cost or coverage bound (L or K), and choosing a suitableoptimization algorithm.

151

Page 162: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

3. Loading the selected test cases into the tester.

For a given ATS of a protocol, the first step (i.e. the creation of the incidencematrix) has to be done only once. This step can be the most time consuming of thetest selection process and it is where the most human interface is necessary. (If donewith the manual matrix filling method, described later.) The fact that the sameincidence matrix can be used for subsequent selections means that the efficiency oftest selection can be strongly improved once the incidence matrix is available froma previous session.

Furthermore, if the incidence matrix is available, we can try to carry out theoptimization for different cost, weight functions, optimization problems or differentcoverage models and bounds in order to find the best test set that meet our aims.

5.1 Creation of the subpurpose-test case incidence matrix

In the test selection process, the most crucial step is the creation of the subpurpose-test case incidence matrix. The incidence matrix contains the most crucial informa-tion about the protocol, that is why it is so important to fill this matrix precisely.On the other hand, this matrix filling can be done only once for a protocol, and itis possible to use it in any optimization method later as many times as needed.

5.1.1 Manual matrix filling

There are protocols (see e.g.: [16]) in which conformance requirements are given inthe ATS standard accompanied by the test cases which can be used to check them.In this case we do not need to deal with deriving subpurposes because we can easilyconstruct a matrix which describe the connection between the requirements and testcases.

In other cases, when the requirements are not given explicitly, they have to bedetermined, or approximated by subpurposes. If the ATS is not given in a ma-chine processable form, (i.e.: in TTCN.MP) the incidence matrix can be filled onlymanually. In this case we cannot speak about subpurposes as they have to be auto-matically detectable by definition. What we do instead is finding the conformancerequirements implicitly given in the protocol description and the test cases andfill the requirement-test case incidence matrix by examining which test case checkswhich requirement. This is a difficult task and requires deep knowledge of the cho-sen protocol and test description, as well as considerable time for real-life protocols.On the upside, the matrix filled by an expert is the one which is the closest to thetheoretical conformance requirement-test case incidence matrix.

An example when manual matrix filling is needed is function testing, a testmethodology widely used in e.g. Ericsson. This test method uses neither the con-formance testing methodology nor the TTCN. For this reason it is impossible tocreate the incidence matrix automatically based on TTCN.MP and the manual ma-trix filling has to be used.

152

Page 163: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

5.1.2 Automatic matrix filling

When a machine processable form of the ATS (usually TTCN.MP) is given, thenthe cumbersome manual matrix filling can be avoided by using subpurposes. Sub-purposes are defined as automatically detectable parts of the protocol’s behaviour(see Section 3.1), so automatic methods can be used to fill the subpurpose-test caseincidence matrix.

A good subpurpose definition result in closer approximation of the theoreticalrequirement-test case incidence matrix, so one has to pay due attention to this step.On the other hand, the determination of the subpurposes needs only a good generalview of the structure of the ATS and the behaviour of the protocol. It does notrequire detailed examination and comparison of test cases as in the case of themanual matrix filling where the conformance requirements and their relation to thetest cases have to be fully detected.

We have to decide first what segment of the protocol is going to play the role ofsubpurposes, in other words, following Section 3.2, we have to choose an abstractdata level (see Section 3.3) which will represent the subpurposes. Although PDUsare the most natural candidates for subpurposes, sometimes it is worth steppingone layer up or down, and choosing the PDU types or the parameters of the PDUsrespectively to be subpurposes, if it results in more efficient selection. The mostappropriate choice of subpurposes depends on the structure of the ATS.

We implemented a PERL program that is able to find the PDUs used in thetest cases and fill the incidence matrix independently of the size of the ATS. Thisprogram can also detect PDUs that are used in the test steps or defaults appearingin the test case. So the PDUs related to a test case are sent either in its main bodyor in a test step or default used in the test case. By this the dependencies of he testcases are handled. For example, when a test case appears as the preamble of anothertest case, the incidence matrix will reflect this fact, consequently this dependency istaken into account in the optimization. The program also deletes the all zero rowsif there are any (i.e.: eliminate the PDUs not used in the ATS), and merge equalrows, because in this case the PDUs related to these rows can be together viewedas one subpurpose.

5.2 Creation of cost and weight vectors

Determining the costs of the tests and the weights of the subpurposes is up to the testlaboratories’ individual preferences, but we think that choosing them to be the samefor each test case and subpurpose, respectively is the most natural solution. As forthe coverage, this is because at first sight there is no theoretical basis to distinguishbetween the subpurposes. The costs can be chosen to be the same because the mosttime consuming task during the conformance assessment process is preparation andparameterization, the time of which is in direct proportion to the number of theexecuted tests. Therefore, in most cases all-one vectors can be used as cost and

153

Page 164: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

weight vectors. In our experiments we also used randomly generated vectors as wellas costs and weights based on the estimation of experts.

5.3 Optimization

Having the subpurpose-test case incidence matrix, the cost and weight vectors athand we have to decide on the optimization problem, coverage model and upper orlower bound. Then the optimization problem should be solved to achieve an optimaltest set which can be executed. There are several possible methods to find optimalor very good quality suboptimal solutions of a mathematical programming problem.

We can transform them to an Integer Linear Programming (ILP) problem andsolve with efficient optimization algorithms (e.g.: Branch and Bound) using com-mercial ILP solving softwares. We published this way in [17]. Another possibility isto directly solve the optimization problems with heuristic algorithms, as presentedin [18]. Anyway, the result of the optimization is a test set which is the best possiblesubject to the constraint, and which, because it was selected from the ATS, can bedirectly loaded into the tester.

6 Conclusion

We have introduced the test selection problem arising in the practice of conformancetest laboratories, where the task is to select test cases for execution from the AbstractTest Suite. We have given a formal description of the problem, on the basis of whicha mathematical model of test selection can be given. We have presented a possibleapproach which translates test selection to mathematical programming problems.We have also shown how this model fits in the practice of conformance testing,making it more efficient.

In particular, we defined subpurposes, an automatically detectable approxima-tion of the conformance requirements and the abstract data levels, which help infinding good subpurposes in a protocol.

The presented approach, possibly with slight modifications, can be applied toother kinds of testing, e.g. function or regression testing.

References

[1] ITU-T Recommendation Z.500, Framework on Formal Methods in ConformanceTesting, 1997.

[2] X. Sun, Y. Shen, C. Feng and F. Lombardi, Protocol Conformance TestingUsing Unique Input/Output Sequences, World Scientific, Singapore, 1997.

[3] J. Tretmans, A Formal Approach to Conformance Testing, PhD Thesis, Uni-versity of Twente, The Netherlands, 1992.

154

Page 165: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[4] S.T. Vuong and J. Alilovic-Curgus, On Test Coverage Metrics for Communi-cation Protocols in J. Kroon, R.J. Heijink, E. Brinksma (Eds.), Protocol TestSystems, IV, Elsevier, 31-45, 1992.

[5] S.T. Vuong, J. Zhu and J. Alilovic-Curgus, Sensitivity Analysis of the MetricBased Test Selection in M. Kim, S. Kang, K. Hong (Eds.) Testing of Commu-nicating Systems, Vol. 10, Chapman & Hall, 1997.

[6] J. Zhu and S.T. Vuong, Generalized Metric Based Test Selection and CoverageMeasure for Communication Protocols in T. Mizuno, N. Shiratori, T. Higashino,A. Togashi (Eds.), Formal Description Techniques and Protocol Specification,Testing and Verification, Chapman & Hall, 299-314, 1997.

[7] B. Baumgarten and A. Giessler, OSI Conformance Testing Methodology andTTCN, Elsevier, Amsterdam, 1994.

[8] M. Bush, K. Rasmussen and F. Wong, Conformance Testing Methodologies forOSI Protocols, AT&T Technical Journal, 84-100, January/February 1990.

[9] ITU-T Recommendation X.290-X.296 - ISO/IEC 9646, Information Technol-ogy - Open Systems Interconnection - Conformance Testing Methodology andFramework, 1994.

[10] ETSI ETR 266; Methods for Testing and Specification (MTS); Test Purposestyle guide, 1996.

[11] R.L. Probert and O. Monkewich, TTCN: The International Notation for Spec-ifying Tests of Communications Systems, Computer Networks and ISDN Sys-tems 23, 417-438, 1992.

[12] R.J. Heijink, FAITH, a General Purpose Test System for ISDN, ComputerNetworks and ISDN Systems 26, 1581-1593, 1994.

[13] K. Tarnay, Protocol Specification and Testing, Akademiai Kiado, Budapest,1991.

[14] ETSI DES/MTS-00063-1 v1.0.10; Methods for Testing and Specification(MTS); The Tree and Tabular Combined Notation version 3; TTCN-3: CoreLanguage, 2000.

[15] T. Csondes, B. Kotnyek, Automated Test Case Selection Based on Subpur-poses, in Gy. Csopaki, S. Dibuz, K. Tarnay (Eds.) Testing of Communicat-ing Systems, Methods and Applications, Kluwer Academic Publishers, 251-265,IFIP TC6 12th International Workshop on Testing of Communicating Systems(IWTCS’99), Budapest, Hungary, September 1-3, 1999.

155

Page 166: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

[16] ETSI Draft prTBR4 Integrated Services Digital Network (ISDN); Attachmentrequirements for terminal equipment to connect to an ISDN using ISDN primaryrate access, 1994.

[17] T. Csondes, S. Dibuz, B. Kotnyek, Test Suite Reduction in Conformance Test-ing, Acta Cybernetica, Vol. 14 No. 2, 229-238, 1999.

[18] B. Kotnyek, T. Csondes, Heuristic Methods for Conformance Test Selection,European Journal of Operational Research, submitted, August 2000.

156

Page 167: BRICS · submitted papers the programme committee selected 9 papers and 1 tool demonstration for presentation at the workshop. Together with the keynote presentation by David Lee

Recent BRICS Notes Series Publications

NS-01-4 Ed Brinksma and Jan Tretmans, editors. Proceedings ofthe Workshop on Formal Approaches to Testing of Software,FATES ’01, (Aalborg, Denmark, August 25, 2001), August2001. viii+156 pp.

NS-01-3 Martin Hofmann, editor. Proceedings of the 3rd InternationalWorkshop on Implicit Computational Complexity, ICC ’01,(Aarhus, Denmark, May 20–21, 2001), May 2001. vi+144 pp.

NS-01-2 Stephen Brookes and Michael Mislove, editors.PreliminaryProceedings of the 17th Annual Conference on MathematicalFoundations of Programming Semantics, MFPS ’01,(Aarhus,Denmark, May 24–27, 2001), May 2001. viii+279 pp.

NS-01-1 Nils Klarlund and Anders Møller. MONA Version 1.4 — UserManual. January 2001. 83 pp.

NS-00-8 Anders Møller and Michael I. Schwartzbach.The XML Revo-lution. December 2000. 149 pp.

NS-00-7 Nils Klarlund, Anders Møller, and Michael I. Schwartzbach.Document Structure Description 1.0. December 2000. 40 pp.

NS-00-6 Peter D. Mosses and Hermano Perrelli de Moura, editors.Pro-ceedings of the Third International Workshop on Action Seman-tics, AS 2000,(Recife, Brazil, May 15–16, 2000), August 2000.viii+148 pp.

NS-00-5 Claus Brabrand. <bigwig> Version 1.3 — Tutorial. Septem-ber 2000. ii+92 pp.

NS-00-4 Claus Brabrand.<bigwig> Version 1.3 — Reference Manual.September 2000. ii+56 pp.

NS-00-3 Patrick Cousot, Eric Goubault, Jeremy Gunawardena, Mau-rice Herlihy, Martin Raussen, and Vladimiro Sassone, edi-tors. Preliminary Proceedings of the Workshop on Geometryand Topology in Concurrency Theory, GETCO ’00,(State Col-lege, USA, August 21, 2000), August 2000. vi+116 pp.

NS-00-2 Luca Aceto and Bjorn Victor, editors. Preliminary Proceedingsof the 7th International Workshop on Expressiveness in Concur-rency, EXPRESS ’00,(State College, Pennsylvania, USA, Au-gust 21, 2000), August 2000. vi+130 pp.