[PPT] - Model-driven Engineering of Software Product Lines P. Heymans, P-Y. PowerPoint Presentation

SLIDE 1

1

University of Namur, Belgium

Computer Science Faculty

Model-driven Engineering of Software Product Lines

P. Heymans, P-Y. Schobbens, J-C. Trigaux, G. Saval
R. Matulevicius, A. Classen, A. Hubaux, Y. Bontemps

University of Namur, Belgium

PReCISE Research Centre in Information Systems Engineering www.software-engineering.be

MoVES general meeting, Namur, 25/05/07

SLIDE 2

2

University of Namur, Belgium

Computer Science Faculty

Model-based Engineering of Software Product Lines

1. Model-based Engineering

f Evolving Data-intensive

Systems

2. Model-based Engineering of Software Product Lines

3. A Flexible MetaCase Environment to support Domain-Specific Visual Languages 4. Measuring the Quality of Programs and Models to Support their Evolution 5. Business-IT Alignment

1. Introduction to Software Product Lines
2. Feature Diagrams
3. Comparative Survey and Formalisation
4. Separation of Concerns
5. Feature Interaction Detection
6. Possible Contributions to MoVES WPs

SLIDE 3

3

University of Namur, Belgium

Computer Science Faculty

D o m a i n E n g i n e e r i n g

Software Product Line Engineering (SPLE)

Domain Domain Analysis Analysis Domain Domain Design Design Domain Domain

Implementation Implementation

Application Application

Requirements Requirements

Application Application Design Design Application Application Coding Coding

Reference Reference Requirements Requirements Reusable Reusable Components Components Reference Reference Architecture Architecture

A p p l i c a t i o n E n g i n e e r i n g

Domain Expertise

New Requirements

Core Core Assets Assets

Feedback/ Adaptation Final Products

www.sei.cmu.edu/productlines

SLIDE 4

4

University of Namur, Belgium

Computer Science Faculty

SPLE — The philosophy

Institutionalised reuse
Proactive approach to software evolution
Anticipating change through variability management
identifying variability
realizing variability

From opportunistic reuse... ...to planned and systematic reuse Subroutines 70’s Objects 80’s Components 90’s

Product Lines

SLIDE 5

5

University of Namur, Belgium

Computer Science Faculty

Key Advantages

Economies of scale
systematic reuse of requirements, components, architecture, code, tests,...
e.g., HP (printer firmware) reduced resources to 25%
Shorter time-to-market
e.g., HP reduced development time by 33%
New developments made less risky
from radical to normal design
e.g., HP reported 96% fewer defects

Many other success stories: Philips, Nokia, Daimler-Chrysler, Bosch, Lucent (phone switches), MarketMaker, NRO (sattelite software),...

[Comm. ACM, December 2006]

SLIDE 6

6

University of Namur, Belgium

Computer Science Faculty

Key Challenges

High upfront costs
Fitness for purpose is even more crucial
business case and requirements influence the viability of a whole family
Variability Management
variability modelling — feature interaction — SPL evolution — automation

Accumulated costs Number of different systems Upfront investment Break Even Point Lower cost per system

[Comm. ACM, December 2006]

single product dev. PL dev.

SLIDE 7

7

University of Namur, Belgium

Computer Science Faculty

Mobile Phone Keyboard Messaging Imaging Connectivity Dial Voice Chat MMS Picture Messaging Camera Video WAP Bluetooth WAP 2.0 WAP 1.0

Root Optional Feature XOR decomposition Mandatory Feature AND decomposition

Additional constraint(s): Picture Messaging requires Camera

High-level Modelling of Variability with Feature Diagrams (FD)

FODA: Feature-Oriented Domain Analysis [Kang et al., 1990]

Alternative Features

SLIDE 8

8

University of Namur, Belgium

Computer Science Faculty

Mobile Phone Keyboard Messaging Imaging Connectivity Dial Voice Chat MMS Picture Messaging Camera Video WAP Bluetooth WAP 2.0 WAP 1.0

Root Optional Feature XOR decomposition Mandatory Feature AND decomposition

Additional constraint(s): Picture Messaging requires Camera

High-level Modelling of Variability with Feature Diagrams (FD)

Alternative Features

SLIDE 9

9

University of Namur, Belgium

Computer Science Faculty

Mobile Phone Keyboard Messaging Imaging Connectivity Dial Voice Chat MMS Picture Messaging Camera Video WAP Bluetooth WAP 2.0 WAP 1.0

Root Optional Feature XOR decomposition Mandatory Feature AND decomposition

Additional constraint(s): Picture Messaging requires Camera

High-level Modelling of Variability with Feature Diagrams (FD)

Alternative Features

SLIDE 10

10

University of Namur, Belgium

Computer Science Faculty

Problems with FDs

Research fragmentation
many languages, no standard
mostly informally defined
pros and cons misunderstood
No clear modelling guidelines
what’s in a feature?
how to deal with large variability models?
Rudimentary automated support
underexploited automation
suboptimal or incorrect algorithms proposed

SLIDE 11

11

University of Namur, Belgium

Computer Science Faculty

Existing FD languages

FODA (OFT) [Kang et al., 1990] FORM (OFD) [Kang et al., 1998] FeatuRSEB (RFD) [Griss et al., 1998] VBFD [van Gurp et al., 2001] EFD [Riebisch et al., 2002]

Gen. Prog. (GPFT)

[Czarnecki et al., 2000] PLUSS (PFT) [Eriksson et al., 2005]

SLIDE 12

12

University of Namur, Belgium

Computer Science Faculty

Existing FD languages

FODA (OFT) [Kang et al., 1990] FORM (OFD) [Kang et al., 1998] FeatuRSEB (RFD) [Griss et al., 1998] VBFD [van Gurp et al., 2001] EFD [Riebisch et al., 2002]

Gen. Prog. (GPFT)

[Czarnecki et al., 2000] PLUSS (PFT) [Eriksson et al., 2005]

Aesthetic differences

SLIDE 13

13

University of Namur, Belgium

Computer Science Faculty

Existing FD languages

FODA (OFT) [Kang et al., 1990] FORM (OFD) [Kang et al., 1998] FeatuRSEB (RFD) [Griss et al., 1998] VBFD [van Gurp et al., 2001] EFD [Riebisch et al., 2002]

Gen. Prog. (GPFT)

[Czarnecki et al., 2000] PLUSS (PFT) [Eriksson et al., 2005]

Aesthetic differences Stronger claims

SLIDE 14

14

University of Namur, Belgium

Computer Science Faculty

Existing FD languages

FODA (OFT) [Kang et al., 1990] FORM (OFD) [Kang et al., 1998] FeatuRSEB (RFD) [Griss et al., 1998] VBFD [van Gurp et al., 2001] EFD [Riebisch et al., 2002]

Gen. Prog. (GPFT)

[Czarnecki et al., 2000] PLUSS (PFT) [Eriksson et al., 2005]

Aesthetic differences Stronger claims

V a g u e u s e

f

t e r m s

s y n t a x , s e m a n t i c s , e x p r e s s i v e n e s s , a m b i g u i t y , . . .

SLIDE 15

15

University of Namur, Belgium

Computer Science Faculty

Attacking Research Fragmentation

Formal definition of FODA
General formal definition of FODA-inspired languages
Survey according to formal criteria
ambiguity — expressiveness — embeddability — succinctness
complexity of decision procedures

[Bontemps et al., ICFI, 2004] [Schobbens et al., RE, 2006] [Schobbens et al., J. Computer Networks, 2007]

SLIDE 16

16

University of Namur, Belgium

Computer Science Faculty

...

Generic syntactic domain LFFD (GT,NT,GCT,TCL) All the FDs one can write in a language of the FFD family

All the diagrams one can write in LOFT All the diagrams one can write in LOFD All the diagrams one can write in LPFT

Common semantic domain SFFD = PL All the possible meanings

f FDs

Common semantic function MFFD

Generic Formal Semantics through FFD

SLIDE 17

17

University of Namur, Belgium

Computer Science Faculty

The LFFD generic abstract syntax

Every FD d ∈ LFFD(GT,NT,GCT,TCL) is a tuple (N,r, λ,DE,CE,Φ) such that

N the set of nodes
r ∈ N the root
DE ⊆ N × N the decomposition edges

(obeying GT)

λ : N→NT the function labelling

nodes with boolean operators

CE ⊆ N × GCT × N the constraint edges
Φ ⊆ TCL the textual constraints
+ 4 well-formedness constraints

e.g. only r has no parent f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

SLIDE 18

18

University of Namur, Belgium

Computer Science Faculty

The LFFD generic abstract syntax

Every FD d ∈ LFFD(GT,NT,GCT,TCL) is a tuple (N,r, λ,DE,CE,Φ) such that

N the set of nodes
r ∈ N the root
DE ⊆ N × N the decomposition edges

(obeying GT)

λ : N→NT the function labelling

nodes with boolean operators

CE ⊆ N × GCT × N the constraint edges
Φ ⊆ TCL the textual constraints
+ 4 well-formedness constraints

e.g. only r has no parent f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

r: f1

SLIDE 19

19

University of Namur, Belgium

Computer Science Faculty

The LFFD generic abstract syntax

Every FD d ∈ LFFD(GT,NT,GCT,TCL) is a tuple (N,r, λ,DE,CE,Φ) such that

N the set of nodes
r ∈ N the root
DE ⊆ N × N the decomposition edges

(obeying GT)

λ : N→NT the function labelling

nodes with boolean operators

CE ⊆ N × GCT × N the constraint edges
Φ ⊆ TCL the textual constraints
+ 4 well-formedness constraints

e.g. only r has no parent f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

SLIDE 20

20

University of Namur, Belgium

Computer Science Faculty

The LFFD generic abstract syntax

Every FD d ∈ LFFD(GT,NT,GCT,TCL) is a tuple (N,r, λ,DE,CE,Φ) such that

N the set of nodes
r ∈ N the root
DE ⊆ N × N the decomposition edges

(obeying GT)

λ : N→NT the function labelling

nodes with boolean operators

CE ⊆ N × GCT × N the constraint edges
Φ ⊆ TCL the textual constraints
+ 4 well-formedness constraints

e.g. only r has no parent f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

Conventionally, for a leaf node n, λ(n) =and0

SLIDE 21

21

University of Namur, Belgium

Computer Science Faculty

The LFFD generic abstract syntax

Every FD d ∈ LFFD(GT,NT,GCT,TCL) is a tuple (N,r, λ,DE,CE,Φ) such that

N the set of nodes
r ∈ N the root
DE ⊆ N × N the decomposition edges

(obeying GT)

λ : N→NT the function labelling

nodes with boolean operators

CE ⊆ N × GCT × N the constraint edges
Φ ⊆ TCL the textual constraints
+ 4 well-formedness constraints

e.g. only r has no parent f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

SLIDE 22

22

University of Namur, Belgium

Computer Science Faculty

The LFFD generic abstract syntax

Every FD d ∈ LFFD(GT,NT,GCT,TCL) is a tuple (N,r, λ,DE,CE,Φ) such that

N the set of nodes
r ∈ N the root
DE ⊆ N × N the decomposition edges

(obeying GT)

λ : N→NT the function labelling

nodes with boolean operators

CE ⊆ N × GCT × N the constraint edges
Φ ⊆ TCL the textual constraints
+ 4 well-formedness constraints

e.g. only r has no parent f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

SLIDE 23

23

University of Namur, Belgium

Computer Science Faculty

Overview of FD abstract syntaxes

∅

requires, excludes and ∪ xor ∪ or ∪ {opt1}

TREE

PLUSS (PFT)

CR

∅

and ∪ xor ∪ or ∪ {opt1}

TREE

Gen. Prog.

(GPFT)

CR

requires, excludes card ∪ {opt1}

DAG

Riebisch et al. (EFD)

CR

requires, excludes and ∪ xor ∪ or ∪ {opt1}

DAG

van Gurp et al. (VBFD)

CR

requires, excludes and ∪ xor ∪ or ∪ {opt1}

DAG

FeatuRSEB (RFD)

CR

∅

and ∪ xor ∪ {opt1}

DAG

FORM (OFD)

CR

∅

and ∪ xor ∪ {opt1}

TREE

FODA (OFT)

TCL GCT

NT GT

Language

SLIDE 24

24

University of Namur, Belgium

Computer Science Faculty

Semantic domain

A configuration is a set of nodes/features
A product is a set of primitive nodes/features
A product line (PL) is a set of products

f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

∈ ℘N

f1 f3 f4 f5 f6 f7

SLIDE 25

25

University of Namur, Belgium

Computer Science Faculty

Semantic domain

A configuration is a set of nodes/features
A product is a set of primitive nodes/features
A product line (PL) is a set of products

f1 f5 f6 f7

∈ ℘N

f1 f3 f4 f5 f6 f7

∈ ℘P

remove non-primitive features

where P ⊆ N

f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

e.g., if f3 and f4 are ‘‘irrelevant’’ (non-primitive) for the stakeholders

SLIDE 26

26

University of Namur, Belgium

Computer Science Faculty

Semantic domain

A configuration is a set of nodes/features
A product is a set of primitive nodes/features
A product line (PL) is a set of products

∈ SFFD = PL = ℘℘P

f4 f5 f6 f7 f4 f5 f7 f6

SLIDE 27

27

University of Namur, Belgium

Computer Science Faculty

Semantic function’s signature — MFFD: LFFD → PL

... ... LFFD PL MFFD

SLIDE 28

28

University of Namur, Belgium

Computer Science Faculty

Semantic function’s definition ∀ d ∈ LFFD • M’FFD(d) is the PL s.t.

r (the root) is in every configuration
the meaning of the operators is satisfied
Φ (textual constraints) are satisfied
CE (graphical constraints) are satisfied
if a node s (≠ r) is in the configuration,
ne of its parents must be too

(justification rule) ...

f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

M’FFD(d) =

SLIDE 29

29

University of Namur, Belgium

Computer Science Faculty

Semantic function’s definition ∀ d ∈ LFFD • M’FFD(d) is the PL s.t.

r (the root) is in every configuration
the meaning of the operators is satisfied
Φ (textual constraints) are satisfied
CE (graphical constraints) are satisfied
if a node s (≠ r) is in the configuration,
ne of its parents must be too

(justification rule)

f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

...

f1 ... f1 ... f1 ...

M’FFD(d) =

SLIDE 30

30

University of Namur, Belgium

Computer Science Faculty

Semantic function’s definition ∀ d ∈ LFFD • M’FFD(d) is the PL s.t.

r (the root) is in every configuration
the meaning of the operators is satisfied
Φ (textual constraints) are satisfied
CE (graphical constraints) are satisfied
if a node s (≠ r) is in the configuration,
ne of its parents must be too

(justification rule)

f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

...

f1 f2 ... f1 f3 f4 f5 f6 ... f1 f2 f3 ...

M’FFD(d) =

SLIDE 31

31

University of Namur, Belgium

Computer Science Faculty

Semantic function’s definition ∀ d ∈ LFFD • M’FFD(d) is the PL s.t.

r (the root) is in every configuration
the meaning of the operators is satisfied
Φ (textual constraints) are satisfied
CE (graphical constraints) are satisfied
if a node s (≠ r) is in the configuration,
ne of its parents must be too

(justification rule)

f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

...

... ... f1 f2

M’FFD(d) =

SLIDE 32

32

University of Namur, Belgium

Computer Science Faculty

Semantic function’s definition ∀ d ∈ LFFD • M’FFD(d) is the PL s.t.

r (the root) is in every configuration
the meaning of the operators is satisfied
Φ (textual constraints) are satisfied
CE (graphical constraints) are satisfied
if a node s (≠ r) is in the configuration,
ne of its parents must be too

(justification rule)

f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

...

... ... f1 f3 f4 f5 f6 f7 f8

M’FFD(d) =

SLIDE 33

33

University of Namur, Belgium

Computer Science Faculty

Semantic function’s definition ∀ d ∈ LFFD • M’FFD(d) is the PL s.t.

r (the root) is in every configuration
the meaning of the operators is satisfied
Φ (textual constraints) are satisfied
CE (graphical constraints) are satisfied
if a node s (≠ r) is in the configuration,
ne of its parents must be too

(justification rule)

f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

...

... ... f1 f2 f5 f7 f6

M’FFD(d) =

SLIDE 34

34

University of Namur, Belgium

Computer Science Faculty

Semantic function’s definition

f1 f2 f3 f4 f5 f6 f7 f8

f2 requires f5

requires excludes

λ(f1) = or2 λ(f3) = and3 λ(f4) = or2

f1 f3 f4 f5 f6 f7 f1 f2 f3 f4 f5 f6 f7

M’FFD(d) = ∀ d ∈ LFFD • M’FFD(d) is the PL s.t.

r (the root) is in every configuration
the meaning of the operators is satisfied
Φ (textual constraints) are satisfied
CE (graphical constraints) are satisfied
if a node s (≠ r) is in the configuration,
ne of its parents must be too

(justification rule)

SLIDE 35

35

University of Namur, Belgium

Computer Science Faculty

Semantic function’s definition

f1 f5 f6 f7 f1 f2 f5 f6 f7

MFFD(d) =

f1 f3 f4 f5 f6 f7 f1 f2 f3 f4 f5 f6 f7

M’FFD(d) =

remove non-primitive features

SLIDE 36

36

University of Namur, Belgium

Computer Science Faculty

Main findings

Ambiguities found in most languages, but FODA
Most languages are expressively complete (when more than trees)
They actually compete for ‘‘readability’’
Card operators alone allow for expressive completeness and

‘‘natural’’ modelling (& traceability)

f1 f2 f3 f4 f5 f6? f7 f8

λ(f1) = or2 λ(f3) = and3 λ(f4)

= xor2

f6 f1 f2 f3 f4 f5 f6? f7 f8

λ(f1) = card2[1..2] λ(f3) = card3[3..3] λ(f4)

= card2[1..1]

f6

λ(f6)

= card1[0..1]

λ(f6)

= opt1

LVFD = LFFD(DAG, card, ∅, ∅)

SLIDE 37

37

University of Namur, Belgium

Computer Science Faculty

Decision Problems and Complexity

Satisfiability: MFFD(d) ≠ ∅
NP-complete
linear for many tree-shaped graphs
Product checking: {f1,...,fn} ∈ MFFD(d)
NP-complete
linear for many tree-shaped graphs, or if P = N
Equivalence: MFFD(d1) = MFFD(d2)
Π1-complete
Tractability issues but efficient algorithms in many common cases
Existing algorithms can now be proved for correctness and optimality

SLIDE 38

38

University of Namur, Belgium

Computer Science Faculty

More Decision Problems

Dead features: P \ ∪ MFFD(d)
Commonalities: ∩ MFFD(d)
‘‘Merging’’ FDs: construct d3 from d1 and d2 s.t.
Intersection: MFFD(d3) = MFFD(d1) ∩ MFFD(d2)
Union: MFFD(d3) = MFFD(d1) ∪ MFFD(d2)
Reduced product:

MFFD(d3) = {p1 ∪ p2  p1 ∈ MFFD(d1) ∧ p2 ∈ MFFD(d2)}

etc... [Benavides et al., JISBD, 2006]

Decision problems disambiguated wrt [Benavides et al.,JISBD’06]

SLIDE 39

39

University of Namur, Belgium

Computer Science Faculty

Comparative Semantics

FODA (OFT) [Kang et al., 1990] FORM (OFD) [Kang et al., 1998] FeatuRSEB (RFD) [Griss et al., 1998] VBFD [van Gurp et al., 2001] EFD [Riebisch et al., 2002]

Gen. Prog. (GPFT)

[Czarnecki et al., 2000] PLUSS (PFT) [Eriksson et al., 2005] [Batory, SPLC, 2005] [Czarnecki et al., SPIP, 2005] [Benavides et al., CAiSE, 2005] vDFD [van Deursen et al., 2002] [Sun et al., ICECCS, 2005]

Tool-based semantics can be complex and error-prone
transformations are cumbersome
semantic domains are too rich
simple rules (e.g., justification) are often forgotten
Proposed a general method for comparative semantics

[Trigaux et al., CERE’06] [Heymans et al., SVM-WS’07]

SLIDE 40

40

University of Namur, Belgium

Computer Science Faculty

What’s in a Feature? (part I)

No agreement on what a feature is
Our review of definitions and usages suggests to distinguish

(at least) between

f2: Payment Upon Invoice Online Store f4: Credit Card Payment f3: Check of Credit History «requires» f1: Debit Card Payment

Optional Feature Mandatory Feature

f2: Payment Upon Invoice Online Store f4: Creidt Card Payment f3: Check of Credit History f1: Debit Card Payment

Alternative Features

Required Variability Provided Variability

From marketing, customers, product management From existing software assets

[Metzger&Heymans,TR, 2006]

Optional Features

SLIDE 41

41

University of Namur, Belgium

Computer Science Faculty

What’s in a Feature? (part I)

No agreement on what a feature is
Our review of definitions and usages suggests to distinguish

(at least) between

f2: Payment Upon Invoice Online Store f4: Credit Card Payment f3: Check of Credit History «requires» f1: Debit Card Payment

Optional Feature Mandatory Feature

f2: Payment Upon Invoice Online Store f4: Creidt Card Payment f3: Check of Credit History f1: Debit Card Payment

Alternative Features

Required Variability Provided Variability

From marketing, customers, product management From existing software assets

[Metzger&Heymans,TR, 2006]

Optional Features

Mismatch !

SLIDE 42

42

University of Namur, Belgium

Computer Science Faculty

Separation of Concerns and Automation

f4: Credit Card Payment

Provided Variability (FD) Required Variability (OVM)

Feature must be in all PL members Feature must be in the PL member iff variant is chosen Optional Variant f2: Payment Upon Invoice Online Store f3: Check of Credit History f1: Debit Card Payment Alternative Features Optional Feature Online Store

VP1

Payment by Debit Card

V1

Payment Upon Invoice

V2

Check of Credit History

V3

requires Variation Point

1..1

FD X-links OVM F O SAT The idea Automation

Reduction to SAT
Consistency checks, e.g.
Unrealizable required variability

M(O) \ M(G)|PO

Unused provided variability

M(F) \ M(G)|PF

Internal SPL competition

(po ∪ pf) ∈ M(G) ∧(po’ ∪ pf) ∈ M(G) ∧ (po≠po’)

G VFD

[Metzger et al.,RE’07]

SLIDE 43

43

University of Namur, Belgium

Computer Science Faculty

What’s in a Feature? (part II)

RE makes a fundamental distinction between
requirements (R)—optative statements about the environment

‘‘only authorised users should have access to their calendar’’

domain hypotheses (W)—indicative statements about the environment

‘‘users do not disclose their passwords’’

specifications (S)—optative black-box descriptions of system behaviour

‘‘ users get access to their calendar by entering their password’’

Primary correctness argument: W, S R
Suggestion: each feature f stands for 3 (sets of) descriptions: Rf, Wf, Sf

⊥

[Classen, Master thesis, 2007] [Jackson & Zave,TOSEM’97]

SLIDE 44

44

University of Namur, Belgium

Computer Science Faculty

Problem-level Feature Interaction Detection

...

f1 f2 f3 ... ...

W1,S1 R1 W2,S2 R2 W3,S3 R3 W1,W2,S1,S2 R1,R2 W1,W3,S1,S3 R1,R3 W1,W2,W3,S1,S2,S3 R1,R2,R3 ⊥ ⊥ ⊥ ⊥ ⊥ ⊥

Current results
W, R, S expressed in Event Calculus and checked with Decreasoner
‘‘brute force’’ SAT based implementation
linked to the Problem Frames approach
applied to a Smart Home system product line
Future work
ptimize verification

[Classen, Master thesis, 2007]

     

SLIDE 45

45

University of Namur, Belgium

Computer Science Faculty

Feature Interaction Detection across Abstraction Levels

Formal models at all levels
Linked by formal refinement relationships
Features as model transformations

[Ryan&Schobbens, ICFI’04] POTS in logic POTS in Statecharts POTS in C POTS in Assembly Language POTS+MB in logic POTS+MB in Statecharts POTS+MB in C POTS+MB in Assembly Language transition systems micro-transitions

perational semantics

real-time semantics, interruptions

Message Box

+

requires: ... introduces: ... changes: ...

new

SLIDE 46

46

University of Namur, Belgium

Computer Science Faculty

Feature Interaction Detection across Abstraction Levels

4 types of interactions

Interlevel interaction (breaks refinement)

type  — impl. violates its introduced specification
type  — impl. violates the changed specification of former features
type  — impl. violates the changed specification of the base system

f7 ( f4 ( f5 ( base ) ) ) Intralevel interaction (breaks the order-independence of features)

type  — two sequences of the same features lead to different impl.

f7 ( f4 ( f5 ( base ) ) ) ≠ f4 ( f7 (f5 ( base ) ) ) f7 ( f4 ( f5 ( base ) ) ) spec. impl.

  

SLIDE 47

47

University of Namur, Belgium

Computer Science Faculty

Future Work and Contributions to MoVES WPs

WP2 — Models & Restructuring
Further formalise FD constructs
binding times — feature specialisation & implementation — attributes —

further separation of concerns

Formalise links between variability models and other models

(orthogonal variability) [G. Saval’s PhD 2006-2010]

Refactoring FDs
Comparative survey of goal modelling languages

[R. Matulevicius’ postdoc 2006-2008]

WP3 — Composition, Decomposition and Re-Composition
Integration of FD and Problem Frames [A. Classen’s PhD 2007-2011]

SLIDE 48

48

University of Namur, Belgium

Computer Science Faculty

Future Work and Contributions to MoVES WPs

WP4 — Consistency Checking and Co-evolution
... of separated variability models/concerns [A. Hubaux’s PhD 2007-2011]
... of variability models and other models
WP 5 — Refinement and Synthesis
Instantiation of the FIREworks framework with your favourite languages
WP7 — Incremental Design and Verification
Incremental Verification of W, S R in PL

[A. Classen’s PhD 2007-2011]

⊥

SLIDE 49

49

University of Namur, Belgium

Computer Science Faculty

That’s it...

Thank you! Any questions?

SLIDE 50

50

University of Namur, Belgium

Computer Science Faculty

...except for this shameless advertisement

Go there!

It’ll be fun !

Ireland is great

Did I mention that ? C’mon there’s much more than

It won’t rain, I promise