Question

I am using Sparx EA (current version) to reverse engineer a simple little test solution to a class diagram (C# if it matters). There are just two classes. Test1 and Test2. Test1 has a property;

public List<Test2> test2list { get; set; }

Based on that property, I would expect EA to infer that the two classes are related and update the diagrams accordingly, but it does not.. I just get two classes and have to manually link them..

Is there some way to get EA to recognize the relationships?

Answer 1

First off, I think the discussion in the question comments highlights the underlying problem: there is no consensus as to which relationships in UML correspond to which constructs in implementation language X.

Put another way, there are no standardized UML profiles for the most common implementation languages. (There is a very old one for Java, but it’s obsolete.) I consider this one of the great failings of UML, not an issue in any specific tool.

To answer the question: no, EA does not infer dependencies or usages in this case. But the problem here is deeper: EA doesn’t resolve template types correctly.

Expanding on your example, consider these four cases:

public List<Test2> test2ListProp { get; set; }
public List<Test2> test2ListAttr;
public Test2 test2SingleProp { get; set; }
public Test2 test2SingleAttr;

EA recognizes the properties, which it represents as operations — not attributes. It does not create any connectors for these. The non-property ones, on the other hand, are represented in the model both by attributes and by directed associations. Attibutes and directed associations used this way are semantically equivalent in UML, but the same does not hold for operations.

If you now go into the model and rename Test2, you will see that EA correctly updates the names of the non-list types both in the attribute and the property, but that the others retain their List<Test2> types. So this is where it breaks; the List<Test2> type is simply a string, not a proper model reference.

You should also note that the directed association test2ListAttr has a multiplicity 0..*. This is because EA has correctly inferred that this attribute is in fact a list. This inference can be controlled in Tools – Options – C# – Additional Collection Classes.

If you now go and delete List<#TYPE#>; from that option, then create a template class List in your model and redo the import (probably a good idea to clear the model first in this case), EA will change its representation of test2ListAttr. Instead of creating a 0..* directed association to Test2, it will create a template binding to your List class, specifying Test2 as the actual parameter.

This is a proper model reference and if you change the name of Test2 the binding will be updated (you may need to reload the diagram) — in other words, this is a correct representation and if you were to generate code out of this model, it will be correct. In fact, with the options set this way and the List class pre-created, the behaviour is correct for three out of our four cases above.

However, this doesn’t solve the problem for properties whose types are template classes. Because EA represents them as operations, it can’t draw the directed associations for them, and because of that, it won’t occur to it to draw template bindings for them either. I should report this as a bug if I were you.

On a related note, you can get EA to create dependencies for operation returns and parameter types (but not for template type usage). This is set in Tools – Options – Source Code Engineering.