4

Here is my UML Diagram:

'Unauthorised User', 'Authorised User' and 'Admin' actors on one side, a set of action bubbles they connect to, and then a 'Check Credentials' that funnel some of the action into a Credentials Database actor

Are the "post answer" and "vote" actions an extension of browsing? Since you have to SELECT / VIEW (?) a question in order to answer or vote. Or can I simply say in my use case text that you must have selected a question as a precondition? Should I also change Browsing to search only?

Diagram info

I try to depict a basic uml use case diagram for a system really similar to the stackexchange websites. Just consider a simplified version. I know there are many ways to draw these diagrams but I did my best to declutter and keep only the high level functionalities.

Authorised user is someone who is logged in. Let's suppose that you can only browse and search for questions if you are not logged in. Credentials are mostly for checking the reputation.

Improve this question
7
  • 1
    Check credentials is no use case but a function. You should instead attach a constraint to the according UCs like { must be logged on}.
    – user188153
    Commented Nov 12, 2020 at 11:58
  • When I try to downvote here on stack, I get a notification saying that I don't have enough reputation. Obviously my reputation was stored somewhere and was smaller than the required. That is the reason why I included a database that checks who I am and what my reputation is. It seemed important from the database perspective. What is the mistake in this line of thought?
    – Dots
    Commented Nov 12, 2020 at 16:56
  • 1
    I have no idea what you are talking about and how this is related to your question.
    – user188153
    Commented Nov 12, 2020 at 17:33
  • The system I have drawn is very similar to stackexchange websites. Essentially I try to replicate it. A database needs a way to know who posted a question, who voted.. etc. (but it doesn't need to know who is browsing just browsing anonymously)
    – Dots
    Commented Nov 12, 2020 at 17:37
  • Ok, but what is the issue then? Is it that a DV need authorization? From UC perspective that's just a constraint.
    – user188153
    Commented Nov 12, 2020 at 17:39

1 Answer 1

Reset to default
0

To answer the question in the title first, your use-case diagram is entirely correct.

To be honest, I am missing one use-case and that is a "login" use-case in which an unauthorized user becomes an authorized user.

Are "post answer" and "vote" an extension of browsing? Since you have to SELECT / VIEW (?) a question in order to answer or vote. Or can I simply say in my use case text that you must have selected a question as a precondition?

If you can imagine another way of reaching a question's page other than browsing, for example if somebody sends you a direct link to a question, then "post answer" and "vote" can be used completely independently of browsing. This means they are not extensions.

You can indeed say in the use case text that you must be viewing the question as a precondition for being able to perform that use-case.

Should I also change Browsing to search only?

I don't see any reason to replace Browsing with Search, but you can have them as independent use-cases.

Let's suppose that you can only browse and search for questions if you are not logged in.

Based on your diagram, my assumption was that both authorized (logged-in) and unauthorized (not logged-in) users can browse and that you don't need any credentials/reputation to do so.

Improve this answer
4
  • 2
    Login is no use case at all since it does not bring any added value. It's simply a constraint applied to use cases.
    – user188153
    Commented Nov 12, 2020 at 11:56
  • 3
    "Login" isn't usually a use case. A good use case describes a series of steps to achieve a goal. Simply logging into the system isn't usually a goal of a user. When it is shown, it can be an include relationship with other use cases, but I've found that this could clutter up the diagram. There should be textual descriptions of use cases, so describing the login steps and linking it to the relevant use cases is best done there rather than in the diagram.
    – Thomas Owens ♦
    Commented Nov 12, 2020 at 12:02
  • 1
    @qwerty_so, the fact that here the actors are differentiated between authenticated an unauthenticated users makes that "login" does bring a user added value: they can put themselves in the set of authenticated users and get another set of use-cases available to them. If the differentiation in actors wasn't made, then "login" could be part of the flow of the use-case(s) and left out of the diagram.
    – Bart van Ingen Schenau
    Commented Nov 12, 2020 at 12:56
  • 1
    Well, the term "added value" seems to be interpretable. Getting authorization is nothing I would call added value.
    – user188153
    Commented Nov 12, 2020 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.