I have the below question:
An actor is associated to a use case A, which has an extension use case B and B is extension of use case C.
Question: does it mean that the actor has access to use case C?
Thanks in advance!
Joanna
Having reviewed the diagram you have provided, your answer would be no, unless I am missing something where you are generalising the role of the fitment manager.
This would mean that the fitment manager would then inherit the roles of the other actor in the system.
Your diagram does not show this, so no the fitment manager does not have access to use case c. Although there is an extension to use case b from the fitment managers interaction with use case a.
I hope that helps
Related
I read that it is not correct to connect more than one primary actor to a use case so a situation like the image below is not correct
So I used inheritance like this
But the use case has an extended use case that is for only one actor (the second actor does not have that extended use case).
So in my example both manager and HR can browse users but only the manager can block a user.
How can I represent that in the diagram?
Two (or more actors) connected to one use case mean that all actors are involved in this use case. If you want to show, that either one of multiple actors can be involved, a generalization is a good possibility.
The notion of "primary" actor is not specified in UML. Therefore, I talked about actors involved in a use case. Of course, in the description of the use case you will be clear about which actor initiates the use. This will be the primary actor.
All the problems you have with «extend» can be solved by simply omitting it. In my opinion «extend» doesn't contribute to a better model. If you want to say that there is an overlap in the description of several use cases, you could use «include». But actually, you should not worry too much about these relationships. After all, you want to describe what actors are using the system for. Each actor goal is an own use case.
I'm with Axel: stay away from «extend» unless you know what it's meant for. I would guess that in your case it's legit. So what you can do is to just add a constraint to either the extend relation or to the actors explaining the restriction. Simply show it as a note with the constraint { in curly brackts}.
Otherwise there is a convention to put primary actors (the one that triggers the UC) to the left and involved actors to the right. Your approach with generalization is just fine. An actor represents role (like in a screenplay). And identifying those roles is an essential part during UC synthesis.
As always I recommend to read Bittner/Spence about use case modeling.
This notion of "primary" actor is not in the latest (2.5.1) version of the UML Specification. You just associate the right actor/s (Manager, HR or both) to each of your use cases without using generalization (inheritance).
How to present on the diagram of use cases that
before any activity an actor needs to be logged in into the system?
e.g Use case "Display information about an employee" uses server and the another use case ("Search the employee in the database")?
Is my use case diagram correct?
You need to set pre-condition constraints for UCs telling { user must be logged on}.
Your UC diagram start resembling a spider's web (and is hardly recognizable). A good indicator that your design went wrong somewhere. Look at the single UCs and ask yourself: does this represent added value for the actor? If the answer is yes, you're fine.
After some zoom I see "Employee management", "Account management" and others that simply do not name UCs meaningful (they are likely processes). Use verb-substantive. And keep above question in mind.
A quick google indicates that use case preconditions are a useful way to represent the requirement that a user be logged in first. However, preconditions can clutter the UC diagram with text and possibly restrict the number of use cases on a particular diagram. I suggest creating a new actor that is an "authenticated user". This differentiates the actor from a user that has not yet logged in and allows clear representation of the use cases available to each.
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.
In a use case diagram, if a use case B extends a use case A, does it mean that an actor who is only associated with use case A ... is also associated with use case B(indirectly)?
I am making a use case diagram for a criminal record management system. The jail superintendent and the police officers both have the privilege to search a criminal via different inputs and then access his entire information. When viewing the information of the criminal, the superintendent also has a choice to modify it while the police officer does not.
Now I have made the use case for "search" and "access info" the same which both the actors can access. The "access info" use case extends the "search" use case. Now, if I extend the "access info" by the "update" use case in the diagram, would it imply that anybody who could access info could also update? That is, will I be wrongly depicting that the police officer could also update the criminal's information.
*I have not made an association between the police officer actor and the update use case. I am confused about the indirect association here...via the search and access information.
if a use case B extends a use case A, does it mean that an actor who is only associated with use case A ... is also associated with use case B
No, it doesn't. The "extends" relationship can be considered to mean "adds to", in terms of adding additional steps or options to an existing use case. So if an actor is associated with use case A, they may or may not be associated with the extended use case "B".
You may be looking for inheritance (generalisation) between use cases. If use case B inherits from use case A then if an actor is associated with use case A, this relationship is inherited by use case B. The problem with this (although tools let you draw it) is that the semantics of use case inheritance aren't really defined by the standard so you need to define clearly what you mean by it yourself.
Looking at the specifics of your example though, I think you're nearly there. If you create a use case "Access and Update Info" that extends "Access Info" then only the jail superintendent actor should have access to it.
You could also consider inheritance between actors, which can work quite well. For example, you could have a base actor "Read Only User" that accesses Search and Access Info. Then add an actor "Information Owner" (for example) that extends "Read Only User" and adds the reference to the "Access and Update Info" use case. What you're now doing is describing user interactions in terms of the roles they play in the system rather than in the domain. That can be useful or can be a barrier to communication - it all rather depends on context.
If communication with end-users is key, I'd suggest keeping the diagram very simple and not using any of these sophisticated relationships. On the other hand, if those using the model have a fairly good knowledge of UML, using "extends" and actor inheritance can add precision to the model and avoid duplication.
if A is extension use case (not base use case), can A be directly referenced by the actor?
YES
The user can as said above, but does not indirectly reference/use it, it must be explicitly modeled.
Drive Truck extends Drive Steering Based Vehicle. It make sense that the Actor could reference either.
You can make the case that there are two kinds of use cases:
Abstract -- not directly experience by an actor, but extensions ("subclasses") are.
Concrete -- experienced by an actor.
yes; the fact that A extends some other use-case does not 'hide' it from actors