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 CheckingAccount
inv: bal >0 and bal >= limitcontext 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