Re: Invariants evaluating to undefined

Re: Invariants evaluating to undefined

From: Prof. Dr. Peter H. Schmitt ^lt;>
Date: Fri 07 Apr 2006 - 08:53:30 BST
Message-ID: <>
D H. Akehurst wrote:
> I cannot see the advantage of having OclVoid/null and OclInvalid.
> To my mind, 'null' could be a literal representation of OclUndefined 
> which is of type OclVoid - i.e. as per the old version of OCL
> this works as far as I can see.
> Does someone have an example of a situation where it is necessary to 
> have the new Invalid/null division?

We use OCL to write specification for JavaCard programs. We have 
extended OCL, before the advent of OCL2.0, by a type Null containing 
only the literal null. We tought, and still think, of it as an OCL 
profile for Java specifications. In this context it does make sense,
since we have to have access to the null object also on the OCL language 
level and it also makes sense to have Null be a subtype of every other
model type, not of data types like integers.
I share D.H. Akehurst's scepticism on OclVoid in general. The 
explanation that Earl Waldin dug out

   LiteralNull and OclInvalid to distinguish between the situations
    where we have an absence of value (LiteralNull) and an invalid events
    (such as division of zero).

may sound nice at first sight, but when you start thinking about it, it
grumbles into meaninglesness. To start with: why is 5/0 an event? I 
thought of it as an absence of value.

There is a (ridiculous) amount of literature on dealing with 
undefinedness in logic. The best way for the OCL standard to go,
as I see it, is to declare certain expressions to be undefined  by using 
the Boolean query oclIsUndefined(), and not
include any commitment how the logic should handle this. The  approach 
to use three-valued logic, which has led to the introduction of the type 
OclInvalid and the literal it contains, is just one way to do so and 
only half-heartedly persued in the standrad documents. We found the use 
of underspecification much more usefull.

regards  Peter

Fakultät für Informatik
Universität Karlsruhe
Received on Fri Apr 07 08:53:52 2006