[Uml-devel] Recent Association patch.
brian.thomas at gsfc.nasa.gov
Thu Nov 13 07:40:07 UTC 2003
On Thursday 13 November 2003 09:46 am, umbrello-devel-request at mail.kde.org wrote:
> Hi Brian,
> In associationwidget.cpp:1.68, Brian Thomas writes:
> + IF we are cut n pasting, why are we handling this association as a
> If the cut operation physically removes not only the
> AssociationWidget but also the UMLAssociation, then the
> paste operation fails because it relies on the UMLAssociation
> still being available. The problem here is we would need paste
> buffers for _two_ objects.
But we should just be caching the meta-data about the association
(generally, thats just the fields of the UMLAssociation) instead of
passing around object pointers.
There have been several changes to the association code recently
that have been causing problems. I see the following:
1. AssociationWidgets may share UMLAssociations (used to be simple
one-to-one, now its many-to-one).
2. New types of associations, e.g. at_Realization, (a type of dependancy)
Neither of these changes have been fully debugged. As a result of the
first change, its possible to have unattached UMLAssociations floating
around, because the parent AssociationWidgets no longer can control
if they live or die. As a result of the second change, we can do code generation
because some of the types of association arent actually available to the generator
(e.g. not entered into the list of umldoc associations, etc).
Strictly speaking the UMLAssociation class should be in *composition* with the
parent AssociationWidget, IF it is created with a parent AssocWidget. This is why
I put in a reference counter, so that the UMLassociation will die when the last parent
widget does. Along these lines, I dont see why we have cleanup() method being
called by umldoc/umlview classes on associations. In everycase where
assoc->cleanup() occurs in the code, the next line causes the association to then delete.
Hence, I concluded that cleanup is just as detail of the association destructor, and
should be only called from there. This last change, I dont think, will change
any behavior in the code.
> + We should be using the XMI representation for a cut and paste. This
> + allows us to be clean here, AND a choice of recreating the object
> + w/ same id IF its a "cut", or a new object if its a "copy" operation
> + (in which case we wouldnt be here, in cleanup()).
> + At any rate, currently you cant cut n paste associations anyways.
> What do you mean? I use cut&paste of associations all the time!
Ugh. How do you do that? I dont see the cut'n paste buttons working (!!).
This is my bad here. I agree that changing this functionality is the major
change, and should have been presented to the list first. Please accept
my appologies on being too agressive. I guess I got caught up in the
I think it IS correct to be using XMI to record the meta-data of associations
for cut-n-paste, HOWEVER, thats a BIG change that we dont have time
I will try to revert this change so that cut-n-paste of associations is back.
> Brian, I would suggest that before you make this kind of change,
> how about posting your diffs to uml-devel for discussion.
Agreed. I was too aggressive in fixing my own bugs to notice I was
doing the wrong thing. Again, my appologies to all developers.
> Along these lines, how do you get the problem of the duplicate
> UMLAssociations? I haven't seen these here - but I guess I'm
> just using umbrello differently than you are. (For one, I've
> not been using the code generation in a while.)
> So in this case I think it would be good to make a bugs.kde.org entry.
The bug appears when you try to place a realization between a class
and interface. Place the same realization twice (which you shouldnt
be able to do), and you will see what I am talking about.
> As for your current modifications, I will try to look at them
> over the weekend.
I will try to revert the small part related to cut-n-paste today if I can.
I hope the other changes, which arent as drastic, may stand.
More information about the umbrello-devel