Object-Oriented Analysis and Design

This course is about building large software systems through objects. We study how to move from a real-world problem, through a clear statement of what is needed (analysis), to a plan for how to build it (design), and finally to working code. The thread that runs through every stage is the notion of an object — a capsule that holds data and the behavior that acts on that data together. Before we talk about any diagram or model, we need to agree on why we build software this way and what the key terms actually mean. This first session lays that foundation.

This first lecture sets the vocabulary you will use in every later session: object, class, state, behavior, abstraction, encapsulation, inheritance, polymorphism, interface, UML, and design patterns. It also connects those words to the bigger story — that software is built through a lifecycle of analysis and design, and that the reason a whole industry runs on these ideas is that they map directly onto a world we already understand.

Object-Oriented Analysis and Design (OOAD)
            |  core question: which objects exist, and which is responsible for what?
            v
            ------------------------------------------------
            |  analysis (WHAT is needed)  |  design (HOW)  |
            |  problem side               |  solution side |
            ------------------------------------------------
            |  expressed in objects all the way through    |
            v
       implementation (working code)

From the first minute the course establishes a single mental habit that carries through every lecture: speak in objects. When you analyze, you look for objects; when you design, you decide how those objects collaborate; when you code, you implement them. This session gives each of those words a precise meaning, so the rest of the course can assume you already share them.

1.1 The Object-Oriented Paradigm

1.1.1 Object orientation as a design paradigm

There are several ways to design and build software, and object orientation is one paradigm — one overall style or philosophy of solving a problem with software. The professor framed it simply: a software design paradigm is just "various ways through which you can build your software." Object orientation sees the world, and therefore the software we build to model it, as a collection of objects that interact.

The core premise is simple to state: our world is made of objects. Look outside a window and you will find ten objects without trying — humans, animals, plants, buildings, cars. Anything we can visualize, any entity with a role to play, is an object. Every object has some properties and some role to play, and the real world runs as a collection of interacting objects each doing its job. A class session, for instance, only happens because students and a teacher are communicating and coordinating with each other through devices such as laptops and phones — many objects, each following some rules, working toward one aim.

This is why object orientation is described as intuitive: because every person can relate to it. When you say "student" or "teacher" or "course," people already share a mental image of the thing, its properties, and what it does. The more a system maps onto things people already understand, the easier it is to design, to explain, and to maintain.

The intuitive label matters beyond comfort. When a system is built from concepts that map directly onto a domain people already know, a new team member can often guess what a class is for and where a feature belongs just by reading the class names — no dense manual required. This mapping is the seed of everything else in the course: analysis, design, and implementation all reuse the same object vocabulary because that vocabulary was borrowed from the real world in the first place.

1.1.2 From functional decomposition to objects

Object orientation did not always exist, and it helps to know what came before it. Historically, computer systems were built with a structured modeling or functional approach: the main building blocks were functions. In languages such as C and C++, a program was essentially a collection of functions, and the data those functions operated on lived separately. The professor pointed out that this mirrors how a real organization looks from the outside: in a retail store there is a manager doing a job, inventory staff working on the back end, delivery people handling dispatch — it all looks like a set of functionalities or behaviors carried out by different people.

The trouble shows up when the world changes. In the functional approach, both the data and the functions that touch it are scattered, so whenever a change is requested, you edit functions here and there, and maintenance becomes very challenging. The idea of object orientation came to prominence around the 1990s (the professor said "during 90s or 95"). Instead of keeping functions and data apart, object orientation joins them: a real-world object's functionality and its attributes (the data, which in programming we call variables or fields) are combined together as one capsule — that capsule is the object. This single shift — data and behavior living together — is the main aspect of object-oriented systems.

1.1.3 The object-oriented programming languages

Because this is an interactive course, the session opened with a quick check of what students already know.

Note the distinction the professor was careful to draw: we teach with Java, but we do not teach Java itself. Implementation is part of this course only in the sense that an analysis or design that cannot be implemented is useless. Learning the language itself happens in a dedicated programming course.

// The point here is the shape of a class, not the Java grammar.
    // A real design can later be written in Java, C++, Python, or anything else.
    public class Book {
        private String title;        // state lives here
        public void print() {        // behavior lives here
            System.out.println(title);
        }
    }

The deeper point of this aside is that the language is a vehicle for the ideas. If we had to fight a confusing language, the object concepts would get lost in syntax. Because Java is widely known and its object model matches the textbook, it lets everyone concentrate on deciding what the objects are — the part that generalizes to any language — rather than on the mechanics of a specific one.

1.1.4 Why a common language helps

There is a deeper reason everyone in the course speaks "object," even across roles. Because we find objects in the real world, look for objects during analysis, look for objects during design, and talk about objects during implementation, one particular concept and one vocabulary carries the whole software development lifecycle. When the analysis, the design, and the code all talk about the same objects, communication is much easier, and many mismatches that plague projects are prevented at the source.

Real-world connections and study advice for this section: the languages you will actually meet in industry include Java and C++, and knowing the difference between "teaching with a language" and "teaching a language" will matter when you pick up new tools on a job.

1.2 The Software Engineering Lifecycle and Development Models

1.2.1 The phases of building software

The professor asked the class to recall the software engineering lifecycle — the sequence of phases through which software is delivered to a customer. The agreed list, in a rough order, is:

1. Requirements — decide what the system must do
2. Design — decide how it will do it
3. Implementation — write the code
4. Testing — check that it actually works
5. Deployment — going live, first to early adopters
6. Maintenance — keep it working and improve it over time

The professor added a caution: it is tempting to think of this as a strict sequence, but that is misleading. In practice testing starts early, and pieces of the work overlap, which is exactly why we need development models rather than a rigid checklist.

1.2.2 Development models

A development model captures how you walk through those phases. The session named several:

• Waterfall model — the classic linear model, phase by phase. Each phase finishes completely before the next begins, like water falling level to level. The professor's verdict was blunt: "no one uses" it in practice today.
• Iterative models — these are very popular, because you revisit and improve the system in cycles. You build a small working slice, learn from it, then expand.
• Spiral model — another well-known model that emphasizes repeated risk review rounds. Each loop of the spiral adds functionality while explicitly reviewing the biggest risks before committing more effort.
• Unified Process model — this is the one this course follows, and the textbook is built around it. It works in an iterative fashion, and it is the agile Unified Process (a light, flexible version of the UP) that the companion textbook uses as its running example.

So the takeaway is not that there is one correct sequence, but that there are many software engineering models, and the Unified Process (an iterative model) is the one we adopt for this course.

1.2.3 Why we must analyze and design at all

The professor grounded all of this in history. In the days before the 1970s, programs were written mostly by scientists and mathematicians who fully understood their problems and implemented them directly. Once software became a commercial activity and large teams started building systems, many projects began to fail and there was chaos because people skipped methodology. This led to well-known failure studies, most notably the Standish Report (1995), which tracks how large numbers of software projects fail. The professor asked students to read it (it is also made available on the learning portal) because it is important to understand why projects go wrong.

The dominant cause of failure is instructive: requirements were not understood properly. Teams would develop software, hand it over, and hear "this is not what we asked for." The mismatch happened because either the customer could not state the requirements, or the developers could not collect them, or the two sides simply failed to communicate. The lesson is that modeling and documentation exist to close exactly this gap. There is a balance, though: engineers do not like excessive documentation — "who will read it, it is not a novel or a story." So we produce only the minimum required documentation, but what we do produce must be genuinely useful.

A repeated warning from the session: requirements must be testable and unambiguous. A clear requirement can be checked and agreed on by both sides. If you cannot say exactly what is required, you cannot build a solution — no matter how good a mathematician or programmer you are.

1.3 Analysis versus Design

1.3.1 The simplest way to separate the two

The cleanest mental model given in the session is this: analysis is the problem side; design is the solution side. Two words carry most of the weight:

• What — during analysis you decide what is required.
• How — during design you decide how the system will achieve what is required.

So analysis asks "What does the system do?" and design asks "How do we achieve it?" Investigation is the term closest to analysis: before reaching a conclusion you gather every relevant fact, exactly as a police inspector investigates a case or a doctor investigates a patient's symptoms and possibilities. The professor joked that investigation brings to mind police work, then emphasized the serious message: we should investigate the problem with that same determination to turn over every angle, but using soft skills — being cautious, not treating everyone as a suspect — while still reaching a complete understanding before we conclude.

1.3.2 The scope: analysis and design are for big software

1.3.3 Requirements and the SRS

Because requirements are the number-one cause of failure, the session spelled out what proper requirements work looks like. We start from an idea or a system and interact with the various stakeholders — the people who have an interest in that software. From customers or clients we collect the requirements, then we convert them into a more formal statement called the Software Requirements Specification (SRS). The SRS is written from the developer's or programmer's perspective, in language developers can act on, and it is signed as an agreement between the customers and the developers. Both sides now share one understanding; the requirements are clear, testable, and unambiguous, and that agreement is the foundation for everything that follows.

1.3.4 Design as a creative, constrained process

Once requirements are clear enough (the professor was quick to note that in software all requirements will not be clear, and that is acceptable), design begins. Design is a creative process: you look at all the alternate solutions and choose the best one, within the constraints you actually face — the resources, the people, the time, and the money available. An engineer has to pick the best solution under those real limits, and that chosen design then has to be implemented by a team of programmers.

The professor offered a memorable analogy: design for software is like architecture for a building. A contractor or architect takes a lot of money to design a building because the design is valuable. A building has many views — front, top, side, left, right, east — and internally it has electrical lines, plumbing, sewage, gas connections, and different kinds of rooms. Similarly, software has a high-level design (like the architectural plan) and a detailed design (like the plumbing, electricity, and rooms — in software terms, the data structures and algorithm design). We create the various modules and packages of the system, and we make them clear to the people who will implement them. The design is expressed as communicating objects and their components.

1.3.5 Why we speak in objects in both phases

A key structural point: we choose to produce the solution in terms of objects because we can relate to objects throughout the entire lifecycle. Whether we are analyzing, designing, or implementing, we talk about the same objects. One vocabulary, consistent end to end. That is the whole aim of object-oriented analysis and design — finding the right set of objects is described as the essence of object orientation, and it is what the rest of the course trains you to do.

An intuition worth keeping: analysis is about the problem, design is about the solution, and neither is a pure stage — they blend into each other, but keeping the What/How distinction in mind prevents the two most common errors (designing before understanding, or collecting wishes without specifying a testable need).

1.4 Objects, Classes, State, and Behavior

1.4.1 Real-world objects

We return to the starting intuition and make it precise. In the real world, an object is anything that has state and exhibits behavior:

• State means the properties, attributes, or fields — for a student, the name, ID number, date of birth, marks. In older languages these were the variables holding information.
• Behavior means the functionality, the responsibilities, the roles — what the object does. In programming terms these are the functions, which in object orientation we call methods.

Everywhere around us, objects combine these two: a dog, a car, a bicycle, a fan, a room, an air conditioner, a pen. The professor's phrase is that each object has "some state information, some behavior," and a role to play. When we build software, we capture only some of that — and that act of choosing what to keep is called abstraction, which we meet properly in the next section.

1.4.2 Classes are templates for objects

An object is a concrete instance. A class is the template, prototype, or blueprint that describes a whole kind of object: what common properties and what responsibilities each individual of that kind will have. The professor emphasized repeatedly:

The professor gave a powerful framing worth keeping: classes are user-defined data types. A predefined type like int describes a set of allowed values and the operations you can perform on them; each int variable you declare is one instance. A class is exactly analogous: you define the type (the class), compile it, and later create any number of objects from it — each object being one instance of your user-defined type.

1.4.3 Class notation and the book example

It is worth seeing how a class is drawn and used, because this notation returns throughout the course. A class is shown as a rectangle divided into three parts: the class name at the top, the attributes in the middle, and the methods at the bottom. The professor's running example was a book:

• Class name: Book
• Attribute: title (and we can add more, such as the number of pages, or the author name)
• Method: print — a method that prints the title

+------------------+
    |      Book        |   <- class name
    +------------------+
    |  - title         |   <- attributes (the state)
    +------------------+
    |  + print()       |   <- methods (the behavior)
    +------------------+

Once the Book class is defined, we can create any number of book objects, one per different subject or title, and each can run print to show its title. When we finally implement, this small diagram becomes a plain class with a method and an attribute — public class, a title field, and a print method. This tiny example captures the whole pipeline: we look at the real world, we analyze the concepts, we create a design, and then we implement.

The professor noted an important philosophical detail about responsibility. In the real world a book does not print itself — somebody else prints it. But in software we often give one object the whole responsibility it can carry, because the object holds all the information it needs. For example, an employee software object can be given the method to generate its own salary once thirty days have passed; the real-world employee would never cheat, so we can trust the computed object to produce the value fairly. Likewise a book object, looking at itself, knows its title and author, so we write a method that lets it report them. This is an actualization of reality — modeling the real world into software objects that can answer for their own data.

The professor's library case study (already present in the course material) will be a recurring example: in the real library you have books, a librarian, and a library building; in the software we search for the corresponding objects that issue a book, return a book, and record a borrower's details. What used to be done with paper catalogs and library cards is done today entirely by software.

1.4.4 Worked example: the course object

To make state and behavior concrete, the class considered a course — which is a concept, not a physical thing, and therefore a great test of the idea. You have never seen a course; you have seen its printout, its handout, its schedule. The professor asked: what are the state and behavior of a course object?

This example teaches two things. First, concepts (bookings, transactions, a course) can be objects even though they are not physical — a banking transaction or a railway reservation is a concept, not a tangible thing. Second, identifying state is usually easy, while identifying the methods is the difficult part — you have to decide what roles the object must actually play in your system.

1.4.5 The integer range aside

The professor mentioned, in passing, that predefined types like int come with a built-in domain of allowed values. The exact figures spoken aloud were garbled, but the idea is standard and worth recording with that caveat:

$$\text{int domain}=[-2^{31},2^{31}-1]$$

1.5 Abstraction and Encapsulation

1.5.1 Abstraction

Abstraction is the act of ignoring what is not needed. When we model a real-world object as a software object, we do not — and cannot — copy every feature. We keep only the properties and behaviors that are relevant to the particular problem, and we deliberately ignore the features that are not relevant. The professor's example: as a teacher in this class, he is not interested in what students earn, or what they do in the evening, or what other courses they take, so those features are abstracted away. What matters is that you are a qualified student of the institution, so those features stay. Abstraction is how we organize the world and reduce its complexity; "through abstraction we achieve encapsulation," and it is how we decide what each software object must contain.

1.5.2 Encapsulation

Encapsulation is the packaging of those chosen attributes and methods into a module, together with controlled access. The professor described it in terms of security and structure: "I need to safeguard my code. Anyone should not be able to change it, and I need to provide a structure to it."

A teaching warning that came up here: the difficult part of building a class is identifying methods, not attributes. Attributes (the state, the fields) are comparatively easy to list; deciding what behavior the object must responsibly perform is the harder, more valuable skill.

1.6 Inheritance

1.6.1 Generalization and specialization

Inheritance is the concept of defining a new class by reusing what already exists in a parent class, and it mirrors the real world's parent–child relationship. We inherit many features, properties, and ways of doing things from our parents. In software, inheritance is a way to avoid rewriting code again and again — a major source of reuse.

The professor framed inheritance as generalization and specialization:

The whole world is organized hierarchically: there is a plant hierarchy and an animal hierarchy; companies are hierarchies (CEO, directors, presidents, others); families have a family tree. Inheritance is naturally drawn as a tree structure, and it is precisely because the world is hierarchical that inheritance is such a natural and "very popular, simple" tool.

1.6.2 Reuse is the goal

The underlying goal of object orientation in software is reuse of what you already know. Every time you use int or float, you are reusing a predefined type that someone built for you. With user-defined items, at design-pattern level as well, you do not want to construct everything from scratch — you inherit from the relevant class and add only what is new. This is the same philosophy behind design patterns (Section 1.10): reuse proven solutions rather than reinventing them.

        Vehicle            (wheels, topSpeed — written once)
           /   |   \
         Car Truck Bus         (each adds only its unique parts)

1.7 Polymorphism

1.7.1 One interface, many implementations

Polymorphism ("many forms") was defined in the simplest sticky way: one interface, multiple implementations. The same public interface can be backed by different internal implementations, and the caller does not care which one it gets.

The professor's favorite example was the USB connector. USB is one interface through which you can plug in a mouse, a keyboard, a pen drive — many different devices, each with its own implementation, all connecting through the same interface. Extending the idea to cars: Maruti, Hyundai, BMW, and Tesla all make cars with their own implementations, but the interface of driving — the steering wheel, the accelerator, the brake, the clutch — is the same. You learn one interface and can drive all of them.

Each object exposes its own public interface through which people interact, and behind that interface there can be multiple implementations. The professor tied this back to the earlier point: polymorphism is the aspect through which inheritance is often achieved, so the two are very closely related.

1.7.2 Why polymorphism matters for design

Because every object has interfaces and the implementations behind them are free to differ, designers can swap implementations without disturbing the users of the interface — the system becomes flexible and open to change. That flexibility is exactly what makes object-oriented systems easier to maintain than the older function-based designs, which is a thread running through the whole course.

1.8 Interfaces

1.8.1 The bridge of interfaces

An interface is the contract between a class and its users. When you create an object, the people using it need to know how they may use it, and you provide a public interface that says: this is the way you can use me. The professor's picture is the black box: the user knows what the object does and how to invoke it, but not how it does it.

Every individual and every product has some interface. A projector or a laptop exposes a USB port — an interface that lets other things connect and use the device's services. Every organization has a public interface; every product has a user interface through which users interact. When you declare an interface, you guarantee a particular behavior: through this interface is a contract between user and class — this is the way I will behave. The user needs to understand the interface but does not need to enter the implementation.

1.8.2 Interface versus implementation

A crucial separation the session emphasized is between the interface of a class and its implementation:

• Interface — the agreed, stable way to use the object. You design it carefully so it does not need to change.
• Implementation — the internal details, which will keep changing as new algorithms, new requirements, and improvements come along.

Because these are separated, you can change the implementation any time while it stays hidden from the end user; the visible functionality you do not want to change is locked in the interface. This is the practical payoff of encapsulation and abstraction — the world's complexity is reduced by restricting how much of each system you must understand to use it safely.

1.8.3 Interfaces and Java

An important, exam-relevant technical point: in Java, interfaces are also how multiple inheritance is implemented. A class can inherit behavior from multiple interfaces (while normal class inheritance is single). So the word "interface" does double duty in the course — it is the conceptual black-box contract and a concrete Java construct that enables multiple inheritance. This is worth flagging because the two meanings are easy to conflate.

// Java: one interface, many implementations (and multiple inheritance of behavior).
    public interface Connectable {
        void connect();
    }

    public interface Chargeable {
        void charge();
    }

    // A class may implement SEVERAL interfaces -> multiple inheritance of behavior.
    public class USBDevice implements Connectable, Chargeable {
        public void connect() { /* USB-specific */ }
        public void charge()  { /* USB-specific */ }
    }

1.9 UML and Use Case Analysis

1.9.1 UML as a common design language

UML, the Unified Modeling Language, is the notation this course uses to communicate models. It came about because earlier each modeling school had its own terms and concepts, and UML unified them all into one design language. When we draw analysis models and requirements, or design models, UML is the shared vocabulary with which we express them.

There is a strong practical reason to draw models rather than only write text: clients and stakeholders are not interested in reading long text documents. They understand pictures and graphical models far more easily. So much of the modeling in this course is visual — diagrams people can look at and nod along with.

1.9.2 Use case analysis

Because requirements are the number-one cause of project failure, the course puts heavy weight on gathering them well, and the tool we use for that is use case analysis. To collect requirements we must satisfy and interact with the end users. This is why the approach is called use case analysis: we describe the system through the cases in which users actually use it. The professor noted a curiosity: strictly speaking, use case analysis itself has no object orientation — yet it has become the de facto standard for analyzing a system, and it is a main component of the course, combined with object-oriented analysis.

1.9.3 Modeling is abstraction of reality

The session tied modeling back to abstraction: when we model, we are making an abstraction of reality. The software objects we create are not exactly the same as the real-world objects they stand for. A real-world object has a huge number of feature, but the software object has only the limited set we chose to implement. The professor used the comparison of an online product listing — a product may have a picture, a 3D view, a look and feel — but in software we store only the properties that matter to the system. Modeling therefore means abstracting the real world into a software model that captures what is relevant and drops the rest, and doing that modeling for both analysis and design is what this course teaches.

1.10 Design Patterns

1.10.1 Patterns as repeatable solutions

A design pattern is a general, repeatable solution to a recurring problem — a collection of problem and solution. The idea is that every software system need not be designed from scratch: for a given kind of problem there are proven, reusable solutions, and we learn those best practices instead of reinventing them. A pattern is generic, so you apply it by adapting a general solution to a specific case.

The professor linked this to engineering broadly: in every engineering discipline there are patterns — the way dresses have their patterns, the way buildings repeat structures. Just as in any field, repeating problems get repeating solutions, and in software those solutions get written down and documented so others can reuse them.

1.10.2 The history and the people

Two sets of names matter here. The idea of a pattern in design is credited to Christopher Alexander (in architecture), who is regarded as the father of the pattern concept. But the software community knows patterns chiefly through the landmark 1994 book co-authored by Gamma and colleagues ("the Gang of Four"), published using C++ for its examples, which collected 23 or 24 patterns and made them widely known. So, in software engineering, a pattern is defined as a problem-and-solution pair, documented generically, ready to be specialized.

A final framing from the session ties several threads together: the best way to approach object orientation is to look for best practices — proven, repeatable solutions — and to apply them rather than build everything from scratch. That is the spirit behind both inheritance's reuse and the entire field of design patterns.

Exam Guidance Summary

This first session is an introduction, so it contained no mark distributions or question-type guidance — but it set expectations that shape how you should prepare for the rest of the course and its assessments:

Key Industry Applications

The real-world connections woven through this session, gathered here for quick reference:

• Ubiquitous software. Banking transactions, checking account balances, transfers done on mobile phones, railway reservation systems, and air-flight ticket booking are all software systems — everyday systems that object-oriented design helps build. The professor's refrain is that "everywhere software is there."
• Java and C++ in industry. Java is a leading industrial language (originally started by Sun and now maintained by Oracle), and the course teaches with it because its concepts are widely accepted; C++ knowledge transfers easily to Java. On the job you will meet both.
• Pattern catalogs. The Gang of Four design-pattern catalog (1994) and Christopher Alexander's original pattern idea are the commercial and engineering foundation of reuse; companies build libraries of reusable components on exactly this idea.
• Visual modeling with stakeholders. Because clients do not read long text documents, industry uses graphical models (UML) and use case analysis — the de facto standard — to communicate requirements with end users.
• Iterative development. Industry has largely abandoned the waterfall model in favor of iterative models such as the Unified Process, and historical failure data (the Standish Report of 1995) is used to argue for disciplined requirements handling in real projects.
• Abstraction in e-commerce. Product listings carry only the properties that matter (images, 3D views, look and feel), a concrete example of abstracting a real product into a limited software object.
• Everyday modeling objects. Concepts such as a course, a banking transaction, a booking, or a reservation are software objects even though they are not physical — the same abstraction principle applies to businesses that model invisible ideas as objects.