I have a use case where user may log in via normal login, as well as social login such as Twitter, Google, Facebook. I draw the use case as below but not sure if it is correct.
Login account ---extends---> normal login
---extends---> Twitter login
---extends---> Google login
---extends---> Facebook login
The <<extends>> works vice versa.
I'm quite tired telling this all the time, but Login account is not a use case. It does not deliver any value to an actor. It is a simple constraint which applies to other real use cases.
Further: avoid the use of <<extends>>/<<include>>. They are a sign of functional analysis you are trying to do with your use cases. Instead use cases are synthesized which makes a big difference. If your use case diagrams start resembling a spider's web your design is broken.
Recommended read: Bittner/Spence.
In general I tend to agree with Thomas Kilian to be careful with use cases for loggin in as they generally do not pass the boss test.
Will my boss be happy if I do [--insert use case--] 100 times?
But use cases are used in many different ways, and for many different systems. If your system is authentication service then I guess Log In might be an important use case.
Anyhow, the extend relations are pretty much wrong.
There is also a heated debate in the community on what extends really means, and how to use it. I usually advice not to use extend at all.
But if you want to keep them then you probably need to do it the other way around.
The extending use case inserts some specific functionality to the extended use case at a specific point in the execution of the extended use case (the extension point). The extended use case has no knowledge of the extending use case(s).
Extends is probably not what you need here.
I would probably not go into that much detail, and stick to the single Log in use case (if any). You could make alternate scenario's for facebook, twitter, google, etc...
But if you really need this much detail in your use case model then I would use generalization
As you can see there is one abstract use case Log in. The three other concrete use cases inherit from this use case.
In analyses there are no right or wrong answers. There are only better or worse answers, and it all depends heavily on the purpose of your model.
I think your use cases are a little too technical. When you're identifying use cases, you need to go back over them a few times to make sure the complete set of uses cases is meaningful. This often means some use cases are merged into a single one, others are split, etc.
The key question to ask when differentiating use cases is "is the difference between these two use cases meaningful to the actor?" You should not be asking "are there different ways to achieve this functionality?" or "will the implementation need to support several different protocols?" These are design issues, which should be documented not in the use cases but in the collaborations which realize them. Realizing one use case with several different alternative collaborations is perfectly valid and normal use of UML.
In this case, does it matter to the user how they log in or is it only important that they log in? I suspect the latter, in which case there should only be one use case.
Related
I have a question related to Use Case diagram for a mobile app and charging.
So let's say My use case is Set Charging mode. Charging mode can either be Immediately or Scheduled Later. What Relationship should be between the Set Charging Mode UC and the two different options?
I have thought about using Generalization but I am not 100% sure this is correct.
Not knowing much about your context, I nevertheless understand that "Set charging mode" is not really a user goal: it's not a set of behaviors with observable results of value for the user. As such it should not be a use case.
In principle, "Set charging mode" would be part of the description of the real use case (e.g. getting something for which the user will be charged). Or maybe you'll specify the expected behaviors in a separate activity diagram.
If I'd be wrong, or if despite the advise you'd opt for a use case, the use case should require a choice, and a mutually exclusive one. This would be part of description of the use case Set charging mode, or indicated as a comment for the use case.
If I'd still be wrong and if you'd really really want to show two use cases, you could indeed either have two specific extensions to the choice or consider specialization. However, from your description, I still understand that these use cases would not be independent (Set charging mode or Set charging mode to later make no sense on their own). Moreover they seem far too detailed for a use-case. I'd therefore really advise not to follow this way keep UC for the big picture and avoid getting lost in details better documented elsewhere.
To complete Christophe's answer, you have to keep in mind 2 things (at least):
the purpose of a use case diagram is to help you in the specification of the problem and later in programming
UML does not define a level of granularity for a use case except the famous 'observable and tangible goal' but to help you, keep in mind that a use case is detailed with an activity diagram (among others). In your case, the corresponding activity diagram would contain ONE action
The use case should depict this situation:
A shipman can ask questions via radio to either a VL, DM or WL. Depending on the question, they need to look it up in APIC (a software tool), but this is not always the case. They all are apic operators, but depending on their role, they have their speciality that they only can access in apic.
The question the shipman asks can be about lock executions, the nautical weather, etc... but it all comes down to the same question-answer format.
Is my use case correct?
Asking a question is usually not a use case. The goal of the shipman is probably not to ask a question, but to get some answers. So asking and anwering is one use case.
When analysing the use case, several possibilities will show up, such as looking up information in the APICS-system. I would just describe this within the use case (possibly with an Activity Diagram). What is the advantage of using an extend here? (I agree with the other answer, that the arrow is in the wrong direction. Additionally it should be an open arrow).
Each goal is an own use case, even when they have much in common. After describing the essential steps of the use cases, it may save some work to look at them and find those that have a big overlap in the essential steps and then create an abstract use case containing the commonalities. But this should only be done after describing the use cases.
Always remember, that the main goal of use case analysis is to find all functional requirements for the system, especially those that are not immediately obvious. If your use cases are just wrappers of functions you already know, not much insight is gained by them.
Three issues here:
The extends arrow is the wrong way around.
Generalizations of UCs is a bad idea in general.
Just as a side note: your actors miss their legs. This way it's a Female symbol (Venus' mirror).
Let's elaborate a bit on the 2nd. Why is it a bad idea? UCs represent a single added value for an actor a system under consideration will deliver. So each UC is unique (think of unique sales propositions). Generalization of USP is only valid in a franchise. So unless you model McDonalds here, it's likely a wrong approach. Look at the main UC "ask question". Do you consider that added value from a system? I wouldn't. When looking at the bubbles behind they more look like primary use cases. So, just remove that general "ask question" and connect the bubbles behind directly with Shipman.
As always when it comes to UC questions: Bittner/Spence about UC is the best read I can recommend.
I have a question about uml and extend notation of use-case.
How I can extend all use case.
For example if I created a connection down use case that extend almost all use case, but I don't want to connect all with the notation on the use case diagram cause is very orrible to see. How can I do?
First of all: the importance of Use Cases
Modeling Use Case Diagrams (Use Case Modeling) is SO important step in Software Analysis and Use Case Modeling should be performed by professional Analysts:
All estimations (Time, Budget, Resources and etc.) are performed based an Use Cases.
In some Use Case Driven Methodologies, all subsequent steps are based on Use Cases.
and etc.
Secondly: Knowing Use Case Modeling Traps.
In Use Case Modeling there are some traps that we need to conside related to your question:
(Trap #1: Use cases that users don't understand.) (see reference 1)
Use cases are a way to represent user requirements, which describe
what the user needs to be able to do with the product. Use cases
should focus on tasks a user needs to accomplish with the help of the
system, so they should relate to the user's business processes.
Your users should be able to read and review use cases to find
possible problems, such as missing alternative flows or incorrectly
handled exceptions. If users cannot relate to use cases, there's a
problem. Perhaps they're written too much from a technical, rather
than business, perspective.
(Trap #4: Describing specific user interface elements and actions) (see reference 1)
Write "essential" use cases that describe the interactions between the
user and the system at an abstract level, without incorporating
user interface specifics. The use case description should not include
a screen design, although simple user interface prototypes can be
valuable to facilitate the use case exploration.
(2. Not having clear business goals for every use case) (see reference 2)
(6. Specifying use cases in too much detail) (see reference 2)
Thirdly: Use Case Modeling is in the Requirement phage of methodologies.
We should not put common implementation methods in Use Cases. Common methods in implementation handled by other diagrams in next steps of methodology. (maybe in Design Model) So, if we put all common methods in Use Case Model, the number of use cases increases a lot. (and our estimation as mentioned in first part goes wrong)
You can't - and it's nonsense. A use case shows added value for an actor. Extensions to use cases are very rare. In most cases people try to apply functional decomposition and mistake a step of actions recurring in multiple use cases as "partial" use cases. They aren't! If you are trying to do what you describe you went the wrong path. You should instead think why and where your use case synthesis broke.
I strongly recommend reading Bittner/Spence to get the right idea what use cases are all about.
You can use use inheritance.
Something like this, use cases B and C are extended since this is inherited.
But as #Kilian said, it would be interesting that you explain why you need a such model.
With this Use Case diagram, I'm unsure if I'm currently doing it correctly or not. Checked online and each site is giving me a different answer. I just need a direction or someone to correct me.
This is interesting as I am currently going through the exact same discussion with a client...
I would say "no" simply because I am unsure of what this actually represents.
A use case must bring a benefit to a user, and I really don't this in this diagram. What does Actor0 actually trying to accomplish? I do not get this from the diagram.
Did you write down statements before trying to do this? I find that going to a whiteboard and writing down what your actor's goal and how you see this happening so that the actor achieves the goal is a good start to better understanding the use case and differentiate the system being built from external systems. One way to do this is through a set of user stories (or use case slices).
And answering Thomas Kilian's excellent questions will also help you in this task!
Also, you are doing something that I see too often from people starting with use cases (and sometimes with UML experience): use case decomposition as a set of actions - basically trying to model a set of activities by breaking it down. Doing that is typically the second step in your analysis (e.g., by using activity and sequence diagrams).
No. Only "Register" (what?) and "Add/View Details" (which?) can be regarded as use cases since they add value. Neither "Login" nor "Main Menu" are use cases. The first is a constraint and the second an implementation detail.
[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.