1

I have seen on the internet many examples of use cases diagrams (in UML) as this one:

enter image description here

What I see is that the delete use case does not include the create use case. Even though I can't imagine deleting a user without creating it.

I wonder why it is still right to not use the include ? And I wonder when should I use it and when to not use it ?

Christophe
  • 68,716
  • 7
  • 72
  • 138
celia
  • 33
  • 10

2 Answers2

4

If there is Delete-User - - <<include>> - -> Create-User that means during the execution of the UC Delete-User the UC Create-User is also executed, and of course that has no sense.

The expected behavior can be :

  • Delete-User has the prerequisite Create-User was successfully executed for the same user and Delete-User was not already executed successfully for the same user (after the last Create-User then)
  • or Delete-User can be executed without prerequisite but if the user does not exist (Create-User was not executed successfully for the same user, or Delete-User was already executed for the same user after the last creation or the user) this is an error case
Christophe
  • 68,716
  • 7
  • 72
  • 138
bruno
  • 32,421
  • 7
  • 25
  • 37
  • `error case` means it's a certain flow of execution in the UC's course of events. So that's some behavior you don't show on the UC level itself. – qwerty_so Aug 25 '20 at 21:39
  • It still unclear, I think I see what you are trying to tell me but I don't see clear. What I understood is that it has no sense to execute the create whenever we want to delete. However, we need to create that user before we can delete it. – celia Aug 25 '20 at 23:40
  • @celia yes, *before* , not *during*, this is why there is no include. For the rest I cannot decide myself what the UC delete-user does because I am not the author of the diagram you give and the textual description of the UCs is not given, I can just give possibilities and this is what I did in my answer. Do you understand (may be also thank to the other answer) ? – bruno Aug 26 '20 at 07:05
  • Ahh ok I see, so in the diagram we speak about what is executed _during_ not before. But, in the textual description, we can give more details about the prerequisite. Right ? – celia Aug 26 '20 at 07:54
  • sure if there are prerequisite etc that must be described in the textual description, an UC cannot be just an ellipse in a diagram, like a book is not reduced to its table of content / chapter titles – bruno Aug 26 '20 at 08:37
  • Thanks a lot for your help, have a super great day. – celia Aug 26 '20 at 08:49
3

Bruno's excellent answer already explains why it's not a good idea to include Create into Delete, and what alternatives may be used to express the relation that you explained between the two use-cases.

But in case it helps, here another angle:

  • A use-case diagram does not represent a logical sequence of activities.
  • A use-case only represents a goal for an actor that motivates his/her interaction with the system independently of the other use-cases and the system's history. So, the simple fact that a sysAdmin may want at a moment in time to delete a User is sufficient for the use-case Delete to exist on its own.
  • include shows that a goal may include some other goals of interest for the user. Inclusion is not for functional decomposition where you'd break down what needs to be done in all the details. It's not either to show the sequential dependency. So for Delete, you shall not include what happens before, because happens-before is sequentiality. Inclusion only highlight some relevant sub-goals that are meaningful for the user and that the user always want to achieve when aiming at the larger goal.
  • finally, a use-case Delete may have perfect sense even if the use-case Create was never performed by any actor, for example because:
    • the new system took over a legacy database with all its past account, and the first thing that the SysAdmin will do in the new system, will be to clean-up the already existing old unused accounts before creating new ones.
    • the SysAdmin wants to Delete an account but finds out only during the interaction that the account didn't exist, was misspelled, or was already deleted. These possibilities are all be alternate flows that you would describe in the narrative of the the same use-case.
    • or if not Create use-case would be foreseen, because the user creation would be done automatically in the background (e.g. based on an SSO), without the actors being involved at all.
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • Thanks, for your answer it is even detailed and supports what I have understood from the comment before. However, how should I understand the include (order --include--> login). The user goal is to order not to login and he won't login while he orders. – celia Aug 26 '20 at 08:14
  • @celia The login is not really a user goal. It’s more a constraint for being identified for doing some things. This being said, even if would be a goal, the inclusion would mean that every time you’d order, you’d also do a login (which is certainly not true if you do two orders in a same login connection). – Christophe Aug 26 '20 at 08:22
  • Ok thanks a lot !! just a last question, if I do (Grant access -- include --> select user). To mean that every time I grant access I select the targeted user. It is still correct ? – celia Aug 26 '20 at 08:53
  • @celia yes, it is – Christophe Aug 26 '20 at 08:59
  • Thanks a lot, I finally get it. have a good super day – celia Aug 26 '20 at 09:02
  • @celia Glad that it could help :-) A nice day and plenty of success with your project – Christophe Aug 26 '20 at 09:03
  • Nice complement of my answer, UV – bruno Aug 26 '20 at 10:24