Home » Archived » M2M (model-to-model transformation) » insert two (or more) elements to a feature which is a list
| insert two (or more) elements to a feature which is a list [message #37414] |
Mon, 14 May 2007 07:17  |
Eclipse User |
|
|
|
Originally posted by: beppo123.gmx.de
Hello,
I want to add two (or more) elements to a feature which is a list. I have
some question about that and want to
post my remarks:
-> What is the best practice to do that?
-> I get a transformation result which seems to be non deterministic.
-> I think the assignment to lists with different types (list <- element) is
irritating and strange.
-> What is the best practice to do that?
----------------------------------------
I am using a "trick" and initialize an empty sequence to that I add the
elements.
Is there a better way to do that?
using{
emptySequence : Sequence(OclAny )
= Sequence{};
}
to
class_controller : UMLSimpleClassDiagramModel!Class(
name <- 'ClassK'
,ownedAttribute <- emptySequence -> append(property_controller)
-> append(property_aas)
)
,property_controller : UMLSimpleClassDiagramModel!Property (
name <- 'PropController
)
,property_aas : UMLSimpleClassDiagramModel!Property (
name <- 'PropAAS'
)
-> I get a transformation result which seems to be non deterministic.
------------------------------------------------------------ ---------
If I assign two elements to two different lists in one rule, I get an non
deterministic result.
It doesn't matter if the elements are assigned directly or with my "trick":
to
class_controller : UMLSimpleClassDiagramModel!Class(
name <- 'class' + 'K'
)
,class_aas : UMLSimpleClassDiagramModel!Class(
name <- 'Class' + 'AAS'
)
,property_controller : UMLSimpleClassDiagramModel!Property (
name <- 'PropController'
)
,property_aas : UMLSimpleClassDiagramModel!Property (
name <- 'PropAAS'
)
do{
class_controller.ownedAttribute <- property_aas;
class_controller.ownedAttribute <- property_controller;
class_aas.ownedAttribute <- property_aas;
class_aas.ownedAttribute <- property_controller;
}
-- expected result (as an example)
---------------------------------------
<Class name='ClassK>
<Property name="PropAAS" />
<Property name="PropController" />
</Class>
<Class name='ClassAAS>
<Property name="PropAAS" />
<Property name="PropController" />
</Class>
-- real result (one of two different possibilities, properties can be
subelements vice versa.)
---------------------------------------
<Class name='ClassK>
<Property name="PropAAS" />
</Class>
<Class name='ClassAAS>
<Property name="PropController" />
</Class>
---------------------------------------
-> I think the assignment to lists with different types (list <- element) is
irritating and strange.
------------------------------------------------------------ ----------------------------------------
class_controller : UMLSimpleClassDiagramModel!Class(
name <- 'ClassK'
,ownedAttribute <- property_aas
)
Thanks and best regards, Susanne.
|
|
|
| Re: insert two (or more) elements to a feature which is a list [message #37448 is a reply to message #37414] |
Mon, 14 May 2007 07:45  |
| Eclipse User |
|
|
|
Originally posted by: eric.vepa.gmail.com
Hi Susanne,
Your trying to share attributes, but it seems the reference
"ownedAttribute" (from the KM3 metamodel you are using) is a containment
reference (equivalent to UML composition relationship).
If you really want to share them, you may remove the "container"
property or manually duplicate the two attributes.
S wrote:
> Hello,
> I want to add two (or more) elements to a feature which is a list. I have
> some question about that and want to
> post my remarks:
>
> -> What is the best practice to do that?
> -> I get a transformation result which seems to be non deterministic.
> -> I think the assignment to lists with different types (list <- element) is
> irritating and strange.
>
>
> -> What is the best practice to do that?
> ----------------------------------------
> I am using a "trick" and initialize an empty sequence to that I add the
> elements.
> Is there a better way to do that?
>
> using{
> emptySequence : Sequence(OclAny )
> = Sequence{};
> }
> to
> class_controller : UMLSimpleClassDiagramModel!Class(
> name <- 'ClassK'
> ,ownedAttribute <- emptySequence -> append(property_controller)
> -> append(property_aas)
> )
> ,property_controller : UMLSimpleClassDiagramModel!Property (
> name <- 'PropController
> )
> ,property_aas : UMLSimpleClassDiagramModel!Property (
> name <- 'PropAAS'
> )
>
>
>
> -> I get a transformation result which seems to be non deterministic.
> ------------------------------------------------------------ ---------
> If I assign two elements to two different lists in one rule, I get an non
> deterministic result.
> It doesn't matter if the elements are assigned directly or with my "trick":
>
> to
> class_controller : UMLSimpleClassDiagramModel!Class(
> name <- 'class' + 'K'
> )
> ,class_aas : UMLSimpleClassDiagramModel!Class(
> name <- 'Class' + 'AAS'
> )
> ,property_controller : UMLSimpleClassDiagramModel!Property (
> name <- 'PropController'
> )
> ,property_aas : UMLSimpleClassDiagramModel!Property (
> name <- 'PropAAS'
> )
> do{
> class_controller.ownedAttribute <- property_aas;
> class_controller.ownedAttribute <- property_controller;
> class_aas.ownedAttribute <- property_aas;
> class_aas.ownedAttribute <- property_controller;
> }
>
> -- expected result (as an example)
> ---------------------------------------
> <Class name='ClassK>
> <Property name="PropAAS" />
> <Property name="PropController" />
> </Class>
>
> <Class name='ClassAAS>
> <Property name="PropAAS" />
> <Property name="PropController" />
> </Class>
>
> -- real result (one of two different possibilities, properties can be
> subelements vice versa.)
> ---------------------------------------
> <Class name='ClassK>
> <Property name="PropAAS" />
> </Class>
>
> <Class name='ClassAAS>
> <Property name="PropController" />
> </Class>
> ---------------------------------------
>
> -> I think the assignment to lists with different types (list <- element) is
> irritating and strange.
> ------------------------------------------------------------ ----------------------------------------
>
> class_controller : UMLSimpleClassDiagramModel!Class(
> name <- 'ClassK'
> ,ownedAttribute <- property_aas
> )
>
> Thanks and best regards, Susanne.
>
>
--
Éric Vépa
|
|
| |
| Re: [ATL] insert two (or more) elements to a feature which is a list [message #37633 is a reply to message #37607] |
Tue, 15 May 2007 05:07 |
 Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hello Suzanne,
First thing first, sorry for repeating this again, but could you please
prefix your ATL-related posts on this newsgroup with [ATL]? Thanks.
>>> -> What is the best practice to do that?
The following binding is the simplest solution I can think of:
ownedAttribute <- Sequence {property_controller, property_aas}
>>> -> I think the assignment to lists with different types (list <-
element)
>>> is irritating and strange.
Could you please tell me what you mean?
>> Your trying to share attributes, but it seems the reference
>> "ownedAttribute" (from the KM3 metamodel you are using) is a
containment
>> reference (equivalent to UML composition relationship).
>> If you really want to share them, you may remove the "container"
property
>> or manually duplicate the two attributes.
Thanks to Eric you for diagnosing this issue ;-).
> yes, you are right, but wouldn't it not be better if ATL would throw an
> error instead of a incorrect result?
Well, with respect to containment semantics, I would argue that you get
the result that you asked for ;-). For instance, in real life, if you
take a wheel from a car to put it on another car, it is not on the first
car any longer.
That being said, I agree that whereas this behavior (may) make sense
when you write imperative code, it is usually confusing when writing
declarative code. This is especially due to execution ordering issues,
on which you have little/no control in declarative code.
>>> -> I get a transformation result which seems to be non deterministic.
You only get a non-deterministic result because you ask ATL to do two
incompatible things at the same time, and it does not choose the same
solution to this ambiguity each time. Therefore, I find your suggestion
of throwing an error quite appropriate, because there is indeed a
problem in such a case. Thanks for your feedback.
Although it is possible to make the ATL VM throw an error when such a
case occur, I believe there should still be an option to disable the
check (i.e., like for inter-model references), which would of course be
enabled by default.
Another possibility would be to only issue a warning.
Please, feel free to submit a bugzilla entry for follow-up on your
suggestion :-).
Best regards,
Frédéric Jouault
|
|
|
| Re: [ATL] insert two (or more) elements to a feature which is a list [message #40339 is a reply to message #37633] |
Tue, 22 May 2007 13:36 |
Dennis Wagelaar
Messages: 147
Registered: July 2009 |
Senior Member |
|
|
Frédéric Jouault schreef:
> Hello Suzanne,
*snip*
>
> >> Your trying to share attributes, but it seems the reference
> >> "ownedAttribute" (from the KM3 metamodel you are using) is a
> containment
> >> reference (equivalent to UML composition relationship).
> >> If you really want to share them, you may remove the "container"
> property
> >> or manually duplicate the two attributes.
>
> Thanks to Eric you for diagnosing this issue ;-).
>
>
> > yes, you are right, but wouldn't it not be better if ATL would throw an
> > error instead of a incorrect result?
>
> Well, with respect to containment semantics, I would argue that you get
> the result that you asked for ;-). For instance, in real life, if you
> take a wheel from a car to put it on another car, it is not on the first
> car any longer.
>
> That being said, I agree that whereas this behavior (may) make sense
> when you write imperative code, it is usually confusing when writing
> declarative code. This is especially due to execution ordering issues,
> on which you have little/no control in declarative code.
>
>
> >>> -> I get a transformation result which seems to be non deterministic.
>
> You only get a non-deterministic result because you ask ATL to do two
> incompatible things at the same time, and it does not choose the same
> solution to this ambiguity each time. Therefore, I find your suggestion
> of throwing an error quite appropriate, because there is indeed a
> problem in such a case. Thanks for your feedback.
>
>
>
> Although it is possible to make the ATL VM throw an error when such a
> case occur, I believe there should still be an option to disable the
> check (i.e., like for inter-model references), which would of course be
> enabled by default.
>
> Another possibility would be to only issue a warning.
>
> Please, feel free to submit a bugzilla entry for follow-up on your
> suggestion :-).
>
>
> Best regards,
>
> Frédéric Jouault
A short note on inter-model references: these references are by
definition never containment references, since that would transfer the
assigned element from one model to the other (compare to inter-car
wheels ;-)). This means that the multiple assignment check of
containment references is always relevant.
This relates to the deep-copy bug (#146756). This bug was caused by the
assumption that inter-model containment references should be allowed
when "allow inter-model references" is enabled. There is however no such
thing as an inter-model containment reference. The effect was that
entire source element containment trees are moved from source to target
model. The effect resembled a deep copy instead of a move, since the
source model modifications are never stored.
Kind regards,
Dennis
P.S. related bug can be found here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=146756
|
|
|
| Re: [ATL] insert two (or more) elements to a feature which is a list [message #40898 is a reply to message #40339] |
Wed, 23 May 2007 12:40 |
Frédéric Jouault
Messages: 572
Registered: July 2009 |
Senior Member |
|
|
Hi Dennis,
Thank you for this information :-).
Best regards,
Frédéric Jouault
Dennis Wagelaar wrote:
> Frédéric Jouault schreef:
>> Hello Suzanne,
> *snip*
>>
>> >> Your trying to share attributes, but it seems the reference
>> >> "ownedAttribute" (from the KM3 metamodel you are using) is a
>> containment
>> >> reference (equivalent to UML composition relationship).
>> >> If you really want to share them, you may remove the "container"
>> property
>> >> or manually duplicate the two attributes.
>>
>> Thanks to Eric you for diagnosing this issue ;-).
>>
>>
>> > yes, you are right, but wouldn't it not be better if ATL would
>> throw an
>> > error instead of a incorrect result?
>>
>> Well, with respect to containment semantics, I would argue that you
>> get the result that you asked for ;-). For instance, in real life, if
>> you take a wheel from a car to put it on another car, it is not on the
>> first car any longer.
>>
>> That being said, I agree that whereas this behavior (may) make sense
>> when you write imperative code, it is usually confusing when writing
>> declarative code. This is especially due to execution ordering issues,
>> on which you have little/no control in declarative code.
>>
>>
>> >>> -> I get a transformation result which seems to be non
>> deterministic.
>>
>> You only get a non-deterministic result because you ask ATL to do two
>> incompatible things at the same time, and it does not choose the same
>> solution to this ambiguity each time. Therefore, I find your
>> suggestion of throwing an error quite appropriate, because there is
>> indeed a problem in such a case. Thanks for your feedback.
>>
>>
>>
>> Although it is possible to make the ATL VM throw an error when such a
>> case occur, I believe there should still be an option to disable the
>> check (i.e., like for inter-model references), which would of course
>> be enabled by default.
>>
>> Another possibility would be to only issue a warning.
>>
>> Please, feel free to submit a bugzilla entry for follow-up on your
>> suggestion :-).
>>
>>
>> Best regards,
>>
>> Frédéric Jouault
>
> A short note on inter-model references: these references are by
> definition never containment references, since that would transfer the
> assigned element from one model to the other (compare to inter-car
> wheels ;-)). This means that the multiple assignment check of
> containment references is always relevant.
>
> This relates to the deep-copy bug (#146756). This bug was caused by the
> assumption that inter-model containment references should be allowed
> when "allow inter-model references" is enabled. There is however no such
> thing as an inter-model containment reference. The effect was that
> entire source element containment trees are moved from source to target
> model. The effect resembled a deep copy instead of a move, since the
> source model modifications are never stored.
>
> Kind regards,
> Dennis
>
> P.S. related bug can be found here:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=146756
|
|
|
Goto Forum:
Current Time: Tue Apr 23 13:14:08 GMT 2024
Powered by FUDForum. Page generated in 0.03475 seconds |
] 
Search
Help
Register
Login
Home
