Question about UML extend/include from Book Example

Question

Hi, Reading the book about UML, I do not understand following:

                                      --------include---> Add new manufacturer
  Servoce Assistant---Add new product
                                     <--------extend----Add new product type    

I just do not understand it. If there is yet uknown manufacturer, it uses included case Add manufacturer. But if it is yet uknown type, there is extend? That does not make any sense to me. It would make sense if only Add manufacturer could be called from different places but Add new product type exists only for that case. Is it correct? Thank you!

Answer 1

First you need to give people some context here. You are using Use Case diagrams. Second, I usually stay away from extend with UML; but I'll give it a go. "Include" is used to modularize Use Cases. For example, "User Logs In" is used a lot and is much easier to "Include" than write out the steps in every Use Case it is in. "Extend" is trying to use generalization/inheritance with Use Cases, but I don't think it's very, well, usable. Here's an example, "Add Tiger" extends "Add Animal". Again, I would stay way from "Extend".

Answer 2

Tomas, do you mean extension points as opposed to extending a class ?

Taking LWoodyiii's example with Login, you would have the use scenario where everything works perfect as a starting point, and then you would add extensions to the use case with the places where the scenario could go wrong ?

There are lots of examples out there, just google for uml use case extension.

Answer 3

If there is yet uknown manufacturer, it uses included case Add manufacturer. But if it is yet uknown type, there is extend? That does not make any sense to me.

I'm not entirely sure it makes sense to me either.

The UML2 spec says of include (section 16.3.5):

An include relationship between two use cases means that the behavior defined in the including use case is included in the behavior of the base use case. The include relationship is intended to be used when there are common parts of the behavior of two or more use cases. This common part is then extracted to a separate use case, to be included by all the base use cases having this part in common. Since the primary use of the include relationship is for reuse of common parts, what is left in a base use case is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base use case depends on the addition but not vice versa.

Execution of the included use case is analogous to a subroutine call. All of the behavior of the included use case is executed at a single location in the included use case before execution of the including use case is resumed.

...

Note that the included use case is not optional, and is always required for the including use case to execute correctly.

And of extends (section 16.3.3):

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.

...

If the condition of the extension is true at the time the first extension point is reached during the execution of the extended use case, then all of the appropriate behavior fragments of the extending use case will also be executed. If the condition is false, the extension does not occur.

Use cases are rather procedural things to find in an OOD language. Includes are sub-routine calls. Extends are optional procedures, either like conditional logic or the template method pattern, where the main method may or may not call to a more specific implementation.

As a use case is a classifier, you can use the same Generalisation relationship between use cases as you would between classes to signify generalisation. Extension and inclusion denote optional and required sub-behaviours.

It would make sense if only Add manufacturer could be called from different places but Add new product type exists only for that case. Is it correct? Thank you!

It says that whenever you add a product, you always add a new manufacturer, and sometimes you might add a new product category. It doesn't say whether or not any of the use cases are called from elsewhere, though normally you would only split off included use cases if they were. Given real-world manufacturers make different products, it's probably a badly formed example.

Answer 4

The following explanations might help clarify the "extend" and "include" relationships on use case diagrams:

Include: An including use case calls or invokes the included one. Inclusion is used to show how a use case breaks into smaller steps. The included use case is at the arrowhead end.

Extend: An extending use case adds goals and steps to the extended use case. The extensions operate only under certain conditions. The extended use case is at the arrowhead end.

UML Use Case Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409427%28VS.100%29.aspx