Information Technology Reference
In-Depth Information
intentional elements. To name a few, GRL adds
beliefs
, Nòmos adds
norms
, and
even
aspects
appear as dependums. There are not many modification proposals,
e.g., resources may be classified as physical or informational with consequences
for class diagram generation in an MDD process.
-
On intentional element links. Most of the variants keep the general idea of the
three link types (
means-end
,
task decompositions
and
softgoal contributions
),
some of them merge two of them, e.g., GRL defines a link
decomposition
that
merges
means-end
and
task-decomposition
. Then we have lots of variations about
types of decompositions (e.g, Tropos allows both
AND
and
OR
means-end links),
contribution values (labels such as +,- vs.
make
,
help
, etc.), correctness conditions
(e.g., whether a resource may be a mean for a goal), etc. Finally, some modifica-
tions usually occur in the form of labels, e.g., quantitative labels for contributions
in GRL, multiplicity in some Tropos-based variants, etc. A special type of modifi-
cation is relaxing some conditions, e.g., allowing links among intentional elements
that belong to different actors, or contributions to goals.
-
On dependencies. About modifications, we may find the addition of attributes
which qualify the type of dependency, e.g., Secure-Tropos adds
trust
and
owner-
ship
qualifiers. Then, we have new types of relationships that may be interpreted
as dependencies, like Nòmos' legal relations. Also, a quite usual variation is to get
rid of dependencies' strength, probably due to the difficulty of interpreting the
concept in a reasoning framework. The type of depender and dependee also pre-
sents constraints sometimes, e.g., GRL forces them to be intentional elements, ac-
tors are not allowed in this context.
-
On diagrams. The distinction among SD and SR diagrams is not always kept,
some proposals just have a single model in which the actors may be gradually re-
fined. One type of diagram that was depicted in Yu's thesis but not recognised as
such was actor diagram, and some authors have promoted this third type of dia-
gram as such. On addition, several proposals of types of diagrams exist, from the
generic concept of module to specific proposals like interaction channel.
The result of this study shows the complexity of the model transformation problem. In
fact, one may easily anticipate that it will be impossible to get an automatic transfor-
mation technique for any pair of existing proposals. It becomes necessary to investi-
gate the limits of model transformation in
i*
and provide a general customizable
framework.
3 A Metamodel View of
i*
Model Translation
Metamodels have been the traditional tool in Software Engineering to express valid
models of a certain modelling language [11]. The language used to specify a meta-
model is called metalanguage. Note that metamodels represent only what can be ex-
pressed in valid models but not what these expressions mean, i.e., a metamodel speci-
fies the syntax of a modelling language but not its semantics.
In the case of
i*
transformations, the different
i*
variants mentioned in Section 2
correspond to their own metamodels which are expressed using different metalan-
guages (e.g., UML, EBNF, Telos). The problem of transforming a source model into a
