3.4 Aspects and Join Points

The principle of domain autonomy allows us to build models of domains that are quite separate from one another. From the point of view of the user interface domain, the meaning of what is selected from a menu is both irrelevant and unknown, and from the point of view of the application the fact that a catalog item was selected from a menu list is irrelevant.

At construction time, when we have already built complete executable UML models of each domain, we will need to build a correspondence between different elements of each of the participating domains. The correspondence is between a specific type of thing in the application (catalog item) and an instance, expressed as data, in the user interface (the list of allowable items in the menu).

The two domains, the application and the user interface, need to be woven together, and the combination then translated to form the implementation. More generally, the several domains must be woven together and translated by the model compiler into the implementation.

This is the same problem taken on by various aspect-oriented programming environments. Analogously, each domain is an aspect ^[2] and each bridge is a set of join points. The join points are simply correspondences between elements in two aspects that are then compiled into code. (For a useful introduction to aspect orientation, see [1].)

^[2] While aspects can contain anything a programmer chooses, a well-chosen aspect corresponds to a single domain.

We take up several ways of doing this in Chapter 18: Model Compilers. For the purposes of specification in executable UML, the key issue is to link specific elements in one domain with the specific elements in another that implement it as part of the construction process.