Visualisierung hierarchischer Domänenmodelle

Transkript

1 Universität Ulm Ulm Germany Fakultät für Ingenieurwissenschaften und Informatik Institut für Künstliche Intelligenz Visualisierung hierarchischer Domänenmodelle Bachelorarbeit an der Universität Ulm Vorgelegt von: Dennis Mack Gutachter: Prof. Dr. Susanne Biundo-Stephan Betreuer: Pascal Bercher 2012

2 Fassung 29. Oktober 2012 c 2012 Dennis Mack This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License. To view a copy of this license, visit or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA. Satz: PDF-LATEX 2ε

3 Zusammenfassung In dieser Arbeit wird eine Visualisierung von hierarchischen Domänenmodellen erarbeitet, welche es dem Nutzer ermöglicht eine Domäne auf eine möglichst einfache und intuitive Weise zu erfassen und zu verstehen. Des Weiteren kann die Visualisierung zur Fehleranalyse sowie der automatischen Generierung von Grafiken für Publikationen verwendet werden. Zu Beginn der Arbeit wird der Formalismus des hybriden Planens vorgestellt sowie ein Planungsalgorithmus für das Lösen von hybriden Planungsproblemen. Ausgehend davon wird eine Datenstruktur zur Visualisierung der Domäne entwickelt und der ursprüngliche Planungsalgorithmus mittels einiger Änderungen dahingehend umkonfiguriert, dass er zur Erstellung der Datenstruktur verwendet werden kann. Basierend auf dieser Datenstruktur werden verschiedene Layouts für die Visualisierung entwickelt, ein adäquates Grafikframework für die Umsetzung bestimmt sowie mit Hilfe ausgewählter Layoutalgorithmen die Visualisierung implementiert. iii

4

5 Inhaltsverzeichnis 1. Einleitung Motivation Verwandte Arbeiten Aufgabenstellung Struktur der Arbeit Hybrides Planen Formalismus Die logische Sprache L Tasks T Pläne Domäne D & Dekompositionsmethoden M Hybrides Planungsproblem Lösen von hybriden Planungsproblemen Datenstruktur der Visualisierung Anforderungen Technische Anforderungen Visuelle Anforderungen Struktur des Task Decomposition Trees Erstellung des Task Decomposition Trees Aufbau des PANDA 2 -Planers Änderungen am ursprünglichen Planungsalgorithmus Algorithmus zur Erstellung des Task Decomposition Trees Visualisierung Allgemeine Begriffserklärung Vorstellung der Layouts Listendarstellung Baum mit Methoden-Knoten Baum ohne Methoden-Knoten Graph mit Methoden-Knoten Frameworks zur Visualisierung GraphViz Zest JUNG v

6 Inhaltsverzeichnis Processing Implementierung in Processing Walker-Layout Sugiyama-Layout Präsentation des entwickelten Werkzeuges Zusammenfassung und Ausblick Zusammenfassung Ausblick Erweiterungen des Werkzeuges Verwendung der Datenstruktur beim Planungsprozess A. Anhang 49 vi

7 1. Einleitung 1.1. Motivation Die rasch fortschreitende Technologisierung des Alltags führt dazu, dass der Umgang mit technischen Geräten immer unvermeidlicher wird. Dabei werden diese technischen Geräte stets komplexer und spezialisierter auf deren möglichen Anwendungsgebiete zugeschnitten. Diese Entwicklung steht jedoch meist diametral entgegengesetzt zu Benutzerfreundlichkeit sowie Bedienkomfort; viele technische Geräte können bei erstmaliger Benutzung nicht ohne vorherige Konsultierung des zugehörigen Handbuches bedient werden. Ein weiteres Problem besteht darin, dass bei länger Nichtbenutzung eines Gerätes dessen Bedienung dem Nutzer nicht mehr gegenwärtig ist. Diese Hindernisse führen dazu, dass die Frustration des Nutzers sowie dessen Ablehnung gegenüber neuer Geräte steigt. Der Sonderforschungsbereich/Transregio 62 (SFB TRR 62), in dessen Umfeld diese Arbeit entstanden ist, hat die Vision, dass technische Systeme der Zukunft Companion-Systeme sind. Als Companion-Systeme werden dabei kognitive technische Systeme bezeichnet, die sich in ihrer Funktionalität auf den jeweiligen Nutzer einstellen. Der Projektbereich A des SFB TRR 62 beschäftigt sich mit Prozessen der Handlungsplanung und Entscheidungsfindung mit dessen Hilfe Nutzer bei der Bedienung von technischen Geräten unterstützt werden können. Ein mögliches Anwendungsszenario könnte darin bestehen, einen Benutzer bei der Bedienung eines neu erworbenen Smartphones zu unterstützen [1]. Die dafür benötigten Planungsdomänen werden an der Universität Ulm mit Hilfe des PANDA- Editors erstellt, der dem Benutzer viele Möglichkeiten bietet eine Domäne schnell und effizient zu modellieren. Mit Hilfe des Editors ist es grundsätzlich möglich Informationen aus einer vorhandenen Domäne zu extrahieren, jedoch fehlt dem Editor die Möglichkeit eine modellierte Domäne visuell darzustellen. Dabei ist es vor allem die visuelle Darstellung, die es dem Benutzer erlaubt einen möglichst einfachen und intuitiven Zugang zu einer Domäne zu finden. An diesem Punkt setzt diese Arbeit an und offeriert eine Lösung um hierarchische Domänenmodelle für den Benutzer visuell übersichtlich darzustellen. Diese neuartige Option eine vorliegende Domäne zu veranschaulichen bietet für den Modellierer eine große Hilfestellung um den Überblick über eine Domäne zu behalten und etwaige Fehler zu beheben, die beim Entwurfsprozess entstanden sein könnten. Der größte Nutzen dieser Arbeit besteht jedoch darin Personen, die mit einer Domäne noch nicht vertraut sind, einen möglichst einfachen und intuitiven Zugang zu dieser zu gewähren, indem die Domäne grafisch dargestellt wird. Durch diese Hilfe können Nutzer schnell in Domänen eingearbeitet werden und damit auch 1

8 1. Einleitung alte Domänen wiederverwendet und aktualisiert werden. Des Weiteren stellt die Visualisierung auch ein Werkzeug für die automatische Generierung von Bildern für Publikationen, Poster und Präsentationen dar, ohne welches eine Domäne jedes Mal selbst nachvollzogen und von Hand gezeichnet werden müsste. Dies stellt für den Nutzer eine große Zeitersparnis sowie Arbeitserleichterung dar. Erste Verwendung findet die Visualisierung in dieser Arbeit; so sind ein Großteil der Darstellungen mit Hilfe des erarbeiteten Werkzeuges entstanden Verwandte Arbeiten Zwei mit dieser Arbeit verwandte Publikationen setzen den Fokus auf die unterstützte Erstellung von Domänenmodellen. In der Arbeit von Simpson et al. [8] wird mit GIPO IV ein umfangreiches Werkzeug beschrieben um hierarchische sowie klassische Planungsdomänen erstellen zu können. Dabei handelt es sich um einen selbst entwickelten, objekt-orientierten Ansatz, wodurch der Modellierer der Domäne auf Objekten arbeitet anstatt spezielle Sprachen zur Definition von Domänen verwenden zu müssen. Mit Hilfe verschiedener graphischer Werkzeuge können Domänen definiert, getestet und validiert werden. Ein explizites Werkzeug, um eine Domäne hierarchisch zu visualisieren gibt es jedoch nicht, ein Werkzeug welches dieser Aufgabe am nähesten kommt ist der in GIPO IV enthaltene Concept Editor, mit dessen Hilfe Objekte und deren Abhängigkeiten untereinander modelliert sowie visualisiert werden können. Das in der Publikation von Vaqeruo et al. [11] vorgestellte Werkzeug itsimple ist inhaltlich eng verwandt mit GIPO IV, wobei itsimple mehrere bekannte Sprachen wie XML, UML, Petri- Netze sowie PDDL miteinander vereint um Domänenmodelle zu erstellen, zu testen sowie zu analysieren. itsimple unterstützt den Designer einer Domäne vor allem darin, alle nötigen Anforderungen an eine Domäne zu erfassen, die Domäne zu modellieren sowie zu analysieren. Dabei wird eine Variante von UML, UML.P (UML in a Planning Approach), benutzt, mit dessen Hilfe Klassendiagramme sowie Zustandsdiagramme erstellt werden können, aus denen die Domäne entwickelt wird Aufgabenstellung Die Aufgabenstellung dieser Arbeit besteht darin eine Visualisierung von hierarchischen Domänenmodellen zu ermöglichen, mit dessen Hilfe der Modellierer sowie auch etwaige weitere Nutzer die Domäne betrachten sowie möglichst intuitiv und einfach erfassen können. Um dieses Ziel erreichen zu können, besteht die erste Aufgabe darin eine möglichst effiziente Datenstruktur, die der späteren Visualisierung zu Grunde liegt, zu entwickeln. Des Weiteren muss diese Datenstruktur unabhängig von der verwendeten Visualisierung sein, d.h. die Visualisierung muss austauschbar sein, wobei die Datenstruktur stets als deren Grundlage fungieren 2

9 1.4. Struktur der Arbeit soll. Dadurch ergibt sich die Möglichkeit, die Visualisierung später zu erweitern und auf spezifische Bedürfnisse des Nutzers anzupassen. Eine Anforderung dieser Arbeit besteht darin, möglichst viele der bereits vorhandenen Algorithmen und Routinen des an der Universität Ulm entwickelten PANDA 2 -Planers wiederzuverwenden, um die spätere Wartung des Quelltextes zu vereinfachen. Außerdem soll die Visualisierung in ein schon bestehendes Werkzeug zur explorierten Planraumdarstellung integriert werden, welches auf dem eclipse-framework 1 basiert Struktur der Arbeit Der Rest der Arbeit wird wie folgt strukturiert sein. In Kapitel 2 wird auf die Grundlagen des hybriden Planens eingegangen und das nötige Wissen vermittelt, welches in den folgenden Kapiteln vorausgesetzt wird. Kapitel 3 behandelt die Datenstruktur, welche der Visualisierung zu Grunde liegt. Das darauf folgende Kapitel, Kapitel 4, geht auf die tatsächliche Visualisierung ein, stellt in aller Kürze verschiedene, für die Implementierung in Frage kommende Grafikframeworks dar und präsentiert letztendlich die umgesetzte Implementierung. Kapitel 5 schließt diese Arbeit mit einer Zusammenfassung ab und gibt einen Ausblick auf mögliche Erweiterungen des entwickelten Werkzeuges

10

11 2. Hybrides Planen Die Handlungsplanung ist ein Teilbereich der Künstlichen Intelligenz mit dessen Hilfe es beispielsweise möglich ist Nutzer bei der Verwendung von technischen Systemen zu unterstützen. Man geht bei der Handlungsplanung von einem gegebenen Anfangszustand aus, d.h. der Ausgangssituation, welche mit Hilfe bestimmter Tasks in einen gewünschten Zielzustand überführt werden soll. Die zur Verfügung stehenden Tasks sind in der sogenannten Domäne, einem Modell der geltenden Welt, hinterlegt. Die Domäne ist eine Abstraktion der Welt, in der geplant werden soll, wobei in dieser bestimmte Gesetze gelten und eine bestimmte endliche Menge an Tasks ausführbar ist. Damit der gegebene Ausgangszustand in einen Zielzustand überführt wird, müssen in einer bestimmten Reihenfolge ausgewählte Tasks angewandt werden. Um diese Abfolge zu ermitteln gibt es unterschiedliche Ansätze, jedoch soll im Folgenden das hybride Planen behandelt werden, welches die Grundlage für die spätere Visualisierung darstellt. Das hybride Planen stellt eine Mischform aus zwei verschiedenen Planungsformen dar, welche im Folgenden erläutert werden. Auf der einen Seite befindet sich das Partial-Order Causal-Link (POCL)-Planen. Beim POCL- Planen handelt es sich um ein Suchverfahren, welches Suche im Planraum verwendet, mit dem Prinzip der geringsten Verpflichtung [7] arbeitet sowie den Fokus auf kausale Zusammenhänge zwischen Tasks legt. Dadurch entstehen als Lösung partiell geordnete Pläne, die sich mittels Linearisierung in total geordnete Pläne transformieren lassen. Diese Pläne wiederum enthalten eine Abfolge von Tasks, den sogenannten Planschritten. Diese Planschritte werden durch kausales Schließen festgelegt, d.h. es wird immer berücksichtigt, dass bestimmte Vorbedingungen gelten müssen, bevor ein ausgewählter Task ausgeführt werden kann. Des Weiteren führt die Ausführung eines Tasks zu Zustandsänderungen in der Welt. Das kausale Schließen lässt den Menschen besonders gut nachvollziehen wieso eine Aktion vor der anderen ausgeführt werden muss. Die partielle Ordnung der Pläne gibt dem Nutzer die Freiheit, Pläne in der für ihn günstigsten Abfolge auszuführen. Dadurch eignet sich POCL-Planen gut für das Planen mit und für Menschen. Auf der anderen Seite besteht das hybride Planen aus dem Hierarchical Task Network (HTN)- Planen. HTN-Planen erweitert das Planen um ein weiteres wichtiges Merkmal: die Hierarchie. Tasks werden hierzu im HTN-Planen in primitive und abstrakte Tasks unterteilt. Abstrakte Tasks lassen sich durch sogenannte Dekompositionsmethoden in partiell geordnete Pläne zerlegen, die selbst wieder aus primitiven sowie abstrakten Tasks bestehen können. Dekompositionsmethoden beinhalten somit Expertenwissen, da sie abstrakte Tasks in Subtasks verfeinern, die vom Modellierer der Domäne speziell dafür vorgesehen wurden. Ausgehend von einem 5

12 2. Hybrides Planen initialen, partiellen, teilweise abstrakten Plan wird beim HTN-Planen durch erschöpfendes Anwenden von Dekompositionsmethoden auf abstrakten Tasks der initiale, partielle Plan immer weiter verfeinert, bis schlussendlich der Lösungsplan nur noch aus primitiven Tasks besteht, die vom Nutzer direkt ausgeführt werden können. Diese schrittweise Verfeinerung ähnelt der menschlichen Herangehensweise komplexe Probleme in einfachere Subprobleme zu unterteilen. Basierend auf den vorgestellten Eigenschaften lassen sich mittels HTN-Planen anspruchsvolle Probleme in der realen Welt lösen. Hybrides Planen kombiniert die oben vorgestellten Merkmale der zwei Planungsarten. Dadurch ist es möglich Expertenwissen und kausales Schließen zu vereinen. Abstrakte Tasks haben, im Gegensatz zum HTN-Planen, selbst auch Vor- und Nachbedingungen und können mittels kausalem Schließen in bestehende Pläne integriert werden. Dadurch wird hybrides Planen zu einem mächtigen Werkzeug, welches flexibel und anpassungsfähig genug ist, um beispielsweise Unterstützung bei der Bedienung von technischen Geräte bieten zu können [1]. Die Smartphone-Domäne wurde im Zuge der Publikation von Biundo et al. [1] entwickelt und behandelt die Bedienung eines Smartphones. Dabei geht es vor allem um die Navigation durch dessen Menüs sowie die Verwendung von Standard-Diensten. Bei diesen Standard-Diensten handelt es sich um das Tätigen von Anrufen, das Versenden von s und MMS, das Erstellen von Alarmen, Kontakten, Terminen sowie Aufgaben. Diese Dienste sind in den Basisfunktionen aller heutzutage handelsüblichen Smartphones vorhanden. Dieses Domänenmodell wird im Rest der Arbeit zur Veranschaulichung des Formalismus im nächsten Kapitel sowie in der Visualisierung verwendet Formalismus Im Folgenden soll nun der Formalismus des hybriden Planens vorgestellt werden, dessen Darstellung an die Publikation von Biundo et al. [1] angelehnt ist Die logische Sprache L Der Formalismus des Hybriden Planens beruht auf einer geordneten, quantor-freien Prädikatenlogik 1. Ordnung. Die zugrunde liegende Sprache L wird durch das Tupel Z,<,R,C,V,L beschrieben. Z steht für die Menge an verschiedenen Sorten, wobei gilt, dass jede Variable und Konstante zu einer Sorte z Z gehört. < drückt die Hierarchie auf den Sorten aus Z aus; so ist es möglich, dass eine Sorte mehrere Subsorten besitzen kann. R besteht aus einer Menge an Relationen, mit dessen Hilfe Eigenschaften von Objekten präzisiert werden können. Des Weiteren ist C eine Menge von Konstantensymbolen, mit welchen sich Objekte referenzieren 6

13 2.1. Formalismus lassen. Eine Konstante c C beschreibt somit genau ein Objekt und besitzt eine Signatur z Z. V repräsentiert alle Variablensymbole, die, genau wie jede Konstante, eine Signatur z Z besitzen. In der Smartphone-Domäne gibt es beispielsweise die Sorten Contactable, Message, SMS und MMS. Contactable beschreibt hierbei einen Kontakt, Message eine Nachricht, wobei es sich bei SMS und MMS um Subsorten von Message handelt. Es gilt somit formal SMS < Message sowie MMS < Message. contact1 C wäre ein Beispiel für eine Konstante der Sorte Contactable Z. Um Variablen und Konstanten besser auseinander zu halten, wird die in PDDL [6] eingeführte Konvention verwendet jeder Variablen ein Fragezeichen voranzustellen. Bei PDDL handelt es sich um eine Standardsprache zur Beschreibung von nicht-hierarchischen Planungsdomänen und -problemen. L besteht schließlich aus einer unendlichen Menge an Labels, die dazu benutzt werden um an sich identische Tasks, wie sie in partiellen Plänen vorkommen können, zu unterscheiden Tasks T Alle Tasks innerhalb einer Domäne werden in der Menge T zusammengefasst, wobei jeder einzelne Task t den Zustand s in den Folgezustand s überführt, sofern der Task t in s anwendbar ist. Ein Zustand bezeichnet hier eine endliche Menge an grundierten Atomen, die zu einem Zeitpunkt gelten. Jeder Task t T besteht aus dem Tupel pre, post, wobei pre für die Vorbedingungen und post für die Nachbedingungen des Tasks stehen. Vorund Nachbedingungen bestehen aus Konjunktionen von Literalen über den Task-Parametern τ = τ 1...τ n. Der Task contact(contactable?c, Message?m)= havesent(?m), hasreceived(?c,?m) havesent(?m) aus der Smartphone-Domäne bedingt beispielsweise für den Fall, dass ein Kontakt mit Hilfe einer Nachricht kontaktiert werden soll, dass die Nachricht noch nicht gesendet worden sein darf; nach Ausführung des Tasks hat der Kontakt die Nachricht erhalten und die Nachricht wurde versandt. Um den grundierten Task t in Zustand s anwenden zu können, müssen sowohl alle positiven Literale aus pre in s vorhanden sein als auch alle negativen Literale in s fehlen. Nach Anwendung von t werden alle positiven Literale in post zum Zustand s hinzugefügt und alle negativen Literale aus s entfernt, was zum neuen Zustand s führt. Tasks können, wie bereits beschrieben, abstrakt oder primitiv sein, d.h. T = T primitiv T abstrakt. Primitive Tasks lassen sich ohne weiteres vom Benutzer ausführen, wohingegen abstrakte Tasks erst mittels Dekompositionsmethoden weiter verfeinert werden müssen Dekompositionsmethoden werden in Kapitel näher erläutert. 7

14 2. Hybrides Planen Pläne Ein partieller Plan wird beschrieben durch P = PS,,VC,CL, wobei PS (Plan Steps) für die Menge an Planschritten steht. Ein Planschritt ps PS ist ein Paar l : t, bestehend aus einem (partiell) gegrundeten Task t T sowie einem Label l L mit dem Planschritte, die dieselben Tasks beinhalten, unterschieden werden können. repräsentiert die Menge an expliziten Ordnungsbeziehungen, die besagen, dass Planschritt ps i vor Planschritt ps j ausgeführt werden muss, falls gilt ps i ps j mit ps i, ps j PS. VC (Variable Constraints) stehen für eine Menge an Variablenbedingungen, die es erlauben Gleichheit sowohl als auch Ungleichheit von Variablen mit Variablen sowie auch zwischen Variablen und Konstanten festzulegen. Die Menge an kausalen Links wird in CL (Causal Links) repräsentiert, wobei jeder kausale Link c CL in der Form l i,φ,l j dargestellt wird. l i steht dabei für den Planschritt ps i = l i : t i der eine nötige Vorbedingung φ für Planschritt ps j = l j : t j liefert. φ muss sowohl mit einem Literal aus pre als auch mit einem Literal aus post unifizierbar sein und bedingt damit, dass ps i vor ps j ausgeführt wird. Im Folgenden sollen mit partiellen Plänen sämtliche Tupel bezeichnet werden, die den oben beschriebenen Strukturen entsprechen, wohingegen mit Plänen nur solche partiellen Pläne bezeichnet werden, welche eine Lösung des gegebenen Planungsproblems beschreiben. Die Formalisierung hybrider Planungsprobleme und ihren Lösungskriterien werden in Abschnitt 2.2 behandelt Domäne D & Dekompositionsmethoden M Die Domäne lässt sich mit Hilfe des Tupels D = L,T,M beschreiben, welches aus der logischen Sprache L, der Menge an Tasks T sowie der Menge an Dekompositionsmethoden M besteht. Wie weiter oben erläutert wurde, lässt sich die Menge der Tasks T in eine Teilmenge von primitiven Tasks (T primitiv ), die sich nicht weiter zerlegen lassen, sowie eine Menge an abstrakten Tasks (T abstrakt ) unterteilen. Abstrakte Tasks besitzen, genau wie primitive Tasks, Vor- und Nachbedingungen, damit sie in eine partiellen Plan eingefügt werden können [2], wobei sie sich jedoch nicht direkt durch den Benutzer anwenden lassen. Dazu müssen sie zuerst mittels Dekompositionsmethoden verfeinert (dekomponiert) werden. Eine Dekompositionsmethode m = t,vc, P M verfeinert hierzu den abstrakten Task t in den partiellen Plan P, der den abstrakten Task t repräsentiert, wobei die Variablenbedingungen VC die Variablen von t mit den Variablen von P in Verbindung setzen. Abbildung 2.1 zeigt 8

15 2.1. Formalismus die Verfeinerung des abstrakten Tasks send_sms mittels zweier verschiedener Dekompositionsmethoden (do_send_sms_viafavourites und do_send_sms_viamessages) in zwei unterschiedliche partielle Pläne. Abbildung 2.1.: Verfeinerung eines abstrakten Tasks mittels zweier Dekompositionsmethoden Hybrides Planungsproblem Ein hybrides Planungsproblem lässt sich mittels folgendem Tupel π = D,P init beschreiben, wobei D die Domäne und P init den initialen, partiellen Plan bezeichnet. Dieser partielle Plan enthält zusätzlich zwei künstliche Planschritte ps init und ps goal um den Startund Endzustand zu kodieren. Zwischen diesen beiden Planschritten befinden sich alle anderen Planschritte, die sich schon innerhalb des partiellen Plans befinden oder im Laufe des Suchprozesses in diesen partiellen Plan eingefügt werden. Um sicherzustellen, dass es sich bei P sol = PS sol,< sol,vc sol,cl sol um einen gültigen Lösungsplan für das hybride Planungsproblem π handelt, muss dieser Plan P sol folgende Eigenschaften erfüllen: 9

16 2. Hybrides Planen 1. P sol muss durch Verfeinerung von P init entstanden sein. Verfeinerungen bezeichnen das Anwenden von Dekompositionsmethoden, das Einfügen von Tasks, Variablenbedingungen, kausalen Links sowie Ordnungsbedingungen. 2. P sol darf nur aus primitiven Tasks bestehen, da abstrakte Tasks nicht ausführbar sind. 3. Jedes Literal in jeder Vorbedingung eines Planschrittes in P sol muss durch einen kausalen Link erfüllt sein, damit die Abfolge der Planschritte ausgeführt werden kann. 4. Es darf keine kausalen Bedrohungen geben, d.h. alle Planschritte sind so angeordnet, dass die Nachbedingungen eines jeden Planschrittes keine Vorbedingungen aller möglichen, darauffolgenden Planschritte verletzen. Durch die Eigenschaften 2 bis 4 wird sichergestellt, dass alle Linearisierungen eines Lösungsplans P sol ausführbar sind und Eigenschaft 1 erlaubt nur solche, die aus der Verfeinerung des initialen, partiellen Plans entstanden sind. Eine mögliche Vorgehensweise um einen Lösungsplan P sol für ein hybrides Planungsproblem π zu finden wird in Kapitel 2.2 vorgestellt Lösen von hybriden Planungsproblemen In diesem Kapitel wird eine ausgewählte Herangehensweise vorgestellt um einen möglichen Lösungsplan für ein gestelltes hybrides Planungsproblem zu finden. Ausgehend von einem initialen, partiellen Plan wird dieser mittels sukzessiver Verfeinerung in einen Lösungsplan P sol überführt. Die dazu verwendete Vorgehensweise sieht vor, dass jeweils ein partieller Plan P aus der Liste aller bereits erstellten partiellen Pläne, die noch weiter verfeinert werden müssen, der sogenannten Fringe, entnommen wird. Zu Beginn enthält diese Fringe nur den initialen, partiellen Plan P init. Daraufhin wird überprüft, ob dieser partielle Plan P allen Lösungskriterien, wie sie in Kapitel vorgestellt wurden, genügt. Falls ja, handelt es sich bei P um eine Lösung und diese wird zurückgegeben. Falls nicht, besitzt P eine oder mehrere Eigenschaften, die die oben genannten Lösungskriterien verletzen. Eigenschaften, die Lösungskriterien verletzen, nennt man Flaws. Flaws lassen sich in verschiedene Klassen, abhängig von dem Lösungskriterium, welches sie verletzen, unterteilen. Enthält ein partieller Plan P beispielsweise einen abstrakten Task t, so besitzt er einen Flaw f der Klasse F AbstrakterTask. Um diesen Flaw zu beheben, muss eine passende Modifikation m gewählt werden, nach deren Anwendung der partielle Plan P frei von Flaw f ist. In dem gewählten Beispiel muss demnach eine passende Dekompositionsmethode für den abstrakten Task t ausgewählt werden. Analog zu den Flaws lassen sich auch die Modifikationen in verschiedene Klassen unterteilen. Des Weiteren lässt sich festhalten, dass eine gewisse Beziehung zwischen den verschiedenen Flaw-Klassen und Modifikationsklassen besteht. So lässt sich zum Beispiel ein Flaw der Klasse F AbstrakterTask nur von einer Modifikation der Klasse 10

17 2.2. Lösen von hybriden Planungsproblemen M ExpandiereTask beseitigen. Tabelle 2.1 geht genauer auf die Beziehung zwischen den einzelnen Flaw-Klassen und ihren jeweils auflösenden Modifikationsklassen ein. Lösungskriterium Flaw-Klasse Modifikationsklasse 1 2 F AbstrakterTask M ExpandiereTask 3 F O f f enevorbedingung M ErzeugeKausalenLink, M ExpandiereTask, M FuegeTaskEin 4 F KausaleBedrohung M ExpandiereTask, M ErzeugeOrdnung, M BindeVariable, M Separation Tabelle 2.1.: Diese Tabelle beschreibt die Flawklassen, die die jeweiligen Lösungskriterien eines Plans verletzen, sowie ihre Modifikationsklassen, die die Flaws der jeweiligen Klassen potentiell beheben Nachdem alle Flaws des selektierten, partiellen Plans P berechnet wurden, wird ein Flaw ausgewählt, der behoben werden soll. Für diesen Flaw werden alle möglichen Modifikationen berechnet, die diesen Flaw beheben. Diese Modifikationen werden auf P angewandt und die daraus resultierenden Pläne in die Fringe eingefügt. Dies wird solange wiederholt bis entweder ein gültiger Lösungsplan gefunden wurde oder die Fringe leer ist, was bedeutet, dass für dieses Planungsproblem keine gültige Lösung gefunden werden konnte. Dieses Vorgehen wird durch Algorithmus 1 beschrieben. Algorithm 1: Planungsalgorithmus input : Die Menge Fringe = {P init }. output: Ein Lösungsplan oder fail 1 while Fringe /0 do 2 P plansel (Fringe) 3 Fringe Fringe \ {P} 4 Flaws flawdetection(p) 5 if Flaws = /0 then return P 6 f flawsel (Flaws) 7 Fringe Fringe { applymod(p,m) m genmods( f )} 8 return fail Mittels der Funktion plansel (Zeile 2) wird aus der Fringe ein partieller Plan P selektiert und in Zeile 3 aus ihr entfernt. Im nächsten Schritt wird die Menge an Flaws in P durch die Methode flawdetection ermittelt und in der Menge Flaws festgehalten. Ist diese Menge leer, so handelt es bei P um eine Lösung, die zurückgegeben wird. Anderenfalls wird ein Flaw f mit Hilfe der Funktion flawsel aus der Menge Flaws ausgewählt um diesen zu beheben. In Zeile 7 wird die Menge aller möglichen Modifikationen für diesen Flaw f berechnet, daraus jede Modifikation mittels der Methode applymod auf P an- 11

18 2. Hybrides Planen gewandt und die daraus resultierenden partiellen Nachfolgerpläne in die Liste der noch zu betrachtenden, partiellen Pläne, der Fringe, eingefügt. Dieser Vorgang wird wiederholt, bis entweder eine Lösung gefunden oder die Fringe leer ist, in letzterem Fall gilt als bewiesen, dass keine Lösung existiert; entsprechend wird fail zurückgegeben (Zeile 8). 12

19 3. Datenstruktur der Visualisierung Nachdem die formalen Grundlagen für die Visualisierung vorgestellt wurden, soll im folgenden Kapitel auf die zugrunde liegende Datenstruktur der Visualisierung eingegangen werden: den Task Decomposition Tree. Es soll an dieser Stelle betont werden, dass mit Hilfe des Task Decomposition Trees nicht nur die Struktur der Domäne visualisiert werden soll; dazu wäre eine separate Datenstruktur nicht erforderlich, da alle Informationen in der Domäne hinterlegt sind und diese lediglich zu visualisieren wären. Der Task Decomposition Tree soll hingegen jede mögliche Dekomposition eines jeden Tasks beinhalten. Um diesen Unterschied zu illustrieren, stelle man sich folgendes Beispiel vor: Innerhalb einer Domäne gebe es einen abstrakten Task t(?v) mit genau einer möglichen Dekompositionsmethode. Im initialen, partiellen Plan käme nun sowohl Task t(c 1 ), wobei?v an die Konstante c 1 gebunden ist, als auch Task t({c 2,c 3 }) vor, wobei hier der Wertebereich von?v die Konstante c 2 und c 3 beinhaltet. Dadurch gäbe es zwei Dekompositionen, die sich hinsichtlich ihrer Variablenbelegung unterscheiden würden, somit unterschiedlich wären und auch zwei mal dargestellt werden würden. Daraus resultierend muss der Task Decomposition Tree berechnet werden und kann nicht in simpler Weise aus der Domäne erstellt werden. Für die Berechnung des Task Decomposition Trees wird auf die Architektur des PANDA 2 -Planers zurückgegriffen werden, da dieser die dafür nötigen, effizienten Algorithmen und Strukturen beinhaltet. Für die Visualisierung wird demnach eine Struktur benötigt, die alle möglichen Dekompositionen eines jeden Tasks der Domäne kapselt und derart aufbereitet, dass auf die verfügbaren Informationen einfach und schnell zugegriffen werden kann. Die Datenstruktur soll dabei so effizient wie möglich aufgebaut sein; hierzu soll ein Großteil der vorhandenen Datenstrukturen des PANDA 2 -Planers verwendet werden. Ein weiteres Merkmal der Datenstruktur besteht darin, dass sie von der später verwendeten Visualisierung unabhängig ist. Dies ist wichtig, da sich die Datenstruktur nicht mehr ändern sollte, wohingegen die Visualisierungen austauschbar sein sollen. Dies führt uns zu den Anforderungen an die Datenstruktur, die beim Entwurf berücksichtigt werden müssen Anforderungen Die Anforderungen lassen sich grob in zwei Kategorien unterteilen. Auf der einen Seite befinden sich die technischen Anforderungen, die den Aufbau der Daten- 13

20 3. Datenstruktur der Visualisierung struktur betreffen, auf der anderen Seite die visuellen Anforderungen, die festlegen, was die Datenstruktur speichern muss, um die Visualisierung zu ermöglichen Technische Anforderungen 1. Schnelle Berechnung Darunter verstehen wir die Tatsache, dass die Datenstruktur aus der Domäne so schnell wie möglich erstellt werden kann. Dies ist wichtig, da die Wartezeit bis zur Darstellung der Domäne für den Benutzer auf ein Minimum reduziert werden soll. 2. Geringer Speicherverbrauch Eng verwandt mit Punkt 1 ist die Anforderung, dass die Datenstruktur so wenig Speicher wie möglich verwenden soll. Diese Anforderung ergibt sich aus der Tatsache, dass die Datenstruktur nicht nur von der Visualisierung benutzt wird, sondern zukünftig auch innerhalb des Planers verwendet werden soll. Eine detailliertere Erläuterung dieser Einsatzmöglichkeit wird in Kapitel vorgestellt. 3. Kompatibel mit den vorhandenen PANDA 2 -Strukturen Ziel des Entwurfes ist es, so viel wie möglich der schon vorhandenen Strukturen des PANDA 2 -Planers wiederzuverwenden. Darunter fallen Algorithmen sowie auch die Datenstrukturen die vom PANDA 2 -Planer benutzt werden. Dadurch wird Redundanz vermieden und hierdurch die spätere Wartung des Quelltextes deutlich erleichtert sowie die Fehlerwahrscheinlichkeit reduziert. 4. Unabhängigkeit von verwendeter Visualisierung Wie schon am Anfang des Kapitels erwähnt, soll die Datenstruktur als Grundlage für die Visualisierung dienen, jedoch nicht von einer konkreten Umsetzung einer Visualisierung abhängen. Dadurch wird garantiert, dass einzelne Visualisierungen später leicht untereinander ausgetauscht, neue Visualisierungen entwickelt sowie mehrere Visualisierungen gleichzeitig für ein- und dieselbe Domäne verwendet werden können Visuelle Anforderungen 1. Darstellung der Domäne Die Datenstruktur soll in der Lage sein, das Domänenmodell darzustellen, d.h. es sollen alle möglichen Dekompositionen aller Tasks darstellt werden, die innerhalb der Domäne möglich sind. 2. Darstellung einer Probleminstanz Abseits der Möglichkeit die komplette Domäne darzustellen, soll auch die Option bestehen diejenige Darstellung der Domäne, die durch den initialen, partiellen Plan entsteht, darstellen zu können. Diese zeichnet sich durch eine mögliche Einschränkung auf eine Untermenge an Tasks im Vergleich zur kompletten Domäne aus sowie einer möglichen 14

21 3.2. Struktur des Task Decomposition Trees größeren Menge an Konstanten, die durch den initialen, partiellen Plan hinzugefügt werden. Zur Vermeidung von Unklarheiten muss hier erwähnt werden, dass in Kapitel 2 formal die Menge der Konstanten C nicht in eine Menge von Konstanten der Domäne sowie der Probleminstanz aufgeteilt wird, da C zur logischen Sprache L gehört. In der Architektur des PANDA 2 -Planers kann die Probleminstanz jedoch eine eigene Menge an Konstanten besitzen. Die obige Erklärung bezieht sich daher auf die Repräsentation des PANDA 2 - Planers. 3. Repräsentation von Planstruktur Es soll möglich sein die Planstruktur von Plänen, d.h. die Ordnungsbeziehungen und kausalen Links (siehe Kapitel 2.1.3) darzustellen. Dies ist ein sehr wichtiger Punkt für die Möglichkeit eine Domäne mit Hilfe der Visualisierung zu inspizieren und auf Fehler zu untersuchen. Auch erleichtert die Darstellung von Planstruktur das Verständnis der Domäne, da sie aufzeigt welche Ordnungsbeziehungen und kausalen Zusammenhänge zwischen einzelnen Tasks vorliegen. 4. Anzeige von Variablen, deren Wertebereiche sowie Variablenbedingungen Auch dieser Punkt betrifft die Tatsache, dass mit Hilfe der Visualisierung leichter nach Fehlern gesucht werden kann. So soll die Möglichkeit bestehen, sich in der Domäne deren Variablen anzeigen zu lassen sowie deren Wertebereiche. Außerdem soll der Benutzer sich die Variablenbedingungen, die innerhalb einer Planes vorliegen, darstellen lassen können. 5. Verschiedene Layouts Die Datenstruktur soll mittels verschiedener Layouts dargestellt werden können. Damit sollen verschiedene Ansichten auf die gleiche Datenstruktur ermöglicht werden, wobei jede Ansicht unterschiedliche Schwerpunkte in der Visualisierung setzen kann. So könnte sich beispielsweise ein Layout auf die Darstellung von Planstruktur konzentrieren, ein anderes Layout hingegen mehr die Bedeutung der vorliegenden Hierarchie herausarbeiten. Des Weiteren bietet sich dem Nutzer dadurch die Möglichkeit von ihm präferierte Layouts zur Darstellung der Domäne zu benutzen. Kapitel 4 bietet einen Überblick über die umgesetzten Visualisierungen und diskutiert deren jeweiligen Vor- und Nachteile Struktur des Task Decomposition Trees Anhand der oben angeführten Anforderungen wurde eine Datenstruktur entworfen, die all diese erfüllt. Als Grundstruktur wurde ein bipartiter, endlicher Und/Oder-Baum gewählt, der sogenannte Task Decomposition Tree, welcher sich mittels des Tupels N M,N T,E 15

22 3. Datenstruktur der Visualisierung darstellen lässt. N M bezeichnet die Menge an Methoden-Knoten, N T die Menge an Task-Knoten und E die Menge an Kanten, welche die Knoten untereinander verbinden. Der Aufbau des Task Decomposition Trees besteht aus einer ersten Schicht, in der sich ausschließlich Task-Knoten, die die Tasks des initialen, partiellen Plans repräsentieren, befinden. In der darauffolgenden Schicht befinden sich ausschließlich Methoden-Knoten, bei denen es sich um Nachfolger von abstrakten Task-Knoten handelt, da sich primitive Tasks nicht weiter dekomponieren lassen. Diese zwei Schichten wechseln sich nun solange ab bis alle abstrakten Tasks dekomponiert wurden. Ein schematischer Aufbau des Task Decomposition Trees wird in Abbildung 3.1 dargestellt. t 1 t 2 m 11 m 12 m 13 m 21 m 22 and and and t 111 t 112 t 121 t 131 t 132 t 211 t 221 t 222 Abbildung 3.1.: Schematischer Aufbau des Task Decomposition Trees Da es im Allgemeinen die Möglichkeit der Rekursion in einer Domäne gibt, muss diese Möglichkeit auch im Task Decomposition Tree berücksichtigt werden. Eine Rekursion kann beispielsweise in folgendem Fall auftreten: Es gebe in einer Domäne zwei abstrakte Tasks t, t sowie zwei Dekompositionsmethoden m 1 und m 2 welche t verfeinern. m 1 verfeinert t in einen partiellen Plan, der nur aus t besteht, m 2 verfeinert t hingegen in einen partiellen Plan, welcher aus t und t besteht. Exakt dieses Szenario tritt in der Smartphone-Domäne auf (siehe Abbildung 3.2). Durch die Rekursion gibt es die Möglichkeit den Task t beliebig oft einzufügen. Abbildung 3.2.: Rekursion in der Smartphone-Domäne Dies ist von Bedeutung in rein-hierarchischen Domänen, in welchen Tasks nicht beliebig in 16

23 3.3. Erstellung des Task Decomposition Trees partielle Pläne eingefügt werden dürfen. Da ein Baum keine Rekursion unterstützt, wird dieses Problem dadurch gelöst, dass ein schon dekomponierter Task-Knoten zwar erneut als Task-Knoten im Baum hinterlegt wird, jedoch nicht ein weiteres Mal dekomponiert wird; er wird dahingegen als schon dekomponiert markiert. Ein Task-Knoten n t N T ist die Repräsentation eines einzelnen Tasks, daher speichert ein Task- Knoten eine Referenz auf den darzustellenden Task, wobei ein Task t T die Task-Parameter τ = t 1...t n besitzt (siehe Kapitel 2.1.2). Formal gilt somit für einen Task-Knoten n t = t. Die Identität zweier Task-Knoten n t1 = t 1 sowie n t2 = t 2 gilt genau dann, wenn die Anzahl ihrer jeweiligen Task-Parameter übereinstimmt sowie sich jeder Task-Parameter von t 1 mit einem Task-Parameter von t 2, unter Betrachtung der jeweils geltenden Variablenbedingungen für jeden Task, unifizieren lässt. Die Variablenbedingungen, die für einen bestimmten Task- Knoten gelten, werden in dessen jeweiligen Vater-Knoten gespeichert, bei dem es sich um einen Methoden-Knoten handelt. Methoden-Knoten repräsentieren jeweils eine Dekompositionsmethode m = t,vc, P = PS,, VC,CL, wobei die Planschritte PS des partiellen Plans P durch Task-Knoten repräsentiert werden, die die Kinder des jeweiligen Methoden-Knotens im Task Decomposition Tree sind. Formal besteht ein Methoden-Knoten n m N M somit aus dem Tupel m. Für alle Tasks des initialen, partiellen Plans gilt, dass diese als Task-Knoten Element der ersten Schicht des Task Decomposition Trees sind. Für die Menge der Kanten E gelten nun folgende Eigenschaften. Handelt es sich bei m = t,vc,p M um eine Dekompositionsmethode für einen Task-Knoten n t = t N T, so gilt m N M und es existiert eine Kante e = (n t, m ) E. Existiert ein Methoden-Knoten n m = t,vc,p = PS,VC,, CL N m so existiert auch für jeden Planschritt ps i = l i : t i PS ein Task-Knoten n ti = t i sowie eine Kante (n m,n ti ) E. Durch diese Eigenschaften wird gewährleistet, dass ein Task-Knoten n t = t nur mit Methoden-Knoten verbunden ist, die auch dessen repräsentierten Task t verfeinern. Des Weiteren ist ein Methoden-Knoten n m = t,vc,p nur mit den jeweiligen Task-Knoten verbunden, die mit den Tasks des partiellen Plans P korrespondieren. Alternativ kann der Task Decomposition Tree auch mit Hilfe eines Graphen anstatt eines Baumes ausgedrückt werden [4] Erstellung des Task Decomposition Trees In diesem Kapitel wird kurz der Aufbau des PANDA 2 -Planers vorgestellt sowie dargelegt wie der in Kapitel 2 vorgestellte Planungsalgorithmus (siehe Algorithmus 1) mittels einiger Änderungen so umkonfiguriert wird, dass er zur Erstellung des Task Decomposition Trees benutzt werden kann. Dazu sollen zunächst die Unterschiede des Planungsalgorithmus zu der Erstellung des Task 17

24 3. Datenstruktur der Visualisierung Decomposition Trees herausgearbeitet werden und daraufhin der verwendete Algorithmus zur Erstellung des Task Decomposition Trees präsentiert werden Aufbau des PANDA 2 -Planers Da die Datenstruktur der Visualisierung die Datenstrukturen des PANDA 2 -Planers der Universität Ulm mit benutzt, soll in diesem Kapitel kurz dessen Funktionsweise erläutert werden. Der PANDA 2 -Planer ist ein Planer, welcher basierend auf dem in Kapitel 2 vorgestellten Planungsalgorithmus in der Lage ist sowohl nicht-hierarchische als auch hierarchische Planungsprobleme zu lösen. Wird eine Domäne sowie ein dazu passendes Planungsproblem in den PANDA 2 - Planer geladen, so wird daraus eine 1:1-Darstellung dieser Daten aus Java-Objekten kreiert; diese Darstellung wird als kanonische Darstellung bezeichnet (siehe Abbildung 3.3). Um das gestellte Planungsproblem lösen zu können, wird die kanonische Darstellung optimiert, d.h. sie wird in eine effiziente Darstellung überführt, die der kanonischen Darstellung entspricht. Auf dieser effizienten Darstellung, wird der Planungsalgorithmus angewandt und eine mögliche Lösung für das gestellte Planungsproblem, P sol, gefunden. Abbildung 3.3.: Aufbau des PANDA 2 -Planers Die effiziente Darstellung wird auch in der Datenstruktur der Visualisierung verwendet, da der Task Decomposition Tree mit den vorhandenen Algorithmen des PANDA 2 -Planers aufgebaut werden wird, welche auf der effizienten Darstellung operieren Änderungen am ursprünglichen Planungsalgorithmus Rekapituliert man Algorithmus 1, so wird in diesem ein partieller Plan aus der Fringe selektiert, dessen Flaws ermittelt und daraus ein Flaw ausgewählt, der daraufhin behoben wird. Die daraus resultierenden Nachfolgepläne werden in die Menge der partiellen Pläne, die noch weiter verfeinert werden müssen, eingefügt. Sobald ein partieller Plan gefunden wird, der den Lösungskriterien entspricht, terminiert der Algorithmus, d.h. es handelt sich um ein sequentielles Vorgehen, welches sukzessive alle Flaws behebt bis ein gültiger Plan gefunden wurde. 18

25 3.3. Erstellung des Task Decomposition Trees Im Folgenden soll dieser ursprüngliche Algorithmus als Ausgangsbasis dienen, der mittels weniger Änderungen derart modifiziert wird, dass er für die Erstellung des Task Decomposition Trees verwendet werden kann. Da die Aufgabe des zu entwickelnden Algorithmus nicht darin besteht ein Planungsproblem zu lösen, sondern der Task Decomposition Tree erstellt werden soll, welcher jede Dekomposition eines jeden abstrakten Tasks in der Domäne darstellt, lässt sich zunächst einmal die Anzahl der zu betrachtenden Flaw-Klassen auf die Klasse F AbstrakterTask einschränken. Daraus folgt, dass alle möglichen Modifikationen der Klasse M ExpandiereTask angehören und es sich um Dekompositionsmethoden handelt. Als Nächstes soll erläutert werden wie der ursprüngliche Algorithmus Modifikationen auf partiellen Plänen anwendet. Wurde eine passende Modifikation m M für einen Flaw f eines partiellen Plans P generiert und diese nun auf P angewandt, so werden die Änderungen in P eingefügt. Diese Vorgehensweise soll in Abbildung 3.4(a) illustriert werden. Bei P 1 soll es sich hierbei um einen partiellen Plan handeln, der drei Tasks beinhaltet, wobei t 2 T abstrakt und t 1,t 3 T primitiv. Nun gebe es genau eine Dekompositionsmethode m M, die den abstrakten Task t 2 verfeinert, welche auf den partiellen Plan P 1 angewandt wird. Diese Anwendung führt dazu, dass der abstrakte Task t 2 durch dessen äquivalenten partiellen Plan P ersetzt und P korrekt in P 1 eingefügt wird, woraus ein neuer, partieller Plan P 2 entsteht. (a) Anwendung einer Dekompositionsmethode (b) Dekomposition auf einem künstlichen, partiellen Plan Abbildung 3.4.: Gegenüberstellung der Dekompositionen Zur Erstellung des Task Decomposition Trees ist jedoch von Interesse, wie ein einzelner abstrakter Task dekomponiert wird, d.h. in diesem Beispiel wäre P relevant, jedoch nicht der 19

26 3. Datenstruktur der Visualisierung resultierende partielle Plan P 2. Da die Funktionsweise des Planungsalgorithmus beibehalten werden soll, besteht das Problem darin, lediglich den partiellen Plan P zu erhalten. Dies kann man lösen, in dem ein künstlicher, partieller Plan P art = {ps 2 = l 2 : t 2 }, /0, /0, /0 erstellt wird, welcher nur den abstrakten Task t 2 enthält. Wenn man daraufhin die Dekompositionsmethode m auf P art anwendet, erhält man als Resultat einen partiellen Plan der nur diejenigen Tasks enthält, die t 2 repräsentieren (siehe Abbildung 3.4(b)). Darauf folgt, dass wenn man den Task Decomposition Tree mit diesem Ansatz erstellen will, so darf die Fringe nur aus künstlichen, partiellen Plänen bestehen, die jeweils einen abstrakten Task enthalten. Um den Task Decomposition Tree zu erstellen, erstellt man als Erstes einen speziellen Methoden-Knoten, welcher dem Wurzelknoten entspricht, da für diesen keine Dekompositionsmethode m M existiert. Für jeden Planschritt des initialen Problems P init wird ein korrespondierender Task-Knoten erstellt und mit dem Wurzelknoten verbunden. Falls ein Planschritt einen abstrakten Task enthält, so wird daraus ein künstlicher, partieller Plan erstellt, der genau diesen abstrakten Task enthält, und in die Fringe eingefügt. Entnimmt man nun einen künstlichen, partiellen Plan P = {l : t}, /0, /0, /0 aus der Fringe, so wird für jede mögliche Dekompositionsmethode von t ein korrespondierender Methoden-Knoten n m erstellt und mit dem Task-Knoten, welcher t repräsentiert, verbunden. Nach Anwendung einer Dekompositionsmethode m auf P erhält man, da P nur t beinhaltet, einen partiellen Plan P, welcher exakt alle Tasks enthält, die den abstrakten Task t wie in m festgelegt verfeinern. Für jeden dieser Tasks wird ein korrespondierender Task-Knoten erstellt und mit dem Methoden-Knoten verbunden, welcher die angewandte Dekompositionsmethode repräsentiert. Des Weiteren wird für jeden Planschritt des Plans P, der einen abstrakten Task enthält, ein partieller, künstlicher Plan erstellt und in die Fringe eingefügt. Dieses Vorgehen wird solange wiederholt bis alle abstrakten Tasks dekomponiert wurden und der Task Decomposition Tree damit erstellt wurde. In Abbildung 3.5 wird ein Arbeitsschritt zur Erstellung des Task Decomposition Trees illustriert. Auf der rechten Seite befindet sich eine Darstellung des Task Decomposition Trees und in der Mitte soll die Verfeinerung eines partiellen Plans veranschaulicht werden. Aus der Fringe wird nun ein künstlicher, partieller Plan P entnommen, dessen Task t einen korrespondierenden Task-Knoten n t im Task Decomposition Tree besitzt. In diesem Beispiel gebe es nun genau eine Dekompositionsmethode m, welche t verfeinert. Für diese Dekompositionsmethode wird ein äquivalenter Methoden-Knoten n m erstellt und mit n t verbunden. Aus der Anwendung von m auf P resultiert der partielle Plan P, welcher aus drei Tasks besteht, wobei t 1,t 3 T abstrakt und t 2 T primitiv. Für jeden dieser Tasks wird ein Task-Knoten im Task Decomposition Tree erstellt (n t1,n t2,n t3 ) und mit n m verbunden; zusätzlich werden für t 1 sowie t 3 künstliche, partielle Pläne erstellt (P art 1,P art 2 ) und diese in die Fringe eingefügt. 20

27 3.3. Erstellung des Task Decomposition Trees Abbildung 3.5.: Darstellung einer Dekomposition eines partiellen Plans P sowie dessen Repräsentation im Task Decomposition Tree. P wird durch m M in den partiellen Plan P verfeinert, wodurch der Task t durch die abstrakten Tasks t 1,t 3 sowie den primitiven Task t 2 ersetzt wird. Für die abstrakten Tasks werden künstliche, partielle Pläne erstellt, welche in die Fringe eingefügt werden Algorithmus zur Erstellung des Task Decomposition Trees Algorithmus 2 beschreibt den Konstruktionsprozess des Task Decomposition Trees ausgehend von einem gegebenen hybriden Planungsproblem π = D,P init. Der Rückgabewert des Algorithmus liefert den daraus erstellten Task Decomposition Tree. Zuerst wird in der Vorbereitungsphase der Wurzelknoten des Task Decomposition Trees erstellt, bei dem es sich um eine speziell gekennzeichnete Instanz des Typs Methoden-Knoten handelt und dieser Knoten zu der Menge N M, den Methoden-Knoten, hinzugefügt. Des Weiteren werden aus den Planschritten des initialen, partiellen Plans die korrespondierenden Task-Knoten erstellt und mit dem Wurzelknoten verbunden (Zeile 3-4). In der nächsten Zeile wird die Fringe mit den künstlichen, partiellen Plänen gefüllt, die aus den Planschritten des initialen, partiellen Plans erstellt werden. Die Menge der expandierten Tasks wird mit der leere Menge initialisiert, was die Vorbereitungsphase beendet. In der Hauptschleife wird, solange die Fringe nicht leer ist, ein künstlicher, partieller Plan P = {ps = l : t}, /0, /0, /0 selektiert und aus der Fringe entnommen. Dieses Vorgehen ist analog zum ursprünglichen Algorithmus. Als Nächstes wird in Zeile 10 überprüft, ob der Task t schon einmal expandiert wurde. Ist dies der Fall, so muss keine Verfeinerung vorgenommen werden und der nächste partielle Plan kann betrachtet werden. Anderenfalls wird in Zeile 11 die Menge der Flaws von P berechnet und ein Flaw f selektiert (Zeile 12). Dieses Vorgehen ist trivial, da die Menge der Flaws immer die Kardinalität 1 besitzt 21

28 3. Datenstruktur der Visualisierung und der Klasse F AbstrakterTask angehört. Dies resultiert aus der Vorgabe, dass sich in der Fringe nur künstliche, partielle Pläne befinden in denen exakt ein abstrakter Task enthalten ist. In Zeile 13 werden daraufhin alle möglichen Modifikationen des Flaws berechnet; diese Modifikationen gehören alle der Klasse M ExpandiereTask an und es handelt sich daher um Dekompositionsmethoden. Für jede dieser Dekompositionsmethoden m wird nun der resultierende Nachfolgerplan PS,,VC,CL generiert, indem m auf den partiellen Plan P angewandt wird. Die Methoden flawdetection (Zeile 11), flawsel (Zeile 12), genmods (Zeile 13) sowie applymod (Zeile 14) wurden dabei unverändert aus dem original Planungsalgorithmus übernommen. Im nächsten Schritt wird der passende Methoden-Knoten n m erstellt, zu der Menge der Methoden- Knoten hinzugefügt sowie in den Task Decomposition Tree eingefügt. In Zeile 18 wird die Menge der künstlichen, partiellen Pläne P art aus den Planschritten PS des Nachfolgeplans erstellt. Daraufhin werden die korrespondierenden Task-Knoten kreiert und zu der Menge N T hinzugefügt, sowie mit dem Methoden-Knoten n m verbunden. Danach wird die Menge P art in die Fringe eingefügt. Schlussendlich wird der Task t als schon expandiert markiert und die Hauptschleife beginnt wieder von vorne. Dies wird solange wiederholt bis die Fringe leer ist und somit alle abstrakten Tasks dekomponiert wurden. 22

29 3.3. Erstellung des Task Decomposition Trees Algorithm 2: Algorithmus um den Task Decomposition Tree zu erstellen input : Hybrides Planungsproblem π = D,P init = PS init, init,vc init,cl init output: T DT = N M,N T,E 1 root = ε, /0,P init 2 N M {root} 3 N T {t l : t PS init } 4 E {(root,n t ) n t N T } 5 Fringe { {ps}, /0, /0, /0 ps = l : t PS init and t T abstrakt } 6 expandedtasks /0 7 while Fringe /0 do 8 P = {ps = l : t}, /0, /0, /0 plansel(fringe) 9 Fringe Fringe \ {P} 10 if t expandedtasks then continue 11 Flaws flawdetection(p) 12 f flawsel(flaws) 13 forall the m genmods(p, f ) do 14 PS,,VC,CL applymod(p,m) 15 n m = m 16 N M N M {n m } 17 E E {(t,n m )} 18 P art { {ps }, /0, /0, /0 ps = l : t PS and t T abstrakt } 19 t n = {t art {ps art = l art : t art }, /0, /0, /0 P art } 20 N T N T t n 21 E E {(m n,t i ) t i t n } 22 Fringe Fringe P art 23 end 24 expandedtasks expandedtasks {t} 25 end 26 return N M,N T,E 23

30

31 4. Visualisierung Nachdem im vorherigen Kapitel das Grundgerüst für die Visualisierung gelegt wurde, soll in diesem Kapitel die grafische Umsetzung im Vordergrund stehen. Dazu werden zuerst vier verschiedene Layouts erarbeitet sowie deren Tauglichkeit mit ihren jeweiligen Vor- und Nachteilen diskutiert. Danach sollen unterschiedliche Grafikframeworks mit ihren jeweiligen Vor- und Nachteilen vorgestellt werden, wobei am Ende eines dieser Grafikframeworks für die spätere Implementierung ausgewählt werden wird. Am Ende des Kapitels wird die konkrete Umsetzung der Visualisierung mit Hilfe des gewählten Frameworks vorgestellt sowie das erarbeitete Werkzeug präsentiert Allgemeine Begriffserklärung Da für einige Objekte die Repräsentation unabhängig von dem gewählten Layout ist, sollen in diesem Abschnitt diese allgemein geltenden Darstellungen vorgestellt werden. Für die Darstellung von Tasks innerhalb der Grafiken gelten folgende Konventionen: Handelt es sich um einen abstrakten Task, so wird dieser mit einem Rechteck mit abgerundeten Ecken sowie der Hintergrundfarbe blau dargestellt. In der gleichen Darstellungsform werden abstrakte Tasks, die schon einmal verfeinert wurden, dargestellt, jedoch mit dem Unterschied, dass diese die Hintergrundfarbe türkis besitzen. Primitive Tasks hingegen werden durch rechtwinklige Rechtecke mit der Hintergrundfarbe violett symbolisiert. Wird die Planstruktur eines partiellen Plans angezeigt, so handelt es sich hierbei um die Darstellung von Ordnungsbeziehungen, kausalen Links sowie der Variablenbelegung des partiellen Plans (siehe Abbildung 4.1). Zur Kennzeichnung des partiellen Plans werden alle Tasks, die diesem partiellen Plan angehören, durch ein abgerundetes Rechteck mit dickerer Linienstärke umrahmt. Die vorhandenen Ordnungsbeziehungen werden mittels Bogen dargestellt, ausgehend von dem Task welcher vor dem Task ausgeführt werden muss, in welchem der Bogen endet. Kausale Links werden mit gestrichelten Pfeilen dargestellt. Für die Definitionen von Tasks, Planstruktur, kausalen Links, Ordnungsbeziehungen sowie (partiellen) Plänen soll auf das Kapitel 2 verwiesen werden. 25

32 4. Visualisierung Abbildung 4.1.: Repräsentation von Planstruktur eines partiellen Plans 4.2. Vorstellung der Layouts Im Folgenden sollen nun vier verschiedene Layouts präsentiert werden, die jeweils unterschiedliche Blickwinkel auf die darunterliegende Datenstruktur ermöglichen. Es wird für jedes Layout dessen Vor- und Nachteile erörtert werden sowie dessen Einschränkungen erklärt werden. Bevor die verschiedenen Layouts näher vorgestellt werden, soll die nachstehende Tabelle 4.1 einen Überblick über die mögliche Darstellung von Planstruktur sowie von Methoden-Knoten abhängig von einer gewählten Grundstruktur geben. Das Symbol trägt die Bedeutung, dass die Option wahlweise an- oder ausgeschaltet werden kann; das Zeichen symbolisiert, dass die jeweilige Option in dieser Struktur nicht benutzt werden kann. Das Symbol sagt aus, dass die jeweilige Grundstruktur nur mit der aktivierten Option verwendet werden kann. Beispielsweise ist es in einem Graph nicht möglich, diesen ohne der Darstellung von Methoden-Knoten zu verwenden. Diese Einschränkungen ergeben sich aus der Tatsache, dass die Verwendung von gewissen Option innerhalb einer Grundstruktur zu visuell nicht ansprechenden Darstellungen führen kann. Bei der Vorstellung der verschiedenen Layouts wird darauf näher eingegangen. Grundstruktur Planstruktur Methoden-Knoten Liste Baum Graph Tabelle 4.1.: Mögliche Optionen der jeweiligen Grundstruktur 26

33 4.2. Vorstellung der Layouts Listendarstellung Bei diesem Layout handelt es sich um eine Adaption der Darstellung welche in der Publikation von Biundo et al. [1, Seite 224] verwendet wurde. Abbildung 4.2 zeigt ein Beispiel dieses Layouts. Lässt sich ein abstrakter Task dekomponieren, so werden die Tasks, die diesen abstrakten Abbildung 4.2.: Darstellung einer Domäne mit der Listendarstellung Task ersetzen eine Spalte weiter rechts platziert. Jeder Task wird somit in einer gewissen Spalte (Position in x-richtung) sowie einer gewissen Zeile (Position in y-richtung) positioniert. Dabei ist jeweils der erste Task der Dekomposition mit dem zu ersetzenden abstrakten Task verbunden. Die Linien sind rechtwinklig zueinander angeordnet, was dieses Layout ähnlich einer Ordnerstruktur erscheinen lässt. Damit lassen sich auch die Vorteile dieses Layouts bezeichnen: Es ist übersichtlich und es lässt sich auf einen Blick feststellen, welcher Task durch welche Tasks ersetzt wird. Somit eignet es sich gut, um einen ersten groben Überblick auf die repräsentierte Domäne zu erlangen. Für tiefere Einblicke muss aber auf andere Layouts zurückgegriffen werden, die es einem ermöglichen Planstruktur darzustellen. Dies ist bei diesem Layout nicht möglich, ohne dass die Struktur des Layouts zerstört wird, was zu einer Unübersichtlichkeit führt, die das Layout nicht mehr benutzbar macht. Methoden-Knoten werden nicht zusätzlich dargestellt, da dies die Übersichtlichkeit des Layouts beeinträchtigen würde sowie in der Originalvorlage nicht vorhanden war. Somit lässt sich zwar erkennen welcher abstrakte Task in welche Tasks dekomponiert wird, eine explizite Nennung der Methode, die dies ermöglicht, findet jedoch nicht statt. 27

34 4. Visualisierung Baum mit Methoden-Knoten Der Task Decomposition Tree wird mit Hilfe dieses Layouts in einer Baumstruktur aufbereitet, wobei Methoden-Knoten explizit dargestellt werden. Die Methoden-Knoten werden mit dem jeweiligen Namen der repräsentierten Dekompositionsmethode beschriftet und mit denjenigen Task-Knoten verbunden, welche den abstrakten Task-Knoten ersetzen. Ein Beispiel dieses Layouts wird in Abbildung 4.3 präsentiert. Mit Hilfe dieses Layouts ist es möglich, eine sehr saubere und übersichtliche Darstellung der Dekompositionshierarchie zu erreichen. Dieses Layout beinhaltet sehr viel Information durch die expliziten Methoden-Knoten und bietet auch die Möglichkeit Planstruktur anzuzeigen (siehe Abbildung 4.4). Dadurch eignet es sich sehr gut um umfassend über eine Domäne zu informieren. Jedoch kommt diese Detailfülle auch mit einem Preis durch die Darstellung der expliziten Methoden-Knoten beansprucht dieses Layout am meisten Platz und die Informationen werden räumlich am weitesten verteilt. Abbildung 4.3.: Darstellung des Baum mit Methoden-Knoten Layouts. Eine größere Version dieser Abbildung befindet sich im Anhang (Abbildung A.1) Baum ohne Methoden-Knoten Dieses Layout ähnelt dem zuletzt vorgestellten Layout, wobei das Augenmerk hier darauf gelegt wurde, den Platzverbrauch des Layouts zu minimieren, aber trotzdem die gleiche Menge an Information zu transportieren. Dazu werden in diesem Layout die Methoden-Knoten nicht explizit dargestellt, sondern die Kanten, die von abstrakten Task-Knoten auf deren zu ersetzende Task-Knoten zeigen, mit den Namen der jeweiligen Dekompositionsmethoden annotiert. Des Weiteren werden alle Task-Knoten, die einen abstrakten Task-Knoten verfeinern, mit einem zusätzlichen Rahmen versehen, um deren Zugehörigkeit zu symbolisieren. Außerdem ist es möglich Planstruktur anzeigen zu lassen (siehe Abbildung 4.6). Die Vorteile dieses Layouts sind somit identisch zu vorigem Layout, jedoch benötigt dieses Layout weniger Platz um dieselbe Information darzustellen. Der Nachteil besteht darin, dass die Methoden-Knoten nicht explizit aufgelistet werden, wodurch der Schwerpunkt mehr auf die Dekomposition der abstrakten Task-Knoten gelegt wird. 28

35 4.2. Vorstellung der Layouts Abbildung 4.4.: Darstellung von Planstruktur im Baum mit Methoden-Knoten Layout Abbildung 4.5.: Darstellung des Baum ohne Methoden-Knoten Layouts. Eine größere Version dieser Abbildung befindet sich im Anhang (Abbildung A.2). 29

36 4. Visualisierung Abbildung 4.6.: Darstellung von Planstruktur innerhalb des Baum ohne Methoden-Knoten Layouts 30

37 4.3. Frameworks zur Visualisierung Graph mit Methoden-Knoten Dieses Layout soll einen Graphen des Domänenmodells darstellen, wobei Task-Knoten sowie auch Methoden-Knoten explizit dargestellt werden. Jeder Task-Knoten wird in diesem Layout nur einmal dargestellt, d.h. es gibt keine zwei Task-Knoten, die denselben Task repräsentieren. Diese Eigenheit dieses Layouts führt dazu, dass sich Planstruktur nicht darstellen lässt, ohne dass es zu einer großen Unübersichtlichkeit führen würde. Zur Illustration lässt sich ein Beispiel betrachten welches einen Task-Knoten recht weit links auf der Zeichenfläche platzieren würde und genau dieser Task-Knoten beträchtlich weiter rechts noch einmal referenziert würde. Die Kanten, die sich auf diesen Knoten beziehen, würden durch den gesamten Graphen gezeichnet werden, was auf der einen Seite schon vorhandene Strukturen verdecken würde, auf der anderen Seite auch für die Darstellung der Planstruktur ungünstig wäre, da stets zwischen dem Task-Knoten ganz links und den restlichen Strukturen rechts hinund hergewechselt werden müsste. Ein ähnliches Argument begründet die Tatsache wieso kein Graph ohne Methoden-Knoten existiert. Werden keine Methoden-Knoten angezeigt, so muss, beispielsweise durch einen Rahmen, gekennzeichnet werden, welche Tasks einen bestimmten abstrakten Task verfeinern. Nun kann es vorkommen, dass ein Task sich weit links auf Zeichenfläche befindet, die restlichen Tasks jedoch auf der rechten Seite; dies würde zu einem Rahmen führen, der andere Tasks verdecken würde und damit diesen Graphen nicht benutzbar macht. Aus diesen Gründen ist in diesem Layout eine Darstellung nur ohne Planstruktur und mit separaten Methoden-Knoten möglich. Die Positionierung des Graphen wird mit Hilfe des Algorithmus von Sugiyama [9] vorgenommen, der in der Literatur dafür verwendet wird Graphen gemäß ihrer hierarchischen Struktur darzustellen. Die genaue Vorgehensweise dieses Algorithmus wird in Kapitel behandelt Frameworks zur Visualisierung Um die oben vorgestellten Layouts grafisch darzustellen, muss zuerst ein geeignetes Zeichenframework ausgewählt werden. Auf den nachfolgenden Seiten sollen in Kürze die Frameworks vorgestellt werden, die für die Umsetzung in Betrachtung kamen sowie deren Eigenschaften und die jeweiligen Vor- und Nachteile diskutiert werden GraphViz GraphViz 1 ist eine Software mit deren Hilfe Graphen visualisiert werden können. Sie wurde von AT&T-Research entwickelt und wird als open source-framework bereitgestellt. Graph- Viz verwendet eine eigene Skriptsprache, mit Hilfe derer Graphen beschrieben und dargestellt

38 4. Visualisierung werden können. Das Layout des Graphen wird von GraphViz berechnet, wobei versucht wird, den Graphen möglichst kompakt aber dennoch gemäß den hinterlegten Regeln in der Skriptdatei darzustellen. Aufgrund der Tatsache, dass sich Graphen mit Hilfe dieser Skriptsprache erstellen lassen, eignet sich GraphViz gut um in kurzer Zeit ansprechende Graphen zu modellieren. Die Darstellung eines Graphen lässt sich in viele verschiedene Ausgabeformate exportieren (PDF, JPEG, PNG,... ), jedoch handelt es sich dabei stets um statische Formate, die keine Interaktionsmöglichkeit von Seiten des Nutzers vorsehen. Aufgrund dieser Einschränkung wurde GraphViz in dieser Arbeit nur für die Prototyp-Entwicklung der verschiedenen Layouts benutzt, da in der umgesetzten Visualisierung die Möglichkeit bestehen soll mit dem Graphen zu interagieren. Deshalb wurden im Folgenden noch weitere Grafikframeworks untersucht Zest Zest 2 ist ein Visualisierungsframework, welches speziell für die eclipse-plattform entwickelt wurde und verwendet daher die in eclipse bewährte JFace/SWT-Technologie. Dadurch lassen sich bestehende eclipse-anwendungen ohne größere Probleme um Visualisierungen von Graphen erweitern. Des Weiteren beinhaltet Zest verschiedene Layout-Algorithmen, wodurch eine einfache und schnelle Darstellung von Graphen gewährleistet ist. Zest war auf den ersten Blick das präferierte Framework, vor allem im Hinblick darauf, dass das Tool, in welches die Visualisierung integriert werden soll, auf eclipse basiert. Des Weiteren bietet es große Unterstützung hinsichtlich der Interaktion des Nutzers mit dem erstellten Graphen, so werden beispielsweise Möglichkeiten des Verschiebens sowie Zoomens des Graphen angeboten. Jedoch zeigten erste Tests, dass Zest ab einer Anzahl von mehr als 500 Knoten nicht mehr flüssig auf die Eingaben des Benutzers reagierte. Dadurch schied Zest aus den weiteren Überlegungen aus, da Wert auf die Skalierbarkeit der Darstellung gelegt wird JUNG JUNG 3 ist eine Grafikbibliothek, die auf Java basiert. Sie ist für die Verwendung mit großen Graphen optimiert und kann diese entsprechend schnell und effizient darstellen. Genau wie Zest bietet diese Bibliothek auch native Unterstützung für die Interaktion mit dem Graphen an. Da der Quellcode der Bibliothek frei verfügbar ist, kann der Benutzer ohne größere Probleme neue Features implementieren. Dennoch gab es Probleme mit der Umsetzung der Darstellung von Planstruktur, da dort zwei verschiedene Layouts verwendet werden müssen. Auf der einen Seite ein Layout, welches sich um die Anordnung der Grundstruktur kümmert, auf der anderen Seite das Layout welches für die Anordnung der Task-Knoten, die zu einem partiellen Plan gehören, verantwortlich ist. JUNG unterstützt nativ jedoch nicht die Verwendung von zwei

39 4.4. Implementierung in Processing unterschiedlichen Layouts innerhalb eines Graphen. Daher schied auch JUNG aus der näheren Wahl aus Processing Processing 4 ist ein Grafikframework, welches auf Java aufsetzt und die Möglichkeiten von Java zur Grafikausgabe derart abstrahiert, dass eine einfache und unkomplizierte Verwendung von Seiten des Benutzers möglich ist. Dadurch dass Processing eine reine Grafikbibliothek ist und nicht auf die Darstellung von Graphen festgelegt ist, bietet es dem Benutzer viel Freiheit in der Darstellung der Daten. Dieser vermeintliche Vorteil birgt aber auch einen großen Nachteil. So gibt es nicht wie in den anderen vorgestellten Frameworks schon vorhandene Layouts, mit dessen Hilfe die Graphen automatisch und optisch ansprechend angeordnet werden. Durch die Verwebung mit Java sind rudimentäre Möglichkeiten der Interaktion vorhanden, die jedoch noch ausgebaut werden müssen, beispielsweise um feststellen zu können, ob sich die Position der Maus aktuell über einem Objekt befindet. Aufgrund der obigen vorgestellten Gründen fiel die Wahl des Grafikframeworks auf Processing. Spezifische Arbeiten, die durch diese Wahl anfielen, werden im nächsten Kapitel vorgestellt Implementierung in Processing Da es sich bei Processing um eine reine Grafikbibliothek handelt, die es dem Nutzer zwar ermöglicht wesentlich einfacher als in reinem Java Objekte auf den Bildschirm zu zeichnen, bietet Processing jedoch keine vorgefertigten Layouts um diese Zeichenobjekte in einer bestimmten Weise anzuordnen. Daher musste für diese Arbeit auf Algorithmen aus dem Bereich der Graphendarstellung zurückgegriffen und diese selbst implementiert werden, um die oben beschriebenen Layouts Graph mit Methoden-Knoten, Baum mit Methoden-Knoten sowie Baum ohne Methoden-Knoten umsetzen zu können. Im Konkreten handelt es sich hierbei um den Algorithmus von Walker [12], der dafür benutzt wird um Bäume korrekt und visuell ansprechend umzusetzen. Um die Graphdarstellung zu ermöglichen, greifen wir auf das hierarchische Layout von Sugiyama et al. [9] zurück, was benutzt wird um Planstruktur innerhalb von partiellen Plänen darzustellen sowie das Graph mit Method-Knoten-Layout umzusetzen Walker-Layout Der von Walker vorgeschlagene Algorithmus [12] platziert die Elemente einer Baumstruktur möglichst visuell ansprechend und dabei so platzsparend wie möglich

40 4. Visualisierung Folgende, erstmals in der Publikation von Wetherell und Shannon [13] beschriebene, ästhetische Anforderungen werden an den Algorithmus gestellt, damit von einer ansprechenden Darstellung gesprochen werden kann. 1. Das Layout soll die Hierarchie des Baumes widerspiegeln, d.h. Knoten auf einer Ebene des Baumes sollten sich auf einer horizontalen Ebene befinden. 2. Der Elternknoten sollte zentriert über dessen Kinderknoten platziert werden 3. Ein Baum und dessen Spiegelbild sollten dementsprechend positioniert werden, vor allem sollen Subbäume innerhalb eines Baumes stets auf dieselbe Weise positioniert werden, unabhängig davon an welcher Stelle sie sich im Baum befinden 4. Die Kinder eines Knotens sollen jeweils den gleichen Abstand zueinander haben Im Folgenden soll nun der Algorithmus von Walker beschrieben werden. Grundlegend lässt sich festhalten, dass Subbäume als Einheiten betrachtet werden, d.h. sobald ein Knoten um einen gewissen Betrag verschoben wird, so werden auch all dessen Kinder um den gleichen Betrag verschoben. Außerdem wird der Baum von unten beginnend bei seinen Kindern nach oben zur Wurzel hin aufgebaut. Des Weiteren wird jeder Knoten des Baumes um zwei Felder (prelim(x) und mod(x)) erweitert, wobei in prelim(x) die vorläufige Position des Knotens hinterlegt und in mod(x) die Modifikationssumme des Knotens gespeichert wird. Der Algorithmus besteht aus zwei verschiedenen Läufen, welche den Baum positionieren. Bei dem ersten Lauf handelt es sich um einen bottom-up postorder-lauf, welcher zuerst die Blätter des Baumes positioniert, d.h. die passenden Werte von prelim(x) sowie mod(x) werden dort gesetzt, und rekursiv von links nach rechts vorgeht. Dabei werden für einen gegebenen Knoten dessen Subbäume von links nach rechts angeordnet, wobei zwei Subbäume jeweils so weit voneinander getrennt werden, dass ihre Konturen sich nicht mehr berühren, d.h. jeder äußere Knoten auf der rechten Seite des vorigen Subbaumes hält einen gegebenen Mindestabstand zu dem äußeren Knoten auf der linken Seite des nachfolgenden Subbaumes ein. Bei dieser Anordnung der Subbäume kann es zu einem unerwünschten Effekt, dem sogenannten links/rechts-kleben kommen, was die Tatsache beschreibt, dass durch das Verschieben eines größeren Subbaumes nach rechts, die anderen Subbäume sich zu weit links befinden. Dadurch wird das Ästhetikkriterium 4 verletzt. Walker löst dieses Problem durch Anwendung folgender Vorgehensweise: falls ein Subbaum so weit nach rechts verschoben wird, dass sich eine Lücke öffnet, so werden die anderen Subbäume proportional zu der Größe der Lücke verschoben, so dass am Ende des Vorgangs alle Subbäume den gleichen Abstand voneinander haben. Die Anwendung dieses Vorschlages auf den Baum, welcher in Abbildung 4.7(a) dargestellt wird, resultiert in Abbildung 4.7(b), welcher nun frei vom Effekt des links/rechts-klebens ist. Der zweite Lauf ist, nachdem im ersten Lauf die vorläufigen Positionen der Knoten gesetzt wurden, für die finale Positionierung der Knoten verantwortlich. Dazu wird, ausgehend von dem Wurzelknoten des Baumes, in einer postorder-traversierung die tatsächliche Position des 34

41 4.4. Implementierung in Processing (a) Baum, welcher den Klebeeffekt demonstriert (b) Korrekt gelayouteter Baum Abbildung 4.7.: Demonstration des Klebeeffekts sowie des bereinigten Baumes Knotens x berechnet, welche sich aus dessen vorläufiger Position prelim(x) sowie der Modifikationssumme mod(x) zusammensetzt. Aus Platzgründen wird der Pseudocode dieses Algorithmus hier nicht abgedruckt, interessierte Leser sollen hierzu auf den Originalartikel von Walker [12] verwiesen werden Sugiyama-Layout Bei dem erstmals von Sugiyama et al. [9] vorgestellten Algorithmus handelt es sich um eine Vorgehensweise mit dessen Hilfe sich Digraphen in passende horizontale Schichten einteilen und dadurch hierarchisch darstellen lassen. Die hier beschriebene Methode lehnt sich an der von Battista et. al [10] beschriebenen Vorgehensweise an. Der komplette Algorithmus lässt sich in drei Phasen aufgliedern: 1. Zuweisung der Schichten 2. Minimierung der Kreuzungen 3. Bestimmen der horizontalen Koordinate Als Ausgangsbasis für den Algorithmus wird von einem azyklischen Digraphen G = (V, E) ausgegangen, wobei V die Menge der Knoten bezeichnet und E die Menge der Kanten. Sollte es sich bei G um einen Graph handeln, der nicht azyklisch ist, müssen zuvor in einem Vorverarbeitungsschritt alle Zyklen aus dem Graphen entfernt werden, bevor der Algorithmus angewandt werden kann. Im Folgenden sollen nun die oben vorgestellten drei Phasen näher beschrieben werden. 35

42 4. Visualisierung Zuweisung der Schichten In diesem Schritt wird der azyklische Digraph G in einen hierarchischen Digraphen überführt, wobei alle Knoten v V jeweils in eine Schicht L 1,L 2,...L h eingeteilt werden, so dass gilt wenn (u,v) E und u L i sowie v L j, dann muss auch gelten i < j. Wenn man von der Höhe eines hierarchischen Digraphen spricht, so ist hiermit die Anzahl h der Schichten gemeint. Die Breite bezeichnet die maximale Anzahl an Knoten in einer Schicht, d.h. max 1 i h L i. Die Länge einer Kante e = (u,v), wobei gilt u L i und v L j berechnet sich aus der Differenz ihrer Schichten, i j. Der hierarchische Digraph wird als korrekt bezeichnet, sofern für jede Kante gilt, dass ihre Länge nicht größer als eins ist. Um eine korrekte Schichtung zu erreichen, wird für jede Kante e = (u,v) die eine Länge von 1 überschreitet, sogenannte Dummy-Knoten in jeder Schicht, die die Kanten durchquert, eingefügt. Dieses Vorgehen ist wichtig, da für die spätere Phase der Kreuzungsreduktion ein korrekter Digraph vorliegen muss. Abbildung 4.8.: Korrekte Schichtung eines Digraphen, wobei die kleineren Kreise die eingefügten Dummy-Knoten darstellen Minimierung der Kreuzungen Nachdem alle Knoten einer Schicht zugewiesen wurde, besteht die nächste Aufgabe darin, die Kreuzungen der Kanten zu minimieren, da dies zu einer angestrebten ästhetischen und übersichtlichen Darstellung führt. Dabei spielt die exakte Position der Knoten keine Rolle, sondern die Reihenfolge der Knoten ist von Bedeutung, d.h. man hat ein kombinatorisches Problem zu lösen. Es gibt nun mehrere Heuristiken, dieses Problem zu lösen. Die meisten dieser Heuristiken verwenden dabei den sogenannten layer-by-layer sweep, bei dem die Anordnung der Knoten Schicht für Schicht vorgenommen wird. Man bestimmt dazu zuerst eine fixe Permutation der Knoten in der ersten Schicht L 1 des Graphen. Danach wird für die restlichen i = 2,3,...,h Schichten jeweils die Permutation der darüberliegenden Schicht L i 1 als fest angesehen, wohingegen die Knoten in der Schicht L i so angeordnet werden sollen, dass die Kreuzungsanzahl 36

43 4.5. Präsentation des entwickelten Werkzeuges minimal wird. Durch diese Vorgehensweise wird das Problem der Kreuzungsminimierung auf jeweils zwei Schichten beschränkt, wobei eine Schicht fixiert ist. Bestimmung der horizontalen Koordinaten Nachdem der grobe Aufbau des Graphen in den vorigen zwei Phasen festgelegt wurde, besteht der Zweck dieser Phase darin, die x-koordinaten der Knoten so festzulegen, dass die Anzahl der Knicke der Kanten minimal sowie der Digraph nicht zu breit wird. Wie auch in den anderen zwei Phasen gibt es mehrere Vorgehensweisen um dies zu erreichen, im Folgenden soll die Positionierung mittels Prioritätswerten erläutert werden. Die Vorgehensweise ist ähnlich zu Phase 2, d.h. man verwendet auch hier den layer-by-layer sweep. Eine Position in Schicht L i 1 wird dabei fixiert, worauf die Anordnung der Knoten in Schicht L i optimiert wird. Man wählt nun jeden Knoten einzeln aus und berechnet dessen Prioritätswert. Dieser Prioritätswert setzt sich aus der Anzahl seiner Nachbarn zusammen sowie der Tatsache, ob es sich um einen Dummy-Knoten handelt oder nicht. Handelt es sich bei v V um einen Dummy-Knoten und er besitzt nur einen Nachbar in L i 1, bei dem es sich auch um einen Dummy-Knoten handelt, so möchte man hier eine möglichst gerade Kante haben, d.h. diese beiden Knoten möglichst untereinander platzieren. Daher muss der Knoten v in diesem Fall einen sehr hohen Prioritätswert erhalten. Die Vorgehensweise besteht nun darin, beginnend mit den Knoten mit dem höchsten Prioritätswert, die Knoten so nah wie möglich an ihrer Wunschposition zu platzieren. Dabei ist zu beachten, dass eine Position nur einmal besetzt werden kann, es kann also keine zwei Knoten geben die sich an selber Stelle befinden. Des Weiteren muss die Sortierung erhalten bleiben, d.h. schon gesetzte Knoten mit höherer Priorität bleiben an ihrer Wunschposition, wohingegen Knoten mit niederer Priorität verschoben werden dürfen. Für eine detaillierte Erklärung der verschiedenen Heuristiken sowie deren algorithmische Umsetzung soll auf die Publikation von Battista et al. verwiesen werden [10] Präsentation des entwickelten Werkzeuges Nachdem in den vorigen Abschnitten die verschiedenen Layouts sowie verwendete Algorithmen zur Implementierung erörtert wurden, soll im Folgenden das daraus entstandene Werkzeug vorgestellt werden. Abbildung 4.9 zeigt die Hauptansicht des Werkzeuges, wobei einzelne Abschnitte der Toolbar farbig hervorgehoben und mit Nummern versehen sind. Um eine Domäne visualisieren zu können, muss zunächst ein Domänenmodell sowie eine dazu passende Probleminstanz ausgewählt werden. Dies geschieht über den Reiter File in der Menüleiste. Dort lässt sich nun mittels des Eintrags Load Domain And Problem die gewünschten Dateien auf der Festplatte auswählen. Nachdem dies geschehen ist, kann der Nutzer festlegen, ob er die komplette Domäne oder nur die Probleminstanz visualisieren lassen 37

44 4. Visualisierung Abbildung 4.9.: Hauptansicht des Werkzeuges 38

45 4.5. Präsentation des entwickelten Werkzeuges will. Dazu wählt er jeweils den Reiter Domain oder Problem unterhalb der Menüleiste aus. Sobald diese geschehen ist, muss er im unteren Teil des Programms den Task Decomposition Tree -Reiter auswählen um zur Visualisierung zu gelangen. Sobald dies erfolgte, bietet sich dem Nutzer das in Abbildung 4.9 abgebildete Bild. Im oberen Bereich befindet sich die Toolbar, im unteren Bereich die Zeichenfläche, innerhalb derer die Visualisierung dargestellt wird. Die Toolbar bietet dem Nutzer die Möglichkeit verschiedene Präferenzen für die zu generierende Visualisierung festzulegen. Alle Optionen, die das Layout der Visualisierung betreffen befinden sich in der Grafik innerhalb des roten Rechtecks mit der Nummer 1. Dort wird die Grundstruktur der Visualisierung (Baum, Graph oder Liste) festgelegt, ausgewählt ob Methoden- Knoten angezeigt werden sollen sowie die Darstellung von Planstruktur aktiviert. Falls eine Option in einer gewählten Grundstruktur nicht verfügbar ist, wird diese Option dem Nutzer gegenüber deaktiviert und ausgegraut dargestellt. Dies entspricht Tabelle 4.1, welche zum Beispiel die Darstellung von Planstruktur innerhalb der Listendarstellung nicht zulässt. Das grüne Rechteck mit der Nummer 2 beinhaltet alle Optionen, mit deren Hilfe sich das Aussehen der Task-Knoten steuern lässt. Ist keine dieser Optionen ausgewählt, so wird bei der Darstellung eines Task-Knotens nur dessen Name angezeigt (siehe Abbildung 4.10(a)). Wird die Option Show Arguments aktiviert, so werden die Task-Parameter τ eines jeden Tasks, wie in Abbildung 4.10(b) zu sehen ist, dargestellt. Zusätzlich lassen sich durch Auswahl von Show Sorts die Sorten der jeweiligen Parameter einblenden (siehe Abbildung 4.10(c)). (a) Keine Argumente (b) Anzeige von Argumenten (c) Anzeige von Argumenten und Sorten Abbildung 4.10.: Steuerung des Aussehens der Task-Knoten Wurde die Darstellung von Task-Parametern aktiviert, wird es dem Nutzer ermöglicht, die Darstellung von Variablen an seine Wünsche anzupassen. Dazu gibt es die Möglichkeit nur den Namen (Option Name ), nur den Wertebereich (Option Domain ) oder beide Möglichkeiten zusammen anzuzeigen (Option Name & Domain ). Wird die Option Name ausgewählt, so wird der Variablennamen mit einem vorangestellten Fragezeichen dargestellt (Abbildung 4.11(a)); wird der Wertebereich der Variablen ausgewählt so wird dieser mit umschließenden geschweiften Klammern angezeigt (Abbildung 4.11(b)). Abbildung 4.11(c) zeigt die Kombination dieser beiden Optionen bei der Name der Variablen durch einen Doppelpunkt von dessen Wertebereich getrennt wird. Zusätzlich lässt sich für Variablen auch noch festlegen in welcher Art und Weise deren Namen dargestellt werden sollen. Dazu gibt es innerhalb des Menüs Variable Names die zwei 39

46 4. Visualisierung (a) Anzeige des Namens (b) Anzeige des Wertebereichs (c) Anzeige von Name und Wertebereich Abbildung 4.11.: Unterschiedliche Darstellungsarten einer Variablen Optionen Original sowie Shortened. Die Option Original greift dazu auf die Namen der Variablen zurück, so wie sie in der Definition der Domäne vom Modellierer festgelegt wurden (siehe Abbildung 4.12(a)). Der Name einer jeden Variablen innerhalb eines Task-Knotens (a) Ursprünglicher Variablenname (b) Gekürzter Variablenname Abbildung 4.12.: Darstellung der zwei Optionen bezüglich des Variablennamens besteht bei Auswahl von Shortened aus der Konkatenation des Wortes var sowie einer fortlaufenden Nummer beginnend bei 1. Die erste Variable eines Task-Knotens bekommt somit den Namen var1, die dritte Variable den Namen var3. Für gewöhnlich ist es sinnvoll die Variablen gekürzt darzustellen, da die Variablennamen innerhalb einer Domäne meist länger sind und damit die Länge der Task-Knoten sowie der gesamten Darstellung in die Breite ziehen. Jedoch kann die Darstellung Original beispielsweise bei der Analyse eines Fehlers dazu verwendet werden, die Variable in der Domäne wiederzufinden, damit das Problem behoben werden kann. Des Weiteren ist es möglich zusätzliche Informationen über jeden Task-Knoten einzublenden. Verharrt der Nutzer einen kurzen Augenblick mit der Maus über einem Task-Knoten (Mouse- Over), so werden die Vor- und Nachbedingungen des ausgewählten Tasks dargestellt; das Minus-Symbol steht dabei für ein Negationszeichen (siehe Abbildung 4.13). Diese Darstellung ist dabei abhängig von den zu diesem Zeitpunkt ausgewählten Optionen bezüglich der Darstellung der Task-Knoten sowie der Variablendarstellung. In Abbildung 4.13 ist zum Beispiel die Anzeige der Argumente sowie deren Sorte aktiviert. Wurde vom Benutzer die Option Planstruktur aktiviert, so können innerhalb eines partiellen 40

47 4.5. Präsentation des entwickelten Werkzeuges Abbildung 4.13.: Einblenden der Vor- und Nachbedingungen eines Task-Knotens Plans auch weitere Informationen mittels eines Mouse-Overs eingeblendet werden. Wird dabei über einem kausalen Link l i,φ,l j verharrt, so wird dessen geschützte Bedingung φ angezeigt (siehe Abbildung 4.14(a)). Befindet sich der Mauszeiger innerhalb eines partiellen Plans so werden die dort vorliegenden Variablenbedingungen angezeigt (siehe Abbildung 4.14(b)). Auch bei diesen beiden Features hängt die Darstellung von den gewählten Optionen bezüglich den gewählten Eigenschaften zur Anzeige der Task-Knoten ab. Befindet sich die Maus innerhalb der Zeichenfläche, so hat der Nutzer die Möglichkeit durch das Gedrückthalten der rechten Maustaste den dargestellten Ausschnitt zu verschieben. Außerdem kann er unter Zuhilfenahme des Mausrades die Zoomstufe der Darstellung verändern. Mit diesen Mitteln kann die Darstellung der Domäne komfortabel erforscht werden. Dennoch kann es in manchen Fällen erforderlich sein die Visualisierung gezielt nach dem Vorkommen bestimmter Tasks, Methoden, Variablen oder Konstanten zu durchsuchen. Mit Hilfe der Suchmaske, welche sich innerhalb des orangen Rechtecks mit der Nummer 3 in Abbildung 4.9 befindet, lässt sich unter Verwendung von regulären Ausdrücken nach Objekten, die auf der Zeichenfläche dargestellt werden, suchen. Wird ein passendes Objekt gefunden, so wird dieses dementsprechend gekennzeichnet und in der Mitte der Zeichenfläche zentriert. In Abbildung 4.15 wird diese Funktionalität demonstriert. Zur weiteren Erleichterung der Navigation innerhalb der Visualisierung besteht für den Nutzer die Möglichkeit durch das Klicken auf Kanten zu dessen jeweiligen Start- oder Endpunkten zu gelangen. Ist eine Kante selektiert und wird die linke Maustaste doppelt betätigt, so gelangt der Nutzer zu dem Endknoten dieser Kanten; wird mit der rechten Maustaste doppelt geklickt wird der Nutzer zum Startknoten befördert. Eine ähnliche Interaktionsmöglichkeit besteht auch innerhalb partiellen Plänen: Mit einem rechten Doppelklick gelangt der Nutzer zu demjenigen Task welcher durch diesen partiellen Plan verfeinert wird. Eine weitere Möglichkeit des Werkzeuges besteht darin einen ausgewählten Task-Knoten beim Wechsel von Layouts sowie den oben erwähnten Anzeigeoptionen stets in der Mitte zu zentrieren. Dies ist nützlich wenn nur ein bestimmter Ausschnitt aus der Visualisierung betrachtet werden soll. Der Nutzer kann durch einen Klick mit der linken Maustaste auf einen Task- Knoten diesen als neues Zentrum der Visualisierung auswählen. Soll die Zentrierung aufgehoben werden, so klickt der Nutzer mit der linken Maustaste auf eine leere Stelle in der Zeichenfläche. 41

48 4. Visualisierung (a) Darstellung eines kausalen Links (b) Anzeige von Variablenbedingungen Abbildung 4.14.: Anzeige von zusätzlicher Information innerhalb eines partiellen Plans 42

49 4.5. Präsentation des entwickelten Werkzeuges Abbildung 4.15.: Suche eines Tasks mit Hilfe eines regulären Ausdrucks 43