A Foundation for Behavioural Conformance in Software ... - CiteSeerX

A Foundation for Behavioural Conformance in Software Product Line Architectures Dario Fischbein, Sebastian Uchitel

Victor Braberman

Department of Computing Imperial College 180 Queen’s Gate London, SW7 2RH, UK

Computer Science Department School of Sciences, Universidad de Buenos Aires, and CONICET Ciudad Universitaria, Buenos Aires C1428EGA, Argentina

[fdario,s.uchitel]@doc.ic.ac.uk

[email protected] ABSTRACT Software product lines or families represent an emerging paradigm that is enabling companies to engineer applications with similar functionality and user requirements more effectively. Behaviour modelling at the architecture level has the potential for supporting behaviour analysis of entire product lines, as well as defining optional and variable behaviour for different products of a family. However, to do so rigorously, a well defined notion of behavioural conformance of a product to its product line must exist. In this paper we provide a discussion on the shortcomings of traditional behaviour modelling formalisms such as Labelled Transition Systems for characterising conformance and propose Modal Transition Systems as an alternative. We discuss existing semantics for such models, exposing their limitations and finally propose a novel semantics for Modal Transition Systems, branching semantics, that can provide the formal underpinning for a notion of behaviour conformance for software product line architectures.

1. INTRODUCTION Software product lines or families represent an emerging paradigm that is enabling companies to engineer applications with similar functionality and user requirements more effectively [8, 21]. Hence, there is a need to create novel software techniques that can support the engineering of such families of software products. Software architecture [31] is widely recognised as an abstraction that can provide benefits for reasoning about the high-level design of complex software systems and for facilitating its implementation and deployment [14, 35]. Software architectures for product lines [35, 2] define the common architecture of a family of software products instead of fixing one particular architectural instance that may correspond to one of the products of the family. Product line architectures do not only include a description of mandatory ele-

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ROSATEA ’06 July 17, 2006, Portland, Maine, USA Copyright 2006 ACM 1-59593-459-6/06/07 ...$5.00.

ments which are part of all possible products of the family, but also may describe variation points: aspects of the architecture that are either optional or vary according to the specific product is being built. As noted by Muccini and Bucchiarone [29], existing approaches to product line architectures (e.g., [35, 12, 13]) focus on structural aspects rather than on behavioural modelling. We believe this is a missed opportunity, as behaviour modelling and analysis has been shown to be successful in uncovering design errors [6] at the software architecture level, and is likely to be beneficial for product line architectures too. Traditional behaviour models such as Labelled Transition Systems are not entirely adequate for describing behaviour of software product line architectures. The behaviour of a software product line can be considered to be partially defined in that it allows for optional and variant behaviour of the different systems that compose the product line. Yet the semantics of traditional behaviour models assumes a complete description of the system behaviour up to some level of abstraction, and hence cannot support modelling and reasoning in the presence of partial behavioural information (i.e. optionality and variability). Operational models that allow explicit modelling of unknown aspects of system behaviour are referred to as partial behavioural models. Partial behaviour models have been used to model the behaviour of product line architectures [29]. In essence, a partial behaviour model can be thought of as specifying a set of possible implementations. These implementations arise from making different decisions on those aspects in which the model was partial. For instance, deciding if a particular optional behaviour is to be included in a specific product. Hence, partial behaviour models must come equipped with a notion of conformance, which defines whether a given (non-partial) behaviour model conforms to the required behaviour described in the partial model. Having a notion of conformance is crucial for analysis and testing of final implementations of a product line [8]. Furthermore, if the notion of conformance can also be shown formally to be property preserving, then it is possible to analyse the partial behaviour model of a product family and gain assurance over all possible products of that family. A particular kind of partial behavioural model that has been studied widely is Modal Transition Systems (MTS), an extension of Label Transition Systems (LTS). These models

come equipped with several notions of conformance which relate MTS models with the LTS models that are considered valid implementations of the partial behaviour model. These notions of conformance, termed formally refinements, can be shown to preserve temporal logic properties [3, 19]. Furthermore, model checking of MTS is not more complex than model checking LTS [5] as the model check can be reduced to two checks on LTS. Hence, with no significant increase in cost, analysis can be done at the product line level for all possible members of the product family. In conclusion, MTS seem an appropriate candidate for rigorous modelling and analysis of product line architectural behaviour. Unfortunately, existing semantics over MTS do not adequately capture the notion of conformance that would be expected in the context of product line software engineering. In this paper is we argue why this is the case with a small example inspired in product lines architectures and provide a new semantics for MTS given by a novel notion of implementation. This new semantics, which underpins a sound notion of conformance for software product line architectures, is related to branching bisimulation[34] over LTS in a similar way existing MTS semantics informally relate to strong and weak bisimulation over LTS.

2. LABELLED TRANSITION SYSTEMS In this section we review LTS [23] and equivalence and refinement relations over them. We discuss why LTS are not appropriate for modelling partial knowledge on system behaviour, and hence not appropriate for describing the behaviour of product line architectures or more generally, for iterative development of system behaviour models. Labelled transitions systems provide a basis for modelling and analysing system behaviour at the software architecture level. An LTS describes how a system component interacts with its environment through shared events. LTS are equipped with a distinguished event, τ , that models internal computation that is not observable by the environment. Definition 1. (Labelled Transition Systems) Let States be a universal set of states, Act be a universal set of observable action labels, and let Actτ = Act ∪ {τ }. A labelled transition system (LTS) is a tuple P = (S, L, ∆, s0 ), where S ⊆ States is a finite set of states, L ⊆ Actτ is a set of labels, ∆ ⊆ (S × L × S) is a transition relation between states, and s0 ∈ S is the initial state. We use αP = L \ {τ } to denote the communicating alphabet of P . Figure 1 shows a graphical representation of two LTSs. Given an LTS P = (S, L, ∆, s0 ) we say P transitions on ℓ to P ′ , ℓ

denoted P −→ P ′ , if P ′ = (S, L, ∆, s′0 ) and (s0 , ℓ, s′0 ) ∈ ∆. ℓˆ

ℓ

Similarly, we write P −→ P ′ to denote that either P −→ P ′ ℓ or ℓ = τ and P = P ′ are true. We use P =⇒ P ′ to denote ℓ τ τ ∗ ′ ∗ P (−→) −→ (−→) P . Let w = w1 , . . . , wk be a word over w Actτ . Then P −→ P ′ means that there exist P0 , . . . , Pk such wi+1 that P = P0 , P ′ = Pk , and Pi −→ Pi+1 for 0 ≤ i < k. We w w ′ write P −→ to mean ∃P · P −→ P ′ . Finally, we extend =⇒ to words in the same way as we do for −→.

2.1 Equivalences A number of equivalence relations have been proposed that provide a criteria for deciding if syntactically different LTS models describe the same behaviour. We briefly review

three classical equivalence relations as they shall be referred to throughout this paper. The first of these relations is that of Strong Bisimulation. Definition 2. (Strong Bisimulation Equivalence) Let ℘ be the universe of all LTS, and P, Q ∈ ℘. P and Q are strong equivalent, written P ∼ Q, if αP = αQ and (P, Q) is contained in some bisimulation relation R ⊆ ℘ × ℘ for which the following holds for all ℓ ∈ Actτ : 1. 2.

ℓ

ℓ

(P −→ P ′ ) =⇒ (∃Q′ · Q −→ Q′ ∧ (P ′ , Q′ ) ∈ R) ℓ ℓ (Q −→ Q′ ) =⇒ (∃P ′ · P −→ P ′ ∧ (P ′ , Q′ ) ∈ R)

Informally, two models are strong equivalent if their initial states are strong equivalent, and two states are strong equivalent if, whenever one action can be executed in one of them leading to a state B, the other can execute the same action reaching a state B ′ , where B ′ is again equivalent to B. This equivalence does not distinguish τ transitions as special or unobservable actions. A property of this equivalence is that it preserves the branching structure of processes[15]. In contrast Weak Bisimulation equivalence compares the observable behaviour of models and consequently ignores internal computations (τ -transitions). Some authors call this equivalence observational equivalence, but we are going to use this expression to refer to any equivalence that considers τ -transitions as unobservable actions. Weak bisimulation equivalence is coarser than strong equivalence and does not preserve the branching structure of processes as it is shown in [34]. Definition 3. (Weak Bisimulation Equivalence) Let ℘ be the universe of all LTS, and P, Q ∈ ℘. P and Q are weak bisimulation equivalent, written P ≈ Q, if αP = αQ and (P, Q) is contained in some weak bisimulation relation R ⊆ ℘ × ℘ for which the following holds for all ℓ ∈ Actτ : ℓ

ℓˆ

ℓ

ℓˆ

1.

(P −→ P ′ ) =⇒ (∃Q′ · Q =⇒ Q′ ∧ (P ′ , Q′ ) ∈ R)

2.

(Q −→ Q′ ) =⇒ (∃P ′ · P =⇒ P ′ ∧ (P ′ , Q′ ) ∈ R)

Finally, we present Branching bisimulation equivalence. This equivalence is observational and also preserves the branching structure of LTS models[15]. In fact, it is the coarsest equivalence that preserves the branching structure of processes[15], and hence coarser than strong equivalence yet finer than weak bisimulation equivalence. Definition 4. (Branching Bisimulation Equivalence) Let ℘ be the universe of all LTS, and P, Q ∈ ℘. P and Q are branching bisimulation equivalent, written P ≈b Q, if αP = αQ and (P, Q) is contained in some observational bisimulation relation R ⊆ ℘×℘ for which the following holds for all ℓ ∈ Actτ : ℓ

τ ˆ

ℓˆ

ℓ

τ ˆ

ℓˆ

1.

(P −→ P ′ ) =⇒ (∃Q′ , Q′′ · Q =⇒ Q′ −→ Q′′ ∧ (P, Q′ ) ∈ R ∧ (P ′ , Q′′ ) ∈ R)

2.

(Q −→ Q′ ) =⇒ (∃P ′ , P ′′ · P =⇒ P ′ −→ P ′′ ∧ (P ′ , Q) ∈ R ∧ (P ′′ , Q′ ) ∈ R)

Note that the following Stuttering Lemma holds for branching bisimulation of LTS models. This lemma plays an important role in the discussion we present in section 5, as it does not hold for MTS models.

Lemma 1. (Stuttering Lemma) Let R be the largest branchτ τ τ ing bisimulation between P and Q. If r −→ r1 −→ · · · −→ τ ′ ′ rm −→ r (m ≥ 0) is a path such that (r, s), (r , s) ∈ R then (ri , s) ∈ R ∀ i ≤ m.

2.2 Refinements and Partial Behaviour The equivalence relations given above provide different criteria for deciding if two syntactically different LTS models describe the same behaviour. However, in the context of model that is being constructed iteratively, some formal notion that allows assessing if a model is a refinement of another is needed. The intuition being that as a model is refined, it becomes less abstract and closer to the characteristics of the target implementation. In a software product line development, the expectation is that all products of the family be a refinement of the product line architecture. One of the classical notions of refinement is based on Strong Simulation. While Strong Bisimulation defines an equivalence, Strong Simulation defines a partial order over LTS, and in particular P ∼ Q =⇒ P ⊑s Q ∧ Q ⊑s P . Note, that notions of simulation based on Weak and Branching Bisimulation can be defined following the same pattern as Strong Simulation and Bisimulation have. Definition 5. (Strong Simulation [16]) Let ℘ be the universe of all LTS, and P, Q ∈ ℘. Q simulates P , written P ⊑s Q, if αP = αQ and (P, Q) is contained in some simulation relation R ⊆ ℘ × ℘ for which the following holds for all ℓ ∈ Actτ : ℓ

ℓ

(P −→ P ′ ) =⇒ (∃Q′ · Q −→ Q′ ∧ (P ′ , Q′ ) ∈ R) c 1 1 3 a a

0

0

b b 2 2 (a) (b) Figure 1: An example of an LTS (a) that is refined by another (b). We argue that LTS models and refinement notions such as that based on strong simulation cannot adequately capture the incremental nature of developing behaviour models starting from models that embody a partial knowledge of the intended system behaviour to models that accurately capture all aspects of system behaviour up to a fixed alphabet. This means that they are also inadequate for describing the behaviour of product line architectures, as these must include a description of behaviour that all products in the family are expected to exhibit, behaviour that no product in the family is expected to exhibit, and finally behaviour that depending on the particular product instance, may or may not be permissible. Consider a classical refinement notion between LTS consisting in considering that P refines Q if P simulates Q. i.e. Q ⊑s P . One of the properties that characterize this refinement is that it reduces the degree of non determinism. With this refinement we know that any behaviour of Q is a valid behaviour of P . However, using this refinement it is not possible to ensure that a forbidden behaviour for the system described in Q will be preserved in the refined model P . For example, the model shown in figure 1(b) refines the one shown in figure 1(a) and it can be easily seen that model

1(b) has the possibility of taking transition c after taking a in spite of being forbidden in model 1(a). Moreover, a model consisting in a state with a self-transition for every element of the alphabet is considered by this semantics a refinement of any other model. On the other hand, if we consider that P refines Q if Q simulates P , i.e. P ⊑s Q. In this case we know that any behaviour of P is a valid behaviour of Q, but not the other way around. Therefore, if Q determines that certain behaviour is forbidden in a system we know that it will also be forbidden by P since any behaviour in P can be simulated by Q. However, using this semantics it is not possible to ensure that a desired behaviour for the system which is depicted in Q will be preserved in the refined model P . For example, the model shown in figure 1(a) refines the one shown in figure 1(b) and it can be easily seen that model 1(a) loses the possibility of taking transition c after taking transition a. Moreover, a model consisting in a state with no transitions is, considered by this semantics, a refinement of any other model. In essence, LTS and refinements based on simulation (be them strong, weak or branching) provide either the maximum or the minimum allowed behaviour for a system. While one bound is specified, i.e. either the lower or upper bound, the other bound remains open. In fact, this limitation is not due to the definition of refinement as a simulation (failures [32], testing [7] refinements have similar problems) but to an intrinsic characteristic of LTS models. Specifically, using these models it is not possible to identify which aspects of the system have already been defined and which still remains to be refined. This is true both for expected and forbidden behaviour. For this reason we will consider MTS since they allow us to explicitly specify which behaviour is required, possible or forbidden.

3.

MODAL TRANSITION SYSTEMS

In this section, we introduce MTS and a motivating example inspired on specification of behaviour for software product lines. We will use the case study in the next sections to illustrate both the problem with existing semantics of MTS and motivate a novel notion of conformance. The example that we use is inspired on the control software for family of mp3 players, embedded software for consumer electronics is one of the domains in which product families have been deployed [35]. A product of this family of mp3 players offers different functionality to a user by grouping related functions into menus. The general behaviour of the control software is basically as follows: the user selects the desired menu and the system offers the functions associated to the menu. If the user does not choose any function after an elapsed time, the system time outs, beeps and returns to the initial state. The final detail of available menus and functions of a product will depend on the various hardware features that the product includes. For instance, the player may come fitted with a digital camera and consequently require picture taking and image management software. This functionality will be available through a number of menus that are optional at the product line level. Clearly some menus will be required to be present in all products of the family such as those that group functionality for the selection and playback of mp3 files. To model the software for such a product family we use MTS. These models are capable of distinguishing between

behaviour that is required to be exhibited by a system (or family of systems), that is required not to be exhibited and additionally behaviour which is optional. Definition 6. (Modal Transition Systems) A modal transition system (MTS) M is a structure (S, L, ∆r , ∆p , s0 ), where ∆r ⊆ ∆p , (S, L, ∆r , s0 ) is an LTS representing required transitions of the system and (S, L, ∆p , s0 ) is an LTS representing possible (but not necessarily required) transitions of the system. We use αM = L \ {τ } to denote the communicating alphabet of M . In Figure 2 we show an MTS for the family of mp3 players. For simplicity we abstract the name of the specific menus and functions, adopting menu1 , . . . , menun labels for menus and f unc1 , . . . , f uncxj for the functionality grouped by the menu menuj . Transition labels that have a question mark are those in ∆p − ∆r . We refer to these transitions as “maybe” transitions, to distinguish them from required ones (those in ∆r ). Given an MTS M = (S, L, ∆r , ∆p , s0 ) we say M transitions on ℓ through a required transition to M ′ , denoted ℓ M −→r M ′ , if M ′ = (S, L, ∆r , ∆p , s′0 ) and (s0 , ℓ, s′0 ) ∈ ∆r , and M transitions through a possible transition, denoted ℓ M −→p M ′ , if (s0 , ℓ, s′0 ) ∈ ∆p . Similarly, for γ ∈ {r, p} ℓˆ

ℓ

we write M −→γ M ′ to denote that either M −→γ M ′ or ℓ ℓ = τ and P = P ′ are true, and we use P =⇒γ P ′ to denote τ τ ∗ ℓ ∗ ′ P (−→γ ) −→γ (−→r ) P . Note that LTS are a special type of MTS that do not have maybe transitions.

f uncx1 1x1 f unc1 τ

11

τ

τ

A:

M1 nu me

1

beep

0

B

me nu

n?

τ

4.

EXISTING DEFINITIONS OF CONFORMANCE

In this section we analyse the adequacy of existing MTS semantics as foundations for modelling behaviour of software product lines and for checking conformance of system behaviour to that of a product line. Discussion is based on the example presented in the previous section.

4.1

Strong Semantics

When considering LTS, strong semantics refers to the semantics given by strong bisimulation. One of the particularities of this semantics is that it lacks a notion of unobservable or internal action, i.e. τ -labelled transitions. Larsen has extended this semantics over MTS [24]. Strong refinement of MTS captures the notion of elaboration of a partial description into a more comprehensive one, in which some knowledge over the maybe behaviour has been gained. It can be seen as being a “more defined than” relation between two partial models. Intuitively, refinement in MTS is about converting maybe transitions into required transitions or removing them altogether: an MTS N refines M if N preserves all of the required and all of the proscribed behaviours of M . Alternatively, an MTS N refines M if N can simulate the required behaviour of M , and M can simulate the possible behaviour of N . Note the similarity the definition below has with that of strong bisimulation (Definition 2).

Mn

n1

τ

τ

products and the latter corresponding to those whose inclusion depends on the particular product of the family is to be built. Note that any behaviour that is not maybe nor required is forbidden. When an Mi state is reached, meaning that the user has selected the menu i, a set of transitions f unc1 to f uncxi become available. These transitions represent the access to the functionalities that can be triggered from this menu item. If the user triggers one of these, the system will carry out the associated task and after finishing that task it will return to the initial state. If the user does not select any functionality in a certain amount of time then a time out occurs, making the system leave the Mi state and return to the initial state by doing a beep. This time out is an internal event and therefore not visible to the user, so it is modelled with a τ transition.

f unc1 nx 1 f uncxn Figure 2: An MTS that models a family of software controllers for an electronic device. What is being captured in Figure 2 is the way the user can access the functionalities of the device. How these functionalities work is below the level of abstraction of this model and are consequently represented with τ transitions (e.g. the transition from state 11 to 0). From the initial state there are n transitions labelled menu1 to menun each one representing the selection of one menu entry by the user. These transitions are either required or maybe, the former corresponding to the menu items that must be in all final

Definition 7. (Strong Refinement) Let δ be the universe of all MTS. N is a refinement of M , written M  N , if αM = αN and (M, N ) is contained in some refinement relation R ⊆ δ × δ for which the following holds for all ℓ ∈ Actτ : 1. 2.

ℓ

ℓ

(M −→r M ′ ) =⇒ (∃N ′ · N −→r N ′ ∧ (M ′ , N ′ ) ∈ R) ℓ ℓ (N −→p N ′ ) =⇒ (∃M ′ · M −→p M ′ ∧ (M ′ , N ′ ) ∈ R)

Consider the MTS shown in Figure 2. If modellers decide to exclude menun then the model that would represent such decision is the one shown in Figure 3. According to strong semantics this latter model is a valid possible evolution of the initial one since the MTS A is refined by the MTS B (A  B), incorporating as new knowledge that the menun has been removed from the functionalities of the system. The refinement relation between these models is R = {(0, 0), (B, B), (M1 , M1 ), (11 , 11 ), . . . , (1x1 , 1x1 )}.

f uncx1

ones and therefore the comparison result of these models will not be as expected. In conclusion, to support model elaboration and provide a useful notion of conformance, it is imperative to use a semantics that makes a distinction between observable and non-observable actions, i.e. an observational semantics. As far as we know weak refinement [24] is the only observational semantics currently defined over MTS. We consider this semantics in the following subsection.

1x1 f unc1 τ

11

B:

τ

0

M1 τ nu me

1

beep

B

Figure 3: A model of the controller software that conforms (as defined by Strong Refinement) to the product family behaviour.

readList

Definition 8. ((Strong) Implementation) We say that an LTS I = (SI , LI , ∆I , i0 ) is a (strong) implementation of an MTS M = (SM , LM , ∆rM , ∆pM , m0 ), written M  I, if M  MI with MI = (SI , LI , ∆I , ∆I , i0 ). We also define the set of implementations of M as I[M ] = {I LT S | M  I}. Considering that strong refinement is transitive [24] it is straightforward to proof that M  M ′ implies I[M ] ⊇ I[M ′ ]. Hence when a model is evolved into a more refined one no new possible implementations for the system will be added, in fact when a model is enriched with more requirements the set of possible implementations can only be reduced. Another important result is that the reciprocal of the previous property is also valid, I[M ] ⊇ I[M ′ ] =⇒ M  M ′ [18]. A consequence of this is that when a modeller creates a new model to reflect additional requirements that were gathered we can be sure that this model will be accepted as a valid evolution of the previous model iff the set of implementations of the new model is a subset of the implementations of the previous one. These results, make strong refinement, an appealing notion for supporting iterative elaboration of partial models into comprehensive descriptions of system behaviour, or in the case of software product lines, the stepwise refinement of a product family behaviour model into a specific product that conforms to the product family’s intended behaviour. However, in practice, model elaboration and product instantiation can necessitate extending the alphabet of the system to describe behaviour in more detail. For example, in our example we may eventually want to describe with more detail how a particular function will be provided in a specific model. This can be seen in Figure 4 where the τ transition from state 1x1 to state 0 of the initial model has been replaced by the secuence readList, showList. Once this has been done we will need a way to ensure that the new model does in fact conform the previous one. Since strong refinement requires the alphabets of the models being compared to be equal we will need to check this using the concept of hiding, where transitions with new symbols of the alphabet are replaced with tau transitions. However, this refinement does not consider tau transitions as silent

f uncx1

f unc1

2x1 11

C:

showList Note that because the MTS B in Figure 3 has no maybe transitions, it can be considered an LTS and we say that it is an implementation of (or that it conforms to the behaviour described by) the model in Figure 2.

1x1

τ

M1 τ nu 1 me

beep

0

B

Figure 4: A more detailed model of a product where the behaviour of functionality associated to f uncx1 has been detailed.

4.2

Weak Semantics

Weak MTS refinement also defined by Larsen [24] allows comparing the observable behaviour of models while ignoring the possible differences that they may have in terms of internal computation. In other words, this notion of refinement considers τ -labelled transitions differently from other transitions. Weak MTS refinement is this defined based on the definition of LTS weak bisimulation, as can be seen in the following definition. Definition 9. (Weak Refinement) N is a weak refinement of M , written M O N , if αM = αN and (M, N ) is contained in some refinement relation R ⊆ δ × δ for which the following holds for all ℓ ∈ Actτ : ℓ

ℓˆ

ℓ

ℓˆ

1.

(M −→r M ′ ) =⇒ (∃N ′ · N =⇒r N ′ ∧ (M ′ , N ′ ) ∈ R)

2.

(N −→p N ′ ) =⇒ (∃M ′ · M =⇒p M ′ ∧ (M ′ , N ′ ) ∈ R)

It is worth noting that the relation between weak bisimulation and weak refinement follows the same pattern used to extend strong bisimulation into a refinement. Also, if a model N is a strong refinement of model M (M  N ) then N is also a weak refinement of M (M O N ). Finally, as with strong refinement, a notion of (weak) implementation can be defined between MTSs and LTSs. We now consider again the model C described in Figure 4. If we hide the new actions and then use weak refinement to compare it with the initial model A, it can be stated that C is a refinement of A being the refinement relation R = {(0, 0), (B, B), (M1 , M1 ), (11 , 11 ), . . . , (1x1 , 1x1 ), (0, 2x1 )}. Thus, as expected, with this semantics the analysed model is an adequate evolution of the initial one. Having introduced weak semantics and shown one example of its applicability we now analyse more closely its adequacy of to support a model elaboration. Our analysis is based on one particular implementation of the MTS A, which we present in Figure 5 and denote I. Considering

f uncx1

weak semantics, since R = {(0, 0), (B, B), (M1 , M1 ), (11 , 11 ), . . . , (1x1 , 1x1 )} is a refinement relation between A and I, the latter is a valid implementation of A.

1x1 f unc1 11

τ

f uncx1 1x1

τ fu

f unc1 τ

11

M1

I:

Obs(A):

τ

τ n me

nc

··· 1

fu

beep

0

nu me

0

τ

B

τ

1

menu1 beep

u1 fu

M1

nc x 1

me nu

nc

1

···

fu

xn

τ

menun ?

n?

nc

B

τ Mn

n1 f unc1

menun nx 1

Figure 5: A valid implementation of the initial model according to weak refinement. Intuitively, from the original model A, an implementation that conforms to the behaviour of the product family may or may not have a menun , but if it did have such menu, it would be expected that all the functions associated with this menu (i.e. f unc1 . . . f uncxn were available to the user. However, in the proposed implementation I, the user never has the possibility of selecting functions f unc1 . . . f uncxn after selecting menun . This breaks the intuition of what behaviour conformance should preserve: if a menu is included, all its associated functionality will be available to users. This example shows that weak semantics is not adequate to support elaboration of behaviour models. A more in depth analysis of this semantics allows us to gain some insight as to why weak refinement leads to such unintuitive implementations. For this we use an alternate (yet equivalent) standard definition of weak semantics. Weak semantics can be thought of as simply applying strong semantics to the models obtained from performing the transitive closure of tau transitions. Definition 10. (Observational Graph) Given an MTS M = (S, L, ∆r , ∆p , s0 ), the observational graph of M is the derived MTS Obs(M ) = (S, L, ∆ro , ∆po , s0 ) where ∆ro , ∆po are given by: ℓ ℓˆ 1. ∆ro = {M −→ M ′ |M =⇒r M ′ } ℓ

ℓˆ

2. ∆po = {M −→ M ′ |M =⇒p M ′ } Property 1. (Weak Refinement) N is a weak refinement of M , written M O N , if and only if Obs(M )  Obs(N ). We now revisit the case study with this alternative definition of weak semantics. Consider the transitive closure of the model in Figure 2 depicted in Figure 6. The transition labelled menun in Figure 2 gives rise to two different maybe menu menu transitions in Figure 6, i.e. 0 −→n m Mn and 0 −→n m B. In obtaining the implementation in Figure 5, we can consider that these two transitions were refined inconsistently: menu menu 0 −→n m B became a valid behaviour while 0 −→n m Mn became forbidden. These kind of “inconsistent” decisions that weak refinement allows over different transitions in the closured model that were originated from the same maybe transition are the cause for these unexpected implementations.

f uncxn Figure 6: A graphical representation of the observational graph of model in Figure 2

5.

A NOVEL NOTION OF CONFORMANCE

In the previous section we analysed the shortcomings of strong and weak semantics as a foundation for characterising conformance and supporting model elaboration. The former semantics does not distinguish unobservable actions and hence does not support comparing models whose internal behaviour has been described to varying levels of detail. The latter does not preserve branching behaviour adequately, hence, allowing implementations of partial models that contradict the intuition modellers may have of conformance. In this section we define a new notion of conformance that has the desired properties of both weak and strong semantics, i.e. an observational semantics that preserves branching structure. To do this we consider a third equivalence over LTS called branching equivalence. As shown previously, the three equivalences on LTS are given by a symmetric simulation relation, the difference between them is the way a transition on one model is simulated by the other model. Figure 7 shows a graphical representation of how a transition is simulated in each of these three equivalences. We have also shown strong and weak MTS refinement to be loosely based on the corresponding LTS equivalences by having a slightly asymmetric bisimulation in that every required transition in the less refined model must be simulated by the refined model using only required transitions, and every possible transition in the refined model must be simulated by possible transitions of the less refined model. Unfortunately, LTS branching bisimulation cannot be adapted in a similar way to produce an adequate MTS refinement. Consider the refinement from applying to LTS branching equivalence a similar pattern as for LTS strong and weak equivalence: Definition 11. (Na¨ıf branching refinement 1) N is a branching refinement of M , written M b1 N , if αM = αN and (M, N ) is contained in some refinement relation R ⊆ δ × δ for which the following holds for all ℓ ∈ Actτ :

τˆ ℓ

ℓ

ℓ

τˆ ℓˆ

ℓ

ℓˆ

τˆ (a) (b) (c) Figure 7: Depiction of how a transition is simulated in bisimulation: (a) strong; (b) branching; (c) weak.

0

1

τ? a

τ

2

b

3 b1

0

b

1

4 Figure 8: Example of a refinement according Definition 11 where the branching structure of the less refined process is not preserved.

ℓ

τ

ℓˆ

1. (M −→r M ′ ) =⇒ (∃N ′ , N ′′ · N =⇒r N ′ −→r N ′′ ∧ (M, N ′ ) ∈ R ∧ (M ′ , N ′′ ) ∈ R) ℓ

τ

ℓˆ

2. (N −→p N ′ ) =⇒ (∃M ′ , M ′′ · M =⇒p M ′ −→p M ′′ ∧ (M ′ , N ) ∈ R ∧ (M ′′ , N ′ ) ∈ R) The above definition does not lead to an adequate refinement notion since it does not preserve branching structure. The Figure 8 shows an example of a model refining another model without preserving the branching structure; R = {(0, 0), (2, 0), (3, 1)} is the relation that relates these models according to the previous definition. The reason why this definition does not preserve the branching structure is that it does not guarantee that all intermeτ diate states of M =⇒p M ′ are related to N , in other words the stuttering lemma of Section 2 does not generalise to MTS. A workaround to this problem could be to strengthen the definition of branching refinement by explicitly requiring stuttering to be preserved. The definition that would be obtained is the following:

than the initial state. In particular it solves the problem of Figure 8. However, this definition has another problem. If we consider the set of implementations of M and N , the fact that one is included in the other one does not imply the existence of a refinement relation between them, i.e. Ib2 [M ] ⊇ Ib2 [N ] 6⇒ M b2 N . Figure 9 shows an example of this case. While the two models shown have the same set of possible implementations according to Definition 12, there is no appropriate refinement relation for A2 b2 A1. Because of this, Definition 12 is inappropriate since one could end up creating a model that properly restricts the set of possible implementations defined by the previous model but that could be not considered a valid evolution due to the inexistence of a refinement relation between the two models.

0

τ?

1

a

6b2

2

0

a?

1

Figure 9: Two models that have the same set of implementations according Definition 12 but one is not a refinement of the other according the same definition. To overcome these limitations, rather than defining the MTS semantics by giving a refinement notion and defining the notion of implementation on top of it, we adopt the opposite strategy: We first define Branching Implementation and then give a definition for branching refinement based on that of Branching Implementation. Definition 13. (Branching Implementation) Let ℘ be the universe of all LTS and δ of all MTS. Let M a MTS, and I a LTS such that αM = αI, I is a branching implementation of M ,written M b I , if and only if (M, I) is contained in some implementation relation R ⊆ δ × ℘ for which the following holds for all ℓ ∈ Actτ : ℓ

1. (M −→r M ′ ) =⇒ (∃ I0 , . . . , In , I ′ · I0 = I ∧ τ Ii −→ Ii+1 ∀ 0 ≤ i < n ∧ ℓˆ

In −→ I ′ ∧ (M ′ , I ′ ) ∈ R ∧ (M, Ii ) ∈ R ∀ 0 ≤ i ≤ n) ℓ 2. (I −→ I ′ ) =⇒ (∃ M0 , . . . , Mn , M ′ · M0 = M ∧ τ Mi −→p Mi+1 ∀ 0 ≤ i < n ∧ Definition 12. (Na¨ıf 2 branching refinement) N is a branchℓˆ ing refinement of M , written M b2 N , if αM = αN and Mn −→p M ′ ∧ (M ′ , I ′ ) ∈ R ∧ (M, N ) is contained in some refinement relation R ⊆ δ × δ (Mi , I) ∈ R ∀ 0 ≤ i ≤ n) for which the following holds for all ℓ ∈ Actτ : From this definition, an associated notion of refinement ℓ 1. (M −→r M ′ ) =⇒ (∃ N0 , . . . , Nn , N ′ · N0 = N ∧ comes naturally: N is a refinement of M if all the implemenτ Ni −→r Ni+1 ∀ 0 ≤ i < n ∧ tations of N are implementations of M . This refinement is ℓˆ finer that weak refinement and therefore preserves properties Nn −→r N ′ ∧ (M ′ , N ′ ) ∈ R ∧ in 3 valued weak µ-calculus [4]. Thus we can check proper(M, Ni ) ∈ R ∀ 0 ≤ i ≤ n) ties at a family level gaining confidence over all products. ℓ ′ ′ 2. (N −→p N ) =⇒ (∃ M0 , . . . , Mn , M · M0 = M ∧ The results of checking a property against the behaviour of τ Mi −→p Mi+1 ∀ 0 ≤ i < n ∧ a product family given as an MTS can be true, f alse, or ℓˆ maybe. While true properties will hold in all products (i.e. Mn −→p M ′ ∧ (M ′ , N ′ ) ∈ R ∧ refinements) and f alse properties will hold in none, maybe (Mi , N ) ∈ R ∀ 0 ≤ i ≤ n) properties will be product specific. Model checking 3 valThis definition preserves branching structure since every ued weak µ-calculus formulae over an MTS reduces to two intermediate state a model goes through when simulating a classical model checks of 2-valued weak µ-calculus formulae transition on the other model is actually related to the initial over LTS. Consequently, there is no significant increase in state of that transition. Intuitively, this means that none complexity when checking properties over the entire family of those intermediate states present more or less behaviour rather than on one product at a time.

Clearly it can be observed that if this relation is restricted to LTS it coincides with branching equivalence. It can also be easily proved that if M b I and I ≈b I ′ then M b I ′ , and so this novel implementation relation is a sound extension of branching equivalence. In this way we have defined a new semantics over MTS that extends branching equivalence. The notion of Branching Implementation captures the intuition of behaviour conformance in software product lines adequately. In [11] we provide a large number of small examples that validate this claim. In particular, it can be shown that the behaviour model for the software controller of an electronic device depicted in Figure 5 does not conform to (i.e. is not a branching implementation of) the behaviour for the entire product family depicted in Figure 2. This result follows the intuition of conformance that a modeller may have of such product family. Note that a consequence of defining branching refinement as set inclusion of valid implementations is that it does not give an operational definition of refinement like weak and strong semantics have (Definitions 7 and 9). This is a shortcoming for defining tractable algorithms for checking branching refinement, and hence limits the support for iterative elaboration of partial behaviour models. We leave such an operational definition of branching refinement for future work. However, the notion of Branching Implementation can be checked, and hence an algorithm for checking conformance of the behaviour of a product against its product family’s behaviour can be formulated. We do this in the next section.

BS(M, I, I ′ , ℓ, R) ≡ ∃(M0 , . . . , Mn , M ′ ) · M0 = M ∧ τ Mi −→p Mi+1 ∀ 0 ≤ i < n ∧ (Mi , I) ∈ R ∀ 0 ≤ i ≤ N ∧ ℓˆ

Mn −→p M ′ ∧ (M ′ , I ′ ) ∈ R) Theorem 1. Let be R, P ⊆ δ × ℘ such as R is branching implementation relation. If R ⊆ P then R ⊆ F (P ) Definition 15. Let A be an MTS we define the “reachaw bility” set of A as Reach(A) = { A′ | ∃w ∈ Act∗τ · A −→ A′ } Remark 1. Reach(A) is a finite set by definition of MTS. Theorem 2. Let M be an MTS and I an LTS, and R0 , R1 , . . . ⊆ δ × ℘ given by R0 = Reach(M ) × Reach(I) and Ri+1 = F (Ri ). Then there exists j such that: 1. Rj = Ri ∀i > j 2. (M, I) ∈ Rj ⇐⇒ M b I

In this section we present an algorithm for checking conformance as defined by Branching Semantics. In addition we comment on a tool we have constructed1 and used to validate our approach. Details on the tool and validation can be found in [11]. The algorithm for checking conformance is a fixed point algorithm that starts with the Cartesian product of the states and iteratively eliminates from it the pairs that are not valid according to the required relation. We first provide a formal definition of a function over the domain of binary relations between models and then we demonstrate that by applying this function iteratively it converges. Moreover, we demonstrate that if a branching implementation relation exists between models then the fix point to which the function converges is actually a branching implementation relation.

For a proof of the above theorems refer to [11]. The theorems prove the feasibility of using a fix-point algorithm to obtain a branching implementation relation. We have implemented the fix-point algorithm given above in a tool developed using Java 5. The tool not only checks if a given LTS is a branching implementation of a given MTS, but also checks if the former is a weak or strong implementation of the latter. It also can compare MTS models for weak, strong and na¨ıf 2 branching refinement. The procedure for checking these other relations can be given as fix-point algorithms similar to that of branching implementation. In order to express the complexity of the conformance checking for the different semantics we denote the number of states of the largest model given as input as n. Then, the spatial complexity is O(n2 ) for any semantics while the time complexity is in the worst case O(n5 ∗log(n)) for strong, O(n6 ∗ log(n)) for weak, and O(n4 ∗ n! ∗ log(n)) for branching semantics. For the particular case of LTS equivalence relations more efficient algorithms are known (e.g. [10]). However, this is not the case for implementation or refinement relations. We leave for future work the development of a more efficient check for branching implementation. We have used the tool to validate our approach. To aide its use, we extended the process algebra FSP, which originally has an LTS semantics and is the input to the LTSA tool [26], to describe MTS models. For an explanation of the extension of FSP, details on the tool and validation refer to [11].

Definition 14. Let ℘ be the universe of all LTS, δ of all MTS. F : P(δ × ℘) → P(δ × ℘) is defined by:

7.

6. CHECKING CONFORMANCE

F (R) = {(M, I) ∈ R | ℓ ∀ℓ, ∀M ′ · ((M −→r M ′ ) =⇒ F S(M, M ′ , I, ℓ, R)) ℓ ′ ∧ ∀ℓ, ∀I · ((I −→ I ′ ) =⇒ BS(M, I, I ′ , ℓ, R)) } where: F S(M, M ′ , I, ℓ, R) ≡ ∃(I0 , . . . ,In , I ′ ) · I0 = I∧ τ Ii −→ Ii+1 ∀ 0 ≤ i < n ∧ (M, Ii ) ∈ R ∀ 0 ≤ i ≤ n ∧ ℓˆ

In −→ I ′ ∧ (M ′ , I ′ ) ∈ R 1

Available at http://www.doc.ic.ac.uk/∼fdario/MTSTool/

DISCUSSION AND RELATED WORK

In this paper we have studied a particular kind of partial behaviour model, namely MTS models. We believe that they are a natural extension to the formalisms that have been successful for reasoning about system behaviour at the software architecture level [6]. However, other formalisms for which allow explicit modelling of lack of information exist. Partial Kripke structures [5] and Kripke Modal Transition Systems [17] extend Kripke structures to support propositions in states to be one of three values (true, false, and unknown). In our work, states do not have any semantics, focus is on interaction between system components and their environment, hence semantics is defined over the events that

fire transitions between states, hence we build on models in the labelled transition systems [23] style. Our definition of Modal Transition Systems is essentially that proposed by Larsen et al. [24]. However, in [24] all MTS have the same alphabet, the universe of all labels, while we extend the definition of MTSs to include a communication alphabet in line with [26]. Making the communication alphabet explicit allows scoping models and capturing the fact that system components may control and monitor different sets of events [20]. A notable event-based modelling framework for describing partial behaviour that has been specifically designed for describing behaviour of product families is that given by Muccini et al [29]. They extend LTS models with guarded transitions. Guards are predicates that are evaluate to true depending on the characteristics of the product in a product line may include. This provides in-built support, which MTS lack, for describing optional behaviour tied to highlevel product decisions. For example, transition menui may be guarded by a predicate bluetoothP resent, which is expected to be true if the device has bluetooth capabilities. We believe that the notion of branching semantics we present can, and should be adapted to the models given in [29] to provide a formal notion of behavioural conformance. Furthermore, it may be possible to encode such models in MTS using some form of naming convention for guards. Numerous extensions of MTS exist such as Mixed Transition Systems [9] and disjunctive modal transition systems [25]. The semantics we proposed could be studied for these formalisms too. We believe that existing weak and strong refinement notions in these settings will suffer from the same shortcomings as MTSs. A slightly different approach to modelling unknown behaviour is taken in [33, 28]. In [33] Partial Labelled Transition Systems, each state is associated with a set of actions that are explicitly proscribed from happening. Extended Transition Systems[28] also associate a set of actions with each state, but in this case it models the actions for which the state has been fully described. The relation between these models and MTS, and in particular, our notion of refinement has yet to be studied. Related work regarding refinement and simulation has been discussed extensively throughout the work. Our notions of branching refinement and branching implementation are heavily inspired on that of branching bisimulation, although as shown, the extension of branching bisimulation from LTS to MTS cannot be done straightforwardly. Numerous other refinement notions exist, both for LTS (such as trace, failures [32], and testing [7] refinement) and for other state-based modelling formalisms such as kripke structures. We have also compared extensively the notion of refinement we propose with respect to strong [24] and weak refinement [24] over MTS. Behaviour modelling of software product lines has also been addressed using scenario-based techniques [36, 1] and research into how use cases and scenarios can be used to support testing analysis exists [30, 22, 1, 27]. Their exists a natural relation between scenarios and partial behaviour models (e.g. [33]) which suggest that the results herein described are relevant for scenario-based approaches to product lines.

8. CONCLUSIONS AND FUTURE WORK Our research objective is the development of practical and

effective techniques with tool support for the elaboration of comprehensive behaviour models in a context where total information is not available, such as iterative and incremental software development processes and development of software product lines. Traditional behaviour models such as LTS are not adequate for such purpose while MTS models can be used to facilitate model elaboration, and in particular, they can provide a rigorous underpinning needed to support sound reasoning about the behaviour of software product line architectures. In this work we have analysed the adequacy of the existing semantics for MTS models for characterising conformance to a partial description of system behaviour with the aim of providing the grounding for a notion of conformance that can be used to support modelling and analysis of software product lines. We have argued why strong and weak semantics are not adequate and introduced a new semantics loosely based on the traditional branching semantics for LTS. Finally, we have developed a software tool to verify refinement and implementation notions analysed in this work. The tool supports an extended version of the FSP for modelling MTS. Future research is required to provide more efficient techniques for checking conformance of LTS models against MTS ones. Based on existing algorithms for refinement and bisimulation(e.g. [10]), we believe that a polinomial algorithm for verifying branching implementation may exist. In addition, an operational notion of branching refinement is needed to also allow comparing MTS models for refinement, this would extend the current support for checking implementations against product family descriptions to support stepwise refinement of the latter to the former. We also except to research algorithms that provide diagnostic information to the modeller when non-conforming models are analysed. Finally, we intend to continue to validate the ideas discussed in this paper by applying them to further case studies.

Acknowledgments We acknowledge EPRSC grant PBM EP/C541133/1, ANCyT BID PICT 11738 and UBACyT X020 for partially funding this work.

9.

REFERENCES

[1] A. Bertolino and S. Gnesi. Use Case-Based Testing of Product Lines. In Proceedings of the 9th European Software Engineering Conference held jointly with the 10th ACM SIGSOFT International Symposium on Foundations of Software Engineering (ESEC/FSE), pages 355–358, Sept. 2003. [2] J. Bosch. Design and use of software architectures: adopting and evolving a product-line approach. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 2000. [3] G. Brunet. “A Characterization of Merging Partial Behavioural Models”. Master’s thesis, Univ. of Toronto, January 2006. [4] G. Brunet, M. Chechik, and S. Uchitel. “Properties of Behavioural Model Merging”. formal methods 2006, hamilton, ontario canada. 2006. [5] G. Bruns and P. Godefroid. “Model Checking Partial State Spaces with 3-Valued Temporal Logics”. In CAV’99, volume 1633 of LNCS, pages 274–287, 1999.

[6] E. Clarke and J. Wing. “Formal Methods: State of the Art and Future Directions”. ACM Computing Surveys, 28(4):626–643, December 1996. [7] R. Cleaveland and M. Hennessy. Testing equivalence as a bisimulation equivalence. Formal Asp. Comput., 5(1):1–20, 1993. [8] P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison-Wesley Professional, Boston, MA, USA, 2002. [9] D. Dams. Abstract Interpretation and Partition Refinement for Model Checking. PhD thesis, Eindhoven University of Technology, The Netherlands, July 1996. [10] A. Dovier, C. Piazza, and A. Policriti. A fast bisimulation algorithm. In CAV, pages 79–90, 2001. [11] D. Fischbein. Branching semantics for modal transition systems. Master’s thesis, University of Buenos Aires, Department of Computing, April 2006. [12] A. Garg, M. Critchlow, P. Chen, C. V. der Westhuizen, and A. van der Hoek. An environment for managing evolving product line architectures. In International Conference on Software Maintenance, pages 358–367, 2003. [13] D. Garlan, R. T. Monroe, and D. Wile. Acme: Architectural description of component-based systems. In G. T. Leavens and M. Sitaraman, editors, Foundations of Component-Based Systems, pages 47–68. Cambridge University Press, 2000. [14] D. Garlan and D. E. Perry. Introduction to the special issue on software architecture. IEEE Trans. Softw. Eng., 21(4):269–274, 1995. [15] R. v. Glabbeek. What is branching time semantics and why to use it? In M. Nielsen, editor, The Concurrency Column, pages 190–198. Bulletin of the EATCS 53, 1994. [16] M. Hennessy and R. Milner. Algebraic laws for nondeterminism and concurrency. J. ACM, 32(1):137–161, 1985. [17] M. Huth. “Model-Checking Modal Transition Systems Using Kripke Structures”. In Proceedings of Third International Workshop on Verification, Model-Checking, and Abstract Interpretation, Venice, Italy, January 2002. [18] M. Huth. Refinement is complete for implementations. Formal Asp. Comput., 17(2):113–137, 2005. [19] M. Huth, R. Jagadeesan, and D. A. Schmidt. “Modal Transition Systems: A Foundation for Three-Valued Program Analysis”. In ESOP’01, volume 2028 of LNCS, pages 155–169, 2001. [20] M. Jackson. Software requirements & specifications: a lexicon of practice, principles and prejudices. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA, 1995. [21] M. Jazayeri, A. Ran, and F. van der Linden. Software architecture for product families: principles and practice. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2000. [22] E. Kamsties, K. Pohl, S. Reis, and A. Reuys. Testing Variabilities in Use Case Models. In International Workshop on Product Family Engineering (PFE), 2003.

[23] R. M. Keller. Formal verification of parallel programs. Commun. ACM, 19(7):371–384, 1976. [24] K. Larsen and B. Thomsen. “A Modal Process Logic”. In LICS’88, pages 203–210, 1988. [25] K. Larsen and L. Xinxin. “Equation Solving Using Modal Transition Systems”. In 5th Annual IEEE Symposium on Logic in Computer Science, pages 108–117, 1990. [26] J. Magee and J. Kramer. Concurrency: state models & Java programs. John Wiley & Sons, Inc., New York, NY, USA, 1999. [27] J. D. McGregor. Testing a Software Product Line. Technical Report CMU/SEI-2001-TR-022, Software Engineering Institute, Carnegie Mellon University, Dec. 2001. [28] R. Milner. A modal characterisation of observable machine-behaviour. In CAAP ’81: Proceedings of the 6th Colloquium on Trees in Algebra and Programming, pages 25–34, London, UK, 1981. Springer-Verlag. [29] H. Muccini and A. Bucchiarone. Formal behavioral specification of a product line architecture. Technical Report TRCS 014/2004, University of L’Aquila, 2004. [30] C. Nebut, F. Fleurey, Y. L. Traon, and J.-M. J´ez´equel. A Requirement-based Approach to Test Product Families. In International Workshop on Product Family Engineering (PFE), 2003. [31] D. E. Perry and A. L. Wolf. Foundations for the study of software architecture. SIGSOFT Softw. Eng. Notes, 17(4):40–52, 1992. [32] S. Schneider and S. A. Schneider. Concurrent and Real Time Systems: The CSP Approach. John Wiley & Sons, Inc., New York, NY, USA, 1999. [33] S. Uchitel, J. Kramer, and J. Magee. “Behaviour Model Elaboration using Partial Labelled Transition Systems”. In ESEC/FSE’03, pages 19–27, 2003. [34] R. J. van Gabbeek and W. P. Weijland. Branching time and abstraction in bisimulation semantics. J. ACM, 43(3):555–600, 1996. [35] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee. The koala component model for consumer electronics software. Computer, 33(3):78–85, 2000. [36] T. Ziadi, L. H´elou¨et, and J.-M. J´ez´equel. Modeling Behaviors in Product Lines. In International Workshop on Requirements Engineering for Product Lines (REPL), pages 33–38, Sept. 2002.