Why Elaborate Models?

There are many scenarios in which we might choose to elaborate a model. The most conspicuous is filling in the implementation of a method generated from an incomplete model. All that can be generated for a method whose semantics aren't captured by the source model is a plain return statement or a "not implemented" exception. Patently, this has to be "elaborated" via the addition of some sensible code.

As another example, when we generate a user interface (UI) from the structure of a model, the generated UI may have to be elaborated to improve layout or improve the UI elements to be used (for example, radio buttons as opposed to a drop-down box), or to address fields that aren't required in a given context. In this case, the source modeling language doesn't explicitly expose all of the artifacts required on the ultimate target, so the target needs to be elaborated.

Next, imagine a business model captured in a modeling language using workflows, resources, business rules, synchronization points, and the like. Let's assume that we want to map this to a model that addresses implementation components, inheritance, attributes and operations, storage formats, transactions, and so forth. There are several aspects for which the mapping function can only guess default settings, and some of these settings may not even be filled in automatically from what's in the business model. Again, elaboration of the target model is required. This can mean the addition of technical detail required for the implementation of the business model and changing settings wrongly proposed by the mapping function. As in the UI example above, the business modeling language wouldn't have allowed us to provide this kind of specification; moreover, the business model is not the right place to talk about technical implementation detail.

Manual model elaboration, though generally required in practice, represents a break from the "pure" approach of linking models through the application of mapping functions. Though this human intervention is an integral part of MDA, you should use it carefully in order to get the best out of your MDA process.

Here are a few guidelines for deciding whether or not to elaborate:

• Don't elaborate a model if you don't have to; otherwise, developers will have to understand all of the metamodels and mapping functions involved.

• Strive for intuitive and accessible ways of providing specification knowledge.

• Localize elaborations; avoid redundancy in elaborating locations.

• Don't expose intermediate models that don't need elaboration.

Observing these criteria means that model elements are added only at the appropriate level of abstraction, at the places designed to be elaborated.

In addition to the possibility of elaborating a model, we may also wish to expose a model so it can be examined, even if we have no intention of elaborating it. For example, if a model is input to or output from a mapping function that causes a significant change in the level of abstraction, being able to view the mapping inputs and outputs can be a tremendous help in understanding what's going on.

Another cultural occasion is the target model as an important artifact at a process or organization boundary. For example, if the software development process calls for a design model before the implementation can start, this target model has to exist as an explicit artifact for delivery.

To avoid unnecessary meddling with generated models, we could create the intermediate models as read-only artifacts, so they can serve as input for the subsequent mappings and be used as documentation.