Variability Evolution in the large

1

VARIABILITY EVOLUTION IN THE LARGEA View Point from the Systems Software Domain(Current Results and Next Steps)

Leonardo Passos(lpassos@gsd.uwaterloo.ca)

2

IN REAL-WORLD SETTINGS In real-world settings, variability is complex

Introducing PLA at Bosch Gasoline Systems: Experiences and Practices Steger et at, SPLC’04

> 5,000 features

Extracted from http://tinyurl.com/pnor6oj

Automotive domain

3

IN REAL-WORLD SETTINGS In real-world settings, variability is complex

A Survey of Variability Modeling in Industrial Practice, Berger et al., VaMoS’13

> 10,000 features

Extracted from http://tinyurl.com/pnor6oj

Automotive domain

4

VARIABILITY IS PERVASIVELarge number of features = large number of variation points

Requirements

Source code

Design models

(Variation point)

Coevolution is inevitable!

Variability Model (VM)

5

DIAGNOSISCurrent research Practice!?

Focus mostly on evolution @ VMs only

How variability evolvesacross different artifacts?

Techniques for variabilityevolution are tested on random VMs or fictitious scenarios

Evolution of VMs and related artifacts rely on fictitious/small subjects

Which evolution scenarios occur in practice?

How large systems cope with thecomplexity in the face ofvariability evolution?

VM: Variability Model

6

NOT SURPRISINGLY

“Variability evolves as a result of adding, deleting, or updating variation points and variants. However, we found little support for systematically and sufficiently supporting evolution in variability models and other related artifacts.”

Managing Variability in Software Product LinesIEEE Software: Voice of Evidence, 2010

Lianping ChenMuhammad Ali Babar Forrest Shull

7

OUR PROPOSAL

Study how large and complex variability-aware software systems evolve

8

GOAL (1)Understand the coevolution of variability models and related artifacts

Which evolution scenarios occur in practice?

What causes them to occur?

How are changes made when realizing such scenarios?

What’s the impact on existing solutions for variability evolution?

9

GOAL (2)Understand how complex variability-aware systems cope with evolution in the large

How easy is it for these systems to accommodate new features?

How do they handle the increasing complexity of variability in the face of evolution?

10

ROADMAP

axTLS

FreeBSD

BusyBox CoreBoot

Coevolution of variability models and related artifacts

Coping with complexity

Starting point

Goal 1

Goal 2

ROADMAP (CONT.)All subjects belong to the systems software domain

Organization:

11

Variability Model

(Kconfig, CDL)

Build Files(Makefiles)

Code(C/C++ source files +

ifdefs)

Variabilityis pervasive to

all these spaces

12

HOW THESE THREE SPACES WORK

Ralink Drivers

…

RT2860 RT3090… …

If RT2860 is selected compile rt2860.c

If RT3090 is selected compile rt3090.c

rt2860.c rt3090.c

Variability Model

(Kconfig, CDL)

Build Files(Makefiles)

Code(C/C++ source files

+ ifdefs)

STARTING POINT: LINUX KERNEL AS A CASE STUDY

Large and complex software system

Release 3.9:

> 13,000 features

> 35,000 source files (mostly C code)

> 90,000 variation points distributed over Makefiles + annotated C code (ifdefs)

Linux is likely to reflect the complexity found in real-world settings

LINUX HAS A STEADY GROWTH

SCOPING LINUX

Variability model

(Kconfig)

Build files(Makefiles)

Code(C source files + ifdefs)

Changes triggered

by changesin the VM.

Specifically, we consider

coevolutiontriggered by

adding/removingfeatures in the

VM

CATALOG OF PATTERNS

206 feature additions in the VM 101 feature removals in the VM

5 patterns 7 patterns1 pattern(rename)

= (78%) = (68%)

17

PATTERN EXAMPLE (FEATURE REMOVALS)

Ralink Drivers

…

RT2860 RT3090… …

If RT2860 is selected compile rt2860.c

If RT3090 is selected compile rt3090.c

rt2860.c rt3090.c

Merge capabilities ofrt3090.c into rt2860.c

CoevolutionPattern:

MergeOptionalVisibleFeature

IntoSibling

(MOVFS)

18

DETAILING THE COEVOLUTION PATTERNConcrete evolution scenario

Merge of two features

What causes it to occur Feature similarity

How are changes made: Feature, its build rules, and its C files are removed Capabilities are merged to existing feature’s code

Conclusion: no functionality is lost!

19

IN CONTRAST…

RT3090 is no longer supported

Functionality has been lost

Ralink Drivers

…

RT2860 RT3090… …

Ralink Drivers

…

RT2860… …

20

IMPACT ON EXISTING TECHNIQUES (1)Edit-based reasoning techniques that take the VM evolution alone need to account for changes in other spaces

Example: [Thüm, ICSE’09]

Removal of RT3090is seen as specialization

21

NEXT STEPS: BEYOND LINUXVerify to which degree the collected patterns can explain the evolution other systems

Collect other emerging patterns specific to these projects

axTLS BusyBox CoreBoot

22

TOWARDS GOAL 2Understand how complex variability-aware systems cope with evolution in the large

Let’s us go back to Linux...

TOWARDS GOAL 2Feature additions: 6 patterns = 78% of the sample

23

81%

19%

Feature addition

Addition based on new elements

Addition based on existing elements

80%

20%

Addition of features from new elements

Addition of modular feature

Addition of non-modular feature

Low scattering

Mostly devicedrivers

24

MODULARITY

25

VARIATION POINTS (SCATTERING)

26

DEVICE DRIVERS VS SCATTERING LOCATIONSlicing the kernel (thanks to Greg Kroah-Hartman) :

driver core fs net firmware arch misc

DEVICE DRIVERS VS SCATTERING LOCATION

28

HYPOTHESESH1) Specific features are allowed to cause scattering

H2) Others can only cause scattering in the place where they are defined (e.g., inside driver)

Along with high modularity, controlling the scattering allows thekernel to cope with its increasing variability

29

RESEARCH QUESTIONS Which features cause scattering?

What are their characteristics?

Is scattering local to the feature’s subsystem, or does it go beyond that?

What’s the complexity of the scattering being caused?

How does scattering evolve over time?

How does the modularity design employed by the kernel prevent scattering?

30

NEXT STEPSVerify our hypothesis and answer our questions in two other operating systems (in addition to Linux)

FreeBSD

31

NEXT STEPS (CONT.)

FilesUnified set ofsubsystems(all 3 Oss)

Features

32

MAIN PUBLICATIONSPassos, L., J. Guo, Leopoldo Teixeira, K. Czarnecki, A. Wasowski, and Paulo Borba, "Coevolution of Variability Models and Related Artifacts: A Case Study from the Linux Kernel", 17th International Software Product Line Conference, Tokyo, ACM, 2013.

Passos, L., K. Czarnecki, S. Apel, A. Wasowski, C. Kästner, J. Guo, and C. Hunsen, "Feature-Oriented Software Evolution", 7th International Workshop on Variability Modelling of Software-intensive Systems, Italy, ACM , 2013.

33

SUPPORTING MATERIAL

http://lpassos.bitbucket.org/coevolution-patterns/

34

ACKNOWLEDGMENTS Jesus Padila for his join-work in FreeBSD

Jianmei Guo and Leopoldo Teixeira for helping in the identification of patterns in Linux

Professors Sven Apel and Krzysztof Czarneck for their constant remarks (and patience…)

Professors Andrzej Wąsowski and Paulo Borba on early feedback on the patterns work and review of our early drafts

35Questions?