r2pl, pittsburgh november 10, 2005 copyright © fraunhofer iese 2005 analyzing the product line...

R2PL, PittsburghNovember 10, 2005

Copyright © Fraunhofer IESE 2005

Analyzing the Product Line Adequacy of

Existing Components

Jens [email protected]

Dirk [email protected]



Analyzing the Product Line Adequacy of Existing Components

Outline

• Subject Component

• Architecture Development

• Reverse Engineering

• Discussion




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




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




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




Approach Business andorganizational goals

Functional andquality req.

Existingartifacts,

documents,systems, ...

Stakeholder analysisDefinition of

architectural views

(View-based)(Product Line)Architecture

Set upinfrastructure

Extraction(Basic-)

Analyses

ExtractionSpecialAnalyses

infrastructure-extension (optional)

Planning

Realization

Documentation

Ass

essm

ent

(optional

)

ArchitectureDevelopment

ReverseEngineering

ReverseEngineeringInformation

Request

Response

Business andorganizational goals

Functional andquality req.

Existingartifacts,

documents,systems, ...

Stakeholder analysisDefinition of

architectural views

(View-based)(Product Line)Architecture

Set upinfrastructure

Extraction(Basic-)

Analyses

ExtractionSpecialAnalyses

infrastructure-extension (optional)

Planning

Realization

Documentation

Ass

essm

ent

(optional

)

ArchitectureDevelopment

ReverseEngineering

ReverseEngineeringInformation

Request

Response




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




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




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?




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

1149- 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




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




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




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




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




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




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?

r2pl, pittsburgh november 10, 2005 copyright © fraunhofer iese 2005 analyzing the product line...

Documents

product line architectures

copyright fraunhofer

kloc slide

new components

external media slide

based development

development process

incremental development