The problem is identical in C++.
If you import a class with an attribut of type QList<SimpleBean>, Umbrello doesn't draw any association.

But IMHO the problem isn't with the import.
You can design a class ComplexBean in Umbrello with a attribut of type List<SimpleBean>. The aggregation isn't drawn.

Perhaps the problem is with the function UMLView::createAutoAttributeAssociations that doesn't handle such a case.
As you said, List<SimpleBean> is identified as a new data type.

A quick and dirty hack could update this function.
When the attribute type matches the pattern A<B>, the updated function may look for types B in the current diagram instead of looking for A<B> in the current diagram.

Is this solution OK ? 

 

> Perhaps the problem is with the function
> UMLView::createAutoAttributeAssociations that doesn't handle
> such a case.

Yes, that could work.
You would need to analyze the name of each UMLDataType encountered
while iterating over the attributes of the class: Take apart the
"<template_param>" syntax, search the model for each of the
template params, and generate a Dependency to the UMLAttribute found.

Created an attachment (id=19935) [details]
patch for #140669

This patch is against branches/3.5, I haven't tested it in trunk.

Now, if one class (ComplexBean) has list of SimpleBeans (List<SimpleBean>),
umbrello draws a relationship between SimpleBean and ComplexBean classes. 
It works also with C++.
This patch also adds a data type  "List<SimpleBean>" and a class "List" in the
logical view when you add an attribute List<SimpleBean> inside the umbrello
designer. Before in such a case, a class List<SimpleBean> was added.

C++ namespaces and Java packages are better handled when you add an attribute
with namespaces or package inside the umbrello designer.

> This patch is against branches/3.5, I haven't tested it in trunk. 
 
Nice work.

> Now, if one class (ComplexBean) has list of SimpleBeans (List<SimpleBean>),
> umbrello draws a relationship between SimpleBean and ComplexBean classes.

You draw the relationship as composition/aggregation.
However, on generating code, this means that an extra member of type
SimpleBean will be created in ComplexBean.
(The aggregation/composition is already drawn correctly to the datatype
"List<SimpleBean>".)

IMHO we would need an indication on the association that shows the
template-parameter-of relationship.
IMHO we could create a Dependency instead of Aggregation/Composition.

 

>However, on generating code, this means that an extra member of type
>SimpleBean will be created in ComplexBean. 
No, because this composition/agregation is added in the view (UMLView) not in the concept (Classifier).
I have tested it, no extra member is generated.

>IMHO we could create a Dependency instead of Aggregation/Composition.
I will try to have a look at it but I won't be able to do it before few weeks. 


 

> No, because this composition/agregation is added in the view (UMLView)
> not in the concept (Classifier).

Ah, okay. I overlooked that.
It's interesting that this usage survives a save/load cycle.
Anyway, I'm adding the parsing of template instantiations and creation
of UMLAssociation(at_Dependency) at Import_Utils::createUMLObject().

SVN commit 643026 by okellogg:

Apply attachment 19935 [details] from Antoine Dopffer with enhancement of Import_Utils::
createUMLObject() for creating UMLAssociation(at_Dependency) from the related
classifier to known classifiers mentioned in a template instantiation.
FEATURE:140669


 M  +1 -0      ChangeLog  
 M  +68 -0     umbrello/attribute.cpp  
 M  +13 -0     umbrello/attribute.h  
 M  +50 -7     umbrello/codeimport/import_utils.cpp  
 M  +6 -0      umbrello/codeimport/import_utils.h  
 M  +14 -5     umbrello/dialogs/umlattributedialog.cpp  
 M  +49 -35    umbrello/umlview.cpp  
 M  +10 -0     umbrello/umlview.h