Created attachment 86826 [details] bug reporduce example. steps to reproduce: 1. create class daigram 2. create class "super" 3. crate class "derived" 4. make generalization assotiation (Implements) between "super" and derived. 5. delete association. 6. generate all code (C++) result: in the "derived.h": class derived_class : public superclass if repeat steps 4, 5 few times: in the "derived.h": class derived_class : public superclass, public superclass // two assotiations
Created attachment 86827 [details] results of code generation
(In reply to comment #0) > Created attachment 86826 [details] > bug reporduce example. > > steps to reproduce: > > 1. create class daigram > 2. create class "super" > 3. crate class "derived" > 4. make generalization assotiation (Implements) between "super" and derived. > 5. delete association. > 6. generate all code (C++) > > result: > in the "derived.h": class derived_class : public superclass > > if repeat steps 4, 5 few times: > in the "derived.h": class derived_class : public superclass, public > superclass // two assotiations The reason for this is that the related UMLAssociation has not been removed from the document. In AssociationWidget::cleanup() I found the following comment: .... if (m_umlObject && m_umlObject->baseType() == UMLObject::ot_Association) { /* We do not remove the UMLAssociation from the document. Why? - Well, for example we might be in the middle of a cut/paste. If the UMLAssociation is removed by the cut then upon pasteing we have a problem. This is not quite clean yet - there should be a way to explicitly delete a UMLAssociation. The Right Thing would be to have a ListView representation for UMLAssociation. ` IF we are cut n pasting, why are we handling this association as a pointer? 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()). */ setUMLAssociation(0); }
*** Bug 425295 has been marked as a duplicate of this bug. ***