Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » Evaluation of allInstances and self usage
Evaluation of allInstances and self usage [message #53626] Mon, 07 April 2008 10:20 Go to next message
Michael Soden is currently offline Michael Soden
Messages: 27
Registered: July 2009
Junior Member
This is a multi-part message in MIME format.
--------------010001010403040101090202
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Hi folks,

I came across some questions regarding the 'allInstances' implementation.

First of all I'm wondering why I have to specify a 'self' object for
evaluation of an 'allInstances' query. Suppose a query in the EcoreEval
env over a metamodel having class 'A' like:

[...]
OCLExpression oclExpr = helper.createQuery("A.allInstances()");
query.evaluate();

it will return 'null', since the implementation cannot figure out in
what extent (i.e. resources) my objects live. If I provide an apropriate
'self', everything works fine. However, what shall I do if a query uses
multiple different meta-classes? For example let's take the following
query (underlying metamodel has simply two classes, not inheriting each
other, both having an EString attribute 'name'):

A.allInstances()->select( a | B.allInstances()->exists( b | b.name =
a.name ) )

Shall I provide an 'A' instance or a 'B' for evaluation? What happens if
a query uses already 'self' bound to a different type (in my example
let's say 'B'):

AB::A.allInstances()->select(a : A | a.name.=(self.name))

Thanks in advance for bringing light into the dark,
Michael

PS: I attached my sample project if somebody wants to take a closer look

--------------010001010403040101090202
Content-Type: application/octet-stream;
name="AllInstances.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="AllInstances.zip"

UEsDBBQACAAIADGxejgAAAAAAAAAAAAAAAAXAAAAQWxsSW5zdGFuY2VzLy5j bGFzc3BhdGid
jz0LwjAURWcF/0PIbqqbQ2sRqaBDlVJnqcmjjcaXmA/Rf29Vii46uN17ORy4 cXo9KXIB66TG
hI7ZiBJAroXEOqHbcjGc0HQ66MdcVc6Zyjdt6b0boLc3cpQoEuosp+QxvmL0 neQaO1LbmgFX
0jhgRgDj2gKzcA7SgtioUEt0f6gOwjNVBeRNe4Stimw3X+flbJlnxS+bDt4E 3wn3Ep9wHH2+
vwNQSwcIynwRTaUAAAAzAQAAUEsDBBQACAAIADGxejgAAAAAAAAAAAAAAAAV AAAAQWxsSW5z
dGFuY2VzLy5wcm9qZWN0vZLBSgMxEIbPCr5D2buJ3jykW7RF8KAI1QeIk3FN SSYhyRYf3yTN
KkspeBBv8/8zf75hiFh9WrPYY4ja0bK7ZlfdAgmc0jQsu9eX+8ubbtVfnAsf 3A4hbTBC0D7l
6eyeCZIW+1tjHigmSYBR8GqVHjhrkVIv+FQVtz0Uq+Az9TZqo7Yeoagm1zkq SVWn4VwYGILR
PiLbqcTAhVzIvawBDD8r5IQMw1jYsWk+NwQ/ovyK6xWyR0n6HWO6+1/sFj7Q yj+BNmc6eeal
MWCbPojT1z70ywJ17lSmrPxsxkHT01Fgqgvx+y/Mv9gXUEsHCLbVFQbqAAAA oQIAAFBLAwQU
AAgACAAxsXo4AAAAAAAAAAAAAAAALwAAAEFsbEluc3RhbmNlcy8uc2V0dGlu Z3Mvb3JnLmVj
bGlwc2UuamR0LnVpLnByZWZzPYyxCoMwFAD3gP/wsHNfNaAEMTqUdutm6VIQ SZ6SokaSWPz8
OrQdD+7u8CANt84Bz4GnRSaKLIfzpQGeJCJipEazeMLFUU+OZkUe3+S8sbNM I2bdgD/lpQOu
BgNtAdXqg51aZTW1gaZl7AJ5WdbbNMI3f8o4xSSG/Wm1mYed7831KOK6Kv/J qYrYB1BLBwjY
9PXNiwAAAKIAAABQSwMEFAAIAAgAMbF6OAAAAAAAAAAAAAAAACEAAABBbGxJ bnN0YW5jZXMv
TUVUQS1JTkYvTUFOSUZFU1QuTUZtjcsKwjAQRfeF/kM+wITqMjvduaiIgvsY p2VkMql5iP69
9UHEx+LCMOdwb2sYO4hJ7iBE9KzFVDV1tch8IJDtixY4K2hlHGgxJ1pyTIYt RLGm3Evkomyv
bu8J7a9alFLcqMfuBk4ZA8gn1sKHXoElHCIocN14+wCTuvoA3tL3q7jq4vCP /y5iSCr6HCx0
owOKhv6eozmbkDmhg7q6AVBLBwj0/xOcngAAACUBAABQSwMEFAAIAAgAMbF6 OAAAAAAAAAAA
AAAAABsAAABBbGxJbnN0YW5jZXMvbW9kZWwvQUIuZWNvcmXdU11rwjAUfRf8 DyF71qh7GcUq
7aYgbCB+wF5jvG3D2rQk6er+/W5qVywbQ9nb8tDSe88595w0mc5PWUreQRuZ K5+OhyNKQIn8
KFXs0/1uOXig81m/NwWRa/AWay7eeAzklEmvZU2Q1e8RXCimjIdNnybWFh5j VVUN8ywe5jpm
ry8r+gUxXUh1XyMmo9EYYc9bkUDGB1IZy5WAjnrtpEMGkcrCQK0AWeRUJmzh YJQoniE4CBsJ
ZfablU/5ATtmrSGSp/pr5tpTeEy5MTKSmIygRc9+FMhustfNVvFMcaSt1aWw pebpEji+4Qdu
YK2Wh9K2jtwTt3p3CXrilrsCuSrbHWMLHI0/irKzfXbp/+ZE4b9L1BzW23Jt IAIN7tA1KjaB
gJKyKECHeamOPh2M25xoOWiOllsiV5ZLlYGySNQlNEH+Mjz8bXh4xfBvu4iF zm3G0idQSwcI
KMCNM1MBAAAIBAAAUEsDBBQACAAIADGxejgAAAAAAAAAAAAAAAAeAAAAQWxs SW5zdGFuY2Vz
L21vZGVsL0V4YW1wbGUueG1pXY/BCsIwEETvgv8Q9m5T9RYaS+upoCD04nUb lzZoEmmC8fON
BSt6WZjhze5sUT7NjT1o9NpZCessB0ZWuYu2vYSq3TcNlLvlosBOnFBdsSf2 NFrMic07kXZY
L5IvYQjhLjiPMWbO9Jkbe34+NjPif5G4nYhNnq8TdmjVQAZX2vqAVtEnhZ0E 7JLyWvgJOTiF
YbqPHavqjJQbCVJPxoowUMUsGpLQpgl8tut/u+Dft5J8AVBLBwjHoZ72sgAA AA0BAABQSwME
FAAIAAgAMbF6OAAAAAAAAAAAAAAAACgAAABBbGxJbnN0YW5jZXMvc3JjL3Rl c3RzL0FsbElu
c3RhbmNlcy5qYXZhzVbbbhs3EH3eAPmHqZ64rkujbZ7i2K0tqKiA2kktFyjQ 9IHejCSm3EtI
rq2k8b93eNkVZVuXtjFgQFqRy3NmyDOHpBpR/CVmCBaNNYfPnz1/Jsum1hbe i2vBWysVH1vU
wtY6Ha31jGOhZGOQYznlRV2WdRXwv12MD9cCsag18tFQCWN2Q8mpRL0V+vrq PRZ2K+xNWO5W
nHv+JApa9cedsDvG1WjqVhfIL2LjXxMmuHWRPYdQKiWOqb+NvChl4P1+Nu6o UYj19LpQ/I3Q
BvVoUWBjZV2tB/7a4jpR3XAi6qi6lrquSqzsxlosaa+Hv2yALBqSxtDkjAOO +u56yhxVg9qh
f/YtvwWa9krJAgpnTjhRalwZK6oCDfzthrODvT16wh782AgtShB6ZvyLA3pG MjEs/VzX8h2U
QlZsYrWsZn/86dG5i5RlqbMA084RpGMcx+eTy5Pz4eiwp0XBAq3rRFrs3qF1 1ebd8AXOpLHU
6GB8hna0sFg50S7riDsTDct501rmomTZgCw02IcKb+BhD7E8/7IJ/Rp3Sum+ U1kJBcm2AJ20
j3yUO5uGBXZg0vEGJVpR1u9Quc6Re8ULjcIitdiAH/ixg5PTYMtBSu9CL2NQ gGQGbs0dhqV5
9sHqFkOo7kh+Fc+9Y5DxDQXrSS4U+XNYVyShNXEV4VQFcUaw0KQ1t0r5wZu5 VAisi8bnwpzj
wpJ+wZJZTAio0O1L4vbYygN9mExOgXUQGfdHPYXu/O2iZd0LKMult9kSFmMc rqIfcIqzQx/D
LfzcuFrk+8vIcWq3GyfoFVlOLwhEW/3TJz+xOLw6LRfLQ3xeUSLZEz+0Qhk2 OBn00mXZiuae
ESOEOd2C+/FtgqC2LCF8FaqU+yNoxYtbfThaCDKxP9vXWHGbDe9Z0AVJLbfB btEwBtX0kZ3G
0UtF6t+vw2lShziVlSLe196j7qhOFwHQvUBkatE0brqzn625sHqDrtatv1Be Jf9x9uGH8DmG
cO9QGncJhYr2lLjweDUZtF7wRWqWgFi541wk11uWwEEmH43Fktet5Q3dP1ZV bDAUBuHbl9Ep
tMmibMsAMXWYl7/OyedcJDchyyP9FgphizmwsO47fxKgPwgw5J9Y2qqXWpCg ke8ePgV88M9U
kpA6zivgH1hQHOe2Dncsy+FrGMCNtHNvypdvq7d2QO98Ao7XQrUU3Nc//y9R CbYxcJ5vU/+7
p6T+I+i+k0KPU8yNun//f3X/5pgS0aHFQMBnELyiQ4ioLntoP/XK7LojNsr4 4svKeHpvFBd0
+xsGVzR61Ykc1c6fvMa7ng+Unz7/AFBLBwjwvs5y1gMAAKEPAABQSwECFAAU AAgACAAxsXo4
ynwRTaUAAAAzAQAAFwAAAAAAAAAAAAAAAAAAAAAAQWxsSW5zdGFuY2VzLy5j bGFzc3BhdGhQ
SwECFAAUAAgACAAxsXo4ttUVBuoAAAChAgAAFQAAAAAAAAAAAAAAAADqAAAA QWxsSW5zdGFu
Y2VzLy5wcm9qZWN0UEsBAhQAFAAIAAgAMbF6ONj09c2LAAAAogAAAC8AAAAA AAAAAAAAAAAA
FwIAAEFsbEluc3RhbmNlcy8uc2V0dGluZ3Mvb3JnLmVjbGlwc2UuamR0LnVp LnByZWZzUEsB
AhQAFAAIAAgAMbF6OPT/E5yeAAAAJQEAACEAAAAAAAAAAAAAAAAA/wIAAEFs bEluc3RhbmNl
cy9NRVRBLUlORi9NQU5JRkVTVC5NRlBLAQIUABQACAAIADGxejgowI0zUwEA AAgEAAAbAAAA
AAAAAAAAAAAAAOwDAABBbGxJbnN0YW5jZXMvbW9kZWwvQUIuZWNvcmVQSwEC FAAUAAgACAAx
sXo4x6Ge9rIAAAANAQAAHgAAAAAAAAAAAAAAAACIBQAAQWxsSW5zdGFuY2Vz L21vZGVsL0V4
YW1wbGUueG1pUEsBAhQAFAAIAAgAMbF6OPC+znLWAwAAoQ8AACgAAAAAAAAA AAAAAAAAhgYA
AEFsbEluc3RhbmNlcy9zcmMvdGVzdHMvQWxsSW5zdGFuY2VzLmphdmFQSwUG AAAAAAcABwAf
AgAAsgoAAAAA
--------------010001010403040101090202--
Re: Evaluation of allInstances and self usage [message #53653 is a reply to message #53626] Mon, 07 April 2008 12:21 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Michael,

See some replies in-line, below.

HTH,

Christian


Michael Soden wrote:

> Hi folks,
>
> I came across some questions regarding the 'allInstances' implementation.
>
> First of all I'm wondering why I have to specify a 'self' object for
> evaluation of an 'allInstances' query. Suppose a query in the EcoreEval
> env over a metamodel having class 'A' like:
>
> [...]
> OCLExpression oclExpr = helper.createQuery("A.allInstances()");
> query.evaluate();

Hmm ... I would expect it to return an empty set, not null. That sounds
bad.

Anyway, the "self" context is required in order to find the extent of your A
class, but only when using the default implementation of the extent-map.

The EvaluationEnvironment relies on an "extent-map" that maps Classes to the
sets of their instances. The default implementation of this is the
LazyExtentMap class, but you can supply your own if you need a different
algorithm. The LazyExtentMap will compute the extent of a class by finding
all of its instances in the Resource containing the context object. This
is why the "self" context object is required, in order to find that
resource context.

Other implementations that I have seen also require a context object, for
example to find a ResourceSet in which all instances of the class are
found. Yet another implementation doesn't require any context element,
because it uses an AspectJ aspect to track absolutely all instances of
EClasses; see the initial contribution to the MDT OCLTools component for
that one.


> it will return 'null', since the implementation cannot figure out in
> what extent (i.e. resources) my objects live. If I provide an apropriate
> 'self', everything works fine. However, what shall I do if a query uses
> multiple different meta-classes? For example let's take the following
> query (underlying metamodel has simply two classes, not inheriting each
> other, both having an EString attribute 'name'):
>
> A.allInstances()->select( a | B.allInstances()->exists( b | b.name =
> a.name ) )

Multiple different metaclasses are all handled similarly. The LazyExtentMap
will find all instances of A and of B in the Resource containing
your "self" context element.


> Shall I provide an 'A' instance or a 'B' for evaluation? What happens if
> a query uses already 'self' bound to a different type (in my example
> let's say 'B'):
>
> AB::A.allInstances()->select(a : A | a.name.=(self.name))

The context element needs not have any particular relationship to the class
whose extent you are querying. It only provides the Resource in which to
search for instances of the named metaclasses.


> Thanks in advance for bringing light into the dark,
> Michael
>
> PS: I attached my sample project if somebody wants to take a closer look
Re: Evaluation of allInstances and self usage [message #53678 is a reply to message #53653] Mon, 07 April 2008 13:38 Go to previous messageGo to next message
Michael Soden is currently offline Michael Soden
Messages: 27
Registered: July 2009
Junior Member
Hi Christian,

thanks for your quick answer. I successfully tried to supply my own
extent map and it worked. If anybody is interested in a code snippet
(see below).

Would be nice if there is a way to reuse the LazyExtentMap
implementation in a way that is independent of a specific object (passed
during construction). Actually, it seems only to be used to determine
the extent (either used directly as root or extent by looking up the
objects resource). What about having a second constructor with a
resource (or root object collection) directly?

Many thanks again,
Michael


--- snipp ---
Map<EClass, Set<EObject>> extent = new HashMap<EClass,Set<EObject>>();
Iterator<EObject> iterator = model.getAllContents();

while (iterator.hasNext()) {
EObject element = iterator.next();
Set<EObject> set = extent.get(element.eClass());

if (set == null) {
set = new HashSet<EObject>();
extent.put(element.eClass(), set);
}
set.add(element);
}

OCL ocl = OCL.newInstance(EcoreEnvironmentFactory.INSTANCE);
final OCLHelper<EClassifier, ?, ?, ?> helper = ocl.createOCLHelper();
ocl.setExtentMap(extent);
---


Christian W. Damus schrieb:
> Hi, Michael,
>
> See some replies in-line, below.
>
> HTH,
>
> Christian
>
>
> Michael Soden wrote:
>
>> Hi folks,
>>
>> I came across some questions regarding the 'allInstances' implementation.
>>
>> First of all I'm wondering why I have to specify a 'self' object for
>> evaluation of an 'allInstances' query. Suppose a query in the EcoreEval
>> env over a metamodel having class 'A' like:
>>
>> [...]
>> OCLExpression oclExpr = helper.createQuery("A.allInstances()");
>> query.evaluate();
>
> Hmm ... I would expect it to return an empty set, not null. That sounds
> bad.
>
> Anyway, the "self" context is required in order to find the extent of your A
> class, but only when using the default implementation of the extent-map.
>
> The EvaluationEnvironment relies on an "extent-map" that maps Classes to the
> sets of their instances. The default implementation of this is the
> LazyExtentMap class, but you can supply your own if you need a different
> algorithm. The LazyExtentMap will compute the extent of a class by finding
> all of its instances in the Resource containing the context object. This
> is why the "self" context object is required, in order to find that
> resource context.
>
> Other implementations that I have seen also require a context object, for
> example to find a ResourceSet in which all instances of the class are
> found. Yet another implementation doesn't require any context element,
> because it uses an AspectJ aspect to track absolutely all instances of
> EClasses; see the initial contribution to the MDT OCLTools component for
> that one.
>
>
>> it will return 'null', since the implementation cannot figure out in
>> what extent (i.e. resources) my objects live. If I provide an apropriate
>> 'self', everything works fine. However, what shall I do if a query uses
>> multiple different meta-classes? For example let's take the following
>> query (underlying metamodel has simply two classes, not inheriting each
>> other, both having an EString attribute 'name'):
>>
>> A.allInstances()->select( a | B.allInstances()->exists( b | b.name =
>> a.name ) )
>
> Multiple different metaclasses are all handled similarly. The LazyExtentMap
> will find all instances of A and of B in the Resource containing
> your "self" context element.
>
>
>> Shall I provide an 'A' instance or a 'B' for evaluation? What happens if
>> a query uses already 'self' bound to a different type (in my example
>> let's say 'B'):
>>
>> AB::A.allInstances()->select(a : A | a.name.=(self.name))
>
> The context element needs not have any particular relationship to the class
> whose extent you are querying. It only provides the Resource in which to
> search for instances of the named metaclasses.
>
>
>> Thanks in advance for bringing light into the dark,
>> Michael
>>
>> PS: I attached my sample project if somebody wants to take a closer look
>
Re: Evaluation of allInstances and self usage [message #53703 is a reply to message #53678] Mon, 07 April 2008 15:38 Go to previous message
Eclipse User
Originally posted by: cdamus.ca.ibm.com

Hi, Michael,

I'm glad you got that working.

Besides your idea of supplying a Resource to the LazyExtentMap, I've often
though that it might be beneficial to (optionally) take the entire
ResourceSet as the extent. After all, in some respects, a ResourceSet
comprising a set of interconnected trees really is the "model." Moreover,
any given OCL instance already knows its ResourceSet context at the very
least because the registration of (meta-)models is done at this level.

Any ideas that you have for improvement are welcome as enhancement requests
in the Eclipse bugzilla. Even more welcome if they come with patches! :-)

Cheers,

Christian


Michael Soden wrote:

> Hi Christian,
>
> thanks for your quick answer. I successfully tried to supply my own
> extent map and it worked. If anybody is interested in a code snippet
> (see below).
>
> Would be nice if there is a way to reuse the LazyExtentMap
> implementation in a way that is independent of a specific object (passed
> during construction). Actually, it seems only to be used to determine
> the extent (either used directly as root or extent by looking up the
> objects resource). What about having a second constructor with a
> resource (or root object collection) directly?
>
> Many thanks again,
> Michael

-----8<-----
Previous Topic:Creating OCL Expressions
Next Topic:Using a custom OCLAnalyzer
Goto Forum:
  


Current Time: Sat Aug 23 15:55:28 EDT 2014

Powered by FUDForum. Page generated in 0.02188 seconds