Unit 4: Behavioural Modelling
Learning Objectives
- Create use case diagrams that accurately represent system scope, actors, and goal relationships
- Select the appropriate behavioural diagram for a given modelling challenge
- Model alternative flows and exception conditions, not only the happy path
- Evaluate the effectiveness and limitations of behavioural models
Core Input
Read through each tab before working through the key concepts.
A use case diagram captures the goals that actors want to achieve using a system. It is the primary tool for defining system scope and communicating requirements to non-technical stakeholders.
Key elements:
- Actor — any entity outside the system boundary that interacts with it. Actors can be human users, external systems, or time-triggered events.
- Use case — a goal that an actor wants to achieve. Named as a verb-noun phrase: Book Appointment, Cancel Referral, Generate Availability Report.
- System boundary — the rectangle that defines what is inside the system and what is outside. Actors sit outside; use cases sit inside.
- «include» — a mandatory sub-flow that is always triggered by the base use case. The base use case is incomplete without the included one.
- «extend» — an optional extension that adds behaviour to the base use case only under a specified condition. The base use case is complete without it.
- Generalisation — an actor or use case that inherits the behaviour of a more general one. A Consultant may generalise Clinician.
Use case diagrams show what users want to do. Activity and sequence diagrams show how — the internal flow of behaviour and the interactions between components.
Activity diagrams model processes and workflows — the sequence of actions, decisions, and parallel flows involved in achieving a goal. Key elements:
- Action node — a single step in the workflow
- Decision node (diamond) — a branching point; exactly one outgoing path is taken based on a guard condition
- Fork / Join (thick bars) — fork splits one flow into multiple parallel branches; join waits for all branches to complete
- Swimlanes — partition the diagram to show which actor or system component is responsible for each action
Sequence diagrams model interactions between specific named objects over time, showing the messages they exchange. Key elements:
- Lifeline — a vertical dashed line representing an object's existence during the interaction
- Activation bar — a narrow rectangle on a lifeline showing the period of active processing
- Synchronous message — filled arrowhead; sender waits for the receiver to respond
- Return message — dashed arrow; the response from a synchronous call
- Combined fragments — rectangular frames labelled with operators:
alt(alternatives),opt(optional),loop(repeated)
Behavioural models serve as the bridge between requirements and design. The translation from stakeholder need to technical specification requires discipline at each step:
- From requirements to use cases — each functional requirement should correspond to one or more use cases. An FR that has no corresponding use case has no defined user context; a use case with no corresponding requirement may represent gold-plating.
- From use cases to activity diagrams — each complex use case is elaborated into an activity diagram that details the workflow steps, decision points, and exception flows.
- From activity diagrams to sequence diagrams — each workflow step maps to messages exchanged between system components, making component boundaries and responsibilities explicit.
A common failure is to model only the happy path — the workflow as it should proceed when everything goes right. A professional model must also address alternative and exception flows: what happens when the patient has no available slots? When the payment fails? When the session times out? These are the scenarios that most commonly expose design weaknesses.
Key Concepts: Use Case Modelling
Work through each item. Use case diagrams are deceptively simple — the precision is in the details.
A complete actor set covers all entities that interact with the system — not only the primary human user. Common categories to check:
- Primary actors — users who directly initiate use cases to achieve their goals (patient, GP, consultant)
- Supporting actors — external systems or services that the system interacts with to fulfil use cases (email service, payment gateway, NHS Spine)
- Administrative actors — users with system management responsibilities (system administrator, data protection officer)
- Regulatory actors — external bodies whose access or audit requirements must be modelled (Care Quality Commission, NHS Digital)
A use case diagram that only shows primary human actors is typically incomplete. Missing actors mean missing use cases — and missing requirements.
This is one of the most frequently confused distinctions in use case modelling:
«include» models a mandatory sub-flow. Every time the base use case executes, the included use case executes as part of it. The base use case is not complete without it. Arrow direction: from base to included.
Example: Book Appointment always includes Authenticate User. You cannot book without being authenticated. The base use case (Book Appointment) depends on the included use case.
«extend» models optional behaviour that may occur under a specific condition. The base use case is complete without the extension. Arrow direction: from extending to base.
Example: Book Appointment may be extended by Add Interpreter Request, but only if the patient has flagged a language need. The base use case is fully valid without this extension.
A use case diagram shows structure but not detail. Each significant use case should have a textual description with the following components:
- Use Case ID and Name
- Primary Actor — who initiates this use case
- Preconditions — what must be true for this use case to begin
- Main Success Scenario — the step-by-step happy path
- Alternative Flows — what happens when conditions vary from the expected
- Exception Flows — what happens when errors occur
- Postconditions — what is true when the use case successfully completes
A use case description without alternative and exception flows is describing a system that only works when nothing goes wrong. That is not a system — it is a prototype.
Key Concepts: Activity and Sequence Diagrams
These two diagram types complement use cases — one models workflow, the other models interaction.
The key distinction is what you are trying to communicate:
Use an activity diagram when you want to model a process or workflow — the flow of steps, decisions, and parallel paths that constitute an activity. Activity diagrams do not require named participants; they show what happens. They are particularly effective for business process modelling and for showing complex decision logic or parallel execution.
Use a sequence diagram when you want to model the interactions between specific named objects — the messages they exchange, and in what order. Sequence diagrams make component boundaries explicit and show which objects are responsible for which processing steps. They are most effective when the system architecture is beginning to take shape.
In practice, both are often used for the same use case: an activity diagram models the overall workflow; sequence diagrams elaborate specific interactions within it.
Exception flows reveal design weaknesses that the happy path conceals. Consider a sequence diagram for Book Appointment that only models success. It says nothing about what the system does when:
- The patient's session expires mid-booking
- The selected appointment slot is taken by another user simultaneously
- The email confirmation service is unavailable
- The patient's account has been suspended for data protection reasons
Each of these scenarios requires a specific system response. If the model does not include them, they have not been specified — and they will not be designed for, tested for, or handled correctly in production.
A sequence diagram's alt combined fragment is the mechanism for modelling
these alternative outcomes. A diagram with no alt fragments is modelling only
the happy path and should be treated as incomplete.
Behavioural models are powerful but have significant limitations:
- Combinatorial explosion — a system with many use cases and exception paths cannot be fully modelled without producing an unmanageable number of diagrams. Modelling requires selection: which use cases and workflows are complex enough to justify detailed modelling?
- Static snapshots — diagrams represent the system at one point in requirements understanding. As requirements evolve, diagrams become stale unless actively maintained.
- Communication limits — use case diagrams are readable by non-technical stakeholders; sequence diagrams typically are not. Different audiences need different levels of detail.
- No performance or security insight — behavioural models show what the system does but not how fast or how securely. NFRs require separate analytical treatment.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
In a use case diagram, the «extend» relationship is drawn as a dashed arrow from:
A sequence diagram showing only the successful booking of an appointment, with no combined fragments, is best described as:
AI tools can generate use case descriptions, draft activity flow steps, and even produce rough sequence diagram representations from natural language descriptions of a system.
- Assist: Given a requirements description, AI can generate candidate use cases, suggest actors that may have been missed, and draft step-by-step use case descriptions — providing a useful starting point for analysis.
- Risk: AI-generated behavioural models typically model only the happy path. They reflect patterns from training data — systems that work as intended. They rarely model failure modes, race conditions, or the informal workarounds that observation-based elicitation would reveal. An AI-generated use case description without exception flows is a model of how the system should behave, not how it will behave.
- Principle: The value of modelling is in the thinking it forces. Using AI to generate a diagram without interrogating it — asking "what happens when this fails?", "who else needs to be in this interaction?" — produces the appearance of analysis without the substance. Always treat AI-generated models as first drafts requiring critical extension.
Activities
Individual task
Using the requirements baseline from Unit 3, create a use case diagram for the hospital appointment booking system covering at least three use cases. Your diagram must include:
- All relevant actors (primary, supporting, and administrative)
- The system boundary with a clear label
- At least one «include» and one «extend» relationship (correctly directed)
- A brief written justification for each «include» and «extend» relationship explaining why you chose that relationship type
Pair task
Review your partner's use case diagram critically:
- Are all actors present? Check for missing supporting systems and administrative roles.
- Are «include» and «extend» relationships correctly directed and appropriately used?
- Does any use case span too broad a goal? (A use case called "Manage System" is likely too broad.)
- Are any use cases missing that correspond to requirements in the Unit 3 baseline?
Identify one strength and one specific improvement, each with a justification.
Group task — activity diagram for a complex workflow
As a group, select the most complex use case in your system (e.g. Book Appointment or Process GP Referral) and produce a full activity diagram. Your diagram must include:
- At least one decision node with guard conditions on each outgoing branch
- At least one exception flow (e.g. slot unavailable, session timeout, system error)
- Swimlanes showing which actor or component is responsible for each action
- A join or fork if there are any parallel actions in the workflow
After completing the diagram, update your RTM from Unit 3 to link the use cases and activity diagram steps to the relevant requirement IDs.
Review
- «include» — mandatory; the base use case always triggers the included use case. Arrow from base to included. The base is incomplete without it.
- «extend» — optional; the extending use case adds behaviour only under a specified condition. Arrow from extending to base. The base is complete without it.
A model that only shows the happy path describes a system that only works when nothing goes wrong. In a real system, exceptions are not edge cases — they are regular occurrences. Booking conflicts, session timeouts, and service failures must be specified, designed for, and tested. A model that omits them has not been fully analysed — and the system built from it will handle failures unpredictably.
Proceed to Unit 5: Architecture & Design when ready.