What is the best way to represent the use cases of a system which has multiple users who have to log in to a system, in order perform various tasks?
For example, consider a university system where the admin can log in and add students to a database and the registrar can also log in and modify the data base?
Please post a simple use case diagram if possible.
You can simply represent each user (or, more scalable, each group or role) as an Actor. Each Actor would then be associated to a different set of use cases.
If there are is-a relationships between Actors, you can of course use hierarchies, so the children will inherit their ancestors' use cases.
Related
I'm stuck and confuse if I need to identify Database as an Actor since the database is given in the scenario.
I tried first to make it as an actor since based on the scenario, the data needed is from database. I Also tried to create a use case for the whole scenario but not sure if correct.
Here is the link of the scenario: https://justpaste.it/7tljo
The Use Case Diagram I created:
Is the database an actor?
A database should in principle not be an actor in a use-case. Two reasons for that:
A database is in general a component used to implement a system, so it is part of the system's internals (even if it is bought from a third party and installed on a separate server). But actors must be external to the system.
Actors may represent separate systems that interact with the system. But some degree of autonomy is expected since they play a role in the case: either the system actor supports the use-case, like a human actor could do, or it uses the system for achieving its own goals.
More generally, some useful question to ask yourself about candidate system actors: does the business need to know? are users or business stakeholders interested in? is the system actor a system that would be useful if your system wouldn’t exist? could we imagine the same use case with a human user instead of a system actor?
Is the overall diagram ok?
Syntactically, the diagram looks ok. But it methodically break down features/functionality in smaller pieces. This is called functional decomposition: Although it is not forbidden by UML, it leads to complex and unreadable diagrams. This is why the use-case community recommends not to do this, and instead prefer to align use case on user goals.
Hint: if you start to think about workflows, order of operations or user interface components when you design your use-cases (e.g. review contract, approve contract), you probably should consider using an activity diagram instead.
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.
I wondered if anyone could let me know whether this diagram is approximately correct?
I am depicting a database booking system and am very confused about the relationships between some of these use cases. I am fairly sure that I should include them on the same diagram but unsure whether some of my actors (Vet / Nurse) should be on the right hand side because they are kind of end-users whilst also being first users (sorry can't recall the term).
So when you modeling a Use case diagram, you have to realize that you can only approach for describe the functional requirements of the system.
Your system is treated as a blackbox-that is, dealing with what the system does in response to the actor's inputs, not the internals of how it does it. And use case always starts with an input from an actor.
Before modeling a diagram, you have to identify actors(Primary, Secondary), use cases & use case relationships. Actors are who or what initiates events involved in the task of the use case. Actors are simply roles that people pre objects play.
According to your problem,
A dog owner calls the clinic to make an appointment for a yearly
checkup. The nurse finds the nearest empty time slot in
appointment book and schedules the appointment for that time slot.
in here you can see that two people, dog owner and nurse involving the scenario, but the actual actor who interacts with the system is the nurse.
And the use case is a summary of scenarios for a single task or goal. So, you can see that Nurse is Making the appointment for the dog owner.
So to finally, you have to identify what are the relationships. simply relationships are representing communication between actor and use case or dependencies between use cases.
Dependencies between use cases can be defined by using include & extend relationships.
Include is using for determine to identify common sequences of interactions in several use cases. (Can be extracted and reused)
& extend is using for model alternative paths that a use case might have.And you have to keep in mind that base use case doesn't depend on the extension use case
I am creating use-case diagram. I have two actors: user and admin. Admin can check all orders, and user can check only his/her orders.
Should I create two use cases in my UML diagram, or I can use one use case with condition for user actor?
If I can use condition, which symbol must I use? Square brackets or curly brackets?
You need to attach a constraint to either the connector, the use case or the actor (where it's most appropriate). It could look like this:
Note that this is an example and contains redundant constraints which should not be done for a real UC.
I believe you are doing too much as part of your use case analysis.
Use cases are listing what your users (actors) can do and what benefit they get from doing those actions.
Thinking that way, each user/actor will have a set of actions (use cases) that will provide them with a benefit.
In your example, you should have many use cases for each actor, e.g., Admin would be able to create/delete users and provileges (UC1), list all actions from one or many users (UC2) and both would yeild different results.
When you start building your domain and behaviour models, then you will start adding the details of the behaviour.
I have three main actors in my Use Case diagram, Admin, SuperAdmin, User.
Now SuperAdmin CRUD Admins, each admin have different privilege, 3 different privileges to be precise.
My question is do I have to create 3 types of Admins (so 2 more actors) which each admin is represented according to his privilege, or just create a single Admin actor & link it to all three use cases (the 3 privileges)?
I am new user of UML & This is my 1st project.
That depends on the privileges.
If a privilege is a use case - a specific behaviour of the subject(system you are creating), exposed to a user - then if two actors differ in admittance to this use case, they should be shown as different actors. For example, one admin can register a user, the other cannot. Make also different names for them.
If a privilege is NOT a behaviour - for example, one admin can set the priority level of user 0..5 and another can set it in range 0..7, they could be shown as one actor and their privileges could be shown as states. State machines, according to UML standard, can be included in Use Cases.
If the privilege is merely temporary, surely use one actor, because it IS the state. Don't forget, that different users in different moments often have different options. But this fact is to be described by state machine, inside or outside of the Use case diagram.
By UML definition, actor does not represent privilegies.
UML says, When system executes declared usecases, it interacts (or collaborates) with actors associated to usecase. It means, if actor does not have association (direct or indirect) to UseCase, it has not access to this functionality.
Actor can specialize other actor, it means, specialized actor interact with system during execution of usecases, thas more general actor has associated etc.
Do not define actors only just to describe privilegies, it is not correct approach.