I'm wandering whether the following use case diagram is correct because I'm not sure if such notations are possible: something is going from extending use case, and this notation of this transition. I haven't found any information regarding such cases and would be glad if someone could help me.
To express that a (partial or secondary) use case is used only under certain cercumstances and you want to express them explicitly, you can use extension points. An extension points defines explicitly the conditions when the Main use case is extended. In reality, this Feature of uml is Quitte rarely used. Because it adds a high degree of concreteness to the abstrakt Level of use cases.
In your example you are using the wrong kind of relation. You are showing an extend relation, which expressed that a Stereotype can be applied to a meta type. Instead you should use an extends relation, which has a dashed line and on open arrow head.
Related
I have been trying to understand it but I couldn't. Can someone explain this shortly? Is there some problem with this UML diagram? If there is, where?
I thought that instead of extending arrows there might be a generalization for the pic, video, tag names, and feeling use cases. And I think that included arrows should have been dashed. Are these true? Thank you already.
You can not understand this since it is absolute nonsense. This is some semi-activity diagram. A use case is about actor goals, not how to do something. Please give the author of that a heavy kick in the rear. Or if you not that rude as myself (being a pacifist with empasis on fist - haha) just encourage them otherwise to start learning about use cases.
As always I recommend reading Bittner/Spence about use cases.
The following aspects of the diagram violate the UML specifications:
The boundary box shall represent a system (e.g. Facebook), not a function (Add Status).
Keywords include and extend shall be written in guillemets: «include», «extend».
The «include» arrows shall be dashed.
The «include» arrows shall have open arrow-heads.
To apply the use case technique in a project, the team shall agree on a specific methodology and/or philosophy. UML doesn't offer this, it is just a language (despite some definitions in the UML specification that point in a certain direction). Therefore, I will not give my opinion on whether this is a proper way of use case modeling.
With regard to generalization versus extension: both are possible in this case. If "Add Status" would mean: add pic or add video or etc., then a generalization would be more appropriate. The extension suggests that "Add Status" means: add pic and/or video and/or etc. In other words, each extending use case extends the original with additional capabilities.
Hi, I would like to have the receptionist and the manager to be able to view work type and rates and subsequently update it. However, tech personnel can only view but not update. Is the diagram valid?
I read that extended use-case are initiated by actors that initiated the base case. How should I differentiate that tech personnel can only initiate the base case and not the extended case? Should I not place the extension association? What about included use-case?
Sorry if this question has been asked before.
You should neither «include» nor «extend»
View work type and rates and Edit work type and rates are perfectly valid independent use cases.
In general it is a bad idea to chain use cases together just because you usually do one after the other.
You should not try to model the sequence of activities with use cases. Use your business process analysis for that.
You can use the post- and preconditions to constrain the execution of use case. In fact your Edit use case doesn't really require the View use case in particular to be executed does it?. It probably only needs a work type to be selected. So it can be executed right after any use case that has a postcondition stating that work type is selected.
Which use case does that is irrelevant to the Edit use case, as long as a work type is selected before the use case starts. There might be 10 different use cases that result in a work type being selected.
The «extend» I consider to be simply wrong. Extending use cases are usually incomplete use cases that insert their behavior into a complete use case are a particular extension point defined in the extended use case. The extended use case in does not have any knowledge about the extending use case and does not need or use the results of this behavior.
The few cases I which I found «extend» use cases to be applicable were things like monitoring use case. For example a use case that monitors the number of open tickets in the system and sends an alert to an admin in case a certain threshold is surpassed.
If you still insist on linking the use cases together, for example in case you really mean that you can only edit rates after executing the use case View work type and rates I would do it the other way around. Include the use case View work type and rates from the use case Edit work type and rates, probably as the first step.
Both solutions (separate use cases, or include from Edit to View) solve your issue regarding the rights of different users as it is now clear beyond any doubt who can do what.
I'd model it this way:
Manager and Receptionist have the same roles in this context which is why I used a generalization. Without knowing the domain this seems okay, but it's just a proposal.
The <<extend>> is constrained by {not allowed for actor Tech} which clearly excludes this actor from entering this (optional) use case.
There is no need to also associate Receptionist with Update... since it's an extension of View..., except you want to be able to Update without Viewing first.
N.B. about <<include>>/<<extend>>: They are not meant as chaining use cases. The UML spec states (pp. 638):
Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more UseCases.
and
The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common.
Now that <<include>> just looks like a bastard. A use case is about a unique added value. And this uniqueness can be questioned if there were behavioral recurrence in more than one use case. In any case these relations are often just taken as functional decomposition. And that would be plain wrong. From my POV the UML spec would be better without these relations.
In context of the above diagram it represent a pattern where you view something and only then can make it editable. It would well be perfect to have two individual bubbles without <<extend>> where you place a constraint in Update telling { can only be reached after View... }.
I would change extend by include. To update the work, you have to view it. It is mandatory to view it.
In your diagram, Manager and Receptionnist are equivalent, with this schema only, you can define one actor only. Or model that Manager inherits from Receptionnist.
And to avoid mistake, if you do that, you have to be sure that Receptionist and Manager can also activate the view use case without the update. Otherwise some associations have to be remove.
Let's assume that there is a UseCase called "Start Pattern Recognition". But when stating pattern recognition, it's mandatory to either to train a new model or import existing (pre trained) model. One of those option must be performed. I tried to represent that in UML as shown below (I used Includes instead of Extends since it's mandatory to perform either one of this UseCases). But I'm not sure whether it is correct to use "Extension Points" with Include UseCases. Is this correct or Is there any other way to do this?
It isn't correct; there is no analogous concept to extension points for includes in the UML spec. As xmojmr has very correctly stated, you really have your inclusion backwards.
This is easy to do, because it's easy to get caught up thinking about the order that use cases occur in over time. The use case diagram doesn't have anything to do with time; it just states what things a system does, who or what interacts with it and what uses what.
When you are ready to think about the flow of a use case, think about it in terms of an activity diagram. Also, look at the idea of a "use case narrative", which documents the behavior of the use case.
By the way, extension points in a use case diagram are optional.
How do I create an abstract use case in enterprise architect 10?
Edit:
Here is an example:
How do I achieve this in Enterprise Architect?
Stereotyping the use case as "abstract" does not change the font face.
I'm not asking how to change the font manually. I was expecting that if a use case is stereotyped as "abstract" then its title font face would automatically be changed to italic. But that does not seem to be the case.
Go to the properties window (not the dialog that pops up when you double click on the element, the windows default posion is in the lower-left corner).
In the "Advanced" section set "Abstract" to "True".
Regardless of the type of element, "abstractness" is not expressed as a stereotype in EA, so that wouldn't work for classes either. Instead, there is an "abstract" checkbox in the element's Properties dialog. You'll find it on the Details page if you open the dialog for a class.
The same dialog for a use case, however, does not include the "abstract" checkbox. However, the underlying data model allows any element to be abstract, including use cases.
Leaving aside the correctness or otherwise of modelling abstract use cases in favor of answering the actual question, there are two ways to achieve an abstract use case in EA. Both are "proper" in that they result in use cases with the appropriate "abstract" property set, as opposed to making purely cosmetic changes in the font or similar.
Use cases made abstract in either of these ways will be displayed with an italic font automatically, they can be distinguished in searches and generated reports, etc.
Method 1: element properties window
In the Element Properties Window (not the dialog but the one you open in Element menu), you can set the "abstract" property under the Advanced branch.
Method 2: use a script
Here's a VB script snippet which makes a single use case abstract.
if (theElement.Type = "UseCase") then
theElement.Abstract = 1
theElement.Update()
end if
If you place that in a diagram or object browser script you can easily make a use case abstract. You'll probably want to modify it to make it a toggle rather than one-way, but you get the idea.
This can be useful if you've already created a number of concrete use cases and want to make them abstract.
It is possible, but useless, and and style both in UML and OOP
If your client insists on the structure, you can show variations of some behaviour by extends and include stereotypes. And some of the variations can have a note that says, that this variation will be never really realized. This is semantically equivalent to your abstract use case. ...And the uselessness of the thing is obvious, too.
You can set Abstrect property directly, as is shown in a neighbouring answer. But it doesn't add to usefullness.
More reasons not to use "abstract" :
What does being abstract means? It means, that this very structure will be never realized by itself, and will only provide some common features to other, concrete structures. I.e., it is setting the way of REALIZATION, the inner construction of your system. And you should NOT solve problems of realization on UC diagrams, they are merely formal way of setting the task you are solving. You should not mix setting the task and solving it.
In technical way, being abstract is a structural piece of information. Use case diagram is a behavioral diagram. You CAN use structural elements borrowed from other diagrams in it, though. For example, abstract classes. But it is for exceptional use, not standard one. For example, you are solving the task and (alas!) you have already some SW/HW rigidly set due to licenses or politics. It is not good, but it can happen. But use case itself if pure behavioral element and you can't simply say it is abstract.
"abstract" is a word used in some languages, but not in all OOP languages. You shouldn't set the language in the UC diagram.
Use case shows behaviour, and will be realized first rather by interface than by class. And all interfaces already are abstract.
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.