"I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant!" -- George Romney, 1967 U.S. Presidential Candidate


Domain Modeling



o       When we build a domain model, we start off by trying to identify objects in the real world that is, the main conceptual objects that are going to participate in this
system. When you design object-oriented software, you try to structure your software around this real-world, problem space objects.


o       The domain modeling process, for which we’re following the Object Modeling Technique (OMT) school of thought, is fundamentally an inside-out approach. Inside out means
 that we’re starting with the core objects in the system, then working from the inside outward, to see how those objects are going to participate in the system we’re building.


o       The best sources of domain objects are likely to be the high-level problem statement, and expert knowledge of the problem space.


o       Much like an entity-relationship diagram (ERD), our domain model, updated to show associations—the relationships between pairs of objects—should be a true
statement about the problem space. This model serves as the foundation of our future class model.


o       It is recommended that you establish a time budget for building your initial domain model. You’re not going to make it perfect, anyway, so do it quickly and expect to fix it up as you proceed. You should be vigilant about making necessary adjustments to your analysis-level class model in response to occurrences during robustness analysis and throughout the project.


Should we

1- Start assigning multiplicities to associations right off the bat?

2- Do noun and verb analysis exhaustively?

3- Assign operations to classes?

4- Debate whether to use aggregation or composition?

5- Presume a specific implementation strategy?




What are Three Strategies to Find Conceptual Classes?

1.      Reuse or modify existing models. This is the first, best, and usually easiest approach. There are published, well-crafted domain models and data models (which can be modified into domain models) for many common domains, such as inventory, finance, health, and so forth. Example books Analysis Patterns by Martin Fowler, and the Data Model Resource Book (volumes 1 and 2) by Len Silverston.

2.      Use a category list.

3.      Identify noun phrases.


Table 9.1. Object Category List.



business transactions

Guideline: These are critical (they involve money), so start with transactions.

Sale, Payment


transaction line items

Guideline: Transactions often come with related line items, so consider these next.


product or service related to a transaction or transaction line item

Guideline: Transactions are for something (a product or service). Consider these next.


Flight, Seat, Meal

where is the transaction recorded?

Guideline: Important.

Register, Ledger


roles of people or organizations related to the transaction; actors in the use case

Guideline: We usually need to know about the parties involved in a transaction.

Cashier, Customer

Passenger, Airline

place of transaction; place of service


Airport, Plane, Seat

noteworthy events, often with a time or place we need to remember

Sale, Payment, Flight

physical objects

Guideline: This is especially relevant when creating device-control software, or simulations.

Item, Register , Airplane

descriptions of things





Guideline: Descriptions are often in a catalog.



containers of things (physical or information)

Store, Airplane

things in a container

Item Passenger

other collaborating systems



records of finance, work, contracts, legal matters

Receipt, Ledger


financial instruments

Cash, Check


schedules, manuals, documents that are regularly referred to in order to perform work






  • Analysis: What does the software do
  • Design: How does it do it

Requirements are most associated with Analysis

  • What does the customer want?
  • More importantly, what does the customer need?
    • Can be more involved than simply asking them what they want!
    • Requirements elicitation techniques

Requirements can be stated well or poorly

  • What criteria are used to determine how well requirements have been stated?
  • Requirements analysis vs. system analysis

Requirements analysis: What should the system do?

System analysis: What the system does.

Requirements are usually fairly vague. System analysis must remove the vague aspects of requirements.


Requirement: Customers must be able to log in to our website

What effect does the above requirement have on our system?