If an actor communicates with use case A, does he automatically communicate with an extending use case B or do I have to draw a second association beetween the actor and use case B - if my intention is to have the actor execute both A and B? What if, instead of <<extends>>, the the association between A and B was <<includes>>? Would a line between the actor and use case A also imply that the actor can execute the included use case (B)? Or do I have to draw a second line from the actor to use case b?
EDIT: I'm afraid I did not make myself clear. My doubt is not about the semantics of includes and extends or when use them, but rather their correct representation on a diagram. If I was asked to draw an ATM use case diagram, I'd probably would come up with the same diagram #RedBeard presented. However, in the site [http://elearning.uml.ac.at/], they assert that, acording to them UML2 standard, for the diagram to be complete, one should also draw two more associations, connecting the actor directly to the included and extending use cases, that is, one line from the actor to Card Identification and one more from the actor to Online Help, otherwise these use cases would never be executed. Since I found this explanation nowhere in the UML Super Strucure book, I decided to post this question here.
I add an example coming (more or less) from UML2.5 Specifiation. As you can see when a "Customer" want to "Withdraw" he must "Card Identication" because you have an Include from "Withdraw" to "Card Identication" so a "Card Identication" is always included when a "Customer" want to "Withdraw".
At the same time when a "Customer" want to "Perform ATM Transaction" (which can be a "Withdraw", a "Transfer", or a "Deposit"), he may, or not select a "On line Help". Thsi is due to the Extend link between "Perform ATM Transaction" and "On line Help" which means that a "Perform ATM Transaction" can be extended by "On line Help".
So if you want to model the fact that a actor have to do always both A and B an Include link would work. An Include link model a possible extension which is not mandatory. Hoping it is clear.
Related
I'm trying to figure out which use cases should I put in my use case diagram. I'm developing a poll webapp: after login, an authenticated user can browse a list of polls, then may select one poll from the list and finally may answer a poll.
This is what I made.
I'm in doubt with the extend relationship, is that correct or I should separate all these use cases without the extend relationship?
Every use case should let the actor achieve some goal, so that, at the end of the use case, the actor can say: "I'm finished".
In my opinion, the best use case is "Answer poll". The actor's goal is to give his/her opinion.
"Browse questions" could also be a use case: the goal is satisfying the actor's curiosity: "See what questions there are." But this is arguable.
I don't see any added value for the actor in use case "Select question". It seems to me that this is just a required step towards answering the poll. I would eliminate this use case. Selecting a question is a step in the flow of steps of use case "Answer poll".
Now suppose we keep two use cases: "Browse questions" and "Answer poll". What relationship would these two use cases have, include or extend?
Personally, I would use an include relationship. It's more natural to say that answering a poll includes browsing the questions than to say that answering a poll is an extended way of browsing the questions. But an include will only be possible if the complete use case "Browse questions" can be inserted at a single point in use case "Answer poll" (typically at the start of "Answer poll"). This may not be the case in your situation. Maybe you want to let the actor return to "Browse questions" after having answered a poll, for example to execute some final steps specified in "Browse questions". In that case, an extend relationship can be used.
If you opt for an include relationship, then don't forget to draw an association between the actor and "Answer poll".
A minor remark to end with: extend and include should be written completely in lowercase.
No, that's just wrong. You are starting functional decomposition. You don't do that during a use case synthesis. There is just one use case here: Browse questions. This is the one bringing added value to the actor. The other ones are steps in a scenario described inside the use case.
As always I recommend to read Bittner/Spence about use cases.
Given the following scenario:
If the credit card is declined, the card will be ejected. Otherwise, some amount will be charged.
How do I model this in a Use Case Diagram?
As far as I understand extends, (A) extending (B) means that: "If A happens, B can happen aswell". But this doesn't quite express the above scenario since one of these events/activities has to follow.
I think my main problem is that I have not quite internalised what you express and what you leave out in a Use Case Diagram.
It's neither. The Use Case is Pay X or Buy Y or the like. This is shown in the UC bubble connected to the Actor getting that added value. Your description only shows an alternative in the flow of the UC, not another UC being included or extended. A UC is only about added value, not about functions.
As always I recommend reading Bittner/Spence.
Looks like Payment using credit card is the use case here and two scenarios are possible
1.Payment successful
2.Payment declined
These are mutually exclusive paths of the use case and dont fit into the extends or includes relationships between use cases.
Includes relationship indicates a mandatory relationship while extends indicates a optional relationship
Is UML allowing this?
Can I define how an actor is interacting with use case?
In other words, can an use case have a different action depending on who triggered it?
For example in the following picture, Client pays for food, and waiter accepts the payment, but client and waiter are connected to the same use case. Wouldn't it be more convenient, to make separate use case called "Receive the payment" for waiter?
UML allows such things, but they are nonsense (like you can use English language to talk nonsense). A use case represents an added value for its primary actor. And if you have some UC Pay for food this is only a UC for the Waiter, not for the Client. The latter is only a secondary actors and of course he has no added value from this UC - rather the opposite.
If you want to follow very strict way describing how Client interacts with a restaurant as System under Discussion then you don't have Waiter as an actor, it's part of the System and does not belong to diagram of this level.
Is it possible for use case to have different action depending on which Actor triggers it?
Technically yes, but it smells bad. Consider to split the common part into separate scenario (this probably would require creation of a new common role as well). Anyway this is not related really to the main part of your question.
Client pays for food, and waiter accepts the payment, but client and waiter are connected to the same use case.
Here goes the tricky part. They aren't connected to the same use case, only client is connected to your "Pay for food". A use case describes interplay of Actor and the system under discussion. In "Pay for food" Waiter is a part of the system, you just don't have it as an actor on this level.
Wouldn't it be more convenient, to make separate use case called "Receive the payment" for waiter?
It's not about convenience actually, but yes. You have "Client pays for food" step in some high level "Client eats in restaurant" scenario. You can expand it into a scenario one level lower with steps like "System provides a receipt", "Client gives cash", "System returns change".
Now you can expand "System provides a receipt" into yet another scenario now on Subfunction level where you can finally introduce Waiter as an actor and describe steps how he goes to cash register, unlocks it with a badge, selects table, click "print receipt"... And on diagram of this level you will finally put Waiter as an actor.
Very easily. UC diagram has special words for that.
You can have an action of Payment that will Include actions of Receiving Money and Paying. It is absolutely normal.
Don't forget, that the use case diagram needn't to be the most common diagram in the project. UML outspokenly doesn't limit diagrams to abstraction levels. So, you can make more common use case, without include subtasks and later make more specific one, with include's. The first one will be that to be shown to the client, and the second one probably will not.
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
In a use case diagram, if a use case B extends a use case A, does it mean that an actor who is only associated with use case A ... is also associated with use case B(indirectly)?
I am making a use case diagram for a criminal record management system. The jail superintendent and the police officers both have the privilege to search a criminal via different inputs and then access his entire information. When viewing the information of the criminal, the superintendent also has a choice to modify it while the police officer does not.
Now I have made the use case for "search" and "access info" the same which both the actors can access. The "access info" use case extends the "search" use case. Now, if I extend the "access info" by the "update" use case in the diagram, would it imply that anybody who could access info could also update? That is, will I be wrongly depicting that the police officer could also update the criminal's information.
*I have not made an association between the police officer actor and the update use case. I am confused about the indirect association here...via the search and access information.
if a use case B extends a use case A, does it mean that an actor who is only associated with use case A ... is also associated with use case B
No, it doesn't. The "extends" relationship can be considered to mean "adds to", in terms of adding additional steps or options to an existing use case. So if an actor is associated with use case A, they may or may not be associated with the extended use case "B".
You may be looking for inheritance (generalisation) between use cases. If use case B inherits from use case A then if an actor is associated with use case A, this relationship is inherited by use case B. The problem with this (although tools let you draw it) is that the semantics of use case inheritance aren't really defined by the standard so you need to define clearly what you mean by it yourself.
Looking at the specifics of your example though, I think you're nearly there. If you create a use case "Access and Update Info" that extends "Access Info" then only the jail superintendent actor should have access to it.
You could also consider inheritance between actors, which can work quite well. For example, you could have a base actor "Read Only User" that accesses Search and Access Info. Then add an actor "Information Owner" (for example) that extends "Read Only User" and adds the reference to the "Access and Update Info" use case. What you're now doing is describing user interactions in terms of the roles they play in the system rather than in the domain. That can be useful or can be a barrier to communication - it all rather depends on context.
If communication with end-users is key, I'd suggest keeping the diagram very simple and not using any of these sophisticated relationships. On the other hand, if those using the model have a fairly good knowledge of UML, using "extends" and actor inheritance can add precision to the model and avoid duplication.