[ Home Page ] [ Eiffel Archive ] [ Eiffel Classes and Clusters | Eiffel Applications ]
Written by Michael Kaufmann, Harald Lauer, Matthias Ettrich and Klaus Soukup
http://www-pr.informatik.uni-tuebingen.de/Research/GraVis/GraVis.html (GraVis Home Page)
Efficient and effective information visualization is crucial in many application domains and is becoming even more important, since the amount of data users are expected to handle is increasing rapidly. One of the best ways to model data and its dependencies are graphs, but this alone is limited without the ability to visualize these graphs. Thus there is a growing need of graph drawing systems and automatic graph layout generation.
GraVis has been designed to serve as a visualization tool usable in many application domains. To accomplish this, our main design goals have been extensibility and flexibility. The essence of these goals are that we did not want to introduce arbitrary limitations in the capabilities of GraVis like many of its predecessors did, and we wanted to give the user of GraVis the opportunity to create his own extension modules increasing the usability of GraVis in his or her particular application domain.
Anyone who has to work with large sets of data is a potential user of GraVis. This includes but is certainly not limited to application domains like software engineering, database systems, network management and many more. Last but not least GraVis is of course also a tool suited for research in the area of graph algorithms and graph drawing. Since this is the main area of interest of our research group, suggestions about new applications domains and its requirements are always welcome. Please contact us and we may even be able to design a layout algorithm especially for your needs.
The design of GraVis includes elements making it a generally usable tool for information visualization, if this data is representable as graphs. This generality forces GraVis to be both extensible and flexible. To be concrete, the following design elements realize these goals:
The functionality described in the list is implemented and working
These screenshots show the kinds of graphs that can be displayed. The first is generated by the Kandinsky Layout Module, and the second by the Tree Layout Module.
Some of the important features mentioned at the beginning of this page are now described and explained more detailed, such that the design goals and their usefulness become clearer. The following diagram gives an overview over the general structure of GraVis.
GraVis is devided into six modules or classes of modules. The top row represents the kernel system with the exception of the visualization component (or Viewer), which may also be regarded as an external module since it is not necessary for the kernel to operate. The bottom row represents the tools and extension modules with the special characteristic that they are easily interchangeable, such that eg. some algorithm may be implemented and tested as a extension module and then compiled into GraVis as a tool - or vice versa.
The arrows between the modules represent the communication links used for command and information exchange. Since each module communicates with the others by using a communication port, the modules are highly independent of each other.
The kernel of GraVis implements the base functionality of the graph drawing system and consists of the Dispatcher and the Documents. The role of the dispatcher is to control the startup, execution and shutdown of GraVis by handling and resending command objects.
The design philosophy in GraVis follows the object-oriented paradigma and the system is accordingly implemented in the object-oriented programming language Eiffel. To achieve our goal of maximum flexibility and extensibility, the design uses several techniques described in greater detail on the language page of GraVis. Important here are the design patterns, namely the observer and the command pattern. Both are used in the Dispatcher to implement the communication concept, which is based on sending command objects between the various modules. The observer pattern controls the receivers of the command objects.
Multiple graphs are represented by one Document each, which is the other important component of the kernel system. The base of a document is the powerfull graph data structure used throughout the system. As indicated in the structure diagram, graphs are realized as a class hierarchy supporting two- and three-dimensional coordinates. The Document controls and handles access to the graphs via the communication interface. The command objects received by a document are stored on a stack, implementing the undo/redo mechanism supported by GraVis.
One of the highlights of GraVis is its intuitive user interface implemented in the visualization component. The Viewer itself is highly optimized such that even large graphs can be interactively manipulated with minimal slowdown. With all these optimizations the Viewer still supports the complete set of graphical attributes necessary for effective graph visualization. Among these attributes are:
Elimination of extensive input mode changing was the primary design goal of the user interface. Creating and modifying a graph is very easy and fast in GraVis since almost every important operation can be performed with the left mouse button. The behaviour changes according to the context where the button event occured, such that creating nodes, edges and bends, moving them or creating selections can be done rapidly. The right mouse button is reserved for delete operations which can affect single graph elements or whole selections. Finally, the middle mouse button represents special functions like label editing.
Extending the functionality of the graph drawing system is an important aspect of GraVis. The extension facility is mainly used to make new graph algorithm modules available for the system. However, the facility provides also the important possibility to add communication interfaces to other applications such that GraVis serves as a visualization frontend. These applications can be very complex like a CASE tool or very simple like a printing service using a format not directly supported by GraVis.
Extension modules, which are either standalone or directly compiled into GraVis, are independent of the rest of the system and thus form a module and algorithm library. This library can be used within other applications provided that the standard interface of the modules is supported.
When used directly in GraVis, extension modules may interact with the base system in various ways. They can monitor the user input to implement incremental graph layout algorithms or they can activly update the Viewer while executing an arbitrary graph algorithm, thus animating it. Using this interaction scheme, external applications communicating with GraVis receive their data and update the Viewer with new data they generate.
GraVis is the result of the effort of a dedicated group of people and is managed by the Parallel Computing Group at the University of Tübingen.
Team Member Task Contact Information Michael Kaufmann Boss firstname.lastname@example.org Harald Lauer Also Boss, but responsible for design and kernel system, data structures, extensions and everything that is wrong and/or missing. email@example.com Matthias Ettrich Display engine, user interface, communication, and many suggestions/ideas/... firstname.lastname@example.org Klaus Soukup 3D viewer, skip lists email@example.com
Copyright (c) 1994-1997 University of Tuebingen, Germany All Rights Reserved.
GraVis is copyrighted by the University of Tuebingen and the following terms apply to all files in the GraVis distribution. The authors hereby grant permission to use, copy and modify this software and its documentation for any purpose, except the ones mentioned in this copyright notice, provided that existing copyright notices are retained in all copies. No written agreement, license, or royalty fee is required for any of the authorized uses. Commercial use of GraVis without prior written permission isprohibited. GraVis must not be distributed without prior written permission. The terms of this copyright notice also apply to any modification to this software.
IN NO EVENT SHALL THE AUTHORS OR DISTRIBUTORS BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS SOFTWARE, ITS DOCUMENTATION, OR ANY DERIVATIVES THEREOF, EVEN IF THE AUTHORS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. THE AUTHORS AND DISTRIBUTORS SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. THIS SOFTWARE IS PROVIDED ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE NO OBLIGATION TO PROVIDE MAINTENANCE, SUPPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
Harald Lauer (firstname.lastname@example.org), 15 July 1997
[ Home Page ] [ Eiffel Archive ] [ Eiffel Classes and Clusters | Eiffel Applications ]