Binucci, Carla

Didimo, Walter

English

AbstractThe paper presents a software system for computing orthogonal drawings of graphs with labels on vertices and edges, while minimizing the area or the total edge length of the drawing. The system is thought mainly to support CASE tools in the automatic visualization of diagrams like UML diagrams and ER-diagrams.We thank Giuseppe Liotta and Maddalena Nonato for their useful discussions

Elsevier - Publisher Connector 

A Software System for Computing Labeled Orthogonal Drawings of Graphs 

Open Access Repository

A Software System for Computing LabeledOrthogonal Drawings of Graphs(Extended Abstract)Carla Binucci1Dipartimento di Ingegneria Elettronica e dell'InformazioneUniversita di PerugiaPerugia, ItalyWalter Didimo2Dipartimento di Ingegneria Elettronica e dell'InformazioneUniversita di PerugiaPerugia, ItalyAbstractThe paper presents a software system for computing orthogonal drawings of graphswith labels on vertices and edges, while minimizing the area or the total edge lengthof the drawing. The system is thought mainly to support CASE tools in the auto-matic visualization of diagrams like UML diagrams and ER-diagrams.1 IntroductionThe increasing complexity of software systems and information systems hascaused a signicant demand of technologies for the automatic visualization ofdiagrams, like for example UML diagrams and ER-diagrams (see Figure 1).These diagrams can be modeled by graph structures, where vertices representobjects and edges represent relationships between pairs of objects. In addition,textual or graphic labels are usually associated with vertices and edges of thediagrams.Several CASE tools oer sophisticated graphic editors to create diagramsused in the design of a software or in the design of a database, but it is still1Email: binucci@diei.unipg.it2Email: didimo@diei.unipg.itPreprint submitted to Elsevier Preprint81poor the supply of functionalities to automatically draw diagrams in such away that they are \readable" for the user. Readability of diagrams is usuallyreached by taking into account the optimization of several drawing aesthetics,like for example the area occupied by the drawing, the length of the edges, thenumber of crossings between edges, vertices, and labels, the number of bendsalong the edges, the angular resolution of the edges.MovingdownMovingupIdleMoving to firstfloorOnfirst floorgo down(floor)arrive atfloorgo up(floor)arrive atfirst floorgo up(floor)time outarrive atfloor(a)Afferenza DIPARTIMENTOComposizionePartecipazioneSEDEIMPIEGATOPROGETTO(1,1)Direzione(0,1)(0,N)(1,N)(1,1)(1,N)(1,N)(0,1)(b): AccordoSharing:RegistraAccordoUI:Viaggio: CarSharer3: * get ID car sharer(): ControlloRegistraAccordor7: aggiungi viaggio()5: get ID viaggio()2: crea accordo sharing()AmministratoreCarMatch6: trova per ID()9:[primoAccordo=null]   set primo accordo()1: imposta dettagli()8: set accordo sharing()4: trova per ID()nuovoaccordo()(c)Fig. 1. Diagrams from real-world applications. (a) A state-transition diagram, (b)an ER-diagrams, (c) A collaboration diagrams.From the above motivations, the problem of computing drawings of graphswith labels on vertices and edges has been widely investigated in the graphdrawing and computational geometry communities. Most of the results inthe literature assume that the vertices and the edges of the graph have beenalready drawn, and concentrate only on the placement of the labels. See forexample [7,8,9,12,13,15]. These assumptions however can represent a severelimitation to the readability of the nal drawing in many applications. Forexample, in the drawing of UML diagrams and ER-diagrams, there are nomotivations to consider the geometry of vertices and edges as predened. In-82stead, the geometry of vertices and edges can be computed in such a way tofree up space for the insertion of the labels.In this paper we present a software system that computes labeled drawingsof graphs in the orthogonal drawing convention. An orthogonal drawing is suchthat vertices are drawn as points or boxes of the plane and edges are drawnas sequences of vertical and horizontal segments between their end-vertices.Several kinds of diagrams used in the software engineering and informationsystem areas can be represented by labeled orthogonal drawings. Namely, weare interested in those diagrams where vertices are represented as boxes thatcan host their associated labels (see for example Figure 1). Our system allowsthe computation of a labeled orthogonal drawing while minimizing the area orthe total edge length of the drawing. Note that, the problems of computinglabeled or unlabeled orthogonal drawings of minimum area or minimum totaledge length have been shown to be NP-complete [14]. The drawing algorithmsof our system are based on recent results presented in [2], in which, for therst time, strategies are provided for the computation of labeled and unlabeledorthogonal drawings with minimum area. Previous results concentrate on theminimization of total edge length and only deal with vertex labels [11,10]: also,vertices are always represented as points and their labels are placed aroundthem. This model is not suitable for the diagrams we are interested in.The paper is organized as follows. Section 2 recalls basic denitions ongraph drawing and introduces the labeled orthogonal drawing standard adoptedby our system. Section 3 describes the architecture and the functionalities ofour system. Section 4 sketches some algorithmic ideas that is behind oursystem. Conclusions and open problems are given in Section 5.2 Labeled Orthogonal DrawingsLet G be a graph. A drawing   of G maps each vertex v of G to a distinctpoint pv of the plane and each edge e = (u; v) of G to a simple Jordan curveof the plane between pu and pv: vertices pu and pv are called end-points of e.Drawing   is planar if no two edges intersect, except at common end-points.A graph is planar if it admits a planar drawing.A planar orthogonal drawing G is a special planar drawing of G on theplane, where edges are drawn as sequences of horizontal and vertical segments.More formally, a planar orthogonal drawing of G is such that: Each vertex v of G is mapped to a distinct point pv of an integer coordinatesgrid of the plane; Each edge (u; v) of G is mapped to a sequence of horizontal and verticalgrid segments between pu and pv. We call these segments edge-segments. No two distinct edges intersect except at common end-points.83Fig. 2. A labeled planar orthogonal drawing. Red (light) boxes representedge-labels. Blue (dark) boxes represent vertices.A planar graph G admits a planar orthogonal drawing if and only if everyvertex of G has degree at most four, where the degree of a vertex is thenumber of its adjacent vertices. Several extensions of the original denitionof orthogonal drawing have been provided in the literature in order to dealwith vertices of degree higher than four. These extensions use to representvertices as boxes instead of points. Some applications allow boxes representingdierent vertices to have dierent sizes [16,1]; other applications require thatall the boxes have the same size [3].A class H of planar orthogonal drawings of G that dier only for the lengthof some edges is called a planar orthogonal representation ofG. In other words,an orthogonal representation of G species: For each edge e ofG, the sequence of left and right turns (bends) encounteredalong e moving from a predened vertex of e; For each vertex v, the value of the angle formed by every pair of edgesincident on v that are consecutive in the clockwise order around v.A classical graph drawing problem is to determine a planar orthogonaldrawing   of G within a given orthogonal representation of G, in such a waythat either the area or the total edge length of   is minimized. Both theversions of this problem have been shown to be NP-complete [14].We consider the problem of computing planar orthogonal drawings of G =(V;E) with labels on edges and vertices, while minimizing the area or thetotal edge length of the drawing within a given orthogonal representation Hof G. Each label is represented as a box with predened height and width.We call edge-label and vertex-label a label of an edge and a label of a vertex,respectively. We suppose that each edge and each vertex can have only oneassociated label.More formally, let LE (LV ) be a set of edge-labels (vertex-labels) of G, eachof them with associated height and width. A labeled planar orthogonal drawing84of (G;LE; LV ) within an orthogonal representation H of G is a drawing   suchthat:(i) G is drawn as a planar orthogonal drawing within H. The vertices of Gthat have no labels are mapped to grid points. Each vertex v that hasa label v is drawn as a box with the height and the width associatedwith v: v does not intersect other vertices and edges, except its incidentedges.(ii) Each edge-label e of e is drawn as a box that has the height and thewidth of e and that has one side properly contained in a segment of e.Label e does not intersect other edge-segments, vertices, and edge-labels.Figure 2 shows an example of a labeled planar orthogonal drawing.3 High Level Description of the SystemThe system we present computes a labeled orthogonal drawing of a graph Gwhile minimizing the area or the total edge length of the drawing within agiven orthogonal representation H of G.The whole system integrates dierent software technologies. It uses theGDToolkit graph drawing library [5], the Microsoft Visual Basic program-ming language, the AMPL [4] language for mathematical programming, andthe CPLEX solver [6]. The general architecture of the system is depicted inFigure 3.                                                      moduleODO  moduleIDG(G, L  , L  , H)E VΓAMPLCPLEXVBapplicationapplicationapplicationSystemGDToolkitAMPL instance file XML file XML fileFig. 3. The general architecture of the system.The system computes labeled orthogonal drawings of minimum total edge85length based on an ILP (Integer Linear Programming) formulation. Somealgorithmic ideas are given in Section 4. A more detailed description of theILP formulation can be found in [2].To deal with the ILP problem the system uses the AMPL language, whichallows the programmer to keep distinct the description of the model and thedescription of the instances of the ILP problem. The model of the ILP problemis an abstract specication of the objective function, variables, and constraintsof the ILP problem, and it is stored in a le with a specic le format. Eachinstance of the ILP problem describes concrete data according to a specicinput labeled graph, and it is stored in a le with a format that is dierent fromthe ILP model le format. Dierent instances of the same ILP problem arestored in distinct les, but are described with respect to the same model. Torun a computation of the ILP problem the system uses the well known CPLEXsolver. AMPL provides the interface to access the CPLEX functionalities.The main module of our system is the ODO module (Orthogonal DrawingOptimizer module). It oers a graphical user interface written in the MicrosoftVisual Basic programming language. This interface allows the user to load aninstance of the ILP problem (given in the AMPL instance le format) andto run a computation over this instance. The user can decide if he wants toperform the minimization of the total edge length or the minimization of thearea. In the latter case, the whole execution consists of several computationsof ILP problems that are slight variations of the ILP problem for total edgelength. During the execution the current best drawing is repeatedly updatedand shown on an area that is embedded in the graphical interface, and severalstatistics about the drawing quality (like area and total edge length) andabout the performance of the computation (like CPU time and number ofILP computations) are shown in a distinct panel. The user can benet fromthese real-time information for two main purposes: (i) He can use them tounderstand the behavior of CPLEX algorithms on dierent instances, andhe can tune some algorithm parameters in order to make the computationsfaster. (ii) He can decide to prematurely stop the execution if the current bestdrawing already matches his aesthetic requirements. This is useful especiallyfor long time computations.At the end of an execution, the user can save the labeled drawing   ina specic XML le format, which can be handled by dierent real-world ap-plications in the software engineering eld. The XML format is that denedin the GDToolkit library. The ODO module oers also the option of automat-ically loading and running a block of instances and saving, in a unique le,the statistics of every execution. In this sense, the module can be used as aplatform for experiments. Figure 4 shows a snapshot of the graphical interfaceof the ODO module.86Fig. 4. A snapshot of the ODO module. In the orthogonal drawing, red (light)boxes represent edge-labels and blue (dark) boxes represent vertices.The generation of the les that dene the instances in the AMPL for-mat is performed by the IDG module (Instance Data Generation module).This module is written in the C++ programming language and based on theGDToolkit graph drawing library. It receives as input a specic XML ledescribing a labeled graph (G, LE, LV ) along with an orthogonal representa-tion H of G, and takes advantage of the GDToolkit API to construct fromthe input information the description of the instance of the ILP problem interms of variables and constraints data. The module is also able to computean orthogonal representation of G if it is not provided one.4 Algorithmic AspectsOur system implements and/or integrates several algorithms both in the graphdrawing area and in the optimization problems area. In this section we givesome algorithmic ideas that is behind the system. A more detailed descriptionof the algorithms and their experimental results can be found in [2].The IGD module interacts with objects dened in the GDToolkit libraryfor representing graphs and orthogonal representations of graphs. By query-ing these objects, the IGD module constructs auxiliary objects for representingsegments that form edges, vertices, and labels. After that, these objects aretranslated into variables and constraints of the ILP problem. In particular,variables and constraints of the ILP problem represent all valid positions forthe edge labels and all valid points on which edges can be incident on a vertex87represented as a box. Constraints of the ILP problem must also guarantee theplanarity of the labeled drawing, in terms of edge, vertex, and label intersec-tions.The objective function of the ILP problem can be either the minimumtotal edge length of the drawing, i.e. the sum of the length of its edges, orthe minimum width or height of the drawing. The ODO module is also ableto compute a drawing of minimum area, by applying several times a modiedversion of the ILP problem, which allows us to compute a drawing of minimumwidth, under a certain constraint on the height. Namely, suppose that M isan upper bound on the height of a minimum area drawing. The algorithm forcomputing a drawing with minimum area works as follows. First, it computesa drawing   such that: (i)   has the minimum width among the drawings withheight less than M + 1; (ii)   has the minimum height among the drawingswith the same width as  . After that, the algorithm iteratively proceeds bylooking for a new drawing with the same properties as   among those of heightless than the height of  . The algorithm stops when it fails searching such adrawing. The upper boundM can be found easily. For example,M can be setequal to the number of horizontal segments of the orthogonal representationplus the heights of all labels. The algorithm above sketched can also be used,as a special case, for computing orthogonal drawings with minimum area ofgraphs without labels. Our system is the rst that implements an algorithmfor computing minimum area orthogonal drawings, both for the labels and forthe unlabeled version of the problem.Experiments performed with the system on a large test suite of labeledgraphs have shown that the algorithm for the minimization of the area requiresfew seconds for graphs with number of vertices up to 20, and it takes someminutes for graphs with up to 40 vertices. Long time computations can beneeded for graphs with more than 50 vertices. The experiments have beenperformed on a PC Pentium III, 800MHz, 512MB RAM capacity, WindowsNT operating system, and CPLEX 7.1. Also, a comparison with previousknown heuristics for the area minimization of labeled orthogonal drawings hasshown that the minimum area can signicantly improve the area of a drawingcomputed by the heuristics. The average improvements with respect to thebest known heuristic are between 10% and 20%, depending on the density(number of edges on number of vertices) of the graphs.5 Conclusions and Open ProblemsWe presented a system that computes orthogonal drawings with labels onvertices and edges, while minimizing the area or the total edge length of thedrawing within a given orthogonal representation. Our system is based on aninteger linear programming formulation presented in a previous work. How-88ever, this formulation is currently restricted to graphs with vertices of degreeat most four. Since our system is thought to support CASE tools in the auto-matic visualization of diagrams, it is crucial to extend the ILP formulation tographs with any vertex degree. Also, we are working to improve the eÆciencyof the algorithms for those graphs that have a high number of vertices.AcknowledgmentsWe thank Giuseppe Liotta and Maddalena Nonato for their useful discussions.References[1] G. D. Battista, W. Didimo, M. Patrignani, and M. Pizzonia. Orthogonal andquasi-upward drawings with vertices of arbitrary sizes. In Symposium on GraphDrawing (GD'99), volume 1731 of LNCS, pages 297{310, 2000.[2] C. Binucci, W. Didimo, G. Liotta, and M. Nonato. Computing labeledorthogonal drawings. In Symposium on Graph Drawing (GD'02). to appear.[3] U. Fomeier and M. Kaufmann. Drawing high degree graphs with low bendnumbers. In Proc. GD '95, volume 1027 of LNCS, pages 254{266, 1996.[4] R. Fourer, D. M. Gay, and B. W. Kernighan. AMPL: A modeling LanguageFor Mathematical Programming. Duxbury Press / Brooks/Cole PublishingCompany, 1993.[5] GDToolkit. On line: Graph drawing toolkit: http://www.dia.uniroma3.it/gdt.[6] ILOG CPLEX. http://www.ilog.com/products/cplex.[7] K. G. Kakoulis and I. G. Tollis. On the edge label placement problem. InSymposium on Graph Drawing (GD'96), volume 1190 of LNCS, pages 241{256,1997.[8] K. G. Kakoulis and I. G. Tollis. An algorithm for labeling edges of hierarchicaldrawings. In Symposium on Graph Drawing (GD'97), volume 1353 of LNCS,pages 169{180, 1998.[9] K. G. Kakoulis and I. G. Tollis. On the complexity of the edge label placementproblem. Computational Geometry: Theory and Applications, 18:1{17, 2001.[10] G. Klau and P. Mutzel. Combining graph labeling and compaction. InSymposium on Graph Drawing (GD'99), LNCS, pages 27{37, 1999.[11] G. Klau and P. Mutzel. Optimal compaction of orthogonal grid drawings. InInteger Programming and Combinatorial Optimization (IPCO'99), volume 1610of LNCS, pages 304{319, 1999.89[12] G. Klau and P. Mutzel. Optimal labelling of point features in the sliding model.In In Proc. COCOON'00, volume 1858 of LNCS, pages 340{350, 2001.[13] S. Nakano, T. Nishizeki, T. Tokuyama, and S. Watanabe. Labeling points withrectangles of various shape. In Symposium on Graph Drawing (GD'00), volume1984 of LNCS, pages 91{102, 2001.[14] M. Patrignani. On the complexity of orthogonal compaction. ComputationalGeometry: Theory and Applications, 19:47{67, 2001.[15] T. Strijk and A. Wol. The map labeling bibliography. on-line:http://www.math-inf.uni-greifswald.de/map-labeling/bibliography/.[16] R. Tamassia, G. D. Battista, and C. Batini. Automatic graph drawing andreadability of diagrams. IEEE Trans. Syst. Man Cybern, (1):61{79, 1988.90

A Software System for Computing Labeled Orthogonal Drawings of Graphs

file:///data/remote/core/dit/data/elsevier/pdf/6de/aHR0cDovL2FwaS5lbHNldmllci5jb20vY29udGVudC9hcnRpY2xlL3BpaS9zMTU3MTA2NjEwNTgwNTM0MQ==.pdf

A Software System for Computing Labeled Orthogonal Drawings of Graphs

Abstract

Similar works

Full text

Available Versions

Elsevier - Publisher Connector

Elsevier - Publisher Connector

Open Access Repository