Use of MOLA Tool as RSA plug-in for Building an IS within Hibernate Framework

This example is an extended version of Section 7 in MOLA tool paper at GraMoT 2005 workshop in Tallinn.

In this example we show how the Eclipse plug-in form of MOLA tool could be used for MDD style development of information systems in Java within the Hibernate persistence framework. This framework provides a "classical" object-relational mapping between Java classes and database tables, permitting a developer to access instances of such classes (actually stored in a database) as if they were true Java objects. The modeling tool where the models are built is assumed to be IBM Rational RSA. The implementation language is Java. Just one nontrivial step in the methodology is illustrated. We assume that a PIM – an IS domain model in the form of a standard UML 2.0 class diagram has been built (see a small example in Fig. 1). Some of the classes must be persistent – stored in a relational database as tables. The standard Hibernate object-relational mapping is assumed for these classes, which requires "standard" Java getters and setters to be added for the persistent attributes and association ends of a class, with other attributes and operations unmodified. In addition, for each such mapping the Hibernate mapping descriptor (an XML file) must be built. Thus the task is to build a PSM model consisting of three parts – the augmented UML classes, database schema definition and Hibernate mapping descriptors.

Figure 1. UML class diagram with stereotypes in RSA (PIM model).

In order to specify adequately the logical design decisions at the PIM level, a custom profile (HibernateProfile) is required. This profile should contain the stereotypes persistent (both for classes and properties, representing either attributes or association ends), PK – for attributes (properties) and FK – for association ends (properties). Just to simplify using RSA, here so-called RSA keywords are used instead of proper stereotypes (their appearance in RSA diagrams looks the same). If these stereotypes are appropriately applied to the PIM model, then the three-part PSM can be generated automatically by a MOLA transformation:

– for each persistent class a table will be defined (containing persistent attributes and persistent navigable associations as columns and foreign key constraints/columns for associations with FK)

– appropriate getters/setters will be added to the class

– the Hibernate descriptor will be defined.

Fig. 1 shows these stereotypes applied (RSA does not visualize stereotypes for association ends, these are shown as comments). All classes there are assumed to be persistent, but not all attributes. Classes in a PIM normally should contain also business operations, we don’t show them for brevity. We assume also that primary keys consist of one column (Hibernate uses a complicated mapping for complex keys).

Figure 2. Transformed UML class diagram for Hibernate framework in RSA (PSM model).

Fig. 2 shows how the first the first component of the result – the updated class diagram should look like. Getters and setters are added where appropriate, but custom stereotypes are removed – because RSA cannot use them for its own Java code generation rules.

Fig. 3 shows the required second component of the result – the database schema. The model is built according to the EMF SQL metamodel, but RSA data model visualization feature is used to show the schema as a diagram.

Since there is no visualization for Hibernate XML descriptors, they are not shown here.

Figure 3. Data model visualization in RSA (PSM model).

Now the MOLA transformation for this task is described. Fig 4. shows the metamodel.

Figure 4 Metamodel for the transformation

The metamodel contains an essential fragment of UML 2.0 metamodel for class diagrams, namely the part required for building "normal" design class diagrams. In addition, there a version of Relational Database metamodel is also included (part of the version used in Eclipse based tools, including RSA), and a custom metamodel for Hibernate object-relational mapping. Since keywords instead of true profiles are used in UML, the metamodel doesn't contain the UML profiles fragment (keywords are stored as EMF EAnnotations).

The next figures show the transformation program itself.

Fig. 5 shows the main program, Fig 6 to – all the subprograms.

Figure 5. MOLA transformation program (main).

Figure 6. BuildDtatabase subprogram

Figure 7. AddGettersSetters subprogram

The AddGettersSetters transformation uses the same UML metamodel as a target – it is an update transformation, which simply attaches new Operation instances to existing Class instances.

Figure 8. Subprogram BuildRDBTable

The BuildRDBTable program (Fig. 8) builds a table for the class and then performs a loop, which builds a column (including its type and key constraints) for each persistent property. The target metamodel for this program is the SQL metamodel in EMF, but for BuildHibernateMapping – the metamodel obtained from the Hibernate XML schema definition. Actually in MOLA all these metamodels appear as a common class diagram, but packages are used to separate them. The same packages are used to guide the MOLA tool XMI exporter component – in this case several separate XMI files must be generated, but for Hibernate mapping a non-XMI XML coding is required.

Figure 9. Subprogram SetColumnType

Figure 10. BuildForeignKeys

Figure 11. Subprogram RemoveKeywords

To use the transformation within RSA, a special wrapper plug-in for Eclipse has been developed, which, at first, invokes the UML 2.0 XMI import on a selected RSA export file, then invokes the MOLA VM (interpreter) on the selected MOLA program. Finally, XMI export (with certain configuration possibilities) is invoked on the transformed model and the obtained XMI files must be imported back into RSA (except for Hibernate mapping). Fig. 12 shows the plug-in in action.

Figure 12. RSA plug-in

Namely this way, models in Fig. 2 and 3. were obtained from RSA model in Fig.1.