Collections as Properties

[Matt Edwards]

As a part of our SOA strategy we have developed several thousand C# classes and interfaces that define our service contracts and message schemas. These are all very consistent in their use of generic lists, List<#TYPE#>, for all collections, and expose all of these collections as properties. I have been able to successfully reverse engineer these properties into the model, but the collection classes are not correctly translated into aggregation/composition relationships – they just appear as operations with no direct link to the underlying type. We need these links to visualize the relationships between entity classes and to enable full traceability between these entities.

Likewise, I seem to be having difficulty generating collection class properties from aggregation/composition relationships. What I get are fields instead of properties, which isn’t surprising considering there do not appear to be any options to control property handling from the aggregation/composition link. This seems quite fundamental, am I missing something? We are still using EA 7.0.

[«Midnight»]

Hi Matt,

Just a wild guess here...

Can you use Import Binary Module to capture the 'live' classes? If so, what happens if you then do a reverse engineering exercise (to another package tree of course)? Will EA recognize the collections (etc.) as instances of the classes you previously imported?

This sometimes - and only sometimes - helps with .Net and .jar files when reversing preexisting code.

David

PS: If it will work at all - no assurances there - it is probably very sensitive to namespace root settings. If the results seem strange (versus just plain failure) when you first try this, play around with namespace settings (see the EA docs) a bit to see if things fall into line.