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.