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:send result to 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
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.