Expressing relationships between types


I believe one of the strongest things going for class diagrams is being able to holistically look at a collection of types and see how they’re related.  In other words, it’s not just about getting shapes on a diagram but about the lines that connect them.  So I’m always interested in learning more about the kinds of relationships, or lines, users try to express on class diagrams.

To date, the VS Class Designer supports visualizing two kinds of relationships: 1) inheritance lines, and 2) association lines on fields and properties.

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

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

I’ve seen other types of lines on class diagrams, such as dependency lines, to signify for example that one particular class instantiates/calls another class.  Another scenario might be to show a method’s parameter type as a relationship.  These latter cases aren’t supported in VS2005 and I’d like to get a feel for how prevalent these and other relationship kinds are on class diagrams. 

We’ve seen feedback reported on this issue through the MSDN Feedback Center – I wonder if anyone else would like to share their thoughts.

Regards,

John Stallo

VS Class Designer Program Manager


Comments (10)

  1. John Lewicki says:

    I think this is a big usability gap in the tool; I also opened a suggestion about this back in July:

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=c2deace8-197f-458a-b659-67d56cb7f54d

    I use these types of relationships on diagrams all the time.

    Its good to know that this is at least on the radar screen of you folks as MS…

  2. Chris says:

    Express relationships? YES, YES, YES, YES.

  3. Mike Lorengo says:

    I agree with John Lewicki

    I like to show a —–> Depends relationship as well as a ——> Uses relationship. Another relationship that I feel is missing i the Realization or Implementation of an Interface

    I really like VS 2005, but until better support is offered, I’m stuck using XDE.Net

  4. First of all an assumption, class designer is a design tool, not a conceptual modeling tool.

    As a design tool I want class designer to represent only those things that affect the code generated from it, and vice versa. As much as can be code generated I want class designer to represent.

    UML (for example) suppports a wide variety of association adornments for cardinality, visibility, aggregation, and so on. I need these when conceptualising because I want to express I wide range on information in the diagrams, where there might be a wide variety of different implementations.

    When looking at life-cycle management I also want tracability reletionships so I can visualise the temporal relationships between elements modelled at different levels of abstraction, and at different parts of the development timeline.

    When looking at deployment and coupling I want dependency relationships so that I can understand what will be impacted by changes to my interface.

    That said if dependency relationships can code generate import statements then this may fit the design viewpoint.

    Taking the DSL idea these are different languages to support different viewpoints of the project. So i’d support keeping the class designer focused on design and code-generation, and hope that the other problems have the appropreste DSL available.

    By keeping Class design tightly coupled to the language implementation and code generation, then it also becomes a reference for what it is possible to write/code generate. This reenforces understanding of both designer and language.

  5. 247Blogging says:

    I believe one of the strongest things going for class diagrams is being able to holistically look at a collection of types and see how they’re related . In other words, it’s not just about getting shapes on a diagram but about the lines that connect them

  6. Dating says:

    I believe one of the strongest things going for class diagrams is being able to holistically look at a collection of types and see how they’re related . In other words, it’s not just about getting shapes on a diagram but about the lines that connect them