Class Diagram (UML)
A UML class diagram shows the structure of a domain as classes, the categories of objects an organisation keeps information about. Each class carries the attributes that describe it, the operations that say what can be done with it and the associations that link it to others, each association annotated with a multiplicity that fixes how many occurrences are allowed at each of its ends. It is the data-modelling notation of object-oriented design: where the entity-relationship diagram serves the schema of a relational database, the class diagram serves the structure of a piece of software, and it is the only one of the two to carry behaviour on top of structure. The notation is defined by the OMG's UML specification. The notation reads at the conceptual and analysis level, the one that falls to the business analyst.
Goal
The class diagram gives a shared, unambiguous representation of the structure of a domain intended for a piece of object-oriented software: which classes exist, what they carry as attributes and operations and how they relate. It writes this in a vocabulary the business can confirm and the developer can implement. The decision it supports is the structure of the code, the domain classes and their associations, at the moment when that choice is still open to debate and cheap to undo, before implementation.
The deliverable is a diagram together with text that documents it. At the level that concerns the business analyst, it is a conceptual and analysis model: the domain classes, their essential attributes, the significant business operations, the associations named in the words of the business and the multiplicities set at their ends. BABOK places the class diagram as one of the two notations of the data model, the one that supports object-oriented development, and it contrasts it with the entity-relationship diagram, which serves the schema of a relational database. The data-modelling hub sets out this division and points to the notation that fits.
Usage
When to use it
- Designing object-oriented software: the artifact being designed is the structure of the code, and the classes and their associations frame it.
- Behaviour matters as much as structure: the class carries operations that the entity-relationship diagram cannot express.
- The developer is the downstream reader: the class diagram is the notation the development team reads fluently.
- An existing object-oriented system to document: reconstruct the real classes and their links before an evolution or a takeover.
When not to use it
- The artifact being designed is the schema of a relational database: it is the persistent schema that is being designed, not the code, so take the entity-relationship diagram.
- The domain vocabulary is still disputed: fix the meaning first with a concept model, then the structure.
- A strictly business audience with no IT background: the formalism puts them off, so keep a glossary for that audience.
Description
A business analyst does not have to draw the whole of UML to use a class diagram. What is needed is to be able to read a handful of elements and combine them. The rest of the notation belongs to the detailed-design level and falls outside the business analyst's scope.
The class and its three compartments
A class is a rectangle with three stacked compartments. The class name sits in the top compartment, singular and in the words of the business. The attributes occupy the middle compartment, the operations the bottom one. The name alone is enough while the rest is not yet settled, and the two lower compartments fill in as work proceeds.
An attribute is a piece of information held about the class, written in the form name: Type, for example priceCHF: Decimal or startDate: Date. The type is optional at the conceptual level and is pinned down towards the logical level. The attribute says which information is held, its allowed values and its format, but the detailed definitions belong to the data dictionary. An operation says what can be done with the class, written at the bottom of the rectangle, for example validate() or renew(endDate). It is the operation that separates the class from the entity of an entity-relationship diagram: the entity carries attributes and relationships, it does not carry behaviour.
Association, multiplicity, generalisation
An association is a line between two classes, saying that they relate and how. It is readily named with a verb, holds or covers. In a class model one speaks of an association where a data model speaks of a relationship.
The multiplicity is the annotation carried at each end of the association. It fixes the minimum and maximum number of occurrences allowed on the side where it is written. The usual values are 1 for exactly one, 0..1 for zero or one and therefore optional, * or 0..* for any number and 1..* for at least one. One speaks of multiplicity where a data model speaks of cardinality, for the same idea of bounds. What most often trips people up is the direction of reading: the bound written at one end reads at that end. In "a client holds 0..* subscriptions", the 0..* is written on the subscription side and describes the number of subscriptions, not the number of clients. Reading 0..* as "mandatory" is the other common mistake, when the 0 says the link is optional.
Generalisation is the "is-a" link. It is drawn as a line ending in a hollow triangle that points at the general class, the super-class. The sub-classes inherit the attributes, operations and associations of the super-class and add their own. The hollow triangle distinguishes it from the association: the triangle marks inheritance, the plain line a structural link. Taking one for the other distorts the reading of the model. To build a diagram, you set out the domain classes, fill in their attributes and their significant business operations, link them with associations annotated with multiplicities and factor what is common to several classes into a super-class joined by generalisation.
The level that falls to the business analyst
A class diagram exists at several levels, like any data model. The conceptual and analysis level is the business analyst's: domain classes named in the words of the business, essential attributes, business operations, associations and multiplicities. It is independent of the technology and the business can confirm or refute it. The logical and physical levels, member visibility, technical types, method signatures, interfaces and infrastructure classes belong to the implementation experts. BABOK reserves these levels for those who implement the object-oriented solution.
This is where the central pitfall for a business analyst comes from: over-modelling towards implementation. Adding visibility markers +/-, getX and setX accessors, technical types or design patterns encroaches on another craft and weighs the model down into a level of detail the business can no longer validate. The second pitfall is to confuse the class diagram with the entity-relationship diagram. Both model the same conceptual content of the domain, but they serve different artifacts and speak two vocabularies: the class carries operations and speaks of association and multiplicity, the entity carries no behaviour and speaks of relationship and cardinality. The criterion that separates them is therefore the artifact being designed, object-oriented code or relational schema. An object-oriented application sitting on a relational database, an ordinary case in Switzerland, produces both models.
AI considerations
A language model renders two services on this technique. The first is deriving a candidate model: it reads a body of requirements, interview notes or existing code and proposes classes, attributes, operations and associations. On a legacy system with no documentation the gain is real, and the draft it produces is corrected faster than a blank page is filled. The second is spotting the gaps: an orphan class with no association, a plausible association that has not been drawn or an attribute repeated across several classes that suggests a generalisation to factor out.
The limit is firm and business in nature. The correct multiplicity, whether a client may hold several subscriptions or a policy covers only one insured party, is a business fact that the text does not deliver reliably, and a wrong bound makes the model lie. The semantics of the domain, what a class means to the organisation and the fact that an association really exists in its activity, are confirmed with the experts. And a language model tends to over-model towards implementation. Every proposal from the AI is a draft submitted to the domain experts and to the business analyst who holds the analysis level.
Examples
The concept the example makes visible is the assembly of three elements on a single small diagram: the three-compartment class, the association annotated with multiplicities and the generalisation. The case chosen is Swiss public-transport subscriptions, where the GA travelcard and the half-fare travelcard are two types of the same subscription.
Two points are easy to miss. The multiplicity 0..* is written on the Subscription side and reads there: a client holds zero, one or several subscriptions, while the 1 on the Client side says that a subscription belongs to exactly one client. The hollow triangle pointing at Subscription marks inheritance: GeneralSubscription and HalfFare inherit number, startDate, endDate and priceCHF as well as the operations validate() and renew(), and each adds only its own attribute, the travel class for the GA travelcard, the discount rate for the half-fare card. Four classes, one association and one generalisation are enough to carry the whole notation a business analyst needs to read.
Visualisations
The form carries the meaning. The rectangle with three compartments says that an object has a name, attributes and operations. The line says an association, and the bound written at its end reads at that end. The hollow triangle says a generalisation and points at the general class. A reader who knows these three signs reads a complete class diagram without a legend, such as the one for the subscriptions.
Cost
| Phase | Level | Rationale |
|---|---|---|
| Preparation | Medium | Gather the sources, requirements, interview notes, existing code or schema, then identify the experts who can authoritatively confirm the classes, the associations and their multiplicities. |
| Execution | Low to medium | The analysis level is set out in a few sessions with the domain experts. The cost grows with the number of classes and associations. Implementation detail stays outside the business analyst's scope. |
| Documentation | Medium | The analysis model lives with the domain and is updated at every change to the classes or their links. It stays lighter than the logical and physical models, which are held by implementation. |
Tooling
A whiteboard is enough for a first sketch: a few classes and their links fit on one surface and are corrected standing up, which is often the right scale for the analysis level. General-purpose diagramming tools, diagrams.net, Lucidchart or Visio, carry UML stencils and give a clean, shareable drawing, well suited as long as the diagram supports a discussion. Dedicated UML modelling workbenches, Enterprise Architect, Visual Paradigm, StarUML or Modelio, hold the class diagram as one view of a coherent model: they check the model, link it to the other UML diagrams and, on the implementation side, generate code from the classes or reverse-engineer the classes from existing code. That reverse-engineering is useful for documenting a legacy object-oriented system, provided the result is then brought back to the analysis level rather than letting technical detail saturate the model. Text-generation tools, such as PlantUML, describe the diagram in a few lines of versionable text, which suits a model kept alongside the code.
Sources
- OMG (Object Management Group), Unified Modeling Language (UML) Specification, version 2.5.1: the specification that defines the class diagram and its notation, three-compartment classes, attributes, operations, associations, multiplicity and generalisation. It is the normative anchor of the notation.
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.15 Data Modelling: the class diagram among the two notations of the data model, the definition of class, attribute, operation and association and the routing rule that uses it for object-oriented development.