1

I want to model the following behaviour: When an administrator creates a blogpost, then it is something different compared to when an user creates a blogpost, as for example the moderator is involved in the create blogpost use case, as he verifies the blog post. However, when the administrator doesn't have his role as administrator, his blog posts also needs to be verified by a moderator, as he himself inherits the behaviour of the user.

This example below may only make sense if an administrator can remove his own role, when he doesn't want to use the system as administrator.

I hope this makes sense.

enter image description here

Christophe
  • 68,716
  • 7
  • 72
  • 138
Husky
  • 71
  • 1
  • 7
  • 1
    Too late for an answer, but this is only one UC where you have different scenarios inside being constrained by the type of actor starting the UC. – qwerty_so Jan 11 '21 at 23:50
  • 1
    @qwerty_so, it's never too late to answer ;-) I've seen cases when the later answer got multiple more upvotes than the original one. Especially for a person who learns, it is a good idea to have all aspects shown so if you think the accepted answer is insufficient, adding your own is an option. – Ister Jan 13 '21 at 11:07
  • @Ister No chance to compete against Christophe. Basically he elaborated on what I was commenting. As usual in best length. But yes, if I had a different opinion I would as well answer the other day ;-) – qwerty_so Jan 13 '21 at 19:35

1 Answers1

2

Keep it as simple as possible

You should not have twice the same use-case name to represent different behaviors in the same model. This is extremely confusing.

By the way, the UML specification do not defined what exactly is meant when multiple actors are related to the same use-case: it can be multiple actors each involved separately in different occurences of the use-case, but it can be as well be that all actors must be involved each time.

As a consequence, I'd suggest to keep a single Create blogpost use-case related to User and Moderator. You can still keep the Administrator being a specialization of User and use this specialization in the detailed description of the use-cases behaviors.

enter image description here

But not simpler as necessary

If you think that this does not express sufficiently accurately your situation, you have two possibilities.

  1. Keep a single Create blogpost use-case associated only to the more general User, and «extend» it with an additional Moderate blogpost use-case associated only with a Moderator. THis makes sense, because the moderation use-case is a goal of its own for a moderator, that it can be reused (e.g. could also be an extension to Update blogpost).
  2. Since actors and use-cases are both classifiers, you may also think imagine a use-case Create unmoderated blogpost being a specialization of a more general Create blogpost. However this requires some more precision about redefinitions, and is in my view less expressive that #1.

The first case would look like:

enter image description here

Additional thoughts

A Moderator is in principle also a User. By curiosity: what happens if a Moderator creates a blogpost: can he/she self modereate the own content? Or musta four eyes principle make sure that a different moderetor moderates this post ;-)

Christophe
  • 68,716
  • 7
  • 72
  • 138
  • 3
    An even better option in my IMO is to have two different use cases, but without the «extends». I can imagine that creating the blogpost and moderating the blogposts are separate activities that can happen at completely different times. `Moderate blogpost` could have a precondition stating that a draft blogpost exists. – Geert Bellekens Jan 12 '21 at 05:07
  • 1
    i was about to write the same as @Geert. Extension means you have variants in a UC. But these are more two really single different UCs. Well, I know this can be debated ;-) But in any case I just avoid extensions as they tend to introduce functional decomposition. – qwerty_so Jan 12 '21 at 08:59
  • 2
    @GeertBellekens Indeed, I agree. In fact I started to realize that my thinking was biased by the original UC when drawing the second diagram (see my orange note). Personally I would have I completely decoupled the two UC (i.e. moderator moderates every day a queue of pending blogposts, a goal that is independent from the blogpost creation). I nevertheless decided to just leave the hint in the note as it was and let OP chose how to best express the problem in the end. – Christophe Jan 12 '21 at 10:53
  • 1
    @qwerty_so I agree (more details in my answer to Geert) – Christophe Jan 12 '21 at 10:54
  • Thank you for the answers. I agree, that `Moderate blogpost` should be a different use case. I only wanted to show in this example that one use case has a slightly other procedure than the other one - Sorry for the confusion! – Husky Jan 12 '21 at 12:13