Post on 07-Apr-2018
8/6/2019 Book Chapter Variability Integration-Edited
1/32
1
SETTING THE CONTEXT FOR
VARIABILITY INTEGRATION IN
SOFTWARE PRODUCT LINEShahliza Abd Halim
Dayang Norhayati Abg Jawawi
Safaai Deris
INTRODUCTION
The need for a faster, better and cheaper production of software
has motivated the intention to use again and again the repetitive
structure from the previous software development project in a new
but similar context. However, routinely practical and realistic
problem which occurs in software development force software
developers towards producing fast and ad hoc solutions to solve
the problem. This scenario hinders the payoffs of productivity and
quality that can be reaped from software reuse. Thus the problem
of software reuse has been highlighted in (Prieto-Diaz, 1993) as
lack of widespread, formalize and systematic reuse. In (Frakes &
Isoda, 1994) the success factors of systematic software reuse lies
on its repeatable process, domain specific focus and the reuse itself
primarily concentrates on higher level lifecycle artefacts such as
requirement, design and subsystems.
One of the notable approaches for systematic softwarereuse is Software Product Line (SPL) (Paul Clements &
8/6/2019 Book Chapter Variability Integration-Edited
2/32
2 Variability Integration in SPL
Northrop, 2002; Pohl, Bckle, & van der Linden, 2005). SPL
fulfils the criteria of systematic reuse where it focuses on domain
specific approaches and enables the reuse of higher and lower levelartefacts in software development. In SPL reuse happens with the
use ofcore assets (Paul Clements & Northrop, 2002; McGregor,
Northrop, Jarrad, & Pohl, 2002). With core assets, overlaps among
members of the family can be leverage by merging common parts
(known as commonality) and at the same time managing itsvariabilities. Thus, systematic reuse and automation in producing
products from SPL depends on how well its core asset is designed.
The more generic the core assets the more products can begenerated. This generality requires postponing the design decisions
with variation points to represent variabilities.
Due to the numerous feature interactions and variation
points to represent the variability in different level ofabstractions
in software development the amount of variability that has to be
supported in software artefacts is growing considerably and also
variability among individual products in the software product line
also increases. As in (Berg, Bishop, & Muthig, 2005) managingvariations at different levels of abstraction and across all generic
development artefacts is an overwhelming task. Thus a central
issue in SPL is the systematic management of variabilitywhere it
has been the key difference with conventional software and also
has been a major challenge in SPL development (Jan Bosch, 2004;
Krueger, 2002). This chapter focuses on the variability betweenrequirements and architectural levels of SPL development
phase. The explicit integration between the different phases is
hoped to have a significant benefit in the variability representation
between different abstraction levels and also leads towards a more
efficient product derivation in SPL.
OVERVIEW OF SOFTWARE PRODUCT LINE (SPL)
8/6/2019 Book Chapter Variability Integration-Edited
3/32
Variability Integration in SPL 3
The purpose of this section is to describe SPL in general. Firstly,
we describe the difference between SPL and another notable
paradigm in software reuse; Component Based SoftwareEngineering (CBSE). The difference basically lies on the
generality of its software artefacts known as core assets. Secondly,
we discuss the core assets role in SPL. Finally, we further discuss
on the importance of variability as a concept which plays the
important role to create generality in core assets.
Software Product Line
Among the prominent software reuse paradigms are Component
Based Software Engineering and also Software Product Line.
Even though both paradigms have the same phases of product
development, Domain Engineering and Application Engineering
however based on (Colin Atkinson & Muthig, 2002) there are
differences in each the focus of each phases as shown in Table 1.
Table 1 Differences between Component Based Development
and SPL
Approach CBD SPL
Domain
Engineering
(Development
for reuse)
Create primitive building
blocks for the use of
multiple application
Creating generic
artifacts that are
sufficiently general
to span a domain or
family of
applications.
Application
Engineering
(Developmentwith Reuse)
Create new applications by
assembling prefabricated
components.
Instantiate specific
artifacts tailored to
the needs of aspecific application
user.
8/6/2019 Book Chapter Variability Integration-Edited
4/32
4 Variability Integration in SPL
Based on Table 1, the ability of SPL to instantiate rather
than assemble the product is due to the generic nature of its
software artefacts known as core assets.
Core Assets
All artefacts associated with the reuse of similar products in the
product lines are referred as core asset (Paul Clements & Northrop,
2002; Her, Kim, Oh, Rhew, & Kim, 2007). Among the artefacts of
core asset are architecture, reusable software components, domain
models, requirements statements, documentation andspecifications, performance models, schedules, budgets, test plans,
test cases, work plans, and process descriptions. In order for
members in the SPL to share the same core assets, variability is
used to delay design decisions until it comes to a point whereby
differences will occur between members of the family and this
point is referred as variation point (J. Bosch, Florijn, Greefhorst,
Kuusela, Obbink, & Pohl, 2002; Svahnberg, Gurp, & Bosch,
2001a)
Variability
Variability can be defined as the ability to change or customize a
system (Bosch, 2001). First discussion on variability in software
artefacts comes from (Jacobson, 1997) where variability is seen as
practical, effective and scalable way for flexible and generic
component reuse to accommodate the differences between
individual application systems. As described by Bosh (Svahnberg,
Gurp, & Bosch, 2001b), to make an existing piece of software
reusable it must be able to be adapted in different context.
In order to have a clearer understanding of variability, we
represent variability metamodel that is based on (M. Moon, Yeom,
K and Chae, HS, 2005; Thiel & Hein, 2002) as shown in Figure 1.
Variation point represents variability in SPL. With each variationpoint, there are one or many choices to replace the variation point
and these choices are called variants. Moreover; the variation
8/6/2019 Book Chapter Variability Integration-Edited
5/32
Variability Integration in SPL 5
point itself can be specified with specification for an easier
selection and adaptation of the variation point.
Among the information included in the variation pointspecification are variation type which has been divided into four
types: computation, external, control and data as in (M. Moon,
Yeom, K and Chae, HS, 2005). Variation point cardinality
indicates the minimum number of variants which have to be
selected for this number of variation point and the maximum
number of variants that can be selected for this variation point
(Halmans & Pohl, 2003). Binding time is the time when variation
point has been bound to a chosen variant. According to (Thiel &Hein, 2002), resolution rules are strategies to be applied when
variation point needs to be bound.
Figure 1 Variability Metamodel to represent
concepts in variability
8/6/2019 Book Chapter Variability Integration-Edited
6/32
6 Variability Integration in SPL
STATE OF THE ART FOR VARIABILITY INTEGRATION
IN CORE ASSETS DEVELOPMENT
The building of the most important core asset, the PL Architecture
requires the understanding of domain requirements and precisely
defining, identifying and representing its variations systematically
and explicitly (Kircher, Schwanninger, & Groher, 2006; M. Moon,
Yeom, K and Chae, HS, 2005; Trigaux & Heymans, 2003; Yu,
Akhihebbal, & Jarzabek, 1998). Commonality and variabilityidentified in domain requirements will help in the refinement of
architectural components.
Among those existing feature oriented approaches such as
FORM (Kang, Kim, Lee, Kim, Shin, & Huh, 1998), FARM (P.
Sochos, Riebisch, & Philippow, 2006) and QUASAR (Chastek,
Donohoe, Kang, & Thiel, 2001), (Thiel & Hein, 2002), few
approaches deal with mapping from requirements to product line
architecture. This task is made difficult due to the dependenciesamong variants in architecture in order to fulfill a single
customers requirements (Bachmann & Bass, 2001; Chastek, 2001;
Thiel & Hein, 2002). Mapping of user requirements with the core
assets for the adaptation process and derivation of core assets
based on user requirements is a non-trivial task (Dhungana, 2006;
Matinlassi, 2004). This research concentrates on the integration of
variability in requirements and architecture phase in core assets
development approach.
8/6/2019 Book Chapter Variability Integration-Edited
7/32
Variability Integration in SPL 7
In order to illustrate the difficulties in linking between both
abstraction levels, we have adopted a diagram from (Bachmann &
Bass, 2001; P. Clements, Bachmann, Bass, Garlan, Ivers, Little, Nord, & Stafford, 2003) which shows the relation between
variation point in requirements to the architecture. The diagram has
been altered to illustrate library systems requirements and their
connection to the architecture as shown in Figure 2. From the
figure, Loan Material requirement has a variation point which
shows optional choices. Optional choices indicate that either one or
both alternative requirements can be chosen. In order to fulfil the
chosen requirements, dependencies among the variant module inarchitecture (depicted by the name Package) have to be resolved.
Choosing requirements and also resolving the appropriate
architecture structure highlight the needs to understand the variant
requirements and specifying them in order to address variants at
architectural level.
Figure 2 .Variability integration in relating
requirements and architecture
8/6/2019 Book Chapter Variability Integration-Edited
8/32
8 Variability Integration in SPL
We further discuss the related works which will be further
analysed in the evaluation framework. In order to classify works
related to our research, we focus our review on the approachestowards core asset development. These approaches are also known
as domain engineering approaches. The rationale of focusing on
core asset development approaches is based on the following
justifications:-
i. These approaches have a wider perspective in domain
engineering thus have a more refined scoping for the
product line
ii. These approaches have a more refined process that can beinterrelated with corresponding assets and artefacts.
iii. These approaches have already a product specific
instantiation mechanism in certain abstraction level (for
example at requirements or architectural level). The
mechanism can be effectively used in the derivation of
product specific application in the SPL.
Among the approaches which satisfies these criteria areProduct Line UML Based Software Engineering Environment
(PLUSEE) from the work of (Gomaa, 2005; Hassan & Michael,
2007), Domain Requirement Asset Manager (DREAM) from the
work of (Mikyeong, Keunhyuk, & Heung Seok, 2005; M. Moon,
Chae, Nam, & Yeom, 2007), QUASARapproach by Stefan Theil
and Andreas Hein (Chastek, 2001; M. Moon et al., 2007; Thiel &
Hein, 2002), Drama from the work of (Jintae Kim, Park, &
Sugumaran, 2008) and KobRa from the work (C. Atkinson,
Bayer, & Muthig, 2000). These approaches are further evaluated
based on an evaluation framework discussed in the following
section.
EVALUATION ON THE CORE ASSETS DEVELOPMENTAPPROACH
8/6/2019 Book Chapter Variability Integration-Edited
9/32
Variability Integration in SPL 9
In this section, an assessment has been made on the five core assets
development approaches in the previous subsection in a systematic
and consistent manner, reflecting on how far these approachessolve the integration of variability from requirement to architecture
level. In order to come out with our own evaluation criteria, we
refer to aspects highlighted by (Sinnema & Deelstra, 2007) for
their classification framework on variability modelling techniques
which comprise of:
i) What is exactly to be model?
ii) How tools support help in creating and using the
model?iii) Which step should be taken in order to use this model
i.e what processes are defined?
iv) What construct are available to do so?
For our evaluation criteria, we have modified these aspects
to make it suitable for our focus on variability integration. Among
the criteria chosen for the evaluation framework are.
Evaluation Criteria 1: Representation for integration
This criteria is to address the first question by (Sinnema &
Deelstra, 2007) of What exactly to be modelled?. The authors in
(Bachmann, Goedicke, Leite, Nord, Pohl, Ramesh, & Vilbig, 2004;
J. Bosch et al., 2002) have highlighted that variability must be
considered explicitly as a first class representation and the most
explicit representation for variability is via metamodel (Hassan &
Michael, 2007). Therefore, in order to identify on what are being
model, we first consider metamodel of the integration of variability
between requirements to architecture as the first sub criteria.
Representation for integration can be formal if the representation is
in the form of metamodel, semi-formal representation if the
modelling language such as UML is used and arbitrary if there is
no standard modelling language.Furthermore, as we concentrate on integrating variability
between requirements to architecture, we consider both viewpoints
8/6/2019 Book Chapter Variability Integration-Edited
10/32
10 Variability Integration in SPL
of this abstraction levels as an important aspects to be model. For
requirement viewpoints, Kotonya and Sommerville (Kotonya &
Sommerville, 1996) have proposed two different kinds ofviewpoint, either functional viewpoints or non-functional
viewpoint (viewpoint concentrates on the constraints imposed on
the system requirements). For architecture viewpoints, (Moore,
2005) describe the views as consisting of static (structural) view
and behavioural (dynamic) view
Evaluation Criteria 2: Process of Integration.
Process of integration criteria addressed the second and third
questions from (Sinnema & Deelstra, 2007). Therefore, there are
two more sub criteria to be included in this evaluation. The first
sub criterion is the tool support for the integration. The second sub
criterion is either the process for integration is explicitly defined orimplicitly defined. The process is explicit if it is a well defined and
repeatable. The process is implicit if it is otherwise.
Evaluation Criteria 3: Construct for Integration.
This criteria is to address the last question from (Sinnema &
Deelstra, 2007).of What construct available to do so?. In order to
identify the aspect of what construct available to model the
variability integration, we adopted two sub criteria from (P. P.
Sochos, I. and Riebish, M., 2004) on the construct for variability
integration. The first construct is the derivation technique of
architectural components from requirement. The second construct
is the mapping mechanism between the two abstraction level, therequirements and architecture level.
8/6/2019 Book Chapter Variability Integration-Edited
11/32
Variability Integration in SPL 11
Summary of evaluation criteria
Criteria Explanation
Representation for Integration
Variability
Representation
How variability is represented?
Requirement
Viewpoints
Are there any viewpoints in representing
requirements?
Architectural
Viewpoints
Are there any viewpoints in representing
architecture?Process of Integration
Tool support Is there any tool support for the process?
Variability
Management
Process
Is there any process defined in order to integrate
requirement to architecture?
Construct for Integration
Architecturalderivation
What is the derivation of architecturalcomponentsfrom requirement
Mapping
mechanism
What is themapping mechanism between the two
phases
Based on the criteria discussed in Table 2, we have
evaluated the six core assets development chosen earlier against
8/6/2019 Book Chapter Variability Integration-Edited
12/32
12 Variability Integration in SPL
the criteria. The following are the elaborated comparison for the
five approaches.
Evaluation Result 1: Representation for Integration
Each approach has different concern in representing variability
integration in their metamodel. Two approaches have extended
standards metamodel, DREAM and QUASAR. Reusable Assets
Specification (RAS) metamodel has been extended in Domain
Requirement and Domain Architecture of DREAM approach and
also produces Traceability metamodel to relate between the twophases. In QUASAR, the IEEE 1471 standards for architectural
documentation have been extended to show the variability
integration from feature to architecture. In order to have variability
integration, PLUSEE encompasses a multiple-view meta-model to
unify SPL representation for requirement, analysis and architecture
phase where each phase has its own view of metamodel. In Drama
there is a model in the form of class diagram to show the
relationships between goal, scenario and variability. In KobrA, itsmetamodel is package into three package structure, asset, generic
asset and decision model. Decision model package support the
traceability of variability in the assets and generic assets (Colin
Atkinson & Muthig, 2002).
All of the approaches have requirement viewpoints
Approaches such as PLUSEE and DREAM concentrate on
functional requirements withuse case. On the contrary, QUASAR
concentrates on feature model in order to relate with the
architectural variability. Another different technique is by Drama
where viewpoints related to requirements are the Abstraction View
and Quality View. Abstraction View consists of top down and
bottom up view. Bottom up view enables the identification of
initial goal requirement and top down view validates the initial
goal and refines it into sub-goals and scenario. In Quality View,
functional requirements is mapped into quality attributes(Jeongwook Kim, Kim, Park, & Sugumaran, 2004). However,
KobrA has a more different approach in terms of its viewpoints
8/6/2019 Book Chapter Variability Integration-Edited
13/32
Variability Integration in SPL 13
where it is divided into Komponent specification which describe
what a component does and Komponent realization which describe
how it does it. Komponent specification consists of four mainmodels, the structural model, the behavioural model, the functional
model and the decision model. We further classify Komponent
realization as architectural view and further describe in the next
subtopic.
Almost all of the approaches have both structural and
behavioural viewpoints in their approach except for Drama.
Though having the same viewpoints, they have different models in
their views. PLUSEE represents static (structural) modelling viewwith a class model and represents dynamic (behavioural) view with
collaboration and state chart model. DREAM supports Structural
View with component model and Behavioural View with
collaboration diagram. In Drama, Structure View represents the
systems boundary and structural relationship between entities in a
particular context while Function View captures the interactions
between various components (Jeongwook Kim et al., 2004).
KobrA with its Komponent realization comprise of four mainmodels, interaction model, structural model, activity model and the
decision model. QUASAR architectural viewpoints comprise of
Logical View and Process View to represent software aspects
while Physical View represents physical aspects and Deployment
View represent system aspects.
Evaluation Result 2: Process of Integration
Only one of these approaches do not have tool support. KobRa is
not reported as having a tool to support its process. Even though
other approaches have tool to support its process such as DREAM,
QUASAR, PLUSEE and Drama, not all of them support the
integration between requirements to architecture. For example in
DREAM, the tool reportedly support domain requirements whereas
for its integration to domain architecture, only traceabilitymetamodel being proposed for the time being. As for QUASAR,
8/6/2019 Book Chapter Variability Integration-Edited
14/32
14 Variability Integration in SPL
the tool has been commercially developed and there is not much
insight can be gained in the functionality of the tool.
DREAM and QUASAR have an explicit variabilitymanagement in its elicitation, specification and design process. In
DREAM, the integration of the three processes is based on matrix
technique in analysing commonality and variability of the most
atomic requirement(primitive requirement) in legacy systems. The
analysis is carried out in specification process in order to generate
use case diagram and design process in order to develop
component based domain architecture. In QUASAR, requirements
in the form of business case goes through several iterations ofanalysis and feature modelling in order to create domain
architecture.
Other approaches such as PLUSEE, Drama and KobrA
have concentrated on either one or two processes in requirement to
architecture integration. Drama concentrates on elicitation of
logical components usingGoal and Scenariobased technique and
also using quantitative analysis to construct domain architectures
without any elaboration on specification process. PLUSEEconcentrates on integration of requirement and analysis process
albeit the design process is not elaborated.
Evaluation Result 3: Construct for Integration
Except for KobrA and PLUSEE, other approaches have explicitly
mentioned their architectural derivation from requirements. Dream
uses variability and commonality analysis matrix in order to derive
architectural design. In Drama, goal and scenario based domain
requirement analysis is used to identify basic architectural units.
For QUASAR, feature model is used to identify the corresponding
design elements in the architecture.
In DREAM, trace relationships are used to map between
domain requirement and domain architecture. For Drama, mapping between requirements to architecture is based on the
transformation of goal into logical component and the scenario
8/6/2019 Book Chapter Variability Integration-Edited
15/32
Variability Integration in SPL 15
which describes how the logical components work. PLUSEE uses
feature dependencyfor mapping between requirement and analysis
views, but the mapping to architectural view is not elaborated. InKobrA, Decision model is the construct use for mapping
mechanism between the Komponent specification and Komponent
realization. QUASAR has a feature configuration and also
architecture configuration in order to relate variation points in both
requirements and architecture.
The summary of these approaches and its corresponding
evaluation framework characteristics can be referred in Table 3.
CRITICAL DISCUSSION ON THE EVALUATION
FRAMEWORK
With the integration from requirements to architecture, an explicit
link can be drawn from both phases thus enabling the utilisation of
the variation point that has been placed in software architecture
(Bachmann & Bass, 2001).Furthermore the gap between different
stakeholders in core assets development can be narrowed as the
refinement in requirements can be integrated to the variability in
more structured form as in the architecture.
Based on the evaluation in the previous section and the
evaluation summary in Table 3, almost all the approaches haverepresentation in the form of metamodel, requirement and
architecture viewpoints. However, not all of the approaches
explicitly specified their integration process. Though these
approaches have various constructs in their integration however the
constructs still do not explicitly show how the variability in
requirement being transformed into architectural variability
structure.
The integration process is still more of a creative ratherthan systematic process. This evaluation have been further
supported by the statement in (Galster, Eberlein, & Moussavi,
8/6/2019 Book Chapter Variability Integration-Edited
16/32
16 Variability Integration in SPL
2006) on the lack of systematic guidelines, processes and tools for
the support of building architectures based on requirements.
Based on Table 3 also, the works which fulfil almost all theevaluation criteria are DREAM and QUASAR. Inspired by the
work of QUASAR and the commonality and variability matrix in
DREAM we have proposed a pragmatic approach in our research
for combining these approaches. The combination of the
approaches is hoped to reap a systematic integration of variation
points in the requirement and architectural level with specified
guideline, process and tool for the integration process. The
following section discusses on the integration of both approachesconceptually with variability integration metamodel.
Summary of approaches and their evaluation criteria
8/6/2019 Book Chapter Variability Integration-Edited
17/32
Variability Integration in SPL 17
Characteristics Approaches
PLUSEE DREAM QUASAR Drama KobRa
Variability
Representation
Formal
(multiple
view
metamodel)
Formal
(extended
RAS
metamodel)
Formal
(extended
IEEE 1471
architecture
documentation)
Semi-
Formal
(class
diagram)
Formal
(metamodel
for asset,
generic
assets and
decision
model)
Requirements
Viewpoints
Functional
(use case)
Functional
(use case)
Functional
(feature model)
Functional
+ Non-Functional
(Abstraction
View and
Quality
View)
Functional
+ Non-Functional
(Komponent
Specification
consist of
structural
model,
behaviour
model,
functionalmodel,
decision
model)
Architecture
Viewpoints
Static +
Behavioral
(class,
collaboration
and state
chart model)
Static +
Behavioral
(component
model,
collaboration
diagram)
Static +
Behavioral
(Logical View,
Process View,
Physical View,
Deployment
View)
Static View
(Structure
View,
Function
View)
Static +
Behavioral
(Komponent
Realization
consist of
interaction
model,
structural
model,
activity
model,
decision
model0
8/6/2019 Book Chapter Variability Integration-Edited
18/32
18 Variability Integration in SPL
CONCEPTUAL APPROACH TO VARIABILITY
INTEGRATION
From the critical discussion, two approaches have been identified
with one of them representing a strong concentration in
requirement (Dream approach by (Mikyeong et al., 2005; M.
Moon et al., 2007)) coined as requirement centric approach.
Another approach is chosen for representing concentration in
architecture level (QUASAR approach by Stefan Theil and
Andreas Hein (Chasteket al., 2001; Thiel & Hein, 2002)) coined
as architecture centric approach. The approaches are furtheranalysed in the following section and their advantages and
drawbacks are further discuss.
Characteristics Approaches
PLUSEE DREAM QUASAR Drama KobRa
Tool Support Have tool
support
Tool only
support in
domain
requirements
Commercial
tool
development
Have tool
support
Not
mentioned
Variability
Management
Process
Implicit Explicit Explicit Implicit Implicit
ArchitectureDerivation
Notmentioned
Commonalityand
Variability
requirement
matrix
FeatureModel
Goal andScenario based
domain
requirement
analysis
Notmentioned
Mapping
Mechanism
No
elaboration
on the
mappingfrom
analysis to
architectural
view
Trace
relationships
Feature
configuration
and
architectureconfiguration
Transformation
of goal into
logical
components
Decision
model for
mapping
betweenKomponent
Specification
to
Komponent
Realization
8/6/2019 Book Chapter Variability Integration-Edited
19/32
Variability Integration in SPL 19
Dream Approach
Dream systematically develops requirements as core assets to
enhance requirements reusability. This approach is applied to
product line of B2B2C e-travel systems. Processes in Dream
approach can be summarised as follows: scoping of domain
requirements; followed by identification of common and variable
domain requirements using atomic requirements known as
Primitive Requirements (PR) with matrix known as CVProperty;
refining of domain requirements with requirement specificationand constraint between requirements; development of domain use
case model with matrix, and finally definition of the specification
and constraints of domain use case.
QUASAR approach
This approach concentrates on resolving variability for generating
specific product architecture in the product line with traceabilityfrom feature model to logical and physical architecture. The case
study of this approach is applied to software intensive systems
namely Car Periphery System. Processes in QUASAR approach
can be summarized as: preparation of workflow which contains
activities to support early architectural consideration; modelling of
workflow which contains activities for modelling architectural
views and variability within each view; evaluation of workflow
that contains activities for analysing architectural qualities.
Advantages of both approaches
Particularly in Dream, the approach has objectively identified
commonality and variability in requirements with matrix. The
domain requirements provide a suitable production plan which
tally to the market segment. This approach also provides a way to
compose domain requirements for product specific derivation inSPL.
8/6/2019 Book Chapter Variability Integration-Edited
20/32
20 Variability Integration in SPL
In the meantime, QUASAR concentrates on the product
line architecture and extends the IEEE 1471 recommended practice
for architectural description. The extensions enable a moresystematic representation for assets and artefacts in the SPL
architecture. Furthermore, with the configuration processes
between the feature and architecture level, the transformation of
information between the two abstractions level is able to be
performed.
Drawbacks of both approaches
In Dream, functional requirements are represented in a natural
language and use case diagram whilst matrix is used to determine
common and variable requirements. In contrast with Dream,
QUASAR represents the functional and non functional
requirements in the form of feature model. Albeit the popular
usage of feature model by various researches in SPL, feature
model reportedly does not properly represent the semantic in
requirements as reported in (Berg et al., 2005; M. Moon, Yeom, Kand Chae, HS, 2005; Soon-Bok, Jin-Woo, Chee-Yang, & Doo-
Kwon, 2007; Yu et al., 1998). Furthermore, commonality and
variability could not be objectively identified in feature model as it
relies on developers intuition and domain experts experience for
common and variable requirements determination.
Despite the fact that Dream is better in representing
requirements, the approach has drawback in their architecture
concern. Dream has fewer architectural views compared to
QUASAR which has different views to suit different stakeholders
needs. Furthermore, even though Dream can derive product
specific requirements, there is no mentioning of any derivation for
product specific architecture in this approach. In QUASAR, the
derivation of product specific architecture is based on resolution
rule and also architecture configuration.
Task to Integrate both Approaches
8/6/2019 Book Chapter Variability Integration-Edited
21/32
Variability Integration in SPL 21
In order to analysed and also integrate the metamodels of both
approaches, the steps that we have taken are listed below:
i. Separation of variability information from bothDream andQUASAR approaches. Separation is done in order to have
variability information in the third dimension. The
variability information can be referred in Variability
Metamodel as shown in Fig. 1.
ii. Identification of where the points of variation in both
approaches are. Identification of variation point in different
abstraction level is done to map the point of variation to the
variability metamodel.iii. Creation of relationships between the point of variation in
Dream and QUASAR metamodels with the variability
metamodel. This relationship can be further enhanced for
the purpose of traceability and also derivation.
Metamodel of Variability Integration
Metamodel of variability integration can be referred in a higherabstraction view in the form of packages is as shown in Figure 3.
The figure shows the relationships between Dream metamodel,
QUASAR metamodel, Variability Metamodel and IEEE 1471
metamodel.
8/6/2019 Book Chapter Variability Integration-Edited
22/32
22 Variability Integration in SPL
Figure 3 Higher abstraction for the variability
integration metamodel
Details of the metamodel for each packages and
relationships between the metaclasses can be referred in Figure 4.
Based on Figure 4, variability in requirement is realised by
CVProperty metaclass that represents matrix for specifying the
common and variable domain requirements. Variation point is
shown in PRElement that represents the specification for thevariability in requirements.
Variability in architecture is realised by Architectural
Variability metaclass. Architectural Variability reflects the
existence of alternative design options that could not be bound
during architectural modelling. Variation point in architecture is
represented by ArchitecturalVariationPointwhere it is mapped to
VariationPoint in the Variability Metamodel.
Variability metamodel contains information on variationpoint specification. It also contains dependency and resolution rule
to record the interdependence of requirement or architecture with
8/6/2019 Book Chapter Variability Integration-Edited
23/32
Variability Integration in SPL 23
one another and how to resolve it. This can further help in product
specific architecture derivation. Two important metaclasses in
Variability metamodel are Variability and Variation Point. Thesetwo classes have relationships with Dream (which represents
requirements level metamodel) and QUASAR (which represents
architectural level metamodel). Variability metaclass is realised at
the requirements level by CVProperty metaclass. At the
architectural level Variability metaclass is realised by Architectural
Variability metaclass. Variation Point metaclass is realised by
PRElementat the requirements level while Architectural Variation
Point realised Variation Point metaclass at the architectural level.IEEE 1471 metamodel contains standards to describe
architectural documentation. It has relationship with the QUASAR
metamodel (architecture level metamodel). With the IEEE 1471
standard metamodel, the architectural level information can be
described more uniformly following the view and viewpoints that
have been determined in the IEEE 1471.
8/6/2019 Book Chapter Variability Integration-Edited
24/32
24 Variability Integration in SPL
8/6/2019 Book Chapter Variability Integration-Edited
25/32
Variability Integration in SPL 25
Figure 4 Proposed Variability Integration
Metamodel
CONCLUSION
The identification of variability at the architectural level requires
the understanding of variability at the requirements level.
Therefore, the integration and relations between variability in
requirement and architecture level of the core asset must be
explicitly defined for stakeholders to understand how designers
realized product line variability and also for product derivation. As
a result, variability integration plays a significance role in relating
variability from requirements to architecture.
From the result of the evaluation framework, almost all of
the existing core assets development approaches have their own
metamodel and representations at the requirements as well as at
architecture level. However, the integration process is not
explicitly shown by the approaches. Furthermore, the lack of tools
to support this process also highlights the needs for the variability
integration tool for this research. The approaches also did not show
explicitly how the construct for the integration being transform
from requirements level to architectural level. Based on the
evaluation results we propose a pragmatic approach by combiningtwo approaches which fulfil the most evaluation criteria; DREAM
which concentrate more on requirements level and QUASAR
which concentrate more on the architectural level.
The advantage of combining requirements centric and
architecture centric approach is that it allows variability to be
represented and integrated in a different abstraction level.
Furthermore, requirements with natural language and use case
diagram are used instead of feature to express more semanticmeaning of the requirements. Moreover, extension with IEEE 1471
could bring in the benefit of using viewpoints library with suitable
8/6/2019 Book Chapter Variability Integration-Edited
26/32
26 Variability Integration in SPL
patterns or template for representation of architectural views.
However, all the advantages come with a price of the challenges in
integrating both approaches. Among the challenges are thetransformation between requirements and architecture should have
an explicit computation for its transformation. Furthermore the
guidelines, rules and procedures of both approaches must be
understood in order to synergize the integration of both
approaches. Furthermore the mapping or traceability and also
dependency between both abstractions levels must be determine to
enable a systematic derivation between both levels.
Our first step in the integration is the variability integrationmetamodel as shown in Figure 4 which is still in its preliminary
stage. Only the initial relationship between the requirements,
architecture and variability metamodel has been identified and also
the relationships between the architectural metamodel with the
IEEE 1471 metamodel. Further work is needed in order for the
metamodel to be used for validation with case study. The two
focuses that must be fulfilled are the traceability and the derivation
techniques that enable product specific application to be derived orcreated using the metamodel. Traceability will enable the
requirement to be traced to the related structure in the architecture.
Derivation technique on the other hand will enable the
architectural variation point to be bound based on the chosen
requirements.
Among the future work in order to enhance the metamodel
are to develop thoroughly the rules for integration of the
approaches, to determine the traceability and dependency between
both abstraction levels to alleviate the derivation process and to
validate and verify the metamodel and its rule with case studies. It
is hoped that the integration of variability between the requirement
and architecture level will enable an efficient traceability and thus
will leverage product specific derivation in product line.
8/6/2019 Book Chapter Variability Integration-Edited
27/32
Variability Integration in SPL 27
REFERENCES
Atkinson, C., Bayer, J., & Muthig, D. (2000). Component-BasedProduct Line Development: The KobrA Approach.Software Product Lines: Experience and Research
Directions: Proceedings of the First Software Product
Lines Conference (SPLC1), August 28-31, 2000, Denver,
Colorado.
Atkinson, C., & Muthig, D. (2002).Enhancing Component
Reusability through Product Line Technology (Vol.
Volume 2319): Springer Berlin / Heidelberg.Bachmann, F., & Bass, L. (2001). Managing variability in
software architectures. Paper presented at the Proceedings
8/6/2019 Book Chapter Variability Integration-Edited
28/32
28 Variability Integration in SPL
of the 2001 symposium on Software reusability: putting
software reuse in context Toronto, Ontario, Canada.
Bachmann, F., Goedicke, M., Leite, J., Nord, R., Pohl, K., Ramesh,B., et al. (2004). A Meta-model for Representing
Variability in Product Family Development. In Software
Product-Family Engineering(pp. 66-80).
Berg, K., Bishop, J., & Muthig, D. (2005). Tracing Software
Product Line Variability: from Problem to Solution Space.
Paper presented at the Proceedings of the 2005 annual
research conference of the South African institute of
computer scientists and information technologists on ITresearch in developing countries, White River, South
Africa
Bosch, J. (2004). Software variability management, Edinburgh,
United Kingdom.
Bosch, J., Florijn, G., Greefhorst, D., Kuusela, J., Obbink, J. H., &
Pohl, K. (2002). Variability Issues in Software Product
Lines. Software Product-Family Engineering: 4th
International Workshop, PFE 2001, Bilbao, Spain, October3-5, 2001: Revised Papers.
Chastek, G. (2001).Product Line Analysis: A Practical
Introduction. Pittsburgh: Software Eng. Inst. (SEI),
Carnegie Mellon Univ.
Chastek, G., Donohoe, P., Kang, K., & Thiel, S. (2001). Product
Line Analysis: A Practical Introduction.
Clements, P., Bachmann, F., Bass, L., Garlan, D., Ivers, J., Little,
R., et al. (2003).Documenting software architectures:
views and beyond: Addison-Wesley, Boston.
Clements, P., & Northrop, L. (2002). Software Product Lines:
Practices and Patterns. Boston: Addison-Wesley
Longman.
Dhungana, D. (2006).Integrated variability modeling of features
and architecture in software product line engineering.
Paper presented at the 21st IEEE/ACM InternationalConference on Automated Software Engineering (ASE'06),
Tokyo, Japan.
8/6/2019 Book Chapter Variability Integration-Edited
29/32
Variability Integration in SPL 29
Frakes, W. B., & Isoda, S. (1994). Success factors of systematic
reuse. Software, IEEE, 11(5), 14-19.
Galster, M., Eberlein, A., & Moussavi, M. (2006). Transition fromrequirements to architecture: A review and future
perspective. Paper presented at the Seventh ACIS
International Conference on Software Engineering,
Artificial Intelligence, Networking, and Parallel/Distributed
Computing, (SNPD'06), Las Vegas, NV, United States.
Gomaa, H. (2005).Designing Software Product Lines with UML.
From use cases to pattern-based software Architectures:
Addison Wesley.Halmans, G., & Pohl, K. (2003). Communicating the variability of
a software-product family to customers. Software and
Systems Modeling, 2(1), 15-36.
Hassan, G., & Michael, E. S. (2007).Automated Software Product
Line Engineering and Product Derivation. Paper presented
at the System Sciences, 2007. HICSS 2007. 40th Annual
Hawaii International Conference on System Sciences,
Hawaii.Her, J. S., Kim, J. H., Oh, S. H., Rhew, S. Y., & Kim, S. D. (2007).
A framework for evaluating reusability of core asset in
product line engineering.Information and Software
Technology, 49(7), 740-760.
Jacobson, I., Griss, M., Jonsson, P. (1997). Software Reuse
Architecture, Process and Organization for Business
Success: ACM Press.
Kang, K. C., Kim, S., Lee, J., Kim, K., Shin, E., & Huh, M.
(1998). FORM: A feature-oriented reuse method with
domain-specific reference architectures.Annals of Software
Engineering, 5, 143-168.
Kim, J., Kim, J., Park, S., & Sugumaran, V. (2004). A multi-view
approach for requirements analysis using goal and scenario.
Industrial Management and Data Systems, 104(9), 702-
711.Kim, J., Park, S., & Sugumaran, V. (2008). DRAMA: A
framework for domain requirements analysis and modeling
8/6/2019 Book Chapter Variability Integration-Edited
30/32
30 Variability Integration in SPL
architectures in software product lines.Journal of Systems
and Software, 81(1), 37-55.
Kircher, M., Schwanninger, C., & Groher, I. (2006). Transitioningto a software product family approach - challenges and
best practices. Paper presented at the Software Product
Line Conference, 2006 10th International.
Kotonya, G., & Sommerville, I. (1996). Requirements engineering
with viewpoints. Software Engineering Journal, 11(1), 5-
18.
Krueger, C. W. (2002). Variation Management for Software
Production Lines. Software Product Lines: SecondInternational Conference, SPLC2, San Diego, CA, USA,
August 19-22, 2002: Proceedings.
Matinlassi, M. (2004). Comparison of Software Product Line
Architecture Design Methods: COPA, FAST, FORM,
KobrA and QADA. Paper presented at the Proceedings of
the International Conference on Software Engineering
(ICSE'04).
McGregor, J. D., Northrop, L. M., Jarrad, S., & Pohl, K. (2002).Initiating software product lines. Software, IEEE, 19(4),
24-27.
Mikyeong, M., Keunhyuk, Y., & Heung Seok, C. (2005). An
approach to developing domain requirements as a core
asset based on commonality and variability analysis in a
product line. Software Engineering, IEEE Transactions on,
31(7), 551-569.
Moon, M., Chae, H. S., Nam, T., & Yeom, K. (2007). A
Metamodeling Approach to Tracing Variability between
Requirements and Architecture in Software Product Lines.
Computer and Information Technology, 2007. CIT 2007.
7th IEEE International Conference on, 927-933.
Moon, M., Yeom, K and Chae, HS. (2005). An Approach to
Developing Domain Requirements as a Core Asset Based
on Commonality and Variability Analysis in Product Line.IEEE Transactions on Software Engineering, 31(7), 551-
569.
8/6/2019 Book Chapter Variability Integration-Edited
31/32
Variability Integration in SPL 31
Moore, J. W. (2005). The Road Map to Software Engineering: A
Standards-Based Guide: Wiley Publication.
Pohl, K., Bckle, G., & van der Linden, F. (2005). SoftwareProduct Line Engineering: Foundations, Principles, and
Techniques: Springer.
Prieto-Diaz, R. (1993). Status report: software reusability.IEEE
Software, Volume 10(Issue 3), 61 - 66.
Sinnema, M., & Deelstra, S. (2007). Classifying variability
modeling techniques.Information and Software
Technology, 49(7), 717-739.
Sochos, P., Riebisch, M., & Philippow, I. (2006). The Feature-Architecture Mapping (FArM) Method for Feature-
Oriented Development of Software Product Lines. Paper
presented at the Proceedings of the 13th Annual IEEE
International Symposium and Workshop on Engineering
and Computer Based Systems (ECBS'06).
Sochos, P. P., I. and Riebish, M. (2004).Feature Oriented
Development of Software Product Lines:Mapping Feature
Models to the Architecture. Paper presented at theNODe2004.
Soon-Bok, L., Jin-Woo, K., Chee-Yang, S., & Doo-Kwon, B.
(2007).An Approach to Analyzing Commonality and
Variability of Features using Ontology in a Software
Product Line Engineering. Paper presented at the
Conference Name|. Retrieved Access Date|. from URL|.
Svahnberg, M., Gurp, J. v., & Bosch, J. (2001a). On the Notion of
Variability in Software Product Lines. Paper presented at
the Working IEEE/IFIP Conference on Software
Architecture, 2001 (WICSA'01).
Svahnberg, M., Gurp, J. v., & Bosch, J. (2001b). On the Notion of
Variability in Software Product Lines.IEEE.
Thiel, S., & Hein, A. (2002). Systematic Integration of Variability
into Product Line Architecture Design. In Software
Product Lines : Second International Conference, SPLC 2,San Diego, CA, USA, August 19-22, 2002. Proceedings (pp.
67-102).
8/6/2019 Book Chapter Variability Integration-Edited
32/32
32 Variability Integration in SPL
Trigaux, J. C., & Heymans, P. (2003). Modelling variability
requirements in Software Product Lines: A comparative
survey.EPH3310300R0462/215315, FUNDPEquipeLIEL, Namur.
Yu, C. C., Akhihebbal, A. L., & Jarzabek, S. (1998).Handling
Variant Requirements in Software Architectures for
Product Families. Paper presented at the Proceedings of the
Second International ESPRIT ARES Workshop on
Development and Evolution of Software Architectures for
Product Families.