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.
Related
I have a use case "manage login and security" (MA01) which is described as follows: As a user I want to be able to navigate to the login & security screen in myaccount to be able to manage my credentials.
There is another use case called "Manage account details" (MA03) which is described as follows: As a user I want to manage my access data (email, password).
There are many more use cases like the second one. There are more use cases which are more and more specific. So for example the use case "change email" (MA03 001) which is a possible use case for managing the account details.
How do I show that in a use case diagram?
Is this a generalization relationship between the use cases? The first is very general and wants to manage the login and security; the other use case is more specific and wants to manage the account details.
Workflow of use case manage login and security looks like this
There are various opinions on how to apply the use-case technique. Your team seems to have an unfamiliar approach, but I won't comment on that. You have use cases and detailed flow descriptions and now you want to create a use case diagram to get a visual overview of these use cases. The question is which relationships to use between the use cases in the diagram. I will summarize the available relationship types and when to use them. Finally, I will draw conclusions about which relationships are applicable in the examples you have provided.
«include»
If the flow of use case UC1 contains a step that says "Now execute UC2" or "Perform UC2" or whatever, then the use case diagram should have an «include» relationship between UC1 and UC2, with the arrow pointing from UC1 to UC2.
Side note: Many people interpret UML such, that the «include» relationship only exists if UC1 always executes UC2, but in my opinion, it also exists if UC1 executes UC2 only under certain conditions.
«extend»
If the flow of use case UC1 contains an extension point EX1 (i.e. a point in the flow where UC1 can be extended, without any reference to a use case that contains the extension) and use case UC2 specifies steps to be inserted at extension point EX1 in UC1, then the use case diagram should have an «extend» relationship between UC1 and UC2, with the arrow pointing from UC2 to UC1. In the use case diagram, you may also mention the names of the extension points. If you want details about this, please refer to the UML 2.5.1 specification, chapters 18.1.4 and 18.1.5.
generalization
If UC1 and UC2 are similar, but UC1 is more general than UC2 and UC2 is more specific than UC1, then the use case diagram may have a generalization relationship between UC1 and UC2, with the arrow pointing from UC2 to UC1. For example, UC1 is "Buy a product" and UC2 is "Buy a food product". The description of UC2 says how it differs from UC1, but UC1 does not have any reference to more specific use cases. If UC1 shall not be executed on its own, but only the more specific use cases, then UC1 shall be marked as {abstract}.
Conclusion
There may be a generalization from use case MA03 "Manage account details" to MA01 "Manage login and security", but only if all account details can be regarded as login and security details and MA01 does not refer to MA03.
The relationship between MA03 and MA03.001 depends on how the flows of these use cases are specified. Please refer to the descriptions above to determine which relationship applies here.
There shall be an «include» relationship from use case "Display Login & Security" to use case "Set password", because the former use case says, at step 3: "Perform process UC-MA11 - Set password".
The description of Display login & security in the history of your post corresponds indeed to the step by step description of a very detailed use-case at sub-function level. Although UML allows to do such a functional decomposition, it is not recommended, as it leads to cluttered use-case diagrams with little added value compared to the tabular description that you already have.
I think Admiraal's answer provides all the necessary information if you want to pursue this way. I'd just add that Change email is in no way a specialization of Manage account details, since you cannot use the former as a substitue for the latter, it's just a part of it.
It appears however, the wording of your question (e.g. "workflow") and of your UC description (e.g. "action", "perform process UC-MA11-Set password") suggests that you're not really modelling use-cases but that you're rather modelling activities. For this an activity diagram would be much more suitable and value adding than an UC, because it allows you to show the successive steps, the sequencing of steps, and the call of activities ("processes") that can be specified in more detail in another diagram. In this case, you'd keep as use-case only the highest level of your current UC modeling, which may then more probably look as user goals.
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.
I'm creating a UseCase diagram for a library management system . I have a "Login" usecase which every actor should do befor going to other usecases . in other words , I want to show that "Login" usecase is the prerequisite to other usecases .
anyone know how to show this ?
thanks
There are a few ways to do this:
Use the <<include>> relation, where every UC <<includes>> login as the first step
Set a pre-condition on every UC that User must have logged in
Create an Actor named "Logged in User" (or similar) and show all your Use Cases related to it.
Which you choose depends on a number of factors. (1) is simple and intuitive but doesn't really scale well on a diagram if you've lots of Use Cases. (2) works well if you're documenting Use Cases textually - but doesn't show up on diagrams. (3) might not be conventional, but can provide more scalability than (1) while still be viewable on a diagram. However it breaks down if you have multiple Actors, each of which must be logged in to perform their UCs.
I personally tend to use (2). If I need a UC diagram I'll include a "Login" UC on it but won't show relation from it to other UCs.
One option I wouldn't recommend is the <<extend>> relation, where every UC <<extends>> the login UC. It doesn't really work semantically and suffers the same scalability issues as (1) above.
hth.
An alternative to an <<includes>> relationship in this case is a <<precedes>> dependency. This makes it clearer that login must precede the use case rather than simply occurs at some point during a use case.
Enterprise Architect includes such a stereotyped dependency in its Use Case toolbox, but you could otherwise create your own stereotyped dependency. The EA documentation on this states:
Invokes and Precedes relationships are defined by the Open Modelling Language (OML). They are stereotyped Dependency relationships; Invokes indicates that Use Case A, at some point, causes Use Case B to happen, whilst Precedes indicates that Use Case C must complete before Use Case D can begin.
You may not want to introduce OML idioms to your UML, but the feature does exactly what you want and is visible at the diagram level.
UCs are useful for many things, but most importantly for communication. If you start using relationships on UC diagrams, your communication benefits drop down a notch. Same with copy pasting prerequisite "user X must be logged on" in each UC, etc.
Most importantly UCs are not intended to be complete system specification. So simply put it somewhere else, for example:
as a rule in overall system rules list
as a table in "user access rights" spec section
Except for the context of UML,if A extends B,then B is a subset of A.
But in UML, it's the opposite,say,if A extends B,then A is a subset of B,
why is it so strange?
The <<extend>> dependency is only used for Use cases. It means that one use case extends the other under certain circumstances. In the following:
The client views account details. Under certain circumstances, the client may also "View Open Orders" as part of "View Account Details". It's also possible that the client will "View History" as part of "View Account Details".
This has nothing to do with generalization / specialization.
<<extend>> is confusing in use case diagrams. The smallest part of the confusion is that use case diagrams are not use cases!
A use case is a document, not a diagram. For example, the diagram above might have been drawn from the following use case text:
Client views account details.
Extensions:
1a. If client clicks "Open Orders" link
Client views open orders
1b. If client clicks "View history" link
Client views history
In a more-detailed model, these "extension points" would be listed on the "View Account details" use case element on the diagram. But this clutters the diagram terribly, in my opinion.
I first really learned UML by reading "UML Distilled" by Martin Fowler. I just checked that book before posting this answer, and found that Fowler suggests ignoring <<extend>>.
To write it in terms of use cases (I believe this is context you meant - if not, correct me), lest think about ordering a meal in your favorite fast food restaurant.
Basic use case is to order a meal, but it can be extended if you present a discount coupon. Every time you go trough this use cale, you get a meal, but only under special circumstances you pay less than usually (or get an extra sandwich).
I found quite a good example here: http://www.agilemodeling.com/essays/useCaseReuse.htm. As you can see enrolment for international student includes additional security check, and is applied only to a subset of enrollments. Hope that will help more.
UML doesn't use the term "to extend/extension". Instead, it uses the term "to generalize/generalization"; people also often refer to it as "to inherit/inheritance".
If B is a generalization of A (i.e. A inherits from B), then A is a subset of B. This should become clear from the "is-a" relationship: if every A is a B, then A is clearly a subset of B. In your terminology, if A extends B, A is a subset of B.
A type is a predicate: for every object, you can determine whether it belongs to the predicate. Extending the predicate means to make it more restrictive.