2

I have this kind of situation where I have multiple actors which share the same use case.

I cannot figure out from which point of view I should write the flow of events and describe the sequence diagram of this specific use case, having more than one single actor.

aculf
  • 31
  • 3
  • You should write scenario from the point of view of the use case – Geert Bellekens Jan 23 '20 at 09:27
  • How can I properly do it? I've always wrote from the actor's point of view. – aculf Jan 23 '20 at 09:34
  • 1
    Traditionally you write scenario's as conversation between the actor and the system: 1) The Actor does xxx 2) The system does yyy 3 ) The actor does zzz etc... without specifying which of the (primary) actors exactly. Adding or removing a (primary) actor should not change the use case. – Geert Bellekens Jan 23 '20 at 10:37
  • Perfect. Thank you! – aculf Jan 23 '20 at 10:40

1 Answers1

2

You: I have multiple actors which share the same use case.
... from which point of view I should write the flow of events

Use-cases are goal-oriented. They are not supposed to be a functional decomposition nor a sequence of actions. It's not me, but Ivar Jacobson, the inventor of use-cases, in Use-Case 2.0:

A use case is all the ways of using a system to achieve a particular goal for a particular user.
(Page 4)

So use-cases are meant to provide the big picture. Your use-case diagram should identify these independent goals. Of course, behind each use case, you have some narrative that describe the interaction between the actors and the use-case:

The purpose of a use-case narrative is to tell the story of how the system and its actors work together to achieve a particular goal. (...)
Use-case narratives can be developed at different levels of detail ranging from a simple outline, identifying the basic flow and the most important variants, through to a comprehensive, highly detailed specification
(Page 47)

One way of describing this flow, is how Geert Bellekens explained in the comments: describing the scenario telling who does what in which order. A variant of this presentation is a tabular form: a column for the actor actions and a column for the actor actions.

Now, if you're at the beginning of the design, and especially if you have several actors, this kind of UC description forces you to make a decision about the way you design the interactions. A more creative variant is to describe essential use-cases: instead of describing the flow of event, you make a table describing mapping more in detail the intents (i.e. intentions) of the actors (in one or n columns) to the corresponding responsibilities of the system (in a separate column).

You can then start to think about possible sequences, but also about alternative sequences that could provide a better user experience or a more optimal flow of information. The flexibility is so high that you could even design voice-driven or NLP driven interfaces in which the sequence is not predetermined but could be different for each use-case execution.

Christophe
  • 68,716
  • 7
  • 72
  • 138