I want to clarify one scenario in use-case diagram which involve in payment. There are 2 way of doing a payment.
Using card
Using mobile number
Here want to clarify about the second one. To do a mobile base payment first user need to add the mobile number when user try to do a payment in payment page. I put that as a extend relationship. Please tell me is this correct.
Formally, this is not correct. Use-cases could be associated with actors but not with other use-cases: the relationship between two use-cases may be «extend», or «include» or specialization. In consequence, Add mobile number and mobile can't be associated the ay you have diagrammed it.
Depending on what you mean, you may correct your diagram:
by showing that mobile includes Add mobile number (dashed line with arrow), if you mean that every time mobile is executed, add mobile number would also be executed.
by showing that Add mobile number extends mobile (dashed line with arrow), if you mean that in some cases where mobile is executed, add mobile number could need to be executed as well.
Other notation improvement coulb be to get rid of the arrows for associations wetween actors and use-cases. This is an obsolete notation.
Beyond these purely formal remarks, it's important to realize that use-cases should represent goals of value for users. While we would certainly agree that payment is a goal for the user, and we could certainly understand your desire to add extensions for different payment means, we would certainly not agree on the fact that Add mobile number is a goal for the user. It's either functional decomposition or user-interface details, both aspects that should in principle not be documented in a UC diagram.
Related
I am fairly new to UML especially use case. My question is should we divide use case to represent the flow of our systems?
For example, Party Management System has features like Party control, Mission Control and Participant Control. One participant can join many parties and parties can have many participants.
Users after login can choose All parties they currently enroll through Show Party button. Parties can be created by users and thus they will become Host so that they can invite Participants to join and give them Missions.
Selecting one party will direct user to Party Name page. From there, Host can Invite Participants via Participant Control tab, change their role into Host or Participant handle Mission to them in Mission Control tab contained in a specific Party.
Host can change party type to Open/Invite Only in Party Control tab or change name and date.
Only host can modify Party Details and assign Mission, participants can view missions that are assigned to them but cannot modify anything. All the tabs are placed at a Left Side Menu Bar.
We have 2 primary actors, Host and Participants. So my question begins here:
1. Should I divide use case to 4 use cases: All Parties (which will have Show Party process), Party Control, Mission Controls, Participant Controls just like the basic flow of the system (After login, users are in dashboard. From Dashboard, Choose Show Party—> Party Control, Mission Control, Participant Control)?
2. With each Use Case diagrams, I will add a Flow Chart to further illustrate how users interact with system, if just one Use Case diagram is need in this case, should I break down those features into many Flow Charts?
Thank you for reading my question!
No! What you are talking of is functional decomposition and that is not part of use case (diagrams). A use case "just" shows the added value it gives to an actor of the system under consideration.
When it comes to implementation details or "user stories" you can either use a Cockburn-like textual description or choose activity diagrams. It's also possible to have a mix if you have complex scenarios. However, there shouldn't be an overlap since then you have the question: which one tells the truth. Edits over time will likely diverge and leave some mess behind.
As always I recommend to read Bittner/Spence about use cases!
P.S. Basically #Christophe's and my answer are similar or at least they do not contradict. I'm just stressing a bit more that functional decomposition is a no-go on use case level.
Yes, use-cases can be broken down into several distinct diagrams that each show a part of the larger model.
But no, not a breakdown by flow: Use-cases are not for modeling flows. Use cases should correspond to user goals and should not to show how these goals shall be achieved:
for user interface details (e.g. the button, which leads to a feature, then the next...) you may use wireframes
for a more global design of user experience, you may consider story boards or user journey maps.
for a detailed flow of control or objects, you may consider activity diagrams instead of flow charts. In fact an activity diagram can specify a behaviors that allows to achieve a complex use case. However, withstand the temptation of “visual programming”.
But the use-case itself should be independent of how it is implemented and leave freedom for user-centric UI design. What can this system do for its users is the main question the diagram should answer.
I am to create a UseCase diagram for an existing web program. Unfortunately I am very unsure about UseCase, I like to mix it with other UMLs.
For this purpose, I have picked out the order page.
There are 3 different users, the admin, driver and customer.
The admin can view all orders and has the ability to create a new order.
The driver can see his own orders, as well as orders he can accept.
The customer can see his own orders, as well as place a new order.
There is a possibility to choose between the standard view (row view) and a widget view of the meta information of the order.
Last but not least, there is the possibility to click on one of the orders and a single order overview will open.
Based on this I have now created a UseCase diagram, my first question would be: Is this all correct, with the informations i gave?
Will this then become a huge UseCase diagram? Or should this rather be done page by page for web applications? For example, if this is the order overview and I now have the use case that I change the page (In this case, when I go to the single order overview). And is there a way to make this look cleaner? All these extends/includes on 1 place looks confusing.
I'm afraid I don't know if I'm doing this only partially right, or completely missing the point.
What you need to remember is that Use Cases are about added value and not about technical realization. That's really hard for tech people and that's why they always start functional decomposition. So looking at the above, the only use case is Show Order and nothing else.
Login is no use case from that perspective. It is just a constraint you apply to certain use cases.
You just have focused on the Show aspect but likely there's also add/edit/delete. Such CRUD can be dealed with in variuous ways and there's no general rule. There might be a Manage and a Show or what ever combination along with constraints.
Basically, when your UC diagram resembles a spider web your design is likely broken.
I'm so confused about the difference between extension use case and parent use case in Use case diagram.
I would like to know when can I use the extend and when can I use the parent use case?
For example :
Print Slip extend Confirm
pay through PayPal inherits Payment.
pay through credit card inherits Payment.
What's the difference between inherits and extend ?
Image source : https://t4tutorials.com/use-case-diagrams/
All proportions kept to compare the extend and the include + generalizations is like to compare the aggregations a and b + generalizations in :
In your diagram because of the extend the behavior defined in the UC Print Slip can be inserted into the behavior defined by the UC Confirm Order
The generalizations are like they are elsewhere in UML, pay through paypal is a Payment and pay through credit card is a Payment too. The diagram indicates the UC Confirm Order includes the UC Payment or one of the two inheriting UCs. So the behavior of the UC Confirm Order contains unconditionally the behavior of the UC Payment or the behavior of the UC pay through paypal or the behavior of the UC pay through credit card.
There is an example of inheritance between UCs in the norm, see figure 18.11 page 646 in chapter 18.1.5 of formal/2017-12-05
The two blue bubbles right bottom inherit from Payment through the generalization relation. That's, well, not advisable although looking convenient. Unlike for class inheritence which is clearly defined, a UC inheritence is an open field. The UML spec uses a generalization in just one single diagram and makes absolutely no definition of what a generalization for UCs actually means!
A use case is very much in the world of prose and informal language. It (probably, since there's no definition) means that you take the description of the parent UC and replace parts of it (override) with text defined in the inheriting UC. From a context that sometimes partially works. However, paying via credit card and Paypal is very different (you know) and there's not much in common. So a better way would be to «extend» Payment with the various ways to pay. This way you have a fixed payment procedure which optionally can go the credit card or Paypal way (or even a mix if so designed).
N.B.: The above example is just a bad one. It starts functional decomposition. Use cases shall show a single unique added value a system under consideration shall bring to its actor(s). Print slip is definitely a pure function and no real added value (who needs a paper slip these days?). Selection of product just the same: what's the added value here? Calculate... is telling just that it's a function. Basically you have two use cases: Confirm order and Make payment (note that using verb+substantive is mandatory in describing a use case in the title).
As always I shall recommend Bittner/Spence as excellent read about use cases.
I am trying to design a use case diagram for the following scenario.
I have a society that is distributing goods to clients based on their orders. These clients can be administrations, companies, or private individuals.
Depending on what the client is I want to know more or less of their info (name, number etc)
The use cases are different depending on whether the client is:
English
English and have used this service for more than 3 years
Foreign
For example:
The 1) English clients' orders are accepted only if they pay a small fee in advance.
The 2) English clients that have used the service for 3 years don't have to pay this fee but need to get approbation from a different actor (an Agent in this case)
The 3) Foreign clients' orders are always accepted no matter what.
This right here is where I run into trouble and need help with.
The orders from nglish clients that have a criminal record are always denied UNLESS they are an administration.
What are the most optimal actor choices here? I thought of going with English client, and Foreign clients but I don't know how to include the "Unless the client is an administration" in the use case.
The use case diagram is not the right place to put this information. As correctly pointed out by #Christophe, a use-case represents a goal for a user who is going to interact with the system to achieve the goal.
This means that there is only one single use case in your scenario: "Order Goods". However, it has a set of preconditions. You could list them as structured plain text. Since there is quite some complexity behind each of them, I recommend to put them into a separate decision chart. Then you have a nice clean separation of the diagram scopes, and they remain easily readable.
Sidenote: There could be a second one "distribute ordered goods" executed by a 2nd actor who is an employee who does fulfillment / routing / dispatching.
Actors in UML use-cases are classifiers. To decide about which actors to create requires to understand the actors their goals and behaviours and how they differ in the interaction with the system.
First of all, you need to clarify the super-ambiguous requirements:
"English client": is this a client with English nationality? Is it a client that lives permanently in the UK? Is this a client with an address in the UK? Is it a client with a +44 phone number?
"Foreign client": same kind of questions + can you define for sure the difference between Ensglish and Foreign? For example: what with bi-nationals? what with people having two addresses one being abroad?
"Using this service more than three years": what with a foreign customer who uses the service for 3 years and then settles in the UK?
Since you deliver goods, you might also need to consider a delivery address. What with an English client ordering on a foreign address or vis-versa ?
"criminal record": the criminal record might change over time: is it provided at each purchase? or is it part of the customer registration process ? In the latter case, is there a need to periodically renew this information ?
Use-cases should in principle be goal oriented. So a use-case represents a goal for a user who is going to interact with the system to achieve the goal. Use-cases are not meant to describe the detailed sequence of your process (if client is this, do that, etc...) and neither are actors meant for that purpose.
You should therefore consider reformulating the use-cases to represent how the actors would perceive them. If needed you may consider the status of the actor that could explain that an actor behaves very differently. Typically in your case, I could imagine :
New client: a new client may want to provide details (address, identification) or evidence that they are entitled to buy (criminal record - I suppose your activity is regulated if you request such details)
Public administration: behavior of administration in purchase is anyway different because of public procurement and legal constraints.
Privately owned company: behavior is different since it can involve several persons,
Private individual
The need to pay an advance fee seem to depend on the address, nationality, history. It's more related to the process (it's a part of it) than an independent goal for an actor. So I would neither show this as a use-case nor make different actors for this purpose.
The reason to deny an order is not something that is not relevant for the customer (no customer has a goal go get a purchase denied!). It's relevant to you and your system and is a consequence of the registration process. So no need to have a dedicated actor for that.
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