In a UML use-case diagram, how do include and extend differ, and which way does each arrow point?
answer
- Two dashed arrows, one keyword each
- One always runs, one only sometimes
- Direction is what gets marked
- Point the arrow at the unaware use case
- Condition and extension point live on extend
basics
~20 sInclude means the base use case always performs the included behaviour, and the arrow points from base to included. Extend means optional behaviour attaches at a named extension point under a condition, with the arrow pointing from the extending use case to the base.
solid answer
~50 sBoth are dashed dependency arrows with an open head and a keyword, which is why they get confused; the difference is obligation and direction. **Include** is mandatory reuse: the base use case always performs the included behaviour, and the arrow runs **from the base to the included** use case. **Extend** is conditional: an optional or exceptional behaviour inserts itself into the base at a named **extension point**, guarded by a condition written on the relationship, and the arrow runs **from the extending use case back to the base**. The mnemonic that survives an interview is that the arrowhead always points at the use case that is *unaware* of the relationship — an included use case does not know it is included, and a base does not know it is extended. The practical test for extend: delete the extension and the base must still make complete sense.
code
pseudocode · 15 linesinclude - mandatory, base depends on the included behaviour
Run monthly payroll ....<<include>>....> Verify tax rates
Run an off-cycle payment ....<<include>>....> Verify tax rates
extend - conditional, the extension depends on the base
Attach a late-timesheet note ....<<extend>>....> Submit a timesheet
condition: {timesheet arrived after the cut-off}
extension point: after entry validation
mnemonic: the arrowhead points at the use case that does
NOT know about the relationshipgo deeper
Recall that include is always performed and extend only sometimes, and that both are dashed arrows with a keyword. Being able to state which one is conditional already puts you ahead of most candidates at this level.
Explain the mechanics an interviewer is actually testing: the direction of each arrow and why it points that way, the named extension point, and the condition written on the extend relationship. Expect to be shown a diagram with one arrow reversed and asked to fix it.
Demonstrate restraint. Say when neither relationship is right — a single shared step belongs in the flow text — and explain how a diagram overrun with include arrows stops being a scope statement. Show you know an include silently enlarges the base use case's definition of complete.
Own the standard: how much relationship notation a team is allowed to use before the diagram costs more to maintain than it settles, and when a written use-case flow serves the argument better than more arrows. Be able to defend a deliberately sparse convention.
## The two relationships side by side Both relationships are **dependencies**: a dashed line, an open arrowhead, and a keyword in guillemets. That shared appearance is exactly why candidates mix them up, because the only visible differences are the word and the direction of the arrow. | | include | extend | |---|---|---| | Meaning | The base use case always performs the included behaviour | Optional behaviour is inserted into the base under a condition | | Arrow points | From the **base** to the **included** use case | From the **extending** use case to the **base** | | Obligation | Mandatory on every run | Conditional, on some runs only | | Who knows whom | The base knows what it includes; the included does not know its callers | The extension knows its base; the base does not know it is extended | | Condition | None — there is nothing to decide | Written on the relationship, at a named **extension point** in the base | | Typical use | Behaviour shared by several base use cases | An optional add-on or an exceptional variation added later | ## Include: mandatory, factored-out behaviour Include means the base use case's flow *always* runs the included behaviour. It exists for two honest reasons: several base use cases share a chunk of behaviour and you would rather write it once, or one chunk is substantial enough that naming it makes the base readable. On a payroll platform, "Run monthly payroll" and "Run an off-cycle payment" may both include "Verify tax rates", and that shared inclusion is the whole justification for drawing it. Two properties matter. First, the included use case is **complete in its own right** — it is a use case, not a fragment. Second, it is **unaware of who includes it**, which is what makes it reusable and what fixes the arrow direction: the base depends on it, not the other way round. The abuse to avoid is treating include as a function call. Once you start factoring out every shared step, the diagram stops being a scope statement and becomes a call graph, and the boundary argument it exists to settle disappears underneath the wiring. ## Extend: conditional, and the base does not know Extend goes the other way, and that surprises people because in reading order the base feels like it comes first. The dependency runs from the extension to the base: the extending use case cannot exist without something to attach to, while the base is complete on its own. Two pieces of the notation carry the meaning: - The **extension point** — a named location declared inside the base use case, so the extension attaches at a defined place in the flow rather than vaguely "somewhere". - The **condition** — written on the extend relationship in braces, for example a note that is added only when a timesheet arrived after the cut-off. It is the extension's condition, not the base's. The clean test: **delete the extending use case and the base must still make complete sense.** If deleting it leaves a hole, the behaviour was mandatory and you wanted include, or it was never a separate use case at all. ## The mnemonic that survives the interview **The arrowhead always points at the use case that does not know about the relationship.** The included use case has no idea it is included. The base has no idea it is extended. Point the arrow at the ignorant one and you cannot get it backwards under pressure. A second check is to read the arrow aloud as "depends on". "Run monthly payroll depends on Verify tax rates" is true, so the include arrow runs that way. "Verify tax rates depends on Run monthly payroll" is false. For extend, "Attach a late-timesheet note depends on Submit a timesheet" is true, and the reverse is not. ## When the honest answer is neither 1. If the shared behaviour is a **single step**, write it into the base use case's flow text. A step is not a use case, and a diagram of includes is a decomposition, not a scope statement. 2. If the "optional" behaviour is really **a different goal with its own primary actor**, give it its own use case and an association, not an extend arrow. 3. If two variants differ across **the whole flow** rather than at one inserted point, generalization between use cases is the better fit. 4. If the extension exists only because a founder asked for something new this week, it is a request being parked on a diagram. Keep the base honest and track the request where work is tracked. ## What interviewers listen for - The direction of each arrow, stated confidently and justified rather than guessed. - Mandatory versus conditional, and where the condition and the extension point live. - Restraint: the ability to say that most shared behaviour belongs in the flow text. - The consequence: an include changes what "complete" means for the base use case, and an extend does not — which is why one of them can quietly grow a base use case's scope and the other cannot.
- How would you show that the extra behaviour attaches in the middle of the base flow, not at the end?Declare a named extension point inside the base use case at that place in its flow, and name that extension point on the extend relationship. Without it the diagram only says the behaviour attaches somewhere, which is not enough for anyone writing or testing the flow.
- Can an included use case be run on its own?Structurally yes — it is a complete use case, not a fragment. In practice it usually satisfies no actor's goal by itself, which is why it has no primary actor. If it does have one, it deserves its own association and should stand as a first-class use case rather than only as an inclusion.
- What is the quickest test that you have chosen extend rather than include correctly?Delete the extending use case and read the base. If the base still describes a complete, sensible goal, extend was right. If the base now has a hole where the behaviour used to be, the behaviour was mandatory and the relationship should have been include pointing the other way.
Include is an ingredient the recipe always uses; extend is a garnish that adds itself when a condition holds. The recipe knows its ingredients, but it has never heard of the garnish.
saying these in an interview costs you the question
- Draws the extend arrow from the base to the optional behaviour
- Says include is optional and extend is mandatory
- Uses include for every shared step, producing a call graph
- Cannot say where the extend condition and extension point live
- Thinks an include arrow means the base calls a function
- Claims both arrows always point at the base use case