<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Aggregate Contribution of Decomposed Intentional Elements</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Aprajita</string-name>
          <email>aprajita.aprajita@mail.mcgill.ca</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Gunter Mussbacher</string-name>
          <email>gunter.mussbacher@mcgill.ca</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department of Electrical and Computer Engineering, McGill University</institution>
          ,
          <addr-line>Montreal</addr-line>
          ,
          <country country="CA">Canada</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2016</year>
      </pub-date>
      <volume>1674</volume>
      <fpage>73</fpage>
      <lpage>78</lpage>
      <abstract>
        <p>We present aggregate contribution as a solution for two longstanding issues with goal modeling languages such as i* and GRL which support decomposition and contribution links for intentional elements. An aggregate contribution summarizes the contributions of constituent parts (child elements) at the parent level, giving the modeler an overview of the actual impact of the parent while still enabling the correct evaluation of the goal model.</p>
      </abstract>
      <kwd-group>
        <kwd>Goal Modeling</kwd>
        <kwd>Decomposition</kwd>
        <kwd>Contribution</kwd>
        <kwd>GRL</kwd>
        <kwd>Goal-oriented Requirement Language</kwd>
        <kwd>URN</kwd>
        <kwd>User Requirements Notation</kwd>
        <kwd>Evaluation</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        Goal models are graphs of intentional elements such as goals and tasks connected by
various relationships and optionally assigned to actors. Common relationships
supported by many goal modeling notations (e.g., i* [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], the Goal-oriented Requirement
Language (GRL) [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], the NFR framework [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], and KAOS [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]) are contributions and
decompositions. This paper addresses shortcomings related to (a) a lack of support for
relationship abstractions [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] and (b) analysis anomalies [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] in goal models that
support decompositions and contributions.
      </p>
      <p>
        In Section 2, we briefly discuss the two aforementioned issues and further motivate
our proposed solution with the help of an example. Section 3 then explains how we
address these two issues in detail. We use GRL to visualize the examples, but the
solution applies to any other goal modeling notation with decompositions,
contributions, and a propagation-based evaluation mechanism. The paper concludes and
briefly discusses future work in Section 4.
“Sloth” (Lack of Support for Relationship Abstractions) and “Wrath” (Analysis
Anomalies) are two of the eight “deadly sins” [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] that are still haunting GRL and
other goal modeling languages today. Currently in GRL, it is not possible to describe
the relationships of an intentional element based on the relationships of its constituent
parts. As shown in Figure 1(a), the constituent parts of task A, i.e., A1 and A2, do not
make their individual contributions apparent at the parent level. This may lead to
      </p>
      <p>
        Copyright © 2016 for this paper by its authors. Copying permitted for private and academic purposes.
ambiguities as the parent task does not seem to be contributing to the goal. To
overcome this slothful [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] behavior, a better visualization is needed of the total
contributions of any given intentional element. Adding all contributions manually in the goal
model to overcome “sloth” gives birth to “wrath”. A relationship shown at more than
one level of abstraction creates an analysis anomaly, because it should be taken into
account only once but is actually considered multiple times. Figure 1 describes the
three cases in a goal model evaluated with a quantitative evaluation algorithm [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. As
shown, (a) and (b) are equivalent (evaluation of goal G is 30), but (c) results in a
different evaluation (i.e., 60) because of the repetition of the same relationship at two
different abstraction levels: (i) the individual contributions of A1 and A2 to goal G
and (ii) the combined contribution at the parent level.
Similar issues exist for qualitative and mixed evaluation algorithms [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. To tackle
these issues, the concept of aggregate contribution for decomposed parent elements is
introduced and a proof of concept implementation provided in jUCMNav [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
3
      </p>
    </sec>
    <sec id="sec-2">
      <title>Inferring Aggregate Contributions</title>
      <p>When an intentional element (task A), that is decomposed into A1 and A2, contributes
to another intentional element (goal G), two cases arise. First, task A does not have
any individual contribution to goal G and contributes only through its constituent
parts, i.e., A1 and A2. In this case, only contributions of A1 and A2 should be
considered while evaluating goal G (i.e., G should evaluate to 30 in Figure 1(c)). Second,
task A, along with contributing through its parts, also has its own individual
contribution to goal G. Here, contributions of all elements (A, A1, A2) should be considered
for the evaluation of goal G (i.e., G should evaluate to 60 in Figure 1(c)). The second
case often occurs when the parent captures contributions common to all its parts.</p>
      <p>The new concept of aggregate contribution clearly differentiates these two cases
by showing the range of contributions for a parent element based on its parts and the
decomposition type. For an AND decomposition, all parts contribute for the parent.
For an OR decomposition, at least one part but possibly all parts contribute for the
parent. For an XOR decomposition, exactly one part contributes for the parent. An
aggregate contribution is a range of values, because it shows the result of all possible
combinations of the contributions of its constituent parts (1 for AND, 2N-1 for OR,
and N for XOR with N being the number of parts). A new icon ( ) and its textual
equivalent “A:” are used to denote a contribution link with aggregate contribution,
followed by the actual value of the aggregate contribution.</p>
      <p>
        All common GRL evaluation algorithms (quantitative, qualitative, mixed) first
calculate for a given element its evaluation value coming from decomposition links, then
contribution links, and finally dependency links [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. Aggregate contribution affects
the calculation of the contribution links, in that a link with only an aggregate
contribution must not be considered by the evaluation algorithm. The aggregate
contribution itself is calculated for each decomposed parent element before the evaluation.
      </p>
      <p>Quantitative Evaluation Algorithm. This algorithm uses quantitative
contribution values (e.g., task A1 contributes 10 to goal G in Figure 1(c)) and quantitative
evaluations of contributing elements (e.g., 100 for task A1) to determine an element’s
evaluation that is coming from contribution links (e.g., for task A). An aggregate
contribution is only calculated for a decomposed parent element that has an outgoing
contribution link and is decomposed into one or more constituent parts. A modeler,
therefore, has control over whether to show an aggregate contribution by explicitly
adding the outgoing contribution link for the decomposed parent element. In addition,
an aggregate contribution may also be indicated with a Boolean flag added to the
metaclasses representing the goal model or intentional elements in the GRL
metamodel. The aggregate contribution calculated for this algorithm is referred to as
quantitative aggregate contribution (QNAC).
position types, showing the cases for only positive contributions, only negative
contributions, and mixed contributions of parts. It considers that the contributions by an
element’s parts may consist of both individual and range contributions, both positive
or negative. A range contribution may exist because a part of an element may itself be
a decomposed element with an aggregate contribution, an example of which is shown
in Figure 3(b). An aggregate contribution is a range represented by “A:[Min,Max]”,
except where the minimum and maximum values are the same which is simply
represented by “A:Max”.</p>
      <sec id="sec-2-1">
        <title>Contribu</title>
        <p>tions ↓</p>
      </sec>
      <sec id="sec-2-2">
        <title>Positive</title>
      </sec>
      <sec id="sec-2-3">
        <title>Negative</title>
      </sec>
      <sec id="sec-2-4">
        <title>Mixed</title>
        <p>AND
Min</p>
        <p>Max
Σ 
+ Σ 
Σ 
+ Σ</p>
        <p>OR
Min</p>
        <p>Max
min(  ,   )</p>
        <p>Σ  + Σ 
Σ  + Σ 
Σ  + Σ 
max(  ,   )
Σ  + Σ</p>
        <p>XOR
Min</p>
        <p>Max
)





,
(
x
Legend:   : Individual quantitative contribution value of part i
tively, of a range contributed by part i
   ,    : Left (minimum) and right (maximum) quantitative contribution values,
respec</p>
        <p>, 
   , 
respectively, of a range contributed by part i, when it contributes negatively

  : Individual quantitative contribution value of part i, when i contributes negatively
 : Individual quantitative contribution value of part i, when i contributes positively</p>
        <p>: Left (minimum) and right (maximum) quantitative contribution values,
respectively, of a range contributed by part i, when it contributes positively</p>
        <p>: Left (minimum) and right (maximum) quantitative contribution values,
Note:</p>
        <p>All calculated minimums and maximums are capped to -100 and 100, respectively, to
respect valid GRL contribution and evaluation values.
Note that aggregate contribution as proposed here abstracts from the contributions of
constituent parts only, but does not abstract from all combinations of contributions
and evaluations of constituent parts. In that sense, the abstraction is based on the static
goal model specification and does not consider the evaluation of the goal model. This
can clearly be seen in Figure 2(a). Propagating the evaluation of B (50) to A with only
the aggregate contribution (20) results in 10 and not the correct 25. It is possible to
consider an aggregate contribution as an abstraction of the evaluation instead of the
static goal model specification. In that case, however, AND as well as XOR
decompositions have to be treated like an OR decomposition in Table 1 (i.e., the aggregate
contribution in Figure 2(a) would be “A:[-10,30]” and in Figure 2(c) “A:[-5,35]”; this
would ensure that the evaluation of B always falls into the range defined by the
aggregate contribution of A on B and the evaluation of A).</p>
        <p>As discussed earlier, a decomposed element may also contribute individually in
addition to its parts. In Figure 3(a), B contributes to A individually as well, unlike the
examples in Figure 2. In this case, the QNAC value for B is calculated the same way
as for the examples in Figure 2 and the contribution of B is added on top. Thus, the
evaluation of goal A is 40 (10 as shown in Figure 2(c) plus (30 * 100)/100 from B).
To calculate the QLAC value abstracting contributions only for an AND
decomposition (e.g., the QLAC value of B contributing to A in Figure 4(b)), the count of each
type of qualitative contribution of the constituent parts of B to A is determined first.
Then, the dominant for each strength is identified, i.e., a positive contribution and a
negative contribution of the same strength (bottom-left to top-right diagonal in bold in
Figure 4(a); e.g., “Make” and “Break”) cancel each other out (= “None”) and any
remaining ones are dominant. Afterwards, the strongest contribution (most positive or
most negative depending on the dominant) is combined with the strongest opposite
contribution (most negative or most positive, respectively) based on Figure 4(a), until
only either positive or negative contributions are left. Finally, the highest (in case only
positive contributions are left) or the lowest (in case only negative contributions are
left) contribution value is selected as the QLAC value of B to A. If all contribution
values cancel each other out, the QLAC value is considered to be “Unknown”.</p>
        <p>For example, Figure 4(b) shows an AND decomposition, where the parts of B
contribute as follows to A: “Make”, “Help”, “Some Negative”, and “Hurt”. One “Make”
and zero “Break” result in one “Make” being dominant. Zero “Some Positive” and
one “Some Negative” result in one “Some Negative” being dominant. One “Help”
and one “Hurt” cancel each other out. Since “Make” is the strongest remaining
contribution, it is combined with the strongest opposite contribution, i.e., “Some
Negative”, resulting in one “Help” according to Figure 4(a) (row 2, column 3).</p>
        <p>Similar to the quantitative evaluation algorithm, decomposition hierarchies of
arbitrary depths and various combinations of decomposition types are handled with a
bottom-up approach.</p>
        <p>
          Mixed Evaluation Algorithm. This algorithm uses qualitative contribution values
and quantitative evaluations of contributing elements to determine an element’s
evaluation that is coming from contribution links [
          <xref ref-type="bibr" rid="ref1">1</xref>
          ]. Consequently, aggregate
contributions are calculated for this algorithm using the same approach as discussed for the
qualitative evaluation algorithm.
4
        </p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Conclusions and Future Work</title>
      <p>This paper discusses the issues “Sloth” (Lack of Support for Relationship
Abstractions) and “Wrath” (Analysis Anomalies) in GRL and proposes the concept of
aggregate contribution to address them. An aggregate contribution indicates the
contributions of constituent parts for a decomposed parent element, given a sense of the
overall combined contribution of the parent when all its parts are taken into account. The
calculation of aggregate contribution for different decomposition types and
evaluation algorithms is defined and detailed with the help of illustrative examples. In future
work, we plan to find ways to abstract other goal modeling concepts such as
dependencies and indicators for parent elements.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>D.</given-names>
            <surname>Amyot</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Ghanavati</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Horkoff</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G.</given-names>
            <surname>Mussbacher</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Peyton</surname>
          </string-name>
          , and E. Yu, “
          <article-title>Evaluating goal models within the Goal-oriented Requirement Language”</article-title>
          .
          <source>International Journal of Intelligent Systems (IJIS)</source>
          , Wiley, vol.
          <volume>25</volume>
          , no.
          <issue>8</issue>
          , pp.
          <fpage>841</fpage>
          -
          <lpage>877</lpage>
          ,
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>L.</given-names>
            <surname>Chung</surname>
          </string-name>
          ,
          <string-name>
            <given-names>B.A.</given-names>
            <surname>Nixon</surname>
          </string-name>
          ,
          <string-name>
            <given-names>E.</given-names>
            <surname>Yu</surname>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>Mylopoulos</surname>
          </string-name>
          ,
          <article-title>Non-Functional Requirements in Software Engineering</article-title>
          . Kluwer Academic Publishers,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <article-title>[3] ITU-T, User Requirements Notation (URN) - Language definition</article-title>
          .
          <string-name>
            <surname>ITU-T Recommendation</surname>
          </string-name>
          Z.
          <volume>151</volume>
          (
          <issue>11</issue>
          /08), Geneva, Switzerland,
          <year>November 2008</year>
          ; http://www.itu.int/rec/T-REC-Z.
          <volume>151</volume>
          /en.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4] jUCMNav,
          <source>development build 6</source>
          .0.
          <issue>D0610</issue>
          .v1626, http://jucmnav.softwareengineering.ca/jucmnav.
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>G.</given-names>
            <surname>Mussbacher</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Amyot</surname>
          </string-name>
          , and
          <string-name>
            <given-names>P.</given-names>
            <surname>Heymans</surname>
          </string-name>
          , “
          <article-title>Eight Deadly Sins of GRL”</article-title>
          .
          <source>5th International i* Workshop</source>
          (iStar
          <year>2011</year>
          ), Trento, Italy, CEUR-WS
          <volume>766</volume>
          :
          <fpage>2</fpage>
          -
          <lpage>7</lpage>
          ,
          <year>2011</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <surname>A. van Lamsweerde</surname>
          </string-name>
          ,
          <article-title>Requirements Engineering: From System Goals to UML Models to Software Specifications</article-title>
          . John Wiley &amp; Sons Ltd,
          <year>2009</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>E.</given-names>
            <surname>Yu</surname>
          </string-name>
          ,
          <article-title>Modeling Strategic Relationships for Process Reengineering</article-title>
          .
          <source>Ph.D. thesis</source>
          , University of Toronto, Canada,
          <year>1995</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>