What is OOAD?

What is OOAD?

Object-Oriented Analysis and Design (OOAD) is a systematic approach to analyzing, designing, and building software systems using object-oriented principles. Instead of thinking about data flows and procedures, you think about objects — entities that combine data and behavior into a single unit.

OOAD bridges the gap between what the customer wants (requirements) and what developers build (code). It gives you a structured way to understand a problem domain, model it with objects and classes, and then design a solution that maps naturally to that model.

Think of it this way: if you're building a house, you don't start hammering nails immediately. You first understand the requirements (number of rooms, style, budget), then create blueprints, and finally construct. OOAD is the blueprint phase for software.

The Two Phases: Analysis and Design

OO Analysis focuses on understanding the problem domain. You identify objects, their attributes, operations, and relationships. The goal is to answer: "What does the system need to do?" You don't think about implementation details here — just modeling the real world.

OO Design focuses on crafting the solution. You decide on class hierarchies, design patterns, interfaces, and system architecture. The goal is to answer: "How will the system do it?" This is where you make technical decisions about frameworks, databases, and APIs.

Analysis Phase:
┌─────────────────────────────────────────────────┐
│  Problem Domain        →  Conceptual Model        │
│  ──────────────           ───────────────────     │
│  • Identify objects    →  • Class diagrams        │
│  • Find attributes     →  • Object relationships  │
│  • Discover operations →  • Use case diagrams     │
└─────────────────────────────────────────────────┘

Design Phase:
┌─────────────────────────────────────────────────┐
│  Conceptual Model      →  Design Model            │
│  ───────────────────       ──────────────         │
│  • Class hierarchy     →  • Detailed classes       │
│  • Relationships       →  • Design patterns        │
│  • Interfaces          →  • Architecture           │
└─────────────────────────────────────────────────┘

Why Use OOAD?

OOAD offers several key advantages over traditional approaches. First, it models the real world more naturally — you can represent a Bank, Customer, and Account as objects just as they exist in reality. Second, it promotes reusability through inheritance and composition. Third, it makes systems easier to maintain because changes are localized to specific classes rather than scattered across the codebase.

Here's a simple illustration of how OOAD thinking works. Imagine modeling an online store:

Real World Objects:
┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Customer   │────▶│    Order     │────▶│    Item      │
│              │     │              │     │              │
│ • name       │     │ • orderId    │     │ • name       │
│ • email      │     │ • date       │     │ • price      │
│ • address    │     │ • total      │     │ • quantity   │
│              │     │              │     │              │
│ • placeOrder │     │ • calculate  │     │ • getDetails │
│ • viewHistory│     │   Total()    │     │ • applyDisc  │
└──────────────┘     └──────────────┘     └──────────────┘

Each box = a Class
Each line = a Relationship
Each bullet = Attribute or Operation

Notice how the design mirrors reality. A Customer places Orders, and Orders contain Items. This natural mapping makes the system easier to understand, build, and maintain.

OOAD vs Traditional Approaches

Traditional structured analysis focuses on functions and data flows — thinking in terms of "what happens step by step." OOAD focuses on objects and their interactions — thinking in terms of "who does what with whom." The OO approach scales better for complex systems because it encapsulates state and behavior together, reducing the ripple effects of changes.

Consider a simple example. In procedural code, a function `processOrder(order)` might modify order data directly. In OO design, the Order object itself knows how to process itself — keeping its internal state protected and its behavior coherent.

// Procedural approach — data and functions are separate
function processOrder(order) {
  order.total = order.items.reduce((sum, i) => sum + i.price * i.qty, 0);
  order.status = "processed";
}

// OO approach — behavior belongs to the object
class Order {
  constructor(items) {
    this.items = items;
    this.status = "pending";
    this.total = 0;
  }

  process() {
    this.total = this.items.reduce((sum, i) => sum + i.price * i.qty, 0);
    this.status = "processed";
  }
}