• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Feature-Oriented Software Evolution
 

Feature-Oriented Software Evolution

on

  • 132 views

In this paper, we develop a vision of software evolution based ...

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 e ectively 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.

Statistics

Views

Total Views
132
Views on SlideShare
132
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Feature-Oriented Software Evolution Feature-Oriented Software Evolution Presentation Transcript

    • Feature-Oriented Software Evolution(Vision paper)Leonardo Passos1 Krzysztof Czarnecki1 Sven Apel2Andrzej Wąsowski3 Christian Käster4 Jianmei Guo1Claus Hunsen21University of Waterloo 2University of Passau 3IT University 4CMUThe Seventh International Workshop on Variability Modelling of Software-intensive Systems1/37
    • Software evolves. . .2/37
    • ExampleAutomotive embedded software:3/37
    • ExampleAutomotive embedded software:• Changing regulations3/37
    • ExampleAutomotive embedded software:• Changing regulations◦ ABS is now mandatory in the EU3/37
    • ExampleAutomotive embedded software:• Changing regulations◦ ABS is now mandatory in the EU• Market differentiating enhancements3/37
    • ExampleAutomotive embedded software:• Changing regulations◦ ABS is now mandatory in the EU• Market differentiating enhancements◦ Electronic stability control (SC) improves ABS by preventing skidding3/37
    • ExampleAutomotive 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 availability3/37
    • ExampleAutomotive 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 ones3/37
    • Understanding the evolution inplace is not easy. . .4/37
    • ScenarioABS + SC5/37
    • Scenario• Integration can scatter different artifacts5/37
    • Scenario• Integration can scatter different artifacts• Different levels of abstractions not mastered by all stakeholders5/37
    • Scenario• Integration can scatter different artifacts• Different levels of abstractions not mastered by all stakeholdersSystemlevelCodelevelManagementlevel5/37
    • Scenario• Integration can scatter different artifacts• Different levels of abstractions not mastered by all stakeholdersSystemlevelCodelevelManagementlevel⇐ Developers5/37
    • Scenario• Integration can scatter different artifacts• Different levels of abstractions not mastered by all stakeholdersSystemlevelCodelevelManagementlevel⇐ System engineers5/37
    • Scenario• Integration can scatter different artifacts• Different levels of abstractions not mastered by all stakeholdersSystemlevelCodelevelManagementlevel⇐ Project managers5/37
    • In practical settings. . .6/37
    • In practical settings. . .Complex and large software systems have:7/37
    • In practical settings. . .Complex and large software systems have:• Diverse set of stakeholders7/37
    • In practical settings. . .Complex and large software systems have:• Diverse set of stakeholders• Diverse set of artifacts7/37
    • In practical settings. . .Complex and large software systems have:• Diverse set of stakeholders• Diverse set of artifacts• Different stakeholders have particular “views” over the software7/37
    • In practical settings. . .Complex and large software systems have:• Diverse set of stakeholders• Diverse set of artifacts• Different stakeholders have particular “views” over the softwareStakeholders need a common meeting point7/37
    • Otherwise. . .(no common meeting point)8/37
    • Otherwise. . .(no common meeting point)Ineffective communication8/37
    • Otherwise. . .(no common meeting point)Ineffective communication Software flaws8/37
    • Otherwise. . .(no common meeting point)Ineffective communication Software flawsArchitecture decay8/37
    • Otherwise. . .(no common meeting point)Ineffective communication Software flawsArchitecture decay Higher maintenance costs8/37
    • Hypothesis9/37
    • HypothesisManaging evolution at the level of features can addressthe challenges describe above10/37
    • HypothesisArguments favouring the hypothesis:10/37
    • HypothesisArguments favouring the hypothesis:• Feature = cohesive requirements bundle10/37
    • HypothesisArguments favouring the hypothesis:• Feature = cohesive requirements bundle• Requirements are a common point among all stakeholders10/37
    • HypothesisArguments favouring the hypothesis:• Feature = cohesive requirements bundle• Requirements are a common point among all stakeholders• Features are more coarse-grained than individual requirements10/37
    • HypothesisArguments favouring the hypothesis:• Feature = cohesive requirements bundle• Requirements are a common point among all stakeholders• Features are more coarse-grained than individual requirements◦ Facilitates understanding10/37
    • HypothesisArguments 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 terms10/37
    • HypothesisArguments 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
    • Our vision(Assuming the validity of our hypothesis)11/37
    • Feature-oriented evolution based on:Tracing12/37
    • Feature-oriented evolution based on:TracingAnalyses12/37
    • Feature-oriented evolution based on:TracingAnalysesRecommendations12/37
    • Purpose of our workResearch agenda basedon our vision for feature-orientedsoftware evolutionThis presentation covers part of that agenda(see paper for more details)13/37
    • Motivating example14/37
    • Motivating exampleCarYRSYRS-M2SCABSSCSCConvFeaturemodelBRAABSConvYRS SCYRS-M1Merge + clone yaw rate prediction15/37
    • Motivating exampleCarYRSYRS-M2SCABSSCSCConvFeaturemodelBRAABSConvYRS SCYRS-M1Merge + clone yaw rate prediction15/37
    • Motivating exampleCarYRSYRS-M2SCABSSCSCConvFeaturemodelBRAABSConvYRS SCMerge + clone yaw rate prediction15/37
    • Motivating exampleCarYRSYRS-M2SCABSSCSCConvFeaturemodelBRAABSConvYRS SCMerge YRS-M2 into YRS + rename YRS to YS15/37
    • Motivating exampleCarYSSCABSSCSCConvFeaturemodelBRAABSConvYS SCMerge + clone yaw rate prediction15/37
    • Tracing16/37
    • TracingYRS-M2YRS-M1 YRS-M2 YS(t1) (t2) (t3)DYRS()1/217/37
    • TracingYRS-M2YRS-M1 YRS-M2 YS(t1) (t2) (t3)DYRS()1/2Bug found in YS17/37
    • TracingYRS-M2YRS-M1 YRS-M2 YS(t1) (t2) (t3)?DYRS()Does the bug exist in YRS-M2 (t2)?1/217/37
    • TracingYRS-M2YRS-M1 YRS-M2 YS(t1) (t2) (t3)? ?Does the bug exist in YRS-M1/2 (t1)?17/37
    • TracingYRS-M2YRS-M1 YRS-M2 YS(t1) (t2) (t3)? ? ?() Does the bug exist in both t1 and t2?1/217/37
    • TracingYRS-M2YRS-M1 YRS-M2 YS(t1) (t2) (t3)? ? ?DYRS() Answering requires tracing the evolution of single features1/217/37
    • Tracing• Traceability has to be recovered from a multi-space setting:17/37
    • Tracing• Traceability has to be recovered from a multi-space setting:◦ Recover traceability of different artifacts (e.g.: FM, Build files, Ccode)17/37
    • Tracing• Traceability has to be recovered from a multi-space setting:◦ Recover traceability of different artifacts (e.g.: FM, Build files, Ccode)◦ Integrate the evolution history of those artifacts over time17/37
    • Tracing• Traceability has to be recovered from a multi-space setting:◦ Recover traceability of different artifacts (e.g.: FM, Build files, Ccode)◦ Integrate the evolution history of those artifacts over time◦ Draw an evolution history (timeline)17/37
    • Tracing• Traceability has to be recovered from a multi-space setting:◦ Recover traceability of different artifacts (e.g.: FM, Build files, Ccode)◦ Integrate the evolution history of those artifacts over time◦ Draw an evolution history (timeline)YRS-M1YRS-M2(t2)(t1) (t3)YSYRSM MM17/37
    • Tracing(Research questions)18/37
    • Tracing (Research questions)• Tracing certain artifacts can be daunting19/37
    • Tracing (Research questions)• Tracing certain artifacts can be daunting◦ Individual build rules in build files (e.g., make is Turing-complete)19/37
    • 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 costly19/37
    • 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 costlyRQ: How to recover traceability links in build files and sourcecode in variability-aware systems?19/37
    • 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 costlyRQ: How to recover traceability links in build files and sourcecode in variability-aware systems?RQ: Once recovered, how to update them to reflect thetemporal evolution in place?19/37
    • Tracing (Research questions)• Different artifacts = different sources to draw the evolution in place19/37
    • Tracing (Research questions)• Different artifacts = different sources to draw the evolution in place◦ Mailing lists19/37
    • Tracing (Research questions)• Different artifacts = different sources to draw the evolution in place◦ Mailing lists◦ Commit patches and log messages19/37
    • 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 systems19/37
    • 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 systemsRQ: Which sources are trustworthy?19/37
    • Analyses20/37
    • Analyses(Back to the motivating example)21/37
    • AnalysesAfter the evolution of the SPL, stakeholders noticed that:22/37
    • AnalysesAfter the evolution of the SPL, stakeholders noticed that:• Maintenance is taking longer22/37
    • AnalysesAfter the evolution of the SPL, stakeholders noticed that:• Maintenance is taking longer• Productivity has decreased22/37
    • AnalysesAfter the evolution of the SPL, stakeholders noticed that:• Maintenance is taking longer• Productivity has decreased• Bugs are starting to rise22/37
    • AnalysesAfter the evolution of the SPL, stakeholders noticed that:• Maintenance is taking longer• Productivity has decreased• Bugs are starting to riseWell-known phenomena of software aging22/37
    • AnalysesWe envision three analyses to prevent aging:22/37
    • AnalysesWe envision three analyses to prevent aging:• Consistency checking analysis22/37
    • AnalysesWe envision three analyses to prevent aging:• Consistency checking analysis• Change impact analysis22/37
    • AnalysesWe envision three analyses to prevent aging:• Consistency checking analysis• Change impact analysis• Architectural analysis22/37
    • Analyses(Consistency checking)23/37
    • Analyses (Consistency checking)Goal: prevent inconsistencies in different artifactsDNpit24/37
    • Analyses (Consistency checking)Goal: prevent inconsistencies in different artifacts...#ifdef Conv// switch// to Conv// if ABS// fails#endif......sensor_data_t data ;#ifdef SCdata = get_value(data) ;#endifif (data->check_oversteering())react_oversteering() ;......#ifdef SC && YRS_M1double predicted_value...#endif...abs.c (1) abs.c (2) abs.c (3)...#ifdef SC && YRS_M1predictor_t p ;#elseint p = 0;#endif...predicted_value=p->get() ;abs.c (4)DNpit24/37
    • Analyses (Consistency checking)Goal: prevent inconsistencies in different artifacts...#ifdef Conv// switch// to Conv// if ABS// fails#endif......sensor_data_t data ;#ifdef SCdata = get_value(data) ;#endifif (data->check_oversteering())react_oversteering() ;......#ifdef SC && YRS_M1double predicted_value...#endif...abs.c (1) abs.c (2) abs.c (3)...#ifdef SC && YRS_M1predictor_t p ;#elseint p = 0;#endif...predicted_value=p->get() ;abs.c (4)Dead code DNpit24/37
    • Analyses (Consistency checking)Goal: prevent inconsistencies in different artifacts...#ifdef Conv// switch// to Conv// if ABS// fails#endif......sensor_data_t data ;#ifdef SCdata = get_value(data) ;#endifif (data->check_oversteering())react_oversteering() ;......#ifdef SC && YRS_M1double predicted_value...#endif...abs.c (1) abs.c (2) abs.c (3)...#ifdef SC && YRS_M1predictor_t p ;#elseint p = 0;#endif...predicted_value=p->get() ;abs.c (4)Null pointer exception DNpit24/37
    • Analyses (Consistency checking)Goal: prevent inconsistencies in different artifacts...#ifdef Conv// switch// to Conv// if ABS// fails#endif......sensor_data_t data ;#ifdef SCdata = get_value(data) ;#endifif (data->check_oversteering())react_oversteering() ;......#ifdef SC && YRS_M1double predicted_value...#endif...abs.c (1) abs.c (2) abs.c (3)...#ifdef SC && YRS_M1predictor_t p ;#elseint p = 0;#endif...predicted_value=p->get() ;abs.c (4)Syntax errorDNpit24/37
    • Analyses (Consistency checking)Goal: prevent inconsistencies in different artifacts...#ifdef Conv// switch// to Conv// if ABS// fails#endif......sensor_data_t data ;#ifdef SCdata = get_value(data) ;#endifif (data->check_oversteering())react_oversteering() ;......#ifdef SC && YRS_M1double predicted_value...#endif...abs.c (1) abs.c (2) abs.c (3)...#ifdef SC && YRS_M1predictor_t p ;#elseint p = 0;#endif...predicted_value=p->get() ;abs.c (4)DNpit Type error24/37
    • Analyses (Consistency checking)Goal: prevent inconsistencies in different artifacts...#ifdef Conv// switch// to Conv// if ABS// fails#endif......sensor_data_t data ;#ifdef SCdata = get_value(data) ;#endifif (data->check_oversteering())react_oversteering() ;......#ifdef SC && YRS_M1double predicted_value...#endif...abs.c (1) abs.c (2) abs.c (3)...#ifdef SC && YRS_M1predictor_t p ;#elseint p = 0;#endif...predicted_value=p->get() ;abs.c (4)Other types of analysis exist: e.g., model-checkingDNpit24/37
    • Consistency checking(Research questions)25/37
    • Consistency checking (Research questions)• Variability aware-analysis is costly.26/37
    • 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 largesystems?26/37
    • 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 largesystems?• Existing flow-analysis is intra-procedural.26/37
    • 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 largesystems?• Existing flow-analysis is intra-procedural.RQ: How to adapt existing inter-procedural analyses tohandle variability?26/37
    • Analyses(Impact analysis)27/37
    • Impact analysisGoal: assess impact of changes28/37
    • Impact analysisGoal: assess impact of changesScenario:• To identify bugs, stakeholders in our SPL have created formalspecifications of the system’s features• Support for cruise control (CC)28/37
    • Impact analysisGoal: assess impact of changesScenario:• To identify bugs, stakeholders in our SPL have created formalspecifications of the system’s features• Support for cruise control (CC)CarYRSYRS-M2SCABSSCSCConvFeaturemodelBRAABSConvYRS SCYRS-M1CC28/37
    • Impact analysisStability-control behaviour property: No subsystem increasesacceleration when SC is engaged29/37
    • Impact analysisStability-control behaviour property: No subsystem increasesacceleration when SC is engaged1. CC cruise speedis set2. Engage CC3. Drivers loosescontrol4. Engage SC5. CC accelerates toachieve cruise speed29/37
    • Impact analysisStability-control behaviour property: No subsystem increasesacceleration when SC is engaged1. CC cruise speedis set2. Engage CC3. Drivers loosescontrol4. Engage SC5. CC accelerates toachieve cruise speedAdding CC violates the given property29/37
    • Impact analysisStability-control behaviour property: No subsystem increasesacceleration when SC is engaged1. CC cruise speedis set2. Engage CC3. Drivers loosescontrol4. Engage SC5. CC accelerates toachieve cruise speedAdding CC violates the given property(Impact analysis aims to detect that promptly)29/37
    • Impact analysis (Research questions)• Currently, consistency between implementation assets (code) andthe system’s specified property is mostly intractable.30/37
    • Impact analysis (Research questions)• Currently, consistency between implementation assets (code) andthe system’s specified property is mostly intractable.RQ: How to verify that the system implementation does notbreak its specified properties?30/37
    • Analyses(Architectural analysis)31/37
    • 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-basedmetrics◦ feature-model based metrics◦ product-line based metrics32/37
    • Architectural analysis• Evidence relating scattering and defects is rather preliminary.33/37
    • Architectural analysis• Evidence relating scattering and defects is rather preliminary.RQ: Can we provide more evidence for the relationshipbetween scattering and defects?33/37
    • Recommendations34/37
    • Recommendations + research questionSuggestions for:35/37
    • Recommendations + research questionSuggestions for:• Consistency analysis35/37
    • Recommendations + research questionSuggestions for:• Consistency analysis• Impact analysis35/37
    • Recommendations + research questionSuggestions for:• Consistency analysis• Impact analysis• Architectural analysis35/37
    • Recommendations + research questionConsistency:• Fix recommendations for different artifacts types35/37
    • Recommendations + research questionConsistency:• Fix recommendations for different artifacts typesRQ: How to devise a fixing recommender integratingdifferent artifacts, with different abstraction levels?35/37
    • Recommendations + research questionConsistency:• Fix recommendations for different artifacts typesRQ: How to devise a fixing recommender integratingdifferent artifacts, with different abstraction levels?Impact analysis:• Point which features are more likely to have defects after a change35/37
    • Recommendations + research questionConsistency:• Fix recommendations for different artifacts typesRQ: How to devise a fixing recommender integratingdifferent artifacts, with different abstraction levels?Impact analysis:• Point which features are more likely to have defects after a changeRQ: Which feature-based metrics are good defect predictors?35/37
    • Recommendations + research questionArchitectural analysis:35/37
    • Recommendations + research questionArchitectural analysis:• Propose merges (features are too similar)35/37
    • Recommendations + research questionArchitectural analysis:• Propose merges (features are too similar)• Suggest feature retirement35/37
    • Recommendations + research questionArchitectural analysis:• Propose merges (features are too similar)• Suggest feature retirement• Suggest which features to modularize35/37
    • Recommendations + research questionArchitectural analysis:• Propose merges (features are too similar)• Suggest feature retirement• Suggest which features to modularizeRQ: Which scenarios should be supported (are required inpractice)?35/37
    • Conclusion• We hypothesized that feature-oriented evolution can mitigateexisting 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 vision36/37
    • Thanks for listening!37/37