1.5 Characteristics of OCL

In the previous section, we saw that even a simple three-class model needs much additional information in OCL to make it complete, consistent, and unambiguous. If you had only the UML diagram, many open questions would remain . It is very likely that a system built based on the diagram alone will be incorrect. It is clear that OCL is a vital language for building better models. In the next section, we will take a closer look at some of the characteristics of OCL.

1.5.1 Both Query and Constraint Language

In UML 1.1, OCL was a language to express constraints on the elements given in the diagrams of the model. In the introduction to this book, we already defined a constraint as follows :

A constraint is a restriction on one or more values of (part of) an object-oriented model or system.

What this means is that although the diagrams in the model state that certain objects or data values may be present in the modeled system, these values are valid only if the condition specified by the constraint holds. For example, the diagram in Figure 1-4 tells us that flights may have any number of passengers, but the constraint restricts the flights to those for which the number of passengers is equal to or less than the number of seats on the plane. Flights for which the condition does not hold are not valid in the specified system.

In UML 2, OCL can be used to write not only constraints, but any expression on the elements in the diagram. Every OCL expression indicates a value or object within the system. For example, the expression 1+3 is a valid OCL expression of type Integer , which represents the integer value 4. When the value of an expression is of Boolean type, it may be used as a constraint. Therefore, the possibilities that the language offers have grown considerably.

OCL expressions can be used anywhere in the model to indicate a value. A value can be a simple value, such as an integer, but it may also be a reference to an object, a collection of values, or a collection of references to objects. An OCL expression can represent, e.g., a boolean value used as a condition in a statechart, or a message in an interaction diagram. An OCL expression can be used to refer to a specific object in an interaction or object diagram. The next expression, for example, defines the body of the operation availableSeats() of the class Flight :

  context  Flight::availableSeats() : Integer  body  : plane.numberOfSeats - passengers->size() 

Other examples of using OCL expressions include the definition of the derivation of a derived attribute or association (explained in Section 3.3.8), or the specification of the initial value of attributes or associations (explained in Section 3.3.2).

Because an OCL expression can indicate any value or collection of values in a system, OCL has the same capabilities as SQL, as proved in [Akehurst01]. This is clearly illustrated by the fact that the body of a query operation can be completely specified by a single OCL expression. However, neither SQL nor OCL is a constraint language. OCL is a constraint and query language at the same time.

1.5.2 Mathematical Foundation, But No Mathematical Symbols

An outstanding characteristic of OCL is its mathematical foundation. It is based on mathematical set theory and predicate logic, and it has a formal mathematical semantics [Richters01]. The notation, however, does not use mathematical symbols. Experience with formal or mathematical notations have led to the following conclusion: The people who can use the notation can express things precisely and unambiguously, but very few people can really understand such a notation. Although it seems a good candidate for a precise, unambiguous notation, a mathematical notation is not suitable for a standard language that is to be widely used.

A modeling language needs the rigor and precision of mathematics, but the ease of use of natural language. These are conflicting requirements, so finding the right balance is essential. In OCL, this balance is found by using the mathematical concepts without the abracadabra of the mathematical notation. Instead of using mathematical symbols, OCL uses plain ascii words that express the same concept.

Especially in the context of MDA, where a model needs to be transformed automatically, the value of an unambiguous mathematical foundation for the PIM language is of great value. There can be no doubt as to what an OCL expression means, and different tools must understand the expressions in the same way.

The result is a precise, unambiguous language that should be easily read and written by all practitioners of object technology and by their customers, i.e., people who are not mathematicians or computer scientists. If you still do not like the syntax of OCL, you may define your own. The OCL specification allows anyone to define his or her own syntax. The only condition is that your syntax can be mapped to the language structures defined in the standard [OCL03]. Appendix C provides an example of a different syntax expressing the same underlying structures. This syntax is directed toward use by business modelers.

1.5.3 Strongly Typed Language

An essential characteristic of OCL is that it is a typed language. OCL expressions are used for modeling and specification purposes. Because most models are not executed directly, most OCL expressions will be written while no executable version of the system exists. However, it must be possible to check an OCL expression without having to produce an executable version of the model. As a typed language, OCL expressions can be checked during modeling, before execution. Thus, errors in the model can be removed at an early stage.

Many popular programming languages are typed languages as well. Java, Eiffel, C#, delphi, and so on all fall into this category.

1.5.4 Declarative Language

Another distinguishing feature is that OCL is a declarative language. In procedural languages, like programming languages, expressions are descriptions of the actions that must be performed. In a declarative language, an expression simply states what should be done, but now how . To ensure this, OCL expressions have no side effects; that is, evaluating an OCL expression does not change the state of the system. Declarative languages have several advantages over procedural languages.

The modeler can make decisions at a high level of abstraction, without going into detail about how something should be calculated. For example, the body expression of the operation availableSeats() in Section 1.5.1 clearly specifies what the operation should calculate. How this should be done is not stated; this will depend on the implementation strategy of the whole system. One option is the representation of associations in the code. How do we find all of the passengers on a Flight ? A flight object could contain a collection of references to its passengers. Alternatively, a Flight has no direct reference to its passengers, but needs to search a Passenger table in a database to find its passengers. A third implementation strategy would be to add an additional attribute to Flight , containing the number of passengers. Care should be taken to update the value of this attribute whenever a Passenger books or cancels a Flight . The body-expression in OCL allows for all of these implementations , because it describes only the what, not the how. If a procedural language were used to specify the body of availableSeats(), it would have forced a specific implementation style, which is undesirable for a PIM-level model.

In making OCL a declarative language, the expressions in a UML model are lifted fully into the realm of pure modeling, without regard for the nitty-gritty details of the implementation and the implementation language. An expression specifies values at a high level of abstraction, while remaining 100 percent precise.