Identify responsibilities on domain class models.
Indicate visibility only on design models.
Indicate language-dependent visibility with property strings.
Indicate types on analysis models only when the type is an actual requirement.
Be consistent with attribute names and types.
Model association classes on analysis diagrams.
Center the dashed line of an association class.
Use common terminology for class names.
Prefer complete singular nouns for class names.
Name operations with a strong verb.
Name attributes with a domain-based noun.
Do not model scaffolding code.
Do not model keys.
Never show classes with just two compartments.
Label uncommon class compartments.
Include an ellipsis ( . . . ) at the end of incomplete lists.
List static operations/attributes before instance operations/attributes.
List operations/attributes in decreasing visibility.
For parameters that are objects, list only their type.
Develop consistent operation and attribute signatures.
Avoid stereotypes implied by language naming conventions.
Indicate exceptions in an operation’s property string.
Reflect implementation language constraints in interface definitions.
Name interfaces according to language naming conventions.
Prefer “lollipop” notation to indicate realization of an interface.
Define interfaces separately from your classes.
Do not model the operations and attributes of interfaces in your classes.
Model collaboration between two elements only when they have a relationship.
Model a dependency when the relationship is transitory.
Tree-rout similar relationships to a common class.
Always indicate the multiplicity.
Avoid a multiplicity of “*”.
Replace relationship lines with attribute types.
Do not model implied relationships.
Do not model every dependency.
Center names on associations.
Write concise association names in active voice.
Indicate directionality to clarify an association name.
Name unidirectional associations in the same direction.
Word association names left to right.
Indicate role names when multiple associations between two classes exist.
Indicate role names on recursive associations.
Make associations bi-directional only when collaboration occurs in both directions.
Redraw inherited associations only when something changes.
Question multiplicities involving minimums and maximums.
Apply the sentence rule for inheritance.
Place subclasses below superclasses.
Beware of data-based inheritance.
A subclass should inherit everything.
Be interested in both the whole and the part.
Place the whole to the left of the part.
Apply composition to aggregates of physical items.
Apply composition when the parts share their persistence life cycle with the whole.
Don’t worry about the diamonds.