Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Computing derived attribute values with dynamic EMF(How to set SettingDelegates?)
Computing derived attribute values with dynamic EMF [message #1727686] Fri, 25 March 2016 09:29 Go to next message
Yves BERNARD is currently offline Yves BERNARDFriend
Messages: 152
Registered: July 2014
Senior Member
I try to provide computation of derived attribute values for EMF models which are build dynamically. I think that the OCL plugin is able to do almost all for me assuming I use it properly.

The simplest approach seems to generate dynamically the EAnnotations that are used by the Ecore delegation mechanism.

According to this document: https://wiki.eclipse.org/OCL/OCLinEcore my understanding is that these annotations should be linked to the derived EStructuralFeature. So I tried something like this:
EcoreUtil.setAnnotation(structuralFeature, OCLConstants.OCL_DELEGATE_URI, "derivation","<...OCL code...>")


It still does not work because I guess I have to trigger the creation of the settingDelegates but I have not find how to do that so far.



Yves
Re: Computing derived attribute values with dynamic EMF [message #1727688 is a reply to message #1727686] Fri, 25 March 2016 09:55 Go to previous messageGo to next message
Yves BERNARD is currently offline Yves BERNARDFriend
Messages: 152
Registered: July 2014
Senior Member
Ok, I think that finally I found how to fix this in the "OCLinEcore" web page:

Quote:
The setting delegate is specified by an EPackage EAnnotation with:
Source = "http://www.eclipse.org/emf/2002/Ecore"
Key = "settingDelegates"
Value = "http://www.eclipse.org/emf/2002/Ecore/OCL"

The delegate value matches an org.eclipse.emf.ecore.setting_delegate extension point usage in the org.eclipse.ocl.ecore plug-in that provides the delegate functionality. Multiple comma-separated delegates may be specified


Yves

[Updated on: Fri, 25 March 2016 10:48]

Report message to a moderator

Re: Computing derived attribute values with dynamic EMF [message #1727703 is a reply to message #1727688] Fri, 25 March 2016 13:29 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

The Delegate EAnnotations are non-trivial to get right.

If you must generate them manually you might consider using some of the
Pivot OCL subroutines.

You might even consider constructing a pivot model - rationalized UML +
OCL hybrid and then save it as Ecore.

Regards

Ed Willink

On 25/03/2016 09:55, Yves BERNARD wrote:
> Ok, I think that finally I found how to fix this in the "OCLinEcore"
> web page:
>
> Quote:
>> The setting delegate is specified by an EPackage EAnnotation with:
>> Source = "http://www.eclipse.org/emf/2002/Ecore"
>> Key = "settingDelegates"
>> Value = "http://www.eclipse.org/emf/2002/Ecore/OCL"
>
Re: Computing derived attribute values with dynamic EMF [message #1728138 is a reply to message #1727703] Thu, 31 March 2016 10:20 Go to previous messageGo to next message
Yves BERNARD is currently offline Yves BERNARDFriend
Messages: 152
Registered: July 2014
Senior Member
Hi Ed,

I think I'm not far away from success but a tricky point remains. Maybe you have a solution for it.

Following the instructions given by the OCLinEcore documentation (see my previous message), I can provide a string specifying the OCL code of the derivation. For example assuming two Boolean attributes "isOk" and "isNotOk", I can specify "not isOk" as the derived value of the "isNotOk" attribute. This works fine and the value of "isNotOk" is properly computed according to the value of the "isOK" attribute.

The point is that the derivation constraints shall be specified in a UML model, through UML::Constraints owned by the classifier. They look something like:

context MyClassifier::isNotOk : Boolean
derive: not isOk


Note that there can be more than one derivation per UML::Constraint::specification.

So, I need to parse the body of the specification to retrieve the constrained attribute and the OCL expression to configure the SettingDelegate. Once again, OCL does it for me. The parser provides a List of org.eclipse.ocl.ecore.Contraints that I can use for getting both the constrained attribute(s) and the corresponding OCL expression(s).

The point is that these expressions has the ExpressionInOCL type. The strings I can get from their "body expressions" are not valid OCL code that I could use to create the eAnnotation.

An ugly solution would be, once the derived attribute identified, to restart from the uml::Constraint::specification, trying to parse it using some specific code in order to retrieve the string of the OCL code... But this would be rather cumbersome!

Do you see a better solution, maybe using an OCLAnalyser or something like this?

Thanks,




Yves
Re: Computing derived attribute values with dynamic EMF [message #1728159 is a reply to message #1728138] Thu, 31 March 2016 12:13 Go to previous messageGo to next message
Yves BERNARD is currently offline Yves BERNARDFriend
Messages: 152
Registered: July 2014
Senior Member
I confirm that it works with a "quick & dirty" solution as the one described in my previous post but I'm still looking for a more elegant and more robust solution. Wink

Yves
Re: Computing derived attribute values with dynamic EMF [message #1728163 is a reply to message #1728138] Thu, 31 March 2016 12:49 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Sorry, you require too much telepathy and intuition.

There is no org.eclipse.ocl.ecore.Contraint class. The classic OCL has
an org.eclipse.ocl.ecore.Constraint but then you refer to
ExpressionInOCL which rather suggests that you are using the Pivot OCL
as does your consideration of OCLinEcore.

If you want me to look at something, please provide code so that I can
understand rather than guess at what you are really doing.

See https://wiki.eclipse.org/OCL/ForumNetiquette

Regards

Ed Willink

On 31/03/2016 11:20, Yves BERNARD wrote:
> Hi Ed,
>
> I think I'm not far away from success but a tricky point remains.
> Maybe you have a solution for it.
>
> Following the instructions given by the OCLinEcore documentation (see
> my previous message), I can provide a string specifying the OCL code
> of the derivation. For example assuming two Boolean attributes "isOk"
> and "isNotOk", I can specify "not isOk" as the derived value of the
> "isNotOk" attribute. This works fine and the value of "isNotOk" is
> properly computed according to the value of the "isOK" attribute.
>
> The point is that the derivation constraints shall be specified in a
> UML model, through UML::Constraints owned by the classifier. They look
> something like:
>
> context MyClassifier::isNotOk : Boolean
> derive: not isOk
>
>
> Note that there can be more than one derivation per
> UML::Constraint::specification.
>
> So, I need to parse the body of the specification to retrieve the
> constrained attribute and the OCL expression to configure the
> SettingDelegate. Once again, OCL does it for me. The parser provides a
> List of org.eclipse.ocl.ecore.Contraints that I can use for getting
> both the constrained attribute(s) and the corresponding OCL
> expression(s).
>
> The point is that these expressions has the ExpressionInOCL type. The
> strings I can get from their "body expressions" are not valid OCL code
> that I could use to create the eAnnotation.
>
> An ugly solution would be, once the derived attribute identified, to
> restart from the uml::Constraint::specification, trying to parse it
> using some specific code in order to retrieve the string of the OCL
> code... But this would be rather cumbersome!
>
> Do you see a better solution, maybe using an OCLAnalyser or something
> like this?
>
> Thanks,
>
>
>
Re: Computing derived attribute values with dynamic EMF [message #1728179 is a reply to message #1728163] Thu, 31 March 2016 15:35 Go to previous messageGo to next message
Yves BERNARD is currently offline Yves BERNARDFriend
Messages: 152
Registered: July 2014
Senior Member
Yes, I have to admit that it is not easy to navigate among the miscellaneous versions/specializations of the homonymous classes of the OCL API! Smile

That point is that I cannot provide the full code here (I use Scala).

Note that my message didn't say that org.eclipse.ocl.ecore.Constraint was a Class.


So let's try being more precise.

1. An org.eclipse.ocl.ecore.OCL instance is created (name: ocl)

2. the following OCL code (including the line breaks) is store in a string and used to create an org.eclipse.ocl.OCLInput (name: oclInput)

        package X
	
	context MyClassifier::isNotOk : Boolean
	derive: not isOK
	
	endpackage


3. this oclInput is parsed by the ocl instance and the result (of type List<CT>) is stored in a value (name: constraints):

val constraints = ocl.parse(oclInput)


According to the documentation, and except if I missed something, in the case ofan org.eclipse.ocl.ecore.OCL (cf. http://download.eclipse.org/ocl/javadoc/6.0.0/org/eclipse/ocl/ecore/OCL.html), the type parameter "CT" refers to the definition of an Interface named "Constraint" which is defined in the package "org.eclipse.ocl.ecore" (cf. http://download.eclipse.org/ocl/javadoc/6.0.0/org/eclipse/ocl/ecore/Constraint.html). So, "constraints" is actually a List of elements which have the org.eclipse.ocl.ecore.Constraint type.

4. Elements from the "constraints" list are filtered and the information required to build the eAnnotations is extracted:

 for {
      c <- constraints.filter(_.getStereotype == "derivation" )
      stFeature = c.getConstrainedElements.head.asInstanceOf[EStructuralFeature]
      oclStr = c.getSpecification.getBodyExpression.toString()
    } 
    yield setDerivationBehavior(stFeature, oclStr)


The point is that the value of "oclStr" is then: "self.isOk.not()" while I would need the initial OCL code: "not isOK" (or "not self.isOk")


Yves
Re: Computing derived attribute values with dynamic EMF [message #1728186 is a reply to message #1728179] Thu, 31 March 2016 17:02 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi

Since you do not provide code you are largely on your own.

Since you use the old Classic OCL that is being superseded by the more
uniform more UML-aligned Pivot OCL, you are low on my priority list.

The Classic OCL has a ToStringVisitor that is clearly documented as
being for debug purposes.

The Pivot OCL has a similar ToStringVisitor but also an extensible
PrettyPrintVisitor that produces valid OCL / QVT.

The Pivot OCL eliminates the mega-parameter lists that are difficult to
get right. No CT to figure out.

The PIvot OCL also makes some progress in sorting out the distinction
between

derived CONSTRAINT => Constraint (accumulates down the inheritance
hierarchy)
initial VALUE => OCLExpression which is a ValueSpecification (redefines
down the inheritance hierarchy)

The Classic OCL treats them all as constraints leaving uncertainty as to
how init and der interact.

Regards

Ed Willink


On 31/03/2016 16:35, Yves BERNARD wrote:
> Yes, I have to admit that it is not easy to navigate among the
> miscellaneous versions/specializations of the homonymous classes of
> the OCL API! :)
>
> That point is that I cannot provide the full code here (I use Scala).
>
> Note that my message didn't say that org.eclipse.ocl.ecore.Constraint
> was a Class.
>
>
> So let's try being more precise.
>
> 1. An org.eclipse.ocl.ecore.OCL instance is created (name: ocl)
>
> 2. the following OCL code (including the line breaks) is store in a
> string and used to create an org.eclipse.ocl.OCLInput (name: oclInput)
>
>
> package X
>
> context MyClassifier::isNotOk : Boolean
> derive: not isOK
>
> endpackage
>
>
> 3. this oclInput is parsed by the ocl instance and the result (of type
> List<CT>) is stored in a value (name: constraints):
>
> val constraints = ocl.parse(oclInput)
>
>
> According to the documentation, and except if I missed something, in
> the case ofan org.eclipse.ocl.ecore.OCL (cf.
> http://download.eclipse.org/ocl/javadoc/6.0.0/org/eclipse/ocl/ecore/OCL.html),
> the type parameter "CT" refers to the definition of an Interface named
> "Constraint" which is defined in the package "org.eclipse.ocl.ecore"
> (cf.
> http://download.eclipse.org/ocl/javadoc/6.0.0/org/eclipse/ocl/ecore/Constraint.html).
> So, "constraints" is actually a List of elements which have the
> org.eclipse.ocl.ecore.Constraint type.
>
> 4. Elements from the "constraints" list are filtered and the
> information required to build the eAnnotations is extracted:
>
> for {
> c <- constraints.filter(_.getStereotype == "derivation" )
> stFeature =
> c.getConstrainedElements.head.asInstanceOf[EStructuralFeature]
> oclStr = c.getSpecification.getBodyExpression.toString()
> } yield setDerivationBehavior(stFeature, oclStr)
>
>
> The point is that the value of "oclStr" is then: "self.isOk.not()"
> while I would need the initial OCL code: "not isOK" (or "not self.isOk")
Previous Topic:How to add power operation to the primitive type Integer?
Next Topic:Global operation for oclAny
Goto Forum:
  


Current Time: Tue Mar 19 10:24:00 GMT 2024

Powered by FUDForum. Page generated in 0.02567 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top