The most popular transformation benchmark example – transformation of UML class model to relational database is used here. There are several versions of this example originally proposed by OMG – nearly each paper uses its own version. We use here the version from the QVT-P proposal. The source metamodel is a significantly simplified fragment of the UML class dia-gram metamodel, it is visible in the upper part of Fig. 1. The target metamodel is a simplified relational database metamodel, it is given in the lower part of Fig.1. Next, the precise informal specification of the transformation task will be given (since there are some minor deviations from the QVT-P proposal due to some inconsistencies in it). Any persistent Class (with kind=“persistent”) must be transformed into a database Table. In addition, a (primary) key is built for this table. Attributes of the class, which have a primitive data type, must be transformed into columns of the corresponding table (we assume here that types in UML and SQL coincide). Attributes whose type is a class, must be “drilled-down”: primitively-typed attributes of this new class are added as columns to the table for the original class. Class-typed attributes are proc-essed as before. The process is repeated until no new columns can be added to the table for the original class. In other words, a transitive closure is performed, which finds all “indirect” attributes of the class. The added columns have compound names consisting of all attribute names along the path. One special issue must be reminded here: several attributes of a class may have the same class as a type, in this case the added columns are duplicated for each of them (they have unique names!). In other words, any path leading to a primitively-typed attribute results into a separate column. For primitive-typed “direct” attributes of a persistent class with kind=”primary”, the corresponding columns are included in the relevant (primary) key. An association (with multiplicities ignored, but direction taken into account) is transformed into a foreign key for the “source end” table. The same table is extended with columns cor-responding to columns of the (primary) key at the target end. For both “primary” and “foreign” columns their kind is set accordingly.
The first step in building a MOLA program (transformation) is to define the work-space metamodel (see Fig.1). This metamodel includes both the source metamodel (light yellow classes – the upper part) and the target metamodel (dark yellow classes – the lower part). Both metamodels are taken from the problem domain without modi-fications – they describe the corresponding input data (source model) and the result (target model) of the transformation.
However, some elements typically are added to the workspace metamodel. First, there are mapping associations – associations linking classes in the source and target metamodels (red lines in Fig.1). They serve two different purposes – on the one hand, they document relations between the corresponding source and target elements of the transformation (e.g., Class and Table, Attribute and Column, etc.) and thus enable the traceability at the instance level (which Table was obtained from which Class). On the other hand, they have a technical role in MOLA – after being built by one rule, they frequently are used in patterns of subsequent rules. It is recommended in MOLA to start the role names of mapping associations with “#”. Another possible metamodel extensions are temporary classes – AttrCopy in the example and temporary associations (associations linking AttrCopy to base classes of the metamodel, all temporary elements are in green color in the example). This tem-porary class will be used to store copies of an attribute – indirect attributes. Tempo-rary elements serve as a “workspace” for transformations, they have instances only during the transformation execution, and they are not supplied at input and are dis-carded at output. Base metamodel classes may have also temporary attributes added (attributes which have value only during the transformation execution) – this example does not use them.
The transformation is specified in MOLA by means of one main diagram (Fig. 2) and four subprograms (subdiagrams) – Fig. 3 to 6. The implemented transformation corre-sponds to its informal specification in a quite straightforward manner. The specifica-tion requires to perform a transitive closure – to find all indirect attributes of a class, and with duplicates included (therefore attribute copying is required). We use an idea that each instance of indirect attribute actually is a path in the “instance graph” from the “root class” to an attribute. The iterative algorithm (Fig. 3) for finding all indirect attributes of a class is inspired by the well known algorithm for finding all paths from a node. All diagrams (Fig. 2 to 6) are annotated by standardized comments and, we hope, will require no other explanations.
