[news.eclipse.modeling.mdt] Re: Derive constraints

["Kenn Hussey" <Kenn.Hussey@xxxxxxxxxxxxxxx>]

Christian,

Some of the "additional" operations in UML are for the purposes of invariant 
constraints, but others are not. Some (a small number) of them are defined 
specifically to provide the derivation for derived properties.

Regarding the IMM specification, those of us that are OCL savvy asked the 
same question of those that were proposing an alternative (simple) 
formalism. I think it comes down to a decision about which things need to be 
"first class" concepts in the metamodel (like multiplicities, redefinitions, 
etc.) and which should get "second class" (e.g. via constraints) 
treatment...

Kenn

"Christian W. Damus" <cdamus@xxxxxxxxxx> wrote in message 
news:ftiqmv$ins$1@xxxxxxxxxxxxxxxxxxxx
> Hi, Kenn,
>
> Thanks for your reply.
>
> There are two problems with the operation visibility:  Ecore doesn't model
> visibilities (does UML provide some kind of annotation?) and OCL ignores
> visibility, anyway (as a constraint specification language, is has 
> god-like
> powers of perception).  This isn't particularly important to me,
> personally, but I thought I should raise the question.
>
> Interestingly, the "additional operations" defined using OCL cannot 
> actually
> (formally) specify any visibility, as the OCL syntax has no such 
> mechanism.
> Which makes sense, because the purpose of additional operations is to
> assist the definition of OCL constraints, which ignore visibility,
> anyway.  :-)
>
> The UML specification does provide a considerable number of additional
> operations (specified using OCL).  I've noticed, however, that this is the
> *only* manifestation of operations in the UML.  Did the UML authors decide
> that they would never actually model operations in their metaclasses?  The
> only features actually provided by the UML's metaclasses are properties.
> It seems odd.
>
> I'm curious to know why OCL isn't a sufficient formalism for specification
> of property derivation in the IMM...
>
> Cheers,
>
> Christian
>
>
> Kenn Hussey wrote:
>
>> Christian,
>>
>> I'm not sure that defining an operation to describe the mechanism by 
>> which
>> a value is derived is necessarily a Java-ism. This convention of using
>> (OCL) operations to describe how properties are derived was used in the
>> UML metamodel/specification long before the Java implementation was
>> provided at Eclipse. I agree that it's awkward (like many things in UML).
>> We're actually looking at formalizing the way types and proeperties can 
>> be
>> derived based on other types/properties as part of the IMM specification
>> submission at the OMG...
>>
>> In the meantime, could the visibility of the operation not be used to
>> restrict its exposure via OCL? For example, I usually make all of my
>> "implementation" operations protected...
>>
>> Kenn
>
> -----8<-----