Eclipse Community Forums: OCL » Other model backends

Help

Home

Home » Modeling » OCL » Other model backends

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

Other model backends [message #56413]

Thu, 22 May 2008 07:52

Eclipse User

Originally posted by: stepper.sympedia.de

Hi Christian,

Is it possible to use OCL with non-Ecore based models?

I ask this because Simon and I plan to develop a remote query mechanism
for CDO and a CDO repository usually doesn't know about Ecore.
Internally (over the network and in the server) CDO uses a different
concept of CDORevisions which capture a single state in the lifetime of
a client side EObject (instance level). At the model level CDO uses the
concept of a CDOClass which is contained in a CDOPackage and has
CDOFeatures. All these concepts are more or less mappeable to/from their
Ecore counter parts.

In addition it would be interesting to use OCL as a server side
validation facility. Incoming CommitTransactionRequests could be
validated remotely before being applied to a backend.

Cheers
/Eike

Report message to a moderator

Re: Other model backends [message #56468 is a reply to message #56413]

Thu, 22 May 2008 19:38

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-tTG6FmFvt15vInZdAul0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Eike,

Yes. Since the 1.1 release, MDT OCL supports the implementation of
"metamodel bindings." Out-of-the-box, the MDT OCL SDK provides bindings
for Ecore and UML.

You need to ensure that your metamodel implements the constructs
required by OCL in some fashion: these are the notions of Classifier,
Operation, Property, etc. Your metamodel must be Ecore-based (Ecore is
the meta-metamodel). If these requirements are satisfied, you basically
provide three things:

* an EnvironmentFactory implementation (with an Environment and
UMLReflection implementation) for your metamodel
* a specialization of the AST model (the Types and Expressions
packages) that supplies the generic type parameter substitutions
that map your metamodel's constructs to OCL's parameters and
mixes in the generalizations of your metamodel's Classifier and
TypedElement constructs
* an implementation of the OCL Standard Library as an instance of
your metamodel

The Ecore and UML bindings provided by the SDK serve as examples, and
the Advanced Topics in the developer guide has a word or two to say on
the subject. I have seen evidence at EclipseCon of additional metamodel
bindings, and I have prototyped the concept with SQL, myself.

Perhaps I can contribute in some way? One tool that is lacking from the
MDT OCL SDK is the metamodel-binding generator. It's a lot of work to
build one by hand, and it could benefit a lot from some automation.

HTH,

Christian

On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:

> Hi Christian,
>
> Is it possible to use OCL with non-Ecore based models?
>
> I ask this because Simon and I plan to develop a remote query mechanism
> for CDO and a CDO repository usually doesn't know about Ecore.
> Internally (over the network and in the server) CDO uses a different
> concept of CDORevisions which capture a single state in the lifetime of
> a client side EObject (instance level). At the model level CDO uses the
> concept of a CDOClass which is contained in a CDOPackage and has
> CDOFeatures. All these concepts are more or less mappeable to/from their
> Ecore counter parts.
>
> In addition it would be interesting to use OCL as a server side
> validation facility. Incoming CommitTransactionRequests could be
> validated remotely before being applied to a backend.
>
> Cheers
> /Eike
>

--=-tTG6FmFvt15vInZdAul0
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.1">
</HEAD>
<BODY>
Hi, Eike, 
 
Yes.  Since the 1.1 release, MDT OCL supports the implementation of "metamodel bindings."  Out-of-the-box, the MDT OCL SDK provides bindings for Ecore and UML. 
 
You need to ensure that your metamodel implements the constructs required by OCL in some fashion:  these are the notions of Classifier, Operation, Property, etc.  Your metamodel must be Ecore-based (Ecore is the meta-metamodel).  If these requirements are satisfied, you basically provide three things: 
 
<UL>
<LI>an EnvironmentFactory implementation (with an Environment and UMLReflection implementation) for your metamodel
<LI>a specialization of the AST model (the Types and Expressions packages) that supplies the generic type parameter substitutions that map your metamodel's constructs to OCL's parameters and mixes in the generalizations of your metamodel's Classifier and TypedElement constructs
<LI>an implementation of the OCL Standard Library as an instance of your metamodel
</UL>
 
The Ecore and UML bindings provided by the SDK serve as examples, and the Advanced Topics in the developer guide has a word or two to say on the subject.  I have seen evidence at EclipseCon of additional metamodel bindings, and I have prototyped the concept with SQL, myself. 
 
Perhaps I can contribute in some way?  One tool that is lacking from the MDT OCL SDK is the metamodel-binding generator.  It's a lot of work to build one by hand, and it could benefit a lot from some automation. 
 
HTH, 
 
Christian 
 
On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,

Is it possible to use OCL with non-Ecore based models?

I ask this because Simon and I plan to develop a remote query mechanism 
for CDO and a CDO repository usually doesn't know about Ecore. 
Internally (over the network and in the server) CDO uses a different 
concept of CDORevisions which capture a single state in the lifetime of 
a client side EObject (instance level). At the model level CDO uses the 
concept of a CDOClass which is contained in a CDOPackage and has 
CDOFeatures. All these concepts are more or less mappeable to/from their 
Ecore counter parts.

In addition it would be interesting to use OCL as a server side 
validation facility. Incoming CommitTransactionRequests could be 
validated remotely before being applied to a backend.

Cheers
/Eike

</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-tTG6FmFvt15vInZdAul0--

Report message to a moderator

Re: Other model backends [message #56521 is a reply to message #56468]

Fri, 23 May 2008 06:08

Eclipse User

Originally posted by: stepper.sympedia.de

Hi Christian,

Thanks for the info. It sounds promising on one hand and on the other
I'm a bit worried about your statement concerning the meta-meta-model
requirement (Ecore). Since we have no explicit models at all I'd like to
explain it in Java terms:

From an API perspective in a CDO client we have real EObjects in
memory. In fact they're typed CDOObject which extends EObject:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p

From an implementation point of view the main difference between
EObjectImpl and CDOObjectImpl is that the latter does not store the
modeled state in Java instance fields but instead somewhere in the
associated CDORevision:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup

Reflectively accessible via CDORevisionData:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup

These CDORevisions are transferred over the network and stored somehow
in the CDO server. Notice that there is no dependenciy from CDORevision
on Ecore at all! A CDORevision is associated with a CDOClass which also
relates to an EClass but only in a sematical sense. There's no
dependency from CDOClass on Ecore. In general, everything in CDO that
passes the network is implemented in the cdo.protocol plugin which has,
again, no dependency on EMF/Ecore.

This is the situation: At the CDO server side we have no EMF, thus no
Ecore. But we have instances that support reflective access via a
dynamic model that semantically relates to an Ecore model. Btw. a
CDOClass looks like:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup

Sorry for the lengthy monologue ;-)

What makes me a bit more hopeful is your statement about SQL below
which, in itself, is not Ecore derived. Or do you mean something like an
SQL.ecore?

Anyway, I suspect that you get an impression of the situation in a CDO
server. Do you think it's worth discussing whether/how your OCL
interpreter is able to validate CDORevision instances?

And yes, if it'd be possible somehow, your contribution would be
welcome! ;-)

Cheers
/Eike

p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day
in advance...

Christian W. Damus schrieb:
> Hi, Eike,
>
> Yes. Since the 1.1 release, MDT OCL supports the implementation of
> "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides
> bindings for Ecore and UML.
>
> You need to ensure that your metamodel implements the constructs
> required by OCL in some fashion: these are the notions of Classifier,
> Operation, Property, etc. Your metamodel must be Ecore-based (Ecore
> is the meta-metamodel). If these requirements are satisfied, you
> basically provide three things:
>
> * an EnvironmentFactory implementation (with an Environment and
> UMLReflection implementation) for your metamodel
> * a specialization of the AST model (the Types and Expressions
> packages) that supplies the generic type parameter substitutions
> that map your metamodel's constructs to OCL's parameters and
> mixes in the generalizations of your metamodel's Classifier and
> TypedElement constructs
> * an implementation of the OCL Standard Library as an instance of
> your metamodel
>
>
> The Ecore and UML bindings provided by the SDK serve as examples, and
> the Advanced Topics in the developer guide has a word or two to say on
> the subject. I have seen evidence at EclipseCon of additional
> metamodel bindings, and I have prototyped the concept with SQL, myself.
>
> Perhaps I can contribute in some way? One tool that is lacking from
> the MDT OCL SDK is the metamodel-binding generator. It's a lot of
> work to build one by hand, and it could benefit a lot from some
> automation.
>
> HTH,
>
> Christian
>
> On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
>> Hi Christian,
>>
>> Is it possible to use OCL with non-Ecore based models?
>>
>> I ask this because Simon and I plan to develop a remote query mechanism
>> for CDO and a CDO repository usually doesn't know about Ecore.
>> Internally (over the network and in the server) CDO uses a different
>> concept of CDORevisions which capture a single state in the lifetime of
>> a client side EObject (instance level). At the model level CDO uses the
>> concept of a CDOClass which is contained in a CDOPackage and has
>> CDOFeatures. All these concepts are more or less mappeable to/from their
>> Ecore counter parts.
>>
>> In addition it would be interesting to use OCL as a server side
>> validation facility. Incoming CommitTransactionRequests could be
>> validated remotely before being applied to a backend.
>>
>> Cheers
>> /Eike
>>
>>

Report message to a moderator

Re: Other model backends [message #56924 is a reply to message #56521]

Wed, 28 May 2008 01:49

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-2LAU8m9wLgxbdo5uatFO
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Eike,

Sorry for the delayed response. See some replies in-line.

cW

On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:

> Hi Christian,
>
> Thanks for the info. It sounds promising on one hand and on the other
> I'm a bit worried about your statement concerning the meta-meta-model
> requirement (Ecore). Since we have no explicit models at all I'd like to
> explain it in Java terms:

Well, the OCL Abstract Syntax Model needs to be able to reference model
elements, and to persist those references via the usual EMF mechanisms.
That implied a requirement that the target metamodel be EMF-based.

> From an API perspective in a CDO client we have real EObjects in
> memory. In fact they're typed CDOObject which extends EObject:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p
>
> From an implementation point of view the main difference between
> EObjectImpl and CDOObjectImpl is that the latter does not store the
> modeled state in Java instance fields but instead somewhere in the
> associated CDORevision:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup
>
> Reflectively accessible via CDORevisionData:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup
>
> These CDORevisions are transferred over the network and stored somehow
> in the CDO server. Notice that there is no dependenciy from CDORevision
> on Ecore at all! A CDORevision is associated with a CDOClass which also
> relates to an EClass but only in a sematical sense. There's no
> dependency from CDOClass on Ecore. In general, everything in CDO that
> passes the network is implemented in the cdo.protocol plugin which has,
> again, no dependency on EMF/Ecore.

If you have CDOClasses paired with EClasses, then perhaps for OCL
purposes you could implement this mapping on-the-fly? The Environment
and EvaluationEnvironment APIs should be sufficiently abstract to allow
you to delegate the EMF-based access to the CDOClasses and
CDORevisions ... at least, if you can't, then perhaps this API needs
enhancement.

> This is the situation: At the CDO server side we have no EMF, thus no
> Ecore. But we have instances that support reflective access via a
> dynamic model that semantically relates to an Ecore model. Btw. a
> CDOClass looks like:
> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup
>
> Sorry for the lengthy monologue ;-)
>
> What makes me a bit more hopeful is your statement about SQL below
> which, in itself, is not Ecore derived. Or do you mean something like an
> SQL.ecore?

That's what I meant. In fact, the SQL metamodel from DTP.

> Anyway, I suspect that you get an impression of the situation in a CDO
> server. Do you think it's worth discussing whether/how your OCL
> interpreter is able to validate CDORevision instances?

Yes, it would make a good case study for the generality of the
metamodel-binding mechanism.

> And yes, if it'd be possible somehow, your contribution would be
> welcome! ;-)

Heh heh ... that's the trick, isn't it? Finding the opportunity to do
yet more work! :-P

>
> Cheers
> /Eike
>
> p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day
> in advance...
>
>
> Christian W. Damus schrieb:
> > Hi, Eike,
> >
> > Yes. Since the 1.1 release, MDT OCL supports the implementation of
> > "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides
> > bindings for Ecore and UML.
> >
> > You need to ensure that your metamodel implements the constructs
> > required by OCL in some fashion: these are the notions of Classifier,
> > Operation, Property, etc. Your metamodel must be Ecore-based (Ecore
> > is the meta-metamodel). If these requirements are satisfied, you
> > basically provide three things:
> >
> > * an EnvironmentFactory implementation (with an Environment and
> > UMLReflection implementation) for your metamodel
> > * a specialization of the AST model (the Types and Expressions
> > packages) that supplies the generic type parameter substitutions
> > that map your metamodel's constructs to OCL's parameters and
> > mixes in the generalizations of your metamodel's Classifier and
> > TypedElement constructs
> > * an implementation of the OCL Standard Library as an instance of
> > your metamodel
> >
> >
> > The Ecore and UML bindings provided by the SDK serve as examples, and
> > the Advanced Topics in the developer guide has a word or two to say on
> > the subject. I have seen evidence at EclipseCon of additional
> > metamodel bindings, and I have prototyped the concept with SQL, myself.
> >
> > Perhaps I can contribute in some way? One tool that is lacking from
> > the MDT OCL SDK is the metamodel-binding generator. It's a lot of
> > work to build one by hand, and it could benefit a lot from some
> > automation.
> >
> > HTH,
> >
> > Christian
> >
> > On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
> >> Hi Christian,
> >>
> >> Is it possible to use OCL with non-Ecore based models?
> >>
> >> I ask this because Simon and I plan to develop a remote query mechanism
> >> for CDO and a CDO repository usually doesn't know about Ecore.
> >> Internally (over the network and in the server) CDO uses a different
> >> concept of CDORevisions which capture a single state in the lifetime of
> >> a client side EObject (instance level). At the model level CDO uses the
> >> concept of a CDOClass which is contained in a CDOPackage and has
> >> CDOFeatures. All these concepts are more or less mappeable to/from their
> >> Ecore counter parts.
> >>
> >> In addition it would be interesting to use OCL as a server side
> >> validation facility. Incoming CommitTransactionRequests could be
> >> validated remotely before being applied to a backend.
> >>
> >> Cheers
> >> /Eike
> >>
> >>

--=-2LAU8m9wLgxbdo5uatFO
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Eike, 
 
Sorry for the delayed response.  See some replies in-line. 
 
cW 
 
 
On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,

Thanks for the info. It sounds promising on one hand and on the other 
I'm a bit worried about your statement concerning the meta-meta-model 
requirement (Ecore). Since we have no explicit models at all I'd like to 
explain it in Java terms:
</PRE>
</BLOCKQUOTE>
 
Well, the OCL Abstract Syntax Model needs to be able to reference model elements, and to persist those references via the usual EMF mechanisms.  That implied a requirement that the target metamodel be EMF-based. 
 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>
 From an API perspective in a CDO client we have real EObjects in 
memory. In fact they're typed CDOObject which extends EObject: 
<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=markup</A>

 From an implementation point of view the main difference between 
EObjectImpl and CDOObjectImpl is that the latter does not store the 
modeled state in Java instance fields but instead somewhere in the 
associated CDORevision: 
<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup</A>

Reflectively accessible via CDORevisionData: 
<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup</A>

These CDORevisions are transferred over the network and stored somehow 
in the CDO server. Notice that there is no dependenciy from CDORevision 
on Ecore at all! A CDORevision is associated with a CDOClass which also 
relates to an EClass but only in a sematical sense. There's no 
dependency from CDOClass on Ecore. In general, everything in CDO that 
passes the network is implemented in the cdo.protocol plugin which has, 
again, no dependency on EMF/Ecore.
</PRE>
</BLOCKQUOTE>
If you have CDOClasses paired with EClasses, then perhaps for OCL purposes you could implement this mapping on-the-fly?  The Environment and EvaluationEnvironment APIs should be sufficiently abstract to allow you to delegate the EMF-based access to the CDOClasses and CDORevisions ... at least, if you can't, then perhaps this API needs enhancement. 
 
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
This is the situation: At the CDO server side we have no EMF, thus no 
Ecore. But we have instances that support reflective access via a 
dynamic model that semantically relates to an Ecore model. Btw. a 
CDOClass looks like: 
<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup</A>

Sorry for the lengthy monologue ;-)

What makes me a bit more hopeful is your statement about SQL below 
which, in itself, is not Ecore derived. Or do you mean something like an 
SQL.ecore?
</PRE>
</BLOCKQUOTE>
<PRE>

</PRE>
That's what I meant.  In fact, the SQL metamodel from DTP. 
 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>
Anyway, I suspect that you get an impression of the situation in a CDO 
server. Do you think it's worth discussing whether/how your OCL 
interpreter is able to validate CDORevision instances?
</PRE>
</BLOCKQUOTE>
 
Yes, it would make a good case study for the generality of the metamodel-binding mechanism.
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
And yes, if it'd be possible somehow, your contribution would be 
welcome! ;-)
</PRE>
</BLOCKQUOTE>
 
Heh heh ... that's the trick, isn't it?  Finding the opportunity to do yet more work!  :-P 
 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>

Cheers
/Eike

p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day 
in advance...

Christian W. Damus schrieb:
> Hi, Eike,
>
> Yes. Since the 1.1 release, MDT OCL supports the implementation of 
> "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides 
> bindings for Ecore and UML.
>
> You need to ensure that your metamodel implements the constructs 
> required by OCL in some fashion: these are the notions of Classifier, 
> Operation, Property, etc. Your metamodel must be Ecore-based (Ecore 
> is the meta-metamodel). If these requirements are satisfied, you 
> basically provide three things:
>
> * an EnvironmentFactory implementation (with an Environment and
> UMLReflection implementation) for your metamodel
> * a specialization of the AST model (the Types and Expressions
> packages) that supplies the generic type parameter substitutions
> that map your metamodel's constructs to OCL's parameters and
> mixes in the generalizations of your metamodel's Classifier and
> TypedElement constructs
> * an implementation of the OCL Standard Library as an instance of
> your metamodel
>
>
> The Ecore and UML bindings provided by the SDK serve as examples, and 
> the Advanced Topics in the developer guide has a word or two to say on 
> the subject. I have seen evidence at EclipseCon of additional 
> metamodel bindings, and I have prototyped the concept with SQL, myself.
>
> Perhaps I can contribute in some way? One tool that is lacking from 
> the MDT OCL SDK is the metamodel-binding generator. It's a lot of 
> work to build one by hand, and it could benefit a lot from some 
> automation.
>
> HTH,
>
> Christian
>
> On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
>> Hi Christian,
>>
>> Is it possible to use OCL with non-Ecore based models?
>>
>> I ask this because Simon and I plan to develop a remote query mechanism 
>> for CDO and a CDO repository usually doesn't know about Ecore. 
>> Internally (over the network and in the server) CDO uses a different 
>> concept of CDORevisions which capture a single state in the lifetime of 
>> a client side EObject (instance level). At the model level CDO uses the 
>> concept of a CDOClass which is contained in a CDOPackage and has 
>> CDOFeatures. All these concepts are more or less mappeable to/from their 
>> Ecore counter parts.
>>
>> In addition it would be interesting to use OCL as a server side 
>> validation facility. Incoming CommitTransactionRequests could be 
>> validated remotely before being applied to a backend.
>>
>> Cheers
>> /Eike
>>
>> 
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-2LAU8m9wLgxbdo5uatFO--

Report message to a moderator

Re: Other model backends [message #56950 is a reply to message #56924]

Wed, 28 May 2008 06:41

Eclipse User

Originally posted by: stepper.sympedia.de

Hi Christian,

I hoped that your OCL interpreter has a similar model interface like the
Dresden OCL Toolkit: http://dresden-ocl.sourceforge.net
It's long ago that I played with it, but they have sort of an abstract
model facade that is independent on concreate model implementations
(like EMF). For several such implementations they have bridges (EMF,
MDR). With such a design it would be comparingly easy to develop a new
model bridge.

Btw. this sounds interesting, too:
http://dresden-ocl.sourceforge.net/gbbraeuer/index.html

I cc'ed Simon because he'll do the main work to integrate the CDO server
with OCL.
And yes, my participation offer is a bit plump -- but you asked ;-)

Btw2. I still plan to work with you on the incremental validation stuff
that we talked about last Con.
Or is your ability to spend unpaid effort more limited with your new job?

Cheers
/Eike

Christian W. Damus schrieb:
> Hi, Eike,
>
> Sorry for the delayed response. See some replies in-line.
>
> cW
>
>
> On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:
>> Hi Christian,
>>
>> Thanks for the info. It sounds promising on one hand and on the other
>> I'm a bit worried about your statement concerning the meta-meta-model
>> requirement (Ecore). Since we have no explicit models at all I'd like to
>> explain it in Java terms:
>>
>
> Well, the OCL Abstract Syntax Model needs to be able to reference
> model elements, and to persist those references via the usual EMF
> mechanisms. That implied a requirement that the target metamodel be
> EMF-based.
>
>
>> From an API perspective in a CDO client we have real EObjects in
>> memory. In fact they're typed CDOObject which extends EObject:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p>
>>
>> From an implementation point of view the main difference between
>> EObjectImpl and CDOObjectImpl is that the latter does not store the
>> modeled state in Java instance fields but instead somewhere in the
>> associated CDORevision:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup>
>>
>> Reflectively accessible via CDORevisionData:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup>
>>
>> These CDORevisions are transferred over the network and stored somehow
>> in the CDO server. Notice that there is no dependenciy from CDORevision
>> on Ecore at all! A CDORevision is associated with a CDOClass which also
>> relates to an EClass but only in a sematical sense. There's no
>> dependency from CDOClass on Ecore. In general, everything in CDO that
>> passes the network is implemented in the cdo.protocol plugin which has,
>> again, no dependency on EMF/Ecore.
>>
> If you have CDOClasses paired with EClasses, then perhaps for OCL
> purposes you could implement this mapping on-the-fly? The Environment
> and EvaluationEnvironment APIs should be sufficiently abstract to
> allow you to delegate the EMF-based access to the CDOClasses and
> CDORevisions ... at least, if you can't, then perhaps this API needs
> enhancement.
>
>
>> This is the situation: At the CDO server side we have no EMF, thus no
>> Ecore. But we have instances that support reflective access via a
>> dynamic model that semantically relates to an Ecore model. Btw. a
>> CDOClass looks like:
>> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup>
>>
>> Sorry for the lengthy monologue ;-)
>>
>> What makes me a bit more hopeful is your statement about SQL below
>> which, in itself, is not Ecore derived. Or do you mean something like an
>> SQL.ecore?
>>
>
> That's what I meant. In fact, the SQL metamodel from DTP.
>
>
>> Anyway, I suspect that you get an impression of the situation in a CDO
>> server. Do you think it's worth discussing whether/how your OCL
>> interpreter is able to validate CDORevision instances?
>>
>
> Yes, it would make a good case study for the generality of the
> metamodel-binding mechanism.
>
>> And yes, if it'd be possible somehow, your contribution would be
>> welcome! ;-)
>>
>
> Heh heh ... that's the trick, isn't it? Finding the opportunity to do
> yet more work! :-P
>
>
>> Cheers
>> /Eike
>>
>> p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day
>> in advance...
>>
>>
>> Christian W. Damus schrieb:
>> > Hi, Eike,
>> >
>> > Yes. Since the 1.1 release, MDT OCL supports the implementation of
>> > "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides
>> > bindings for Ecore and UML.
>> >
>> > You need to ensure that your metamodel implements the constructs
>> > required by OCL in some fashion: these are the notions of Classifier,
>> > Operation, Property, etc. Your metamodel must be Ecore-based (Ecore
>> > is the meta-metamodel). If these requirements are satisfied, you
>> > basically provide three things:
>> >
>> > * an EnvironmentFactory implementation (with an Environment and
>> > UMLReflection implementation) for your metamodel
>> > * a specialization of the AST model (the Types and Expressions
>> > packages) that supplies the generic type parameter substitutions
>> > that map your metamodel's constructs to OCL's parameters and
>> > mixes in the generalizations of your metamodel's Classifier and
>> > TypedElement constructs
>> > * an implementation of the OCL Standard Library as an instance of
>> > your metamodel
>> >
>> >
>> > The Ecore and UML bindings provided by the SDK serve as examples, and
>> > the Advanced Topics in the developer guide has a word or two to say on
>> > the subject. I have seen evidence at EclipseCon of additional
>> > metamodel bindings, and I have prototyped the concept with SQL, myself.
>> >
>> > Perhaps I can contribute in some way? One tool that is lacking from
>> > the MDT OCL SDK is the metamodel-binding generator. It's a lot of
>> > work to build one by hand, and it could benefit a lot from some
>> > automation.
>> >
>> > HTH,
>> >
>> > Christian
>> >
>> > On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
>> >> Hi Christian,
>> >>
>> >> Is it possible to use OCL with non-Ecore based models?
>> >>
>> >> I ask this because Simon and I plan to develop a remote query mechanism
>> >> for CDO and a CDO repository usually doesn't know about Ecore.
>> >> Internally (over the network and in the server) CDO uses a different
>> >> concept of CDORevisions which capture a single state in the lifetime of
>> >> a client side EObject (instance level). At the model level CDO uses the
>> >> concept of a CDOClass which is contained in a CDOPackage and has
>> >> CDOFeatures. All these concepts are more or less mappeable to/from their
>> >> Ecore counter parts.
>> >>
>> >> In addition it would be interesting to use OCL as a server side
>> >> validation facility. Incoming CommitTransactionRequests could be
>> >> validated remotely before being applied to a backend.
>> >>
>> >> Cheers
>> >> /Eike
>> >>
>> >>
>>

Report message to a moderator

Re: Other model backends [message #57349 is a reply to message #56950]

Fri, 30 May 2008 03:31

Eclipse User

Originally posted by: cdamus.zeligsoft.com

--=-S03OkZHhym7xySay1BH2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi, Eike,

See some replies, in-line.

cW

On Wed, 2008-05-28 at 08:41 +0200, Eike Stepper wrote:

> Hi Christian,
>
> I hoped that your OCL interpreter has a similar model interface like the
> Dresden OCL Toolkit: http://dresden-ocl.sourceforge.net

Yeah. That never was a design priority for the OCL component, since way
back in the days when it live in IBM RSA (before it was contributed to
Eclipse). It was always intended to be EMF-based, and there didn't seem
much reason to change that in the Eclipse Modeling Project.

If there really is sufficient interest in opening up the design beyond
EMF, then of course we might entertain the idea.

> It's long ago that I played with it, but they have sort of an abstract
> model facade that is independent on concreate model implementations
> (like EMF). For several such implementations they have bridges (EMF,
> MDR). With such a design it would be comparingly easy to develop a new
> model bridge.

Yes, that is a common pattern in OCL implementations.

> Btw. this sounds interesting, too:
> http://dresden-ocl.sourceforge.net/gbbraeuer/index.html
>
> I cc'ed Simon because he'll do the main work to integrate the CDO server
> with OCL.
> And yes, my participation offer is a bit plump -- but you asked ;-)

Plump? Perhaps you are translating a German idiom too
literally ... :-)

> Btw2. I still plan to work with you on the incremental validation stuff
> that we talked about last Con.
> Or is your ability to spend unpaid effort more limited with your new job?

I'm still interested in this, of course, because I think there is
potential for some valuable new work in the OCL component. Any time
that I spend on it will mostly be my own, but it will be fun. And I'll
be very happy to see you and Simon join the OCL contributor community,
which I hope to do a better job of fostering in the next release. We
should starting hatching plan items in this area for the 1.3 release
after Ganymede.

>
> Cheers
> /Eike
>
>
>
> Christian W. Damus schrieb:
> > Hi, Eike,
> >
> > Sorry for the delayed response. See some replies in-line.
> >
> > cW
> >
> >
> > On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:
> >> Hi Christian,
> >>
> >> Thanks for the info. It sounds promising on one hand and on the other
> >> I'm a bit worried about your statement concerning the meta-meta-model
> >> requirement (Ecore). Since we have no explicit models at all I'd like to
> >> explain it in Java terms:
> >>
> >
> > Well, the OCL Abstract Syntax Model needs to be able to reference
> > model elements, and to persist those references via the usual EMF
> > mechanisms. That implied a requirement that the target metamodel be
> > EMF-based.
> >
> >
> >> From an API perspective in a CDO client we have real EObjects in
> >> memory. In fact they're typed CDOObject which extends EObject:
> >> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p>
> >>
> >> From an implementation point of view the main difference between
> >> EObjectImpl and CDOObjectImpl is that the latter does not store the
> >> modeled state in Java instance fields but instead somewhere in the
> >> associated CDORevision:
> >> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup>
> >>
> >> Reflectively accessible via CDORevisionData:
> >> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup>
> >>
> >> These CDORevisions are transferred over the network and stored somehow
> >> in the CDO server. Notice that there is no dependenciy from CDORevision
> >> on Ecore at all! A CDORevision is associated with a CDOClass which also
> >> relates to an EClass but only in a sematical sense. There's no
> >> dependency from CDOClass on Ecore. In general, everything in CDO that
> >> passes the network is implemented in the cdo.protocol plugin which has,
> >> again, no dependency on EMF/Ecore.
> >>
> > If you have CDOClasses paired with EClasses, then perhaps for OCL
> > purposes you could implement this mapping on-the-fly? The Environment
> > and EvaluationEnvironment APIs should be sufficiently abstract to
> > allow you to delegate the EMF-based access to the CDOClasses and
> > CDORevisions ... at least, if you can't, then perhaps this API needs
> > enhancement.
> >
> >
> >> This is the situation: At the CDO server side we have no EMF, thus no
> >> Ecore. But we have instances that support reflective access via a
> >> dynamic model that semantically relates to an Ecore model. Btw. a
> >> CDOClass looks like:
> >> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup < http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup>
> >>
> >> Sorry for the lengthy monologue ;-)
> >>
> >> What makes me a bit more hopeful is your statement about SQL below
> >> which, in itself, is not Ecore derived. Or do you mean something like an
> >> SQL.ecore?
> >>
> >
> > That's what I meant. In fact, the SQL metamodel from DTP.
> >
> >
> >> Anyway, I suspect that you get an impression of the situation in a CDO
> >> server. Do you think it's worth discussing whether/how your OCL
> >> interpreter is able to validate CDORevision instances?
> >>
> >
> > Yes, it would make a good case study for the generality of the
> > metamodel-binding mechanism.
> >
> >> And yes, if it'd be possible somehow, your contribution would be
> >> welcome! ;-)
> >>
> >
> > Heh heh ... that's the trick, isn't it? Finding the opportunity to do
> > yet more work! :-P
> >
> >
> >> Cheers
> >> /Eike
> >>
> >> p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day
> >> in advance...
> >>
> >>
> >> Christian W. Damus schrieb:
> >> > Hi, Eike,
> >> >
> >> > Yes. Since the 1.1 release, MDT OCL supports the implementation of
> >> > "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides
> >> > bindings for Ecore and UML.
> >> >
> >> > You need to ensure that your metamodel implements the constructs
> >> > required by OCL in some fashion: these are the notions of Classifier,
> >> > Operation, Property, etc. Your metamodel must be Ecore-based (Ecore
> >> > is the meta-metamodel). If these requirements are satisfied, you
> >> > basically provide three things:
> >> >
> >> > * an EnvironmentFactory implementation (with an Environment and
> >> > UMLReflection implementation) for your metamodel
> >> > * a specialization of the AST model (the Types and Expressions
> >> > packages) that supplies the generic type parameter substitutions
> >> > that map your metamodel's constructs to OCL's parameters and
> >> > mixes in the generalizations of your metamodel's Classifier and
> >> > TypedElement constructs
> >> > * an implementation of the OCL Standard Library as an instance of
> >> > your metamodel
> >> >
> >> >
> >> > The Ecore and UML bindings provided by the SDK serve as examples, and
> >> > the Advanced Topics in the developer guide has a word or two to say on
> >> > the subject. I have seen evidence at EclipseCon of additional
> >> > metamodel bindings, and I have prototyped the concept with SQL, myself.
> >> >
> >> > Perhaps I can contribute in some way? One tool that is lacking from
> >> > the MDT OCL SDK is the metamodel-binding generator. It's a lot of
> >> > work to build one by hand, and it could benefit a lot from some
> >> > automation.
> >> >
> >> > HTH,
> >> >
> >> > Christian
> >> >
> >> > On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
> >> >> Hi Christian,
> >> >>
> >> >> Is it possible to use OCL with non-Ecore based models?
> >> >>
> >> >> I ask this because Simon and I plan to develop a remote query mechanism
> >> >> for CDO and a CDO repository usually doesn't know about Ecore.
> >> >> Internally (over the network and in the server) CDO uses a different
> >> >> concept of CDORevisions which capture a single state in the lifetime of
> >> >> a client side EObject (instance level). At the model level CDO uses the
> >> >> concept of a CDOClass which is contained in a CDOPackage and has
> >> >> CDOFeatures. All these concepts are more or less mappeable to/from their
> >> >> Ecore counter parts.
> >> >>
> >> >> In addition it would be interesting to use OCL as a server side
> >> >> validation facility. Incoming CommitTransactionRequests could be
> >> >> validated remotely before being applied to a backend.
> >> >>
> >> >> Cheers
> >> >> /Eike
> >> >>
> >> >>
> >>

--=-S03OkZHhym7xySay1BH2
Content-Type: text/html; charset=utf-8

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.16.0">
</HEAD>
<BODY>
Hi, Eike, 
 
See some replies, in-line. 
 
cW 
 
 
On Wed, 2008-05-28 at 08:41 +0200, Eike Stepper wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Hi Christian,

I hoped that your OCL interpreter has a similar model interface like the 
Dresden OCL Toolkit: <A HREF="http://dresden-ocl.sourceforge.net">http://dresden-ocl.sourceforge.net</A>
</PRE>
</BLOCKQUOTE>
 
Yeah.  That never was a design priority for the OCL component, since way back in the days when it live in IBM RSA (before it was contributed to Eclipse).  It was always intended to be EMF-based, and there didn't seem much reason to change that in the Eclipse Modeling Project. 
 
If there really is sufficient interest in opening up the design beyond EMF, then of course we might entertain the idea. 
 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>
It's long ago that I played with it, but they have sort of an abstract 
model facade that is independent on concreate model implementations 
(like EMF). For several such implementations they have bridges (EMF, 
MDR). With such a design it would be comparingly easy to develop a new 
model bridge.
</PRE>
</BLOCKQUOTE>
 
Yes, that is a common pattern in OCL implementations.
<PRE>

</PRE>
 
<BLOCKQUOTE TYPE=CITE>
<PRE>
Btw. this sounds interesting, too: 
<A HREF="http://dresden-ocl.sourceforge.net/gbbraeuer/index.html">http://dresden-ocl.sourceforge.net/gbbraeuer/index.html</A>

I cc'ed Simon because he'll do the main work to integrate the CDO server 
with OCL.
And yes, my participation offer is a bit plump -- but you asked ;-)
</PRE>
</BLOCKQUOTE>
 
Plump?  Perhaps you are translating a German idiom too literally ...  :-) 
 
<PRE>

</PRE>
<BLOCKQUOTE TYPE=CITE>
<PRE>
Btw2. I still plan to work with you on the incremental validation stuff 
that we talked about last Con.
Or is your ability to spend unpaid effort more limited with your new job?
</PRE>
</BLOCKQUOTE>
 
I'm still interested in this, of course, because I think there is potential for some valuable new work in the OCL component.  Any time that I spend on it will mostly be my own, but it will be fun.  And I'll be very happy to see you and Simon join the OCL contributor community, which I hope to do a better job of fostering in the next release.  We should starting hatching plan items in this area for the 1.3 release after Ganymede. 
 
<BLOCKQUOTE TYPE=CITE>
<PRE>

Cheers
/Eike

Christian W. Damus schrieb:
> Hi, Eike,
>
> Sorry for the delayed response. See some replies in-line.
>
> cW
>
>
> On Fri, 2008-05-23 at 08:08 +0200, Eike Stepper wrote:
>> Hi Christian,
>>
>> Thanks for the info. It sounds promising on one hand and on the other 
>> I'm a bit worried about your statement concerning the meta-meta-model 
>> requirement (Ecore). Since we have no explicit models at all I'd like to 
>> explain it in Java terms:
>> 
>
> Well, the OCL Abstract Syntax Model needs to be able to reference 
> model elements, and to persist those references via the usual EMF 
> mechanisms. That implied a requirement that the target metamodel be 
> EMF-based.
>
>
>> From an API perspective in a CDO client we have real EObjects in 
>> memory. In fact they're typed CDOObject which extends EObject: 
>> <A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=markup</A> <<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=marku p"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/cdo/CDOObject.java?root=Modeling_Project&view=markup</A>>
>>
>> From an implementation point of view the main difference between 
>> EObjectImpl and CDOObjectImpl is that the latter does not store the 
>> modeled state in Java instance fields but instead somewhere in the 
>> associated CDORevision: 
>> <A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup</A> <<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevision.java?root=Mo deling_Project&view=markup</A>>
>>
>> Reflectively accessible via CDORevisionData: 
>> <A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup</A> <<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/revision/CDORevisionData.java?roo t=Modeling_Project&view=markup</A>>
>>
>> These CDORevisions are transferred over the network and stored somehow 
>> in the CDO server. Notice that there is no dependenciy from CDORevision 
>> on Ecore at all! A CDORevision is associated with a CDOClass which also 
>> relates to an EClass but only in a sematical sense. There's no 
>> dependency from CDOClass on Ecore. In general, everything in CDO that 
>> passes the network is implemented in the cdo.protocol plugin which has, 
>> again, no dependency on EMF/Ecore.
>> 
> If you have CDOClasses paired with EClasses, then perhaps for OCL 
> purposes you could implement this mapping on-the-fly? The Environment 
> and EvaluationEnvironment APIs should be sufficiently abstract to 
> allow you to delegate the EMF-based access to the CDOClasses and 
> CDORevisions ... at least, if you can't, then perhaps this API needs 
> enhancement.
>
> 
>> This is the situation: At the CDO server side we have no EMF, thus no 
>> Ecore. But we have instances that support reflective access via a 
>> dynamic model that semantically relates to an Ecore model. Btw. a 
>> CDOClass looks like: 
>> <A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup</A> <<A HREF=" http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup"> http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo.protocol/src/or g/eclipse/emf/cdo/protocol/model/CDOClass.java?root=Modeling _Project&view=markup</A>>
>>
>> Sorry for the lengthy monologue ;-)
>>
>> What makes me a bit more hopeful is your statement about SQL below 
>> which, in itself, is not Ecore derived. Or do you mean something like an 
>> SQL.ecore?
>> 
> 
> That's what I meant. In fact, the SQL metamodel from DTP.
>
>
>> Anyway, I suspect that you get an impression of the situation in a CDO 
>> server. Do you think it's worth discussing whether/how your OCL 
>> interpreter is able to validate CDORevision instances?
>> 
>
> Yes, it would make a good case study for the generality of the 
> metamodel-binding mechanism.
> 
>> And yes, if it'd be possible somehow, your contribution would be 
>> welcome! ;-)
>> 
>
> Heh heh ... that's the trick, isn't it? Finding the opportunity to do 
> yet more work! :-P
>
>
>> Cheers
>> /Eike
>>
>> p.s. Will you be coming to ESE? Ed mentioned a modeling symposium a day 
>> in advance...
>>
>>
>> Christian W. Damus schrieb:
>> > Hi, Eike,
>> >
>> > Yes. Since the 1.1 release, MDT OCL supports the implementation of 
>> > "metamodel bindings." Out-of-the-box, the MDT OCL SDK provides 
>> > bindings for Ecore and UML.
>> >
>> > You need to ensure that your metamodel implements the constructs 
>> > required by OCL in some fashion: these are the notions of Classifier, 
>> > Operation, Property, etc. Your metamodel must be Ecore-based (Ecore 
>> > is the meta-metamodel). If these requirements are satisfied, you 
>> > basically provide three things:
>> >
>> > * an EnvironmentFactory implementation (with an Environment and
>> > UMLReflection implementation) for your metamodel
>> > * a specialization of the AST model (the Types and Expressions
>> > packages) that supplies the generic type parameter substitutions
>> > that map your metamodel's constructs to OCL's parameters and
>> > mixes in the generalizations of your metamodel's Classifier and
>> > TypedElement constructs
>> > * an implementation of the OCL Standard Library as an instance of
>> > your metamodel
>> >
>> >
>> > The Ecore and UML bindings provided by the SDK serve as examples, and 
>> > the Advanced Topics in the developer guide has a word or two to say on 
>> > the subject. I have seen evidence at EclipseCon of additional 
>> > metamodel bindings, and I have prototyped the concept with SQL, myself.
>> >
>> > Perhaps I can contribute in some way? One tool that is lacking from 
>> > the MDT OCL SDK is the metamodel-binding generator. It's a lot of 
>> > work to build one by hand, and it could benefit a lot from some 
>> > automation.
>> >
>> > HTH,
>> >
>> > Christian
>> >
>> > On Thu, 2008-05-22 at 09:52 +0200, Eike Stepper wrote:
>> >> Hi Christian,
>> >>
>> >> Is it possible to use OCL with non-Ecore based models?
>> >>
>> >> I ask this because Simon and I plan to develop a remote query mechanism 
>> >> for CDO and a CDO repository usually doesn't know about Ecore. 
>> >> Internally (over the network and in the server) CDO uses a different 
>> >> concept of CDORevisions which capture a single state in the lifetime of 
>> >> a client side EObject (instance level). At the model level CDO uses the 
>> >> concept of a CDOClass which is contained in a CDOPackage and has 
>> >> CDOFeatures. All these concepts are more or less mappeable to/from their 
>> >> Ecore counter parts.
>> >>
>> >> In addition it would be interesting to use OCL as a server side 
>> >> validation facility. Incoming CommitTransactionRequests could be 
>> >> validated remotely before being applied to a backend.
>> >>
>> >> Cheers
>> >> /Eike
>> >>
>> >> 
>> 
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>

--=-S03OkZHhym7xySay1BH2--

Report message to a moderator

Previous Topic:	querying across multiple XMI resources
Next Topic:	Can OCL be used standalone?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Fri Apr 19 20:30:00 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter