=Paper=
{{Paper
|id=Vol-1554/PD_MoDELS_2015_paper_10
|storemode=property
|title=Support for Evaluation of Impact Models in Reuse Hierarchies with jUCMNav and TouchCORE
|pdfUrl=https://ceur-ws.org/Vol-1554/PD_MoDELS_2015_paper_10.pdf
|volume=Vol-1554
|authors=Romain Alexandre,Cécile Camillieri,Mustafa Berk Duran,Aldo Navea Pina,Matthias Schöttle,Jörg Kienzle,Gunter Mussbacher
|dblpUrl=https://dblp.org/rec/conf/models/AlexandreCDPSKM15
}}
==Support for Evaluation of Impact Models in Reuse Hierarchies with jUCMNav and TouchCORE==
https://ceur-ws.org/Vol-1554/PD_MoDELS_2015_paper_10.pdf
Support for Evaluation of Impact Models in Reuse
Hierarchies with jUCMNav and TouchCORE
Romain Alexandre⇤ , Cécile Camillieri⇤ , Mustafa Berk Duran† ,
Aldo Navea Pina† , Matthias Schöttle‡ , Jörg Kienzle‡ , and Gunter Mussbacher†
⇤ Polytech Nice Sophia, Université de Nice, France
{romain.alexandre | cecile.camillieri}@polytech.unice.fr
† Department of Electrical and Computer Engineering, McGill University, Montreal, QC, Canada
{berk.duran | aldo.naveapina}@mail.mcgill.ca, gunter.mussbacher@mcgill.ca
‡ School of Computer Science, McGill University, Montreal, QC, Canada
Matthias.Schoettle@mail.mcgill.ca, Joerg.Kienzle@mcgill.ca
Abstract—In Concern-Orientation, software systems are built be used, but fail when it comes to describing which reusable
with the help of reusable artifacts called concerns, leading to reuse artifact should be chosen over another reusable artifact. A
hierarchies, because higher-level concerns may reuse lower-level developer typically has to discover the advantages and dis-
concerns. At each level in the reuse hierarchy, a concern uses goal
modelling techniques to describe the impact of selected variations advantages of candidate reusable artifacts by going through
from the concern on system qualities such as performance, cost, documentation, blogs, and tutorials. In Concern-Orientation,
and user convenience. To reason about trade-offs among system this knowledge is captured in the impact model of a concern.
qualities in the whole system, the individual goal models from all Concern-Orientation advocates the reuse of smaller, lower-
levels in the reuse hierarchy have to be considered together. This level concerns to build larger, higher-level concerns leading
requires the ability to select variations from different levels in
the reuse hierarchy, to connect impacts from lower levels to those to a reuse hierarchy consisting of concerns differing in size,
at higher levels, and eventually to propagate the evaluation of abstraction level, and complexity. When a concern is reused,
lower-level goal models to higher-level goal models based on the the impacts of selected features on system qualities must
selection of variations. This tool demonstration reports on such consequently be connected to the impacts of the reusing
an evaluation mechanism for two tools that provide integrated concern, so that eventually the whole system can be analyzed.
support for Concern-Orientation: the requirements engineering
tool jUCMNav and the software design tool TouchCORE. The connected impacts must allow for the propagation of
evaluation values from lower-level goal models to higher-
I. I NTRODUCTION level goal models based on the selection of variations from
Model-Driven Engineering (MDE) advocates the use of dif- different levels in the reuse hierarchy. This tool demonstration
ferent modelling formalisms during software development, so reports on such an evaluation mechanism in the requirements
that the most appropriate modelling notation at the right level engineering tool jUCMNav [6] and the software design tool
of abstraction can be chosen to describe and reason about the TouchCORE [7]. Both tools provide integrated support for
system under development. In Concern-Orientation, software Concern-Orientation based on a common metamodel [8]. Out
systems are built with reusable artifacts called concerns. A of the many tool demonstrations for jUCMNav, TouchCORE,
concern is a new model-based unit of reuse encapsulating and its predecessor TouchRAM, there are three demonstrations
software artifacts pertaining to a domain of interest that span that are most relevant to this demonstration. At RE 2014,
multiple development phases and levels of abstraction [1]. combined reasoning of goal and feature models was presented
Hence, various modelling notations are used to describe a with jUCMNav [9]. At MODELS 2014, a demonstration show-
concern covering structural, behavioural, and other properties cased how jUCMNav and TouchRAM have been integrated
as required by the domain of interest. However, a concern to provide initial support for Concern-Orientation [8]. At
always uses (i) feature models [2] to capture the reusable Modularity 2015, the TouchCORE tool was demoed for the
variants/solutions provided by the concern and (ii) impact first time, focusing on feature modelling and traceability in the
models to capture the impact of a selection of features on context of Concern-Orientation [10]. However, the evaluation
system qualities. of impact models across levels in reuse hierarchies, i.e., across
This tool demonstration focuses on the impact models of concern boundaries, has not been demonstrated before.
concerns, which are based on goal modelling technology [3], Section II gives a brief overview of the evaluation of goal
[4], [5] and depend on the selection of features. A different models and outlines which challenges need to be addressed
feature selection may result in drastically different impacts for the evaluation of goal models in reuse hierarchies. Sec-
on system qualities. Concern-Orientation aims to address a tion III describes the required changes to the jUCMNav and
shortcoming of popular reusable artifacts, such as Java li- TouchCORE tools in support of goal model evaluation in reuse
braries or components, which excel in defining an API or hierarchies, while the last section concludes the paper and
required/provided interfaces that allow the reusable artifact to discusses future work.
II. S HORTCOMINGS OF P ROPAGATION -BASED
E VALUATION OF G OAL M ODELS
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 rea-
soning about goals and system qualities through propagation-
based evaluation mechanisms. Such evaluation mechanisms
propagate user-defined initial satisfaction values from lower-
level 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 Figure 1. Combined Feature Model of Reuse Hierarchy with Three Levels
of Concerns (Dynamically Visualized with TouchCORE)
(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. at the third level in the reuse hierarchy. Consequently based on
There are three challenges that need to be addressed to en- this reuse hierarchy, Authorization first reuses Authentication,
able propagation-based evaluation across concern boundaries and in turn Authorization is then reused by the Bank.
in a reuse hierarchy. At the time Authorization reuses Authentication, the devel-
a) Distributed Impact Models: Existing propagation- oper of Authorization cannot fully select all necessary features
based evaluation mechanisms assume that a goal model is in Authentication. For example, the Password feature and the
contained in one module and not distributed over the impact Facial Recognition feature both work for what Authorization
models of several reusable concerns. Using existing goal wants to accomplish, but their impacts on system qualities
modelling concepts, one could theoretically create a single, cause the first selection to be preferable if cost is an issue
monolithic impact model that contains the individual impact and the other selection to be preferable if tighter security is
models from all levels in the reuse hierarchy. While this would an issue. However, the developer of Authorization is not in a
defeat the purpose of having multiple, reusable modules in the position to make this decision, because this depends on the
first place, there is a second reason why this is problematic. context of whoever is going to reuse Authorization (i.e., only
This monolithic impact model would have to be able to the developer of the Bank in our case can determine that).
dynamically discount impacts from lower-level concerns, if Therefore, the developer of Authorization will only make a
the feature that is reusing the lower-level concern is currently partial selection of features in Authentication and leave some
not selected. This is not easily possible with standard goal features open to be selected by the developer of the Bank (i.e.,
modelling concepts. We therefore introduced a new goal the developer of Authorization is delaying some decisions to
modelling element called the Feature Impact Node [11], which whoever is going to reuse Authorization).
aggregates the impacts of reused concerns and the reusing In Fig. 1, the checkmarks indicate that the developer of
feature, takes into account whether the reusing feature is Authorization selected the Access Blocking and Auto Logoff
selected or not to actually propagate upwards its satisfaction features from the Authentication concern, because the devel-
value, and still respects concern boundaries. An improved oper deemed them to be absolutely necessary for the purposes
evaluation mechanism for Concern-Orientation has to properly of Authorization. This decision may be debatable, but serves
take into account Feature Impact Nodes. to illustrate a point with the example. The up arrows, on the
b) Distributed Specification of Initial Satisfaction Values: other hand, indicate those feature that can still be selected by
Fig. 1 combines three levels of concerns in a reuse hierarchy the developer of the Bank. Remember that feature selections
into one feature model. At the top, the features of a Bank are inputs to the impact model, which contain features as
concern are shown with white background. Directed dotted leaf nodes. Consequently, the user-defined initial satisfaction
arrows in the feature model indicate the reuse of a concern. values corresponding to the selection of features are distributed
The Authorization concern is reused in total three times: by over several concerns. Existing propagation-based evaluation
the Internet Banking Interaction feature, the ATM Interaction mechanisms assume that this is not the case. To address this
feature, and the Vault feature. In addition, the Camera and issue, we introduced the ability to specify a partial set of initial
Sensor concerns are also reused by the Vault feature. The satisfaction values [11]. An improved evaluation mechanism
Authorization, Camera, and Sensor concerns are hence at the for Concern-Orientation has to combine these partial sets
second level in the reuse hierarchy. The Authorization concern into one set for each impact model before performing the
itself reuses the Authentication concern, i.e., Authentication is evaluation of the impact model in the reuse hierarchy.
Figure 2. Reuse of Impact Model Elements in TouchCORE
c) Relative Contribution Values: The third issue is or- the normalization has to take constraints among impact model
thogonal to the first two already mentioned ones. It is related elements into account [12].
to the use of relative contribution values in impact models. In
III. E VALUATION IN R EUSE H IERARCHIES WITH
goal models, contribution values are defined for contribution
J UCMNAV AND T OUCH CORE
links that connect goal model elements and propagate the
satisfaction values of source elements to a parent element with jUCMNav is a requirements engineering tool that already
a weighted sum approach. offers significant support for the evaluation of impact models,
but until now had little support for model reuse. TouchCORE,
For the NFR Framework, GRL, and i*, three types of contri- on the other hand, is a software design tool that is predomi-
bution values are known: qualitative, quantitative, and real-life nantly built in support of model-based reuse, and until now
values. Qualitative values are too imprecise for use in Concern- had no support for goal-oriented modelling. Consequently,
Orientation, because they only differentiate features by limited different functionality had to be added to the tools to support
shades of negative and positive contributions. Quantitative distributed impact models, distributed specification of initial
values are from a specific range (typically [-100,100]). In satisfaction values, and relative contribution values.
the context of Concern-Orientation, they are difficult to use, In the TouchCORE tool, support for impact modelling was
because one has to assume that many developers will build implemented from scratch, taking best practices from GRL
reusable concerns. If a developer of Concern A describes the into account (e.g., a clear distinction between the impact
impact on a system quality as 75 out of [-100,100] and model definition for a concern and views of those definitions,
a developer of Concern B describes the impact on the same allowing the same impact model element to be shared among
system quality as 90 out of [-100,100], then there has views focusing on one high-level system quality at a time).
to be an implicit understanding what these numbers mean. Fig. 2 depicts an impact model for improving the security
If not, the two concerns cannot be reused together, because of the Bank concern as defined in the TouchCORE tool. The
the inconsistency in the contribution values would render the contributions are defined with relative values and four new
impact model analysis useless. Given that impacts need to be Feature Impact Nodes (FINs) are used in the impact model.
specified to vague system qualities such as user convenience, Each FIN is related to exactly one feature of the Bank concern
usability, or security, it is unlikely that such an understand- as shown in the top row of the FIN. Each additional row of a
ing exists. The third option (real-life values) addresses this FIN represents a reused impact model element from another
issue, because actual measurements from real-life are taken concern. The numbers in each row describe the relative impact
to characterize the impact on a system quality. While this of the reused impact model elements and the feature itself.
addresses the inconsistency issue, it is not necessarily easy In jUCMNav, the concept of a Reuse Link was introduced
or cost-effective to capture such measurements. to allow impact model elements from a reusable concern to
Therefore, we have devised a way to use relative contribu- be used in the impact model of the reusing concern. A Reuse
tion values [12]. This allows each developer to specify contri- Link is illustrated as a dashed arrow in Fig. 3, which shows
bution values relative to all locally known impacts on a system the same impact model from Fig. 2 as it is visualized in the
quality. Furthermore, an improved evaluation mechanism for jUCMNav tool. Note how each FIN is not represented with
Concern-Orientation has to ensure that the satisfaction values, a rectangle as in TouchCORE, but is visualized with goal
which are derived from the relative contribution values, are model elements that are already supported by jUCMNav (the
normalized to the [0,100] range, thus enabling the compo- representation used by TouchCORE may also be implemented
sition of impact models from different concerns. In addition, for jUCMNav in the future). For example, the two goals
Figure 3. Evaluation of Impact Models with Reuse Hierarchy in jUCMNav
Improve Operational Security (Internet Banking Interaction) initial satisfaction values. In addition, it is now possible to
and Internet Authorization.Improve Security as well as the specify relative contribution values in impact models. In the
feature Internet Banking Interaction correspond to the leftmost future, we will consider extending impact models (i) with other
rectangle in Fig. 2. goal modelling concepts such as actor (for the modelling of
The evaluation of impact models in a reuse hierarchy intentions of stakeholders) and indicator (for the modelling of
uses an algorithm that starts at the topmost impact model real-life measurements) and (ii) with better support for taking
and then recursively evaluates all impact models of reused contextual information from the reusing concern into account
elements before evaluating the impact model with the reused in the impact model of the reused concern.
elements. Feature selections from various levels in the reuse
R EFERENCES
hierarchy are combined as needed. Fig. 3 shows the result
of an evaluation of impact models in a reuse hierarchy with [1] O. Alam, J. Kienzle, and G. Mussbacher, “Concern-Oriented Software
Design,” in MODELS 2013, pp. 604–621, Springer, 2013.
the contribution values as well as satisfaction values after [2] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson, “Feature-
normalization (e.g., the 1 and 10 from the Internet Banking oriented domain analysis (FODA) feasibility study,” Tech. Rep.
Interaction FIN in Fig. 2 are translated into a 9 and 91 on the CMU/SEI-90-TR-21, SEI, CMU, November 1990.
[3] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, Non-Functional
[0,100] scale in Fig. 3). Requirements in Software Engineering. Springer, 2000.
For the normalization of satisfaction values calculated with [4] International Telecommunication Union (ITU-T), “Recommendation
relative contribution values, the improved evaluation mecha- Z.151 (10/12): User Requirements Notation (URN) - Language Defi-
nition,” approved October 2012.
nism needs to check whether any constraints among features [5] E. Yu, Modelling strategic relationships for process reengineering. PhD
are violated given a specific feature selection. This is accom- thesis, Department of Computer Science, University of Toronto, 1995.
plished with the help of the FAMILIAR tool [13][14], which [6] “jUCMNav Tool.” http://jucmnav.softwareengineering.ca/.
[7] “TouchCORE Tool.” http://touchcore.cs.mcgill.ca/.
uses a SAT solver to verify whether constraints in a feature [8] N. Thimmegowda, O. Alam, M. Schöttle, W. Al Abed, T. Di’Meco,
model are violated. L. Martellotto, G. Mussbacher, and J. Kienzle, “Concern-Driven Soft-
ware Development with jUCMNav and TouchRAM ,” in Proceedings
of the Demonstrations Track of the International Conference on Model
IV. C ONCLUSION Driven Engineering Languages and Systems (MODELS 2014), vol. 1255
of CEUR Workshop Proceedings, pp. 1 – 6, October 2014.
This tool demonstration showcases support for the evalua- [9] Y. Liu, Y. Su, X. Yin, and G. Mussbacher, “Combined goal and feature
tion of impact models of reusable concerns in a reuse hierarchy model reasoning with the user requirements notation and jucmnav,” in
in two tools: jUCMNav—a requirements engineering tool with Requirements Engineering Conference (RE), 2014 IEEE 22nd Interna-
tional, pp. 321–322, Aug 2014.
a long history in goal-based modelling, and TouchCORE— [10] M. Schöttle, N. Thimmegowda, O. Alam, J. Kienzle, and G. Mussbacher,
a software design tool with a long history in model-based “Feature modelling and traceability for concern-driven software develop-
reuse. In Concern-Orientation, the impact of a concern’s ment with TouchCORE,” in Companion Proceedings of MODULARITY
2015, pp. 11–14, ACM, 2015.
features on system qualities is captured in a specialized goal [11] M. B. Duran, A. Navea Pina, and G. Mussbacher, “Evaluation of
model called impact model. With the new support, it is now Reusable Concern-Oriented Goal Models,” Model-Driven Requirements
possible to evaluate the combined impact of all concerns in Engineering (MoDRE), 2015.
[12] M. B. Duran, G. Mussbacher, N. Thimmegowda, and J. Kienzle, “On
a reuse hierarchy to enable system-wide trade-off analysis of the Reuse of Goal Models,” SDL Forum’15, October 2015.
candidate feature selections across concern boundaries. This [13] M. Acher, P. Collet, P. Lahire, and R. B. France, “Familiar: A domain-
is an improvement over existing propagation-based evalua- specific language for large scale management of feature models,” Science
of Computer Programming (SCP), vol. 78, no. 6, pp. 657–681, 2013.
tion mechanisms for goal models, which typically assume [14] “FAMILIAR Tool.” http://familiar-project.github.io/.
a monolithic goal model with a centralized specification of