In an use case I have two Actor/user:
Patient
Expert
Both of them can do create/view/edit on patient profile. Expert can do them on all profiles,but patient can effect only on him/her profile.
I have to keep diagram clear and avoid from repeating the same things. Now I want to know is there a way to draw create/view/edit once but describe patient's limitations? Or it may be my mistake and it is better to use another diagram to describe limitations of actors? Sorry,but I am new by UML.
In the UML Use Case diagram there is (as far as I know) no built-in way to visually capture constraints. You can show then using the invaluable note symbol:
Although you can model the access right policies using some simple means:
realistic user access rights management will be probably implemented using access tokens, authentication, authorization and all this stuff delegated to another (complex and reliable) system component providing some kind of CanAccess(who, what, CRUD): boolean service to the "system".
In order to capture the various limitations you would typically put them into the precondition part of the Wikipedia: Use case narrative.
In the UML model the limitations would map to constraints and guard conditions shown in the behavior diagrams describing the use case.
See also:
chapter "Describing Use Case Behaviors" in uml-diagrams.org: UML Use Case
A use case diagram is not meant to show the permissions that each actor has to perform particular operations. It is meant to show what the system has to do and who it has to do it for.
In this case, I'd say you have only one kind of actor for this use case diagram: User. And you have the use cases: "User Creates/views/edits".
The exception would be if the Create operation of an Expert is different from that of a Patient (in a way that would be visible on the use case diagram). For instance, if "Expert Creates" also has to perform "Expert Sends Email", then that would be a reason to consider two separate actors.
Related
I have seen examples of people representing CRUD use cases in use case diagrams as "Manage X", but I wanted to know whether I can use a generalisation like the one in the screenshot to group many of them.
My intention is that "manage item" applies to the current catalogue being browsed. Would this be fine?
Use case diagram:
Yes, you can use a generalization to convey the intent that the actor manages items, and that items can be of different kind.
But your diagram looks very detailed and appears to be more a user interface model rather than a real goal-oriented use-case. I.e it describes more the “how” than the “what”. This is not forbidden according to the UML specifications, but not advised, as it leads to complex diagrams, distracts the modeler from the user goals, and leads to a premature design of a user-interface, whereas other modeling techniques are better suited to ensure an optimal user experience.
See also this question, that addresses similar concerns but at a lower level of abstraction.
P.S - Unrelated thoughts: The diagram might create ambiguity, since it suggests on one side that browsing is specialized by types of items (browse X and browse Y), but at the same time it suggests that any browsing can be extended with managing any kind of items (manage X, manage Y). This could be one more symptom that the use case was created with some class design in mind and not centered on user goals
I want a use case - store information system. I am to present the owner's requirements on a use case diagram, incl. a customer who, after logging in, does shopping, and an admin, who after logging in, manages prices, etc.
Can I log into the system generalize from one use case - two actors combined with one use case (below)? How can I 'improve' the diagram?
UML does not specify the semantic when more than one actor is associated to the same use-case. It can mean for example that one of the actors only is involved without the other, that the two actors are involved at the same time, or that the two actors are involved one after the other.
For sure, actors and use-cases are classifiers. You can therefore use generalization of use-cases or of actors (as explained with an example here) .
But your diagram, while syntactically correct, has some issue:
First Admin account is not a use-case: it does not produce any observable results to the actor; it is an internal detail of the sytem. So it does not correspond to the UML criteria of a use-case.
Then, Login, Confirm password (and perhaps Checkout?) do not correspond to user goals. As explained here, this is not fundamentally wrong according to the UML specifications, but it is a bad practice. Use-cases are meant to describe actor goals, and not details of a process or a user interface.
Maybe i'm old school, but you should also surround the use-cases with a box representing the "subject", i.e. the system under consideration.
There's no special magic about it, UML Use Case describes a case and can have more than one user.
Maybe just moving the shared Use Cases next.
But, since Use Case diagrams support User Inheritance as if they were classes, maybe adding a generic abstract superclass alike GenericUser with the shared Use Cases, and subclass alike User and Admin with their own specific Use Cases would be useful.
[Original Title] : Does an actor need to point directly in use case diagram?
or can I do it like this?
in this Use Case Diagram, I want to say that actor can use any use case in the pointed group-of-use-case.
does this kind of thing allowed?
Edit #1
The reason why I ask this question, is because when I create this use case there's a lot of line intersecting each other that makes me confuse.
And there's a comment :
It would be better to split that into smaller diagrams
does it mean like this?
Edit #2
after reading comment :
A UseCase specifies a set of actions performed by its subjects, which yields an observable result that is of value for one or more Actors or other stakeholders of each subject.
so I decided to change to this :
is this how a use case diagram should be?
Edit #3
CONCLUSION
An actor should point directly to use case
Read more the detail about how a Use Case Diagram should be in comment on this question
To be UML compliant you can not do that. But I guess one can understand what you are trying to communicate.
As a side note: Login is not a business use case. It is a constraint. Also with CRUD use cases I would not separate them but have a Maintain <object> instead (which itself is some borderline use case since maintaining something is not directly business relevant). You can constrain maintenance operations to certain actors separately.
Edit Regarding Login (one of my favorites): Use cases are most commonly used to describe business context (exactly as you are doing). So when looking from a business perspective, a Login is not a use case, but a simple constraint (you can do the business relevant things only when you are logged in).
Now for the Manage/Maintain use cases. They are on a similar level. Usually the "managing" itself is not directly business related. In many cases the focus on the real business was lost. So instead the reason why you manage something is the real use case (e.g. Correct User Data, Collect User Data). This is quite challenging and I confess that sometimes I also fall back to Manage. Most people don't bother but doing a good job requires to think over basics and not adopt bad habits.
I drawing use case diagram for my club, but i not sure this is the correct way to say administrator can do anything and member only can view profile, update data only the data itself
I build diagram with gliffy, this is my diagram and json data (this is just another representation of the picture below).
In principle your drawing is ok. What is definitely wrong is CRUD. This is not a use case. The same goes for Search. A use case must have substantive and verb at least. It may have an object as well.
Another thing is <<include>> relation. Avoid it! What you're trying here is a functional decomposition. Use cases are synthesized. When it comes to a functional decomposition in the class design you may introduce a general package for searching or CRUD.
There are various approaches on how to draw UCs. I prefer to bind them to Business processes rather than actors, since actor is mostly just any user of the system with some access rights assigned.
In this case I agree with #Thomas Kilian that draw use cases like CRUD or Update member data is not very useful. In use case diagram you are modelling interface of your system - buttons available for the outside world (actors) to press. Update member data is not visible outside so why to model it in Use Case diagram?
On a Use Case diagram can you show things that an actor cannot do, for example because they won't have permissions to do it?
Or is it just implied due to the fact that they won't have a line joining them to the particular use case?
If the Use Case you are diagramming is the case where an actor attempts to do something that is not permitted and is then denied, then yes, I would show it.
Otherwise, I would stick to only including things that are actually part of the use case.
No. An Actor would be connected to everything that he can do. If the Actor can't do it, then it's not shown.
This is what alternate paths are for. The basic path (a.k.a. happy path) will show what happens when the correct Actor initiates the Use Case. In the alternate paths you can show what happens if the wrong Actor attempts to initiate it.
You might model Role actors that can do the task. You could then have another use case that has the original actor attempting to acquire the given Role.
IMHO this question and most of the answers give a wrong impression about the way use cases should be used.
Use case was intended as a requirements technique that uses natural language. It is most and quite effective that way.
It can be a thoroughly destructive technique when it is combined with too much UML/modeling. Structured modeling of use case texts for example by modeling main and alternative flows using UML Activity Diagrams is a tried and tested way for example to create Use Cases of Mass Destruction.
A use case diagram can be useful but we should remember the purpose of use case as a technique which is first and foremost to identify the user goals a system should support. Subsequently we can capture more details using natural language in use case texts using main flow, alternative flows etc.
Using diagramming tools we can visualize some simple information:
- For each user goal we can create model element type Use Case.
- Show system boundary using a box for the system with use case elements in it.
- Create a relationship between actor and use case to show the actor has a particular goal against the system.
Keeping an up-to-date list of actors mapped to goals is however of secondary importance. Doing a stakeholder analysis, drawing up lists of actors is a means to identify the users goals. After user goals have been identified it is strictly speaking not longer necessary to keep the lists of actors around.
If we are asking questions about how to put user permissions in a use case model we are most likely trying to capture too much information. We should abstract model elements away so that the model does not try to answer/capture these type of detailed design questions.