UML & System Design
Complete Exam Study Guide
All 8 Topics Covered in Detail
Use Case · Class · Sequence · Activity · Statechart
Scenario · Collaboration · Test Cases
Table of Contents
1. Use Case Diagram
2. Use Case Description
3. Class Diagram & Class Identification
4. Sequence Diagram (Basic & Alternate Flow)
5. Activity Diagram
6. State Chart Diagram
7. Scenario Diagram · Scenario Matrix · Test Case Matrix
8. Collaboration Diagram
1. Use Case Diagram
What is it?
A Use Case Diagram is a behavioral UML diagram that shows the functional requirements of a system. It
captures the interactions between external users (actors) and the system to achieve specific goals. It is the
highest-level view of what a system does.
Key Components
Component Description
Actor External entity interacting with the system. Drawn as a stick figure.
Use Case A function or service the system provides. Drawn as an oval/ellipse.
System Boundary A rectangle that encloses all use cases belonging to the system.
Association A solid line connecting an actor to a use case.
Use case A always calls use case B (mandatory dependency). Dotted
«include» arrow from A to B.
Use case B optionally extends use case A (conditional). Dotted arrow from
«extend» B to A.
Inheritance between two actors or two use cases. Solid arrow with hollow
Generalization head.
Step-by-Step: How to Draw
1. Identify all actors — who or what interacts with the system from outside.
2. Identify all use cases — list every function the system must perform.
3. Draw the system boundary — a rectangle; write system name on top.
4. Place actors outside the rectangle (primary actors on left, secondary on right).
5. Place use cases inside the rectangle as labelled ovals.
6. Draw association lines (solid) between each actor and its use cases.
7. Add «include» with a dashed arrow pointing TO the included use case.
8. Add «extend» with a dashed arrow pointing TO the base use case.
9. Add generalization arrows if actors or use cases share common behavior.
«include» vs «extend» — Key Difference
«include»: The included use case is ALWAYS executed. Example: 'Borrow Book' always includes
'Login'.
«extend»: The extending use case runs ONLY under certain conditions. Example: 'Return Book' may
extend 'Pay Fine' only if there is a fine.
Example — Online Shopping System
Actor Customer, Admin, Payment Gateway
Browse Products, Add to Cart, Place Order, Make Payment, Track Order,
Use Cases Manage Inventory
«include» Place Order includes Make Payment (always needed)
«extend» Make Payment extends Apply Coupon (optional step)
Practice Questions
Q1: Draw a use case diagram for an Online Banking System. Actors: Customer, Bank Admin.
Include at least 5 use cases, one «include», and one «extend» relationship.
Q2: Draw a use case diagram for a Hospital Management System with actors: Patient, Doctor,
Receptionist. Show Login as an «include» for Make Appointment.
Q3: Explain with diagram the difference between «include» and «extend». Give one real-world
example of each.
2. Use Case Description
What is it?
A Use Case Description is a detailed textual document that describes a single use case step by step. It
converts the visual use case oval into a written specification showing exactly how the actor and system
interact under normal and abnormal conditions.
Standard Template Fields (Memorize These)
Field Description
Use Case Name The name of the use case (e.g., Borrow Book)
Use Case ID Unique identifier: UC-01, UC-02, etc.
Actor Who triggers this use case (primary actor)
Precondition Conditions that MUST be true BEFORE the use case starts
Postcondition State of the system AFTER the use case completes successfully
Main Flow Step-by-step interaction under normal/ideal conditions (happy path)
Alternate Flow What happens when a variation occurs but is still valid
Exception Flow What happens when an error or failure occurs
Complete Example — UC-02: Borrow Book
Use Case Name Borrow Book
Use Case ID UC-02
Actor Library Member
Precondition 1. Member is logged in.
2. Member has valid library card.
3. At least one copy of the book is available.
Postcondition 1. Book is marked as issued in the system.
2. Due date is set and recorded.
3. Book inventory count is decremented by 1.
Main Flow 1. Member searches for a book by title or author.
2. System displays the book details and availability.
3. Member selects the book and clicks 'Borrow'.
4. System checks member's borrow limit and eligibility.
5. System records the borrowing transaction.
6. System displays confirmation with due date.
Alternate Flow Step 2a: Book is not available.
a1. System shows 'Book Unavailable' message.
a2. System offers 'Reserve Book' option.
a3. Member reserves the book. Use case ends.
Exception Flow Step 4a: Member has unpaid fines.
e1. System displays 'Outstanding Fine' error.
e2. System blocks borrowing and redirects to Payment.
e3. Use case terminates.
Alternate Flow vs Exception Flow
Alternate Flow: A valid variation of the normal scenario (e.g., book unavailable → reserve). Use case
still completes in some form.
Exception Flow: An error or failure that stops the use case (e.g., system crash, unpaid fine blocking
action).
Practice Questions
Q1: Write a complete use case description for 'User Login' with alternate flow for wrong
password and exception flow for account lockout after 3 attempts.
Q2: Write a use case description for 'Online Payment' including exception flow for payment
gateway failure.
Q3: What is the difference between Precondition and Postcondition? Explain with the 'Place
Order' use case.
3. Class Diagram & Class Identification
What is it?
A Class Diagram is a structural UML diagram that shows the static structure of a system — the classes,
their attributes, methods, and the relationships between them. It forms the blueprint for writing code.
Class Structure (3 Compartments)
Top compartment Class Name — written in bold, centered, with first letter capitalized
Middle compartment Attributes — data fields: visibility name : dataType
Bottom compartment Methods — operations: visibility name(params) : returnType
Visibility Symbols
+ (public) Accessible from anywhere
- (private) Accessible only within the class
# (protected) Accessible within class and subclasses
~ (package) Accessible within the same package
Relationships in Class Diagrams
Association A general relationship between two classes. Solid [Link] uses Library
Aggregation Whole-part: part can exist independently. Hollow diamond
Department
on whole.
has Employees
Composition Strong whole-part: part cannot exist without whole. Filled
House
diamond
has Rooms
on whole.
Inheritance IS-A relationship. Solid line with hollow triangle pointing
Dog
to extends
parent. Animal
Dependency One class depends on another. Dashed arrow. Order uses PaymentGateway
Realization Class implements an interface. Dashed line with hollow
Car
triangle.
implements Drivable
Multiplicity How many instances relate: 1, *, 0..1, 1..*, 0..* 1 Customer has 0..* Orders
How to Identify Classes (Step-by-Step)
1. Read the problem statement carefully.
2. Underline all NOUNS — these are candidate classes (e.g., Student, Book, Library, Order).
3. Underline all VERBS — these become methods (e.g., borrow(), search(), pay()).
4. Eliminate duplicates and overly vague nouns (e.g., 'data', 'information').
5. Identify attributes for each class — the properties it must store.
6. Identify relationships — which classes know about or contain others.
7. Draw the class diagram with proper notation.
Example — Library System Classes
Book Member BorrowRecord
- bookId : String - title - memberId : String - name - recordId : String -
: String - author : String : String - email : String borrowDate : Date -
- isAvailable : Boolean - fineAmount : Float dueDate : Date -
returnDate : Date
+ search() : List + + borrowBook() : void + + calculateFine() : Float
getDetails() : String + returnBook() : void + + isOverdue() : Boolean
updateAvailability() : payFine() : Boolean
void
Relationships: Member (1) ——— BorrowRecord (0..*) ——— Book (1). Member borrows many Books through
BorrowRecord (Association/Aggregation).
Practice Questions
Q1: Identify classes, attributes, and methods from: 'An online shopping system allows
customers to browse products, add them to a cart, and place orders. Admin manages the
product catalogue.'
Q2: Draw a class diagram for a University System with classes: Student, Course, Faculty,
Department. Show all relationships with multiplicity.
Q3: What is the difference between Aggregation and Composition? Draw an example of each.
4. Sequence Diagram (Basic & Alternate Flow)
What is it?
A Sequence Diagram is a behavioral UML diagram that shows how objects interact with each other in a
time-ordered sequence. It captures the order of messages exchanged between objects to accomplish a
specific use case.
Key Components
Component Description
Actor/Object Shown as a box at the top with the name. Actor shown as stick figure.
A vertical dashed line descending from each object/actor. Represents the
Lifeline object's life during interaction.
A thin rectangle on the lifeline showing when the object is
Activation Bar active/executing.
Message Horizontal arrow between lifelines. Shows method call or communication.
Return Message Dashed arrow going back. Shows return value or response.
Self Message Arrow that loops back to the same lifeline (object calls itself).
Combined fragment for alternate flows. Box labeled 'alt' with conditions in [
Alt Fragment ].
Opt Fragment Box labeled 'opt' for optional steps.
Loop Fragment Box labeled 'loop' for repeated messages.
Step-by-Step: How to Draw
1. List all objects/actors that participate in the scenario.
2. Draw each as a box at the top of the diagram with a vertical dashed lifeline.
3. Draw messages (solid arrows) horizontally from sender to receiver in TIME ORDER (top to bottom).
4. Label each message arrow with the method name and parameters.
5. Add activation bars on the lifeline when an object is processing.
6. Draw return messages as dashed arrows going back to the caller.
7. For alternate flows: enclose them in an 'alt' combined fragment box, with condition in [brackets].
8. For optional steps: use 'opt' fragment. For loops: use 'loop' fragment.
9. Ensure time flows strictly top to bottom — earlier events are higher up.
Example — Login Sequence (Basic Flow)
Step From To Message (Solid Arrow)
1 User UI enterCredentials(username, password)
2 UI AuthCtrl login(username, password)
3 AuthCtrl Database validateUser(username, password)
4 Database AuthCtrl return: userRecord / null
5 AuthCtrl UI return: loginSuccess / loginFailed
6 UI User display: Dashboard / Error Message
Alternate Flow — Using 'alt' Fragment
The 'alt' fragment divides the scenario into branches using conditions in square brackets. Draw a rectangle
around the alternate section, label it 'alt' in the top-left corner, and separate each branch with a dashed
horizontal divider line.
[credentials valid] AuthCtrl → UI: loginSuccess(sessionToken)
[credentials invalid] AuthCtrl → UI: loginFailed('Wrong password')
[account locked] AuthCtrl → UI: accountLocked('Too many attempts')
Practice Questions
Q1: Draw a sequence diagram for 'ATM Cash Withdrawal' showing actors: Customer, ATM, Bank
Server. Include alternate flow for insufficient balance.
Q2: Draw a sequence diagram for 'Online Shopping — Place Order' with basic flow and alternate
flow for payment failure.
Q3: What is an activation bar in a sequence diagram? When is it used? What is the difference
between a synchronous message and an asynchronous message?
5. Activity Diagram
What is it?
An Activity Diagram is a behavioral UML diagram that shows the flow of activities or actions within a
system or process. It is similar to a flowchart but adds support for parallel activities, swim lanes, and object
flows.
Key Components
Component Description
Initial Node Filled solid black circle. Starting point of the activity.
Activity/Action Rounded rectangle. Represents a single step or action.
Decision Node Diamond shape. Has one input and multiple outputs with [conditions].
Merge Node Diamond shape with multiple inputs and one output. Joins branches.
Fork Node Thick horizontal/vertical bar. One input, multiple parallel outputs.
Join Node Thick horizontal/vertical bar. Multiple parallel inputs, one output.
Final Node Circle inside a circle (bullseye). End of the entire activity.
Flow Final Circle with X inside. Ends just one flow path (not the whole activity).
Partitions diagram into vertical/horizontal sections, one per
Swim Lane actor/department.
Control Flow Arrow showing the sequence from one activity to the next.
Object Flow Dashed arrow showing an object being passed between activities.
Step-by-Step: How to Draw
1. Identify the process to be modeled and all its activities.
2. Draw the Initial Node (solid black circle) at the top.
3. Draw each activity as a rounded rectangle and connect with arrows.
4. At decision points draw a diamond and label each outgoing arrow with [condition].
5. Use Fork bars for parallel tasks that start simultaneously.
6. Use Join bars to synchronize parallel paths before proceeding.
7. Add Swim Lanes if multiple actors/roles are involved — one lane per actor.
8. Draw the Final Node (bullseye) at the end of the process.
9. Ensure all paths lead to the Final Node — no dead ends.
Example — Online Order Processing (with Swim Lanes)
Browse Products → Add to Cart → Checkout → Enter Payment → Confirm
Customer Lane Order
Validate Payment → Update Inventory → Generate Invoice → Send
System Lane Confirmation
Warehouse Lane Receive Order → Pack Items → Ship Package → Update Tracking
Decision Points [Payment Success?] → Yes: Process Order / No: Notify Customer
Parallel (Fork) After payment success: simultaneously Update Inventory + Send Email
Activity vs Flowchart — Key Differences
Activity Diagram supports: parallel flows (fork/join), swim lanes for multiple actors, object flows, and
is part of UML.
Flowchart is simpler: only sequential and conditional flows, single actor, not part of UML standard.
Practice Questions
Q1: Draw an activity diagram for 'Student Course Registration' with swim lanes for: Student,
System, Professor.
Q2: Draw an activity diagram for 'ATM Withdrawal' including decision nodes for PIN verification
and balance check.
Q3: Explain the difference between Fork/Join nodes and Decision/Merge nodes in an activity
diagram with an example.
6. State Chart Diagram
What is it?
A State Chart Diagram (also called State Machine Diagram) shows the different states an object can be in
throughout its life and the transitions between those states. It models the dynamic behavior of a SINGLE
object in response to events.
Key Components
Component Description
Initial State Solid filled black circle. Where the object's life begins.
Rounded rectangle with the state name inside. The condition the object is
State in.
Final State Bullseye (circle within circle). End of the object's life.
Transition Solid arrow from one state to another, labeled: event [condition] / action
Something that causes the transition (e.g., buttonClicked, timeout,
Event paymentReceived)
Guard Condition Boolean condition in [ ] that must be true for transition to fire.
Action Activity executed during the transition (after /).
Entry Action Action performed when entering a state (entry: doSomething)
Exit Action Action performed when leaving a state (exit: doSomething)
Do Activity Activity that runs while the object is in that state (do: processData)
Composite State A state that contains nested sub-states (inner state machine).
Transition Syntax (Very Important)
Format: event [guard_condition] / action
Transition Label Breakdown
Event: paymentMade | Guard: amount > 0 | Action:
paymentMade [amount > 0] / generateReceipt generateReceipt
timeout [attempts >= 3] / lockAccount Event: timeout | Guard: 3 attempts | Action: lock
bookAvailable / sendNotification Event with no guard, just action
[items in cart] / proceedToCheckout Guard-only transition (no event name)
Step-by-Step: How to Draw
1. Choose the object whose lifecycle you are modeling (e.g., Order, Book, Account).
2. List all possible states the object can be in (e.g., New, Processing, Shipped, Delivered).
3. Draw the Initial State (black circle) and connect to the first state.
4. Draw each state as a rounded rectangle.
5. Identify events that cause transitions between states.
6. Draw arrows between states, labeled with: event [condition] / action.
7. Add entry/exit/do actions inside the state box if required.
8. Draw the Final State (bullseye) where the object's life ends.
9. Verify: every state must have at least one incoming and one outgoing transition (except start/end).
Example — Order Object State Chart
State Entry Action Possible Transitions (Event → Next State)
New entry: generateOrderId orderConfirmed → Processing
cancelled → Cancelled
Processing entry: notifyWarehouse paymentReceived [paid] → Shipped
paymentFailed → Cancelled
Shipped entry: sendTrackingNo delivered → Delivered
returned → Returned
Delivered entry: closeOrder refundRequested → Returned
Cancelled entry: refundAmount — (Final State)
Returned entry: processRefund — (Final State)
Practice Questions
Q1: Draw a state chart diagram for a 'Library Book'. States include: Available, Reserved,
Borrowed, Lost, Under Repair.
Q2: Draw a state chart diagram for a 'Bank Account'. Include states: Active, Suspended, Frozen,
Closed. Show all transitions with events and guard conditions.
Q3: What is the difference between an Activity Diagram and a State Chart Diagram? When would
you use each?
7. Scenario Diagram · Scenario Matrix · Test Case
Matrix
Scenario Diagram — What is it?
A Scenario Diagram (also called an instance-level sequence diagram) shows ONE specific execution path
of a use case with actual object names and real values. It is essentially a Sequence Diagram with concrete
data instead of generic messages.
Scenario Matrix — What is it?
A Scenario Matrix is a table that systematically lists all possible scenarios for a use case by combining
different conditions. Each row represents one unique combination of conditions, giving a unique scenario
with a specific outcome.
How to Build a Scenario Matrix — Step by Step
1. Identify the use case (e.g., User Login).
2. List all conditions that can vary (e.g., username valid?, password correct?, account active?).
3. Create columns: Scenario ID | Condition 1 | Condition 2 | ... | Outcome.
4. Fill each row with T (True/Valid) or F (False/Invalid) for each condition.
5. Determine the Expected Outcome for each combination.
6. Mark which scenarios are Valid (test both expected success and expected failure).
Example — Login Scenario Matrix
Scenario ID Username Valid? Password Correct? Account Active? Expected Outcome
SC-01 T T T Login Success — Dashboard shown
SC-02 T F T Login Fail — Wrong password error
SC-03 F T T Login Fail — User not found error
SC-04 T T F Login Fail — Account suspended message
SC-05 F F F Login Fail — User not found error
SC-06 T F (×3) T Account Locked — Too many attempts
Test Case Matrix — What is it?
A Test Case Matrix maps each scenario to specific test cases with actual input values, expected outputs,
and actual outputs (if testing is done). It is the bridge between scenarios and actual software testing.
Test Case Matrix — Without Actual Values (Standard Format)
TC ID Scenario Test Input Expected Output Pass/Fail
TC-01 SC-01 Valid user, correct pwd Login success —
TC-02 SC-02 Valid user, wrong pwd Error: wrong password —
TC-03 SC-03 Invalid username Error: user not found —
TC-04 SC-04 Valid user, inactive acct Error: account suspended —
TC-05 SC-06 3 wrong passwords Account locked message —
Test Case Matrix — With Actual Values
TC ID Input (Actual Values) Expected Output Actual Output Result
TC-01 user='john@[Link]' Dashboard displayed Dashboard displayed PASS
pwd='Pass@123'
TC-02 user='john@[Link]' 'Wrong password' error 'Wrong password' error PASS
pwd='wrongpwd'
TC-03 user='ghost@[Link]' 'User not found' error 'User not found' error PASS
pwd='Pass@123'
TC-04 user='john@[Link]' 'Account suspended' App crashed FAIL
pwd='Pass@123'
account=INACTIVE
TC-05 user='john@[Link]' 'Account Locked' msg 'Account Locked' msg PASS
3× pwd='wrongpwd'
Practice Questions
Q1: Create a Scenario Matrix for 'ATM Cash Withdrawal' with conditions: PIN correct?, Sufficient
balance?, Card valid?
Q2: Based on your scenario matrix for ATM withdrawal, create a Test Case Matrix with actual
values. Show at least 5 test cases.
Q3: What is the difference between a Scenario Matrix and a Test Case Matrix? Why are both
needed in software testing?
8. Collaboration Diagram
What is it?
A Collaboration Diagram (called Communication Diagram in UML 2.x) shows the structural organization of
objects and their interactions. Unlike Sequence Diagrams, it emphasizes the LINKS between objects
rather than time order. Messages are numbered to show sequence.
Key Difference: Sequence vs Collaboration
Aspect Sequence Diagram Collaboration Diagram
Focus TIME ORDER of messages (vertical axis) STRUCTURAL LINKS between objects
Time Shown by vertical position (top=first) Shown by message numbering (1, 2, 3...)
Lifelines Yes — vertical dashed lines No — objects shown as boxes/nodes
Links Not emphasized Explicitly shown as lines between objects
Best for Understanding flow / sequence of events Understanding which objects interact & how
Also called Sequence Diagram (UML 1 & 2) Communication Diagram (UML 2.x)
Key Components
Component Description
Object Shown as a rectangle: objectName : ClassName (e.g., john : Customer)
Link Solid line connecting two objects that communicate.
Message Arrow on the link labeled with a sequence number and method name.
Sequence Number Numbers like 1, 2, 3... or nested 1.1, 1.2 for sub-messages.
Self-Link A curved arrow from an object back to itself (self-message).
Guard Condition Shown in [ ] on the message label: 1.1 [balance>0] : debitAmount()
Iteration Shown with * : 3 * : printItem() — means repeated call
Message Numbering — Nested Calls
Number Meaning
1 First message in the entire interaction
2 Second top-level message
1.1 First sub-message triggered by message 1
1.2 Second sub-message triggered by message 1
1.1.1 Sub-sub-message triggered by message 1.1
3* Message 3 is sent iteratively (in a loop)
[x>0] 2 Message 2 is conditional (only sent if x > 0)
Step-by-Step: How to Draw
1. Identify all objects that participate in the interaction.
2. Draw each object as a rectangle labeled objectName : ClassName.
3. Draw links (solid lines) between objects that send/receive messages.
4. Number all messages sequentially (1, 2, 3...). Use nested numbers (1.1, 1.2) for sub-calls.
5. Label each link with: sequenceNumber [condition] * : messageName(params).
6. Add arrowheads on the links showing direction of communication.
7. Add a self-link for any self-messages (object calling its own method).
8. Verify: the sequence of numbered messages should match the same sequence diagram.
Example — Login Collaboration Diagram
Message # From Object To Object Message Label
1 :User (Actor) :LoginForm 1: submitCredentials(user, pwd)
2 :LoginForm :AuthService 2: authenticate(user, pwd)
2.1 :AuthService :UserDB 2.1: findUser(username)
2.2 :UserDB :AuthService 2.2: return userRecord
2.3 :AuthService :UserDB 2.3: [pwd matches] verifyPassword(pwd)
3 :AuthService :LoginForm 3: return sessionToken / error
4 :LoginForm :User 4: displayDashboard() / showError()
Practice Questions
Q1: Draw a collaboration diagram for 'ATM Cash Withdrawal'. Objects: Customer, ATMInterface,
AccountManager, Bank Database. Number all messages correctly.
Q2: Convert this sequence diagram to a collaboration diagram: User → BookingSystem →
PaymentGateway → EmailService (for Online Ticket Booking).
Q3: Explain with a diagram the use of nested message numbers (1, 1.1, 1.2, 2) in a collaboration
diagram. Why are they important?
Quick Reference — Exam Cheat Sheet
Diagram Type Shows Key Symbols
Use Case Behavioral What the system does Stick figure, Oval, System box, «include»/«extend»
Use Case Description Textual Step-by-step use case detail Table: Pre/Post/MainFlow/Alt/Exception
Class Structural Classes, attributes, methods 3-part rectangle, +/-/#, arrows for relationships
Sequence Behavioral Time-ordered object interaction Lifelines, activation bars, sync/async arrows, alt/opt/loop
Activity Behavioral Flow of activities/actions Initial node, activity box, diamond, fork/join bars, swim lane
State Chart Behavioral States of ONE object Rounded rect (state), bullseye, event[guard]/action on arrow
Scenario Matrix Analytical All condition combinations Table: ScenarioID | Conditions (T/F) | Expected Outcome
Test Case Matrix Testing Actual test cases with values Table: TCID | Input | Expected | Actual | Pass/Fail
Collaboration Behavioral Object links + numbered msgs Object boxes, links with numbered arrows (1, 1.1, 2...)
Common Exam Tips
• Always label your diagram type at the top (e.g., 'Use Case Diagram — Library System').
• In Use Case Diagrams: actors go OUTSIDE the system boundary, use cases go INSIDE.
• «include» arrow points FROM the base use case TO the included one. «extend» points FROM
extending TO base.
• In Class Diagrams: filled diamond = Composition (strong), hollow diamond = Aggregation (weak).
• In Sequence Diagrams: TIME flows top to bottom. Return messages are DASHED arrows.
• In State Charts: label transitions as: event [guard] / action — all three parts may not always be
present.
• Collaboration Diagram: number messages 1, 2, 3... Nested sub-messages use 1.1, 1.2, 1.1.1 etc.
• Activity Diagram: Use Fork (thick bar) for parallel AND-splits; Diamond for conditional OR-splits.
• Test Case Matrix with actual values must have: Input Values, Expected Output, Actual Output,
Pass/Fail.
• Scenario Matrix uses T/F for conditions; Test Case Matrix uses real values.
Good luck on your exam! You've got this. ■