modern software systems
DESCRIPTION
SPLGraph: Towards a Formalism for Software Product Lines Itay Maman IBM Research – Haifa Goetz Botterweck Lero – The Irish software Engineering Research Centre May 2 nd 2010, PLEASE 2010. Modern Software Systems. Heterogonous artifacts Source code: C, Java, DSLs, … Design documents - PowerPoint PPT PresentationTRANSCRIPT
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