Composing Feature Models

Composing Feature Models

Mathieu Acher1, Philippe Collet1, Philippe Lahire1, Robert France2

1 University of Nice Sophia Antipolis (France),

Modalis Team (CNRS, I3S Laboratory)

2 Computer Science Department,

Colorado State University

1

• Software Product Lines (SPL)– From common assets, different programs of a domain

can be assembled

– Promote systematic reuse

• Feature modeling– Widely used technique in SPL engineering

• domain analysis, requirements, code representation, etc.

• academic and industrial tool support

• Key idea: express variability of a family in terms of features

Why feature models?

2Mathieu Acher « Composing Feature Models »

• Hierarchy of features plus variability information

What is feature model?

Mathieu Acher « Composing Feature Models » 3



mandatory




optional5Mathieu Acher « Composing Feature Models »



alternative6Mathieu Acher « Composing Feature Models »



alternative (not mutually exclusive)7Mathieu Acher « Composing Feature Models »

• Represent a set of valid configurations

– Configuration: set of features selected

– Valid configuration: defined by the semantics

Feature models and Configuration







Person, housing, streetName, telephone, areaCode, transport, car


• Issues in Feature Modeling

• Requirements and Rationale for the Composition Language

• Composition Operators

• Conclusion and Future Work

Agenda


Feature Models


Feature Models


Feature Models

Scalability issues in terms of- construction- evolution- reasoning


Separating and ComposingFeature Models


Composing Feature Models


Design of a Language for Composing Feature Models

17

with predictable properties

Mathieu Acher « Composing Feature Models »

Requirements

insert merge


• Characterizing the result of a Compositional Operator in terms of sets of configurations

Rationale

FM1 FM2

Mathieu Acher « Composing Feature Models »


Rationale

FM1 FM2


Classification [Thüm, Batory and Kästner (ICSE’09)]


Rationale

Base Aspect

To predict which configurations will be removed, added, or/and kept…

We choose to distinguish Aspectfrom Base models


• Insert and Merge operators

• Ensure predictable properties between input feature models and composed feature models

– In terms of sets of configurations

– We choose to distinguish Aspect from Base models

• Describe operators in terms of

– What?

– Where?

– How?

Rationale (cont’d)


Insert Operator: Syntax

insert (aspectFeature: Feature, joinpointFeature: Feature, operator: Operator)

What? Where? How?

AspectBase



insert (urbanTransport, transport, Xor)

=Base

Aspect

Result



insert (urbanTransport, transport, And-mandatory)

=Base

Aspect

Result



insert (urbanTransport, transport, And-optional)

=Base

Aspect

Result



insert (urbanTransport, transport, And-optional)

=Base

Aspect

Result


Reasoning on the Result (1)

The set of configurations of the FM after insertion (Result) is at least the set of configurations of Base FM.

Base : {{B, B2}, {B, B1, B2 }}

=Base Aspect Result




Base : {{B, B2}, {B, B1, B2 }}Result : {{B, B2}, {B, B1, B2 }, {B, A, B1, B2 }, {B, A, A1, B1, B2 }, {B, A, A1, B, B2 }}

=Base Aspect Result




Base : {{B, B2}, {B, B1, B2 }}Result : {{B, B2}, {B, B1, B2 }, {B, A, B1, B2 }, {B, A, A1, B1, B2 }, {B, A, A1, B, B2 }}

=Base Aspect Result



The set of configurations of the FM after insertion (Result) is at least the set of configurations of Base FM. {{B, B2}, {B, B1, B2 }}{{B, B2}, {B, B1, B2 }, {B, A, B1, B2 }, {B, A, A1, B1, B2 }, {B, A, A1, B, B2 }}

Result FM is a generalization of Base FM.

=Base Aspect Result



=Base : {{B, B2}, {B, B1, B2 }}Aspect : {{A}, {A, A1}}

Result : {{B, A, B2}, {B, A, B1, B2 }, {B, A, A1, B1, B2 }, {B, A, A1, B, B2 }}

Base Aspect Result



=The set of configurations of Result is at least the set of configurationsof the “cross product” of Base and Aspect.

Base : {{B, B2}, {B, B1, B2 }}Aspect : {{A}, {A, A1}}Base * Aspect = Result

Base Aspect Result



=Base : {{B, B2}, {B, B1, B2 }}Aspect : {{A}, {A, A1}}Base * Aspect = ResultResult : {{B, A, B2}, {B, A, B1, B2 }, {B, A, A1, B1, B2 }, {B, A, A1, B, B2 }}

Base Aspect Result



=Base : {{B, B2}, {B, B1, B2 }}Aspect : {{A}, {A, A1}}Base * Aspect = ResultResult : {{B, A, B2}, {B, A, B1, B2 }, {B, A, A1, B1, B2 }, {B, A, A1, B, B2 }}

Base Aspect Result



=Base Aspect Result


merge (aspectFeature: Feature, baseFeature: Feature, mode: Mode)

Merge Operator: Principles

What? Where? How?




What? Where? How?

Renaming mechanism



• Two “modes”

– Union

– Intersection


What? Where? How?


Merge Operator: Intersection Mode

The intersection of two FMs, Base and Aspect, is a new FM where each configuration that is valid both in Base and Aspect, is also valid.




{{Person, transport, car}, {Person, transport, other}}44Mathieu Acher « Composing Feature Models »





Have a look at housing feature

No merged model


Merge Operator: Union Mode



The union of two FMs, Base and Aspect, is a new FM where each configuration that is valid either in Base or Aspect, is also valid.




• A set of composition operators dedicated to feature models – syntactic definition– documented properties (based on the semantics of feature

models)– rules and algorithm

• Related work– Schobbens et al.

+ intersection, union, and reduced product

- no implementation, more properties to cover

– Alves et al. + catalogue rules to refactoring feature models- merge is not fully considered

– Segura et al. + catalogue rules to merging feature models- semantics of the merge not defined (corresponds to union mode)

Conclusion


• Several cross-validity implementations– Kompose, ATL, AGG, etc.

• Feature Models extension– internal-constraints– inter-constraints (btw aspect and base models)– cardinality-based feature model

• Large scale validation– two case studies and SPLs:

• Medical Imaging Grid Services• Video Surveillance Systems

– “usage”, modular reasoning, etc.

Future Work


?53Mathieu Acher « Composing Feature Models »

http://www.i3s.unice.fr/~acher/

Education

Composing Feature Models