8

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: use-case diagram

Edit 2: Or maybe simpler like this? enter image description here

user1989781
  • 119
  • 1
  • 2
  • 8

3 Answers3

4

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):

  1. Too detailed Use Case Diagram (model 1) (please see my previous post TIPS here)
  2. Username is not Use Case.
  3. There is not extend relationship between Login and Reset Password. (model 2)
  4. Login associated with registered user? All users can trigger Login Use Case (even successful or not).
  5. Wrong uses of include and extend and inheritance relationships (model 1).

Please consider my offered Use Case Diagram:

enter image description here

Additionally, you can add pre-conditions and post-conditions to your use case documentation. But, they do not change the Use Cases.

Gholamali Irani
  • 4,391
  • 6
  • 28
  • 59
2

Your second model is far better. Use Cases generalization is not used often even in specification an exemple is provided. use cases with generalization.

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.

granier
  • 1,739
  • 13
  • 25
  • Both registered and unregistered users can view posts. Basically what I want to show is that being registered is not an requirement to view posts, am I allowed to do that? – user1989781 Jan 02 '18 at 12:00
  • Your schema is rigth from an UML point of view, so you are allowed to do that. But if User can activate the Use Cases View post and Register, that's mean that an unregistered user can view posts and, for me, Unregistered User is not needed. – granier Jan 02 '18 at 14:07
0

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.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86
  • Let's say I have a use case that's called "create post" and the creator of the post can also "change post". Would it make sense to extend here or should I rather split them into 2 different use-cases? – user1989781 Jan 02 '18 at 11:50
  • Does this make sense? https://i.imgur.com/RzJByUc.png It looks very bloated, maybe some of these are not valid use-cases? – user1989781 Jan 02 '18 at 12:24
  • You could simply sub-divide that into several diagrams according to business domains (e.g. one for management, one for user interactions). Or you use boundaries to show these domains. – qwerty_so Jan 02 '18 at 12:55
  • Re. "extend": CRUD is a borderline and you can see it both ways. Either you have a single "Manage " or single "C ", "R ", etc. If one of those is predominant it's better to make it a stand-alone UC. Otherwise a single CRUD use case is better. YMMV – qwerty_so Jan 02 '18 at 12:58