The behaviour of an UML model may be elaborated using OCL to define
operation bodies
property derivations/initializers
class invariants to be observed by user models
metaclass invariants to be observed by class diagrams
guards for state machines
Although the UML metamodel makes extensive use of OCL to specify its own well-formedness, there is no explicit ability to use OCL within UML. Usage of OCL, or any other language, is enabled by the flexibility of the ValueSpecification class and the OpaqueExpression extension.
The metamodel specifies the usage of a ValueSpecification wherever a value can sensibly be provided by a variety of technologies. Simple values can be provided by for instance a LiteralString or LiteralInteger. More interesting values by an OpaqueExpression that has two interesting list features, one of language names and the other of string bodies in the corresponding language. The lists provide an ability to provide implementations in a variety of languages. In practice only one is used and if the language name is omitted, an implementation default of OCL is assumed.
Specification of a behaviour such as “name.toUpper()” can be achieved by an OpaqueExpression in which the language is Sequence(‘OCL’) and the body is Sequence(‘name.toUpper()’). The OCL is therefore embedded in a textual form that has no knowledge of the classes in OCL metamodel.
Users of the OCL Java API may avoid the need to incur OCL parsing costs by exploiting OCL’s ExpressionInOCL class that extends ValueSpecificaion and delegates functionality to an OCLExpression.
A class invariant specifies a constraint that must be true for all well-formed instances of the class. It is specified in Papyrus, by:
creating a Constraint Node on a Class Diagram
dismissing the premature editor popup
optionally drawing a Link from the Constraint to a Class to be constrained
optionally replacing the auto-generated Constraint name
defining the Context in which the Constraint is to be evaluated
defining the Specification of the Constraint with OCL text
Note that the editor that opens automatically when creating a Constraint Node must be dismissed by clicking on the diagram, since no Constraint implicitly or explicitly involving
self
can be entered before the Context has been defined.
Note that the Constrained Element associated with the Link drawn between Constraint and Class has no functional utility. It is the Context that defines OCL’s
self
and so the Context that actually defines what is constrained.
You may provide the OCL text directly from The Properties View, however the resulting Wizard provides no syntax checking, highlighting or context assist. The Essential OCL editor may be activated by direct edit; select the Constraint then press F2. (Note that the editor has a significant start up time on the first usage, so be patient).
Preconditions specify constraints that must be satisfied before operation execution starts.
Postconditions specify constraints that must be satisfied after operation execution finishes. Postconditions may use the reserved parameter name
result
to refer to the one result permitted by OCL. The @pre suffix may be used to refer to the state of variables prior to execution of the operation.
In OCL, a body-expression defines the functionality of the operation as a result-type-valued expression such as
some-computation
. In contrast in UML, a body-condition defines the functionality of the operation as a Boolean-valued constraint on the result such as
result = some-computation
.
In Papyrus, preconditions, postconditions and a body-condition are all drawn by
creating a Constraint Node on a Class Diagram
dismissing the premature editor popup
optionally replacing the auto-generated Constraint name
adding the Constraint to the appropriate Precondition, Postcondition, Body-condition of an Operation
defining the Specification of the Constraint with OCL text
Note that the editor that opens automatically when creating a Constraint Node must be dismissed by clicking on the diagram, since no Constraint implicitly or explicitly involving
self
can be entered before the Context has been defined.
Note that in Papyrus 0.10.0, it is not currently possible to draw a Link from Constraint to Operation.
Note that in Papyrus 0.10.0, there is no stereotype display to indicate the precondition/postcondition/body-condition role.
Note that in Papyrus 0.10.0, the Context field in the Properties View for a Constraint should not be used for an Operation since it is unclear which of the three possible constraint features is required. Instead use the Advanced Tab so that the required Constraints can be edited unambiguously.
Note that the OCL expressions for preconditions ad postconditions should be Boolean-valued. The result-valued body-expression form should be used for a body-condition.
The owning type of the Operation is used as OCL’s
self
context.
Papyrus 0.10.0 does not support the use of an OCL-valued OpaqueExpression to define the default or derived value of a Property initializer.
A Profile Constraint is very similar to a Class Invariant. However since the Profile is Constraint is drawn at M2, it may be evaluated at M1 to check a UML Class Diagram for consistency. In contrast a Class Invariant drawn at M1, may be evaluated by user tooling at M0 to validate user models. It is specified in Papyrus, by:
creating a Constraint Node on a Profile Diagram
dismissing the premature editor popup
optionally replacing the auto-generated Constraint name
defining the Context in which the Constraint is to be evaluated
defining the Specification of the Constraint with OCL text
Note that Papyrus 0.10.0 does not support drawing a Link to a Metaclass. This is only a visual inelegance, since the link has no functional significance.
A Constraint may be aplied to a Statemachine in the same way as for a Class to specify an invarinat of the Statemachine.
The guard condition of a Statemachine Transition may be specified by associating a Constraint with a transition. It is drawn in Papyrus by
creating a Constraint Node on a Statemachine Diagram
dismissing the premature editor popup
optionally replacing the auto-generated Constraint name
defining the Guard in which the Constraint is to be evaluated
defining the Specification of the Constraint with OCL text
The required Transition is specified as the Guard of the Transition.
The owning type of the Statemachine defines OCL’s
self
.