Handling UML class diagram of a large class in a document for printing

Question

I am currently writing a formal document in which I should place a specific UML class diagram.

The class has about 30 members, and roughly the same amount of methods. When I create a class diagram using any tool, it makes it a really long list - over 60 lines. It simply doesn't fit on a single page (I need the document printed).

Redesigning the class is out of the question.

How should I handle this problem? I have two ideas:

1. Split the diagram - make one diagram for data members, and second one for methods.
2. Make the diagram in two columns - one column for data members, and second one for methods.

Would such diagrams still be technically correct? I am unsure whether that would still make a valid UML.

Answer 1

There are tools that you can use to hide members of a class. I think Rational System Architect supports this and surely Sparx Enterprise Architect does. With such a tool I would create two diagrams, one displaying the members only (and a collapsed methods part) and one displaying the methods only (and a collapsed members part). Something like:

+--------------------+
| SomeClass          |
+--------------------+
| methods            |
+--------------------+
| +DateOfBirth: Date |
| +Name : String     |
| …                  |
+--------------------+

+----------------------------+
| SomeClass                  |
+----------------------------+
| members                    |
+----------------------------+
| +void Say(String message)  |
| +void Sleep(TimeSpan time) |
| …                          |
+----------------------------+

If you want to be sure the readers of the documents understand the meaning of your diagrams you could drop a line explaining why you hid parts of the class.

Answer 2

Several things can be done here.

First, divide fields from methods. There are other classes on the diagram, too, and if an attribute is shown by an arrow, you needn't put it simultaneously into the class block. That is absolutely standard trick.

Second, you could hide methods and other fields and show the class as and empty block with name only, change the color for it, to see it better, put a note about the next diagram and make this second diagram, that will consist of this class only.

You can stop on it. But other steps are possible.

As creating huge classes diagrams and diagrams after code is NOT standard at any rate, I wouldn't try to look more saint that I am and I would break other standards a bit.

Instead the second step I would draw dependencies to the return classes of functions and write functions' names with parameter lists on them.

So, your class will have in its block only members of standard types. Other members will create many connections and that number of connection will need the class block to be large - you need the place to connect all ends.

Of course, you can combine that with the separate diagram.

Answer 3

You might decide to only show public members / methods, if your tool supports that. Or hide trivial stuff like standard getters and setters. (Drop a note about what's hidden, as others indicated already) The goal should be to give the reader the insight of what run state the instances hold and which are the important operations that one can do with them.

If you had code access, it would be useful to do some refactoring, e.g. either split up the class into smaller chunks, or introduce a façade (leaving the original class untouched). I understand this does not apply to your specific case but it might help others, as it is a common modeling problem.