how to interpret model validation message

[RainerQ]

Hi

what is it, EA wants to tell me with the following message:

MVR090001 - warning (UpdateClientThread (Class)): Attribute/AssociationEnd mismatch, updateFileList: Type (List<UpdateFile>/UpdateFile),  Containment (Not Specified/Reference),  Multiplicity (1/*)      

I assume I have done something wrong with the aggregation between the "UpdateClientThread" class and the "UpdateFile" class on my class diagram...

Thanks for help.

Regards
Rainer

[Geert Bellekens]

Rainer,

I'm afraid EA actually keeps two copies of the relationship in your model, the association, and the attribute.
I guess you'll have to make sure the properties on the associationEnd match the properties on the attribute.
Seems like the type, the containment and the multiplicity don't match.

Geert

[RainerQ]

Hi Geert,

thanks for your answer, but I am afraid I don't understand it.

Let me describe a little the related part of my model:

there are two reverse engineered C# classes:
- UpdateClientThread
- UpdateFile

UpdateClientThread has a field updateFileList:
private List<UpdateFile> updateFileList;

In EA I have set the collection class for association roles to List<#TYPE#>.

I placed both classes on a class diagram. Here is the first thing which confused me a little. I would have expected EA to recognize the aggregation between UpdateClientThread and UpdateFile.

Since that was not the case I manually added the aggregation and set the aggregation properties.
Source:
Name : updateFileList
Multiplicity : * since there can be many UpdateFiles in the
                     updateFileList.

Target :
Multiplicity : 1 because there will always be exactly one UpdateClientThread.

Obviously all this "doing" must have a mistake in it.

Regards
Rainer

[Geert Bellekens]

Rainer,

Did you create an aggregation, or an association with the aggregationType set to shared/composite ?
For some bizar reason those two are different things in EA, so they might behave differently.

You could also try to draw the association/aggregation the other way around (making UpdateClientThread the source and UpdateFile the target)

EA still seems to make a distinction between source/target of an association, although in UML there is no such notion for associations.

Geert

[RainerQ]

Hi Geert,

I created the aggregation by drawing a composition to the from the UpdateClientThread towards UpdateFile class.

Note : in the Options->Links I have checked the "Draw Aggregations Reversed" since that is how I look at the things ;-)

Regards

[Geert Bellekens]

Yes, I guess that is how most of us naturally draw compositions.
But the thing is that EA will still make the UpdateFile class the source, and UpdateClientThread class the target.
I wonder what happens if you switch source and target, or if you use a regular association with aggregation property set to composite.

Geert

[RainerQ]

I have now switched the sourc/target multipicity. I still get a warning:

MVR090001 - warning (UpdateClientThread (Class)): Attribute/AssociationEnd mismatch, updateFileList: Type (List<UpdateFile>/UpdateFile),  Containment (Not Specified/Reference)      

before it was:
MVR090001 - warning (UpdateClientThread (Class)): Attribute/AssociationEnd mismatch, updateFileList: Type (List<UpdateFile>/UpdateFile),  Containment (Not Specified/Reference),  Multiplicity (1/*)      

The following are common:
- Attribute/AssociationEnd mismatch
- updateFileList: Type (List<UpdateFile>/UpdateFile)
- Containment (Not Specified/Reference)

Regards
Rainer

[Geert Bellekens]

Containment should be pretty easy to solve, this property is available both on the association end as on the attribute.

The other conflict (Type) I'm not sure.
I'm afraid EA can't really handle the generic List<> type in reverse engineering.
You could try to set the type of the attribute to UpdatFile, adjust the multiplicity and define the container type in the attribute's details tab.
EA might just generate the correct source then.

Geert

[RainerQ]

Hi Geert,

thanks for your help.
I now have 0 error(s) 0 warning(s) but...

With type conflict I did as you suggested and changed the attributs type to UpdateFile and on its details I checked the "Attribute is a collection" and for the container type I entered "List". Unfortunately the generated code is not correct. I endup with:
private UpdateFile List updateFileList;

but it should be
private List<UpdateFile> updateFileList;

It looks that I have to live EA waring but then at least the code stays compilable...

Regards
Rainer

Regards
Rainer

[Geert Bellekens]

Might be a good idea to send (another) change request to support generics in (reverse) code engineering.
If enough people ask for it they might just be tempted to implement it (sooner)

Geert

[RainerQ]

Hi Geert,

I think I will do so. Thanks for your help!

Regards
Rainer