Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » OCL » allOwnedElements() omits StructuredActivity's children
allOwnedElements() omits StructuredActivity's children [message #63170] Wed, 15 October 2008 01:07 Go to next message
Eclipse User
Originally posted by: rafael.abstratt.com

I have a very simple UML model:

Package
+-Activity
+-Comment
+-StructuredActivityNode
+-Comment
+-ObjectFlow
+-CreateObjectAction
+-ActivityParameterNode
+-InputPin

It is only bogus like that because I was trying to understand the
behavior below.

Then I start playing with the OCL console (btw, *very* handy little
tool, thanks!):

Evaluating:
Action.allInstances()

Results:
<Structured Activity Node>
<Create Object Action>

That is awesome. However, the following test puzzles me:

Evaluating:
self.allOwnedElements()

Results:
<Structured Activity Node>
<Comment>
<Comment>
<Activity>

What is the explanation for this result? At some point I thought it was
somehow stopping at the StructuredActivityNode and not going deeper. But
then I added a comment to it and it showed the comment.

Any ideas?

Thanks.

Rafael
Re: allOwnedElements() omits StructuredActivity's children [message #63202 is a reply to message #63170] Wed, 15 October 2008 08:41 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Rafael,

See some replies in-line, below.

HTH,

Christian


Rafael Chaves wrote:
> I have a very simple UML model:
>
> Package
> +-Activity
> +-Comment
> +-StructuredActivityNode
> +-Comment
> +-ObjectFlow
> +-CreateObjectAction
> +-ActivityParameterNode
> +-InputPin
>
> It is only bogus like that because I was trying to understand the
> behavior below.
>
> Then I start playing with the OCL console (btw, *very* handy little
> tool, thanks!):

Heh heh ... I'm glad you're enjoying it. I find it quite useful for
querying models. OCL has a not-quite-surprising ability to express
virtually all of the questions we might ask about a model.


> Evaluating:
> Action.allInstances()
>
> Results:
> <Structured Activity Node>
> <Create Object Action>
>
> That is awesome. However, the following test puzzles me:
>
> Evaluating:
> self.allOwnedElements()
>
> Results:
> <Structured Activity Node>
> <Comment>
> <Comment>
> <Activity>
>
> What is the explanation for this result? At some point I thought it was
> somehow stopping at the StructuredActivityNode and not going deeper. But
> then I added a comment to it and it showed the comment.

The allInstances() operation is defined by OCL, but the
Element::allOwnedElements() operation is not. It is defined by UML2. I
think it is defined in the specification, not just by the implementation.

allOwnedElements() is a recursive application of the ownedElement
derived union. So, if you are missing any elements, then it is because
ownedElement is missing some subsets.

I have included the MDT UML2 newsgroup in this reply so that they may
help you to correlate the missing subsets to UML RTF issues and/or raise
new ones as necessary. Any problems of missing subsets are most likely
errors in the UML specification than defects in the implementation.


> Any ideas?
>
> Thanks.
>
> Rafael
Re: allOwnedElements() omits StructuredActivity's children [message #63250 is a reply to message #63202] Thu, 16 October 2008 01:30 Go to previous messageGo to next message
Eclipse User
Originally posted by: rafael.abstratt.com

Thanks for the clarification, Christian.

I have yet to understand why Element#allOwnedElements() does not work
properly, but I tried to work around this issue by invoking
EObject#eAllContents(), but just hit another block: the OCL interpreter
returns no results.

It seems the fact that the result of eAllContents() is an empty
collection but a non-'empty' iterator (don't ask me why) confuses the
OCL evaluator. But even if eAllContents() returned an iterator that did
not implement java.util.Collection, I was wondering if you would expect
iterators to be handled properly (as some sort of OCL collection) by the
OCL evaluator.

Cheers,

Rafael

Christian W. Damus wrote:
> Hi, Rafael,
>
> See some replies in-line, below.
>
> HTH,
>
> Christian
>
>
> Rafael Chaves wrote:
>> I have a very simple UML model:
>>
>> Package
>> +-Activity
>> +-Comment
>> +-StructuredActivityNode
>> +-Comment
>> +-ObjectFlow
>> +-CreateObjectAction
>> +-ActivityParameterNode
>> +-InputPin
>>
>> It is only bogus like that because I was trying to understand the
>> behavior below.
>>
>> Then I start playing with the OCL console (btw, *very* handy little
>> tool, thanks!):
>
> Heh heh ... I'm glad you're enjoying it. I find it quite useful for
> querying models. OCL has a not-quite-surprising ability to express
> virtually all of the questions we might ask about a model.
>
>
>> Evaluating:
>> Action.allInstances()
>>
>> Results:
>> <Structured Activity Node>
>> <Create Object Action>
>>
>> That is awesome. However, the following test puzzles me:
>>
>> Evaluating:
>> self.allOwnedElements()
>>
>> Results:
>> <Structured Activity Node>
>> <Comment>
>> <Comment>
>> <Activity>
>>
>> What is the explanation for this result? At some point I thought it
>> was somehow stopping at the StructuredActivityNode and not going
>> deeper. But then I added a comment to it and it showed the comment.
>
> The allInstances() operation is defined by OCL, but the
> Element::allOwnedElements() operation is not. It is defined by UML2. I
> think it is defined in the specification, not just by the implementation.
>
> allOwnedElements() is a recursive application of the ownedElement
> derived union. So, if you are missing any elements, then it is because
> ownedElement is missing some subsets.
>
> I have included the MDT UML2 newsgroup in this reply so that they may
> help you to correlate the missing subsets to UML RTF issues and/or raise
> new ones as necessary. Any problems of missing subsets are most likely
> errors in the UML specification than defects in the implementation.
>
>
>> Any ideas?
>>
>> Thanks.
>>
>> Rafael
Re: allOwnedElements() omits StructuredActivity's children [message #63275 is a reply to message #63250] Thu, 16 October 2008 09:14 Go to previous messageGo to next message
Eclipse User
Originally posted by: cdamus.zeligsoft.com

Hi, Rafael,

As far as OCL is concerned, the TreeIterator is just an opaque
data-type. It doesn't know what to do with it.

It would be difficult for EMF to make the iterator behave like a
collection, because in Java, collections are mutable. However, in OCL,
they aren't, so it would be feasible from that perspective.

However, it would probably be better in the long run to get
allOwnedElements() working correctly. :-)

cW

Rafael Chaves wrote:
> Thanks for the clarification, Christian.
>
> I have yet to understand why Element#allOwnedElements() does not work
> properly, but I tried to work around this issue by invoking
> EObject#eAllContents(), but just hit another block: the OCL interpreter
> returns no results.
>
> It seems the fact that the result of eAllContents() is an empty
> collection but a non-'empty' iterator (don't ask me why) confuses the
> OCL evaluator. But even if eAllContents() returned an iterator that did
> not implement java.util.Collection, I was wondering if you would expect
> iterators to be handled properly (as some sort of OCL collection) by the
> OCL evaluator.
>
> Cheers,
>
> Rafael
>
> Christian W. Damus wrote:
>> Hi, Rafael,
>>
>> See some replies in-line, below.
>>
>> HTH,
>>
>> Christian
>>
>>
>> Rafael Chaves wrote:
>>> I have a very simple UML model:
>>>
>>> Package
>>> +-Activity
>>> +-Comment
>>> +-StructuredActivityNode
>>> +-Comment
>>> +-ObjectFlow
>>> +-CreateObjectAction
>>> +-ActivityParameterNode
>>> +-InputPin
>>>
>>> It is only bogus like that because I was trying to understand the
>>> behavior below.
>>>
>>> Then I start playing with the OCL console (btw, *very* handy little
>>> tool, thanks!):
>>
>> Heh heh ... I'm glad you're enjoying it. I find it quite useful for
>> querying models. OCL has a not-quite-surprising ability to express
>> virtually all of the questions we might ask about a model.
>>
>>
>>> Evaluating:
>>> Action.allInstances()
>>>
>>> Results:
>>> <Structured Activity Node>
>>> <Create Object Action>
>>>
>>> That is awesome. However, the following test puzzles me:
>>>
>>> Evaluating:
>>> self.allOwnedElements()
>>>
>>> Results:
>>> <Structured Activity Node>
>>> <Comment>
>>> <Comment>
>>> <Activity>
>>>
>>> What is the explanation for this result? At some point I thought it
>>> was somehow stopping at the StructuredActivityNode and not going
>>> deeper. But then I added a comment to it and it showed the comment.
>>
>> The allInstances() operation is defined by OCL, but the
>> Element::allOwnedElements() operation is not. It is defined by UML2.
>> I think it is defined in the specification, not just by the
>> implementation.
>>
>> allOwnedElements() is a recursive application of the ownedElement
>> derived union. So, if you are missing any elements, then it is
>> because ownedElement is missing some subsets.
>>
>> I have included the MDT UML2 newsgroup in this reply so that they may
>> help you to correlate the missing subsets to UML RTF issues and/or
>> raise new ones as necessary. Any problems of missing subsets are most
>> likely errors in the UML specification than defects in the
>> implementation.
>>
>>
>>> Any ideas?
>>>
>>> Thanks.
>>>
>>> Rafael
Re: allOwnedElements() omits StructuredActivity's children [message #63299 is a reply to message #63275] Thu, 16 October 2008 11:07 Go to previous message
Eclipse User
Originally posted by: rafael.abstratt.com

Agreed. I did some investigation and the problem seems related to the
implementation of StructureActivityNode#getOwnedElements() (which
#allOwnedElements() implementation relies upon) not including its
immediate child nodes and edges.

I reported it as: https://bugs.eclipse.org/251045

Cheers,

Rafael

Christian W. Damus wrote:
> Hi, Rafael,
>
> As far as OCL is concerned, the TreeIterator is just an opaque
> data-type. It doesn't know what to do with it.
>
> It would be difficult for EMF to make the iterator behave like a
> collection, because in Java, collections are mutable. However, in OCL,
> they aren't, so it would be feasible from that perspective.
>
> However, it would probably be better in the long run to get
> allOwnedElements() working correctly. :-)
>
> cW
>
> Rafael Chaves wrote:
>> Thanks for the clarification, Christian.
>>
>> I have yet to understand why Element#allOwnedElements() does not work
>> properly, but I tried to work around this issue by invoking
>> EObject#eAllContents(), but just hit another block: the OCL
>> interpreter returns no results.
>>
>> It seems the fact that the result of eAllContents() is an empty
>> collection but a non-'empty' iterator (don't ask me why) confuses the
>> OCL evaluator. But even if eAllContents() returned an iterator that
>> did not implement java.util.Collection, I was wondering if you would
>> expect iterators to be handled properly (as some sort of OCL
>> collection) by the OCL evaluator.
>>
>> Cheers,
>>
>> Rafael
>>
>> Christian W. Damus wrote:
>>> Hi, Rafael,
>>>
>>> See some replies in-line, below.
>>>
>>> HTH,
>>>
>>> Christian
>>>
>>>
>>> Rafael Chaves wrote:
>>>> I have a very simple UML model:
>>>>
>>>> Package
>>>> +-Activity
>>>> +-Comment
>>>> +-StructuredActivityNode
>>>> +-Comment
>>>> +-ObjectFlow
>>>> +-CreateObjectAction
>>>> +-ActivityParameterNode
>>>> +-InputPin
>>>>
>>>> It is only bogus like that because I was trying to understand the
>>>> behavior below.
>>>>
>>>> Then I start playing with the OCL console (btw, *very* handy little
>>>> tool, thanks!):
>>>
>>> Heh heh ... I'm glad you're enjoying it. I find it quite useful for
>>> querying models. OCL has a not-quite-surprising ability to express
>>> virtually all of the questions we might ask about a model.
>>>
>>>
>>>> Evaluating:
>>>> Action.allInstances()
>>>>
>>>> Results:
>>>> <Structured Activity Node>
>>>> <Create Object Action>
>>>>
>>>> That is awesome. However, the following test puzzles me:
>>>>
>>>> Evaluating:
>>>> self.allOwnedElements()
>>>>
>>>> Results:
>>>> <Structured Activity Node>
>>>> <Comment>
>>>> <Comment>
>>>> <Activity>
>>>>
>>>> What is the explanation for this result? At some point I thought it
>>>> was somehow stopping at the StructuredActivityNode and not going
>>>> deeper. But then I added a comment to it and it showed the comment.
>>>
>>> The allInstances() operation is defined by OCL, but the
>>> Element::allOwnedElements() operation is not. It is defined by
>>> UML2. I think it is defined in the specification, not just by the
>>> implementation.
>>>
>>> allOwnedElements() is a recursive application of the ownedElement
>>> derived union. So, if you are missing any elements, then it is
>>> because ownedElement is missing some subsets.
>>>
>>> I have included the MDT UML2 newsgroup in this reply so that they may
>>> help you to correlate the missing subsets to UML RTF issues and/or
>>> raise new ones as necessary. Any problems of missing subsets are
>>> most likely errors in the UML specification than defects in the
>>> implementation.
>>>
>>>
>>>> Any ideas?
>>>>
>>>> Thanks.
>>>>
>>>> Rafael
Previous Topic:[Announce] MDT OCL 1.3.0 I200810152219 is available
Next Topic:Validation menu option and OCL on UML
Goto Forum:
  


Current Time: Thu Jul 31 03:29:57 EDT 2014

Powered by FUDForum. Page generated in 0.02211 seconds