Modeling & Notations
Modeling is the translation of a fuzzy conversation about a system into an unambiguous diagram that an analyst, a developer, and a stakeholder all read the same way. A notation sets the rules of that translation — a set of shapes with fixed meaning — so the goal is not to "draw it nicely" but to pick the notation for the job and not confuse what each kind of diagram shows.
There are two large notations here: UML describes a system's structure and behavior, BPMN describes business processes. Common interview traps are mixing UML with BPMN, naming one diagram type for every purpose, or confusing a sequence diagram (interaction over time) with a class diagram (structure). The full map lives in the layers below.
Topic map
- Modeling notations — UML, BPMN, and the doc-as-code approach: how they differ and what each describes.
- Diagram types — which diagrams belong in system documentation and the question each one answers.
- Use case — a formalized description of an actor interacting with the system: actors, flows, pre- and post-conditions.
- Use case, user story, and job story — three levels of describing a need and where each fits.
- Sequence diagram — participant interaction ordered in time via lifelines and messages.
- BPMN elements — events, tasks, gateways, and flows as the notation's base categories.
- BPMN gateways — how exclusive, parallel, inclusive, and event-based gateways route the flow.
Common traps
| Mistake | Consequence |
|---|---|
| Mixing UML (structure/behavior) with BPMN (business processes) | The diagram answers the wrong question; readers interpret it differently |
| Naming one diagram type for every purpose | You skip data, interaction, or deployment — the picture is incomplete |
| Confusing a sequence diagram with a class diagram | You lose the time axis and message order — the scenario is unreadable |
| Treating BPMN flows as plain arrows | Step order disappears; the process becomes a set of disconnected boxes |
| Swapping exclusive and parallel gateways | The process branches down every path instead of one, or vice versa — the logic breaks |
| Confusing a use case with a one-line user story | You lose alternative flows, exceptions, and conditions — the spec is incomplete |
Interview relevance
Modeling is asked to check whether you tell the notations apart and understand what each diagram shows. A candidate who says "UML is about structure and behavior, BPMN is about the business process, and a sequence diagram is about interaction over time" immediately gets ahead of one who calls everything a "flowchart".
Typical checks:
- Which notations you use and how UML differs from BPMN.
- Which diagram types documentation needs and the question each answers.
- What a use case consists of and how it differs from a user story and a job story.
- BPMN elements and gateways: naming the four categories and the gateway semantics.
Common wrong answer: "UML and BPMN are the same thing, just different pictures." In fact they are different notations with different scope: UML models the system (classes, states, interactions), BPMN models the flow of a business process through events, tasks, gateways, and flows.