When I’m learning about a new program or teaching someone else about an existing one, I find it helpful to begin by identifying the key classes and seeing how they relate to each other. There are many different ways that classes can be related. Three important relationships are inheritance, association, and dependency. I’ll talk about associations and dependencies in this article. Inheritance is covered in another article titled Visualizing Inheritance Hierarchies at http://blogs.msdn.com/classdesigner/archive/2005/03/10/391292.aspx.
Here’s an example that I’ll use to explain what an association is. It begins with a class diagram of some classes in an order processing system:
Here’s the same diagram with associations:
The lines represent associations. They make it easy to see how the classes fit together. In this example, Customer is a class which has a collection of Orders. An Order can have several LineItems which are OrderDetails, etc.
In Class Designer, an association is a line drawn from a class containing a particular field to another class which is the type of the field. A property can also be shown as an association with the line ending at the type of the property. Classes, interfaces and structures (struct in C#, structure in VB, and any class deriving from System.ValueType in J#) all can have associations.
You may have noticed that my definition of association does not explain the presence of the Orders and LineItems associations in the example given earlier. Although the Customer class does not have a field or property whose type is Order, it does have a field which is a collection of Orders. So Class Designer displays it as a collection association. The collection association line is drawn to the type being collected rather than the collection type.
You can choose which type of association you want to see. Select a field or property and choose Show as Association or Show as Collection Association from the context menu (or Class Designer menu).
If you change your mind and want to see it as a field or property again, select the association line and choose Show as Field (or Show As Property) from the context menu (or Class Designer menu).
There are cases where Class Designer cannot show a collection field or property as a collection association. That’s because we cannot always determine the type of object a collection is meant to store. While technically it would be correct to draw the association line to System.Object, we opted against this as it usually is not helpful. Instead we decline to draw any collection association for which we cannot determine the type stored in the collection.
Class Designer employs some clever heuristics for determining the type in a collection. There is an excellent article describing these heuristics at http://blogs.msdn.com/r.ramesh/archive/2005/02/01/364862.aspx.
As we’ve just seen, associations are deduced from fields and properties. It could be helpful if Class Designer could deduce other relationships, particularly those known as dependencies. A class is dependent on the classes it uses. One way to see the dependencies of a particular class is to look at its method signatures. It is dependent upon the types used for parameters and return types.
Although Class Designer does not yet show dependencies, we are trying to gauge customer interest in having support for them at http://blogs.msdn.com/classdesigner/archive/2005/03/16/396476.aspx. We would love to hear your opinions.
Software Development Engineer
Visual Studio Class Designer Team