UML and system modelling: seven views of one system.

Why we model: selective abstraction as engineering tool.

Software engineering is the discipline that builds large, useful programs without their complexity becoming the dominant cost. Modelling is one of the levers that keeps complexity under control: a model shows part of the system clearly precisely because it hides everything else. Different stakeholders need to see different parts, which is why there is no single diagram type that captures a system, and why this companion treats seven of them.

The idea of a "model" in engineering predates software. In mechanical, civil, and electrical engineering, drawings replace prose because they are denser, more checkable, and (when standardised) less ambiguous. The same case applies to software, with one extra wrinkle: the artefact we are modelling does not yet exist, so the model has to do double duty as both description (of what we intend to build) and specification (of what counts as having built it correctly). Sommerville (Software Engineering, 10th ed., 2015, ch.5) captures this in a one-sentence definition that is worth taking apart:

Two words in that sentence carry the weight: ignores and complementary. A model ignores by design; if it captured every detail, it would be the system itself, and would offer no leverage. And no single model is enough: a use case diagram says nothing about how data is structured, a class diagram says nothing about how messages flow over time, a sequence diagram says nothing about how the system is deployed across machines. Complementary models compose into a full picture because each ignores something different, and the engineer's job is to know which complement to add next.

The shorter, practitioner-facing summary is: a model is the language of the designer; a description of the system-to-be-built (or as-built) from a particular perspective; a tool for communicating with stakeholders; and a means of reasoning about some characteristic of the system without holding the whole of it in your head. UML, the Unified Modelling Language, is the standardised vocabulary in which those models are now drawn. The rest of this chapter develops where UML came from, where it is used in practice, and how to choose which model to draw, before turning to how to draw each of the seven course diagrams correctly. A worked example near the end ties them together from elicitation to first-cut design, and a closing section lists the marking pitfalls.

Two questions a model must answer

Before you draw a model, you should know which two questions it answers, because if it answers neither, it is not earning its place on the page:

• Who is the reader? A developer? An auditor? A clinical specialist? The customer's contracting officer? A model is a piece of communication; it has to be addressed to someone.
• What decision does it support? Scope confirmation? An algorithm choice? A staffing estimate? A deployment topology? A model that does not help anyone decide anything is decoration.

Every diagram in this companion is paired with a short "where it earns its place" panel that names the reader and the decision. Keep those two anchors in mind as you read; they are what separates a useful diagram from a textbook one.

Three modelling moves

Underneath the fourteen UML diagram types are just three modelling moves you make again and again. Recognising which move you are making is the easiest way to pick the right diagram:

• Abstraction. Strip out detail to expose structure. The class diagram does this for code; the use case diagram does it for usage; the deployment diagram does it for infrastructure.
• Decomposition. Split one thing into parts that can be reasoned about separately. Composite use cases decompose system functionality; activity diagrams decompose a use case into ordered steps; component diagrams decompose the system into modules.
• Refinement. Take a sketched-in object and add detail. A use case sketch refines into an activity diagram; a class diagram refines into a sequence diagram; a state name refines into a sub-state machine.

If you find yourself drawing a diagram without doing one of these three moves, the diagram is probably not adding value; you are decorating.

A model earns its place by what it makes discussable. A use case diagram makes the system's interactions with its users discussable in a single page; a class diagram makes its static structure discussable; a sequence diagram makes one specific interaction discussable. None of them captures the system, and that is exactly the point.

The Three Amigos and the method wars.

UML did not arrive whole. It was the result of a deliberate, three-year unification at Rational Software (1994 to 1997) of three competing object-oriented modelling notations, led by the engineers who had created them. Understanding that backstory matters, because every UML diagram type still bears the fingerprint of which of the three contributed it.

Before UML: the method wars

The 1980s and early 1990s were the boom years of object-oriented analysis and design. Smalltalk had been released in 1980; C++ in 1985; Java arrived in 1995. As industry adopted these languages, the demand for diagrammatic notations to plan large object-oriented systems exploded. By the early 1990s the field had no fewer than fifty published methods, each with its own conventions for classes, associations, inheritance, and behaviour. Fowler later called the period the "method wars" (UML Distilled, 2003, ch.1): teams that adopted one method could not exchange diagrams with teams that adopted another, and reading the OO literature meant learning a different graphical vocabulary every few months.

Three of the methods dominated by 1994. Each was associated with one prominent author, each came out of a different industrial setting, and each was strongest in a different part of the lifecycle:

The three were complementary in scope (analysis, design, requirements) and convergent in spirit (all object-oriented, all diagrammatic), but stubbornly incompatible in notation. A class drawn in OMT looked nothing like a class drawn in Booch, and Jacobson's use case bubbles had no equivalent in either. Teams that mixed methods spent disproportionate effort translating between them.

The unification: 1994 to 1997

The first move came in October 1994: Rumbaugh left General Electric to join Booch at Rational Software, with the explicit goal of merging OMT and the Booch method. They circulated a draft "Unified Method" version 0.8 in October 1995. Jacobson sold Objectory to Rational the same month and joined the team; from that point the three were collaborating in one company, on one notation. Industry shorthand quickly named them the Three Amigos, after the 1986 film.

The unification was not a vote between three favourites; it was a re-engineering of the combined notation around what each method did best. Rumbaugh's class-and-association notation became UML's structural backbone; Jacobson's use cases were lifted in essentially unchanged; Booch's emphasis on design-level diagrams supplied component and deployment views. The result was published as UML 0.9 in June 1996, renamed Unified Modelling Language rather than Unified Method (a deliberate distinction: a language is a notation only, not a prescribed process).

In November 1997, the Object Management Group (OMG) adopted UML 1.1 as a standard. The OMG is an industry consortium founded in 1989 to standardise object-oriented and distributed-system technologies (it also maintains CORBA and SysML). UML's transfer to OMG was the moment it stopped being a Rational product and became a public standard. The notation was frozen at UML 1.1, substantially revised at UML 2.0 (2005, which added the sequence-diagram interaction fragments and refined activity diagrams along business-process lines), and has been stable since UML 2.5.1 (2017), the version this course follows. The point of standardising was readability: after UML, a diagram drawn in one company is readable in another, in a research lab, and in a textbook.

UML is a language, not a method

A common confusion is to expect UML to tell you when to draw each diagram. It does not. UML is a notation only: it standardises the shape of an ellipse for a use case, the rules for an include arrow, the compartments of a class box. The decisions about which diagrams to draw, in what order, and how much detail to put on them belong to the process, which is a separate concern. The most-cited process built around UML is the Rational Unified Process (RUP, Kruchten, 2003), but agile teams routinely use a small subset of UML inside Scrum or XP without adopting RUP at all. The course's structure follows this separation: chapter 3 covers the process by which requirements are produced; this chapter covers the language in which the resulting models are drawn.

Where UML lives now.

UML's status today is uneven across the industry. Knowing where it is heavily used and where it is light-touch is part of using it correctly.

Heavily used. Regulated domains (medical devices, automotive safety, avionics, rail), where traceability from requirements to design is a certification requirement; Model-Based Systems Engineering (MBSE), where SysML (a UML profile) is the primary modelling notation; teaching, where UML's diagrammatic vocabulary is still the standard way to introduce object-oriented design; and large enterprise architecture work, where component and deployment diagrams remain the standard medium for documenting system structure.

Lighter use. Agile teams often use only a subset (use cases or activity diagrams for requirements; class diagrams sketched on whiteboards) and rarely produce the full UML model that the textbook describes. The reasons are pragmatic, not ideological: keeping a heavyweight model in sync with rapidly changing code is expensive, and teams have learned to invest in the diagrams that pay back in conversation rather than those that pay back in documentation.

Areas of growth. The rise of safety- and security-critical AI systems has brought renewed interest in MBSE and formal modelling, including UML-derived notations. The diagrammatic vocabulary has also re-emerged in domain-specific contexts (database modelling tools, infrastructure-as-code visualisers, sequence diagrams generated automatically from distributed traces).

For the COMP433 student, the practical takeaway is that the seven diagrams treated in depth here are all in current use somewhere, and being fluent in them is genuinely portable knowledge. The diagrams treated more briefly (object, communication, timing, interaction overview) are still in the standard but are encountered much less often in industry.

The four families of models.

Sommerville (2015, ch.5) groups system models into four families by what they make discussable. The families are not mutually exclusive (one diagram can belong to two), but knowing the family helps decide what kind of question the diagram is being drawn to answer, and which UML diagram types are the natural fit. Hover any card below for a worked example and a sharper definition.

The families are not partitions. A use case diagram is partly context and partly interaction; an activity diagram can be either interaction or behavioural depending on the level it is drawn at; a component diagram is structural but its interface contracts already imply interaction. The classification is a thinking aid, not a rigid taxonomy: when a team realises it has drawn three interaction diagrams and no structural one, it has a signal that an important class diagram is still missing.

From elicitation to deployment: where each model fits.

The diagrams in this chapter do not exist in isolation. Each one sits at a particular point in the software lifecycle, takes its input from the artefact that precedes it, and produces an output that the next artefact builds on. This section is the map that the rest of the companion fills in.

A common misconception is that UML diagrams are alternatives ("should I draw a use case or a class diagram?"). The right framing is sequential: each diagram answers a question the previous one raised, at the right level of abstraction for the stage you are in. Knowing which question is on the table is what tells you which diagram to draw next.

Reading the pipeline

Three observations worth pausing on:

1. Cost estimation is a decision gate, not a deliverable. Steps 1 and 2 produce the requirements; step 3 prices them. The estimate is what the customer needs to authorise the design work (steps 4–10). Doing the estimate too early, before requirements are stable, produces a number nobody can defend. Doing it too late, after design has started, means the team is committed to a price that may not match the work.
2. The arrows go forward but the work goes back and forward. A class diagram drawn at step 6 usually exposes a missing requirement at step 2, which is added and propagates back through the use cases (step 4). The pipeline is a thinking aid, not a waterfall.
3. Not every step is mandatory. A small project may skip the activity diagram entirely; a project with no domain objects with lifecycles may skip the state machine. The skip rule is the same as the model rule: if it does not change anyone's decision, do not draw it.

Cost estimation in context

Cost estimation is treated in depth in the Ch.3 companion, which includes an interactive calculator. The view from this chapter is about when and why, not how. The key implications:

• What you estimate. The unit of estimation is the User Requirement, not the use case. A single user requirement may map to several use cases (or none); the estimate has to attach to the requirement so it survives the design pass.
• What the estimate produces. Total effort (in person-weeks), schedule (effort × 1.30 buffer), cost (schedule × weekly salary), and a quoted price range (cost × 1.10 to 1.30). That price range is the artefact that goes back to the customer for sign-off.
• What changes the estimate. Anything that changes the requirements. A new UR added during use case modelling does not enter the pipeline silently; it goes back to step 3 and the estimate is revised. This is why the iteration loop in the figure points back to step 1 and not to step 2 or 3 alone.
• What the estimate does not do. It does not constrain how the team builds the system, which design patterns it uses, or which architectural style fits. Those are downstream choices that the estimate's coarseness has to absorb.

A worked thread through the journey

To make the pipeline concrete, follow one user requirement through it. The example is the Library System used as the running example in the rest of this companion:

One user requirement, and already five linked analysis artefacts. Most of the value is not in any single one; it is in the traceability from UR3 onward, which lets the team change the design and know which other artefacts to update. These five are the analysis views this chapter teaches first; section 14 carries the same thread on into the design diagrams (class, sequence, state, component, deployment).

UML 2.5: fourteen diagram types.

The UML 2.5 specification defines fourteen diagram types, split into structural (seven) and behavioural (seven). Nine of these are conventionally treated as the "standard" set you will encounter on real projects, and seven are covered in depth in this companion (and used in the COMP433 project). The map below lists all fourteen for completeness; the italicised types are part of the standard but encountered less often in practice.

The seven types covered in depth below are: use case, activity, class, sequence, state machine, component, and deployment. Together they cover the full life cycle of a typical project: requirements (use case, activity), analysis and design (class, sequence, state machine), and architecture (component, deployment).

Use case diagrams: actors, tasks, system boundary.

A use case diagram is a one-page picture of who interacts with the system and the named tasks they perform. It is the first UML diagram drawn on most projects: it converts the list of User Requirements into something that fits on one A4 page, makes scope confirmable with the customer, and produces the index of tasks that downstream diagrams (activity, sequence, class) refine.

What a use case diagram is for, precisely

The diagram serves three decisions, and only three:

• Scope confirmation. The customer signs off (or contests) that the listed use cases are the right set and that no major task is missing. The diagram is read from the actor side: "as a BookBorrower, the system lets me Borrow, Return, Renew, and Browse; is that all I need it to do?".
• Actor inventory. Names the primary and secondary actors that interact with the system. This list flows directly into requirements (each actor needs its sentence-long description) and into design (each actor becomes a class or external system in the class diagram).
• Task index. Names the tasks (use cases). Each use case will get its own textual description (section 8), at least one activity diagram if the workflow is non-trivial (section 9), and at least one sequence diagram for its key scenario (section 11). The diagram is the table of contents for those downstream artefacts.

Beyond those three decisions, the use case model earns its keep across the whole project. The course notes list five further things a good use case set does: it specifies the context of the system (its boundary and the actors around it); it lets the team plan iterations of development (each use case is a unit of work to schedule); it validates the architecture (every architecturally significant use case must be realisable on the proposed design); it drives implementation (each use case becomes a thread of construction); and it generates test cases (each scenario through a use case is a system-test script). Use cases are built early in development, by analysts and domain experts during requirements analysis, and stay useful long after.

It does not show: the order of work inside a use case (use an activity diagram), the messages between objects realising a use case (use a sequence diagram), what data the system holds (use a class diagram), or where the system runs (use a deployment diagram). A use case ellipse is, deliberately, an opaque label; the substance lives in the textual description.

When the diagram is drawn

In the project pipeline (section 5, figure 1), the use case diagram is the bridge between requirements and design. It is drawn for the Phase 2 deliverable: each User Requirement that names a clear actor and a clear goal becomes one use case, and the diagram makes the relationships between them (sub-tasks, conditional alternatives) visible alongside the textual UR / SR list. It is then revised at the start of Phase 3 as design begins, because the design pass surfaces additional sub-tasks (which become <<include>> use cases) and alternative paths (which become <<extend>> use cases).

Building blocks

A use case diagram has three building blocks: actors, use cases, and the system boundary. Actors are drawn as stick figures (or sometimes labelled boxes for non-human actors) outside the boundary; use cases are ellipses with a verb-phrase label inside the boundary; the system boundary is a rectangle that contains the use cases and explicitly excludes the actors. Associations are simple solid lines between an actor and a use case they participate in (no arrow head, because participation is undirected). Refinement relationships between use cases are drawn as dashed arrows with one of three stereotypes: <<include>>, <<extend>>, or generalisation (inheritance).

Building blocks, drawn correctly

Actors: primary and secondary

An actor is a role someone or something plays when interacting with the system. Actors are not specific people; the same person can be two actors at different times. A doctor who also borrows books at the staff library is a Doctor in one system and a BookBorrower in the other. The course conventionally splits actors into two kinds:

• Primary actor. The user who initiates or benefits from a use case. Usually a human role (BookBorrower, Librarian, Doctor, Nurse).
• Secondary actor. An external system, hardware device, or system-triggered event that the system depends on or interacts with. Common examples: SystemTimer (for scheduled events), EmailSystem (an external service the system pushes to), BankSystem (an external payment service the system queries).

How to identify actors:

• What roles do the direct users of the system play?
• Who provides information to the system?
• Who receives information from the system?
• What external systems must the system communicate with?

Notation convention. Each actor's name is a noun (CamelCase, no spaces), and the actor is documented in one sentence covering its role and how it interacts with the system. For example: "BookBorrower: a member of the library who borrows physical copies of books (Primary)." The description belongs in the requirements document next to the diagram; the diagram itself only carries the name.

A worked actor list, and actor generalisation

Identifying actors is rarely a one-pass job: the first list is usually too coarse or too fine, then it is organised. Reading the Library requirements actor-first yields a fine-grained list of roles, several of which turn out to be the same person:

The last four are all the same human, the Librarian; listing them as separate fine-grained roles first and then grouping them is the normal route to a clean actor. Where one actor can do everything another can and more, the relationship is actor generalisation, drawn with the hollow-triangle inheritance arrow (as in a class diagram), pointing from the specialised actor to the general one. For the Library, the primary-actor hierarchy is:

• From most general to most specific: LibraryUser, then Browser, then BookBorrower, then JournalBorrower. Each inherits the use cases of the one before it and adds its own: a Browser can search, a BookBorrower is a Browser who can also borrow books, a JournalBorrower is a BookBorrower who can also borrow journals.
• Browser is also specialised by Librarian. The staff actor inherits the ability to browse and adds the management use cases (add, update, catalog, remove).

Generalisation keeps the diagram honest: rather than repeating every borrowing association on JournalBorrower, you draw it once on BookBorrower and let JournalBorrower inherit it. This is the actor-side counterpart of the use case generalisation covered below.

Use cases: things actors do with the system

A use case is a task an actor needs to perform with the help of the system. Two rules from the course notes:

• Always start a use case label with a verb. "Borrow copy of a book", not "Book borrowing". The verb is what tells you it is a use case rather than a class.
• Describe the use case's semantics in a sentence or two. The ellipse on the diagram is the entry point; the description in the requirements document is what the team builds against.

How to find use cases:

• Scenario-based analysis. Write the system's processes as scenarios; each interaction in a scenario is a candidate use case.
• Actor-based analysis. Start from the actor list; for each actor, ask what they need from the system, and what other interactions they take part in for someone else's benefit.

How do you know a candidate is genuinely a use case, and at the right granularity? The course's tests: estimate the frequency of use (something done once at setup may not warrant its own use case); examine the differences between candidate use cases (if two are nearly identical, they may be one use case with alternative scenarios); and distinguish the normal from the alternative course of events (an alternative path is usually a scenario of an existing use case, not a new use case). A use case should be a complete, valuable task from the actor's point of view, not a single click ("enter password") nor a whole subsystem ("manage everything").

Building the diagram from the requirements: noun-verb analysis

The course's standard technique for turning a written requirements document into a first-cut use case diagram is noun-verb analysis. Read the requirements text and mark it up in two colours:

• Nouns and noun phrases map to candidate actors (and, later, candidate classes and attributes). "library member", "member of staff", "member of the public" become BookBorrower, JournalBorrower, BookBrowser; "email" and "bank" surface secondary actors.
• Verbs and verb phrases map to candidate use cases. "borrow", "renew", "return", "browse / search", "pay a fine", "send", "manage / add / update / catalog / remove" each become a use case.
• Noun-verb interactions map to associations. "a member may borrow" is the association line between the BookBorrower actor and the Borrow use case.

Not every candidate survives. Discard: redundant or omnipotent nouns (a catch-all "system" that does everything), vague entities, meta-language (words about the document rather than the domain), entities outside the system scope, pure attributes, and constraints or events that are not tasks. What remains, read straight off the marked-up text, is the actor list down the side, the use case ellipses in the middle, and the association lines between them. The same noun-verb pass later seeds the class diagram, so it is worth doing carefully.

Step through (or play) the construction of a use case diagram from a short narrative and its user requirements, with each actor and use case traced back to the line it came from.

Relationships between use cases: include, extend, generalisation

Once you have more than a handful of use cases, you will start to see that some use cases share sub-tasks with each other, others fire only in exceptional circumstances, and others are variations on a common theme. UML 2.5 gives three stereotypes for these refinements. Each has a precise meaning and a precise arrow direction, and confusing them is the single most common notation error on this material.

Worked second example: online food ordering

The Library example shows the mechanics; an online food-ordering app shows the same stereotypes paying back in a different domain.

• Place order is the primary use case (initiated by the Customer).
• Calculate order total is <<include>>-d from Place order, and also from Modify order, because both always need the running total (items, delivery fee, tax). It is factored out so the pricing rules live in one place and both base use cases change together.
• Apply promo code is <<extend>>-ed from Place order, at an extension point "before payment", with guard [has promo]. Most orders carry no promo; the extension keeps the Place order description clean.
• Refuse order is <<extend>>-ed from Place order, at the extension point "after stock check", with guard [item unavailable]. This is structurally identical to the Library's Refuse loan, and shows the same conditional-alternative pattern recurring across very different domains.

The two stereotypes answer two different needs. <<include>> exists to avoid duplication when two or more base use cases share a sub-task (Calculate order total is shared by Place order and Modify order). <<extend>> exists to keep the base description clean when an optional or exceptional behaviour would otherwise crowd it (Apply promo code and Refuse order only run sometimes; each belongs on a separate ellipse, not as a footnote inside Place order).

Generalisation, and all three refinements together

The third refinement, generalisation (informally <<inherit>>), applies when one use case is a more specific version of another. A library borrower can Pay fine in two ways: Pay by cash and Pay by credit card each specialise Pay fine, inheriting its general workflow and adding their own steps. The notation is the class-diagram one: a solid line with a hollow triangle, pointing from the specialised case to the general Pay fine.

The three refinements compose, and a single realistic requirement usually needs all of them. Take the rule "for every successful credit-card payment, send an email confirmation; the bank must approve the payment and may refuse it":

• Pay by credit card <<inherit>> Pay fine: it is a kind of fine payment.
• Pay by credit card <<include>> Send payment confirmation: every successful card payment sends one, so it is unconditional, and the confirmation reaches the Email System (a secondary actor).
• Pay by credit card is <<extend>>-ed by Validate payment against the Bank System: the bank may refuse, so this is the conditional, sometimes-failing path.

Reuse cuts across this picture: Send message (by email) is factored out as an included sub-use-case shared by both "Send reminder to late loans" (triggered by the SystemTimer) and "Send payment confirmation". One ellipse, two base cases, one change-point. This single Pay-fine picture is the clearest demonstration that include, extend, and generalisation are not academic decorations: all three fall out of one ordinary business rule.

Extension points

A common question is "where in the base does the extension fire?" The answer is given by an extension point: a named position in the base's workflow, written in a compartment inside the base ellipse (or in the base's textual description). Borrow copy of a book declares two:

• maximum no. of items on loan, reached after the system has counted the borrower's current loans. The Refuse loan extension fires here with guard [too many books].
• status validation, reached after the BookBorrower's identity has been confirmed. No extension attaches to it in this example; a point is declared whenever the requirements might later hang a conditional behaviour there.

Extension points keep the base's flow auditable: a reader of the base ellipse sees the named hooks and can look up which extensions attach to each. Without them, an <<extend>> arrow is just "this fires somewhere in here", which is too vague to be useful in a contract.

Actor generalisation, use-case generalisation, composite (multi-level) use cases, and extension points, each on a small worked example with a note on when to use it.

When NOT to use these refinements

A diagram with more refinement arrows than associations is over-modelled. Three signs that you are overusing the stereotypes:

• An <<include>> with one parent. If only one use case includes a particular sub-task, the sub-task is not being reused; it is being prematurely factored. Inline it into the description.
• An <<extend>> with no extension point. Without a named extension point, the extension is just an alternative path of the base. Document it as an alternative scenario in the base's description (section 8) rather than as a separate ellipse.
• Generalisation between use cases that share no actor. Use case generalisation rarely earns its place in business systems; it is more useful in tooling that auto-generates code from the model. For COMP433 projects, prefer <<include>> for shared sub-tasks and <<extend>> for variants, and reach for generalisation only when the two are genuinely the same use case at different specificity levels.

A second worked example: the MHC-PMS

The Mentcare mental-health patient-management system (MHC-PMS), Sommerville's running example, exercises the same machinery in a different domain. Its actors are the Medical receptionist, Nurse, Doctor, Manager, and the external Patient record system (a secondary actor). Typical use cases: Register patient, Unregister patient, View patient info, Contact patient, Transfer data, View / Edit patient medical record, Setup consultation, Export statistics report, Generate medical report.

One detail is worth singling out, because it is easy to draw wrongly: Transfer data is initiated by the medical receptionist, but its result flows out of the system to the Patient record system. The external records system is therefore a secondary actor: the association line leaves the boundary on the far side of the Transfer data ellipse, with the receptionist on the near side. The receptionist triggers the use case; the records system receives its output. Distinguishing the primary actor who starts a use case from the secondary actor on the receiving end is exactly the kind of thing the diagram exists to make explicit.

Multi-level (composite) use cases

For larger systems, a single top-level diagram becomes unreadable. The standard pattern is to draw a high-level diagram with composite use cases (each one labelled with a verb phrase like "Manage patient registration"), and to draw a separate first-level diagram for each composite that decomposes it into its constituent use cases. A second-level diagram may decompose a particular first-level use case further, if needed.

A composite use case is marked with a small grid icon to signal that it decomposes further. For the MHC-PMS, the course uses three levels:

• Top level (overall system). Composite use cases "Manage patient registration", "Manage patient medical record", "Generate medical report", alongside simple ones such as "View patient info", "Export statistics report" and "Setup consultation".
• First level. Each composite is magnified: "Manage patient registration" splits into Register new patient and De-register existing patient; "Manage patient medical record" splits into View patient medical record and Edit patient medical record; "Generate reports" splits into Generate prescribed drugs report and Generate patient reports (itself still composite).
• Second level. The still-composite "Generate patient reports" splits into Generate admitted-patient report and Generate discharged-patient reports.

Each level keeps the same system boundary (MHC-PMS) and shows only the actors relevant to that region. Treat the top-level diagram as a map of the system, and each lower-level diagram as a magnified region of that map; decompose only as far as readability requires.

Use case descriptions: the diagram is the index.

A use case ellipse on a diagram is barely a label. The use case itself is fully specified in a structured description. This is the same template the requirements companion uses in Section 8; here it is applied to use cases specifically.

The fields are: System Name, Use Case Title, Description, Actors, Data, Stimulus/Trigger, Pre-conditions, Workflow (or Sequence/Flow of Events), Post-conditions/Response, Comments. Below is the course's canonical worked example.

The same template applied in a different domain, the MHC-PMS "Transfer patient data" use case, shows it is not Library-specific. Note that the external Patient record system appears in the Actors row as a secondary actor, matching the boundary-leaving arrow on the MHC-PMS use case diagram:

Scenarios: normal, alternative, error

Each time an actor interacts with the system, the triggered use case instantiates a scenario: a specific path through the use case with no branching. Scenarios are typically documented as text alongside the diagram and serve as the readable narratives that customers and testers can confirm against. For each non-trivial use case, the course expects at least three scenarios:

• Normal scenario. The happy path that completes successfully under the typical conditions.
• Alternative scenario. An equally successful but different path (a different actor, a different starting state, a non-default flow).
• Error scenario. An unsuccessful outcome with explicit handling. What happens when the pre-condition fails, when the network drops, when the data is missing.

Worked scenarios for "Borrow copy of a book":

Notice that the two error scenarios describe quite different failures: one is a business rule violation (too many books), the other is a physical/data integrity issue (damaged barcode). Both are equally valid sources of requirements: the first generates "the system shall enforce a maximum of six items on loan"; the second generates "the system shall provide a manual barcode entry option".

Activity diagrams: flow, decisions, parallelism.

An activity diagram captures the workflow of a use case or a business process. It is the right diagram when the team needs to talk about the order of work, the decisions that branch the flow, and the activities that can run in parallel.

Activity diagrams have a small, fixed vocabulary. Once the symbols are known, the diagram reads like a flow chart with two added powers: it can show parallelism explicitly, and it can assign activities to actors using swimlanes.

Beyond drawing a workflow that is already understood, activity diagrams are an elicitation tool. Drawn during requirements work, they help the team see how use cases interact to achieve a business process, and they frequently surface use cases and operations that the static use case diagram missed. They model the system's behaviour and the dependencies and coordination between activities, and a well-formed one has a property worth checking explicitly: the flow must not get "stuck", every path eventually reaches a final node. Although they are most often drawn for a use case or a business process, an activity diagram can be attached to any model element to describe its dynamic behaviour.

Notation

Watch the Book room use case become an activity diagram, with each step of its description highlighted as the matching action appears.

Decision vs fork, merge vs join

Two pairs of symbols are routinely confused, and the distinction is the most-marked correctness point on this material. A decision (diamond) chooses one of several guarded branches: its branches are alternatives, and exactly one fires. A fork (bar) starts all of its branches at once: its branches are concurrent. The test is simple. Are the branches a choice (one of them) or parallel work (all of them)? "New patient? create vs search record" is a decision; "place order, then send the confirmation email and update inventory" is a fork, because both happen.

Each opening symbol must be closed by its partner: a decision is closed by a matching merge (the diamond that brings the alternatives back to one path), and a fork is closed by a matching join (the bar that waits for every parallel branch to finish before continuing). An unmatched decision usually means a branch that silently never rejoins; an unmatched fork means concurrency that is never synchronised. Guards on a decision should be mutually exclusive and exhaustive, so exactly one branch is always taken.

A worked fork / join: in a "process order" workflow, the initial node leads to Receive order, then a fork runs two paths in parallel, Fill order (which itself contains a decision, priority vs regular delivery, closed by a merge) and Send invoice then Receive payment. A join waits for both the goods and the payment before Close order and the final node. The fork says both happen; the join says wait for both.

The fork and join for steps that run at the same time, and the merge that closes a decision.

Two granularities: a use case flow, or a whole process

The same notation serves two levels. At the use case level, an activity diagram unpacks one use case ("Borrow copy of a book": locate the book, then fork to stamp the book and record the borrowing in parallel, then join). At the business-process level, it spans several use cases and actors ("book a journey": reserve flight, hotel and car in parallel, with a loop that repeats the car reservation until it succeeds, then confirm). Iteration like that loop, and parallelism like those reservations, are exactly what an activity diagram adds over a numbered list. Keep one granularity per diagram; mixing a single use case and a whole process on one page makes both hard to read.

Tying it back: the Library Borrow / Return workflow

The activity diagram for the Library's Borrow and Return use cases pulls together everything in this section: swimlanes for the two actors, a decision, a fork and join for the parallel stamping and record-keeping, and an explicit loop so a member can process several books in one visit. Iteration is the one piece of vocabulary the earlier figures did not need; here the [another book] edge feeds the flow back to the borrow-or-return decision until the member is done.

Loops: repeat, retry, and guarded exit

Loops are how an activity diagram expresses "do this more than once", and they take a few shapes worth recognising, all built from an ordinary decision whose branch points back into the flow:

• Repeat returns to an earlier action to process the next item, the [another book] edge above.
• Retry returns to a step after a check fails, so the actor can correct and try again, a declined payment or an invalid entry that must be re-entered.
• Guarded exit leaves the loop when a condition is met or a limit is reached, a maximum number of attempts, or a timeout that routes to an alternative ending.

A retry loop and a guarded exit usually appear together: try, check, and on failure either loop back or, once the attempts run out, leave by a different edge. The case study in the next section draws a retry loop in full.

When to draw an activity diagram

Activity diagrams pay back when the workflow has at least one of: a non-trivial number of decisions, parallel work that the team needs to discuss explicitly, or coordination across multiple actors. They are over-engineering for use cases with a single linear path of three or four steps.

Two practical conventions:

• One activity diagram per use case is the typical granularity. Higher-level activity diagrams (business-process view) are also common, but mixing the two granularities in one diagram makes both hard to read.
• Swimlanes are worth the effort as soon as more than one actor is involved. The same activities, drawn without swimlanes, lose the information about who does what.

From requirements to models: a booking system, end to end.

The two behavioural views in this chapter, the use case diagram and the activity diagram, are usually drawn back to back from the same requirements. This case study takes one small system from a short requirements description through to both diagrams, so the bridge between them is concrete. The worked example in section 14 carries a single requirement all the way to a class fragment; here the focus is the two diagrams an analyst draws first.

Stage 1: the requirement description

A boutique hotel wants a small online booking system. From a stakeholder workshop, the analyst captures:

Stage 2: user requirements

The description yields a short set of user requirements (UR), each a complete task from someone's point of view:

Reading the nouns and verbs (section 7): the nouns Guest, Hotel Manager, and the external payment provider become actors; "search", "book", "cancel", "maintain", "pay", and "check availability" become candidate use cases; the guest-verb pairings become associations.

Stage 3: the use case diagram

Two primary actors (Guest, Hotel Manager) and one secondary actor (Payment Provider) sit around the boundary. Every booking checks availability and takes payment, so both are <<include>> sub-tasks (Check availability is shared by Search rooms and Book room); a promo code is optional, so it <<extend>>s Book room. Manage room inventory is not one task but several (add a room, update a rate, set availability, remove a room), so it is drawn as a composite use case (the small grid marker) that expands into its own lower-level diagram rather than sitting as one vague catch-all ellipse.

Stage 4: the use case description

The central use case, Book room, expands into the template from section 8:

Stage 5: the activity diagram

The same Book room flow, drawn as an activity diagram, makes the order of work, the decisions, the retry loop, and the hand-off to the external provider explicit. Swimlanes assign each step to the Guest, the Booking System, or the Payment Provider.

Read it against the description and every action traces back to a workflow step or an alternative path. The use case description and the activity diagram describe the same behaviour at two levels: the description in words, the diagram in flow.

Class diagrams: the system's static structure.

A class diagram shows the classes in a system and the associations between them. It is the longest-lived diagram on most projects, because the static structure changes more slowly than any particular flow through it.

Classes, not instances. A class diagram shows the types in the system, Book, LibraryMember, the kinds of thing that can exist, not the particular copy on the shelf or the member at the desk. To show specific instances at one moment (this member, that copy, with concrete values) you draw an object diagram, the section immediately after this one.

Where the classes come from: three design approaches

Before any class is drawn you decide how to decompose the system. Adel's notes name three classic strategies; analysis-level work usually blends them, but it helps to know which one you are leaning on.

• Top-down. Begin with the whole system, split it into subsystems, then into classes. Strong when the high-level architecture is already understood; the risk is inventing classes the requirements never asked for.
• Bottom-up. Begin with concrete domain things (a book, a copy, a member) and compose upward. This is exactly what noun-verb analysis does, and it keeps the model anchored to the requirements text.
• Middle-out. Begin with the few central concepts you are sure of, then work outward in both directions. Common when one or two entities (Patient, Loan) clearly anchor the domain.

In analysis we work mostly bottom-up from the requirements, using the noun-verb method below, and sanity-check it against a top-down view of the whole. The goal is classes justified by the text, not by the developer's imagination.

Reading a class out of the other diagrams

A class box has three compartments, and each maps to something the behavioural views already produced. This is the bridge from behaviour to structure: the name compartment comes from an actor or entity, the attributes from the data the use cases touch, and the operations from the use cases that object performs. Every part of a class should be answerable to an earlier model.

Anatomy of a class box

Visibility, in full

UML's visibility markers map directly to access modifiers in mainstream OO languages, with one or two extra options:

• + public: accessible by any client of the class.
• - private: accessible only by members of the same class.
• # protected: accessible by members of the class or any subclass.
• ~ package: accessible by classes in the same package.
• / derived: a value computed from other attributes, not stored independently (e.g., /age computed from birthDate).

Relationships: associations, generalisation, aggregation

Multiplicity, in detail

Multiplicity on an association end answers: how many instances of this class can participate in the relationship at one time? Standard values:

Aggregation vs composition

Both denote "part of" relationships, but with different lifetime semantics:

• Aggregation (open diamond): a "weak" part-of. The part can exist independently of the whole. A team has members; if the team is dissolved, the members still exist. Aggregation is a hint about intent more than a binding constraint.
• Composition (filled diamond): a "strong" part-of. The part's lifetime is tied to the whole. If the whole is destroyed, so are the parts. A house has rooms; destroy the house and the rooms cease to exist.

Modern style is to avoid aggregation where composition would do, because aggregation is semantically weak: most tools and reviewers cannot distinguish it from a plain association. Composition, by contrast, has bite.

Association classes

When an association itself has attributes that do not belong to either of the connected classes, those attributes live on an association class. Example: a Loan between a LibraryMember and a BookCopy has its own startDate and returnDate; these are attributes of the borrowing relationship, not of the member or of the copy. The association class is drawn as a regular class box, connected to the association line by a dashed link.

Data-driven noun-verb analysis

The standard recipe, introduced by Shlaer and Mellor in the late 1980s and used in the course, is the noun-verb analysis: read through the requirements document and underline every noun phrase; collect those noun phrases as a candidate class list; discard inappropriate ones (redundant, omnipotent, vague, meta-language, outside the system scope, or really attributes of something else); then identify every verb and assign verbs to candidate classes as operations. The result is a first-cut class diagram that is grounded in the requirements you wrote, rather than the developer's imagination.

Six categories of "inappropriate" noun, worth memorising because they recur in reviews of analysis-level class lists:

• Redundant. Two nouns name the same thing (e.g., "library member" and "borrower" both refer to LibraryMember).
• Omnipotent / "manager" / "system". Vague catch-alls that would do everything; usually a sign the analyst stopped abstracting too early.
• Vague. "Information", "data", "item"; not concrete enough to model.
• Meta-language. Words about the requirements rather than the domain ("requirement", "feature", "constraint").
• Outside the system scope. Real things, but the system does not need to know about them.
• Actually attributes. "Title" and "ISBN" sound like classes but are attributes of Book.

Heuristic categories from Booch's Object-Oriented Analysis and Design for which nouns make good classes:

• Tangible or real-world things (book, copy, course, room).
• Roles (library member, student, doctor, member of staff).
• Events (arrival, departure, request, payment).
• Interactions (meeting, consultation, treatment).

Analysis classes vs design classes

An analysis class abstracts one or more classes of the eventual design; it models the problem domain, not the solution. It focuses on functional requirements, defines responsibilities (cohesive subsets of behaviour), names attributes at a domain level, and shows the relationships it takes part in. A design class adds full method signatures and types, tightened visibility, infrastructure classes (persistence, controllers, factories), design patterns, and navigability. In this course, Phase 3 expects an analysis-level class diagram drawn from your requirements; reserve the design-level detail for later.

Worked example: the Library, noun analysis

Adel's running example. Underline the nouns in the requirement, then sift them.

Candidate classes kept: Book, BookCopy, Journal, LibraryMember, StaffMember. Discarded or demoted: Library (the system itself), item (vague), three weeks / six / 12 (loan period and limits: attributes and multiplicities, not classes).

Noun-verb analysis gives candidates, not answers. For each one you argue keep, reject, or it depends, and the reasoning matters more than the verdict:

The teaching point: a good class list is defended, not asserted. Be ready to say why BookCopy earns its place and library does not, to name the alternative you considered (the LibraryItem superclass, the Role class), and why you set it aside.

What makes a good analysis class

Five criteria, drawn from Cooper, Larman, and the broader OO design literature, that practitioner reviews look for:

• Its name reflects its intent. "AccountManager" tells you what it does; "Util" or "Helper" tells you nothing.
• It is a crisp abstraction. Models one specific element of the problem domain, not several.
• A small, defined set of responsibilities. One reason to change; one cluster of behaviour.
• High cohesion. Its attributes and operations are tightly related.
• Low coupling. Few necessary associations with other classes; nothing accidental.

Associations: direction, roles, and reflexive links

Name an association with a verb phrase and read it in a direction. A plain line is bidirectional; an arrowhead makes it unidirectional (the tail class can reach the head class, but not the reverse). An association connects classes (the type level); a link is one instance of it between two specific objects (Adel: links instantiate associations).

Generalisation: the substitutability test

Draw generalisation only for a genuine is-a. The test is substitutability: anywhere the code expects a LibraryMember you can hand it a StaffMember and nothing breaks. Wrong: "Car is-a Engine", a car is not a kind of engine, it has one, so that is an association (Car has Engine). Right: "ElectricCar is-a Car". If the substitution would be absurd (an Engine where a Car is expected), it is not generalisation.

A second domain: the MHC-PMS

Adel's other running example, from Sommerville's mental-health-care patient management system. It shows a different shape: one central, attribute-rich class, Consultation, that anchors the whole model.

Dependency, data types, and enumerations

A dependency (dashed line, open arrowhead) is a transient "uses" link, the weakest relationship: if an Order merely takes a Product as a method argument, that is a dependency, whereas an Order that holds Products over time is an association. Two stereotypes in guillemets flag boxes that are not ordinary domain classes: an «enumeration» is a type whose value must be one of a fixed, named list (a Category is Book, Music, Video or Software and nothing else); a «dataType» is a type with no identity of its own, defined purely by its value (two Money amounts of the same value are interchangeable, whereas two Order objects are distinct even with identical fields).

Cohesion: high versus low

Most weak class models fail on cohesion or coupling. The test is simple: count the reasons to change. A low-cohesion Patient that also sends reminder emails, generates PDF reports, connects to the database and calculates insurance has four reasons to change; touch the email server and you risk breaking billing. A high-cohesion Patient does one job (be a patient) and moves the rest to a NotificationService, a ReportGenerator, a PatientRepository and an InsuranceCalculator, so it changes only when what it means to be a patient changes. Fewer reasons to change is higher cohesion.

Object diagrams: a snapshot of the running system.

A class diagram shows the types; an object diagram shows specific instances of those types and the links between them at a single moment. Adel introduces it immediately after the class diagram, because the quickest way to test a class model is to populate it with real objects and see whether everything fits.

What an object diagram is

Objects are instances of classes. An object diagram captures objects and the relationships between them, that is, instances of classes and the links (instances of associations) between them. It is built during analysis and design to illustrate data and object structures, to specify snapshots of the system at a point in time, and above all to validate the class model, asking whether the classes are sufficient to hold the data and support the methods the system needs. Analysts, designers and implementers all draw them.

Notation: the object icon

An object box has a name compartment and an optional attribute compartment. The name is written objectName : ClassName and is underlined (this is what distinguishes an object from a class); each attribute is shown as attribute = value. Crucially, operations and attribute types are not shown on an object diagram: it is about concrete data at one instant, not behaviour.

Worked example: a class model and its snapshot (SmartSoft)

Adel's running example pairs a class diagram with one object diagram that instantiates it. First the class model: a Company is composed of Departments and Offices; a Department is located at an Office and can contain sub-departments (a reflexive composition); a Person works at a Department and one Person manages it (a subset of works-at); a Headquarter is a kind of Office; and a Person depends on ContactInformation.

Now one snapshot of that model: the company "Smart Software", with its actual departments, office, an employee, and his contact record. Every box is an instance of a class above; every value is concrete; no operations appear.

A second snapshot: the Library

The same idea against the Library class diagram from the previous section: one member, one copy, one borrowing link.

Sequence diagrams: the order of messages.

A sequence diagram shows one specific interaction: who sends what message to whom, in what order. Time runs top to bottom; participants are arranged left to right. Unlike a class diagram, which captures the system at rest, a sequence diagram captures the system in motion.

Instances, and one scenario at a time. The lifelines are instances (objects), written : Class (anonymous) or name : Class, never bare classes, because a sequence diagram shows real objects exchanging messages on one run. And one diagram tells one story: a single scenario of a single use case. Draw the normal (happy) path first as an instance diagram; fold the alternatives and errors in with combined fragments (alt, opt, loop), or draw them as separate diagrams (the generic diagram). Do not try to cram every path into one picture.

Where the participants and messages come from

A sequence diagram invents nothing. It realises one scenario of a use case, using the classes from the class diagram and calling their operations:

Consistency check. If a lifeline receives a message fetchRecord(), the class it instantiates must declare fetchRecord(). The sequence diagram is therefore a live check on the class diagram: a message with no matching operation means the class model is incomplete.

One scenario, or all of them: instance vs generic

Adel draws the distinction clearly. An instance diagram is one concrete run, no branching, the happy path: quick to draw, ideal for explaining the normal flow. A generic diagram shows the family of runs using combined fragments (alt, opt, loop) to fold the alternatives and repetitions into one picture. Rule of thumb: draw the instance first to nail the normal flow, then promote it to a generic diagram only where real branching or looping matters. Do not cram every error path into one diagram; that is what fragments, or separate diagrams, are for.

A generic diagram with an alt fragment

Figure 7 promotes an instance to a generic diagram: the authorisation decision is folded into one picture with an alt fragment, exactly the notation the legend above introduces. Solid arrows are synchronous calls, dashed open-headed arrows are returns, and the guard after each branch label decides which one fires.

UML 2.0 fragments, in detail

UML 2.0 added interaction fragments to make sequence diagrams expressive enough for non-trivial flows. The five most common operators:

Worked example: the "Deposit Cash" use case

Adel's self-service-machine example, the normal scenario. Three internal objects do the work: the front (the customer interface), the register (where money is counted and the cash reserve kept), and the dispenser (which delivers the receipt).

Back to back: the Library "Borrow a copy" scenario

The same Library modelled earlier with a use case, an activity diagram and a class diagram, now in motion for one scenario. The lifelines are objects of the classes LibraryMember, BookCopy and Loan; the messages are their operations; the alt is the activity's "limit reached?" decision.

Pitfalls

• All scenarios in one instance diagram. An instance shows one run; use alt / opt / loop (a generic diagram), or separate diagrams, for the rest.
• Forgotten returns. A synchronous call that never returns hides where control resumes; draw the dashed reply.
• Messages with no home. Sending fetchRecord() to a lifeline whose class has no such operation; fix the class diagram or the message.
• Time running upward. Messages must descend; an arrow back up the page is a modelling error, and repetition belongs in a loop fragment.
• Wrong activations. The bar should cover exactly the time the participant is processing, no more.
• Using a sequence diagram for structure. It shows one interaction over time, not what exists; that is the class diagram's job.

Step through a sequence diagram

The interactive below plays a sequence diagram one message at a time. Use it to see how activation bars grow and shrink as messages flow.

State machine diagrams: the object's life.

A state machine diagram captures the states an object passes through during its lifetime and the events that cause transitions between them. It is the right diagram whenever a class has a meaningful "current state" that callers must reason about.

Where it fits, and at what stage. A state machine describes the lifecycle of the instances of one class (a Loan, an Order, a BookCopy), so it is drawn at the design stage, after the class diagram has identified a class whose behaviour is state-dependent, the same call doing different things, or being illegal, in different states. Like the class diagram it is object-focused and long-lived; unlike a sequence diagram, which shows one scenario across many objects, a state machine shows one object across its whole life. Most classes never need one, reach for it only when an object's allowed operations change with its state.

Notation

• States: rounded rectangles with the state name.
• Initial state: filled black circle, exactly one per diagram.
• Final state: filled black circle inside a ring.
• Transitions: labelled arrows between states, labelled event [guard] / action. Any of the three parts can be omitted.
• Internal activities: written inside the state box, with the form entry / action, do / action, exit / action.
• Composite states: a state that itself contains other states (sub-states). Drawn as a state box with internal states inside it.

Theoretical foundations: from finite automata to statecharts

A state machine is a finite-state automaton: a finite set of states, an alphabet of events, and a transition function mapping a (state, event) pair to a next state. It is the oldest and most rigorously understood model of behaviour in computing, which is why the same idea drives compilers, network protocols and control systems.

• Moore vs Mealy. In a Moore machine the output is attached to the state (it depends only on where you are); in a Mealy machine the output is attached to the transition (it depends on the state and the event). UML deliberately allows both: entry / do / exit activities are Moore-style (tied to the state), while the action on a transition is Mealy-style (tied to the event). Knowing which you mean keeps the diagram unambiguous.
• Run-to-completion semantics. UML processes one event completely before starting the next: a transition, with its guard evaluation and action, runs atomically, and events arriving meanwhile queue. This is what makes a state machine implementable and free of mid-transition races, and why guards must be side-effect-free and actions short.
• Determinism. A well-formed machine is deterministic: from any state, an event and its guards select at most one transition. Two transitions on the same event with overlapping guards is a modelling error (nondeterminism), exactly the defect the diagram exists to expose.
• Harel statecharts. A flat machine suffers state explosion: model n independent on/off features and you need 2ⁿ states. David Harel's statecharts (1987), which UML adopts, add three ideas that tame this: hierarchy (a composite state groups sub-states and shares their outgoing transitions), orthogonality (concurrent regions active at once, so independent features add rather than multiply), and history (re-enter a composite state where it last left off). A UML state machine is, formally, a Harel statechart in UML notation.

Events, guards, actions, activities: the full vocabulary

A transition label has the form event [guard] / action, and each part is precise:

• Event (the trigger), of four kinds: a call event is an operation invoked on the object (borrow()); a signal event is an asynchronous message received; a change event fires when a condition becomes true, written when(balance < 0); a time event fires after a duration or at a moment, written after(30 days) or at(09:00). A transition with no event is a completion (triggerless) transition: it fires as soon as the source state's activity finishes.
• Guard: a boolean condition in [brackets] that must hold for the transition to fire. It must be side-effect-free, and across the transitions leaving one state on the same event the guards should be mutually exclusive, so the machine stays deterministic.
• Action: instantaneous, uninterruptible behaviour, run as the transition is taken (Mealy-style) or on entry / exit of a state (run every time the state is entered or left, whichever transition was used).
• Do-activity: an ongoing activity that runs while the object sits in a state (do / countDays()) and is interrupted if an event causes an exit. Unlike an action it takes time and can be cut short.
• Internal vs self-transition: an internal transition handles an event without leaving the state, so entry/exit do not re-run; a self-transition exits and re-enters the state, so they do. Confusing the two is a frequent source of real bugs.

Composite, orthogonal, and history states

These are the statechart extensions that keep a real diagram readable. A composite state contains a nested sub-machine; a transition out of it applies to all its sub-states at once, so you draw the shared cancel arrow once rather than from every sub-state. Orthogonal regions, separated by a dashed line inside a composite state, are active simultaneously: independent concerns modelled as two regions need 2 + 2 states, where flat modelling needs 2 × 2, and the gap widens fast. A history pseudostate (a circled H) remembers which sub-state was active when the composite was last left, so re-entry resumes there: it is how a "resume" feature is modelled.

When to draw a state machine

State machines pay back when at least one of the following is true:

• The class has more than two meaningful states and the transitions between them are non-trivial.
• The behaviour of the class depends on its current state (the same method does different things in different states).
• Errors and unexpected events have meaningful state-dependent behaviour.
• The state machine corresponds to a real, externally observable lifecycle (loan status, order status, ticket status).

Most classes do not need a state machine. Data carriers, value objects, and pure functions have no state in this sense. Drawing a state machine for them is over-engineering. Conversely, every domain object whose lifecycle is meaningful (Order, Loan, Ticket, Patient, Account) is a candidate.

Simulate the BookCopy state machine

The interactive below runs the BookCopy state machine. Fire events with the buttons and watch the current state change, with guards enforced.

Architectural diagrams: components and deployment.

Component and deployment diagrams sit higher up the abstraction ladder than the diagrams above. They are concerned with how the system is partitioned at build time and how it is distributed at run time.

Component diagrams

A component diagram shows the structural relationships between the major components of a system. A component in UML 2 is a modular part of the system with well-defined interfaces. Components offer two kinds of interface:

• Provided interfaces (drawn as a lollipop): operations the component makes available to clients.
• Required interfaces (drawn as a socket): operations the component needs from other components.

A provided lollipop fits into a matching required socket; the connection is valid if the socket's required operations are a subset of the lollipop's provided operations and their signatures are compatible.

What a component is, in theory

A component is a modular, replaceable unit of the system that hides its implementation behind well-defined interfaces. Its defining property is substitutability: anything that offers the same provided interfaces can replace it without the rest of the system noticing. That single idea is what makes plug-ins, device drivers and microservices possible.

• Component vs class. A class is a unit of code; a component is a larger unit of delivery and replacement, usually built from many classes, and defined by its interfaces rather than its internals. You design against a component's interface, never its classes.
• Interfaces as contracts. A provided interface (lollipop) is a promise the component keeps; a required interface (socket) is a need it has. A connection is valid only when a provided interface satisfies a required one (its operations are a superset, with compatible signatures). Programming to interfaces, not implementations, is what keeps the structure flexible.
• Ports and connectors. A port is a named interaction point on a component's boundary that groups the interfaces offered or needed there. Two connectors wire them: an assembly connector joins one component's required interface to another's provided interface (lollipop into socket); a delegation connector forwards an external port inward to the internal part that actually implements it. Ports and delegation are how a large component is built from smaller ones while still presenting one clean boundary.

Componentisation guidelines

• Keep components cohesive. A component should implement a single, related set of functionality. User-interface logic for one application, business classes for one domain concept, or technical infrastructure for one concern (security, persistence).
• UI classes go in application components. Screens, pages, reports, and the glue logic that wires them together belong in a UI-stereotyped component.
• Technical classes go in infrastructure components. Security, persistence, middleware, logging belong in <<infrastructure>> components shared across the system.
• Assign hierarchies to the same component. Inheritance and composition hierarchies almost always belong together; splitting them creates artificial component coupling.
• Minimise inter-component message flow. Two components that talk constantly are a sign they should be one component.
• Define component contracts as interfaces. Every service a component offers to its clients is an interface; this is what makes the component substitutable.

Deployment diagrams

A deployment diagram shows the runtime configuration of the system: which software runs on which hardware (or virtual) nodes, and how the nodes connect. It is the right diagram when the system is non-trivially distributed.

Notation:

• Nodes: 3D boxes representing a hardware or software execution environment. Common stereotypes: <<server>>, <<client>>, <<database>>, <<mobile device>>.
• Artifacts: deployable items on a node. Drawn as a rectangle with a <<artifact>> stereotype and a small document icon. Executables, configuration files, databases.
• Communication paths: lines between nodes, often labelled with the protocol (HTTPS, JDBC, AMQP).
• Component-to-node mapping: components from a component diagram are placed inside nodes to show which node hosts which component at runtime.

Nodes, artefacts, and manifestation

Deployment has a small vocabulary worth getting exactly right:

• A node is a run-time resource, split into a device (physical hardware: a server, a phone, a router) and an execution environment (software that hosts other software: a JVM, a Docker container, an application server, a browser). An execution environment is usually drawn nested inside the device that runs it.
• An artefact is a concrete, deployable file: a .jar, a .war, an executable, a config file, a database file. Artefacts are what actually get copied onto nodes, as opposed to the logical components they realise.
• Manifestation is the link between the two worlds: an artefact manifests one or more components. So the chain runs component (logical part) → artefact (the physical file that embodies it) → node (where that file runs).
• Communication paths between nodes are labelled with the protocol (HTTPS, JDBC, AMQP, gRPC); they are the run-time analogue of the component diagram's connectors.

Architecture vs architectural style

A small but useful distinction:

• An architectural style is a pattern for a system layout. Examples: layered, client-server, peer-to-peer, three-tier, model-view-controller (MVC), pipes-and-filters, service-oriented (SOA).
• A software architecture is an instance of a style, applied to a specific system. The deployment diagram above is an instance of the 3-tier style.

Architectural styles: a catalogue

A style is a reusable pattern for the system's overall layout, with a known shape and a known trade-off; an architecture is one style (or a blend) applied to a specific system. The common styles:

The 4+1 view model: why one diagram is never enough

No single diagram captures an architecture, so Kruchten's 4+1 view model (1995) describes it from several viewpoints at once, and each maps onto a UML diagram you now know:

This is the theoretical reason a chapter on system modelling needs all of these diagrams: each is a different projection of one system, and the use cases are the thread that checks the projections agree. It is the same point Sommerville makes with his four perspectives (context, interaction, structural, behavioural): you understand a system only by looking at it from more than one direction at once.

From elicitation to first-cut model: one requirement, all the way through.

The earlier sections cover each diagram in isolation. This section walks one user requirement from the elicitation interview to a first-cut design, showing the substance at each step. The example is intentionally small so the full trace fits on this page; on a real project, every requirement goes through this same chain.

Stage 1: Elicitation snippet

In a structured interview with the head librarian of the Birzeit Main Library, the analyst captures the following extract (paraphrased to the level of detail an interview transcript would record):

Notice what the interview transcript already contains, even before any modelling: an actor (BookBorrower, called "the student"), a sub-actor implied (Librarian, the speaker), a business rule (max six items), a domain rule (loan periods depend on book type), a normal flow, an exception (damaged barcode), and an alternative outcome (loan refused). The analyst's job in the next stage is to write that down in a form that survives months of execution.

Stage 2: User Requirement (UR) and System Requirements (SR)

The transcript converts into one UR with two SR refinements. The numbering follows the convention used in Ch.3 section 3.

Each SR is a developer-precise refinement of UR3 (note the shared prefix). Each is testable: SR3.1 corresponds to a test case for the seventh-loan refusal, SR3.2 to a parameterised test of the three loan periods, SR3.3 to a manual-entry test plus exception verification.

Stage 3: Effort estimate for UR3

Using the per-UR method from Ch.3 section 11, the team estimates UR3 as follows. The estimate is in person-weeks (pw); the calculator in Ch.3 takes these numbers and rolls them up into the project total.

This estimate is what the customer is asked to authorise. If the customer later asks for "also support overdue notifications", a new UR is added, re-estimated, and added to the project total before any work begins.

Stage 4: Use case ellipse and description

UR3 maps to one primary use case (Borrow copy of a book) plus its refinement use cases (Compute return date as <<include>>, Refuse loan as <<extend>>). The diagram form is in figure 3 above; the textual form, expanded into the eight-field template used throughout section 8, looks like this:

This textual description is the contract; the ellipse on the diagram is the index entry. The activity diagram (section 9) would draw steps 1 through 7 as actions in swimlanes for BookBorrower, Librarian, and System, with a decision diamond at step 3 splitting the normal and refusal branches. The sequence diagram (section 11) would draw the messages between Librarian, System, BookCopy, Loan, and PersistenceStore for the normal scenario.

Stage 5: First-cut class fragment

From the noun-verb analysis of the UR / SR text (section 10): nouns LibraryMember, Book, BookCopy, Loan, Librarian; attributes loan count, status, barcode, start_date, return_date, type; verbs borrow, return, compute return date, refuse. The first-cut class diagram fragment for UR3 is:

Three observations worth taking away from the fragment:

• Every SR has a home. SR3.1 (max six loans) is the 0..6 multiplicity on the borrows association. SR3.2 (compute return date) is the computeReturn() operation on Loan. SR3.3 (manual barcode entry, damaged-barcode exception) does not appear here because it is a workflow concern; it lives in the activity diagram for the use case, not in the class fragment.
• Aggregation vs composition is a domain decision, not a notation choice. Book aggregates BookCopy because copies survive the deletion of the catalogue record (they are physical books on the shelf). If we were modelling an e-book platform where deleting a Book also deleted its copies, composition would be correct.
• The class fragment surfaces a question the requirements missed. The Loan association class implies a Loan has a single member at a time. But what about historical loans (a copy borrowed by two members at different times)? The class diagram makes the team ask whether Loan instances are kept after return, and at the point that question is asked, the team goes back to UR3 and adds: "the system shall keep loan history for at least seven years for audit." That is the iteration loop in figure 1 made concrete.

What this thread illustrates

One requirement, five artefacts, each refining the previous and each surfacing questions the previous stage missed. The work of UML modelling is not drawing pretty ellipses; it is the disciplined re-asking, at progressively finer detail, of "what exactly does the system do?". A model that lets you skip the re-asking is not a useful model. A model that forces the re-asking, and lets the team write the answers down so they survive the project, is the artefact this chapter is teaching you to produce.

Eight modelling pitfalls that show up in practice.

Drawn from Fowler's UML Distilled, recurring review findings on real UML models, and Brooks' general observations about modelling.

Sources cited above, and where to go next.

The course textbook and Prof Adel's lecture notes anchor the chapter; the books below are the works directly referenced in the text and the standard practitioner references.

Course material

UML, primary references

Originals that fed into UML

Class and component design

Adjacent course material