Checklist for a class diagram describing a system domain model

The following checklist can be used to help check the validity of basic class diagrams. It can't be relied on completely, but at least if you focus on these items, you will avoid common mistakes.

This list assumes you have been asked to create a class diagram for the domain model of a system, containing classes, associations, attributes and generalizations. It does not consider operations/methods, etc. Since interfaces describe sets of operations, it does not consider those either. It also does not consider user interface classes or other architectural classes.

Items marked with ** are the ones you should check if you are in a hurry, since these are the biggest source of mistakes that are quick to correct.

A. Valid and appropriate classes

1. Have you added all needed classes from the requirements (mostly they appear as nouns)? Cross them off in the requirements when you have accounted for them.
2. Are all class names written in the singular and starting with a capital letter? **
3. Have you avoided using such naming elements as 'data', 'record', or 'info'? **
4. Where a name could have multiple related meanings, have you named each class so its meaning can be precisely understood? **
5. Have you considered cases where there are two or more names for the same thing, and created just a single class? **
6. Have you avoided classes representing user interface elements or architectural elements, since you are creating only a system domain model? **
7. Have you included only classes for which data will actually need to be stored or manipulated? Delete any others. **

B. Valid and appropriate associations

1. Have you added all needed associations from the requirements? Cross off appropriate phrases in the requirements when you have accounted for them.
2. Do all associations have multiplicity at both ends? **
3. Have you read the associations in both directions and thought about the correctness? **
4. Have you looked extremely carefully at associations with a '1' end to be absolutely certain that having an associated object is always needed at all times? **
5. Do you have any 1--1 associations? These are exceedingly rare, and usually incorrect. For a 1--1 association there must always be the same number of instances of each class and they must be organized in pairs.
6. Is it correct that any unlabelled associations can be read as 'has'? If not, add role names to clarify the meanings of one or both ends?
7. Do you have any association classes? Have you followed the correct pattern for them (1 X -- * AC; 1 Y -- * AC;)?
8. Do you have any reflexive associations? If have you checked to ensure lower bound at both ends is 0? Have you checked that there are role names on asymmetric reflexive associations, and a single association name on symmetric ones?
9. Do you have any classes that should be split into an 'Abstraction' and an 'Occurrence' class using a * -- 1 association?
10. Have you handled any situations where you need to have a class for a category or type of thing as well as a class for the associated things?
11. Does your model have any instance hierarchies (e.g. organization chart, folder hierarchy, category hierarchy) and if so have you used either an asymmetric reflexive association or the general hierarchy (composite) pattern?
12. Have you avoided situations where you have shown something both as an association and an attribute, or specified the 'implementation' of an association as attributes? (e.g. a List, where you already have an association).
13. Do role names start with lower case letters and have a meaning that is a role the class plays?
14. If you have directed associations (arrows), have you checked that they are correct?
15. If you have used the open diamond to specify an aggregation, is this really the 'whole' end of a proper part-whole relationship? When in doubt leave out the diamond. **
16. If you have used a filled-in diamond to specify a composition, is this really the 'whole' end of a proper relationship where the part(s) must be destroyed when the whole is?
17. Have you avoided associations that should be operations (e.g. 'borrow' and 'return' associations when you should in fact have an association to a single 'Loan' class'?
18. Do you have a class representing the company or organization itself? If so, is this needed, is it a singleton, and do any associations from this have '1' as the upper bound?
19. Do you have a class representing end users of the system? If so are you actually storing data about users? If not, delete such classes.

C. Valid and appropriate attributes

1. Have you added all needed attributes?
2. If there are classes that need some form of identification, have you added an 'id' or 'name' attribute, even if not explicit in the requirements? **
3. Do the attributes represent simple data that each instance must have (String, Integer, Float, Date, Time, Boolean etc.)? You can also use other very simple classes you create as an attribute type, but it is suggested you use associations instead. **
4. Have you avoided plural attributes in most cases? It is best to use associations instead.

D. Valid and appropriate generalization and inheritance

1. Have you used the proper open triangle symbol, pointing to the superclass? **
2. Have you avoided multiplicity on generalizations? **
3. Does the 'isa rule' apply between all subclasses and their superclass? **
4. Does everything in each superclass also apply to every one of its subclasses? This applies to everything that inherits including attributes, associations, and even operations (even though you are not showing them). **
5. Have you avoided situations where an instance would need to change class? Delete such classes and use an attribute in the superclass or an associated role class. **
6. Have you avoided situations where there are several subclasses that would not be meaningfully different? i.e, with the same attributes, operations or associations as each other or the superclass? Delete such classes, and use an attribute in the superlass. **
7. Have you searched for situations where there are classes that are similar and created a superclass for the common elements?
8. Have you avoided multiple inheritance unless you know it is supported by the target programming language, and would not lead to excessive complexity?

E. Overall evaluation

1. Do you have any classes with huge numbers of attributes (>10) or associations (>5)? If so, consider splitting such classes into a superclass and a subclass.
2. Have you made your model as general as you can, avoiding aspects that would need to be changed if the organization or business changed? For example, avoid using the names of specific products, organizational units, etc.
3. Can you see any ways to simplify your model in any way?