System Sequence Diagrams, Activity Diagrams and UML Foundations

# System Sequence Diagrams, Activity Diagrams and UML Foundations

7.1 Static and Dynamic Views — Where Requirement Analysis Sits

Requirement analysis sits between the business world and the software world. Its job is to capture what the system must do before you decide how to build it. To do that well you need two complementary pictures of the same system at once — what it is when time is frozen, and what it does as time moves. This section makes that distinction precise and shows why use cases and activity diagrams belong to the dynamic family, how business processes feed requirement discovery, and why the lecture repeats the phrasing deliberately.

7.1.1 The Two Views of Any System

Every software system needs to be understood from two angles at the same time. One angle is a snapshot view: what boxes exist, what their names are, what they contain when time is frozen. The other angle is a flow view: how things happen over time, what message goes where, what step follows what. The first is called a static view. The second is called a dynamic view or interaction view. Static here means time-invariant structure; dynamic means time-ordered behavior where interaction drives change. Modeling is about capturing both, and neither alone is complete.

Think of a building versus its daily life. A floor plan shows walls, rooms, and doors — that is the static view. A daily schedule of who moves through which door, in what order, with which keys — that is the dynamic view. You need the floor plan to know what can be connected, and you need the schedule to know what actually happens.

Keeping this distinction helps you pick the right diagram for the question at hand. If the prompt asks "what are the conceptual classes," you draw static. If it asks "what happens when the cashier enters an item," you draw dynamic.

Label note for this lecture: The lecture sometimes labels an interactive diagram to mean dynamic diagram. Treat the terms as synonyms here: any diagram that shows interaction among participants over time is dynamic.

Visual intuition: picture two windows onto the same shop. The static window is a table: rows are kinds (Client, Campaign), columns are attributes, cells are associations — no arrows, no time. The dynamic window is a vertical timeline: time flows top to bottom, actors sit on the left, the system sits on the right, solid arrows fly left-to-right as messages. The y-axis is time; the x-axis is "who." Peaks and branches in that timeline mark choices and parallelism; cross-lane hops mark handoffs. One sentence takeaway: static tells you what can be said; dynamic tells you what is said and when.

System sequence diagrams and, later, sequence diagrams for object design also belong to the dynamic family in full. The point of learning both families is to get complementary pictures of the same system: structure plus behavior. Without the static you name things inconsistently; without the dynamic you miss missing events.

7.1.2 From Business Processes to Use Cases

A business process is a coherent group of tasks that an organization does to achieve a business outcome — for example "sell items in a shop," "admit a student to an academic program," or "buy items at a supermarket." A use case is a textual story of an actor using the system to achieve a user goal that typically mirrors one such process element.

Requirement analysis can start from business processes. Look at the real work the organization does, break it into processes and sub-processes, and turn those into use cases. In that sense each use case relates back to a business process element. You are not inventing software features in the abstract; you are mirroring what people already do to achieve a goal. This outside-in habit — real work first, software second — is the whole point of analysis.

Another path to the same requirements is the activity diagram, which the lecture describes as a business flow diagram. Compare the two lenses side by side:

• A use case says "who wants what from the system" — actors, goals, preconditions, main success steps, and extensions, mostly in text.
• An activity diagram says "what task follows what task in the real operation" — activities as rounded rectangles, ordered by arrows, with diamonds for choices and bars for parallel work.

For example, if you look at selling in a shop or admitting a student to an academic program or buying items at a supermarket, the ordered list of tasks is the business process. Capturing those flows gives a second lens on functional requirements, overlapping with use cases but adding explicit order, branching, and parallel work. Redundancy between the two is welcome at this stage because it builds understanding: the use case keeps you honest about goals and stakeholders, the activity diagram keeps you honest about order and handoffs.

Body text bridge: which to start with? In practice teams often sketch a coarse activity flow to see the end-to-end business order, then harvest use cases from it (each coherent flow segment becomes a candidate use case), then detail one use case's scenario in an SSD. The reverse — starting from a use case and sketching its activity — also happens when a single goal's branching is heavy. Neither path is mandatory; what matters is that the two artifacts are cross-checked for consistency.

7.1.3 Pedagogical Note on Granularity and Repetition

The lecture returns several times to the same idea — static versus dynamic — using different phrasing: "snapshot versus over time," "boxes view versus flow view." This repetition is intentional. The first phrasing helps you name the categories. The second helps you remember when each category is useful: snapshot when you want to freeze structure, flow when you want to see what happens next. Keeping both wordings together makes the distinction stick, especially under exam time pressure where a quick label ("is this about structure or story?") chooses the correct diagram family in seconds.

The same granularity care appears in how business processes become use cases: do not invent tiny single-click use cases and do not pack a whole department into one giant use case. The course calibrates to medium granularity suitable for a 30- to 40-minute classroom exercise — that theme recurs in sections 7.3 and 7.4 as the Manage versus Add decision.

Real-world and domain connection: In retail, banking, and university admission, analysts always start by shadowing the real process (the business flow), then write use cases to freeze each actor's goal, then sketch activity flows to expose hidden branches (for example, "what if the card is rejected?" or "what if the student is already enrolled?"). Teams that skip the flow view often build software that automates the wrong order; teams that skip the snapshot view build software where the same concept has three names. Using both views keeps the business conversation and the technical conversation aligned — domain experts validate the flow (they recognize their work), engineers validate the structure (they see what must be built).

7.2 Unified Modeling Language — A Notation System for Modeling

UML is the shared picture language you will use for every view introduced in 7.1. This section makes precise what UML is, what it is not, which views it covers, how it came to replace older notations in places like database design, and how to get fluent fast enough for exam diagram-creation tasks.

7.2.1 Definition, History and What UML Is Not

The Unified Modeling Language (UML) is a language for specifying, visualizing, and constructing the artifacts of a software system. An artifact here means any outcome of development work in information technology: source code, a database design, a model, a diagram, a document. Code itself is an artifact. UML supplies the notation to picture those artifacts so they can be discussed, checked, and then built. That "picture is worth a thousand words" role is why teams show a picture to a domain expert rather than reading code to them.

What UML is not matters as much as what it is.

• It is not a programming language. You cannot execute a class diagram directly (code generation from models exists in tools, but the diagram itself is not the program). If you write precise symbols, you are specifying intent, not issuing a compiler command.
• It is not a process that you follow step by step to get an automatic output. It does not tell you to "do step 1, then step 2, then a design emerges." It is a notation system you apply within a process — for example the Unified Process — to model systems with object concepts.
• It is notation plus semantics, not just pretty shapes. A line means an association with multiplicity and reading direction; an arrow type means sync versus async; a bar means fork versus join. The visual choice carries meaning that a reviewer will check.

History in one line: UML started in 1997 as the unification of competing object modeling notations (Booch, OMT, OOSE), and has gone through many variations and changes since then — UML 1.x and then UML 2.x, where activity diagrams moved from a specialization of state diagrams to full-fledged artifacts. It has become a de facto standard for modeling across industry, which is why the course uses it and why Larman Chapter 6 is the prescribed reading bridging lecture and textbook.

Visual intuition: imagine a city from above. The use case view is the tourist map pins (who comes for what). The static view is the zoning map (which building types where, with connections). The dynamic view is the traffic flow animation (which street used when, where queues form). The component/deployment views are the construction-site and logistics maps (which prefabricated parts assembled where, which site hosts which service). One city, many maps — aligned by names.

7.2.2 Artifacts, Views and How UML Replaces Older Diagrams

Because UML is rich and extendable, it is used even where other notations once ruled. For database design, teams now often use UML class diagrams instead of entity-relationship (ER) diagrams. That shift shows how the same notation system covers different engineering needs — an entity in ER maps to a class in UML, a relationship maps to an association, and attributes remain attributes — but UML adds operations (in design), visibility, and a unified way to talk about behavior nearby.

Through UML you obtain many windows onto one system without redrawing the system itself:

• Use case view answers scope: which actors, which goals, what is in and out. A use case diagram lists ellipses and actors; the accompanying use case text carries preconditions, success guarantees, and extensions.
• Component view and deployment view answer build-and-run: how parts are packaged (components, packages) and where they run (nodes, artifacts deployed to nodes).
• Static view (class / domain model) answers vocabulary: what conceptual classes exist, with which attributes and associations, frozen in time.
• Dynamic view (sequence, activity, state) answers story: who talks to whom, in what order, under which guards, with which parallel splits.

Each view comes from drawing a different diagram family, not from changing the system. When you draw all of them you are looking at the same subject from several windows. That is the modeling habit industry reviews rely on: teams show a use case view to check scope with domain experts, then a static view to check structure, then dynamic views to check story order, then component and deployment views to check build and run constraints. A missing view is a missing question that a stakeholder would have asked.

Real-world note: The multi-view habit is why a banking review shows a use case view for regulators, an activity view for operations staff, a class view for persistence designers, and a deployment view for infrastructure — same loan system, different questions, same names kept consistent.

7.2.3 Tools and Practice Guidance

The lecture encourages starting right away with a modeling tool and drawing for any system you think about. The specific tools named are:

• ArgoUML — free, open source, often recommended for beginners because it runs everywhere and checks UML well-formedness.
• StarUML — lightweight and widely used for quick class and sequence sketching.
• Visual Paradigm VGO — Visual Paradigm (referred to as VGO in the talk) and IBM Rational Rose — commercial options with broad coverage, history tracking, and team features when available.

Pick any free tool that runs on your machine and start building diagrams. Do not wait for a perfect case study — model the shop where you buy tea, the admission desk, the campaign example from 7.3, the washing-machine cycle from 7.4. The tool is just the pencil; the thinking is the skill.

The only way to gain skill for creation tasks in the assessment is to create. The guidance given is to solve at least five case studies end to end, producing the full set of relevant diagrams for each. By repeatedly applying the notations to varied domains — retail sale, admission, campaign management, washing machine use, book chapter writing — you move from "I know UML symbols" to "I can model a new problem." That is exactly the transition the earlier intuition warned about: notation is cheap (hours), object thinking is built over cases (weeks). A good drill for each case is: (1) list actors and goals, (2) draft a domain model of noun phrases, (3) write one SSD for the main success scenario, (4) sketch one activity diagram with one decision and one swimlane, (5) cross-check names across all artifacts.

Real-world and domain connection: Visual modeling as communication scales beyond classrooms. In industry, a campaign management team would not email paragraphs to align a client, a manager, and an accountant — they would pin one use case diagram, one SSD for Record Client Payment, and one swimlane activity diagram for Add Campaign → Generate Invoice → Make Payment → Record Payment on the wall and ask each role to validate their lane. The tool chain listed above exists to make that wall sketch maintainable as the system grows.

7.3 System Sequence Diagrams — Events and Operations at the System Boundary

A system sequence diagram is the first place where a written scenario turns into a time-ordered picture of what crosses the system boundary. Get this diagram right and you have named every system-level operation your design must later handle. Get it wrong — by opening the black box too early or by naming a device instead of an intent — and later object design will inherit the confusion. This section makes the black-box stance precise, teaches the small notation completely, drills the naming discipline, and works two recurring classroom cases end to end: the retail Process Sale and a campaign management case study.

7.3.1 Purpose and Why It Is Not the Same as a Sequence Diagram

A system sequence diagram (SSD) is not the same thing as a sequence diagram, and the word system in the name matters. Formally, an SSD is a representation of a use case scenario as an ordered interaction, used for requirement analysis only. Its job is to capture the system events and the system operations that respond to them, while the system is still treated as a black box. You are describing what the system must react to, not how internal objects collaborate to do it.

A sequence diagram in the later design phase looks inside the system at objects. An SSD stays outside. There are only two parties in the picture: one or more actors and the single system object. In the analysis space you draw the system as one whole block; in design you decompose that block into many objects that together complete a scenario. That decomposition step is deliberate — later you will allocate each system operation to a controller or domain object — but it comes after analysis.

Key distinctions held side by side:

The lecture notes that UML itself defines only sequence diagrams. The SSD form discussed here is presented in the textbook by Larman (often cited as LAMAT / Larman) using the same sequence-diagram notation applied at system level. That framing matters for reading the textbook alongside the lecture: when Larman draws an SSD, he is intentionally using UML sequence-diagram symbols but choosing to show only the system as a single lifeline.

7.3.2 Notation, System Boundary and Time as Order

Notation for an SSD reuses UML sequence-diagram notation, but with a deliberately small subset:

• A vertical dashed lifeline for each participant: one for the actor (for example :Cashier), one for the system (:System). The lifeline box holds the participant name; the dashed line extends below to show existence over time for the scenario duration.
• A narrow activation rectangle (activation box, historically called execution specification bar) on a lifeline when that participant is engaged in handling a message. On the system side it sits around the handling of each incoming message; on the actor side it is often shown thinly or omitted in quick sketches.
• A solid arrow with a label for each message sent from actor to system. The arrow head is filled for synchronous calls (the usual case at this level — the actor waits for the system's immediate response such as display of description and running total). Labels include the operation name and parameters, for example enterItem(itemID, quantity).
• The colon collection symbol notation for the system object: :System. Writing just System would read as a class (a type). Writing :System or s1:System reads as an object, an instance. Only one system object appears because the whole software is being viewed as one black box interacting with users. In strict UML, :System is an unnamed instance of the system — not a class name — and the underline that older texts showed is no longer required in UML 2, though some slides retain it.

A system boundary is the imagined border around the software. Any message that crosses that border from an actor into the system is a system event. The system's reply is tied to a system operation — the named capability the system offers to handle that event. In the diagram, order from top to bottom is time. One message is shown after another to indicate what happens first, what happens second, and so on. Time is thus implicit in the vertical order; no extra clock symbol is needed — sequence itself carries temporal meaning. A common refinement in textbooks is the UML loop frame (a rectangle labeled loop with guard [more items]) around the repeating enterItem fragment, meaning "repeat while more items remain."

A useful analogy given is the get and post idea from web interaction: an actor issues a request (get/post), the system receives it and runs an operation on itself. The event is the incoming stimulus crossing the boundary; the operation is what the system does because of that stimulus. Another physical image: a file crossing a reception counter — the handover is the event, the clerk's register update is the operation. The diagram shows the handover arrow; the activation box shows the clerk busy.

Visual intuition: lay a ruler vertically beside the diagram. Every horizontal arrow's height on that ruler is its timestamp. Two messages at nearly the same height would be concurrent — SSDs avoid that by showing a single scenario with one thread of actor input at a time. If you rotate the diagram 90 degrees so time flows left to right, you have not changed meaning, but you have violated UML reading convention (top-to-bottom is expected). Keep time vertical and guards in square brackets on loop edges.

7.3.3 System Events and System Operations — Naming Discipline

Every system event is an external input that stimulates the system and comes from outside the boundary, usually initiated by an actor. The system must have a corresponding system operation that handles it. At this level those operations are described for the whole system. Later in design they will be broken down into many finer methods on many objects that together fulfill the system-level operation.

How to name events and responses so that analysis stays analysis:

• Keep names simple and at a high level of abstraction — one verb plus a domain noun, not a sentence.
• Use domain language that domain experts recognize, not technical jargon. enterItem and makePayment are recognizable to a cashier; invokeItemHandler is not.
• Do not tie the name to a physical device or person. Whether an item is entered by scanning a barcode or by scanning a QR code or by typing is a later design decision. Saying enterItem keeps the design open. Saying scanBarcode would prematurely fix a device choice and force every downstream sketch to assume a scanner exists. The textbook contrast is enterItem(itemID) (better — intent) versus scan(itemID) (worse — mechanism).
• Keep responses at the same high domain level rather than jumping to internal implementation language. A return like description, price, runningTotal is domain; LineItemDTO is design.
• Write names as concise business functions, for example makeNewSale, enterItem, endSale, makePayment.
• Start with a verb (add…, enter…, end…, make…) since these are commands or requests, as the Larman guideline emphasizes.

Exam note carried: When you capture system events in a written answer, writing clear domain names and keeping them consistent across your use case text, your SSD, and your operation list is part of what gets graded. Examiners often compare the three artifacts for name alignment — makeNewSale in the text must be makeNewSale on the arrow, not startSale in one place and newSale in another.

The diagram emphasizes events that cross from actor to system. Responses from system to actor also appear (the domain data returned), but the emphasis is on finding the boundary-crossing events because those define what the system must support. A useful habit: highlight every verb in the main success scenario where the actor does something to the system — each is a candidate system event.

7.3.4 Worked Examples — Point-of-Sale Process Sale and the Campaign Management Exercise

#### Point-of-Sale Process Sale — the running SSD illustration

This is the running illustration used to show how SSD text converts to picture. Only one scenario is drawn at a time, usually the main success path that is used about 90 percent of the time. If an alternate scenario is also frequent or complex (for example credit authorization), you may draw a second diagram for that alternative, but you do not crowd every alternative into one picture.

Setup: Actor is Cashier (primary actor). System is :System — the point-of-sale terminal software as a black box, not NextGenPOS or Register yet. The name :System is deliberately generic to stress the black-box stance.

Common guidance for drawing this SSD that markers check: keep one lifeline for the Cashier and one for :System. Place messages in the same order as the scenario sentences. Keep labels domain-oriented and verb-first. Accompany the picture with the scenario text so a reader can follow either form and cross-check. Apply the simplicity rule reinforced in class: if the message list starts to get long and hard to read, split into two diagrams rather than letting one diagram become dense and messy. This is the professor's most repeated analysis warning — simplicity over completeness in a single picture.

#### Campaign management case study — analysis exercise after SSD introduction

This case appears as a one-page problem statement taken from a software engineering textbook — Opti-Planet Software Engineering Panet (textbook by authors cited as starting with Panet — cited in the talk as available on the internet for further reading). Students are given five minutes in class to identify actors and use cases before discussion, so medium granularity is exercised under time pressure.

Problem context in brief: an organization that runs campaigns for clients. Work includes recording client details, managing campaigns, recording campaign completion, assigning staff to campaign work, and handling payment.

7.3.5 Student Questions and Answers

Real-world and domain connection: Retail POS, telecom call-flow diagrams, and campaign management billing all use the same black-box operation-identification habit before any class diagram is drawn. The SSD's operation list seeds three downstream artifacts at once: operation contracts (pre/postconditions on the domain model), the glossary (parameter and return-value definitions such as "receipt layout" with a sample picture), and the design interaction diagrams where one enterItem expands into a collaboration among Register, Sale, ProductCatalog, and ProductDescription. Starting from a correct boundary event list prevents rework in all three.

7.4 Activity Diagrams — Business Process Flow, Branching and Concurrency

If SSDs tell you which boundary events exist for one scenario, activity diagrams tell you how a whole business process moves — its order, its choices, its parallel lanes, and the objects that travel with it. This is the richest dynamic view in the lecture, and the most checked for notation literacy: start, activity, decision, merge, fork, join, guards, swimlanes, and object nodes must each be placed correctly, and guards must be mathematically precise and mutually exclusive.

7.4.1 Definition and Role of Activities and Business Processes

An activity is any operation performed by the system or organization — any task or function the system needs to carry out, named as a short domain phrase such as "enter item," "generate invoice," or "write chapter draft." An activity diagram is the UML replacement for data flow diagrams (DFDs). There is no DFD in UML; you show the flow of inputs and outputs through activities instead. The diagram is very close to a flowchart, but with richer features taken from state charts — notably the bar notation for concurrency and the formal guard language.

Think of it as business process modeling at the flow-of-activities level. You take a business process — any coherent group of tasks that achieves a business outcome such as "buy items," "process a sale," "admit a student," "write a chapter of a book," "dry clothes in a washing machine," or "manage a campaign" — break it into numbered activities, and show how to move from one activity to the next. The output is a controlled flow that says what to do, in what order, and what data or object travels along. That "controlled" word matters: unlike free-form prose, the diagram has executable semantics loosely grounded in Petri nets — tokens flow through the graph, activities fire when tokens arrive, joins wait for all tokens.

Where to use it in the Unified Process vision:

• In requirement analysis: to represent the real-world business process as it exists or as it is desired — the "as-is" and "to-be" before automation. This is the Business Modeling discipline view.
• In design: to draw the logic of an algorithm or the flow of an operation when you need precise step order, branching conditions, and parallel work — effectively a flowchart for a method, but with fork/join for concurrency.

In both phases it is a dynamic, behavioral diagram. It captures what the system does as action unfolds, not just what the system contains at rest. You can create one activity diagram per business process, and you can also create one per use case when that clarity helps, but doing both at full depth for a large organization can produce a large number of diagrams, so judgment is needed. In practice many teams start at a high business-process level, keep level-0 diagrams short (five to seven activities), and expand each complex activity in its own sub-diagram using the rake symbol — rather than letting one page become crowded.

7.4.2 Notational Elements — Start, Activity, Transitions, Objects and Guards

Core elements taught in sequence, each with a precise visual form examiners check:

• Start node: a solid filled circle. It marks where the flow begins. This is the first symbol on the page, placed top-left or top-center by convention for Western reading. Every activity diagram should have one start (a missing start is a common deduction).
• Activity node: a rounded rectangle. It denotes performance of an operation. Examples: "enter item," "show running total," "record client payment," "write chapter draft," "add exercises to chapter." Give each activity a meaningful name that summarizes the task in a few words, at a consistent level of abstraction across the diagram. While the activity is running, its internal steps are not expanded — the view stays at functionality level. Once the activity completes successfully, there is an automatic outgoing transition — you do not need an explicit "done" event; completion triggers the arrow.
• Transition arrow: a directed arrow from one activity to another. The trigger is completion of the source activity. You are not modeling event interrupts at this level; you are modeling normal forward movement once the current task is done. Data flow and control flow both travel along the arrow: inputs arrive, outputs leave, preconditions and postconditions hold at the arrow ends. Think of a file moving from one office desk to the next in a physical workflow — the file is the carried information, the arrow is the corridor.
• Guard condition: a condition in square brackets, for example \[hours \le 40\] or \[hours > 40\] or \[draft\ satisfactory\] or \[no\ campaign\ to\ add\]. A guard on an outgoing edge means the flow can proceed along that edge only if the condition evaluates to true. Guards on edges leaving the same decision point must be mutually exclusive (no overlap) and complete (every possible value chooses one edge) — exactly one path taken, not both and not none. Guards are how you encode if-else logic inside the activity flow without cluttering the activity names themselves.
• Decision node: a diamond shape. It marks a branch point where the flow chooses among outgoing edges based on guard evaluations. It corresponds to a conditional choice. The decision diamond itself carries no label beyond perhaps the condition name — the guards on outgoing edges carry the logic.
• Merge node: also a diamond. It marks where alternative branches rejoin into one flow. In the lecture the combined use is spoken of as decision/merge using the same diamond shape, with guards determining which edge arrives. Keeping merge explicit helps the reader follow alternative histories that meet again. Do not confuse merge with join: merge is "any one incoming history suffices to continue" (OR), join is "all incoming parallel histories must have arrived to continue" (AND).
• End node: a bullseye — a filled inner circle inside an outer circle. Some teaching sketches show a plain empty circle as an alternate, but the bullseye is the more widely recognized UML end symbol and the one to use on an exam. It marks termination of that flow path. Some flows have multiple ends; some continuous processes omit an end with justification, but for exam diagrams include a bullseye.
• Object node / object flow: an optional rectangle (often with an underlined name using colon object notation such as new Client : Client) showing an object or document that is created or used as the flow moves. For example, "new client object" after Add Client, or a "new campaign" object after Add Campaign, or a receipt document after Generate Invoice. An arrow from an activity to an object node shows creation; an arrow from an object node into the next activity shows that activity needs that object as input. This piece is optional while you are still identifying objects, but it anticipates the later object-identification phase and shows data flow alongside control flow. In more advanced notation the UML 2 object node may show a «datastore» stereotype for persistent storage.
• Subactivity state / bigger states (hierarchical decomposition): when an activity itself becomes large, you may show its internal steps as sub-activities inside a larger rounded rectangle, or break the complex diagram into a separate, smaller activity diagram that details that one task. The rake symbol (a small fork-like icon in the corner of an activity) indicates "this activity is expanded in a child diagram." Complex diagrams should be split into a parent plus children (level 0, level 1, level 2) instead of letting one page become crowded — a guideline repeated with SSD simplicity and later with domain model decomposition.

Reading direction is left to right and top to bottom, consistent with flowchart habit. State-chart notation is the source of many of these symbols. In activity-diagram terms, states are treated as activities and transitions are triggered by activity completion rather than by external events.

Visual intuition: imagine a river with a single source (filled start circle), widening into activity pools (rounded rectangles), then splitting at a diamond weir (decision) whose sluice gates are labeled with guards — water can go only through the open gate — then either reuniting at a second diamond pool (merge) where either stream suffices to fill the onward channel, or truly splitting into parallel canals at a thick dam (fork) where water goes both ways at once and only reunites at a thick collector dam (join) that waits for water from every canal before releasing onward. Object nodes are the barges on the water — created at one pool, carried downstream, consumed at the next. One sentence takeaway: diamonds choose one history (OR), bars run many histories at once (AND).

7.4.3 Decisions, Merges, Forks, Joins and Concurrency

Every activity diagram can show three patterns of control: sequential flow, branched flow, and concurrent flow.

Sequential flow: one activity completes and the next begins. This is the default arrow chain. It models "do A, then do B" where completion of A triggers B.

Branched flow: at a decision diamond the flow examines guard conditions and takes one path. The decision node splits; the merge node reunites. The shape read is decision (split) then merge (meet again).

• Example given for iteration: writing a chapter is described as an iterative loop. The author writes a draft, evaluates \[review\ satisfactory\]. If not satisfactory, the loop revises the draft again. If satisfactory, the flow exits the loop. The text words this as "if this condition is not satisfied, if you are not satisfied, you will keep on revising this particular thing" and only then proceed. The guard controls whether the loop repeats — a loop is just a decision-plus-merge cycling back.
• Payroll illustration: hours worked is checked at a decision node. Guard \[hours \le 40\] leads to Do Normal Payroll. Guard \[hours > 40\] leads to Do Overtime Payroll. Both paths later merge. Because guards are mutually exclusive and complete, exactly one of the two payroll actions runs for a given employee; the merge then carries the chosen history to End or to the next step. Writing hours with symbols: guard \[hours \le 40\] and guard \[hours > 40\], where $hours$ is the number of hours logged, $hours\in {\mathbb{R}}_{\ge 0}$. Precision is numeric at that check — a student who writes \[hours = 40\] as a case loses both mutual exclusion and completeness.
• Campaign addition guards: \[campaign\ to\ add\] versus \[no\ campaign\ to\ add\] illustrate the same pattern in a requirements setting — a business choice with no arithmetic, still Boolean and still needs mutual exclusion.

Concurrent flow: when tasks can run in parallel, you show that with fork and join.

• Fork: a thick horizontal or vertical bar (spoken of as a double bar) where one flow divides into two or more flows that proceed at the same time. It spreads control into parallel tracks. Semantically it replicates the flow token onto every outgoing edge.
• Join: a matching thick bar where parallel flows synchronize and merge back into one flow before the next activity continues. Conceptually no output token emerges until every incoming token has arrived. A join is not a merge — merge fires on any one arrival, join waits for all.

Think of fork as splitting the file into two copies processed by different desks simultaneously, and join as collecting both processed copies before the next step proceeds. That parallel structure is what makes activity diagrams richer than simple flowcharts and is the idea loosely grounded in Petri-net token flow.

You also show repetition where needed — some activities repeat or loop back, sometimes with a merge feeding back to an earlier decision. The lecture stresses control flow, data flow, and guard-controlled branching together rather than picking only one; a mature diagram shows all three where each adds clarity.

Exam note: Being able to name each node type — decision versus merge, fork versus join — and point to which bar is which is part of diagram literacy checks. Knowing that fork splits into parallel and join brings parallel back together is expected; markers often ask "which thick bar is the fork?" and check that your join has one outgoing edge, not two.

7.4.4 Swimlanes and Object Flows

When different people, organizations, or departments carry out different activities within one business process, you make that responsibility visible with swimlanes (also called partitions).

Visual idea: like lanes in a swimming pool. Each lane is a vertical (or for business processes, often horizontal) column labeled with who does the work — for example Campaign Manager, Accountant, Client, or Accounts Department, Admission Department, Welfare Division. Every activity is placed inside the lane of the party responsible for it. Transitions may stay inside one lane when one party does several steps in a row, or they may cross a lane border when the baton passes to another party. Swimlanes add "who" without changing the flow logic — the underlying edges, guards, forks, and object nodes remain the same.

• Campaign example with lanes: the Campaign Manager records campaign data; when done, the Accountant generates the invoice; the Client makes the payment; finally the Campaign Manager records the client payment. Placing those four activities in three lanes (Campaign Manager | Accountant | Client) makes the handoff visible without extra text — a crossing arrow tells you a different role now acts. If you removed lanes, the order would look identical; you would just lose responsibility assignment.
• Practice guidance: create lanes whenever a business process touches several places or several roles. If the process stays with one actor, you can skip lanes and keep the diagram flat (no need to add a single lane that contains everything). There is no mandatory rule; use lanes where responsibility handoff adds clarity, omit them where they would clutter. Textbooks suggest fewer than five lanes before splitting into sub-diagrams.

Object flows connect to swimlanes naturally. When an activity creates an object — such as a new client record or a new campaign record as a rectangle node — that object node sits after the creation activity and before the consuming activity. A simple version says: after Add New Client, a new Client object is created; after Add New Campaign, a new Campaign object is created. Shown with lanes, the object may sit in the creator's lane and then be needed in the next lane's activity, emphasizing cross-lane information transfer. Syntax options include a rectangle on the arrow, or an explicit pin (small square on the activity border) labeled with the object type — an input pin on the left or top of the activity, an output pin on the right or bottom, named with the parameter. For exam level, a plain rectangle with new Client : Client on the transition suffices; pins are bonus literacy.

The notes emphasize that showing objects and object flows at this stage is optional. Full object identification comes next. For now the point is to demonstrate that activity diagrams can carry data together with control, and that both can be made precise. A mature activity diagram is judged on whether it shows both when the case hinges on a document: for example, the Invoice must exist before Make Payment can consume it, and that dependency is visible as an object node between them.

7.4.5 Worked Examples — Book Chapter, Washing Machine, and Campaign Management

#### Worked example 1 — Writing a particular chapter of a book (instructional flowchart-like activity diagram)

Setup: Goal is to produce a complete chapter. Steps are tasks within that business process, not software internals — the domain is deliberately non-software to show notation generality.

#### Worked example 2 — Dry clothes with a washing machine (appliance business process)

Setup: Business process name is "Dry Clothes." Activities are appliance tasks, but the focus is still on flow, not on internal mechanics.

#### Worked example 3 — Stock processing and campaign management (consolidated swimlane + object flow view)

Setup: Comprehensive view of the campaign business process, combining sequencing, branching, parallel possibility, lanes, and objects. This diagram reads like a high-level business process model that could be mapped to data-flow alternatives, and it directly prepares object identification (what objects were created and where they are needed).

All three patterns are called out as concrete building blocks: sequential chain, conditional decision/merge with bracketed guards, and concurrent fork/join with synchronization. Together they let the activity diagram serve as a modern process model for analysis and also as algorithm logic for later design, where an activity might represent a loop body in code.

Real-world view: This pattern is how organizations document real workflows before building software — banking funds transfer from Operations to Risk to Finance, insurance claim assessment across branches, admission office file movement from desk to desk — so the eventual system mirrors an efficient business order rather than imposing an arbitrary software order. The most common failure is drawing a beautiful sequence that no business person recognizes; the fix is to validate the activity flow on the wall with the people who actually carry the files.

7.4.6 Student Questions and Answers

Real-world and domain connection: Activity modeling is how express-parcel shippers (Larman's client case), banks, insurers, and admission offices validate processes before automating them. The parcel shipper pins one wall-sized activity diagram with partitions for Customer, Driver, Sorting Hub, and Finance and walks it with operators — missing guards and orphaned branches become visible in a way paragraphs hide. That is the same habit behind the proficiency note in 7.4: transitions are triggered by completion, data travels with control, and the diagram is the contract for what "done" means at each desk.

7.5 Domain Model — Conceptual Class Diagram as the Bridge Out of Analysis

The domain model is where analysis stops describing stories and starts naming the enduring kinds of things that make every story possible. If SSDs gave you the verbs (system events) and activity diagrams gave you the flows, the domain model gives you the nouns — with attributes and associations precise enough that a designer can later turn them into software classes without inventing the vocabulary.

7.5.1 Conceptual Class Diagram as an Analysis-Class Picture

A domain model is another name for a conceptual class diagram. It is the class diagram of analysis. It is not the design class diagram that later shows software classes with full method signatures, visibility, attribute types, and framework types. It shows real-world objects — often called conceptual classes — as they exist in the problem domain in the analyst's understanding, before any software decision is made.

For example, the same retail and campaign worlds that gave you Client, Campaign, Invoice, and Sale as use-case and activity elements now appear as classes with attributes and associations that a business expert would recognize as ordinary business language: a Campaign has a title and budget; a Client has name and contact; an Invoice has invoiceDate and amount. You are still in the analysis space. The objects here come from the problem side, not from a design invention. You will use this analysis information later in the design space by refining these conceptual classes into software classes — but the conceptual names already inspire the software names, which lowers the representational gap between how stakeholders think and how code is written.

Formally this is a static diagram. At any moment in time it shows the kinds of things and their relations — a snapshot of structure — not the order in which messages are sent. It has no lifelines, no time axis, no activation bars. That is why it pairs well with the dynamic diagrams already covered: the SSD tells you how the system is stimulated over time (which events, which operations), activity diagrams tell you how business tasks flow (which activity triggers which), and the domain model tells you what the enduring kinds of things are that underlie both — the things that must be remembered across events.

A concrete placement: the lecture positions the domain model as the point where requirement analysis ends and object orientation begins. Up to this point you were modeling requirements (goals, events, flows). From the next class forward you will model objects (responsibilities, collaborations, visibility). The domain model is the bridge: its classes are still conceptual (not software), but they are named and related using UML class-diagram notation (boxes and lines) that designers will keep.

Visual intuition: picture a dictionary where each headword is a class box, each definition includes attributes (what you remember about one entry) and see-also links as associations (how entries relate). The domain model is that dictionary drawn as a graph: boxes are words, lines are meaningful sentences ("a Sale is Paid-by one Payment," "a Campaign is Managed-for one Client"), and multiplicities are the grammar (one versus many). You can read it left-to-right or top-to-bottom by following the reading-direction arrow on each line, but no single line has temporal priority — it is a map, not a timeline.

Practical cues the lecture pairs with this view: the textbook advice is to sketch a domain model on a whiteboard in a couple of hours early in each iteration, bounded by the use case scenarios under development (for this lecture, the cash-only Process Sale and the campaign case), rather than attempting a waterfall "model everything perfectly." An agile habit is to photograph the whiteboard and move on — the model has served its purpose of aligning vocabulary.

Real-world and domain connection: Teams that separate analysis artifacts (use cases, SSDs, activity flows, conceptual domain model) from design artifacts (design class diagrams, detailed sequence diagrams, deployment diagrams) keep the business conversation distinct from the technical conversation. That separation helps stakeholders approve what is wanted before debating how it is built — for example, a retail chain can approve "a Sale contains SalesLineItems each recording a sale of an Item described by a ProductDescription" without yet approving whether ProductDescription is cached in memory. That approval then becomes the shared vocabulary that designers reuse verbatim as software class names (ProductDescription, Sale) to lower the gap between mental model and code.

7.5.2 Exam Scope and Transition to Object Orientation

Exam note: The block ending at the domain model marks the limit of analysis-phase material for this segment. The lecturer states explicitly that the syllabus up to the domain model is inclusive for the current analysis portion — every topic from static/dynamic views through use cases, UML views, SSDs, activity diagrams, and the conceptual domain model is fair game. System contracts, while related to SSD system operations (pre/postconditions on domain objects), are noted as a possible addition when SSDs are discussed in fuller detail, but they are not the focus of this diagram-building assessment and may be introduced time-permitting alongside SSDs.

Study guidance paired with that scope:

• Read Larman Chapter 6 third edition — the prescribed chapter for use case writing and use case diagram conventions alongside SSD material. The textbook presents the SSD as sequence-diagram notation at system level, consistent with the lecture; reading it cleans up "LAMAT versus UML" confusion.
• Review the notations and the dual importance of activity diagrams as business process models (analysis) and as design flow models (later use for algorithms). Be able to draw both uses — a business case with swimlanes and a method's branching logic — so you recognize the same symbols in different contexts.
• Treat UML as notation you can extend rather than as a fixed process to memorize. The value of UML in the Unified Process is that it is flexible and can host any useful practice that adds value, not that it prescribes a single workflow.
• Practical readiness means being able to draw the diagram a prompt asks for from a one-page case text, not just naming parts. For a prompt like the campaign management case, you should be able to produce a medium-granularity use case model, one SSD for the main success scenario, one activity diagram showing decision, merge, fork, join, guards, and optionally swimlanes and object nodes, and a small domain model.

Future direction signaled: the next class will cover object orientation in depth and the method for identifying objects — turning the conceptual classes of the domain model into a design-ready object view. System contracts, time permitting, are noted as a possible addition when SSDs are discussed in fuller detail. Activity diagram sub-topics such as sub-activities (rake), object flows with pins and rationales, and lane details will reappear once object identification makes them more concrete.

Real-world recap: In product teams, the domain model is often the first wall artifact that survives from story to sprint: business analysts, domain experts, and engineers all point at the same boxes and argue about one line ("should a Campaign be described by a CampaignDescription?") rather than about code. That argument, settled early, prevents a later persistence or pricing bug where a price is duplicated on every Item instance instead of living once on its description.

Exam Guidance Summary

The analysis phase through the domain model is the assessed block. This summary consolidates what to revise, what textbook page to open, what a task prompt looks like, and which visual details examiners check for marks.

• Scope for this block: analysis phase through system sequence diagrams, activity diagrams, and domain models inclusive. The domain model as a conceptual class diagram is the endpoint of analysis before object-oriented design begins. System contracts may be introduced alongside SSDs when time permits as pre/postconditions on domain objects, but contracts are not the focus of this diagram-building assessment — focus revision time on creating SSDs and activity diagrams, not on contract prose.
• Textbook alignment: Read Larman Chapter 6 third edition for use-case writing, use-case diagram reading, and SSD handling where the SSD is presented using sequence-diagram notation at system level. Larman Chapter 6 is the single prescribed source bridging lecture and textbook; later chapters on SSDs (Chapter 10) and activity diagrams (Chapter 28) and domain models (Chapter 9) deepen the same examples with the NextGen POS case.
• Format of assessment tasks: Expect to be given a one-page case study — for example a campaign management organization serving clients with campaigns, staff allocation, invoice, and payment, or a retail point-of-sale Process Sale, or a chapter-writing or washing-machine workflow. You will need to name actors and use cases (at medium granularity), describe the main success scenario in text, and draw the requested diagrams: a use case model (ellipses plus actors with a comment note where needed), one or more SSDs for the main success scenario with correct :System notation, and one or more activity diagrams with decisions, merges, forks, joins, guards in brackets, and optionally swimlanes and object nodes where responsibility or data matters.
• Medium granularity is the norm for classroom exercises. Avoid scattering the model into many tiny single-step ellipses (one ellipse per button press) and also avoid packing everything into one overly generic "Manage System" use case. Merging fine-grained Add or Delete variants into one manage-style use case (for example Manage Client Details) is explicitly accepted as a way to stay at the intended level. In industry the granularity naturally varies with scope and audience; in the course a balanced middle is expected and more than one grouping can earn full marks if it is consistent and justified.
• Visual literacy checks examiners use as quick filters: start node as filled circle at the top, end as bullseye, activity as rounded rectangle, decision and merge as diamonds with bracketed mutually exclusive and complete guards such as \[hours \le 40\] and \[hours > 40\], fork and join as thick bars for parallel split and synchronization (one entry to a fork, one exit from a join, entered and exited from the same side), swimlanes as labeled partitions for responsibility by actor or department (few enough to stay readable), object nodes as rectangles for created or used documents or entities (for example new Client : Client), comments as folded-corner rectangles attached by a dashed line, and system object notation :System (colon = instance) versus class notation System (no colon = type).
• Simplicity and splitting rule: If any diagram becomes complex, break it into multiple simpler diagrams rather than crowding one page — one SSD per scenario, one activity diagram per coherent process level with sub-diagrams for complex steps marked by the rake symbol. A picture should be readable left to right and top to bottom at a glance. Accompany an SSD with its scenario text so both forms reinforce each other and inconsistency becomes visible.
• Time order carries meaning: In SSDs the vertical order is the time order of events — reordering arrows changes the story. In activity diagrams transitions are triggered by completion of the source activity, not by an external event; the arrow means "when this task finishes, that one starts."
• Practice contract: Solve at least five varied case studies end to end and draw each diagram family for each study using a tool at hand — ArgoUML, StarUML, or similar. Notation can be memorized quickly (hours), but modeling thought becomes fluent only through repeated application across domains (weeks). Timed practice on a fresh one-page case is the single best predictor of creation-task marks.

Key Industry Applications

These applications show where the analysis views taught in this lecture actually earn their keep outside the classroom — the same SSD, activity, and domain model habits appear wherever a business process must be understood before it is automated.

• Point-of-sale retail systems — modeling cashier–system interactions with SSD events makeNewSale, enterItem(itemID, quantity), endSale, makePayment(amount) to define system operations for a black-box store terminal before designing internal collaborations among Register, Sale, ProductCatalog, and Payment. The SSD operation list directly seeds operation contracts and the design sequence diagrams.

• Campaign management organizations — modeling the end-to-end flow from Add Client and Add Campaign through Assign Staff to Campaign, Generate Invoice, and Record Client Payment across Campaign Manager, Accountant, and Client swimlanes. Swimlanes make responsibility handoff visible, guard conditions like \[campaign\ to\ add\] keep the business rule explicit, and object nodes (new Client : Client, Invoice) make the data that must travel between departments checkable before automation.

• Business process redesign in banking, insurance, and admission offices — documenting file movement and control flow from department to department with decisions, merges, forks, joins, and object flows before a workflow system is built. Teams pin a wall-sized activity diagram with partitions for each office and walk it with the clerks who actually carry the files; missing guards and orphaned parallel branches become visible in a way paragraphs hide, and the fork → parallel work → join pattern shows where staffing can speed the process.

• Appliance and operational workflows — washing machine dry cycle and similar task-choice scenarios modeled as activity flows to distinguish conditional work (\[dryer\ available\] versus \[line\ dry\ needed\]) before merging to a single End. The same branching pattern appears in logistics, cooking, and checkout — any process where one history is chosen among alternatives.

• Publishing and content workflows — book chapter production with draft, revision loop until \[satisfactory\], addition of exercises and diagrams as sequential and iterative activities. This non-software domain teaches the notation without letting students hide behind code, and its loop pattern reappears in software sprints and review cycles.

• Database design practice — industry shift from entity-relationship (ER) diagrams to UML class modeling for persistence structure, and use of UML across component and deployment views for product teams building at scale. The same class-box notation that draws Client and Campaign in the domain model later draws tables and services, keeping the vocabulary aligned from analysis to deployment.

• Tooling chain in practice — Visual Paradigm (VGO), ArgoUML, StarUML, and IBM Rational Rose as selection options for creating and maintaining UML diagrams in academic and commercial settings, supporting the "picture is worth a thousand words" role of visual models in reviews. The tool choice matters less than the habit: teams that keep a shared, versioned set of use case, SSD, activity, and domain views can hold a design review where each stakeholder validates their own window — domain experts the flows, engineers the classes, infrastructure the deployment — using consistent names.

The common thread: analysis artifacts are cheapest to change when they are pictures on a wall, and most expensive when they become code. Investing in one SSD per scenario and one clear activity diagram per process — plus a domain model that names the nouns once — prevents the class of errors where the system faithfully automates the wrong order.