[Uml-devel] Recent Association patch.

[Brian Thomas]

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
> pointer?
>
> 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
	bug-fixing mode.

	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
	to do. 

	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.


	=b.t.

>
> Regards
>
> Oliver