Chapter 4: Domain Models
Source files used: Lecture 4 - Domain Models; textbook (applying-uml-and-patterns.pdf) Chapter 10 as support.
A focused guide to domain models for the COMP302 Midterm 1. It covers what a domain model is (and is not), how to find conceptual classes, description classes, associations, attributes, and the most common modeling mistakes. Guide 3 produced use case text; this guide turns that text into the first object-oriented model.
Roadmap: 1 OOA/D and UP → 2 Inception and Requirements → 3 Use Cases → 4 Domain Models → 5 SSDs and Contracts → 6 Logical Architecture → 7 Interaction Diagrams
What a Domain Model Is
A Visual Dictionary of the Domain
A domain model is the most important and classic model in OO analysis. It illustrates the noteworthy concepts in a domain and is a source of inspiration for designing some software objects later.
It is drawn with UML class diagram notation in the conceptual perspective, and it shows:
- domain objects (conceptual classes),
- associations between conceptual classes,
- attributes of conceptual classes.
It is a UP Business Modeling artifact. The textbook defines a conceptual class as an idea, thing, or object, described by its symbol (name, such as Sale), intension (definition: “represents the event of a purchase transaction, and has a date and time”), and extension (the set of all examples: every sale).
A partial NextGen POS domain model from the lecture:
+---------------+ 0..1 Records-sale-of 1 +------+ * Stocked-in 1 +---------+
| SalesLineItem |------------------------| Item |----------------| Store |
|---------------| +------+ |---------|
| quantity | | address |
+---------------+ | name |
| 1..* +---------+
| Contained-in | 1
| 1 | Houses
+---------------+ 0..1 Captured-on 1 +----------+ 1..* |
| Sale |----------------------------------| Register |-------+
|---------------| +----------+
| date |
| time |
+---------------+
| 1
| Paid-by
| 1
+---------------+
| Payment |
|---------------|
| amount |
+---------------+What a Domain Model Is Not
A domain model is a visualization of things in a real-situation domain, not of software objects such as Java or C# classes. So these do not belong in it:
- software artifacts, such as a window or a database (unless the domain itself is software concepts, such as a model of GUIs),
- responsibilities or methods.
AVOID: SalesDatabase <- software artifact, not part of the domain
AVOID: Sale | date, time | print() <- software class with a method
OK: Sale | dateTime <- real-world concept with an attributeExam Trap #1: Drawing a database, a window, or methods in the domain model. These are the first things a “what should not be here?” question looks for.
Lowering the Representational Gap
The representational gap is the gap between our mental model of the domain and its representation in software (textbook). A key OO idea: name software classes in the domain layer after concepts in the domain model, and give them domain-familiar information and responsibilities.
Domain model: Payment (amount) --Pays-for-- Sale (date, time)
|
| inspires the names and objects of
v
Design model: Payment (amount: Money; getBalance(): Money)
--Pays-for-- Sale (date: Date, startTime: Time; getTotal(): Money)The two Payments are not the same thing: the concept inspired the naming and definition of the software class. This lowers the representational gap between how stakeholders think about the domain and the code.
Finding Conceptual Classes
Three Strategies
- Reuse or modify existing models. Published domain and data models exist for common domains (inventory, finance, health). Excellent, but outside the course’s scope.
- Use a category list.
- Identify noun phrases.
Category List
The lecture’s table, shortened. Start with transactions, since they involve money:
| Category | Examples |
|---|---|
| business transactions | Sale, Payment, Reservation |
| transaction line items | SalesLineItem |
| product or service related to a transaction | Item, Flight, Seat, Meal |
| where the transaction is recorded | Register, Ledger, FlightManifest |
| roles of people or organizations (actors) | Cashier, Customer, Store, MonopolyPlayer, Passenger, Airline |
| place of transaction or service | Store, Airport, Plane, Seat |
| physical objects | Item, Register, Board, Piece, Die, Airplane |
| descriptions of things | ProductDescription, FlightDescription |
| catalogs | ProductCatalog, FlightCatalog |
| other collaborating systems | CreditAuthorizationSystem, AirTrafficControl |
The full list also has noteworthy events, containers and things in containers, records (Receipt, MaintenanceLog), financial instruments (Cash, Check), and schedules or documents (RepairSchedule).
Noun Phrase Identification
Linguistic analysis: identify the nouns and noun phrases in textual descriptions of the domain (such as the use cases) and treat them as candidate conceptual classes or attributes. From Process Sale, iteration 1, the lecture gets these candidates:
Register Item Store Sale SalesLineItem Cashier
Customer Ledger CashPayment ProductCatalog ProductDescriptionThe textbook warns that a mechanical noun-to-class mapping is risky, because words are ambiguous; use judgment.
The Mapmaker Strategy
A textbook guideline for naming and scoping:
- use the existing names in the territory (a library’s “Borrower”, not your own word),
- exclude irrelevant features (no Pen or PaperBag in a POS model),
- do not add things that are not there.
Attributes vs Classes
The Number-or-Text Rule
Should something be an attribute of a class, or a separate conceptual class?
If we think of something as simply a number or text in real life, it should be an attribute. Otherwise, it should be a conceptual class.
WORSE: Sale | store BETTER: Sale -- Store | phoneNumber
WORSE: Flight | destination BETTER: Flight -- Airport | nameA store is not a number or text (it is an organization occupying space), and a destination is an airport, not a number. The textbook adds: if in doubt, make it a separate concept; attributes should be fairly rare in a domain model.
Exam Trap #2: Modeling a real-world thing as an attribute because it “feels small”.
WRONG: Flight | destination : String
CORRECT: Flight ---- Flies-to ---- AirportDescription Classes
What and Why
A description class contains information that describes something else. Example: ProductDescription records the price, picture, and text description of an item.
Why not put all that information in the Item class?
- The information must be stored even when no items of that product currently exist (the store sold out, but someone still asks the price).
- It avoids duplicating product information in every item object.
- The serial number belongs to the item; the picture of the product belongs to the description.
WORSE: all product information inside every Item
+---------------+
| Item |
|---------------|
| description |
| price |
| serial number |
| itemID |
+---------------+
BETTER: one description describes many items
+--------------------+ 1 Describes * +---------------+
| ProductDescription |---------------------| Item |
|--------------------| |---------------|
| description | | serial number |
| price | +---------------+
| itemID |
+--------------------+The same idea for flights: even when a flight is not scheduled that day, its flight description exists.
Flight (date, time) * -- Described-by -- 1 FlightDescription (number)
FlightDescription * -- Describes-flights-to -- 1 Airport (name)The textbook’s rule: add a description class when (1) a description is needed independent of the current existence of the things it describes, (2) deleting those things would lose information that must be kept, or (3) it reduces redundant or duplicated information.
Associations
What Is an Association?
An association is a relationship between classes (more precisely, between their instances) that indicates some meaningful and interesting connection. Show associations that are needed to satisfy the information requirements of the current scenarios, and that help in understanding the domain.
Include:
- need-to-remember associations: knowledge of the relationship must be preserved for some duration,
- associations derived from the Common Associations List.
Lecture examples:
| Relationship | Remember it? |
|---|---|
| Sale and its SalesLineItems | yes, or you cannot reconstruct a sale, print a receipt, or compute the total |
| Cashier looks up a ProductDescription | no |
| which Square a Monopoly player is on | yes |
| the dice total that decided the move | no, do not store it with the Dice or the Square |
Association Notation
+----------+ 1 Records-current > 0..1 +------+
| Register |-------------------------------------| Sale |
+----------+ +------+
1 and 0..1 multiplicities, one at each end
Records-current association name (capitalized)
> optional reading direction arrow- An association is a line between classes with a capitalized association name.
- Each end may carry a multiplicity expression.
- The association is inherently bidirectional: logical traversal from either side is possible. This traversal is purely abstract; it is not a statement about connections between software entities.
- The optional reading direction arrow only says which way to read the name. It is often excluded.
Naming Associations
Use the ClassName-VerbPhrase-ClassName format, so it reads as a meaningful sentence. Names such as “Has” or “Uses” are usually poor because they add no understanding.
WRONG: Sale Uses CashPayment Player Has Square
CORRECT: Sale Paid-by CashPayment Player Is-on SquareMultiplicity
Multiplicity defines how many instances of class A can be associated with one instance of class B. A single Store can be associated with many (*) Items.
| Expression | Meaning |
|---|---|
* | zero or more (“many”) |
1..* | one or more |
1..40 | one to 40 |
5 | exactly 5 |
3, 5, 8 | exactly 3, 5, or 8 |
0..1 | zero or one (optional) |
Multiple Associations Between the Same Two Classes
Two classes may have several associations; this is not uncommon. Flying-to and flying-from are different relationships, so they are drawn separately:
+--------+ * Flies-to 1 +---------+
| |----------------------------| |
| Flight | | Airport |
| |----------------------------| |
+--------+ * Flies-from 1 +---------+Common Associations List
| A … B | Examples |
|---|---|
| A is a transaction related to another transaction B | CashPayment to Sale, Cancellation to Reservation |
| A is a line item of a transaction B | SalesLineItem to Sale |
| A is a product or service for a transaction (or line item) B | Item to SalesLineItem, Flight to Reservation |
| A is a role related to a transaction B | Customer to Payment, Passenger to Ticket |
| A is a physical or logical part of B | Drawer to Register, Square to Board, Seat to Airplane |
| A is physically or logically contained in/on B | Register to Store, Item to Shelf, Passenger to Airplane |
| A is a description for B | ProductDescription to Item, FlightDescription to Flight |
| A is known/logged/recorded/reported/captured in B | Sale to Register, Piece to Square, Reservation to FlightManifest |
| A is a member of B | Cashier to Store, Player to MonopolyGame, Pilot to Airline |
| A is an organizational subunit of B | Department to Store, Maintenance to Airline |
| A uses or manages or owns B | Cashier to Register, Player to Piece, Pilot to Airplane |
| A is next to B | SalesLineItem to SalesLineItem, Square to Square, City to City |
Attributes
Attribute Basics
An attribute is a logical data value of an object. The full UML attribute syntax is:
visibility name : type multiplicity = default {property-string}
- dateTime : Date private attribute
+ pi : Real = 3.14 {readOnly} public, read-only, initialized
middleName : [0..1] optional value
/ total : Money derived attributemiddleName : [0..1]embeds a requirement (a domain rule) in the model; ideally such attribute requirements go in the Glossary.- A derived attribute is marked with
/: it is noteworthy but can be calculated, such as Sale’s/totalfrom its SalesLineItems, or/quantityderived from the multiplicity of Records-sale-of. It may still be recorded.
Suitable Attribute Types: Data Types
Attribute types should be data types: “primitive” types such as number, boolean, character, string (text), date, time, and enumerations (Size = {small, large}). Other common data types: Address, Color, geometrics (Point, Rectangle), PhoneNumber, SSN, UPC, SKU, ZIP or postal codes.
A data type is a set of values for which unique identity is not meaningful: equality is by value. Two separate instances of the integer 5, of the string ‘cat’, or of the date “Nov. 13, 1990” are not worth distinguishing. Two Person instances both named “Jill Smith” are: they can be different people.
The type of an attribute should not be a complex domain concept such as Sale or Airport. Relate conceptual classes with associations, not attributes:
WORSE: Flight | destination
BETTER: Flight 1 -- Flies-to -- 1 Airport
WORSE: Cashier | name, currentRegister
BETTER: Cashier | name 1 -- Works-on -- 1 Register | numberWhen to Define a New Data Type Class
Represent something as a new data type class when:
- it is composed of separate sections (phone number, name of person),
- it has operations such as parsing or validation (social security number),
- it has other attributes (a promotional price with a start and end date),
- it is a quantity with a unit (a payment amount has a currency),
- it is an abstraction of one or more types (ItemID generalizes UPC and EAN).
Whether to draw such a type (ItemID, Address) as a separate box with an association, or as an attribute type (itemId : ItemID), has no single correct answer: both are OK, depending on what you want to emphasize.
No Foreign-Key Attributes
Attributes should not be used to relate conceptual classes. The most common violation is a foreign-key attribute, as in relational database design:
WORSE: BETTER:
+-----------------------+ +---------+ 1 Works-on 1 +----------+
| Cashier | | Cashier |----------------| Register |
|-----------------------| |---------| |----------|
| name | | name | | number |
| currentRegisterNumber | +---------+ +----------+
+-----------------------+Exam Trap #3: Storing the ID or serial number of another domain object as an attribute. Draw an association to that object instead. (An object’s own identifier is fine: the NextGen model gives Register and Cashier an id.)
Quantities and Units
Most numeric quantities should not be plain numbers. “The price was 13” says little: euros? kilograms?
NOT USEFUL: Payment | amount : Number
BETTER: Payment | amount : Quantity (Quantity has an amount and a Unit)
BETTER: Payment | amount : Money (Money: a Quantity with a currency unit)The Two Case Studies
NextGen POS (Process Sale, Cash-Only, Iteration 1)
The full iteration-1 model from the lecture, as an association list (multiplicity next to each class):
SalesLineItem 1..* Contained-in 1 Sale
SalesLineItem 0..1 Records-sale-of 1..* Item
ProductCatalog 1 Contains 1..* ProductDescription
ProductDescription 1 Describes * Item
ProductCatalog 1 Used-by * Store
Store 1 Stocks * Item
Store 1 Houses 1..* Register
Ledger 1 Records-accounts-for 1 Store
Ledger 1 Logs-completed * Sale
Sale 0..1 Captured-on 1 Register
Sale 1 Paid-by 1 CashPayment
Sale 1 Is-for 1 Customer
Cashier 1 Works-on 1 Register
Attributes: Sale.dateTime, Sale./total, SalesLineItem.quantity,
ProductDescription.itemID, .description, .price, Store.name, .address,
CashPayment.amountTendered, Register.id, Cashier.idWhy these attributes: amountTendered decides if payment is sufficient and computes change; description, itemID, and price show and look up items and compute totals; dateTime goes on the receipt; quantity records “five packages of tofu”; name and address go on the receipt.
Monopoly (Play Monopoly Game, Simplified)
Die 2 Played-with 1 MonopolyGame
MonopolyGame 1 Played-on 1 Board
Board 1 Contains 40 Square
Player 2..8 Plays 1 MonopolyGame
Player 1 Owns 1 Piece
Piece 0..8 Is-on 1 Square
Attributes: Die.faceValue (to compute the move distance), Square.name (for
the trace output), Player.name, Piece.nameExam-Style Practice Problems
Problem 1: What Does Not Belong?
Question: The Fall 2024 Midterm 1 study sheet shows this domain model and asks which elements should not be in it:
Games Database (associated with Computer Game: stored-in)
Player: - ID, + name, + email address, - nick name
Computer Game: + genre, + name, + getName()
Publisher: - website, + name
Player 1 owns 0..* Computer Game; Computer Game 1..* published by 1 PublisherAnswer:
- Games Database (and its stored-in association): a software artifact, not a real-world concept.
- getName(): a method; domain models have no responsibilities or methods.
- The + / - visibility markers: public/private is a software design detail, so they are best dropped too.
Problem 2: Taxi Fleet Domain Model
Question: The study sheet’s scenario: a taxi fleet company with drivers working for the company, taxis owned by the company, the assignment of drivers to taxis at a given moment, and whether a taxi is occupied (transporting a passenger). Draw a domain model.
Answer:
+-------------+ 1 Employs * +-------------+
| TaxiCompany |---------------------------| Driver |
|-------------| |-------------|
| name | | name |
+-------------+ +-------------+
| 1 | 0..1
| Owns | Assigned-to
| | 0..1
| * +-------------+
+----------------------------------| Taxi |
|-------------|
| plateNumber |
| occupied |
+-------------+- “assigned” relates two concepts, so it is an association (not a
taxiIDattribute on Driver). - “occupied” is a yes/no value, so it is a Boolean attribute of Taxi.
Problem 3: Short Answers
Question: (a) Can you have multiple associations between the same two domain classes? (b) Why don’t we represent the id of other domain objects as attributes, and what do we do instead?
Answer:
- (a) Yes, when they are distinct relationships: Flight Flies-to Airport and Flight Flies-from Airport.
- (b) An id of another object is a foreign key, a relational database design detail that hides the real relationship. Draw an association between the two conceptual classes instead.
Common Exam Traps
1. Software Artifacts in the Domain Model
WRONG: SalesDatabase, LoginWindow, GameManager
CORRECT: real-world concepts only: Sale, Register, PlayerWhy: A domain model is not a picture of software objects.
2. Methods in the Domain Model
WRONG: Sale | date, time | print()
CORRECT: Sale | dateTimeWhy: Responsibilities and methods are purely software concepts.
3. Foreign Keys Instead of Associations
WRONG: Cashier | currentRegisterNumber
CORRECT: Cashier 1 -- Works-on -- 1 RegisterWhy: Conceptual classes are related with associations, not attributes.
4. A Concept Used as an Attribute Type
WRONG: Flight | destination : Airport
CORRECT: Flight -- Flies-to -- AirportWhy: Attribute types should be data types, not complex domain concepts.
5. A Real-World Thing as an Attribute
WRONG: Sale | store
CORRECT: Sale -- StoreWhy: If it is not a number or text in real life, it is a conceptual class.
6. Vague Association Names
WRONG: Player Has Square, Sale Uses CashPayment
CORRECT: Player Is-on Square, Sale Paid-by CashPaymentWhy: Use ClassName-VerbPhrase-ClassName names that add meaning.
7. No Description Class
WRONG: Item | description, price, serial number, itemID
CORRECT: ProductDescription | description, price, itemID
1 -- Describes -- * Item | serial numberWhy: Prices must survive when items sell out, and data must not be duplicated.
8. Plain Numbers for Quantities
WRONG: Payment | amount : Number
CORRECT: Payment | amount : MoneyWhy: A quantity without its unit is ambiguous.
9. Reading Arrow Mistaken for Navigation
WRONG: "Records-current > means Register can reach Sale but not the reverse."
CORRECT: "The arrow only tells you which way to read the name."Why: Associations in a domain model are bidirectional and abstract.
Final Tips for the Midterm
- Run the “not allowed” checklist first: software artifacts, methods, foreign keys, concept-typed attributes, visibility markers.
- Apply the number-or-text rule: anything else becomes a class with an association.
- Name every association with a verb phrase: and put a multiplicity on both ends.
- Reach for a description class: whenever data must outlive the things it describes or would be duplicated.
- Mine the use case text: noun phrases plus the category list give the candidate classes fast.
- Know the vocabulary terms: conceptual class, description class, association, representational gap.
Good luck on the midterm! You’ve got this.