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".
Related
So basically i'm wondering if I'm thinking correctly. In an e-commerce environment does the order of a product have a relationship to the admin use case of managing orders? Once an order has gone through is the admin then going to be able to see the order through a relationship between the 2 use cases. I've provided an image for reference in my case.Here is the image
TL;DR
No, there is no extension here. Those will be two separate UCs.
Explanation
First let me focus on the goal of the Use Case diagram. This diagram is intended to show functions of the system and users (or more broadly actors) engaged in those functions. It is not used to show how data flow through the system or what are steps of the processing. There are other diagrams to do that.
As a rule of thumb, something is a good use case if you can log into the system, perform only the action of this single use case and then log out.
Extends (Includes works pretty much the same, it's just stronger) means that when you run the extended UC you can include the other use case as well. In other words in your specific example when Customer logs to E-Commerce to place an order he can while placing an order also choose to additionally receive and manage order (BTW I would reconsider this UC, you probably have few separate UCs here like Complete order, Dispatch order or Reject order) in which case additionally an Admin is need. Even if you invert Extends, it's still not what you want. Those two UC happen totally separately even though the order processed by Admin is the very same one placed by Customer.
I did not search for too long but I did not find a case where a given use case, associated to one actor, is extended or included by another use case, associated to another actors.
A use case describe the usage of your system by a given actor so you do not have any other actor involved.
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.
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.
I'm trying to write an use for shopping online . Customer can search for their desired item and add them to the shopping cart,but when they decide to check out, they need to log in with their account. But what happen if customer already logged in ? Is my diagram still correct ? If not, How can I modify it ?
Any use case must be connected to some actor(s). So, you should add connections.
The CheckOut use case is strange and inunderstandable. I don't know any action in net stores, that includes both login and payment. If you mean ordering, the login or payment are additional separate use cases, that are connected to ordering by some conditions that could be described as states.
Don't forget, you can't show sequences of actions and states by use cases elements only. If you have a small use case diagram, you could include state machine diagrams in it, but here it is not good - You have totally forgotten the admin and seller actors and their use cases, so the full use case diagram will be too large to add something extra in it. Describe sequences about logging in additional State Machine diagrams.
You are trying to use the use case diagram as a workflow editor, which is incorrect.
Use case diagrams are used to indicate the actions that a user can take to accomplish something. They do not represent the sequence of these actions. Each use case starts from a specific user action, and not as a side effect of another use case.
In your diagram, the "Search" use case is fine, but the display of the result is part of that use case. It would not be very useful if the system would just display a "search complete" result and then force the user to do some action to view the result... Although you have an <<include>> relationship, that it not what it means.
One example for <<include>> is one for a Login use case. The Customer could login on their own before doing anything else or the login could be triggered by another use case, such as Check Out. Login would therefore be a use case on its own and it would also be <<include>> by the Check Out use case.
Add to Cart is a use case that should be triggered directly by the Customer. It is not something that is triggered automatically - the Customer needs to do something.
The same applies to the Make Payment use case. I would think that the Customer needs to perform an explicit action in order to pay.
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