Mappings of MOF Metamodels and Object-oriented Languages

Introduction

This chapter discusses the main steps for transforming NEREUS constructions into object oriented languages. As an example, we use the Eiffel language that allows integrating specifications with Eiffel contracts (Meyer, 1992). Figure 1 shows the main steps.

Figure 1.

From NEREUS to object oriented languages

The Eiffel code is constructed gradually. First, associations and operation signature are translated. The transformation is supported by reusable components. From OCL and NEREUS specifications it is possible to construct contracts on Eiffel and /or feature implementations by applying heuristics.

Mapping Classes And Associations

For generating code from some NEREUS specification we need transformation rules. For each class in NEREUS an Eiffel class is built. If a NEREUS class is incomplete, i.e., it contains sorts and operations in the clause DEFERRED, the keyword class in Eiffel is preceded by the keyword deferred. NEREUS and Eiffel have the same syntax for declaring class parameters. Then, this transformation is reduced to a trivial translation.

The relation introduced in NEREUS using the clause IMPORTS will be translated into a client relation in Eiffel. The relation expressed through the keyword INHERITS in NEREUS will become an inheritance relation in Eiffel. This provides the mechanism to carry out modifications on the inherited classes that will allow adaptation. Also, subsortings will become inheritance relations.

Associations are transformed by instantiating schemes that exist in the reusable component Association. A component is defined in three levels of abstraction that integrate NEREUS incomplete algebraic specifications, complete algebraic specifications and object oriented code.

Figure 2 depicts a specific Association component including schemes for the Eiffel language. It describes taxonomy of associations classified according to kind, degree, navigability and multiplicity.

Figure 2.

Association component

The first level describes a hierarchy of incomplete specifications of associations using NEREUS and OCL. Every leaf in this level corresponds to sub-components at the second level.

A realization sub-component is a tree of algebraic specifications: the root is the most abstract definition and the internal nodes correspond to different realizations of the root. For example, for a “binary, bi-directional and many-to-many” association, different realizations through hashing, sequences, or trees could be associated. These subcomponents specify realizations starting from algebraic specifications of Eiffel libraries (Meyer, 1994).

The implementation level associates each leaf of the realization level with different implementations in Eiffel. Implementation sub-components express how to implement associations and aggregations. For example, a bi-directional binary association with multiplicity “one-to-one” will be implemented as an attribute in each associated class containing a reference to the related object. On the contrary, if the association is “many-to-many”, the best approach is to implement the association as a different class in which each instance represents one link and its attributes.

For every ASSOCIATES clause, a scheme in the implementation level of the association component will be selected and instantiated. In these cases, the implementation level schemes suggest including reference attributes in the classes or introducing an intermediate class or container. Notice that the transformation of an association does not necessarily imply the existence of an associated class in the generated code as an efficient implementation can suggest including reference attributes in the involved classes.

The following scheme may be used to implement bidirectional associations. It include two schemes for classes Class1 and Class2