Opening questions worth asking yourself: how often do you create diagrams and do modelling? What kinds of diagrams do you create? What tools do you use?
Notation formality
Three main categories of notation, shown as a pyramid representing usage and popularity:
| Category | Examples | Character |
|---|---|---|
| Informal | Boxes and lines | Widest usage |
| Semi-formal | UML, BPMN, ArchiMate | Middle |
| Formal | AADL — e.g. the graphical definition of a speed control system | Narrowest |
A diagram without a key makes it genuinely difficult to identify the different elements. The course demonstrates this deliberately with a keyless diagram for discussion. Always provide a legend.
UML
UML's diagram set splits into two top-level categories: structural diagrams (class, object, package, profile, composite structure, component, deployment) capture the static shape of a system, while behavioral diagrams (use case, activity, state machine, sequence, communication, timing, interaction overview) capture how it behaves over time. This structural/behavioral split is the organising principle behind UML's roughly thirteen diagram types, of which class, sequence and use case are simply the most frequently used in practice.
The UML specification is updated and managed by the Object Management Group. The first versions were created by the "Three Amigos" — Grady Booch (creator of the Booch method), Ivar Jacobson (Object-Oriented Software Engineering, OOSE), and Jim Rumbaugh (Object-Modeling Technique, OMT).
| Version | Date | Change |
|---|---|---|
| 1.3 | 03-2000 | A number of changes to the UML metamodel, semantics and notation, but considered a minor upgrade to the original proposal |
| 1.4.2 | 01-2005 | Accepted as ISO specification ISO/IEC 19501. (UML 1.5 was released two years earlier) |
| 2.0 | 08-2005 | New diagrams: object, package, composite structure, interaction overview, timing, profile. Collaboration diagrams renamed communication diagrams |
| 2.5 | 06-2015 | Called a "minor revision" to UML 2.4.1, but a lot of effort went into simplifying and reorganizing the specification document, which was re-written "to make it easier to read" — for example reducing forward references as much as possible |
Popularity of UML is decreasing. The top three diagrams in practice: class, sequence, use case.
Today, when UML notation is not so widely used due to objective reasons, we can use the "boxes and lines" notation for any view.
BPMN, ArchiMate and behavioural diagrams
BPMN is semi-formal. Beyond the standard diagram set:
- Conversation diagrams — represent groups of messages called "communications" and their relation between process and participants
- Choreography diagrams — represent participant interaction between task and users or resources, and the messages resulting from this interaction
- Swim lanes are partitioned
BPMN also defines its own symbol vocabulary worth knowing by name: gateways (exclusive, inclusive, parallel, and event-based) control branching and merging of flow, pools and lanes partition a process by participant, and dedicated icon families distinguish task types (user, service, manual, script, send, receive, business rule) from event types (start, intermediate, end, each combinable with triggers like message, timer, signal, or error). BPMN 2.0 also distinguishes a process diagram, which models a single participant's internal flow, from a collaboration diagram, which shows multiple participants' pools exchanging message flows with each other.
ArchiMate is a semi-formal enterprise architecture modelling language.
The module also covers two notations outside the UML/BPMN/ArchiMate trio: the flowchart/swimlane (also called a cross-functional diagram), which divides a process's steps into lanes by department, role, or system to show who is responsible for each step, and the mind map, which organises ideas as branches radiating outward from a single central concept rather than as a sequential flow.
There are also many similar diagrams for behaviour and state: UML Activity, Data flow, UML State, BPMN.
Diagram hygiene
When tidying up a diagram, think about:
- Aligning elements — either by one of their sides (e.g. top) or by their centres; the latter works best when aligning vertically
- Making elements the same size where possible
- Always including a key
A few further named rules round out the discipline: Less is more (an overloaded diagram with too many elements conveys less than a small, focused one, since the audience cannot tell what to focus on and disengages), No crossings (avoid letting any two connector lines cross), and Orthogonality (restrict connectors to strictly horizontal or vertical segments with right-angle bends, which instantly makes a diagram look more professional). A further rule, Hierarchies, requires that generalisation or realisation relationships be drawn with parent elements above their children so inheritance arrows consistently point upward.
Exercises — Module 5
Task. Draw two diagrams for Lumen Diagnostics. Output: one context diagram and one container diagram (C4 or equivalent). You will reuse them in the Module 6 SAD.
- Read the Lumen Diagnostics case
- Draw a context diagram (scheduling platform at the centre)
- Referral management system, patient identity service, SSO
- The one automated partner API
- Patients, referral desk, Scheduling Manager, partner practices
- Draw a container diagram of the platform
- Portals, offer/workflow service, search, notifications, data stores
- Apply the diagram-hygiene rules from this module
- Label each connector with the protocol or data, not just "uses"