In this paper, we develop a vision of software evolution based on a feature-oriented perspective. From the fact that features provide a common ground to all stakeholders, we derive a hypothesis that changes can be eectively managed in a feature-oriented manner. Assuming that the hypothesis holds, we argue that feature-oriented software evolution relying on automatic traceability, analyses, and recommendations reduces existing challenges in understanding and managing evolution. We illustrate these ideas using an automotive example and raise research questions for the community.

1. Feature-Oriented Software Evolution
(Vision paper)
Leonardo Passos1 Krzysztof Czarnecki1 Sven Apel2
Andrzej Wąsowski3 Christian Käster4 Jianmei Guo1
Claus Hunsen2
1University of Waterloo 2University of Passau 3IT University 4CMU
The Seventh International Workshop on Variability Modelling of Software-intensive Systems
1/37

2. Software evolves. . .
2/37

3. Example
Automotive embedded software:
3/37

4. Example
Automotive embedded software:
• Changing regulations
3/37

5. Example
Automotive embedded software:
• Changing regulations
◦ ABS is now mandatory in the EU
3/37

6. Example
Automotive embedded software:
• Changing regulations
◦ ABS is now mandatory in the EU
• Market differentiating enhancements
3/37

7. Example
Automotive embedded software:
• Changing regulations
◦ ABS is now mandatory in the EU
• Market differentiating enhancements
◦ Electronic stability control (SC) improves ABS by preventing skidding
3/37

8. Example
Automotive embedded software:
• Changing regulations
◦ ABS is now mandatory in the EU
• Market differentiating enhancements
◦ Electronic stability control (SC) improves ABS by preventing skidding
• New technology availability
3/37

9. Example
Automotive embedded software:
• Changing regulations
◦ ABS is now mandatory in the EU
• Market differentiating enhancements
◦ Electronic stability control (SC) improves ABS by preventing skidding
• New technology availability
◦ Laser-based distance sensors are more precise than radio-based ones
3/37

10. Understanding the evolution in
place is not easy. . .
4/37

11. Scenario
ABS + SC
5/37

12. Scenario
• Integration can scatter different artifacts
5/37

13. Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
5/37

14. Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
System
level
Code
level
M
anagem
entlevel
5/37

15. Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
System
level
Code
level
M
anagem
entlevel
⇐ Developers
5/37

16. Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
System
level
Code
level
M
anagem
entlevel
⇐ System engineers
5/37

17. Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
System
level
Code
level
M
anagem
entlevel
⇐ Project managers
5/37

18. In practical settings. . .
6/37

19. In practical settings. . .
Complex and large software systems have:
7/37

20. In practical settings. . .
Complex and large software systems have:
• Diverse set of stakeholders
7/37

21. In practical settings. . .
Complex and large software systems have:
• Diverse set of stakeholders
• Diverse set of artifacts
7/37

22. In practical settings. . .
Complex and large software systems have:
• Diverse set of stakeholders
• Diverse set of artifacts
• Different stakeholders have particular “views” over the software
7/37

23. In practical settings. . .
Complex and large software systems have:
• Diverse set of stakeholders
• Diverse set of artifacts
• Different stakeholders have particular “views” over the software
Stakeholders need a common meeting point
7/37

24. Otherwise. . .
(no common meeting point)
8/37

25. Otherwise. . .
(no common meeting point)
Ineffective communication
8/37

26. Otherwise. . .
(no common meeting point)
Ineffective communication Software flaws
8/37

27. Otherwise. . .
(no common meeting point)
Ineffective communication Software flaws
Architecture decay
8/37

28. Otherwise. . .
(no common meeting point)
Ineffective communication Software flaws
Architecture decay Higher maintenance costs
8/37

29. Hypothesis
9/37

30. Hypothesis
Managing evolution at the level of features can address
the challenges describe above
10/37

31. Hypothesis
Arguments favouring the hypothesis:
10/37

32. Hypothesis
Arguments favouring the hypothesis:
• Feature = cohesive requirements bundle
10/37

33. Hypothesis
Arguments favouring the hypothesis:
• Feature = cohesive requirements bundle
• Requirements are a common point among all stakeholders
10/37

34. Hypothesis
Arguments favouring the hypothesis:
• Feature = cohesive requirements bundle
• Requirements are a common point among all stakeholders
• Features are more coarse-grained than individual requirements
10/37

35. Hypothesis
Arguments favouring the hypothesis:
• Feature = cohesive requirements bundle
• Requirements are a common point among all stakeholders
• Features are more coarse-grained than individual requirements
◦ Facilitates understanding
10/37

36. Hypothesis
Arguments favouring the hypothesis:
• Feature = cohesive requirements bundle
• Requirements are a common point among all stakeholders
• Features are more coarse-grained than individual requirements
◦ Facilitates understanding
• Evolution can be put in simple terms
10/37

37. Hypothesis
Arguments favouring the hypothesis:
• Feature = cohesive requirements bundle
• Requirements are a common point among all stakeholders
• Features are more coarse-grained than individual requirements
◦ Facilitates understanding
• Evolution can be put in simple terms
◦ Add new feature, retire old ones, etc.
10/37

38. Our vision
(Assuming the validity of our hypothesis)
11/37

39. Feature-oriented evolution based on:
Tracing
12/37

40. Feature-oriented evolution based on:
Tracing
Analyses
12/37

41. Feature-oriented evolution based on:
Tracing
Analyses
Recommendations
12/37

42. Purpose of our work
Research agenda based
on our vision for feature-oriented
software evolution
This presentation covers part of that agenda
(see paper for more details)
13/37

43. Motivating example
14/37

44. Motivating example
Car
YRS
YRS-M2
SC
ABSSC
SCConv
Featuremodel
BRA
ABSConv
YRS SC
YRS-M1
Merge + clone yaw rate prediction
15/37

45. Motivating example
Car
YRS
YRS-M2
SC
ABSSC
SCConv
Featuremodel
BRA
ABSConv
YRS SC
YRS-M1
Merge + clone yaw rate prediction
15/37

46. Motivating example
Car
YRS
YRS-M2
SC
ABSSC
SCConv
Featuremodel
BRA
ABSConv
YRS SC
Merge + clone yaw rate prediction
15/37

47. Motivating example
Car
YRS
YRS-M2
SC
ABSSC
SCConv
Featuremodel
BRA
ABSConv
YRS SC
Merge YRS-M2 into YRS + rename YRS to YS
15/37

48. Motivating example
Car
YSSC
ABSSC
SCConv
Featuremodel
BRA
ABSConv
YS SC
Merge + clone yaw rate prediction
15/37

49. Tracing
16/37

50. Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
DYRS()1/2
17/37

51. Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
DYRS()1/2Bug found in YS
17/37

52. Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
?
DYRS()Does the bug exist in YRS-M2 (t2)?1/2
17/37

53. Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
? ?
Does the bug exist in YRS-M1/2 (t1)?
17/37

54. Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
? ? ?
() Does the bug exist in both t1 and t2?1/2
17/37

55. Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
? ? ?
DYRS() Answering requires tracing the evolution of single features1/2
17/37

56. Tracing
• Traceability has to be recovered from a multi-space setting:
17/37

57. Tracing
• Traceability has to be recovered from a multi-space setting:
◦ Recover traceability of different artifacts (e.g.: FM, Build files, C
code)
17/37

58. Tracing
• Traceability has to be recovered from a multi-space setting:
◦ Recover traceability of different artifacts (e.g.: FM, Build files, C
code)
◦ Integrate the evolution history of those artifacts over time
17/37

59. Tracing
• Traceability has to be recovered from a multi-space setting:
◦ Recover traceability of different artifacts (e.g.: FM, Build files, C
code)
◦ Integrate the evolution history of those artifacts over time
◦ Draw an evolution history (timeline)
17/37

60. Tracing
• Traceability has to be recovered from a multi-space setting:
◦ Recover traceability of different artifacts (e.g.: FM, Build files, C
code)
◦ Integrate the evolution history of those artifacts over time
◦ Draw an evolution history (timeline)
YRS-M1
YRS-M2
(t2)(t1) (t3)
YS
YRS
M M
M
17/37

61. Tracing
(Research questions)
18/37

62. Tracing (Research questions)
• Tracing certain artifacts can be daunting
19/37

63. Tracing (Research questions)
• Tracing certain artifacts can be daunting
◦ Individual build rules in build files (e.g., make is Turing-complete)
19/37

64. Tracing (Research questions)
• Tracing certain artifacts can be daunting
◦ Individual build rules in build files (e.g., make is Turing-complete)
◦ Fine-grained variability analysis in code is costly
19/37

65. Tracing (Research questions)
• Tracing certain artifacts can be daunting
◦ Individual build rules in build files (e.g., make is Turing-complete)
◦ Fine-grained variability analysis in code is costly
RQ: How to recover traceability links in build files and source
code in variability-aware systems?
19/37

66. Tracing (Research questions)
• Tracing certain artifacts can be daunting
◦ Individual build rules in build files (e.g., make is Turing-complete)
◦ Fine-grained variability analysis in code is costly
RQ: How to recover traceability links in build files and source
code in variability-aware systems?
RQ: Once recovered, how to update them to reflect the
temporal evolution in place?
19/37

67. Tracing (Research questions)
• Different artifacts = different sources to draw the evolution in place
19/37

68. Tracing (Research questions)
• Different artifacts = different sources to draw the evolution in place
◦ Mailing lists
19/37

69. Tracing (Research questions)
• Different artifacts = different sources to draw the evolution in place
◦ Mailing lists
◦ Commit patches and log messages
19/37

70. Tracing (Research questions)
• Different artifacts = different sources to draw the evolution in place
◦ Mailing lists
◦ Commit patches and log messages
◦ Bug reports in bug tracking systems
19/37

71. Tracing (Research questions)
• Different artifacts = different sources to draw the evolution in place
◦ Mailing lists
◦ Commit patches and log messages
◦ Bug reports in bug tracking systems
RQ: Which sources are trustworthy?
19/37

72. Analyses
20/37

73. Analyses
(Back to the motivating example)
21/37

74. Analyses
After the evolution of the SPL, stakeholders noticed that:
22/37

75. Analyses
After the evolution of the SPL, stakeholders noticed that:
• Maintenance is taking longer
22/37

76. Analyses
After the evolution of the SPL, stakeholders noticed that:
• Maintenance is taking longer
• Productivity has decreased
22/37

77. Analyses
After the evolution of the SPL, stakeholders noticed that:
• Maintenance is taking longer
• Productivity has decreased
• Bugs are starting to rise
22/37

78. Analyses
After the evolution of the SPL, stakeholders noticed that:
• Maintenance is taking longer
• Productivity has decreased
• Bugs are starting to rise
Well-known phenomena of software aging
22/37

79. Analyses
We envision three analyses to prevent aging:
22/37

80. Analyses
We envision three analyses to prevent aging:
• Consistency checking analysis
22/37

81. Analyses
We envision three analyses to prevent aging:
• Consistency checking analysis
• Change impact analysis
22/37

82. Analyses
We envision three analyses to prevent aging:
• Consistency checking analysis
• Change impact analysis
• Architectural analysis
22/37

83. Analyses
(Consistency checking)
23/37

84. Analyses (Consistency checking)
Goal: prevent inconsistencies in different artifacts
DNpit
24/37

85. Analyses (Consistency checking)
Goal: prevent inconsistencies in different artifacts
...
#ifdef Conv
// switch
// to Conv
// if ABS
// fails
#endif
...
...
sensor_data_t data ;
#ifdef SC
data = get_value(data) ;
#endif
if (data->check_oversteering())
react_oversteering() ;
...
...
#ifdef SC && YRS_M1
double predicted_value
...
#endif
...
abs.c (1) abs.c (2) abs.c (3)
...
#ifdef SC && YRS_M1
predictor_t p ;
#else
int p = 0;
#endif
...
predicted_value=p->get() ;
abs.c (4)
DNpit
24/37

86. Analyses (Consistency checking)
Goal: prevent inconsistencies in different artifacts
...
#ifdef Conv
// switch
// to Conv
// if ABS
// fails
#endif
...
...
sensor_data_t data ;
#ifdef SC
data = get_value(data) ;
#endif
if (data->check_oversteering())
react_oversteering() ;
...
...
#ifdef SC && YRS_M1
double predicted_value
...
#endif
...
abs.c (1) abs.c (2) abs.c (3)
...
#ifdef SC && YRS_M1
predictor_t p ;
#else
int p = 0;
#endif
...
predicted_value=p->get() ;
abs.c (4)
Dead code DNpit
24/37

87. Analyses (Consistency checking)
Goal: prevent inconsistencies in different artifacts
...
#ifdef Conv
// switch
// to Conv
// if ABS
// fails
#endif
...
...
sensor_data_t data ;
#ifdef SC
data = get_value(data) ;
#endif
if (data->check_oversteering())
react_oversteering() ;
...
...
#ifdef SC && YRS_M1
double predicted_value
...
#endif
...
abs.c (1) abs.c (2) abs.c (3)
...
#ifdef SC && YRS_M1
predictor_t p ;
#else
int p = 0;
#endif
...
predicted_value=p->get() ;
abs.c (4)
Null pointer exception DNpit
24/37

88. Analyses (Consistency checking)
Goal: prevent inconsistencies in different artifacts
...
#ifdef Conv
// switch
// to Conv
// if ABS
// fails
#endif
...
...
sensor_data_t data ;
#ifdef SC
data = get_value(data) ;
#endif
if (data->check_oversteering())
react_oversteering() ;
...
...
#ifdef SC && YRS_M1
double predicted_value
...
#endif
...
abs.c (1) abs.c (2) abs.c (3)
...
#ifdef SC && YRS_M1
predictor_t p ;
#else
int p = 0;
#endif
...
predicted_value=p->get() ;
abs.c (4)
Syntax errorDNpit
24/37

89. Analyses (Consistency checking)
Goal: prevent inconsistencies in different artifacts
...
#ifdef Conv
// switch
// to Conv
// if ABS
// fails
#endif
...
...
sensor_data_t data ;
#ifdef SC
data = get_value(data) ;
#endif
if (data->check_oversteering())
react_oversteering() ;
...
...
#ifdef SC && YRS_M1
double predicted_value
...
#endif
...
abs.c (1) abs.c (2) abs.c (3)
...
#ifdef SC && YRS_M1
predictor_t p ;
#else
int p = 0;
#endif
...
predicted_value=p->get() ;
abs.c (4)
DNpit Type error
24/37

90. Analyses (Consistency checking)
Goal: prevent inconsistencies in different artifacts
...
#ifdef Conv
// switch
// to Conv
// if ABS
// fails
#endif
...
...
sensor_data_t data ;
#ifdef SC
data = get_value(data) ;
#endif
if (data->check_oversteering())
react_oversteering() ;
...
...
#ifdef SC && YRS_M1
double predicted_value
...
#endif
...
abs.c (1) abs.c (2) abs.c (3)
...
#ifdef SC && YRS_M1
predictor_t p ;
#else
int p = 0;
#endif
...
predicted_value=p->get() ;
abs.c (4)
Other types of analysis exist: e.g., model-checkingDNpit
24/37

91. Consistency checking
(Research questions)
25/37

92. Consistency checking (Research questions)
• Variability aware-analysis is costly.
26/37

93. Consistency checking (Research questions)
• Variability aware-analysis is costly.
RQ: Do existing approaches for variability-aware type-
checking, flow-analysis and model-checking scale to large
systems?
26/37

94. Consistency checking (Research questions)
• Variability aware-analysis is costly.
RQ: Do existing approaches for variability-aware type-
checking, flow-analysis and model-checking scale to large
systems?
• Existing flow-analysis is intra-procedural.
26/37

95. Consistency checking (Research questions)
• Variability aware-analysis is costly.
RQ: Do existing approaches for variability-aware type-
checking, flow-analysis and model-checking scale to large
systems?
• Existing flow-analysis is intra-procedural.
RQ: How to adapt existing inter-procedural analyses to
handle variability?
26/37

96. Analyses
(Impact analysis)
27/37

97. Impact analysis
Goal: assess impact of changes
28/37

98. Impact analysis
Goal: assess impact of changes
Scenario:
• To identify bugs, stakeholders in our SPL have created formal
specifications of the system’s features
• Support for cruise control (CC)
28/37

99. Impact analysis
Goal: assess impact of changes
Scenario:
• To identify bugs, stakeholders in our SPL have created formal
specifications of the system’s features
• Support for cruise control (CC)
Car
YRS
YRS-M2
SC
ABSSC
SCConv
Featuremodel
BRA
ABSConv
YRS SC
YRS-M1
CC
28/37

100. Impact analysis
Stability-control behaviour property: No subsystem increases
acceleration when SC is engaged
29/37

101. Impact analysis
Stability-control behaviour property: No subsystem increases
acceleration when SC is engaged
1. CC cruise speed
is set
2. Engage CC
3. Drivers looses
control
4. Engage SC
5. CC accelerates to
achieve cruise speed
29/37

102. Impact analysis
Stability-control behaviour property: No subsystem increases
acceleration when SC is engaged
1. CC cruise speed
is set
2. Engage CC
3. Drivers looses
control
4. Engage SC
5. CC accelerates to
achieve cruise speed
Adding CC violates the given property
29/37

103. Impact analysis
Stability-control behaviour property: No subsystem increases
acceleration when SC is engaged
1. CC cruise speed
is set
2. Engage CC
3. Drivers looses
control
4. Engage SC
5. CC accelerates to
achieve cruise speed
Adding CC violates the given property
(Impact analysis aims to detect that promptly)
29/37

104. Impact analysis (Research questions)
• Currently, consistency between implementation assets (code) and
the system’s specified property is mostly intractable.
30/37

105. Impact analysis (Research questions)
• Currently, consistency between implementation assets (code) and
the system’s specified property is mostly intractable.
RQ: How to verify that the system implementation does not
break its specified properties?
30/37

106. Analyses
(Architectural analysis)
31/37

107. Architectural analysis
• Feature model = view of the system architecture
• From the recovered traces, one can track the “health of the system”
• Different indicators can be collected to assess the system evolution:
◦ code metrics
◦ process metrics
◦ feature-based
metrics
◦ feature-model based metrics
◦ product-line based metrics
32/37

108. Architectural analysis
• Evidence relating scattering and defects is rather preliminary.
33/37

109. Architectural analysis
• Evidence relating scattering and defects is rather preliminary.
RQ: Can we provide more evidence for the relationship
between scattering and defects?
33/37

110. Recommendations
34/37

111. Recommendations + research question
Suggestions for:
35/37

112. Recommendations + research question
Suggestions for:
• Consistency analysis
35/37

113. Recommendations + research question
Suggestions for:
• Consistency analysis
• Impact analysis
35/37

114. Recommendations + research question
Suggestions for:
• Consistency analysis
• Impact analysis
• Architectural analysis
35/37

115. Recommendations + research question
Consistency:
• Fix recommendations for different artifacts types
35/37

116. Recommendations + research question
Consistency:
• Fix recommendations for different artifacts types
RQ: How to devise a fixing recommender integrating
different artifacts, with different abstraction levels?
35/37

117. Recommendations + research question
Consistency:
• Fix recommendations for different artifacts types
RQ: How to devise a fixing recommender integrating
different artifacts, with different abstraction levels?
Impact analysis:
• Point which features are more likely to have defects after a change
35/37

118. Recommendations + research question
Consistency:
• Fix recommendations for different artifacts types
RQ: How to devise a fixing recommender integrating
different artifacts, with different abstraction levels?
Impact analysis:
• Point which features are more likely to have defects after a change
RQ: Which feature-based metrics are good defect predictors?
35/37

119. Recommendations + research question
Architectural analysis:
35/37

120. Recommendations + research question
Architectural analysis:
• Propose merges (features are too similar)
35/37

121. Recommendations + research question
Architectural analysis:
• Propose merges (features are too similar)
• Suggest feature retirement
35/37

122. Recommendations + research question
Architectural analysis:
• Propose merges (features are too similar)
• Suggest feature retirement
• Suggest which features to modularize
35/37

123. Recommendations + research question
Architectural analysis:
• Propose merges (features are too similar)
• Suggest feature retirement
• Suggest which features to modularize
RQ: Which scenarios should be supported (are required in
practice)?
35/37

124. Conclusion
• We hypothesized that feature-oriented evolution can mitigate
existing challenges in evolving large-complex systems
• From that hypothesis, we presented our vision based on tracing,
analyses and recommendations
• We are have started working on the realization of that vision
36/37

125. Thanks for listening!
37/37