UNIT 4: Object-Oriented Analysis and Design

I. FOUNDATIONAL CONCEPTS OF MODELING & OO APPROACH

What is a Model?

A model is a simplified, abstract representation of a complex system, created to understand, visualize, specify, or document aspects of that system before construction.

Purposes of Modeling:

• Visualization: To see the system's structure and behavior.

• Specification: To precisely define the system's architecture and components.

• Construction: To serve as a blueprint for generating code and artifacts.

• Documentation: To provide persistent records for maintenance and knowledge transfer.

[!TIP] Exam Focus: Questions often ask for purposes. List all four clearly with a one-line explanation for each.

Object-Oriented Approach

The core philosophy is to model a system as a collection of cooperating objects, where each object is an instance of a class and has its own state and behavior.

Four Fundamental Aspects:

1. Things: Objects (instances) and Classes (templates) representing the primary elements in the model.

2. Relationships: Connections between things (e.g., Association, Generalization, Dependency).

3. Diagrams: Graphical notations (UML diagrams) to visualize the things and relationships from different viewpoints.

4. Language-Independent: The concepts and diagrams are not tied to any specific programming language.

Domain Modeling & Attribute Types

A domain model identifies the key conceptual classes and their relationships within the problem domain, before considering software implementation.

Suitable Attribute Types:

• Primitive Types: int, float, String, boolean. Represent basic data.

• Enumerated Types: A predefined set of named constants (e.g., enum OrderStatus { PENDING, SHIPPED, DELIVERED }).

• Value Objects: Objects defined by their attributes, not identity (e.g., Date, Money). They are immutable and often modeled as attributes of other classes.

II. ROLE OF UML & TYPES OF MODELS

Need for Modeling in Analysis & Design

Rushing into implementation without modeling leads to:

• Architectural flaws discovered late.

• Misunderstood requirements and missing functionality.

• Poor communication among stakeholders.

• Difficult maintenance due to lack of clear structure.

• Costly rework as changes propagate through code.

Criteria for Simplifying Models (Eliminating Elements):

• Necessity: Is the class/association directly required to meet the core requirements?

• Relevance: Does it represent a fundamental concept in the problem domain?

• Stability: Is it likely to change frequently? (Prefer stable, central concepts).

• Duplication: Can it be derived from or merged with another existing element?

Unified Modeling Language (UML)

UML is a standardized graphical language for visualizing, specifying, constructing, and documenting software system artifacts.

UML Diagram Categories & Primary Purpose:

[!TIP] Common Pitfall: Confusing Activity (workflow) with State Machine (state changes). Activity models processes; State Machine models lifecycle of a single object.

III. STRUCTURAL DIAGRAMS (STATIC VIEW)

Class Diagram

The foundation of OO design. Shows system's classes, their attributes, operations, and relationships.

Notation:

• Class: Rectangle with three compartments: Name, Attributes, Operations.

• Association: Line connecting classes. May have role names and multiplicity.

• Multiplicity: 1, 0..1, 1..*, *, m..n (defines cardinality).

• Navigability: Arrowhead on association line (unidirectional vs. bidirectional).

• Generalization (Inheritance): Solid line with a hollow triangle arrowhead pointing to the superclass.

• Aggregation (Whole-Part, shared): Hollow diamond on the whole side.

• Composition (Strong ownership, lifecycle dependency): Filled diamond on the whole side.

Identifying from Requirements:

• Associations: Look for noun phrases that imply a relationship (e.g., "Customer places Order" → Customer--places-->Order).

• Generalization: Look for "is-a" or "kind-of" relationships (e.g., "Savings Account is a Account").

Object Diagram

A snapshot of instances (objects) and their links at a specific point in time. Shows concrete examples of the structures defined in a class diagram.

When to use: To illustrate complex data structures, test class diagram rules, or provide a concrete example for understanding.

Component Diagram

Models physical, replaceable parts of a system (e.g., libraries, executables, files) and their dependencies.

Notation:

• Component: Rectangle with a small "plug" icon (<<component>> stereotype).

• Provided Interface: Lollipop (ball) symbol—what the component offers.

• Required Interface: Socket symbol—what the component needs.

• Dependency: Dashed arrow from client to supplier.

Detailed Study: Component Models

• CORBA (Common Object Request Broker Architecture): A vendor-neutral, language-independent standard for distributed objects. Uses an ORB (Object Request Broker) as a middleware "bus" for communication.

• COM (Component Object Model) / DCOM (Distributed COM): Microsoft's binary standard for component interoperability. COM is for in-process; DCOM extends it for network communication using RPC.

Deployment Diagram

Models the physical architecture—hardware nodes (devices, servers) and the software artifacts (executables, libraries, configuration files) deployed on them.

Notation:

• Node: 3D box labeled with its name (e.g., [Web Server]).

• Artifact: Rectangle with a folded corner (<<artifact>> stereotype), placed inside or connected to a node.

• Communication Path: Line between nodes, labeled with the communication protocol (e.g., HTTP, TCP/IP).

Practical Application (Banking):

[Client PC] --(HTTPS)--> [Web Server] --(JDBC)--> [Database Server]

   |                          |

[Browser]               [Web App.war]

IV. BEHAVIORAL DIAGRAMS (DYNAMIC VIEW)

Use Case Diagram

Captures functional requirements from an actor's (user or external system) perspective. Shows system's functionality and its external interactors.

Notation:

• Actor: Stick figure (human) or box (external system).

• Use Case: Oval with a verb phrase (e.g., "Withdraw Cash").

• System Boundary: Box surrounding all use cases.

• Association: Solid line connecting actor to the use cases they initiate.

• Include: Dashed arrow with <<include>>—mandatory sub-functionality (e.g., "Withdraw Cash" includes "Authenticate User").

• Extend: Dashed arrow with <<extend>>—optional/conditional behavior (e.g., "Withdraw Cash" extended by "Print Receipt" at point of extension).

Practical Application: Online Shopping System

Actors: Customer, Admin, Payment Gateway

Use Cases: Browse Catalog, Add to Cart, Checkout, Manage Inventory, Process Payment

Relationships: Checkout <<include>> Authenticate; Checkout <<extend>> Apply Discount

Sequence Diagram

Models interactions over time between objects/parts for a specific scenario. Emphasizes time ordering of messages.

Notation:

• Lifeline: Dashed vertical line for an object/part.

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

• Synchronous Message: Solid line with filled arrowhead (caller waits).

• Asynchronous Message: Solid line with stick arrowhead (caller continues).

• Return Message: Dashed line with open arrowhead (optional).

• Destruction: 'X' at end of lifeline.

Practical Application: Library Management (Issue/Renew Book)

1. Member → System: issueBook(bookId)

2. System → Book: isAvailable()

3. System → MemberAccount: checkFines()

4. System → LoanRecord: createLoan(member, book, date)

5. System → Book: setStatus(LOANED)

6. System → Member: showDueDate(dueDate)

Interaction/Communication Diagram (Collaboration Diagram)

Models interactions focusing on the structural organization of objects and the links between them. Message sequence is indicated by numbered messages.

Comparison: Sequence vs. Communication Diagram

Practical Application: ATM Card-Based Banking

Shows objects: CardReader, Keypad, Screen, Customer, Account, BankServer. Links: Customer--insertsCard-->CardReader. Messages numbered: 1: insertCard(), 2: readCard(), 3: requestPIN(), etc.

Activity Diagram

Models workflow, business process, or operational logic. Good for modeling parallel behavior and algorithmic flows.

Notation:

• Action: Rounded rectangle (work performed).

• Initial Node: Filled circle.

• Final Node: Bullseye (filled circle with ring).

• Decision/Merge: Diamond (branching/joining).

• Fork/Join: Thick horizontal/vertical line (splits/merges parallel flows).

• Swimlane: Partitioned areas to group actions by responsible actor/object.

Critical Application Guidance:

• DO NOT USE for: Modeling detailed logic within a single operation or complex conditional logic of an object's behavior.

• PREFER instead: Sequence Diagram for detailed message flow, State Machine Diagram for state-dependent behavior.

• Use for: High-level business workflows, use case scenarios, parallel processes.

State Machine Diagram

Models the discrete state changes of a single object (or system) throughout its lifecycle in response to events.

Notation:

• State: Rounded rectangle.

• Initial State: Filled circle.

• Final State: Bullseye.

• Transition: Arrow from source state to target state, labeled event [guard] / action.

• Composite State: State with nested substates.

• Concurrent Regions: Split state into parallel regions (using fork/join lines).

V. DIAGRAM SELECTION, NOTATION & PRACTICAL DESIGN

Guidelines for Diagram Selection

Comprehensive UML Notation Review

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

• Static/Class: Underlined name.

• Abstract: Italic name or {abstract}.

• Multiplicity: 1, 0..1, *, 1..*, m..n.

• Dependency: Dashed arrow (uses, calls, depends).

• Realization: Dashed line with hollow triangle (interface implementation).

User Interface Design & Modeling (ATM Example)

Design screens: Welcome Screen → Card Entry → PIN Entry → Main Menu → Withdraw/Balance/.... Modeling Link: Each screen transition corresponds to a use case or part of an interaction. The UI flow can be modeled with an Activity Diagram (swimlanes for UI vs. Backend). The backend logic triggered by "Withdraw" is modeled with a Sequence Diagram.

Integrated System Modeling (Banking Application)

1. Use Case Diagram: Defines functional requirements (e.g., Transfer Funds, View Statement).

2. Sequence Diagrams: Detail the object interactions for each key use case.

3. Class Diagrams: Define the static structure (classes like Account, Transaction).

4. Component Diagram: Shows software components (AccountManager.jar, TransactionService.dll) and their interfaces.

5. Deployment Diagram: Maps components to physical nodes:

   
   [Client PC] --(HTTPS)--> [Load Balancer] --(RMI)--> [App Server Cluster]
   
                                         |
   
                                     [Database Server]
   
   

   The deployment diagram physically realizes the interactions defined in the sequence diagrams.

VI. EXAMINATION FOCUS & HIGH-YIELD TOPICS

Diagram Drawing & Interpretation (Highest Frequency)

• Use Case: Be precise with actors, system boundary, <<include>>/<<extend>>. Online Shopping is a classic.

• Sequence/Interaction: Show lifelines, clear message numbering (for Comm.), activation bars (for Sequence). Library Issue/Renew and ATM are common.

• Component/Deployment: Know notation for interfaces (lollipop/socket), nodes, artifacts. Banking app deployment is typical.

Conceptual Explanations & Comparisons

• Sequence vs. Collaboration/Communication: Focus on time vs. structure.

• Activity vs. State Machine: Focus on workflow/process vs. object lifecycle.

• Aggregation vs. Composition: Focus on shared vs. strong lifecycle ownership (filled vs. hollow diamond).

• Structural vs. Behavioral Diagrams: Static structure vs. dynamic behavior.

Application-Oriented Questions

• Identifying Model Elements: From a problem description ("A Professor teaches many Courses..."), identify the Association (Professor--teaches--Course) and its multiplicity (1 Professor to * many Courses).

• Choosing Diagram Type: Given a scenario ("Show the steps a user follows to reset a password"), choose Activity Diagram or Use Case (depending on level).

• Component Models: Be able to define CORBA (ORB-based, language-neutral) and COM/DCOM (Microsoft, binary standard, in-process vs. distributed).

Design Judgment

• Consequences of No Modeling: Unmaintainable code, missed requirements, integration nightmares.

• Elimination Criteria: Answer using the Necessity, Relevance, Stability, Duplication framework.

[!TIP] Final Exam Strategy: When asked to draw a diagram, first identify the diagram type from the question's keywords (e.g., "over time" → Sequence; "workflow" → Activity; "physical parts" → Deployment). Then, list all key elements (actors, classes, messages) before drawing. Always draw neatly and label everything.