350 likes | 420 Views
Variability Evolution in the large. A View Point from the Systems Software Domain (Current Results and Next Steps). Leonardo Passos (lpassos@gsd.uwaterloo.ca). In real-world settings. In real-world settings, variability is complex. Automotive domain.
E N D
Variability Evolution in the large A View Point from the Systems Software Domain(Current Results and Next Steps) Leonardo Passos(lpassos@gsd.uwaterloo.ca)
In real-world settings • In real-world settings, variability is complex Automotive domain Introducing PLA at Bosch Gasoline Systems: Experiences and Practices Steger et at, SPLC’04 > 5,000 features Extracted from http://tinyurl.com/pnor6oj
In real-world settings • In real-world settings, variability is complex Automotive domain A Survey of Variability Modeling in Industrial Practice, Berger et al., VaMoS’13 > 10,000 features Extracted from http://tinyurl.com/pnor6oj
Variability is pervasive • Large number of features = large number of variation points Requirements Variability Model (VM) Design models Source code (Variation point) Coevolution is inevitable!
Diagnosis Current research Practice!? Focus mostly on evolution @ VMs only How variability evolvesacross different artifacts? Techniques for variability evolution are tested on random VMs or fictitious scenarios Which evolution scenarios occur in practice? Evolution of VMs and related artifacts rely on fictitious/small subjects How large systems cope with the complexity in the face ofvariability evolution? VM: Variability Model
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.” LianpingChen Forrest Shull Muhammad Ali Babar Managing Variability in Software Product Lines IEEE Software: Voice of Evidence, 2010
Our proposal Study how large and complex variability-aware software systems evolve
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?
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?
Roadmap Goal 1 axTLS BusyBox CoreBoot Coevolution of variability models and related artifacts Starting point Goal 2 FreeBSD Coping with complexity
RoadMap (Cont.) • All subjects belong to the systems software domain • Organization: Variability Model (Kconfig, CDL) Build Files(Makefiles) Variability is pervasive to all these spaces Code (C/C++ source files + ifdefs)
How these three spaces work … Variability Model (Kconfig, CDL) Ralink Drivers … … RT3090 RT2860 Build Files(Makefiles) If RT2860 is selected compile rt2860.c If RT3090 is selected compile rt3090.c Code (C/C++ source files + ifdefs) rt2860.c rt3090.c
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
Scoping LINUX Specifically, we consider coevolution triggered byadding/removingfeatures in the VM Build files(Makefiles) Variability model (Kconfig) Changes triggered by changesin the VM. Code (C source files + ifdefs)
Catalog of patterns 206 feature additions in the VM 101 feature removals in the VM 1 pattern(rename) 7 patterns 5 patterns = (78%) = (68%)
Pattern example (Feature removals) … Coevolution Pattern: MergeOptional VisibleFeature Into Sibling (MOVFS) Ralink Drivers … … RT3090 RT2860 If RT2860 is selected compile rt2860.c If RT3090 is selected compile rt3090.c Merge capabilities of rt3090.c into rt2860.c rt2860.c rt3090.c
Detailing the coevolution pattern • Concrete 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!
In contrast… • RT3090 is no longer supported • Functionality has been lost … … Ralink Drivers Ralink Drivers … … … … RT3090 RT2860 RT2860
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 RT3090 is seen as specialization
Next steps: Beyond linux • Verify to which degree the collected patterns can explain the evolution other systems • Collect other emerging patterns specific to these projects axTLS BusyBox CoreBoot
Towards goal 2 • Understand how complex variability-aware systems cope with evolution in the large Let’s us go back to Linux...
Towards goal 2 • Feature additions: 6 patterns = 78% of the sample Mostly device drivers Low scattering
device drivers vs scattering location • Slicing the kernel (thanks to Greg Kroah-Hartman) : fs arch driver firmware net core misc
Hypotheses • H1) 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 the kernel to cope with its increasing variability
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?
Next steps • Verify our hypothesis and answer our questions in two other operating systems(in addition to Linux) FreeBSD
Next steps (Cont.) Unified set ofsubsystems (all 3 Oss) Files Features
Main publications • Passos, 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.
Supporting material http://lpassos.bitbucket.org/coevolution-patterns/
Acknowledgments • Jesus Padila for his join-work in FreeBSD • JianmeiGuo and Leopoldo Teixeira for helping in the identification of patterns in Linux • Professors Sven Apeland Krzysztof Czarneck for their constant remarks (and patience…) • Professors AndrzejWąsowski and Paulo Borba on early feedback on the patterns work and review of our early drafts