One of the lesser known and used components of the Unified Modeling Language (UML) is the Object Constraint Language (OCL). The consortium that is responsible for publishing the UML standard is the Object Management Group (OMG). It includes companies like Rational Software, Microsoft, Oracle and IBM. OCL was included as part of the UML V1.1 specification in September 1997. The current specification for the OCL can be found in the OMG’s UML V1.3 specification, published in June 1999. This document can be located at this web address:ftp://ftp.omg.org/pub/docs/ad/99-06-08.pdf.

The introduction to the Object Constraint Language Specification describes the OCL as follows:

A UML diagram, such as a class diagram, is typically not refined enough to provide all the relevant aspects of a specification. There is, among other things, a need to describe additional constraints about the objects in the model. Such constraints are often described in natural language. Practice has shown that this will always result in ambiguities. In order to write unambiguous constraints, so-called formal languages have been developed. The disadvantage of traditional formal languages is that they are usable to persons with a string [editor’s note: strong] mathematical background, but difficult for the average business or system modeler to use.

OCL has been developed to fill this gap. It is a formal language that remains easy to read and write. It has been developed as a business modeling language within the IBM Insurance division, and has its roots in the Syntropy method.

OCL is a pure expression language. Therefore, an OCL expression is guaranteed to be without side effect. When an OCL expression is evaluated, it simply returns a value. It cannot change anything in the model. This means that the state of the system will never change because of the evaluation of an OCL expression, even though an OCL expression can be used to specify a state change (e.g., in a post-condition).

OCL is not a programming language; therefore, it is not possible to write program logic or flow control in OCL. You cannot invoke processes or activate non-query operations within OCL. Because OCL is a modeling language in the first place, not everything in it is promised to be directly executable.

OCL is a typed language, so each OCL expression has a type. To be well formed, an OCL expression must conform to the type conformance rules of the language. For example, you cannot compare an Integer with a String. Each classifier defined within a UML model represents a distinct OCL type. In addition, OCL includes a set of supplementary predefined types.

As a specification language, all implementation issues are out of scope and cannot be expressed in OCL.

The evaluation of an OCL expression is instantaneous. This means that the states of objects in a model cannot change during evaluation.

We can see that one of the primary reasons for OCL’s existence is to remove the ambiguity in the way natural language statements are written. In Dave Wendelken and Betty Hilbrant Baker’s April 2000 article PROJECT SCOPE DOCUMENT: A "HOW TO" they provide a number of great examples of natural language ambiguities.

Business Rules

When describing a business rule it is often important to specify 3 components:

1. Event
2. Condition
3. Action

The components Event, Condition and Action are sometimes referred to as an ECA. An ECA and identifies for every business event a series of conditions and a set of actions to be carried out. As an example, we may have a business event that deals with hiring new employees. One of the conditions for starting employment may be proof of the employee’s legal status to work. In the United States the employer may ask to see the employees passport, driver’s license, social security card or some other form of legal identification. Depending on what is provided the action will be to allow the employee to start working or to prevent the employee from legally starting employment until such proof is provided.

The OCL primarily relies on other notations in the UML to provide the Event and Action specifications. The primary function of the OCL is to document the Condition (constraint).

The Event can be documented using a UML Statechart or Activity diagram.

The Action can be documented using a UML Class diagram.

Examples

In this Statechart diagram, the states shown are associated with the operation of a telephone.

In this Activity diagram, the internal states shown are associated with a person brewing coffee.

In this Class diagram, the structure of a chess game is shown.

OCL constraints can be directly added to any of these diagrams (and the 6 other UML diagrams), or they can be written in an independent document. If they are written in an independent document, they must still refer to a class diagram for context. The fundamental unit of reference for OCL is a class. This implies that OCL is tightly integrated with UML diagrams (especially the class diagram).

The language has features to support statements that are expressed as navigation from a class to other classes, and to reference attributes of the classes. As stated previously, OCL is a typed expression language. When used to express constraints, OCL statements are predicates; for a given instance, they will evaluate to True or False. Each operand in the language has a type, and each operator is described in terms of the types of operands that are valid, and the type of the result. The validity of a statement is determined, in part, by conformance to the type rules in forming expressions.

OCL expressions are stereotyped as one of the following:

«invariant»

«precondition»

«postcondition»

In OCL, labels are substituted for the stereotypes. They are:

Inv:

Pre:

Post:

An invariant is a constraint that states a condition that must always be met by all instances of the class. In OCL, expressions that express invariants are always true. Preconditions and postconditions are also constraints, but they only have to evaluate as being true at a certain point in time. For a precondition, it is before the execution of an operation, and a postcondition is after the execution of an operation.

Borrowing from Smalltalk, OCL uses the reserved word "self" to indicate an instance.

Inv: Self.minimumBalance > 0

OCL does not specify what to do if the constraint is violated. Operations in the class can be specified to handle anomalies.

The example business rule: "A prospective employee that provides proof of a legal work status can begin employment," specifies the action in addition to the constraint. In OCL, we would need to provide a context for the constraint. This might be the EMPLOYEE class. You would also need to provide the class’ operation for the constraint. For example:

Context Employee::activateEmployment()

Post: self.approvedWorkDocuments > 0

In future articles, we’ll explore other forms of OCL expressions in more depth.