- Email: [email protected]
Feature interaction detection using a synchronous approach and testing
Computer Networks 32 (2000) 419±431
www.elsevier.com/locate/comnet
Feature interaction detection using a synchronous approach and testing q L. du Bousquet *, F. Ouabdesselam, J.-L. Richier, N. Zuanon LSR-IMAG, BP 72, 38402 Saint Martin d'H eres cedex, France
Abstract We present a synchronous framework for both modeling, specifying telephone systems, and detecting interactions among services. The detection process is based on automated testing techniques provided by the tool that we developed, Lutess. Lutess allows driving the test with operational pro®les or behavioral patterns. The use of Lutess in the First Interaction Detection Contest led to very good results, since most interactions foreseen by the Contest Committee have been detected. Ó 2000 Published by Elsevier Science B.V. All rights reserved. Keywords: Feature interaction detection; Validation of telecommunication services; Automated speci®cation-based testing; Synchronous programming
1. Introduction This paper is concerned with the use of formal description techniques for the detection of telephone feature interactions, at the speci®cation stage. It focuses on our proposal for detecting interactions in the First Feature Interaction Detection Contest, held during the Fifth Feature Interaction Workshop [12]. A feature interaction occurs when the activation of two features (or two activations of the same feature) produces an unexpected behavior. Although much eort has been devoted to this q This work has been partially supported by a contract between CNET-France Telecom and University Joseph Fourier, #957B043. * Corresponding author. E-mail addresses: [email protected] (L. du Bousquet), [email protected] (F. Ouabdesselam), [email protected] (J.-L. Richier), [email protected] (N. Zuanon).
problem, there is still much debate as to how to deal with interactions, and on how interaction should be de®ned. As a contribution to this debate, we propose a solution, which consists of validating models of features by testing prototypes derived from executable speci®cations of the features, in a synchronous context. Given an executable speci®cation S of a telephony system including some features, a description of its environment E and a set P of properties which S must satisfy, validating S consists of comparing behaviors produced by S with respect to E and P. S and P are expressed in Lustre [5], which is both an executable speci®cation language and a linear past temporal logic [19]. E is described in an extended form of Lustre. The testing techniques on which our method lies are characterized by an automated test data generation and an automated verdict production. However, identifying interactions has to be performed manually.
1389-1286/00/$ - see front matter Ó 2000 Published by Elsevier Science B.V. All rights reserved. PII: S 1 3 8 9 - 1 2 8 6 ( 0 0 ) 0 0 0 0 8 - 6
420
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
We have decided to favor a testing approach for several reasons: 1. Like testing, feature interaction detection can be viewed as ®nding errors in a program. Moreover, testing allows to assess the suitability of a software product to its operational role and interaction occurrences are strongly connected to the feature contexts of execution. 2. Testing is always feasible, whatever the size of the system to be tested. This is not true for similar approaches such as model-checking. 3. Our testing tool, Lutess, provides an environment which is appropriate to evaluate the adequacy of a property. This is particularly useful when searching for interaction is inconclusive and the relevance of the property must be questioned. Section 2 details the synchronous approach. Section 3 de®nes the notions of feature and interaction. Then, Section 4 describes our testing tool. Section 5 explains how the detection phase was conducted and how interactions revealed themselves. Section 6 mentions related work. Finally, Section 7 discusses the results and Section 8 concludes this experiment. 2. Background: synchronous approach Reactive programs are applications that continuously interact with their environment: to each input provided by the latter, the application reacts by emitting an output. Synchronous programs [3] are a sub-class of reactive programs which satisfy the synchrony hypothesis: every reaction of a synchronous program is instantaneous. Synchronous programs have cyclic behaviors: at each tick of a global clock (also called instant of time), all inputs are read and processed simultaneously, and all outputs are emitted. The synchronous approach helps avoid the combinatorial explosion problem, which impairs the approaches based on parallel and communicating processes. Indeed, all parallel components of a synchronous system react simultaneously and, thus, their executions are not intertwined [3]. An additional consequence of this characteristic is that all state transitions (which take place at each reaction) are visible from the environment.
Our work is more precisely based on Lustre, a synchronous declarative data-¯ow language [5]. Lustre oers usual arithmetic, Boolean and conditional operators and two speci®c operators: pre, the ``previous'' operator, and ! the ``followed-by'' operator. Let E and F be two expressions of the same type denoting the sequences (e0 ; e1 ; . . . ; en . . .) and (f0 ; f1 ; . . . ; fn . . .); pre E denotes the sequence (nil; e0 ; e1 ; . . . ; enÿ1 . . .) where nil is an unde®ned value. E ! F denotes the sequence (e0 ; f1 ; . . . ; fn . . .). Lustre is an executable speci®cation language, which corresponds also to a linear past temporal logic [9]. Therefore, temporal logic formulae are easily evaluated in an execution of a Lustre program. Lustre allows the speci®er to de®ne its own logical and/or temporal operators to express invariants or properties. For example, in this paper, we use the user-de®ned temporal operator Once A from B to C to specify that A must hold at least once between the instants when, respectively, B and C occur. 3. Feature and interaction de®nitions In the contest, the detection of interactions concerns pairs of features. The composition operation and the notion of interaction have to be de®ned by the contestants. A feature is a complement to the basic two-party service known as the Plain Old Telephone Service (POTS); thus it cannot stand by itself. In this paper, we consider that a feature F is characterized by a couple (B, P) where B is the feature's behavior and P a set of requirements imposed on F (the properties that the feature is expected to satisfy). The behavior is stated as an executable speci®cation, while the requirements are expressed in temporal logic. The methods applied to obtain from the contest data the speci®cation and the properties, to compose features and to detect interactions are given in this section. Interaction detection is performed on these speci®cations and properties. 3.1. Architecture of the whole telephony system Our approach is based on the construction of a synchronous model of the contest telephony
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
system (also called network). That requires this system to be reactive and consequently to clearly identify what its environment is made of. We have opted for a reactive system including the Switch and the Service Control Point (SCP) (Fig. 1a). Its environment is composed of the set of telephone devices and the Operations System (OS). The messages exchanged between the reactive system and its environment are the events de®ned in the contest instructions (user-to-switch, switchto-user and switch-to-OS). The inputs issued to the executable speci®cation associated with the reactive system are the user-toswitch events, whereas the outputs are the switchto-user events and the events produced for the billing system. For each pair of features, with each user is associated a logical telephone (LT). An LT is a behavioral speci®cation of POTS and the pair of features. The SCP is represented by a unique function, included in each LT (Fig. 1b). The introduction of LTs has been necessary for the following reason: Chisel diagrams represent generic behaviors, that have to be instantiated with the identity of the various users involved in the execution of a feature. In order to avoid enumerating all the possible combinations, we found useful to make explicit the behavior of a feature for each user, regardless of the other users involved in the feature. An LT includes information about the state of the user's phone: what is its current state in the Chisel diagram, optionally, who is its user's party,
421
... It also includes data about the features: which have been subscribed to by the user, and what are the parameters associated with each feature. The simplifying assumptions stated in the contest instructions allowed us to construct more easily our model of the network. These assumptions abstract from classical telecommunication system operations. For instance, one of these assumptions stated that ``user-to-switch messages get an instantaneous response from the switch'', while the communication means between the switch entities was left unspeci®ed. This naturally led to a centralized model, for the description of which the synchronous approach is well-adapted. Other assumptions concern provisioning of features (the subscriptions to each features should be statically set), congestion of the system (no message is delayed nor lost) and timing constraints (e.g., no disconnect delay when a user hangs up). All these assumptions help in producing a simpler speci®cation. 3.2. Building the executable model of a feature For each feature and its Chisel diagram, an executable speci®cation in Lustre is systematically derived. The Chisel diagram is ®rst expressed in the form of one or possibly several I/O automata, which are then translated in Lustre. This intermediary step helps identify the reactive aspects of the system. Translating a Chisel diagram into I/O automata is done in two steps. First, the diagram is analyzed,
Fig. 1. Network model.
422
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
Fig. 2. The two automata for INFB.
so as to identify the dierent users involved in the feature execution. Each user has a ``role'' in the communication. For instance, POTS 1 involves two roles: the caller and the callee. Call Forwarding (INCF) feature involves three roles, the caller, the callee (the user to whom the INCF is provided) and the forwarded-to user (the user to whom the call is redirected as a result of forwarding). The next step consists in projecting the Chisel diagram onto each role. To this end, for each role, the diagram is duplicated and simpli®ed: all the inputs/outputs that do not aect the user with that role are hidden. For example, analyzing the Freephone Billing feature (INFB) leads to two automata, which are informally 2 represented in Fig. 2.
1 Strictly speaking, POTS is not a feature; the construction of its Lustre model is, however, similar in many respects to that of the features. 2 For sake of simplicity, the ®gure abstracts the ``intelligent'' part (i.e., involving the SCP) of the feature.
The state numbering refers to the one in the Chisel diagram. State ``0'' is the state where the feature is idle. The I/O automata are then straightforwardly translated into a single Lustre module. The execution of a feature is distributed among the various LTs that are involved. LTs are composed in a synchronous manner and evolve simultaneously. As a consequence, for one same input, several LTs can react, each one emitting an output to its user. 3.3. Expressing the requirements of a feature The requirements of a feature re¯ect the expectations of the end-user regarding its behavior. They are expressed in a temporal logic (actually in Lustre), on the set of global variables, inputs and outputs. The requirements are inferred mainly from the informal description of the feature. Analysis of the Chisel diagram helps sometimes make them more precise. These requirements can only be obtained by
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
a manual analysis. Discussions about the validity of this analysis can be found in the concluding section. For example, let us consider the Calling Number Delivery (CND) feature. The informal requirements are: · CND1 CND enables the subscriber's telephone to receive and display the number of the originating party on an incoming call. · CND2 For the purpose of the contest, we assume the capability of delivering the number of the calling party whenever an idle called party receives the StartRinging event. From this description, we deduced the following properties, written in Lustre: 1 CNDsub x and ConnectRequest z; x and pre Idle x ) Display x; z 2 CNDsub x ) Display x; z , StartRinging x; z where CNDsub(x) is true if x is a subscriber of CND feature, and ConnectRequest z; x is true whenever a call from z to x is attempted. Other terms are the events or variables de®ned in the contest description. POTS is not considered as a feature for several reasons. First, as a basic and essential component, it is required for building the global service provided to the user. Second, the requirements that might be expressed on it are likely to be altered by any feature. For instance, one requirement on POTS would ensure that the caller is charged for any call he/she makes. Any feature that modi®es the billing of a call will violate this requirement. Therefore, we only consider requirements on the features. Some other requirements are not speci®c to one single feature and deal with the global service. For the most part, these requirements deal with consistency. For instance, to each message initiating a tone or a billing, corresponds a terminating message. To maintain a kind of uniformity in our de®nitions, we consider these requirements as part of the requirements for each feature. 3.4. De®nition of the behavior of a feature In the following, for any set X of variables, VX denotes the set of values of the variables in X.
423
x 2 VX is an assignment of values to all variables in X. Formally speaking, the behavior of POTS or of any feature is described as a set of reactions for each LT. Each set is a partial function, so that the function is de®ned only when POTS or the feature reacts for the given LT. The pro®le of the POTS behavior function is de®ned as POTS : VSG input ! VSP output where · input is the set of incoming events (originated from the environment). · output is the set of events issued to the environment. · SP is the set of variables characterizing the internal state of the user's telephone. This state is handled in the corresponding LT. · SG is a set of all global variables: SG SP1 SPm , where m is the number of LTs and SPi is the set of variables SP of LT i. This global state is internal to the switch. POTS has the same behavior for all users. Note that, in a given LT, SP is common to POTS and all features. Each LT can read the global variables of the other LTs (via SG). This modeling point of view avoids the use of a network or a speci®c channel to exchange data among the LTs. Thus, the switch can have an instantaneous reaction. In a generic manner, for each LT, the pro®le of the behavior function B of a feature F is de®ned as B : VSG VSF input ! VSP VSF output; where SF is the set of F's local state variables, and input, output and SG are as de®ned above. SP is extended with parameters speci®c to F. These parameters are used to indicate whether the user has subscribed to the feature, and optionally, what are the data associated with this subscription. We call a feature instance a particular assignment of values to these parameters. A feature is not a stand-alone component, since it relies on POTS in order to form a complete service, deliverable to the user. The behavior that results from the integration of a feature F B; P B . It consists of into POTS is denoted by POTS
424
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
building F behavioral speci®cation on top of POTS. This behavior is characterized as follows: · both POTS and B are fed with the same input, at the same time. · POTS and B are executed in parallel, and their results are instantaneously available. · if B reacts to the current input (i.e., B is de®ned for the input), the POTS reaction is ignored: thus, SP and SF are updated with respect to B's answer and the output is the one proposed by B. · otherwise, only the POTS reaction is considered to update SP and determine the value of the output. SF does not change. Note that this behavior description is generic, since it does not depend on B's parameter values. 3.5. Composing features Let F1 B1 ; P1 ; . . . ; Fn Bn ; Pn be n features and suppose a priority order among them. For each LT, a composite feature F can be constructed; its generic behavior B is denoted B1 Bn and its requirements P are expressed by the formula P1 ^ ^ Pn . The pro®le of the behavior function for a composite feature is identical to the one of a single feature. B is de®ned as follows: · if several features among F1 ; . . . ; Fn react to the current input, say Fi , Fj , . . ., each SFi is updated according to the reaction of the corresponding Fi . Let Fm be the feature in Fi , Fj , . . . of highest priority, SP is modi®ed with respect to Fm result, and the output is the one proposed by Fm as well. · if only one feature Fi reacts, F evolves in the very same manner than Fi . · otherwise, the composite feature has no reaction. The behavior that results from the integration of a composite feature F B1 Bn ; P1 ^ Bn . ^ Pn into the POTS is denoted by B1POTS 3.6. De®nition of a feature interaction Considering a system including several features, and the features' requirements, an interaction is de®ned as the system's inability to satisfy the requirements of the composite feature.
The method we use for detecting interaction is based on the well-known satisfaction-on-a-model approach (symbolized by a satisfaction relation ). From a very abstract point of view, and by reference to a classical framework [6], we say that there is an interaction among F1 B1 ; P1 ; . . . ; Fn Bn ; Pn when Bi Pi ; 1 6 i 6 n; POTS
V1 ;
B1 Bn 2P1 ^ ^ Pn ; POTS
V2 :
Intuitively, the purpose of V1 is to validate each feature in isolation. V2 aims at evaluating the composition of features with respect to the conjunction of their requirements. As usual in this approach, the satisfaction relation can only be evaluated on a concrete model, i.e. one has to work with features instances and the properties V1 and V2 are evaluated on some speci®c (well chosen) implementations. The de®nition above has to be complemented with the particular case of a self-interacting feature. Indeed, for a given Fi , if V1 is not satis®ed, it may be that Pi or Fi is wrongly speci®ed or that Fi is not consistent with Pi . In the latter case, it would be reasonable to argue that there is an interaction between two instances of Fi . For the purpose of the contest, features were to be combined in pairs. Since is a non-commutative operator, the search for interactions implies to Bi Bj Bj Bi and POTS . analyze both POTS 4. Tool description and operation Lutess [9,18] is the testing tool which we developed to validate reactive synchronous software. It requires three elements: an environment description written in Lustre (D), a system under test (R) and an oracle (X) describing the system requirements (Fig. 3). The environment description is composed of a set of properties, stated as invariants, that the environment of the system is assumed to satisfy. These invariants constrain the possible behaviors of the environment. Lutess builds a random generator from the environment
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
425
Fig. 3. Lutess.
description and automatically constructs a test harness which links the generator, the system under test and the oracle. Lutess coordinates their executions and records the sequences of input± output relations and the associated oracle verdicts, thanks to the trace collector. Components are just connected to one another and not linked into a single executable code. The system under test and the oracle are both synchronous executable programs, whose inputs and outputs are Boolean vectors. Usually, they are supplied as Lustre programs. The test is operated on a single action-reaction cycle, driven by the generator. The generator randomly selects and sends an input vector to the system under test which reacts with an output vector and feeds back the generator with it. The generator proceeds by producing a new input vector and the cycle is repeated. The oracle observes the program inputs and outputs, and determines whether the software speci®cation is violated. The testing process is stopped when the user-de®ned length of the test sequence is reached. Lutess includes a ``trace collector'' which provides 3 functions: a data recorder, a data translator and a data analyzer. The recorder saves the sequence of input, output and oracle data (Boolean values) produced during a test run. The translator displays the Boolean values in a textual form (de®ned by the user). This makes the manual trace analysis more comfortable than the analysis of sequences of Boolean vectors. The analyzer al-
lows the user to replay a test sequence with different oracles. The Lutess generator selection algorithm chooses a valid input vector, i.e., a vector which is in compliance with the environment description. Basically, the selection is done in equally probable way: in each environment state, any valid input vector has the same probability to be selected. However, this method is not ecient enough when it comes to test systems facing a complex environment: the realistic behaviors might be a small part of all possible behaviors. For instance, we noticed that the use of this method resulted in each user dialing his own number as often as any other number. In reality, this behavior is quite rare, though possible. To overcome this drawback, Lutess oers to the user various facilities to guide the generation of test data [9]. For the purpose of the contest, we extensively used two kinds of guides. A behavioral pattern is a means to guide the test data selection in order to generate more frequently some interesting behaviors. A behavioral pattern is made out of alternating and ordered instant conditions and interval conditions. The instant conditions must be satis®ed one after the other. Each interval condition must be continuously satis®ed between the two successive instant conditions which border it. A behavioral pattern characterizes the class of input/output sequences that match the sequence of conditions. The selection algorithm will favour sequences of inputs that match it. Unlike the environment constraints, these additional guides are not to be strictly enforced. As a
426
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
result, all valid behaviors are still possible,while the more reasonable ones are more frequent. An operational pro®le is a way to de®ne the input statistical distribution [17]. In order to take it into account, Lutess provides a way to assign a multiple probability distribution [20] in terms of conditional probabilities associated with the system under test input variables [8]. The variables which have no associated conditional probabilities are assumed to be uniformly distributed. The conditions are given as Lustre expressions. The Lutess selection algorithm chooses the inputs according to the given distribution. 5. Testing and analysis processes For the purpose of the contest, we arbitrarily chose to build an environment composed of four users. This proved to be enough to detect most of the interactions. 5.1. Testing process As shown before, Lutess operates on three elements: a system under test, an environment description and an oracle program. All together, these elements constitute a test con®guration. In this paragraph, we detail how those three elements were built. (a) The system under test is a model of the telephony system made by the combination of the dierent Lustre modules. We built 78 dierent models (one for each pair of features). (b) The environment description concerns physical limitations that the environment simulator should respect in order to remain realistic, and modeling-related constraints and guides. For instance, a user cannot go o the hook twice in a row without going on the hook in between and viceversa. This alternation can be expressed as follows, i being any user: Once On-hook i from Off-hook i to Off-hook i and Once Off-hook i from On-hook i to On-hook i
The environment constraints were the same for all test con®gurations. Some constraints had to be added to take into account new events such as Dial *69 for Return Call (RC) feature.
The environment constraints also de®ne the parameters associated to the subscriptions to the features. These parameters are set at the initial instant, and remain unchanged afterwards. In addition to these constraints, we sometimes provided guides for a given test con®guration. Guides are dedicated to favor the invocation of features. Some simple features are randomly invoked often enough and did not require any guide (e.g., Terminating Call Screening (TCS) or CND). For more complex features, conditional probabilities were necessary. For instance, one simple way of increasing the number of invocations of the RC feature is to favor the event Dial *69. This has been done thanks to the following conditional probability: hDial B 69; 0:7; pre DialTone Bi At last, we used behavioral patterns for the most complex features, like Three-Way Calling (TWC). One way of invoking this feature is to successively lift the receiver, call a ®rst party, wait for him/her to respond then ¯ash and dial another number. This is represented by the following pattern: Off-hook A not On-hook A Dial A B and Idle B not On-hook A Off-hook B not On-hook A or B Flash A not On-hook A or B Dial A C When testing a pair of features, the guides of both features were used. In the situation where both features had a associated behavioral pattern (i.e., both features are hard to be invoked), the guide for the composite feature was automatically built as the concatenation in any order of the two patterns. Quantitatively, 10 pairs of features did not require any guides, 26 led to conclusive results with operational pro®les, and 42 pairs of features required the combined use of operational pro®les and behavioral patterns. The list of features which are subscribed is provided as inputs from the environment. (c) For a single feature and from each requirement expressed in Lustre, an oracle program was automatically derived. For each pair of features,
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
one global oracle was built as the conjunction of all the oracles associated with the features. For each composite feature, the ®rst step of the detection process consisted in testing the model against the global oracle and recording the corresponding traces (sequences of inputs, outputs and verdicts). If false verdicts showed up in some traces, an interaction might be present. Then, the input/output sequences of interest were reevaluated with respect to each oracle of each feature, in order to ®nd out which requirement has been violated and determine whether an interaction has occurred. This operation was carried out using Lutess data analyzer. 5.2. Interpreting traces Interaction detection is based on the observation of oracle violations. Once an interaction is spotted, the human tester has to examine the trace in order to extract the subsequence of events that has led to the oracle violation. A scenario describes an interaction. It is a relevant trace excerpt (a con®guration of the feature subscriptions and input, output and verdict subsequences). Fig. 4 gives a scenario of an interaction between TCS and CND. In this example, C is a TCS and a CND subscriber. B is in C's screening list. When C calls B, TCS proposes a screening announce, while CND displays the number of the calling party to B. Property [CND2] is violated.
427
poral property on a model. This is a classical logical approach in the literature, which is usually based on model-checking techniques [4,6,10]. The method that we have presented here diers slightly from classical approaches in the sense that we consider a synchronous model and we apply automated testing techniques. Some previous works have shown that the synchronous approach can be applied to a telecommunication system [13,16]. Indeed, such systems have many characteristics of reactive systems. They must satisfy some strong time dependencies between external events and their role is to bring about or maintain desired relationships with the environment. In addition, some of their components can be modeled as instantaneously reacting programs (for example switching systems) [2,4]. The emphasis on testing to detect interactions has been advocated by [11]; interaction detection is considered there as a particular case of conformance testing. Using testing, the idea of a statistical approach to feature interaction analysis was put forward in [14]. In terms of interaction detection, exhaustive simulation of an executable model using observers [1] shares analogies with testing. One can note that the way we modeled POTS and features is similar to approaches based on communicating processes [6,10,15]. However, we have exploited the synchrony hypothesis to build a simpli®ed telephony system model whose signi®cant state evolution steps are fewer, all visible and understandable at the user's level. 7. Results and discussions
6. Related work
7.1. Test eort
The core of our approach consists in reducing feature interaction detection to evaluating a tem-
The whole case study required almost 140 stadays eort:
Fig. 4. Relevant trace excerpt (scenario) for the test of TCS CND.
428
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
· 10 sta-days to model the system and design the modeling rules for features, · 3 sta-days to produce the executable model of each feature, · 1 sta-day to extract the properties of a feature and build the corresponding oracle, · 1 sta-day to test each pair of features. Modeling the system and the features led to produce 5000 lines in Lustre code. The validation phase was made of over 1500 runs of Lutess, each pair of features being tested around 20 times with test sequences of length 5000 to 10,000 steps. Description of the environment involved around 30 constraints, each of them being a temporal logic invariant. 30 other properties were used to describe the features requirements. Regarding execution time, a 10,000-step test run took less than 20 min. 7.2. Results The Contest Committee has listed 98 valid interactions. Lutess led us to ®nd 82 interactions, 72 being valid. In the following, we adopt the interaction description format de®ned by the contest committee. The tables specify for each participant the subscribed features, the role and the initial status, while the scenario describes the traces that results in the interaction. (a) Among the 10 interactions that we found and that were not listed by the Committee: · Two seem to be valid, but omitted by the Committee. Both regard the pair of features Cellular (CELL)/ChargeCall (INCC) and appear as billing con¯icts when both features are invoked on a same call. A B
CELL,INCC
Caller Callee
Idle Idle
Scenario: O-hook A; DialTone A; Dial A 0+B; Announce A EnterPhoneNumber; Dial A C; Announce A EnterPIN; Dial A P; StartAudibleRinging A B jjj StartRinging B A; O-hook B; Con¯ict : INCC proposes ``StopAudibleRinging A B jjj StopRinging B A jjj LogBegin A B C Time'' whereas CELL proposes ``StopAudibl-
eRinging A B jjj StopRinging B A jjj LogBegin A B A Time jjj AirBegin A Time''. · Three were found by the Committee, but not considered as interactions, though the essential requirements of a feature appeared in each case to be violated. For instance, between Call Forwarding Busy Line (CFBL) and Call Waiting (CW), the Committee noticed that a forwarded call would not activate CW at the forwardedto user. However, the Committee doesn't seem to consider this inhibition as an interaction in the contest model (i.e. in the Chisel diagrams). · Five were due to ``over-requirements''. That is, we de®ne a requirement too strongly. This concerns mainly to the TeenLine (TL) feature. Actually, we stated that TL should guarantee that no call is ever charged to its subscriber unless explicit authorization (by dialling the correct PIN). We found it a reasonable implicit consequence of the requirements, though we admit that it may be considered as too strong. The major point in this part of our results is that none of these supplementary interactions can actually be said to be invalid. Most of them come from diverging expectations in the requirements. (b) Regarding the missing 26 interactions, not revealed by Lutess: · 10 would have been found by a more thorough testing. These misses were mainly due to lack of time: once we found an interaction between two features, we often lightened the test eort regarding this pair. · 11 are another symptom of an interaction already revealed. We found it not necessary to list all the symptoms of a single interaction. For instance, the Committee listed two interactions between CW and Three Way Calling (TWC) occurring in very similar conditions. The only dierence between them is that, in the ®rst case, the interaction appears when the user goes on the hook, in the second, when the user ¯ashes. To us, these two problems revealed a single con¯ict. This is due to our decision to consider that several interactions may be the symptoms of one single problem. Once the problem spotted, the features should be re-engineered, in order to solve it. As a side-eect, all interactions able to reveal
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
the problem disappear. From this point of view, it is not necessary to reveal twice a single problem. We reported problems more than symptoms. · Four of them would have required another requirement than those that we set. This happened between TWC and CW. All the CW properties that we stated involve a ¯ash event. Since some interactions occurred without any ¯ash performed, we missed them. It would have been very easy to ®nd them with a straightforward property stating that ``an incoming call to a busy CW subscriber should be put on hold''. · One seems to us not to exist according to the contest description. This interaction is described as involving INCC and TWC: when a TWC subscriber invokes INCC to call another user, the Committee considers that TWC should react. Attentive reading of the speci®cation did not allow us to agree on that point. A B
TWC,INCC
Caller Callee
Idle Idle
Scenario: O-hook A; DialTone A; Dial A 0+B; Con¯ict: INCC gives Announce A EnterPhoneNumber. TWC cannot be invoked at this point: the feature requires its user to be talking and to ¯ash. 8. Conclusions 8.1. Test automation From the tester's perspective, our tool allows a signi®cant relief by automating the test. The human eort can then be shifted toward more useful tasks, such as analyzing the results. From the speci®er's point of view, Lutess was shown to be very helpful in debuging speci®cations. First, Lutess has been used to validate the oracles: the oracle speci®cations are put in place of the system under test and a human observation is substituted for the Lutess oracle. Second, prior to the search for interactions, the service speci®cations to be tested have been validated using oracle properties. For instance, in the speci®cations, some possible transitions were missing in a diagram, or an expected output event was never sent
429
in a given situation. These problems were automatically exhibited as oracle violations. 8.2. Synchronous framework adequacy According to our experience, the synchronous approach seems to be well adapted to model telecommunication features. All the notions introduced by the contest have been successfully described in our approach. The simplifying assumptions allowed to easily model the whole system in a synchronous style, as described in Section 3.1. Synchrony also led to concise modeling. The composition of events, as described in the contest instructions, is simpli®ed: instead of having to take into account all the possible sequences of events allowed by this composition, we simply consider all composed events to be simultaneous. Using an executable model was also highly bene®cial to faithfully describe some complex features, e.g., involving loops. 8.3. Test-based validation A test-based approach appears to be more suitable than veri®cation-based methods. Indeed, detecting interaction is equivalent to looking for errors, which is exactly the goal of testing. On the contrary, veri®cation techniques aim at proving the correctness of a piece of software. Even though testing provides less con®dence and less de®nitive results, it is more adapted to this kind of problems. However, such an approach has several weak points. When to stop testing? One of the major problems we had during this experiment was to decide when the test should be stopped. Indeed, testing does not provide a de®nitive verdict on the absence of interaction. In fact, stopping a test run too early was the major reason that prevented us from detecting some interactions. Thus, to evaluate how signi®cant various test sequences were, and to increase con®dence in testing, we have worked along two directions: · since interactions occur mostly during, or just after, feature invocation, we designed some spe-
430
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
ci®c oracles that count how often a feature is invoked. · we also used a model-checker to compare the abilities of various validation methods to detect feature interactions. Experimentation showed that model-checking is often not applicable due to lack of time or memory [7]. Expressing the ``good'' properties. Since the whole detection process is based on the properties describing the requirements, one may ask to what extent are the results dependent on them. To our experience, an interaction shows itself through various signs. Therefore, there are many ways to reveal one speci®c problem and the stated properties just need to uncover one of these signs. So, building the property from the requirements is not the critical part, since several properties can unveil dierent symptoms of a same problem. What is essential is to de®ne properly the good requirements of a feature. If we miss a requirement, chances are, we miss as well some interactions. However, we argue that de®ning requirements can be done quite intuitively and does not demand an expert.
test run. This leads to quicker results when the test harness construction is more expensive than the data generation itself, which was true for the contest. On the other hand, since this method relies on the features' speci®c properties, we had to carefully de®ne them in order to detect all interactions. 8.5. General conclusion Globally, the fact that our approach is based on confronting a model to high-level requirements has proved to be highly pro®table. Indeed, the detection process can be carried out while abstracting from some details of the model; this was particularly adapted to the contest problem because several aspects were left undetailed in the instructions. Consequently, the success of the detection process depends strongly on the stated properties: one has to cautiously analyze the speci®cation in order to extract the adequate properties and to express them in a correct manner.
8.4. Impact of the feature composition operation Since the way in which to compose features was not explicitly stated in the contest instructions, we had to de®ne our own (see Section 3.5). We also examined another way to compose features: when the features propose incompatible answers, the result is an inconsistent event, that violates the integrity constraints (i.e., the properties not speci®c to one feature, see last paragraph of Section 3.3). Meanwhile, feature inhibition (a feature is inhibited when its reaction is not taken into account because of its lower priority) was still possible, and it was still necessary to check the feature properties' validity. Both methods appear to have the same power of uncovering interactions. We chose to use the ®rst one, so as to avoid inconsistent situations. If such a situation occurs when using the second method, it is usually useless to continue the test run, since data are meaningless. On the contrary, the ®rst method allows to keep on testing and to ®nd more interactions, or other symptoms of the same interaction, during one single
Acknowledgements We would like to thank Remy Cave and Jerome Vassy, the two undergraduate students who assisted us in our participation in the contest.
References [1] I. Aggoun, P. Combes, Observers in the SCE and the SEE to detect and resolve services interactions, in: Feature Interactions in Telecommunications Systems IV, IOS Press, Amsterdam, 1997. [2] P.K. Au, J.M. Atlee, Evaluation of a state-based model of feature interactions, in: Feature Interactions in Telecommunications Systems IV, IOS Press, Amsterdam, 1997. [3] A. Benveniste, G. Berry, The synchronous approach to reactive and real-time systems, Proceedings of the IEEE 79 (9) (1991) 1270±1282. [4] J. Blom, R. Bol, L. Kempe, Automatic detection of feature interactions in temporal logic, in: K.E. Cheng, T. Ohta (Eds.), Feature Interactions in Telecommunications Systems III, IOS Press, Amsterdam, 1995, pp. 1±20. [5] P. Caspi, N. Halbwachs, D. Pilaud, J. Plaice, LUSTRE, a declarative language for programming synchronous sys-
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
[6]
[7] [8]
[9]
[10] [11]
[12]
[13]
[14]
[15]
[16] [17] [18] [19]
[20]
tems, in: 14th Symposium on Principles of Programming Languages (POPL 87), Munich, ACM, 1987, pp. 178±188. P. Combes, S. Pickin, Formalization of a user view of network and services for feature interaction detection, in: Feature Interactions in Telecommunications Systems, IOS Press, Amsterdam, 1994, pp. 120±135. L. du Bousquet, Feature interaction detection using testing and model-checking, experience report, in: Formal Method, Toulouse, France, September 1999. L. du Bousquet, F. Ouabdesselam, J.-L. Richier, Expressing and implementing operational pro®les for reactive software validation, in: Ninth International Symposium on Software Reliability Engineering, Paderborn, Germany, 1998. L. du Bousquet, F. Ouabdesselam, J.-L. Richier, N. Zuanon, Lutess: a speci®cation-driven testing environment for synchronous software, in: 21st International Conference on Software Engineering, ACM, May 1999. M. Faci, L. Logrippo, B. Stepien, Structural models for specifying telephone systems, Computer Networks and ISDN Systems 29 (4) (1997) 501±528. J.-C. Godskesen, A formal framework for feature interaction with emphasis on testing, in: K.E. Cheng, T. Ohta (Eds.), Feature Interactions in Telecommunications Systems III, IOS Press, Amsterdam, 1995, pp. 21±30. N. Grieth, R. Blumenthal, J.-C. Gregoire, T. Ohta, Feature interaction detection contest, in: Feature Interactions in Telecommunications Systems V, IOS Press, Amsterdam, 1998, pp. 327±359; also: Comput. Networks 32 (2000) 487±510. L.J. Jagadeesan, A. Porter, C. Puchol, J.C. Ramming, L. Votta, Speci®cation-based testing of reactive software: tools and experiments, in: 19th International Conference on Software Engineering, 1997. K. Kimbler, Towards a more ecient feature interaction analysis ± a statistical approach, in: K.E. Cheng, T. Ohta (Eds.), Feature Interactions in Telecommunications Systems III, IOS Press, Amsterdam, 1995, pp. 201±211. F.J. Lin, Y.-J. Lin, A building block approach to detecting and resolving feature interactions, in: Feature Interactions in Telecommunications Systems, IOS Press, Amsterdam, 1994, pp. 86±119. G. Murakami, R. Sethi, Terminal call processing in Esterel, in: Proceedings of IFIP 92 World Computer Congress, Madrid, Spain, 1992. J. Musa, Operational pro®les in software-reliability engineering, IEEE Software (1993) 14±32. F. Ouabdesselam, I. Parissis, Testing synchronous critical software, in: Fifth International Symposium on Software Reliability Engineering, Monterey, USA, 1994. D. Pilaud, N. Halbwachs, From a synchronous declarative language to a temporal logic dealing with multiform time, in: Symposium on Formal Techniques in Real Time and Fault Tolerant Systems, Warwick, Springer, Berlin, 1988. J. Whittaker, Markov chain techniques for software testing and reliability analysis, Ph.D. Thesis, University of Tenessee, 1992.
431
Lydie du Bousquet was awarded a Ph.D. in Computer Science from Joseph Fourier University, Grenoble, France, in 1999. She received a ``Magistere d'informatique'' and a ``Dipl^ ome d'etudes approfondies'' from Claude Bernard University, Lyon, and ``Ecole Normale Superieure de Lyon''. She is currently a postdoctoral fellow at IRISA, Rennes, France. Her research interests focus on validation of safety critical systems. Farid Ouabdesselam is a Professor of Computer Science at Joseph Fourier University, Grenoble, France. He received his ``Docteur-Ingenieur'' degree from ``Institut National Polytechnique de Grenoble'' and was awarded a ``Habilitation a diriger des recherches'' from Joseph Fourier University. Until 1981, he worked with Thomson, Telemecanique Electrique and SEMS, as a system designer in compiler construction and real-time applications. From 1981 through 1985, he held various faculty visiting positions as Assistant and Associate Professor at UC Santa Barbara and Queen's University (Kingston, Canada). He has published in image analysis, program construction and veri®cation, theorem-proving, testing and software engineering. More recently, he has concentrated on the areas of telephony systems and speci®cation-based testing. Jean-Luc Richier is a full-time researcher in Computer Science with the french ``Centre National de la Recherche Scienti®que''. He graduated from ``Ecole Normale Superieure'', Paris, and was awarded a Ph.D. from University of Paris 6. Until 1983, he was a member of the LITP laboratory, Paris. In 1984, he joined the IMAG Institute, Grenoble. He published in automata theory, model-checking, protocol veri®cation and Internet protocols. He developed the Xesar model-checker for protocol veri®cation. His current research interests include validation of distributed systems using formal methods, services in telephony systems and new generation Internet protocols (IPv6). Nicolas Zuanon is a 3rd year Ph.D. student in Computer Science at Joseph Fourier University, Grenoble, France. He graduated in Computer Science from ``Ecole Nationale Superieure d'Informatique et Mathematiques Appliquees de Grenoble''. His research interests include speci®cation-based testing, applied to the speci®cation and validation of telephone services. His Ph.D. work is partially supported by a contract between France-Telecom and Joseph Fourier University.
www.elsevier.com/locate/comnet
Feature interaction detection using a synchronous approach and testing q L. du Bousquet *, F. Ouabdesselam, J.-L. Richier, N. Zuanon LSR-IMAG, BP 72, 38402 Saint Martin d'H eres cedex, France
Abstract We present a synchronous framework for both modeling, specifying telephone systems, and detecting interactions among services. The detection process is based on automated testing techniques provided by the tool that we developed, Lutess. Lutess allows driving the test with operational pro®les or behavioral patterns. The use of Lutess in the First Interaction Detection Contest led to very good results, since most interactions foreseen by the Contest Committee have been detected. Ó 2000 Published by Elsevier Science B.V. All rights reserved. Keywords: Feature interaction detection; Validation of telecommunication services; Automated speci®cation-based testing; Synchronous programming
1. Introduction This paper is concerned with the use of formal description techniques for the detection of telephone feature interactions, at the speci®cation stage. It focuses on our proposal for detecting interactions in the First Feature Interaction Detection Contest, held during the Fifth Feature Interaction Workshop [12]. A feature interaction occurs when the activation of two features (or two activations of the same feature) produces an unexpected behavior. Although much eort has been devoted to this q This work has been partially supported by a contract between CNET-France Telecom and University Joseph Fourier, #957B043. * Corresponding author. E-mail addresses: [email protected] (L. du Bousquet), [email protected] (F. Ouabdesselam), [email protected] (J.-L. Richier), [email protected] (N. Zuanon).
problem, there is still much debate as to how to deal with interactions, and on how interaction should be de®ned. As a contribution to this debate, we propose a solution, which consists of validating models of features by testing prototypes derived from executable speci®cations of the features, in a synchronous context. Given an executable speci®cation S of a telephony system including some features, a description of its environment E and a set P of properties which S must satisfy, validating S consists of comparing behaviors produced by S with respect to E and P. S and P are expressed in Lustre [5], which is both an executable speci®cation language and a linear past temporal logic [19]. E is described in an extended form of Lustre. The testing techniques on which our method lies are characterized by an automated test data generation and an automated verdict production. However, identifying interactions has to be performed manually.
1389-1286/00/$ - see front matter Ó 2000 Published by Elsevier Science B.V. All rights reserved. PII: S 1 3 8 9 - 1 2 8 6 ( 0 0 ) 0 0 0 0 8 - 6
420
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
We have decided to favor a testing approach for several reasons: 1. Like testing, feature interaction detection can be viewed as ®nding errors in a program. Moreover, testing allows to assess the suitability of a software product to its operational role and interaction occurrences are strongly connected to the feature contexts of execution. 2. Testing is always feasible, whatever the size of the system to be tested. This is not true for similar approaches such as model-checking. 3. Our testing tool, Lutess, provides an environment which is appropriate to evaluate the adequacy of a property. This is particularly useful when searching for interaction is inconclusive and the relevance of the property must be questioned. Section 2 details the synchronous approach. Section 3 de®nes the notions of feature and interaction. Then, Section 4 describes our testing tool. Section 5 explains how the detection phase was conducted and how interactions revealed themselves. Section 6 mentions related work. Finally, Section 7 discusses the results and Section 8 concludes this experiment. 2. Background: synchronous approach Reactive programs are applications that continuously interact with their environment: to each input provided by the latter, the application reacts by emitting an output. Synchronous programs [3] are a sub-class of reactive programs which satisfy the synchrony hypothesis: every reaction of a synchronous program is instantaneous. Synchronous programs have cyclic behaviors: at each tick of a global clock (also called instant of time), all inputs are read and processed simultaneously, and all outputs are emitted. The synchronous approach helps avoid the combinatorial explosion problem, which impairs the approaches based on parallel and communicating processes. Indeed, all parallel components of a synchronous system react simultaneously and, thus, their executions are not intertwined [3]. An additional consequence of this characteristic is that all state transitions (which take place at each reaction) are visible from the environment.
Our work is more precisely based on Lustre, a synchronous declarative data-¯ow language [5]. Lustre oers usual arithmetic, Boolean and conditional operators and two speci®c operators: pre, the ``previous'' operator, and ! the ``followed-by'' operator. Let E and F be two expressions of the same type denoting the sequences (e0 ; e1 ; . . . ; en . . .) and (f0 ; f1 ; . . . ; fn . . .); pre E denotes the sequence (nil; e0 ; e1 ; . . . ; enÿ1 . . .) where nil is an unde®ned value. E ! F denotes the sequence (e0 ; f1 ; . . . ; fn . . .). Lustre is an executable speci®cation language, which corresponds also to a linear past temporal logic [9]. Therefore, temporal logic formulae are easily evaluated in an execution of a Lustre program. Lustre allows the speci®er to de®ne its own logical and/or temporal operators to express invariants or properties. For example, in this paper, we use the user-de®ned temporal operator Once A from B to C to specify that A must hold at least once between the instants when, respectively, B and C occur. 3. Feature and interaction de®nitions In the contest, the detection of interactions concerns pairs of features. The composition operation and the notion of interaction have to be de®ned by the contestants. A feature is a complement to the basic two-party service known as the Plain Old Telephone Service (POTS); thus it cannot stand by itself. In this paper, we consider that a feature F is characterized by a couple (B, P) where B is the feature's behavior and P a set of requirements imposed on F (the properties that the feature is expected to satisfy). The behavior is stated as an executable speci®cation, while the requirements are expressed in temporal logic. The methods applied to obtain from the contest data the speci®cation and the properties, to compose features and to detect interactions are given in this section. Interaction detection is performed on these speci®cations and properties. 3.1. Architecture of the whole telephony system Our approach is based on the construction of a synchronous model of the contest telephony
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
system (also called network). That requires this system to be reactive and consequently to clearly identify what its environment is made of. We have opted for a reactive system including the Switch and the Service Control Point (SCP) (Fig. 1a). Its environment is composed of the set of telephone devices and the Operations System (OS). The messages exchanged between the reactive system and its environment are the events de®ned in the contest instructions (user-to-switch, switchto-user and switch-to-OS). The inputs issued to the executable speci®cation associated with the reactive system are the user-toswitch events, whereas the outputs are the switchto-user events and the events produced for the billing system. For each pair of features, with each user is associated a logical telephone (LT). An LT is a behavioral speci®cation of POTS and the pair of features. The SCP is represented by a unique function, included in each LT (Fig. 1b). The introduction of LTs has been necessary for the following reason: Chisel diagrams represent generic behaviors, that have to be instantiated with the identity of the various users involved in the execution of a feature. In order to avoid enumerating all the possible combinations, we found useful to make explicit the behavior of a feature for each user, regardless of the other users involved in the feature. An LT includes information about the state of the user's phone: what is its current state in the Chisel diagram, optionally, who is its user's party,
421
... It also includes data about the features: which have been subscribed to by the user, and what are the parameters associated with each feature. The simplifying assumptions stated in the contest instructions allowed us to construct more easily our model of the network. These assumptions abstract from classical telecommunication system operations. For instance, one of these assumptions stated that ``user-to-switch messages get an instantaneous response from the switch'', while the communication means between the switch entities was left unspeci®ed. This naturally led to a centralized model, for the description of which the synchronous approach is well-adapted. Other assumptions concern provisioning of features (the subscriptions to each features should be statically set), congestion of the system (no message is delayed nor lost) and timing constraints (e.g., no disconnect delay when a user hangs up). All these assumptions help in producing a simpler speci®cation. 3.2. Building the executable model of a feature For each feature and its Chisel diagram, an executable speci®cation in Lustre is systematically derived. The Chisel diagram is ®rst expressed in the form of one or possibly several I/O automata, which are then translated in Lustre. This intermediary step helps identify the reactive aspects of the system. Translating a Chisel diagram into I/O automata is done in two steps. First, the diagram is analyzed,
Fig. 1. Network model.
422
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
Fig. 2. The two automata for INFB.
so as to identify the dierent users involved in the feature execution. Each user has a ``role'' in the communication. For instance, POTS 1 involves two roles: the caller and the callee. Call Forwarding (INCF) feature involves three roles, the caller, the callee (the user to whom the INCF is provided) and the forwarded-to user (the user to whom the call is redirected as a result of forwarding). The next step consists in projecting the Chisel diagram onto each role. To this end, for each role, the diagram is duplicated and simpli®ed: all the inputs/outputs that do not aect the user with that role are hidden. For example, analyzing the Freephone Billing feature (INFB) leads to two automata, which are informally 2 represented in Fig. 2.
1 Strictly speaking, POTS is not a feature; the construction of its Lustre model is, however, similar in many respects to that of the features. 2 For sake of simplicity, the ®gure abstracts the ``intelligent'' part (i.e., involving the SCP) of the feature.
The state numbering refers to the one in the Chisel diagram. State ``0'' is the state where the feature is idle. The I/O automata are then straightforwardly translated into a single Lustre module. The execution of a feature is distributed among the various LTs that are involved. LTs are composed in a synchronous manner and evolve simultaneously. As a consequence, for one same input, several LTs can react, each one emitting an output to its user. 3.3. Expressing the requirements of a feature The requirements of a feature re¯ect the expectations of the end-user regarding its behavior. They are expressed in a temporal logic (actually in Lustre), on the set of global variables, inputs and outputs. The requirements are inferred mainly from the informal description of the feature. Analysis of the Chisel diagram helps sometimes make them more precise. These requirements can only be obtained by
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
a manual analysis. Discussions about the validity of this analysis can be found in the concluding section. For example, let us consider the Calling Number Delivery (CND) feature. The informal requirements are: · CND1 CND enables the subscriber's telephone to receive and display the number of the originating party on an incoming call. · CND2 For the purpose of the contest, we assume the capability of delivering the number of the calling party whenever an idle called party receives the StartRinging event. From this description, we deduced the following properties, written in Lustre: 1 CNDsub x and ConnectRequest z; x and pre Idle x ) Display x; z 2 CNDsub x ) Display x; z , StartRinging x; z where CNDsub(x) is true if x is a subscriber of CND feature, and ConnectRequest z; x is true whenever a call from z to x is attempted. Other terms are the events or variables de®ned in the contest description. POTS is not considered as a feature for several reasons. First, as a basic and essential component, it is required for building the global service provided to the user. Second, the requirements that might be expressed on it are likely to be altered by any feature. For instance, one requirement on POTS would ensure that the caller is charged for any call he/she makes. Any feature that modi®es the billing of a call will violate this requirement. Therefore, we only consider requirements on the features. Some other requirements are not speci®c to one single feature and deal with the global service. For the most part, these requirements deal with consistency. For instance, to each message initiating a tone or a billing, corresponds a terminating message. To maintain a kind of uniformity in our de®nitions, we consider these requirements as part of the requirements for each feature. 3.4. De®nition of the behavior of a feature In the following, for any set X of variables, VX denotes the set of values of the variables in X.
423
x 2 VX is an assignment of values to all variables in X. Formally speaking, the behavior of POTS or of any feature is described as a set of reactions for each LT. Each set is a partial function, so that the function is de®ned only when POTS or the feature reacts for the given LT. The pro®le of the POTS behavior function is de®ned as POTS : VSG input ! VSP output where · input is the set of incoming events (originated from the environment). · output is the set of events issued to the environment. · SP is the set of variables characterizing the internal state of the user's telephone. This state is handled in the corresponding LT. · SG is a set of all global variables: SG SP1 SPm , where m is the number of LTs and SPi is the set of variables SP of LT i. This global state is internal to the switch. POTS has the same behavior for all users. Note that, in a given LT, SP is common to POTS and all features. Each LT can read the global variables of the other LTs (via SG). This modeling point of view avoids the use of a network or a speci®c channel to exchange data among the LTs. Thus, the switch can have an instantaneous reaction. In a generic manner, for each LT, the pro®le of the behavior function B of a feature F is de®ned as B : VSG VSF input ! VSP VSF output; where SF is the set of F's local state variables, and input, output and SG are as de®ned above. SP is extended with parameters speci®c to F. These parameters are used to indicate whether the user has subscribed to the feature, and optionally, what are the data associated with this subscription. We call a feature instance a particular assignment of values to these parameters. A feature is not a stand-alone component, since it relies on POTS in order to form a complete service, deliverable to the user. The behavior that results from the integration of a feature F B; P B . It consists of into POTS is denoted by POTS
424
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
building F behavioral speci®cation on top of POTS. This behavior is characterized as follows: · both POTS and B are fed with the same input, at the same time. · POTS and B are executed in parallel, and their results are instantaneously available. · if B reacts to the current input (i.e., B is de®ned for the input), the POTS reaction is ignored: thus, SP and SF are updated with respect to B's answer and the output is the one proposed by B. · otherwise, only the POTS reaction is considered to update SP and determine the value of the output. SF does not change. Note that this behavior description is generic, since it does not depend on B's parameter values. 3.5. Composing features Let F1 B1 ; P1 ; . . . ; Fn Bn ; Pn be n features and suppose a priority order among them. For each LT, a composite feature F can be constructed; its generic behavior B is denoted B1 Bn and its requirements P are expressed by the formula P1 ^ ^ Pn . The pro®le of the behavior function for a composite feature is identical to the one of a single feature. B is de®ned as follows: · if several features among F1 ; . . . ; Fn react to the current input, say Fi , Fj , . . ., each SFi is updated according to the reaction of the corresponding Fi . Let Fm be the feature in Fi , Fj , . . . of highest priority, SP is modi®ed with respect to Fm result, and the output is the one proposed by Fm as well. · if only one feature Fi reacts, F evolves in the very same manner than Fi . · otherwise, the composite feature has no reaction. The behavior that results from the integration of a composite feature F B1 Bn ; P1 ^ Bn . ^ Pn into the POTS is denoted by B1POTS 3.6. De®nition of a feature interaction Considering a system including several features, and the features' requirements, an interaction is de®ned as the system's inability to satisfy the requirements of the composite feature.
The method we use for detecting interaction is based on the well-known satisfaction-on-a-model approach (symbolized by a satisfaction relation ). From a very abstract point of view, and by reference to a classical framework [6], we say that there is an interaction among F1 B1 ; P1 ; . . . ; Fn Bn ; Pn when Bi Pi ; 1 6 i 6 n; POTS
V1 ;
B1 Bn 2P1 ^ ^ Pn ; POTS
V2 :
Intuitively, the purpose of V1 is to validate each feature in isolation. V2 aims at evaluating the composition of features with respect to the conjunction of their requirements. As usual in this approach, the satisfaction relation can only be evaluated on a concrete model, i.e. one has to work with features instances and the properties V1 and V2 are evaluated on some speci®c (well chosen) implementations. The de®nition above has to be complemented with the particular case of a self-interacting feature. Indeed, for a given Fi , if V1 is not satis®ed, it may be that Pi or Fi is wrongly speci®ed or that Fi is not consistent with Pi . In the latter case, it would be reasonable to argue that there is an interaction between two instances of Fi . For the purpose of the contest, features were to be combined in pairs. Since is a non-commutative operator, the search for interactions implies to Bi Bj Bj Bi and POTS . analyze both POTS 4. Tool description and operation Lutess [9,18] is the testing tool which we developed to validate reactive synchronous software. It requires three elements: an environment description written in Lustre (D), a system under test (R) and an oracle (X) describing the system requirements (Fig. 3). The environment description is composed of a set of properties, stated as invariants, that the environment of the system is assumed to satisfy. These invariants constrain the possible behaviors of the environment. Lutess builds a random generator from the environment
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
425
Fig. 3. Lutess.
description and automatically constructs a test harness which links the generator, the system under test and the oracle. Lutess coordinates their executions and records the sequences of input± output relations and the associated oracle verdicts, thanks to the trace collector. Components are just connected to one another and not linked into a single executable code. The system under test and the oracle are both synchronous executable programs, whose inputs and outputs are Boolean vectors. Usually, they are supplied as Lustre programs. The test is operated on a single action-reaction cycle, driven by the generator. The generator randomly selects and sends an input vector to the system under test which reacts with an output vector and feeds back the generator with it. The generator proceeds by producing a new input vector and the cycle is repeated. The oracle observes the program inputs and outputs, and determines whether the software speci®cation is violated. The testing process is stopped when the user-de®ned length of the test sequence is reached. Lutess includes a ``trace collector'' which provides 3 functions: a data recorder, a data translator and a data analyzer. The recorder saves the sequence of input, output and oracle data (Boolean values) produced during a test run. The translator displays the Boolean values in a textual form (de®ned by the user). This makes the manual trace analysis more comfortable than the analysis of sequences of Boolean vectors. The analyzer al-
lows the user to replay a test sequence with different oracles. The Lutess generator selection algorithm chooses a valid input vector, i.e., a vector which is in compliance with the environment description. Basically, the selection is done in equally probable way: in each environment state, any valid input vector has the same probability to be selected. However, this method is not ecient enough when it comes to test systems facing a complex environment: the realistic behaviors might be a small part of all possible behaviors. For instance, we noticed that the use of this method resulted in each user dialing his own number as often as any other number. In reality, this behavior is quite rare, though possible. To overcome this drawback, Lutess oers to the user various facilities to guide the generation of test data [9]. For the purpose of the contest, we extensively used two kinds of guides. A behavioral pattern is a means to guide the test data selection in order to generate more frequently some interesting behaviors. A behavioral pattern is made out of alternating and ordered instant conditions and interval conditions. The instant conditions must be satis®ed one after the other. Each interval condition must be continuously satis®ed between the two successive instant conditions which border it. A behavioral pattern characterizes the class of input/output sequences that match the sequence of conditions. The selection algorithm will favour sequences of inputs that match it. Unlike the environment constraints, these additional guides are not to be strictly enforced. As a
426
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
result, all valid behaviors are still possible,while the more reasonable ones are more frequent. An operational pro®le is a way to de®ne the input statistical distribution [17]. In order to take it into account, Lutess provides a way to assign a multiple probability distribution [20] in terms of conditional probabilities associated with the system under test input variables [8]. The variables which have no associated conditional probabilities are assumed to be uniformly distributed. The conditions are given as Lustre expressions. The Lutess selection algorithm chooses the inputs according to the given distribution. 5. Testing and analysis processes For the purpose of the contest, we arbitrarily chose to build an environment composed of four users. This proved to be enough to detect most of the interactions. 5.1. Testing process As shown before, Lutess operates on three elements: a system under test, an environment description and an oracle program. All together, these elements constitute a test con®guration. In this paragraph, we detail how those three elements were built. (a) The system under test is a model of the telephony system made by the combination of the dierent Lustre modules. We built 78 dierent models (one for each pair of features). (b) The environment description concerns physical limitations that the environment simulator should respect in order to remain realistic, and modeling-related constraints and guides. For instance, a user cannot go o the hook twice in a row without going on the hook in between and viceversa. This alternation can be expressed as follows, i being any user: Once On-hook i from Off-hook i to Off-hook i and Once Off-hook i from On-hook i to On-hook i
The environment constraints were the same for all test con®gurations. Some constraints had to be added to take into account new events such as Dial *69 for Return Call (RC) feature.
The environment constraints also de®ne the parameters associated to the subscriptions to the features. These parameters are set at the initial instant, and remain unchanged afterwards. In addition to these constraints, we sometimes provided guides for a given test con®guration. Guides are dedicated to favor the invocation of features. Some simple features are randomly invoked often enough and did not require any guide (e.g., Terminating Call Screening (TCS) or CND). For more complex features, conditional probabilities were necessary. For instance, one simple way of increasing the number of invocations of the RC feature is to favor the event Dial *69. This has been done thanks to the following conditional probability: hDial B 69; 0:7; pre DialTone Bi At last, we used behavioral patterns for the most complex features, like Three-Way Calling (TWC). One way of invoking this feature is to successively lift the receiver, call a ®rst party, wait for him/her to respond then ¯ash and dial another number. This is represented by the following pattern: Off-hook A not On-hook A Dial A B and Idle B not On-hook A Off-hook B not On-hook A or B Flash A not On-hook A or B Dial A C When testing a pair of features, the guides of both features were used. In the situation where both features had a associated behavioral pattern (i.e., both features are hard to be invoked), the guide for the composite feature was automatically built as the concatenation in any order of the two patterns. Quantitatively, 10 pairs of features did not require any guides, 26 led to conclusive results with operational pro®les, and 42 pairs of features required the combined use of operational pro®les and behavioral patterns. The list of features which are subscribed is provided as inputs from the environment. (c) For a single feature and from each requirement expressed in Lustre, an oracle program was automatically derived. For each pair of features,
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
one global oracle was built as the conjunction of all the oracles associated with the features. For each composite feature, the ®rst step of the detection process consisted in testing the model against the global oracle and recording the corresponding traces (sequences of inputs, outputs and verdicts). If false verdicts showed up in some traces, an interaction might be present. Then, the input/output sequences of interest were reevaluated with respect to each oracle of each feature, in order to ®nd out which requirement has been violated and determine whether an interaction has occurred. This operation was carried out using Lutess data analyzer. 5.2. Interpreting traces Interaction detection is based on the observation of oracle violations. Once an interaction is spotted, the human tester has to examine the trace in order to extract the subsequence of events that has led to the oracle violation. A scenario describes an interaction. It is a relevant trace excerpt (a con®guration of the feature subscriptions and input, output and verdict subsequences). Fig. 4 gives a scenario of an interaction between TCS and CND. In this example, C is a TCS and a CND subscriber. B is in C's screening list. When C calls B, TCS proposes a screening announce, while CND displays the number of the calling party to B. Property [CND2] is violated.
427
poral property on a model. This is a classical logical approach in the literature, which is usually based on model-checking techniques [4,6,10]. The method that we have presented here diers slightly from classical approaches in the sense that we consider a synchronous model and we apply automated testing techniques. Some previous works have shown that the synchronous approach can be applied to a telecommunication system [13,16]. Indeed, such systems have many characteristics of reactive systems. They must satisfy some strong time dependencies between external events and their role is to bring about or maintain desired relationships with the environment. In addition, some of their components can be modeled as instantaneously reacting programs (for example switching systems) [2,4]. The emphasis on testing to detect interactions has been advocated by [11]; interaction detection is considered there as a particular case of conformance testing. Using testing, the idea of a statistical approach to feature interaction analysis was put forward in [14]. In terms of interaction detection, exhaustive simulation of an executable model using observers [1] shares analogies with testing. One can note that the way we modeled POTS and features is similar to approaches based on communicating processes [6,10,15]. However, we have exploited the synchrony hypothesis to build a simpli®ed telephony system model whose signi®cant state evolution steps are fewer, all visible and understandable at the user's level. 7. Results and discussions
6. Related work
7.1. Test eort
The core of our approach consists in reducing feature interaction detection to evaluating a tem-
The whole case study required almost 140 stadays eort:
Fig. 4. Relevant trace excerpt (scenario) for the test of TCS CND.
428
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
· 10 sta-days to model the system and design the modeling rules for features, · 3 sta-days to produce the executable model of each feature, · 1 sta-day to extract the properties of a feature and build the corresponding oracle, · 1 sta-day to test each pair of features. Modeling the system and the features led to produce 5000 lines in Lustre code. The validation phase was made of over 1500 runs of Lutess, each pair of features being tested around 20 times with test sequences of length 5000 to 10,000 steps. Description of the environment involved around 30 constraints, each of them being a temporal logic invariant. 30 other properties were used to describe the features requirements. Regarding execution time, a 10,000-step test run took less than 20 min. 7.2. Results The Contest Committee has listed 98 valid interactions. Lutess led us to ®nd 82 interactions, 72 being valid. In the following, we adopt the interaction description format de®ned by the contest committee. The tables specify for each participant the subscribed features, the role and the initial status, while the scenario describes the traces that results in the interaction. (a) Among the 10 interactions that we found and that were not listed by the Committee: · Two seem to be valid, but omitted by the Committee. Both regard the pair of features Cellular (CELL)/ChargeCall (INCC) and appear as billing con¯icts when both features are invoked on a same call. A B
CELL,INCC
Caller Callee
Idle Idle
Scenario: O-hook A; DialTone A; Dial A 0+B; Announce A EnterPhoneNumber; Dial A C; Announce A EnterPIN; Dial A P; StartAudibleRinging A B jjj StartRinging B A; O-hook B; Con¯ict : INCC proposes ``StopAudibleRinging A B jjj StopRinging B A jjj LogBegin A B C Time'' whereas CELL proposes ``StopAudibl-
eRinging A B jjj StopRinging B A jjj LogBegin A B A Time jjj AirBegin A Time''. · Three were found by the Committee, but not considered as interactions, though the essential requirements of a feature appeared in each case to be violated. For instance, between Call Forwarding Busy Line (CFBL) and Call Waiting (CW), the Committee noticed that a forwarded call would not activate CW at the forwardedto user. However, the Committee doesn't seem to consider this inhibition as an interaction in the contest model (i.e. in the Chisel diagrams). · Five were due to ``over-requirements''. That is, we de®ne a requirement too strongly. This concerns mainly to the TeenLine (TL) feature. Actually, we stated that TL should guarantee that no call is ever charged to its subscriber unless explicit authorization (by dialling the correct PIN). We found it a reasonable implicit consequence of the requirements, though we admit that it may be considered as too strong. The major point in this part of our results is that none of these supplementary interactions can actually be said to be invalid. Most of them come from diverging expectations in the requirements. (b) Regarding the missing 26 interactions, not revealed by Lutess: · 10 would have been found by a more thorough testing. These misses were mainly due to lack of time: once we found an interaction between two features, we often lightened the test eort regarding this pair. · 11 are another symptom of an interaction already revealed. We found it not necessary to list all the symptoms of a single interaction. For instance, the Committee listed two interactions between CW and Three Way Calling (TWC) occurring in very similar conditions. The only dierence between them is that, in the ®rst case, the interaction appears when the user goes on the hook, in the second, when the user ¯ashes. To us, these two problems revealed a single con¯ict. This is due to our decision to consider that several interactions may be the symptoms of one single problem. Once the problem spotted, the features should be re-engineered, in order to solve it. As a side-eect, all interactions able to reveal
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
the problem disappear. From this point of view, it is not necessary to reveal twice a single problem. We reported problems more than symptoms. · Four of them would have required another requirement than those that we set. This happened between TWC and CW. All the CW properties that we stated involve a ¯ash event. Since some interactions occurred without any ¯ash performed, we missed them. It would have been very easy to ®nd them with a straightforward property stating that ``an incoming call to a busy CW subscriber should be put on hold''. · One seems to us not to exist according to the contest description. This interaction is described as involving INCC and TWC: when a TWC subscriber invokes INCC to call another user, the Committee considers that TWC should react. Attentive reading of the speci®cation did not allow us to agree on that point. A B
TWC,INCC
Caller Callee
Idle Idle
Scenario: O-hook A; DialTone A; Dial A 0+B; Con¯ict: INCC gives Announce A EnterPhoneNumber. TWC cannot be invoked at this point: the feature requires its user to be talking and to ¯ash. 8. Conclusions 8.1. Test automation From the tester's perspective, our tool allows a signi®cant relief by automating the test. The human eort can then be shifted toward more useful tasks, such as analyzing the results. From the speci®er's point of view, Lutess was shown to be very helpful in debuging speci®cations. First, Lutess has been used to validate the oracles: the oracle speci®cations are put in place of the system under test and a human observation is substituted for the Lutess oracle. Second, prior to the search for interactions, the service speci®cations to be tested have been validated using oracle properties. For instance, in the speci®cations, some possible transitions were missing in a diagram, or an expected output event was never sent
429
in a given situation. These problems were automatically exhibited as oracle violations. 8.2. Synchronous framework adequacy According to our experience, the synchronous approach seems to be well adapted to model telecommunication features. All the notions introduced by the contest have been successfully described in our approach. The simplifying assumptions allowed to easily model the whole system in a synchronous style, as described in Section 3.1. Synchrony also led to concise modeling. The composition of events, as described in the contest instructions, is simpli®ed: instead of having to take into account all the possible sequences of events allowed by this composition, we simply consider all composed events to be simultaneous. Using an executable model was also highly bene®cial to faithfully describe some complex features, e.g., involving loops. 8.3. Test-based validation A test-based approach appears to be more suitable than veri®cation-based methods. Indeed, detecting interaction is equivalent to looking for errors, which is exactly the goal of testing. On the contrary, veri®cation techniques aim at proving the correctness of a piece of software. Even though testing provides less con®dence and less de®nitive results, it is more adapted to this kind of problems. However, such an approach has several weak points. When to stop testing? One of the major problems we had during this experiment was to decide when the test should be stopped. Indeed, testing does not provide a de®nitive verdict on the absence of interaction. In fact, stopping a test run too early was the major reason that prevented us from detecting some interactions. Thus, to evaluate how signi®cant various test sequences were, and to increase con®dence in testing, we have worked along two directions: · since interactions occur mostly during, or just after, feature invocation, we designed some spe-
430
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
ci®c oracles that count how often a feature is invoked. · we also used a model-checker to compare the abilities of various validation methods to detect feature interactions. Experimentation showed that model-checking is often not applicable due to lack of time or memory [7]. Expressing the ``good'' properties. Since the whole detection process is based on the properties describing the requirements, one may ask to what extent are the results dependent on them. To our experience, an interaction shows itself through various signs. Therefore, there are many ways to reveal one speci®c problem and the stated properties just need to uncover one of these signs. So, building the property from the requirements is not the critical part, since several properties can unveil dierent symptoms of a same problem. What is essential is to de®ne properly the good requirements of a feature. If we miss a requirement, chances are, we miss as well some interactions. However, we argue that de®ning requirements can be done quite intuitively and does not demand an expert.
test run. This leads to quicker results when the test harness construction is more expensive than the data generation itself, which was true for the contest. On the other hand, since this method relies on the features' speci®c properties, we had to carefully de®ne them in order to detect all interactions. 8.5. General conclusion Globally, the fact that our approach is based on confronting a model to high-level requirements has proved to be highly pro®table. Indeed, the detection process can be carried out while abstracting from some details of the model; this was particularly adapted to the contest problem because several aspects were left undetailed in the instructions. Consequently, the success of the detection process depends strongly on the stated properties: one has to cautiously analyze the speci®cation in order to extract the adequate properties and to express them in a correct manner.
8.4. Impact of the feature composition operation Since the way in which to compose features was not explicitly stated in the contest instructions, we had to de®ne our own (see Section 3.5). We also examined another way to compose features: when the features propose incompatible answers, the result is an inconsistent event, that violates the integrity constraints (i.e., the properties not speci®c to one feature, see last paragraph of Section 3.3). Meanwhile, feature inhibition (a feature is inhibited when its reaction is not taken into account because of its lower priority) was still possible, and it was still necessary to check the feature properties' validity. Both methods appear to have the same power of uncovering interactions. We chose to use the ®rst one, so as to avoid inconsistent situations. If such a situation occurs when using the second method, it is usually useless to continue the test run, since data are meaningless. On the contrary, the ®rst method allows to keep on testing and to ®nd more interactions, or other symptoms of the same interaction, during one single
Acknowledgements We would like to thank Remy Cave and Jerome Vassy, the two undergraduate students who assisted us in our participation in the contest.
References [1] I. Aggoun, P. Combes, Observers in the SCE and the SEE to detect and resolve services interactions, in: Feature Interactions in Telecommunications Systems IV, IOS Press, Amsterdam, 1997. [2] P.K. Au, J.M. Atlee, Evaluation of a state-based model of feature interactions, in: Feature Interactions in Telecommunications Systems IV, IOS Press, Amsterdam, 1997. [3] A. Benveniste, G. Berry, The synchronous approach to reactive and real-time systems, Proceedings of the IEEE 79 (9) (1991) 1270±1282. [4] J. Blom, R. Bol, L. Kempe, Automatic detection of feature interactions in temporal logic, in: K.E. Cheng, T. Ohta (Eds.), Feature Interactions in Telecommunications Systems III, IOS Press, Amsterdam, 1995, pp. 1±20. [5] P. Caspi, N. Halbwachs, D. Pilaud, J. Plaice, LUSTRE, a declarative language for programming synchronous sys-
L. du Bousquet et al. / Computer Networks 32 (2000) 419±431
[6]
[7] [8]
[9]
[10] [11]
[12]
[13]
[14]
[15]
[16] [17] [18] [19]
[20]
tems, in: 14th Symposium on Principles of Programming Languages (POPL 87), Munich, ACM, 1987, pp. 178±188. P. Combes, S. Pickin, Formalization of a user view of network and services for feature interaction detection, in: Feature Interactions in Telecommunications Systems, IOS Press, Amsterdam, 1994, pp. 120±135. L. du Bousquet, Feature interaction detection using testing and model-checking, experience report, in: Formal Method, Toulouse, France, September 1999. L. du Bousquet, F. Ouabdesselam, J.-L. Richier, Expressing and implementing operational pro®les for reactive software validation, in: Ninth International Symposium on Software Reliability Engineering, Paderborn, Germany, 1998. L. du Bousquet, F. Ouabdesselam, J.-L. Richier, N. Zuanon, Lutess: a speci®cation-driven testing environment for synchronous software, in: 21st International Conference on Software Engineering, ACM, May 1999. M. Faci, L. Logrippo, B. Stepien, Structural models for specifying telephone systems, Computer Networks and ISDN Systems 29 (4) (1997) 501±528. J.-C. Godskesen, A formal framework for feature interaction with emphasis on testing, in: K.E. Cheng, T. Ohta (Eds.), Feature Interactions in Telecommunications Systems III, IOS Press, Amsterdam, 1995, pp. 21±30. N. Grieth, R. Blumenthal, J.-C. Gregoire, T. Ohta, Feature interaction detection contest, in: Feature Interactions in Telecommunications Systems V, IOS Press, Amsterdam, 1998, pp. 327±359; also: Comput. Networks 32 (2000) 487±510. L.J. Jagadeesan, A. Porter, C. Puchol, J.C. Ramming, L. Votta, Speci®cation-based testing of reactive software: tools and experiments, in: 19th International Conference on Software Engineering, 1997. K. Kimbler, Towards a more ecient feature interaction analysis ± a statistical approach, in: K.E. Cheng, T. Ohta (Eds.), Feature Interactions in Telecommunications Systems III, IOS Press, Amsterdam, 1995, pp. 201±211. F.J. Lin, Y.-J. Lin, A building block approach to detecting and resolving feature interactions, in: Feature Interactions in Telecommunications Systems, IOS Press, Amsterdam, 1994, pp. 86±119. G. Murakami, R. Sethi, Terminal call processing in Esterel, in: Proceedings of IFIP 92 World Computer Congress, Madrid, Spain, 1992. J. Musa, Operational pro®les in software-reliability engineering, IEEE Software (1993) 14±32. F. Ouabdesselam, I. Parissis, Testing synchronous critical software, in: Fifth International Symposium on Software Reliability Engineering, Monterey, USA, 1994. D. Pilaud, N. Halbwachs, From a synchronous declarative language to a temporal logic dealing with multiform time, in: Symposium on Formal Techniques in Real Time and Fault Tolerant Systems, Warwick, Springer, Berlin, 1988. J. Whittaker, Markov chain techniques for software testing and reliability analysis, Ph.D. Thesis, University of Tenessee, 1992.
431
Lydie du Bousquet was awarded a Ph.D. in Computer Science from Joseph Fourier University, Grenoble, France, in 1999. She received a ``Magistere d'informatique'' and a ``Dipl^ ome d'etudes approfondies'' from Claude Bernard University, Lyon, and ``Ecole Normale Superieure de Lyon''. She is currently a postdoctoral fellow at IRISA, Rennes, France. Her research interests focus on validation of safety critical systems. Farid Ouabdesselam is a Professor of Computer Science at Joseph Fourier University, Grenoble, France. He received his ``Docteur-Ingenieur'' degree from ``Institut National Polytechnique de Grenoble'' and was awarded a ``Habilitation a diriger des recherches'' from Joseph Fourier University. Until 1981, he worked with Thomson, Telemecanique Electrique and SEMS, as a system designer in compiler construction and real-time applications. From 1981 through 1985, he held various faculty visiting positions as Assistant and Associate Professor at UC Santa Barbara and Queen's University (Kingston, Canada). He has published in image analysis, program construction and veri®cation, theorem-proving, testing and software engineering. More recently, he has concentrated on the areas of telephony systems and speci®cation-based testing. Jean-Luc Richier is a full-time researcher in Computer Science with the french ``Centre National de la Recherche Scienti®que''. He graduated from ``Ecole Normale Superieure'', Paris, and was awarded a Ph.D. from University of Paris 6. Until 1983, he was a member of the LITP laboratory, Paris. In 1984, he joined the IMAG Institute, Grenoble. He published in automata theory, model-checking, protocol veri®cation and Internet protocols. He developed the Xesar model-checker for protocol veri®cation. His current research interests include validation of distributed systems using formal methods, services in telephony systems and new generation Internet protocols (IPv6). Nicolas Zuanon is a 3rd year Ph.D. student in Computer Science at Joseph Fourier University, Grenoble, France. He graduated in Computer Science from ``Ecole Nationale Superieure d'Informatique et Mathematiques Appliquees de Grenoble''. His research interests include speci®cation-based testing, applied to the speci®cation and validation of telephone services. His Ph.D. work is partially supported by a contract between France-Telecom and Joseph Fourier University.