1 / 35

Variability Evolution in the large

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.

swann
Download Presentation

Variability Evolution in the large

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Variability Evolution in the large A 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 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

  3. 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

  4. 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!

  5. 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

  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.” LianpingChen Forrest Shull Muhammad Ali Babar Managing Variability in Software Product Lines IEEE Software: Voice of Evidence, 2010

  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 Goal 1 axTLS BusyBox CoreBoot Coevolution of variability models and related artifacts Starting point Goal 2 FreeBSD Coping with complexity

  11. 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)

  12. 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

  13. 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

  14. Linux has a SteadY growth

  15. 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)

  16. Catalog of patterns 206 feature additions in the VM 101 feature removals in the VM 1 pattern(rename) 7 patterns 5 patterns = (78%) = (68%)

  17. 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

  18. 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!

  19. In contrast… • RT3090 is no longer supported • Functionality has been lost … … Ralink Drivers Ralink Drivers … … … … RT3090 RT2860 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 RT3090 is seen as specialization

  21. 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

  22. Towards goal 2 • Understand how complex variability-aware systems cope with evolution in the large Let’s us go back to Linux...

  23. Towards goal 2 • Feature additions: 6 patterns = 78% of the sample Mostly device drivers Low scattering

  24. Modularity

  25. Variation points (scattering)

  26. device drivers vs scattering location • Slicing the kernel (thanks to Greg Kroah-Hartman) : fs arch driver firmware net core misc

  27. device drivers vs scattering location

  28. 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

  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 steps • Verify our hypothesis and answer our questions in two other operating systems(in addition to Linux) FreeBSD

  31. Next steps (Cont.) Unified set ofsubsystems (all 3 Oss) Files Features

  32. 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.

  33. Supporting material http://lpassos.bitbucket.org/coevolution-patterns/

  34. 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

  35. Questions?

More Related