doc/org.eclipse.ocl.doc/doc/1710-ocl-in-papyrus.textile - ocl/org.eclipse.ocl - Git at Google


 h2(#OCLinPapyrus). OCL in UML (using Papyrus)

 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

 h3(#OCLinPapyrus-UML-integration). UML Integration

 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.

 h3(#OCLinPapyrus-Class-Invariant). Class Invariant

 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

 !{width:100%}images/1710-class-invariant.png(Papyrus Class Invariant)!

 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).

 h3(#OCLinPapyrus-Operation-Constraints). Operation Precondition, Postcondition and Body

 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

 !{width:90%}images/1710-operation-constraints.png(Papyrus Operation Constraints)!

 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.

 h3(#OCLinPapyrus-Property-Initializers). Property Initializers

 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.

 h3(#OCLinPapyrus-Profile-Constraint). Profile Constraint

 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

 !{width:100%}images/1710-profile-constraint.png(Papyrus Profile Constraint)!

 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.

 h3(#OCLinPapyrus-State-Constraint). Statemachine Constraint

 A Constraint may be aplied to a Statemachine in the same way as for a Class to specify an invarinat of the Statemachine.

 h3(#OCLinPapyrus-Transition-Guard). Statemachine Transition Guard

 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

 !{width:100%}images/1710-transition-guard.png(Papyrus Transition Guard)!

 The required Transition is specified as the Guard of the Transition.

 The owning type of the Statemachine defines OCL's @self@.

	h2(#OCLinPapyrus). OCL in UML (using Papyrus)

	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

	h3(#OCLinPapyrus-UML-integration). UML Integration

	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.

	h3(#OCLinPapyrus-Class-Invariant). Class Invariant

	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

	!{width:100%}images/1710-class-invariant.png(Papyrus Class Invariant)!

	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).

	h3(#OCLinPapyrus-Operation-Constraints). Operation Precondition, Postcondition and Body

	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

	!{width:90%}images/1710-operation-constraints.png(Papyrus Operation Constraints)!

	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.

	h3(#OCLinPapyrus-Property-Initializers). Property Initializers

	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.

	h3(#OCLinPapyrus-Profile-Constraint). Profile Constraint

	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

	!{width:100%}images/1710-profile-constraint.png(Papyrus Profile Constraint)!

	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.

	h3(#OCLinPapyrus-State-Constraint). Statemachine Constraint

	A Constraint may be aplied to a Statemachine in the same way as for a Class to specify an invarinat of the Statemachine.

	h3(#OCLinPapyrus-Transition-Guard). Statemachine Transition Guard

	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

	!{width:100%}images/1710-transition-guard.png(Papyrus Transition Guard)!

	The required Transition is specified as the Guard of the Transition.

	The owning type of the Statemachine defines OCL's @self@.