Software maintenance and evolution evolution and maintenance of software product lines
This presentation is the property of its rightful owner.
Sponsored Links
1 / 60

Software maintenance and evolution Evolution and maintenance of software product lines PowerPoint PPT Presentation


  • 88 Views
  • Uploaded on
  • Presentation posted in: General

Software maintenance and evolution Evolution and maintenance of software product lines. Prof. Robertas Dama š evi č ius , robertas.damasevicius @ktu.lt Prof. Vytautas Štuikys Kaunas University of Technology. Contents. What is software product line (PL)? PL development PL evolution

Download Presentation

Software maintenance and evolution Evolution and maintenance of software product lines

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Software maintenance and evolution evolution and maintenance of software product lines

Software maintenanceandevolutionEvolution and maintenance of software product lines

Prof. Robertas Damaševičius,[email protected]

Prof. Vytautas Štuikys

Kaunas University of Technology

Evolution and maintenance of software product lines


Contents

Contents

  • What is software product line (PL)?

  • PL development

  • PL evolution

  • PL evolution driving forces

    • Porter’sFiveForcesModel

  • PL maintenance

  • Guidelines for PL evolution and maintenance

Evolution and maintenance of software product lines

2


Definitions

Definitions

  • Software Product Line (PL): a collection of similar software systems created from a shared set of software assets using a common means of production

  • Product Line asset: any kind of asset that captures information about PL and its development process

  • Core asset: a reusable artifact or resource that is used in the production of more than one product in a software PL

    • an architecture, a software component, a domain model, a requirements statement or specification, a document, a plan, a test case, a process description, or any other useful element of a software production process

  • Product Line evolution: accumulated PL change over time

Evolution and maintenance of software product lines

3


Variability

Variability

  • Ability of a system to be efficiently extended, changed, customized or configured for use in a particular context.

  • Ability of a system, an asset, or a development environment to support the production of a set of artifacts that differ from each other in a preplanned fashion

  • Ability of a core asset to adapt to usages in the different product contexts that are within the product line scope.

  • When a core asset is created, the common part is produced, which will not change as the core asset is used from product to product.

  • A variable part is the position in an asset where a variation can took place

  • The realization of a variable part is called a variant.

Evolution and maintenance of software product lines


Product line

Product line

  • "A software product line is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way" (Clements & Northrop, 2001)

Evolution and maintenance of software product lines

5


Product line1

Product line

  • Companies today do not develop individual products, rather, they develop product lines - families of manufactured products, that need to be customized for a variety of physical devices, protocols, environments, and languages

  • To cover product line, companies need to use components from multiple suppliers, who offer feature-specific services

  • This leads to a product line with alternative components

  • Product line becomes a first-order entity of development

Source: www.biglever.com


Motivation for product lines

Motivation for product lines

  • Suppose a software system S evolves into a family (“line”) of similar systems released to various customers over time

  • 1. Each system release may implement:

    • a. Common features shared by all releases of S.

    • b. Variant features shared with some other releases

    • c. Some unique features

  • 2. Feature implementation may vary across system releases.

  • 3. Each release should contain only features that its customers wish to have. This may be important for:

    • a. Reliability reasons

    • b. Strict time performance or memory consumption requirements, for example, in embedded system software, mobile device applications, etc.

    • c. Large packages such as that need to be tailored for different operating environments

Evolution and maintenance of software product lines

7


Contents1

Contents

  • What is software product line (PL)?

  • PL development

  • PL evolution

  • Porter’sFiveForcesModel

  • PL maintenance

  • Guidelines for PL evolution and maintenance

Evolution and maintenance of software product lines

8


Pl engineering

PL engineering

  • Software PL engineering allows the shifting of the focus of development and evolution from the individual products to the PL

Evolution and maintenance of software product lines


Reusable pl assets

Reusable PL assets

  • Normal software components

  • Training specific to product line

  • Business case for the use of a product line for a set of products,

  • Set of identified risks for building products for product line,

  • Etc.

Evolution and maintenance of software product lines

10


Pl development 1

PL development (1)

Sami OUALI, Naoufel KRAIEM, Henda BEN GHEZALA. Framework for Evolving Software Product Line.

International Journal of Software Engineering & Applications (IJSEA), Vol.2, No.2, April 2011

Evolution and maintenance of software product lines


Pl development 2

PL development (2)

  • In software product line development context, the purpose is to develop not only a single product but several more or less distinct products

  • These products are developed together.

  • Information captured in the development artifacts concerns all the product of the software product line and not only each product separately.

Evolution and maintenance of software product lines


Reuse in pl 1

Reuse in PL (1)

  • Let A be an artifact and A' be the same artifact after modification, A' = modify (A).

  • Let another artifact B be an exact copy of A, denoted by B = copy (A).

  • Let C denote a core asset and let P denote an artifact of a product.

  • (a) P = modify (copy (C))

    • This is the case where a core asset is acquired by the product and is then modified to produce a specific artifact. It is a classical scenario of reusing a core asset as a baseline for a specific artifact.

    • Example: C is a design pattern and P is a specific design based on the pattern

  • (b) P = copy (modify (C))

    • This is the case where a core asset is modified before being acquired by the product. This scenario usually occurs when several products require a modified version of the core asset at the same time.

    • Example: component engineering group develops a specific design pattern and then copies of that pattern are released for acquisition.

Evolution and maintenan ce of software product lines


Reuse in pl 2

Reuse in PL (2)

  • (c) C = modify (copy (P))

    • This is the case where a specific product’s artifact is mined but needs to undergo modifications before becoming a core asset.

    • Example: establishing an initial core assets repository from specific existing products, consistent with a standard architecture.

  • (d) C = copy (modify (P))

    • This is the case where a specific product’s artifact undergoes modifications before being mined as a core asset. This is the least likely scenario for reuse, because the core assets plane is not expected to “record” modifications performed within specific products.

    • Example: component engineering group notices that the product has upgraded an artifact which was previously mined as a core asset.

Evolution and maintenan ce of software product lines


Contents2

Contents

  • What is software product line (PL)?

  • PL development

  • PL evolution

  • Porter’sFiveForcesModel

  • PL maintenance

  • Guidelines for PL evolution and maintenance

Evolution and maintenance of software product lines

15


Software evolution

Software evolution

  • Evolution is the accumulated effects of change over time

  • Forces drive the change in a certain direction at a certain point in time, and whether those forces are anticipated or controlled is uncertain

  • Direction of that change may or may not be desirable

  • Evolution is a challenge for a product line organization

  • Complex relationships among those assets, and between those assets and the products they are part of, magnify the effects of evolution

Evolution and maintenance of software product lines

16


Product line change

Product line change

  • Product line assets change over time

    • in response to a specific stimulus such as the need to meet a new standard or to address an emerging market niche

      • effects of change can be anticipated and directed

    • assets are changed for reasons specific to the asset such as removing defects or achieving consistency with other assets

      • effects may not be recognized until changes have accumulated

Evolution and maintenance of software product lines

17


Asset evolution

Asset evolution

  • Asset evolution happens in response to forces both outside and within PL organization:

    • A new release of a standard, which is integral to the products, forces changes in core assets and directs evolution toward compliance with the standard

      • Such a release can be anticipated, its impact can be analyzed, and resulting changes can be managed

    • Adopting new technologies forces assets to change.

      • This may be part of a continuous evolution as a technology matures, or a radical change if a disruptive technology emerges and forces a major change in direction

    • A change in marketing strategy

      • Can be an internal evolutionary force that directs evolution toward higher performance or more features

Evolution and maintenance of software product lines

18


Asset evolution problems

Asset evolution problems

  • Asset evolution can cause problems with the core asset base and with product production

  • Certain dependencies among assets must be maintained

  • If two related assets evolve in different directions, the consistency of the core asset base is threatened

  • Conflicting goals can lead to conflicting changes that cause erosion of the core asset base’s integrity

  • To avoid such erosion, a change to any core asset must be analyzed in advance to determine its impact on related assets

  • An evolution plan is developed that balances the forces of potentially inconsistent changes

Evolution and maintenance of software product lines

19


Phenotypic asset change

Phenotypic asset change

  • Not every change to an asset should be considered evolutionary

  • A phenotypic change typically affects a single product.

  • Defect repair does not move an asset in a specific direction; it simply moves the single asset to where it was assumed to be all along

  • When a supplier discontinues a component, selecting an exact replacement from a different company does not evolve the PL or individual products in any direction

  • It simply allows those products in the product line that use the component to maintain their current position

Evolution and maintenance of software product lines

20


Software pl evolution problems

Software PL evolution problems

  • Evolution of a single asset can affect many other assets and multiple products

  • Many relationships exist among product line assets

  • Creating a product involves the use of many assets, some of which might be derivations of other assets

  • One asset might constrain the design or structure of another

  • Changes made to one asset are propagated to other assets

Evolution and maintenance of software product lines

21


Anticipated vs unanticipated evolution

Anticipated vs. Unanticipated Evolution

Evolution and maintenance of software product lines

22


Anticipated evolution

Anticipated evolution

  • Three software product line practice areas are primary influences on the mitigation of anticipated evolution:

    • Technology Forecasting enhances the possibility that any evolution will be anticipated and proactively searches for changes related to advances in technologies used to implement the product line

    • Understanding Relevant Domains provides an understanding of which features are most likely to change

    • Market Analysis provides an understanding of which existing products will become obsolete and which new products are likely to be successful

Evolution and maintenance of software product lines

23


Unanticipated evolution

Unanticipated evolution

  • External events to the product line organization lead to unanticipated evolution:

    • Political decisions made by organizational and technical managers lead to unpredictable changes and unanticipated evolution

    • Business cycles can be predicted, but the effects of their changes cannot always be

    • Technology cycles do not always run their course. In some cases, disruptive technologies gain rapid, widespread acceptance forcing unanticipated changes in products

Evolution and maintenance of software product lines

24


Handling unforeseen unanticipated changes

Handling unforeseen (unanticipated) changes

Evolution and maintenance of software product lines

25


Evolutionary life cycle of product line

Evolutionary Life Cycle of Product Line

  • All assets evolve, not just the software assets.

  • Dependencies among PL assets provide pathways for propagation of evolutionary forces

    (According to Svahnberg and Bosch)

Evolution and maintenance of software product lines

26


Categories of pl architecture evolution

Categories of PL Architecture Evolution

  • Split of the product line architecture

  • Derivation of a new PL architecture from an existing one

  • Development of new PL components

  • Change of PL components

  • Replacement of a PL component

  • Split of a PL component

  • New relationship between PL components

  • Changed relationship between PL components

Evolution and maintenance of software product lines

27


Pl configuration management and evolution model

PL configuration management and evolution model

A Configuration Management Model for Software Product Line

Liguo Yu and Srini Ramaswamy

Evolution and maintenance of software product lines


Pl configuration management and evolution model1

PL configuration management and evolution model

  • Separation of responsibilities

  • The configuration management of software product line is divided into two domains, the production domain and the product domain.

  • Production domain manages the evolution of components, assets (core assets and custom assets), and core instances.

  • Product domain determine the evolution of custom parts of a product.

Evolution and maintenance of software product lines


2d evolution of software product

2D Evolution of Software Product

Schach and Tomer

Evolution and maintenance of software product lines

30


2d evolution of software product1

2D Evolution of Software Product

  • Development axis, along which versions are developed;

  • Maintenance axis, along which artifacts are modified

  • φ - the initial (empty) artifact, prior to any development action

  • Ri, Si, Di, and Ci - versions of requirements, specification, design and code

Evolution and maintenance of software product lines


3d evolution of software product

3D Evolution of Software Product

Evolution and maintenance of software product lines

32


3d evolution of software product1

3D Evolution of Software Product

  • Reuse introduces additional dimension (axis)

  • How core assets, can be constructed, or acquired, independently of each other

  • Acquiring a core asset: core assets are transferred to specific products

  • Mining an existing asset: specific artifacts may become core assets.

Evolution and maintenance of software product lines


Pl evolution tree

PL Evolution Tree

Evolution and maintenance of software product lines

34

Shach and Tomer


Risks of pl evolution 1

Risks of PL Evolution (1)

  • Consistency

    • Threat: as changes accumulate, related assets might be changed in different directions and no longer be compatible

    • Mitigation: planning for evolution by specifying its direction and designing defensively. An evolution plan should be then created for each related asset. If a constraint prevents a consistent change to a related asset, the process must be rolled back so that an alternative can be tried

Evolution and maintenance of software product lines

35


Risks of pl evolution 2

Risks of PL Evolution (2)

  • Completeness

    • Threat: given changes to a large number of assets, an association could potentially be lost or rerouted during evolution, resulting in an asset being omitted from a configuration and blocked from further changes

    • Mitigation: periodical inspection of the output of a change process and comparison with the input. Results should be specified clearly in the evolution plan

Evolution and maintenance of software product lines

36


Risks of pl evolution 3

Risks of PL Evolution (3)

  • Correctness

    • Threat: changing an asset might introduce a defect into it

    • Mitigation: specifying the direction of evolution to include a design for the change. Changes to assets should undergo the same inspection as the original asset.

Evolution and maintenance of software product lines

37


Implementing evolution evolve each asset pattern

Implementing Evolution:“Evolve Each Asset” Pattern*

*Clements and Northrop

Evolution and maintenance of software product lines

38


Evolve each asset

“Evolve Each Asset”

  • “Technical Planning” provides skills and techniques needed to develop a work breakdown structure to scope and estimate the work

  • “Data Collection, Metrics, and Tracking” provides the data, techniques, and algorithms that support the estimation and tracking of progress against the plan

  • Product Asset (PA)data used to evaluate the quality of evolution

  • Tools used to build an asset would also be used to evolve it

  • “Process Definition” is required if the asset’s evolution causes a change in the technology behind the asset, and a new process for the evolved asset is needed

  • The evolved asset is placed under configuration management, and made available

Evolution and maintenance of software product lines

39


Evolution process 1

Evolution process (1)

  • Initiate Evolution

    • Architecture evaluation initiates the evolution of requirements, architecture, or components

    • System-level inspections and tests initiate the evolution of architecture or components

    • Unit and integration tests typically initiate evolution only in the components

    • User feedback initiates evolution in a product, particularly its requirements

    • Feedback from product builder to core asset builder can initiate the evolution of any core asset

Evolution and maintenance of software product lines

40


Evolution process 2

Evolution process (2)

  • Develop an Evolution Plan

    • Feedback is analyzed to determine whether there should be several independent changes or just one coordinated attack.

    • For each change, the primary asset to be evolved is identified.

    • A change impact analysis is conducted to scope the evolution effort.

    • Maintenance metrics are used to evaluate required effort.

    • Plan is developed for the evolution

Evolution and maintenance of software product lines

41


Evolution process 3

Evolution process (3)

  • Apply Transformations

    • Evolution plan identifies the transformations that will be used to modify each asset

    • Applying transformations to one asset might lead to the transformation of others identified during change impact analysis

    • Examples:

      • Refactoring: module structure of software assets is changed by reallocating and regrouping behaviour found in other structures

      • Reconfiguration: changing the objects that implement the asset

      • Customization: changing existing assets to satisfy new requirements that are related to existing ones

      • Model Transformations

Evolution and maintenance of software product lines

42


Evolution process 4

Evolution process (4)

  • Accept the Evolved Assets

    • The evolution plan defines the testing activities that determine whether the newly modified asset is consistent with the other core assets.

    • The evolution plan might call for the immediate update of several existing configurations (e.g., if defect repairs are needed), or the asset might be incorporated in a new configuration (e.g., in a new version of the product or through its use by another asset)

    • Configuration controls is used to manage configurations

Evolution and maintenance of software product lines

43


Change impact analysis

Change Impact Analysis

  • Change impact analysis provides a means of predicting which assets will be affected by a specific change before the change is made

  • Using that analysis, the analyst can determine whether the benefit from the change is worth the effort required to make it

  • Involves

    • conducting a traceability analysis to identify impacted places

    • identifying the interactions affected by the change

    • evaluating the effect of changes on assumptions

    • identifying new constraints

    • identifying regression tests

Evolution and maintenance of software product lines

44


Parts of software w r t evolution

Parts of Software w.r.t. Evolution

  • Evolution-critical parts — parts of the design or software that need to be evolved because of existing problems

  • Evolution-prone parts — parts of the design or software that are likely to evolve because the corresponding requirements are likely to change

  • Evolution-sensitive parts — parts of the design or software that will be expensive to evolve

    • E.g. depth metric in OO software identifies classes that are near or at the top of inheritance hierarchies. The higher the class is, the higher the number of dependencies and the bigger the change impact will be if the class is chosen for evolution

Evolution and maintenance of software product lines

45


Pl evolution and comprehension

PL evolution and comprehension

  • Successful evolution of SPLs requires comprehension of the impact change.

  • If a product has a (security) bug, it is necessary to identify all products (deployed and under development) that are affected.

  • If a feature is added or removed it is necessary to assess the impact on all products, e.g., to determine if an already deployed product can be maintained using the current product line or if an older version of the product line needs to be used.

  • Only, if all changes can be traced and reasoned about it is possible to determine how a changed requirement affects the products.

Evolution and maintenance of software product lines


Contents3

Contents

  • What is software product line (PL)?

  • PL development

  • PL evolution

  • Porter’sFiveForcesModel

  • PL maintenance

  • Guidelines for PL evolution and maintenance

Evolution and maintenance of software product lines

47


Essential pl activities

Essential PL activities

  • Activities are all essential, inextricably linked, and highly iterative, and can occur in any order.

  • Strong feedback loop between the core assets and the products.

    • Core assets are developed or procured for later use in the production of products.

    • Existing products may be mined for generic assets which are then migrated into the product line's core asset base.

    • Product development may lead to revisions of existing core assets or new core assets

  • Management to control resources in the development and sustainment of the core assets.

    • New products must align with the existing core assets,

    • Core assets must be updated to reflect the new products that are being marketed.

SEI, A Framework for Software Product Line Practice, Version 5.0.

Evolution and maintenance of software product lines


External forces for change porter s five forces model

External Forces for Change:Porter’s Five Forces Model

Evolution and maintenance of software product lines

49


Porter s forces

Porter’s forces

Chastek et al.

Evolution and maintenance of software product lines


Production planning artefacts

Production planning artefacts

  • How a software product line organization builds its products is a system?

  • Production system has both

  • functionality (e.g., the development tools employed) and

  • quality attributes (e.g., how quickly a specified product can be delivered).

  • Production planning devises a production system that

    • Satisfies the organization’s goals and constraints for its product line;

    • Coordinates the design of the core assets with the production system;

    • Communicates the effective use of the production system to the product developers

Evolution and maintenance of software product lines


External forces for change

External Forces for Change

  • Potential entrants into the market might force a change in the fundamental business strategies of the organization. Such a change might cause changes in product line strategy, architecture and related assets

  • Industry competitors might force a change in assets by leading efforts to change domain standards or by introducing a disruptive technology into a previously stable market

  • Substitutes for products of the product line might force change by adopting new techniques that allow the substitutes to be offered at reduced prices or delivered more quickly

  • Buyers might force change by demanding the latest technology in the products they buy

  • Suppliers might force change by discontinuing or evolving the assets they provide to the product line

Evolution and maintenance of software product lines

52


Production planning

Production planning

  • Production strategy: determines how product development satisfies the organization’s goals for the PL and integrates the goals, policies, and actions of the PL organization for product production.

  • Production method: determines what processes, models, and technologies can be used to ensure consistency and the necessary variation across the core assets based on the production strategy.

  • Provides required coordination of the core assets and product development activities to assure efficient interaction of PL activities (core asset development, product building, and management)

  • Production plan: that describes what the product developers need to know to effectively use the core assets to develop products with predictable results

Evolution and maintenance of software product lines


Contents4

Contents

  • What is software product line (PL)?

  • PL development

  • PL evolution

  • Porter’sFiveForcesModel

  • PL maintenance

  • Guidelines for PL evolution and maintenance

Evolution and maintenance of software product lines

54


Benefits to maintenance

Benefits to maintenance

  • Increased product diversity and the scale of different products that can be effectively delivered in a PL

  • Reduction of per-product development cost and overhead – and higher profit margins.

  • Reduction in time-to-market for new and updated products, and an increased agility to react to new opportunities and changing marketplace conditions.

  • Increase in product quality, a reduction in defect density and improved risk management.


Guidelines for pl evolution 1

Guidelines for PL Evolution (1)

1. Avoid adjusting component interfaces

  • Sooner or later the interfaces of components will need to be changed because a new implementation requires more of the interface than was planned from the beginning

    2. Focus on making component interfaces general

  • The prevalent form of evolution is that of adding new implementations to the existing components and thus increase the set of supported standards

    3. Separate domain and application behavior

  • Aggregate relationships should be used as the only connector between the two

    4. Keep the software product line intact

  • Develop one product line per type of product

Evolution and maintenance of software product lines

56


Guidelines for pl evolution 2

Guidelines for PL Evolution (2)

5. Detect and exploit common functionality in component implementations

  • Every domain component should have at least one library component in its tow, where common functionality between component implementations can be placed as soon as it is identified as shared between implementations

    6. Be open to rewriting components and implementations

  • Rather than forcing the change into the component, which results in a patchy code and shortens its life, the option to rewrite the component from scratch should be considered

    7. Avoid hidden assumptions and design decisions in the source code

  • Some design decisions do not take on a first class representation in the architecture, and becomes hidden in the source code

Evolution and maintenance of software product lines

57


Summary knowledge acquired 1

Summary: knowledge acquired (1)

  • All PL assets will evolve over time, because:

    • Users want more features or the latest technology for existing features

    • People learn new skills or improve the ones they already possess

    • New standards are developed and existing standards are upgraded

    • Vendors phase out products and offer new ones

  • Basic techniques for managing product line evolution are

    • Anticipation: by analyzing market trends and technology changes

    • Direction: provides a means for managing the consistency of assets

Evolution and maintenance of software product lines

58


Summary knowledge acquired 2

Summary: knowledge acquired (2)

  • Evolution techniques such as change impact analysis allow to make decisions about which changes to allow.

  • Risks resulting from evolution relate to losing the consistency, completeness, and correctness of the PL asset base

  • Anticipation and control of evolution reduces the likelihood of the risks becoming a problem

  • Applying evolution transformations reduces the impact that those problems can have on the asset base

Evolution and maintenance of software product lines

59


References

References

  • J.D. McGregor. The Evolution of Product Line Assets.CMU/SEI-2003-TR-005, June 2003.

  • P. Clements, L. Northrop. Software Product Lines: Practices and Patterns. Addison-Wesley, 2002.

  • M. Svahnberg, J. Bosch. Evolution in Software Product Lines: Two Cases. Journal of Software Maintenance 11, 6 (1999), 391-422.

  • M. Pussinen A survey on software product-line evolution. Rep. 32, Institute of Software Systems, Tampere University of Technology, 2002, 51 pp.

  • S.R. Schach, A. Tomer. Development/ Maintenance/ Reuse: Software Evolution in Product Lines. In Software Product Lines Experience and Research Directions. Proc. of the 1st Software Product Lines Conf., pp. 437-450. Kluwer Academic Publishers, 2000.

  • Gary J. Chastek, John D. McGregor: Modeling Variation in Production Planning Artifacts. VaMoS 2009: 45-50.

  • Chastek, G.J.; Donohoe, P.; McGregor, J.D., "Formulation of a Production Strategy for a Software Product Line“ (2009). SEI. Paper 31.

Evolution and maintenance of software product lines

60


  • Login