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.
Related
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 just want to determine if I am using extend and include correctly. If I am using either incorrectly somewhere here please indicate where, and if possible, why it is incorrect.
https://imageshack.com/scaled/large/163/nlnk.jpg
Cheers.
Rules for using <<include>> and <<extend>> are simple:
<<include>> defines a sub use-case which is always included in the general use-case: use-case -include--> sub use-case. Usually it's used to denote a distinct part of a use-case or a common part that can be reused by other use-cases.
<<extend>> defines an optional sub use-case that can be executed upon certain conditions (which should be defined at a lower level design, not in use-case diagram). Here the direction of the relation is opposite to the <<include>> relation: use-case <--extend- sub use-case.
Apply these rules to your diagram and figure out if it's correct.
It looks as though "secure login" is required to be performed prior to the other activities that you link with <<include>>. Include implies that the use case also runs the included use case every time which in this case is probably not what you intend (just one login per session). You can always create new stereotypes, such as <<precedes>> or <<requires>>. Using them consistently will allow you to convey your meaning.
I find this piece of advice before when I'm trying to distinguish the difference between using extend and intend in use case diagram.. I hope it helps you too. The original advice comes from this StackOverflow answer.
Difference between extend and include
Extend is used when a use case conditionally adds steps to another
first class use case. For example, imagine "Withdraw Cash" is a use
case of an ATM machine. "Assess Fee" would extend Withdraw Cash and
describe the conditional "extension point" that is instantiated when
the ATM user doesn't bank at the ATM's owning institution. Notice that
the basic "Withdraw Cash" use case stands on its own, without the
extension.
Include is used to extract use case fragments that are duplicated in
multiple use cases. The included use case cannot stand alone and the
original use case is not complete without the included one. This
should be used sparingly an only in cases where the duplication is
significant and exists by design (rather than by coincidence). For
example, the flow of events that occurs at the beginning of every ATM
use case (when the user puts in their ATM card, enters their PIN, and
is shown the main menu) would be a good candidate for an include.
Also, from every book I've read, it is always recommended to use include and extend sparingly. Keep It Simple Silly.
Many relationships are clearly not correct here. However, I think the main issue with this diagram is not the correct use of include and extend, but rather to complex and overall unclear relationships. Although sitactically valid, you should avoid using more than one level of these relationships.
Your diagram is really hard to follow and to interpret.
Some refactoring ideas and corrections:
show "Secure login" class separately, linked only with Actor and then apply the following precondition for all use cases that "include" it: "User is securelly logged in"
"Logout after 5 mins" should be own use case, only connected to Actor as well, with 2 preconditions: "User is securelly logged in" and "User was inactive for 5 mins"
Remove the include between "Logout after 5 mins" and "Initiate a call". Extend might be more appropriate
reverse the direcction of the include between "Transfer funds..." and "Insure adequate funds..." - it is clear that the first one includes the second one and not vice versa
consider breaking a diagram in 2 or more simple and small diagrams of only related UCs: all login/logout could for example be shown separate and simplify the view. You should not have more than 5-7 use cases on one diagram
Suppose we have a simple on-line store. Things that the user would want to achieve with the store would be:
Register (to create an account)
Browse items
Add items to basket
Checkout and pay
View account information
Edit account information
etc
However, there would be functionality that the user could initiate but wouldn't be their main goal of using the system:
Login
Logout
Select 'electronics' department
Select 'vehicles' department
Enter delivery details
etc
I would argue that things like login and logout shouldn't be in the UML use case diagram. The reason being that a user would not want to go to the on-line store just to login; they would always have another aim which would be to view / edit account information or browse and buy stuff.
Likewise, the two select 'statements' are part of the browse items use case. I wouldn't use generalisation because there could be many departments.
Finally, the enter delivery details is part of the 'checkout' or 'edit account information' use case. I would normally lump this in with the 'edit account information' use case otherwise you may as well have use cases for 'edit name', 'edit email' etc.
My main concern is if you have a very complex use case diagram it defeats the purpose of having one as it won't be easy to read.
So, my question is as follows. Is my thinking behind this correct? Is it best to only model 'real' goals in the use case diagrams or everything that the actors can initiate?
Does a UML use can show everything the actor can do (functionality) or
everything the actor wants to do (goals)?
It can be either - the UML spec isn't prescriptive on that front. Alistair Cockburn created a categorisation for Use Cases that indicates what level they focus on.
Having said that:
My main concern is if you have a very complex use case diagram it
defeats the purpose of having one as it won't be easy to read.
That's a very real risk. Personally I find I get most from UCs by focusing on the users and their goals. What value are they looking to get from the system?
Keeping it at that level prevents a "can't see the wood for the trees" situation - and also stops UCs becoming a complete, functional decomposition design.
hth.
It is not wrong to exclude some use cases from your diagram, and indeed it might be a good idea. For instance, if you are going to show your diagram to the business department, you can draw an UML model that describes the operational use cases. If you are going to hand down your diagram to the programmers, you would want to give them a complete description of what they have to implement. These are just models of your system.
When one draws a use case diagram, usually one also writes the behavior of each use case (as free-text description, pseudocode, or by using interaction diagrams).
The UML specification says that:
A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.
Login and Logout are observable to the user. While the user will not visit your site with the only goal of logging in, such use case certainly has some execution flow that you also want to describe. If you don't allow users to initiate a login by themselves, there will be use cases that include the functionality of login. A user may have also interest on logging out before leaving the site, so that no session data will remain stored in his computer.
Select 'electronics' department, Select 'vehicles' department... Why not just Select department (I suppose that they are not too different).
I would draw this and other use cases, as long as they are relevant to the model.
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