24-08-2012, 03:55 PM
Development/Maintenance/Reuse: Software Evolution in Product Lines
[attachment=32652]
Abstract
The evolution tree model is a two-dimensional model that describes how the versions of
the artifacts of a software product evolve. The propagation graph is a data structure that can be
used for effective control of the evolution of the artifacts of a software product. In this paper we
extend the evolution tree model and propagation graph to handle the evolution of a software
product line.
Software product lines are characterized by large-scale reuse, especially of core assets.
We show how a third dimension can be added to the evolution tree model to handle this reuse.
In particular, the new model incorporates bidirectional reuse within product lines. That is, the
new model can handle the transfer of an artifact from the core assets repository to a specific
product (acquiring a core asset) as well as the transfer of a specific asset from a specific product
to the core assets repository (mining an existing asset).
Introduction
In classical software engineering, software construction consists of two activities performed
sequentially: development and maintenance. Starting from scratch, the software product is
developed and then installed on the client’s computer. Any change to the software after
installation, whether to fix a residual fault or extend the functionality, constitutes maintenance.
Thus, the way that software was developed classically can be described as the development-andthen-
maintenance model.
Nowadays, however, this model has proved to be impractical for two reasons. First, software
engineers usually have to cope with changing requirements and evolving technologies, the socalled
“moving target problem” [Schach, 1999]. To see how this affects the software life cycle,
suppose that the client’s requirements change while the design is being developed. The software
engineering team will have to suspend development and modify the specification document to
reflect the changed requirements. Furthermore, it may then be necessary to modify the design as
well if the changes to the specifications necessitate corresponding changes to those portions of
the design that have already been completed. Only when these changes have been made can
development proceed. In other words, developers frequently have to perform software
maintenance before the product is installed. In theory, such maintenance might have to be
performed just one day after the client’s original requirements were given to the software
engineering team, in contrast to the classical model of development-and-then-maintenance.
Software Maintenance with Propagation Graphs
The evolution tree model above describes the concept of software evolution. It also
symbolically depicts the various versions of the requirements, specification, design, and code. A
more detailed tool is required for controlling the changes in the product efficiently. One such tool
is the propagation graph [Schach and Tomer, 2000], a data structure that can be used to control a
maintenance-oriented software development process. The fundamental idea underlying a
propagation graph is that software artifacts implement requirements and in turn generate new
requirements. For example, a client’s requirement is implemented by one or more specification
artifacts. These specification artifacts in turn generate a new set of requirements, the
specification requirements. This is illustrated in Figure 2, which shows the propagation graph
for a specific case study described in [Schach and Tomer, 2000] using a simplified waterfall lifecycle
model. The figure shows how software can be modeled as alternating sets of requirements
and artifacts. Each set of artifacts satisfies the set of requirements above it and generates a new
set of requirements below it.
Evolution of a Software Product Line
We now extend the evolution tree model of Section 2 to express the evolution of an entire
software product line. A software product line is “a set of software-intensive systems sharing a
common, managed set of features that satisfy the specific needs of a particular market segment or
mission” [Clements and Northrop, 1999]. In practice, individual products are expected to evolve
more efficiently within the product line framework, mainly by reusing software artifacts
previously constructed during the evolution of other products in the product line. More
specifically, a set of reusable artifacts, denoted as core assets [Clements and Northrop, 1999] is
available for each of the products. Core assets may be obtained either by off-the-shelf acquisition
from external sources (e.g., software libraries, design patterns), by development within the
product line organization as generic building blocks, or by “mining” existing artifacts from
specific products. Irrespective of their source, core assets are usually stored in a core assets
repository and are maintained by a component-engineering group, external to any specific
product development group. Products in a product line are derived from a common domain
architecture, which is a core asset by itself.
Software Reuse in Product Lines
We now return to the propagation graph model and show how it can be applied to practical
reuse. There are two major questions concerned with reuse: First, is reusing a core asset more
effective than development of a new artifact (the development/acquisition decision [Clements
and Northrop, 1999])? Second, if an artifact is of a higher level of abstraction (e.g., a design
pattern), would it be effective to reuse it together with its descendents (e.g., a Java code
module)? In the following we will address these two questions by means of the propagation
graph model extended to a third dimension to incorporate the reuse inherent in product lines.
Conclusions and Future Work
In this paper we introduced a three-dimensional model that describes the evolution of
software product lines and outlined the means by which propagation graphs may be employed
for effective reuse purposes within the context of product lines.
The characteristics of propagation graphs and their associated requirement–implementation
subgraphs should be studied in detail and practical methods for using them should be developed.
We are currently building CASE tools to support the evolution tree and propagation graph
models. In this paper we have added a third dimension to the evolution tree to describe the reuse
inherent in software product lines. It will be necessary to extend those CASE tools to support
this new development.
[attachment=32652]
Abstract
The evolution tree model is a two-dimensional model that describes how the versions of
the artifacts of a software product evolve. The propagation graph is a data structure that can be
used for effective control of the evolution of the artifacts of a software product. In this paper we
extend the evolution tree model and propagation graph to handle the evolution of a software
product line.
Software product lines are characterized by large-scale reuse, especially of core assets.
We show how a third dimension can be added to the evolution tree model to handle this reuse.
In particular, the new model incorporates bidirectional reuse within product lines. That is, the
new model can handle the transfer of an artifact from the core assets repository to a specific
product (acquiring a core asset) as well as the transfer of a specific asset from a specific product
to the core assets repository (mining an existing asset).
Introduction
In classical software engineering, software construction consists of two activities performed
sequentially: development and maintenance. Starting from scratch, the software product is
developed and then installed on the client’s computer. Any change to the software after
installation, whether to fix a residual fault or extend the functionality, constitutes maintenance.
Thus, the way that software was developed classically can be described as the development-andthen-
maintenance model.
Nowadays, however, this model has proved to be impractical for two reasons. First, software
engineers usually have to cope with changing requirements and evolving technologies, the socalled
“moving target problem” [Schach, 1999]. To see how this affects the software life cycle,
suppose that the client’s requirements change while the design is being developed. The software
engineering team will have to suspend development and modify the specification document to
reflect the changed requirements. Furthermore, it may then be necessary to modify the design as
well if the changes to the specifications necessitate corresponding changes to those portions of
the design that have already been completed. Only when these changes have been made can
development proceed. In other words, developers frequently have to perform software
maintenance before the product is installed. In theory, such maintenance might have to be
performed just one day after the client’s original requirements were given to the software
engineering team, in contrast to the classical model of development-and-then-maintenance.
Software Maintenance with Propagation Graphs
The evolution tree model above describes the concept of software evolution. It also
symbolically depicts the various versions of the requirements, specification, design, and code. A
more detailed tool is required for controlling the changes in the product efficiently. One such tool
is the propagation graph [Schach and Tomer, 2000], a data structure that can be used to control a
maintenance-oriented software development process. The fundamental idea underlying a
propagation graph is that software artifacts implement requirements and in turn generate new
requirements. For example, a client’s requirement is implemented by one or more specification
artifacts. These specification artifacts in turn generate a new set of requirements, the
specification requirements. This is illustrated in Figure 2, which shows the propagation graph
for a specific case study described in [Schach and Tomer, 2000] using a simplified waterfall lifecycle
model. The figure shows how software can be modeled as alternating sets of requirements
and artifacts. Each set of artifacts satisfies the set of requirements above it and generates a new
set of requirements below it.
Evolution of a Software Product Line
We now extend the evolution tree model of Section 2 to express the evolution of an entire
software product line. A software product line is “a set of software-intensive systems sharing a
common, managed set of features that satisfy the specific needs of a particular market segment or
mission” [Clements and Northrop, 1999]. In practice, individual products are expected to evolve
more efficiently within the product line framework, mainly by reusing software artifacts
previously constructed during the evolution of other products in the product line. More
specifically, a set of reusable artifacts, denoted as core assets [Clements and Northrop, 1999] is
available for each of the products. Core assets may be obtained either by off-the-shelf acquisition
from external sources (e.g., software libraries, design patterns), by development within the
product line organization as generic building blocks, or by “mining” existing artifacts from
specific products. Irrespective of their source, core assets are usually stored in a core assets
repository and are maintained by a component-engineering group, external to any specific
product development group. Products in a product line are derived from a common domain
architecture, which is a core asset by itself.
Software Reuse in Product Lines
We now return to the propagation graph model and show how it can be applied to practical
reuse. There are two major questions concerned with reuse: First, is reusing a core asset more
effective than development of a new artifact (the development/acquisition decision [Clements
and Northrop, 1999])? Second, if an artifact is of a higher level of abstraction (e.g., a design
pattern), would it be effective to reuse it together with its descendents (e.g., a Java code
module)? In the following we will address these two questions by means of the propagation
graph model extended to a third dimension to incorporate the reuse inherent in product lines.
Conclusions and Future Work
In this paper we introduced a three-dimensional model that describes the evolution of
software product lines and outlined the means by which propagation graphs may be employed
for effective reuse purposes within the context of product lines.
The characteristics of propagation graphs and their associated requirement–implementation
subgraphs should be studied in detail and practical methods for using them should be developed.
We are currently building CASE tools to support the evolution tree and propagation graph
models. In this paper we have added a third dimension to the evolution tree to describe the reuse
inherent in software product lines. It will be necessary to extend those CASE tools to support
this new development.