Paper Title: On the Precise Meaning of the OCL Constraints

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 areattached to the operation? • What impact do the constraints on the superclass have on its subclasses?

Invariants context CheckingAccount inv: bal >= limit

Problem Question: When during the execution is the validity of invariant enforced? bal = $100 withdraw ($70) => bal = $30 deposit ($30) => bal = $60 withdraw ($70) => bal = -$10 deposit ($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 CheckingAccount inv: bal >= limit context CheckingAccount::withdraw(n:Interger): void volatile=true …

Undefinedness of Pre and Post Undefinedness = non-existence of result • Exceptionundefinedness • 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 Constraints Question: What is the meaning when several constraints areattached 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>=0 post: true context CheckingAccount::withdraw(n: Integer) pre: bal – n >=limit post: bal = bal@pre – n May not always be a good idea; some parts may not be satisfied n=2 bal=1 limit=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. X context B inv: INV1 and INV2 context B::op(x:T) pre: PRE1 and PRE2 post: POST1 and POST2

Exercise context Account inv: bal >0 context Account::deposit(n: Integer) pre: n>0 post: bal = bal@pre + n context CheckingAccount inv: bal >= limit context CheckingAccount::withdraw(n: Integer) pre: (n>=0) and (bal – n >=limit) post: bal = bal@pre – n What is the full list of OCL constraints for CheckingAccount?

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

Paper Title: On the Precise Meaning of the OCL Constraints