Linking Goal-Oriented Requirements and Model-Driven Development - Intentional Perspectives on Information Systems Engineering - page 267

nor do they introduce automation possibilities. Therefore, the application of these
proposals must be manually performed [ 27] . This is not a suitable option because
the manual translation of models is a time consuming and error prone task [ 25] .
Hence, automatic linking of GORE models and MDD approaches takes on special
relevance for the adoption of new development paradigms and the improvement of
development processes.
One important aspect that must be discussed about our proposal is how to identify
the subset of GORE modeling constructs that must be considered for the generation
of MDD models, since it is very probable that not all the elements of the defined
i ∗ model have to be considered for the development of a software product. In the
proposal, even though the constructs that participate in the MDD model generation
are identified, this is not enough to assure that only the elements that are related
to the software specification participate in the transformation. For instance, in the
example, the i ∗ Actor is considered in the class model generation, but in a real i ∗
model some actors may not be relevant for the intended system, and, therefore, they
must not be transformed into classes of the class model. UML profiles provide a
suitable solution for this issue since it is possible to indicate that only those stereo-
typed (extended) elements must be considered in the transformation process. This is
an important reason for using UML profiles instead of other metamodel extension
mechanisms [ 4] . Other reasons are that the UML profile has a standard specification
[ 32] and a standardized interchange format (XMI [ 33] ).
Another interesting discussion point of this proposal is the need for defining
an Integration Metamodel instead of a direct mapping between the original GORE
metamodel and the MDD requirement metamodel. The definition of an Integration
Metamodel is performed because a direct mapping does not always provide
enough information to automatically identify the required metamodel extensions
[ 10, 12] . Also, a direct transformation is dependent on the extension mechanism
selected. In contrast, the Integration Metamodel allows the required extensions to
be automatically identified independently of their final implementation.
Some additional benefits of the Integration Metamodel are the following: it auto-
mates the generation of the required transformation rules; the required extensions
can be validated before its implementation; it allows the automatic generation of
the mapping for the interchange of models; and it provides a common interface
between the GORE metamodel and the MDD requirement metamodel. This last
benefit prevents a change in the original GORE metamodel from affecting the
transformation rules that are defined in the MDD requirement metamodel. These
benefits are better perceived in real GORE models that are more complex than the
presented example.
The Integration Metamodel is also useful for MDD approaches that already have
a requirement modeling approach. In this case, the MDD requirement metamodel is
the metamodel of the existent requirement approach. The next steps of the process
are normally applied over this metamodel, and the differences that may exist with
the target GORE metamodel (for instance, the i ∗ metamodel) are managed by the
Integration Metamodel and the metamodel extensions.