Integrator

Figure 8.13: Screenshot of the SDM rule editor

ofMOFOperationsfor eachTGGRuleto theMOFClassthat corresponds to the TGGNodethat owns the rule. Furthermore, eachMOFOperationis pro-vided with a SDM diagram that represents the operational rule. Finally, from the generated MOF 2.0-compliant specification MOFLON’s code generator is able to generate JMI-compliant Java code that can then be applied to realize the intended model integration.

Figure 8.14: Screenshot of the MOFLON-Integrator

able to access the generated code. Furthermore, the framework must be provided with strategies how to apply the generated code (cf. Section7.2).

Since the framework must be able to access the generated code we have two possibilities how to implement such a framework. On the one hand we could generate a dedicated framework for each model integration, which is insepara-bly linked to the code generated from the TGG specification. This is done by approaches like [Bec08] for instance. On the other hand we could implement a generic framework that is able to dynamically access the generated model inte-gration code at runtime. Since both possibilities are appropriate and feasible it is merely a matter of taste. In the end we chose the latter possibility for implement-ing a prototypical model integration framework. The name of the prototype we implemented simply isIntegrator. We emphasize that the MOFLON-Integrator is a component that runs independently from the MOFLON case tool.

Figure 8.14 presents a screenshot of our prototype. In the first row of the MOFLON-Integrator dialog we have to specify the metamodels of the source, the target, and the correspondence models. In the second row we have to spec-ify the source, target, and correspondence models. In the third row we have to choose whether we want to access the regarded models through the APIs (ap-plication programming interfaces) of the CASE tools that keep the data (online mode) or throughxmi-exports of the tools’ data (offline mode). In case of the

MOF to Java Mapping 39 The root of the inheritance graph is a group of predefined interfaces that make up the Reflective package (see Chapter 5, MOF Reflective Package). These interfaces collectively provide:

n Operations that implement object identity.

n Operations that provide introspection.

n Operations for exercising the functionality of an object independent of its (metamodel-specific) generated interface.

Note –The interfaces in the Reflective package are all designed to be “abstract”; i.e. it is not anticipated that they should be the “most derived” type of any metaobject.

The interfaces for the Package objects, Association objects, Class Proxy objects and Instance objects provide functionality as described previously. The inheritance patterns are as follows:

n An Instance object that has no supertypes extends RefObject; all other Instance objects extend their supertypes.

n A Package object that has no supertypes extends RefPackage; all other Package objects extend their supertypes.

n All Class Proxy objects extend RefClass.

n All Associations extend RefAssociation.

C2 C1 Package P1

P1 P2

A

Metamodel Definition

C1Class

P2 P1

C2 C1

C2Class A

RefPackage RefAssociation RefFeatured RefBaseObject

Inheritance in Generated Interfaces

RefObject RefClass

FIGURE 4-1 Generated Java inheritance patterns.

Figure 8.15: Mapping of a MOF model to Java interfaces (taken from [Sun02])

correspondence model the online mode could mean that the correspondence links are stored in a database instead of a simplexmi-file.

Generally, the offline mode requiresjar-files that have been generated by MOF-LON from MOF 2.0-compliant specifications. These jar-files contain JMI⁴ -compliant interfaces [Sun02] and corresponding in-memory implementations. In case of the online mode thesejar-files contain JMI-compliant interfaces as well.

Rather than corresponding in-memory implementations these jar-files provide implementations that map the JMI interfaces to the APIs of the regarded tools.

Both variants ofjar-files (online or offline) usually provide a reader and a writer in order to (de-)serialize the tools’ data using theXMI⁵file format [OMG05a].

Sun’s JMI specification defines a mapping of MOF models to Java interfaces.

Figure 8.15exemplarily illustrates this mapping. On the left-hand side we see

4Java Metadata Interfaces

5XML metadata interchange

a very simple MOF model. We have two packages P1 andP2. Thereby, P2 inherits fromP1. Furthermore,P1contains two classesC1andC2that inherit from each other and are related to each other by means of an associationA. The right-hand side of the figure depicts the corresponding JMI interfaces. First of all the JMI specification defines a set of reflective interfaces that are independent from the actual metamodel. These interfaces enables users to explore the cor-responding metamodel as well as conforming models without any knowledge of the metamodel itself. Furthermore, the JMI specification demands that for a given metamodel a number of dedicated interfaces must exist that enable the users to access the metamodel and conforming models relying on the actual types that are defined by the metamodel.

All other JMI interfaces directly or indirectly inherit from the reflective in-terface RefBaseObject. This interface contains operations for querying the identity of model elements, to determine their meta object and their contain-ing package, and to evaluate constraints attached to them. TheRefPackage interface provides operations for accessing elements (i.e., classes, associations, nested packages that reside in a given package. The operations of the Ref-Associationinterface enables its users to query and maintain links between model elements that are based on a given association. Using the operations of the RefFeaturedinterface a user can utilize the (possibly statical) features (i.e., attributes and operations) of model elements. Additionally, the RefObject interface provides operations to check whether a model element is of a certain type and to determine the containment hierarchy of model elements by means of composition relationships. Finally, theRefClassinterface offers operations to query the set of model elements of a given type and allows for the creation of new model elements.

Besides the reflective interfaces a number of metamodel-dependent interfaces that extends the reflective interfaces are generated. For each package of the meta-model a corresponding interfaceP1andP2are generated. Similarly, association Ais mapped to a corresponding interface. Finally, for each classC1andC2two interfaces are generated. The interfacesC1andC2represent the actual model el-ements whereas the interfacesC1ClassandC2Classact as factory interfaces that additionally keep track on the set of model elements of the regarded type.

These factory interfaces are calledproxiesin the JMI specification.

Our generic model integration framework heavily relies on the reflective JMI interfaces since the framework should be kept independent from the actual meta-models of the to be integrated meta-models. In contrast the code generated from the

declarative TGG rules relies on the typed JMI interfaces as the rules are only valid for the metamodels chosen at specification time anyway.

The fourth row of Figure8.14contains a button for invoking theLinkbrowser of the MOFLON-Integrator as explained in the following section. Furthermore, there is a combo box that allows the users to choose the model integration task they want to perform. Currently, only the forward model transformation task is prototypically implemented. The implementation of the remaining integration tasks is straight-forward and will be include in the next version of the MOFLON-Integrator. Finally, the Go-button invokes the chosen model integration task which results in the application of the appropriate model integration rules ac-cording to the rule application strategy as explained in Section7.2. The last row of the MOFLON-Integrator dialog is used to display information on the currently running integration task.