Visualisierungsunterstützung für kooperative Aktivitäten im Internet

Transkript

1 Visualisierungsunterstützung für kooperative Aktivitäten im Internet Diplomarbeit eingereicht beim Fachbereich Informatik der Universität Hamburg Heiko Zade betreut von Prof. Dr. Joachim W. Schmidt Prof. Dr. Klaus Brunnstein 29. März 1998

2

3 Zusammenfassung Das Ziel dieser Arbeit ist es, Vorarbeiten für eine Visualisierungskomponente des auf dem Modell der Business Conversations aufbauenden Agentensystems zu leisten und einen Prototyp zu entwickeln. Die Visualisierung von Daten und möglichen Aktionen erfolgt dabei im Internet. Dazu werden das Agentensystem analysiert, Voraussetzungen benannt, mögliche Visualisierungsansätze dargestellt und Lösungswege aufgezeigt. Außerdem werden die für eine dynamische Visualisierung notwendigen Voraussetzungen festgestellt und das Tycoon Agentensystem getestet.

4

5 I Inhaltsverzeichnis 1. Einführung und Motivation Das Tycoon Business Conversations - Projekt Das Agentensystem Ein Anwendungsbeispiel Zielsetzung dieser Arbeit Aufbau der Arbeit Das Modell der Business Conversations Das Kooperationsleitbild Grundlagen Konzepte Das Verarbeitungmodell von Konversationen Sekundäre Konversationen Finale Dialoge Konversationsspezifikationen Konversationsinstanzen Invarianten des Modells Das Agentensystem Der Aufbau des Tycoon-Agentensystems Das Nachrichtensubsystem Migration von Agenten Starten von Konversationen Regeldefinition und -auslösung Zusammenfassung... 28

6 II Inhaltsverzeichnis 4. Grundlagen und Anforderungen der Visualisierung Grundlagen der Visualisierung Visualisierung im Internet Datentypen der Business Conversations Allgemeine Anforderungen Synchrone und asynchrone Verbindungen Funktionalität des Agentensystems Dynamische Visualisierung Dialogobjekte Anfragen Inhaltsobjekte Visualisierungsvorlagen Dienstleisterseite Kundenseite Erstellung der Vorlagen Abspeicherung der Vorlagen Aufruf der Vorlagen Zusammenfassung Analyse der Tycoon Business Objects Verbindungsablauf Daten- und Aktionsobjekte Seitenobjekte Zusammenfassung Design der Visualisierungskomponente Atomare Datentypen Komplexe Datentypen Auswahltypen Dialoge Sequence Rcd und Variant Anfragen Einordnung des Visualisierungsdienstes... 64

7 Inhaltsverzeichnis III Zentraler Visualisierungsdienst Integrierter Visualisierungsdienst Nebenläufigkeit und Migration Zusammenfassung Realisierung der Visualisierungskomponente Starten des Visualisierungsservers Verwaltung der Konversationen Verbindungsablauf Starten von Konversationen Migration Übertragung der Daten Synchrone und asynchrone Kommunikation Erweiterungen der Tycoon Business Objects Vorarbeiten für die dynamische Visualisierung Zusammenfassung und Ausblick Zusammenfassung Ausblick A. Glossar A.1 Glossar der Agententerminologie A.2 Glossar der Business Conversations B. Abkürzungen C. Ausgewählte Programmbeispiele zur Visualisierung C.1 Konversationsspezifikation Kreditvergabe C.2 Konversationsspezifikation Portnummer holen C.3 Regeldefinition C.4 Typdefinition von agent.conversation C.5 Datentypdefinition in TBCContent.ti C.6 Typdefinition von tbconv.dialog C.7 Kreditdaten Dialog Spezifikation C.8 Inhaltsobjekt eines Dialoges C.9 Generische Typermittlung

8 IV Inhaltsverzeichnis C.10 Tycoon Business Objects Seitenobjekt C.11 Tycoon Business Objects Datenobjekte C.12 Tycoon Business Conversations Aktionsobjekt Literaturverzeichnis

9 V Abbildungsverzeichnis 2.1: Phaseneinteilung einer Kommunikation : Modellbildung für Informationssysteme : Verfeinerung mittels sekundären Konversationen : Spezifikation von Konversationen, Dialogen und Inhalten : Instanzen von Konversationen, Dialogen und Inhalten : Aufbau des Tycoon Agentensystems : Die Threads und Nachrichten eines Agenten : Zuordnung der Agenten zu Orten und Domänen : Logische Struktur der Agentenwelt : Zustandsdiagramm einer Konversation : Objektstrukturmodell von Agent und Rolle : Ansätze zur Datenvisualisierung : Objektstrukturmodell zum Zugriff auf Dialogobjekte : Struktur der Visualisierungsvorlagen : Informationsfluß zur Visualisierung : Verbindungsablauf der Visualisierung : Aufbau eines Seitenobjektes : Visualisierung atomarer Daten : Kennwortfeld : Textbereich : Visualisierung der SingleChoice als Kombinationsfeld : Visualisierung der SingleChoice mit atomaren Daten : Komplexe Optionsgruppe : Visualisierung der MultipleChoice : Visualisierung von Dialogen mit Frames : Zweidimensionale Tabelle : Mehrdimensionale Tabelle... 62

10 VI Abbildungsverzeichnis 6.11: Visualisierung einer Anfrage durch eine Schaltfläche : Externer Visualisierungsdienst : Zentraler Visualisierungsagent : Integrierte Visualisierung : Threads der integrierten Visualisierung : Hauptmenü des Agenten : Konversationsliste : Verbindungsablauf zur Visualisierung : Zustandsdiagramm der Visualisierung beim Kunden : Konversationsübersicht C.1: Konversationsspezifikation Kreditvergabe... 98

11 1 1. Kapitel Einführung und Motivation Wir leben in einer Zeit, in der immer leistungsfähigere Informationssysteme Unternehmen und Privatpersonen kostengünstig zur Verfügung stehen und in der gleichzeitig die Entwicklung der Nachrichtensysteme von geschlossenen, firmenbezogenen und zentralistisch aufgebauten Strukturen hin zu vernetzten [Ober91a], offenen, kommunikativen und dezentralen Systemen tendiert. Parallel dazu wandeln sich die betrieblichen Unternehmensprozesse durch fortschreitende Automatisierung und andere Entwicklungen wie Unternehmensfusionen und das Eingehen weltweiter wirtschaftlicher Verflechtungen, um dem sich verschärfenden nationalen und internationalen Wettbewerb gewachsen zu sein. Dieses wird durch die Entwicklung von Workflows [Jabl94] und Workflowmanagementsystemen [Jabl95] noch unterstützt. Diese Umstände machen es für die Unternehmen unabdingbar, den Betriebsablauf so effizient wie möglich mit Hilfe computergestützter Vorgangsbearbeitung zu gestalten. Das Erfordernis und der Wunsch vieler Anwender, anwendungsfreundliche Benutzerschnittstellen für die Kommunikation mit diesen Systemen zu schaffen, bleibt auch deshalb für die Informatik eine der großen Herausforderungen [Schm83, Hübn90]. Einen maßgeblichen Anteil an dieser rasanten Entwicklung trägt das globale Netzwerk Internet, durch das die Zugriffsmöglichkeiten auf Informationen grundlegend verändert wurden [WBW96]. Insbesondere die graphischen Benutzeroberflächen, die auch ungeübten Anwendern den Zugang zu Informationen ermöglichen, die anwenderorientierten Dienste wie elektronische Post und multimedialer Hypertext verursachen eine ständig zunehmende Informationsnutzung. Gleichzeitig ist die abrufbare Menge an Informationen um ein vielfaches größer als jemals zuvor [DDJ+97]. Der Informationsbedarf in den Unternehmen hat auch dazu geführt, daß über 50% der Benutzer das Internet für geschäftliche Belange nutzen [PK97].

12 2 1. Einführung und Motivation 1.1 Das Tycoon Business Conversations - Projekt Durch technologische und marktwirtschaftliche Entwicklungen haben sich die Informationsstrukturen hin zu grundlegend veränderten, interaktiven, vernetzten, verteilten und teilautonomen Informationssystemen entwickelt [Blas90, Catt91]. Um die Anforderungen dieser Informationsstrukturen und -systeme zu unterstützen, sind neue Methoden und Werkzeuge erforderlich. Basierend auf dem Business Conversation-Modell (siehe Abschnitt 2) wurde ein Agentensystem realisiert [Joha97], das eine Lösung für die Anforderungen der neuen Informationsstrukturen darstellt. Der interaktive Bereich dieses Systems ist durch Konzepte und Methoden der Visualisierung zu lösen. Dieses ist der Hauptbestandteil dieser Arbeit. Das Ziel des Projektes "Tycoon Business Conversations" ist die Entwicklung kooperativer, mobiler, reaktiver und teilautonomer Agenten, die als Stellvertreter des Menschen im Netz wirken. Sie stellen auf diese Art eine personalisierte Verbindung der realen zur modellierten Welt dar. Der Stellvertreter repräsentiert den Benutzer und seine Autorität gegenüber anderen Agenten der modellierten Welt, indem er für ihn Entscheidungen trifft und Arbeiten ausführt. Beale und Wood [BW94] definieren Agenten folgendermaßen: Ein Agent kann als eine relativ einfache, heterogene, autonome und kommunizierende Software-Komponente definiert werden; viele dieser Agenten existieren gleichzeitig und arbeiten zusammen, um eine Aufgabe für einen Benutzer zu erfüllen.. Wenn Agenten aufgrund eigener Entscheidung in einem Netzwerk von einem Computer zu einem anderen migrieren können und in der Lage sind, sich dort mit ihrem Namen anzumelden, zählen sie zur Klasse der mobilen Agenten [Wagn97]. Bei der Betrachtung der Business Conversations (BC) sind zwei verschiedene Realisierungen zu unterscheiden. Die erste Realisierung eines Agentensystems, das auf den BCs basiert, erfolgte von Johannisson [Joha97] mittels der Programmiersprache Tycoon und ist benannt als Tycoon Business Conversations (TBC). Die zweite Realisierung wird derzeit durch Wegner [Wegn98] und Ripp [Ripp98] vorgenommen. Sie benutzen dafür die objektorientierte Sprache Tycoon-2 [Wahl98, Weik98], die gegenüber Tycoon eine erheblich bessere Unterstützung des Internets bietet. Die vorliegende Arbeit beschränkt sich auf die erste Realisierung der TBCs in Tycoon, weil deren Implementation in Tycoon-2 erst kurz vor dem Abschluß der vorliegenden Arbeit erfolgte. Zu diesem Thema wurden im letzten Jahr mehrere Diplomarbeiten geschrieben. Richtsmeier [Rich97] hat einen Web Site Profiler entwickelt und Kruse [Krus97] eine Möglichkeit, die Kommunikation zwischen den Agenten zu protokollieren. Fecht [Fech97] beschäftigte sich in seiner Studienarbeit mit der Sicherheit im Internet unter Berücksichtigung des TBC-Modells. 1.2 Das Agentensystem Durch die Implementierung eines verteilten, persistenten und kooperierenden Agentensystems durch Johannisson [Joha97], steht der Prototyp eines Systems zur Verfügung, das auf die neuen

13 1.3. Ein Anwendungsbeispiel 3 Kommunikationsstrukturen zugeschnitten ist. Das schnellste und intelligenteste System aber nutzt nicht viel, wenn seine Ergebnisse nicht leicht verständlich sind, weil keine benutzerfreundliche Kommunikation stattfinden kann [Schm83]. Deshalb ist es angezeigt, eine Benutzerschnittstelle für das o.g. Agentensystem zu entwickeln, die es ermöglicht, die Daten in angemessener Form zu präsentieren. Die durch das Agentensystem realisierten Agenten sind als Stellvertreter des menschlichen Benutzers in der Lage, einfache Aufgaben, die dieser Benutzer an sie delegiert, zu erledigen. So können sie z.b. Treffen mit anderen Agenten vereinbaren und sie verwirklichen. Ebenso ist eine Kooperation mehrerer Agenten, also die Zusammenarbeit mehrerer Systeme, die gemeinsame Ziele verfolgen und in ihrer Arbeit aufeinander angewiesen sind [Maaß91], denkbar. Dabei repräsentieren die Agenten die Autorität ihrer Benutzer durch die von ihnen durchgeführten Aktionen und die getroffenen Entscheidungen. Die Agenten sind die aktiven Komponenten des Systems. Sie erfüllen ihre Aufgaben, indem sie Konversationen miteinander führen. 1.3 Ein Anwendungsbeispiel Folgendes Anwendungsbeispiel wird in der Arbeit verwendet: Ein Kunde möchte bei einer Bank einen Kredit aufnehmen. Hierzu versorgt er einen seiner Stellvertreter-Agenten, mit den nötigen Informationen. Dieses sind u.a. die Kredithöhe, die Laufzeit und die monatliche Tilgung. Danach schickt er den Agenten zum Kreditinstitut. Dort nimmt der Agent in einer Konversation Kontakt mit dem Stellvertreter-Agenten des Sachbearbeiters auf. Dieser Agent prüft zuerst, ob sein Sachbearbeiter überhaupt zuständig ist. Ist der Sachbearbeiter nicht berechtigt, diesen Antrag zu bearbeiten, unter Umständen ist das Kreditvolumen zu hoch, so wird der Antrag gleich weiter an den Vorgesetzten geschickt, ohne dem Sachbearbeiter zur Kenntnis zu gelangen. Ist der Sachbearbeiter ermächtigt, den Kreditantrag zu bearbeiten, erscheint der Antrag in seiner Liste der auszuführenden Arbeiten. Er bearbeitet den Antrag, gewährt den Kredit, setzt einen Kreditzins fest und sendet ein Angebot ab. Falls er den Kredit verwehrt, übermittelt er eine Absage. Sein Stellvertreter protokolliert den Vorgang und sendet die Entscheidung des Sachbearbeiters an den Stellvertreter des Antragstellers. Der Stellvertreter des Antragstellers kann nun sofort zu seinem Auftraggeber zurückkehren oder, je nach den erhaltenen Befehlen, andere Banken aufsuchen, um vergleichende Angebote einzuholen. Sobald er wieder bei seinem Besitzer ist, trägt er sich in die Übersicht der auszuführenden Arbeiten ein. Der Antragsteller öffnet bei Gelegenheit diese Liste, arbeitet sie ab und nimmt so Kenntnis von den getroffenen Entscheidungen. Hat der Kunde einen ausreichenden Kredit, so ist es ihm im Rahmen seines Limits möglich, in Warenhäusern einzukaufen und dort entweder mit einer Kreditkarte zu bezahlen oder über seine Kundennummer dem Unternehmen die Abbuchung des Kaufbetrags zu ermöglichen.

14 4 1. Einführung und Motivation 1.4 Zielsetzung dieser Arbeit Die bisher existierende Realisierung des Modells der Business Conversations läßt Benutzereingaben nur im Tycoon Top Level zu. Diese Realisierung ist wegen der Eingabe von Befehlen in Kommandozeilen weder benutzerfreundlich noch intuitiv. Deshalb soll das von Johannisson [Joha97] entwickelte Agentensystem um eine Visualisierungskomponente erweitert werden, damit eine benutzerfreundliche Ein- und Ausgabe von Daten erreicht wird. Weiterhin ist es Ziel der Arbeit, eine an das vorhandene Modell der Business Conversations gebundene Benutzerschnittstelle zu schaffen, die das benutzerfreundliche Darstellen, Erfassen und Ändern der Daten von Geschäftsprozessen zuläßt. Außerdem sollen mit dieser Benutzerschnittstelle zum Agentensystem die Aktionen (requests) des Systems ausgelöst werden können. Da es durch das Internet Unternehmen und privaten Nutzern möglich geworden ist, Daten aus Arbeitsabläufen mit diesem Medium weltweit darzustellen, wird die Visualisierungskomponente die Möglichkeit bieten, Daten in HTTP-Clients anzuzeigen. Die Arbeit wird Voraussetzungen für die Visualisierung benennen, mögliche Ansätze diskutieren und mit einem Prototyp die Durchführbarkeit der statischen Visualisierung von Tycoon Business Conversations aufzeigen. Die Arbeit soll überdies als Test der Tycoon Business Conversations (TBC) dienen und Erkenntnisse darüber vermitteln, welche Komponenten für eine Visualisierung der TBCs erforderlich sind. Weiterhin liefert sie Aufschlüsse darüber, welche Komponenten in das Basissystem integriert und welche Voraussetzungen erfüllt werden müssen, damit die dynamische Darstellung der TBCs ermöglicht werden kann. Aus diesen Gründen wird, um eine große Bandbreite an Anwendungen abdecken zu können, ein möglichst allgemeines Modell gestaltet und ein System von Visualisierungsvorlagen analysiert, das eine effektive dynamische Darstellung der TBCs ermöglicht. Die Sicherheitsaspekte, die bei der Verwendung der TBCs im Internet zu beachten sind, bilden den Inhalt der Arbeit von Fecht [Fech97]. Sicherheit in Bezug auf Tycoon wurde bereits in [Kass95, Will96] behandelt. Die Autorisierungs- und Authentifizierungsaspekte, die bei einem komplexen System zu beachten sind, werden in den Arbeiten [LAMP81, Oppl92] dargelegt. 1.5 Aufbau der Arbeit Das Kapitel 2 "Das Modell der Business Conversations" beschreibt den Language/Action- Ansatz, der dem Modell zugrundeliegt, und die verschiedenen Komponenten, die notwendig sind, um ihn in ein Computermodell umsetzen zu können. Aufbauend auf dem Modell wird in Kapitel 3 "Das Agentensystem" die Umsetzung des Modells mit Hilfe der Programmiersprache Tycoon thematisiert. Dabei werden diejenigen Komponenten der Realisierung, die für die Visualisierung benötigt werden, eingehend betrachtet. Im Kapitel 4 "Grundlagen und Anforderungen der Visualisierung" sind notwendige Merkmale und einschränkende Bedingungen für eine Datenvisualisierung beschrieben. Dazu gehören u.a. die durch das Hypertext Transfer Protocol gesetzten Rahmenbedingungen. Das Kapitel 5 "Analyse der

15 1.5. Aufbau der Arbeit 5 Tycoon Business Objects" untersucht, ob bzw. in welcher Weise das System der Tycoon Business Objects für die Visualisierung benutzt werden kann. Aufbauend auf den Anforderungen an die Datenvisualisierung und der Analyse der Tycoon Business Objects wird in Kapitel 6 das Design der Visualisierungskomponente erläutert. Hierbei werden Verfahren und Schnittstellen der Visualisierung benannt. Danach folgt in Kapitel 7 "Realisierung der Visualisierungskomponente" die Beschreibung der prototypischen Realisierung. Die Zusammenfassung in Kapitel 8 zieht eine Bilanz der geleisteten Arbeit. Der Ausblick weist auf die Entwicklungsmöglichkeiten des Systems hin.

16

17 7 2. Kapitel Das Modell der Business Conversations In diesem Kapitel wird das Modell der Business Conversations vorgestellt. Das Modell wurde 1996 in Zusammenarbeit von Matthes [Matt97a, Matt97b, DDJ+97], Johannisson [Joha97], Richtsmeier [Rich97], Kruse [Krus97] und dem Verfasser entwickelt. Die Ausführungen entsprechen im wesentlichen denen von Johannisson. Zunächst wird in diesem Kapitel der Language/Action-Ansatz [Wino87, FGHW88] vorgestellt, der die Basis für das Kooperationsmodell darstellt, anschließend werden die Konzepte erläutert, die hinter diesem Modell stehen. Eine ausführliche Beschreibung der Realisierung dieses Ansatzes folgt in Kapitel Das Kooperationsleitbild Das Modell der Business Conversations wurde aufbauend auf dem Language/Action-Ansatz [Wino87, FGHW88] entwickelt. Der Language/Action-Ansatz basiert auf der Sprechakttheorie, die im Rahmen der sprachanalytischen Philosophie entwickelt, von Austin [Aust62] eingeführt und von Searle [Sear69] ergänzt wurde. Die Sprechakttheorie betrachtet die Sprache als die wichtigste Größe für kooperative Zusammenarbeit zwischen Menschen. Die Spechakttheorie besagt, daß sich sprachliche Aussagen, die Sprechakte, hinsichtlich ihrer Verwendung in fünf disjunkte Typklassen einteilen lassen: assertive Äußerungen (Feststellungen) direktive Äußerungen (Aufforderungen) kommissive Äußerungen (Versprechen) expressive Äußerungen (Ausdruck von Meinungen) deklarative Äußerungen (Erklärungen) Nach Searle ist eine Aussage dabei unmittelbar an ihre Bedeutung gekoppelt. Sprechakte werden daher als Mitteilungen von legalen Zustandsänderungen ihres Sprechers innerhalb einer Konversation betrachtet.

18 8 2. Das Modell der Business Conversations Arbeiten aus dem Bereich der computerunterstützten Gruppenarbeit von Fernando Flores und Terry Winograd [Wino87, FGHW88] identifizieren die zwei wesentlichen Arten von Sprechakten, die in der Domäne von Geschäftsprozessen eine Rolle spielen: Das sind zum einen die Conversations for Possibilities (CfP) und zum anderen die Conversations for Action (CfA). Eine CfA ist eine Folge von Aufforderungen und Versprechen, die direkt auf eine gemeinsame Aktivität der Gesprächspartner ausgerichtet ist. Dabei ist innerhalb einer CfA die Reihenfolge der einzelnen Sprechakte, d.h. die erlaubten Gesprächstransitionen, unter den Gesprächspartnern festgelegt. Werden in einer Konversation keine Verpflichtungen eingegangen, sondern wird die "Funktion eines Managers'' wahrgenommen, sprechen Winograd und Flores vom Typ einer CfP. In diesem Fall werden in einer Konversation nur Feststellungen, Meinungen oder Erklärungen ausgetauscht. Bei keinem Partner wird durch einen Sprechakt eine Aktion impliziert. Eine CfA oder CfP strukturiert und koordiniert einzelne Sprechakte. Durch diese Sprechakte bilden die beteiligten Kommunikationspartner eine gemeinsame Historie, vor deren Hintergrund neue Sprechakte erzeugt und interpretiert werden. Bei einer CfA, deren Konzept dem Kooperationsmodell der Business Conversations zugrunde liegt, vereinbaren die Partner wechselseitig zukünftige Aktionen, die direkt an die geäußerten Sprechakte der jeweiligen Partner gekoppelt sind. 2.2 Grundlagen Das Modell der Business Conversations bildet einen Rahmen für die anwendungsnahe Modellierung von Informationssystemen auf der Grundlage von Sprechakten. Es definiert eine Terminologie und eine Semantik, mit der Informationssysteme aus der Sicht von Sprechakten modelliert und spezifiziert werden können. Dabei orientiert es sich begrifflich an der Domäne der Geschäftsprozesse und erfaßt neben den statischen Aspekten eines Dienstes gleichermaßen die dynamische Interaktion von Kunde und Dienstleister über die Zeit. Basis des Modells ist die Annahme, daß die Kommunikationsmuster der Sprechakte universell sind, das bedeutet, sie sind von der Art der Akteure (Software, Menschen) und von den verwendeten Kommunikationsmedien und -protokollen unabhängig. Sowohl die Interaktion zwischen menschlichen Akteuren als auch die zwischen Menschen und maschinellen Akteuren oder gar die zwischen zwei maschinellen Akteuren ist innerhalb des Modells transparent, wird also gleich behandelt. Das Modell der Business Conversations beschreibt die zielgerichtete Kommunikation zwischen zwei Akteuren, die in den Rollen Kunde und Dienstleister handeln. Die Festlegung, welche Rolle von welchem Akteur eingenommen wird, kann, je nach der persönlichen Blickrichtung, unterschiedlich ausfallen. Ein Beispiel hierfür ist die Beziehung zwischen Diplomand und Betreuer. Aus der einen Sichtweise heraus ist der Diplomand Kunde des Betreuers und erhält als Dienstleistung die Betreuung der Arbeit. Aus der anderen Sichtweise ist es das vorrangige Ziel der Diplomarbeit, eine Arbeit zu erbringen, die im universitären Bereich weiterverwendet werden kann. Dabei ist die Universität der Kunde des Diplomanden, dessen Dienstleistung es ist, eine entsprechende Arbeit zu erstellen.

19 2.2. Grundlagen 9 Die Business Conversations basieren auf der Theorie der Conversations for Action (CfA), die besagt, daß eine Kommunikation mit dem Ziel einer Aktion zwischen einem Kunden und einem Dienstleister in einen Zyklus mit vier Phasen unterteilt werden kann. Annahme Anfragephase Übereinkunftsphase Kunde Dienstleister Rückmeldephase Leistungsphase Erfüllung Abbildung 2.1: Phaseneinteilung einer Kommunikation Die Beziehung zwischen einem Kunden und einem Dienstleister folgt immer dem skizzierten Ablauf: Als erstes wird der Kunde in der Anfragephase beim Dienstleister unverbindlich nach einer Dienstleistung anfragen. Am Ende dieses Schrittes steht dann, in der zweiten Phase, der Übereinkunftsphase, die Verhandlung mit dem Dienstleister, einen gewählten Dienst tatsächlich verbindlich zu erbringen. Das Erbringen der vereinbarten Leistung geschieht in der Leistungsphase, an deren Ende aus der Sicht des Dienstleisters die geforderte Leistung erbracht ist. In der vierten Phase, der Rückmeldephase, wird der Kunde dem Dienstleister mitteilen, ob die erbrachte Leistung seinen Anforderungen entspricht. Nur wenn auch die letzte Phase erfolgreich abgeschlossen ist, wurde das gemeinsame Ziel von Kunde und Dienstleister, und damit das Ziel ihrer Kommunikation, erreicht. Der Austausch von Sprechakten innerhalb dieser vier Phasen wird unter dem Begriff der Konversation zusammengefaßt, welcher sich mithin immer auf einen konkreten Gegenstand, die Dienstleistung oder Aktion, bezieht. Der Zyklus kann durch den Verzicht auf einzelne Phasen vereinfacht werden, wenn die betrachtete Kunde-Dienstleister-Beziehung dies erlaubt. Zum Beispiel können die Phasen Anfrage und Übereinkunft zusammengefaßt werden. Dabei bleiben jedoch sowohl die Reihenfolge der Phasen als auch der Zyklus erhalten. Das Modell der Business Conversations ergänzt bereits etablierte Modelle (wie z.b. Object Modelling Technique, Entity-Relationship-Modell), welche die Modellierung von Informationssystemen nach innen gestatten (siehe Abbildung 2.2). Diese Modelle können aus der

20 10 2. Das Modell der Business Conversations Sicht einer Anwendung als systemnahe Modelle bezeichnet werden. Sie strukturieren Systemkomponenten daten- bzw. objektzentriert, d.h. auf Entitäts- oder Objektebene. Die Business Conversations stellen den kooperativen Charakter eines Informationssystems in den Vordergrund. Durch die Betrachtung der von dem System nach außen erbrachten Dienstleistungsprozesse wird eine anwendungsnahe Modellierung des Systems unterstützt. Hierdurch wird der Abstand zwischen der realen Welt und ihrer Abbildung durch Informationssysteme verkleinert. Das Modell versucht nicht, Informationssysteme auf der Ebene von Objekten oder Klassen zu beschreiben. Vererbungs-, Aggregations- oder Generalisierungsbeziehungen von Objekten innerhalb des betrachteten Informationssystems müssen durch andere, auf diesen Zweck spezialisierte Modelle beschrieben werden. Object Modelling Technique Reale Welt: - Geschäftsprozesse - Akteure - Information Computersysteme: - Prozesse - Objekte - Daten Business Conversations Entity- Relationship Diagramme Abbildung 2.2: Modellbildung für Informationssysteme

21 2.3. Konzepte Konzepte Ein integraler Bestandteil des Business Conversation-Modells ist ein vereinbartes Verarbeitungsmodell, das die Interaktion zwischen zwei Partnern definiert und ihre jeweiligen Rollen innerhalb der Interaktion, d.h. innerhalb eines Gesprächs, festlegt. Dieses Verarbeitungsmodell muß von beiden Gesprächspartnern eingehalten werden, um den korrekten Fortgang des Gesprächs zu gewährleisten. Um die Einhaltung des Modells zu gewährleisten wird jeder Konversation eine Konversationsspezifikation (siehe Abschnitt C.1) zugrundegelegt. Diese Spezifikation enthält alle möglichen Schritte jeder Phase eines Sprechaktes. Ein derartiger Schritt wird fortan als Dialog bezeichnet. Außerdem ist der Inhalt jedes Dialogs in Form von Variablenvereinbarungen definiert. Die Zustandsübergänge zwischen den Dialogen sind als Anfragen (requests) in der Spezifikation enthalten. Dadurch entspricht ein Dialog einem Formular in der realen Welt. Der Inhalt des Dialoges entspricht den Formularfeldern und die Anfragen sind mit den Aktionen vergleichbar, die mit dem Formular durchgeführt werden können. Wird ein Dialog nicht zurückgesandt, so wird die Konversation, ebenso wie in der realen Welt, nicht fortgeführt Das Verarbeitungmodell von Konversationen In einer Konversation wird jede zielgerichtete Interaktion (d.h. jeder mögliche Sprechakt der Language/Action-Perspektive) mit Dialogen realisiert. Für die Dialoge zweier Instanzen wird angestrebt, ein möglichst genaues Abbild des gewohnten Arbeitskontextes zu erhalten. Dieses gilt um so mehr, je mehr Menschen an diesen Dialogen beteiligt sind. Hierzu werden die bekannten Tätigkeiten soweit wie möglich auf Mensch-Maschine- Interaktionen abgebildet und die Informationen so strukturiert, daß der jeweilige Kommunikationspartner die im Sprechakt enthaltenen Information seinem eigenen Ausführungskontext zuordnen kann. Dafür entwickelt der Benutzer ein mentales Modell von seiner Arbeitsaufgabe und deren Lösung im Dialog mit dem Rechner [Hübn90]. Der Inhalt der Dialoge ist festgelegt und durch den Verwendungszweck bedingt. In den durch die Konversation gesetzten Grenzen können sie allerdings von allen beteiligten Partnern genutzt werden, sei es durch Ausfüllen der vorgegebenen Freifelder oder durch Inspektion des vorhandenen Inhalts. Durch die Inhalte der Dialoge werden von der ausgebenden Seite mögliche Folgeaktionen impliziert, die mit dem Dialog in direktem Zusammenhang stehen. Auf diese Weise repräsentiert ein Dialog einen bestimmten Punkt in einer längeren Beziehung zwischen zwei Partnern, der Schlüsse auf gültige Fortsetzungen der Beziehung in die Zukunft ermöglicht. Es existieren keine allgemeingültigen Dialoge, die für eine Vielzahl von Konversationen vorgesehen sind und nur auf der Grundlage eines Rollenmodells, in das die an der Konversation Teilnehmenden eingeordnet sind, ausgewertet werden. Dieses ließe sich zwar mit dem Modell der Visualisierungsvorlagen (siehe Abschnitt 4.8) über Rollenprofile realisieren, spricht aber gegen die Auffassung einer zielgerichteten Kommunikation und damit gegen das Modell der Business Conversations.

22 12 2. Das Modell der Business Conversations Jeder Dialog beschreibt indirekt einen Zustand in einer Konversation zwischen einem Kunden und einem Dienstleister. Im Gegensatz zur zeitlich ausgedehnten Konversation besitzt ein Dialog keine nach außen sichtbaren Zwischenzustände. Die Zustandsübergänge, d.h. der Beginn eines neuen Dialogs innerhalb einer Konversation, werden durch Auswertung und Verarbeitung einer Anfrage des Kunden beim Dienstleister durchgeführt. Dabei ist der Kunde derjenige Akteur, der den Zeitpunkt des Zustandsüberganges bestimmt: Indem er eine Anfrage an den Dienstleister stellt, führt dieser seine mit der Anfrage assoziierte Bearbeitungsregel aus und generiert einen neuen (Antwort-)Dialog für den Kunden. Die Menge der möglichen Anfragen, die ein Kunde ausgehend von einem Zustand einer Konversation an einen Dienstleister richten kann, ist durch den Dialog bestimmt, welcher den aktuellen Zustand der Konversation repräsentiert. Dies entspricht in der Formularanalogie der Möglichkeit, in einem vorgegebenen Formular einen Kundenwunsch ankreuzen zu können. Es sind darüber hinaus genau zwei Anfragen definiert, die nicht in der Menge der Anfragen enthalten sind, die ein Dialog explizit vorgibt: Die initiale Anfrage: Ein Kunde muß eine Konversation mit einem Dienstleister beginnen können, ohne sich vorher bereits in einer Konversationsbeziehung mit ihm zu befinden. In diesem Fall kann der Kunde genau eine Anfrage an den Dienstleister stellen, nämlich die nach der Eröffnung der Konversation. Die Spezifikation dieser Anfrage ist zusammen mit dem zugeordnetem, initialen Dialog Teil des Business Conversation-Systems. Eine spezielle Anfrage nach dem Abbruch der Konversation: Diese Anfrage löst ein Kunde implizit aus, wenn er innerhalb einer vom Dienstleister vorgegebenen Zeitspanne keine Anfrage an den Dienstleister stellt. Tatsächlich ist dies keine wirklich vom Kunden stammende Anfrage, sondern wird vom System des Dienstleisters im Namen des Kunden generiert. Außerdem ist dem Kunden der explizite Abbruch der Konversation erlaubt. Die Spezifikation dieser Anfrage ist ein Teil des Business Conversation-Systems. Eine Konversation zwischen einem Kunden und einem Dienstleister wird mit diesen Mechanismen auf eine festgelegte Abfolge von Dialogen und Anfragen übertragen. Der Dienstleister gibt dabei jeweils einen Dialog vor, den der Kunde erhält und so bearbeiten kann. Der Kunde ist jedoch immer der Initiator einer Konversation und der Dienstleister der Akzeptor. Während einer Konversation sind Kunde und Dienstleister abwechselnd Sprecher und Zuhörer. Auf diese Weise werden Ketten aus Ereignissen und Aktionen [DHL90] gebildet. Die beiden Partner der Konversation definieren Bearbeitungsregeln, mit denen sie auf die Ereignisse des jeweils anderen Partners reagieren und dadurch Aktionen ausführen. Die gültigen Transitionen einer Konversation, wie sie durch die Regeln implementiert werden, sind durch eine zugehörige Spezifikation bestimmt (siehe auch Abschnitt 2.3.4). Menschliche Akteure simulieren Kundenregeln, indem sie den Inhalt der Dialoge lesen und entsprechend ihren Wünschen verändern. Maschinelle Kunden besitzen einen Programmkode für die Regeln, der die Inhalte der Dialoge entsprechend der kodierten Vorschrift interpretiert bzw. abändert. Die Regeln des Kunden enden immer mit der Übermittlung des eventuell veränderten Dialogs zusammen mit einer Anfrage.

23 2.3. Konzepte 13 Ebenso muß der Dienstleister auf die Dialoge und Anfragen des Kunden entsprechend einer Regel reagieren. Seine Aktion endet immer damit, daß er einen neuen Dialog, den er bei Bedarf vorher mit inhaltlichen Vorgaben gefüllt hat, an den Kunden übermittelt. Durch die wechselseitige Ausführung einer Kundenregel und einer Dienstleisterregel wird jede Konversation gemäß der zugrundeliegenden Spezifikation systematisch entwickelt. Innerhalb einer Konversation kann ein Dienstleister, dann jedoch in der Rolle eines Kunden, eine weitere Konversation mit einem anderen Dienstleister initiieren, sofern das zur Ausführung seiner Bearbeitungsregel notwendig ist. Dieses führt zum Konzept der sekundären Konversation Sekundäre Konversationen Mit der Technik der sekundären Konversation ist eine Mischform der Beziehung zwischen Kunde und Dienstleister möglich (siehe Abbildung 2.3). Dabei wird der Dienstleister A 2 innerhalb einer Konversation mit einem Kunden A 1 selbst zum Kunden eines weiteren Dienstleisters A 3. A primäre 1 Konversation A sekundäre A 2 Konversation 3 Abbildung 2.3: Verfeinerung mittels sekundären Konversationen Konversationen werden in synchrone und asynchrone Konversationen unterteilt. Synchrone sekundäre Konversationen unterbrechen die initiierende primäre Konversation für die Dauer ihrer Ausführung. Sie bilden damit eine eingeschobene Konversation, bei der ein impliziter Rollenwechsel des Akteurs stattfindet. Wird eine sekundäre Konversation asynchron ausgeführt, ist keine Unterbrechung der primären Konversation notwendig. Eine asynchrone sekundäre Konversation verhält sich wie eine primäre, kann jedoch die übergeordnete Konversation verzögern; die Atomarität der Bearbeitungsregel wird aufgehoben Finale Dialoge Jede Konversation besitzt eine definierte Menge von finalen Dialogen, die sie erreichen kann. Jeder Dialog ohne einen Folgedialog, d.h. ohne eine mögliche ausgehende Anfrage, ist ein finaler Dialog der Konversation. Die Konversationsbeziehung zwischen den beteiligten Partnern wird bei Erreichen eines solchen Dialogs beendet. Das Modell definiert einen Finaldialog für das erfolgreiche Ende jeder Konversation (d.h. sowohl Kunde als auch Dienstleister bestätigen das erfolgreiche Erreichen des gemeinsamen Ziels) sowie einen finalen Fehlerdialog. Dieser Fehlerdialog ist implizit von jedem Dialog einer Konversation aus erreichbar, ohne daß dies in der Spezifikation vermerkt werden muß. Dieser Dialog bietet die Möglichkeit, Ausnahmebehandlungen in den Bearbeitungsregeln für Konversationen vorzusehen. Eine solche Ausnahme kann von beiden Partnern jederzeit in einer Konversation ausgelöst werden.

24 14 2. Das Modell der Business Conversations Die entsprechende zugehörige Anfrage, durch die der Kunde den Übergang in einen Ausnahmezustand anzeigt, wird durch das Modell definiert. Die Entscheidung, unter welchen Umständen welcher Dialog welcher Phase aus Abbildung 2.3 zugeordnet wird, ist eine Designentscheidung bei der Anwendungsentwicklung. Das Phasenmodell kann von einer Anwendung genutzt werden, um Punkte innerhalb einer Konversation mit dem Partner zu vereinbaren, mit deren Erreichen beide Partner verbindliche Aussagen über den Gesprächsverlauf treffen. Das Modell der Business Conversations verwendet zwei Beschreibungsebenen für Konversationen, die im Folgenden getrennt vorgestellt werden: 1. Die Ebene der Konversationsspezifikationen: Auf dieser Ebene wird die Struktur möglicher Konversationen definiert. Diese Ebene entspricht der Typebene einer Programmiersprache, mit dem Unterschied, daß Konversationsspezifikationen eine Laufzeitrepräsentation besitzen. Konversationsspezifikationen bilden Fabriken (engl. factories), welche die Erzeugung von Konversationen, ihren Instanzen, steuern. 2. Die Ebene der Konversationsinstanzen: Gegenstand dieser Ebene sind konkrete Konversationen, die zwischen einem Kunden und einem Dienstleister stattfinden. Konversationen sind immer konform zu einer zugehörigen Konversationsspezifikation. Sie werden anhand dieser Spezifikation erzeugt und sind an ein Kunde-Dienstleister-Paar gebunden Konversationsspezifikationen Die Abbildung 2.4 zeigt ein Modell für Spezifikationen von Konversationen. Das Diagramm ist in der OMT-Notation [RBP+91] dargestellt. Konversationsspezifikationen legen fest, welche Struktur Konversationsobjekte im Falle einer Instantiierung haben sollen. Sie umfassen dabei sowohl den statischen Teil einer Konversation, also die Datenmodellierung für den Informationsaustausch, als auch den dynamischen Teil der Beziehung zwischen Kunden und Dienstleistern, die Prozeßmodellierung. Spezifikationen sind inspizierbar: Beide Partner können untersuchen, ob die Konversation in ihren jeweiligen Kontext und zu ihrer Sicht des Kooperationsziels paßt. Nach diesem Modell enthält jede Konversationsspezifikation (siehe Anhang C.1) mehrere Dialogspezifikationen. Eine dieser Dialogspezifikationen ist als initialer Dialog ausgezeichnet, jede Konversation dieses Typs beginnt mit diesem Dialog. Dialogspezifikationen bestehen aus Inhaltsspezifikationen und Spezifikationen für Anforderungen. Jede Anforderungsspezifikation ist über die possiblereplies-beziehung mit der Spezifikation des nachfolgenden Dialogs verbunden. Die Markierung ellipses zeigt an, daß sich die Aktion, die beim Dienstleister auf die Auswertung des Dialoges folgt, über mehrere Dialoge hinziehen kann, deren Spezifikation nicht sichtbar sind. Dieses ermöglicht es dem Dienstleister, Teile der Spezifikation zu verbergen und sie bei Bedarf zu ändern, ohne die zukünftigen Kunden informieren zu müssen. Die Inhalte können auf verschiedene Art und Weise spezifiziert werden. Zum einen gibt es einfache Basistypen wie ganze Zahlen, rationale Zahlen, Zeichenketten, einen Datumstyp und

25 2.3. Konzepte 15 einen Spezifikationsobjekttyp. Zum anderen können komplexe Inhalte mit Records, Varianten, Auswahllisten oder Sequenzen modelliert werden, wobei auch verschachtelte Inhalte zugelassen sind. Für alle Inhaltstypen existieren Operationen zum Erzeugen der entsprechenden Spezifikationsobjekte. Die Operationen auf den Spezifikationsobjekten sind in der Abbildung aus Gründen der Übersichtlichkeit nicht dargestellt. Auf der Ebene der Konversationsspezifikationen können Meta-Dienste erstellt werden, die auf diesen Spezifikationsobjekten operieren. In erster Linie sind das grafische Editoren oder Anzeiger, Modellverifikatoren und Spezifikationsmakler. Wichtiger Nutzen der Spezifikationen ist ihre Überprüfbarkeit, durch die eine gesicherte maschinelle Abwicklung von Konversationen unter Beibehaltung der Autonomie der Partner ermöglicht wird. Alle Spezifikationen sind sowohl in der Implementationssprache als auch im eigenen Typsystem Objekte erster Klasse. Sie können somit benannt, gespeichert oder verschickt werden und besitzen eine Laufzeitrepräsentation. Die atomaren Inhaltsobjekte Integer (Int), reelle Zahl (Real), Zeichenkette (String) und Datum (Date) stellen gegenüber bekannten Programmiersprachen keine Besonderheit dar. Sequence ist eine Liste von Elementen; SingleChoice ermöglicht die Auswahl eines Elements aus einer Liste von Elementen; MultipleChoice ist der Typ für die Auswahl mehrerer Elemente aus einer Liste von Elementen. Zu beachten ist hierbei, daß die Elemente dieser Listen sowohl von atomarem Typ als auch von komplexem Typ sein können. Die interne Realisierung erfolgte über eine Iteration. Der Record Typ (Rcd) ist ebenfalls als Iteration realisiert. Der variante Typ (Variant) letztendlich bedarf einer näheren Erläuterung, da auf die Visualisierung dieses Typs in Abschnitt noch besonders eingegangen werden soll. Er wird deshalb in Abschnitt 4.3 ausführlicher behandelt.

26 16 2. Das Modell der Business Conversations TBCSpec name :String initialdialogspec dialogspecs possiblereplies DialogSpec name :String possiblerequests contentspec RequestSpec name :String ellipses :Bool TBCContentSpec spec Int Real String Date MultipleChoice SingleChoice Variant Rcd elements 1+ CSpec Dialog Sequence NamedContentSpec name :String Abbildung 2.4: Spezifikation von Konversationen, Dialogen und Inhalten

27 2.3. Konzepte Konversationsinstanzen Die nachfolgende Abbildung 2.5 zeigt den Aufbau von Instanzen von Konversationen und den Zusammenhang mit Spezifikationen. Von einer Konversationsspezifikation können beliebig viele Konversationen instantiiert werden. Jede Konversation befindet sich zu einem Zeitpunkt in einem Quadranten der Ellipse aus Abbildung 2.1 und erlaubt den Zugriff auf den aktuellen Dialog (current-dialog Beziehung). Jeder Dialog wird innerhalb der Konversationsspezifikation durch eine Dialogspezifikation inhaltlich vorgegeben. Basierend auf den Dialogspezifikationen werden konkrete Dialoge erzeugt. Aus dem Dialog heraus ist der Inhalt, der aus der Dialogspezifikation erzeugt wurde, erreichbar. Die Objektstruktur für die Instanzen der Inhaltsspezifikationen sind in Abbildung 2.5 zu sehen. Für jeden Inhaltstyp sind bestimmte Operationen definiert, an denen sich die Funktionalität der Visualisierung in Abschnitt 4.3 ausrichtet. 1. Der Wert der Int, Real, String, Date, SingleChoice, MultipleChoice, Cspec und Dialog Objekte kann gelesen und gesetzt werden. 2. In Listenobjekten für eine einfache Auswahl (SingleChoice) können die Alternativen gesetzt werden, man kann alle Alternativen auslesen und genau eine davon auswählen. Außerdem kann die gewählte Alternative bestimmt werden. In Listenobjekten für mehrere Wahlmöglichkeiten (MultipleChoice) enthält der Zustand beliebig viele Selektionen. Zusätzlich zu den Operationen bei Listenobjekten mit einfacher Auswahl können gewählte Alternativen wieder deselektiert werden. 3. In einem Record-Objekt (Rcd) können die aggregierten Inhaltsobjekte über ihren Namen referenziert werden. In einem varianten Record-Objekt (Variant) können zusätzlich gekapselte Varianten ausgewählt oder die Auswahl gelesen werden. 4. Die durch Objekte des Sequenztyps aggregierten Objekte (Sequence) sind nicht direkt in das Dialogobjekt eingebunden. Stattdessen stellen Sequenz-Objekte Methoden für den Zugriff auf Massendatenbestände durch Klienten zur Verfügung. Die Erzeugung von Sequenzobjekten erfordert die Konkretisierung der von der Objektschnittstelle geforderten abstrakten Zugriffsfunktionen auf den Datenbestand, der von der Sequenz repräsentiert werden soll [Joha97].

28 18 2. Das Modell der Business Conversations Agent(A) state() :A self() :agent.t migrateto(...) :Ok meet(...) :agent.t meetandtalk(...) :TBConv(S) addcustomerrole addperformerrole CustomerRole(S) isnil() :Bool startconversation(...) :Ok spec TBCSpec name :String spec PerformerRole(S) isnil() :Bool set spec set CustomerRule Conversation(S) PerformerRule c TBConv(S) s:s newdialog(...) :Dialog savedialog(...) :Ok copyhistorydialog() :Dialog currentdialog DialogSpec name :String spec Dialog Request content TBCContentSpec spec TBCContent Int Real String Date set(...) :Ok get() :Int set(...) :Ok get() :Real set(...) :Ok get() :String set(...) :Ok get() :NewDate MultipleChoice SingleChoice Variant Rcd get() :iter.t getchoices() :iter.t choose(...) :Ok discard(...) :Ok select(...) :Ok setchoices(...):ok get() :T getchoices() :iter.t choose(...) :Ok select(...) :Ok setchoices(...):ok select(...) :Ok selected() :String ref 1+ CSpec Dialog Sequence NamedContentSpec set(...) :Ok get() : CSpec set(...) :Ok get() : Dialog set(...) :Ok get() :Sequence name :String Abbildung 2.5: Instanzen von Konversationen, Dialogen und Inhalten

29 2.4. Invarianten des Modells Invarianten des Modells Die folgenden Invarianten sollen Interpretationsmöglichkeiten innerhalb des Modells einschränken. Ziel ist es, möglichst viele Punkte eindeutig festzulegen. 1. Alle Dialogspezifikationen einer Konversationsspezifikation haben verschiedene Namen. Das gleiche gilt für alle benannten Inhaltsspezifikationen und alle Anfragespezifikationen einer Dialogspezifikation. 2. Eine Dialogspezifikation gehört zu genau einer Konversationsspezifikation. Unterschiedliche Konversationsspezifikationen können gleiche Dialogspezifikationen enthalten. Diese Dialogspezifikationen haben nicht die gleiche Objektidentität. 3. Benannte Inhaltsspezifikation und Anfragespezifikationen gehören zu genau einer Dialogspezifikation. 4. Unterschiedliche Dialogspezifikation können gleich benannte Inhaltsspezifikationen oder gleiche Anfragespezifikationen enthalten. Diese Inhaltsspezifikationen und Anfragespezifikationen haben in den verschiedenen Dialogspezifikationen nicht die gleiche Objektidentität. 5. Die Namen der Objekte dienen in ihren jeweiligen Sichtbarkeitsbereichen als Schlüssel zur Identifikation. 6. Jede Konversationsspezifikation enthält die Spezifikation und Benennung eines initialen Dialoges. 7. Jede Konversationsspezifikation hat eine finale Dialogspezifikation mit dem Namen breakdown. Damit bleibt jede Konversation auch in Ausnahmefällen in einem gesicherten Zustand. Es kann mithin keine unvorhergesehenen Konfigurationen geben. 8. Jede Dialogspezifikation mit dem Namen breakdown hat benannte Inhaltsspezifikationen mit den Namen lastdialog, reason. Dadurch kann aus der Abbruchsituation später der Grund für den Abbruch sowie der letzte erfolgreich bearbeitete Dialog, rekonstruiert werden. 9. Alle finalen Dialogspezifikationen haben keine Folgedialoge und deswegen keine Anfragespezifikationen. 10. Wird ein finaler Dialog in einer Konversation erreicht, so wird diese bei beiden Partnern beendet.

30

31 21 3. Kapitel Das Agentensystem Um beurteilen zu können, was mit dem gegebenen System der Business Conversations in Bezug auf eine Visualisierung realisierbar ist, reicht es nicht aus, nur das Modell zu kennen. Es muß auch das Wissen über die Implementierung dieses Modells vorhanden sein. In diesem Kapitel wird deshalb der grundlegende Aufbau des von Johannisson entwickelten Agentensystems beschrieben. Weitere Informationen zu den zugrundeliegenden Konzepten und zur Implementation finden sich in [Krus97, Joha97]. 3.1 Der Aufbau des Tycoon-Agentensystems Das Agentensystem wurde von Johannisson [Joha97] im Rahmen seiner Diplomarbeit entworfen und prototypisch in der Programmiersprache Tycoon entwickelt. Hierbei handelt es sich um eine persistente, polymorphe, orthogonale und typsichere Sprache. Es soll hier darauf verzichtet werden, diese Sprache näher zu erklären. Genaue Informationen zu Tycoon finden sich in [Matt95, MMS94, MSS95, MMM93, GM94, MS92, MS93]. Eine weitere Implementierung eines Agentensystems für die Business Conversations, in der objektorientierten Sprache Tycoon-2, wird von Wegner [Wegn98] im Rahmen seiner Diplomarbeit vorgenommen. Anwendungssysteme Anwendungssysteme Agentensystem Agentensystem Business Conversations Business Conversations Nachrichtensubsystem Nachrichtensubsystem Kommunikationsinfrastruktur Abbildung 3.1: Aufbau des Tycoon Agentensystems Die Agenten, durch die Anwendungen implementiert werden, sind der Anwendungsebene zuzuordnen. Das Agentensystem (agentenv) besteht aus mehreren Teilen. Der zentrale Teil ist das

32 22 3. Das Agentensystem Modul agent.tm. Es enthält sowohl das eigentliche Agentensystem, worin die Ereignisverwaltung integriert ist, als auch die Möglichkeiten, mobile Agenten, Domänen und Orte zu erzeugen. Das Modul location.tm ist für die Adressierung und Namensauflösung zuständig. In wwuid.tm sind Möglichkeiten vorhanden, eindeutige Identifikationen zu erzeugen. Die für das Agentensystem notwendige Basis liefern die Bibliotheken der Business Conversations (tbcenv) und des Nachrichtensubsystems (itcenv). In den Business Conversations werden die Datentypen und Methoden der Konversationen, Dialoge, Anfragen und Inhaltsobjekte definiert. Das Agentensystem benutzt diese für die Kommunikation der Agenten untereinander. Das Nachrichtensubsystem wird in Abschnitt 3.2 näher erläutert. Die Visualisierung soll es ermöglichen, die Inhalte der Dialoge von Kommunikationen darzustellen. Zu diesem Zweck soll die Visualisierung in der obersten Ebene des Tycoon- Agentensystems angesiedelt werden. Es sollen möglichst wenige Änderungen an den zugrundeliegenden Systemen vorgenommen werden. Sind Änderungen notwendig, so ist darauf zu achten, daß bereits existierende Agenten und parallele Projekte nicht beeinträchtigt werden. 3.2 Das Nachrichtensubsystem Durch das Nachrichtensubsystem wird eine nachrichtenorientierte, asynchrone und domänenübergreifende Kommunikation zwischen den Agenten ermöglicht. Es übernimmt für das Agentensystem die Rolle des Postboten und wird im folgenden mit ITC (Inter Thread Communication) abgekürzt. Die Agenten kommunizieren mit Nachrichten. Dienstleisterthread Kundenthread Hauptthread Kundenthread Dienstleisterthread Hauptthread Agent A Agent B Abbildung 3.2: Die Threads und Nachrichten eines Agenten Ein einzelner Agent besteht aus drei Threads des Tycoonsystems. Threads des Tycoonsystems sind keine Betriebssystemthreads. Der Hauptthread empfängt alle Nachrichten und leitet sie, sofern sie nicht an ihn selber gerichtet waren, an einen der beiden anderen Threads weiter. Der Kunden- und der Dienstleisterthread empfangen diese Nachrichten und führen je nach Nachrichtentyp entweder interne Aktionen oder Regeln aus. Die internen Aktionen sind vom Agentensystem vorgegeben und

33 3.3. Migration von Agenten 23 für alle Agenten gleich. Die Regeln werden für jeden Agenten gesondert festgelegt. Nähere Informationen hierzu sind in Abschnitt 3.5 zu finden. Es existiert keine von außen zugängliche Bindung an den Agenten, um direkt auf ihn zugreifen zu können. Dadurch wird die Autonomität der Agenten gewährleistet. Eine Kommunikation mit den Agenten ist nur über Nachrichten möglich. Werden Nachrichten zwischen Kunden und Dienstleistern ausgetauscht, so wird automatisch die ID der jeweiligen Konversation mit in die Nachricht eingebunden. So kann beim Empfänger der Hauptthread des Agenten jede Nachricht einer Konversation dem Kunden- oder Dienstleisterthread zuordnen. Die Nachrichten enthalten außerdem einen Dialog und, sofern ein Kunde der Absender war, eine Anfrage. Die damit verbundene Auslösung der Regeln wird in Abschnitt 3.5 näher erläutert. Es lassen sich nur typisierte Nachrichten verschicken. Um beliebige neue Nachrichtentypen zu definieren sind Änderungen in itcmessage erforderlich. Alle Nachrichten durchlaufen, bevor sie an eine andere Domäne oder einen lokalen Empfänger übermittelt werden, den Mediator. Der Mediator ist ein optionaler Systemdienst des Nachrichtensubsystems. Die Funktionsweise des Mediators wird ausführlich in [Krus97] beschrieben. Dort wird sie unter anderem dazu benutzt, den Nachrichtenverkehr zu protokollieren. Es ist aber auch möglich, Sicherheitsverfahren an dieser Stelle in das System zu integrieren [Fech97]. 3.3 Migration von Agenten Unter Migration versteht man die Fähigkeit von Programmen oder Programmteilen, sich innerhalb eines Rechnernetzes von einem Ort zu einem anderen zu bewegen. Ein Agent kann entweder als mobiler Agent oder als Ort (Place) in einer Domäne (Domain) initialisiert werden. Jeder Ort einer Domäne kann weitere Orte enthalten. In Abschnitt wird auf Besonderheiten eingegangen, die auftreten, wenn Agenten, die Informationen im Internet darstellen, von einem zum anderen Ort migrieren. Beim Erzeugen einer Domäne werden automatisch die dazugehörigen Agentensystem- und Nachrichtensubsystemkomponenten initialisiert. Es ist möglich, auf einem Rechner mehrere Domänen zu erzeugen.