Automatic Visualization of Abstract System Specifications

Automatic Visualization of Abstract System Specifications Axel Schneider, Stephan Walter Lucent Technologies Network Systems GmbH Nürnberg, Germany {aschneider, wstephan}@lucent.com Jan Langer, Ulrich Heinkel University of Technology Chemnitz, Germany {jan.langer, ulrich.heinkel}@etit.tu-chemnitz.de Abstract Complexity of hardware/software systems is continuously increasing. Formal specification is a methodology to ensure better quality of system specifications and to allow automated verification with tools like model checkers. Many formal specification approaches are known – ranging from programming languages to graphical specification tools. Each approach has its specific benefits. Usually, for abstract system and software specifications either table based or graphical notations are used. This paper presents a concept that leverages the advantages of both approaches by combining them in a single front-end. Both the table based and the graphical representation may be used for editing the specification. An automatic synchronization mechanism ensures that both representations are kept consistent. The implementation of the concept uses the table based formal language ADeVA and the Graphviz graph layout programs. 1. Introduction Usually the specification is the first step in the development of a hardware / software system. Even today, the method used most often for specifying a system is a textual description of its requirements in natural language. For a complex system the specification may consist of several thousand pages. Hence, the subsequent functional verification process is very time-consuming. Frequently, ambiguous, incomplete or incorrect specifications lead to defects, which are overlooked and cause considerable additional costs in later phases of the design process. That increases the demand for formal methods to specify and verify systems on a high level of abstraction. A number of formal specification methods Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006 for different abstraction levels are known, e.g. the programming-like B-method [1], the table based SCR (Software Cost Reduction) [2][3] and graphical specification tools like Statemate [4] or AutoFocus/AutoMode [5][6]. Lucent Technologies developed its own table based formal specification language ADeVA (Advanced Design and Verification of Abstract systems) [7][8] and the corresponding specification platform “SpecEdit”[9]. In ADeVA each table is the representation of a finite state machine (FSM). According to the number of states and transitions of this FSM the table can become very long and complex. In most cases, a graphical representation can help making large tables more manageable. This work presents the concept of an easy-to-use tool that automatically generates graphs from ADeVA tables and provides corresponding viewing and editing capabilities. Finally, it can synchronize the graphs with the tables to provide consistency between both representations. The layout of the ADeVA graphs will be realized using the Graphviz layout library. 2. ADeVA and SpecEdit ADeVA is a table based formal language for the abstract specification of hardware/software systems. A system is described as a set of asynchronous parallel automata communicating with each other [10]. Each automaton has a set of input signals and drives exactly one output signal, i.e. its state. To describe an automaton, ADeVA basically provides two kinds of tables: Mode Transition Tables (MTT) are used to model the system’s control flow and Data Transformation Tables are intended to describe data value transformations. Table 1. MTT for the signal Q of a D-flipflop From false To true Condition Table 2. DTT for the signal Out of a counter Output D Clk Reset T @T F Out Out true false F @T F true false - - @T Each line of an MTT represents a transition. The state signal changes from the value in the first column to the value in the second column if the conditions in the following columns are satisfied. So the first line of Table 1 predicates that the output signal Q changes from false to true if D is true, clk becomes true and reset is false. The @ symbol indicates that the corresponding input signal has to change to the following logical value at the current time to satisfy the condition. If an input signal has no influence on a certain condition it is don’t care which is symbolized by a hyphen. A DTT, like the one in Table 2, is read line-by-line, too. The signal in the first row changes to the value in the second row (independent of its old value) if the subsequent conditions are true. Condition Incr Decr Out + 1 @T F Out - 1 F @T The specification platform SpecEdit supports the compilation and maintenance of ADeVA specifications. Moreover, it provides generators for the specification documents that are needed for the subsequent development phases. The document generator automatically combines all parts of the formal ADeVA specification (text fragments, tables, data type definitions etc.) into a standard documentation format. Figure 1 shows a screenshot of SpecEdit’s user interface. SpecEdit allows loading additional plug-ins. For verification purposes a model checking plug-in exists, which checks arbitrary properties for validity. The properties can be written in PSL, LTL or CTL. To exchange data with its plug-ins, SpecEdit exports the data using an XML format. Figure 1. SpecEdit user-interface Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006 Value 3. Automatic graph drawing An essential feature of the tool is the automatic visualization of graphs, whose structural information exists only as tables. Therefore, we first want to analyze common methods of automatic graph drawing and evaluate their usability for accomplishing the special task of drawing finite state machine diagrams (bubble diagrams). 3.1. State of the art The known graph drawing algorithms can be divided into two classes. On the one hand, hierarchical algorithms try to achieve good layouts by assigning the nodes of a graph to discrete ranks. Reordering the nodes in the ranks to avoid edge crossing can optimize the appearance of the graph. The layout can be radial or directed. The problem of these algorithms is: The results are strongly dependent on the initial order of the nodes. As a matter of principle, it is impossible to pin nodes to given positions. This is needed to allow dynamic updates between the tabular and the graphical representation of the graph without changing those parts of the graph, which were placed manually. On the other hand, there are algorithms that use a physical model. Nodes are represented by objects, which are influenced by forces. A good layout is obtained by finding a configuration of these objects, which minimizes the forces or total energy within the system. The forces don’t need to correspond to true physical forces, and typically the solution represents a local minimum. In the following, two major approaches are mentioned: The Kamada Kawai Algorithm [11] assumes that there is an ideal spring between every possible pair of nodes, such that the length of the spring is set to the shortest path distance between the endpoints. The algorithm attempts to minimize the energy in the system. The algorithm proposed by Fruchterman and Reingold [12] uses springs between nodes connected with an edge, and a repulsive force between all pairs of nodes. It achieves a layout by minimizing the forces applied to the nodes. The main disadvantage of these algorithms is: During layout they handle nodes, as if they were ideal points. The attractive and repulsive forces that are decreasing with the distance are directly applied to these points. However, the nodes of bubble diagrams are circles with a certain radius. This is necessary because the nodes hold information, such as the corresponding value of the state variable. One of the main aspects of bubble diagrams is the visibility of all Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006 information. On the other hand, if we have a tightly connected complex graph and the nodes are handled as points, it is easily possible that the nodes overlap each other, i.e. the distance between them is smaller than twice the radius. Even at such a small distance the resulting repulsive forces might not be strong enough to separate the nodes. Although, it is possible to detect overlaps automatically and to run another algorithm afterwards to eliminate these overlaps, this can disarrange the whole graph – even positions of those nodes that were placed by hand. So, this solution is not appropriate for our particular application. Another problem is that these algorithms have no functionality for routing the edges of the graph. Edges are drawn as simple lines. Multiple edges between two nodes overlap each other. Finally, we conclude that no known layout algorithm satisfies all demands of the required tool. The solution must be a new algorithm developed from scratch or a mixture and optimization of known graph drawing algorithms. For our application, we decided to develop an optimized graph drawing algorithm based on the algorithm proposed by Fruchtermann and Reingold. 3.2. The Graphviz package The Graphviz-Package is a library and a set of programs for computing well-structured layouts for graphs [13]. It has been developed at AT&T and is available under the Common Public License. The layout programs read descriptions of graphs in a simple textual format named DOT and produce diagrams in several useful representations, e.g. as bitmap or vector images, such as Scalable Vector Graphic (SVG) or PostScript (ps). Graphviz offers a wide variety of different layout algorithms. For example, the program neato provides “spring model” layouts using the Kamada-Kawai algorithm, fdp uses the Fruchterman-Reingold algorithm and dot draws hierarchical graphs. 4. The optimized layout algorithm Similar to the algorithm of Fruchterman and Reingold (FR) we use attractive forces (springs) between nodes connected by an edge and repulsive forces between each pair of nodes. The springs have a simple linear characteristic curve of the type Fs = K ( x − l ) where K is the spring constant, l is the length of the spring if it is not expanded, x is the current length of the spring and F is the resulting force. We did not change anything at this point. The repulsive force can be understood as a special electrostatic field. FR uses a field of the type Ff = a x where a is a constant value, x is the distance to the center and F is the resulting force. At a very small distance the resulting force approaches infinity and the algorithm has to limit such radical forces. However, at a larger distance the force decreases too fast. Figure 2 shows the characteristic function of F. Ff the little forces. So the last step is to shift down the characteristics of the force field such that it intersects the x-axis. We define this point to be at distance x = 2r+l where l shall be the “length” of the force field. Finally we obtain the equation Fmax in x < 2r     − Fmin    ( x − 2r ) ln    F −F     max min  Ff =    l + 2r        −F  F F e else ( ) − ⋅ min min  max Now nodes far from each other will be attracted by the force field. If there are only two nodes without an edge between each other, they will be placed at a distance of l. The characteristic of the final equation is shown in Figure 3. Ff Fmax 1 0 0 0 x a Figure 2. Force field of the Fruchtermann-Reingold algorithm So the first idea was to replace this field by an exponential force field: Ff = a ⋅ e − x b Now the force at x = 0 is one and not infinite. Hence, the maximum force is a. The parameter b can be used to tune the range of the field (e.g. at 2 ⋅ b only 5% of the maximum force is left.) At zero distance we still have a steep gradient, so we insert a shift of the whole function to the right by two times the radius r and replace the function in the region (0 ≤ x < 2r ) by the constant a: a  x − 2r Ff =  (− ) a ⋅ e b in x < 2r else This way, the nodes are not handled as ideal points anymore. They are treated as electrically charged plates now. The effect is that as long as two nodes overlap they repel each other with the maximum force a. Together with the attractive spring forces, this model will achieve good results for small graphs. But as the repulsive force will be positive at any distance a large graph will tend to be straddled by the sum of all Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006 Fmin x 2r l + 2r Figure 3. Characteristic of the final equation To calculate the optimal position, we use an iterative solver, similar to the solver used in the Fruchteman Reingold algorithm, which tries to minimize the forces applied to the nodes. There are the following operations to be done in each iteration: • First, we calculate the force of the field between each possible pair of nodes and add this force to the corresponding node’s displacement vector. • Then we calculate the force of the spring for each edge and add this force to the displacement vector of the nodes connected by this edge. • Finally, for each node we add the node’s displacement vector to its position and reset the displacement vector to zero. An optimum state is reached when the sum of the absolute values of all applied displacements reaches a certain threshold value. Figure 4 shows two graphs, on the left side as drawn by the algorithm proposed by Fruchterman and Reingold (a and c) and on the right side as drawn by the optimized algorithm. We realize that the nodes of graph b) are distributed more regular and the corners of the whole triangle are less spiky. Graph d) shows that nodes of subclusters are placed nearer to each other. For our application these results are more useful. a) b) c) d) Drawn by the Fruchtermann and Reingold algorithm Drawn by the optimized algorithm Figure 4. Layout examples This algorithm can also be used for the layout of the edges. After the placement, we restrain the positions of all nodes. Subsequently, the edges are split into at least two subedges. At the split point we insert a virtual node connecting both subedges. The algorithm can now be run again to place the virtual nodes. Finally the edges are drawn as splines with the computed positions of the virtual nodes used as control points. A simple example for the automatic drawing of the edges is shown in Figure 5. The big circles are the actual nodes of the graph. The smaller circles are the inserted virtual nodes. Their positions are used to draw the grey spline edges. Finally, the optimized graph drawing algorithm was filed for patent application. Figure 5. Drawing edges Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006 more details need to be defined (e.g. precise transition conditions) the drawings are manually converted into tables. Additionally, a designer, who needs to understand the tables, starts with converting them back into a simplified graph on a sheet of paper. If details are needed, the engineer again takes this information from the tables. Hence, experience shows that it is necessary to support both tables and graphs in parallel to be able to choose the most appropriate way, depending on the current situation. The basic concept of a tool that is capable of handling both domains is illustrated in Figure 6 and further explained in the following chapters. 5. A graph generator and editor for ADeVA specifications 5.1. Motivation ADeVA tables may be very large for complex systems. Although tables are easy to store and to process by a computer, they become increasingly unclear and confusing for a human brain. It is difficult to analyze large tables to get an understanding of their meaning. The practical experience with ADeVA and SpecEdit [14][15][16] shows that the specification engineer normally starts with a simple drawing on a sheet of paper. Once the graph gets too complex and SpecEdit Graph Editor Initial transformation DOT Translation Translation toto DOT DOT DOT Graphviz Graphviz Without position data Export Export vector vector// pixel pixel graphic graphic Import Import from from DOT DOT Contains position data Change tracking table → graph OD SynchronSynchronization ization Graph instance XML Relayout Relayout XML Change tracking graph → table Translation Translation toto OD OD Save / load XML Split/ Split/ merge merge data data User User Figure 6. Graph Editor overview Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006 GUI GUI 5.2. Basic requirements A powerful tool to automatically transform ADeVA tables into graphs needs to fulfill at least the following requirements: • It shall be possible to edit the graph by hand. • Manual changes must be preserved. • The tool has to track changes in the original table and automatically extend the graph. • In any case, there must not be any inconsistency between the graph and the table. • A conversion of the graph into standard image formats must be supported to feed the SpecEdit document generator and to be processed with external tools For expansion with new functionality, SpecEdit provides a simple plug-in-mechanism. Whenever a piece of the specification is selected to be shown in the editor, SpecEdit passes the internal data to all connected plug-ins via a custom data structure, the so called Object Data (OD). To gain access to SpecEdit’s internal data the plug-ins can manipulate the received OD with the help of a set of predefined functions. Furthermore, all plug-ins have the possibility to store additional private data in the XML database. This is useful to store the manual layout changes of the user. The graph editor tool is realized as such a SpecEdit plug-in. 5.3. Initial transformation from tables to graphs A common case is the visualization of an existing tabular specification item. The initial transformation can be performed using the Graphviz-Package. Therefore, we have to translate SpecEdit’s OD format into Graphviz’s DOT-language. This description is used as input for Graphviz. The package supports a variety of image formats that could be directly displayed. However, such images are of little use as later changes of the automaton must be conveniently applied to the graph. Hence, we chose to process the data and output it in the DOT-format again but the output now contains additional position data for nodes and edges. Finally, we parse the output and store all information in a custom XML tree structure. The graph, which is stored in this tree, can now be displayed. Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006 5.4. Synchronization graphs between tables and The module, which is responsible for displaying the graph, also holds all necessary functionality to edit it. Basically, we provide the possibility to add or delete edges and nodes or to edit their properties such as size and position. Whenever the user makes changes in the graphical representation we have to update SpecEdit’s internal database. Therefore we translate the structural information in the XML tree to OD and pass it to SpecEdit. The other way around, it is necessary to track changes that were made in the tabular representation to update the graph accordingly. The pure detection of changes is fairly easy. It is also easy to remove elements of the graph in case the corresponding data was removed from the table. But if the table was extended we have to place the new elements in the graph automatically without changing parts of the graph that the user placed manually. We intend to preserve user changes because the user knows why he placed the elements as he did and we don’t want to destroy his work. Another criterion for the placement is to avoid overlapping of the new nodes with already existing elements. To obtain a solution we must have the possibility to determine whether an element of the graph was placed by hand or by the layout algorithm. Therefore, we allow locking elements by introducing an additional “don’t touch” attribute. Manually placed elements are locked for replacement automatically. Besides, the user may lock the whole graph in its current appearance. Now, we are able to decide between two cases. In case no element of the graph is locked (or the user explicitly unlocked all elements) we are allowed to relayout the whole graph using the same mechanism that is used for the initial transformation. The second case is that one ore more elements are locked. If so, we must use a layout algorithm, which allows pinning, i.e. to be able to handle nodes with a fixed position. By principle the Kamada-Kawai algorithm or the Fruchermann-Reingold algorithm can be used, but often they produce overlaps and they do not handle the layout of the edges. Hence we decided to use our own algorithm as proposed in Section 4. The application of this algorithm solves the mentioned problems as overlaps are avoided and the edges are correctly placed. 5.5. Import/Export Another functionality of the graph editor is its load/store capability. The plug-in mechanism uses a custom XML tree that contains all private data, thus we can easily pass this XML structure to SpecEdit. During the runtime of the program, the tree also contains the data that is already stored in SpecEdit’s internal database. To avoid redundancy we split this data from the tree before the XML structure is passed to SpecEdit. The other way around, the plug-in has to merge SpecEdit’s Object Data with the saved XML tree when the user loads an existing graph. The user may also want to use the graph within other applications and especially in the documentation of the designed system. So the graph editor has the ability to export the graph into more common formats like SVG or image formats. Furthermore, the document generator of SpecEdit is extended accordingly to place the graph images together with the corresponding tables into the specification document. 6. Summary Graphical and table based notations are wellknown methods for formal specification. A graphical notation is the most suitable way to get started with specifying a complex system. Furthermore, it allows quickly getting an idea of the general behavior of a system. On the other hand, tables are more detailed while being very clear and readable. The combination of a table based notation with a graphical notation integrated into one specification platform allows the specification authors and design engineers to choose the appropriate view of a specification depending on their individual needs. Both views may be used for changing the specification, while automatic updates ensure the consistency of tables and graphs. To achieve a layout of the graphical representation that fulfills our special requirements we developed an optimized graph layout algorithm. An implementation of the described concept is provided for the specification platform SpecEdit using the formal language ADeVA. It is expected to satisfy the needs for a flexible specification platform with convenient viewing and editing facilities. 7. References [1] S. Schneider, The B-Method: An Introduction, Palgrave, Cornerstones of Computing series, October 2001 Proceedings of the Sixth International Conference on Quality Software (QSIC'06) 0-7695-2718-3/06 $20.00 © 2006 [2] C. Heitmeyer, R. Jeffords, B. Labaw: “Automated consistency checking of requirements specifications”, ACM Transactions on Software Engineering and Methodology, 5(3): 231-261, 1996 [3] C. Heitmeyer, M. Archer, R. Bharadwaj, R. Jeffords: “Tools for constructing requirements specifications: The SCR toolset at the age of ten”, International Journal of Computer Systems Science and Engineering, 20(1): 19-35, January 2005 [4] http://www.ilogix.com [5] F. Huber, S. Molterer, B. Schätz, O. Slotosch, A. Vilbig: “Traffic Lights: an AutoFocus Case Study”, Proceedings of International Conference on Application of Concurrency to System Design, 1998 [6] D. Ziegenbein, U. Freund, P. Braun, R. Sandner, A. Bauer, J. Romberg, B. Schätz: “AutoMoDe – Model-Based Development of Automotive Software”, Conference on Design, Automation and Test in Europe (DATE), IEEE Computer Society, 2005 [7] W. Haas, S. Gossens., U. Heinkel: “Formal Behavioural Specification for Advanced Design and Verification of ASICs (ADeVA)“, GI/ITG/GMM Workshop Methoden und Beschreibungssprachen, Tübingen, Feb. 2002 [8] W. Haas, U. Heinkel, S. Gossens: “Integration of Formal Specification into the Standard ASIC Design Flow“, 7th IEEE/IEICE Int. Sympos. on High Assurance Systems Engineering HASE, Tokio, Japan Oct. 2002 [9] A. Schneider, T. Bluhm, T. Renner, U. Heinkel, J. Knaeblein, R. Zavala: “Formale Spezifikation und Verifikation abstrakter Beschreibungen von Telekommunikationsprotokollen“, 9. GI/ITG/GMM Workshop Methoden und Beschreibungssprachen, Dresden, Februar 2006 [10] W. Haas, U. Heinkel, S. Gossens: “Semantics of a Formal Specification Language for Advanced Design and Verification of ASICs (ADeVA)“, 11th E.I.S.-Workshop, Erlangen, Germany April 2003 [11] T. Kamada and S. Kawai: „An algorithm for drawing general undirected graphs”, Information Processing Letters, 31(1): 7–15, April 1989 [12] T.M.J. Fruchterman, E.M. Reingold: “Graph Drawing by Force-directed Placement.Software”, Practice and Experience, 21(11): 1129–1164, November 1991. [13] http://www.graphviz.org [14] A. Schneider, T. Bluhm, T. Renner, U. Heinkel, J. Knaeblein, R. Zavala: “Formal Verification of Abstract System and Protocol Specifications“, 30th IEEE/NASA Software Engineering Workshop, Columbia MD, April 2006 [15] A. Thomas, J. Becker, U. Heinkel, K. Winkelmann, J. Bormann: “Formale Verifikation eines Sonet/SDH Framers“, GI/ITG/GMM Workshop Methoden und Beschreibungssprachen, Kaiserslautern, Februar 2004 [16] W. Haas, T. Bürner, S. Gossens, U. Heinkel: “Formal Specification of a 40GBit/s Sonet/SDH ASIC with ADeVA“, FDL Forum on Design Languages, Frankfurt 2003