Subject Matter and Language Abstraction

Figure 3-2 shows some of the conceptual entities associated with a banking system, which we have abstracted, classified, and generalized by examining "real" customers, accounts, and transactions and capturing their critical properties, such as customer city, account balance, and transaction amount. In so doing, our modeler has abstracted away irrelevant properties, such as a customer's salary, number of children, and ghastly personal habits. However, the model also has abstracted away information that's required to make the system work properly, such as how we know that Fred (an object of class Customer) truly is Fred when he attempts to withdraw money from his account.

Figure 3-2. Domain-level class diagram for banking model

This security information has been abstracted away because it belongs to a different subject matter, or problem domain. The bank can be modeled without reference to security, so long as somehow we can establish that a customer really is who he or she claims to be. Obversely, the problem of identifying and authenticating a person, and authorizing his or her operations, occurs in many systems, not just banking, and security can be modeled without reference to banking, as it would have to be in a building security or network security problem, say. We can then model the bank without worrying about security at all, and model security without worrying about its potential applications. It is then a separate problem to hook the two models together to create an implementation, and so specify where security applies within the banking model.

This, of course, is exactly what MDA does.

Ignoring whole subject matters is a form of abstraction. The banking model ignored security, and the security model ignored other subject matters, so that each model can stand alone, as a separate problem domain.

A problem domain is a subject matter that can be understood independently of other subject matters. A problem domain can be based around some "real" world, such as customers and accounts for a bank, or it can be less concrete, such as a model of security, or even an operating system.

Figure 3-3 shows an excerpt from a typical Security model that our banking system might use. This is a typical set of classes for role-based access control.

Figure 3-3. Domain-level class diagram for security domain

The classes on this diagram are:

• A ProtectedResource is something affected by system actions.

• A ProtectedAction is an action that is subject to authorization.

• A Principal is a human being or application operating as an authorized user of a system on whose behalf actions are triggered.

• A Role defines a relationship between a Principal and the system.

• A Permission reflects the actions that a Principal, acting in a particular Role, can take with regard to a particular ProtectedResource.

Separately, each domain model is expressed in some kind of modeling language. Mathematical equations are one language that we may use to describe air flow over a wing; symbols for resistors, capacitors, and various integrated circuits constitute a language used by electrical engineers; scale drawings help civil engineers; and Hollywood gets by on recreational drugs.

Any modeling language allows you to say some things but not others. For example, an association between Customers and Accounts captures the notion that customers own their related accounts, but it doesn't say whether to use a linked list, pointers, or hash tables. This comes about because the language itself exists at a particular level of abstraction.

By thinking about the problem at a high level of abstraction, specifying a system is much more convenient, efficient, and reusable. We increase productivity because we can say more, more quickly. The higher the level of the language, the greater the amount of functionality that can be delivered for a given amount of effort.

In addition, we can perform a transformation from one level of language abstraction to another. For example, we could decide that every association will be implemented by a pointer. In other words, a large amount of detail in one language can automatically be derived from an abstract specification in another language.

Often, these two kinds of abstraction ignoring subject matters and ignoring realizations are conflated. When we elaborate our banking model to include behavior related to security, and various implementation technologies as well, we change the level of subject-matter abstraction and language abstraction at the same time.

Figure 3-4 illustrates this situation. Both axes denote an abstraction level, one for the subject matter and the other for the modeling language. Note that the axis marked Language is inverted so that a high level of abstraction is near the origin. This allows us to draw the curve from the upper left to the lower right that shows decreasing abstraction in the subject matter at the same time as decreasing abstraction in the modeling language. In short, as we progress from, say, analysis to design, the subject matter and the modeling language both become less abstract.

Figure 3-4. Subject matter and modeling language abstraction levels

Of course, it doesn't have to be this way. There's nothing to prevent one from specifying the behavior of the bank in Java or Smalltalk, and indeed some folks, in particular those in the Extreme Programming (XP) camp, promote exactly this idea. It's also perfectly reasonable to express a model of an implementation technology in a highly abstract analysis language, such as the UML, which one might want to do in the context of merging models, which we discuss in Chapter 6.