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.
Related
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.
I am new to object oriented design and I wanted to do my first ever UML use case Diagram on a simple application which contains toolbar on the top left corner. The toolbar is called files and when the user clicks on it,a drop down menu is opened with options to open a slide,save slide,make new slide and exit the application.
My question is, am I doing it correct with Use-Case inheritance(Generalization) ?
This is my diagram.
I am sorry to disapoint you, but I have to tell you that this practice is just plain wrong:
From the point of view of the semantics, the use-case specialization means that Open presentation is a special form of Check file, and Save file as well, and that the actor could use them interchangeably and independently. But this cannot be what you mean: exiting a presentation is at best a sub-part of checking a file
From the point of view of the purpose, a use-case should represent a user goal. It's part of the problem space, i.e. what the user wants to achieve. It's not part of the solution space, i.e. how the user will achieve it. A toolbar is not a goal: it's a user-interface element.
From the engineering practice perspective, use-case should not be used for user-interface design. It's not my own statement, but that of Jacobson, Booch and Rumbaugh, the founding fathers of UML:
The problem is that the [use-case] descriptions often contain implicit decisions about user-interfaces. Later, when the user interface designers suggest suitable user-interfaces for the use-case , they may be limited by those decisions.
in The unified software development process, page 164
So in conclusion, it's a bad idea to start use-cases from the user-interface. It locks you into your own design and ignores the user experience. You should focus instead only on the user needs. THe same use-case could then be used whether you'll implement it using a GUI interface, a chatbot interface, or a a voice-based interface.
While drawing Use Case diagram, one thing you should focus on is, the actual meaning of it and the purpose of drawing it.
A Use Case refers to what the users in respect of their type are able to do in your System... Anything inside the boundary is what system is capable of doing or what it can provide as a service to its users.
While naming the use cases, you should only use verbs and actions, for example:
1- Login | 2- Submit a Request | 3- Update Profile Description
You should avoid any nouns in them.
There are several relationships that exist in a Use Case Diagram among use cases, and a relationship among actors and use cases of the system, And They are as follows:
Association: the only relationship that can exist between an actor and a use case; Which says the actor is initiator of this use case, or is the one who is caple of operating the use case.
In the example above, User is caple of loggin in and submitting a complaint.
Include: Use Cases can include one or more use cases. When a use case includes another use case, it means the included use case or use cases happen all the time and are part of the initial use case.
Paying fees is included, because user has to pay the fees in signing up process, it has to be done, and it's part of the baseline path of the scenario.
Extend: When a use case is not happening all the time, and is part of your alternative path ( Alternative path of the complete scnario for this use case ), the use case should be extended to the base use case.
Forget password is extended to Login use case, because it doesn't happen all the time, and it's part of a alternative path of Login scenario.
Generalization: When there exist several different ways that a use case can be performed and completed, we use generalization. The inheritent use cases should all be of the same type as the inherited use case.
Submitting a complaint can be done in several different ways, in this case, we need to seprate each use case and inherit from from the submit a complaint use case which includes paying fees, this shows that, paying fees is a part of every type of complaint which is submitted.
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.
Suppose we have a simple on-line store. Things that the user would want to achieve with the store would be:
Register (to create an account)
Browse items
Add items to basket
Checkout and pay
View account information
Edit account information
etc
However, there would be functionality that the user could initiate but wouldn't be their main goal of using the system:
Login
Logout
Select 'electronics' department
Select 'vehicles' department
Enter delivery details
etc
I would argue that things like login and logout shouldn't be in the UML use case diagram. The reason being that a user would not want to go to the on-line store just to login; they would always have another aim which would be to view / edit account information or browse and buy stuff.
Likewise, the two select 'statements' are part of the browse items use case. I wouldn't use generalisation because there could be many departments.
Finally, the enter delivery details is part of the 'checkout' or 'edit account information' use case. I would normally lump this in with the 'edit account information' use case otherwise you may as well have use cases for 'edit name', 'edit email' etc.
My main concern is if you have a very complex use case diagram it defeats the purpose of having one as it won't be easy to read.
So, my question is as follows. Is my thinking behind this correct? Is it best to only model 'real' goals in the use case diagrams or everything that the actors can initiate?
Does a UML use can show everything the actor can do (functionality) or
everything the actor wants to do (goals)?
It can be either - the UML spec isn't prescriptive on that front. Alistair Cockburn created a categorisation for Use Cases that indicates what level they focus on.
Having said that:
My main concern is if you have a very complex use case diagram it
defeats the purpose of having one as it won't be easy to read.
That's a very real risk. Personally I find I get most from UCs by focusing on the users and their goals. What value are they looking to get from the system?
Keeping it at that level prevents a "can't see the wood for the trees" situation - and also stops UCs becoming a complete, functional decomposition design.
hth.
It is not wrong to exclude some use cases from your diagram, and indeed it might be a good idea. For instance, if you are going to show your diagram to the business department, you can draw an UML model that describes the operational use cases. If you are going to hand down your diagram to the programmers, you would want to give them a complete description of what they have to implement. These are just models of your system.
When one draws a use case diagram, usually one also writes the behavior of each use case (as free-text description, pseudocode, or by using interaction diagrams).
The UML specification says that:
A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.
Login and Logout are observable to the user. While the user will not visit your site with the only goal of logging in, such use case certainly has some execution flow that you also want to describe. If you don't allow users to initiate a login by themselves, there will be use cases that include the functionality of login. A user may have also interest on logging out before leaving the site, so that no session data will remain stored in his computer.
Select 'electronics' department, Select 'vehicles' department... Why not just Select department (I suppose that they are not too different).
I would draw this and other use cases, as long as they are relevant to the model.
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