- ✓UML, the Unified Modelling Language, provides a standardised set of diagram types for documenting software systems.
- ✓Use case diagrams describe the interactions between users (actors) and the system, capturing what the system must do from the user's perspective.
- ✓Sequence diagrams show the order in which objects interact during a specific scenario, making complex behaviour easier to understand and communicate.
- ✓State machine diagrams model how an object changes state in response to events, which is particularly useful for embedded systems and protocols.
- ✓Behavioural modelling is valuable throughout development, not just at the design stage; diagrams can be updated as understanding of the system evolves.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Today we're covering software behavioural design, which is about modelling how software will behave before you build it. Sam, why is this important?
Sam: Because software behaviour can be very complex, and trying to reason about that complexity purely in your head, without visual models, is a recipe for misunderstandings and defects. Behavioural modelling gives developers and stakeholders a shared way to visualise and communicate how the system should respond to inputs and events, before a single line of code is written.
Alex: UML is the standard language for this, right?
Sam: Yes. UML, the Unified Modelling Language, was developed in the 1990s to standardise the visual notation used in software design. It includes both structural diagrams that model what a system is made of, and behavioural diagrams that model how it works. For our purposes in this lesson, we're focusing on the behavioural ones.
Alex: Let's start with use case diagrams.
Sam: Use case diagrams are often the first behavioural diagram you create for a new system. They model the system from the outside, showing the different types of users, called actors, and the things they can do with the system, called use cases. An actor might be a Customer, a Manager, or an Administrator. A use case might be 'Place Order', 'View Report', or 'Manage User Accounts'. The diagram shows which actors can participate in which use cases, giving a high-level view of the system's functionality from the user's perspective.
Alex: And sequence diagrams?
Sam: Sequence diagrams model how objects interact during a specific scenario, showing the order of messages exchanged between them over time. The vertical axis represents time flowing downward, and each object or system component is shown as a vertical lifeline. Messages between components are shown as horizontal arrows. A sequence diagram for the 'Place Order' use case might show the sequence of interactions between the user, the web application, the order processing service, the inventory system, and the payment gateway.
Alex: What about state machine diagrams?
Sam: State machine diagrams model how an individual object changes state in response to events. They're particularly useful for objects that have a defined lifecycle with distinct states and clear transitions between them. An order, for example, might have states: Pending, Confirmed, Dispatched, Delivered, and Cancelled. The diagram shows which events trigger transitions between these states, and what actions occur during transitions. These are very common in embedded systems, protocols, and anywhere that sequential state management is important.
Alex: Are these diagrams used throughout development or just at the design stage?
Sam: They're most intensively created during design, but they remain useful throughout development. When a defect is found, updating a sequence diagram to reflect the correct intended behaviour can help identify where the code diverges from the design. When adding a new feature, a use case diagram helps ensure the new functionality is consistent with the overall system model. And they're invaluable documentation for maintenance teams.
Alex: Great. So behavioural modelling is a professional discipline that elevates the quality of software design.
Sam: Absolutely. The teams that invest in design artefacts like these build better systems with fewer surprises during implementation.
Alex: Thanks Sam. We move into Unit 8 next time.