OOAD

What is OOA?
OOA = Object-Oriented Analysis
Object-Oriented Analysis is the first phase in Object-Oriented development where we:
✔ Study the problem
✔ Identify the requirements
✔ Identify the objects, their attributes, and interactions

Simply: OOA understands what the system must do using objects.

Main Goal of OOA

To understand the real-world problem and convert it into a model with:
• Objects
• Classes
• Relationships
• Use cases
• Interaction between different actors and the system

Steps in OOA

Step No Activity Example (Online Shopping System)

Understand the problem Customers need to buy products through website

Identify actors Customer, Admin, Payment Gateway

Identify use cases Login, View products, Add to cart, Make payment

Identify objects Product, Cart, Order, Customer

Identify attributes & methods Product → name, price, description

Define relationships Customer places Order; Order contains Products

OOA Focus Areas

OOA focuses on 3 major models:
Model Purpose

Object Model Identifies objects, classes, attributes, relationships

Describes behavior and interactions over time (sequence/activity

Dynamic Model
diagrams)

Functional
Defines what the system should do (use cases)
Model

Characteristics of OOA

Feature Meaning

Based on real world objects Uses real concepts like Student, Course, Account

Improves understanding Stakeholders and developers understand same model

Avoids complexity Breaks big problem into smaller objects

Reusability Same object can be used again in other systems

Outputs of OOA
After completing OOA, we get diagrams (UML):

Use Case Diagram

Class Diagram (High level)
Sequence Diagram (basic interactions)
Activity / Workflow Diagram
Requirements documents
These outputs will be used in next phase — OOD (Object-Oriented Design).

Example to Understand OOA Easily

Suppose we want to build a Library Management System

In OOA:
We identify:
• Actors → Student, Librarian
• Use cases → Borrow book, Return book, Search book
• Objects → Book, Student, Staff, IssueRecord
 • Attributes → Book → title, author, category
• Relationships → Student borrows Book
This gives a clear understanding of what the system should do before coding begins.

Summary

OOA Means Analysis of problem using Objects

Focus Understand requirements

Output Objects, Use cases, diagrams

Benefit Better clarity, Less complexity

System Development Life Cycle

The System Development Life Cycle (SDLC) provides a well-structured framework that
gives an idea, of how to build a system. It consists of steps as follows - Plan, Analyze,
Design, Develop, Test, Implement and Maintain. In this article, we will see all the stages of
system development.

System Development Life Cycle

Table of Content
• Stages (Phases) of System Development Life Cycle
o Planning
o Analysis
o Design
o Development
o Testing
o Implementation
o Maintenance
 • How is System Development Life Cycle different from System Design Life Cycle?
• Significance of System Design in System Development Life Cycle
We will delve into the significance of each stage, emphasizing the critical role played by
System Design in the overall process.
Stages (Phases) of System Development Life Cycle
The System Development Life Cycle (SDLC) consists of several interconnected phases that
provide a structured framework for developing a system. These phases include Planning,
Analysis, Design, Development, Testing, Implementation, and Maintenance. Each phase
plays a vital role in ensuring the system is successfully developed, with System Design being
especially critical in shaping the final product.
Stage 1: Planning
The Planning phase sets the foundation for the entire SDLC. This stage involves identifying
the system's objectives, defining the scope, setting timelines, and allocating necessary
resources. Effective planning ensures that the development process aligns with the
organization's goals, guiding the project in a clear and structured direction.
Stage 2: Analysis
In the Analysis phase, the focus is on understanding and documenting the system’s
requirements. This involves gathering input from stakeholders, reviewing current processes,
and identifying the system’s needs. The data collected forms the basis for developing a
system that addresses both user expectations and organizational challenges.
Stage 3: Design
The Design phase translates the requirements gathered during Analysis into a detailed
technical blueprint. This includes designing the system’s architecture, database models, user
interfaces, and defining system components. The outcome of this phase provides the technical
structure needed to guide the upcoming development and implementation activities.
Stage 4: Development
In this phase, the actual coding and development of the system take place. Developers build
the system according to the design specifications, implementing features, creating databases,
and writing code. This phase also includes initial internal testing to ensure the system
functions as expected and adheres to design and functional requirements.
Stage 5: Testing
Testing is a crucial phase that ensures the system is free of errors and functions correctly
under various conditions. This phase includes multiple types of testing, such as unit testing,
integration testing, system testing, and user acceptance testing. The goal is to identify and fix
any issues before the system is deployed.
Stage 6: Implementation
The Implementation phase involves deploying the developed system into a live environment.
Key activities include system installation, migrating data, training users, and configuring
infrastructure. This phase requires thorough planning to ensure a smooth transition from the
existing system to the new one with minimal disruptions.
Stage 7: Maintenance
Maintenance is an ongoing phase where the system is monitored, maintained, and updated as
needed. This includes bug fixes, performance enhancements, security patches, and
responding to user feedback. Proper maintenance ensures the system remains efficient,
secure, and adaptable to future business needs.

What is Object-Oriented System Development Methodology?

Object-Oriented System Development Methodology (OOSDM) is a software
development approach that builds a system using objects, classes, methods, and their
interactions throughout the entire development life cycle.

Simply: It is a step-by-step method to develop software using object-oriented concepts

from analysis to maintenance.

Goal of OOSDM
To develop a software system that is:
✔ Closer to real-world models
✔ Easy to modify, reuse, and expand
✔ Built using object-oriented principles (Encapsulation, Inheritance, Polymorphism,
Abstraction)

Phases of Object-Oriented System Development Methodology

OOSDM uses four major phases:

Phase Description Output

Understand the problem, identify

Object-Oriented Requirement model + Use
actors, use cases, and system
Analysis (OOA) case diagrams
requirements

Class diagrams, sequence

Object-Oriented Design system architecture using
diagrams, database
Design (OOD) objects, classes, relationships
schema

Implement the system design using

Object-Oriented Executable code /
OOP languages (Java, Python, C++,
Programming (OOP) software
C#, [Link] etc.)
Phase Description Output

Object-Oriented Verify object behavior, interaction, and Tested system with no

Testing (OOT) functionality bugs

After testing → Deployment → Maintenance.

Main Characteristics of OOSDM

Feature Explanation

System is developed in repeated cycles until

Iterative
complete

Small modules are developed and added

Incremental
step-by-step

System is divided into multiple reusable

Component-based
components

Objects & classes can be reused across

Reusable
systems

Continues the object concept throughout Objects are used in every phase, not only
development during coding

Activities in Each Phase

Phase Activities Involved

OOA Identify objects, attributes, methods, actors, use cases

OOD Define class structures, class-relationships, module interactions, user interface design

OOP Coding, creating objects, implementing classes & inheritance

OOT Unit testing, integration testing, system testing

Real-Time Example

Consider a Hospital Management System

Phase Example

OOA Identify objects: Patient, Doctor, Appointment, Bill

OOD Create class model, sequence diagram for appointment scheduling

OOP Implement classes in Java/Python

OOT Test appointment booking, bill calculation, doctor schedule

Summary Table

Concept Description

OOSDM A methodology for developing software using OO principles

Uses OOA → OOD → OOP → OOT sequence

Focus Objects, classes, relationships, interactions

Benefit Reusable, maintainable, scalable and real-world oriented software

Unified Process in OOAD

The Unified Process (UP) in Object-Oriented Analysis and Design (OOAD) is a flexible and
iterative approach to developing software. It focuses on creating working software
increments, collaborating with team members, and adapting to changes.

What is Unified Process?

The Unified Process (UP) in Object-Oriented Analysis and Design (OOAD) is a software
development methodology that emphasizes iterative development, collaboration, and
flexibility. It is based on the Unified Modeling Language (UML) and is characterized by its
use of use cases to drive development, its focus on architecture-centric development, and its
emphasis on risk management and incremental delivery. UP is a flexible and adaptable
process that can be tailored to meet the specific needs of a project or organization, making it a
popular choice for many software development teams.
Importance of Unified Process
• Complex software projects are made more manageable by Unified Process. It breaks
them into smaller, iterative chunks.
• Clear guidelines and workflows from Unified Process boost communication. It e-
nsures stakeholder collaboration is seamless.
• Continuous feedback is emphasized by UP's approach. High-quality software meeting
requirements are the result.
Key Principles of Unified Process
Below are the key principles of the Unified Process:
• Iterative and Incremental: Unified Process divides the development process into
multiple iterations, with each iteration adding new functionality incrementally.
• Use Case Driven: The Unified Process focuses on identifying and prioritizing use
cases that represent the system's functionality from the user's perspective.
 • Architecture-Centric: The Unified Process emphasizes defining and refining the
system architecture throughout the development process.
• Risk Management: Unified Process identifies and manages project risks proactively
to minimize their impact on the project's success.
• Continuous Validation: Unified Process ensures continuous validation of the
system's requirements, design, and implementation through reviews, testing, and
feedback.
Phases of Unified Process
Unified Process (UP) is characterized by its iterative and incremental approach to software
development. The phases in Unified Process provide a structured framework for managing
the various activities and tasks involved in building a software system. Here's an in-depth
look at each phase:
1. Inception
This is the initial phase where the project's scope, objectives, and feasibility are determined.
Key activities in this phase include identifying stakeholders, defining the initial requirements,
outlining the project plan, and assessing risks. The goal of this phase is to establish a solid
foundation for the project and ensure that it is worth pursuing.
2. Elaboration
In this phase, the project requirements are analyzed in more detail, and the architecture of the
system is defined. Key activities include developing use cases, creating the architectural
baseline, identifying key components, and refining the project plan. The goal of this phase is
to mitigate major risks and establish a solid architectural foundation for the project.
3. Construction
This is the phase where the actual implementation of the system takes place. Key activities
include developing, testing, and integrating the system components, as well as continuously
verifying that the system meets the requirements. The goal of this phase is to build a
complete, high-quality software product that is ready for deployment.
4. Transition
In this final phase, the software is deployed to end users. Key activities include user training,
final system testing, and transitioning the system to the operations and maintenance team.
The goal of this phase is to ensure a smooth transition from development to production and to
address any issues that arise during deployment.
These phases are iterative, meaning that they may be revisited multiple times throughout the
project to incorporate feedback, make improvements, and address changes in requirements.
This iterative approach allows for flexibility and adaptability, making the Unified Process
well-suited for complex and evolving software projects.
Workflows in Unified Process
Below are the different workflows in the Unified Process:
 • Requirements Workflow: Identifies, analyzes, and prioritizes system requirements,
ensuring alignment with stakeholder needs.
• Analysis and Design Workflow: Translates requirements into system designs,
defining the architecture and high-level structure of the system.
• Implementation Workflow: Implements system functionality based on design
specifications, coding and integrating components as needed.
• Test Workflow: Designs and executes test cases to verify system functionality,
ensuring the software meets quality standards.
• Deployment Workflow: Prepares and transitions the system for deployment,
ensuring a smooth transition from development to production.
• Configuration and Change Management: Manages configuration items and tracks
changes, ensuring version control and integrity throughout development.
• Project Management Workflow: Oversees project progress, resources, and schedule,
ensuring timely delivery and adherence to quality standards.
• Environment Workflow: Sets up and maintains development, testing, and production
environments, enabling efficient software development.
Artifacts and Deliverables in Unified Process
Artifacts and deliverables in the Unified Process (UP) are documents and work products that
are created and used throughout the software development process. These artifacts and
deliverables help to capture and communicate important information about the project,
including requirements, design decisions, and implementation details.
Some common artifacts and deliverables in the UP include:
• Vision Document: Provides an overview of the project's objectives, scope, and
stakeholders' needs.
• Use Case Model: Describes the system's functionality from the user's perspective,
detailing use cases and actors.
• Design Model: Represents the system's architecture and design, including class
diagrams, sequence diagrams, etc.
• Implementation Model: Provides detailed specifications for implementing system
functionality, often including code.
• Test Plan: Outlines the approach and strategy for testing the system, including test
cases and test scenarios.
• Deployment Plan: Describes the steps and considerations for deploying the system to
users or production environments.
• User Manual: Provides instructions and guidelines for users on how to interact with
and use the system effectively.
 • Project Schedule: Specifies the timeline and milestones for project activities, helping
to track progress and deadlines.
Roles and Responsibilities of Unified Process
In the Unified Process (UP), there are several roles with specific responsibilities that
contribute to the successful development of a software system. These roles and their
responsibilities include:
• Project Manager: Responsible for overall project planning, scheduling, resource
allocation, and coordination of activities. The project manager ensures that the project
is completed on time, within budget, and meets the specified requirements.
• Architect: Responsible for defining the overall architecture of the system, including
its structure, components, and interactions. The architect ensures that the system is
scalable, maintainable, and meets the desired quality attributes.
• Analyst: Responsible for gathering and analyzing requirements from stakeholders
and translating them into detailed specifications. The analyst also helps to identify
risks and propose mitigation strategies.
• Designer: Responsible for creating detailed designs for the system, including class
diagrams, sequence diagrams, and other UML diagrams. The designer works closely
with the architect to ensure that the design aligns with the overall architecture.
• Developer: Responsible for implementing the system according to the design
specifications. The developer writes code, tests it, and integrates it with other
components of the system.
• Tester: Responsible for testing the system to ensure that it meets the specified
requirements and is free of defects. The tester develops test cases, executes them, and
reports any issues found.

Review of Objects in OOAD

What is an Object?
Object-nu sonna real-world thing-oda software version.
• State (Attributes / Data)
• Behavior (Methods / Operations)
• Identity (Unique existence)

Example:
Car is an object.
• State: color, speed, model
• Behavior: start(), stop(), accelerate()
 Characteristics of an Object

Feature Meaning (Simple English)

State Object-la store aagura values (attributes).

Behavior Object enna actions perform pannum (methods).

Identity Every object has a unique ID (even if values same).

Abstraction Complex things-a simple-aa represent panradhu.

Encapsulation Data + Methods together pack panradhu; protection.

Objects in OOAD (Conceptual View)

OOAD-la objects are used to represent:
1. Real-world entities (Student, Teacher, Account)
2. Conceptual entities (Transaction, Booking)
3. Software components (Controllers, Services in design)

How Objects Interact?

Objects interact using messages.
Example:
[Link](order)
Customer object → sends message → Order object.

Objects vs Classes

Class Object

Blueprint / Template Actual entity created from class

Defines attributes & behaviors Contains real values

Not memory-consuming Occupies memory

Example:
• Class → Car
• Object → Ani's Car, Friend’s Car
 Benefits of Using Objects in OOAD
• Reusability
• Maintainability
• Modularity
• Flexibility
• Easy to map real-world → software

Notations (UML Object Diagram)

Objects-a UML-la represent pannum pothu:
ObjectName : ClassName
----------------------
attribute1 = value
attribute2 = value
Example:
ani : Student
----------------------
name = "Ani"
rollNo = 12

What is Polymorphism?
The word Polymorphism comes from Greek:
• Poly → Many
• Morph → Forms
So, Polymorphism = Ability of a message (method) to take multiple forms.
It allows the same method name to perform different behaviors in different objects.

Same function name, different outputs based on the object.

Why Polymorphism is Used?

✔ Increases code flexibility
✔ Improves reusability
✔ Supports dynamic behavior in runtime

Types of Polymorphism
Polymorphism is mainly of two types:

Type Also Called Happens When? Example

Compile-time Static / Early Method is fixed during Method

Polymorphism Binding compilation Overloading

Dynamic / Late Method

Runtime Polymorphism Method selected at runtime
Binding Overriding

Compile-time Polymorphism (Method Overloading)

Same method name but different parameters.
Example:
class MathOps {
int add(int a, int b) { return a+b; }
int add(int a, int b, int c) { return a+b+c; }
}
Here → add() method has multiple forms.

Runtime Polymorphism (Method Overriding)

Same method name and parameters → different behavior in child class.
Example:
class Animal {
void sound() { [Link]("Animal sound"); }
}

class Dog extends Animal {

void sound() { [Link]("Bark"); }
}
When you call:
Animal a = new Dog();
[Link](); // Output: Bark

Method behavior changes at runtime.

Operator Overloading (Language-Dependent)

In some languages like C++:
+ operator → adds numbers
+ operator → concatenates strings
This is also polymorphism.
(Not supported in Java except for Strings)

Real-World Example
Example: Remote Control - Same button, different behavior
• TV → Volume up increases TV volume
• Set-top box → Volume up increases sound of STB
Same action → Different results.

Relationship with Inheritance

Polymorphism works with inheritance and interfaces:
• Child class overrides parent class method
• Interface implemented by many classes with different behavior

Advantages of Polymorphism

Benefit Meaning

Flexibility One interface multiple implementations

Reusability Write code once → works for many objects

Easy maintenance Modification only in subclasses

 Summary Table

Feature Meaning

Polymorphism One method → many forms

Key concept Overloading (compile-time), Overriding (runtime)

Result Dynamic behavior & flexible code

Relationship Strongly linked with inheritance

What is Object Relationship?

In OOAD, object relationship refers to the ways in which objects/classes are connected
and interact with each other inside a system.

Objects do not work independently — they collaborate to perform system functions.

Why Relationships are Needed?

Reason Purpose

To connect objects Share data / actions

To show dependencies Which object uses another

To represent real-world structure Like employee works in department

To improve design Understanding system communication

Types of Object Relationships

OOAD mainly uses four important relationships:

Keyword /
Relationship Meaning Example
Symbol

General relationship / “uses” / “works Student — attends —

Association
communication with” Course

Whole–part relationship Department has

Aggregation “has-a”
(weak) Teachers

Strong whole–part House contains

Composition “contains”
relationship Rooms
 Keyword /
Relationship Meaning Example
Symbol

Generalization /
Parent–child relationship “is-a” Dog is-a Animal
Inheritance

Association
General link between two objects where both can exist independently.
Example:
Doctor — treats — Patient
Diagram notation:
Doctor -------------- Patient

Aggregation (Weak Whole–Part)

Represents a whole–part relationship where the part can exist independently from the
whole.
Example:
Department has Teachers
Even if a department is removed, teachers still exist.
Diagram notation:
Department ◇------- Teacher
(Hollow diamond)

Composition (Strong Whole–Part)

Represents a whole–part relationship where the part cannot exist independently.
Example:
House contains Rooms
If the house is destroyed, rooms do not remain.
Diagram notation:
House ◆------- Room
(Filled diamond)
 Generalization / Inheritance
Relationship where the child acquires the features of the parent.
Example:
Dog is-a Animal
Diagram notation:
Animal △------- Dog

Other (Minor) Relationships

Some OOAD texts also include:

Relationship Meaning

Dependency Temporary usage of another object

Multiplicity Number of objects in a relationship (1..*, 0..1 etc.)

Real-World Example – Library System

Object Relationship

Library — contains — Books Composition

Member — borrows — Book Association

Librarian — manages — Books Association

EBookLibrary — is-a — Library Inheritance

Library — has — Staff Aggregation

Summary Table

Concept Meaning

Object Relationship How objects connect and communicate

Association General relationship

Aggregation Whole–part (independent)

Composition Whole–part (dependent)

Concept Meaning

Generalization IS-A inheritance

UML Diagram – Object Relationships

┌────────────┐ Association (↔) ┌────────────┐
│ Teacher │ ─────────────────────────────────→ │ Student
│
└────────────┘ (Teacher teaches Student) └────────────┘

┌────────────┐ Aggregation (◇) ┌────────────┐

│ Department │ ◇──────────────────────────→ │ Teacher │
└────────────┘ (Teachers are part of dept,
but can exist separately)

┌────────────┐ Composition (◆) ┌────────────┐

│ House │ ◆────────────────────────→ │ Room │
└────────────┘ (Room cannot exist without house)

┌────────────┐ Dependency (↝) ┌────────────┐

│ Customer │ ↝────────────────────────→ │ Invoice │
└────────────┘ (Customer uses invoice,
no lifelong link)

┌────────────┐ Generalization (Inheritance) ┌────────────┐

│ Person │ ────────────────▲──────────────── │ Student
│
└────────────┘ │ └────────────┘
│
 │
└──────────────→ ┌────────────┐
│ Teacher │
└────────────┘

Meaning of Symbols

Relationship Type UML Symbol Meaning

Association — Simple link / communication

Aggregation ◇ Whole–Part (loose)

Composition ◆ Whole–Part (strong)

Dependency ↝ Temporary link / uses

Generalization / Inheritance Arrow ▲ Parent–child / Is-a relationship

Quick Real-World Examples

Relationship Example Explanation

Association Doctor ↔ Patient Doctor treats Patient

Aggregation Library ◇ Books Books can exist outside library

Composition Car ◆ Engine Engine cannot exist without Car

Dependency User ↝ LoginService User depends on Login system

Generalization Animal → Dog Dog is an Animal

Component-Based Development (CBD)

Component-Based Development is a software development approach where an application
is built by combining pre-built, reusable software components instead of developing
everything from scratch.

Simple meaning
CBD = Create software like assembling LEGO bricks
Each brick = Component (pre-built module)
Final application = Combination of multiple components
 What is a Component?
A component is a self-contained software unit that:
✔ Performs a specific function
✔ Can be reused in different applications
✔ Can be developed, replaced, or upgraded independently
Example components:
• Login module
• Payment module
• Image upload module
• Email sending module
• Notification module

Key Features of Components

Feature Description

Reusability Same component can be used in multiple apps

Independence Each component can be developed separately

Replaceability A component can be changed without affecting others

Encapsulation Internal code hidden — only interface available

Interoperability Works with other components via interfaces

CBD Development Model – Phases

Requirement Analysis
Identify what components are needed

Component Selection / Development

Choose existing components or build new ones

Component Integration
Combine components using interfaces

Component Testing
Test individual components
 System Testing & Deployment
Test full system and deliver to users

🏛 Architecture of Component-Based Systems

┌─────────────────────────────┐
│ Application │
│ (Composed of Components) │
└────────────┬─────┬──────────┘
│ │
┌──────────▼──┐ │ ┌──────────▼────────┐
│ Login │ │ │ Payment │
│ Component │ │ │ Component │
└─────────────┘ │ └────────────────────┘
│
┌─────────▼────────┐
│ Notification │
│ Component │
└───────────────────┘

Advantages of CBD

Benefit Explanation

Faster development Reusing components saves time

Low cost No need to build every feature

Better quality Pre-tested components reduce bugs

Easy maintenance Replace or update components independently

High scalability New components can be added easily

⚠ Disadvantages of CBD
Disadvantage Explanation

Difficult to select correct components Not all components will fit easily

Integration issues Compatibility problems may occur

Expensive initial development Creating reusable components takes time

Version management Updating one component may affect others

Where CBD is used?

Industry / Area Examples

Web Applications Payment gateway, Authentication APIs

Mobile Apps Battery manager, Camera module

Gaming Physics engine, Audio engine

E-commerce Cart system, Inventory system

Enterprise Systems ERP modules, CRM modules

✔ Real-time Example
If you build an Online Shopping Website, you don't code everything.
You assemble components like:
• User Login Component
• Product Display Component
• Cart Component
• Payment Component
• Email Component
These components are assembled → the website becomes complete.

Summary

CBD Concept One Sentence

Idea Build software using reusable components

Goal Reduce development time & cost

CBD Concept One Sentence

Component Independent reusable software unit

Result Fast development + easy maintenance

RAD – Rapid Application Development

RAD stands for Rapid Application Development.
It is a software development methodology that focuses on fast development, quick
delivery, and continuous user feedback.

Simple Meaning
RAD = Develop software quickly by building prototypes → get user feedback → improve →
finalize.
Instead of spending long time on planning, RAD focuses on building working models in
short cycles.

Key Principles of RAD

Principle Meaning

Fast development Reduce development time

Prototyping Build sample models instead of full system first

User involvement Users continuously give feedback

Iterative improvement System is improved step-by-step

Reusability Use reusable components to speed development

RAD Development Phases

Requirement Planning
• Collect basic requirements
• No long documentation
• Users + Developers discuss together

User Design Phase

• Build prototype (sample screens / demo model)
 • User reviews and gives suggestions
• Prototype revised again and again

Construction Phase
• Full system is developed using approved prototype
• Use automated tools / reusable components to speed development

Cutover / Implementation Phase

• Testing + Data conversion + User training
• System delivered to users

RAD Model Diagram

┌───────────────┐
│ Requirement │
│ Planning │
└──────┬────────┘
│
┌──────▼─────────┐
│ User Design │ ↔ Prototyping & Feedback
└──────┬─────────┘
│
┌──────▼─────────┐
│ Construction │
└──────┬─────────┘
│
┌──────▼─────────┐
│ Implementation │
└───────────────┘

Advantages of RAD
Benefit Explanation

Very fast development Product delivered quickly

High user satisfaction Continuous user input

Reduced risk Errors found early via prototypes

Better flexibility Changes accepted anytime

⚠ Disadvantages of RAD

Drawback Explanation

Not suitable for large complex projects Too many modules → difficult to manage

Requires skilled developers Needs experts in rapid designing

Requires continuous user participation If users are not available → project fails

Cost may increase Use of tools and prototypes is expensive

When to Use RAD?

RAD is suitable when:
✔ Requirements are changing frequently
✔ Quick delivery is needed
✔ Users can actively participate
✔ Project scope is small or medium

Not suitable when:

✖ Project is very large and complex

✖ Performance is extremely critical
✖ Users are not available for feedback

✔ Real-time Example
If a company wants to build a mobile banking app quickly:
1. Developers create a prototype showing login, balance, payment screens
2. Users test and give feedback
3. Developers modify features fast
4. Final app is built based on accepted prototype
This is RAD approach.

Summary Table

Topic Summary

RAD Rapid Application Development

Focus Fast delivery + Prototypes + User feedback

Model Type Iterative

Best for Small/Mid projects, frequent changes

Key Benefit Faster time to market

Dynamic Binding (Late Binding / Run-time Binding)

Dynamic binding means that the method to be executed is decided at run-time (during
program execution), not at compile time.

Simple Meaning
When a function call is linked to the actual function while the program is running, it is
called dynamic binding.
Dynamic binding is used to achieve polymorphism.

When does Dynamic Binding happen?

It happens when:
• A parent class reference points to a child class object
• And method overriding is used

The decision → “Which method should run?” is taken at run time based on the object
type.

Simple Example (in real life)

A Remote control can control:
• TV
• Set-top box
 • Sound system
Remote button = Command (method)
Actual device receiving command = Object (decided at runtime)
So the same button (method) performs different actions depending on the device (object
type).

Program Example (Java)

class Animal {
void sound() {
[Link]("Animal makes a sound");
}
}

class Dog extends Animal {

void sound() {
[Link]("Dog barks");
}
}

public class Main {

public static void main(String[] args) {
Animal obj = new Dog(); // Parent reference → Child object
[Link](); // Output: Dog barks (Runtime decision)
}
}
Explanation
• obj is an object of Dog, but it is referenced by Animal
• JVM decides at runtime which sound() method to call → Dog method

✔ This is Dynamic Binding

Why Dynamic Binding is Important?

Benefit Explanation

Supports polymorphism Same method name behaves differently

Flexibility New child classes can be added without changing existing code

Extensibility Easy to extend applications

Reusability Parent references can handle many child objects

Dynamic Binding vs Static Binding

Static Binding Dynamic Binding

At compile time At run time

Function decided early Function decided late

Used in method overloading Used in method overriding

Faster Slight slower

Example: private, static, final methods Example: overridden methods

⚙ Languages That Support Dynamic Binding

• Java
• Python
• C#
• C++
• [Link]
• Ruby

Summary

Topic Description

Dynamic Binding Method call is decided at run time

Other names Run-time binding, Late binding

Requirement Method overriding + parent reference, child object

Topic Description

Related concept Polymorphism

TESTING:

Software Testing
Software testing is the process of verifying and validating that a software system or
application:

✔ Works as intended
✔ Meets user requirements
✔ Is free from defects or errors
Simply: Testing = Checking the system to ensure it works correctly and reliably.

Objectives of Testing

Objective Explanation

Detect errors Find bugs in code before deployment

Ensure quality Ensure software meets functional and non-functional requirements

Improve reliability System should perform correctly in all scenarios

Verify performance Check speed, security, and stability

User satisfaction Confirm system meets user expectations

Types of Testing

Functional Testing
• Tests what the system does (functionality)
• Example: Login works, Payment processes correctly

Non-Functional Testing
• Tests how the system works (performance, security, usability)
• Example: Response time < 2 seconds, secure password storage

Structural / White Box Testing

• Tests internal code and logic
 • Example: Path coverage, loop testing

Black Box Testing

• Tests without knowing internal code
• Example: Input → Output validation

Unit Testing
• Tests individual modules / components
• Example: Testing Login() function independently

Integration Testing
• Tests interaction between modules
• Example: Payment module interacting with Order module

System Testing
• Tests the entire system as a whole
• Example: Full e-commerce app tested end-to-end

Acceptance Testing
• Done by users to verify requirements
• Example: Client checks hospital management system before deployment

Testing in OOAD
In Object-Oriented Analysis and Design (OOAD), testing focuses on:
1. Objects – Check if objects perform expected behaviors
2. Messages / Interactions – Check communication between objects
3. Classes / Inheritance – Ensure overridden methods work properly
4. Polymorphism – Verify dynamic binding works correctly

Testing Life Cycle (STLC)

Requirement Analysis

Test Planning

Test Design

Test Implementation
 Test Execution

Defect Reporting & Tracking

Test Closure

Testing Techniques

Technique Description

Manual Testing Tester executes test cases manually

Automated Testing Use tools like Selenium, JUnit, NUnit

Regression Testing Ensure new changes do not break existing code

Smoke Testing Quick check to see if build is testable

Performance Testing Check speed, scalability, and load handling

Security Testing Check for vulnerabilities

Advantages of Testing

Advantage Explanation

Detect defects early Reduces cost and time for fixing bugs

Improve software quality Ensures correct functionality

Ensure reliability System works under all scenarios

Meet user expectations Increases user satisfaction

⚠ Disadvantages / Challenges

Disadvantage Explanation

Time-consuming Requires thorough test planning

Costly Especially for automated tools and complex testing

Not always bug-free Some errors may still remain

Requires skilled testers Knowledge of OOAD, programming, and tools needed

 Summary Table

Topic Meaning / Key Points

Testing Process to verify software correctness

Focus in OOAD Objects, classes, interactions, polymorphism

Types Unit, Integration, System, Acceptance, Functional, Non-functional

Purpose Detect defects, ensure quality, meet requirements

Overview of Software Development Methodologies

A software development methodology is a framework or process used to plan, structure,
and control the development of software systems.
Different methodologies define how requirements, design, coding, testing, and
maintenance are handled.

Waterfall Model
• Sequential process: each phase must finish before the next begins.
• Phases: Requirement → Design → Implementation → Testing → Deployment →
Maintenance
• Advantages: Simple, easy to manage, documentation heavy
• Disadvantages: Inflexible to changes, late user feedback
• Best for: Projects with stable requirements

Rapid Application Development (RAD)

• Focus: Speedy development and quick delivery
• Features: Uses prototypes, reusable components, iterative design
• Advantages: Fast delivery, high user involvement
• Disadvantages: Requires skilled developers, not suitable for large complex projects
• Best for: Projects with short timelines and frequent requirement changes

Prototyping Model
• Focus: Build a working prototype first, refine based on user feedback
• Features: Iterative, user-centric
• Advantages: Better requirement understanding, reduced risk
• Disadvantages: Can lead to scope creep, cost may increase
• Best for: UI-heavy projects or when requirements are unclear

Object-Oriented Methodology (OOM)

• Focus: Building software using objects and classes (OOAD approach)
• Phases: OOA → OOD → OOP → Testing → Maintenance
• Advantages: Reusable, modular, maintainable, scalable
• Disadvantages: Requires skilled developers, steep learning curve
• Best for: Large, complex systems where real-world modeling is useful

Component-Based Development (CBD)

• Focus: Assemble software from pre-built reusable components
• Advantages: Fast development, reusable components, lower cost in long term
• Disadvantages: Integration issues, component compatibility
• Best for: Enterprise systems, web applications, modular software

Agile Methodology
• Focus: Iterative and incremental development with continuous user feedback
• Features: Scrum, Kanban, sprints, adaptive planning
• Advantages: Flexible, high user satisfaction, reduces risk
• Disadvantages: Requires frequent user involvement, can be hard to manage large
teams
• Best for: Projects with rapidly changing requirements

Spiral Model
• Focus: Combines iterative development with risk analysis
• Phases: Planning → Risk Analysis → Engineering → Evaluation (repeat)
• Advantages: Focuses on risk reduction, iterative
 • Disadvantages: Complex, costly
• Best for: Large, high-risk projects

Comparison Table

Model Approach Key Feature Best For

Waterfall Sequential Phase-wise completion Stable requirements

RAD Iterative Rapid prototyping Short timelines

Prototype Iterative User feedback & refinement Unclear requirements

OOM Object-oriented Reusability & modularity Complex systems

CBD Component assembly Reusable modules Enterprise systems

Agile Iterative & incremental Flexible & adaptive Changing requirements

Spiral Iterative with risk Risk-driven Large, high-risk projects

Key Points:
• Choice of methodology depends on: project size, complexity, risk, user
involvement, time constraints
• Modern trends favor Agile + OOM + CBD for modular, reusable, and flexible
systems.
• RAD, Prototyping, and Agile focus on early user involvement, unlike Waterfall.

Object Modeling Technique (OMT)

OMT is a structured methodology for analyzing and designing object-oriented systems.
It was introduced by James Rumbaugh in the early 1990s.
OMT is widely used in OOAD (Object-Oriented Analysis and Design).

Purpose of OMT
• To analyze and model real-world systems using objects
• To design object-oriented software systems
• To provide diagrams and notations for clarity
 Key Features of OMT

Feature Description

Object-Oriented Focuses on objects as the building blocks

Modeling Creates visual models to understand systems

Structured Follows a systematic approach: analysis → design → implementation

Three main models Object Model, Dynamic Model, Functional Model

OMT Models

Object Model
• Represents the static structure of the system
• Shows classes, objects, and relationships
• Includes:
o Classes and attributes
o Associations between classes
o Inheritance (generalization) relationships
• Example: Class diagram showing Student, Teacher, Course

Dynamic Model
• Represents behavior over time
• Shows how objects interact and change states
• Includes:
o State diagrams
o Events and transitions
• Example: A Student object state: Registered → Enrolled → Graduated

Functional Model
• Represents data flow and transformations
• Shows how inputs are transformed to outputs
 • Includes:
o Data flow diagrams (DFDs)
• Example: Registration process → Input: Student info → Output: Enrollment
confirmation

OMT Process
1. Object Analysis → Identify objects, attributes, relationships
2. Dynamic Analysis → Identify events and state changes
3. Functional Analysis → Identify processes and data flows
4. Design Phase → Create diagrams, define methods, map to programming language
5. Implementation → Code objects based on OMT design

Advantages of OMT

Advantage Explanation

Visual representation Diagrams make design easy to understand

Supports modularity Objects and classes promote modular design

Easy to maintain Clear object models reduce complexity

Supports reuse Classes and components can be reused

⚠ Disadvantages of OMT

Disadvantage Explanation

Steep learning curve Requires knowledge of OO concepts

Complex for small projects Overhead may not be justified

Tool-dependent Needs UML/OMT-compatible tools for diagrams

Example of OMT Diagrams

Object Model (Class Diagram)
┌─────────┐
│ Student │
├─────────┤
│ name │
│ rollNo │
│ age │
├─────────┤
│ register()│
│ payFees() │
└─────────┘

┌─────────┐
│ Course │
├─────────┤
│ cName │
│ credits │
├─────────┤
│ enroll()│
└─────────┘

Relationship: Student → enrolls in → Course

Dynamic Model (State Diagram)
Registered → Enrolled → Graduated
Functional Model (Data Flow)
Student Info → Registration Process → Enrollment Confirmation

Summary Table

Concept Description

OMT Object Modeling Technique for OOAD

Focus Objects, their behavior, and processes

Models Object Model, Dynamic Model, Functional Model

Concept Description

Goal Visual modeling to simplify design and implementation

Creator James Rumbaugh

Booch Methodology
Booch Methodology is an object-oriented software development methodology developed
by Grady Booch.
It is used for analyzing, designing, and developing complex software systems.
It focuses on iterative development, object modeling, and component-based design.

Key Features of Booch Methodology

Feature Description

Object-Oriented Focuses on objects as the main building blocks

Iterative Process Development is done in repeated cycles (iteration)

Diagrams Uses Booch diagrams for modeling objects and interactions

Component-Based Supports modular and reusable design

Phases Covered Analysis, Design, Implementation, Testing

Booch Development Phases

Conceptualization / Analysis
• Identify objects and classes
• Understand system requirements
• Focus on real-world modeling

Specification / Design
• Define object interfaces, relationships, and behaviors
• Prepare class diagrams, object diagrams, and interaction diagrams

Implementation
• Convert design into code
• Map objects to programming constructs (classes, methods, attributes)
 Testing / Maintenance
• Verify system behavior
• Maintain reusable components

Booch Modeling Diagrams

Booch methodology uses 6 types of diagrams:

Class Diagram
• Shows classes, attributes, methods, and relationships (inheritance, association,
aggregation)

Object Diagram
• Snapshot of objects and relationships at a specific time

Interaction Diagram
• Shows messages exchanged between objects during a process

State Transition Diagram

• Represents object behavior over time

Module Diagram
• Shows high-level components / modules and their relationships

Process Diagram
• Represents dynamic flow / control of processes

Advantages of Booch Methodology

Advantage Explanation

Supports large systems Well-suited for complex applications

Iterative approach Errors detected and corrected early

Visual modeling Booch diagrams make understanding easier

Reusable components Promotes modularity and reuse

⚠ Disadvantages of Booch Methodology

Disadvantage Explanation

Complex Diagrams and notation can be complicated for beginners

Tool-dependent Needs CASE tools for effective diagramming

Time-consuming Detailed analysis and modeling increase effort

Real-World Example
If you are building a Banking System:
• Objects: Account, Customer, Transaction
• Class Diagram: Shows attributes like accountNo, balance
• State Diagram: Account state: Active → Frozen → Closed
• Interaction Diagram: Customer sends money → Transaction object → Update
account
Booch methodology helps visualize all these objects, states, and interactions clearly.

Summary Table

Concept Description

Booch Methodology OOAD methodology by Grady Booch

Focus Objects, iterative development, modularity

Key Diagrams Class, Object, Interaction, State, Module, Process

Goal Model and build complex OO systems effectively

Strength Visual, iterative, reusable components

Weakness Complex, requires CASE tools, time-consuming

Jacobson Methodology (OOSE – Object-Oriented Software Engineering)

The Jacobson Methodology was introduced by Ivar Jacobson in the early 1990s.
It is also called OOSE – Object-Oriented Software Engineering.
It focuses on developing software systems using objects, use-cases, and iterative design.

Key Features of Jacobson Methodology

Feature Description

Use-case driven Focuses on modeling system behavior from the user’s perspective

Object-Oriented Uses objects and classes as building blocks

Iterative development System is built incrementally and iteratively

Three main models Object model, Dynamic model, Use-case model

Supports Reuse Promotes reusable components and modularity

Jacobson Methodology Models

Use-Case Model
• Represents system functionality from user’s viewpoint
• Shows actors (users) and interactions with the system
• Example: “Student registers for a course”
• Tools: Use-case diagrams

Object Model
• Represents static structure of the system
• Includes classes, objects, attributes, and relationships
• Example: Student, Course, Teacher and their associations

Dynamic Model
• Represents system behavior over time
• Includes states, events, and transitions
• Example: Student object states: Registered → Enrolled → Graduated

Jacobson Methodology Process

Requirement Analysis
• Identify use cases
• Identify actors and their interactions

Object Analysis
• Identify classes, objects, attributes, and relationships

Dynamic Analysis
 • Model events and object behavior

Design and Implementation

• Prepare class diagrams, interaction diagrams, and state diagrams
• Implement in an OO programming language

Testing and Maintenance

• Test object interactions
• Maintain reusable components

Advantages of Jacobson Methodology

Advantage Explanation

User-centered Use cases make requirements clear

Supports OOAD Combines object, dynamic, and use-case models

Modular & reusable Objects and components can be reused

Iterative Errors detected early and requirements refined

⚠ Disadvantages

Disadvantage Explanation

Requires skilled developers Use-case modeling and OOAD expertise needed

Complex for beginners Multiple models increase learning curve

Tool-dependent Diagrams are easier with CASE tools

Example
University Registration System:
• Actors: Student, Admin, Teacher
• Use Case: “Register Course” → Student selects courses → System validates →
Confirmation sent
• Object Model: Classes: Student, Course, Department
• Dynamic Model: Student state: Registered → Enrolled → Graduated
Jacobson methodology maps user actions to system objects and their behavior.
 Summary Table

Concept Description

Jacobson Methodology OOAD methodology by Ivar Jacobson (OOSE)

Focus Use-case driven, object-oriented, iterative

Models Use-case, Object, Dynamic

Goal Build systems based on user requirements

Strength Clear user focus, reusable objects

Weakness Complex for beginners, tool-dependent

Rumbaugh Methodology (OMT – Object Modeling Technique)

The Rumbaugh Methodology, also called OMT (Object Modeling Technique), was
developed by James Rumbaugh in the 1990s.
It is a structured object-oriented methodology for analyzing, designing, and developing
software systems using objects, classes, and interactions.

Key Features of Rumbaugh Methodology

Feature Description

Object-Oriented Uses objects and classes to model real-world entities

Structured Approach Follows systematic steps: analysis → design → implementation

Three Main Models Object Model, Dynamic Model, Functional Model

Supports Reuse Classes and components can be reused in multiple systems

Visual Modeling Uses UML-style diagrams to represent objects and interactions

Three Models of Rumbaugh Methodology

Object Model
• Represents the static structure of the system
• Shows classes, attributes, objects, and relationships
• Example: Student, Teacher, Course classes and their associations
 Dynamic Model
• Represents system behavior over time
• Shows states, events, and transitions of objects
• Example: Student object states: Registered → Enrolled → Graduated

Functional Model
• Represents data flow and transformations
• Shows processes that manipulate data
• Example: Registration process → Input: Student info → Output: Enrollment
confirmation

Rumbaugh Methodology Process

Object Analysis
• Identify objects, attributes, and relationships

Dynamic Analysis
• Identify events and state changes for objects

Functional Analysis
• Identify processes and data flow

Design Phase
• Create diagrams: class diagrams, state diagrams, data flow diagrams

Implementation
• Map objects to programming language constructs (classes, methods)

Advantages of Rumbaugh Methodology

Advantage Explanation

Visual modeling Easy to understand system using diagrams

Reusable components Classes and objects can be reused

Modularity System divided into manageable objects and components

Supports OOAD Well-suited for object-oriented design

⚠ Disadvantages

Disadvantage Explanation

Complex for beginners Multiple models can be confusing

Tool-dependent Needs CASE tools for diagramming

Time-consuming Detailed modeling may increase effort

Example
Library Management System:
• Object Model: Classes: Book, Student, Librarian
• Dynamic Model: Book states: Available → Issued → Returned
• Functional Model: IssueBook process → Input: Book & Student → Output: Updated
status
This methodology maps objects, behavior, and processes to build the system efficiently.

Summary Table

Concept Description

Rumbaugh Methodology Object-Oriented Modeling Technique (OMT) by James Rumbaugh

Focus Objects, their behavior, and processes

Models Object Model, Dynamic Model, Functional Model

Goal Model real-world systems for OO software development

Strength Reusable, visual, modular

Weakness Complex, tool-dependent, requires experience

Design Patterns
A design pattern is a reusable solution to a commonly occurring problem in software
design.
Simply: Design patterns are best-practice templates for solving recurring problems in
software development.
They don’t provide code directly, but provide a guide or template that can be
implemented in any programming language.
 Why Use Design Patterns?

Reason Explanation

Reusability Solve common problems without reinventing the wheel

Maintainability Easier to modify and maintain code

Scalability Patterns provide structure for future growth

Communication Standard terminology for developers

Best Practices Proven solutions from experienced developers

Categories of Design Patterns

Creational Patterns
• Deal with object creation
• Help decouple system from concrete classes
• Examples:
o Singleton – Only one instance of a class exists
o Factory Method – Creates objects without specifying exact class
o Abstract Factory – Creates families of related objects
o Builder – Builds complex objects step by step
o Prototype – Creates new objects by copying existing ones

Structural Patterns
• Deal with object composition and relationships
• Help organize classes and objects into larger structures
• Examples:
o Adapter – Converts interface of a class to another interface
o Decorator – Adds responsibilities to objects dynamically
o Facade – Provides simplified interface to complex subsystem
o Composite – Represents part-whole hierarchy
o Proxy – Controls access to an object
 Behavioral Patterns
• Deal with object interaction and communication
• Help define how objects collaborate and respond
• Examples:
o Observer – One object updates others automatically
o Strategy – Allows selecting algorithm at runtime
o Command – Encapsulates a request as an object
o Template Method – Defines skeleton of algorithm, subclasses override steps
o Iterator – Access elements of a collection sequentially

Key Concepts

Concept Explanation

Pattern Name A common name for the pattern (e.g., Singleton)

Problem The recurring issue the pattern solves

Solution The approach/template to solve the problem

Consequences Pros and cons of using the pattern

Example: Singleton Pattern

Problem: Only one object of a class should exist (e.g., a PrinterManager or Database
connection).
Solution:
class Singleton {
private static Singleton instance;
private Singleton() {} // private constructor
public static Singleton getInstance() {
if(instance == null) {
instance = new Singleton();
}
return instance;
 }
}
Usage: Ensures only one instance exists and is accessible globally.

Advantages of Using Patterns

Advantage Explanation

Reusable solutions Can apply pattern in multiple projects

Faster development Don’t need to solve the same problem repeatedly

Improved code readability Standard patterns improve communication

Reduce errors Patterns are proven solutions

⚠ Disadvantages / Challenges

Disadvantage Explanation

Complexity Patterns can be overused or misunderstood

Learning curve Developers need experience to apply patterns correctly

Not a complete solution Must adapt to the context of the project

Summary Table

Topic Description

Design Pattern Reusable solution to a common software problem

Types Creational, Structural, Behavioral

Purpose Improve code reusability, maintainability, and communication

Example Singleton, Observer, Factory Method, Decorator

UML (Unified Modeling Language)

UML is a standard visual modeling language used to analyze, design, and document
object-oriented systems.
It provides diagrams and notations to represent classes, objects, relationships, behavior,
and interactions.
Simply: UML = Blueprint for object-oriented software systems
It was developed by the “Three Amigos” – Booch, Rumbaugh, and Jacobson.

Purpose of UML

Purpose Explanation

Visual Modeling Helps understand complex systems using diagrams

Communication Standardizes design between developers and stakeholders

Documentation Provides clear system design documents

Analysis & Design Used in OOAD process to model objects and relationships

Implementation Planning Helps map design to code easily

Types of UML Diagrams

UML diagrams are divided into two major categories:

Structural Diagrams (Static View)

• Represent static aspects of a system: objects, classes, relationships

Diagram Purpose

Class Diagram Shows classes, attributes, methods, and relationships

Object Diagram Snapshot of objects and their relationships at a point in time

Component Diagram Shows software components and dependencies

Deployment Diagram Shows hardware nodes and software deployment

Package Diagram Groups related classes into packages

Composite Structure Diagram Shows internal structure of classes and collaborations

Behavioral Diagrams (Dynamic View)

• Represent dynamic behavior, interactions, and flow in a system
Diagram Purpose

Use Case Diagram Shows actors and system functionality

Sequence Diagram Shows interaction between objects over time

Communication Diagram Shows object relationships and message flows

State Machine Diagram Shows states of objects and transitions

Activity Diagram Shows workflow and processes

Timing Diagram Shows object behavior over time intervals

Interaction Overview Diagram Combination of activity and sequence diagrams

Key UML Concepts

Concept Explanation

Actor Entity (user/system) interacting with the system

Use Case Functional requirement / action of the system

Class Template for creating objects (attributes + methods)

Object Instance of a class

Association Relationship between classes/objects

Inheritance / Generalization “Is-a” relationship between classes

Aggregation / Composition “Has-a” relationship between classes

Advantages of UML

Advantage Explanation

Standardization Widely accepted standard for OO modeling

Visualization Makes complex systems easier to understand

Communication Helps communicate design to stakeholders

Documentation Provides reusable system documentation

Supports OOAD Can be used in all phases: Analysis → Design → Implementation

⚠ Disadvantages of UML

Disadvantage Explanation

Can be complex Too many diagram types can confuse beginners

Tool-dependent Best used with CASE tools like StarUML, Visual Paradigm

Learning curve Requires understanding of OO concepts and UML notations

Example of UML Use

Library Management System
• Actors: Librarian, Student
• Use Case Diagram: Borrow Book, Return Book, Reserve Book
• Class Diagram: Classes: Book, Student, Librarian
• Sequence Diagram: Student → BorrowBook() → Librarian → UpdateInventory()

Summary Table

Concept Description

UML Unified Modeling Language

Purpose Visual modeling, documentation, and communication

Diagram Structural (Class, Object, Component, Deployment) & Behavioral (Use Case,
Types Sequence, Activity, State)

Key
Actor, Use Case, Class, Object, Relationships
Concepts

Strength Standardized, visual, supports OOAD

Weakness Complex, tool-dependent, learning curve

UML Class Diagram

A Class Diagram is a type of structural diagram in UML that shows:
• Classes (blueprints of objects)
• Attributes (data stored in class)
• Methods / Operations (functions performed by class)
 • Relationships (associations, inheritance, aggregation, composition)
Simply: Class Diagram = Static view of the system
It is the backbone of OOAD, used in analysis and design.

Components of a Class Diagram

Class
• Represented as a rectangle divided into three compartments:
+-------------------+
| Class Name |
+-------------------+
| Attributes |
+-------------------+
| Methods / Operations |
+-------------------+
• Example:
+-------------------+
| Student |
+-------------------+
| rollNo: int |
| name: string |
| age: int |
+-------------------+
| registerCourse() |
| payFees() |
+-------------------+

Attributes
• Represent data or properties of a class
• Syntax: visibility name: type
• Visibility symbols:
 o + Public
o - Private
o # Protected
Example: +name: string

Methods / Operations
• Represent behavior / functions of the class
• Syntax: visibility name(parameters): returnType
Example: +registerCourse(course: Course): void

Relationships
1. Association → A link between two classes
o Example: Student ----enrolls----> Course
2. Multiplicity → Number of objects in the relationship
o 1, 0..1, 1..*, *
3. Aggregation (Has-a) → Represents whole-part relationship (hollow diamond)
o Example: Library <>---- Book
4. Composition (Strong Has-a) → Represents strong ownership (filled diamond)
o Example: House ◆---- Room
5. Inheritance / Generalization (Is-a) → Child class inherits from parent class (arrow
with hollow triangle)
o Example: Dog ─|> Animal
6. Dependency → One class depends on another (dashed arrow)
o Example: Invoice --> PaymentProcessor

Example Class Diagram

+---------------+
| Person |
+---------------+
| -name: string |
 | -age: int |
+---------------+
| +getDetails() |
+---------------+
^
|
-----------------
| |
+---------------+ +---------------+
| Student | | Teacher |
+---------------+ +---------------+
| -rollNo: int | | -employeeId: int |
| -course: string| | -subject: string |
+---------------+ +---------------+
| +register() | | +teach() |
+---------------+ +---------------+
• Person is a parent class
• Student and Teacher inherit from Person (Generalization)
• Attributes and methods are clearly listed

Advantages of Class Diagrams

Advantage Explanation

Visual Representation Easy to understand system structure

Reusable Design Classes and relationships can be reused

Communication Helps developers and stakeholders understand the system

Supports OOAD Basis for coding classes in object-oriented languages

⚠ Disadvantages
Disadvantage Explanation

Complex for large systems Large diagrams can be confusing

Maintenance effort Requires updates when system changes

Tool-dependent Easier with CASE tools

Summary Table

Component Description

Class Blueprint for objects, contains attributes & methods

Attribute Data stored in class, with visibility (+/-/#)

Method Behavior or function of class

Association Link between classes

Aggregation Whole-part relationship (hollow diamond)

Composition Strong whole-part relationship (filled diamond)

Inheritance Child class inherits from parent (hollow triangle)

Dependency Uses another class (dashed arrow)

Dynamic Modeling
Dynamic Modeling is the process of modeling the behavior of objects over time in a
system.
It focuses on how objects interact, respond to events, and change states during execution.
Simply: Dynamic Modeling = Modeling the system’s behavior and interactions
It is used in Object-Oriented Analysis and Design (OOAD) alongside Object Model
(static) and Functional Model.

Purpose of Dynamic Modeling

Purpose Explanation

Capture Behavior Represent how objects behave in response to events

Event Handling Show responses to internal/external events

Purpose Explanation

Interaction Analysis Model communication between objects

System Simulation Helps in testing and verifying workflows before coding

Key Elements of Dynamic Modeling

1. Objects – Entities whose states change over time
2. Events – Triggers that cause objects to change state
3. States – Different conditions or situations an object can be in
4. Transitions – Movement from one state to another due to events
5. Interactions – Messages exchanged between objects to perform tasks

Types of Dynamic Models

State Diagrams (Statecharts)

• Represent object states and transitions
• Shows how an object changes from one state to another due to events
Example: Student object
Registered → Enrolled → On Leave → Graduated
• Event: “Enroll” → Transition from Registered → Enrolled

Interaction Diagrams
• Represent communication between objects
• Two main types:
1. Sequence Diagram – Shows messages exchanged over time
2. Communication Diagram – Shows object links and message flow
Example: Borrow Book process in Library System
Student → Librarian: requestBook()
Librarian → Book: checkAvailability()
Book → Librarian: returnStatus()
Librarian → Student: issueBook()
 Activity Diagrams
• Represent workflow or process logic
• Shows parallel and sequential activities
• Useful for modeling use-case flows
Example: Online Shopping Checkout Process
Add to Cart → Select Payment → Make Payment → Order Confirmation

Advantages of Dynamic Modeling

Advantage Explanation

Visualizes system behavior Easier to understand dynamic aspects of the system

Detects logical errors Identify invalid states and transitions early

Supports OOAD Complements object and functional models

Improves design Helps in defining inter-object communication

⚠ Disadvantages

Disadvantage Explanation

Complexity Large systems may have many states and interactions

Maintenance Updating dynamic models can be time-consuming

Tool-dependency Often easier with UML/CASE tools

Summary Table

Concept Description

Dynamic
Modeling object behavior over time and interactions
Modeling

Key Elements Objects, States, Events, Transitions, Interactions

Common State Diagram, Sequence Diagram, Communication Diagram, Activity

Diagrams Diagram

Purpose Understand behavior, interactions, workflows

Concept Description

Advantages Visualize behavior, detect errors, support OOAD

Unified Modeling Language (UML) Diagrams

Unified Modeling Language (UML) is a general-purpose modeling language. The main aim
of UML is to define a standard way to visualize the way a system has been designed. It is
quite similar to blueprints used in other fields of engineering. UML is not a programming
language, it is rather a visual language.
• We use UML diagrams to show the behavior and structure of a system.
• UML helps software engineers, businessmen, and system architects with modeling,
design, and analysis.
• The International Organization for Standardization (ISO) published UML as an
approved standard in 2005. UML has been revised over the years and is reviewed
periodically.
Why do we need UML?
• Complex applications need collaboration and planning from multiple teams and hence
require a clear and concise way to communicate amongst them.
• Businessmen do not understand code. So UML becomes essential to communicate
with non-programmers about essential requirements, functionalities, and processes of
the system.
• A lot of time is saved down the line when teams can visualize processes, user
interactions, and the static structure of the system.
Types of UML Diagrams
UML is linked with object-oriented design and analysis. UML makes use of elements and
forms associations between them to form diagrams. Diagrams in UML can be broadly
classified as:
Structural UML Diagrams
Structural UML diagrams are visual representations that depict the static aspects of a system,
including its classes, objects, components, and their relationships, providing a clear view of
the system's architecture. Structural UML diagrams include the following types:
Class Diagram
The most widely use UML diagram is the class diagram. It is the building block of all object
oriented software systems. We use class diagrams to depict the static structure of a system by
showing system's classes, their methods and attributes. Class diagrams also help us identify
relationship between different classes or objects.

Class Diagram
Composite Structure Diagram
We use composite structure diagrams to represent the internal structure of a class and its
interaction points with other parts of the system.
• A composite structure diagram represents relationship between parts and their
configuration which determine how the classifier (class, a component, or a
deployment node) behaves.
• They represent internal structure of a structured classifier making the use of parts,
ports, and connectors.
• We can also model collaborations using composite structure diagrams.
• They are similar to class diagrams except they represent individual parts in detail as
compared to the entire class.
Object Diagram
An Object Diagram can be referred to as a screenshot of the instances in a system and the
relationship that exists between them. Since object diagrams depict behaviour when objects
have been instantiated, we are able to study the behaviour of the system at a particular instant.
• An object diagram is similar to a class diagram except it shows the instances of
classes in the system.
 • We depict actual classifiers and their relationships making the use of class diagrams.
• On the other hand, an Object Diagram represents specific instances of classes and
relationships between them at a point of time.

Component Diagram
Component diagrams are used to represent how the physical components in a system have
been organized. We use them for modelling implementation details.
• Component Diagrams depict the structural relationship between software system
elements and help us in understanding if functional requirements have been covered
by planned development.
• Component Diagrams become essential to use when we design and build complex
systems.
• Interfaces are used by components of the system to communicate with each other

Deployment Diagram
Deployment Diagrams are used to represent system hardware and its software. It tells us what
hardware components exist and what software components run on them.
 • We illustrate system architecture as distribution of software artifacts over distributed
targets.
• An artifact is the information that is generated by system software.
• They are primarily used when a software is being used, distributed or deployed over
multiple machines with different configuration

Package Diagram
We use Package Diagrams to depict how packages and their elements have been organized. A
package diagram simply shows us the dependencies between different packages and internal
composition of packages.
• Packages help us to organise UML diagrams into meaningful groups and make the
diagram easy to understand.
• They are primarily used to organise class and use case diagrams

Activity Diagrams
We use Activity Diagrams to illustrate the flow of control in a system. We can also use an
activity diagram to refer to the steps involved in the execution of a use case.
• We model sequential and concurrent activities using activity diagrams. So, we
basically depict workflows visually using an activity diagram.
• An activity diagram focuses on condition of flow and the sequence in which it
happens.
 • We describe or depict what causes a particular event using an activity diagram.
Use Case Diagrams

Use Case Diagrams are used to depict the functionality of a system or a part of a system. They are
widely used to illustrate the functional requirements of the system and its interaction with external
agents(actors).

• A use case is basically a diagram representing different scenarios where the system can be
used.

• A use case diagram gives us a high level view of what the system or a part of the system does
without going into implementation details. '

Activity Diagram
Use Case Diagrams
Use Case Diagrams are used to depict the functionality of a system or a part of a system.
They are widely used to illustrate the functional requirements of the system and its interaction
with external agents(actors).
• A use case is basically a diagram representing different scenarios where the system
can be used.
• A use case diagram gives us a high level view of what the system or a part of the
system does without going into implementation details. '
Sequence Diagram
A sequence diagram simply depicts interaction between objects in a sequential order i.e. the
order in which these interactions take place.
• We can also use the terms event diagrams or event scenarios to refer to a sequence
diagram.
• Sequence diagrams describe how and in what order the objects in a system function.
• These diagrams are widely used by businessmen and software developers to
document and understand requirements for new and existing systems.
Sequence Diagram
Communication Diagram
A Communication Diagram (known as Collaboration Diagram in UML 1.x) is used to show
sequenced messages exchanged between objects.
• A communication diagram focuses primarily on objects and their relationships.
• We can represent similar information using Sequence diagrams, however
communication diagrams represent objects and links in a free form.
Communication Diagram
Timing Diagram
Timing Diagram are a special form of Sequence diagrams which are used to depict the
behavior of objects over a time frame. We use them to show time and duration constraints
which govern changes in states and behavior of objects.
Interaction Overview Diagram
An Interaction Overview Diagram (IOD) is a type of UML (Unified Modeling Language)
diagram that illustrates the flow of interactions between various elements in a system or
process. It provides a high-level overview of how interactions occur, including the sequence
of actions, decisions, and interactions between different components or objects.
Interaction Overview Diagram
6.1. Additions in UML 2.0
• Software development methodologies like agile have been incorporated and scope of
original UML specification has been broadened.
• Originally UML specified 9 diagrams. UML 2.x has increased the number of
diagrams from 9 to 13. The four diagrams that were added are : timing diagram,
communication diagram, interaction overview diagram and composite structure
diagram. UML 2.x renamed statechart diagrams to state machine diagrams.
• UML 2.x added the ability to decompose software system into components and sub-
components.
Tools for creating UML Diagrams
There are several tools available for creating Unified Modeling Language (UML) diagrams,
which are commonly used in software development to visually represent system architecture,
design, and implementation. Here are some popular UML diagram creating tools:
• Lucidchart: Lucidchart is a web-based diagramming tool that supports UML
diagrams. It's user-friendly and collaborative, allowing multiple users to work on
diagrams in real-time.
• [Link]: [Link] is a free, web-based diagramming tool that supports various
diagram types, including UML. It integrates with various cloud storage services and
can be used offline.
• Visual Paradigm: Visual Paradigm provides a comprehensive suite of tools for
software development, including UML diagramming. It offers both online and
desktop versions and supports a wide range of UML diagrams.
• StarUML: StarUML is an open-source UML modeling tool with a user-friendly
interface. It supports the standard UML 2.x diagrams and allows users to customize
and extend its functionality through plugins.

Steps to create UML Diagrams

Creating Unified Modeling Language (UML) diagrams involves a systematic process that
typically includes the following steps:
• Step 1: Identify the Purpose:
Decide on the objective for which the UML diagram is being made. Among the many
applications for the many types of UML diagrams are requirements collection, system
architecture development, and class relationship documentation.
• Step 2: Identify Elements and Relationships:
Choose which crucial elements—classes, objects, use cases, etc.—should be included
in the diagram, along with their relationships.
• Step 3: Select the Appropriate UML Diagram Type:
Select the type of UML diagram that best suits your modeling requirements. Class
diagrams, use case diagrams, sequence diagrams, activity diagrams, and more are
examples of common forms.
• Step 4: Create a Rough Sketch:
A basic sketch on paper or a whiteboard can be useful before utilizing a UML
modeling tool. This can assist you in seeing how the elements are arranged and
related to one another.
• Step 5: Choose a UML Modeling Tool:
Choose a UML modeling tool based on your needs. Numerous offline and online
applications are available with features for making and modifying UML diagrams.
• Step 6: Create the Diagram:
Create a new project or diagram using the UML modeling tool of your choice. Start
by adding components to the diagram, such as actors, classes, and use cases, and then
link them together with the proper relationships, such as dependencies and
associations.
• Step 7: Define Element Properties:
Give each diagram element the appropriate qualities and attributes. Use case specifics,
class characteristics and methods, and any other information unique to the diagram
type may be included.
 • Step 8: Add Annotations and Comments:
By using annotations, remarks, and clarifying notes, you can improve the diagram's
readability.
• Step 9: Validate and Review:
Check the diagram for completeness and accuracy. Make that the elements,
limitations, and linkages appropriately depict the system or process that is intended.
• Step 10: Refine and Iterate:
Refine the diagram based on feedback and additional insights. UML diagrams are
often created iteratively as the understanding of the system evolves.

What is a Use Case Model?

A use case model is a technique used in software development and systems engineering to
describe the functional requirements of a system. It focuses on how a system interacts with
external entities (actors) to achieve specific goals, providing a user-centric perspective of the
system's behavior. This model is essential for understanding and documenting how a system
is supposed to work from the viewpoint of its end users.
Key Components of a Use Case Model
1. Actors: These are external entities (users, systems, or devices) that interact with the
system. For example, in an online shopping system, actors could include customers
and administrators.
2. Use Cases: These represent specific functionalities or processes the system performs
to meet the needs of the actors. For instance, use cases in an online shopping system
might include "Browse Products" or "Checkout."
3. Relationships: These define how actors and use cases interact. Common relationships
include: Association: Links actors to use cases they are involved in. Include: Indicates
that one use case incorporates another for shared functionality. Extend: Adds optional
or conditional behavior to a base use case. Generalization: Represents inheritance
between use cases or actors.
4. System Boundary: A box that defines the scope of the system, distinguishing internal
functionalities (use cases) from external entities (actors).
Purpose and Benefits
A use case model helps to:
• Capture functional requirements: It specifies what the system should do, not how it
should do it.
• Visualize interactions: It provides a clear picture of how users engage with the
system.
• Define system scope: It clarifies what is inside and outside the system's boundaries.
 • Facilitate communication: It bridges the gap between technical teams and non-
technical stakeholders by using simple, intuitive diagrams.
Use Case Diagram
A use case diagram is a graphical representation of the use case model. It uses symbols like
stick figures for actors and ovals for use cases, connected by lines to show interactions. For
example, in a library system, a "Student" actor might interact with the "Borrow Book" use
case.
Example
For a University Library System, a use case model might include:
• Actors: Student, Librarian.
• Use Cases: Borrow Book, Return Book, Search Catalog.
• Relationships: A "Borrow Book" use case might include a "Login" use case for
authentication.
Best Practices
• Focus on what the system does, not how it does it.
• Use clear and consistent naming for actors and use cases.
• Keep diagrams simple and avoid overloading them with details.
• Validate the model with stakeholders to ensure alignment with requirements.
A use case model is a powerful tool for capturing system functionality and ensuring that all
stakeholders have a shared understanding of the system's goals and interactions.

Creation of Classes in OOAD

In Object-Oriented Analysis and Design (OOAD), Creation of Classes refers to the
process of identifying, defining, and modeling classes that represent the real-world entities
of the system.
A class is a conceptual model describing a set of objects that share common attributes,
operations, relationships, and behaviors.
Goal: Convert real-world problem domain elements into classes that form the structure of the
system.

Steps in Class Creation (OOAD Process)

Identify Classes (Object Identification)

• Analyze the problem statement, use cases, and system requirements
 • Find nouns and entities → potential classes
Example (Library System): Book, Student, Librarian, Loan

Define Responsibilities of Each Class

• Determine what the class should know (attributes)
• Determine what the class should do (methods/operations)

Specify Attributes (Data Members)

• These describe the state of a class
Example: bookId, title, author

Specify Methods / Operations

• These describe the behavior or functions of the class
Example: issueBook(), returnBook()

Define Relationships Between Classes

• Determine how classes interact:
o Association
o Aggregation
o Composition
o Inheritance
o Dependency

Represent Classes Using UML Class Diagram

• Class name
• Attributes
• Methods
• Visibility (+ / – / #)

Standard UML Format for a Class

-----------------------------
| Class Name |
-----------------------------
| Attributes (State) |
-----------------------------
| Methods (Behavior) |
-----------------------------

Example of Class Creation (OOAD Context)

Example: Student Class

Responsibilities:
• Store student information
• Provide services like registration and fee payment
• Maintain course enrollment

Class Model (UML Text Form):

+-----------------------------+
| Student |
+-----------------------------+
| -studentId: int |
| -name: string |
| -dob: date |
| -department: string |
+-----------------------------+
| +registerCourse(): void |
| +payFees(): boolean |
| +getProfile(): string |
+-----------------------------+

Guidelines for Good Class Creation

Guideline Description

High cohesion All attributes and methods must relate to one responsibility

Low coupling Minimum dependency between classes

Reusability Class should be reusable in multiple contexts

Encapsulation Data must be protected using visibility rules

 Importance of Class Creation in OOAD

Benefit Explanation

Forms core structure Classes become the building blocks of the system

Improves maintainability System becomes modular and easy to update

Enables reusability Classes can be reused across projects

Supports scalability New classes can be easily added

Final Exam Definition

Creation of Classes in OOAD is the process of identifying and defining classes that
represent real-world objects in the problem domain. It includes specifying attributes,
operations, and relationships, and representing them using UML class diagrams to build
the static structure of an object-oriented system.

Noun Phrase Approach

The Noun Phrase Approach is a popular technique used in Object-Oriented Analysis
(OOA) to identify classes and objects from the problem statement or system requirements.
It is based on the idea that most classes in a system can be discovered by extracting nouns
and noun phrases from textual descriptions (SRS, use cases, user stories, etc.).
Nouns → Potential Classes / Objects
Verbs → Potential Operations / Methods

Purpose of Noun Phrase Approach

Objective Explanation

Identify domain classes Extract objects required in the system

Understand system requirements Converts text requirements into object model

Simplify class creation Helps in designing class diagrams

Steps in Noun Phrase Approach

Read the problem statement / requirements carefully

Example: "The student registers for a course and pays the fee."

Underline / list all nouns and noun phrases

Student, Course, Fee, Registration

Classify nouns into categories

Category Examples

Likely classes Student, Course

Attributes Name, Age, Course Title

Rejected nouns Screen, Report (if not objects)

Remove unnecessary nouns

• UI words → Screen, Window, Button
• Generic words → System, Information
• Duplicates or synonyms → Pupil = Student

Finalize the classes and attributes

• Example:
o Classes: Student, Course, Fee
o Attributes of Student: name, rollNo
o Attributes of Course: courseName, duration

Example

Requirement Statement
"A customer places an order for products and makes payment using a credit card."
Extracted Nouns:
Customer, Order, Product, Payment, Credit Card
After filtering:

Final Classes Attributes

Customer customerId, name

Order orderId, date

Product productId, price

Payment amount, mode

 Advantages of Noun Phrase Approach

Advantage Explanation

Simple and systematic Easy even for beginners

Reduces missing classes Finds potential objects from text

Improves traceability Tracks requirements directly to design

⚠ Limitations

Limitation Reason

Not always accurate Some nouns may not be classes

Needs domain knowledge Analyst must validate extracted nouns

Cannot identify behavior alone Verbs still required for methods

Final Exam Answer (Short Definition)

Noun Phrase Approach is a technique in Object-Oriented Analysis where classes and
objects are identified by extracting nouns and noun phrases from the problem
description. It assumes that nouns represent potential objects while verbs represent
potential operations.

Responsibilities in OOAD
In Object-Oriented Analysis and Design (OOAD), responsibilities refer to the obligations
or duties assigned to a class or object.
They describe what an object knows and what an object does.
Simply: Responsibilities define the purpose and behavior of a class.

Types of Responsibilities
Responsibilities are mainly classified into two categories:

Type Meaning Example

Knowing What the object should store / Student knows name, rollNo,
Responsibilities understand course
Type Meaning Example

Student registers course, pays

Doing Responsibilities Actions the object must perform
fees

Knowing Responsibilities (Knowledge Responsibilities)

These represent information the object maintains or acquires.
Examples:
• Customer knows name, address, phone number
• Book knows title, author, ISBN
• Account knows balance and account number

Doing Responsibilities (Behavioral Responsibilities)

These represent operations that the object performs.
Examples:
• Customer places order
• Book updates availability
• Account deposits and withdraws money

Importance of Responsibilities

Benefit Explanation

Defines class behavior Helps decide which methods belong to the class

Improves cohesion Each class becomes focused on one purpose

Reduces complexity Responsibilities are distributed among classes

Helps in collaboration Objects interact based on responsibilities

Responsibility Assignment
Responsibility assignment occurs during Object-Oriented Design (OOD).
Common guidelines:
• Assign responsibilities to the class that has the information needed to fulfill it
(Information Expert Principle)
 • Avoid giving too many unrelated responsibilities to one class (maintain high
cohesion)
• Avoid dependency on many classes (maintain low coupling)

Example (Student Registration System)

Class Knowing Responsibilities Doing Responsibilities

Student name, rollNo, course registerCourse(), payFees()

Course courseName, duration addStudent(), scheduleExam()

Payment amount, mode processPayment(), generateReceipt()

Key Exam Definition

Responsibilities in OOAD represent the knowledge and actions that an object or class
must maintain and perform. They indicate what a class knows (attributes) and what it
does (methods), helping define the role and behavior of objects within the system.

What is Collaboration?
Collaboration in Object-Oriented Design means objects working together to complete a
task.

A single object cannot finish every responsibility by itself.

So it asks help from other objects.
When two or more objects interact and exchange messages, it is called collaboration.

Key Idea
Collaboration = Objects + Communication + Working together to finish something

Example (Simple Understanding)

Imagine you are ordering food online.

Action Which Objects Collaborate?

Place Order Customer ↔ Order

Pay bill Order ↔ Payment ↔ Bank

Action Which Objects Collaborate?

Update stock Order ↔ Inventory System

So:
• Order object collaborates with Customer, Payment, and Inventory
• Payment collaborates with Bank
None of these objects can complete the full process alone — they depend on
collaboration.

How Collaboration Happens?

It happens through messages.
Customer → createOrder() → Order
Order → makePayment() → Payment
Payment → verify() → Bank
Order → updateStock() → Inventory
Each arrow shows a message, meaning one object is asking another object to do some work.

Where Collaboration is Used in UML?

Collaboration is mainly shown in:

• Sequence Diagram
• Communication (Collaboration) Diagram
These diagrams show:
• Which objects talk to each other
• In what order the communication happens

Real-world Analogy
Imagine a school annual day event:
• Principal plans
• Teachers assign tasks
• Students perform
• Technicians operate sound system
All work together to complete the event ⇒ This is collaboration.

Why Collaboration Is Important?

Benefit Reason

Reusability Objects do single jobs & can be reused

Maintainability Easy to update / fix code

Flexibility System can grow without redesign

Better performance Load shared between multiple objects

✔ One-line definition
Collaboration is the process in which multiple objects communicate and coordinate to
achieve a common responsibility.

Collaborators
Collaborators mean who helps whom inside a system.

In Object-Oriented Design, an object may not do everything by itself.

It may need help from other objects to perform a task.
The objects that help each other are called collaborators.
Example
Consider ordering a product in an online shopping system:

Object Needs Help From Task

Order Customer, Payment, Inventory To place order

Payment Bank To complete payment

Customer Cart To select items

So here:
• Order collaborates with Customer, Payment, and Inventory.
• Payment collaborates with Bank.

Collaboration = Objects working together to complete a function

Relationships
Relationship means how objects or classes are connected.
There are different types of relationships in OOAD:

Relationship Type Meaning Example

Association General connection between two classes Teacher — Student

Aggregation Whole–Part (but part can exist independently) Library ↠ Books

Composition Whole–Part (part cannot exist independently) House → Rooms

Inheritance One class inherits another class Dog inherits Animal

Dependency One class temporarily depends on another Invoice uses Printer

Visual Understanding
Customer ---- places ----> Order → Association
Order ---- contains ----> OrderItem → Aggregation/Composition
Payment ---- processes ----> Bank → Dependency
Dog ---- is-a ----> Animal → Inheritance

Difference Between Collaborators & Relationships

Collaborators Relationships

Focus on objects working together to complete Focus on connection between classes in

actions model

Based on function / behavior Based on structure

Seen in sequence diagrams / collaboration

Seen in class diagrams
diagrams

Dynamic interaction Static connection

Simple Analogy

Concept Real-Life Example

Relationship A doctor and a hospital are connected (doctor works in hospital)

Collaboration The doctor collaborates with a nurse to perform surgery

 What is Super – Sub Class Hierarchy?
A Super–Sub Class Hierarchy represents a parent–child structure of classes formed
through inheritance.

One Super Class (parent)

Multiple Sub Classes (children)
Each Sub Class can again become a Super Class for its own Sub Classes

So the classes form a tree-like structure called Hierarchy.

Example (Real-world)
Living Thing ← Super Class
|
------------------------
| | |
Animal Plant Microorganism ← Sub Classes
|
-----------------------
| | |
Dog Cat Bird ← Sub Sub Classes

“Living Thing” is the top super class

“Animal” is sub class of Living Thing but super class of Dog, Cat, Bird
This chain of inheritance is called Super–Sub Class Hierarchy.

Programming Example
class LivingThing { // Super Class
void grow() {}
}

class Animal extends LivingThing {} // Sub Class

class Dog extends Animal {} // Sub Sub Class

class Cat extends Animal {} // Sub Sub Class
Here:
• LivingThing → Super Class
• Animal → Sub Class of LivingThing
• Dog, Cat → Sub Classes of Animal

Hierarchy Representation in UML

+------------------+
| LivingThing |
+------------------+
^
-----------------------------------------
^ ^ ^
+-------------+ +---------------+ +----------------+
| Animal | | Plant | | Microorganism |
+-------------+ +---------------+ +----------------+
^
------------------------
^ ^ ^
+--------+ +--------+ +--------+
| Dog | | Cat | | Bird |
+--------+ +--------+ +--------+
The arrows point from Sub Class to Super Class (UML standard).

Why Super – Sub Class Hierarchy is Used?

Benefit Reason

Reusability Common features written only once in super class

Extensibility New classes can be added without changing old ones

Reduced redundancy No duplicate code

Clear organization Classes arranged from general → specific

✔ One-line Definition
A Super–Sub Class Hierarchy is a layered arrangement of classes where higher-level
super classes provide general features and lower-level sub classes provide specialized
features through inheritance.

What is Aggregation?
Aggregation is a special type of object relationship where:
One object (whole) contains or is composed of other objects (parts)
But the parts can exist independently, even if the whole is destroyed

It is called a “Has–A relationship”

Simple Understanding
• Class A has Class B
• But Class B can live without Class A
Example:
A University has Colleges.
If the university is closed, the colleges still exist.

UML Representation
Aggregation is represented by a hollow diamond (◊) pointing to the whole.
University ◊─── College
Diamond near University because it is the whole.

Real World Examples

Whole Parts

Library Books

Company Employees

Team Players

Department Staff
Whole Parts

School Teachers

In all these cases, if the whole disappears, the parts still exist.

Small Program Example (Java)

class Book {
String title;
}

class Library { // Aggregation

Book book; // Library has a Book
}

Book can exist without Library

So this is aggregation

Aggregation vs Composition (Important)

Feature Aggregation Composition

Relationship Weak "Has–A" Strong "Part–Of"

Object dependency Parts live independently Parts cannot live without whole

Diamond symbol ◊ (Hollow Diamond) ◆ (Filled Diamond)

Example Library – Books Human – Heart

✔ One-line Definition
Aggregation is a weak form of association where a whole object contains parts, but the
parts can exist independently even if the whole is destroyed.