Handling Variability and Traceability over SPL Disciplines

SPL has proven to be a successful approach in many business environments (Clements & Northrop, 2001a; Pohl et al., 2005a). Nevertheless, the SPL advantages do not come for free. They demand mature software engineering, planning and reuse, adequate practices of management and development, and also the ability to deal with organizational issues and architectural complexity. If these points are not considered, the product line success could be missed (Birk & Heller, 2007). Therefore, the development should be supported by auxiliar methods and tools, specially due to the complexity of the software systems that a SPL is supposed to deal with, represented by the variabilities.


Introduction
SPL has proven to be a successful approach in many business environments (Clements & Northrop, 2001a;Pohl et al., 2005a).Nevertheless, the SPL advantages do not come for free.They demand mature software engineering, planning and reuse, adequate practices of management and development, and also the ability to deal with organizational issues and architectural complexity.If these points are not considered, the product line success could be missed (Birk & Heller, 2007).Therefore, the development should be supported by auxiliar methods and tools, specially due to the complexity of the software systems that a SPL is supposed to deal with, represented by the variabilities.
Modeling can be used as a support mechanism to define and represent the variability involved in a SPL in a controlled and traceable way, as well as the mappings among the elements that compose a SPL.Many SPL projects are developed and maintained using model-based approaches (Dhungana et al., 2010).In this context, this chapter1 proposes a metamodel representing the interactions among the assets of a SPL, developed in order to provide a way of managing traceability and variability.The proposed metamodel consists of representing diverse reusable assets involved in a SPL project, ranging from scoping to test artifacts, and also documentation.
The motivation to build the metamodel emerged from the experience gained during an industrial SPL project development that we have been involved in.This project consists of introducing SPL practices in a company working in the healthcare management systems domain, placed in Salvador, Brazil.The company currently has a single software development process and develops four different products: SmartHealth, a product composed by 35 modules (or sub-domains), which has the capability of managing a whole hospital, including all areas, ranging from financial management to issues related to patient's control; SmartClin, composed by 28 modules, is responsible to perform the clinical management, supporting activities related to medical exams, diagnostics and so on; SmartLab is a product composed by 28 modules, which integrates a set of features to manage labs of clinical pathology; all Although diverse metamodels have been proposed in the literature (Anquetil et al., 2010;Bachmann et al., 2003;Bayer & Widen, 2001;Bühne et al., 2005;Moon et al., 2007;Sinnema et al., 2004;Streitferdt, 2001) in order to address variability and traceability aspects, they generally cover the SPL phases partially or do not treat such issues together through all the SPL disciplines.In this paper, we propose a metamodel which provides support for several SPL aspects, such as scoping, requirements, tests, and project and risk management.Furthermore, the metamodel was built upon a set of requirements concerning different issues identified in the literature, which is further discussed in Section 4. It also serves as a basis to understand the mappings among the SPL assets, communicate them to the stakeholders, facilitate the evolution and maintenance of the SPL, as well as it can be adapted to other contexts.
The remainder of this chapter is structured as follows: Section 2 presents an overview regarding SPL and its main concepts; Section 3 introduces the traceability conept; Section 4 specifies the requirements for a SPL metamodel; Section 5 describes the actual proposed metamodel, detailing its building blocks; in Section 6 an initial validation of the proposal is presented; Section 7 presents the related work; and finally, Section 8 concludes this work and outlines future work.

SPL essential activities
Software Product Lines combine three essential and highly iterative activities that blend business practices and technology.Firstly, the Core Asset Development (CAD) activity that does not directly aim at developing a product, but rather aims to develop assets to be further reused in other activities.Secondly, Product Development (PD) activity which takes advantage of existing, reusable assets.Finally, Management activity, which includes technical and organizational management (Linden et al., 2007).Figure 1 illustrates this triad of essential activities.

Core Asset Development
Core Asset Development is the life-cycle that results in the common assets that in conjunction compose the product line's platform (Linden et al., 2007).The key goals of this activity are (Pohl et al., 2005b): • Define variability and commonality of the software product line; • Determine the set of product line planned members (scope); and • Specify and develop reusable artifacts that accomplish the desired variability and further instantiated to derive product line members.
This activity (Figure 2) is iterative, and its inputs and outputs affect each other.This context influences the way in which the core assets are produced.The set of inputs needed to accomplish this activity are following described (Northrop, 2002).Product constraints commonalities and variations among the members that will constitute the product line, including their behavioral features; Production constraints commercial, military, or company-specific standards and requirements that apply to the products in the product line; Styles, patterns, and frameworks relevant architectural building blocks that architects can apply during architecture definition toward meeting the product and production constraints; Production strategy the whole approach for realizing the core assets, it can be performed starting with a set of core assets and deriving products (top down), starting from a set of products and generalizing their components in order to produce product line assets (bottom up) or both ways; Inventory of preexisting assets software and organizational assets (architecture pieces, components, libraries, frameworks and so on) available at the outset of the product line effort that can be included in the asset base.
Based on previous information (inputs), this activity is subdivided in five disciplines: (i) domain requirements, (ii) domain design, (iii) domain realization (implementation), (iv) domain testing and (v) evolution management, all of them administered by the management activity (Pohl et al., 2005b).These disciplines are responsible for creating the core assets, as well as, the following outputs (Figure 2) (Clements & Northrop, 2001b): Product line scope the description of the products derived from the product line or that the product line is capable of 5 Handling Variability and Traceability over SPL Disciplines www.intechopen.comFig. 2. Core Asset Development (Northrop, 2002).
including.The scope should be small enough to accommodate future growth and big enough to accommodate the variability.Core assets comprehend the basis for production of products in the product line, besides the reference architecture, that will satisfy the needs of the product line by admitting a set of variation points required to support the spectrum of products, theses assets can also be components and their documentation.The Production plan describes how the products are produced from core assets, it also describe how specific tools are to be applied in order to use, tailor and evolve the core assets.

Product development
The product development main goal is to create individual (customized) products by reusing the core assets previously developed.The CAD outputs (product line scope, core assets and production plan), in conjunction with the requirements for individual products are the main inputs for PD activity (Figure 3).Fig. 3. Product Development (Northrop, 2002).
In possession of the production plan, which details how the core assets will be used in order to build a product, the software engineer can assemble the product line members.The product requirement is also important to realize a product.Product engineers have also the responsibility to provide feedback on any problem or deficiency encountered in the core assets.It is crucial to avoid the product line decay and keep the core asset base healthy.

Management
The management of both technical and organizational levels are extremely important to the software product line effort.The former supervise the CAD and PD activities by certifying that both groups that build core assets and products are engaged in the activities and to follow the process, the latter must make sure that the organizational units receive the right and enough resources.It is, many times, responsible for the production strategy and the success or failure of the product line.

SPL variability management
During Core Asset Development, variability is introduced in all domain engineering artifacts (requirements, architecture, components, test cases, etc.).It is exploited during Product Development to derive applications tailored to the specific needs of different customers.
According to Svahnberg et al. (2005), variability is defined as "the ability of a software system or artifact to be efficiently extended, changed, customized or configured for use in a particular context".
It is described through variation points and variants.While, the variation point is the representation of a variability subject (variable item of the real world or a variable property of such an item) within the core assets, enriched by contextual information; the variant is the representation of the variability object (a particular instance of a variability subject) within the core assets (Pohl et al., 2005b).
The variability management involve issues, such as: variability identification and representation, variability binding and control (de Oliveira et al., 2005).Three questions are helpful to variability identification, what vary the variability subject, why does it vary the drivers of the variability need, such as stakeholder needs, technical reasons, market pressures, etc.The later, how does it vary the possibilities of variation, also known as variability objects.
The variability binding indicates the lifecycle milestone that the variants related with a variation point will be realized.McGregor et al., 2004).
Finally, the purpose of variability control is to defining the relationship between artifacts in order to control variabilities.

SPL traceability
It most organizations and projects with mature software development processes, software artifacts created during the application of these processes end up being disconnected from each other.There are several factors leading to the lack of traceability among artifacts, as stated by Rilling et al. (2007).They are: (i) these artifacts may be written in different languages (natural language vs. programming language); (ii) the system is described by considering 7 Handling Variability and Traceability over SPL Disciplines www.intechopen.comvarious abstraction levels/views (scoping and requirements vs. design or implementation); (iii) software processes do not consider maintenance of existing traceability links as a "must have" practice; and also (iv) there is a lack of adequate tool support to create and maintain traceability among software artifacts.
The lack of traceability among artifacts can be considered a major challenge for many software maintenance activities (Rilling et al., 2007).As a result, during the comprehension of existing software systems, software engineers are likely to spend an enormous effort on synthesizing and integrating information from various sources to establish links among these artifacts.
Indeed, by establishing traceability, engineers have the opportunity to understand how software artifacts interact with each other, in terms of relations and dependencies.Traceability links are indeed helpful when considering the evolutionary characteristic of the software artifacts, that are likely to be changed during its lifecycle.
According to Anquetil et al. (2010), establishing traceability yield a series of benefits, such as: (i) to relate software artifacts and corresponding design decisions, (ii) to give feedback to architects and designers about the current state of the development, allowing them to reconsider alternative design decisions, and to track and understand errors, and (iii) to ease communication between stakeholders, among others.
In SPL, where assets can be used by many products, traceability is even more important.A change in an artifact in a product line may lead to resultant changes in all products developed reusing such an artifact.Hence, it is necessary to define dependency relationships between the relevant artifacts to support consistent change integration (Moon et al., 2007).
Traceability practices vary widely-from high-end to low-end (Ramesh & Jarke, 2001).The prior use customized traceability knowledge for managing variability.Project managers may select traceability practices based on project characteristics such as system complexity, product line vs. single system software development, and degree of variety involved.The later take more of a "one-size fits all" approach to documenting traceability knowledge, and create simple traceability links between customer requirements, design, and code modules.While high-end practices aim at customer satisfaction and system quality, low-end are used just to meet organizational or customer-mandated quality requirements (Mohan & Ramesh, 2007).

Requirements for the SPL metamodel
We identified some work (Bayer & Widen, 2001;Bühne et al., 2005;Sinnema et al., 2004;von Knethen & Paech, 2002) that elicited different requirements which a metamodel for SPL should be in conformance with, in order to support properly the SPL development characteristics.The requirements are following described.
In (Sinnema et al., 2004), the authors propose four (4) requirements that a framework for modeling variability in SPL should have to support product derivation.However, the product derivation phase in SPL depends on how properly the previous phases are done.Therefore, such requirements in our metal-model are considered from the initial SPL phases: Uniform and first-class representation of variation points in all abstraction levels.Sinnema et al. (2004) stated that "uniform and first-class representation of variation points facilitates the assessment of the impact of selections during product derivation and changes during evolution".

8
Software Product Line -Advanced Topic www.intechopen.comHierarchical organization of variability representation.In (Sinnema et al., 2004), it is also argued that explicitly representing these variation points hierarchically reduces the cognitive complexity during the product derivation process.
Dependencies, including complex ones, should be treated as first-class citizens in the modeling approach."First class representation of dependencies can provide a good overview on all dependencies".In our metamodel, we provide mechanisms that enable all the SPL assets, even as all the dependencies, be treated as first-class citizens.
The interactions between dependencies should be represented explicitly.All the assets in a SPL should be linked in order to preserve their dependencies.By doing that, the product derivation, maintenance and evolution of the SPL can be performed in an efficient and effective way.Thus, the metamodel should have a very high degree of linkage among its entities.
In (Bühne et al., 2005), three (3) essential requirements were defined to support variability documentation across different SPLs.Although our metamodel is not intended to support multiple SPLs yet, one of those requirements may be useful: Facilitate the creation of views on the documented variability and constraints.Bühne et al. (2005) stated that an approach to document and manage variability across SPLs needs "to support selective retrieval of variability and commonality information, including variability constraints".It is not a specific cause when supporting different SPLs, but it is also important in a single SPL.

Traceability requirements
While analyzing all the previous requirements, we have noticed that traceability is the fundamental building block that enables those requirements.Thus, the basis for constructing a SPL metamodel is a strong linkage among all elements/assets involved in a SPL development.
These elements, such as features, requirements, design, source code, and test artifacts, should be linked in a way that their building, evolution and maintenance could be more effectively controlled, and the impact of changes and addition of new features in different products from the SPL could be analyzed.
According to von Knethen & Paech (2002), tracing approaches should capture and manage relationships among the different documents built during development phase.It enables to support various stakeholders, such as maintainer, project manager, customers, developers, testers, etc., in performing their tasks.For example, project planners use traceability to perform impact analysis, while designers use it to understand dependencies between requirement and design (von Knethen & Paech, 2002).Thus, we believe that without enabling traceability as a basis of the metamodel, the realizations of the requirements previously described are not feasible, becoming the SPL development a complete disorder.
In (Bayer & Widen, 2001), some requirements are set that consider traceability issues: (a) base the traceability on the SPL metamodel; (b) it should be customizable in terms of available trace types; (c) it should be capable of handling variability in the product line infrastructure; (d) the number of traces should be as small as possible; and (e) it should be automatable.
Although we presented a large set of requirements along this section, we have not found studies that implement all these together.Thus, in our proposal, we grouped all these 9 Handling Variability and Traceability over SPL Disciplines www.intechopen.comrequirements to fit them in our metamodel, as detailed in next section.Furthermore, such requirements can also serve as a guideline for building SPL models.

The SPL metamodel
In this section, we describe the initial metamodel developed in order to fulfill the requirements specified in previous sections.It was developed using the UML notation (Booch et al., 2005).The metamodel was initially divided into SPL management, which currently includes the risk management sub-metamodel, and the SPL core development, which are the scoping, requirement, and tests sub-metamodels.Henceforth, we will call the submetamodels just by models.
Figure 4 shows the overall view of the metamodel, where the dashed boxes specify the models of the metamodel.The variability model is strongly based on the generic metamodel proposed by Bachmann et al. (2003).We split the metamodel into small diagrams in the next subsections in order to explain it in details.It starts by detailing the Asset UML Profile, scoping model, then moving towards requirement, tests, and management models.

Asset UML profile
This is the metamodel core entity, called Asset, as shown in Figure 5.This entity is used as a UML profile3 for the other entities of the metamodel which should behave as an Asset.Thus, whenever an entity of the SPL metamodel have the properties of an Asset, it is extended using the asset profile tag.The usage of such profile has three main reasons: (1) to enable the evolution and maintenance of the metamodel without the need to modify the entire metamodel; (2) to transform the metamodel entities into first class entities; and (3) to keep the metamodel views clean and understandable.
The Asset entity is the metamodel core since it has properties that make feasible some of the requirements aforementioned.For example, it is related to a History entity, which is responsible to keep track of the changes that are performed in some Asset object.Thus, a History object records the Asset object which was modified, what kind of modification was performed, and who did it.Recording such modifications enables, for example, to calculate the probability that an Asset object has to be modified -such probability could impact directly in the SPL architecture design (von Knethen & Paech, 2002).
The Asset entity is also related to a set of metrics (Metric entity).During the SPL development, it is important to have information quantifying the metrics.For example, we could measure the effort for scoping analysis and requirement analysis, thus it would be possible to estimate the value for each feature or requirement.We could also set a metric for number of LOC (Lines of Code) for each feature in the SPL, or how many requirements and use cases some feature has.The granularity of the metrics can vary from the very high level to the very low level due to the strong tracking capability of the metamodel.of this should be created.Thus, integrating a versioning mechanism inside the metamodel will enable easy maintenance of different versions of the same product.If the metamodel is extended to support different SPLs, it becomes more critical.The History entity should not be confused with the Version entity; the former holds metadata information for the Asset object, while the later keeps different copies of an Asset object.
Last, but not least, the metamodel also integrates a mechanism for issues reporting.This mechanism enables any Asset object to be associated with an Issue object.It also means that someone could report an issue for different versions of the same Asset object.As direct impact of this mechanism, it will provide easy maintenance and evolution of different Asset object versions.However, due to better understanding reasons, the issue mechanism showed in the  Asset UML Profile is a simplification of what an issue mechanism should be.Therefore, the metamodel can be extended with other specialized entities to support a complete issue tracker system, even as it could be done for versioning, metrics, and history mechanisms.

Scoping model
During the scoping phase (John & Eisenbarth, 2009), the feature model is assembled based on the method to identify those features (Kang et al., 1990).In some cases, a tree is built containing all feature types, such as mandatory, alternative and optional.The scoping model is shown in Figure 6.
We used the Composite design pattern (Gamma et al., 1995) to represent the feature model, since it is a good representation using UML diagrams for the feature model proposed by Kang et al. (1990).It enables the features and their dependencies to be represented in a form of a tree, where features can have sub-features (children) recursively.The feature model proposed in the scoping model also enables other relationship between features, e.g. it is possible to specify what are the required and excluded features when choosing any feature.Moreover, the metamodel can be extended to support other relationships.
In the scoping model, a Feature object has BindingTime, VariabilityType, Module and Product entities associated with it.We did not specify the binding times and variability types for the features, because it must be done when instantiating the metamodel.According to Kang et al. (1990), examples of binding time are before compilation, compile time, link time, load time, run-time; and examples of variability type can be Mandatory, Alternative, Optional, and Or.
In the scoping model, the Feature objects are grouped into Module objects, and Module objects are then grouped into Product objects.The Module objects can be viewed also as the sub-domains of the Product objects.It was decided to structure the metamodel in this way since it better represents the SPL project we are developing in the mentioned private company.However, if it is not necessary to have a Module entity, it is easy to remove that from the metamodel, since the other phases are not directly linked to the Module entity.
Fig. 6.The model for scoping phase.

Requirements model
The metamodel also involves the requirement engineering traceability and interactions issues, considering the variability and commonality in the SPL products.The two main work products from this SPL phase are the requirements and use cases.Figure 7 presents the model regarding the requirements phase.The Requirement object is composed by name, description, bindingTime, priority.During its elicitation, it should envisage the variations over the foreseeable SPL life-cycle (Clements & Northrop, 2001a), considering the products requirements and the SPL variations.Briefly, it presents what the systems should do and how they are supposed to be.
Some scoping outputs serve as source of information in this phase.For instance, during the requirements elicitation the feature model is one of the primary artifacts.Features and requirements have a many-to-many relationship, which means that one feature can encompass many requirements and different requirements can encompass many features (Neiva et al., 2009).
It is important to highlight that the metamodel was built in order to address the behavior of SPL projects.In this sense, there are three scenarios where a requirement may be described: (i) the requirement is a variation point; (ii) the requirement is a variant of a variation point; and (iii) the requirement has variation points.
The same scenarios are used when eliciting use cases, it also can be composed by variation points and variants, represented in the model by flow and sub-flow, respectively.In addition, the same many-to-many association is used between requirements and use cases, in which one requirement could encompass many use cases, and a use case could be encompassed by many requirements.The UseCase model is composed by name, description, preCondition and postCondition.The alternative flows are represented by the flows and sub-flows.

Tests model
The metamodel encompasses testing issues in terms of how system test cases interact with other artifacts.The Test Cases are derived from Use Cases, as can be seen in the metamodel and separated in Figure 8.This model expands on the abstract use case definition, in which variability is represented in the use cases.A use case is herein composed by the entity AbstractFlow, that comprises the subentity Flow, which actually represent the use case steps.Every step can be associated with a subflow, that can represent a variation point.Figure 9 illustrates the dependency between test objective and test case when variability is considered (Wübbeke, 2008).Consider that in (A) the component is variable as a whole, and in (B) only part of the component is variable.They will turn, respectively, into (A') and (B'), the former as a new test case, which is variable as a whole, and the latter, a test case in which only the corresponding part of the test case is variable.Hence, the challenge is how to optimally build test cases that take into consideration variability aspects so that the reuse of the parts of test cases will emerge easily.
The case illustrated in the Figure 9 is a typical case, in which only part of a use case varies.It is not necessary to create different use cases to represent the variability, but rather reuse part of it.According to the requirements model of the metamodel (Figure 7), such a representation is feasible, since every step in a use case can make reference to a subflow.In this case, if we consider the first three possible scenarios, we could create the test case for scenario (1), and then reuse the flow of this scenario and the results for the remaining scenarios ( 2) and ( 3).This idea is brought from the control-flow coverage criteria, based on graph representation.We applied this same representation, but now considering aspects of variability.Considering that a use case can generate several test cases, the strategy to represent each step in a use case and enable it to be linked to a variation point enables the building of test cases which also consider the variation points.This way, several test cases can be instantiated from a use case, that have represented the variation points.Variability is preserved in the core asset test artifacts to facilitate reuse.

Software Product Lines -The Automated Analysis
This strategy allows that every change in the use case and/or the variation points and variants to be propagated to the test cases and their steps (variable or not), due to the strong traceability represented in the metamodel.

Initial management model
In this section, the main characteristics of the management model are presented.The main objective of this model is to coordinate the SPL activities.Through this model it is possible to manage the SPL project and consequently keep track of its different phases and the staff responsible for that.Thus, it is possible to maintain the mappings and traceability between every artifact.
As illustrated in Figure 11, the management model can be viewed as the starting point to the SPL metamodel.Hence, through this model we can define information about the SPL project as well as details such as the SPL phases, the tasks to be performed, the members responsible for the tasks and their associated roles.In addition, the decisions about the SPL project can be documented using the Decision entity, by describing the alternatives, justification, notes, when it occurred, and the involved staff.
Fig. 11.The model for project management.

Risks model
According to Sommerville (2007), Risk Management (RM) is particularly important for software projects because of the inherent uncertainties that most projects face.These stem from loosely defined requirements, difficulties in estimating the effort and resources needed for software development, and dependence on individual skills and requirements changes due to changes in customer needs.

16
Software Product Line -Advanced Topic www.intechopen.comThus, our RM model for SPL involves activities which must be performed during the RM process that involves all SPL phases.These activities are based on the definition proposed by Sommerville (2007), however it was adapted to our context, based upon the needs with feedback in risk identification stage.The following activities for RM should be performed: 1. Risk identification: it is possible to map the risks in the project, considering product and business risks identification; 2. Risk Documentation: identified risks are documented in order to provide the assessment of them; 3. Risk analysis: the likely to occur and the consequences of these risks are assessed; 4. Risk planning: plans to address the risk either by avoiding it or minimizing its effects on the project are drawn up; 5. Risk monitoring: the risk is constantly assessed and plans for mitigation are revised as more information about the risk becomes available.
These activities compose the base for the RM model proposed in our metamodel in a way that may support an automated risk management strategy.Figure 12 shows the functionalities encompassed by the RM model.According to the RM model, the risks are identified and then their main characteristics are documented.The characteristics are: the risk description, type, status, mitigation strategy, and contingency plans.In addition, as the RM process is a continuous activity, it is necessary to keep track of the history about the management of these risks.Thus, the risks' likelihood and impact are documented according to their occurrence, which can happen in different moments throughout the project development.It is important to emphasize that our approach to risk management should be performed in the essential activities of the SPL: Core Assets Development (CAD), Product Development (PD) and Management (M).

Implementing and validating the metamodel
In order to validate the metamodel, we have implemented a web tool where all the entities from the metamodel are provided and specialized in the tool for the company settings, and the intended metamodel traceability is fully supported.We implemented the tool using the Django4 framework, which enabled the fast development of a functional prototype.With Django implementation, we mapped the metamodel entities and their relationship within Python5 classes, and then a relational database for these entities is automatically created.Finally, Django generates a Web application where it is possible to test the mapping by inserting some test data -in our case, the documentation regarding features, requirements and so on.
After this initial application generated by Django, we can extend it by developing new functionalities for the tool.Currently, it is possible to use the tool to document all the assets regarding the metamodel, however the test cases derivation from use cases is not supported yet.Furthermore, the tool is able to produce feature models visualizations, as well as product maps and other type of project documentation.For example, there are several types of reports that can be generated, such as: features per modules/products; all the features, requirements and use cases per modules/products; and the traceability matrix among these different assets.
Additionally, the tool also aids in the inspection activity -static quality assurance activities carried out by a group composed by the authors of the artifacts, a reader and the reviewers -through the generation of different reports and providing a way to gather information about the change requests that should be performed in the inspected artifacts.Moreover, it is important to mention that the tool provides a bug tracker, as proposed by the metamodel, in order to manage the change requests.This also enables the tool to store all the historical data to be further reused and serve as lessons learned in project future activities.
Since the tool provides the traceability proposed in the metamodel, it has also a way to measure the impact analysis of each change request.For example, given a change in a use case, the user opens a change request referencing that asset in order to solve that problem, then the Change Control Board will investigate the change and assign a responsible to fix it.
As soon as someone starts to investigate the defect/enhancement, the tool can be asked to inform the impacted artifacts associated with that change in that specific use case.In this way, it can also help the decision regarding when a change should be done in the common platform or in a single SPL product.
The tool has been used inside the company mentioned in the initial sections, since July 2010.As previously stated, the project goal is to change their single software development process to a SPL process.The tool is currently being used by SPL consultants working embedded in the company to perform the scoping and requirements engineering phases.So far, it was documented 4 products, 9 modules, 97 features, 142 requirements and 156 use cases using the tool.In parallel, designing, implementation and testing are being started.

Others metamodels, approaches and tools
We searched the literature related work which addressed metamodels for SPL and/or approaches and tools derived from the metamodels.Hence, we briefly describe our findings in the following subsections.

Metamodels
In (Streitferdt, 2001), it is proposed a metamodel to integrate requirements to the feature model, such as the one proposed in (Kang et al., 1990).A requirement, in this case, is an indivisible piece of text describing some portion of the system to be developed.The requirements can be described hierarchically, thus achieving variability.Furthermore, the traceability among the entities is based on the metamodel itself.
In (Bachmann et al., 2003), a high level metamodel for representing variability in SPL is proposed.The major goal of the metamodel was to "separate out the representation of variability from the representation of various assets developed in the product development lifecycle while maintaining the traceability between them".
The authors in (Berg et al., 2005) proposed a conceptual variability model in order to address traceability of variations at different abstraction levels and across different generic artifacts of the SPL.To achieve that, it is proposed to represent the variability in a third dimension.
In such dimension, the variations points would be linked to the generic artifacts (such as requirements, use cases, architecture, etc.) to keep the traceability.
In (Bühne et al., 2005), a metamodel is described to structure variability information across different SPLs.It also based the metamodel in a set of requirements to document requirements variability.Moon et al. (2007) introduced two metamodels representing domain requirements and domain architecture with variability, and the traceability between these artifacts are based upon the metamodel.

Approaches and tools
In (Dhungana et al., 2007), it is briefly described an integrated tool support to develop SPL.Such tool follows some requirements, such as: Domain-specific adaptations, Mining existing assets, Involving multiple teams, Project-specific adaptations, Support for product derivation, Capturing new requirements during derivation, and Supporting product line evolution.However, it is not discussed the metamodel behind it.
Alférez et al. ( 2008) proposed a model-driven approach for linking features and use cases, along with its activities, and an example about how to apply the approach was showed.The authors did not differentiate between requirements model and use case model, and it is not explicitly described how the flows and sub-flows of the use cases should be handle.
Jirapanthong & Zisman (2009) presented the XTraQue, which is a rule-based approach to support automatic generation of traceability relations.In the approach, the feature model, use cases and some design documents are represented using XML.Thus, the approach extracts the relationships from these documents automatically using predefined rules.

19
Handling Variability and Traceability over SPL Disciplines

www.intechopen.com
Software Product Lines -The Automated Analysis As it can be seen, the literature basically proposes metamodels or techniques that address only a specific portion of SPL development.In addition, traceability and variability are not always considered together, or the description and the details of them are very simplified.Thus, the main difference between the previous described work and our proposal, is that we present a metamodel, and the implementation of it, for SPL development concerning variability and traceability aspects together along the early phases of SPL, and providing a level of details that simplifies the adoption of the metamodel.Furthermore, the tool that implements our metamodel is currently being used in a industrial project.

Conclusion and future work
In this chapter, it was proposed a metamodel for Software Product Lines that encompasses several phases of a SPL development, representing the interactions among the assets of a SPL, developed in order to provide a way of managing traceability and variability, and its initial validation inside a private company.The metamodel was built based upon a real-world SPL project being conducted in a private software company from Brazil.The organization works in the healthcare management systems domain, and have essentially four products, counting a total of 102 modules (sub-domains), with encompass about 840 features.
The phases currently supported by the metamodel include: scoping, requirements engineering, and tests.Additionally, the metamodel also supports different management aspects of a SPL project.For example, in the current version of the metamodel it is possible to manage different SPL projects concerning the staff, phases and activities, and it is proposed a model for managing risks in SPL.
In the way that we conceived the metamodel, the assets are treated as first-class citizens, which means that we can trace the linkage of any asset to others.Furthermore, treating assets as first-class citizens in our metamodel also enables a set of issues: to keep different versions of the same asset concerning different products in the SPL; to keep the history of assets modifications; to associate any metrics to assets; and it is also possible to manage the defects for different versions of the assets.Furthermore, by incorporating the management model, it is also possible to keep track of different assets and their responsible.
Although the metamodel was conceived to represent the SPL project for a specific company, in which we have been working jointly, it was built to be adaptable to other contexts.For example, the metamodel can be easily changed to support single system development by removing SPL specific entities.
For future work, we intend to extend the metamodel to support more aspects of SPL development.Specifically, we are planning to extend the model for metrics management, detailed software configuration aspects, integrate a model for SPL architecture, and establish mechanisms to link all these artifacts to source code.
We also plan to provide some way to enable the products derivation.The reuse between different SPLs (Bühne et al., 2005) is also intended to be implemented in future releases of the metamodel.In addition, formalized evaluations will be performed, that consider aspects of empirical software engineering, in order to assess the metamodel effectiveness.Finally, the prototype initially created to support the metamodel should be evolved, as well as formally validated.

20
Software Product Line -Advanced Topic www.intechopen.com

Furthermore, the
Fig. 4. Overview of the proposed SPL metamodel.

11Handling
Variability and Traceability over SPL Disciplines   www.intechopen.com

Fig. 9 .
Fig. 9. Dependency between test objective and test cases considering variability.
Consider a hypothetical situation in which there are two variation points, the first representing an optional feature (white diamond), and the second representing an alternative feature (black diamond), as depicted by the diagram shown in Figure 10.This diagram represents five possible scenarios: (1) [A-B-C-D], (2) [A-B-C-D-E-F], (3) [A-B-C-D-E-G], (4) [A-E-F], (5) [A-E-G].