I have a Generalization in my use case diagram. How can I write the specification for each of them.
This should help you:
three use cases into one use case
My comment there was:
I would only add descriptions where they add value. So if you have a
general precondition for all three (login is a good example) then add
that to "manage accounts". Anything specific goes to the respective
"sub" use case. Similar to how you would deal with inheritance on code
level!
That way you'll avoid redundant documentation that you would need to keep in sync and which would be tiring to read.
Related
Suppose I have a use case with the name "View Items" that shows a list of items to the user. The user may optionally select a specific item to view its details and then back to the list again.
Should "View Item Details" extend "View Items" or they are stand-alone usecases?
Based on Extending definition here:
Extend is a directed relationship that specifies how and when the
behavior defined in usually supplementary (optional) extending use
case can be inserted into the behavior defined in the extended use
case.
For example (in that reference):
Registration use case is complete and meaningful on its own. It could
be extended with optional Get Help On Registration use case.
Meaning that, in Registration Use Case and in it's behavior, we may need to perform Get Help On Registration Use Case too.
It seems only a link, but it is not just a link to Get Help On Registration Use Case (we may need it to perform Registration).
For another example (from this question):
Suppose that we have Answer the Question Use Case and Research the Answer Use Case. To perform Answer the Question Use Case we may need to perform Research the Answer Use Case too. (And also this is not only a link)
For another example:
Suppose that we have Enroll in University and Perform Security Check Use Cases. To perform Enroll in University Use Case we may need to perform Perform Security Check Use Case too.
In Extend:
A behavior extends another if it is in addition to, but not necessarily part of the behavior.
Therefor: In your example to perform View Items Use Case we do not need to perform View Item Details Use Case too. In other word, in the steps of View Items scenario, we do not need to perform (or optionally) View Item Details scenario. They are stand-alone Use Cases.
I simply ask: does it add value? If yes, then just make it a stand alone use case. The use of <<extend>>/<<include>> usually indicates that someone is trying to do functional decomposition. I regard the introduction of these relations as bad move in UML which is likely sprung out of a technicians head than a business person. Added value can not really be sub-divided. Either it is, or is not.
"To add value, that is the question", and "There's something rotten in the state of UML".
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.
[Original Title] : Does an actor need to point directly in use case diagram?
or can I do it like this?
in this Use Case Diagram, I want to say that actor can use any use case in the pointed group-of-use-case.
does this kind of thing allowed?
Edit #1
The reason why I ask this question, is because when I create this use case there's a lot of line intersecting each other that makes me confuse.
And there's a comment :
It would be better to split that into smaller diagrams
does it mean like this?
Edit #2
after reading comment :
A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject.
so I decided to change to this :
is this how a use case diagram should be?
Edit #3
CONCLUSION
An actor should point directly to use case
Read more the detail about how a Use Case Diagram should be in comment on this question
To be UML compliant you can not do that. But I guess one can understand what you are trying to communicate.
As a side note: Login is not a business use case. It is a constraint. Also with CRUD use cases I would not separate them but have a Maintain <object> instead (which itself is some borderline use case since maintaining something is not directly business relevant). You can constrain maintenance operations to certain actors separately.
Edit Regarding Login (one of my favorites): Use cases are most commonly used to describe business context (exactly as you are doing). So when looking from a business perspective, a Login is not a use case, but a simple constraint (you can do the business relevant things only when you are logged in).
Now for the Manage/Maintain use cases. They are on a similar level. Usually the "managing" itself is not directly business related. In many cases the focus on the real business was lost. So instead the reason why you manage something is the real use case (e.g. Correct User Data, Collect User Data). This is quite challenging and I confess that sometimes I also fall back to Manage. Most people don't bother but doing a good job requires to think over basics and not adopt bad habits.
I just want to determine if I am using extend and include correctly. If I am using either incorrectly somewhere here please indicate where, and if possible, why it is incorrect.
https://imageshack.com/scaled/large/163/nlnk.jpg
Cheers.
Rules for using <<include>> and <<extend>> are simple:
<<include>> defines a sub use-case which is always included in the general use-case: use-case -include--> sub use-case. Usually it's used to denote a distinct part of a use-case or a common part that can be reused by other use-cases.
<<extend>> defines an optional sub use-case that can be executed upon certain conditions (which should be defined at a lower level design, not in use-case diagram). Here the direction of the relation is opposite to the <<include>> relation: use-case <--extend- sub use-case.
Apply these rules to your diagram and figure out if it's correct.
It looks as though "secure login" is required to be performed prior to the other activities that you link with <<include>>. Include implies that the use case also runs the included use case every time which in this case is probably not what you intend (just one login per session). You can always create new stereotypes, such as <<precedes>> or <<requires>>. Using them consistently will allow you to convey your meaning.
I find this piece of advice before when I'm trying to distinguish the difference between using extend and intend in use case diagram.. I hope it helps you too. The original advice comes from this StackOverflow answer.
Difference between extend and include
Extend is used when a use case conditionally adds steps to another
first class use case. For example, imagine "Withdraw Cash" is a use
case of an ATM machine. "Assess Fee" would extend Withdraw Cash and
describe the conditional "extension point" that is instantiated when
the ATM user doesn't bank at the ATM's owning institution. Notice that
the basic "Withdraw Cash" use case stands on its own, without the
extension.
Include is used to extract use case fragments that are duplicated in
multiple use cases. The included use case cannot stand alone and the
original use case is not complete without the included one. This
should be used sparingly an only in cases where the duplication is
significant and exists by design (rather than by coincidence). For
example, the flow of events that occurs at the beginning of every ATM
use case (when the user puts in their ATM card, enters their PIN, and
is shown the main menu) would be a good candidate for an include.
Also, from every book I've read, it is always recommended to use include and extend sparingly. Keep It Simple Silly.
Many relationships are clearly not correct here. However, I think the main issue with this diagram is not the correct use of include and extend, but rather to complex and overall unclear relationships. Although sitactically valid, you should avoid using more than one level of these relationships.
Your diagram is really hard to follow and to interpret.
Some refactoring ideas and corrections:
show "Secure login" class separately, linked only with Actor and then apply the following precondition for all use cases that "include" it: "User is securelly logged in"
"Logout after 5 mins" should be own use case, only connected to Actor as well, with 2 preconditions: "User is securelly logged in" and "User was inactive for 5 mins"
Remove the include between "Logout after 5 mins" and "Initiate a call". Extend might be more appropriate
reverse the direcction of the include between "Transfer funds..." and "Insure adequate funds..." - it is clear that the first one includes the second one and not vice versa
consider breaking a diagram in 2 or more simple and small diagrams of only related UCs: all login/logout could for example be shown separate and simplify the view. You should not have more than 5-7 use cases on one diagram
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.