Access to Linked Attribute source information

[da_Burp]

For a modeltransformation from PIM to a C# PSM I would like to have access to information about the source of a Linked Attribute so I can generate intial code in one class that know about the the class/role on the other side of the association.

I have a bi-directional one to many association between let's say a Parent[1]<-(dad) and a (kids)->[0..*]Child. Now I want to expose the collection of children as ReadOnly, this can be done in code generation and is ok. To be able to add and remove children from that relation I have written templates that generate these Add and Remove functions. I want to generate code in these functions as well. I have succeeded in generating initial code for the collection access in the form of this.Kids.Add(child); However, in Bi-Directional relations I want to add another line that sets the relation on the child in the form of Child.Dad = this; I have explicitly named the role dad because it's the rolename that is used to generate the field & property on the Child class. Unfortunately the only information I have access to on the moment of generating the Add/Remove functions during the transformation is the Type information of the target(Child). So the only way I have found so far to make this work is to give the role the same name as the target Type using the 'linkAttName' substitution macro. This however can be very confusing, and it would just be a whole lot easier to make it useable when there is access to source information of the linked attribute just like there is on the connector substitution macro fields.

I guess there's might be some explicit reasoning for this. So the question is if this can be made possible, and if not, for what reason it is done this way?


[size=10]Another thing that apparently isn't possible is that parts of the PIM that have been deleted don't get deleted on transformation in the PSM. I was striving to be able to have the PSM be equal with what was in the model plus have functionality that was added in code to be synchronised with the PSM as well. But I guess that's just simply to ambitious since it's is not possible to have the Transformation distinguish what in the PSM is from synchronising with code and what is from the PIM. Concluding this I think I will abandon the reverse engineering(or reverse engineer in a seperate model if needed) and stick to only forward engineering to make this not to complicated and error prone for other people to use.[/size]

[Eve]

If you want access to the opposite role of a linked attribute, you'll need to use the Connector list instead of the linked attribute.

[da_Burp]

I understand, but I want to use the role name for generating code in the target class(Parent) of the linked attribute which sets up the Bi-Directional relationship when adding or removing an child through Add/Remove functions.

...in Bi-Directional relations I want to add another line that sets the relation on the child in the form of Child.Dad = this; I have explicitly named the role dad because it's the rolename that is used to generate the field & property on the Child class.

But since I'm not in any class scope when the connectors Template is run, so I don't have the ability to do any editing in the class neccesary for adding functions & code(Child.Dad = this;).

I have also tried adding TaggedValues to the connector so I could use those in the LinkedAttrbute template, but I figured it's also not possible to add Tagged Values to connectors in the templates.

[«Midnight»]

A bit of a long shot here, but perhaps the relationship itself is at fault.

[So, please take this with a grain of salt...]

Paolo - check recent posts by gurus, you'll find him - has written in detail on how composite associations (I'm purposefully avoiding UML terms) can be created two ways in EA. Unfortunately, while they seem to be the same on a diagram, and they produce the same dialogs, they are not the same in the underlying schema.

Do a search on Paolo's work and you'll find the appropriate threads. He explains the differences provides suggestions on which creation method is best to get the best results in UML 2.

Once you've got the gist of it, see if your associations are the 'wrong' flavor. If so, try creating a simple model the other way, and see if you can make the templates work.

David