UNIT 1: Introduction to Object-Oriented Analysis and Design

1. Fundamentals of Modeling

What is a Model?

A model is an abstract representation of a system or concept, built to understand, visualize, or communicate aspects of that system before building it. It simplifies reality by focusing on essential features while hiding unnecessary details.

Purposes of Modeling (Frequently Examined)

[!TIP] Exam Focus: Always list at least 4–5 purposes. "Communication" and "Complexity Management" are most commonly cited.

Why Modeling is Required in Analysis & Design?

• Analysis Phase: Models help understand the problem domain, capture requirements, and establish a shared vision.

• Design Phase: Models guide the technical blueprint, ensuring the solution is structured, reusable, and maintainable.

• Avoids Implementation Rush: Direct coding without models leads to structural flaws, missed requirements, and high change costs.

Object-Oriented Approach: Definition & Four Key Aspects

The object-oriented (OO) approach views a system as a collection of interacting objects, each with its own state and behavior.

Role of UML in Preparing Models

UML (Unified Modeling Language) is a standardized graphical language for visualizing, specifying, constructing, and documenting OO software artifacts. It provides:

• A common notation for all stakeholders.

• A suite of diagram types for different perspectives (structure, behavior, architecture).

• Tool support for model creation, validation, and code generation.

2. UML Overview

Introduction to UML

• Purpose: To standardize modeling notations and practices for OO systems.

• History: Merged notations from Booch, OMT, and OOSE in the 1990s; now maintained by the Object Management Group (OMG).

Classification of UML Diagrams

UML 2.x diagrams are broadly classified into:

[!NOTE] Component and Deployment diagrams are also considered architectural diagrams.

Purpose of Each Diagram Type (Frequently Examined)

UML Notations (Frequently Examined)

Common symbols and conventions:

[!TIP] Multiplicity Cheat Sheet: 0..1 (optional), 1 (exactly one), * (many), 1..* (at least one), 0..* (zero or more).

3. Use Case Modeling (Frequently Examined)

Use Case Diagram Components

1. Actor: Role played by a user or external system (stick figure). Not necessarily a person.

2. Use Case: Oval representing a discrete unit of functionality that delivers value to an actor.

3. System Boundary: Box enclosing all use cases; defines system scope.

4. Relationships:

   • Association: Solid line connecting actor to use case (actor participates).

   • Include: Dashed arrow with <<include>>; mandatory sub-function.

   • Extend: Dashed arrow with <<extend>>; optional/conditional extension.

   • Generalization: Solid line with hollow arrow; inheritance between actors or use cases.

Identifying Actors & Use Cases

• Actors: Ask "Who uses the system?" or "What external systems interact?" (e.g., Customer, Admin, Payment Gateway).

• Use Cases: Ask "What tasks does each actor perform?" (e.g., Place Order, Make Payment, Generate Report).

Example: Online Shopping System

4. Domain Modeling (Frequently Examined)

Domain Model Concepts

• Entity Class: Represents a fundamental, long-lived concept in the domain (e.g., Customer, Order). Has a unique identity (ID).

• Value Class: Represents a descriptive property or measure (e.g., Money, Address). Defined by its attributes, not identity. Often modeled as attributes or separate classes if complex.

Attributes: Suitable Attribute Types

Focus on data type attributes:

[!TIP] Use complex types when the property has its own attributes/behavior (e.g., Money has amount and currency).

Associations (Frequently Examined)

An association represents a structural relationship between classes.

• Identifying: Look for verbs in requirements ("orders have items", "customer places order").

• Multiplicity: Specify how many instances participate (1, 0..1, 1..*, *).

• Navigability: Arrow indicates direction of traversal (optional; often bidirectional).

• Association Class: If the association itself has attributes (e.g., OrderItem with quantity and price), model it as a class attached to the association.

Example: Customer — places — Order

Multiplicity: Customer 1 —— 0..* Order (one customer places zero or more orders).

Generalizations (Frequently Examined)

Super-sub class (inheritance) relationship.

• Identify: "Is-a" relationship. E.g., Payment is a superclass; CreditCardPayment, PayPalPayment are subclasses.

• UML Notation: Solid line with hollow arrow pointing to superclass.

• When to use: When subclasses share common attributes/operations but have specialized variations.

Domain Model vs. Design Model

Common Errors When Rushing to Implementation

1. Turning every noun into a class → bloated, irrelevant classes.

2. Missing associations → isolated classes, no connectivity.

3. Overusing inheritance → deep hierarchies, fragile base class problem.

4. Ignoring multiplicities → ambiguous relationships.

5. Adding design details prematurely (e.g., databases, UI controls) → domain model becomes implementation-specific.

Deciding Which Classes/Associations/Generalizations to Eliminate

• Eliminate classes that:

  • Represent transient values (model as attributes instead).

  • Have no meaningful responsibilities or attributes.

  • Are purely implementation artifacts (defer to design).

• Simplify associations by:

  • Removing unnecessary navigability arrows.

  • Reducing multiplicity to simplest valid form.

  • Merging weak associations into attributes.

• Prune generalizations if:

  • Subclasses differ only by data (use attributes instead).

  • Inheritance violates Liskov Substitution Principle.

  • Only one or two subclasses exist (consider flattening).

5. Transition from Analysis to Design

From Domain Model to Design Model

1. Refine Classes: Add operations (methods) based on required behavior. Define visibility (+ public, - private, # protected).

2. Add Design Elements:

   • Controllers/Facades: Handle use case logic (e.g., OrderController).

   • Interfaces: Define contracts for services (e.g., PaymentProcessor).

   • Data Access Objects (DAOs): Isolate persistence logic.

3. Eliminate Analysis-Only Elements: Remove vague business terms not needed in software (e.g., Customer might stay, but BusinessRule might become a method).

4. Optimize Associations: Convert bidirectional to unidirectional if navigation is one-way; introduce indirection (e.g., Order → CustomerDAO instead of direct link).

5. Apply Design Patterns: Where appropriate (e.g., Strategy for payment algorithms, Observer for notifications).

[!TIP] The design model should be implementation-ready but still language-agnostic (UML level).

6. Interaction Diagrams (Highly Frequently Examined)

Sequence Diagrams (Highly Frequently Examined)

Purpose: Model the time-ordered sequence of messages between objects for a specific scenario (use case or operation).

Elements:

• Lifeline: Dashed vertical line; represents an individual participant (object/class instance) over time.

• Activation Bar: Thin rectangle on lifeline; shows period an object is performing an action.

• Message: Horizontal arrow between lifelines; synchronous (solid arrowhead, caller waits) or asynchronous (stick arrowhead, caller continues).

• Self-Message: Message arrow looping back to same lifeline (recursion or internal processing).

• Destroy: X at end of lifeline; object is deleted.

• Frame: Rectangle around diagram; may have name and fragment type (alt, loop, opt).

Creation Steps:

1. Identify scenario (e.g., "withdraw cash" in ATM).

2. List participating objects (actors + system objects).

3. Arrange lifelines vertically (time flows downward).

4. Add messages in chronological order from top to bottom.

5. Use frames for conditional/iterative logic.

Example: Library Management (Issue/Renew Book)

Collaboration Diagrams (Communication Diagrams)

Purpose: Emphasize structural organization of objects and their links; messages are numbered for sequence.

Elements:

• Links: Solid lines connecting objects (like associations).

• Numbered Messages: 1., 2., etc., near link; sequence indicated by numbering (can have 1a, 1b for concurrent).

• Object Boxes: Same as sequence diagram lifeline headers (object:Class).

Key Difference from Sequence: Collaboration diagrams focus on object relationships; sequence diagrams focus on time ordering. Sequence is better for complex timing; collaboration for simpler scenarios with many objects.

Comparison: Sequence vs. Collaboration Diagrams (Frequently Examined)

[!TIP] When to use which? Use sequence for detailed algorithmic flow or real-time constraints. Use communication for overview of object collaborations in a single scenario.

When to Use Interaction Diagrams vs. Activity Diagrams

• Interaction Diagrams (Sequence/Communication): Model object-to-object interactions for a specific scenario. Who talks to whom, and in what order?

• Activity Diagrams: Model workflow or business process across multiple actors/systems. What are the steps, decisions, and parallel flows? Use when you need to show branching, merging, or parallel activities not tied to specific objects.

7. Activity Diagrams

Purpose

Model:

• Business processes or workflows.

• Algorithm logic (especially complex control flow).

• Parallel/concurrent activities.

Notation

• Action: Rounded rectangle; atomic step.

• Decision Node: Diamond; branches based on guard condition [condition].

• Merge Node: Diamond; combines alternative flows.

• Fork Node: Thick bar; splits into parallel flows.

• Join Node: Thick bar; synchronizes parallel flows.

• Swimlane: Vertical/horizontal partition; groups actions by responsible actor or class.

• Start/End: Solid circle / bullseye.

When NOT to Use Activity Diagrams (Frequently Examined)

Practical Situations for Other Diagrams

• Use Case Diagram: During requirements gathering to outline system scope and user roles.

• Object Diagram: To illustrate a complex data structure or debug a specific runtime state.

• Interaction Diagram: To detail how a use case is realized through object collaborations (design phase).

8. Structural Diagrams (Advanced)

Class Diagrams (Design-Level)

Recap from domain model, but at design level:

• Add operations (methods) with parameters.

• Specify visibility (+ public, - private, # protected).

• Include design patterns (e.g., <<interface>> stereotype).

• May show inner classes, templates (generics).

Object Diagrams (Frequently Examined)

• Purpose: Show a snapshot of instances (objects) and their links at a specific moment. Like a "running" class diagram.

• Notation: Object boxes: objectName:ClassName (e.g., c1:Customer). Links are instances of associations.

• When to Use:

  • To illustrate complex data structures (e.g., linked list, tree).

  • To provide a concrete example of a class diagram.

  • For debugging or explaining a particular runtime scenario.

  • Not for overall system design; only for representative snapshots.

Component Diagrams (Frequently Examined)

• Purpose: Show physical, replaceable parts (components) of a system and their interfaces/dependencies.

• Elements:

  • Component: Rectangle with <<component>> stereotype and small "plug" icon.

  • Interface: Circle or rectangle with <<interface>>; lollipop (provided) or socket (required) notation.

  • Dependency: Dashed arrow from client to supplier.

• Component Models (Frequently Examined):

  • CORBA (Common Object Request Broker Architecture): OMG standard for distributed objects. Uses IDL (Interface Definition Language), ORB (Object Request Broker) for language-agnostic communication.

  • COM (Component Object Model): Microsoft technology for binary software components. Uses GUIDs, registry, IUnknown interface. Language-independent on Windows.

  • DCOM (Distributed COM): Extension of COM for network distribution; uses RPC (Remote Procedure Call).

Deployment Diagrams (Frequently Examined)

• Purpose: Show physical arrangement of hardware nodes and software artifacts (executables, libraries, configurations).

• Elements:

  • Node: 3D box; represents hardware or software execution environment (e.g., Server, Client PC).

  • Artifact: Rectangle with <<artifact>> and folded corner icon (e.g., app.exe, config.xml).

  • Communication Path: Line between nodes; may show protocol (e.g., HTTP, TCP/IP).

• Example: Banking Application

  • Nodes: Web Server, Application Server, Database Server, ATM Client.

  • Artifacts: banking.war on Web Server, banking.jar on App Server, banking.db on DB Server.

  • Paths: ATM Client ↔ Web Server (HTTPS), Web Server → App Server (RMI), App Server ↔ Database Server (JDBC).

9. User Interface Design

Designing UIs in OO Context

• Model-View-Controller (MVC): Separate UI (View) from business logic (Model) and input handling (Controller).

• OO Principles: Encapsulate UI components as objects; use inheritance for common widgets (e.g., Button → RoundButton).

• Patterns: Observer (for event handling), Composite (for nested UI containers).

Principles for ATM UI Design

1. Simplicity: Minimal steps for common tasks (withdraw, balance inquiry).

2. Consistency: Standard button placements, prompts, and error messages.

3. Feedback: Clear responses for every action (e.g., "Please wait...", "Transaction complete").

4. Error Handling: Graceful recovery from invalid inputs (e.g., wrong PIN).

5. Security: Hide sensitive data (mask PIN), auto-logout after inactivity.

6. Accessibility: Large buttons, audio options, clear contrast.

Example ATM Screen Flow:

[Insert Card] → [Enter PIN] → [Main Menu]

Main Menu: [Withdraw] [Balance] [Deposit] [Exit]

Withdraw: [Enter Amount] → [Confirm] → [Dispense Cash] → [Receipt?] → [Take Card]

10. UML Notations Summary

[!TIP] Multiplicity Quick Reference:

0..1 = optional, single

1 = exactly one

* or 0..* = zero or more

1..* = one or more

n..m = between n and m (inclusive)

Final Exam Strategy:

1. Memorize diagram purposes (Why use sequence vs. activity?).

2. Practice drawing use case, class (domain), sequence diagrams from scenarios.

3. Distinguish analysis vs. design models clearly.

4. Learn UML notation for multiplicities, relationships, and diagram elements.

5. Compare sequence/collaboration and when not to use activity—these are high-frequency questions.