Tools for automated conformance testing of Java Card applets Lydie du Bousquet1
Hugues Martin2
Abstract In this article, we describe a methodology enabling to automatically gener-
ate test suits for Java Card applets. The considered case study is a classical electronic purse. We use two complementary tools: TGV to generate test data, and Umlaut to design an object-oriented model and to translate it into the input format of TGV. The integration of those tools in an industrial process is evaluated in the context of the purse case study. 1
Introduction
The speci c domain of smart cards is close to the domain of embedded devices VV99]. The applications require to be strongly validated before being deployed on thousands or millions of eventually personalized copies. The Open Card platforms have introduced the possibility to change or to update applications embedded during the full life cycle. This possibility of loading and executing new applications during the card life has raised new problems for embedded application validation, as developers and testers do not have necessary cards when they develop new applications. However, the quality and security requirements are still the same as for traditional smart cards. Developers and testers need to use methods and techniques that are compliant with a high security level and that ful ll industrial software development constraints such as time to market. In this context, the validation of Java Card applets needs to be compliant with an object-oriented process and to use techniques that enable to certify a high level of quality and security. In this article, we propose a solution for Java Card applet validation, based on conformance testing, which uses dierent complementary test tools devoted to formal methods. The applet model is speci ed in UML, as it enables to integrate our testing process in an industrial objectoriented development. We assume that the permanent elements of the card: the Java Card Virtual Machine (JCVM) and the Operating System (OS), and that most of security requirements are valid. Our main goal is then to verify the application conformity to the speci cation, and to verify the applet integration with other loaded applets within the card. This article is structured in the following manner. Section two presents the case study used to validate our testing process. Section three is devoted to the presentation of the dierent tools that have been used. Section four describes their integration in our process. Results of their application on our case study is detailed in section ve. Finally, section six is devoted to the conclusions and actual works. 1 2
IRISA, Campus de Beaulieu, 35042 Rennes Cedex, France Lydie.du
[email protected] Gemplus Research Labs, BP 100 13881 Cedex, France
[email protected]
2
Case study: a Java card applet validation
In order to apply our test methodology, we use a well-known type of smart card applications: a purse. The considered purse applet provides ve functions to the card holder: authentication, debit, credit, change currency and display the purse balance. It also provides other administrative functions in order to manage usability constraints. The user authentication process is from the responsibility of the Java Card, contrary to the administrator authentication, which is from the responsibility of the applet. In its full version, our case study contains nine operations intended to the card holder and forty operations intended to the applet manager. Its compiled size, to be embedded in a Java Card, exceeds 23Ko. Its code size exceeds 7000 lines of Java code. It uses the Java Card API and the mechanisms of shareable interfaces to communicate with other embedded Java Card applets. For the purpose of this article, we provide only a very few part of it. This has been selected to show how some security aspects are taken into account. In order to prevent malicious use of the purse, a security protocol has been introduced (see gure 1). For instance, to credit the purse, the user has to perform two actions. The rst one is an initialization (appInitCredit ), which aims at conguring a secure communication between the purse and the card reader. This operation represents a cryptographic key generation. The second operation is the \acknowledgment" of the credit operation (appCredit operation). It consists in performing the credit operation while verifying the correctness of the secure communication. For security reasons, the appInitCredit operation succeeds only if the user is authenticated. Moreover, a key computed when performing an appInitCredit operation has a limited lifetime. It is invalidated by the application if another operation than appCredit is performed just after an appInitCredit operation. It is also invalidated after an appCredit operation. This mechanism is also applied for the user authentication, the debit and the change currency operations. During the initialization phase of those operations, other veri cations can be done. For instance, a credit operation can only be performed if the required amount is positive, and if the resulting balance value is not higher than a prede ned value stored in the MaxBalance variable. 3
Context: existing tools for test generation
3.1 UMLAUT: a UML transformation framework Unied Modeling Language (UML)
Booch, Jacobson and Rumbaugh have proposed the Uni ed Modeling Language (UML) to the OMG, to gather the object-oriented notions into one single language BJR98]. It has been standardized by the OMG, and is now more and more widespread, integrating more and more evolutions RJB97]. UML enables to express models from dierent points of view thanks to several kinds of diagrams. In the following, we are essentially interested in the class diagram, the statechart diagrams and the deployment diagrams. As we want to automatically
Purse applet
Terminal initCredit(amount) key = initCredit answer appCredit(k) credit certificat initCredit(amount) initCredit answer: no key appCredit(k) Credit answer: failure
initCredit(amount) key = initCredit answer appCredit(k) Credit answer: failure
if ‘‘correct’’ amount and user authenticated if (k=key) then do credit operation (a) Correct operation sequence if ‘‘incorrect’’ amount or non authenticated user no key is returned The system do not the operation whatever the value of k is. (b) Incorrect initialization if ‘‘correct’’ amount and user authenticated if (k /= key) the system do not the operation (c) Incorrect acknowledgment
initCredit(amount) key = initCredit answer
if ‘‘correct’’ amount and user authenticated
any operation the operation answer appCredit(k)
The system do not the operation
Credit answer: failure (d) Interrupted operation sequence
Figure 1: The credit secure messaging behavior generate tests, we use UML in a particular way. The resulting model can be computed in order to obtain the expected results with respect to the model (the abstraction of the model is not raised at this step). The class diagram shows the type of the objects present in a system and the static relationships among them. The most important relationships are associations. They represent the relationships between the instances of the class. Association ends have cardinality and may be decorated by an arrowhead to express the navigability in a given direction (navigability expresses the ability
of a class to call the methods of another class). The classes are represented as boxes divided into three parts de ning the name, the attributes and the operations of the classes. There is a speci c type of class which is called \Actor". In a UML model, the set of classes represents the system speci cation, and the set of actors represents the environment speci cation. The class diagram also shows the relations between actors and objects of the application. A statechart is a graphical representation of a statemachine. The original concept was invented by David Harel Har87]. A statemachine is a speci cation of the sequence of states that an object goes through in response to events during its life, together with its responsive actions. It is usually represented as an automaton. A statemachine (or a statechart) is composed of states and transitions. J There are dierent sorts of states in a statechart: simple, initial ( ), nal ( ) or composite. The transitions are labeled. The label is composed of three parts representing the calling event, a guard and the responsive actions (Event Guard] / Actions ). A guarded transition occurs only if the guard is evaluated to true. A deployment diagram shows the con guration of run-time processing nodes and the components that live on them. Deployment diagrams address the static deployment view of an architecture. Umlaut Umlaut is a tool dedicated to the manipulation of UML models. It is a general
framework for UML model transformation JLP98]. In this article, we focus on the Valood module of Umlaut, which is dedicated to the transformation of a UML model into a Labeled Transition System (LTS), for test case generation purposes. Indeed, many tools such as model-checkers or test generator operate in the LTS formalism. They already have proven useful to validate Lotos or SDL speci cations. In this context, the OPEN/CAESAR toolbox Gar98] oers a collection of validation tools based on a common interface oering services to build the accessibility graph of a speci cation. This interface is language independent. Several compilers are provided for the compilation of Lotos and SDL speci cations. They make the speci cations available to the validation tools through the standard graph library interface. Thanks to this separation of concerns, the existing tools can be reused for UML without change, by implementing a compiler. This is also done by Valood module. To perform the transformation into a LTS, Valood needs a consistent model, composed of a class diagram, a deployment diagram, and the statecharts of all the objects present in the deployment diagram. This latter is used to describe how the system is at the initial state i.e. what are the actual system objects. The class diagram speci es the operations attached to the objects, and the statecharts describe the behavior of each object. Intuitively, the behavior of the full system is given by the \composition" of all object statecharts. This \composition" relies on the communication among the objects. Mainly two types of communication can be used. A synchronous one corresponds to a method call. An asynchronous one corresponds to message passing (which can be implemented with queues for instance).
3.2 TGV: a conformance testing tool Conformance testing
In this paper, we focus on a black box functional testing called conformance testing ISO91]. This testing technique is one of the most rigorous Bri88, Tre92]. The key points are that there are a speci cation and a system implementation exhibiting behaviors. The speci cation is a prescription of what the system should do. The goal of the testing is to check whether the implemented system satis es this prescription. The usual theoretical approach is to consider a formal speci cation of the Implementation Under Test (IUT) intended behavior. According to attended security level, the tester identi es a conformance relation (or a fault model) that is used to de ne an implementation correctness criterion, with respect to the formal speci cation. This conformance relation also allows to formally de ne test cases, their execution on an IUT, and the notion of verdict associated to this execution. Three verdicts are generally distinguished. Informally, \fail" means rejection by the test case, \pass" means that the goal of the test experiment (described by a so called test purpose) is reached, and \inconclusive" means that the implementation correctly behaves but, due to the lack of control on the IUT, does not allow to reach the expected goal. As verdicts should be strongly related to conformance, a notion of correctness of test cases can be de ned. For example, a sound test case will declare \fail" only non-conformant implementations with respect to the speci cation. We may also require that any implementation which does not conform to the speci cation in a behavior targeted by the test purpose might be rejected by a fail verdict (we call it \partial completeness"). Some other correctness criteria involving \pass" and \inconclusive" verdicts can also be de ned.
TGV
During the last decade, conformance testing theory and algorithms for the generation of tests have been developed. TGV is such a tool. It is developed by IRISA JM99], and relies on the OPEN/CAESAR libraries Gar98]. TGV needs as inputs a speci cation and a test purpose. The speci cation can be expressed as a Labeled Transition System (LTS). A LTS is a structure consisting of states with transitions between them, where transitions are labeled with actions or events. An example of a coee machine speci cation is given gure 2. This speci cation indicates that the coee machine should rst \receive" one or two coins, and an order (tea or coee, with or without sugar), and then \emit" the right product(s). A test purpose is used to select a part of the speci cation, for which a test case will be generated. A \good" test purpose should be simple (typically, much simpler than the speci cation) and should select exactly the scenarios that the user has in mind. Two test purposes (TP) are given gure 3. The test purpose TP1 means that one wants to select a test case in which the coee machine should receive an input whose name begins with \co" (i.e. coee or coin), and then \emit" sugar. The end of the test is denoted by a transition labeled \accept" in the test purpose. So in TP1, the test will be completed after the sugar \emission".
?coin ?coin ?tea+suggar !tea !sugar
?tea !tea
?coffee !coffee
?coffee+sugar !coffe !sugar
?i: specification input !o: specification output
Figure 2: Speci cation of a coee machine, expressed in LTS The test purpose TP2 diers from TP1 by the input name \cof*" (i.e. coee) instead of \co*". Given a speci cation and a test purpose, TGV generates only one abstract test case. If the test purpose TP1 is used, TGV will produce non-deterministically one of the two test cases (TC1 or TC2). If the test purpose TP2 is chosen, TGV will generate only TC2. This one indicates that after the insertion of two coins and a \coee+sugar" command, the environment should obtain some coee and sugar. As one can notice, the test case actions have not the same orientation as the speci cation ones. Indeed, the speci cation expresses the implementation under test viewpoint. On the contrary, a test case speci es what the environment (here the coee machine users) should do and observe during the test. !coin !coin !coffee+sugar
!coin ?co*
?cof*
!sugar
!sugar accept
accept TP1
TP2
!tea+sugar Fail
?tea ?sugar Pass
Fail TC1
?coffee ?sugar Fail Pass TC2
Fail
Figure 3: Some examples of test purposes and test cases TGV relies on ecient algorithms which are based on adaptations of onthe-y model-checking algorithms JM99]. \On-the-y" means that the test case generation is done in a lazy way. During the computation, the speci cation state space is not completely stored, so that state explosion problem is limited.
TGV and UMLAUT connection
As we said before, for the present work, we express the speci cation with a UML model. The speci cation is automatically translated into a LTS thanks to the Umlaut tool JLP98]. One important point to note is that the use of TGV is possible only if the speci cation denotes a closed system. This means that the LTS speci cation should contain no free variable. So, to make the connection between TGV and Umlaut possible, the UML model should correspond to a closed system. First, the UML model should describe both the implementation under test and its environment. The environment is modeled by one or several actors. For instance, the purse is the implementation under test, and the card reader (or terminal) is the environment. The system speci cation is deduced from the statemachine composition of the actors and of the implementation objects. The actor statemachine(s) should invoke the implementation under test methods. For instance, appInitCredit is a methods of the purse implementation. The user statemachine should contain at least a transition labeled by appInitCredit. Moreover, since appInitCredit has some parameters, one has to instantiate them. Let us consider that appInitCredit has one parameter \ca" that is the credit amount. Then, one transition in the actor statemachine could be appInitCredit(100). Usually, the parameter values are selected using a classical partition testing strategy WC80]. The actor statemachine should also provide some methods that the implementation under test (IUT) could call to deliver its results. Those methods will usually have some parameters. Those parameters are not free variables, since their values are xed by the IUT.
3.3 Test generation for the Purse case study Environment description with UMLAUT
A Java Card applet is a reactive system, i.e. it is a system that is supposed to interact continuously with its environment Pnu86]. Moreover, it is supposed to react to any solicitation of the environment. The card reader (or terminal) is generally blocked between the card solicitation and its reaction. We consider that the system environment is the terminal (Fig. 4(a)), and we model it with a two-simple-state statemachine. The gure 4(b) gives the outlines of the statemachine. The system responses are always displayed with the same operation, called \show" in our model. The terminal operations are for instance appInitCredit(100). In the nal model of the purse, we elicit 143 transitions for the terminal operations, which correspond to the chosen parameter instantiations for the 47 methods of the purse.
Diculties during test generation
To use TGV, we have to exhibit a set of test purposes. Considering smart card validation, the number of test purposes can be very large compared to the application size, depending on the abstraction level of the model. In case of Java Card
ter 1
usm
PURSE
terminal operations
1
TERMINAL
system answers
(a) Simplified class diagram
(b) Simplified statechart for the terminal actor
Figure 4: One reactive system environment model application, an important part of security features is provided by the Java Card platform. As we suppose the platform validity, some tests purposes dedicated to speci c smart card constraints can be removed. Smart card applications, and so Java Card applications require well known properties such as every function must be valid, available and every misuse must have been anticipated. One test strategy for conformance testing consists in testing each function for every normal use and every possible misuse. During the work on the case study, we noticed that for each property to validate, we had to produce a lot of similar test purposes. For instance, we indicate that the credit operation can only be done if the user is authenticated, if the required credit amount is positive, if the balance will not exceed MaxBalance and if the secure messaging is correctly done. Each of these operations can be done with correct or incorrect parameters: correct or incorrect PIN and key for appVerifyPIN operation call, correct or wrong key for appCredit. For appInitCredit, the amount can be positive, null, negative, or greater or equals to MaxBalance. To check the credit function, we found interesting to generate one test case for each combination of the dierent parameters values, thus 4*2*4 test purposes. Those test purposes dier only from the value of the parameters. The process of creating the test purposes by hand is repetitive, and is a curb to a large scale use of TGV. 4
Integration of the tools in an industrial process
Test purpose design
The test purpose design is one of the most important phase in the testing process with TGV. The number of errors that can be discovered depends of the test purpose set. If a large test purpose subset is forgotten, then some errors could be missed. So it is important to provide some help and/or to facilitate the work of test purpose design. We decided to study this problem in the context of the purse case study. The solution we proposed here relies on the fact that a lot of test purposes are really similar. Two test purposes can be similar because they describe the same sequence of actions but with dierent parameters. Or, they can
be similar because they represent the same \type" of sequence. For instance, to check the purse behavior when the user secure messaging is interrupted, one may design a test purpose in which the credit function is used, and a similar test purpose using the debit function.
action1(*) action2(*) Accept high−level test purpose buildTP
action1(*) action2(*) Accept high−level test purpose TGV
action1(56) action2(12,34) Accept instanciated test purposes TGV
action1(56) event(5749) action2(12,34) (Pass) test case set (b)
action1(56) event(5749) action2(12,34) (Pass) test case set (a)
Figure 5: Approach for test purpose design Our solution consists in oering a front-end before TGV. It takes as input a high-level test purpose, and generates automatically the associated set of instantiated test purposes (see Figure 5(a)). We call this front-end program BuidTP. For instance, let us consider the credit function validation. A high-level test purpose can be \HTP1 =(appVerifyPIN(*) . appInitCredit(*) . appCredit(*) )", where \*" means that the parameters should be instantiated and \." stands for the concatenation. The parameter instantiations are chosen in the set of transitions de ned in the actor statechart(s). Figure 6 depicts a test purpose produced by BuilTP from HTP1. In the tex-
tual representation, \des()" indicates the initial state, the transition number and the state number. The expressions \ter!" and \ter?" identify the environment emission and reception events. The user PIN is 9999, and MaxBalance is equal to 300. des(0,6,6) (0,"ter?usm.appInitVerifyPIN",1) (1,"ter?usm.appVerifyPIN(9999,4444)",2) (2,"ter?usm.appInitCredit(200)",3) (3,"ter?usm.appCredit(11110)",4) (4,"ter!*",5) (5,accept,5)
TP textual representation
des(0,8,9) (0,"ter!usm.appInitVerifyPIN",1) (1,"ter?show(44443,ok)",2) (2,"ter!usm.appVerifyPIN(9999,4444)",3) (3,"ter?show(0,ok)",4) (4,"ter!usm.appInitCredit(200)",5) (5,"ter?show(11110,ok)",6) (6,"ter!usm.appCredit(11110)",7) (7,"ter?show(0,ok),(PASS)",8) TC textual representation
Figure 6: Example of a test purpose and its corresponding test case The high-level test purposes can also be expressed with sets of methods. Indeed, in BuildTP, it is possible to de ne some \sets" to gather similar methods with respect to their role in the application. For instance, we can introduce the sets \adm" and \app", which contain respectively the administrative and applicative methods. We also de ne the sets \init Secure Messaging" (init), \acknowledgment Secure Messaging" methods (ack), \SetAttribute" (set), \GetAttribute" (get), and \AllMethods" (all). For example, the appInitCredit method belongs to the sets \all", \app" and `init", (see gure 7). It is also possible to link two methods. The link \NumAck" allows to declare that the acknowledgment method of appInitDebit is appDebit.
High-level test purpose and test hypothesis
The most general high-level test purpose is HG = \ all n ", with an integer that has to be xed. It represents all the sequences of actions. It can be considered as an exhaustive test (with respect to the environment domain de ned in the speci cation). Unfortunately, this strategy is usually impossible to apply. For instance, with the nal model of the purse, the set \all" contains 143 elements (number of instantiated transitions in the terminal statemachine). So, if is xed to four, the BuildTP has to generate more than 400000000 instantiated test purposes. n
n
n
Since exhaustive testing is not possible, one has to re ne the high-level test purposes. It is then possible to formulate explicitly some test hypothesis Pha94], and then to evaluate whether there are relevant or not.
10 11 12 13 14 15 16
appInitCredit appInitDebit appInitExchange appInitVerifyPIN appGetBalance appCredit appDebit appExchange appVerifyPIN
60 61 62 63 64 65 66 67 68
ALL
CONF NumAck
noOP APP ADM GET SET INIT admVerifyAdmPIN admInitAdmMode admGetExpirationDate admSetExpirationDate admSetSystemKey admGetMaxBalance admSetMaxBalance
X X X X X 10 X X X X X X X X X X X X X X X X X X X X X X X X X
X X X X
65 66 67 68
X X X X X
X X X X X X X X X
Figure 7: Example of types for the Purse methods For instance, let us study again the validation of the user secure messaging. One property is that the initialization and the acknowledgment operations should be performed consecutively. If one or several operations are done between the initialization and the acknowledgment, the acknowledgment should fail (see gure 1(d)). We can design the following high-level test purpose to validate this property: user authenticated] . init . alln . confNumAck where \user authenticated" is a precondition of the high-level test purpose. An explicit test hypothesis is to assert that the user secure messaging behavior is the same for all 2 1 1. This hypothesis allows us to x to 1. n
::
Executable test cases
n
The last step of the tools integration consists in translating abstract test suites previously generated into concrete test suites. In order to perform it, we have developed a translator: aut2Java, that raises the abstraction done when building the UML model and test purposes. The abstraction were done by selecting concrete values for method parameters. Using a dictionary of actions, aut2Java replaces all the actions by concrete method calls and concrete response data.
Case study
In a rst experiment, we expressed 10 high-level test purposes. It allows us to generate 1800 test cases. It took less than half a day to generate the abstract test cases, to compile and to execute them. It took 8 days to generate aut2Java and to set up BuildTP. We found 38 errors, among which the fact that the user secure messaging was interruptible for the change currency function. 5
Results
The methodology integrating the previously detailed tools has been applied to the case study described in the second section of this article. In order to analyze these results, a manual process has been applied at the same time. The results of both process are described in gure 8.
Process Errors found Number of test suites Time spent Manual Automated Both
39 38 49
95 1800 NA
25 15 NA
Figure 8: Case study results At a rst glance, one can notice that the automated testing process has required less days to obtain similar results as those obtained using a manual process. However, when comparing the test suites and the errors found, it appears that each process has its own advantages. On the one hand, the UML model and the associated test purposes use abstractions that are not present in the manual process. As a consequence, the manual process has found some errors that cannot be detected by the automated process. On the other hand, the automated process has not missed some combinations of actions that were voluntary and involuntary omitted by the manual process. At last but not least, the systematic manual process was less rigorous than the automated process. Considering that the UML model was too abstract, we have pursued both manual and automated tests. It appears that manual process has discovered some new errors that were detected by the automated process. However, omissions was still present in the test suites. Considering automated tests, it appears that reducing abstractions is not trivial, but the resulting tests suites are still more complete than the test suites generated by the manual process. In order to determine in which cases a automated process is suitable for Java Card applications, we should perform several experiments, with the following constraint: { Each experiment should stop only when the UML model integrates all data structure (concrete enough to generate all the required tests).
{ Each experiment should integrate development time, number of lines of code
and test delay to elaborate ratio and rules for automated Java Card testing. { Each experiment should take into account applet correction and evolution in order to precise the adaptability of the automated process to the life cycle of industrial developments. 6
Conclusion and perspectives
In this article, we have presented a testing process that uses dierent complementary tools in order to automatically generate test suites for Java Card applications. We have chosen UML as speci cation language, as it enables to describe in an object-oriented fashion the Java Card applications. We use the Umlaut tool, in order to convert UML diagrams in an object-oriented model suitable for test suites generation. We use the TGV test tool, as it enables to generate tests suites that are conform to the applet speci cation. We use BuildTP in order to generate test purposes that are compliant with a smart card process and that can be interpreted by TGV. We use aut2Java in order to generate concrete test suites for our thousands abstract test suites. To evaluate our methodology on smart-card applications, we have applied all these complementary tools on a case study. Resulting tests show that our methodology can be applied to Java Card applications, provided that human tester manages data. In order to increase industrial applicability, it could be suitable to specify test purposes in UML, instead of LTS. So, tester and developers could use together only one speci cation language, and all test data could be expressed in only one model. Moreover, it could be interesting to integrate the BuildTP front-end in TGV (Fig. 5(b)). In order to optimize test execution, it could be interesting to compile tests suites in order to test each path in the control ow as less as possible. Finally, for a very industrial point of view, it could be suitable to integrate all the speci cation and test tools together, in order to automate the transition between all of them. References
BJR98] G. Booch, I. Jacobson, and J. Rumbaugh. The Uni ed Modeling LanguageUser Guide. Addison-Wesley, 1998.
Bri88] E. Brinksma. A theory for derivation of tests. In S. Aggrawal and K. Sabnani, editors, Protocol Speci cation, Testing and Veri cation VIII, 1988.
Gar98] Hubert Garavel. Open/csar: An open software architecture for verication, simulation, and testing. In Proceedings of the First Int. Conference on Tools and Algorithms for the Construction and Analysis of Systems (TACAS). LNCS 1384, Springer Verlag, 1998.
Har87] D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231{274, 1987.
ISO91] ISO. Information Technology, Open Systems Interconnection, Conformance Testing Methodology and Framework. International Standard IS-9646. ISO, Geneve, 1991. Also: CCITT X.290{X.294.
JLP98] Jean-Marc Jezequel, Alain LeGuennec, and Francois Pennaneach. Validating distributed software modelled with UML. In Proc. Int. Workshop UML98, Mulhouse, France, June 1998.
JM99] T. Jeron and P. Morel. Test generation derived from model-checking. In Computer Aided Veri cation (CAV). LNCS 1633, Springer-Verlag, 1999.
Pha94] M. Phalippou. Relations d'implementations et hypotheses de test sur des automates a entrees et sorties. These, Universite Bordeaux I, France, septembre 1994.
Pnu86] A. Pnueli. Application of temporal logic to the specication and verication of reactive systems : a survey of current trends. Current Trends in Concurrency, LNCS, Springer-Verlag, 224:510{584, 1986.
RJB97] J. Rumbaugh, I. Jacobson, and G. Booch. Uni ed Modeling Langage Reference Manual. Addison-Wesley, 1997.
Tre92] J. Tretmans. A formal approach to conformance testing. PhD thesis, University of Twente, Enschede, The Netherlands, 1992.
VV99] J.-J. Vandewalle and E. Vetillard. Developing smart card-based applications with java card. In Third European Research Seminar on Advances in Distributed Systems (ERSADS), Madeira Island - Portugal, April 1999.
WC80] L. White and E. Cohen. A Domain Strategy for Computer Program Testing. IEEE Transactions on Software Engineering, pages 247{257, May 1980.
