I've been studying use case diagrams for a little while now and i've created my own to model one for a mobile banking system. However, in my model there is one thing that i am unsure how to accomplish. In the picture below, you can see the user. I dragged arrows to the subusers(pincode user, secure key device user, e-legitimation user). By this solution I am not sure if the subusers will get access to the login circle or not, because they don't have any arrows going to it.
So I guess my question is: Will the subusers(pincode user, secure key device user, e-legitimation user) be able to log in with this diagram or not?
Also will the current diagram force the subusers to login or are they just able to pass the login? Is an include arrow needed somewhere here perhaps?
According to your diagram your subusers can use login usecase but this login usecase is not required by any other usecases.
For modeling the fact taht a usecase A "needs" another usecase B you have to create an include from B to A.
RB
Just a little remark: the display of yours include and generalization links look wrong for me which is ironic when using a graphical language :-D
Related
In this sequence diagram I am trying to show:
Admin can login.
If login success -> redirect to admin dashboard
Once at admin dashboard, admin can click UI buttons to [ edit, view & delete ] a user
I am not sure if this diagram displays this correctly. Is it okay just to use Boundary "Admin Panel" to show different options or should each option be it's own boundary? e.g. boundary for edit user, delete user & view user.
Any feedback to improve this to make it clearer would be really appreciated
Thanks in advance.
This diagram shows too much and in a misleading way.
This diagram says that the Admin will login, then edit a user, the view a user, then delete a user. But I don’t think that you want to say that the Admin will always do all these actions and in this precise order. This is why this diagram is misleading.
Moreover, I don’t think that when doing the three in this order there would be anything different from the case it would be done in a different order. So there’s no need to show all the possibilities in a single diagram.
So, my advice:
cut this diagram in 4 different interactions: login, edit, view, and delete. All but the first one would have as precondition that user is logged in. In fact I make more assertive here what was already suggested for your registration scenario in your earlier question today
UML is neutral about what you can or should represent with the sequence diagram. Nevertheless, it is best kept for explaining interactions that are not obvious. Using it as a kind if visual programming for obvious interactions may be time-consuming modelling that tends to quickly be obsolete.
also, sequence diagrams are not the best way for modelling user interface. If you model your user interface with a wireframe storyboard (see links in the edit of my answer to your earlier question), you could then link the relevant sequence diagram to the relevant user interface design. The advantage is that you could verify with users that UI latch expectations based on the wireframe, but document for the developers what happens behind the scene, thus allowing to better understand how the short sequence contributed to the whole.
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 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.
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 have a few questions regarding use-case diagram:
If my system has register/login use-case for guest, should it be enabled for admin, user (i just wanna clarify, if i have login system, do i assume that admin, user etc. are people who already logged in to system so i skip them with logging thing)?
If my system has a student actor, that is signing for individual seminars/courses, do i have (or am i allowed) to make use-case for ,,taking class'' after singing for them, and should there be relations between those 2
Should my teacher inherit from student actor, since he can browse courses as well? (and so on admin?)
Is my payment setup correct?
Remember that these are roles not people. An admin can be a guest, so long as they behave entirely like a guess, no special functions or rules. However, during log-in the user role could change, become admin. Note you are in some sense missing authenticate user, each use-case that requires security should include it, generally not extend.
Only if it interacts with the system, example, triggers an auto completion or is tracked in some way there of. Relations are not needed generally, associations could help communicate something that is ambiguous, but I am not sure what the would be in this case.
Nope, really then the role is any user could browse courses once they are authenticated. You could have students, admins, and teachers be sub-types of authenticated or associated person, etc.
Depends. Firstly you never pay and sign-up at the same time, so from a user standpoint that is broken. There are other ways in UML to connect this constraint of paying for courses. Process diagram, state diagram, etc. Because payment is really a long running transaction which can be hard to pin down. I would personally show the student and the external payment system interacting with the "payment" use cases.
Remember unless you are generating code most of the time UML is about communication so knowing your audience. Do not be afraid to use comments or constraints, if this is homework, use a constraint and get some real points. Maybe even put a constraint on the sign and pay course use cases.
If you want the admin to be able to log-in then he would have a use case for that. I agree that he most likely won't be registering, so maybe you want to break the register/log-in into two use cases?
You do not have to make a "Take Class" use case. Only make it, if that's how the user will interact with the system. My guess is that he won't be "taking" the class with the system, in which case it won't be a use case of the system.
I would think that you wouldn't want to inherit from student. First of all, from a realistic stand-point, it doesn't make sense. That would mean a teacher is-a student. You could extract that behavior to another parent class, but that might make the hierarchy too large and confusing.
If you are asking whether it is correct to say "sign for course" includes "pay for course," then maybe, it's probably better to use extend.
Another suggestion. The black arrow (usually means "dependency" in UML) you have between Actors and Use Cases, should probably be bi-directional, non-arrowed, line (this is usually called "association") At least that is what the UML standard says.