evolution and maintenance of software product lines 1 software maintenance and evolution evolution...

Evolution and maintenance of software product lines

1

Software maintenanceSoftware maintenance andand evolutionevolution

Evolution and maintenance of software Evolution and maintenance of software product linesproduct lines

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

Prof. Vytautas Štuikys

Kaunas University of Technology


2

Contents

• What is software product line (PL)?• PL development• PL evolution• PL evolution driving forces

– Porter’s Five Forces Model

• PL maintenance• Guidelines for PL evolution and maintenance

2


3

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

3

VariabilityVariability

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


4


5

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)

5

Product lineProduct 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


7

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

7


8

Contents

• What is software product line (PL)?• PL development• PL evolution• Porter’s Five Forces Model• PL maintenance• Guidelines for PL evolution and maintenance

8

PL engineeringPL engineering

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


9


10

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.

10

PL development (1)PL development (1)


11

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

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.


12

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

13

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

14


15

Contents


15


16

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

16


17

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

17


18

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

18


19

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

19


20

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

20


21

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

21


22

Anticipated vs. Unanticipated Evolution

22


23

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

23


24

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

24


25

Handling unforeseen (unanticipated) changes

25


26

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)

26


27

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

27

PL configuration management PL configuration management and evolution modeland evolution model


28

A Configuration Management Model for Software Product LineLiguo Yu and Srini Ramaswamy

PL configuration management PL configuration management and evolution modeland 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.


29


30

2D Evolution of Software Product

30Schach and Tomer


• 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


31


32


32


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


33


34

PL Evolution Tree

Shach and Tomer34


35

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

35


36


• 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

36


37


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

37


38

Implementing Evolution:“Evolve Each Asset” Pattern*

*Clements and Northrop

38


39

“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

39


40

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

40


41


• 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

41


42


• 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

42


43


• 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

43


44

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

44


45

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

45

PL evolution and comprehensionPL 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.


46


47

Contents


47

Essential PL activitiesEssential 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.


48

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


49

External Forces for Change:Porter’s Five Forces Model

49

Porter’s forcesPorter’s forces


50Chastek et al.

Production planning artefactsProduction 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


51


52

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

52

Production planningProduction 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


53


54

Contents


54

Benefits to maintenanceBenefits 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.


56

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

56


57

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

57


58

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

58


59

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

59


60

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.

60

evolution and maintenance of software product lines 1 software maintenance and evolution evolution...

Documents