Eclipse Community Forums: MDT (Model Development Tools) » [Announce] OCL Tools component proposal

Help

Home

Home » Modeling » MDT (Model Development Tools) » [Announce] OCL Tools component proposal

Show: Today's Messages :: Show Polls :: Message Navigator

[Announce] OCL Tools component proposal [message #377141]

Tue, 31 July 2007 15:07

Kenn Hussey

Messages: 1620
Registered: July 2009

Senior Member

Attached is a proposal to create a new OCL Tools component as part of the
MDT subproject. Technical discussions about the formation, scope, and
direction of this new component will take place on the eclipse.modeling.mdt
newsgroup (please prefix the subject with [OCL Tools]). If you have comments
or ideas, or interest in contributing to the component, please join in the
discussion!

Attachment: OCLTools.zip
(Size: 7.00KB, Downloaded 234 times)

Report message to a moderator

Re: [Announce] OCL Tools component proposal [message #377143 is a reply to message #377141]

Fri, 03 August 2007 13:54

William Piers

Messages: 301
Registered: July 2009

Senior Member

Hello,

As an ATL contributor, I am currently working on providing syntax editor
for ATL, and I am very interested in this component.
I need to implement a type inference system for OCL in order to provide
full completion within the ATL editors, and although the scope of this
proposal goes far beyond that, I hope that I will be able to reuse part
of the work that will be done to achieve my goals.

I will be quite busy with providing completion for both ATL and OCL
language within the same editor, so I am eager to find out more about
the inside of this future component and to know if it will be possible
for me to integrate it.

Best regards,

--
William Piers
MDA Consultant, Obeo (http://www.obeo.fr)

Kenn Hussey a écrit :
> Attached is a proposal to create a new OCL Tools component as part of the
> MDT subproject. Technical discussions about the formation, scope, and
> direction of this new component will take place on the eclipse.modeling.mdt
> newsgroup (please prefix the subject with [OCL Tools]). If you have comments
> or ideas, or interest in contributing to the component, please join in the
> discussion!

Report message to a moderator

[OCL Tools] Re: [Announce] OCL Tools component proposal [message #377144 is a reply to message #377143]

Sat, 04 August 2007 11:01

Miguel Garcia

Messages: 77
Registered: July 2009

Member

William,

Providing Content Assist in an OCL text editor is within the scope of OCL
Tools. Actually, MDT OCL already provides the building blocks for that, as
described in its online help:

"The OCLHelper API provides support for content-assist in rich editors, by
parsing partial OCL expressions and supplying completion suggestions. The
List<Choice> getSyntaxHelp(ConstraintKind, String) operation returns a list
of suggestions for the next token to follow the end of the expression
fragment"

Such functionality is exemplified in OCL Interpreter (an example delivered
as part of MDT OCL).

What is (still) missing is a full-fledged OCL-aware text editor, although
some prototypes are in the works.

I guess your main uses cases are ATL-related, as I understand from your
email and from the "Declarative QVT Component Proposal",
http://wiki.eclipse.org/images/9/9a/Declarative_QVT_componen t_proposal.pdf
where you appear as Initial Committer

(For the rest of us, that proposal is about a creating a component in the
M2M project, which has been approved and focuses on Model-to-Model
Transformations, http://www.eclipse.org/m2m/)

From what I understand, nothing stands in the way for components under the
M2M umbrella to reuse functionality exported by (future) OCL Tools plugins
(the idea appears already in the OCL Tools proposal), but I don't yet see
how contributions originating in (some) M2M component can find their way
into OCL Tools, as those contributions assume a superset / different
language than OCL 2.0.

What areas of the future OCL Tools would you like to see completed first?
(other than the OCL Compiler for EMF, which is ready). You might consider
participating in their development in parallel to your activities in M2M
projects.

Regards,

Miguel

--
Miguel Garcia miguel.garcia@tuhh.de
Institute for Software Systems (STS), AB 4-02
Technische Universitaet Hamburg-Harburg
Harburger Schlossstr. 20, 21073 Hamburg Fax: (+49)40-42878-2515
http://www.sts.tu-harburg.de/~mi.garcia

"William Piers" <william.piers@obeo.fr> wrote in message
news:f8vc1s$jo0$1@build.eclipse.org...
> Hello,
>
> As an ATL contributor, I am currently working on providing syntax editor
> for ATL, and I am very interested in this component.
> I need to implement a type inference system for OCL in order to provide
> full completion within the ATL editors, and although the scope of this
> proposal goes far beyond that, I hope that I will be able to reuse part of
> the work that will be done to achieve my goals.
>
> I will be quite busy with providing completion for both ATL and OCL
> language within the same editor, so I am eager to find out more about the
> inside of this future component and to know if it will be possible for me
> to integrate it.
>
> Best regards,
>
> --
> William Piers
> MDA Consultant, Obeo (http://www.obeo.fr)
>
> Kenn Hussey a

Report message to a moderator

Re: [Announce] OCL Tools component proposal [message #377148 is a reply to message #377141]

Sat, 04 August 2007 17:53

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Kenn Hussey wrote:
> Attached is a proposal to create a new OCL Tools component as part of the
> MDT subproject. Technical discussions about the formation, scope, and
> direction of this new component will take place on the eclipse.modeling.mdt
> newsgroup (please prefix the subject with [OCL Tools]). If you have comments
> or ideas, or interest in contributing to the component, please join in the
> discussion!
>
>
Hi

I have just uploaded the Eclipse 3.3 aligned release of the UMLX tools.
(see http://www.eclipse.org/gmt/umlx/download/index.html or
http://download.eclipse.org/technology/gmt/umlx/updates/)

These provide:

A Model Registry to support resolution of the vague model name
typical of many models and the physical resource.

Multi-page editors supporting concrete (textual)
syntax and abstract (Ecore XMI, EMOF XMI, Resource tree) pages.

There are four editors, parsers, unparsers sharing very similar techology
KM3 for meta-models (Ecore)
OCL for ...
QVTcore
QVTrelation

The OCL is perhaps of most relevance to the OCL tools proposal, although
the MDT OCL refactoring to provide the extensibility to support re-use for
QVTcore and QVTrelation may be significant too.

Each of the above is available with Ecore-based or EMOF-based meta-models;
EMOF is determined by XML namespace usage not file extension and EMOF or
Ecore meta-models may be used interchangeably.

The refactoring of the org.eclipse.ocl.internal.parser to support extensibility
and more plausible error handling may be found in
org.eclipse.gmt.umlx.ocl.cst.parser. The error handling could be improved
further but I didn't want to have to change too much of the existing code.
------------------------------------------------------------ --------------
The OCL editor performs a very limited amount of semantic checking; limited
because the current OCL environments and parsers presume that they exit on
first failure, and do not work hard to proceed or diagnose errors.

Slight modification to parsing calls to use a consistent error handling policy
that always works with respect to a CSTNode so that the correct underline
context is available for markers would make the editor much better. Calls that
currently pass an Identifier or a list of Strings need to change to avoid
loss of the IdentifierCS, PathCS. A notable example is lookupClassifier that
has lost the CSTNode context with which to report the error.

Regards

Ed Willink

Report message to a moderator

[OCL Tools] the OCL text editor in UMLX [message #377151 is a reply to message #377148]

Mon, 06 August 2007 08:34

Miguel Garcia

Messages: 77
Registered: July 2009

Member

Ed,

I've taken a look at plugins

org.eclipse.gmt.umlx.editor
org.eclipse.gmt.umlx.ocl.cst
org.eclipse.gmt.umlx.ocl.editor

and in the process got familiarized with the Model Registry capability. I
see the architecture behind the tooling.

Leaving aside that tooling, and just focusing on the OCL editor, I have some
comments:

a) keeping in-synch EMOF and Ecore files storing the ASTs for the .ocl text
being edited is uncommon.
Which use cases are enabled by them?

b) the UMLX OCL editor has some usability features (new file wizard, problem
markers, sxntax highlighting, automatic indentation) but lacks others (Auto
Completion, handling OCL's package statement).

I compared before different editors, and found useful to catalog their
usability features.
The result is Ch. 1 of
http://www.sts.tu-harburg.de/~mi.garcia/SoC2007/draftreport. pdf
(besides features, there are code snippets and references to further
material on how to implement them)

Running the risk of offering a laundry list, the UMLX OCL editor could be
extended to support:

- parentheses matching
- range indicator
- templates (for example for iterate)
- content outline
- folding
- hovers over text fragments (e.g. to display definitions)
- hyperlinks
- mark occurrences
- context menu on the editor surface, for example Go to Declaration
- content formatting
- views, for example OCLASTView,
http://www.eclipse.org/articles/article.php?file=Article-How ToProcessOCLAbstractSyntaxTrees/index.html
- EMF Type Hierarchy view, as in
http://www.sts.tu-harburg.de/%7Emi.garcia/SoC2007/Improvemen tsToTheEmfaticEditor.pdf

So, what I'm saying is: getting leverage from the architecture used to
deliver QVTr, QVTc, KM3, and so on editors can provide some of the
functionality needed, however the fine-tuning still remains to be done, and
it's that fine-tuning that the OCL user cares about as it has the biggest
impact on productivity.

Regards,

Miguel

--
Miguel Garcia miguel.garcia@tuhh.de
Institute for Software Systems (STS), AB 4-02
Technische Universitaet Hamburg-Harburg
Harburger Schlossstr. 20, 21073 Hamburg Fax: (+49)40-42878-2515
http://www.sts.tu-harburg.de/~mi.garcia

----- Original Message -----
From: "Ed Willink" <ed@willink.me.uk>
Newsgroups: eclipse.modeling.mdt
Sent: Saturday, August 04, 2007 7:53 PM
Subject: Re: [Announce] OCL Tools component proposal

> Kenn Hussey wrote:
>> Attached is a proposal to create a new OCL Tools component as part of the
>> MDT subproject. Technical discussions about the formation, scope, and
>> direction of this new component will take place on the
>> eclipse.modeling.mdt newsgroup (please prefix the subject with [OCL
>> Tools]). If you have comments or ideas, or interest in contributing to
>> the component, please join in the discussion!
>>
>>
> Hi
>
> I have just uploaded the Eclipse 3.3 aligned release of the UMLX tools.
> (see http://www.eclipse.org/gmt/umlx/download/index.html or
> http://download.eclipse.org/technology/gmt/umlx/updates/)
>
> These provide:
>
> A Model Registry to support resolution of the vague model name
> typical of many models and the physical resource.
>
> Multi-page editors supporting concrete (textual)
> syntax and abstract (Ecore XMI, EMOF XMI, Resource tree) pages.
>
> There are four editors, parsers, unparsers sharing very similar techology
> KM3 for meta-models (Ecore)
> OCL for ...
> QVTcore
> QVTrelation
>
> The OCL is perhaps of most relevance to the OCL tools proposal, although
> the MDT OCL refactoring to provide the extensibility to support re-use for
> QVTcore and QVTrelation may be significant too.
>
> Each of the above is available with Ecore-based or EMOF-based meta-models;
> EMOF is determined by XML namespace usage not file extension and EMOF or
> Ecore meta-models may be used interchangeably.
>
> The refactoring of the org.eclipse.ocl.internal.parser to support
> extensibility
> and more plausible error handling may be found in
> org.eclipse.gmt.umlx.ocl.cst.parser. The error handling could be improved
> further but I didn't want to have to change too much of the existing code.
> ------------------------------------------------------------ --------------
> The OCL editor performs a very limited amount of semantic checking;
> limited
> because the current OCL environments and parsers presume that they exit on
> first failure, and do not work hard to proceed or diagnose errors.
>
> Slight modification to parsing calls to use a consistent error handling
> policy
> that always works with respect to a CSTNode so that the correct underline
> context is available for markers would make the editor much better. Calls
> that
> currently pass an Identifier or a list of Strings need to change to avoid
> loss of the IdentifierCS, PathCS. A notable example is lookupClassifier
> that
> has lost the CSTNode context with which to report the error.
>
> Regards
>
> Ed Willink
>

Report message to a moderator

Re: [OCL Tools] the OCL text editor in UMLX [message #377154 is a reply to message #377151]

Mon, 06 August 2007 20:35

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Miguel

> a) keeping in-synch EMOF and Ecore files storing the ASTs for the .ocl text
> being edited is uncommon.
> Which use cases are enabled by them?

The editor is updating either text or resource never both, so OCL text and AST
are cross generated by parsing/unparsing (losing comments and formatting).

Incremental parsing/update is a low priority future feature.

Preserving comments and possibly formatting is higher but still low priority.

EMOF/Ecore synchronisation is a beneficial feature of stateless EMOF adapters.

The sole use case that the EMOF functionality is intended to support is load/save of
OMG compliant EMOF-based OCL within an Ecore-based MDT OCL tool. EMOF editing
and the EMOF/Ecore synchronisation is an accidental bonus.

> b) the UMLX OCL editor has some usability features (new file wizard, problem
> markers, sxntax highlighting, automatic indentation) but lacks others (Auto
> Completion, handling OCL's package statement).
>
> I compared before different editors, and found useful to catalog their
> usability features.
> The result is Ch. 1 of
> http://www.sts.tu-harburg.de/~mi.garcia/SoC2007/draftreport. pdf
> (besides features, there are code snippets and references to further
> material on how to implement them)
>
> Running the risk of offering a laundry list, the UMLX OCL editor could be
> extended to support:
>
> - parentheses matching
> - range indicator
> - templates (for example for iterate)
> - content outline
> - folding
> - hovers over text fragments (e.g. to display definitions)
> - hyperlinks
> - mark occurrences
> - context menu on the editor surface, for example Go to Declaration
> - content formatting
> - views, for example OCLASTView,
> http://www.eclipse.org/articles/article.php?file=Article-How ToProcessOCLAbstractSyntaxTrees/index.html
> - EMF Type Hierarchy view, as in
> http://www.sts.tu-harburg.de/%7Emi.garcia/SoC2007/Improvemen tsToTheEmfaticEditor.pdf

Thanks for the suggestions. Some of these are on my to do list, but my top priority goal
is to leverage the GMF Ecore editor to provide graphical pages for the KM3 and QVTr editors
so that text and graphics are interchangeable.

> So, what I'm saying is: getting leverage from the architecture used to
> deliver QVTr, QVTc, KM3, and so on editors can provide some of the
> functionality needed, however the fine-tuning still remains to be done, and
> it's that fine-tuning that the OCL user cares about as it has the biggest
> impact on productivity.

I'd be interested in hearing quite what the OCL editor requirement is. I get the
impression that IBM and MDT are not at all interested in the idea. The OCL editor
I produced was something of a side effect, I had most of the OCL support for QVTr,
and I had a flexible editor, and I wanted to run OCL-level JUnit tests of
pretty expression unparsing, so why not do OCL too - much better than nothing.

If anyone wants to help with your laundry list I'd be delighted in the assistance since
all those features are good for the other editors too.

Regards

Ed Willink

Report message to a moderator