Search code examples
umlsequence-diagramuser-interaction

System sequence diagram - Can system request input from actor?

in uml - system sequence diagram, can the system ask input from the actor (see attached picture)

example

In my example, the scenario is: system is prompting a confirmation input from user and user is to enter in the input.

Wondering if this is the correct representation for it? I asked as usually I have done it the other way round, in which actor gives input to the system and system return the output based on input...

Solution

  • Preliminary remark

    The practice of showing an actor in an interaction diagram is well accepted and quite common.

    Nevertheless, in principle, an UML interaction diagram such as a sequence diagram, should show interactions between lifelines within an enclosing classifier:

    • The actor being external to your system, it’s not a part of any enclosing classifier in your system.
    • As a consequence, this is valid UML only if the scope of your model is larger than the IT system, i.e. you model the organisatiin that uses your IT system.
    • Moreover the message semantic is not clearly defined for human participants, which is exactly the issue behind your question

    Be consistent

    If you choose to go on with your modeling approach and consider the actor as any other classifier, then your actor instance should behave as any other object.

    The flow of messages shows which object is the sender of the message and which object responds. You should consistently keep this logic, as you did in your diagram. It will be btw one of the rare place on your model where you can show that the system is at the origin of this specific interaction and not the user. (hint: don’t forget the execution specification on the lifeline: it’ll increase the readability)

    If you would materialize the free-will of the actor by an arrow/message in the opposite direction, you would only increase the ambiguity further: this would give the impression that the actor is at the initiative of the message, and that the actor could send a completely different message instead. And I’m not sure that your system is designed for responding to arbitrary messages from the user.

    Another alternative?

    A less ambiguous alternative could be to show the interaction between a system core element and an element that represents the UI: the UI element acts as proxy for the user, but since it’s an object like any other, the interpretation of message flows is unambiguous.

    This is one of the idea behind the ECB decomposition, the C being a use-case specific controller (so it links this interaction to the requirements) and the B being the UI boundary exposed to a specific kind of actors (without entering into UI details).