Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Activating container() support in OCL*Delegates and OCLConsole(Configuring OCL components with ParsingOptions.implicitRootClass EOBJECT)
icon5.gif  Activating container() support in OCL*Delegates and OCLConsole [message #666838] Fri, 22 April 2011 20:08 Go to next message
Jörn Guy  Süß is currently offline Jörn Guy Süß
Messages: 83
Registered: July 2009
Location: Germany
Member

I use the container relationship intentionally in one of my ecore models to enforce a well-formedness rule.The structure is of the form A contains 1 B and A contains 1 C. I need to navigate from B and C to A to express some additional WFR. I would like to use the
container()
property for it, but it is not available in OCL.

What do I know about this issue?

  1. I can add a derived reference and implement it in Java. This means I need to introduce a technical artifact into the model to work around an infrastructure issue. Dead
  2. I can convert the composition to references and then use opposed references. That means I have to restructure my model to work around an infrastructure issue. Dead
  3. The problem can be solved by having the OCL infrastructure configured for properties of EOBJECT, as shown in the FAQ:How do I invoke methods such as eContainer(), eContents(), eGet()?


I have three questions:

  1. Can the OCL*Delegates be configured to accept the additional properties of EOBJECT, as described in the FAQ?
  2. Can the OCL Console that I use for type-checking be configured to accept the additional properties of EOBJECT, as described in the FAQ?
  3. If not, where and how do these components need to be patched to allow this behaviour?


Help is appreciated, as I like OCL and would like to promote it in practice, but this issue is a blocker on my project, and I will have to scrap OCL use if I cannot get it to work.
Re: Activating container() support in OCL*Delegates and OCLConsole [message #666842 is a reply to message #666838] Sat, 23 April 2011 01:34 Go to previous messageGo to next message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Hi Joern

Under what timescales is this a blocker?

The Indigo release has much more comprehensive support for the Xtext
editors with an Xtext-based OCL Console, an extensible modelled OCL
Standard Library and a UML-derived highly OMG compliant pivot model
representation hiding the eccentricities of Ecore and UML.

eContainer() should never have been visible in Eclipse OCL.

container() should never be visible in OMG OCL; it's a MOF operation and
MOF is not part of thge UML package merge.

The modelled library for Indigo M6 therefore has oclContainer() and
oclContents() which might eventually make it into OMG OCL. No further
action required to use them.

This functionality is all part of a prototype resolving some major
mostly behind-the-scenes problems in the OCL specification. It is
therefore part of the Examples and Editors optional feature. It is
planned to move it from examples to core functionality for Juno.

To make the functionality available for the old console probably just
requires a one/two line (menu-driven) options zap when the OCL facade is
created. But you'll also hit the problem that the old console has no
Load Resource... for Complete OCL.

Hope you can wait for Indigo (June release, M6 now, M7 two weeks).

[For the specific problem of opposites, you may add oppositeRoleName
annotations to your Ecore model so that OCL can use the missing names. ]

Regards

Ed Willink



On 23/04/2011 01:08, Joern Guy Suess wrote:
> I use the container relationship intentionally in one of my ecore
> models to enforce a well-formedness rule.The structure is of the form
> A contains 1 B and A contains 1 C. I need to navigate from B and C to
> A to express some additional WFR. I would like to use the container()
> property for it, but it is not available in OCL.
>
> What do I know about this issue?
>
> I can add a derived reference and implement it in Java. This means I
> need to introduce a technical artifact into the model to work around
> an infrastructure issue. x(
> I can convert the composition to references and then use opposed
> references. That means I have to restructure my model to work around
> an infrastructure issue. x(
> The problem can be solved by having the OCL infrastructure configured
> for properties of EOBJECT, as shown in the
> FAQ:http://wiki.eclipse.org/MDT/OCL/FAQ#How_do_I_invoke_meth ods_such_as_eContainer.28.29.2C_eContents.28.29.2C_eGet.28.2 9.3F
>
>
> I have three questions:
>
> Can the OCL*Delegates be configured to accept the additional
> properties of EOBJECT, as described in the FAQ?
> Can the OCL Console that I use for type-checking be configured to
> accept the additional properties of EOBJECT, as described in the FAQ?
> If not, where and how do these components need to be patched to allow
> this behaviour?
>
>
> Help is appreciated, as I like OCL and would like to promote it in
> practice, but this issue is a blocker on my project, and I will have
> to scrap OCL use if I cannot get it to work.
Re: Activating container() support in OCL*Delegates and OCLConsole [message #667130 is a reply to message #666842] Tue, 26 April 2011 19:42 Go to previous messageGo to next message
Jörn Guy  Süß is currently offline Jörn Guy Süß
Messages: 83
Registered: July 2009
Location: Germany
Member

Hi Ed,

Thanks for the detailed information. Let's hope that the oclContainer() operation makes its way into the specification. I know how slowly it can move. Some of the input from the UML conference in SF is still on the tbd list, as far as I can see Wink

My deadline is a week away. I wanted to use OCL to drive the backing model of a simulator. I will have to go with one of the hacks. I cannot justify diverting much time to the infrastructure. I will investigate the annotation and see if that solves the issue.

Looking forward to the next release. It is good to see that OCL is getting some standard integrated tooling.

BTW: Is anyone considering an editor for OCL documents? I think they would be fantastic to write stage validation in. One could write a document for each stage, register as an extension point and then get step by step validation. Link a resource to the invariant name and you have multi-lingual validator, without writing a single line of code. How good is that?

I will post an update here on how things develop.

Best wishes,

Joern Guy Suess
Re: Activating container() support in OCL*Delegates and OCLConsole [message #667142 is a reply to message #667130] Wed, 27 April 2011 01:02 Go to previous message
Ed Willink is currently offline Ed Willink
Messages: 4003
Registered: July 2009
Senior Member
Ho Joern
> Thanks for the detailed information. Let's hope that the
> oclContainer() operation makes its way into the specification. I know
> how slowly it can move.
Since I'm on the OMG OCL RTF, what happens to OCL is significantly
influenced by what I have time to get round to. Right now modeling the
OCL specification so that it is free from stupid typos is top priority,
then change material can be auto-generated allowing more productive
progress.
> Some of the input from the UML conference in SF is still on the tbd
> list, as far as I can see ;)
News to me. There are no raised OMG issues with respect to OCL.
> My deadline is a week away. I wanted to use OCL to drive the backing
> model of a simulator. I will have to go with one of the hacks. I
> cannot justify diverting much time to the infrastructure. I will
> investigate the annotation and see if that solves the issue.
OCL 2.3.defines navigation of missing association end names so that A::b
: B can be reverse navigated from a B as aB.A. In OCL 2.0/2.2 there was
a suggestion that the first letter be converted to lowercase so that
aB.a might work. You could give each a quick try; you might get lucky. I
implemented the OCL 2.3 behaviour for the new OCL code yesterday, expect
to commit it today. Implementing it identified three new problems with
the specification.
>
> Looking forward to the next release. It is good to see that OCL is
> getting some standard integrated tooling.
>
> BTW: Is anyone considering an editor for OCL documents? I think they
> would be fantastic to write stage validation in. One could write a
> document for each stage, register as an extension point and then get
> step by step validation. Link a resource to the invariant name and you
> have multi-lingual validator, without writing a single line of code.
> How good is that?
Yes. It is the Complete OCL editor. The Helios release supports an OCL
document complementing an Ecore model. It's touch and go whether some
degree of support for UML will be in Indigo. But perhaps I miss your
point about stages.

Regards

Ed Willink
Previous Topic:Retrieve literals from enum
Next Topic:Parallelized execution of OCL queries
Goto Forum:
  


Current Time: Tue Jul 22 21:30:01 EDT 2014

Powered by FUDForum. Page generated in 0.02156 seconds