Model-Driven Engineering (MDE) advocates the use of different modelling formalisms during software development, so that the most appropriate modelling notation at the right level of abstraction can be chosen to describe and reason about the system under development. In Concern-Orientation, software systems are built with reusable artifacts called concerns. A concern is a new model-based unit of reuse encapsulating software artifacts pertaining to a domain of interest that span multiple development phases and levels of abstraction [1]. Hence, various modelling notations are used to describe a concern covering structural, behavioural, and other properties as required by the domain of interest. However, a concern always uses (i) feature models [2] to capture the reusable variants/solutions provided by the concern and (ii) impact models to capture the impact of a selection of features on system qualities.
This tool demonstration focuses on the impact models of concerns, which are based on goal modelling technology [3], [4], [5] and depend on the selection of features. A different feature selection may result in drastically different impacts on system qualities. Concern-Orientation aims to address a shortcoming of popular reusable artifacts, such as Java libraries or components, which excel in defining an API or required/provided interfaces that allow the reusable artifact to be used, but fail when it comes to describing which reusable artifact should be chosen over another reusable artifact. A developer typically has to discover the advantages and disadvantages of candidate reusable artifacts by going through documentation, blogs, and tutorials. In Concern-Orientation, this knowledge is captured in the impact model of a concern.
Concern-Orientation advocates the reuse of smaller, lowerlevel concerns to build larger, higher-level concerns leading to a reuse hierarchy consisting of concerns differing in size, abstraction level, and complexity. When a concern is reused, the impacts of selected features on system qualities must consequently be connected to the impacts of the reusing concern, so that eventually the whole system can be analyzed. The connected impacts must allow for the propagation of evaluation values from lower-level goal models to higherlevel goal models based on the selection of variations from different levels in the reuse hierarchy. This tool demonstration reports on such an evaluation mechanism in the requirements engineering tool jUCMNav [6] and the software design tool TouchCORE [7]. Both tools provide integrated support for Concern-Orientation based on a common metamodel [8]. Out of the many tool demonstrations for jUCMNav, TouchCORE, and its predecessor TouchRAM, there are three demonstrations that are most relevant to this demonstration. At RE 2014, combined reasoning of goal and feature models was presented with jUCMNav [9]. At MODELS 2014, a demonstration showcased how jUCMNav and TouchRAM have been integrated to provide initial support for Concern-Orientation [8]. At Modularity 2015, the TouchCORE tool was demoed for the first time, focusing on feature modelling and traceability in the context of Concern-Orientation [10]. However, the evaluation of impact models across levels in reuse hierarchies, i.e., across concern boundaries, has not been demonstrated before.
Section II gives a brief overview of the evaluation of goal models and outlines which challenges need to be addressed for the evaluation of goal models in reuse hierarchies. Section III describes the required changes to the jUCMNav and TouchCORE tools in support of goal model evaluation in reuse hierarchies, while the last section concludes the paper and discusses future work.
Goal modelling notations such as the NFR Framework [3], the Goal-oriented Requirement Language (GRL), which is part of the User Requirements Notation [4], or i* [5] support reasoning about goals and system qualities through propagationbased evaluation mechanisms. Such evaluation mechanisms propagate user-defined initial satisfaction values from lowerlevel goal model elements-typically leaf nodes-to those of higher-level goal model elements. Both jUCMNav and TouchCORE use goal modelling technology based on GRL. In the context of Concern-Orientation, lower-level goal model elements are typically features of the concern (i.e., the different variations offered by the concern) and higher-level goal model elements describe system qualities. Furthermore, the initial satisfaction value of a feature is either the minimum possible (i.e., 0 in our case) if the feature is not selected and the maximum possible (i.e., 100 in our case) if the feature is selected.
There are three challenges that need to be addressed to enable propagation-based evaluation across concern boundaries in a reuse hierarchy.
a) Distributed Impact Models: Existing propagationbased evaluation mechanisms assume that a goal model is contained in one module and not distributed over the impact models of several reusable concerns. Using existing goal modelling concepts, one could theoretically create a single, monolithic impact model that contains the individual impact models from all levels in the reuse hierarchy. While this would defeat the purpose of having multiple, reusable modules in the first place, there is a second reason why this is problematic. This monolithic impact model would have to be able to dynamically discount impacts from lower-level concerns, if the feature that is reusing the lower-level concern is currently not selected. This is not easily possible with standard goal modelling concepts. We therefore introduced a new goal modelling element called the Feature Impact Node [11], which aggregates the impacts of reused concerns and the reusing feature, takes into account whether the reusing feature is selected or not to actually propagate upwards its satisfaction value, and still respects concern boundaries. An improved evaluation mechanism for Concern-Orientation has to properly take into account Feature Impact Nodes.
b) Distributed Specification of Initial Satisfaction Values: At the time Authorization reuses Authentication, the developer of Authorization cannot fully select all necessary features in Authentication. For example, the Password feature and the Facial Recognition feature both work for what Authorization wants to accomplish, but their impacts on system qualities cause the first selection to be preferable if cost is an issue and the other selection to be preferable if tighter security is an issue. However, the developer of Authorization is not in a position to make this decision, because this depends on the context of whoever is going to reuse Authorization (i.e., only the developer of the Bank in our case can determine that). Therefore, the developer of Authorization will only make a partial selection of features in Authentication and leave some features open to be selected by the developer of the Bank (i.e., the developer of Authorization is delaying some decisions to whoever is going to reuse Authorization).
In Fig. 1, the checkmarks indicate that the developer of Authorization selected the Access Blocking and Auto Logoff features from the Authentication concern, because the developer deemed them to be absolutely necessary for the purposes of Authorization. This decision may be debatable, but serves to illustrate a point with the example. The up arrows, on the other hand, indicate those feature that can still be selected by the developer of the Bank. Remember that feature selections are inputs to the impact model, which contain features as leaf nodes. Consequently, the user-defined initial satisfaction values corresponding to the selection of features are distributed over several concerns. Existing propagation-based evaluation mechanisms assume that this is not the case. To address this issue, we introduced the ability to specify a partial set of initial satisfaction values [11]. An improved evaluation mechanism for Concern-Orientation has to combine these partial sets into one set for each impact model before performing the evaluation of the impact model in the reuse hierarchy. For the NFR Framework, GRL, and i*, three types of contribution values are known: qualitative, quantitative, and real-life values. Qualitative values are too imprecise for use in Concern-Orientation, because they only differentiate features by limited shades of negative and positive contributions. Quantitative values are from a specific range (typically [-100,100]). In the context of Concern-Orientation, they are difficult to use, because one has to assume that many developers will build reusable concerns. If a developer of Concern A describes the impact on a system quality as 75 out of [-100,100] and a developer of Concern B describes the impact on the same system quality as 90 out of [-100,100], then there has to be an implicit understanding what these numbers mean. If not, the two concerns cannot be reused together, because the inconsistency in the contribution values would render the impact model analysis useless. Given that impacts need to be specified to vague system qualities such as user convenience, usability, or security, it is unlikely that such an understanding exists. The third option (real-life values) addresses this issue, because actual measurements from real-life are taken to characterize the impact on a system quality. While this addresses the inconsistency issue, it is not necessarily easy or cost-effective to capture such measurements. Therefore, we have devised a way to use relative contribution values [12]. This allows each developer to specify contribution values relative to all locally known impacts on a system quality. Furthermore, an improved evaluation mechanism for Concern-Orientation has to ensure that the satisfaction values, which are derived from the relative contribution values, are normalized to the [0,100] range, thus enabling the composition of impact models from different concerns. In addition, the normalization has to take constraints among impact model elements into account [12].
JUCMNAV AND TOUCHCORE jUCMNav is a requirements engineering tool that already offers significant support for the evaluation of impact models, but until now had little support for model reuse. TouchCORE, on the other hand, is a software design tool that is predominantly built in support of model-based reuse, and until now had no support for goal-oriented modelling. Consequently, different functionality had to be added to the tools to support distributed impact models, distributed specification of initial satisfaction values, and relative contribution values.
In the TouchCORE tool, support for impact modelling was implemented from scratch, taking best practices from GRL into account (e.g., a clear distinction between the impact model definition for a concern and views of those definitions, allowing the same impact model element to be shared among views focusing on one high-level system quality at a time). Fig. 2 depicts an impact model for improving the security of the Bank concern as defined in the TouchCORE tool. The contributions are defined with relative values and four new Feature Impact Nodes (FINs) are used in the impact model. Each FIN is related to exactly one feature of the Bank concern as shown in the top row of the FIN. Each additional row of a FIN represents a reused impact model element from another concern. The numbers in each row describe the relative impact of the reused impact model elements and the feature itself.
In jUCMNav, the concept of a Reuse Link was introduced to allow impact model elements from a reusable concern to be used in the impact model of the reusing concern. A Reuse Link is illustrated as a dashed arrow in Fig. 3, which shows the same impact model from Fig. 2 as it is visualized in the jUCMNav tool. Note how each FIN is not represented with a rectangle as in TouchCORE, but is visualized with goal model elements that are already supported by jUCMNav (the representation used by TouchCORE may also be implemented for jUCMNav in the future). For example, the two goals The evaluation of impact models in a reuse hierarchy uses an algorithm that starts at the topmost impact model and then recursively evaluates all impact models of reused elements before evaluating the impact model with the reused elements. Feature selections from various levels in the reuse hierarchy are combined as needed. Fig. 3 shows the result of an evaluation of impact models in a reuse hierarchy with the contribution values as well as satisfaction values after normalization (e.g., the 1 and 10 from the Internet Banking Interaction FIN in Fig. 2 are translated into a 9 and 91 on the [0,100] scale in Fig. 3).
For the normalization of satisfaction values calculated with relative contribution values, the improved evaluation mechanism needs to check whether any constraints among features are violated given a specific feature selection. This is accomplished with the help of the FAMILIAR tool [13] [14], which uses a SAT solver to verify whether constraints in a feature model are violated.
This tool demonstration showcases support for the evaluation of impact models of reusable concerns in a reuse hierarchy in two tools: jUCMNav-a requirements engineering tool with a long history in goal-based modelling, and TouchCOREa software design tool with a long history in model-based reuse. In Concern-Orientation, the impact of a concern's features on system qualities is captured in a specialized goal model called impact model. With the new support, it is now possible to evaluate the combined impact of all concerns in a reuse hierarchy to enable system-wide trade-off analysis of candidate feature selections across concern boundaries. This is an improvement over existing propagation-based evaluation mechanisms for goal models, which typically assume a monolithic goal model with a centralized specification of initial satisfaction values. In addition, it is now possible to specify relative contribution values in impact models. In the future, we will consider extending impact models (i) with other goal modelling concepts such as actor (for the modelling of intentions of stakeholders) and indicator (for the modelling of real-life measurements) and (ii) with better support for taking contextual information from the reusing concern into account in the impact model of the reused concern.