Activity and swim-lane diagrams — COMP 410

Functional modelling works at two levels

Functional modelling describes the processing a system performs. It is one of the element sets of the requirements model, sitting beside scenario-based modelling (what the user is trying to achieve) and class-based modelling (what the system is made of), and it addresses two levels of procedural abstraction at once.

The upper level is user-observable functionality: processing the user starts directly and whose result the user sees. "Return a tool" is one of these in BorrowBox — the member does something, and something visibly happens. The lower level is the operations inside analysis classes that actually do the work: ToolCopy.gradeCondition(), LateFee.assess(), Locker.release(). The same function exists at both levels, described once for the person paying for the system and once for the people who have to build it. Keeping the two levels distinct is the whole skill — an analysis-level model that starts naming methods has slid into design, and a design-level model that only says "return a tool" has not said anything a programmer can use.

The activity diagram

At the analysis level the notation for procedure is the UML activity diagram. Its vocabulary is small and worth being able to list cold: a rounded rectangle is an action (one step of processing), an arrow is flow from one action to the next, a decision diamond is a branch with every outgoing arrow labelled by the condition that selects it, and a heavy horizontal bar is a fork (or, read the other way, a join) showing that the flows either side of it happen in parallel. The diagram supplements a use case by drawing the flow through one scenario, including the branches the use case narrative mentions only in passing.

That last clause is the thinking move. A use case sentence like "the librarian inspects the tool and re-shelves it" hides a decision: what if the tool comes back damaged? Drawing the flow forces the decision diamond into the open, and the diamond forces you to name both branches. Pressman's own advice is to draw activity diagrams at analysis level only where the functionality is genuinely complex — a linear three-step scenario is already fully described by its text, and a diagram of it is an artefact to maintain for no information gained.

Swim lanes add the "who"

A swim-lane diagram is the same activity diagram partitioned into parallel vertical segments, one per actor or analysis class, with every action placed in the lane of whoever is responsible for it. Nothing else changes: the same actions, the same decision diamonds, the same forks, the same flow derived from the same use case.

What the partition buys you is responsibility, and specifically the hand-offs. Every arrow that crosses a lane boundary is a point where work passes from one party to another, which means it is a point where an interface must exist, where information can be lost, and where the requirements are most likely to be wrong. Counting boundary crossings is a cheap and surprisingly good measure of how risky a workflow is. It also tells you when the notation is not worth it: if every action ends up in one lane, you have drawn an activity diagram with a decorative border.

Worked example — BorrowBox return-and-inspect

The use case Return a tool reads, in one sentence: the member drops the tool into any open locker bay, and the librarian inspects it and puts it back into circulation. Drawn as a flow it becomes six actions and one decision. The member places the tool in the bay. The locker senses the load and shuts the door. The locker controller alerts the librarian's worklist. The librarian inspects and assigns a condition grade — the decision. Grade A or B, and the copy is re-shelved as Available; grade C or worse, and the librarian logs a DamageReport and routes the copy to repair.

Now partition it. Actions one belongs to the Member, two and three to the Locker, four to six to the Librarian. Three lanes, and exactly two boundary crossings: member to locker, and locker to librarian. Those two crossings are the two interfaces the architecture is obliged to supply — a physical load sensor with a debounce rule, and an event channel from the locker estate into the librarian's queue. Neither of them appears anywhere in the one-sentence use case, and both of them are where this feature will actually go wrong.

The activity diagram for Return a tool, drawn as a directed graph. The Inspect node is the decision: both outgoing arrows carry the condition that selects them, which is the rule a decision diamond enforces. Six actions, one branch — and the damage branch exists nowhere in the one-sentence use case.

The same six actions, partitioned by responsibility. Read down: work crosses a lane boundary twice — member to locker, locker to librarian. Each crossing is an interface the design must supply and a place the requirements can be wrong; neither is visible in the flow above.