Splitting up a UML Class Diagram?

Question

So I have to make a class diagram for a Unity game I made as part of a project.

Trouble is I have to make a class for every script, of which there are 60.

The guidelines given to me simply states: Create a class diagram of your game.

So should I be splitting this up into several different class diagrams or literally just one inevitably disgusting 60 class diagram?

Answer 1

Your guidelines already told you what to do for this project: "Create a class diagram of your game." If this is a class project, create a single horse blanket, make your professor happy, and get a good grade.

However, on a real-world project, you should create many micro-subject-area diagrams for your audience. Review with each person only the diagrams that matter to them. That's how you (and your victims) can survive very large projects.

To create micro-subject-area diagrams, create a set of diagrams, each containing 7 ± 3 classes. Every class has only one fully-defining diagram showing all of its compartments and associations. Everywhere else, the class should appear only with its class name (to help define other classes) and a hyperlink. The hyperlink makes it work like an edge connector that takes you to its fully-defining diagram. (If you use MagicDraw, there is a free plug-in available, called AutoStyler, that automates this.)

Answer 2

It is legitimate to split up class diagrams, as class diagrams are meant to clarify things, which a gigantic mega class diagram arguably does not do. As such, class diagrams should usually concentrate on a few specific aspects that you want to show:

• Do you want to provide a detailed structural representation of a given set of classes? If so, only depict these classes with all members, but skip any other classes (e.g., do not draw them as class nodes, but instead just mention their names as member/parameter types where appropriate).
• Do you want to provide the class structure related to a particular functionality? If so, draw the relevant set of classes, but skip irrelevant members (e.g. members that have to be there for the sake of infrastructure support, but that are not a part of the actual business logic you are focusing on).
• etc.

Now, when there is any expectation of completeness rather than a mere overview, it needs to be clear what parts of the diagram are complete and which ones are abbreviated. Again, this is possible in various ways:

• As in the first bullet item above, mentioning a type name without drawing it is a clear indication that there is another type that is not depicted in the current diagram, without making the depicted class incomplete.
• Alternatively, you can make use of "natural boundaries by abstraction" in your code: If you use classes from an extensive hierarchy, it may be sufficient to draw only the base class, or a few general base classes, in one diagram, while detailing the actual class hierarchy (without any of the context from the other diagram) in a separate diagram.

Two remarks on your specific question:

• In your case, "60 scripts" sounds like various of them may easily fall into the last case, allowing you to separate overall architectural diagrams from a class hierarchy diagram.
• You say there are "guidelines". If this is for some kind of competition or for any other kind of evaluation (e.g., for studying), take all this advice with caution: Internal grading guidelines might not necessarily be congruent with what would be practical/useful in an actual project.

Answer 3

tl;dr

• Create as many class diagrams as you need
• Avoid wallpaper diagrams only
• Create wallpaper diagrams, though. But assemble them from existing diagrams.
• Try to spot sub-domains (things that belong together) and place them in one diagram