I am trying to draw a use case diagram for navigation. However, I am not sure if it is correct since the 'call out address' base use case is being used as included use case.
Any comments on the above diagram please?
This is not a use case diagram. Your bubbles contain Actions being part if some Activity carried out by a use case. A use case shows added value an actors gets from the system under considertion. Please start at square one!
I recommend reading Bittner/Spence about use case modelling. The best read you can get on that topic.
I have seen many use case diagrams where a use case can be included to only 1 other use case, is this right or wrong? I have the understanding that in order for a use case to be included, it must be included to minimum 2 other use cases to be considered.
If this is true(minimum 2 use case to be considered an include), if its just linked to 1 other use case, do i just use a normal association? thank you
This is a recurring question and often interpreted the wrong way. Include does not mean "call" in a functional analysis sense. It means "this is a use case which can optionally be included". E.g. if you have a tool box you sell with different tool sets (different licensing for software). When you model use cases you synthesize single actions in a form so they build a set that returns some value to the actor. You will not divide pieces of value into smaller ones.
Use cases are about synthesis, not about analysis. When your use case diagrams start resembling spider webs then your design is broken.
I have this use case diagram. As you can see, "Rate Service Provider" is the general use case of "Rate on Computer" and "Rate Online" use cases. Since those two use cases are specific, I know they have separate use case narratives. Now my question is that do you need to create a use case narrative for a general use case? The general use case has almost the same behavior as the two specific use cases. Thank you. :)
Yes, base on my previous experienced. The rate computer and rate online will be the alternative sequence in your use case narrative.
You will need a narrative that describes the behavior common to both sub-cases for Rate Service Provider. In that narrative, mention the inherited cases, and provide a separate narrative for each of them. Much as you would do with a narrative for a use case that has included use cases.
Is there any tool which can automatically extract all possible scenarios from an use case UML diagram?
No I don't think so. The problem is that the Use Case diagram is almost entirely content free in UML. It's really just a guide to how to read the use case body specifications and documents their relationships. A test case generator would need to read the use case bodies, however UML doesn't define a standard form or semantics for them, so there's nothing for a test case generator to work with.
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!
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.
Include and Extend relationships on a use case diagram http://i.msdn.microsoft.com/Dd409427.UML_UCOvStructure(en-us,VS.100).png
UML Use Case Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409427%28VS.100%29.aspx
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.
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".
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.