R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Jens Knodel Dirk Muthig

Slide 1 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Outline Subject Component Architecture Development Reverse Engineering Discussion

Slide 2 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Context Large organization migrating towards product line engineering -Application of PuLSE  Scoping  Architecting  Component engineering Product line architecture -Family of car multimedia systems -Automotive domain -Two major parts  Panel: mainly used for user interaction  Back-end system: mainly used for computation, network functionality, and external media

Slide 3 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Motivation Components as part of product line architectures -Explicitly developed for systematic reuse -Support the scope of variability required -Flexible towards the anticipated changes Existing components -Do they achieve sufficient product line adequacy?  Injection the required variability support  Resolution potential architectural mismatches  Improvement of the internal quality Decision conflict of product line architects -Reuse and adaptation of existing component -Construction of new components from scratch  Application of reverse engineering to analyze the product line adequacy of the existing components

Slide 4 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Subject Component Subject: Graphics component -Key component of the panel -Responsibilities  User interface visualization based on predefined masks  Composition of masks  Interaction between back-end and panel  Graphical elements -Static information -Dynamic sequence control -Main architectural driver: minimization of the data flow between the two parts -Written in C++, approximately 180 KLOC

Slide 5 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Approach

Slide 6 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components PuLSE-DSSA Product Line Software Engineering – Domain-Specific Software Architecture -Scenario-based development in iterations that explicitly addresses the stakeholders’ needs -Incremental development, which successively prioritizes requirements and realizes them -Direct integration of reengineering activities into the development process on demand -View-based documentation -Main loop steps  Planning  Realization  Documentation  Assessment

Slide 7 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components ADORE Architecture- and Domain-Oriented Reengineering -Reverse engineering  Identification of components  Assessment of their adequacy  Initiated product line architecture needs -Reuse Decision  Reuse of existing component  Development of a new product line component from scratch -Renovation  Necessary renovation and extension activities  Adaptation of the component for its product line use

Slide 8 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Reverse Engineering Techniques Concerns -Static architecture evaluations.  Was the component implemented accordingly to its documentation, how consistent is the documentation and can it integrated seamlessly into the product line architecture? -Variability analysis  To which degree contains the subject component already existing variability?  Is it possible to relate these code-level variations to higher levels? -Source code analysis  What are maintenance and evolution risks of the current implementation? -Code comments  Have the algorithms and implementation decisions made so far been documented?

Slide 9 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Static Architecture Evaluation Consistency of the component to its documentation Component engineering models -Decomposition into three internal layers -Mapping of layers to the source code files High degree of consistency -Layer-1 uses Layer-2, grey arrow, cardinality Violations:  Layer-2 to Layer-1 (blue arrow, cardinality 2) -Absence  Layer-2 to Layer-3  the layer was only realized in stubs, was still under development Detailed analysis of layers internals -Pointers for improvement

Slide 10 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Variability Analysis Variants in the source code -Conditional compilation with macros -Optional or variable code parts or alternative implementations with preprocessor commands #if, #ifdef, etc.) -Resolution by the preprocessor Variability analysis -To which extent the macros and compile switches realize variability with respect to the product map -Explicit documentation of variability identified -Derivation of decision models Advanced variability management: frame processors -Frames contain both source code and frame-specific code providing adaptation (frame commands) -Frames can be arranged in hierarchies -Resolution at compile time by the frame processor, an advanced preprocessor -Tool-supported conversion of macros into frames -Adding a new variant involves only the creation of the respective frames

Slide 11 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Clone Detection Code clone is a code fragment that occurs in more than one place -Master and clone: produced by copy and paste (sometimes containing minor modifications) -Threat to the evolution of a system or a component  Increased total code size  Higher effort for maintenance (when there is the need for a change, all duplicates have to be addressed)  Reduced code readability  Increased risk because an error can be propagated to several places in the source code Clone detection -Based on text pattern matching -Internal clones (duplicated code lines found in a single file) -External clones (clones found in different files) -Number of code clones with a size greater than 20 lines

Slide 12 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Metric Hotspots Source code metrics -Learn about potentially problematic areas -Measurement of coupling, size and complexity metrics -Analysis of the outliers, unanticipated values, problematic areas and hotspots Significant outliers for the following metrics: -cyclomatic complexity (for methods and class averages) -CBO (coupling between object classes) -NOC (number of derived children) -Function size in terms of LOC (lines of code) Code reviews -Error-proneness -Risks of unwanted side effects -Difficult to understand -Avoidance of potential maintenance problems

Slide 13 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Source Code Analysis Source code analysis -Folder structure and files: decomposition not reflected as it was documented -Empty files: a couple of empty (or almost empty) files were identified (less than 20 LOC) -Inconsistent naming conventions: not used consistently throughout the component -Ratio of commented lines to source code lines: below 10 percent Refactorings -Risk mitigation -Improvement of readability

Slide 14 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Conclusion Graphics component -Sufficient adequacy for the emerging product line -Need for renovations and extensions  Improvement of the internal quality  Assurance of consistency to the documentation and the intended design  Refactoring of variabilities  Removal of architectural mismatches and integration of the component Successful application of Fraunhofer PuLSE™ and ADORE™ -Well-invested effort in reverse engineering -Architectural reuse decision well-grounded on the reverse engineering Need for adaptation for single system components -In our experience so far, as-is reuse mostly does not work -Need for efficient and focused reverse engineering analyses to support the reuse decision making -Estimation the effort required

Slide 15 R2PL, Pittsburgh November 10, 2005 Copyright © Fraunhofer IESE 2005 Analyzing the Product Line Adequacy of Existing Components Discussion Points Did as-is reuse of existing components developed for single systems work for you product line? What are additional reverse engineering techniques suitable for analyses of the adequacy of a component? How do you evaluate the adequacy of components to be reused? How to analyze a component more efficiently? How to keep the effort for adaptation low?