Some notes on asynchronous messages
Quick Sequence Diagram Editor is not a tool that gives you unlimited freedom of drawing. A sequence is subject to these two constraints:
- Messages can only be sent by actors or objects that have received a message and are still active.
- When a message is sent, some activities that were initiated by the sending object (the caller) may have to be finished before. This is done automatically by the Quick Sequence Diagram Editor, which should be considered an advantage: Answer arrows need not be specified by the user, the editor takes care that they are inserted at the right place and time.
These constraints seem to make it impossible to specify an asynchronous message. This is a message that returns immediately from the callee and renders it active while the caller remains active as well and could send another message without rendering the former callee inactive again.
But such messages can be modelled very well by Quick Sequence Diagram Editor as it supports multithreading. One may object to this because multithreading is an implementation detail, and maybe one does not want to deal with it. But multithreading is the only means (and it is a sufficient means too) for modelling asynchronity that is offered by the editor. And after all, it is just a modelling tool, so one does not have to delve really deeply into the details of multithreading.
As an example, suppose you want to model a sequence where a server starts a background job that does a lot of queries to a database and sends back a result later:
user:Actor
server:Server[a]
job:BackgroundJob[a]
db:Database[a]
user:server[s].start
# Here comes the asynchronous message that implicitly spawns
# a new thread. Thanks to the mnemnonic 'j' the job object
# can safely be identified on that new thread, so
# you do not even have to deal with thread numbers.
[c asynchronous message]
server:>job[j].start
[/c]
job:db.do 1'000'000 queries
server[s]:server.do something useful
job[j]:job.analyze queries
job[j]:job.compute result
server[s]:server.wait for result
job[j]:server.send back result
job[j]:stop
server[s]:user.send result to user
As long as objects are used by only a single thread or there are mnemonics, thread numbers can be ignored. If thread colourizing is disabled, the resulting sequence diagram should look very similar to a diagram made with a WYSIWYG tool that allows to put arrows everywhere.