Models and Platforms

The discussion so far has concerned itself with the various properties of a single model. However, MDA is all about transforming between models, each of which captures one or more subject matters and each of which is expressed in a language with a specific degree of abstraction.

Platform independence is a relative concept. One way to look at it is to refer to the curve in Figure 3-4. For two arbitrary models, the one that's higher up the curve is more platform-independent, while the one lower down is more platform-specific. It's the smoothness of this curve, and the mixing of subject matters, that is the genesis of the endless arguments about what constitutes analysis and what constitutes design. It's also at the heart of continuing discussions today about what constitutes platform independence.

The politically correct way of thinking about this is to define two kinds of models, as described below.

A PIM is a model of a subject matter, such as banking, telephony, or the operation of a copier. A PIM's metamodel (see Metamodels and Platforms in Chapter 2) represents abstractions from one or more platform models. For example, a PIM of a bank need not capture the details of security, a network, or a persistence mechanism.

A PSM, as the name suggests, is a model that relies on details about platforms. A PSM of a bank-with-database, for example, would refer to tables for persistent data describing accounts and also classes for transient information about those accounts. (In this sense, the bank and the database are combined, though the database software has a life of its own.) As another example, certain banking operations may be combined with other operations that check the identity of the requestor, thereby providing for "security level 3," whatever that might be. In this case, a PSM is more clearly a weaving together of the elements of the PIM and of the required platforms, a database, and a security mechanism.

Figure 3-2 showed a portion of a PIM that represents a typical bank. This model didn't reference distributed objects and remote accessibility, even though we happen to know that the design will use a target technology that offers both locally and remotely accessible objects.

We've chosen to abstract away this technology in the analysis model for the usual reasons: The operation of remote objects is not of interest with regard to the subject matter of the bank, and this additional information unnecessarily clutters the model and the business expert's mind. As a consequence, we've chosen to use an analysis modeling language at a level of abstraction that can't describe remote accessibility.

Figure 3-5 shows a PSM for the bank with references to platform-specific concepts, namely access to remote and local objects. The PSM refers to additional information about the implementation. (Note the UML stereotypes on the Customer, Transaction, and Account classes, which specify which classes are "local" and which are "remote.")

Figure 3-5. Design-level class diagram for banking model

The PSM uses a modeling language at a lower level of abstraction than the analysis model; it includes classes and other model elements that capture how, in this example, to effect remote accessibility. In other words, the design model has changed both the level of abstraction of the modeling language and the subject matter, in this case by conjoining banking stuff with technology stuff.