feature-oriented software evolution
Post on 18-Dec-2014
140 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
Software evolves. . .
2/37
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
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
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
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
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
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
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
Understanding the evolution inplace is not easy. . .
4/37
Scenario
ABS + SC
5/37
Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
Syste
m leve
l
Code l
evel
Manag
emen
t leve
l
5/37
Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
Syste
m leve
l
Code l
evel
Manag
emen
t leve
l
5/37
Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
Syste
m leve
l
Code l
evel
Manag
emen
t leve
l
5/37
Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
Syste
m leve
l
Code l
evel
Manag
emen
t leve
l
⇐ Developers
5/37
Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
Syste
m leve
l
Code l
evel
Manag
emen
t leve
l
⇐ System engineers
5/37
Scenario
• Integration can scatter different artifacts
• Different levels of abstractions not mastered by all stakeholders
Syste
m leve
l
Code l
evel
Manag
emen
t leve
l
⇐ Project managers
5/37
In practical settings. . .
6/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 software
Stakeholders need a common meeting point
7/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 software
Stakeholders need a common meeting point
7/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 software
Stakeholders need a common meeting point
7/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 software
Stakeholders need a common meeting point
7/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 software
Stakeholders need a common meeting point
7/37
Otherwise. . .(no common meeting point)
Ineffective communication Software flaws
Architecture decay Higher maintenance costs
8/37
Otherwise. . .(no common meeting point)
Ineffective communication
Software flaws
Architecture decay Higher maintenance costs
8/37
Otherwise. . .(no common meeting point)
Ineffective communication Software flaws
Architecture decay Higher maintenance costs
8/37
Otherwise. . .(no common meeting point)
Ineffective communication Software flaws
Architecture decay
Higher maintenance costs
8/37
Otherwise. . .(no common meeting point)
Ineffective communication Software flaws
Architecture decay Higher maintenance costs
8/37
Hypothesis
9/37
Hypothesis
Managing evolution at the level of features can addressthe challenges describe above
10/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
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
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
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
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
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
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
Our vision(Assuming the validity of our hypothesis)
11/37
Feature-oriented evolution based on:
Tracing
Analyses
Recommendations
12/37
Feature-oriented evolution based on:
Tracing
Analyses
Recommendations
12/37
Feature-oriented evolution based on:
Tracing
Analyses
Recommendations
12/37
Purpose of our work
Research agenda basedon our vision for feature-oriented
software evolution
This presentation covers part of that agenda(see paper for more details)
13/37
Motivating example
14/37
Motivating example
Car
YRS
YRS-M2
SC
ABS SC
SC Conv
Fea
ture
mod
el
BRA
ABSConv
YRS SC
YRS-M1
Merge + clone yaw rate prediction
15/37
Motivating example
Car
YRS
YRS-M2
SC
ABS SC
SC Conv
Fea
ture
mod
el
BRA
ABSConv
YRS SC
YRS-M1
Merge + clone yaw rate prediction
15/37
Motivating example
Car
YRS
YRS-M2
SC
ABS SC
SC Conv
Fea
ture
mod
el
BRA
ABSConv
YRS SC
Merge + clone yaw rate prediction
15/37
Motivating example
Car
YRS
YRS-M2
SC
ABS SC
SC Conv
Fea
ture
mod
el
BRA
ABSConv
YRS SC
Merge YRS-M2 into YRS + rename YRS to YS
15/37
Motivating example
Car
YSSC
ABS SC
SC Conv
Fea
ture
mod
el
BRA
ABSConv
YS SC
Merge + clone yaw rate prediction
15/37
Tracing
16/37
Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
DYRS()1/2
17/37
Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
DYRS()1/2Bug found in YS
17/37
Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
?DYRS()Does the bug exist in YRS-M2 (t2)?1/2
17/37
Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
? ?Does the bug exist in YRS-M1/2 (t1)?
17/37
Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
? ? ?() Does the bug exist in both t1 and t2?1/2
17/37
Tracing
YRS-M2YRS-M1 YRS-M2 YS
(t1) (t2) (t3)
? ? ?DYRS() Answering requires tracing the evolution of single features1/2
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-M1
YRS-M2
(t2)(t1) (t
3)
YS
YRS
M M
M
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-M1
YRS-M2
(t2)(t1) (t
3)
YS
YRS
M M
M
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-M1
YRS-M2
(t2)(t1) (t
3)
YS
YRS
M M
M
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-M1
YRS-M2
(t2)(t1) (t
3)
YS
YRS
M M
M
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-M1
YRS-M2
(t2)(t1) (t
3)
YS
YRS
M M
M
17/37
Tracing(Research questions)
18/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 costly
RQ: 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)
• 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 sourcecode in variability-aware systems?
RQ: Once recovered, how to update them to reflect thetemporal evolution in place?
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 costly
RQ: 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)
• 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 sourcecode in variability-aware systems?
RQ: Once recovered, how to update them to reflect thetemporal evolution in place?
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 costly
RQ: 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 place
◦ Mailing lists
◦ Commit patches and log messages
◦ Bug reports in bug tracking systems
RQ: Which sources are trustworthy?
19/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 systems
RQ: Which sources are trustworthy?
19/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 systems
RQ: Which sources are trustworthy?
19/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 systems
RQ: Which sources are trustworthy?
19/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 systems
RQ: Which sources are trustworthy?
19/37
Analyses
20/37
Analyses(Back to the motivating example)
21/37
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
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
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
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
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
Analyses
We envision three analyses to prevent aging:
• Consistency checking analysis
• Change impact analysis
• Architectural analysis
22/37
Analyses
We envision three analyses to prevent aging:
• Consistency checking analysis
• Change impact analysis
• Architectural analysis
22/37
Analyses
We envision three analyses to prevent aging:
• Consistency checking analysis
• Change impact analysis
• Architectural analysis
22/37
Analyses
We envision three analyses to prevent aging:
• Consistency checking analysis
• Change impact analysis
• Architectural analysis
22/37
Analyses(Consistency checking)
23/37
Analyses (Consistency checking)
Goal: prevent inconsistencies in different artifacts
DNpit
24/37
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
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
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
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
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
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
Consistency checking(Research questions)
25/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
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
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
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 analysis
Goal: assess impact of changes
Scenario:
• To identify bugs, stakeholders in our SPL have created formalspecifications of the system’s features
• Support for cruise control (CC)
Car
YRS
YRS-M2
SC
ABS SC
SC Conv
Fea
ture
mod
el
BRA
ABSConv
YRS SC
YRS-M1
CC
28/37
Impact analysis
Goal: assess impact of changes
Scenario:
• To identify bugs, stakeholders in our SPL have created formalspecifications of the system’s features
• Support for cruise control (CC)
Car
YRS
YRS-M2
SC
ABS SC
SC Conv
Fea
ture
mod
el
BRA
ABSConv
YRS SC
YRS-M1
CC
28/37
Impact analysis
Goal: assess impact of changes
Scenario:
• To identify bugs, stakeholders in our SPL have created formalspecifications of the system’s features
• Support for cruise control (CC)
Car
YRS
YRS-M2
SC
ABS SC
SC Conv
Fea
ture
mod
el
BRA
ABSConv
YRS SC
YRS-M1
CC
28/37
Impact analysis
Stability-control behaviour property: No subsystem increasesacceleration when SC is engaged
1. CC cruise speed is set
2. Engage CC
3. Drivers loosescontrol
4. Engage SC5. CC accelerates to achieve cruise speed
Adding CC violates the given property
(Impact analysis aims to detect that promptly)
29/37
Impact analysis
Stability-control behaviour property: No subsystem increasesacceleration when SC is engaged
1. CC cruise speed is set
2. Engage CC
3. Drivers loosescontrol
4. Engage SC5. CC accelerates to achieve cruise speed
Adding CC violates the given property
(Impact analysis aims to detect that promptly)
29/37
Impact analysis
Stability-control behaviour property: No subsystem increasesacceleration when SC is engaged
1. CC cruise speed is set
2. Engage CC
3. Drivers loosescontrol
4. Engage SC5. CC accelerates to achieve cruise speed
Adding CC violates the given property
(Impact analysis aims to detect that promptly)
29/37
Impact analysis
Stability-control behaviour property: No subsystem increasesacceleration when SC is engaged
1. CC cruise speed is set
2. Engage CC
3. Drivers loosescontrol
4. Engage SC5. CC accelerates to achieve cruise speed
Adding 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.
RQ: How to verify that the system implementation does notbreak its specified properties?
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 metrics
32/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
Architectural analysis
• Evidence relating scattering and defects is rather preliminary.
RQ: Can we provide more evidence for the relationshipbetween scattering and defects?
33/37
Recommendations
34/37
Recommendations + research question
Suggestions for:
• Consistency analysis
• Impact analysis
• Architectural analysis
35/37
Recommendations + research question
Suggestions for:
• Consistency analysis
• Impact analysis
• Architectural analysis
35/37
Recommendations + research question
Suggestions for:
• Consistency analysis
• Impact analysis
• Architectural analysis
35/37
Recommendations + research question
Suggestions for:
• Consistency analysis
• Impact analysis
• Architectural analysis
35/37
Recommendations + research question
Consistency:
• Fix recommendations for different artifacts types
RQ: 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 change
RQ: Which feature-based metrics are good defect predictors?
35/37
Recommendations + research question
Consistency:
• Fix recommendations for different artifacts types
RQ: 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 change
RQ: Which feature-based metrics are good defect predictors?
35/37
Recommendations + research question
Consistency:
• Fix recommendations for different artifacts types
RQ: 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 change
RQ: Which feature-based metrics are good defect predictors?
35/37
Recommendations + research question
Consistency:
• Fix recommendations for different artifacts types
RQ: 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 change
RQ: Which feature-based metrics are good defect predictors?
35/37
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 inpractice)?
35/37
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 inpractice)?
35/37
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 inpractice)?
35/37
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 inpractice)?
35/37
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 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 vision
36/37
Thanks for listening!
37/37
top related