Building an MDA Process

After all of the discussion of the various aspects of MDA, at some point, one needs a process. We started this chapter by talking about models, which of course are at the heart of MDA. At the heart of defining an MDA process, by extension, is the identification of these models.

Think of the gap that separates a problem statement from a coded system. If the gap is narrow enough, you can simply hop across, but if it's wider, you need some stepping stones. The stones represent the models you select; each step from one stone to another represents a mapping function. The path from one side to the other constitutes a particular mapping chain for this project.

Deciding where to place the stones, and planning the journey from one side to the other, constitutes a definition for an MDA process. The selection of the models and the mapping functions between them must fit together to form the specific process you apply on your MDA project.

The best approach to building an MDA process involves a combination of two approaches: (1) focusing on finding models that exist at a single level of abstraction, and (2) focusing on the length of the mapping chain and finding an optimal length for each "hop" in the chain. A multiple-hop approach tends to simplify the mapping functions; it exposes an intermediate model (which sits between the source model and the target model) so the mapping functions can be reused. The choice of intermediate domains may also depend on what is available for reuse (possibly from third parties).

An effective approach is to divide up the system into independent subject matters, or problem domains. These subject matters can be displayed on a domain chart, which shows the domains and the bridges in other words, the mapping functions, marks, and marking models between them. The domain chart forms the basis for defining the MDA process for your project.

Chapter 11 provides more detail about defining an MDA process.