Week 8 Lesson

UML and Practical Design Diagrams

A useful diagram explains one idea clearly.

UMLclass diagramsequence diagramcomponent diagramuse casearchitecture sketch

Learning Objectives

  • Create class diagrams that show responsibility and relationships.
  • Create sequence diagrams for important workflows.
  • Create component diagrams for high-level system structure.
  • Decide when a diagram is useful and when it is too much.

Lecture Notes

Diagrams are communication tools. Their purpose is not to decorate a project or satisfy a checklist. A good diagram answers a question. What classes are involved? What talks to what? What happens during checkout? Where does data flow? If a diagram does not answer a question, it probably needs a clearer purpose.

Class diagrams show classes, fields, methods, and relationships. For most student projects, the diagram should focus on important domain classes and dependencies, not every getter and setter. A class diagram for a library system might show Book, Patron, Loan, LoanPolicy, and CatalogRepository. The valuable part is seeing responsibility and relationship at a glance.

Sequence diagrams show interactions over time. They are excellent for workflows such as login, checkout, enrollment, or sending reminders. A sequence diagram makes hidden dependencies visible. If the UI directly calls the database, payment service, and email service during checkout, the diagram reveals a design smell.

Component diagrams show larger parts of the system: Web UI, API, Domain Services, Database, Notification Provider, Payment Provider. These diagrams are useful for architecture conversations. They do not need to include every class. They should show boundaries and communication paths.

UML notation can become overwhelming. In this course, correctness of thought matters more than perfect notation. Students should learn enough notation to communicate clearly, then keep diagrams lean. A messy diagram with every possible detail can be less useful than a simple sketch with good labels.

Worked Example: Mermaid class diagram example

Before
classDiagram
class AppEverything
After / Better
classDiagram
class Task {
  +title: string
  +dueDate: Date
  +complete()
}
class TaskRepository {
  +save(task)
  +findAll()
}
class ScheduleService {
  +upcomingTasks(tasks, today)
}
class DashboardView
DashboardView --> ScheduleService
ScheduleService --> Task
TaskRepository --> Task
Design lesson: The good diagram shows the main objects and dependencies without drowning the reader in every implementation detail.

Lab: Diagram a Workflow

Scenario: Model the checkout workflow for a food ordering app.

Steps

  1. Write the workflow in plain English.
  2. Create a sequence diagram for the workflow.
  3. Create a class or component diagram for the same system.
  4. Mark one dependency that could become a problem.
  5. Explain the design improvement you would make.

Deliverables

  • Sequence diagram
  • Class/component diagram
  • Design note

Assignment

Create two diagrams for your capstone: one class/module diagram and one sequence diagram for the most important workflow.

Discussion Prompts

  • What makes a diagram too detailed?
  • Who is the audience for a design diagram?
  • Should diagrams be updated after code changes?

Week 8 Quiz

Use these as quick checks after the lesson.

Question 1

A sequence diagram is best for showing:

Question 2

A class diagram is useful for showing:

Question 3

A component diagram usually shows:

Question 4

A useful diagram should:

Question 5

For this course, diagram value is measured mostly by:

Student Notes

Saved in this browser only.