1

My colleagues and me are not really sure how to model use case, 3 of us each came to different solution, you can see each image bellow, they are simplified versions of what we are facing. We are just starting to work on serious projects and no one of us has much experience so we want to learn from start what is best practice in this situation.

We have web app that has some portion of site accessible to every user while other parts require login, now we are not really sure what is proper way of writing use case for that. My idea was to separate user to guest user and authenticated user, this way our use case won't get messy with bunch of include relations(we got much more use cases than presented here).

This is what I have done:

In my opinion is most understandable and scalable as it clearly separates two kind of users. My use case idea

Another possible approach:

This seems good as well, more understandable than last one when we have more use cases Another use case idea

And last one:

This is closest to UML specification that we learnt on university, but it starts to look really messy once we add more use cases, lines start to cross each other and its hard to see what is what. Another use case idea

Our question is what is best way to write use case diagram in this situation?

FilipRistic
  • 2,661
  • 4
  • 22
  • 31

3 Answers3

2

You should use the first approach with the separate use cases and actors.

You could possibly add a precondition to Use Case A and Use Case B saying something like: The user must be authenticated.

The postcondition of the Login use case could then read: The user is authenticated. This ties your use cases to the result of the Login use case rather then to the actual use case.
If tomorrow you create a new use case that has the same postcondition as the Login use case, you don't need to redesign all the other use cases that include the Login use case (or worse are included by the Login use case)

In this case it all seems obvious from the actor names only, so you could even consider leaving it out altogether.

Geert Bellekens
  • 12,788
  • 2
  • 23
  • 50
1

Use neither of your approaches! Login is no use case at all since it adds no value. Use a constraint { needs to be logged on} for use cases where authentication is needed.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Thanks, just one more question, should that constraint connect actor with use case or 2 use cases or it doesn't really matter and can be used in both ways? – FilipRistic Mar 28 '18 at 13:16
  • The constraint can be either connected to the UC (so everyone needs authentication) or to the connector between UC and Actor (means: applies only to that specific Actor). Generally: UC show added value. If you can't see any, it's no UC. – qwerty_so Mar 28 '18 at 13:47
  • That makes sense, thank you again you helped me a lot. – FilipRistic Mar 28 '18 at 20:46
-1

Use approach two.For understanding split the use cases in parts.As for approach two you can show user login and in another use case u can show what authenticated user can do.

raja
  • 83
  • 2
  • 3
  • 16