Halbautomatische Linienführung in Adora

Halbautomatische Linienführung in
Adora-Modellen unter Berücksichtigung
des Zoom-Algorithmus
Diplomarbeit im Fach Informatik
vorgelegt von
Tobias Reinhard
Horw, Schweiz
Matrikelnummer 00–713–446
Angefertigt am
Institut für Informatik
der Universität Zürich
Prof. Dr. Martin Glinz
Betreuer:
Silvio Meier
Christian Seybold
Abgabetermin der Arbeit:
30. September 2004
Inhaltsverzeichnis
Abbildungsverzeichnis
1 Einführung
1.1 Aufgabenstellung . . . . . . .
1.2 Aufbau der Arbeit . . . . . .
1.3 Adora Grundlagen . . . . .
1.3.1 Grundkonzepte . . . .
1.3.2 Sprachkonstrukte . . .
1.3.3 Visualisierungskonzept
1.4 Zoom-Algorithmus . . . . . .
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
3
4
4
6
10
12
2 Problemstellung
2.1 Linienführung mit Hindernissen . . . . . . . . . . .
2.1.1 Direkte Linien . . . . . . . . . . . . . . . .
2.1.2 Orthogonale Linien . . . . . . . . . . . . . .
2.1.3 Weitere Ansätze . . . . . . . . . . . . . . .
2.1.4 Beurteilungskriterien . . . . . . . . . . . . .
2.1.5 Linienführung in Adora-Modellen . . . . .
2.2 Dynamisches Layout . . . . . . . . . . . . . . . . .
2.2.1 Mental Map des Benutzers . . . . . . . . .
2.2.2 Mental Map einer Linie . . . . . . . . . . .
2.3 Sekundärnotation . . . . . . . . . . . . . . . . . . .
2.3.1 Sekundärnotation der Linienführung . . . .
2.3.2 Änderungen am Layout . . . . . . . . . . .
2.4 Anforderungen an einen Linienführungsalgorithmus
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
17
19
19
20
20
22
22
23
24
25
26
26
.
.
.
.
.
.
.
.
.
28
29
30
31
32
33
34
37
38
38
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Bestehende Ansätze der Linienführung
3.1 Automatisches Layouten von Graphen . . .
3.1.1 Graphenlayouter . . . . . . . . . . .
3.1.2 Layouten von dynamischen Graphen
3.1.3 Anwendbarkeit auf Adora-Modelle
3.2 Schaltungsentwurf . . . . . . . . . . . . . .
3.2.1 Algorithmus von Lee . . . . . . . . .
3.2.2 Line Probing . . . . . . . . . . . . .
3.2.3 Weitere Ansätze . . . . . . . . . . .
3.2.4 Anwendbarkeit auf Adora-Modelle
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
3.2.5
ii
Routing in Kommunikationsnetzwerken . . . . . . . . . . . . . . . . .
4 Linienführung in einem dynamischen Layout
4.1 Moderate Änderungen der direkten Linienführung . . . . . . . . . .
4.1.1 Das Linienproblem . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3 Beurteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Anwendung des Zoom-Algorithmus auf die Hilfspunkte . . . . . . . .
4.2.1 Vorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Beurteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Kopplung der Hilfspunkte an die Knoten . . . . . . . . . . .
4.3 Echter Routing-Algorithmus: Kachelbasierte Linienführung . . . . .
4.3.1 Explizite Repräsentation des freien Raumes . . . . . . . . . .
4.3.2 Entkopplung der eigentlichen Linienführung vom Finden eines
ten Pfades . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3 Sekundärnotation . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4 Linienüberlappungen und -überscheidungen . . . . . . . . . .
4.3.5 Beurteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.6 Weitere Anwendungsmöglichkeiten für die Datenstruktur . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
geeigne. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
5 Realisierung des Linienführungsalgorithmus
5.1 Datenstruktur: Corner Stitching . . . . . . . . . .
5.1.1 Kachel an bestimmter Position lokalisieren
5.1.2 Datenstruktur aufbauen . . . . . . . . . . .
5.1.3 Nachbarn bestimmen . . . . . . . . . . . . .
5.2 Geeigneten Pfad finden . . . . . . . . . . . . . . .
5.3 Linienführung . . . . . . . . . . . . . . . . . . . . .
5.3.1 Orthogonale Linienführung . . . . . . . . .
5.3.2 Linienführung mit Hilfe von Splines . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
41
41
41
42
44
45
46
46
48
48
48
51
56
58
59
61
62
62
62
64
66
67
70
70
76
6 Zusammenfassung und Diskussion
77
Literaturverzeichnis
79
Abbildungsverzeichnis
1.1
1.2
1.3
1.4
1.5
Adora-Modell eines Steuerungssystems einer Heizung
Kontextdiagramm des Steuerungssystems . . . . . . .
Vorgehen des Zoom-Algorithmus . . . . . . . . . . . .
Berechnung der Verschiebevektoren gemäss Berner . .
Fehlende Invertierbarkeit beim Zoom-Algorithmus . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
10
12
13
14
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
Hindernisse bei der Linienführung . . . . . . . . . . . . . . . . . . . .
Direkte Linienführung . . . . . . . . . . . . . . . . . . . . . . . . . . .
Einfügen mehrer Hilfspunkte . . . . . . . . . . . . . . . . . . . . . . .
Orthogonale Linienführung . . . . . . . . . . . . . . . . . . . . . . . .
Weitere Ansätze zur Linienführung . . . . . . . . . . . . . . . . . . . .
Linienführung in einem Scenariochart . . . . . . . . . . . . . . . . . .
Veränderung des Layouts durch den Zoom-Algorithmus . . . . . . . .
Konflikt bei der Erhaltung der Mental Map einer Linie . . . . . . . . .
Einfluss der Start- und Endpunkte auf die orthogonale Linienführung
Einflussnahme bei der direkten und orthogonalen Linienführung . . . .
Erhaltung der Sekundärnotation bei manuellen Änderungen . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
18
18
19
20
21
23
24
25
25
26
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
Verlegung von bestehenden Linien durch yFiles . .
Gitterstruktur . . . . . . . . . . . . . . . . . . . . .
Kosten berechnen . . . . . . . . . . . . . . . . . . .
Pfad zurückverfolgen . . . . . . . . . . . . . . . . .
Berechnete Distanzwerte . . . . . . . . . . . . . . .
Vorgehen beim Line Probing . . . . . . . . . . . .
Fluchtpunkte beim Line Probing . . . . . . . . . .
Beispiel eines Gitter-Graphen . . . . . . . . . . . .
Uniforme Gitterstruktur bei einem Adora-Modell
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
33
34
35
36
37
37
38
39
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
Linienproblem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lösung des Linienproblems durch das Einfügen von Hilfspunkten . . . .
Grenzen der moderaten Anpassung der Linienführung . . . . . . . . . .
Verschieben eines Hilfspunktes durch den Zoom-Algorithmus . . . . . .
Problem bei der Anwendung des Zoom-Algorithmus auf die Hilfspunkte
Anwendung des von Marty erweiterten Algorithmus von Berner . . . . .
Corner Stitching Datenstruktur . . . . . . . . . . . . . . . . . . . . . . .
Repräsentation der Nachbarschaftsbeziehungen zwischen den Kacheln .
Pfad aus freien Kacheln . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
43
44
46
47
47
49
49
51
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ABBILDUNGSVERZEICHNIS
iv
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
Uniforme Zellen / Kacheln der Corner Stitching Struktur . . . . . .
Berechnung der Distanzwerte . . . . . . . . . . . . . . . . . . . . . .
Beziehung zwischen Pfaden und ihren Elternpfaden . . . . . . . . . .
Pfadstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mehrere gleich lange Pfade . . . . . . . . . . . . . . . . . . . . . . .
Verschiedene Möglichkeiten der Linienführung in einem Pfad . . . .
Erhaltung der Sekundärnotation durch die Corner Stitching Struktur
Möglichkeiten zur Auflösung von Linienüberscheidungen . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
52
53
54
54
55
56
57
58
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
Kachel an einem bestimmten Punkt lokalisieren . . . . . . . . . . . . .
Knoten in die Corner Stitching Struktur einfügen . . . . . . . . . . . .
Unterschiedliche Corner Stitching Strukturen innerhalb eines Knotens
Auffinden aller Nachbarn einer Kachel . . . . . . . . . . . . . . . . . .
Finden eines geeigneten Pfades . . . . . . . . . . . . . . . . . . . . . .
Bestimmung des Startpunktes durch den Linienführungsalgorithmus .
Mögliche Konstellationen bei der orthogonalen Linienführung . . . . .
Bestimmung der Eintritts- und Austrittsrichtung . . . . . . . . . . . .
Vorgehen bei der orthogonalen Linienführung . . . . . . . . . . . . . .
Problemfälle bei der orthogonalen Linienführung . . . . . . . . . . . .
Mehrere Lösungen bei der orthogonalen Linienführung . . . . . . . . .
Linienführung mit Hilfe von Splines . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
64
66
67
68
69
71
71
72
74
75
76
Kapitel 1
Einführung
Die Bedeutung von Software hat in den letzten Jahren durch die zunehmende Automatisierung
in fast allen Lebensbereichen stark zugenommen. Dementsprechend werden Software-Systeme
immer komplexer und in Bereichen eingesetzt, in denen ein Fehlverhalten zu grossem wirtschaftlichem Verlust oder zur Gefährdung von Menschenleben führen kann. Die vielen Terminund Kostenüberschreitungen oder gar abgebrochenen Projekte zeigen, dass die Entwicklung
von Software auch heute noch nur ungenügend beherrscht wird. Mit der Enwicklung neuer Methoden und Techniken versucht das Software Engineering die Softwareentwicklung in
systematische und zuverlässigere Bahnen zu lenken.
Die ersten Probleme bei der Entwicklung eines Software-Systems bringt bereits die Spezifikation, d.h. die Erhebung der an das System gestellten Anforderungen, mit sich. Dies hat in
erster Linie damit zu tun, dass in dieser Phase auf einem hohen Abstrahierungslevel gearbeitet
werden muss und Personen aus den verschiedensten Bereichen in den Prozess involviert sind.
Als erschwerender Faktor kommt hinzu, dass Fehler, die in diesen frühen Phasen begangen
werden, später oft gar nicht mehr oder nur mit hohen Kosten korrigiert werden können. Eine
Spezifikation der Anforderungen in natürlicher Sprache lässt sich zwar ohne verherige Schulung erstellen und ist für alle Beteiligte verständlich; in eine solche Spezifikation schleichen
sich jedoch leicht Mehrdeutigkeiten und Widersprüche ein und die Zusammenhänge sind oft
nur schwer zu erkennen. Aus diesem Grund haben sich eine ganze Reihe teilformaler und formaler Modelle zur Beschreibung von Anforderungen und Entwürfen von Software-Systemen
entwickelt.
In den letzten Jahren hat sich aus diesen Ansätzen UML (Unified Modeling Language
[Rum99]) zu einem inoffiziellen Industriestandard entwickelt. UML ist ein offener und erweiterbarer Standard, der laufend weiterentwickelt wird und deshalb mitlerweile auch einen
sehr grossen Sprachumfang aufweist. Modelle bestehen in UML aus einer losen Sammlung von
Einzelmodellen, welche die verschiedenen Aspekte (wie z.B. die statische Struktur oder das
dynamische Verhalten) eines Systems beschreiben. Durch diese Aufteiltung in verschiedene
separate Modelle kann es leicht zu Konsistenzproblemen (d.h. widersprüchlichen Aussagen in
verschiedenen Teilmodellen) kommen und das Zusammensuchen der relevanten Informationen
kann sich mühsam gestalten. Daneben leidet UML auch noch unter anderen konzeptionellen
Schwächen. So existiert z.B. keine Möglichketen für eine systematische Systemdekompositi-
1
KAPITEL 1. EINFÜHRUNG
2
on1 , die eine Aufteilung des Gesamtsystems in kleinere und leichter verständliche Teilsysteme
ermöglicht. Zusätzlich sind auch viele Sprachkonstrukte nicht eindeutig definiert.
Adora [Joo99], [Gli02], [Xia04] ist eine objektorientierte Sprache zur Spezifikation von Anforderungen und Beschreibung von Software-Entwürfen mit dem Ziel, einige der grössten
Schwächen aktueller Modellierungssprachen wie z.B. UML zu überwinden. Adora steht dabei
als Akronym für “Analysis and Description Of Requirements and Architecture” und wurde von der Forschungsgruppe Requirements Engineering der Universität Zürich entwickelt.
Gegenüber bestehenden Modellierungssprachen weist Adora im Wesentlichen folgende Besonderheiten auf:
• Die Verwendung eines integrierten Modells, das nicht, wie z.B. UML, auf Klassen, sondern auf abstrakten Objekten basiert und durch eine hierarchische Dekomposition eine
Strukturierung des Systems ermöglicht.
• Ein Werkzeugkonzept, das die Visualisierung von Modellen in ihrem Kontext und in
Übereinstimmung mit ihrer logischen Struktur ermöglicht.
• Die Unterstützung eines flexiblen und inkrementellen Modellierungsprozesses, der insbesonders je nach Problemstellung verschiedene Formalitätsgrade von Modellen zulässt.
1.1
Aufgabenstellung
Adora ist in erster Linie eine graphische Spezifikationssprache, wodmit die Modelle primär
mittels graphischer Symbole beschrieben werden. Bei dieser Visualisierung werden Beziehungen zwischen den Symbolen der verschiedenen Sprachkonstrukten durch Linien repräsentiert.
Dabei ist es in der Regel unvermeidlich, dass es zu Überschneidungen zwischen diesen Linien
und anderen graphischen Symbolen kommt. Um die Lesbarkeit von Adora-Modellen nicht
zu beeinträchtigen ist es notwendig, die Linien um diese Hindernisse herumzuführen.
Das Problem der Linienführung tritt in dieser Form nicht nur in Adora-Modellen sondern
z.B. auch in UML-Klassenmodellen auf. Adora erlaubt es jedoch zusätzlich, ein System auf
verschiedenen Abstraktionsebenen zu beschreiben und darzustellen. Dabei können Details der
einzelnen Systemteile ein- oder ausgeblendet werden, wodurch das Layout2 der Darstellung
verändert wird. Dadurch weisen Adora-Modelle kein statisches Layout auf, bei dem die
Symbole bei der Erstellung des Modells platziert und dann deren Positionen und Grössen nicht
mehr verändert werden. Bei Adora muss vielmehr davon ausgegangen werden, dass aus dem
integrierten Gesamtmodell heraus für den Benutzer jeweils die Darstellung, die ihn bei seiner
momentanen Tätigkeit am Besten unterstützt, dynamisch generiert wird. Ein Adora-Modell
weist damit eine dynamische Darstellung auf, wodurch auch die Linienführung dynamisch
erfolgen muss. Die Linienführung ist damit keine einmalige Tätigkeit, sondern muss z.B. bei
einem Wechsel des Abstraktionsniveaus von Neuem durchgeführt werden. Die dynamischen
Darstellung erfordert zudem eine automatische Linienführung, da der Benutzer sonst nach
jeder Änderung der Darstellung die Linien manuell anpassen muss.
1
Ab Version 2.0 [Omg03] bietet nun auch UML Möglichkeiten zur Systemdekomposition.
Der Begriff Layout umfasst im Rahmen dieser Arbeit die Positionen und Grössen der graphischen Symbole,
die bei der Linienführung als Hindernisse auftreten können. Die Linien selbst gehören bei dieser Definition nicht
zum Layout. Der Begriff des Layouts wird damit gleich wie in [Ber02] und [Mar02] verwendet.
2
KAPITEL 1. EINFÜHRUNG
3
Auch ist es dem Benutzer möglich, Änderungen am Layout (d.h. der Position und Grösse
der graphischen Symbole) eines Adora-Modells vorzunehmen, um das Modell entsprechend
seinen Vorstellungen zu gestalten. Diese vom Benutzer vorgenommenen Änderungen, die sogenannte Sekundärnotation [Pet95], soll dabei unabhängig von der aktuell generierten Darstellung so weit wie möglich erhalten werden. Die Sekundärnotation umfasst jedoch nicht
nur die Position und Grösse der graphischen Symbole, sondern auch die Linien, mit denen
Beziehungen zwischen den verschiedenen Sprachkonstrukten repräsentiert werden. Bei einer
durch eine Veränderung der Darstellung notwendig gewordenen Anpassung der Linien muss
deshalb auch die Sekundärnotation dieser Linien so weit wie möglich erhalten werden.
Mit diesen drei Problembereichen der Linienführung in einem Adora-Modell beschäftigt sich
die vorliegende Arbeit. Dabei wird sowohl das grundlegende Problem analysiert, es werden
bestehende Ansätze auf ihre Anwendbarkeit untersucht und ein neuer Ansatz wird vorgeschlagen.
1.2
Aufbau der Arbeit
Die Arbeit gliedert sich in sechs aufeinander aufbauende Kapitel. Das Einführungskapitel
behandelt zuerst die Grundlagen der Sprache Adora. Danach folgt eine kurze Übersicht
über die grundlegenden Konzepte zur Visualisierung von Adora-Modellen. Abgeschlossen
wird dieses erste Kapitel mit einer Diskussion der bestehenden Zoom-Algorithmen, da diese
einen grossen Einfluss auf die Linienführung ausüben.
Eine detaillierte Diskussion des Problems der Linienführung in Adora-Modellen folgt in
Kapitel 2. Dabei geht es sowohl um die Linienführung in einem statischen Layout, als auch
um die speziellen Probleme, die sich durch das dynamische Layout von Adora-Modellen
ergeben. Zusätzlich befasst sich dieses Kapitel mit den Auswirkungen einer automatischen
Linienführung auf den Benutzer und - umgekehrt - mit dem Einfluss des Benutzers auf die
Linienführung.
In Kapitel 3 werden bestehende Ansätze der Linienführung aus den verschiedensten Bereichen, wie dem automatischen Zeichnen von Graphen oder dem computerunterstützten
Entwurf elektronischer Schaltungen, vorgestellt. Diese Ansätze gehen von einem statischen
Layout aus; ein dynamisch generiertes Layout, wie es bei Adora-Modellen auftritt, ist bei
diesen Ansätzen nicht vorgesehen.
Kapitel 4 geht auf Strategien für die Linienführung in Adora-Modellen ein. Diese unterscheiden sich von den Ansätzen in Kapitel 3 durch die zusätzliche Dynamik des Layouts. Dabei
werden als Erstes Ansätze diskutiert, die bereits andernorts (wie z.B. in [Ber02]) vorgeschlagen
worden sind. Ausgehend von den Problemen, die bei der Anwendung dieser Ansätze auftauchen, wird danach eine neue Strategie zur Linienführung in Adora-Modellen entwickelt.
Die zur Realisierung des in Kapitel 4 vorgestellten Ansatzes benötigten Algorithmen werden in
Kapitel 5 näher vorgestellt. Die Beschreibung bewegt sich dabei auf einer relativ abstrakten
Ebene, ohne auf die Realisierung in einer bestimmten Sprache oder Umgebung einzugehen.
Kapitel 6 schliesslich bildet mit einer Zusammenfassung und Beurteilung der Resultate der
Arbeit den Abschluss. Im abschliessenden Kapitel wird auch noch auf offene Fragen und im
Rahmen dieser Arbeit nicht behandelte Probleme eingegangen.
KAPITEL 1. EINFÜHRUNG
1.3
4
Adora Grundlagen
Die folgenden Abschnitte führen die Grundlagen der Sprache Adora ein. Dabei werden die
der Sprache zu Grunde liegenden Konzepte, die wichtigsten Sprachkonstrukte und die Grundlagen der Visualisierung behandelt. Es handelt sich dabei jedoch nur um eine Übersicht über
die elementarsten Eigenschaften und nicht um eine systematische Beschreibung der Sprache.
Für eine detaillertere Beschreibung von Adora sei deshalb auf [Joo99], [Gli02], [Ber02] und
[Xia04] verwiesen.
1.3.1
Grundkonzepte
Adora basiert im Wesentlichen auf den folgenden fünf grundlegenden Konzepten:
• Verwendung von abstrakten Objekten an Stelle von Klassen
• Strukturierung des zu modellierenden Systems durch ein hierarchische Dekomposition in eine Teil/Ganzes-Hierarchie
• Modellierung aller Aspekte des Systems in einem einzigen integrierten Modell
• Möglichkeit verschiedene Teile des Systems je nach Wichtigkeit und damit verbundenem
Risiko mit unterschiedlichen Formalitätsgraden zu beschreiben
• Visualisierung des Modells in seinem Kontext, indem Details immer mit einer Abstrahierung ihres Kontexts visualisiert werden
Abstrakte Objekte
Im Gegensatz zu den meisten objektorientierten Modellierungssprachen steht bei Adora
nicht ein Klassenmodell sondern ein Objektmodell im Mittelpunkt. Bei Klassendiagrammen
ist es nicht möglich, mehrere Objekte der gleichen Klasse oder Beziehungen zwischen Objekten
(und nicht Klassen) zu modellieren [Joo97], [Gli00]. Diese beiden Situationen treten in der
Praxis jedoch häufig auf. Ausserdem ist eine hierarchische Zerlegung des Gesamtmodells mit
Klassenmodellen nur schwer durchführbar. Dies liegt in erster Linie daran, dass Objekte einer
bestimmten Klasse in verschiedenen Teilen des Systems auftauchen können.
Werden abstrakte Objekte, d.h. abstrakte Repräsentationen konkreter Objekte, verwendet,
so treten diese Probleme nicht auf. Wird mit abstrakten Objekten gearbeitet, so rücken die
kontextabhängigen Aspekte der Objekte (z.B. Kommunikation, Interaktion, Beziehungen) in
den Vordergrund, was das Systemverständnis erleichtert. Kontextunabhängige Aspekte der
Objekte (d.h. die gemeinsamen Eigenschaften aller Objekte eines Typs) werden in Adora in
einem Typverzeichnis beschrieben. Ein Typ in Adora entspricht damit einer Klasse, wie sie
z.B. in einem UML-Klassenmodell auftritt. Die Typen können damit analog zu Klassenhierarchien in einer Subtypenhierarchie organisiert werden.
Um die Präzision in den Modelle zu erhöhen, unterscheidet Adora zwischen Objekten und
Objektmengen. Objekte repräsentieren dabei eine einzelne Instanz und Objektmengen stehen
als Repräsentanten für mehrere Instanzen.
KAPITEL 1. EINFÜHRUNG
5
Hierarchische Dekomposition
Um auch in einer grösseren Spezifikation die Übersicht zu behalten, ist es unumgänglich, das
Gesamtsystem in kleinere Teilsysteme zu zerlegen. Dabei gliedert eine gute Zerlegung das System rekursiv in kohärente Teile, die über schmale Schnittstellen miteinander kommunizieren
und für sich ohne detailliertes Wissen der anderen Teile verstanden werden können. Zusätzlich
sollte von jeder Komposition und ihren Beziehungen eine abstrakte Übersicht existieren.
Bestehende Modellierungssprachen beinhalten normalerweise zwei verschiedene Möglichkeiten
zur Dekomposition des Gesamtsystems: (i) die verschiedenen Aspekte des Systems werden in
unterschiedlichen Modellen beschrieben und (ii) verwandte Informationen werden in Behälterkonstrukten (wie z.B. Paketen in UML) abgelegt. Beide diese Ansätze vermögen jedoch den
Anforderungen an eine gute Dekomposition nicht zu genügen. Eine Dekomposition bezüglich
der verschiedenen Aspekte ermöglicht keine Zerlegung in kohärenten Teile, solange diese Teile
nicht den Aspekten entsprechen. In Behälterkonstrukten können, wie der Name schon andeutet, beliebige Dinge abgelegt werden. Pakete in UML haben z.B. eine zu schwache Semantik
um als Komposition in dem Sinne zu dienen, dass eine Komposition eine abstrake Übersicht
ihrere Teile und derer Beziehungen darstellt.
Im Gegensatz dazu werden Objekte in Adora rekursiv in weitere Objekte zerlegt. Dadurch
entsteht eine Teil/Ganzes-Hierarchie, die Objekte in eine baumartige Struktur einteilt. Objekte der tieferen Hierarchiestufen modellieren damit kleine Ausschnitte des Systems im Detail,
Objekte auf höheren Hierarchiestufen grosse Teile des Systems auf einer abstrakteren Ebene.
Integriertes Gesamtmodell
In bestehende Modellierungssprachen setzt sich das Gesamtmodell in der Regel aus einer
Reihe mehr oder weniger stark gekoppelter Diagramme zusammen. Bei dieser sogenannten
Aspektmodellierung werden die einzelnen Aspekte des Systems getrennt voneinander dargestellt. So beschreiben in UML z.B. Klassendiagramme die statische Struktur des Systems und
Zustandsautomaten das dynamisches Verhalten des Systems getrennt voneinander. Zusammenhänge und Abhängigkeiten zwischen den verschiedenen Aspektmodellen müssen deshalb
explizit beschrieben werden. Dabei kann es leicht zu Unstimmigkeiten und Widersprüchen
zwischen den verschiedenen Modellen kommen und viele Informationen werden in den verschiedenen Modellen redundant abgelegt.
Adora modelliert - im Gegensatz dazu - alle Modellierungsaspekte (z.B. Struktur, Daten,
Verhalten, Benutzerinteraktion) in einem integrierten Gesamtmodell. Dadurch wird zusätzlich
die Definition einer strengen Konsistenznotation möglich, welche als Grundlage für automatische Konsistenzprüfungen dienen kann. Ein einzelnes Modell ermöglich auch eine systematisches Vorgehen bei der Modellierung und reduziert den Anteil redundanter Informationen
und damit auch die Gefahr von Widersprüchen und Unstimmigkeiten.
Die Verwendung eines integrierten Modells bedeutet jedoch nicht, dass immer alle Informationen in einem einzigen Diagramm dargestellt werden. Bei einer solchen Flut von Informationen
wäre es kaum mehr möglich, sich im Modell zurecht zu finden. Die Menge der dargestellten
Informationen reduziert sich aus folgenden zwei Gründen: (i) durch die hierarchische Dekomposition ist der Benutzer in der Lage den Fokus und die Abstraktionsebene der Darstellung
auszuwählen und (ii) verwendet Adora ein Visualisierungskonzept, das auf der Einblendung
KAPITEL 1. EINFÜHRUNG
6
von Aspekten anstelle verschiedener Modellen beruht. Die Basissicht besteht dabei nur aus den
Objekten und Objektmengen und deren hierarchischer Struktur. In diese Basissicht können
vom Benutzer dann weitere Aspekte eingeblendet werden.
Das integrierte Gesamtmodell ist daher in der Regel ein abstraktes Modell, aus dem - je
nach Intension des Benutzers - verschiedene Darstellungen generiert werden. Die Lesbarkeit
des Modells wird dabei durch eine geeignete Wahl der Abstraktionsebene und durch das
Ausblenden von zur Zeit nicht interessierenden Aspekten gewährleistet.
Variabler Formalitätsgrad
Die Aufgabe der Software-Entwicklung besteht darin, die informalen Vorstellungen des Auftraggebers in den vollständig formalen Programmcode zu überführen. Beim ersten Schritt
dieses Prozesses, der Anforderungsspezifikation, sollte die Modellierungssprache die Wahl des
Formalitätsgrades dem Benutzer überlassen. Der Formalitätsgrad kann damit der Komplexität und Risikolastigkeit der Problemstellung angepasst werden. Das Spektrum kann dabei
von der informalen natürlichen Sprache bis hin zu vollständig formalen Elementen reichen.
In Adora hat der Benutzer die Wahl zwischen informalen, formalen oder teilformale Spezifikationsmöglichkeiten. Zustandübergänge können z.B. mit Hilfe einer formalen Notation,
informal mit Text oder teilformal beschrieben werden. Die Wahl des Formalitätsgrades bezieht sich dabei nicht auf das gesamte Modell, sondern es ist auch möglich, verschiedene Teile
eines Systems mit unterschiedlichen Formalitätsgraden zu beschreiben.
Visualisierung des Kontextes
Werden in existierenden Modellierungssprachen Möglichkeiten nur Systemdekomposition zur
Verfügung gestellt, so verwenden diese normalerweise einen explosiven Zoom. Dabei werden
die einer Komposition untergeordneten Elemente in einem separaten Diagramm dargestellt.
UML z.B. ermöglicht das Zusammenfassen von verwandten Informationen in einem Paket
und die Darstellung dieser Pakete und deren Beziehungen untereinander in einem Diagramm.
Die innere Struktur eines Pakets wird dann jedoch durch ein separates Klassendiagramm
beschrieben, wodurch die Informationen über den Kontext (d.h. die anderen Pakete und die
Beziehungen zwischen den Paketen), in den das Paket eingebettet ist, verloren gehen. Ein
explosiver Zoom führt also zu einem Verlust des umgebenden Kontextes.
Adora verwendet demgegenüber ein Fischaugenkonzept [Fur86], wodurch es möglich wird,
eine oder mehrere Komponenten des Systems mit einem höheren Detaillierungsgrad als sein
Umfeld darzustellen, wobei das Umfeld und damit der Kontext auf einer abstrakteren Ebene
sichtbar bleibt, [Ber02]. Dadurch wird die Verständlichkeit der Modelle erhöht und das Navigieren erleichtert. Diese Technik erlaubt es auch, den Abstrahierungsmechanismus der Sprache
durch ein entsprechendes Visualisierungskonzept in einem Werkzeug zu unterstützen.
1.3.2
Sprachkonstrukte
Ein Adora-Modell setzt sich aus einer hierarchischen Objektstruktur und einem Typenverzeichnis zusammen. Das Objektmodell wird durch die sogenannte Basisstruktur beschrieben
und ist nach dem Prinzip der Teil/Ganzes-Hierarchie aufgebaut. Die Basisstruktur kann durch
KAPITEL 1. EINFÜHRUNG
7
eine Reihe von aspektbezogenen Einblendungen ergänzt werden. Im Typenverzeichnis werden
die gemeinsamen (d.h. kontextunabhängigen) Eigenschaften aller Objekte eines bestimmten
Typs in textueller Form beschrieben.
Die folgenden Abschnitte beschreiben die Basistruktur und die verschiedenen Einblendungen.
Dabei dient ein verteiltes Steuerungssystem einer Heizung [Gli02] als Beispiel. Das System
soll eine komforable Steuerung eines Heizungssystems in einem aus mehreren Räumen bestehenden Gebäude ermöglichen. Dabei ist es möglich, das gesamte System von einem einzigen
Ort aus zu steuern. Zusätzlich kann auch eine Temperatursteuerung für jeden einzelnen Raum
individuell freigeschaltet werden. Das verteilte System setzt sich damit aus zwei Hauptteilen
zusammen, einem zentralen Steuerungsmodul und einer Reihe von Modulen zur individuellen
Steuerung der Temperatur in einem bestimmten Raum. Abbildung 1.1 zeigt das AdoraModell dieses Systems.
Abbildung 1.1: Adora-Modell eines Steuerungssystems einer Heizung
Basisstruktur
Die Basistruktur bildet eine Objekthierarchie bestehend aus Objekten und Objektmengen, die
nach dem Prinzip der Teil/Ganzes-Hierarchie ineinander geschachtelt sind. Objekte werden
darin als Rechtecke und Objektmengen als Rechteckstapel dargestellt. So ist das MasterModule in Abbildung 1.1 als Objekt modelliert, da es davon nur eine Instanz geben kann. Weil
es für jeden Raum eine eigene Instanz des RoomModule gibt, wird dieses als Objektmenge
mit der Kardinalität (1,n) modelliert.
Ein hierarchisch übergeordnetes Objekt steht im Modell als Abstraktion seiner Komponenten
im Sinne einer Kompositionsabstraktion. Um die Hierarchie im Modell sichtbar zu machen,
wird ein Komprimierungs- und Expansionsmechanismus verwendet, der es ermöglicht eine
Komposition auf einer beliebigen Abstraktionsebene darzustellen. Wird ein Objekt oder ei-
KAPITEL 1. EINFÜHRUNG
8
ne Objektmenge abstrahiert, d.h. durch die Ausblendung der darin enthaltenen Elemente,
dargestellt, so werden seinem Namen drei Punkte angefügt. So sind in Abbildung 1.1 auf
Seite 7 z.B. BoilerControlPanel und BoilerControl in einer abstrahierten Form dargestellt,
das Objekt RoomModule ist im Gegensatz dazu vollkommen expandiert, wodurch alle darin
enthaltenen Elemente sichtbar werden.
Strukturelle Sicht
Mit der strukturellen Sicht lässt sich die Basisstruktur mit Informationen über die Beziehungen zwischen den Objekten und Objektmengen erweitern. Alle Arten von Informationsfüsse
zwischen Objekten werden in Adora durch eine Art von Beziehung, der Assoziation, beschrieben. Eine Assoziation ist in Adora immer eine gerichtete binäre Beziehung und wird
durch die Angabe einer Bezeichnung und der Kardinalität näher spezifiziert. Besteht zwischen
zwei Objekten eine bidirektionale Beziehung, so wird diese durch zwei gerichtete Assoziationen modelliert. In einem Adora-Modell werden Assoziationen durch Linien zwischen den
beteiligten Objekten oder Objektmengen dargestellt.
Da sich in einem Adora-Modell die zwei an einer Assoziation beteiligten Objekte auf verschiedenen Abstraktionsebenen befinden können, müssen auch die Beziehungen die hierarchische
Struktur des Modells in geeigneter Form widerspiegeln. Beziehungen auf einer tiefen Abstraktionsebene müssen also auch auf höheren Abstraktionsebenen sichtbar bleiben. So existiert
z.B. in Abbildung 1.1 auf Seite 7 eine Assoziation zwischen zwei in BoilerControlPanel und
BoilerControl enthaltenen Objekten. Da diese beiden Objekte in der aktuellen Darstellung
nicht sichtbar sind, wird die Assoziation abstrahiert (durch eine dickere Linie) dargestellt.
Im Gegensatz dazu stellt die Assozation zwischen Settings und Controller innerhalb von
RoomControl eine Beziehung zwischen diesen beiden Objekten dar und ist deshalb nicht abstrahiert. Teilweise ist es nötig, sowohl die abstrahierte als auch die nicht abstrahierte Form
einer Assoziation gleichzeitig darzustellen. In diesem Fall werden die beiden Assoziationen
durch eine Haarlinie miteinander verbunden, um die hierarchischen Beziehungen zwischen
den Assoziationen hervorzuheben [Joo99].
Verhaltensorientierte Sicht
Im Gegensatz zu den meisten anderen Modellierungssprachen wird bei Adora auch das
Verhalten in die Basisstruktur integriert und damit mit dem Objektmodell verknüpft. Das
Verhalten wird dabei durch Statecharts [Har87] beschrieben. Zustände werden dabei, wie in
Statecharts üblich, durch Rechtecke mit abgerundeten Ecken dargestellt. Neben elementaren
Zuständen sind auch komplexe Zustände möglich. Komplexe Zustände enthalten selbst wieder
elementare oder komplexe Zustände.
Die Statecharts wurden in Adora in der Form erweitert, dass sie auch Objekte und Objektmengen enthalten können. Dabei repräsentieren jedes Objekt und jede Objektmenge einen
abstrakten Zustand, der weitere Objekte und/oder Zustände enthalten kann. Objekte, die
einen Zustand beschreiben, werden dabei als Komponentenzustand bezeichnet. Führt ein Zustandsübergang zu einem solchen Komponentenzustand, so bedeutet dies, dass eine Instanz
des Objekts erzeugt wird. Beim Verlassen des Komponentenzustandes wird diese Instanz wieder zerstört. Das Objekt HeatingOn in Abbildung 1.1 auf Seite 7 ist ein Komponentenzustand.
KAPITEL 1. EINFÜHRUNG
9
Kommt es vom elementaren Zustand HeatingOff zu einem Zustandsübergang auf HeatingOn,
so wird eine Instanz davon erzeugt. Im Kontext der Heizungssteuerung ist das so zu verstehen,
dass die Funktionen zur Steuerung der Heizung eines Raumes erst verfügbar werden, wenn
die Heizung für diesen Raum eingeschalten worden ist.
Zustände werden durch Zustandsübergänge miteinander verbunden. Bei einem Zustandsübergang wird durch eine Übergangsbedingung und eine Übergangsaktion spezifiziert, unter welchen Umständen der Zustandsübergang eintritt und welche Aktionen dabei ausgelöst werden. Ein Zustandsübergang wird bei den Statecharts durch einen Pfeil zwischen den beiden
Zuständen dargestellt. Die Bedingungen und Aktionen der Zustandsübergänge können dabei informal, formal oder teilformal spezifiziert werden. So wird z.B. in Abbildung 1.1 der
Zustandsübergang vom Zustand LocalControlOf zum Zustand LocalControlOn formal spezifiziert, derjenige vom Zustand LocalControlDisabled zum Komponentenzustand LocalControlEnabled informal mit natürlicher Sprache.
Funktionale Sicht
In der funktionalen Sicht werden Eigenschaften von Objekten oder Objektmengen beschrieben, die nicht bereits durch den Typ im Typenverzeichnis definiert worden sind. Die funktionale Sicht existiert nur in textueller Form und wird auch nicht wie die anderen Sichte in die
Basisstruktur eingeblendet. Haben z.B. die beiden Objekte BoilerControl und RoomControl
im Modell von Abbildung 1.1 den gleichen Typ, so können mit Hilfe der funktionalen Sicht
die Unterschiede (z.B. in den Initialisierungswerten der Attribute) beschrieben werden.
Benutzersicht
Die Benutzersicht beschreibt das System aus dem Blickwinkel des Benutzers, wobei dieser den
inneren Aufbau des Systems nicht kennt. Die Benutzersicht wird in Adora durch hierarchisch
strukturierte Szenarien beschrieben. Unter Szenario wird dabei eine geordnete Menge von
Interaktionen zwischen Partnern, in der Regel dem System und einer Menge von externen
Akteuren, verstanden.
Objekte und Szenarien stellen in Adora komplementäre Konzepte dar. Szenarien beschreiben
die Stimuli, die von externen Akteuren in das System gelangen, und die Reaktionen des
Systems darauf. Hängen diese Reaktionen von vorhergehenden Stimuli und Reaktionen ab,
so ist eine Spezifikation mit Szenarien alleine nicht mehr möglich. In solchen Fällen werden
zusätzlich auch die Objekte benötigt. Szenarien werden in Adora-Modellen durch Ovale
dargestellt und können in Objekte eingebettet werden. Ein eingebettetes Szenario interagiert
bei seiner Ausführung mit dem umgebenden Objekt.
Szenarien können textuell oder mit Hilfe von Statecharts spezifiziert werden. Zusätzlich ist es
auch möglich, die Szenarien mit Hilfe sogenannter Scenariocharts [Xia04] zu beschreiben. Szenariocharts sind um Nebenläufigkeit erweiterte Jackson-Diagramme [Jac75]. Mit Hilfe diese
Scenariocharts ist auch in der Benutzersicht eine hierarchische Dekomposition möglich. Dabei werden Szenarien auf einer hohen Abstraktionsebene durch weitere Szenarien auf einer
tieferen Ebene genauer beschrieben. Die Benutzersicht ermöglicht damit die Einbettung einer
zweiten parallelen Hierarchie in die Basisstruktur.
KAPITEL 1. EINFÜHRUNG
10
Kontextuelle Sicht
In der kontextuellen Sicht werden die Akteure und Objekte in der Umgebung des zu modellierenden Systems dargestellt. Da die kontextuelle Sicht ebenfalls in die Basisstruktur eingeblendet wird, kann der Kontext des Systems auf jeder Abstraktionsebene dargestellt werden. Wird
das System weitestgehend abstrahiert, so entspricht die Basisstruktur mit der eingeblendeten
kontextuellen Sicht einem Kontextdiagramm. Abbildung 1.2 zeigt das Kontextdiagramm des
Steuerungssystems aus Abbildung 1.1 auf Seite 7. Dabei wird von allen Details innerhalb von
HeatingControlSystem abstrahiert. Operator, Boiler, RadiatorValve und User sind in diesem
Diagramm Akteure, die mit dem System interagieren.
In Adora können nicht nur Beziehungen zwischen den Akteuren und dem System, sondern
auch Beziehungen zwischen verschiedenen Akteuren ausserhalb des Systems spezifiziert werden. Akteure werden in Adora graphisch durch Sechsecke dargestellt und die Beziehungen
durch Linien.
Abbildung 1.2: Kontextdiagramm des Steuerungssystems
1.3.3
Visualisierungskonzept
Um die Erstellung und Bearbeitung von Adora-Modellen in einem Werkzeug zu ermöglichen,
wurde ein neuartiges Visualisierungskonzept [Ber02], [Xia04] entwickelt, das dem Abstraktionsmechanismus der Sprache Rechnung trägt. Dabei wird nicht - wie in den meisten Werkzeugen üblich - ein explosiver Zoom, sondern ein Zoom, der auf dem sogenannten Fischaugenkonzept [Fur86] aufbaut, eingesetzt. Dieses Visualisierungskonzept wird in den nächsten
Abschnitten näher erläutert. Zuerst soll aber die folgende Aufzählung einen kurzen Überblick
über die Anforderungen an ein gutes Visualisierungskonzept geben [Ber02]. Ein solches Konzept ist sowohl für die Verständlichkeit als auch die Benutzerfreundlichkeit eines graphischen
Modells von entscheidender Bedeutung.
• Die Orientierung im Modell soll dadurch unterstützt werden, dass jeweils nur so viele
Details wie im Moment benötigt dargestellt werden, ohne dass dabei der globale Kontext, in den diese eingebettet sind, verloren geht.
KAPITEL 1. EINFÜHRUNG
11
• Der kognitive Ballast für die Navigation muss minimiert werden. Als kognitiver Balast
[Bea90] werden jene Überlegungen des Benutzers bezeichnet, die ausschliesslich dazu dienen, die Bedienungsschritte zu bestimmen, die zum Erreichen eines Navigationsschrittes
benötigt werden.
• Der Semantik der zugrunde liegenden Notation muss Rechnung getragen werden, um
die Ausdrucksstärke des Modells in der Visualisierung zu erhöhen.
• Die Verständlichkeit der Visualisierung soll durch die Unterstützung des Abstraktionsmechanismus des Modells erhöht werden.
• Die Visualisierung soll eine Sekundärnotation [Pet95] unterstützen. Die Sekundärnotation umfasst dabei die Änderungen, die der Benutzer manuell am Layout vornimmt.
Diese Sekundärnotation sollte auch bei der Durchführung von Navigationsaktivitäten
so weit wie möglich erhalten bleiben.
Werden hierarchische Strukturen in einem Werkzeug visualisiert, so kommt dabei in den
meisten Fällen eine der folgenden Techniken zum Einsatz: (i) es wird jeweils nur ein Element
und dessen direkte Nachfolger in der Hierarchie auf einmal dargestellt oder (ii) alle Elemente
werden in einer einzigen Sicht (teilweise noch mit einer zusätzlichen Übersicht) visualisiert.
Bei (i) kommt dabei in der Regel ein explosiver Zoom zum Einsatz. Bei einem explosiven
Zoom geht der aktuelle Kontext verloren, weil das Element, auf das der Zoom angewandt
wird, nach dem Zoomschritt das gesamte aktuelle Fenster einnimmt oder in einem neuen
Fenster dargestellt wird. Diese Werkzeuge können also nur entweder eine globale Sicht ohne
lokale Details oder lokale Details ohne den globalen Kontext darstellen. Dadurch wird der
kognitive Ballast bei wachsender Modellgrösse erheblich vergrössert [Ber98].
Im Gegensatz dazu setzt das Visualisierungskonzept von Adora auf das Fischaugenkonzept
[Fur86]. Das Fischaugenkonzept bietet - in Analogie zu einem Fischauge - eine Visualisierung,
die im fokussierten Punkt lokale Details zeigt, wobei der Detaillierungsgrad mit wachsender
Entfernung von diesem Punkt abnimmt. Eine Fischaugensicht visualisiert ein Modell also mit
Hilfe eines Weitwinkelobjektivs. Dadurch können sowohl lokale Details als auch der globale
Kontext in einer Sicht dargestellt werden. Die lokalen Details werden dabei benötigt, um dem
Benutzer alle Informationen über den Teil bereitzustellen, auf den er im Moment fokussiert ist.
Der globale Kontext ist nötig, um die Position des Fokus im gesamten Modell zu bestimmen
und damit Voraussetzung für eine schnelle und einfache Orientierung und Navigation.
Beim Visualisierungskonzept von Adora wird das Fischaugenkonzept nicht in seiner ursprünglichen Form angewandt, sondern den Anforderungen angepasst. Die Fischaugensicht
wird dabei nicht durch eine geometrische Projektion eines grossen flachen Modells generiert.
Stattdessen kommt eine logische Fischaugensicht zum Einsatz, die auf dem Abstraktionsmechanismus von Adora aufbaut. Weiter sind in der Fischaugensicht, wie sie in Adora zum
Einsatz kommt, mehr als nur ein Fokus möglich. Durch dieses Konzept können im Moment
weniger interessierende Element in komprimierter Form (d.h. abstrahiert) und die im Zentrum
des Interesse liegenden Element in expandierter Form dargestellt werden.
Das Visualisierungskonzept führt dazu, dass in Adora-Modellen zwei Möglichkeiten der Navigation existieren [Sch96], eine physikalische und eine logische Navigation. Physikalische Navigation wird nötig, sobald die Grösse der Darstellung die Grösse des Bildschirms überschreitet. Dabei handelt es sich um die etablierte Navigationsart in einem flachen Modell, wobei
KAPITEL 1. EINFÜHRUNG
12
normalerweise Mittel wie Rollbalken oder ein Zoom (in diesem Fall ein Zoom mit globalem
Skalierungseffekt) zum Einsatz kommen. Adora bietet zusätzlich noch eine logische Navigation für das Navigieren in der hierarchischen Struktur. Damit wird es möglich, Elemente
zu verfeinern3 (Einzoomen) und damit darin enthaltene Element auf einer tieferen Abstraktionsebene sichtbar zu machen. Beim Vergröbern (Auszoomen) wird von den Datails, die in
einem Element enthalten sind, abstrahiert und damit eine abstraktere Sicht generiert.
1.4
Zoom-Algorithmus
Das zur logischen Navigation benötige Vergröbern und Verfeinern von Objekten, Objektmengen und komplexen Zuständen erfordert einen Algorithmus, der die dabei notwendigen
Änderungen am Layout vornimmt. Beim Visualisierungskonzept von Adora-Modellen übernimmt der Zoom-Algorithmus von Berner [Ber02] diese Aufgabe. Er bietet die notwendige
Funktionalität zur Verfeinerung von Objekten. Die Vergröberung kann ebenfalls mit diesem
Algorithmus realisiert werden, wobei jedoch zusätzliche Massnahmen nötig werden, um Okklusionen4 zwischen Objekten zu verhindern.
Wird ein Objekt in einem logischen Zoom-Schritt verfeinert oder vergröbert, so ändert sich die
Grösse des Objekts, um Platz für die Darstellung der darin enthaltenen Details zu schaffen
bzw. diesen Platz wieder freizugeben, wenn die Details nicht mehr dargestellt werden. Bei
einer solchen Grössenänderung müssen auch die Positionen der Objekte in der Umgebung des
Objekts angepasst werden. Diese Objekte werden dabei radial um den Betrag verschoben, um
den das Objekt in diese Richtung verkleinert oder vergrössert wurde. Abbildung 1.3 illustriert
das grundlegende Vorgehen des Zoom-Algorithmus.
Abbildung 1.3: Vorgehen des Zoom-Algorithmus
3
Die Begriffe verfeinern und vergröbern wurden von [Ber02] eingeführt und werden deshalb auch in dieser
Arbeit weiterverwendet.
4
Unter Okklusionen sind Situationen zu verstehen, bei denen es zu Überlappungen zwischen zwei oder
mehreren Objekten kommt.
KAPITEL 1. EINFÜHRUNG
13
Das Verfeinern eines Objektes erfolgt dabei in drei sich rekursiv wiederholenden Schritten:
1. Die Grösse des Objekts, das verfeinert werden soll, wird bestimmt. Dabei muss genügend
Platz geschaffen werden, um alle im Objekt enthaltenen Elemente darzustellen.
2. Für jedes Objekt, das sich auf der selben Darstellungsebene befindet, wird ein Verschiebevektor berechnet und das Objekt damit verschoben. Ein Objekt befindet sich auf der
gleichen Darstellungsebene wie das verfeinerte Objekt, wenn beide Objekte das gleiche
Objekt als direkt übergeordnete Komposition haben.
3. Ist das verfeinerte Objekt selbst wieder in einer Komposition enthalten, so wird die
Grösse dieses übergeordneten Objekts angepasst. Dabei sind erneut die Schritte 1 bis 3
zu durchlaufen.
Anhand von Abbildung 1.3 auf Seite 12 lässt sich dieses Vorgehen nachvollziehen. Objekt A
soll verfeinert werden. Die dafür benötige Grösse wird in Schritt 1 berechnet und entspricht
dem mit A’ bezeichneten Rechteck. Die Objekte B, C und D, die sich auf der selben Darstellungseben wie A befinden, müssen nun in Schritt 2 verschoben werden. Dazu müssen als
Erstes die Verschiebevektoren berechnet werden. Dazu wird für Objekt B eine Gerade durch
die Mittelpunkte von A und B geführt. Der Verschiebevektor wird nun durch die Schnittpunk→
−
te dieser Linie mit den Rechtecken A und A’ definiert ( b für Objekt B in Abbildung 1.3). Die
−
→
→
Verschiebevektoren −
c und d für die Objekte C und D werden in analoger Weise berechnet.
Bei diesem einfachen Vorgehen kann es jedoch zu Okklusionen zwischen Objekten kommen,
weshalb im Algorithmus von Berner die Verschiebevektoren in leicht abgewandelter Form
berechnet werden. Das Vorgehen hierzu ist in Abbildung 1.4 veranschaulicht:
Abbildung 1.4: Berechnung der Verschiebevektoren gemäss Berner
KAPITEL 1. EINFÜHRUNG
14
Im Beispiel von Abbildung 1.4 wird wiederum Objekt A verfeinert, wodurch die Objekte B, C
und D verschoben werden müssen. Für die Berechnung der Verschiebevektoren wird zuerst die
Umgebung von A in der Ausgangssituation in vier Halbebenen unterteilt. In Abbildung 1.4
werden diese entsprechend ihrer geographischen Position mit N, S, W und O bezeichnet. Die
Verschiebevektoren werden nun abhängig davon berechnet, in welcher Halbebene sich der
Mittelpunkt des zu verschiebenden Objekts befindet. Um Okklusionen zu vermeiden wird
dabei für jede Halbebene eine Minimaldistanz berechnet. Für die vier Halbebenen sind diese
→
→
→
→
Minimaldistanzen in Abbildung 1.4 mit den Vektoren −
n, −
s,−
w und −
o dargestellt. Befindet
sich der Mittelpunkt des zu verschiebenden Objekts vor der Verschiebung in zwei Halbebenen,
so ist der Verschiebevektor durch die beiden Minimaldistanzen dieser Halbebenen definiert. In
Abbildung 1.4 befindet sich nur der Mittelpunkt des Objekts C in zwei Halbebenen, nämlich
→
N und O. Der Verschiebevektor −
c dieses Objektes entspricht nun dem Vektorprodukt von
−
→
−
→
n und o . Befindet sich der Mittelpunkt des zu verschiebenden Objektes jedoch in nur einer
Halbebene, so wird der Verschiebevektor - wie für Abbildung 1.3 auf Seite 12 beschrieben berechnet.
Weil die Verschiebevektoren je nach Lage des zu verschiebenden Objekts beim Algorithmus
von Berner unterschiedlich berechnet werden, erfüllt dieser das Kriterium der Invertierbarkeit5 nicht. Eine Layout-Operation wird in diesem Zusammenhang als invertierbar bezeichnet,
sofern sie die folgenden beiden Bedingungen erfüllt: (i) der Algorithmus, der die Operation ausführt, kann auch für die Umkehroperation benutzt werden und (ii) die Ausführung
der Operation und der Umkehroperation nacheinander führen wieder zum Ausgangszustand
zurück. Die erste Bedingung (i) stellt für den Zoom-Algorithmus kein Problem dar, da er
sowohl für die Verfeinerung als auch für die Vergröberung von Objekten eingesetzt werden
kann. Die zweite Bedingung (ii) kann jedoch nicht erfüllt werden, wenn das zu verschiebende Objekt durch eine Verfeinerung oder Vergröberung in eine andere Halbebene verschoben
wird. Abbildung 1.5 illustriert dieses Problem.
Abbildung 1.5: Fehlende Invertierbarkeit beim Zoom-Algorithmus
In Abbildung 1.5a wird Objekt A vergröbert, wodurch Objekt B verschoben werden muss.
Der Mittelpunkt von B befindet sich dabei nur in einer Halbebene, nämlich O, wodurch der
5
[Ber02] verwendet dafür in Analogie zu den Sortieralgorithmen den Begriff der Stabilität.
KAPITEL 1. EINFÜHRUNG
15
Verschiebevektor durch die Gerade durch die Mittelpunkte von B und A und deren Schnittpunkte mit den Rechtecken A und A’ definiert wird. Entspricht A nach der Vergröberung also
A’, so entspricht B nach der Vergröberung von A B’. Abbildung 1.5b zeigt die Umkehroperation dieser Vergröberung, die Verfeinerung von A. Der Mittelpunkt von B befindet sich nun in
zwei Halbebenen (N und O), wodurch sich der Verschiebevektor durch die Minimaldistanzen
dieser beiden Halbebenen berechnet. Nach der Verfeinerung von A entspricht B damit B’.
Die Anwendung der Vergröberung und deren Umkehroperation der Verfeinerung nacheinander führt in diesem Fall also nicht mehr zur Ausgangsituation zurück. Wäre der Algorithmus
invertierbar, so müsste das Objekt B’ in Abbildung 1.5b dem Objekt B in Abbildung 1.5a
entsprechen. Die Endsituation von Abbildung 1.5b mit A’ und B’ bleibt nun jedoch stabil,
d.h. B’ bleibt auch nach mehrmaligem Verfeinern und Vergröbern an seiner Position, weil sich
das Objekt B nun immer in der selben Halbebene befindet.
Zusätzlich können auch bei der Berechnung der Verschiebevektoren, wie sie Berner vorschlägt, Okklusionen auftreten [Mar02]. Da die Projektionstechnik okklusionsfrei arbeiten
muss (gemäss den Anforderungen auf Seite 103 in [Ber02]), müssen entstandene Okklusionen nachträglich erkannt und aufgelöst werden. Durch diese nachträglichen Eingriffe in das
Layout verschärft sich aber das Problem der fehlenden Invertierbarkeit weiter, da der ZoomAlgorithmus nur auf das aktuelle Layout andewandt wird und Layoutveränderungen (d.h. Positionsändeurngen von Objekten), wie sie bei der Auflösung von Okklusionen entstehen, nicht
mehr rückgängig machen kann.
Die Invertierbarkeit ist aber nicht das einzige Kriterium zur Beurteilung der Qualität von
Zoom- bzw. Verschiebealgorithmen. Neben der beschriebenen Invertierbarkeit enthält die
Aufzählung von Marty [Mar02] z.B. auch noch die Raumeinteilung, die angibt, wie viel Freiraum der Algorithmus schafft und wie gut der bestehende Freiraum zur Verteilung der Objekte
genutzt wird, oder den Grad der Automatisierung, d.h. die Anzahl der Schritte von Seiten
des Benutzers gegenüber der Anzahl von Schritten, die vom Algorithmus übernommen wird.
Die ausführliche Behandlung der fehlenden Inverterierbarkeit des Zoom-Algorithmus in dieser
Einführung rührt daher, dass diese für die Linienführung eines der Hauptprobleme darstellt.
Marty untersucht anhand dieser Kriterien auch noch Alternativen zum Algorithmus von Berner, die auch auf dem Grundgedanken der radialen Verschiebung beruhen, kommt dabei aber
zur Erkenntnis, dass keiner der Ansätze (inkl. dem von Berner) eine rundum zufriedenstellende Lösung ermöglicht. Die vorliegende Arbeit nimmt im Folgenden den von Marty erweiterte
Algorithmus von Berner zur Grundlage und behandelt deshalb auch die damit auftretenden Probleme. Grundätzlich wird die Linienführung jedoch unabhängig von einer speziellen
Layout-Operation (wie z.B. dem Zoom-Algorithmus) behandelt.
Kapitel 2
Problemstellung
Bei der Visualisierung von Adora-Modellen werden, wie im verhergehenden Kapitel erläutert,
Linien zur Repräsentation von Beziehungen zwischen Objekten oder Objektmengen (Assoziationen), Zustandsübergängen (Transitionen), hierarchischen Beziehungen zwischen Szenarien
und Beziehungen zwischen externen Akteuren und dem System verwendet. Vor allem bei
komplexeren Modellen ist es dabei in der Regel unvermeidlich, dass es zu Überschneidungen
zwischen Linien und Knoten1 kommt. Auch Überlappungen von Linienbeschriftungen oder
Überschneidungen von verschiedenen Linien treten mit zunehmender Komplexität der Modelle vermehrt auf. Solche Überschneidungen und Überlappungen beeinträchtigen die Lesbarkeit
eines Modelles und sollten deshalb möglichst vermieden werden.
Das Problem verschärft sich zusätzlich durch das dynamische Layout von Adora-Modellen,
bei dem verschiedene Darstellungen aus dem integrierten Gesamtmodell generiert werden. Bei
der Anwendung von Layout-Operationen, wie z.B. dem Zoom-Algorithmus, verändert sich
das Layout (d.h. die Positionen und Grössen der Knoten) nicht unerheblich, wodurch neue
Überschneidunge entstehen können. Auch wenn die Knoten bei der Erstellung des Modells
sorgfältig so platziert werden, dass es zu möglichst wenigen Überschneidungen kommt, können
z.B. beim Zoomen durch die Veränderungen der Positionen und Grössen der Knoten trotzdem
Überschneidungen auftreten.
Die folgenden Abschnitte beschreiben ausführlich das Problem der Linienführung im Allgemeinen und bei Adora-Modellen im Besonderen, um daraus die Anforderungen an einen
Ansatz zur Linienführung in Adora-Modellen herzuleiten.
2.1
Linienführung mit Hindernissen
Die Platzierung und Wahl der Grösse der verschiedenen Knoten wird bei Adora-Modellen
durch den Benutzer vorgenommen. Mit der Wahl der Positionen und Grössen der Knoten
legt der Benutzer zusätzliche Informationen über das zu modellierende System im Layout des
Modells ab. Diese im Layout des Modells enthaltenen Informationen werden als Sekundärno1
Im Folgenden werden die graphischen Symbole aller Sprachkonstrukte, die bei der Linienführung als Hindernisse auftauchen können, in Anlehnung an die Graphentheorie unter dem Begriff Knoten zusammengefasst.
Darunter fallen abstrakte Objekte und Objektmengen, elementare und komplexe Zustände, Szenarien und
externe Akteure.
16
KAPITEL 2. PROBLEMSTELLUNG
17
tation [Pet95] bezeichnet. Das vom Benutzer erstellte Layout und damit die Sekundärnotation
müssen möglichst erhalten bleiben. Dies gilt für alle Operationen, die Veränderungen an der
graphischen Repräsentation des Modells vornehmen, d.h. sowohl für den Zoom-Algorithmus
als auch für den Linienführungsalgorithmus. Im Gegensatz zum Zoom-Algorithmus, dessen
Zweck in der Veränderung des Layouts liegt und der das bestehende Layout immer nur bis
zu einem gewissen Grad erhalten kann, sollte der Linienführungsalgorithmus die Position und
Grösse der Knoten nicht verändern und die Platzierung und Grösse der Knoten als gegeben
und unveränderbar betrachten. Zur Vermeidung von Überschneidungen zwischen Linien und
Knoten bleibt deshalb nur die Möglichkeit, die Linien explizit um die Hindernisse herumzuführen.
Obwohl die verschiedenen in Abschnitt 1.3.2 beschriebenen Sprachkonstrukte, die als Hindernisse für die Linienführung in Frage kommen, durch unterschiedliche graphische Symbole
repräsentiert werden, beschränkt sich die folgende Diskussion auf rechteckige Hindernisse, da
sich, wie Abbildung 2.1 zeigt, alle graphischen Symbole durch ein Rechteck annähern lassen.
Abbildung 2.1: Hindernisse bei der Linienführung
In den folgenden Abschnitten wird auf verschiedene grundlegende Ansätze zur Führung von
Linien und die dabei anwendbaren Strategien zur Vermeidung von Überschneidungen zwischen
Linien und Knoten eingegangen. Dabei wird das Probleme der Überschneidungen von Linien untereinander und der Überlappungen von Linienbeschriftungen vorerst nicht behandelt.
Dabei beziehen sich die Ausführungen auf ein statisches Layout, d.h. das Problem der Überschneidungen tritt nur beim Hinzufügen oder Verschieben von Linien oder Knoten auf. Das
Problem tritt somit in der gleichen Form z.B. auch bei UML-Diagrammen auf. Das durch den
Zoom-Algorithmus (oder andere Layout-Operationen) entstehende dynamische Layout wird
in Abschnitt 2.2 behandelt.
2.1.1
Direkte Linien
Der einfachste Ansatz der Linienführung besteht in der direkten Verbindung des Start- und
Endpunktes durch ein gerade Linie. Die Linie entspricht damit immer dem direkten und damit kürzesten Weg. Da die beiden Knoten auf direktem Weg miteinander verbunden sind,
lässt sich die Verbindung leicht erkennen, ohne die Linie lange suchen zu müssen. Der direkte Ansatz kommt vor allem bei Darstellungen von Sachverhalten, bei denen es auf Grund
ihrer Struktur zu gar keinen oder nur sehr wenigen Überschneidungen von Knoten und Linien kommen kann. Beispiele dazu sind Stammbäume oder Bäume als Datenstrukturen in
der Informatik. Ebenfalls weite Verbreitung geniesst die direkte Linienführung im Bereich
der Visualisierung von Graphen. Bei Graphen haben die Knoten jedoch normalerweise keine
oder eine vernachlässigbare Ausdehnung, wodurch Überschneidungen mit Linien2 selten auftreten. Im Gegensatz dazu haben die Knoten in einem Adora-Modell immer eine gewisse
2
Bei Graphen wird für die Linien in der Regel der Begriff Kante verwendet.
KAPITEL 2. PROBLEMSTELLUNG
18
Grösse und die Modelle weisen normalerweise auch keine Struktur auf, die Überschneidungen
verunmöglicht oder nur selten auftreten lässt. Abbildung 2.2 veranschaulicht die direkte Linienführung und eine dabei auftretende Überschneidung zwischen einer Linie und dem Knoten
A.
Abbildung 2.2: Direkte Linienführung
Die Überschneidung in Abbildung 2.2 lässt sich durch das Einfügen eines Hilfspunktes in die
Linie auflösen. Dadurch wird die Linie in zwei Segmente aufgeteilt und um Knoten A herumgeführt. Obwohl diese Linie jetzt nicht mehr direkt vom Start- zum Endpunkt führt, sondern
den Umweg über einen Hilfspunkt nimmt, wird im Folgenden für diesen Ansatz weiterhin der
Begriff der direkten Linienführung verwendet. Oftmals reicht jedoch ein einzelner Hilfspunkt
nicht aus, um eine Linie um ein Hindernis herumzuführen. Liegen die Knoten ungünstig, wie
z.B. in der Konstellation von Abbildung 2.3, sind zwei Hilfspunkte nötig, um das Hindernis
zu umfahren, da nach dem Einfügen des ersten Hilfspunktes eines der beiden enstandenen
Segmente wiederum durch Knoten B hindurchführt.
Abbildung 2.3: Einfügen mehrer Hilfspunkte
Je grösser das im Weg stehende Hindernis ist, desto eher sind zwei Hilfspunkte nötig um eine
Linie darum herum zu führen. Da abstrakte Objekte und Objektmengen in Adora-Modellen
aufgrund der Kompositionsabstraktion weiterer Knoten enthalten können, haben sie oftmals
eine grosse Ausdehnung. Werden zwei Hilfspunkte benötigt, um eine Linie um ein Hindernis
herumzuführen, so verläuft diese Linie, wie Abbildung 2.3 illustriert, in einem gewissen Bereich
parallel zum Rand des Hindernisses. Damit geht ein grosser Vorteil der direkten Linienführung
verloren, dass nämlich Linien leicht von Knoten zu unterscheiden sind, da sie, im Gegensatz
zu den Rändern der Knoten, weder horizontal noch vertikal verlaufen.
KAPITEL 2. PROBLEMSTELLUNG
2.1.2
19
Orthogonale Linien
Bei der orthogonalen oder rechtwinkligen Linienführung besteht eine Linie nur aus horizontalen und vertikalen Segmenten. Der Begriff orthogonal bezieht sich dabei auf die einzelnen
Segmente einer Linie, die immer orthogonal d.h. rechtwinklig aufeinandertreffen. Dieser Ansatz der Linienführung kommt z.B. bei Gegenstands-Beziehungs-Modellen im Bereich der
Datenbanken oder oft auch bei UML-Klassenmodellen zum Einsatz.
Eine orthogonal geführte Linie enthält, ausser wenn eine direkte horizontale oder vertikale
Verbindung zwischen dem Start- und Endpunkt möglich ist, auch dann Hilfspunkte, wenn
sie nicht um ein Hindernis herumführt. Die Linien werden dadurch länger und verbinden
die beteiligten Knoten nicht mehr auf dem direkten Weg. Da die Linien jedoch nur aus
horizontalen und vertikalen Segmenten bestehen, fügen sie sich nahtlos in Modelle, die in erster
Linie aus rechteckigen Knoten bestehen, ein. Beispiele solcher Modelle sind die GegenstandsBeziehungs-Modelle, UML-Klassenmodelle und auch Adora-Modelle. Dies hat jedoch auch
den Nachteil, dass es schwieriger wird, Linien von den Rändern der Knoten zu unterscheiden,
vor allem wenn jeweils nur Teile der Linien oder Knoten sichtbar sind. Abbildung 2.4 zeigt
das Beispiel aus Abbildung 2.2 mit orthogonal geführten Linien.
Abbildung 2.4: Orthogonale Linienführung
Überschneidungen von orthogonalen Linien mit Knoten können - wie in Abbildung 2.4 angedeutet - ebenfalls durch das Einfügen von Hilfspunkten oder aber durch das Verschieben
von einzelnen oder mehreren Segmenten aufgelöst werden. Da eine orthogonal geführte Linie
normalerweise bedeutend mehr Hilfspunkte enthält als eine direkte Linienführung, ist es oftmals möglich, die Linie ohne das Einfügen zusätzlicher Hilfspunkte nur durch das Verschieben
bereits bestehender Hilfspunkte um das Hindernis herumzuführen.
2.1.3
Weitere Ansätze
Zur Linienführung sind beliebige weitere Ansätze denkbar. So schlägt Berner [Ber02] den
Einsatz von Splines vor, um die Linien als Kurven um Hindernisse herumzuführen. Eine solche Linienführung hat den Vorteil, dass sich die Linien stark von den rechteckigen Knoten
abheben. Eine solche Linienführung hat wie die direkte Linienführung die Tendenz, dass sich
Linien, die um mehrere grössere Hindernisse herumgeführt werden müssen, immer stärker der
rechteckigen Form der Hindernisse angleichen und damit einer orthogonalen Linienführung
immer ähnlicher werden. Die verschiedenen Ansätze können auch kombiniert werden. Abbil-
KAPITEL 2. PROBLEMSTELLUNG
20
dung 2.5 illustriert drei weitere Möglichkeiten, um die Linie zur Verbindung der Knoten A und
D zwischen den Knoten B und C hindurchzuführen. In Abbildung 2.5a wird die Linie durch
den Einsatz von Splines geführt, Abbildung 2.5b und Abbildung 2.5c sind Kombinationen der
verschiedenen Ansätze. Von all diesen Ansätzen geniessen der direkte und orthogonale Ansatz
die weiteste Verbreitung.
Abbildung 2.5: Weitere Ansätze zur Linienführung
2.1.4
Beurteilungskriterien
Die Beurteilung der Qualität einer bestimmten Art der Linienführung erfolgt meistens anhand von bestimmten ästhetischen Kriterien wie z.B. der Anzahl der Linienschnittpunkte
oder der durchschnittlichen Länge der Linien. Oftmals geben jedoch auch einfach persönliche
Präferenzen den Ausschlag, die Linien z.B. direkt oder orthogonal zu führen. Daneben haben
sich für bestimmte Bereiche auch bestimmte Stile der Linienführung durchgesetzt. So werden
z.B. beim Zeichnen von Gegenstands-Beziehungs-Modellen die Linien in der Regel orthogonal
geführt.
Welchen Einfluss die Art der Linienführung auf die Lesbarkeit und Verständlichkeit von graphischen Modellen hat, ist kaum untersucht. Nur gerade im Bereich des Graphenlayouts wurde
versucht anhand von Experimenten [Pur98] herauszufinden, welchen Faktoren die Lesbarkeit
und Verständlichkeit eines Graphen positiv oder negativ beeinflussen. Dabei mussten die
Probanden bestimmte Fragen zu den Graphen beantworten (z.B. wie lange der kürzeste Weg
zwischen zwei Knoten ist). Die Anzahl der korrekten Antworten und die Zeit, die zur Beantwortung einer Frage benötigt wurde, wurden danach ausgewertet. Dabei zeigte sich, dass eine
hohe Anzahl von Linienüberschneidungen und von Hilfspunkten in einer Linie die Lesbarkeit
negativ beeinflussen. Eine direkte Übertragung dieser Resultate auf die Linienführung in einem Adora-Modell is aber kaum möglich, da sich diese stark von Graphen unterscheiden.
So haben die Knoten bei einem Adora-Modell im Gegensatz zu den Graphen eine nicht vernachlässigbare Ausdehnung und die Position und Grösse der Knoten können - im Gegensatz
zu den Graphenlayoutern - zur Optimierung der Linienführung nicht verändert werden.
2.1.5
Linienführung in Adora-Modellen
Die Frage, welche Art der Linienführung für Adora-Modelle am geeignetsten ist, lässt sich
nur schwer beantworten. Zum einen spielen dabei wiederum persönliche Präferenzen eine wichtige Rolle. Zum anderen können Linien, die unterschiedliche Beziehungen repräsentieren auch
KAPITEL 2. PROBLEMSTELLUNG
21
unterschiedlich geführt werden. Als Beispiel hierzu soll das Scenariochart [Xia04] (vgl. dazu
Abschnitt 1.3.2) aus Abbildung 2.6 dienen. Ein Scenariochart bildet eine Baumstruktur; die
Linien zwischen den Szenarien repräsentieren also hierarchische Beziehungen. Baumstrukturen werden in der Regel mit einer direkten Linienführung visualisiert, wie dies auch für Abbildung 2.6a der Fall ist. Werden die Linien wie in Abbildung 2.6b orthogonal geführt, so ist für
den erfahrenen Benutzer nicht sofort ersichtlich, dass es sich dabei um eine Baumstruktur handelt. Für Assoziationen zwischen abstrakten Objekten oder Objektmengen kann jedoch eine
orthogonale Linienführung besser geeignet sein, da sich eine orthogonale Linienführung, wie
in Abschnitt 2.1.2 beschrieben, für Layouts mit primär rechteckigen Hindernissen besonders
eignet. Zusätzlich können die verschiedenen Beziehungen in der Visualisierung auch leichter
voneinander unterschieden werden, wenn die Linien, die sie repräsentieren, unterschiedlich
geführt werden.
Abbildung 2.6: Linienführung in einem Scenariochart
Ästhetische Kriterien für die Linienführung in Adora-Modellen lassen sich aus den Kriterien,
die für das Zeichnen von Graphen (vgl. dazu Abschnitt 3.1) entwickelt wurden, ableiten. Das
Kriterium, dass es zu keinen Überschneidungen zwischen Knoten und Linien kommen darf,
ist eine grundlegende Anforderung an den Ansatz zur Linienführung und taucht deshalb in
der folgenden Aufzählung nicht auf.
• Möglichst kurze Linien. Wird eine Linie nicht direkt von Start- zum Endpunkt
geführt, sondern über Umwege, so wird es für den Betrachter schwieriger herauszufinden,
welchen Knoten durch eine Linie miteinander verbunden sind. Folgt die Linie, dem Weg,
den das Auge beim Wechsel des Fokus von einem Knoten zu einem anderen nimmt, so
lässt sich die Verbindung dieser beiden Knoten sofort erkennen.
• Minimierung der Anzahl Hilfspunkte. Mit zunehmender Anzahl von Hilfspunkten
steigt auch der Aufwand, der nötig ist, um einer Linie zu folgen.
• Vermeidung von Linienüberlappungen und -überschneidungen. Kommt es zu
KAPITEL 2. PROBLEMSTELLUNG
22
Überlappungen oder Überschneidungen3 von Linien, so muss der Betracher die beiden
Linien zuerst voneinder trennen, um ihnen folgen zu können.
Diese Kriterien stehen jedoch in vielen Fällen in Konflikt zueinander. So kann es z.B. nötig
werden eine Linie zu verlegen, um Überschneidungen mit anderen Linien zu verhindern.
Dadurch entspricht die Linie unter Umständen aber nicht mehr der kürzest möglichen
Linie.
2.2
Dynamisches Layout
Zusätzlich zum Problem der Linienführung mit Hindernissen muss der Linienführungsalgorithmus in einem Adora-Modell auch auf Veränderungen am Layout, wie sie z.B. durch
den Zoom-Algorithmus hervorgerufen werden, entsprechend reagieren. Durch das Zoomen
verändern sich die Grössen und Positionen der Knoten und sichtbare Linien können verschwinden und neue Linien können sichtbar werden. Durch die Verschiebung und Änderung
der Grösse von Knoten können Überschneidungen mit Linien verschwinden oder neue hinzukommen. Das dynamische Layout von Adora-Modellen kommt jedoch nicht nur durch den
Zoom-Algorithmus zu Stande, sondern z.B. auch durch das Ein- und Ausblenden von verschiedenen Aspekten. Die Visualisierung von Adora-Modellen unterscheidet sich z.B. von
UML-Klassendiagrammen darin, dass verschiedene Darstellungen - je nach Abstraktionsebene und eingeblendeter Aspekte - dynamisch aus dem integrierten Gesamtmodell generiert
werden.
2.2.1
Mental Map des Benutzers
Bei der Arbeit mit graphischen Repräsentationen entwickelt der Benutzer eine sogenannten
Mental Map [Ead91], [Ead95] der Darstellung. Diese Mental Map ermöglicht es ihm, sich
vor allem in grossen und komplexen Darstellungen schnell und ohne grosse Mühe zurecht zu
finden. So muss der Benutzer nach kurzer Zeit z.B. nicht mehr das gesamte Adora-Modell
durchsuchen um einen bestimmten Knoten zu finden, sondern er sucht diese instiktiv an der
richtigen Stelle. Die Mental Map beschränkt sich jedoch nicht nur auf graphische Modelle,
sondern ist für alle Bereiche, die eine Orientierung erfordern, von Bedeutung. Werden die
Erwartungen, die aus der Mental Map resultieren (z.B. der Ort an dem sich ein Knoten
befinden sollte), nicht erfüllt, so findet sich der Benutzer im Modell kaum mehr zurecht und
muss sich wieder eine neue Mental Map aufbauen.
Automatische Eingriffe in die graphische Darstellung von Modellen sollten deshalb dafür
sorgen, dass die Darstellung auch nach ihrer Anwendung noch möglichst mit der Mental
Map des Benutzers übereinstimmt. Im Falle von Adora-Modellen betrifft dies in erster Linie
den Zoom- und Linienführungsalgorithmus. Der Zoom-Algorithmus hat sich dabei um die
Wahrung der relativen Position von Knoten gegenüber benachbarten Knoten zu bemühen.
Durch das in Abschnitt 1.4 beschriebene Vorgehen wird versucht dieser Forderung so gut als
möglich gerecht zu werden. Der Linienführungsalgorithmus muss versuchen, die Linien bei
einer Veränderung des Layouts durch den Zoom-Algorithmus so anzupassen, dass sie weiter
3
Unter Überschneidung ist dabei die Kreuzung von zwei Linien zu verstehen. Bei einer Überlappung kommen
die Linien in einem bestimmten Bereich aufeinander zu liegen.
KAPITEL 2. PROBLEMSTELLUNG
23
mit der Mental Map des Benutzers übereinstimmen. Abbildung 2.7 zeigt ein einfaches AdoraModell vor und nach der Vergröberung von Knoten B. Der Zoom-Algorithmus platziert die
Knoten A und C so, dass die Darstellung weiterhin der Mental Map des Benutzers entspricht.
Innerhalb dieses angepassten Layouts muss der Linienführungsalgorithmus nun dafür sorgen,
dass sich die Darstellung der Verbindung der Knoten A und C nur soweit verändert, dass eine
schnelle Wiedererkennug ermöglicht wird.
Abbildung 2.7: Veränderung des Layouts durch den Zoom-Algorithmus
Wie bereits in Abschnitt 1.4 beschrieben, verändert der Zoom-Algorithmus in gewissen Situationen das Layout so stark, dass die Darstellung nur noch teilweise mit der Mental Map des
Benutzers übereinstimmt. Im Weiteren ist der Algorithmus auch nicht stabil, d.h. die Umkehrung eines Zoom-Schrittes führt in vielen Fällen nicht mehr zum Ausgangslayout zurück.
Da der Linienführungsalgorithmus auf das vom Zoom-Algorithmus veränderte Layout aufsetzen muss, kann er die Mental Map der Linien nur in dem Umfang erhalten, in dem der
Zoom-Algorithmus die Mental Map bei der Positionierung der Knoten bewahrt. Zerstört also
der Zoom-Algorithmus (oder eine andere Layout-Operation) die Mental Map des Layouts,
so kann der Linienführungsalgorithmus normalerweise auch die Mental Map der Linien nicht
mehr erhalten.
2.2.2
Mental Map einer Linie
Gewisse Autoren (wie z.B. [Nor96]) argumentieren, dass für die Mental Map einer Darstellung
nur die Positionen und Grössen der Knoten eine Rolle spielen. Bei Knoten erinnert sich der
Benutzer an deren Position, Linien sind jedoch nur von Bedeutung, um Verbindungen “on the
fly” zu erkennen und haben damit keinen Einfluss auf die Mental Map. Dieser Ansatz wird
jedoch in dieser Arbeit nicht weiterverfolgt, da er auch keine Sekundärnotation ermöglicht.
Für die Wiedererkennung einer Linie und damit mit der grössten Bedeutung fü die Erhaltung
die Mental Map des Benutzers kommen verschiedene Eigenschaften einer Linie in Frage. Es
sind dies unter anderem der Start- und Endpunkt auf dem Rand der beteiligten Knoten, die
Anzahl der Hilfspunkte in der Linie oder dem Umstand, auf welcher Seite die Linie um ein
bestimmtes Hindernis herumführt. Die Mental Map einer Linie ist dabei in hohem Masse
von den Knoten, zwischen denen die Linie hindurchführt, anhängig. So bleibt die Mental
Map der Linie in Abbildung 2.7 in erster Linie dadurch erhalten, dass die relative Position
des vertikalen Liniensegments gegenüber den Knoten A und B gleich bleibt. Normalerweise
ist es jedoch aus folgenden Gründen nicht möglich, alle diese Eigenschaften auch nach der
KAPITEL 2. PROBLEMSTELLUNG
24
Veränderung des Layouts durch den Zoom-Algorithmus beizubehalten. Erstens kann sich das
Layout so stark verändern, dass es mit der Erhaltung gewisser Eigenschaften zu einer unsinnigen Linienführung kommt. Und zweitens stehen gewisse Eigenschaften, wie Abbildung 2.8
veranschaulicht, in Konflikt zueinander. So ändert sich zwar bei der Lösung b) die Anzahl
der Hilfspunkte in der Linie nicht, der Startpunkt auf der Startknoten befindet sich nach dem
Zoom-Schritt jedoch nicht mehr auf dem linken, sondern auf dem oberen Rand. Lösung c)
bewahrt zwar den Startpunkt verändert jedoch die Anzahl der Hilfspunkte.
Abbildung 2.8: Konflikt bei der Erhaltung der Mental Map einer Linie
Eine grosse Bedeutung bei der Erhaltung der Mental Map spielt die Invertierbarkeit (vgl. dazu Abschnitt 1.4) von Operationen, die Veränderungen am Layout vornehmen. Für den Linienführungsalgorithmus bedeutet dies, dass eine Linie nach einer auf eine Vergröberung folgende Verfeinerung eines Knotens wieder gleich aussehen sollte, wie vor der Vergröberung des
Knotens. Der Linienführungsalgorithmus kann diese Invertierbarkeit jedoch nur garantieren,
sofern auch der Zoom-Algorithmus dies tut. Dies ist, wie in Abschnitt 1.4 besprochen, nicht
immer der Fall.
2.3
Sekundärnotation
Neben der Primärnotation, durch die Symbole für die Repräsentation der verschiedenen
Sprachkonstrukte definiert sind, ist für eine gute Verständlichkeit graphischer Repräsentationen die sogennante Sekundärnotation [Pet95] von grosser Bedeutung. Die Sekundärnotation
umfasst das Layout der Darstellung, d.h. die Positionen und Grössen der Elemente bzw. Knoten. Bestimmte Strukturen und Beziehungen eines Modells werden erst durch die Position und
Grösse der Elemente offensichtlicht. Zusätzlich lassen sich durch das Layouts für erfahrene
Benutzer leicht bestimmte Muster im Modell erkennen.
Bei Adora-Modellen wird die Sekundärnotation durch den Benutzer bei der Erstellung des
Modells oder bei nachträglichen manuellen Änderungen definiert. Unter dem Begriff der Sekundärnotation werden deshalb bei Adora-Modellen die vom Benutzer manuell an der Darstellung vergenommenen Änderungen zusammengefasst. Die in Abschnitt 2.2.1 beschriebene
Mental Map entspricht damit dem Layout, wie es durch den Benutzer mit Hilfe der Sekundärnotation definiert wird. Die Erhaltung der Mental Map wäre zwar auch ohne Einbezug
der Sekundärnotation möglich, indem gar keine Änderungen durch den Benutzer zugelassen
oder diese einfach ignoriert würden, wie dies z.B. bei automatischen Graphenlayoutern der
Fall ist. Das Umgekehrte ist jedoch nicht der Fall, d.h. eine Sekundärnotation macht nur Sinn,
wenn dadurch die Mental Map definiert wird und diese auch bei automatischen Änderungen
KAPITEL 2. PROBLEMSTELLUNG
25
am Layout so weit wie möglich erhalten bleibt.
2.3.1
Sekundärnotation der Linienführung
Im Bereich des Layouts wird die Sekundärnotation durch die Position und Grösse der Knoten
definiert, da dies die Eigenschaften sind, die der Benutzer verändern kann. Bei der Linienführung sind die Linieneigenschaften, die die Sekundärnotation ausmachen, weniger offensichtlich. Bei allen Ansätzen kommt die Position der Start- und Endpunkte auf den Rändern
der beteiligte Knoten als durch den Benutzer veränderbare Eigenschaft (und damit als Teil
der Sekundärnotation) in Frage. Wie Abbildung 2.9 zeigt, hat der Benutzer bei der orthogonalen Linienführung bereits mit der Wahl der Start- und Endpunkte einen starken Einfluss
darauf, wie die Linie zwischen den Knoten A und B geführt wird. So sind durch die Wahl von
Start- und Endpunkt der Linien vier verschieden Linien möglich.
Abbildung 2.9: Einfluss der Start- und Endpunkte auf die orthogonale Linienführung
Ebenfalls als Teil der Sekundärnotation kommt die Position von Hilfspunkten in den Linien in Frage. Bei der orthogonalen Linienführung ist es dabei jedoch nicht möglich, nur einen
einzelnen Punkt zu verschieben, da sonst die Linie nicht mehr nur aus horizontalen oder vertikalen Segmenten besteht. Es ist deshalb nur möglich ein Liniensegment und damit gleichzeitig
zwei Punkte zu verschieben. Abbildung 2.10 veranschaulicht das Verändern der Position von
Hilfspunkten sowohl bei der direkten als auch bei der orthogonalen Linienführung.
Abbildung 2.10: Einflussnahme bei der direkten und orthogonalen Linienführung
KAPITEL 2. PROBLEMSTELLUNG
26
Den grösstmöglichen Einfluss auf die Linienführung hätte der Benutzer dadurch, dass er beliebige Punkte auswählen könnte, durch welche die entsprechende Linie dann z.B. orthogonal
hindurchgeführt wird. Ein solch starker Einbezug des Benutzers bringt jedoch zwei grundlegende Probleme mit sich. Erstens ist eine gewisse Automatisierung unerlässlich, da sich der
Benutzer sonst kaum mehr um seine eigentliche Aufgabe, nämlich der Erstellung oder Bearbeitung eines Modells kümmern kann, da er zu stark mit Fragen des Layouts beschäftigt ist.
Und zweitens ist eine solche vom Benutzer frei gewälte Linienführung nach der Anwendung
des Zoom-Algorithmus (oder einer anderen Layout-Operation) oftmals nicht mehr sinnvoll,
da sich das Layout zu stark verändert.
2.3.2
Änderungen am Layout
Änderungen am Layout eines Adora-Modells können auf zwei verschiedene Arten auftreten:
durch eine Layout-Operation wie z.B. den Zoom-Algorithmus oder manuell durch den Benutzer. Im ersten Fall ist die Erhaltung der Sekundärnotation (und damit der Mental Map) in
jedem Fall in so hohem Masse wie möglich zu gewährleisten. Aber auch bei manuellen Änderungen durch den Benutzer kann die Erhaltung der Sekundärnotation Sinn machen. Und
dies, obwohl eine solche Änderungen selbst die Sekundärnotation verändert. Abbildung 2.11
veranschaulicht eine solche Situation: Obwohl Knoten C und damit der Startpunkt der Linie verschoben wird, bleibt die Sekundärnotation der Linie erhalten, indem der Abstand des
horizontalen Segments gegenüber Knoten A gleich bleibt.
Abbildung 2.11: Erhaltung der Sekundärnotation bei manuellen Änderungen
2.4
Anforderungen an einen Linienführungsalgorithmus
Zusammenfassend stellen sich an einen Linienführungsalgorithmus für Adora-Modelle folgende Anforderungen:
1. Der Linienführungsalgorithmus muss in der Lage sein, Linien in einem statischen Layout
um Hindernisse herumzuführen ohne dabei das Layout (d.h. die Positionen und Grössen
der Knoten) zu verändern. Darunter fällt auch die Verhinderung von Überschneidungen
von Linien.
KAPITEL 2. PROBLEMSTELLUNG
27
2. Bestehende Linien müssen bei der Anwendung des Zoom-Algorithmus (oder anderen
Layout-Operationen) angepasst werden, ohne dass dabei neue Überschneidungen oder
Überlappungen auftreten. Der für diese Anpassung verantwortliche Algorithmus muss
dabei eine Laufzeit aufweisen, die eine interaktive Nutzung ermöglicht. Die vom ZoomAlgorithmus vorgenommenen Veränderungen am Layout verunmöglichen jedoch in vielen Fällen eine Anpassung der Linie, wodurch die Linie komplett neu geführt werden
muss.
3. Die Sekundärnoation, d.h. manuelle Änderungen an den Linien, müssen bei diesen Anpassungen - so weit wie möglich - erhalten bleiben.
Kapitel 3
Bestehende Ansätze der
Linienführung
Die Aufgabe, Linien zur Verbindung von zwei Punkten zwischen Hindernissen hindurchzuführen, stellt sich in verschiedenen Bereichen. Einer davon ist die graphische Darstellung
von Informationen, z.B. Objekten und Beziehungen zwischen diesen Objekten. Da Graphen
genau solche Beziehungen zwischen Objekten beschreiben, werden diese durch das Zeichnen
von Graphen visualisiert. Die Objekte werden dabei als Knoten und die Beziehungen als Kanten bezeichnet. In einem Graph können dabei die verschiedensten Beziehungen repräsentiert
werden, z.B. Verwandschaftsbeziehungen in einem Stammbaum oder Verkehrsverbindungen
in Netzplänen von Verkehrsbetrieben. Auch die verschiedenen Beziehungen in einem AdoraModell können durch einen Graphen beschrieben werden. Aus Grüden der Übersichtlichkeit
ist beim Zeichnen von Graphen darauf zu achten, dass es zu möglichst wenigen Überschneidungen zwischen Knoten und Kanten und Kanten untereinander kommt [Pur98]. Damit weist
das Zeichnen von Graphen grosse Ähnlichkeiten zur Linienführung in Adora-Modellen auf.
Eine etwas andere Aufgabe hat die Linienführung im Bereich des Schaltungsentwurfs. Dabei
repräsentieren die Linien nicht bloss Beziehungen, sondern stellen physische Verbindungen
zwischen den verschiedenen Elementen dar. Dadurch stellen sich auch andere Anforderungen
an einen Algorithmus, der diese elektrischen Leitungen durch das Layout hindurchführt. So
müssen z.B. Überschneidungen von Leitungen untereinander in jedem Fall verhindert werden,
da damit die Platine oder Schaltung zerstört werden würde. Im Gegensatz zum Graphenlayout
sind die Positionen und Grössen der Schaltungselemente in der Regel fest vorgegeben und
können bei der Linienführung nicht verändert werden.
Die in diesem Kapitel vorgestellten Ansätze zur Linienführung gehen von einem statischen
Layout1 aus, d.h. das Layout ändert sich nur, wenn der Benutzer Veränderungen daran vornimmt. Ein dynamisches Layout, wie es bei den Adora-Modellen z.B. durch den ZoomAlgorithmus entsteht, ist bei diesen Ansätzen nicht vorgesehen. Auf mögliche Strategien zur
Linienführung in einem dynamischen Layout geht Kapitel 4 ein.
1
Das Layout umfasst dabei nur die Elemente, die bei der Linienführung Hindernisse darstellen, nicht jedoch
die Linien selbst. In einem Graph wird das Layout damit durch die Position und Grössen der Knoten definiert;
beim Schaltungsentwurf durch die Positionen und Grössen der Schaltungselemente.
28
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
3.1
29
Automatisches Layouten von Graphen
Anschaulich bestehen Graphen2 aus eine Menge von Punkten, die durch Linien miteinander verbunden sind, wobei die Linien Beziehungen zwischen den Punkten repräsentieren. Die
Punkte werden dabei als Knoten, die Linien als Kanten bezeichnet. Die Anwendungsmöglichkeiten von Graphen sind sehr vielfältig. So werden z.B. beim Entwurf von Datenbanken als
Gegenstands-Beziehungs-Modellen oder zur Beschreibung sozialer Netzwerke Graphen eingesetzt. Dementsprechend hat sich die Visualisierung von Graphen als Untergebiet der Informatik und der Mathematik etabliert.
Beim automatischen Layouten von Graphen wird das Layout (d.h. die Positionierung der
Knoten) in erster Linie durch die Beziehungen zwischen den Knoten (und damit den Kanten)
bestimmt. Die Knoten werden so platziert, dass es zu keinen oder möglichst wenig Überschneidungen zwischen Knoten und Kanten kommt. Im Gegensatz dazu wird das Layout von
Adora-Modellen durch den Benutzer bestimmt und die Linienführung muss nachträglich
auf diesem vorgegebenen Layout operieren. Daneben wird ein Adora-Modell inkrementell
erstellt, d.h. die Knoten und Linien werden nach und nach dem Modell hinzugefügt. Damit
ein automatischer Graphenlayouter das Layout eines Graphen berechnen kann, müssen alle
Knoten und Kanten bekannt sein, d.h. der Erstellung des Graph muss vor der Anwendung
des Layouters abgeschlossen sein.
Um das Layout eines Graphen automatisch (d.h. durch einen Algorithmus) festzulegen, werden Kriterien benötigt, um die Qualität eines Layouts zu beurteilen. Je nach Anwendungsbereich unterscheiden sich auch diese Kriterien, da beim Layout eines Graphen nicht nur dessen
strukturelle Eigenschaften, sondern auch zusätzliches Wissen über die Semantik des Graphen
eine wichtige Rolle spielt. So werden z.B. bei einem Stammbaum die Knoten in der Regel
nach Geburtsdatum der betreffenden Personen sortiert von oben nach unten oder von links
nach rechts angeordnet. Da Graphenlayouts in den meisten Fällen zur Visualisierung von
Informationen und damit für menschliche Betrachter erstellt werden, werden die Kriterien
zur Beurteilung der Qualität des Layouts als ästhetische Kriterien bezeichnet. Diese Kriterien sind aber sowohl von der Anwendung als auch vom Betrachter abhängig und deshalb
oft subjektiver Natur. Die folgende Aufzählung enthält eine Auswahl aus den am häufigsten
genannten ästhetische Kriterien (vgl. dazu z.B. [Pur98]).
• Minimierung von Linienüberschneidungen. Kommt es zu vielen Linienüberschneidungen, so wird es für einen Betrachter mühsam herauszufinden, welche Knoten miteinder verbunden sind. Kann ein Graph ohne Linienüberschneidungen gezeichnet werden,
so wird er als planar bezeichnet.
• Minimierung der Knicke in den Linien. Die Anzahl der Knicke oder Hilfspunkte
spielt v.a. bei der orthogonalen Linineführung eine wichtige Rolle. Wird eine Linie mit
Hilfe einer grossen Anzahl von Hilfspunkten geführt, so wird es für den Betrachter
schwieriger, der Linie zu folgen.
• Minimierung der Ausdehnung. Ein Layout, bei dem die Knoten gleichmässig über
den zur Verfügung stehenden Raum verteilt sind, wird in der Regel als angenehmer
empfunden als ein Layout, bei dem sich grosse Lücken zwischen den Knoten befinden.
2
Im Folgenden wird der Begriff Graph als Oberbegriff benutzt. Es wird also nicht weiter zwischen einfachen
Graphen und spezielleren Graphen wie z.B. Multigraphen unterschieden.
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
30
• Symmetrien veranschaulichen. Sind in den zu visualisierenden Daten Symmetrien
enthalten, so sollten diese durch das Layout sichtbar gemacht werden.
• Gruppen zusammenfassen. Weist die Struktur der Daten auf eine Aufteilung in
verschiedene Gruppen hin, so sollten die Knoten so platziert werden, dass diese Gruppenstrukturen sichtbar werden.
Die ersten drei Kriterien beziehen sich nur auf das Aussehen des visualisierten Graphen,
während die letzten beiden Kriterien zusätzliche in den Daten enthaltenen Informationen
sichtbar machen sollen. Mit den in Abschnitt 2.1.4 beschriebenen Experimenten versuchte
Purchase [Pur98] die Bedeutung der verschiedenen ästhetische Kriterien für die Lesbarkeit
und Verständlichkeit von Graphen zu klären. Dabei zeigte sich, dass in erster Linie eine hohe
Anzahl von Linienüberschneidungen und Knicken in den Linien die Lesbarkeit erschwert.
Einige der genannten Kriterien können nicht effizient (d.h. mit akzeptabler Laufzeit des Algorithmus) optimiert werden, wodurch oftmals auf Heuristiken zurückgegriffen werden muss.
Zusätzlich kann es zu Konflikten zwischen den verschiedenen Kriterien kommen.
3.1.1
Graphenlayouter
Für das automatische Layouten von Graphen wurden im Verlauf der Zeit eine grosse Anzahl
von Algorithmen entwickelt, wobei die oben genannten Kriterien jeweils unterschiedlich stark
gewichtet werden. Die Algorithmen sind oftmals auf einen bestimmten Anwendungsbereich
ausgerichtet, da für eine ansprechendes Layout in vielen Fällen zusätzliche Informationen über
den Anwendungsbereich benötigt werden.
Eine ganze Gruppe von Algorithmen zum automatischen Layouten von Graphen beruht
z.B. auf dem kräftebasierten Ansatz [Ead84]. Dabei bilden die Graphen ein System von interagierenden physikalischen Objekten, das von verschiedenen Kräften bestimmt wird. Als
physikalische Analogie verhalten sich die Knoten eines Graphen wie Kugeln, die sich gegenseitig abstossen. Diese Kugeln werden durch Federn miteinander verbunden, d.h. die Kanten
des Graphen werden durch Federn ersetzt. Die Federn üben, je nachdem ob sie gestreckt oder
gestaucht werden, unterschiedliche Kräfte auf das physikalische System aus. Der kräftebasierte Algorithmus versucht nun ein Gleichgewicht aller im System wirkenden Kräfte herzustellen
und das System damit in einen stabilen Zustand zu überführen. Das ganze aus Kugeln bestehende System wird also einfach “losgelassen”, wodurch sich überdehnte Federn zusammenziehen und gestauchte Federn ausdehnen. Das Vorgehen führt somit dazu, dass die Knoten
gleichmässig verteilt werden und adjazente3 Knoten nahe beieinander liegen. Für die grosse
Akzeptanz des kräftebasierten Ansatzes sind dabei in erster Linie die folgenden Eigenschaften
verantwortlich: Aufgrund seiner physikalischen Analogie ist er sehr intuitiv und damit in seinen Grundlagen leicht verständlich. In seiner einfachen Form lässt er sich auch relativ leicht
implementieren und liefert in vielen Fällen gute Ergebnisse.
Die Linien werden beim kräftebasierten Ansatz direkt vom Start- zum Endknoten geführt.
Dabei stellen Überschneidungen zwischen Kanten und Knoten aus zwei Gründen kein grosses
Problem dar. Erstens werden die Knoten so angeordnet, dass adjazente Knoten nahe beieinander liegen und damit treten lange Kanten nur selten auf. Und zweitens haben die Knoten in
3
Knoten werden in einem Graphen als adjazent bezeichnet, wenn sie durch eine Kante miteinander verbunden sind.
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
31
der Regel gar keine oder eine vernachlässigbare Ausdehnung, wodurch sich durch eine kleine
Verschiebung eines Knotens eine Überschneidung leicht auflösen lässt.
Bezüglich der Visualisierung der Knoten gleichen Adora-Modelle UML-Klassendiagrammen,
da die Knoten sowohl in Adora-Modellen als auch in UML-Klassenmodellen eine relative
grosse Ausdehnung haben. Der Ansatz von Eiglsperger [Eig03] z.B. platziert die Knoten in
einem UML-Klassendiagramm so, dass es zu möglichst wenigen Überschneidungen zwischen
Knoten und Linien kommt, und führt die Linien zur Repräsentation der Beziehungen orthogonal zwischen den Knoten hindurch. Die Platzierung der Knoten und die Linienführung bilden
dabei wieder eine Einheit, d.h. die Knoten werden so platziert, dass möglichst wenig Linienüberscheidungen auftreten. Aufbauend auf diesem Ansatz ermöglicht der in yFiles [Wie01]
implementierte Graphenlayouter auch eine automatische orthogonale Linienführung in einem
durch den Benutzer vorgegebenen Layout, d.h. die Erstellung des Layouts (d.h. die Platzierung der Knoten) und die Linienführung werden getrennt voneinander durchgeführt. Der zu
Grunde liegende Algorithmus versucht dabei jeweils die Linienführung global, d.h. unter Einbezug aller existierenden Linien, zu optimieren. Dadurch kann das Hinzufügen einer einzelnen
neuen Linie Veränderungen an einem grossen Teil der bestehenden Linien verursachen. Abbildung 3.1 illustriert den Vorgang, bei dem das Hinzufügen der Linie zwischen den Knoten
C und D zu einer komplett neuen Führung der bestehenden Linie zwischen den Knoten A
und E führt.
Abbildung 3.1: Verlegung von bestehenden Linien durch yFiles
3.1.2
Layouten von dynamischen Graphen
Viele Szenarien beim Graphenlayout sind in dem Sinne dynamisch, dass sie ein wiederholtes
Layouten des Graphen nach Änderungen an dessen Struktur oder den Layouteigenschaften
erfordern. Die einfachste Möglichkeit zur Behandlung dieser Dynamik besteht darin, jede
Modifikation als komplett eigenständiges Problem zu betrachten und deshalb auch losgelöst
vom bestehenden Layout zu behandeln, d.h. das Layout des Graphen wird einfach komplett
neu berechnet. Ein solches Vorgehen hat jedoch zwei bedeutende Nachteile: Erstens ist es
ineffizient, aufgrund einer kleinen lokalen Änderung das gesamte Layout neu zu berechnen.
Und zweitens zerstört ein solches Vorgehen die in Abschnitt 2.2.1 beschriebene Mental Map
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
32
des Benutzers. Aus diesem Grund haben sich eine Reihe von Autoren mit dem dynamischen
Zeichnen von Graphen beschäftigt. Die Dynamik kommt dabei durch vom Benutzer vorgenommene Änderungen (z.B. dem Hinzufügen oder Entfernen von Knoten) zu Stande, und
beschränkt sich damit auf einen kleinen Teilbereich des Graphen.
Um die Mental Map des Benutzers zu erhalten existieren zwei Möglichkeiten:
1. Unterstützung des Benutzers, indem die Änderungen animiert oder hervorgehoben werden, damit sie leicht erkannt werden können und der Übergang zum neuen Layout sanft
erfolgt.
2. Die Änderungen am Layout minimieren, um den Aufwand zur Erkennung von Ähnlichkeiten möglichst gering zu halten.
Um das Layout möglichst schonend zu verändern kommen dabei zwei Vorgehensweisen in
Frage: die Änderungen beschränken sich nur auf einen Teil der Knoten und Kanten oder das
Ausmass der Änderung wird mit Hilfe eines Distanzmass gemessen und dann minimiert. Als
Distanzmass kommt dabei z.B. die Summe der euklidischen Distanzen (z.B. [Bri98]), um die
jeder Knoten durch die Änderung verschoben worden ist.
Die dynamischen Graphen kommen dem dynamischen Layout von Adora-Modellen schon
näher als die statischen Graphen, bei denen das Layout nach jeder Änderung komplett neu
berechnet wird. Im Vergleich zum statischen Graphenlayout geniesst das Problem des dynamischen Layouts jedoch nur geringe Aufmerksamkeit.
3.1.3
Anwendbarkeit auf Adora-Modelle
Im Bereich des automatischen Graphenlayouts wird die Linienführung fast ausnahmslos als
integraler Teil des Layoutprozesses betrachtet. Die Linienführung wird dabei in erster Linie durch eine geschickte Positionierung der Knoten optimiert. Im Gegensatz dazu wird in
einem Adora-Modell das Layout durch den Benutzer vorgegeben und die Linienführung
hat sich im dadurch vorgegebenen Rahmen zu bewegen. Die Algorithmen aus dem Bereich
des automatischen Layoutens von Graphen eignen sich deshalb nicht zur Linienführung in
Adora-Modellen.
Die automatischen Graphenlayouter operieren normalerweise auch auf einem statischen Layout, d.h. das Layout des Graphen wird einmal berechnet und ändert sich danach nicht mehr.
Wird auf Änderungen Rücksicht genommen und das Layout nur schonend verändert, so
müssen sich die Änderungen auf einen kleinen Teil des Graphen beschränken. Der ZoomAlgorithmus verändert demgegenüber praktisch das gesamte Layout eines Adora-Modells
und die Dynamik in einem Adora-Modell hat damit ein ganz anderes Ausmass als sie im
Bereich der automatischen Graphenlayouter behandelt wird.
Da der gesamte Layoutprozess automatisch abläuft, hat der Benutzer normalerweise auch
gar keinen Einfluss darauf. Selbst bei Algorithmen, die das Layout (d.h. die Positionen und
Grössen der Knoten) nicht antasten und nur die Linien zwischen den Knoten hindurchführen,
hat der Benutzer in den meisten Fällen keine Möglichkeit der Einflussnahme. So kann der
Benutzer z.B. beim beschriebenen yFiles [Wie01] die Linienführung nur dadurch beeinflussen,
dass er den Start- oder Endknoten verschiebt, an der Linie selbst sind keine Änderungen
möglich.
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
3.2
33
Schaltungsentwurf
Auch elektronische Schaltungen bilden mit den elektronischen Elementen als Knoten und
den elektrischen Leitungen als Kanten einen Graphen. Trotzdem hat sich das Gebiet des
Entwurfes von Schaltung unabhängig vom Gebiet der Graphenlayouter entwickelt. Dies hat
mehrere Gründe: Im Gegensatz zum Layout von Graphen hat das Layout von Platinen oder
Schaltungen nicht den ästhetischen Kriterien eines menschlichen Betrachters, sondern technischen Kriterien, wie z.B. der Verhinderung von Überschneidungen von Leitungen oder maximal erlaubter Länge von Leitungen, zu genügen. Im Weiteren sind im Bereich des Entwurfs
von Schaltungen das Layouten (d.h. das Platzieren der elektronischen Elementen) und die
Linienführung4 zwei voneinander getrennte Arbeitsschritte, die nacheinander durchgeführt
werden. Im Bereich hochintegrierter Schaltung (VLSI: Very Large Scale Integration) ist die
Anzahl der Knoten und Kanten mit mehreren Millionen zusätzlich sehr hoch. Aufgrund dieser
Unterschiede wird der Bereich des Schaltungsentwurfs hier auch getrennt von den automatischen Graphenlayoutern betrachtet.
Im Bereich der elektrischen und elektronischen Schaltungen hat sich für die Linienführung der
Stil der orthogonalen Linienführung durchgesetzt. Nur im Bereich von analogen Schaltungen
werden die Leitungen teilweise auch schräg geführt. Da Überschneidungen von Leitungen
in jedem Fall verhindert werden müssen, werden die Leitungen nicht nur auf einer Ebene,
sondern in mehreren übereinanderliegenden Schichten geführt. Die Linienführung läuft damit
nicht mehr nur im zwei-, sondern im dreidimensionalen Raum ab. Die folgende Diskussion
beschränkt sich jedoch auf die Anwendung im zweidimensionalen Raum.
Abbildung 3.2: Gitterstruktur
Für die Linienführung beim Schaltungsentwurf wurden verschiedene Techniken entwickelt.
Der grösste Teil davon arbeitet dabei mit einer aus uniformen Zellen bestehenden Gitterstruktur. Abbildung 3.2 zeigt ein Beispiel einer solchen Gitterstruktur. Dabei sollen die bei4
Das Führen der Leitungen wird im Bereich des Schaltungsentwurfs als Routing bezeichnet. Im Folgenden
wird dafür jedoch der Begriff der Linienführung beibehalten.
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
34
den mit S und E bezeichneten Zellen durch eine Linie miteinander verbunden werden, wobei
die dunkelgrau hinterlegten Zellen Hindernisse darstellen. Weil sich die Linie wie in einem
Labyrinth zwischen Hindernisse hindurchbewegen muss, wird diese Technik auch als Maze
Routing bezeichnet.
3.2.1
Algorithmus von Lee
Der bedeutenste Algorithmus, um einen Pfad durch eine uniforme Gitterstruktur zu finden, ist
der Algorithmus von Lee [Lee61]. Es handelt sich dabei um eine Breitensuche, die garantiert
den kürzest möglichen Pfad liefert. Der Algorithmus setzt sich aus zwei Phasen zusammen.
Als Erstes werden vom Startpunkt aus in einer wellenförmigen Bewegung die Zellen mit einem
Kostenwert versehen, bis dabei der Endpunkt erreicht wird. Danach wird vom Endpunkt aus
anhand der Kostenwerte der Zellen der kürzeste Weg zum Startpunkt zurückverfolgt.
Abbildung 3.3 illustriert die ersten und letzten drei Schritte der ersten Phase. Dabei sollen die
beiden hellgrau hinterlegten Zellen miteinander verbunden werden, wobei die dunkelgrauen
Zellen Hindernisse darstellen. Beim Schritt k werden dabei jeweils alle Zellen mit dem Wert
k von der Startzelle mit der Distanz k belegt.
Abbildung 3.3: Kosten berechnen
Der Algorithmus arbeitet dabei mit einer Queue-Datenstruktur, die nach dem First-In-FirstOut Prinzip organisiert ist. Zellen werden also in der Reihenfolge aus der Queue entnommen,
in der sie darin abgelegt worden sind. In Schritt 0 wird die Startzelle mit der ManhattenDistanz 0 belegt und in der Queue abgelegt. Danach wird diese Zelle gleich wieder aus der
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
35
Queue entnommen und alle Zellen in ihrer von Neumann-Nachbarschaft5 werden mit einem
um eins erhöten Distanzwert belegt und in der Queue abgelegt. Aus der Queue wird dann
wiederum die nächste Zelle entnommen und die benachbarten Zellen, sofern sie noch keinen Distanzwert besitzen, werden analog verarbeitet. Trifft der Algorithmus während dieses
Vorgehens auf die Endzelle oder befinden sich keine Zellen mehr in der Queue, so hat der Algorithmus seine Arbeit beendet. Im ersten Fall hat er dabei einen Pfad gefunden, im zweiten
Fall existiert kein Pfad zwischen der Start- und der Endzelle. Dadurch findet der Algorithmus
von Lee in jedem Fall, in dem ein Pfad existiert, diesen Pfad.
Die zweite Phase besteht nun darin, den in der ersten Phase gefundenen Pfad aus der Gitterstruktur herauszulesen. Der Algorithmus beginn dabei bei der Endzelle und springt jeweils in
die benachbarte Zelle, die einen um eins geringeren Distanzwert als die aktuelle Zelle aufweist.
Abbildung 3.4 veranschaulicht dieses Vorgehen anhand des Beispieles aus Abbildung 3.3 auf
Seite 34.
Abbildung 3.4: Pfad zurückverfolgen
Dabei ist zu beachten, dass die Auswahl der nächsten Zelle beim Zurückverfolgen des Pfades
nicht eindeutig ist, d.h. es können mehrere gleichwertige Zellen existieren. So kommen in
Abbildung 3.4 von der Endzelle aus sowohl der linke als auch der obere Nachbar für den Pfad
in Frage. Auch für die nachfolgenden Zellen im Pfad können jeweils mehrere benachbarte
Zellen bezüglich ihres Distanzwertes gleichwertig sein.
Laufzeit- und Speicherplatzkomplexität
Eine hohe Laufzeit- und Speicherplatzkomplexität ist der Preis, der für die Garantie, den
kürzest möglichen Pfad zu finden, zu bezahlen ist. Besteht die Gitterstruktur aus b × h Zellen,
so hat der Algorithmus zur Berechnung der Distanzwerte eine Laufzeit- und Speicherplatzkomplexität der Ordnung O(bh). Das folgende Beispiel veranschaulicht diese Dimensionen:
Ist eine Gitterstruktur 2000 Zellen hoch und 2000 Zellen breit, so besteht sie gesamthaft
aus 4’000’000 Zellen. Wird das Gitter z.B. durch ein aus 32-bit Zahlen bestehendes zweidimensionales Array repräsentiert, so belegte die gesamte Gitterstruktur bereits 16 Megabyte
Speicher.
Das Problem der hohen Laufzeitkomplexität lässt sich auch anhand eines kleinen Beispiels
nachvollziehen. Das Gitter in Abbildung 3.5 besteht gesamthaft aus 225 Zellen, wovon 56
5
Die von Neumann-Nachbarschaft umfasst die vier Nachbarn, die sich links, rechts, oberhalb und unterhalb
einer Zelle befinden.
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
36
durch Hindernisse belegt sind. Im Gitter sind somit 169 Zellen vorhanden, durch die ein
Pfad hindurchführen kann. Um einen Pfad zwischen den beiden mit S und E bezeichneten
Zellen zu finden, muss der Algorithmus in 14 Schritten für 144 Zellen einen Distanzwert
berechnen. Somit werden in diesem Fall mehr als 85% aller freien Zellen durch den Algorithmus
bearbeitet, obwohl der Start- und Endpunkt relativ nahe beieinander liegen. Die hohe Anzahl
an Zellen kommt dabei durch die Breitensuche zu Stande, bei der nicht gezielt in eine Richtung
nach einem Pfad gesucht wird, sondern blind in alle Richtungen. Nur durch diese Breitensuche
ist der Algorithmus von Lee aber in der Lage, garantiert den kürzsten Pfad zu finden, falls
mindestens ein Pfad existiert.
Abbildung 3.5: Berechnete Distanzwerte
Um die Laufzeit und den Speicherplatzbedarf von Lee’s Algorithmus zu reduzieren wurden eine ganze Reihe von Techniken vorgeschlagen. So kombiniert z.B. der Algorithmus von Soukup
[Sou78] die Breitensuche mit einer Tiefensuche. Dabei wird immer in Richtung des Ziels gesucht, ohne dabei die Richtung zu ändern (Tiefensuche). Trifft der Algorithmus dabei auf ein
Hinderniss, so wird analog zum Algorithmus von Lee mit einer Breitensuche um das Hindernis
herumgesucht. Dieses Vorgehen kann jedoch zu einer suboptimalen Lösung führen, d.h. der
Algorithmus liefert nicht in jedem Fall den kürzesten Pfad. Das grundsätzliche Problem der
hohen Anzahl von Zellen, aus denen sich die Gitterstruktur zusammensetzt, vermag jedoch
keine der vorgeschlagenen Techniken zu lösen.
Da die mit dem Algorithmus von Lee berechneten Distanzwerte der Zellen die Kosten angeben, mit denen die Startzelle erreicht werden kann, lässt sich die Linienführung durch das
Einführen von zusätzlichen Kosten beeinflussen. So können z.B. die Zellen in Regionen, durch
die der Pfad nicht hindurchführen sollte, zusätzlich künstlich verteuert werden. Damit können
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
37
z.B. Überschneidungen von Linien verhindert werden.
3.2.2
Line Probing
Einen etwas anderen Ansatz der Linienführung im Bereich des Schaltungsentwurfs stellt das
Line Probing [Mik68] dar. Die grundlegende Idee besteht dabei darin, jeweils durch den Startund den Endpunkt sowohl eine vertikale als auch eine horizontale Linien6 zu führen, wobei
diese Linien auf den Linien einer uniformen Gitterstruktur verlaufen. Schneidet sich eine der
Linien, die durch den Startpunkt führen, mit einer der Linien durch den Endpunkt, so wurde
ein Pfad gefunden. Abbildung 3.6 illustriert das Vorgehen beim Line Probing:
Abbildung 3.6: Vorgehen beim Line Probing
Existiert kein Schnittpunkt zwischen den Linien, so werden an den Fluchtpunkten neue Linien erzeugt. Als Fluchtpunkte dienen dabei alle Schnittpunkte des Gitters mit den bereits
bestehenden Linien. Die Fluchtpunkte sind in Abbildung 3.7 durch Kreise dargestellt. Die
vier ursprünglichen Linien, aus denen die Fluchtpunkte hervorgegangen sind, sind in der Abbildung stärker hervorgehoben.
Abbildung 3.7: Fluchtpunkte beim Line Probing
6
Streng geometrisch handelt es sich dabei um eine Strecke, da sie einen Start- und Endpunkt besitzt.
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
38
Die horizontalen und vertikalen Linien werden dabei sowohl für den Start- als auch den Endpunkt in getrennten Listen abgelegt. Wird nun z.B. an einem vom Startpunkt ausgehenden
Fluchtpunkt eine horizontale Linie erzeugt, so wird sie mit allen Linien in der Liste, in der die
vom Endpunkt ausgehend erzeugten vertikalen Linien enthalten sind, auf einen Schnittpunkt
überprüft. Wird auf diese Weise ein Schnittpunkt entdeckt, so wurde ein Pfad gefunden.
Dieser Pfad entspricht jedoch nicht immer der optimalen (d.h. kürzesten) Lösung. Wie der
Algorithmus von Lee hat auch das Line Probing eine hohe Laufzeit (der Ordnung O(l), wobei
l die Anzahl der Linien angibt), da je nach Grösse und Auflösung des zu Grunde liegenden
Gitters eine sehr grosse Anzahl von Linien nötig wird.
3.2.3
Weitere Ansätze
Neben den beiden beschriebenen Techniken zur Linienführung beim Schaltungsentwurf existiert noch eine ganze Reihe weiterer Ansätze. So operiert z.B. eine Gruppe von Algorithmen
auf einem Graphen, der ein Abbild der Gitterstruktur darstellt. Die Zellen bilden dabei die
Knoten und von Neumann-Nachbarn werden durch eine Kante miteinander verbunden. Innerhalb dieses Graphen wird dann z.B. mit dem Algorithmus von Dijkstra [Dij59] der kürzeste
Pfad gesucht. Abbildung 3.8 zeigt ein Beispiel eines solchen Gitter-Graphen.
Abbildung 3.8: Beispiel eines Gitter-Graphen
Die Hindernisse aus Abbildung 3.8a werden dabei im Gitter-Graphen von Abbildung 3.8b als
schwarze Punkte dargestellt, die freien Zellen als nicht ausgefüllte Kreise. Die grau markierten
Knoten in Abbildung 3.8b markieren einen möglichen Pfad um die beiden Zellen S und E aus
Abbildung 3.8a zu verbinden.
3.2.4
Anwendbarkeit auf Adora-Modelle
Da im Bereich des Schaltungsentwurfs die Linienführung erst nach der Positionierung der
Schaltungeselemente durchgeführt wird und damit keinen Einfluss auf das Layout (d.h. die
Position der Schaltungselemente) nehmen kann, weist das Problem grosse Änlichkeiten mit
dem Problem der Linienführung in einem Adora-Modell auf. Ebenso haben in beiden Fällen
die Knoten, die als Hindernisse auftreten können, eine gewisse Ausdehnung, die nicht, wie im
Falle der Graphenlayouter, einfach vernachlässigt werden kann.
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
39
Die beiden Probleme unterscheiden sich jedoch in grundlegenden an sie gestellten Anforderungen. Die Linienführung in einer Schaltung hat nur technischen Kriterien, wie z.B. der
Vermeidung von Überschneidungen oder der maximal zulässigen Länge der Linien bzw. Leitungen, zu genügen. Bei einam Adora-Modell stehen dem gegenüber ästhetische Kriterien
im Vordergrund.
Im Gegensatz zu Adora-Modellen, bei denen es häufig zu Veränderungen am Layout kommt,
die eine neue Linienführung erfordern, ist die Linienführung beim Entwurf einer Schaltung
normalerweise ein einmaliger Vorgang, der nach dem Platzieren der Elemente und der Bestimmung der benötigten Verbindungen durchgeführt wird. Aus diesem Grund stellen die hohen
Laufzeiten der Algorithmus in der Regel auch kein allzu grosses Problem dar. Die Arbeit an
einem Adora-Modell ist jedoch in erster Linie eine interaktive Tätigkeit, wodurch Algorithmen mit einer derart hohen Laufzeit nicht in Frage kommen. Dies ist auch der Grund, warum
Berner [Ber02] den Einsatz solcher “echter” Routing-Algorithmen für Adora-Modelle als
nicht machbar erachtet. Der in Abschnitt 4.3 vorgestellte Ansatz ermöglicht jedoch die Anwendung einer Variation des Algorithmus von Lee auf Adora-Modelle ohne die beschriebenen
Laufzeitprobleme.
Abbildung 3.9: Uniforme Gitterstruktur bei einem Adora-Modell
Die hohe Laufzeit kommt durch die uniforme Gitterstruktur (d.h. die gesamte Platine oder
Schaltung wird in gleichgrosse quadratische Zellen unterteilt) zu Stande, auf der die meisten
Algorithmen zur Linienführung im Bereich des Schaltungsentwurfs arbeiten. Die Zellengrössen
werden dabei so gewählt, dass eine Leitung horizontal oder vertikal durch die Zelle hindurchgeführt werden kann. Durch diese kleine Ausdehnung einer Zelle setzt sich das Gitter aus
sehr vielen Zellen zusammen. Beim Platinenlayout und v.a. beim Entwurf im VLSI Bereich
wird versucht die gesamte Ausdehnung der Schaltung möglichst gering zu halten, wodurch
sich die Grösse des Gitters wieder reduziert. Im Gegensatz dazu können zwischen den Knoten
in einem Adora-Modell grosse Zwischenräume bestehen. Die Zellengrösse des Gitters muss
sich aber an der geringsten Distanz zwischen zwei Knoten orientieren. So darf die Zellengrösse
des Gitters in Abbildung 3.9 nicht grösser sein als die Distanz zwischen den Knoten A und
C, da sonst keine Linien zwischen den beiden Knoten hindurchgeführt werden können. Die
KAPITEL 3. BESTEHENDE ANSÄTZE DER LINIENFÜHRUNG
40
Zellengrösse in einem Adora-Modell muss sich daher im Bereich weniger Pixel bewegen. Da
die Knoten im Modell oftmals eine grosse Ausdehnung aufweisen und damit das gesamte Modell eine grosse Fläche belegt, wird die Anzahl der Zellen extrem gross. Ein Adora-Modell
verschärft damit das Problem der hohen Anzahl von Zellen in der Gitterstruktur in der Regel
noch.
3.2.5
Routing in Kommunikationsnetzwerken
Der Begriff Routing tritt in der Informatik am häufigsten im Zusammenhang mit Kommunikationsnetzwerken auf. Ein Routing-Algorithmus ist dabei dafür verantwortlich, Pakete über
Zwischenstationen von der Quell- zur Zielstation durch das Netzwerk zu führen. Das Routing
in diesem Zusammenhang unterscheidet sich damit vom Routing im Bereich des Schaltungsentwurfs und der Adora-Modelle dadurch, dass es sich nicht in erster Linie mit Hindernissen,
sondern mit Verbindungen unterschiedlicher Qualität zu beschäftigen hat.
Ein grosser Teil der Routing-Algorithmen im Bereich der Netzwerke operiert dabei auf einem
Graphen, in dem die an das Netzwerk angeschlossenen Maschinen die Knoten bilden und die
Kanten die Verbindungen zwischen diesen Maschinen repräsentieren. Die Kanten haben dabei
unterschiedliche Gewichte, mit denen die Qualität der Verbindung beschrieben wird. In diesem
Graphen wird dann z.B. mit dem Algorithmus von Dijkstra [Dij59] der kürzeste Pfad gesucht.
Die Länge einer Kante ergibt sich dabei durch das ihr zugewiesene Gewicht. Ein Beispiel eines
solchen Algorithmus ist der für das Routing im Internet eigesetzte OSPF-Algorithmus (Open
Shortest Path First [Moy98]). Das Routing in einem Kommunikationsnetzwerk weist damit
Änlichkeiten mit dem in Abschnitt 3.2.3 beschriebenen Ansatz der Linienführung mit Hilfe
eines Gitter-Graphen auf. Da es sich jedoch stark vom Problem, das im Zusammenhang mit
Adora-Modellen auftritt, unterscheidet, wird das Routing, wie es in Kommunikationsnetzwerken auftritt, hier nur der Vollständigkeit halber aufgeführt und im Rahmen dieser Arbeit
nicht weiter behandelt.
Kapitel 4
Linienführung in einem
dynamischen Layout
Die im vorherigen Kapitel vorgestellten Ansätze zur Linienführung operieren auf einem statischen Layout. Die Visualisierung von Adora-Modellen wiest jedoch ein dynamisches Layout
auf, da je nach Abstraktionsebene und eingeblendeter Aspekte unterschiedliche Darstellungen
aus dem integrierten Gesamtmodell generiert werden. Neben dem Führen von Linien durch
ein statisches Layout, muss der Ansatz für die Linienführung also auch Vorgehensweisen zur
Anpassung der Linien bei Veränderungen des Layouts, wie sie z.B. bei der Anwendung des
Zoom-Algorithmus auftreten, beinhalten. Bei dieser Anpassung der Linien muss zusätzlich
die Sekundärnotation der Linie so weit wie möglich erhalten bleiben.
Das aktuelle Kapitel geht auf eine Reihe von Ansätzen ein, die für die Linienführung in einem dynamischen Layout in Frage kommen. Dabei werden jedoch nur Strategien behandelt,
die keine Änderungen am Layout, d.h. an der Position und Grösse der Knoten, vornehmen.
Die verschiedenen Ansätze operieren damit sowohl beim Hinzufügen neuer Linien oder Knoten als auch bei der Anpassung der Linien nach einer Veränderung des Layouts auf einem
vorgegebenen und nicht veränderbarem Layout.
4.1
Moderate Änderungen der direkten Linienführung
Berner [Ber02] schlägt vor, die Linienführung beim Auftreten von Überschneidungen zwischen
einer Linie und einem Knoten möglichst schonend anzupassen, wobei die grobe Richtung der
Linie beibehalten wird. Dabei wird die Linie zuerst direkt vom Start- zum Endpunkt geführt
und danach werden Schritt für Schritt Überschneidungen mit Knoten aufgelöst. Das Ziel
bleibt dabei immer eine direkte Linienführung und die Anpassungen sind nur temporärer
Natur. Die Strategie lässt sich damit auch nur bei einer direkten Linienführung anwenden.
4.1.1
Das Linienproblem
Als Linienproblem bezeichnet Berner Überschneidungen zwischen Linien und Knoten, die
bei der Anwendung des Zoom-Algorithmus durch die Veränderung des Layouts entstehen
können. Damit beschränkt sich Berner auf die Probleme, die durch das dynamische Layout
41
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
42
der Adora-Modelle auftreten, und geht nicht auf Überschneidungen ein, die bei der Erstellung
des Modells (d.h. beim Hinzufügen von Linien und Knoten) auftreten.
Das Linienproblem umfasst dabei nur Überschneidungen zwischen Linien und Knoten und
nicht Überschneidungen von Linien untereinander oder Überlappungen von Linienbeschriftungen. Nur ein echter Routing-Algorithmus (z.B. der in Abschnitt 3.2.1 beschriebenen Algorithmus von Lee) ist gemäss Berner in der Lage, das Problem der Überschneidungen von Linien zu
lösen. Da diese Algorithmen aus dem Bereich des Platinenlayouts oder dem Design integrierter
Schaltungen eine sehr hohe Zeitkomplexität aufweisen, kommen sie gemäss Berner nicht für
eine interaktive Nutzung, wie sie bei Adora-Modellen auftritt, in Frage. Zusätzlich werden
bei diesen Algorithmen oftmals bestehende Linien komplett neu geführt, um Überschneidungen zu verhindern, was bei einem Adora-Modell die Sekundärnotation und damit die Mental
Map des Benutzers zerstören würde. Für Berner kommen echte Routing-Algorithmen deshalb
nicht in Frage und das Problem lässt sich nur durch moderate Änderungen der direkten Linienführung1 lösen. Diesen Ansatz bezeichnet Berner denn auch als Poor-Man’s-Routing, um sie
vom Einsatz eines echten Routing-Algorithmus abzugrenzen. Abbildung 4.1 veranschaulicht
das von Berner beschriebene Linienproblem, das beim Verfeinern des Knotens C auftritt.
Abbildung 4.1: Linienproblem
Wird die Linie zwischen Knoten B und D jedoch hinzugefügt, solange Knoten C verfeinert
ist, so tritt die Überschneidung bereits beim Hinzufügen der Linie auf. Da auch in diesem
Fall die Linie angepasst werden muss, wird der Begriff des Linienproblems für die folgende
Diskussion um diese Situation erweitert.
4.1.2
Vorgehen
Zur Lösung des Linienproblems kommen gemäss Berner zwei verschiedene Möglichkeiten in
Frage: Zum einen das Verschieben der Start- und Endpunkte auf dem Rand der beteiligten
Knoten und zum anderen das Einfügen von Hilfspunkten in die Linie. Das Verschieben der
Start- und Eckpunkte löst jedoch das Problem der Überschneidung in den meisten Fällen
nicht und zerstört zusätzlich einen Teil der Sekundärnotation der Linie. So führt im Beispiel
von Abbildung 4.1 diese Strategie nicht zum Erfolg, da die Knoten, auf deren Rand der Start1
Berner [Ber02] bezeichnet seinen Ansatz zur Lösung des Linienproblems als “moderate Änderung der
Linienführung”. Dieser Begriff wird deshalb auch in dieser Arbeit weiterverwendet.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
43
bzw. Endpunkt liegt, zu klein sind, um die Punkte genügend weit zu verschieben, um die
Überschneidung aufzulösen. Aus diesem Grund wird diese Strategie nicht weiter verfolgt.
Durch das Einfügen von Hilfspunkten in die Linie wird, wie bereits in Abschnitt 2.1.1 kurz
angesprochen, die Linie in mehrere Segmente unterteilt und damit um das Hindernis herumgeführt. Die Linien werden dabei immer mit so wenig Hilfspunkten wie möglich geführt,
d.h. Hilfspunkte können wieder verschwinden, wenn sie für eine überschneidungsfreie Linienführung nicht mehr benötigt werden. Berner unterscheidet zwischen einer Einpunktstrategie, bei der ein einzelner Hilfspunkt ausreicht, und einer Mehrpunktstrategie, bei der mehrere
Hilfspunkte eingefügt werden müssen. Da sich die beiden Strategien bezüglich des Vorgehens jedoch nicht stark unterscheiden, werden sie im Folgenden zusammen betrachtet. Abbildung 4.2 veranschaulicht anhand eines Beispiels das Vorgehen beim Einfügen von Hilfspunkten:
Abbildung 4.2: Lösung des Linienproblems durch das Einfügen von Hilfspunkten
Die Umsetzung der Strategie erfordert zwei Schritte: erstens die Bestimmung der Schnittpunkte zwischen der Linie und den Knoten und zweitens die Berechnung der Position der
Hilfspunkte, die eingefügt werden müssen:
1. Alle Knoten werden auf Schnittpunkte mit dem nächsten Segment2 (zu Beginn entspricht dies dem ersten und einzigen Segment) überprüft. Jener Schnittpunkt, der die
geringste Distanz zum Startpunkt aufweist, markiert dabei die erste Überschneidung
(Schritt 1 in Abbildung 4.2). Wird keine Überschneidung entdeckt, so wird das nächste
Segment überprüft. Entspricht das aktuelle Segment dem letzten Segment der Linie, so
ist die Anpassung der Linienführung beendet.
2. Abhängig von der Position des Schnittpunktes auf dem Rand des Hindernisses und dem
Winkel der Überschneidung, wird jener Eckpunkt des Hindernisses ausgewählt, über
den die Linie am Hindernis verbeigeführt werden kann. In einem parametrisierbaren
Abstand zu diesem Eckpunkt wird dann ein Hilfspunkt in die Linie eingefügt. Dabei ist
zusätzlich noch sicherzustellen, dass der Hilfspunkt nicht innerhalb eines Hindernisses zu
2
Ein Segment (oder auch Liniensegment) bezeichnet in diesem Zusammenhang den Teil einer Linie, der
durch zwei Hilfspunkte begrenzt wird. Ein Segment entspricht damit einer Strecke, wie sie in der Geometrie
definiert ist. Befinden sich keine Hilfspunkte in der Linie so besteht die Linie aus einem einzigen Segment, das
vom Start- zum Endpunkt reicht.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
44
liegen kommt (Schritt 2 in Abbildung 4.2). Danach wird das Vorgehen rekursiv auf das
Segment vor und nach dem Hilfspunkt angewandt (Schritte 3 und 4 in Abbildung 4.2).
4.1.3
Beurteilung
Vor allem bei einfacheren Layouts (wie z.B. dem in Abbildung 4.2 auf Seite 43) liefert der
Ansatz der moderaten Änderungen der direkten Linienführung gute Resultate. Dabei kommt
vor allem der in Abschnitt 2.1.1 beschriebene Vorteile der direkten Linienführung, dass sich
die Linien stark von den Hindernissen abheben, zum Tragen. Bei einem einfachen Layout
spielt es für den Benutzer auch keine Rolle (d.h. seine Mental Map wird nicht zerstört), wenn
Hilfspunkte je nach aktuellem Layout hinzukommen oder verschwinden, solange die Linie
immer ungefähr gleich verläuft. Der Benutzer hat jedoch auch nur einen sehr begrenzten
Einfluss auf die Linienführung. Da die Linien grundsätzlich immer direkt vom Start- zum
Endpunkt geführt werden und Hilfspunkte je nach Layout hinzugefügt und wieder entfernt
werden, kann der Benutzer nur gerade auf die Position von Start- und Endpunkt Einfluss
nehmen. Die Sekundärnoation einer Linie besteht deshalb nur aus den Positionen des Startund Endpunktes.
Da es sich bei diesem Vorgehen nicht um einen echten Routing-Algorithmus handelt, können
bei komplexeren Layouts Probleme auftauchen. Diese entstehen in erster Linie dadurch, dass
die grobe Richtung der Linie beibehalten wird und die Linie Schritt für Schritt angepasst
wird, wodurch eine globale (d.h. auf die ganze Linie bezogene Optimierung) nicht möglich
ist. So ist z.B. bei jeder Überschneidung mit einem Knoten aufgrund lokaler Informationen
(z.B. der Position des Schnittpunkts) zu entscheiden, wo der Hilfspunkt platziert wird und
somit auf welcher Seite die Linie am Hindernis vorbeigeführt wird. Zusätzlich scheitert der
Ansatz der moderaten Anpassungen in Fällen, in denen die Linie in eine Sackgasse verläuft,
da in diesem Fall bereits in vorhergehenden Schritten eine radikale Änderung nötig gewesen
wäre. Abbildung 4.3 veranschaulicht diese zwei Probleme: Im Beispiel auf der linken Seite
wäre eine kürzere Linienführung mit weniger Hilfspunkten möglich. Aufgrund der Position
des ersten Schnittpunktes wird mit Hilfe der beschränkten lokalen Informationen (z.B. der
Distanz zu den verschiedenen Eckpunkten des Hindernisses) die Position des ersten Hilfspunktes ausgewählt, die sich im Nachhinein (aus globaler Perspektive) als nicht optimal erweist.
Das Beispiel auf der rechten Seite verunmöglicht eine moderate Anpassung der Line, da eine
Richtungsänderung nötig wäre, um die Linie um die Hindernisse herumzuführen.
Abbildung 4.3: Grenzen der moderaten Anpassung der Linienführung
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
45
Der Ansatz der moderaten Änderung der direkten Linienführung lässt sich in seinen Grundzügen
leicht realisieren. Die grösste Schwierigkeit liegt in der Bestimmung der Positionen der Hilfspunkte. Werden die Hilfspunkte in einem festen oder parametrisierbarem Abstand vom Hindernis eingefügt, so können sie innerhalb eines weiteren Knotens zu liegen kommen. Vor dem
Einfügen eines Hilfspunktes muss deshalb die Umgebung des Bereichs, in den der Hilfspunkt
eingefügt werden soll, untersucht werden. Dabei ist es normalerweise unvermeidlich, das gesamte Modell nach einem Knoten zu durchsuchen, der an dieser Position liegt. Zusätzlich
erhöhen die vielen möglichen Spezialfälle (u.a. die beiden in Abbildung 4.3) die Komplexität
der Realisierung sehr stark. Zusammenfassend lässt sich deshalb sagen, dass sich die Strategie
für die einfacheren Fälle in kurzer Zeit und ohne grosse Probleme realisieren lässt. Eine Realisierung, die eine universelle Anwendbarkeit garantiert (d.h. für jedes Layout eine brauchbare
Lösung liefert), ist jedoch nicht möglich.
Neben der fehlenden universellen Anwendbarkeit stellt die Laufzeit des Algorithmus bei einer
grossen Anzahl von Hindernissen ein Problem dar, vor allem wenn bei einem Zoom-Schritt
(oder einer anderen Layout-Operation, die einen grossen Teil des Layouts verändert) viele Linien angepasst werden müssen. Um Überschneidungen zwischen einer Linie und einem
Knoten zu erkennen, muss jeder Knoten, der aufgrund der Hierarchie für eine Überschneidung
in Frage kommt, darauf hin überprüft werden. Durch das rekursive Vorgehen, bei dem nach
dem Einfügen eines Hilfspunktes beide dadurch entstandene Segmente wiederum auf Überschneidungen untersucht werden müssen, nimmt die Laufzeit mit der Anzahl der Segmente
exponentiell zu. Dieses Problem lässt sich anhand von Abbildung 4.2 auf Seite 43 illustrieren.
Da die Linie vom Knoten A zum Knoten D führt, kommen als Hindernisse die Knoten B
und C in Frage. Aufgrund ihrer hierarchischen Struktur kann es zu keinen Überschneidungen
mit Knoten, die sich z.B. innerhalb von B befinden, kommen. Alle Knoten, mit denen es zu
einer Überschneidung mit der Linie kommen kann, müssen nun jedesmal darauf hin überprüft werden. In Schritt 1 in Abbildung 4.2 müssen also Knoten B und C überprüft werden.
Bei Schritt 2 müssen nun beide in Schritt 1 entstandenen Segmente (vor und nach dem in
Schritt 1 eingefügten Hilfspunkt) wiederum mit den beiden Knoten B und C auf Überschneidungen überprüft werden. Im vorliegenden Fall stellt dies kein Problem dar, da nur eine
Linie angepasst werden muss und nur zwei Hindernisse existieren. Sind jedoch eine grosse
Anzahl von Hindernissen vorhanden und müssen viele Linien angepasst werden, so wird die
Laufzeit zu einem Problem. Das Vorgehen leidet damit unter einem Problem, das bei vielen
geometrischen Algorithmen auftaucht, dass nämlich nicht bekannt ist, welche Knoten für eine
Überschneidung in Frage kommen können und deshalb immer alle überprüft werden müssen.
4.2
Anwendung des Zoom-Algorithmus auf die Hilfspunkte
Bei der Vergröberung oder Verfeinerung eines Knotens werden - wie in Abschnitt 1.4 beschrieben - die benachbarten Knoten mit Hilfe eines Zoom-Algorithmus verschoben. Ein weiterer
Ansatz für die Anpassung der Linien bei Layoutveränderungen beruht deshalb auf der Idee,
die Positionen der Hilfspunkte in den Linien ebenfalls durch den Zoom-Algorithmus (oder allgemeiner durch den Algorithmus, der das Layout verändert) neu zu berechnen. Dieser Ansatz
erfüllt damit jedoch nur einen Teil der in Abschnitt 2.4 an einen Linienführungsalgorithmus
gestellten Anforderungen: Das Problem der erstmaligen Linienführung beim Hinzufügen einer
neuen Linie wird durch diesen Ansatz nicht gelöst und erfordert deshalb einen zusätzlichen
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
46
Algorithmus. So wäre es z.B. möglich, den in Abschnitt 4.1 beschriebenen Ansatz zur moderaten Änderung der direkten Linienführung dafür einzusetzen. Damit werden beim Hinzufügen
einer Linie Überschneidungen mit Konten verhindert, indem die Linie, wie in Abschnitt 4.1.2
beschrieben, schonend angepasst wird. Kommt es dann zu einer Veränderung des Layouts, so
ist die Layout-Operation (in diesem Fall der Zoom-Algorithmus) neben der Neupositionierung
der Knoten auch für die Anpassung der Linien verantwortlich.
4.2.1
Vorgehen
Hilfspunkte in den Linien werden bei diesem Ansatz gleich wie die Knoten des Modells behandelt. Sie werden also - wie in Abschnitt 1.4 erläutert - mit Hilfe von Verschiebevektoren an
ihre neue Position verschoben. Abbildung 4.4 veranschaulicht das Vorgehen bei einer Veränderung des Layouts, die durch die Verfeinerung von Knoten A nötig wird. Für die Berechnung
der Verschiebevektoren kommt dabei der Algorithmus von Berner [Ber02] zum Einsatz. Für
den Hilfspunkt H in der Linie wird dabei analog zu den Knoten B, C und D ein Verschiebevektor berechnet und der Hilfspunkt durch diesen an die Position H’ verschoben. Dadurch
kann eine Überschneidung zwischen der Linie und Knoten C, der nach seiner Verschiebung
C’ entspricht, verhindert werden.
Abbildung 4.4: Verschieben eines Hilfspunktes durch den Zoom-Algorithmus
4.2.2
Beurteilung
Die Umrechnung der Position der Hilfspunkte mit Hilfe des Zoom-Algorithmus scheint auf den
ersten Blick die plausibelste Strategie zur Anpassung der Linienführung nach einem ZoomSchritt zu sein, da sich die Linienführung an den Positionen der Knoten orientieren muss. Im
Weiteren lässt sich dadurch die Sekundärnotation der Linien analog zur Sekundärnotation
des Layouts durch den Zoom-Algorithmus erhalten. Das Problem bei diesem Ansatz ist aber,
dass der Algorithmus, der für die Layout-Operation verantwortlich ist, garantieren muss, dass
es zu keinen Überschneidungen zwischen Knoten und Linien kommt.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
47
Bei der Verschiebung der Hilfspunkte bei einem Zoom-Schritt durch den Algorithmus von
Berner können in gewissen Situationen nach der Verschiebung neue Überschneidungen auftreten. Abbildung 4.5 veranschaulicht eine solche Situation. Wird der Hilfspunkt H bei der
Verfeinerung von Knoten A analog zu den Knoten B, C und D verschoben, so genügt diese
Verschiebung nicht, um eine Überscheidung zwischen der Linie und dem nun verfeinerten
Knoten A’ zu verhindern.
Abbildung 4.5: Problem bei der Anwendung des Zoom-Algorithmus auf die Hilfspunkte
Da der Algorithmus von Berner Okklusionen zwischen Knoten nicht in jedem Fall verhindern
kann, wurde er, wie in Abschnitt 1.4 beschrieben, von Marty [Mar02] erweitert. Abbildung 4.6
illustriert die Verschiebung der Knoten B, C und D sowie des Hilfspunktes H durch den von
Marty erweiterten Algorithmus von Berner bei der Verfeinerung des Knotens A.
Abbildung 4.6: Anwendung des von Marty erweiterten Algorithmus von Berner
Um in diesem Fall die Überschneidungen zwischen der Linie und Knoten A’ aufzulösen ist
eine umfassende Anpasung der Linie notwendig, da diese nun zwischen A’ und C’ hindurchgeführt werden muss. Ein solch umfangreiche Anpassung der Linie kommt jedoch bereits
einer komplett neuen Linienführung gleich, wodurch das Verschieben der Hilfspunkte durch
den Zoom-Algorithmus überhaupt keinen Sinn mehr hat. Noch schwieriger wird die Situation
im Falle einer orthogonalen Linienführung, da dabei zwei aufeinanderfolgende Hilfspunkte
in einer Linie immer entweder die gleiche horizontale oder vertikale Position haben müssen.
Diese Forderung kann z.B. der Zoom-Algorithmus von Berner nicht erfüllen.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
48
Zusätzlich führt dieser Ansatz dazu, dass die Linienführung stark mit den Layout-Operationen
gekoppelt wird, da sich die Algorithmen zur Realisierung der Layout-Operationen auch immer
noch um die Linienführung kümmern müssen. Sollen zu einem späteren Zeitpunkt weitere
Layout-Operationen oder andere Zoom-Algorithmen realisiert werden, so muss dabei immer
auch eine überschneidungsfreie Linienführung sichergestellt werden.
4.2.3
Kopplung der Hilfspunkte an die Knoten
Eine Abwandlung des Ansatzes, die Hilfspunkte in den Linien durch die Layout-Operation
selbst zu verschieben, könnte darin bestehen, die Hilfspunkte an die Knoten zu koppeln und
dann mit diesen zu verschieben.. So wäre es in Abbildung 4.6 auf Seite 47 z.B. möglich den
Hilfspunkt H an Knoten C zu koppeln und ihn dann bei der Verfeinerung von A zusammen
mit Knoten C (d.h. mit gleichbleibendem Abstand zwischen C und H) zu verschieben. Der
Hilfspunkt H würde damit nach seiner Verschiebung ungefähr H’ entsprechen. Bei diesem
Vorgehen tauchen jedoch, wie Abbildung 4.6 bereits klar macht, die gleichen Probleme wie
bei der Anwendung des Zoom-Algorithmus (oder einer anderen Layout-Operation) auf die
Hilfspunkte auf.
4.3
Echter Routing-Algorithmus: Kachelbasierte Linienführung
Die beiden bisher vorgestellten Strategien zur Linienführung lassen zwei wesentliche Probleme in den Vordergrund treten: Erstens ist ein globaler Ansatz nötig um eine Linie auch in
komplexeren Layouts möglichst optimal führen zu können. Dies ist nur mit Hilfe eines echten
Routing-Algorithmus möglich und kann z.B. nicht durch eine schonende Anpassung einer direkten Linie an die Hindernisse erreicht werden. Zweitens gestaltet sich die Linienführung und
auch die Anpassung einer bestehenden Linie nach einer Veränderung des Layouts schwierig,
solange der dafür zur Verfügung stehende freie Raum nicht bekannt ist. So muss z.B. vor dem
Einfügen eines Hilfspunktes jeder Knoten darauf überprüft werden, ob der Hilfspunkt in ihm
zu liegen kommt und damit verschoben werden muss. Der im Folgenden vorgestellte Ansatz
beruht auf einer Datenstruktur, die den freien Raum (d.h. den Raum zwischen den Knoten)
explizit repräsentiert, und wendet zur Linienführung einen echten Routing-Algorithmus auf
diese Struktur an.
4.3.1
Explizite Repräsentation des freien Raumes
Um Überschneidungen zwischen Linien und Knoten zu verhindern, müssen die Linien durch
den freien Raum, der sich zwischen den Knoten befindet, geführt werden. Bei der Visualisierung von Adora-Modellen ist jedoch immer nur der von den Knoten belegte Raum explizit
durch die Position und Grösse der Knoten repräsentiert. Der freie Raum zwischen den Knoten
muss für Operationen, die darauf angewiesen sind, jedesmal aufwendig rekonstruiert werden,
indem die Liste der Knoten (zum Teil sogar mehrmals) durchlaufen wird. Ebenso müssen
Nachbarschaftsbeziehungen zwischen den Knoten der Visualisierung jedesmal aufwendig berechnet werden.
Da diese beiden Probleme auch im Bereich des Entwurfs von integrierten Schaltungen auftauchen, wurde in diesem Umfeld die sogenannte Corner Stitching Datenstruktur [Ous84]
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
49
entwickelt, die sowohl den belegten als auch freien Raum explizit repräsentiert und die verschiedenen Nachbarschaftsbeziehungen enthält. Abbildung 4.7 veranschaulicht, wie vier Knoten in einer Corner Stitching Datenstruktur repräsentiert werden. Die Struktur setzt sich
dabei aus zwei Arten von Kacheln zusammen: Belegte Kacheln repräsentieren die Knoten
und der Raum dazwischen wird durch freie Kacheln repräsentiert.
Abbildung 4.7: Corner Stitching Datenstruktur
Die freien Kacheln werden dabei als maximale horizontale Streifen organisiert, was bedeutet,
dass sich links oder rechts einer freien Kachel niemals eine weitere freie, sondern immer
nur eine belegte oder keine Kachel befinden kann. Direkt oberhalb oder unterhalb davon
können sich jedoch ohne weiteres weitere freie Kacheln befinden. Dadurch ergibt sich für jede
Anordnung von belegten Kacheln (Knoten) eine einzige Möglichkeit der Zerlegung des freien
Raumes in freie Kacheln. Die Organisation der maximalen horizontalen Streifen ist dabei
grundlegend für die Effizienz der Struktur und der darauf operierenden Algorithmen. Die
belegten Kacheln unterscheiden sich dabei von den freien nur in der Tatsache, dass sie belegt
sind, ansonsten werden die beiden Kachelarten genau gleich repräsentiert und behandelt.
Die Kacheln werden durch eine Reihe von Zeigern, den sogenannten Corner Stitches, miteinander verbunden. Dabei besitzt jede Kachel an jeder ihrer vier Ecken je zwei Zeiger zu ihren
Nachbarn, insgesamt also acht Zeiger, wie Abbildung 4.8 illustriert. Die Zeiger werden dabei
anhand ihrer Position mit den in der Abbildung gezeigten Namen benannt.
Abbildung 4.8: Repräsentation der Nachbarschaftsbeziehungen zwischen den Kacheln
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
50
Die Operationen auf der Corner Stitching Struktur zeichnen sich dadurch aus, dass sie alle immer nur auf Informationen aus ihrer lokalen Umgebung angewiesen sind, wodurch sich
die Grösse des gesamten Modells nicht negativ auf Laufzeit der Algorithmen auswirkt. Die
Algorithmen haben dadurch in den meisten Fällen auch eine zur Anzahl der involvierten Kacheln lineare Laufzeit. Für die Linienführung von grösster Bedeutung sind dabei die folgenden
Algorithmen, auf deren Realisierung in Kapitel 5 eingegangen wird:
• Finden der Kachel an einer bestimmten Position
Eine häufig benötigte Operation ist das Auffinden einer Kachel an einer bestimmten
Position (angegeben durch deren Koordinaten). Dies ist sowohl für belegte Kacheln
(d.h. das Auffinden eines Knoten an einer bestimmten Position) als auch für freie Kacheln möglich. Ein Beispiel einer solchen Operation könnte das Bestimmen des Knotens
sein, auf den der Mauszeiger momentan zeigt.
• Einfügen eines Knoten
Um die Corner Stitching Datenstruktur zu erstellen, werden die betroffenen Knoten (und
damit belegte Kacheln) nacheinander in die Struktur eingefügt. Da der Algorithmus
beim Einfügen nur auf lokale Informationen aus der direkten Umgebung angewiesen ist,
kann die Datenstruktur sehr schnell aufgebaut werden.
• Direkte Nachbarn finden
Mit Hilfe der Corner Stitches können alle Nachbarn einer Kachel auf einer oder allen
Seiten sehr schnell bestimmt werden. Dies ist erforderlich um sich bei der Linienführung
von Kachel zu Kachel durch das Modell zu bewegen.
Die Corner Stitching Datenstruktur ermöglicht auch die leichte Realisierung einer Reihe weiterer Algorithmen. Darunter z.B. einer Bereichssuche (d.h. das Auffinden aller Knoten innerhalb eines bestimmten Bereichs) oder der sogenannte Schneepflug, der beim Verschieben eines
Knotens auch alle Knoten, die dieser Verschiebung im Wege stehen, entsprechend verschiebt.
Mit dem Schneepflug ist es z.B. möglich den Platz, der dem Modell oder der Schaltung zur
Verfügung steht, zu verkleinern und dabei die Beziehungen der Kachlen untereinander zu erhalten. Da diese Algorithmen für die Linienführung jedoch nicht von Bedeutung sind, werden
sie nicht vertieft behandelt.
Der Grund für die Entwicklung der Corner Stitching Datenstruktur bestand darin, eine Technik zu entwickeln, die eine effiziente Speicherung aller Schaltungselemente ermöglicht. Da sich
integrierte Schaltungen aus mehreren Millionen Elementen zusammensetzen können [Ous85],
ist es für Werkzeuge in diesem Bereich unmöglich immer alle Elemente im Speicher zu halten.
Mit Hilfe der Corner Stitches ist es kein Problem, alle Elemente z.B. in einer Datenbank
zu bestimmen, die im Moment auf dem Bildschirm angezeigt werden sollen, ohne dabei jedesmal alle Elemente zu durchlaufen. Bei der Anwendung der Corner Stitching Struktur
auf Adora-Modelle stellt jedoch nicht eine grosse Anzahl von Elementen, sondern fehlende Nachbarschaftsbeziehungen und fehlendes Wissen über den freien Raum im Modell das
Hauptproblem dar.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
4.3.2
51
Entkopplung der eigentlichen Linienführung vom Finden eines geeigneten Pfades
Da durch die Corner Stitching Datenstruktur der freie Raum zwischen den Knoten explizit
durch Rechtecke repräsentiert wird, lässt sich das Problem der Linienführung in zwei getrennte
Aufgaben aufteilen. Der erste Schritt besteht darin, einen aus freien Kacheln bestehenden Pfad
zu finen, der den Start- und Endpunkt der Linie verbindet und damit den Bereich, in dem die
Linie verlaufen kann, vorgibt. Dieser Vorgang wird im Bereich der integrierten Schaltungen
als Channel Finding bezeichnet. In Abbildung 4.9 sind die freien Kacheln, aus denen sich der
Pfad zur Verbindung3 der Punkte A und B zusammensetzt, grau hinterlegt dargestellt. Da
dieser Algorithmus auf den Kacheln der Corner Stitching Struktur operiert, wird der Ansatz
im Folgenden als kachelbasierte Linienführung bezeichnet.
Abbildung 4.9: Pfad aus freien Kacheln
Wie genau (z.B. möglichst direkt oder orthogonal) die Linie innerhalb dieses Bereiches geführt
wird, bleibt einem zweiten Algorithmus überlassen. Dadurch kann die Komplexität der Realisierung dieses zweiten Algorithmus bedeutend reduziert werden und er kann leicht ausgetauscht werden.
Finden eines geeigneten Pfades
Für das Finden eines geeigneten Pfades bestehend aus freien Kacheln kommt dabei ein Algorithmus, der in den Grundzügen dem Ansatz von Dion und Mornier [Dio95] folgt, zum Einsatz. Die grundlegende Idee besteht wie beim Algorithmus von Lee (vgl. dazu Abschnitt 3.2.1)
darin, vom Startpunkt aus jeweils alle benachbarten Zellen bzw. Kacheln wellenförmig mit
einem Kostenwert zu belegen und dann in einem zweiten Schritt anhand dieser Kostenwerte
den kürzesten Pfad zu bestimmen.
Im Gegensatz zum Algorithmus von Lee, der auf einem Gitter mit uniformen (d.h. gleich
grossen quadratischen) Zellen operiert, haben die freien Kacheln der Corner Stitching Struktur unterschiedliche Grössen und damit auch nicht immer die gleiche Anzahl an Nachbarn.
3
Im Folgenden wird davon ausgegangen, dass die Positionen von Start- und Endpunkt der Linien als Teil
der Sekundärnotation durch den Benutzer fest vorgegeben sind.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
52
Abbildung 4.10 illustriert den Unterschied zwischen einer uniformen Gitterstruktur, wie sie
beim Algorithmus von Lee zum Einsatz kommt, und der auf Kacheln basierenden Corner
Stitching Struktur. Dadurch dass bei einer uniformen Gitterstruktur alle Zellen die gleiche
Grösse haben, besteht die von Neumann-Nachbarschaft (ausser am Rand der Struktur) immer aus vier Zellen. Bei der Kachel-basierten Struktur fällt die Nachbarschaft einer Kachel
je nach ihrer Grösse und der Grösse der Nachbarn unterschiedlich aus. Die unterschiedlichen
Nachbarschaftsbeziehungen werden in Abbildung 4.10 durch Pfeile dargestellt. Dabei handelt
es sich im Falle der Corner Stitching Struktur (Abbildung 4.10b) nicht um die Corner Stitches, die die Kacheln zusammenhalten, sondern bloss um eine Darstelltung aller Nachbarn
der Kachel.
Abbildung 4.10: Uniforme Zellen / Kacheln der Corner Stitching Struktur
Dadurch lässt sich eine der grundlegenden Ideen des Algorithmus von Lee, die vier Nachbarn
einer Zelle ausgehend von der Zelle, die den Startpunkt enthält, jeweils mit dem Wert der
Manhattan-Distanz4 zur Startzelle zu belegen, nicht direkt anwenden, da durch die unterschiedliche Anzahl von Nachbarn bei der Corner Stitching Struktur mehrere Werte für eine
einzelne Kachel möglich sind. Dieses Problem lässt sich ebenfalls durch Abbildung 4.10b veranschaulichen: Je nachdem, ob der Wert für Kachel E aus den Werten von Kacheln C, D oder
F berechnet wird, kommt ein anderer Wert zustande. Bei einer uniformen Gitterstruktur kann
dieses Problem, wie sich leicht nachvollziehen lässt, nicht auftreten.
Da sich bei der Corner Stitching Struktur nicht für jede Kachel ein eindeutiger Wert berechnen
lässt, ist ein anderer Ansatz nötig. Dion und Mornier [Dio95] schlagen deshalb vor, die für die
Linienführung benötigten Distanzwerte5 zwischen den Kacheln nicht in der Struktur selbst,
sondern für jeden möglichen Pfad separat abzulegen. Als erstes stellt sich dabei jedoch die
Frage, wie diese Distanzwerte berechnet werden können.
Wie beim Algorithmus von Lee werden jeweils die Distanzwerte ausgehend von einer Kachel
für alle deren Nachbarn berechnet. In Abbildung 4.11 soll vom Startpunkt S aus ein Pfad
berechnet werden, wobei die Position des Endpunktes in diesem Zusammenhang noch keine
Rolle spielt und dieser deshalb in der Abbildung auch nicht erscheint. Die Startkachel ist in
4
Der Begriff der Manhattan-Distanz ist vom Bild rechteckig angelegter Strassenzügen in amerikanischen
Grossstädten abgeleitet. Die Manhattan-Distanz misst dabei nicht die Distanz, die durch die Luftlinie zwischen
zwei Punkten angegeben wird (Euklidische Distanz), sondern die Distanz, die durch das Entlanggehen an den
Strassenzügen zurückgelegt wird. Dafür werden auch die Begriffe der City-Block-Distanz oder TaxifahrerDistanz verwendet. Im zweidimensionalen Raum definiert sich die Manhattan-Distanz zwischen zwei Punkten
P und Q folgendermassen: M (P, Q) = |xP − xQ | + |yP − yQ |
5
Unter Distanz oder Distanzwert ist im Folgenden immer die Manhattan-Distanz bzw. deren Wert zu
verstehen.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
53
diesem Fall Kachel A, da die Linie nur in dieser freien Kachel beginnen kann. Vom Startpunkt
aus werden jetzt die Distanzwerte zu den Nachbarn B, C und D und damit die Kosten für eine
Linie vom Startpunkt S durch Kachel A zu diesen Nachbarnkacheln berechnet. Da die Kacheln
der Corner Stitching Struktur unterschiedliche Grössen haben, kann der Distanzwert nicht,
wie beim Algorithmus von Lee für die ganze Zelle, sondern nur für einen bestimmten Punkt
innerhalb der Kachel gelten. Der Punkt, an dem der Distanzwert für eine Kachel berechnet
wird, wird im Folgenden als Kostenpunkt bezeichnet. Die Kostenpunkte für die Kacheln D, B
und C sind in Abbildung 4.11 mit K1, K2 und K3 bezeichnet. Die Position der Kostenpunkte
leitet sich dabei aus der Position des Startpunktes S ab. Die von S ausgehenden Pfeile6 in
Abbildung 4.11 zeigen die kürzesten Wege, über die die Nachbarkacheln B, C und D von S aus
erreicht werden können. Die Kostenpunkte K1, K2 und K3 entsprechen dabei den Punkten,
bei denen diese Pfeile auf die Kacheln treffen. Der Kostenpunkt einer benachbarten Kachel
entspricht damit dem Punkt innerhalb dieser Kachel, der gegenüber dem Kostenpunkt der
aktuellen Kachel (S für Kachel A) die geringste euklidische Distanz aufweist.
Für diese Kostenpunkte in den benachbarten Kacheln wird nun die Manhattan-Distanz zwischen dem Kostenpunkt dieser Nachbarnkacheln und dem Kostenpunkt der aktuellen Kachel berechnet. In Abbildung 4.11 werden also drei Distanzwerte berechnet: Die ManhattanDistanz zwischen S und K1, S und K2 sowie S und K3.
Abbildung 4.11: Berechnung der Distanzwerte
Diese Distanzwerte werden in einem Pfad abgelegt. Dabei handelt es sich um eine Datenstruktur die folgende Elemente enthält:
• Einen Zeiger auf die Endkachel, mit der der Pfad endet.
• Einen Zeiger auf den Elternpfad. Im Pfad selbst sind immer nur die Informationen für
den letzten Teil des Pfades enthalten, d.h. den Pfad von der letzten Kachel bzw. deren
Kostenpunkt zur aktuellen Kachel (der Endkachel). Wird jeweils den Zeigern auf den
Elternpfad gefolgt, so lässt sich der gesamte Pfad bis zum Startpunkt rekonstruieren.
• Die Position des Kostenpunktes innerhalb der Endkachel, an der der Distanzwert
berechnet wurde.
6
Diese Pfeile haben nichts mit der späteren Linienführung zu tun, sondern sollen nur veranschaulichen, wie
die Kostenpunkte berechnet werden.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
54
• Die Manhattan-Distanz vom Kostenpunkt über die Kostenpunkte aller Elternpfade
zum Startpunkt. Der Distanzwert berechnet sich damit durch die Summe des Distanzwertes des Elternpfades und der Manhattan-Distanz zwischen dem Kostenpunkt des
Elternpfades und dem aktuellen Kostenpunkt.
Abbildung 4.12: Beziehung zwischen Pfaden und ihren Elternpfaden
Anhand von Abbildung 4.12 soll die Beziehung zwischen Pfaden und ihren Elternpfaden
verdeutlicht werden. Dabei soll eine Linie vom Startpunkt S zum Endpunkt E geführt werden.
Der erste Pfad enthält dabei Kachel A als Endkachel, den Startpunkt S als Kostenpunkt und
damit einen Distanzwert von 0, da der Kostenpunkt der ersten Kachel dem Startpunkt der
Linie entspricht. Von Kachel A aus sind nun drei weitere Pfade möglich, nämlich zu den
Kacheln B, C und D. Diese neuen Pfade erhalten den ersten Pfad als Elternpfad, die Punkte
K1, K2 oder K3 als Kostenpunkt und die jeweiligen Distanzen zwischen K1, K2 oder K3
und S (dem Kostenpunkt des Elternpfades) als Distanzwerte. Mit den Endkacheln B, C und
D wird danach analog zu Kachel A verfahren. Ein Pfad wird nicht weiter verfolgt, wenn er
auf eine Kachel trifft, die er bereits enthält. Die verschiedenen Pfade bilden dadurch eine
Baumstruktur, wodurch sich trotz der grossen Anzahl an Pfaden der benötigte Speicherplatz
in Grenzen hält. Diese Baumstruktur für Abbildung 4.12 ist in Abbildung 4.13 abgebildet.
Abbildung 4.13: Pfadstruktur
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
55
Alle Pfade werden entsprechend ihres Distanzwertes sortiert in einer Heap-Datenstruktur
[Wil64] gehalten, wodurch die Abfrage des nächsten Pfades aus dem Heap jeweils den Pfad
mit dem geringsten Distanzwert liefert. Nachdem alle Pfade zu den Nachbarn einer Kachel
berechnet und in den Heap eingefügt wurden, wird der Pfad mit dem niedrigsten Distanzwert
aus dem Heap entnommen und dessen Nachbarn verarbeitet. Wird ein Pfad, dessen Endkachel
der Endkachel der Linie (d.h. der freien Kachel die den Endpunkt enthält) entspricht, aus
dem Heap entnommen, so wird der Vorgang abgebrochen, da damit ein Pfad vom Startzum Endpunkt gefunden wurde. Da der Pfad den gesamten Weg vom Start- zum Endpunkt
enthält, entfällt auch das Zurückverfolgen, wie es beim Algorithmus von Lee nötig ist.
Da für alle Nachbarn einer Kachel jeweils ein neuer Pfad erzeugt wird, explodiert die Anzahl der Pfade kombinatorisch mit der Anzahl Kacheln. Diese explosionsartige Zunahme der
Pfade stellt jedoch aus folgenden Gründen kein Problem dar: Erstens hält sich die Anzahl
der Kacheln im gesamten Modell dank der Corner Stitching Struktur in Grenzen7 . Zweitens
werden Pfade nicht weiterverfolgt, wenn sie auf eine Kachel treffen, die sie bereits enthalten.
Und Drittens werden durch die Sortierung der Pfade im Heap entartete Pfade (d.h. Pfade mit
einem sehr hohen Distanzwert) nicht mehr aus dem Heap entnommen und damit auch nicht
weiterverfolgt.
Die Anzahl der Pfade liesse sich noch weiter reduzieren, indem neben der Distanz zum Startpunkt auch die Distanz zum Endpunkt der Linie in den Distanzwert des Pfades einfliesst.
Damit wird der Distanzwert geringer, je näher zum Ziel der Pfad kommt. Da der Pfad mit
dem geringsten Distanzwert zuerst aus dem Heap entnommen wird, werden als erstes die
Pfade weiterverfolgt, die bereits in der Nähe des Ziels angekommen sind. Das Finden eines
geeigneten Pfades geht dabei von einer Breiten- zu einer Tiefensuche über. Bei diesem Vorgehen ist es jedoch nicht mehr möglich, alle bezüglich der Distanz optimalen Pfade zu finden,
wie dies im nächsten Abschnitt beschrieben wird.
Da die Distanzwerte durch die Manhattan-Distanz zwischen den verschiedenen Kostenpunkten berechnet werden, ist es möglich, dass mehrere Pfade die gleiche (kürzeste) Länge aufweisen und damit für die Linienführung in Frage kommen. Abbildung 4.14 zeigt ein solches
Beispiel in dem zwei Pfade beim Endpunkt E die gleiche Distanz zum Startpunkt S aufweisen.
Abbildung 4.14: Mehrere gleich lange Pfade
7
Bei n Knoten in einem Modell besteht die Corner Stitching Struktur aus maximal 4n + 1 Kacheln. [Ous84]
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
56
Der beschriebene Algorithmus ist in der Lage alle optimalen (d.h. kürzesten) Lösungen zu
liefern. In Abbildung 4.14 wird zuerst der mit den Kostenpunkten A bezeichnete Pfad verfolgt, da dessen Distanzwerte geringer sind als die des zweiten Weges. Wird jedoch der letzte
Abschnitt des Pfades (d.h. der Teil zwischen A2 und E) berechnet, so entspricht der Distanzwert der gesamten Manhattan-Distanz zwischen S und E. Der Algorithmus bricht jedoch in
diesem Fall nicht ab, obwohl der Pfad die Endkachel der Linie als Endkachel enthält, sondern
legt den Pfad im Heap ab. Nun ist aber die Manhattan-Distanz zwischen S und B1 geringer
als die Manhattan-Distanz zwischen S und E und der zweite Pfad wird berechnet. Erst wenn
auch dieser Pfad den Endpunkt erreicht hat, wird einer der beiden kompletten Pfade aus dem
Heap entnommen und danach der Vorgang abgebrochen. Die übrigen Lösungen liegen dann
alle an der Spitze des Heaps und können leicht entnommen werden. Somit ist der Algorithmus
in der Lage alle bezüglich der Distanz optimalen Lösungen zu liefern, wobei es dem eigentlichen Linienführungsalgorithmus überlassen bleibt, anhand eigener Kriterien eine davon für
die Linienführung auszuwählen.
Linienführung
Für die eigentliche Linienführung innerhalb des aus freien Kacheln bestehenden Pfades, sind
verschieden Ansätze denkbar. Abbildung 4.15 zeigt drei davon. Da bekannt ist, wo der Pfad
durchführt und wieviel freier Raum für die Linie zur Verfügung steht, weisen Realisierungen
der dazu benötigten Algorithmen keine hohe Komplexität auf. Abschnitt 5.3 geht auf eine
mögliche Realisierungen ein.
Abbildung 4.15: Verschiedene Möglichkeiten der Linienführung in einem Pfad
4.3.3
Sekundärnotation
Die Corner Stitching Datenstruktur lässt sich neben der Linienführung auch für die Erhaltung der Sekundärnotation einer Linie nutzen. Die Sekundärnotation einer Linie ist, wie in
Abschnitt 2.3.1 beschrieben, von der Position der Knoten, zwischen denen die Linie hindurchführt, abhängig. Da dank der Corner Stitching Struktur für alle freien Kacheln, durch
die eine Linie hindurchfüren muss, jeweils die benachbarten Knoten bzw. belegten Kacheln bekannt sind, lässt sich die Struktur zur Erhaltung der Sekundärnotation nutzen. Abbildung 4.16
illustriert das Vorgehen hierzu anhand einer orthogonalen Linienführung. Es ist jedoch ebenso
auf die anderen Ansätze anwendbar, sofern diese Änderungen durch den Benutzer und damit
eine Sekundärnotation vorsehen.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
57
Abbildung 4.16: Erhaltung der Sekundärnotation durch die Corner Stitching Struktur
Durch die expliziten Nachbarschaftsbeziehungen lässt sich in Abbildung 4.16a leicht das
Rechteck berechnen, das den Bereich zwischen den Knoten A und B angibt, in dem sich
das entsprechende vertikale Segment der Linie befinden muss. Dieses in Abbildung 4.16a
dunkelgrau hinterlegte Rechteck kann dabei für verschieden Zwecke genutzt werden:
• Das Rechteck gibt an, wieweit der Benutzer das entsprechende Liniensegment verschieben und damit die Sekundärnotation definieren kann.
• Die relative horizontale Position der Linie innerhalb des Rechtecks definiert die Sekundärnotation, die auch bei Veränderungen des Layouts erhalten bleiben muss. Wird
wie in Abbildung 4.16b das Layout durch die Vergröberung von Knoten B verändert,
so kann die relative horizontale Position des Liniensegments aus Abbildung 4.16a innerhalb dieses Rechtecks beibehalten werden. Dazu wird die Linie erst komplett neu
geführt und dann entsprechend der Sekundärnotation (d.h. der relativen Position innerhalb des Rechtecks) angepasst. Das Vorgehen muss dabei auf alle horizontalen und
vertikalen Segmente einer Linie angewandt werden.
• Das Rechteck lässt sich zusätzlich auch noch für die Auflösung von Linienüberlappungen
nutzen, da es angibt wie weit eine Linie für eine solche Auflösung maximal verschoben
werden kann. Auf das Vorghen hierzu geht der nächste Abschnitt detaillierter ein.
Grundsätzlich wäre mit dem kachelbasierten Ansatz auch eine grössere Einflussnahme durch
den Benutzer möglich, indem dieser z.B. freie Kacheln angeben könnte, durch welche die Linie
dann hindurchgeführt wird, oder die Linie sogar frei durch den freien Raum hindurchführen.
Bleibt die Corner Stitching Struktur nach einer Veränderung des Layouts durch eine LayoutOperation weitgehend erhalten (d.h. es ändern sich in erster Linie die Grössen der Kacheln),
so könnte nach der Layoutänderung die Linie an die veränderten Kacheln angepasst werden,
ohne sie komplett neu zu führen. Ein solcher Ansatz lässt sich jedoch für Adora-Modelle im
Moment nicht umsetzten, da der Zoom-Algorithmus in bestimmten Situationen das Layout
so stark verändert, das die bisherige Linienführung umöglich wird und ein komplett neuer
Pfad durch das Modell hindurch gesucht werden muss. Muss die Linie komplett neu geführt
werden, so geht die Sekundärnotation verloren, womit es keinen Sinn macht, dem Benutzer
einen grossen Einfluss auf die Linienführung zu überlassen, wenn diese Änderungen bei der
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
58
ersten Anwendung des Zoom-Algorithmus alle verloren gehen. Aus diesem Grund beruht der
kachelbasierte Ansatz auf einer automatischen Linienführung. Mit Hilfe der Corner Stitching
sind jedoch auch andere Ansätze möglich, sofern die Layout-Operationen die Erhaltung des
Layouts in einem bestimmten Rahmen garantieren können.
4.3.4
Linienüberlappungen und -überscheidungen
Werden die Linien um die Hindernisse herumgeführt ohne dabei auf bestehnde Linien Rücksicht zu nehmen, so kommt es zu Überschneidungen und Überlappungen zwischen verschiedenen Linien. Unter Überschneidungen sind dabei Situationen zu verstehen, bei der sich zwei
Linien in einem Punkt kreuzen. Bei Überlappungen kommen die Linien in einem bestimmten
Bereich aufeinander zu liegen. Überlappungen stellen dabei das grössere Problem dar, da die
beiden Linien optisch nicht mehr voneinander unterschieden werden können. Im Folgenden
soll deshalb in erster Linie die Auflösung von Überlappungen und nicht von Überschneidungen behandelt werden. Abbildung 4.17a illustriert eine solche Überlappung zweier Linien. Die
Linien zwischen A und D und zwischen B und C kommen in einem bestimmten Bereich aufeinander zu liegen. Das Problem kann zwar bei allen Ansätzen der Linienführung auftreten,
gewisse Ansätze, wie z.B. der orthogonale sind jedoch anfälliger dafür. Im Folgenden werden nur Vorgehensweisen betrachtet, die keine bestehenden Linien verlegen, sondern nur die
neue Linie an bereits bestehende Linien anpassen. Werden beim Hinzufügen einer neuen Linie
bestehende Linien verschoben, so leidet zum einen die Sekundärnotation darunter und zum
anderen kann es zu einer Kettenreaktion kommen, wodurch eine grosse Anzahl der Linien
verschoben werden muss. Um Überlappungen zu verhindern, kommen im Wesentlichen zwei
Möglichkeiten in Frage.
Abbildung 4.17: Möglichkeiten zur Auflösung von Linienüberscheidungen
Bei der ersten Möglichkeit wird die Corner Stitching Datenstruktur um eine dritte Kachelart
erweitert: die Linienkacheln. Diese stellen im Gegensatz zu den belegten Kacheln für die Linienführung keine unüberwindbaren Hindernisse dar, ihre Durchquerung wird jedoch erschwert,
indem der Distanzwert mit einem konstanten Wert multipliziert wird. Dadurch werden solche Linienkacheln für die Linienführung weniger attraktiv, da sie höhere Kosten aufweisen.
Durch dieses Vorgehen lassen sich sowohl Überlappungen von Linien als auch Überschneidungen zwischen Linien minimieren. Abbildung 4.17b veranschaulicht dieses Vorgehen. Bei einem
solchen Vorgehen tauchen jedoch zwei wesentliche Probleme auf: erstens wird die Realisierung der Operationen auf der Corner Stitching Struktur bedeutend komplexer. So kommen,
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
59
falls es, wie in Abbildung 4.17b, zu einer Kreuzung von Linien kommt, Linienkacheln innerhalb von anderen Linienkacheln zu liegen, was durch das Aufsplitten einer der Linienkacheln
verhindert werden muss. Und zweitens kann die Linienführung für den Benutzer nur noch
schwer nachvollziebar werden, da die Linien plötzlich und für den Benutzer ohne einsichtigen
Grund komplett anders geführt werden. So werden, falls in Abbildung 4.17b noch weitere
Linien zwischen A und D hinzugefügt werden, diese ab einer gewissen Anzahl um die Knoten
B oder C herumgeführt, da der direkte Weg durch die bereits bestehenden Linien zu teuer
wird. Dies minimiert zwar die Überschneidungen und Überlappungen der Linien ist jedoch für
einen Benutzer ohne Kenntnis dieser Vorgänge kaum nachvollziebar. Dabei handelt es sich um
ein generelles Problem aller globalen Ansätze der Linienführung (d.h. der Ansätze, die beim
Hinzufügen von neuen Linien alle bestehenden Linien in die Linienführung miteinbeziehen).
Die Linienführung verhält sich bei solchen Ansätzen nicht mehr stetig, d.h. kleinste Veränderungen am Layout oder einer Linie können einen bedeutenden und nicht nachvollziebaren
Einfluss auf das Layout haben.
Die zweite Möglichkeit besteht darin, die Corner Stitching Struktur nicht zu verändern und
damit beim Finden eines geeigneten Pfades die übrigen Linien zu vernachlässigen. Erst bei
der eigentlichen Linienführung (d.h. beim Hindurchführen der Linie durch den aus freien Kacheln bestehenden Pfad) werden Überlappungen nachträglich aufgelöst. Dazu ist es nötig, die
Segmente der neuen Linie auf Überlappungen mit den Segmenten bestehender Linien zu überprüfen und im Fall einer Überlappung das entsprechende Segment der neuen Linie zu verschieben. Abbildung 4.17c illustriert dieses Vorgehen. Das dunkelgrau hinterlegte Rechteck gibt
dabei den Bereich an, indem sich das Segment bewegen kann und entspricht dem Rechteck,
das auch für die Erhaltung der Sekundärnotation zum Einsatz kommt. Bei diesem Vorgehen
werden in erster Linie Linien verschoben, deren Segment in einem gewissen Bereich aufeinander liegen und es wird nicht die Anzahl der Schnittpunkte zwischen den Linien minimiert.
Ab einer genügend hohen Anzahl von Linien, die durch einen engen Bereich hindurchführen,
kommen die Linien auch wieder aufeinander zu liegen, was jedoch durch den Benutzer durch
das Verschieben von Knoten und Linien verhindert werden kann. Diese Möglichkeit überlässt
damit einen Teil der Verantwortung für das Verhindern von Linienüberschneidungen dem
Benutzer und gesteht diesem damit auch einen grösseren Einfluss zu.
4.3.5
Beurteilung
Bei der beschriebenen kachelbasierten Linienführung handelt es sich um einen echten RoutingAlgorithmus, d.h. der Algorithmus findet in jedem noch so komplizierten Layout den kürzesten
Weg, sofern mindestens ein Weg existiert. Er ist deshalb bei der Anwendung nicht auf bestimmte Layouts oder Konstellationen beschränkt. Dadurch dass die verschiedenen Schritte
für die Linienführung einzeln realisiert und getestet werden können, halten sich auch die
Komplexität und damit der Aufwand der Realisierung in Grenzen.
Adora-Modelle unterscheiden sich vom Entwurf integrierter Schaltungen durch eine kleinere
Anzahl von Knoten. Diese Knoten sind in der Regel jedoch bedeutend grösser und haben die
unterschiedlichsten Ausdehnungen. Die Corner Stitching Struktur kommt diesem Umstand
entgegen, da ihre Komplexität von der Anzahl der Knoten und nicht von der Ausdehnung
des Gesamtmodells abhängt. Bei einer uniforme Gitterstruktur, wie sie z.B. beim Algorithmus von Lee zum Einsatz kommt, darf die Zellengrösse und damit die Auflösung des Gitters
die minimale Distanz zwischen zwei Knoten nicht unterschreiten, da sonst keine Linie mehr
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
60
zwischen diesen Knoten hindurchgeführt werden kann. Dadurch explodiert bei einem grossen
Modell die Anzahl der Zellen und die Algorithmen kommen für eine interaktive Nutzung nicht
in Frage. Die Corner Stitching Struktur jedoch lässt sich sehr schnell erstellen und kann trotzdem mit einer sehr grossen Anzahl von Knoten umgehen. So sind im Bereich der integrierten
Schaltungen mehrere Millionen Knoten keine Seltenheit [Ous85]. Weil sich die Anzahl der
Kacheln in Grenzen hält, weisen auch die Algorithmen zur Linienführung Laufzeiten auf, die
eine interaktive Nutzung ermöglichen.
Zusätzlich zum Problem der Linienüberschneidungen stellt sich bei der Linienführung noch
das Problem der Überlappungen von Linienbeschriftungen oder von Linienbeschriftungen und
Knoten. Liegen der Beschriftungen verschiedener Linien übereinander, so sind sie nicht mehr
lesbar. Die Linienbeschriftungen müssen deshalb so platziert werden, dass es zu keinen oder
möglichst wenige Überlappungen kommt. Das Problem weist dabei Ähnlichkeiten zum Problem der Linienüberschneidungen auf, wodurch auch ähnliche Ansätze zur Lösung denkbar
sind (vgl. dazu Abschnitt 4.3.4). Da durch die Corner Stitching Struktur für jedes Segment
einer Linie bekannt oder leicht herauszufinden ist, wieviel freier Raum sich darum herum
befindet, kann bei der Platzierung der Linienbeschriftungen auf diese Information zurückgegriffen werden.
Gegenüber den anderen vorgestellten Ansätze weist der Ansatz der kachelbasierten Linienführung im Wesentlichen die folgenden Vorteile auf:
• Der Ansatz bietet einen echten Routing-Algorithmus, der in jedem Fall einen Pfad findet, falls einer existiert. Eine solche universelle Anwendbarkeit können die anderen
Ansätze nicht bieten.
• Bei der kachelbasierten Linienführung wird das Finden eines geeigneten Pfades
von der eigentlichen Linienführung entkoppelt. Dadurch sind verschiedene Arten
der Linienführung (z.B. möglichst direkt oder orthogonal) auf dem gleichen Fundament
aufbauend realisierbar. Eine neue Linienführung lässt sich dabei leicht realisieren, da
der grösste Teil des Problems getrennt davon bereits gelöst ist.
• Die Linienführung wird bei diesem Ansatz von den Layout-Operationen (wie z.B. dem
Zoom-Algorithmus) entkoppelt. Die Linienführung ist dabei nicht von den LayoutOperationen abhängig und neue Layout-Operationen lassen sich ohne Änderungen an
der Linienführung realisieren.
• Die kachelbasierte Linienführung weist eine Laufzeit auf, die eine interaktive Nutzung
in einem Werkzeug ermöglicht.
• Neben der eigentlichen Linienführung ermöglicht der Ansatz auch Vorgehensweisen zur
Erhaltung der Sekundärnotation einer Linie und z.B. auch zum Platzieren der
Linienbeschriftungen.
Im Weiteren wird deshalb nur dieser Ansatz der kachelbasierten Linienführung weiter verfolgt.
Die anderen Ansätze werden aufgrund der grundsätzlichen Probleme, die sie mit sich bringen,
nicht weiter verfolgt.
KAPITEL 4. LINIENFÜHRUNG IN EINEM DYNAMISCHEN LAYOUT
4.3.6
61
Weitere Anwendungsmöglichkeiten für die Datenstruktur
Die Corner Stitching Struktur kann nicht nur für die Linienführung sondern für alle Layoutoperationen, die auf Informationen über den freien Raum zwischen den Knoten oder über
Nachbarschaftsbeziehungen im Layout angewiesen sind. So muss z.B. der Zoom-Algorithmus
in der jetztigen Form Okklusionen zwischen Knoten zuerst entdecken und dann auflösen.
Operiert der Zoom-Algorithmus jedoch auf einer Corner Stitching Struktur, so ist für jeden
Knoten bereits zum Voraus klar, wie weit er verschoben werden kann, da der dafür benötigte
freie Raum explizit in der Struktur repräsentiert ist.
Kapitel 5
Realisierung des
Linienführungsalgorithmus
Wurden im vorhergehenden Kapitel die grundlegende Idee hinter der Kachel-basierten Linienführung und das Vorgehen dazu eingeführt, so bieten die folgenden Abschnitte einen
detaillierteren Einblick in die dazu benötigen Algorithmen. Darunter fallen sowohl solche
zur Erstellung und Verwaltung der Corner Stitching Datenstruktur als auch die eigentlichen
Linienführungsalgorithmen.
5.1
Datenstruktur: Corner Stitching
Da die Corner Stitching Struktur für alle folgenden Algorithmen von grundlegender Bedeutung ist, wird zuerst auf diese Datenstruktur eingegangen. Die Ausführungen folgen dabei in
weiten Teilen der Orginalpublikation von Ousterhout [Ous84]. Da die Datenstruktur mit den
Corner Stitches, wie in in Abschnitt 4.3.1 dargelegt, einen einfachen und leicht verständlichen
Aufbau besitzt, werden im Folgenden in erster Linie die darauf operierenden Algorithmen
erläutert.
5.1.1
Kachel an bestimmter Position lokalisieren
Eine der häufigsten geometrischen Operationen auf einem Adora-Modell ist das Lokalisieren
des Knotens der sich an einer bestimmten Position (angegeben durch deren Koordinaten)
befindet. Diese Operation muss z.B. bei jeder Bewegung des Mauszeigers durchgeführt werden,
um zu bestimmen in welchem Knoten sich dieser im Augenblick befindet. Normalerweise
werden dazu alle Knoten einer Liste sequentiell durchlaufen und jeweils darauf überprüft, ob
sich die Koordination des gesuchten Punktes innerhalb des Knotens befinden. Hält sich die
Anzahl der Knoten in Grenzen, so stellt dieses Vorgehen trotz seiner Ineffizienz kein Problem
dar.
Die Corner Stitching Struktur ermöglicht jedoch die Anwendung eines ausgereifteren Algorithmus, der für jeden beliebigen Punkt die Kachel liefert, in der dieser Punkt enthalten ist.
Dabei kann es sich sowohl um eine belegte Kachel (d.h. einen Knoten) als auch eine freie
62
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
63
Kachel handeln. Der Algorithmus kann dabei von jeder beliebigen Kachel aus mit seiner Arbeit beginnen. Bei der Anwendung auf die Adora-Modelle startet der Algorithmus jedoch
normalerweise aus der (freien oder belegten) Kachel, die sich in der linken oberen Ecke des
Modells befindet. Der Algorithmus setzt sich dabei aus folgenden Schritten zusammen:
1. Zuerst folgt der Algorithmus den Corner Stitches, die auf den oberen oder unteren
Nachbarn einer Kachel zeigen (lt und lb in Abbildung 4.8 auf Seite 49), bis er auf eine
Kachel trifft, deren vertikales Intervall die vertikale Position des Punktes enthält.
2. Von dieser Kachel aus folgt der Algorithmus solange den Corner Stitches zu den linken
und rechten Nachbarn (tl und tr in Abbildung 4.8 auf Seite 49) bis er auf eine Kachel
trifft, deren horizontales Intervall die horizontale Position des Punktes enthält.
3. Bei diesem Vorgang kann es dazu kommen, dass das vertikale Intervall der durch die
horizontale Suche (Schritt 2) gefundenen Kachel die vertikale Position des Punktes nicht
mehr enthält. Abbildung 5.1 illustriert dieses Problem: durch die Lage von Kachel F
springt der Algorithmus bei der horizontalen Suche in Kachel G. Die vertikale Position
des Punktes liegt jedoch nicht innnerhalb dieser Kachel. Deshalb müssen die Schritte 1
und 2 solange wiederholt werden, bis die Kachel gefunden wurde, die den Punkt auch
wirklich enthält.
Abbildung 5.1: Kachel an einem bestimmten Punkt lokalisieren
Im ungünstigsten Fall müssen bei diesem Vorgehen alle Kacheln der Struktur untersucht
√
werden. Im durchschnittlichen Fall sind jedoch bei n Kacheln nur gerade n Kacheln1 zu
durchsuchen, also deutlich weniger als beim sequentiellen Durchsuchen einer Liste, bei dem
durchschnittlich n2 Kacheln untersucht werden müssen. Der Algorithmus spielt seine Stärke
damit bei einer sehr grossen Anzahl von Kacheln aus, wie dies bei integrierten Schaltungen
normalerweise der Fall ist. Aufgrund der bedeutend geringeren Anzahl an Knoten und damit auch an Kacheln ist dieser Unterschied bezüglich der Laufzeit bei Adora-Modellen von
geringerer Bedeutung.
1
Eine ausführliche Diskussion hierzu findet sich in [Ous84].
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
5.1.2
64
Datenstruktur aufbauen
Bevor mit der Corner Stitching Datenstruktur gearbeitet werden kann, muss diese aufgebaut
werden. Zu Beginn besteht die gesamte Struktur aus einer einzigen freien Kacheln, die den
Bereich des gesamten Layouts einnimmt. In diese freie Kachel werden dann nacheinander alle
Knoten eingefügt. Da bei einem Adora-Modell die Knoten hierarchisch ineinander geschachtelt sind, wird die Corner Stitching Strukur immer innerhalb eines Knoten für alle Kinder
dieses Knotens erstellt. Da die Corner Stitching Struktur im vorliegenden Fall nur für die
Linienführung benutzt wird, wird die gesamte Struktur erst im Nachhinein, d.h. wenn das
gesamte Layout (Position und Grösse der Knoten) bereits festgelegt ist, erstellt. Beim Erstellen der Struktur kann deshalb immer von einem korrekten Layout, d.h. einem Layout ohne
Überlappungen zwischen Knoten, ausgegangen werden. Daher ist es auch nicht nötig vor dem
Einfügen eines Knoten zu überprüfen, ob der Knoten an dieser Stelle überhaupt eingefügt
werden kann, obwohl eine solche Überprüfung mit Hilfe der Corner Stitching Struktur leicht
möglich wäre. Abbildung 5.2 zeigt das Vorgehen beim Einfügen eines Knotens in eine Corner
Stitching Strukur. Dabei wird ein Knoten in eine Struktur eingefügt, die bereits andere Knoten enthält. Das Vorgehen beim Einfügen des ersten Knotens bleibt jedoch dasselbe, wobei
die Struktur vor dem Einfügen dann nur aus einer einzige freie Kachel besteht.
Abbildung 5.2: Knoten in die Corner Stitching Struktur einfügen
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
65
Der Algorithmus setzt sich aus folgenden Schritten zusammen:
1. Mit Hilfe des in Abschnitt 5.1.1 beschriebenen Algorithmus wird nach der freien Kachel
gesucht, die die obere linke Ecke (P1 in Abbildung 5.2a) des einzufügenden Knotens
enthält. Aufgrund der Organisation der Corner Stitching Struktur ist die gesamte obere
Kante des einzufügenden Knoten in einer einzigen freien Kachel enthalten.
2. Diese obere Kachel wird entlang einer horizontalen Linie, die durch die obere Kante
des einzufügenden Knotens verläuft, in zwei Kacheln aufgespaltet (Abbildung 5.2b).
Dabei müssen die Corner Stitches der beteiligten und benachbarten Kacheln angepasst
werden.
3. Mit Hilfe des in Abschnitt 5.1.1 beschriebenen Algorithmus wird nach der freien Kachel
gesucht, die die untere linke Ecke (P2 in Abbildung 5.2a) des einzufügenden Knotens
enthält.
4. Diese untere Kachel wird analog zu Schritt 2 aufgespalten und die Corner Stitches
angepasst (Abbildung 5.2b).
5. Ausgehend von der oberen Kante des neuen Knotens werden bis zu der unteren Kante
alle Kacheln durchlaufen. Dabei muss jede Kachel vertikal in zwei Kacheln aufgespaltet
werden: Eine Kachel rechts und eine Kachel links des neuen Knotens. Freie Kacheln
werden falls möglich vertikal zu einer einzelnen Kacheln verbunden. Dabei sind jeweils
die Corner Stitches aller beteiligten Kacheln anzupassen (Abbildung 5.2c).
Die Laufzeit des Algorithmus hängt vom Aufwand, der für das Aufspalten und Verbinden der
Kacheln benötigt wird, ab. Dieser wiederum ist abhängig von der Anzahl der zu bearbeitenden
Kacheln, d.h. von der Umgebung, in die der neue Knoten eingefügt werden soll. Normalerweise
läuft dieser Vorgang in konstanter Zeit ab, ist also nicht abhängig von der Anzahl der Knoten
im gesamten Modell. Eine genauere Diskussion des Aufwandes für das Einfügen von Knoten
in die Corner Stitching Struktur findet sich in der Orginalpublikation von Ousterhout [Ous85].
Das Entfernen von Knoten aus der Corner Stitching Struktur erfolgt invers zum oben beschriebenen Einfügen. Da jedoch bei der Linienführung die Struktur jedesmal, wenn sie
benötigt wird, “on-the-fly” erstellt wird, wird diese Operation im Zusammenhang mit der
Linienführung nicht benötigt.
Struktur speichern
Beim Aufbauen der Corner Stitching Struktur stellt sich die Frage, zu welchem Zeitpunkt
diese Struktur neu aufgebaut werden muss und ob und wie sie abgespeichert werden kann.
Da die Knoten eines Adora-Modells hierarchisch ineinander geschachtelt sind, besteht ein
erster Ansatz darin, für jeden Knoten eine Corner Stitching Struktur zu erstellen, die jeweils
dessen Kinder als belegte Kacheln enthält. Diese Struktur müsste nur einmal erstellt werden und könnte danach im Knoten gespeichert werden. Das Problem mit diesem Ansatz ist
aber, dass die Corner Stitching Struktur je nach Start- und Endknoten der betreffenden Linie
unterschiedlich ausfällt. Damit gibt es im Zusammenhang mit der Linienführung keine eindeutige Corner Stitching Struktur für jeden Knoten, die einmal erstellt und dann abgespeichert
werden kann. Abbildung 5.3 veranschaulicht dies:
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
66
Abbildung 5.3: Unterschiedliche Corner Stitching Strukturen innerhalb eines Knotens
Obwohl die Linie aus Abbildung 5.3a als auch in Abbildung 5.3b durch Knoten 1 hindurchführen, kommen in den beiden Fällen unterscheidliche Corner Stitching Strukturen zum
Einsatz. Der Unterschied kommt dadurch zu Stande, dass die beiden Linien aufgrund der
hierarchischen Einordnung ihrer Start- und Endknoten um unterschiedliche Hindernisse herumgeführt werden müssen. So stellt z.B. der Knoten 1.1.2 in Abbildung 5.3a für die Linie
ein Hindernis dar, in Abbildung 5.3b jedoch nicht, da er in diesem Fall innerhalb des Startknotens liegt. Der Aufbau der Corner Stitching ist damit nicht nur von den Kindern des
übergeordneten Knotens, sondern auch von der Linie selbst abhängig.
Aus diesem Grund ist es nicht sinnvoll, für jeden Knoten die entsprechende Corner Stitching
Struktur aufzubauen und diese im Knoten zu speichern. Zwar wäre es möglich, für jede Linie
die entsprechende Struktur zu speichern, um bei einer Anpassung der Linie infolge einer
Layoutveränderung darauf zurückgreifen zu können. Dabei wird es jedoch auch nötig, diese
Struktur bei einer Veränderung des Layouts (z.B. einer Positionsänderung eines Knotens)
anzupassen. Eine solche Anpassung kann sich aufwendig gestalten, da bestehende Kacheln
verschwinden und neue Kacheln hinzukommen können und eine grosse Anzahl von Corner
Stitches angepasset werden müssen. Da sich eine Struktur sehr schnell erstellen lässt, ist es in
der Regel einfacher, bei jeder Linienführung eine neue Corner Stitching Struktur zu erstellen
und diese auch nicht abzuspeichern.
5.1.3
Nachbarn bestimmen
Eine weitere häufig benötigte Operation ist das Auffinden aller Kacheln, die eine bestimmte Kachel auf einer bestimmten Seite berühren. Mit Hilfe der Corner Stitches ist es bei der
Corner Stitching Struktur ein Leichtes diese Nachbarn auszumachen, indem einfach den entsprechenden Corner Stitches gefolgt wird. Abbildung 5.4 auf Seite 67 veranschaulicht das
Vorgehen zum Auffinden aller Nachbarn, die Kachel A auf der rechten Seite berühren. Die
Bezeichnung der Corner Stitches entspricht dabei derjenigen aus Abbildung 4.8 auf Seite 49.
Die Suche beginnt dabei mit der Corner Stitch tr, die den rechten Nachbarn an der oberen
rechten Ecke von Kachel A angibt. Dieser Zeiger führt auch gleich zum ersten Nachbarn.
Danach wird jeweils den lb Corner Stitches gefolgt, bis die unterste Kachel erreicht wird. Die
unterste Kachel entspricht dabei der Kachel, die über br von der Kachel A aus erreichbar ist.
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
67
Abbildung 5.4: Auffinden aller Nachbarn einer Kachel
5.2
Geeigneten Pfad finden
Die grundlegende Funktionsweise des Algorithmus zum Finden eines geeigneten Pfades wurde
bereits in Abschnitt 4.3.2 erläutert. Im Folgenden wird dessen Vorgehen systematisch und
anhand eines Beispiels beschrieben. Der Algorithmus setzt sich dabei aus folgenden Schritten
zusammen:
1. Mit Hilfe des Algorithmus aus Abschnitt 5.1.1 wird nach den beiden freien Kacheln
gesucht, die den End- bzw. Startpunkt der Linie enthalten. Der Start- und Endpunkt der
Linie sind damit als Teil der Sekundärnotation fest vorgegeben (vgl. dazu Abschnitt 2.3)
und können durch den Algorithmus nicht verändert werden. Dabei ist zu beachten, dass
diese Punkte auf den Rändern der entsprechenden Knoten liegen und deshalb zuerst in
die nächstgelegenen freien Kacheln übertragen werden müssen.
2. Ein erster Pfad wird erstellt. Der genaue Aufbau eines Pfades ist in Abschnitt 4.3.2
beschrieben. Dieser erste Pfad enthält noch keinen Elternpfad; Er enthält die Startkachel
aus Schritt 1 als Endkachel, den Startpunkt aus Schritt 1 als Kostenpunkt und einen
Distanzwert 0. Dieser Pfad wird im Heap abgelegt.
3. Die folgenden Schritte werden wiederholt, solange der Heap, in dem die Pfade abgelegt
sind, nicht leer ist. Der nächste Pfad wird aus dem Heap entnommen. Dieser aktuelle
Pfad entspricht dem Pfad, der im Moment den kleinsten Distanzwert aufweist. Entspricht die Endkachel dieses Pfades der Endkachel der Linie aus Schritt 1, so wurde
ein Pfad gefunden. Existieren mehrere Lösungen so befinden sich diese an der Spitze des Heaps und können daraus entnommen werden. Potentielle Lösungen lassen sich
dabei daran erkennen, dass ihre Endkachel der Endkachel der Linie entspricht. Alle
diese Lösungen werden vom Algorithmus zurückgegeben, womit dieser beendet wird.
Ansonsten wird der aktuelle Pfad im folgenden Schritt weiterverarbeitet.
4. Dieser Schritt wird in analoger Weise für die Nachbarn oberhalb, unterhalb, links und
rechts der Endkachel des aus dem Heap entnommenen Pfades durchgeführt.
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
68
Mit Hilfe des Algorithmus aus Abschnitt 5.1.3 werden alle Nachbarn der Endkachel des
aktuellen Pfades durchlaufen. Entspricht der aktuelle Nachbar dieser Iteration einer belegten Kachel oder ist die entsprechende Kachel bereits im Pfad enthalten, so wird dieser
Nachbar übersprungen. Ansonsten wird die Position des nächsten Kostenpunktes bestimmt. Dieser Kostenpunkt entspricht dabei dem Punkt innerhalb der Nachbarkachel,
der gegenüber dem aktuellen Kostenpunkt die geringste Distanz aufweist (vgl. dazu Abschnitt 4.3.2). Danach wird die Manhatten-Distanz zwischen dem neuen Kostenpunkt
und dem Kostenpunkt des aktuellen Pfades berechnet. Zum Abschluss wird ein neuer
Pfad mit dem aktuellen Pfad als Elternpfad, dem aktuellen Nachbarn als Endkachel,
dem neuen Kostenpunkt und dem berechneten Distanzwert erzeugt und im Heap abgelegt.
Abbildung 5.5 illustriert das Vorgehen des oben beschriebenen Algorithmus anhand eines
einfachen Beispiels. Dabei soll eine Linie zwischen den Hindernissen C und K hindurch vom
Punkt X1 zum Punkt X2 geführt werden.
A
A
B
B
F
E
C
G
D
X1
F
E
H
C
G
X1
K3
H
K1
I
I
L
K
J
M
X2
N
L
K
J
O
M
X2
P
E
B
Q
Q
(a)
(b)
K211
K311
C
G
D
F
E
A
C
G
D
X1
X1
H
H
K13
I
K12
K11
J
O
B
K21
F
N
P
A
K31
D
K2
K
I
K12
L
M
X2
N
O
K
J
L
M
N
O
P
P
Q
X2
K111
Q
(d)
(c)
Abbildung 5.5: Finden eines geeigneten Pfades
Zu Beginn wird in Abbildung 5.5a der erste Pfad P0 erzeugt, der Kachel H als Endkachel,
Punkt X1 als Kostenpunkt und einen Distanzwert 0 enthält. Dieser Pfad wird im Heap abge-
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
69
legt und in Schritt 2 auch gleich wieder daraus entnommen. Als nächstes werden alle Nachbarn
der Kachel H (der Endkachel von P0) durchlaufen und die jeweiligen Kostenpunkt innerhalb
dieser Nachbarn bestimmt. Abbildung 5.5b zeigt die drei Kostenpunkte K1, K2 und K3 für
die drei Nachbarn I, G und E. Für jeden der Nachbarn wird ein neuer Pfad erzeugt, der
P0 als Elternpfad enthält. Somit werden drei neue Pfade P1, P2 und P3 mit dem jeweiligen
Kostenpunkt K1, K2 und K3 und der Manhatten-Distanz zwischen dem Kostenpunkt und
dem Startpunkt X1 im Heap abgelegt.
Aus dem Heap wird nun der Pfad mit dem geringsten Distanzwert entnommen und die Nachbarn von dessen Endknoten verarbeitet. In Abbildung 5.5c wird entsprechend den Distanzwerten zuerst P1 dann P2 und zuletzt P3 aus dem Heap entnommen. Aus P1 entstehen durch
die drei Nachbarn drei neue Pfade (K11, K12 und K13) und aus P2 und P3 jeweils ein neuer
Pfad P21 bzw. P31, die nun ihrerseits im Heap abgelegt werden. Aus dem Heap wird nun
wiederum jeweils der Pfad mit dem geringsten Distanzwert entnommen. In Abbildung 5.5d
werden die Pfade in der Reihenfolge P21, P11 und P12 aus dem Heap entommen und verarbeitet. Da der Pfad P12 Kachel L und damit die Endkachel der Linie als Endkachel enthält,
wurde ein Pfad gefunden und er Algorithmus hat seine Arbeit erledigt. Im vorliegenden Fall
gibt es damit nur eine optimale Lösung.
Position von Start- und Endpunkt
In der bisher beschriebenen Form wird die Position des Start- und Endpunktes der Linie vor
der Anwendung des Algorithmus festgelegt und durch den Algorithmus nicht verändert. Wird
die Position der beiden Punkte als Teil der Sekundärnotation betrachtet, so ermöglicht dieses
Vorgehen die Erhaltung dieses Teils der Sekundärnotation bei Layoutveränderungen. Fügt
der Benutzer jedoch eine neue Linie zum Modell hinzu, so müssen die Positionen der beiden
Punkte bestimmt werde. Dies kann z.B. dadurch geschehen, dass eine direkte Linie durch die
Mittelpunkte des Start- und Endknoten gezogen wird und der Start- und Enpunkt dann dem
Schnittpunkt dieser Linie und dem Rand des Start- bzw. Endknoten entspricht. Durch eine
kleine Modifikation ist aber auch der Algorithmus zum Finden eines geeigneten Pfades in der
Lage, die Positionen der beiden Punkte zu bestimmen. Abbildung 5.6 illustriert das Vorgehen
anhand des Startpunktes:
Abbildung 5.6: Bestimmung des Startpunktes durch den Linienführungsalgorithmus
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
70
Der Algorithmus beginnt dabei nicht mit einem Punkt, der auf dem Rand des Startknotens
liegt, sondern dem Mittelpunkt des Knotens. Die Startkachel der Linie ist damit nicht mehr eine freie Kachel, sondern entspricht der Kachel, die mit dem Startknoten belegt ist. Ansonsten
bleibt das Vorgehen unverändert, d.h. die Nachbarkacheln der Startkachel werden durchlaufen und jeweils die Position der Kostenpunkte bestimmt. Durch dieses Vorgehen bestimmt
der Algorithmus die erste freie Kachel, durch die ein bezüglich der Distanz optimaler Pfad
hindurchführen muss. Ausgehend von dieser Kachel lässt sich dann leicht der Startpunkt auf
dem Rand des Startknotens bestimmen. Diese Vorghen lässt sich in analoger Weise auch auf
den Endpunkt der Linie anwenden, wodurch der Algorithmus in der Lage ist den kürzesten
Pfad zwischen zwei Knoten zu finden. Die Bestimmung von Start- und Endpunkt durch den
Algorithmus macht dabei jedoch nur beim erstmaligen Führen einer Linie Sinn, da sonst die
Sekundärnotation (vgl. dazu Abschnitt 2.3) zerstört wird.
5.3
Linienführung
Für das Führen der Linien durch den aus freien Kacheln bestehenden Pfad sind, wie bereits in
Abschnitt 4.3.2 ausgeführt, verschiedenste Algorithmen denkbar. Im folgenden Abschnitt wird
als Besipiel dazu eine mögliche Realisierung einer orthogonalen Linienführung beschrieben.
5.3.1
Orthogonale Linienführung
Der folgende Algorithmus führt die Linien orthogonal durch den aus freien Kacheln bestehenden Pfad. Dabei geht er rückwärts vor, d.h. er beginnt mit der Endkachel und arbeitet
sich bis zur Startkachel durch den Pfad hindurch. Diese Vorgehensweise kommt dadurch zu
Stande, dass der im vorhergehenden Abschnitt beschriebene Algorithmus Pfade jeweils durch
die Endkachel und einen Verweis auf den Elternpfad repräsentiert. Um den gesamten Pfad zu
rekonstruieren ist es deshalb nötig, sich mit Hilfe der Verweise auf die Elternpfade von hinten
nach vorne durch den Pfad zu hangeln. Damit ein solcher Pfad nicht zuerst in eine anderen
Struktur umgewandelt werden muss, geht der Linienführungsalgorithmus rückwärts vor.
Das vorgestellte Verfahren führt die Linie innerhalb einer freien Kachel in Abhängigkeit von
der Richtung aus der die Linie die Kachel betritt und diese wieder verlässt. Die Richtungen
werden im Folgenden mit den vier Himmelsrichtungen Nord, Süd, Ost und West bezeichnet.
Dabei sind für eine freie Kachel vier verschiedene Konstellationen möglich:
1. Die Linie durchquert die freie Kachel vertikal, d.h. sie betritt die Kachel von Norden
und verlässt sie nach Süden. Ebenso möglich ist eine Durchquerung von Süden nach
Norden (Abbildung 5.7a). Dabei spielt es im Moment noch keine Rolle, ob für diese
Durchquerung innerhalb der Kachel zusätzliche Hilfspunkte nötig sind oder nicht.
2. Die Linie verlässt die Kachel wieder in die gleiche Richtung, aus der sie diese betreten
hat. Dabei kann es sich sowohl um Süden als auch um Norden handeln (Abbildung 5.7b).
3. Die Linie ändert innerhalb der Kachel ihre Richtung, d.h. sie betritt die Kachel von
Norden oder Süden und verlässt sie nach Osten oder Westen. Ebenso ist es möglich,
dass die Linie von Westen oder Osten in die Kachel eintritt und diese entweder nach
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
71
Norden oder Süden verlässt (Abbildung 5.7c). Diese Situation kann nur eintreten, falls
die Kachel im Osten oder Westen dem Start- oder Endknoten entspricht.
4. Die Kachel wird von der Linie horizontal durchquert, d.h. die Linie tritt von Westen
oder Osten in die Kachel ein und verlässt sie auf der gegenüberliegenden Seite (Abbildung 5.7d). Aufgrund der Organisation der Corner Stitching Struktur in maximale
horizontale Streifen kann dieser Fall nur eintreten, wenn die betreffende freie Kachel
sowohl der Start- als auch der Endkachel der Linie entspricht, d.h. der Pfad aus einer
einzigen freien Kachel besteht.
Abbildung 5.7: Mögliche Konstellationen bei der orthogonalen Linienführung
Da sich der Pfad aus einer Kette von freien Kacheln zusammensetzt, lassen sich aufgrund der
vorhergehenden und nachfolgenden Kachel leicht die Richtungen bestimmen, aus denen die
Linie eine Kachel betreten und sie wieder verlassen muss. Der Pfad zwischen den Punkten
X1 und X2 in Abbildung 5.8 setzt sich aus den vier dunkelgrau hinterlegten freien Kacheln
zusammen. Kachel B befindet sich in diesem Pfad zwischen den Kacheln D und A, woraus
sich schliessen lässt, dass die Linie Kachel B von Süden her betreten und nach Norden wieder verlassen muss. Im Folgenden werden dafür die Begriffe Eintritts- und Austrittsrichtung
verwendet. Kachel B in Abbildung 5.8 hat damit die Einrtittsrichtung Süd und die Austrittsrichtung Nord.
S
X1
A
B
D
E
X2 E
Abbildung 5.8: Bestimmung der Eintritts- und Austrittsrichtung
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
72
Der Algorithmus durchläuft rückwärts alle freien Kacheln, aus denen sich der Pfad zusammensetzt. Die Kacheln in Abbildung 5.8 werden damit in der Reihenfolge E, D, B und A
durchlaufen. Die letzte Kachel E lässt sich dabei direkt aus dem Pfad entnehmen, da sie der
Endkachel des Pfades entspricht. Die übrigen Kacheln befinden sich jeweils im Elternpfad
des aktuellen Pfades, d.h. D im Elternpfad des Pfades, der E als Endkachel enthält. Für jede
freie Kachel werden dabei zuerst die Eintritts- und Austrittsrichtung in bzw. aus der Kachel
bestimmt. Im ersten Durchlauf (d.h. für die Endkachel des Pfades) müssen dabei beide Richtungen bestimmt werden. Danach entspricht die Eintrittsrichtung jeweils der Gegenrichtung
der Austrittsrichtung der vorhergehenden Kachel. Da eine Linie in Abbildung 5.8 z.B. Kachel
D nach Norden hin verlassen muss, kann Kachel B nur von Süden her betreten werden.
Abbildung 5.9: Vorgehen bei der orthogonalen Linienführung
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
73
Abbildung 5.9 illustriert das Vorgehen des Algorithmus beim Führen einer Linie von Punkt
P1 zu Punkt P2. Der Pfad setzt sich dabei aus den dunkelgrau hinterlegten freien Kacheln
zusammen. Beim Bestimmen der Eintritts- und Austrittsrichtung wird jeweils auch gleich
noch das horizontale Intervall festgelegt, durch das ein vertikales Segment hindurchführen
muss. Die beiden Punkte die dieses Intervall aufspannen werden in Abbildung 5.9 jeweils mit
L und R bezeichnet. So muss z.B. eine Linie, die Kachel E in Abbildung 5.9a von Süden
her betritt, zwischen den Punkten L1 und R1 hindurchführen. Da sich der Endpunkt P2 als
Teil der Sekundärnotation nicht verschieben lässt, wird die Linie zuerst so lange wie möglich
ohne Richtungsänderung vom Endpunkt weg geführt. Befindet sich die horizontale Position des Liniensegments nicht mehr innerhalb des von L und R aufgespannten Intervalls, wie
dies in Abbildung 5.9b mit L2 und R2 der Fall ist, so sind Hilfspunkt nötig, damit sich die
horizontale Position des vertkalen Segment wiederum innerhalb des von L2 und R2 aufgespannten Intervalls befindet. Die horizontale Position der Hilfspunkte ergibt sich dabei aus
dem letzten bzw. nächsten Segment, die vertikale Position entspricht der vertikalen Position
des Mittelpunktes der Kachel, in welche der Hilfspunkt eingefügt wird. Da sich die horizontale Position der Punkte L3 und R3 in Abbildung 5.9c gegenüber derjenigen von L2 und
R2 in Abbildung 5.9b nicht ändert, kann die Linie ohne Änderung weitergeführt werden. In
Abbildung 5.9d wird das durch L4 und R4 aufgespannte horizontale Intervall jedoch schmaler, da Kachel B schmaler ist als Kachel D. Wärend sich der Algorithmus durch die Kacheln
hindurch bewegt, werden die Positionen von L und R nur verändert, falls der Bereich eingeschränkt wird, d.h. L nach rechts oder R nach links verschoben werden muss. Dadurch
geben die beiden Punkte immer den schmalsten horizontalen Durchgang an, durch den sich
ein vertikales Segment hindurchbewegen muss. Im Fall von Abbildung 5.9d wird der zuletzt
eingefügte Hilfspunkt H2 nach links verschoben, um die Linie durch den Mittelpunkt von Kachel B hindurchzuführen. Der durch L und R aufgespannte Bereich gibt dabei jeweils an, wie
weit der zuletzt eingefügte Hilfspunkt bewegt werden kann. In Abbildung 5.9e verändert sich
die horizontale Position von L5 und R5 gegenüber L4 und R4 nicht und die Linie wird ohne
Veränderung durch Kachel B hindurchgeführt. Da sich der Startpunkt P1 nicht verschieben
lässt, wird in Abbildung 5.9f das Intervall einfach auf diesen Punkt eingeschränkt, d.h. sowohl L als auch R entsprechen P1. Dadurch befindet sich dieser neue Bereich ausserhalb des
Bereiches von Abbildung 5.9e und die Hilfspunkte H3 und H4 sind nötig um die Linie durch
Kachel A hindurchzuführen.
Im obigen Beispiel tritt nur der Fall auf, dass die Linie von Süden nach Norden durch eine
Kachel hindurchgeführt werden muss (dies entspricht der Konstellation a in Abbildung 5.7
auf Seite 71). Dies ist aufgrund der Organisation der Corner Stitching Struktur in maximale
horizontale Streifen auch der Fall, der am häufigsten eintritt. In den übrigen Fällen (Konstellation b, c und d in Abbildung 5.7) ist ein solch kompliziertes Vorgehen gar nicht nötig,
da alle Informationen, die für das Einfügen eines Hilfspunktes benötigt werden, in der betreffenden Kachel enthalten sind und die Position der Hilfspunkte nicht durch vorhergehende
oder nachfolgende Kacheln beeinflusst werden kann. So ist z.B. für die Situation in Abbildung 5.7c die Position des Hilfspunktes beim Einfügen bekannt und diese Position wird nicht
mehr verändert. Die vertikale Position ist durch die vertikale Position des zuletzt eingefügten
Hilfspunktes und die horizontale Position durch die horizontale Position des Start- bzw. Endpunktes gegeben. Veränderungen an der Position eines bereits eingefügten Hilfspunkt (wie
dies in Abbildung 5.9d der Fall ist) sind somit in keiner dieser Konstellationen nötig.
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
74
Problemfälle
Beim oben beschriebenen Vorgehen zur orthogonalen Linienführung kann es in bestimmten
Situationen zu einer unschönen Linienführung kommen. Dabei wird jedoch auch in diesen
Fällen die Linie korrekt, d.h. ohne Überschneidungen mit Knoten geführt. Abbildung 5.10
zeigt drei solche Problemfälle.
A
A
B
B
C
C
B
B
D
D
A
C
D
(a)
B
C
(b)
(c)
Abbildung 5.10: Problemfälle bei der orthogonalen Linienführung
In der Situation a wird die Linie sehr nahe am Knoten C entlang geführt, obwohl zwischen
den Knoten C und D bedeutend mehr Raum zur Verfügung steht. Dieses Problem tritt auch
im Beispiel von Abbildung 5.9b auf Seite 72 bei den Kacheln E und F auf. Ein ähnliches Problem zeigt Situation b in Abbildung 5.10, bei der die Linie ebenfalls in zu geringem Abstand
an einem Knoten vorbeigeführt wird. Die Linien nutzen in beiden Fällen den zur Verfügung
stehenden freien Raum in vertikaler Richtung nicht optimal aus. Aufgrund der Organisation
der Corner Stitching Struktur tritt dieses Problem nur bei horizontalen Liniensegmenten auf,
d.h. die vertikalen Segmente werden immer innerhalb des zur Verfügung stehenden Raumes zentriert. Das Problem lässt sich leicht lösen, indem, nachdem die Linie geführt worden
ist, in einem zweiten Schritt die horizontalen Liniensegmente ebenfalls zentriert werden. Dies
geschieht mit Hilfe des Rechteckes, das den Bereich angibt, in dem sich ein Liniensegment
befinden muss. Diese Rechtecke sind in Abbildung 5.10 dunkelgrau hinterlegt dargestellt. Dieses Rechteck kommt ebenfalls für die Erhaltung der Sekundärnotation und das Verschieben
von Liniensegment zur Vermeidung von Linienüberlappungen zum Einsatz (vgl. dazu Abschnitt 4.3.3). Innerhalb dieses Rechteckes kann das betreffende horizontale Liniensegment
dann zentriert werden.
Durch die Zentrierung der Linie innerhalb des freien Raumes, wird in Situation c in Abbildung 5.10 die Linie mit zu grossem Abstand um Knoten B herumgeführt. Auch dieses
Problem lässt sich leicht lösen, indem ein Grenzwert eingeführt wird, ab dem die Linie nicht
mehr zentriert, sondern in einem festen Abstand um den betreffenden Knoten herumgeführt
wird.
Bestimmen der optimalen Lösung
Der Algorithmus zum Finden eines geeigneten Pfades aus freien Kacheln kann, wie in Abschnitt 5.2 beschrieben, mehrere gleichwertige Lösungen liefern. Der Algorithmus, der die
Linie durch diese Kacheln hindurchführt, muss deshalb anhand eigener Kriterien eine dieser
Lösungen auswählen. Dazu ist es in der Regel nötig, durch alle Pfade, die für eine optimale
Linienführung in Frage kommen, eine Linie hindurchzuführen und diese verschiedenen Linien
miteinander zu vergleichen. So existieren z.B. in Abbildung 5.11 zwei Lösungen, wie eine Linie
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
75
von P1 zu P2 geführt werden kann. Die beiden Linien weisen dabei sogar die gleiche Länge
auf.
Abbildung 5.11: Mehrere Lösungen bei der orthogonalen Linienführung
Aus diesen Lösungen muss nun eine ausgewählt werden. Für die Auswahl kommen verschiedene Kriterien in Frage. Ein Auswahlverfahren kann z.B. nach folgenden Kriterien durchgeführt
werden. Die Kriterien 1 bis 3 kommen dabei bei einem Auswahlverfahren zur Anwendung, bei
dem zuerst anhand des ersten Kriteriums versucht wird, einen Sieger zu küren. Ist aufgrund
des ersten Kriteriens keine eindeutige Wahl möglich, weil beide Lösungen gleich gut abschliessen, kommt das zweite Kriterium zum Einsatz. Ist auch damit keine eindeutige Auswahl
möglich, so wird das dritte Kriterium zur Entscheidung herangezogen. Dabei handelt es sich
jedoch nur um eine Heuristik, d.h. es ist nicht garantiert, dass mit diesen Kriterien immer
eine eindeute Auswahl möglich ist. Die folgenden Kriterien leiten sich aus den ästhetischen
Kriterien aus dem Bereich des Graphenlayouts (vgl. dazu Abschnitte 2.1.5 und 3.1) ab.
1. Die Anzahl der Hilfspunkte in der Linie. Die Anzahl der Hilfspunkte stellt ein intuitives
Kriterium zur Beurteilung der Qualität einer Linie dar, da mit zunehmender Anzahl
von Hilfspunkten auch die Komplexität einer Linie zunimmt.
2. Die gesamte Länge der Linie. Die Länge der Linie entspricht dabei in vielen Fällen nicht
der Distanz, die beim Finden eines geeigneten Pfades zum Einsatz kommt, weil sich die
Kostenpunkte, mit denen diese Distanz berechnet wird, oftmals am Rande der freien
Kacheln befindet, die Linie selbst jedoch möglichst zentriert durch die Kacheln geführt
wird.
3. Die Länge des kürzesten Segments der Linie. Dieses Kriterium wird nötig, falls anhand
der ersten beiden Kriterien keine eindeutige Auswahl möglich ist. Das Kriterium nimmt
damit nicht eine ästhetische Beurteilung vor, sondern soll ein eine eindeutige Auswahl
der Lösung ermöglichen.
Die Auswahl der Lösung muss dabei eindeutig sein, d.h. eine Lösung darf nicht nur aufgrund
der Tatsache, dass sie als Erste gefunden wurde, ausgewählt werden. Dies ist nötig, damit
die Linien symetrisch geführt werden. Symetrisch bedeutet in diesem Zusammenhang, das
eine Linie die vom End- zum Startpunkt führt, gleich aussieht wie eine Linie die umgekehrt
KAPITEL 5. REALISIERUNG DES LINIENFÜHRUNGSALGORITHMUS
76
vom Start- zum Endpunkt führt. Dabei werden zwar in beiden Fällen die gleichen Lösungen
gefunden, jedoch in unterschiedlicher Reihenfolge. Hat bei der Auswahl der Lösung diese
Reihenfolge einen Einfluss, so ist es möglich, dass je nach Richtung die Linie unterschiedlich
geführt wird.
5.3.2
Linienführung mit Hilfe von Splines
Aufbauend auf dem Vorgehen zur orthogonalen Linienführung aus Abschnitt 5.3.1 lassen
sich nun leicht weitere Linienführungen realisieren. So lässt sich z.B. durch das Einfügen von
Stützpunkten an Stelle der Hilfspunkte eine auf Splines basierende Linienführung realisieren.
Abbildung 5.12 illustriert dies anhand des Beispiels aus Abbildung 5.9 auf Seite 72.
Abbildung 5.12: Linienführung mit Hilfe von Splines
Daneben sind aber auch ganze andere Vorgehensweisen möglich, bei denen die Position der
Hilfspunkt - anders als in Abschnitt 5.3.1 beschrieben - berechnet werden. Für eine direkte
Linienführung kann das oberste Kriterium z.B. darin bestehen, die Linie mit möglichst wenig
Hilfspunkten zu führen, womit auch ein anderes Verfahren angewandt werden muss, um diese
Punkte zu bestimmen.
Kapitel 6
Zusammenfassung und Diskussion
Die Aufgabe der vorliegenden Arbeit bestand darin, eine Linienführung für Adora-Modelle
zu entwickeln. Die Analyse bestehehender Linienführungsalgorithmen und von verschniedenen Autoren vorgeschlagener Ansätze für die Linienführung in Adora-Modellen brachte eine
Reihe von Problemen zum Vorschein. So stellt bereits die Linienführung in einem statischen
Layout ein nicht unerhebliches Problem dar. Die Visualisierung von Adora-Modelle beruht
jedoch auf einem dynamischen Layout, bei dem aus einem integrierten Gesamtmodell unterschiedliche Darstellungen dynamisch generiert werden. Um ein interaktives Arbeiten mit den
Modellen zu ermöglichen, werden dabei sehr hohe Anforderungen an die Laufzeit der Algorithmen gestellt. Aus diesem Grund kommen die meisten bestehenden Ansätze fürAdora-Modelle
nicht in Frage, da sie eine zu hohe Laufzeitkomplexität aufweisen.
Als zusätzliche Anforderung muss in Adora-Modellen die möglichst gute Erhaltung der Sekundärnotation ermöglicht werden, um dem Benutzer einen gewissen Einfluss auf das Layout
und damit auch die Linienführung zu belassen. Aus diesem Grund kann die Linienführung
nicht vollautomatisch durchgeführt werden. Die Sekundärnotation muss dabei, unabhängig
von der aktuellen Darstellung, so gut wie möglich erhalten bleiben. Oftmals muss nach einer
Veränderung des Layouts durch den Zoom-Algorithmus die Linie aber auch komplett neu
gefürt werden, da der Zoom-Algorithmus das Layout des Modells zu stark verändert. In diesem Fall ist eine Erhaltung der Sekundärnotation nicht möglich. In den meisten bestehenden
Ansätzen ist eine solche manuelle Einflussnahme in die Linienführung nicht vorgesehen.
Da sich keiner der bestehenden Ansätze als für Adora-Modelle geeignet erwies, wurde im
Verlauf der Arbeit ein neuer Ansatz entwickelt, der auf einer Datenstruktur beruht, die im
Bereich des computerunterstützten Entwurfs von Schaltungen in erster Linie zum effizienten
Speichern der Schaltungselemente entwickelt wurde. Dabei wird die eigentliche Linienführung,
d.h. das Bestimmen der benötigen Hilfspunkte in den Linien, vom Finden des Bereiches, durch
den die Linie hindurchführen muss, entkoppelt. Damit ist es möglich, verschiedene Ansätze der
Linienfühung (z.B. orthogonal oder möglichst direkt) auf dem gleichen Fundament aufbauend
zu implementieren und damit auch austauschbar zu gestalten. Zusätzlich ermöglicht dieser
Ansatz dem Benutzer in beschränktem Masse Änderungen an der Linienfügrung vorzunehmen
und diese auch bei Layoutveränderungen, wie sie z.B. durch den Zoom-Algorithmus entstehen,
zu erhalten.
Da sich die Erfüllung der an die Linienführung gestellten Anforderungen eine grosse Herausfor77
KAPITEL 6. ZUSAMMENFASSUNG UND DISKUSSION
78
derung darstellte, konnte im Rahmen der zur Verfügung stehenden Zeit keine abgeschlossene
Realisierung für das Problem der Linienführung erarbeitet werden. Der vorgestellte Ansatz
entspricht denn auch mehr einem grundlegenden Konzept als einer detaillierten technischen
Lösung. Seine grundsätzliche Tauglichkeit für die Linienführung in Adora-Modellen hat er
jedoch in einem Prototyp unter Beweis gestellt. Im Zusammenhang mit der Realisierung
sind aber auch einige grundsätzliche Probleme bei der Linienführung aufgetaucht, denen bis
jetzt noch kaum Aufmerksamkeit gewidmet wurde. So bleibt es z.B. unklar, in welchem Ausmass der Benutzer Einfluss auf die Linienführung nehmen und damit die Sekundärnotation
definieren möchte. Ebenfalls bist jetzt nicht geklärt ist die Frage, welche Elemente eines
Adora-Modells die Mental Map des Benutzers ausmachen und damit auch nach Layoutveränderungen weiterhin dieser Mental Map entsprechen müssen. Diese Fragen müssten mit
Hilfe einer empirischen Analyse mit realen Adora-Modellen geklärt werden.
Die Corner Stitching Datenstruktur, auf der die Linienführung beruht, könnte zusätzlich
auch in anderen Bereichen der Visualisierung von Adora-Modellen eingesetzt werden, da sie
zwei grundlegende Probleme aller geometrischen Algorithmen angeht: die Repräsentation der
Nachbarschaftsbeziehungen zwischen den graphischen Symbolen und die explizite Repräsentation des freien Raumes zwischen den Elementen. Auf diese Informationen sind auch andere Layout-Operationen, wie z.B. der Zoom-Algorithmus, angewiesen. Die Corner Stitching
Datenstruktur macht dabei das Durcharbeiten des gesamten Modells oder aller Elemente
überflüssig.
Am Beispiel einer orthogonalen Linienführung wurde im Rahmen dieser Arbeit ein mögliches
Vorgehen, das auf der Idee der kachelbasierten Linienführung beruht, vorgestellt. Ein nächster
Schritt würde nun die Realisierung anderer Linienführungen (z.B. möglichst direkt oder mit
Hilfe von Splines), die ebenfalls auf dem vorgestellten Ansatz beruhen, umfassen. Dadurch
wäre es dann auch möglich, Linien, die unterschiedliche Beziehungen in einem Adora-Modell
repräsentieren, unterschiedlich zu führen und damit voneinander abzuheben. Da der vorgestellte Ansatz das Problem der Linienführung in zwei Teilaufgaben zerlegt, stellt eine solche
Erweiterung kein grosses Problem dar.
Ein weiterer Bereich, der mit der Linienführung in engem Zusammenhang steht, jedoch im
Rahmen dieser Arbeit nicht vertieft behandelt wurde, betrifft das Problem der Platzierung
der Linienbeschriftungen. Da der kachelbasierte Ansatz den Pfad der Linien durch eine Reihe
von freien Kacheln repräsentiert, ist der freie Raum, in dem die Linienbeschriftungen platziert werden können, für jede Linie bekannt. Dadurch sollte sich auch ein Algorithmus zur
Platzierung der Linienbeschriftungen ohne grosse Mühe realisieren lassen.
Literaturverzeichnis
[Bea90]
Beard, D. V., Walker, J. Q.: Navigational techniques to improve the display of
large two-dimensional spaces. Behaviour & Information Technology, Vol. 9, No.
6, p. 451-466, 1990
[Ber98]
Berner, S., Joos, S., Glinz, M., Arnold, M.: A visualization concept for hierarchical object models. Proceedings of the 13th IEEE International Conference on
Automated Software Engineering (ASE-98), p. 225-228, 1998
[Ber02]
Berner, S.: Modellvisualisierung für die Spezifikationssprache ADORA. Dissertation, Universität Zürich, 2002
[Bri98]
Bridgeman, S., Tamassia, R.: Difference metrics for interactive orthogonal graph
drawing algorithms. Proceedings of the 6th International Symposium on Graph
Drawing (GD 98), p. 57-71, 1998
[Dij59]
Dijkstra, E. W.: A Note on Two Problems in Connexion with Graphs. Numerical
Mathematics, Vol. 1, p. 269-271, 1959
[Dio95]
Dion, J., Monier, L. M.: Contour: A Tile-based Gridless Router. Western Research Laboratory Research Report 95/3, Palo Alto, 1995
[Ead84]
Eades, P.: A heuristic for graph drawing. Congressus Numerantium, Vol. 42, p.
149-160, 1984
[Ead91]
Eades, P., Lai, W., Misue, K., Sugiyama, K.: Preserving the mental map of a
diagram. Proceedings of Compugraphics 91, p. 34-43, Sesimbra, Portugal, 1991
[Ead95]
Eades, P., Lai, W., Misue, K., Sugiyama K.: Layout adjustment and the mental
map. J. Visual Languages Comput. 6, p. 183-210, 1995
[Eig03]
Eiglsperger, M.: Automatic Layout of UML Class Diagrams: A Topology-ShapeMetrics Approach. Dissertation, Universität Tübingen, 2003
[Fur86]
Furnas, G. W.: Generalized fisheye views. Proceedings of ACM CHI 86 Conference on Human Factors in Computing Systems, Boston, 1986
[Gli00]
Glinz, M.: Problems and deficiencies of UML as a requirements specification
language. Proceedings of the Tenth International Workshop on Software Specification and Design, p. 11-22, San Diego, 2000
79
LITERATURVERZEICHNIS
80
[Gli02]
Glinz, M., Berner, S., Joos, S.: Object-oriented modeling with ADORA. Information Systems 27, p. 425-444, 2002
[Har87]
Harel, D.: Statecharts: a visual formalism for complex systems. Sci. Computer
Programming 8, p. 231-274, 1987
[Jac75]
Jackson, M. A.: Principles of Program Design. Academic Press, New York, 1975
[Joo97]
Joos, S., Berner, S., Arnold, M., Glinz, M.: Hierarchische Zerlegung in objektorientierten Sepezifikationsmodellen. Softwaretechnik-Trends 17 (1), p. 29-37,
1997
[Joo99]
Joos, S.: ADORA-L - Eine Modellierungssprache zur Spezifikation von SoftwareAnforderungen. Dissertation, Universität Zürich, 1999
[Lee61]
Lee, C. Y.: An Algorithm for Path Connection and its Application. IRE Transactions on Electronic Computers, 1961
[Mar02]
Marty, M.: Analyse und Erweiterung von Algorithmen zur logischen Navigation
in Adora-Modellen. Diplomarbeit, Universität Zürich, 2002
[Mik68]
Mikami, K., Tabuchi, K.: A computer program for optimal routing of printed
circuit connectors. IFIPS Proceedings, H47, p. 1475-1478, 1968.
[Moy98]
Moy, J.: OSPF Version 2. Network Working Group, Request for Comments: 2328,
April 1998
[Nor96]
North, S. C.: Incremental layout with DynaDag. Proceedings of the 3rd International Symposium on Graph Drawing, p. 409-418, 1996
[Omg03]
OMG: UML 2.0 Superstructure Specification. OMG document ptc/0308-02. Tech. Rep., Object Management Group, http://www.omg.org/cgibin/doc?ptc/2003-08-02, 2003
[Ous84]
Ousterhout, J. K.: Corner Stitching: A Data Structuring Technique for VLSI
Layout Tools. IEEE Transactions on Computer-Aided Design CAD-3(1), p. 8789, January 1984
[Ous85]
Ousterhout, J., Hamachi, G., Mayo, R., Scott, W., Taylor, G. S.: The Magic VLSI
Layout System. IEEE Design and Test of Computers 2(1), p. 19-30, February
1985
[Pet95]
Petre, M.: Why looking isn’t always seeing - Readership Skills and Graphical
Programming. Communications of the ACM, Vol. 38, No. 6, p. 33-43, June 1995
[Pur98]
Purchase, H. C.: The Effects of Graph Layout. Proceedings of the Australian
Conference on Computer Human Interaction, p. 80, 1998
[Rum99]
Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modeling Language Reference Manual. Addison-Wesley, Reading, 1999
LITERATURVERZEICHNIS
81
[Sch96]
Schaffer, D., et al.: Navigating Hierarchically Clustered Networks through
Fisheye and Full-Zoom Methods. ACM Transactions on Computer-HumanInteraction, Vol. 3, No. 2, p. 162-188, 1996
[Sou78]
Soukup, J.: Fast maze router. Proceedings of the 15th conference on design
automation, p. 100-102, Las Vegas, Nevada, United States, 1978
[Wie01]
Wiese, R., Eiglsperger, M., Kaufmann, M.: yFiles: Visualization and Automatic
Layout of Graphs. Proceedings of the 9th International Symposium on Graph
Drawing (GD 2001), p. 453, 2001
[Wil64]
Williams, J. W. J.: Algorithm 232: Heapsort. Communications of the ACM, Vol.
7, No. 6, p. 347-348, 1964
[Xia04]
Xia, Y.: A Language Definition Method for Visual Specification Languages. Dissertation, Universität Zürich, 2004