Paper (PDF) - STS

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

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.

I
Inhaltsverzeichnis
1. Einführung und Motivation................................................................................................ 1
1.1 Das Tycoon Business Conversations - Projekt...................................................................... 2
1.2 Das Agentensystem ............................................................................................................... 2
1.3 Ein Anwendungsbeispiel .......................................................................................................3
1.4 Zielsetzung dieser Arbeit....................................................................................................... 4
1.5 Aufbau der Arbeit.................................................................................................................. 4
2. Das Modell der Business Conversations............................................................................ 7
2.1 Das Kooperationsleitbild ....................................................................................................... 7
2.2 Grundlagen ............................................................................................................................ 8
2.3 Konzepte.............................................................................................................................. 11
2.3.1 Das Verarbeitungmodell von Konversationen..................................................................... 11
2.3.2 Sekundäre Konversationen.................................................................................................. 13
2.3.3 Finale Dialoge ..................................................................................................................... 13
2.3.4 Konversationsspezifikationen.............................................................................................. 14
2.3.5 Konversationsinstanzen....................................................................................................... 17
2.4 Invarianten des Modells....................................................................................................... 19
3. Das Agentensystem............................................................................................................ 21
3.1 Der Aufbau des Tycoon-Agentensystems ........................................................................... 21
3.2 Das Nachrichtensubsystem.................................................................................................. 22
3.3 Migration von Agenten........................................................................................................23
3.4 Starten von Konversationen................................................................................................. 25
3.5 Regeldefinition und -auslösung........................................................................................... 27
3.6 Zusammenfassung ............................................................................................................... 28

II
Inhaltsverzeichnis
4. Grundlagen und Anforderungen der Visualisierung ..................................................... 29
4.1 Grundlagen der Visualisierung............................................................................................ 30
4.2 Visualisierung im Internet ...................................................................................................31
4.3 Datentypen der Business Conversations.............................................................................. 32
4.4 Allgemeine Anforderungen ................................................................................................. 34
4.5 Synchrone und asynchrone Verbindungen .......................................................................... 35
4.6 Funktionalität des Agentensystems ..................................................................................... 35
4.7 Dynamische Visualisierung................................................................................................. 36
4.7.1 Dialogobjekte....................................................................................................................... 37
4.7.2 Anfragen .............................................................................................................................. 40
4.7.3 Inhaltsobjekte....................................................................................................................... 40
4.8 Visualisierungsvorlagen ......................................................................................................41
4.8.1 Dienstleisterseite.................................................................................................................. 43
4.8.2 Kundenseite ......................................................................................................................... 43
4.8.3 Erstellung der Vorlagen....................................................................................................... 44
4.8.4 Abspeicherung der Vorlagen ............................................................................................... 45
4.8.5 Aufruf der Vorlagen ............................................................................................................ 47
4.9 Zusammenfassung ............................................................................................................... 48
5. Analyse der Tycoon Business Objects.............................................................................. 49
5.1 Verbindungsablauf............................................................................................................... 49
5.2 Daten- und Aktionsobjekte.................................................................................................. 51
5.3 Seitenobjekte ....................................................................................................................... 52
5.4 Zusammenfassung ............................................................................................................... 53
6. Design der Visualisierungskomponente........................................................................... 55
6.1 Atomare Datentypen............................................................................................................ 55
6.2 Komplexe Datentypen ......................................................................................................... 56
6.2.1 Auswahltypen ...................................................................................................................... 57
6.2.2 Dialoge................................................................................................................................. 60
6.2.3 Sequence.............................................................................................................................. 61
6.2.4 Rcd und Variant................................................................................................................... 63
6.3 Anfragen .............................................................................................................................. 64
6.4 Einordnung des Visualisierungsdienstes ............................................................................. 64

Inhaltsverzeichnis
III
6.4.1 Zentraler Visualisierungsdienst ........................................................................................... 65
6.4.2 Integrierter Visualisierungsdienst........................................................................................ 68
6.5 Nebenläufigkeit und Migration ........................................................................................... 69
6.6 Zusammenfassung ............................................................................................................... 71
7. Realisierung der Visualisierungskomponente................................................................. 73
7.1 Starten des Visualisierungsservers ...................................................................................... 73
7.2 Verwaltung der Konversationen.......................................................................................... 74
7.3 Verbindungsablauf .............................................................................................................. 76
7.3.1 Starten von Konversationen.................................................................................................79
7.3.2 Migration ............................................................................................................................. 79
7.3.3 Übertragung der Daten ........................................................................................................ 80
7.4 Synchrone und asynchrone Kommunikation....................................................................... 81
7.5 Erweiterungen der Tycoon Business Objects...................................................................... 83
7.6 Vorarbeiten für die dynamische Visualisierung .................................................................. 83
8. Zusammenfassung und Ausblick ..................................................................................... 85
8.1 Zusammenfassung ............................................................................................................... 85
8.2 Ausblick............................................................................................................................... 87
A. Glossar................................................................................................................................ 91
A.1 Glossar der Agententerminologie........................................................................................ 91
A.2 Glossar der Business Conversations.................................................................................... 93
B. Abkürzungen...................................................................................................................... 95
C. Ausgewählte Programmbeispiele zur Visualisierung..................................................... 97
C.1 Konversationsspezifikation Kreditvergabe.......................................................................... 97
C.2 Konversationsspezifikation Portnummer holen................................................................... 99
C.3 Regeldefinition .................................................................................................................... 99
C.4 Typdefinition von agent.Conversation ................................................................................ 99
C.5 Datentypdefinition in TBCContent.ti ................................................................................ 100
C.6 Typdefinition von tbConv.Dialog...................................................................................... 100
C.7 Kreditdaten Dialog Spezifikation ...................................................................................... 100
C.8 Inhaltsobjekt eines Dialoges.............................................................................................. 101
C.9 Generische Typermittlung ................................................................................................. 101

IV
Inhaltsverzeichnis
C.10 Tycoon Business Objects Seitenobjekt.............................................................................. 101
C.11 Tycoon Business Objects Datenobjekte ............................................................................ 102
C.12 Tycoon Business Conversations Aktionsobjekt ................................................................ 102
Literaturverzeichnis ..................................................................................................................... 103

V
Abbildungsverzeichnis
2.1: Phaseneinteilung einer Kommunikation .................................................................................. 9
2.2: Modellbildung für Informationssysteme................................................................................ 10
2.3: Verfeinerung mittels sekundären Konversationen ................................................................. 13
2.4: Spezifikation von Konversationen, Dialogen und Inhalten.................................................... 16
2.5: Instanzen von Konversationen, Dialogen und Inhalten ......................................................... 18
3.1: Aufbau des Tycoon Agentensystems ..................................................................................... 21
3.2: Die Threads und Nachrichten eines Agenten......................................................................... 22
3.3: Zuordnung der Agenten zu Orten und Domänen ................................................................... 24
3.4: Logische Struktur der Agentenwelt ....................................................................................... 25
3.5: Zustandsdiagramm einer Konversation.................................................................................. 26
3.6: Objektstrukturmodell von Agent und Rolle........................................................................... 27
4.1: Ansätze zur Datenvisualisierung............................................................................................36
4.2: Objektstrukturmodell zum Zugriff auf Dialogobjekte ........................................................... 39
4.3: Struktur der Visualisierungsvorlagen..................................................................................... 42
4.4: Informationsfluß zur Visualisierung ...................................................................................... 46
5.1: Verbindungsablauf der Visualisierung................................................................................... 50
5.2: Aufbau eines Seitenobjektes .................................................................................................. 53
6.1: Visualisierung atomarer Daten............................................................................................... 55
6.2: Kennwortfeld ......................................................................................................................... 56
6.3: Textbereich............................................................................................................................. 56
6.4: Visualisierung der SingleChoice als Kombinationsfeld......................................................... 58
6.5: Visualisierung der SingleChoice mit atomaren Daten ........................................................... 58
6.6: Komplexe Optionsgruppe ...................................................................................................... 59
6.7: Visualisierung der MultipleChoice ........................................................................................ 59
6.8: Visualisierung von Dialogen mit Frames............................................................................... 60
6.9: Zweidimensionale Tabelle ..................................................................................................... 61
6.10: Mehrdimensionale Tabelle..................................................................................................... 62

VI
Abbildungsverzeichnis
6.11: Visualisierung einer Anfrage durch eine Schaltfläche ........................................................... 64
6.12: Externer Visualisierungsdienst............................................................................................... 65
6.13: Zentraler Visualisierungsagent............................................................................................... 66
6.14: Integrierte Visualisierung....................................................................................................... 69
6.15: Threads der integrierten Visualisierung ................................................................................. 70
7.1: Hauptmenü des Agenten ........................................................................................................ 74
7.2: Konversationsliste .................................................................................................................. 75
7.3: Verbindungsablauf zur Visualisierung................................................................................... 76
7.4: Zustandsdiagramm der Visualisierung beim Kunden ............................................................ 78
7.5: Konversationsübersicht .......................................................................................................... 82
C.1: Konversationsspezifikation Kreditvergabe ............................................................................ 98

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].

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

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.

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

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.

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 3.
2.1 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.

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.

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

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

2.3. Konzepte 11
2.3 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.
2.3.1 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.

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.

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.
2.3.2 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.
2.3.3 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.

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.
2.3.4 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

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 6.2.4 noch
besonders eingegangen werden soll. Er wird deshalb in Abschnitt 4.3 ausführlicher behandelt.

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

2.3. Konzepte 17
2.3.5 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].

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

2.4. Invarianten des Modells 19
2.4 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.

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

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

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 7.3.2 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.

24 3. Das Agentensystem
Domain
rootPlace
Agent
ITC
subplaces
owner :T
name :String
birth() :Ok
meet() :T
die() :Ok
leave :Ok
enter :Ok
Place
MobileAgent
owner :T
name :String
birth() :Ok
meet() :T
die() :Ok
incomingAgent() :Bool
outgoingAgent() :Ok
Abbildung 3.3: Zuordnung der Agenten zu Orten und Domänen
Für mobile Agenten stellt das Agentensystem Funktionen zum lokalen und domänenübergreifenden
Migrieren innerhalb der in Abbildung 3.3 dargestellten Methoden des Agenten zur Verfügung. Im
Prototyp ist die Migration innerhalb der Regeln (siehe Abschnitt 3.5) des Agenten noch nicht
vollständig realisiert. Die Regeln werden in der birth-Methode des Agenten definiert. Die
Grundlagen für die Migration von Tycoon-Threads wurden mit der Arbeit von Mathiske [Math96]
gelegt und werden im Agentensystem genutzt, um komplette Agenten mit ihren Threads migrieren
zu lassen. Ein derartiger mobiler Agent hat fünf Methoden zur Verfügung.
Die birth-Methode wird ausgeführt, sobald der Agent in seinem Ort erzeugt worden ist. Die die-
Methode, bevor der Agent beendet wird. Die meet-Methode wird angewendet, wenn ein anderer
Agent versucht, sich mit diesem Agenten zu treffen. Die leave-Methode kommt zur Ausführung,
sobald die Domäne bereit ist, den Agenten an einen anderen Ort zu schicken. Hiernach werden die
lokalen Bindungen zum Agenten- und Nachrichtensubsystem gelöst. Danach werden die drei
Threads des Agenten linearisiert und an den neuen Ort geschickt [Joha97]. Sobald der linearisierte
Agent im neuen Ort angekommen ist, wird er an das dort vorhandene Agenten- und
Nachrichtensystem gebunden. Danach wird die enter-Methode ausgeführt. Vor dem Betreten des
Ortes muß der Ort zustimmen. Die Zustimmung des Ortes erfolgt durch den Ortewächter (Place
Guard), hierzu wird die Funktion incomingAgent benutzt. Es kann also auch vorkommen, daß der
Zutritt, basierend auf der jeweiligen Definition des Ortes, verweigert wird. Diese Möglichkeit ist
ein Ansatzpunkt für ein Sicherheitssystem.
Bei einer Migration mittels der Methode migrateTo werden die Objekte, zu denen Bindungen
bestehen, an den neuen Ort mitgenommen. Ausnahmen hiervon bilden das Agentensystem und das
Nachrichtensubsystem. Beide sind am neuen Ort bereits vorhanden. Findet die Migration innerhalb
der Domäne statt, so werden nur die internen Datenstrukturen des lokalen Agentensystems
angepaßt. Eine Migration muß in einem nicht aufteilbaren Programmschritt (transaktional)
erfolgen, um Fehler, wie das Löschen von Agenten, zu vermeiden [Mat96, GMI95a].

3.4. Starten von Konversationen 25
Domain
P
P
P
n
Place Guard n
Migration
0
1
11 12
P
Linearized
Agent
Agent
P
Place n
Abbildung 3.4: Logische Struktur der Agentenwelt
Migriert ein Agent von einem Ort zum anderen, so wird zuerst eine Kopie des Agenten erzeugt.
Diese wird dann am neuen Ort aufgebaut. Die Methode incomingAgent wird ausgeführt und muß
entscheiden, ob der Agent eintreten darf. Erfolgt ein Eintritt, wird der Agent am alten Ort gelöscht.
Wird der Eintritt verwehrt, so wird die Kopie des Agenten am neuen Ort gelöscht. Vor dem
Verlassen des Ortes wird outgoingAgent ausgeführt.
3.4 Starten von Konversationen
Es gibt zwei Methoden Konversationen zu starten. Bei der meetAndTalk-Methode trifft sich der
Agent mit dem Dienstleister und baut eine synchrone Konversation auf. Das Ergebnis der Methode
ist eine Konversation vom Typ TBConv.T. Diese Methode blockiert den aufrufenden Thread bis
zum Ende der Konversation. Sie wird in einigen Fällen für sekundäre Konversationen genutzt,
wenn die Fortsetzung der primären Konversation vom Ergebnis der sekundären abhängt. Für das
meetAndTalk müssen sich die Agenten in der gleichen Domäne befinden.
Die zweite Methode erzeugt eine asynchrone Konversation. Sie gliedert sich in zwei Teilschritte.
Der erste ist das Treffen mit dem anderen Agenten (meet). Der zweite ist das Starten der
Konversation (startConversation). Für das meet müssen beide Agenten in derselben Domäne sein.
Zur Zeit muß auch das startConversation in derselben Domäne erfolgen. Es ist also auch hiermit
nicht möglich, zuerst zu migrieren, den anderen Agenten zu treffen, zurückzumigrieren und aus der
anderen Domäne heraus die Konversation zu starten. Bei dieser Arbeitsweise kommt es zu keiner
Blockade des aufrufenden Threads. Sie ist deshalb die standardmäßig verwendete Methode.

26 3. Das Agentensystem
Kundenagent
gestartet
Initiale Anfrage
Dienstleister hat
initiale Anfrage
erhalten
Initialer Dialog
Kunde hat Dialog
erhalten
Dialog und Anfrage
Dialog
Dienstleister hat
Dialog und
Anfrage erhalten
finaler Dialog
Kunde hat finalen
Dialog erhalten
Abbildung 3.5: Zustandsdiagramm einer Konversation
Zum Starten einer Konversation erzeugt der Kunde den initialen Dialog des BC-Modells und
schickt ihn mit der initialen Anfrage und der Konversationsspezifikation an den Dienstleister. Die
Spezifikationen sind inspizierbar. Beide Partner können so untersuchen, ob die Konversation in
ihren jeweiligen Kontext und zu ihrer Sicht des Kooperationsziels paßt.
Der Dienstleister antwortet ihm mit dem initialen Dialog laut Konversationsspezifikation. Danach
findet die Konversation statt. Sie kann sich über viele Anfragen und Dialoge erstrecken. Es gibt
hierbei keine Anfrage ohne Dialog. Währenddessen können weitere Konversationen begonnen und
beendet werden. Zur Zeit ist keine Zugriffsmethode vorhanden, die eine Übersicht über alle
laufenden oder abgeschlossenen Konversationen eines Agenten liefert. Zum Beenden der
Konversation sendet der Dienstleister den in Abschnitt 2.3.3 geschilderten finalen Dialog.

3.5. Regeldefinition und -auslösung 27
3.5 Regeldefinition und -auslösung
Die Definitionen der Regeln, die auszuführen sind, sobald ein Dialog bzw. eine Anfrage gesendet
wird, sind in den Agenten enthalten. Ein Beispiel einer derartigen Regeldefinition findet sich in
Abschnitt 0. Das Aktivieren dieser Regeln ist im zugrundeliegenden Agentensystem im Modul
agent.tm zu finden.
a :A
Agent(A)
state() :A
self() :agent.T
meet(...) :agent.T
meetAndTalk(...) :tbConv.T(S)
migrateTo(...) :Ok
addCustomerRole
addPerformerRole
s :S
CustomerRole(S)
spec() :tbcSpec.T
isNil() :Bool
set(...) :Ok
startConversation(...) :Ok
s:S
PerformerRole(S)
spec() :tbcSpec.T
isNil() :Bool
set(...) :Ok
Abbildung 3.6: Objektstrukturmodell von Agent und Rolle
Ein Agent kann, wie es in Abbildung 2.3 und Abbildung 3.6 dargestellt wurde, sowohl Kunde als
auch Dienstleister sein. Dementsprechend kann er Regeln für beide Rollen beinhalten. Es bestehen
jedoch Unterschiede bei der Definition der Regeln. Unabhängig von den tatsächlich definierten
Regeln wird für jeden Agenten ein Kunden- und ein Dienstleisterthread gestartet.
Eine Regeldefinition für den Kunden besteht, wie in Abschnitt C.3 dargestellt, aus einer Funktion
mit zwei Parametern und der eigentlichen Regeldefinition. Die Parameter der Funktion sind der
Name des Dialoges, für den die Regel gedacht ist, und ein Funktionsaufruf, der einen Bezug auf die
Konversation liefert.
Beim Dienstleister gibt es demgegenüber bis auf einen weiteren Parameter, der den Namen der
gewählten Anfrage enthält, keinen Unterschied. Nur am Ende einer Regel wird ersichtlich, daß der
Dienstleister einen Dialog sendet, der Kunde dagegen eine Anfrage an den Dienstleister zurückgibt.
Daß bei einer Anfrage des Kunden auch der Dialog mit den geänderten Werten zurückgesandt
wird, ist aus einer Regel selber nicht ersichtlich. Hierbei handelt es sich um eine Funktionalität des
Agentensystems.

28 3. Das Agentensystem
Die Auslösung der Regeln erfolgt im Agenten, sobald eine entsprechende ITC-Nachricht
eingegangen ist. Für den Dienstleister- und den Kundenteil existieren im Modul agent.tm
Funktionen, in denen die ITC-Nachrichten abgehandelt werden. Für den Dienstleister sind dieses
die Funktion newSubP und der Nachrichtentyp customerDialogRequestA. Für den Kunden werden
die Funktion newSubC und der Nachrichtentyp performerDialogA benutzt.
Je nachdem, ob es sich um einen Regelaufruf für einen Dienstleister oder für einen Kunden
handelt, erfolgt der Aufruf etwas anders. Der Aufruf einer Kundenregel besteht aus dem internen
Namen der zugehörigen Spezifikation und dem Dialognamen. Für den Aufruf einer
Dienstleisterregel wird zusätzlich der Name der vom Kunden ausgewählten Anfrage benötigt.
Um den internen Namen zu erhalten, wird die interne ID der jeweiligen Konversation benutzt, weil
ein Agent in der Lage ist, mehrere Konversationen mit der gleichen Spezifikation zur gleichen Zeit
zu führen. Die interne Konversations-ID wird vom Agentensystem beim Absenden der o.g.
Nachrichten automatisch mit in die Nachrichten eingebunden. Ohne diese ID ist eine Aktivierung
von Regeln nicht möglich.
In Abschnitt 7.6 werden aufbauend auf der Regelaktivierung Grundlagen für die dynamische
Visualisierung realisiert.
3.6 Zusammenfassung
Das Agentensystem stellt die Realisierung einer Umgebung für Agenten dar. Es basiert auf einem
Nachrichtensubsystem zur Kommunikation und verwendet die BCs, in denen die grundsätzlichen
Definitionen der Datentypen und Methoden der Objekte des Modells enthalten sind, als
Kooperationsleitbild.
Der Beginn einer Konversation geht immer vom Kunden aus. Zum Starten von Konversationen
gibt es eine den Kunden blockierende und eine nicht blockierende Möglichkeit. Dieses Verhalten
der einzelnen Agenten wird durch ihre Regelbasis definiert. Die Regeln werden durch den
Hauptthread des Agenten ausgelöst. Ein Agent kann gleichzeitig eine beliebige Anzahl von
Konversationen führen. Da ein Agent sowohl einen Kunden- als auch einen Dienstleisterthread hat,
kann er zugleich Kunde und Dienstleister sein.

29
4. Kapitel
Grundlagen und Anforderungen der
Visualisierung
In diesem Kapitel werden zunächst die bei einer Visualisierung im Internet vorhandenen
Rahmenbedingungen untersucht und im Anschluß daran die Ansprüche erörtert, die durch die
Datentypen der TBCs gestellt werden. Danach werden allgemeine Anforderungen für die
Visualisierung der TBCs und die Unterschiede zwischen synchroner und asynchroner
Kommunikation diskutiert. Es schließen sich Überlegungen an, wie diese Anforderungen mit den
Business Conversations zu erfüllen sind und wo das Modell der Business Conversations erweitert
werden muß.
Darauf aufbauend werden die für eine dynamische Visualisierung zur Verfügung stehenden
Funktionalitäten des TBC-Systems aufgezeigt. Schließlich werden die für eine dynamische
Visualisierung notwendigen Voraussetzungen diskutiert. Auf diese Weise soll dieses Kapitel
Aufschlüsse darüber liefern, welche Komponenten in ein Basissystem zu integrieren sind, um die
dynamische Visualisierung zu ermöglichen. Basierend auf dem dynamischen Ansatz wird ein
System von Visualisierungsvorlagen analysiert, welches eine effektive dynamische Darstellung der
TBCs ermöglichen soll.
Da das Ausgabemedium mit dem Internet Client bereits festgelegt ist, wird auf einen Vergleich
bereits existierender Systeme verzichtet. Eine ausführliche Darstellung und vergleichende
Betrachtung existierender Dienste sowie deren Vor- und Nachteile findet sich in [Mues94]. Ein
weiterer Vergleich von Visualisierungsdiensten verschiedener Programmierumgebungen ist in
[Koeh96] enthalten.
Ein Großteil der Funktionalität, die in vielen Produkten, die in [Mues94] beschrieben werden, mit
der Visualisierung gegeben ist, läßt sich im HTTP nur mit Hilfe von Programmiersprachen wie
Java, Javascript oder HTML-Script abbilden. Diese Arbeit beschränkt sich auf den Einsatz von
HTML.
Um einen Dienst zur Visualisierung zu entwickeln, müssen die Anforderungen und Ziele definiert
werden, die dieser erfüllen soll. Zu diesem Zweck wird in dieser Arbeit ein allgemeines Modell der
TBCs genutzt. An diesem Modell wird untersucht, was zu visualisieren ist, wie dieses geschehen
soll, welche Rahmenbedingungen eingehalten werden müssen und welche Funktionalität auf den
visualisierten Objekten bereitgestellt werden muß.

30 4. Grundlagen und Anforderungen der Visualisierung
Bei der Visualisierung der TBCs handelt es sich in erster Linie um die Visualisierung der Werte,
die in Datenstrukturen enthalten sind. Sie werden im folgenden allgemein als Daten bezeichnet.
Durch die Anzeige dieser Daten werden die dahinter liegenden Datenstrukturen nur zum Teil mit
visualisiert, weil große Teile der strukturellen Informationen, wie z.B. Typinformationen, nicht
oder nur eingeschränkt wiedergegeben werden. Da aber jeder Dialog einem Schritt bei der
Abarbeitung des Workflows zuzuordnen ist, handelt es sich indirekt um die Visualisierung des
Status eines Workflows.
4.1 Grundlagen der Visualisierung
Visualisierung ist der Vorgang der Sichtbarmachung von Materie, Energie, Informationen oder
Prozessen. In der Informatik wird dieser Vorgang auf die Visualisierung von Daten, den direkten
Repräsentanten von Informationen [Kröm92] und Prozessen beschränkt.
Da das Auge das Hauptsinnesorgan des Menschen ist, mit ihm nimmt der Mensch den größten Teil
an von außen auf ihn einwirkenden Informationen wahr [Fran87], ist die Visualisierung die
wichtigste Möglichkeit zur Präsentation von Daten. Damit Daten für den Menschen visuell
wahrnehmbar werden, müssen sie in eine geeignete Darstellung umgewandelt werden. Weil das
Kurzzeitgedächnis nur eine kleine Anzahl an Elementen verarbeiten kann, ist es gerade bei
komplexen Strukturen wichtig, daß der Benutzer die visualisierten Seiten schnell und sicher
bedienen kann [Vogt97]. Auf den Einsatz von kontinuierlichen Animationen soll nach Möglichkeit
verzichtet werden, da diese die Konzentration des Benutzers auf die wesentlichen Inhalte einer
Seite erschweren [Keek97].
Grundsätzlich können verschiedene Aspekte visualisiert werden, z.B. der Programmtext, die
Datenstrukturen, die darin enthaltenen Werte, der Status eines in der Ausführung befindlichen
Programmes, der Kontrollfluß, der Ablauf eines Workflows oder die implementierten Algorithmen.
In allen Fällen erschwert jedoch große Komplexität die Visualisierung [Brow88] (siehe Abschnitt
6.2).
Bei der Datenvisualisierung sind die Benutzerschnittstellen mit interner und externer Kontrolle zu
unterscheiden [Götz94]. Die interne Kontrolle stellt den klassischen Ansatz dar. Hierbei liegt die
Kontrolle vollständig in der Applikation und es erfolgt eine unidirektionale Kommunikation
zwischen Applikation und Benutzerschnittstelle [Götz94]. Die Applikation ruft Funktionen der
Benutzerschnittstelle auf und bestimmt damit Zeitpunkt und Art der Interaktionsmöglichkeiten des
Benutzers. Da der Benutzer bei der internen Kontrolle zu jedem Zeitpunkt nur die von der
Applikation im aktuellen Modus vorgesehenen Interaktionsmöglichkeiten besitzt, werden die
daraus resultierenden Dialoge auch als modal bezeichnet. Eine weitere Charakterisierung der
internen Kontrolle bezeichnet diese Form der Dialogführung als systemgesteuerten Dialog
[Götz94].
Die Nachteile der internen Kontrolle haben zu der Entwicklung von Benutzerschnittstellen mit
externer Kontrolle geführt. Interaktive Benutzerschnittstellen mit einer externen
Kontrollarchitektur werden vollständig durch die Benutzerschnittstelle kontrolliert, so daß man
auch von einem benutzergesteuerten Dialog spricht. Die Applikation wird dabei in geeignete
Unterprogramme zerlegt. Diese Unterprogramme werden von der Benutzerschnittstelle als

4.2. Visualisierung im Internet 31
Reaktion auf Ereignisse (Benutzereingabe oder interne Nachrichten der Benutzerschnittstelle)
aufgerufen [Götz94].
Bei der Erstellung eines Gesamtsystems muß mit der Konzeption der Benutzerschnittstelle
begonnen werden, damit eine Einengung des Benutzers aus anwendungstechnischen oder
realisierungstechnischen Gründen vermieden wird [Hübn90]. Wenn die Konzeption der
Benutzerschnittstelle nicht vor der Systemerstellung erfolgen kann, muß das zugrundeliegende
System möglicherweise um die entsprechenden Komponenten erweitert werden, was einen
erhöhten Arbeitsaufwand darstellt. Dieser wird u.a. aus Kostengründen häufig vermieden, so daß
die Benutzerorientierung der Schnittstelle nur unvollkommen ist.
4.2 Visualisierung im Internet
Im Internet hat sich das Hypertext Transfer Protocol (HTTP) als ein Standard zur Übermittlung von
multimedialen Dokumenten etabliert. Dieses Kommunikationsprotokoll ermöglicht es, Text,
Grafiken, Klangdateien und andere Daten zu übermitteln und liefert damit die
Kommunikationsbasis für das World Wide Web [Morr95].
Mit dem HTTP übermittelte Dokumente werden auch HTML-Seiten genannt. Die Hypertext
Markup Language (HTML) ist eine systemunabhängig definierte Sprache für die Formatierung von
World Wide Web-Dokumenten. Sie enthält Methoden, mit denen Textcharakteristiken (z.B. Fett,
Kursiv), die Plazierung von Grafiken, Verknüpfungen u.a. festgelegt werden. Zur Anzeige eines
HTML-Dokuments wird ein HTTP-Client benötigt [Micr97]. Die Darstellung eines HTML-
Dokumentes kann je nach Client verschieden aussehen, weil mit HTML zwar die Inhalte einer
Seite spezifiziert werden können, die Visualisierung derselben jedoch nur eingeschränkt festlegbar
ist.
Auf dem Protokoll aufbauende HTTP-Clients, die auch als Web-Browser bezeichnet werden,
stehen für fast alle derzeit aktuellen Betriebssysteme zur Verfügung. Deshalb soll für die
Visualisierung ein Client benutzt werden, der das HTTP verwendet. Dadurch wird eine breite
Abdeckung der möglichen Benutzergruppen erreicht.
Als Web-Browser stehen unter anderem neuere Produkte, wie Netscapes Communicator oder der
Internet Explorer Vers. 4 von Microsoft, aber auch ältere Versionen dieser und anderer Hersteller
zur Verfügung. Für die Erzeugung der HTML-Seiten dürfen aus Kompatibilitätsgründen keine
Funktionen verwendet werden, die auf Besonderheiten einzelner Browser fußen.
Um eine Seite mit einem HTTP-Client darzustellen, wird eine Anfrage in Form eines Uniform
Resource Locators (URL) an einen Server gesandt. Mit dem URL (z.B. http://www.unihamburg.de/index.html)
wird der Ressourcentyp (z.B. FTP, HTTP oder Gopher), auf den
zugegriffen werden soll, der Standort und der genaue Speicherort der Daten innerhalb dieses
Standorts bezeichnet [Micr97]. Über das Internet wird die Anfrage an den entsprechenden Server
geleitet und dort ausgewertet. Falls die gewünschte Seite auf dem Server vorhanden ist, schickt er
diese in Form einer Nachricht zurück. Der Client visualisiert die Antwort.

32 4. Grundlagen und Anforderungen der Visualisierung
Für die Eingabe von Daten in HTML-Seiten, werden Formularbereiche (Forms) auf der HTML-
Seite definiert. Es ist möglich, auf jeder Seite mehrere Formularbereiche zu definieren. Die
Bereiche können weder ineinander verschachtelt werden noch überlappen. In diesen Bereichen sind
die einzelnen Formularfelder (siehe Abschnitt 6.1 und 6.2) enthalten. Die Daten aus den
Formularfeldern werden durch die Aktivierung einer absenden-Schaltfläche an den im Formular
spezifizierten Server gesandt (siehe Abschnitt 5.1). Dadurch wird ein HTTP-Request, der eine URL
und die eigene Adresse enthält, an den Server gesendet. Für das Übermitteln der in den
Formularfeldern vorhandenen Daten stellt das HTTP zwei Methoden zur Verfügung.
Bei der get-Methode wird ein "?" an die URL angehängt. Danach werden die in den
Formularfeldern vorhandenen Daten an die URL angehängt. Die Namen der Datenfelder werden
hierbei durch Gleichheitszeichen von den Daten getrennt. Die einzelnen Ausdrücke (z.B.
Name=Zade) werden durch das kaufmännische Und "&" separiert. Der letzte Ausdruck gibt den
Namen der aktivierten Schaltfläche wieder. Eine derartige URL hat folgendes Aussehen :
http://www.sts.tu-harburg.de/cgi-bin/tycoon?Name=Zade&Feld2=b&Anfrage= Abschicken.
Hierbei können nur Daten übermittelt werden, die dem ASCII-Zeichensatz entsprechen [W3C97].
Diese Methode wird standardmäßig von den Tycoon Business Objects (siehe Kapitel 5) verwendet.
Wird die post-Methode verwendet, so werden die Daten nicht in der URL sondern in einer
gesonderten Nachricht übermittelt.
4.3 Datentypen der Business Conversations
Weil es für eine Visualisierung wichtig ist, welche Datentypen in der zu visualisierenden Struktur
vorkommen können und welche Funktionalitäten auf ihnen definiert sind, werden im folgenden die
Datentypen der Business Conversations eingehend analysiert. Überblicke über die vorhandenen
Datentypen sind in Abbildung 2.4 und der Definition der Datentypen in TBCContent.ti (siehe
Abschnitt C.5) vorhanden.
Die atomaren Datentypen sind Int, Real, Date und String. Der Datentyp Cspec kann die
Spezifikation einer Konversation enthalten, der Datentyp Dialog einen kompletten Dialog. Beide
werden für die Archivierung von Konversationen benötigt [Krus97]. Da ein Dialog weitere Dialoge
als Inhaltsobjekte enthalten kann, muß es die Visualisierungskomponente ermöglichen, derartige
Hierarchien darzustellen. Die weiteren Datentypen Rcd, SingleChoice und MultipleChoice können
jeweils beliebige andere Datentypen der Business Conversations enthalten, sind also kaskadierbar.
Der Datentyp Sequence, der zum Zugriff auf Massendaten dient, hebt sich dadurch hervor, daß die
Zugriffsfunktionen auf die externen Datenstrukturen für jede Datenstruktur extra programmiert
werden müssen, also noch nicht vorhanden sind. Da die Möglichkeit, variante Inhaltsobjekte zu
deklarieren, eines der Merkmale ist, welches die TBCs von anderen Systemen unterscheidet, soll
sie näher erläutert werden.
Variante Datentypen (variant), in den TBCs als variante Tupel realisiert, sind sinnvoll, wenn
Fallunterscheidungen gemacht werden und für jeden Fall verschiedene Angaben benötigt werden.
Anhand eines Beispiels wird die Definition und der Zugriff auf diese Objekte erklärt, damit die
Diskussion der Visualisierung derartiger Objekte in Abschnitt 6.2.4 nachvollziehbar ist.

4.3. Datentypen der Business Conversations 33
Wie bereits in der Einleitung geschildert, hat ein Kunde eines Warenhauses die Möglichkeit, eine
Leistung mit einer Kundennummer oder Kreditkarte zu bezahlen. Die zugehörige Dialogdefinition
mit varianten Teilen kann folgendermaßen aussehen:
let Bezahlungsart_DialogSpec =
tbcSpec.dialogSpec (
"Bezahlungsart"
array
tbcSpec.requestSpec("absenden" array "Werte Formular" end false)
tbcSpec.requestSpec("abbruch" array "Endergebnis" end false)
end
array
tuple "Name" fun() tbcContent.stringSpec() end
tuple "Vorname" fun() tbcContent.stringSpec() end
tuple "Zahlungsart" fun() tbcContent.variantSpec(
array
tuple “Kundenkonto” fun() tbcContent.stringSpec() end
tuple "VISA" fun() tbcContent.rcdSpec(
array
tuple "Kartennummer" fun() tbcContent.intSpec() end
end )
end
end )
end
end )
tuple "Gueltigkeit"
fun() tbcContent.dateSpec() end
Den ersten Teil der Dialogdefinition bilden die zwei möglichen Aktionen „abschicken“ und
„abbrechen“. Danach sind die Inhaltsobjekte Name und Vorname, die immer angegeben werden
müssen, definiert. Bei der Rechnungsart gibt es die Möglichkeit, zwischen den Varianten
Kundenkonto und Visa zu wählen. Die Rechnung kann also über ein bereits eingerichtetes
Kundenkonto oder per VISA-Karte bezahlt werden. Beim Kundenkonto ist die Bezeichnung des
Kundenkontos anzugeben. Die Variante Kundenkonto besteht aus einer atomaren Variablen vom
Typ String. Bei der zweiten Variante, der Bezahlung per VISA, sind mehrere Angaben zu machen.
Deshalb wurde ein Record als Datentyp ausgewählt. Implementationsseitig liegt in den Business
Conversations hinter diesem Recordtyp ein namedContent, der aus genau einem Array besteht. Die
Felder müssen also, wie bei einer Inhaltsspezifikation üblich, in einer Arraynotation angegeben
werden. Jedes einzelne Feld kann wiederum jeden zulässigen Inhaltstyp haben. Es sind also auch
verschachtelte variante Strukturen möglich.
Auf einem varianten Inhaltsobjekt sind mehrere Funktionen definiert. Die erste Variante
(Kundenkonto) ist standardmäßig ausgewählt. Mit select(“VISA“) kann die VISA-Variante
ausgewählt werden. Mit selected() läßt sich der Name der gewählten Variante herausfinden, und
mit ref() kann auf das Inhaltsobjekt der gegenwärtig aktuellen Variante, also „VISA“ oder
„Kundenkonto“ zugegriffen werden. Das Ergebnis besteht entweder aus einem atomaren oder aus
einem komplexen Inhaltsobjekt. Die Zugriffsfunktionen auf diese Objekte werden im folgenden
näher erläutert.
Die zugehörigen Funktionen der anderen Datentypen sind ebenfalls in TBCContent.ti deklariert.
Des weiteren sind sie in der Abbildung 2.5 enthalten. Auf den Datentypen Cspec, Dialog, Int, Real,

34 4. Grundlagen und Anforderungen der Visualisierung
Date, String sind die Operationen set() und get() definiert. Sie dienen zum Setzen und Auslesen der
Werte. Bei Rcd und Variant kann auf die Inhaltsobjekte mit ref() zugegriffen werden.
Hervorzuheben ist hierbei, daß die Verschachtelung von Inhaltsobjekten möglich ist, wobei am
Ende der Verschachtelung immer atomare Datentypen stehen, auf die mit den o.g. Funktionen
zugegriffen werden kann. Bei den Datentypen zur Auswahl einer (singleChoice) oder mehrerer
(multipleChoice) Möglichkeiten liefert get() die derzeitige Auswahl und choose() wählt ein neues
bzw. zusätzliches Element aus. Mit discard() wird bei der Mehrfachauswahl die Markierung eines
Objektes zurückgesetzt. Die Funktion select() markiert eine oder mehrere Möglichkeiten als ausgewählt.
Die Funktionen zum Setzen und Auslesen der zugelassenen Auswahlmöglichkeiten sind
setChoices() und getChoices().
Bei Sequence, mit der ein Zugriff auf Massendaten realisiert werden kann, existieren die
Funktionen set() und get(), die Referenzen auf die Schnittstellen zu Massendaten setzen bzw.
auslesen.
Zusammenfassend ist festzustellen, daß Werte der atomaren Inhaltsobjekte geschrieben und
gelesen werden können. Die strukturell höherwertigen Objekte lassen sich in ihren Inhalten auf die
atomaren Objekte zurückverfolgen. Ergänzend kommen weitere Zugriffsfunktionen dazu.
4.4 Allgemeine Anforderungen
Der Entwickler soll bei der Gestaltung von HTML-Seiten die Möglichkeit haben, Standards der
Visualisierung und Benutzerführung, die sich im Internet etabliert haben, beizubehalten. Unter
anderem soll die Möglichkeit, eine Seite mit grafischen Informationen aufzuwerten, vorhanden
sein. Er soll die Chance haben, die in HTML vorhandenen Mittel weitestgehend auszunutzen, um
das Grundproblem, seine Vorstellungen möglichst direkt zum Ausdruck bringen zu können
[Ober87], mit hoher Effizienz zu lösen. Andere visuelle Hervorhebungen, die u.a. der
Benutzerführung dienen können, und Kommentartexte sollten hierzu realisierbar sein.
Um eine schnelle Akzeptanz des Systems zu erreichen und die Eingewöhnungsphase zu verkürzen,
wird eine einfache Bedienbarkeit des Systems angestrebt. Dafür soll der Benutzer seine
Navigationsgewohnheiten, wie z.B. die Benutzung der Zurück- (back) und Wiederherstellen-
Schaltflächen (reload) nicht aufgeben müssen. Die Visualisierung der Inhaltsobjekte und Anfragen
(requests) soll gängigen Fenstersystemen entsprechen.
Die Einbindung von Grafiken und anderen multimedialen Objekten in das Model der Business
Conversations ist zur Zeit noch nicht realisiert. Dennoch sollen derartige Objekte in der
Visualisierungkomponente nutzbar sein, um z.B. den Anforderungen von Benthien/Markus
[BM97], die für ihre Arbeit Grafiken benötigen, entgegenzukommen oder Formulare
benutzerfreundlicher gestalten zu können.
Um datenintensive Anwendungen bearbeiten zu können, muß die Funktionalität der grafischen
Benutzerschnittstelle (Graphical User Interface, GUI) dahingehend ausgerichtet werden, in großen
und komplexen Datenbeständen navigieren zu können und dem Benutzer die Möglichkeit geben,
seine definierte Auswahl anzuzeigen oder zu verändern. Die Daten können dabei sowohl atomare
Objekte als auch höhere Strukturen oder sogar komplexe Multimediaobjekte sein.

4.5. Synchrone und asynchrone Verbindungen 35
4.5 Synchrone und asynchrone Verbindungen
Bei der Kommunikation wird zwischen synchroner und asynchroner Kommunikation
unterschieden [Mass91]. Zur asynchronen Kommunikation gehört u.a. der elektronische
Nachrichtenaustausch. Telefongespräche und Videokonferenzen sind der synchronen
Kommunikation zuzurechnen. Um flexibel zu sein, ist es das Ziel der Arbeit sowohl synchrone als
auch asynchrone Kommunikationsverbindungen zu unterstützen.
Asynchrone Kommunikation findet im Agentensystem bei der Verständigung zweier Menschen
statt, wenn eine sofortige Antwort nicht notwendig ist oder mindestens ein Kommunikationspartner
Zeit zum Antworten braucht. Sie kann in Mensch-Maschine Verbindungen auftreten, wenn die
Antwortzeit der Maschine zu lang ist. Da der jeweilige Kommunikationspartner in der
Zwischenzeit weiterarbeiten können soll, ist eine Übersicht über den derzeitigen Stand der
Konversation sinnvoll, um nach einer Unterbrechung der Kommunikation wieder auf die
Konversation zugreifen zu können. In dieser Übersicht muß eine Information enthalten sein,
welcher Kommunikationspartner zur Zeit den aktiven Part hat. Um einen schnellen Zugang zu den
momentan zu bearbeitenden (aktiven) Dialogen zu haben, ist die Übersicht mit einem direkten
Zugang in die aktiven Dialoge zu versehen.
Die synchronen Verbindungen sind sinnvoll, wenn der Anwender mit einer Gegenstelle
kommuniziert, die Antworten schnell genug generieren kann. Unterbricht der Benutzer die
Kommunikation, indem er während der Bearbeitungszeit des Kommunikationspartners einer
anderen Arbeit nachgeht, so wird aus der synchronen eine asynchrone Kommunikation. Soll die
Kommunikation später synchron weitergeführt werden, muß die Visualisierungskomponente auch
diesen Wechsel unterstützen.
4.6 Funktionalität des Agentensystems
Um das Konzept der Agenten durch die Visualisierung nicht zu beschränken, ist die Migration von
Agenten auch weiterhin über Rechnergrenzen hinweg zu ermöglichen.
Der Nachrichtenaustausch der Agenten untereinander soll weiterhin über die ITCs abgewickelt
werden. Er darf deshalb durch die Visualisierung nicht beeinflußt werden.
Die Visualisierung darf ferner keinen der drei Agententhreads blockieren. Eine derartige Blockade
hätte zur Folge, daß während der Visualisierung entweder keine Nachrichten mehr angenommen
werden könnten, oder daß ankommende Nachrichten nicht mehr verarbeitet würden. Beides hätte
zur Folge, daß die Fähigkeit des Agenten, beliebig viele Konversationen auf einmal zu führen,
stark eingeschränkt würde.
Um dem Benutzer einen Überblick über alle aktiven Konversationen zu geben, muß der aktuelle
Status jeder Konversation visualisierbar sein. Dies aber wird derzeit, wie in Abschnitt 3.4
geschildert, durch das Agentensystem nicht unterstützt. Deshalb ist es erforderlich, daß durch das
Visualisierungssystem eine geeignete Funktionalität zur Verfügung gestellt wird.

36 4. Grundlagen und Anforderungen der Visualisierung
4.7 Dynamische Visualisierung
Bei der Visualisierung ist zwischen dem statischem und dem dynamischen Ansatz zu unterscheiden
[Mues94]. Beim statischen Ansatz wird die Visualisierung durch den Entwickler vorweggenommen.
Beim dynamischen Ansatz dagegen erfolgt die Visualisierung während der Laufzeit
des Programms.
Die statische Visualisierung gliedert sich in die interaktive Erzeugung der Darstellung, bei der
Komponenten aus einem Editor ausgewählt werden und die Bibliotheksaufrufe, die bereits
vorhandene Funktionen benutzen [Mues94].
Bei der dynamischen Visualisierung, bei der die Visualisierungsobjekte generisch erzeugt werden,
tritt das Problem auf, daß die Semantik von Objekten nicht modelliert werden kann. Wird z.B.
durch das zugrundeliegende TBC-System ein boolscher Wert nicht unterstützt, so kann er u.a.
durch eine Zeichenkette oder einen Zahlenwert abgebildet werden. Die Darstellung des Objektes
sollte aber aus Gründen der Benutzerführung wieder als boolscher Wert, der nur zwei Zustände
annehmen kann, erfolgen. Ein anderes Beispiel bildet ein Textfeld, das entweder zur Ein- und
Ausgabe von Werten oder nur als Kommentar dient. Bei der statischen Visualisierung kann der
Programmierer infolge seiner Kenntnisse anstelle der typspezifischen Visualisierung auch eine
andere wählen. Die Abspeicherung semantischen Wissens zur dynamischen Modellierung ist im
TBC-System nicht vorgesehen. Es muß also eine Möglichkeit zur Verwaltung semantischen
Wissens geschaffen werden, weil sonst nur typspezifische Darstellungen der Daten und nicht die
semantisch sinnvolleren Darstellungen erzeugt werden können.
Ansatz Erzeugung Datendarstellung
interaktiv
statisch
beliebig
Bibliotheksaufrufe
typspezifisch
dynamisch
generiert
Abbildung 4.1: Ansätze zur Datenvisualisierung
Gerade bei der Visualisierung von varianten oder datenintensiven Strukturen ist es sehr aufwendig,
wenn nicht gar unmöglich, die Darstellung aller möglichen Inhalte im voraus zu programmieren.
Eine dynamische Visualisierung ist deshalb nicht nur in diesen Fällen der statischen Visualisierung
überlegen.

4.7. Dynamische Visualisierung 37
Auch wenn nicht alle Spezifikationen der Dialoge von vornherein bekannt sind, was beispielsweise
bei der in Abschnitt 2.3.4 geschilderten Verwendung des ellipses-Attributes der Fall ist, muß auf
generische Dienste ausgewichen werden, weil eine Visualisierung sonst nicht stattfinden kann.
Entwickler schätzen den Anteil der graphischen Benutzeroberfläche am Programmkode auf ca.
60% [Wege95]. Eine entsprechende dynamische Lösung hätte gegenüber einer statischen die
Vorteile, sie nur einmal erarbeiten zu müssen. Der mit ihrer Erstellung verbundene wesentlich
höhere Arbeitsaufwand entsteht unter anderem durch die hohen Anforderungen an Effizienz und
Fehlerunanfälligkeit. Eine dynamische Lösung bietet sich nach allem um so mehr an, je öfter neue
Business Conversations spezifiziert werden.
Die Anwendung einer dynamischen Lösung ist weiterhin vorteilhaft, weil sich dadurch der zur
Visualisierung eines Wertes notwendige Programmkode auf den Aufruf einer generischen, also auf
Werte verschiedenen Typs anwendbaren Funktion reduziert [CW85]. Brown [Brow88] stellt fest,
daß die Generierung der Bildschirmrepräsentation umso weniger automatisch erfolgen kann, je
abstrakter, umfassender der Inhalt der zu visualisierenden Daten ist. Die Bedeutung dieser Aussage
wird durch die Ausführungen in Abschnitt 6.2 über flexible Visualisierungsrichtlinien für die in
den TBCs definierbaren komplexen Datentypen aufgezeigt.
Um zu klären, ob eine dynamische Visualisierung mit den TBCs realisierbar ist, müssen die
Datenstrukturen und die auf ihnen definierten Funktionen der TBCs näher analysiert werden.
4.7.1 Dialogobjekte
Um die Visualisierung dynamisch realisieren zu können, müssen der Typ und der Name jedes
Inhaltsfeldes sowie der Name jeder im Dialog enthaltenen Anfrage analysiert werden. Diese
Informationen sind den jeweiligen Spezifikationen zu entnehmen.
Tycoon ist eine statisch typisierte Programmiersprache, in der zur Laufzeit keine Typinformationen
mehr vorhanden sind, die es ermöglichen, die Struktur eines Wertes zu bestimmen und die
entsprechende Bildschirmrepräsentation zu generieren. Deshalb war bisher die typsichere
generische Visualisierung allein auf der Basis von Tycoon nicht erreichbar. Durch das System der
Business Conversations ist es nun jedoch möglich, den Typ eines jeden Inhaltsobjektes
festzustellen und damit generisch auszuwerten. Es bleibt aber zu prüfen, ob die für eine
dynamische Visualisierung notwendigen Funktionen im TBC-System zur Verfügung stehen.
Aus den o.g. Gründen ist es notwendig, die Spezifikationen der Dialoge zu analysieren. Eine
Analysemöglichkeit besteht darin, sich der Spezifikation der zugehörigen Konversation zu
bedienen. Da beim Kunden, bedingt durch das ellipses Attribut, nicht alle Dialoge einer
Konversation spezifiziert sein müssen, reicht diese Möglichkeit nicht aus, alle
Dialogspezifikationen zu untersuchen. Es ist deshalb notwendig, innerhalb einer Regel direkt auf
die Spezifikation des Dialoges zuzugreifen, die dieser immer mit sich führt. Der Vollständigkeit
halber soll vorher noch das Verfahren erörtert werden, mit dem auf die Inhalte der
Konversationsspezifikation zugegriffen werden kann. Für die nachfolgenden Erklärungen wird die
Dialogspezifikation kreditDatenDialogSpec aus der Konversationsspezifikation kreditConvSpec in
Abschnitt C.1 zugrunde gelegt.

38 4. Grundlagen und Anforderungen der Visualisierung
Bei einer Konversationsspezifikation mit dem Namen kreditConvSpec liefert die Funktion
kreditConvSpec.dialogSpecs() eine Iteration vom Typ iter.T(tbcSpec.DialogSpec), die Zugriff auf
die Spezifikation der gesamten Konversation bietet. Mit iter.size(kreditConvSpec .dialogSpecs())
läßt sich die Anzahl der in dieser Konversationsspezifikation enthaltenen Dialoge feststellen.
Auf den ersten Dialog kann mit kreditConvSpec.dialogSpecs().get() zugegriffen werden. Das
Ergebnis ist die Spezifikation des ersten Dialogs und hat den Typ tbcSpec.DialogSpec. Der zweite
Dialog ist mit kreditConvSpec.dialogSpecs().rest().get() erreichbar. Durch rekursive Anwendung
der Funktionen rest() und get() lassen sich alle weiteren Dialogspezifikationen auswählen.
Um sich innerhalb einer Regel auf die Spezifikation eines Dialoges zuzugreifen, muß jedoch etwas
anders verfahren werden. Beim Aufruf einer Regel durch das Agentensystem wird eine Variable
conv übergeben, die den Typ agent.Conversation hat. Die Definition dieses Typs ist in Abschnitt
C.4 enthalten. Über die Variable c, welche die Spezifikation der Konversation repräsentiert und mit
Hilfe der Funktion conv.c.currentDialog(), kann auf den aktuellen Dialog zugegriffen werden. Das
Ergebnis ist vom Typ tbConv.Dialog, dessen Definition in Abschnitt C.5 enthalten ist. Diese
Möglichkeit wird in fast jeder Regel genutzt, um sich der aktuellen Werte bedienen zu können.

4.7. Dynamische Visualisierung 39
name :String
TBCSpec
dialogSpecs() :iter.T(DialogSpec)
initialDialogSpec() :DialogSpec
spec
s :S
TBConv(S)
spec() :tbcSpec.T
saveDialog(...) :Ok
copy HistoryDialog(...) :Dialog
newDialog(...) :Dialog
currentDialog() :Dialog
initialDialogSpec
dialogSpecs
currentDialog
name :String
DialogSpec
possibleRequests() :iter.T(RequestSpec)
contentSpec() :tbcContent.Spec
spec
Dialog
spec() :tbcSpec.DialogSpec
content() :tbcContent.T
content1(...) :tbcContent.T
possibleReplies
possibleRequests
name :String
ellipses :Bool
RequestSpec
possibleReplies() :iter.T(String)
content
content1
Request
ContentSpecElement
ContentElement
contentSpec
elements
ref
TBCContentSpec
TBCContent
elements() :iter.T(NamedContentSpec)
spec
spec() :tbcContent.Spec
ref(name :String) :T
Abbildung 4.2: Objektstrukturmodell zum Zugriff auf Dialogobjekte
Über conv.c.currentDialog().spec() kann jetzt die Dialogspezifikation erreicht werden. Sie ist vom
Typ tbcSpec.DialogSpec. Damit sind hier die gleichen Möglichkeiten vorhanden wie auch beim
Zugriff über die Konversationsspezifikation. Die im folgenden beschriebenen Zugriffsverfahren
gelten also für beide Möglichkeiten. Das so erhaltene Ergebnis ist in Abschnitt C.7 aufgezeigt.

40 4. Grundlagen und Anforderungen der Visualisierung
Der Funktionsaufruf conv.c.currentDialog().spec() ist im folgenden mit d abgekürzt. Den
Dialognamen erhält man dann mit d.name.
4.7.2 Anfragen
Um die Namen der Anfragen (requests) eines Dialoges zu erhalten, kann die Dialogspezifikation
benutzt werden. Die Namen der Anfragen sind in der Dialogspezifikation in den possibleRequests,
einer Struktur vom Typ Iter enthalten.
Mit d.possibleRequests() erhält man Zugriff auf diese Struktur. Die Anzahl der Anfragen des
aktuellen Dialoges läßt sich mit iter.size(d.possibleRequests()) herausfinden. Die Funktion
d.possibleRequests().get() liefert die erste Anfrage und d.possibleRequests().get().name den Namen
dieser Anfrage. Weitere Informationen zu einer Anfrage werden zur Visualisierung nicht benötigt.
Mit d.possibleRequests().rest().get().name bekommt man den Namen der zweiten Anfrage. Durch
rekursive Anwendung der rest()-Funktion können alle weiteren Anfragen erreicht werden.
Zusätzlich läßt sich mit der Funktion tbConv.isFinalDialog() noch überprüfen, ob es sich hier um
einen finalen Dialog handelt, der keine Anfragen enthält.
4.7.3 Inhaltsobjekte
Um die einzelnen Inhaltsobjekte eines Dialoges zu bekommen, kann ebenfalls auf die
Dialogspezifikation zugegriffen werden. Die Funktion d.contentSpec() liefert die Spezifikation der
Struktur des Dialogs. In der Struktur sind die einzelnen Inhaltsobjekte enthalten. Die
Abspeicherung der Inhaltsobjekte der Spezifikation eines Dialoges (TBCContentSpec) als
Ausprägung rcd eines varianten Tupels vom Typ Spec ist durch das Agentensystem festgelegt. In
Abschnitt C.8 findet sich die Definition.
Da es sich hierbei um variante Tupel handelt, muß die !-Notation verwendet werden. Das erste
Inhaltsobjekt wird durch d.contentSpec()!rcd.elements().get() geliefert. Die weiteren Elemente
lassen sich wieder mit der rest()-Funktion auslesen.
Der Name des ersten Elements ist das Ergebnis von d.contentSpec()!rcd.elements().get() .name.
Dieser wird benötigt, um mit der Funktion content1(name), die in TBConv.ti definiert ist, auf den
Inhalt der Variablen zuzugreifen.
Die Spezifikation des Elements bekommt man mit d.contentSpec()!rcd.elements().get().spec(). Aus
ihr ist zwar der Typ des Elements erkennbar, dieser alleine ist jedoch wenig nützlich.
Die ?-Notation symbolisiert bei varianten Tupeln einen Test, der als Ergebnis entweder einen
boolschen Wert liefert oder eine Ausnahme auslöst, wenn es sich um einen unbekannten Typ
handelt. Mit d.contentSpec()!rcd.elements().get().spec()?int steht eine Möglichkeit zur Verfügung,
um festzustellen, ob der Typ der Variablen Int ist. Weitere Funktionen für die anderen Datentypen
sind vorhanden. Ansatzweise ist die notwendige Programmierung in Abschnitt C.8 enthalten. Weil
es in den Business Conversations nur eine geringe Anzahl von Typen gibt, ist der Aufwand, den
Typ des Inhaltsobjekts herauszufinden, nicht besonders groß.

4.8. Visualisierungsvorlagen 41
Handelt es sich beim Inhaltsobjekt um ein atomares Objekt, ist keine weitere Aktion erforderlich.
Für verschachtelte Inhaltsobjekte existieren Möglichkeiten, auf die darin enthaltenen Unterobjekte
zuzugreifen. In MultipleChoice- und SingleChoice-Objekten ist über die Funktion getChoices()
eine Iteration der Unterobjekte erhältlich. Beim Datentyp Sequence liefert die Funktion elements()
eine derartige Iteration. In diesen Iterationen lassen sich mit den o.g. Funktionen die darin
enthaltenen Unterobjekte auswählen.
Bei den Datentypen Variant und Rcd ist es möglich über eine NamedContentSpec und die dafür
definierte Funktion spec() auf die TBCContentSpec der Unterobjekte zuzugreifen. Mit den o.g.
Funktionen kann danach auf die Inhalte der Unterobjekte zugegriffen werden. Bei Inhaltsobjekten
vom Typ Dialog oder Cspec ist der Zugriff über die in Abschnitt 4.7.1 genannten Methoden
möglich.
Abschließend läßt sich sagen, daß die für eine dynamische Visualisierung notwendigen
Zugriffsfunktionen zur Verfügung stehen, solange die Spezifikation vorhanden ist. Ist die
Spezifikation nicht vorhanden, so besteht innerhalb einer Regel keine Möglichkeit, auf eine
Anfrage oder ein Inhaltsobjekt zuzugreifen, dessen Name nicht bekannt ist. Da die Dialoge
aufgrund einer Spezifikation generiert werden und die Spezifikation im Konversationsobjekt
mitgeführt wird, stellt die Notwendigkeit der Spezifikation keine Einschränkung der Funktionalität
dar.
4.8 Visualisierungsvorlagen
Bei einer statischen Visualisierung (siehe Abschnitt 4.7) kann die Erscheinungsform jedes Dialoges
mit seiner Feldanordnung, den Kommentaren, weiterführenden Links, Grafiken, multimedialen
Elementen und Attributen von vornherein festgelegt werden. Bei der dynamischen Visualisierung
der Tycoon Business Conversations fehlt eine solche Möglichkeit, weil sie im Konzept der TBCs
nicht vorgesehen ist. Es würden nur Felder mit ihren Namen und Inhalten dargestellt werden
können, auf semantische Informationen würde jedoch nicht zugegriffen werden.
Ein Beispiel für semantisches Wissen ist die Darstellung von Grafiken. Sie lassen sich auf einer
HTML-Seite durch Verweise darstellen. Da multimediale Datentypen im TBC-System noch nicht
vorhanden sind, könnte für die Verweise der Datentyp String benutzt werden. Ohne Wissen über
die Interpretation eines Feldes würde es dann als Textfeld dargestellt werden, weil bei der
dynamischen Visualisierung ohne semantisches Wissen nur typspezifische Darstellungen erzeugt
werden können (siehe Abbildung 4.1). Das notwendige semantische Wissen, einen Feldinhalt als
Verweis und nicht als Text zu interpretieren, ist in den TBCs nicht darstellbar. Da es nicht
ausreicht, ein leistungsfähiges Visualisierungssystem zu erstellen, ohne gleichzeitig eine
erfolgreiche Mensch-Maschine-Kommunikation zu schaffen, muß auch semantisches Wissen in
eine derartige Entwicklung mit einbezogen werden. Dieses war bei den meisten frühen
Visualisierungssystemen nicht der Fall [MHHB88].
Aus dieser Problemstellung ergibt sich die Notwendigkeit, für den dynamischen Ansatz zusätzliche
Informationen zur Visualisierung zur Verfügung zu stellen. Mit den Visualisierungsvorlagen wird
eine Lösung für die personalisierte Darstellung der Dialoge von Konversationen vorgestellt.

42 4. Grundlagen und Anforderungen der Visualisierung
HTML-Dialog
Kundenvorlage
Kunde
Szenarienvorlage
Szenario
Kunde
Dialogvorlage
Dienstleister
Dialog
Objekt
Standard-
Visualisierung
eines Objektes
Konversations-
Spezifkation
Abbildung 4.3: Struktur der Visualisierungsvorlagen
Die Visualisierungsvorlagen sind dazu gedacht, dem Dienstleister durch Standards zu einer
schnelleren Entwicklung zu verhelfen. Er kann einmal festgelegte Darstellungen wiederverwenden.
Ihm wird darüberhinaus die Möglichkeit gegeben, dynamisch erstellte Visualisierungen mit seinem
eigenen Layout zu versehen. So kann er u.a. Objekte gruppieren, um Platz zu sparen oder
Kommentare und Hervorhebungen einfügen, um Aufmerksamkeit zu erregen. Die Vorlagen sollen
außerdem dem einzelnen Kunden die Möglichkeit geben, die Darstellung der Dialoge seines
Agenten den eigenen Anforderungen anzupassen und damit eine benutzerdefinierte Oberfläche zu
ermöglichen. Die Visualisierungsvorlagen sind als Stilrichtlinien (style guides) zu verstehen, die
eine Vermischung dynamischer und statischer Visualisierung ermöglichen.
Für diese Zwecke wird das Modell der Visualisierungsvorlagen in zwei Teile aufgegliedert. Der
Teil, der die Standards setzt, wird beim Dienstleister angesiedelt. Der andere Teil, die
benutzerspezifische Visualisierung, wird dem Kunden zugeordnet.

4.8. Visualisierungsvorlagen 43
Um darzustellen, welche Überlegungen die Grundlage des Implementationsmodelles bilden,
auftretende Probleme bewußt zu machen und Lösungen anzubieten, müssen die einzelnen
Darstellungsebenen, die letztendlich zur Visualisierung des Dialoges führen, näher betrachtet
werden.
4.8.1 Dienstleisterseite
Ein Dialog ist immer genau einer Konversationsspezifikation zugeordnet. Eine Konversationsspezifikation
besteht normalerweise aus mehreren Dialogen. In den Dialogen kommen
Inhaltsfelder und Aktionen vor, die, basierend auf ihrem Typ, die in Kapitel 6 geschilderte
Standarddarstellung besitzen. Jedes der Objekte, wie z.B. ein Feld für den Nachnamen, kann in
mehreren Dialogen einer Konversation vorkommen.
Um dieselben Objekte innerhalb einer Konversation immer gleich darstellen zu können, ist es
notwendig, jedem Objekt eine eindeutige Objektidentität zuzuweisen. Würde man diese dem Tupel
(Feldname, Dialogname) zuweisen, so ist keine dialogübergreifende Visualisierung möglich, da
durch die Invarianten, die in Abschnitt 2.4 erklärt wurden, jedes Objekt in dieser Kombination nur
einmal vorkommen darf. Deshalb ist es sinnvoll, die Objektidentität einem Paar (Feldname, Typ)
zuzuteilen. Dadurch muß Abschnitt 2.4 um eine Invariante erweitert werden, die besagt, daß ein
Paar (Feldname, Typ) in allen Dialogen einer Konversation immer die gleiche Bedeutung hat.
Die so erreichte Objektidentität ermöglicht die Abspeicherung einer Standardvisualisierung für ein
Objekt. Die Standardvisualisierung des Objektes umfaßt nicht nur die Festlegung der Darstellung
eines Objektes als Kombinationsfeld, Optionsgruppe, Textfeld oder Kommentarfeld, sondern auch
Attribute wie den Namen, die Größe, Schriftart, -ausrichtung und -auszeichnung, Farbe,
Standardwert, Schreibschutz und Sichtbarkeit [W3C97].
Für jeden Dialog, der einer HTML-Seite entspricht, kann eine spezielle Visualisierung festgelegt
werden. Dadurch können in jedem Dialog die Feldreihenfolge festgelegt, Attribute hinzugefügt und
Hilfen zur Benutzerführung, wie etwa Kommentare und graphische Auszeichnungen angeboten
werden. Bei der Visualisierung einzelner Objekte werden die vorgegebenen Standards benutzt,
sofern in der Dialogvorlage diese Einstellungen nicht überschrieben wurden. Ist für einen Dialog
keine Dialogvorlage vorhanden, können die Objekte in der Reihenfolge visualisiert werden, die in
der Konversationsspezifikation angegeben ist. Hierbei sollten die o.g. Standards für die einzelnen
Objekte beachtet werden.
4.8.2 Kundenseite
Auf der Kundenseite kann jeder Kunde für jeden Dialog seine eigene benutzerbezogene
Visualisierung einstellen. Hierbei kann es sich z.B. um eine besonders große Schrift oder
Tonausgabe handeln.
Außerdem können für jeden Kunden verschiedene Szenarien existieren. Die Szenarien können auch
von mehreren Kunden wie der Abteilung einer Firma, gemeinsam benutzt werden. Ein Szenario
kann u.a. die Verbindung über ein lokales Netzwerk definieren, während ein anderes die
Verbindung über ein Modem beinhaltet, bei der keine multimedialen Daten übertragen werden

44 4. Grundlagen und Anforderungen der Visualisierung
sollen. Das ist gerade bei der zunehmenden Bedeutung der Heimarbeit ein wichtiger Aspekt. Aber
auch verschiedene Browserversionen mit ihren installierten Plugins können durch Szenarien
repräsentiert werden.
Da sich nicht immer automatisch feststellen läßt, mit welcher Konfiguration der Benutzer gerade
arbeitet, muß es für den Benutzer bei der Anmeldung an seinen Stellvertreter, den Agenten, eine
Möglichkeit geben, das gewünschte Szenario einzustellen. Diese Möglichkeit kann beispielsweise
in der Anmeldung integriert sein oder extra abgefragt werden.
4.8.3 Erstellung der Vorlagen
Die Erzeugung der Vorlagen kann u.a. durch statische Programmierung der festzulegenden
Eigenschaften oder mit Seitenerstellungstools wie Frontpage, Dreamweaver, Net Dynamics bzw.
Hot Dog stattfinden. Bei den Seitenerstellungstools ist darauf zu achten, daß nur standardisierter
HTML-Code erzeugt wird. Dieses ist z.B. bei Frontpage, obwohl es auf der Microsoft Windows
Basis zu den besten Programmen für die Erstellung von HTML-Seiten gehört [EBB97], häufig und
gerade wenn Formularfelder genutzt werden, nicht der Fall. Nach der Erstellung kann die Seite
analysiert werden, um, wie Ripp [Ripp98] es vorschlägt, daraus die Konversationsspezifikation zu
entwerfen. Für das Auswerten einer so entwickelten HTML-Seite ist die in Abschnitt 5.1
beschriebene Änderung erforderlich, weil die Objektnamen einer HTML-Seite bei den Tycoon
Business Objects, die in Abschnitt 5 erläutert werden, dynamisch festgelegt werden und die
Verwendung von statischen Namen zur Zeit nicht unterstützt wird.

4.8. Visualisierungsvorlagen 45
4.8.4 Abspeicherung der Vorlagen
Die Visualisierungsvorlagen lassen sich an verschiedenen Stellen speichern.
• Direkt in den Dialogen
• In einer Datenstruktur innerhalb des Agenten
• In einer externen Datenbank
• In einem neuen Agenten
Bei der Speicherung in den Dialogen muß die generelle Spezifikation der Dialoge um einen
entsprechenden Eintrag erweitert werden. Dieses ist jedoch ein tiefer Eingriff in das TBC-System
und deshalb nicht zu favorisieren. Es kann auch in der Konversationsspezifikation für jede
Dialogspezifikation ein zusätzliches Feld eingefügt werden, welches die notwendigen
Informationen enthält. Doch dieses Feld müßte dann zu jeder Dialogspezifikation vorhanden sein
und würde damit das Erstellen der Konversationsspezifikation erschweren. Außerdem würden die
so abgespeicherten Informationen den Speicherbedarf des Agenten, der ja mehrere Konversationen
gleichzeitig führen kann, erhöhen. Die Informationen müßten zudem bei jeder Migration des
Agenten mitgenommen werden.
Ebenso verhält es sich mit der Speicherung in einer extra anzulegenden Datenstruktur im Agenten.
Der Vorteil einer Speicherung im Agenten selber ist der schnelle Zugriff. Die Informationen stehen
sofort zur Verfügung und verursachen keine Performanceeinbußen durch sekundäre
Konversationen, wie es bei der nächsten Möglichkeit der Fall ist. Aber die Erhöhung des
Speicherbedarfs steht dem Ziel, möglichst kleine Agenten zu erzeugen, entgegen. Bei wenigen
Dialogen in einer Konversation wird die Größe des Agenten, ein kleiner Agent ist ca. 70 KB groß,
nicht wesentlich erhöht. Da die Anforderungen an das System aber vorsehen, komplexe
Agentensysteme entwickeln zu können, scheidet auch diese Möglichkeit aus.
Die dritte Möglichkeit ist die Speicherung in einer externen Datenbank. Für den Zugriff auf diesen
Datenbestand kann z.B. der Datentyp sequence verwendet werden. Diese Datenbank müßte an
einem festen Ort vorhanden sein, damit die Zugriffsmöglichkeit gewährleistet ist.
Die besten Voraussetzungen schafft die Ablage der Informationen in einem nur dafür zuständigen
Agenten. Die Agenten werden in Tycoon, einem persistenten System, erstellt. Die Vorteile dieser
Lösung sind, daß die Funktionen des sequence Datentyps nicht extra erstellt werden müssen und
die Kommunikation mit diesem Agenten durch sekundäre Konversationen erfolgen kann.
Außerdem kann der Vorlagenagent auf einfache Art und Weise mit Regeln versehen werden. So
kann er z.B. benötigte aber nicht vorhandene Informationen aufgrund der implementierten Regeln
selbstständig besorgen. Dadurch wird ein in sich geschlossenes Konzept erreicht. Zudem ist bei
Bedarf eine Migration möglich. Wegen dieser Vorteile ist diese Möglichkeit der Speicherung in
einer externen Datenbank und den anderen Möglichkeiten vorzuziehen.
Bei der Abspeicherung der Vorlagen ist zwischen der Kunden- und der Dienstleisterseite zu
unterscheiden. Die Kundenvorlagen können im Netz an einer beliebigen Stelle liegen. Nur dem

46 4. Grundlagen und Anforderungen der Visualisierung
Stellvertreteragenten des Kunden muß bekannt sein, wo sie zu finden sind. Die Migrationsfähigkeit
des Stellvertreters wird hierdurch nicht eingeschränkt.
Die Visualisierungsvorlagen des Dienstleisters gliedern sich in zwei Teile. Ein Teil wird für die
eigene Visualisierung der Dialoge benötigt. Die Abspeicherung kann analog zu den
Kundenvorlagen erfolgen. Der zweite Teil besteht aus den Dialogvorlagen, in denen die
Informationen für die Kunden abgespeichert werden. Da ein Dienstleister zur gleichen Zeit auch
Kunde sein kann, bietet es sich an, alle ihn selber betreffenden Visualisierungsinformationen in
einem Vorlagenagenten zu speichern. Auf diese Weise wird ein einheitlicher Aufbau für die
Visualisierung geschaffen, der von der jeweiligen Rolle, Kunde oder Dienstleister, abstrahiert. Der
Dienstleister- und der Kundenvorlagen-Agent werden im folgenden, soweit nicht ausdrücklich
zwischen ihnen unterschieden werden muß, beide als Vorlagenagenten bezeichnet.
Kunden
Agent
Kunden-
vorlagen-
Agent
Dialog-
vorlagen-
Agent
Dienstleister
Agent
Dienstleister-
vorlagen-
Agent
Abbildung 4.4: Informationsfluß zur Visualisierung
In den Dialogvorlagen, die der Dienstleister für andere zur Verfügung stellt, können auch
Informationen enthalten sein, welche die Kunden nicht ändern dürfen. Um diese Informationen
entsprechend schützen zu können, sollten die Vorlagen mit diesen Informationen an einem
absicherbaren Ort abgespeichert und mit den entsprechenden Sicherheitsmaßnahmen abgeschirmt
werden. Hierdurch wird die Migrationsfähigkeit des Dienstleisters nicht beeinträchtigt, weil die
Vorlagen im Vorlagenagenten am Ort verbleiben können. Die Implementierung eines
Rollenmodells in die Visualisierungsvorlagen ist zwar theoretisch möglich, für das Modell der BCs
aber nicht notwendig, weil schon durch die Aufnahme der Konversation und Angabe der
Konversationsspezifikation jedem Teilnehmer eine definierte Rolle zugewiesen wird.
Prinzipiell können alle Visualisierungsvorlagen, die zu einer Konversation gehören, in einem
Vorlagenagenten gespeichert werden. Der Zugriff auf diese Informationsmenge ist aber schwer
abzusichern, und die ganze Kommunikation liefe über diesen einen Agenten, so daß, gerade bei
vielen Konversationen oder Konversationen mit vielen Dialogen Leistungseinbußen auftreten
werden. Deshalb ist es sinnvoll, die Vorlagen für den Kunden und den Dienstleister in getrennten
Agenten abzuspeichern. Da die Dialogvorlagen an einer abgesicherten Stelle gespeichert werden
müssen, ist zu prüfen, welche Vor- und Nachteile durch eine gesonderte Speicherung der Kunden-,
Dienstleister- und Dialogvorlagen entstehen.

4.8. Visualisierungsvorlagen 47
4.8.5 Aufruf der Vorlagen
Der Nachteil einer getrennten Speicherung besteht darin, daß für die Visualisierung jedes Dialoges
auf den Agenten, der die Dialogvorlagen verwaltet (Dialogvorlagenagent), mit einer sekundären
Konversation zugegriffen werden muß. Dieses läßt sich nur umgehen, indem alle für eine
Konversation relevanten Visualisierungsinformationen im Vorlagenagenten gespeichert werden.
Dafür muß sichergestellt werden, daß die Vorlagenagenten des Kunden und Dienstleisters durch
den Agenten, der die Dialogvorlagen verwaltet, von Änderungen, die gerade bei lang andauernden
Konversationen auftreten können, informiert werden. Da die Informationen nur für die Agenten
interessant sind, zwischen denen gerade eine Konversation dieses Typs geführt wird, läßt sich
dieses über eine Verwaltung der Konversationen im Dialogvorlagen-Agenten realisieren. Hierbei
tritt das in Abschnitt 3.4 geschilderte Problem auf, daß diese Verwaltung durch das Agentensystem
nicht unterstützt wird. Eine Lösung für die Verwaltung von Konversationen wird deshalb in
Abschnitt 7.1 beschrieben.
Um die Dialoge darstellen zu können, kann der Vorlagenagent beim Beginn einer Konversation
alle erforderlichen Visualisierungdaten bekommen. Für die Anforderung und Übertragung der
Daten vom Dialogvorlagen-Agenten können sekundäre Konversationen genutzt werden. Der
Stellvertreteragent kann die im Vorlagenagenten gespeicherten Informationen zur Visualisierung
der Dialoge benutzen.
Um die gespeicherte Datenmenge des Vorlagenagenten klein zu halten, müssen die
Visualisierungsinformationen am Ende der Konversation gelöscht werden. Dazu ist es erforderlich,
daß der Stellvertreteragent seinen Vorlagenagenten in der Regel des finalen Dialoges vom Ende der
Konversation unterrichtet. Danach muß der Vorlagen-Agent den Dialogvorlagen-Agenten
benachrichtigen, daß er keine weiteren aktuellen Visualisierungsinformationen für die beendete
Konversation benötigt und die Visualisierungsinformationen, die er vom Dialogvorlagen-Agenten
bekommen hatte, löschen. Zusammen mit den Änderungsinformationen des Dialogvorlagen-
Agenten während der Konversation wird so sichergestellt, daß stets die aktuellen
Visualisierungsinformationen vorhanden sind und der gespeicherte Datenumfang der Agenten nicht
unnötig zunimmt.
In Verbindung mit der Entwicklung von Cascading Style Sheets (CSS) [W3C97, Münz97b], ist zu
untersuchen, ob Teile der Visualisierungsvorlagen in der HTML-Seite als Style Sheets
abgespeichert werden können. CSS beschreiben, wie Dokumente am Bildschirm oder auf
Ausdrucken dargestellt werden [W3C98]. Die Nutzung von Cascading Style Sheets setzt allerdings
voraus, daß alle Anwender neuere HTTP-Clients benutzen. Die derzeitigen HTTP-Clients haben
den Standard noch nicht voll implementiert [Hüsk97b]. Außerdem lassen sich nicht alle
Visualisierungsinformationen in die Style Sheets einbinden. Unter anderem sind die Überlegungen
zur Standardisierung der Positionierung von Grafiken noch nicht abgeschlossen [Hüsk97b].
Außerdem fehlt die Möglichkeit, die Reihenfolge von Objekten festzulegen. Zur Zeit sind die Style
Sheets in ihrer Funktionalität auf die reine Optik beschränkt [Münz97c]. Aus diesen Gründen
können die CSS zwar in das Visualisierungskonzept eingebunden werden, reichen aber für die notwendige
Funktionalität nicht aus.
Die Angabe der Rollen der an einer Konversation beteiligten Agenten läßt nicht erkennen, wer die
Dialogvorlagen letztendlich erstellt hat. Dieses kann auch durch eine dritte Person geschehen sein.
Es ist außerdem zu berücksichtigen, daß nicht nur eine, sondern mehrere Konversationen gleichen

48 4. Grundlagen und Anforderungen der Visualisierung
Typs zur gleichen Zeit geführt werden können. Wenn beispielsweise mehrere Kunden zur gleichen
Zeit an die Kreditabteilung einer Bank herantreten, um einen Kredit zu beantragen. Ebenso könnten
mehrere Kunden gleichzeitig in einem virtuellen Kaufhaus einkaufen.
Bei der dynamischen Visualisierung muß jeder Agent selber die entsprechenden Informationen
abfragen. Es werden mit dem Dialog keine Visualisierungsinformationen mitgeschickt, weil ein
derartiges Vorgehen konzeptuelle Änderungen am Agentensystem zur Folge hätte.
Bevor es letztendlich zur Visualisierung kommt, sind zwei sekundäre Konversationen notwendig.
In der ersten befragt der jeweilige Kunden- oder Dienstleisteragent seinen Vorlagen-Agenten nach
Visualisierungsinformationen. In der zweiten befragt der Vorlagen-Agent den Dialogvorlagen-
Agenten nach Informationen, wie die Dialoge der Konversation zwischen Kunde und Dienstleister
visualisiert werden sollen. Die Informationen, die den ersten Dialog betreffen, sendet er als finalen
Dialog an den Stellvertreter-Agenten zurück. Da die Stellvertreter-Agenten die
Visualisierungsinformationen nicht intern speichern können, ist für die folgenden Dialoge jeweils
eine Konversation mit dem Vorlagen-Agenten zu führen.
4.9 Zusammenfassung
An die Visualisierung sind folgende Anforderungen zu stellen: Es soll ein Internet Client
geschaffen werden, der weder bisherige Threads blockiert, noch die Migration der Agenten
einschränkt. Sämtliche in den TBCs vorhandene Datentypen müssen darstellbar sein. Für die
Ausgabe von Massendaten müssen mehrere Möglichkeiten vorhanden sein, um unterschiedliche
Mengen von Datensätzen auf verschiedene Arten darstellen zu können. Bestehende Standards der
Darstellung, Benutzerführung und Bedienung des Systems sollen mit der
Visualisierungsschnittstelle realisierbar sein. Der Benutzer muß zwischen synchronen und
asynchronen Verbindungen wählen und wechseln können.
Ein dynamisches Modell, das die Abspeicherung von Semantiken ermöglicht, könnte durch den
Einsatz von Visualisierungsvorlagen realisiert werden.

49
5. Kapitel
Analyse der Tycoon Business Objects
Für die Visualisierung bietet es sich an, auf bereits vorhandene Funktionalitäten zurückzugreifen.
Im wesentlichen kommen hierfür zwei Arbeiten in Frage. In der ersten wird eine Verbindung
zwischen dem Internet und dem Tycoon Objektspeicher geschaffen [Ramm96]. Die zweite ist ein
Prototyp der Tycoon Business Objects (TBO), mit dem Objekte im Internet visualisiert werden
sollen.
Die Arbeit von Ramme hat das Ziel, Objektreferenzen im Objektspeicher von Tycoon zu
visualisieren. Damit trifft sie nicht das Ziel der vorliegenden Arbeit. Die Tycoon Business Objects
wurden vom Matthes und Müßig mit dem Ziel geschaffen, Tycoonobjekte verschiedenen Typs im
Internet darzustellen. Außerdem sind sie als Vorläufer zu den Tycoon Business Conversations zu
sehen, haben aber bis auf eine ähnliche Erzeugung von Objekttypen mit der Realisierung von
Johannisson [Joha97] nichts mehr zu tun. Um Objekte im Internet darzustellen, wurde eine
Funktionsbibliothek geschaffen, die im nachfolgenden näher beschrieben wird.
Das System der TBOs ist unter wwwenv in den Tycoon Bibliotheken zu finden und besteht aus
mehreren Teilen. Die für die Visualisierung der TBCs wichtigen Teile sind Tbo.ti und Html.ti.
Html.ti enthält Funktionen zur Erzeugung von HTML-Befehlen, Tbo.ti dient zur Erzeugung und
Verwaltung von Datenobjekten und Webservern. Im folgenden werden die einzelnen Teile dieses
Systems näher erklärt und untersucht, ob sie für die Visualisierung der TBCs geeignet sind.
5.1 Verbindungsablauf
Um die TBOs nutzen zu können, muß zunächst ein TBO-Server gestartet werden. Über diesen
Server werden die zu visualisierenden Objekte angesprochen und visualisiert.
Ein HTTP-Client, der Informationen visualisieren soll, sendet einen HTTP-Request, also eine
URL, an den Webserver. Dieser führt das in der URL genannte cgi-Skript aus [Mise98]. Ein cgi-
Skript ist ein Programm, das im Common Gateway Interface (CGI) eines Webservers vorhanden
ist. Das Common Gateway Interface ist eine Schnittstelle zwischen World Wide Web-Servern und
Skripten, Dienstprogrammen und Programmen, die Benutzerantworten auf Clientanforderungen
generieren [Morr95].

50 5. Analyse der Tycoon Business Objects
Auf dem Webserver wird durch dieses cgi-Skript ein C-Programm gestartet. Das Programm wertet
die URL aus und sendet sie über den Port, dessen Nummer im Skript festgelegt ist, an den TBO-
Server. Der TBO-Server verarbeitet die Anfrage, erzeugt den entsprechenden HTML-Code und
sendet diesen zurück an den HTTP-Client. Danach greift er sofort wieder auf den angegebenen Port
zu, um ankommende Nachrichten zu empfangen.
Da der TBO-Server die Anfragen über einen Port empfängt, muß dieser Port von vornherein beiden
Seiten bekannt sein. Der TBO-Server wird deshalb unter Angabe der Portnummer gestartet. Es
lassen sich gleichzeitig mehrere Server auf unterschiedlichen Ports eines Rechners starten.
Irgendwo SUN01 Webserver SUN02
TBO-User
HTTP-Client
Script
"tycoon"
C-Programm
"t2w3"
TBO-Server
.../cgi-bin/
tycoon?
object=
./t2w3 sun02.
sts.tu-harburg.de
8697
TBO-Action
main(array "8697"
"/cgi-bin/tycoon" end )
HTTP
Port
Abbildung 5.1: Verbindungsablauf der Visualisierung
Bei der Visualisierung vergibt der TBO-Server selbstständig Namen für die visualisierten Objekte,
die auf der HTML-Seite verwendet werden. Es gibt zwar eine Funktion setObjectName(), aber der
damit gesetzte Name hat keinen Einfluß auf die Visualisierung. Er wird nur intern verwendet. Auch
mit den Funktionen addAttribute() und setAttributes() läßt sich dieses nicht beheben, weil damit
zwar neue Attribute hinzugefügt und diese auch geändert werden können, eine Änderung des
Attributes name aber nicht möglich ist.
Um den mit setObjectName() gesetzten Objektnamen standardmäßig für die Visualisierung zu
verwenden, müßten in tbo.tm die Funktionen newObjectName() und newFieldName() angepaßt
werden.
Eine Visualisierung von anderen, im TBO-System vorher nicht definierten, Objekten, über das
Interface Html.ti ist zwar möglich, aber die darin enthaltenen Daten können aufgrund der fehlenden
Namenszuordnung mit dem existierenden System nicht ausgewertet werden. Deshalb sind nur die
vorhandenen Datentypen verwendbar. Um weitere Datentypen nutzen zu können, muß das TBO-
System (Tbo.ti) um neue Datentypen erweitert werden.

5.2. Daten- und Aktionsobjekte 51
5.2 Daten- und Aktionsobjekte
Wenn die Visualisierung durch den TBO-Server erfolgt, muß für jeden zu visualisierenden
Datentyp der TBCs ein Gegenstück im TBO-Modul vorhanden sein.
Typ Name TBO Name TBC
Fließkommazahl Nicht vorhanden TbcContent.realSpec()
Ganzzahl Tbo.int TbcContent.intSpec()
Zeichen Nicht vorhanden Nicht vorhanden
Zeichenkette Tbo.string TbcContent.stringSpec()
Boolsche Werte Tbo.bool Nicht vorhanden
Datum Tbo.date TbcContent.dateSpec()
Mehrfachauswahl Tbo.enum
checkboxType
selectMultipleType
Oder Tbo.iter
TbcContent.multipleChoiceSpec()
Einzelauswahl
Tbo.enum
radioType
TbcContent.singleChoiceSpec()
Record Siehe unten TbcContent.rcdSpec()
Variante Tupel Siehe unten TbcContent.variantSpec()
Massendaten Siehe unten TbcContent.sequenceSpec ()
Konversationsspezifikation
Siehe unten
TbcContent.cspecSpec()
Dialog Siehe unten TbcContent.dialogSpec()
Formular Tbo.user Dialog
Aktion Tbo.action Request
Hyperlink Html.anchor Nicht vorhanden
Grafik Nicht vorhanden Nicht vorhanden
Tabelle 1: Vergleich der Datentypen
Da für die Darstellung die zu visualisierenden Objekte der TBCs und damit die dort zur Verfügung
stehenden Typen ausschlaggebend sind, ist ein Vergleich der Datentypen der TBCs und TBOs
notwendig.
Für den Datentyp der Fließkommazahl (Real) existiert kein Äquivalent bei den TBOs. Das einzelne
Zeichen läßt sich in beiden Systemen durch eine Zeichenkette (String) der Länge eins realisieren.

52 5. Analyse der Tycoon Business Objects
Eine boolsche Variable (Bool) läßt sich auf der TBC-Seite z.B. als Zeichenkette (String) mit den
Inhalten „true“ oder „false“ oder als ganze Zahl (Int) mit den Inhalten 0 oder 1 darstellen. Die
Datentypen Record (Rcd), variantes Tupel (Variant), Konversationsspezifikation (Cspec) und
Dialog (Dialog) können, wie in Abschnitt 6.2.4 und 0 gezeigt, in atomare Datentypen aufgelöst
werden, so daß bei den TBOs entsprechende Typen die Darstellung zwar erleichterten, aber nicht
benötigt werden. Auch der Zugriff auf Massendaten (sequence) läßt sich auf atomare Typen
zurückführen. Die dafür notwendigen Zugriffsfunktionen sind in Abschnitt 4.7.3 aufgeführt. Die
Konversationsspezifikation (Cspec) muß nicht visualisiert werden. Sie ist nur für die Realisierung
des Archives notwendig [Krus97]. Sollten die Anforderungen hin zu einer Visualisierung geändert
werden, so würde die Konversationsspezifikation als mehrzeilige Zeichenkette dargestellt werden,
die nur ausgegeben, aber nicht geändert werden könnte.
Der Datentyp der Mehrfachauswahl (tbo.iter) wird u.a. zur Darstellung von Listen atomarer Typen
benutzt. Für nicht atomare Typen müßte die Realisierung in tbo.tm entsprechend erweitert werden.
Ebenso wie die Datentypen, müssen auch die Aktionen (requests) eines Dialoges durch die TBOs
abbildbar sein. Dieses läßt sich mit den Objekten vom Typ tbo.action realisieren. Sie werden in der
HTML-Seite als Schaltflächen visualisiert.
Durch die Betätigung einer Schaltfläche wird auf der TBO-Seite eine tbo.action ausgelöst. Danach
werden die in dieser Aktion definierten Befehle ausgeführt. Entweder wird durch einen der Befehle
eine HTML-Seite an den HTTP-Client gesendet, oder es wird automatisch bei der Beendigung der
tbo.action eine leere Seite an den Client zurückgegeben. Dieses automatische Senden verursacht
Probleme, die in Abschnitt 7.3 näher erklärt und gelöst werden.
5.3 Seitenobjekte
Die Objekte vom Typ tbo.user entsprechen bei der Visualisierung einer HTML-Seite. Sie können
außerdem noch verschachtelt werden, so daß ein tbo.user-Objekt aus mehreren anderen tbo.user-
Objekten aufgebaut werden kann. Ein tbo.user-Objekt setzt sich dabei aus vielen Einzelobjekten
vom Typ tbo.action oder TBO-Datentypen zusammen. Des weiteren können mit Funktionen des
Interfaces Html.ti, wie z.B. html.plain(), einfache Texte und andere Objekte zu
Kommentarzwecken eingefügt werden.

5.4. Zusammenfassung 53
tbo.user
tbo.string
tbo.bool
tbo.date
tbo.action
HTML Text
tbo.int
tbo.newDate tbo.iter tbo.enum
Abbildung 5.2: Aufbau eines Seitenobjektes
Um Probleme beim Wiederherstellen von Seiten, dem reload, zu vermeiden, müssen die einzelnen
Seitenobjekte exportiert werden. Damit wird gleichzeitig erreicht, daß diese Seitenobjekte direkt
und nicht nur durch den Umweg über andere Seiten, abrufbar sind. Daneben empfiehlt es sich,
diese auch gleich mit einem internen Namen zu versehen, auch wenn dies für den reinen Export
nicht notwendig ist.
Ebenso wie die in Abschnitt 5.1 geschilderten Objekte verfügt auch dieser Typ über eine display-
Methode, die es ermöglicht, das Objekt an den Server zu senden.
5.4 Zusammenfassung
Das TBO-System stellt mit seinen Daten-, Aktions- und Seitenobjekten eine Möglichkeit zur
Unterstützung der Visualisierung von TBCs dar. Es ist zu diesem Zweck an einigen Stellen zu
erweitern, wie z.B. um den Datentyp Real und die Möglichkeit, Grafiken darzustellen. Außerdem
ist zu testen, wie der Datenaustausch zwischen den TBO- und TBC-Objekten funktioniert und ob
der TBO-Server genutzt werden kann, ohne die Fähigkeiten des Agentensystems einzuschränken.

55
6. Kapitel
Design der Visualisierungskomponente
Nach der Analyse der für die Visualisierung wichtigen Einzelheiten wird jetzt der Aufbau des
Visualisierungssystems vorgestellt. Aufbauend auf den einzelnen Datentypen und einer Diskussion
der möglichen Darstellungsarten der Datentypen, erfolgt danach die Einordnung in das
Agentensystem und die Behandlung der durch das System bedingten Voraussetzungen.
Generell wird die optimale Visualisierung eines Objektes davon beeinflußt, was zu welchem
Zweck dargestellt werden soll. Ein singleChoice-Objekt kann z.B. einerseits als Kombinationsfeld,
andererseits aber auch als Liste von Optionsfeldern dargestellt werden. Nur bei den atomaren
Objekten läßt sich aufgrund der Möglichkeiten von HTML eine Standarddarstellung angeben.
Doch auch hier muß in Einzelfällen die Breite der Felder spezifiziert werden. Bei den komplexen
Datentypen muß ggf. die gewünschte Erscheinung bestimmt werden. Dieses kann mit den in
Abschnitt 4.8 geschilderten Visualisierungsvorlagen geschehen.
6.1 Atomare Datentypen
In den Business Conversations sind die atomaren Datentypen Int, Real, String und Date
vorgesehen. In HTML lassen sich derartige Daten in Formularfeldern des input-Typs darstellen.
Abbildung 6.1: Visualisierung atomarer Daten
Es kann in einer reinen HTML-Seite kein Unterschied zwischen den o.g. Datentypen gemacht
werden. Die Daten werden alle in derselben Form als Zeichenkette über die URL zurückgeliefert.
Eine Umsetzung in die entsprechenden Typen muß auf der Programmseite erfolgen. Dieses wird
durch die Nutzung des TBO-Systems automatisch erreicht.

56 6. Design der Visualisierungskomponente
Darf die Eingabe des Benutzers nicht sichtbar sein, so kann ein Kennwortfeld (password)
verwendet werden. Eingegebene Zeichen werden hier durch Sterne symbolisiert [Morr95].
Abbildung 6.2: Kennwortfeld
Beim Absenden von Kennwörtern muß darauf geachtet werden, daß die post-Methode (siehe
Abschnitt 4.2) verwendet wird. Eine Verwendung der get-Methode führt dazu, daß das Kennwort
im Klartext in der URL auftaucht.
Reicht eine einzelne Zeile nicht aus, weil die aus- oder einzugebende Informationsmenge zu groß
oder über mehrere Zeilen verteilt ist, muß ein Textbereich (textarea) verwendet werden [Morr95].
Abbildung 6.3: Textbereich
Die geschilderten Verfahren orientieren sich an der HTML 4.0 Spezifikation [W3C97]. Andere
Möglichkeiten, flexiblere Seiten zu erzeugen und auszuwerten, werden durch
Programmiersprachen wie Java [Java96], JavaScript und DynamicHTML [Hüsk97a] geboten.
Die Umsetzung von TBO- zu TBC-Datentypen wird in Abschnitt 7.3.3 ausführlich beschrieben.
6.2 Komplexe Datentypen
Die komplexen Datentypen können weitere TBC-Datentypen enthalten. Diese Verschachtelung
kann in beliebige Verschachtelungstiefen fortgesetzt werden. Zu den komplexen Datentypen zählen
SingleChoice, MultipleChoice, Dialog, Cspec, Sequence, Rcd und Variant. Für diese Datentypen
muß differenziert werden, ob sie nur atomare Objekte oder weiterverschachtelte Elemente
enthalten.
Für atomare Objekte sind die oben genannten Darstellungen zusammen mit den im Folgenden
ausgeführten typspezifischen Wiedergaben ausreichend. Da das TBO-System eine Verschachtelung
von Objekten zuläßt, wird die Darstellung komplexer Objekte durch die Aggregation von
Einzelkomponenten erzeugt. Hierbei sind die unten beschriebenen Einzelheiten für die jeweiligen
Typen zu beachten.

6.2. Komplexe Datentypen 57
Generell lassen sich verschachtelte Datenstrukturen in HTML mit Tabellen, Frames und
Hyperlinks, die auf weitere HTML-Seiten verweisen, gut darstellen. Frames sind HTML-Seiten, in
denen weitere HTML-Seiten dargestellt werden können, so daß eine Verschachtelung von HTML-
Seiten realisierbar wird. Die Darstellungsmöglichkeiten sind im TBO-System bereits vorhanden
oder werden durch die in Abschnitt 7.5 geschilderten Erweiterungen gegeben. Gerade bei den
komplexen Inhaltsobjekten muß der von Bachmann [Bach95] formulierte erste Grundsatz der
Design-Grundlagen für Hypertext-Systeme beachtet werden. Dieser Grundsatz lautet: Entwerfe
Oberflächen so einfach wie möglich. Gemeint ist damit, daß bei der Verwendung zu vieler Objekte
auf einer HTML-Seite der Benutzer leicht die Übersicht verliert. Wenn viele Informationen
dargestellt werden müssen, sollten diese aufgeteilt und zu verschiedenen Zeitpunkten,
beispielsweise durch untergeordnete Fenster, präsentiert werden.
Deshalb muß bei den verschachtelten Objekten die Verschachtelungstiefe und die Anzahl der
Objekte pro Ebene beachtet werden. Ab einer vom Einzelfall abhängigen Verschachtelungstiefe
und Objektanzahl kann die Visualisierung nicht mehr auf einer einzelnen HTML-Seite erfolgen,
weil die Übersichtlichkeit und damit ein wesentlicher Aspekt der Benutzerfreundlichkeit des
Systems, nicht mehr gegeben wäre. Es können weitere Fenster, im folgenden als Unterfenster
bezeichnet, geöffnet werden, um Einzelheiten darzustellen. Ein automatisches Anzeigen aller
Einzelheiten in weiteren Fenstern (Unterfenstern) ist jedoch aus Gründen der Übersichtlichkeit
nicht sinnvoll. Deshalb wurde die Möglichkeit geschaffen, Unterfenster mit Schaltflächen oder
Hyperlinks aufzurufen. Diese Fenster können wiederum bei genügend komplexen Datenstrukturen,
eigene Unterfenster haben.
Sind die Unterfenster visualisiert, muß sichergestellt werden, daß sie bei der Auswahl eines
anderen Elementes auf der Hauptseite aktualisiert werden [Mues94]. Außerdem ist es sinnvoll, die
Folgeseiten beim Verlassen der Hauptseite zu schließen. Bei Datenänderungen, die z.B.
Auswirkungen auf aggregierte Werte in übergeordneten Fenstern haben, müssen die abhängigen
Fenster aktualisiert werden.
Derartige Anforderungen lassen sich für nicht HTML-basierte Visualisierungen u.a. mit den in
[Mues94] und [Koeh96] geschilderten Methoden lösen. In HTML 4.0 stehen nur Möglichkeiten
zum Aktualisieren der Folgeseite oder des übergeordneten Fensters zur Verfügung. Ein
automatisches Schließen derselben erfordert über HTML hinausgehende Funktionalitäten.
Aus diesen Gründen ist die Darstellung mit Unterfenstern nach Möglichkeit zu vermeiden. Die
bessere Alternative bieten in den meisten Fällen Frames.
6.2.1 Auswahltypen
Zu den Auswahltypen gehören die Auswahl eines Elementes aus einer Liste (SingleChoice) und die
Auswahl mehrerer Elemente (MultipleChoice). Bei der Darstellung einer SingleChoice ist der Typ
der darin enthaltenen Objekte zu beachten. Gehört er zu den atomaren Datentypen, so bietet sich
eine Darstellung als Kombinationsfeld (listbox) an. Diese hat den Vorteil, daß wenig Platz
verbraucht wird. Dafür sind allerdings nicht alle Möglichkeiten auf einmal sichtbar.

58 6. Design der Visualisierungskomponente
Abbildung 6.4: Visualisierung der SingleChoice als Kombinationsfeld
Sollen mehrere Werte auf einmal sichtbar sein, so kann die Darstellung als Listenfeld oder
Optionsgruppe mit einzelnen Optionsfeldern (radio Buttons) erfolgen.
Listenfeld
Optionsgruppe
Abbildung 6.5: Visualisierung der SingleChoice mit atomaren Daten
Bei verschachtelten Datentypen ist die Darstellung als Optionsgruppe, die aus mehreren
Optionsfeldern mit weiter untergeordneten Feldern besteht, zu benutzen.
Die Darstellung komplexer Optionsgruppen und Kontrollkästchen wird durch die TBOs nicht
unterstützt. Deshalb muß für die Darstellung ein komplexes Objekt in einfach strukturierte Objekte
zerlegt werden. Danach wird jeweils eine Zeile der Optionsgruppe, also ein Optionsfeld,
abwechselnd mit den dazu gehörenden Unterfeldern erzeugt.

6.2. Komplexe Datentypen 59
Abbildung 6.6: Komplexe Optionsgruppe
Da verschachtelte Formulare in HTML nicht möglich sind, werden bei der Auswahl einer Option
auch die den anderen Optionen untergeordneten Felder mit übermittelt. Der Agent muß nach einer
Auswahl selbständig die relevanten Informationen filtern.
Abbildung 6.7: Visualisierung der MultipleChoice

60 6. Design der Visualisierungskomponente
Beim Typ MultipleChoice ist zu beachten, daß in ihm häufig komplexe Strukturen enthalten sind,
die im Einzelfall mit beachtet werden müssen. Beim Absenden des Formulars an den Server
werden die Werte derjenigen Kontrollkästchen (checkbox) mit übermittelt, die vorher ausgewählt
wurden. Es ist, anders als bei der Optionsgruppe, nicht möglich, Kontrollkästchen zu gruppieren.
Alle selektierten Felder werden mit an den Server übermittelt. Dabei kann nicht überprüft werden,
ob das übergeordnete Objekt ebenfalls ausgewählt wurde. Agentenseitig ist eine Nachbearbeitung
der zurückgesandten Informationen notwendig.
6.2.2 Dialoge
Die Darstellung ganzer Dialoge, wie sie z.B. für das Archiv [Krus97] erforderlich ist, kann mit
Frames erfolgen. Hierbei wird eine HTML-Seite in mehrere Teilbereiche unterteilt, die alle aus
einzelnen Seiten bestehen. Ebenso ist es möglich, Dialoge in Tabellenzellen darzustellen. Sie
können auch zusammen mit den anderen Daten auf einer Seite untergebracht werden. Hier muß
allerdings darauf geachtet werden, daß die zu einem Dialog gehörenden Daten als
zusammenhängend gekennzeichnet werden. Dieses kann bei einer dynamischen Darstellung mit
Hilfe der Visualisierungsvorlagen aus Abschnitt 4.8 geschehen.
Abbildung 6.8: Visualisierung von Dialogen mit Frames
Für die Darstellung der einzelnen Elemente der Dialoge gelten die bereits beschriebenen
Einzelheiten. Werden die im Archiv gespeicherten Dialoge dargestellt, so muß sichergestellt
werden, daß keine Änderungen an den Dialogen vorgenommen werden können. Dieses kann
beispielsweise mit den Visualisierungsvorlagen oder durch die Verwendung von nicht aktivierten
(disabled) Feldern geschehen [W3C97].

6.2. Komplexe Datentypen 61
6.2.3 Sequence
Mit dem Datentyp sequence wird die Verwaltung von Massendaten ermöglicht. Die mit diesem
Typ aggregierten Objekte sind nicht direkt in das Dialogobjekt eingebunden. Stattdessen werden
Methoden für den Zugriff auf Datenbanken durch Klienten zur Verfügung gestellt [Joha97].
Die tabellenorientierte Darstellung ist sinnvoll, um eine größere Anzahl von Datensätzen
gleichzeitig anzuzeigen. Hierbei ist zwischen zwei- und mehrdimensionalen Tabellen zu
unterscheiden. Eine zweidimensional organisierte Massendatenstruktur kann sehr gut mit Tabellen
dargestellt werden [Jone96]. Die Spaltenüberschriften ergeben sich aus den entsprechenden
Feldbezeichnungen.
Abbildung 6.9: Zweidimensionale Tabelle
Ist die Organisation der Massendaten mehr als zweidimensional, was u.a. bei Pivot-Tabellen der
Fall sein kann, kann die Darstellung häufig noch mit Tabellen erfolgen [Jone96]. Die Entwicklung
einer statischen Visualisierung von Massendaten ist aufgrund der vielen zu beachtenden Objekte
sehr umfangreich. Die dynamische Erstellung dieser Tabellen wird gegenüber den
zweidimensionalen Tabellen dadurch erschwert, daß die Zuordnung und graphische Darstellung
der weiteren Dimensionen semantisches Wissen voraussetzt.

62 6. Design der Visualisierungskomponente
Abbildung 6.10: Mehrdimensionale Tabelle
Sind die einzelnen Felder in der Tabelle mehrdimensional strukturiert, so sind die Grenzen der
Übersichtlichkeit schnell erreicht. Dann ist es vorteilhafter, für die Darstellung Unterfenster oder
Frames zu benutzen [AH97]. Gerade mit Frames läßt sich die Übersichtlichkeit einer HTML-Seite
stark erhöhen, indem ein Navigationsbereich erstellt wird, der auch beim Blättern im Hauptbereich,
in dem die Daten dargestellt werden, nicht verschwindet [AH97] (siehe Abbildung 6.8). Werden
für die Navigation keine Frames benötigt, so sollte auf den Einsatz von Frames verzichtet werden,
weil die Übersichtlichkeit einer HTML-Seite durch Frames gemindert wird [Niel96] und die
meisten Benutzer Seiten ohne Frames vorziehen [Sull96].
Welche Art der Darstellung gewählt wird, ist im einzelnen abhängig von der Anzahl der Datensätze
und der Komplexität der Struktur. Es läßt sich für diesen Zweck keine allgemeingültige Regel
angeben.
Da es bei Massendaten häufig nicht erforderlich oder aufgrund der Datenmenge nicht sinnvoll ist,
alle Datensätze auf einmal darzustellen, müssen Möglichkeiten vorhanden sein, auch Teilmengen

6.2. Komplexe Datentypen 63
anzuzeigen. Abhängig von der Art der Daten kann die anzuzeigende Datensatzanzahl variieren. Um
dieses flexibel lösen zu können, ist der Einsatz von Visualisierungsvorlagen sinnvoll. Die hierin
enthaltenen Informationen können z.B. die maximale Anzahl an gleichzeitig anzuzeigenden
Datensätzen beinhalten.
Bei allen Möglichkeiten ist es erforderlich, Obergrenzen für die Anzahl der gleichzeitig
angezeigten Datensätze oder Verweise festzulegen. Diese Anforderung kann direkt bei der
Erstellung der HTML-Seiten erfüllt werden. Eine andere Möglichkeit, die Anforderung zu erfüllen,
besteht darin, die Funktionen, über die beim Datentyp Sequence auf die Massendaten zugegriffen
wird, so zu realisieren, daß von vornherein nur die gewünschte Anzahl an Datensätzen ausgegeben
wird. Da zur Zeit bei der Sequence keine Funktionen zum Zugriff auf die Massendaten existieren,
wurde die zweite Möglichkeit in der Realisierung nicht berücksichtigt.
Zusätzlich sind in den HTML-Seiten Funktionen z.B. in Form von Schaltflächen zu implementieren,
um den nächsten bzw. vorherigen Teil der Datensätze anzuzeigen.
6.2.4 Rcd und Variant
Der Datentyp Rcd dient der Verwaltung von Recordstrukturen innerhalb von Dialogobjekten. Die
Darstellung einer Recordstruktur erfolgt durch die Visualisierung der einzelnen im Record
enthaltenen Felder. Deshalb gelten die o.g. Möglichkeiten, einzelne Felder oder Strukturen
darzustellen, auch für die Records. Gegebenenfalls läßt sich die Zusammengehörigkeit der
einzelnen Elemente noch durch Linien oder Rahmen zeigen.
Beim Datentyp Variant handelt es ich um variante Tupel. Die Darstellung der einzelnen Varianten
lehnt sich an die Möglichkeiten von Rcd an. Allerdings können Anzahl, Größe und Typ der Felder
je Variante unterschiedlich sein.
Es ist von der konkreten Anwendung abhängig, ob alle Varianten dargestellt werden, so daß der
Kunde entscheiden kann, welche er nutzen möchte, oder vor der Darstellung entschieden wird,
welche Variante visualisiert wird. Die zweite Möglichkeit ist leichter zu realisieren, weil weniger
Felder angezeigt werden müssen und die Übersichtlichkeit dadurch gesteigert wird.
Werden alle Varianten gleichzeitig dargestellt, so ist es nicht möglich, eine Variante innerhalb der
TBO-Aktionen des Kunden auszuwählen. Hierdurch würde der Visualisierungsteil des Agenten
Funktionalitäten erhalten, die nach dem Konzept der Business Conversations nur in den Regeln
enthalten sein dürfen. Werden mehrere Varianten angezeigt, so muß die Auswahl der Variante
beim Dienstleister erfolgen.
Eine Umsetzung, in der nur jeweils eine Variante sichtbar ist und in der innerhalb einer HTML
Seite zwischen den Varianten mit Hilfe eines Kombinationsfeldes umgeschaltet wird, wie es bei
[Mues94] realisiert wurde, ist mit reinen HTML-Befehlen nicht möglich. Es fehlt die Möglichkeit,
durch die Auswahl von Werten Aktionen auslösen [Münz97a] zu können. Bei [Mues94] war diese
Möglichkeit durch die Nutzung des NeWS-Toolkits [SS92] gegeben. Durch den Einsatz von
Programmiersprachen wie JavaScript [Münz96] und Java [Java96] ließe sie sich auch für das
Agentensystem implementieren.

64 6. Design der Visualisierungskomponente
Sollen alle Varianten visualisiert werden, so kann dieses ähnlich der singleChoice in Abbildung 6.6
geschehen. Der Benutzer kann eine Variante markieren und die entsprechenden Felder ausfüllen.
Zu beachten ist auch hier, daß alle Felder aller Varianten zum visualisierenden Agenten
zurückgesandt werden. Die Auswertung muß also der Agent selber übernehmen.
Variante Typen werden durch eine statisch programmierte Darstellung sehr eingeschränkt, weil
bereits während der Entwicklung alle möglichen Varianten vorausgesehen werden müssen. Ist ein
varianter Datentyp erst einmal in seine Bestandteile zerlegt, liegen nur noch die oben bereits
behandelten Datentypen vor. Die Zusammengehörigkeit der Elemente muß eventuell, wie beim
Typ Rcd, hervorgehoben werden.
6.3 Anfragen
Anfragen können sowohl als Hyperlinks, Grafiken mit Hyperlinks (image), Image Maps oder als
Schaltflächen (button) realisiert werden.
Werden Anfragen durch Hyperlinks repräsentiert, müssen die zurückzusendenden Werte in den
Hyperlinks entweder bereits eingetragen sein oder es ist nur möglich, auf vorher durch das TBO-
System erzeugte und exportierte HTML-Seiten zu kommen. Bei der ersten Möglichkeit muß das
TBO-System die Logik liefern, die so ankommenden URLs in Aktionen umzusetzen. Das TBO-
System kann nur diejenigen Teile einer URL auswerten, die den vorher erzeugten Objekten, den
input-Elementen der HTML-Seite, entsprechen. Deshalb müssen die vorher festzulegenden Werte
in TBO-Objekten, die z.B. als unsichtbare Felder (hidden) auf der HTML-Seite dargestellt werden,
vorhanden sein. Da die Objektnamen der durch das TBO-System dargestellten Objekte aber nicht
beeinflußbar sind (siehe Abschnitt 5.1), müßte hierfür das TBO-System erweitert werden. Die
zweite Möglichkeit ist sinnvoll, wenn Hyperlinks, wie in Abbildung 6.8 gezeigt, zur Navigation
eingesetzt werden.
Da Hyperlinks im allgemeinen mit fest vorgegebenen Inhalten assoziiert werden, sind sie nicht so
geeignet wie die Schaltflächen, die standardmäßig in den bisherigen Formularen im Internet als
Auslöser von Aktionen benutzt werden. Deshalb werden in der Realisierung standardmäßig diese
Schaltflächen für die Anfragen verwendet, obwohl auch Hyperlinks und Grafiken möglich sind.
Abbildung 6.11: Visualisierung einer Anfrage durch eine Schaltfläche
Ebenso können weitere Funktionen, wie etwa zur Verwaltung der Visualisierungsvorlagen, durch
Schaltflächen dargestellt werden.

6.4. Einordnung des Visualisierungsdienstes 65
6.4 Einordnung des Visualisierungsdienstes
Bei der Entwicklung eines Visualisierungsdienstes ist zu entscheiden, ob ein bereits existierender
Dienst genutzt werden soll, der Visualisierungsdienst als externer Dienst zur Verfügung stehen
oder in das Agentensystem eingebaut werden soll.
HTTP-Client
HTTP-Client
Visualisierungsagent
Visualisierungsagent
Agent A
Agent B
Abbildung 6.12: Externer Visualisierungsdienst
Bei der Verwendung bereits existierender externer Dienste ist eine Kompromißlösung notwendig,
weil diese die Anforderungen nicht in idealer Weise erfüllen [Koeh96]. Um eine bedingte
Anpassung an die eigenen Anforderungen zu ermöglichen, muß ein externer Visualisierungsdienst
erweiterbar sein. Der Vorteil externer Visualisierungsdienste besteht darin, daß die Entwicklung
einer eigenen Benutzerschnittstelle, die sehr aufwendig und fehlerträchtig sein kann und einen
hohen Wartungsaufwand erfordert, entfällt. Der Vorteil eines selbst entwickelten Dienstes liegt
darin, daß er den eigenen Wünschen und Anforderungen entsprechend entwickelt werden kann. Da
derzeit kein Programm existiert, welches den Anforderungen an die Visualisierung der TBCs
entspricht, bleibt nur, einen derartigen Dienst selbst zu erstellen.
6.4.1 Zentraler Visualisierungsdienst
Bei einem zentralen Visualisierungsagenten handelt es sich um einen Agenten, der für alle anderen
Agenten über Nachrichten erreichbar ist und deren Dialoge visualisiert. Durch die Entwicklung
eines zentralen Visualisierungsdienstes, der unabhängig von einzelnen Agenten existiert, erreicht

66 6. Design der Visualisierungskomponente
man eine Trennung zwischen Visualisierung und den Regeln der Agenten. Durch diese Trennung
wird nicht nur die Wartung der einzelnen Agenten einfacher, sondern man erreicht bei einem
generisch implementierten Visualisierungsdienst auch kürzere Entwicklungszeiten und besseres
Prototyping der Agenten.
HTTP-Client
HTTP-Client
Visualisierungsagent
Agent A
Agent B
Abbildung 6.13: Zentraler Visualisierungsagent
Für die Nutzung des zentralen Visualisierungsagenten muß sein Aufenthaltsort den anderen
Agenten bekannt sein. Ist die Auslastungsgrenze des Visualisierungsagenten erreicht, können
weitere Visualisierungsagenten erzeugt werden. Ein Verteileragent kann dann die einzelnen
Aufträge auf die Visualisierungsagenten verteilen, so daß die Adressen der einzelnen Agenten nicht
veröffentlicht werden müssen. Gleichzeitig könnte mit Hilfe des Verteileragenten ein
Zugriffsschutz implementiert werden. Der Verteileragent muß eine feste Adresse bekommen, weil
das Nachrichtensubsystem den Wechsel einer Adresse mit automatischem Weiterleiten der
Nachrichten noch nicht unterstützt.
Der Visualisierungsagent erhält per ITC-Nachricht den zu visualisierenden Dialog, die
Konversations-ID des aufrufenden Agenten und die Adresse des HTTP-Clients. Der Dialog wird in
HTML umgesetzt und über das HTTP an den Browser verschickt. Dort werden die Daten geändert
und durch das Drücken einer Schaltfläche abgesandt. Die vom Client erzeugte URL wird an den
zentralen Visualisierungsagenten zurückgeschickt. Dieser trägt die geänderten Werte in den Dialog
ein und sendet ihn, gegebenenfalls zusammen mit der Angabe der ausgewählten Anfrage, per ITC
an den Auftraggeber zurück. Der sendet den Dialog und, wenn er in der Konversation die
Kundenrolle innehat, die Anfrage zurück an seinen Konversationspartner.

6.4. Einordnung des Visualisierungsdienstes 67
Es ist, wie in Abschnitt 6.5 näher erläutert, nicht sinnvoll, eine Regel für die Visualisierung zu
unterbrechen. Deshalb ist es nicht zweckmäßig, an derjenigen Stelle einer Regel fortzusetzen, an
der die Visualisierung aufgerufen wurde. Stattdessen ist die Regel nach dem Aufruf der
Visualisierung zu beenden, ohne eine Antwort an den Konversationspartner zu senden. Basierend
auf der vom Visualisierungsagenten ankommenden ITC-Nachricht wird eine andere Regel
ausgeführt, welche die Antwort an den Konversationspartner zurücksendet.
Damit Nachrichten an den Visualisierungsagenten gesandt bzw. vom Visualisierungsagenten
abgeschickt werden können, muß das Nachrichtensubsystem (ITC) um die entsprechenden
Nachrichtentypen erweitert werden. Außerdem ist das Agentensystem so zu erweitern, daß bei der
Ankunft der Nachrichtentypen die ihnen entsprechenden Aktionen ausgeführt werden.
Um die einzelnen Agenten, deren Dialoge visualisiert werden, erreichen zu können, muß ihre
genaue Adresse entweder dem Benutzer oder dem Visualisierungsagenten bekannt sein. Wenn der
Benutzer die Adressen seiner Agenten verwaltet, muß er sie entweder in Form von URLs eingeben,
oder ein entsprechendes Eingabeformular ausfüllen, damit der Visualisierungsagent die
entsprechenden Agenten findet. Verwaltet der Visualisierungsagent die auf ihn zugreifenden
Agenten, was der Benutzerfreundlichkeit und einem stufenweise aufgebauten Sicherheitskonzept
entgegenkäme, müssen sich die Agenten bei ihm anmelden.
Wie in Abschnitt 3.4 geschildert, erlaubt es das Agentensystem, daß ein Agent mehrere
Konversationen führt, die auf derselben Konversationsspezifikation beruhen. Dadurch kann ein
Agent auch gleichzeitig mehrere gleich spezifizierte Dialoge bearbeiten. Um jede beim
Visualisierungsagenten ankommende URL genau einem Dialog zuordnen zu können, muß jeder
Dialog eine eindeutige ID bekommen. Diese ID muß als Feld auf der HTML-Seite vorhanden sein,
damit sie in der zurückgesandten URL enthalten ist. Die vom Agentensystem zur Verfügung
gestellte Konversations-ID kann wegen der darin enthaltenen Zeichen nicht verwendet werden. Die
Zeichen "?", "=", "/", "&" und Steuerungszeichen können in der ID des Agentensystems
vorkommen. Diese haben in der URL jedoch reservierte Bedeutungen oder sind, wie z.B. einige
Steuerzeichen, gar nicht zugelassen. Durch ein Ausfiltern dieser Zeichen aus der Konversations-ID
würde eine nicht eindeutige ID entstehen. Es muß also im Visualisierungsagenten eine eigene
Zuordnung und Verwaltung von IDs erfolgen.
Um dem Benutzer eine Übersicht über diejenigen Konversationen zu bieten, die ein Agent starten
kann, gibt es zwei Möglichkeiten: Der Visualisierungsagent kann, zusammen mit der Anmeldung
des Agenten, eine Liste der ausführbaren Konversationen bekommen. Dieses würde zu einer
Funktionserweiterung über die eigentliche Visualisierung hinaus führen. Es wäre eine
entsprechende Verwaltung in den Visualisierungsagenten zu implementieren.
Die andere Möglichkeit besteht darin, den Agenten um eine entsprechende Regel zu erweitern.
Diese Regel, beispielsweise Hauptmenü genannt, liefert eine Übersicht über die startbaren
Konversationen und ggf. weitere Statusinformationen über die derzeit laufenden Konversationen.
Um eine Regel aufzurufen, benötigt der Agent die ID der Konversation, in der diese Regel
aufgerufen wird. Wurde die Anmeldekonversation bereits beendet, so existiert keine laufende
Konversation mehr. Ein Regelaufruf kann aufgrund der fehlenden Konversations-ID nicht mehr
stattfinden. Um dieses zu umgehen, müßte die Anmeldekonversation beliebig lange
aufrechterhalten werden.

68 6. Design der Visualisierungskomponente
Als Ausweg, die o.g. langandauernde Anmeldekonversation mit dem Visualisierungsagenten zu
umgehen, kann der Visualisierungsagent eine neue Konversation mit dem Benutzeragenten
beginnen. Der Benutzeragent übernimmt dadurch automatisch die Rolle des Dienstleisters und
sendet dem kontaktierenden Agenten, abhängig von der zugrundeliegenden
Konversationsspezifikation, einen initialen Dialog, das Hauptmenü. Dieses wird entsprechend
visualisiert. Ausgehend davon lassen sich über den Benutzeragenten weitere Konversationen
starten und die Konversationsübersicht anzeigen.
Um die in Abschnitt 4.5 erwähnte asynchrone Kommunikation gewährleisten zu können, ist eine
Übersicht über die laufenden Konversationen notwendig. Ebenso wie das oben genannte
Hauptmenü, ließe sich auch diese Übersicht innerhalb des Visualisierungsagenten realisieren.
Besser ist aber auch hier die Realisierung der Übersicht in den einzelnen Agenten, um den
modularen Aufbau des Agentensystems fortzuführen.
6.4.2 Integrierter Visualisierungsdienst
Die Alternative zum zentralen Visualisierungsagenten besteht darin, die Visualisierungskomponente
direkt in die Agenten einzubauen.
Eine Anmeldung der Agenten an die Visualisierungskomponente, wie sie beim zentralen
Visualisierungsagenten erforderlich ist, ist bei der integrierten Visualisierungskomponente nicht
notwendig, weil jeder Agent seine Visualisierungskomponente bereits enthält. Ebenso läßt sich das
Hauptmenü über die eingebaute Visualisierungskomponente leicht implementieren. So kann die in
Abschnitt 4.5 erwähnte synchrone Kommunikation realisiert werden, ohne Änderungen am
Agentensystem vornehmen zu müssen.
Bei der Realisierung einer asynchronen Kommunikation treten die gleichen Probleme wie beim
zentralen Visualisierungsagenten auf. Die Verwaltung der aktiven Konversationen muß extra
realisiert werden, weil das Agentensystem keinen Zugriff auf die intern vorhandene
Verwaltungsstruktur zuläßt. In die Verwaltung der laufenden Konversationen läßt sich allerdings
die Vergabe von IDs für die Dialoge mit einbinden, so daß sowohl die aktuellen Konversationen als
auch die aktuellen Dialoge an einer Stelle zu verwalten sind.
Der Nachteil dieser Lösung besteht darin, daß der Programmkode der einzelnen Agenten
unübersichtlicher ist, weil die Visualisierung in jeden Agenten eingebaut werden muß. Hierbei wird
zwangsläufig, wie bei vielen graphischen Benutzeroberflächen, der Kode des
Anwendungsprogramms mit dem der Benutzeroberfläche vermischt [Wege95]. Wenn nicht bereits
bei der Entwicklung auf eine übersichtliche Gliederung des Programmkodes geachtet wird, ist es
später fast unmöglich, die oberflächenspezifischen Funktionen herauszufinden.

6.5. Nebenläufigkeit und Migration 69
HTTP-Client
HTTP-Client
Visualisierung
Visualisierung
Agent A
Agent B
Abbildung 6.14: Integrierte Visualisierung
Der Vorteil dieser Lösung besteht in der Nutzung des existierenden Agentensystems. Es sind weder
neue Nachrichtentypen zu deklarieren, noch Änderungen am Agentensystem durchzuführen.
Zudem kann die Realisierung so erfolgen, daß Komponenten der integrierten Visualisierung bei
Bedarf in einen zentralen Visualisierungsagenten übernommen werden.
Da das Agentensystem sehr umfangreich und komplex ist und die Visualisierung ohne größere
Eingriffe in das zugrundeliegende System auskommen soll, ist die Implementation der
Visualisierung in Form eines eigenständigen zentralen Agenten mit den oben genannten
Eigenschaften nicht sinnvoll. Beim integrierten Visualisierungsdienst sind keine oder in seinen
Erweiterungen nur geringe Änderungen des Agentensystems notwendig, die bereits existierende
Agenten nicht beeinträchtigen. Daher wird die Variante mit dem integrierten
Visualisierungsagenten realisiert.
6.5 Nebenläufigkeit und Migration
Würde die Visualisierungskomponente in die bisherigen Threads des Agenten eingebaut, führte
dieses zu einer zeitweiligen Blockade der entsprechenden Threads. Wird z.B. der Kundenthread zur
Visualisierung genutzt, so wird innerhalb einer Kundenregel der Dialog visualisiert und danach auf
die Antwort des HTTP-Clients gewartet. Während dieser Zeit kann der Kundenthread nicht
weiterarbeiten, ist also blockiert. Dieses führt dazu, daß Dialoge die während dieser Wartezeit von
Dienstleistern gesendet werden, es können mehrere Konversationen gleichzeitig geführt werden,
nicht abgearbeitet werden. Um das zu vermeiden, ist es notwendig, für den Empfang von
Nachrichten des HTTP-Clients einen Kommunikationsthread (TBO-Thread) in den Agenten zu
implementieren.

70 6. Design der Visualisierungskomponente
Für diesen Kommunikationsthread besteht innerhalb des Agenten zusammen mit den anderen
Threads ein gemeinsamer Zugriff auf diejenigen Daten, die sie für die Visualisierung untereinander
austauschen müssen. Hierzu gehören u.a. die visualisierten Felder und die Übersicht über die
laufenden Konversationen (siehe Abschnitt 7.2).
Agent
Kundenthread
anderer
Agent
TBO-
Thread
Agententhread
HTTP-
Client
Dienstleister
-thread
Datenbasis
Abbildung 6.15: Threads der integrierten Visualisierung
Der TBO-Thread startet einen TBO-Server, der auf Nachrichten vom HTTP-Client wartet und zur
Visualisierung der Dialoge dient.
Um das Konzept der Agenten durch die Visualisierung nicht zu beschränken, muß die in Abschnitt
3.1 geschilderte Migration von Agenten weiterhin über Rechnergrenzen hinweg möglich sein. Da
der TBO-Thread bei einer Migration nicht wie ein Agententhread an den neuen Ort migriert
werden kann, muß der TBO-Thread vor der Migration beendet werden. Nach der Migration ist der
TBO-Thread am neuen Ort wieder zu starten. Hierbei muß möglicherweise ein anderer
Kommunikationsport gewählt werden.

6.6. Zusammenfassung 71
6.6 Zusammenfassung
Atomare Inhaltsobjekte sollen als Eingabefelder dargestellt werden. Komplexe Inhaltsobjekte
werden auf ihre atomaren Inhalte zurückgeführt, sofern sie nicht als Optionsgruppen,
Kontrollkästchen oder Tabellen visualisiert werden können. Die Darstellung von Varianten kann in
Form von Optionsgruppen oder zurückgeführt auf atomare Werte erfolgen. Massendatenstrukturen
wie Sequence werden - soweit möglich - als Tabellen erfolgen. Sind die komplexen Strukturen zu
umfangreich, so sind sie in Frames darzustellen. Um die Übersicht zu erhöhen, kann die
Darstellung der o.g. Objekte in Tabellen eingebettet und mit Kommentaren oder optischen
Auflockerungen versehen werden. Anfragen werden als Schaltflächen oder, wenn sie nur zur
Navigation dienen, als Hyperlinks dargestellt.
Es wird ein in das Agentensystem integrierter Visualisierungsdienst realisiert. Dieser Dienst läuft
in einem eigenen Thread ab. Die Migrationsfähigkeit wird gewährleistet, indem vor der Migration
der Visualisierungsthread beendet und am neuen Ort wieder gestartet wird.

73
7. Kapitel
Realisierung der
Visualisierungskomponente
In diesem Kapitel werden aufbauend auf dem Design der Visualisierungskomponente die
Einzelheiten der Realisierung beschrieben. Die Ergebnisse liegen in der Tycoonbiliothek tbcwww
vor. Außerdem werden die bereits erfolgten Vorbereitungen für die dynamische Visualisierung
vorgestellt.
7.1 Starten des Visualisierungsservers
Der Visualisierungsserver (TBO-Server) wird gestartet, indem zuerst mit let s=tbo.newServer() ein
neues Serverobjekt erzeugt wird. Danach werden mit tbo.setPort(Portnummer) und
tbo.setCgiBinTycoon(cgi-bin-Pfad) die Portnummer und ein Verweis auf das cgi-bin Verzeichnis
des Webservers gesetzt. Der TBO-Server wird danach als eigener Thread gestartet
(thread.fork(fun(self :thread.T(Ok)):Ok tbo.startServer)).
Um eine standardisierte Möglichkeit zu haben, den Agenten mit Hilfe des Visualisierungsservers
zu verwalten und Konversationen starten oder weiterführen zu können, ist es nötig, für alle
Agenten einen einheitlichen Zugriff zu bieten. Dieser wird durch das Hauptmenü geboten. Der
Inhalt des Hauptmenüs variiert je nach der Definition der einzelnen Agenten.

74 7. Realisierung der Visualisierungskomponente
Abbildung 7.1: Hauptmenü des Agenten
7.2 Verwaltung der Konversationen
Um die Benutzereingaben in HTML-Formularen den einzelnen Dialogen der Konversationen
zuordnen zu können, das TBO-System für die Visualisierung zu verwenden und für die in
Abschnitt 4.5 erwähnte asynchrone Kommunikation, ist es erforderlich, sich einer Liste der aktiven
Konversationen bedienen zu können. Das Agentensystem bietet keine Möglichkeit, aus dem
Kunden- oder Dienstleisterthread heraus auf die im Agentensystem vorhandene Liste der aktiven
Konversationen zuzugreifen. Deshalb ist es notwendig, eine derartige Liste für jeden Agenten
anzulegen.
Diese Konversationsliste muß für jede Konversation mehrere Einträge enthalten. Die
Konversations-ID (ownConvID) ist notwendig, damit innerhalb einer Regel Dialoge und
Konversationen bereits vorhandenen Einträgen in der Konversationsliste zugeordnet werden
können. Die HTML-ID (htmlID) wird gebraucht, um, wie in Abschnitt 6.4 geschildert, die URLs
den visualisierten Dialogen zuzuordnen. Die Konversation (conversation) ist erforderlich, damit es
in den TBO-Aktionen möglich ist, Dialoge und Anfragen an den Konversationspartner abzusenden.
Ein Verweis auf den aktuellen Server (actualServer) wurde eingefügt, falls in einer Erweiterung

7.2. Verwaltung der Konversationen 75
des Systems mehrere TBO-Server genutzt werden sollen. Die Angabe des aktuellen Dialoges
(actualDialog) und der letzten Anfrage (requestValue) sind notwendig, um innerhalb der Übersicht
(Abbildung 7.5) den Status der Konversation angeben zu können. Eine Semaphore (waitServer) je
Konversation ist erforderlich, damit das TBO-System, wie in Abschnitt 7.3 erklärt, genutzt werden
kann. Eine Information (inUse) zur Verwaltung der Statusinformation, ob der Agent handeln muß
oder auf eine Aktion des Konversationspartners wartet, wird gebraucht, weil es zur Zeit im
Agentensystem keine Abfragemöglichkeit gibt, welcher Konversationspartner zu agieren hat.
Außerdem wird eine Variable (empty) zur Anzeige benötigt, inwieweit der Eintrag in der
Konversationsliste noch belegt ist oder die Konversation bereits beendet wurde.
tbcwww
emptyDialogSpec :tbcSpec.DialogSpec
emptyDialog() :tbConv.Dialog
startWWWServer(...) :Ok
newConvList(...) :conversationsList.T
startRequest(...) :Ok
convToList(...) :Ok
newConvList
conversationsList
name :String
owner :wwwuid.T
findHtmlID(...) :Int
findConvID(...) :Int
findNextEmptyElement() :Int
setName(...) :Ok
getName() :String
setOwner(...) :Ok
getOwner() :wwuid.T
getConvListElement(...) :convListElements.T
setConvListElement(...) :Ok
getConvListElement
convListElements
conversation :agent.Conversaton
ownConvID :Int
htmlID :Int
actualServer :tbo.Server
waitServer :semaphore.T
active :Bool
inUse :Bool
actualDialog :tbConv.Dialog
requestValue :String
setConversation(...) :Ok
getConversation :agent.Conversation
setConvID(...) :Ok
getConvID() :Int
setHtmlID(...) :Ok
getHtmlID() :Int
setActualServer(...) :Ok
getActualServer() :tbo.Server
activateWaitServer() :Ok
releaseWaitServer() :Ok
isActiveWaitServer() :Bool
setActive() :Ok
resetActive() :Ok
isActive() :Bool
setInUse() :Ok
resetInUse(): OK
isInUse() :Bool
setActualDialog(...) :Ok
getActualDialog() :tbConv.Dialog
setRequestValue(...) :Ok
getRequestValue() :String
Abbildung 7.2: Konversationsliste
Die als nicht mehr belegt (empty) markierten Einträge können entweder für die nächste neue
Konversation verwendet werden oder ausgewertet werden, falls eine Übersicht über die beendeten
Konversationen erstellt werden soll. Für die Abspeicherung der Konversationsliste kann z.B. eine
Arraystruktur, eine Hash-Tabelle, eine Iteration oder ein Dictionary verwendet werden. Für den
Prototyp wurde eine Arraystruktur zugrunde gelegt.

76 7. Realisierung der Visualisierungskomponente
7.3 Verbindungsablauf
Für die Visualisierung wird ein Visualisierungsthread (TBO-Thread) pro Agent gestartet. Das
Starten des Threads erfolgt in der birth-Methode des Agenten im Anschluß an die Definition der
für die Visualisierung notwendigen Objekte.
Im TBO-Thread werden der Kommunikationsport und der Pfad des cgi-bin-Verzeichnisses gesetzt.
Danach wird der Visualisierungsserver (TBO-Server) gestartet. Dieser ist, wie in Abschnitt 6.5
erklärt, für das Empfangen der Nachrichten vom HTTP-Client erforderlich. Durch das Beenden des
TBO-Servers wird auch der TBO-Thread beendet.
Sendet der Kunde mit dem HTTP-Client eine URL an den Agenten, so wird beim Agenten eine
TBO-Aktion ausgeführt. In dieser Aktion wird die URL ausgewertet und danach ein Dialog mit
einer Anfrage an den Dienstleister abgesandt. Die TBO-Aktion kann jetzt aber noch nicht beendet
werden, weil, bedingt durch die Realisierung der TBOs, sonst eine leere Seite an den HTTP-Client
gesendet würde. Deshalb wird die Ausführung der TBO-Aktion mit Hilfe einer Semaphore
unterbrochen. Sobald der zur Anfrage gehörende Dialog des Dienstleisters empfangen wurde, wird
dieser in HTML umgesetzt und der HTML-Code an den HTTP-Client gesandt. Danach wird die in
der TBO-Aktion aktive Semaphore deaktiviert, so daß die TBO-Aktion beendet werden kann.
Kunde
Dienstleister
HTTP
Client
TBO
Server
Thread
TBO
Action
TBO
User
Objekt
Hauptthread
Kundenthread
Hauptthread
Dienstleisterthread
Abbildung 7.3: Verbindungsablauf zur Visualisierung
Beim Beenden der TBO-Aktion wird an den obigen HTTP-Client eine leere HTML-Seite
zurückgesandt. Doch da bereits vorher der Dialog als HTML-Seite abgesandt wurde, wird die
zweite Seite vom HTTP-Client nicht mehr beachtet.

7.3. Verbindungsablauf 77
Im Unterschied zur Visualisierung einer Konversation beim Kunden werden beim Dienstleister nur
Dialoge versandt. Bei der reinen Visualisierung besteht aber kein Unterschied.
Der oben geschilderte Ablauf einer Visualisierung soll im folgenden weiter konkretisiert werden.
Auf eine Anfrage hin schickt der Dienstleister einen Dialog an den Kunden. Das Abschicken des
Dialoges wird im Dienstleisterthread ausgelöst. Der Hauptthread verpackt den Dialog in einer ITC-
Nachricht. Er fügt u.a. die interne ID hinzu, die diese Konversation beim Kunden hat. Beim
Kunden wird die Nachricht durch den Hauptthread empfangen. Dieser entnimmt den Dialog aus
der Nachricht und veranlaßt beim Kundenthread die Ausführung der zu diesem Dialog gehörenden
Regel. Die Kundenregel setzt in der in Abschnitt 7.1 näher erläuterten Verwaltungsstruktur der
Konversationen die entsprechenden Werte. Da auf die Konversations-ID innerhalb der Regeln
inzwischen zugegriffen werden kann, ist es möglich, sie für die Adressierung der Konversation in
der Liste zu verwenden. Vorher war es notwendig, die Speicheradresse der Spezifikation der
aktuellen Konversation zu verwenden, um das entsprechende Element der Konversationsliste zu
finden. Nach dem Setzen der Werte werden die im Dialog enthaltenen Werte der TBC-Datentypen
in TBO-Datentypen übertragen. Der Dialog selber wurde bereits vorher beim Kunden im TBO-
System als tbo.user-Objekt definiert und hat dabei den Namen "ersteintrag" erhalten. Mit dem
Befehl tbo.exportObject(s ersteintrag) ist das Objekt dem TBO-Server bekanntgemacht worden.
Zusätzlich zu den im Dialog definierten Variablen enthält das tbo.user-Objekt eine HTML-ID, die
als verborgenes Formularfeld dargestellt wird. Nunmehr wird die display-Funktion für das
tbo.user-Objekt (z.B. ersteintrag.display) aufgerufen. Das tbo.user-Objekt, welches im
wesentlichen aus einer Reihe von display-Anweisungen für TBO-Werte besteht, greift für die
Visualisierung auf die oben gesetzten TBO-Werte zu. Durch diesen Funktionsaufruf wird für den
Dialog mit den enthaltenen Daten HTML-Code generiert und an den HTTP-Client gesendet. Dort
werden die Daten visualisiert. Die Semaphore, welche die oben geschilderte Visualisierung einer
leeren Seite durch die TBO-Aktion blockiert hatte, wird danach von der Kundenregel wieder
freigegeben. Wird die Regel nicht bis hierhin ausgeführt, weil z.B. die Visualisierung scheitert, so
wird auch die Semaphore nicht wieder freigegeben.
Hiernach wird die Ausführung der Kundenregel beendet, ohne eine Antwort an den Dienstleister zu
senden. Das Beenden der Kundenregel ist notwendig, weil eine Unterbrechung der Kundenregel
z.B. mit Hilfe einer Semaphore während auf die Benutzereingabe gewartet wird, zu einem
zeitweiligen Stillstand des Kundenthreads führen und die Atomarität der Regeln verletzen würde.
Dieses muß aus den in Abschnitt 6.5 genannten Gründen vermieden werden. Eine Antwort an den
Dienstleister kann noch nicht zurückgesandt werden, weil diese von der Benutzereingabe abhängig
ist. Deshalb darf die Regel nicht durch einen request beendet werden, sondern muß durch den
Aufruf der Funktion deferredRequest() abgeschlossen werden.
Im Formular, das im Browser visualisiert wird, können nun durch den Benutzer Werte geändert
werden. Damit die so eingegebenen Daten abgeschickt werden können, muß der Benutzer eine
Schaltfläche betätigen. Dadurch wird eine URL, in der die neuen Werte enthalten sind, zurück an
den TBO-Server gesandt.

78 7. Realisierung der Visualisierungskomponente
HTTP-Client hat
HTML-Seite
dargestellt
HTTP-Client und
Agent sind
gestartet
HTML-Darstellung des Dialoges
an den HTTP-Client
URL an TBO-Server
URL
Kunde hat
Dialog erhalten
TBO-Aktion wird
ausgeführt
Dialog vom Dienstleister
Anfrage an
Dienstleister
gesandt
Anfrage und Dialog
zum Dienstleister
warten
[Dialogdarstellung an
HTTP-Client gesendet]
finaler Dialog
TBO-Aktion
beendet
Kunde hat finalen
Dialog erhalten
HTML-Darstellung des Dialoges
an den HTTP-Client
Finaler Dialog
wurde angezeigt
Abbildung 7.4: Zustandsdiagramm der Visualisierung beim Kunden
Basierend auf den Inhalten der URL wird durch den TBO-Server beim Kunden eine TBO-Aktion
ausgelöst. Zuerst wird über die HTML-ID die zugehörige Konversation aus der Liste der
Konversationen herausgesucht. Danach werden die Werte aus den TBO-Datentypen in den
entsprechenden Dialog dieser Konversation übertragen. Nach der Werteübertragung wird mit der
Funktion request(Kundenkonversation Anfragename) die Anfrage ausgelöst, die bewirkt, daß der
Dialog und die zugehörige Anfrage an den Dienstleister zurückgesandt werden. Hiernach wird, um
einem Beenden der TBO-Aktion entgegenzuwirken, die oben erwähnte Semaphore gesetzt. Der
Dienstleister erhält den Dialog und die Anfrage. Er reagiert entsprechend und schickt den nächsten
Dialog.

7.3. Verbindungsablauf 79
Da der menschliche Dienstleister vom Beginn einer Konversation nicht automatisch benachrichtigt
werden kann, weil der HTTP-Client die Daten aktiv anfordern muß, erfährt er von einer neuen
Konversation nichts. Sobald sich der Dienstleister seine Konversationsübersicht anzeigen läßt, wird
er von der neuen Konversation informiert. Die darauf folgende Visualisierung der Dialoge verläuft
bis auf zwei Funktionsaufrufe analog zu der Visualisierung auf der Kundenseite. Beim
Dienstleister hat die Funktion, die eine Regel beendet ohne einen Dialog abzusenden, den Namen
deferedDialog(). Das dann erforderliche Absenden des Dialoges erfolgt mit
reply(Dienstleisterkonversation Dialog).
7.3.1 Starten von Konversationen
Wie in Abbildung 7.4 gezeigt, muß eine Semaphore verwendet werden, um die Abarbeitung der
TBO-Aktion zu unterbinden, bis die Visualisierung des Folgedialogs durch die Regel erfolgt ist.
Danach ist es notwendig, diese Semaphore wieder freizugeben, um die TBO-Aktion zu beenden.
Dieses ist auch beim Starten von Konversationen der Fall. Bedingt durch den Ablauf beim Starten
von Konversationen im Agentensystem, kann eine beginnende Konversation vor dem initialen
Dialog noch keinen Eintrag in der Konversationsliste besitzen. Erst wenn der initiale Dialog
empfangen wurde, können die entsprechenden Werte in der Konversationsliste gesetzt werden. Es
muß also eine Adresse festgelegt werden, unter der die o.g. Semaphore zu finden und nach der
Visualisierung des initialen Dialoges freizugeben ist. Diese Adresse ist 0.
Da nur eine derartige ID existiert, muß der erste Dialog vor dem Starten der nächsten Konversation
bearbeitet worden sein. Erst danach können neue Konversationen auf die Semaphore 0 zugreifen
und damit gestartet werden.
7.3.2 Migration
Bei einer Migration des Agenten ist darauf zu achten, daß die Kommunikation des Benutzers mit
dem Agenten nicht unterbrochen wird. Da der TBO-Thread bei einer Migration nicht wie die
Agententhreads an den neuen Ort gesendet werden kann, ist zu prüfen, bei welcher Art von
Migration die Verbindung zum TBO-Thread verlorengeht. Hierfür sind drei Arten der Migration zu
unterscheiden:

80 7. Realisierung der Visualisierungskomponente
• Ortswechsel innerhalb der Domäne
• Domänenwechsel auf einem Rechner
• Migration über Rechnergrenzen hinweg
Wechselt ein Agent den Ort innerhalb einer Domäne, ist keine weitere Aktion für die
Visualisierung notwendig. Der bisherige Visualisierungsthread kann weiterhin benutzt werden.
Wechselt ein Agent die Domäne, bleibt aber auf dem aktuellen Rechner, so ist es nicht unbedingt
erforderlich, einen neuen Visualisierungsthread in der neuen Domäne zu starten. Der bisherige
Visualisierungsthread kann weiterhin verwendet werden. Wird jedoch die alte Domäne durch das
Beenden des die Domäne beinhaltenden Tycoonsystems aufgelöst, so wird damit auch der in
diesem Tycoonsystem gestartete Visualisierungsthread beendet. Die Verbindung des Benutzers zu
seinem Agenten geht verloren. Migriert der Agent auf einen anderen Rechner, so geht in jedem Fall
die Verbindung zum Visualisierungsthread verloren. Es ist dann notwendig, den
Visualisierungsthread vor der Migration in eine andere Domäne oder zu einem anderen Rechner zu
beenden, weil sonst ein nutzloser Thread weiterlaufen würde.
Der Visualisierungsthread wartet an einem Port auf ankommende Nachrichten (siehe Abschnitt
5.1). Intern ist dieses über eine Socketkommunikation realisiert. Um den Visualisierungsthread zu
beenden, muß zuerst die tbo.stopServer()-Methode ausgeführt werden. Hierdurch wird das
Abbruchkriterium für die Schleife gesetzt, innerhalb derer der Visualisierungsthread den Socket
abfragt. Aber erst nach dem Empfang einer Nachricht wird das Schleifenende erreicht. Das Zeichen
"|" symbolisiert für den Visualisierungsthread das Ende einer Nachricht. Es ist daher notwendig,
dieses Zeichen einmal an den Port zu senden, um den Thread zu beenden.
Das Herunterfahren des Servers kann in die leave-Methode eingebunden werden, weil diese
Methode beim Verlassen des Ortes aktiviert wird. Nach der Migration muß dem Agenten ein neuer
Port zugewiesen werden, damit der Visualisierungsthread an diesem Port wieder gestartet werden
kann. Die Portzuweisung kann in einer neuen Konversation geschehen. Der Start dieser
Konversation kann Bestandteil der enter-Methode sein, die beim Betreten eines Ortes ausgeführt
wird.
Für die Zuweisung einer Portnummer muß es einen Agenten geben, der die Ports zumindest
domänenweit verwaltet. Dieses kann entweder der dedizierte Agent der Domäne (Rootplace) sein,
der Ortswächter selber oder auch ein spezieller Agent pro Rechner, der die Ports für alle Domänen
eines Rechners verwaltet. Für eine domänenweite Portverwaltung sollte der Portverwaltungsagent
im Rootplace der Domäne ansässig sein. Da auf einem Rechner mehrere Domänen existieren
können, ist eine zentrale domänenübergreifende Portverwaltung vorzuziehen. Nach der Zuweisung
einer Portnummer wird ein neuer Visualisierungsthread gestartet.
7.3.3 Übertragung der Daten
Die Übertragung der Daten zwischen den TBCs und den TBOs erfolgt an zwei Stellen. In den
Regeln der Agenten werden die Daten der TBCs in TBOs umgesetzt. Vor dem Auslesen der Daten
aus den TBC-Objekten müssen die entsprechenden TBO-Objekte erstellt worden sein (siehe

7.4. Synchrone und asynchrone Kommunikation 81
Abschnitt C.11). Mit let kredithoehe_html = tbo.int() wird beispielsweise ein Integerobjekt erstellt.
Das Auslesen der Daten aus den Dialogen geschieht mit Hilfe der get()-Funktion. Die folgende
Zeile überträgt den Wert aus dem TBC-Objekt in das entsprechende TBO-Objekt.
kredithoehe_html.val :=
conv.c.currentDialog.content1("Kredithoehe")!int.get()
Die Übertragung der im HTTP-Client eingegebenen Werte an den aktuellen Dialog erfolgt in der
TBO-Aktion. Für das TBC-Objekt ist hierzu die set() Funktion notwendig. Im folgenden wird ein
Wert in ein Inhaltsobjekt des aktuellen Dialoges übertragen.
conv.c.currentDialog.content1("Kredithoehe")
!int.set(kredithoehe_html.val)
Die Umsetzung der Objekte muß für jedes Inhaltsobjekt einzeln durchgeführt werden. Dadurch
wird der Programmkode für jeden Agenten stark erweitert. Eine Lösung hierfür ist eine dynamische
Visualisierung, auf die im Ausblick und in Abschnitt 4.7 näher eingegangen wird.
7.4 Synchrone und asynchrone Kommunikation
Eine synchrone Verbindung ist dadurch gekennzeichnet, daß nach dem Absenden der Anfrage auf
die Antwort gewartet und diese Zeit nicht durch andere Aktionen unterbrochen wird. Es muß
hierbei für die Visualisierung die ganze Zeit ein Browserfenster geöffnet bleiben. Der Computer
darf weder heruntergefahren, noch darf aus diesem Fenster eine andere Konversation gestartet oder
eine andere Aktion durchgeführt werden.
Aus diesen Einschränkungen ist ersichtlich, daß eine derartige Verbindung eher der Einzelfall sein
wird. Nur bei einer schnellen Verbindung eines Menschen zu einer Maschine, bei der in der Regel
Wartezeiten von weniger als 5 Sekunden auftreten, wird sie als annehmbar empfunden.
Das TBO-System ist für synchrone Verbindungen ausgelegt. Es sind deshalb bei der Realisierung
keine Besonderheiten zu beachten.
In den Tests der synchronen Verbindungen waren die Wartezeiten nicht länger als zwei Sekunden.
Diese Zeiten wurden im wesentlichen durch die Auslastung des TBO-Servers und des Netzes
verursacht. Die durchschnittliche Wartezeit vom Abschicken der Anfrage bis zum Ende der
Visualisierung der Antwort blieb unter einer Sekunde. Zu berücksichtigen ist hier allerdings, daß
keine zeitraubenden Berechnungen durchgeführt wurden.

82 7. Realisierung der Visualisierungskomponente
Abbildung 7.5: Konversationsübersicht
Für die Realisierung der asynchronen Kommunikation wird die Verwaltung der Konversationen
(siehe Abschnitt 7.1) verwendet. Aus der Konversationsliste wird mit Hilfe eines tbo.user-Objektes
eine Übersicht generiert und angezeigt. Die in Abbildung 7.5 gezeigte Übersicht enthält sowohl
aktive als auch inaktive Konversationen. Ein Darstellung nur der aktiven oder inaktiven
Konversationen ist ebenfalls abrufbar (siehe Abbildung 7.1). Durch Betätigung der Schaltfläche
Dialog anzeigen wird der aktuelle Dialog der Konversation visualisiert.

7.5. Erweiterungen der Tycoon Business Objects 83
Die Realisierungen sowohl der Übersicht als auch des Hauptmenüs (siehe Abschnitt 7.1) basieren
auf den Möglichkeiten des TBO-Systems. Es werden hierfür keine Funktionen des Agentensystems
benutzt.
7.5 Erweiterungen der Tycoon Business Objects
Um den Anforderungen an die darstellbaren Datentypen (siehe Abschnitt 4.3) zu genügen, wurden
die TBOs um den Datentyp Real erweitert. Außerdem wurde der Datentyp HiddenInt eingeführt,
der für die Darstellung der HTML-ID gebraucht wird. Ebenso war es erforderlich, den Datentyp
des TBO-Servers um die Angabe des Visualisierungsslots zu erweitern.
Das HTML-Modul und Interface der TBOs wurde u.a. um Funktionen zur Darstellung von
Tabellen, Grafiken und grafisch hinterlegten Hyperlinks erweitert.
7.6 Vorarbeiten für die dynamische Visualisierung
Um eine dynamische Visualisierung zu ermöglichen, war es notwendig, das bisherige starre
Regelsystem des Agentensystems etwas aufzuweichen. Im bisherigen Regelsystem ist bei den
Kunden für jeden ankommenden Dialog maximal eine Regel definiert. Ebenso ist beim
Dienstleister für jede ankommende Anfrage eine Regel festgelegt. Bisher blockiert der
Kundenthread, sobald innerhalb einer Nachricht ein Dialog empfangen wird, dem keine Regel
zugeordnet werden kann. Dieses kann z.B. bei einer unvollständigen Ausprogrammierung des
Agenten oder auch nach einer Anfrage vorkommen, die unter Nutzung des ellipses-Attributes
(siehe Abschnitt 2.3.4) spezifiziert wurde. Der Dienstleisterthread bleibt stehen, wenn eine Anfrage
an den Dienstleister gesandt wird, für die keine Regel vorhanden ist.
Da in dem in Abschnitt 4.7 geschilderten dynamischen Visualisierungssystem nicht für jeden
Dialog oder jede Anfrage eigene Regeln vorhanden sein sollen, wurde eine HTML- und eine
default-Regel implementiert. Die HTML-Regel ist zur Visualisierung der Dialoge gedacht. Die
default-Regel wurde implementiert, um Fehler abfangen und analysieren zu können. Wenn für
einen Dialog oder eine Anfrage keine Regel vorhanden ist, wird automatisch die HTML-Regel
ausgeführt, die diesen Dialog visualisiert. Ist auch diese nicht vorhanden, wird die default-Regel
ausgeführt. Ist auch die default-Regel nicht vorhanden, so bleibt der entsprechende Thread, wie
auch zuvor, an dieser Stelle stehen.
Um beim Dienstleister die Anfragen auswerten zu können, muß der Name der aktuellen Anfrage
bekannt sein (siehe Abschnitt 3.5). Das TBC-System ist nur in der Lage, den Namen des aktuellen
Dialoges mit allen in ihm enthaltenen möglichen Anfragen zu liefern (siehe Abschnitt 4.7). Die
aktuelle Anfrage kann jedoch nicht abgefragt werden. Deshalb wurde das System um eine
entsprechende Funktionalität erweitert. Durch diese Implementierungen ist es jetzt möglich, die
statischen Regeln eines Agenten mit einer dynamischen Visualisierung zu kombinieren. Der Agent
kann weiterhin aufgrund seiner Regeln handeln. In den Fällen aber, in denen keine Regel
vorhanden ist, kann der betreffende Dialog automatisch visualisiert werden.

85
8. Kapitel
Zusammenfassung und Ausblick
Das Ziel dieser Arbeit war es, Vorarbeiten für eine Visualisierungskomponente des auf dem Modell
der Business Conversations aufbauenden Agentensystems zu leisten und einen Prototyp zu
entwickeln. Dazu wurden das Agentensystem analysiert, Voraussetzungen benannt, mögliche
Visualisierungsansätze dargestellt und Lösungswege aufgezeigt. Außerdem wurden die für eine
dynamische Visualisierung notwendigen Voraussetzungen festgestellt und das Agentensystem
getestet.
8.1 Zusammenfassung
Mit dieser Arbeit wurde eine Analyse für die Visualisierung durchgeführt und eine Möglichkeit
geschaffen, die Daten der Tycoon Business Conversations mit Hilfe eines HTTP-Clients
anzuzeigen und zu ändern. Hierfür stehen je nach Datentyp verschiedene Möglichkeiten zur
Verfügung. Es lassen sich sowohl atomare als auch komplex strukturierte Datentypen wie z.B.
variante Tupel anzeigen. Dabei besteht die Möglichkeit, die Daten in einfachen Eingabefeldern,
komplexen Strukturen, Tabellen, Unterfenstern und Frames anzuzeigen.
Außerdem ist es möglich, die Aktionen, die in den TBCs den Übergang von einem Dialog zum
nächsten darstellen, zu visualisieren. Diese Aktionen können als Schaltflächen, Hyperlinks und
Grafiken mit Hyperlinks dargestellt werden. Standardmäßig werden sie als Schaltflächen
dargestellt.
Im Hinblick auf eine Visualisierung wurde das Agentensystem analysiert. Aufbauend auf den
Ergebnissen dieser Analyse wurden die Anforderungen an die Visualisierung definiert. Um diese
Anforderungen erfüllen zu können, wurde das System der Tycoon Business Objects analysiert und
verwendet. Es wurde um die notwendigen Datentypen und Funktionen ergänzt.
Daran anschließend wurden mehrere Möglichkeiten, die Visualisierungskomponente zu
implementieren, einander gegenübergestellt. Die Visualisierungskomponente wurde als statischer
Prototyp in das Agentensystem eingebunden.
Mehrere Beispielanwendungen, die unter anderem die Leistungsfähigkeit der Visualisierung im
Zusammenspiel mit anderen Entwicklungen [BM97, Krus97] beweisen, wurden realisiert.

86 8. Zusammenfassung und Ausblick
Die Inhaltsobjekte und Anfragen der Dialoge einer Konversation können sowohl auf der Kundenals
auch auf der Dienstleisterseite dargestellt und bearbeitet werden. Außerdem können Zusatzinformationen
z.B. zur Benutzerführung in die Darstellung der Dialoge integriert werden.
Mit der Visualisierungskomponente ist es möglich, sowohl synchrone als auch asynchrone
Kommunikationen anzuzeigen. Um die Konversationen verwalten zu können, ist eine Übersicht
über alle Konversationen notwendig. Weil ein Zugriff auf die im Agenten vorhandene Liste nicht
ohne größere Eingriffe zu realisieren war, mußte für die Visualisierung bei jedem Agenten eine
Übersicht der Konversationen aufgebaut werden.
Da eine statische Visualisierung gerade bei varianten oder Massendatenstrukturen sehr aufwendig
ist, wurde das Agentensystem daraufhin analysiert, ob es eine dynamische Visualisierung zuläßt.
Hierbei wurde festgestellt, daß das System in der Regelausführung um einige Attribute und um die
auf diesen Attributen aufbauende Funktionalität erweitert werden mußte. Diese Erweiterungen
wurden durchgeführt, so daß für eine dynamische Visualisierung keine weiteren Änderungen des
Agentensystems notwendig sind.
Für die dynamische Darstellung der TBCs wurde ein System von Visualisierungsvorlagen
konzipiert, das eine Möglichkeit bietet, semantisches Wissen und Funktionalitäten der
Benutzerführung während der dynamischen Visualisierung zu nutzen.
Die bisher erstellten Module können für die Entwicklung einer generischen Visualisierung genutzt
werden. Ebenso ist es möglich, die vorhandenen Funktionalitäten in einem zentralen
Visualisierungsagenten zu integrieren.
Durch die Implementation der Visualisierung werden die Funktionen des Agentensystems in keiner
Weise beeinträchtigt. Die Agenten kommunizieren weiterhin über das Nachrichtensubsystem und
haben die Möglichkeit zu migrieren.
Das Modell der Business Conversations und das Agentensystem haben sich während der Arbeit als
gute Basis erwiesen. Wünschenswerte Erweiterungen wären der Zugriff auf die im Agenten
vorhandene Konversationsliste und die Realisierung von multimedialen Datentypen in den
Business Conversations.

8.2. Ausblick 87
8.2 Ausblick
Die entwickelte Visualisierungsumgebung kann in mehrere Richtungen weiterentwickelt werden.
Diese Richtungen lassen sich grundsätzlich den TBCs, den TBOs und der dynamischen
Visualisierung zuordnen.
Die Tycoon Business Conversations können, damit sie den heutigen Anforderungen im World
Wide Web entsprechen, um multimediale Datentypen wie Grafik, Videos und Klangobjekte
ergänzt werden.
Um nicht in jeden Agenten die Verwaltung seiner Konversationen implementieren zu müssen,
sollte das Agentensystem so erweitert werden, daß im Kunden- und Dienstleisterthread die
Informationen der Konversationsliste, die Auskunft über die derzeit laufenden Konversationen des
einzelnen Agenten gibt, verfügbar sind. Aufgrund der Kapselung der Threads des Agentensystems
existiert derzeit keine Zugriffsmöglichkeit auf diese Informationen. Nach Konversationsende
werden die mit der Konversation zusammenhängenden Daten aus der Konversationsliste gelöscht.
Es gibt keine Möglichkeit im Agentensystem, eine Liste der beendeten Konversationen zu
erzeugen. Auf bereits beendete Konversationen läßt sich durch Nutzung eines Archivs [Krus97]
zugreifen.
Da die Konversationsspezifikationen eine einfache Struktur aufweisen, bietet es sich an, ein
Produkt zu entwickeln, das die Möglichkeit bietet, die Spezifikationen mit einer graphischen
Oberfläche zu erstellen. Eine andere Möglichkeit, die von Ripp [Ripp98] in seiner Arbeit
aufgezeigt wird, ist die Darstellung der Dialoge mit HTML-Editoren festzulegen und diesen Kode
für die Erstellung der Spezifikationen zu nutzen. Hierfür sind im TBO-System die Funktionen
setFieldName() und newObjectName() so zu erweitern, daß vom Entwickler vorgegebene
Feldnamen für die Visualisierung der einzelnen Objekte benutzt werden können. Zur Zeit werden
intern erzeugte Objektnamen verwendet.
Aufbauend auf den Konversationsspezifikationen kann ein Tool entwickelt werden, das in
Interaktion mit einem Entwickler aus einer Konversationsspezifikation ein Agentengerüst generiert.
Die Inhalte der einzelnen Regeln des Agenten müssen hierbei durch den Entwickler ausformuliert
werden.
Damit bei der Entwicklung der Agenten nicht auch alle Visualisierungsfunktionen mit erstellt
werden müssen, sollte ein externer Visualisierungsserver realisiert werden. Aufgrund der
Komplexität der Visualisierung, für einen einfachen Agenten mit Visualisierungsfunktionen sind
ca. 500 Programmzeilen nötig, würde eine in den Agenten integrierte Visualisierung die
Entwicklung einer grafischen Oberfläche zur Agentenerstellung sehr erschweren.
Mit einem externen Visualisierungsagenten kann der Programmablauf losgelöst von der
Visualisierung entwickelt werden. Wird die Definition und Erstellung der Agenten durch die
Visualisierungskomponente nicht beeinflußt, so ist es bei der Entwicklung der einzelnen Agenten
unerheblich, welche Art der Visualisierung (E-Mail, EDI, HTTP-Client, etc.) letztlich gewählt
wird.

88 8. Zusammenfassung und Ausblick
Wenn der externe Visualisierungsagent zentral realisiert wird, kann die Realisierung so erfolgen,
daß die Visualisierungsaufträge bei einem hohen Auftragsvolumen automatisch auf mehrere
Visualisierungsagenten verteilt werden. Dieses kann entweder eine Funktionalität sein, die in den
einzelnen Visualisierungsagenten eingebaut ist, oder die Visualisierungsagenten können von einem
Verteileragenten bedient werden.
Bei einer außerhalb der Agenten angesiedelten Visualisierung sind die in Abschnitt 6.4
beschriebenen Änderungen des Agenten- und des Nachrichtensubsystems erforderlich. Um in
diesen externen Visualisierungsagenten nicht für jede Konversation die Funktionen zur Darstellung
und Nutzung der Objekte selbst programmieren zu müssen, sollte eine dynamische Lösung angestrebt
werden.
Für die dynamische Visualisierung bietet es sich an, die Visualisierungsvorlagen (siehe Abschnitt
4.8) zu realisieren, um semantische und Zusatzinformationen bei der Darstellung von Objekten
nutzen zu können. Die Definition der Datenstruktur zur Abspeicherung der o.g. Informationen in
den Visualisierungsvorlagen ist noch festzulegen. Hier kann u.a. durch die Weiterentwicklung und
Implementierung der Cascading Style Sheets in den HTTP-Clients noch geforscht werden. Die
Datenstrukturdefinition müßte mit einer prototypischen Realisierung der dynamischen
Visualisierung verbunden werden.
Da die manuelle Erstellung der grafischen Repräsentation von Dialogen mittels Visualisierungsvorlagen
sehr zeitintensiv ist und viel Programmtext erfordert, sollte ein Produkt erstellt werden,
das den Entwickler bei der Konstruktion von Visualisierungsschnittstellen unterstützt. Dieser kann
über eine Reihe von Diensten verfügen, die grafische Grundfunktionalitäten bereitstellen. Der
Entwickler muß dann noch die für seine Anwendung notwendigen Elemente miteinander
verbinden.
Wird ein Objekt zur selben Zeit an mehreren Stellen dargestellt, so ist ein erhöhter Verwaltungsaufwand
nötig, um die Konsistenz der Daten sicherzustellen. Bei einer Änderung der Daten
des Objektes müßten alle anderen Darstellungen dieses Objektes automatisch aktualisiert werden.
Mit der alleinigen Verwendung von HTML ist dieses aufgrund der Möglichkeiten von HTML nicht
möglich. Durch die Nutzung von Programmiersprachen wie Java kann dieses Problem gelöst
werden. Ebenso sind Erweiterungen der Visualisierungsmöglichkeiten denkbar. Es könnten z.B.
Menüstrukturen über Image Maps realisiert werden.
Der Prototyp des Agentensystems sollte letztlich so erweitert werden, daß die Migration von
Agenten auch innerhalb von Regeln möglich ist. Dadurch könnten Agenten basierend auf den von
ihnen ausgeführten Aktionen migrieren. Außerdem sollte die Möglichkeit der mehrfachen
Migration von und zu einem Ort sichergestellt werden. Im derzeitigen Prototyp des Agenten kann
es dazu kommen, daß nach einer mehrfachen Migration die im Agenten vorhandenen Regeln nicht
ausgelöst werden.
Um zu verhindern, daß bei der Darstellung der Dialoge blockierende Zustände erreicht werden,
sollte bei der Visualisierung auf den Einsatz von Unterbrechungsvariablen verzichtet werden.
Hierzu muß das TBO-System so angepaßt werden, daß Semaphoren nicht mehr benötigt werden.
Zu diesem Zweck muß die Abarbeitung der Aktionen geändert werden. Dazu könnte u.a. die
dispatch-Methode geändert werden.

8.2. Ausblick 89
Damit nicht jeder Benutzer im Fenster des HTTP-Clients mitlesen kann, welche Inhalte an den
Server übermittelt werden, ist es notwendig, die Übermittlungsart für Formularinhalte auf die post-
Methode umzustellen. Mit der gegenwärtig verwendeten get-Methode kann nur eine beschränkte
Zeichenanzahl auf einmal übermittelt werden. Dieses bedeutet bei Massendaten eine große
Einschränkung.
Parallel zur Entwicklung der BCs in Tycoon wird das Agentensystem in Tycoon-2 implementiert.
Es ist zu überlegen, ob die Weiterentwicklung der Visualisierung der Business Conversations nicht
besser in dieser Programmiersprache erfolgen sollte, weil die dort zur Verfügung stehenden
Möglichkeiten, Objekte in HTTP-Clients darzustellen, die Fähigkeiten von Tycoon bei weitem
übersteigen.
Es fehlen bisher Konzepte zur Modellierung von zusammenlaufenden Konversationen. Ein
Beispiel dafür ist das folgende Szenario: Zwei Mitarbeiter derselben Firma geben unabhängig
voneinander Bestellungen auf. Sie bemerken dies während der Bearbeitung. Wie ist es möglich,
diese zwei getrennten Konversationen zu einer zusammenzuführen, ohne die entstandenen Daten
zu verlieren? Das bisherige Konzept der Konversationen sieht ein Zusammenführen von
Konversationen nicht vor.
Die Erweiterung der Tycoon Business Conversations um ein Rollenmodell steht ebenfalls aus.
Mittels eines solchen Modells kann ein Benutzer eine Konversation beginnen und ein anderer, der
im Unternehmen in derselben Rolle tätig ist, diese Konversation fortführen, ohne sie ausdrücklich
übertragen zu bekommen. Da kein Rollenmodell existiert, kann keine Konversationsinstanz
gleichzeitig von mehreren Benutzern verwendet werden.

91
Anhang A
Glossar
A.1 Glossar der Agententerminologie
Domäne (domain): Eine Komponente, die Orte und Agenten beherbergt und verwaltet. Domänen
sind symbolisch adressierbar und besitzen immer mindestens einen Ort, welcher die Domäne
selbst repräsentiert.
Aktivität (activity): Eine Aktivität ist eine beliebige Aufgabe, die durch einen oder mehrere
Agenten modelliert wird. Dabei können Aktivitäten über Adressräume verteilt sein.
Mobiler Software-Agent (mobile agent): Ein mobiler Software-Agent ist eine Komponente,
welche aus einer oder mehreren aktiven Einheiten besteht. Ein Agent ist Teil mindestens
einer Aktivität. Mobile Agenten sind in der Lage, sich über Adressraumgrenzen zu bewegen.
Agenten kommunizieren untereinander über typisierte Nachrichten.
Kommunikationsendpunkt (port): An einem Kommunikationsendpunkt empfängt eine aktive
Einheit Nachrichten. Es gibt benannte und anonyme Kommunikationsendpunkte. Eine aktive
Einheit kann einen benannten Kommunikationsendpunkt über dessen Adresse identifizieren
und Nachrichten an diesen senden. Ein anonymer Port kann nur Nachrichten von aktiven
Einheiten empfangen, die eine Objektbindung an den (privaten) Portidentifikator besitzt.
Portidentifikator (port identifier): Ein Portidentifikator ist ein weltweit eindeutiger Bezeichner,
der automatisch einem neu erzeugten Port zugewiesen wird. Alle Ports werden über
Nachrichtensubsysteme mittels dieses Identifikators referenziert.
Nachricht (message): Nachrichten sind typisierte Botschaften und werden über Ports ausgetauscht.
Es gibt einen definierten Satz von Nachrichten, welcher die Grundlage der
Kooperationsprotokolle auf Systemebene zwischen Agenten bilden.
Aktive Einheit (thread): Eine aktive Einheit ist in der Lage, eine Nachricht an eine andere (nicht
notwendigerweise verschiedene) aktive Einheit zu versenden.
Ort (place): Ein Ort ist ein Agent, der eine Domäne aufgabenspezifisch logisch untergliedert. Ein
Ort ist eine spezielle Form eines Agenten. Jeder Ort ist durch einen lokal zur Domäne

92 Anhang A. Glossar
eindeutigen Namen identifiziert. Orte können wiederum andere Orte und Agenten beinhalten
und bilden eine Hierarchie. Sie sind Sichtbarkeitsbereiche für die Adressierung von Agenten.
Treffen (meeting): Ein Treffen findet zwischen zwei Agenten innerhalb eines Ortes statt. Treffen
werden durch die Domäne vermittelt und koordinieren den Anfang einer Kooperation
zwischen Agenten, indem sie diese untereinander sichtbar machen.

93
A.2 Glossar der Business Conversations
Konversation (conversation): Der Oberbegriff für eine Folge von Dialogen zwischen einem
Kunden und einem Dienstleister, mit dem Ziel einer Aktion. Eine Konversation kann
einzelne (Teil-) Konversationen wiederverwenden.
Sprechakt (speech act): Ein Begriff aus der Language-Action Sicht auf CSCW nach T. Winograd
[FlWi+88]: „... human beeings are fundamentally linguistic beings: action happens in
language in a world constituted by language.''. Genauer werden Sprechakte in Zyklen von
vier Phasen unterteilt: Anfrage, Übereinkunft, Leistung und Rückmeldung. In einer
technischen Umsetzung des Modells wird ein Sprechakt als Konversation bezeichnet.
Phase (phase): Granularität des Sprechaktmodells. Die Einteilung in Phasen muß nicht in einer
Implementation widergespiegelt werden. Sie dient allein der Veranschaulichung des Ablaufs
von Sprechakten.
Anfrage (I) (request): Bezeichnung für Phase eins des Modells.
Anfrage (II) (request): Die Bearbeitung einer Anfrage führt im Modell in einen neuen Dialog.
Anfragen sind die einzige Möglichkeit in einer Konversation einen neuen Zustand zu
erreichen.
Übereinkunft (agreement): Bezeichnung für die zweite Phase des Modells.
Leistung (performance): Bezeichnung für die dritte Phase des Modells.
Rückmeldung (feedback): Bezeichnung für die vierte Phase des Modells.
Kunde (customer): Initiator einer Konversation. Innerhalb eines Sprechakts ist die Rolle des
Kunden festgelegt. Aus der Sicht einer übergeordneten Konversation kann der Kunde jedoch
gegenüber einem anderen Kunden wiederum in der Rolle des Dienstleisters auftreten.
Dienstleister (performer): Akzeptor einer Konversation. Innerhalb eines Sprechakts ist die Rolle
des Dienstleisters festgelegt. Aus der Sicht einer übergeordneten Konversation kann der
Dienstleisters jedoch gegenüber einem anderen Dienstleisters wiederum in der Rolle des
Kunden auftreten.
Akteur (Actor): Sowohl der Kunde als auch der Dienstleister nehmen aktiv (daher Akteur) an der
Konversation teil.

94 Anhang A. Glossar
Regel (Rule): Jeder Akteur führt Aktionen aus, die Regeln genannt werden. Der Dienstleister
reagiert aufgrund einer Anfrage gemäß einer zugehörigen Regel und erzeugt einen neuen
Dialog. Der Kunde wiederum reagiert auf den Dialog gemäß seinen eigenen Regeln.
Annahme (acceptance): Die ersten beiden Phasen eines Sprechaktzyklus.
Erfüllung (completion): Die letzten beiden Phasen eines Sprechaktzyklus.
Dialog (dialog): Ein Schritt einer Phase eines Sprechakts. Das Mittel des Dialogs ist nicht
bestimmt. Eine Phase kann beliebig viele Dialogschritte erfordern. Dialoge enthalten
strukturierte Information, ihren Inhalt.
Inhalt (content): Ein Teil eines Dialogs in Form eines inspizierbaren Bedeutungsträgers.
Modifikator (modifier): Mit Modifikatoren kann eine bestehende Konversation in Form einer Sub-
Konversation an die Erfordernisse der einbettenden Konversation angepaßt werden. Dialoge
der Sub-Konversation können konfiguriert, automatisiert oder ausgeblendet werden.
Historie (history): Die Historie bildet die gemeinsame Vergangenheit von Kunde und Dienstleister
innerhalb einer Konversation. Sie wird transparent vom System fortgeschrieben und enthält
alle relevanten Daten einer Konversation, insbesondere alle Anfragen und Dialoge. Sowohl
Kunde als auch Dienstleister haben vollständigen Zugang zu den gesammelten Daten, die
von beiden Seiten als verbindlich betrachtet werden.
Abbruch (breakdown): Ein Abbruch ist eine spezielle Anfrage an einen Dienstleister in einer
Fehlersituation. Diese Anfragen werden in der Regel vom System im Namen des Kunden an
den Dienstleister gestellt (z.B. bei einer Zeitüberschreitung des Kunden in einem Dialog).
Konversations-Stadium (conversation stage): Eine Konversation befindet sich immer in einem
definierten Stadium. Damit werden die Phasen des Sprechaktzyklus widergespiegelt.

95
Anhang B
Abkürzungen
ASCII
BC
CfA
CfP
CGI
CSCW
CSS
GUI
HTML
HTTP
ITC
OMT
TBC
TBO
URL
American Standard Code for Information Interchange
Business Conversations
Conversations for Action
Conversations for Possibilities
Common Gateway Interface
Computer Supported Cooperative Work
Cascading Style Sheets
Graphical User Interface, Grafische Benutzerschnittstelle
Hypertext Markup Language
Hypertext Transfer Protocol
Inter Thread Communication
Object Modelling Technique
Objektorientierter Ansatz zur Softwaremodellierung.
Tycoon Business Conversations
Tycoon Business Objects
Uniform Resource Locator

97
Anhang C
Ausgewählte Programmbeispiele zur
Visualisierung
C.1 Konversationsspezifikation Kreditvergabe
(* Kreditvergabe conversation specification: *)
let kreditDatenDialogSpec =
tbcSpec.dialogSpec("Kreditdaten" array
tbcSpec.requestSpec("absenden" array "Kreditangebot" end false)
tbcSpec.requestSpec("abbrechen" array "Kein Kredit" end false)
end
array
tuple "Kredithoehe" fun() tbcContent.intSpec() end
tuple "Laufzeit" fun() tbcContent.intSpec() end
tuple "Mitteilung" fun() tbcContent.stringSpec() end
end)
let kreditAngebotDialogSpec =
tbcSpec.dialogSpec("Kreditangebot" array
tbcSpec.requestSpec("annehmen" array "Kreditannahme" end
false)
tbcSpec.requestSpec("ablehnen" array "Kein Kredit" end false)
tbcSpec.requestSpec("Werte aendern" array "Kreditdaten" end
false)
end
array
tuple "Kredithoehe" fun() tbcContent.intSpec() end
tuple "Laufzeit" fun() tbcContent.intSpec() end
tuple "Zins" fun() tbcContent.realSpec() end
tuple "Tilgung" fun() tbcContent.intSpec() end
tuple "Mitteilung" fun() tbcContent.stringSpec() end
end)
let kreditannahmeDialogSpec =
tbcSpec.dialogSpec("Kreditannahme" array end
array

98 Anhang C. Ausgewählte Programmbeispiele zur Visualisierung
tuple "Mitteilung" fun() tbcContent.stringSpec() end
end)
let keinKreditDialogSpec =
tbcSpec.dialogSpec("Kein Kredit" array end
array
tuple "Mitteilung" fun() tbcContent.stringSpec() end
end)
let kreditConvSpec =
tbcSpec.new("Kredit" kreditDatenDialogSpec array
kreditDatenDialogSpec
kreditAngebotDialogSpec
kreditannahmeDialogSpec
keinKreditDialogSpec
end)
Initialer Dialog
Kreditdaten
Kreditbetrag
Laufzeit
Mitteilung
Kreditangebot
Kreditbetrag
Laufzeit
Zins
Tilgung
Mitteilung
Finale Dialoge
Kreditannahme
Mitteilung
Kein Kredit
absenden
abbrechen
annehmen
ablehnen
Werte ändern
Mitteilung
Abbildung C.1: Konversationsspezifikation Kreditvergabe

C.2. Konversationsspezifikation Portnummer holen 99
C.2 Konversationsspezifikation Portnummer holen
(* Portnummer holen conversation specification: *)
let takePortDialogSpec =
tbcSpec.dialogSpec("takePort" array end
array
tuple "Portnumber" fun() tbcContent.stringSpec() end
end)
let takePortConvSpec =
tbcSpec.new("takePortSpec" takePortDialogSpec array
takePortDialogSpec
end)
C.3 Regeldefinition
let wwwKreditPerformer = m.addPerformerRole(:Ok kreditConvSpec fun() ok)
let chefKreditCustomer = m.addCustomerRole(:Ok chefKreditConvSpec)
wwwKreditPerformer.set("Kreditdaten" "abbrechen"
fun(conv :agent.Conversation(Ok)) :tbConv.Dialog
begin
let d = conv.c.newDialog("Kein Kredit")
...
d
end)
chefKreditCustomer.set("chefKreditdaten"
fun(conv :agent.Conversation(Ok)) :String
begin
...
"chefAbsenden"
end)
C.4 Typdefinition von agent.Conversation
Let Rec Conversation(S

100 Anhang C. Ausgewählte Programmbeispiele zur Visualisierung
customerRole() :Bool
end
C.5 Datentypdefinition in TBCContent.ti
Let Rec Spec

C.8. Inhaltsobjekt eines Dialoges 101
C.8 Inhaltsobjekt eines Dialoges
tuple_case rcd of Spec with
let elements = fun() :iter.T(NamedContentSpec)
end :tbcContent.Spec
C.9 Generische Typermittlung
try
d.contentSpec()!rcd.elements().get().spec()?int
let variablenTyp = “int”
else
end
try
d.contentSpec()!rcd.elements().get().spec()?string
let variablenTyp = “string”
else
end
case variablentyp of
int ...
string ...
C.10 Tycoon Business Objects Seitenobjekt
let kreditDaten = tbo.user (tbo.htmlHead fun(s :Server v :String)
begin
htmlID.display(s v)
html.plain(s.page "Kredithoehe : ")
kredithoehe_html.display(s v)
html.newRow(s.page)
html.plain(s.page "Laufzeit : ")
laufzeit_html.display(s v)
html.newRow(s.page)
absenden.display(s v)
abbrechen.display(s v)
end)
tbo.setObjectName(kreditDaten "kreditDaten")
tbo.exportObject(s kreditDaten)

102 Anhang C. Ausgewählte Programmbeispiele zur Visualisierung
C.11 Tycoon Business Objects Datenobjekte
Konversationsspezifische Variablen
let kredithoehe_html = tbo.int()
let laufzeit_html = tbo.int()
let zins_html = tbo.real()
let tilgung_html = tbo.int()
let mitteilung_html = tbo.string()
Allgemeine Variablen
let htmlID = tbo.hiddenInt()
C.12 Tycoon Business Conversations Aktionsobjekt
let annehmen = tbo.action(fun(s :Server v :String) begin
activeConversations[htmlID.val].actualDialog.content1
("Kredithoehe")!int.set(kredithoehe_html.val)
activeConversations[htmlID.val].requestValue := "annehmen"
let requestConversation :agent.Conversation(Ok) =
optional.value(:agent.Conversation(Ok)
activeConversations[htmlID.val].actualConversation)
requestConversation.request(:Ok requestConversation
activeConversations[htmlID.val].requestValue)
semaphore.wait(activeConversations[htmlID.val].wartenServer)
end)
annehmen.val := "Kredit annehmen"

103
Literaturverzeichnis
[AH97]
[Aust62]
[Bach95]
[Blas90]
[BM97]
[Brow88]
[BW94]
[BW95]
[Catt91]
[CW85]
[DDJ+97]
[DHL90]
[EBB97]
Catherine A. Ashworth, David B. Hamilton. A Case for Frames. Conference
proceeding der 3rd Conference on Human Factors & the Web,
http://www.uswest.com/web-conference/proceedings/ashworth.html, 1997.
J. Austin. How to do things with words. Technical report, Oxford University Press,
Oxford, 1962.
Frank Bachmann. Entwicklung des multimedialen Beratungssystems MIDA zur
Gestaltung von Benutzeroberflächen unter software-ergonomischen
Gesichtspunkten. GMD-Studien 254, Gesellschaft für Mathematik und
Datenverarbeitung, Sankt Augustin , Deutschland, 1995. Zugleich : Diplomarbeit,
Universität Bonn, 1995.
A. Blaser (Hrsg.). Database Systems of the 90s, Lecture Notes in Computer
Science, Bd. 466. Springer--Verlag, Berlin u.a., 1990.
Thomas Benthien, Christian Martens. Prozeßorientierte Integration von Win32-
Anwendungen in offene Agentensysteme. Studienarbeit in Vorbereitung,
Fachbereich Informatik, Universität Hamburg, Deutschland, 1997.
M.H. Brown. Perspectives on Algorithm Animation. In: Proceedings of the ACM
CHI'88 Conference on Human Factors in Computing Systems, 1988
Russel Beale and Andrew Wood. Agent-Based Interaction. In People and
Computers IX, Proceedings of HCI'94, pages 239--245, August 1994.
Gerd Bremer and Jens Wahlen. Objektorientierte Datenmodellierung: Strukturierte
Generatoren zur Codeerzeugung. Studienarbeit, Fachbereich Informatik,
Universität Hamburg, Germany, February 1995.
R.G.G. Cattel, Next-Generation Database Systems. Communications of the ACM,
Jg. 34, 1991.
L. Cardelli, P. Wegner. On Understanding Types, Data Abstraction, and
Polymorphism. ACM Computing Surveys, Jg. 17 Nr. 4, 1985.
Giorgio De Michelis, Eric Dubois, Matthias Jarke, Florian Matthes, John
Mylopoulos, Mike Papazoglou, Klaus Pohl, Joachim Schmidt, Carson Woo, and
Eric Yu. Cooperative Information Systems: A Manifesto. In Mike P. Papazoglou
and Gunther Schlageter, editors, Cooperative Information System: Trends and
Directions. Academic Press, 1997.
U. Dayal, M. Hsu, and R. Ladin. Organizing Long-Running Activities with
Triggers and Transactions. ACM SIGMOD, 1990.
Stephan Ehrmann, Andreas Beier, Jo Bager. Auf Knopfdruck Web: HTML-
Editoren mit Site-Management-Funktionen. . In c't 15.97, Verlag Heinz Heise,
Hannover, 1997.

104 Literaturverzeichnis
[Fech97] Peter Fecht. Sicherheitsrisiken und Sicherheitsmechanismen im Internet.
Studienarbeit, Fachbereich Informatik, Universität Hamburg, Deutschland, 1997.
[FGHW88] Fernando Flores, Michael Graves, Brad Hartfield, and Terry Winograd. Computer
Systems and the Ontologie of Organisational Interaction. ACM Transaction on
Office Information Systems, 6(2):153--172, April 1988.
[GM94] Andreas Gawecki und Florian Matthes. The Tycoon Machine Language TML: An
Optimizable Persistent Program Representation. FIDE Technical Report Series
FIDE/94/100, Fachbereich Informatik, Universität Hamburg, Deutschland, August
1994.
[Götz94] Rainer Götze. Datenmodellierung für multimediale Benutzerschnittstellen. In
Berichte aus dem Fachbereich Informatik, Bericht Nr. 1/94, Carl von Ossietzky
Universität Oldenburg, Deutschland, 1994.
[Hach96] Ilona Hachmann. Generische Visualisierungsdienste am Beispiel von StarView
und Tycoon. Studienarbeit, Fachbereich Informatik, Universität Hamburg,
Germany, 1996.
[Herr91] Thomas Herrmann. Die Bedeutung menschlicher Kommunikation für die
Kooperation und für die Gestaltung computerunterstützter Gruppenarbeit. In Horst
Oberquelle, Kooperative Arbeit und Computerunterstützung : Stand und
Perspektiven. Verlag für Angewandte Psychologie Göttingen, Verlagsgruppe
Hogrefe, 1991.
[Hübn90] Wolfgang Hübner. Entwurf graphischer Benutzerschnittstellen : Ein
objektorientiertes Interaktionsmodell zur Spezifikation graphischer Dialoge. In
Beiträge zur graphischen Datenverarbeitung, Dissertation, Technische Hochschule
Darmstadt, Deutschland, Springer-Verlag Berlin u.a., 1990
[Hüsk97a] Ralf Hüskes. Flexible Seiten. c't 16.97, Verlag Heinz Heise, Hannover, 1997.
[Hüsk97b] Ralf Hüskes. Schnittmuster für Web-Schneider: Was Style Sheets vermögen und
wo die Browser versagen. c't 12.97, Verlag Heinz Heise, Hannover, 1997.
[Jabl94] S. Jablonski. MOBILE: A Modular Workflow Model and Architeture. In:
Proceedings of the 4th International Working Conference on Dynamic Modelling
and Information Systems, Noordwijkerhout, Niederlande, November 1994.
[Jabl95] S. Jablonski. Workflow--Management--Systeme: Motivation, Modelllierung,
Architektur. Informatik Spektrum, Jg. 18 Nr. 1, 1995..
[Java96] Java unleashed. Sams.net Publishing, Indianapolis, 1996.
[Joha97] Nico Johannisson. Eine Umgebung für mobile Agenten: Agentenbasierte verteilte
Datenbanken am Beispiel der Kopplung autonomer „Internet Web Site Profiler“.
Diplomarbeit, Fachbereich Informatik, Universität Hamburg, 1997.
[Jone96] Christopher V. Jones. Visualization and Optimization. Kluwer Academic
Publishers, Norwell, Massachusetts, USA, 1996.
[Kass95] Thomas Kaß. Anwendungsspezifische Autorisierungsstrategien in polymorphen
persistenten Programmierumgebungen : Ein Bibliotheksansatz. Diplomarbeit.
Fachbereich Informatik, Universität Hamburg, 1995.
[Keek97] Kevin Keeker. Improving Web Site Usability and Appeal.
http://www.microsoft.com/workshop/author/plan/improvingsiteusa-f.htm, 1997.

Literaturverzeichnis 105
[Koeh96] Hubertus Koehler. Generische Daten- und Funktionsvisualisierung in einer
persistenten Programmierumgebung. Master’s thesis, Fachbereich Informatik,
Universität Hamburg, Germany, March 1996.
[Krus97] Wolfgang Kruse. Historienmanagement für kooperative Aktivitäten. Diplomarbeit,
Fachbereich Informatik, Universität Hamburg, Deutschland, 1997.
[Lamp81] Leslie Lamport. Password authentication with insecure communication.
Communications of the ACM, Nov. 1981.
[Maaß91] Susanne Maaß. Computergestützte Kommunikation und Kooperation. In Horst
Oberquelle, Kooperative Arbeit und Computerunterstützung : Stand und
Perspektiven. Verlag für Angewandte Psychologie Göttingen, Verlagsgruppe
Hogrefe, 1991.
[Math96] Bernd Mathiske. Mobilität in persistenten Objektsystemen. Dissertation,
Universität Hamburg, Fachbereich Informatik, Arbeitsbereich DBIS, Mai 1996.
[Matt95] Florian Matthes. Higher-Order Persistent Polymorphic Programming in Tycoon. In
M.P. Atkinson (Hrsg.), Fully Integrated Data Environments. Springer-Verlag,
Berlin, 1995.
[Matt97a] Florian Matthes. Business Conversations: A High-Level System Model for Agent
Coordination. (to appear in the Proceedings of DBPL-97), März 1997.
[Matt97b] Florian Matthes. Mobile Processes in Cooperative Information Systems. In
Proceedings STJA'97 (Smalltalk und Java in Industrie und Ausbildung), Erfurt,
Springer-Verlag, Berlin, Deutschland, 1997.
[MHHB88] Andreas Mahling, Jürgen Herczeg, Michael Herczeg, Heinz-Dieter Böcker.
Beyond Visualization: Knowing and Understanding. In Visualization in Human-
Computer Interaction, Lecture Notes in Computer Science, Springer-Verlag,
Berlin, 1988.
[Micr97] Microsoft FrontPage 97: Schritt für Schritt. Microsoft Press, Unterschleißheim,
Deutschland, 1997.
[Mise98] Andreas Misera. Forms & CGI. In Internet World Bd. 2/98, WebMedia GmbH,
München, 1998.
[MMM93] B. Mathiske, F. Matthes, and S. Müßig. The Tycoon System and Library Manual.
DBIS Tycoon Report 212-93, Fachbereich Informatik, Universität Hamburg,
Dezember 1993.
[Morr95] Mary E. S. Morris. HTML : WWW effektiv nutzen. Verlag Heinz Heise,
Hannover, Deutschland, 1995.
[MP97] Computer Fachlexikon. Microsoft Press Deutschland, Unterschleißheim, 1997.
[MS92] Florian Matthes und Joachim W. Schmidt. Definition of the Tycoon Language - A
Preliminary Report. DBIS Tycoon Report 062--92, Fachbereich Informatik,
Universität Hamburg, Deutschland, 1992.
[MS93] Florian Matthes und Joachim W. Schmidt. System Construction in the Tycoon
Environment: Architectures, Interfaces and Gateways. In: Proceedings of Euro--
Arch'93 Congress. Springer--Verlag, Berlin u.a., 1993.
[Mues94] Sven Müßig. Beiträge zur typsicheren generischen Datenvisualisierung.
Diplomarbeit, Fachbereich Informatik, Universität Hamburg, Deutschland, 1994.
[Münz96] Stefan Münz. JavaScripts selbst erstellen. http://www.netzwelt.com/selfjavs/, 1996.

106 Literaturverzeichnis
[Münz97a] Stefan Münz. HTML-Dateien selbst erstellen : Das Kompendium für Entwickler
von WWW-Seiten. http://www.netzwelt.com/selfhtml/, 1997.
[Münz97b] Stefan Münz. Style-Sheets Formatvorlagen. http://www.netzwelt.com
/selfhtml/tcj.htm, 1997.
[Münz97c] Stefan Münz. Kurzreferenz: Style-Sheet-Angaben. http://www.netzwelt.com
/selfhtml/tcjc.htm, 1997.
[Niel96] Jakob Nielsen.. Top Ten Mistakes in Web Design. Jakob Nielsen's Alertbox for
May 1996, http://www.useit.com/alertbox/9605.html, 1996.
[Ober91a] Horst Oberquelle. Kooperative Arbeit und menschengerechte Groupware als
Herausforderung für die Software-Ergonomie. In Horst Oberquelle, Kooperative
Arbeit und Computerunterstützung : Stand und Perspektiven. Verlag für
Angewandte Psychologie Göttingen, Verlagsgruppe Hogrefe,1991.
[Ober91b] Horst Oberquelle. CSCW- und Groupware Kritik. In Horst Oberquelle,
Kooperative Arbeit und Computerunterstützung : Stand und Perspektiven. Verlag
für Angewandte Psychologie Göttingen, Verlagsgruppe Hogrefe, 1991.
[Oppl92] Rolf Opplinger, Computersicherheit. Vieweg-Verlag Braunschweig, 1992.
[PK97] James E. Pitkow, Colleen M. Kehoe. Results from the Third WWW User Survey.
The World Wide Web Journal, Vol. 1, Nr. 1,
http://www.gvu.gatech.edu/user_surveys/papers/survey_3_paper.html, 1995.
[Ramm96] Kay Ramme. Hypertextbasierte Visualisierung von Tycoon-Bibliotheken in
Netzwerken. Studienarbeit, Fachbereich Informatik, Universität Hamburg, April
1996.
[RBP+91] Rumbaugh, James, Blaha, Michael, Premerlani, William, Eddy, Frederick und
Lorensen, William. Object-Oriented Modeling and Design. Prentice Hall,
Englewood Cliffs, New Jersey 07632, 1991.
[RBP+93] James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William
Lorensen, Doris Märtin (Übers.). Objektorientiertes Modellieren und Entwerfen.
Carl Hanser Verlag, München mit Prentice-Hall International, London, 1993.
[Rich97] Ingo Richtsmeier. Kommunizierende Informationssysteme am Beispiel autonomer
Internet WebSiteProfiler: Vergleich objekt- und agentenbasierter Ansätze.
Diplomarbeit, Fachbereich Informatik, Universität Hamburg, 1997.
[Ripp98] Volker Ripp. Verbesserung der Lokalität und Wiederverwendbarkeit von
Geschäftsprozessen: Probleme und Lösungsansätze am Beispiel kundenorientierter
Hotelgeschäftsprozesse. Diplomarbeit in Vorbereitung, Fachbereich Informatik,
Universität Hamburg, Deutschland, 1997.
[Schm83] Alfred A. Schmitt. Dialogsysteme : Kommunikative Schnittstellen, Software
Ergonomie und Systemgestaltung. In Reihe Informatik, Band 40,
Bibliographisches Institut, Mannheim, Deutschland, 1983.
[Sear69] J. Searle. Speech Acts. Technical Report, Cambridge University Press, Cambridge,
1969.
[SS92] SunSoft, Inc. The NeWS Toolkit 3.1 Reference Manual. SunSoft, Inc., Mountain
View, 1992.
[Sull96] Terry Sullivan. Interface Elements: To Frame, Or Not To Frame?,
http://www.pantos.org/atw/35295.html, 1996.

Literaturverzeichnis 107
[Vogt97] Petra Vogt. Designertricks: Tips zur besseren Gestaltung von Websites. In c’t
13.97, Verlag Heinz Heise, Hannover, 1997.
[W3C97] World Wide Web Consortium. HTML 4.0 Specification. http://www.w3.org/TR,
1997.
[W3C98] World Wide Web Consortium. Web Style Sheets: What are style sheets?.
http://www.w3.org/style/, 1998.
[Wagn97] Gerd Wagner. Software mit Managerqualitäten. c't 15.97, Seite 234 - 242, Verlag
Heinz Heise, Hannover, 1997.
[Wahl98] Jens Wahlen. Entwurf einer objektorientierten Sprache mit statischer Typisierung
unter Beachtung kommerzieller Anforderungen. Diplomarbeit in Vorbereitung,
Fachbereich Informatik, Universität Hamburg, Deutschland, 1998.
[WBW96] Jason Wood, Ken Brodlie, Helen Wright. Visualization over the World Wide Web
and its application to enviromental data. In Proceedings Visualization '96, IEEE
Visualization Conference, IEEE Computer Society Press, Los Alamitos, 1996.
[Wege95] Wegener, H. Die Erfindung des Rades, Wiederverwendbare Komponenten für die
Benutzerschnittstelle. iX 3.1995.
[Wegn98] Holm Wegner. Objektorientierter Entwurf und Realisierung eines
Agentensystems für kooperative Internet-Informationssysteme. Diplomarbeit in
Vorbereitung, Fachbereich Informatik, Universität Hamburg, Deutschland, 1998.
[Weik98] Marc Weikard. Entwurf und Implementierung einer portablen multiprozessorfähigen
virtuellen Maschine für eine persistente, objektorientierte
Programmiersprache. Diplomarbeit in Vorbereitung, Fachbereich Informatik,
Universität Hamburg, Deutschland, 1998.
[Will96] André Willomat. Authentisierung in Tycoon: Eine polymorophe
Entwicklungsschnittstelle zu Kerberos. Studienarbeit, Fachbereich Informatik,
Universität Hamburg, 1996.
[Wino87] Terry A. Winograd. A Language/Action Perspective on the Design of Cooperative
Work. Technical Report STAN-CS-87-1158, Department of Computer Science,
Stanford University, Stanford, CA 94305, 1987.

108
Erklärung
Hiermit erkläre ich, die vorliegende Diplomarbeit selbständig durchgeführt und keine anderen als
die angegebenen Quellen und Hilfsmittel benutzt zu haben.
Hamburg, den 29. März 1998
(Heiko Zade)