Evolution and maintenance of software product lines 1 Software maintenance and evolution Evolution...
-
Upload
kerry-matthews -
Category
Documents
-
view
231 -
download
2
Transcript of 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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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.
Evolution and maintenance of software product lines
4
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
9
Evolution and maintenance of software product lines
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)
Evolution and maintenance of software product lines
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.
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
15
Contents
• What is software product line (PL)?• PL development• PL evolution• Porter’s Five Forces Model• PL maintenance• Guidelines for PL evolution and maintenance
15
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
25
Handling unforeseen (unanticipated) changes
25
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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.
Evolution and maintenance of software product lines
29
Evolution and maintenance of software product lines
30
2D Evolution of Software Product
30Schach and Tomer
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
31
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
33
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
36
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
36
Evolution and maintenance of software product lines
37
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.
37
Evolution and maintenance of software product lines
38
Implementing Evolution:“Evolve Each Asset” Pattern*
*Clements and Northrop
38
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
41
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
41
Evolution and maintenance of software product lines
42
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
42
Evolution and maintenance of software product lines
43
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
43
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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.
Evolution and maintenance of software product lines
46
Evolution and maintenance of software product lines
47
Contents
• What is software product line (PL)?• PL development• PL evolution• Porter’s Five Forces Model• PL maintenance• Guidelines for PL evolution and maintenance
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.
Evolution and maintenance of software product lines
48
SEI, A Framework for Software Product Line Practice, Version 5.0.
Evolution and maintenance of software product lines
49
External Forces for Change:Porter’s Five Forces Model
49
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
Evolution and maintenance of software product lines
51
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
53
Evolution and maintenance of software product lines
54
Contents
• What is software product line (PL)?• PL development• PL evolution• Porter’s Five Forces Model• PL maintenance• Guidelines for PL evolution and maintenance
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.
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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
Evolution and maintenance of software product lines
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