Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » accessing dynamic eobject api + function libraries
accessing dynamic eobject api + function libraries [message #22906] Thu, 10 May 2007 13:27 Go to next message
Kagan Turgut is currently offline Kagan Turgut
Messages: 12
Registered: July 2009
Junior Member
i would like to be able to check whether an attribute is actually set or
not within an expression, and unset it if necessary within an ocl
expression.

how can i call the eobject dynamic methods such as eIsSet(x),
isUnsettable(x) unset(x) etc within an OCL expression?

thanks in advance,
kagan
Re: accessing dynamic eobject api + function libraries [message #22950 is a reply to message #22906] Thu, 10 May 2007 14:58 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Kagan,

In any case, you should never be able to call eUnset() because OCL is a
side-effect-free language. Its semantics do not allow the modification of
the model that it is constraining/querying.

Regarding eIsSet() and isUnsettable(): OCL provides no means to access the
metamodel of the model that it is constraining. That is, you can check
whether

self.oclIsKindOf(Xyz)

but you cannot do

self.oclType

to get the Xyz metaclass in order then to do

self.oclType.getEStructuralFeature("x")

I don't know whether this is an accidental or intentional omission from the
spec. I suspect that it is accidental because the UML 2.1 specification
actually uses such non-existent constructs as "self.oclType" in defining
its constraints.

Cheers,

Christian


Kagan Turgut wrote:

> i would like to be able to check whether an attribute is actually set or
> not within an expression, and unset it if necessary within an ocl
> expression.
>
> how can i call the eobject dynamic methods such as eIsSet(x),
> isUnsettable(x) unset(x) etc within an OCL expression?
>
> thanks in advance,
> kagan
Re: accessing dynamic eobject api + function libraries [message #23670 is a reply to message #22906] Wed, 16 May 2007 19:24 Go to previous messageGo to next message
Eclipse User
Originally posted by: carrasco.ModelDrivenDevelopment.co.uk

You may try implementing a property (added to your .ecore before
generation),
returning the instance of the ecore:EClass metaclass,
then you can reason over it with OCL.

You
Re: accessing dynamic eobject api + function libraries [message #23880 is a reply to message #23670] Thu, 17 May 2007 09:10 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Antonio,

You can take this one step further by not actually implementing the
modelClass property in your Ecore model (which might be seen as breaking
the model's semantic cohesion, especially as it crosses meta-levels), but
rather defining it in a custom Ecore environment as an OCL-defined
"additional attribute", for use by OCL constraints only.

See the newly-added Programmer's Guide topic in the M7 build, that discusses
how to extend the environment for this kind of situation, with a working
example. The example defines an additional operation, but the mechanism is
the same:

OCL Developer Guide
Programmer's Guide
Advanced Topics
Customizing the Environment

The example adds a regexMatch() operation to the String primitive type. It
is actually implemented in the
org.eclipse.ocl.ecore.tests.EcoreEnvironmentTest class, verbatim from the
guide.

Cheers,

Christian


Antonio Carrasco wrote:

> You may try implementing a property (added to your .ecore before
> generation),
> returning the instance of the ecore:EClass metaclass,
> then you can reason over it with OCL.
>
> Youll need to add the ecore metamodel Ecore.ecore
> as a resource to your own .ecore metamodel.
>
> For any side effects, you may just invoke any method of your own
> implementation.
>
> Thats breaking the rules, right.
> Thats why we put them there, first!
>
> <eClassifiers xsi:type="ecore:EClass" name="ConModelClass"
> abstract="true">
>
> <eStructuralFeatures xsi:type="ecore:EReference" name="modelClass"
> lowerBound="1" eType="ecore:EClass
> ../../../plugin/org.eclipse.emf.ecore/model/Ecore.ecore#//EC lass "
> changeable="false" volatile="true" transient="true" derived="true"/>
>
> </eClassifiers>
>
> From the OCL console:
> Evaluating:
>
> self.modelClass
>
> Results:
>
> EClass Proceso
>
>
> Evaluating:
>
> self.modelClass.eAllAttributes
>
> Results:
>
> EAttribute codigoYNombre
>
> EAttribute codigo
>
> EAttribute nombre
>
> EAttribute codigoCompleto

<snip>
Re: accessing dynamic eobject api + function libraries [message #23921 is a reply to message #23880] Thu, 17 May 2007 10:20 Go to previous messageGo to next message
Eclipse User
Originally posted by: carrasco.ModelDrivenDevelopment.co.uk

Wow!

What an amazing piece of technology you guys are putting together!
I believe most would agree that the actual power of the approach,
as you guys are implementing it withing the Eclipse ecosystem,
exceeds whatever where the most forward-looking expectatives
of the original OCL spec.

We
Re: accessing dynamic eobject api + function libraries [message #23959 is a reply to message #23921] Thu, 17 May 2007 10:44 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Antonio,

<blushing>Thanks for the vote of confidence!</blushing>

We're all very pleased that what we are providing is proving so valuable to
you.

Have you cast your vote for EMF?

http://www2.sys-con.com/java/readerschoice2004/frameliveupda te.cfm?BType=11

cW


Antonio Carrasco wrote:

> Wow!
>
> What an amazing piece of technology you guys are putting together!
> I believe most would agree that the actual power of the approach,
> as you guys are implementing it withing the Eclipse ecosystem,
> exceeds whatever where the most forward-looking expectatives
> of the original OCL spec.
>
> Were now in Inception work,
> and the focus is such, that Ive had no reason to allocate time to use your
> last versions -
> no need for the profits of detailed OCL specification.
>
> But I am really, really looking forward to it
> (about the 2nd or 3rd time I declare so).
> Cheers!
> ACV

<snip>
oclType, Re: accessing dynamic eobject api + function libraries [message #43504 is a reply to message #22950] Sun, 18 November 2007 06:28 Go to previous messageGo to next message
Philipp W. Kutter is currently offline Philipp W. Kutter
Messages: 301
Registered: July 2009
Senior Member
Hi, Christian.
Is oclType now accessible in the newest version of the ocl.ecore,
or do I need to add it by hand to the environment?

I came to the problem trying to access eContainer, an Issue I will
describe in a separate post.

Best, Philipp

Christian W. Damus wrote 10.05.2007:
> Hi, Kagan,
>
> In any case, you should never be able to call eUnset() because OCL is a
> side-effect-free language. Its semantics do not allow the modification of
> the model that it is constraining/querying.
>
> Regarding eIsSet() and isUnsettable(): OCL provides no means to access the
> metamodel of the model that it is constraining. That is, you can check
> whether
>
> self.oclIsKindOf(Xyz)
>
> but you cannot do
>
> self.oclType
>
> to get the Xyz metaclass in order then to do
>
> self.oclType.getEStructuralFeature("x")
>
> I don't know whether this is an accidental or intentional omission from the
> spec. I suspect that it is accidental because the UML 2.1 specification
> actually uses such non-existent constructs as "self.oclType" in defining
> its constraints.
>
> Cheers,
>
> Christian
>
>
> Kagan Turgut wrote:
>
>> i would like to be able to check whether an attribute is actually set or
>> not within an expression, and unset it if necessary within an ocl
>> expression.
>>
>> how can i call the eobject dynamic methods such as eIsSet(x),
>> isUnsettable(x) unset(x) etc within an OCL expression?
>>
>> thanks in advance,
>> kagan
>
Re: oclType, Re: accessing dynamic eobject api + function libraries [message #43598 is a reply to message #43504] Mon, 19 November 2007 08:13 Go to previous message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Philipp,

Nope, oclType isn't available yet, and probably won't be until the OMG
defines it.

Of course, one could consider, in the mean-time, sneaking it in via a new
ProblemOption (error by default) for those clients that don't mind
depending on non-standard constructs. The problem with that, though, is
that probably the OMG would end up defining something different, which
makes for an incompatible transition for these clients, anyway.

Cheers,

Christian


Philipp W. Kutter wrote:

> Hi, Christian.
> Is oclType now accessible in the newest version of the ocl.ecore,
> or do I need to add it by hand to the environment?
>
> I came to the problem trying to access eContainer, an Issue I will
> describe in a separate post.
>
> Best, Philipp
>

-----8<-----
Previous Topic:Query evaluate DynamicEObjectImpl problem.
Next Topic:Defining EOpposites on subclasses
Goto Forum:
  


Current Time: Thu Aug 28 11:34:57 EDT 2014

Powered by FUDForum. Page generated in 0.02400 seconds