ASDL:Designentscheidungen und Architektur

From Wiki

Contents 1 Designentscheidungen 1.1 Zielspezifikation 1.2 Umsetzung der Suchunterstützung 1.3 Umsetzung des Werkzeuges 1.4 Umsetzung der Adaptivität 2 ASDL-Aufbau & Ablauf 3 Daffodil-Architektur 3.1 Aufbau 3.2 Backend 3.2.1 Services und Request 3.3 Frontend

Designentscheidungen

Zielspezifikation

Das Ziel dieses Projekts ist es, ein adaptives Tool zur Suchunterstützung modellieren. Hierbei soll es sich um ein agentenbasiertes Tool handeln, welches dem User bei unzureichenden Suchergebnissen einen oder mehrere Vorschläge unterbreitet.

Diese Vorschläge basieren auf Marcia Bates' Suchtaktiken, die im Laufe der Seminarphase besprochen wurden. Um die Vorschläge passend zur jeweiligen Suchsituation im System zu gewichten und abzulegen, kommt ein CBR-System (Case-Based-Reasoning) zum Einsatz, welches auf einer MySQL-Datenbank aufsetzt. Dabei sollen Suchsituation als Problemfälle (Case) und Suchvorschläge als Lösungen (Suggestion) angesehen werden. Ausgehend von einer anfangs kleinen Fallbasis (siehe Datenbank-Skripte) sollen mit Hilfe des fallbasierten Schließens geeignete Lösungen für neue Fälle gelernt werden. CBR erscheint am sinnvollsten, da so das System durch das Hinzufügen von Fällen in die Fallbasis (durch positives Feedback des Nutzers) hinzulernen kann. Der im Kapitel Inferenzmethoden beschriebene CBR-Zyklus findet sich im ASDL-Tool wieder. Ähnliche Cases werden berechnet (Retrieve), von den Vorschlägen werden einer oder mehrere vom User ausgewählt (Reuse & Revise) und dann in der Datenbank abgespeichert (Retain). Ein regelbasiertes System würde brauchbare Regeln benötigen, um gute Ergebnisse zu liefern. Diese scheinen aber - auch wegen der recht knappen Entwicklungszeit - schwerer umsetzbar als ein CBR-System, da eine längere Evaluierung noch wichtiger wäre. Auch das Umsetzten der Lernfähigkeit des Systems wäre unnötig weitaus schwieriger gewesen.

Aufgrund des Seminabeitrags über Agentensysteme entschieden wir einen Afferenz-Agenten (Observer-Agent), einen Inferenz-Agenten (Reasoning-Agent) und einen Efferenz-Agenten (Output-Agent) zu entwickeln. Im Laufe des Projekts haben wir uns entschieden, den Output-Agenten zwar zu programmieren, diesen aber nur die Nachrichten zwischen Reasoning-Agent und Tool weiterleiten zu lassen. Die Funktionalität des dritten Agenten wurde auf das Tool und den Reasoning-Agenten verteilt:

• Observer-Agent: "Beobachten" der Suchanfrage und des Suchergebnisses -> Kontextdaten
• Reasoning-Agent: Berechnung der Vorschläge aus den Kontextdaten.
• Output-Agent: Zum Weiterleiten von Nachrichten vom ASDL-Tool und Reasoning-Agenten, evtl. für zukünftige Erweiterungen weitere Berechnung mit Hilfe der Vorschläge.

Die Hauptnachricht, die zwischen den Agenten verschickt wird und die Grundlage für das Case-Based-Reasoning ist, ist die Kontextdaten-Nachricht. Diese Nachricht besteht im einzelnen aus den folgenden Elementen:

• #Hits
• #Operatoren
• Anfrageterme
  • Autor
  • Ttitel
  • Freitext
  • Jahr
• Antwortzeit
• Liste der DLs
• Extrahierte Terme
  • Schlagwörter
  • Autoren
  • Konferenzen
  • Journale

Die zugehörige DTD zu dieser XML-Nachricht ist im letzten Kapitel (Anhang) dieses Berichts zu finden.

Der Nutzer soll selbst entscheiden können ob er die vom System gemachten Vorschläge, welche in einen seperaten Fenster auf Anfrage angezeigt werden, annimmt. Dem Nutzer soll es ermöglicht werden Vorschläge automatisch auszuführen und Feedback über die Nützlichkeit der Vorschläge zu geben.

Umsetzung der Suchunterstützung

• Die Vorschläge sollen auf Taktiken und Stratagemen von Marcia Bates und auf anderen Quellen basieren, z.B. wird auch der Einsatz eines weiteren Daffodil-Tools vorgeschlagen.
• Es soll keine Vorschläge zur Bedienung von Daffodil geben.

Umsetzung des Werkzeuges

• Im Back-End: durch drei Agenten: Observer-Agent, Reasoning-Agent, Output-Agent (vgl. ASDL-Aufbau)
• Im Front-End: durch ein Präsentationstool, welches auf Nutzeraufforderung Vorschläge in einer geordneten nach berechneter Ähnlichkeit sortierten Liste darstellt, erklärt und auf Verlangen des Nutzers ausführt und die Möglichkeit bietet, Vorschläge als hilfreich zu bewerten.

Umsetzung der Adaptivität

• Die Wahl der Vorschläge geschieht mittels CBR-Methoden anhand der Nutzersituation. Die Auswahl und Reihenfolge der Vorschläge wird anhand des Benutzerfeedbacks angepasst. Durch längere Nutzung des ASDL-Tools ist zu erwarten, dass die Qualität der Vorschläge steigt.
• Die ausführbaren Vorschläge werden - falls möglich bzw. sinnvoll - an die gegebene Situation angepasst (z.B. an die konkreten Terme der Suche).
• Nutzerspezifische Adaption durch User Modelling wird zunächst nicht berücksichtigt.

ASDL-Aufbau & Ablauf

Bei der Architektur mussten wir festlegen, wie die einzelnen Agenten und das Tool miteinander in Bezug stehen und in welcher Weise sie miteinander kommunizieren. Dazu haben wir erstmal festgelegt, welche Agenten und Klassen wichtig für die Kommunikation sind. Diese bestehen, wie im Ablaufdiagramm zu erkennen, aus folgenden Komponenten:

• User-Agent
• Oberserver-Agent
• Reasoner-Agent
• Output-Agent
• Datenbank
• Daffodil-Backend

Wenn ein User eine Suchanfrage in Daffodil eingibt, werden dem Observer-Agenten die Suchanfrage und das Suchergebnis mittles einer XML-Nachricht geschickt, sobald beide eingetroffen sind. Daraus berechnet er die Kontextdaten (siehe oben). Diese werden dann im nächsten Schritt an den Reaoning-Agenten verschickt. Aus diesen Kontextdaten wird ein Case(=Fall) konstruiert. Es werden dann die vorhanden Fälle aus der Datenbank eingelesen und mit Hilfe eines Ähnlichkeitsmaßes (Klasse StandardSimilarityMeasure) mit dem aktuellen Fall verglichen und so die ähnlichsten berechnet. Dem Search-Tool wird über den Output-Agenten eine Nachricht geschickt, in der die Anzahl der vorhandenen Vorschläge enthalten ist. Das Search-Tool zeigt daraufhin den Butten zur Anforderung der Vorschläge an. Der Reasoning-Agent speichert die berechneten Fälle temporär ab (natürlich nicht in der Datenbank!).

Wenn der Benutzer auf diesen Button klickt, wird eine Nachricht vom Search-Tool zur Anforderung der Vorschläge über den Output-Agenten an den Reasoning-Agenten weitergeleitet. Die Vorschläge - also die Suggestions, die bei den ähnlichsten Fällen in der DB gespeichert waren - werden dann über den Output-Agenten an das ASDL-Tool geschickt. Die Kontextdaten werden grundsätzlich immer mitgeschickt.

Das ADSL-Tool öffnet danach ein Fenster im Userinterface, in dem dem User die besten Vorschläge zur Suchverbesserung dargestellt werden. Falls der User einen Fall als hilfreich bewertet, wird dieser über den Output-Agenten an den Reasoning-Agenten geschickt. Der Reasoning-Agent speichert dann diesen mit den aktuellen Kontextdaten, die mitgeschickt wurden, und der ID der Suggestion als neuen Fall in die Datenbank ab, so dass sich die Datenbasis mit der Zeit immer weiter verbessert und somit hilfreichere Vorschläge generieren kann.

Daffodil-Architektur

Aufbau

Backend

Das Daffodil-Backend basiert auf der CORBA-Agentenarchitektur. CORBA ist eine objektorientierte Middleware, die plattformübergreifende Protokolle und Dienste definiert und von der Object Management Group (OMG) entwickelt wird. CORBA vereinfacht das Erstellen verteilter Anwendungen in heterogenen Umgebungen. Alle Services sind als Agenten implementiert, sowohl die internen als auch die externen Agenten. Die internen Agenten kommunizieren mittels XML-Nachrichten. Die externen Agenten nutzten das HTTP-Protokoll und verbinden sich über den Message-Transfer-Agent mit dem Backend.

Services und Request

Alle Dienste erweiten die Agent- oder ExternalAgent-Klassen. Ein Agent implementiert die Kommunikation. Er wartet auf neue Nachrichten und kann Nachrichten verschicken. Zu jedem Agenten existiert ein Request, welcher als Thread läuft. Dieser enthält die Programmlogik des Agenten. Dabei startet jede Nachricht mit neuer Request-ID einen neuen Request.

Das ASDL-Projekt verwendete folgende Daffodil-Klassen für die Umsetzung der drei Agenten:

• de.unido.daffodil.core.AgentSen: Um die sensorischen Funktionen Daffodils nutzen zu können, müssen solche Agenten von dieser Klasse erben (wie der Observer-Agent)
• de.unido.daffodil.core.RequestSen: Der Request für einen sensorischen Agenten

• de.unido.daffodil.core.Agent: "Herkömmliche" Agenten (wie der Reasoning-Agent) erben von dieser Klasse
• de.unido.daffodil.core.Request: Der Request für einen Agenten ohne senorische Funktionalitäten

• de.unido.daffodil.core.RunnableAgent: Um die Erzeugung von Requests zu vereinfachen, gibt es die Möglichkeit, von dieser Klasse zu erben (wie der Output-Agent)
• de.unido.daffodil.core.RunnableRequest: Der dazugehörige Request

Frontend

Der Desktop basiert auf dem WOB-Modell. Das WOB-Modell dient der Gestaltung weborientierter, grafischer Benutzungsoberflächen für Informationssysteme. Es handelt sich um softwareergonomische Vorschläge, die eine Werkzeugmetapher basierende, objektorientierte Benutzungsoberfläche ermöglichen sollen. Es ist auch grafisch direktmanipulativ. Hierdurch soll die Gestaltung grafischer Benutzungsoberflächen effizienter ablaufen. Dabei sind Werkzeugmetapher und objektbasiertes Nutzerinterface die zentralen Konzepte. Die Datenobjekte können durch direkte Manipulation benutzt werden, was vielen Usern als Drag und Drop bekannt ist.

• de.izsoz.fiola.wob.desktop.InternalTool: Die Tools in Daffodil erben von dieser Klasse
• de.izsoz.fiola.wob.desktop.InternalView: Jedes Tool hat ein oder mehrere Views (Model-View-Controller), diese erben von der Klasse InternalView