SPLGraph: Towards a Formalism for Software Product Lines

Itay Maman IBM Research – Haifa

Goetz Botterweck

Lero – The Irish software Engineering Research Centre

May 2nd 2010, PLEASE 2010

2/23

Modern Software Systems

Heterogonous artifacts –Source code: C, Java, DSLs, …–Design documents–User manuals–Licenses–Presentations

Heterogonous artifact-specific tools/editors

3/23

…IDE/CompilerDesign

ToolRequirements

Tool

Multi Product Tool Stack

Variability

Requirements Design Tests …

Feature Model

P1 configuration

Variability Variability Variability

RequirementsRequirements DesignDesign TestsCode ……P

1 A

rtifa

cts

Rev

iew

\E

dit

File Repository

4/23

Difficulties

Rework: Implementing variability in each tool

Lack of system wide traceability

Viewers cannot be used without the editors–E.g., Lint cannot be used without a variability-enabled IDE

Features are a special construct

5/23

Tool Stack: Centralized Variability

Feature Model + Materializer

P1 configuration

…IDE/CompilerDesign

ToolRequirements

Tool

Variability UI Variability UI Variability UI Variability UI

Requirements Design Tests …RequirementsRequirements DesignDesign TestsCode ……P

1 A

rtifa

cts

Rev

iew

\E

dit

File Repository

6/23

QA Scenario

Feature Model + Materializer

P1 configuration

Compiler

Design TestsDesignRequirements TestsCodeP1

Art

ifact

s

P1 can now be tested

Plain compiler –

no variability support

File Repository

RequirementsTool

7/23

Can Materialization be Centralized?

Vision: a dedicated, generic, product line tool–Handles a wide range of artifacts–Relieve tool vendors from implementing variability mechanisms

Similar to source control–IDEs do not try to roll out their own source control mechanism–(Other than UI support)–Variability is more difficult – finer granularity

8/23

Striking a balance

High Level Representations (E.g., UML)–Operations: deleteClass, replaceClass, deleteRequirement, …

–Representation is too Specific => Operations are not generic–(Too many operations to implement)

Low Level Representations: Stream of bits–Only three operations: deleteBit(offset), insertBit(offset, value),

replaceBit(offset, value) –Sensitivity to changes: when content changes all offsets must be

recalculated–(Impractical)

9/23

Wish List

Insensitivity to changes– Local changes in content => local changes in representation

Generic: A small number of variability operations– Work on all artifacts

Self sustainable: Variability can be defined on variability

Decidable

Solution: A directed, labeled, graph– Requires: A translation scheme (bi directional)

10/23

SPLGraph

A directed graph <V,E> –Defined as a 7-tuple

Label function: L(x) : V E → String

A set of mutation vertices: M

A set of decision vertices: D

Three special vertices: T, F, X

(Formalization & Patterns are in the paper)

11/23

Simple Example: “class a extends b”(no variability)

a bextends

se0

12/23

Mutation Vertex g

a

g e1

b

c

e1

subj

ect

key

target

a

g e1

b

c

e1

key

targetsubj

ect

apply(g)

13/23

Decision vertex h

h

a

b

s

f

t

e1

T

condition

y

xe2

e3

14/23

Traversal from vertex s

h

a

b

s

f

t

e1

T

condition

y

xe2

e3

15/23

Algorithm: Materialize

Inputs: G, N, P, s– G: An SPLGraph

– N, P: Sets of decision vertices (disjoint)

– s: A vertex

Steps:– Set the decision of all vertices in N to be F

• (Add a condition edge)

– Set the decision of all vertices in P to be T• (Ditto)

– Q = All vertices reachable from s

• (respecting the traversal semantics of decision vertices)

– For each mutation vertex q in Q do apply(q)

16/23

Example: “class a extends b”

h

a

g extends

b

c

s

f

t

extends

subj

ect

key

target

e1

materialize(G,{},{h},s)

h

a

g extends

b

c

s

f

t

extends

subj

ect

key

target

e1

Tcondition

17/23

Everything is a Vertex!

h1 a

g

f

extends

b

c

sf

t

extends

subjectkey

target

s1 g1

condition

key

e1

e3

target

subject

h2

e2

df

…

18/23

Prototype Tool

Can Import existing Java Code

Program elements can be marked as optional–Field, Method, Class, Package

Materialize => Generates a new program–Some of the optional elements are excluded–Determined by a user decision–The algorithm has no Java knowledge!–Can be extended by writing new translators

19/23

Performance: Graph Construction

Construction time vs. #Classes

0

2

4

6

8

10

12

14

16

100 200 300 400 500 600 700 800 900 1000 1100 1200 1300 1400 1500 1600

#Classes

Tim

e (S

econ

ds)

20/23

Scalability

Materialization time vs. #Vertices

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

20000 22500 25000 27500

#Vertices

Tim

e (S

econ

ds)

5000100001500020000

21/23

Future

Product line support in IBM/Rational Jazz platform–First steps: Rhapsody 7.5.2

Source Control vs. Product Lines

Graph-oriented Database

Streamlining the translation schemes API

22/23

Summary

Simplicity: A single kind of transformation–Namely: Edge rerouting

Self-sustainability: “Everything is a vertex”–The model can define variability on itself–Similar to the Object-model of object-oriented languages –(See: Smalltalk)

Decoupling materialization from artifacts

23/23

Questions ?

imaman@il.ibm.com

twitter.com/pembleton