Quick Sequence Diagram Editor is a tool for
		creating UML sequence diagrams from textual descriptions of objects
		and messages.
	It supports threads, 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.
	
	
		Among its features are:
		
			- Automatic redrawing - The diagram changes as you type.
- Syntax check - errors in the textual descriptions are
				highlighted and can thus easily be found.
- Automatic completion - Object names can be guessed from a
				prefix (using the TAB key).
- Export - Diagrams can be exported in virtually any format,
				whether vector or pixel based.
- Zoom - Diagrams can be viewed in any zoom factor.
- View-text-correspondence - When you enter a message, the
				diagram view scrolls to where the corresponding arrow is to be seen.
				When you click an arrow, the cursor moves to the line where the
				message corresponding to the arrow is specified.
- Server mode - Diagram specifications generated by another
				tool can be transmitted through a socket and displayed in real-time.
			
- Links - You can create links to other diagrams. This feature
				can be used for providing easy access to a finer view onto something
				from which a more coarse-grained diagram abstracts away.
		- 
Breadth first search
- 
 Example illustrating levels 
- 
Ticket order
- 
 SSH 2 (by courtesy of Carlos Duarte) 
		
- 
Webserver
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 '\'.
	
	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.
	
	If <name> is prefixed with a '/', the
		lifeline will be invisible until the instance is created by a 'new'
		message to <name> (see below).
	
	An object declaration can be followed by a
		sequence of <flags> between square brackets. These flags
		are supported:
	
	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.
	
	The label of the lifeline will not be
		underlined.
	
	The object behaves like an actor (see below),
		but it is represented by a box with a thick border, not by a figure.
	
	
	
		The object will be destroyed automatically when the last
		activity that it was involved in has finished.
	
	
	
	
	
	   The object's lifeline might be placed at the horizontal position of
	   an object that has already been destroyed (relevant only for 
	   initially invisible objects).
	
	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.
	
	
	
	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.
	
	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.
	<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.
	<message> can consist of more than one
		line, separated by (a literal) \n.
	
	
		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.
	
	
	
		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.
	
	
	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.
	
	
	
	
	Diagrams can be annotated in three different
		ways.
	
	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.
	
	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.
	
	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.
	
	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.
	
	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-
line
note
*<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)foo
bar: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.
	
	
		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 a
link: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:/".
	
	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.
	
	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.
	
	
		Please also take a look at these supplementary help pages:
		
	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.
	
	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"
	
	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.
	
	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.
	
	<run-command> <OPTIONS> <sdfiles>
	
	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.
	
Copyright (c) 2006 - 2016 Markus Strauch. All
		rights reserved.
	
	This program is released under the terms of the
		BSD license:
	Redistribution and use in source and binary
		forms, with or without modification, are permitted provided that the
		following conditions are met:
	Redistributions of source code must retain the
		above copyright notice, this list of conditions and the following
		disclaimer.
	Redistributions in binary form must reproduce
		the above copyright notice, this list of conditions and the following
		disclaimer in the documentation and/or other materials provided with
		the distribution.
	
		 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS
			AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
			INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
			MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
			IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
			ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
			CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
			SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
			BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
			WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
			OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
			EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 
	
	
	
	
		The icon identifying the program's window is taken from ArgoUML,
		copyright by Tigris - see 
			http://argouml.tigris.org  - and released under the terms of the BSD
		license (see above).
	
		The following software may be included in this product: FREEHEP -
		Copyright 2000-2005 by CERN, Geneva, Switzerland; SLAC, Stanford,
		California, U.S.A.; University of California Santa Cruz, U.S.A. The
		use of this software is governed by the terms of the LGPL. See 
			http://www.fsf.org/licensing/licenses/lgpl.html 
	The following software may be included in this
		product: Java port of GNU getopt from glibc 2.0.6 Copyright (c)
		1987-1997 Free Software Foundation, Inc. Java Port Copyright (c) 1998
		by Aaron M. Renn (arenn@urbanophile.com) This software is released
		under the terms of the GNU Lesser General Public License.
		See see 
			http://www.fsf.org/licensing/licenses/lgpl.html