Object-Oriented Analysis and the Domain Model

Formalize — what "decompose into objects" means

An object here is a domain participant with identity (you can point to this specific one), state (information it remembers over time), and purpose (the work it contributes to solving the current requirement). A class groups similar objects under one name and definition.

OOA as decomposition therefore means: given the SIS and its use cases, identify the set of domain concepts — persons, places, events, catalogs, transactions, rules, records — that together can realize every required story through collaboration. The decomposition is guided by three properties:

1. Domain grounding: each object name is a word people in the domain already use (guest, reservation, sale, payment), kept consistent via a glossary — a shared list of terms with plain definitions that the whole team honors.
2. Vocabulary continuity: the same names carry forward through analysis → design → programming. You do not rename "Reservation" to "BookingRecord" in design and "ResvObj" in code. That continuity is deliberate so learning in one phase transfers.
3. Collaboration focus: objects are not isolated nouns; they are chosen because they must work together to make the use-case steps happen. The question is not "list all nouns" but "which participants, talking through which relationships, can enact these stories?"

Formalize — one vocabulary, progressively refined

The lecture makes a single point repeatedly because beginners often miss it: analysis, design and programming use the same object idea. You do not invent a fresh set of objects for each phase.

• Analysis: first cut — identify conceptual classes that exist in the real domain, name their purpose, note high-level responsibilities without methods, and show associations in domain language.
• Design: detailed assignment — add responsibilities as operations (method signatures), decide visibility, navigation direction, patterns, persistence and performance choices. The conceptual classes remain recognizable; some may split or merge but the names stay.
• Programming: realization — implement the designed classes, choosing data structures and language idioms. The conceptual lineage is still traceable "Reservation → Reservation class."

This continuity is intentional. It lowers cognitive load (learn the domain once, refine thrice) and supports traceability (a design decision can be explained as "because in the domain a Reservation covers a Stay").

Formalize — two lenses on the same requirement

• Function-oriented analysis: ask "what steps (business processes, functions) happen?" Decompose a big function into smaller Data Flow Diagram (DFD) processes, track inputs/outputs, then map processes onto modules. The primary structure is the process hierarchy.

• Object-oriented analysis: ask "which things exist, what do they know, and how do they collaborate to make the steps happen?" Decompose the problem domain into objects/classes (persons, places, events, catalogs, transactions) and the associations (real-world connections) that let them interact to realize each use case. The primary structure is the collaboration graph.

User requirements themselves can be expressed from different viewpoints: C-requirements (customer-facing — value in the customer's language) and D-requirements (developer-facing — system specification in implementation-aware language). The same requirement can be written either way. OOA chooses the developer-facing view to be object-centric and then demonstrates, via collaboration, how those objects enact the customer-facing stories. That choice produces the smaller representation gap (see 8.7): the names in the model match the names people in the domain use in everyday speech, so less translation is needed between mental model and software model.

Why that matters: OO's claimed advantages — managing complexity by hiding it inside owning objects, and supporting ease of change via low coupling — follow directly from this lens. When requirements change, you often add or adjust a collaboration, not rewrite a global process tree.

Formalize — definition and notation

A domain model — also called a conceptual class diagram or analysis class diagram — is a visual dictionary of the noteworthy concepts in the problem domain, drawn with the same rectangle-and-line notation as a UML class diagram but with a different intent.

What it shows (conceptual perspective, Fowler; UP artifact — T1 Ch.9):

• Conceptual classes — ideas, things, or objects in the real domain that matter for the current iteration (e.g., Sale, Payment, Reservation, Room, Guest). The box shows the class name in domain vocabulary.
• Attributes — logical data values remembered about the concept, only where already known (e.g., Sale date, time; ProductDescription price). Many classes legitimately have no attributes yet — you know the concept exists and its purpose, but have not discovered its data.
• Associations — named, real-world connections between conceptual classes (e.g., Sale Paid-by Payment, Room assigned to Reservation). At this stage associations are plain, named lines (no aggregation/composition adornments, no inheritance, no navigability decisions) labeled with the domain's verb phrase.

What it does not show (by rule):

• Methods / operations — behavior is deliberately absent. You may note a high-level responsibility in prose, but you do not add method signatures, visibility, or navigation direction; those are design decisions.
• Software artifacts — no windows, databases, frameworks, or implementation classes. A POS domain model shows a real Register, not a Java JFrame; an Inventory concept, not a SalesDatabase table.

The model is static — a snapshot of concepts, their information, and their real-world links — and it is scoped: it aims to represent completely, for the current iteration, just enough of reality to solve the stated requirement. Every box and line must earn its place by helping answer "how does this set of concepts, collaborating, solve the current use cases?" It also serves as a source of inspiration for software design: the conceptual classes (and their names) inspire — but are not identical to — the software classes in the design model's domain layer (T1 Fig. 9.6). Lowering that name gap has been shown, since the 1990s Smalltalk experience cited in T1 Ch.9, to lower comprehension and change cost.

Formalize — two artifacts, one notation, different intent

Both diagrams use UML class boxes and association lines, which is exactly why the distinction must be made explicit.

A simple test: if you showed the conceptual diagram to a domain expert with no software background, they should be able to correct it ("no, a Reservation covers a Stay, not a Room directly"). If you showed the design diagram, they would rightly say "I don't know what private or 0..1 means here."

Formalize — iterative, scoped, idealized

Three discipline ideas control the domain model's growth:

• Iterative refinement: The domain model is not drawn once. You make a first cut in analysis, refine it in design (adding operations, navigation, patterns), and refine again in implementation — within boundaries. Analysis is where you practice thinking in objects for the first time; later passes make that thinking sharper.
• Scoping: Two boundaries gate every addition: the system boundary (defined during use-case work — what is inside the system vs. an external actor) and the current iteration's scope (which use cases are under design this iteration). A concept outside either boundary is excluded, even if it is a real domain thing. Only enough of the world to represent the current problem completely enters the diagram.
• Idealized behavior: Analysis models what the system should support, not just how work happens today in a manual process. Your solution should be better than the existing way of working. If today's manual resort log conflates "reservation" and "walk-in hold" on sticky notes, the model still distinguishes them cleanly as Reservation vs. Hold concepts because the idealized flow requires it.

Together these say: stay inside the iteration boundary, model the world as it should be to satisfy the requirements, and let understanding grow across passes.

Formalize — the landscape of candidate origins

There is no formula that maps a noun to a class. Any physical thing, idea, or concept that matters in the problem domain can be treated as an object if it helps solve the current requirement. The question is never "is this kind of noun an object in general?" but "does this concept matter here for solving the current iteration's requirement, with identity, state, and participation?"

Where to look — prompts, not rules — mirrors the conceptual class category list (T1 9.5, Table 9.1):

• Persons and roles: Guest, Customer, Receptionist, Teacher, Dean. Often actors or role-played participants.
• Physical items and tangible devices: Room, Bed, Register, Item, Die, Board, Piece.
• Places: Store, Resort, Campus, City, Airport.
• Transactions and events: Reservation, Sale, Payment, Loan, Flight, MonopolyGame move.
• Catalogs and descriptions: RoomType, ProductCatalog, ProductDescription, FlightDescription.
• Rules, policies, and records: RatePolicy, CancellationRule, Ledger, ReservationLog.
• Supporting / passive receivers: a database or record that never initiates interaction but receives results and retains them (e.g., Ledger that is updated with sale/accounting info, Inventory that is adjusted).

Even "quiet" participants qualify when the domain needs them — a record that only receives a result still remembers information needed for later collaborations. Borderline cases are resolved not by a universal checklist but by domain judgment grounded in the use-case stories for the current scope.

A note on the learning order: many students meet programming first, where objects are already defined, and only later meet analysis where objects must be discovered. That is the reverse of most engineering disciplines, where analysis and design precede implementation. If you have built programs, you can use that memory as a heuristic: ask "would I expect this concept to hold data over time and take part in work, or would it simply be a value held by something else?"

Formalize — one sentence that decides

The most reliable practical test offered in the lecture:

You should be able to state the purpose of the class or object in the problem domain in plain language — one or two sentences saying what this object stands for and what it contributes to solving the current problem.

• Passes: you can write a crisp intension — "A Reservation represents a guest's undertaking to hold one or more rooms over a specific Stay, tracks confirmation status, and initiates assignment and payment." You know its instances (R1, R2, ...), its state (dates, confirmation), and its collaborations.
• Fails: you can only write vague phrasing — "Night is ... a night?" — or describe it solely as a value on another thing ("the night on a date"). If you cannot say what work it does in the story without resorting to "it is a kind of detail," reconsider.

This test does three things at once: (a) rejects invented-but-weightless objects, (b) forces a high-level abstraction anchored in domain language (managing complexity by grouping related information and work under a name people recognize), and (c) enforces that objects own their part of complexity rather than scattering details across functions. Object orientation, in this telling, is a complexity management strategy — each concept hides its interior complexity behind a purposeful name.

Formalize — abstraction as disciplined suppression of detail

Abstraction in OOA means keeping the view at a high level and deliberately suppressing implementation detail. You capture enough to see how work gets done (who, with whom, to what end) without deciding how code will do it (which fields, which algorithm, which framework).

Two consequences follow:

1. Methods absent by design. The domain model leaves out operations and often shows classes with no attributes yet. You are still deciding what exists, not how it operates internally. That is not incompleteness; it is keeping the abstraction honest.
2. Small model, large explanatory power. A handful of well-connected concepts (say, 6–9 classes) can realize many use cases when their associations are right. This is why Larman (T1 Ch.9) celebrates a rich set of conceptual classes discovered quickly — a few hours of skilled modeling often pays off disproportionately in design clarity.

The discipline that keeps abstraction from becoming vague is real-world grounding: associations are named with the domain's own verb phrases ("Reservation covers Stay", "Teacher teaches Student"), vocabulary is held honest in the glossary, and every new concept is tested with "could I explain this to a domain person using their terms?" When that answer is yes, the abstraction is earning its keep.

Formalize — textual (noun-phrase) analysis

Also called noun-phrase analysis, natural-language analysis, or Nell's method (after Abbott / Moreno). The idea is intentionally low-tech:

1. Read to understand first. Read the use case or problem statement two or three times until you can paraphrase what must be built — do not underline while still confused about the flow.
2. Underline nouns and noun phrases. Every noun is a candidate class; every verb / verb phrase hints at a responsibility that may later become an operation, but in analysis you do not turn verbs into methods.
3. Collect into a rough candidate list. No filtering while harvesting — the list is possibilities, not answers. Include compound phrases ("product catalog" as one candidate, not two).
4. Judge each noun after harvesting. Ask: is this a concept with identity, state, and collaboration for this iteration, or simply a value held by another concept?That judgment cannot be automated — Bus tagging or POS-style automated noun tagging (the lecture's "bus tagging / manual marking") surfaces the same nouns mechanically, but a person must decide "class vs. attribute vs. outside scope."

Judgment uses the purpose test (8.3), the class-vs-attribute test (8.6), and iteration scope. The recommended habit is to avoid selectivity too early: optionally keep two lists — a stronger set you are confident about and a weaker set you are unsure about (might be an attribute, might be vague, might be out-of-scope). Unless you have a strong reason to remove a candidate, keep it. Losing a possible concept now is harder to recover than pruning later. As you continue reading, additional candidates and their attributes emerge.

Formalize — Class-Responsibility-Collaborator

A CRC card (Beck & Cunningham, OOPSLA 1989; popularized by Horstmann T2 Ch.2 and Larman via GRASP) is a physical index-card view of one conceptual class. On the card:

• Class: the class name (singular noun, domain term) at the top.
• Responsibilities: one to three high-level pieces of work the class is accountable for in the domain — written in plain language, not as method signatures. Example for Mailbox: "manage passcode", "manage greeting", "manage new and saved messages." A single responsibility may later give rise to several methods, but at this stage it is intentionally coarse.
• Collaborators: other classes it needs to interact with to meet each responsibility. Example: Mailbox collaborates with MessageQueue to manage messages; Reservation collaborates with Room and Guest.

The workshop practice: lay cards on a table, walk through use cases informally as conversations between cards, and move cards to see who does what. When a responsibility cannot be met alone, the question "who else must be involved?" directly names a collaborator — and thus a missing candidate. The cards are deliberately small (index-card sized) to discourage overloading a single class and are discarded after the session — they are a discovery tool, not archival documentation (T2 2.7).

Formalize — experience as accelerator, not gate

The lecture is candid: past experience with similar domains and with having built objects before accelerates every step, because you pattern-match faster and recognize when "city" should be a class versus an attribute. Two facts contextualize this:

• Students often meet programming first (objects already given) and analysis later (objects must be found) — the reverse of most engineering where analysis/design precede building. That inversion explains why object discovery feels hard initially even to competent coders.
• Experience is therefore valuable but not the only way to recognize an object, and it is not treated as a prerequisite. The taught fallback sequence when you feel you have "no experience" is exactly the pipeline of this lecture:

1. Noun-phrase analysis of use cases as a systematic start.
2. CRC play to test collaborations and surface missing participants.
3. Category catalog prompts (T1 Table 9.1) to jog overlooked kinds.
4. Purpose/intension/extension and class-vs-attribute checks to prune.
5. Boundary/control/entity lenses for interaction-heavy domains (8.6).

Applied together, these steps teach thinking in objects; each repetition makes the feel for "keep vs. drop vs. fold into attribute" faster. The lecture explicitly says there is no formula mapping a sentence to a theorem-like answer — judgment develops by doing several cases.

Formalize — three ideas behind "does this deserve a class?"

Borrowing the classic analysis of conceptual classes (Larman T1 9.5, after Mordechai & Marcia — symbol / intension / extension), three linked ideas clarify the claim that a candidate is a real class:

• Intension — the definition or purpose — the what and why of the concept in plain words for the problem at hand. If you can define it precisely for the use cases in scope, the intension is crisp. For Student the intension might be: "a person enrolled in the institution who takes courses to earn a degree." It says what counts and why the system must care.
• Extension — the set of instances in the real world — the actual examples to which the concept applies, at this moment and over time. For Student that extension is {S1, S2, S3, ...}, many actual students. For Fan, Car, Bird the extension is also large — many fans, many cars, many birds.
• Representation — the symbol or name you use in the model to stand for the concept and carry its definition. The word "Student" in the diagram is the representation that bundles the definition (intension) and denotes the set of examples (extension).

A candidate that has a crisp intension and a real, broad extension (multiple instances) is well-supported as a class: it organizes a genuine plurality under one purposeful name. A concept with a crisp intension but a tiny extension (one or two instances) may be better as a value or anonymous object (see 8.5.2). A concept without a crisp intension cannot be defended as a class regardless of instance count — you cannot explain what it is for the current problem.

These three move together: representation without intension is an empty label; intension without extension is a definition of nothing; extension without intension is an unlabeled pile.

Formalize — narrow extension or no grouping benefit

If a notion has only one or two instances in the problem as scoped, it often does not need a class of its own. The modeling cost (a box, a name, associations to maintain) outweighs the grouping benefit when there is almost nothing to group. In such cases an anonymous object or a simple value (attribute) may be enough.

Horstmann and Larman both use the same contrasting examples to make the judgment concrete:

• Positive — keep: Fan, Car, Bird were offered precisely because each has many instances. The class name pays its way by organizing a real plurality (the extension is populous). A Car class collects shared structure and associations that would otherwise be duplicated.
• Negative — fold or drop: a facility's "Main Controller" that exists as a single instance, a one-off configuration string, or the "night" count inside a stay discussed in 8.3 — each adds a box that holds a single value and connects to no one else. Keeping them as classes inflates the model: more names to learn, more lines to maintain, zero additional explanatory power.

This choice interacts with abstraction (8.3.3): at the high level at which you are modeling to manage complexity, each class should pay its way by making the story clearer, not more fragmented. Adding boxes for singleton ideas fragments without clarifying.

A practical rule: if you can replace the candidate by an attribute on its natural owner (e.g., stay.durationNights: int, resort.mainFanMode: String) and still play every use case, prefer the attribute. If you later discover the candidate needs its own state and relationships (e.g., Fan gains speed, requiresMaintenance(), association to Technician), promote it back to a class in a later iteration — the iterative discipline (8.2.3) makes that safe.

Formalize — classification

Classification is the act of putting similar objects into one class. Instead of treating S1 and S2 as unrelated particulars, you notice they share the same intension (definition/purpose), similar structure (attributes), and similar collaborations, and you place them under the common name Student. The move from objects (many particulars) to class (one concept that stands for all of them) is exactly this grouping.

The same habit clarifies role cases. Consider roles such as Teacher, Student, Dean, Assistant Dean — all are persons, and each role name groups many persons. Whether Role itself should be a separate class or merely an attribute of Person (e.g., person.role: String) depends on whether the role carries additional state or behavior beyond a label:

• Label-only → attribute: Teacher as a tag on Person with no distinct associations or rules beyond "is a teacher" is an attribute value.
• Behavior-bearing → class (often via generalization): if Dean adds approving leave, signing documents, chairing committees — work and associations distinct from Teacher — then Dean is better as a class, possibly as a subclass of Person or via a Role hierarchy. The lecture notes that adjectives that add behavior hint at this inheritance decision rather than a simple attribute, a point revisited under class-vs-attribute (8.6) and inheritance where the pattern is formalized.

Classification is thus not mere naming; it is organizing work and information by similarity, tested by whether the grouped instances share collaborators, rules, and lifecycle.

Formalize — attribute vs. class

An attribute is a logical data value of an object (Larman T1 9.16) — often simple text or a number with no further structure or behavior of its own and no independent relationships. A class has identity (you can refer to this specific one), can participate in relationships (associations), and may own behavior even if that behavior is not yet shown as methods in the conceptual model.

Practical test (lecture + T1 9.12 guideline):

If we do not think of some conceptual class X as a number or text in the real world, X is probably a conceptual class, not an attribute ( Larman).

Concretely, look at each candidate noun and ask:

• Does it need to connect to other concepts via an association that must be remembered? If yes → class. A Destination that is not just a string but a massive thing that occupies space and connects to Flight, Airport services, and Passenger flows (T1 Fig. 9.22) is a class Airport, not a flight.destination: String.
• Does it have its own state beyond a single value — multiple attributes, a lifecycle, rules, or derived information? If yes → class.
• Does it own work or business rules that must be stated against it? If yes → class.
• If it appears only as a simple value held by another concept with no links or rules — e.g., a descriptive string, a count, a date — treat it as an attribute: room.roomNumber: String, sale.date: Date, salesLineItem.quantity: int.

Tie-breaker rule (lecture, emphasized): When you are genuinely unsure whether something should be a class or an attribute, lean toward class. Analysis aims to find a rich set of objects; keeping a candidate as a class preserves information you can simplify later (fold into an attribute in design when field detail shows it is too thin). Recovering a concept you dropped too early is harder than collapsing a thin class later. This rule interacts with the "do not be selective too early" advice of 8.4/8.8.

Formalize — a checklist of prompts, not rules

Experience can be turned into a checklist of common categories that often map to classes. These are prompts that help you spot candidates you might otherwise miss; they do not force a decision — each match is still filtered by purpose, extension, class-vs-attribute, and iteration scope.

Categories emphasized in the lecture (mapped to Larman T1 Table 9.1's category list for business information systems, with guidance on priority):

• Physical / tangible items: Room, Building, Device, Board, Piece, Airplane — especially relevant for device-control or simulation domains (Monopoly, telecom switch). Prioritize visible, tracked inventory.
• Transactions and transactional events: Booking, Payment, Sale, Reservation — critical because they involve money/value and anchor many line items, rules, and audit trails. Start here for business systems.
• Transaction line items: SalesLineItem, StayNight (when night-level pricing matters), MealOrderLine — transactions often come with related line items; consider these immediately after the transaction itself.
• Products or services related to a transaction/line item: Item, ProductDescription, RoomType, Flight, Seat, Meal — "the transaction is for something."
• Where the transaction is recorded / place of transaction and of service: Register, Ledger, Store, Resort, Airport, Plane — important to anchor "where is this remembered?"
• Roles played by persons and organizations: Teacher, Student, Dean, Assistant Dean (lecture); Passenger, Pilot, Cashier, Customer, MonopolyPlayer, Airline (T1). Actors in the use case belong here.
• Rules, policies, and specifications: CancellationPolicy, PricingStrategy, DailyPriceChangeList — especially when rules vary by time, contract, or type.
• Catalogs and descriptions (description classes, T1 9.13): RoomCatalog, ProductCatalog, FlightCatalog, ProductDescription — group descriptions of item types distinct from individual physical items/instances.
• Containers and groupings: Store, Bin, Board, Airplane, Resort — things that contain other things.
• Other categories (also in T1): Events/incidents with a time/place you must remember, records of finance/work/contracts, financial instruments, schedules/manuals regularly referred to (repair schedule), and collaborating systems / external systems.

Seeing a noun and matching it to one of these buckets gives you a reason to keep it for closer inspection (a prompt to survive early pruning). A lot of physically visible things become classes because you track persistent information about them; some events become classes because they have state and participate in collaborations.

Formalize — the ECB (Entity-Boundary-Control) lens

A second, orthogonal grouping lens — prominent in OO design and previewable during analysis — sorts candidates into three kinds by role in a scenario. In UP and in Jacobson/Coad traditions (Horstmann T2 Ch.2 "systems and system interfaces," Larman T1 Ch.14–17 with GRASP):

• **Entity concepts — hold persistent information* that lives longer than a single interaction. They correspond to things you track over time: Sale, Loan, Reservation, Inventory, Ledger, booking records, room occupancy, passenger manifest. They do the core domain work* and retain state. Lifecycle: long-lived, auditable.

• **Boundary concepts — represent interaction between an actor and the system*. Display forms, login screens, receipt views, confirmation pages, handheld register displays — the surfaces the actor sees and touches* to provide input or see results. They handle presentation and input adaptation, not business rules. Example: LoginScreen, BookingForm, ReceiptView.

• **Control concepts — manage a scenario and delegate work*. A play-game manager, a booking coordinator, a network-and-security controller, a ReservationCoordinator — they receive input from boundary ideas and hand coordinated work to* entity ideas that do the persistent core job. They are deliberately lean coordinators, not gods.

Linking the three explicitly (e.g., with links typed as ostom and clc in the teaching diagram — lecture's shorthand) helps the team see that a collaboration path is complete: Actor ↔ Boundary ↔ Control ↔ Entity. A use case that lacks one link often has a gap — e.g., input with no control to delegate, or a control with no entity to retain outcome.

Adjectives and grammar matter operationally (linked explicitly in lecture):

• An adjective that adds behavior ("corporate negotiable reservation") may hint at an inheritance distinction (a subclass or strategy hierarchy) rather than a simple attribute — revisited in inheritance.
• Passive voice hides actors: "the booking was confirmed" hides who confirmed. Turning it into active voice — "the system confirmed the booking" or "the receptionist confirmed the booking" — surfaces the subject noun that may be a missing candidate (often a Control or Actor). Scanning for passive sentences is a concrete pruning/discovery habit.

These lenses are highlighted as within hearing even though full responsibility assignment (GRASP, operation contracts, interaction diagrams) is left to design — they give high-level clarity now and sharpen later assignment.

Formalize — what an association is (and is not) at this stage

An association in the domain model is a plain relationship between two classes that reflects how they connect in the real world — for example, a Teacher teaches Students, a Sale Paid-by Payment, a Reservation covers Stay.

Notation and intent in analysis (Larman T1 9.14–9.15):

• Drawn as a simple line between two class boxes, optionally named with the real-world phrase people use — the ClassName-VerbPhrase-ClassName format (Sale Paid-by CashPayment, Stores-*, Houses). The name starts with a capital letter (UML classifier of links); the optional reading-direction small arrow has no model meaning — it only aids reading, and is often omitted. Multiplicity on the ends may be shown where the need-to-remember constraint is clear (e.g., Sale 1 Contains 1..* SalesLineItem).
• Need-to-remember criterion: add an association when knowledge of the relationship needs to be preserved for some duration — milliseconds to years, depending on context. Must we remember which Reservation covers which Stay to reconstruct a stay or compute a charge? Must we remember which Sale was Captured-on which Register for audit? Then the line must be there. Conversely, a transitory look-up (Cashier glancing at ProductDescriptions) that leaves no memory need not be an association.
• What is excluded now: inheritance, polymorphism, aggregation/composition adornment, navigability direction, and role multiplicity refinements are not added at this stage; those decisions belong to design. At this stage associations are inherently bidirectional in meaning — logical traversal is abstract, not a software navigation claim.

Why identification matters: a domain model without associations is just a list of nouns; with associations it becomes a picture of collaboration — how work moves between participants to achieve a requirement. A practical check: play through a use case and at each step ask "who talks to whom to make this step happen?" If coordination is required and no line exists, a gap exists.

Larman's Common Associations List (T1 Table 9.2) is the companion prompt for finding them — A is a transaction related to B (CashPayment—Sale), is a line item of B (SalesLineItem—Sale), is a product/service for B, is a role related to B, is physical/logical part of B, is contained in/on B, is a description for B, is known/recorded/reported/captured in B, is a member of B, is an organizational subunit of B, uses/manages/owns B, is next to B — run each category against the candidate list as a cross-check.

Formalize — the glossary as the model's companion artifact

A glossary (UP Glossary, T1 Fig. 9.1) is the artifact that holds the domain vocabulary: each key concept and significant term is listed with its meaning in the domain's own phrasing — not in code terms. It is built alongside the domain model, and the two are kept consistent.

What it contains:

• For every conceptual class and for significant attributes/association names, the term and its definition (e.g., Reservation: "a guest's commitment to hold specified rooms over a dated Stay, with a confirmation status and associated payment undertaking").
• For near-synonyms observed in text (customer vs. client in the resort story; student vs. learner elsewhere), the glossary records one preferred term — the one the domain actually uses — and lists the others as aliases to be dropped from the model. This is the judgment that makes redundancy pruning (8.8) defensible rather than arbitrary.
• Attribute requirements implied by the domain model (allowed values, optionality like middleName : [0..1]) may be transferred to the glossary as the data dictionary companion, because people rarely re-read the diagram for such rules and diagrams are often discarded after iteration (Larman 9.16 guidance).

Habit recommended in the lecture: every time you meet a new term that matters — whether it becomes a class or remains an attribute — define it in the glossary in the domain's own phrasing right then. That entry then anchors later discussion. When you add or rename an association, you can check it against the glossary ("is 'hosts' the verb the resort's staff uses?") rather than guessing what a word meant that week. In artifact terms (T1 Fig. 9.1): use-case concepts + expert insight → domain model ↔ glossary → operation contracts / Design Model / data dictionary.

Formalize — representation gap and the domain-language lever

The representation gap is the distance between how the real world describes a problem and how software describes it. The larger the gap, the more translation — and misunderstanding — sits between a domain stakeholder's mental model and the software model.

In older function-oriented work using C-like languages, that gap was large: real-world things were encoded as functions and record structs with names far from everyday speech (Larman T1 9.3, Fig. 9.6: the 1953 payroll program as 1000010101... as the extreme gap). Someone looking at that encoding cannot see the payroll domain; each change requires re-translating domain intent into procedural form.

Object-oriented analysis aims to shrink that gap by using the same terms in the analysis model that people use in the world — class names, attribute names, and association verb phrases drawn directly from domain speech. That is why every guideline so far converges here:

• Class names are domain nouns (Sale, Reservation, Payment, Guest) rather than technical labels (TxnManager, DataStore).
• Association names are domain verbs (hosts, covers, is assigned to, settles) rather than generic has / uses or storage labels (FK_Reservation_Room).
• Domain model is a conceptual-perspective model that inspires — but is not identical to — the software classes of the Design Model's domain layer. In the design layer, the object-oriented developer takes inspiration from real-world names (domain Payment → software Payment with getBalance(): Money) so the software representation and the mental model stay low-gap (T1 Fig. 9.6).

The gap is never zero — software must still make implementation choices (visibility, navigation, persistence) that the domain does not — but reducing naming and conceptual distance has a practical time-and-money consequence: comprehension and modification become cheaper because reviewers and domain experts remain able to read and correct the model.

Formalize — seven-step workflow from raw candidates to light class diagram

The lecture ties all prior lenses into a concrete, repeatable workflow (the same flow underlying Larman T1 Ch.9–10 for moving requirements → domain model → SSD/contracts):

1. Start textual analysis on the use cases. Underline every noun / noun phrase and collect them into a rough candidate list. Include all that appear; do not filter while gathering. The list is possibilities, not answers. Optionally run Bus/auto tagging to check manual capture — but keep judgment manual.

1. Optionally tag / Bus-tag the text. Use automated noun surfacing as a completeness check, not a decision-maker. Merge tagged results into your rough list.

1. Build two working lists. Keep a stronger set you are confident about and a weaker set you are unsure about (might be an attribute, vague, decorative, or outside scope). Calling them strong and weak, or vehicles for consideration, keeps weaker ideas visible rather than hiding them prematurely. That two-list habit is presented as the primary safeguard against losing information under time pressure.

1. *Evaluate each candidate with a strong reason to keep or drop.* Pruning reasons taught (lecture + T1 guidance) — use them as audit labels:

• Redundant — two or three nouns mean the same thing (customer = client; reservation = booking in this domain's speech) → keep the term the domain actually uses, drop the rest as aliases in the glossary.
• Irrelevant — noun sits only in narrative color and has nothing to do with the requirement being solved.
• Vague / ill-defined — high-level phrase you cannot picture as an object with state, behavior, and identity (e.g., "system" as a generic manager, "data" as a substance).
• Attribute — simple text/number that belongs as a feature of another concept rather than its own concept (sale.date, stay.nights, room.roomNumber). Apply the class-vs-attribute test (8.6).
• Operation — a verb-like idea that describes work but not a durable participant ("booking" as the act of booking vs. Reservation the undertaking). Operations become responsibilities, not classes.
• Out of scope — concept outside the system boundary set in use-case scoping (8.2) — real but not our problem this iteration.
• Additional checks:
• An incident or event that does have state, behavior and identity (e.g., Sale, Payment, GameMove) can stay as an object even though it is an event.
• A role that adds behavior may stay as a class/distinct type rather than a mere label.
• An adjective that merely qualifies a value stays as part of an attribute (roomType = "deluxe"); an adjective that adds behavior / distinct rules may hint at a separate class or inheritance later ("corporate negotiable reservation" with distinct pricing rules → NegotiableReservation specialization).
• Passive voice surfaces hidden subjects — turning "the booking was confirmed" into active voice ("the Receptionist confirmed the booking" / "the System confirmed the booking") names a candidate actor/control that passive phrasing hid.

1. When you drop an item, you need a strong reason; when you keep one, you need positive evidence. Evidence for keeping: the candidate carries state + behavior + identity, participates in relationships (associations you can name), or groups many instances (broad extension). If unsure between attribute and class, the tie-breaker from 8.6 applies: keep it as a class for now — you can fold it in design; recovering a dropped concept is harder.

1. Add known attributes to the remaining classes and sketch associations between them using real-world phrases. Keep the result as a light class diagram — a high-level picture with at most a few attributes per box, plain named associations, no methods — that together with the glossary shows the current understanding. Use the need-to-remember association criterion and the Common Associations List (8.7) as a completeness check.

1. Test the set against use cases with CRC-style play. Walk 2–3 stories: can these objects, talking through their associations, realize the required flows? Missing participants or missing links show up immediately as play stalls. Adjust and re-prune.

An active-voice habit helps during pruning (turn passive sentences into active ones to surface hidden subjects), and scanning for adjectives that carry behavior surfaces inheritance hints without yet committing to design detail.

Formalize — case-study discipline and iteration discipline

The lecture turns the workflow into a practice prescription and an iteration ethic that together replace "read more theory."

Practice prescription — 4-to-5 full cases, hands-on:

The central exercise uses a resort reservation system case study that spans two pages of narrative, but parallel quick studies are named for an ATM system, a library system, and a restaurant booking system, alongside Larman's point-of-sale terminal running example. The instruction is tactile — take pen and paper; read the two-page story at least two or three times to grasp what must be built; draw a light activity/Data Flow view by hand to see inputs and outputs; underline every noun; extract candidates; group similar objects into classes; reason explicitly about which candidates should become attributes or disappear as redundant or irrelevant.

The discipline advice is quality over quantity: solve at least four or five complete cases end-to-end — analysis through design to programming — rather than many partial sketches. Four polished, fully reasoned cases teach more than many thin ones because the same judgments recur (synonym customer vs. client; whether campus / city should be a class; whether rate / night should be a class or a value; how an event with state earns a class) and the learner's feel for when a noun should stay, become an attribute, or go becomes faster and better grounded. The lecture is blunt: no amount of reading substitutes for that hands-on repetition.

Iteration discipline — two guardrails that run through every case:

1. *Do not rush to name every future object at once. Make a first cut that is complete for the current iteration's requirements, then refine across analysis → design → implementation as understanding grows. The first cut made in analysis is where you practice thinking in objects*; later passes make that thinking sharper. Early big-modeling that attempts completeness for imagined futures is labeled analysis paralysis (T1 9.4) — it will never be truly correct nor repay the time.
2. Always constrain within the current iteration's requirements and its system boundary. Expanding beyond that scope early makes the model hard to finish and hides the idealized behavior you are trying to capture — what the system should do well, not just what happens manually today. The result should be better than the existing manual workaround, not a transcription of it.

Together these say: finish a coherent iteration, auditably reasoned, then build on it.

Formalize — settled state before moving to design

By the time the candidate list has been pruned, each surviving class should have:

• a short, plain purpose statement (intension) —
• a sense of whether it groups many instances (extension) and any known attributes that are simple values, and
• any associations in domain language that wire it to collaborators.

The surviving set is naturally viewed through the entity / boundary / control lenses (preview from 8.6, foreshadowing design):

• **Entity ideas that retain persistent information** remain central: Reservation, Stay, Room occupancy, Sale, Loan, booking records, Ledger. They live longer than any single interaction and do the domain's persistent core work.
• **Boundary ideas that sit on the actor–system edge** hold the interaction: login screens, booking forms, display views, receipt views — the surfaces actors touch to provide input or see results.
• **Control ideas that coordinate work* sit between them: a BookingCoordinator / PlayGameManager / Network-and-Security Controller that receives input from boundary ideas and hands work to entity ideas. Login screens as a boundary where the actor interacts, the Security Control as the coordinator that receives that input, and the underlying profile/booking data as entities* that retain state — the lecture's login→security→data chain — is the canonical ECB wiring.

The lecture also marks two transition notes:

1. What was covered so far in analysis proper: classes, associations, and attributes — the vocabulary and wiring that lets the domain be talked about completely for this iteration.
2. What comes next: the last part of analysis after the domain model is system contracts (in Larman's UP sequence — Ch.11 / SSDs + contracts extending from use cases and the domain model), followed by movement into object-oriented design where responsibilities become detailed, methods appear, and GRASP assignment, interaction diagrams, and visibility/navigation choices are made.

The classes to carry forward are intentionally limited — the lecture explicitly notes that today it built the ninth class concept precisely to make the next design step manageable. That pacing is itself an iteration lesson: finish a coherent cut, then build on it; do not carry a bloated analysis into design and hope design will sort it out.