I'm working on an usecase diagram. The customer can pay through credit card or cash or check. I know I should mention them in diagram. But are they three separate main usecases that should be listed under usecases?
Generally, what is or is not a use case depends on the use case philosophy you are applying. The person who taught the UML class that I attended made it very clear that in his opinion, a use case can only be something that an actor wants to do.
As such, "Entering a Password" can never be a use case, because a user doesn't want to enter a password. Entering a password can just be a step within a use case, such as "Check the Account Balance".
I'd see paying as a very similar case. A customer doesn't want to pay for its own sake; a user pays because it's part of a bigger process, which is a use case.
You can model a payment use case and then create three extending use cases, one for each payment method
Only if the system you are modeling responds differently to different methods of payment.
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.
This is a simple ATM use-case diagram:
I think it missed something like Login (authentication) and Print (after Transfer, Withdraw... we will be asked for selecting print bill or not). So are they use-case?
When trying to decide if a certain piece of behavior should be a use case you should look to the "observable result" for the main actor. Does "login" yield such a result?
It depends on the system you are developing, the complexity of the authentication system etc. It might be a mere step in the use case scenario or it might become a (secondary) use case.
Another tool I teach my students is the BOSS test.
You have to ask yourself:
Will my boss be happy when I 100 times today?
Usually usecases like "Login" fail the BOSS test. Things like "Create Order" or "Pay Invoice" usually pass the BOSS test.
But again whether or not to make a use case depends on your methodology (granularity of your use cases), on your system, and on the complexity. There is no YES/NO answer.
No absolutely not. "Login" and "Print" are not usecases of ATM. User must by identified before use of ATM services as describe usecase diagram you provide. But, user does not use ATM for LOGIN service. It is not meaningful service. Print is not a UseCase as well. Print is one of step of processes within some of usecases of ATM.
Your UseCase diagram is correct.
Yes, Login is a use case. If Login doesn't happen, then none of the other use cases can happen.
A use-case is a process where an actor interacts with the system. Now map this with Login. Login is a user authentication process where the customer inputs the card and PIN. Then the system carries out the authentication. So this is by all means a use-case.
I have a scenario where a customer calls and gets an appointment at a garage. When drawing a UML Use Case Diagram, is the actor who is connected to placing this appointment inside the system (a) the customer, or (b) the employee?
The person that has their fingers on the keyboard and mouse is the actor. The person calling in is important from a business perspective, but not as important as the customer service rep that is interacting with the system.
Knowing that the actor is a CSR helps the screen designer and even the developer, because they will work from that perspective, ask for requirements or design clarifications from that perspective, and the system will be better as a result.
The reason the conflict exisits is because of the point of the project when you start drawing these use cases.
In your example, you already know that there is a CSR using 'a system' to make the booking.
However the design could have started from scractch. If this had happened the initial broad use case would have been 'a customer wishes to make a booking'. This could have lead to a number of differenc cases i.e. a customer will call a telephone number and an automated service will make the booking, a customer arrives at the garage and uses a terminal to make a booking or (as in your case) talks to a CSR (however that is i.e. phone or face2face) and they make the booking.
In many examples the customer would be the main actor in the system. However in your design the CSR is the one holding the mouse/keyboard/phone/pen or whatever and you don't need to design the iteraction between the customer and the CSR! Most societies did that years ago :)
It can be both. It depends. There is no single good way to model this. I would personally opt for the customer.
It is btw perfectly alright to include the phone as part of your system. So the boundary of a system does not have to be a defined by screen, mouse, keyboard. A printer might be included too as part of the system. I have written use case where it was quite essential that users printed some information and file that.
Who is the important actor here? The customer right? It is interesting to note here that Alistair Cockburn extended the actor and goals model of Ivar Jacobson with the actors and 'interests' model. His advice is to also think about who cares (or gets hurt) if user goal fails.
Is it important to get the actor just right? It is useful to brainstorm actors to find all user goals against the system. When you are confident you have found all goals, the actor is not so important anymore. Would you 'write' a completely different use case depending on this decision? Would a different system be build based on the outcome of this decision?
Who initiates the interaction? What is the event initiates it? This event is the decision of customer to call to make an appointment.
You could model customer as primary and employee as secondary actor helping customer to reach user goal. Both use phone and system to reach the goal, customer helped by employee. How they do that exactly is design?
Another consideration is that the 'actor' is a role. So you could use a role Appointment Maker. Some people care a lot about keeping job titles separate from roles as there typically some flexibility in roles that job titles perform.
There are also people who are of opinion that use of 'system' in describing use case is undesirable. They feel that it is a design/implementation decision and so they prefer more neutral 'Performer'. The Performer could be a system but also a human. In use case texts they use 'Initiator' and 'Performer' and in introduction of the use case text they explain that the 'Initiator' is in use case the Appointment Maker.
I personally think it would be fine and better if the use case was described as if customer was the one operating the system. The employee is just passing along information from system to customer and vice versa.
The book by Alistair Cockburn is a recommended read. His insights really helped me with questions like this one. It also helps to make sense of UML in relation to use case
I have a few questions regarding use-case diagram:
If my system has register/login use-case for guest, should it be enabled for admin, user (i just wanna clarify, if i have login system, do i assume that admin, user etc. are people who already logged in to system so i skip them with logging thing)?
If my system has a student actor, that is signing for individual seminars/courses, do i have (or am i allowed) to make use-case for ,,taking class'' after singing for them, and should there be relations between those 2
Should my teacher inherit from student actor, since he can browse courses as well? (and so on admin?)
Is my payment setup correct?
Remember that these are roles not people. An admin can be a guest, so long as they behave entirely like a guess, no special functions or rules. However, during log-in the user role could change, become admin. Note you are in some sense missing authenticate user, each use-case that requires security should include it, generally not extend.
Only if it interacts with the system, example, triggers an auto completion or is tracked in some way there of. Relations are not needed generally, associations could help communicate something that is ambiguous, but I am not sure what the would be in this case.
Nope, really then the role is any user could browse courses once they are authenticated. You could have students, admins, and teachers be sub-types of authenticated or associated person, etc.
Depends. Firstly you never pay and sign-up at the same time, so from a user standpoint that is broken. There are other ways in UML to connect this constraint of paying for courses. Process diagram, state diagram, etc. Because payment is really a long running transaction which can be hard to pin down. I would personally show the student and the external payment system interacting with the "payment" use cases.
Remember unless you are generating code most of the time UML is about communication so knowing your audience. Do not be afraid to use comments or constraints, if this is homework, use a constraint and get some real points. Maybe even put a constraint on the sign and pay course use cases.
If you want the admin to be able to log-in then he would have a use case for that. I agree that he most likely won't be registering, so maybe you want to break the register/log-in into two use cases?
You do not have to make a "Take Class" use case. Only make it, if that's how the user will interact with the system. My guess is that he won't be "taking" the class with the system, in which case it won't be a use case of the system.
I would think that you wouldn't want to inherit from student. First of all, from a realistic stand-point, it doesn't make sense. That would mean a teacher is-a student. You could extract that behavior to another parent class, but that might make the hierarchy too large and confusing.
If you are asking whether it is correct to say "sign for course" includes "pay for course," then maybe, it's probably better to use extend.
Another suggestion. The black arrow (usually means "dependency" in UML) you have between Actors and Use Cases, should probably be bi-directional, non-arrowed, line (this is usually called "association") At least that is what the UML standard says.