Injecting quality attributes into software architectures with the common variability language

Abstract

Quality attributes that add new behavior to the functional software architecture are known as functional quality attributes (FQAs). These FQAs are applied to pieces of software from small components to entire systems, usually crosscutting some of them. Due to this crosscutting nature, modeling them separately from the base application has many advantages (e.g. reusability, less coupled architectures). However, different applications may require differ-ent configurations of an FQA (e.g. different levels of secu-rity), so we need a language that: (i) easily expresses the variability of the FQAs at the architectural level; and that (ii) also facilitates the automatic generation of architectural configurations with custom-made FQAs. In this sense, the Common Variability Language (CVL) is extremely suited for use at the architectural level, not requiring the use of a particular architectural language to model base functional requirements. In this paper we propose a method based on CVL to: (i) model separately and generate FQAs cus-tomized to the application requirements; (ii) automatically inject customized FQA components into the architecture of the applications. We quantitatively evaluate our approach and discuss its benefits with a case study.

Context‐dependent reconfiguration of autonomous vehicles in mixed traffic

“…Specifically, each variation point (dashed line) defines a transformation (eg, object existence, object substitution, and parameter assignment) in the software architecture that will be executed by the CVL engine when a particular configuration is selected in the variability model, adapting the components of the autonomous vehicle. () For example, when the context changes because the vehicle joins a motorway, a new configuration is generated: The new context is selected in the tree, and the IDM model is automatically selected in the configuration due to the cross‐tree constraints defined in OCL. The CVL engine will resolve the variability, changing the IDM component to be the car‐following model in the autonomous vehicle.…”

“…4 The bottom half of Figure 1 defines a transformation (eg, object existence, object substitution, and parameter assignment) in the software architecture that will be executed by the CVL engine 37 when a particular configuration is selected in the variability model, adapting the components of the autonomous vehicle. 38,39 For example, when the context changes because the vehicle joins a motorway, a new configuration is generated: The new context is selected in the tree, Each configuration of the controller is a set of choices in the variability model (features in grey in Figure 1). In our approach, we first generate a particular configuration of the reconfigurable vehicle controller agent, which is able to detect changes in weather conditions (rain intensity) and evaluate the traffic quality based on the selected indicators of safety (time to collision, post-encroachment time) and efficiency (travel time).…”

An automatic process for weaving functional quality attributes using a software product line approach

“…Another advantage of CVL is that the complete variability model of the FQAs can be divided and modularised in different levels of detail and thus, it is possible to model each FQA separately in different variability models (like Security in Figure 5) and then relate those models defining a complete variability model, that includes all the FQAs, with their dependency relationships (i.e., the interFQAs-dependencies) (see Figure 4). The CVL variability models of other FQAs are detailed in [14].…”

“…By combining SPL and aspect-oriented software development (AOSD) technologies, we have defined a generic process to: (i) specify and model the variability and dependencies among FQAs, defining a reusable family of FQAs; (ii) customise the FQAs to fulfil the application requirements and automatically generate an architectural configuration of FQAs; and (iii) weave the customised FQAs into the software architecture of the base application without manually modifying it. We present and compare two instantiations of our generic process using different variability languages and architecture description languages: 1) with feature models and AO-ADL, an aspect-oriented architecture description language [12,13]; and 2) using the Common Variability Language (CVL) and a MOF-compliant language such as UML [14]. We illustrate our approach with an evoting case study and quantitatively evaluate both approaches by using suitable metrics (degree of dependency, variability, automation, separation of concerns) to assess the benefits of each approach.…”

Towards the dynamic reconfiguration of quality attributes

“…However, although SPLs are traditionally used to exploit and handle the commonalities and variations of the base functionality of the applications, QAs variability has not received as much attention (Etxeberria et al 2007), and there is a lack of existing approaches that integrate QA variability as a part of the systematic variability management of SPLs (Myllärniemi et al 2012). In this paper, we follow our previous approach (Horcas et al 2014a) to model the variability of the QAs separately from the base application variability. Separately modelling the variability of the QAs from the variability of the base application has many advantages such as a better reusability of both the QAs and the applications.…”