Unit 8: Integrating UML
Learning Objectives
- Explain what traceability means and why it matters in software design
- Identify the most common types of contradiction across UML diagrams
- Produce a consistent, integrated set of diagrams for the group's shared system
Core Input
Read through each tab before working through the key concepts.
Traceability is the ability to follow a requirement from its origin through every design artefact that implements it.
In a UML model, the chain runs:
- Requirement — a statement of what the system must do
- Use case — the requirement expressed as a user goal
- Class diagram — the structural elements that support the use case
- Sequence or activity diagram — the behaviour that implements the use case
A traceability matrix is a table that maps each requirement to its use case, its supporting classes, and its behavioural model. It makes gaps visible at a glance: a row with an empty cell means something is missing.
Contradictions between UML diagrams are almost inevitable in early design. Common types:
- Missing class — a class appears in a sequence diagram but is not defined in the class diagram. The structural model is incomplete.
- Missing behavioural model — a use case has no corresponding sequence or activity diagram. How the use case is implemented is unspecified.
- Multiplicity conflict — the class diagram specifies a 1..* relationship, but the sequence diagram sends a message to a single object with no loop. These are inconsistent assumptions.
- Missing operation — a sequence diagram calls an operation on a class that does not appear in the operations compartment of the class diagram.
- Orphaned class — a class in the class diagram is never referenced by any use case, sequence diagram, or activity diagram. It may be unnecessary.
Use this checklist to verify a set of integrated UML diagrams:
- Every requirement maps to at least one use case.
- Every use case has at least one sequence or activity diagram modelling its implementation.
- Every class name in a sequence diagram exists in the class diagram.
- Every operation called in a sequence diagram appears in the class diagram's operations compartment.
- Multiplicities in the class diagram are consistent with the message flows in sequence diagrams.
- Every class in the class diagram is referenced by at least one behavioural diagram or use case.
- Activity diagrams for business processes are consistent with the sequence diagrams for the same use case.
Key Concepts: Traceability
Work through each item carefully — traceability is abstract but has very practical consequences.
Traceability means that every design element can be linked back to a requirement that justifies its existence — and every requirement can be followed forward to the design elements that implement it.
Traceability matters for three reasons:
- Completeness checking — if a requirement has no corresponding design element, it will not be implemented. Traceability makes this visible before it becomes a problem.
- Impact analysis — when a requirement changes, traceability tells you exactly which diagrams need to be updated. Without it, changes are made blindly and inconsistency spreads.
- Justification — every class and operation should exist because a requirement demands it. A class with no traceable requirement may be scope creep or dead code.
A traceability matrix is typically a table with requirements as rows and design artefacts as columns (use cases, classes, diagrams). A cell is marked when the artefact implements or relates to the requirement.
Simple example:
| Requirement | Use Case | Classes | Sequence Diagram |
|---|---|---|---|
| FR01: User can log in | Login | User, Session, AuthService | Login Sequence |
| FR02: User can reset password | Reset Password | User, EmailService | — |
The empty cell for FR02 immediately flags a gap: the Reset Password use case has no sequence diagram. That needs to be produced.
A complete UML model for a use case traces through four levels:
- Requirements document — the written specification: "The system shall allow registered users to log in with an email address and password."
- Use case diagram — the Login use case, associated with the Registered User actor.
- Class diagram — the User, AuthService, and Session classes with their attributes and operations.
- Sequence diagram — the messages between the actor, LoginController, AuthService, UserDatabase, and Session during a login interaction.
Each level adds detail. None is optional in a complete design — each answers a different question that developers, testers, and stakeholders need answered.
Most software spends far more time being maintained than being initially built. When a system is maintained, the original development team may have moved on. New developers must understand what was built and why.
Without traceability:
- A developer modifies a class without realising it is the only implementation of a critical requirement
- A requirement is changed but only some diagrams are updated — the rest become stale
- Features are added that duplicate existing functionality, because no one can trace what already exists
Traceability is the map that keeps a system navigable as it evolves.
Key Concepts: Finding and Resolving Contradictions
Contradictions in a model are not failures — they are discoveries. The goal is to find and resolve them before development begins.
A contradiction exists when two or more diagrams make incompatible assumptions about the same system. Common examples:
-
A sequence diagram calls
User.getAccount(), but the class diagram does not listgetAccount()as an operation of User. -
The class diagram shows a
1..*relationship (one or more) between Course and Student, but a sequence diagram processes a fixed single student with no loop. - A use case named "Send Invoice" has no sequence or activity diagram showing how it is implemented — it is specified in requirements but not designed.
- An activity diagram shows "Check Inventory" as a step, but there is no Inventory class in the class diagram.
When a class appears in a sequence diagram but not in the class diagram, there are two possible resolutions:
- The class is genuinely needed: Add it to the class diagram with appropriate attributes and operations. Update the traceability matrix. Check if it affects any multiplicity constraints.
- The class was modelled in error: It may be a renamed version of an existing class, or a responsibility that should be part of another class. Correct the sequence diagram.
In practice: ask "should this class exist?" before adding it. Every class in the model should trace back to a requirement.
A multiplicity conflict occurs when the structural model and a behavioural model make incompatible assumptions about how many objects are involved.
To resolve it, ask: what does the business rule actually say?
- If the class diagram is correct (e.g. a course really does have many students), update the sequence diagram to use a loop fragment or show the pattern for a single student with a note that it loops.
- If the sequence diagram reflects actual behaviour (e.g. in practice only one student is processed at a time), update the class diagram multiplicity to match.
The resolution should match the business rule — not whichever diagram is easier to change.
An orphaned class is one that appears in the class diagram but is never referenced in any use case, sequence diagram, or activity diagram.
Before deleting it, investigate:
- Was it added for a requirement that was later removed? Remove the class.
- Is it needed for a use case that has not yet been modelled? Add the missing behavioural diagram.
- Is it a utility or infrastructure class (e.g. Logger, Configuration) with no direct use case? Document why it exists — it is not traced to a functional requirement but may be justified by a non-functional one.
Orphaned classes are not always wrong, but they always deserve scrutiny.
Watch
Video coming soon
Check Your Understanding
Select the best answer for each question.
A sequence diagram shows a 'PaymentProcessor' class, but this class does not appear in the class diagram. What does this indicate?
What is the primary purpose of a traceability matrix?
Activities
Individual task
Using your diagrams from Units 3–7, create a traceability table for your group's system.
Structure the table with these columns:
- Requirement (from Unit 2)
- Use case (from Unit 3)
- Supporting classes (from Units 4–5)
- Sequence or activity diagram (from Units 6–7)
Mark any cells where you have no artefact — these are your gaps. Note them for the pair task.
Pair task
Compare traceability tables with a partner and identify:
- Use cases with no behavioural model — a sequence or activity diagram should exist for every use case. Which are missing?
- Classes not referenced by any use case or behavioural diagram — these are orphaned classes. Are they justified or should they be removed?
- Sequence diagram operations not in the class diagram — list any and decide whether to add them to the class diagram or correct the sequence diagram.
Group task
Using the gaps and contradictions identified by the pair task, produce an updated, integrated set of diagrams for your system:
- Every use case has at least one behavioural model
- Every class in a sequence diagram exists in the class diagram
- Every operation called in a sequence diagram is listed in the class diagram
- The traceability matrix has no empty cells
This integrated model is the input for Unit 9, where you will document and present it.
Review
- A requirements list (from Unit 2)
- A use case diagram with all actors and use cases (Unit 3)
- A class diagram with attributes, operations, and relationships (Units 4–5)
- A sequence diagram for each major use case (Unit 6)
- An activity diagram for each major workflow (Unit 7)
- A traceability matrix linking all four levels (Unit 8)
A set of consistent, traced diagrams is the raw material for documentation. In Unit 9, you will learn to present this material clearly to different audiences — not just producing correct diagrams, but communicating what they mean and why the key decisions were made.
Proceed to Unit 9: Design & Documentation when ready.