Studienarbeit GXL2SVG - Visualierung von Graphen in SVGist/documents/schricker2005sa.pdf3.7.3 Globale CSS-Denition innerhalb der SVG-Grak . . . . . . 21 ... um die Position von

Universität Koblenz-LandauInstitut für SoftwaretechnikProf. Dr. Jürgen Ebert

StudienarbeitGXL2SVG - Visualierung von

Graphen in SVG14. Dezember 2005

Florian Schricker

INHALTSVERZEICHNIS 1

Inhaltsverzeichnis

1 Einführung 4

2 GXL 52.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 TGraphen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.3 GReQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Scalable Vector Graphics 83.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Einheiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Einfache Formen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 Pfade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.6 Gruppen von Grafikobjekten . . . . . . . . . . . . . . . . . . . . . . 18

3.7 Cascading Style Sheets . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.7.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.7.2 Verwendung eines externen Stylesheets . . . . . . . . . . . . 21

3.7.3 Globale CSS-Definition innerhalb der SVG-Grafik . . . . . . 21

3.7.4 style-Attribut am Grafikobjekt . . . . . . . . . . . . . . . . . 22

3.7.5 Anwendungsreihenfolge . . . . . . . . . . . . . . . . . . . . 22

3.7.6 Gruppen und CSS . . . . . . . . . . . . . . . . . . . . . . . 23

3.7.7 Elementtyp-bezogene Styling-Attribute . . . . . . . . . . . . 23

3.7.8 Klassenbezogene Styling-Attribute . . . . . . . . . . . . . . 24

3.7.9 Instanzbezogene Styling-Attribute . . . . . . . . . . . . . . . 25

3.8 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Layoutverfahren 264.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 Layoutverfahren der GraphViz-Bibliothek . . . . . . . . . . . . . . . 26

4.3 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Die Layoutspezifikation 295.1 Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . . . . 29


5.1.1 Einheitensystem . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.2 Koordinatensystem . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.3 Grundlagen der Knotendarstellung . . . . . . . . . . . . . . . 30

5.1.4 Grundlagen der Kantendarstellung . . . . . . . . . . . . . . . 31

5.2 Layoutangaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Architektur 346.1 Designziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.2 UML-Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Layoutspezifikation als GSI-Repository 367.1 Überblick über GSI . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7.2 Realisierung der Layoutspezifikation als GSI-Repository . . . . . . . 36

7.3 Name-Ausdruck-Paare des Repositories . . . . . . . . . . . . . . . . 37

7.4 Allgemeine Layoutangaben . . . . . . . . . . . . . . . . . . . . . . . 38

7.4.1 Signatur des Informationssegments . . . . . . . . . . . . . . 38

7.4.2 Layoutverfahren . . . . . . . . . . . . . . . . . . . . . . . . 39

7.4.3 Größe der Gesamtgrafik . . . . . . . . . . . . . . . . . . . . 39

7.4.4 Hintergrundfarbe . . . . . . . . . . . . . . . . . . . . . . . . 39

7.4.5 Navigationsrahmen . . . . . . . . . . . . . . . . . . . . . . . 40

7.4.6 Farben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.4.7 Definition von Farben . . . . . . . . . . . . . . . . . . . . . 41

7.4.8 Definition einer Farbtabelle . . . . . . . . . . . . . . . . . . 41

7.4.9 Zugriff auf eine Farbtabelle . . . . . . . . . . . . . . . . . . 41

7.4.10 Definition eines Farbverlaufs . . . . . . . . . . . . . . . . . . 42

7.4.11 Auswahl aus einem Farbverlauf . . . . . . . . . . . . . . . . 43

7.5 Layoutangaben für Graphelemente . . . . . . . . . . . . . . . . . . . 44

7.5.1 Ebenen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.5.2 Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.6 Layoutangaben für die Knotendarstellung: . . . . . . . . . . . . . . . 45


7.6.2 Darstellungsstil . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.6.3 Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47


7.6.5 Schrift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48


7.6.6 Umrandung . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.6.7 Größe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.7 Layoutangaben der Kantendarstellung . . . . . . . . . . . . . . . . . 49


7.7.2 Darstellungsstil . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.7.3 Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.7.4 Label-Schrift . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.7.5 Terminal-Label . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.7.6 Terminal-Label-Schrift . . . . . . . . . . . . . . . . . . . . . 51


7.7.8 Kantensymbol . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.7.9 Kantenzug . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8 Anwendungsbeispiel 54

9 Fazit 589.1 Zusammenfassung des Entwicklungsverlaufs . . . . . . . . . . . . . 58

9.2 Schlussbemerkung . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

A Standard-Farbtabelle 59

B Zugriffsinformation der Layoutspezifikaten 60

C CD-Inhalt 62

1 Einführung 4

1 Einführung

In dieser Arbeit wird ein Werkzeug zur Graphvisualisierung vorgestellt.

Graphen, eine mathematische Struktur bestehend aus Knoten, verbunden durch Kanten(vgl. Abb.), bestehen in heutigen Anwendung meist aus vielen solchen Graphelemen-ten. Realistisch sind mehrere Tausend Knoten und mehr Kanten.

Als Eingabeformat für das Werkzeug bietet sich das Graph-Austauschformat GXL(Graph eXchange Language) an. GXL ist ein anerkannter XML-Standard und erlaubtdem Werkzeug das Einlesen und die Visualisierung von Graphen aus unterschiedlichs-ten Bereichen.

Um Graphen darzustellen, werden Layoutverfahren benötigt, um die Position vonKnoten zu bestimmen und um die Kantenverläufe zwischen den Knoten zu berechnen.Dieses Werkzeug nutzt für das Layouting von Graphen die GraphViz Bibliothek. UnterLayouting versteht man das Anwenden eines Layoutverfahrens, welches Knotenpositi-on und Kantenverläufe berechnet. GraphViz implementiert dazu drei Layoutverfahren,welche Graphen hierarchisch, symmetrisch oder radial darstellen. Aufgrund der CPL-Lizenz kann GraphViz in das Werkzeug integriert und die bereitgestellten Verfahrengenutzt werden.

Zusätzlich ist das Werkzeug so ausgelegt, dass weitere Implementationen von Layout-verfahren hinzugefügt werden können, sollten diese zu einem späteren Zeitpunkt zurVerfügung stehen.

Bei der Visualisierung von Graphen stoßen aktuelle Lösungen schnell an ihre Gren-zen; insbesondere bei Pixel-basierten Ausgabeformaten (Rastergrafiken) werden dieDarstellungen von Graphen schnell sehr groß und unübersichtlich oder auf zu wenigRaum werden Graphdarstellungen völlig unkenntlich.

Durch den Einsatz von Scalable Vector Graphics (SVG) bei diesem Werkzeug sollenDarstellungsprobleme dieser Art vermieden werden. SVG ist eine Sprache in XMLzur Beschreibung von zwei-dimensionalen Grafiken, die sich aus grafischen Primitivenzusammensetzen. Als Primitive stehen Kreise, Rechtecke, Ellipsen und Linienzüge zurVerfügung, die zusammengesetzt die fertige SVG-Grafik ergeben.

Obwohl GraphViz selbst bereits SVG unterstützt, sind, durch den Einsatz einer Lay-outspezifikation, weitaus flexiblere Visualisierungen möglich. Dies geschieht durchEinbeziehung des gegebenen Graphen: über eine Anfragesprache können Grapheigen-schaften in die Layoutspezifikation fließen, welche die Darstellung beeinflussen.

Ziel ist also ein Werkzeug, das über eine Layoutspezifikation, welche die Darstellungs-eigenschaften beschreibt, einen gegebenen GXL-Graphen mit SVG visualisiert. DieLayoutspezifikation bietet dabei eine möglichst flexible, unabhängige Beschreibungder Darstellung mit der Möglichkeit, den jeweils darzustellenden Graphen mit einzu-beziehen.

2 GXL 5

2 GXL

Das in dieser Arbeit vorgestellte Werkzeug zur Graphvisualisierung nutzt das XML-basierte Austauschformat GXL (Graph eXchange Language) als Eingabeformat fürGraphen.

2.1 Einführung

Entwickelt wurde GXL in Kollaboration verschiedener Universitäten, um einen XML-basierten Standard für den Austausch von Daten zwischen verschiedenen Tools zuschaffen ([GXL01]). Daran beteiligt sind:

• University of Waterloo• University of California• Darmstadt University of Technology• University of Koblenz-Landau

Daten werden bei GXL generell durch Graphen repräsentiert. Bei einem Graphen han-delt es um einen abstrakten Datentyp, bestehend aus Knoten und Kanten, die Bezie-hungen (Verbindungen) zwischen den Knoten herstellen.

2.2 TGraphen

Als Eingabe unterstützt werden in diesem Werkzeug Graphen der TGraph-Submengevon GXL; TGraphen sind angeordnete, gerichtete, typisierte und attributierte Graphen(vgl. Abb. 1). Das heisst:

• TGraphen bestehen aus einer geordneten, endlichen Folge von Knoten V undKanten E.• Alle Kanten haben einen, nicht notwendigerweise verschiedenen Start- und Ziel-

knoten.• Jedem Graphelement (Knoten oder Kante) ist ein Typ einer gegebenen Typmen-

ge zugewiesen.• Graphelemente, bzw. deren Typen, können Attribute (Name-Wert-Paare) enthal-

ten.

Neben TGraphen erlaubt GXL auch Hypergraphen und hierarchische Graphen. Diesewerden in dieser Arbeit aber nicht unterstützt.

2.2 TGraphen 6

v1 : Function

name = "main"

v4 : Function

name = "max"

v6 : Variable

name = "a"

v7 : Variable

name = "b"

v5 : Function

name = "min"

v2 : FunctionCall v3 : FunctionCall

e1 : isCaller

line = 8

e2 : isCaller

line = 19

e3 : isCallee e4 : isCalleee6 : isInput

e7 : isInput

e5: isInput e8 : isInput

{1}{1} {2}{2}

e9 : isOutput e10 : isOutput

Abbildung 1: ein TGraph (Quelle: www.gupro.de/GXL)

Der in Abbildung 1 gezeigt TGraph im GXL-Format1:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE gxl SYSTEM "http://www.gupro.de/GXL/gxl-1.0.dtd">

<gxl xmlns:xlink=" http://www.w3.org/1999/xlink">

<graph5 id="complexExample-instance" edgeids=" true" edgemode=" directed"

hypergraph=" false">

<type xlink:href="[...]#complexExampleSchema" xlink:type=" simple"/>

<node id="v1">

<type xlink:href="[...]#Function" xlink:type=" simple"/>

10 <attr name=" name"><string> main</string></attr></node>

<node id="v2">

<type xlink:href="[...]#FunctionCall" xlink:type=" simple"/></node>

<node id="v3">

<type xlink:href="[...]#FunctionCall" xlink:type=" simple"/></node>

15 <node id="v4">


<attr name=" name"><string> max</string></attr></node>

<node id="v5">


20 <attr name=" name"><string> min</string></attr></node<node id="v6">

<type xlink:href="[...]#Variable" xlink:type=" simple"/>

<attr name=" name"><string> a</string></attr></node>

<node id="v7">

25 <type xlink:href="[...]#Variable" xlink:type=" simple"/>

<attr name=" name"><string> b</string></attr></node>

<edge id="e1" to="v2" from="v1">

<type xlink:href="[...]#isCaller" xlink:type=" simple"/>

<attr name=" line"><int> 8</int></attr></edge>

30 <edge id="e2" to="v3" from="v1">

<type xlink:href="[...]#isCaller" xlink:type=" simple"/>

<attr name=" line"><int> 19</int></attr></edge>


<type xlink:href="[...]#isCallee" xlink:type=" simple"/></edge>


<type xlink:href="[...]#isCallee" xlink:type=" simple"/></edge>

<edge id="e5" to="v2" from="v6" toorder=" 1">

<type xlink:href="[...]#isInput" xlink:type=" simple"/></edge>


1 lange URLs in href -Attributen gekürzt;ersetze "[...]" mit "http://www.gupro.de/GXL/examples/schema/gxl/complexExample/complexExampleSchema.gxl"

2.3 GReQL 7

40 <type xlink:href="[...]#isInput" xlink:type=" simple"/></edge>






<type xlink:href="[...]#isOutput" xlink:type=" simple"/></edge>


<type xlink:href="[...]#isOutput" xlink:type=" simple"/></edge>

</graph>

50 </gxl>

2.3 GReQL

Die Einschränkung auf TGraphen im Rahmen dieser Arbeit ermöglicht die Verwen-dung von GReQL (Graph Repository Query Language) [GREQL01] zur Berechnungunterschiedlichster Metriken und anderer Eigenschaften eines gegebenen Graphen, umdiese zum Beispiel bei der Darstellung zu verwenden.Ein gegebener GXL-Graph muss sich demnach in einen TGraphen konvertieren lassen,um mit dem Werkzeug dieser Arbeit visualisiert zu werden.

Für weitere Beispiele und Informationen sei auf [GXL01, GXL02, GXL03] verwiesen.

2.4 Fazit

GXL ermöglicht es dem in dieser Arbeit vorgestellten Werkzeug, Graphen aus unter-schiedlichsten Bereichen der Softwaretechnik einzulesen, um diese zu visualisieren.

3 Scalable Vector Graphics 8

3 Scalable Vector Graphics

Dieses Kapitel gibt eine Einführung in Scalable Vector Graphics (SVG), eine Sprachezur Beschreibung von zwei-dimensionalen Vektor- und gemischten Vektor- / Raster-grafiken in XML [SVG01]. SVG ist eine W3C Recommendation mit starkem Rückhaltaus der Industrie; es haben u.a. Adobe, SUN Microsystems und IBM an der SVG-Spezifikation mitgearbeitet.

Basierend auf [SVG01] gibt dieses Kapitel in den folgenden Abschnitten genau denÜberblick über SVG, der den für diese Arbeit notwendigen Teil von SVG abdeckt.Diese Einführung bezieht sich außerdem ausschließlich auf die SVG-Beschreibung inder Version 1.1.

Einen “Vorgeschmack” auf die Möglichkeiten zeigt Abbildung 2.

Abbildung 2: “Powered by GXL”

3.1 Grundlagen

Die Sprache SVG ermöglicht es, zwei-dimensionale Grafiken durch die Kompositionvon drei verschiedenen Typen von Grafikobjekten zu erstellen. Die möglichen Grafi-kobjekte sind:

• Vektorgrafiken, beschrieben durch Linien und/oder Kurven• Bilder, ein mögliches Format ist beispielsweise PNG• Text

Grafikobjekte lassen sich desweiteren gruppieren, transformieren, mit Stilen indivi-dualisieren und es ist durch Scripting möglich, interaktive Grafiken zu erzeugen.

Aufbau von SVG-Dokumenten

Der Aufbau eines XML-Dokumentes, das eine SVG-Grafik beschreibt (ein SVG-Do-kument), wird durch folgenden Rumpf definiert:

3.1 Grundlagen 9

<?xml version="1.0" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"

"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">

5 <svg width="300" height="100"version="1.1" xmlns="http://www.w3.org/2000/svg">

<desc>Beschreibung (optional)</desc>

10 <!−− SVG−Grafikobjekte hier −−>

</svg>

Abbildung 3: SVG-Dokumentenstruktur

Wichtig sind die Attribute width und height, sie definieren die Größe der SVG-Grafik.

Koordinatensystem und Ansichten

Das Koordinatensystem von SVG-Grafiken hat eine nach unten zeigende y-Achse. DieZeichenfläche (Canvas) ist in beiden Richtungen unbeschränkt; das durch die Attributewidth und height aufgespannte Rechteck beschreibt die sichtbare Fläche (Viewport)und somit, wie bereits erwähnt, die Größe der SVG-Grafik.

Abbildung 4 verdeutlicht diesen Zusammenhang: auf dem “unendlich” großen Canvaswird durch das svg-Element der Viewport am Ursprung mit gegebener Höhe und Breitegesetzt. Alle Grafikobjekte, die in diesem Viewport liegen, sind Teil der resultierendenSVG-Grafik.Dargestellt ist der Viewport der in Abbildung 3 angeführten SVG-Grafik.

width

height Viewport

y-Axis

x-Axis

Canvas

0 300

0

100

Abbildung 4: Zusammenhang Canvas / Viewport

Ansichten ändern mit viewBox

Das (optionale) viewBox-Attribut des svg-Elements ermöglicht es, den in einem View-port darzustellenden Teil einer SVG-Grafik zu bestimmen. Durch Neu-Definition von

3.2 Einheiten 10

Ursprung und Größe mittels des viewBox-Elements kann im gegebenen Viewport einanderer Ausschnitt einer SVG-Grafik dargestellt werden. Es handelt sich also um ei-ne Transformation des Koordinatensystems: das viewBox-Attribut erlaubt die Trans-lation und Skalierung des Koordinatensystems. Zusätzlich lässt sich das Skalierungs-Verhalten durch das preserveAspectRatio-Attribut weiter einstellen (vgl. [SVG06]).

Viewport

Canvas

width=200

heig

ht=2

00

nicht sichtbar

Canvas

400

viewBox -200 0 400 400

nic

ht s

icht

bar

SkalierungTranslation

altes Koordinatensystem

neues Koordinatensystem

Abbildung 5: Neues Koordinatensystem durch viewBox

Abbildung 5 zeigt wie mittels einer Koordinatentransformation ein anderer Ausschnittder zugrunde liegenden Grafikobjekte auf dem Canvas (hier: ein schwarz gefüllterKreis) im Viewport dargestellt wird.Der SVG-Quelltext dazu:

Unverändertes Koordinatensystem Transformiertes Koordinatensystem<svg version="1.1"

xmlns="http://www.w3.org/2000/svg"width="200" height="200">...

</svg>

<svg version="1.1"xmlns="http://www.w3.org/2000/svg"width="200" height="200"viewBox="-200 0 400 400"preserveAspectRatio="none">...

</svg>

3.2 Einheiten

Alle Koordinaten- und Längenangaben einer SVG-Grafik können mit und ohne Ein-heiten definiert werden. Wird keine Einheit angegeben, so spricht man von User-Einheiten (s.u.); mögliche absolute Einheiten sind u.a.: em, px, pt, cm und in.

3.3 Einfache Formen 11

User-Einheiten

Im initialen Zustand entspricht eine User-Einheit einem Pixel bzw. entspricht genauder Größe, welche das Medium, in dem die SVG-Grafik angezeigt wird, als Pixelgrößedefiniert. Diese Größe kann sich durch die Verwendung des viewBox-Attributs oderanderer Transformationen ändern, so dass eine User-Einheit dann nicht (mehr) derPixelgröße des Ausgabegerätes entspricht.

Absolute Einheiten (px, pt, cm) werden immer abhängig von der durch das Ausga-begerät gegebenen Pixelgröße berechnet. Da sich diese aber ändern kann (nicht alleAusgabegeräte definieren für einen Pixel dieselbe Größe) und da SVG-Grafiken per sefrei skalierbar (Scalable Vector Graphics) sind, wird von der Verwendung von abso-luten Einheiten abgeraten. Im Folgenden werden im Zusammenhang mit SVG immerUser-Einheiten verwendet, um eine einheitliche Darstellung auf allen Ausgabegerätensicherzustellen.

User-Einheiten und das viewBox-Attribut

Das oben eingeführte viewBox-Attribut (Translation und Skalierung des Viewports)bestimmt, wie User-Einheiten auf die Größe der SVG-Grafik abgebildet werden. Die-sen Zusammenhang verdeutlicht noch einmal Abbildung 6.

<svgversion="1.1" xmlns="..."width="400pt" height="300pt"viewBox="0 0 800 600">

5<!−−

SVG−Grafikobjekte hier−−>

10 </svg>

Größe der SVG-Grafik: 400pt x 300pt(definiert im svg-Element)

300pt

400pt

abgebildet auf User-Einheiten (800 x 600)durch das viewBox-Attribut

800

600

Viewport

(200, 200) (600, 200)

(200, 400) (600, 400)

Abbildung 6: Zusammenhang viewBox / User-Einheiten

3.3 Einfache Formen

SVG enthält fünf sogenannte grafische Primitive:

• Rechteck – rect• Kreis – circle


• Ellipse – ellipse• Linie – line, polyline• Polygon – polygon

Für eine detaillierte Beschreibung der einzelnen Primitive siehe [SVG02]; im Folgen-den wird jeweils ein Beispiel mit Quelltext und resultierender SVG-Grafik für die gra-fischen Primitive präsentiert.

Das rect-Element


5<rectx="100" y="100"width="200" height="100" />

10 </svg>Viewbox: 400 x 300

Position (x/y)

width

heig

ht

Über das x- und y-Attribut wird die Position der linken, oberen Ecke des Rechtecksgesetzt; width und height bestimmen die Größe des Rechtecks.

Das circle-Element


5<circlecx="200" cy="150"r="100" />


Position (cx/cy)

Radius (r)

Im Gegensatz zum Rechteck wird die Position eines Kreises über den Mittelpunktgegeben (cx- / cy-Attribut). Das r-Attribut setzt den Radius des Kreis um den Mittel-punkt.


Das ellipse-Element


5<ellipsecx="200" cy="150"rx="100" ry="50" />


Position (cx/cy)

Radien (rx, ry)

Analog zu Kreisen wird auch bei Ellipsen die Position über den Mittelpunkt gesetzt.Die Größe setzt sich bei Ellipsen über zwei Radien zusammen; das rx-Attribut definiertden Radius in x-Richtung und das ry-Attribut in y-Richtung.

Linien mit dem line- und polyline-Element


5<linex1="100" y1="50" x2="300" y2="50" />

<polyline10 points=

"100, 100 300,200 100,200 300,100"style="fill:none; stroke:black;" />

</svg>Viewbox: 400 x 300

1

23

4

Polyline

(x1,y1) (x2,y2)

Line

Das line-Element zieht eine Linie vom gegebenen Startpunkt (x1- / y1-Attribut) zumZielpunkt (x2- / y2-Attribut).

Das polyline-Element stellt Linienzüge dar. Die einzelnen Punkte des Linienzugeswerden im points-Attribut als Koordinatenpaare (x,y) angegeben.Das Beispiel zeigt, wie mittels des style-Attributs die Darstellung weiter beeinflusstwerden kann. In Kapitel 3.7 wird darauf detailliert eingegangen. Außerdem sind in derAbbildung die Punkte des Linienzuges zum besseren Verständnis hervorgehoben unddurchnummeriert.

3.4 Pfade 14

Das polygon-Element


5<polygon

points="150, 50 250, 50 300,150250,250 150,250 100,150" />

10</svg> Viewbox: 400 x 300

Mit dem polygon-Element werden geschlossene Polygone gezeichnet. Ähnlich dempolyline-Element werden dazu die Punkte der Reihe nach im points-Attribut angege-ben In der resultierenden SVG-Grafik wird beim polygon-Element immer eine Liniezwischen dem ersten und letzten Punkt gezogen, um die Figur zu schließen.

3.4 Pfade

Pfade sind das Allround-Werkzeug von SVG: alle oben vorgestellten grafische Primi-tive lassen sich durch einen Pfad darstellen. Dazu ermöglichen Pfade das Zeichnen vonKurven.

Das Konzept eines Pfades lässt sich gut mit dem Zeichnen mit einem Stift auf einemBlatt Papier beschreiben: Man setzt den Stift an und bewegt ihn dann auf eine bestimm-te Art und Weise an eine andere Stelle. Die Bewegung des Stiftes wird mit einem soge-nannten Pfadausdruck beschrieben; der Pfadausdruck enthält sequentiell angeordnete“Befehle”, welche die Stiftbewegung des Pfades definieren. Zusätzlich kann innerhalbeines Pfadausdrucks der Stift jederzeit an eine neue Stelle gesetzt werden; man sprichtdann von einem Teilpfad.

Definiert wird ein Pfad durch ein path-Element, der Pfadausdruck wird im d-Attributangegeben.

Abbildung 7 veranschaulicht in vier Schritten den sukzessiven Aufbau eines einfachenPfadausdrucks2.

2 mit genau einem Teilpfad

3.4 Pfade 15

Stift ansetzen Linie zeichnen

Kurve zeichnen Pfad schliessen

21

3 4

M 50 50 L 100 100

C 125 100 150 75 150 50 Z

Abbildung 7: Aufbau eines Pfadausdrucks (konzeptionell)

Das resultierende path-Element lautet:

<path d="M 50 50 L 100 100 C 125 100 150 75 150 50 Z"style="stroke:black; fill:none;" />

Auch bei diesem Beispiel werden über ein style-Attribut (vgl. Kap. 3.7) Darstellungs-eigenschaften verändert3, da der Darstellungsstandard von Pfaden diese "unsichtbar”macht.

Der Pfadausdruck: Mögliche Befehle

Der Pfadausdruck, angegeben im d-Attribut eines gegebenen path-Elements, bestehtaus einer Reihe von Befehlen. Zu allen Befehlen gibt es immer zwei Möglichkeiten,die Bewegung des Stifts zu definieren: absolut und relativ. Bei absoluten Angabenwird die gewünschte Position mit Koordinaten im aktuellen Viewport definiert; relativeKoordinaten bestimmen die Position relativ zur vorherigen Position und werden miteinem vorangestellten + bzw. - angegeben. Abbildung 8 zeigt beispielhaft eine Kurve,definiert mit relativen Koordinaten im Pfadausdruck.

Eine vollständige Übersicht zu SVG-Pfaden und Pfadausdrücken liefert die Spezifi-kation ([SVG03]), Tabelle 2 gibt eine tabellarische Übersicht der in der Arbeit an-gewendeten Befehle. Dabei werden alle Koordinatenangaben eines Pfadausdrucks inUser-Koordinaten angegeben.

Hinweis: In der Parameter-Spalte werden Gruppen von Parametern in Klammern an-

3 hier: keine Füllfarbe, Linienzug schwarz

3.5 Text 16


5<pathd="m 100 150

c 0 -50 100 -50 100 00 50 100 50 100 0"

10 style="fill:none;" />

</svg> Viewbox: 400 x 300

Abbildung 8: Kurve mit relativen Koordinaten-Angaben

gegeben. Ein “+” bedeutet, dass mehrere Gruppen von Parametern möglich sind.

Name Befehl Parameter(s.u.)

Beschreibung

moveto M (absolut)m (relativ)

(x y)+ Startet einen (Teil-) Pfad an gegebener Position (xy); eine anschliessende Folge von Koordinatenpaa-ren wird als (implizite) Folge von lineto-Befehleninterpretiert. Ein relativ angegebener Startpunktwird als absolut definierter Startpunkt interpretiert.

lineto L (absolut)l (relativ)

(x y)+ Zeichnet eine Linie von der aktuellen Position nach(x y). Eine Folge von Koordinatenpaare wird als Po-lyline3.3 interpretiert.

closepath Z bzw. z Beendet den aktuellen (Teil-) Pfad und zeichnet eineLinie zurück zum Start des (Teil-) Pfades.

curveto C (absolut)c (relativ)

(x1 y1 x2 y2x y)+

Zeichnet eine Bézierkurve von der aktuellen Positi-on nach (x y) unter Berücksichtigung der Kontroll-punkte (x1 y1) und (x2 y2). Durch eine Folge vonKoordinatenpaaren kann eine Folge von Bézierkur-ven gezeichnet werden; dabei definiert das letzte (xy)-Paar den Endpunkt der Kurvenfolge.

Tabelle 2: Möglichkeiten des Pfadausdrucks

3.5 Text

Text wird innerhalb einer SVG-Grafik durch das text-Element (vgl. Abb. 10) beschrie-ben. Es verhält sich wie ein normales Grafikobjekt und nimmt gegenüber den grafi-schen Primitiven keine Sonderrolle ein. Daraus folgt, dass weitere Darstellungsattri-bute über das style-Attribut angegeben werden können. Kapitel 3.7 stellt vor, welcheAttribute, auch für text-Elemente, möglich sind.

Definiert wird die Position von text-Elementen über das x- und y-Attribut. Dabei istzu beachten, dass die Position eines Textelements links auf der sogenannten Basisli-

3.5 Text 17

nie des Textes (vgl. Abb. 9) beginnt. Dieser Punkt auf der Basislinie wird Text-Ankerbezeichnet. Über das text-anchor-Attribut kann dieser versetzt werden, Abbildung 9veranschaulicht an einem Beispiel die drei Möglichkeiten “left”, “middle” und “right”.

The quick brown fox

Basislinie

Text-Anker

"left" "middle" "right"

Abbildung 9: Basisline und Text-Anker

Beispiel

Abbildung 10 zeigt einen Text in einer SVG-Grafik. Über das text-anchor-Attribut istdieser genau in der Mitte des Viewports ausgerichtet.

<svgversion="1.1"xmlns="http://www.w3.org/2000/svg"width="400pt" height="300pt"

5 viewBox="0 0 400 300">

<textx="200" y="150" text−anchor="middle"style="font-size:20;">

10The quick brown fox

</text>

15 </svg>

The quick brown fox

Viewbox: 400 x 300

Position (x="200", y="150")

Abbildung 10: text-Element; SVG und resultierende Grafik

Whitespace

SVG behandelt bei text-Elementen Zeilenumbrüche und alle Leerzeichen vor und hin-ter dem Text als Whitespace (zu ignorierender Text).

Zusätzlich werden alle Tabulator-Zeichen in Leerzeichen umgewandelt und anschlie-ßend alle zusammenhängenden Leerzeichen zu einem “verschmolzen”. Daraus folgt,dass text-Elemente immer nur einzeilige Textabschnitte beschreiben; mehrzeiliger Textmuss aus einzelnen text-Elementen zusammengesetzt werden.

3.6 Gruppen von Grafikobjekten 18

Beispiel

Das text-Element:

<text>wenig Text, aber

sehr viel

Whitespace</text>

wird nach der Entfernung von Whitespace zu einem “Einzeiler”:

<text>wenig Text, aber sehr viel Whitespace</text>

3.6 Gruppen von Grafikobjekten

Grafikobjekte, einfache Formen sowie Pfadobjekte, lassen sich durch das g-Elementzu einem Objekt gruppieren. Durch eine solche Gruppe können beliebig komplexeGrafiken zusammengesetzt werden. Zusätzlich können Gruppen selbst Teil andererGruppen sein.

Beispiel

<g><rect x="100" y="100" width="100" height="100" /><line x1="100" y1="100" x2="150" y2="50" /><line x1="150" y1="50" x2="200" y2="100" />

5 <g><rect x="155" y="130" width="30" height="30" /><rect x="115" y="130" width="30" height="60" />

</g></g>

Gruppen transformieren

Gruppen lassen sich durch Angabe des transform-Attributs beliebig im Koordinaten-system transformieren.

Möglich sind:

• Translation,• Skalierung und• Rotation.

Durch Schachtelung von Gruppen können beliebig viele Transformationen auf unter-schiedlichste Weise auf derart gruppierte Grafikobjekte angewendet werden. Außer-dem können oben angeführte Transformationen in einem transform-Attribut auch di-rekt hintereinander definiert werden.

3.7 Cascading Style Sheets 19

Beispiel

Die Abbildungen 11, 12 und 13 zeigen, jeweils mit SVG-Quelltext und -Grafik, diesequentielle Transformation einer Gruppe von grafischen Primitiven. Deutlich wirddabei, wie die Anwendungsreihenfolge die Gruppe im Viewport transformiert.

<svg version="1.1"xmlns="http://www.w3.org/2000/svg"width="400" height="300">

5 <g id="g1"><rect x="25" y="25" width="25" height="25"/><rect x="50" y="50" width="25" height="25"/>

</g>


untransformierte Gruppe

Abbildung 11: Gruppe im “Originalzustand”


5 <g id="g1" transform="translate(150,0)"><rect x="25" y="25" width="25" height="25"/><rect x="50" y="50" width="25" height="25"/>

</g>


Translation um (150,0)

Abbildung 12: Translation


5 <g id="g1"transform="rotate(45) translate(150,0)"><rect x="25" y="25" width="25" height="25"/><rect x="50" y="50" width="25" height="25"/>

</g>10

</svg>Viewbox: 400 x 300

Rotation um 45°

Abbildung 13: Rotation

3.7 Cascading Style Sheets

SVG unterstützt das Setzen von Darstellungseigenschaften mittels Cascading StyleSheets (CSS) [CSS2-01] – das sog. Styling. CSS erlaubt es Autoren, Darstellungsvor-gaben, z.B. Schriftarten oder Abstände, an strukturierte Dokumente4 zu binden. Eine

4 HTML- oder XML-Dokumente wie SVG-Grafiken


derartige Trennung von Darstellungsvorgaben vom Inhalt vereinfacht die Pflege sol-cher Dokumente und vermeidet Redundanzen.

Das in dieser Arbeit vorgestellte Werkzeug verwendet grundsätzlich CSS zur Gestal-tung von SVG-Grafiken. Eine vollständige Beschreibung aller Möglichkeiten bietet dieSVG-Spezifikation unter [SVG04]; im Folgenden werden nur die benötigten Styling-Möglichkeiten und -Mechanismen vorgestellt.

3.7.1 Einführung

Durch CSS-Styling-Attribute können alle möglichen Darstellungseigenschaften einesGrafikobjekts beeinflusst werden. Grundsätzlich sind Styling-Attribute Name-Wert-Paare; einer Eigenschaft x wird ein (neuer) Wert y zugewiesen, z.B. bei der Angabe"fill:#ff0000" wird der Eigenschaft “fill” (Füllfarbe) der Wert “#ff0000” (FarbeRot) zugewiesen.

Bei der Verwendung von CSS kann das Aussehen der Objekte einer SVG-Grafik aufdrei Arten definiert werden:

1. externe CSS-Datei

2. globale CSS-Definition in einem style-Element innerhalb der SVG-Grafik

3. per Grafikobjekt durch Angabe eines style-Attributs

In externen CSS-Dateien und in globalen CSS-Definition innerhalb einer SVG-Grafikwerden Stil-Angaben, durch Gruppierungen, entweder

• für alle Elemente eines bestimmten Typs (z.B. alle line-Elemente)• für Elemente einer bestimmten Klasse (definiert durch das class-Attribut)• für Elemente mit einem bestimmten Bezeichner; Instanz (definiert durch das id-

Attribut)

definiert.

Eine Gruppe von Styling-Attributen wird wie folgt definiert:

Bezeichner {}

Alle innerhalb der geschweiften Klammern angegeben Styling-Attribute sind Teil derGruppe. Tabelle 3 enthält dazu die Styling-Attribute, die in dieser Arbeit angewendetwerden. Eine komplette Übersicht bietet [SVG05].


Name Beschreibung

font-family Zu verwendende Schriftart

font-size Größe der Schrift

fill Füllfarbe des Grafikobjekts

stroke Farbe des Linienzuges / des Rahmens eines Grafikobjekts

stroke-width Breite des Linienzuges / des Rahmens

stroke-dasharray Ermöglicht unterschiedlichste Linienzüge

Tabelle 3: Styling-Attribute

Durch diese Techniken, indem also globale, klassenbezogene und instanzbezogeneStyling-Attribute in Gruppen organisiert werden können, werden Redundanzen ver-mieden und die Flexibilität erhöht; auch ein Neu-Gestalten wird vereinfacht.

3.7.2 Verwendung eines externen Stylesheets

Ein externes Stylesheet wird noch vor der eigentlichen SVG-Grafik eingebunden (vgl.Abb. 14). Dabei sind nicht nur lokale Dateien möglich, mit dem href -Attribut könnenalle, durch eine URL5 auffindbare, Stylesheets eingesetzt werden.

<?xml version="1.0" standalone="no"?>

<?xml−stylesheet href="styledefs.css" type="text/css"?>

5 <svg width="300" height="100"version="1.1" xmlns="http://www.w3.org/2000/svg">

</svg>

Abbildung 14: Stylesheets

Bei der in Abbildung 14 gezeigten Referenz auf das externe Stylesheet “styledefs.css”handelt es sich um einen Verweis auf eine lokale Datei, die sich im selben Verzeichniswie die SVG-Grafik befinden muss.

3.7.3 Globale CSS-Definition innerhalb der SVG-Grafik

Ein globales style-Element wird in einem zentralen defs-Element innerhalb der SVG-Grafik eingebunden:

<?xml version="1.0" standalone="no"?>

<svg [...]>

5 <defs>

5 Unified Resource Locator


<style type="text/css"><![CDATA[[...]

]]></style></defs>

10</svg>

3.7.4 style-Attribut am Grafikobjekt

Neben externen Stylesheets und globalen CSS-Definition kann zusätzlich jedes SVG-Element individuell durch das style-Attribut gestylt werden. Dort definierte Styling-Attribute überschreiben dabei alle bereits für das Element definierten Attribute (vgl.Kap. 3.7.5).

Beispiel

Das Beispiel veranschaulicht, wie eine Darstellungseigenschaft (hier: Farbe) einesGrafikobjekt der Klasse “smallGreenText” (s. Kap. 3.7.8) direkt durch ein entspre-chendes style-Attribut überschrieben wird.

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="400" height="300">

<defs><style type="text/css"><![CDATA[

5 .smallGreenText {font-size: 8pt;color: green;

}]]></style>

10 </defs>

<text class="smallGreenText" style="color: red;"x="10" y="10">

Dies ist die erste Zeile des Klassikers "Der Name des Buches".15 </text>

</svg>

3.7.5 Anwendungsreihenfolge

Die Anwendungsreihenfolge von Style-Informationen ist wie folgt:

Standardwert6←−ueberschreibt globales style-Element

globales style-Element←−ueberschreibt externes Stylesheet

externes Stylesheet←−ueberschreibt lokales style-Attribut

6 aus der SVG-Spezifikation


Alle Darstellungsattribute einer SVG-Grafik können also, unabhängig von innerhalbder Grafik definierten CSS-Angaben, durch Einbinden eines externen Stylesheets voll-ständig neu definiert werden.

3.7.6 Gruppen und CSS

Die in Kapitel 3.6 eingeführten Gruppen können, wie andere SVG-Grafikobjete, eben-falls mittels CSS gestylt werden. In einer Gruppe zusammengefasste Grafikobjekte“erben” dabei die Style-Angaben der Gruppe. Dabei gilt, dass explizite Style-Angabenvon Elementen innerhalb einer Gruppe die Angaben der Gruppe überschreiben. Auchunterstützen Gruppen das Stylen mittels Klassen (class-Attribut), Instanzen (id-Attribut)und direktes Anführen von Style-Angaben durch ein style-Attribut.

Beispiel

Das Beispiel in Abbildung 15 zeigt die Anwendung einiger Styling-Möglichkeiten aufgrafische Primitive. Die in der Gruppe gesetzen Style-Angaben werden an die in derGruppe zusammengefassten Rechtecke “vererbt”; durch direkte Angabe eines style-Attribut können solche geerbten Angaben individuell überschrieben werden.


5 <gstyle="fill:none;stroke:black;stroke-width:2">

<rect x="50" y="150" width="50" height="50"/><rect x="100" y="100" width="50" height="50"

10 style="stroke-dasharray:2,2;"/><rect x="150" y="150" width="50" height="50"/><rect x="200" y="100" width="50" height="50"/><rect x="250" y="150" width="50" height="50"

style="fill:black;"/>15 <rect x="300" y="100" width="50" height="50"/>

</g>

</svg>

Viewbox: 400 x 300

Abbildung 15: CSS, angewendet auf grafische Primitive

3.7.7 Elementtyp-bezogene Styling-Attribute

Entsprechend Kap. 3.7.1 können die Darstellungseigenschaften aller SVG-Grafikob-jekte eines bestimmten Typs, z.B. alle Pfade (path-Element), durch die Angabe einerCSS-Gruppe für den Elementtyp definiert werden, welche die gewünschten Styling-Attribute enthält.


Beispiel

Alle path-Elemente sollen folgende Darstellungseigenschaften aufweisen:

• Füllfarbe Orange• Farbe des Linienzuges: Grün

Daraus ergibt sich folgende Style-Umgebung für path-Elemente:

path {fill: orange;stroke: green;

}

3.7.8 Klassenbezogene Styling-Attribute

Eine Klasse wird einem SVG-Grafikobjekten durch das class-Attribut zugewiesen. Umeiner Klasse Styling-Attribute zuzufügen, wird eine Style-Umgebung mit dem Klas-sennamen definiert, angeführt durch einen Punkt:

.NameOfClass {attr: value;

}

Beispiel

Folgendes Beispiel zeigt eine SVG-Grafik, die global eine Klasse “thickGreenLine”definiert und diese über das class-Attribut zwei grafischen Primitiven zuweist.


5 <defs><style type="text/css"><![CDATA[

.thickGreenLine {stroke: green;stroke-width: 6;

10 }]]></style>

</defs>

<path class="thickGreenLine"15 d="m 75 75 l 50 -50 l 50 50 z" />

<line class="thickGreenLine"x1="5" y1="5" x2="90" y2="5" />

</svg>

3.8 Fazit 25

3.7.9 Instanzbezogene Styling-Attribute

Das id-Attribut benennt die Instanz eines gegebenen Grafikobjekts. Der Instanz kön-nen in einer Style-Umgebung, bezeichnet mit dem Instanznamen und dem Präfix “#”,Darstellungsattribute zugewiesen werden.

Beispiel

Einem text-Element wird über ein id-Attribut die Instanz “Buchtitel” zugewiesen; imAnschluss folgt die Style-Umgebung.

<svg [...]><text id="Buchtitel" x="50" y="150">Der Name des Buches

</text>5 </svg>

Style-Umgebung:

#Buchtitel {font-family: serif;font-size: 28pt;font-weight: bold;color: blue;

}

3.8 Fazit

SVG ist ein offener Standard der bereits von unterschiedlichen, grafischen Werkzeu-gen (Editoren sowie Anzeigeprogrammen) unterstützt wird. Die Möglichkeit, Grafikeneinfach durch eine Textausgabe zu erzeugen ist besonders von Vorteil, da somit keine,oft sehr aufwendige, Grafik-Bibliothek gebraucht wird.

Da SVG-Grafiken als XML-Dokument vorliegen, sind sie durch das DOM (DocumentObject Model) zugreifbar. Dies ermöglich Scripting und das dynamische Verändernvon SVG-Grafiken. Mit dem Einsatz von CSS und Scripting stellt SVG eines der fle-xibelsten Grafikformate dar und kommt aus diesen Gründen als Ausgabeformat zumEinsatz.

4 Layoutverfahren 26

4 Layoutverfahren

Die dritte, wichtige Komponente bei der Graphvisualisierung ist, neben dem Einga-beformat GXL und der Ausgabesprache SVG, ein Werkzeug, das Layoutverfahren fürGraphen bereitstellt. Layoutverfahren bestimmen algorithmisch die Position der Gra-phelemente (Knoten und Kanten) in der visuellen Repräsentation.

Das in dieser Arbeit vorgestellte Werkzeug nutzt die GraphViz-Bibliothek für dieseAufgabe.

4.1 Grundlagen

Grundsätzlich werden bei Layoutverfahren Knoten als geometrische Form, sogenann-te Shapes, einer bestimmten Größe aufgefasst, Kanten hingegen als ein Linienzug.Die GraphViz-Bibliothek stellt für Knoten eine Reihe von Shapes zur Verfügung, derLinienzug einer Kante wird durch eine Bézier-Kurve repräsentiert.

Für eine gegebene Menge von Knoten und Kanten, nachdem für Knoten eine Shapegewählt wurde, versucht ein Layoutverfahren diese durch einen Algorithmus anzuord-nen. Die Knoten, bzw. die für ihre Darstellung gewählte Shape, werden dem Algorith-mus entsprechend angeordnet und die Kanten dazwischen gezogen.

4.2 Layoutverfahren der GraphViz-Bibliothek

GraphViz stellt drei Layoutverfahren zur Verfügung:

• ein Layoutverfahren nach Sugiyama [dot01], bei dem ein hierarchisches Layoutdes Graphen angestrebt wird.• ein Verfahren nach Kamada-Kawai [neato01], das möglichst symmetrische Dar-

stellungen erzeugt.• ein Verfahren nach Wills [twopi01], das den Graph radial anordnet.

4.2 Layoutverfahren der GraphViz-Bibliothek 27

Abbildung 16: hierarchisch angeordneter Graph, nach Sugiyama

Abbildung 17: symmetrisch angeordneter Graph, nach Kamada-Kawai

4.3 Fazit 28

Abbildung 18: radial angeordneter Graph, nach Wills

Die Abbildungen 16, 17 und 18 geben jeweils ein Beispiel für die zur Verfügung ste-henden Verfahren.

4.3 Fazit

Layoutverfahren liefern für Graphen die Positionen der Knoten und für Kanten denVerlauf des Linienzuges.

“Layoutalg. Wissenschaft für sich”; deswegen GraphViz verwendet, das drei Verfahrenzur Verfügung stellt, freigegeben unter Lizenz X; aber: Layoutverfahren als separaterBaustein, Aussehen des Graphens und damit auch Eigenschaften des Layouts aus-schließlich über Layoutspezifikation gesteuert - wird im nächsten Kapitel vorgestellt.

5 Die Layoutspezifikation 29

5 Die Layoutspezifikation

Die Layoutspezifikation beschreibt das Aussehen des gesamten Graphen und die Dar-stellung der Graphelemente in der visuellen Repräsentation. Dazu definiert die Spezi-fikation eine Reihe von Layoutangaben (5.2).

Obwohl GraphViz als Bibliothek für Layoutverfahren und SVG als primäres Ausga-beformat von diesem Werkzeug verwendet bzw. unterstützt werden, ist die Layoutspe-zifiaktion per se unabhängig von diesen Komponenten aufgebaut. Dadurch wird eineeventuelle Erweiterung des Werkzeugs um weitere Verfahren oder Ausgabeformat ef-fektiv unterstützt.

Im Folgenden wird zuerst auf wichtige Grundvoraussetzungen für die Spezifikationeingegangen. Anschließend wird die Realisierung der Layoutspezifikation und dabeidie möglichen Layoutangaben im Detail beschrieben.

5.1 Rahmenbedingungen

Grundvoraussetzung für eine von Graph-Layoutalgorithmen und Ausgabeformaten un-abhängige Layoutspezifikation ist ein Satz von fest definierten Rahmenbedingungen.Zu diesen Rahmenbedingungen zählen:

• das Einheitensystem,• das Koordinatensystem und• die Darstellungsgrundlagen für Knoten und Kanten.

Diese Rahmenbedingungen gelten für alle Layoutverfahren bzw. deren Implementati-on gleichermaßen. Basierend auf diesen Eingaben und den Layoutangaben der Spe-zifikation ermitteln Layoutverfahren die Positionen der Knoten und den Verlauf derKantenzüge.

5.1.1 Einheitensystem

Um eine möglichst große Unabhängigkeit vom Ausgabemedium zu erreichen, werdenalle Angaben der Layoutspezifikation ohne Einheiten definiert (vgl. Kap.3.2). Die In-terpretation der Längenangaben wird somit immer dem Ausgabemedium überlassen.

Ist beispielsweise in der Spezifikation definiert, ein Knoten sei 100 Einheiten (sog.User-Einheiten) breit, so kann dieser bei der Darstellung am Monitor 100 Pixel breitsein, beim Druck auf Papier jedoch 100 Point7.

5.1.2 Koordinatensystem

Das verwendete Koordinatensystem entspricht dem SVG-Koordinatensystem. Es hatseinen Ursprung in der linken, oberen Ecke; die positive x-Achse verläuft nach rechts

7 1 Point = 1/72 Zoll

5.1 Rahmenbedingungen 30

und die positive y-Achse nach unten (vergl. Abb. 19). Das Koordinatensystem ist nichtauf den positiven Bereich beschränkt.

5.1.3 Grundlagen der Knotendarstellung

positive x-axis

positive y-axis

width

height

global origin

node position

shape: rectangle

shape: ellipse

edge control-points

edge

Abbildung 19: Darstellung wichtiger Eigenschaften für Layout-Implementationen

Unabhängig von der konkreten Darstellung eines Knotens – spezifiziert in der Lay-outspezifikation – ist es notwendig, dessen Shape festzulegen. Diese ist eine einfache,geometrische Form und sie beschreibt nur den Umriss des Knoten.

Auf die festgelegte Shape eines Knoten kann bei der Ermittlung der Kantenverläufedurch ein Layoutverfahren zurückgegriffen werden, um Start- und Endpunkt genau andie Knoten setzen zu können. Die konkrete Darstellung des Knotens sollte die gewählteShape deshalb nach Möglichkeit immer genau ausfüllen, um fehlerhafte Kantenzügezu vermeiden. Die Verwendung von Shapes für Layoutverfahren ermöglicht somit,ausgefallene Knotenformen zu zeichnen, ohne dass ein gegebenes Layoutverfahrendie Knotenform im Detail kennen muss. Durch eine passende Shape ist sichergestellt,dass Kantenzüge vom Layoutverfahren dennoch korrekt gezogen werden können.

Zwei mögliche Shapes zeigt exemplarisch Abbildung 19: ellipse und rectangle.

Bei der Positionsbestimmung eines Knotens durch ein Layoutverfahren wird der Mit-telpunkt der Bounding-Box der Shape des Knotens geliefert (Abb. 20).

5.1 Rahmenbedingungen 31

shape: ellipse shape: diamond

Bounding-Box

Mittelpunkt der Shape

Abbildung 20: Mittelpunkte

5.1.4 Grundlagen der Kantendarstellung

Kanten werden durch Bézier-Kurven dargestellt.Eine Bézier-Kurve wird durch 3n + 1 Punkte beschrieben (n ∈ N0). Abbildung 21zeigt exemplarisch eine Bézier-Kurve für n = 2; der Startpunkt sei in diesem Beispielp1. Zusätzlich sind zur Veranschaulichung die Tangenten eingezeichnet.

p

pp

p

p

1

2

3

4 5

pp

Kantensymbol

7 6

Abbildung 21: Bézier-Kurve (n = 2)

Die Darstellung der Pfeilspitze (Kantensymbol) kann am Start- und / oder am End-punkt der Bézier-Kurve erfolgen. Abbildung 21 zeigt exemplarisch das Kantensymbolam Ende der Kurve (hier: p7).Unabhängig davon wird das Kantensymbol immer mit Hilfe des vorherigen oder nächs-ten Bézier-Kontrollpunktes gesetzt. Dies ermöglicht es, das Kantensymbol tangentialan die Kurve zu setzen (in Abb. 21 zw. p7 und p6).

Form und Größe des Kantensymbols sowie die Gestaltung der Kante selbst sind alsLayoutangaben Teil der Layoutspezifikation.

5.2 Layoutangaben 32

5.2 Layoutangaben

Die Layoutspezifikation steuert Eigenschaften der visuellen Repräsentation über Lay-outangaben. Dazu legt eine Layoutangabe jeweils eine Eigenschaft, zum Beispiel dieStrichstärke der Kantenzüge oder die Schriftfarbe eines Knoten-Labels, fest.

Eigenschaften

Die durch Layoutangaben definierbaren Eigenschaften der SVG-Repräsentation desGraphen sind generell Name-Wert-Paare; einer Eigenschaft x wird der (feste) Werty zugewiesen. Unterschieden wird dabei zwischen Layoutangaben, die den Graphenim Ganzen manipulieren (Kap. 7.4), und Angaben, die auf Graphelemente (Kap. 7.5)einwirken. Allen Layoutangaben ist desweiteren ein Standardwert zugewiesen. Dasheisst, dass in einer konkreten Layoutspezifikation nur die Layoutangaben enthaltensein müssen, welche Werte neu definieren.

Anfragengestützte Layoutangaben

Im Allgemeinen weist eine Layoutangabe einer Eigenschaft einen festen Wert zu. An-fragengestützte Layoutangaben erweitern die Layoutspezifikation um die Möglichkeit,Eigenschaften abhängig vom Eingabegraphen, bzw. dessen Elementen, zu definieren(vgl. Kap. 7.3). Somit kann zum Beispiel die Anzahl der Kanten an einem Knoten x dieVisualisierung von x beeinflussen. In einem solchen Fall wird eine Eigenschaft durchein Name-Ausdruck8-Paar repräsentiert: Der Wert, welcher einer Eigenschaft x zuge-wiesen wird, ist das Ergebnis y der (Anfrage-) Auswertung des gegebenen Ausdrucks.

Übersicht

Realisiert sind eine Reihe von Layoutangaben, welche die Darstellung der Graphele-mente bzw. die Darstellung des ganzen Graphen steuern. Die folgende Tabelle gibteine Übersicht vorab, die Kapitel 7.4, 7.6 und 7.7 geben detailliert Auskunft über diehier zusammengefassten Möglichkeiten.

Layoutangabe Beschreibung

GraphdarstellungLayoutalgorithmus Möglich sind die drei Verfahren der GraphViz-Bibliothek (s.

Kap. 4.2)Größe der Gesamtgrafik Die Größe der Visualisierung, welche den Graphen komplett

darstellt, ist als Layoutangabe definierbarHintergrundfarbe Für die Gesamtgrafik kann die Hintergrundfarbe definiert wer-

den (“Papierfarbe”).

8 Ausdruck synonym zu GReQL-Anfrage

5.2 Layoutangaben 33

KnotendarstellungDarstellungsstil Für Knoten sind eine Reihe von geometrischen Formen als

Darstellungsstil möglich.Beschriftung Die Knotenbeschriftung ist frei als Layoutangabe definierbar.Schrift Die Schriftart und -größe der Knotenbeschriftung kann ange-

passt werdenUmrandungslinie Der Rahmen des gewählten Darstellungsstil kann angepasst

werden; möglich ist eine Veränderng der Farbe, der Strichstär-ke und -form (Strichelung o.ä.) des Rahmens

Größe Die Größe der Knotendarstellungen kann über Layoutanga-ben definiert werden; unterschieden wird zwischen Höhe undBreite.

Hintergrundfarbe Diese Layoutangabe setzt die Hintergrundfarbe der geometri-schen Form der Knotendarstellung.

Kantendarstellung

Darstellung des Kanten-zugs

Wie bei der Umrandungslinie der Knotendarstellungen kön-nen die Kantenzüge eingefärbt werden und die Strichstärkesowie die Strichform angegeben werden.

Beschriftung Bei Kanten kann die Beschriftung der Kante und eine Be-schriftung für die Kantenendpunkte frei angegeben werden.

Kantenendsymbole Layoutangaben steuern, ob und welche Symbole gegebenen-falls dargestellt werden.

Schrift Die Schriftart und Größe der Kantenbeschriftungen sind wiefür Knoten über Layoutangaben einstellbar.

Hintergrundfarbe Die Hintergrundfarben der Kantenbeschriftungen sind eben-falls steuerbar.

6 Architektur 34

6 Architektur

Das in dieser Arbeit vorgestellte Werkzeug basiert auf einer Reihe von Bausteinen; dieGraphViz-Bibliothek übernimmt das Layouten von Graphen, die Layoutspezifikationist als GSI-Applikation (s. Kap. 7) implementiert und diese wiederum benutzt inten-siv die GReQL-Bibliothek. “Auf den Schultern von Riesen stehend” vereint diesesWerkzeug offene Standards in der Ein- und Ausgabe und flexible sowie performanteGraphtechniken zu einem neuen Tool der Graphvisualisierung.

Das Datenflussdiagramm in Abbildung 22 zeigt dazu die Umgebung des Werkzeugs.

Visualisierer

Layouter

Layoutspez.(XML-Dok.)

GSI

GraphViz

GXL-GraphLayout-

Spezifikation SVG

Layoutgraph

Abbildung 22: Datenflussdiagramm des Werkzeugs

6.1 Designziele

Der Layouter nutzt die Layoutspezifikation, um einen gegebenen Graphen zu layou-ten; die Ergebnisse (Knotenpositionen u.ä.) werden im Dokument Layoutgraph fest-gehalten. Der Layoutgraph ist nur ein Interface, um eine nahe an den verwendetenLayoutern stehende Implementation zu ermöglichen; für die GraphViz-Bibliothek isteine Instanz des Layoutgraph-Interfaces implementiert. Außerdem kann das Werkzeugdurch weitere Implementationen des Interfaces um andere Layoutverfahren erweitertwerden.

Ähnlich verhält es sich bei dem Visualisierer, der die Darstellung des Graphen mit denInformationen aus der Layoutspezifikation und dem Layoutgraph-Interface erzeugt.Auch der Visualisierer ist ein Interface, das für SVG als Ausgabe implementiert wurde.

Beim Entwerfen und Realisieren der Werkzeugarchitektur wurden insgesamt folgendeDesignziele verfolgt:

• Das Tool sollte erweiterbar sein

– um neue Layoutverfahren– um neue Visualisierer

und zusätzlich

6.2 UML-Klassendiagramm 35

• eine Bibliothek zur SVG-Graph-Visualisierung bereitstellen, sowie• eine darauf aufbauende CLI9-Applikation bereitstellten.

6.2 UML-Klassendiagramm

Das folgende Klassendiagramm in Abbildung 23 zeigt den Aufbau des Werkzeugs imDetail. Hervorzuheben sind dabei die beiden Interface-Klassen LayoutGraph und Wri-ter; über diese Klassen werden zum einen Layoutverfahren und zum anderen weitereVisualisierer ermöglicht. Die GraphViz-Bibliothek ist über die von LayoutGraph abge-leitete Klasse GV_LayoutGraph eingebunden und die SVG-Visualisierung übernimmtSVGWriter, eine Implementation des Visualisierer-Interfaces Writer.

LayoutSpec

GSIApplication

LayoutGraph Writer

Interface fürLayoutverfahren

Interface fürVisualisierer

g2svg-Bibliothek G2SVG

GV_LayoutGraph SVGWriterInterface zur SVG-Graph-Visualisierung mitGraphViz

Abbildung 23: UML-Klassendiagramm

Die Layoutspezifikation (LayoutSpec) als GSI-Applikation, die Interfaces LayoutGraphund Writer sowie deren Implementationen für GraphViz und SVG bilden zusammendie Bibliothek “g2svg”, die über die Klasse G2SVG ein Interface zur Graphvisualisie-rung bereitstellt.Die g2svg-Bibliothek wird von der in Kapitel 6.1 geforderten CLI-Applikation “g2svg”verwendet.

Insbesondere die Bibliothek ist im Quelltext ausführlich dokumentiert und gibt dortweiterführende Hinweise zur Verwendung und Erweiterung um neue Layoutverfahrenoder Visualisierer.

9 Command Line Interface

7 Layoutspezifikation als GSI-Repository 36

7 Layoutspezifikation als GSI-Repository

Die Layoutspezifikation wird als GSI-Repository bereitgestellt (vergl. Abb. ??).

Die Wahl fiel auf GSI aus mehreren Gründen: GSI bietet ein XML-basiertes Datenre-pository mit umfangreichen Datentypen. Außerdem kann, aufbauend auf der gegebe-nen GSI-API, leicht ein Interface für den Zugriff auf das eigene Repository (hier: dieLayoutspezifikation) erstellt werden.

7.1 Überblick über GSI

Mit GSI bzw. mit der GSI-API können Graph-basierte Repositories inklusive Zugriffs-interface realisiert werden. Der Datengraph des Repositories entspricht einer XML-Datei, das den Umfang des Repositories bestimmt. Der Zugriff basiert auf GReQL-Anfragen [GREQL01], die immer selbst Teil des Repositories sind (sog. Zugriffsseg-mente). Dies ermöglicht unterschiedlichste Möglichkeiten beim Zugriff auf die Infor-mationen des Repositories, die in Informationssegmenten zusammengefasst sind.

Über eine entsprechende Identifikation und anschließender Parametrisierung der Zu-griffssegmente werden Daten aus Informationssegmenten im Repository angewähltund an den Anwender weitergegeben.Dazu ermöglicht es GSI, durch einen großen Vorrat an Datentypen, beliebig struktu-rierte Daten in Informationssegmenten abzubilden.

Eine detaillierte Beschreibung der GSI-API enthält [GSI01].

7.2 Realisierung der Layoutspezifikation als GSI-Repository

Die Realisierung der Layoutspezifikation als GSI-Repository hat folgende Konsequen-zen:

1. Die Layoutspezifikation ist ein XML-Dokument.

2. Der Zugriff auf die Layoutspezifikation erfolgt über ein Interface, bereitgestelltdurch die GSI-API. Die Zugriffssegmente, Teil des Repositories selbst, entspre-chen einem statischen Block, der den Kopf des XML-Dokumentes bildet. DieseKopfdaten sind in Anhang B angeführt.

3. Die Layoutangaben der Spezifikation werden durch Name-Ausdruck-Paare imXML-Repository abgebildet und entsprechend in Informationssegmente grup-piert:• allgemeine Layoutangaben• Layoutangaben der Knotendarstellung• Layoutangaben der Kantendarstellung

Für die Informationssegmente, welche Layoutangaben gruppieren, existieren Signatu-ren. Um z.B. eine allgemeine Layoutangabe zu spezifizieren, wird die Layoutangabe

7.3 Name-Ausdruck-Paare des Repositories 37

in die Signatur gesetzt und diese in die Spezifikation aufgenommen. Die Signaturendienen somit als “Schablonen” bei der Entwicklung eigener Layoutspezifikationen.

Aufbau

Für das XML-Dokuments, welches das GSI-Repository beschreibt (kurz: die Layout-spezifikation), ergibt sich aus folgender Aufbau für die Entwicklung eigener Layout-spezifikationen:

<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE GSIFunctionSet SYSTEM "GSIF.dtd">

<GSIFunctionSet name="LayoutSpec" version="1.0">



</GSIFunctionSet>

7.3 Name-Ausdruck-Paare des Repositories

Alle Layoutangaben werden durch (meist konstante) Ausdrücke gesetzt. Einer einfa-chen Layoutangabe, die einer Eigenschaft einen festen Wert zuweist, wird also einkonstanter (GReQL-) Ausdruck des gewünschten Typs (Integer, Float, String) zuge-wiesen; der Wert einer Layoutangabe kann aber somit auch immer das Ergebnis einerAnfrageauswertung sein.

Synonym zu “Name-Ausdruck-Paar” ist “Name-Anfrage-Paar”; auch bei konstantenAusdrücken handelt es sich immer um auszuwertende GReQL-Anfragen.

Anfrageauswertung

Da über die Auswertung beliebiger Anfragen der Wert einer Layoutangabe bestimmtwerden kann, ist es möglich, Eigenschaften des konkreten Eingabegraphen bei derVisualisierung zu nutzen. Zusätzlich kann, bei Layoutangaben für Knoten und Kanten,das aktuelle Graphelement über eine freie Variable genutzt werden. Die Bezeichnerdieser Bindungen sind fest vorgegeben:

• v für Knoten• e für Kanten

Somit ist es zum Beispiel möglich, über die Anfrage

USING v: typeName(v)

den Typbezeichner eines Knotens als Beschriftung zu setzen (vgl. Kap. 7.6.3).

7.4 Allgemeine Layoutangaben 38

Name-GreqlText-Tupel

Durch der Verwendung des Anfrageauswerters ergibt sich: Alle Layoutangaben sindName-GreqlText-Tupel (vgl. Abb. 24) im Repository, eingebettet in ein GSI-Informationssegmentfür allgemeine Layoutangaben, Layoutangaben der Knoten- oder der Kantendarstel-lung.

<Tupel><Name>NameOfLayoutProperty</Name><GreqlText>Expression</GreqlText>

</Tupel>

Abbildung 24: Layoutangaben als Name-GreqlText-Tupel

Außerdem muss bei Anfragen in GreqlText-Elementen darauf geachtet werden, dassfür XML reservierte Zeichen (z.B. “<”) entweder entsprechend maskiert werden odersog. CData-Blöcke verwendet werden.

Alle im Folgenden vorgestellten Layoutangaben werden jeweils in einer Tabelle zu-sammengefasst, die den Namen (Name-Element im Tupel) und den erwarteten Ergeb-nis-Wertebereich10 der Anfrage im GreqlText-Element aufführt.

7.4 Allgemeine Layoutangaben

Unter allgemeinen Layoutangaben versteht man alle Angaben, welche die Darstellungdes gesamten Graphen beeinflussen. Sie werden einmal definiert und gelten global. Al-le allgemeinen Layoutangaben sind in einem Informationssegment zusammengefasst.Ein solches Informationssegment muss nicht Teil einer Layoutspezifikation sein. Wirdkein Informationssegment angegeben oder nur Teile der möglichen Layoutangabenangegeben, so gelten Standardwerte für nicht neu definierte Layoutangaben.

7.4.1 Signatur des Informationssegments

Wie in Kapitel 7.2 beschrieben, werden Layoutangaben in Informationssegmente grup-piert. Allgemeine Layoutangaben werden in der Spezifikation durch folgendes Seg-ment angegeben:

<GSIFunctionApplication function="CommonLayoutProperties">

<Parameter/>

<Result><Set>

</Set>

</Result>

</GSIFunctionApplication>

10 Anfragen, die ungültige Werte liefern, werden ignoriert.


7.4.2 Layoutverfahren

Die prominenteste, allgemeine Layoutangabe ist die des verwendeten Layoutverfah-ren. Zur Wahl stehen die in der GraphViz Library [GraphViz01] implementierten Lay-outverfahren:

• ein hierarchisches Layoutverfahren nach Sugiyama [Ref] – dot• ein symmetrisches Verfahren nach Kamada-Kawai [Ref] – neato• ein radiales Verfahren nach Wills [Ref] – twopi

Name-Anfrage-Paar:

Name Standard Wertebereich

LayoutAlgorithm ’dot’ [’dot’, ’neato’, ’twopi’]

7.4.3 Größe der Gesamtgrafik

Die Höhe und Breite der Gesamtgrafik lässt sich über Layoutangaben steuern.

Dabei entspricht eine gegebene Größe der Gesamtgrafik bei einer SVG-Grafik der Grö-ße des Viewports (vgl. Kap. ??). Darüber hinaus gilt, dass über ein entsprechendesviewBox-Attribut das in User-Einheiten (vgl. Kap. 3.2) definierte Koordinatensystemder gegebenen Größe angepasst wird.Der Standardgröße (640pt auf 480pt) wird somit über das viewBox-Attribut "0 0 640480" das gleichlautende Koordinatensystem in User-Einheiten zugewiesen.

Name-Anfrage-Paare:


Width 640 N+

Height 480 N+

7.4.4 Hintergrundfarbe

Die Hintergrundfarbe der Gesamtgrafik kann ebenfalls als allgemeine Layoutangabeangegeben werden.

Name-Anfrage-Paar:


BackgroundColor TUP(

’default’,

216)

Auswahl aus CLUT / Gradient (vgl. Kap.

7.4.9 u. 7.4.11)


7.4.5 Navigationsrahmen

Diese Layoutangabe bestimmt, ob um die Graphvisualisierung klickbare Kontrollenfür Zoom und Navigation angezeigt werden (vgl. Abb. 25). Außerdem werden, wennein Navigationsrahmen gesetzt ist, angewählte Graphelemente optisch hervorgehoben.

Name-Anfrage-Paar:


NavigationFrame ’false’ [’true’, ’false’]

Abbildung 25: Graphvisualisierung mit Zoom- und Navigationskontrolle

7.4.6 Farben

Ein weiterer Aspekt der Layoutspezifikation wird prinzipiell als allgemeine Layou-tangabe behandelt: die zur Verfügung stehenden Farben. Layoutangaben, die Farbensetzen (z.B. die Hintergrundfarbe der Gesamtgrafik), können nur definierte Farben nut-zen.

Möglich ist

• die Definition einer oder mehrerer Farbtabellen (CLUT 11) oder• die Definition von Farbverläufen (Gradienten).

Beim Setzen von Farben wird jeweils ein Wert aus einer Farbdefinition (CLUT oderGradient) akzeptiert. Als Standard ist eine an die Netscape-Web-Farbpalette angelehn-te Farbtabelle vorhanden (s. Anhang A).

11 Color LookUp Table


7.4.7 Definition von Farben

Farben werden durch einen hexadezimalen Ausdruck innerhalb eines Text-Elementsdefiniert. Verwendet wird dazu das additive RGB-Farbsystem ([RGB01]). Eingeleitetwird der Ausdruck mit ’#’, für jeden der Farbkanäle (“Rot”, “Grün” und “Blau”) istein Wert x ∈ [00, . . . , FF ] erlaubt.

Blau wird zum Beispiel hexadezimal durch das Text-Element <Text>#0000FF</Text>definiert.

7.4.8 Definition einer Farbtabelle

Farbtabellen sind allgemeine Layoutangaben und gelten somit global; jede Farbtabellewird in einem eigenen Informationssegment spezifiziert.

Signatur: Informationssegment für eine Farbtabelle

Obwohl Farbtabellen als allgemeine Layoutangaben gelten, werden sie in einem eige-nen Informationssegment (vgl. Kap. 7.2) definiert:

<GSIFunctionApplication function="CLUT"><Parameter>

<Name>  </Name></Parameter><Result>

<List>

</List></Result>


Beispiel: Farbtabelle mit 6 Farbwerten

Die Farbtabelle SimpleCLUT möge die sechs am häufigsten verwendeten Farbwerteenthalten. Sie wird durch folgendes Informationssegment definiert:

<GSIFunctionApplication function="CLUT"><Parameter>

<Name>SimpleCLUT</Name></Parameter><Result>

<List><Text>#000000</Text> <Text>#0000FF</Text> <Text>#FF0000</Text> <Text>#00FF00</Text> <Text>#FFFF00</Text> <Text>#FFFFFF</Text> 

</List></Result>


7.4.9 Zugriff auf eine Farbtabelle

Eine Farbe aus einer Farbtabelle wird durch ein Tupel referenziert, bestehend aus


• dem Typen als String (hier: ’CLUT’; eine Farbtabelle),• dem Namen der Farbtabelle und• dem Index der gewünschten Farbe aus der Tabelle. Der Index beginnt bei 0.

Beispiel

Um beispielweise die Hintergrundfarbe des Gesamtgrafik (allgemeine Layoutangabe,s.o.) auf das Gelb der obigen Farbtabelle SimpleCLUT zu setzen, wird folgendes Tupleim Informationssegment der allgemeinen Layoutangaben benötigt:

<Tuple><Name>BackgroundColor</Name><GreqlText>TUP(’CLUT’, ’SimpleCLUT’, 4)</GreqlText>

</Tuple>

7.4.10 Definition eines Farbverlaufs

Unter einem Farbverlauf versteht man den sanften Übergang von einer Startfarbe zurgewünschten Zielfarbe. Abbildung 26 zeigt dazu einen Farbverlauf von Blau (#0000FF)nach Rot (#FF0000).

Abbildung 26: Farbverlauf Blau→ Rot

Farbverläufe sind, wie Farbtabellen, globale Layoutangaben und werden in einem ei-genen Informationssegment je Farbverlauf definiert.

Signatur: Informationssegment für einen Farbverlauf

Auch Farbverläufe werden wie Farbtabellen in einem eigenständigen Informationsseg-ment definiert:

<GSIFunctionApplication function="Gradient"><Parameter>

<Name>  </Name></Parameter><Result>

<Tuple><Text>  </Text><Text>  </Text>

</Tuple></Result>



Interpolation

Die Interpolation von Start- zu Zielfarbe verläuft linear innerhalb des RGB-Farbwürfels(Abb. 27). Der Farbverlauf aus Abbildung 26 entspricht demnach der Diagonalen der“Hinterseite” des RGB-Farbwüfels aus Abb. 27 (rechts) von rechts-unten (Blau) nachlinks-oben (Rot).

#FF00FF

#FF0000

#FFFFFF

#FFFF00#0000FF

#00FFFF

#00FF00

#FF00FF

#FF0000

#000000

#FFFF00#0000FF

#00FFFF

#00FF00

Abbildung 27: RGB-Farbwürfellinks: Weiss im Zentrum (Außenseite);

rechts: Schwarz im Zentrum (Innenseite)

Beispiel: Farbverlauf von Blau nach Rot

Der in Abb. 26 vorgestellte Farbverlauf von Blau nach Rot wird durch folgendes In-formationssegment spezifiziert:

<GSIFunctionApplication function="Gradient"><Parameter>

<Name>BlueToRed</Name></Parameter><Result>

<Tuple><Text>#0000FF</Text> <Text>#FF0000</Text> 

</Tuple></Result>


7.4.11 Auswahl aus einem Farbverlauf

Ähnlich dem Zugriff auf eine Farbpalette wird bei der Auswahl aus einem Farbverlaufüber ein GReQL-Tupel bestimmt, welche “Stelle” welches Farbverlaufs gesetzt wird.Entsprechend besteht das Tupel aus

• dem Typen (hier: ’Gradient’; ein Farbverlauf),• dem Namen des Farbverlaufs und• dem Index der gewünschten Farbe im Intervall [0, . . . , 1]; 0 entspricht der Start-

farbe, 1 der Zielfarbe.

7.5 Layoutangaben für Graphelemente 44

Beispiel

Die unten als Name-Anfrage-Paar angegebene Layoutangabe setzt, beispielsweise ineinem Informationssegment der allgemeinen Layoutangaben, die Hintergrundfarbe aufdie Farbe “zwischen” Blau und Rot.

<Tuple><Name>BackgroundColor</Name><GreqlText>TUP(’Gradient’, ’BlackToBlue’, 0.5)</GreqlText>

</Tuple>

7.5 Layoutangaben für Graphelemente

Im Gegensatz zu allgemeinen Layoutangaben, die nur einmal für einen gegebenen Gra-phen definiert werden, ist es möglich, verschiedene Layoutangaben für verschiedeneGraphelemente zu definieren. Dies erlaubt die Realisierung unterschiedlicher Visuali-sierungen, abhängig von Typen und Instanzen der Graphelemente eines Graphen, diedennoch über die gleiche Layoutspezifikation nach SVG konvertiert werden.

7.5.1 Ebenen

Um eine Feinkontrolle über die Verknüpfung einer Layoutangabe mit einem gegebe-nen Graphelement zu erreichen, sind die Layoutangaben in drei Ebenen unterteilt:

1. Globale AngabenSie wirken auf alle Graphelemente (Knoten bzw. Kanten) ein.Eigenschaften, die als globale Angaben definiert sind, dienen als (neue) Stan-dardwerte und gelten, wenn keine weitere Layoutangabe definiert ist.

2. Klassenbezogene AngabenEine solche Layoutangabe wirkt auf Graphelemente des gegebenen Typs12 undaller Subtypen ein.Klassenbezogene Layoutangaben überschreiben globale Layoutangaben für Gra-phelemente des gegebenen Typs.

3. Instanzbezogene AngabenDie dritte Ebene von Layoutangaben wirkt nur auf die gegebene Instanz ein; z.B. der Knoten v4 oder die Kante e42. Dies ist möglich, da die Graphelementeeines TGraphen in einer globalen Anordnung vorliegen.

Informationssegmente für Layoutangaben der Knoten- und Kantendarstellung steuernüber Parameter, auf welche Ebene sie einwirken:

1. Sie wirken global, wenn kein Parameter angegeben wird.

2. Sie wirken auf eine Klasse von Graphelementen des Typs x durch die Angabeeines TypeId-Elements als Parameter.

12 gemäß Graphklasse

7.6 Layoutangaben für die Knotendarstellung: 45

3. Sie wirken auf Instanzen von Graphelementen durch die Angabe eines entspre-chenden VertexId- oder EdgeId-Elements.

GSI erlaubt die Angabe mehrerer Parameter in einem Informationssegment. Somit istes möglich, dass z.B. ein Informationssegment der Knotendarstellung auf Klassen undInstanzen wirkt.

7.5.2 Beispiele

Global wirkendes Informationssegment durch ein leeres Parameter-Element:

<Paramter/>

Ein Informationssegment, dass auf die Klasse von Graphelementen des Typs SomeTy-peOfEdge wirkt:

<Parameter><TypeId>SomeTypeOfEdge</TypeId>

</Parameter>

Abschließend ein Informationssegment, welches auf einige (fiktive) Instanzen und eineKlasse einwirkt:

<Parameter><TypeId>YetAnotherTypeOfNode</TypeId><VertexId>v05</VertexId><VertexId>v42</VertexId><VertexId>v23</VertexId>

</Parameter>

7.6 Layoutangaben für die Knotendarstellung:

Layoutangaben der Knotendarstellung werden, analog zu den allgemeinen Layou-tangaben, ebenfalls in einem Informationssegment zusammengefasst. Über Parameter(s.o.) werden die Ebenen gesetzt, auf welche das Segment wirkt.

7.6.1 Signatur des Informationssegments<GSIFunctionApplication function="VertexLayoutProperties">

<Parameter>

</Parameter>

<Result><Set>


</Result></GSIFunctionApplication>

Im Folgenden werden die Layoutangaben der Knotendarstellung vorgestellt.


7.6.2 Darstellungsstil

Knoten lassen sich auf zwei verschiedene Arten darstellen:

1. einfache Darstellung durch Angabe der Shape

2. UML-Stil

Ein Knoten wird bei der einfachen Darstellung durch eine Shape mit Label darge-stellt. Das Label wird dazu immer zentriert in der angegeben Shape dargestellt (vgl.Abb. 28), kann aber durch eine eigenständige Layoutangabe der Knotendarstellungdefiniert werden (Kap. 7.6.3 unten).

HasNoEdges

Shape: ellipse

Label

Has6

Edges

Shape: hexagon

Label

Abbildung 28: Einfache Knotendarstellung (Beispiele)

Bei der UML-Darstellung werden Knoten immer entsprechend der Abbildung X ge-zeichnet.

vNo : TypeName

attr = val

UML-Stil

Abbildung 29: UML-Stil

Angaben zum Label werden bei der UML-Darstellung ignoriert, nicht aber Angabenwie

• Hintergrundfarbe,• Schriftart, -größe und -farbe,• Farbe, Stil und Größe der Umrandungslinie.

Diese Layoutangaben können zusätzlich zum UML-Stil gesetzt werden und.

Name-Anfrage-Paar:


VertexStyle ’ellipse’ [’circle’, ’diamond’,

’ellipse’, ’square’,

’rectangle’, ’uml’]


circle diamond ellipse rectangle square

Abbildung 30: Mögliche Shapes der einfachen Knotendarstellung

7.6.3 Label

Diese Layoutangabe wirkt nur auf Knoten, die nicht im UML-Stil gezeichnet werden.Als Standard wird der Typbezeichner dargestellt, erlaubt ist die Angabe aller Stringsbzw. Anfragen, die Strings liefern. Zeilenumbrüche werden dabei mit der Zeichenkette"\n" gesetzt.

Name-Anfrage-Paar:


Label USING v:

typeName(v)

Strings

Beispiel:

Das Label soll, über drei Zeilen, die Id, die Anzahl der Kanten am Knoten und denTyp anzeigen.

<Tuple><Name>Label</Name><GreqlText>USING v:

5 ’v’ + vertexId(v) + ’\n’ +degree: ’ + degree{}(v) + ’\n’ +’Type: ’ + typeName(v)

</GreqlText></Tuple>

resultierende SVG-Darstellung


Bei allen Knotendarstellungen, inklusive der UML-Darstellung, kann eine Hintergrund-farbe angegeben werden.

Name-Anfrage-Paar:



’default’,

215)

Auswahl aus CLUT / Gradient


7.6.5 Schrift

Die für das Label verwendete Schrift kann über drei Layoutangaben gesteuert werden;dabei kann die Schriftart (“Familie”), die Farbe und die Größe der Zeichen gesetztwerden.

Name-Anfrage-Paare:


FontColor TUP(

’default’, 0)


FontFamily ’sans-serif’ [’serif’, ’sans-serif’,

’monospace’]

FontSize 10 N+

Beispiel

Abb. 31 zeigt Möglichkeiten der Layoutangaben der Schriftgestaltung: Schriftfamilie,Größe und Farbe.

Abbildung 31: Layoutangaben der Schriftgestaltung

7.6.6 Umrandung

Der Umrandung der Shape, bzw. die Umrandung bei der UML-Darstellung, wird durchdrei weitere Layoutangaben: Stil (vgl. Abb. 32), Farbe und Stärke des Linienzuges.

solid dashed dotted

Abbildung 32: Linienstile

7.7 Layoutangaben der Kantendarstellung 49

Name-Anfrage-Paare:


LineColor TUP(

’default’, 0)


LineStyle ’solid’ [’solid’, ’dashed’, ’dotted’]

LineWidth 1 N+

7.6.7 Größe

Es ist außerdem möglich, die Breite und Höhe einer Knotendarstellung über Layou-tangaben zu definieren.

Dabei ist zu beachten, dass die Größe der Knotendarstellung zuerst vom Inhalt derDarstellung abhängt. D.h. dass schon die Schriftgröße die Größe des Knotens in dervisuellen Repräsentation beeinflusst, da immer versucht wird, Beschriftungen vollstän-dig anzuzeigen. Daraus folgt, dass ein Angabe der Knotengröße durch Höhe und Brei-te nur als Minimalwerte für die Knotengröße zu betrachten ist. Ein Knoten, der 50User-Einheiten breit sein soll, wird durch eine lange Beschriftung entsprechend grö-ßer dargestellt.

Name-Anfrage-Paare:


Width 100 N+

Height 75 N+

7.7 Layoutangaben der Kantendarstellung

Auch die Layoutangaben der Kantendarstellung sind in einem Informationssegmentzusammengefasst, das über Parameter steuert, auf welche Ebene das Segment wirkt.

7.7.1 Signatur des Informationssegments<GSIFunctionApplication function="EdgeLayoutProperties">

<Parameter>

</Parameter>

<Result><Set>




7.7.2 Darstellungsstil

Für die Kantendarstellung stehen vier Stile zur Verfügung:

1. einfache Darstellung;dabei wird nur der Kantenzug gezeichnet, ohne Beschriftung (linke Kante inAbb. 33)

2. beschrifteter Kantenzug;es wird die Typbezeichnung als Beschriftung des Kantenzuges gesetzt; anpass-bar mit der Label-Layoutangabe (mittlere Kante in Abb. 33)

3. UML-Stilähnlich der Knotendarstellung (rechte Kante in Abb. 33)

Abbildung 33: Kanten-Darstellungsstile

Name-Anfrage-Paar:


EdgeStyle ’simple’ [’simple’, ’label’, ’uml’]

7.7.3 Label

Die Kantenbeschriftung wird beim Darstellungsstil “beschrifteter Kantenzug” durchdiese Layoutangabe gesteuert. Auch hier wird, wie bei Knoten-Beschriftungen, mitder Zeichenkette “\n” ein Zeilenumbruch gesetzt.

Name-Anfrage-Paar:


Label USING v:

typeName(v)

Strings


7.7.4 Label-Schrift

Wie auch für Knoten kann die für das Label verwendete Schrift über drei Layoutanga-ben gesteuert werden.

Name-Anfrage-Paare:


FontColor TUP(

’default’, 0)


FontFamily ’sans-serif’ [’serif’, ’sans-serif’,

’monospace’]

FontSize 10 N+

7.7.5 Terminal-Label

Neben der Kantenbeschriftung selbst, welche in der Nähe der Mitte des Kantenzugesdargestellt wird13, kann für eine Kante ein Label für den Kantenanfang und -ende ge-setzt werden (sog. Terminal-Label); unterschieden wird zwischen Alpha- und Omega-Label einer Kante (vgl. Abb. 34).

Abbildung 34: Alpha- und Omega-Label einer Kante

Name-Anfrage-Paare:


AlphaLabel ” Strings

OmegaLabel ” Strings

7.7.6 Terminal-Label-Schrift

Die für die Terminal-Label verwendete Schrift lässt sich, analog zur Schrift der Kan-tenbeschriftung, über Layoutangaben eigenen Wünschen gemäß anpassen.

13 abhängig von Layoutverfahren


Name-Anfrage-Paare:


AlphaLabelFontColor TUP(

’default’, 0)


AlphaLabelFontFamily ’sans-serif’ [’serif’, ’sans-serif’,

’monospace’]

AlphaLabelFontSize 10 N+

OmegaLabelFontColor TUP(

’default’, 0)


OmegaLabelFontFamily ’sans-serif’ [’serif’, ’sans-serif’,

’monospace’]

OmegaLabelFontSize 10 N+


Name-Anfrage-Paar:



’default’,

215)


7.7.8 Kantensymbol

Für das Kantenstart- und Kantenendsymbol kann aus einer Reihe von Symbolen ge-wählt werden (vgl. Abb. 35 li.). Außerdem ist die Größe des Symbols definierbar (vgl.Abb. 35 re.).

filled-arrow empty-arrow

filled-dot empty-dot

none

arrow

filled-diamond empty-diamond size

Abbildung 35: Kantensymbole und -größe


Name-Anfrage-Paare:


AlphaSymbol ’none’ [’arrow’, ’filled-arrow’,

’empty-arrow’, ’filled-dot’,

’empty-dot’, ’filled-diamond’,

’empty-diamond’, ’none’]

OmegaSymbol ’arrow’ [’arrow’, ’filled-arrow’,

’empty-arrow’, ’filled-dot’,

’empty-dot’, ’filled-diamond’,

’empty-diamond’, ’none’]

AlphaSymbolSize 10 N+

OmegaSymbolSize 10 N+

7.7.9 Kantenzug

Die Layoutangabe, die das Aussehen des Linienzuges einer Kante bestimmt, schließtdie Möglichkeiten der Layoutspezifikation ab. Wie bei der Umrandung von Knotensind drei Stile möglich (vgl. Abb. 32).

Name-Anfrage-Paare:


LineStyle ’solid’ [’solid’, ’dashed’, ’dotted’]


8 Anwendungsbeispiel

Dieses Kapitel veranschaulicht die Möglichkeiten der Layoutspezifikation anhand meh-rerer Beispiele. Diese gehen insbesondere auf den Name-Anfrage-Ansatz der Layou-tangaben ein.

Alle folgenden Beispiele zeigen an Ausschnitten einige interessante und herausragen-de Möglichkeiten der Layoutspezifikation bei der Graphvisualisierung.

Layoutangaben global neu definieren

Die Standardwerte für Layoutangaben der Spezifikation setzen zwar eine vernünftigeBasis für die Graphvisualisierung; der Versuch, das GXL-Meta-Schema, Version 1.0,damit zu visualisieren, liefert aber ein ungenügendes Ergebnis:

Abbildung 36: Ausschnitt GXL-Meta-Schema (Standardwerte)

Durch globale Redefinition des Knoten- und Kantenstiles wird, durchden UML-Stilfür alle Knoten und Kanten, eine deutlich bessere Übersichtlichkeit erreicht.

Die dazu angewendete Layoutspezifikation:


<GSIFunctionSet name="LayoutSpec" version="1.0">5

<!−− Zugriffssegmente (Anhang B) fehlen! −−>

<GSIFunctionApplication function="EdgeLayoutProperties"><Parameter />

10 <Result><Set>

<Tuple><Name>EdgeStyle</Name><GreqlText>’uml’</GreqlText>

15 </Tuple></Set>


20 <GSIFunctionApplication function="VertexLayoutProperties"><Parameter /><Result>

<Set><Tuple>

25 <Name>VertexStyle</Name>


<GreqlText>’uml’</GreqlText></Tuple>

</Set></Result>

30 </GSIFunctionApplication>

</GSIFunctionSet>

Der oben gezeigte Ausschnitt, nun im UML-Stil:

Abbildung 37: Ausschnitt GXL-Meta-Schema (UML-Stil)

Layoutangaben nach Typ

Abb. 37 zeigt einige Kanten des Typs “isA”. Für diese ist der UML-Stil überflüssig;eine Kante mit passendem Symbol repräsentiert eine solche Kante genauso.

Um dies zu erreichen, werden globale Layoutangaben für Kanten des Typs “isA” mitentsprechenden Werten (Zeile 23-38) der Spezifikation hinzugefügt:




<GSIFunctionApplication function="EdgeLayoutProperties"><Parameter />

10 <Result><Set>

<Tuple><Name>EdgeStyle</Name><GreqlText>’uml’</GreqlText>

15 </Tuple></Set>


20 <GSIFunctionApplication function="EdgeLayoutProperties"><Parameter>

<TypeId>isA</TypeId>


</Parameter><Result>

25 <Set><Tuple>

<Name>EdgeStyle</Name><GreqlText>’simple’</GreqlText>

</Tuple>30 <Tuple>

<Name>OmegaSymbol</Name><GreqlText>’empty-arrow’</GreqlText>

</Tuple></Set>

35 </Result></GSIFunctionApplication>

<GSIFunctionApplication function="VertexLayoutProperties"><Parameter />

40 <Result><Set>

<Tuple><Name>VertexStyle</Name><GreqlText>’uml’</GreqlText>

45 </Tuple></Set>


50 </GSIFunctionSet>

Diese Spezifikation zeichnet den Ausschnitt nun mit entsprechenden Symbolen an al-len Kanten des Typs “isA”:

Abbildung 38: Ausschnitt GXL-Meta-Schema

Layoutangaben und Anfrageauswerter

Die Knoten im Schema-Ausschnitt (Abb. 38) werden im UML-Stil dargestellt. Diesbezieht sich in diesem Fall auf die Knotenklasse und dessen Attribute, welche aberwiederum Klassen repräsentieren. Der Name dieser Klassen ist im Attribut “name”gegeben; über eine Anfrage kann dieses als Beschriftung gesetzt werden, indem für


Knoten des Typs “NodeClass” ein neues Informationssegment mit Layoutangaben derSpezifikation hinzugefügt wird:




<!−− bisherige Informationssegmente ausgeblendet −−>

10 <GSIFunctionApplication function="VertexLayoutProperties"><Parameter>

<TypeId>NodeClass</TypeId></Parameter><Result>

15 <Set><Tuple>

<Name>VertexStyle</Name><GreqlText>’rectangle’</GreqlText>

</Tuple>20 <Tuple>

<Name>Label</Name><GreqlText>USING v: v.name</GreqlText>

</Tuple></Set>

25 </Result></GSIFunctionApplication>

</GSIFunctionSet>

Alle Knoten des Typs “NodeClass” werden nun mit dem Klassennamen aus dem At-tribut “name” beschriftet:

Abbildung 39: Ausschnitt GXL-Meta-Schema

9 Fazit 58

9 Fazit

Das geforderte Tool zur Graphvisualisierung, wie in dieser Studienarbeit beschrieben,konnte umgesetzt werden. Insbesondere die angedachten Fähigkeiten der Layoutspezi-fikation, im Zusammenspiel mit dem Anfrageauswerter, sind wie beschrieben einsetz-bar. Dies macht des hier vorgestellte Werkzeug zu einem besonders für die Graphvi-sualisierung geeigneten Tool mit der Neuheit, den darzustellenden Graphen als Quellefür Attribute der Darstellung heranzuziehen.

Im Folgenden wird das Geleistete noch einmal zusammengefasst und abschließendbewertet.

9.1 Zusammenfassung des Entwicklungsverlaufs

Aus einer zu Beginn ausgearbeiteten, kurzen Problembeschreibung entwickelte sichschnell die Dreiteilung der Arbeit in Layoutspezifikation, Layouter und Visualisie-rer. Für Layouting-Aufgaben wurde von vornherein die GraphViz-Bibliothek ins Au-ge gefasst, auch SVG als visuelle Repräsentation war vorgegeben. Somit übernahm dieLayoutspezifikation die Hauptrolle (Kap. 5 u. 7); waren zu Beginn noch fest definierte,unflexible Layoutangaben angedacht, wurde diese während der Entwicklung der Mög-lichkeiten der Spezifikation zu den hier vorgestellten, “dynamischen” Layoutangabenmit Hilfe des Anfrageauswerters.

Nachdem die Layoutspezifikation im Wesentlichen aufgesetzt wurde, begann die itera-tive Entwicklung eines Testsystems. Durch dieses Testsystem konnten erste Erfahrun-gen mit dem Design der Layoutspezifikation gemacht werden, insbesondere da die-se als GSI-Applikation implementiert wurde (Kap. 7.2). Außerdem konnte aus demTestsystem, über iterative Entwicklungsschritte, der endgültige g2svg-Baustein fertig-gestellt werden. Die gesammelten Erfahrungen während des Testens sind so in deng2svg-Baustein geflossen.

9.2 Schlussbemerkung

Obwohl manche Möglichkeit, die SVG bereitstellt, (Scripting-Fähigkeiten und wei-terführende Textformatierungen) nur im Ansatz verwendet wird und die Pflege derLayoutspezifikation als XML-Dokument über einen dafür ausgelegten Editor verein-facht werden könnte, bietet das hier vorgestellte Werkzeug zur Graphvisualisierungein umfangreiches Potential an. Insbesondere die GReQL-Anbindung und die damitmögliche Einbeziehung des gegebenen Graphen mit all seinen Eigenschaften in dieVisualisierung schafft neue, sehr flexible Darstellungsweisen.

A Standard-Farbtabelle 59

A Standard-Farbtabelle

Abbildung 40: Farbtabelle default


B Zugriffsinformation der Layoutspezifikaten

<GreqlText><![CDATA[

USING informationtype, name :FROM it:V{InformationType}, n:V{Name}, gfa:V{GSIFunctionApplication}, g:V{GreqlText}

5 WITH it.value = informationtype ANDn.value = name ANDit (-->{isParameterIn}) gfa ANDn (-->{isParameterIn}) gfa ANDgfa.function = ’AccessInformation’ AND

10 g (-->{isResultIn}) gfaREPORT g.valueEND ]]></GreqlText>

15 <!−− Ermöglicht den Zugriff auf allgemeine Layoutangaben −−><GSIFunctionApplication function="AccessInformation">

<Parameter><InformationType>CommonLayoutProperties</InformationType><Name>GlobalStyle</Name></Parameter>

20 <Result><GreqlText><![CDATA[

FROM gfa:V{GSIFunctionApplication}, t:V{Tuple}WITH gfa.function = ’CommonLayoutProperties’ AND

t -->{isTupleIn}-->{isResultIn} gfa25 REPORT theElement(FROM n:V{Name}, g:V{GreqlText}

WITH n -->{isComponentIn} t ANDg -->{isComponentIn} t

REPORT SET n.value, g.value END)END

30 ]]></GreqlText></Result></GSIFunctionApplication>

<!−− Liefert die globalen Layoutangaben (für Knoten oder Kanten) −−><GSIFunctionApplication function="AccessInformation">

35 <Parameter><InformationType>LayoutProperties</InformationType><Name>DefaultLayout</Name></Parameter>

<Result><GreqlText><![CDATA[

40 USING func :FROM gfa:V{GSIFunctionApplication}, t:V{Tuple}WITH inDegree{isParameterIn}(gfa) = 0 AND

gfa.function = func ANDt -->{isTupleIn} -->{isResultIn} gfa

45 REPORT theElement(FROM n:V{Name}, g:V{GreqlText}WITH n -->{isComponentIn} t AND

g -->{isComponentIn} tREPORT SET n.value, g.value END)

END50 ]]></GreqlText></Result></GSIFunctionApplication>

<!−− Liefert alle Layoutangaben zu gegebener Knoten−Id −−><GSIFunctionApplication function="AccessInformation">

55 <Parameter><InformationType>VertexLayoutProperties</InformationType><Name>LayoutForVertexId</Name></Parameter>


60 USING vId :FROM gfa:V{GSIFunctionApplication}, t:V{Tuple}, id:V{VertexId}WITH id -->{isParameterIn} gfa AND

id.value = vId ANDgfa.function = ’VertexLayoutProperties’ AND

65 t -->{isTupleIn}-->{isResultIn} gfaREPORT theElement(FROM n:V{Name}, g:V{GreqlText}



REPORT SET n.value, g.value END)70 END ]]></GreqlText></Result></GSIFunctionApplication>

<!−− Liefert alle Layoutangaben zu gegebener Kanten−Id −−><GSIFunctionApplication function="AccessInformation">

75 <Parameter><InformationType>EdgeLayoutProperties</InformationType><Name>LayoutForEdgeId</Name></Parameter>


80 USING eId :FROM gfa:V{GSIFunctionApplication}, t:V{Tuple}, id:V{EdgeId}WITH id -->{isParameterIn} gfa AND

id.value = eId ANDgfa.function = ’EdgeLayoutProperties’ AND




<!−− Liefert alle Layoutangaben zu gegebener Typ−Id −−><GSIFunctionApplication function="AccessInformation">

95 <Parameter><InformationType>LayoutProperties</InformationType><Name>LayoutForType</Name></Parameter>


100 USING type, func :FROM gfa:V{GSIFunctionApplication}, t:V{Tuple}, typeId:V{TypeId}WITH typeId -->{isParameterIn} gfa AND

typeId.value = type ANDgfa.function = func AND




C CD-Inhalt 62

C CD-Inhalt

Die dieser Arbeit beigelegte CD enthält die Quelltexte des implementierten g2svg-Bausteins, der ebenfalls Bestandteil des Repositories der Arbeitsgruppe Ebert am In-stitut für Softwaretechnik ist.

Ebenfalls auf der CD befindet sich die GraphViz-Bibliothek in der Version 2.6, welchedie Layoutverfahren bereitstellt.

LITERATUR 63

Literatur

[SVG01] Scalable Vector Graphics (SVG) 1.1 Specification,http://www.w3.org/TR/SVG11/intro.html

[SVG06] Scalable Vector Graphics (SVG): The preserveAspectRatio attribute,http://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute

[SVG02] Scalable Vector Graphics (SVG): Basic Shapes,http://www.w3.org/TR/SVG11/shapes.html

[SVG03] Scalable Vector Graphics (SVG): Paths,http://www.w3.org/TR/SVG11/paths.html

[SVG04] Scalable Vector Graphics (SVG): Styling,http://www.w3.org/TR/SVG11/styling.html

[SVG05] Scalable Vector Graphics (SVG): SVG’s styling properties,http://www.w3.org/TR/SVG11/styling.html#SVGStylingProperties

[CSS2-01] Cascading Style Sheets, level 2 (CSS2) Spezifikation,http://www.w3.org/TR/REC-CSS2/

[CSS2-02] Cascading Style Sheets, level 2 (CSS2): Generic font families,http://www.w3.org/TR/REC-CSS2/fonts.html#generic-font-families

[GXL01] Exchanging Graphs with GXL, Andreas Winter, Fachbericht Informatik9/2001, Universität Koblenz-Landau, Institut für Informatik, Koblenz,August 2001

[GXL02] GXL Instance API, Darya Zavgorodnya, Volker Riediger, Andreas Win-ter

[GXL03] GXL Webseite, Introduction,http://www.gupro.de/GXL/Introduction/intro.html

[GraphViz01] Drawing Graphs with GraphViz, Emden R. Gansner, 15. April 2003

[GSI01] Das GSI-Interface Benutzerhandbuch, Bernt Kullbach, Florian Schri-cker

[GREQL01] GReQL - eine Anfragesprache für das GUPRO-Repository, Sprachbe-schreibung (Version 1.2), Manfred Kamp

[RGB01] Der RGB-Farbraum, Wikipedia, die freie Enzyklopädie,http://de.wikipedia.org/wiki/RGB-Farbraum

[dot01] Methods for Visual Understanding of Hierarchical System Structures.K. Sugiyama, S. Tagawa, and M. Toda. IEEE Trans. Systems, Man andCybernetics, SMC- 11(2):109?125, February 1981.

LITERATUR 64

[neato01] An algorithm for drawing general undirected graphs. T. Kamada and S.Kawai. Information Processing Letters, 31(1):7?15, April 1989.

[twopi01] Nicheworks - interactive visualization of very large graphs. G. Wills. InG. DiBat- tista, editor, Symposium on Graph Drawing GD?97, volume1353 of Lecture Notes in Computer Science, pages 403?414, 1997.

Documents

Studienarbeit GXL2SVG - Visualierung von Graphen in SVGist/documents/schricker2005sa.pdf3.7.3 Globale CSS-Denition innerhalb der SVG-Grak . . . . . . 21 ... um die Position von