Figure A-2 shows a class diagram with a few OCL expressions, including:

Figure A-2. Example OCL constraints of varying complexity

OCL expressions consist of model elements, constants, and operators. Model elements include class attributes, operations, and members though association. The OCL expressions in Figure A-2 use the model elements baseCost, totalCost, and getTaxRate( ). (Later sections contain OCL expressions with members through association.)

Constants are unchanging values of one of the predefined OCL types. In Figure A-2, constants include 0.0 of type Real and 'Unpaid' of type String. Operators combine model elements and constants to form an expression. In Figure A-2, operators include <>, +, and =.

The following sections discuss the basics of OCL types and operators and then show how to combine these into expressions you can use in your UML models.

OCL has four built-in types: Boolean, Integer, Real, and String. Table A-1 shows examples of these four types. These examples are typical constants you could encounter in OCL expressions.

OCL has the basic arithmetic, logic, and comparison operators. OCL also has more advanced functions such as returning the maximum of two values and concatenating Strings. OCL is a typed language, so the operator has to make sense for its values. For example, you can’t take the sum of an Integer and a Boolean. Table A-2 shows commonly used operators in OCL expressions.

Operators in the groups Comparison, Equality, and Boolean all return results of type Boolean. For example, age = 65 evaluates to true or false. The other operators in Table A-2 return the same type with which they’re used. For example, if baseCost and tax are Real, then baseCost + tax will also be Real.

Figure A-2 shows that getTaxRate( ) returns a double (this model was written with Java types), but the table in Table A-2 mentions that the operator + is defined on Reals and Integers. That’s perfectly fine; when building an OCL expression, you can match your types to the closest OCL type.

So far you’ve seen the building blocks of OCL expressions. Now let’s combine them to build a sample OCL expression.

totalCost = baseCost * (1+getTaxRate(  ))

This OCL expression is taken from Figure A-2. It contains the following building blocks of an OCL expression:

The above expression actually consists of several OCL expressions, which are in turn combined by operators. For example, 1+getTaxRate( ) evaluates to a Real, which is then multiplied with baseCost. That resulting value is checked for equality with totalCost using the = operator. You can combine model elements, constants, and expressions according to their type, but the combined expression must be type Boolean. This is because we’re focusing on using OCL to express constraints and guards, which must evaluate to true or false.

Another commonly used constraint is to specify that an object isn’t null. To specify that an object isn’t null, you have to use the OCL’s notation for sets and operations on sets. Figure A-3 shows how to check that Author’s member through association fee isn’t null using the expression:

self.fee->notEmpty(  )

Figure A-3. Constraining that a member isn’t null

Notice the reference to self in the OCL expression in Figure A-3. Because it is attached to Author, self refers to objects of type Author. The self keyword is commonly used when you set a context in an OCL expression, as shown in the following section.

Figure A-2 defined OCL expressions on the elements they constrain, while Figure A-3 defined an OCL expression on the containing class. You can write an OCL expression at different areas in your diagram. How you write the OCL expression depends on the context, or where you are in the diagram.

Figure A-4 shows how to check that baseCost of AccountFee is greater than or equal to 0 at different reference points in the diagram. The first diagram shows this constraint in the context of baseCost, the second shows this constraint at AccountFee, and the third shows this constraint at Author.

Figure A-4. The way you write a constraint depends on your reference point in the diagram

If your reference point is baseCost, e.g., by writing a constraint in curly braces after baseCost, then you write:

baseCost >= 0.0

If you’re referring to the AccountFee class, e.g., by attaching a note to the AccountFee class, then you write:

self.baseCost >= 0.0

Finally, if you’re referring to the Author class, e.g., by attaching a note to the Author class, then you write:

self.fee.baseCost >= 0.0

You can also write OCL constraints that aren’t physically attached to model elements. For example, your UML tool may provide a text editor for entering constraints. If you do this, write the context explicitly. If the context is the AccountFee class, then you write:

Context AccountFee
inv: self.baseCost >= 0.0

The inv keyword indicates that the constraint is an invariant, or a condition that must always be true. When specifying the context, you also specify the type of constraint it is. Constraint types are discussed in “Types of Constraints,” next.

There are three types of constraints:

Previous examples in this chapter focused on invariants, but all three constraint types can be expressed in your UML diagrams or related documentation. The following examples will show how to provide preconditions and postconditions for the method incrementRating. The reference class diagram is shown in Figure A-5.

Figure A-5. We’ll provide preconditions and postconditions for the incrementRating method

Suppose incrementRating will increment the value rating by the value amount. We want to first specify a precondition that amount is less than a maximum legal amount, say 100, and a postcondition ensuring that rating has been incremented by amount. To write these preconditions and postconditions, you first specify the context and then the constraints.

context BlogEntry::incrementRating(amount: int) : void
pre: amount <= 100
post: rating = rating@pre + amount

Notice the @pre directive: rating@pre is the value of rating before the method executes. You can use the @pre notation on methods too:

context BlogEntry::incrementRating(amount: int) : void
pre: amount <= 100
post: getRating(  ) = getRating@pre(  ) + amount

Invariants, preconditions, and postconditions are part of an approach known as “Design by Contract,” developed by Bertrand Meyer. “Design by Contract” attempts to make more reliable code by establishing a contract between a class and its clients. A class’s contract tells its clients that if they call its methods with valid values, then they will receive a valid value in response. A contract also establishes invariants on a class, meaning that the class’s attributes will never violate certain constraints.

If you’re wondering why you haven’t encountered invariants, preconditions, and postconditions in your code, note that support for Design by Contract differs per programming language. “Design by Contract” is built into the Eiffel programming language, which was also developed by Bertrand Meyer. Eiffel has keywords for invariants, preconditions, and postconditions, and an exception is thrown if any of these constraints are violated. With other languages, you have to either implement constraint handing yourself or use a package such as iContract for Java. iContract is a preprocessor with doc-style tags to specify invariants, preconditions, and postconditions. iContract also throws an exception if a constraint is violated.

The real power of OCL comes from tools that can use the OCL constraints from your UML model to perform constraint checking for you. While at the moment there is wide variation in tool maturity and level of integration, the ultimate goal is to enhance integration of your UML model with the runtime behavior of your system. This has the benefit of allowing you to catch errors early and saving on debugging time.

Some UML tools focus on placing the OCL constraints from your diagrams into generated code so that the constraints can be checked at runtime (although at the moment, these may only be proposed or partial implementations). Example approaches include generating assert statements directly in your code to allow constraint checking, or embellishing your code with Java annotations or doc-style tags containing OCL constraints, which can then be used by standard OCL tools that can check constraints at runtime. For example, the open source UML tool ArgoUML inserts OCL constraints into generated Java code as doc-style tags. With doc or annotations in your code, you can take advantage of OCL tools (such as ocl4java or the Dresden OCL Toolkit) that perform code enhancement to provide you runtime feedback about constraint violations in your executed code.

Stay on the lookout for developments in this area; as MDA and Executable UML (introduced in Chapter 1) become increasingly central to UML, you can expect even more of these capabilities to be integrated with modeling tools.