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

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

I. Foundations of Object-Oriented Paradigm

Object-Oriented Approach:

A programming and design paradigm that structures software as a collection of objects that interact by sending messages to each other. Each object is an instance of a class, which defines its attributes (data) and methods (behavior).

Core Principles:

• Encapsulation: Bundling data and methods that operate on that data within a single unit (object/class).

• Inheritance: Mechanism for creating new classes (derived) from existing ones (base), promoting reuse.

• Polymorphism: Ability of different classes to respond to the same message (method call) in different ways.

• Abstraction: Hiding complex implementation details and exposing only essential features.

Comparison with Procedural Programming:

Role in Managing Complexity:

• Decomposition: Breaks a large, complex system into smaller, manageable objects.

• Abstraction: Allows designers to focus on what an object does, not how it does it.

• Encapsulation: Protects object integrity by hiding internal state, reducing interdependencies.

• Inheritance: Promotes reusability, reducing code duplication and maintenance overhead.

• Polymorphism: Enables flexible, extensible code that can handle new object types with minimal changes.

[!TIP] Exam Focus: Be prepared to contrast OO with procedural programming point-by-point and explain how each OO principle (especially encapsulation and abstraction) directly tackles complexity.

II. Core Object-Oriented Concepts

1. Encapsulation

• Definition: The mechanism of wrapping data (variables) and code (methods) together as a single unit (class) and restricting direct access to some of the object's internal components.

• Purpose:

  • Data Hiding: Protects internal state from unintended external modification.

  • Controlled Access: Provides public methods (getters/setters) to access and modify private data safely.

  • Increased Flexibility: Internal implementation can change without affecting client code.

• Implementation: Achieved using access specifiers (e.g., private, protected, public in C++/Java).

2. Inheritance

• Definition: A mechanism where a new class (derived/child/subclass) acquires the properties and behaviors of an existing class (base/parent/superclass).

• Types:

  • Single: One subclass inherits from one superclass.

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

  • Multilevel: A subclass is inherited from another subclass (A -> B -> C).

  • Hierarchical: Multiple subclasses inherit from a single superclass.

  • Hybrid: Combination of two or more types.

• Key Terms: base class, derived class, superclass, subclass.

• Benefits: Reusability (reuse existing code), Extensibility (add new features easily), Logical Hierarchy (is-a relationship).

3. Polymorphism

• Definition: "Many forms." The ability of an object to take on many forms. The same operation (method name) can behave differently on different classes.

• Types:

  • Compile-Time Polymorphism (Static Binding): Resolved at compile time.

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

  • Runtime Polymorphism (Dynamic Binding): Resolved at runtime based on the actual object type.

    • Method Overriding: Subclass provides a specific implementation for a method already defined in its superclass. Requires inheritance.

    • Dynamic Binding: The JVM/compiler decides at runtime which overridden method to call based on the actual object type, not the reference type.

4. Abstraction

• Definition: The concept of exposing only the essential features of an object while hiding the unnecessary details.

• Significance:

  • Reduces complexity by focusing on what an object does, not how.

  • Provides a clear, simplified interface for the user.

• Implementation Mechanisms:

  • Abstract Classes: Cannot be instantiated. May contain abstract methods (declared without implementation) that must be implemented by concrete subclasses.

  • Interfaces: A pure form of abstraction. Contains only abstract methods (prior to Java 8) and constants. A class can implement multiple interfaces, achieving a form of multiple inheritance.

[!TIP] Common Pitfall: Do not confuse Abstraction (concept of hiding complexity) with Encapsulation (mechanism of bundling data/methods and controlling access). Abstraction uses encapsulation.

III. Unified Modeling Language (UML)

Primary Goals of UML:

1. Visualize: Create graphical representations (diagrams) of a system.

2. Specify: Provide a precise, unambiguous model of the system.

3. Construct: Serve as a blueprint for generating code.

4. Document: Capture design decisions and system architecture.

5. Communicate: Establish a common language for stakeholders (analysts, designers, developers, clients).

UML Diagrams Overview:

• Structural Diagrams: Show the static structure of a system.

  • Class Diagram, Object Diagram, Component Diagram, Deployment Diagram, Package Diagram.

• Behavioral Diagrams: Show dynamic behavior and interactions.

  • Use Case Diagram, Sequence Diagram, Activity Diagram, State Machine Diagram.

Class Diagram (Most Important Structural Diagram):

• Elements:

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

  • Interface: Similar to class, with <<interface>> stereotype.

  • Enumeration: A set of named constants.

• Relationships:

  | Relationship | Symbol | Meaning | Example | | :--- | :--- | :--- | :--- | | Association | Solid line | "uses" relationship; objects are connected. | Student -- Course | | Aggregation | Line with hollow diamond | "has-a" (whole-part); part can exist independently. | Department <>-- Professor | | Composition | Line with filled diamond | Strong "has-a"; part lifecycle depends on whole. | Car <filled>-- Engine | | Generalization | Line with hollow triangle | Inheritance (is-a). | Car <hollow>-- Vehicle | | Dependency | Dashed line | One class depends on another (e.g., uses as parameter). | Report ..> Database | | Realization | Dashed line with hollow triangle | Class implements an interface. | Car ..<> Drivable |

• Multiplicity: Specifies the number of instances at each end of an association (e.g., 1, *, 0..1, 1..*).

• Navigability: Arrowhead on association line indicates direction of access (A --> B means A knows about B).

Relationships Among Different UML Models:

• Traceability: Elements in one diagram are linked to elements in others.

  • Use Case Diagram (requirements) -> Sequence Diagram (scenario flow) -> Class Diagram (static structure).

  • A use case scenario (sequence) identifies the classes and messages needed, which are then formalized in the class diagram.

• Consistency: Changes in a behavioral model (e.g., a new message in a sequence diagram) must be reflected in the structural model (adding a method to the corresponding class).

[!TIP] Exam Focus: You must be able to draw and interpret a Class Diagram with at least 3 different relationships (e.g., Association, Inheritance, Dependency). Know the symbols for Aggregation vs. Composition.

IV. Object-Oriented Design (OOD)

Definition and Purpose:

• OOD is the process of creating an implementation-independent model of the system's solution structure, its components, and their interactions. It answers "How will the system be built?"

• It follows Object-Oriented Analysis (OOA), which focuses on understanding the problem domain ("What is the system?").

• Purpose: To transform the conceptual OOA model into a detailed, actionable blueprint for implementation.

OOD Process and Activities:

1. Apply Design Principles: Use SOLID (Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) and GRASP (General Responsibility Assignment Software Patterns) to assign responsibilities to classes.

2. Identify Classes & Responsibilities: Refine OOA model. Identify design classes (not just analysis classes), their attributes, and operations.

3. Design Collaborations: Determine which classes need to interact to fulfill responsibilities.

4. Create UML Design Models: Develop detailed Class Diagrams, Sequence Diagrams for key scenarios, and Package Diagrams for organization.

5. Package Design: Group related classes into packages/modules to manage complexity and define dependencies.

Translating OOD into Implementation:

1. Mapping Design to Language Constructs:

   • UML Class -> Programming language class.

   • UML Interface -> interface (Java) or abstract class with pure virtual functions (C++).

   • UML Association -> Member variable (reference/pointer) in the class.

   • UML Inheritance -> extends (Java) or : (C++) keyword.

   • UML Method -> Class member function/method.

2. Code Generation: Use CASE tools (e.g., Rational Rose, Enterprise Architect) for forward engineering (UML -> code) and reverse engineering (code -> UML).

3. Implementation Considerations:

   • Choose appropriate data structures and algorithms.

   • Handle error conditions and exceptions.

   • Ensure thread safety if needed.

   • Optimize for performance.

4. Round-Trip Engineering: The ability to synchronize changes between the UML model and source code bidirectionally.

[!TIP] Common Question: "Explain the process of translating OOD into implementation." Structure your answer: 1) Mapping rules (UML element -> code), 2) Tools (CASE), 3) Practical considerations, 4) Round-trip engineering.

V. Object-Oriented Programming Languages

Fundamental Characteristics:

1. Everything as Objects: Primitive data types may exist, but complex entities are objects.

2. Classes & Objects: Formal definition of object blueprints (classes) and their instances (objects).

3. Inheritance: Mechanism for defining new classes based on existing ones.

4. Polymorphism: Support for dynamic binding and method overriding.

5. Encapsulation: Access control mechanisms (private, public, etc.).

6. Message Passing: Objects communicate by sending messages (calling methods).

Comparison with Procedural and Functional Languages:

[!TIP] Key difference: OO bundles state + behavior; Procedural separates them; Functional avoids mutable state altogether.

VI. Object-Oriented Database Management Systems (OODBMS)

Query Languages for OODBMS:

• Designed to manipulate and retrieve persistent objects directly, without the need for impedance mismatch.

• Object Query Language (OQL): A standard, SQL-like language for OODBMS. It navigates object structures using path expressions.

  • Example: SELECT name FROM Employee WHERE worksIn.name = 'R&D'

  • Can query complex objects, follow relationships (like traversing a graph), and leverage inheritance (SELECT * FROM Person returns all Employee, Manager objects).

• Extensions of SQL (SQL3): Added object-oriented features (user-defined types, inheritance, reference types) to standard SQL.

Comparison with SQL in Relational Databases:

[!TIP] Impedance Mismatch: The fundamental conceptual gap between the object-oriented model (used in application code) and the relational model (used in RDBMS). OODBMS aims to eliminate this.

\boxed{\text{Core Exam Topics: OO Principles (4 pillars), UML Class Diagram (relationships), OO vs Procedural, OOD Process, OODBMS vs RDBMS}}