Feature specification: a logic-independent approach

Fundamenta Informaticae XX (2004) 1–31

1

IOS Press

Feature specification: a logic-independent approach Marc Aiguier1 , Christophe Gaston2 and Pascale Le Gall1 1 Université

´ d’Evry, LaMI CNRS UMR 8042, ´ 523 pl. des Terrasses F-91000 Evry

faiguier,legallglami.univ-evry.fr

fax number: (+33) 1 60 87 37 89 2 CEA/DRT/LIST/DTSI/SLA Saclay

F-91191 Gif sur Yvette Cedex

f hristophe.gastonortolan. ea.frg ea.fr

Abstract. In this paper, we investigate the formal specification of features and feature systems in the mathematical paradigm often called “logic-independent”, and formally capture in this paradigm the underlying important notions of feature integration and feature interactions. The complexity of real systems results in the definition of formal means to manage their size. To deal with this issue, we propose a refinement of feature specifications by a more concrete one, which enables one to build his(her) specification in an incremental way. Moreover, we use such a refinement in order to deal with the complexity of feature interaction, which is one of the main problem encountered when dealing with feature interaction detection. The study of interactions through implementation is still n open problem. The present paper furnishes answers to encounter this purpose in a logic-independent framework, using algebraic refinement techniques.

Keywords: feature, feature interaction, logic-independent, institutions, algebraic refinement

this work was partially supported by the RNRT French project VALISERV and by the European Commission under WGs Fireworks (23531)

2

M. Aiguier et al. / Logic-independent feature specifications

1. Introduction 1.1. Motivation Since software have been designed for other application domains than scientific calculus, we have been rapidly confronted with their constant update. In these new applications, update of softwares is not the result of a discovery of “bugs” in associated programs but rather a natural evolution of these programs in order to answer new requirements from users. Hence, softwares were no longer monolithic entities but are both opened and adaptable objects led to incorporate new services (features) not initially foreseen by designers. Although this problem is not new in applied software engineering, it has been considered by researchers of the field of formal specifications, mainly through European and national projects [20, 43], quite recently. Actually, this consideration has been mainly initiated by telecommunication companies which become aware of economical impacts of such update activities. Indeed, in telecommunication systems, services correspond to new capabilities offered to users, and more and more services are offered by them. The primary motivation to offer new services to users seems to be that they differentiate providers, and are significant sources of revenue in their own right. Consequently, a badly designed feature can have calamitous consequences from an economical point of view. Now, this notion of feature is recognized to be not limited to telecommunication systems. Any part or aspect of a specification which has a self-contained functional rôle can be viewed as a feature. The main problem with feature design is that features are seldom designed independently of each other. Consequently, unexpected behaviors can occur. These unexpected behaviors are called interactions. To illustrate the notion of interaction, let us consider the feature call forward when busy (C.F.B.) which consists in allowing any of its users to forward all incoming calls to another specified phone of one’s own choosing. Of course, such a service modifies the basic telephone feature (usually called P.O.T.S. for Plain Old Telephone Service). Indeed, when the user phone is already engaged, P.O.T.S. indicates this fact by a peculiar tone in handset. To leave telecommunication examples, we can also cite the lift case equipped with the basic service which consists in answering users’s requirements by respecting the order of their occurring, and the feature which indicates a priority floor. An expected property of the basic feature is that all requirements will be eventually satisfied. However, the feature of priority floor can question this liveness property (see Section 3.2). It is clear that adding new behaviors in softwares requires first to check the consistency of resulting softwares (i.e. softwares obtained after having integrated these new behaviors). Indeed, these new behaviors can be incompatible with existing features. A consequence of such incompatibilities is the impossibility to extend softwares in order to answer these new requirements. Moreover, adding a consistent feature does not prevent to modify the previous specified behaviors. Therefore, these modifications have also to be checked. These two problems are well-known under both terms: 1. feature integration, and 2. feature interaction. The problem of feature integration is usual in the field of formal methods and consists in checking that systems enriched with new features yield again existing features as well as the new ones, at least as they are explicitly specified. On the contrary, the problem of feature interaction is more disconcerting


3

because it questions the modularity principles usual in formal software engineering based on a complete preservation of behaviors of modified systems (see [33] for a state-of-the-art on this subject). Checking the correctness of modular systems is usually simple to obtain because it is based on the “Machiavellian” principle “divide and conquer”. Hence, the correctness of local modules leads to correctness of the global system. Here, the difficulty is that we accept to question behaviors of systems. The problem is then to check this questioning by trying to prevent “bad” behaviors. The question is: what is a bad behavior? In the framework of a modular approach, answering this question is obvious because quantitative. Indeed, a bad behavior is any new property satisfied by the enriched system and that was not yielded previously. On the contrary, in the framework of feature design, answering the previous question becomes qualitative, and then prevents to give a rigorous definition to this notion but rather is a matter for subjectivity exclusive to anyone. Let us illustrate this remark by an example. Let us consider a phone system equipped with the two following features: 1. Terminating Call Screening (T.C.S.) which enables a subscriber to automatically refuse all incoming calls from some phones the number of which belongs to a “black list”, and 2. Three Way Calling (3W.C.) which enables a subscriber to be engaged with both other speakers, and then to be three in phone communication at the same time. Let us consider the following scenario: A and B take out a subscription to 3W.C. and T.C.S, respectively. C belongs to A’s black list, A is engaged with B, and A activates the 3W.C. feature by calling C. If C picks up, B finds himself back on the phone with C, what partially questions the behavior of T.C.S. Has such behavior to be either prevented or authorized? From the point of view of B, this scenario can be supposed to be undesirable. But, from the point of view of A, preventing such a behavior consists in reducing 3W.C.’s potentialities, and then can be undesirable. From this, we notice that deciding the qualitative nature (bad—good) of feature interactions is an expert matter. One may well wonder the usefulness of formal methods for this purpose if we cannot formally define the notion of badly interaction. Among reasons which justify the usefulness of formal methods in such a domain, we can cite three of them which seem of the greatest importance to us: 1. every company designing softwares, attempts to control its development costs. But, formal methods are usually together with verifying tools whose some of them are automatized, what is beneficial for development costs. 2. Verifying working-order of systems is a hard task which often requires rigorous methods in order to verify many (usually infinite) scenario of interactions. In this way, formal methods are right candidates to specify the expected behaviors of systems as well as reasoning about them. 3. formal methods are usually together with both structuring and refining techniques. This may enable us to address interactions at the levels they emerge from, and then reduce complexity of interaction analysis procedure. Many formal works have been developed to deal with both feature interaction and integration analysis in the last decade. Each of them proposes to modelize within different formalisms (temporal logics [7, 14, 35, 36], automates [11, 27, 34], dynamical logics [12, 32], and first order logic [22, 41]) the different notions of feature conception which are feature, feature system, integration and interaction problems.

4


However, there is not consensus on modelized notions and mainly on the notion of feature interaction (see related works in Section 5). The nature of detected interactions strongly depends on the used formalism and mainly of associated tools (model-checking, formal proofs, testing,...). Therefore, in order to take into account all the forms of interaction, defining these notions in a generic way, that is in a logicindependent framework, can be necessary. But, is such a generic formalization possible? Key notions of feature oriented design could rely on dedicated aspects which cannot be easily abstracted as this is the case for the object-oriented design [17]. Indeed, the notions of states, object identity, method and message-passing are hardly modelizable in a logic-independent framework 1 . Concerning featureoriented design, such a generic formalization is possible. Indeed, the feature notion only defines a new form of structuring of software systems through features they do. No other aspect is attached except the rôle of features in system structuring. Therefore, we can disregard underlying formalism and focus us on the rôle of features in structuring. In this way, feature design, on its syntactic aspects, is closed to modular design. Therefore, as this has been widely done for the modular approach [33], an institutionlike framework [25] seems adequate to define generic feature systems. We propose then, in this paper, to extend any logic L presented under its institutional form into a logic dedicated to the feature-oriented conception. The interest here is twofold: 1. we provide for both designers and users of logics, a methodology to specify and to study feature systems and their interactions systematically. Hence, we prevent the authors and users of such logics from developing lots of unavoidable formal definitions and results (as defining feature, feature integration and feature interactions) in their formalism. 2. finally, we will show in the paper that this new form of conception is exclusively defined by means of syntactical extensions of feature specifications and systems. Semantics of such notions will be always interpreted through the functor M od and the validation relation j= of the extended logic L (see Section 2 for a succinct presentation of the theory of institution). Consequently, all associated verification tools will be able still to be used to check correctness of feature systems and study feature interactions. All the definitions and theoretical notions presented in this paper will be examplified with the telecommunication system composed of the services POTS, CW and CFB. This system will be specified in C T L [19]. Another example of formalism which fits with all requirements of feature logics together with feature system specifications in this logic are situated in our previous paper [23].

1.2. Structure of the paper We assume that the reader is familiar with the basic notions of category theory as found in the introductory chapters of a textbook on the subject [29, 3]. The paper is organized as follows: Section 2 introduces basic requirements we expect from a formalism to be used for feature design. In Section 3 we define in any logic satisfying the basic requirements 1

Actually, some works have been proposed to modelize such notions at a more abstract level. In this way, we can cite [40] where object concepts are defined using a particular class of institutions, more or less extensions of temporal logics. Regarding object states, recently, some works have been proposed where states can be structured from any suitable institution [46, 4], and properties on dynamic aspects are expressed as pre- and post-conditions on compositions of dynamic operations [45, 4, 5].


5

previously stated, called feature logic, the notions of feature specification, feature system, feature integration and feature interaction. In Section 4, we define a refinement theory in the generic framework of feature logic, and show how to use such a theory to facilitate the search of feature interactions in software systems. To achieve this purpose, we give preservation results through refinement relations. Related works are addressed in Section 5. Finally, we give a summary, comments and perspectives to Section 6.

2. Base feature logic Herein, we start by defining the basic requirements that a formalism has to satisfy to be extended into a logic dedicated to feature design. In order to define a generic version (i.e. logic-independent) of the feature paradigm, we follow the basic ideas developed in the theory of institutions [25].

2.1. Institution Briefly, the theory of institutions abstracts the semantical part of the informal notion of logical systems. Intuitively, a logical system is given by a syntax, a semantic and a proof calculus. Syntax allows us to state properties denoting behaviors that we want to satisfy on a system. These properties have to be unmistakable in an unequivocal way. Therefore, they have to be defined formally. The whole set of properties to satisfy is usually called a formal specification, and the statement of a property is called a sentence. In practice, syntactic part of a logic is based on inductive constructions of formulas from given symbols. Classically, the set of these symbols is called a signature. Symbolic treatment of properties is not sufficient to deal with the correctness of systems. Indeed, they are only un-meaningful sequences of symbols. Then, we have to give a corresponding meaning “in the real world” to phenomena that we want to guarantee. To achieve this purpose, we have to rigorously modelize the real world, and then to consider mathematical models that represent possible abstractions of this real world. Finally, we have to be able to denote among all sentences, properties which are satisfied by these models. This part is usually called semantics. This last part is fundamental in the sense that it allows to deal with the correctness of systems “scientifically”. However, it is not sufficient. Indeed, a fundamental aspect of formal software engineering is to automatically check the correctness of softwares. Hence, the question is: How to automatically check (or prove) that a sequence of symbols is a property satisfied by our software? For this purpose, we have to define how to manipulate formulas and how these manipulations lead to obtain the truth of a property. We usually call these manipulations inference rules, and we talk about calculus. Institutions only concern both syntactical and semantical aspects of a logical system. To abstract the notion of logical system, the authors in [25] define a signature simply as an element of a category. Therefore, sentences associated to a signature are simply defined as a set. All other computable contingencies such as inductively defining formulas from signatures, are not considered. In the same way, models associated to a signature are only objects of a category, any other structure is not associated to them. To characterize properties satisfied by a class of models, a binary relation between models and sentences, called satisfaction relation and denoted “j=”, is defined. More formally, an institution is then defined as follows:

6


Definition 2.1. (Pre-institution [38]) A pre-institution I is defined by a category Sig of signatures provided with, for each signature , a set-valued functor Sen : Sig ! Set yielding the -sentences, a category-valued contravariant functor op ! C at yielding the -models, and a Sig -family j= of binary relations j= jM od()j M od : Sig jSen()j. Within the framework of institutions, a supplementary condition, called the satisfaction condition, is added to formalisms. This condition expresses that properties are preserved through signature morphisms. Formally, this is expressed as follows: Definition 2.2. (Institution) An institution I is a pre-institution satisfying the following property:

8 : ! 0; 8M 2 M od(0 ); 8' 2 Sen(); M j=0 Sen()(') , M od()(M) j= ' Specifications in the small are defined as usual. Definition 2.3. (Flat specification) Given a feature logic L = (Sig; Sen; M od; j=), a L-specification SP is defined by a signature and a set ax of formulas in Sen(). Given a L-specification SP = (; ax), we note M od(SP ) the full sub-category of M od() whose objects are all -models M such that for any ' 2 ax, M j= '. Finally, we note SP the subset of Sen(), so-called semantic consequences of SP , defined as follows: SP = f' j 8M 2 jM od(SP )j; M j= 'g. One of consequences of the satisfaction condition is that we can restrict the functor category of specifications as expressed by the following result:

( ) to the

M od

Proposition 2.1. If L is an institution, then for any L-specification morphism : SP1 ! SP2 (i.e. : 1 ! 2 and Sen( )(ax1 ) ax2 ) we have M od( ) : M od(SP2 ) ! M od(SP1 ) is a functor. Proof: Let ' 2 ax1 and M 2 M od(SP2 ). As Sen( )(ax1 ) ax2 , we have from the satisfaction condition, we conclude M od( )(M) j= '.

M j= Sen()(').

Corollary 2.1. If L is an institution, then for every specification morphism Sen( )(SP1 ) SP2 . Proof: Let SP1

(

: SP1

Therefore,

ut

! SP2 , we have

j=

M od SP1

'. Let M 2 M od(SP2 ). As L is an institution, by Proposition 2.1, M od( )(M) 2 ). Therefore, M od()(M) j= '. By the satisfaction condition, we conclude M j= Sen()(').

ut

Another simple consequence of the satisfaction condition is the following: Proposition 2.2. (Cut) If L is an institution, then for every L-specification (; Ax) and every

(; Ax) =)

(; Ax)

Sen(), we have:


7

Proof: Simple consequence of Definition 2.3.

ut

The satisfaction condition is very useful for modularity purposes. Indeed, it ensures one of the two ways of the modularity (so-called modularity by restriction in [6]) which expresses that a “complex” system can be used for simpler purposes 2 . However, one of the particularity of the feature paradigm is the ability to “break” the modularity. This ability is desired in order to keep a flexible conception. The consequence is that some unexpected behaviors (related to the existing system) can occur (feature interaction problem). Therefore, we will see in Section 3 that imposing the satisfaction condition may prevent us to detect some feature interactions (cf. Proposition 3.1).

2.2. Strongly inclusive category A fundamental basic notion of the feature paradigm is that features are defined sharing some common informations issued from the basic system. Consequently, the joint integration of two features F1 and F2 has to take into account some symbol sharing. At the signature level, this means that the signature of a system which has the two features F1 and F2 , has to contain the union of F1 and F2 signatures. Thus we need the categorical notion for the union on signatures. Classically, the categorical concept of pushout and more generally finite colimit provides the abstract basis for combining signatures (and more generally specifications) in a systematic manner [33]. However, it is well-known that the concept of pushout is too general to deal with the concept of union, g1 ! S S 0

even though we take the category of sets usually denoted

Set.

Indeed, given a pushout g2 ??y

S2

1

? ? y in

! S

arrows g1 and g2 may not be inclusions (by the way nor injections) and then both S0 may not be the intersection of S1 and S2 and S the union of S1 and S2 . Therefore, to categorically denote the set-theoretical union, we have to parameterize the pushout by an object denoting the sharing between 1 and 2 (usually noted 1 \ 2 ) provided with two morphisms denoting inclusions. However, the usual definition of union throughout a pushout is only up to isomorphism. Intuitively, this means that this approach allows to rename symbols in the signature 1 [ 2 . In our context, we prefer that the notion of union of signatures avoids renaming. Indeed, a feature generally characterizes the behavior of a new functionality. Thus, its description introduces just a few new symbols. The greatest part of used symbols refers to already existing functionalities, whose some behaviors can be modified. To obtain this result, we use the axiomatization of the notion of inclusion given in [15]. The main advantage of this axiomatization is that intersection and union are unique. Consequently, there is no longer parameterization by the intersection, and renaming is avoided (i.e. union is not defined up to isomorphism).

Set,

Let us recall the axiomatization of the notion of inclusion given in [15] : Definition 2.4. A category C is strongly inclusive if and only if C is a category with pullbacks and there exists two sub-categories I and E of C such that: 2

The other way is that a simple system can be extended to be reused for more “complex” purposes. This way is obtained by imposing that there exists a synthesis functor (left adjoint to Mod( )) which is an inverse to the forgetful functor Mod( ) [6, 15].

8


1. 2. 3. 4.

jIj = jEj = jCj; any e 2 H omE is epic; every morphism f in C can be factored uniquely as Æ e with 2 I and e 2 E ; H omI defines a partial order on C and the poset (jCj; H omI ) is a lattice where the sup of A and is the sum of A and B , denoted A + B , and the inf of A and B is the unique inclusion pullback in C of the sum, called intersection of A and B and denoted A \ B (both existence and uniqueness of A \ B are given in [15]). Moreover, we impose on A + B to be the pushout of A \ B .

B

The morphisms in I are called inclusions and the pair (I ; E ) is called the inclusion system of C . Afterwards, we will use the notation A ,! B to denote the morphism : A ! B in H omI (A; B ). Remark 2.1. Sum and intersection are unique and the full sub-category whose morphisms are inclusions is finitely cocomplete (see [15] for the complete proofs of these results). Example 2.1. As an example, the category Set provides with the inclusion system (I ; E ) where I contains all the inclusions and E contains all the surjections is trivially strongly inclusive. Indeed, given g1 ! S S 0

1

a pushout g2 ??y

S2

? ? y in Set with S0

! S

theoretical union of S1 and S2 (i.e. pushout of S1 \ S2 .

S

= S1 \ S2

= S1 [ S2 ).

and all arrows are inclusions,

S

denotes the set-

This pushout is also a pullback, so S1

[ S2 is the

2.3. Feature logic To deal with feature conception, we add to the quadruple (Sig; Sen; M od; j=) some properties in order to deal with the concepts of inclusions, intersections and unions of signatures. Moreover, we impose that the functor Sen maps all inclusion morphisms 2 I to the set-theoretic inclusion in Set between sets of formulas. This last condition is usually satisfied (anyway all logics that are widely used in computing science and mathematics satisfy it). Feature logics are then defined by: Definition 2.5. (Feature logic) A feature logic is a pre-institution

(Sig; Sen; M od; j=) satisfying:

Sig is a strongly inclusive category whose associated inclusion system is (I ; E ). It has an initial object, denoted ; , which is also initial in I . Finally, intersection is distributive with respect to sum, that is: 8; 0 ; 00 2 jSig j; \ (0 + 00 ) = ( \ 0 ) + ( \ 00 ).

8( ,! 0), Sen() Sen(0) Imposing the distributive law is a technical point which will be used to obtain most of the results in Section 4.3.


9

Example 2.2. (C T L as an institution) C T L [19] is a branching-time temporal logic where the structure representing all possible executions is tree-like rather than linear. It is well-adapted to specify and reason about non-deterministic and/or concurrent process. When dealing with propositional fragment of logics, a signature is only a set of propositional variables. Thus SigCT L is simply the category Set. Therefore, the most natural inclusion system for SigCT L is (ICT L ; ECT L ), where ICT L contains set-theoritical inclusions and ECT L contains all the surjections. Therefore, + and \ are the set-theoretical union and intersection, respectively. ; is initial Set. Moreover, [ is distributive with respect to \. The mathematical definition of a -model M is given by a set S of states, a binary relation R S S satisfying: 8s 2 S; 9s0 2 S; s R s0 , and a total function L : S ! P () called labelling function. Therefore, -models are labelled transition systems where R denotes the transition relation and L is the labelling associating for each state s of S the set of propositional variables true at s. For any signature , we note M odCT L () the category whose objects are all -models and whose morphisms between two -models M = (S; RS ; LS ) and M0 = (S 0 ; RS 0 ; LS 0 ) are total functions f : S ! S 0 compatible with relation and labelling functions. Now for all signature morphism : ! 0 , M odCT L ( ) : 0 0 0 0 0 0 M odCT L ( ) ! M odCT L () is the functor defined by M odCT L ( )((S ; RS 0 ; LS 0 )) = (S ; RS 0 ; LS 0 ) where for all s 2 S 0 ; LS 0 (s) = fp 2 n (p) 2 L0S (s)g. A -axiom is a well-formed formula whose the syntaxical rules are given by:

j C T L ) C T L j X C T L j G C T L j F C T L C T L U C T L j 8C T L j 9C T L AT OM ::= p j ? CT L

::=

AT OM

being any propositional variable of . We note SenCT L () the set of all the -axioms. Because well-formed formula in C T L are inductively defined from a set of propositional variables, for every signatures 0 , we trivially have Sen() Sen(0 ). For every 2 jSig j, let us note j= M od() Sen() the relation defined by: M j= ' if and only if for any sequence = (s0 ; s1 ; : : : ; sn ; : : :) where si R sj for every i < j (runs), (M; ) j= ' where (M; ) j= ' means, for any i 2 N , let us note i the subsequence (si ; si+1 ; : : : ; sn ; : : :) of ,

p

(M; ) j= p iff p 2 L(s0 ) for p 2 ; (M; )6j= ?; (M; ) j= '1 ) '2 iff if (M; ) j= '1 then (M; ) j= '2 ; (M; ) j= X ' iff (M; 1 ) j= '; (M; ) j= G ' iff for all i 2 N , (M; i ) j= '; (M; ) j= F ' iff there exists i 2 N , (M; i ) j= '; (M; ) j= '1 U '2 iff there is j 2 N s.t. (M; j ) j= '2 and for all k < j 2 N (M; k ) j= '1 ;

10


(M; ) j= 8' iff for any run 0 starting to s0, (M; 0 ) j= '; (M; ) j= 9' iff there exists a run 0 starting to s0, (M; 0 ) j= '; Let us note j=CT L the family of relations fj= g2jSigCTL j . Then, the quadruple LCT L = (SigCT L ; SenCT L ; M odCT L

) is an institution.

Indeed, the satisfaction condition holds because no pruning is done on sets of states throughout signature morphisms.

3. Formal specification of feature systems 3.1. Feature specification and their integration Let us consider a feature logic L = (Sig; Sen; M od; j=). How to specify a feature in such a logic? To answer such a question, let us come back to the example T.C.S. succinctly presented in the previous section. In this example, we have seen that T.C.S. directly modifies the behavior of P.O.T.S. (the basic phone service). Indeed, the behavior of P.O.T.S. consists in describing how two physical phones can be connected together. Hence, when someone dials a phone number whose the associated phone is free then a ringing indicates this and if someone takes off the hook, a communication can be engaged. The feature T.C.S. directly questions this basic behavior by modifying the property that every incoming call on a free phone is indicated by a ringing. Indeed, if a black list of phone numbers has been drawn up by a subscriber A, any incoming call from one of such phone numbers is not indicated by a ringing on A’s physical phone anymore. On the contrary, all the other properties of P.O.T.S. are preserved by T.C.S. Therefore, let us consider a formula '(X; Y ) of the specification of P.O.T.S. that gives the basic properties specifying how to engage a communication from X to Y. A generic description of T.C.S. could be the following: 1. 2.

:t s?(Y ) ) '(X; Y ) t s?(Y ) ) (X; Y )

where t s? : subs riber is a predicate which indicates that someone has subscribed or not to T.C.S., and (X; Y ) gives the new conditions to engage a communication from X to Y by respecting T.C.S.’s constraints. Regarding this example, we can see that a feature specification only makes sense with respect to the system where it will be plugged on. Hence, a feature is a basic element of design which includes a strong partial knowledge of the system specification on which we plan to plug it on. This partial knowledge reflects both:

the subpart of the system that the feature aims at enriching, and the basic behaviors (here expressed by axioms) that the feature aims at modifying.

In practice, modifying some behaviors of some subparts of systems is checked by imposing that some properties are preserved. For instance, the fact that all phone calls have to be paid by someone, will never question. These preserved properties are not necessarily explicitly specified in the system specification. They can be semantical consequences of it. In our logic-independent framework, this naturally leads to the following representation of feature specifications:


11

an enrichment of the system signature to modify in order to characterize the addition of new functionalities (e.g. the addition of the predicate t s?), a modification of some axioms (e.g. removing tions), and

(

' X; Y

) and replacing it by both above implica-

a set of properties which have to be preserved, called invariants.

This gives rise to the following definition: Definition 3.1. (Feature specification) A feature specification F is a triple (SP; I nv; SP 0 ) such that SP = (; Ax) and SP 0 = (0 ; Ax0 ) are both L-specifications, et I nv Sen(). Moreover, this triple satisfies both following conditions: 1.

,! 0 , and

2.

I nv

SP

SP \ SP 0.

is called the required specification of F . Elements in I nv are called invariants.

In practice, the required specification is often restricted to the basic feature or very few ones. Moreover, the basic behaviors that the feature under specification aims at modifying and to preserve, usually make a partition of the set of axioms of its required specification. Hence, the set I nv contains the invariants that we want to preserve after the integration of the feature F as expressed by the second condition in Definition 3.1. Therefore, this last property can be seen as the feature correctness. Remark 3.1. The definition of a feature specification is closely related to the notion of correct refinement in the classic sense of algebraic specifications [18]. Indeed, we can see a feature specification as a correct refinement of the specification (; I nv ) defined in terms of a signature morphism together with a preservation of the behavior (represented by I nv ). A feature system specification will then be a set of feature specifications. However, this is not sufficient. Indeed, semantics of specifications can only be defined from flat specifications because models do not take into account structuring. Therefore, we have to associate to any set of feature specifications a ”flat” L-specification. The key question is how to define such a flat L-specification provided with an adequate semantic counterpart. A first answer might be to consider the union of all axioms issued from the different features of the system under analysis. However, this is not the good solution. Indeed, let us recall that each feature is defined as possibly modifying the behavior of the existing system (more precisely, a subpart of it) where it will be plugged on. Thus, any system obtained would be lucky enough to be inconsistent. The good answer is to provide the system with an order of integration compatible with the requirements of each feature. Hence, a feature F2 has to be integrated after a feature F1 if the required specification of F2 depends on F1 . Concerning two independent features, this order is arbitrary and then is left to specifier’s free will. Moreover, it is easy to see that this free will has no consequence on the resulting flat specification obtained by following any integration order satisfying the above basic requirements.

12


Definition 3.2. (Feature system Specification) A feature system specification Sys is a finite sequence (Fi )in of feature specifications. The first feature specification F0 of Sys is necessarily of the form ((; ; ;); ;; SP ). It is called the basic feature 3 . Example 3.1. Here, we present a small example of a specification of a feature system in C T L , including a simplified basic telephone feature B , a call waiting feature C W and a call forward when busy feature C F B , whose meaning will be discussed in their respective associated sections. The basic telephone system feature B : Due to the lack of space, we cannot present the whole specification of the basic telephone feature. The feature we present here, will only express the unique axiom which is required by the features C W and C F B . There are N phones involved in the basic system. The basic telephone feature is of the form B = (((; ; ;); ;; ; ,! B ); axB ) where ; denotes the empty signature and :

8 >< B = i6 jS N > : =

axB

B1 :

F ree Pi Pi alls Pj Pi ref uses Pj

9 >= >;

only contains the following axiom schematas:

8GP ( (

i

alls P

j

^ :Free P ! 8X P (

j

j

refuses P ))) i

Axiom B 1 expresses that whenever a call of source Pi and target Pj is done, if Pj is not free, then the call will be refused in the next state. The call-waiting feature C W : When a phone Pj is not free, C W allows it to put on hold any caller (Axiom C W 1). When this is the case then possibly the two phones can get engaged at the next time (Axiom C W 2), but this will not happen if one of the two phones becomes free (Axiom C W 3). The feature C W is of the form C W = (((B ; fB 1g); ;; B ,! CW ); axCW ) where: Pi

fPi holds Pj g CW = B [ i6=jS 2f1;2;3g

axCW

is the set containing the three following axioms schematas :

CW1 :

8GP ( (

8GP

CW2 :

( (

8GP

3

alls P

j

holds P

i

j

holds P

i

CW3 :

( (

i

j

^ :Free P ! 8X :Free P ^ :Free P ^ P

! 9X P (

! 8X

(

j

i

j

j

holds P )))

online P )))

Free P

((

i

j

j

_ Free P ! :P i)

j

holds P ))) i

For instance, F0 is the specification of P.O.T.S. in telephone systems or the basic feature of lifts.

i


13

The call-foward when busy feature C F B : When a phone Pj is not free, C F B allows its users to forward all the incoming calls to another phone (Axiom C F B 2). When C F B is not used, the incoming calls are refused (Axiom C F B 1). The feature specification C F B is of the form C F B = (((B ; fB 1g); ;; B ,! CF U ); axCF U ) where:

CFSB = B [ fC F B P

i6=j 2f1;2;3g

axCW

i Pj

g

is the set containing the two following axiom schematas:

8GP CFB2 : 8 G P CFB1 :

( (

i

alls P

j

( (

i

alls P

j

W CFB P P ! 8X P refuses P ^ :Free P ^ :kN ^ :Free P ^ CFB P P ! 8X P alls P j

j

(

j

j

k

k ))

(

The flat L-specification from a feature system specification struction from its integration order. Notation 3.1. Let SP ax.

(

is the result of an inductive con-

= (; ax) be a L-specification. Then, let us note Sig(SP ) = and Ax(SP ) =

Notation 3.2. Let us note SP

! SP 0 to mean that Sig(SP ) ,! Sig(SP 0 ) and Ax(SP ) Ax(SP 0).

,

Definition 3.3. (Integration) Let Sys = (Fi )in be a feature system specification. Let us note specifications inductively defined by:

Sys0

let Fi

i )))

k )))

i

Sys

j

(Sysi )in

the sequence of

L-

= SP00 , and = (SP; I nv; SP 0 ), then Sysk +1

= (Sig(Sysk ) + Sig(SP 0 ); (Ax(Sysk ) n Ax(SP )) [ Ax(SP 0 )).

Sysn is the L-specification resulting from the integration order. This integration order is sensible if and only if for every feature specification Fi = (SPi ; I nvi ; SPi0 ) there exists j < i such that SPi ,! Sysj .

Remark 3.2. Let us recall that a feature is defined in isolation. But in practice, between the description of a feature and its integration, others features will probably be defined and plugged on the existing system. Moreover, among those features, some of them may be defined on the same required specification. Thus, when we integrate any feature, its required specification may no longer exist. This motivates the notion of sensible integration order. This notion imposes that the required specification of any feature occurs only in the whole integration history of the system existing before the integration of the feature of interest. Example 3.2. With notations of Example 3.1, let us consider the system (B; C W; C F B ). The integration sequence for this system is (Sys1 ; Sys2 ; Sys3 ) where Sys1 = (B ; fB1 g), Sys2 = (CW ; ax2 ), where ax2 = fC W1 ; C W2 ; C W3 g and Sys3 = (CW [ CF U ; ax3 ), where ax3 = fC W1 ; C W2 ; C W3 ; C F B1 ; C F B2 g.

14


Hence, Sysn is the final flat L-specification of the feature system specification Sys and has to be understood as the “final system” obtained after integration. Therefore, the semantics of Sys is defined by M od(Sysn ). A feature system specification is meaningful if the specification Sys is consistent, that is there is at least one (untrivial) model in M od(Sysn ) which satisfies it. Therefore, feature integration problems are restricted to verify that both L-specification Sysn obtained after integration is consistent and all invariants are preserved by Sys, that is: Definition 3.4. (Sound integration) Let Sys = (Fi )in be a feature system specification. 1. 2.

Sys

has a sound integration if and only if:

9' 2 Sen(Sig(Sysn )); Sysn6j=' (Sys is consistent) 81 i n; Sysn j= I nvi (invariants are preserved)

Therefore, the satisfaction of invariants is a correctness criteria. Indeed, when they are not satisfied, they can be considered as harmful interactions. Definition 3.5. (Pre-institution of feature specifications) Let L = (Sig; Sen; M od; j=) be a feature logic. Then, let us define the quadruple Lfeat = (Sigfeat ; Senfeat ; M odfeat ; j=feat ) as follows:

is the category of feature signatures and feature signature morphisms defined, respectively, as triples (SP; I nv; ,! 0 ) and for two feature signatures (SP1 ; I nv1 ; 1 ,! 01 ) and (SP2 ; I nv2 ; 2 ,! 02 ) as a pair (1 : 1 ! 2 ; 2 : 01 ! 02 ) satisfying both following conditions:

Sigfeat

1. 2.

2 ,! 02 Æ 1 = 2 Æ 1 ,! 01 , Sen(1 )(Ax(SP1 )) Ax(SP2 ) and Sen(1 )(I nv1 ) I nv2 .

The functor Senfeat maps each feature signature nature morphism (1 ; 2 ) to Sen(2 ).

(SP; I nv; ,! 0 ) to Sen(0 ), and each sig-

The functor M odfeat maps each feature signature (SP; I nv; ,! 0 ) to M od(0 ; I nv ), and each signature morphism every (1 ; 2 ) : (SP1 ; I nv1 ; 1 ,! 01 ) ! (SP2 ; I nv2 ; 2 ,! 02 ) to 0 0 M od(2 ) : M od(2 ; I nv2 ) ! M od(1 ; I nv1 ) (M od(2 ) is a functor by Proposition 2.1).

j=feat = (j=F )F 2jSigfeat where for each F = (SP; I nv; ,! 0, j=F =j=0 . Fact 3.1. If L is an institution (i.e. the satisfaction condition is satisfied) then Lfeat so is. By following Definition 2.3, a feature specification is then any pair (F ; axF ). To connect the form of feature specifications such as defined in Definition 3.1 with the form of specifications in Lfeat , it is sufficient to consider, given a feature specification F = (SP; I nv; SP 0 ), that F = (SP; I nv; Sig (SP ) ,! 0 0 Sig (SP )) and axF = Ax(SP ).


15

3.2. Feature interactions As we previously glimpsed in Introduction, integrating a feature in a system is not a conservative operation, that is some modifications on any subpart of the enriched system have been allowed to be done. Hence, integrating features can generate some “disturbances” named feature interactions. The qualitative nature of these disturbances (i.e. to be bad or good) is purely subjective and then is an expert matter. However, a formal description of feature interactions without any value judgment can be given. Indeed, an interaction is the result of the comparison between “what is true for the feature” with “what is true for the system”. From a logical point of view, this naturally leads to both following sets: 1. Non-conformance properties: The feature under analysis does less services than scheduled (by its specification) when it is plugged on the system. 2. Emerging properties: the feature under analysis does more services than scheduled when it is plugged on the system. This gives rise to both following definitions: Definition 3.6. (Non-conformance properties) Let Sys = (Fi )in be a feature system specification. The set of non-conformance properties for (1 i n) with respect to Sys is defined by:

Fi

NCP Fi ;Sys = Fi n Sys Example 3.3. As an example, we can cite the usual property of P.O.T.S. which means that all incoming call from A on B is indicated by either a tone on B’s phone when B is free, or a peculiar ringing in A’s handset. Indeed, when the feature T.C.S. is integrated, this last property becomes a non-conformance property for P.O.T.S. In the same way, in the framework of the lift specification, the usual liveness property which prevents that a requirement is never handled, becomes a non-conformance property for the basic service when the priority floor service is integrated. Non-conformance properties are direct consequences of behavior non-preservation which underlie feature design. They directly question one of both principles of the modular conception which is that “all complex softwares can be used to simple purposes”. In the institution framework, this principle is a consequence of the satisfaction condition (cf. Corollary 2.1). Hence, if the underlying feature L is an institution (i.e. it satisfies the satisfaction condition), we have the following result: Proposition 3.1. If L is an institution then for every feature system specification Sys = (F )in and every feature specification Fi = (SPi ; I nvi ; SPi0 ) of Sys such that SPi0 ,! Sysn , we have: NCP Fi ;Sys = ;. Proof: As SPi

! Sysn, by Proposition 2.1, we have:

,

( 0 ) ,! Sig(Sysn ))(M od(Sysn )) M od(SPi0 ) Hence, for every ' 2 Ax(SPi0 ), we have Sysn j= ', and then Fi Sys . (

M od Sig SPi

ut

16


Corollary 3.1. If L is an institution, we always have:

NCP Fn ;Sys = ;.

Hence, using an institution as feature logic can restrict the capability to discover non-conformance properties. In order to define emerging properties, a restriction has to be done on properties in Sys . Indeed, most properties in Sys (the set of true properties for Sys) do not involve the feature of interest F = (SP; I nv; SP 0 ): all those which do not contain any syntactical elements introduced by the signature of F . These properties are over the language introduced by the system minus the one introduced by F . To define a pertinent set of emerging properties, we have to exclude from Sys all properties which do not affect the feature of interest. Therefore, if we note Sig (F ) = Sig (SP 0 ), then all properties belonging to Sys \ Sen(Sig (Sysn ) n Sig (F )) have not to be considered as emerging properties. The axiomatization of the set-theoretic difference, useful to give a meaning to Sig (Sysn ) n Sig (F ), has not been defined in [15]. Therefore, before introducing the set of emerging properties, let us start by giving such an axiomatization. categorical axiomatization of the set-theoretical difference As it is argued in [15], even though set inclusions are the simplest natural example of inclusion system, inclusion systems in general may have properties that are quite different from those of sets. For example, any inclusion A ,! B in set theory is ”split” in the sense that B can be written as a disjoint union A C where C is the ”difference” between B and A. This property does not hold for all inclusion systems. For example, given a many sorted signature inclusion (fsg; ;) ,! (fsg; ff : s ! sg), the difference (;; ff : s ! sg) is not a signature. The expected result should be (;; ;). Nevertheless, the notion of difference can be expressed in a categorical manner if we do not ground this axiomatization on property of disjoint union. Indeed, we can characterize the difference between B and A, denoted B n A, as the greatest set of sets X included in B such that X \ A = ;. Therefore, we assume in the following that every feature logic L = (Sig; Sen; M od; j=) satisfies the following supplementary requirement:

`

Definition 3.7. (Categorical difference) Let L = (Sig; Sen; M od; j=) be a feature logic. L satisfies the property of difference if and only if for every pair of signatures (; 0 ) 2 jSig jjSig j, if we note Sig0 n the full sub-category of I , the object class of which is jSig0 n j = fX j X \ = ; ^ X ,! 0 g, then Sig0 n has a terminal object that we note 0 n . We call it the difference between 0 and . Note that this property is satisfied by all classical logics such as for instance LCT L . Afterwards, we consider that feature logics satisfy such a property. Let us resume our definition of emerging properties. Notation 3.3. Let F 0 Ax(F ) = Ax(SP ).

= (SP; I nv; SP 0 ) be a feature specification.

Definition 3.8. (Representative properties) Let Sys = (Fi )in be a system specification. For every properties for Fi is defined as follows:

= Sig(SP 0 ), et

i n, the set SysFi of representative

Fi = Sys n Sen(Sig (Sysn ) n Sig (Fi ))

Sys

1

Let us note Sig (F )


17

The set of emerging properties is then defined as follows: Definition 3.9. (Emerging properties) Let Sys = (Fin ) be a system specification. The set of emerging properties for Fi with respect to Sys, is defined by:

EP Fi ;Sys = SysFi n Fi Example 3.4. As an example, let us suppose that a user A has subscribed to both features C.F.B. and C.W. Moreover, let us suppose that B is calling A but A is already engaged. Finally, let us suppose that no priority rules has not been specified concerning these two services. Both C.W. and C.F.B. are going to be activated, and then B is going to be both in waiting and forwarded in another phone. At the specification level, this conflict is denoted by an emerging property that can only be checked at the system level. Formally, from the feature system of Example 3.2, this is expressed as follows: It is easy to see that EP (CW;Sys3 ) 6= ;. Indeed from C W1 and C F B1 we deduce that the formula :

8(G (Pi alls Pj ^ :F ree Pj ^ C F B Pj Pk ! X (Pi allsPk ^ Pj holds Pi ))) is an element of Sys3 CW . It is easy to see that it is not an element of C W . It reveals a subspecification interaction between C W and the system Sys3 . The reason is that the activation conditions for C W and C F B are the same (roughly speaking : the callee is not free).

4. Refinement One of the main open problem encountered when dealing with feature design is that some interactions may appear at different levels of design. [26] points out that some interactions may be inherited from higher to lower levels but also that some others may disappear through the operation of concretization. For example, an interaction due to a non-deterministic description may disappear in a lower level of design and replaced by deterministic ones. [26] draws up then the conclusions that:

interactions should be addressed at the levels they emerge from, and it is necessary to have a framework that supports the mapping from one level to the next lower one.

Here, we propose then to use refinement techniques as a basic incremental method to simplify the feature interaction task. The underlying motivation is that interaction are easier to study on more abstract specifications when some details are hidden. Of course, as pointed out in [26], the problem of the correction of the mapping from an abstract level to a more concrete one is essential: the important point is to study interaction preservation when dealing with more concrete specifications. Defining a refinement theory in the framework of feature design has then two purposes: 1. answering the problem of specifying real size systems, and 2. studying interactions at every design step, and studying how these interactions behave though refinement.

18


In the following, we suppose that the underlying feature logic is an institution, that is it satisfies the satisfaction condition. This condition is necessary to establish some results of interaction preservation through refinement relation. Therefore, we are going to take advantage from having shown that the feature logic is an institution to define a refinement theory within it. Hence, we will use notations and results established in [8, 39] where refinement has been studied in the abstract framework of institution.

4.1. Feature refinement Since system specifications are grounded on set of features, the basic refinement is feature refinement. Feature specifications being at the end flat L-specifications of the form (; ax), syntax of refinement follows the usual definition, that is enriching signatures and replacing axioms by more concrete ones. Any transformation is not made over both required specification and the set invariants of feature specifications. Indeed, refinement focuses on a concretization of feature behaviors. On no account, is it to give a concrete expression of other features except through interactions. Hence, both requirement specification and set of invariants are preserved because they denote feature behaviors which are in front of the feature under refinement in the integration order. Therefore, they are not concerned by the refinement. This leads to the following definition: Definition 4.1. (Syntactic refinement) Let F be a feature specification. A Syntactic refinement of F is a Sig (F ) ,! Sig (SPimp ). Let us note F SPimp such a refinement.

L-specification SPimp such that

Example 4.1. Let us consider the basic telephone system B presented in Example 3.1. We can refine this feature by adding in the signature a proposition which denotes an authorisation of communication (between phones) given by the system. Bimp is then defined as follows: Bimp = (Bimp ; axBimp ) where:

Bimp = B [i6=jS fsys aut Pi Pj g N axB only contains the two following axiom schematas: B1 B1

imp1 imp2

: :

8 G P alls P ^ :Free P ! 8X :sys aut P 8 G :sys aut P P ! P refuses P ( ( ( (

i

j)

j

i

j

j

(

i

P ))) j

i ))

Axiom B 1imp1 expresses that whenever a call of source Pi and target Pj is done, if Pj is not free, the system refuses the communication. Axiom B 1imp2 expresses that whenever the system refuses a communication, this communication does not happen. A refinement can introduce both decision and algorithmic choices. For instance, abstractly specifying a sorting only requires that the resulting array is a permutation of the input one, and its elements are sorted in the expected order. It is clear that all existing sortings are correct realizations of such a specification. But, if we specify a peculiar algorithm for sorting such as quick-sort, we cut down in the class of acceptable sorting algorithms and only preserve the desired algorithm. The consequence of such choices then consists in cutting down in model classes 4 . Semantically, this is expressed as follows: 4

If we make an analogy between specification models and possible realizations.


19

Definition 4.2. (Semantic refinement) SPimp be a syntactic refinement. SPimp is a semantic refinement of F , written F Let F and only if M od(Sig (F ) ,! Sig (SPimp ))(M od(SPimp )) M od(F ).

SPimp , if

Semantic refinement well expresses refinement correctness, that is the refinement specification meets all requirements of the higher level specification. Indeed, we have the following result: Proposition 4.1. Let F

SPimp

be a syntactic refinement. Then, we have:

F SPimp () F SP imp Proof: ()) Let

2 F , and let M 2 M od(SPimp ). As L is an institution, by Proposition 2.1, we have M od(Sig (F ) ,! Sig (SPimp ))(M) 2 M od(F ). Therefore, M od(Sig (F ) ,! Sig (SPimp ))(M) j= ' (from the second point of Definition 2.5, Sen(Sig (F ) ,! Sig (SPimp ))(') = '). By the satisfaction condition, we can conclude M j= '. (() Let M 2 M od(SPimp ). By hypothesis, for every ' 2 Ax(F ), we have M j= '. As L is an institution, we have M od(Sig F ,! Sig (SPimp ))(M) j= '. ut Corollary 4.1. Let F SPimp be a semantic refinement with F = (SP; I nv; SP 0 ). Therefore, Fimp = '

(SP; I nv; SPimp ) is a feature specification. Proof: I nv

. F , so is I nv SPimp

Example 4.2. If we consider the refinement of Example 4.1, it is easy to see that consequence of B 1imp1 and B 1imp2 .

ut B

1 is a semantical

Another condition is usually added to the refinement correctness in order to express that a refinement does not make any decision and design choice but rather completely simulates the abstract specification, that is the refinement specification is indistinguishable from the behavior of the implemented feature specification. This is the case when we simulate a data structure from other data structures which are available in the target programming language (e.g. stacks from the pair (array,natural number) or list from pointers). In a logical approach, specification behavior being defined by the class of models that satisfy axioms, the preservation of behavior is expressed as follows: Definition 4.3. (Complete preservation of behavior) Fimp be a syntactic refinement. Then, Fimp completely preserves the behavior of Let F \ Sen(F ). only if F = Fimp

F if and

Because, semantic refinement cuts down in model classes of specification, both notions of refinement correctness and preservation of behaviors are not similar. The only way to obtain such a result is to impose on specification models the following condition:

8M 2 M od(F ); 9M0 2 M od(Fimp ); M od(Sig(F ) ,! Sig(Fimp ))(M0 ) = M

20


This last condition, usually called completeness [18], means that every possible realizations of the abstract specification is refined by (at least) a realization of the more concrete specification. Example 4.3. The refinement given in Example 4.1 is complete. Indeed, any model (S; R; L) of B can be extended into one (or several) model(s) of Bimp which only have the property that for any state s 2 S such that Pi alls Pj 2 L(s) and F ree Pj 2 = L(s). 0 = L(s ). Therefore for all sRs0 , sys aut Pi Pj 2 Hence, M odfeat (B ,! Bimp )(jM odfeat (Bimp )j) = jM odfeat (B )j. From the satisfaction condition, we then obtain B = Bimp \ Senfeat (FB ), where FB is the signature of B .

4.2. Refinement and integration Of course, it is not reasonable to refine a specification as a whole in a single step. Large softwares usually require many refinement steps before obtaining efficient programs. This leads to the notion of sequential composition of refinement steps. Usually, composition of enrichment is mainly divided into two concepts: 1. horizontal composition, and 2. vertical composition. Horizontal composition deals with refinement of subparts of system specifications when they are structured into specification “blocks”. In our framework, blocks are feature specifications. On the contrary, vertical composition deals with many refinement steps. In both cases, we will show that the correctness is preserved. 4.2.1.

Horizontal composition

Here, horizontal composition can be informally expressed as follows: “if a feature specification Fimp correctly refines a feature specification F of a system Sys, then all requirements of Sys are preserved by the system where F has been replaced by its refinement Fimp ” Before establishing this result, we have in first to formally define what means “the system where F has been replaced by its refinement Fimp ”. Indeed, this replacement cannot be a simple substitution of F by Fimp because some features integrated in Sys may share with F some axioms. Therefore, these axioms have to be removed and replaced by axioms of Fimp everywhere they occur in Sys. Hence, in each feature specification of Sys, we have to replace any axiom ' of F , when it occurs, by a set of axioms ax' of the refinement specification Fimp . Of course, to ensure a syntactic consistency, ' has to be replaced by the same set ax' everywhere it occurs in Sys. Now, to ensure a semantic consistency, this replacement has not to generate inconsistencies with other existing features in Sys. Therefore, we have to impose that ax' satisfies ', that is ax' j= '. For logics equipped with a refinement theory, this last condition is usually satisfied. Indeed, for these logics, a refinement is usually defined by an implementing specification and an intermediate specification [18]. The intermediate specification is an enrichment of the implementing one, and usually (at least in practice) makes a correspondence one-toone between the operations of the implementing specifications and the operations of the specification to


21

be implemented. Moreover, this correspondence is usually defined in a constructive way. In our framework, we directly manipulate the result of this enrichment without mentioning enriched specification (i.e. the implementing specification), that is both implementing and intermediate specifications are together in a flat specification SPimp . Finally, a last condition has to be imposed in order to define a concrete system which is lucky enough to be an implementation of the abstract one. This last condition states that for two distinct properties ' and '0 , ax' and ax'0 are disjoint. This allows to prevent the following kind of situation: let us suppose two properties ' and '0 of F such that ax' \ ax'0 6= ;, and let us suppose that after an integration step, ' has been removed and replaced by ax' but not '0 . In the refined system we want to find ax'0 again. However, because ' has been removed, we will only find again ax'0 n (ax' \ ax'0 ). This last condition can seem strong because for instance in the framework of a refinement of a data structure (e.g. stacks) by other ones (e.g. arrays to stock elements and natural numbers to denote top of stacks), this intersection is usually non-empty. Indeed, similar parts of implementing specifications used in a refinement can naturally be used to specify different operations in the intermediate specification. For instance, the operation push for stacks is simulated by increasing of one unit stack height. Hence, this requires to use the operation successor of arithmetic, itself used to simulate the operation height for stacks. In the framework developed in [18], it would be sufficient to impose this condition to be disjoint on axioms of the intermediate specification. In our framework where both intermediate and implementing specifications are put together into a flat specification, we can nevertheless, from such a situation, generate an empty intersection. It is sufficient that the institution gets an internal conjunction. In this case, we ) ^ . Syntactically, this ensures replace any formula 2 ax'0 n (ax' \ ax'0 ) by the formula (

^

2ax' \ax'0

us an empty intersection between both sets ax' and ax'0 . Therefore, replacing a feature F by a correct refinement in a system specification is expressed as follows: Definition 4.4. (Consistent with refinement) Let F Fimp be a semantic refinement. let R consistent with the refinement if and only if:

= (ax' )'2Ax(F ) be a partition of Ax(Fimp ).

R is said

8' 2 Ax(F ); (Sig(F ); ') (Sig(Fimp ); ax' ) Example 4.4. Regarding to Example 4.1, if we set that axB 1 = fB 1imp1 ; B 1imp2 g, then R is consistent with the refinement. Indeed, we have: axB1 j= B1 .

= faxB1 g

The condition given in Definition 4.4 is stronger that the refinement correctness such as it has been defined in Definition 4.2. Indeed, we have the following result: Proposition 4.2. If a set R is consistent with a refinement F

Fimp , then we have F Fimp .

Proof: As R is consistent with a refinement F Fimp , we have for every ' 2 Ax(F ) that ax' j= '. Therefore, by Corollary 2.1, ax' [ ax'0 j= ', and then ax' [ ax'0 j= '0 . Let us suppose, f'; '0 g j= . By Proposition 2.2, we have ax' [ ax'0 j= . . By Proposition 4.1, By iterating this schema on all formulas in Ax(F ), we conclude that F Fimp ut we then conclude F Fimp .

22


Afterwards, this new condition will re-define refinement correctness. Hence, from now, a refinement will be correct, if there exists a partition of axioms of refinement specifications satisfying the condition of Definition 4.4. Definition 4.5. (Integration) Let Sys = (F )in be a system specification. Let Fk Fimp where Fk = (SPk ; I nvk ; SPk0 ) with 1 k n. Let R = (ax' )'2Ax(F ) be a partition of Ax(Fimp coherent with the refinement. Let us Fimp℄R = (F i)in the system specification modulo R where: for every 1 i n, note Sys[Fk F i = (SP i; I nvi; SP 0 i) is defined by:

(

Sig SP i

) = minfX j X ,! Sig(SPi ) + Sig(Fimp ) ^8' 2 Ax(SPi ) \ Ax(Fk );

'

2 Sen(X )g

and Sig (F i ) = minfX j X ,! Sig (Fi ) + Sig (Fimp ) ^8' 2 Ax(Fi ) \ Ax(Fk ); ' 2 Sen(X )g where minfX j P (X )g means the least signature according to inclusion morphisms satisfying the property P .

I nv i

(

= I nvi

Ax SP i

) = Ax(SPi ) n Ax(Fk ) [

(F i ) = Ax(Fi ) n Ax(Fk ) [

Ax

[ [

'2Ax(SPi )\Ax(Fk )

'2Ax(Fi )\Ax(Fk )

ax'

and

ax'

Example 4.5. Regarding to the system presented in Example 3.2 and the refinement presented in Example 4.1, we only have to replace the required specification (B ; fB 1g) of both C W and C F B by (Bimp ; fB 1imp1 ; B 1imp2 g). From Definition 4.5, we have F k = Fimp . Moreover, the flat specification, noted Sysn [Fk Fimp ℄R which results of the integration of all feature specifications in Sys[Fk Fimp ℄R has then the following form: Sysn

[Fk

Fimp℄R = (Sig(Sysn ) + Sig(Fimp ); Ax(Sysn ) n Ax(Fk ) [ (

[ '2Ax(Sysn )\Ax(Fk )

ax'

))

From there, we obtain the expected result: Theorem 4.1. (Horizontal composition) If F Fimp , then: Sys

Sys[Fk

Fimp ℄R

Proof: . More generally, we have for any 1 i n As F Fimp , from Proposition 4.1, we have F Fimp that Fi F i . Therefore, by following the same approach than in the proof of Proposition 4.2, we can conclude Sysn (Sys[Fk Fimp℄R )n. ut This result naturally extends the local correctness of feature refinements to the level of specifications of feature systems.


Corollary 4.2.

(

(

)

! Sig(Sys[Fk

M od Sig Sys ,

4.2.2.

Fimp ℄R ))(M od(Sys[Fk

23

Fimp℄R )) M od(Sys).

Vertical composition

The vertical composition establishes a transitive closure of correct refinement relations. It is expressed by the following result: Theorem 4.2. (Vertical composition) The following rule is correct:

F F 0 F 0 F 00 F F 00 Proof: This is a direct consequence of Proposition 4.1.

ut

Remark 4.1. Uniquely from the hypothesis that Fimp is a correct refinement of F , both reduct functors Fimp℄R ) to M od(Sys) are [39]’s constructors from M od(Fimp ) to M od(F ) and from M od(Sys[F where the specification-building operation is the usual translate operation taken from [39]. Consequently, Theorem 4.1 and Theorem 4.2 can be directly obtained from the [39]’s vertical composition theorem.

4.3. Refinement and interaction To establish our preservation results, we have first to impose that the new vocabulary introduced by refinement has not been already introduced by some other features of the system. This gives rise to the notion of refinement compatible with system defined as follows: Definition 4.6. (Refinement compatible with system) Let Sys = (Fi )in be a system specification. Fk Fimp is said to be compatible with Sys if and only if for every 1 i n, Sig (Fi ) \ Sig (Fimp ) = Sig (Fi ) \ Sig (Fk ). Before giving our preservation results, let us start by proving three technical results which will be useful for our purposes: Lemma 4.1. For every feature logic L, we have: 1. 2. 3.

8 2 jSigj; + ; = 8; 0 2 jSigj; + 0 = ; ) = ; ^ 0 = ; 8; 0 2 jSigj; \ 0 = () ,! 0

Proof: 1. As + ; is the pushout of (; ,! ; ; ,! ; ), there is a unique morphism h : + ; ! such that h Æ ,! + ; = I d . h is uniquely factored as h = e Æ . Therefore, we have e = I d, and + ; ,! . As H omI defines a partial order, we conclude + ; = .

24


2. From the premise of the implication, we have Therefore, = ; and 0 = ; . 3.

! ; and 0 ,! ;.

,

But,

; is initial in I .

()) Obvious because from the hypothesis, we directly deduce \ 0 ,! 0 . (() By definition,

we have \ 0 ,! . Now, from both the hypothesis ,! 0 and the intersection is idempotent, we deduce that ,! \ 0 . As H omI defines a partial order, we conclude \ 0 = .

ut

Sys = (Fi )in be a system specification. Let Fk Fimp compatible with Sys. let R = (ax' )'2Ax(F ) be a partition of Ax(Fimp ) consistent with refinement. Therefore, we have:

Lemma 4.2. Let

(

Sig Sysn

) n Sig(Fi ) = Sig(Sysn [Fk

Fimp℄R n Sig(F i)

Proof: This can be proven by the following equivalences resulting from the distributive law of Definition 2.5, the compatibility condition and Lemma 4.1: Let us note Y = minfX j X ,! Sig (Fi ) + Sig (Fimp ) ^8' 2

(Fi ) \ Ax(Fk );

Ax

'

2 Sen(X )g

\ Sig(F i) = ; ^ X ,! Sig(Sysn [Fk Fimp℄R ) m X \ (Sig (Fi ) + Y ) = ; ^ X \ (Sig (Sysn ) + Sig (Fimp )) = X m X \ Sig (Fi ) = ; ^ X \ Sig (Sysn ) = X X

ut

Lemma 4.3. With all the notations of Lemma 4.1, we have:

Sys

Fi

(Sys[Fk

Fimp ℄R)F i

Proof: This results from Theorem 4.1 and Lemma 4.2.

ut

Theorem 4.3. (Partial results of preservation) Let Sys = (F )in be a system specification. Let Fk Fimp compatible with Sys. let R = (ax' )'2Ax(F ) be a partition of Ax(F )imp consistent with refinement. Therefore, we have the following set-theoretical inclusions: for every 1 i n such that Ax(Fi ) \ Ax(Fk ) = ;,

EP (Fi ;Sys) EP (F i ;Sys[Fk Fimp ℄R) \ Sen(Sig(Sysn )) NCP (F i;Sys[Fk Fimp ℄R) \ Sen(Sig(Fi ) NCP (Fi ;Sys)

Proof: Because Ax(Fi ) \ Ax(Fk ) = ;, we have Fi and Lemma 4.3.

= F i . Therefore, both inclusions result from Theorem 4.1

ut


25

We do not ensure results of preservation for features Fi which share with Fk some axioms because we have for them: Fi F i . This is a consequence of design choices the effect of which is to cut down model classes of specifications. Hence, these design choices can have naturally solved some interactions (e.g. en interaction due to non-determinism of a functionality which becomes deterministic through refinement), and then make non-conformance properties disappear through refinement steps. Now, we can also use refinement in order to restrict complexity of feature interactions through specification abstraction, and then obtain that all interaction studied at an abstract level are preserved at more concrete ones. Indeed, a feature specification can put many particular points forward, but only some of them are recognized to be sensitive to harmful interactions. The idea is then to abstract feature specifications by hiding the non-sensitive points. Consequently, from a feature specification F , we obtain a F . Here, any design choice has not been done. We saw feature specification Fabs satisfying Fabs previously that in this case a complete preservation of behaviors through refinement can be imposed. Here, because some axioms of F can be shared with other features in system, a more subtle condition than the one given in Definition 4.3 has to be imposed. This new form of completeness of refinement is expressed as follows: Definition 4.7. (Complete refinement revisited) Let F Fimp be a syntactic refinement. Let R = (ax')'2Ax(F ) be a partition of Ax(F ). Then, Fimp completely preserves the behavior of F with respect to R if and only if: 1.

(

M od Sig

(F ) ,! Sig(Fimp ))(M od(Sig(Fimp ))) = M od(F )

8' 2 Ax(F ); 8M 2 jM od(Sig(Fimp ))j; M j= ' , M j= ax' We will say then that R is complete with refinement. 2.

The first condition is the classic condition of completeness of refinement [18]. It implies the com plete preservation of behavior, that is: F = Fimp \ Sen(F ). But, this result is not sufficient for our purpose. Indeed, as any axiom ' 2 ax(F ) is replaced by a set ax' ax(Fimp ), a complete refinement has to satisfy the following property:

8' 2 ax(F ); (Sig(F ); ') = (Sig(Fimp ); ax' ) \ Sen(F ) The second condition of Definition 4.7 allows us to obtain such a result as expressed by the following result: Fact 4.1. From Definition4.7, we have:

8' 2 ax(F ); (Sig(F ); ') = (Sig(Fimp ); ax' ) \ Sen(F ) The completeness is extended to feature systems: Proposition 4.3. Let Sys = (F )in be a system specification. Let Fk Fimp compatible with let R = (ax' )'2Ax(F ) be a partition of Ax(F )imp complete with refinement. Therefore, we have: Sys

= Sys[Fk

Fimp ℄R \ Sen(Sig(Sysn ))

Sys.

26


Proof: . To \ Sen(Sig(Fk )). By Proposition 4.2, we have Fk Fimp In first, let us prove that Fk = Fimp 0 prove the opposite inclusion, let us consider for any pair ('; ' ) 2 Ax(Fk ) Ax(Fk ) a model M 2 jM od(Sig(Fk ))j such that M j= f'; '0 g. By Definition 4.7, there exists M0 2 jM od(Sig(Fimp ))j such that M od(Sig (Fk ,! Fimp ))(M0 ) = M. Therefore, M od(Sig (Fk ) ,! Sig (Fimp ))(M0 ) j= f'; '0 g. By the satisfaction condition, we have M0 j= f'; '0 g. Consequently, by Definition 4.7, M0 j= ax' [ 0 ax'0 , and then M j= . By the satisfaction condition, we conclude M j= . \ Sen(Sig (F )). By iterating this process on each formula in Ax(Fk ), we conclude Fk = Fimp For every 1 i 6= k n, we have also:

(Sig(Fi ); Ax(Fi ) \ Ax(Fk )) = (Sig(F i );

[

ax'

'2Ax(Fi )\Ax(Fk )

) \ Sen(Sig(Fi ))

Indeed, let ' 2 Ax(Fi ) n (Ax(Fi ) \ Ax(Fk )). Therefore, let us show:

(Sig(Fi ); (Ax(Fi ) \ Ax(Fk )) [ f'g) = (Sig((F i ); Let

2 (Sig((F i );

[

[

ax'

) [ f'g) \ Sen(Sig(Fi ))

'2Ax(Fi )\Ax(Fk )

ax'

) [ f'g) \ Sen(Sig(Fi )).

'2Ax(Fi )\Ax(Fk )

Let M 2 M od((Sig (Fi ); (Ax(Fi ) \ Ax(Fk )) [ f'g)). By Definition 4.7, there exists M0 2 jM od(Sig (F i ))j such that M. Therefore, we have:

(

M od Sig

(Fi )

! Sig(F i))(M0 ) =

,

(Fi ) ,! F i )(M0 ) j= (Ax(Fi ) \ Ax(Fk )) [ f'g By the satisfaction condition, we have M0 j= (Ax(Fi ) \ Ax(Fk )) [ f'g. Consequently, by Defini[ 0 ax' ) [ f'g, and then M j= .By the satisfaction condition, we conclude tion 4.7, M0 j= ( (

M od Sig

'2Ax(Fi )\Ax(Fk )

M j=

. By iterating this process, on each formula in Ax(Fi ) n (Ax(Fi ) \ Ax(Fk )) and Ax(Sysn ) n (Ax(Sysn ) \ Ax(Fk )), we show, respectively, both following equations: 1.

2.

(Sig(Fi ); (Ax(Fi ) \ Ax(Fk )) [ f'g) =

Sys

= Sys[Fk

(Sig((F i );

Fimp ℄R \ Sen(Sig(Sysn))

[

ax'

) [ f'g) \ Sen(Sig(Fi ))

'2Ax(Fi )\Ax(Fk )

ut

From Proposition 4.3, we obtain our expected result which states a complete preservation of interactions through refinement. Theorem 4.4. (Complete Preservation of interactions) Let Sys = (F )in be a system specification. Let Fk Fimp compatible with Sys. let R = (ax' )'2Ax(F ) be a partition of Ax(F )imp complete with refinement. Therefore, we have the following set-theoretical inclusions: 81 i n,


EP (Fi ;Sys) = EP (F i;Sys[Fk NCP (F i ;Sys[Fk

Fimp ℄R )

Fimp ℄R )

27

\ Sen(Sig(Sysn ))

\ Sen(Sig(Fi )) = NCP Fi;Sys

Proof: Both equations are simple consequences of Proposition 4.3.

ut

Hence, from Theorem 4.4, any new interaction which will occur at the concrete level will be directly connected to details which were previously hidden in the more abstract specification.

5. Related work There exist many formal works dealing with both problems of feature design and interaction detection. The most of these works follow the design approach which have been defined in the present paper, that is specifying a feature as modifying/extending some existing features in systems [7, 11, 13, 14, 22, 28, 31, 34, 35, 36, 42]. Most of them directly use for specifying both features in isolation and feature systems, either the semantical model of automates [11, 27, 34, 42] , or a modal logic such as dynamic or temporal logic, semantics of which is expressed from automates or more generally from Kripke models [12, 14, 35, 36], or some restrictions of the first order predicate logic [22, 41]. The problem of feature integration strongly depends on specification semantics. For instance, when dealing with automates, feature integration is based on composition techniques such as superimposition [35, 36, 44]. For most of these works, the correctness of integration then consists in verifying, as in our framework, that each of requirements of feature specifications are preserved. Hence, any requirement which is not preserved through feature integration is noted as harmful. In the literature such interactions are called interference. For most of these works, interferences are usually the only looked for interactions. For interactions without undesirability criterion, we have seen in Section 3, that their set is usually infinite. This is our both sets of emerging and non-conformance properties. An exhaustive search of such interactions is then impossible. To answer such an impossibility, some works define critical criteria which are specific to the application domain under consideration. For instance, we can cite among the more critical problems, the one of shared resource contention, or read/write contention of some data, or deadlocks in systems [2, 10, 21, 30, 37]. These criteria have been used to select the set of interactions which satisfy them. On no account detected interactions are considered as undesirable. They only characterize the borderline cases to check because they are recognized as problematic in the application domain under consideration. Up to our knowledge, only in D. Cansell and D. Méry’s works [12, 13] refinement techniques are used to deal with the feature interaction problem at every specification level, although this problem has been recognized as essential in the domain [26]. The idea of the authors is to modelize the integration of features through the refinement operation of abstract machines of the specification language B [1]. Hence, harmful interactions are the consequences of a breaking of the refinement correctness defined by a behavior preservation. Here again, detected interactions are only interferences.

28


6. Conclusion In this paper, we have presented an abstract framework which allows one to specify feature systems and formally defining both integration and interaction problems. Our approach has been to define such a logic in a generic way, that is describing a formal methodology which defines how to extend any logic satisfying some requirements in a feature logic. From such feature logics, feature have been defined by a set of invariants of the existing system that the feature of interest ensures to preserve, and a set of properties specifying its behavior. Integration of features in an existing system is correct if the resulting system has at least an un-trivial model. Finally, an interaction between a feature and a system on which the feature has been integrated, occurs when one of both underlying sets emerging and non-conformance properties is non-empty. Emerging and non-conformance properties denote behaviors in addition and in less, respectively, than scheduled by the specification of the feature of interest. A theory of feature refinement has also been defined for such feature logics. If such a refinement is correct (i.e. all realizations of the system used for refinement can simulate the behavior of the refined object), then the refined feature can be replaced by its refinement in the system, and preserves the global behavior of the system. Moreover, we have studied feature interaction preservations through refinement. We have shown that without supplementary conditions emerging properties are preserved, but some nonconformance properties can disappear. This is due to design choices which cut down the model class. Therefore, in order to obtain a complete preservation of interaction through refinement, we have given two sufficient conditions which ensure such a result. Several research issues still need to be explored. Among of them, the main ones are: 1. extending the refinement in order to refine a feature specification by a feature system specification. This will certainly require to find again the usual distinction between intermediate and implementing specifications. Intermediate specifications will then characterize an enrichment of other feature specifications used in the refinement. It will be integrated last in the refining system. 2. taking benefits of our logic-independent setting to investigate towards other techniques well-studied in this framework such as functional testing. Indeed, we have seen that both sets of emerging and non-conformance properties are usually infinite. Therefore, this prevents to study exhaustively all interactions. This is close to functional testing, mainly with techniques to select tests from specifications.

References [1] J.-R. Abrial. The B book - Assigning Programs to Meanings. Cambridge Universuty Press, 1996. [2] P.-K. Au and J.-M. Atlee. Evaluation of a state-based model of feature interactions. In P. Dini, R. Boutaba, and L. Logrippo, editors, Feature Interactions in Telecommunications Networks, pages 153–167. IOS Press, 1997. [3] M. Barr and C. Wells. Category Theory for Computing Science. Prentice-Hall, 1990. [4] H. Baumeister. Relations between Abstract Datatypes modeled as Abstract Datatypes. PhD thesis, University of Saarlandes, 1998.


29

[5] H. Baumeister and A. Zamulin. State-based extension of casl. In W. Grieskamp, T. Santen, and B. Stoddart, editors, Intergrated Formal Methods (IFM), volume 1945 of Springer, pages 3–25. Springer, 2000. [6] M. Bidoit. The stratified loose approach: a generalisation of initial and loose semantics. In Recent Trends in Data Type Specification, Lecture Notes in Computer Science, pages 1–22. Springer, 1987. [7] R. Bol, J. Blom, and L. Kempe. Automatic detection of feature interactions in temporal logic. In K.-E. Cheng and T. Otha, editors, Feature Interactions in Telecommunications (FIW), pages 1–21. IOS Press, 1995. [8] T. Borzyszkowski. Logical systems for structured specifications. Theoretical Computer Science, 2002. paraitre. [9] L.-G. Bouma and K. Kimbler, editors. Feature Interactions in Telecommunications and Software Systems. IOS Press, 1998. [10] K.-H. Braithwaite and J.-M. Atlee. Towards automated detection of feature interactions. In L. Bouma and H. Velthuijsen, editors, Feature Interactions in Telecommunications Systems (FIW), pages 36–59. IOS Press, 1994. [11] J. Brederek. Formal criteria for feature intercations in telecommunications systems. In V.-B. Iversen and J. Norgaad, editors, IFIP International Working Conference on Intelligent Networks, pages 83–97, 1995. [12] D. Cansel and D. Mry. Abstraction and refinement of features. In [24], pages 65–84. [13] D. Cansell and D. Mry. Playing with abstraction and refinement for managing features intercations - a methodological approach to feature interaction problem. In A. Galloway, J.-P. Bowen, S. Dunne, and S. King, editors, ZB2000, volume 1878 of Lecture Notes in Computer Science. Springer, 2000. [14] F. Cassez, M.-D. Ryan, and P.-Y. Schobbens. Proving feature non-interaction with alternating-time temporal logic. In [24], pages 85–105. [15] R. Diaconescu, J. Goguen, and P. Stefaneas. Logical support for modularization. In G. Huet and G. Plotkin, editors, Logical Environments, pages 83–130, 1991. Prooceedings of Workshop on Logical Frameworks. [16] P. Dini, R. Boutaba, and L. Logrippo, editors. Feature Interactions in Telecommunication Networks. IOS Press, 1997. [17] H.-D. Ehrich. Algebraic Foundations of Systems Specification, chapter Object specification, pages 435–465. IFIP State-of-the-Art Reports. Springer, 1999. [18] H. Ehrig and H. Kreowski. Algebraic Foundations of Systems Specification, chapter Refinement and implementation, pages 201–243. IFIP State-of-the-Art Reports. Springer, 1999. [19] E.-A. Emerson. Handbook of Theoretical Computer Science, chapter Temporal and Modal Logic, pages 995–1073. Elsevier, 1990. [20] FIREworks. Feature integration in requirements engineering, 1997-2001. ESPRIT Working Group 23531. [21] M. Frappier, A. Milli, and J. Desharnais. Detecting feature interactions on relational specifications. In P. Dini, R. Boutaba, and L. Logrippo, editors, Feature Interactions in Telecommunications Networks, pages 123–137. IOS Press, 1997. [22] A. Gammelgaard and J.-E. Kristensen. Interaction detection, a logical approach. In L. Bouma and H. Velthuijsen, editors, Feature Interactions in Telecommunications Systems (FIW), pages 178–196. IOS Press, 1994. [23] C. Gaston, M. Aiguier, and P. Le Gall. Algebraic treatment of feature-oriented systems. In [24], pages 105–125. [24] S. Gilmore and M.-D. Ryan, editors. Language Constructs for Decsribing Features. Springer, 2000.

30


[25] J.A. Goguen and R.-M. Burstall. Institutions: Abstract model theory for specification and programming. Journal of the ACM, 39(1):95–146, 1992. [26] D.-O. Keck and J. Kuehn. The feature and service interaction problem in telecommunication systems: A survey. IEEE Transactions on Software Engineering, 24(10):779–796, 1998. [27] A. Khoumsi. Detection and resolution of interactions between services of telephone network. In [16], pages 78–92. [28] F. Klay, M. Rusinowitch, and S. Stratulat. Analysing feature interactions with automated deduction systems. In 7th International Conference on Telecommunication Systems, Modelling and Analysis (ICOTS), pages 542–554, 1999. [29] S. Mac Lane. Categories for the Working Mathematician. Graduate Texts in Mathematics. Springer, 1971. [30] A.-Y.-H. Lee. Formal Specification and Analysis of Intelligent Network Services and Their Interaction. PhD thesis, University of Queensland, Australia, 1992. [31] F.-J. Lin and Y.-J. Lin. A building block approach to detecting and resolving feature interactions. In L. Bouma and H. Velthuijsen, editors, Feature Interactions in Telecommunications Systems (FIW), pages 86–119. IOS Press, 1994. [32] D. Mry, D. Cansell, and S. Merz. Predicate diagrams for the verification of reactive. In T. Santen, W. Grieskamp, and B. Stoddart, editors, Integrated Formal Method (IFM2000), volume 1945 of Lecture Notes in Computer Science, pages 380–398. Springer, 2000. [33] F. Orejas. Algebraic Foundations of Systems Specification, chapter Structuring and Modularity, pages 159– 201. IFIP State-of-the-Art Reports. Springer, 1999. [34] T. Otha and T. Yoneda. A formal approach for definition and detection of feature interaction. In [9], pages 202–216. [35] M. Plath and M.-D. Ryan. Plug-and-play features. In [9], pages 150–164. [36] M. Plath and M.-D. Ryan. Feature integration using a fetaure construct. Science of Computer Programming, 2000. [37] K.-P. Pomakis and J.-M. Atlee. Reachibility analysis of feature interactions: A progress report. In Proceedings Int’l Symp. Software Testing and Analysis (ISSTA’96), pages 216–223, 1996. [38] A. Salibra and G. Scollo. A soft stairway to institutions. In M. Bidoit and C. Choppy, editors, Recent Trends in Data Type Specification, volume 655 of Lecture Notes in Computer Science, pages 310–329. Springer, 1993. [39] D. Sannella and A. Tarlecki. Toward formal development of programs from algebraic specifications: implementations revisited. Acta Informatica, 25:233–281, 1988. [40] A. Sernadas, C. Sernadas, and C. Caleiro. Fibring of logics as a categorial construction. Journal of Logic and Computation, 9(2):149–179, 1999. [41] B. Stepien and L. Logrippo. Representing and verifying intentions in telephony features using abstract data types. In K.-E. Cheng and T. Otha, editors, Feature Interactions in Telecommunications (FIW), pages 141– 157. IOS Press, 1995. [42] S. Stratulat. Preuves par rcurrence avec ensembles couvrants contextuels. Applications la vrification de logiciels de tlcommunications. PhD thesis, Universit Henri Poincar - Nancy 1, 2000. [43] VALISERV. Validation de services de tlcommunications : dtection incrmentale d’interactions par le test, 2000-2004. French project RNRT.


31

[44] N. Zuanon. Modular feature integration and validation in a synchronous context. In [24], pages 213–231. [45] E. Zucca. From static to dynamic abstract data-types. In W. Penczek and A. Szlas, editors, Mathematical Foundations of Computer Science (MFCS’96), volume 1113 of Lecture Notes in Computer Science, pages 579–590. Springer, 1996. [46] E. Zucca. From static to dynamic abstract data-types: An institution transformation. Theoretical Computer Science, 216(1/2), 1999.