Days of …

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.

Do not name associations that have association classes.

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 relationships horizontally.

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.

Apply the sentence rule for aggregation.

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.

Name use cases using domain terminology.

Imply timing considerations by stacking use cases.

Place your primary actor(s) in the top-left corner of the diagram.

Draw actors on the outside edges of a use case diagram.

Name actors with singular, domain-relevant nouns.

Associate each actor with one or more use cases.

Name actors to model roles, not job titles.

Use > to indicate system actors.

Don’t allow actors to interact with one another.

Introduce an actor called “time” to initiate scheduled events.

Indicate an association between an actor and a use case if the actor appears within the use case logic.

Avoid arrowheads on actor-use case relationships.

Apply > when you know exactly when to invoke the use case.

Apply > when a use case may be invoked across several use case steps.

Apply > associations sparingly.

Generalize use cases when a single condition results in significantly new business logic.

Do not apply >, >, or >.

Avoid more than two levels of use case associations.

Place an included use case to the right of the invoking use case.

Place an extending use case below the parent use case.

Apply the “is like” rule to use case generalization.

Place an inheriting use case below the base use case.

Apply the “is like” rule to actor inheritance.

Place an inheriting actor below the parent actor.

Indicate release scope with a system boundary box.

Avoid meaningless system boundary boxes.