The Object Constraint Language: Getting Your Models Ready for MDA (2nd Edition)

Before we discuss how to build a model, we need to understand what is meant by the word model . This term is used in many contexts and often has a different meaning. For instance, the R&L system depicted in the previous chapter is often called a class model . A statechart is sometimes called a state model . Are these models two separate, unrelated items, or should we consider them to be part of the same thing?

3.1.1 Definitions

In this book a model describes a system using a well-defined language. Therefore, the answer to the question above should be that both are views of the same model. Both class diagrams and the statecharts show items that describe the same system using the same language ”namely, UML.

We use the word model to refer to a consistent, coherent set of model elements that have features and restrictions, where model elements are the compositional elements that may be used in artifacts written in UML and/or OCL. For example, classes are model elements, and so are states. Attributes and operations are features of classes, and derivation rules and invariants are restrictions on attributes and classes, respectively. Because most models are built using tools, we refer to the storage of all model elements as the model repository .

To indicate a certain view on the repository of model elements we use the word diagram . Using these definitions, the picture shown in Figure 2-1 is a diagram showing part of the R&L model . Model elements can be shown in one, in many, or in no diagrams. When an element is present in the model repository, it is part of the model. It need not be shown in any diagram. Nor is it necessary to show all of the features of a model element when one is present on a diagram. For instance, a class can be shown on two diagrams. On the first diagram, all attributes could be shown, but no operations. On the second diagram, all operations could be shown, but no attributes.

The definitions used in this book are summarized as follows :

A model is a consistent, coherent set of model elements that have features and restrictions.

A model repository is the storage of all model elements in an automated tool.

A diagram is a view of the model elements in a model.

3.1.2 A Model Is a Consistent, Coherent Unit

Any model must be an integrated, consistent, and coherent unit. It must be crystal clear how entities shown in one diagram relate to entities in other visible parts of the model. In the previous example, it must be clear that in both class diagrams the same class is depicted. Likewise, it should be clear that the objects in an interaction diagram are instances of classes present in the model. These classes may be visible in one of the class diagrams. Another example of the relationship between model elements shown in different diagrams is the connection between a statechart, with all its states and transitions, and its owning class. This class must be present in the model, and may be shown in other diagrams. The attributes and operations of this class shown in the class diagram may also be shown in the statechart, e.g., in a guard to a transition.

OCL expressions are often not shown in any diagram, but they are still part of the model. They are present in the underlying repository. Automated tools will use the OCL expressions in a model in addition to the other information in the model. Therefore, we must establish how the UML diagrams and OCL expressions are connected. The relation between OCL expressions and entities shown on the diagrams must be clear. The link between an entity in a UML diagram and an OCL expression is called the context definition of an OCL expression.

3.1.3 The Context of an OCL Expression

The context definition of an OCL expression specifies the model entity for which the OCL expression is defined. Usually this is a class, interface, datatype, or component. For sake of convenience, we use the word type in the remainder of this book to indicate either class, interface, datatype, or component. In terms of the UML standard, this is called a Classifier , but we prefer to use the more intuitive word type .

Sometimes the model entity is an operation, and rarely it is an instance. It is always a specific element of the model, usually defined in a UML diagram. This element is called the context of the expression.

Next to the context, it is important to know the contextual type of an expression. The contextual type is the type of the context, or of its container. It is important because OCL expressions are evaluated for a single object, which is always an instance of the contextual type. To distinguish between the context and the instance for which the expression is evaluated, the latter is called the contextual instance . Sometimes it is necessary to refer explicitly to the contextual instance. The keyword self is used for this purpose (see Section 6.1.2).

For example, the contextual type for all expressions in Figure 3-1 is the class LoyaltyAccount . The precondition ( pre: i>0 ) has as context the operation earn. When it is evaluated, the contextual instance is the instance of LoyaltyAccount for which the operation has been called. The initial value ( init: 0 ) has as context the attribute points . The contextual instance will be the instance of LoyaltyAccount that is newly created.