I am trying to design a Use Case Diagram for an app like Stack Overflow. I have tried to add some basic functionalities in this diagram.
I want to improve this diagram to include an exhaustive list of all the features of Stack Overflow, but have no idea of how to do so. Also, should there be another actor for Admin who manages user accounts, or not? And if we are asked for Use Cases, should we describe the inner functionalities, preconditions and postconditions of each use case separately?
What if other than these two actors, I decide to add a Mediator actor too, who forwards the problems to the mentor, and when a mentor solves it, it is the responsibility of mediator to mark it solved?
If you want to map all the use cases and actors in StackOverflow you can take the Tour and search for some known Q&A in the Help Center.
And yes, if you want to make an exhaustive list, then you should include every actor - including Admin and Mediator. However, I'm not sure that you can figure out the admin's use cases (or other managing roles in this platform) since you are a user and it isn't reflected to you.
If there are use-cases that are unique to a specific actor, then you should add that actor to the diagram - and use inheritance! (When actor b has all the cases of a plus more, then b is inherits a) - this one is called "Generalization of an Actor" (you can google search some examples).
As for your other questions:
Please note that Use Case Diagram is an addition to the Use Case Modeling, more like an appendix. When you are modeling - you explain lots of details about the use case (some of them you've mentioned), such as: Primary actor, Scope, User Story, Postconditions, Preconditions, Triggers, Flow, and many more... There are a lot of templates actually. You can review them Here.
You do not describe visually* any preconditions or post-conditions, however, you have some tools that can describe which cases are **included in a specific case (in order to use feature Y - you should go over feature X). Or, which cases extends other cases (while you are using feature X, you can (but not have to) use feature Y).
Hope it helped :)
I encourage you to use a modeler rather than to draw your diagram by hand.
I want to improve this diagram to include an exhaustive list of all the features of Stack Overflow
The exhaustive list of the features of S.O. is certainly very be long, and you will have problem too see it because surely some parts are hidden to 'standard' users. What is your goal, to model S.O. or to use it as an exercise ? On the second case it is not necessary to manage all
should there be another actor for Admin who manages user accounts, or not?
Sure they are admins or 'super' users.
if we are asked for Use Cases, should we describe the inner functionalities, preconditions and postconditions of each use case separately?
A use case is not only an ellipse in a diagram, and a model is not ajust a list of diagrams. Yes each UC must have its description and the possible pre/post conditions etc
What if other than these two actors, I decide to add a Mediator actor too ...
I don't know if there are mediators, but I am quite surprised by the 'mentor' whose role is to answer. If you have him you make a separation between the roles consisting to ask and to answer, so the other role cannot be the very general user but probably must be more specific
You will have lot of remarks about the UC login for sure ;-)
Related
I have seen examples of people representing CRUD use cases in use case diagrams as "Manage X", but I wanted to know whether I can use a generalisation like the one in the screenshot to group many of them.
My intention is that "manage item" applies to the current catalogue being browsed. Would this be fine?
Use case diagram:
Yes, you can use a generalization to convey the intent that the actor manages items, and that items can be of different kind.
But your diagram looks very detailed and appears to be more a user interface model rather than a real goal-oriented use-case. I.e it describes more the “how” than the “what”. This is not forbidden according to the UML specifications, but not advised, as it leads to complex diagrams, distracts the modeler from the user goals, and leads to a premature design of a user-interface, whereas other modeling techniques are better suited to ensure an optimal user experience.
See also this question, that addresses similar concerns but at a lower level of abstraction.
P.S - Unrelated thoughts: The diagram might create ambiguity, since it suggests on one side that browsing is specialized by types of items (browse X and browse Y), but at the same time it suggests that any browsing can be extended with managing any kind of items (manage X, manage Y). This could be one more symptom that the use case was created with some class design in mind and not centered on user goals
I want a use case - store information system. I am to present the owner's requirements on a use case diagram, incl. a customer who, after logging in, does shopping, and an admin, who after logging in, manages prices, etc.
Can I log into the system generalize from one use case - two actors combined with one use case (below)? How can I 'improve' the diagram?
UML does not specify the semantic when more than one actor is associated to the same use-case. It can mean for example that one of the actors only is involved without the other, that the two actors are involved at the same time, or that the two actors are involved one after the other.
For sure, actors and use-cases are classifiers. You can therefore use generalization of use-cases or of actors (as explained with an example here) .
But your diagram, while syntactically correct, has some issue:
First Admin account is not a use-case: it does not produce any observable results to the actor; it is an internal detail of the sytem. So it does not correspond to the UML criteria of a use-case.
Then, Login, Confirm password (and perhaps Checkout?) do not correspond to user goals. As explained here, this is not fundamentally wrong according to the UML specifications, but it is a bad practice. Use-cases are meant to describe actor goals, and not details of a process or a user interface.
Maybe i'm old school, but you should also surround the use-cases with a box representing the "subject", i.e. the system under consideration.
There's no special magic about it, UML Use Case describes a case and can have more than one user.
Maybe just moving the shared Use Cases next.
But, since Use Case diagrams support User Inheritance as if they were classes, maybe adding a generic abstract superclass alike GenericUser with the shared Use Cases, and subclass alike User and Admin with their own specific Use Cases would be useful.
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.
This question already has an answer here:
Have I to use the same actors for those extending or included use cases? [closed]
(1 answer)
Closed 6 years ago.
I am currently refreshing/altering my knowledge in software development because I will work in this area soon. We have learned a lot about UML diagrams and coding at University, but I have never brought it all together in a real Project. Therefore, I started to create a test web-app in Grails, and I wanted to begin with a requirements analysis and use cases too keep it close to reality.
My web-app should allow users to share recipes, find recipes and review recipes by other users. Every recipe has many ingredients, which are not just strings but rather entities so that calories, fat, protein and carbs can be used to automatically calculate nutrition facts of a certain recipe.
An ingredient can be added to the database by either a consumer or nutrition expert. If it is created by a consumer, it is only a "prospective" ingredient, meaning that it has to be verified by an administrator to become a "proper" ingredient -- otherwise it is marked, e.g. red text color.
This is my current use case diagram:
http://ubuntuone.com/0zDw9kEbj1BwtXjnCtxdwC
My question here is:
Can extending or included use cases be accessed independently? If I do it as in the screenshot, can AddProspectiveIngredient be used without going through the CreateRecipe use case? Same question for included use cases.
EDIT: I don't think this is a duplicate of this question. In the linked question (1), I ask if I have to use the same actor for extending and included use cases as in the extended or including use case. In this answer (2), however, I merely ask about reuse between use cases.
In (1) it is all about the actor, and I am very satsified with this answer, as I now understand that the primary actor of an extending use case will inevitably be a subclass of the primary actor of the extended use case.
(2) addresses reusability of extending and included use cases, but is not necessarily connected to actors. It is about reusing them in other use cases. So if I have two use case CreateRecipe (a) and AddIngredientToDatabase (b), where (b) extends (a), can I also extend a third use case with (b)? Here I also received my answer, that they can and should be reused.
Maybe the questions seem similar because I created them on the same day with the same example and the answers both mention actors, which make them seem as duplicates. As they are both answered and I am satisfied with both answers, why close the questions as "too broad" or "duplicates"? If it was answered succesfully with different answers, how can it be too broad or a duplicate?
I am also happy to rephrase them slightly to keep them open, if I am told what the core issues. More answers and comments on the topics are still interesting to me.
Can extending or included use cases be accessed independently?
They rather should be. It is a good and correct style. Use case is some activity conducted between one or more actors and system. You should try not to show here some inner operations, that are not connected to users. Nothing invisible to users can be shown here. USER cases, remember?
So, no inner structure here.
You can collect some cases in groups - subsystems. But it is not inner structure, they are not IT systems, they are simply common themes of activities, obvious for users. Such subsystems should get later at least common UI style.
As for logic that could be used by users, it can be shown on other diagrams. Many diagrams can exist on this level - State machines, Activities, Timing. But don't try to show processes on the Use case diagram, too.
So, I don't know how well have you interviewed the client, but you use case diagram looks almost correct. Only the AddProspectiveIngredient Use Case should get its user or more.
On a Use Case diagram can you show things that an actor cannot do, for example because they won't have permissions to do it?
Or is it just implied due to the fact that they won't have a line joining them to the particular use case?
If the Use Case you are diagramming is the case where an actor attempts to do something that is not permitted and is then denied, then yes, I would show it.
Otherwise, I would stick to only including things that are actually part of the use case.
No. An Actor would be connected to everything that he can do. If the Actor can't do it, then it's not shown.
This is what alternate paths are for. The basic path (a.k.a. happy path) will show what happens when the correct Actor initiates the Use Case. In the alternate paths you can show what happens if the wrong Actor attempts to initiate it.
You might model Role actors that can do the task. You could then have another use case that has the original actor attempting to acquire the given Role.
IMHO this question and most of the answers give a wrong impression about the way use cases should be used.
Use case was intended as a requirements technique that uses natural language. It is most and quite effective that way.
It can be a thoroughly destructive technique when it is combined with too much UML/modeling. Structured modeling of use case texts for example by modeling main and alternative flows using UML Activity Diagrams is a tried and tested way for example to create Use Cases of Mass Destruction.
A use case diagram can be useful but we should remember the purpose of use case as a technique which is first and foremost to identify the user goals a system should support. Subsequently we can capture more details using natural language in use case texts using main flow, alternative flows etc.
Using diagramming tools we can visualize some simple information:
- For each user goal we can create model element type Use Case.
- Show system boundary using a box for the system with use case elements in it.
- Create a relationship between actor and use case to show the actor has a particular goal against the system.
Keeping an up-to-date list of actors mapped to goals is however of secondary importance. Doing a stakeholder analysis, drawing up lists of actors is a means to identify the users goals. After user goals have been identified it is strictly speaking not longer necessary to keep the lists of actors around.
If we are asking questions about how to put user permissions in a use case model we are most likely trying to capture too much information. We should abstract model elements away so that the model does not try to answer/capture these type of detailed design questions.