Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » MDT (Model Development Tools) » Derive constraints
Derive constraints [message #378281] Wed, 09 April 2008 05:39 Go to next message
Javi is currently offline Javi
Messages: 8
Registered: July 2009
Junior Member
Is it possible to define derive constraints (OCL would be my preference)
for UML properties and get EMF to generate the proper code?

The article "Implementing Model Integrity in EMF with MDT OCL" makes it
work for OCL. My question is about doing the same in UML.

Thanks
Re: Derive constraints [message #378282 is a reply to message #378281] Wed, 09 April 2008 08:48 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn Hussey
Messages: 1618
Registered: July 2009
Senior Member
Javi,

This is really a question for the UML2 newsgroup (copied). Yes, this support
was added to last year's UML2 release (2.1) - see
http://wiki.eclipse.org/index.php/MDT_1.0_New_and_Noteworthy #OCL_Integration.
See also
https://eclipsecon.greenmeetingsystems.com/attachments/downl oad/286.

Kenn

"Javi" <jfbriones@yahoo.com> wrote in message
news:2916e15a0b464d493ad2d28257cdf60c$1@www.eclipse.org...
> Is it possible to define derive constraints (OCL would be my preference)
> for UML properties and get EMF to generate the proper code?
>
> The article "Implementing Model Integrity in EMF with MDT OCL" makes it
> work for OCL. My question is about doing the same in UML.
>
> Thanks
>
Re: Derive constraints [message #378283 is a reply to message #378282] Wed, 09 April 2008 09:57 Go to previous messageGo to next message
Javi is currently offline Javi
Messages: 8
Registered: July 2009
Junior Member
Hello Kenn,

Currently I'am successfully using OCL to create body expressions. I saw in
the references you gave me how invariant constraints could be specified as
well.

But what I would like to have is to specify the body of derived properties.

For example, in the example of Car-Person, imagine I would like to have a
property in Car:

Car::/ownerAge (result = self.owner.age)

Thus, I would not need to insert code in Car.getOwnerAge(). In UML I do
not have the method getOwnerAge() only the derived property ownerAge.

I just tried to create in UML the method getOwnerAge() besides the
property ownerAge and it seems to work. Is this the way to do it? Is it
required to add the getter in UML?

Thank you.
Re: Derive constraints [message #378284 is a reply to message #378283] Wed, 09 April 2008 10:23 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn Hussey
Messages: 1618
Registered: July 2009
Senior Member
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

"Javi" <jfbriones@yahoo.com> wrote in message
news:2ac33d93a79c06410006f82f51a620c5$1@www.eclipse.org...
> Hello Kenn,
>
> Currently I'am successfully using OCL to create body expressions. I saw in
> the references you gave me how invariant constraints could be specified as
> well.
>
> But what I would like to have is to specify the body of derived
> properties.
>
> For example, in the example of Car-Person, imagine I would like to have a
> property in Car:
>
> Car::/ownerAge (result = self.owner.age)
>
> Thus, I would not need to insert code in Car.getOwnerAge(). In UML I do
> not have the method getOwnerAge() only the derived property ownerAge.
>
> I just tried to create in UML the method getOwnerAge() besides the
> property ownerAge and it seems to work. Is this the way to do it? Is it
> required to add the getter in UML?
>
> Thank you.
>
Re: Derive constraints [message #378285 is a reply to message #378284] Wed, 09 April 2008 11:03 Go to previous messageGo to next message
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 11:25 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn Hussey
Messages: 1618
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 12:26 Go to previous messageGo to next message
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 16:12 Go to previous messageGo to next message
Kenn Hussey is currently offline Kenn Hussey
Messages: 1618
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 16:41 Go to previous message
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 #592380 is a reply to message #378281] Wed, 09 April 2008 08:48 Go to previous message
Kenn Hussey is currently offline Kenn Hussey
Messages: 1618
Registered: July 2009
Senior Member
Javi,

This is really a question for the UML2 newsgroup (copied). Yes, this support
was added to last year's UML2 release (2.1) - see
http://wiki.eclipse.org/index.php/MDT_1.0_New_and_Noteworthy #OCL_Integration
See also
https://eclipsecon.greenmeetingsystems.com/attachments/downl oad/286

Kenn

"Javi" <jfbriones@yahoo.com> wrote in message
news:2916e15a0b464d493ad2d28257cdf60c$1@www.eclipse.org...
> Is it possible to define derive constraints (OCL would be my preference)
> for UML properties and get EMF to generate the proper code?
>
> The article "Implementing Model Integrity in EMF with MDT OCL" makes it
> work for OCL. My question is about doing the same in UML.
>
> Thanks
>
Re: Derive constraints [message #592392 is a reply to message #378282] Wed, 09 April 2008 09:57 Go to previous message
Javi is currently offline Javi
Messages: 8
Registered: July 2009
Junior Member
Hello Kenn,

Currently I'am successfully using OCL to create body expressions. I saw in
the references you gave me how invariant constraints could be specified as
well.

But what I would like to have is to specify the body of derived properties.

For example, in the example of Car-Person, imagine I would like to have a
property in Car:

Car::/ownerAge (result = self.owner.age)

Thus, I would not need to insert code in Car.getOwnerAge(). In UML I do
not have the method getOwnerAge() only the derived property ownerAge.

I just tried to create in UML the method getOwnerAge() besides the
property ownerAge and it seems to work. Is this the way to do it? Is it
required to add the getter in UML?

Thank you.
Re: Derive constraints [message #592403 is a reply to message #378283] Wed, 09 April 2008 10:23 Go to previous message
Kenn Hussey is currently offline Kenn Hussey
Messages: 1618
Registered: July 2009
Senior Member
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

"Javi" <jfbriones@yahoo.com> wrote in message
news:2ac33d93a79c06410006f82f51a620c5$1@www.eclipse.org...
> Hello Kenn,
>
> Currently I'am successfully using OCL to create body expressions. I saw in
> the references you gave me how invariant constraints could be specified as
> well.
>
> But what I would like to have is to specify the body of derived
> properties.
>
> For example, in the example of Car-Person, imagine I would like to have a
> property in Car:
>
> Car::/ownerAge (result = self.owner.age)
>
> Thus, I would not need to insert code in Car.getOwnerAge(). In UML I do
> not have the method getOwnerAge() only the derived property ownerAge.
>
> I just tried to create in UML the method getOwnerAge() besides the
> property ownerAge and it seems to work. Is this the way to do it? Is it
> required to add the getter in UML?
>
> Thank you.
>
Re: Derive constraints [message #592416 is a reply to message #378284] Wed, 09 April 2008 11:03 Go to previous message
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 11:25 Go to previous message
Kenn Hussey is currently offline Kenn Hussey
Messages: 1618
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 12:26 Go to previous message
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 16:12 Go to previous message
Kenn Hussey is currently offline Kenn Hussey
Messages: 1618
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 16:41 Go to previous message
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<-----
Previous Topic:Derive constraints
Next Topic:[SBVR] Interest in UML/OCL to SBVR metamodel transformation
Goto Forum:
  


Current Time: Fri Apr 18 06:59:12 EDT 2014

Powered by FUDForum. Page generated in 0.09250 seconds