Information Technology Reference
In-Depth Information
Table 2.
Correspondence between the
i*
supermetamodel and iStarML
i* Supermetamodel Element
iStarML Construction
XClass Actor
<actor>
XClass Intentional Element
<ielement>
Association XClass Boundary
<boundary> nested under <actor>
Association XClass Dependency Segment
<dependee> or <dependeder> nested under
<dependency>
XClass ActorLink
<actorLink>
XClass IElementLink
<ielementLink>
Association XClass ArrivesTo
<dependency> nested under <ielement>
technologies in order to parse and process iStarML files. The particular XML ele-
ments of iStarML correspond to supermetamodel concepts as we show in Table 2.
For the translation algorithm, it is important to start reminding from Section 3 that,
since we are using the
i*
supermetamodel, then the departing model
m1
is considered
an instance of the
i*
supermetamodel. Therefore the translation from the metamodel
M1
to
M2
should be considered in fact as a translation from the
i*
supermetamodel to
M2
. Since the target variant corresponds to a restricted version of the very
i*
super-
metamodel, then the refactoring operations required for translation can be only to
restrict attributes of the existing classes or to constraint the set of values of specific
attributes. In our iStarML implementation, this means to omit some attribute of an
existing XML element or to translate specific values of attributes to a different set.
Both types of translations (if any) can imply different semantic-preserving situations.
In order to minimize information loss, an algorithm is proposed (Figure 6). It is
presented as a UML activity diagram labelled with information about the semantic-
preservation consequences considering Wachsmuth's framework. The activities are:
−
Copy known formations
. The part of
m1
that is also a valid instance of
M2
is di-
rectly considered as part of
m2
. In other words, the concepts which are shared by
both metamodels
M1
and
M2
are kept. In case that the full model
m1
is a valid in-
stance of
M2
, we finish and classify the translation as strictly semantic preserving.
Example: a generic actor is always kept as a generic actor.
−
Translate using bijective mappings
. Let's name
m1
A
the part of
m1
that has not
been treated in the previous activity. The part of
m1
A
for which we may establish a
bijective mapping between its elements and corresponding elements, which are
instance of
M2
, is translated using this bijective mapping. In other words, the
concepts that can be expressed in both metamodels
M1
and
M2
but with different
constructs, are just translated. In case that after this activity the full
m1
has been
treated, then the translation is
semantic preserving modulo variation
. Example: a
task
can be translated into
plan
and a
plan
into a
task
.
−
Translate using injective mappings
. Let's name
m1
B
the part of
m1
that has not
been treated in the previous activity. The part of
m1
B
for which we may establish
an injective mapping from its elements to others which are instance of
M2
, is trans-
lated using this mapping. In case that after this activity the full
m1
has been treated,
then the translation is
decreasing modulo variation
(the variation introduced by
the mapping). Example: a
make
contribution from GRL can be translated into ++
contribution in seminal
i*
, but not any ++ is a
make
contribution.
