UML class diagrams show the classes of a system, their interrelationships, and the operations and attributes of the classes. They are used to

1. ■ explore domain concepts in the form of a domain model,

2. ■ analyze requirements in the form of a conceptual/analysis model,

3. ■ depict the detailed design of object-oriented or object-based software.

A class model comprises one or more class diagrams and the supporting specifications that describe model elements, including classes, relationships between classes, and interfaces.

General Guidelines

Because UML class diagrams are used for a variety of purposes—from understanding your requirements to describing your detailed design—you will need to apply a different style in each circumstance. This section describes style guidelines pertaining to different types of class diagrams.

Identify Responsibilities on Domain Class Models

When creating a domain class diagram, often as part of your requirements modeling efforts, focus on identifying responsibilities for classes instead of on specific attributes or operations. For example, the Invoice class is responsible for providing its total, but whether it maintains this as an attribute or simply calculates it at request time is a design decision that you'll make later.

There is some disagreement about this guideline because it implies that you should be taking a responsibility-driven approach to development. Craig Larman (2002) suggests a data-driven approach, where you start domain models by identifying only data attributes, resulting in a model that is little different from a logical data model.