OCL (was: Introducing myself + question)

Technical (archive)
1

Hi Thomas,
I appreciate the trouble you've taken to evaluate OCL, and think several
of the issues are worthy of consideration.
Just for your information, and for others on this list, the latest
version of the OCL 2.0 submission is 1.6 (as opposed to 1.0 you reviewed
which is 2.5 years old!). This is due to be adopted later today, as it
happens.
Despite the imminent adoption it is still possible to submit issues to
OMG's Finalization Task Force which is responsible for considering
implementation and other issues prior to the standard becoming
officially 'Finalized' and 'Available'. To do this just send an email to
issues@omg.org, or fill in the form at the OMG web site
http://www.omg.org/technology/issuesform.htm.

In general OMG attempts to be an open and responsive organization and
anyone (not only members) can raise issues against any OMG
specification. Though OMG can only address issues if it know about them
- so I would sincerely encourage people to use the mechanisms available.

However, while I must admit a bias as one of the submitters of OCL 2.0,
I would disagree that the semantics are 'quite broken'. I assume the
following from the review is intended to illustrate 'broken semantics':
--->
In section 2.5.4, subsection "Navigation over Associations with
Multiplicity Zero or One" it is stated that "...a single object can be
used as a set as well. It then behaves as if it is a Set containing the
single object...". I had to read this a few times to believe it. While
there is clearly a drive to make everything somehow the same for the
purpose of querying, there is no way a formal type system can be
respected if such liberties are taken - the basis of correct
specifications disappears. There is no way, for example, that
PERSON.manager: PERSON can act as a Set<> if has been specified as a
PERSON - these are two distinct types, and have nothing to do with each
other. "
<---

I view treating a single object as a set as a convenient implicit 'cast'
operation. Most programming languages have such a thing: e.g. to allow
an Integer to be treated as a Real. And if really concerned about the
difference OCL has capabilities to distinguish an object from a set.

Finally, with regard to implementability, there are several
implementations of OCL in existence (currently of OCL 1, though OCL 2
does not introduce any radically new capabilities). These exist in both
commercial products (e.g. BoldSoft, now part of Borland) and
university/research projects (e.g. Kent Modelling Framework -
www.cs.ukc.ac.uk/kmf).

Regards
Pete

Pete Rivett (pete.rivett@adaptive.com)
Consulting Architect, Adaptive Inc.
Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK
Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448
http://www.adaptive.com

2

Hi Pete,

Pete Rivett wrote:

Hi Thomas,
I appreciate the trouble you've taken to evaluate OCL, and think several
of the issues are worthy of consideration. Just for your information, and for others on this list, the latest
version of the OCL 2.0 submission is 1.6 (as opposed to 1.0 you reviewed
which is 2.5 years old!). This is due to be adopted later today, as it
happens.

I reviewed the version I did because it was the one passed around (or referred to with a URL, I forget which) recently by HL7...Can you provide a URL to the latest submission?

Despite the imminent adoption it is still possible to submit issues to
OMG's Finalization Task Force which is responsible for considering
implementation and other issues prior to the standard becoming
officially 'Finalized' and 'Available'. To do this just send an email to
issues@omg.org, or fill in the form at the OMG web site
http://www.omg.org/technology/issuesform.htm.

I guess I could do this, but I don't imagine they are going to be interested in anything but tiny details by now...

In general OMG attempts to be an open and responsive organization and
anyone (not only members) can raise issues against any OMG
specification. Though OMG can only address issues if it know about them
- so I would sincerely encourage people to use the mechanisms available.

my general impression of the OMG, and experience with members of HDTF certainly supports, this, and I think that OMG is overall an organisation with good process, timeliness, and a good track record....in a way it is a pity that HDTF (health domain task force) has little support at the moment (or so I've been told) since the OMG process is definitely superior to that in other standards organisations. But - that's a conversatino for another day/mailing list!

However, while I must admit a bias as one of the submitters of OCL 2.0,
I would disagree that the semantics are 'quite broken'. I assume the
following from the review is intended to illustrate 'broken semantics': --->
In section 2.5.4, subsection "Navigation over Associations with
Multiplicity Zero or One" it is stated that "...a single object can be
used as a set as well. It then behaves as if it is a Set containing the
single object...". I had to read this a few times to believe it. While
there is clearly a drive to make everything somehow the same for the
purpose of querying, there is no way a formal type system can be
respected if such liberties are taken - the basis of correct
specifications disappears. There is no way, for example, that
PERSON.manager: PERSON can act as a Set<> if has been specified as a
PERSON - these are two distinct types, and have nothing to do with each
other. "
<---

yes, this is the major problem I see. It is quite pervasive as well.

I view treating a single object as a set as a convenient implicit 'cast'
operation. Most programming languages have such a thing: e.g. to allow
an Integer to be treated as a Real.

well actually, this capability is not casting, but "type promotion", and only applies (as far as I know) to numeric types to enable infix/prefix arithmetic and relational operator semantics (e.g. "3.0 + 1" and "3.1415926 < 2.171828") to be evaluated. Type promotion of numeric types is quite a specific feature, and is done by compilers, not programmers. Casting on the other hand is almost always a dangerous and bad thing. I can't think of any code where it was justified, where the language itself was not already the problem, e.g. by not having generic classes, the lack of whcih is the main reason for programmers being forced to cast.

But the real problem is that turning an Integer into a Real is reasonable: they have almost the same interface. Turning PERSON into SET<PERSON> makes no sense - there are no similarities between the interface of a T and a Set<T> in general. No common programming languages support this natively (I'm sure there is some academic language which does), and if programmers start doing such casts, they will get into serious trouble.

Secondly, this feature of OCL seems to prevent simple statements like:

context PERSON
inv: employer <> null

This is the most common kind of statement one wants to make in invariants, pre- and post-conditions. I cannot imagine why it is not available (maybe it is - it wasn't apparent to me in the spec, nor to the authors of another report on OCL which I have seen).

And if really concerned about the
difference OCL has capabilities to distinguish an object from a set.

do you mean the dot and arrow notation?

Finally, with regard to implementability, there are several
implementations of OCL in existence (currently of OCL 1, though OCL 2
does not introduce any radically new capabilities). These exist in both
commercial products (e.g. BoldSoft, now part of Borland) and
university/research projects (e.g. Kent Modelling Framework -
www.cs.ukc.ac.uk/kmf).

this is good to know. However, I feel it is a real pity to have this problem of Set<T>/T in OCL - I think it's a real error in OCL, especially as the rest of OCL is pretty good, and quite powerful.

- thomas beale

3

Dear all,

I have started looking at the latest OCL submission. A lot of work has obviously been done, but it seems it is still not possible to write the most basic of all constraints, e.g.###

context Person inv:

wife <> null

and

context Person inv:

wife <> null implies wife.gender = Gender::female

Instead one is forced to write:

context Person inv:

wife->notEmpty() implies wife.gender = Gender::female

which is not only counter-intuitive (Person.wife is not defined as a Set of anything, it is defined as a Person), but seems wrong because there is no formal connection between whatever Set the expression “wife->” refers to and the underlying model, so how can one say anything about what the membership of this set might imply for the value of the Person at the other end of the wife association?

I think that the real problem is that UML sees associations as somehow different from attributes, when there is no difference - except graphically. I still cannot see how a Set can be called a “convenient” cast of Person - what language allows this?

have I misread the submission?

  • thomas beale

Pete Rivett wrote:

4

Instead one is forced to write:

context Person inv:

wife->notEmpty() implies wife.gender = Gender::female

which is not only counter-intuitive (Person.wife is not defined as a Set of anything, it is defined as a Person), but seems wrong because there is no formal connection between whatever Set the expression "wife->" refers to and the underlying model, so how can one say anything about what the membership of this set might imply for the value of the Person at the other end of the wife association?

but it's worse than this in practice. if wife is null, therefore
wife->isEmpty is true. Therefore wife.Gender = Gender::female is
true, because there is no wife in the list that breaks this
constraint.

This is not intuitive but is an inevitable conclusion from the
use of wife->notEmpty() to specify that wife != null.

Obviously it's safe if you write
inv: not (wife->notEmpty()) and (wife.gender = Gender::female)

but most people wouldn't think of doing this and would simply
write
inv: wife.gender = Gender::female

expecting that this would only be true if wife.Gender actually
was Gender::female

Grahame

5

You should use "not(wife.oclIsUndefined())" as opposed to
"wife->notEmpty()". This avoids the problems you outline about treating
the value as a Set.

There was a conscious decision not to use null: this is a quote from a
response I had from the submission lead on the subject:

"Null is not defined in the spec. You should test the value for =
Undefined.
We have not put both Null and Undefined in the spec, because that will
raise many discussions about different types of being void."

However I can see that this is a decision we may wish to review as part
of the Finalization process and input from people such as yourselves.
Personally I think oclIsUndefined may be too broad.

Note that those interested who are OMG members can sign themselves up to
the FTF mailing list without being official FTF members. The FTF will be
cartered in the June Paris meeting.

Regards
Pete

Pete Rivett (pete.rivett@adaptive.com)
Consulting Architect, Adaptive Inc.
Dean Park House, 8-10 Dean Park Crescent, Bournemouth, BH1 1HL, UK
Tel: +44 (0)1202 449419 Fax: +44 (0)1202 449448
http://www.adaptive.com

6

Apologies - my last reply was wrong, since the spec does say to use
isEmpty() to test for lack of a value: in section 2.5.3 (under
"Navigation over Associations with Multiplicity Zero or One").

This section does make the point that the -> operator can be treated as
a 'cast to set' operator, and that without it the property value can not
be treated as a set. Does that make things more coherent in your
opinion?

Hope that makes things clearer. Sorry about the confusion.

Pete