Unit I – Unified Process & Use Case Diagrams .docx

notes

1. UNIT I – UNIFIED PROCESS & USE CASE DIAGRAMS (9 Hours)
Course: CS2041 – Cloud Computing Essentials (OOAD Foundations Refresher)
Format: Assistant Professor Notes + Final Report
Focus: Definitions • Deep explanations • Step-by-step methods • Real-time industry examples •
Mini-templates • Viva & Exam Qs
1) Introduction to OOAD with OO Basics
1.1 What is OOAD?
Object-Oriented Analysis and Design (OOAD) is a disciplined approach to building software
by modeling the problem domain with objects and progressively refining it into a working
design and code. OOAD emphasizes abstraction, encapsulation, modularity, and reusability.
1.2 Why OOAD?
Aligns software with real-world concepts (objects, responsibilities, collaborations).
Encourages low coupling and high cohesion, enabling maintainability and reuse.
Supports iterative development and early risk reduction.
1.3 OO Basics (Core Concepts)
Class: Blueprint for objects. Contains attributes + operations.
Example: Customer(name, phone).placeOrder()
Object: Runtime instance of a class. Has state + behavior.
Example: customer1 with name = "Uma".
Abstraction: Focus on essential features; hide unnecessary details.
Example: A Payment abstracts UPI/Card/Cash internals.
Encapsulation: Bundle data + methods; hide internals.
Example: Account.debit(amount) checks rules internally.
Inheritance: Reuse via is-a relation.
Example: DeliveryAgent is-a Employee.
Polymorphism: Same message, different implementations.
Example: Payment.authorize() behaves differently for Card, UPI, Wallet.
Association/Aggregation/Composition: Structural relations among classes.
oAssociation: Customer—Order (n..m).
oAggregation (whole–part, weak): Cart aggregates Item.
oComposition (whole–part, strong lifecycle): Order composes OrderLineItem.
1.4 Mini Case A – Online Food Delivery (India)
Classes: Customer, Restaurant, MenuItem, Cart, Order, Payment, DeliveryAgent, Offer.
Polymorphism: Payment → CardPayment, UpiPayment, CashOnDelivery.

2. Encapsulation: Order.calculateTotal() hides tax/offer logic.
Inheritance: Employee → DeliveryAgent, SupportAgent.
1.5 Mini Case B – Campus E-Wallet
Actors: Student, Merchant Kiosk, Bank API.
Classes: Wallet, Transaction, QRCode, TopUp, Refund.
Design Note: Use composition: Wallet → many Transaction.
1.6 OOAD Workflow (High Level)
1.Analysis: Understand domain → use cases → domain model.
2.Design: Convert to classes, interfaces, patterns, subsystem architecture.
3.Implementation: Code + unit tests.
4.Validation: System/acceptance tests aligned to use cases.
2) Unified Process (UP)
2.1 What is UP?
The Unified Process is an iterative, incremental, risk-driven, architecture-centric, and use-case–
driven framework. It structures development into four phases, each with one or more iterations.
2.2 Key Characteristics
Iterative & Incremental: Deliver in small increments; refine through feedback.
Risk-Driven: Attack highest risks early (tech, schedule, cost, legal, security).
Architecture-Centric: Establish a robust, executable architecture baseline early.
Use-Case–Driven: Requirements expressed as use cases guide analysis, design, tests.
2.3 Phases & Major Milestones
1.Inception → Lifecycle Objective milestone
Vision, scope, feasibility, business case, high-level risks, candidate use cases.
2.Elaboration → Lifecycle Architecture milestone
Refine architecture, mitigate critical risks, produce executable architectural baseline, plan
construction.
3.Construction → Initial Operational Capability milestone
Build features iteratively; complete most functionality; intensive testing.
4.Transition → Product Release milestone
Beta, user training, deployment, operational readiness.

3. 2.4 Workflows/Disciplines
Business Modeling, Requirements, Analysis & Design, Implementation, Test,
Deployment
Supporting: Configuration Mgmt, Project Mgmt, Environment (tools), Change Mgmt.
2.5 Roles (examples)
Analyst, Architect, Designer, Developer, Tester, CM Engineer, PM, UX, DBA, DevOps.
2.6 Artifacts (deliverables)
Vision, Use-Case Model, Supplementary Spec (non-functional reqs), Domain Model, Design
Model, Data Model, Iteration Plan, Risk List, Test Cases, Build/Release Notes.
2.7 Real-Time Example – Campus E-Wallet System
Inception: Value prop (cashless campus), scope (top-up, pay, refunds), high-level risks
(fraud, KYC).
Elaboration: Architecture POC: QR payments, integration with Bank API sandbox;
security hardening; pick tech stack (Spring Boot + MySQL + Keycloak).
Construction: Iterations deliver: I1 (top-up, balance), I2 (payments, refund), I3 (reports,
admin).
Transition: Pilot in canteen → feedback → full rollout across campus.
3) UML Diagrams – Overview and Practical Use
UML = Unified Modeling Language (visual standard for OO systems).
3.1 Structural Diagrams
Class Diagram: Shows classes, attributes, operations, and relationships.
When: Designing domain/data model; communicating structure.
Mini Example (E-Commerce): Customer — places —> Order — contains —>
OrderLineItem — refers —> Product.
Object Diagram: Snapshot of objects at runtime.
Use: Debug complex graphs; example state of an order with two line items.
Package Diagram: Organize classes into packages/modules; show dependencies.
Use: Layered architecture (ui, service, domain, infra).
Component Diagram: Physical components (services, libraries) and provided/required
interfaces.
Use: Microservices and external gateways.
Deployment Diagram: Nodes (servers/devices) and artifact deployment.
Use: Cloud topology (WebApp on EC2, DB on RDS, CDN, Payment Gateway).

4. Composite Structure Diagram: Internal structure of a class/component and ports.
Use: Complex UI widget or service composition.
3.2 Behavioral Diagrams
Use Case Diagram: Actors + use cases + relations.
Use: Scope and stakeholder communication.
Sequence Diagram: Time-ordered interactions (lifelines, messages).
Use: Detail a scenario like checkout.
Communication Diagram: Same as sequence but focus on object links.
Use: Network of collaborators.
Activity Diagram: Workflow/control flow with decisions/parallelism.
Use: Business processes (refund approval).
State Machine Diagram: States & transitions of a reactive object.
Use: Order lifecycle (Created→Paid→Packed→Shipped→Delivered/Cancelled).
Interaction Overview & Timing: Higher-level interaction flow; timing constraints
(often used in embedded/real-time systems).
4) Use Cases – In Depth
4.1 Definition
A use case describes a goal-oriented interaction between an actor (user or external system) and
the system that yields measurable value to the actor.
4.2 Levels (Cockburn)
Summary (cloud): Big picture business goals.
User-goal (sea level): Daily user tasks (preferred for requirements).
Sub-function (underwater): Low-level functions reused by others.
4.3 Textual Use Case Template (Recommended)
Use Case Name
Scope & Level
Primary Actor
Stakeholders & Interests
Preconditions

5. Postconditions (Success/Failure)
Main Success Scenario (MSS) steps
Extensions (Alternate/Exception Flows)
Special Requirements (NFRs: performance, security, usability)
Open Issues/Notes
4.4 Quality Checklist
Actor achieves clear business value.
Observable results; verifiable postconditions.
Steps are intent-focused (what, not UI how).
Keep MSS 5–15 steps; move details to extensions.
4.5 Example – ATM: Withdraw Cash (User-Goal)
Primary Actor: Customer
Preconditions: Valid card; ATM online; sufficient cash.
Postconditions: Account debited; cash dispensed; receipt optional.
MSS:
1.Customer inserts card.
2.System prompts for PIN; Customer enters PIN.
3.System verifies PIN.
4.Customer selects Withdraw.
5.Customer enters amount.
6.System checks balance & cash availability.
7.System dispenses cash.

6. 8.System updates account, logs transaction.
9.System offers receipt; session ends.
Extensions:
3a. Invalid PIN (×3) → retain card.
6a. Insufficient funds → show error; allow new amount.
4.6 Example – Food Delivery: Place Order (with NFRs)
NFRs: Response < 2s; Payment PCI-DSS; 99.9% uptime; support 1M DAUs.
5) Case Study – Next-Gen POS System (Retail Checkout)
Adapted from standard POS case studies used in OOAD courses. Focus = Process
Sale.
5.1 Actors
Cashier (primary), Customer, Store Manager, External Payment Service, Inventory System, Tax
Authority API, Printer.
5.2 Key Use Cases
Process/Record Sale (scan items, total, pay)
Handle Payment (Card/UPI/Cash)
Apply Promotions/Coupons
Print/Email Receipt
Manage Returns/Refunds
Update Inventory
End-of-Day Reconciliation/Reports
5.3 Textual Use Case – Process Sale (Detailed)
Primary Actor: Cashier
Preconditions: POS logged in; Register open.
Postconditions: Sale completed or void; inventory updated; receipt issued.
MSS:

7. 1.Cashier starts a new sale.
2.For each item, Cashier scans barcode (or enters SKU).
3.System displays line item, price, running total, and stock units.
4.Cashier optionally applies customer loyalty and promotions.
5.Cashier initiates payment.
6.System sends amount to Payment Service (UPI/Card).
7.Payment Service authorizes/declines.
8.On success, System records payment, updates inventory.
9.System prints/emails receipt; closes sale.
Extensions:
2a. Barcode unreadable → manual SKU entry.
4a. Promo invalid → notify; continue.
7a. Authorization failed → retry/alternate tender.
8a. Inventory negative → alert; manager override.
5.4 Domain Model (Core Concepts)
Sale (dateTime, total)
SalesLineItem (qty, subtotal)
ProductSpecification (itemId, price, description, taxCategory)
Payment (amount, type, authCode) → CardPayment, UpiPayment, CashPayment
Register, Store, CashDrawer, Receipt
Promotion, LoyaltyAccount
Associations:
Sale 1..* SalesLineItem; SalesLineItem —1→ ProductSpecification; Sale —1..*→ Payment.

8. 5.5 System Sequence Diagram (SSD) – Process Sale
Lifelines: Cashier (actor), POS System, Payment Service.
Flow: startNewSale() → loop [scanItems] enterItem(barcode, qty) → endSale() →
makePayment(amount) → authorize(amount) ↔ PaymentSvc → printReceipt().
5.6 Operation Contracts (Examples)
enterItem(barcode, qty)
Post: a SalesLineItem instance created; associated with current Sale; subtotal updated.
makePayment(amount)
Post: Payment created; linked to current Sale; Sale marked PAID if amount ≥ total.
5.7 Design Considerations
GRASP Patterns: Controller = Register/POS; Information Expert = Sale computes total;
Low Coupling between UI and Sale; High Cohesion within Sale.
Persistence: ORM mapping Sale→sales table, etc.
Reliability: Idempotent payment capture; retry policies; offline mode with sync.
6) Inception Phase (Unified Process) – Deliverables & Example
6.1 Purpose
Establish vision, scope, feasibility, and major risks. Decide go / no-go.
6.2 Typical Deliverables
Vision & Business Case (problem, benefits, KPIs)
Scope (in/out) & high-level features
Stakeholder list
Actors and Goals list
Initial Use-Case Model (names + brief descriptions)
Risk List (top 10)
Feasibility: technical, operational, schedule, legal

9. Rough Cost & ROI
Initial Project Plan & Iteration 1 plan
6.3 Example – Hospital Appointment Management
Vision: Reduce patient wait time by 40%; enable digital booking & e-prescriptions.
Scope (In): registration, doctor schedule, booking, cancellations, reminders, billing.
Scope (Out): pharmacy stock management (phase 2).
Actors: Patient, Doctor, Receptionist, Lab System, Payment Gateway.
High Risks: data privacy, appointment clashes, SMS/email reliability.
Initial Use Cases: Register Patient, Book Appointment, Cancel, Pay Bill, Generate
Prescription, Sync Lab Results.
Feasibility: Use existing HIS integration; adopt OTP-based login; cloud hosting.
7) Use Case Modelling – Step-by-Step Method
7.1 Identify Actors (external to system)
Primary human: end users (Customer, Cashier, Student).
Secondary human: admins, back-office.
External systems: Payment Gateway, Bank API, SMS/Email service.
Devices: Scanner, Printer, IoT terminals.
7.2 Discover User-Goal Use Cases
Technique: Actor–Goal List. For each actor, list their goals in the system’s scope. Keep names
verb-noun: Place Order, Pay Bill, Track Package.
7.3 Write Brief Descriptions → Expand Textual Use Cases
Start with a brief (2–3 lines).
Expand important ones to fully dressed template (Section 4.3).
Attach NFRs to each (availability, security, performance, usability).

10. 7.4 Draw the Use Case Diagram
Show system boundary, actors, use cases, and relations (include/extend/generalization).
Keep diagrams readable (≤ 12 use cases per diagram).
Avoid showing UI steps or database tables in a use case diagram.
7.5 Traceability
Map each use case → tests (acceptance scenarios).
Map use case steps → sequence diagrams and operation contracts.
Map to design components and user stories/tasks for implementation.
7.6 Example – Ride-Hailing App
Actors: Rider, Driver, Payment Service, Maps API, SMS Gateway.
Use Cases: Request Ride, Accept Ride, Navigate to Pickup, Start Trip, End Trip, Pay
Fare, Rate Driver.
Include/Extend: Authenticate User (include); Apply Promo (extend Pay Fare).
8) Relating Use Cases – include, extend, generalization
8.1 «include» (mandatory reuse)
Extract a common sub-function used by multiple use cases.
Always executed when the base use case runs.
Example: Checkout «include» Authenticate Customer; Pay Bill «include» Compute Tax.
8.2 «extend» (optional/conditional behavior)
Represents a conditional or optional scenario that adds steps to a base use case at a
defined extension point.
Example: Checkout may be extended by Apply Coupon only if customer enters a
coupon.
Example: Place Order extended by Gift Wrap.

11. 8.3 Generalization (specialization)
Actors or Use Cases can specialize others.
Actor Example: User ← Admin, Seller, Buyer.
Use Case Example: Make Payment ← Card Payment, UPI Payment, Wallet Payment.
8.4 Common Mistakes & Tips
Don’t use «include» for sequencing (it’s not call flow control). Use it only for shared
mandatory sub-goals.
Don’t overuse «extend» to model every small option; prefer extensions section in textual
use case unless reuse/visibility is needed.
Generalize only when the specializations have different notable behavior.
9) When to Use Use Cases (and when not)
9.1 Best Situations
When stakeholders need clear, narrative requirements.
Systems with many human interactions (banking, retail, healthcare, campus apps).
To align testing with user goals (acceptance criteria from MSS/Extensions).
To drive UX prototypes and sequence diagrams.
9.2 Not a Great Fit
Algorithmic libraries with no external actors (e.g., ML math kernels).
Batch ETL pipelines where flow is mostly data-driven (prefer activity diagrams + data
specs).
Very fine-grained API specs (prefer OpenAPI/contract tests alongside a few top-level
use cases).
9.3 Use Cases vs User Stories
Use Case: richer structure; actors, pre/post; main + alternate flows.
User Story: “As a , I want so that .” Good for agile planning; add acceptance criteria to
approach use-case rigor.

12. FINAL REPORT ELEMENTS (Per Topic)
Below are ready-to-submit summaries you can paste into your lab/assignment report.
A. OOAD with OO Basics – Final Report Summary
Aim: Understand OO concepts and apply to real domain.
Theory: Classes, objects, abstraction, encapsulation, inheritance, polymorphism;
associations (aggregation, composition).
Method: Identify domain nouns/verbs → draft class diagram → validate with scenarios.
Observation: Encapsulation reduces ripple changes; composition models lifecycle.
Result: Working model for Food Delivery & Campus Wallet case; reusable classes
defined.
Conclusion: OOAD maps real-world entities to software, improving maintainability.
B. Unified Process – Final Report Summary
Aim: Apply UP to structure development.
Theory: Iterative, risk-driven, architecture-centric, use-case–driven.
Procedure: Conduct Inception (vision, scope, risks) → Elaboration (architecture
baseline) → Construction (feature iterations) → Transition (release).
Result: Campus E-Wallet plan with phased iterations and risk mitigation.
Conclusion: UP reduces risk and delivers value incrementally.
C. UML Diagrams – Final Report Summary
Aim: Use UML to visualize system structure and behavior.
Theory: Structural (Class, Component, Deployment, …) and Behavioral (Use Case,
Sequence, Activity, …).
Procedure: From use cases derive sequence diagrams; from domain nouns build class
diagram; map services/components; plan deployment.
Result: Coherent models for POS and E-commerce examples.
Conclusion: UML enhances communication and design correctness.

13. D. Use Case – Final Report Summary
Aim: Capture functional requirements via actor goals.
Theory: Cockburn levels; textual template; MSS & extensions; NFRs.
Procedure: Actor–Goal list → Brief use cases → Fully dressed for critical flows.
Result: ATM Withdraw & POS Process Sale use cases.
Conclusion: Use cases provide testable, stakeholder-friendly requirements.
E. Case Study – Next-Gen POS – Final Report Summary
Aim: Model retail checkout with robust domain and interactions.
Theory: Domain model (Sale, SalesLineItem, ProductSpecification, Payment), SSDs,
operation contracts, GRASP.
Procedure: Write Process Sale; derive classes; define contracts; sketch SSD.
Result: Clear design supporting promotions, loyalty, refunds, inventory updates.
Conclusion: POS case demonstrates end-to-end OOAD traceability from use case to
design.
F. Inception – Final Report Summary
Aim: Establish feasibility and scope early.
Key Artifacts: Vision, Risk list, Actor–Goal list, Initial use cases, Feasibility, Plan.
Result: Hospital Appointment example with defined KPIs & pilot plan.
Conclusion: Strong inception prevents scope creep and surprises later.
G. Use Case Modelling – Final Report Summary
Aim: Systematically derive use cases and diagrams.
Method: Identify actors → goals → brief → fully dressed → diagrams → traceability.
Result: Ride-Hailing app model ready for design & testing.
Conclusion: Consistent modeling ensures coverage and testability.

14. H. Relating Use Cases – Final Report Summary
Aim: Apply «include», «extend», and generalization correctly.
Method: Extract mandatory common parts (include); model optional flows (extend);
specialize actors/UCs when behavior differs.
Result: Clean diagrams for Checkout, Payment, Promotions.
Conclusion: Proper relations reduce duplication and diagram clutter.
I. When to Use Use Cases – Final Report Summary
Use When: Human-centric systems; acceptance testing alignment; early stakeholder
communication.
Avoid When: Pure algorithmic or batch systems without actors.
Integration: Complement with user stories, prototypes, OpenAPI, BPMN as needed.
EXAM PREP: 2-Mark & 13-Mark Questions (with pointers)
Part-A (2 Marks)
1.Define abstraction and encapsulation with one example each.
2.Differentiate aggregation vs composition.
3.List the four phases of Unified Process.
4.What is a use case? Name its core elements.
5.Mention two advantages of iterative development.
6.What is a System Sequence Diagram (SSD)?
7.Give one example each for «include» and «extend».
8.What is a domain model?
9.State the purpose of the Inception phase.
10.List any four behavioral UML diagrams.

15. Part-B (13 Marks) – Model Answers (Bullet Key)
1.Explain Unified Process with a suitable case study.
Phases, milestones, artifacts, roles; Campus E-Wallet timeline; risk table; iteration plan.
2.Elaborate on Use Case Modeling with examples.
Actor identification, goal discovery, templates, quality checks; Ride-Hailing examples.
3.Discuss Next-Gen POS case from requirements to design.
Use cases, domain model, SSDs, operation contracts, GRASP mapping; promotions &
refunds.
4.Detail UML diagram taxonomy and practical usage.
Structural vs behavioral; when to use each; mini examples; pitfalls.
5.Describe Inception activities and deliverables.
Vision, scope, business case, feasibility, risk list, plan; Hospital example; KPIs.
6.Differentiate include, extend, and generalization with diagrams and scenarios.
Definitions, semantics, do’s/don’ts; E-commerce checkout mappings.
READY-TO-USE TEMPLATES
Textual Use Case Template (Fill-in)
Use Case:
Level:
Primary Actor:
Stakeholders & Interests:
Preconditions:
Postconditions (Success/Failure):
Main Success Scenario:
1)
2)
…
Extensions:
E1)
Special Requirements (NFRs):
Notes/Issues:
Iteration Plan (One Page)
Iteration Goal:
Backlog Items (linked to UCs):
Risks to Mitigate:
Acceptance Tests (from MSS):

16. Deliverables:
Metrics: velocity, defects, coverage.
Quick Viva Notes (One-liners)
UP is risk-driven and architecture-centric; not just a waterfall.
Use cases are intent-focused, not UI click scripts.
«include» = mandatory reuse; «extend» = optional variation.
Domain model ≠ database schema; it’s a conceptual view.
SSD captures external events and system responses per scenario.
End of Unit I Report
Tip: Next, add diagrams (Use Case, Class, Sequence, Activity) for POS, Food Delivery, and
Ride-Hailing to solidify understanding. I can generate clean diagram drafts on request.