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
	Place Order
	Update Address

Order
	Add Item
	Remove Item
	calculate Total

Product
	Update Price

Behavior should align with responsibility.

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

Behaviors discovered.

Initial Model

 Customer
    |
    v
   Card
    |
    v
   ATM
    |
    v
CashDispenser

Avoid Technical Objects Early

Beginners often identify:

DatabaseManager

NetworkHandler

FileManager

CacheController

too early.

These are implementation concerns.

Object-oriented analysis should focus on:

Business Concepts

not technical details.

Domain Vocabulary

One of the most important outcomes of OOA:

Ubiquitous Language

Every stakeholder should use the same terms.

Example:

Hotel System
	Guest
	Reservation
	Room
	Check-In
	Check-Out

Everyone speaks the same language.

Bad Vocabulary:

Developer says:
	BookingEntity
	
Business says:
	Reservation

Confusion emerges.

Use domain language whenever possible.

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 exist:

Ask:

Who knows whom?
Who owns whom?
Who uses whom?

Example:

Order contains OrderItem
	Relationship Composition

Customer places Order
	Relationship Association

Order uses PaymentService
	Relationship Dependency

CRC Cards

A classic OOA technique.

CRC:

Class
Responsibilities
Collaborators

Example:

Order

Responsibilities:
	Add Item
	Remove Item
	Calculate Total

Collaborators:
	Product
	Payment