Evolving Software Requirements and Architectures

using Software Product Line Concepts

Hassan Gomaa
Department of Computer Science
George Mason University
Fairfax, VA, USA
[email protected]

Abstract—This paper proposes an evolutionary development how feature modeling can be used to characterize variability
approach, which uses software product line and feature due to requirements evolution and its impact on architecture
modeling concepts for evolving software requirements and evolution. The approach extends the PLUS UML-based SPL
architectures. The different versions of an evolutionary system design method [3] to address evolutionary feature-based use
are considered a software product line, with each version of the
system a product line member. Requirements are modeled using
case modeling and software architectural design. Being feature
both use case and feature modeling. Evolution is built into the based, the approach closely relates the evolution of the
software development approach because variability in the software architecture to the evolution of software requirements.
software architecture is determined by considering the impact of
each variable feature on the software architecture and evolving II. MODEL-BASED EVOLUTION
the architecture to address new features. Being feature based, the In model-based software design and development, software
approach closely relates the evolution of the software architecture modeling is used as an essential part of the software
to the evolution of software requirements, as well as providing development process. A better understanding of a system or
traceability between requirements and architecture.
product line can be obtained by considering the multiple views
Index Terms—software evolution, software requirements, [7], such as requirements models, static models, and dynamic
feature modeling, software product lines, software architecture models of the system or product line. A key view in the
multiple views of a software product line is the feature
I. INTRODUCTION modeling view [5]. The feature model is crucial for managing
variability and product derivation as it describes the product
The Twin Peaks model [1] advocates intertwining software line requirements in terms of commonality and variability.
requirements and architectures for incremental development. The different versions of a system as it evolves can be
To address these issues, this paper proposes an incremental considered a product line, with each version of the system a
and evolutionary development approach, which uses software member of the product line [6]. In order to keep track of system
product line (SPL) [2,3,4] and feature modeling [5] concepts evolution, it is necessary to explicitly model the different
to incrementally evolve software requirements and features of the system as it evolves, and use the feature model
architectures. In typical SPL development, a feature model, to differentiate among the different versions of the system.
which captures the commonality and variability in software
requirements, and domain architecture are created for the SPL, III. EVOLUTIONARY SOFTWARE DEVELOPMENT
from which applications are derived and deployed. However, The Evolutionary Process Model for SPL engineering
for evolutionary systems and product lines, it is necessary to used in the PLUS method [3] consists of two highly iterative
progress beyond a static feature model and domain main processes (Fig. 1):
architecture to address evolving the feature model in a) Domain Engineering. A domain (SPL) multiple-view
conjunction with the domain architecture. model is developed. The domain requirements (feature and
The different versions of an evolving system constitute use case models) and analysis (static and dynamic)
a family of systems with some common functionality and models, domain architecture, and reusable components are
some variable functionality, a property they share with developed and stored in the SPL reuse library.
software product lines. Feature modeling is widely used to b) Application Engineering. A software application
characterize SPL variability prior to application derivation and (individual SPL member) multiple-view model is derived from
deployment. With the approach described in this paper, the the domain multiple-view model. The user selects the required
goal is to model all versions of an evolving system, in features for the application. Given these features, the domain
particular the evolving requirements and architecture using models and architecture are tailored to derive the application
SPL concepts. feature model and architecture. The architecture determines
Software requirements are determined using both use which reusable components are needed for the application.
case and feature modeling. A feature is a reusable SPL
requirement or characteristic. The emphasis of this paper is on

978-1-4673-6439-3/13/$31.00 c 2013 IEEE 24 TwinPeaks 2013, San Francisco, CA, USA

 Consider an example of feature evolution. A basic
microwave oven system is to evolve by adding some new
features, as depicted in Fig. 2 using the UML meta-class
notation with stereotypes depicting features and feature groups
[3]. Using SPL concepts, the original system and evolved
system are both members of the SPL. Features provided by
both systems are considered common features, while features
representing evolving requirements are variable features. The
feature variability could be either optional or alternative
features. In the evolutionary microwave oven example,
evolution involves adding a Light feature (light is present or
not) and a Beeper feature (beep when cooking is finished) to a
basic microwave oven. Both features are categorized as
optional features from an SPL perspective (Fig. 2), because
they only exist in the evolved system. Two other features are
Fig. 1: Evolutionary SPL process model added, a multi-line display in place of the original one-line
display and a multi-level heating element (high, medium, low)
The common features and kernel software architecture instead of a one-level heating element feature. For these latter
represent the commonality of the SPL. Evolution is built into two cases, the features are categorized as alternative features
the software development approach because the variability in (Fig. 2), since in each case a choice has to be made, e.g.,
the software architecture is developed by considering the between the one-line display and the multi-line display. One of
impact of each variable feature on the software architecture the alternative features can be chosen as the default feature.
and evolving the architecture to address the feature. From a feature modeling perspective, the initial version of the
The addition of optional and alternative features microwave oven system evolves with the One Line Display
necessitates the evolution of the original kernel software feature evolving from a common feature to a default feature in
architecture by designing optional and variant components to a new Display Unit feature group, in which the alternative
realize these features. The rest of the paper describes how Multi Line display feature is added (Fig. 2). The feature group
feature dependent evolution can be used to systematically is an exactly-one-of feature group consisting of two mutually
incorporate optional and variant components into an exclusive features, one of which must always be selected for a
evolutionary component-based software architecture. system.
«optional requires «common
«optional
IV. EVOLUTIONARY FEATURE MODELING feature» feature»
Microwave
requires
feature»
Light Beeper
«exactly-one- Oven Kernel
Feature modeling is an important concept in software product of feature
group»
line engineering [5]. Features are analyzed and categorized Display
requires requires «exactly-one-
of feature
Unit
as common features (must be supported in all product line {mutually
group»
Heating
exclusive
members), optional features (only required in some product feature}
Element
{mutually exclusive
line members), alternative features (a choice of feature is «alternative «default
feature}

available) and prerequisite features (dependent upon other feature»

Multi-line
feature»
One-line «default «alternative
feature» feature»
features). There may also be dependencies among features, Display Display
One-level Multi-level
Heating Heating
such as mutually exclusive features. The emphasis in feature mutually
includes

modeling is capturing SPL variability, since these features «optional

feature»
differentiate one member of the family from the others. TOD
Clock
Features are incorporated into UML using meta-classes Fig. 2: Feature Model for Evolutionary System
(Fig. 2) and given stereotypes to differentiate between
«common feature», «optional feature» and «alternative feature» V. EVOLUTIONARY USE CASE MODELING
[3,7]. Furthermore, feature groups, which place a constraint on The functional requirements of a system are defined in
how certain features can be selected for a SPL member, such as terms of use cases and actors. For a single system, all use cases
mutually exclusive features, are also modeled using meta- are required. In a software product line, only some of the use
classes and given stereotypes, e.g., «zero-or-one-of feature cases, which are referred to as kernel use cases, are required by
group» or «exactly-one-of feature group» [3,7]. all members of the family. Other use cases are optional, in that
Feature modeling can be used to differentiate among the they are required by some but not all members of the family.
changes to the software system as it evolves through different Some use cases may be alternative, that is different versions of
versions. Thus each version of the system can be described by the use case are required by different members of the family.
means of the features it provides. However, during evolution In UML, the use cases are labeled with the stereotype «kernel»,
the reuse property of a feature can change. Thus, what «optional» or «alternative» [3]. Variability can also be inserted
constitutes a common feature in the first version of the system into a use case through variation points that specify locations in
might evolve into an optional or alternative feature in a the use case where variability can be introduced [3,8,9].
subsequent version of the system.

25
 Whereas feature modeling is effective at differentiating
between commonality and variability, use case modeling
provides a behavioral view on software functionality by
describing the sequence of interactions between the actor(s) and
the system. This behavioral view is used to determine where the
evolutionary changes need to be introduced into the use case,
which can be taken advantage of during subsequent evolutional
behavioral modeling, as described in Section VI. In particular,
v ariation points can be used to describe newly evolved
functionality (represented as an optional feature in the feature
model) or evolved alternative functionality (represented as an
alternative feature in the feature model). Larger scale evolution
could result in new use cases being added, which are categorized
as optional or alternative use cases. Establishing traceability
between use case and feature models is described in [3].
An example from the Microwave Oven case study is the
Fig. 3: Evolution with addition of optional objects
Cook Food use case describing the sequence of interactions
between the actor and the system. The main sequence consists VII. EVOLUTIONARY SOFTWARE ARCHITECTURAL PATTERNS
of the user placing an item in the oven, entering the cooking
time, and pressing the start button; the system then cooks the Software architectural patterns [10] provide a reusable
food for a specified time. Adding the light feature would result template for the overall software architecture. Basing the
in the variation points introduced for switching on the light software architecture of a SPL on one or more software
when the door is opened and cooking is started, and switching architectural patterns helps in designing the original
off the light when the door is closed and cooking is finished. architecture as well as evolving the architecture.
Adding the multi-line display would lead to variation points at Many software systems and product lines can be based on
steps in the use case where information is displayed. Other well understood software architectures. For example, the
evolutionary features such as TOD Clock are sufficiently client/server software architecture is prevalent in many
different that they necessitate the addition of optional use cases, software applications. Evolution in client / server and service
Set TOD Clock and Display TOD, which must be reused oriented architectures is helped by using broker and discovery
together and hence constitute one optional feature. patterns. With this approach, an architecture can evolve with
the addition of new services, which can be discovered by
VI. EVOLUTIONARY BEHAVIORAL MODELING clients. New clients can be added that discover services. A new
Evolutionary behavioral modeling is an iterative strategy version of a service can replace an older version. Clients
[3] to determine the kernel software architecture and to communicating via the broker would automatically be
determine the impact of each newly evolved feature on the connected to the new version of the service. The
architecture. This results in new components being added to the Subscription/Notification pattern also helps evolution by
architecture or existing components having to be modified. The decoupling the original sender of the message from the
kernel system is the first version of the evolutionary recipients of the message.
architecture and corresponds either to the first deployed system Many real-time systems provide overall control of the
or for a product line design, an architecture that consists of environment by providing centralized control, decentralized
kernel objects and possibly default objects. The kernel software control, or hierarchical control [11]. Each of these control
architecture is developed by integrating the interaction approaches can be modeled using a software architectural
diagrams that realize the kernel use cases [3]. pattern. In a centralized control pattern, there is one control
As the system evolves, it is likely that optional objects component, which executes a state machine. It receives sensor
(e.g., Light Interface and Beeper Interface) and variant objects input from input components and controls the external
(e.g., Multi-Line Display Interface) will need to be added. It is environment via output components, as shown in Fig. 4. In a
also possible that due to evolutionary change, some kernel centralized control pattern, evolution takes the form of adding
objects might need to evolve into optional or variant objects. or modifying input and/or output components that interact with
The evolutionary development approach starts with the the control component. Another architectural pattern that is
kernel system and considers the impact of optional and/or worth considering for software evolution is the layered
alternative features. This results in the addition of optional or architectural pattern. This pattern allows for ease of extension
variant components to the evolving architecture. For example and contraction [12] because components can be added to or
adding the Light and Beeper features necessitates the addition removed from higher layers, which use the services provided
of the optional Light Interface and Beeper Interface objects. by components at lower layers of the architecture. Other
However it also necessitates a change in the Microwave patterns, such as the client/server and control patterns, can be
Control object that must send commands to these objects, such integrated with the layered pattern.
as Switch On, Switch Off, and Beep, as shown in the
communication diagram in Fig. 3.

26
 VIII. EVOLUTIONARY SOFTWARE ARCHITECTURE An evolved software architecture, which includes these two
The capability for modeling component-based distributed optional components as well as the variant Multi-Line
software architectures [10] is particularly valuable for Microwave Display component is shown in Fig. 6. In this
evolutionary system and SPLs, to allow the development of figure, each component is depicted with a reuse stereotype
kernel, optional and variant components. Evolving the (e.g., kernel, variant, optional) and a role stereotype (e.g., input,
software architecture is done by considering the impact of the output, control).
optional and alternative features on the kernel architecture and
what optional and variant components are needed to realize
these features. Traceability between software requirements
and architectures is established through features that model
variable requirements and relating these features to the
architectural components that realize the features [3].
Fig. 4 shows the kernel component-based software
architecture for the Microwave Oven. The kernel architecture
supports the Microwave Oven System use case model with the
Cook Food use case before evolution and the introduction of
any variation points. The architecture is based on the
centralized control pattern [10], in which there are input
components such as Door and Keypad components, the
centralized Microwave Control component, and output
components such as the Microwave Display component.
«input component» «input component» «input component»
DoorComponent WeightComponent KeypadComponent
Fig. 6: Evolutionary Component-Based Software Architecture

IX. DYNAMIC SOFTWARE PRODUCT LINES

Dynamic software product lines are needed when SPL
members need to evolve after deployment while the system is
operational [13]. Dynamic software adaptation for SPLs is the
«control component»
MicrowaveControl process of changing the architecture of a SPL member at run-
time to a different product line member. In other words,
dynamic software adaptation is concerned with changing the
application configuration at runtime after it has been deployed
and is needed for SPLs that have to dynamically adapt after
original deployment. To address dynamic adaptation, the
dynamic SPL life cycle extends the PLUS method’s
«output component»
HeatingElementComponent
«output component»
MicrowaveDisplay
Evolutionary Process Model for SPLs [14], as shown in Fig. 7.
For dynamic adaptation, PLUS consists of three phases: 1)
Fig. 4: Kernel Component-Based Software Architecture Domain Engineering, 2) Application Engineering, 3) Dynamic
Fig. 5 depicts two Feature dependent optional components, Application Adaptation.
Lamp and Beeper, and specifies their interfaces, which are The first two phases are as described in Section III. During
determined from the feature based impact analysis (Fig. 3). the third phase, Dynamic Application Adaptation, the
executable application is dynamically changed from the run-
time configuration for one SPL member to a new application
run-time configuration for a different SPL member [14].
The dynamic SPL feature model has to capture all features
of the SPL corresponding to the different application run-time
architectures. The run-time feature model captures the features
of the currently executing application and is initially deployed
at application derivation time. Furthermore, this feature model
can change at run-time by deactivating those features no longer
required and dynamically replacing them with new features
(from the original or evolved SPL feature model) that are
required. In order to dynamically adapt the software
architecture in response to these feature changes, it is necessary
to have a feature/component table that relates each feature to
Fig. 5: Feature dependent Optional Components
the components that realize the feature.

27
 Fig. 7: Software life cycle for dynamic SPL

This approach uses the PLUS feature/component [3] Gomaa, H., “Designing Software Product Lines with UML:
dependency table [3] to fulfill this need. As with conventional From Use Cases to Pattern-based Software Architectures”,
SPLs, this table is developed during SPL engineering and then Addison-Wesley, 2005.
used to derive the initial application architecture at application [4] K. Pohl et al, “Software Product Line Engineering: Foundations,
engineering time. The difference is that the table is later used to Principles and Techniques”, Springer, 2005.
dynamically adapt this architecture at run-time during dynamic [5] Kang K. C. et. al., “Feature-Oriented Domain Analysis,” TR No.
adaptation. CMU/SEI-90-TR-21, Software Engineering Institute, Nov 1990.
[6] H. Gomaa, “A Software Modeling Odyssey: Designing
X. CONCLUSIONS Evolutionary Architecture-centric Real-Time Systems and
Product Lines”, Proc. 9th Intl. Conf. on Model-Driven Eng.,
This paper has described an evolutionary software
Languages, and Systems, Genova, Italy, October 2006.
development approach, which uses software product line and
feature modeling concepts for evolving software requirements [7] H. Gomaa and M.E. Shin, “Multiple-View Modeling and Meta-
Modeling of Software Product Lines”, Journal of IET Software,
and architectures. The different versions of a system constitute Vol. 2, Issue 2, pp. 94-122, April 2008.
a family of systems with some common functionality and some
[8] Jacobson, I., M. Griss, and P. Jonsson. 1997. Software Reuse:
variable functionality. With the approach described in this Architecture, Process and Organization for Business Success.
paper, the goal is to model all versions of an evolving system, Reading, MA: Addison-Wesley.
in particular the evolving requirements and architecture using
[9] D. Webber and H. Gomaa, "Modeling Variability in Software
SPL concepts. The addition of optional and alternative Product Lines with the Variation Point Model", Journal of
features necessitates the adaptation of the original software Science of Computer Programming, Volume 53, Issue 3, Pages
architecture by designing optional and variant components to 305-331, Elsevier, December 2004.
realize these features. Based on feature modeling, the approach [10] R. N. Taylor, N. Medvidovic, and E. M. Dashofy, Software
closely relates the evolution of the software architecture to the Architecture: Foundations, Theory, and Practice. Wiley, 2009.
evolution of software requirements, as well as providing [11] H. Gomaa, “Software Modeling and Design: UML, Use Cases,
continuous traceability between requirements and architecture. Patterns, and Software Architectures”, Cambridge University
To ensure consistency among the multiple views of an Press, February 2011.
evolving system, it is desirable to have an underlying multiple [12] Parnas D., "Designing Software for Ease of Extension and
view meta-model. A multiple view meta-model for software Contraction", in Hoffman, D., and D. Weiss (eds.). Software
product lines has been developed [7]. Future work involves Fundamentals: Collected Papers by David L. Parnas. Addison-
extending this meta-model to incorporate concepts of software Wesley, 2001
evolution and dynamic SPL adaptation. Future work also [13] M. Hinchey, S. Park and K. Schmid, “Building Dynamic
involves applying these ideas to modeling larger evolutionary Software Product Lines”, IEEE Computer, Vol. 45, No. 10,
systems and product lines. October 2012.
[14] H. Gomaa and K. Hashimoto, “Dynamic Software Adaptation
REFERENCES for Service-Oriented Product Lines”, Proc. 5th Intl Workshop on
[1] B. Nuseibeh. "Weaving Together Requirements and Dynamic Software Product Lines, Munich, Germany, Aug 2011.
Architectures," IEEE Computer, vol. 34, no. 3, pp. 115-117,
Mar. 2001.
[2] P. Clements and L. Northrop, Software Product Lines: Practices
and Patterns, Addison Wesley, 2002.

28