Kimbo gave a good example!
One clarification, an extension point usually references another use case rather than another flow.
The way I like to think about the difference is that the alternate flow is another way to get to an outcome for a given use case as opposed to an extension which is an optional set of steps and therefore can be easily specified/described as a separate use case.
There are two ways of answering your question:
- Practical - Understand your need and solve it?
- Exact - What does the UML specification say?
Practical
From a practical standpoint - I already provided you with my view in my previous post. What I would add is to think about when you might want to break a use cases into multiple use cases. I usually separate functionality from one use case into another use case for 3 reasons:
- Deal with complexity - when a use case specification becomes very large (with numerous alternate flows and exception flows) it is a sign to consider breaking the use case down further.
- Deal with optional behavior - when you need to add to a use case optional behavior which does not alter the outcome of the main use case, it's another case to consider expressing that logic as another use case. Example: Main use case would be the place purchase order allowing the actor to buy a set of items. An optional set of steps during the process of the main use case or at the end of it is to request a new product catalog. The process for requesting a new product catalog can be expressed as another use case since regardless of its outcome it has not impact on the main "purchase order" use case.
- Deal with common behavior - think of this as reuse at us case level. If you have two processes/use cases that share something in common - the flow/steps/process in common is a candidate for being described in a separate use case and simply referenced from the other two use cases.
Exact
If you really want to know exactly how these constructs are supposed to be used then your definitive source is the UML specification published by OMG (free to download).
The actual, formal, specification is a bit hard to navigate if you're not familiar with it so here are some excerpts.
The UML specification defines 2 main relationships between two use cases: extend and include:
Include: "An include relationship defines that a use case contains the behavior defined in another use case."
Extend: "A relationship from an extending use case to an extended use case that specifies how and when the behavior defined in the extending use case can be inserted into the behavior defined in the extended use case."
As you can see, the definitions are not very practical - aka you need to re-read the entire section on use cases a number of times.
A little bit more from the specification (see Chapter 16 of the UML Superstructure document):
Extend
"This relationship specifies that the behavior of a use case may be extended by the behavior of another (usually supplementary) use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case and is meaningful independently of the extending use case. On the other hand, the extending use case typically defines behavior that may not necessarily be meaningful by itself. Instead, the extending use case defines a set of modular behavior increments that augment an execution of the extended use case under specific conditions.
Note that the same extending use case can extend more than one use case. Furthermore, an extending use case may itself be extended."
Include:
"Include is a DirectedRelationship between two use cases, implying that the behavior of the included use case is inserted into the behavior of the including use case. It is also a kind of NamedElement so that it can have a name in the context of its owning use case. The including use case may only depend on the result (value) of the included use case. This value is obtained as a result of the execution of the included use case.
Note that the included use case is not optional, and is always required for the including use case to execute correctly."
Again, for all practical purposes, an extend is functionality which is generally NOT required, but the include is generally functionality which is required.
IMPORTANT NOTE: The UML Specification does NOT contain any guidance on how to describe the internals of a use case and therefore it does not include any topics such as: main flow, alternate flow, exception flow. These constructs are found more as an informal agreement of what these terms mean among the practitioners that use use cases.
Hope this post did not add to the confusion.
Adrian