Articles‎ > ‎

Comparison of reuse approaches in the software industry

posted Dec 25, 2016, 3:23 AM by Attila Nemeth   [ updated Dec 25, 2016, 3:30 AM ]
It is not always clear how Product Line Engineering fits into the world of reuse approaches commonly used throughout the software engineering landscape. Therefore in this article we take a look at different methodologies, evaluate their capabilities, their benefits and biggest challenges along the properties most important to systematic and efficient reuse. Following reuse approaches are investigated: Parametrization, Components, Clone and Own / Branching, Versioning, Frameworks, Domain Specific Languages and finally Product Line Engineering itself.

 
 Name: Parametrization
 Short Description: Configurable Parameters are used to changed / adapt control flow and behaviour of assets.
 Supported Granularity: Fine Grained
 Main Challenge: Parameter dependencies are usually not expressed explicitly in a fully formal, provable way. It is often complex to read parametrized code since it requires the reader to instantiate the code relevant for a specific variant manually on the fly (#ifdef, if (param == 12) ).
 Main Benefit: Performance (#ifdef), Dynamic Change (if (param == 12) ).
 Variation Scope: Structural (any granularity), Parametric
 Direct Link to Use of Assets: No
 Required Tool Support: Each tool must provide parametrization concept (control structures, preprocessor, … ).
 Explicit Evolution Support: No

 Name: Components
 Short Description: Components with well defined interfaces are composed into a system. Composition selects suitable components and connects them.
 Supported Granularity: Coarse Grained (Interface and/or Component level)
 Main Challenge: Modifying existing components must not break existing uses of the component. This often leads to interface bloat and related code bloat to support varying use cases. Makes components complex and hard to maintain and increase memory footprint. Often leads to components with versioned interfaces which then increase number of maintained assets and make composition process complex. Usually combined with internal parametrization for variation handling.
 Main Benefit:  Well defined interfaces decouple development and simplify testing. For stable components reuse is easy.
 Variation Scope: Structural (Component Level)
 Direct Link to Use of Assets: No
 Required Tool Support: Can be implemented by convention only (file system conventions) or with dedicated approaches such as AUTOSAR and suitable tools.
 Explicit Evolution Support: No

 Name: Clone and Own / Branching
 Short Description: A suitable asset is selected from a repository. It is copied / branched and modified to suit the changed requirements.
 Supported Granularity: Coarse Grained (Branchable / Copyable Asset, usually file level or above)
 Main Challenge: Since the copied/branched assets in most cases are not directly matching the minimal variation granularity, common code / information is duplicated. This creates increased mainteance effort. It also increases the total size of the to be considered assets for reuse, making selection and composition incrementally more complex over time. It also complicates reuse since merging of functionalities from different, independently evolved assets is often complex.
 Main Benefit: High decoupling of development paths, permits quick modifications without harming others.
 Variation Scope: Structural (Asset Level)
 Direct Link to Use of Assets: Yes
 Required Tool Support: File system conventions / Version Control System
 Explicit Evolution Support: Partially

 Name: Versioning
 Short Description: Changed assets are identified by version numbers. Systems are composed by selecting a valid combination of assets and version numbers to fit needs.
 Supported Granularity: Coarse Grained (Versionable asset, usually file or larger)
 Main Challenge: Version numbers do not contain information about the variation, they merely denote a variation. For selecting the right version extra information has to be used for selection. Since in principle each version of an asset can be reused, the number of assets to consider grows quickly. Usually this leads to adoption of a clone and own approach with constant reuse degradation and increased maintenance effort.
 Main Benefit: Decoupling of development paths, may permit quick modifications without harming others.
 Variation Scope: Structural (Component Level)
 Direct Link to Use of Assets: Yes
 Required Tool Support: Depending on the approach usually a version control system or similar (PLM, Component Repository)
 Explicit Evolution Support: Partially

 Name: Frameworks
 Short Description: A framework provides a defined set of services used by applications.
 Supported Granularity: Flexible
 Main Challenge: Required flexibility usually leads to complex configuration/parametrization framework. Performance & memory footprint is often not as good as in other approaches if framework is always deployed completely. Usually covers only architectural/implementation part, not requirements.
 Main Benefit: A framework is tested and released as whole. High reuse can be achieved if framework variation is kept minimal.
 Variation Scope: Parametric and Structural (Granularity framework dependent, usually framework level)
 Direct Link to Use of Assets: No
 Required Tool Support: Flexible, depending on framework
 Explicit Evolution Support: No

 Name: Domain Specific Languages
 Short Description: Domain specific languages constructed to provide application specific constructs like states and state transistions to abstract from "low level" general purpose programming languages. May include explicit variation point concept.
 Supported Granularity: Flexible (depends on DSL)
 Main Challenge: Requires investment and know-how in designing an suitable DSL and for maintenance of it. Usually covers only architectural/implementation part, not requirements.
 Main Benefit: Properly designed DSL reduce the size of the to be maintained assets and simplify understanding them. DSL may also include appropriate variation point concepts and can provide users with the necessary tools to deal with increased reuse complexity.
 Variation Scope: Any (Structural, Parametric, … depending on DSL)
 Direct Link to Use of Assets: No
 Required Tool Support: Usually DSL development tools and tools generated from DSL specification.
 Explicit Evolution Support: No

 Name: Product Line Engineering
 Short Description: Integrates reuse approaches into a holistic view by providing explicit notion of variants derived from reusable assets and connecting reuse concepts throughout the development using a uniform variation notation. It also covers the processes to handle the evolution of assets.
 Supported Granularity: Flexible
 Main Challenge: Collaboration is more complex. Higher coupling of activities on assets in reused parts. Possibly higher QA effort.
 Main Benefit: Leverages existing variation concepts in each domain, connects them. Usually reduces the size / amount of to be managed assets significantly. This reduces complexity and maintenance effort and increases reuse. Version management is simplified significantly.
 Variation Scope: Any (Structural, Parametric, … on any suitable level)
 Direct Link to Use of Assets: Yes
 Required Tool Support: No necessarily, but in most cases dedicated variant management tool to maintain variant information and uniform variability model is required
 Explicit Evolution Support: Yes

Comments