Modelling variability in software product lines (SPL) development is receiving a lot of attention in current years, building on the idea that product derivation could be automatically derived from a product line through model transformations. Software Product Line development involves the explicit management of variability that has to be encompassed by the software artifacts, in particular by the software architecture. This variability has to be supported and represented by the architecture. The Common Variability Language (CVL) allows to represent such variability independently of the Architecture Description Language (ADL). In this research work we define a set of model transformations to support the resolution of the product architecture variability in an automated way by using the Atlas Transformation Language (ATL). The transformation takes as input a multimodel which allows us to represent the relationships between the external variability, represented by a feature model, the architectural variability, represented by the CVL model, and the non-functional requirements, represented in a quality model and generates as output the CVL resolution model that represents the product architecture's variability resolution.
iability of domain artifacts that is hidden from customers" [2]. Both external and internal variability are important to the success of developing software artifacts. However, external variability deserves special attention as it is visible to users and relates to requirements defined at early development stages where errors or inaccuracies are relatively inexpensive and easy to detect and correct.
In SPL software architectures play a dual role: on the one hand, the product line architecture (PLA) should provide variation mechanisms which will help us to achieve a set of allowed variations, and on the other hand, the derived product architecture (PA) from the PLA by exercising its built-in architectural points [1].
For enabling the automatic resolution of the PLA variability is required not only that the architectural description languages provide variation mechanisms, but also to explicitly represent how the different variants realize the external variability usually represented in feature models.
The Common Variability Language (CVL) [3] is a language that allows the specification of variability over any EMF-based model, and supports the automatic resolution of the variability and the derivation of resolved models. In CVL approach, we can distinguish three models: i) The base model, which is a model described in a Domain Specific Language; ii) The variability model, which is the model that defines variability on the base model; iii) The resolution model, that describes how the variability has been resolved with the aim to create a new model in the base DSL.
For a given base model, we can derive several resolution models, that, through a generic CVL model-to-model transformation can generate the product specific models, which conforms to the base DSL.
CVL incorporates its own variability mechanisms, and concepts like type, composite variability, constraint and iterator, will help us to mimic feature diagrams. Moreover, there are lower level concepts (e.g., fragment substitution, object existence) that can be used to extend those provided by the Architectural description languages (ADLs).
The main goal of this research work is the development of ATL model transformations which will allow us to automate the resolution of variability on PLAs, obtaining the CVL resolution models of the architecture of the product under development. These transformations take as input a product configuration which comprises not only functional but also non-functional requirements (NFRs).
Such transformations are developed by using ATL [4], an imperative-declarative language, based in OCL and developed by ATLAS group in response to the QVT standard from the OMG. Once obtained the CVL resolution models will be used to obtain the PA through a CVL model transformation. 2
In a Software Product Line (SPL) scenario it is difficult to manage the derivation of the architectural specification of a product (PA), especially when the SPL allows a wide range of variability. CVL has been used in several approaches to support the resolution of the architectural variability and the derivation of product architectures in SPL development (e.g., [5], [6], [7])
Nascimento et al. [5] present an approach for defining product line architectures using CVL. They apply the Feature-Architecture Mapping Method (FArM) to filter the feature models in order to consider only the architectural-related features. These features will form the CVL specification that will allow obtaining the COSMOS* architectural models. They do not define relationships between the external variability model (features model) and the architectural variability expressed in CVL and thus the derivation of the product architecture taking as input the configuration is not supported. They explicitly omit the non-functional requirements when applying the FArM method.
Svendsen et al.[6] present the applicability of CVL for obtaining the product models for a Train Control SPL that are defined using a DSL. They only consider the explicit definition of the internal variability and consequently, the configuration should be made directly over the CVL specification of the internal variability.
Combemale et al. [7] present an approach to specify and resolve variability on Reusable Aspect Models (RAM), a set of interrelated design models. They use CVL to resolve the variability on each model and then compose the corresponding reusable aspects by using the RAM weaver. They also consider just the internal variability, and the configuration should be made over the CVL specification.
Summarizing, the approaches described above do not establish relations among the SPL external variability and the architectural variability nor consider non-functional requirements in the process. The establishment of connections between the SPL external variability, the non-functional requirements, represented in a quality model, and the architectural variability, represented by using CVL allows us to automatically solve the architectural variability by using ATL model transformations. 3
Our approach for the automatic resolution of the PLA in architectural models through ATL transformation is supported by the use of a multimodel [8, 9] that allows the explicit representation of relationships among entities in different viewpoints. The problem of representing and automatically resolving the architectural variability taking into account functional and non-functional requirements requires (at least) three viewpoints: The variability viewpoint represents the SPL external variability expressing the commonalities and variability within the product line. It has a main element, feature, expressed by means of a variant [10] of the cardinality found in the feature model. The architectural viewpoint represents the architectural variability of the Product Line architecture that realizes the external variability of the SPL expressed in the variability viewpoint. It is expressed by means of the Common Variability Language (CVL) and its main element is the Variability Specification (VSpec) [3]. The quality viewpoint represents the hierarchical decomposition of quality into sub-characteristics, quality attributes, metrics and the impacts and constraints among quality attributes. It is expressed by means of a quality model for software product lines [11], that allows the representation of NFRs as constraints.
Fa
VSpeca
child
VSpecb Fa isRealizedBy
CVLdomain
NFRi isRealizedBy
In the multimodel we can also specify how a given feature is_realized_by [12] a set of VSpecs or how a given NFR is_realized_by [12] a set of VSpecs or how a given VSpec impacts [8] positively or negatively on a quality attribute.
By using the multimodel and the product configuration, which comprises features and NFRs that the product must fulfill together with the quality attributes priorities, in this research work we focus on the definition of a set of ATL model transformation to support the resolution of the architectural variability and the automatic generation of CVL resolution models.
The quality attribute priorities together with the impacts that VSpecs have on the quality attributes are used to choose from a set of architectural variants that having the same functionality differ in their quality attribute levels. Fig. 1 shows the structure of the ATL transformation rules. Although the transformations have been defined using ATL, Fig. 1 shows the structure using QVT [13] graphical syntax due to clarity and simplicity reasons. Fig. 1(a) shows how we use the is_realized_by relationship between features and VSpec to positively resolve the VSpecb when we select Fa in the configuration. Fig. 1(b) shows how we use the is_realized_by relationship between NFRs and VSpec to positively resolve the VSpecb when we select NFRis in the configuration. Similarly, we positively resolve a given VSpec when it is the alternative that best fits the quality attributes priorities combined with the the impact relationships between VSpecs and quality attributes by implementing the AHP [14] method. (a) SelectedFeatureToSelectedVSpec
EVSpeca (b) SelectedNFRToSelectedVSpec
EVSpeca when VSpeca.resolution=true; when VSpeca.resolution=true;
These transformations are tested in an automotive case study for obtaining the product architecture of vehicle control systems1. Fig. 2 shows an excerpt of an example of the CVL resolution model generation of this case study. The configuration consists on the following features: ABS, Traction control, Stability Control and Cruise Control and a prioritized quality attribute: Latency Time. This Cruise Control feature can be realized by two different architectural variants Simple (which impacts positively on Latency Time) and Adaptive (which impacts negatively on Latency Time). The transformation process positively resolves SimpleCruisseControl System VSpec since has a positive impact on the prioritized quality attributes. 1 The whole specification of the case study is available for download at: http://users.dsic.upv.es/~jagonzalez/CarCarSPL/links.html
VSpecResolution
CVLdomain EVSpecb
MMdomain
VSpeca VSpecb [1.1]
ABS Attributes [0.1] TractionControl Attributes [0.1] EstabilityControl Attributes
[0.1] CruiseControl
Attributes isRealizedBy
VVSSppeecc34 VSpec41 impact -70 AdaptativeCruisseControl System
VVSSppeecc34 VSpVeScp3e1c2 impact +50 SimpleCruisseControl System
VVSSppeecc34
VSpVeScp2e1c2 EstabilityControl System
VVSSppeecc34 VSpVeScp1e1c2 CVL resolution model
generation isRealizedBy
VSpVeScVp1VSeSpcp2eecc34 TractionControl System isRealizedBy
ABS Control System
GPS Attributes Feature
Feature Group
Mandatory Optional
Legend
Implies Qa AQtturiabliutyte
These ATL transformations will be also employed in a cloud system service context, with the purpose of performing cloud applications derivation from other existing cloud services that incorporate variability. This variability could respond to the existence of multiple services with the same functionality and different non-functional properties, or because the very same services still include the variability through configuration interfaces. The transformation generates as out choreography and orchestration models of our new service.
At the moment, we are not providing a full coverage of CVL language. We are now focusing on the Fragment Substitution and Object Substitution variability types [15] to express the architectural variability. 4
We have presented our approach to automatically derive the CVL resolution models for a given product configuration by using an ATL transformation.
We also show how quality assurance techniques can be introduced in SPL product architecture derivation, and how the Model Driven Software Development principles are going to help us to resolve the automatic resolution of variability in product line architectures. A model transformation chain (ATL+CVL transformations) allow us to obtain the first version of the architecture of the product under development.
We are now working on the test of the ATL transformations in real scenarios and on the integration with the CVL supporting tool so as to enable the CVL transformation that generates the models that represent the architecture of the product under development. We also plan to incorporate other CVL variation mechanisms that will enrich the expressiveness of the architectural variability.