Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Future Directions for MDT/OCL(Pivot vs. UML/Ecore)
Future Directions for MDT/OCL [message #665444] Thu, 14 April 2011 15:54 Go to next message
Axel Uhl is currently offline Axel UhlFriend
Messages: 40
Registered: July 2009
Member
There are currently two possible strands of activity in the MDT/OCL project that compete for resources. I'd like to quickly summarize them as unbiased as I can, then providing a personal view on things, hoping to get some community feedback.

For one thing, there is what may be considered a "mature" code base. It tries its best to accomodate for two metamodels: UML and Ecore. This incurs some complications and requires maintaining two implementation flavors with one common base, using a lot of Java generics to cope. On a positive note, this approach tunes each of the two flavors to the target environment. In particular, the Ecore-specific implementation is tightly integrated with the Ecore metamodel which works well for tool building efforts utilizing the standard Ecore/EMF capabilities.

OMG OCL 2.2 compliance is still lacking in some areas of the mature implementation. See, for example, https://bugs.eclipse.org/bugs/show_bug.cgi?id=342644. And surely there are several other issues as well.

With Eclipse 3.7 (Indigo), MDT/OCL will ship a new implementation in its examples feature that demonstrates a different approach. A Pivot metamodel that attempts to bridge the incompatibilities between UML and Ecore is provided, and OCL expressions will be bound to instances of this Pivot metamodel instead of directly attaching to the Ecore / UML metamodel. In addition, the Pivot approach brings with it an entirely modeled standard library. Its evaluator holds some improvements as to the performance of iterators and collections.

The Pivot model raises a few questions regarding the metamodel life cycle, as Pivot model elements need to be created for either UML or Ecore model elements. This may happen on the fly. It may also be desirable to store the Pivot models derived from the UML/Ecore models, be it for performance or static analysis or simply for storing the OCL expressions referring to the Pivot elements. Storing the Pivot models, in turn, raises a number of questions such as

- What's the resource and its URI for storing the Pivot model?
- What's the identity of the Pivot elements, how can corresponding elements in the UML/Ecore models be obtaines and how can we efficiently navigate from the UML/Ecore models to the corresponding Pivot elements? (Clear how to do this when constructed on the fly, e.g., by maintaining maps with the links; not so clear when persistently storing the Pivot models and OCL expressions.)
- What happens in those cases where Pivot elements need to exist where there is no 1:1 counterpart on the Ecore side, as it the case for uni-directional references in Ecore which are represented as associations with two properties in the Pivot model?
- How to version-control the Pivot models?
- How to deal with synchronization issues when either the Pivot model or the UML/Ecore model is modified? (Think about refactoring operations on the Ecore model and their effects on the OCL models attached to the Pivot model)

The MDT/OCL team just has so much time to spend, and we're currently discussing where to put our focus. We could spend time on improving the existing UML/Ecore-specific implementations w.r.t. OMG OCL compliance, bug fixing and performance improvements. Reasons in favor:

- This is the default implementation shipping with Indigo which is currently in use.
- Improvements will benefit the existing user community immediately.
- It serves as risk mitigation strategy in case some issues with the new Pivot approach turn out to be hard to overcome, perhaps limiting its adoption.

We could invest our time into the Pivot model approach. Reasons in favor:

- Betting on the Pivot model's widespread adoption, the future-oriented implementation would get the most development resources.
- Improving the Pivot model fast can help in furthering its chances to adoption.

Now, let me quickly summarize my personal view on this. We at SAP are users of the Ecore flavor of OCL. We like the tight integration with Ecore/EMF and the fairly simple life cycle this gives us. We'd like to see some performance improvements in the existing evaluator code base as well as fixes to the major incompatibilities with the OCL spec that are hard to work around (see again, e.g., https://bugs.eclipse.org/bugs/show_bug.cgi?id=342644). We are a bit afraid of the life cycle questions raised by the Pivot approach as we expect a significant complexity add to our model management. Besides, we don't have a use case for the UML integration, so one of the key reasons why the Pivot model needs to exist is not relevant to us. Of course, this doesn't apply to the positive side effects of having a modeled standard library, smarter collection implementations and generally a more truthful standard implementation as found in the current environment. However, we think that these benefits would as well be achievable with the standard environment, not requiring another model next to the OCL-annotated Ecore model.

I would like to hear from our community what they think about this. Any comments are very welcome.

Thanks and best,
-- Axel
Re: Future Directions for MDT/OCL [message #770147 is a reply to message #665444] Fri, 23 December 2011 13:15 Go to previous messageGo to next message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 301
Registered: July 2009
Senior Member
Dear Axel.
It must be frustrating there was no reply to this substantial message
since April. Or is there a mailing list, I do not know of, where the
discussion happened?

The huge progress Ed Willing made since this posting seems to make
clear, that the Pivot based version will come to life.

However I think we should nevertheless do some improvements to the
exiting version of OCL, especially the one tuned towards ECore.

The reason is that we are at a decision point in the Eclipse community
where the EMof+OCL+QVTO stack must be implemented in an as mature and
stable way as possible.

This will build the foundation for supporting the future with the Pivot
implementation. But only doing the Pivot version may turn the focus away
from the visionary modeling vision created by the OMG, and brought to
life in a pragmatic way be the Eclipse Modeling Projects headed by Ed Merks.

Of course you are right that we cannot spend the resources twice.

Therefore I will ask people I know to propose help and resources to
improve the current ECore tailored version, without taking time away
from the people working on the Pivot model.

Hope you see a posting here with a proposal to help soon.

Best Regards, Philipp

On 14.04.2011 17:54, Axel Uhl wrote:
> There are currently two possible strands of activity in the MDT/OCL
> project that compete for resources. I'd like to quickly summarize them
> as unbiased as I can, then providing a personal view on things, hoping
> to get some community feedback.
>
> For one thing, there is what may be considered a "mature" code base. It
> tries its best to accomodate for two metamodels: UML and Ecore. This
> incurs some complications and requires maintaining two implementation
> flavors with one common base, using a lot of Java generics to cope. On a
> positive note, this approach tunes each of the two flavors to the target
> environment. In particular, the Ecore-specific implementation is tightly
> integrated with the Ecore metamodel which works well for tool building
> efforts utilizing the standard Ecore/EMF capabilities.
>
> OMG OCL 2.2 compliance is still lacking in some areas of the mature
> implementation. See, for example,
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=342644. And surely there
> are several other issues as well.
>
> With Eclipse 3.7 (Indigo), MDT/OCL will ship a new implementation in its
> examples feature that demonstrates a different approach. A Pivot
> metamodel that attempts to bridge the incompatibilities between UML and
> Ecore is provided, and OCL expressions will be bound to instances of
> this Pivot metamodel instead of directly attaching to the Ecore / UML
> metamodel. In addition, the Pivot approach brings with it an entirely
> modeled standard library. Its evaluator holds some improvements as to
> the performance of iterators and collections.
>
> The Pivot model raises a few questions regarding the metamodel life
> cycle, as Pivot model elements need to be created for either UML or
> Ecore model elements. This may happen on the fly. It may also be
> desirable to store the Pivot models derived from the UML/Ecore models,
> be it for performance or static analysis or simply for storing the OCL
> expressions referring to the Pivot elements. Storing the Pivot models,
> in turn, raises a number of questions such as
>
> - What's the resource and its URI for storing the Pivot model?
> - What's the identity of the Pivot elements, how can corresponding
> elements in the UML/Ecore models be obtaines and how can we efficiently
> navigate from the UML/Ecore models to the corresponding Pivot elements?
> (Clear how to do this when constructed on the fly, e.g., by maintaining
> maps with the links; not so clear when persistently storing the Pivot
> models and OCL expressions.)
> - What happens in those cases where Pivot elements need to exist where
> there is no 1:1 counterpart on the Ecore side, as it the case for
> uni-directional references in Ecore which are represented as
> associations with two properties in the Pivot model?
> - How to version-control the Pivot models?
> - How to deal with synchronization issues when either the Pivot model or
> the UML/Ecore model is modified? (Think about refactoring operations on
> the Ecore model and their effects on the OCL models attached to the
> Pivot model)
>
> The MDT/OCL team just has so much time to spend, and we're currently
> discussing where to put our focus. We could spend time on improving the
> existing UML/Ecore-specific implementations w.r.t. OMG OCL compliance,
> bug fixing and performance improvements. Reasons in favor:
>
> - This is the default implementation shipping with Indigo which is
> currently in use.
> - Improvements will benefit the existing user community immediately.
> - It serves as risk mitigation strategy in case some issues with the new
> Pivot approach turn out to be hard to overcome, perhaps limiting its
> adoption.
>
> We could invest our time into the Pivot model approach. Reasons in favor:
>
> - Betting on the Pivot model's widespread adoption, the future-oriented
> implementation would get the most development resources.
> - Improving the Pivot model fast can help in furthering its chances to
> adoption.
>
> Now, let me quickly summarize my personal view on this. We at SAP are
> users of the Ecore flavor of OCL. We like the tight integration with
> Ecore/EMF and the fairly simple life cycle this gives us. We'd like to
> see some performance improvements in the existing evaluator code base as
> well as fixes to the major incompatibilities with the OCL spec that are
> hard to work around (see again, e.g.,
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=342644). We are a bit
> afraid of the life cycle questions raised by the Pivot approach as we
> expect a significant complexity add to our model management. Besides, we
> don't have a use case for the UML integration, so one of the key reasons
> why the Pivot model needs to exist is not relevant to us. Of course,
> this doesn't apply to the positive side effects of having a modeled
> standard library, smarter collection implementations and generally a
> more truthful standard implementation as found in the current
> environment. However, we think that these benefits would as well be
> achievable with the standard environment, not requiring another model
> next to the OCL-annotated Ecore model.
>
> I would like to hear from our community what they think about this. Any
> comments are very welcome.
>
> Thanks and best,
> -- Axel
Re: Future Directions for MDT/OCL [message #770200 is a reply to message #770147] Fri, 23 December 2011 16:02 Go to previous messageGo to next message
Axel Uhl is currently offline Axel UhlFriend
Messages: 40
Registered: July 2009
Member
Hi Philipp,

no, I haven't seen any answer other than yours so far.

I could imagine that Ed Willink may disagree about your paragraph on the OMG and the relation to Eclipse/EMF/MOF. The way I've seen it so far, Ed Willink's Pivot implementation is trying to close a few gaps that exist between the OMG standards and the "mature" Ecore-tailored Eclipse implementations. As I've mentioned before, this comes at some cost, particularly in the area of managing metamodels and their life cycle; here and there also with regards to performance, e.g., for numerical data types, although the Pivot implementation has brought us significantly closer to the spec (which is almost unimplementable when you think about the Real data type, for example).

When you say "implementing QVTo etc. in a *mature* way" are you referring to the OCL/Ecore implementation as "mature?" This is the terminology we've been using in the OCL project for the Ecore-based implementation, as opposed to the Pivot implementation. Can you clarify?

Best,
-- Axel
Re: Future Directions for MDT/OCL [message #771819 is a reply to message #770200] Wed, 28 December 2011 08:32 Go to previous messageGo to next message
Philipp W. Kutter is currently offline Philipp W. KutterFriend
Messages: 301
Registered: July 2009
Senior Member
> no, I haven't seen any answer other than yours so far.
This is a pitty.

> I could imagine that Ed Willink may disagree about your paragraph on the
> OMG and the relation to Eclipse/EMF/MOF.
I will discuss the point directly with him.


> When you say "implementing QVTo etc. in a *mature* way" are you
> referring to the OCL/Ecore implementation as "mature?" This is the
> terminology we've been using in the OCL project for the Ecore-based
> implementation, as opposed to the Pivot implementation. Can you clarify?
Yes, I used the same terminology.

The ECore based implementation simply went through so many usages, that
it is more mature. However I recently still detected a major bug w.r.t.
method binding.

I am sure, Ed Willink can reflect all progress in the ECore based
implementation in the Pivot based implementation, thus every progress
on the ECore based implementation should be a good news for the Pivot
based implementation, except if resources all go into the ECore based
implementation.

Thus a good balance should be found. The GMF Tooling project team
proposed recently to help pushing the impact analyzer which currently
works on the ECore based implementation of OCL, but the discussion
already shows, that this will have some good side effects on the future
integration of the impact analyzer for the Pivot implementation.

Regards, Philipp
Re: Future Directions for MDT/OCL [message #771900 is a reply to message #771819] Wed, 28 December 2011 13:31 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4186
Registered: July 2009
Senior Member
Hi

It is important not to get confused by the two potential variation
points
(https://www.most-project.eu/admin/xinha/plugins/ExtendedFileManager/images/Publications/2010/related/WILKETHIELEWENDE2010MODELS.pdf).
The pivot approach independently normalises both meta-model variation
(EMOF,Ecore,UML,...) as Pivot and model variation (EObject, POJO, XML,
....) as Value.

The meta-model variation is significant mostly during analysis. The
model variation during evaluation.

The normalisation to Value has marginal costs/savings; an
IntegerValueImpl is essentially identical to Integer; both wrap "int";
the difference is that IntegerValueImpl is polymorphically a Value, and
polymorphically an IntegerValue allowing automatic promotion to a 'long'
or 'BigInteger' when actually necessary.

The new evaluator has directly generated code largely eliminating the
meta-model. Evaluation occurs on EObjectValues that wrap the access to
EObjects. There should therefore be little trouble using the new
evaluator in conjunction with other Ecore tools.

Regards

Ed Willink


On 28/12/2011 08:32, Philipp W. Kutter | Montages AG wrote:
>
>> no, I haven't seen any answer other than yours so far.
> This is a pitty.
>
>> I could imagine that Ed Willink may disagree about your paragraph on the
>> OMG and the relation to Eclipse/EMF/MOF.
> I will discuss the point directly with him.
>
>
>> When you say "implementing QVTo etc. in a *mature* way" are you
>> referring to the OCL/Ecore implementation as "mature?" This is the
>> terminology we've been using in the OCL project for the Ecore-based
>> implementation, as opposed to the Pivot implementation. Can you clarify?
> Yes, I used the same terminology.
>
> The ECore based implementation simply went through so many usages,
> that it is more mature. However I recently still detected a major bug
> w.r.t.
> method binding.
>
> I am sure, Ed Willink can reflect all progress in the ECore based
> implementation in the Pivot based implementation, thus every progress
> on the ECore based implementation should be a good news for the Pivot
> based implementation, except if resources all go into the ECore based
> implementation.
>
> Thus a good balance should be found. The GMF Tooling project team
> proposed recently to help pushing the impact analyzer which currently
> works on the ECore based implementation of OCL, but the discussion
> already shows, that this will have some good side effects on the
> future integration of the impact analyzer for the Pivot implementation.
>
> Regards, Philipp
Re: Future Directions for MDT/OCL [message #772207 is a reply to message #771900] Thu, 29 December 2011 08:48 Go to previous messageGo to next message
Axel Uhl is currently offline Axel UhlFriend
Messages: 40
Registered: July 2009
Member
Ed,

doesn't the new evaluator depend on the Pivot metamodel APIs? At which point in time does compilation of OCL expressions to Java happen and how is the generated/compiled Java code managed?

Thanks,
-- Axel
Re: Future Directions for MDT/OCL [message #772233 is a reply to message #772207] Thu, 29 December 2011 10:04 Go to previous message
Ed Willink is currently offline Ed WillinkFriend
Messages: 4186
Registered: July 2009
Senior Member
Hi

You can easily verify that org.eclipse.ocl.examples.{domain,library}
have a full evaluator but no dependency on
org.eclipse.ocl.examples.{codegen,pivot}, so within the reflective
limitations of not using oclType() arbitrary evaluation is possible.

The codegen (at genmodel-time) does two jobs.
a) A dispatch table variant of the user meta-model is created as e.g.
UserTables.java adjacent to UserPackage.java. The dispatch table uses
optimized Inheritance/Fragment tables that depend on a very lightweight
structural meta-model defined by
DomainElement/DomainType/DomainOperation etc with ExecutorType as a
concrete implementation. (The Pivot meta-model also implements
DomainElement/DomainType/DomainOperation etc.) - see OCLstdlibTables or
PivotTables or
/org.eclipse.ocl.examples.xtext.tests/src/codegen/company/CodegencompanyTables.java
for examples.
b) Operation/Property bodies are provided for all OCL expressions in a
bodies package, adjacent to and invoked from the impl package. The use
of direct Java eliminates the need for representtaions of OCL meta-model
classes such as OclExpression. Just Value and run-time support classes
are required.

With an M6 deadline looming, I'm reviewing the APIs and can't really see
any reason why Inheritance/Fragment tables cannot be created on the fly
from a dynamic Ecore EPackage (or Java Package or XSD schema). This
should allow oclType() in straight EObject OCL reducing the behavoural
limitation to
- reflective usage such as oclType().ownedOperation() requires
PivotTables on the class path
- Complete OCL usage requires the Pivot facilities to perform the
associated merges
It should also make the gear change between the full Pivot
representation and the lightweight dispatch representation clearer.

Regards

Ed Willink

On 29/12/2011 08:48, Axel Uhl wrote:
> Ed,
>
> doesn't the new evaluator depend on the Pivot metamodel APIs? At which
> point in time does compilation of OCL expressions to Java happen and
> how is the generated/compiled Java code managed?
>
> Thanks,
> -- Axel
Previous Topic:OCL Table
Next Topic:Running .ocl against a model
Goto Forum:
  


Current Time: Fri Dec 19 02:26:32 GMT 2014

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

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