Home » Modeling » MDT (Model Development Tools) » Derive constraints
| | | |
| Re: Derive constraints [message #378285 is a reply to message #378284] |
Wed, 09 April 2008 15:03   |
Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Kenn,
This has the unhappy side-effect of actually *modeling* the accessor
operation, which is a Java-ism. This accessor then becomes available to
OCL, resulting in possible confusion and even incompatibility of OCL
expressions with other implementations of the metamodel that don't model
these accessors.
Is it possible that the code generation could elide the accessor operation
from the Ecore representation that results? This, together with the
ability to use package-merge to include the accessors only for codegen but
not the *.metamodel.uml resource, would make a clean metamodel for clients
such as OCL.
Cheers,
Christian
Kenn Hussey wrote:
> Javi,
>
> Yes, the current way to do it (as supported by the UML2 code generator) is
> to introduce an operation that has the same signature as the accessor you
> are looking to derive. Ed's also looking at how to provide built-in
> support for feature derivation in EMF - take a look at
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701.
>
>
> Kenn
-----8<-----
|
|
|
| Re: Derive constraints [message #378286 is a reply to message #378285] |
Wed, 09 April 2008 15:25 |
 Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
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
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ftilrb$k85$1@build.eclipse.org...
> Hi, Kenn,
>
> This has the unhappy side-effect of actually *modeling* the accessor
> operation, which is a Java-ism. This accessor then becomes available to
> OCL, resulting in possible confusion and even incompatibility of OCL
> expressions with other implementations of the metamodel that don't model
> these accessors.
>
> Is it possible that the code generation could elide the accessor operation
> from the Ecore representation that results? This, together with the
> ability to use package-merge to include the accessors only for codegen but
> not the *.metamodel.uml resource, would make a clean metamodel for clients
> such as OCL.
>
> Cheers,
>
> Christian
>
>
> Kenn Hussey wrote:
>
>> Javi,
>>
>> Yes, the current way to do it (as supported by the UML2 code generator)
>> is
>> to introduce an operation that has the same signature as the accessor you
>> are looking to derive. Ed's also looking at how to provide built-in
>> support for feature derivation in EMF - take a look at
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701.
>>
>>
>> Kenn
>
> -----8<-----
|
|
|
| Re: Derive constraints [message #378287 is a reply to message #378286] |
Wed, 09 April 2008 16:26 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
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<-----
|
|
|
| Re: Derive constraints [message #378288 is a reply to message #378287] |
Wed, 09 April 2008 20:12 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
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@ca.ibm.com> wrote in message
news:ftiqmv$ins$1@build.eclipse.org...
> 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<-----
|
|
|
| Re: Derive constraints [message #378289 is a reply to message #378288] |
Wed, 09 April 2008 20:41 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Kenn,
Right, I tend to think of derivations as constraints, too, because they're
specifications (not implementations). :-)
I'll be interested to see what the IMM comes up with. In my opinion, OCL is
very simple (by design) such that it hardly requires savvy-ness. But, I do
understand the "second-class" argument, too. Although constraints are, of
course, and integral and essential part of any model (and thus
first-class), they do take have a very different structure from built-ins
like subsetting and multiplicity.
Thanks again!
cW
Kenn Hussey wrote:
> 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
-----8<-----
|
|
| | | |
| Re: Derive constraints [message #592416 is a reply to message #378284] |
Wed, 09 April 2008 15:03 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Kenn,
This has the unhappy side-effect of actually *modeling* the accessor
operation, which is a Java-ism. This accessor then becomes available to
OCL, resulting in possible confusion and even incompatibility of OCL
expressions with other implementations of the metamodel that don't model
these accessors.
Is it possible that the code generation could elide the accessor operation
from the Ecore representation that results? This, together with the
ability to use package-merge to include the accessors only for codegen but
not the *.metamodel.uml resource, would make a clean metamodel for clients
such as OCL.
Cheers,
Christian
Kenn Hussey wrote:
> Javi,
>
> Yes, the current way to do it (as supported by the UML2 code generator) is
> to introduce an operation that has the same signature as the accessor you
> are looking to derive. Ed's also looking at how to provide built-in
> support for feature derivation in EMF - take a look at
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701
>
>
> Kenn
-----8<-----
|
|
|
| Re: Derive constraints [message #592419 is a reply to message #378285] |
Wed, 09 April 2008 15:25 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
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
"Christian W. Damus" <cdamus@ca.ibm.com> wrote in message
news:ftilrb$k85$1@build.eclipse.org...
> Hi, Kenn,
>
> This has the unhappy side-effect of actually *modeling* the accessor
> operation, which is a Java-ism. This accessor then becomes available to
> OCL, resulting in possible confusion and even incompatibility of OCL
> expressions with other implementations of the metamodel that don't model
> these accessors.
>
> Is it possible that the code generation could elide the accessor operation
> from the Ecore representation that results? This, together with the
> ability to use package-merge to include the accessors only for codegen but
> not the *.metamodel.uml resource, would make a clean metamodel for clients
> such as OCL.
>
> Cheers,
>
> Christian
>
>
> Kenn Hussey wrote:
>
>> Javi,
>>
>> Yes, the current way to do it (as supported by the UML2 code generator)
>> is
>> to introduce an operation that has the same signature as the accessor you
>> are looking to derive. Ed's also looking at how to provide built-in
>> support for feature derivation in EMF - take a look at
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=216701
>>
>>
>> Kenn
>
> -----8<-----
|
|
|
| Re: Derive constraints [message #592426 is a reply to message #378286] |
Wed, 09 April 2008 16:26 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
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<-----
|
|
|
| Re: Derive constraints [message #592436 is a reply to message #378287] |
Wed, 09 April 2008 20:12 |
Kenn Hussey
Messages: 1620
Registered: July 2009 |
Senior Member |
|
|
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@ca.ibm.com> wrote in message
news:ftiqmv$ins$1@build.eclipse.org...
> 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<-----
|
|
|
| Re: Derive constraints [message #592449 is a reply to message #378288] |
Wed, 09 April 2008 20:41 |
| Eclipse User |
|
|
|
Originally posted by: cdamus.ca.ibm.com
Hi, Kenn,
Right, I tend to think of derivations as constraints, too, because they're
specifications (not implementations). :-)
I'll be interested to see what the IMM comes up with. In my opinion, OCL is
very simple (by design) such that it hardly requires savvy-ness. But, I do
understand the "second-class" argument, too. Although constraints are, of
course, and integral and essential part of any model (and thus
first-class), they do take have a very different structure from built-ins
like subsetting and multiplicity.
Thanks again!
cW
Kenn Hussey wrote:
> 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
-----8<-----
|
|
|
Goto Forum:
Current Time: Tue Apr 23 08:45:13 GMT 2024
Powered by FUDForum. Page generated in 0.05541 seconds |
] 
Search
Help
Register
Login
Home
