Object-Oriented Analysis: Understanding the Problem Domain

Introduction

Up to this point, we have learned how objects work.

We understand:

Objects
Classes
State
Behavior
Relationships
Encapsulation
Abstraction
Inheritance
Polymorphism
Information Hiding

These concepts teach us how to build objects.

However, they do not answer a far more important question:

Where do objects come from?

Suppose a product manager walks into your office and says:

“We need an online hotel booking system.”

That's all.

There is:

• No design
• No database
• No APIs
• No UML diagrams
• No existing code

There is only a business problem waiting to be solved.

Yet, somehow, experienced software architects transform that vague sentence into something clear.

How do you go from:

English Requirements

to:

class Hotel {};
class Room {};
class Booking {};
class Guest {};

How do architects identify:

• Which objects should exits?
• What responsibilities each object should own?
• How objects collaborate?
• Which object owns which data?
• Which object performs which behavior?
• Which relationships should exist?
• Which objects should not exist at all?

These questions are far more difficult than writing C++ code.

In professional software development, coding is usually the easiest part.

The real challenge is discovering the correct modle of the business.

This process is called: Object-Oriented Analysis (OOA)

Historical Context

During the early years of software development, many projects followed a very simple process:

Requirements
     ↓
   Code

Developers jumped directly into implementations.

At first, this seemed efficient.

However, as systems became larger and more complex, serious problems began to appear.

Projects commonly suffered from:

• Rigid architectures
• Poor maintainability
• Incorrect abstractions
• Duplicate logic
• Tight coupling
• Massive refactoring
• High development costs

Developers realized that programming without understanding the business domain was like constructing a building without a blueprint.

Software engineering needed a disciplined approach that focused on understanding the problem before solving it.

Object-Oriented Analysis emerged as that solution.

Programming vs Software Design

Many beginners believe that software development is primarily about writing code. In reality, programming is only one activity within a much larger engineering process.

Consider the following analogy.

Suppose someone asks an architect to build a hospital.

The architect does not immediately begin laying bricks.

Instead, the architect first asks questions:

• How many patients will hospital serve?
• How many operating rooms are required?
• Where should the emergency department be located?
• How should ambulances enter the building?
• How do doctors move between departments?

Only after understanding these requirements does the architect create a blueprint.

Construction begins only after the blueprint is complete.

Software development follows the same principle.

Writing C++ code without understanding the problem is like constructing a building without architectural drawings.

The result may stand for a while, but it is unlikely to satisfy its intended purpose or adapt well to future changes.

Why Software Modeling Exists

Software systems have grown enormously over the past several decades.

Early computer programs often consisted of a few hundred lines of code written by a single developer.

Modern enterprise systems may contain:

• Millions of lines of code
• Thousands of classes
• Hundreds of developers
• Multiple teams working simultaneously
• Years or decades of maintenance

At this scale, simply “writing code” is not enough.

Engineers need a way to understand and organize complexity before implementation begins.

This need gave rise to software modeling.

Software modeling is the process of creating simplified representations of a software system before it is built.

A model is not the software itself.

It is an abstraction that helps us understand:

• What the system should do.
• What concepts exist.
• How those concepts relate.
• How responsibilities should be distributed.
• How different parts of a system collaborate.

Just as architects create building blueprint, software engineers create models of software systems.

These models help us reason about complexity long before implementation begins.

Every software project begins with a problem.

For example:

• Customers need to book hotel rooms online.
• Students need to enroll in university courses.
• Drivers need to find nearby passengers.
• Patients need to schedule medical appointments.

Notice that none of these problems mention:

• Classes
• Objects
• Databases
• APIs
• Design patterns
• Programming languages

They describe business needs.

Professional software development transforms those needs through several stages:

Business Problem
        │
        ▼
Requirements
        │
        ▼
Analysis
        │
        ▼
Design
        │
        ▼
Implementation
        │
        ▼
Working Software

Each stage answers a different question.

What is Object-Oriented Analysis and Design (OOAD)?

Object-Oriented Analysis and Design, commonly abbreviated as OOAD, is a systemtaic approach to developing object-oriented software.

Rather than jumping directly to code, OOAD introduces two important stages:

1. Object-Oriented Analysis (OOA)
2. Object-Oriented Design (OOD)

Together, they form a bridge between the problem domain and the software solution.

The overall process can be visualized as:

Business Requirements
        │
        ▼
Object-Oriented Analysis
        │
        ▼
Object-Oriented Design
        │
        ▼
Implementation (C++)

OOAD encourages engineers to think before they code.

Instead of asking:

“Which class should I write first?”

OOAD asks:

“What problem am I solving, and what is the best way to model it?”

This shift in mindset is what separates software design from programming.

The Two Halves of OOAD

Although often mentioned together, Object-Oriented Analysis and Object-Oriented Design are distinct activities with different goals.

Object-Oriented Analysis (OOA)

The purpose of OOA is to understand the problem domain.

It focuses on discovering:

• Business concepts
• Business rules
• Responsibilities
• Relationships
• Behaviors
• Collaborations

OOA asks questions such as:

What Is Object-Oriented Analysis?

Definition:

Object-Oriented Analysis is the process of identifying objects, responsibilities, relationships, and behaviors from a problem domain.

The emphasis is on understanding reality, not implementing software.

OOA asks questions such as:

• What concepts exist?
• What responsibilities do they have?
• How do they interact?
• What information do they own?
• How are they related?

Notice and important distinction:

Analysis != Design
Design != Implementation

Each stage has a different objective.

Object-Oriented Design (OOD)

Once the domain is understood, OOD focuses on designing a software solution.

It answers questions such as:

• Which classes should exist?
• Should a concept be represented as a class or an interface?
• Should objects communicate through composition or inheritance?
• Which design principle should guide the structure?
• Which design patterns, if any, are appropriate?

OOD transforms the conceptual understanding gained during analysis into a concrete software design that is maintainable, extensible, and ready for implementation.

OOA vs. OOD

OOAD Is an Iterative Process

A common misconception is that OOAD is a strictly linear sequence:

Requirements
      ↓
Analysis
      ↓
Design
      ↓
Code

Real projects are rarely this simple.

As the design evolves, you often discover that your understanding of the business was incomplete.

This leads you back to analysis.

Similarly, implementation may reveal that certain design decisions need refinement.

A more realistic view is:

Requirements
      │
      ▼
Analysis
   ↕
Design
   ↕
Implementation

The arrows between analysis and design go in both directions because software development is an iterative learning process.

Good architects continuously refine their understanding of the domain and adjust the design accordingly.

The Three Stages of Object-Oriented Development

Professional object-oriented development typically follows:

Analysis
    ↓
Design
    ↓
Implementation

Analysis

Focus:

What exists?

Example:

Customer
Order
Product
Payment

Design

Focus:

How should they interact?

Example:

Relationships
Interfaces
Patterns
Dependencies

Implementation

Focus:

How do we code it?

Example:

class Customer
{
};

Common Beginner Mistake

Beginners often do:

Requirements
      ↓
Implementation

Skipping analysis entirely.

Result:

Poor Object Models

Understanding the Domain

Object-Oriented Analysis begins with understanding the domain.

What Is a Domain?

A domain is:

The area of business or problem space for which software is beign built.

Examples:

Banking

Healthcare

Education

Hotel Booking

E-Commerce

Ride Sharing

Each domain has its own vocabulary, rules, and concepts.

Example Domain: Library Management System

Suppose we are developing software for a library.

Before writing any code, we observe the business.

Library Management System

Domain concepts:

Book

Member

Librarian

Loan

Reservation

These concepts exist before software exists.

You job is to discover them.

The Fundamental Rule

A critical principle:

Software should model the business, not the database.

Bad designers think:

Tables
Columns
Indexes

This is a mistake.

Instead, think about:

Books
Members
Loans
Reservations
Payments

Technology comes later.

Reality comes first.

Domain-Driven Thinking

Professional software designers first ask:

What concepts exist in reality?

Not:

What tables should I create?

This mindset is known as Domain-Driven Thinking.

The software should reflect the real business as naturally as possible.

Finding Objects

The primary goal of Object-Oriented Analysis is discovering the right objects.

But how can we identify them?

One of the oldest and most effective techniques is the Noun Technique.

The Noun Technique

One of the oldest OOA techniques.

Read the requirements carefully.

Highlight every noun.

Step 1

Read requirements carefully.

Example:

A customer can place an order.
An order contains products.
A payment is made for an order.

Step 2

Extract nouns.

Customer
Order
Product
Payment

These nouns become candiate objects.

Candidate means:

“This might become a class.”

Not every noun becomes a class.

They are simply starting points.

Another Example:

Requirement:

Students enroll in courses.
Professors teach courses.
Departments manage professors.

Nouns:

Student
Course
Professor
Department

Potential objects discovered.

Important Warning

Not every noun becomes a class.

Example:

System
Database
Screen
Information

Although they are nouns, they are usually not business objects.

The noun technique provides candidates., not final answers.

Analysis requires judgement.

Verb Analysis

After identifying nouns, analyze the verbs. Verbs usually represent behaviors.

Example:

Customer places order.

Verb:

places

Potential behavior:

customer.placeOrder();

Another Example

User logs in.

Verb:

logs in

Potential behavior:

user.login();

Another Example:

Librarian issues book.

Behavior:

librarian.issueBook();

Example Walkthrough

Requirement:

A user can add products to a cart and place an order.

Nouns:

User
Product
Cart
Order

Verbs:

Add
Place

Potential model:

class User;
class Product;
class Cart;
class Order;

Possible Behaviors:

cart.addProduct();
user.placeOrder();

Identifying Responsibilities

Once objects are identified:

Ask:

What is each object responsible for?

Responsibilities define an object's purpose.

Example: Library System

Book Responsible for:
	Title
	Author
	Availability
	ISBN
	Category

Member Responsible for:
	Borrowing books
	Returning books
	Reserving books
	Viewed borrowed items

Loan Responsible for:
	Issue Date
	Due Date
	Return Date
	Status
	Fine Calculation

Good object models emerge from good responsibility assignment.

Responsibility-Driven Design (RDD)

Professional object-oriented designers often follow a philosophy called Responsibility-Driven Design (RDD)

The central question is:

Who should do this?

Consider the requirement:

Calculate the total cost of an order.

Who should do it?

Possible answers:

User
Order
Database
UI

Correct:

Order

Because Order owns the collection of purchased items.

Therefore:

class Order
{
public:
    double calculateTotal();
};

Bad Design would place this responsibility elsewhere.

Example:

class User
{
public:

    double calculateOrderTotal();
};

The User does not own the order's contents.

The responsibilitu has been assigned incorrectly.

A good design aligns responsibility with ownership.

Identifying State

Each object usually owns information.

Ask:

What does this object know?

Example:

Customer knows:
	Name
	Email
	Phone Number
	Address

Order knows:
	Items
	Status
	Date
	Total

Product knows:
	Price
	Name
	Stock
	Category

These pieces of information later become attributes (member variables).

Identifying Behavior

Next Ask:

What can this object do?

Customer
	Place Order
	Update Address
	View Orders

Order
	Add Item
	Remove Item
	calculate Total
	Cancel
	Confirm Payment

Product
	Update Price
	Change Stock
	Apply Discount

Behavior should always match the object's responsibilies.

Object Discovery Example

ATM System

Requirement:

Customer inserts card.
Customer enters PIN.
ATM validates card.
Customer withdraws money.
ATM dispenses cash.

Nouns:

Customer
Card
ATM
PIN
Cash

Potential objects:

Customer
Card
ATM
Transaction
CashDispenser

Verbs:

Insert
Validate
Withdraw
Dispense

Possible behaviors:

atm.validateCard();
customer.enterPIN();
atm.withdrawMoney();
cashDispenser.dispenseCash();

The English requirements naturally reveal the object model.

Avoid Technical Objects Too Early

A common mistake among beginners is identifying technical classes during analysis.

Examples include:

DatabaseManager
NetworkHandler
FileManager
CacheController
Logger

These are implementation concerns.

During Object-oriented Analysis, the focus should remain on business concepts.

Instead of asking:

“What database classes do I need?”

Ask:

"What exists in the business?"

Technical objects can be introduced later during design.

Building a Domain Vocabulary

One of the most valuable outcomes of Object-Oriented Analysis is the creation of a shared language, often called a Ubiquitous Language.

Ubiquitous Language

Everyone involved in the project should use the same terminology.

For a hotel booking system:

Hotel System
	Guest
	Reservation
	Room
	Check-In
	Check-Out

Developers, analysts, testers, and business experts should all use these terms consistently.

Bad Vocabulary:

Developer says:
	BookingEntity
	
Business says:
	Reservation

Although they refer to the same concept, different terminology creates confusion.

Whenever possible, software should adopt the language used by the business.

Example: Food Delivery System

Requirement:

Customers place orders.
Restaurants prepare food.
Delivery partners deliver orders.
Payments are processed.

Objects:

Customer
Restaurant
Order
DeliveryPartner
Payment

Responsibilities:

Customer:
	Create Order
	
Restaurant:
	Prepare Food

Order:
	Track Status

DeliveryPartner:
	Deliver Order

Payment:
	Process Payment

Discovering Relationships

Once objects have been identified, determine how they relate to one another.

Ask questions such as:

Who knows whom?
Who owns whom?
Who collaborates(uses) with whom?
Who depends on whom?

Example:

Customer places Order
	Relationship Association

Order contains OrderItem
	Relationship Composition

Order uses PaymentService
	Relationship Dependency

CRC Cards

A classic Object-Oriented Analysis technique is the CRC Card, which stands for:

Class
Responsibilities
Collaborators

Each card represents one class.

Example Order:

Order:
Responsibilities:
	Add Item
	Remove Item
	Calculate Total
	Confirm Payment
	Generate Invoice

Collaborators:
	Product
	OrderItem
	Payment
	Customer

CRC cards provide a simple but effective way to evaluate whether responsibilities are assigned appropriately and whether collaboration between classes is logical.