Agent Building Shell / COOL

Die Agent Building Shell⁸ ist eine Expertensystem-Schale für Agentensysteme. Sie enthält eine Reihe von Sprachen und Funktionalitäten sowie eine toolbasierte Ent-wicklungs- und Laufzeitumgebung. Die Sicht auf die Agentenprogrammierung ist stark kommunikationszentriert: Agenten erarbeiten Lösungen, indem sie Koopera-tionsprotokolle, die hier Konversationen genannt werden, abarbeiten.

Konversationen werden als endliche Automaten mit einem ausgezeichnetem An-fangs und einer Menge von Endzuständen modelliert. Zustandswechsel finden durch Nachrichtenaustausch in Form von Sprechakten statt. Abbildung 4-5 zeigt ein Verhandlungsprotokoll aus Sicht des initiierenden Agenten. Vom Anfangszustand 1 geht der Agent durch Versenden eines Vorschlags (als propose/ noptiert) in Zustand 2 über. Dort wechselt er, je nachdem wie die Antwort ausfällt, entweder nach 3, 4 oder 5. Derartige Konversationsgraphen werden mit Hilfe der Koordina-tionssprache COOL⁹ beschrieben.

8. [Barbuceanu, Fox 1996].

9. COOrdination Language [Barbuceanu, Fox 1995].

Abbildung 4-5: COOL-Konversation als endlicher Automat¹⁰

• Konversationsregeln spezifizieren das Verhalten eines Agenten innerhalb eines Kooperationsprotokolls. Für jeden Zustandsübergang im Konversationsgraphen muß eine Regel existieren, die das Verhalten des Agenten beschreibt. Die Vor-bedingung einer Konversationsregel besteht aus dem Zustandsnamen und einem erwarteten Sprechakt. Im Aktionsteil der Regel ist neben der Handlungsanwei-sung eine Spezifikation der zu sendenden Nachricht und den Nachfolgezustand enthalten. Um auch Konversationen mit mehreren Agenten zu ermöglichen exi-stieren Konstrukte, um den Empfang mehrerer Nachrichten zu testen.

(def-conversation-rule r1 :current-state 2 :received (proposed

:sender ?initiator

:content (produce ?what ?amount ?time)) :such-that (can-do ?what ?amount ?time) :next-state 3

:transmit (accept

:content (produce ?what ?amount ?time)))

• Fehlerbehandlungsregeln feuern, wenn eine empfangene Nachicht nicht behan-delt werden kann. Eine solche Situation kann durch Kommunikationsfehler, Verzögerungen oder fehlerhaft (bzw. unvollständig) implementierte Protokolle

10. Das Senden einer Nachricht wird durch einen nachgestellten, der Empfang durch einen vorangestellten Schrägstrich gekennzeichnet

propose/

counter/

r e j e c t /

accept/accept / f a i l / s a t i s f y

/accept

/ r e j e c t

/counter 1

2

3

5 4

6 7

Sprechakt: empfangen/senden

eintreten. Durch Fehlerbehandlung kann nun flexibel reagiert werden - vom Start einer Klärungskonversation über das Vernachlässigen des Fehlers bis hin zur Fehlermeldung auf dem Terminal des Benutzers.

• Konversationsklassen spezifizieren die Zustände, Konversations- und Fehlerbe-handlungsregeln, Kooperationspartner, Variablen und Kontrollmechanismen von Konversationen. Das Klassenkonzept erlaubt es, daß ein Agent mehrere Protokolle desselben Typs gleichzeitig fahren kann.

(def-conversation-class Cnv-1 :initiator ?initiator :respondent ?respondent :variables (?v1 ?v2) :initial-state s0

:final-states (s5 s7 s6)

:conversation-rules ((s0 r1 r2), ...) :error-rules (e1, ...)

:error-rule-applier ERA-1)

Ein Kooperationsprotokoll wird durch Instanzbildung einer Konversationsklasse gestartet. Dabei wird eine Konversationsumgebung generiert, die den Zustand der Protokolldurchführung verwaltet. Außerdem bietet sie einen Speicher für globale Variablen, mit dem beispielsweise Zwischenergebnisse persistent über mehrere Zu-stände hinweg verwaltet werden können.

4.3.1 Methodik

Agentenprogrammierung in COOL ist gleichbedeutend mit der Konstruktion von Konversationen. Hierfür existiert eine komfortable Entwicklungsumgebung, die Rapid Prototyping unterstützt. Konversationsklassen und -regeln können Schritt für Schritt definiert und getestet werden. Trifft der Agenteninterpreter auf eine nicht vorhandene Konversationsregel, wird der Benutzer aufgefordert, entsprechende Maßnahmen zu ergreifen. So können Protokolle inkrementell kreiert und verbessert werden. Eingebettet in die Entwicklungsumgebung sind Debuggingwerkzeuge, mit denen zur Lauf- bzw. Testzeit aktiv in das Systemgeschehen eingegriffen werden kann.

Zu dem interaktionszentrierten Modellierungsansatz stellt JAFMAS¹¹ eine Ent-wicklungsmethodik bereit. Danach besteht der Prozeß der Agentenprogrammierung aus 5 Schritten:

11. Java-based Agent Framework for Multi-Agent Systems [Chauhan 1997]. JAFMAS stellt im wesentli-chen eine Re-Implementierung von COOL in Java dar.

1 Identifikation der Agenten: Eine vorgegebene Aufgabenstellung wird anhand von globalen Zielen in Agenten zerlegt. Dabei werden agentenlokale Ziele und Dienste identifiziert. Es folgt eine Einordnung ähnlicher Agenten zu Agenten-kategorien. So gelangt man zu Agentenklassen.

2 Definition der Konversationen: Für jeden Agenten werden die notwendigen Konversationen mittels endlicher Automaten beschrieben.

3 Bestimmung der Konversationsregeln: Hierbei werden die Konversationen

„mit Leben gefüllt“, indem die Zustandsübergänge der Automatenmodelle durch Regeln beschrieben werden.

4 Analyse der Konversationen: Die Vollständigkeit und logische Konsistenz aller Konversationen ist zu untersuchen. Es wird vorgeschlagen, sich hierbei auto-matischer Unterstützung z.B. in Form von Petrinetzwerkzeugen zu bedienen.

Im Erfolgsfall ist die Systemkohärenz sichergestellt, ansonsten muß zum letz-ten Schritt zurückgekehrt werden.

5 Implementierung des Agentensystems: Mit Hilfe eines passenden Werkzeugs (JAFMAS-Klassenbibliotheken) werden die Konversationsregeln, Sprechakte und Agenten implementiert.

4.3.2 Bewertung

Agenten bestehen aus einer Menge von Konversationen. Eine Architektur, die Wis-sen speichert, verarbeitet oder räsonniert ist nicht vorhanden. Weil sich alles Han-deln in den Konversationen abspielt, können Agenten als strikt reaktiv bezeichnet werden. Die Modellierung und Programmierung mit COOL/JAFMAS entspricht ei-ner problemzentrierten Top-Down-Vorgehensweise. Letztendlich handelt es sich um eine Erweiterung bekannter objektorientierter Ansätze. Agenten sind verteilte Objekte, die anstelle von Methodenaufrufen zu komplexen Interaktionen in der La-ge sind.

Die Kommunikation orientiert sich an KQML. Dabei wurde die Nachrichtensyn-tax um einen :conversation-Eintrag erweitert, der den Bezug eines Sprechaktes zur dazugehörigen Konversationsinstanz herstellt. Erst dadurch ist es möglich, auf die Historie einer Kooperation Bezug zu nehmen. Die Semantik von Sprechakten wird vollständig in den Konversationsregeln festgelegt und ist alleine vom Zustand der Konversation und dem Nachrichteninhalt abhängig. Eine linguistische Schicht ist nicht vorhanden, Sprechakte werden per pattern matching erkannt. Die Performati-ve ist somit „syntaktischer Zucker“ ohne eigentliche Bedeutung. Da die Wahl einer Konversationsregel durch einen allgemeinen Unifikationsschritt entschieden wird, ist es beispielsweise möglich, sämtliche Kommunikation über einen einheitlichen tell-Sprechakt abzuhandeln.