Marks and Marking Models

Several kinds of marks are commonly used; we describe only those associated with model elements of the developer model (at the M1 level; see The Four-Layer Architecture in Chapter 4) to start with. Based on our example above, each data access operation in the source model would have a mark we'll call it AccessorType with one of two possible values: isRemote and isLocal. (We explore how to use the UML's tag definition construct to represent marks in Chapter 7.) As another example, suppose a system will have to handle 100,000 Customers and 500,000 Accounts. This information could be valuable in decisions involving the size of table spaces in a database, and in the generation of optimized data access statements. We can capture this information as a mark InstanceQuantity on each class.

Often, a mapping function needs some additional input just because it has to fill a blank in the target model. Imagine, for example, a mapping function that produces a relational database schema from a UML model. Capitulating to the power of today's database administrators, it's a good idea to assume they will tell you the target table and column names, even if there doesn't even seem to be a specific reason for each choice. In this case, the mark is simply used to specify the name of the target table or the column, respectively. The mapping function won't use different rules depending on the mark's value; it simply copies the value to the database schema definition.

We need to define each kind of mark as having a name and a type. In addition, a kind of mark can have a default value.

Consider again the example of producing either remote access or local access from a marked source model. In programmer-esque language:

enum AccessorType [ isRemote, isLocal] = isLocal

declares an enumeration named AccessorType that can have one of two values, where the default is isLocal.

In general, a mark can have any kind of type. For our example of a quantity used to direct table allocation, we could define a mark in the marking model named InstanceQuantity, of type Integer, with a default so that the application engineer can choose to enter counts only for those classes with an especially large or small number of instances. We would represent this in our UML model as

InstanceQuantity: Int = 50000;

Similarly, the table name and column name are of type String with no default.