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

UNIT 1: Foundations & UML Overview

Based on the B OOAD - DEC 2024 paper, this unit covers the core philosophy of Object-Orientation, its primary principles, the Unified Modeling Language (UML), and the transition from design to implementation and databases.

1.0 Fundamental Object-Oriented Concepts (The Four Pillars)

These are the foundational mechanisms that define the OO paradigm.

[!TIP] Common Pitfall: Students often confuse Abstraction (hiding complexity, defining contract) and Encapsulation (bundling data/methods, hiding state). Abstraction is at the design level; Encapsulation is at the implementation level.

2.0 Object-Oriented Analysis & Design (OOAD) Process & Philosophy

2.1 The Object-Oriented Approach

• Philosophy: Views a system as a collection of cooperating objects. Primary building blocks are objects, not functions or procedures.

• Key Principles:

  • Object Identity: Each object has a unique identity.

  • Encapsulation: As defined above.

  • Message Passing: Objects interact by sending and receiving messages (invoking methods).

2.2 OO vs. Procedural/Functional Programming

2.3 Managing Complexity in Large Systems

OO principles directly combat complexity:

• Modularity: System is broken into manageable, independent classes.

• Abstraction: Hides unnecessary details, exposing only essential interfaces.

• Inheritance: Creates hierarchical taxonomies, reducing redundancy.

• Encapsulation: Localizes change; internal modifications don't affect other objects.

• Loose Coupling & High Cohesion: Objects interact through well-defined interfaces (low coupling) and have focused responsibilities (high cohesion).

2.4 Object-Oriented Design (OOD)

• Definition: The process of defining the software architecture, components, and interfaces of a system to fulfill the requirements identified during analysis.

• Objective: To create a design model that is implementable, efficient, and maintainable.

• Activities: Translating the analysis model (use cases, domain models) into a design model (class diagrams, sequence diagrams, architecture).

3.0 Unified Modeling Language (UML) - Introduction & Models

3.1 Primary Goals of UML

A standardized visual modeling language used to:

1. Visualize a system's architectural blueprints.

2. Specify its structure and behavior.

3. Construct its detailed models.

4. Document its artifacts.

Serves as a common language for stakeholders (analysts, designers, developers, clients).

3.2 UML Diagrams - Classification

UML 2.x diagrams are broadly classified into:

Relationship Among Models: They provide complementary views of the same system. For example, a Use Case Diagram (functional requirements) drives the Class Diagram (static structure), which is then detailed in Sequence Diagrams (dynamic interactions) for specific scenarios.

3.3 Class Diagram (Deep Dive - Most Asked)

• Purpose: Shows the static structure of a system—its classes, attributes, operations, and the relationships among them.

• Core Elements:

  • Class: Represented as a rectangle with three compartments: Name, Attributes, Operations.

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

  • Interface: A class-like rectangle with <<interface>> stereotype.

  • Relationships:

    • Association: Structural relationship ("has-a"). Shown as a solid line. Multiplicity (1, 0..1, 1..*, *, etc.) specifies cardinality at each end.

    • Aggregation: A special form of association (whole-part) with shared ownership. Represented by a hollow diamond on the whole side.

    • Composition: A stronger form of aggregation (whole-part) with exclusive ownership & coincident lifecycle. Represented by a filled (black) diamond on the whole side.

    • Generalization (Inheritance): "IS-A" relationship. Shown as a solid line with a hollow arrowhead pointing to the parent.

    • Dependency: A "uses" relationship (a change in one element affects another). Shown as a dashed line with an open arrowhead.

    • Realization: A class/interface implements an interface. Shown as a dashed line with a hollow arrowhead pointing to the interface.

Example: Simple Library System Class Diagram

+----------------+      1..* +----------------+      0..* +----------------+

|    Library     |<>--------|    Book        |<>--------|   Borrower     |

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

| - name: String |           | - isbn: String |           | - id: String   |
| - address: Str |           | - title: String|           | - name: String |

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

| + addBook()    |           | + checkout()   |           | + borrowBook() |
| + register()   |           | + return()     |           | + returnBook() |

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

<> denotes Composition (Library composes Books; Book composes Borrower relationship? Adjust based on logic. Often, Borrower and Book have an association with multiplicity).

4.0 OO Languages & Implementation

4.1 Fundamental Characteristics of OO Languages

A language is considered OO if it supports:

1. Classes & Objects as fundamental constructs.

2. Encapsulation (via access control).

3. Inheritance (single or multiple).

4. Polymorphism (dynamic binding). Examples: C++, Java, C#, Python, Smalltalk.

4.2 Translating Object-Oriented Design into Implementation

This is the process of mapping design model elements to source code.

1. Map Classes: Each UML class becomes a class/interface in code.

2. Map Attributes & Operations: Attributes become member variables; operations become methods. Apply access specifiers as per design.

3. Map Relationships:

   • Association: Implemented using object references (pointers) as member variables.

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

   • Interface Realization: Use implements (Java) or pure virtual classes (C++).

   • Composition/Aggregation: Implemented as member object references (composition) or pointers/references (aggregation).

4. Implement Behavior: Flesh out method bodies based on sequence/activity diagrams.

5. Apply Patterns & Refactor: Use established Design Patterns (e.g., Singleton, Observer) to solve recurring problems and improve code structure.

5.0 Object-Oriented Databases (OODB) & Query Languages

5.1 Need for OODB

Relational DBMS (RDBMS) struggle with:

• Complex data types (objects, arrays, multimedia).

• Inheritance (mapping class hierarchies to tables is awkward).

• Direct object storage (avoids ORM impedance mismatch).

• Navigational access (traversing object graphs naturally).

• OODB stores objects persistently in a database, maintaining their OO properties.

5.2 Query Language for OODB (e.g., OQL - Object Query Language)

• Definition: A declarative, SQL-like query language for OODBs, standardized by ODMG.

• Purpose: To query and manipulate persistent objects based on their class structure and relationships.

• Key Capabilities:

  • Query objects by class.

  • Navigate through object references (path expressions).

  • Utilize inheritance (queries on a superclass include subclasses).

  • Return collections of objects (sets, lists, bags).

• Simple Syntax Example:

  
  SELECT p.name
  
  FROM Person p
  
  WHERE p.address.city = "Bhopal"
  
  

  (Navigates from Person to address to city).

5.3 Comparison: OODB Query Language (OQL) vs. SQL

[!TIP] Exam Focus: Be prepared to differentiate clearly between OQL and SQL, especially regarding data model, navigation (path vs. join), and inheritance support. This is a direct 7m question.