The system has 3 types of users : system admin, company user and supplier user. One of the system functionalities is to manage a list of unit costs for some actions. I am trying to draw a UML use case of this specific functionality but I don't really know if I am doing it properly.
Only the system admin and the company user can access this functionality, is it right to specify that like in the picture below?
Is there something wrong or mistake in this use case?
Related
I am currently working on the use cases for a car sharing app.
The simple diagram for the process of registration looks like this:
At the moment I am stuck with the following scenarios.
When a new customer is registered, a process is carried out at the head office (central)in which the following points are checked
Scenario 1 - Head office side:
1. The identity of new customers is carried out externally with
the post. Two possibilities: presenting the identity card at a post office branchor carrying out by video.
2. The verification of the customer's bank details is carried out externally with the bank.
3.The system will verify that the contact details (email address) are correct
4.the consent to the GTC has been obtained
My sketch for the confirmation process looks like this:
How do I show that the system verifies that the contact details (email address) is correct ? How do I show that consent to the GTC has been given ?
Scenario 2 - Customer's side: A customer can view and edit the information of his registration.
1.Edit profile data
2.Edit contact information
3.Edit bank details.
If information is changed during editing, verification must be carried out again by the head office.
What would the two use case diagrams look like ?
One or two apps?
(Posted before diagrams were added to the question)
Nothing in the narrative says that you need two systems. It's too early to decide about system architecture. You could have the following variants, each with pros and cons:
one and the same system (e.g. post office and customer access it via the web);
one and the same system that is accessible using different components on different devices (e.g. a rich client in the post office, a web interface for the customer on her mac/PC and a mobile app for a customer when using a smartphone);
several independent systems (e.g. a back office in the post-office, and an independent app that would connect not only to the back office, but also to other back-end services e.g. from other companies).
But how do you want to decide before first knowing what is needed and how the needs are related?
First, you have to understand the big picture of what's needed. Focus on the users not on the inner details of your solutions, as explained in the UML specifications:
UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. (...)
a UseCase (...) specifies a set of behaviors (...), which yields an observable result that is of value for Actors or other stakeholders (...)
(...) without reference to its internal structure
Look into your narrative to find actors (people, organisation, responsibilities), their goals (what do they need to do?) and how they could relate to each other. Just try a first sketch.
Your current model
(Posted after the diagrams were added)
I still see no reason to go for 2 distinct systems. You are working on a solution for car sharing. It may have different sub-systems/components, but the actors do not care. And neither does your customer. But:
If you'd go for two independent systems, you'd draw two disginct diagrams, and in each diagram you'd have an actor representing the other system that interacts with the system under consideration. As said, this makes sense only if it's an independent system.
In your case, I could imagine this for the bank account verification and the video identity verification: unless you intend to develop your own super-secured AI component capable of doing this, you'd probably outsource this to a specialized company, that may offer this service via an automated API.
The identify verification is at a different level of details than the other use-cases. You may want to show it in a separate diagram, in order not to pollute the main diagram.
And lastly, your second diagram has some issues:
the arrows of extend and include should not following the same direction: the target of an include is the included use case whereas the target of the extend arrow should be the use case that is extended (and not the use case that is extending the normal use case as you have shown).
ID correct and Bank correct are states. Use cases do not show states. The end-state can be specified in the description of the use-case but not in the use-case diagram.
Post office, Bank account, Video seem to be use-cases, but they are not well described.
A possible diagram could therefore be:
Note: I'd personally prefer specialization of Ensure identity. This corresponds more to the reality that there are two very distinct behaviors. But extension is ok.
Just to stress this fact: you do NOT describe a scenario with use cases. A use case is "just" to show the added value a system under consideration delivers to one of its actors. What you are asking is functional decomposition and that's just plain wrong. You would describe a scenario with an activity diagram (or as plain text like in the Cockburn way).
Let's say that i have started making an use case diagram for tourist agency web application. So what bothering me is the thing that i am not sure should i make administrator role and connect him with other actors with the generalization because they share common behaviors.
For example, i have web-site visitor as a role, then i have registered one who can book hotels... Now i was thinking of putting the administrator role who would have permissions to do what ever he wants to do. So all i need is your advice and what you would do if you will ever have the similar problem.
Yes, you can do that. And it's a common pattern. An actor represents (plays) a role within the system under consideration. And if you find people acting with different roles you can apply a generalization. Especially if you generalize Administrator from User this says that the admin can do anything the user can do.
In my application each user can create his own system and add team members to it. Each team member in scope of a system has a certain set of permissions, basing on which system decides if team member can access the functionality.
Some examples are:
Access to analytics board
Access to system configuration utility
Access to team management utility
Access to service handling utility
Each team member can have assigned any combination of these permissions.
I'd like to create an UML use case diagram, but i don't know how to represent use cases which are restricted only to team members that are allowed to use them.
Representing permission is like breaking the generalisation os UML use-case diagrams. You need to write them down in your use case scenario and for UML you can have separate section wise representation.
I don't think that use case diagram is sufficient for your requirements. You are talking about a user who has set of permissions. These permission are variable in time. It doesn’t depend on position (what’s more, we are not talking about being a deputy for a boss who just left for holiday).
In this case I always prepare use case such as Manage Permission and an actor is always a user. Then I make a class diagram where the user/permission model is. Then you have several possibilities how to work with permissions:
In every scenario the first step should be checking the permission to
do this steps.
Every use case has a preconditions related to
permissions.
…
Check the diagram where the simplest example is.
In the model part, I use actors inheritance to model right. For example, the
most simple actor is "user" and it is linked to use case "login" only, it gets the minimum right.
Others actors inherit from it. Like that they all have the right to connect to the system.
The most powerful actor, let say Administrator, inherits from all actors like that it gets all rights.
After you can not translate this in code automatically ... :)
Company X wants a web-based system that serves as a market place of ideas. Users should be able to login and post new ideas. Other users can comment on them and “upvote” them. The Administrators can login and mark that ideas have been implemented, and can reward the employee who posted it.
Following are the requirements:
Users should be able to login.
Users should be able to post a new idea.
Users should be able to search for and view other ideas
Users should be able to comment on ideas
Users should be able to upvote ideas
Administrators should be able to mark ideas as implemented
Administrators should be able to delete unwanted comments
Do you guys think my diagram is correct? I am new to UML so you guys can make fun!
http://imgur.com/TGKhweh
It is a not so bad start. Only:
Administrators are also users. They descend from them. So, they should have a generalization connection - empty triangle head arrow from Admin to User. Or to OtherUser (look below).
it is more natural to have a picture and name of an exemplar of agent. So, user, administrator - in singular.
you can divide Users from Other Users only if they have different definition and that difference is seen from the documentation, too. It is not. I would use only Users.
Of course, if some users really have different rights, it is OK, but:
the name is not good, IMHO.
They have all options of users, don't they? So they have to descend from Users
You should continue by adding the parts of your future system, that will collaborate with human agents on these use cases. Now you have only the first half of work done.
Edit:
Still your admin hasn't the generalization error from Admin to User. Admin can do ALL activities that user can, cannot he?
Still you have no subsystems on the diagram.
Search through older ideas should be the use case directly connected to user. And it does not extends nothing on the diagram.
Remember - use Include and Extends only on the last stage of UC diagram creation. When you already have the main picture and are refining it. And very often they should be used only on further, more thorough diagrams. Using Include and Extend from the start means that you haven't found the main concepts yet.
Should I make two separate use cases if a Member of the website can View their own personal profile and those of other users? Should it be Member - View Own Profile and Member-View Others' Profile? Or just Member - View Profile is enough?
As per comments, An use case can have one complete scenario/feature/function of the application. Hence if you are talking about use-case of member viewing profile, then it will be one use case but if you are talking about test cases for verification, then it would be two test cases.
A member viewing own profile does not mean that he can view others profiles too. Hence you need to have two test cases for verifying both the possibilities.
On the other hand, there are few more cases in this too - you should have cases like member able to edit his profile, edit others profile and this can also go to individual fields too. Member being able to edit all his details, but able to edit few details of other particular members below him in hierarchy and should not be able to edit any details of other members above him in hierarchy etc.
I would say the three use cases, like this:
Use cases demonstrate how actors use the system to achieve their goals. So structuring of use cases must adhere to these goals. Would you say, that an actor, e.g. visitor of your web app, would use your appication just to view his profile? Would he use it just to view profile some other user? If those are separate goals, then the use cases should be separate. But if you want to allow a visitor to see information about other users on site, one use case suffices.