On The Precise Meaning of OCL Constraints

1. On The Precise Meaning of OCL Constraints Cesar Chacon October 4th 2012

2. Using OCL with Advanced Support Tools -Generating assertion code from OCL or by using the integrity checking mechanisms of database systems. –To experiment with symbolic representations of possible object configurations, as a means to check consistency and correctness of the rule set. –To statically prove that the code never violates the constraints.

3. Invariants "Invariants must be true upon completion of the constructor and every public method but not necessarily during the execution of methods." Volatile {volatile=true}(abbreviated by {volatile} This indicates that the operation does not require validity of the invariants at the end of its execution.

4. Undefinedness Exception undefinedness: Non-termination undefinedness:

5. Partial Correctness If an answer is returned it will be correct. op(x) is PC w.r.t. PRE and POST conditions if: PRE is valid for given snapshot of σ and if the application of op to σ leads to a defined result, then POST is valid for the resulting system state.

6. Total Correctness Correctness + Termination = Total Correctness. op(x) is TC w.r.t. PRE and POST conditions if: PRE is valid for given snapshot of σ then the application of op to σ leads to a defined result, then POST is valid for the resulting system state.

7. Preconditions "The precondition is not the operation under which operation is called. [...] The precondition is is the condition under which the operation guarantees that the postcondition will be true"

8. Partial Exception Correctness op(x) is PEC w.r.t. PRE and POST conditions if: -op is PC w.r.t. PRE and POST - If the application of op to σ leads to a defined result, then PRE has held at invocation time. Example where a is an account: a.depost(5) being undefined it not excluded in PEC

9. Total Exception Correctness op(x) is TEC w.r.t. PRE and POST conditions if: -op is TC w.r.t. PRE and POST - The application of op to σ leads to a defined result, iffPRE has held at invocation time.

10. Splitting of Constraints Means: Specifying several PRE and POST condition constraints for the same operations. - Splitting and Merging constraints - Transformation rules to combine constraints PRE1 PRE2 PRE POST1 POST2 POST

11. Transformation Rule for PC context C::op(x: T) pre: PRE2 post: POST2 context C::op(x: T) pre: PRE1 post: POST1 context C::op(x: T) pre: true post: (PRE1@pre implies POST1) and (PRE2@pre implies POST2)

12. Transformation Rule for TC context C::op(x: T) pre: PRE2 post: POST2 context C::op(x: T) pre: PRE1 post: POST1 context C::op(x: T) pre: PRE1 or PRE2 • post: (PRE1@pre implies POST1) and (PRE2@pre implies POST2)

13. Transformation Rule for PEC context C::op(x: T) pre: PRE2 post: POST2 context C::op(x: T) pre: PRE1 post: POST1 context C::op(x: T) pre: PRE1 and PRE2 post: POST1 and POST2

14. Transformation Rule for PEC It doesn't work properly w.r.t. splitting constraints! For this case: The combination of two OCL-Constraints only works if the two preconditions are equivalent. In all other cases one will end up with an inconsistent specification.

15. Inheritance of Constraints context A inv: INV1 context A::op(x: T) pre: PRE1 post: POST1 context B inv: INV2 context B::op(x: T) pre: PRE2 post: POST2 PEC Complerion of the constraints for Class B (In the blue box) context B inv: INV1 and INV2 context B::op(x: T) pre: PRE1 and PRE2 post: POST1 and POST2

16. Abstract Semantics

17. Conclusion • There are several variants for the precise meaning of OCL constraints in the context of UML. • We can use transformation rules to combine or split multiple PRE and POST conditions on functions. • We can use transformation rules to combine PRE and POST conditions from parent classes and subclasses to gain an insight on the implications of inheritance.