2IRR00 · Topic 03
Modelling with UML
Use-case, activity, and class diagrams
Use cases & use-case diagrams
A use case describes how a system shall be used / should behave; a use-case diagram shows actors, use cases (ellipses), the system boundary, and their relationships.
A use case has one main scenario plus alternative and exception scenarios, and makes functional requirements concrete.
Actors (stick figures or «actor» rectangles) are associated to use cases via solid lines.
«include»: shared behaviour fully included in another use case (the arrow points to the included use case). «extend»: optional/alternative behaviour under a condition (arrow points to the base use case, with an extension point).
Use-case template sections: Identifier/Name, Priority, Summary, Actors, Trigger, Pre-conditions, Post-conditions, Result, Main/Alternative/Exception scenarios, Requirements.
Invalid learning block
media.gallery · use-cases-slides
Common mistakes
- Modelling a PROCESS / chain of events in a use-case diagram (use an activity diagram instead).
- Modelling functional decomposition (belongs in a class diagram).
- Getting include/extend arrow direction wrong; mixing abstraction levels/granularities; missing actor associations.
- Intermixing alternative scenarios (correct, event-triggered) with exception scenarios (errors).
Exam tips
- include = always needed shared step; extend = conditional/optional add-on. Know which arrow points where.
- Typical task: complete a partial use-case diagram from a use-case description — identify actors, then use cases, then include/extend.
Use cases & use-case diagrams practice
1 questions
Class diagrams (the exam favourite)
A class diagram shows classes with attributes/methods and the static relationships between them: association, generalisation (inheritance), aggregation, and composition, annotated with multiplicities and visibility.
Abstract classes are written in italics or marked {abstract} and CANNOT be instantiated directly — only a concrete subclass can be instantiated.
Visibility (Java semantics): public (everyone), protected (subclasses + package), package/default (same package), private (only within the class). A subclass does NOT 'see' a private field of its parent, but it DOES inherit/have it.
Generalisation: 'Car is a Vehicle' (inheritance, hollow triangle).
Aggregation (hollow diamond): parts can exist WITHOUT the whole; a part may be shared by / contained in different wholes and is NOT deleted with the whole.
Composition (filled diamond): the part exists in only ONE whole at a time and IS deleted when its whole is deleted.
Multiplicities: 0..1, 1, n, 1..*, * specify how many instances participate.
{abstract} A has public a, private b
↑ (B,C inherit from A; D associates A; E,F inherit from B)
An instance of A: ✘ cannot be instantiated as A itself (abstract)
An instance of F: has variable b (inherited), can see a (public),
does NOT have d, cannot see e (private elsewhere)
Aggregation (A in D, hollow diamond):
• A may be contained in different instances of D
• A is NOT deleted when its D is deleted
Composition would instead mean: exactly one whole + deleted with it.Invalid learning block
media.gallery · class-diagrams-slides
Common mistakes
- Confusing 'has a variable' (inherited, exists in the object) with 'can see a variable' (visibility allows access).
- Swapping aggregation vs composition deletion/sharing semantics.
- Trying to instantiate an abstract class directly.
Exam tips
- Composition = filled diamond = lifetime-bound + single owner + deleted together. Aggregation = hollow diamond = independent lifetime + shareable.
- private = not visible even to subclasses; protected = visible to subclasses; but inheritance still gives the subclass the field.
- MCQ with negative marking: read each option as a precise Java statement.
Class diagrams (the exam favourite) practice
1 questions
Activity diagrams
An activity diagram models the control/object flow of a use case: actions, an initial node, an activity-final node, decision/merge nodes, and fork/synchronization (parallel) nodes.
Decision node (diamond) splits into guarded alternative flows; a matching MERGE node rejoins them. Each decision should have a merge.
Fork node splits into parallel flows; a matching synchronization (join) node rejoins them. Each fork should have a sync.
Decision/merge (alternatives) and fork/sync (parallel) are DIFFERENT and must not be intermixed.
Object nodes represent objects relevant to the flow (only if actually used).
Invalid learning block
media.gallery · activity-diagrams-slides
Common mistakes
- Not merging after a decision (a merge should not flow straight into an action; each action has one in/one out).
- Not synchronizing parallel flows, or running dependent actions in parallel.
- Mixing decision/merge with fork/sync nodes; vague guards; modelling implementation instead of the use case.
Exam tips
- Rule of thumb: every decision needs a merge, every fork needs a synchronization.
- Activity diagrams detail use cases conceptually (who acts, what, in what order) — not code execution (that's a state chart).
Activity diagrams practice
1 questions