Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

Appendix A. GOPPRR to MOF Transformation
Figure A.1.: A possible transformation from GOPPRR to MOF using redefinitions of
associations
This leaves the main problem that associations to different types have to be defined separately
and therefore named differently. For example, in ModelTransitionBinding the compositions
connection1 and connection2. Since those associations can be then named more less arbitrary,
model and generator development might emerge as more difficult and even non-unique.
To avoid this problem, constraints could be used instead of the redefinition of associations
to define the allowed association ends for certain sub types of a meta model. Fortunately,
OCL can also be used for meta models or rather concrete models of MOF. In Figure A.1, to
only allow “Mode” objects to be in a “CurrentMode” or “NextMode” tole, the following OCL
statement could be used:
context GOPPRR: : CProject
inv : m_GraphSet−>s e l e c t (m_Type = ’ EVCStateMachine ’ )−>f o r A l l (
graph |
graph . m_Connection . m_Calls−>f o r A l l (
c a l l |
c a l l . m_pObject . oclIsTypeOf (Mode)
and
( c a l l . m_pRole . oclIsTypeOf ( CurrentMode ) or c a l l . m_pRole . oclIsTypeOf ( NextMode ) )
)
)
This example shows that it not only renders the redefinitions of associations unnecessary but
also the intermediate connection types ModeConnection1 and ModeConnection2 because the
OCL can be directly defined for the each call in m_Calls. A minor disadvantage is that, besides
the graphical modelling of sub-types, the bindings are specified by textual OCL statements
outside the graphical model, which are not as intuitively understandable, like the GOPPRR
abstract syntax description.
244