Charting the MDA Process

Of course, you must identify the models the stepping stones comprising your system as part of defining an MDA process. While we can build a model of anything we please, models based on subject-matter boundaries increase the likelihood of reuse of the models.

Some subject matters are easy to find. For example, a user interface is obviously separate from the bank, and it can be modeled as an independent entity. Others are less obvious.

Security, after all, could be modeled as a part of the bank application proper. After all, security is a fundamental part of any bank. Indeed, one could make the argument that building the bank-plus-security as a single unit is easier because we can see how security fits in to the bank, and we don't have to mess with mapping functions. On the other hand, a fully developed model of security could be reused for other applications, and the security model could be replaced by a different approach to security. Both models are independent of one another.

Maintaining subject-matter separation makes true model portability possible, though it does require some abstraction work. It is typical, though wrong, to see physical implementation technology built into a model. For example, were we to build an automated teller machine (ATM), it would be a separate subject matter from the task of moving virtual money from one account to another. The right approach is to abstract out a separate problem domain that manages the physical hardware used to control the device, in this case a digital I/O interface that maps directly to events on the application.

The collection of problem domains and mapping functions comprising the system can be depicted by a domain chart. Figure 11-1 is a typical domain chart that shows the domains and the bridges between them.

Figure 11-1. Example domain chart

The domain chart provides the foundation for defining the MDA process for your project. (Note that a package that contains all of the packages in the figure via a composition relationship would form a composed realization, which we discussed in Chapter 2 [see Metamodels and Platforms].) The construction and maintenance of this chart provides a framework for continued work on the project, in terms of addressing questions such as, Which models are complete? Which mapping functions? Which metamodels? And which marking models?