3

Is it correct for the user(actor) in sequence diagram to receive a message from object while<< UI>> is exist in the diagram

for example user will request to edit some data ..so the request will be sent from user to the UI which will pass it to the object that contain the data.. for example if I want to send reply to user saying "the edit has been done successfully " what I want to know is ( is it correct to send that message from the object to the user directly ?) or or the message should be sent to UI

sana
  • 41
  • 2
  • 2
    I think this is a great question, but could you perhaps add a few example diagrams to better explain your problem? As it stands, it is a bit unclear what you are talking about. – amon Aug 02 '18 at 06:31

1 Answers1

2

The theory

If you take the UML standard by the letter, a sequence diagram is an interaction diagram (clause 17.8 of the specs), and therefore represents interactions between elements of an enclosing classifier (clause 17.2.3.1), which means a class, a component or the system as a whole.

An actor does not belong to the system: it should therefore not appear as a lifeline. Typically, what should appear as a lifeline instead, is an instance of some classifier that belongs to the UI and that would notify the user of the information.

Therefore, this diagramming practice is formally incorrect.

Philosophical remark: a user does not offer a reliable interface and may react in an unforeseen or irrational manner to incoming messages ;-)

In practice

It is however a common and convenient practice to include an actor in a sequence diagram. After all, the UML standard sees the actor as a classifier (clause 18.1.2), although it doesn't belong to the system.

As this is not foreseen by the standard, there are no clear rules about what can be done and the applicable semantics. If you opt for this approach, you are therefore free to proceed as you want.

This is however a non standard use of UML. It can be an issue if valid UML models are contractually required in your project.

Philosophical remarks: the main interest of UML diagrams is to communicate the internals of a system. Abusing syntactic elements (e.g. actors in a sequence diagram) can sometimes improve this understanding, provided it is done in a manner that is consistent with the standard (e.g. use a classifier where a classifier is expected) and with comments where it is ambiguous. And finally, one can always argue that there is a larger system made of the modelled system and its users.

Community
  • 1
Christophe
  • 74,672
  • 10
  • 115
  • 187
  • In system sequence diagrams (c.f. Craig Larman) the actor represents an abstraction of a presentation layer. The idea is the technology for UI depends on platforms, etc. and that is not easy to specify in a high level design. System events are originated by actors, and results are returned. Actors are not objects, but they are useful in SSDs especially when you want to have traceability between a high level design and the use case (if you're using that technique). They can't receive messages, but in SSDs an asynchronous event is used to specify a communication to actors, via updates in the UI. – Fuhrmanator Aug 03 '18 at 00:32
  • @Fuhrmanator thank you for this additional confirmation. I fully agree that this practice can improve communication about the design. In the UML standard, an actor is a classifier, and instances of classifiers make lifelines. The formal restriction to the use of actors in the SD is only the term "enclosing classifier" . This is why I made two points: theory vs practice. In the case of secondary system actors this practice would even allow to document real messages to be exchanged (without having to go for BPMN). For human actors, messages could be mapped to instructions & procedures. – Christophe Aug 03 '18 at 07:53
  • When you've referred to *theory* I'm understanding it more as *formal code generation*, which doesn't really apply to SSDs (although it's been a few years since I saw demos for BPMN-based tools). – Fuhrmanator Aug 06 '18 at 21:10
  • @Fuhrmanator I see; let me disambiguate: with "theory" I meant exclusively "strict compliance with a formal standard". (*By the way, code generation is easier with BPMN because this notation and its semantic purposely evolved in v2.0 to be able to generate executable BPEL*) – Christophe Aug 06 '18 at 21:50