skip to content

In a UML class diagram, how do you read a class box's three compartments and its visibility markers?

level: juniorimportance: must knowfreq 74%

answer

  1. Three stacked areas, always the same order
  2. Name on top, then state, then behaviour
  3. One symbol sits before each member name
  4. Four visibility markers, widest to narrowest

basics

~20 s

A class box stacks three compartments: the class name on top, the attributes in the middle, the operations at the bottom. A leading +, -, # or ~ on a member marks it public, private, protected or package-visible.

solid answer

~40 s

Read a class box top to bottom. The **first compartment** carries the classifier name — italic or `{abstract}` when it is abstract, with a keyword in guillemets such as `«interface»` above the name when it is not a plain class. The **second** lists attributes, written `visibility name : type [multiplicity] = default`. The **third** lists operations, written `visibility name(parameter : type) : returnType`. The leading symbol is visibility: `+` public, `-` private, `#` protected, `~` package. An underlined member is class-scoped rather than per-instance, and a leading `/` marks a derived value. Only the name compartment is mandatory. A compartment that is drawn but left empty claims the class has no members of that kind; a compartment omitted entirely claims nothing at all, which is why a name-only box is legal and common.

code

pseudocode · 13 lines
pseudocode
+---------------------------------------------+
|               DeliverySlot                  |
+---------------------------------------------+
| - slotId : Text                             |
| + windowStart : Timestamp                   |
| # capacity : Integer = 23                   |
| ~ notes : Text [0..2]                       |
| / remaining : Integer                       |
+---------------------------------------------+
| + reserve(orderRef : Text) : Boolean        |
| + release(orderRef : Text)                  |
| - recount() : Integer                       |
+---------------------------------------------+

go deeper

for a junior

Be ready to name the three compartments in order and the four visibility markers on sight. Interviewers use this as a quick check that you have actually read a class diagram rather than only heard of one.

for a middle

Explain the attribute and operation syntax in full — type, multiplicity, default and the constraints in braces — and say what an italic name or an underlined name changes about the member.

for a senior

Read a box as a set of claims: which members form the public surface, what an empty compartment asserts as against an omitted one, and where the diagram's intent and the shipped system may legitimately differ.

for a principal

Own the convention itself. Decide how much detail your team's boxes carry, insist that suppressed compartments are never mistaken for empty ones, and keep the notation cheap enough that people keep using it.

## What a class box represents A **class box** is a rectangle divided by horizontal rules into **compartments**. It stands for a *classifier* — a kind of thing in the design, not one particular object — so everything written inside describes what every instance of that kind holds and can do. The compartment order is fixed, top to bottom, and that fixed order is what makes a box readable without a legend: nobody has to work out whether they are looking at data or at behaviour. ## The three compartments 1. **Name compartment** — the only mandatory one. It holds the class name, centred, bold by convention. An **abstract** class shows its name in *italics* or carries the constraint `{abstract}`. When the classifier is not a plain class, a keyword in guillemets sits above the name: `«interface»`, `«enumeration»`, `«datatype»`. 2. **Attribute compartment** — the structural features, one per line: what each instance holds. 3. **Operation compartment** — the behavioural features, one per line: what each instance can be asked to do. Two kinds of absence mean different things, and the difference is worth stating out loud in review: - A compartment that is **drawn but empty** asserts the class has no members of that kind. - A compartment that is **omitted entirely** asserts nothing. The members exist; this page simply is not showing them. An overview page for a regional grocery-delivery product might show fourteen boxes with names only, because relationships are the point of that page; a detail page then expands the two or three boxes whose internals are under discussion. ## How an attribute line is written The full form is: `visibility name : type [multiplicity] = default {property}` Everything but the name is optional, so the same attribute can appear as `capacity` on one page and as `# capacity : Integer = 23 {readOnly}` on another without the two contradicting each other. - **`[multiplicity]`** on an attribute says how many values it holds — `[0..1]` optional, `[1..*]` one or more. An attribute with no multiplicity written is read as a single value. - **An underlined name** is class-scoped: one value belonging to the classifier itself, not one copy per instance. - **A leading `/`** marks the value as *derived* — computed from other features rather than stored. - **`{property}`** carries constraints such as `{readOnly}`, `{ordered}` or `{unique}`. ## How an operation line is written The full form is: `visibility name(direction parameter : type, ...) : returnType {property}` - Parameters may carry a **direction** — `in`, `out`, `inout` — before the parameter name; `in` is the usual case and is normally left off. - The **return type** follows the closing parenthesis, and an operation that returns nothing simply omits it. - An **italic operation name** is abstract: declared here, with a specialization expected to supply the behaviour. - **`{query}`** marks an operation that reads state without changing it. ## The four visibility markers | Marker | Visibility | Who may reach the member | | --- | --- | --- | | `+` | public | anything that can see the class at all | | `-` | private | only the class itself | | `#` | protected | the class and its specializations | | `~` | package | classifiers in the same package | Three things are worth knowing about them: - They are **notation, not enforcement**. They record what the designer intends. An implementation may offer a coarser or a finer access model than these four, and where the two disagree the running system is the truth. - Visibility is about *who may reach the member*, never about how important it is. A long list of `-` attributes beside two `+` operations is the healthy shape: it says the class keeps its state to itself and offers a small surface. - Some diagrams substitute lock or key icons for the symbols. That is a presentation layer on top; the four symbols are the standard the notation defines. ## Reading a box quickly 1. Read the name and any guillemet keyword, and decide **what kind of thing** this is. 2. Skim the attribute compartment for `+` and `#` members — those are the parts other classifiers are invited to depend on. 3. Read the operation compartment as the class's **public offer**: the `+` operations are the contract, the rest is machinery. 4. Note anything italic (abstract) or underlined (class-scoped). Both change how the box may be used before you read a single line of source. ## What the box deliberately does not say - Nothing about **order of execution**; a class diagram is a static view. - Nothing about **how many objects exist** at run time — that is what multiplicity on relationships states. - No promise that the listed members are *all* the members, unless the compartments are shown and empty. - No commitment to an implementation: an attribute in the box may end up a stored field, a computed value, or a stored column, and the diagram is content not to decide.

  • A compartment is drawn but left empty. What is the diagram claiming?
    That the class has no members of that kind. An empty compartment is a positive statement, unlike an omitted compartment, which claims nothing and simply hides detail. Reviewers read the two very differently: an empty attribute compartment on a class you expected to hold state is a finding worth raising, whereas a box drawn with only a name is normal on an overview page.
  • What does underlining a member name inside a class box mean?
    It marks the member as class-scoped: one attribute value, or one operation, belonging to the classifier itself and shared across every instance rather than copied per object. The same convention applies in both the attribute and the operation compartment. Because underlining is easy to lose on a printed or scaled-down page, it is worth naming in the diagram's key.
  • How is an abstract class distinguished from a concrete one in a class box?
    By an italic class name, or by the constraint `{abstract}` beside the name where italics would not survive the medium. The same convention marks an abstract operation inside the operation compartment: the name is italic, declaring the operation without supplying behaviour, and a concrete specialization is expected to provide it.

Think of the box as a passport page: identity at the top, fixed details in the middle, and what the holder is permitted to do at the bottom — always in that order, so you can read the third block without reading the first.

saying these in an interview costs you the question

  • Says the middle compartment lists operations and the bottom one attributes
  • Reads plus and minus as required versus optional
  • Thinks a name-only box means the class has no members
  • Treats visibility markers as something the diagram enforces
  • Assumes compartment order can vary from diagram to diagram
  • Reads an underlined member as merely emphasised