UML - Difference between Includes, Uses and Extends

The difference between Includes and Extends (to me) at the base level is this:

Saying “A includes B” implies that A is a higher level goal than B, A names B as a step, and B does not name A (ordinary subroutine call semantics).

Saying “B extends A” implies that B names A, naming a place within A which, when the named condition occurs, jumps to B (”come from” instruction semantics). A does not name B. B can actually be any goal level, higher, same, or lower than A.

With that difference, I think all the rest of the includes/extends debate can be derived.

A “use case” is generic in the sense that data specifics are generalized (made into variables). It is a description of a set of possible executions. It could contain “if” statements, but usually we discourage that as a writing style convention.

A “scenario” is one particular execution of a use case (possibly, I suspect, crossing multiple use cases), with all data values specified. It necessarily has no “if” statements, since it is the execution of a single path.

A “course” is a particular chunk of descriptive text in the use case containing no if statements, but making data values generic. A scenario made formulaic, so there is no branching but many data values could be substituted. Thus there is the ‘main course’ and some number of ‘alternate courses’.

I assume, when you say “trying to understand includes and extends”, that you are talking about use case diagrams. You know people don’t get messed up in that stuff very much when using the textual forms. People do get messed up in that stuff when using the diagrams. Hence my assumption.

Why are you using the diagrams? What do you want out of your diagram(s)? When would you have “that which you need”?

“An extending or extension use case extends a base use case if the extending use case names the part of the base use case that it extends. The base use case does not name the lower-level use case. This is useful if you want to have any number of lower level use cases extending the higher level one, and don’t want the maintenance nightmare of updating the higher level use case each time a new lower level use case is added.

Behaviorally, the extending use case specifies some internal point in the course of the base use case, with a triggering condition. Behavior runs through the base use case until the condition occurs, at which moment the behavior continues in the extending use case. When the extending use case finishes, the behavior picks up in the base use case where it left off.

An extension use case is just the extension condition and handling pulled out and turned into a use case on its own. You may think of an extension use case as a scenario extension that outgrew the use case in which it was embedded and was given its own space.

The most appropriate use of extends is when there are many asynchronous services the user might request, which should not disturb the main flow of the main success scenario. This sort of situation is common with shrink-wrapped software such as a word processor (hence the figure, showing “Check spelling” as an extension of “Type a document”)”"

That strikes me as a second answer: for the reviews to understand all the ways of interacting with the system. I respectfully suggest that they will not understand “the ways that they plan to interact with the system” by looking at a pile of ellipses with arrows going in all different directions and little <<extends>> and <<include>> hanging off them. That they will much better understand after reading some sentences.

The point of my questioning is this. If you understand why you are using a particular part of the tool capabilities, what you get out of the exercise for all the time you put into it, then you can much better judge when to stop using the increasingly arcane bits of the tools.

You can shoehorn almost all of the textual characteristics of a use case into a diagram, using the more sophisticated (rarified?) parts of UML, such as dependency arrows and annotations. So “can” and “want to” are quickly separated.

What triggered this was the comment about making “Cancel transaction” an extending use case. But it’s only 1 sentence long! Yes you can, but what is the purpose of the diagram? To give an overview - but “Cancel transaction” doesn’t belong on an overview diagram!

It is a “clam”-level goal, the lowest-level goal level we have named, one that shouldn’t get written. We say “clam” to indicate that it is not at sea-level, it is not merely underwater, it is sitting on the bottom.

If you find yourself drawing an ellipse and arrow for a clam-level goal, stop and ask again - what is the purpose of the diagram?

As soon as I partition behavior into manageable chunks (the different use cases) I have to worry about how they relate to each other. Include and Extend relationships exist whether I am drawing a diagram or using text alone. Btw, I am not advocating giving each alternate course its own ellipse - just to make that clear.