book chapter variability integration-edited

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 &


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)


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.


4/32


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


5/32


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


6/32


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.


7/32


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/32


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


9/32


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


10/32


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.


11/32


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


12/32


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


13/32


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,


14/32


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


15/32


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,


16/32


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


17/32


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


18/32


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


19/32


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.


20/32


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


21/32


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.


22/32


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


23/32


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.


24/32



25/32


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


26/32


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.


27/32


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


28/32


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.


29/32


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


30/32


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.


31/32


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


32/32


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.

book chapter variability integration-edited

Documents