[Uml-devel] [Bug 117875] Imported C++ classes not saved correctly in the XMI file

Maciej Puzio maciek at work.swmed.edu
Tue Dec 13 23:29:02 UTC 2005


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=117875         




------- Additional Comments From maciek work swmed edu  2005-12-14 01:41 -------
I have found two bugs in Umbrello that were causing the behavior that I described in this report. I have fixed these bugs and tested the program (patches attached).

The bugs were surfacing because of the sequence of class declarations in zCDataTypes.H. Several classes are declared as part of namespace zMol, first by forward declarations, and then by full class declarations (e.g. class zCAnySpaceData). As a result of 2 bugs that I've found, these classes were not correctly included in programs's data structures, and resultantly were omitted from the XMI file during the save operation. Below are the details.

The direct reason why some classes were not saved was that they had the package attribute (UMLObject::m_pUMLPackage) set correctly to the name of the namespace in which they were declared, but did not belong to the list of children of that package (UMLPackage::m_objects). Because of that they were skipped in both UMLDoc::saveToXMI (umldoc.cpp line 1636), and in UMLPackage::saveToXMI (package.cpp lines 172-177, called from UMLDoc::saveToXMI, line 1656). Code in both saveToXMI methods is correct, and the problem is the m_pUMLPackage/m_objects anomaly.

That anomaly was caused by the bug in ClassImport::createUMLObject (classimport.cpp lines 167-169). Class zCAnySpaceData (and other like it) are processed through createUMLObject twice, first as a result of a forward declaration, and then as a result of a full declaration. As a result of a second bug, that I describe later, namespace was ignored for the forward declaration. During the second pass through createUMLObject, namespace was provided correctly, and this resulted in UMLObject being reassigned to a different UMLPackage. However, only UMLObject::m_pUMLPackage was assigned, and the object was not added to the UMLPackage::m_object list. That created the anomaly that was preventing object from being saved.

The patch (also attached as classimport.cpp.diff):
168c168,171
< 		o->setUMLPackage(parentPkg);
---
>             if (o->getUMLPackage())
>                 o->getUMLPackage()->removeObject(o);
>             o->setUMLPackage(parentPkg);
>             parentPkg->addObject(o);

As a side note, I am not sure that reassigning classes from one namespace to another is a correct behavior. If there are 2 identically named classes declared in 2 namespaces, they should be present in the tree as 2 distinct objects, rather than one object in the namespace that was seen last, as the code appears to be doing now.

The second bug is in CppTree2Uml::parseElaboratedTypeSpecifier (classparser/cpptree2uml.cpp, line 404). The code ignores the current namespace (m_currentNamespace[m_nsCtl], which results in class being assigned to the empty namespace (NULL). 

Patch (also attached as cpptree2uml.cpp.diff):

404c404
<     UMLObject *o = m_importer->createUMLObject( Uml::ot_Class, text );
---
>     UMLObject *o = m_importer->createUMLObject( Uml::ot_Class, text, m_currentNamespace[m_nsCnt] );

Please forgive me any deficiencies in this report; I am a newbie to Umbrello, KDE and UML. I am not sure whether I should leave this report as UNCONFIRMED (it is quite clear that the bugs exist, and where), or change it to RESOLVED. While the issue has been resolved for the copy of Umbrello that I have, the bugs persist in the publicly available release. (?)




More information about the umbrello-devel mailing list