An infrastructure on top of
configuration management
Michalis Anastasopoulos
Outline
• Foundations
• Problem Statement
• Contribution
Foundations
•
Product Line Engineering (PLE) is an approach that comes with
true order-of-magnitude improvements
-
cost
-
schedule
-
quality
Focus of this work
To control
– over time –
When is this type of control necessary?
Typically in bigger product line organizations
in which reusable and specialized artifacts
evolve in parallel
Seite 6/42
IWPSE-EVOL’09
Copyright © Fraunhofer IESE 2009
High-level Product Line Development Process
Development with reuse
Main Evolution Control Scenarios
•
Controlling changes made on reusable assets
(called core assets)
•
Controlling changes made on product-specific assets
(called instances) derived from core assets
•
Controlling changes on product-specific assets that have been
What does evolution control actually mean? (1/2)
What does evolution control actually mean? (1/2)
Control loop in SPL evolution
Change Request
Configuration Management (1/2)
•
Configuration Management (CM) is a mature and established
discipline for managing the evolution of (single) systems
•
Basic Functions of Configuration Management
- Identification
- Control
- Status Accounting
Configuration Management (2/2)
•
In practice there are two main strategies addressing
the PLE evolution control scenarios
-
Branching
Main line of development
Branching Example
Special line of development (e.g. Product A) Special line of development (e.g. Product B)Branch off Branch off
Integrate back to mainline
Propagate Propagate to
Build Management Example: Linux Kernel
Build selected
system
Outline
• Foundations
• Problem Statement
• Contribution
Problem statement
•
Configuration management is an established technology
yet it does not directly address the PLE evolution scenarios
•
The user has to combine
many low-level operations
for
performing each of the evolution scenarios
•
This can become a problem as
Seite 18/42
Illustrative Example: Sample Instantiations (black box)
Product 1
Illustrative Example: Traceability given through CM
Product 1 branch of S
Product 1 branch of A
Illustrative Example: Complexity of CM
1. Open the version graph of S
2. Identify the product branches (there may be many other temporary
branches next to the product branches)
3. For each product branch look for new S versions since the last
synchronization between family and Application Engineering
4. For each new version of S query the configuration management system
for the changes made in that version
5. Filter out product-specific changes and identify changes that may affect
S
Outline
• Foundations
• Problem Statement
• Contribution
Contribution
•
The 5 steps discussed above could be subsumed under a single
logical command
-
findInstanceChanges(S)
•
This logical command would encapsulate and automate the
underlying Configuration Management operations
•
The contribution lies in the
definition
and
realization
of logical
commands like the above that
Sample
Outline
• Foundations
• Problem Statement
• Contribution
Current Validations
•
Controlled Experiment
Controlled Experiment
• H1: The proposed method significantly reduces
the effort in terms of time necessary for performing evolution control operations
- Framework Engineering
- Application Engineering
• H2: The proposed method significantly
increases the efficiency for controlling the evolution of a product line
- repository complexity increase rate
Seite 30/42
IWPSE-EVOL’09 Amsterdam, 24.08.2009
Copyright © Fraunhofer IESE 2009
Setup
Variable Type
The approach in use Independent Students experience Independent Necessary time Dependent Complexity increase Dependent Correctness Dependent Family Engineering Application Engineering CL 2, 7, 9, 10 1, 6, 8, 13 SVN 3, 5, 11 4, 12, 14
Family Engineer Application Engineering Task 1 Create core assets Create instances
Task 2 Change core assets Change instances
Task 3 Find instances of core assets
Find the origins of instances (i.e. core assets they have been derived
Variables
Groups
Results
H1
28%
improvement
in average
Results
H2
H2
does
not
validate
(only H2.2
validates)
Analysis H2
•
H2.1 (complexity reduction) did not validate
-
false usage led to many unnecessary versions
-
however the CL gives by default more freedom and the
probability of creating many unnecessary version is high
•
H2.2 (correctness) did validate
-
CL users solved all tasks correctly
Statistical Analysis of Experiment Results
•
No statistical significance could be achieved
- Not enough data points were available
•
Statistical Tests performed thus far
- t-test not applicable (chi-test negative, no normal distributions)
- wilcoxon-test applicable but showed no significance
- (pending) two-way analysis of variance suffering from limited
Simulation Study
•
Goal
- to overcome the significance problems
•
Approach
- Gain more data points through simulation
Simulation Results
•
Simulation increased the observations to 289 from 32
•
19% improvement could be shown
•
Statistical significance could be shown
Further results of simulation: Service time analysis
8%
Conclusions
• Controlling the evolution of Product Lines is difficult in current practice
- CM used by default
- yes traditional CM does not explicitly address the scenarios in PLE
• Solution approach is to encapsulate CM
- explicitly address PLE scenarios
- hide away the complexity
- automate
• Initial Validations were positive
Feedback Questions
• Have you seen this problem in practice?
• Do you see something missing from this
research?
• Do you see formalization as a necessary
ingredient?
Debate Questions
• Can processes solve evolution problems?
- e.g. formal change processes
• Which field of Software Evolution research is
missing currently sound empirical studies the most?
• What are proper ways of obtaining empirical
Thank you for your attention!
Contact Information
Michail Anastasopoulos: [email protected]
+49 (631) 6800-2264
