OOAD (CY-604 (B)) - Unit 5 Short Notes

UNIT 5: Object-Oriented Analysis and Design (OOAD)

A. FUNDAMENTAL OBJECT-ORIENTED CONCEPTS (Core Pillars)

These are the foundational principles of the OO paradigm.

1. Encapsulation

• Definition: The mechanism of binding data (attributes) and the methods (functions) that operate on that data into a single unit, called a class. It restricts direct access to some of an object's components, which is a key form of data hiding.

• Principle: Internal state of an object is protected from outside interference. Access is controlled via a public interface.

• Implementation: Achieved using access specifiers:

  • private: Accessible only within the same class. (Primary tool for data hiding).

  • public: Accessible from any other class.

  • protected: Accessible within the same class and its subclasses.

• Example: A BankAccount class encapsulates balance (private) and provides public methods deposit() and withdraw() to modify it safely.

[!TIP] Exam Focus: Distinguish Encapsulation (bundling data & methods) from Data Hiding (the goal of restricting access, often achieved via private members).

2. Inheritance

• Definition: The process where a new class (subclass/child) acquires the properties and behaviors of an existing class (superclass/parent). It represents an "IS-A" relationship.

• Types:

  | Type | Description | Example | | :--- | :--- | :--- | | Single | One subclass inherits from one superclass. | Car inherits from Vehicle. | | Multiple | One subclass inherits from multiple superclasses. (Not supported in Java/C#) | HybridEngine inherits from ElectricMotor and CombustionEngine. | | Multilevel | Inheritance chain: A -> B -> C. | ElectricCar inherits from Car, which inherits from Vehicle. | | Hierarchical | Multiple subclasses inherit from one superclass. | Car, Truck, Motorcycle all inherit from Vehicle. | | Hybrid | Combination of two or more types. | Multilevel + Hierarchical. |

• Benefits:

  • Reusability: Write common code once in a superclass.

  • Extensibility: Easily add new functionality in subclasses.

  • Organizational: Creates a logical hierarchy/classification.

3. Polymorphism

• Definition: The ability of an object to take many forms. It allows a single interface to represent different underlying forms (data types/classes).

• Types:

  1. Compile-Time Polymorphism (Static Binding):

     • Method Overloading: Multiple methods in the same class with the same name but different parameters (type, number, or order).

     • Operator Overloading: Redefining the behavior of an operator (e.g., +) for user-defined types (supported in C++, not Java).

  2. Runtime Polymorphism (Dynamic Binding):

     • Method Overriding: Subclass provides a specific implementation of a method that is already defined in its superclass. The method call is resolved at runtime based on the actual object type.

     • Requires: Inheritance + virtual/override keyword (language-specific).

[!TIP] Exam Distinction: Overloading happens within a class (same name, different parameters). Overriding happens across a hierarchy (same signature, different implementation).

4. Abstraction

• Definition: The concept of hiding complex implementation details and showing only the essential features of an object. It focuses on what an object does, not how it does it.

• Implementation: Achieved using:

  • Abstract Classes: Cannot be instantiated. May contain abstract methods (no body) that must be implemented by subclasses.

  • Interfaces: A pure contract of abstract methods. A class can implement multiple interfaces.

• Abstraction vs. Encapsulation:

  • Abstraction is about hiding implementation details at the design level (using abstract classes/interfaces).

  • Encapsulation is about bundling data and methods and hiding data at the implementation level (using access modifiers).

B. UNIFIED MODELING LANGUAGE (UML) & MODELING

1. Primary Goals of UML

A standardized, general-purpose visual modeling language to:

• Visualize system architecture.

• Specify system components and their interactions.

• Construct the system blueprint.

• Document all artifacts.

2. UML Diagrams Overview

UML 2.x diagrams are broadly classified into:

• Structural Diagrams (Static): Show the static structure.

  • Class, Object, Component, Deployment, Composite Structure, Package.

• Behavioral Diagrams (Dynamic): Show dynamic behavior and interactions.

  • Use Case, Sequence, Activity, State Machine, Communication, Interaction Overview, Timing.

3. Class Diagram (Detailed)

Purpose: The backbone of OO design. Shows the static structure of a system by modeling:

• Classes (with attributes & operations)

• Their relationships

• Multiplicity (cardinality)

• Navigability

Notation:

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

|     Class Name      |

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

| - attribute1 : Type |
| - attribute2 : Type |

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

| + operation1()      |
| + operation2()      |

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

• + = Public, - = Private, # = Protected.

Key Relationships:

Multiplicity: Placed at ends of association lines.

• 1 : Exactly one.

• 0..1 : Zero or one.

• 1..* : One or more.

• * or 0..* : Zero or more.

• 1..5 : Between 1 and 5.

Example (Simplified Library):

[Library] "1" ◆─── "*" [Book]

[Book] "1" ◇───── "*" [Author]

[Book] ▲──────── [TextBook]

[Student] "1" ──── "0..*" [BorrowRecord]

[BorrowRecord] ───▷ [Book]

4. Relationship Among Different UML Models

UML diagrams provide complementary views of the same system:

1. Use Case Diagram (Requirements) → Class Diagram (Static Structure).

2. Class Diagram → Sequence/Communication Diagrams (Dynamic Interaction for a scenario).

3. Sequence Diagram details the messages between objects defined in the class diagram.

4. Activity/State Diagrams model workflow/state changes of classes/objects.

5. Component/Deployment Diagrams show physical architecture based on logical classes.

[!TIP] Exam Strategy: Be prepared to draw a class diagram for a given scenario (e.g., Banking, Hospital). Identify classes, attributes, key methods, and correctly apply relationships (especially Aggregation vs. Composition).

C. OBJECT-ORIENTED DESIGN (OOD) PROCESS & IMPLEMENTATION

1. Object-Oriented Design (OOD)

• Definition: The phase following OOA (Object-Oriented Analysis). It focuses on the technical solution—how to build the system to meet the requirements.

• Key Activities:

  1. Define system architecture (layers, subsystems).

  2. Refine and detail class definitions from OOA.

  3. Specify relationships, collaborations, and responsibilities.

  4. Design patterns for recurring problems.

  5. Define interfaces and control flow.

2. Translating OOD into Implementation

• Mapping:

  • Class → Class file/definition in code (.java, .cs).

  • Attribute → Member variable.

  • Operation → Method/function.

  • Inheritance → extends (Java) / : (C#) keyword.

  • Interface → implements (Java) / : (C#) keyword.

  • Association → Object reference/pointer as a member variable.

  • Aggregation/Composition → Similar to association, but with ownership semantics (e.g., managing lifecycle).

• Considerations:

  • Language Choice: Must support core OO features (e.g., Java, C#, C++, Python).

  • Design Patterns: Implement patterns (Singleton, Observer, etc.) identified in OOD.

  • Persistence: Map objects to database tables (ORM - Object-Relational Mapping) if using a relational DB.

3. Managing Complexity in Large Systems

• OO Approach:

  • Modularity: System is decomposed into cohesive, loosely-coupled classes/objects.

  • Encapsulation: Hides internal complexity behind a simple interface.

  • Abstraction: Models the problem domain at an appropriate level of detail.

  • Inheritance: Promotes code reuse and hierarchical organization.

• Procedural Programming Approach:

  • Top-Down Decomposition: Breaks problem into functions/subroutines.

  • Data is Passive: Global/shared data structures are manipulated by many functions.

  • Tight Coupling: Functions and data are often inseparable, leading to ripple effects of change.

  • Result: Harder to maintain, reuse, and scale for large, complex systems.

[!TIP] Key Contrast: OO focuses on "what objects exist and how they collaborate". Procedural focuses on "what steps to execute and in what order".

D. OBJECT-ORIENTED LANGUAGES vs. PROCEDURAL/OTHER PARADIGMS

1. Fundamental Characteristics of OO Languages

A language is considered OO if it supports:

1. Objects & Classes: Fundamental units of construction.

2. Encapsulation: Bundling & information hiding.

3. Inheritance: Mechanism for reuse and hierarchy.

4. Polymorphism: Ability to send the same message to different objects.

2. OO vs. Procedural Programming

3. OO vs. Functional Languages

E. OBJECT-ORIENTED DATABASES (OODB) & QUERIES

1. Query Language for OODB (OODQL)

• Definition: A query language designed to work with Object-Oriented Databases (OODB), which store data as objects (like in OO programs) rather than tables.

• Key Features:

  • Directly manipulates complex objects (with nested structures).

  • Supports inheritance in queries (e.g., "find all Vehicle objects" includes Car, Truck).

  • Can invoke methods on objects within queries.

  • Supports object identity (unique ID, not just key value).

  • Handles long-duration transactions and versioning.

2. OODQL vs. SQL (Relational)

[!TIP] Critical Concept: The "Impedance Mismatch" is the fundamental problem OODB/OODQL tries to solve—the disconnect between the object model used in OO programming and the relational model used in traditional SQL databases.