Feature Interaction Detection using a Synchronous Approach and Testing ? L. du Bousquet, F. Ouabdesselam, J.-L. Richier, N. Zuanon LSR-IMAG,BP 72, 38402 Saint Martin d'Heres cedex, France
Abstract We present a synchronous framework for 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 its user to drive 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 were detected.
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 e ort has been devoted to this 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 ?
This work has been partially supported by a contract between CNET-France Telecom and University Joseph Fourier, #957B043. E-mail addresses: fldubousq,ouabdess,richier,
[email protected] Preprint submitted to Elsevier Preprint
5 January 2000
S requires 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 automated test data generation and automated verdict production. However, identifying interactions has to be performed manually. 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 evaluates the suitability of a software product to its operational role. (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. The following section 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 has been conducted and how interactions were found. Section 6 mentions related works. Finally, section 7 discusses the results and section 8 provides some conclusions.
2 Background: synchronous approach Reactive programs are applications that continuously interact with their environment: to each input provided by the environment, 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 makes approaches based on parallel and communicating processes intractable. 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. 2
Our work is based on Lustre, a synchronous declarative data- ow language [5]. Lustre o ers 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 [19]. Therefore, temporal logic formulae are easily evaluated on 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 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) ( g.1a). Its environment is composed of the set of telephone devices and the Operations System (OS). The messages exchanged between 3
System specification
OS OS
SCP
SCP
SCP
SCP
LT
LT
LT
Switch
switch
C
A
...
System specification
... B (a)
(b)
Fig. 1. Network model
the reactive system and its environment are the events de ned in the contest instructions (user-to-switch, switch-to-user and switch-to-OS). The inputs issued to the executable speci cation associated with the reactive system are the user-to-switch events, whereas the outputs are the switch-touser 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 ( g.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 it 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, ... 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 produce a simpler speci cation. 4
1
Dialing x Dial x y and Idle y StartRinging y x
Dial x y and Idle y StartAudibleRinging x y
Dial x y and Busy y LineBusyTone x
4 13
4 On-hook x StopAudibleRinging x y Off-hook y StopAudibleRinging x y
On-hook x StopRinging y x
Off-hook y StopRinging y x LogBegin x y y Time
16 16
6 On-hook y LogEnd x y Time
6 On-hook y Disconnect x y
On-hook x Disconnect y x LogEnd x y Time
11
8
On-hook x
On-hook y
0
On-hook x
Input events Output events
0 IN-FB for caller (x)
IN-FB for callee (subscriber y)
Fig. 2. The two automata for INFB
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, so as to identify the di erent 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 a ect 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 gure 2. 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 1
Strictly speaking, POTS is not a feature; the construction of its Lustre model is however similar in many respects to the features' one. 2 For sake of simplicity, the gure abstracts the \intelligent" part (i.e. involving the SCP) of the feature.
5
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 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 8 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 6
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 . 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 LTi. 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. 7
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 B . It from the integration of a feature F = (B; P ) into POTS is denoted by POTS consists of building F 's 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 = :::B . (B1 ::: Bn ; P1 ^ ::: ^ Pn ) into the POTS is denoted by B1POTS n
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. 8
The method we use for detecting interaction is based on the well-known satisfaction-on-a-model approach (symbolized by a satisfaction relation j=). 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: 8 >< B j= Pi; 1 i n V1 POTS >: B1:::B 2 P1 ^ : : : ^ Pn V2 POTS i
n
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 requires analyzing B B B B both POTS and POTS . i
j
j
i
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 (), a system under test () and an oracle ( ) describing the system requirements ( g. 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 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 pro9
Environment ∆ description
dynamically produced input data
input data generator
Test harness
system under test
Σ
program output
oracle
verdict
Ω
Communication link
trace collector
Object provided by the user
Fig. 3. Lutess
grams, 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 mode (de ned by the user). This makes the manual trace analysis easier than the analysis of sequences of boolean vectors. The analyzer allows the user to replay a test sequence with di erent oracles. The Lutess generator selection algorithm chooses a valid input vector, i.e. a vector which is in compliance with the environment description. The selection is done so that, in each environment state, any valid input vector has the same probability to be selected. However, this method is not ecent 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 o ers 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 10
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 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 4 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 di erent Lustre modules. We built 78 di erent 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 modelingrelated constraints and guides. For instance, a user cannot go o the hook twice in a row without going on the hook in between and vice-versa. This alternation can be expressed as follows, i being any user: (Once On-hook i from O -hook i to O -hook i) and 11
(Once O -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 (B )i Finally, 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: O -hook A [not On-hook A] Dial A B and IdleB [not On-hook A] O -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, 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 12
Test con guration: B is a TCS and CND subscriber. C is on B's screening list.
Step Input A's output 32 On C NoST 33 O C NoST 34 Dial C B NoST
B's o. C's o. NoST NoST NoST DT C NoST Ann C Scr
D's o. Displ. Partys state NoST - - - - - - - - Id Id Id Di NoST - - - - - - - - Id Id Di Di NoST - C - - - - - - Id Id Ex Di
O T T
F
Fig. 4. Relevant trace excerpt (scenario) for the test of TCS+CND
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 sub-sequence 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). Figure 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.
6 Related work The core of our approach consists in reducing feature interaction detection to evaluating a temporal 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 di ers 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 [16,13]. Indeed, such systems have many 13
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) [4,2]. 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 [15,6,10]. 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 7.1 Test e ort
The whole case study required almost 140 sta -days e ort:
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 5,000 lines in Lustre code. The validation phase was made of over 1,500 runs of Lutess, each pair of features being tested around 20 times with test sequences of length 5,000 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 minutes. 14
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 CELL,INCC Caller Idle B Callee 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 \StopAudibleRinging 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 forwarded-to 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 applies 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. 15
b) Regarding the missing 26 interactions, not revealed by Lutess: Ten would have been found by 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 e ort regarding this pair.
Eleven are another symptom of an interaction that we found. We found it
unnecessary 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 di erence 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 observation that several interactions may be the symptoms of one single problem. Once the problem has been spotted, the features should be re-engineered. As a side-e ect, all interactions revealing the problem disappear. From this point of view, it is not necessary to report a single problem twice. We reported problems more than symptoms.
Four of them would however have required another requirement than those
that we set. This happened between TWC and CW. All the CW properties 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 TWC,INCC B
Caller Idle Callee Idle
Scenario: O -hook A; DialTone A; Dial A 0+B; Con ict: INCC gives Announce A EnterPhoneNumber. TWC can't be invoked at this point: the feature requires its user to be talking and to ash.
8 Conclusions Test automation
From the tester's perspective, our tool allows a signi cant relief by automating the test. The human e ort can then be shifted toward more useful tasks, such as analyzing the results. 16
From the speci er's point of view, Lutess has proved to be very helpful in debugging 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 in a given situation. These problems were automatically exhibited as oracle violations.
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 3.1. Synchrony also led to concise modeling. The composition of events, as described in the contest instruction, 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.
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 problem. 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 detection of some interactions. Thus, to evaluate how signi cant were various test sequences, 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 speci 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 modelchecking is often not applicable due to lack of time or memory [7]. 17
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 di erent 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.
Impact of the feature composition operation
Since the way to compose features was not explicitly stated in the contest instructions, we had to de ne our own composition method (see 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 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 permits continued testing and nding more interactions, or other symptoms of the same interaction, during one single test run. This leads to quicker results. This is important 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.
General conclusion
Globally, the fact that our approach is based on evaluating a model using highlevel 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 analyze the speci cation carefully in order to extract the appropriate properties and to express them correctly. 18
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 and P. Combes. Observers in the SCE and the SEE to detect and resolve services interactions. In Feature Interactions in Telecommunications Systems IV. IOS Press, 1997. [2] P.K. Au and J.M. Atlee. Evaluation of a state-based model of feature interactions. In Feature Interactions in Telecommunications Systems IV. IOS Press, 1997. [3] A. Benveniste and G. Berry. The Synchronous Approach to Reactive and RealTime Systems. Proceedings of the IEEE, 79(9):1270{1282, 1991. [4] J. Blom, R. Bol, and L. Kempe. Automatic detection of feature interactions in temporal logic. In K.E. Cheng and T. Ohta, editors, Feature Interactions in Telecommunications Systems III, pages 1{20. IOS Press, 1995. [5] P. Caspi, N. Halbwachs, D. Pilaud, and J. Plaice. LUSTRE, a declarative language for programming synchronous systems. In 14th Symposium on Principles of Programming Languages (POPL 87), Munich, pages 178{188. ACM Press, 1987. [6] P. Combes and S. Pickin. Formalization of a user view of network and services for feature interaction detection. In Feature Interactions in Telecommunications Systems, pages 120{135. IOS Press, 1994. [7] L. du Bousquet. Feature interaction detection using testing and model-checking, experience report. In World Congress on Formal Methods, Toulouse, France, September 1999. [8] L. du Bousquet, F. Ouabdesselam, and J.-L. Richier. Expressing and implementing operational pro les for reactive software validation. In 9th International Symposium on Software Reliability Engineering, Paderborn, Germany, 1998. [9] L. du Bousquet, F. Ouabdesselam, J.-L. Richier, and N. Zuanon. Lutess: a speci cation-driven testing environment for synchronous software. In 21st International Conference on Software Engineering, pages 267{276. ACM Press, May 1999. [10] M. Faci, L. Logrippo, and B. Stepien. Structural models for specifying telephone systems. Computer Networks and ISDN Systems, 29(4):501{528, 1997.
19
[11] J.-C. Godskesen. A formal framework for feature interaction with emphasis on testing. In K.E. Cheng and T. Ohta, editors, Feature Interactions in Telecommunications Systems III, pages 21{30. IOS Press, 1995. [12] N. Gri eth, R. Blumenthal, J.-C. Gregoire, and T. Ohta. Feature interaction detection contest. In Feature Interactions in Telecommunications Systems V, pages 327{359. IOS Press, 1998. Also in this issue. [13] L.J. Jagadeesan, A. Porter, C. Puchol, J.C. Ramming, and L. Votta. Speci cation-based Testing of Reactive Software: Tools and Experiments. In 19th International Conference on Software Engineering, 1997. [14] K. Kimbler. Towards a more ecient feature interaction analysis - a statistical approach. In K.E. Cheng and T. Ohta, editors, Feature Interactions in Telecommunications Systems III, pages 201{211. IOS Press, 1995. [15] F.J. Lin and Y.-J. Lin. A building block approach to detecting and resolving feature interactions. In Feature Interactions in Telecommunications Systems, pages 86{119. IOS Press, 1994. [16] G. Murakami and R. Sethi. Terminal call processing in Esterel. In Proc. IFIP 92 World Computer Congress, Madrid, Spain, 1992. [17] J. Musa. Operational Pro les in Software-Reliability Engineering. IEEE Software, pages 14{32, march 1993. [18] F. Ouabdesselam and I. Parissis. Testing Synchronous Critical Software. In 5th International Symposium on Software Reliability Engineering, Monterey, USA, 1994. [19] D. Pilaud and 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, 1988. Springer Verlag. [20] J. Whittaker. Markov chain techniques for software testing and reliability analysis. PhD thesis, University of Tenessee, 1992.
20
