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

UNIT 3: Object-Oriented Analysis and Design

I. Fundamentals of Modeling and Object-Oriented Approach

What is a Model?

• Definition: A model is an abstraction of a real-world system or phenomenon. It is a simplified representation that focuses on essential aspects while ignoring irrelevant details.

• Purposes of Modeling:

  • Abstraction: Manage complexity by hiding unnecessary details.

  • Communication: Provide a common visual language for stakeholders (analysts, designers, developers, clients).

  • Documentation: Create artifacts that describe the system's structure and behavior.

  • Analysis & Prediction: Explore "what-if" scenarios and understand system properties before construction.

  • Blueprint: Serve as a plan for implementation.

[!TIP] Exam Focus: Be ready to list at least 4 purposes of modeling. A model is not the final system; it's a representation.

Object-Oriented Approach

• Core Meaning: A paradigm that structures a system as a collection of objects—self-contained entities that combine data (state) and procedures (behavior) that operate on that data.

• Four Fundamental Aspects:

  1. Objects: Basic runtime entities.

  2. Classes: Blueprints/templates for creating objects.

  3. Inheritance: Mechanism for creating new classes (subclasses) from existing ones (superclasses), promoting reuse.

  4. Polymorphism: Ability of different objects to respond to the same message (method call) in different ways (e.g., method overriding).

Analysis vs. Design

• Risks of Rushing Implementation: Leads to building the wrong system, incorrect class/association choices, high rework cost, and a system that is difficult to maintain or extend.

• Criteria for Elimination (Refinement):

  • Classes: Eliminate if they have no persistent data, no significant behavior, or are merely redundant descriptors.

  • Associations: Remove if they are weak, implied by other relationships, or do not represent a fundamental, lasting connection.

  • Generalizations: Discard if the subclasses do not have significant, unique attributes/operations or if the hierarchy is artificial.

Domain Modeling

• Suitable Attribute Types: Focus on data type attributes (e.g., String name, int accountNumber, Date birthDate).

• Focus on Data Type Attributes: Domain models describe the problem space, not solutions. They capture nouns (concepts) and their characteristics (attributes). Avoid including implementation-specific types (like ArrayList) or behavioral methods.

II. Unified Modeling Language (UML) Overview

Role of UML in Modeling

• Purpose: UML is a standardized graphical language for visualizing, specifying, constructing, and documenting the artifacts of an object-oriented system.

• Significance: Provides a common, unambiguous notation for all stakeholders, enabling consistent communication and modeling across the software lifecycle.

Types of UML Models

UML Notations and Diagram Types (UML 2.x)

• Structural Diagrams: Class, Object, Component, Deployment, Package, Composite Structure.

• Behavioral Diagrams: Use Case, Activity, Sequence, Communication (formerly Collaboration), Interaction Overview, Timing, State Machine.

• Common Notations: Rectangles (classes/components), ovals (use cases), stick figures (actors), diamonds (aggregation/composition), arrows (associations/dependencies), lifelines and messages (interaction).

III. Structural Modeling

Class Diagrams

• Identifying Classes: Find nouns and noun phrases in requirements (e.g., "Customer," "Order," "Payment").

• Associations & Multiplicities: Model meaningful, lasting relationships between classes. Multiplicity defines how many: 1, 0..1, *, 1..*.

  • Example: Customer "places" 0..* Order.

• Super-Sub Class (Generalization): Identify inheritance hierarchies. Look for "is-a" relationships and shared attributes/operations.

  • Example: SavingsAccount is-a BankAccount.

• Attribute Visibility & Operations: Use + (public), - (private), # (protected). Operations are listed as name(parameters): returnType.

• Refining Class Diagrams:

  1. Remove redundant classes (e.g., a class that is just an attribute).

  2. Remove weak or derived associations (can be calculated).

  3. Simplify generalization hierarchies if artificial.

  4. Ensure all classes have a clear purpose.

Object Diagrams

• Purpose: Show a snapshot of instances (objects) and their links at a specific point in time. Useful for illustrating concrete examples of a class diagram.

• Notation: Similar to class diagrams but with object names underlined (customer1: Customer) and links (solid lines) instead of associations.

• Difference from Class Diagram: Class diagram is the template (abstract); object diagram is a specific instance (concrete).

IV. Behavioral Modeling

Use Case Diagrams

• Elements:

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

  • Use Case: A discrete, meaningful unit of functionality (oval).

  • System Boundary: Box containing all use cases.

• Relationships:

  • Association: Solid line between actor and use case.

  • Include (<<include>>): Mandatory sub-functionality (e.g., "Login" included in "Buy Item").

  • Extend (<<extend>>): Optional/conditional behavior (e.g., "Apply Discount" extends "Checkout").

  • Generalization: Actor or use case inheritance.

• Identifying Use Cases: Find verb phrases describing user goals (e.g., "Search Catalog," "Place Order").

• Example: Online Shopping System

  • Actors: Customer, Guest, Payment Gateway, Shipping System.

  • Use Cases: Browse Products, Add to Cart, Checkout, Process Payment, Track Shipment.

  • Checkout includes Validate Cart; Checkout extends Apply Coupon.

Interaction Diagrams

• Sequence Diagrams

  • Purpose: Model time-ordered interactions between objects for a specific scenario.

  • Notation:

    • Lifeline: Vertical dashed line for an object/participant.

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

    • Message: Horizontal arrow between lifelines (synchronous solid, asynchronous open arrow, return dashed).

    • Frame: Rectangle surrounding diagram with a header (e.g., alt for alternative, loop).

  • Example: Library Management (Issue/Renew)

    
    User -> LibrarySystem: issueBook(bookId)
    
    LibrarySystem -> Book: checkAvailability()
    
    Book --> LibrarySystem: true
    
    LibrarySystem -> LoanRecord: create()
    
    LoanRecord --> LibrarySystem: success
    
    LibrarySystem --> User: Book Issued
    
    

• Collaboration Diagrams (Communication Diagrams)

  • Purpose: Model structural organization of objects and the messages they exchange. Emphasizes links between objects.

  • Notation: Objects connected by links (solid lines). Messages are numbered sequences (1, 2, 2.1) placed near links.

  • Key: Shows who talks to whom; sequence is inferred from numbering.

• Comparison: Sequence vs. Collaboration Diagrams

[!TIP] Common Pitfall: Don't confuse extend (optional/conditional) with include (mandatory reuse). In sequence diagrams, synchronous messages wait for a reply; asynchronous do not.

Activity Diagrams

• Purpose: Model workflow or business process. Shows flow of control and data.

• Notation:

  • Action: Rounded rectangle (work unit).

  • Control Flow: Solid arrow (sequence).

  • Object Flow: Dashed arrow (object passed).

  • Partition (Swimlane): Vertical/horizontal band grouping actions by responsible actor/object.

  • Decision Node: Diamond (<>), guard conditions [condition].

  • Fork/Join: Thick horizontal/vertical bar for parallel flows.

• When NOT to Use: Avoid for modeling detailed object interactions or state-dependent behavior. Use Sequence/Communication diagrams for interactions and State Machine diagrams for state-dependent behavior.

• Practical Situations:

  • Use Case Diagram: For high-level functional requirements and actor-goal overview.

  • Object Diagram: For illustrating a concrete example or snapshot (e.g., "show the state after order placement").

  • Interaction Diagram: For detailing how objects collaborate to fulfill a single use case scenario.

V. Architectural and Implementation Modeling

Component Diagrams

• Purpose: Show physical, replaceable parts of the system (components) and their interfaces and dependencies. Models the implementation view.

• Notation:

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

  • Interface: Circle or half-circle (lollipop) for provided, socket for required.

  • Dependency: Dashed arrow.

• Component Models:

  | Model | Key Features | Role | | :--- | :--- | :--- | | CORBA | Language-neutral, middleware standard, uses IDL (Interface Definition Language). | Enables interoperability between components written in different languages on different OS. | | COM | Binary standard from Microsoft, language-neutral (within Windows), uses interfaces (IUnknown). | Building block for Windows applications; components are DLLs/EXEs. | | DCOM | Distributed COM, extends COM across network. | Enables COM component communication across networked machines. |

• Example: Banking Application

  • Components: AccountManager, TransactionProcessor, ReportingService.

  • AccountManager depends on TransactionProcessor interface.

  • ReportingService requires IDataProvider interface (provided by AccountManager).

Deployment Diagrams

• Purpose: Model the physical architecture—hardware nodes and how software artifacts are deployed on them.

• Notation:

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

  • Connection: Line between nodes (e.g., TCP/IP, Bluetooth).

  • Artifact: Rectangle with <<artifact>> (e.g., main.exe, config.xml) placed on a node.

• Example: Banking Application

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

  • Artifacts: BankingApp.war on Web Server, AccountDB on Database Server.

  • Connections: HTTPS between Client and Web Server; JDBC between App Server and DB Server.

User Interface Design in OOAD

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

• Representing UI in UML: Often modeled as a specialized class or component (e.g., <<boundary>> class or UIComponent). It interacts with control classes (logic) and entity classes (data).

• Example: ATM Banking System UI

  • Boundary Classes: ATMScreen, Keypad, CardReader.

  • Control Class: ATMController (handles transactions).

  • Entity Class: BankAccount.

  • Interaction: ATMScreen (boundary) sends enterPin() message to ATMController (control), which then queries BankAccount (entity).

VI. Integration and Application

Combining Diagram Types

• Traceability: A well-designed suite of diagrams is traceable.

  • Use Case → Sequence/Communication (scenario realization) → Class (collaborating objects & operations).

  • Class Diagram provides the vocabulary for all other diagrams.

• Complementary Roles:

  • Use Case: What the system does (functional requirements).

  • Class: Static structure (nouns).

  • Sequence/Communication: Dynamic collaboration for a use case (verbs).

  • Activity: Workflow across use cases or within a complex use case.

  • Component/Deployment: Physical implementation and deployment.

Modeling Complete Systems

1. Develop a Suite: Start with Use Case diagram for scope. Develop Class diagram for core structure. Create Sequence diagrams for key scenarios. Use Activity for complex workflows. Add Component/Deployment for architecture.

2. Consistency Checks:

   • Every use case scenario should have a corresponding sequence/communication diagram.

   • All objects in interaction diagrams must exist in the class diagram.

   • Operations called in sequences must be defined in the corresponding class.

   • Multiplicities and associations in class diagrams should align with object links shown in interaction diagrams.

3. Completeness: Ensure all requirements from the use case model are addressed by at least one other diagram (usually a sequence or activity).

[!TIP] Exam Strategy: When asked to "draw a diagram for X," first identify the diagram type (Use Case? Sequence?), then list the key elements (actors, classes, lifelines) before drawing. Always relate it back to the requirements.