Udostępnij za pośrednictwem


Setting up and viewing relationships between classes

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 https://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:

Expressing relationships between types: inheritance, associations, and collection associations.

Here’s the same diagram with associations:

Expressing relationships between types: inheritance, associations, and collection 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).

Expressing relationships between types: inheritance, associations, and collection associations.

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).

Expressing relationships between types: inheritance, associations, and collection associations.

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 https://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 https://blogs.msdn.com/classdesigner/archive/2005/03/16/396476.aspx. We would love to hear your opinions.

Charlotte Fallarme

Software Development Engineer

Visual Studio Class Designer Team

Comments

  • Anonymous
    March 18, 2005
    What I would like to see is "Round-Trip" class models. I need CD to capture my "older" .NET classes.
  • Anonymous
    March 19, 2005
    Chris,
    If you had implemented strongly typed collections in previous versions of .net then we will be able to recognize them as collections.

    I am not sure if I addressed your concern. In case I didn't, it would be nice if you could explain the issue with a simple example.

    Thanks.
    _Rakesh
  • Anonymous
    March 26, 2005
    I think it's great for this feature but I'm having problems with trying to get it to work with my Domain classes. All collections are implemented as an ArrayList so the designer won't let me associate say a field called Orders (of type ArrayList) to a collection of a class called Order.
  • Anonymous
    March 27, 2005
    Bil, you are correct. Unfortunately we won't be able to visualize the collected type if the collection is a collection of objects - like ArrayList. We discussed the possibility of getting this information from the user in cases like these. However, it didn't meet the bar for V1.

    Ramesh.
  • Anonymous
    April 04, 2005
    The comment has been removed
  • Anonymous
    May 19, 2008
    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
  • Anonymous
    May 19, 2008
    PingBack from http://247blogging.info/story.php?title=ClassDesigners-WebLog-Setting-up-and-viewing-relationships-between-classes