Software Engineering showed how a project is run; Object Oriented Analysis and Design (OOAD) shows how to think about and draw the system before it is built. Its language is UML (Unified Modeling Language), the standard way to sketch classes, interactions and deployments. Whiteboard design interviews, architecture documents and service diagrams all draw on it. This article revisits the five units of the JNTUK course.
Unit 1: Introduction to the object model and UML
Complexity and the object model
Software is complex because of the problem domain, the difficulty of managing development, and the flexibility of software itself. The answer is decomposition and a good model. The object model rests on four major elements (abstraction, encapsulation, modularity, hierarchy) and three minor ones (typing, concurrency, persistence).
| Term | Meaning |
|---|---|
| Object | Has state (data), behaviour (operations) and identity |
| Class | A template for similar objects |
| Relationships | Association (uses), aggregation (has-a, parts can exist alone), composition (owns, parts die with the whole), generalization (is-a), dependency |
Analysis versus design
Analysis asks what the system must do and models the problem domain; design decides how it will do it and models the solution. The process is iterative: identify classes, relationships, attributes and operations, then refine.
UML basics
UML is a notation, not a method. It has things (classes, use cases, components, notes), relationships and diagrams. Diagrams fall into two groups:
| Group | Diagrams |
|---|---|
| Structural (static) | Class, object, component, deployment, package |
| Behavioural (dynamic) | Use case, sequence, collaboration (communication), state machine, activity |
The four-plus-one view (use case, logical, process, implementation, deployment) shows a system from different viewpoints.
Today: the idea of describing a system with several views is how architecture documents are still written: a logical diagram, a data flow, a deployment view. The C4 model and tools like draw.io or Mermaid are lighter versions of UML.
Unit 2: Class and object diagrams
Class diagrams
A class diagram is the main static model. A class is a three-part box: name, attributes and operations, with visibility marks: + public, - private, # protected.
| Relationship | Notation | Example |
|---|---|---|
| Association | Line, with multiplicity (1, 0..*, 1..*) | A Customer places many Orders |
| Aggregation | Hollow diamond | A Team has Players |
| Composition | Filled diamond | An Order owns its Order Lines |
| Generalization | Hollow triangle arrow | Savings Account is-a Account |
| Realization | Dashed hollow arrow | A class implements an interface |
| Dependency | Dashed arrow | A class uses another briefly |
Abstract classes are shown in italics, interfaces with «interface». Stereotypes, constraints and notes extend UML.
Object diagrams
An object diagram is a snapshot of instances at one moment, underlined names such as order42 : Order. It is used to explain a class diagram by example.
Finding classes
A common technique is to read the requirements and underline nouns (candidate classes) and verbs (candidate operations). CRC cards (Class, Responsibility, Collaborators) help a team find them. Good classes have clear responsibilities, high cohesion and low coupling.
Today: database schema design, ORM entity models and API resource models are class diagrams in another form. A “domain model” in domain-driven design is the same idea, naming the core entities and how they relate.
Unit 3: Behavioural modelling: use cases, interactions and state
Use case diagrams
A use case diagram shows what the system does from the user’s viewpoint.
| Element | Meaning |
|---|---|
| Actor | A user or external system (stick figure) |
| Use case | A goal, an oval (for example “Place order”) |
| «include» | A use case always uses another (for example “Make payment”) |
| «extend» | An optional extension (for example “Apply coupon”) |
| System boundary | A box around the use cases |
Each use case has a written scenario: preconditions, main flow, alternative flows and postconditions.
Interaction diagrams
| Diagram | Shows | Emphasis |
|---|---|---|
| Sequence diagram | Objects as vertical lifelines and messages as horizontal arrows in time order | Order of messages |
| Communication (collaboration) diagram | Objects linked by lines, with numbered messages | Structure of links |
Sequence diagrams include synchronous and asynchronous messages, return messages, activation bars and fragments (alt for choices, loop, opt).
State machine diagrams
A state machine models the life of one object: states, transitions triggered by events, optional guards [condition] and actions. It is suited to objects with a lifecycle, such as an Order (Created, Paid, Shipped, Delivered, Cancelled).
Activity diagrams
An activity diagram is a flowchart for a process: actions, decisions, forks and joins for parallel work and swimlanes to show who does each step.
Today: sequence diagrams are the most used UML diagram in practice: they show how an API request passes through a gateway, services and database, and are common in design reviews and incident write-ups. State machines describe order lifecycles, CI pipeline stages and Kubernetes pod phases.
Unit 4: Architecture: components, deployment and packages
Component diagrams
A component is a replaceable, deployable part of the system with defined interfaces: a provided interface (what it offers) and a required interface (what it needs), drawn as ball-and-socket. A component diagram shows how a system is assembled from modules, libraries and services.
Deployment diagrams
A deployment diagram shows the physical layout: nodes (servers, devices, containers) and the artifacts (executables, files) placed on them, with the communication paths. It answers “what runs where”.
Package diagrams
A package groups related elements. A package diagram shows the groups and their dependencies, which should be acyclic and layered: a lower layer should not depend on a higher one.
Architecture ideas
| Idea | Meaning |
|---|---|
| Layered architecture | Presentation, business logic, data access |
| Separation of concerns | Each part has a clear job |
| Dependency inversion | Depend on abstractions, not details |
| Reuse | Frameworks, libraries and components |
Together with Unit 1, the Rational Unified Process (RUP) organises work in four phases (inception, elaboration, construction, transition), driven by use cases, architecture-centric and iterative.
Today: a component diagram is a map of microservices and the APIs they provide and consume. A deployment diagram is a Kubernetes cluster drawing: nodes, pods, services and databases. A package diagram is the module structure of a repository, where cyclic dependencies between packages are a warning sign.
Unit 5: Design patterns
A design pattern is a named, reusable solution to a common design problem. The “Gang of Four” book lists 23, in three groups.
Creational patterns
| Pattern | Intent |
|---|---|
| Singleton | One instance with a global access point (a configuration object) |
| Factory Method | Let subclasses decide which class to create |
| Abstract Factory | Create families of related objects |
| Builder | Construct a complex object step by step |
| Prototype | Create objects by copying an existing one |
Structural patterns
| Pattern | Intent |
|---|---|
| Adapter | Make an incompatible interface fit the one you expect |
| Decorator | Add behaviour to an object without subclassing |
| Facade | A simple interface to a complex subsystem |
| Proxy | A stand-in that controls access (lazy loading, caching, security) |
| Composite | Treat a tree of objects like a single object |
| Bridge, Flyweight | Separate abstraction from implementation; share objects to save memory |
Behavioural patterns
| Pattern | Intent |
|---|---|
| Observer | Notify dependents when an object changes (event listeners, publish-subscribe) |
| Strategy | Swap algorithms at run time |
| Command | Wrap a request as an object (undo, queues) |
| State | An object changes behaviour with its state |
| Template Method | Fix the steps, let subclasses fill details |
| Iterator, Chain of Responsibility, Mediator, Visitor | Traverse; pass a request along handlers; centralise communication; add operations to a structure |
Patterns are tools, not goals: using them where they are not needed makes code harder to read. The related GRASP principles (Information Expert, Creator, Controller, Low Coupling, High Cohesion) guide assigning responsibilities.
Today: the Adapter is every API wrapper, the Facade is an API gateway, the Proxy is a service mesh sidecar or a caching reverse proxy, Observer is event handling and message topics, Strategy is a pluggable retry or load-balancing policy, and the Singleton is a shared connection pool. Spring, Angular and React use many of these under the hood.
One-minute recap
| Unit | Key idea | You meet it in |
|---|---|---|
| 1. Object model and UML | Abstraction, encapsulation, modularity, hierarchy; structural and behavioural diagrams | Architecture documents, C4 diagrams |
| 2. Class and object diagrams | Association, aggregation, composition, generalization | ORM and domain models, schema design |
| 3. Behavioural models | Use cases, sequence, state and activity diagrams | API flow diagrams, order and pipeline lifecycles |
| 4. Architecture views | Component, deployment, package diagrams | Microservice maps, Kubernetes layouts |
| 5. Design patterns | Creational, structural, behavioural; GRASP | Adapters, facades, observers, strategies |
Next in Engineering Revisited: Operating Systems.
Written by Claude, Anthropic’s AI assistant, as part of Engineering Revisited, a quick refresher of the B.Tech subjects one at a time.