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 motivation here is to give enough flexibility to the customer so that they can build the class diagram to suit their needs.