Inversing of mappings is one of the most important model management operators. Informally speaking, the operator puts back a given mapping of metamodels. The operator has multiple practical applications - it is essential in various model management applications like schema evolution [Mel04], it can also simply serve a role of an 'undo' facility, etc. In this use case, we introduce an application of inverses in system supporting work of salesmen, where there is a need to synchronize data between global database and some local databases stored on PDAs.
The objective of this use case is to show that AMW can easily support the process of inverse mapping generation.
In this use case we generate an inverse weaving model from the weaving model. The figure below presents consecutive steps of mapping inverting. In the first step we find correspondences between two input metamodels (it has a form of a weaving model). Although, core original AMW weaving metamodel is not directed (there is no distinction between source and target), in case of inverting metamodel mapping, such a distinction is necessary. (Therefore, we will use the terms weaving model and inverse weaving model.) In the following step, we generate an inverse weaving model on the basis of a weaving model. Further, we translate this weaving model into an executable ATL transformation, so we are able to transform data from one model to another.
"Inverse mapping" Use Case's Overview
In order to support inverse metamodel mappings we introduced an extension to the core weaving metamodel. Among others, in this metamodel we associated with each supported type of a link/operation the type of a link/operation being its inverse (we store this information as annotations).
In the use case we introduce an ATL transformation which generates the inverse mappings. The transformation takes as an input an original weaving model and its weaving metamodel. We assume that the resulting inverse mapping can then be manually corrected if the result is not satisfactory for the user. Next, the resulting weaving model can be used as input of higher-order transformations to generate executable transformation of models (using this transformation, we are able to translate data from one format to another).
We illustrate our approach to inversing metamodel mapping using an example with two metamodels that describe sale data (metamodels of databases are shown below). One of the metamodels is relational (it contains only flat tables), while the other is XML (nested). This are metamodels used by a Sales Force Automation (SFA) i.e., a system aimed at automating business tasks of sales teams working out of their offices; such tasks include order processing, contact management, information sharing, customer management, etc. We have a global relational database kept in the headquates of a company (its fragment is presented in the figure below), and small salesmen applications designed for PDAs that uses only fragment of this database using XML format. In the periodical process of synchronisation of these databases inverse mappings are crucial.