SE311 / UML Class & Use Case Diagrams
SE 311 · Requirements Engineering · Study Aid

UML Diagrams Cheat Sheet

A complete, exam-focused guide to drawing Class Diagrams and Use Case Diagrams using the Smart Parking System as the worked example.

Class DiagramsUse Case DiagramsSmart Parking Case StudyExam Ready
1

Introduction to UML Diagrams

What are they, and when do you use each one?

📐 Class Diagram

A structural diagram that shows classes, attributes, methods, and relationships. Think of it as a blueprint of the system data.

When to useDuring Requirements Analysis to model domain objects and their connections.
🎭 Use Case Diagram

A behavioral diagram that shows what the system does from the user's perspective. It maps actors to goals.

When to useDuring Requirements Elicitation to capture functional requirements and interactions.
Comparison Table
Feature Class Diagram Use Case Diagram
Type Structural Behavioral
Focus What data exists and how it relates What users can do with the system
Main element Classes with attributes and methods Actors and use cases
Relationship types Association, inheritance, composition, aggregation Association, include, extend, generalization
Answers "What is the system made of?" "Who does what with the system?"
CD

Class Diagram - Cheat Sheet

Everything you need to draw a correct class diagram

Class Box Format
ClassName
- attributeName: type
- anotherAttr: type
+ methodName(): returnType

Top: class name. Middle: attributes. Bottom: methods or operations.

Exam NoteIn domain models, the methods section is often left empty. Focus on classes, attributes, relationships, multiplicity, and constraints.
Visibility Symbols
+
Public
Accessible from anywhere
−
Private
Only within the class
#
Protected
Class and subclasses
Relationship Types
Relationship Symbol Meaning Example
Association ────── A general connection. Customer -> Review
Aggregation ◇────── Weak has-a ownership. ParkingArea ◇── ParkingSlot
Composition ◆────── Strong has-a ownership. ParkingSession ◆── Payment
Inheritance ──────▷ Is-a relationship. Member ──▷ Customer
Dependency - - - -→ Temporary use. Payment - - -> PaymentGateway
Multiplicity
Notation Meaning Example
1 Exactly one ParkingSession has exactly 1 Payment
0..1 Zero or one A slot may or may not have a Reservation
0..* Zero or more A Customer can have many ParkingSessions
1..* One or more A ParkingArea has at least one ParkingSlot
0..3 Zero up to 3 A Member can have 0 to 3 active Reservations
Smart Parking ConstraintAdd { max 3 active reservations per member }.
🪜 Step-by-Step: How to Draw a Class Diagram
Find nouns

Customer, Member, ParkingArea, ParkingSlot, Reservation, ParkingSession, Payment, Review, Administrator.

Remove weak or implementation classes

Remove Database, WebServer, LoginPage, Button, Screen, and vague System classes.

Add attributes

Use persistent information from the scenario.

Find relationships

Member makes Reservation; Member is a Customer; ParkingSession has Payment.

Add multiplicity

Put numbers at both ends of every association.

Add constraints

Use curly braces for rules like the maximum three reservations rule.

⚠️ Common Mistakes - Class Diagrams
MistakeIncluding implementation classes like Database, WebServer, LoginPage, Button, or Screen.
MistakeMaking actions into classes, such as Login or Browse.
MistakeForgetting multiplicity at both ends.
✅ Exam Checklist - Class Diagram
  • Every class has a singular noun name
  • Relevant attributes are listed with types
  • Visibility symbols are used consistently
  • Inheritance arrow points to the parent
  • Multiplicity appears at both association ends
  • Constraints are shown in curly braces
  • No UI, database, or web server classes
UC

Use Case Diagram - Cheat Sheet

Everything you need to draw a correct use case diagram

Elements & Notation
Element Notation Description
Actor Stick figure External person or system.
Use Case Oval User goal written as a verb phrase.
System Boundary Rectangle Use cases inside; actors outside.
«include» Dashed arrow Mandatory behavior.
«extend» Dashed arrow Optional behavior.
«include» explained

Always happens.

End Parking Session
  «include» -> Make Online Payment
«extend» explained

Sometimes happens.

Leave Feedback
  «extend» -> Rate Parking Area
🪜 Step-by-Step: How to Draw a Use Case Diagram
Identify actors

Customer, Member, Administrator, Payment Gateway.

Identify user goals

Use verb phrases like View Available Slots and Reserve Slot.

Draw the system boundary

Use cases inside and actors outside.

Connect actors to use cases

Use solid association lines.

Check include and extend

Include is mandatory. Extend is optional.

⚠️ Common Mistakes - Use Case Diagrams
MistakeMaking devices or UI components actors.
MistakeAdding too many include or extend relationships.
MistakePutting Login as a standalone use case.
✅ Exam Checklist - Use Case Diagram
  • System boundary is drawn and labeled
  • Actors are outside the boundary
  • Use cases are inside the boundary
  • Each use case uses a verb phrase
  • Every actor connects to at least one use case
  • Include and extend arrows point correctly
★

Worked Example: Smart Parking System

Full class diagram and use case diagram with explanations

📖 System Scenario

A web-based system manages a smart parking service. The system handles multiple parking areas and parking slots. It records which customers reserve or use parking slots and when.

For each parking session, the start time, end time, and total fee are recorded. The system tracks available and occupied parking slots in real time.

Members can reserve parking slots in advance. A member can reserve up to 3 parking slots at a time. Customers can make online payments, rate parking areas from 1-5, and leave anonymous feedback.

The system stores customer information: name, phone number, car plate number, and email. Members have a membership ID and password. Administrators manage parking areas and slots, including location and pricing details.

📐 Class Diagram - Smart Parking System

Scroll horizontally on mobile. Connector lines are routed around class boxes to avoid overlaps.

Member - membershipId: String- password: String- monthlyFee: Decimal- discountRate: Float - methods - Customer - name: String- phoneNumber: String- carPlateNumber: String- email: String - methods - Administrator - adminId: String- name: String- email: String - methods - Reservation - reservationId: String- reservationDate: Date- startTime: DateTime- endTime: DateTime- status: Enum ParkingArea - areaId: String- location: String- pricingDetails: Decimal- averageRating: Float ParkingSession - sessionId: String- startTime: DateTime- endTime: DateTime- totalFee: Decimal ParkingSlot - slotId: String- status: Enum- type: String Payment - paymentId: String- amount: Decimal- paymentDate: Date- method: String- status: Enum Review - reviewId: String- rating: Int (1..5)- feedback: String- isAnonymous: Boolean «inherits» makes10..3 { max 3 per member } has10..* manages10..* manages10..* 11..* for1..*1 uses0..*1 has11 writes10..* for0..*1
Inheritance
Composition
Aggregation
Reservation
Customer/session
Admin
Review
💡 Why each class and relationship?
Why these classes? ▶
Class Why included
Customer Customers park, pay, and review.
Member Specialized Customer with reservations and discounts.
ParkingArea Represents managed locations and pricing.
ParkingSlot Represents slots and availability status.
Reservation Records advance bookings.
ParkingSession Records actual use and fee.
Payment Stores payment details.
Review Stores rating, feedback, and anonymity.
Why Composition vs. Aggregation? ▶
CompositionParkingSession to Payment is strong ownership.
AggregationParkingArea to ParkingSlot is weaker whole-part ownership.
🎭 Use Case Diagram - Smart Parking System

Scroll horizontally on mobile. Actor links use short, direct routes and include/extend arrows follow UML direction rules.

Smart Parking System Customer Member Admin PaymentGateway View AvailableParking Slots Start ParkingSession End ParkingSession Make OnlinePayment Rate ParkingArea Leave Feedback Reserve ParkingSlot Register asMember Manage ParkingAreas Manage ParkingSlots Update PricingDetails Track SlotAvailability «include» «include» «extend»
Customer
Member
Admin
Payment Gateway
include
extend
💡 Why each actor, use case, and relationship?
Why these actors? ▶
Actor Why included
Customer Primary user who parks, pays, and reviews.
Member Specialized customer with reservation privileges.
Administrator Manages infrastructure and pricing.
Payment Gateway External payment processor.
Why «include» and «extend»? ▶
IncludeEnd Session includes Make Online Payment; Reserve Slot includes View Available Slots.
ExtendLeave Feedback extends Rate Parking Area because feedback is optional.
✓

Before You Submit - Final Checklist

Run through this before handing in any UML assignment

📐 Class Diagram Final Check
  • Every requirement noun is represented by a class or attribute
  • No implementation classes
  • Attributes use visibility symbols
  • Multiplicity is shown at both ends
  • Generalization arrow points to the parent class
  • Constraints are written in curly braces
🎭 Use Case Diagram Final Check
  • System boundary is drawn and labeled
  • Actors are outside the boundary
  • Use cases are inside the boundary
  • Use cases use verb phrases
  • Include and extend arrows point correctly
  • Login is not listed as a goal use case
🎯 Final Exam TipThe most common reason for lost marks: missing multiplicities on class diagrams and wrong include/extend direction on use case diagrams.
Prepared by: Shoug Alomran · SE 311 Software Requirements Engineering