Object Oriented Analysis and Design (IT-503 (C)) - Unit 5 Short Notes

UNIT 5: OBJECT-ORIENTED ANALYSIS AND DESIGN

I. Introduction to Modeling in OOAD

A model is an abstract representation of a system, built to understand, visualize, and communicate its structure and behavior before construction.

Purposes of Modeling:

• Communication: Common language for stakeholders (clients, analysts, developers).

• Documentation: Captures analysis and design decisions.

• Planning & Blueprint: Guides implementation and reduces complexity.

• Visualization: Makes abstract concepts concrete.

• Validation: Allows early detection of flaws and inconsistencies.

Why Modeling is Essential:

• Manages complexity by focusing on essential details.

• Reduces risk and cost by identifying issues early.

• Provides a shared understanding among team members.

• Facilitates maintenance and future enhancements.

Role of UML:

• Unified Modeling Language (UML) is the standard graphical notation for creating OO models.

• Provides a consistent set of diagram types and symbols.

• Enables clear, unambiguous communication of design.

Types of Models:

II. Core Object-Oriented Concepts

The object-oriented (OO) approach organizes software around "objects" (data + operations) rather than functions and logic.

Four Key Aspects:

1. Encapsulation: Bundling data (attributes) and methods (operations) that operate on the data into a single unit (class). Hides internal state through information hiding (public/protected/private visibility).

   \boxed{\text{Encapsulation} = \text{Data} + \text{Methods} + \text{Hiding}}

2. Inheritance: A mechanism where a new class (subclass/child) derives properties and behavior from an existing class (superclass/parent). Promotes code reuse and establishes hierarchical classification (generalization).

3. Polymorphism: "Many forms." The ability of different classes to respond to the same message (method call) in different ways. Achieved through method overriding (runtime) and overloading (compile-time).

4. Abstraction: Identifying essential characteristics of an object while ignoring irrelevant details. Defines a clear boundary and contract for an object.

III. Domain Modeling with UML Class Diagrams

A. Identifying Classes and Attributes

• Classes are identified from nouns/noun phrases in requirements (e.g., Customer, Order, Invoice).

• Attributes are properties of a class (e.g., Customer.name, Order.orderDate).

• Suitable Attribute Types:

  • Primitive Types: int, float, boolean, String.

  • Object Types: References to other classes (e.g., Order.customer: Customer). This creates an association.

  • Focus: Domain model attributes should be data-oriented (state), not behavioral. Operations are typically omitted in pure domain models.

B. Modeling Relationships

• Associations: Semantic relationships between classes (e.g., Customer places Order).

  • Multiplicity: Defines how many instances participate.

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

  • Role Names: Clarify the purpose (e.g., Customer---(places)--->Order).

• Generalization (Inheritance): "Is-a" relationship. Shown with a hollow triangle arrow pointing to the superclass.

  • Used when subclasses share common features but have specific variations.

C. Class Diagram Notation

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

|     ClassName     |

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

| - attribute1: Type|
| # attribute2: Type|
| + operation():Ret |

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

• Visibility Indicators: + (public), - (private), # (protected).

• Attributes: [visibility] name : type [multiplicity]

• Operations: [visibility] name (param-list) : return-type

IV. Behavioral Modeling: Use Case Diagrams

A. Purpose and Components

• Purpose: Capture functional requirements from a user's perspective. Shows system's external behavior.

• Components:

  • Actor: Role played by a user or external system (stick figure).

  • Use Case: A discrete unit of functionality that delivers value to an actor (oval).

  • System Boundary: Box enclosing all use cases, separating system from environment.

• Relationships:

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

  • Include (<<include>>): Mandatory sub-functionality (e.g., Register includes Validate Credit Card).

  • Extend (<<extend>>): Optional/conditional behavior (e.g., Buy Item extended by Apply Discount).

  • Generalization: Actor or use case inheritance (triangle arrow).

B. Drawing Use Case Diagrams: Online Shopping System Example

[Customer] ---> (Browse Catalog)

[Customer] ---> (Place Order) <<include>> (Make Payment)

[Customer] ---> (Track Order)

[Admin] ---> (Manage Inventory)

[Customer] ---> (Write Review) <<extend>> (Rate Product)

System Boundary: [Online Shopping System]

C. When to Use Use Case Diagrams

• Requirements Elicitation & Analysis.

• Stakeholder Communication (non-technical focus).

• Defining system scope.

• NOT for detailed design or internal logic.

V. Behavioral Modeling: Interaction Diagrams

A. Overview

• Show object interactions over time for a specific scenario (use case).

• Sequence Diagram: Emphasizes temporal ordering of messages (time axis top-to-bottom).

• Collaboration (Communication) Diagram: Emphasizes structural organization of objects (messages numbered for sequence).

B. Sequence Diagrams

• Notation:

  • Lifeline: Dashed vertical line (object's existence).

  • Activation Bar: Thin rectangle on lifeline (period of activity).

  • Message: Solid arrow (synchronous), dashed arrow (asynchronous).

  • Combined Fragments: alt (if/else), opt (option), loop (iteration), par (parallel).

• Example: Library Management (Issue/Renew Book)

  1. Member -> Librarian: issueBook(bookId)

  2. Librarian -> BookCatalog: findBook(bookId)

  3. BookCatalog --> Librarian: Book (return)

  4. Librarian -> MemberRecord: checkEligibility(memberId)

  5. Librarian -> LoanRecord: createLoan(...)

  6. Librarian --> Member: Book Issued

C. Collaboration Diagrams

• Notation: Objects as rectangles, links as solid lines, messages as numbered arrows with sequence:message format (e.g., 1: issueBook()).

• When to Use: When object structure is more important than precise timing. Often easier to draw for simple flows on a single page.

D. When to Use Interaction Diagrams

• Detailed Scenario Modeling (specific use case paths).

• Workflow Specification between objects.

• Identifying Responsibilities (methods needed on classes).

• NOT for overall system behavior (use use case diagrams).

VI. Behavioral Modeling: Activity Diagrams

A. Purpose and Notation

• Purpose: Model workflow of business processes or algorithmic logic. Shows parallel/concurrent activities.

• Notation:

  • Action: Rounded rectangle (atomic step).

  • Control Flow: Solid arrow (sequence).

  • Object Flow: Dotted arrow (object availability).

  • Decision/Merge Node: Diamond (branch/join based on guard [condition]).

  • Fork/Join Node: Thick bar (split/merge parallel flows).

  • Swimlanes: Partition for different responsibilities (e.g., User vs. System).

B. When NOT to Use Activity Diagrams

• Overly complex procedural logic (many branches/loops).

• Detailed step-by-step object interactions (use Sequence Diagrams).

• Simple linear flows (use text or pseudocode).

C. Alternative Diagrams

• Sequence Diagrams: For precise object message ordering.

• Use Case Diagrams: For high-level functional overview.

• State Machine Diagrams: For lifecycle of a single object.

VII. Structural Modeling: Additional Diagrams

A. Object Diagrams

• Purpose: Snapshot of object instances and their links at a specific moment. Concrete example of a class diagram.

• When to Use: Illustrating test scenarios, explaining complex structures, validating class diagram design.

• Notation: Same as class diagram, but with object names (objectName:ClassName) and attribute values.

B. Component Diagrams

• Purpose: Show organization and dependencies among software components (modular, replaceable parts).

• Notation:

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

  • Interface: Circle/ball (provided) or socket (required) labeled with interface name.

  • Dependency: Dashed arrow.

• Component Models:

  • CORBA (Common Object Request Broker Architecture): Middleware standard for distributed objects. Uses IDL (Interface Definition Language). Enables language- and location-transparent communication.

  • COM (Component Object Model) & DCOM (Distributed COM): Microsoft's binary standard for component interoperability. COM for single-machine, DCOM extends it for network distribution. Based on IUnknown interface (reference counting).

C. Deployment Diagrams

• Purpose: Model physical architecture – hardware nodes and software artifacts deployed on them.

• Notation:

  • Node: 3D box (e.g., [Server], [Mobile Device]).

  • Artifact: Rectangle with <<artifact>> and folded corner (e.g., main.exe, database.jar).

  • Communication Path: Solid line between nodes.

• Example: Banking Application

  
  [Client PC] --(HTTP)--> [Web Server]
  
  [Web Server] --(JDBC)--> [Database Server]
  
  [ATM] --(Secure Socket)--> [Transaction Server]
  
  

VIII. UML Notation Standards and Diagram Selection Guidelines

A. Detailed UML Notations (Key Symbols)

• Class: Rectangle with 3 compartments (name, attributes, operations).

• Association: Solid line, optional arrowhead (navigability).

• Aggregation: Hollow diamond (whole-part, weak ownership).

• Composition: Filled diamond (strong ownership, lifecycle dependency).

• Dependency: Dashed arrow (using relationship).

• Generalization: Hollow triangle arrow.

• Realization (Interface): Dashed hollow triangle arrow.

B. Guidelines for Selecting Appropriate Diagrams

IX. Design Refinement and Pitfalls

A. Common Errors from Rushing into Implementation

• Incomplete Analysis: Missed requirements, incorrect domain model.

• Poor Class Design: God classes (too many responsibilities), anemic classes (data-only), inappropriate inheritance.

• Tight Coupling: Classes depend heavily on each other's internals, reducing reusability and maintainability.

• Leaky Abstractions: Exposing internal details, breaking encapsulation.

B. Criteria for Eliminating Classes, Associations, Generalizations

• Necessity: Is it directly required by a use case or essential to the domain?

• Cohesion: Does the class have a single, well-defined responsibility? (High cohesion = keep)

• Coupling: Does removing it reduce dependencies between remaining classes? (Low coupling = good)

• Alignment: Does it accurately reflect the problem domain? Remove "implementation-driven" or "redundant" elements.

• Generalization: Keep only if subclasses have significant specific attributes/operations and the superclass is meaningfully abstract.

C. Practical Considerations in Model Simplification

• Balance Detail vs. Clarity: Include only what's necessary for the current purpose.

• Avoid Over-Engineering: Don't model for hypothetical future needs (YAGNI - You Aren't Gonna Need It).

• Iterative Refinement: Start simple, add detail as understanding deepens.

• Validate with Stakeholders: Ensure model matches reality and requirements.

X. User Interface Design in OO Context

A. Designing User Interfaces for Systems

• Principles: Consistency, feedback, simplicity, error prevention, user control.

• OO Context: UI elements (windows, buttons) can be modeled as objects with state and behavior.

• Patterns: Model-View-Controller (MVC) separates data (model), UI (view), and logic (controller).

B. Linking UI Design to Use Cases and Interaction Diagrams

1. From Use Cases: Identify all user-system interactions (each "step" in a use case suggests a UI screen/component).

2. From Interaction Diagrams: The sequence of messages between User (actor) and System objects maps directly to UI navigation and screen flows.

3. Result: A storyboard or navigation flow diagram linking screens.

C. Example: UI Design for an ATM Banking System

• Key Screens (Objects): CardReaderScreen, PinEntryScreen, MainMenuScreen, WithdrawalScreen, BalanceScreen, ReceiptScreen.

• Flow from Use Case "Withdraw Cash":

  1. CardReaderScreen -> User: "Insert Card"

  2. User -> PinEntryScreen: Enters PIN

  3. PinEntryScreen -> System: validatePIN()

  4. System -> MainMenuScreen: Displays options

  5. User selects "Withdraw" -> WithdrawalScreen

  6. User enters amount -> System processes -> ReceiptScreen

• Diagrammatic Representation: A storyboard showing screen mockups with arrows indicating navigation paths based on user actions and system responses. Alternatively, a high-level activity diagram with swimlanes for User and ATM System showing screen transitions.

Exam Tip: For UI design questions, sketch the key screens and draw arrows showing the flow between them, referencing the relevant use case steps. Mention how it maps to the interaction diagram.