TorXviz Toolset

For our testing tool(kit) TorX we developed several small reusable visualization tool components that so far have only been distributed as part of the TorX distribution.
Since these components have specifically been developed with reuse outside TorX in mind they also deserve distribution 'outside' TorX. This is where they are available 'outside' TorX.

Functionality

Currently the toolset offers the following:
(the main links below refer to the the tool description in the online manual pages of TorX which may be slightly out of sync with the version made available here. However, the distribution here includes up-to-date manual pages.)
  • AniFSM -- on the fly construction, animation (by highlighting of nodes and edges), and (limited) editing of (di)graphs in dot format
  • mscviewer -- on the fly construction and animation of (very simple) message sequence charts
  • AniWait -- animate a simple progress bar
  • MControl -- a slider to slide forward and backwards through the animation steps
  • tmcs -- a simple tcp multicast server that the tool components use to synchronously update their view when we step forwards or backwards in the animation

Distribution

All these programs are written in Tcl/Tk. The intention is to make them available as starkits: one self-contained starkit for each individual program, i.e. for each client program and for each server program. To use them you will just have to make sure you have the tclkit executable for your platform (in case of windows you will need both tclkit and tclkitsh, because windows tclkit is unable to communicate over standard input and output, which we need for the client programs (see below), and tclkitsh is unable to create windows, which we need for the server programs (see below)).

Architecture

Each of these tools (except tmcs which is not really a visualization tool but just provides a piece of infrastructure used by them) has a client-server architecture. Each of the tools consists of two programs: a client program and a server program.

The server programs do the real work (maintain windows, perform animation etc.). The user 'talks with' the server programs using the client programs, to issue animation commands, and, where applicable, to on the fly contruct the thing (graph, msc) to animate.

The user 'talks' with the client programs by giving them command line arguments when the client programs are started, and by writing to the standard input and reading from the standard output of the client programs while they run. At the end of an animation sequence the user 'generates' end-of-file on the standard input of the client programs that it started. These client programs will then close their connection to the server programs to inform the servers that the animation sequence was completed, and exit. The servers will continue to run and the animations continue to be accessable. However, depending on toggles set by the user, windows of which the animation sequence is complete may be reused to show a 'fresh' animation sequence when a new client connects to the server.

The client programs make sure that their server program counterpart is started if it is not running already. There may be multiple client programs that concurrently use the same running server program to show their animation.

For each of the tools in the toolset the animation consists of a sequence of discrete steps. The user can use buttons on the animation windows to step backwards and forwards in the animation sequence, to show the animation 'state' corresponding to each of the discrete animation steps that have been encountered so far. When multiple animation viewers are used to view different aspect (animations) of the same activity, these viewers can be 'connected' such that when the buttons in one of the windows are used to step forwards or backwards all 'connected' viewers also step forwards or backwards, such that all connected viewers always show their animation state for the same discrete animation step. The connection is made at the start of an animation 'run' by starting 'tmcs', a simple tcp multicast server, before starting any of the animation client programs. 'tmcs' will tell on which host/port it is listening. Then, when starting an animation client program, it is given the address (hostname, port number) on which the just started 'tmcs' is listing.

Rationale/Motivation

The architecture was developed to support the following goals: (the following list is probably incomplete)
  • it must be possible to (re)use them outside TorX without any problem
  • the tools must not have TorX-specific features; instead they must be general enough to be generally useable
  • each of the tools should use 'natural' input languages, where needed we use translators from TorX-specific formats to these 'natural' languages
  • the tools must not do too much ('do one thing and do it well')
  • it must be possible to use indivual tools in isolation
  • 'integration' of the tools (like e.g. for the 'connected' stepping through the animation sequence) should be done via external means (e.g. on the shell level) to allow use of the several tools in isolation
  • the tools should work cross-platform
  • the 'interface' between the user and the animation tools must be (programming)language indepent
  • at the end of an animation 'run' the viewers must still be running
  • it must be possible to (automatically) reuse the windows in which the animations are shown -- to avoid desktop clutter, and to avoid 'by hand' closing of all animation windows that are no longer needed

History/Background

These tools were not developed because we were interested in development in this area. We would rather have (re)used tools developed by others, if we would have been able to find them.

These tools were developed out of nececessity: the functionality we looked for seemed to be unavailable (or at least not available in the form in which we wanted it).

The mscviewer was developed first, by 'reusing' and hacking msc viewing code from xspin. Initially it was part of the 'xtorx' graphical user interface of TorX. In a next step it was decoupled and made into a separate component, using (a small subset of) the standard msc notation as input language. Here the client/server approach was prototyped.

The graph animation viewer was started as 'jararacy' by extending 'dotty' with a means to do 'remote controlled' animation (coloring of nodes). It used animation commands that were TorX-specific. However, because it was (seemed) impossible to reuse the dotty window for a subsequent animation, and it proved cumbersome to manually close each jararacy window the graph animation functionality was rewritten as 'anifsm' in tcl/tk using tcldot. Initially this used the same TorX-specific animation commands. In a next step the animation language was made more general, using only general concepts like colors, nodes and edges. Currently we are extending this with editing features 'lifted' from doted, to allow simple editing of the graphs (add/delete nodes/edges, change attributes), and (interpreting the graph as automaton) writing it out in the Aldebaran .aut format.

The progress bar was made 'on a whim' to visualize progress in timed testing.

The Mcontrol slider bar was made to demonstrate the simplicity of the 'tmcs'-based connection aproach, and because, even though all the animation tools have buttons to single-step through the animation sequence, the functionality of the slider was not available in any of them.

Questions and Support

For all questions and support contact Axel.Belinfante@cs.utwente.nl

This page has last been updated by Axel Belinfante on Wednesday, 8 March 2006.