Formalisation of Requirements with emphasise on ... - CiteSeerX

Formalisation of Requirements with emphasise on Feature Interaction detection Johan Blom Department of Computer Systems Uppsala University, Sweden [email protected]

1 Introduction In this paper a framework, Tussilago , for the speci cation of telephone services is presented. We particularly address the following problems. 1. Formalisation in a way close to the intuitive understanding of a set of requirements expressible with use cases. Our formalism uses a particular interpretation of Message Sequence Charts (MSC), where the graphical syntax used to visualise MSCs has a close relationship to the speci cation. 2. Structuring formal speci cations of telephone services into modules might be used to increase reusability of speci cations. New modules might also cause addition of new functionality. A non-monotonic construct introduced to combine modules will further increase reusability of speci cations. 3. Automatic detection of a class of interactions between features. We show how a method described in [2] can be directly used on the presented framework. We aim for a speci cation style, in which each feature is speci ed in a separate module. Ideally, a complete telephone service should be obtainable by composing a module containing a basic service with those modules that specify the desired set of features. We assume a system modelled as a set of individuals where the state of the system is de ned by the state of individuals and relations between them. As individuals are distributed in a network, the global state might be seen as the composition of local states of the individuals. The local state of an individual might for example re ect that it is connected with some other individual. Stimuli from the environment are modelled by external events. For example, a user dialling a number is such stimuli to an individual in the system. But the eect of dialling is not isolated to one individual as it triggers a request to connect to another individual, situated somewhere else in the network. The recipient of this request might then answer with a positive or negative reply depending on whether or not it is possible to set up the call between the individuals. The system reacts to incoming events by a state change, which may aect several individuals of the system and depends on the present states of these individuals. Our proposed language intends to give a more structured presentation of state changes as a

combination of smaller steps. For example dialling might be separated into a request and reply step with distinct state changes. At each step an individual receives an event representing certain information, and based on the current state it may in turn update its local state and generate new events to other individuals. Thus we might model dialling with separate events for the request and reply to/from the individual we are dialling to, where each event causes a small step. A sequence of steps triggered by the arrival of an external event are collected to a macro step which de nes the response of the system to this particular event. This way of modelling state changes has the following advantages: - It is consistent with the distributed view of the state. At each step a sequence of steps can thus be visualised as the exchange of internal events between individuals, accompanied by corresponding state changes. Smaller steps can be illustrated by a certain form of MSC. This view of the system is achieved by allowing internal communication to take place via internal events and introducing conventions on arguments to variables. - If several macro-steps are similar, the common parts can be represented by a single set of rules. Thus it makes reuse of previously speci ed rules possible. It also makes the speci cation easier to maintain as we can choose to add or change only aected rules. This mechanism is similar to Statecharts [8, 16], but with a deterministic choice of smaller steps as further elaborated in Section 3. Throughout the paper, we use the speci cation of a simple telephone system (POTS) and a Call Forward feature as an example. In Section 2 the basic language is presented, Section 3 informally explains semantics, formal de nitions are given in Section 4. Section 5 explains connections to MSCs, modules are introduced in Section 6 and Section 7 explains the connections to feature interaction.

2 Syntax and Informal Semantics We assume a given set IDS of individuals which are intended to represent objects such as telephones or subscribers and are denoted by a ; b ; c ; possibly with a subscript.

Variables Three sets of variables are assumed.  The set of individual variables, Vids , ranged over by id and a possible subscript.  The set of state variables, Vs , where each state variable has a nonnegative arity

and represents relations between individuals or the state of individuals. We may for example represent that two telephones a and b are connected with each other by connected (a ; b ) or the fact that user a has picked up the receiver by active (a ).  The set of event variables, Ve , where each event variable has a nonnegative arity and represents stimulus. If e 2 Ve and a : : : am 2 IDS then e (a ; : : : ; am ) represent an event. For example the action taken by a user a when dialling a number to another user b might be represented by the event Dialling (a ; b ). 1

1

Our intention is to interpret the rst argument of a state variable as identifying identi es the location of the property (i.e. trying (a ; b ) should be read as \a knows that a is trying to get a connection to b" or \at a the value of trying is b " ), to separate concerns between dierent individuals. Thus we can de ne the local state of an individual by using the rst argument to a state variable as the location of an instance of the variable. Event variables can be further subdivided into two disjoint sets, internal and external event variables. External event variables represent externally generated stimuli, such as Dialling . Internal event variables represent stimuli generated when a rule is triggered by another (external or internal) event. The introductory example might be modelled using an internal event, Request (a ; b ), i.e. \a request is sent from a to b ", which is triggered by Dialling (a ; b ), i.e. \a dials b ", and denotes the fact that setup information is transfered from a to b .

Atomic Formulas An atomic formula is either an atomic state formula or atomic

event formula.  Atomic state formulas are state variables applied to individual variables. If v 2 Vs has arity m and id ; : : : ; idm 2 Vids then v (id ; : : : ; idm ) is an atomic state formula.  Atomic event formulas are event variables applied to individual variables. If e 2 Ve has arity n and id ; : : : ; idm 2 Vids then e (id ; : : : ; idm ) is an atomic event formula. The set of atomic event formulas are further divided into internal and external event formulas depending on the event variable e . 1

1

1

1

Preconditions The set Cpre of preconditions is de ned inductively as the least set

satisfying: 1. If h is an atomic state formula then h 2 Cpre . 2. If v (id ; : : : ; idm ) is an atomic state formula then 9 idk : v (id ; : : : ; idk ; : : : ; idm ) 2 Cpre where 1  k  n . 3. If c ; c 2 Cpre then c _ c ; c ^ c ; : c 2 Cpre In a speci cation, preconditions are completely distinguished from event formulas. 1

1

1

2

1

2

1

2

1

Postconditions The set Cpost of postconditions is de ned inductively, if id 2 Vids , 1

as the set of conjunctions of sub-formulas of the form: 1. v (id ) = True or v (id ) = False if v 2 Vs has arity one. 2. v (id ) = setexpr (v ; id ) and v 2 Vs has arity m > 1, where setexpr (v ; id ) is a set expression over v and id . Set expressions are further de ned inductively as - v (id ) is a set expression over v and id , - if setexpr (v ; id ) is a set expression over v and id then v (id )[fhid ; : : : ; idm ig is a set expression over v and id . - if setexpr (v ; id ) is a set expression over v and id then v (id )nfhid ; : : : ; idm ig is a set expression over v and id . 1

1

+

1

+

+

1

1

1

1

1

1

1

1

2

1

1

2

1

1

1

3. v = v ? Bk fhid ; : : : ; idk ? ; idk ; : : : ; idm ig if v 2 Vs and has arity m > 1 A postcondition states the value of state variables in the next state. For this purpose the operator is introduced such that for a state variable v , the value of v in the next state is denoted v . In particular the value at the location id in the next state is denoted v (id ) . We here use an alternative notation for state variables, similar to for example Z, [14] where state variables may be treated both as sets and predicates. If v is binary we use v (id ) to denote the set fid 0 j v (id ; id 0)g. In other words, v (id ) can be thought of as the part of v which is local to id . This generalises straight-forwardly to state variables with higher arity. For example, we express the addition of the set fb g at the individual a for a state variable v as v (a ) = v (a ) [ fb g. The notation W ? Bk S is a generalisation of domain/range restriction also found in Z where k is the k :th argument in W that matches any individual, all other arguments must be equal to those in S . Thus for example connected ? B fid g removes all tuples of 0 form hid ; id i from connected , i.e. id will not be connected to any other individual. +

1

1

+1

+

+

1

1

+

+

2

Reactive rules A reactive rule is of the form: e ^ c =ids) c ^ ei where c 2 Cpre , c 2 Cpost and e; ei are conjunctions of atomic event formulas. The sub-formula e ^ c is also referred to as the condition and c ^ ei as the eect of the 1

1

2

2

1

2

rule. The set ids is used to represent existentially quanti ed individual variables over a rule. An individual variable is free in a rule if it does not occur in ids or as parameter to a triggering event formula. Intuitively, a reactive rule states the eect when an instance of the conditional formula is true. For example, an instance of a reactive rule for hanging up Onhook (id1 ) ^ dialtone (id1 ) =) dialtone (id1 )+ = False

where the state formula dialtone (id ) means that id can hear a dial tone and dial a number is Onhook (a ) ^ dialtone (a ) =) dialtone (a ) = False if a 2 IDS . An instance of a formula is obtained by instantiating all individual variables not free. In an instance of a reactive rule, the instantiations of e; ei are referred to as sets of events, c as a precondition instance and c as a postcondition instance. Sometimes the precondition contains an existentially quanti ed variable that we want to refer to in the eect. We solve this problem by allowing the condition to declare the individuals ids , to which the eect part can refer. Formally, 1

1

+

1

e ^ c1 =ids) c2 ^ ei

2

=b (9 ids : e ^ c ) =) (9 ids : c ^ c ^ ei ): 1

1

2

Note that when ids is the empty set, both the notation and its semantics reduce to ordinary implication. With variables that do not occur in the event formula, and are not bound by an existential quanti er inside the rule, a broadcast might be simulated.

Example 1 Consider a rule in a Conference Call feature where all other users, currently

connected, need to be informed when one of them hangs up. This could be modelled

by a broadcast of a Release (a ; b ) event to all individuals b that a is connected to, as given by the precondition inconference (a ; b ), on the occurrence of the event Onhook (a ). Thus we have a rule Onhook (id ) ^ inconference (id ; id2 ) =) Release (id ; id2) :

It is important to distinguish this reactive rule from the very similar one which only will send the event to one user, non-deterministically chosen 2 Release (id ; id ) : Onhook (id ) ^ inconference (id ; id2 ) =id) 2

3 Semantics and System behaviour The system state is maintained by the state variables and is changed by the occurrence of external events. We assume interleaving of external events such that we do not need to consider the simultaneous occurrence of two or more external events. In a real system , it is of course possible that two external events occur at exactly the same time. Such a race condition can be handled by nondeterministically choosing one of the events and treat the other immediately after the treatment of the rst. According to the synchrony hypothesis (as in e.g. [1]) the system is assumed to be fast enough to complete its reaction to one external event before the arrival of the following one. Another possibility is to assume an input \queue" (as in SDL [6]) where external events are buered awaiting treatment. The complete system reaction to an external event is composed of the eect caused by the external event and the eects of the internal events triggered as a result of the external event. micro ? steps e1

(s

1;

e1 )

i5 s1 ; fi1 g)

i1

s1 ; fi2 g)

(

s1 ; fi5 g)

i3

i2

(

(

s1 ; fi3 ; i4 g)

(

i4

s1 ; fi6 g)

(

(s

2;

e2 )

i6

v1 (a )+ = setexpr0 (v1 ; a ) v1 (c )+ = setexpr2 (v1 ; c ) v3 (a )+ = True v2 (b )+ = setexpr1 (v2 ; b ) v2 (b )+ = setexpr4 (v2 ; b )

macro ? step

Figure 1: A macro-step, triggered by an external event e1 , is built from a set of microsteps caused by internal events i1 : : : i6, each generating postconditions that are collected in the next state s2. The principle is illustrated in Figure 1 where an external event e occurs at the system state s . Each time e occurs a similar graph can be drawn by considering the reactive rules for generating new internal events. Following the terminology used in for example Statecharts [8], we will use the term Micro-step to refer to a set of rules with true events and true instances of conditional formulas that will occur simultaneously and which might generate new internal events. 1

1

1

In addition, each micro-step generates postconditions which are \collected" at the bottom of Figure 1. We use the term Macro-step for the complete set of micro-steps which is the result of the chain reaction initiated by an external event. In the gure (s ; e ) enables a reactive rule that generates a postcondition, v (a ) = setexpr (v ; a ), and an internal event i , this event further generates v (b ) = setexpr (v ; b ) and i , that in turn generates more internal events and postconditions. Unlike e.g. Statecharts the micro-steps are not carried out in a sequence. Instead, the postconditions of the micro-step are \recorded" and collected to a larger postcondition of the entire macro-step. When the macro-step is completed, the collected postconditions are carried out as one atomic action. In Figure 1 this means that we have an aggregated postcondition that aects v ; v and v . The eect of this postcondition is embodied in the next state s where the next external event e occurs. The combined eects of a macro-step must be consistent. For our language, this informally means that a state variable, at each location, can not be added and eliminated with the same tuple during a single macro-step and only updated with a single postcondition. Thus in Figure 1 setexpr (v ; b ) and setexpr (v ; b ) need to be equal. In the case where a set of tuples are eliminated from W with W ? Bk S and k = 1 this means that W cannot be updated by any other postcondition in the macro-step. 1

+

2

1

2

1

+

1

0

1

1

1

2

2

3

2

2

1

2

4

2

Example 2 The following rules constitute the macro-step for dialling a number, notify

the called party and get status information in return. A chain of micro-steps is triggered by Dialling (id ; id ), which generates an internal event Request (id ; id ) to request the establishment of a connection. Depending on the current state of the called party it answers with either a Refuse (id ; id ) if the user is busy and cannot set up a connection, or Ringing (id ; id ) to notify that the phone is ringing. 1 0 active (id ) CC B B ^ dialtone (id ) C B ^ : 9 ide : trying (id ; ide ) C Dialling (id ; id ) ^ B CC =) Request (id ; id ) B B @ ^ : 9 ide : connected (id ; ide ) A ^ : 9 ide : connected (ide ; id ) 2

2

2

2

2

2

Request (id ; id2) ^ active (id2 ) Request (id ; id2) ^ 9 ide : trying (ide ; id2 ) ! : active ( id 2) Request (id ; id2) ^ ^ : 9 id : trying (id ; id ) e e 2

=) Refuse (id ; id ) =) Refuse (id ; id ) =) Ringing (id ; id ) ! ! busytone ( id ) = True active ( id ) Refuse (id ; id ) ^ ^ dialtone (id ) =) ^ dialtone (id ) = False ! ! active ( id ) trying ( id ) = trying ( id ) [ f id g Ringing (id ; id ) ^ ^ dialtone (id ) =) ^ dialtone (id ) = False 2

2

2

+

2

+

+

2

+

2

4 Formal De nitions The formal model used is based upon a sequence of states which is also used for the semantics of Linear-time Temporal Logic. The formal semantics for the speci cation style is de ned by providing the formal de nition for changes occuring within a state change as a reaction to external stimulus.

State The state of the system is an evaluation of all state variables in Vs to values, where each n -ary v 2 Vs is mapped to an n -ary relation over IDS . System con guration Is a tuple (s ; ) where s is the current state of the system and  the current set of events observed.

Macro steps Is a tuple (e ; ; SE ) where e is an external event,  a set of internal events triggered by e and SE a set of postconditions generated. A behavior is an in nite sequence of macro-steps.

De nition: We de ne the satisfaction of a precondition instance c by a state s , denoted s j= c , as follows. 1. s j= True , s 6j= False 2. s j= v (a ; : : : ; an ) i ha ; : : : ; an i 2 s (v ) 3. s j= 9 idk : v (a ; : : : ; idk ; : : : ; an ) 2 Cpre i there exists ak such that ha ; : : : ; ak ; : : : ; an i 2 s (v ) 4. s j= c _ c i s j= c or s j= c 5. s j= c ^ c i s j= c and s j= c 6. s j= : c i s 6j= c 1

1

1

1

1

2

1

1

2

1

1

2

2

1

The following De nition de nes the conditions under which a macro-step can occur in a given system con guration.

De nition: A macro-step, MS = (e ; ; SE ), can occur in a system con guration 0

SC = (s ; e0 ) if  and SE are minimal sets such that whenever there is an instance of a reactive rule e ^ c =ids) c1 ^ : : : ^ cn ^ e1 ^ : : : ^ em

such that there are values for individuals in ids such that - e 2  is an external event and e = e or 8 e 2 e ! e 2  and - s j= c where c is a conditional formula then we can choose values for the individuals in ids such that we have c ; : : : ; cn 2 SE and e ; : : : ; em 2 , where c ; : : : ; cn , e ; : : : ; em are obtained by the chosen instantiation of ids . 0

0

1

1

1

1

De nition: The eect of a macro-step, MS = (e ; ; SE ), is consistent i for each pair of postcondition instances y = w ; y = w 2 SE it is the case that + 1

1

+ 2

0

2

if y = y then also w = w . In other words two dierent updates can not be made to the same state variable at the same location during a single macro-step. 1

2

1

2

5 Expressing Use Cases with MSCs in Tussilago In the preceding sections, we have de ned a language for specifying services, which is based on rules that de ne the allowed transitions of a telephone system. In practice, many designers of telephone services nd textual rule-based notations unintuitive. Instead graphical notations such as SDL and Message Sequence Charts (MSC) are used widely in practice. MSCs also have an advantage in being a way to represent use cases, a commonly used technique for creating a structured model of a system given a set of informal requirements (see e.g. [11, 13]). From use cases we may extract basic use cases and by translating each basic use case to a macro-step the complete speci cation might be created in a systematic way. In the left part of Figure 2 two such use cases from POTS are separated into basic use cases. The idea of using composite use cases as a method to extract more basic use cases is further elaborated in e.g. [9]. In order to provide a more intuitive means for formulating speci cations, we will in this section present an alternative graphical syntax for reactive rules which is close to the standardised MSC notation [10]. id id 1

2

Init

Init

Ohook Dialling (id2)

1a

Request Ringing

1a

Connect

Ohook (id1 )

2a

id1

2b

Dialling (id1 ; id2 )

Dialling (id1 ; id2 )

3

1b

1b

Init

1a

Request Refuse

Onhook (id1 )

Ohook (id2 )

Ohook

id2

Init

Ohook Dialling (id2)

2a

2b

Onhook

3

Figure 2: Use cases that shows the relation between when rules are triggered. In its most basic form, an MSC contains a set of vertical lines, each of which represents a certain individual. Between these vertical lines, arrows are drawn to represent the exchange of messages. The vertical dimension is used to represent causality and order between messages. We will represent reactive rules as Basic MSCs in the following way. Each individual variable in a rule will correspond to a vertical line in a corresponding MSC. Events in a rule correspond to messages which are drawn as arrows from the environment or between the vertical lines. As discussed previously, each reactive rule is \executed" at a certain individual. We use the convention that events which trigger rules at individual id are drawn as incoming arcs to the line of individual id . In this way, an event which is generated at id and triggers a rule at id is drawn as an arrow from id to id . We will label arrows with events, and, when possible, omit their parameters. The 1

1

1

2

1

2

convention is that an arrow labelled e from id to id represents the internal event e (id ; id ). Similarly, an arrow incoming to id labelled e represents the external event e (id ). Beyond these parameters, events can be assigned extra parameters explicitly. An example is the event Dialling (id ) which, when arriving at id represents the event Dialling (id ; id ). Pre- and post-conditions to rules triggered are shown as conditions before and after events respectively. In many cases, our interest in using MSCs is merely to illustrate the possible combinations of events in a system. In this case, we may choose to omit the pre- and postconditions from the MSC, and only draw the events in each macro-step. In the right part of Figure 2, macro-steps are separated by a dotted box and labelled as the corresponding basic use case. 1

1

2

2

1

1

2

1

1

2

6 Speci cation Modules In general, when constructing a large speci cation, a major problem is to structure the speci cation in a suitable way, similarly to creating large programs. Because the systems considered here typically consist of a number of dierent features, we would like to support a style where each feature is speci ed individually in a separate module. Each module should be able to introduce new events and new components of the state and thus make it possible to focus only on the important details of the feature de ned in the current module. The entire speci cation should be obtainable by composing these modules in a simple way. Structuring the speci cation in this way also makes it possible to reuse previously de ned modules. We introduce a non-monotonic construct which enables reuse of modules that \almost t" the needs of a current speci cation. A further advantage by dividing a large speci cation into several modules is that the readability and overview of the complete speci cation is improved. It is important to note that as all variables and events are global, descriptions of the currently used vocabulary and connected informal requirements must be kept visible simultaneously with the formal speci cation. Thus we need methods and tools that systematically produce and handle large amounts of informal requirements; a suggested such method is described further in [4].

Example 3 The speci cation of a Call Forward feature in Figure 3 allows a user to have

incoming calls forwarded to a dierent phone. This speci cation reuses the speci cation of POTS and all rules and variables given there. This simple version of the feature does not prevent cycles of consecutive redirects; in order to avoid this further preconditions would need to be added. Below, dierent constructs available for speci cations of modules are further elaborated.

Imported modules A list of previously de ned modules might be imported. In this way parts of a previous speci cation can be reused. When a module is imported with an import statement, all its de nitions are left unchanged. In the example above a previously de ned module POTS is imported. Declarations Variables introduced in the current module must be declared. In the

example in Figure 3 a new variable forward keeps track of who has ordered a redirection

#import "POTS " #declare forward #observes active ; connected ; trying #transparent speaking (id1) =b 9 ide : connected (id1; ide ) #allowed f ReqCF (id1; id2) W active (id1 ) CancelCF (id1) W active (id1 )

g

ReqCF (id1 id2) ^ : 9 ide : forward (id1 ide ) =) forward (id1 )+ = forward (id1 ) [ fid2 g CancelCF (id1) ^ forward (id1 id2) =id)2 forward (id1 )+ = forward (id1 ) n fid2g ;

;

;

#override f Request (id1 ; id2) =Request (id1; id2 ) ^

;

g

Forward (id1 id2 idorg ) ^ ;

;

Forward (id2 id3 idorg ) ^ ;

;

Forward (id2 id3 idorg ) ^ ;

;

Forward (id2 id3 idorg ) ^ ;

;

!

forward (id2 id3 ) =id)3 Forward (id id id ) 2 3 1 ^ speaking (id2) ;

;

!

forward (id2 id3) =id)3 Forward (id2 id3 idorg ) ^ speaking (id3) : 9 ide : forward (id3 ide ) ! =) Refuse (id3 idorg ) ^ active (id3) : 9 ide : forward (id3 ide ) ! =) Refuse (id3 idorg ) ^9 ide : trying (ide id3) ! : 9 ide : trying (ide id3) =) Ringing (id3 idorg ) ^: active (id ) ;

;

;

;

;

;

;

;

;

;

3

Figure 3: A speci cation of a Call Forward on Busy feature to whom. For example, forward (id ; id ) means that a call to id is redirected to id . Sometimes we would like to refer to variables introduced elsewhere that we just want to observe. In the above speci cation active , connected and trying are declared as such variables from POTS. 2

3

2

3

Transparents We sometimes want to give a name and express informal requirements that can be de ned in terms of state variables. As transparents are abbreviations that behaves as macros they do not extend the state space. In Figure 3 speaking (id ) is de ned as transparent as it can be replaced by 9 ide : connected (id ; ide ). Reactive rules In Figure 3 two reactive rules for new external events are de ned.

The rst, ReqCF (id ; id ), de nes the request of a Call Forward from user id to id . The second, CancelCF (id ), cancels a forward id has made. In a module all individual variables are assumed to be dierent within a reactive rule. Thus there are implicit conditions id 6= id in both above rules. 1

1

2

1

2

2

Allowedness conditions To each external event we associate a distinguished set of

the preconditions, the allowedness condition. It characterises an assumption about the

environment when an external event can happen, in contrast to preconditions in the reactive rules which are conditions on triggering. In Figure 3 the allowedness conditions for ReqCF (id ; id ) and CancelCF (id ) state that the receiver must be lifted. As these are common for all reactive rules associated to a particular external event they are given in a separate table in the module. 1

2

1

Overrides Sometimes we can reuse existing modules by slightly modi ng existing

rules. For example, such a modi cation might be a resolution to a feature interaction. Override, with the syntax #overridefoldpre =newset g, adds the rules in newset to the module and replaces those rules that ful l the precondition oldpre with equivalent rules, except for the addition of negated preconditions of the rules in newset . In Figure 3 all reactive rules from POTS for requesting a connection upon dialling are replaced with the rule ! forward ( id ; id ) id3 =) Forward (id ; id ; id ) Request (id ; id ) ^ ^ speaking (id ) 1

2

2

3

2

2

3

1

if id is speaking with someone and has ordered redirection to id . This way of interpret override corresponds to giving a higher priority to rules in newset than rules that ful l the precondition oldpre . The eect is similar to the resolution method suggested in [3]. An MSC that shows the behaviour of this override is given in Figure 4. It should be emphasized that the use of override should be minimized. id id id id 2

3

2

1

Dialling (id2)

Request Refuse

3

Forward (id1)

4

Forward (id1) Ringing

POTS

POTS+CF

POTS+CF

POTS

Figure 4: Overriding the generation of Refuse (id ; id ) speci ed in the POTS module because id subscribes to a Call Forward feature. 2

1

2

As some state variables in Vs might not occur in the combined eect of a macro-step there is a need for a frame axiom to ensure that the variables not explicitly mentioned in postconditions do not change. The frame axiom for a speci cation can be automatically calculated from reactive rules in Tussilago by examining the collected postconditions for each possible macro-step. A speci cation S = (Init ; Spec ; Frame ) is a tuple consisting of 1. Initial conditions, Init , for all state variables. 2. The complete speci cation, Spec , is built by combining modules with the import statement, thus a Directed Cyclic Graph (DAG) of modules is constructed. 3. Frame constraints, Frame , for all external events given in the modules.

6.1 Non-monotonic issues

In evolving systems such as telecommunication systems there is a certain degree of non-monotonicity present. What follows is a list of issues raised in [15] and discussions on how they relate to the suggested framework. Non-monotonic extensions: Addition of a new feature to an existing telecommunications service sometimes requires modi cations of the original service. Override is used to capture such a way of building a speci cation where new modules are added over a long period of time and the interpretation of events and variables tend to change. The frame problem: Introduction of new variables in modules causes changes of premises for when eects should occur. This is taken care of by the frame axiom and violations thereof cause frame interactions. Property (re)formulation: The validity of properties might change because the \meaning" of events and variables change during time. When adding a new module the interaction formulas checked earlier might not be valid any longer because the interpretation of variables and/or events have changed. The problem on how to interpret a speci cation cannot be solved within a formal framework alone. Thus there is a need for a systematic and careful handling of all assumptions and associated requirements. To some extent this problem is solved for external events because of the de nition of allowedness conditions. We could use something similar for internal events, but state variables are harder to deal with as they express requirements directly.

7 Feature Interaction - Detection and Resolution In order to be able to detect and resolve feature interactions we need to de ne what it is in our framework. We have found four categories of interactions of which the rst three have been further discussed in a previous paper [2]. Below, p is used to denote a list of individuals a : : : an and x a state, i.e. the collected state variables in the speci cation. Allowedness interaction The rst possibility of interaction occurs if two modules disagree about the allowedness of an event. Formally, this can be expressed as 9 p : : (allowed (x ; p ) , allowed (x ; p )) where we have an external event event (p ) in both modules. We say `possibility', because even if there is a state x in which the above formula is true, this state might not be reachable from the initial state. If such an interaction is reachable an agreement needs to be made such that one of the alternatives is chosen, and the other event possibly renamed. Eect interaction A second possibility is that when an event is allowed, the set of postconditions becomes inconsistent. Again we have an external event event (p ) in both speci cations and such states x might exist, but not be reachable. Formally, 9 p ; ids ; ids : cpre1 (x ; p ; ids ) ^ cpre2 (x ; p ; ids ) ^ @x : cpost1 (x ; p ; ids ; x ) ^ cpost2 (x ; p ; ids ; x ): where cpre1 and cpre2 are preconditions and cpost1 ,cpost2 postconditions to a macrostep. To check for eect interaction in a speci cation we need to consider all possible macro-steps after the interpretation of all overrides. If such an interaction is reachable we might use the override construct to resolve the interaction. 1

1

1

2

2

1

2

1

2

Frame interaction Frame interaction occurs between a frame formula of an old spec-

i cation and a reactive rule in the new speci cation if the the new speci cation violates the frame axiom. If such an interaction occurs it is resolved by extending the frame axiom and rules accordingly. Override interaction When a single reactive rule is overridden in two dierent ways we have an override interaction. Such con icting updates of the speci cation might appear if two modules import the same module but want to change it dierently. Interactions of this type can be detected during the interpretation of overrides by keeping track of which reactive rules have been overridden. To resolve, both overrides needs to be examined and one of them chosen. The module with the override not chosen must then be replaced unless the chosen override can be accepted. Possibly there will also be a need for a redesign of several modules. In addition to the above mentioned types of interactions, when adding a new module we might also get new interactions because of the addition or replacement of rules that change the interpretation of events and state variables. These kinds of problems were discussed in Section 6.1. With the current tool support we can automatically generate the necessary eect and allowedness interaction formulas and compile these formulas and the speci cation to a reachability problem expressed in Linear-time Temporal Logic. If we limit ourself to only unary and binary state variables and disallow broadcasts (with one exception) the logic is compilable to a format suitable for a speci cally designed model-checker [12]. Frame interaction formulas are currently not supported. During the compilation the absence of override interaction is also checked.

8 Conclusion and Future Work We have described a modular formal speci cation language Tussilago tailored to support reuse of previously de ned parts of the speci cation, have a close relationship to user requirements expressed with MSCs and after compilation, be suitable for automatic veri cation of properties of the speci cation. Reusability was further supported by a non-monotonic \override" construct that patches old speci cations. We presented a formal model of a distributed telecom system were each user had separated concern. To communicate and transfer data, users send events among each other on a network. But we gave no properties to the network, its only eect was to separate dierent users from each other. In this framework we characterised feature interaction within the system and described how existing tools could perform automatic detection in most cases. Furthermore, we described how resolution of interactions could be applied within the framework. An interaction caused by two features sharing the same event, but giving dierent eects, could be resolved with the non-monotonic construct and thus replace unwanted rules with the resolution. Deciding which way an interaction should be resolved is the speci ers concern, thus override interaction which stems from incompatible resolutions, cannot be resolved without a redesign of the resolution itself. We are currently working with a larger case study with about 20 features that will give a better picture on the applicability of our method. We are also investigating further connections to ongoing work on handling of a large number of requirements within the development of features.

Acknowledgements to Bengt Jonsson and Roland Bol for many fruitful ideas and discussions.

References [1] G. Berry and G. Gonthier. The ESTEREL synchronous programming language: design, semantics, implementation. volume 19, pages 87{152, 1992. [2] J. Blom, R. Bol, and L. Kempe. Automatic detection of feature interactions in temporal logic. In Cheng and Ohta [7], pages 1{19. [3] J. Blom, B. Jonsson, and L. Kempe. Using temporal logic for modular speci cation of telephone services. In Bouma and Velthuijsen [5], pages 197{216. [4] R Bol, J Blom, M Dam, A Ekman, L-a Fredlund, J Jonasson, B Jonsson, and T Grelsson. Requirements Engineering and Formalisation in a Telecommunivation Environment. Technical Report ASTEC-96-2, ASTEC, 1996. Available from http://www.docs.uu.se/docs/ /arena.html. [5] L. G. Bouma and Hugo Velthuijsen, editors. Feature Interactions in Telecommunications Systems, Amsterdam, The Netherlands, May 1994. IOS Press. [6] CCITT, Geneva. CCITT, COM X-R 26, Revised Recommendation Z.100 CCITT Speci cation and Description Language (SDL), May 1992. [7] K. E. Cheng and T. Ohta, editors. Feature Interactions in Telecommunications III, Tokyo, Japan, Oct 1995. IOS Press. [8] D. Harel, A. Pnuelli, J. Schmidt, and R. Sherman. On the formal semantics of statecharts. In Proc. 2nd IEEE Int. Symp. on Logic in Computer Science, pages 54{64, Ithaca, NY, 1987. [9] G.J. Holzmann. Early fault detection tools. LNCS, 1055:1{13, March 1996. (invited paper, reprinted in Software Concepts and Tools, Vol. 17, No. 2, pp. 63-69, 1996). [10] ITU-T. Recommendation Z.120. Message Sequence Chart (MSC), 1994.  [11] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Software Engineering - A Use Case Driven Approach. Addison-Wesley, 1992. ISBN 0-201-54435-0. [12] S. Johansson. Implementation of backward reachability analysis of feature interaction in telecommunication systems. Technical Report DoCS 96/68, Department of Computer Systems, Uppsala University, 1996. Masters thesis. [13] K. Kimbler and D. Sbirk. Use case driven analysis of feature interactions. In Bouma and Velthuijsen [5], pages 167{177. [14] J.M. Spivey. The Z Notation. Prentice-Hall, 1989. [15] H. Velthuijsen. Issues of non-monotonicity in feature-interaction detection. In Cheng and Ohta [7], pages 31{42.

[16] Michael von der Beeck. A comparison of statecharts variants. In H. Langmaack, W.-P. de Roever, and J. Vytopil, editors, Formal Techniques in Real-Time and Fault-Tolerent Systems, volume 863 of Lecture Notes in Computer Science, pages 128{148. Springer Verlag, 1996.