The Dresden OCL Toolkit is probably the longest serving implementation and
its maintainers have put great effort into assuring compliance with current
standards. Dresden OCL also benefits from close involvement of one of its
present and former staff with the OMG standardisation effort.
However, the OMG has not elected or promoted a reference implementation.
This is mainly for political and economic reasons, as it would force other
members of the OMG to comply. Also, the OMG is a commercial organisation, so
research groups do not appear as players and can not provide substantial
However, the OCL community seems to agree that harmonisation is a necessary
goal: There are a great number of interesting implementations available in
academia, whose use is limited due to lack of code exchangeability. For this
reason, the last OCL workshop promoted the creation of a central hub to
facilitate discussion and foster consolidation of the standard outside the
OMG. You will find the resolution reflected in the report on the workshop in
the satellite volume of models 2004:
Since the 2004 workshop TU Dresden has acted on this resolution and provided
the common point of reference. From my point of view, the next steps in
consolidation would require the specification of a number of test cases and
models, which could be used by domain members to verify their
implementation. Such concrete compliance tests could then be used to provide
a table of implementations, showing supported and missing features.
Finally, you may have gotten the wrong impression about OCL from the
preceding discussion. Unfortunately, it touched upon a widely debated
language feature of OCL. (Other candidates for such debate would likely be
transitive closures, handling of tri-valued logic, and non-determinism
caused by ->any() and ->asSequence() operators.) However, most of OCL is
fairly consolidated. So I have faith that we will eventually converge on
quality implementations that can serve as a reference.
Jörn Guy Süß
Room 350, General Purpose South Building (building 78) Division of Systems
and Software Engineering School of Information Technology and Electrical
Engineering The University of Queensland Queensland 4072 AUSTRALIA
Phone: +61 7 3365 2883; Fax: +61 7 3365 4999
[mailto:firstname.lastname@example.org] On Behalf Of Rafael Chaves
Sent: Tuesday, 16 May 2006 23:56
Subject: OMG specs and reference implementations
Reading the thread 'asking about OCL', I was amazed by how much debate
was created by such a simple language feature. I guess this is a big
weakness in OMG's approach of publishing specifications and letting
others implement them later, without a reference
implementation/compatibility testing tools.
I have the impression that the UML2 project from eclipse.org is seen as
the reference implementation for UML 2.*. Is that correct? If so, will
OCL have a reference implementation as well?
Waldin, Earl wrote:
> While we are on the issue of notation for class properties/operations
> (i.e. static properties/operations), may I point out that OCL 2.0 did
> change from using the UML 1.4 '.' notation to the '::' notation! One
> may not have noticed this because Chapter 7 of the specification still
> uses the old syntax. However, Chapter 7 is only informative and not
> normative. Chapter 9, which defines the concrete syntax and which I
> assume is normative, uses '::'. I am referring to the OCL version in the
> current finalization task report (ptc/2005-06-06), which, barring any
> catastrophe, will become the formal version. So the expected formal
> version will not be consistent in this point. This has been brought to
> the attention of the OMG in "Issue 8937: Notation for accessing class
> operations is inconsistent (ocl2-rtf)" which you can find at
> Now, what /we/ think it should be is a different issue!
> -Earl Waldin
> -----Original Message-----
> *From:* email@example.com
> [mailto:firstname.lastname@example.org] *On Behalf Of *Anneke Kleppe
> *Sent:* Tuesday, 16 May, 2006 13:49
> *To:* email@example.com
> *Subject:* [Fwd: Re: asking about OCL]
> The predefined operation /allInstances /is an operation that
> effectively works on a class, not on an instance. It does not make
> sense to ask for the set of all instances from a single instance,
> instead you should ask its class. This has not been addressed in the
> OCL specification properly. There is a bit of cryptic text that
> says: "Returns all instances of self. Type T is equal to self." In
> my opinion, the operation /allInstances /should have been defined as
> an instance of class /Feature /(UML Superstructure, section 7.3.10)
> with attribute '/isStatic/' set to true.
> In OCL all static features, attributes or operations, are referenced
> using the double colon notation. Therefore, in my opinion, the
> correct notation would be the one that Steffen mentioned:
> A::allInstances(). Unfortunately, all examples in the OCL spec. use
> the single dot notation, but they do use 'CLASSNAME.allInstances()',
> not self.allInstances(). As I said, the latter expression does not
> make any sense at all. In fact, in our book and in the Octopus tool,
> the double colon notation is the only one that is regarded correct.
> I hope this helps to clear things up.
> Anneke Kleppe
> Achim D. Brucker wrote:
>>"Prof. Dr. Peter H. Schmitt" <firstname.lastname@example.org> schrieb:
>>>That is strange. I would have thougth Steffen Zschaler's comment correct.
>>>Is there a definite way to settle disputes of this kind?
>>in the OCL 2.0 standard, "allInstances" is defined as being an
>>operation of class OclAny (e.g. see chapter 11 of the standard)
>>and thus its use should be similar to other operations defined
>>within OclAny, e.g. "_=_" or oclIsNew(). Therefore, on any
>>instance variable, i.e., self, one can write
>>"self.allInstances()". And by the way, the Dresden OCL Parser
>>also uses this as concrete syntax :-).
>>In the old OCL 1.1 standard, "allInstances()" is declared
>>as operation of type OclType. This leads just to another concrete
>> context Person:
>> inv: Person.allInstances->size() >1
>>The notion "Person::allInstances" emerges often, but I have no idea
>>from where it comes, albeit I have often used it myself :-)
To remove yourself from this list please mail
with a message containing the word "unsubscribe".
Received on Wed 17 May 2006 - 02:07:25 BST