feature specification: a logic-independent approach

Fundamenta Informaticae XX (2004) 1–31 1

IOS Press

Feature specification: a logic-independent approach

Marc Aiguier 1, Christophe Gaston2 and Pascale Le Gall1�1Universite d’Evry, LaMI CNRS UMR 8042,

523 pl. des Terrasses F-91000Evryfaiguier,legallg�lami.univ-evry.frfax number: (+33) 1 60 87 37 892CEA/DRT/LIST/DTSI/SLA Saclay

F-91191 Gif sur Yvette Cedexf hristophe.gaston�ortolan. ea.frg� ea.fr

Abstract. In this paper, we investigate the formal specification of features and feature systems inthe mathematical paradigm often called “logic-independent”, and formally capture in this paradigmthe 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. Todeal 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 sucha refinement in order to deal with the complexity of feature interaction, which is one of the mainproblem encountered when dealing with feature interactiondetection. The study of interactionsthrough implementation is still n open problem. The presentpaper furnishes answers to encounterthis 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 projectVALISERV and by the European Commission under WGsFireworks (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 beenrapidly confronted with their constant update. In these newapplications, update of softwares is not theresult of a discovery of “bugs” in associated programs but rather a natural evolution of these programs inorder to answer new requirements from users. Hence, softwares were no longer monolithic entities butare both opened and adaptable objects led to incorporate newservices(features) not initially foreseen bydesigners. Although this problem is not new in applied software engineering, it has been considered byresearchers 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 companieswhich become aware of economical impacts of such update activities. Indeed, in telecommunicationsystems, services correspond to new capabilities offered to users, and more and more services are offeredby them. The primary motivation to offer new services to users seems to be that they differentiateproviders, and are significant sources of revenue in their own right. Consequently, a badly designedfeature can have calamitous consequences from an economical point of view. Now, this notion of featureis recognized to be not limited to telecommunication systems. Any part or aspect of a specification whichhas a self-contained functional role can be viewed as a feature.

The main problem with feature design is that features are seldom designed independently of eachother. Consequently, unexpected behaviors can occur. These unexpected behaviors are calledinterac-tions. To illustrate the notion of interaction, let us consider the featurecall forward when busy(C.F.B.)which consists in allowing any of its users to forward all incoming calls to another specified phoneof one’s own choosing. Of course, such a service modifies the basic telephone feature (usually calledP.O.T.S. for Plain Old Telephone Service). Indeed, when theuser phone is already engaged, P.O.T.S. in-dicates this fact by a peculiar tone in handset. To leave telecommunication examples, we can also cite thelift case equipped with the basic service which consists in answering users’s requirements by respectingthe order of their occurring, and the feature which indicates a priority floor. An expected property of thebasic feature is that all requirements will be eventually satisfied. However, the feature of priority floorcan question this liveness property (see Section 3.2).

It is clear that adding new behaviors in softwares requires first to check the consistency of result-ing softwares (i.e. softwares obtained after having integrated these new behaviors). Indeed, these newbehaviors can be incompatible with existing features. A consequence of such incompatibilities is the im-possibility to extend softwares in order to answer these newrequirements. Moreover, adding a consistentfeature does not prevent to modify the previous specified behaviors. Therefore, these modifications havealso 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 checkingthat systems enriched with new features yield again existing features as well as the new ones, at least asthey are explicitly specified. On the contrary, the problem of feature interaction is more disconcerting

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

because it questions the modularity principles usual in formal software engineering based on a completepreservation of behaviors of modified systems (see [33] for astate-of-the-art on this subject). Checkingthe 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 globalsystem. Here, the difficulty is that we accept to question behaviors of systems. The problem is then tocheck this questioning by trying to prevent “bad” behaviors. The question is:what is a bad behavior?Inthe framework of a modular approach, answering this question is obvious because quantitative. Indeed, abad behavior is any new property satisfied by the enriched system and that was not yielded previously. Onthe contrary, in the framework of feature design, answeringthe previous question becomes qualitative,and then prevents to give a rigorous definition to this notionbut rather is a matter for subjectivity exclusiveto anyone. Let us illustrate this remark by an example. Let usconsider a phone system equipped withthe two following features:

1. Terminating Call Screening(T.C.S.) which enables a subscriber to automatically refuse all incom-ing 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, respec-tively. 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? Fromthe point of view of B, this scenario canbe supposed to be undesirable. But, from the point of view of A, preventing such a behavior consistsin reducing 3W.C.’s potentialities, and then can be undesirable. From this, we notice that deciding thequalitative nature (bad—good) of feature interactions is an expert matter. One may well wonder the use-fulness 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 ofthem which seem of the greatest importance to us:

1. every company designing softwares, attempts to control its development costs. But, formal meth-ods are usually together with verifying tools whose some of them are automatized, what is benefi-cial for development costs.

2. Verifying working-order of systems is a hard task which often requires rigorous methods in orderto verify many (usually infinite)scenarioof interactions. In this way, formal methods are rightcandidates 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 mayenable us to address interactions at the levels they emerge from, and then reduce complexity ofinteraction analysis procedure.

Many formal works have been developed to deal with both feature interaction and integration analysisin 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 differentnotions of feature conception which are feature, feature system, integration and interaction problems.


However, there is not consensus on modelized notions and mainly on the notion of feature interaction (seerelated works in Section 5). The nature of detected interactions strongly depends on the used formalismand mainly of associated tools (model-checking, formal proofs, testing,...). Therefore, in order to takeinto account all the forms of interaction, defining these notions in a generic way, that is in a logic-independent framework, can be necessary. But, is such a generic formalization possible? Key notionsof feature oriented design could rely on dedicated aspects which cannot be easily abstracted as thisis the case for the object-oriented design [17]. Indeed, thenotions of states, object identity, methodand message-passing are hardly modelizable in a logic-independent framework1. Concerning feature-oriented design, such a generic formalization is possible.Indeed, the feature notion only defines a newform of structuring of software systems through features they do. No other aspect is attached except therole of features in system structuring. Therefore, we can disregard underlying formalism and focus uson the role of features in structuring. In this way, featuredesign, on its syntactic aspects, is closed tomodular design. Therefore, as this has been widely done for the modular approach [33], an institution-like framework [25] seems adequate to define generic featuresystems. We propose then, in this paper,to extend any logicL presented under its institutional form into a logic dedicated to the feature-orientedconception. The interest here is twofold:

1. we provide for both designers and users of logics, a methodology to specify and to study featuresystems and their interactions systematically. Hence, we prevent the authors and users of suchlogics 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 meansof syntactical extensions of feature specifications and systems. Semantics of such notions will bealways interpreted through the functorMod and the validation relationj= of the extended logicL(see Section 2 for a succinct presentation of the theory of institution). Consequently, all associatedverification tools will be able still to be used to check correctness of feature systems and studyfeature interactions.

All the definitions and theoretical notions presented in this paper will be examplified with the telecom-munication system composed of the services POTS, CW and CFB.This system will be specified inCTL� [19]. Another example of formalism which fits with all requirements of feature logics togetherwith 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 introduc-tory chapters of a textbook on the subject [29, 3].

The paper is organized as follows: Section 2 introduces basic requirements we expect from a formal-ism to be used for feature design. In Section 3 we define in any logic satisfying the basic requirements

1Actually, 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 ofinstitutions, more or less extensions of temporal logics. Regardingobject states, recently, some works have been proposed where states can be structured from any suitable institution [46, 4], andproperties on dynamic aspects are expressed as pre- and post-conditions on compositions of dynamic operations [45, 4, 5].


previously stated, calledfeature logic, the notions of feature specification, feature system, feature inte-gration and feature interaction. In Section 4, we define a refinement theory in the generic frameworkof feature logic, and show how to use such a theory to facilitate the search of feature interactions insoftware 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 toSection 6.

2. Base feature logic

Herein, we start by defining the basic requirements that a formalism has to satisfy to be extended into alogic dedicated to feature design.

In order to define a generic version (i.e. logic-independent) of the feature paradigm, we follow thebasic 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 usto state properties denoting behaviors that we want to satisfy on a system. These properties have to beunmistakable in an unequivocal way. Therefore, they have tobe defined formally. The whole set ofproperties to satisfy is usually called aformal specification, and the statement of a property is called asentence. In practice, syntactic part of a logic is based on inductiveconstructions of formulas from givensymbols. Classically, the set of these symbols is called asignature. Symbolic treatment of propertiesis not sufficient to deal with the correctness of systems. Indeed, they are only un-meaningful sequencesof symbols. Then, we have to give a corresponding meaning “inthe real world” to phenomena that wewant to guarantee. To achieve this purpose, we have to rigorously modelize the real world, and then toconsider mathematical models that represent possible abstractions of this real world. Finally, we have tobe able to denote among all sentences, properties which are satisfied by these models. This part is usuallycalledsemantics. This last part is fundamental in the sense that it allows to deal with the correctness ofsystems “scientifically”. However, it is not sufficient. Indeed, a fundamental aspect of formal softwareengineering is to automatically check the correctness of softwares. Hence, the question is:How toautomatically check (or prove) that a sequence of symbols isa property satisfied by our software?Forthis purpose, we have to define how to manipulate formulas andhow these manipulations lead to obtainthe truth of a property. We usually call these manipulationsinference rules, and we talk aboutcalculus.

Institutions only concern both syntactical and semanticalaspects of alogical system. To abstractthe notion oflogical system, the authors in [25] define a signature simply as an element ofa category.Therefore, sentences associated to a signature are simply defined as a set. All other computable con-tingencies 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 tothem. To characterize properties satisfied by a class of models, a binary relation between models andsentences, calledsatisfaction relationand denoted “j=”, is defined. More formally, an institution is thendefined as follows:


Definition 2.1. (Pre-institution [38])A pre-institutionI is defined by a categorySig of signatures provided with, for each signature�, aset-valued functorSen : Sig ! Set yielding the�-sentences, a category-valued contravariant functorMod : Sigop ! Cat yielding the�-models, and aSig-family j= of binary relationsj=�� jMod(�)j �jSen(�)j.

Within the framework of institutions, a supplementary condition, called thesatisfaction condition,is added to formalisms. This condition expresses that properties are preserved through signature mor-phisms. Formally, this is expressed as follows:

Definition 2.2. (Institution)An institutionI is a pre-institution satisfying the following property:8� : �! �0; 8M 2Mod(�0); 8' 2 Sen(�); M j=�0 Sen(�)('),Mod(�)(M) j=� '

Specifications in the small are defined as usual.

Definition 2.3. (Flat specification)Given a feature logicL = (Sig; Sen;Mod; j=), aL-specificationSP is defined by a signature� anda setax of formulas inSen(�). Given aL-specificationSP = (�; ax), we noteMod(SP ) the fullsub-category ofMod(�) whose objects are all�-modelsM such that for any' 2 ax, M j=� '.Finally, we noteSP � the subset ofSen(�), so-calledsemantic consequences ofSP , defined as follows:SP � = f' j 8M 2 jMod(SP )j; M j=� 'g.

One of consequences of the satisfaction condition is that wecan restrict the functorMod(�) to thecategory of specifications as expressed by the following result:

Proposition 2.1. If L is an institution, then for anyL-specification morphism� : SP1 ! SP2 (i.e.� : �1 ! �2 andSen(�)(ax1) � ax2) we haveMod(�) : Mod(SP2)!Mod(SP1) is a functor.

Proof:Let ' 2 ax1 andM 2 Mod(SP2). As Sen(�)(ax1) � ax2, we haveM j= Sen(�)('). Therefore,from the satisfaction condition, we concludeMod(�)(M) j= '. utCorollary 2.1. If L is an institution, then for every specification morphism� : SP1 ! SP2, we haveSen(�)(SP �1 ) � SP �2 .

Proof:Let SP1 j= '. Let M 2 Mod(SP2). As L is an institution, by Proposition 2.1,Mod(�)(M) 2Mod(SP1). Therefore,Mod(�)(M) j= '. By the satisfaction condition, we concludeM j= Sen(�)(').utAnother simple consequence of the satisfaction condition is the following:

Proposition 2.2. (Cut)If L is an institution, then for everyL-specification(�; Ax) and every� � Sen(�), we have:� � (�; Ax)� =) �� (�; Ax)�


Proof:Simple consequence of Definition 2.3. ut

The satisfaction condition is very useful for modularity purposes. Indeed, it ensures one of the twoways of the modularity (so-calledmodularity by restrictionin [6]) which expresses that a “complex”system can be used for simpler purposes2. However, one of the particularity of the feature paradigmis the ability to “break” the modularity. This ability is desired in order to keep a flexible conception.The consequence is that some unexpected behaviors (relatedto the existing system) can occur (featureinteraction problem). Therefore, we will see in Section 3 that imposing the satisfaction condition mayprevent 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 commoninformations issued from the basic system. Consequently, the joint integration of two featuresF1 andF2 has to take into account some symbol sharing. At the signature level, this means that the signature ofa system which has the two featuresF1 andF2, has to contain the union ofF1 andF2 signatures. Thuswe need the categorical notion for the union on signatures.Classically, the categorical concept of pushout and more generally finite colimit provides the abstractbasis 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,

even though we take the category of sets usually denotedSet. Indeed, given a pushoutS0 g1��! S1g2??y ??yS2 ��! S inSet, arrowsg1 andg2 may not be inclusions (by the way nor injections) and then both S0 may not be the

intersection ofS1 andS2 andS the union ofS1 andS2.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 morphismsdenoting inclusions. However, the usual definition of unionthroughout a pushout is only up to isomor-phism. Intuitively, this means that this approach allows torename symbols in the signature�1 [�2.

In our context, we prefer that the notion of union of signatures avoids renaming. Indeed, a featuregenerally characterizes the behavior of a new functionality. Thus, its description introduces just a fewnew symbols. The greatest part of used symbols refers to already existing functionalities, whose somebehaviors can be modified. To obtain this result, we use the axiomatization of the notion of inclusiongiven 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).

Let us recall the axiomatization of the notion of inclusion given in [15] :

Definition 2.4. A categoryC is strongly inclusiveif and only if C is a category with pullbacks and thereexists two sub-categoriesI andE of C such that:

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


1. jIj = jEj = jCj;2. anye 2 HomE is epic;

3. every morphismf in C can be factored uniquely as� Æ e with � 2 I ande 2 E ;

4. HomI defines a partial order onC and the poset(jCj;HomI) is a lattice where the sup ofA andB is the sum ofA andB, denotedA+B, and the inf ofA andB is the unique inclusion pullbackin C of the sum, calledintersectionof A andB and denotedA\B (both existence and uniquenessof A \B are given in [15]). Moreover, we impose onA+B to be the pushout ofA \B.

The morphisms inI are calledinclusionsand the pair(I; E) is called theinclusion systemof C. After-wards, we will use the notationA ,! B to denote the morphism� : A! B in HomI(A;B).Remark 2.1. Sum and intersection are unique and the full sub-category whose morphisms are inclusionsis finitely cocomplete(see [15] for the complete proofs of these results).

Example 2.1. As an example, the categorySet provides with the inclusion system(I; E) whereI con-tains all the inclusions andE contains all the surjections is trivially strongly inclusive. Indeed, given

a pushoutS0 g1��! S1g2??y ??yS2 ��! S in Set with S0 = S1 \ S2 and all arrows are inclusions,S denotes the set-

theoretical union ofS1 andS2 (i.e. S = S1 [ S2). This pushout is also a pullback, soS1 [ S2 is thepushout ofS1 \ S2.2.3. Feature logic

To deal with feature conception, we add to the quadruple(Sig; Sen;Mod; j=) some properties in orderto deal with the concepts of inclusions, intersections and unions of signatures. Moreover, we impose thatthe functorSen maps all inclusion morphisms� 2 I to the set-theoretic inclusion inSet between setsof formulas. This last condition is usually satisfied (anyway all logics that are widely used in computingscience and mathematics satisfy it). Feature logics are then defined by:

Definition 2.5. (Feature logic)A feature logicis a pre-institution(Sig; Sen;Mod; 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 inI. Finally, intersection is distributive with respect tosum, that is:8�;�0;�00 2 jSigj; � \ (�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 inSection 4.3.


Example 2.2. (CTL� as an institution)CTL� [19] is a branching-time temporal logic where the structurerepresenting all possible executionsis tree-like rather than linear. It is well-adapted to specify and reasonabout non-deterministic and/orconcurrent process. When dealing with propositional fragment of logics, a signature is only a set ofpropositional variables. ThusSigCTL� is simply the categorySet. Therefore, the most natural inclusionsystem forSigCTL� is (ICTL� ; ECTL�), whereICTL� contains set-theoritical inclusions andECTL� con-tains 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�-modelM is given by a setS of states, a binary relationR � S � Ssatisfying: 8s 2 S;9s0 2 S; s R s0, and a total functionL : S ! P(�) called labelling function.Therefore,�-models are labelled transition systems whereR denotes the transition relation andL is thelabelling associating for each states of S the set of propositional variables true ats. For any signature�, we noteModCTL�(�) the category whose objects are all�-models and whose morphisms betweentwo �-modelsM = (S;RS ; LS) andM0 = (S0; RS0 ; LS0) are total functionsf : S ! S0 compatiblewith relation and labelling functions. Now for all signature morphism� : � ! �0, ModCTL(�) :ModCTL(�0)!ModCTL(�) is the functor defined byModCTL�(�)((S0; R0S0 ; L0S0)) = (S0; R0S0 ; LS0)where for alls 2 S0; LS0(s) = fp 2 �n�(p) 2 L0S(s)g.A �-axiomis a well-formed formula whose the syntaxical rules are given by:CTL� ::= ATOM j CTL� ) CTL� jX CTL� j G CTL� j F CTL�CTL� U CTL� j 8CTL� j 9CTL�ATOM ::= p j ?p being any propositional variable of�. We noteSenCTL�(�) the set of all the�-axioms.Because well-formed formula inCTL� are inductively defined from a set of propositional variables, forevery signatures� � �0, we trivially haveSen(�) � Sen(�0).

For every� 2 jSigj, let us notej=�� Mod(�)� Sen(�) the relation defined by:M j=� ' if andonly if for any sequence� = (s0; s1; : : : ; sn; : : :) wheresi R sj for everyi < j (runs),(M; �) j=� 'where(M; �) j=� ' means, for anyi 2 N, let us note�i the subsequence(si; si+1; : : : ; sn; : : :) of �,� (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 existsi 2 N, (M; �i) j=� ';� (M; �) j=� '1 U '2 iff there isj 2 N s.t. (M; �j) j=� '2 and for allk < j 2 N (M; �k) j=�'1;

10 M. Aiguier et al. / Logic-independent feature specifications� (M; �) j=� 8' iff for any run�0 starting tos0,(M; �0) j=� ';� (M; �) j=� 9' iff there exists a run�0 starting tos0,(M; �0) j=� ';

Let us notej=CTL� the family of relationsfj=�g�2jSigCTL� j. Then, the quadrupleLCTL� = (SigCTL� ; SenCTL� ;ModCTL� ; j=CTL�) is an institution. Indeed, the satisfaction condition holds because no pruning is done on sets of statesthroughout signature morphisms.

3. Formal specification of feature systems

3.1. Feature specification and their integration

Let us consider a feature logicL = (Sig; Sen;Mod; 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 previoussection. In this example, we have seen that T.C.S. directly modifies the behavior of P.O.T.S. (the basicphone service). Indeed, the behavior of P.O.T.S. consists in describing how two physical phones canbe connected together. Hence, when someone dials a phone number whose the associated phone is freethen a ringing indicates this and if someone takes off the hook, a communication can be engaged. Thefeature T.C.S. directly questions this basic behavior by modifying the property that every incoming callon a free phone is indicated by a ringing. Indeed, if a black list of phone numbers has been drawn upby a subscriber A, any incoming call from one of such phone numbers is not indicated by a ringingon A’s physical phone anymore. On the contrary, all the otherproperties of P.O.T.S. are preserved byT.C.S. Therefore, let us consider a formula'(X;Y ) of the specification of P.O.T.S. that gives the basicproperties specifying how to engage a communication from X to Y. A generic description of T.C.S. couldbe the following:

1. :t s?(Y ) ) '(X;Y )2. t s?(Y ) ) (X;Y )wheret 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 Yby respecting T.C.S.’sconstraints. Regarding this example, we can see that a feature specification only makes sense withrespect to the system where it will be plugged on. Hence, a feature is a basic element of design whichincludes a strong partial knowledge of the system specification on which we plan to plug it on. Thispartial 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 someproperties are preserved. For instance, the fact that all phone calls have to be paid by someone, will neverquestion. 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 tothe following representation of feature specifications:

M. Aiguier et al. / Logic-independent feature specifications 11� an enrichment of the system signature to modify in order to characterize the addition of newfunctionalities (e.g. the addition of the predicatet s?),� a modification of some axioms (e.g. removing'(X;Y ) and replacing it by both above implica-tions), and� a set of properties which have to be preserved, calledinvariants.

This gives rise to the following definition:

Definition 3.1. (Feature specification)A feature specificationF is a triple(SP; Inv; SP 0) such thatSP = (�; Ax) andSP 0 = (�0; Ax0) arebothL-specifications, etInv � Sen(�). Moreover, this triple satisfies both following conditions:

1. � ,! �0, and

2. Inv � SP � \ SP 0�.SP is called therequired specificationof F . Elements inInv are calledinvariants.

In practice, the required specification is often restrictedto the basic feature or very few ones. Moreover,the basic behaviors that the feature under specification aims at modifying and to preserve, usually makea partition of the set of axioms of its required specification.

Hence, the setInv contains the invariants that we want to preserve after the integration of the featureF as expressed by the second condition in Definition 3.1. Therefore, this last property can be seen as thefeature correctness.

Remark 3.1. The definition of a feature specification is closely related to the notion of correct refinementin the classic sense of algebraic specifications [18]. Indeed, we can see a feature specification as acorrect refinement of the specification(�; Inv) defined in terms of a signature morphism together witha preservation of the behavior (represented byInv).

A feature system specification will then be a set of feature specifications. However, this is not suf-ficient. Indeed, semantics of specifications can only be defined from flat specifications because modelsdo not take into account structuring. Therefore, we have to associate to any set of feature specificationsa ”flat” L-specification. The key question is how to define such a flatL-specification provided with anadequate semantic counterpart. A first answer might be to consider the union of all axioms issued fromthe different features of the system under analysis. However, this is not the good solution. Indeed, letus recall that each feature is defined as possibly modifying the behavior of the existing system (moreprecisely, a subpart of it) where it will be plugged on. Thus,any system obtained would be lucky enoughto be inconsistent. The good answer is to provide the system with an order of integration compatiblewith the requirements of each feature. Hence, a featureF2 has to be integrated after a featureF1 if therequired specification ofF2 depends onF1. Concerning two independent features, this order is arbitraryand then is left to specifier’s free will. Moreover, it is easyto see that this free will has no consequenceon the resulting flat specification obtained by following anyintegration order satisfying the above basicrequirements.


Definition 3.2. (Feature system Specification)A feature system specificationSys is a finite sequence(Fi)i�n of feature specifications. The first featurespecificationF0 of Sys is necessarily of the form((�;; ;); ;; SP ). It is called thebasic feature3.

Example 3.1. Here, we present a small example of a specification of a feature system inCTL�, includ-ing a simplifiedbasic telephonefeatureB, a call waiting featureCW and acall forward when busyfeatureCFB, whose meaning will be discussed in their respective associated sections.

The basic telephone system featureB: Due to the lack of space, we cannot present the whole speci-fication of thebasic telephonefeature. The feature we present here, will only express the unique axiomwhich is required by the featuresCW andCFB. There areN phones involved in the basic system. Thebasic telephone featureis of the formB = (((�;; ;); ;;�; ,! �B); axB) where�; denotes the emptysignature and :� �B = Si6=j�N 8><>: Free PiPi alls PjPi refuses Pj 9>=>;� axB only contains the following axiom schematas:

B1 : 8(G(Pi alls Pj ^ :Free Pj ! 8X (Pj refuses Pi)))Axiom B1 expresses that whenever a call of sourcePi and targetPj is done, ifPj is not free, thenthe call will be refused in the next state.

The call-waiting feature CW : When a phonePj is not free,CW allows it to put on hold any callerPi (Axiom CW1). When this is the case then possibly the two phones can get engaged at the next time(Axiom CW2), but this will not happen if one of the two phones becomes free (Axiom CW3). ThefeatureCW is of the formCW = (((�B ; fB1g); ;;�B ,! �CW ); axCW ) where:� �CW = �B [ Si6=j2f1;2;3g fPi holds Pjg� axCW is the set containing the three following axioms schematas :

CW1 : 8(G(Pi alls Pj ^ :Free Pj ! 8X (:Free Pi ^ :Free Pj ^ Pj holds Pi)))CW2 :8(G(Pj holds Pi ! 9X (Pi online Pj)))CW3 :8(G(Pj holds Pi ! 8X ((Free Pj _ Free Pi) ! :Pj holds Pi)))

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


The call-foward when busy featureCFB: When a phonePj is not free,CFB allows its users toforward all the incoming calls to another phone (AxiomCFB2). WhenCFB is not used, the in-coming calls are refused (AxiomCFB1). The feature specificationCFB is of the formCFB =(((�B ; fB1g); ;;�B ,! �CFU); axCFU ) where:� �CFB = �B[Si6=j2f1;2;3g fCFB Pi Pjg� axCW is the set containing the two following axiom schematas:

CFB1 : 8(G(Pi alls Pj ^ :Free Pj ^ :(Wk�N CFB Pj Pk)) ! 8X (Pj refuses Pi)))CFB2 : 8(G(Pi alls Pj ^ :Free Pj ^ CFB Pj Pk ! 8X (Pi alls Pk)))

The flatL-specification from a feature system specificationSys is the result of an inductive con-struction from its integration order.

Notation 3.1. Let SP = (�; ax) be aL-specification. Then, let us noteSig(SP ) = � andAx(SP ) =ax.

Notation 3.2. Let us noteSP ,! SP 0 to mean thatSig(SP ) ,! Sig(SP 0) andAx(SP ) � Ax(SP 0).Definition 3.3. (Integration)Let Sys = (Fi)i�n be a feature system specification. Let us note(Sysi)i�n the sequence ofL-specifications inductively defined by:� Sys0 = SP 00, and� letFi = (SP; Inv; SP 0), thenSysk+1 = (Sig(Sysk) + Sig(SP 0); (Ax(Sysk) n Ax(SP )) [Ax(SP 0)).Sysn is theL-specification resulting from the integration order. This integration order issensibleif andonly if for every feature specificationFi = (SPi; Invi; SP 0i ) there existsj < i such thatSPi ,! Sysj.Remark 3.2. Let us recall that a feature is defined in isolation. But in practice, between the descriptionof a feature and its integration, others features will probably be defined and plugged on the existing sys-tem. 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 thenotion of sensible integration order. This notion imposes that the required specification of any featureoccurs only in the whole integration history of the system existing before the integration of the featureof interest.

Example 3.2. With notations of Example 3.1, let us consider the system(B;CW;CFB). The integra-tion sequence for this system is(Sys1; Sys2; Sys3) whereSys1 = (�B ; fB1g), Sys2 = (�CW ; ax2),whereax2 = fCW1;CW2; CW3g andSys3 = (�CW [�CFU ; ax3), whereax3 = fCW1; CW2; CW3; CFB1; CFB2g.


Hence,Sysn is the final flatL-specification of the feature system specificationSys and has to beunderstood as the “final system” obtained after integration. Therefore, the semantics ofSys is definedby Mod(Sysn). A feature system specification is meaningful if the specificationSys is consistent, thatis there is at least one (untrivial) model inMod(Sysn) which satisfies it. Therefore, feature integrationproblems are restricted to verify that bothL-specificationSysn obtained after integration is consistentand all invariants are preserved bySys, that is:

Definition 3.4. (Sound integration)Let Sys = (Fi)i�n be a feature system specification.Sys hasa sound integrationif and only if:

1. 9' 2 Sen(Sig(Sysn)); Sysn 6j=' (Sys is consistent)

2. 81 � i � n; Sysn j= Invi (invariants are preserved)

Therefore, the satisfaction of invariants is a correctnesscriteria. Indeed, when they are not satisfied, theycan be considered as harmful interactions.

Definition 3.5. (Pre-institution of feature specifications)LetL = (Sig; Sen;Mod; j=) be a feature logic. Then, let us define the quadrupleLfeat = (Sigfeat; Senfeat;Modfeat; j=feat) as follows:� Sigfeat is the category of feature signatures and feature signaturemorphisms defined, respec-

tively, as triples(SP; Inv;� ,! �0) and for two feature signatures(SP1; Inv1;�1 ,! �01) and(SP2; Inv2;�2 ,! �02) as a pair(�1 : �1 ! �2; �2 : �01 ! �02) satisfying both followingconditions:

1. �2 ,! �02 Æ �1 = �2 Æ �1 ,! �01,2. Sen(�1)(Ax(SP1)) � Ax(SP2) andSen(�1)(Inv1) � Inv2.� The functorSenfeat maps each feature signature(SP; Inv;� ,! �0) to Sen(�0), and each sig-

nature morphism(�1; �2) to Sen(�2).� The functorModfeat maps each feature signature(SP; Inv;� ,! �0) to Mod(�0; Inv), andeach signature morphism every(�1; �2) : (SP1; Inv1;�1 ,! �01) ! (SP2; Inv2;�2 ,! �02) toMod(�2) : Mod(�02; Inv2)!Mod(�01; Inv1) (Mod(�2) is a functor by Proposition 2.1).� j=feat= (j=�F )�F2jSigfeat where for each�F = (SP; Inv;� ,! �0, j=�F=j=�0 .

Fact 3.1. If L is an institution (i.e. the satisfaction condition is satisfied) thenLfeat so is.

By following Definition 2.3, a feature specification is then any pair(�F ; axF ). To connect the formof feature specifications such as defined in Definition 3.1 with the form of specifications inLfeat, it is suf-ficient to consider, given a feature specificationF = (SP; Inv; SP 0), that�F = (SP; Inv; Sig(SP ) ,!Sig(SP 0)) andaxF = Ax(SP 0).


3.2. Feature interactions

As we previously glimpsed in Introduction, integrating a feature in a system is not a conservative oper-ation, 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 qualitativenature 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 truefor 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 itsspecification) when it is plugged on the system.

2. Emerging properties:the feature under analysis does more services than scheduled when it isplugged on the system.

This gives rise to both following definitions:

Definition 3.6. (Non-conformance properties)Let Sys = (Fi)i�n be a feature system specification. The set ofnon-conformance propertiesfor Fi(1 � i � n) with respect toSys is defined by:NCPFi;Sys = F�i n Sys�Example 3.3. As an example, we can cite the usual property of P.O.T.S. which means that all incomingcall from A on B is indicated by either a tone on B’s phone when Bis free, or a peculiar ringing in A’shandset. Indeed, when the feature T.C.S. is integrated, this last property becomes a non-conformanceproperty for P.O.T.S. In the same way, in the framework of thelift specification, the usual livenessproperty which prevents that a requirement is never handled, becomes a non-conformance property forthe basic service when the priority floor service is integrated.

Non-conformance properties are direct consequences of behavior non-preservation which underliefeature 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 isa consequence of the satisfaction condition (cf. Corollary2.1). Hence, if the underlying featureL is aninstitution (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)i�n and ev-ery feature specificationFi = (SPi; Invi; SP 0i ) of Sys such thatSP 0i ,! Sysn, we have:NCPFi;Sys =;.Proof:AsSPi ,! Sysn, by Proposition 2.1, we have:Mod(Sig(SP 0i ) ,! Sig(Sysn))(Mod(Sysn)) �Mod(SP 0i )Hence, for every' 2 Ax(SP 0i ), we haveSysn j= ', and thenF�i � Sys�. ut


Corollary 3.1. If L is an institution, we always have:NCPFn;Sys = ;.Hence, using an institution as feature logic can restrict the capability to discover non-conformance prop-erties.

In order to define emerging properties, a restriction has to be done on properties inSys�. Indeed,most properties inSys� (the set of true properties forSys) do not involve the feature of interestF =(SP; Inv; SP 0): all those which do not contain any syntactical elements introduced by the signatureof F . These properties are over the language introduced by the system minus the one introduced byF . To define a pertinent set of emerging properties, we have to exclude fromSys� all properties whichdo not affect the feature of interest. Therefore, if we noteSig(F) = Sig(SP 0), then all propertiesbelonging toSys� \ Sen(Sig(Sysn) n Sig(F)) have not to be considered as emerging properties. Theaxiomatization of the set-theoretic difference, useful togive a meaning toSig(Sysn) n Sig(F), has notbeen defined in [15]. Therefore, before introducing the set of emerging properties, let us start by givingsuch an axiomatization.

categorical axiomatization of the set-theoretical difference As it is argued in [15], even though setinclusions are the simplest natural example of inclusion system, inclusion systems in general may haveproperties that are quite different from those of sets. For example, any inclusionA ,! B in set theoryis ”split” in the sense thatB can be written as a disjoint unionA`C whereC is the ”difference”betweenB andA. This property does not hold for all inclusion systems. For example, given a manysorted signature inclusion(fsg; ;) ,! (fsg; ff : s ! sg), the difference(;; ff : s ! sg) is not asignature. The expected result should be(;; ;). Nevertheless, the notion of difference can be expressedin a categorical manner if we do not ground this axiomatization on property of disjoint union. Indeed,we can characterize the difference betweenB andA, denotedB n A, as the greatest set of setsXincluded inB such thatX \ A = ;. Therefore, we assume in the following that every feature logicL = (Sig; Sen;Mod; j=) satisfies the following supplementary requirement:

Definition 3.7. (Categorical difference)Let L = (Sig; Sen;Mod; j=) be a feature logic.L satisfies theproperty of differenceif and only if forevery pair of signatures(�;�0) 2 jSigj� jSigj, if we noteSig�0n� the full sub-category ofI, the objectclass of which isjSig�0n�j = fX j X \ � = �; ^X ,! �0g, thenSig�0n� has a terminal object thatwe note�0 n �. We call it thedifferencebetween�0 and�.

Note that this property is satisfied by all classical logics such as for instanceLCTL� . Afterwards, weconsider that feature logics satisfy such a property.

Let us resume our definition of emerging properties.

Notation 3.3. LetF = (SP; Inv; SP 0) be a feature specification. Let us noteSig(F) = Sig(SP 0), etAx(F) = Ax(SP 0).Definition 3.8. (Representative properties)Let Sys = (Fi)i�n be a system specification. For every1 � i � n, the setSys��Fi of representativeproperties forFi is defined as follows:Sys��Fi = Sys� n Sen(Sig(Sysn) n Sig(Fi))


The set of emerging properties is then defined as follows:

Definition 3.9. (Emerging properties)Let Sys = (Fi�n) be a system specification. The set ofemerging propertiesfor Fi with respect toSys,is defined by: EPFi;Sys = Sys��Fi n F�iExample 3.4. As an example, let us suppose that a user A has subscribed to both features C.F.B. andC.W. Moreover, let us suppose that B is calling A but A is already engaged. Finally, let us supposethat no priority rules has not been specified concerning these two services. Both C.W. and C.F.B. aregoing to be activated, and then B is going to be both in waitingand forwarded in another phone. Atthe specification level, this conflict is denoted by an emerging property that can only be checked at thesystem level. Formally, from the feature system of Example 3.2, this is expressed as follows:

It is easy to see thatEP(CW;Sys3) 6= ;. Indeed fromCW1 andCFB1 we deduce that the formula :8(G(Pi alls Pj ^ :Free Pj ^ CFB Pj Pk ! X (Pi allsPk ^ Pj holds Pi)))is an element ofSys3��CW . It is easy to see that it is not an element ofCW �. It reveals a sub-

specification interaction betweenCW and the systemSys3. The reason is that the activation conditionsfor CW andCFB 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 interactionsmay appear at different levels of design. [26] points out that some interactions may be inherited fromhigher 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 ofdesign 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 mappingfrom one level to the next lower one.

Here, we propose then to use refinement techniques as a basic incremental method to simplify the featureinteraction task. The underlying motivation is that interaction are easier to study on more abstract speci-fications when some details are hidden. Of course, as pointedout in [26], the problem of the correctionof the mapping from an abstract level to a more concrete one isessential: the important point is to studyinteraction 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 studyinghow these interactions behave thoughrefinement.


In the following, we suppose that the underlying feature logic is an institution, that is it satisfies thesatisfaction condition. This condition is necessary to establish some results of interaction preservationthrough refinement relation. Therefore, we are going to takeadvantage from having shown that thefeature logic is an institution to define a refinement theory within it. Hence, we will use notations andresults 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 isfeature refinement.Feature specifications being at the end flatL-specifications of the form(�; ax), syntax of refinementfollows 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 specifi-cations. Indeed, refinement focuses on a concretization of feature behaviors. On no account, is it to givea concrete expression of other features except through interactions. Hence, both requirement specifica-tion and set of invariants are preserved because they denotefeature behaviors which are in front of thefeature 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. ASyntactic refinementof F is a L-specificationSPimp such thatSig(F) ,! Sig(SPimp). Let us noteF SPimp such a refinement.

Example 4.1. Let us consider the basic telephone systemB presented in Example 3.1. We can refinethis 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 [ Si6=j�N fsys aut Pi Pjg� axB only contains the two following axiom schematas:B1imp1 : 8(G(Pi alls Pj ^ :Free Pj)! 8X (:sys aut Pi Pj)))B1imp2 : 8(G(:sys aut Pi Pj ! Pj refuses Pi))Axiom B1imp1 expresses that whenever a call of sourcePi and targetPj is done, ifPj is not free,the system refuses the communication. AxiomB1imp2 expresses that whenever the system refuses acommunication, this communication does not happen.

A refinement can introduce both decision and algorithmic choices. For instance, abstractly speci-fying a sorting only requires that the resulting array is a permutation of the input one, and its elementsare sorted in the expected order. It is clear that all existing sortings are correct realizations of such aspecification. But, if we specify a peculiar algorithm for sorting such as quick-sort, we cut down in theclass of acceptable sorting algorithms and only preserve the desired algorithm. The consequence of suchchoices then consists in cutting down in model classes4. Semantically, this is expressed as follows:4If we make an analogy between specification models and possible realizations.


Definition 4.2. (Semantic refinement)LetF SPimp be a syntactic refinement.SPimp is asemantic refinementof F , writtenF SPimp, ifand only ifMod(Sig(F) ,! Sig(SPimp))(Mod(SPimp)) �Mod(F).

Semantic refinement well expresses refinement correctness,that is the refinement specification meetsall requirements of the higher level specification. Indeed,we have the following result:

Proposition 4.1. LetF SPimp be a syntactic refinement. Then, we have:F SPimp () F� � SP �impProof:()) Let ' 2 F�, and letM 2 Mod(SPimp). As L is an institution, by Proposition 2.1, we haveMod(Sig(F) ,! Sig(SPimp))(M) 2 Mod(F). Therefore,Mod(Sig(F) ,! Sig(SPimp))(M) j= '(from the second point of Definition 2.5,Sen(Sig(F) ,! Sig(SPimp))(') = '). By the satisfactioncondition, we can concludeM j= '.

(() LetM 2 Mod(SPimp). By hypothesis, for every' 2 Ax(F), we haveM j= '. AsL is aninstitution, we haveMod(SigF ,! Sig(SPimp))(M) j= '. utCorollary 4.1. LetF SPimp be a semantic refinement withF = (SP; Inv; SP 0). Therefore,Fimp =(SP; Inv; SPimp) is a feature specification.

Proof:Inv � F�, so isInv � SP �imp. utExample 4.2. If we consider the refinement of Example 4.1, it is easy to see thatB1 is a semanticalconsequence ofB1imp1 andB1imp2.

Another condition is usually added to the refinement correctness in order to express that a refinementdoes 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 featurespecification. This is the case when we simulate a data structure from other data structures which areavailable in the target programming language (e.g. stacks from the pair (array,natural number) or listfrom pointers).In a logical approach, specification behavior being defined by the class of models that satisfy axioms, thepreservation of behavior is expressed as follows:

Definition 4.3. (Complete preservation of behavior)Let F Fimp be a syntactic refinement. Then,Fimp completely preserves the behavior ofF if andonly if F� = F�imp \ Sen(F).

Because, semantic refinement cuts down in model classes of specification, both notions of refinementcorrectness and preservation of behaviors are not similar.The only way to obtain such a result is toimpose on specification models the following condition:8M 2Mod(F); 9M0 2Mod(Fimp); Mod(Sig(F) ,! Sig(Fimp))(M0) =M


This last condition, usually calledcompleteness[18], means that every possible realizations of the ab-stract specification is refined by (at least) a realization ofthe more concrete specification.

Example 4.3. The refinement given in Example 4.1 is complete. Indeed, any model(S;R;L) of B canbe extended into one (or several) model(s) ofBimp which only have the property that for any states 2 Ssuch thatPi alls Pj 2 L(s) andFree Pj =2 L(s).Therefore for allsRs0, sys aut Pi Pj =2 L(s0).Hence,Modfeat(�B ,! �Bimp)(jModfeat(Bimp)j) = jModfeat(B)j. From the satisfaction condition,we then obtainB� = Bimp� \ Senfeat(�FB ), where�FB is the signature ofB.

4.2. Refinement and integration

Of course, it is not reasonable to refine a specification as a whole in a single step. Large softwaresusually require many refinement steps before obtaining efficient programs. This leads to the notion ofsequential composition of refinement steps. Usually, composition of enrichment is mainly divided intotwo concepts:

1. horizontal composition, and

2. vertical composition.

Horizontal composition deals with refinement of subparts ofsystem specifications when they are struc-tured into specification “blocks”. In our framework, blocksare feature specifications. On the contrary,vertical composition deals with many refinement steps. In both cases, we will show that the correctnessis preserved.

4.2.1. Horizontal composition

Here, horizontal composition can be informally expressed as follows:

“ if a feature specificationFimp correctly refines a feature specificationF of a systemSys, then allrequirements ofSys are preserved by the system whereF has been replaced by its refinementFimp”

Before establishing this result, we have in first to formallydefine what means “the system whereFhas been replaced by its refinementFimp”. Indeed, this replacement cannot be a simple substitutionofF by Fimp because some features integrated inSys may share withF some axioms. Therefore, theseaxioms have to be removed and replaced by axioms ofFimp everywhere they occur inSys.Hence, in each feature specification ofSys, we have to replace any axiom' of F , when it occurs, by aset of axiomsax' of the refinement specificationFimp. Of course, to ensure a syntactic consistency,'has to be replaced by the same setax' everywhere it occurs inSys. Now, to ensure a semantic consis-tency, this replacement has not to generate inconsistencies with other existing features inSys. Therefore,we have to impose thatax' satisfies', that isax' j= '. For logics equipped with a refinement theory,this last condition is usually satisfied. Indeed, for these logics, a refinement is usually defined by animplementing specification and an intermediate specification [18]. The intermediate specification is anenrichment of the implementing one, and usually (at least inpractice) makes a correspondence one-to-one between the operations of the implementing specifications and the operations of the specification to


be implemented. Moreover, this correspondence is usually defined in a constructive way. In our frame-work, we directly manipulate the result of this enrichment without mentioning enriched specification (i.e.the implementing specification), that is both implementingand intermediate specifications are togetherin a flat specificationSPimp.Finally, a last condition has to be imposed in order to define aconcrete system which is lucky enoughto be an implementation of the abstract one. This last condition states that for two distinct properties'and'0, ax' andax'0 are disjoint. This allows to prevent the following kind of situation: let us supposetwo properties' and'0 of F such thatax' \ ax'0 6= ;, and let us suppose that after an integrationstep,' has been removed and replaced byax' but not'0. In the refined system we want to findax'0again. However, because' has been removed, we will only find againax'0 n (ax' \ ax'0). This lastcondition 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), thisintersection is usually non-empty. Indeed, similar parts of implementing specifications used in a refine-ment can naturally be used to specify different operations in the intermediate specification. For instance,the operationpush for stacks is simulated by increasing of one unit stack height. Hence, this requiresto use the operation successor of arithmetic, itself used tosimulate the operationheight for stacks. Inthe framework developed in [18], it would be sufficient to impose this condition to be disjoint on axiomsof the intermediate specification. In our framework where both intermediate and implementing speci-fications are put together into a flat specification, we can nevertheless, from such a situation, generatean empty intersection. It is sufficient that the institutiongets an internal conjunction. In this case, wereplace any formula 2 ax'0 n(ax'\ax'0) by the formula( ^�2ax'\ax'0�)^ . Syntactically, this ensures

us an empty intersection between both setsax' andax'0 .Therefore, replacing a featureF by a correct refinement in a system specification is expressedas follows:

Definition 4.4. (Consistent with refinement)Let F Fimp be a semantic refinement. letR = (ax')'2Ax(F) be a partition ofAx(Fimp). R is saidconsistent with the refinementif and only if:8' 2 Ax(F); (Sig(F); ')� � (Sig(Fimp); ax')�Example 4.4. Regarding to Example 4.1, if we set thataxB1 = fB1imp1; B1imp2g, thenR = faxB1gis consistent with the refinement. Indeed, we have:axB1 j= B1.

The condition given in Definition 4.4 is stronger that the refinement correctness such as it has beendefined in Definition 4.2. Indeed, we have the following result:

Proposition 4.2. If a setR is consistent with a refinementF Fimp, then we haveF Fimp.Proof:As R is consistent with a refinementF Fimp, we have for every' 2 Ax(F) that ax' j= '.Therefore, by Corollary 2.1,ax' [ ax'0 j= ', and thenax' [ ax'0 j= '0. Let us suppose,f';'0g j= .By Proposition 2.2, we haveax' [ ax'0 j= .By iterating this schema on all formulas inAx(F), we conclude thatF� � F�imp. By Proposition 4.1,we then concludeF Fimp. ut


Afterwards, this new condition will re-define refinement correctness. Hence, from now, a refinementwill be correct, if there exists a partition of axioms of refinement specifications satisfying the conditionof Definition 4.4.

Definition 4.5. (Integration)Let Sys = (F)i�n be a system specification. LetFk Fimp whereFk = (SPk; Invk; SP 0k) with1 � k � n. LetR = (ax')'2Ax(F) be a partition ofAx(Fimp coherent with the refinement. Let usnoteSys[Fk Fimp℄R = (F i)i�n the system specification moduloR where: for every1 � i � n,F i = (SP i; Invi; SP 0i) is defined by:� Sig(SP i) = minfX jX ,! Sig(SPi)+Sig(Fimp)^8' 2 Ax(SPi)\Ax(Fk); ' 2 Sen(X)g

andSig(F i) = minfX jX ,! Sig(Fi)+Sig(Fimp)^8' 2 Ax(Fi)\Ax(Fk); ' 2 Sen(X)gwhereminfX j P(X)g means the least signature according to inclusion morphismssatisfying thepropertyP.� Invi = Invi� Ax(SP i) = Ax(SPi) n Ax(Fk) [ ['2Ax(SPi)\Ax(Fk) ax' andAx(F i) = Ax(Fi) n Ax(Fk) [ ['2Ax(Fi)\Ax(Fk) ax'

Example 4.5. Regarding to the system presented in Example 3.2 and the refinement presented in Ex-ample 4.1, we only have to replace the required specification(�B ; fB1g) of bothCW andCFB by(�Bimp ; fB1imp1; B1imp2g).From Definition 4.5, we haveFk = Fimp. Moreover, the flat specification, notedSysn[Fk Fimp℄Rwhich results of the integration of all feature specifications inSys[Fk Fimp℄R has then the followingform: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℄�RProof:As F Fimp, from Proposition 4.1, we haveF� � F�imp. More generally, we have for any1 � i � nthatF�i � F�i . Therefore, by following the same approach than in the proofof Proposition 4.2, we canconcludeSys�n � (Sys[Fk Fimp℄R)�n. utThis result naturally extends the local correctness of feature refinements to the level of specifications offeature systems.


Corollary 4.2.Mod(Sig(Sys) ,! Sig(Sys[Fk Fimp℄R))(Mod(Sys[Fk Fimp℄R)) �Mod(Sys).4.2.2. Vertical composition

The vertical composition establishes a transitive closureof correct refinement relations. It is expressedby the following result:

Theorem 4.2. (Vertical composition)The following rule is correct: F F 0 F 0 F 00F F 00Proof:This is a direct consequence of Proposition 4.1. utRemark 4.1. Uniquely from the hypothesis thatFimp is a correct refinement ofF , both reduct functorsfrom Mod(Fimp) to Mod(F) and fromMod(Sys[F Fimp℄R) to Mod(Sys) are [39]’s constructorswhere the specification-building operation is the usualtranslateoperation 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 byrefinement has not been already introduced by some other features of the system. This gives rise to thenotion ofrefinement compatible with systemdefined as follows:

Definition 4.6. (Refinement compatible with system)Let Sys = (Fi)i�n be a system specification.Fk Fimp is said to becompatible withSys if and onlyif 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 beuseful for our purposes:

Lemma 4.1. For every feature logicL, we have:

1. 8� 2 jSigj; �+�; = �2. 8�;�0 2 jSigj; �+�0 = �; ) � = �; ^�0 = �;3. 8�;�0 2 jSigj; � \ �0 = �() � ,! �0

Proof:

1. As�+ �; is the pushout of(�; ,! �;�; ,! �;), there is a unique morphismh : � + �; ! �such thathÆ� ,! �+�; = Id�. h is uniquely factored ash = eÆ �. Therefore, we havee = Id,and�+�; ,! �. AsHomI defines a partial order, we conclude�+�; = �.


2. From the premise of the implication, we have� ,! �; and�0 ,! �;. But, �; is initial in I.Therefore,� = �; and�0 = �;.

3. ()) Obvious because from the hypothesis, we directly deduce� \ �0 ,! �0.(() By definition, we have� \ �0 ,! �. Now, from both the hypothesis� ,! �0 and theintersection is idempotent, we deduce that� ,! � \ �0. As HomI defines a partial order, weconclude� \ �0 = �. ut

Lemma 4.2. Let Sys = (Fi)i�n be a system specification. LetFk Fimp compatible withSys. letR = (ax')'2Ax(F) be a partition ofAx(Fimp) consistent with refinement. Therefore, we have: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, thecompatibility condition and Lemma 4.1: Let us noteY = minfX jX ,! Sig(Fi)+Sig(Fimp)^8' 2Ax(Fi) \Ax(Fk); ' 2 Sen(X)gX \ Sig(F i) = �; ^X ,! Sig(Sysn[Fk Fimp℄R)mX \ (Sig(Fi) + Y ) = �; ^X \ (Sig(Sysn) + Sig(Fimp)) = XmX \ Sig(Fi) = �; ^X \ Sig(Sysn) = X utLemma 4.3. With all the notations of Lemma 4.1, we have:Sys��Fi � (Sys[Fk Fimp℄R)��FiProof:This results from Theorem 4.1 and Lemma 4.2. utTheorem 4.3. (Partial results of preservation)Let Sys = (F)i�n be a system specification. LetFk Fimp compatible withSys. let R =(ax')'2Ax(F) be a partition ofAx(F)imp consistent with refinement. Therefore, we have the followingset-theoretical inclusions: for every1 � i � n such thatAx(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:BecauseAx(Fi)\Ax(Fk) = ;, we haveF�i = F�i . Therefore, both inclusions result from Theorem 4.1and Lemma 4.3. ut


We do not ensure results of preservation for featuresFi which share withFk some axioms becausewe have for them:F�i � F�i . This is a consequence of design choices the effect of which is to cut downmodel 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 throughrefinement), 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 spec-ification abstraction, and then obtain that all interactionstudied at an abstract level are preserved at moreconcrete ones. Indeed, a feature specification can put many particular points forward, but only some ofthem are recognized to be sensitive to harmful interactions. The idea is then to abstract feature speci-fications by hiding the non-sensitive points. Consequently, from a feature specificationF , we obtain afeature specificationFabs satisfyingFabs F . Here, any design choice has not been done. We sawpreviously that in this case a complete preservation of behaviors through refinement can be imposed.Here, because some axioms ofF can be shared with other features in system, a more subtle conditionthan the one given in Definition 4.3 has to be imposed. This newform of completeness of refinement isexpressed as follows:

Definition 4.7. (Complete refinement revisited)LetF Fimp be a syntactic refinement. LetR = (ax')'2Ax(F) be a partition ofAx(F). Then,Fimpcompletely preserves the behaviorof F with respect toR if and only if:

1. Mod(Sig(F) ,! Sig(Fimp))(Mod(Sig(Fimp))) = Mod(F)2. 8' 2 Ax(F);8M 2 jMod(Sig(Fimp))j; M j= ',M j= ax'

We will say then thatR is complete with refinement.

The first condition is the classic condition of completenessof refinement [18]. It implies the com-plete preservation of behavior, that is:F� = F�imp \ Sen(F). But, this result is not sufficient for ourpurpose. Indeed, as any axiom' 2 ax(F) is replaced by a setax' � ax(Fimp), a complete refinementhas 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 followingresult:

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)i�n be a system specification. LetFk Fimp compatible withSys.letR = (ax')'2Ax(F) be a partition ofAx(F)imp complete with refinement. Therefore, we have:Sys� = Sys[Fk Fimp℄�R \ Sen(Sig(Sysn))


Proof:In first, let us prove thatF�k = F�imp \ Sen(Sig(Fk)). By Proposition 4.2, we haveF�k � F�imp. Toprove the opposite inclusion, let us consider for any pair(';'0) 2 Ax(Fk) � Ax(Fk) a modelM 2jMod(Sig(Fk))j such thatM j= f';'0g. By Definition 4.7, there existsM0 2 jMod(Sig(Fimp))j suchthatMod(Sig(Fk ,! Fimp))(M0) =M. Therefore,Mod(Sig(Fk) ,! Sig(Fimp))(M0) j= f';'0g.By the satisfaction condition, we haveM0 j= f';'0g. Consequently, by Definition 4.7,M0 j= ax' [ax'0 , and thenM0 j= . By the satisfaction condition, we concludeM j= .By iterating this process on each formula inAx(Fk), we concludeF�k = F�imp \ Sen(Sig(F)).For every1 � i 6= k � n, we have also:(Sig(Fi); Ax(Fi) \Ax(Fk))� = (Sig(F i); ['2Ax(Fi)\Ax(Fk)ax')� \ 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);( ['2Ax(Fi)\Ax(Fk)ax') [ f'g)� \ Sen(Sig(Fi))Let 2 (Sig(F i);( ['2Ax(Fi)\Ax(Fk)ax') [ f'g)� \ Sen(Sig(Fi)).LetM2Mod((Sig(Fi); (Ax(Fi) \Ax(Fk)) [ f'g)).By Definition 4.7, there existsM0 2 jMod(Sig(F i))j such thatMod(Sig(Fi) ,! Sig(F i))(M0) =M. Therefore, we have:Mod(Sig(Fi) ,! F i)(M0) j= (Ax(Fi) \Ax(Fk)) [ f'gBy the satisfaction condition, we haveM0 j= (Ax(Fi) \ Ax(Fk)) [ f'g. Consequently, by Defini-

tion 4.7,M0 j= ( ['2Ax(Fi)\Ax(Fk)ax') [ f'g, and thenM0 j= .By the satisfaction condition, we concludeM j= .By iterating this process, on each formula inAx(Fi)n(Ax(Fi)\Ax(Fk)) andAx(Sysn)n(Ax(Sysn)\Ax(Fk)), we show, respectively, both following equations:

1. (Sig(Fi); (Ax(Fi) \Ax(Fk)) [ f'g)� = (Sig(F i);( ['2Ax(Fi)\Ax(Fk)ax') [ f'g)� \ Sen(Sig(Fi))2. Sys� = Sys[Fk Fimp℄�R \ Sen(Sig(Sysn)) utFrom Proposition 4.3, we obtain our expected result which states a complete preservation of interac-

tions through refinement.

Theorem 4.4. (Complete Preservation of interactions)Let Sys = (F)i�n be a system specification. LetFk Fimp compatible withSys. let R =(ax')'2Ax(F) be a partition ofAx(F)imp complete with refinement. Therefore, we have the follow-ing set-theoretical inclusions:81 � i � n,

M. Aiguier et al. / Logic-independent feature specifications 27� EP(Fi;Sys) = EP(F i;Sys[Fk Fimp℄R) \ Sen(Sig(Sysn))� NCP(F i;Sys[Fk Fimp℄R) \ Sen(Sig(Fi)) = NCPFi;SysProof: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 directlyconnected 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 havebeen defined in the present paper, thatis 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 sys-tems, either the semantical model of automates [11, 27, 34, 42] , or a modal logic such as dynamic ortemporal logic, semantics of which is expressed from automates or more generally from Kripke mod-els [12, 14, 35, 36], or some restrictions of the first order predicate logic [22, 41]. The problem of featureintegration strongly depends on specification semantics. For instance, when dealing with automates, fea-ture integration is based on composition techniques such assuperimposition [35, 36, 44].For most of these works, the correctness of integration thenconsists in verifying, as in our framework,that each of requirements of feature specifications are preserved. Hence, any requirement which is notpreserved through feature integration is noted as harmful.In the literature such interactions are calledinterference. For most of these works, interferences are usually the onlylooked for interactions.For interactions without undesirability criterion, we have seen in Section 3, that their set is usually infi-nite. This is our both sets of emerging and non-conformance properties. An exhaustive search of suchinteractions is then impossible. To answer such an impossibility, some works define critical criteriawhich are specific to the application domain under consideration. For instance, we can cite among themore 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 interac-tions which satisfy them. On no account detected interactions are considered as undesirable. They onlycharacterize the borderline cases to check because they arerecognized as problematic in the applicationdomain under consideration.Up to our knowledge, only in D. Cansell and D. Mery’s works [12, 13] refinement techniques are used todeal with the feature interaction problem at every specification level, although this problem has been rec-ognized as essential in the domain [26]. The idea of the authors is to modelize the integration of featuresthrough the refinement operation of abstract machines of thespecification language B [1]. Hence, harm-ful interactions are the consequences of a breaking of the refinement correctness defined by a behaviorpreservation. Here again, detected interactions are only interferences.


6. Conclusion

In this paper, we have presented an abstract framework whichallows one to specify feature systems andformally defining both integration and interaction problems. Our approach has been to define such alogic in a generic way, that is describing a formal methodology which defines how to extend any logicsatisfying some requirements in a feature logic. From such feature logics, feature have been definedby a set of invariants of the existing system that the featureof interest ensures to preserve, and a set ofproperties specifying its behavior. Integration of features in an existing system is correct if the resultingsystem has at least an un-trivial model. Finally, an interaction between a feature and a system on whichthe feature has been integrated, occurs when one of both underlying setsemergingandnon-conformanceproperties is non-empty. Emerging and non-conformance properties denote behaviors in addition and inless, 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 iscorrect (i.e. all realizations of the system used for refinement can simulate the behavior of the refinedobject), then the refined feature can be replaced by its refinement in the system, and preserves the globalbehavior 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 non-conformance properties can disappear. This is due to designchoices which cut down the model class.Therefore, in order to obtain a complete preservation of interaction through refinement, we have giventwo 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 implement-ing specifications. Intermediate specifications will then characterize an enrichment of other featurespecifications 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-studiedin this framework such as functional testing. Indeed, we have seen that both sets of emerging andnon-conformance properties are usually infinite. Therefore, this prevents to study exhaustivelyall interactions. This is close to functional testing, mainly with techniques to select tests fromspecifications.

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, Universityof Saarlandes, 1998.


[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 ofSpringer, pages 3–25. Springer, 2000.

[6] M. Bidoit. The stratified loose approach: a generalisation of initial and loose semantics. InRecent Trends inData 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. Chengand 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 andH. Velthuijsen, editors,Feature Interactions in Telecommunications Systems (FIW), pages 36–59. IOS Press,1994.

[11] J. Brederek. Formal criteria for feature intercationsin telecommunications systems. In V.-B. Iversen andJ. 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 - amethodological approach to feature interaction problem. In A. Galloway, J.-P. Bowen, S. Dunne, and S. King,editors,ZB2000, volume 1878 ofLecture Notes in Computer Science. Springer, 2000.

[14] F. Cassez, M.-D. Ryan, and P.-Y. Schobbens. Proving feature non-interaction with alternating-time temporallogic. 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. IOSPress, 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 imple-mentation, 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, pages995–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. Velthui-jsen, 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] , pages105–125.

[24] S. Gilmore and M.-D. Ryan, editors.Language Constructs for Decsribing Features. Springer, 2000.


[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: Asurvey.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] , pages78–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), pages542–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. PhDthesis, 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. Boumaand H. Velthuijsen, editors,Feature Interactions in Telecommunications Systems (FIW), pages 86–119. IOSPress, 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 ofLectureNotes 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] , pages202–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. InProceed-ings 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 Trendsin Data Type Specification, volume 655 ofLecture Notes in Computer Science, pages 310–329. Springer,1993.

[39] D. Sannella and A. Tarlecki. Toward formal developmentof programs from algebraic specifications: imple-mentations revisited.Acta Informatica, 25:233–281, 1988.

[40] A. Sernadas, C. Sernadas, and C. Caleiro. Fibring of logics as a categorial construction.Journal of Logicand Computation, 9(2):149–179, 1999.

[41] B. Stepien and L. Logrippo. Representing and verifyingintentions in telephony features using abstract datatypes. 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 delogiciels 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.


[44] N. Zuanon. Modular feature integration and validationin 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,MathematicalFoundations of Computer Science (MFCS’96), volume 1113 ofLecture Notes in Computer Science, pages579–590. Springer, 1996.

[46] E. Zucca. From static to dynamic abstract data-types: An institution transformation.Theoretical ComputerScience, 216(1/2), 1999.

feature specification: a logic-independent approach

Documents