Note51

0.0 by Final Revision by ChatGPT

11 min read

📘 Section 1 (Chapter 1 + Cohesion & Coupling)

1. Fundamental Object-Oriented Concepts

1.1 Abstraction

  • Definition: The process of focusing on essential qualities of an object rather than the specific details.
  • Key idea: “What it does” rather than “How it does it.”
  • Example: A Car object exposes methods like startEngine() without revealing the internal combustion details.
  • Benefit: Simplifies complexity by hiding unnecessary details.

1.2 Encapsulation

  • Definition: Bundling of data (attributes) and behavior (methods) into a single unit (class), while restricting direct access to internal details.
  • Key idea: “Hide the implementation, expose the interface.”
  • Example: A BankAccount class hides its balance variable and only allows access via deposit() or withdraw().
  • Benefit: Protects integrity of data, reduces unintended interference.

1.3 Modularization

  • Definition: Breaking a complex system into smaller, manageable, independent modules.
  • Key idea: Divide and conquer.
  • Example: A university system split into modules: StudentManagement, CourseCatalog, Billing.
  • Benefit: Easier maintenance, testing, and reuse.

1.4 Hierarchy

  • Definition: Organizing system elements into levels of abstraction.
  • Key idea: “Is-a” and “part-of” relationships.
  • Example: Asset → BankAccount → SavingsAccount.
  • Benefit: Promotes clarity and reuse through structured organization.

1.5 Generalization

  • Definition: Extracting shared characteristics from multiple classes and combining them into a generalized superclass.
  • Key idea: “Is-a-kind-of” relationship.
  • Example: Employee generalized into FullTimeEmployee, PartTimeEmployee.
  • Benefit: Reduces redundancy, supports inheritance.

1.6 Inheritance

  • Definition: Mechanism where a subclass acquires attributes and behaviors of a superclass.
  • Key idea: Reuse and extend existing code.
  • Example: Doctor and Patient inherit from Person.
  • Types:
    • Single inheritance: subclass inherits from one superclass.
    • Multiple inheritance: subclass inherits from multiple superclasses (use with caution).
  • Benefit: Promotes reuse, but must avoid poor inheritance coupling.

1.7 Message Passing

  • Definition: Objects communicate by sending messages (method calls) to each other.
  • Key idea: Interaction between objects.
  • Example: Customer object sends placeOrder() message to Order object.
  • Benefit: Decouples objects, enabling modular design.

1.8 Polymorphism

  • Definition: The ability of different classes to respond to the same message in different ways.
  • Key idea: “One interface, many implementations.”
  • Example: calculatePay() behaves differently for FullTimeEmployee, PartTimeEmployee, ContractEmployee.
  • Benefit: Flexibility, extensibility, and cleaner code.

2. Coupling & Cohesion

2.1 Cohesion

  • Definition: The degree to which elements within a module/class belong together.
  • High cohesion: Each class/module has a single, well-defined responsibility.
  • Low cohesion: Class/module does many unrelated things.
  • Better: High cohesion is desirable.
  • Benefit: Improves readability, maintainability, and reusability.

2.2 Coupling

  • Definition: The degree of dependency between different modules/classes.
  • High coupling: Modules are heavily dependent on each other.
  • Low coupling: Modules are independent and interact through minimal, well-defined interfaces.
  • Better: Low coupling is desirable.
  • Benefit: Reduces ripple effects of changes, improves modularity.

2.3 Relationship Between the Two

  • Goal: Achieve high cohesion and low coupling.
  • Why: Together, they produce systems that are easier to maintain, extend, and reuse.
  • Mnemonic: “Strong inside, loose outside.”

📘 Section 2 (Chapter 2)

1. Traditional Waterfall Model

1.1 Definition

  • A sequential software development model where each phase must be completed before moving to the next.
  • Phases: System Engineering → Requirements Analysis → Design → Construction → Testing → Installation → Maintenance.

1.2 Strengths

  • Clear structure with defined deliverables at each stage.
  • Easier to manage specialized teams.
  • Strong emphasis on documentation and upfront requirements.
  • Good for projects with stable, well-understood requirements.

1.3 Weaknesses

  • Rigid: difficult to go back once a phase is complete.
  • Late discovery of flaws: testing happens at the end.
  • Poor adaptability to changing requirements.
  • Often results in poor user satisfaction if needs evolve.
  • Maintenance becomes costly.

2. Unified Software Development Process (USDP)

2.1 Definition

  • A generic, iterative, and incremental process framework for object-oriented development.
  • Embodies best practices to overcome waterfall’s weaknesses.

2.2 Four Phases

  1. Inception – Define scope, purpose, feasibility.
  2. Elaboration – Capture requirements, establish architecture.
  3. Construction – Build the system incrementally.
  4. Transition – Deploy, install, and roll out to users.

2.3 Core Workflows (RADIT)

  • Requirements – capture and model user needs.
  • Analysis – refine requirements into analysis models.
  • Design – define architecture, components, interfaces.
  • Implementation – coding, integration, component reuse.
  • Testing – verify system against requirements.

2.4 Best Practices

  • Develop iteratively – deliver in increments, refine with feedback.
  • Manage requirements – continuous user involvement.
  • Use component architectures – modular, reusable, extensible.
  • Model visually (UML) – diagrams for clarity.
  • Continuously verify quality – testing throughout, not just at the end.
  • Manage change – version control, adaptability.

2.5 Iterative & Incremental Development

  • Iterative: repeat workflows multiple times, refining system each cycle.
  • Incremental: each iteration delivers a working subset of the system.
  • Benefit: reduces risk, adapts to change, provides early user feedback.

3. Exam-Style Focus Areas

  • Compare Waterfall vs USDP (strengths, weaknesses, adaptability).
  • Identify USDP phases and their purposes.
  • Explain RADIT workflows.
  • Best practices: why they matter and how they reinforce each other.
  • Iterative vs Incremental: differences and benefits.
  • Deliverables at each stage (e.g., requirements spec, design models, test reports).

📘 Section 3 (Chapter 10 - 15)

1. Chapter 10 – Software Architecture

1.1 Definition

  • Software Architecture: Description of subsystems and components of a software system and their relationships.
  • It is an artifact of design, not just code.

1.2 Subsystems

  • Subsystem: Groups elements with common properties, encapsulating responsibilities.
  • Communication styles:
    • Client–Server: One subsystem provides services, the other consumes.
    • Peer-to-Peer: Subsystems depend on each other.
  • Advantages: Smaller units, reuse, maintainability, portability.

1.3 Layering & Partitioning

  • Layering: Organize by abstraction levels (e.g., UI → Logic → Data).
  • Partitioning: Organize by functionality (e.g., Billing, Campaign, HR).
  • Closed architecture: Only adjacent layers communicate (better encapsulation).
  • Open architecture: Any layer can call lower layers (faster, but less encapsulated).
  • OSI 7-layer model is a classic example.

1.4 MVC (Model–View–Controller)

  • Model: Core functionality, data.
  • View: Presentation to user.
  • Controller: Handles user input, updates model.
  • Propagation mechanism: Ensures views update when model changes.
  • Benefit: Separation of concerns, reuse, flexibility.

1.5 Three- and Four-Tier Architectures

  • Three-tier: Presentation, Logic, Data.
  • Four-tier: Adds Domain layer (shared across multiple apps).
  • Benefit: Scalability, maintainability, distribution.

2. Chapter 11 – System Architecture & Influences

2.1 Key Definitions

  • System: Set of components accomplishing functions.
  • Architecture: Fundamental organization of components and relationships.
  • Architectural View: Perspective of system (logical, process, deployment, etc.).
  • Viewpoint: Template for creating a view.

2.2 4+1 View Model (Kruchten)

  1. Use Case View – functional requirements.
  2. Logical View – design classes, interfaces.
  3. Implementation View – subsystems, components.
  4. Process View – processes, concurrency.
  5. Deployment View – physical nodes, communication.

2.3 Why Model Architecture?

  • Helps reason about quality attributes: performance, reliability, security.
  • Each view contributes differently (e.g., Process View → concurrency, Deployment View → distribution).

2.4 Influences on Architecture

  • Existing systems: heritage, adapters, reverse engineering.
  • Enterprise architectures: frameworks (Zachman, FEAF, TOGAF).
  • Technical reference architectures: standards, guidance.
  • Architectural styles: independent components, data flow, data-centered, virtual machine, call-and-return.

2.5 UML for Architecture

  • Package diagrams: group elements.
  • Component diagrams: physical artifacts (files, executables).
  • Deployment diagrams: nodes, devices, communication paths.

3. Chapter 12 – System Design

3.1 Analysis vs Design

  • Analysis: What the system must do.
  • Design: How the system will do it.
  • Example: Analysis says “Campaign has a title.” Design says “Title stored in DB, displayed on screen.”

3.2 Logical vs Physical Design

  • Logical: Platform-independent.
  • Physical: Platform-specific (e.g., Java vs C++).
  • MDA (Model Driven Architecture): PIM (platform-independent model) → PSM (platform-specific model).

3.3 System vs Detailed Design

  • System Design: High-level architecture, subsystems, processor allocation.
  • Detailed Design: Attributes, operations, UI classes, data management classes.

3.4 Qualities of Good Design

  • High cohesion, low coupling.
  • Other qualities: reusable, efficient, reliable, secure, maintainable, flexible.
  • Trade-offs: Functionality vs cost, reliability vs budget, flexibility vs complexity.

3.5 Coupling & Cohesion Types

  • Cohesion: Coincidental (worst) → Logical → Temporal → Sequential → Functional (best).
  • Coupling: Interaction coupling, inheritance coupling.
  • Goal: Strong cohesion, loose coupling.

3.6 Liskov Substitution Principle (LSP)

  • Derived objects should be usable as base objects without breaking integrity.
  • Violations occur when subclasses override behavior incorrectly.

4. Chapter 13 – Detailed Design

4.1 Class Design

  • Attributes: Declared with type, initial value, properties (e.g., {not null}).
  • Operations: Defined with signatures (name, parameters, return type).
  • Visibility: Public (+), Private (–), Protected (#), Package (~).

4.2 Interfaces

  • Define contracts (operations only).
  • Realization relationship: Class implements interface.

4.3 Associations

  • One-way vs two-way associations.
  • Collection classes: handle one-to-many relationships.
  • Many-to-many: resolved with collection/associative classes.

4.4 Integrity Constraints

  • Referential integrity: IDs must refer to existing objects.
  • Dependency constraints: attributes must remain consistent.
  • Domain integrity: attributes must hold valid values.

4.5 Designing Operations

  • Consider computational complexity, performance, flexibility, ease of implementation.

5. Chapter 14 – Data Management Design

5.1 Data Management Layer

  • Includes Data Access & Manipulation (DAM) logic and storage design.
  • Four-step approach:
    1. Select storage format.
    2. Map problem-domain objects to persistence format.
    3. Optimize storage.
    4. Design DAM classes.

5.2 Persistence Formats

  • Files: Sequential (good for reports), Random (good for updates).
  • Relational DBMS: tables, keys, referential integrity.
  • Object-relational DBMS: supports complex data.
  • Object-oriented DBMS: supports OO concepts directly.

5.3 Mapping Objects to RDBMS

  • Classes → tables.
  • Attributes → columns.
  • Associations → foreign keys.
  • Multi-valued attributes → new tables.
  • Inheritance → subclass shares primary key with superclass.

5.4 Normalization

  • 0NF → 1NF → 2NF → 3NF.
  • Goal: reduce redundancy, avoid anomalies.

5.5 DAM Classes

  • Act as translators between problem-domain objects and database.
  • One DAM class per problem-domain class.
  • Provide methods like ReadTable(), WriteTable().

6. Exam-Style Focus Areas (Chp 10–14)

  • Subsystems & communication styles (client-server vs peer-to-peer).
  • Layering: closed vs open, OSI model.
  • MVC architecture.
  • 4+1 views of architecture.
  • Influences on architecture (existing systems, enterprise frameworks, technical standards).
  • Coupling & cohesion: definitions, examples, which is better.
  • Liskov Substitution Principle.
  • System vs detailed design.
  • Integrity constraints.
  • Normalization levels.
  • DAM classes and their role.

🚀 OOAD Exam Cheat Sheet

1. Core OO Principles

  • Abstraction → Focus on what, not how. Hide details.
  • Encapsulation → Bundle data + behavior, hide implementation.
  • Modularity → Break system into manageable parts.
  • Hierarchy → Organize by levels of abstraction.
  • Generalization → Extract common features into superclass.
  • Inheritance → Subclass reuses/extends superclass.
  • Message Passing → Objects communicate via methods/messages.
  • Polymorphism → One interface, many implementations (e.g., calculatePay()).

2. Coupling & Cohesion

  • Cohesion = how focused a class/module is.
    • High cohesion = good (single responsibility).
  • Coupling = how dependent modules are.
    • Low coupling = good (independent, minimal dependencies).
  • Goal: High cohesion, Low coupling → maintainable, reusable, flexible.

3. Chapter 2 – USDP vs Waterfall

  • Waterfall: Sequential, rigid, late testing, poor adaptability.
  • USDP: Iterative + incremental, component-based, requirements-driven.
  • USDP Phases:
    1. Inception (scope, purpose)
    2. Elaboration (requirements, architecture)
    3. Construction (build incrementally)
    4. Transition (deploy, rollout)
  • Workflows (RADIT): Requirements, Analysis, Design, Implementation, Test.
  • Best Practices: Iterative dev, manage requirements, component architectures, UML modeling, continuous testing, manage change.

4. Chapter 10 – Software Architecture

  • Subsystems: Client–Server vs Peer-to-Peer.
  • Layering: Closed (strict, encapsulated) vs Open (flexible, less safe).
  • MVC: Model (data), View (UI), Controller (input).
  • 3-tier: Presentation, Logic, Data.
  • 4-tier: Adds Domain layer (shared logic).

5. Chapter 11 – System Architecture & Influences

  • 4+1 Views: Use Case, Logical, Implementation, Process, Deployment.
  • Why model? → Reason about performance, reliability, security.
  • Influences: Existing systems, enterprise frameworks (Zachman, TOGAF), technical standards.
  • Architectural styles: Independent components, Data flow, Data-centered, Virtual machine, Call-and-return.
  • UML Tools: Package diagrams, Component diagrams, Deployment diagrams.

6. Chapter 12 – System Design

  • Analysis vs Design: What vs How.
  • Logical vs Physical Design: Platform-independent vs platform-specific.
  • MDA: PIM → PSM.
  • System vs Detailed Design: High-level subsystems vs attributes/operations.
  • Qualities of good design: Reusable, efficient, reliable, secure, maintainable, flexible.
  • Trade-offs: Functionality vs cost, reliability vs budget.
  • LSP: Subclasses must behave like base class.

7. Chapter 13 – Detailed Design

  • Class design: Attributes (types, init values), Operations (signatures), Visibility (+, –, #, ~).
  • Interfaces: Define contracts, realized by classes.
  • Associations: One-way, two-way, many-to-many (use collection/associative classes).
  • Integrity constraints: Referential, Dependency, Domain.
  • Operation design: Consider complexity, performance, flexibility.

8. Chapter 14 – Data Management Design

  • Persistence formats: Files (sequential/random), RDBMS, Object-relational, OO DBMS.
  • Mapping to RDBMS: Classes → tables, Attributes → columns, Associations → foreign keys, Multi-valued → new tables, Inheritance → shared primary key.
  • Normalization: 0NF → 1NF → 2NF → 3NF (reduce redundancy).
  • DAM classes: One per domain class, translate between objects and DB.

🔑 Exam Hotspots

  • Define & compare OO principles (abstraction, encapsulation, etc.).
  • Coupling vs Cohesion: which is better and why.
  • Waterfall vs USDP: strengths, weaknesses, phases.
  • USDP best practices.
  • Subsystems & layering (closed vs open).
  • MVC architecture.
  • 4+1 views of architecture.
  • Liskov Substitution Principle.
  • Integrity constraints.
  • Normalization.
  • DAM classes role.

Graph View

Backlinks