I am going to design a system that has a login facility. After login the logged user can do several things so is it needed to include login usecase by that several usecases?
In most cases, it will only clutter up your diagrams. Login is neither complex (*) nor does it give you much added value as a use case. In your textual document that includes the use cases with description, include as a prerequisite a list of features that require a successful login. Easier to track and to test.
(*) In regards to the expected outcome from the user's perspective. Login could be of an arbitrary technical complexity but that is irrelevant for the use case diagram.
Related
I am new to object oriented design and I wanted to do my first ever UML use case Diagram on a simple application which contains toolbar on the top left corner. The toolbar is called files and when the user clicks on it,a drop down menu is opened with options to open a slide,save slide,make new slide and exit the application.
My question is, am I doing it correct with Use-Case inheritance(Generalization) ?
This is my diagram.
I am sorry to disapoint you, but I have to tell you that this practice is just plain wrong:
From the point of view of the semantics, the use-case specialization means that Open presentation is a special form of Check file, and Save file as well, and that the actor could use them interchangeably and independently. But this cannot be what you mean: exiting a presentation is at best a sub-part of checking a file
From the point of view of the purpose, a use-case should represent a user goal. It's part of the problem space, i.e. what the user wants to achieve. It's not part of the solution space, i.e. how the user will achieve it. A toolbar is not a goal: it's a user-interface element.
From the engineering practice perspective, use-case should not be used for user-interface design. It's not my own statement, but that of Jacobson, Booch and Rumbaugh, the founding fathers of UML:
The problem is that the [use-case] descriptions often contain implicit decisions about user-interfaces. Later, when the user interface designers suggest suitable user-interfaces for the use-case , they may be limited by those decisions.
in The unified software development process, page 164
So in conclusion, it's a bad idea to start use-cases from the user-interface. It locks you into your own design and ignores the user experience. You should focus instead only on the user needs. THe same use-case could then be used whether you'll implement it using a GUI interface, a chatbot interface, or a a voice-based interface.
While drawing Use Case diagram, one thing you should focus on is, the actual meaning of it and the purpose of drawing it.
A Use Case refers to what the users in respect of their type are able to do in your System... Anything inside the boundary is what system is capable of doing or what it can provide as a service to its users.
While naming the use cases, you should only use verbs and actions, for example:
1- Login | 2- Submit a Request | 3- Update Profile Description
You should avoid any nouns in them.
There are several relationships that exist in a Use Case Diagram among use cases, and a relationship among actors and use cases of the system, And They are as follows:
Association: the only relationship that can exist between an actor and a use case; Which says the actor is initiator of this use case, or is the one who is caple of operating the use case.
In the example above, User is caple of loggin in and submitting a complaint.
Include: Use Cases can include one or more use cases. When a use case includes another use case, it means the included use case or use cases happen all the time and are part of the initial use case.
Paying fees is included, because user has to pay the fees in signing up process, it has to be done, and it's part of the baseline path of the scenario.
Extend: When a use case is not happening all the time, and is part of your alternative path ( Alternative path of the complete scnario for this use case ), the use case should be extended to the base use case.
Forget password is extended to Login use case, because it doesn't happen all the time, and it's part of a alternative path of Login scenario.
Generalization: When there exist several different ways that a use case can be performed and completed, we use generalization. The inheritent use cases should all be of the same type as the inherited use case.
Submitting a complaint can be done in several different ways, in this case, we need to seprate each use case and inherit from from the submit a complaint use case which includes paying fees, this shows that, paying fees is a part of every type of complaint which is submitted.
I'm making a website where the visitor can:
View posts.
Only use regular or Facebook registration if they're not signed in.
Only login with Facebook if they've registered with Facebook.
Only use regular login or password reset if they've registered in the regular way.
Only create posts or unregister if they're authenticated.
I don't understand how I should model the different use-cases available for the visitor. Since an unregistered visitor can become registered visitor and a registered visitor can become an unregistered visitor, they can do the same thing on the site, they just take different paths.
Are these conditions important for a use-case diagram? Is it too specific to say that regular registration requires many fields to be filled in, while Facebook registration only requires the visitor to choose a username?
Can a use-case extend itself? Like if the registration fails, the visitor repeats the registration again.
Edit: I made a guess how to do the diagram:
Edit 2: Or maybe simpler like this?
As #granier said, Your second model is far better and #Thomas Kilian's points are remakable.
I want to say your mistakes and offer a new Use Case Diagram. I think there are some mistakes in your models (Logically and Practically):
Too detailed Use Case Diagram (model 1) (please see my previous post TIPS here)
Username is not Use Case.
There is not extend relationship between Login and Reset Password. (model 2)
Login associated with registered user? All users can trigger Login Use Case (even successful or not).
Wrong uses of include and extend and inheritance relationships (model 1).
Please consider my offered Use Case Diagram:
Additionally, you can add pre-conditions and post-conditions to your use case documentation. But, they do not change the Use Cases.
Your second model is far better. Use Cases generalization is not used often even in specification an exemple is provided. .
Since the user should be able to register, the actor "Unregistered User" could be removed. No ?
I use Use Cases generalization in one case only : when i want that several Use Cases get the same includes or extension.
There is nothing wrong with showing constraints as you did it. What I do is usually to create an overview diagram like your #2. And then focusing on single use cases showing just their relations to actors and requirements - and eventually constraints derived from the latter.
Don't fall in the trap of functional decomposition and avoid <<include>>/<<extend>> or even worse generalizations. Use cases are not used to decompose functional parts but synthesize them. A use case shows a single added value the system under consideration delivers to one of its actors.
Login is no use case since it has no added value. It is a constraint which you can attach to use cases.
As always: the UML specs are no good read to understand Use Case synthesis. It's written by eggheads with little business background. Look into Bittner/Spence instead.
I'm developing a web application and I'm on the design stage. In the use cases, users can view their profile on a certain page, and they can also update their profile information from that page. Now I wonder if the Update Profile operation extend the View Profile operation in my case?
Simply speaking: do not use extend or include with use cases. A single use case bubble represents a unique added value the system under consideration returns to the actor. If you can not tell that something is added value, it is not an use case. Include/extend are in most cases used as functional decomposition. But use cases are synthesized, which is the exact opposite.
In your case (and where it comes to CRUD) think of what is behind the scenes. Here it is dealing with a profile. So you could call it Maintain Profile which includes (in internal steps) the viewing and editing. Usually you can simply constrain functional parts. Furthermore your system description will be more lucid when using less bubbles. Remember: if your use cases start looking like spider webs, your system design is most likely wrong.
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.
I want to use package to group similar use cases. There is a problem about the included login use case, it make the graph not well presented. If I include the login use case in every package, I think it's wrong. Should I remove the login use case or remain?
Create another package "Common things" or "Support" or something like that and put "Login" and eventually other reusable use cases there. You will probably have some more commonly used use cases (like "Print report", "Logout", etc).
Than make all other packages dependent on that one:
This is a common practice of keeping your use cases nicely organized.
In this particular case of "login" I would recommend you not to "include" it in other use cases, but rather to keep it isolated and put the precondition ("User has been logged on to system") in all other use cases. This makes your model much cleaner and easier to follow, keeps the dependency and relationships count low, etc. Just imagine your diagram without this "includes" - looks better, right? :)
If you decide to do it this way, keep the same packages I suggested, but remove the dependencies (as the "login" is not included any more), unless there are other included/extended UCs that justify the dependency.
Login is not a UseCase at level of detail you presented in the diagram. Just remove Login Usecase and your diagram will be correct.
By usecase definition in UML. UseCase represents usefull functionality of system. Login is not a functionality from this point of view, but it is precondition to execute usecases you defined. It means, user must be logged on in order to interract with system within UseCase eecution.