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

UNIT 2: Object-Oriented Analysis and Design

I. Foundations of Modeling in OOAD

What is a Model?

A model is an abstract representation of a system, built to understand, visualize, communicate, and document aspects of that system before construction.

Purposes of Modeling:

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

• Documentation: Captures decisions and system structure for future maintenance.

• Analysis: Allows exploration of "what-if" scenarios, identification of inconsistencies, and complexity management.

• Planning & Implementation Guidance: Serves as a blueprint for coding and testing phases.

Object-Oriented Approach

Object-oriented (OO) is a paradigm that structures software as a collection of objects—self-contained entities combining data (attributes) and behavior (operations). The four fundamental aspects are:

1. Objects: Instances of classes; the basic runtime entities.

2. Classes: Blueprints/templates defining common structure and behavior for a set of objects.

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

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

Domain Modeling & Attribute Types

A domain model identifies key conceptual entities (classes) and their relationships within the problem space.

Suitable Attribute Types (Focus on Data Type Attributes):

• Primitive Types: int, string, float, boolean. Used for simple, atomic data.

• Complex Types (Value Objects): Objects defined by their value (e.g., Date, Money, Address). They lack a distinct identity and are often immutable.

• Entity Types: Objects with a unique, persistent identity (e.g., Customer, Account). Their state can change over time.

Key Distinction: Value objects are compared by value; entities are compared by identity.

Need for Modeling & Role of UML

Risks of Rushing into Implementation:

• Incomplete/inconsistent requirements leading to rework.

• Missed relationships and hidden dependencies.

• Poor scalability and maintainability.

• Ineffective communication among team members.

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

Role of UML:

• Provides a common notation for all stakeholders.

• Supports multiple, inter-related views of a system.

• Facilitates analysis, design, and implementation mapping.

Types of UML Models & Their Purpose:

| Model Type | Purpose | Key Diagrams |

| :--- | :--- | :--- |

| Structural | Shows static architecture: classes, objects, components, nodes. | Class, Object, Component, Deployment |

| Behavioral | Shows dynamic aspects: interactions, state changes, workflows. | Use Case, Sequence, Activity, State |

| Architectural | Organizes system into physical/logical components and their deployment. | Component, Deployment |

II. UML Overview and Notations

UML Diagram Taxonomy

UML 2.x diagrams are broadly categorized:

UML Notations in Detail (Common Elements)

Graphical Elements:

• Node: Rectangle with compartments (Name, Attributes, Operations). Stereotypes <<interface>>, <<entity>> in small caps above name.

• Edge/Connector: Line between nodes. Types: Association (solid), Dependency (dashed), Generalization (solid line with hollow triangle), Realization (dashed line with hollow triangle).

• Compartment: Horizontal sections within a class rectangle.

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

• Multiplicity: 1, *, 0..1, 1..*, m..n placed near association ends.

• Qualified Association: A box attached to an association end, representing a lookup key (e.g., account[accountNumber]).

• Note: Dog-eared rectangle for comments, attached via dashed line.

III. Structural Diagrams

Class Diagrams

Identifying Associations:

• A semantic connection between two or more classes.

• Binary Association: Connects two classes (most common).

• Unary (Reflexive) Association: Connects instances of the same class (e.g., Employee manages Employee).

• Qualified Association: Uses a qualifier (key) to reduce multiplicity (e.g., a Customer has many Accounts, but account[accountNumber] selects one).

• Multiplicity: Defines how many instances participate. 1 (exactly one), * (many), 0..1 (optional), 1..* (at least one).

Super-Sub Class Relationships (Generalization):

• Criteria: "Is-a" relationship, shared attributes/operations, polymorphic substitution principle.

• Notation: Solid line with hollow triangle pointing to the superclass.

• Design Implication: Promotes reuse but increases coupling. Use when there is clear, stable hierarchy.

Object Diagrams

Purpose: A snapshot showing a set of objects and their links at a specific moment. Used to illustrate complex class diagram scenarios, test multiplicities, or provide concrete examples.

Notation: Similar to class diagram but with underlined object names: objectName:ClassName.

When to Use: To show a concrete example of a system structure, validate class diagram logic, or document a test case.

Component Diagrams

Purpose: Model physical, replaceable parts of a system (components) and their dependencies. Shows organization and dependencies among software components.

Component Models (Standards):

1. CORBA (Common Object Request Broker Architecture):

- OMG standard for distributed objects.

- Uses **IDL (Interface Definition Language)** to define object interfaces.

- **ORB (Object Request Broker)** mediates client-server communication.

- Components are **objects** with interfaces defined in IDL.

2. COM (Component Object Model) & DCOM (Distributed COM):

- Microsoft's binary standard for component interoperability.

- Components expose **interfaces** (pure abstract classes in C++).

- **DCOM** extends COM for network communication using RPC.

- Key concept: **QueryInterface** to discover supported interfaces.

Deployment Diagrams

Purpose: Model the physical architecture of a system—hardware nodes and the software artifacts (executables, libraries, configurations) deployed on them.

Notation:

• Node: 3D box (e.g., [Server], [PC]). Can have nested nodes.

• Artifact: Rectangle with folded corner (e.g., main.exe, config.xml). Placed on nodes.

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

Example for Banking Application:

[ATM Node] --(HTTP)--> [Web Server Node]

                 |

             [App Server Node] --(JDBC)--> [Database Server Node]

Artifacts: ATMClient.jar, WebApp.war, EJB.jar, DB Schema

IV. Behavioral Diagrams

Use Case Diagrams

Purpose: Capture functional requirements from an actor's perspective. Shows system's external functionality.

Elements:

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

• Use Case: Oval representing a unit of functionality.

• Relationships:

• Association: Connects actor to use case (participation).

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

• Extend (<<extend>>): Optional/conditional extension (e.g., Place Order extended by Apply Discount).

• Generalization: Actor or use case inheritance (specialized actor inherits base use cases).

Example: Online Shopping System

Actors: Customer, Guest, Admin.

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

Relationships: Checkout includes Process Payment; Guest generalizes Customer.

Interaction Diagrams

Sequence Diagrams:

• Notation: Lifeline (dashed vertical line from object rectangle), Activation Bar (thin rectangle on lifeline during execution), Messages (horizontal arrows: solid=synchronous, open arrow=asynchronous, dashed=return).

• Time Axis: Vertical (time flows downward).

• Example: Library Management (Issue/Renew Book):

User -> LibrarySystem: issueBook(bookID)

LibrarySystem -> Book: checkAvailability()

Book --> LibrarySystem: status

LibrarySystem -> User: confirmIssue()

Renewal follows similar flow with renewBook().

Collaboration (Communication) Diagrams:

• Notation: Objects as rectangles, Links (lines connecting objects), Messages numbered sequentially (1., 2., 1.1, 2.1*) near links.

• Emphasis: Structural organization of objects; time order is inferred from message numbers, not spatial layout.

• Similarities/Dissimilarities:

| Aspect | Sequence Diagram | Collaboration Diagram |

| :--- | :--- | :--- |

| Primary Focus | Time ordering of messages. | Structural links among objects. |

| Layout | Objects arranged vertically; time flows down. | Objects arranged arbitrarily; links show topology. |

| Message Timing | Explicit via vertical position. | Implicit via numbering. |

| Ease of Reading | Clear temporal flow. | Better for seeing object connectivity. |

Example: ATM Card-Based Banking:

Objects: Customer, ATM, CardReader, BankServer, Account.

Messages (numbered): 1. insertCard(), 2. validatePIN(), 3. selectAccount(), 4. getBalance(), etc.

Activity Diagrams

Purpose: Model workflow of a system or business process, or the logic of an algorithm. Good for parallel/concurrent activities.

Notation:

• Action: Rounded rectangle (single step).

• Decision Node: Diamond ([condition]).

• Merge Node: Diamond (combines flows).

• Fork/Join: Thick horizontal/vertical bar (splits/combines parallel flows).

• Swimlane: Divides diagram by responsibility (e.g., User, System).

• Start/End: Filled circle / bullseye.

When NOT to Use Activity Diagrams:

• For simple, linear sequences of operations (use a use case or simple sequence).

• When the focus is on object interactions over time (use sequence/collaboration).

• For modeling detailed state changes of a single object (use state machine diagram).

Preferable Alternatives:

• Use Case Diagram: For high-level user functionality.

• Sequence/Collaboration Diagram: For detailed object message flows.

Practical Situations for Diagram Selection:

• Use Case Diagram: During requirements gathering to identify actors and major functions.

• Object Diagram: To illustrate a complex scenario from a class diagram with specific data.

• Interaction Diagram (Sequence/Comm): During design to detail how objects collaborate to fulfill a use case.

V. Design Considerations, Refinement, and Applications

Common Design Pitfalls & Refinement

Errors from Rushing Implementation:

• Inadequate or ambiguous requirements → building wrong features.

• Missed associations/generalizations → flawed class structure.

• Poor scalability & performance → system cannot handle load.

• Tight coupling & low cohesion → difficult to modify/maintain.

Deciding What to Eliminate (Classes, Associations, Generalizations):

Apply these criteria:

1. Redundancy: Duplicate classes/associations serving the same purpose.

2. Low Cohesion: A class doing too many unrelated things → split or remove.

3. High Coupling: Unnecessary dependencies between classes → weaken or remove association.

4. Lack of Necessity: Classes with no attributes/operations or associations with no meaningful purpose in the problem domain.

5. Premature Generalization: Inheritance hierarchies built on speculation rather than proven commonality.

User Interface Design in OOAD (ATM Example)

Integrate UI design with use cases and interaction diagrams.

Steps:

1. Identify key use cases (Withdraw Cash, Check Balance, Transfer Funds).

2. For each use case, design a sequence/communication diagram showing interaction between Customer, ATMUI, ATMController, BankServer.

3. UI Mockup: Sketch screens (welcome, PIN entry, main menu, transaction confirmation) showing input fields, buttons, and messages.

4. Link UI events to messages in interaction diagrams (e.g., click(Withdraw) → ATMUI -> ATMController: initiateWithdraw()).

Neat Diagram Expectation: A combination showing use case diagram (system boundary) alongside a sequence diagram for a primary flow, with UI screens referenced in notes.

Integrated Application: Banking System

Component Diagram for Banking App:

Components: <<component>> TransactionProcessing, <<component>> SecurityManager, <<component>> ReportingService, <<component>> CustomerDatabase.

Dependencies: TransactionProcessing depends on SecurityManager and CustomerDatabase; ReportingService depends on CustomerDatabase.

Deployment Diagram for Banking App:

Nodes: [Load Balancer], [Web Server Cluster], [App Server Cluster], [Primary DB Server], [Backup DB Server], [ATM Network].

Artifacts: WebApp.war on Web Server, EJB.jar on App Server, BankDB.schema on DB Servers.

Paths: HTTPS between ATM and Load Balancer; RMI/IIOP between Web/App servers; JDBC to DB servers.

Mapping: SecurityManager component deployed on App Server; CustomerDatabase artifact on Primary DB Server.

[!EXAM TIPS & COMMON PITFALLS]

TIP 1: When asked to "identify associations/generalizations," look for noun phrases in the problem description (potential classes) and verb phrases (potential associations). For generalization, look for clear "is-a" and shared attributes.

PITFALL 1: Confusing association (semantic link) with dependency (usage/change impact). Use dependency for "uses" relationship (e.g., a class that creates another), association for structural "has-a" or "knows-a".

TIP 2: For diagram selection questions, remember:

• Use Case: "What does the system do for actors?"

• Sequence: "How do objects interact over time for a scenario?"

• Activity: "What is the workflow/parallel process?"

• Class: "What are the static classes and their relationships?"

PITFALL 2: In sequence diagrams, destruction of an object is shown by a large X at the end of its lifeline. Forgetting this in lifetime scenarios.

TIP 3: For component diagrams, always stereotype components (<<component>>) and show provided/required interfaces (lollipop/socket notation) if asked for detail.

PITFALL 3: In multiplicity, 0..1 means optional (zero or one), 1 means mandatory exactly one, * means zero or more. Misreading leads to incorrect model constraints.

TIP 4: When designing for ATM/Online Shopping, standard actors are User/Customer, Admin. Key use cases involve authentication, transaction, and management. Always show <<include>> for mandatory sub-flows like Authenticate.

PITFALL 4: Drawing generalization triangles pointing to the subclass. They must point upward to the superclass.

TIP 5: For CORBA vs COM:

• CORBA: Language-neutral, uses IDL & ORB. Platform-independent.

• COM/DCOM: Microsoft-specific, binary standard. DCOM adds network transparency.

Be ready to contrast them in a 14-mark question.