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?

MDA Distilled. Principles of Model-Driven Architecture
MDA Distilled. Principles of Model-Driven Architecture
ISBN: B00866PUN2
Year: 2003
Pages: 134 © 2008-2017.
If you may any questions please contact us: