| [ Home | What's New | Contents | Overview | Contributors | Distribution | Examples | Documentation | Manual | Publications | Mailing List Archive | Problems ] | This page was last updated by Axel Belinfante on 2006-06-30 | |
| TorX Test Tool Information | ||
| Prev | Next | |
After start up, anifsm creates a window
(with the given title) for each file in dotfiles (or just a single window
if no dotfiles was given, or if dotfiles consists only of the special name
``-'') in which it draws the automaton for that file and then for the last (or
only) window waits for commands (for animation or layout) on standard input.
The animation and layout commands are discussed below in COMMANDS. On end
of file on standard input, or when the user removes the window (or presses
the Quit button which tells anifsmsrv to stop running) anifsm exits.
Note: the special treatment of ``-'' is deprecated and may disappear is future
versions.
In each anifsm window the graph can be edited (constructed, changed) using the mouse. The left mouse button is used to create nodes and edges; the right mouse button is used to delete them, to edit their attributes, and to post a pop-up menu which includes entries to save the graph to file in dot, Aldebaran (.aut), and Postscript format. For further details see EDITING below. Details of the transformation to Aldebaran (.aut) format are discussed below in AUTOMATON.
The middle mouse button can be used to scroll the canvas in its window by moving the mouse with the middle button pressed. When the middle button is clicked without moving the mouse the canvas of all clones of that window is scrolled to show the positition at which the mouse was clicked. When the Control key is pressed while the mouse is moved with the middle button pressed the canvases of all clones of the window are continuously scrolled to show the item under mouse.
Actually, anifsm
is a shell-level command that uses a running anifsmsrv to load the named
dot file, and animate it using animation commands on standard input. The
connection between anifsm and a running anifsmsrv will not be closed until
the complete standard input of the anifsm command has been processed by
anifsmsrv. If anifsm cannot find a running anifsmsrv, it will start a new
one. To display the new dot file, anifsm will reuse windows, but only those
that contain a completed animation, and have the Reuse toggle activated.
To choose which window to reuse, anifsm uses the -k key command line option.
If there are reusable windows with the same key, one of those will be used.
Otherwise, if anifsm was invoked without -k key option, it will look for
reusable windows with a non-empty key. If anifsm was invoked with a non-empty
-k key option, it will look for reusable windows with an empty key. If none
of the above is succesful, a new window will be created.
In general, it should not be necessary to start anifsmsrv by hand.
The -r command line option of anifsm will activate the Reuse toggle button for the window that will contain the dotfile given on the same command line.
The -k key command line option of anifsm will associate key with the window in which the given dotfile is animated. The key will be displayed to the right of the Reuse button. The key is used to guide the reuse of windows in which the animation is finished, as discussed above.
To make a running anifsmsrv go away invoke anifsm with the -exit command line option.
The animation in the window will follow the animation commands read from standard input. The animation can be stepped through manually using the Step up and down arrow buttons (as discussed below in BUTTONS).
In addition, the animation can be remotely controlled. If the -m mcastid command line option is given, or environment variable TORXMCASTID was set, anifsm will attempt to make a remote control connection to the tcp address in mcastid. If it succeeds, it will then interpret lines of text read from the remote control connection consisting of a single number as commands to show the corresponding step in the animation. Additionally, whenever the user uses mouse button and/or navigation commands to show a different step, its step number is written to the remote control connection. The remote control connection allows multiple viewers to show the same test step.
The animation commands are expected to be generated using log2jararacy(1) and jararacy2anifsm(1), e.g. using a unix command as
log2jararacy < logfile | jararacy2anifsm | anifsm dotfileor
tail -f logfile | log2jararacy | jararacy2anifsm | anifsm dotfileMake sure that the logfile contains a run of the automaton present in dotfile.
A mix of animation and layout (graph operation) commands is expected to be generated by log2anifsm(1) e.g. using a unix command as
log2anifsm < logfile | anifsm -or
tail -f logfile | log2anifsm | anifsm -
Of course, layout and animation commands can also be generated by other programs, or even be written by hand.
dot command argument aname avalue aname avalue ...
Known layout commands and their arguments are:
command arguments command arguments ...Known commands and their arguments are:
The node identifiers should be present in the dotfile or given in dot node or dot edge commands. The edge identifiers should be given in the dotfile as the value of a name attribute of an edge, as for example e42 is given in
src -> dst [label=action, name=e42 , ...];Alternatively, an edge identifier can be of the form
src->dst(note: no whitespace between src, -> and dst) where src and dst are node identifiers. Note, however, that if src and dst are linked by multiple edges, an arbitrary one will be chosen! It is much safer to rely on name attributes in the dotfile.
Clicking the left mouse button on the background of the canvas creates a new node.
Pressing the left mouse button on (in) a node and (while keeping the mouse button pressed) moving the mouse slightly starts the creation of an edge, as indicated by the red arrow which then appears. If the left mouse button is then released with the mouse cursor on (in) a node, an edge is created from the originating node to the destination node. If these nodes are the same a self-loop is created. If the mouse was released while the mouse cursor was not in a node, no edge is created (this can be used to cancel the creation of an edge). Just clicking the left mouse button on a node without moving the mouse at all does nothing (to avoid having to remove lots of unwanted self-loops).
Pressing the right mouse button on
a node or edge pops up an attribute edit box, which allows editing of node
or edge attributes, and deletion of the node or edge. The top part of the
edit box contains attribute names (on the left) with their current values
(on the right). The values that can be changed appear in entry fields. To
change a value, edit it in the entry field, and press the return key to
'commit' the change. To add an attribute not yet present, enter its name
in the empty entry field on the left (under the 'known' attribute names),
and its value in its corresponding entry field on the right, and press
the return key.
At the bottom of the edit box there are two buttons: Delete, which deletes
the node or edge from the graph, and Dismiss, which makes the edit box
disappear.
Pressing the right mouse button on a the background of the canvas pops up a menu that contains commands to create a new (inititially empty) window, to open (read) a dot file, to show some information, to connect to an mcast session, to write the graph in the window in dot, Aldebaran (.aut), or postscript format, and to pop up an edit box to edit global graph, node or edge attributes.
When a graph is read or constructed, the start state will be determined as follows. Initially, the first node created in a graph will be the start state. Then, the nodes are inspected and where applicable autexclude attributes will be set. Finally the edges are inspected. If there is an edge from an aut-excluded node to a non-aut-excluded node, the non-aut-excluded will be the start state of the automaton. If there are multiple such edges, the 'last' one 'wins'.
When the Aldebaran (.aut) file is written, the transition names are taken from the label attributes of the edges. The state names are determined as follows. If a graph node has a label attribute, it is used to determine the state name, otherwise the node name is used. If all such names (of all non-autexcluded graph nodes) consist of the same string prefix followed by a number, the numbers are used as state numbers in the Aldebaran file. Otherwise the complete names are used (which make them just be numbers).
In addition to the attribute names understood by dot there are a few node and edge attribute names that dot does not care about, but that are special for anifsm.
Attributes that have no value yet (that have the empty value) appear with {} as value in the edit box.
S0to color node S0 red; the commands are equivalent, the first uses the defaults. The last shows that in addition to color names also the #rgb color specifications of tcl/tk can be used.
-n S0
-c red -n S0
-c #f00 -n S0
-c green S0to color node S0 green;
-c green S0 S1 -e e0 -c blue e1 -n S2 S3 S4 -e e2to color nodes S0 and S1 and edge e0 green and nodes S2, S3 and S4 and edges e1 and e2 blue;
-e e0to color edge e0 red.
Example of mix of dot layout and animation commands (note that we do not have to use dot node commands if we do not need to specify attributes for the nodes, and we do not have multiple nodes with the same name). We specify edges between nodes a, b, and c, with name attributes that we use in subsequent animation commands, and for the edge from a to c we specify a ``backwards'' direction, equivalent to dir=back in a dot file. We then specify some additional edges, without name attribute, so we use the src->dst notation to refer to them in the subsequent animation commands.
dot edge a->b name e0 dot edge b->c name e1 dot edge a->c name e2 dir back -e e0 -e e1 -e e2 dot edge a->d dot edge d->c -e a->d -e d->c -e e2
Example of the creation of subgraphs. With the subgraph definition and subgraph attribute in the definition of both nodes a and d both nodes will be at the top, having the same rank. Without the subgraph definition node d would be next to node b.
The three dot edge lines above can be combined into two:
dot subgraph g1 rank same dot node a subgraph g1 dot node b dot node c dot node d subgraph g1 dot edge a->b dot edge b->c dot edge d->c
dot edge a->b->c dot edge d->c
Because the animation commands are read from standard input, it is not possible to read the dotfile from standard input. However, the (new) dot layout commands that can be given on standard input compensate for that to a certain extent.
The window does not automatically scroll to follow the colored states.
After an syntax error has been encountered in an input dotfile, tcldot(1) (at least the version in GraphViz 1.8.5) seems to be unable to recover sufficiently to be able to read more (syntactly correct) dotfiles.
After the revision of the syntax of the commands accepted on standard input to make it more general and take out the TorX specific features, the language accepted by anifsm differs from the one accepted by jararacy(1). The difference between the two is bridged by jararacy2anifsm(1). However, the fact that we have this difference breaks the fall-back to jararacy(1) that used to be present in anifsm, because if this fall-back would be used, jararacy(1) would be given the revised commands which it will not understand. As a consequence, the fall-back has been removed: if anifsm can not find tcl package Tcldot it will just give up.
The usage of autstart and autexclude attributes to indicate automaton features of the graph is clumsy.
When the attribute edit box is popped up, it tries to position itself under the mouse cursor, in an attempt to reduce the necessary mouse movements. We added this in the hope that it would be benificial, but it works not as benificial as intended: the fact that the box is moving all the time is very annoying. To be fixed.
There is no indication that a graph that was read in from a dot file has been altered using mouse commands.
There are no distinct view and edit modes (editing is always enabled). There is not enough experience (yet) with anifsm to tell whether such modes are actually needed, though.
| Prev | Table of Contents | Next |
| Appendix D: TorX Manual Pages: adaptsim(1) - torx program to interface to a TorX primer used as SUT |
|
Appendix D: TorX Manual Pages: anifsmsrv(1) |