Paper Title: On the Precise Meaning of the OCL Constraints

Presented by Alla Dove

What we want OCL to be

Main Purpose of OCL: Provide precise information in UML, which can be ambiguous

Use in Advanced Support Tools:– check database integrity– check correctness of rules– prove that code never violates the constraints

What OCL is really like

• Lack of precise semantics

Questions:– When during the execution is the validity of invariant

enforced?– Is it possible to specify non-terminating operations in OCL?– What is the meaning when several constraints are attached

to the operation?– What impact do the constraints on the superclass have on

its subclasses?

Invariants

context CheckingAccountinv: bal >= limit

Problem

Question: When during the execution is the validity of invariant enforced?

bal = $100withdraw ($70) => bal = $30deposit ($30) => bal = $60withdraw ($70) => bal = -$10deposit ($30) => bal = $20

Need to have a checkpoint at the end of a series of transfers.

Proposed Informal Semantics

• If an operation is used to compute intermediate results, use “volatile” property

volatile=true => invariant is not enforced

context CheckingAccountinv: bal >= limit

context CheckingAccount::withdraw(n:Interger): void volatile=true…

Undefinedness of Pre and Post

Undefinedness = non-existence of result– Exception undefinedness • division by zero• accessing object through a reference which is null

– Non-termination undefinedness • loops that run forever

Problem

Question: Is it possible to specify non-terminating operations in OCL?

In OCL, an operation is always required to terminate.

“Exception undefinedness” only

Proposed Solution

• Require all query operations defined in OCL to terminate

• Other operations transforming the state may or may not terminate

Splitting of ConstraintsQuestion: What is the meaning when several constraints are attached to the same operation?

Complex post and pre conditions are split into smaller ones:

context CheckingAccount::withdraw(n: Integer)pre: (n>=0) and (bal – n >=limit)post: bal = bal@pre – n

context CheckingAccount::withdraw(n: Integer)pre: n>=0post: true

context CheckingAccount::withdraw(n: Integer)pre: bal – n >=limitpost: bal = bal@pre – n

May not always be a good idea;some parts may not be satisfiedn=2bal=1limit=0

Inheritance of Constraints

Question: What impact do the constraints on the superclass have on its subclasses?

Liskov’s Substitution Principle:A class can always be substituted by any of its subclasses.

Proposed Solution

Two approaches:1. Make developer responsible

- may overlook critical cases- not consistent with object-oriented paradigm

2. Consider all constraints on superclass to be constraints on its subclasses.

context A inv: INV1context A::op(x:T)pre: PRE1post: POST1

context B inv: INV2context B::op(x:T)pre: PRE2post: POST2X

context B inv: INV1 and INV2context B::op(x:T)pre: PRE1 and PRE2 post: POST1 and POST2

Exercise

context CheckingAccountinv: bal >= limit

context CheckingAccount::withdraw(n: Integer)pre: (n>=0) and (bal – n >=limit)post: bal = bal@pre – n

context Accountinv: bal >0

context Account::deposit(n: Integer)pre: n>0post: bal = bal@pre + n

What is the full list of OCL constraints for CheckingAccount?

Result:

context CheckingAccountinv: bal >0 and bal >= limit

context CheckingAccount::deposit(n: Integer)pre: n>0post: bal = bal@pre + n

context CheckingAccount::withdraw(n: Integer)pre: (n>=0) and (bal – n >=limit)post: bal = bal@pre – n