Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Re: allOwnedElements() omits StructuredActivity's children
Re: allOwnedElements() omits StructuredActivity's children [message #477829] Wed, 15 October 2008 12:41 Go to next message
Eclipse UserFriend
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 #477833 is a reply to message #477829] Thu, 16 October 2008 05:30 Go to previous messageGo to next message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
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 #477836 is a reply to message #477833] Thu, 16 October 2008 13:14 Go to previous messageGo to next message
Eclipse UserFriend
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 #477837 is a reply to message #477836] Thu, 16 October 2008 15:07 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
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
Re: allOwnedElements() omits StructuredActivity's children [message #627038 is a reply to message #477829] Thu, 16 October 2008 05:30 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
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 #627041 is a reply to message #477833] Thu, 16 October 2008 13:14 Go to previous message
Eclipse UserFriend
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 #627042 is a reply to message #477836] Thu, 16 October 2008 15:07 Go to previous message
Rafael Chaves is currently offline Rafael ChavesFriend
Messages: 362
Registered: July 2009
Senior Member
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:Re: Building UML2-approximated Model in EMF
Next Topic:Re: Building UML2-approximated Model in EMF
Goto Forum:
  


Current Time: Thu Mar 28 09:02:52 GMT 2024

Powered by FUDForum. Page generated in 0.03269 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top