Unit 3 Notes

Object oriented analysis

1️⃣ Introduction to OOA

●​ Definition:​
Object-Oriented Analysis (OOA) is the process of analyzing a problem domain to
identify objects, classes, and their relationships, focusing on what the system
should do instead of how it will do it.​

●​ Key Idea:​
Represent the problem using real-world objects → classes, attributes, and
behaviors.​

2️⃣ Objectives of OOA

✔ Understand the system requirements.​
✔ Identify real-world objects & classes.​
✔ Define relationships between classes.​
✔ Build UML models for better visualization.​
✔ Prepare input for Object-Oriented Design (OOD).

3️⃣ Steps of Object-Oriented Analysis

Step 1: Understand the Problem Domain

●​ Gather requirements.​

●​ Example: Library Management System.​

Step 2: Identify Actors and Use Cases

●​ Actors: Entities interacting with the system (User, Librarian).​

●​ Use Cases: Functions the system must perform (Borrow Book, Return Book).​
🔹 UML Use Case Diagram Example (Library System):
[Member] ----> (Borrow Book)
[Member] ----> (Return Book)
[Librarian] ----> (Add Book)
[Librarian] ----> (Remove Book)

Step 3: Identify Objects and Classes

●​ Convert nouns → objects.​

●​ Example: Book, Member, Librarian, Loan.​

Step 4: Identify Attributes and Methods

●​ Example:​

○​ Book → title, author, ISBN | issueBook()​

○​ Member → name, ID | borrowBook()​

○​ Librarian → staffID | manageBook()​

Step 5: Define Relationships

●​ Types: Association, Aggregation, Inheritance, Dependency.​

🔹 UML Class Diagram Example:

+------------------+ +------------------+
| Member | | Book |
|------------------| |------------------|
| name | | title |
| memberID | | author |
|------------------| | ISBN |
| borrowBook() | | issueBook() |
| returnBook() | | returnBook() |
+------------------+ +------------------+
| ^
| |
 | +------------------+
| | Librarian |
| |------------------|
| | staffID |
| |------------------|
| | manageBook() |
| +------------------+

Step 6: Model Interactions

●​ Represent how objects collaborate.​

🔹 UML Sequence Diagram (Borrow Book):

Member ---> Librarian: Request Book
Librarian ---> Book: Check Availability
Book ---> Librarian: Availability Status
Librarian ---> Member: Issue Book Confirmation

Step 7: Validate the Model

●​ Cross-check requirements with diagrams.​

●​ Ensure no function/relationship is missing.​

4️⃣ Deliverables of OOA

●​ Use Case Model → System functions.​

●​ Class Diagram → Objects, attributes, and relationships.​

●​ Interaction Diagrams → Object collaborations.​

●​ Glossary of Objects → Complete object list with attributes & methods.​

5️⃣ Example Recap: Library Management System

 1.​ Actors: Member, Librarian.​

2.​ Use Cases: Borrow Book, Return Book, Add Book, Remove Book.​

3.​ Classes: Book, Member, Librarian, Loan.​

4.​ Relationships: Member borrows Book, Librarian manages Book.​

5.​ UML Models: Use Case, Class Diagram, Sequence Diagram.​

Object-Oriented Design (OOD)

1️⃣ Introduction
●​ Definition:​
Object-Oriented Design (OOD) is the process of transforming the analysis model
(OOA) into a design model that can be directly implemented in a programming
language.​

👉 In short:
●​ OOA = What the system should do​

●​ OOD = How the system will do it​

OOD focuses on defining the software architecture, detailed class structures, methods,
and relationships for implementation.

2️⃣ Objectives of OOD

✔ Convert analysis objects → design-level classes.​
✔ Specify data types, method signatures, algorithms.​
✔ Define how objects interact (design patterns, responsibilities).​
✔ Optimize design for performance, maintainability, and scalability.​
✔ Prepare for coding in languages like Java, C++, Python.
3️⃣ Key Concepts in OOD
1.​ Classes & Objects – Refined from analysis, now with data types & detailed
operations.​

2.​ Relationships – Association, Aggregation, Inheritance, Composition.​

3.​ Design Principles – Encapsulation, Abstraction, Modularity, Reusability.​

4.​ Design Patterns – Singleton, Factory, Observer, MVC, etc.​

5.​ Physical Packaging – Mapping classes into modules/packages.​

6.​ Optimization – Improving algorithms and structure.​

4️⃣ Steps in Object-Oriented Design

Step 1: Refine Classes and Objects

●​ Add detailed attributes (with data types) and methods (with signatures).​

Example:​
​
class Book {
string title;
string author;
string ISBN;
bool available;
public:
void issueBook(Member m);
void returnBook(Member m);
};

●​

Step 2: Define Relationships

●​ Inheritance: Generalization / Specialization.​

●​ Aggregation/Composition: Whole-Part relationships.​

 ●​ Association: Simple link between classes.​

Step 3: Design Class Diagrams (Detailed)

●​ Include methods, attributes, visibility (+ public, - private, # protected).​

🔹 Example (Library System Class Diagram – Design Level):

+---------------------+
| Book |
|---------------------|
| - title: string |
| - author: string |
| - ISBN: string |
| - available: bool |
|---------------------|
| + issueBook(m:Member): void |
| + returnBook(m:Member): void|
+---------------------+

+---------------------+
| Member |
|---------------------|
| - name: string |
| - memberID: int |
|---------------------|
| + borrowBook(b:Book): void |
| + returnBook(b:Book): void |
+---------------------+

Step 4: Model Interactions

●​ Use Sequence Diagrams and Collaboration Diagrams to show object interactions.​

Example (Borrow Book Sequence):

Member → Librarian: requestBook(Book)

Librarian → Book: checkAvailability()
Book → Librarian: availability
Librarian → Member: confirmIssue()
Step 5: Apply Design Patterns

●​ Example: Singleton for Database Connection.​

●​ Example: Factory for creating Book objects.​

Step 6: Physical Packaging

●​ Group classes into modules/packages.​

●​ Example:​

○​ entities → Book, Member, Librarian.​

○​ services → LoanService, NotificationService.​

5️⃣ Deliverables of OOD

●​ Detailed Class Diagram (with data types, visibility).​

●​ Sequence & Collaboration Diagrams (interactions).​

●​ State Diagrams (object lifecycle).​

●​ Package Diagram (modular structure).​

●​ Design Patterns Used.​

6️⃣ Example Recap (Library System – OOD)

●​ Analysis (OOA) gave us Book, Member, Librarian, Loan.​

●​ In OOD we refine them into detailed classes with attributes, methods, and
interactions.​

●​ We design class diagrams, sequence diagrams, and package diagrams.​

●​ Ready for coding in C++/Java/Python.

Combining Three Models in OOAD

1️⃣ Introduction
In OOAD, three different models are created during Object-Oriented Analysis (OOA) to
understand the system from different perspectives.​
But since each model only shows a partial view of the system, we need to combine them
into one unified model before moving to Object-Oriented Design (OOD).

👉 This process is called Combining Three Models.

2️⃣ The Three Models

1.​ Object Model (Static View)​

○​ Describes the structure of the system.​

○​ Shows objects, classes, attributes, and relationships.​

○​ Represented by Class Diagrams, Object Diagrams.​

2.​ 🔹 Example: Book, Member, Librarian classes in Library System.​

2.​ Dynamic Model (Behavioral View)​

○​ Describes the behavior of the system over time.​

○​ Shows interactions, states, events, and transitions.​

○​ Represented by Sequence Diagrams, State Diagrams, Activity Diagrams.​

3.​ 🔹 Example: Borrow Book → (Available → Issued → Returned).​

 3.​ Functional Model (Data Flow View)​

○​ Describes what the system does (functions).​

○​ Shows data flow, inputs, outputs, and transformations.​

○​ Represented by Use Case Diagrams, Data Flow Diagrams (DFD).​

4.​ 🔹 Example: Member → Borrow Book → Update Loan Record.​

3️⃣ Why Combine the Models?

●​ Each model gives different information:​

○​ Object model → What objects exist.​

○​ Dynamic model → How they behave.​

○​ Functional model → What functions/data flow exists.​

●​ If they are not combined:​

○​ System design becomes inconsistent.​

○​ Requirements may be missed.​

✅ By combining them → we get a complete, consistent, unified view of the system.

4️⃣ Process of Combining the Models

1.​ Link Functional Model to Object Model​

○​ Functions (from use cases/DFD) are mapped to the objects that perform
them.​

2.​ 🔹 Example: Borrow Book function → handled by Member and Book objects.​
 2.​ Link Dynamic Model to Object Model​

○​ States and events (from state diagrams/sequence diagrams) are mapped to

classes and their methods.​

3.​ 🔹 Example:​
○​ Book class has states: Available → Issued → Returned.​

○​ Methods issueBook(), returnBook() handle transitions.​

3.​ Integrate All Models​

○​ Final model ensures:​

■​ Objects (static) exist for all functions (functional).​

■​ Events and state changes (dynamic) are linked to object

operations.​

5️⃣ Example (Library Management System)

Object Model

●​ Classes: Book, Member, Librarian.​

Dynamic Model

●​ Book: [Available → Issued → Returned].​

Functional Model

●​ Functions: Borrow Book, Return Book.​

Combined View

●​ Borrow Book function → Member interacts with Book.​

 ●​ Book state changes → Available → Issued.​

●​ Methods issueBook() and returnBook() connect function ↔ object ↔ state.​

6️⃣ Diagram Representation

✅ Typically shown as integrated UML diagrams:
●​ Use Case Diagram → linked with Classes.​

●​ Class Diagram → shows objects + methods.​

●​ State/Sequence Diagram → shows how methods change object states.​

7️⃣ Summary
●​ Object Model → Structure (What objects exist).​

●​ Dynamic Model → Behavior (How they change).​

●​ Functional Model → Functions (What system does).​

●​ Combining Three Models = Integrating these views into a single, consistent

design model → foundation for OOD & implementation.

Designing Algorithms in OOAD

1️⃣ Introduction
●​ Definition:​
Designing algorithms in OOAD means defining the step-by-step procedures
(logic) that the system’s methods (behaviors of objects) will follow to perform
their tasks.​

👉 It answers how each operation of a class will work internally.

2️⃣ Why Algorithms in OOAD?
●​ Objects in OOD have methods (functions).​

●​ To implement these methods, we need algorithms.​

●​ Algorithms describe control flow, decision-making, iteration, and data

handling.​

●​ Ensures the system is not just structurally designed but also functionally
complete.​

3️⃣ Characteristics of Good Algorithms in OOAD

✔ Correctness → Must solve the given problem correctly.​
✔ Efficiency → Optimized for time & space complexity.​
✔ Clarity → Easy to understand and implement.​
✔ Modularity → Divided into reusable methods.​
✔ Scalability → Should work even if the system grows.

4️⃣ Steps of Designing Algorithms in OOAD

1.​ Identify the operation (method in class).​

○​ Example: borrowBook() in Member class.​

2.​ Define input and output.​

○​ Input: Book, Member ID.​

○​ Output: Success/failure message.​

3.​ Break down into steps (logic).​

○​ Check if Book is available.​

○​ If available → assign to Member & update status.​

 ○​ Else → notify unavailable.​

4.​ Represent Algorithm.​

○​ Pseudocode​

○​ Flowchart / UML Activity Diagram​

5️⃣ Example – Algorithm in OOAD

Problem: Borrow a Book (Library System)

Class: Member​
Method: borrowBook(Book b)

🔹 Pseudocode:
Algorithm BorrowBook(Member m, Book b)

1. If [Link] = true then

2. Assign b to m

3. Set [Link] = false

4. Print "Book issued successfully."

5. Else

6. Print "Book not available."

7. End If

🔹 UML Activity Diagram (Algorithm Representation):

[Start]

Check availability of Book

|
 /------\

| Yes |----> Assign Book to Member → Update Status → "Issued Successfully"

| No |----> "Book Not Available"

\------/

[End]

6️⃣ Role of Algorithm Design in OOAD

●​ Bridge between Design and Implementation.​

●​ Helps developers know exactly how each method will work.​

●​ Supports documentation and clarity.​

●​ Ensures that objects not only exist but also function correctly.

Design Optimization in OOAD

1️⃣ Definition
Design Optimization is the process of improving the object-oriented design model by
restructuring classes, relationships, and interactions to achieve better performance,
flexibility, and maintainability without changing the system’s functionality.

👉 In short: It’s about making the design simpler, faster, and more efficient.

2️⃣ Objectives of Design Optimization

✔ Reduce unnecessary complexity in design.​
✔ Optimize use of objects, classes, and relationships.​
✔ Improve performance (speed, memory usage).​
✔ Increase reusability of components.​
✔ Make design adaptable to future changes.

3️⃣ Techniques in Design Optimization

🔹 1. Refining Inheritance and Generalization
●​ Avoid deep inheritance hierarchies.​

●​ Replace inappropriate inheritance with composition.​

●​ Example: Instead of Car → ElectricCar → Tesla → Model3, use Car with a

PowerSource composition.​

🔹 2. Optimizing Associations
●​ Use aggregation or composition only where necessary.​

●​ Avoid unnecessary many-to-many relationships.​

🔹 3. Encapsulation & Information Hiding

●​ Keep data members private.​

●​ Expose only necessary operations through public methods.​

🔹 4. Reducing Redundancy
●​ Identify duplicate attributes/methods → move them to a common superclass.​

●​ Example: Student and Teacher both have name, address → move to

Person.​
🔹 5. Optimizing Algorithms and Methods
●​ Replace inefficient algorithms with better ones.​

●​ Example: Instead of linear search, use hashing or indexing.​

🔹 6. Applying Design Patterns

●​ Use proven solutions (patterns) to recurring design problems.​

●​ Example:​

○​ Singleton → For shared database connection.​

○​ Factory Method → For object creation.​

○​ Observer → For event handling.​

🔹 7. Packaging & Modularity

●​ Group related classes into packages/modules.​

●​ Increase reusability and reduce dependency.​

🔹 8. Performance Considerations
●​ Reduce object creation overhead (use object pooling).​

●​ Minimize unnecessary relationships.​

●​ Use lazy initialization when appropriate.​

4️⃣ Example – Library System (Design Optimization)

Before Optimization:
 ●​ Book and Magazine both had title, author, ISBN.​

●​ Multiple associations between Member and Book.​

After Optimization:

●​ Create a superclass Publication → Book and Magazine inherit it.​

●​ Simplify relationship: Member → Loan → Book (instead of Member directly

linked to Book).​

●​ Use Factory pattern for creating Book/Magazine objects.​

5️⃣ Deliverables of Design Optimization

●​ Optimized Class Diagram (cleaner hierarchy, reduced redundancy).​

●​ Optimized Package Diagram (better modularity).​

●​ Clear application of design principles (SOLID).​

●​ Applied design patterns where needed.

Implementation of Control in OOAD

1️⃣ Meaning
Implementation of Control in OOAD refers to how the flow of execution,
decision-making, and coordination among objects is handled during the system’s
operation.

●​ It answers:​

○​ Which object controls the interaction?​

○​ Who initiates actions?​

 ○​ How are decisions (conditions, loops, exceptions) handled in
object-oriented systems?​

👉 In procedural systems, control is centralized (main function, procedures).​

👉 In object-oriented systems, control is distributed among collaborating objects.

2️⃣ Objectives of Control Implementation

✔ Define how the system’s operations are sequenced.​
✔ Assign responsibility of control to specific objects.​
✔ Handle conditions, loops, and exceptions.​
✔ Support concurrency and synchronization (if multiple processes run).​
✔ Ensure the system behaves as per requirements.

3️⃣ Approaches to Control in OOAD

1.​ Centralized Control​

○​ A single controller object (or class) manages the flow.​

○​ Example: A Controller class in MVC that directs requests.​

2.​ Decentralized (Distributed) Control​

○​ Each object is responsible for controlling its own behavior and

interactions.​

○​ Example: In a Library System, Member object initiates borrowBook(),

Book object checks availability, Librarian finalizes issue.​

4️⃣ Control Mechanisms in OOAD

●​ Message Passing: Objects communicate using messages (method calls).​

●​ State Machines: Objects change states (UML State Diagrams).​

●​ Event Handling: External/internal events trigger control flow.​

 ●​ Concurrency Control: Synchronization between threads/objects.​

●​ Exception Handling: Managing unexpected conditions gracefully.​

5️⃣ Example: Library Management System

Scenario: Borrowing a Book

🔹 Control Flow (Sequence Diagram):

Member → Librarian: requestBook(Book)

Librarian → Book: checkAvailability()

Book → Librarian: availability (true/false)

IF available THEN

Librarian → Loan: createLoan(Member, Book)

Loan → Book: markAsIssued()

Librarian → Member: confirmIssue()

ELSE

Librarian → Member: notifyUnavailable()

Here:

●​ Control is partly centralized in the Librarian (acts as a controller).​

●​ Book controls its own state (available or not).​

●​ Loan manages transaction consistency.​

6️⃣ UML Representation

●​ Sequence Diagram → Shows control transfer between objects.​
 ●​ State Diagram → Shows how objects change states under control events.​

●​ Activity Diagram → Shows decision-making, loops, and concurrency.​

7️⃣ Summary
✅ Implementation of Control in OOAD is about defining how control is passed
between objects, how execution flow is handled, and how the system ensures correct
sequencing, state management, and event handling.

●​ In OOA → identify control requirements (use cases, events).​

●​ In OOD → design controllers, methods, and patterns to handle control.​

●​ In Implementation → code actual control logic using loops, conditions,

exceptions, event-handlers, threads.​

Adjustment of Inheritance in OOAD

🔹 Definition
Adjustment of Inheritance is the process of refining and optimizing inheritance
hierarchies during the design phase of OOAD.

👉 In simple words:​
When we create classes and apply inheritance (generalization/specialization),
sometimes the initial hierarchy from analysis is not efficient or not accurate. During
design, we “adjust” it to:

●​ Remove unnecessary inheritance.​

●​ Avoid incorrect hierarchies.​

●​ Shift common features to the right superclass.​

●​ Prevent deep or redundant inheritance chains.​

 ●​ Replace inheritance with composition (if better).​

🔹 Why Adjustment is Needed?

1.​ In OOA, we model the system conceptually (what classes exist).​

2.​ In OOD, we refine them for implementation (how they will work).​

3.​ Sometimes, the inheritance chosen in analysis is not optimal for coding.​

○​ Example: Wrong placement of attributes/methods.​

○​ Example: Multiple inheritance causing conflicts.​

🔹 How Adjustment of Inheritance Works

1.​ Identify Common Features​

○​ Move shared attributes/methods to the superclass.​

2.​ Check Specialization​

○​ Ensure subclasses only add specialized behavior.​

3.​ Avoid Redundancy​

○​ Prevent same attributes/methods in multiple subclasses.​

4.​ Balance Depth of Hierarchy​

○​ Too deep → complex.​

○​ Too shallow → no reuse.​

5.​ Replace Inheritance with Composition (if needed)​

○​ "Has-a" (composition) may be better than "is-a" (inheritance).​

🔹 Example
Initial Analysis Model (OOA):

Vehicle

├── Car

├── Truck

└── Bike

But suppose both Car and Truck share "Engine" details, but "Bike" does not.

Problem:

If we keep "Engine" in Vehicle, Bike unnecessarily gets it.

Adjustment in OOD:

Vehicle

├── Car

└── Truck

Bike

Engine (separate class, used via Composition)

👉 Here, inheritance was adjusted by:

●​ Removing "Engine" from Vehicle.​

●​ Making Engine a composition (has-a) for Car & Truck.​

🔹 UML Illustration
Before Adjustment (Wrong)

+-----------------+

| Vehicle |

|-----------------|

| engineDetails |

|-----------------|

| startEngine() |

+-----------------+

^ ^ ^

| | |

Car Truck Bike (Problem: Bike also has engineDetails unnecessarily)

After Adjustment (Correct)

+-----------------+ +-----------------+

| Vehicle | | Engine |

|-----------------| |-----------------|

| type, wheels |<>--------| engineDetails |

+-----------------+ has-a | startEngine() |

^ ^ +-----------------+

| |

Car Truck Bike (without Engine)

🔹 Benefits of Adjustment of Inheritance

✔ Corrects analysis mistakes.​
✔ Improves reusability and maintainability.​
✔ Prevents redundancy.​
✔ Makes hierarchy logical and efficient.​
✔ Prepares system for implementation in OOP languages.

✅ In short:​
Adjustment of Inheritance in OOAD means refining inheritance hierarchies during
design to remove redundancy, fix misplacements, and choose between inheritance
and composition for an efficient, correct design.

Object Representation in OOAD

1️⃣ Introduction
●​ Definition:​
Object Representation is the way an object’s data (attributes) and behavior
(methods) are represented internally in a system so that it can be stored,
accessed, and manipulated efficiently.​

●​ Simply put:​
​
​
It’s how objects exist in memory or storage and how they are linked to other
objects.​
​

●​ Focus: Internal structure of objects and their relationships.​

2️⃣ Key Concepts

1.​ Attributes​

○​ Represent the state/data of an object.​

○​ Example: Book object → title, author, ISBN, available.​

 2.​ Methods (Operations)​

○​ Represent the behavior of an object.​

○​ Example: issueBook(), returnBook().​

3.​ Object Identity​

○​ Every object has a unique identity, independent of its attribute values.​

○​ Example: Two books with the same title and author are different objects.​

4.​ Relationships / References​

○​ Objects can refer to other objects using pointers, references, or IDs.​

○​ Example: Member object has a reference to Book objects it borrowed.​

3️⃣ Forms of Object Representation

1.​ Attributes Representation​

○​ Using variables (primitive or complex).​

Example in C++:​
​
class Book {

string title;

string author;

string ISBN;

bool available;

};

○​
2.​ Methods Representation​

○​ Using functions tied to the object.​

Example:​
​
void issueBook(Member m);

void returnBook(Member m);

○​
3.​ Reference Representation​

○​ Object stores references/IDs to related objects.​

Example:​
​
class Member {

Book* borrowedBooks[5]; // Array of references to borrowed Book objects

};

○​
4.​ Physical Representation (Memory Layout)​

○​ Objects can be stored as:​

■​ Stack (temporary objects)​

■​ Heap (dynamic objects)​

■​ Database entries (for persistent objects)​

4️⃣ UML Representation of Objects

●​ UML can show objects with attributes and current values.​

●​ Example: Object Diagram for a Library System​

+-----------------------------+

| Book: b1 |

|-----------------------------|

| title = "C++ Basics" |

| author = "John Smith" |

| ISBN = "12345" |

| available = true |

+-----------------------------+

+-----------------------------+

| Member: m1 |

|-----------------------------|

| name = "Alice" |

| memberID = 101 |

| borrowedBooks = [b1] |

+-----------------------------+

5️⃣ Purpose of Object Representation

●​ To store objects efficiently.​

●​ To access and manipulate object data easily.​

●​ To maintain object identity and relationships.​

●​ To provide a basis for design, implementation, and persistence.​

✅ In short:​
Object Representation = How an object’s attributes, methods, identity, and
relationships are stored and represented in a system (memory, database, or model)
for effective access and manipulation.
Physical Packaging in OOAD

1️⃣ Definition
Physical Packaging in OOAD is the process of organizing and grouping design
classes, interfaces, and components into physical modules or packages so that they
can be implemented, compiled, and deployed efficiently.

👉 In simple words:​
It means arranging the classes and objects (designed in OOD) into files, folders,
packages, and libraries that can be managed easily in the real software system.

2️⃣ Why Physical Packaging?

●​ To manage complexity in large systems.​

●​ To improve modularity (divide system into manageable parts).​

●​ To enable team development (different developers can work on different

modules).​

●​ To improve reusability (reuse packages in other projects).​

●​ To simplify deployment & maintenance.​

3️⃣ How It Works

During design, we identify logical packages.​
During physical packaging, we map these into implementation-level entities.

●​ In Java → packages (e.g., [Link]).​

●​ In C++ → namespaces, header files, and libraries.​

●​ In Python → modules and packages (.py files inside directories).​

4️⃣ Example – Library Management System
Logical Classes (from OOD):

●​ Book, Member, Librarian, Loan, NotificationService.​

Physical Packaging:

library-system/

├── entities/

│ ├── [Link]

│ ├── [Link]

│ ├── [Link]

├── services/

│ ├── [Link]

│ ├── [Link]

├── ui/

│ ├── [Link]

└── database/

├── [Link]

Here:

●​ entities package → core objects.​

 ●​ services package → business logic.​

●​ ui package → user interface.​

●​ database package → persistence logic.​

5️⃣ UML Representation (Package Diagram)

🔹 Package Diagram Example
+------------------+ +-------------------+

| entities | | services |

|------------------| |-------------------|

| Book | | LoanService |

| Member | | NotificationService|

| Librarian | +-------------------+

+------------------+

| |

| uses | uses

v v

+------------------+ +-------------------+

| ui | | database |

| MainUI | | DBConnection |

+------------------+ +-------------------+

6️⃣ Benefits of Physical Packaging

✔ Clear structure of the software.​
✔ Easier navigation & debugging.​
✔ Supports parallel development.​
✔ Makes the system portable & maintainable.​
✔ Encourages reuse of components.

✅ In summary:​
Physical Packaging = The step in OOAD where we organize design classes and
components into physical modules/packages (like Java packages, Python modules,
or C++ libraries) to prepare the system for implementation and deployment.

Documenting Design Considerations in

OOAD

1️⃣ Introduction
When we move from Object-Oriented Analysis (OOA) to Object-Oriented Design
(OOD), we don’t just draw class diagrams or sequence diagrams.​
We also need to document important design decisions and rationales so that:

●​ Developers understand the choices made.​

●​ Future maintainers can easily modify or extend the system.​

●​ Stakeholders know why a particular design approach was selected.​

👉 This process is called Documenting Design Considerations.

2️⃣ Definition
Documenting Design Considerations is the practice of recording the important
decisions, assumptions, constraints, trade-offs, and design alternatives that influence
the system architecture and detailed design.

It ensures that the design is traceable, justifiable, and maintainable.

3️⃣ Why Document Design Considerations?
✔ To communicate design decisions clearly.​
✔ To maintain consistency across modules.​
✔ To provide rationale for future changes.​
✔ To handle constraints (performance, scalability, security).​
✔ To help in reviewing and validating the design.

4️⃣ What to Document?

When documenting design considerations, usually the following aspects are
included:

1.​ Design Goals & Constraints​

○​ Performance requirements (fast response, memory usage).​

○​ Security needs (authentication, encryption).​

○​ Scalability & reliability.​

2.​ Architectural Decisions​

○​ Choice of design patterns (e.g., MVC, Singleton).​

○​ Client-server vs layered architecture.​

3.​ Class-Level Design Details​

○​ Why a class was created.​

○​ Inheritance vs composition choices.​

○​ Visibility of methods (+ public, - private).​

4.​ Relationship Considerations​

○​ Why aggregation instead of inheritance?​

○​ Multiplicity (1..*, 0..1, etc.).​

5.​ Trade-offs & Alternatives​

○​ Example: Using an array vs linked list for storage.​

 ○​ Document why one was chosen over the other.​

6.​ Interface & Interaction Decisions​

○​ APIs exposed.​

○​ Message passing between objects.​

7.​ Error Handling & Exceptions​

○​ How errors will be handled gracefully.​

8.​ Documentation with UML Diagrams + Notes​

○​ UML diagrams with explanatory notes in design documents.​

5️⃣ Example (Library Management System)

Suppose we are designing a Library System:

●​ Design Consideration #1:​

Why use inheritance?​

○​ Librarian is a special type of Member → Use inheritance.​

●​ Design Consideration #2:​

Why Singleton Pattern for Database?​

○​ Only one database connection should exist → Singleton ensures

controlled access.​

●​ Design Consideration #3:​

Why use composition for Loan class?​

○​ A Loan cannot exist without Book and Member → Strong composition.​

●​ Design Consideration #4:​

Why use HashMap for storing Books?​

○​ Fast search by ISBN → Better than array for lookup performance.​

📖 These justifications are documented so anyone maintaining the system

understands why choices were made.
6️⃣ Ways to Document
●​ Design Document (SRS/SDD): A written report with decisions, diagrams, and
rationales.​

●​ UML Diagrams with Notes: Adding explanatory text.​

●​ Design Rationale Tables: Tables listing decisions, alternatives, and reasons.​

●​ Inline Code Documentation: Comments linking design choices to

implementation.​

✅ In summary:​
Documenting Design Considerations in OOAD = Writing down the design goals,
constraints, decisions, trade-offs, and justifications behind the design models,
usually supported by UML diagrams and notes.

Structured Analysis and Structured

Design (SA/SD)

1️⃣ Introduction
Before object-oriented methods, the traditional approach for software development
was Structured Analysis and Structured Design (SA/SD).

●​ SA (Structured Analysis): Focuses on understanding the system requirements

using a functional approach.​

●​ SD (Structured Design): Focuses on how to implement those requirements

using modules and hierarchical structure.​

👉 Unlike OOA/OOD (which deal with objects), SA/SD deals with functions, processes,
and data flow.
2️⃣ Structured Analysis (SA)
●​ Definition:​
Structured Analysis is a requirement analysis technique that represents the
system as a set of functions (processes) and data flows.​

●​ Key Tools Used in SA:​

1.​ DFD (Data Flow Diagram): Shows how data moves in the system.​

2.​ ERD (Entity Relationship Diagram): Shows entities and their

relationships.​

3.​ Data Dictionary: Describes data elements.​

4.​ Decision Tables / Trees: Represent conditions and actions.​

●​ Goal of SA:​
Clearly understand what the system should do in terms of processes and data.​

🔹 Example (Library System – SA):

●​ Processes: Borrow Book, Return Book, Add Book.​

●​ Data Stores: Book Database, Member Database.​

●​ Data Flow: Member → Request → Librarian → Update Book Record.​

📌 DFD Example (Level-0 – Library System):

[Member] → (Borrow Book) → [Book Database]

[Member] → (Return Book) → [Book Database]

[Librarian] → (Update Book) → [Book Database]

3️⃣ Structured Design (SD)

●​ Definition:​
Structured Design is the process of converting the results of Structured
Analysis into a blueprint for implementation, focusing on modularity and
 hierarchy.​

●​ Key Principles of SD:​

○​ Modularity: Break the system into small modules.​

○​ Cohesion: Each module should perform a single task.​

○​ Coupling: Minimize interdependencies between modules.​

○​ Top-Down Design: Start from the main system and break it into
submodules.​

●​ Design Representation Tools:​

○​ Structure Charts (like hierarchical block diagrams).​

○​ Module Specifications.​

🔹 Example (Library System – SD):

Top Module: Library Management System

●​ Submodule 1: Book Management​

○​ Add Book​

○​ Delete Book​

●​ Submodule 2: Member Management​

○​ Register Member​

○​ Update Member​

●​ Submodule 3: Loan Management​

○​ Issue Book​

○​ Return Book​

📌 Structure Chart Example (Library System):

Library Management System

├── Book Management

 │ ├── Add Book

│ └── Delete Book

├── Member Management

│ ├── Register Member

│ └── Update Member

└── Loan Management

├── Issue Book

└── Return Book

4️⃣ Comparison of SA vs SD

Aspect Structured Analysis (SA) Structured Design (SD)

Focus What the system should do How the system will be

implemented

Representati DFDs, ERDs, Data Structure Charts, Module Specs

on Dictionary

Approach Functional / Modular, top-down hierarchy

Process-oriented

Output Analysis Model Design Model (blueprint for

(requirements) coding)

5️⃣ Relation with OOAD

 ●​ SA/SD = Old Traditional Approach (Functional).​

●​ OOAD = Modern Approach (Object-Oriented).​

👉 In your syllabus, SA/SD is taught so you can compare it with OOA/OOD.

✅ In summary:
●​ Structured Analysis (SA): A functional way to analyze system requirements
using DFD, ERD, Data Dictionary.​

●​ Structured Design (SD): Converts SA into a modular, top-down design using

Structure Charts and Modules.​

📘 Jackson Structured Development

(JSD)

1️⃣ Introduction
●​ Definition:​
Jackson Structured Development (JSD) is a system development methodology
proposed by Michael A. Jackson in the early 1980s.​
It is a process-oriented and data-driven approach to software development.​

●​ Goal:​
To design and implement software systems by modeling the real-world
entities, their life cycles, and data transformations systematically.​

2️⃣ Key Characteristics of JSD

✔ Based on structured methods → clear, step-by-step development.​
✔ Focuses on processes (functions) and data streams.​
✔ Supports parallel development – analysis, design, and implementation can
overlap.​
✔ Strong emphasis on modeling real-world entities and their life cycles.​
✔ Produces models → networks → software structures → implementations.

3️⃣ Phases of JSD

JSD follows three main stages:

🔹 Stage 1: Modeling the Real World

●​ Identify real-world entities (objects).​

●​ Define their life cycles (sequence of events/changes over time).​

●​ Create entity structure diagrams.​

Example (Library System):

●​ Entity: Book → Life cycle: Created → Issued → Returned → Disposed.​

●​ Entity: Member → Life cycle: Register → Borrow → Return → Cancel.​

🔹 Stage 2: Modeling the System Functions

●​ Define what the system must do with entities.​

●​ Use process structure diagrams (PSDs) to represent processes.​

●​ Show data streams between processes and entities.​

Example:

●​ Process: Borrow Book → Input: Member request + Book available → Output:

Loan record.​

🔹 Stage 3: System Implementation

●​ Map system functions into software modules.​
 ●​ Define data stores, control mechanisms, and timing aspects.​

●​ Refine into program structure.​

4️⃣ JSD Modeling Tools

1.​ Entity Structure Diagram (ESD):​

○​ Shows real-world entities and their life cycles.​

2.​ Process Structure Diagram (PSD):​

○​ Represents system functions and processes.​

3.​ System Network Diagram (SND):​

○​ Shows processes, entities, and data streams as a complete system.​

5️⃣ Example (Library Management – JSD)

●​ Entities: Book, Member, Loan.​

●​ Book Life Cycle: Added → Borrowed → Returned → Removed.​

●​ Processes:​

○​ Add Book, Borrow Book, Return Book, Remove Book.​

●​ System Model:​

○​ Borrow Book Process (Input: Member ID + Book ID → Output: Loan

Record).​

○​ Return Book Process (Input: Book ID → Output: Update Availability).​

6️⃣ Advantages of JSD

✔ Clear methodology – stepwise approach.​
✔ Strong link between real-world entities and system design.​
✔ Useful for real-time systems (airline booking, banking, libraries).​
✔ Can be partially automated.

7️⃣ Disadvantages of JSD

✘ More process-oriented than object-oriented.​
✘ Complex for very large systems.​
✘ Not as flexible as modern OOAD methods (UML, Agile, etc.).

8️⃣ Relation to OOAD

●​ JSD is structured and function-oriented, similar to SA/SD.​

●​ OOAD is object-oriented, focuses on encapsulation, inheritance, and

polymorphism.​

●​ JSD is taught in OOAD courses for historical comparison (to understand the
shift from functional → object-oriented approaches).​

✅ In summary:​
Jackson Structured Development (JSD) is a structured software methodology that
models real-world entities, their life cycles, and processes, then maps them into
system functions and software modules. It bridges real-world modeling with system
implementation in a systematic way.

📘 Mapping Object-Oriented Concepts

Using Non-Object-Oriented Languages

1️⃣ Introduction
 ●​ Object-Oriented Concepts: Objects, Classes, Inheritance, Polymorphism,
Encapsulation, Message Passing.​

●​ Non-Object-Oriented Languages: C, Pascal, Fortran, etc., which are procedural

in nature and lack built-in OOP features.​

👉 The idea is:​

Even if a language is not object-oriented, programmers can simulate OOP concepts
using available constructs (like struct, function pointers, modules, etc.).

2️⃣ Why Mapping is Needed?

●​ Many legacy systems were written in non-OOP languages.​

●​ OOP principles can still be applied for modularity, reusability, and

maintainability.​

●​ Helps migrate systems to OOP languages later.​

3️⃣ Mapping of Key OOP Concepts

🔹 1. Classes and Objects
●​ OOP Concept: Class = blueprint, Object = instance.​

●​ Mapping in C (non-OOP):​

○​ Use struct to represent class attributes.​

○​ Use functions to represent class methods.​

✅ Example (Book class in C):

#include <stdio.h>

#include <string.h>

struct Book {
 char title[50];

char author[50];

};

// Function to act like a method

void printBook(struct Book b) {

printf("Title: %s, Author: %s\n", [Link], [Link]);

int main() {

struct Book b1;

strcpy([Link], "OOP Concepts");

strcpy([Link], "Oxford Manik");

printBook(b1); // behaves like [Link]()

return 0;

🔹 2. Encapsulation
●​ OOP Concept: Binding data + methods, restricting direct access.​

●​ Mapping in C:​

○​ Use struct (data) + related functions.​

○​ Use static keyword to hide data/functions within a module (file-level

encapsulation).​
🔹 3. Inheritance
●​ OOP Concept: Child class inherits parent properties.​

●​ Mapping in C:​

○​ Simulate using nested structures.​

○​ Child struct includes parent struct as a field.​

✅ Example:
struct Person {

char name[50];

};

struct Student {

struct Person base; // acts like inheritance

int rollNo;

};

🔹 4. Polymorphism
●​ OOP Concept: Same function name with different behaviors.​

●​ Mapping in C:​

○​ Use function pointers to achieve polymorphism (like virtual functions).​

✅ Example:
#include <stdio.h>

typedef void (*SpeakFunc)();

struct Animal {

SpeakFunc speak;

};

void dogSpeak() { printf("Woof!\n"); }

void catSpeak() { printf("Meow!\n"); }

int main() {

struct Animal dog = {dogSpeak};

struct Animal cat = {catSpeak};

[Link](); // Woof!

[Link](); // Meow!

return 0;

🔹 5. Message Passing
●​ OOP Concept: Objects communicate by sending messages (method calls).​

●​ Mapping in C:​

○​ Achieved by calling functions with struct as parameters.​

4️⃣ Advantages of Mapping OOP in Non-OOP Languages

✔ Introduces modularity and reusability.​
✔ Helps manage complexity in large procedural programs.​
✔ Eases migration from procedural → OOP systems.
5️⃣ Limitations
❌ No direct support → More coding effort.​
❌ Syntax becomes verbose.​
❌ Hard to enforce strict encapsulation and inheritance.​
❌ Lacks built-in support like Java, C++, Python.

6️⃣ Summary
●​ Mapping OOP concepts in non-OOP languages means simulating classes,
objects, encapsulation, inheritance, polymorphism, and message passing
using procedural features like structs, functions, modules, and function
pointers.​

●​ This allows procedural languages to adopt object-oriented style even without

direct support.​

✅ In short:​
Mapping object-oriented concepts using non-object-oriented languages = applying
OOP principles (like class, inheritance, polymorphism) in procedural languages (like
C, Pascal) using structures, functions, modules, and pointers.

📘 Translating Classes into Data

Structures

1️⃣ Introduction
●​ In Object-Oriented Programming (OOP), a class is a blueprint for creating
objects, containing attributes (data) and methods (behavior).​

●​ But in non-OOP or lower-level implementations, we often need to represent

these classes using data structures (like arrays, records, structs, or tables).​
👉 So, Translating classes into data structures means converting object-oriented
class definitions into procedural-style data representations that can be used in
programming languages without native OOP support.

2️⃣ Why Do We Translate Classes into Data Structures?

✔ To implement OOP concepts in non-OOP languages (like C, Pascal, Fortran).​
✔ To store objects in databases or files.​
✔ For performance optimization (when object overhead is costly).​
✔ For system-level design where objects must be represented as raw data.

3️⃣ Mapping Classes → Data Structures

🔹 Step 1: Translate Attributes → Fields
●​ Each class attribute becomes a field in a data structure.​

Example (Book Class in OOP):

class Book {

string title;

string author;

int ISBN;

};

Translated into C Struct (Data Structure):

struct Book {

char title[50];

char author[50];

int ISBN;

};
🔹 Step 2: Translate Methods → Functions
●​ Each class method becomes a function that operates on the data structure.​

Example (OOP Style):

class Book {

string title;

string author;

int ISBN;

public:

void display();

};

Translated into C Style:

struct Book {

char title[50];

char author[50];

int ISBN;

};

void display(struct Book b) {

printf("Title: %s, Author: %s, ISBN: %d\n", [Link], [Link], [Link]);

}
🔹 Step 3: Translate Inheritance → Nested Structures
●​ Inheritance is simulated by embedding one structure inside another.​

OOP Example:

class Person {

string name;

};

class Student : public Person {

int rollNo;

};

Translated into C Data Structures:

struct Person {

char name[50];

};

struct Student {

struct Person base; // inheritance simulation

int rollNo;

};

🔹 Step 4: Translate Polymorphism → Function Pointers

●​ Virtual methods in classes can be simulated using function pointers in C.​

Example in C:

struct Shape {
 void (*draw)();

};

void drawCircle() { printf("Drawing Circle\n"); }

void drawSquare() { printf("Drawing Square\n"); }

int main() {

struct Shape circle = { drawCircle };

struct Shape square = { drawSquare };

[Link](); // Drawing Circle

[Link](); // Drawing Square

4️⃣ Summary Table

OOP Concept Translation in Data Structure

Class struct / record

Object Variable of struct

Attributes Fields in struct

Methods Functions (operate on struct)

 Inheritance Nested struct / composition

Polymorphis Function pointers

m

5️⃣ Example Recap (Library System – Class → Data

Structure)
Class (OOP):

class Member {

string name;

int memberID;

void borrowBook(Book b);

};

Data Structure (C):

struct Member {

char name[50];

int memberID;

};

void borrowBook(struct Member m, struct Book b) {

printf("%s borrowed %s\n", [Link], [Link]);

}
✅ In short:​
Translating classes into data structures = Converting OOP classes (with attributes +
methods) into procedural data structures (like structs + functions) so that
object-oriented ideas can be implemented in non-object-oriented environments.

📘 OOAD Core Topics with C++

Examples

🔹 Passing Arguments to Methods

●​ Definition: Sending values/variables to functions (methods) when calling them.​

●​ Types in C++:​

1.​ Pass by Value (copy of data)​

2.​ Pass by Reference (alias, modifies original)​

3.​ Pass by Pointer (address passed)​

✅ Example:
#include <iostream>

using namespace std;

class Calculator {

public:

void addByValue(int a, int b) { // pass by value

cout << "Sum (by value): " << (a+b) << endl;

void addByReference(int &a, int &b) { // pass by reference

a += b;
 cout << "Result (by reference): " << a << endl;

};

int main() {

Calculator c;

int x = 5, y = 3;

[Link](x, y);

[Link](x, y);

return 0;

🔹 Implementing Inheritance
●​ Definition: Mechanism of creating new classes (child) from existing ones
(parent).​

✅ Example:
#include <iostream>

using namespace std;

class Person {

public:

string name;

void display() { cout << "Name: " << name << endl; }

};
class Student : public Person { // Inheritance

public:

int rollNo;

void show() { cout << "Roll No: " << rollNo << endl; }

};

int main() {

Student s;

[Link] = "Manik";

[Link] = 101;

[Link]();

[Link]();

return 0;

🔹 Associations
●​ Definition: Relationship between two classes.​

✅ Example (One-to-One):
#include <iostream>

using namespace std;

class LibraryCard {

public:

int cardNo;
 LibraryCard(int c) { cardNo = c; }

};

class Student {

public:

string name;

LibraryCard *card; // Association

Student(string n, LibraryCard *c) : name(n), card(c) {}

void show() { cout << name << " has card " << card->cardNo << endl; }

};

int main() {

LibraryCard c1(123);

Student s1("Manik", &c1);

[Link]();

return 0;

🔹 Encapsulation
●​ Definition: Wrapping data + methods in a class, hiding internal details.​

✅ Example:
#include <iostream>

using namespace std;

class Account {

private: // hidden

double balance;

public:

Account(double b) { balance = b; }

void deposit(double amt) { balance += amt; }

double getBalance() { return balance; } // controlled access

};

int main() {

Account a1(1000);

[Link](500);

cout << "Balance: " << [Link]() << endl;

return 0;

🔹 OOP Style
1. Reusability

✅ Example (inheritance reuse):

class Vehicle {

public: void start() { cout << "Vehicle started\n"; } };

class Car : public Vehicle {};

2. Extensibility
✅ Example (adding new features easily):
class Car {

public: void drive() { cout << "Driving car\n"; } };

class ElectricCar : public Car { // extended class

public: void charge() { cout << "Charging battery\n"; } };

3. Robustness

✅ Example (exception handling):

try {

throw runtime_error("Error occurred");

} catch(exception &e) {

cout << "Handled: " << [Link]();

4. Programming in the Large

●​ Large projects in C++ are organized into namespaces, classes, and modules.​

🔹 Procedural vs OOP
Procedural (C) OOP (C++)

Uses functions Uses classes &

objects

Data is global Data hidden inside

class
 Reuse is low Reuse via inheritance

Example: Example: cout

printf

🔹 OOP Language Features (in C++)

1.​ Class & Object:​

class Book { public: string title; };

Book b1;

2.​ Encapsulation: Private data + public methods.​

3.​ Inheritance: class B : public A {}​

4.​ Polymorphism: Overloading/Overriding.​

5.​ Abstraction: Abstract classes / interfaces.​

6.​ Message Passing: [Link]()​

🔹 Abstraction
●​ Definition: Hiding details, showing only essential.​

✅ Example:
#include <iostream>

using namespace std;

class Shape {

public:

virtual void draw() = 0; // pure virtual (abstraction)

};

class Circle : public Shape {

public:

void draw() { cout << "Drawing Circle\n"; }

};

int main() {

Shape *s = new Circle();

s->draw(); // abstraction in action

return 0;

🔹 Encapsulation (Recap)
●​ Already shown above: private variables + getters/setters.​

👉 Difference:
●​ Abstraction = Hiding implementation (design-level).​

●​ Encapsulation = Hiding data (code-level).​

✅ In short (all in C++):

●​ Passing args → By value, reference, pointer.​

●​ Inheritance → class Child : public Parent.​

●​ Association → One class holds reference of another.​

●​ Encapsulation → private data, public methods.​

●​ OOP style → Reusability, extensibility, robustness.​

●​ Procedural vs OOP → Functions vs Classes.​

●​ Features → Class, Object, Inheritance, Polymorphism, Abstraction,

Encapsulation.​

●​ Abstraction → Pure virtual classes; Encapsulation → Access specifiers.​