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