Coevolution of Variability Models and Related Artifacts A Case Study from the Linux Kernel Leonardo Passos 1 Jianmei Guo 1 Leopoldo Teixeira 2 Krzysztof Czarnecki 1 Andrzej Wąsowski 3 Paulo Borba 2 1 University of Waterloo 2 Federal University of Pernambuco 3 IT University 17th International Software Product Line Conference 1/32
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Coevolution of Variability Models and Related ArtifactsA Case Study from the Linux Kernel
Leonardo Passos1 Jianmei Guo1 Leopoldo Teixeira2
Krzysztof Czarnecki1 Andrzej Wąsowski3 Paulo Borba2
1University of Waterloo 2Federal University of Pernambuco 3IT University
17th International Software Product Line Conference
1/32
A concrete change from the Linuxkernel
2/32
Ralink Drivers
RT2860
...
... ...RT3090
2/32
Ralink Drivers
RT2860
...
... ...RT3090
2/32
Ralink Drivers
RT2860
...
... ...
Does it mean that RT3090 is no longer supported?
2/32
Ralink Drivers
RT2860
...
... ...
Does it mean that RT3090 is no longer supported?
2/32
Existing evolution studies tend to focuson the variability model alone
3/32
That doesn’t tell the whole story. . .
4/32
Ralink Drivers
RT2860... ...RT3090
5/32
Ralink Drivers
RT2860... ...RT3090
Variability model(Kconfig)
5/32
Ralink Drivers
RT2860... ...RT3090
Mapping(Makefiles)
5/32
Ralink Drivers
RT2860... ...RT3090
Implementation(.h and .c files)
5/32
Different artifacts, in different spaces,are connected. . .
5/32
Ralink Drivers
RT2860... ...RT3090
5/32
Ralink Drivers
RT2860... ...RT3090
5/32
Ralink Drivers
RT2860... ...RT3090
5/32
Ralink Drivers
RT2860... ...RT3090
Implementation file(.c or .h)
5/32
Ralink Drivers
RT2860... ...RT3090
macro directive(e.g.:, #ifdef RT2860)
5/32
With the three spaces in mind, the realpicture of . . .
6/32
Ralink Drivers
RT2860
...
... ...RT3090
is
6/32
Ralink Drivers
RT2860... ...RT3090
6/32
Ralink Drivers
RT2860... ...RT3090
copy
copy
copy
Therefore, RT3090 is merged into RT2860
6/32
Ralink Drivers
RT2860... ...RT3090
copy
copy
copy
Therefore, RT3090 is merged into RT28606/32
But, what can be said about the fewstudies that take coevolution into
account?
7/32
Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
◦ Case study restricted to refinement changes (guarantee productcompatibility)
• Seidl et al., SPLC 2012
◦ Validated over a small and fictitious example
8/32
Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
◦ Case study restricted to refinement changes (guarantee productcompatibility)
• Seidl et al., SPLC 2012
◦ Validated over a small and fictitious example
8/32
Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
◦ Case study restricted to refinement changes (guarantee productcompatibility)
• Seidl et al., SPLC 2012
◦ Validated over a small and fictitious example
8/32
Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
◦ Case study restricted to refinement changes (guarantee productcompatibility)
• Seidl et al., SPLC 2012
◦ Validated over a small and fictitious example
8/32
Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
◦ Case study restricted to refinement changes (guarantee productcompatibility)
• Seidl et al., SPLC 2012
◦ Validated over a small and fictitious example
8/32
Studies that consider coevolution
• Borba et al., GPCE 2011
◦ Small case study: Mobile Media and TaRGeT ≈ 40 features
◦ Unlikely to capture the complexity typically found in large systems
◦ Case study restricted to refinement changes (guarantee productcompatibility)
• Seidl et al., SPLC 2012
◦ Validated over a small and fictitious example
8/32
We need practical case studies ofvariability coevolution in large complex
variability rich software
9/32
Better understanding
tools mirroring coevolution as ithappens in practice
10/32
Our work
11/32
A catalog of 13 coevolution patternsfrom a large and complex system
(Linux kernel)
Provides a concrete set of coevolutionoperations performed in practice
12/32
A set of findings from the analyses ofthe catalog and its instances
Presented as take home lessons
13/32
Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
◦ 80, 000 compile-time variation points
◦ 16, 000 Makefiles
◦ 30, 000 header and C files
14/32
Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
◦ 80, 000 compile-time variation points
◦ 16, 000 Makefiles
◦ 30, 000 header and C files
14/32
Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
◦ 80, 000 compile-time variation points
◦ 16, 000 Makefiles
◦ 30, 000 header and C files
14/32
Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
◦ 80, 000 compile-time variation points
◦ 16, 000 Makefiles
◦ 30, 000 header and C files
14/32
Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
◦ 80, 000 compile-time variation points
◦ 16, 000 Makefiles
◦ 30, 000 header and C files
14/32
Linux as a subject of study
• Mature: over 20 years of development
• Complex (in v3.3), with over
◦ 12, 000 features
◦ 80, 000 compile-time variation points
◦ 16, 000 Makefiles
◦ 30, 000 header and C files
14/32
Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
◦ Variability model: Kconfig
◦ Mapping: Makefile
◦ Implementation: annotated C code (CPP directives: #ifdefs)
14/32
Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
◦ Variability model: Kconfig
◦ Mapping: Makefile
◦ Implementation: annotated C code (CPP directives: #ifdefs)
14/32
Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
◦ Variability model: Kconfig
◦ Mapping: Makefile
◦ Implementation: annotated C code (CPP directives: #ifdefs)
14/32
Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
◦ Variability model: Kconfig
◦ Mapping: Makefile
◦ Implementation: annotated C code (CPP directives: #ifdefs)
14/32
Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
◦ Variability model: Kconfig
◦ Mapping: Makefile
◦ Implementation: annotated C code (CPP directives: #ifdefs)
14/32
Linux as a subject of study
• Changes are kept in a publicly available SCM Repository (git)
• Continuous development
• Variability spreads different artifacts (spaces):
◦ Variability model: Kconfig
◦ Mapping: Makefile
◦ Implementation: annotated C code (CPP directives: #ifdefs)
14/32
Catalog of evolution patterns
15/32
Methodology for extracting patterns
2.6.2
6
2.6.2
7
3.1 3.2
. . .
added feature names
removed feature names
time
feature name fprimary commit
commit window (cw)
1. Sample Collection
Added feature names: 206 (5%)
Sample of removed feature names: 101 (10%)
2. Commit retrieval
(adds/removes f fromthe variability model)
complements the primary commit(changes of f are in other spaces)
◦ Modular features in AVOMF cause little scattering outside theirmodule
• AVONMF:
◦ ifdefs of non-modular features are coarse-grained, appearing mostly inthe global (e.g., a conditional data structure) or function level (e.g.,conditional statements)
24/32
Take home lesson #1(practical)
Disciplined use of annotation-based techniques such as#ifdefs do not hinder evolution (hypothesis)
25/32
Catalog of evolution patterns(removals sample)
26/32
Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Remove VisibleOptional Modular
Feature (RVOMF)
27/32
Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Remove VisibleOptional
Non-Modular Feature
(RVONMF)
27/32
Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Inverse removals of
patterns in the additions sample
27/32
Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Merges: feature name is removed from the variability model, but feature continues to be supported elsewhere
Merge Visible Optional Feature
into Sibling
(MVOFS)
Merge of RT3090
into RT2860
27/32
Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Rename
27/32
Pattern catalog (removals sample)
(Sample size = 101, Population size = 1,002)
Removals sample
Not patterns
27/32
Findings (removals sample)
• Merges:
◦ Evolution requires a holistic view
◦ Merges can only be identified by retrieving coevolving artifacts