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

UNIT 3: Object-Oriented Analysis & Design (OOAD)

Based on DEC 2024 OOAD paper analysis. Focus on definitions, comparisons, processes, and diagrammatic notations.

I. Core Object-Oriented Concepts & Principles

A. Encapsulation

• Definition: The bundling of data (attributes) and the methods (operations) that operate on that data into a single unit (class), and restricting direct access to some of the object's components.

• Mechanism: Achieved through access specifiers (e.g., private, protected, public in Java/C++). private members are hidden, accessed only via public methods (getters/setters).

• Importance:

  • Information Hiding: Protects internal state from unintended modification.

  • Modularity: Changes inside a class don't affect external code using its public interface.

  • Increased Security & Maintainability.

[!TIP] Exam Focus: Often asked as "Explain the term." Be ready to give a concise definition and a simple code example showing private data with public methods.

B. Inheritance

• Definition: A mechanism where a new class (subclass/child) derives properties and behaviors from an existing class (superclass/parent). Promotes code reuse.

• Types:

  • Single: One subclass inherits from one superclass.

  • Multiple: One subclass inherits from multiple superclasses (supported in C++, Python; not in Java for classes—interfaces used instead).

  • Multilevel: A subclass inherits from another subclass (e.g., Grandparent -> Parent -> Child).

  • Hierarchical: Multiple subclasses inherit from one superclass.

  • Hybrid: Combination of above types.

• Benefits: Code reuse, extensibility, logical hierarchy.

• Drawbacks: Tight coupling between parent and child; changes in parent can break child. Overuse can lead to deep, complex hierarchies ("fragile base class problem").

[!TIP] Common Pitfall: Confusing inheritance (is-a relationship) with composition (has-a relationship). Inheritance is for "type" extension.

C. Polymorphism

• Definition: The ability of an object to take many forms. The same interface (method name) can exhibit different behaviors based on the actual object type at runtime.

• Types:

  1. Compile-Time (Static) Polymorphism:

     • Achieved by Method Overloading (same method name, different parameters in same class) and Operator Overloading.

     • Binding (method call to definition) happens at compile time.

  2. Runtime (Dynamic) Polymorphism:

     • Achieved by Method Overriding (subclass provides a specific implementation of a method already defined in its superclass).

     • Binding happens at runtime via dynamic method dispatch (using virtual keyword in C++, by default in Java).

     • Requires inheritance.

• Implementation: In Java/C#, all non-static, non-final, non-private methods are virtual by default. In C++, use virtual keyword.

[!TIP] Exam Focus: Distinguish Overloading (same class, different params) vs. Overriding (different classes, same signature). Overriding enables runtime polymorphism.

D. Abstraction

• Definition: Hiding implementation details and showing only essential features of an object. Focuses on what an object does, not how.

• Abstract Class vs. Interface:

  • Abstract Class:

    • Cannot be instantiated.

    • Can have abstract methods (no body) and concrete methods (with body).

    • Can have fields of any access modifier.

    • A class can inherit from only one abstract class (single inheritance).

  • Interface (Java/C#):

    • A pure contract. All methods are implicitly public abstract (Java 8+ allows default/static methods).

    • All fields are public static final (constants).

    • A class can implement multiple interfaces.

    • Represents a "can-do" relationship (capability).

• Purpose: Reduces complexity, isolates impact of change, defines clear contracts.

II. Unified Modeling Language (UML) & Structural Diagrams

A. Class Diagram

• Purpose: The primary UML structural diagram for static modeling. Shows the system's classes, their attributes, operations, and the relationships among them.

• Components:

  • Class: Represented as a rectangle with 3 compartments: Name, Attributes (with visibility + public, - private, # protected), Operations (methods).

  • Relationships:

    1. Association: Basic structural relationship ("has-a"). Solid line. Can have multiplicity (1, *, 0..1, 1..*) and role names.

       • * (many), 1 (one), 0..1 (optional), 1..* (at least one).

    2. Aggregation: A special form of association representing a whole-part relationship where the part can exist independently. Hollow diamond on the whole side.

    3. Composition: A stronger form of aggregation. Part cannot exist independently of the whole. Filled diamond on the whole side. Lifecycle dependency.

    4. Generalization (Inheritance): "is-a" relationship. Solid line with a hollow arrowhead pointing to the superclass.

    5. Dependency: A using relationship. A change in the supplier (target) may affect the client (source). Dashed line with an open arrow pointing from client to supplier.

    6. Realization: Class implements an interface. Dashed line with a hollow triangle pointing to the interface.

[!TIP] Exam Focus: Aggregation vs. Composition is a classic question. Composition implies strong ownership and coincident lifecycle (e.g., Car composes Engine). Aggregation implies shared ownership (e.g., Department aggregates Professor).

B. Primary Goals of UML

1. Standardization: Provide a common, standardized notation for software blueprints.

2. Visualization: Create graphical representations (diagrams) to better understand the system.

3. Specification: Precisely specify the system's artifacts (classes, components, etc.).

4. Construction: Directly map UML models to implementation code (forward engineering).

5. Documentation: Serve as a primary source for documenting the system's architecture and design.

III. Object-Oriented Paradigm & Languages

A. OO Approach vs. Procedural Programming

B. How OO Manages Complexity in Large Systems

1. Modularity: System is broken into independent, manageable objects (classes).

2. Information Hiding (Encapsulation): Internal details of an object are hidden behind a public interface. Reduces system-wide impact of changes.

3. Separation of Concerns: Each class has a single, well-defined responsibility.

4. Reusability:

   • Inheritance: Create new classes from existing ones.

   • Composition: Build complex objects by combining simpler, reusable objects ("has-a").

5. Abstraction: Define clear, simplified interfaces, ignoring irrelevant details.

C. Fundamental Characteristics of OO Languages

A language is considered object-oriented if it supports all four pillars:

1. Abstraction

2. Encapsulation

3. Inheritance

4. Polymorphism

Additional common features: Object identity, message passing, dynamic binding.

D. Comparison: OO vs. Procedural/Functional Languages

IV. OO Models & Implementation

A. Models Available in OO Languages

The Three-Phase Model (Booch/OMT):

1. Object Model: Static structure. Describes objects, classes, attributes, operations, and relationships (Association, Aggregation, Inheritance). Represented by Class Diagrams.

2. Dynamic Model: Behavioral over time. Describes state changes of objects in response to events. Uses State Diagrams and Sequence Diagrams.

3. Functional Model: Data flow and transformations. Describes how data values are computed, the flow of information between functions. Uses Data Flow Diagrams (DFDs) and Activity Diagrams.

B. Relationships Among Different OO Models

• The Object Model provides the static skeleton (nouns/classes).

• The Dynamic Model describes the scenarios and lifecycles of those objects (verbs/events over time).

• The Functional Model describes the computations and transformations that occur on the data as it flows through the system's operations.

• Integration: A complete system design requires all three. For a use case: Object Model identifies participating classes, Dynamic Model shows their interaction sequence, Functional Model details the computations in each step.

C. Process of Translating OOD into Implementation

1. Map Classes to Code: Each UML class becomes a class/struct in the target language (Java, C++, C#).

2. Map Attributes: UML attributes become member variables with appropriate data types and access specifiers (private).

3. Map Operations: UML operations become member functions/methods. Visibility (public, private) is mapped.

4. Map Relationships:

   • Association: Implemented as object references/pointers as member variables.

   • Aggregation/Composition: Implemented as references (aggregation) or by creating/destroying member objects within the constructor/destructor (composition).

   • Inheritance (Generalization): Use language's extends (Java) or : (C++) keyword.

   • Dependency: Implemented as a method parameter, local variable, or temporary object creation.

5. Map Interfaces: UML interfaces become interface (Java) or pure abstract class (C++). Classes implement/inherit them.

6. Consider Patterns & Idioms: Apply relevant design patterns (e.g., Singleton, Factory) during coding for proven solutions.

7. Language-Specific Mappings: Handle differences (e.g., multiple inheritance in C++ vs. interfaces in Java, garbage collection vs. manual memory management).

V. Object-Oriented Design (OOD) & Databases

A. What is Object-Oriented Design (OOD)?

• Definition: The phase in software development that follows analysis (OOA). It defines the solution—how the system will be built to meet the requirements. It specifies the detailed class structures, responsibilities, collaborations, and architectural decisions.

• Objectives: Create a design that is modular, reusable, extensible, and implementable.

• Phase in SDLC: Part of the Design phase, after requirements gathering/analysis (OOA) and before implementation (coding).

• Key Outputs: Class diagrams with detailed attributes/methods, sequence diagrams, collaboration diagrams, package diagrams, design patterns applied.

B. Query Languages for Object-Oriented Databases (OODB)

• Purpose & Necessity: To overcome the "impedance mismatch" between the object-oriented programming model (with complex objects, inheritance, identity) and the relational model (flat tables, no inheritance). OODB query languages allow direct, seamless querying of persistent objects without complex mapping (ORM).

• Key Features & Syntax (OQL - Object Query Language concepts):

  • Path Expressions: Navigate through object structures (e.g., department.employees.name).

  • Complex Objects: Query nested objects and collections directly.

  • Inheritance: Queries can be polymorphic (e.g., SELECT p FROM Person p returns objects of Person and all its subclasses like Student, Faculty).

  • Object Identity: Queries based on object identity (oid), not just attribute values.

  • Collection Types: Supports sets, lists, bags, arrays.

  • Syntax Similarity: Often resembles SQL SELECT-FROM-WHERE but operates on objects and paths.

Example OQL Concept:

SELECT e.name

FROM Employee e

WHERE e.department.name = "Research" AND e.salary > 50000

Here, e.department.name is a path expression navigating from Employee to its related Department object.

C. Comparison: OODB Query Language vs. SQL (Relational)

[!TIP] Exam Focus: Impedance Mismatch is the key reason for OODB and its query language. Be prepared to explain it with an example (e.g., querying a Customer with a list of Order objects).