1 SETTING THE CONTEXT FOR VARIABILITY INTEGRATION IN SOFTWARE PRODUCT LINE

Shahliza 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 software reuse is Software Product Line (SPL) (Paul Clements &

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 level artefacts in software development. In SPL reuse happens with the use of core 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 its variabilities. 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 be generated. 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 of abstractions 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) managing variations 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 variability where 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 between requirements 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)

Variability Integration in SPL

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 Software Engineering (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 Domain Create primitive building Engineering blocks for the use of (Development multiple application for reuse) Application Create new applications by Engineering assembling prefabricated (Development components. with Reuse) SPL Creating generic artifacts that are sufficiently general to span a domain or family of applications. Instantiate specific artifacts tailored to the needs of a specific application user.

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 and specifications, 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 variation point, there are one or many choices to replace the variation point and these choices are called variants. Moreover; the variation

Variability Integration in SPL

point itself can be specified with specification for an easier selection and adaptation of the variation point. Among the information included in the variation point specification 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

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 variability identified 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 dependencies among 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.

Variability Integration in SPL

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 in architecture (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

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 approaches towards 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 be interrelated 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 are Product 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), QUASAR approach 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 DEVELOPMENT APPROACH

Variability Integration in SPL

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 approaches solve 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

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 of viewpoint, 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 or implicitly 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, the requirements and architecture level.

Variability Integration in SPL

11

Summary of evaluation criteria Criteria Explanation Representation for Integration Variability How variability is represented? Representation Requirement Are there any viewpoints in representing Viewpoints requirements? Architectural Are there any viewpoints in representing Viewpoints architecture? Process of Integration Tool support Is there any tool support for the process? Variability Is there any process defined in order to integrate Management requirement to architecture? Process Construct for Integration Architectural What is the derivation of architectural derivation components from requirement Mapping What is the mapping mechanism between the two mechanism phases

Based on the criteria discussed in Table 2, we have evaluated the six core assets development chosen earlier against

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 two phases. 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, its metamodel 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 with use 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

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 main models, 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 view with 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 main models, 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 traceability metamodel being proposed for the time being. As for QUASAR,

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 variability management 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 of analysis 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 using Goal and Scenario based technique and also using quantitative analysis to construct domain architectures without any elaboration on specification process. PLUSEE concentrates 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

Variability Integration in SPL

15

which describes how the logical components work. PLUSEE uses feature dependency for mapping between requirement and analysis views, but the mapping to architectural view is not elaborated. In KobrA, 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 have representation 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 rather than systematic process. This evaluation have been further supported by the statement in (Galster, Eberlein, & Moussavi,

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 the evaluation 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 approaches conceptually with variability integration metamodel.

Summary of approaches and their evaluation criteria

Variability Integration in SPL

17

Characteristics Variability Representation

Approaches PLUSEE Formal (multiple view metamodel)

DREAM Formal (extended RAS metamodel)

QUASAR Formal (extended IEEE 1471 architecture documentation)

Drama SemiFormal (class diagram)

KobRa Formal (metamodel for asset, generic assets and decision model) Functional + NonFunctional (Komponent Specification consist of structural model, behaviour model, functional model, decision model) Static + Behavioral (Komponent Realization consist of interaction model, structural model, activity model, decision model0

Requirements Viewpoints

Functional (use case)

Functional (use case)

Functional (feature model)

Functional + NonFunctional (Abstraction View and Quality View)

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)

18

Variability Integration in SPL

Characteristics Tool Support

Approaches PLUSEE Have tool support

DREAM Tool only support in domain requirements Explicit

QUASAR Commercial tool development Explicit

Drama Have tool support

KobRa Not mentioned

Variability Management Process Architecture Derivation

Implicit

Implicit

Implicit

Not mentioned

Commonality and Variability requirement matrix Trace relationships

Feature Model

Goal and Scenario based domain requirement analysis Transformation of goal into logical components

Not mentioned

Mapping Mechanism

No elaboration on the mapping from analysis to architectural view

Feature configuration and architecture configuration

Decision model for mapping between Komponent Specification to Komponent Realization

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 (Chastek et al., 2001; Thiel & Hein, 2002)) coined as architecture centric approach. The approaches are further analysed in the following section and their advantages and drawbacks are further discuss.

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 specification and 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 traceability from 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 in SPL.

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 more systematic 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, K and Chae, HS, 2005; Soon-Bok, Jin-Woo, Chee-Yang, & DooKwon, 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

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 both Dream and QUASAR 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 higher abstraction 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

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 the variability 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 Architectural Variation Point where it is mapped to Variation Point in the Variability Metamodel. Variability metamodel contains information on variation point specification. It also contains dependency and resolution rule to record the interdependence of requirement or architecture with

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. These two 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 PRElement at 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

Variability Integration in SPL

Variability Integration in SPL

25

Figure 4

Proposed Variability Metamodel

Integration

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 combining two 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 semantic meaning of the requirements. Moreover, extension with IEEE 1471 could bring in the benefit of using viewpoints library with suitable

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 the transformation 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 integration metamodel 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 or created 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.

Variability Integration in SPL

27

REFERENCES Atkinson, C., Bayer, J., & Muthig, D. (2000). Component-Based Product 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

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 IT research 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, October 3-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 International Conference on Automated Software Engineering (ASE'06), Tokyo, Japan.

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 from requirements 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), 702711. Kim, J., Park, S., & Sugumaran, V. (2008). DRAMA: A framework for domain requirements analysis and modeling

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). Transitioning to 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), 518. Krueger, C. W. (2002). Variation Management for Software Production Lines. Software Product Lines: Second International 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), 551569.

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). Software Product 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 FeatureArchitecture Mapping (FArM) Method for FeatureOriented 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 the NODe2004. 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

Variability Integration in SPL

Trigaux, J. C., & Heymans, P. (2003). Modelling variability requirements in Software Product Lines: A comparative survey. EPH3310300R0462/215315, FUNDPEquipe LIEL, 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.