SPLC Presentation

305 views

Published on

The extension of our FOSD paper

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
305
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

SPLC Presentation

  1. 1. Coevolution of Variability Models and Related Artifacts A 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
  2. 2. A concrete change from the Linux kernel 2/32
  3. 3. Ralink Drivers RT2860 ... ... ...RT3090 2/32
  4. 4. Ralink Drivers RT2860 ... ... ...RT3090 2/32
  5. 5. Ralink Drivers RT2860 ... ... ... 2/32
  6. 6. Ralink Drivers RT2860 ... ... ... Does it mean that RT3090 is no longer supported? 2/32
  7. 7. Existing evolution studies tend to focus on the variability model alone 3/32
  8. 8. That doesn’t tell the whole story. . . 4/32
  9. 9. Ralink Drivers RT2860... ...RT3090 5/32
  10. 10. Ralink Drivers RT2860... ...RT3090 Variability model (Kconfig) 5/32
  11. 11. Ralink Drivers RT2860... ...RT3090 Mapping (Makefiles) 5/32
  12. 12. Ralink Drivers RT2860... ...RT3090 Implementation (.h and .c files) 5/32
  13. 13. Different artifacts, in different spaces, are connected. . . 5/32
  14. 14. Ralink Drivers RT2860... ...RT3090 5/32
  15. 15. Ralink Drivers RT2860... ...RT3090 5/32
  16. 16. Ralink Drivers RT2860... ...RT3090 5/32
  17. 17. Ralink Drivers RT2860... ...RT3090 Implementation file (.c or .h) 5/32
  18. 18. Ralink Drivers RT2860... ...RT3090 macro directive (e.g.:, #ifdef RT2860) 5/32
  19. 19. With the three spaces in mind, the real picture of . . . 6/32
  20. 20. Ralink Drivers RT2860 ... ... ...RT3090 is 6/32
  21. 21. Ralink Drivers RT2860... ...RT3090 6/32
  22. 22. Ralink Drivers RT2860... ...RT3090 copy copy copy 6/32
  23. 23. Ralink Drivers RT2860... ...RT3090 copy copy copy Therefore, RT3090 is merged into RT2860 6/32
  24. 24. But, what can be said about the few studies that take coevolution into account? 7/32
  25. 25. Studies that consider coevolution • Borba et al., GPCE 2011 8/32
  26. 26. Studies that consider coevolution • Borba et al., GPCE 2011 ◦ Small case study: Mobile Media and TaRGeT ≈ 40 features 8/32
  27. 27. 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 8/32
  28. 28. 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 product compatibility) 8/32
  29. 29. 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 product compatibility) • Seidl et al., SPLC 2012 8/32
  30. 30. 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 product compatibility) • Seidl et al., SPLC 2012 ◦ Validated over a small and fictitious example 8/32
  31. 31. We need practical case studies of variability coevolution in large complex variability rich software 9/32
  32. 32. Better understanding tools mirroring coevolution as it happens in practice 10/32
  33. 33. Our work 11/32
  34. 34. A catalog of 13 coevolution patterns from a large and complex system (Linux kernel) Provides a concrete set of coevolution operations performed in practice12/32
  35. 35. A set of findings from the analyses of the catalog and its instances Presented as take home lessons 13/32
  36. 36. Linux as a subject of study • Mature: over 20 years of development 14/32
  37. 37. Linux as a subject of study • Mature: over 20 years of development • Complex (in v3.3), with over 14/32
  38. 38. Linux as a subject of study • Mature: over 20 years of development • Complex (in v3.3), with over ◦ 12, 000 features 14/32
  39. 39. 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 14/32
  40. 40. 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 14/32
  41. 41. 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
  42. 42. Linux as a subject of study • Changes are kept in a publicly available SCM Repository (git) 14/32
  43. 43. Linux as a subject of study • Changes are kept in a publicly available SCM Repository (git) • Continuous development 14/32
  44. 44. Linux as a subject of study • Changes are kept in a publicly available SCM Repository (git) • Continuous development • Variability spreads different artifacts (spaces): 14/32
  45. 45. 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 14/32
  46. 46. 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 14/32
  47. 47. 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
  48. 48. Catalog of evolution patterns 15/32
  49. 49. Methodology for extracting patterns 2.6.26 2.6.27 3.1 3.2 . . . added feature names removed feature names time feature name f primary 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 from the variability model) complements the primary commit (changes of f are in other spaces) 3. Analysis & Clustering 4. Pattern extraction almost 4 years of development (Additions sample) (Removals sample) 16/32
  50. 50. Catalog of evolution patterns (additions sample) 17/32
  51. 51. Pattern catalog (additions sample) Rename (Sample size = 206, Population size = 4,112) Additions sample 18/32
  52. 52. Pattern catalog (additions sample) Creation of feature from existing code (Sample size = 206, Population size = 4,112) Additions sample 18/32
  53. 53. Pattern catalog (additions sample) Creation of feature from new elements (Sample size = 206, Population size = 4,112) Additions sample 18/32
  54. 54. Pattern catalog (additions sample) Not patterns (Sample size = 206, Population size = 4,112) Additions sample 18/32
  55. 55. Pattern catalog (additions sample) Two most frequent patterns: Add Visible Optional Modular Feature (AVOMF) Add Visible Optional Non-Modular Feature (AVONMF) 18/32
  56. 56. Add Visible Optional Modular Feature (Example) 19/32
  57. 57. Add Visible Optional Modular Feature Example: CAPTURE_DAVINCI_DM646_EVM CAPTURE_DAVINCI_DM646_EVM VIDEO_DEV ... ... ... CTC' = CTC + (CAPTURE_DAVINCI_DM646_EVM requires MACH_EVM) M' = M + new compilation rule: if CAPTURE_DAVINCI_DM646_EVM is set compile vpfi_capture.c I'= I + vpfi_capture.c CTC: set of cross tree constraints M: Mapping I: Implementation (Before state) (After state) [visible] VIDEO_DEV ... ... ... 20/32
  58. 58. Add Visible Optional Non-Modular Feature (Example) 21/32
  59. 59. Add Visible Optional Non-Modular Feature Example: SQUASHFS_4K_DEVBLK_SIZE SQUASHFS_4K_DEVBLK_SIZE SQUASHFS ... ... ... CTC' = CTC + constraints of SQUASHFS_4K_DEVBLK_SIZE I'= I + < #ifdef SQUASHFS_4K_DEVBLK_SIZE #define SQUASHFS_DEVBLK_SIZE 4096 #else #define SQUASHFS_DEVBLK_SIZE 1024 #endif > CTC: set of cross tree constraints M: Mapping I: Implementation (Before state) (After state) [visible] SQUASHFS ... ... ... M: Mapping 22/32
  60. 60. Findings (additions sample) 23/32
  61. 61. Findings (additions sample) • AVOMF: ◦ Most features in Linux are modular ◦ Modular features in AVOMF cause little scattering outside their module • AVONMF: ◦ ifdefs of non-modular features are coarse-grained, appearing mostly in the global (e.g., a conditional data structure) or function level (e.g., conditional statements) 24/32
  62. 62. Take home lesson #1 (practical) Disciplined use of annotation-based techniques such as #ifdefs do not hinder evolution (hypothesis) 25/32
  63. 63. Catalog of evolution patterns (removals sample) 26/32
  64. 64. Pattern catalog (removals sample) (Sample size = 101, Population size = 1,002) Removals sample Remove Visible Optional Modular Feature (RVOMF) 27/32
  65. 65. Pattern catalog (removals sample) (Sample size = 101, Population size = 1,002) Removals sample Remove Visible Optional Non-Modular Feature (RVONMF) 27/32
  66. 66. Pattern catalog (removals sample) (Sample size = 101, Population size = 1,002) Removals sample Inverse removals of patterns in the additions sample 27/32
  67. 67. 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
  68. 68. Pattern catalog (removals sample) (Sample size = 101, Population size = 1,002) Removals sample Rename 27/32
  69. 69. Pattern catalog (removals sample) (Sample size = 101, Population size = 1,002) Removals sample Not patterns 27/32
  70. 70. Findings (removals sample) • Merges: ◦ Evolution requires a holistic view ◦ Merges can only be identified by retrieving coevolving artifacts • Complete feature removal (e.g., RVOMF = AVOMF−1) ◦ Affect the set of supported products; thus not a refinement ◦ Refinement changes are too restrictive in practice, as complete feature removals are often frequent (43% of all removals) 28/32
  71. 71. Take home lesson #2 (methodological) Effective understanding of variability evolution requires looking at the coevolution of different artifacts 29/32
  72. 72. Take home lesson #3 (requirements for tool implementors) The set of patterns provide concrete operations on how artifacts coevolve Catalog provides evidence on which operations are important (e.g., we did not find split operations) 30/32
  73. 73. Conclusion • We sumarized a catalog of 13 patterns that include coevolution of: ◦ Variability model ◦ Mapping ◦ Implementation • Subject of analysis: a large and complex software system – the Linux kernel • Presented three take home lessons (full list of findings in the paper) 31/32
  74. 74. Thanks for listening! 32/32

×