There is an exercise that requires us to draw a usecase diagram for a bank,
description says that a customer can make deposits and withdraw money. for that usecase scenario do i just draw
"make deposit" and "withdraw money" ? or should I <<'include'>> "update balance" function for both of them as well ?
There is a rule of gold that help me solve similar situations, hope it helps for you.
Use case definition: Series of interaction between an actor and the system to obtain added value.
So, as you can see there are interactions, basically a use case is a series of interactions.
Which interactions are for update balance? None, is just a calculation the system (as opposed to the actor) does.
Let's specify that use case under the assumption is a business use case and is a ATM.
1) Actor1 press 'start button'
2) The system show present card screen
3) Actor1 present card
4) System present menu with options...
5) Actor1 select withdraw .... ...
6) System present screen with updated
balance
7) Actor1 select ....
So this is quite visual, is not a Use case in the first place, becouse there are no interactions involved. So there is no need to check if bring added value or not. Is just an important part of one of the many interactions involved.
There are exceptions in which you may take that shortcut, such as if you want be more clear in the model or if you what to divide work based on Use cases. But IMHO that's not use case at all.
You may have 'Show balance', but it would be only one interaction, with the exception if you have options like "show on screen" or "paper-print on a ATM"
Hope it helps.
Is Update Balance a use case? Is there any added value for the actor? I guess not. It's a simple function which is performed as part of the other 2 use cases. You are trying (like most people) to perform functional decomposition. Just that two use cases share a common function does not make the function a use case. A use case is about added value which the system under consideration delivers to its actor(s). When you describe the scenario inside the use case, you might well refer to scenarios is other use cases. Each scenario step will end in an action. And you could simply refer to the action Update balance described in Make deposit when you describe Withdraw money. But the, Update balance is the result from a simple add operation. So why referring to that as a common function at all?
Related
I'm trying to figure out how to specify an extending use case.
For example, suppose I have a use case Pay described in the normal flow by the point:
1. User select the product
2. User make the payment
3. System validates the payment
This flow is included in a specification table (that include actors, pre-condition, post-condition etc..)
Now I want to refer this user case in the specification of an extending use case like PayWithCreditCard without repeating all equal step; How can I do this?
In this case the only step I need to extend is step 2. and it is extended in someway like:
2.1 User choose payament with credit card
2.2 User insert credit card
2.3 User insert Pin
But how can I put this in a specification without to repeat step 1 and step 3?
Or there is another way to handle with this?
If use-case PayWithCreditCard extends use-case Pay, then Pay should identify explicitly extension-points where the extension will insert its behavior.
This is also (or especially ?) true for the tabular specification of a use-case: the specification shall list potential extension points and identify these in the flow of events. For example Spence & Bittner suggest to use curly brackets to identify the extension points (see their book Use-Case modelling, chapter 7).
In your case, this would look like this:
Use-Case: Pay
Actors: Buyer
Extension-points: Provide payment details
Validate payment
Basic flow:
1. Buyer selects the product
2. Buyer makes payment
2.1. Buyer selects the payment method
2.2. { Provide payment details }
3. System validates payment
3.1. { Validate payment }
3.2. Inform buyer that the payment was accepted
Pre-conditions: ...
The extension points would be defined in the extension. Dependeing on the selected payment method, the { validate payment } extension point could for example trigger an immediate credit card transaction with the bank, or wait for a delayed manual confirmation by an accountant that the incoming wire transfer was received.
For identifying the alternate flows, you could then use:
At { Validate payment }, if rejection or time-out: ....
It is important to be aware that an extension use-case, may need to know about the extension points of the use-case that it extends. This is different from an include relation, where the included UC is understood to be independent of the use-case that includes it.
Basically a use case shall only show added value a system under consideration delivers to one of its actors. Often people tend to start functional decomposition by misusing extends/includes. However, sometimes it's kind of useful to show variations like here when adding different payment methods that extend the payment procedure.
First of all "Pay" is no use case (it's verb only). Even "Pay product" is not a use case. I doubt the actor will see that as added value - it's more the opposite. The use case (I'd guess) is rather "Purchase product" which is a big difference. The actor wants to have the product and it's obvious that something in exchange is needed to get the product (in almost all cases that would simply be money). Now that you have this use case you want to show options (!) which you put into bubbles. These are basically no use cases per se. They just extend an existing use case. "Pay per credit card" and "Pay cash" are such extensions. (Unfortunately UML does not make a difference in the graphics for real and such pseudo use cases.)
Now, in your textual description you would have a decision at the point where you make the payment and where you would branch accordingly. Eg.
Select payment method
2.1 If credit card: Perform use case "Pay with credit card"
2.2 Else if cash: Perfom use case "Pay with cash"
Handling exceptions proves to be tricky here (in graphical as well as textual notation). So you might need to continue
If payment refused resume at ...
or the like.
A UC diagram would look like
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.
In a use case diagram for a web based hire system that I have, the following two functionality were required.
1. To validate a user's login before carrying out a payment function.
2. To check the availability of a certain tool and a time before the user is allowed to hire it.
So, for Case 1, I believe the following is correct. Is this the proper use of an include condition, or is there some other use as well?
An actor has an association with a MAKE PAYMENT use case. An include statement is drawn from the MAKE PAYMENT use case to a VALIDATE USER LOGIN use case.
For Case 2, I mapped it like this. However I feel that this isn't correct.
An actor has an association with a CHOOSE TOOL use case and a CHOOSE TIME. An include statement is drawn from them to a CHECK AVAILABILITY use case.
I think first that the two use case to choose might be more accurately depicted in a single use case, but I can't think of how the availability is to be mapped. Should it be in the specification only?
I would post diagrams, but I don't have enough reputation to.
Welcome to Stackoverflow.
Make "Validate user login" a precondition to "make payment", i.e. do not make it an extra use case. The user will not validate that he himself is logged in, the system does that for him and it's trivial. The precondition is noted in the use case description.
"choose tool" <<include>>s "choose time". That is what the user needs to do, while
"check availability" is what the system does for the user. So that goes to the use case description as well, and is not a use case of its own.
"make payment" <<extend>>s "choose tool", of course.
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