OMG specs and reference implementations



OMG specs and reference implementations

From: Rafael Chaves <rchaves.jug_at_gmail.com>
Date: Tue, 16 May 2006 09:55:53 -0400
Message-ID: <4469D9E9.9030601@gmail.com>
Hi all,

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?

Thanks,

Rafael

Waldin, Earl wrote:
> Hi
>  
> 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
>  
>   http://www.omg.org/issues/ocl2-rtf.open.html#Issue8937
>  
> Now, what /we/ think it should be is a different issue!
>  
>     -Earl Waldin
> 
>     -----Original Message-----
>     *From:* puml-list-request@cs.york.ac.uk
>     [mailto:puml-list-request@cs.york.ac.uk] *On Behalf Of *Anneke Kleppe
>     *Sent:* Tuesday, 16 May, 2006 13:49
>     *To:* puml-list@cs.york.ac.uk
>     *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" <pschmitt@ira.uka.de> 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
>>syntax:
>>   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 :-)
>>
>>Achim
>>  
Received on Tue 16 May 2006 - 14:55:46 BST