Bug 293042 - Junk residual UMLAssociations saved to XMI
Summary: Junk residual UMLAssociations saved to XMI
Status: RESOLVED FIXED
Alias: None
Product: umbrello
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Umbrello Development Group
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-01 12:49 UTC by Skip Huffman
Modified: 2013-11-06 17:19 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.9.0
Sentry Crash Report:


Attachments
A umbrello model file demonstrating the failure (36.73 KB, application/xml)
2012-02-01 12:49 UTC, Skip Huffman
Details
Same file, further stripped. (28.96 KB, application/xml)
2012-02-01 13:34 UTC, Skip Huffman
Details
very simple demo XMI, original version (12.29 KB, text/x-xmi)
2012-02-03 23:11 UTC, Oliver Kellogg
Details
previously attached model after deletions (8.65 KB, text/x-xmi)
2012-02-03 23:21 UTC, Oliver Kellogg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Skip Huffman 2012-02-01 12:49:50 UTC
Created attachment 68396 [details]
A umbrello model file demonstrating the failure

Version:           unspecified (using KDE 4.5.5) 
OS:                Linux

I have a moderately complex model in umbrello.  When I attempt to run the code generation wizard all the classes, except one, create some sort of python code structure.  But one does not.  It pauses on the progress screen and its status never changes from "Not Yet Generated"

I don't think there is anything fancy about this class, and in fact as a test I went in to its properties and deleted all Attributes and Operations and then deleted all the Associations.  It still won't generate code.

Reproducible: Always

Steps to Reproduce:
Open the attached temp.xmi,  attempt to generate python code.  note that the only visible class, "Primitive Test Functions" never leaves the "Not Yet Generated" state.

Actual Results:  
Some code frameworks are generated, others are not.

Expected Results:  
All specified code frameworks should be generated.

This is a very worrisome bug as code framework generation is key to the work flow that I am setting up for my department.
Comment 1 Skip Huffman 2012-02-01 13:34:56 UTC
Created attachment 68402 [details]
Same file, further stripped.

I stripped everything I could find out of this class and it still won't build code.
Comment 2 Skip Huffman 2012-02-01 13:38:43 UTC
It occurs to me that there was one thing that I might have done differently.  I think I used the "Source Code" tab somewhere in that class and put in some psuedocode, just to test that function.  The generation failed, and the first thing I did was delete that code, thinking that I had done it wrong.  But the problem continued even with the code deleted.  But I suspect perhaps some trace has been left.
Comment 3 Skip Huffman 2012-02-01 18:04:40 UTC
I was able to create a seemingly identical class.  Then plug it in to the same place in the diagram.  Delete the problematic class.  Rename my new class to the originals name. And everything now exports.

Very clumsy.
Comment 4 Oliver Kellogg 2012-02-01 19:10:57 UTC
Looking into your attachment id=68402, the class in question is:

<UML:Class visibility="public" isSpecification="false" namespace="Logical View" isAbstract="false" isLeaf="false" isRoot="false" xmi.id="hLB5tjdEVzQ6" name="Primitive Test Functions."/>

However, this class (xmi.id="hLB5tjdEVzQ6") has a few dangling dependencies to classes not contained in the file,

<UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="hLB5tjdEVzQ6" xmi.id="ZYGic8C768cZ" client="jTuo0mdW6PeR" name=""/>
<UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="jTuo0mdW6PeR" xmi.id="1ZTJnXX4rdr0" client="jTuo0mdW6PeR" name=""/>
<UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="jTuo0mdW6PeR" xmi.id="mmtJN3ihe4Pl" client="jTuo0mdW6PeR" name=""/>
[...]
<UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="hLB5tjdEVzQ6" xmi.id="CuwyanplvHio" client="jTuo0mdW6PeR" name=""/>
<UML:Dependency visibility="public" isSpecification="false" namespace="Logical View" supplier="jTuo0mdW6PeR" xmi.id="VemOvUDr3R4Q" client="hLB5tjdEVzQ6" name=""/>

and I see further dangling associations/generalizations/dependencies.

Apparently the cleanup of associations on removal of participant classes is not working as it should.
Or did you hand edit the XMI file?
Comment 5 Skip Huffman 2012-02-01 21:05:45 UTC
Nope, no hand editing.  That is the XMI file produced by Umbrello.  

I did edit the model beforehand for clarity, removing all extraneous diagrams and classes.  But that was all from within Umbrello.  The XMI is exactly as produced by Umbrello.
Comment 6 Skip Huffman 2012-02-02 18:36:54 UTC
Another oddity has cropped up.  In my exported code many of the classes now have a dependency on a library called "Undef" which I certainly have never used.
Comment 7 Oliver Kellogg 2012-02-03 23:11:21 UTC
Created attachment 68474 [details]
very simple demo XMI, original version

(In reply to comment #5)
> Nope, no hand editing.  That is the XMI file produced by Umbrello.  
> 
> I did edit the model beforehand for clarity, removing all extraneous diagrams
> and classes.  But that was all from within Umbrello.  The XMI is exactly as
> produced by Umbrello.

I can reproduce this:
In the demo file attached, there are classes A, B_will_be_removed, and C.
Further, there are two associations,
- "assoc_between_A_and_B" between A and B_will_be_removed,
- "assoc_between_A_and_C_will_be_removed" between A and C.
(text is continued in next attachment)
Comment 8 Oliver Kellogg 2012-02-03 23:21:51 UTC
Created attachment 68475 [details]
previously attached model after deletions

This file is a modification of the previous attachment:
- Class B_will_be_removed was removed using right-mouse-button "Delete" in the tree view
- Association assoc_between_A_and_C_will_be_removed was removed in the diagram area using right-mouse-button "Delete" after selecting the association

The XMI still contains

<UML:Association visibility="public" isSpecification="false" namespace="Logical View" xmi.id="XnIYsvMtysVJ" name="assoc_between_A_and_B" >

although class "B_will_be_removed" was removed.

(The other test, namely the deletion of association assoc_between_A_and_C_will_be_removed, seems to have been successful as this <UML:Association> is no longer in the file.)
Comment 9 Oliver Kellogg 2012-02-12 12:37:35 UTC
(In reply to comment #4)
> [...]
> However, this class (xmi.id="hLB5tjdEVzQ6") has a few dangling dependencies to
> classes not contained in the file,
> [...]
> and I see further dangling associations/generalizations/dependencies.

To be precise, running http://uml.sourceforge.net/developers/ducheck.sh
on your attachment 68396 [details] yields:

$ ducheck.sh bug293042-att68396-temp.xmi 
dangling ref "HXlrwGZbDgpX" in line: 277
dangling ref "U8uSDGx9nOlJ" in line: 209 227
dangling ref "33ggVf38NIOa" in line: 283
dangling ref "kFgW6wFNUyEO" in line: 289
dangling ref "CnzORnvSob8H" in line: 295
dangling ref "gmBSFhoPEarb" in line: 221 226
dangling ref "tMCZ0w1dneni" in line: 227 233
dangling ref "z0Emb5xhbI1j" in line: 171 176 182
dangling ref "wyZjp3CVZTW0" in line: 99 105 110
dangling ref "D0TxuePqawZP" in line: 122
dangling ref "GBQbSm9Czoj6" in line: 271
dangling ref "3cofBiIRpMpa" in line: 250
dangling ref "tyz8MNY1QFG4" in line: 153 158 164 192 197
dangling ref "tvlhAYwbkCeL" in line: 208 214 220
dangling ref "8eYrDspQ6bqh" in line: 116
dangling ref "Vihz7ELPD9fU" in line: 270 276 282 288 294 300
dangling ref "DSsrOcwKg7Bn" in line: 301
dangling ref "fcAQQi3bRXc3" in line: 234 240
dangling ref "YjYJzFEmQceA" in line: 98 104 111 117 123
dangling ref "Wqys6oFQqHaT" in line: 215 225
dangling ref "X7iX3jBoOwXC" in line: 225 226 239 248 250
dangling ref "r7wt4pJOXMw5" in line: 165 183
dangling ref "RfQZdrlB4cAx" in line: 248

> Apparently the cleanup of associations on removal of participant classes
> is not working as it should.

I will try to review the Umbrello source code with an eye to this.
Comment 10 Oliver Kellogg 2012-02-15 05:33:09 UTC
*** Bug 256716 has been marked as a duplicate of this bug. ***
Comment 11 Oliver Kellogg 2012-02-16 17:21:23 UTC
(In reply to comment #6)
> Another oddity has cropped up.  In my exported code many of the classes now
> have a dependency on a library called "Undef" which I certainly have never
> used.

Yes, Umbrello creates this "undef" type as a placeholder when dangling <UML:AssociationEnd>s are loaded.
I take the liberty of renaming this bug according to my findings.
Comment 12 Oliver Kellogg 2012-03-04 11:52:52 UTC
SVN commit 1283458 by okellogg:

umbrello/umlcanvasobject.cpp
- removeAssociationEnd(): Call UMLDoc:removeAssociation() on the assoc.

umbrello/umldoc.cpp
- removeUMLObject(): Remove associations that this object may participate in.



 M  +5 -4      umlcanvasobject.cpp  
 M  +31 -0     umldoc.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1283458
Comment 13 Ralf Habacker 2013-11-06 17:19:37 UTC
apply fixed bug from 4.9.0 changelog