Information Technology Reference
In-Depth Information
-
Some groups have used the
i*
framework with very different purposes thus differ-
ent concepts have become necessary, from intentional ones like trust, delegation
and compliance, to other more related with the modelling of things, like service or
aspect (see [3] for an updated summary).
The adaptability of
i*
to these different needs is part of its own nature, therefore these
variations are not to be considered pernicious, on the contrary, flexibility may be
considered one of the framework's key success features. However, there are some
obvious implications that are not so desirable:
-
It makes difficult to build a repository of
i*
models shared and directly used by
the whole community.
-
It also hampers the possibility of interconnecting different
i*
tools that are not
compliant to the same
i*
language variation.
-
Finally, it makes techniques defined for one
i*
variation not directly applicable
into another variation.
The work presented here addresses these problems and specifically tries to answer the
following research questions:
-
What types of
i*
variations are proposed and how can they be characterized?
-
Which is an appropriate semantic framework for analysing
i*
interoperability?
-
Given two
i*
variations
A
and
B
, to what extent is it possible to translate models
built with
A
to
B
and the other way round according to this semantic framework?
-
Given two
i*
variations
A
and
B
, how can a model from
A
be translated to
B
, in
the light of the limitations identified in the previous question?
The rest of the paper is structured as follows. Section 2 provides the background
about
i*
variations. Section 3 presents the metamodel framework for translation re-
marking why the concepts of supermetamodel and semantic-preservation can be used
for dealing with interoperability among
i*
variants. Section 4 proposes the super-
metamodel for
i*
variants, and Section 5 presents a translation algorithm to maximize
semantic-preservation illustrated with an example of model interchange between two
i*
tools. Finally, Section 6 states the conclusions and future work.
Basic knowledge of
i
* is assumed, see [1] and the
i
* wiki [4] for details.
2 The
i*
Framework: Evolution and Existent Variations
The
i*
framework was issued in the mid-nineties and the first full definition was in-
cluded in the PhD thesis by Eric Yu [1]. Some of its concepts were previously pro-
posed and used in KAOS [5] and in the NFR Framework [6]. This original work on
i*
has been the most cited in the community. Recently, an updated version has been
included as part of the
i*
wiki [4], with minor differences with respect to the seminal
one (e.g., richer types of contribution links).
From this major trunk, we may consider two main variations. On one hand, the
Goal-oriented Requirement Language (GRL) which is part of the User Requirements
Notation (URN) [7]. On the other hand, Tropos [8], an agent-oriented software
methodology that adopts
i*
as its modelling language. In both cases, the differences
with respect to the seminal Yu's
i*
are not that relevant to consider them as different
