Tutorial Samples:

#![SD ticket order]user:Actor/order:Order[x]db:TicketDBacc:Account

user:order.new()order:return=db.reserve(date,count)db:return=acc.debit(cost)acc:return=db.bonus(date,count)

#!>>#!A simple linear-time algorithm for exploring a graph, starting at "someNode". #!#!Let u, v be two nodes of the graph. If the distance between "someNode" and u#!is less than the distance between "someNode" and v, then u will be encountered#!before v.#!#!When a node is encountered for the first time, its level attribute (denoting the#!distance between "someNode" and the node) is set.#!<<

#![SD breadth-first-search]bfs:BFS[a]/queue:FIFOsomeNode:Nodenode:NodeadjList:Listadj:Node

bfs:queue.newbfs:someNode.setLevel(0)bfs:queue.insert(someNode)[c:loop while queue != ()] bfs:node=queue.remove() bfs:level=node.getLevel() bfs:adjList=node.getAdjacentNodes() [c:loop 0<=i<#adjList] bfs:adj=adjList.get(i) bfs:nodeLevel=adj.getLevel() [c:alt nodeLevel IS NOT defined] bfs:adj.setLevel(level+1) bfs:queue.insert(adj) --[else] bfs:nothing to do [/c] [/c][/c]bfs:queue.destroy()

#!>>#!This sequence diagram demonstrates the use of levels and mnemonics.#!

#!<<o:Objectp:Objectq:Object

o:p.activatep:p.self-messagep:q.activateq:q.self-messageq:q.another self-message# Use q[2] as sender, so send back 2 messages implicitly beforeq[2]:p.call back from q[2]p[2]:p.yet another self-message from p[2]p[1]:o.call back from p[1]

[c The same as above, but with mnemonics]o[1]:p[p0].activatep:p.self-messagep:q[q0].activateq:q.self-messageq:q.another self-messageq[q0]:p.call back from q[q0]p[p0]:p.yet another self-message from p[p0]p[p0]:o.call back from p[p0][/c]

#!>>#!Multithreading should be disabled.#!<<#![SD SSH2]user:ActorRNG:RandomNumberGeneratorknown_hosts:Local_File/ssh2:AskMySelfssh:Client[p] "SSH-Client"ordinary_tcp_layer_local:Layer_End/transport_protocol_layer_local:Local_Enduser_authentication_protocol_layer_local:Local_Endconnection_protocol_layer_local:Local_Endether:Net "Ethernet"/shared_secret:DiffieHellmannet:Work "Network"connection_protocol_layer_remote:Layer_Enduser_authentication_protocol_layer_remote:Layer_End/transport_protocol_layer_remote:Layer_Endordinary_tcp_layer_remote:Layer_Endsshd:Daemon [p] "sshd"/sshd2:AskMySelfdsa_host_key:Remote_FileopenPAM:Remote_Authentication_Scheme

user:ssh.sshd -2 lipovitan(at)192:168:19:141

ssh:ordinary_tcp_layer_local.us-ascii: "hello, i'm a mac<CR><LF>" (to port22-->)ordinary_tcp_layer_local:ordinary_tcp_layer_remote.us-ascii: "hello, i'm a mac<CR><LF>" (to port22-->)ordinary_tcp_layer_remote:sshd.(from port22-->) us-ascii: "hello, i'm a mac<CR><LF>"

sshd:ordinary_tcp_layer_remote.(<--to port22) us-ascii: "SSH-2:0-OpenSSH_4:5p1 FreeBSD-20061110<CR><LF>"ordinary_tcp_layer_remote:ordinary_tcp_layer_local.(<--to port22) us-ascii: "SSH-2:0-OpenSSH_4:5p1 FreeBSD-20061110<CR><LF>"ordinary_tcp_layer_local:ssh.(<--to port22) us-ascii: "SSH-2:0-OpenSSH_4:5p1 FreeBSD-20061110<CR><LF>"

sshd:ordinary_tcp_layer_remote.ordinary_tcp_layer_remote:ordinary_tcp_layer_local.ordinary_tcp_layer_local:ssh.

ssh:ordinary_tcp_layer_local.

ordinary_tcp_layer_local:ordinary_tcp_layer_remote.ordinary_tcp_layer_remote:sshd.

ssh:transport_protocol_layer_local.newsshd:transport_protocol_layer_remote.new

sshd:transport_protocol_layer_remote.SSH_MSG_KEXINIT (beggining 'binary packet parameter negotiation' stage of 'key exchange' phase)transport_protocol_layer_remote:transport_protocol_layer_local.SSH_MSG_KEXINIT (beggining 'binary packet parameter negotiation' stage of 'key exchange' phase)transport_protocol_layer_local:ssh.SSH_MSG_KEXINIT (beggining 'binary packet parameter negotiation' stage of 'key exchange' phase)

sshd:transport_protocol_layer_remote.transport_protocol_layer_remote:transport_protocol_layer_local.transport_protocol_layer_local:ssh.

ssh:transport_protocol_layer_local.transport_protocol_layer_local:transport_protocol_layer_remote.transport_protocol_layer_remote:sshd.

ssh:transport_protocol_layer_local.cookie (random bytes used later)transport_protocol_layer_local:transport_protocol_layer_remote.cookie (random bytes used later)transport_protocol_layer_remote:sshd.cookie (random bytes used later)

sshd:transport_protocol_layer_remote.cookie (random bytes used later)transport_protocol_layer_remote:transport_protocol_layer_local.cookie (random bytes used later)transport_protocol_layer_local:ssh.cookie (random bytes used later)

sshd:transport_protocol_layer_remote.transport_protocol_layer_remote:transport_protocol_layer_local.transport_protocol_layer_local:ssh.

ssh:transport_protocol_layer_local.transport_protocol_layer_local:transport_protocol_layer_remote.transport_protocol_layer_remote:sshd.

ssh:transport_protocol_layer_local.kex_algorithms, server_host_key_algorithmstransport_protocol_layer_local:transport_protocol_layer_remote.kex_algorithms, server_host_key_algorithmstransport_protocol_layer_remote:sshd.kex_algorithms, server_host_key_algorithms

sshd:transport_protocol_layer_remote.kex_algorithms, server_host_key_algorithmstransport_protocol_layer_remote:transport_protocol_layer_local.kex_algorithms, server_host_key_algorithms

transport_protocol_layer_local:ssh.kex_algorithms, server_host_key_algorithms

ssh:transport_protocol_layer_local.encryption_algorithms (symmetric)transport_protocol_layer_local:transport_protocol_layer_remote.encryption_algorithms (symmetric)transport_protocol_layer_remote:sshd.encryption_algorithms (symmetric)

sshd:transport_protocol_layer_remote.encryption_algorithms (symmetric)transport_protocol_layer_remote:transport_protocol_layer_local.encryption_algorithms (symmetric)transport_protocol_layer_local:ssh.encryption_algorithms (symmetric)

ssh:transport_protocol_layer_local.mac_algorithmstransport_protocol_layer_local:transport_protocol_layer_remote.mac_algorithmstransport_protocol_layer_remote:sshd.mac_algorithms

sshd:transport_protocol_layer_remote.mac_algorithmstransport_protocol_layer_remote:transport_protocol_layer_local.mac_algorithmstransport_protocol_layer_local:ssh.mac_algorithms

ssh:transport_protocol_layer_local.compression_algorithmstransport_protocol_layer_local:transport_protocol_layer_remote.compression_algorithmstransport_protocol_layer_remote:sshd.compression_algorithms

sshd:transport_protocol_layer_remote.compression_algorithmstransport_protocol_layer_remote:transport_protocol_layer_local.compression_algorithmstransport_protocol_layer_local:ssh.compression_algorithms

sshd:transport_protocol_layer_remote.transport_protocol_layer_remote:transport_protocol_layer_local.transport_protocol_layer_local:ssh.

ssh:transport_protocol_layer_local.transport_protocol_layer_local:transport_protocol_layer_remote.transport_protocol_layer_remote:sshd.

ssh:transport_protocol_layer_local.first_kex_packet_followstransport_protocol_layer_local:transport_protocol_layer_remote.first_kex_packet_followstransport_protocol_layer_remote:sshd.first_kex_packet_follows

ssh:transport_protocol_layer_local.client's "guessed protocol" packettransport_protocol_layer_local:transport_protocol_layer_remote.client's "guessed protocol" packettransport_protocol_layer_remote:sshd.client's "guessed protocol" packet

sshd:transport_protocol_layer_remote.server's "guessed protocol" packet

transport_protocol_layer_remote:transport_protocol_layer_local.server's "guessed protocol" packettransport_protocol_layer_local:ssh.server's "guessed protocol" packet

ssh:ssh2.newssh:ssh2.if guessed_algorithm matches, proceedssh:ssh2.otherwise ignore next packetssh2:ssh.guessed_algorithm matchesssh:ssh2.let's stick to this packet for key exchange

sshd:sshd2.newsshd:sshd2.if guessed_algorithm matches, proceedsshd:guessed_algorithm matches=sshd2.otherwise ignore next packetsshd:sshd2.let's stick to this algorithm for key exchange

ssh:shared_secret.newssh:shared_secret.new shared secret generated every gigabyte or every hourssh:big random number=RNG.gimme a big random number

ssh:=transport_protocol_layer_local.diffie-hellmantransport_protocol_layer_local:shared_secret.diffie-hellman

sshd:transport_protocol_layer_remote.diffie-hellmantransport_protocol_layer_remote:shared_secret.diffie-hellman

shared_secret:shared_secret.shared_secret (used for generating encryption and authentication keys)shared_secret:shared_secret.exchange_hash (permanent session identifier (does not change with "hourly" new keys))

ssh:transport_protocol_layer_local.SSH_MSG_NEWKEYS (begin using new keys (this message is sent with old keys))transport_protocol_layer_local:transport_protocol_layer_remote.SSH_MSG_NEWKEYStransport_protocol_layer_remote:sshd.SSH_MSG_NEWKEYS

sshd:transport_protocol_layer_remote.SSH_MSG_NEWKEYS (begin using new keys (this message is sent with old keys))transport_protocol_layer_remote:transport_protocol_layer_local.SSH_MSG_NEWKEYStransport_protocol_layer_local:ssh.SSH_MSG_NEWKEYS

sshd:ordinary_tcp_layer_remote.ordinary_tcp_layer_remote:ordinary_tcp_layer_local.ordinary_tcp_layer_local:ssh.

ssh:ordinary_tcp_layer_local.

ordinary_tcp_layer_local:ordinary_tcp_layer_remote.ordinary_tcp_layer_remote:sshd.

ssh:transport_protocol_layer_local.SSH_MSG_SERVICE_REQUEST ssh_userauth (i need authentication!)transport_protocol_layer_local:transport_protocol_layer_remote.SSH_MSG_SERVICE_REQUEST ssh_userauthtransport_protocol_layer_remote:sshd.SSH_MSG_SERVICE_REQUEST ssh_userauthsshd:sure=openPAM.can you authorize for the lipovitan account now?

client1:Process[p] "Googlebot"client2:Actor[r] "Surfer"webServer:Server[pr] "Webserver"t1:Thread[at]t2:Thread[at]localDisk:HDD

*1 client1The Google bot in search ofpages it can index.*1

*2 client2An internet surfer in searchof information or such.*2

*3 t1These are two threads fromthe webserver's thread pool.*3(1)client1(2)client2(3)t1

(3)t2

client1:webServer.GET /

webServer:t1.process request "GET /"&

t1[,0]:page=localDisk.read("/var/www/index.html")&client2:webServer.GET /doc/menu.html

*4client1Waiting for the information to arrive.*4

webServer:t2.process request "GET /doc/menu.html"&t2[,1]:page=localDisk.read("/var/www/doc/menu.html")(4)client2t2:client2.send(page)t1[,0]:client1.send(page)t1:stopt2[,1]:stop

Multithreading Multithreading support is an advanced feature that is available since version 2.2. If you are not interested, you can completely ignore it. If you are interested, you may enable it in the "Threads" menu. When multithreading is enabled, you can create diagrams that model arbitarily many sequences running in parallel, not just a single one. The sequences can (at your option) be distinguished by the colours of their corresponding lifelines. There is still no real parallelism, as the messages must be specified in some order. This order can be interpreted as one of many possible interleavings of the threads. A single-processor system would execute them in a similar way.

Specifying diagrams with multiple threads Specifying a multithreaded diagram is only slightly harder than specifying a diagram with a single thread.

Spawning threads A newly spawned thread can be distinguished from older threads by the colour of its corresponding lifelines. If you spawn too many threads, colours may be repeated. Threads have successive numbers, starting with 0. Statically spawned threads Objects that have been declared with the "t" flag set, for example:

o:Object[t]have their own (statically spawned) thread. The first thing that happens on this thread must be a message sent by the corresponding object.

If there is no object with a "t" flag, there is a single thread nonetheless. It starts executing when the first message is sent by an object. Dynamically spawned threads As a rule, a message sent by an actor to an object (dynamically) spawns a new thread. So do messages sent to "active objects". An object can be declared to be active by setting the v flag. Example:

worker:BackgroundWorker[v]Messages sent and received by ordinary objects may also spawn new threads. In order to specify that such a message is spawning, use a colon followed by a ">" to separate the caller from the message. Example:

object:>bar.foo()This means that object spawns a new thread and the first thing this new thread does is executing the foo method of the bar object. Note that you cannot specify answers to messages that spawn threads. If an object running on a new thread wants to communicate with the spawning object, it must explicitly send a message. Broadcast messages A message can have more than one callee, specified in set notation. In this case, it is a broadcast message. Example:

caller:{callee1,callee2,callee3}.broadcastA callee may not occur more than once in the callee set, the caller may not occur at all in there. The effect of a broadcast message is that a new thread is spawned for each callee. It is currently not possible to define mnemonics for objects that are activated by a broadcast message.

Specifying the thread where an activity occurs When more than one thread is used, we need to be able to tell on which of the threads a message occurs. So the level of a caller (specified in square brackets) may be followed by the number of the thread, where level and thread are separated by a comma. Example:

object[0,3]:bar.foo()This means that object is sending a foo() message to bar on the thread number 3. If an object is used by a single thread only, the number of the thread can be omitted. If there is more than one thread using an object and the thread number is omitted, the editor assumes that the message is to be sent on the same thread as the most recent message. If you spawn a new thread, the next message will, if not otherwise specified, be sent on that new thread. It is also possible to omit the level and only specify the thread, so object[,3]:bar.foo() is equivalent to the example above, as 0 is the default level. You can also use a mnemonic between square brackets. When a mnemonic is defined for an object, the mnemonic determines both the level and the thread number. Thread numbers can be made visible at your option (see the "Threads" menu): They are shown at the top of the active lifelines.

Instant return Normally, the focus of a thread's activity stays on the object that has received the most recent message, unless the thread is stopped or another message is sent. Sometimes, however, it may seem inappropriate to have a thread's focus resting on an object for so long. In that case a message should be ended by an "&". This means that the answer to the message will be sent immediately. Note that a message sent later cannot have the callee of the instantly returning message as a caller of course. Example:

foo:bar.notify()&

If a spawning message is suffixed with an "&", the spawned thread does nothing and dies instantly. Such messages might be interpreted as asynchronous signals.

Stopping threads Normally, a thread runs until the end of the diagram. But maybe you would like to model that it dies at some point. This is done by inserting a pseudo message of the form:

object:stop(where of course also a thread number may be specified). Stopping a thread may be necessary before an object can be destroyed, if the thread's activity does not return from the object otherwise. The text of the pseudo message (i. e. "stop") will not appear on the diagram. The visible effect rather is that the corresponding lifeline ends at that point.

Returning control flow Before an object sends a message, a thread's control flow has to return to it, which implies that some answers pending on the thread might have to be sent. Sometimes one wants to manipulate the control flow like this without the need to send a new message, e. g. for representing that a certain set of actions is finished now or for simply doing some "clean-up". This can be done by inserting a pseudo message consisting of just an underscore:

object:_The effect is that enough pending answers will be sent such that "object" could send a message now on its current thread (again, a special thread number may be specified). The pseudo message does not appear on the diagram and there will be no extra space consumed (apart from the space needed for the answers). ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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: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 queriesserver[s]:server.do something usefuljob[j]:job.analyze queriesjob[j]:job.compute resultserver[s]:server.wait for resultjob[j]:server.send back result job[j]:stop

Show diagram 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Summary Quick Sequence Diagram Editor is a tool for creating UML sequence diagrams from textual descriptions of objects and messages. It supports actors, constructors, destructors, notes and fragments. The aim of the tool is to save you from lots of the stupid work that WYSIWYG applications require, by trading off not too much flexibility. It beats these applications by far when it comes to insert or remove objects and messages. This can be done by just inserting or removing a line of text, the tool will do all the rest.

Examples Some examples may require that multithreading is either turned on or off. Breadth first search Example illustrating levels and mnemonics Ticket order SSH 2 (by courtesy of Carlos Duarte)

Webserver

How to enter text Use the text area at the bottom of the window to specify your objects and messages. The object section must be separated from the message section by an empty line. Should there be a (syntax) error in your text, the first line where such an error occurs is highlighted. And there will be a description of the error at the bottom of the window. '.' and ':' will not be interpreted as delimiters, if they are preceded by a '\'.

Objects For each object you want to appear in your sequence diagram, type

<name>:<Type>[<flags>] "<label>"

or /<name>:<Type>[<flags>] "<label>"

into the text area. This represents an instance of class <Type>, named <name> which will be shown as a lifeline. <name>. The [<flags>] and "<label>" parts are optional: If you specify a quoted label, it will be used to label the object with, otherwise the object's label will be derived from the name and the type. Invisible objects If <name> is prefixed with a '/', the lifeline will be invisible until the instance is created by a 'new' message to <name> (see below). Flags An object declaration can be followed by a sequence of <flags> between square brackets. Four flags (a,p,r,x) are supported:

a-nonymous The object is anonymous, so the name (which must still be there in order to be able to reference the lifeline) will not appear on the diagram, just a colon followed by the Type. This flag is useless if a <label> is specified.

r-ole The label of the lifeline will not be underlined.

p-rocess The object behaves like an actor (see below), but it is represented by a box with a thick border, not by a figure.

x-auto-destruction The object is destroyed when it has sent its last answer, denoted by a cross below its lifeline. One might interpret this as automatic destruction of non-persistent objects by a garbage collector. There are other flags, relevant for multithreading . Actors If <Type> is 'Actor', the lifeline belongs to an actor. An actor is always active and sends asynchronous messages. It cannot send messages to itself.

Messages The lines in the message section have the following format:

<caller>[<s>]:<answer>=<callee>[m].<message>

<caller> is the name of an object that has been declared in the object section. It is either the first one to send a message or has received a message before and not yet answered to it. Otherwise it is not active and cannot send a message. [<s>] is optional and refines the specification of the caller object. If <s> is a number, it denotes the 'level' of the caller: A caller may have received k messages to which it has yet to answer. Then <s> can range from 0 to k-1. Before <caller> sends the message, it will answer to the <s> most recent messages. If <s> is not a number, it is a mnemonic. A mnemonic can be defined for a callee (by using the optional [<m>] part). If <s> is a mnemonic that has been defined for the object <caller> and <caller> is still active, <caller>[<s>] references this object. <answer>= is optional and <answer> is simply a string representing the answer to the message. This string is used as a label of a dashed arrow from the <callee> to the <caller> lifeline. <callee>. is optional and <callee> denotes the object that receives the message represented by the string <message>, which is used as a label of an arrow from <caller> to <callee>. If no <callee> is specified, <message> is interpreted as an description of a simple action (not another invocation of a method/procedure) performed by the caller. [<m>] is optional and <m> is a mnemonic containing at least one character that is not a digit. As long as the callee is active, it can be referenced as a caller by its name followed by [<m>]. <message> can consist of more than one line, separated by (a literal) \n. Constructors Messages that are named ' new ' or that start with ' new( ' are special messages. They can be sent only once to objects that were declared with a '/' before their names. On receiving a 'new' message, the object will be created and its lifeline will become visible. Destructors Messages that are named ' destroy ' or that start with ' destroy( ' are also special. They can only be sent to an object that is not active. After receiving the destroy-message, the object may become active for the last time and, for example, send some destroy messages to other objects. But after this last activity ended, the object is destroyed (denoted by a cross below its lifeline) and cannot be reclaimed. Actor messages Actors can only send and receive asynchronous messages that return immediately. An asynchronous message will be generated that is sent back to the actor when the activity that was started by his message is finished. If <answer> is empty and "show answers to actors" is set to 0 in the "Flags" section of the configuration dialog, no answer will be shown. Answers to messages that are sent to actors are ignored. If an actor sends a message to an ordinary object, all activities will be finished before. An actor should typically send the first message of the diagram, but this is not necessary, sequences without even a single actor are still supported. Broadcast messages See multithreading .

Annotations Diagrams can be annotated in three different ways.

Source text comments First, you may insert lines starting with a '#' in the textual description. These lines serve as comments and will not be interpreted, unless they start with '#!', which indicates an active comment.

Title A line of the form

#![<title>]specifies a diagram title. If it is present, the diagram will be surrounded by a frame, with the title written at the top left corner of the frame.

Description A sequence of lines of the form

#!>>#!A paragraph#!of text describing#!what is going on.#!<<

is interpreted as text that will be written above the diagram. Fragments Second, a sequence of messages can be declared to be a fragment of the diagram. A fragment is represented by a frame surrounding those messages. It has a type (for example: alt, cond, or opt), appearing in the top-left corner, and a text, appearing in square brackets at the top of the frame. The text typically represents a condition. For example:

[c:<type> <text>] foo:bar.message_1 foo:bar.message_2 ... foo:bar.message_n[/c]

Fragments can be slightly abused: if you write [c <text>] (without the colon), all of the text will appear in the small box in the top left corner. Fragments may contain sections. To open a new section, insert a line of the form --some text The effect is that a dashed line is drawn from the left to the right end of the current fragment frame, with "some text" being written below this line. Notes Third, there are notes. These appear in a box resembling a piece of paper that is arranged to the right of a lifeline. Notes are a part of the message section. The top of the box is where an arrow belonging to a message specified at the same position in the text would appear. The syntax is similar to a here-document delimited by an asterisk followed by a number (without the <<).

*<num> <name>multi-linenote

*<num><name> is the name of the lifeline such that the note is to the right of it. <num> is the unique number identifying the note. You can refer to this number anywhere in the code - even before the note - in order to associate the note to messages or lifelines. For this you add one of the following prefixes to a message or the name of a lifeline: (<num>). A line will be drawn from the note box with the number <num> to the message arrow or to the current vertical position of the lifeline. (<num>,<anum>). This can only be the prefix of a message. The effect is the same as above, if <num> is not empty. Additionally, there will be a line drawn from the note box <anum> to the arrow belonging to the answer of the message Example:

*5 foo foo calls bar's wait method*5*6 foo foo is waiting for bar*6*7 foo bar is ready*7

(5,7)foo:ready=bar.wait()(6)foo bar:do something(6)foobar:do something more

If you use a "+" instead of a "*", the note box will consume as much vertical space as it needs and there will not be any message arrow or other note box beside it. When using "*", the note box will consume its own vertical space only if it is followed by a message arrow that is adjacent to one its both neighbour lifelines. There are no direct associations between notes and objects. If one wishes to note something concerning an object or actor, she or he should specify a note belonging to the corresponding lifeline before any message has been specified.

Links A single-lined note that starts with "link:" is interpreted as a link to another sequence diagram. The part of the line that follows is a URI (see RFC 3986 ) of an sd file. If the URI is relative, it is resolved against the location of the file of the current diagram. Example:

#BEGIN of file "a.sd"a:A

*1 alink:b.sd

*1 a#END #BEGIN of file "b.sd",#located in the same directory as "a.sd"b:B#END

When the note in the "a.sd" diagram is clicked, "b.sd" will be opened. There is a problem when the characters behind "link:" contain spaces. This is a bad URI syntax. Spaces must be replaced by "%20". Especially on Windows, where directory names with spaces are far from being exceptional - for instance "Program Files" - one may easily run into this problem when trying to specify absolute paths. Those characters are interpreted as a URI for the sake of platform independence. This means that even on the Windows platform, "/" is to be used as a separator in a path to a file. Absolute path names should start with "file:/".

Automatic completion When you have entered a (non-empty) prefix of a name of an object, you can press the TAB key (like in a UNIX shell) or Ctrl-Shift-Space (like in some IDEs) for completing the name automatically or for browsing through (via successive keystrokes) all object names with that prefix. If there is whitespace or a delimiter (one of {'>', ':', '='}) to the left of the cursor, the TAB key will behave normally, so you can still use it for indentations.

Automatic redrawing By default, a new diagram is generated from your text almost as soon as the text changes, even if this change in text would leave the diagram unchanged. This is a suitable behaviour for a standalone PC that is reasonably well equipped. In some situtations, however, especially when Quick Sequence Diagram Editor acts as a remote X client, it can be a nuisance. So you may disable automatic redrawing in the "View" menu. When it is disabled, only a syntax/semantic check is performed. To see a new diagram, you must click "Redraw" or type F5. The time that passes between a change of text and a redrawing or a syntax/semantic check can also be adjusted in the configuration dialog (see "Redraw/syntax check delay"). It may be desirable to have two different delays (one for redrawing, one for the check), but this feature is not (yet?) implemented.

Supplementary help pages Please also take a look at these supplementary help pages: Multithreading Asynchronous messages

Filtering The contents of the text area can be replaced by the output of a command that you have entered after clicking the filter icon. If no text is selected, the whole of the text is used as the command's input and replaced by its output, otherwise the replacement is applied to the selection only. The field where the command is entered can be left by clicking the ESC key. This may also terminate a command that has been entered and has not yet finished. There is a history of commands you have already

entered in this session, through which you can browse using the cursor up and cursor down key. This feature can be used by people who are too lazy to use the file dialog in order to load a file. For example: cat ~/my_diagram.sd. It can also be used for replacing patterns: sed s/foo/bar/g. Or to remove lines that contain comments: grep -v # ... Of course cat, sed and grep must be available on the system then.

HTML map files If an image of a sequence diagram is used on a website, if might be useful to be able to navigate to a certain target if a head of a lifeline is clicked. For this purpose, a HTML map file can be generated for the diagram that is currently being displayed (see the File menu). The map file contains just a <map> tag, comprising <area> tags for each object of the diagram. The <area> tag's href attribute equals the name of the object, or, if the declaration of the object is followed by '#!href="<url>"' , an URL of your choice. Example:

object:Class #!href="../foo.html#bar"

Javadoc taglet Quick Sequence Diagram Editor helps you to add sequence diagrams to your Java documentation (javadoc). Pass these two parameters to the javadoc tool: -tagletpath <CLASSPATH> -taglet net.sf.sdedit.taglet.SequenceTaglet <CLASSPATH> is the location of the Quick Sequence Editor class files, that can be the jar file or the bin directory. If you are using the exe file, there is no such location, sorry. Now javadoc will interpret the contents of @sequence.diagram tags as textual descriptions of sequence diagrams. It will create PNG images from them and they will be shown on the HTML pages generated by the standard doclet. The images are stored in a directory that is a child of the javadoc target directory. When @sequence.diagram is followed by a quoted string, this string will be used as a headline for the sequence diagram. @sequence.diagram can appear in a package description and anywhere in a class definition. Example:

/** This is the description of the EnigmaDecoder. ... @author Alan Turing @sequence.diagram "Instantiation of the EnigmaDecoder" a:A /decoder:EnigmaDecoder a:decoder.new @deprecated */

Beware of code-formatters that join lines in javadoc comments. This might result in syntactically wrong sequence diagram descriptions.

Printing Printing is not supported by the "light" executable jar file, unless it is used with the FreeHEP library on the class path. If FreeHEP is available, diagrams can be printed by external programs that are able to process PS oder PDF files. Choose "Print" in the "File" menu, then select a suitable profile and/or enter the print command of your

choice. You can also choose between PS and PDF output and select the paper format (A3 or A4) and orientation. If the command cannot receive input through STDIN, a temporary PS or PDF file must be generated. The name of the file is a part of the command then. It must be enclosed by curly braces, so sdedit knows which file to generate. Example: lpr {/tmp/printing.ps} The diagram currently being displayed will be exported as /tmp/printing.ps, then lpr is executed with this file as a parameter. On Windows, Acrobat reader (acrord32.exe) is used as a print command. If it is not on your path, you have to enter the path to acrord32.exe manually. It will be remembered if you save the profile by clicking the "Save as" button. Acrobat reader cannot read from STDIN, so you have to specify a temporary file.

Command line usage <run-command> <OPTIONS> <sdfiles>

<run-command> is "sdedit.sh", "sdedit.bat" or "java -jar sdedit-2.10.jar". <sdfiles> are the names of files that, when specified, will be loaded into the text area for editing. OPTIONS: -o output.png : one sdfile must be specified and, without any user interaction, the resulting diagram is written to output.png, which is of course in PNG format. -s <port> : starts the Quick Sequence Diagram Server listening at the given <port>

sd-client.pl When the Quick Sequence Diagram Server runs, the Perl script sd-client.pl (which is a part of the full version of Quick Sequence Diagram Editor) can be used to create sequence diagrams from text files: perl sd-client.pl <type> <infile.sd> <outfile> <type> is one of {ps,pdf,svg,swf,emf,bmp,png,gif,jpg}. sd-client.pl uses port 62015 by default, for using another port you must edit the script.

RT diagram server Diagram specifications can be transmitted through a TCP socket and displayed in real time, i. e. as soon as a new line is transmitted, the diagram will be updated. To use this function, select "Start/stop RT server" in the file menu and enter a port number. A process that connects to the port will have to follow a very simple uni-directional protocol:

The first line is interpreted as the name of a new tab to be opened. The remaining lines are entered into the text area of the new tab. When a line consists of the word "end", the socket will be closed. The line will not appear in the text

area. The server is started automatically if the "Autostart RT diagram server" flag is set to 1 in the configuration dialog. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~