Deriving OOD Classes from a Use Case Diagram: 25-Comp-B11 Advanced Software Design, December 2018, Q4

Question 4: Deriving OOD Classes from a Use Case Diagram (Part I)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

A use case diagram names WHO interacts with the system (actors) and WHAT the system does for them (use cases), but says nothing about the system's internal structure; deriving a design-level class diagram from it is a systematic, if not purely mechanical, mapping exercise built on the Entity/Control/Boundary (ECB) responsibility categories used throughout this subject (Question 19).

Boundary classes, one per actor-facing interaction point. Each distinct way an actor interacts with the system (a screen, a form, an API endpoint) typically yields one Boundary class, since it is the interface surface the actor actually touches. A single actor may drive several Boundary classes if it uses several distinct screens/interfaces.
Control classes, typically one per use case. Each use case's step-by-step logic (the sequence of actions/decisions the use case performs) is naturally assigned to a Control class that orchestrates the interaction between the relevant Boundary and Entity classes for that use case, keeping that flow-of-control logic out of both the interface and the data classes.
Entity classes, one per persistent domain concept. Nouns appearing in the use case's description that must be stored beyond a single use-case execution (a Book, a Patron, an Order) become Entity classes, independent of which actor or use case happens to reference them — a single Entity is frequently shared across several use cases and Control classes.
Relationships between use cases (include/extend) suggest relationships between Control classes, e.g. an included sub-use-case's Control logic can be factored into a class the including use case's Control class calls, mirroring the use-case-level composition at the design level.

Crucially, this mapping is NOT a naming rule: an actor's name does not have to reappear as a class name, and a use case does not have to become exactly one class. The actor "Librarian" scopes WHO can trigger certain use cases; the resulting design might need only a shared StaffAccount Entity and a CirculationController Control class, with no class literally named Librarian at all. What transfers from the use-case model to the design model is the set of RESPONSIBILITIES the use cases imply (interface, orchestration, data), not the actors' or use cases' own names.

Concept & Theory: Use-Case Responsibilities Map to ECB Categories, Not to Names

Topic: Systematic (Boundary/Control/Entity) derivation of design classes from a use-case model's actors and use cases.

Key relations: Actor-facing interaction → Boundary class. Use-case flow-of-control → Control class. Persistent domain noun → Entity class.

Why this works: Deriving classes by RESPONSIBILITY rather than by copying use-case/actor names keeps the resulting design's classes cohesive (Question 19) even when the requirements-level names don't map one-to-one onto convenient design-level abstractions.

Common pitfall: Creating one class per actor and one class per use case by name — this conflates the analysis model's vocabulary with the design model's responsibilities and typically produces poorly cohesive classes.

Source: Sommerville, Software Engineering, ch. "Object-Oriented Design" (use-case to design-class mapping, ECB responsibility assignment).

Question 4 of 28: Deriving OOD Classes from a Use Case Diagram

Question 4: Deriving OOD Classes from a Use Case Diagram (Part I)