Short lived and long lived Class Diagrams

  • [アーティクル]

While building the Class Designer we envisioned two scenarios where a developer would create a class diagram for an existing project.

In the first scenario, the diagrams are short-lived. In this case, a developer may want to gain understanding of some piece of code that they didn't develop. So, to begin with they auto generate the diagram from the code. Unless it is a simple project, it is likely that the diagram is cluttered because of the number of classes and their members. As one team member put it, they would want the ability to quickly hide information on the generated diagram (probably coarse-grained) to reduce the clutter, so that they can “see the wood from the trees”. Here, the diagram they create is probably going to get thrown away or kept only for the developer who created it to quickly understand the piece of the project they are interested in.

In the second scenario, the diagrams are long-lived. In this case, the developer is spending a lot of time and effort in creating the diagram and laying out the shapes. Here the diagram is intended to be part of the documentation of the code and to communicate the design to others. Here they probably want fine-grained mechanisms to fine tune the diagram so that the diagrams contain the right information that they want to communicate.

We provide a few mechanisms to reduce clutter by hiding information.

  • The first is the expand/collapse capability. In the class diagram image posted here you can see that there are individual compartments for different member “kind” (Fields/Properties/Methods/Events). Clicking on the “+/-” button on the compartment headers will either expand or collapse the compartment. For example, the “Methods” compartment in the XmlNode class is collapsed and all the methods in the class are hidden from the diagram. Similarly the “chevron“ icon to the far right of the class name can be used to expand/collapse the entire shape. One can also choose to view the members of the classes shown in the diagram by access modifiers (or visibility in UML terms), i.e, members will be grouped by Public/Protected/Private etc and these compartments can be expanded or collapsed. This is part of the coarse-grained mechanism to hide information so that the developer can quickly hide the information.
  • The second mechanism provided to reduce clutter is by individually hiding a member in a class. Of course, there will be a mechanism to bring the member back on the diagram as well. This is more a fine-grained mechanism available so that the developer can “customize“ the diagram to communicate some aspect of their code. For example, a class may implement multiple interfaces and they want to create a diagram to show the members of one or two of the several interfaces that the class implements.
  • Another way to reduce clutter is to visualize a Property or a Field as an Association. In Class Designer, if you have a Property that is of a particular user defined type, you can choose to view that either as an item in the Properties compartment or as an association line to that type. In the image posted here, you see an association line drawn from XmlDocument to XmlNodeType with the label “NodeType“. Here the developer wanted to visualize the property NodeType as an association line. However, the “NodeType“ property in the class XmlDocumentType is shown as an item in the Properties compartment.

The motivation here is to give enough flexibility to the customer so that they can build the class diagram to suit their needs.

Cheers,

Ramesh.

Comments

  • Anonymous
    March 27, 2004
    I've been following some of the Whitehorse discussions, and there's one usage for the class diagrams that isn't as obvious.I'm looking for a way to provide other developers "pretty" (i.e. visually useful) diagrams of our class hierarchy and object model.  ...