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

To name the links involved in a resource dependency, we consider that the task
related to the depender actor requires the resource for its execution, while the task
related to the dependee actor is responsible for providing the resource.
Thus, at the end of the second step, we obtain two metamodels: the original
i ∗ metamodel (the original GORE metamodel) and the OO-Method requirement
metamodel for the generation of the OO-Method class model (the MDD requirement
metamodel).
Step 3: Definition of Validation Rules. In this step, syntactical validation mech-
anisms are specified in order to perform a correct generation of the corresponding
MDD models. These validation mechanisms must be defined in the MDD require-
ment metamodel (generated in step 2), since this metamodel has all the information
to perform the model transformations. For instance, in the linking example, an
i ∗ resource is transformed into an attribute or a class, depending on whether the
resource is specified as an informational entity or a physical entity (see Table 1) .
From this transformation guideline, a possible validation is to assure the appropri-
ate specification of the kind of resource. This validation can not be specified in the
i ∗ metamodel since the information related to kind of resource is not present.
For the specification of these syntactical validations, we propose the use of OCL
rules since OCL is also part of the OMG standards for the specification of meta-
models; hence, it is defined to work in conjunction with MOF. In addition, the OCL
rules can be automatically processed by tools such as [6] . Thus, for the previous
validation example, we can define the following OCL rule in the class Resource of
the OO-Method requirement metamodel:

Context: Resource::ValEntityKind ()
Body: self.kind = Physical or self.kind = Informational

It is important to note that the modeling information that is not present in the
original GORE metamodel is the critical point to be validated for the correct gener-
ation of the MDD model for two reasons: (1) the modeling information that exists
in the GORE metamodel has probably already been validated; and (2) the new mod-
eling information is essential for performing the model transformations, and hence,
an incorrect specification of this information will produce an incorrect generation
of the MDD model.
Step 4: Application of the Integration Approach. The fourth step of the linking
approach is to go from the models that are based on the original GORE meta-
model to the specific requirement models for the MDD approach that are based
on the MDD requirement metamodel. This is because the intention of the linking
proposal is to use the original GORE modeling approach for requirement model-
ing. In the example, this corresponds to going from i ∗ models that are based on the
original i ∗ metamodel (Fig. 5) to requirement models that are based on the generated
OO-method requirement metamodel (Fig. 7) .
However, this step is not trivial since the additional modeling information and
validation rules that are present in the defined MDD requirement metamodel are
not present in the original GORE metamodel. Thus, in this step, the integra-
tion approach presented in Sect. 3.1 is put into practice to obtain the required