Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Specifying derived values in a UML model
Specifying derived values in a UML model [message #1033431] Thu, 04 April 2013 04:13 Go to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi,

[I didn't see an option to cross post on the papyrus forum, does it exist?]

I am trying to use MDT/OCL to specify derivation rules for UML properties in a specific UML model. What I've tried so far (all using Kepler nightly build of papyrus and MDT/OCL):

1/ Specifying the derivation rule directly in the UML model.
a/ By declaring the property to be read-only and derived, and setting the default value. I don't know whether this is semantically exactly the same as a derivation (bug [url=https://bugs.eclipse.org/bugs/show_bug.cgi?id=382784] has some information on that, which I didn't fully understand). This works fine, although
* [minor, side note] It is quite cumbersome to do so in Papyrus. You can quite easily create the property value using the embedded "advanced property editor", but the default value is always a literal string. That means that, in order to get an OCL expression there, you need to go to the properties view, delete the LiteralString, create an OpaqueExpression, set the language to OCL. Unfortunately, when typing the OCL expression in there, it seems to get lost, and you need to use the advanced property editor to get the expression finally in there.
* More interesting: when taking the (plain) UML model and transforming this via the UML2 model editor to ecore, this "default value expression" gets translated into something like this

attribute attribute2 : types::Boolean = 'self.myprop = 2' { derived readonly transient volatile };


Meaning that the opaque expression is translated into a default value literal in the ecore model, and the link with OCL got completely lost during translation. If setting the default value in UML to an OCL expression would be semantically equivalent to an OCL derivation, then I would guess this is a missing feature of the uml2ecore transformation, right?

b/ By adding an OCL constraint to the UML model via a UML constraint and opaque expression. In this case, this gets translated into (as expected) something like

attribute attribute3 : types::Integer { derived readonly transient volatile };
callable invariant constraint1: self.attribute3 = self.myprop + self.attribute1;


So again, no derivation although one could again argue this is a semantically equivalent way of representing things. The problem I see with this approach is that this works fine to express bijective (?) relationships like the sum, but it wouldn't work for an if/then/else derivation IMO?

2/ Specifying the derivation rule in a CompleteOCL document. Another approach which I tried was to specify the derivation rule in a separate completeOCL document. For this purpose, I tried to start from the completeocltutorial example project and wrote a completeOCL document that looks like
import myumlmodel : 'PapyrusTestFile.uml#/'
 
context myumlmodel::UPPERCASE::myprop : Integer
derive: 0

context myumlmodel::UPPERCASE
inv : myprop = 1


I get the exception which is attached to this post (both when loading the completeOCL resource in the graphical papyrus editor and the UML2 editor).

So finally I didn't find a satisfying solution to specify the derived values yet Sad Did I forget other possibilities to specify derived values? If not, what would be the best way to move on with this?

TIA,

Klaas
Re: Specifying derived values in a UML model [message #1033471 is a reply to message #1033431] Thu, 04 April 2013 04:55 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

The current (Kepler M6) Papyrus-OCL integration is much better than in
Juno since most facilities are there and work, but as you observe you
need to be quite expert to find the correct little pigeon hole to
configure. There are a number of open bugs suggesting improvements in
the Papyrus user interface.

The stupid bug (which should have been fixed in Helios) preventing OCL
in UML being useable as OCL in Ecore has been fixed for invariants and
operation bodies. I've raised
https://bugs.eclipse.org/bugs/show_bug.cgi?id=404876 against MDT/OCL for
now to ensure that we get the right solution for properties too.

Please raise a Bugzilla for the exception trace.

Regards

Ed Willink

On 04/04/2013 09:13, Klaas Gadeyne wrote:
> Hi,
>
> [I didn't see an option to cross post on the papyrus forum, does it exist?]
>
> I am trying to use MDT/OCL to specify derivation rules for UML properties in a specific UML model. What I've tried so far (all using Kepler nightly build of papyrus and MDT/OCL):
>
> 1/ Specifying the derivation rule directly in the UML model.
> a/ By declaring the property to be read-only and derived, and setting the default value. I don't know whether this is semantically exactly the same as a derivation (bug [url=https://bugs.eclipse.org/bugs/show_bug.cgi?id=382784] has some information on that, which I didn't fully understand). This works fine, although
> * [minor, side note] It is quite cumbersome to do so in Papyrus. You can quite easily create the property value using the embedded "advanced property editor", but the default value is always a literal string. That means that, in order to get an OCL expression there, you need to go to the properties view, delete the LiteralString, create an OpaqueExpression, set the language to OCL. Unfortunately, when typing the OCL expression in there, it seems to get lost, and you need to use the advanced property editor to get the expression finally in there.
> * More interesting: when taking the (plain) UML model and transforming this via the UML2 model editor to ecore, this "default value expression" gets translated into something like this
>
>
> attribute attribute2 : types::Boolean = 'self.myprop = 2' { derived readonly transient volatile };
>
>
> Meaning that the opaque expression is translated into a default value literal in the ecore model, and the link with OCL got completely lost during translation. If setting the default value in UML to an OCL expression would be semantically equivalent to an OCL derivation, then I would guess this is a missing feature of the uml2ecore transformation, right?
>
> b/ By adding an OCL constraint to the UML model via a UML constraint and opaque expression. In this case, this gets translated into (as expected) something like
>
>
> attribute attribute3 : types::Integer { derived readonly transient volatile };
> callable invariant constraint1: self.attribute3 = self.myprop + self.attribute1;
>
>
> So again, no derivation although one could again argue this is a semantically equivalent way of representing things. The problem I see with this approach is that this works fine to express bijective (?) relationships like the sum, but it wouldn't work for an if/then/else derivation IMO?
>
> 2/ Specifying the derivation rule in a CompleteOCL document. Another approach which I tried was to specify the derivation rule in a separate completeOCL document. For this purpose, I tried to start from the completeocltutorial example project and wrote a completeOCL document that looks like
>
> import myumlmodel : 'PapyrusTestFile.uml#/'
>
> context myumlmodel::UPPERCASE::myprop : Integer
> derive: 0
>
> context myumlmodel::UPPERCASE
> inv : myprop = 1
>
>
> I get the exception which is attached to this post (both when loading the completeOCL resource in the graphical papyrus editor and the UML2 editor).
>
> So finally I didn't find a satisfying solution to specify the derived values yet :( Did I forget other possibilities to specify derived values? If not, what would be the best way to move on with this?
>
> TIA,
>
> Klaas
>
Re: Specifying derived values in a UML model [message #1033495 is a reply to message #1033471] Thu, 04 April 2013 05:31 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Ed Willink wrote on Thu, 04 April 2013 04:55
Hi

The current (Kepler M6) Papyrus-OCL integration is much better than in
Juno since most facilities are there and work, but as you observe you
need to be quite expert to find the correct little pigeon hole to
configure. There are a number of open bugs suggesting improvements in
the Papyrus user interface.

The stupid bug (which should have been fixed in Helios) preventing OCL
in UML being useable as OCL in Ecore has been fixed for invariants and
operation bodies. I've raised
https://bugs.eclipse.org/bugs/show_bug.cgi?id=404876 against MDT/OCL for
now to ensure that we get the right solution for properties too.


Thx.

Quote:

Please raise a Bugzilla for the exception trace.


https://bugs.eclipse.org/bugs/show_bug.cgi?id=404882 raised.

Thx,

Klaas
Re: Specifying derived values in a UML model [message #1035008 is a reply to message #1033431] Sat, 06 April 2013 03:00 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

[Apologies for the cross-post, but this is perhaps interesting to UML
and Papyrus users. Please reply only to the OCL newsgroup.]

I've just been checking out the use of OCL for Properties.

IMHO A derived property constraint is not semantically distinct from a
class invariant that constrains the member property, so derived
constraints are easily specified as class invariants; just make sure the
Constraint context is the class. (The constrainedElement collection is
potentially redundant and is ignored by MDT/OCL but might be used by
other tools since the specification is very vague here.)

An OCL initial value can be specified in the UML Model Editor by
creation an OCL-languaged OpaqueExpression as the Property's default value.

I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065 to
remedy the loss of this expression during the UML to Ecore conversion.

I've added a note to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249 about the missing
Papyrus support for adding an OpaqueExpression as a Property's default
value.

Currently in MDT/OCL there is complexity as to which of "derivation" or
"initial" settingDelegates should be used when both are present; the
"derivation" is given preference. "derivation" was a mistake and should
not exist, but I suppose for compatibility both will be tolerated
indefinitely.

Regards

Ed Willink



On 04/04/2013 09:13, Klaas Gadeyne wrote:
> Hi,
>
> [I didn't see an option to cross post on the papyrus forum, does it exist?]
>
> I am trying to use MDT/OCL to specify derivation rules for UML properties in a specific UML model. What I've tried so far (all using Kepler nightly build of papyrus and MDT/OCL):
>
> 1/ Specifying the derivation rule directly in the UML model.
> a/ By declaring the property to be read-only and derived, and setting the default value. I don't know whether this is semantically exactly the same as a derivation (bug [url=https://bugs.eclipse.org/bugs/show_bug.cgi?id=382784] has some information on that, which I didn't fully understand). This works fine, although
> * [minor, side note] It is quite cumbersome to do so in Papyrus. You can quite easily create the property value using the embedded "advanced property editor", but the default value is always a literal string. That means that, in order to get an OCL expression there, you need to go to the properties view, delete the LiteralString, create an OpaqueExpression, set the language to OCL. Unfortunately, when typing the OCL expression in there, it seems to get lost, and you need to use the advanced property editor to get the expression finally in there.
> * More interesting: when taking the (plain) UML model and transforming this via the UML2 model editor to ecore, this "default value expression" gets translated into something like this
>
>
> attribute attribute2 : types::Boolean = 'self.myprop = 2' { derived readonly transient volatile };
>
>
> Meaning that the opaque expression is translated into a default value literal in the ecore model, and the link with OCL got completely lost during translation. If setting the default value in UML to an OCL expression would be semantically equivalent to an OCL derivation, then I would guess this is a missing feature of the uml2ecore transformation, right?
>
> b/ By adding an OCL constraint to the UML model via a UML constraint and opaque expression. In this case, this gets translated into (as expected) something like
>
>
> attribute attribute3 : types::Integer { derived readonly transient volatile };
> callable invariant constraint1: self.attribute3 = self.myprop + self.attribute1;
>
>
> So again, no derivation although one could again argue this is a semantically equivalent way of representing things. The problem I see with this approach is that this works fine to express bijective (?) relationships like the sum, but it wouldn't work for an if/then/else derivation IMO?
>
> 2/ Specifying the derivation rule in a CompleteOCL document. Another approach which I tried was to specify the derivation rule in a separate completeOCL document. For this purpose, I tried to start from the completeocltutorial example project and wrote a completeOCL document that looks like
>
> import myumlmodel : 'PapyrusTestFile.uml#/'
>
> context myumlmodel::UPPERCASE::myprop : Integer
> derive: 0
>
> context myumlmodel::UPPERCASE
> inv : myprop = 1
>
>
> I get the exception which is attached to this post (both when loading the completeOCL resource in the graphical papyrus editor and the UML2 editor).
>
> So finally I didn't find a satisfying solution to specify the derived values yet :( Did I forget other possibilities to specify derived values? If not, what would be the best way to move on with this?
>
> TIA,
>
> Klaas
>
Re: Specifying derived values in a UML model [message #1035370 is a reply to message #1035008] Sat, 06 April 2013 15:41 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi Ed,

Ed Willink wrote on Sat, 06 April 2013 03:00
Hi

I've just been checking out the use of OCL for Properties.

IMHO A derived property constraint is not semantically distinct from a
class invariant that constrains the member property, so derived
constraints are easily specified as class invariants; just make sure the
Constraint context is the class. (The constrainedElement collection is
potentially redundant and is ignored by MDT/OCL but might be used by
other tools since the specification is very vague here.)


See my original post and the remark regarding the bijectivity below. Now, it's a very long time ago since I followed a mathematics course, so I don't know whether bijectivity is the correct term, but I will illustrate it with an example. Suppose I have the following in oclinecore

class myclass {
attribute myint : Integer = 5;
attribute mybool : Boolean { derived transient volatile }
			{
				derivation: if myint = 5 then true else false endif;
			}


Transforming this into a constraint becomes a little ugly IMO, the only thing I can think of is
invariant myderivation: myint = 5 implies mybool = true and myint <> 5 implies mybool = false


For more complex constructs I suppose this would get even uglier? So I'm a little reluctant in saying these derivation are _easily_ specified as invariant constraints, unless I'm missing something. The derivation rule also makes it a little more explicit that the derived property is really derived IMO.

Quote:

An OCL initial value can be specified in the UML Model Editor by
creation an OCL-languaged OpaqueExpression as the Property's default value.

I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065 to
remedy the loss of this expression during the UML to Ecore conversion.

I've added a note to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249 about the missing
Papyrus support for adding an OpaqueExpression as a Property's default
value.


Thx!

Quote:

Currently in MDT/OCL there is complexity as to which of "derivation" or
"initial" settingDelegates should be used when both are present; the
"derivation" is given preference. "derivation" was a mistake and should
not exist, but I suppose for compatibility both will be tolerated
indefinitely.


Regards,

Klaas

On 04/04/2013 09:13, Klaas Gadeyne wrote:
> Hi,
>
> [I didn't see an option to cross post on the papyrus forum, does it exist?]
>
> I am trying to use MDT/OCL to specify derivation rules for UML properties in a specific UML model. What I've tried so far (all using Kepler nightly build of papyrus and MDT/OCL):
>
> 1/ Specifying the derivation rule directly in the UML model.
> a/ By declaring the property to be read-only and derived, and setting the default value. I don't know whether this is semantically exactly the same as a derivation (bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=382784] has some information on that, which I didn't fully understand). This works fine, although
> * [minor, side note] It is quite cumbersome to do so in Papyrus. You can quite easily create the property value using the embedded "advanced property editor", but the default value is always a literal string. That means that, in order to get an OCL expression there, you need to go to the properties view, delete the LiteralString, create an OpaqueExpression, set the language to OCL. Unfortunately, when typing the OCL expression in there, it seems to get lost, and you need to use the advanced property editor to get the expression finally in there.
> * More interesting: when taking the (plain) UML model and transforming this via the UML2 model editor to ecore, this "default value expression" gets translated into something like this
>
>
> attribute attribute2 : types::Boolean = 'self.myprop = 2' { derived readonly transient volatile };
>
>
> Meaning that the opaque expression is translated into a default value literal in the ecore model, and the link with OCL got completely lost during translation. If setting the default value in UML to an OCL expression would be semantically equivalent to an OCL derivation, then I would guess this is a missing feature of the uml2ecore transformation, right?
>
> b/ By adding an OCL constraint to the UML model via a UML constraint and opaque expression. In this case, this gets translated into (as expected) something like
>
>
> attribute attribute3 : types::Integer { derived readonly transient volatile };
> callable invariant constraint1: self.attribute3 = self.myprop + self.attribute1;
>
>
> So again, no derivation although one could again argue this is a semantically equivalent way of representing things. The problem I see with this approach is that this works fine to express bijective (?) relationships like the sum, but it wouldn't work for an if/then/else derivation IMO?
>
> 2/ Specifying the derivation rule in a CompleteOCL document. Another approach which I tried was to specify the derivation rule in a separate completeOCL document. For this purpose, I tried to start from the completeocltutorial example project and wrote a completeOCL document that looks like
>
> import myumlmodel : 'PapyrusTestFile.uml#/'
>
> context myumlmodel::UPPERCASE::myprop : Integer
> derive: 0
>
> context myumlmodel::UPPERCASE
> inv : myprop = 1
>
>
> I get the exception which is attached to this post (both when loading the completeOCL resource in the graphical papyrus editor and the UML2 editor).
>
> So finally I didn't find a satisfying solution to specify the derived values yet Sad Did I forget other possibilities to specify derived values? If not, what would be the best way to move on with this?
>
> TIA,
>
> Klaas
>[/quote]
Re: Specifying derived values in a UML model [message #1035431 is a reply to message #1035370] Sat, 06 April 2013 18:09 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

For MyClass.myProperty

derivation: x;

just becomes:

invariant: myProperty = x;

Seems easy enough to me. Remember = is compare.

Regards

Ed Willink

On 06/04/2013 20:41, Klaas Gadeyne wrote:
> Hi Ed,
>
> Ed Willink wrote on Sat, 06 April 2013 03:00
>> Hi
>>
>> I've just been checking out the use of OCL for Properties.
>>
>> IMHO A derived property constraint is not semantically distinct from
>> a class invariant that constrains the member property, so derived
>> constraints are easily specified as class invariants; just make sure
>> the Constraint context is the class. (The constrainedElement
>> collection is potentially redundant and is ignored by MDT/OCL but
>> might be used by other tools since the specification is very vague
>> here.)
>
>
> See my original post and the remark regarding the bijectivity below.
> Now, it's a very long time ago since I followed a mathematics course,
> so I don't know whether bijectivity is the correct term, but I will
> illustrate it with an example. Suppose I have the following in
> oclinecore
>
>
> class myclass {
> attribute myint : Integer = 5;
> attribute mybool : Boolean { derived transient volatile }
> {
> derivation: if myint = 5 then true else false endif;
> }
>
>
> Transforming this into a constraint becomes a little ugly IMO, the
> only thing I can think of is
>
> invariant myderivation: myint = 5 implies mybool = true and myint <> 5
> implies mybool = false
>
>
> For more complex constructs I suppose this would get even uglier? So
> I'm a little reluctant in saying these derivation are _easily_
> specified as invariant constraints, unless I'm missing something. The
> derivation rule also makes it a little more explicit that the derived
> property is really derived IMO.
>
> Quote:
>> An OCL initial value can be specified in the UML Model Editor by
>> creation an OCL-languaged OpaqueExpression as the Property's default
>> value.
>>
>> I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065 to
>> remedy the loss of this expression during the UML to Ecore conversion.
>>
>> I've added a note to
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249 about the
>> missing Papyrus support for adding an OpaqueExpression as a
>> Property's default value.
>
>
> Thx!
>
> Quote:
>> Currently in MDT/OCL there is complexity as to which of "derivation"
>> or "initial" settingDelegates should be used when both are present;
>> the "derivation" is given preference. "derivation" was a mistake and
>> should not exist, but I suppose for compatibility both will be
>> tolerated indefinitely.
>
>
> Regards,
>
> Klaas
>
> On 04/04/2013 09:13, Klaas Gadeyne wrote:
>> Hi,
>>
>> [I didn't see an option to cross post on the papyrus forum, does it
>> exist?]
>>
>> I am trying to use MDT/OCL to specify derivation rules for UML
>> properties in a specific UML model. What I've tried so far (all
>> using Kepler nightly build of papyrus and MDT/OCL):
>>
>> 1/ Specifying the derivation rule directly in the UML model.
>> a/ By declaring the property to be read-only and derived, and
>> setting the default value. I don't know whether this is semantically
>> exactly the same as a derivation (bug [url] has some information on
>> that, which I didn't fully understand). This works fine, although
>> * [minor, side note] It is quite cumbersome to do so in
>> Papyrus. You can quite easily create the property value using the
>> embedded "advanced property editor", but the default value is always
>> a literal string. That means that, in order to get an OCL expression
>> there, you need to go to the properties view, delete the
>> LiteralString, create an OpaqueExpression, set the language to OCL.
>> Unfortunately, when typing the OCL expression in there, it seems to
>> get lost, and you need to use the advanced property editor to get the
>> expression finally in there.
>> * More interesting: when taking the (plain) UML model and
>> transforming this via the UML2 model editor to ecore, this "default
>> value expression" gets translated into something like this
>>
>>
>> attribute attribute2 : types::Boolean = 'self.myprop = 2' { derived
>> readonly transient volatile };
>>
>>
>> Meaning that the opaque expression is translated into a
>> default value literal in the ecore model, and the link with OCL got
>> completely lost during translation. If setting the default value in
>> UML to an OCL expression would be semantically equivalent to an OCL
>> derivation, then I would guess this is a missing feature of the
>> uml2ecore transformation, right?
>>
>> b/ By adding an OCL constraint to the UML model via a UML
>> constraint and opaque expression. In this case, this gets translated
>> into (as expected) something like
>>
>>
>> attribute attribute3 : types::Integer { derived readonly transient
>> volatile };
>> callable invariant constraint1: self.attribute3 = self.myprop +
>> self.attribute1;
>>
>>
>> So again, no derivation although one could again argue this
>> is a semantically equivalent way of representing things. The problem
>> I see with this approach is that this works fine to express bijective
>> (?) relationships like the sum, but it wouldn't work for an
>> if/then/else derivation IMO?
>>
>> 2/ Specifying the derivation rule in a CompleteOCL document. Another
>> approach which I tried was to specify the derivation rule in a
>> separate completeOCL document. For this purpose, I tried to start
>> from the completeocltutorial example project and wrote a completeOCL
>> document that looks like
>>
>> import myumlmodel : 'PapyrusTestFile.uml#/'
>>
>> context myumlmodel::UPPERCASE::myprop : Integer
>> derive: 0
>>
>> context myumlmodel::UPPERCASE
>> inv : myprop = 1
>>
>>
>> I get the exception which is attached to this post (both when loading
>> the completeOCL resource in the graphical papyrus editor and the UML2
>> editor).
>>
>> So finally I didn't find a satisfying solution to specify the derived
>> values yet :( Did I forget other possibilities to specify derived
>> values? If not, what would be the best way to move on with this?
>>
>> TIA,
>>
>> Klaas
>> [/quote]
Re: Specifying derived values in a UML model [message #1037427 is a reply to message #1035431] Tue, 09 April 2013 10:46 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Ed Willink wrote on Sat, 06 April 2013 18:09
Hi

For MyClass.myProperty

derivation: x;

just becomes:

invariant: myProperty = x;

Seems easy enough to me. Remember = is compare.


True Embarrassed

Thx!
Re: Specifying derived values in a UML model [message #1037483 is a reply to message #1035008] Tue, 09 April 2013 12:01 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi Ed,

Ed Willink wrote on Sat, 06 April 2013 03:00
Hi

I've just been checking out the use of OCL for Properties.

IMHO A derived property constraint is not semantically distinct from a
class invariant that constrains the member property, so derived
constraints are easily specified as class invariants; just make sure the
Constraint context is the class. (The constrainedElement collection is
potentially redundant and is ignored by MDT/OCL but might be used by
other tools since the specification is very vague here.)

An OCL initial value can be specified in the UML Model Editor by
creation an OCL-languaged OpaqueExpression as the Property's default value.

I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065 to
remedy the loss of this expression during the UML to Ecore conversion.

I've added a note to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249 about the missing
Papyrus support for adding an OpaqueExpression as a Property's default
value.

Currently in MDT/OCL there is complexity as to which of "derivation" or
"initial" settingDelegates should be used when both are present; the
"derivation" is given preference. "derivation" was a mistake and should
not exist, but I suppose for compatibility both will be tolerated
indefinitely.



(please forgive stupid newbie thinking below, I didn't really know anything about the EMF delegation mechanism until 5 minutes ago)

I was just reading [https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065]. While I agree with your above reasoning on a conceptual level, it seems that you will end up with some problems on a 'tooling' level. Consider the following oclInEcore code

package derivedProperty : NsDerivedProperties = 'http://www.fmtc.be/derivedProperties.ecore'
{
	class derivedTest
	{
		attribute myProp : Integer = '5';
		attribute derivedProp : Integer { derived readonly volatile }
		{
			derivation: myProp;
		}
		attribute invariantDerivedProp : Integer { derived readonly volatile };
		invariant derivationInvariantDerivedProp: invariantDerivedProp = myProp;
	}
}


If you create a dynamic instance of this model, you're in trouble: invariantDerivedProp is (logically) declared readOnly, so you cannot set it, however, you need to set it in order to end up with a valid model. So unless MDT/OCL would persist the last invariant by means of a setting delegate instead of a validation delegate in the EMF world, I guess declaring the derivation rule as an invariant doesn't make sense?

So maybe the semantics of the UML model would be the same if using an invariant constraint for the derivation, but toolwise it doesn't work (I think).

Regards,

Klaas
Re: Specifying derived values in a UML model [message #1037607 is a reply to message #1037483] Tue, 09 April 2013 15:41 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

A derived (constraint) is just that a constraint that can be checked.

An initial value is something that can be computed during initialization.

In UML you have an OCL-languaged OpaqueExpression as the default value.
In Ecore you have an 'initial' settingDelegate

The confusion is that Ecore also has a 'derivation' settingDelegate.

UML does not support Property overloading so a derived initializer is
meaningless. You can only have a derived constraint that ensures that
the initial and any mutated values are ok for the requirements of the
derived class.

Regards

Ed Willink

On 09/04/2013 17:01, Klaas Gadeyne wrote:
> Hi Ed,
>
> Ed Willink wrote on Sat, 06 April 2013 03:00
>> Hi
>>
>> I've just been checking out the use of OCL for Properties.
>>
>> IMHO A derived property constraint is not semantically distinct from
>> a class invariant that constrains the member property, so derived
>> constraints are easily specified as class invariants; just make sure
>> the Constraint context is the class. (The constrainedElement
>> collection is potentially redundant and is ignored by MDT/OCL but
>> might be used by other tools since the specification is very vague
>> here.)
>>
>> An OCL initial value can be specified in the UML Model Editor by
>> creation an OCL-languaged OpaqueExpression as the Property's default
>> value.
>>
>> I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065 to
>> remedy the loss of this expression during the UML to Ecore conversion.
>>
>> I've added a note to
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249 about the
>> missing Papyrus support for adding an OpaqueExpression as a
>> Property's default value.
>>
>> Currently in MDT/OCL there is complexity as to which of "derivation"
>> or "initial" settingDelegates should be used when both are present;
>> the "derivation" is given preference. "derivation" was a mistake and
>> should not exist, but I suppose for compatibility both will be
>> tolerated indefinitely.
>
>
>
> (please forgive stupid newbie thinking below, I didn't really know
> anything about the EMF delegation mechanism until 5 minutes ago)
>
> I was just reading
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065]. While I agree
> with your above reasoning on a conceptual level, it seems that you
> will end up with some problems on a 'tooling' level. Consider the
> following oclInEcore code
>
>
> package derivedProperty : NsDerivedProperties =
> 'http://www.fmtc.be/derivedProperties.ecore'
> {
> class derivedTest
> {
> attribute myProp : Integer = '5';
> attribute derivedProp : Integer { derived readonly volatile }
> {
> derivation: myProp;
> }
> attribute invariantDerivedProp : Integer { derived readonly
> volatile };
> invariant derivationInvariantDerivedProp: invariantDerivedProp
> = myProp;
> }
> }
>
>
> If you create a dynamic instance of this model, you're in trouble:
> invariantDerivedProp is (logically) declared readOnly, so you cannot
> set it, however, you need to set it in order to end up with a valid
> model. So unless MDT/OCL would persist the last invariant by means of
> a setting delegate instead of a validation delegate in the EMF world,
> I guess declaring the derivation rule as an invariant doesn't make sense?
>
> So maybe the semantics of the UML model would be the same if using an
> invariant constraint for the derivation, but toolwise it doesn't work
> (I think).
>
> Regards,
>
> Klaas
>
Re: Specifying derived values in a UML model [message #1038020 is a reply to message #1037607] Wed, 10 April 2013 05:48 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi Ed,

Ed Willink wrote on Tue, 09 April 2013 15:41

A derived (constraint) is just that a constraint that can be checked.

An initial value is something that can be computed during initialization.


That's one way of looking at it. IMO another way of looking at is that both an initial value and a derivation rule are causal (ie. it's obvious which side of the equality sign is calculated from the other side) and hence are computed instead of checked, and that an (invariant) constraint is something that can (or needs to) be checked.

Quote:

In UML you have an OCL-languaged OpaqueExpression as the default value.
In Ecore you have an 'initial' settingDelegate

The confusion is that Ecore also has a 'derivation' settingDelegate.


As far as I understood the remarks of Kenn H in https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065, it's rather the "opposite", in the sense that the 'derivation' settingDelegate is the intended usage of the EMF settingDelegate? This is also conform to the current implementation, in which 'derived properties' are recalculated anytime a dependent property is changed. Moreover, this seems to be conform that derived properties need to be 'computed' instead of being 'checked'?

Quote:

UML does not support Property overloading so a derived initializer is
meaningless. You can only have a derived constraint that ensures that
the initial and any mutated values are ok for the requirements of the
derived class.


I don't understand what you mean with the above though. Given (the little) what I know from the UML specification and ecore/EMF I would say that the (ugly) table below summarizes my point of view:

Concept | UML | eCore/EMF
Invariant constraint || UML constraint with OCL opaque expression (OCL invariant keyword) || constraint annotation + ValidationDelegate
Initial value || Default value (could but needn't be an OCL opaque expression) || Nothing yet, see above bug [x]
Derivation rule || UML constraint with OCL opaque expression (OCL derive keyword) [1] || derivation annotation + SettingDelegate [2]

In my opinion what is currently lacking in MDT/OCL, UML2 and papyrus is
* a way to specify [1] on the UML/papyrus side of things, where currently it is supposed that each constraint is an invariant constraint. The possibility of distinguishing between an OCL invariant constraint and an OCL derivation should be added.
* a way to transform [1] into [2]

Would you agree with this view? (actually I don't think so Smile

Klaas

[x] represents a lacking feature in EMF (arguably), but I see that as outside of the scope of this topic Smile
Re: Specifying derived values in a UML model [message #1038102 is a reply to message #1038020] Wed, 10 April 2013 08:06 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Klaas Gadeyne wrote on Wed, 10 April 2013 05:48

I don't understand what you mean with the above though. Given (the little) what I know from the UML specification and ecore/EMF I would say that the (ugly) table below summarizes my point of view:

Concept | UML | eCore/EMF
Invariant constraint || UML constraint with OCL opaque expression (OCL invariant keyword) || constraint annotation + ValidationDelegate
Initial value || Default value (could but needn't be an OCL opaque expression) || Nothing yet, see above bug [x]
Derivation rule || UML constraint with OCL opaque expression (OCL derive keyword) [1] || derivation annotation + SettingDelegate [2]

In my opinion what is currently lacking in MDT/OCL, UML2 and papyrus is
* a way to specify [1] on the UML/papyrus side of things, where currently it is supposed that each constraint is an invariant constraint. The possibility of distinguishing between an OCL invariant constraint and an OCL derivation should be added.
* a way to transform [1] into [2]

Would you agree with this view? (actually I don't think so Smile



Maybe I've should have added what my understanding of your view is

Concept | UML | eCore/EMF
Invariant constraint || UML constraint with OCL opaque expression (OCL invariant keyword) || constraint annotation + ValidationDelegate
Initial value || Default value (could but needn't be an OCL opaque expression) || Nothing yet, see above bug [x]
Derivation rule || UML constraint with OCL opaque expression (OCL invariant keyword) [1] || derivation annotation + SettingDelegate [2]

In this case:
* You specify the UML constraint for the derivation rule in the context of the class instead of on the property
* You don't use the "derivation" part of OCL in the UML tooling (and hence you get a somewhat a-symmetry between UML and eCore+OCL tooling in which the derivation is available)
* You don't need to do anything to get this working with the current tools
* In order to transform a UML model [1] into an eCore model with correct annotations [2] you need to do more interpretation/work than in the first version (i.e. you need to couple the "derived" information on the properties with the invariant constraints on the class level. [*]

Is this correct?

Klaas

[*] Another way would off course be to alter the annotation types in EMF Smile

Re: Specifying derived values in a UML model [message #1038404 is a reply to message #1038020] Wed, 10 April 2013 16:40 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

I think you are confusing derived in the sense of a consequence of some
algorithm, and derived in the sense of inherited from a supertype.

I cannot comment on your view because it is not readable to me. If you
have a complex presentation try attaching a word/PDF dpcument so that it
is readable.

Regards

Ed Willink


On 10/04/2013 10:48, Klaas Gadeyne wrote:
> Hi Ed,
>
> Ed Willink wrote on Tue, 09 April 2013 15:41
>> A derived (constraint) is just that a constraint that can be checked.
>>
>> An initial value is something that can be computed during
>> initialization.
>
>
> That's one way of looking at it. IMO another way of looking at is
> that both an initial value and a derivation rule are causal (ie. it's
> obvious which side of the equality sign is calculated from the other
> side) and hence are computed instead of checked, and that an
> (invariant) constraint is something that can (or needs to) be checked.
>
> Quote:
>> In UML you have an OCL-languaged OpaqueExpression as the default value.
>> In Ecore you have an 'initial' settingDelegate
>>
>> The confusion is that Ecore also has a 'derivation' settingDelegate.
>
>
> As far as I understood the remarks of Kenn H in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065, it's rather the
> "opposite", in the sense that the 'derivation' settingDelegate is the
> intended usage of the EMF settingDelegate? This is also conform to
> the current implementation, in which 'derived properties' are
> recalculated anytime a dependent property is changed. Moreover, this
> seems to be conform that derived properties need to be 'computed'
> instead of being 'checked'?
>
> Quote:
>> UML does not support Property overloading so a derived initializer is
>> meaningless. You can only have a derived constraint that ensures that
>> the initial and any mutated values are ok for the requirements of the
>> derived class.
>
>
> I don't understand what you mean with the above though. Given (the
> little) what I know from the UML specification and ecore/EMF I would
> say that the (ugly) table below summarizes my point of view:
>
> Concept | UML | eCore/EMF
> Invariant constraint || UML constraint with OCL opaque expression
> (OCL invariant keyword) || constraint annotation + ValidationDelegate
> Initial value || Default value (could but needn't be an
> OCL opaque expression) || Nothing yet, see above bug [x]
> Derivation rule || UML constraint with OCL opaque expression
> (OCL derive keyword) [1] || derivation annotation + SettingDelegate
> [2]
>
> In my opinion what is currently lacking in MDT/OCL, UML2 and papyrus is
> * a way to specify [1] on the UML/papyrus side of things, where
> currently it is supposed that each constraint is an invariant
> constraint. The possibility of distinguishing between an OCL
> invariant constraint and an OCL derivation should be added.
> * a way to transform [1] into [2]
>
> Would you agree with this view? (actually I don't think so :)
>
> Klaas
>
> [x] represents a lacking feature in EMF (arguably), but I see that as
> outside of the scope of this topic :)
Re: Specifying derived values in a UML model [message #1038718 is a reply to message #1038404] Thu, 11 April 2013 04:11 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Ed Willink wrote on Wed, 10 April 2013 16:40
Hi

I think you are confusing derived in the sense of a consequence of some
algorithm, and derived in the sense of inherited from a supertype.


For me, it is the first one (or as the UML spec states it:
If a Property has isDerived = true, it is derived and its value or values may be computed from other information


Quote:

I cannot comment on your view because it is not readable to me. If you
have a complex presentation try attaching a word/PDF dpcument so that it
is readable.


I couldn't find how to put a table on the forum Sad
Does the attachment make it more clear?

Klaas
Re: Specifying derived values in a UML model [message #1038812 is a reply to message #1038718] Thu, 11 April 2013 07:10 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

The PDF makes it much clearer.

I have been referring to derived constraints and pointing out that they
are almost indistinguishable from class invariants referring to a property.

You are referring to derivation rules.

I take the view that that when a Property is being accessed
a) the available value make be directly available as a consequence of
some setter operation or a simple initialization.
b) there may be a specified algorithm to compute the required value,
and it makes no difference whether the intent is to initialize a
non-volatile location or to compute a volatile value or to refresh a
volatile cache.

Ignoring OCL's applicability only to unchanging models...

An initialized value that subsequently mutates can be defined as a
non-derived Property with an OCL initial value.
A derived value that evolves can be defined as a derived Property with
an OCL 'derived' value

For the later case the terminology 'derived' is redundant since why
would it be useful to have an 'initial' value for use on the first ever
access that is distinct from the 'derived' value for all subsequent
accesses. Why is the first access different?

So my view is there is just the value expression, with the
derived/non-derived feature determining how often it is evaluated.

---

The OCL specification is mess on this.

UML 2.5 leaves plenty of wiggle room:

"If a Property has isDerived = true, it is derived and its value or
values may be computed from other information."

So for the OCL specification to specify re-use of the initial value
expression would not violate this statement.

"The derivation for a derived Property may be specified by a constraint."

So the OCL specification might introduce the constraint (that I don't
know how to write since I'm not familiar enough with Slots).

isDerived implies value = initialValue

Regards

Ed Willink


Regards

Ed

On 11/04/2013 09:11, Klaas Gadeyne wrote:
> Ed Willink wrote on Wed, 10 April 2013 16:40
>> Hi
>>
>> I think you are confusing derived in the sense of a consequence of some
>> algorithm, and derived in the sense of inherited from a supertype.
>
> For me, it is the first one (or as the UML spec states it:
> If a Property has isDerived = true, it is derived and its value or values may be computed from other information
>
> Quote:
>> I cannot comment on your view because it is not readable to me. If you
>> have a complex presentation try attaching a word/PDF dpcument so that it
>> is readable.
>
> I couldn't find how to put a table on the forum :(
> Does the attachment make it more clear?
>
> Klaas
>
Re: Specifying derived values in a UML model [message #1044027 is a reply to message #1038812] Thu, 18 April 2013 08:04 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi Ed,

sorry for the delay.

Ed Willink wrote on Thu, 11 April 2013 07:10
Hi
The PDF makes it much clearer.

I have been referring to derived constraints and pointing out that they
are almost indistinguishable from class invariants referring to a property.
You are referring to derivation rules.


Glad we sorted that out Smile

Quote:

I take the view that that when a Property is being accessed
a) the available value make be directly available as a consequence of
some setter operation or a simple initialization.
b) there may be a specified algorithm to compute the required value,
and it makes no difference whether the intent is to initialize a
non-volatile location or to compute a volatile value or to refresh a
volatile cache.

Ignoring OCL's applicability only to unchanging models...

An initialized value that subsequently mutates can be defined as a
non-derived Property with an OCL initial value.
A derived value that evolves can be defined as a derived Property with
an OCL 'derived' value

For the later case the terminology 'derived' is redundant since why
would it be useful to have an 'initial' value for use on the first ever
access that is distinct from the 'derived' value for all subsequent
accesses. Why is the first access different?

So my view is there is just the value expression, with the
derived/non-derived feature determining how often it is evaluated.

---

The OCL specification is mess on this.

UML 2.5 leaves plenty of wiggle room:

"If a Property has isDerived = true, it is derived and its value or
values may be computed from other information."

So for the OCL specification to specify re-use of the initial value
expression would not violate this statement.

"The derivation for a derived Property may be specified by a constraint."

So the OCL specification might introduce the constraint (that I don't
know how to write since I'm not familiar enough with Slots).

isDerived implies value = initialValue


I can follow your reasoning here, and it makes sense to me!

There are 2 things left on my mind:
1/ Conceptually:

This is stated in the UML 2.5 spec.

If there is a defaultValue specified for a Property, this default is evaluated when an instance of the Property is created in the absence of a specific setting for the Property or a constraint in the model that requires the Property to have a specific value. The evaluated default then becomes the initial value (or values) of the Property.


Isn't this somewhat contradictory to your suggestion of using the default value for specifying the derivation? It's not fully contradictory, but it kind of says (I think): You can _only_ consider the default value expression if nothing else is specified. Otherwise, just ignore the 'default value' field.
Of course, this remains "interpretation". If they really mean this, it would have been so much stronger if they had added a well-formedness rule stating the above explicitly (for instance something like
context Property: invariant inv
self.isDerived = true implies self.defaultValue = null


2/ Tooling wise

I think I understand your viewpoint, but from a tooling perspective this would mean that the following things should/could be implemented
- Extending the embedded property editor to allow specifying OCL derivation rules. I guess this is what you stated in comment 8 of https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249#c8, but I think this would be worth a separate bug right?
- Modifying the UML2ecore transformation such that it generates a derivation annotation + SettingDelegate if and only if {{isDerived}} is set to true and the default value is OCL opaque expression. Looking at the bug reports title, I would guess this is bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=404876, but I don't understand really what you mean by the 3 options in Comment 4 of that bug. I would think that the only thing that needs to be modified is the UML2ecore transformation, to take into account the above rule of generating a derivation annotation + SettingDelegate if and only if {{isDerived}} is set to true and the default value is OCL opaque expression?

Re: Specifying derived values in a UML model [message #1044058 is a reply to message #1044027] Thu, 18 April 2013 08:54 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

For the most part the UML spec says, let there be constraints, and then
the individual classes the say, this problem is solved by a constraint.
It's a mess. Every kind of constraint: invariation, operation body,
precondition, property initializer, state triggerr, ... is actually
different.

There could be a UML appendix that summarises the details of constraints.

At the other end, for some constraints, you have the yet-to-aligned with
UML 2.0, OCL 2.x specification; the descriptions do not bear close scrutiny.

So it remains an open issue to find a way to specify constraints that
are practical are not conflicting with the UML specification. This
should eventually materialize in the OCL specification.

Expanding the role of default-value is my current thinking on how to
resolve Property derivation.

My three comments in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065 represent three
implementation alternatives; only one is needed. You might care to add a
comment as to which you think is a good idea and why.

In regard to https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249#c8 I'm
waiting for the Papyrus team to get time/enthusiasm to tackle the issue
of OCL constraint wizards/forms.

(I'm not clear whether you are 'on' the Papyrus team, or just a well
informed active user.)

Regards

Ed Willink






On 18/04/2013 13:04, Klaas Gadeyne wrote:
> Hi Ed,
> sorry for the delay.
>
> Ed Willink wrote on Thu, 11 April 2013 07:10
>> Hi
>> The PDF makes it much clearer.
>>
>> I have been referring to derived constraints and pointing out that
>> they are almost indistinguishable from class invariants referring to
>> a property.
>> You are referring to derivation rules.
>
>
> Glad we sorted that out :)
>
> Quote:
>> I take the view that that when a Property is being accessed
>> a) the available value make be directly available as a consequence of
>> some setter operation or a simple initialization.
>> b) there may be a specified algorithm to compute the required value,
>> and it makes no difference whether the intent is to initialize a
>> non-volatile location or to compute a volatile value or to refresh a
>> volatile cache.
>>
>> Ignoring OCL's applicability only to unchanging models...
>>
>> An initialized value that subsequently mutates can be defined as a
>> non-derived Property with an OCL initial value.
>> A derived value that evolves can be defined as a derived Property
>> with an OCL 'derived' value
>>
>> For the later case the terminology 'derived' is redundant since why
>> would it be useful to have an 'initial' value for use on the first
>> ever access that is distinct from the 'derived' value for all
>> subsequent accesses. Why is the first access different?
>>
>> So my view is there is just the value expression, with the
>> derived/non-derived feature determining how often it is evaluated.
>>
>> ---
>>
>> The OCL specification is mess on this.
>>
>> UML 2.5 leaves plenty of wiggle room:
>>
>> "If a Property has isDerived = true, it is derived and its value or
>> values may be computed from other information."
>>
>> So for the OCL specification to specify re-use of the initial value
>> expression would not violate this statement.
>>
>> "The derivation for a derived Property may be specified by a
>> constraint."
>>
>> So the OCL specification might introduce the constraint (that I don't
>> know how to write since I'm not familiar enough with Slots).
>>
>> isDerived implies value = initialValue
>
>
> I can follow your reasoning here, and it makes sense to me!
>
> There are 2 things left on my mind:
> 1/ Conceptually:
>
> This is stated in the UML 2.5 spec.
>
> If there is a defaultValue specified for a Property, this default is
> evaluated when an instance of the Property is created in the absence
> of a specific setting for the Property or a constraint in the model
> that requires the Property to have a specific value. The evaluated
> default then becomes the initial value (or values) of the Property.
>
> Isn't this somewhat contradictory to your suggestion of using the
> default value for specifying the derivation? It's not fully
> contradictory, but it kind of says (I think): You can _only_ consider
> the default value expression if nothing else is specified. Otherwise,
> just ignore the 'default value' field. Of course, this remains
> "interpretation". If they really mean this, it would have been so
> much stronger if they had added a well-formedness rule stating the
> above explicitly (for instance something like
>
> context Property: invariant inv
> self.isDerived = true implies self.defaultValue = null
>
>
> 2/ Tooling wise
>
> I think I understand your viewpoint, but from a tooling perspective
> this would mean that the following things should/could be implemented
> - Extending the embedded property editor to allow specifying OCL
> derivation rules. I guess this is what you stated in comment 8 of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249#c8, but I think
> this would be worth a separate bug right?
> - Modifying the UML2ecore transformation such that it generates a
> derivation annotation + SettingDelegate if and only if {{isDerived}}
> is set to true and the default value is OCL opaque expression.
> Looking at the bug reports title, I would guess this is bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=404876, but I don't
> understand really what you mean by the 3 options in Comment 4 of that
> bug. I would think that the only thing that needs to be modified is
> the UML2ecore transformation, to take into account the above rule of
> generating a derivation annotation + SettingDelegate if and only if
> {{isDerived}} is set to true and the default value is OCL opaque
> expression?
>
>
Re: Specifying derived values in a UML model [message #1044123 is a reply to message #1044058] Thu, 18 April 2013 10:19 Go to previous messageGo to next message
Klaas Gadeyne is currently offline Klaas Gadeyne
Messages: 86
Registered: July 2009
Member
Hi,

[I snipped your rant against UML and OCL spec Smile]

Ed Willink wrote on Thu, 18 April 2013 08:54


My three comments in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065 represent three
implementation alternatives; only one is needed. You might care to add a
comment as to which you think is a good idea and why.


I would like to, but I'm not sure I understand them (or rather: I'm sure I don't understand them Wink ).

In the attachment I updated "your view" with the things I understood (note that there is no such thing anymore as "your view" and "my view" and I'm only talking about your view). Now, given the assumption that we follow "your view" for me there are 2 problems:
1/ The representation of "initial values" in eCore, for which there is no mechanism currently (as is confirmed by https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065#c3 I guess)
2/ The translation of "derivation rules" (specified by using the {{isDerived}} property and the {{defaultValue}} field into eCore annotations + setting delegates

Now
a) It's not clear for me if the scope of bug #405065 encompasses only 2/ above (or also 1/) and what the relation with https://bugs.eclipse.org/bugs/show_bug.cgi?id=404876 is. I think it would be good to separate 1/ and 2/ clearly, because they are semantically different. My guess is that the 3 options try to solve both 1/ and 2/?

b) For solving 1/ I don't have a good solution (I think there should be modifications on the EMF front for that)
For solving 2/, I would think that adapting the uml2ecore transformation is the most elegant thing to do. I guess that would be (a modified version of?) option c), ie. the uml2ecore conversion does something like this in ugly pseudocode
if (isDerived = true) && ( defaultValue.OCLisTypeOf(OpaqueExpression) && defaultValue.language =  "OCL") then
transform the default value spec into the eCore annotation + setting delegate, and set isDerived = true on the ecore property
endif

In that case, I don't understand what you mean with "inelegant semantic tweak". If you would omit the {{(isDerived = true)}} condition from the above pseudocode, and always set the isDerived true, then it is indeed an inelegant semantic tweak IMO.

So I guess this is option d) Wink

Quote:

In regard to https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249#c8 I'm
waiting for the Papyrus team to get time/enthusiasm to tackle the issue
of OCL constraint wizards/forms.

(I'm not clear whether you are 'on' the Papyrus team, or just a well
informed active user.)


I would say 'none of the above' since "well informed" would be a major exageration, but I'm clearly closer to the latter since I'm not on the Papyrus team at all Smile
Re: Specifying derived values in a UML model [message #1044161 is a reply to message #1044123] Thu, 18 April 2013 11:03 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065#c5 for a reply.

Regards

Ed Willink


On 18/04/2013 15:19, Klaas Gadeyne wrote:
> Hi,
>
> [I snipped your rant against UML and OCL spec :)]
>
> Ed Willink wrote on Thu, 18 April 2013 08:54
>> My three comments in
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065 represent three
>> implementation alternatives; only one is needed. You might care to add a
>> comment as to which you think is a good idea and why.
>
> I would like to, but I'm not sure I understand them (or rather: I'm sure I don't understand them ;) ).
>
> In the attachment I updated "your view" with the things I understood (note that there is no such thing anymore as "your view" and "my view" and I'm only talking about your view). Now, given the assumption that we follow "your view" for me there are 2 problems:
> 1/ The representation of "initial values" in eCore, for which there is no mechanism currently (as is confirmed by https://bugs.eclipse.org/bugs/show_bug.cgi?id=405065#c3 I guess)
> 2/ The translation of "derivation rules" (specified by using the {{isDerived}} property and the {{defaultValue}} field into eCore annotations + setting delegates
>
> Now
> a) It's not clear for me if the scope of bug #405065 encompasses only 2/ above (or also 1/) and what the relation with https://bugs.eclipse.org/bugs/show_bug.cgi?id=404876 is. I think it would be good to separate 1/ and 2/ clearly, because they are semantically different. My guess is that the 3 options try to solve both 1/ and 2/?
>
> b) For solving 1/ I don't have a good solution (I think there should be modifications on the EMF front for that)
> For solving 2/, I would think that adapting the uml2ecore transformation is the most elegant thing to do. I guess that would be (a modified version of?) option c), ie. the uml2ecore conversion does something like this in ugly pseudocode
>
> if (isDerived = true)&& ( defaultValue.OCLisTypeOf(OpaqueExpression)&& defaultValue.language = "OCL") then
> transform the default value spec into the eCore annotation + setting delegate, and set isDerived = true on the ecore property
> endif
>
> In that case, I don't understand what you mean with "inelegant semantic tweak". If you would omit the {{(isDerived = true)}} condition from the above pseudocode, and always set the isDerived true, then it is indeed an inelegant semantic tweak IMO.
>
> So I guess this is option d) ;)
>
> Quote:
>> In regard to https://bugs.eclipse.org/bugs/show_bug.cgi?id=399249#c8 I'm
>> waiting for the Papyrus team to get time/enthusiasm to tackle the issue
>> of OCL constraint wizards/forms.
>>
>> (I'm not clear whether you are 'on' the Papyrus team, or just a well
>> informed active user.)
>
> I would say 'none of the above' since "well informed" would be a major exageration, but I'm clearly closer to the latter since I'm not on the Papyrus team at all :)
>
Previous Topic:Operation overriding : is this a bug in pivot delegates?
Next Topic:Error during "Computing additional info" while using ECore EOperations
Goto Forum:
  


Current Time: Fri Jul 25 21:21:49 EDT 2014

Powered by FUDForum. Page generated in 0.02391 seconds