Feature-Level Change Impact Analysis Using Formal Concept Analysis

1. Feature-Level Change Impact Analysis Using Formal Concept Analysis HamzehEyal-Salman U N I V E R S I T É M O N T P E L L I E R I I LIRMM Lab. SEKE Conference July 1-3, 2014

2. Outline • Background • Software Product Variants • Software Product Line Engineering • Feature-Level Change Impact Analysis • Proposed Approach • Experimental Evaluation • Conclusion

3. Software Product Variants Definition • Software product variants • A collection of similar software products developed by ad-hoc reuse techniques sharing some features (mandatory features) and differing in others (optional features). • A feature is a prominent or distinctive user-visible aspect, quality or characteristic of a software system [Kang et al. 1990] Background Proposed Approach Experimental Evaluation Conclusion

4. Drawbacks of ad-hoc Development • Solution: • Transformation from ad-hoc development (software product variants) to systematic development (software product line engineering). • Reusing features (resp. their implementations) is time-consuming • Changes made to code of common features must be repeated • Evolving product variants lack prescribed planning Background Proposed Approach Experimental Evaluation Conclusion

5. Software Product Line (SPL) Definition & Benefits • Benefits of SPLE • Reduction of maintenance effort • Enhancement of quality • Reduction of development costs • Reduction of time to market Product decisions SPL Production Core assets Basics SPL concepts [Charles Kruger 2006] Software Product Line (SPL) • A family of software-intensive systems • Sharing a common, managed set of features • Developed from a common set of core assets in prescribed way Background Proposed Approach Experimental Evaluation Conclusion

6. Re-engineering Software Product Variants into SPL • Recovering traceability links between features and their implementing source code elements: • Understanding source code of product variants • Reusing right features (resp. their implementations) • Facilitating and Automating new product derivation from SPL’s core assets. • The process of finding such traceability links is known as a feature location. Background Proposed Approach Experimental Evaluation Conclusion

7. Feature-Level Change Impact Analysis [1/2] • Features (resp. their implementation) obtained from product variants ma need to be changed adapting new context (SPLE). • Conducting change impact analysis at feature level for source code changes allow SPL’s manager participate in re-engineering process through change management. • Feature-level CIA is process of determining feature(s) that may be impact for a given change proposal before the change is implemented. Background Proposed Approach Experimental Evaluation Conclusion

8. Feature-Level Change Impact Analysis [2/2] • Change management from SPL manager point of view Feature Level Legend: C: Class F: Feature F F F F Maintainer Traceability Link C Change C C C C C C C C C C C C C C Source Code Level C Background Proposed Approach Experimental Evaluation Conclusion

9. State-Of-The-Art • There is a large body of research proposed for supporting CIA at source code level • [Bixin et al., 2012] - Survey • Few approaches preform CIA at other levels of abstractions • [Apel et Beyer, 2011] • [Hammad et al., 2011] • [Briand et al., 2009] • [Xiao et al., 2007] • [Ibrahim et al., 2005] • CIA at feature level is seldom considered • [Revelleet al. 2011] Background Proposed Approach Experimental Evaluation Conclusion

10. Outline • Background • Software Product Variants • Software Product Line Engineering • Feature-Level Change Impact Analysis • Proposed Approach • Experimental Evaluation • Conclusion Background Proposed Approach Experimental Evaluation Conclusion

11. Illustrative Example • Four product variants of a software bank system Background Proposed Approach Experimental Evaluation Conclusion

12. The Proposed Process of Feature-Level CIA Determining Coupled Features using FCA Determining the Impact Set of Classes Querying Concept Lattice FeatureΧClass Matrix Concept Lattice Change Set Impact Set of Classes A Ranked List of Affected Features Source Code • Input: Source code, classes to be changed and feature-to-class traceability matrix. • Output: A ranked list of affected features. Background Proposed Approach Experimental Evaluation Conclusion

13. Step1: Determining the Impact Set of Classes • Statically analyzing the source code of features • Using abstract syntax tree (AST) • Determining coupled classes based on • Inheritance relationship • Method call • Attribute access • Shared attribute access Background Proposed Approach Experimental Evaluation Conclusion

14. Step2: Determining Coupled Features Using FCA • An example of determining coupled features using FCA Intent Extent Background Proposed Approach Experimental Evaluation Conclusion

15. Step3: Querying concept lattice for determining a ranked list of affected features using impact set of classes Transfer CreateAccount BillPayment Deposite Loan Withdraw • Consider the impact set of classes consists of {DeositeAuthentication, TargetAccount, PayPartially} Background Proposed Approach Experimental Evaluation Conclusion

16. Ranking the Affected Features using Impact Degree Metric (IDM) • We propose two metrics to support feature-level CIA: • Impact Degree Metric (IDM) • To measure the degree to which the implementation of a given feature can be affected. • Changeability Assessment Metric (CAM) • To measure the percentage of features that are affected by a given change proposal. Background Proposed Approach Experimental Evaluation Conclusion

17. Outline • Background • Software Product Variants • Software Product Line Engineering • Feature-Level Change Impact Analysis • Proposed Approach • Experimental Evaluation • Conclusion Background Proposed Approach Experimental Evaluation Conclusion

18. Experimental Evaluation Subject core assets and their respective information • Case studies • Evaluation measures • Precision: is the percentage of the estimated affected features that are actually impacted to all estimated affected features • Recall: is the percentage of the estimated affected features that are really impacted to all actually affected features • F-measure: to find the best possible compromise between recall and precision Background Proposed Approach Experimental Evaluation Conclusion

19. Experimental Evaluation [Cont.] • Precision: [60% - 100%] - CSC : change set of classes • Recall: [75% - 100%] - EIS : Estimated impacted set of features • F-measure: [67% -100%] Background Proposed Approach Experimental Evaluation Conclusion

20. Conclusion • We have proposed a feature-level CIA approach to study the impact of changes made to source code of features obtained from product variants • Experimental results for three core assets of three case studies proved the effectiveness of our approach in terms of the most used metrics on the subject (precision, recall and F-measure). Background Proposed Approach Experimental Evaluation Conclusion

21. Thank You HamzehEyal Salman hamzehahu@gmail.com