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

Extending the Reflexion Method for Consolidating Software Variants into Product Lines

Pierre Frenzel1, Rainer Koschke1, Andreas P.J. Breu2, Karsten Angstmann2

1University of Bremen 2Robert-Bosch GmbH

IEEE Working Conference on Reverse Engineering Vancouver, 30th October 2007

Software Variants

1.0

Client 1

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants

1.0

Client 1

1.1

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants

1.0

Client 1

1.1 1.0.1

Client 2

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants

1.0

Client 1

1.1 1.0.1

Client 2

1.3 1.2 1.0.2

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants

1.0

Client 1

1.1 1.0.1

Client 2

1.3 1.2 1.0.2

Client 3

1.0.1.1

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants

1.0

Client 1

1.1 1.0.1

Client 2

1.3 1.2 1.0.2

Client 3

1.0.1.1

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 2 / 23

Software Variants

1.0

Client 1

1.1 1.0.1

Client 2

1.3 1.2 1.0.2

Client 3

1.0.1.1

• 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

C3 C1 C2

• 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

C3 C1 C2

B A 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

architecture product code

C2 C3

variant 1 A C B

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 6 / 23

Extended Reflexion Method for Variants

Process

C1

architecture product code

C2 C3

variant 1 A C B variant 2 C’ B

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 6 / 23

Extended Reflexion Method for Variants

Process

C1

architecture product code

C2 C3

variant 1 A C B variant 2 C’ B 100% similar 85% similar

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 6 / 23

Extended Reflexion Method for Variants

Process

C1

architecture product code

C2 C3

variant 1 A C B variant 2 C’ B 100% similar 85% similar

C2 C3’

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 6 / 23

Extended Reflexion Method for Variants

Process

C1

architecture product code

C2 C3

variant 1 A C B variant 2 C’ B 100% similar 85% similar

C2 C3’ C4 C1

SPL architecture

C2

≪optional≫

≪variant≫ C3 C3’ ≪variant≫

≪kernel≫

≪kernel≫

{mutually exclusive}

• 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 device1 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).

1Potentially 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:

foo() foo()

100%

single identical

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 11 / 23

Uniqueness of function correspondence

Types of correspondences:

foo() foo()

100%

single identical multi foo()

100% 100% 100%

foo3() foo2() foo1()

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 11 / 23

Uniqueness of function correspondence

Types of correspondences:

foo() foo()

100%

single identical multi foo()

100% 100% 100%

foo3() foo2() foo1()

foo() foo()

< 100%

variant

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 11 / 23

Uniqueness of function correspondence

Types of correspondences:

foo() foo()

100%

single identical multi foo()

100% 100% 100%

foo3() foo2() foo1()

foo() foo()

< 100%

variant foo()

< 100% < 100% < 100%

foo3() foo2() foo1()

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 11 / 23

Uniqueness of function correspondence

H → L where |H| = 1, 538 and |L| = 1, 017

similarity threshold

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 12 / 23

Validation of single-variant correspondences

For θ = 0.6, 175 single-variant correspondences were proposed.

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 13 / 23

Uniqueness of kernel function correspondence

HK → LK for kernel functions where |HK| = 584 and |LK| = 520

similarity threshold

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 14 / 23

Uniqueness of feature function correspondence

HP → LP for feature functions where |HP| = 954 and |LP| = 497

similarity threshold

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 15 / 23

Shared architectural modules and dependences

• nly in L
• nly in H

in L and H #modules 1 5 30 #dependences 10 78 149 Remarks Two-level hierarchy top-level is the same differences are at lower level

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 16 / 23

Similarity in Architectural Conformance

11 #only in H #only in L #in both absences divergences 35 11 1 convergences 100 11 107 Remarks no absences because architecture was reconstructed bottom-up divergences mostly between non-corresponding modules convergences indicate that architecture of L is subsumed by architecture of H

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 17 / 23

Conclusions

We extended reflexion method for software variants. New method leverages similarity at code and architecture level. Industrial case study demonstrates feasibility: mapping and architecture can be transferred largely for kernel modules even for worst case (low-end and high-end variant).

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 18 / 23

Related Research (sorry, guys, not yet done . . . )

Decision making and process Faust and Verhoef (2003) observed frequent development pattern in the information systems world they named software mitosis; propose grow-and-prune model. MAP by Stoermer and O’Brien (2001) and OAR by Bergey et al. (2002): process for selecting existing components for integration in a product line.

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 19 / 23

Related Research (sorry, guys, not yet done . . . )

Decision making and process Faust and Verhoef (2003) observed frequent development pattern in the information systems world they named software mitosis; propose grow-and-prune model. MAP by Stoermer and O’Brien (2001) and OAR by Bergey et al. (2002): process for selecting existing components for integration in a product line. Techniques Baxter and Churchett (2002) use clone detection to find domain concepts in SPLs Maccari and Riva (2001) describe architecture conformance checking for SPLs. Kolb et al. (2006) systematically refactor an existing software component for reuse in an SPL. Riva (2004) proposed method for reconstructing various architectural views of products in an SPL.

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 19 / 23

Related Research (sorry, guys, not yet done . . . )

Decision making and process Faust and Verhoef (2003) observed frequent development pattern in the information systems world they named software mitosis; propose grow-and-prune model. MAP by Stoermer and O’Brien (2001) and OAR by Bergey et al. (2002): process for selecting existing components for integration in a product line. Techniques Baxter and Churchett (2002) use clone detection to find domain concepts in SPLs Maccari and Riva (2001) describe architecture conformance checking for SPLs. Kolb et al. (2006) systematically refactor an existing software component for reuse in an SPL. Riva (2004) proposed method for reconstructing various architectural views of products in an SPL. → No technique for analyzing variants—i.e., unorganized, highly

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 19 / 23

Threats to Validity

• nly two variants of a family of hundreds of variants

two extreme cases (low-end and high-end variant)

• nly one domain—embedded software

industrial code

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 20 / 23

Baxter, I. D. and D. Churchett (2002). Using clone detection to manage a product line. In ICSR7 Workshop, Industrial Experience with Product Line Approaches. PositionPaper. Bergey, J., L. O’Brien, and D. Smith (2002, August). Using options analysis for reengineering (OAR) for mining components for a product

• line. In Proceedings of Second Software Product Line Conference,

Volume 2379, pp. 316–327. Springer Lecture Notes in Computer Science. Faust, D. and C. Verhoef (2003, August). Software product line migration and deployment. Journal of Software Practice and Experiences 33(10), 933955. Kolb, R., D. Muthig, T. Patzke, and K. Yamauchi (2006, March–April). Refactoring a legacy component for reuse in a software product line: A case study. Journal of Software Maintenance and Evolution: Research and Practice 18(2), 109–132.

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 21 / 23

Maccari, A. and C. Riva (2001). Architectural evolution of legacy product

• families. In Proceedings of the Fourth International Workshop on

Product Family Engineering (PFE-4), pp. 63–68. Murphy, G. C., D. Notkin, and K. Sullivan (1995). Software reflexion models: Bridging the gap between source and high-level models. In Proceedings of the Third ACM SIGSOFT Symposium on the Foundations of Software Engineering, New York, NY, pp. 18–28. ACM Press. Riva, C. (2004, October). View-based Software Architecture

• Reconstruction. Ph. d. dissertation, Vienna University of Technology,

Vienna, Austria. Stoermer, C. and L. O’Brien (2001, August). MAP—mining architectures for product line evaluations. In IEEE/IFIP Working Conference on Software Architecture, pp. 35–44. IEEE Computer Society Press. Xing, Z. and E. Stroulia (2004). Understanding phases and styles of

• bject-oriented systems’ evolution. In International Conference on

Software Maintenance, pp. 242–251. IEEE Computer Society Press.

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 22 / 23

Zou, L. and M. Godfrey (2003). Detecting merging and splitting using

• rigin analysis. In Working Conference on Reverse Engineering, pp.

146–154. IEEE Computer Society Press.

• R. Koschke (Univ. Bremen)

Reflexion for Product Lines WCRE07, Oct/30/07 23 / 23