Lesson 1

Introduction to Object Oriented Analysis and Design

This course introduces Object-Oriented Analysis and Design (OOAD): the discipline of turning a real-world problem into a software model made of collaborating objects, and then translating that model into a clean, maintainable implementation (often in C++).

You’ll work through the core ideas behind object orientation—abstraction, encapsulation, polymorphism, and (when appropriate) inheritance—and you’ll learn how to document your thinking using UML. The goal isn’t “draw diagrams for their own sake.” The goal is to clarify: what the system does, who uses it, what concepts matter, and how responsibilities are split.

What OOAD means in modern C++23

OOAD is language-agnostic, but your implementation choices change with modern C++. In C++23, “object-oriented design” is strongest when it aligns with idiomatic C++: value semantics where possible, RAII for resource safety, and interfaces that make invalid states hard to represent.

In other words, OOAD tells you what objects exist and how they collaborate; C++23 gives you powerful tools to make those collaborations safe and efficient: constructors that establish invariants, deterministic destruction, move semantics, standard library types, and carefully controlled ownership (often via smart pointers).

From problem to model: analysis before design

A common failure mode in software is jumping straight into code. OOAD starts earlier: you first decide what the software must accomplish and what concepts the domain actually contains. Only then do you decide how to structure classes, APIs, and dependencies.

Two kinds of analysis

Application analysis (requirements-focused):
This is about understanding what users need and how they will interact with the system. Typical outputs include:
1. Use cases that describe user goals and system responses.
2. Initial acceptance tests that make requirements concrete and testable.
Domain analysis (concepts-focused):
This is about learning the vocabulary of the problem space and the relationships among concepts. If you were modeling course registration, the domain would include concepts like students, courses, sections, enrollments, prerequisites, and rules that constrain them.

Design: responsibilities, interfaces, collaborations

Design takes the results of analysis and shapes them into a blueprint that developers can implement. In OOAD, you continuously ask three questions:

Responsibility: What does this object own or guarantee?
Interface: What operations does it expose, and what invariants must it protect?
Collaboration: Which other objects does it rely on to get work done?

In C++23, good design also means being explicit about ownership and lifetime. If an object “has-a” relationship is strong and exclusive, you usually model it as composition (store the other object as a member). If sharing is required, you model that decision explicitly (often with std::shared_ptr), and you keep sharing scoped and intentional.

UML as communication, not ceremony

UML is a set of standardized diagram types for representing different views of a system. In this course you’ll use UML to make your intent visible—both to yourself and to others—before you commit to code. The diagrams you choose depend on the question you’re trying to answer.

Use Case diagrams summarize user goals and system boundaries.
Class diagrams describe types, responsibilities, and relationships (association, composition, inheritance).
Sequence diagrams show message flow and collaboration over time in a scenario.
Activity diagrams capture workflows and branching logic.
State diagrams describe lifecycle and event-driven state changes (useful for controllers and protocols).

The modern rule of thumb: keep diagrams lightweight and useful. A diagram that is never updated becomes noise. A diagram that clarifies responsibilities or exposes a dependency problem pays for itself quickly.

Course goals

After completing this course, you will be able to create design specifications that demonstrate the essentials of OOP, including:

How classes allow programmers to define domain-specific data types
How objects collaborate through method calls (“message passing”)
How to separate interface from implementation using access control and stable APIs
How constructors establish invariants and guarantee initialization
How (and when) to reuse behavior via inheritance versus composition
How polymorphism enables one interface to support many implementations

Where we go next

Next, you’ll review prerequisites and then begin modeling a small system end-to-end: capture requirements, extract domain concepts, assign responsibilities, and express the design in UML. From there, you’ll translate the design into modern C++—with a focus on encapsulation, clear ownership, and maintainable interfaces.