# Common UML Diagrams

UML is a shared way of drawing software. A use case diagram shows who uses the system and for what, a class diagram shows the classes and how they're related, and a sequence diagram shows the messages that pass between parts, in order. Sketch them to think and to explain.

Apprentice · Software Development · OOP · Updated November 3, 2026

## After this lesson you can

- Read and sketch use case, class and sequence diagrams

## Key takeaways

- A use case diagram shows the actors, as stick figures, and what they do with the system, as ovals named with a verb, inside the system boundary.
- In a class diagram, each class is a box with its name, properties and methods; `+` means `public` and `-` means `private`.
- A hollow triangle points at the parent or the interface: a solid line means inheritance, a dashed line means implements.
- A sequence diagram reads top to bottom, in time order: solid arrows are calls or requests, dashed arrows are replies.
- Keep diagrams small and quick. They're tools for thinking and explaining, not documents to keep perfect.

Before a builder lays a brick, there's a drawing everyone can read: the owner, the architect, the electrician. Software has one too. **UML**, the Unified Modeling Language, is a standard set of diagrams for drawing software, so that a developer, a tester and a product owner can all point at the same picture.

UML has more than a dozen kinds of diagram. Three cover almost everything you'll draw in your first years: **use case**, **class** and **sequence** diagrams. You don't need special software: a whiteboard or paper is fine. The point is to think, and to explain.

## Use case diagrams: who does what

A **use case diagram** shows **who** uses the system, and **what** they use it for. It's drawn before any code, to agree on what to build.

![A use case diagram of the Northwind products app: a box labeled "Northwind products app" holds four ovals: "Browse products", "Sign in", "Add a product" and "Delete a product". A stick figure "Visitor" outside the box is joined to "Browse products" and "Sign in"; a stick figure "User" to "Add a product"; a stick figure "Admin" to "Delete a product". An arrow with a hollow triangle points from Admin to User, and from User to Visitor.](https://fsdtrainingmedia.blob.core.windows.net/public/images/2026/11/f8cca26a2d224284b0977418f6657d99.webp)

| Shape | Means |
|---|---|
| Stick figure | An **actor**: a person, or another system, outside the system that uses it |
| Oval | A **use case**: something an actor does with the system, named with a verb, such as *Add a product* |
| Box | The **system boundary**: what's inside is what you're building |
| Line | This actor takes part in this use case |
| Arrow with a hollow triangle | One actor is a kind of another: an Admin can do everything a User can, and more |

That's the products app from *Exercise: Secure the App*, at a glance: anyone browses, users add, admins delete.

## Class diagrams: the classes and their relationships

A **class diagram** shows the classes: their properties, their methods, and how they're related. It's the diagram closest to code.

![A class diagram. A box "«interface» IProductDao" lists "+ GetAllAsync(categoryId: int?): Task<List&lt;Product>>" and "+ DeleteAsync(productId: int): Task&lt;bool>". Below it, a box "ProductDao" with "- connectionString: string" and the same two methods; a dashed arrow with a hollow triangle points from ProductDao up to IProductDao. To the side, a box "ProductsController" with "- productDao: IProductDao" has a solid arrow pointing to IProductDao. A box "Product" lists "+ ProductId: int", "+ ProductName: string" and "+ UnitPrice: decimal?".](https://fsdtrainingmedia.blob.core.windows.net/public/images/2026/11/4c5fd0b365ef45528d2f930ea9058ccf.webp)

Each class is a box in three parts: its **name**, its **properties**, and its **methods**. The diagram above is this code:

```csharp
public interface IProductDao
{
    Task<List<Product>> GetAllAsync(int? categoryId);
    Task<bool> DeleteAsync(int productId);
}

public class ProductDao : IProductDao
{
    private readonly string connectionString;
    // ...
}

public class ProductsController : ControllerBase
{
    private readonly IProductDao productDao;
    // ...
}
```

| Notation | Means |
|---|---|
| `+` | `public` |
| `-` | `private` |
| `#` | `protected` |
| `name: type` | A property or field, such as `+ ProductName: string` |
| `Method(parameter: type): returnType` | A method |
| «interface» above the name | An interface |
| Solid line, hollow triangle | **Inheritance**: `class SavingsAccount : BankAccount`. The triangle points at the parent. |
| Dashed line, hollow triangle | **Implements**: `class ProductDao : IProductDao` |
| Solid arrow | **Association**: one class uses or holds another, as `ProductsController` holds an `IProductDao` |
| Solid diamond | **Composition**: a part that can't exist without its whole, such as an order's lines |

You've seen these pictures before, in the inheritance and interfaces lessons. A class diagram doesn't need every property: draw what matters for the point you're making.

## Sequence diagrams: who talks to whom, in order

A **sequence diagram** shows the **messages** that pass between parts of the system, top to bottom, in the order they happen. It's how you explain a flow, such as signing in:

![A sequence diagram with five lifelines across the top: "Browser", "Angular app", "AuthController", "UserDao" and "Database". Arrows, top to bottom: Browser to Angular app "clicks Sign in"; Angular app to AuthController "POST /api/auth/login"; AuthController to UserDao "GetByUserNameAsync(userName)"; UserDao to Database "SELECT ... FROM Users"; a dashed arrow back from Database to UserDao "the user's row"; a dashed arrow from UserDao to AuthController "AppUser"; a note on AuthController "checks the password with PasswordHasher, makes a token"; a dashed arrow from AuthController to Angular app "200 { token, userName, role }"; and Angular app to Browser "shows Signed in as ada".](https://fsdtrainingmedia.blob.core.windows.net/public/images/2026/11/d4d36d9ce5dd4824bbad16261dfd4680.webp)

| Shape | Means |
|---|---|
| Box at the top, with a dashed line down | A **lifeline**: one part of the system, over time |
| Solid arrow | A **message**: a call or a request |
| Dashed arrow | A **reply**: what comes back |
| Top to bottom | **Time**: earlier messages are higher |

Reading it top to bottom tells the story: the browser asks the app, the app asks the API, the API asks the DAO, the DAO asks the database, and the answers come back in reverse. Sequence diagrams are great for spotting problems, such as one page that calls the API ten times.

## When to draw them

| Diagram | Draw it to |
|---|---|
| Use case | Agree on what to build, with people who don't write code |
| Class | Plan, or explain, how the code is organized |
| Sequence | Explain, or debug, a flow through several parts |

Keep them **small** and **quick**. A diagram is a tool for thinking and talking, not a document to keep perfect. In interviews, being able to sketch a class or sequence diagram on a whiteboard is a real plus.

## Check yourself

1 question to try on the lesson page.

## So what

Use case diagrams say who does what, class diagrams say how the code is built, and sequence diagrams say what happens in what order. Learn the handful of shapes, and you can read, and sketch, the drawings every team uses.

## Key terms

- Use Case Diagram
- [UML Class Diagram](https://www.ask-codey.com/glossary/uml-class-diagram)
- Sequence Diagram

## Cheat sheets

- [Common UML Diagrams](https://www.ask-codey.com/cheat-sheets/uml-diagrams-common-uml-diagrams-cheat-sheet)

Source: https://www.ask-codey.com/lessons/uml-diagrams-common-uml-diagrams