UML class models: attributes, operations, associations, multiplicity — COMP 410

The class box

A UML class is drawn as a rectangle in compartments: the class name at the top, its attributes beneath, its operations beneath those. Attributes are written as names, optionally with a type; operations carry parentheses, because they are things the object does. Analysis-level class boxes are deliberately sparse — no visibility markers, no return types, no helper methods — because everything you add is a claim about the problem domain that a stakeholder should be able to confirm.

Operations come from the verbs

The parse that gave you nouns also gives you operations: study the narrative again and isolate the verbs. A copy is assigned to a door implies an assign() on the copy or the locker; the system charges a late fee implies a charge() somewhere. Some verbs will attach obviously to one class; others force a decision about where the responsibility lives, which is exactly the question CRC modelling is built to answer, and the reason the two techniques are taught together.

A second source of operations is the communication between objects. Objects collaborate by passing messages, and a message that must be received implies an operation that must exist.

Associations

When two analysis classes are structurally related, UML calls the relationship an association and draws it as a solid line. An association has optional parts: it may be labelled with the name of the relationship; each end may be labelled with the role the class plays there; and arrows on one or both ends indicate navigability — an arrow at one end means you can get to that class easily from the other, but not necessarily back. No arrows usually means a two-way association, or that navigability was not worth deciding yet. An association may also loop from a class to itself, connecting objects of the same class.

One genuinely useful equivalence: an attribute whose type is another class is almost the same statement as an association to that class. Use an attribute when the type is a primitive; use an association when the other type plays a real role in the model and deserves a box of its own.

Multiplicity

The multiplicity at one end of an association is the number of objects of that class associated with one object at the other end. It is written as a non-negative integer or a range: 0..1 means zero or one, 1..* means one or more, * (or 0..*) means zero or more, and a bare 1 means exactly one. Multiplicity is where a class diagram says things a use case cannot: a Reservation holds exactly one ToolCopy and a ToolCopy has at most one live Reservation are two separate business rules, both readable off one line.

Aggregation, composition, dependency, generalization

Four further relationship kinds complete the working vocabulary. Aggregation — a hollow diamond at the whole end — is a whole/part relationship. Composition is aggregation with strong ownership: the parts live and die with the whole, because they have no independent role. Dependency — a dashed line — says that a change to the second class might force a change to the first; it is drawn only for transient uses, since an association already implies dependency. Generalization — a solid line with a hollow triangular arrowhead pointing at the superclass — is the subclass relationship, and a dashed line with the same arrowhead is realization, the implementation of an interface.

Worked example — the BorrowBox class model

The figure shows the five classes that survived the parse in the previous lesson. Read three business rules straight off it. First, Member 1 — 0..* Reservation: a member may hold many reservations at once, and every reservation belongs to exactly one member — so there is no such thing as a household reservation, which is a decision somebody made and which a stakeholder can now dispute. Second, Reservation 0..1 — 1 ToolCopy: the hold is on a specific physical copy, not on the catalogue title, so the model has committed to copy-level reservation and the waitlist must therefore work at copy level too. Third, ToolCopy 0..1 — 0..1 Locker: a copy is in at most one locker and a locker holds at most one copy, and both ends are optional because a copy on loan is in no locker and an empty locker holds no copy.

None of those three sentences can be written on a use case. That is the argument for building the class model at all.

Rendered with this course's entity-relationship renderer standing in for a UML class diagram: each box is a class, the list holds attributes first and then operations (marked with parentheses), and the numbers on each association end are UML multiplicity. A real class diagram would rule a line between the attribute and operation compartments.