"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?

NO

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.
Category	Examples
business transactions Guideline: These are critical (they involve money), so start with transactions.	Sale, Payment Reservation
transaction line items Guideline: Transactions often come with related line items, so consider these next.	SalesLineItem
product or service related to a transaction or transaction line item Guideline: Transactions are for something (a product or service). Consider these next.	Item Flight, Seat, Meal
where is the transaction recorded? Guideline: Important.	Register, Ledger FlightManifest
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	Store 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	ProductDescription FlightDescription
catalogs Guideline: Descriptions are often in a catalog.	ProductCatalog FlightCatalog
containers of things (physical or information)	Store, Airplane
things in a container	Item Passenger
other collaborating systems	CreditAuthorizationSystem AirTrafficControl
records of finance, work, contracts, legal matters	Receipt, Ledger MaintenanceLog
financial instruments	Cash, Check TicketCredit
schedules, manuals, documents that are regularly referred to in order to perform work	DailyPriceChangeList RepairSchedule

Requirements

• 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.

Example:

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

What effect does the above requirement have on our system?