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.
Related
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.
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 wondering if my use case diagram is about right and if anyone could give me some pointers if it's not.
It's for an application where users can login (always required). When they login they see a list with posts which they can up or downvote (like reddit). When selecting a post they can place and delete(only their own) comments.
The user that's logged in can place posts when logged in, but also has a button to view posts they've already placed where they can be edited and deleted.
Finally there's an admin that can delete inappropriate posts and comments.
Am I supposed to define that users can only edit and delete their own posts and comments? If so, how do I do that? Perhaps a different actor?
Thanks in advance!
There are a couple of flaws in your UCs.
Login is not a UC at all (it does not add any value to the actor). It is a constraint you may apply to UCs.
Wrong username/pw is no UC, of course. It's some message that will pop up somewhere.
Register is a UC on it's own. Connect it directly to User.
Using generalization with UC is not a good idea since it will bring in a lot of stuff for discussion. Leave it at the Manage level and describe inside the UC what this means.
<<include>> is usually used the wrong way (namely for functional decomposition). And you are doing that too. So leave it away, concentrate on the basic UC Manage comments and connect that directly with the actor.
If for some reason you need to describe some order for UCs you can use pre-conditions inside the UCs.
Remember that you cannot model everything using use case diagram. A single UC is a set of action flows that provide a specific business result. You can provide details on limitations (e.g. condition that you can manage only your own comments) in a description of UC (either modelled by activity or sequence diagram or simply in a written description) but not on UC diagram.
As the commenting is optional in your system, definitely you've used incorrect relationship. include means that the included UC will be always executed when executing including UC. In your case this is up to a decision of a user which means you should use extends instead (and of course in this case the relationship is in the opposite direction). See 18.1.3.2 (second paragraph) and 18.1.3.3 (first paragraph). You can also find confirmation of that in almost any book about UML based analysis (e.g. Howard Podeswa's "UML for the business analyst" to name one)
Besides that I agree with the list of flaws given by Thomas Kilian.
I'm trying to write an use for shopping online . Customer can search for their desired item and add them to the shopping cart,but when they decide to check out, they need to log in with their account. But what happen if customer already logged in ? Is my diagram still correct ? If not, How can I modify it ?
Any use case must be connected to some actor(s). So, you should add connections.
The CheckOut use case is strange and inunderstandable. I don't know any action in net stores, that includes both login and payment. If you mean ordering, the login or payment are additional separate use cases, that are connected to ordering by some conditions that could be described as states.
Don't forget, you can't show sequences of actions and states by use cases elements only. If you have a small use case diagram, you could include state machine diagrams in it, but here it is not good - You have totally forgotten the admin and seller actors and their use cases, so the full use case diagram will be too large to add something extra in it. Describe sequences about logging in additional State Machine diagrams.
You are trying to use the use case diagram as a workflow editor, which is incorrect.
Use case diagrams are used to indicate the actions that a user can take to accomplish something. They do not represent the sequence of these actions. Each use case starts from a specific user action, and not as a side effect of another use case.
In your diagram, the "Search" use case is fine, but the display of the result is part of that use case. It would not be very useful if the system would just display a "search complete" result and then force the user to do some action to view the result... Although you have an <<include>> relationship, that it not what it means.
One example for <<include>> is one for a Login use case. The Customer could login on their own before doing anything else or the login could be triggered by another use case, such as Check Out. Login would therefore be a use case on its own and it would also be <<include>> by the Check Out use case.
Add to Cart is a use case that should be triggered directly by the Customer. It is not something that is triggered automatically - the Customer needs to do something.
The same applies to the Make Payment use case. I would think that the Customer needs to perform an explicit action in order to pay.
I'm setting the use cases of a project, here are some of the details :
My question is two parts :
first one :
I have an actor user.
The user can register on the website.
He can login, view profile, edit password.
Regarding the previous use cases, I'm confused how to visualize the use cases in the diagram, I was thinking it might be done like the following :
Create a use case "Manage Profile" and connect the other use cases "View Profile,Edit password, etc..." to it with a generalize relationship. and then connect that use case to the "loginCheck" use case with a "include relationship". The actor will indicate "manage profile".
Create a sub-system "Profile" and set the use cases related to within it. then connect it to "loginCheck" with "include relationship". The actor will indicate each use case.
second one :
The user can Add bet : there are some types of bets:
mutual bet :
1- single bets.
2- combination bets
long term bets
championship bets
Should I create a general use case "AddBet" and extend the other types to it.
I can't upload photo directly because I'm new .
First of all, For me I saw a lot of "link" inside your diagram which seems to be use in a wrong way. Maybe you can take a look at some UML ressources and more specifically, association, generalization, include and extend links... BTW I am just curious to know which tool do you use for this? Visio or ArgoUML?
So now concerning your(s) question(s).
When you want to associate an actor to an usecase you have to create an association between them not a generalization
If you want to specifiy that an "manage profile" use case can include (or not) changing password, view its profile, etc for this I would use an extend link.
For modelling the fact that an given use case mandatory include another one I would use include relationship.
the creation of an "add bet" use case "exntended" by the other one would indicate that you have a lot in commmon between all this possible bet.
Please take a look at my screenshots and let discuss about it.
On the Use case diag you should have only actors, visually different systems (such as terminal, client computer, server computer or Profile management system, Betting system ) and real-life actions(use cases).
Systems are shown as blocks, actors as people and use cases as ovals that connect sides of the action.
You should Profile Management as a system, as a protagonist in dialogue user-system. And you'll see, that Mobile bank is NOT a use case, is not an action. Maybe, it is another subsystem, or maybe simply won't belong there.
On your other diagram obviously different sorts of bets are descendents of the "bet" use case. They do not simply extend it.
You have many use cases not connecter to anybody. WHO does these actions? It is the target of UC diagram to show it.