Extending the Reflexion Method for Consolidating Software Variants - PowerPoint PPT Presentation

Extending the Reflexion Method for Consolidating Software Variants into Product Lines Pierre Frenzel 1 , Rainer Koschke 1 , Andreas P.J. Breu 2 , Karsten Angstmann 2 1 University of Bremen 2 Robert-Bosch GmbH IEEE Working Conference on Reverse Engineering Vancouver, 30th October 2007

Software Variants Client 1 1.0 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants Client 1 1.0 1.1 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants Client 2 1.0.1 Client 1 1.0 1.1 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants Client 2 1.0.1 1.0.2 Client 1 1.0 1.1 1.2 1.3 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants Client 3 1.0.1.1 Client 2 1.0.1 1.0.2 Client 1 1.0 1.1 1.2 1.3 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants Client 3 1.0.1.1 Client 2 1.0.1 1.0.2 Client 1 1.0 1.1 1.2 1.3 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants Client 3 1.0.1.1 Client 2 1.0.1 1.0.2 Client 1 1.0 1.1 1.2 1.3 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Consolidation of Software Variants Problem: redundancy in software variants requires repeated changes. Solution: consolidate variants into a managed software product lines with better means for variability implementation: parameterization, generics, code generation, design patterns, . . . R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 3 / 23

Consolidation of Software Variants Problem: redundancy in software variants requires repeated changes. Solution: consolidate variants into a managed software product lines with better means for variability implementation: parameterization, generics, code generation, design patterns, . . . Required: commonalities and variabilities among variants at all levels: source code architectural level feature level R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 3 / 23

Consolidation of Software Variants Problem: redundancy in software variants requires repeated changes. Solution: consolidate variants into a managed software product lines with better means for variability implementation: parameterization, generics, code generation, design patterns, . . . Required: commonalities and variabilities among variants at all levels: source code → diff & Co. architectural level feature level R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 3 / 23

Consolidation of Software Variants Problem: redundancy in software variants requires repeated changes. Solution: consolidate variants into a managed software product lines with better means for variability implementation: parameterization, generics, code generation, design patterns, . . . Required: commonalities and variabilities among variants at all levels: source code → diff & Co. architectural level → architecture reconstruction feature level R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 3 / 23

Consolidation of Software Variants Problem: redundancy in software variants requires repeated changes. Solution: consolidate variants into a managed software product lines with better means for variability implementation: parameterization, generics, code generation, design patterns, . . . Required: commonalities and variabilities among variants at all levels: source code → diff & Co. architectural level → architecture reconstruction feature level → feature location (future work) R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 3 / 23

Consolidation of Software Variants Problem: redundancy in software variants requires repeated changes. Solution: consolidate variants into a managed software product lines with better means for variability implementation: parameterization, generics, code generation, design patterns, . . . Required: commonalities and variabilities among variants at all levels: source code → diff & Co. architectural level → architecture reconstruction feature level → feature location (future work) Focus of this paper use of reflexion method (Murphy et al., 1995) for architecture reconstruction for variants R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 3 / 23

Reflexion Method (Murphy et al., 1995) 1 Create hypothesized architecture model. 2 Extract source model. 3 Map source entities onto architectural entities. 4 Compute reflexion model. 5 Refine/correct. Example C1 C2 C3 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 4 / 23

Reflexion Method (Murphy et al., 1995) 1 Create hypothesized architecture model. 2 Extract source model. 3 Map source entities onto architectural entities. 4 Compute reflexion model. 5 Refine/correct. Example C1 C2 C3 A B C R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 4 / 23

Reflexion Method for Software Variants Current state: reflexion method designed for single systems only. Observations: mapping is manual and expensive work, variants are similar in source code and architecture. Goal: avoid rework by incremental reflexion method. Idea: carry over mapping and architecture between variants. R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 5 / 23

Extended Reflexion Method for Variants Process C1 C2 C3 product architecture code A B C variant 1 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 6 / 23

Extended Reflexion Method for Variants Process C1 C2 C3 product architecture code A B C B C’ variant 1 variant 2 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 6 / 23

Extended Reflexion Method for Variants Process C1 C2 C3 product architecture code A B C B C’ variant 1 100% similar 85% similar variant 2 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 6 / 23

Extended Reflexion Method for Variants Process C1 C2 C3 C2 C3’ product architecture code A B C B C’ variant 1 100% similar 85% similar variant 2 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 6 / 23

Extended Reflexion Method for Variants Process C1 C2 C4 ≪ kernel ≫ ≪ optional ≫ ≪ kernel ≫ { mutually exclusive } SPL ≪ variant ≫ ≪ variant ≫ architecture C3 C3’ C1 C2 C3 C2 C3’ product architecture code A B C B C’ variant 1 100% similar 85% similar variant 2 R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 6 / 23

Corresponding functions among variants Determining correspondence of functions among variants 1 identify candidate pairs using clone detection 2 measure similarity of pairs using normalized Levenshtein distance 3 rank according to similarity 4 let user validate → independent of naming N.B.: Problem similar to origin analysis (Zou and Godfrey, 2003; Xing and Stroulia, 2004) R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 7 / 23

Research question Evaluation Goal: Incrementally transferring mapping and architecture between variants Questions: How similar are systems in terms of code and architecture? Metrics: similarity at code level → uniqueness of function correspondence between variants similarity at architectural level: → degree of shared modules and dependences among architectures similarity in architectural conformance: → degree of shared convergences, divergences, and absences R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 8 / 23

Case Study: Bosch Automotive Embedded Software Family of systems: Industrial embedded software for automotive control device 1 written in C. Deployed by different manufacturers in cars ranging from low-end to high-end. Number of variants: several hundreds (different branches in version control system). 1 Potentially embedded in your car, too. R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 9 / 23

Case Study: Bosch Automotive Embedded Software Selected two variants (from different car manufacturers): L: low-end car variant H: high-end car variant → worst-case scenario R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 10 / 23

Case Study: Bosch Automotive Embedded Software Selected two variants (from different car manufacturers): L: low-end car variant H: high-end car variant → worst-case scenario Architecture: kernel modules: provides hardware abstraction and low-level services largely re-usable across manufacturers and car models feature modules: product-specific functions for one particular car model of one manufacturer variant SLOC files kernel C functions feature C functions L 64,091 448 520 497 H 106,383 470 584 954 Architecture reconstruction started with L. R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 10 / 23

Uniqueness of function correspondence Types of correspondences: identical 100% foo() single foo() R. Koschke (Univ. Bremen) Reflexion for Product Lines WCRE07, Oct/30/07 11 / 23