Study notes on software engineering — with a focus on diagrams.
Software development isn't about writing CRUD. The real skill is how clearly you can visualize a complex system's business logic before writing a single line of code. That skill is diagrams.
The headline note: the 9 most common software diagrams, each explained with one running example — a hotel management system 🏨. Every diagram is written in Mermaid, so it renders right here on GitHub.
| # | Diagram | Answers |
|---|---|---|
| 1 | Use case | Who can do what? |
| 2 | ER | How is the data structured? |
| 3 | Class | How is the code structured? |
| 4 | Sequence | What happens, in what order? |
| 5 | Activity | What is the logic of one process? |
| 6 | State | How does one object's status change? |
| 7 | Component | What software pieces fit together? |
| 8 | Deployment | Where does each piece run? |
| 9 | Data flow (DFD) | How does data move through the system? |
Rule of thumb: use case = scope/who · ER = database · class = code · sequence = interaction over time · activity = one workflow's logic · state = one object's lifecycle · component = software pieces · deployment = where they run · DFD = where data flows.
A lightweight note system: capture into inbox/, refine into topics/, retire to archive/.
| Folder | Purpose |
|---|---|
inbox/ |
Frictionless capture — one idea per file, messy is fine. |
topics/ |
Durable, organized notes — one file per topic. |
archive/ |
Superseded or stale notes kept for reference. |
See topics/index.md for the full topic map.
