Why Mappings?

Consider a platform-independent model, modeled without reference to distributed objects and remote accessibility, and a target technology that offers remotely accessible objects. Let's assume for the moment that we want the design to use this remote-access technology throughout, so that every access is remote. (We'll consider the more realistic and efficient case that some accesses may need to be local in the next chapter.)

In a traditional, code-based, approach to development, we would modify the platform-independent source model to show access to remote objects. This modified model would then be treated as a design model, a new target model that contains both the application model information and additional information about the implementation. Some code-driven processes might then treat this new model as the sole expression of the system, which risks swamping the application with implementation detail, and also risks inhibiting its retargeting. Other approaches might retain both the application model and the design model, which risks divergence between the two models.

To avoid these problems, a model-driven approach maintains a separate mapping function that transforms the source model into the target model. This avoids swamping the source (application) model with detail, and it also circumvents the problem of model divergence, because the target (implementation) model is generated. Model transformations can be repeated, and the implementation model regenerated, after some iterative change in the source model without the need to make all of the design decisions over again.

In other words, the two main features of model mappings are construction and synchronization. Mappings are used to construct target models from source models; because models are derived, they are synchronized by definition. In short, mapping functions represent repeatable design decisions.