Question

I am learning to create Use Case diagrams using the UML specification, but I have a couple of doubts about Use Case relationships which I cannot solve on my own.

My question regards two different situations:

  1. the completion of a specific Use Case is a pre-condition for the execution of another Use Case. I have seen in some article that a "precedes" connector is suggested, but I don't find anything similar in UML ("precedes" and "invokes" relationship should be defined in the OML specification). The "include" relationship of the UML 2.5 specification seems suitable in some scenarios, but not in all of them.
  2. there is an alternative (i.e. optional) flow during the execution of a Use Case, which can also be identified as a different Use Case which is meaningful independently. Reading the "exclude" relationship description, I understand that "the extending UseCase typically defines behavior that may not necessarily be meaningful by itself". Also, some articles says that "The extending use case is dependent on the extended (base) use case" (i.e. doesn't make much sense on its own). I'm not sure that "extend" is the proper relationship in such a situation.

I have faced both situations while designing the same diagram, thus I will report it here for completeness and a better understanding (I haven't already included all the system Use Cases in the diagram):

  1. The User must be logged-in the system before re-scheduling a booking (some articles suggest this to be an "include" relationship), and the User must be viewing the booking to "trigger" the re-scheduling Use Case (this is more close to a "precedes").
  2. If no suitable alternatives are available during re-scheduling, the User should be able to Delete the current booking (instead of re-scheduling it).

Booking System UML Diagram

Was it helpful?

Solution

Use-cases are not intended to have any sequencing between them.

Use-cases are meant to represent interactions with the system that are of value for the actors (i.e. use cases correspond to goals of the actors). UC are in no way detailed specifications of the actions that will happen and their owrder. It's just a placeholder for such specifications.

Use cases are in principle independent from each other, with the exception of the include and the extend relation, which are intended to promote reuse of common behaviors/sub-goals/interactions.

If you want to sequence behaviors, you should consider UML activitiy diagrams or BPMN diagrams.

Licensed under: CC-BY-SA with attribution
scroll top