Class-based modelling: the grammatical parse and the six criteria

The problem: classes are not lying around

Look around a room and the objects are obvious — you can point at them, name them, and say what they do. Look around the problem space of a software application and the classes are far less obvious, because most of them are not physical. Class-based modelling is the discipline that makes them findable: it identifies the classes, attributes, operations, relationships and collaborations that the problem statement implies. It is the second of the requirements model's three element sets, it is derived from the first (the scenarios), and it produces two work products — the UML class diagram and the CRC model.

The method has three mechanical steps and one judgement step, and the marks in an exam answer are almost entirely in steps 2 and 3, which is precisely where weak answers stop.

Step 1 — the grammatical parse

Take the use cases and the processing narrative and underline every noun and noun phrase, entering each into a simple table. Note synonyms as you go — token, code and QR are one candidate, not three. A useful split falls out immediately: if a noun is needed to implement a solution it belongs to the solution space; if it is needed only to describe the problem it belongs to the problem space. Analysis lives in the problem space.

A processing narrative is not the same as a use case: it describes the function to be developed as a whole, rather than one actor's path through it. Parse both.

Step 2 — the seven manifestations

A noun is a candidate class only if it manifests as one of seven things:

1. External entities — other systems, devices or people that produce or consume the information the system uses.
2. Things — reports, displays, letters, signals: parts of the problem's information domain.
3. Occurrences or events — something that happens within the operation of the system.
4. Roles — played by the people who interact with the system.
5. Organizational units — a division, group or team relevant to the application.
6. Places — establishing the context of the problem.
7. Structures — defining a class of objects or a set of related classes.

Write the classification next to each noun. A noun that fits none of the seven is not a class.

Step 3 — the six selection criteria

Surviving nouns are still only potential classes. Six characteristics decide:

1. Retained information — the system must remember something about it to function.
2. Needed services — it has identifiable operations that can change its own attribute values.
3. Multiple attributes — a single-attribute candidate is usually an attribute of something else.
4. Common attributes — a set of attributes can be defined that applies to all instances.
5. Common operations — likewise for operations.
6. Essential requirements — external entities that produce or consume information essential to any solution are almost always classes.

A candidate should satisfy most of these to be included. The decision is somewhat subjective and later work may reinstate a rejected candidate or discard an accepted one — but it must be made, and the reason must be written down, because the reason is what a reviewer (and a marker) reads.

Attributes and operations

Attributes are the data items, composite or elementary, that fully define a class in the context of this problem. Rejected candidates frequently reappear here — that is the normal outcome, not a failure. One guideline saves confusion later: if more than one of an item is associated with the class, model it as an association to another class rather than as an attribute. Operations come from the verbs, and fall into four broad kinds: manipulating data, performing a computation, inquiring about the state of an object, and monitoring an object for a controlling event.

Worked example — parsing the BorrowBox narrative

Here is the processing narrative, written once so the whole module can parse it:

> BorrowBox lends power tools to the members of a neighbourhood. A member browses the catalogue in an app and reserves a tool; the system holds one copy for two hours and issues a one-time token. The member walks to the depot, scans the token at the locker bank, and the locker controller releases the assigned door. When a copy is returned to any free locker, a librarian inspects it, grades its condition, and either re-shelves it or raises a damage report. If a copy is not returned by its due time, the system charges a late fee to the member's account.

Underlining gives: member, neighbourhood, catalogue, app, tool, copy, two hours, token, depot, locker bank, locker controller, door, librarian, condition, damage report, due time, late fee, account — and one noun that is implied rather than written, reservation, which the verb reserves creates.

Now classify and filter. Member is a role; the system retains standing and fees, offers services (mayBorrow, addFee) and has several attributes — accept. Copy, properly ToolCopy, is a thing with a condition, a status and a location — accept, and note that it is distinct from Tool, the catalogue title. Reservation is an occurrence: it is remembered, it expires, it converts into a loan — accept. Locker controller is an external entity producing information essential to any solution — accept on criterion 6. Token fails criterion 3: one value, no services of its own, so it becomes an attribute of Reservation, as two hours becomes expiresAt. Depot is a place, and today it fails criteria 1 and 3 — there is one depot and the system remembers nothing about it — so reject it, and record why, because the day BorrowBox opens a second depot that decision reverses.

That last sentence is the whole lesson. The criteria are not a ritual; they are an argument, and the argument is what changes when the problem changes.