Object-Oriented Analysis and Identifying

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

We understand:

Objects
Classes
State
Behavior
Relationships
Encapsulation
Abstraction
Inheritance
Polymorphism
Information Hiding

However, an important question remains:

Where do objects come from?

Suppose a product manager says:

“We need an online hotel booking system.”

How do you go from:

English Requirements

to:

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

How do architects identify:

Objects
Responsibilities
Relationships
Behavrios
Boudnaries

This process is called:

Object-Oriented Analysis (OOA)

Historical Context

Before Object-Oriented Analysis became popular:

Requirements
     ↓
   Code

Developers jumped directly into implementations.

Results:

Rigid Systems
Poor Maintainability
Wrong Abstractions
Massive Refactoring

Software engineering needed a disciplined way to model reality before coding.

Object-Oriented Analysis emerged as a solution.

What Is Object-Oriented Analysis?

Definition:

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

Notice:

Analysis != Coding

Analysis happens before implementation.

The goal is understanding.

The Three Stages

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

The Core Idea

Object-Oriented Analysis starts with:

Understanding the Domain

What Is a Domain?

A domain is:

The area of business or problem space the software operates in.

Examples:

Banking

Healthcare

Education

Hotel Booking

E-Commerce

Ride Sharing

Example Domain

Consider:

Library Management System

Domain concepts:

Book

Member

Librarian

Loan

Reservation

These concepts exist before software exists.

You job is to discover them.

Domain-Driven Thinking

A common mistake:

Think about Database Tables

Wrong.

Instead think:

What concepts exist in reality?

Professional designers model reality first.

Technology later.

The Noun Technique

One of the oldest OOA techniques.

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
Products
Payment

These become object candidates.

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

These are often not domain objects.

The noun technique provides candidates.

No final answers.

Verb Analysis

After finding nouns:

Analyze verbs.

Verbs reveal:

Behaviors

Requirement:

Customer places order.

Verb:

places

Potential behavior:

customer.placeOrder();

Requirement:

User logs in.

Verb:

logs in

Potential behavior:

user.login();

Requirement:

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;

Behaviors:

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

Identifying Responsibilities

Once objects are identified:

Ask:

What is each object responsible for?

Example

Library System

Book Responsible for:
	Title
	Author
	Availability

Member Responsible for:
	Borrowing
	Returning
	Reserverations

Loan Responsible for:
	Issue Date
	Due Date
	Status

Good object models emerge from good responsibility assignment.

Responsibility-Driven Design

Professional designers often use: Responsibility-Driven Design (RDD)

Core Question:

Who should do this?

Requirement:

Calculate Order Total

Who should do it?

Possible answers:

User
Order
Database
UI

Correct:

Order

Because Order owns the items.

Bad Design:

class User
{
public:

    double calculateOrderTotal();
};

Wrong responsibility.

Good Design:

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

Responsibility aligned with ownership.

Identifying State

Each object usually owns information.

Ask:

What does this object know?

Example:

Customer knows:
	Name
	Email
	Address

Order knows:
	Items
	Status
	Total

Product knows:
	Price
	Name
	Stock

These become candidate attributes.

Identifying Behavior

Ask:

What can this object do?

Customer