MDA Distilled. Principles of Model-Driven Architecture

Another topic of interest in this context is reverse engineering and bidirectional synchronization of models. Of particular interest is whether it's advisable to allow the modification of models at lower levels of abstraction such that the changes can be merged into models at higher levels of abstraction.

A one-time use of an abstracting mapping can be of tremendous help when you're getting started with MDA and you have a pile of legacy source code. In such a situation, "MDA-enabling" these sources is a practical way to bring them into the fold.

Similarly, a one-time abstracting mapping can be useful when you're moving an existing model to a different platform. An abstracting mapping pulls the contents of the detailed model into a more abstract model whence it can then be mapped to other more detailed models for other platforms. Figure 8-1 illustrates this approach to porting models.

On the other hand, regular and frequent use of abstracting mappings is somewhat more problematic, especially if corresponding refining mappings produce "fan-out" (from single source model elements to more than one target model element). This brings about the situation in which it's unclear what modifications to a single target model element should mean for the source model element.

For example, a model for a multi-tiered application will employ a number of combined mapping functions, one for each tier of the application. Naturally, a change to a source model element will potentially be reflected in each of the tiers (say, presentation, application, and database). To make things more complex, each of these tiers can be divided into a number of layers, such as one for interfaces and another for the classes that implement them.

Now imagine that you change a detail in one artifact and want to apply an abstracting mapping to it.

The trouble is that there are multiple ways to reverse-engineer the type of an attribute from its member declaration in the implementation class, from the parameter types in getter/setter operations, from entries in deployment descriptors, from column types in database table definitions, from the type of a UI element, and so forth.

In this representative example, mapping functions are not reversible without more information. If you require reversible mapping functions, you have to introduce additional rules that account, for example, for the fan-out that occurs during the forward mapping.