Version: (using KDE Devel) Installed from: Compiled sources Code import currently creates aggregations/compositions for members whose type it can resolve. This is not necessary, and can actually be bothering. Instead, create attributes for all data members. Resolve the types of the attributes, and determine whether a pointer is involved. On dragging imported classes from the list view to the diagram, do as follows: - If the class representing the type of an attribute is not present on the diagram then display the attribute in the class' attribute compartment. - If the class representing the type of an attribute is present on the diagram then do not display that attribute in the class' attribute compartment. Instead, display an appropriate association (composition or aggregation depending on whether a pointer is involved.) Implementation note: This implies that 1) the m_pObject of an AssociationWidget may also be a UMLAttribute 2) the type of an UMLAttribute is a pointer to a model class (not just a string)
A sneak preview is possible now. Import the following file: // attribute_assoc_demo.h class referenced { public: referenced() {} }; typedef referenced* refPtr; class referencer { public: referenced * getCrudeRef() { return m_pCrude; } refPtr getTypedefRef() { return m_pTypedef; } private: referenced *m_pCrude; refPtr m_pTypedef; }; An AssocWidget is made for m_pCrude, but not yet for m_pTypedef. The load/save of the new originType() and isReference() features of UMLDatatype isn't there yet.
*** Bug has been marked as fixed ***.