Entwicklung eines Metamodells zur Agentenorientierten

Westfälische Wilhelms-Universität Münster
Entwicklung eines Metamodells
zur Agentenorientierten Softwareentwicklung
Masterarbeit
im Fachgebiet Wirtschaftsinformatik
Themensteller:
Prof. Dr. Guido Wirtz
vorgelegt von:
Florian Klein
Steinfurter Straße 18
48149 Münster
Tel. 0251/278682
[email protected]
Abgabetermin:
2003-03-21
– II –
Inhaltsverzeichnis
1 Einleitung ................................................................................................................. 1
1.1 Motivation......................................................................................................... 1
1.2 Ziele.................................................................................................................. 3
1.3 Methodik........................................................................................................... 4
1.4 Aufbau .............................................................................................................. 5
2 Agentenorientierung – eine Bestandsaufnahme......................................................... 6
2.1 Ursprünge der Agentenforschung ...................................................................... 6
2.1.1 Die Erforschung Künstlicher Intelligenz.................................................... 6
2.1.2 Auf der Suche nach neuen Wegen in der Softwareentwicklung ................. 9
2.2 Der Agentenbegriff ......................................................................................... 14
2.3 Agenten in der Theorie.................................................................................... 19
2.3.1 Theorie der Systemebenen ...................................................................... 19
2.3.2 Mentalistische Theorien .......................................................................... 21
2.3.2.1 Rechtfertigung einer mentalistischen Perspektive............................ 21
2.3.2.2 Semantik mentalistischer Modelle................................................... 24
2.3.2.3 Agententheorien.............................................................................. 25
2.3.3 Physikalische Abstützung........................................................................ 28
2.3.4 Agentenkommunikation .......................................................................... 29
2.4 Agenten im Modell ......................................................................................... 33
2.4.1 Referenzmodelle ..................................................................................... 34
2.4.2 Methodologien ........................................................................................ 38
2.4.3 Modellierungssprachen ........................................................................... 43
2.5 Agenten in der Praxis ...................................................................................... 45
2.5.1 Standards ................................................................................................ 45
2.5.1.1 Der MASIF-Standard...................................................................... 46
2.5.1.2 Der FIPA-Standard ......................................................................... 47
2.5.2 Agentenplattformen und Toolkits ............................................................ 50
2.5.3 Agentenbasierte Anwendungen ............................................................... 51
3 Entwurf des Metamodells ....................................................................................... 57
3.1 Modellphilosophie........................................................................................... 57
3.1.1 Modellbegriff .......................................................................................... 57
3.1.2 Agentenbegriff ........................................................................................ 58
3.1.3 Integrationskonzept ................................................................................. 59
3.1.4 Architekturprinzipien .............................................................................. 60
3.1.5 Agententheorie........................................................................................ 62
3.1.6 Systemtheorie ......................................................................................... 65
3.2 Modellstruktur................................................................................................. 66
3.2.1 Physical Layer......................................................................................... 67
3.2.2 Conceptual Layer .................................................................................... 69
– III –
3.3 Modellelemente............................................................................................... 70
3.3.1 Physical Layer......................................................................................... 73
3.3.1.1 Environment Model ........................................................................ 74
3.3.1.2 Entity Model................................................................................... 78
3.3.1.3 Process Model............................................................................... 105
3.3.1.4 Service Model............................................................................... 110
3.3.1.5 Zusammenfassung der Physical Layer........................................... 117
3.3.2 Conceptual Layer .................................................................................. 118
3.3.2.1 Mental Model ............................................................................... 119
3.3.2.2 Behavioral Model ......................................................................... 129
3.3.2.3 Social Model................................................................................. 141
3.3.2.4 Application Model ........................................................................ 158
3.3.2.5 Zusammenfassung der Conceptual Layer ...................................... 167
3.3.3 Zusammenfassung des Gesamtmodells.................................................. 168
4 Studie zur operativen Umsetzung des Metamodells .............................................. 170
4.1 Vorgehensweise ............................................................................................ 171
4.1.1 Verwendete Modellierungsmethode ...................................................... 171
4.1.1.1 Anforderung und Auswahl ............................................................ 171
4.1.1.2 Abstract State Machines................................................................ 172
4.1.1.3 Abstract State Machine Language ................................................. 175
4.1.2 Dekomposition und Strukturierung durch Zwischenziele....................... 177
4.2 Aufbau der Spezifikation............................................................................... 178
4.2.1 Die objektorientierte Cb Laufzeitumgebung ........................................... 179
4.2.1.1 Strukturen ..................................................................................... 179
4.2.1.2 Ausführbare Elemente................................................................... 184
4.2.1.3 Native Klassen .............................................................................. 187
4.2.2 Zur Umsetzung des Metamodells .......................................................... 188
4.3 Erkenntnisse und Kritik ................................................................................. 189
4.3.1 Zur Eignung von AsmL......................................................................... 190
4.3.1.1 Zur Eignung der verfügbaren Werkzeuge ...................................... 190
4.3.1.2 Zur konzeptionellen Eignung der Sprache ..................................... 191
4.3.2 Ausführbare Spezifikationen als Modellierungsmittel............................ 194
5 Fazit und Ausblick................................................................................................ 196
– IV –
Verzeichnis der Modellelemente
Physical Layer............................................................................................................. 73
Environment ........................................................................................................... 76
Entity...................................................................................................................... 83
Agent ............................................................................................................... 88
Agent Shell.................................................................................................... 88
Agent Core.................................................................................................... 88
Item ............................................................................................................... 89
Message ....................................................................................................... 90
Resource ....................................................................................................... 91
Proxy
....................................................................................................... 92
Type
....................................................................................................... 92
Facility............................................................................................................... 93
Percept............................................................................................................... 94
Sensor .................................................................................................................... 96
Visual Sensor ..................................................................................................... 97
Auditive Sensor ................................................................................................. 97
Effector .................................................................................................................. 98
Operative Effector.............................................................................................. 99
Verbal Effector .................................................................................................. 99
Context................................................................................................................. 101
Perceptual Context ........................................................................................... 101
Effective Context ............................................................................................. 102
Process ................................................................................................................. 108
Natural Law ..................................................................................................... 109
Enforcement Process ................................................................................... 109
Mechanism .................................................................................................. 109
Autonomous Process........................................................................................ 110
Service ................................................................................................................. 113
–V–
Conceptual Layer ...................................................................................................... 118
Outlook ................................................................................................................ 120
Statement.............................................................................................................. 121
Inherent Statement ........................................................................................... 122
Cognitive Statement ......................................................................................... 123
Derived Statement............................................................................................ 124
Factual Statement............................................................................................. 124
Modal Statement .............................................................................................. 125
Semantics .................................................................................................... 125
Aim
..................................................................................................... 126
Premeditiaton ....................................................................................................... 127
Agent Personality ................................................................................................. 127
Position ................................................................................................................ 131
Schedule............................................................................................................... 133
Action .................................................................................................................. 133
Physical Effect ................................................................................................. 134
Mental Effect ................................................................................................... 134
Behavior............................................................................................................... 135
Spontaneous Behavior...................................................................................... 136
Conditioned Behavior ...................................................................................... 136
Manifestation ................................................................................................... 137
Deliberation ..................................................................................................... 137
Solitary Behavior ............................................................................................. 138
Interactive Behavior ......................................................................................... 138
Culture ................................................................................................................. 144
Role ...................................................................................................................... 145
Norm .................................................................................................................... 147
Axiom ............................................................................................................. 148
Rule ............................................................................................................. 149
Language.............................................................................................................. 149
Professed Intention ............................................................................................... 152
Explicitly Professed Intention .......................................................................... 153
Implicitly Professed Intention .......................................................................... 153
Assertion.......................................................................................................... 154
Directive .......................................................................................................... 154
Commitment .................................................................................................... 155
Permission ....................................................................................................... 155
Interdiction ...................................................................................................... 156
Declaration ...................................................................................................... 156
Expression ....................................................................................................... 156
Agent.................................................................................................................... 159
Community........................................................................................................... 161
User .................................................................................................................... 162
Purpose................................................................................................................. 163
Mission................................................................................................................. 164
– VI –
Abkürzungsverzeichnis
ABA
ACL
ADT
AEE
AES
AI
A.L.I.C.E.
AMS
AO
AOP
AOSE
ARPA
ASM
AsmL
ATP
ATS
AUML
BDI
BGB
B2B
CORBA
COM
CompTiNE
CPM
C#
dag
DAI
DARPA
DASCh
DCOM
DESIRE
EMS
ePK
ERIM
ERIM CEC
ERM
FIPA
FIPA ACL
HMS
HTTP
IDL
IIS
IRC
JADE
JAFIMA
JFIPA
JVM
Agent-Based Applications
Agent Communication Language
Abstract Data Type
Agent Execution Environment
Agent Execution System
Artificial Intelligence
Artificial Linguistic Internet Computer Entity
Agent Mangagement System
Agent Orientation, Agentenorientierung
Agent Oriented Programming (Modellierungssprache)
Agent Oriented Software Engineering,
Agentenorientierte Softwareentwicklung
Advanced Research Projects Agency
Abstract State Machine
Abstract State Machine Language
Agent Transport Protocol (Aglets Toolkit)
Agent Type System
Agent Unified Modeling Language
Belief – Desire – Intention (Architekturmodell)
Bürgerliches Gesetzbuch
Business to Business
Common Object Request Broker Architecture
Component Object Model
Compile Time Named Entity
Critical Path Method
C Sharp, Programmiersprache im Rahmen von Microsoft .NET
directed acyclic graph (gerichteter azyklischer Graph)
Distributed Artificial Intelligence
Defence Advanced Research Projects Agency
Dynamical Analysis of Supply Chains (Projekt)
(Microsoft) Distributed Component Object Model
Design and Specification of Interacting Reasoning Components
Effector-Medium-Sensor (Modell)
ereignisgesteuerte Prozeßkette
Environmental Research Institute of Michigan
ERIM Center for Electronic Commerce
Entity-Relationship-Model
Foundation for Intelligent Physical Agents
FIPA Agent Communication Language
Holonic Manufacturing System (Industrieprojekt)
Hyper Text Transfer Protocol
Interface Definition Language (CORBA)
(Microsoft) Internet Information Server
Internet Relayed Chat
Java Agent Development Framework
Java Framework for Intelligent and Mobile Agents
Java FIPA (Agentenplattform)
Java Virtual Machine
– VII –
KAoS
KI
KIF
KSE
KQML
LAN
LISP
MAS
MASE
MASIF
NCMS
.NET
NPC
OMG
OO
PERT
PPS
Prolog
P2P
RFC
RMI
RouTiNE
SE
SOAP
SQL
UDDI
UML
UPnP
URL
VM
WAN
WSDL
W3C
XML
Knowledgeable Agent-oriented System
Künstliche Intelligenz
Knowledge Interchange Format
Knowledge Sharing Effort
Knowledge Query and Manipulation Language
Local Area Network
List Processing (Programmiersprache)
Multi-Agent System, Multiagentensystem
(Abweichende Verwendung bei Silva et al.) Mobile Agent System
Multiagent Systems Engineering (Methodologie)
Mobile Agent System Interoperability Facility
National Center for Manufacturing Sciences
dot Net (kein Akronym), Entwicklungsplattform von Microsoft
Non-Player Character
Object Management Group
Object Orientation, Objektorientierung
Program Evaluation and Review Technique
Produktionsplanung und -steuerung
Programming in Logic (Programmiersprache)
Person to Person
Request For Comment (hier: Spezifikationen der Internetprotokolle)
(Java) Remote Method Invocation
Run Time Named Entity
Software Engineering, Softwareentwicklung
Simple Object Access Protocol (XML)
Structured Query Language
Universal Description, Discovery and Integration
Unified Modeling Language
Universal Plug and Play
Uniform Resource Locator
Virtual Machine
Wide Area Network
Web Services Description Language (XML)
World Wide Web Consortium
Extensible Markup Language
– VIII –
Abbildungsverzeichnis
Abbildung 3.1
Abbildung 3.2
Abbildung 3.3
Abbildung 3.4
Abbildung 3.5
Abbildung 3.6
Abbildung 3.7
Abbildung 3.8
Abbildung 3.9
Abbildung 3.10
Abbildung 3.11
Abbildung 3.12
Abbildung 3.13
Abbildung 3.14
Abbildung 3.15
Abbildung 3.16
Abbildung 3.17
Abbildung 3.18
Abbildung 3.19
Abbildung 3.20
Abbildung 3.21
Abbildung 3.22
Abbildung 3.23
Abbildung 4.1
Abbildung 4.2
Abbildung 4.3
Abbildung 4.4
Die Teilmodelle der Physical Layer............................................. 67
Die Teilmodelle der Conceptual Layer ........................................ 69
Wesentliche Elemente eines ERM-Diagramms............................ 72
Elementbeziehungen innerhalb des Environment Model .............. 77
Schematischer Aufbau eines Anwendungssystems ...................... 78
Untergliederung des Begriffs Entity............................................. 82
Grundlegendes Zustandsmodell eines Agenten............................ 86
Schema des Agentenlebenszyklus................................................ 87
Elementbeziehungen innerhalb des Entity Model......................... 94
Interaktion innerhalb des Entity Model ...................................... 102
Ausschnitt eines Entity Model für einen Marktplatz................... 103
Klassendiagramm für den obigen Ausschnitt ............................. 105
Elementbeziehungen innerhalb des Process Model .................... 110
Klassifikationsschema für Services............................................ 112
Übersicht über die wichtigsten Elemente der Physical Layer ..... 117
Elementbeziehungen innerhalb des Mental Model ..................... 128
Elementbeziehungen innerhalb des Behavioral Model ............... 139
Behaviors zweier Agenten in einem PPS-System....................... 141
Elementbeziehungen innerhalb des Social Model ...................... 157
Elementbeziehungen innerhalb des Application Model .............. 165
Definition einer Role auf einem elektronischen Marktplatz........ 166
Übersicht über die wichtigsten Elemente der Conceptual Layer. 167
Zentrale Modellbegriffe und Relationen .................................... 168
Die Interfaces der CompTiNE-Hierarchie ................................. 180
Die Interfaces der RouTiNE-Hierarchie ................................... 182
Ausschnitt aus der Hierarchie der Ausdruckstypen .................... 185
Übersicht über die unterstützten Befehlstypen ........................... 186
–1–
1
1.1
Einleitung
Motivation
Agentenorientierte Ansätze finden gegenwärtig in zahlreichen Bereichen der Informatik
und Softwaretechnik zunehmende Beachtung. Softwareagenten wurden schon vor über
zehn Jahren von zahlreichen Autoren aus den Bereichen der künstlichen Intelligenz und
der Systementwicklung als zukunftsträchtiges Konzept identifiziert (vgl. [Rosenschein/Genesereth 1985], [Shoham 1990], [Wooldridge 1992]), haben jedoch erst vor
dem Hintergrund exogener technischer und sozialer Entwicklungen das gegenwärtige
hohe Maß an Aufmerksamkeit erregt. Das Internet, das seitdem die globale Kommunikation revolutioniert, offene Standards propagiert und Automation, Integration und
Vernetzung im Unternehmensbereich vorangetrieben hat, und der sich aktuell abzeichnende Trend zu mobilen Anwendungen sind dafür verantwortlich, daß Agenten heute
eines der aktivsten und dynamischsten Forschungsgebiete der Informatik darstellen
[Kalenka 2001, S. 12].
Die Agentenmetapher ist ein mächtiges Abstraktionskonzept, dessen Reiz in der
Möglichkeit zur intuitiven Beschreibung komplexen Systemverhaltens liegt [Lind 2000,
S. 1]. Bei seiner Formalisierung stellen seine Eingängigkeit und Vielseitigkeit jedoch ein
wesentliches Hindernis dar. Da das Konzept in den unterschiedlichsten Anwendungskontexten attraktiv ist, ist das Feld von einer starken Heterogenität bezüglich der
Forschungsgegenstände und –ziele geprägt. ‚Agent’ ist dadurch zu einem äußerst
facettenreichen Begriff geworden. Erschwerend kommt hinzu, daß der Begriff eine
starke Faszination auf Medien und Marketingabteilungen ausübt, da er direkt die
weitverbreitete Idealvorstellung eines (mit-)denkenden, intelligenten Computers
[Sundsted 1998a] anspricht. Unrealistische Versprechungen an die Anwender und
übertriebener Optimismus auf Seiten der Entwickler resultieren zwangsläufig in
enttäuschten Erwartungen, die leicht zur Disqualifikation einer Technologie führen
können ([Wooldridge/Jennings 1995, S. 3], [Tveit 2001, S. 2]). Seine inflationäre Anwendung und undifferenzierte Ausdehnung erodiert zudem den Begriff und droht langfristig, ihn zu einem inhaltslosen Modewort (‚Noise Term’) zu machen [Wooldridge/Jennings 1995, S. 4].
–2–
In der Agententheorie als noch jungem Forschungsgebiet existieren noch zahlreiche
teilweise widersprüchliche Grundlagenartikel, die sich um eine Positionsbestimmung
bemühen. Dabei wird häufig diskutiert, ob die Agentenorientierung mit ihren Möglichkeiten und Mängeln ein neues Paradigma der Softwareentwicklung sei. Lind zieht zur
Beantwortung dieser – im Grunde sophistischen – Frage die Definition eines Paradigmas als „[…] theoretisches Gebäude […], in dessen Rahmen Theorien, Gesetze und
Verallgemeinerungen und die Experimente zu ihrer Untermauerung formuliert sind“1
heran [Lind 2000, S. 11], was der Agentenorientierung sicherlich zuzugestehen ist. Den
eigentlichen Kern des Problems trifft aber eher der Duden [Duden 1990b] mit der
Definition als „Denkmuster, das das wissenschaftliche Weltbild, die Weltsicht einer Zeit
prägt“: Kann die Agentenorientierung die Objektorientierung als vorherrschende
Abstraktion verdrängen?2
Jennings hält sie dazu sowohl für geeignet als auch fähig [Jennings 2000, S. 2], räumt aber
ein, daß die Geschichte der Softwareentwicklung reich an brillanten Ideen ist, die es nie
bis in den Mainstream geschafft haben [Jennings 1999, S. 5]. Die Agententechnologie hat
auf dem Weg dorthin noch einen weiten Weg vor sich. Ein Einsatz im professionellen
Bereich erfordert anwenderfreundliche Vorgehensmodelle und solide Werkzeugunterstützung [Tveit 2001, S. 1]. Die Entwicklung geeigneter Werkzeuge wird allerdings nur
dann auf breiter Basis erfolgen, wenn zunächst eine anerkannte Methodologie existiert
[Sycara 1998]. Diese Erkenntnis hat zu einer Schwemme vorgeschlagener Vorgehensmodelle, Modellierungssprachen, Referenzmodelle, Architekturen und Plattformen
geführt. Die daraus resultierenden Probleme, namentlich weitere Fragmentierung, wenig
Wiederverwendung und mehrheitlich im Prototypenstadium stagnierende Projekte,
werden etwa in [Kendall et al. 1998b, S. 1] gewürdigt, nur um im Anschluß mit der
Einführung eines weiteren Referenzmodells beantwortet zu werden [ibid.].
1
“3 : a philosophical and theoretical framework of a scientific school or discipline within which theories,
laws, and generalizations and the experiments performed in support of them are formulated” [Webster
2002b].
2
Eine vergleichbare Interpretation des Begriffs Paradigma findet sich auch bei Kuhn in“The Structure of
Scientific Revolutions“ [Kuhn 1996]. Eine seiner relevanten Beobachtungen in diesem Zusammenhang
ist, daß neue Paradigmen existierende Paradigmen nie schlagartig verdrängen, sondern meist erst von
der nachfolgenden Forschergeneration als kanonisch akzeptiert und allgemein verbreitet werden.
–3–
1.2
Ziele
Welchen Beitrag kann vor diesem Hintergrund das hier vorgeschlagene Metamodell
leisten? Historisch bedingt wird die Agentenforschung von zwei zumeist deutlich
abgegrenzten Strömungen bestimmt: Im akademischen Bereich überwiegt der Anteil der
Autoren mit einem Hintergrund im Bereich der künstlichen Intelligenz (KI), während in
der Praxis evolutionäre Weiterentwicklungen klassischer Softwaretechnik klar dominieren. Der Schwerpunkt liegt im Bereich der KI auf formalen logischen Modellen, die
sich mit der Beschreibung mentaler Zustände ([Rao/Georgeff 1991]), Wissensrepräsentation ([KSE 1995]), Kommunikation ([FIPA C00037], [Viroli/Omicini 2002b]) und Inferenzstrategien beschäftigen, sowie soziologisch gefärbten Betrachtungen über Agentengruppen ([Hogg/Jennings 1997], [Kalenka 2001]). Softwaretechnisch geprägte Forschung
beschäftigt sich mit der Entwicklung praxistauglicher Methodologien ([Brazier et al.
1997], [Wooldridge et al. 2000], [Wood/Deloach 2001]), der Erweiterung objektorientierter Modellierungstechniken ([Bauer et al. 2001], [Lind 2001]) und der praktischen
Umsetzung auf Basis existierender Technologien ([Parunak 2000]). Im kommerziellen
Einsatz ist Infrastruktur eindeutig wichtiger als hochentwickelte Intelligenz [Lawton
1996].
Das Metamodell will zum einen die verschiedenen Sichtweisen in Beziehung setzen und
einen gemeinsamen Bezugsrahmen vorschlagen. Darüber hinaus soll aber auch der
Frage nachgegangen werden, was das verbindende Moment der betrachteten Ansätze
darstellt und die Agentenorientierung im Kern ausmacht. Agentenorientierung wird
dabei primär als abstraktes Prinzip verstanden. Eine objektorientierte Sichtweise wird
von den unterschiedlichsten Sprachen und Laufzeitumgebungen umgesetzt, verwendet,
unterstützt oder zumindest simuliert. Die Ansätze unterscheiden sich zum Teil in
wesentlichen konzeptionellen Punkten fundamental, etwa bei Kapselung, Typensystem,
Vererbungsmechanismen und Speicherverwaltung. Selbst bei Verwendung derselben
Sprache können verschiedene Klassenbibliotheken inkompatible Philosophien umsetzen. Dennoch sind die verwendeten Modellierungstechniken und –prinzipien weitgehend identisch. Mit UML (Unified Modeling Language) [Booch et al. 1998] existiert ein
programmiersprachenunabhängiger Standard zur grafischen Beschreibung objektorientierter Modelle. Entscheidend ist die Verwendung der selben Abstraktion – dem Objekt
als zustandsbehafteter, gekapselter Entität. In diesem Sinne steht das vorgeschlagene
–4–
Metamodell auch nicht in Konkurrenz oder Widerspruch zu existierenden Architekturen
oder Modellierungsmethoden. Sein Abstraktionsgrad erlaubt ihm, unterschiedliche
Methoden einzubinden und alternative Formalismen zuzulassen, da es weder auf eine
spezielle Anwendung oder Architektur abgestimmt ist noch e i n e bestimmte Herangehensweise vorschreiben will. Das Modell ist vom Ansatz her deskriptiv, was jedoch in
keiner Weise einer Beschränkung auf den kleinsten gemeinsamen Nenner gleichkommen soll. Es werden durchaus konkrete Elemente definiert, die eine präzise Beschreibung, Strukturierung und Klassifikation existierender Systeme erlauben sollen. Dies legt
als logischen nächsten Schritt die Entwicklung einer (grafischen) High-LevelSpezifikationssprache auf Basis des Modells nahe, deren Ziel ultimativ wäre, ein
eingängiges, vielseitiges, weitgehend neutrales Ausdrucksmittel im Stile von UML zu
bieten.
1.3
Methodik
Am Anfang der Entwicklung eines Metamodells zur Agentenorientierung muß die
Frage nach dem Verständnis des Agentenbegriffs stehen, das darin zum Ausdruck
kommen soll. Wie läßt sich Agentenorientierung abgrenzen? Welche Ansätze und
Anwendungen sollen erfaßt werden, welche nicht?
Diese Fragen können nur vor dem Hintergrund der existierenden Literatur beantwortet
werden. Ein Metamodell, das den Anspruch erhebt, eine breite Auswahl an Architekturen und Methoden adäquat beschreiben zu können, kann nicht auf rein ideeller Ebene
formuliert werden, sondern muß sich aus der Analyse seines Betrachtungsgegenstandes
ableiten. Daher wird zunächst eine Literaturanalyse vorgenommen, wobei die beiden
Strömungen der Agentenforschung gleichermaßen beachtet werden sollen.
Die Agentenorientierung ist nicht nur selbst ein äußerst aktives Forschungsgebiet,
sondern hat auch von ihren beiden Mutterdisziplinen eine umfangreiche Literatur
geerbt. Eine umfassende Darstellung aller einschlägigen Theorien, Modelle und
Architekturen würde den Umfang dieser Arbeit daher bei weitem sprengen. Der
Schwerpunkt der Betrachtung soll auf den grundlegenden Theorien zur Formalisierung
des Agentenbegriffs liegen. Um eine solide Fundierung in der etablierten Agententheorie zu garantieren, wird versucht, aus dem Gesamtbestand der Literatur die vorherrschenden Lehrmeinungen herauszufiltern. In Vorbereitung des Modellierungsprozesses
–5–
werden diese kurz rezipiert. Ferner werden, ohne jeglichen Anspruch auf Vollständigkeit zu erheben, einige konkrete Architekturen und Anwendungsgebiete betrachtet, um
den praktischen Bezug des Metamodells zu sichern. Die einzelnen Theorien und
Konzepte werden zueinander in Beziehung gesetzt und fallweise um Anmerkungen und
eine Beurteilung bezüglich ihrer Relevanz für das Metamodell ergänzt.
Die Literaturanalyse soll primär deskriptiv sein und hält sich mit Festlegungen zurück.
Sie soll auch keine taxonomische Einteilung der Ansätze vorschlagen – schließlich ist
eines der Ziele, die am Ende des Modells stehen, einen entsprechenden Bezugsrahmen
erst zu schaffen.
Der Versuch einer Synthese der Teilsichten bleibt daher dem Entwurf des Metamodells
vorbehalten. Die Darlegung seiner Grundprinzipien kann somit gleichzeitig als Fazit der
vorhergehenden Studie verstanden werden.
1.4
Aufbau
Im folgenden Abschnitt werden zunächst die Diskussion um das Selbstverständnis der
Agentenorientierung und den Agentenbegriff kurz summiert. Anschließend werden
ausgewählte Theorien, Methoden und Architekturen beschrieben. Zur Abrundung der
Darstellung werden einige beispielhafte agentenbasierte Anwendungen angeführt.
Der dritte Abschnitt der Arbeit beginnt mit der Erläuterung der Philosophie und des
groben Aufbaus des mehrschichtigen Metamodells. Dann werden ebenenweise die
einzelnen Elemente und Prozesse eingeführt und in Strukturmodellen miteinander in
Beziehung gesetzt. Parallel werden dabei jeweils ausgewählte Modellkonzepte anhand
von konkreten Beispielen veranschaulicht.
Im vierten Abschnitt wird schließlich die Möglichkeit einer Umsetzung des Strukturmodells in ein operatives Modell sondiert. Dabei wird insbesondere auf die diesbezügliche Eignung von Abstract State Machines (ASM) eingegangen (vgl. [Gurevich 2000],
[Börger 1999], [Huggins 2003]).
Abschließend werden die Ergebnisse kurz zusammengefaßt und Vorschläge zur
weiteren Entwicklung des Modells formuliert.
–6–
2
2.1
Agentenorientierung – eine Bestandsaufnahme
Ursprünge der Agentenforschung
Zu Beginn der Betrachtung soll eine historische Perspektive gewählt werden, um die im
Anschluß vorgestellten Theorien, Modelle und Anwendungen vor dem Hintergrund des
Kontextes, in dem sie entwickelt worden sind, beurteilen zu können. Obwohl sich die
meisten Ideen weiterhin den Bereichen KI-Forschung oder Softwareentwicklung
zuordnen lassen [Wooldridge et al. 2000, S. 22], ist diese Differenzierung allein unzureichend. Die beiden Zweige der Agentenforschung umfassen selbst wieder zahlreiche
Unterströmungen, die sich gegenseitig berührt, beeinflußt und vermischt haben. Je mehr
sich die Agentenorientierung zudem als eigenes Forschungsgebiet etabliert, wird wohl
auch die beschriebene Dichotomie an Bedeutung verlieren – im Bereich Multiagentensysteme (MAS), dem zentralen Thema der Disziplin, verwischen die Grenzen schon
jetzt. Dennoch lohnt es sich, kurz einen genaueren Blick auf die Wurzeln der modernen
Agentenforschung zu werfen.
2.1.1 Die Erforschung Künstlicher Intelligenz
Als Geburtsstunde der modernen KI-Forschung wird allgemein die DartmouthKonferenz (1956) mit Pionieren wie Minsky, McCarthy, Newell und Simon angesehen
[Schneider/Voß 2001]. Ähnlich wie die Agentenforschung hat die KI mit einem fundamentalen Begriffsproblem zu kämpfen: Was ist künstliche Intelligenz? Minsky definierte Künstliche Intelligenz als „die Wissenschaft, Maschinen Dinge tun zu lassen, die
Intelligenz erforderten, wenn sie von einem Menschen getan würden.“3 Diese Definition
wirft sofort eine neue Frage auf: Was ist ü b e r ha u p t Intelligenz?4 Verschiedene Antworten haben zu fundamental unterschiedlichen Ansätzen geführt. Russell und Norvig
3
4
Im Original: “Artificial Intelligence is the science of making machines do things that would require
intelligence if done by men.“ [Minsky 1968].
Eine Antwort fällt umso schwerer, als die technische Entwicklung selbst das Begriffsverständnis
verändert hat: Durch die Erfindung des Computers wurde etwa die Fähigkeit zur Durchführung
mathematischer Berechnungen, vorher als herausragende Leistung des menschlichen Intellekts betrachtet, entwertet [Kalenka 2001, S. 21].
–7–
[Russell/Norvig 1995] schlagen deren Klassifikation gemäß vier genereller Herangehensweisen vor: menschlich denken (think humanly), menschlich handeln (act humanly), rational denken (think rationally) und rational handeln (act rationally).
Die ersten Arbeiten zielten darauf ab, menschliche Denkprozesse nachzubilden. Ziel
war ein ‚universeller Problemlöser’. Der Ansatz gilt heute als gescheitert, zumal unser
Verständnis des menschlichen Intellekts immer noch äußerst begrenzt ist [Atkinson et al.
2000, S. 192, S. 305ff]. Die Debatte, ob prinzipiell auf der Grundlage heutiger Rechnerarchitekturen Intelligenz auf menschlichem Niveau emulierbar ist (Strong AIHypothese) oder nicht5 (Weak AI-Hypothese), lebt aber weiterhin fort, gerade auch im
Zusammenhang mit Agententechnologien.
Parallel wurde von Anfang an das verwandte Ziel möglichst menschlichen Verhaltens
verfolgt. Der Ansatz hatte für das Feld zwar keine zentrale Bedeutung, dafür aber
naturgemäß eine enorme Außenwirkung.6 Heute lebt er vor allem in Wettbewerben
[Loebner 2001] zum Bestehen des umstrittenen [Shieber 1994] Turing-Tests fort. Bei der
Erforschung innovativer Techniken für Benutzerschnittstellen hat er allerdings eine
Renaissance in Gestalt sprechender Büroklammern [Microsoft 2001] und vergleichbarer
‚anthropomorpher’ Agenten erlebt.
Die KI-Forschung litt darunter, daß reale Erfolge immer im Schatten übertriebener
Erwartungen standen [Schneider/Voß 2001, S. 7]. Nach dem Verfliegen der ersten
Euphorie folgte eine Periode der Konsolidierung und der Erforschung der Grundlagen
rationalen Denkens. Die Rückführung auf ideale Regeln (Syllogismen) sollte zu
optimalen Problemlösungen führen [Kalenka 2001, S. 26]. Der Ansatz steht in der
Tradition der klassischen Logik. Aufbauend auf den Arbeiten von Boole [Boole 1847]
und Frege ([Cleve/Lämmel 2001], [Frege 1879]) zur Aussagenlogik entstand die Prädika-
5
Die Gegner der Hypothese behaupten, Computer könnten menschliches Verhalten bestenfalls nachbilden (Syntaktische Ebene), ohne aber jemals ein Bewußtsein oder echtes Verständnis zu entwickeln
(Semantische Ebene) (vgl. etwa [Gams 1995]). Das bekannteste Argument zur Unterstützung dieser
Behauptung ist die 1980 von Searle formulierte Chinese Room-Analogie [Searle 1980]. Die Debatte
wird mit Vehemenz geführt, vergleiche [Bringsjord 1997]: ‚Strong AI Is Simply Silly’.
6
Diesbezügliche Werke der Science Fiction wie der sprechende, denkende Computer HAL 9000 aus dem
Film 2001: A Space Odyssey (1968) haben das öffentliche Verständnis von KI bis heute nachhaltig
geprägt.
–8–
tenlogik mit den zugehörigen Inferenzstrategien und Notationen zur Wissensrepräsentation. Die entwickelten Formalismen prägen die Agententheorie noch heute. Formallogische Ansätze haben allerdings mit theoretischen Grenzen der Berechenbarkeit und
Verifizierbarkeit, wie sie etwa durch Gödels Unvollständigkeitstheorem [Gödel 1931]
formuliert wurden, zu kämpfen. Die ‚klassische KI’ ist dennoch erfolgreich bei der
Lösung komplexer Probleme, die sich in einen abstrakten Kontext stellen lassen, wobei
die Existenz geeigneter Heuristiken zur effizienten Durchforstung des Suchraums von
zentraler Bedeutung ist. In der Praxis sind Entscheidungen jedoch oft in eingeschränkter
Zeit und auf Grundlage unvollständiger Daten zu treffen, was rein formale Modelle vor
Probleme stellt.7
Der Ansatz des ‚rationalen Handelns’ arbeitet daher primär ergebnisorientiert. Im Sinne
einer behavioristischen Perspektive wird die Intelligenz eines Programms nur nach
seinem Verhalten (in Form von Interaktion mit seiner Umwelt), nicht nach seinen
Entscheidungsprozessen, beurteilt. Welches Verhalten rational ist, wird dabei in
Unkenntnis der optimalen Lösung empirisch anhand von Erfolgsquoten definiert. Im
Rahmen des Ansatzes wurden zum einen neue empirische Verfahren vorgeschlagen,
etwa ‚naturanaloge’ Heuristiken wie neuronale Netze oder genetische Algorithmen.
Zum anderen entwickelte sich ein Trend zur größeren Spezialisierung, generische
Konzepte mit umfassendem Anspruch traten in den Hintergrund. Zudem hatten
praktische Erfolge, etwa im Bereich Expertensysteme, die Bedeutung domänenspezifischen Wissens und seiner effizienten Erfassung unterstrichen.
Ende der siebziger Jahre entstand als neue Disziplin die verteilte Künstliche Intelligenz
(DAI), die sich mit der Aufgabendistribution und Koordination bei verteilten Problemlösungsstrategien beschäftigt [Kalenka 2001, S. 29]. Konkrete Konzepte zur Modellierung entsprechender Systeme schlugen später z. B. Brooks mit der Subsumption
Architecture [Brooks 1986] und Kaelbling mit den Situated Automata [Kaelbling 1986] vor.
In der Folgezeit setzte sich dann für das Konzept der ‚rational handelnden Programme’
7
Das aus dem 14 Jhd. stammende Bild von Buridans Esel [Meyers 1987], der zwischen zwei gleichermaßen attraktiven Heuhaufen verhungert, da keine ‚hinreichende kausale Grundlage’ für eine Entscheidung zuungunsten eines der beiden existiert, illustriert dieses Problem recht treffend.
–9–
verbreitet die Bezeichnung ‚intelligente Agenten’ durch. Der Begriff war bezüglich der
Frage nach starker oder schwacher KI im Grunde wertneutral. Jedoch beruhten viele
Konzepte gerade auf der Idee, ein System aus einfacheren Agenten aufzubauen.
Agenten wurden daher primär als Bausteine von Multiagentensystemen mit eingeschränkter individueller Intelligenz gesehen. Damit einher ging ein Paradigmenwechsel:
die ‚nouvelle AI’ [Brooks 1990, S. 10] löst ‚einfache’ Probleme in komplexer Umgebung. Angemessenster praktischer Benchmark ist nicht mehr die Fähigkeit zum Schach, sondern zum Fußballspielen [Kitano et al. 1997].
Bezüglich der Strategie zur Koordination von Multiagentensystemen existieren
gegenwärtig zwei Schulen [Kalenka 2001, S. 16]: Reduktionismus und Konstruktionismus. Erstere modelliert ‚top-down’, ausgehend vom Gesamtziel, homogene Systeme
‚gutwilliger’ Agenten, was zu sehr komplexen Modellen führen kann. Letztere beginnt
mit der Modellierung individueller Agenten, die eine egoistische Nutzenmaximierung
verfolgen, und setzt sie anschließend zu einem heterogenen System zusammen, was
chaotisches Verhalten nach sich ziehen kann. Einen wichtigen Teilaspekt stellt dabei in
beiden Fällen das ‚Sozialverhalten’ der Agenten dar. Der Social Simulation Approach
[Castelfranchi 1990] versucht in diesem Zusammenhang, Erkenntnisse der Sozialwissenschaften auf Agentensysteme zu übertragen. So werden etwa Agenten mit einem
‚sozialen Gewissen’ vorgeschlagen [Kalenka/Jennings 1995]. Eine verbreitet verwendete
Analogie sind aus der Makroökonomik entlehnte Marktmodelle [Excelente-Toledo et al.
2001].
2.1.2 Auf der Suche nach neuen Wegen in der Softwareentwicklung
Wie auch in anderen Wissenschaftszweigen ist in der Informatik die Frage, wie gut ihre
theoretischen Konzepte und Formalismen bei der Anwendung auf Probleme realistischen Umfangs skalieren, von großer praktischer Bedeutung. Wesentlich ist dabei oft
weniger, o b sich ein System mit einem bestimmten Formalismus beschreiben läßt, als
– 10 –
ob es sich in z w e c k m ä ß i g e r Weise beschreiben läßt.8 Diese Überlegung hat in der
Geschichte zur Einführung jeweils höherer Abstraktionsebenen geführt, wann immer
die verfügbaren Abstraktionsmittel für eine bestimmte Problemklasse nicht mehr
ausreichend erschienen.
In [Wegner 1997] stellt Wegner die kontrovers diskutierte These auf, daß interaktive
Systeme prinzipiell nicht mehr algorithmisch beschreibbar sind.9 Schon die formalen
Grundlagen der Objektorientierung seien unklar, was ihrem Erfolg jedoch nicht
hinderlich gewesen wäre. Die entscheidendere (und unstrittigere) Erkenntnis aus seiner
Argumentation scheint mit Hinblick auf die Softwareentwicklung eher, daß rein
algorithmische Spezifikationen nicht das vorteilhafteste Ausdrucksmittel zur Darstellung komplexer Systeme sind.
Hewitt hat schon 1977 angeregt, daß der Kontrollfluß bei der Ausführung eines
Programms sich auch im Sinne einer ‚Konversation zwischen Experten’ als Muster des
Nachrichtenaustausches zwischen verschiedenen Actors interpretieren lasse [Hewitt
1977]. Der Artikel markiert einen der Ursprünge der verteilten KI; die Actors, atomare
Paare aus einer Berechnungsvorschrift und einer Liste von Acquaintances, haben aus
heutiger Sicht allerdings mehr Ähnlichkeit mit Objekten als mit Agenten. Da für jede
elementare Rechenoperation jeweils ein entsprechender Actor definiert sein muß,
entspricht das Actor-Modell in seinem Abstraktionsgrad eher einem streng objektorientierten System und ist als Grundlage eines agentenorientierten Ansatzes unzureichend
[Wooldridge/Jennings 1998, S. 5]. Die Idee, Systemverhalten über die Interaktion aktiver
Elemente zu definieren, hat es aber bereits erfolgreich formalisiert.
8
9
Ein umfangreiches Komponentensystem besteht im kompilierten Zustand nur noch aus
Maschinensprachecode. Somit läßt es sich offensichtlich auch direkt in Maschinensprache spezifizieren
– ein solches Ansinnen wäre nur alles andere als praktikabel.
Wegner argumentiert plausibel, daß eine a d ä q u a t e Darstellung realer Computersysteme Ein- und
Ausgabebeziehungen einbeziehen müsse [Wegner 1997, S. 1f]. Weiterhin behauptet er allerdings, daß
Interaktionsmaschinen mächtiger als Turingmaschinen seien und damit den akzeptierten Berechenbarkeitsbegriff sowie die Churchsche These in Frage stellen [ibid., S. 2f]. Als formalen Beleg für die
Irreduzierbarkeit von Interaktionsmaschinen auf Turingmaschinen führt er dabei die Aussage an, die
Eingabeströme ersterer ließen sich nicht auf e n d l i c h e n Bändern ausdrücken [ibid., S. 3]. – Eine Kritik
der zugrundeliegenden Interpretation der Churchschen These findet sich in [Copeland 2002]. Für eine
umfassende Kritik an Wegners Ansatz siehe [Prasse/Rittgen 1998].
– 11 –
Komponentenbasierte Systeme mit ihrer viel gröberen Granularität bieten hingegen
Actors mit einem ausreichend hohen Abstraktionsgrad, so daß die interaktionszentrische
Sichtweise tatsächlich einen Vorteil bei der Modellierung des Systems verspricht. Erst
mit der Verbreitung solcher Systeme begann daher das Agentenkonzept allmählich, in
der Softwareentwicklung Fuß zu fassen. Insoweit verwundert es nicht, daß die meisten
praktischen Anwendungen auf entsprechenden Technologien wie Java RMI [Sun
2001], CORBA [OMG 2002] oder COM [Williams/Kindel 1994] basieren (vgl. etwa [IKV
1998], [OMG 1998] oder [Parunak 2000]).
Agentenorientierung: Anspruch…
Welche Signifikanz hat Agentenorientierung als Konzept der Softwareentwicklung?
Was kann sie leisten, was nicht? Ovum bezeichnet Agentenorientierung als ‚neue
Revolution im Softwarebereich’10 [Ovum 1994]. Von der Mehrheit der Autoren wird
Agentenorientierung jedoch nicht als radikaler Bruch mit etablierten objektorientierten
Technologien, sondern als deren evolutionäre Fortentwicklung betrachtet (vgl. z.B.
[Jennings 1999, S. 6], [Shoham 1993]). Kernzielsetzung bleibt die effiziente Entwicklung
preiswerter, wartbarer Software [Tveit 2001, S. 2]. Oft werden Analogien zwischen
objekt- und agentenorientierten Modellelementen sogar explizit angeführt und Entsprechungspaare, etwa ‚Agent’ – ‚Objekt’ oder ‚Rolle’ – ‚Interface’, definiert (vgl. etwa
[Lind 2000, S. 6]). Auch beim Ansatz zur Reduzierung der Systemkomplexität bietet die
Agentenorientierung nichts prinzipiell Neues: Wie in klassischen Komponentenmodellen wird ein modulares, strukturiertes System von Subsystemen entworfen. Drei
Techniken spielen dabei eine Schlüsselrolle: Dekomposition, Abstraktion und Organisation [Booch 1994]. Jennings identifiziert in diesem Zusammenhang drei Schwachpunkte
objektorientierter Ansätze: übermäßig feinkörnige Bausteine, zu rigide Festlegung der
Interaktionsmuster und unzureichende Handhabung von Organisationsstrukturen.
[Jennings 1999, S. 1]. Agenten bieten dagegen eine natürliche Zerlegung gemäß einer
mehrstufigen Zielhierarchie. Die zielorientierten Bausteine kommunizieren nicht auf der
(imperativen) Systemebene, sondern flexibel auf der Wissensebene. Entsprechend der
10
Im Original: ‚a new revolution in software’ [Ovum 1994].
– 12 –
Natur realer Systeme ist der Kontrollfluß dezentral organisiert ([ibid., S. 3f], siehe auch
[Meyer 1997]). Abstraktion wird durch größere semantische Nähe zwischen den
Modellkonstrukten und den Elementen der Problemdomäne erleichtert [ibid., S. 4].
Organisatorische Beziehungen zählen zu den Grundelementen agentenbasierter Systeme
und sind daher transparent und flexibel manipulierbar [ibid., S. 4f]. Dadurch soll
Agentenorientierung zu fehlertoleranteren Anwendungen mit wartbarerem, intuitiverem
Code führen und eine inkrementelle Konstruktion des Systems erleichtern – nur schwer
quantifizierbare, aber durchaus signifikante Vorteile. Andere Autoren sehen in Agenten
vor allem das Potential zur flexiblen, spontanen Interaktion auch über Systemgrenzen
hinaus. Durch Kapselung in Agenten soll das Schnittstellenproblem klassischer
Softwaresysteme gelöst werden [Russell/Norvig 1995]. Im Zusammenhang mit verteilten
und mobilen Anwendungen werden Agenten auch als technisches Konzept für robuste
und ressourcensparende Transaktionen über ein Netzwerk diskutiert. Eine Analyse der
IBM Research Division [Harrison 1995] erkennt zwar im Vergleich mit konventionellen
Techniken in keinem Teilbereich für sich genommen zwingende Vorteile, attestiert dem
Gesamtkonzept auf Grund von Synergien jedoch erhebliches Potential.
… und Realität
Der Einsatz neuer Technologien birgt jedoch auch Risiken. So kann die Ausdruckskraft
und konzeptionelle Eleganz des agentenorientierten Ansatzes leicht dazu verleiten, ihn
als Allheilmittel einsetzen zu wollen. Wooldridge und Jennings stellen in [Wooldridge/Jennings 1998] politische, analytische und technische Fehler in Verbindung mit dem
Einsatz von Agententechnologien übersichtlich dar. Unabhängig vom konkreten
Anwendungsfall ist Agentenorientierung mit inhärenten konzeptionellen Problemen
behaftet. Nichttriviale, praxisbezogene Softwaresysteme zählen zu den komplexesten
von Menschen hervorgebrachten Konstrukten [Jennings 1999, S. 1]. Das Maß an
Komplexität wird dabei nicht durch die Modellierungsmethode bestimmt, sondern
wohnt ihnen unmittelbar inne11 [Brooks 1995]. Effiziente Modellierungstechniken
können Komplexität nur verlagern und verstecken, nicht beseitigen. Die Agentenmeta-
11
Brooks bezeichnet dieses Phänomen als ’the essential complexity of software’ [Brooks 1995].
– 13 –
pher bezieht ihr Potential aus ihrem hohen, über das Objektkonzept hinausgehenden
Abstraktionsgrad. Während Objekte nur ihren inneren Zustand kapseln, findet bei
Agenten zusätzlich eine Kapselung von Verhalten und Entscheidungsprozessen statt,
wodurch zunächst Komplexität verborgen wird. Gleichzeitig wird allerdings strukturelle
Komplexität in prozessuale Komplexität in Form von nichtdeterministischen Interaktionsmustern umgewandelt und damit auf die Systemebene verlagert. Deutlich illustriert
wird dies durch Simulationswerkzeuge, einem naheliegenden und in der Praxis populären (vgl. etwa [Parunak 2000, S. 396f]) Einsatzgebiet von Agententechnologie. Bei der
Beschreibung von Systemen, die nicht mehr durch ein monolithisches Simulationsmodell erfaßbar sind, werden die aktiven Komponenten intuitiv durch von vergleichbar
einfachen Regeln gesteuerte Agenten repräsentiert, deren Zusammenspiel dann in
potentiell chaotischem Systemverhalten resultiert. Dieses Prinzip wird eindrücklich
durch zelluläre Automaten [Wolfram 1983] illustriert. Die Erhaltung der Komplexität
des simulierten Systems ist dabei erklärtes Ziel – das simulierende System bleibt im
gleichen Maße chaotisch. Über letzteres lassen sich somit a priori keine Aussagen
treffen, die nicht auch aus dem simulierten System ersichtlich sind. In allen anderen
Gebieten der Softwareentwicklung ist dieser Effekt hingegen hochgradig unerwünscht,
da die garantierte Einhaltung kritischer Spezifikationen für die meisten Anwendungen
essentiell ist. Der neuralgische Punkt ist, ob sich zur Koordination der autonomen
Agenten robuste, hinreichend einfache Regeln finden lassen, die das gewünschte
Systemverhalten garantieren. Da Agentensysteme aber oft nicht auf der Systemebene,
sondern auf der Komponentenebene (‚bottom-up’) konzipiert werden, wird das Ausbalancieren dieser Regeln leicht ein müheseliger, iterativer Prozeß [Jennings 1999, S. 6].
Auch die in die Fähigkeit der Agenten zur Interoperabilität gesetzten Hoffnungen
bleiben bislang unerfüllt. Die Systemlandschaft ist extrem fragmentiert – es existiert
eine schier unendliche Anzahl weitgehend inkompatibler akademischer und kommerzieller Agentenplattformen. Verschiedene Konsortien haben Standards vorgeschlagen,
um zumindest auf der infrastrukturellen Ebene (Migration/Kommunikation) die
wesentlichen Hindernisse auszuräumen. Zu nennen sind hier besonders der MASIFStandard [OMG 1998] der OMG (Object Management Group) [OMG] und der FIPAStandard [FIPA C00001] der FIPA (Foundation for Intelligent Physical Agents) [FIPA].
Unabhängig von deren Erfolg existiert allerdings ein tiefgreifendes konzeptionelles
Problem. Die für Agenten charakteristische Kommunikation auf der Wissensebene
– 14 –
erfolgt im Allgemeinen durch den Austausch von Nachrichten, die die Form von
Sprechakten (‚Speech Acts’) haben [Wooldridge/Jennings 1995, S. 20]. Deren Semantik
wird zwar in Form einer ‚Agent Communication Language’ (ACL) formal spezifiziert;
in einem heterogenen Umfeld garantiert dies jedoch selbst bei Verwendung der gleichen
ACL kein gegenseitiges Verständnis. Während Sprache von den Sozialwissenschaften
als soziales Konstrukt interpretiert wird, konstruieren aktuelle ACL-Definitionen
Sprache aus der Perspektive der Individuen, was zur Entstehung von Idiolekten und
‚autistischen’ Systemen führt [Singh 1998a, S. 46].
Im Netzwerkbereich sind der Mangel einer standardisierten Infrastruktur und Sicherheitsbedenken die größten Hemmschuhe bei der Einführung der Technologie. Da in
diesem Bereich bislang die ‚erfolgreichsten’ und prominentesten autonomen Agenten
viraler Natur sind12, dürfte auf Seiten der Serverbetreiber die Bereitschaft, Benutzer
personalisierte Agenten serverseitig ausführen zulassen, tendenziell verhalten sein
[Harrison 1995, S. 14].
2.2
Der Agentenbegriff
Bei der Annäherung an den Agentenbegriff wird mit Blick auf seine Entstehungsgeschichte unmittelbar klar, daß sich keine umfassende und dabei gleichzeitig präzise und
trennscharfe Definition finden lassen wird. Jeder Definitionsversuch geht bei der
Abwägung dieser beiden Ziele zwangsläufig einen Kompromiß ein. Die Gewichtung
hängt letztendlich vom Anspruch der Definition ab, weswegen sie in ihrem Entstehungskontext gesehen werden sollte. Ein vermeintlich allgemeingültiges Entscheidungskriterium wird sich der Kritik der davon Ausgeschlossenen stellen müssen,
während in einem operativen Kontext, etwa im Rahmen der Erstellung einer formalen
Methode oder einer Agentenplattform, eine stark einschränkende Sichtweise absolut
legitim ist.
12
Die Erfolge diverser ‚Agenten’ ([CERT 2001a], [CERT 2001b], [Moore et al. 2003]) auf Microsoft‚Plattformen’ (IIS, SQL-Server) zeigen zum einen das (Gefahren-)Potential der Technologie, unterstreichen zum anderen aber auch die entscheidende Rolle einer standardisierten Infrastruktur für einen
Erfolg dieser Größenordnung.
– 15 –
In theoretischen Betrachtungen zum Selbstverständnis der Agentenorientierung wird
oftmals vor allem eine Abgrenzung von der ‚klassischen’ Softwareentwicklung
angestrebt, wobei meist eine Reihe für Agenten charakteristischer Eigenschaften
definiert wird. In einem vielbeachteten Artikel stellen Franklin und Graesser zur Klärung
der Frage „Agent oder bloß Programm?“ [Franklin/Graesser 1997] verschiedene
Definitionen einander gegenüber und destillieren die in ihren Augen wesentlichsten
Charakteristika heraus, wobei allerdings kaum auf den Hintergrund der jeweiligen
Vorschläge eingegangen wird. Nicht zuletzt deswegen bleibt die Antwort unbefriedigend, so daß die von ihnen entwickelte Definition13 nicht entscheidend zu einer
abschließenden Begriffsklärung beitragen konnte ([Wooldridge 1997b], [Kalenka 2001, S.
34]).
Gemein ist allen Perspektiven lediglich die etymologisch motivierte Sicht eines Agenten
(von lat.: agens, handelnd) als handelnde Entität. Gemäß der allgemeinsprachlichen
Verwendung des Begriffs („Agent: Gesandter, Handlungsreisender“ [Duden 1990a]14)
wird oft, gerade im Zusammenhang mit ‚persönlichen’ Agenten, die für ihre Benutzer
Arbeiten übernehmen, noch der (als formales Kriterium unkritische) Aspekt des
s t e l l v e r t r e t e n d e n Handelns angeführt.
In der KI-Forschung wird zunächst die Beziehung des Agenten zu seiner Umwelt
betont. Die Definition als ‚System, das seine Umwelt durch Sensoren wahrnimmt und
durch Effektoren verändert’ [Russell/Norvig 1995, S. 33] wird durch die Idee des
‚rationalen Handelns’ quasi impliziert. Dabei wird diese Umwelt oft zusätzlich als
dynamisch [Hayes-Roth 1995, S. 108] und komplex [Maes 1995] qualifiziert, was auf die
Fähigkeit zu adaptivem und flexiblem Verhalten hindeuten soll. Im Zusammenhang mit
Robotern (zur Kontrastierung mit rein virtuellen Software Agents häufig als Physical
Agents bezeichnet) ist das Sensoren-Effektoren-Modell offensichtlich mehr als nur eine
Abstraktion.
13
“An autonomous agent is a system situated within and a part of an environment that senses that
environment and acts on it, over time, in pursuit of its own agenda and so as to effect what it senses in
the future.” [Franklin/Graesser 1997].
14
Entsprechend auf Englisch: „agent: (4) one who is authorized to act for or in the place of another”
[Webster 2002a].
– 16 –
Die Betrachtung des Agenten als gekapseltes System mit Ein- und Ausgabebeziehungen
setzt voraus, daß diese systemintern bestimmt sind, weswegen die Bezeichnung als
‚autonom’ in diesem Sinne unstrittig ist. Technisch wird diese Sicht oft durch die
Modellierung in einem eigenen Prozeß oder Thread ausgedrückt. Autonomie ist jedoch
immer ein relativer Begriff, der etwa auch auf einer inhaltlichen Ebene interpretiert
wird, was auf eine Gleichsetzung von autonomem Verhalten mit (potentiellem)
Nichtdeterminismus hinausläuft.
Weiterhin erfordert Handeln, daß ein Agent zumindest entweder auf externe Stimuli
reagiert oder aus eigener Initiative tätig wird. Proaktives Verhalten muß in irgendeiner
Form motiviert sein, was auf die verbreitete Charakterisierung von Agenten als
‚zielorientierte Systeme’ führt. Diese Sichtweise findet sich etwa bei Wooldridge in der
populären15 Definition eines Agenten als „gekapseltes Computersystem, das in einer
Umgebung befindlich und in dieser Umgebung zu flexiblem, autonomen Handeln zum
Erreichen seiner Entwurfsziele befähigt ist“16 [Wooldridge 1997a]. Vor dem Hintergrund
der Entwicklungsgeschichte der KI ist verständlich, warum von einigen Autoren aus der
Zielorientierung abgeleitet wird, Agenten müßten problem- bzw. domänenspezifisch
sein (etwa [Repenning 1993]). Eine eher technische Konsequenz ist die Forderung nach
Persistenz [Smith et al. 1994], die für eine längerfristige Zielverfolgung notwendig
erscheint.
Die Zielorientierung ist auch der Ansatzpunkt der klassischen (‚rational denken’) KI,
deren Agentenbegriff eine mentalistische Sicht impliziert: Der Agent kann anhand
seiner Ziele und daraus abgeleiteten Absichten beschrieben werden. Er teilt dabei die
Merkmale eines klassischen wissensbasierten Systems, d.h. er verfügt über einen
Wissensschatz, auf dessen Grundlage er zu logischen Schlußfolgerungen in der Lage ist.
Formal läßt sich seine Essenz durch eine Logik und eine Menge geeigneter Prädikate
ausdrücken.
15
16
[Jennings 1999, S. 2].
Im Original: „An agent is an encapsulated computer system that is situated in some environment, and
that is capable of flexible, autonomous action in that environment in order to meet its design objectives” [Wooldridge 1997a].
– 17 –
Die verteilte KI behält dieses Konzept meist prinzipiell bei, legt aber naturgemäß den
Schwerpunkt auf die soziale Interaktion zwischen Agenten. Ihre sozialen Fähigkeiten
zum Dialog, Verhandeln und Koordinieren [Coen 1995] werden vielfach als definierende Elemente eines ‚sozialen Agentenbegriffs’ gesehen. Da das Konzept der sozialen
Interaktion auf die Kommunikation mit menschlichen Benutzern erweiterbar ist, kann es
prinzipiell auch Systeme aus einem einzelnen Agenten erfassen.
Diese soziale Interaktion mit dem Benutzer steht bei der Verwendung von Agenten als
Instrument zur Implementierung intuitiver Benutzerschnittstellen im Mittelpunkt.
Entsprechende Interface-Agenten oder persönliche Assistenten stehen nicht im prinzipiellen Widerspruch zu den bisherigen Konzepten, bilden aufgrund der sehr spezifischen
an sie gestellten Anforderungen aber dennoch eine Klasse für sich. Die Erfüllung der
Erwartungen des Benutzers ist das entscheidende Erfolgskriterium, besonders, wenn der
Benutzer dem Agenten kritische Aufgaben anvertrauen soll. Von besonderer Bedeutung
sind dabei eine klare, präzise Kommunikation, anwendungsspezifische Eignung und
intelligente Handhabung von deren Grenzen (‚graceful degradation’, wie bei Expertensystemen). Foner stellt in [Foner 1993, S. 35f] eine ausführliche Liste wesentlicher
Anforderungen zusammen.
Diese letzten Punkte zielen bereits weniger auf die Frage, was die Essenz des Agentenbegriffs ausmacht, sondern eher darauf, wie er zu präzisieren ist, um in einem bestimmten Kontext sinnvoll anwendbar zu sein. In derselben Kategorie sind auch andere, in
vielen Fällen durchaus nützliche Anforderungen anzusiedeln. Die Forderung nach
Aufrichtigkeit, Gutwilligkeit und rationalem Verhalten [Wooldridge/Jennings 1995, S. 6]
ist etwa im Kontext geschlossener Systeme sozialer Agenten vernünftig, als allgemeines
Prinzip jedoch zu einschränkend.
Als letzte zentrale Eigenschaft wird Mobilität, die Fähigkeit zur Relozierung des
Agenten zur Laufzeit, angeführt ([Sundsted 1998b], [Lawton 1996]). Dies ist eng mit der
Sicht von Agenten als zukunftsweisende Netzwerktechnologie [Harrison 1995, S. 1]
verknüpft. Mobilität ist sicherlich keine allgemeine Eigenschaft von Agenten; da sie
jedoch ein weitgehend unabhängiges Konzept darstellt, wird sie im allgemeinen einfach
als charakteristische Eigenschaft der speziellen Klasse der mobilen Agenten (Mobile
Agents) gesehen.
– 18 –
In der Softwaretechnik wird vor allem der Gedanke der Autonomie aufgegriffen. Odell
bezeichnet Agenten als „Objects that can say ‘go’ and ‘no’” [Odell 1999]. Lind
beschreibt Agenten als evolutionäre Fortentwicklung: Objekte führten Funktionen und
Daten zusammen und verwalten dadurch ihren internen Zustand selbst. Agenten
vereinen Objekte mit Ressourcen wie etwa Rechenzeit und gewinnen dadurch Kontrolle
über ihre internen Prozesse [Lind 2000, S. 10].
Diese Betrachtungen unterstreichen zwar einerseits die Vielfältigkeit des Agentenbegriffs, zeigen aber andererseits auch, daß die verschiedenen Interpretationen nicht
unbedingt unvereinbar sein müssen, sondern nur unterschiedliche Weiterentwicklungen
eines gemeinsamen, allein lediglich noch zu unspezifischen Grundkonzeptes sind. Unter
Anerkennung dieser Prämisse wird deutlich, daß vielleicht weniger eine endgültige
Definition des Agentenbegriffs vonnöten ist, als vielmehr eine verbindliche Terminologie für die einzelnen Teilkonzepte, die es erlauben würde, das einem Konzept zugrundeliegende Agentenverständnis knapp und allgemein verständlich zu definieren. Solche
Definitionen könnten etwa die Form des von Jennings und Wooldridge in Anlehnung an
die Unterscheidung zwischen schwacher und starker KI eingeführten ‚starken’ und
‚schwachen Agentenbegriffs’ (strong/weak notion of agency) [Wooldridge/Jennings
1995, S. 5f] annehmen. Die schwache Interpretation17 umfaßt Autonomie, Proaktivität,
Reaktivität und soziale Interaktion, die starke Interpretation fügt dem eine mentalistische Sicht und die Fähigkeit zu logischen Folgerungen hinzu.
Abschließend sollte nicht vergessen werden, daß „der Agentenbegriff vor allem ein
Werkzeug zur Systemanalyse sein soll, nicht eine verbindliche Beschreibung, die die
Welt in Agenten und Nicht-Agenten unterteilt“18 [Russell/Norvig 1995, S. 33]. In Industrieprojekten dominiert eine rein pragmatische Verwendung des Agentenbegriffs
[Parunak 2000, S. 393ff]. Lind schlägt hierfür die Bezeichnung ‚sehr schwacher Agentenbegriff’ (very weak notion of agency) vor: Agent ist alles, worauf sich diese Abstraktion
aus Sicht des Entwicklers sinnvoll anwenden läßt [Lind 2000, S. 4]. Wie theoretische
17
18
Im Original: ‘autonomy’, ‘proactivity’, ‘reactivity’,’ sociability’ [Wooldridge/Jennings 1995, S. 5].
Im Original: „The notion of an agent is meant to be a tool for analyzing systems, not an absolute
characterization that divides the world into agents and non-agents.” [Russell/Norvig 1995, S. 33].
– 19 –
Konzepte in der Praxis verwendet werden, hängt ohnehin weniger von ihrer abstrakten
Definition als von den eingesetzten Methodologien und Werkzeugen ab – ob dabei das
Ergebnis eigentlich ‚nur’19 ein Programm ist, ist am Ende unerheblich. 20
Auf Basis dieser Betrachtungen wird im Rahmen des Modellentwurfs21 eine Arbeitsdefinition entwickelt werden, wobei besonders die letzten beiden Gedanken, eine pragmatische Begriffsverwendung und eine um einen generischen Kern herum modular
aufgebaute Definition, Einfluß finden.
2.3
Agenten in der Theorie
2.3.1 Theorie der Systemebenen
Die Theorie der Systemebenen (Computer System Level Paradigm) formalisiert das
Prinzip aufeinander aufbauender Abstraktionsgrade zur Beschreibung von Computersystemen. Die Ebenen sollen jeweils in sich geschlossen, gleichzeitig aber durch die
Mittel der nächstniedrigeren Ebene ausdrückbar sein. Für jede Ebene werden die
Gesichtspunkte System (der Gegenstand der Betrachtung), Components (die aktiven
Elemente des Systems), Medium (die vom System verarbeiteten Elemente), Compositional Laws (Regeln für den Aufbau des Systems) und Behavioural Laws (Regeln über
das Zusammenspiel der aktiven Elemente) festgelegt.
Das Grundmodell sieht die Ebenen Device Level (Physikalische Ebene, Medium sind
Elektronen, kontrolliert durch die Naturgesetze), Circuit Level (Schaltkreisebene,
argumentiert in Spannungspotentialen), Logic Level (Interpretation der Spannungen als
“Is it an Agent, or just a Program?” [Franklin/Graesser 1997].
Diese Interpretation ist nicht zwangsläufig ‚unwissenschaftlich’. Kuhn legt unter Berufung auf
Wittgenstein dar, wie natürlichsprachige Begriffsklassen nicht durch eine Auswahl von Eigenschaften
definiert sind, die von allen ihren Elementen notwendigerweise geteilt werden muß, sondern durch die
fallweise Beurteilung der ‚Familienähnlichkeit’ zwischen einer unbekannten Instanz und den bereits
anerkannten Vertretern der Begriffsklasse. In ähnlicher Weise werde oft ein Paradigma von den
Mitgliedern eines Forschungszweiges erfolgreich und einvernehmlich verwendet, obwohl keine
allgemein anerkannte formale Definition existiert [Kuhn 1996, S. 44ff].
21
Siehe Abschnitt 3.1.2, S. 58.
19
20
– 20 –
Wahrheitswerte, boolesche Logik auf Bitebene) und Symbol Level (Symbolebene,
formuliert aus symbolischen Ausdrücken Programme) vor. [Kalenka 2001, S. 91ff]
Die Theorie formalisiert im Grunde nur das bereits beschriebene intuitive Prinzip, zur
Modellierung eines Systems den jeweils zweckmäßigsten Formalismus zu benutzen,
expliziert aber die wichtige Anforderung, daß ausreichend präzise Regeln bezüglich der
Abstützung einer Abstraktion auf die darunterliegende Ebene existieren müssen, um sie
darauf zurückführen zu können.
Die Wissensebene
Im Zuge der Entwicklung wissensbasierter Systeme erschien die Symbolebene nicht
mehr ausreichend. Newell [Newell1982] schlug daher 1982 die Einführung einer
‚Wissensebene’ (Knowledge Level) vor, die es erlauben sollte, in Zielen und Fakten zu
argumentieren. An die Stelle des Programms mit seinen Ausdrücken, Abarbeitungsfolgen und Strukturen tritt als neues System der Agent. Components sind seine Ziele und
möglichen Handlungen (Goals und Actions). Medium ist Wissen (Knowledge), wobei
Ziele und Handlungen eine besondere Form von Wissen darstellen. Compositional Laws
werden nicht definiert. Behavioural Law ist das Rationalitätsprinzip (Principle of
Rationality). Dieses besagt, daß ein Agent, wenn er Wissen darüber besitzt, daß eine
Handlung zum Ereichen seiner Ziele führt, diese Handlung auswählen wird. Seine
Hauptaufgabe ist es, alle Elemente der Ebene in Beziehung zueinander zu setzen. Als
operatives Prinzip ist es, etwa in Bezug auf Konflikte, zu unspezifisch. Bei der Abstützung auf die Symbolebene wird es daher durch den ‚Problemlösungsprozeß in seiner
Gesamtheit’ umgesetzt. Wissen und Handlungen werden in entsprechenden Daten- und
Programmstrukturen abgebildet.
Die Soziale Ebene
Auf der Wissensebene aufbauend konstruieren Jennings und Campos [Jennings/Campos,
1997] mit Blick auf Multiagentensysteme eine noch höhere Abstraktion, die ‚Soziale
Ebene’. Das betrachtete System ist nun eine Organisation von Agenten. Auf dieser
Ebene sind die Components ganze Agenten und ihre Kommunikationskanäle. Compositional Laws sind Rollen und Beziehungen, die die Agenten annehmen und eingehen,
und die Regeln, die dies kontrollieren. Behavioural Laws bestimmen den Verhaltensko-
– 21 –
dex, nach dem die individuellen Ziele mit den Zielen des Systems ausbalanciert werden.
Medium ist das soziale Wissen der Agenten über ihre Mitagenten, Einflußmöglichkeiten, Rechte und Pflichten. Die neue Perspektive soll es ermöglichen, das Verhalten des
Agentensystems zu erfassen, ohne sich mit den Implementierungsdetails der einzelnen
Agenten auseinander setzen zu müssen [Jennings 1999, S. 7]. Das Interesse von Jennings
und Campos gilt dabei besonders dem Gleichgewicht zwischen individuellen und
gemeinschaftlichen Interessen. Abhängig von den Auswirkungen auf die Gemeinschaft
und den ausführenden Agenten unterscheiden sie zwischen gemeinnützigen (alle
profitieren), egoistischen, selbstlosen und sinnlosen (alle verlieren) Handlungen [Kalenka
2001, S. 101]. Auf dieser Basis definieren sie das ‚soziale Rationalitätsprinzip’ (Principle of Social Rationality), das besagt, daß ein Agent eine Handlung ausführen wird,
wenn ihr gesellschaftlicher Gesamtnutzen positiv ist. Kalenka kritisiert dabei, daß diese
Definition nicht wie behauptet allen Typen von Agentensystemen gerecht werde,
sondern implizit sozial verantwortliche Agenten voraussetze [Kalenka 2001, S. 102].
Die beiden vorgeschlagenen Ebenen bieten einen nützlichen Ansatz zur groben
Strukturierung des Metamodells. Gerade die entscheidende – bei abstrakten Konzepten
der KI immer besonders sensible – Abstützung auf eine niedrigere Ebene wird von
Jennings und Campos jedoch ausgespart.
2.3.2 Mentalistische Theorien
2.3.2.1 Rechtfertigung einer mentalistischen Perspektive
Mentalistische Theorien beschäftigen sich mit der Anwendung von originär in Verbindung mit dem menschlichen Geist definierten Begriffen auf künstliche Systeme. Sie
haben in der KI-Forschung eine lange Tradition. Newells Wissensebene, indem sie mit
Wissen und Zielen von Agenten argumentiert, ist im Grunde ein solches mentalistisches
Konzept. Damit ist ihre Motivation bereits etabliert: Es geht darum, die Abstraktionsebene der Programmierung hinter sich zu lassen.
McCarthy argumentiert in [McCarthy 1979], warum es sinnvoll sein kann, Maschinen
Absichten, Überzeugungen, Willen, Wissen, Fähigkeiten oder Bedürfnisse zuzuschreiben. Der Grund ist für ihn epistemologischer Natur: die Verwendung dieser Konzepte
– 22 –
erlaubt uns, Erkenntnisse zu gewinnen, die uns sonst aufgrund unserer eingeschränkten
Auffassungsgabe verwehrt blieben.22 Dies konkretisiert er in sechs auf KI-Programme
bezogenen Begründungen [ibid., S. 5], die aber im Grunde ganz allgemein die Vorteile
eines Formalismus zur abstrakten Modellierung herausstellen:
1. Der Quellcode eines Programms spezifiziert primär Abläufe, der Zustand zu einem
bestimmten Zeitpunkt ist nicht direkt ablesbar. Eine abstraktere Begriffswelt erleichtert es, seinen Zustand zu verfolgen und verständlich zu beschreiben.
2. Selbst wo eine Simulation technisch oder praktisch nicht möglich ist, können
abstrakte Konzepte eine ‚manuelle’ bzw. mentale Simulation kritischer Aspekte
zulassen.
3. Argumentation auf einer abstrakteren Ebene ermöglicht generelle Aussagen, die
nicht durch eine endliche Anzahl von Simulationsläufen gewonnen werden können.
4. Programme werden leichter verständlich, weil Implementierungsdetails wegfallen.
5. Die abstrakten Konzepte können bei der Analyse und Wartung hilfreich sein, da mit
ihrer Hilfe auf das Konzept, das der Entwickler im Kopf hatte, geschlossen werden
kann.
6. Programme lassen sich auf der Ebene abstrakter Strukturen effizienter vergleichen.
Für intelligente Agenten bieten sich mentalistische Begriffe als eine solche Abstraktion
aus verschiedenen Gründen an. Das Hauptargument ist, daß Menschen bereits daran
gewöhnt sind, im alltäglichen Umgang miteinander ständig subjektive Annahmen über
die Absichten anderer zu formulieren, um deren Verhalten zu verstehen und vorauszusagen. Daher dürfte eine Übertragung auf Agenten den meisten Menschen natürlich und
intuitiv verständlich erscheinen – sofern der Sinngehalt des Begriffs bei der Übertragung erhalten bleibt [ibid., S. 1]. Verallgemeinernd belegt Dennett solche Akteure, deren
Verhalten sich durch die Zuschreibung von Annahmen und Absichten (Intentional
Notions) vorhersagen läßt, mit der Bezeichnung Intentional System [Dennett 1987, S.
49]. Ein solches System besitzt eine ‚Geisteshaltung’ (Intentional Stance).
22
Dies ist letztlich eine erkenntnistheoretische Umformulierung des bereits mehrfach erwähnten Prinzips
der Zweckmäßigkeit von Modellierungsmethoden.
– 23 –
Für das Verständnis von Systemen höherer Ordnung, etwa Agenten, die bei der Lösung
eines Problems ihre eigenen Wissensdefizite analysieren sollen und somit Metawissen
(Wissen ü b e r Wissen) benötigen, erscheint eine mentalistische Interpretation fast
unvermeidlich, da schließlich dem Agenten selbst ein zumindest primitives Wissenskonzept mitgegeben werden muß [McCarthy 1979, S. 2]. Nichtsdestotrotz betont
McCarthy, daß die Zuschreibung mentalistischer Attribute kein komplexes ‚mentales’
System erfordert. Er empfiehlt, die Anwendbarkeit eines konkreten Konzepts konservativ, die generelle Anwendbarkeit mentalistischer Konzepte auf ein Objekt aber großzügig zu beurteilen [ibid.]. Das Objekt selbst muß keinerlei intrinsische mentale Qualitäten
besitzen.23 Dies illustriert er durch die mentalistische Modellierung eines Thermostaten
unter Verwendung von Annahmen („Es ist zu warm/kalt.“) und Absichten („Es soll die
eingestellte Temperatur erreicht werden!“) [ibid., S. 14]. Shoham hält dem allerdings
entgegen, daß mentalistische Konzepte in Fällen, in denen ein rein mechanistisches
Verständnis zur Analyse ausreichen würde, keinerlei zusätzlichen Nutzen stiften
[Shoham 1990, S. 6].
Das Konzept der Wissensebene besagt, daß sich ein System vollständig auf dieser
Ebene beschreiben läßt. McCarthy merkt hingegen an, daß Beschreibungen auf einer
mentalistischen Ebene immer zu unvollständigen Systemen führen, die für sich
genommen – selbst unter der Annahme einer streng deterministischen Implementierung
auf der nächstniedrigen Ebene – keine vollständige Voraussage ihres Verhaltens
zulassen [McCarthy 1979, S. 6].
Zudem bleibt das Problem, die genaue Bedeutung der einzelnen Konzepte zu formalisieren.
23
Interessant ist in diesem Zusammenhang ein Artikel von Searle [Searle 1990]. Er kritisiert darin die
Annahme der kognitiven Psychologie, Bewußtseinsprozesse durch eine Interpretation des menschlichen
Gehirns als komplexe Rechenmaschine erklärbar machen zu können. Dabei würde gemeinhin verdrängt,
daß syntaktische und semantische Beschreibungen nur Konstrukt und dem Gehirn physiologisch
gesehen nicht intrinsisch seien. Insoweit wäre per se die Verwendung mentalistischer Konzepte auf ein
Agentensystem oder einen Thermostaten in keinem geringeren Maße gerechtfertigt als für das Gehirn!
– 24 –
2.3.2.2 Semantik mentalistischer Modelle
Eine solche Formalisierung wirft erhebliche Probleme auf. Zum einen sind die zugrundeliegenden umgangssprachlichen Begriffe unscharf definiert. Wann hat etwa ein Agent
ein Ereignis vorsätzlich verursacht? McCarthy illustriert die Schwierigkeiten einer
logisch präzisen Antwort am Beispiel der durchaus plausiblen Definition „Ein Agent hat
ein Ereignis vorsätzlich verursacht, wenn es nicht eingetreten wäre, wenn seine
Absichten anders gewesen wären.“ In der realen Welt existiert aber kein kartesisches
Produkt, so daß keine Aussage darüber gemacht werden kann, was ceteris paribus in
diesem Falle geschehen wäre. [McCarthy 1979, S. 8]
Weiterhin scheitert der Versuch, mentale Begriffe unmittelbar mit den Mitteln der
klassischen Logik zu beschreiben. Boolesche Logik arbeitet in Kategorien, mentale
Einstellungen sind nicht substituierbare Instanzen. Ist eine Aussage wahr, sind alle
äquivalenten Aussagen wahr. Glaubt jemand eine Aussage, glaubt er nicht zwangsläufig
alle inhaltlich gleichwertigen Aussagen.
Der erfolgreichste Ansatz sind die Possible Worlds Semantics (vgl. [Wooldridge/Jennings
1995, S. 12ff] für eine ausführliche und formale Einführung), die von Hintikka [Hintikka
1962] vorgeschlagen und von Kripke [Kripke 1963] axiomatisch formuliert worden sind.
Die Annahmen eines Agenten werden dabei als eine Menge möglicher Welten beschrieben. Eine mögliche Welt ist ein Zustand, der durch das verfügbare Wissen nicht
ausgeschlossen wird. Ein Grund für die Beliebtheit dieses Ansatzes ist, daß er hinsichtlich der Akquisition und Repräsentation des Wissens neutral ist. Formal beschrieben
wird er durch eine um die dualen Operatoren notwendigerweise ( ) und möglicherweise
(◊) erweiterte klassische Logik. Diese Operatoren beschreiben den Wahrheitsgehalt
einer Aussage in den möglichen Welten: w e i ß ein Agent Aussage ‚A’, so ist A
notwendigerweise in allen Welten wahr, weiß er dagegen nicht, daß A falsch ist, wird A
in einigen der möglichen Welten, also möglicherweise, wahr sein. Mit Hilfe der
Operatoren werden fünf Axiome definiert, die den Umgang mit Annahmen und Wissen
ermöglichen: Aus Wissen kann durch Implikation neues Wissen gewonnen werden
(Axiom K), das Wissen eines Agenten ist konsistent bzw. frei von Widersprüchen
(Axiom D), was gewußt (im Gegensatz zu nur geglaubt) wird, ist auch wahr (Axiom T,
knowledge axiom), der Agent weiß, was er weiß (Axiom 4, positive introspection
axiom), und der Agent weiß, was er nicht weiß (Axiom 5, negative introspection axiom).
– 25 –
Das weitreichende Axiom 5 wird nicht allgemein als Element der Definition von Wissen
akzeptiert. Die größten praktischen Probleme bereitet allerdings das elementare Axiom
K, da es zusammen mit der ebenfalls unverzichtbaren necessitation rule (jede gültige
Formel ist auch notwendigerweise gültig) impliziert, daß der Agent a l l e logischen
Konsequenzen seiner Annahmen ebenfalls annimmt, was den Horizont jedes realen
Agenten übersteigen dürfte (Logical Omniscience Problem). Dessen ungeachtet bildet
das Modell die Grundlage zahlreicher Agententheorien und der Spezifikation der
meisten Agentenkommunikationssprachen.
2.3.2.3 Agententheorien
Eine Agententheorie versucht, die ‚mentale Haltung’ eines Agenten in Attribute zu
fassen und diese miteinander strukturell und dynamisch in Beziehung zu setzen. Die
Liste der vorgeschlagenen Attribute umfaßt unter anderem Ziele, Bedürfnisse, Annahmen, Wissen, Handlungen, Wahlmöglichkeiten, Fähigkeiten, Beziehungen und Interaktionen.
Bratman [Bratman 1987] hat erstmals die besondere Bedeutung von Annahmen, Zielen
und Absichten herausgestellt und damit die Klasse der BDI (Belief-Desire24-Intention)
Theorien begründet. Die Verwendung der Possible Worlds Semantics zu ihrer Definition wirft allerdings ein schwieriges Problem auf: Axiom K impliziert, daß Agenten auch
alle Konsequenzen ihrer Absichten, also auch unerwünschte Nebeneffekte, beabsichtigen müssen.
Cohen und Levesque
Cohen und Levesque [Cohen/Levesque 1990] haben diesen Ansatz weiterentwickelt,
indem sie auf den Grundbegriffen Ziel und Annahme ein System abgeleiteter mentaler
Konstrukte aufstellen. Ein persistentes Ziel (Persistent Goal) ist etwa eine Aussage, von
der der Agent nicht glaubt, daß sie momentan wahr ist (Zielaspekt), und an der er
solange festhält, bis er glaubt, daß sie entweder wahr ist oder niemals wahr werden kann
24
Desire wird in diesem Zusammenhang als zu Goal äquivalenter Begriff verwendet.
– 26 –
(Persistenzaspekt). Eine Absicht (Intention) ist ein darauf aufbauendes Konstrukt: Wenn
der Agent sich in einer Situation befindet, in der er glaubt, eine Handlung ausführen zu
werden, ein persistentes Ziel hatte, diese Situation herbeizuführen und die Handlung
tatsächlich ausführt, dann lag eine Absicht vor. Neben dieser esoterisch anmutenden
Definition formulieren sie jedoch auch einen konkreten Absichtsbegriff, den sie mit
sieben Anforderungen an rationale Agenten illustrieren:
1. Absichten setzen Agenten Ziele, die es zu realisieren gilt.
2. Absichten führen zur Bildung neuer, zwingend nicht konfliktierender Absichten.
3. Agenten registrieren Erfolge und wiederholen gemeinhin gescheiterte Aktionen.
4. Agenten glauben, daß die Realisierung ihrer Absichten möglich ist.
5. Agenten glauben nicht, daß sie ihre Absichten nicht realisieren werden.
6. In gewissen Situationen glauben Agenten, daß sie ihre Absichten umsetzen werden.
7. Agenten müssen nicht unbedingt alle Seiteneffekte ihrer Absichten beabsichtigen.
Dieser Absichtsbegriff soll dem durch die vorgeschlagene Logik etablierten äquivalent
sein.
Rao und Georgeff
Inbegriff des BDI-Konzepts ist heute die von Rao und Georgeff in [Rao/Georgeff 1991]
vorgeschlagene alternative Theorie. Neben Annahmen und Zielen führen sie Absichten
direkt als Primitiv ein, da sie sich davon vielfältigere Anwendbarkeit, eine präzisere
Abgrenzung zwischen endogen (Entscheidung) und exogen (Handlungskonsequenz)
bestimmten Entwicklungen und eine Lösung für das Problem der unerwünschten
Seiteneffekte versprechen [ibid., S. 1].
Ihre Logik beruht auf dem Konzept des Zeitbaums (Time Tree). Zu jedem Zeitpunkt
existiert genau eine Vergangenheit, aber mehrere mögliche zukünftige Zustände. Jeder
Knoten beschreibt einen Zustand (Situation), jede Kante ein Ereignis (Event). Einzelne
Kanten können damit als Handlungen des Agenten, Pfade als Pläne oder Abläufe
verstanden werden. Die von einem Knoten abgehenden Kanten repräsentieren gleichzeitig die Wahlmöglichkeiten eines Agenten. Erfolg ist nicht impliziert – hat eine Hand-
– 27 –
lung mehrere mögliche Konsequenzen, etwa Erfolg und Scheitern, werden diese durch
getrennte Kanten modelliert.
Annahmen, Ziele und Absichten in einer Situation werden wiederum durch Possible
Worlds Semantics beschrieben. Dabei wird aber jede mögliche Welt durch einen
eigenen Zeitbaum, also eine strukturierte Menge von Zuständen, beschrieben. Ein in
einem solchen möglichen Zeitbaum erreichbarer Zustand heißt, je nach Typ des Baums,
belief-, goal- oder intention-accessible. Der angestrebte Zustand (Zielbaum) muß dabei
nicht vollständig den entsprechenden erwarteten Zustand beschreiben (Annahmenbaum), so daß als unvermeidlich anerkannte, aber unerwünschte Konsequenzen nicht
automatisch zu Zielen werden. Umkehrt gilt allerdings das Prinzip des starken Realismus: Jeder Zielbaum muß im entsprechenden Annahmenbaum enthalten sein, so daß die
Erreichung der Ziele nicht nur für nicht unmöglich gehalten wird (schwacher Realismus), sondern sogar ein konkreter Pfad zu jedem erreichbaren Zielzustand existiert. Der
Absichtenbaum ist wiederum im Zielbaum enthalten; beabsichtigte Zustände (Absichtenbaum) sind angestrebte Zustände, zu deren unmittelbaren Erreichung sich der Agent
verpflichtet hat.
Das vorgestellte Konzept ist elegant, erfordert allerdings eine komplexe modale Logik,
die auf Pfaden und Zuständen arbeitet. Neben den aus der temporalen Logik übernommenen Operatoren next, eventually, always und until führt diese noch die zusätzlichen
Pfadoperatoren inevitable (unvermeidbare Konsequenz) und optional (mögliche
Konsequenz) ein.25 Die Logik mit allen ihren Implikationen ist noch nicht erschöpfend
erforscht, jedoch ist absehbar, daß das Problem der formalen Verifikation von Modellen, schon in der klassischen Logik NP-vollständig, mit den verfügbaren Mitteln nicht
handhabbar ist (für eine ausführliche Analyse vgl. [Wooldridge 1998]).
Jennings und Wooldridge regen an, Agententheorien als Spezifikationen und ihre
logischen Formalismen als Spezifikationssprachen zu interpretieren, da zum einen viele
ihrer Probleme von klassischen Spezifikationssprachen her bekannt sind und zum
anderen ihre Nützlichkeit sich so durch ihre Ausdrucksfähigkeit in einem gegebenen
25
Im Grunde können die Operatoren als Allquantor und Existenzquantor für erreichbare Zustände
verstanden werden.
– 28 –
Kontext unmittelbar bewerten läßt [Wooldridge/Jennings 1995, S. 22]. In Anbetracht
ihres mathematisch-formalen Charakters und der hohen logischen Komplexität der
meisten vorgeschlagenen Theorien scheint aber ihre Anwendung als Spezifikationssprache durch die breite Masse der Softwareentwickler noch in weiter Ferne zu liegen.
2.3.3 Physikalische Abstützung
Verfechter einer ‚schwächeren’ KI lehnen nicht nur mentalistische Methoden, sondern
die Verwendung symbolischer Logik generell ab. Brooks [Brooks 1990] argumentiert,
daß ein solcher Ansatz fundamental ungeeignet sei, um Agenten mit ‚pragmatischer’
Intelligenz zu konstruieren, die sich in realistischen Szenarien behaupten können.
Eines der grundlegendsten von der frühen KI-Forschung etablierten Konzepte ist die
Hypothese, daß Intelligenz durch ein System von Symbolen realisiert wird. Denken
wird damit zur kontextfreien Manipulation von Symbolen gemäß prinzipieller Regeln.26
Als Folge dieser Sicht ergibt sich, daß die Objekte der realen Welt im Modell durch
abgegrenzte, benannte Symbole repräsentiert werden müssen. Diese Symbole sind
jedoch nicht intrinsischer Teil der beschriebenen Welt, sondern die Konstruktion eines
Beobachters. Bewegt sich nun ein Agent in einem nichttrivialen Umfeld, muß sein
Wahrnehmungssystem die Welt (nach universellen, problemneutralen Grundsätzen) in
entsprechende Symbole umsetzen. Dabei wird oft angenommen, die erzeugte Interpretation würde eine objektive Aussage über die Wirklichkeit machen. In Wahrheit handelt
es sich jedoch nur um ein Modell der Wirklichkeit, das eine zweckorientierte27, subjektive Beschreibung liefert. Das Problem bei der Verwendung formaler Logik ist nun, daß
subjektive Wahrheiten mit einem im Kern objektiven Formalismus beschrieben werden
sollen. Modale Logik begegnet diesem Problem zwar, führt aber zu einem ‚unnatürlichen’ Verständnis kognitiver Prozesse und nicht handhabbarem Rechenaufwand. Das
wohldokumentierte Problem der Explizierung aller Annahmen (Frame Problem) ist eine
weitere unerwünschte Konsequenz [ibid., S. 2].
26
27
Hier greift wiederum die bereits zitierte Kritik von Searle (vgl. Fußnote 23, S. 19).
Zur Zweckorientierung als notwendiges Merkmal von Modellen vgl. etwa [Holten 1999, S. 9].
– 29 –
Als Alternative schlägt Brooks das Prinzip der physikalischen Abstützung vor (Physical
Grounding) [ibid., S. 3ff], das durch seine Arbeiten an praxistauglichen Physical Agents
motiviert ist. Seine These ist, daß das objektivste Modell der Welt die Welt selbst ist,
und daher jede Wissensrepräsentation direkt in ihr verankert sein sollte. Wissen wird
nicht gespeichert, sondern möglichst kontinuierlich von problemspezifischen Sensoren
aus der Umwelt abgeleitet. Umgekehrt werden Absichten unmittelbar durch Effektoren
umgesetzt. Das intelligente System kann durchaus höhere Abstraktionsebenen besitzen,
die sich aber explizit auf die niedrigeren Systemebenen abstützen müssen. Das System
ist streng hierarchisch und wird von unten nach oben konstruiert. Die SubsumptionArchitektur [ibid., S. 4] ist die Implementierung eines solchen Systems auf Basis von
Netzen endlicher Automaten und ist von zahlreichen Robotern erfolgreich eingesetzt
worden.
Für das Metamodell liefert diese Theorie wesentliche Anregungen, da sie eine ganzheitliche Sicht des Systems fördert und die technische Umsetzung intelligenten Verhaltens
in den Vordergrund stellt.
2.3.4 Agentenkommunikation
Die Kommunikation zwischen Agenten ist natürlich gerade in interaktionszentrischen
Modellen von zentraler Bedeutung, so daß ihrer Beschreibung bei der Konstruktion von
Multiagentensystemen eine große Wichtigkeit zukommt. Aus diesem Grund konzentrieren sich die bisherigen Bemühungen, Standards für Agentensysteme zu definieren, vor
allem auf diesem Gebiet.28
Kommunikation beruht auf der Existenz einer von Sender und Empfänger geteilten
Interpretation einer Nachricht. Für die Interaktion zwischen Agenten sind dabei zwei
Aspekte relevant: Zur Kommunikation auf der Sachebene wird eine verbindliche
Definition der Grundbegriffe und Kompositionsregeln zur Formulierung von faktischen
Aussagen bezüglich ihrer Umwelt (bzw. ihrer Problemdomäne) benötigt. Der Austausch
28
An dieser Stelle soll die theoretische Seite entsprechender Definitionen im Vordergrund stehen.
Bezüglich der praktischen Implikationen ihrer Verwendung als Standards siehe Abschnitt 2.5.1, S. 45.
– 30 –
über Absichten und Einstellungen von Agenten erfordert eine Möglichkeit zur Formulierung von Aussagen zweiter Ordnung, die faktische Aussagen im Sinne der modalen
Logik näher qualifizieren.
Das erste Problem entspricht der Frage nach adäquater Wissensrepräsentation in
wissensbasierten Systemen und kann sich daher auf eine umfangreiche Literatur
abstützen. Das zentrale Problem beim Wissensaustausch ist die Verständigung auf eine
konsistente gemeinsame Ontologie. Gruber [Gruber 1993] definiert eine Ontologie in
diesem Kontext als „Spezifikation einer Konzeptualisierung“, eine formale Beschreibung der in einer Domäne zulässigen Konzepte und Beziehungen zwischen diesen
Konzepten.29 Diese Konzepte müssen dann mit einer geeigneten Syntax, etwa unter
Verwendung von Prädikaten, XML [Bray et al. 2000] oder LISP [Steele 1990] Listen,
versehen werden.
Die Kommunikation von Absichten und Einstellungen wird durch die Theorie der
Sprechakte (Speech Acts) adressiert. Sprechakte sind Aussagen, die wahr werden, indem
sie ausgesprochen werden.30 Verschiedene Nachrichtentypen lassen sich durch Klassen
von Sprechakten beschreiben [Labrou et al. 1999, S. 46]. Die Semantik der Sprechakte
selbst wird dabei zumeist wieder durch eine modale Logik im Sinne einer Agententheorie beschrieben.
Die beiden prävalenten Agentenkommunikationssprachen (ACL) sind KQML (Knowledge Query and Manipulation Language) [KSE 1993], die im Zuge des 1990 von der
ARPA initiierten Knowledge Sharing Effort (KSE) [KSE] entstanden ist, und FIPA
ACL ([FIPA C00007], [FIPA C00008], [FIPA C00009], [FIPA C000010], [FIPA C000011]
und [FIPA C00037]), die eine Weiterentwicklung der bei France Télécom entwickelten
Sprache Arcol darstellt.
29
In diesem Sinne kann auch das vorliegende Metamodell als Versuch, eine Ontologie der Agentenorientierung aufzustellen, interpretiert werden.
30
Die Aussage des Priesters „Hiermit erkläre ich Euch zu Mann und Frau.“ ist etwa ein alltägliches
Beispiel für einen solchen Sprechakt.
– 31 –
KQML
Die Entwicklung von KQML ist ein dezentraler Prozeß, der von einer großen Anzahl
unabhängiger Forscher vorangetrieben wird. Dies führt einerseits zu einer unüberschaubaren Anzahl von Varianten und sogar zur Formulierung konkurrierender Spezifikationen [Labrou/Finin 1997a], andererseits aber auch zu einer großen Anzahl von Implementierungen, die die vorgeschlagenen Konzepte testen, erweitern und verbessern.31 Die
Semantik von KQML ist im ursprünglichen Entwurf nur informal spezifiziert [KSE
1993, S. 8ff]. Der Ansatz ist pragmatisch, bei der Einführung der zahlreichen Performatives (Typen von Sprechakten) geht Ausdrucksvermögen vor Minimalismus [ibid., S.
13]. Jeder Implementierung steht es frei, Performatives hinzuzufügen oder wegzulassen,
solange die vordefinierten nicht umdefiniert werden [ibid., S. 4]. Zur Definition von
Ontologien wird die Sprache Ontolingua verwendet, von einigen Dialekten auch KIF
(Knowledge Interchange Format) [Labrou et al. 1999, S. 46]. Die eigentliche Wissensrepräsentation wird allerdings auf der Inhaltsebene intransparent gekapselt. Die Kommunikationsebene besteht aus Absender, Adressat und einer eindeutigen Nummer. Die
Nachrichtenebene enthält das Performative sowie Metadaten wie die verwendete
Ontologie und die Kodierung des Inhalts. Die eigentliche Nachricht ist eine Liste im
LISP-Stil. Als Reaktion auf Kritik an der Spezifikation wurden die Performatives später
mit einer (nicht näher spezifizierten) BDI-Logik formalisiert, was zwar eine entsprechende Agentenarchitektur nahe legt, aber nicht vorschreiben soll. Jedes Performative
wird durch Preconditions, die Bedingung, aber nicht Auslöser sind, Postconditions, die
nach erfolgreicher Durchführung erfüllt sein müssen, und Completion Conditions, die
die Bedingungen für eine erfolgreiche Ausführung festlegen, beschrieben.
FIPA ACL
FIPA ACL ist KQML oberflächlich sehr ähnlich (vgl. [Labrou 2001, S. 11f]). Die
prolog-basierte Syntax von Arcol wurde bewußt an die LISP-Syntax von KQML
angepaßt, um die Wiederverwendung existierender Parser zu ermöglichen. Auf der
31
Der Entwicklungsprozeß von KQML weist interessante Parallelen zu den größeren der aktuellen
Projekte zur Entwicklung von Open Source Software auf.
– 32 –
semantischen Ebene sind die Unterschiede allerdings so groß, daß eine Übersetzung der
meisten Performatives in entsprechende Communicative Acts der FIPA ACL nicht
möglich ist. Die Sprache ist ein synthetisches Produkt, bei dessen Erarbeitung auf
konzeptionelle Sauberkeit und eine formale Spezifikation Wert gelegt wurde, das aber
über lange Zeit von keinem System implementiert wurde.32 Sie bietet vergleichsweise
wenige, generische Sprechakte, deren Interpretation allerdings erheblich höhere
Anforderungen an Agenten stellt (vgl. [Labrou 2001, S. 10]). Zur Spezifikation wird ein
um unsichere Annahmen (Uncertain Belief) erweitertes BDI-Modell verwendet, mit
dessen Hilfe für jeden Akt notwendige Feasibility Preconditions und der erwartete
Rational Effect, der aber keine Bedingung für konformes Verhalten ist, festgelegt
werden.
Kritik
Beide Sprachen teilen das Problem, nicht trotz, sondern gerade wegen ihrer formalen
Semantiken nicht verifizierbar zu sein. Da die zu ihrer Spezifikation verwendeten
Formeln der jeweils zugrundegelegten modalen Logik hochgradig unentscheidbar sind
[Wooldridge/Jennings 1995, S. 25], kann die Konformität einer Implementation nicht
formal bewiesen werden. Somit sind Inkonsistenzen zwischen verschiedenen Systemen
fast unvermeidlich.
Singh geht in seiner Kritik [Singh 1998a] noch weiter und erklärt die verwendeten
formalen Semantiken schon im Ansatz für unzureichend, um offene Systeme (mit
potentiell böswilligen Agenten) zu modellieren oder Interoperabilität zwischen den
Systemen verschiedener Entwickler zu gewährleisten. Die Beschreibung in mentalistischen Begriffen betont die private Perspektive des Agenten [ibid., S. 40]. Wie anfangs
erwähnt ist Sprache jedoch ein soziales Konstrukt. Formal ließe sich etwa das Konzept
der Lüge korrekt als ‚Agent L äußert Aussage A und nimmt gleichzeitig ¬A an’ fassen.
Dies entspricht nur auf den ersten Blick der intuitiven Definition. Ob ein Agent gelogen
hat, läßt sich nicht allein aus seinem Verhalten bestimmen, sondern hängt von seinen
Annahmen, also einem Aspekt seines nicht beobachtbaren mentalen Zustandes, ab.
32
Inzwischen existieren Implementationen in Form von JADE [JADE] oder JFIPA [JFIPA].
– 33 –
Implementiert der Agent keine BDI-Architektur, existiert die Annahme noch nicht
einmal konkret, sondern nur in der Interpretation seines Programmierers! Die Interaktion zwischen Menschen wird dagegen von sozialen Konventionen geregelt [ibid., S. 45].
Sie kommt ohne die von den ACLs angenommene White Box (‚Gedankenlesen’) aus, da
Konformität ausschließlich auf Grundlage des Verhaltens des Agenten beurteilt wird.
Außerdem kritisiert Singh die mangelnde Expressivität der Sprachen [ibid., S. 43]. Ein
verbreiteter Effekt in KQML-Systemen ist, daß fast ausschließlich Nachrichten mit
dem Performative ‚tell’ ausgetauscht werden, während die Semantik der eigentlichen
Anwendung im Inhalt der Nachrichten definiert wird.33 Den Grund für diesen Effekt
sieht er darin, daß die zahlreichen Sprechakte der ACLs in lediglich zwei Klassen
fallen: Aufforderungen und Beteuerungen. In der menschlichen Kommunikation
existieren jedoch mindestens noch fünf weitere Kategorien: Erlaubnis, Verbot, Versprechen, Deklaration und Meinungsäußerung.
Die Interoperabilität zwischen Systemen ist somit auf gleich zwei Ebenen gestört. Als
Ausweg regt Singh an, in einer hybriden Spezifikationssprache die Konkretheit sozialer
Konventionen mit der Mächtigkeit mentalistischer Attribute zu verbinden [ibid., S. 46f].
2.4
Agenten im Modell
Die Einteilung der im Anschluß umrissenen Konzepte in Modelle, Methodologien und
Modellierungssprachen sei als weitgehend wertungsfreies Strukturierungsmittel
verstanden, da sich diese Aspekte in konkreten Vorschlägen oft überlagern und
vermischen. Modellierungssprachen implizieren oft eine Methodologie, und viele
Vorgehensmodelle beziehen sich auf eine konkrete Architektur.
33
Dies ist im Grunde dasselbe Problem, das auftritt, wenn ein Agent mit rein objektorientierten Methoden
beschrieben werden soll. Das Ergebnis ist ein Objekt mit ca. zwei sehr mächtigen Methoden, act()
und receive(Message), die über seine Funktionsweise so gut wie nichts aussagen.
– 34 –
2.4.1 Referenzmodelle
Ähnlich wie das vorgestellte Metamodell versuchen Referenzmodelle, eine möglichst
allgemeingültige aber gleichzeitig konkrete Beschreibung eines Agentensystems zu
ermöglichen, so daß hier eine gewisse inhaltliche Nähe besteht. Die betrachteten
Referenzmodelle setzen dabei jedoch jeweils andere Schwerpunkte: die einen konzentrieren sich auf bestimmte Teilperspektiven des Systems, während andere mehr Wert
auf direkte Implementierbarkeit legen und daher einen stärker normativen Charakter
besitzen.
Referenzmodelle versprechen eine Standardisierung der Terminologie und der Technologie. In der noch jungen Agentenorientierung ist dieser Effekt jedoch noch nicht
eingetreten, da grob geschätzt mehr Referenzmodelle existieren als Agentenplattformen,
die eine fr e m d e Referenzarchitektur implementieren.
JAFIMA - Java Framework for Intelligent and Mobile Agents
JAFIMA (Java Framework for Intelligent and Mobile Agents) ist ein implementierungsorientierter Architekturvorschlag ([Kendall et al. 1998b], [Kendall et al. 1999]), der
sich das ehrgeizige Ziel setzt, allgemein anerkannte Begriffsdefinitionen und Architekturprinzipien zu liefern und gleichzeitig operationalisierbare Anforderungsdefinitionen
an kommerzielle Systeme zu ermöglichen und Kompatibilität zwischen verschiedenen
Agentensystemen zu garantieren [Kendall et al. 1998b, S. 1]. Die Architektur basiert auf
dem schwachen und starken (hier als ‚wissensbasiert’ interpretiert [ibid., S. 2]) Agentenbegriff von Jennings und Wooldridge. Externe Objekte werden über Sensoren wahrgenommen und zu Annahmen verarbeitet. Eine ausdrucksbasierte Inferenzkomponente
verarbeitet diese und instantiiert aus einem Schatz von Fähigkeiten eine oder mehrere
Absichten als eigenständige Threads, in deren Rahmen Externe Objekte wiederum über
Effektoren manipuliert werden. Das Modell ist in einer Schichtenarchitektur strukturiert,
in der zunehmend abstrakte Ebenen jeweils nur mit den benachbarten Ebenen in
Beziehung stehen sollen [ibid., S. 2]. Die Ebenen sind Sensory (Wahrnehmung), Beliefs
(Annahmen), Reasoning (Inferenz), Actions (Ausführung der Absichten), Collaboration
(Zusammenarbeit mit anderen Agenten), Translation (Übersetzung von Nachrichten in
andere Ontologien) und Mobility (Migration) [ibid., S. 3]. Die Elemente der einzelnen
Ebenen werden durch objektorientierte Entwurfsmuster (Scheduler, Mediator, Visitor,
– 35 –
Factory, Broker, Observer etc.) spezifiziert ([Kendall et al. 1999, S. 5ff] und [Kendall et al.
1997]). Wie bereits der Name andeutet, wird dabei auf eine Implementierung in Java
abgezielt.
Das Modell ist interessant, da es versucht, den starken Agentenbegriff mit Hilfe von
softwaretechnisch fundierten Methoden umzusetzen. Allerdings dürfte das Ziel, durch
konkrete Festlegungen Interoperabilität auf einer technischen und semantischen Ebene
zu ermöglichen, in einem prinzipiellem Konflikt zu seinem allgemeinen Anspruch
stehen. Zudem fehlt eine Modellierung der Umwelt und sozialer Aspekte. Aus modelltheoretischer Sicht erscheint zudem das formulierte Ebenenmodell nicht konsistent mit
der zugrundegelegten Definition einer Schichtenarchitektur: die höheren Ebenen sind
weniger zunehmend starke Abstraktionen als vielmehr vernetzte nebengeordnete
Funktionsmodule.
Referenzmodell für die Überwachung mobiler Agentensysteme
Ein bemerkenswertes Modell wird von Silva et al. vorgeschlagen [Silva et al. 2001]. Es ist
das einzige unter den im Rahmen dieser Arbeit vorgestellten Konzepten, das einen
möglichst neutralen Ansatz im Stil des hier vorgelegten Metamodells verfolgt und
weder ein bestimmtes Anwendungsgebiet unterstellt noch eine eigene Architektur zu
propagieren versucht. Es soll vor allem ein deskriptives Werkzeug sein, das eine
Erörterung und Klassifikation von Agentenarchitekturen (primär für mobile Agenten)
erlauben soll. Dabei konzentriert es sich auf eine statische Erfassung der bereitgestellten
Infrastruktur. Die Perspektive ist konzeptionell und verhältnismäßig grobkörnig: Das
Modell definiert wesentliche Grundbegriffe und generische Architekturelemente, die
von konkreten Systemen entsprechend parametrisiert werden müssen.
Die Autoren sehen Agentensysteme als evolutionäre Weiterentwicklung von Komponententechnologien und beziehen sich konsequenterweise auf den schwachen
Agentenbegriff gemäß Jennings und Wooldridge. MAS (von den Autoren im Rahmen des
Modells abweichend als Mobile Agent Systems definiert) stellen dabei sowohl konzeptionell als oft auch technisch eine Zwischenebene zwischen objektorientierter
Middleware (CORBA, Java RMI) und agentenbasierten Anwendungen im Sinne des
starken Agentenbegriffs (ABA) dar. Das MAS basiert auf den Diensten der Middleware,
die ABA auf der Infrastruktur des MAS [Silva et al. 2001, S. 189f].
– 36 –
Die definierte Begriffswelt ist übersichtlich. Agenten sind aktive Objekte, die stellvertretend und autonom spezifische Aufgaben ausführen, wobei mindestens ein eigener
Thread vorgeschlagen wird. Sie sind Instanzen von Agententypen, in deren Rahmen
auch die bei Migration wichtigen assoziierten Ressourcen wie etwa Quellcode verwaltet
werden. Ein Node ist ein physikalischer Netzwerkknoten. Der Begriff des MAS umfaßt
die gesamte (Software) Infrastruktur, die von den Agenten benötigt wird, also insbesondere auch die Ausführungsumgebung in Form eventueller Virtual Machines. Mehrere
MAS können sich einen Node teilen. Die öffentlichen Schnittstellen des MAS konstituieren den Context, die logische Repräsentation des MAS. Innerhalb des Contexts besetzen
die Agenten Places, über die sie adressierbar sind. Jeder Agent hat einen Benutzer, der
besondere Zugriffsrechte auf ihn hat. Auf der Ebene der ABA existieren ein oder
mehrere Agenten, die eine Community bilden und eine gemeinsame Kommunikationsund Wissensrepräsentationssprache teilen. Die Beziehungen und Mechanismen auf
dieser Ebene werden allerdings nicht vertieft [ibid., S. 191-194].
Das MAS wird dagegen weiter differenziert in das Agent Execution System (AES), das
die grundlegenden Dienste wie Kommunikation und Migration steuert, das Agent Type
System (ATS), das die Agententypen verwaltet, und das Agent Execution Environment
(AEE), in dem die Agenten ausgeführt werden. Die erste Klassifikation erfolgt danach,
ob und in welcher Form diese Elemente in einem Agentensystem existieren. Das AEE
ist in den meisten Fällen einfach die Java Virtual Machine (JVM), wobei oft auch das
AES zusammen mit den Agenten auf dem AEE ausgeführt wird. Das AES kann aber
auch in einem separaten Betriebssystemprozeß laufen, während das AEE ein Interpreter
für eine Agentenskriptsprache ist [ibid., S. 194f].
Die genaue Klassifikation erfolgt gemäß der Umsetzung der einzelnen Basisdienste
(jeweils nur eine beispielhafte Auswahl der Kategorien angegeben): Art der Ausführungsumgebung (Java, Skriptsprache), Typensystem, Identitäts- und Adreßmanagement
(linear/hierarchisch), Persistenz (Agenten/Ressourcen, explizit/implizit, zustandsbehaftet/zustandslos), Migration (zustandsbehaftet/zustandslos, Codeverwaltung), Kommunikation (Synchron/asynchron, direkt/indirekt, point-to-point/broadcast), Proxies (Nachsenden von Nachrichten), Ressourcenverwaltung und Sicherheit (Authentifizierung,
Zugriffsrechte, Integrität) [ibid., S. 196-207].
– 37 –
Abschließend stellen die Autoren fünf populäre Agentenplattformen vor und demonstrieren anhand dieser die Anwendbarkeit ihres Modells auf verschiedene Architekturen.
In zwei Tabellen bilden sie ihre Grundbegriffe mit der Begriffswelt der Plattformen
nach und ordnen die Umsetzung jedes Basisdienstes in eine der definierten Kategorien
ein [ibid., S. 220-225]. In diesem Zusammenhang wird eine Limitation des Modells
deutlich. Es läßt eine übersichtliche Klassifikation, aber keine Spezifikation von
Agentenplattformen zu. Die definierten Modellelemente sind verhältnismäßig grobkörnig und, da sie nur informell definiert werden, nicht auf eine konkretere Ebene abgestützt. Auch die Kategorien sind nur in ihrem eigenen, möglicherweise sehr komplexen
Kontext definiert. Innerhalb des Modells kann etwa etabliert werden, daß zwei Systeme
hierarchische Adressen, Java Methodenaufrufe als Medium und KQML als ACL
verwenden. Die Systeme könnten trotzdem vollkommen inkompatibel sein, was nur
unter Verlassen der Begriffswelt des Modells geklärt werden kann.
Am Rande stellt sich die Frage, warum die Autoren mit keinem Wort das Verhältnis
ihres Vorschlags zu den einschlägigen Standards der FIPA34 erwähnen, dessen Limitationen von ihrem Modell implizit adressiert werden. Das Klassifikationsschema ist in
seiner Domäne zweifellos von Nutzen und beleuchtet viele relevante Charakteristika
von Agentensystemen.
Modell von Odell und Parunak
Auf einer im Vergleich etwas abstrakteren Ebene untersuchen Odell und Mitarbeiter des
ERIM (Environmental Research Institute of Michigan) das Verhältnis zwischen
Agenten und ihrer Umwelt, das sie als zentral für jedes Agentenkonzept ansehen [Odell
et al. 2002]. Die Umwelt legt die Grundlage und stellt die Rahmenbedingungen für die
Handlungen des Agenten [ibid., S. 1]. Aufgrund der praxisorientierten Ausrichtung des
ERIM auf Simulationsmodelle und physikalische Systeme denken sie in diesem
34
Relevant wären hier die FIPA-Standards 00001 (Referenzarchitektur) [FIPA C00001] und 00023
(Infrastruktur zum Agentenmanagement) [FIPA C00023] (siehe Abschnitt 2.5.1.2, S. 47). Sie definieren,
allerdings mit einen normativen Anspruch, ähnliche Architekturelemente, wobei sie mehr auf Tiefe
(Spezifikation von Namenskonventionen und Dienstprotokollen) als auf Breite (Punkte wie Sicherheit,
Persistenz oder Ressourcenmanagement werden nicht addressiert) abzielen.
– 38 –
Zusammenhang zunächst an die physikalische Umgebung (sei sie nun simuliert oder
real) eines Agenten. Diese läßt sich mittels verschiedener Eigenschaften wie Orts- und
Zeitbegriff, Vorhersagbarkeit, Änderbarkeit und Flüchtigkeit sowie anhand charakteristischer Prozesse näher beschreiben [ibid., S. 2ff]. Die von einer Agentenplattform
bereitgestellte Infrastruktur läßt sich auf dieser Ebene erfassen [ibid., S. 4]. Darüber
hinaus erkennen sie aber auch die Notwendigkeit zur Beschreibung des sozialen
Umfeldes eines Agenten. Dieses wird durch ihre Kultur, bestehend aus Sprache,
Interaktionsprotokollen, sozialen Regeln und einer kooperativen oder kompetitiven
Philosophie, bestimmt. Bestimmte Prozesse (Kontrollmechanismen zur Wahrung der
Kultur, Verzeichnisdienste) halten sie dabei für unverzichtbar.
Auf der Grundlage dieser Beobachtungen werden kein Strukturmodell und keine
formalisierte Ontologie definiert, so daß keine exakte, standardisierte Klassifikation
verschiedener Agentensysteme möglich ist. Die herausgestellten Aspekte liefern aber
wertvolle Impulse für den Entwurf eines solchen Strukturmodells.
Das EMS Modell
Ebenfalls aus dem Bereich der Simulation stammt das EMS (Effector-Medium-Sensor)
Modell von Lind [Lind 1998]. Ziel ist die Spezifikation eines generischen Testbetts für
Agentensysteme (und dessen Implementierung in Java), wobei naturgemäß der
Schwerpunkt auf der Interaktion von Agenten(systemen) mit ihrer Umwelt liegt. Die
Architektur bietet drei Abstraktionsebenen, die die Grundelemente (Sensor, Wahrnehmung, etc.), die elementaren Prozesse (z.B. Event Queue/Dispatcher) und anwendungsspezifische Objekte, etwa topologische Strukturen mit Methoden zur Navigation [ibid.,
S. 8]. Da das System die Umwelt, also den Gegenpart, für andere Agentensysteme
liefern soll, ist seine Perspektive in gewisser Weise invertiert, liefert aber dadurch
interessante Beobachtungen und Anregungen bezüglich der Beziehung zwischen
Agenten und ihrer Umwelt.
2.4.2 Methodologien
Agentenorientierte Methodologien müssen einen Mittelweg dazwischen finden, zu
spezifisch auf eine bestimmte Architektur ausgerichtet oder so generisch zu sein, daß
sich kein klarer Pfad zur Implementierung mehr angeben läßt. Bei den aufgeführten
– 39 –
Methodologien sind im Rahmen dieser Arbeit weniger die eigentlichen Vorgehensmodelle als die Frage von Interesse, welche Auswahl von Elementen als aussagekräftig für
die Spezifikation von Systemen angesehen wird.
MASE - Multiagent Systems Engineering
Wood und Deloach schlagen die architekturunabhängig ausgelegte Multiagent Systems
Engineering (MASE) Methodologie vor [Wood/Deloach 2001, S. 207]. Aufgrund der
gesetzten Prämissen ist sie nur für geschlossene, statische (keine Erzeugung neuer
Agenten, keine Mobilität) Systeme mit wenigen Agentenklassen geeignet [ibid., S. 208].
Ausgehend von einem existierenden Anforderungsprofil sieht das Phasenmodell [ibid.,
S. 209-218] sieben Schritte vor:
1. Erfassung der Ziele. Der Ansatz baut hier auf der Arbeit von Kendall [Kendall et al.
1998a] auf. Sie sieht zielbasierte Modellierung als effizientes Mittel zur Beherrschung komplexer, realistischer Szenarien, da Ziele (Was?) stabiler sind als Prozesse
(Wie?). Ziele (Goals) werden zunächst aus allen verfügbaren Quellen zusammengetragen und anschließend in ihren relevanten Anwendungskontext eingebettet. Die
resultierenden Szenarien (Goal Cases) werden hierarchisiert und in wiederverwendbare objektorientierte Bausteine (Goal Case Objects) zerlegt [ibid., S. 2-7].
2. Anwendungsfälle anwenden. Die im Anforderungsprofil identifizierten Use Cases
werden in abstrakte UML Sequenzdiagramme umgeschrieben, um die Interaktionen
(Conversations) zwischen den beteiligten Akteuren genauer zu spezifizieren.
3. Rollen detaillieren. Für jedes Ziel wird eine Rolle definiert, die für die Verfolgung
des Ziels zuständig ist. Die Erfolgsbedingungen für jede Aufgabe werden in einem
UML Zustandsdiagramm festgehalten.
4. Agentenklassen erstellen. Die Akteure werden mit ihren Conversations und den
Rollen, die sie übernehmen, zu Agentenklassen zusammengefaßt.
5. Konversationsprotokolle erstellen. Die Conversations werden als Paare von
Zustandsdiagrammen detailliert spezifiziert.
6. Agentenklassen konstruieren. Das Innenleben der Agentenklassen wird mit den
Mitteln der verwendeten Architektur implementiert.
– 40 –
7. Systementwurf. Die (zur Entwurfszeit ja bereits bekannten) Agenteninstanzen
werden benannt und mit einem Einsatzdiagramm auf die verfügbaren Plattformen
verteilt.
Die Methodologie ist auf mehreren Ebenen interessant: Im Rahmen der gesetzten
Grenzen schafft sie es, von der Architektur zu abstrahieren und trotzdem implementierbare Spezifikationen zu erzeugen. Die Bedeutung von Zielen und ihre Beziehung zu
Rollen wird herausgestellt. Vertraute objektorientierte Notationen werden geschickt
eingebunden.
Gaia
Die Gaia Methodologie [Wooldridge et al. 2000] zielt auf makroskopische Agentensysteme ab, in denen jeder Agent einen eigenen Prozeß darstellt. Die gemachten Einschränkungen ähneln denen bei MASE: modelliert werden geschlossene Systeme mit
statischen Strukturen und Fähigkeiten, mit einer begrenzten Zahl von Agentenklassen
und frei von Zielkonflikten [ibid., S. 286].
Die Modellierung [ibid., S. 286-298] erfolgt ebenfalls unter Verwendung von Rollen.
Diese beschreiben die Aktivitäten eines Agenten und seine Interaktionen mit anderen
Agenten (Protocols). Dabei werden jeder Rolle Rechte (Permissions) und Pflichten
(Responsibilities) zugeordnet. Pflichten zwingen entweder zur aktiven Verfolgung eines
Entwurfsziels (Liveness Responsibility) oder zur Einhaltung bestimmter Grenzen (Safety
Responsibility) und werden als Pascal-ähnlicher Pseudocode spezifiziert. Die von den
Rollen somit erbrachten Dienste werden zusammenfassend im Dienstmodell (Service
Model) illustriert, ihre Austauschbeziehungen im Beziehungsmodell (Acquaintance
Model).
An dieser Stelle zeichnet sich bereits ein wiederkehrendes Problem bei der Modellierung von MAS ab. Im Zentrum einer agentenorientierten Perspektive steht die Betrachtung von I n t e r a k t io n e n zwischen verschiedenen autonomen Agenten. Die Methoden
zu deren Modellierung skalieren aber nur eingeschränkt auf große, heterogene oder gar
offene Systeme, da die Anzahl der möglichen Interaktionsbeziehungen schnell explosiv
zunimmt.
– 41 –
KAoS - Knowledgeable Agent-oriented System
Der Entwurf von KAoS (Knowledgeable Agent-oriented System) [Bradshaw 1996] ist
durch die zwei elementaren Hindernisse für Interoperabilität zwischen Agentensystemen, die uneinheitliche Infrastruktur und die uneinheitliche Semantik, motiviert. Das
infrastrukturelle Problem wird durch eine Abstützung auf existierende Middleware wie
CORBA oder DCOM adressiert. Definierendes Merkmal der Methode sind aber die
Conversation Policies. Während im Rahmen von ACLs wie KQML die Semantik auf
der Ebene einzelner Nachrichten definiert wird, benutzt KAoS Netzpläne, die zulässige
Austauschmuster festlegen. Die Bedeutung der Nachrichten kann so aus ihrem Kontext
heraus besser verstanden werden, wobei allerdings der genaue Effekt der gesamten
Konversation und der einzelnen Nachrichten nur informell beschrieben zu werden
scheint.
Bond Component Agent Model
Bölöni und Marinescu schlagen ein Modell vor, dessen Ziel es ist, eine effiziente
Umsetzung eines starken Agentenbegriffs auf Grundlage existierender Softwaretechnik
zu ermöglichen [Bölöni/Marinescu 1999]. Daher soll das Modell es vermeiden, für
Konzepte nicht realistisch implementierbare formale Definitionen vorzuschreiben,
sondern ihre konkrete Umsetzung dem Ermessen des Entwicklers überlassen. Die
Autoren sehen es als eingeschränkte, aber auch pragmatischere Variante klassischer
BDI-Modelle [ibid., S. 1].
Die Methode definiert zunächst ein ‚objektives’ Modell der Welt aus Sicht eines
externen Beobachters [ibid., S. 2]. Diese besteht aus Objekten, deren Eigenschaften
durch Ereignisse verändert werden. Ereignisse, die durch Agenten herbeigeführt
werden, heißen Aktionen. Dabei wird unterschieden, ob die Welt deterministisch oder
nichtdeterministisch auf Aktionen reagiert. Agenten werden aus Sicht der Welt nach
ihren Aktionen beurteilt; zwei Agenten mit derselben Verhaltensfunktion sind äquivalent. Entwurfsziele (‚erwünschter Zustand der Welt’) werden auf dieser Ebene aus Sicht
des Beobachters definiert.
Das zweite Teilmodell [ibid., S. 3f] beschreibt die subjektive Weltsicht aus Agentenperspektive. Agenten konstruieren sich eine Repräsentation der Welt, die sie durch stete
Wahrnehmung aktuell zu halten versuchen. Da Entwurfsziele und Aktionen auf der
– 42 –
Grundlage der objektiven Weltsicht definiert worden sind, sind sie in diesem Zusammenhang nicht direkt darstellbar und müssen durch eine Agenda und Strategien
nachgebildet werden.
Interessant ist vor allem diese Darstellung des Dualismus zwischen realer und
wahrgenommener Welt. Agenten handeln, indem sie vor dem Hintergrund ihrer Agenda
den Zustand ihres Modells der Welt beurteilen und passende Strategien auswählen.
Dabei besteht das im Zusammenhang mit der physikalischen Abstützung beschriebene
Problem, die Repräsentation der Welt ständig aktuell halten zu müssen, da sonst das
Risiko einer Selbsttäuschung besteht: Eine unkritische Beurteilung der eigenen Repräsentation führt schnell dazu, daß ein Agent seine Ziele zwar in seiner Einbildung, nicht
aber in der Realität erreicht hat.
Multi-Context-Agents
Parsons et al. beschäftigen sich mit der Frage der semantischen Integration zwischen
bereits existierenden (wissensbasierten) Architekturen [Parsons et al. 2002]. Als einen
Mangel aller existierenden Modellierungsmethoden bezeichnen sie, daß sie zwar einer
bestimmten Architektur verhaftet sind, gleichzeitig aber die Elemente dieser Architektur
nicht explizit ausdrücken können und eine Lücke zwischen Spezifikation und Implementierung lassen [ibid., S. 1f]. Abhilfe soll die Verwendung von Multi-Context Systems
schaffen, die für die verschiedenen Komponenten des Gesamtsystems die jeweils am
besten geeignete Methode verwenden. Jeder Formalismus, bestehend aus einer Ontologie und einer Logik, stellt einen eigenen Kontext dar. Die verschiedenen Kontexte
werden dann auf einer zusätzlichen Ebene, die eine Brückenfunktion übernimmt,
miteinander in Beziehung gesetzt [ibid., S. 2]. Sie definiert für jeden Kontext Units
(Strukturelemente der Architektur), Logics (einer Unit zugeordnete deklarative Sprachen mit Axiomen und Inferenzregeln), Theories (einer Unit zugeordnete, in ihrer Logic
formulierte Terme) und Bridge Rules (Regeln, die Terme verschiedener Kontexte
ineinander überführen). Jede Bridge Rule spezifiziert Terme einer Unit, die wahr sein
müssen, damit ein Term einer anderen Unit abgeleitet werden kann. Die resultierenden
Modelle teilen die Probleme aller mathematisch-formalen Spezifikationen, illustrieren
aber, daß es praktisch möglich ist, durch die Angabe konkreter Umformungsregeln eine
Architektur durch eine andere auszudrücken.
– 43 –
2.4.3 Modellierungssprachen
Der Gegensatz zwischen KI-Forschung und klassischer Softwareentwicklung zieht sich
auch durch das breite Spektrum der vorgeschlagenen Modellierungssprachen hindurch.
Die Gruppe der logischen Sprachen versucht, die Spezifikation eines Systems durch
eine modale Logik in eine operationalisierbare Form zu bringen. Ziel ist oft sogar, eine
abstrakte Programmiersprache zu schaffen, die direkt interpretierbar oder kompilierbar
ist. Grafische Modellierungssprachen hingegen zielen vor allem auf Praxistauglichkeit
und Anschaulichkeit. Sie sind oft angepaßte Notationen aus dem Bereich der Objektorientierung, wie sie etwa im Rahmen von MASE verwendet werden.
Logische Spezifikationssprachen
Mit Agent Oriented Programming (AOP) schlug Shoham ([Shoham 1990], [Shoham
1993]) eine erste entsprechende Methode vor. Er definiert eine multimodale Logik,
deren Terme jeweils mit einem Subjekt und einem Zeitpunkt parametrisierbar sind,
sowie die interpretierte Sprache AGENT0, mit der einfache Terme dieser Logik approximierbar sind. Diese wurde jedoch nie bis in ein praxistaugliches Stadium weiterentwickelt, und auch die geplante Methodologie wurde nie formuliert.
Die Sprache Concurrent METATEM [Fisher 1993] überwindet den Bruch zwischen
Logik und Programmiersprache, indem Systeme direkt mit Termen einer klassischen
temporalen Logik spezifiziert werden. Agenten definieren Eingabeprädikate, Ausgabeprädikate und Übergangsregeln. DESIRE (Design and Specification of Interacting
Reasoning Components) [Brazier et al. 1997] ist eine weitere Spezifikationssprache, die
ein System in Teilaufgaben gliedert und deren Ein- und Ausgabebeziehungen beschreibt. Beide Ansätze sind bereits erfolgreich in Praxisprojekten verwendet worden.
Viroli und Omicini definieren eine Spezifikationssprache [Viroli/Omicini 2002a], die zur
Beschreibung von Mentalmodellen, wie sie etwa zur Angabe der Semantik von ACLs
verwendet werden, dienen soll. Sie greifen die Kritik am White Box-Ansatz der bislang
verwendeten BDI-Modelle auf, halten aber eine rein externe Sicht des Agenten als
Black Box wiederum für zu wenig aussagekräftig. Als Synthese schlagen sie die
Verwendung einer Grey Box vor, die weite Teile des Innenlebens des Agenten wegabstrahiert, jene Teile, die sein beobachtbares Verhalten bestimmen, jedoch sichtbar macht
[ibid., S. 1].
– 44 –
Agenten werden als Observable Sources gesehen. Diese stehen in Beziehung zu
Coordinators, die ihr Verhalten durch Eingaben (Conditionings) von außen beeinflussen, und Observers, die die Auswirkungen (Manifestations) ihres Verhaltens beobachten. Der Agent selbst besteht aus zwei Teilen: einem beobachtbaren Part, dem Observable Core, und einer wegabstrahierten architekturspezifischen Komponente, der Agent
Internal Machinery. Der beobachtbare Kern enthält Configuration und Place. Erstere
umfaßt Informationen über die Interaktionen, an denen der Agent gerade beteiligt ist.
Letzterer ist jener Teil des internen Status, der von der Umwelt beeinflußt wird und das
Verhalten gegenüber der Umwelt beeinflußt. Die Agent Internal Machinery interagiert
mit dem beobachtbaren Kern über Änderungen am Place, wobei jedes betroffene
Element durch einen Spontaneous Move dokumentiert wird. Beim Eintreffen eines
Conditioning (reaktiv) oder beim Auslösen eines Spontaneous Move (proaktiv) berechnet die Engine anhand eines Satzes von Transitionsregeln aus Configuration und Place
den neuen internen Zustand und erzeugt gegebenenfalls Manifestations [ibid., S. 2].
Zur Spezifikation des Agenten können so seine Signatur (Conditionings, Spontaneous
Moves, Manifestations), Struktur (Place, Configuration) und Dynamik (Transitionsregeln) verwendet werden. Von konkretem Interesse für das Metamodell ist allerdings
weniger die eigentliche Spezifikationssprache als vielmehr die Idee der Grey Box und
des Observable Core.
Grafische Modellierungssprachen
Angesichts des Erfolges von UML [Booch et al. 1998] bei der objektorientierten
Modellierung überrascht es nicht, daß seitens jener Entwickler, die agentenorientierte
Softwareentwicklung (AOSE) als evolutionäre Fortentwicklung der objektorientierten
Softwareentwicklung (OOSE) ansehen, auch nach geeigneten diesbezüglichen Erweiterungen für UML gesucht wird. Agenten haben meist wenig aussagekräftige Signaturen,
zeigen dafür aber komplexe, nichtdeterministische Interaktionen mit anderen Agenten,
weswegen die Ausdrucksmittel von UML allgemein für eine Modellierung nicht als
ausreichend angesehen werden. Bezüglich der besten Lösung für diese Probleme
herrscht allerdings noch keine Einigkeit, so daß die bisherigen Vorschläge für eine
Agent UML (Agent Unified Modeling Language) das ‚U’ noch zu Unrecht im Namen
tragen.
– 45 –
Odell und Bauer ([Odell et al. 2002], [Bauer et al. 2001]) legen einen umfassenden
Entwurf für einen AUML Standard vor. Die signifikantesten Erweiterungen sieht er am
Sequenz- und am Klassendiagramm vor. Neue Konnektoren und Verzweigungssymbole
sollen beispielsweise parallele und nichtdeterministische Kommunikation beschreiben
helfen. Huget verfolgt einen ähnlichen Ansatz [Huget 2002b], kritisiert aber etwa das
vorgeschlagene Klassendiagramm als zu unhandlich [Huget 2002a, S. 11]. Lind demonstriert dagegen in einem Vorschlag, wie sich komplexe Interaktionen auch mit den
verfügbaren Aktions- und Zustandsdiagrammen ausdrücken lassen [Lind 2001].
Die meisten Vorschläge wirken naheliegend und einleuchtend, was durch die Anschaulichkeit grafischer Methoden befördert wird. Welche Ideen bei der Modellierung
wirklich hilfreich sind, kann jedoch nur durch ausgiebige praktische Anwendung
überprüft werden.
2.5
Agenten in der Praxis
2.5.1 Standards
Es ist bereits herausgestellt worden, daß sich in der Praxis noch kein einheitlicher
Standard für Agentensysteme etablieren konnte. Dazu trägt auch bei, daß die Interessen
der Forschergemeinde und der kommerziellen Entwickler hier deutlich auseinanderlaufen. Die Agententheorie setzt sich mit ungeklärten Fragen der Berechenbarkeit und
Verifizierbarkeit auseinander. Im akademischen Bereich werden noch mit immer neuen
Entwürfen die Möglichkeiten der Agentenorientierung ausgelotet, wobei Interoperabilität nachrangig ist. In der Praxis besteht hingegen weniger Interesse an mathematischer
Vollständigkeit und innovativen Architekturen als an einer standardisierten Grundlage,
auf der zumindest elementare Dienste wie Adressierung und Nachrichtenversand
unmittelbar funktionieren.
Vorwiegend mit Semantik befaßte Standards wie KQML sparen diese Aspekte jedoch
weitgehend aus. Kommerzielle Systeme bieten zwangsläufig konkrete Lösungen für
diese Probleme an. Da jedoch in einem unreifen Markt das ‚not-invented here’-Syndrom
noch besonders stark wirkt, findet noch wenig Wiederverwendung von Ideen statt
[Wooldridge/Jennings 1998, S. 4].
– 46 –
Der im Folgenden vorgestellte MASIF-Standard ist ein deutlich praxisorientierter
Standard, der sich auf die grundlegende Infrastruktur beschränkt. Der anschließend
behandelte FIPA-Standard beschäftigt sich ebenfalls mit Fragen der Infrastruktur, hat
aber einen umfassenderen Anspruch der auch Fragen der Kommunikation und Wissensrepräsentation einschließt.
2.5.1.1 Der MASIF-Standard
Der 1998 von der Object Management Group (OMG) [OMG] veröffentlichte MASIFStandard (Mobile Agent System Interoperability Facility) [OMG 1998] beruht auf
einem von den Herstellern Crystaliz, General Magic, GMD Fokus, IBM und der
Open Group ausgearbeiteten Entwurf einer Infrastruktur zum Management, Transport,
Benennen und Finden von Agenten. Der Standard deckt einen dem Referenzmodell von
Silva [Silva et al. 2001] vergleichbaren Bereich ab, möchte aber konkret Interoperabilität
zwischen realen Systemen ermöglichen und schreibt daher detaillierte Strukturen und
Schnittstellen vor. MASIF baut zudem unmittelbar auf der CORBA-Architektur auf
und nutzt deren Namenskonventionen und -dienste.
Agenten haben einen eindeutigen Namen und besetzen ebenfalls eine Place in einem
Agentensystem. Verbundene Agentensysteme können in Regionen zusammengefaßt
werden, die über jeweils mindestens einen Namensdienst verfügen müssen. Datenstrukturen zur genauen Beschreibung dieser Elemente werden in IDL formuliert. Die
Parameter
umfassen
im
Besonderen
die
verwendete
Programmiersprache,
Serialisierungsmethode oder Agentenplattform. Weiterhin definiert MASIF zwei
Interfaces: MAFAgentSystem [OMG 1998, S. 45-63] und MAFFinder [ibid., S. 64-74].
MAFAgentSystem stellt Methoden zum Erstellen und Verwalten von Agenten, zur
Abfrage von Informationen über Agenten und zum Empfang von fremden Systemen her
migrierender Agenten zur Verfügung. MAFFinder stellt Verzeichnis- und Suchdienste
zur Verfügung, wobei die Verfahren zur internen Verwaltung des Verzeichnisses
freigestellt sind.
MASIF beschränkt sich auf wenige, weitgehend unstrittige Aspekte von Agentensystemen. Vom Transport von Agenten abgesehen ist die Implementierung aller Dienste
vergleichsweise trivial. Zudem steht die Architektur auf einer soliden, akzeptierten
Grundlage in Form von CORBA. Daher überrascht es nicht, daß der Standard bereits
von mehreren Agentenplattformen implementiert worden ist.
– 47 –
2.5.1.2 Der FIPA-Standard
Die Federation for Intelligent Physical Agents (FIPA) [FIPA] ist eine 1996 gegründete
Organisation, der inzwischen über fünfzig Firmen und Forschungseinrichtungen
angehören. Die von ihr veröffentlichten Standards beziehen sich jedoch primär auf
Softwareagenten, auch wenn der Name Anderes suggeriert. Zunächst veröffentlichte die
FIPA alljährlich den gegenwärtigen Stand des Standardisierungsprozesses, was zu den
inzwischen obsoleten Standards FIPA97 und FIPA98 führte. Seither wird der Standard
(unter dem Namen FIPA2000) auf Dokumentenebene verwaltet. Die einzelnen
Spezifikationen durchlaufen den Lebenszyklus Preliminary, Experimental, Standard,
Deprecated und Obsolete, wobei die meisten Dokumente den dritten Schritt übersprungen haben. Gegenwärtig umfaßt der Standard 94 durchnumerierte Einzeldokumente,
von denen rund 40 noch gültig sind.
Die durch den Standard abgedeckten Gebiete sind vielfältig, wobei allerdings die Sicht
von Agenten als wissensbasierte Systeme im Vordergrund steht. Wesentliche Elemente
sind eine abstrakte Architektur [FIPA C00001], die vier Spezifikationssprachen [FIPA
C00007] Semantic Language (SL) [FIPA C00008], Constraint Choice Language (CCL)
[FIPA C00009], Knowledge Interchange Format (KIF) [FIPA C00010] und Resource
Definition Format (RDF) [FIPA C00011], eine Spezifikation zum Agentenmanagement
[FIPA C00023], eine Bibliothek [FIPA C00025] von Interaktionsprotokollen [FIPA
C00026-C00036], die Sprechakte der FIPA ACL [FIPA C00037], das Format [FIPA
C00061] und die Transportmechanismen [FIPA C00067] für Nachrichten und ein Dienst
zum Austausch von Ontologien [FIPA C00086].
Betrachtet werden sollen hier vor allem die Spezifikationen FIPA SC00001 [FIPA
C00001] und FIPA SC00023 [FIPA C00023], die Anfang Dezember 2002 zu Standards
erhoben worden sind. Das erste Dokument beschreibt die abstrakte Architektur, die von
den anderen Spezifikationen als begriffliche Grundlage verwendet wird. Die zentralen
abstrakten Elemente sind Agenten, Dienste, Nachrichten und Transportmechanismen,
um die herum sich nachgeordnete Attribute wie Agent Identifier, Service Locator,
Service Signature, Message Envelope, Message Encoding oder Transport Specific
Address gruppieren. Als Grundprinzipien werden die Kapselung (opacity) [FIPA
C00001, Zeile 632], etwa des Inhalts (Payload) einer Nachricht in einem Transportumschlag (Envelope), und die Verwendung von Handles [ibid., Z.645], die Agenten bei
– 48 –
Anforderung eines Dienstes erhalten, herausgestellt. Die Spezifikation beschreibt primär
die wesentlichen infrastrukturellen Elemente eines Agentensystems, geht aber im
Gegensatz zum MASIF-Standard auch auf Agentenkommunikation und Nachrichtenübertragung ein. Dies führt zu weitergehenden Anforderungen an Agenten, von denen
Interaktion auf semantischer Ebene und mentale Einstellung (Intentional Stance), also
Attribute eines starken Agentenbegriffs, verlangt werden [ibid., Z.543]. Andererseits ist
der Standard in seinen Vorgaben aber auch weniger spezifisch, so daß es nicht garantiert
erscheint, daß Systeme, die die abstrakte Architektur implementieren, auch tatsächlich
kompatibel wären. Ohnehin trägt diese Spezifikation deutliche Spuren eines politischen
Entstehungsprozesses. Sie schließt wesentliche Bereiche wie Identität, Mobilität,
Sicherheit und Lebenszyklus völlig aus [ibid., Z.449-457], behandelt sie also nicht
einmal auf der Ebene von Begriffsdefinitionen oder abstrakten Schnittstellen, da sie
nicht abstrakt beschreibbar oder „noch nicht bereit“ für eine Standardisierung seien
[ibid., Z.440-445].
Eine konkrete Architektur zur Verwaltung von Agenten wird durch FIPA SC00023
[FIPA C00023] definiert. Eine Agentenplattform besteht aus Agenten, einem Agentenmanagementsystem und optionalen Verzeichnisdiensten, die über das Nachrichtentransportsystem auf semantischer Ebene kommunizieren. Zu diesem Zweck werden eine
Ontologie [ibid., Z.541-599] und eine Bibliothek von Communicative Acts [ibid., Z.600730] spezifiziert. Bemerkenswerterweise wird in diesem Zusammenhang auch ein
Lebenszyklusmodell definiert [ibid., Z.347-427].
Der Standard ist auf mehreren Ebenen kritisiert worden. Die generelle Kritik von Singh
[Singh 1998a] bezüglich der Eindeutigkeit der ACL ist bereits wiedergegeben worden.35
Labrou und Finin kritisieren darüber hinaus, daß die Definition der ACL untrennbar ein
bestimmtes internes Agentenmodell voraussetze, was für eine Sprache mit allgemeinem
Anspruch nicht realistisch sei. Weiterhin seien formale Grundlagen, etwa die Definition
der neu eingeführten Unsicheren Annahme (Uncertain Belief), nicht Teil des Standards
und auch nicht in elektronischer Form verfügbar. Zudem würden implizit Details von
35
Siehe Abschnitt 2.3.4, S. 32.
– 49 –
zweifelhaftem allgemeinen Nutzen aus den als Vorbilder dienenden Systemen einfließen, etwa die Ausrichtung des Nachrichtenformats auf eine effiziente Verarbeitung
durch einen in Prolog geschriebenen Parser [Labrou/Finin 1997b].
Der Standard enthält zudem einige formale Mängel. So werden im Stile der RFC [RFC
Editor] Qualifizierer wie may, can und must definiert [FIPA C00001, Z.932], dann aber
nicht konsistent und eindeutig verwendet. Im XML-Schema [Fallside 2001] der RDF
tragen zwei Elemente irrtümlich den gleichen Identifizierer [FIPA C000011, Z.666].
Weiterhin enthält jedes Dokument den rechtlichen Hinweis, daß der Standard keine
Erlaubnis zur Verwendung der beschriebenen Technologien darstelle. Ihre Benutzung
könne die Rechte von FIPA-Mitgliedern oder Dritten verletzen. Während der Haftungsausschluß bezüglich der Rechte Dritter eine übliche Absicherungsmaßnahme darstellt 36,
erscheint der Vorbehalt bezüglich der Rechte der FIPA-Mitglieder für einen Standard
kontraproduktiv.
Das größte praktische Problem für eine weite Akzeptanz des Standards erscheint aber zu
sein, daß er sich noch beständig unter wiederholtem Brechen der Abwärtskompatibilität
weiterentwickelt. Zum gegenwärtigen Zeitpunkt scheint keine kommerzielle Implementierung des gesamten Standards zu existieren.37 Verschiedene Forschungsprojekte haben
den Standard allerdings ganz oder in Teilen in Java umgesetzt. JADE [JADE] ist eine
Bibliothek, die von aktiven Mitgliedern der FIPA entwickelt wird und sich eine
normative Implementierung des Standards zum Ziel setzt. Die Open Source Projekte
JFIPA (Implementierung des XML-Encodings der FIPA ACL) [JFIPA] und FIPA OS
[FIPA OS] scheinen dagegen schon seit über einem Jahr nicht mehr aktiv zu sein.
Welche praktische Relevanz der FIPA-Standard erlangen wird, erscheint zur Zeit noch
nicht absehbar. Problematisch dürfte die starke Ausrichtung auf Künstliche Intelligenz
und die damit zusammenhängende prominente Verwendung modaler Logik sein. Für
36
37
Vgl. etwa die Richtlinien der W3C zu Verwertungsrechten und Haftung [W3C 2000].
Die einzige kommerzielle Plattform, bei der überhaupt eine Referenz auf den FIPA-Standard gefunden
wurde, ist Grasshopper [IKV 1998]. Die Architektur orientiert sich allerdings primär am MASIFStandard und ist erst nachträglich um einen zum (inzwischen obsoleten) FIPA97-Standard kompatibelen Wrapper erweitert worden.
– 50 –
Unternehmen ist die Investition zudem riskant, da der Standard nur eingeschränkt auf
etablierten Standards der Softwaretechnik aufbaut. Im Licht des aktuellen Trends,
proprietäre Protokolle durch offene Internettechnologien zu ersetzen, stehen weite Teile
der Infrastruktur etwa in Konkurrenz zu Web Services und könnten auch durch SOAP
[Gudgin et al. 2002a/b], UDDI [Bellwood et al. 2002] und WSDL [Christensen et al. 2001]
implementiert werden [Fou 2001].
2.5.2 Agentenplattformen und Toolkits
Die Menge der veröffentlichten Agentenplattformen spiegelt die Vielfalt der verfolgten
theoretischen Konzepte wider und ist in diesem Rahmen nicht sinnvoll zu beschreiben.
Das Verzeichnis von AgentBuilder [IntelliOne 2001] und die Mobile Agent List der
Universität Stuttgart [Hohl 1999] können hier einen ersten Überblick vermitteln.
Die erste kommerzielle Agentenplattform war Telescript [White 1994]. Sie verwendete
bereits das Konzept von Agenten als Kunden von im System angebotenen Diensten, das
auch im FIPA-Standard anklingt. Telescript hatte zwar einigen Erfolg, konnte sich aber
nicht durchsetzen und wurde nach mehreren Revisionen vom Hersteller General Magic
eingestellt.
Zur Entwicklung von Anwendungen mit Telescript war das Erlernen einer dedizierten
Skriptsprache erforderlich. Inzwischen hat sich Java als de facto Standard für agentenorientierte Programmierung etabliert. Der Vorteil von Java sind seine große Verbreitung und die Verfügbarkeit einer breiten Palette an Werkzeugen und Schnittstellen. Es
bringt allerdings auch gewisse Einschränkungen mit sich: Migration ist beispielsweise
maximal unter Mitnahme der Daten, nicht jedoch des aktuellen Ausführungszustands
möglich, da diese Information in Java nicht explizit zugänglich ist.
Einer der prominentesten Vertreter solcher Java-basierten Toolkits ist die Aglets
Workbench [IBM 1997] der IBM Forschungsabteilung. Sie ist bislang nur ein Forschungsprototyp, hat aber aufgrund des geringen Einstiegsaufwands (und des Namens
IBM) vielerorts Beachtung gefunden. Ihr besonderer Reiz liegt in der Existenz von
Tahiti, einer grafischen Benutzeroberfläche zur Agentenverwaltung, die die Aktivitäten
der Agenten anschaulich macht. Fokus des Toolkits ist die infrastrukturelle Ebene, also
Kommunikation, Migration und Verwaltung von Agenten. Verschiedene der vorgestell-
– 51 –
ten theoretischen Konzepte werden direkt umgesetzt: Eine Laufzeitumgebung (Host)
enthält verschiedene Kontexte, in denen die Aglets (Kunstwort aus Agent und Applet)
existieren. Aglets haben eine eindeutige Identität, können aber geklont werden. Sie
können eingefroren und persistent gespeichert werden und aktiv durch Versenden oder
passiv auf Anforderung in andere Kontexte migrieren. Kommunikation kann synchron
oder asynchron erfolgen. Dabei werden Aglets durch Proxies repräsentiert, die für
Ortstransparenz sorgen und die öffentlichen Methoden des Aglet(objekts) verstecken.
Auf der objektorientierten Ebene bietet die Plattform Events und Listener, mit denen
etwa andere Aglets von der Ankunft eines neuen Agenten im System unterrichtet
werden können.
Aglets migrieren auf Basis des ATP (Agent Transport Protocol), einer um spezifische
Konstrukte erweiterten Variante von HTTP (Hyper Text Transfer Protocol [Fielding et
al. 1999]). Gerade im Bereich der Kommunikation und Migration existieren sehr
unterschiedliche Ansätze: ffMain [Lingnau et al. 1995] versucht, eine möglichst generische Kommunikationsarchitektur auf Basis von HTTP aufzubauen, während etwa
AgentSpace [Silva 1999] das Problem kontinuierlicher Kommunikation mit migrierenden Agenten (Open Channels) durch die Verwendung einer spezifischen Architektur auf
Basis von Tuple Spaces zu lösen versucht. Andere Plattformen, wie das bereits erwähnte
JADE [JADE], bieten zusätzlich eine integrierte Unterstützung für die Kommunikation
mit ACLs.
Die in Industrieprojekten verwendeten Agentenplattformen sind häufig anwendungsspezifische Einzelanfertigungen, die auf der Basis von bewährten Middlewarearchitekturen entwickelt werden (vgl. etwa [Parunak 2000]).
Mit zunehmender Reife der Agententechnologie ist eine Konsolidierung des Angebots
zu erwarten. Eine völlige Vereinheitlichung ist jedoch mit Blick auf die verfügbare
Vielfalt objektorientierter Entwicklungs- und Laufzeitumgebungen weder zu erwarten
noch erstrebenswert.
2.5.3 Agentenbasierte Anwendungen
Während das Metamodell vor allem eine gute Verankerung in der Theorie anstrebt, soll
es gleichzeitig die praktische Anwendbarkeit nicht aus den Augen verlieren. Abschlie-
– 52 –
ßend sollen daher reale Anwendungen der vorgestellten Theorien und Methodologien
betrachtet werden. Wo haben sich Agenten in der Praxis bereits bewährt? Wo werden
sie zumindest als Lösung in Betracht gezogen? Kann die Agentenmetapher zur Analyse
und Wartung existierender Systeme herangezogen werden?
Interfaceagenten
Interfaceagenten sollen die Bedienung von Software einfacher und vor allem intuitiver
machen. Die Personifikation von Programmen ist dabei ein häufig eingesetztes Mittel,
das oft noch durch eine vermenschlichte Darstellung unterstützt wird. Die Hilfsassistenten, die Microsoft mit Office 97 eingeführt hat [Microsoft 1997], sind das bekannteste,
wenn auch nicht zwangsläufig gelungenste, Beispiel für diese Technik. Sie illustrieren
gleich eine fundamentale Erkenntnis dieses Forschungsgebiets: Autonome Agenten
werden nur akzeptiert werden, wenn ihr Verhalten nicht als aufdringlich, nicht zielführend, undurchsichtig oder schädlich empfunden wird. Microsoft Office demonstriert
aber auch gleichzeitig einen umgekehrten Trend: Blickt man hinter die animierte
Präsentation, leistet der Office-Agent wenig mehr als die klassische Hilfe – abgesehen
davon, daß er auf bestimmtes Benutzerverhalten hin selbständig seine Hilfe anbietet.
Ähnliches leisten die Autokorrektur und die automatische Formatierung auch – zwar
unspektakulärer, aber im Alltag dafür erfolgreicher. Dies illustriert eine zweite Erkenntnis, die wohl für die Agentenorientierung insgesamt relevant ist: Einfache, effiziente
Agenten, die ihre Aufgabe unauffällig erledigen, sind oft besser als übermäßig ambitionierte umfassende Lösungen.
Eine andere Klasse von Interfaceagenten sind sprachgesteuerte Agenten. Ein Beispiel
ist Julia, ein Agent, der in textbasierten Online-Rollenspielen nützliche Informationen
über die Spielwelt und andere Spieler geben kann, dabei aber wie ein normaler Spieler
auftritt und interagiert [Foner 1993]. Ein weiteres Beispiel ist A.L.I.C.E. (Artificial
Linguistic Internet Computer Entity) [Wallace 2001], Gewinner des letztjährigen
Loebner Prize [Loebner 2001]. Solche Agenten erfordern ein größeres Maß an
Intelligenz und vor allem einen leistungsfähigen Parser. Sie sind die von den Theorien
der AOSE am schlechtesten erfaßte Agentenklasse, da hier der Schwerpunkt weniger
auf Verhalten als auf einer aufwendigen internen Informationsverarbeitung liegt. Es
besteht eher eine Nähe zu Expertensystemen im Stil von Mycin [Shortliffe 1976].
– 53 –
Informationsfilter
Eher im Hintergrund arbeiten wiederum Informationsfilter, die eingehende Post nach
Themengebieten sortieren und unerwünschte Werbung unterdrücken. Im weiteren Sinne
kann dies auch einschließen, daß der Agent proaktiv verschiedene Informationsquellen
im Internet abfragt und für den Benutzer relevante Nachrichten auswählt und zusammenstellt. Ein solches System ist der an der Universität Münster entwickelte Pi Agent
[Wortmann 2002, S. 75f]. Das entscheidende Problem in diesem Kontext ist die effiziente Personalisierung des Agenten: Die Ziele des Benutzers müssen möglichst korrekt auf
die Ziele des Agenten abgebildet werden. Klassische Informationsfilter lassen den
Benutzer explizit Regeln definieren, während intelligente Agenten eher versuchen, diese
Regeln durch Beobachtung aus dem Verhalten des Benutzers zu inferieren.
Persönliche Assistenten
Maes sieht die Möglichkeit, intelligente Agenten als „persönliche Assistenten, die mit
dem Benutzer in der selben Arbeitsumgebung zusammenarbeiten“38 [Maes 1994, S. 71]
einzusetzen. Die Vision eines Agenten, der auf den Empfang einer Nachricht, daß der
für eine Konferenz eingereichte Vortrag angenommen wurde, hin den Benutzer
alarmiert und selbständig eine Auswahl der günstigsten Flüge zum Veranstaltungsort
zusammenstellt [Wooldridge/Jennings 1995, S. 3], erscheint mittelfristig noch nicht
realisierbar.
Computerspiele
Moderne Computerspiele sind oft extrem aufwendige Programme, die nicht nur im
Bereich der Grafikprogrammierung die Grenzen des Machbaren abstecken, sondern
auch im Hintergrund zunehmend komplexe Simulationsmodelle verwenden. Während
der Klassiker des Simulationsgenres, SimCity [Electronic Arts 2003a], noch ein regelbasiertes Pseudo-Simulationsmodell verwendet, simulieren moderne Inkarnationen wie
38
Im Original: “The metaphor is that of a personal assistant who is collaborating with the user in the
same work environment.” [Maes 1994, S. 71].
– 54 –
The Sims [Electronic Arts 2003b] oder die Wirtschaftssimulationen Anno 1503 [Sunflower 2003] und Tropico [PopTop 2003] ein System aus individuellen Akteuren.
Künstliche Intelligenz ist zudem oft von entscheidender Bedeutung. In EchtzeitStrategiespielen muß der Computer auf der Makroebene den gegnerischen Strategen
simulieren und zusätzlich auf der Mikroebene die selbständigen Reaktionen einzelner
Einheiten steuern. In 3D-Shootern wie Quake [id Software] steuert der Computer die
Gegner, die in moderneren Spielen auch kommunizieren und ihr Verhalten koordinieren
können. Besonders interessant ist das Spiel Black & White [Lionhead], das die Agentenmetapher quasi zum Spielprinzip erhebt. Der Spieler steuert seinen autonom
agierenden Avatar nicht direkt, sondern erzieht ihn durch Belohnungen und Bestrafungen zum erwünschten Verhalten.
Computerviren
Bei den bisherigen Anwendungen stand zumeist der Aspekt künstlicher Intelligenz im
Vordergrund. Eine rein technische Form von Agenten sind Computerviren. Im Vordergrund stehen hier naturgemäß autonomes proaktives Verhalten und Migration. Kommunikation zwischen den Agenten findet überwiegend nicht statt, jedoch gibt es Viren, die
eine Hintertür von einem Server herunterladen, auf dem befallenen Rechner installieren
und dieses ihrem Ersteller im IRC melden [Symantec 2003].
Betriebssystemtechnik
Song [Song et al. 1996] hat ein System aus vier Agenten entwickelt, die als eigene
Prozesse in einem UNIX-Betriebssystem laufen, durch das Dateisystem wandern und
Dateien komprimieren und archivieren. Das Betriebssystem ist hier also die Agentenplattform. Noch unüblicher mag es zunächst erscheinen, das Betriebssystem selbst als
Multiagentensystem zu betrachten. In einem modernen System mit Plug & Play
Subsystem und anderen vergleichbaren Diensten zur automatischen Konfiguration
(Daemons) ist diese Sicht aber durchaus nicht abwegig. Hinzu kommen noch die
Programme, die der Benutzer aktiv im Hintergrund arbeiten läßt, etwa Indizierungsdienste oder Antivirussoftware.
– 55 –
Mobile Agenten als Netzwerktechnik
Der treibende Gedanke hinter der Verwendung von mobilen Agenten als Netzwerktechnologie ist vor allem Ressourceneffizienz: Der Code soll dort ausgeführt werden, wo die
Daten liegen oder die meiste freie Rechenzeit zur Verfügung steht. Gerade leichtgewichtige Mobilgeräte können so als Thin Client auf die Dienste eines Agenten zugreifen, den der Benutzer auf einen leistungsfähigeren Server geschickt hat [Harrison 1995,
S. 10]. Zudem soll die Abwicklung komplexer Abfragen lokal auf dem Server die
Netzwerkauslastung verringern [ibid., S. 7].
Swarm Intelligence ist eine naturanaloge Weak AI-Technik, die durch das intelligente
kollektive Verhalten von Insektenkolonien inspiriert ist. Sie wird beispielsweise in
Anlehnung an die günstigsten Pfade zu einer Nahrungsquelle, die von Ameisen durch
Pheromone markiert werden, erfolgreich zur Balancierung des Verkehrs in paketbasierten Netzwerken (optimiertes Routing) verwendet [Bonabeau et al. 1998].
Simulation
Wie bereits beschrieben, eignen sich Agenten in besonderem Maße zur Simulation von
Systemen, in denen einfache individuelle Verhaltensmuster chaotisches Gesamtverhalten erzeugen. Beispiele sind das DASCh Projekt (Dynamical Analysis of Supply
Chains) des ERIM CEC (Center for Electronic Commerce) [Parunak 2000, S. 396f] und
ein Projekt des NCMS (National Center for Manufacturing Sciences), das
Induktionsheizungsprozesse simuliert [ibid., S. 397].
Produktionsplanung und –steuerung
Dieses Gebiet erhält von seiten der Industrie große Aufmerksamkeit. Ein Großteil der
Ansätze beruht auf einem ‚naturanalogen’ Marktmodell: Produktionsaufträge werden
mit einem ihrem Umfang und ihrer Priorität entsprechenden Startkapital ausgestattet,
mit dem sie Rohstoffe und Maschinenbenutzungszeiten ersteigern müssen. Selbst wenn
die einzelnen Agenten nur eingeschränkt intelligent sind und eine individuelle Nutzenmaximierung anstreben, sollte sich nach den Regeln der klassischen Ökonomie auf
einem solchen perfekt transparenten Markt das ‚gesamtgesellschaftliche’ Optimum
einstellen.
– 56 –
Ein besonders bemerkenswertes Projekt dieser Art ist das Holonic Manufacturing
System (HMS) von DaimlerChrysler. Es verbindet ein Marktmodell mit sogenannten
Holons, robotischen Transportwagen, die das ausgehandelte Produktionsprogramm auch
direkt in die Tat umsetzen können [Parunak 2000, S. 391].
Elektronische Marktplätze
Der meistverwendete Agent auf einem elektronischen Marktplatz ist wahrscheinlich der
simplizistische eBay-Agent [eBay 2003], der im gesetzten Rahmen fremde Gebote
automatisch überbietet. Im B2B-Bereich wurden entsprechend aufwendigere, automatisierte Systeme diskutiert. Die Autoindustrie strebt traditionell eine möglichst weitgehende Automatisierung ihrer Logistikprozesse an, so daß hier ein prinzipielles Interesse
besteht. Vor dem Hintergrund der Wirtschaftslage wird allerdings gegenwärtig zumeist
einfacheren, bewährten Technologien der Verzug gegeben.
Physikalische Agenten
Grundsätzlich lassen sich jegliche Roboter als physikalische Agenten verstehen.
Besonders hilfreich ist diese Sicht aber vor allem für Roboter, die sich autonom in ihrer
Umwelt bewegen. Kommerzielle Ausführungen solcher Agenten existieren bereits in
Form von selbststeuernden Rasenmähern und Staubsaugern.
Ein Multiagentensystem in diesem Sinne stellen jene Roboter dar, die im Rahmen des
RoboCup [Kitano et al. 1997] in Mannschaften gegeneinander Fußball spielen.
– 57 –
3
3.1
Entwurf des Metamodells
Modellphilosophie
An dieser Stelle sollen die Grundprinzipien und der Anspruch des Metamodells
dargestellt werden. Dabei werden zunächst das zugrundegelegte Modellverständnis und
die verwendete Interpretation des Agentenbegriffs und im Anschluß die daraus abgeleiteten Architekturprinzipien dargestellt.
3.1.1 Modellbegriff
Unter einem Modell wird hier in Anlehnung an Schütte die Abbildung eines Sachverhaltes der realen oder gedachten Welt in einer formalisierten Sprache verstanden, die von
einem Modellierer auf Basis seiner Wahrnehmung erstellt wird [Schütte 1998, S. 59-62].
Das Modell ist dabei keine objektive und isomorphe Abbildung (abbildungsorientiertes
Modellverständnis), sondern ein subjektive, homomorphe Abbildung von hinreichender
Genauigkeit (konstruktivistisches Modellverständnis). Daraus leitet sich ab, daß
Modellbildung immer auf die Verfolgung eines konkreten Untersuchungsziels ausgerichtet ist [Ferstl/Sinz 1998, S. 18].
Ein Metamodell ist informal betrachtet ein Modell eines Modells, wobei zumeist die
Beschreibung auf einer höheren Abstraktionsebene impliziert wird. Aus dem Modellbegriff leitet sich dabei ab, daß die Auswahl relevanter Aspekte des betrachteten Modells
durch den Beschreibungszweck des Metamodells motiviert sein muß. Strahringer
unterscheidet dabei zwischen dem linguistischen und dem prozeßorientierten Prinzip
[Strahringer 1996, S. 19ff]. Ersteres beschäftigt sich in Anlehnung an die Sprachstufentheorie mit der Beschreibung der Objektsprache, mit deren Hilfe das betrachtete Modell
ausgedrückt ist, in einer Metasprache; letzteres beschreibt Modellierungsprozesse. Da
das hier entwickelte Modell auf die Schaffung eines begrifflichen Rahmens abzielt, in
den andere Modellierungsansätze eingeordnet werden können, wird ein sprachbasierter
Ansatz verfolgt.
In diesem Sinne ist die Abgrenzung des hier verfolgten Ansatzes zu existierenden
Referenzmodellen nicht scharf definiert, da auch diese zumindest implizit eine Metasprache definieren. Dabei haben Referenzmodelle jedoch einen stärker normativen
– 58 –
Charakter und geben konkrete Gestaltungsempfehlungen für eine Modellierung
[Becker/Schütte 1996]. Das Metamodell soll hingegen stärker darauf fokussiert sein,
welche Elemente in einem System vorhanden sein können, nicht wie sie gestaltet sein
sollten oder müssen. Die in seinem Rahmen formulierten Prinzipien betreffen die
idealtypischen Beziehungen innerhalb einer Modellierungssprache, nicht innerhalb der
modellierten Systeme, und sollen nicht als einschränkende Vorgaben hinsichtlich des
Entwurfs und der Implementierung konkreter Systeme verstanden werden.
3.1.2 Agentenbegriff
Das Metamodell soll an erster Stelle zur Beschreibung einer möglichst großen Auswahl
der dargestellten Theorien und Architekturen geeignet sein. Deswegen wäre es nicht
zielführend, hier in wenigen Zeilen einen einzigen Agentenbegriff festschreiben zu
wollen. Ohnehin ist die Aussagekraft einer solchen isolierten Definition prinzipiell nur
beschränkt, wie McCarthy (mit Bezug auf den Absichtsbegriff) darlegt: „Für gewöhnlich sind die meisten wissenschaftlichen Konzepte nicht durch einzelne Sätze natürlicher
Sprachen, sondern vielmehr als Teile von Theorien definiert, und die Anerkennung der
Theorie hängt von ihrer Eignung zur Beschreibung einer großen Menge von Phänomenen ab.“39 [McCarthy 1979, S. 7]. In diesem Sinne schlägt sich der zugrundegelegte
Agentenbegriff vor allem in den Beziehungen innerhalb des Metamodells nieder.
Ausschlaggebend ist nicht die wissenschaftliche Eleganz oder Exaktheit einer einzelnen
Definition, sondern die Eignung des Gesamtkonzeptes zu Beschreibung von realen
Agentensystemen. Ausgangspunkt ist deswegen eine undogmatische Interpretation von
Agentenorientierung im Sinne des sehr schwachen Agentenbegriffs40 (very weak
notion).
Damit dieser nicht vollkommen inhaltsleer ist, muß aber die Frage geklärt werden,
w e l c h e Abstraktion dem Entwickler dadurch eigentlich als Werkzeug an die Hand
39
40
Im Original: “It is commonplace that most scientific concepts are not defined by isolated sentences of
natural languages but rather as parts of theories, and the acceptance of the theory is determined by its
fit to a large collection of phenomena” [McCarthy 1979, S. 7] .
Siehe Abschnitt 2.2, S. 18.
– 59 –
gegeben wird. Zu diesem Zweck sei nochmals die Analogie zur Objektorientierung
bemüht: Ihre essentiellen Konzepte sind die Kapselung des internen Objektzustands und
eine datenorientierte Sichtweise. Die Agentenorientierung bietet eine in diesem Sinne
noch stärkere Abstraktion, die in vergleichbarer Weise durch das Prinzip der Kapselung
von internen Prozessen (Verhaltensintransparenz) und eine interaktionsorientierte
Sichtweise beschrieben werden könnte. Die Dehnbarkeit dieser Definition ist nicht als
Nachteil anzusehen. Auch die Objektorientierung gibt keine Vorgaben, welche und wie
viele (oder wenige) Klassen bei der Modellierung eines konkreten Systems zu verwenden sind – dies liegt weitgehend im subjektiven Ermessen des Entwicklers. Das
Konzept wird dadurch intuitiv und flexibel anwendbar.
Die Abbildung in einem operativen Modell erfordert allerdings eine konkrete Umsetzung dieser abstrakten Idee. Als Grundlage soll hier die Sicht eines Agenten als System,
das mit Sensoren und Effektoren mit seiner Umwelt interagiert, dienen, da sie hinreichend generisch41 erscheint und dennoch die Kernpunkte der vorgeschlagenen abstrakten Definition, Kapselung interner Prozesse und Interaktionsorientierung, widerspiegelt.
Die Beschreibung aller weitergehenden Aspekte, etwa mentaler und sozialer Fähigkeiten, Kommunikation und Mobilität, wird durch um diesen Kern herum angeordnete
optionale Module umgesetzt. Da die einzelnen Konzepte weitgehend zueinander
orthogonal sind, können konkrete Agentensysteme mit Hilfe einer passenden Auswahl
einschlägiger Teilmodelle erfaßt werden. Dieser Ansatz greift die oben formulierte
Idee42 eines Baukastensystem-Agentenbegriffs auf.
3.1.3 Integrationskonzept
Ein allgemeingültiges Modell zu formulieren ist leicht, wenn die einzelnen Teile nur
unspezifisch genug gehalten sind. Zur Spezifikation eines Systems ist ein solches
Modell jedoch nicht geeignet, da – wie bei der Beschreibung eines Agenten als ein
41
Die Sicht suggeriert zwar aktive, in gewissen Grenzen autonome Entitäten, läßt sich bei Bedarf aber
auch problemlos auf passive, streng deterministisch reagierende Objekte anwenden – auch wenn ihr
Nutzen in diesem Falle fraglich sein dürfte.
42
Siehe Abschnitt 2.2, S. 18.
– 60 –
Objekt mit den Methoden act() und listen() oder bei der exzessiven Verwendung
von tell-Nachrichten in KQML-Systemen – die eigentliche Beschreibung dann faktisch
auf einer anderen Ebene erfolgt. Beim Metamodell liegt deswegen das Augenmerk
darauf, wie andere Theorien und Architekturen die verschiedenen Teilbereiche beschreiben. Die Aussagen des jeweils expressivsten Formalismus sollten eine semantische Entsprechung innerhalb des Metamodells besitzen.
Dies soll aber nicht dazu führen, daß einfach nur isolierte Elemente anderer Modelle
nebeneinandergestellt oder auf einer rein nominalen Ebene kombiniert43 werden. Eine
der interessantesten Fragen in der Agentenorientierung ist gerade, wie die verschiedenen Konzepte ineinandergreifen und zusammenspielen. Das Metamodell soll hier
versuchen, eine Brücke zwischen der KI-orientierten und der softwaretechnischen
Perspektive zu schlagen, die oft von einer deutlichen Kluft getrennt sind.44 Da die
Beziehungen der Modellelemente zueinander sich nicht einfach direkt beschreiben
lassen, weil sie zu vielfältig oder auch noch gar nicht formalisiert sind, muß das
Metamodell an dieser Stelle die rein deskriptive Ebene verlassen und ein eigenes
Konzept zur Strukturierung entwerfen. Die Philosophie dieses Konzepts wird zwangsläufig nicht immer der Philosophie des betrachteten Agentensystems entsprechen; es ist
aber sein Ziel, durch passende Abbildungsrelationen auch diese Architekturen adäquat
modellieren zu können.
3.1.4 Architekturprinzipien
Das Metamodell untergliedert sich auf der obersten Ebene in zwei Teilmodelle: eine
konkrete Ebene, die die Wahrnehmungen und Handlungen der Agenten beschreibt, und
eine abstrakte Ebene, auf der soziale und mentalistische Konzepte modelliert werden.
Diese Unterteilung ist von der Differenzierung zwischen Physischem und Metaphysischem in der realen Welt inspiriert.
43
Also nicht: ‚Das Aglet beschließt mit seiner BDI-Logik, einen Agenten im MASIF-Verzeichnis zu
suchen, um ihm eine FIPA ACL Nachricht zu senden…’
44
Dies ist ein Unterfangen ganz im Geiste der Wirtschaftsinformatik, die eine Brückenfunktion zwischen
der Formalwissenschaft Informatik und der Realwissenschaft Betriebswirtschaftslehre ausüben will
[Holten 1999, S. 5].
– 61 –
Ziel einer umfassenden Methode zur agentenorientierten Softwareentwicklung muß
sein, einen Weg anzubieten, der ohne Brüche von der abstrakten, konzeptionellen
Beschreibung eines Agentensystems über ein operatives Modell bis hin zur Implementierung führt. Das erste Entwurfsprinzip des Metamodells ist daher die Verankerung in
der klassischen Softwaretechnik. Da jedes System von Softwareagenten letztendlich auf
einem Rechner implementiert werden muß, sollen zumindest die Elemente auf der
niedrigeren Abstraktionsstufe direkt mit einer ‚klassischen’ Modellierungsmethode
beschreibbar sein. Beispielsweise könnte ein implementiertes System aus Objekten
(Modellierung mit UML) bestehen, die sich per HTTP (Spezifiziert durch die Referenz
auf den Standard) XML-Nachrichten (Modellierung durch XML-Schemata) zusenden.
Auf diese Weise lassen sich beliebig spezifische technische Details transparent in
Modelle einbinden.
Darauf baut ein zweites wesentliches Prinzip auf: Die Elemente der abstrakten Ebene
sollen direkt auf Elemente der konkreten Ebene zurückführbar sein. Dies ist zunächst
natürlich eine technische Voraussetzung ihrer Implementierbarkeit, wie sie etwa von der
Theorie der Systemebenen formuliert wird. Die Forderung ist jedoch auch inhaltlich im
Sinne des Positivismus45 zu verstehen: Die Rückführung soll explizit auf semantischer
Ebene durchgeführt werden. Macht ein Agent etwa ein Versprechen (abstrakte Ebene),
schlägt sich dies in einer entsprechenden Nachricht oder einem Protokolleintrag
(konkrete Ebene) nieder, die für andere Agenten wahrnehmbar sind.
Die Idee hinter diesem Ansatz ist die Ausweitung des Prinzips der physikalischen
Abstützung (Physical Grounding) auf rein virtuelle Systeme. Die Elemente der
konkreten Ebene sind zwar in den meisten Fällen selbst nur das Ergebnis eines Modellierungsprozesses, aus Sicht der Agenten jedoch eine ‚physikalische’ Realität, die
unmittelbar und ohne Übersetzung in Symbole wahrgenommen werden kann. Daher
trägt die konkrete Ebene des Metamodells auch die Bezeichnung physikalische Ebene.
Die Vorteile der physikalischen Abstützung in der realen Welt bleiben erhalten: Die
45
Hier verstanden als Form des Empirismus, die Wissen einzig aus Wahrnehmungen ableitet: “A doctrine
contending that sense perceptions are the only admissible basis of human knowledge and precise
thought.” [TAHD 2000]
– 62 –
abstrakten Konzepte sind präzise, eindeutig und in für die Agenten erfahrbarer Form
definiert. Der Protokolleintrag im obigen Beispiel ist somit nicht Konsequenz oder
Ausdruck, sondern essentielle Verkörperung des Versprechens.
Wie die meisten Modellelemente sind auch die formulierten Architekturprinzipien nicht
normativ zu verstehen. Sie sollen die Modellierung erleichtern, nicht einschränken.
3.1.5 Agententheorie
Aus dem Prinzip der physikalischen Abstützung leitet sich direkt eine behavioristische
Sicht auf Agenten, also eine Beschreibung durch ihr beobachtbares Verhalten auf der
physikalischen Ebene, ab. Zur Spezifikation von Systemen wird ein reiner Black BoxAnsatz allerdings in Übereinstimmung mit Viroli und Omicini [Viroli/Omicini 2002a] für
unzureichend gehalten. Die Beschreibung autonomer Agenten durch mentalistische
Begriffe ist eine sowohl nützliche als auch verbreitete Methode, die von einem Metamodell nicht ausgespart werden kann. Dabei wird hier aber im Sinne von McCarthy
[McCarthy 1979] der Schwerpunkt nicht auf eine Abbildung der internen Architektur
von Agenten, sondern auf die Z u s c hr e i b u ng mentaler Attribute gelegt.
Ein Mentalmodell eines Agenten erfordert sowohl eine metaphysisch adäquate46
Repräsentation seiner Begriffswelt, die hier durch die physikalische Ebene geleistet
wird, als auch eine epistemologisch adäquate Darstellung, die die aus Sicht des Agenten
tatsächlich verfügbaren Erkenntnisse beschreibt.
Letzteres kann durch einen White Box-Ansatz wie beispielsweise eine BDI-Architektur
geleistet werden. Dieser Ansatz wird hier allerdings aus drei Gründen nicht verfolgt:
Zunächst wird er als zu spezifisch angesehen. Würden andere Elemente des Modells
sich auf die Interna einer solchen Architektur beziehen, wie dies etwa die FIPA ACL
betreibt, litte die Anwendbarkeit des Metamodells auf Systeme mit anderen Architekturen. Zwar ließe sich die BDI-Architektur hier als reine Interpretationshilfe sehen,
allerdings würde dadurch nur ein zweites Problem akzentuiert: Die mentalen Konstrukte
46
Zur Unterscheidung zwischen metaphysisch adäquater und epistemologisch adäquater Beschreibung
siehe [McCarthy 1979, S. 1].
– 63 –
der BDI existieren im günstigsten Falle innerhalb der Agenten, im ungünstigen Falle
nur im Kopf des Entwicklers. Sofern die Agenten nicht Zugriff auf die interne Repräsentation anderer Agenten haben, läßt sich eine solche White Box schlecht operationalisieren. Die Annahmen der Agenten über die Welt sind überprüfbar, nicht jedoch ihre
Annahmen über die Annahmen anderer Agenten. Drittens wird die mit mentalen
Architekturen praktisch untrennbar verbundene Beschreibung durch modale Logik als
Modellierungsmethode zur kommerziellen Softwareentwicklung im großen Stil kritisch
beurteilt. Eine solide theoretische Fundierung ist wünschenswert – praxisorientierte
Modelle sollten sie jedoch in möglichst anschaulicher und leicht operationalisierbarer
Form umsetzen.47
Der hier vorgeschlagene Ansatz basiert auf einer hybriden Darstellung im Sinne einer
Grey Box. Sie läßt aus Sicht eines externen Beobachters bestimmte sichere Annahmen
über den mentalen Zustand des Agenten zu, ohne jedoch dessen interne Umsetzung
vorzuschreiben, da entsprechende Vorgaben niemals allen Architekturen gerecht
werden könnten. Bei Bedarf bietet das Metamodell dabei allerdings die nötigen
Schnittstellen, um die Grey Box transparent (in doppelter Hinsicht) zu einer implementierungsspezifischen White Box zu erweitern.
Die Bedeutung sozialer Konventionen bei der (menschlichen) Kommunikation und
Interaktion ist bereits herausgestellt worden. Für die Modellierung der Systemebene
sind die tatsächlichen internen Bewußtseinsprozesse der Agenten weniger relevant als
deren soziale Rezipierung. Analog zu menschlichen Überlegungen („Die Gedanken
sind frei.“) sind Annahmen und Absichten eines Agenten für das Gesamtsystem
irrelevant, solange sie sich nicht in konkreter Form auf der physikalischen Ebene
manifestieren. Umgekehrt sind aber bei der nachträglichen Beurteilung von Verhalten
die Absichten und Annahmen des Handelnden von großer Bedeutung. Die Rechtswissenschaften können hier einen wertvollen Beitrag leisten, da entsprechende Beurteilungen vor dem Hintergrund unvollständiger Informationen bezüglich des Wissens und der
47
Lind führt den Vergleich zwischen Objekten und den deutlich älteren, formal als äquivalent bezeichneten Abstrakten Datentypen (ADT) an. Letztere seien heute ungleich weniger populär, da die Beschreibung durch Objekte eine natürlichere Beschreibung der realen Welt ermöglicht und vertraute Denkweisen der Softwareentwickler aufgegriffen habe [Lind 2000, S. 12].
– 64 –
Motivation einer Person einer ihrer zentralen Gegenstände sind. Juristische Konzepte
wie Vorsatz oder grobe Fahrlässigkeit dienen dabei zur Strukturierung der Einschätzung. Idealtypisch sollte eine solche Qualifizierung natürlich die Gedankengänge des
Individuums exakt widerspiegeln, praktisch können hingegen nur sozial anerkannte
Standards für deren Interpretation und Beurteilung ausschlaggebend sein. Dieses Prinzip
zieht sich durch weite Teile der Gesetzgebung in den Bereichen Zivil- und Strafrecht.
Ein Beispiel aus dem Schuldrecht sei §307 BGB (Negatives Interesse): „Wer bei der
Schließung eines Vertrags, der auf eine unmögliche Leistung gerichtet ist, die Unmöglichkeit der Leistung kennt oder kennen muß, ist zum Ersatze des Schadens verpflichtet
[…] Die Ersatzpflicht tritt nicht ein, wenn der andere Teil die Unmöglichkeit kennt oder
kennen muß.“ [BGB]. Es illustriert, wie das Ergebnis einer Transaktion von den
Annahmen der Beteiligten abhängen kann, und wie die Gesellschaft daher in diesem
Zusammenhang Vorgaben darüber macht, was ein Individuum wissen kann oder wissen
muß.
Dieses Prinzip wird hier auf Agentensysteme übertragen. Die mentalen Attribute eines
Agenten werden auf der Basis sozialer Regeln durch sein Verhalten und seine Erklärungen über sein Denken und Verhalten bestimmt. Wird einem Agenten etwa eine Nachricht erfolgreich zugestellt, weiß er den Inhalt der Nachricht. Antwortet er daraufhin mit
einer Bestätigung, glaubt er den Inhalt der Nachricht. Publiziert ein Agent, daß er eine
Beobachterrolle für ein bestimmtes Ereignis übernimmt, muß er davon wissen, wenn
das Ereignis eingetreten ist. In ähnlicher Weise lassen sich auch individuelle Regeln
darüber, welche Schlußfolgerungen ein Agent aus bestimmten Eingaben ziehen wird,
veröffentlichen.
Diese Interpretation geht in eine dem Konzept der Social Stance (soziale Haltung) von
Singh [Singh 1998b] vergleichbare Richtung. Singh sieht dieses allerdings primär als eine
Erweiterung des mentalistischen Konzepts der Intentional Stance um soziale Begriffe,
ganz im Sinne der Einführung einer sozialen Systemebene oberhalb der Wissensebene
durch Jennings und Campos. Konkret geht es dabei um die Erfassung der Beziehungen
und Verpflichtungen, die Agenten in einer Arbeitsgruppe eingehen, aus Sicht der
Agenten. In der hier eingeführten Sichtweise geht es hingegen zuerst um die externe
Wahrnehmung von Seiten der Gesellschaft, so daß die Bezeichnung Legal Stance
(rechtsverbindliche Haltung) vorgeschlagen wird.
– 65 –
3.1.6 Systemtheorie
Multiagentensysteme sind komplexe, nebenläufige, oft auch verteilte Software. Sie
teilen daher alle technische Probleme entsprechender Systeme bezüglich Synchronisation, exklusivem Ressourcenzugriff oder Deadlocks [Wooldridge/Jennings 1998, S. 4].
Beim Entwurf eines Agentensystems sollte daher auf die in diesem Forschungsgebiet
gewonnen Erkenntnisse zurückgegriffen werden. Die Agentenorientierung fügt dem
allerdings noch eine stärkere Verhaltensintransparenz und Nichtdeterminismus auf der
Ebene der einzelnen Systemkomponenten hinzu. Die resultierenden Interaktionsmuster
sind intuitiv sehr schwer erfaßbar und stellen die Methoden der klassischen Softwareentwicklung auf eine harte Probe.
Bei der Diskussion des Verhaltens einzelner Agenten wurde bereits in sozialen Begriffen argumentiert. Dies legt nahe, auch die Gesamtheit der Agenten als soziales System
zu verstehen und zu seiner Beschreibung Begriffe und Konzepte aus den Sozialwissenschaften zu entlehnen. Zum Verständnis der Systemstruktur können Vergleiche zu
sozialen Organisationsformen und Hierarchien gezogen werden. Die Regeln, die das
System kontrollieren und koordinieren, finden eine Entsprechung in der Verfassung,
den Gesetzen und sozialen Konventionen menschlicher Gesellschaften.
Eine solche Darstellung durch Analogien kommt der menschlichen Intuition stark
entgegen und bietet mächtige Ausdrucksmittel, ist aber auch entsprechend weniger
formalisiert. Sie birgt daher die Gefahr, zu abstrakt zu werden, wenn sie nicht ebenfalls
in der technischen Realität des Systems verankert ist. Die Begriffe des Metamodells
sind bewußt anschaulich gewählt, sollen aber auf der Implementierungsebene kein in
irgendeiner Form ‚anthropomorphes’ System voraussetzen. Eine ‚Agentengemeinschaft’ können nicht nur die Marktteilnehmer in einem aufwendigen Social-SimulationModell, sondern genauso einfach Agenten auf derselben Verteilerliste sein.
Dem Modellierer steht es grundsätzlich frei, ob ein Begriff der konzeptuellen Ebene nur
ein Analysewerkzeug oder tatsächlich ein operatives Element des fertigen Systems sein
soll. Dabei ist allerdings eine gewisse Vorsicht geboten. Auf einer logisch-abstrakten
Ebene wird der Kontext impliziert und Informationen sind frei verfügbar. Auf einer
konkreten Ebene ist der Kontext gegeben und die verfügbaren Informationen sind
eingeschränkt. Ein stetes Risiko bei der Verwendung mächtiger Abstraktionen ist die
irrtümliche Abstützung auf Informationen, die zur Laufzeit im gegebenen Kontext
– 66 –
überhaupt nicht verfügbar sind.48 Deswegen ist für alle Elemente, die bei der Ausführung des Systems eine Rolle spielen sollen, eine Abstützung auf die Elemente der
physikalischen Ebene unumgänglich. Gerade in offenen Systemen ist es entscheidend,
alle aufgestellten Regeln e x p l i z i t umzusetzen und sich nicht durch das erwartungskonforme Verhalten eventueller Prototypen, in die sie lediglich implizit eingeflossen
sind, in falscher Sicherheit wiegen zu lassen.
Bezüglich der Frage einer konstruktionistischen oder reduktionistischen Herangehensweise ist das Metamodell neutral. Es unterstützt sowohl die Modellierung von systemweiten Zielhierarchien als auch das inkrementelle Zusammenfügen individueller
Agenten.
3.2
Modellstruktur
Das Metamodell definiert eine Ontologie zur Beschreibung agentenorientierter Systeme.
Der dabei verwendete Ansatz ist sehr abstrakt, um die elementaren Beziehungen
zwischen den Elementen zu betonen und vielen verschiedenen Klassen von Systemen
gerecht zu werden. Gleichzeitig wurde eine möglichst anschauliche Terminologie
gewählt, um das Modell intuitiv verständlich und praktisch anwendbar zu machen.
Dabei wird, wo dies inhaltlich gerechtfertigt ist, die Nähe zur etablierten Terminologie
des Forschungsgebietes angestrebt. Da die einschlägige Literatur durchweg englischsprachig ist, werden auch hier die Modellelemente mit englischen Begriffen belegt.
Die Rekonstruktion von Begriffen aus einer Lebenswelt, in diesem Falle der Landschaft
der realen und theoretischen Agentenarchitekturen, wird als zentrales Charakteristikum
der Wirtschaftsinformatik bezeichnet [Holten 1999, S. 4f]. Die resultierenden Objekttypen können anschließend zur Modellierung im Sinne der Informatik verwendet werden
[ibid., S. 5]. Demgemäß wird das Metamodell durch die Herleitung und Einordnung der
einzelnen Begriffe definiert werden. Da die Beziehungen innerhalb des Modells jedoch
keiner linearen Ordnung folgen, ergibt sich das Problem von Vorwärtsreferenzen. Daher
48
Als einfaches Beispiel diene hier ein C++-Objekt, das zwar durch seine Methodensignatur beschrieben
wird, mangels der Fähigkeit zur Introspektion aber zur Laufzeit keine Aussagen darüber machen kann.
– 67 –
soll einleitend nicht nur die grobe Struktur des Modells definiert, sondern auch ein
Überblick über die wichtigsten Begriffsklassen gegeben werden.
Wie bereits dargestellt wurde, zerfällt das Metamodell in zwei Ebenen: die Physical
Layer, die die konkrete Umsetzung des Systems enthält, und die Conceptual Layer, die
die metaphysischen Aspekte des Systems beschreibt. Diese Ebenen untergliedern sich
jeweils noch in Teilmodelle.
Agent als zentraler Begriff des Metamodells nimmt eine Sonderstellung ein, da er auf
beiden Ebenen vertreten ist. Sein beobachtbarer Anteil wird von der Physical Layer
beschrieben, während die Conceptual Layer seine abstrakte ‚Persönlichkeit’ erfaßt.
Innerhalb der Beschreibung des Agenten in seiner Gesamtheit findet sich somit der
klassische Dualismus Körper – Geist.
3.2.1 Physical Layer
Physical Layer
Process
Model
Service
Model
Environment
Model
Entity
Model
Abbildung 3.1
Die Teilmodelle der Physical Layer
– 68 –
Das grundlegende Element der Physical Layer ist das Environment. Es ist der Behälter,
in den alle anderen Elemente des Metamodells eingebettet sind. Jede Elementinstanz ist
von einem Environment existentiell abhängig. Das Environment Model beschreibt die
in einem Gesamtsystem vorhandenen Environments und ihre hierarchischen oder
netzwerkartigen Beziehungen.
Um das Environment Model herum ordnen sich die drei anderen Teilmodelle der
Physical Layer an, die zur genaueren Spezifikation der einzelnen Environments dienen.
Dies sind das Entity Model, Process Model und Service Model.
Das Entity Model beschreibt die Beschaffenheit und Beziehungen der Entities, der
Objekte, die das Environment bevölkern. Dabei ist der Begriff im Sinne eines abgeschwächten Empirismus aus der Agentenperspektive definiert: Entity ist jedes Systemelement, das p r i n z i p i e l l von einem Agenten wahrgenommen (oder manipuliert)
werden kann. Daher ist im Besonderen auch der beobachtbare Part eines Agent eine
Entity. Als Gegenbegriff dazu beschreibt Item alle anderen Entities. Besondere
Unterkategorien von Item sind Message, Resource, Facility und Proxy. Entities sind
vor dem Hintergrund der physikalischen Abstützung grundsätzlich ungetypt. Ein
Typensystem kann allerdings problemlos durch Entities implementiert werden – die
Entities stehen dann in ‚Instanzbeziehungen’ zu Types.
Das Entity Model beschreibt darüber hinaus auch die Interaktion der Agents mit ihrer
Umwelt. Agents nehmen Entities mit ihren Sensors wahr und manipulieren sie mit
ihren Effectors. Dabei wird die Rolle der Kommunikation durch die Differenzierung in
Auditive Sensor und Verbal Effector, die auf Messages wirken, und Visual Sensor und
Manual Effector unterstrichen. Für jeden Sensor und Effector wird die Menge von
Entities, auf die dieser gegenwärtig wirken kann, als sein Context definiert.
Das Process Model definiert die aktiven Processes, die unabhängig von Agents im
Rahmen des Environment ablaufen. Processes modifizieren Entities. Sie können auch
systemexogene Einflüsse abbilden.
Das Service Model ist bedeutsam für die Beschreibung der Infrastruktur, die im
Rahmen eines Environment angeboten wird. Es ist damit der Anknüpfungspunkt für die
Einbindung konkreter Agentenarchitekturen. Das Modell spezifiziert eine Auswahl von
Services, beispielsweise einen Verzeichnisdienst, Authentifizierungsmechanismen und
– 69 –
Nachrichtentransport. Es verweist weiterhin gegebenenfalls auf Facilities, spezielle
Entities, über die Agents auf die Services zugreifen können.
3.2.2 Conceptual Layer
Conceptual Layer
Behavioral
Model
Application
Model
Mental
Model
Abbildung 3.2
Social
Model
Die Teilmodelle der Conceptual Layer
Im Zentrum der Conceptual Layer steht der Agent. Sie umfaßt das Mental Model, das
Behavioral Model, das Social Model und das Application Model, die eng miteinander
verzahnt sind.
Das Mental Model beschreibt den Agenten durch mentalistische Begriffe. Das Teilmodell definiert Agent Personality, Outlook und Premeditation. Die Agent Personality
abstrahiert von der Implementierung einer eventuellen künstlichen Intelligenz. Der
Outlook des Agenten beschreibt seine Weltsicht und enthält dazu eine Struktur aus
Statements. Besondere Statements sind Aims, deren Hierarchie subjektiv die operativen
Ziele des Agenten beschreibt. Die Premeditation ist ein Plan über zukünftige Actions in
Form eines gerichteten azyklischen Graphen.
– 70 –
Das Behavioral Model beschreibt die externe Sicht auf den Agenten. Es konzentriert
sich auf die Beschreibung der Behaviors, die spezifizieren, wie Agenten wahrnehmen,
interagieren und denken. Die mentalen Einstellungen des Agenten werden durch
Position und Schedule beschrieben, welche die öffentlichen Annahmen über Outlook
und Premeditation sind, die dem Agent im Sinne der Legal Stance zugeschrieben
werden können. Behaviors bestehen aus Actions. Diese sind entweder Anwendungen
von Sensors oder Effectors oder Änderungen an Position und Schedule.
Die Culture steht im Mittelpunkt des Social Model. Diese legt Norms fest, dies sind
zum einen Axioms, invariante Zusicherungen und Einschränkungen, die immer erfüllt
sein müssen, und zum anderen Rules, die regeln, welche Verhaltensweisen zulässig
sind. Weiterhin kann eine Hierarchie von Roles definiert werden. Eine Role ist dabei
eine Menge von Behaviors. Zuletzt legt die Culture noch eine Language und Konventionen für Professed Intentions, von Agenten ‚geäußerte’ Willenserklärungen, fest.
Das Herzstück der Conceptual Layer ist das Application Model. Es beschreibt die
Beziehungen der Agents zueinander und die Communities, in denen sich Agenten
organisieren. Eine Community ist eine Instanz einer Culture. Die Community als
Menge von Agenten kann unter Umständen auch selbst als Agent auftreten. Das
Application Model ordnet auch den Agenten ihren User zu, sofern dieser existiert. Der
Benutzer kann dem Agenten einen Purpose geben. Dieser besteht aus einer beliebig
umfangreichen Zielhierarchie aus Missions und soll die Motivation des Agent aus einer
objektiven Perspektive umreißen.
3.3
Modellelemente
In den folgenden Abschnitten werden die Ebenen, Teilmodelle und Elemente des
Metamodells hergeleitet und detailliert beschrieben. Dabei sei nochmals darauf
hingewiesen, daß alle angeführten Modelle, Elemente, Attribute und Beziehungen strikt
optional sind. Sie sollen ein Beschreibungsmittel bieten, nicht normative Aussagen über
das Vorhandensein bestimmter Elemente und Beziehungen in konkreten Systemen
machen. Unterschiedliche Anwendungen setzen unterschiedliche Schwerpunkte, die
von unterschiedlichen Teilen des Modells abgedeckt werden. Bei der Betrachtung der
Interaktion zwischen Agenten und ihrer Umwelt wird etwa häufig auf die Bedürfnisse
physikalischer Agenten eingegangen, während die Spezifikation der angebotenen
– 71 –
Dienste hauptsächlich für Softwareagenten relevant ist. Auf der konzeptuellen Ebene
existieren Gegensätze zwischen den Anforderungen der starken und schwachen KI.
Die einzelnen Elemente werden möglichst abstrakt definiert. Aus Gründen der Anschaulichkeit und um die Motivation der einzelnen Definitionen praktisch zu illustrieren, werden in den Text eingeflochten konkrete Beispiele angeführt.
Die Beispiele sind jeweils durch einen grauen Kasten hervorgehoben. Die verwendeten
Beispiele nehmen auf unterschiedliche Teile des zweiten Abschnitts Bezug. Einerseits
werden einige der beschriebenen praktischen Anwendungen49 zitiert, um einzelne
Anwendungsfälle zu beleuchten. In diesem Zusammenhang werden etwa die Roboter
des RoboCups, elektronische Marktplätze, der Office Agent und das Spiel Quake
herangezogen. Weiterhin werden allgemeinere, aber konkrete Architekturen, wie sie die
Aglets Workbench oder der MASIF-Standard bieten, zitiert. Zuletzt werden auch
Parallelen zu den Elementen der vorgestellten Referenzmodelle und Theorien gezogen.
Daneben wird gelegentlich auf Analogien mit der Alltagswelt zurückgegriffen. Sämtliche Beispiele sind illustrativ, nicht normativ.
Die Struktur und Beziehungen des Modells werden durch Entity-Relationship-Model
(ERM) Diagramme nach Chen [Chen 1976] beschrieben. ERM-Diagramme sind
ursprünglich eine Methode der Datenmodellierung, eignen sich jedoch gleichermaßen
zur Spezifikation einer Metasprache. 50 Sie sind im Prinzip gleichmächtig zu Klassendiagrammen, erlauben aber explizit selbstreferenzierende Beziehungen und bieten eine
klare Notation zur Quantifizierung von Vererbungs- bzw. Spezialisierungsbeziehungen.
Die Diagramme bestehen aus Entitätstypen (Rechtecke) und Beziehungen (Rauten)
zwischen Entitätstypen. In einer Minimum-Maximum-Notation wird quantifiziert, wie
oft der nebenstehende Entitätstyp in eine Beziehung dieser Art eingehen kann bzw. muß.
Dabei können Beziehungen selbst Beziehungen eingehen, wodurch sie zu umdefinierten
49
50
Siehe Abschnitt 2.5.3, S. 51.
Zu einer ausführlichen Rechtfertigung vergleiche [Holten 1999, S. 23f].
– 72 –
Entitätstypen werden (mit einem Rechteck umgebene Raute).51 Spezialisierungsbeziehungen werden durch Dreiecke ausgedrückt, die mit der Spitze auf den generelleren
Typen zeigen. Die Buchstaben im Dreieck bezeichnen, ob die Zerlegung disjunkt (d)
oder nicht-disjunkt (n) ist, sowie ob die Vereinigungsmenge der spezialisierten Typen
den generelleren Typen total (t) oder nur partiell (p) abdeckt.
Selbstreferenz
(0,1)
(0,n)
Entitätstyp
Entitätssubtyp I
d,t
Entitätssubtyp II
(1,n)
(1,1)
Beziehung
Abbildung 3.3
Wesentliche Elemente eines ERM-Diagramms
Für die einzelnen Elemente der physikalischen Ebene werden Attribute und mit dem
Element assoziierte Ereignisse angegeben. Letztere sind für eine Betrachtung der
Dynamik des Systems und eine Operationalisierung von Belang. Wird ein Element noch
in Unterklassen unterteilt, erben die untergeordneten Elemente die Attribute und
Ereignisse ihres übergeordneten Typen. Auf der konzeptuellen Ebene wird gegebenenfalls angegeben, auf welche Elemente der Physical Layer sich das Element abstützt.
Zum Abschluß jeder Elementbeschreibung werden die Definition, Attribute, Beziehungen und Ereignisse des Elements kurz zusammenfassend dargestellt. Das Verzeichnis
der Modellelemente verweist jeweils auf die Kurzbeschreibung des Elements, die auf
51
In der beispielhaften Abbildung der grafischen Notation nicht dargestellt. Als illustratives Beispiel
kann die Schließung einer Ehe (Beziehung) zwischen zwei Personen (Entitätstyp) dienen. Die Trauzeugen (Entitätstyp) können nicht eindeutig den einzelnen Ehepartnern, sondern nur der Ehe (hier also
Entitätstyp) zugeordenet werden (Beziehung).
– 73 –
diese Weise eine übersichtliche Referenz bieten sollen. Da die Zusammenfassungen
ohnehin im Wesentlichen aus den (englischen) Modellbegriffen bestehen, wurden sie
direkt komplett auf Englisch formuliert.
Element Summary
Element Name – conventional name, aims for clarity and casual usability
Hierarchical Name
Layer.Model.Element – conventional names containing spaces are abbreviated
Definition
Short definition of the element
Attributes
List of common attributes
Relationships
Relationships to Other Elements
Event Classes
Important classes of events generated by this element
Formalisms
Formalisms for expressing conceptual elements
Grounding
Physical layer elements conceptual element is grounded in
Examples
Some examples for purely illustrative purposes
Die grafischen Strukturmodelle werden jeweils zusammenfassend hinter die detaillierte
Beschreibung der darin enthaltenen Elemente gestellt. Zu Beginn jedes Abschnittes
wird aber auf die einschlägigen Diagramme verwiesen, so daß diese auch zum Gewinnen eines ersten Überblicks oder als begleitende Orientierungshilfe genutzt werden
können. Am Ende der Beschreibung jedes Teilmodells wird kurz beschrieben, wie sich
seine Elemente zur Formulierung kompletter Modelle verwenden lassen und welche
Notationen sich dabei anbieten. In einigen Fällen werden zur Illustration einfache
Modelle aufgestellt und visualisiert.
3.3.1 Physical Layer
Die Physical Layer52 ist konzeptionell die einfachere der beiden Ebenen. Bei der
Anwendung ihrer Elemente zur Beschreibung konkreter Systeme entstehen jedoch
komplexe Modelle, da hier auch die technischen Details erfaßt werden.
In Abgrenzung zur Conceptual Layer legt die Physical Layer den Schwerpunkt der
Betrachtung auf die konkreten Elemente eines Systems. Dies kann und soll jedoch nicht
52
Abbildung 3.15, S. 117, bietet eine Übersicht über die wichtigsten Elemente der Physical Layer.
– 74 –
bedeuten, daß die Beschreibung frei von Abstraktionen und Semantik ist. Die verwendeten Konzepte sind lediglich direkter im beobachtbaren Teil des Systems verankert.
Das zentrale Konzept der Ebene ist die Sicht des Agenten als System, das mit Sensoren
und Effektoren mit seinem Umweltkontext interagiert. Die Perspektive ist somit
agentenzentriert, es wird auf der Ebene der kognitiven Umwelt von Agenten argumentiert.
3.3.1.1 Environment Model
I.
Elemente
A.
Environment
Der Umweltkontext der Agenten wird als Environment beschrieben. Agenten sind von
ihrem Environment existentiell abhängig: Ihre physikalische Form auf der Physical
Layer terminiert, wenn das Environment aufhört zu existieren.
Das Environment ist selbst wiederum ein System, das von seiner Umwelt abzugrenzen
ist. Dabei ist ausschlaggebend, ob die Intensität der Beziehungen innerhalb der Systemgrenzen als intensiver empfunden werden als die Beziehungen über diese Grenzen
hinweg (vgl. [Teubner 1999, S. 9ff]). Diese Abgrenzung ist zwangsläufig subjektiv. Es
sollte jedoch möglichst das minimale System gewählt werden, das in der Lage ist, die
gesamte Wahrnehmungs- und Erkenntniswelt der Agenten zu repräsentieren. Dabei muß
dieses System keineswegs geschlossen sein, sondern kann Schnittstellen zu Ressourcen
in seiner Umwelt anbieten.
Der Microsoft Office Agent existiert im Rahmen des Microsoft Office Prozesses mit
seinen Ressourcen und Datenstrukturen. Sein Verhalten kann innerhalb dieses Bezugssystems vollständig beschrieben werden, so daß sich der Prozeß als relevantes Environment anbieten würde. Der Prozeß existiert selbst wiederum im Rahmen des Betriebssystems, dessen Dienste (Dateisystem, Ein- und Ausgabe auf Peripheriegeräten)
als externe Ressourcen zugänglich sind. Dies ließe sich im Stil der Systemebenentheorie
bis auf die Ebene der physikalischen Realität weitertreiben, was in diesem Zusammenhang nicht sinnvoll scheint, da dort keine adäquate Beschreibung mehr möglich ist.
– 75 –
Für die fußballspielenden Roboter des RoboCup bietet sich hingegen die physikalische
Realität, bzw. das Fußballfeld als deren relevanter Ausschnitt, durchaus als passendes
Environment an.
Wo dies sinnvoll erscheint, kann auch ausgehend von einem minimalen Environment
eine Hierarchie jeweils weiter gefaßter Environments definiert werden. Während die
eigentliche Umgebung umfassend modelliert wird, werden dabei die weiteren Environments zumeist entsprechend weniger detailliert beschrieben werden. Sie können
dabei helfen, für bestimmte Prozesse relevante externe Strukturen zu erfassen, ohne
dabei das Kernmodell unnötig aufzublähen.
Daneben können zwischen Environments auch nichthierarchische Beziehungen
bestehen. Das Verhältnis der einzelnen Environments zueinander legt eine netzwerkartige Struktur fest. Die Modellierung von Nachbarschaftsbeziehungen hilft etwa bei der
im Zusammenhang mit Migration, dem Wechsel von einem Environment in ein
anderes, relevanten Frage nach der Existenz und Erreichbarkeit anderer Umgebungen.
Jedes abgegrenzte System besitzt eine zumindest implizite Identität. Die Definition von
Beziehungen erfordert allerdings generell die explizite Verwendung von Ordnungsbegriffen, in diesem Falle bevorzugt Namen oder Adressen.
Für Multiagentensysteme ist es zumeist naheliegend, die von der verwendeten Agentenplattform angebotene Laufzeitumgebung als Environment zu betrachten. Migration ist
dabei der Wechsel zwischen miteinander verbundenen Environments.
Sieht ein Modell die Möglichkeit mehrerer Laufzeitumgebungen auf dem selben
Netzwerkknoten vor und möchte dabei zwischen lokaler und netzwerkbasierter
Migration unterscheiden, ist es sinnvoll, den Netzwerkknoten als übergeordnetes
Environment zu definieren, dessen Strukturelemente die Laufzeitumgebungen sind.
Jedes Environment ist mit drei Spezifikationen assoziiert, die seine spezifischen
Eigenschaften beschreiben. Das Entity Model beschreibt die Strukturen innerhalb des
Environment, das Process Model beschreibt seine aktiven Prozesse und die in ihm
herrschenden Gesetze, und das Service Model beschreibt die angebotene Infrastruktur.
– 76 –
In Abhängigkeit von der Komplexität und der Reichhaltigkeit eines Environment
können die Teilmodelle sehr umfangreich oder auch leer sein.
Die Spezifikation einer Anwendung auf Basis eines Multiagentensystems wird in allen
drei Teilmodellen umfangreiche Festlegungen treffen müssen. Das Umweltmodell eines
persistent gespeicherten Agenten wird dagegen äußerst simplizistisch sein.
Die Beschreibung des Environment legt umfassend den Hintergrund dar, vor dem die
Agenten eines Systems agieren. Das charakteristische Profil unterschiedlicher Architekturen und Plattformen sollte sich als Spezifikation eines Environment eindeutig
ausdrücken lassen. Diese Spezifikation könnte dann als Ausgangspunkt der Modellierung einer konkreten Anwendung auf einer Plattform dienen.
Environments sind zwangsläufig das stabilste Element der Physical Layer. Jedoch
können durchaus zur Laufzeit neue Environments hinzugefügt werden oder – für die
Stabilität verteilter Systeme von größerer Bedeutung – dynamisch entfernt werden.
Letzteres Ereignis muß von der Modellierung erfaßt werden, wenn beim Ausfall eines
Netzwerkknotens alle Agenten, die dorthin migriert waren, auf ihren Ursprungsknoten
automatisch aus Sicherungsdateien wiederhergestellt und reaktiviert werden sollen.
Element Summary
Environment
Hierarchical Name
Physical.Environment
Definition
A system that Agents exist, sense and act in.
Attributes
Identity
Enitity Model Specification
Process Model Specification
Service Model Specification
Relationships
Contains, contained by, references Environment
Contains Entity
Runs Process
Offers Service
Event Classes
Created, Terminated
Examples
Agent management system, virtual machine, file system, operating system,
network node, subset of the physical world.
– 77 –
II.
Modellierung
Da das Environment Model nur einen einzigen Elementtyp enthält, ist sein Strukturmodell entsprechend simpel.
Hierarchy
(0,1)
(0,n)
Environment
(0,n)
(0,n)
Structure
Abbildung 3.4
Elementbeziehungen innerhalb des Environment Model
Wenn bei der Modellierung einer Anwendung mehr als ein Environment definiert wird,
bietet sich eine explizite Darstellung des Teilmodells an. Geeignete Formalismen wären
etwa Organigramme oder UML Deployment-Diagramme.
Im Folgenden wird ein schematisches Beispiel für ein Environment Model einer
verteilten agentenbasierten Anwendung angegeben. Die Agenten werden im Rahmen
von Agentenplattformen (Agent Management System) ausgeführt, die als das primäre
Environment betrachtet werden. Von manchen Plattformen können Agenten serialisiert
und persistent als Datei im Dateisystem (File System) abgelegt werden, wodurch sie von
diesem und nicht mehr von der Agentenplattform abhängig sind. Diesen Environments
übergeordnet ist der Netzwerkknoten (Node), der ein oder mehrere Dateisysteme und
Agentenplattformen enthält. Die Knoten sind teilweise durch ein lokales Netzwerk
(LAN), teilweise durch ein öffentliches Netzwerk (WAN) verbunden, durch die Agenten
sich bei der Migration bewegen. Knoten und Netzwerke können abschließend als
Subsysteme der Realwelt (Physical World) verstanden werden.
– 78 –
Agent
Management
System
Agent
Management
System
Node
WAN
Agent
Management
System
File System
Agent
Management
System
Node
LAN
Node
(Physical World)
Dependency
Accessibility
Abbildung 3.5
Schematischer Aufbau eines Anwendungssystems
Das obenstehende Diagramm illustriert zum einen die existentiellen Abhängigkeiten
zwischen den Umgebungen (durchgezogene Linien) und zum anderen ihre Kommunikationsbeziehungen (gestrichelte Linien).
Die beiden durch ein lokales Netz verbundenen Knoten könnten als eine Region im
Sinne des MASIF-Standards53 betrachtet werden. Die Region sollte aber nicht durch ein
übergeordnetes Environment modelliert werden, da sie im Allgemeinen kein reales,
sondern ein logisches Konstrukt ist. Sie kann auf der konzeptuellen Ebene als Objekt
beschrieben werden, wird hier aber nur durch die besondere Beziehung der beteiligten
Netzwerkknoten (blaue Linien) ausgedrückt.
3.3.1.2 Entity Model
Das Entity Model beschreibt die systeminternen Strukturen eines Environment. Es ist
ein statisches Modell, das nicht den dynamischen Zustand des Systems zu einem
53
Siehe Abschnitt 2.5.1.1, S. 46.
– 79 –
Zeitpunkt beschreibt, sondern die Menge (komplexe Hülle) aller erlaubten Zustände und
Interaktionen festlegt.
Mit Sensoren und Effektoren läßt sich im Grunde nur in Verbindung mit einem
Objektbegriff sinnvoll argumentieren, da sonst nicht beschrieben werden kann, w a s
wahrgenommen bzw. manipuliert wird. Die Objektseite der Interaktionen des Agenten
mit dem Environment wird daher durch ein System von Entities beschrieben. Indem er
ihre Art und Beziehungen im Entity Model54 dokumentiert, legt ein Modellierer eine
Ontologie der wahrgenommenen Agentenumwelt für den weiteren Entwurfsprozeß fest.
Das Entity Model ist primär ein Modellierungswerkzeug. Es beschreibt die Weltsicht
eines e xt e r n e n Beobachters, des Modellierers, und damit nicht zwangsläufig die
tatsächlichen Wahrnehmungen der Agenten. Auf keinen Fall macht es eine Aussage
über die von den Agenten verwendete interne Repräsentation der Welt.
Wie bei der Vorstellung der Theorie der physikalischen Abstützung55 beschrieben,
lehnen Vertreter einer schwachen KI eine Modellierung der Umwelt durch abstrahierende Entitäten prinzipiell ab („Intelligence without representation“, [Brooks 1991]).
Die Abbildung der Welt durch ein System von Symbolen schafft zwar einen – potentiell
trügerischen – Rahmen, in dem Strategien formuliert werden können, die Agenten die
Lösung komplexer Probleme erlauben.56 Praktisch relevant sind die gewonnen Erkenntnisse jedoch nur, wenn auch eine Möglichkeit angegeben wird, wie der Agent in einer
realen Problemsituation die Extraktion der Symbole, die während der Modellierung
vom menschlichen Intellekt geleistet wird, selbst nachvollziehen kann.
Soll die Wahrnehmung der Welt daher strikt aus der Agentenperspektive beschrieben
werden, muß die Modellierung eine rein empiristische Philosophie verfolgen: Die Welt
existiert nur in Form der konkreten Wahrnehmungen der Agenten, so daß sich als Entity
höchstens einzeln abgrenzbare Sensormessungen beschreiben lassen.
54
Abbildung 3.9, S. 94, bietet einen Überblick über die Struktur und Beziehungen der verschiedenen
Arten von Entities. Abbildung 3.10, S. 102, faßt die Modellelemente zusammen, die die Interaktion der
Agenten mit ihrer Umwelt beschreiben.
55
Siehe Abschnitt 2.3.3, S. 29.
56
Ein klassisches Beispiel eines sehr einfachen solchen Rahmens ist die Klötzchenwelt ([Winograd 1972],
vgl. auch [Slaney/Thiébaux 2001]).
– 80 –
In der Subsumption Architecture57 fließen von den Sensoren zu den Systemkomponenten (und zwischen den Komponenten) ausschließlich bedeutungsfreie, nur im
Kontext des Systemzustands von einem externen Beobachter interpretierbare Zahlen.
Dies sind die einzigen identifizierbaren Entities – ein darüber hinausgehendes Modell
der Welt existiert nicht.
Selbst die Verfechter der physikalischen Abstützung erkennen an, daß diese Darstellung
für die Zwecke des menschlichen Modellierers unzureichend ist. Würde jegliche
Metaphysik abgelehnt, ließe sich nicht einmal der Agent selbst als System mit Sensoren
und Effektoren beschreiben. Interaktion in einem Multiagentensystem läßt sich zumindest nicht im herkömmlichen Sinne verstehen, wenn den anderen Agenten keine über
die Wahrnehmungen des betrachteten Agenten hinausgehende Essenz zugesprochen
würde. Zuletzt erfordert die adäquate Formulierung von Zielen und Strategien meistens
abstrakte Begriffe, die eine Interpretation einer Situation zulassen – selbst wenn diese
später im Agenten nur implizit umgesetzt werden. Entscheidend ist, diese Begriffe im
Bezugssystem des Agenten nicht einfach als gegeben vorauszusetzen.
Ein Agent im Rahmen des RoboCup muß andere Spieler erkennen können, was
zumindest ein implizites Bewußtsein bezüglich der Existenz anderer Agenten erfordert.
Weiterhin gilt es, den ‚Ball’ in das gegnerische ‚Tor’ zu befördern – ein Ziel, das sich
ohne diese Begriffe nur sehr umständlich und unverständlich beschreiben läßt. Die
tatsächliche Erkennung von Spielern, Ball und Tor ist allerdings ein erhebliches
technisches Problem.
Für reine Softwareagenten sind die Überlegungen bezüglich der Abbildung der Welt
durch Symbole vergleichsweise unerheblich. In einem Computer als künstlichem
System sind oberhalb der Schaltkreisebene alle Elemente Artefakte, die das Ergebnis
einer Modellierung sind. Daher kann auch durch klar abgegrenzte Entities die objektive
Realität des Systems erfaßt werden.
57
Siehe ebenfalls Abschnitt 2.3.3, S. 29.
– 81 –
I.
Elemente
A.
Entity
Eine Entity ist somit jede Entität, die nach dem Ermessen des Modellierers entweder
selbst ein Agent ist oder zumindest prinzipiell gemäß den Gesetzen des Environment
von einem Agenten wahrgenommen oder beeinflußt werden kann.
Bei der Modellierung der Entities treten die von objektorientierten Modellen bekannten
klassischen Entscheidungsprobleme auf: Die Wahl des Detaillierungsgrades und der
Abgrenzungskriterien zwischen den verschiedenen Entities ist weitgehend willkürlich.
Die Definition einer Entity schließt nicht ein, daß sie Instanz eines Typs sein muß. In
der realen Welt sind Klassen abstrakt, und auch in der Softwaretechnik bietet nicht jede
Programmierumgebung ein Typsystem, weswegen Entities im Allgemeinen ungetypt
sind. Sie können aber eine abstrakte Klasse als Attribut tragen bzw. einen Typ referenzieren, wenn sich dieser als Entity modellieren läßt.
Für physikalische Entities, etwa einen Ball, ist ihre abstrakte Klasse (‚Ball’) nur ein
nominales Attribut. Existiert der Typ einer Entity jedoch konkret, etwa bei einem
Objekt in Form des Programmcodes, kann er auch als Entity referenziert werden.
Jede Entity ist somit eine distinkte Instanz. Dies impliziert, daß jede Entity eine
inhärente Identität besitzt. Diese muß aber kein explizites Attribut sein. Selbst wenn sie
explizit modelliert ist, muß sie nicht zwangsläufig für Agenten wahrnehmbar sein.
Zwei gleichaussehende Tennisbälle sind nur anhand ihrer gegenwärtigen Position (und
beobachteten Vergangenheit) unterscheidbar, ihre Identität wird also nur impliziert.
Zwei gleichaussehende simulierte Gegner bei Quake besitzen zwar innerhalb des
Programms eine explizite Identität (in Form eines Eintrags in einer Zeigertabelle), sind
aber für den Spieler ebenfalls nur anhand ihrer Position unterscheidbar. In einem
MASIF-konformen System hat jeder Agent dagegen eine explizite, öffentliche Adresse.
Bei der Modellierung lassen sich Entities nicht nur eindeutige Bezeichner, sondern auch
beliebige andere, domänenspezifische Attribute zuweisen. Auch hier ist wiederum
– 82 –
Intransparenz durch Kapselung möglich: Eine Entity darf auch Attribute definieren, die
für Agenten nicht wahrnehmbar oder manipulierbar sind.
Entities, von Agenten einmal abgesehen, sind passiv. Daher existieren bei einer
Betrachtung der Dynamik des Systems für sie auch nur drei relevante Klassen von
Ereignissen: Entities können erzeugt, zerstört und durch Agenten oder Umweltprozesse
verändert werden.
Wie einführend gefordert wurde, sollen Entities die gesamte ‚Erkenntniswelt’ der
Agenten beschreiben können, die sich in Abhängigkeit vom Anwendungskontext aus
sehr unterschiedlichen Elementen zusammensetzen kann. Um die Semantik einiger
häufig wiederkehrender Elemente präziser beschreiben zu können, werden im Folgenden Unterklassen von Entity definiert. Neben der schon angedeuteten Unterteilung in
Agenten und Nichtagenten (Items) wird die Menge der Entities darüber hinaus noch
weiter untergliedert.
Agent
Message
d,t
Resource
Item
n,p
Proxy
Entity
Type
Facility
d,p
Percept
Abbildung 3.6
Untergliederung des Begriffs Entity
– 83 –
Element Summary
Entity
Hierarchical Name
Physical.Entity
Definition
Any entity that can potentially be perceived or manipulated by an Agent
Attributes
Identity (implicit)
Type (untyped / nominal / reference to Type Entity)
Set of specific Attributes
Relationships
Arbitrary relationships with other Entities
Perceived by Sensors
Manipulated by Effectors
Event Classes
Created, Changed, Destroyed
Examples
Agents, Walls, Soccer Balls, Sensor Readings, Files, Databases, Sockets,
Messages, Service Directories, Java Objects
i.
Agent
a.
Definition
Agents sind die aktiven Komponenten des Systems. Das Modellelement Agent setzt die
zugrundegelegte58 operative Definition eines Agenten als System, das mit seiner
Umwelt durch Sensoren und Effektoren interagiert, unmittelbar um. Die Definition ist
bewußt so generisch gewählt worden, daß sie auch von klassischen Automaten erfüllt
wird. Was als Agent modelliert wird, liegt weitestgehend im Ermessen des Entwicklers,
auch wenn sich für etablierte Anwendungskontexte sicherlich Erfahrungswerte formulieren lassen, welche Granularität und Anzahl von Agenten am zweckmäßigsten
erscheint.59
Der eBay-Agent ist als ein einfacher Automat interpretierbar, der eine Eingabe (neues
fremdes Höchstgebot) gemäß einer Regel (maximal gewünschtes Gebot) in eine
Ausgabe (neues eigenes Gebot) transformiert. Sein Agentenstatus läßt sich eher auf der
konzeptuellen Ebene begründen, da er stellvertretend und selbsttätig handelt.
Von wesentlicher Bedeutung ist, wie der Agent als System mit Ein- und Ausgabebeziehungen abgegrenzt wird. Per Definition ist jeder Agent auch eine Entity. Er kann somit
58
59
Siehe Abschnitt 3.1.2, S. 59.
Für entsprechende Faustregeln vgl. etwa [Wooldridge/Jennings 1998, S. 5f].
– 84 –
von anderen Agenten und der Umwelt wahrgenommen und manipuliert werden, was
eine Grundvoraussetzung für Interaktion in Multiagentensystemen ist. Dabei kann für
den Agenten bereits in seiner Eigenschaft als Entity eine Kapselung seiner Attribute
definiert werden. Da der Kapselungsaspekt bei Agenten hier aber als zentral angesehen
wird, erscheint in diesem Zusammenhang die Möglichkeit zu einer präziseren Beschreibung erforderlich. Daher läßt sich ein Agent bei Bedarf in zwei Teile unterteilen: die
Agent Shell, die als ‚äußere Hülle’ die extern beobachtbare Repräsentation des Agenten
beschreibt, und den Agent Core, der die Interna des Agenten wie die technische
Umsetzung einer eventuellen Wissensrepräsentation oder Inferenzmaschine umfaßt.60
Auf diese Weise kann klar modelliert werden, welche Informationen über einen
Agenten auf technischer Ebene anderen Agenten zur Verfügung stehen.
Ein Agent hat per Definition die volle Kontrolle über seinen Agent Core in dem Sinne,
daß sein Zugriff darauf keinen extern diktierten Einschränkungen unterliegt. Die Agent
Shell kann dagegen durch ihre Umwelt verändert werden. Der Agent hat zwar in der
Regel einen privilegierten Zugang zu seiner Agent Shell, kann sie aber unter Umständen nicht direkt, sondern nur unter Verwendung von Sensoren und Effektoren wahrnehmen bzw. beeinflussen.
Aglets verwenden ein Proxy-Objekt (Agent Shell), das die öffentlichen Methoden des
eigentlichen Aglet-Objekts (Agent Core) schützt. In einer simulierten Welt (wie etwa
Quake) repräsentiert in der Regel ebenfalls ein Objekt (Agent Shell) den simulierten
‚Körper’ des Agenten. Auf dessen Attribute, beispielsweise die Position im simulierten
Raum, hat der Agent keinen direkten Einfluß, sondern kann sie nur durch Effektoren
(‚bewege’) im Rahmen der Gesetze der simulierten Welt verändern. Dies läßt sich
unmittelbar auf physikalische Agenten übertragen, die den Naturgesetzen unterworfen
sind und nur die Informationen über ihr Chassis besitzen, die ihre Sensoren liefern (also
etwa nicht ihre Farbe, wenn sie Ultraschallsensoren verwenden).
60
Dies zieht auf der technischen Ebene eine Parallele zur Unterscheidung zwischen Observable Core und
Internal Machinery auf der konzeptionellen Ebene durch Viroli/Omicini (siehe Abschnitt 2.4.3, S. 44).
– 85 –
Der Versuch, den Agenten durch zwei völlig getrennte Entitäten zu beschreiben, führt
zu unintuitiven Ergebnissen. Wird die physikalische oder virtuelle Steuerungslogik als
der eigentliche Agent und die von außen zugängliche Repräsentation als quasi ferngesteuerte passive Entity gesehen, geht dabei die existentielle Abhängigkeit zwischen den
beiden Teilen verloren. Die Trennung zwischen Agent Shell und Agent Core ist
weicher und kontextbezogen modellierbar.
Unintuitiv erscheint etwa, das menschliche Nervensystem als einen Agenten zu sehen,
der den Körper als separate Entität steuert. Eine Sicht der Körperoberfläche als unmittelbar wahrnehmbare und beeinflußbare Hülle um ein weitgehend selbstbestimmtes
Inneres ist hingegen für viele alltägliche Situationen praktikabel.
Als der Agent im weiteren Sinne kann der eigentliche Agent zusammen mit den von
ihm benötigten proprietären Ressourcen61 verstanden werden.
Die Sensoren und Effektoren, mit denen der Agent mit dem Environment interagiert,
werden als eine Menge ihm zugeordneter Sensors und Effectors beschrieben. Sensors
und Effectors werden unten als eigene Modellelemente definiert.62
b.
Zustandmodell und Lebenszyklus
Da Agents die zentralen aktiven Elemente des Modells sind, sind die mit ihnen assoziierten Zustände und Ereignisse für die Beschreibung der Dynamik des Systems von
besonderem Interesse. Viele der technisch relevanten Prozesse und Ausnahmezustände
sind eng mit Zustandsübergängen von Agents verknüpft.
Jeder Agent entspricht als aktives System dem von Prozessen bekannten trivialen
Zustandsmodell wird aktiviert → wird ausgeführt → beendet, wobei der letzte Zustand
nicht in endlicher Zeit erreicht werden muß. Softwareagenten im Besonderen hängen zu
ihrer Ausführung in irgendeiner Form von einem Betriebssystemprozeß ab und sind
somit dessen Lebenszyklus Initialisierung, Ausführung/Warten, Terminierung (Initiali-
61
62
Siehe im Detail Resource, S. 90.
Siehe Sensor, S. 97 bzw. Effector, S. 99.
– 86 –
zing → {Running ↔ Waiting} → Terminated) unterworfen. Soll der Agent zusätzlich
Persistenz bieten, muß der gegenwärtige Ausführungszustand eingefroren und gespeichert werden können. Der Agent kann dann mit dem gespeicherten Zustand neu
initialisiert und reaktiviert werden. Der identische Mechanismus wird gegebenenfalls
von zustandsbehafteter Migration genutzt, zustandslose Migration entspricht einer
Neuinitialisierung im Ziel-Environment.
Abbildung 3.7
Initialized
Active
Captured
Suspended
Terminated
Grundlegendes Zustandsmodell eines Agenten
Dies führt auf das obenstehende einfache Zustandsmodell mit den Zuständen Initialized
(ist initialisiert), Active (wird ausgeführt), Suspended (wartet/eingefroren), Captured
(Ausführungszustand eingefangen) und Terminated (ist beendet).
Nachfolgend wird auf Basis dieser Zustände ein detaillierteres Lebenszyklusmodell in
Form eines Aktivitätsdiagrammes vorgestellt, das näher auf die Auslöser der Zustandsübergänge eingeht und mögliche Ausführungsfehler einschließt. Die in der Beschreibung in Klammern angegebenen Begriffe sind die von den Zustandsübergängen
ausgelösten Ereignisse.
Eine neue Agenteninstanz wird zunächst erzeugt und initialisiert, was scheitern kann
(Ereignis: failed). Bei Erfolg (initialized) wird versucht, die zur Ausführung des
Agenten erforderlichen Ressourcen zur Verfügung zu stellen, und gegebenenfalls
gewartet. Sobald alle Ressourcen verfügbar sind, wird der Agent ausgeführt (activated).
Dabei kann er neue Ressourcen anfordern, auf die er gegebenenfalls warten muß
(interrupted). In der Regel erfordert eine erfolgreiche Beendigung der Ausführung
(completed), daß der Agent zu diesem Zeitpunkt aktiv ist, da nur der Agent selbst den
Erfolg erklären kann. Die Ausführung des Agenten kann jederzeit scheitern (aborted).
Der Agent kann während der Ausführung und während er auf Ressourcen wartet exogen
angehalten werden (suspended). Er ist dann vollkommen inaktiv und fremdbestimmt,
kann aus diesem Zustand aber noch direkt wieder aufgeweckt werden. Die Suspendierung kann allerdings auch bedeuten, daß der Agent durch einen gezielten Akt oder im
– 87 –
Rahmen der Terminierung seines Environments vorzeitig beendet wird (aborted).
Zuletzt kann sie auch bedeuten, daß der Agent eingefroren wird, um seinen Zustand
einfangen zu können. Dieser kann persistent gespeichert werden (stored) oder im
Rahmen eines Migrationsprozesses sein Environment verlassen (migrated) und in ein
anderes Environment wandern. Ein System kann Mechanismen vorsehen, um auf
Fehler während der Migration (lost) zu reagieren, in Softwaresystemen etwa durch
Reaktivieren einer lokal zurückbehaltenen Kopie. Bei erfolgreicher Migration oder der
Wiederherstellung aus einem nichtflüchtig gespeicherten Zustandsabbild wird versucht,
den Ausführungszustand des Agenten wiederherzustellen. Ist dies erfolgreich (reactivated), werden wiederum Ressourcen alloziert und die Ausführung wieder aufgenommen.
[Transmission successful]
[Store]
[Completed]
Abbildung 3.8
[Migrate]
[Transmission error]
Transitting
[Save agent state]
Suspended
[Terminate execution]
[Suspend acquisition]
[Resources available]
[Resume execution]
[Suspend execution]
Capture State
[Execution failure]
[Completion]
Run Agent
[Failed]
Persistently
stored
[Wait for resource]
Acquire
Resources
[Resource required]
[Initialized]
[Initialization failure]
Initialize Agent
[Reactivate]
[Aborted]
[Rollback]
Recovery
Procedures
[No recovery]
[Agent reconstructed]
Reconstruct
State
[Lost]
Schema des Agentenlebenszyklus
Der beschriebene Lebenszyklus ist etwa in Verbindung mit den Diensten des Service
Model von Bedeutung, da verschiedene Dienste die beschriebenen Zustandsübergänge
entweder auslösen oder von ihnen angestoßen werden.
– 88 –
Element Summary
Agent
Hierarchical Name
Physical.Entity.Agent
Extends
Entity
Definition
The concrete manifestation of an agent
Attributes
Internal state
Relationships
May consist of Agent Shell and Agent Core
Possesses Sensors
Possesses Effectors
Event Classes
Initialized, Activated, Interrupted, Suspended, Reactivated, Stored, Migrated
Lost, Failed, Aborted, Completed
Examples
See Section 2.5.3 above.
Element Summary
Agent Shell
Hierarchical Name
Physical.Entity.Agent.Shell
Definition
The observable, accessible part of an Agent’s implementation
Relationships
Subsystem of Agent
Examples
An Aglet’s Proxy object, the player’s avatar in a game
Element Summary
Agent Core
Hierarchical Name
Physical.Entity.Agent.Core
Definition
The internal, self-controlled part of an Agent’s implementation
Relationships
Subsystem of Agent
Examples
The actual Aglet object, the player of the game, a BDI-engine
ii.
Item
Item ist der Gegenbegriff zu Agent: Jede Entity, die kein Agent ist, ist ein Item. Items
sind somit die passiven Komponenten des Environment. Items machen gerade im Falle
von Softwareagenten zumeist den überwiegenden Teil des Gesamtsystems aus. Spezielle – weder erschöpfende noch sich gegenseitig ausschließende – Unterklassen von Item
sind Nachrichten, Ressourcen, externe Schnittstellen und Typdefinitionen.
In einem objektorientiert programmierten Agentensystem sind alle Objekte – außer den
Agenten natürlich – Items.
– 89 –
Element Summary
Item
Hierarchical Name
Physical.Entity.Item
Extends
Entity
Definition
An Entity that is specifically not an Agent
Examples
Bank account, soccer ball, XML message, executable file, database
a.
Message
Aufgrund der besonderen Bedeutung, die Kommunikation in vielen Multiagentensystemen zukommt, werden Nachrichten gesondert modelliert. Eine Message ist ein Item,
das zur Kommunikation dient. Die Sicht ist wiederum agentenzentrisch: Per Definition
ist eine Message jedes Item, das von einem Verbal Effector erzeugt bzw. von einem
Auditive Sensor63 wahrgenommen wird.
Eine FIPA-ACL Nachricht, die von zwei Agenten eines Systems ausgetauscht wird, ist
das naheliegendste Beispiel einer Message. Eine Message kann aber auch ein Lichtblitz,
ein gesetztes Flag, eine Datei oder ein Funktionsaufruf sein.
In der Anwendung ist es in vielen Fällen eine Frage der Interpretation, was genau als
Message zu werten ist. Bietet das Environment dedizierte Mechanismen zum Nachrichtentransport, wie sie etwa der FIPA-Standard oder viele Agentenplattformen vorsehen,
ist die Definition eindeutig. Ist eine Message jedoch nicht auf technischer, sondern nur
auf semantischer Ebene als solche erkennbar, ist sie ein soziales Konstrukt und somit
nur unter Bezugnahme auf die Conceptual Layer definierbar. Unter Umständen, wie
etwa im Falle des Funktionsaufrufes, können Messages auch nur ein abstraktes Konzept
sein.
Messages haben einen Absender, den Agenten, der sie erzeugt hat. Sie können einen
oder mehrere explizit angegebene Empfänger haben, wenn das Transportmedium dies
zuläßt. Ihr Inhalt ist in einer festgelegten Form kodiert. Die Bedeutung des Inhalts ist
auf der Conceptual Layer definiert.
63
Dies sind die unten genauer definierten Sensoren und Effektoren eines Agenten, die dediziert der
Kommunikation dienen. Siehe Sensor, S. 97 bzw. Effector, S. 99.
– 90 –
Eine FIPA-ACL Nachricht hat einen expliziten Absender und Empfänger. Sie kann in
XML oder im LISP-Stil kodiert werden. Ihre Bedeutung ergibt sich aus den im
Standard angeführten Definitionen in FIPA-SL.
In Verbindung mit Messages können einige spezifische Ereignisklassen auftreten, die
mit der Übertragung der Nachricht zusammenhängen: Die Zustellung kann erfolgen,
vom Transportsystem aufgeschoben werden oder endgültig scheitern.
Element Summary
Message
Hierarchical Name
Physical.Entity.Item.Message
Extends
Item
Definition
An Item that is emitted by a Verbal Effector or sensed by an Auditive Sensor,
i.e. represents a communication
Attributes
Emitting Agent , Addressee(s), Content, Encoding, Semantics
Relationships
Emitted by Verbal Effector
Perceived by Auditive Sensor
Event Classes
Received, Queued, Failed
Examples
ACL message, text file, specific function call, sound or light pattern
b.
Resource
Eine Resource ist ein Item, das von einem Agenten zur Ausführung benötigt wird. Der
Begriff wird in zwei unterschiedlichen Ausprägungen verwendet. Proprietary Resources sind mit einem Agenten assoziierte Items, die somit Teil des Agenten im weiteren
Sinne sind. Migriert der Agent in ein neues Environment, müssen alle seine Proprietary Resources dort entweder schon vorhanden sein oder mit ihm migrieren.
In einem Java-basierten System sind typische Proprietary Resources die .class oder
.jar Dateien, in denen sein ausführbarer Code gespeichert ist. Als Proprietary Resource
eines Roboters könnte etwa eine externe Stromversorgung gesehen werden.
Shared Resources sind dagegen öffentliche Ressourcen, die in der Regel an ein
Environment gebunden sind und nicht migrieren können. Sie sind nicht mit einem
bestimmten Agenten assoziiert, sondern werden von allen Agenten und Umweltprozessen gemeinsam genutzt, sei es gleichzeitig oder sequentiell exklusiv.
– 91 –
Typische Shared Resources in einem Softwaresystem sind Dateien, Sockets oder
externe Datenbanken. Im abstrakteren Sinne sind darunter auch Rechenzeit und
verwendeter Arbeitsspeicher zu verstehen.
Allen Resources ist gemein, daß sie entweder verfügbar, angefordert, aber noch nicht
erhalten, oder nicht verfügbar sind. Wenn eine Resource nicht verfügbar ist, wird die
reguläre Ausführung des Agenten zwangsläufig unterbrochen; es ist aber denkbar, daß
der Agent aktiv auf den Ausnahmezustand reagiert, etwa durch Abbruch der Migration
im Falle einer Proprietary Resource oder durch Aufgabe der konkreten Aktivität, die
eine bestimmte Shared Resource benötigt.
Element Summary
Resource
Hierarchical Name
Physical.Entity.Item.Resource
Extends
Item
Definition
An Item that is required for an Agent’s execution
Relationships
Required by Agent
Event Classes
Available, Requested, Unavailable
Examples
Configuration file, .jar file, socket, external database, memory, power cable
c.
Proxy
Ein Proxy ist ein Item, das eine Entität außerhalb des Environment vertritt. Proxies
sind die Schnittstellen, die das Environment den Agenten anbietet, etwa um in anderes
Environment zu migrieren oder um auf die umgebende Infrastruktur zuzugreifen.
Viele Agentenplattformen bieten Schnittstellen zu externen Datenbanken, zum Netzwerk oder zum Dateisystem an, die als Proxies verstanden werden können.
Daneben kann ein Proxy auch zur Kommunikation dienen. Verläßt ein Agent ein
System, kann er einen Proxy zurücklassen, über den andere Agenten ihm Nachrichten
nachsenden können. (Der Proxy vertritt zwar einen Agenten, ist aber passiv und daher
ein Item.)
Aglets verwenden Proxies in diesem Sinne zum Routing von Nachrichten.
Da die durch den Proxy repräsentierte Entity Teil eines anderen Environments ist,
entzieht sie sich der direkten Kontrolle durch das lokale Environment. Daher kann es
– 92 –
vorkommen, daß zwar ein Proxy verfügbar ist, dessen Verbindung zur repräsentierten
Entität aber unterbrochen ist.
Element Summary
Proxy
Hierarchical Name
Physical.Entity.Item.Proxy
Extends
Item
Definition
An Item that represents an Entity external to its own Environment
Relationships
Represents an Entity
Event Classes
Connected, Disconnected
Examples
Neighboring environment, socket, database interface, migrated agent
d.
Type
Ein Type ist eine Entity, das einen Agenten- oder Entitytyp darstellt. Als Entity ist er
wahrnehmbar; er ist also die konkrete Repräsentation eines Typs oder einer Klasse im
Environment. In diesem Sinne ist er eng mit dem Konzept der Proprietary Resource
verbunden, da bei Verwendung eines Typsystems die Typdefinition meist zur Ausführung der Instanzen benötigt wird.
Der Programmcode bzw. die Klassendefinition eines Softwareagenten in Form einer
ausführbaren Datei, einer Bibliothek, einem Skript oder einer Java .class Datei definiert
seinen Typ. Der Agent kann ohne diese Spezifikation nicht ausgeführt werden.
Wenn ein Typsystem vorhanden ist, kann die Verwaltung der Typen durch einen
entsprechenden Service beschrieben werden. Die Instanzbeziehung zwischen Entity und
Type ist einfach nur eine spezielle Beziehung zwischen zwei Entities. In ähnlicher
Weise können Types auch voneinander erben oder abstrakte Spezifikationen implementieren.
Element Summary
Type
Hierarchical Name
Physical.Entity.Item.Type
Extends
Item
Definition
An Item that defines an Agent- or Entity-type
Attributes
Specification
Relationships
Instantiated by Agent, respectively Entity
May extend or implement other Types
Event Classes
Instantiated
Examples
Java .class or .jar file, executable, script
– 93 –
iii.
Facility
Eine Facility ist ein Entity, das einen Service64 implementiert. Dienste sind abstrakt;
damit sie von Agenten wahrgenommen und benutzt werden können, müssen sie eine
Schnittstelle in Form einer Entity anbieten. Eine Facility kann dabei selbst ein Agent
oder ein passives Item sein.
Der Postzustellungsdienst wird in der realen Welt durch Briefkästen und Postzusteller
implementiert. In einem Softwaresystem existiert in der Regel ein Verzeichnisdienst,
der entweder in Form einer Liste, in der Agenten nachschlagen können, oder eines
Agenten, an den die anderen Agenten Anfragen schicken können, implementiert ist.
Wie Resources können Facilities verfügbar, angefordert oder nicht verfügbar sein.
Element Summary
Facility
Hierarchical Name
Physical.Entity.Facility
Extends
Entity
Definition
An Entity that implements a Service
Attributes
Profile
Relationships
Implements Service
Event Classes
Available, Requested, Unavailable
Examples
Directory service, yellow pages, message sink, broker, scheduler
iv.
Percept
Ein Percept ist ein Entity, das im Zuge seiner Wahrnehmung durch einen Sensor65 erst
erzeugt wird. Es wird nur benötigt, wenn bei physikalischen Agenten oder speziellen
Klassen von Softwareagenten die Wahrnehmungsprozesse eines Agenten explizit erfaßt
werden sollen. Ein Percept beschreibt einen konkreten, abgegrenzten Eindruck vom
Zustand des Environments, der dem Agenten von seinem Sensor geliefert wird.
Tastet ein Roboter seine Umgebung in regelmäßigen Abständen mit Sonar auf Hindernisse ab, kann das Ergebnis jeder Messung (Rohdaten oder schon vorstrukturiert) als
64
65
Siehe im Detail Abschnitt 3.3.1.4, S. 108.
Siehe Sensor, S. 95.
– 94 –
Percept verstanden werden. Für rein virtuelle Agenten kann dies ebenfalls relevant sein,
wenn sie, wie etwa der Office Agent, versuchen, das Verhalten des Benutzers zu
beobachten.
Element Summary
Percept
Hierarchical Name
Physical.Entity.Percept
Extends
Entity
Definition
A distinct signal emitted by a Sensor of an Agent
Attributes
Pattern
Relationships
Perceived by Sensor
Event Classes
Emitted
Examples
Light or sound pattern described by a sensor, observation about user behavior
B.
Zusammenfassung Strukturaspekt
Die folgende Grafik faßt nochmals die wichtigsten unter den vorgestellten Beziehungen
zwischen den verschiedenen Klassen von Entities zusammen. Die Spezialisierungsbeziehungen wurden hier aus Gründen der Übersichtlichkeit unterdrückt.
Proxy
Agent Shell
Agent Core
(0,1)
(1,1)
(1,1)
represents
consists of
consists of
emits
(1,1)
Message
Environment
Structure
(0,n)
(0,n)
(1,1)
(0,n)
(0,n)
exists in
(1,1)
Entity
d,t
requires
(1,1)
(0,n)
(0,n)
(0,n)
(0,n)
perceives
(1,1)
(0,n)
Structure
Type
Abbildung 3.9
Percept
Item
uses
(0,n)
Resource
Agent
(0,n)
instantiates
(0,n)
Facility
(1,n)
(0,n)
(0,n)
Service
Elementbeziehungen innerhalb des Entity Model
(0,n)
implements
– 95 –
C.
Sensor
Ein Sensor erlaubt einem Agent, Entities in seinem Environment wahrzunehmen. Der
Sensor verwandelt externe Signale in eine agenteninterne Repräsentation der Umwelt.
‚Repräsentation’ setzt in diesem Zusammenhang weder eine Abbildung durch Symbole
noch ein ‚Gedächtnis’ mit einem konsolidierten Modell der Welt voraus.
Ein Sensor kann sowohl aktiv als auch passiv sein. Passive Sensors werden aus dem
Environment entweder mit einem stetigen Datenstrom versorgt oder in Reaktion auf ein
Ereignis angestoßen. Active Sensors fragen entweder kontinuierlich oder in Intervallen
ihr Environment aktiv ab. Diese Unterscheidung zwischen pull- und push-Prinzip wird
lediglich aus praktischen Erwägungen vorgeschlagen, um die Systembeschreibung
intuitiver zu machen. Theoretisch läßt sich jeder aktive Sensor als eine Kombination aus
einem Effektor und einem passiven Sensor beschreiben.
Ein Sonar ist ein in kurzen Intervallen arbeitender aktiver Sensor, eine Fotozelle ein
kontinuierlich arbeitender passiver. Eine Methode, mit der der Nachrichtentransportdienst eine Nachricht an einen Agenten übergeben kann, ist ein passiver Sensor, eine
Methode zum Abfragen einer Datenbank ein aktiver.
Sensors sind notwendigerweise spezialisiert und nehmen nur bestimmte Attribute einer
wohldefinierten Menge von Entities wahr. Daher gilt für physikalische wie softwarebasierte Agenten gleichermaßen, daß sie sich in einem neuen Environment nur zurechtfinden können, wenn ihre Sensors auf die vorhandenen Entities abgestimmt sind.
In einem völlig dunklen Labyrinth kann sich ein Agent nur mit Hilfe eines ‚passenden’
Sensors wie etwa Sonar orientieren, eine Fotozelle ist dagegen nutzlos. Eine SQLDatenbankabfrage setzt eine bestimmte Tabellenstruktur voraus.
Besonders Kommunikation zwischen Agenten oder Agenten und dem Environment
erfordert, daß mindestens eine der beteiligten Seiten a priori Wissen über die Schnittstellen des anderen besitzt. Daher ist es für offene Systeme wichtig, in diesem Bereich
eine wohldokumentierte Infrastruktur anzubieten.
– 96 –
Der MASIF-Standard beschreibt mit dem MAFFinder eine Entity, von der sich
Informationen über andere Agenten aktiv erfragen lassen.
Passive Sensors arbeiten synchron, aktive Sensors können dagegen auch asynchron
arbeiten, wie sich aus der Sicht als Paar aus einem Effector und einem passiven Sensor
direkt ableitet. Wichtigstes mit Sensors assoziiertes Ereignis ist der Empfang eines
Reizes.
Ein Sensor definiert einen Context66, die Menge der Entities, die er gegenwärtig
wahrnehmen kann. Wird die Welt aus der Agentenperspektive beschrieben, erzeugen
Sensors durch die Wahrnehmung Percepts.
Das Modell definiert zwei Unterklassen von Sensoren – im Wesentlichen, um zwischen
dem in Softwaresystemen besonders wichtigen Nachrichtenaustausch und anderer
Wahrnehmung unterscheiden zu können. ‚Kommunikationssensoren’ zum Empfang von
Nachrichten heißen Auditive Sensors, ‚Allzwecksensoren’ zur Formung eines Bildes
vom umgebenden Environment heißen Visual Sensors. Die Unterscheidung ist
wiederum vor allem eine Argumentationshilfe, da eine theoretisch scharfe Trennung
nicht generell möglich ist.
Element Summary
Sensor
Hierarchical Name
Physical.Sensor
Definition
A device allowing an Agent to sense Entities in its Environment
Attributes
Identity, Scope
Relationships
Belongs to Agent
Defines Context
Perceives Entities
May generate Percepts
Event Classes
Stimulated, Context changed
Examples
Sonar, inductive contacts, receive(message), agents.list(), ls command
66
Siehe Context, S. 99.
– 97 –
i.
Visual Sensor
Die Sensorenklasse der Visual Sensors faßt alle Sensors zusammen, mit denen auch
passive Entities ‚unmittelbar’ wahrgenommen werden können. Der Name soll nicht
suggerieren, daß die Wahrnehmung visuell sein muß – sie kann auch akustisch, taktil
oder rein virtuell sein. Er soll nur vermitteln, daß der Agent direkt einen Eindruck von
seiner Umwelt gewinnen kann.
Ein Sonar, ein Funktionsaufruf, der eine Liste aller im System befindlichen Agenten
zurückgibt oder der UNIX-Befehl ls im Kontext des Dateisystems sind Visual Sensors.
Element Summary
Visual Sensor
Hierarchical Name
Physical.Sensor.Visual
Extends
Sensor
Definition
A Sensor that allows the direct observation of the Environment
Examples
Sonar, inductive contacts, agents.list(), ls command
ii.
Auditive Sensor
Die Sensorklasse der Auditive Sensors umfaßt die Sensors, die Kommunikation
empfangen können, die aktiv von anderen Agenten ausgesendet wurde. Entities, die zur
Kommunikation dienen, sind per Definition Messages.
Die receive(Message) Methode vieler Architekturen ist der typische Auditive
Sensor. Die Subroutine, mit der ein Agent auf einem elektronischen Marktplatz
regelmäßig seine Postfächer auf Angebote überprüft, könnte als aktiver Auditive Sensor
gesehen werden. In einem Tuple Space [Silva 1999] ist ein Auditive Sensor nur eine
spezielle Interpretation eines Visual Sensor.
Element Summary
Auditive Sensor
Hierarchical Name
Physical.Sensor.Auditive
Extends
Sensor
Definition
A Sensor that receives communications
Relationships
Receives Messages
Event Classes
Received Message
Examples
receive(message)
– 98 –
D.
Effector
Agents besitzen Effectors, um Entities in ihrem Environment zu manipulieren. Ihre
Anwendung wird exklusiv vom AgentCore gesteuert, der sie bei Bedarf unter Bereitstellung der nötigen Parameter aktiviert. Wie die Sensors sind auch Effectors auf
bestimmte Aktionen und Entities spezialisiert. Dabei kann ein einzelner Effector eine
einfache, allgemein gehaltene oder eine komplexe, sehr spezialisierte Tätigkeit beschreiben.
Physikalische Effectors sind etwa Motoren. In Softwaresystemen lassen sich Effectors
im Grunde immer auf den Aufruf von Funktionen oder Programmen zurückführen,
können dabei aber komplexere Tätigkeiten wie das Erstellen und Versenden einer
XML-Nachricht, die Migration in ein anderes Environment, das Anlegen einer Datei
oder das Schreiben in eine Datenbank umfassen.
Jeder Effector definiert ebenfalls einen Context67, die Menge der Entities, die er
gegenwärtig beeinflussen kann. Seine Anwendung kann synchron oder asynchron sein,
dementsprechend sind die mit einem Effector assoziierten Ereignisse der Beginn und
der Abschluß seiner Anwendung.
Das Modell definiert wiederum zwei Unterklassen von Effector: Operative Effectors,
die Entities direkt manipulieren, und Verbal Effectors, die Messages erzeugen und
dadurch indirekt auf andere Agents einwirken.
Element Summary
Effector
Hierarchical Name
Physical.Effector
Definition
A device allowing an Agent to manipulate Entities in its Environment
Attributes
Identity, Scope
Relationships
Belongs to Agent
Defines Context
Manipulates Entities
Event Classes
Invoked, Applied
Examples
Motors, robotic hand, non-constant function calls, SQL UPDATE, rm
67
Siehe Context, S. 99.
– 99 –
i.
Operative Effector
Ein Operative Effector manipuliert den Zustand einer oder mehrerer Entities des
Systems direkt. Alle im vorherigen Abschnitt beschriebenen Effectors sind auch
Operative Effectors.
Element Summary
Operative Effector
Hierarchical Name
Physical.Effector.Operative
Extends
Effector
Definition
An Effector that directly operates on Entities
Examples
Motors, robotic hand, non-constant function calls, SQL UPDATE, rm
ii.
Verbal Effector
Ein Verbal Effector dient zum Absetzen von Nachrichten. Da Messages Entities sind,
kann ein Verbal Effector in der Regel als ein Sonderfall eines Operative Effector
interpretiert werden. Der Begriff Verbal Effector soll nicht Sprechakte (Speech Acts)
implizieren – Messages können beliebig primitiv sein.
Auf einer typischen Agentenplattform erstellt ein Verbal Effector eine neue Nachricht
und übergibt sie an das Nachrichtentransportsystem.
Element Summary
Verbal Effector
Hierarchical Name
Physical.Effector.Verbal
Extends
Effector
Definition
An Effector that emits Messages
Relationships
Emits Message
Examples
queue(Message)
E.
Context
Context ist ein Begriff, der für die Beschreibung von Interaktionen innerhalb des
Modells von zentraler Bedeutung ist. Der Context eines Agent besteht aus der Menge
aller Entities, die der Agent entweder wahrnehmen oder manipulieren kann. Der
Context zerfällt in zwei natürliche, nicht unbedingt deckungsgleiche Teile: den
Perceptual Context, der aus den von den Sensoren wahrnehmbaren Entities besteht,
und den Effective Context, der die manipulierbaren Entities enthält. Die beiden
Teilkontexte lassen sich wiederum in problembezogene Teilkontexte zerlegen, bis auf
der untersten Ebene die Contexts jeweils für einen Sensor bzw. Effector definiert sind.
– 100 –
Ein gutes Beispiel für ein System von Contexts sind die Zugriffsrechte, die menschliche
oder virtuelle Benutzer auf ein UNIX-Dateisystem besitzen. Abgestuft nach Benutzerkennung und Gruppenzugehörigkeit kann festgelegt werden, welche Dateien verschiedene Benutzer auflisten und lesen (Perceptual Context) bzw. schreiben und löschen
(Effective Context) dürfen.
Die Modellierung ist wiederum durch die agentenzentrierte Sichtweise des Modells
motiviert: Der Agent ist in beiden Fällen Subjekt. Die umgekehrte Perspektive, die
Betrachtung des passiven Kontextes, in dem der Agent Objekt ist, also von anderen
Agenten gesehen und geändert werden kann, ist meist von geringerer praktischer
Bedeutung. Sie wird daher hier nicht näher modelliert, zumal sie sich im Bedarfsfall
indirekt aus den Contexts der anderen Agents ableiten läßt.
In der simulierten Welt von Quake ist der Perceptual Context eines Avatars seine
Sichtweite, sein Effective Context die Reichweite seiner Waffen. Ob der Avatar von
anderen Agenten gesehen wird und vor allem mit deren Waffen erreicht werden kann,
ist eine Frage von durchaus vitalem Interesse. Die zu ihrer objektiven Beantwortung
benötigten Informationen stehen dem Agenten im Rahmen des Spiels nicht zur Verfügung, so daß sich ein entsprechender passiver Kontext zwar definieren, aber nicht
sinnvoll in der Implementierung umsetzen ließe.
Der Context erfüllt im Modell zwei Aufgaben. Zum einen dient er wie in den vorgestellten Beispielen der Beschreibung der Fähigkeiten und Zugriffsrechte der einzelnen
Sensors und Effectors. Auf diese Weise ist er eine Argumentationshilfe bei der
Betrachtung der möglicher Interaktionen im Modell.
Zum anderen ist er der konkrete Ausdruck der logischen Ordnung der Agents im
Environment. Aus dieser Perspektive wird ein Agent nicht durch eine absolute Positionsangabe, sondern seine relative Stellung zu anderen Entities lokalisiert.
Dies ist eine Verallgemeinerung des in anderen Modellen verwandten Begriffs Place. In
einem selbstorganisierenden Netzwerk wird die Position eines Agenten nicht durch eine
feste Adresse, sondern durch seine Verknüpfungen zu benachbarten Agenten definiert.
– 101 –
Die Menge der zu einem Context gehörenden Entities wird entweder intern durch den
Agenten selbst bestimmt, etwa durch die Agenten, die der Agent ’kennt’, oder exogen
durch das Environment vorgegeben, wobei sowohl die rein technischen als auch
anwendungsspezifischen Gegebenheiten eine Rolle spielen können. Rechte und
Verbote, die auf der konzeptuellen Ebene definiert werden, schlagen sich üblicherweise
direkt in einer Änderung des Context nieder.
Anschaulich, wenn auch nicht in dieser Form agentenspezifisch, wird das Prinzip des
selbstverwalteten Context durch Programme zum Instant Messaging illustriert. Nur bei
Personen, die der Benutzer zunächst seiner Freundesliste hinzugefügt hat, ist die
Anwesenheit am Rechner beobachtbar.
Element Summary
Context
Hierarchical Name
Physical.Context
Definition
A set of Entites that can either be sensed or manipulated by an Agent
Relationships
Associated with Agent
May be composed of other Contexts
Event Classes
Changed
Examples
Agents on the same platform, accessible database records
i.
Perceptual Context
Ein atomarer Perceptual Context umfaßt die Entities, die ein Agent mit einem konkreten Sensor wahrnehmen kann. Ein zusammengesetzter Perceptual Context ist die
Vereinigungsmenge verschiedener Teilkontexte. Der gesamte Perceptual Context eines
Agent ist die Summe der Kontexte seiner einzelnen Sensors.
Element Summary
Perceptual Context
Hierarchical Name
Physical.Context.Perceptual
Extends
Context
Definition
The set of Entities that can be sensed with one of an Agent’s Sensors
Relationships
Defined by Sensor
Examples
Visual range, accessible database records, Instant Messaging friends list
ii.
Effective Context
Der Effective Context ist das operative Gegenstück zum Perceptual Context. Für jeden
Effector beschreibt ein einfacher Effective Context, welche Entities ein Agent damit
– 102 –
manipulieren kann. Der Gesamtkontext ist wiederum sie Vereinigungsmenge aller
Einzelkontexte.
Element Summary
Effective Context
Hierarchical Name
Physical.Context.Effective
Extends
Context
Definition
The set of Entities that can be changed with one of an Agent’s Effectors
Relationships
Defined by Effector
Examples
Agents on same node, UNIX: files of agent’s user, Quake: weapons’ range
F.
Zusammenfassung Interaktionsaspekt
Die nachfolgende Grafik gibt nochmals einen Überblick über die Beziehungen, die bei
der Interaktion zwischen Agent, seinen Sensors und Effectors und den Entities des
Environments bestehen.
Verrbal Effector
(1,1)
Effector
(1,1)
emits
n,t
Operative Effector
possesses
(0,n)
(0,n)
manipulates
defines
aggregation
(1,1)
(1,1)
(0,1)
Effective Context
Message
(0,n)
Context
Agent
d,t
(0,n)
(0,n)
(0,n)
(0,n)
(0,n)
Perceptual Context
(1,n)
contains
(1,1)
possesses
(1,1)
(0,n)
defines
Visual Sensor
(1,1)
Sensor
Auditive Sensor
(1,1)
(0,n)
perceives
n,t
(0,n)
Percept
Entity
(0,n)
generates
Abbildung 3.10 Interaktion innerhalb des Entity Model
receives
– 103 –
II.
Modellierung
Im Entity Model wird der Großteil der späteren Implementierung eines Systems
dokumentiert. Je stärker die Interaktion zwischen Agenten im Vordergrund steht, desto
wichtiger ist die Rolle, die das Teilmodell spielt. Für realistische Systeme kann das
Teilmodell leicht sehr komplex werden, so daß eine geeignet strukturierte Darstellungsform unverzichtbar ist.
Auf einem elektronischen Marktplatz können Unternehmen Agenten betreiben, die
miteinander Geschäfte aushandeln und abschließen. Die Agenten werden in einem
zentralen Verzeichnis registriert und durch digitale Zertifikaten authentifiziert. Im
Folgenden ist beispielhaft ein Ausschnitt eines entsprechenden Entity Model dargestellt,
der sich nur mit dem Aspekt des Austausches von Angeboten befaßt.
Agent Directory
Address
Digital Certificate
Agent List
Agent Profile
Identity
Company
Seller Agent
Identity
Buyer Agent
Digital Certificate
Identity
Address
Address
Address
Company
Digital Certificate
Authentification
Query Agent Directory
Read Agent Profile
Send Message
Company
Proposal
Digital Certificate
Sender
Authentification
Recipient
Query Agent Directory
Product
Read Agent Profile
Quantity
Receive Message
Price
Receive Message
Send Message
Reaction
Sender
Recipient
Accept / Decline
Abbildung 3.11
Ausschnitt eines Entity Model für einen Marktplatz
– 104 –
Die verwendete grafische Darstellung ist als ein modifiziertes Klassen- oder Objektdiagramm zu verstehen. Die verschiedenen Entities tragen durch graue Rechtecke gekennzeichnete Attribute. Sensoren (nach innen zeigende Dreiecke) und Effektoren (nach
außen zeigende Dreiecke) sind durch Pfeile mit Attributen und Entities verbunden,
wodurch ihr Context bezeichnet wird. Agents sind schwarz, Items, Visual Sensors und
Operative Effectors blaugrün und Messages, Auditive Sensors und Verbal Effectors
lindgrün.
Die Agenten können das Profil anderer Agenten im Agentenverzeichnis abfragen und
daraus Informationen über ihre Adresse und ihr digitales Zertifikat gewinnen. Angebote
und Reaktionen auf Angebote werden als Nachrichten beschrieben.
Für Agenten mit einem einfachen Umweltmodell, etwa Chatagenten, die intern sehr
aufwendig gestaltet sein können, nach außen aber einfach nur Text einlesen und
ausgeben, ist die Beschreibung als Automat mit Ein- und Ausgabebeziehungen unmittelbar anwendbar.
Komplexere (Software-)Multiagentensysteme werden dagegen in der Regel objektorientiert modelliert werden. Passive Sensors stellen dabei kein Problem dar, da sie den aus
ereignisgesteuerten bzw. nachrichtenorientierten Systemen bekannten Callback- bzw.
Empfangsmethoden entsprechen. Active Sensors und Effectors finden hier ihre
Entsprechung allerdings im Allgemeinen in get() bzw. set()-Methoden a nd e r e r
Objekte. Daher erfordert die Umsetzung in ein objektorientiertes Diagramm einen
gewissen Perspektivwechsel: Die Effectors eines Agenten sind die Menge eigener und
fremder Methoden, die er aufruft bzw. aufrufen kann.
Das Entity Model kann in diesem Sinne problemlos durch UML Klassen- und Kollaborationsdiagramme beschrieben werden, auch wenn Sensoren und Effektoren hier nur
noch implizit abgebildet sind.
Das obige Beispiel wird hier objektorientiert umgesetzt. Das nachstehende UMLKlassendiagramm beschreibt die oben spezifizierte statische Struktur.
– 105 –
DirectoryService
-List<Profile>
+query() : const List<Profile>
+query(String) : const Profile
1...1
+receive(const &Proposal)
+accepted(&Proposal)
+declined(&Proposal)
Abbildung 3.12
-identifier : String
-company : String
-certificate : String
-reference : &Agent
+getIdentifier() : const String
+getCompany() : const String
+getCerificate : const String
+getReference() : &Agent
Agent
-identifier : String
-company : String
-certificate : String
-directory : &DirectoryService
Profile
0…*
0…*
Proposal
-productID : String
-quantity : Integer
-price : Integer
Klassendiagramm für den obigen Ausschnitt
Der Effector zum Abfragen des Verzeichnisses und der Sensor zum Lesen der Profildaten sind hier Methoden des DirectoryService und des Profile. Die Kommunikation
wurde bewußt nicht durch den Austausch von Nachrichtenobjekten umgesetzt, sondern
implizit auf der Ebene von Methodenaufrufen: Der Anbieter übergibt ein Proposal an
die receive Methode des Kunden, dieser gibt es entweder an die accepted oder
declined Methode des Anbieters zurück. Dementsprechend wird auch das Attribut
Address nicht explizit abgebildet, sondern entspricht hier einer Referenz auf die
Speicheradresse eines Agentenobjekts. Der Austauschprozeß könnte in einem (hier
nicht angegebenen) Kollaborationsdiagramm genauer spezifiziert werden.
Im dargestellten Modell sind bislang Agenten die einzigen aktiven Elemente, und die
Entities sind rein passiv, haben also auch keine internen Prozesse, die durch Effectors
oder Sensors angestoßen werden. Diese Limitation wird durch das nachfolgende
Process Model aufgehoben.
3.3.1.3 Process Model
Die Umwelt eines Agenten ist in der Regel nicht statisch. Sie wird vom Agenten selbst
und in Multiagentensystemen auch durch andere Agenten verändert. Zur vollständigen
Beschreibung eines Systems ist eine Beschränkung auf Agenten als einzige aktive
– 106 –
Entitäten meist unzureichend, da dies zum einen auf eine exzessive Anzahl von Agenten
führen kann und zudem manche Prozesse von ihrer Natur her unpersönlich sind.
In der irdischen physikalischen Welt sind alle Objekte der Schwerkraft unterworfen, die
in Richtung des Erdmittelpunktes auf sie einwirkt. In einem rein agentenbasierten
Modell wäre entweder die Erde ein Agent, der auf alle Entities mit einem Effector
einwirkt, oder – gänzlich unintuitiv – jedes Objekt selbst ein Agent, der einen Effector
auf sich selbst anwendet. Beide Sichtweisen sind für eine Modellierung nicht praktikabel.
Daher können im Rahmen des Environment aktive Processes definiert werden, die
unabhängig von einem Agenten auf die Entities einwirken.
Dabei sind verschiedene Klassen von Prozessen interessant.68 Von allgemeiner Bedeutung sind die ‚Naturgesetze’ (Natural Law), denen die Entities im Rahmen des
Environment unterworfen sind. Das Environment kann in diesem Zusammenhang
selbst durch einen aktiven Prozeß repräsentiert werden, der diese Gesetze umsetzt.
In einem Simulationsmodell kann etwa ein Basisprozeß reihum auf die Entities
einzuwirken, etwa um Zeit oder Schwerkraft zu simulieren. Ein Umweltprozeß kann
aber auch abstrakter der Scheduler eines Multiagentensystems sein, der Agenten
Rechenzeit zuteilt.
Wie die Analogie zur physikalischen Welt nahelegt, lassen sich mögliche Ereignisse
und kausale Beziehungen prinzipiell auf die Naturgesetze zurückführen, was jedoch für
eine konkrete Modellierung meist zu abstrakt erscheint. Daher lassen sich auf Basis der
Naturgesetze anwendungsspezifische Korollare, die Enforcement Processes, formulieren, mit denen das Environment die Einhaltung grundlegender Regeln überwacht oder
etwa die Änderungen der Contexts der Agenten berechnet.
68
Abbildung 3.13, S. 110, bietet einen Überblick über die Elemente des Process Model.
– 107 –
In einem Modell zur Ressourcenverwaltung werden mobile Agents mit Credits
ausgestattet, mit denen sie auf Servern Rechenzeit kaufen können. Sobald ein Agent
keine Credits mehr besitzt, wird er durch den Server terminiert.
Mit der gleichen Begründung bietet es sich an, die Reaktionen von Entities auf Effektoren im Rahmen der Umweltprozesse anwendungsbezogen zu beschreiben.
Die Funktionsweise einer Kaffeemaschine läßt sich vollständig durch die Gesetze der
Physik, Chemie und Elektrotechnik erklären. Trotzdem ist es für eine Beschreibung der
Interaktion mit einer Kaffeemaschine sinnvoller, den Prozeß des Kaffeekochens auf
einer höheren Abstraktionsebene zu beschreiben.
Daher können Entities mit Mechanisms, letztlich Beschreibungen ihrer Reaktionsmuster und relevanten internen Prozesse, assoziiert werden. Da die Umwelt selbst ein
aktiver Prozeß ist, können sich somit von den Handlungen eines Agenten ausgelöst oder
spontan als Folge der Naturgesetze mittelbar nichtdeterministische Auswirkungen auf
andere Entities und den Agenten selbst ergeben. Auf diese Weise wird vermieden, daß
zwangsläufig jede in irgendeiner Form ‚agierende’ Entity gleich ein Agent sein m u ß .
Die Frage nach ihrem Agentenstatus wird somit von einer rein technischen auf eine
inhaltliche Ebene erhoben und bleibt dem Ermessen des Entwicklers überlassen.
Zusammen lassen die verschiedenen Prozesse eine Klassifikation des Environment
bezüglich Determinismus, Flüchtigkeit, Zeitbegriff o.ä. im Sinne der Überlegungen von
Odell und Parunak69 zu.
Daneben stellt sich die Frage nach externen Einflüssen, die auf ein Environment
einwirken. Prinzipiell lassen sich externe Akteure innerhalb des Environment durch
einen Agenten beschreiben, dessen AgentCore außerhalb des Systems liegt, sofern die
Logik des Modells dies zuläßt. Jedoch ist dies oft inhaltlich nicht gerechtfertigt, so daß
es in vielen Fällen näher liegt, die externen Einwirkungen durch einen nichtdeterministischen Umweltprozeß, einen Autonomous Process, zu beschreiben.
69
Siehe Abschnitt 2.4.1, S. 37.
– 108 –
In einem Spiel wie Quake ist der Spieler ein externer Einfluß, der durch die Steuerungsbefehle an seinen Avatar die Spielwelt verändert. Aus Sicht anderer Agenten ist
die Spielfigur jedoch nicht von durch die künstliche Intelligenz gesteuerte Figuren
(NPC) zu unterscheiden. Der Avatar ist als ganz normale Agent Shell beobachtbar,
lediglich sein Agent Core liegt außerhalb des Systems.
In anderen Fällen, wenn etwa ein Betriebssystemsagent Mausbewegungen oder
Änderungen am Dateisystem überwacht70 oder ein Informationsfilter auf neue Nachrichten in einer Nachrichtenquelle reagiert, liegt es näher, die Änderungen durch nichtdeterministische Zustandsübergänge zu beschreiben.
Nachfolgend werden die verschiedenen Prozeßtypen nochmals im Detail dargestellt.
I.
Elemente
A.
Process
Ein Process ist ganz allgemein eine Folge von Änderungen an Entities des Environment, die nicht direkt von einem Agenten, sondern durch das Environment verursacht
wird. Ein Process kann sich aus anderen Processes zusammensetzen. Relevante
Ereignisse sind sein Beginn und sein eventuelles Ende.
Element Summary
Process
Hierarchical Name
Physical.Process
Definition
An impersonal process associated with the Environment
Relationships
Affects Entities
Event Classes
Initiated, Terminated
Examples
Gravity, time, causality/consequences, entity reactions, external influences
i.
Natural Law
Ein Natural Law ist ein Process, der konstant und in den meisten Fällen deterministisch
auf die Entities eines Environments einwirkt und dadurch dessen Eigendynamik
beschreibt.
70
Siehe etwa das Beispiel aus Abschnitt 2.5.3, S. 54.
– 109 –
Element Summary
Natural Law
Hierarchical Name
Physical.Process.Law
Extends
Process
Definition
Describes dynamic changes all Entities are subjected to
Examples
Gravity, time, causality/consequences
a.
Enforcement Process
Ein Enforcement Process ist eine erweiterte Form des Natural Law. Er setzt ebenfalls
nur ‚physikalische’ Regeln (keine ‚sozialen’) um, hat aber eine vergleichsweise
komplexere Semantik. Durch Enforcement Processes kann das Environment seine
Agenten verwalten und die Einhaltung von Quoten und Limits überwachen.
Element Summary
Enforcement Process
Hierarchical Name
Physical.Process.Law.Enforcement
Extends
Natural Law
Definition
Describes management or constraint enforcement by the Environment
Examples
Monitor limits, quotas and constraints, terminate avatar with 0% health
b.
Mechanism
Ein Mechanism ist ein Process, der interne Prozesse von Entities und ihre Reaktionen
auf Effektoranwendungen beschreibt. Ein Mechanism wird als Erweiterung des
Begriffs Natural Law gesehen, da er nur rein mechanistische Prozesse beschreibt, die
sich im Grunde auf die physikalischen oder technischen Grundregeln zurückführen
lassen. Mechanisms können bedingte Verzweigungen und Nichtdeterminismus
enthalten. Es ist letztendlich wiederum Ermessensfrage, wann die Prozesse einer Entity
so komplex werden, daß eine Beschreibung als Agent zweckmäßiger erscheint.
Element Summary
Mechanism
Hierarchical Name
Physical.Process.Law.Mechanism
Extends
Natural Law
Definition
Describes the dynamics of an Entity
Relationships
Associated with an Entity
Examples
Entity reactions, internal processes
ii.
Autonomous Process
Ein Autonomous Process ist ein Process, der nichtdeterministische Änderungen des
Environment durch externe Einflüsse beschreibt.
– 110 –
Element Summary
Autonomous Process
Hierarchical Name
Physical.Process.Autonomous
Extends
Process
Definition
Externally caused non-deterministic changes to the Environment
Examples
External influences, user input, technical error conditions
II.
Modellierung
Das Process Model modelliert zum einen die Gesetze und die Eigendynamik des
Systems, zum anderen das Verhalten der Entities.
Enforcement
Process
Composition
Natural Law
d,p
(0,n)
(0,n)
Process
d,t
Mechanism
Autonomous
Process
(1,1)
describes
(0,n)
Entity
Abbildung 3.13 Elementbeziehungen innerhalb des Process Model
Der erste Aspekt ist in physikalischen Systemen nur von deskriptiver Bedeutung, da die
Rahmenbedingungen in diesem Falle schon gegeben sind. In Softwaresystemen kann er
durch die Modellierung des Environment als eigenständiger Prozeß beschrieben
werden, der etwa regelmäßig bestimmte Überprüfungen vornimmt oder Methoden
aufruft oder nichtdeterministische Änderungen an Entities vornimmt.
Die zweite Aufgabe kann durch bekannte objektorientierte Techniken wie UML
Kollaborations-, Aktivitäten- oder Zustandsdiagramme oder verhaltensbeschreibende
Netze bewältigt werden.
3.3.1.4 Service Model
Die Anwesenheit des Service Model in der Physical Layer bedarf insoweit einer
Rechtfertigung, als dieses Teilmodell rein abstrakt ist. Ein Service muß durch eine
Facility oder einen Enforcement Process implementiert sein, um von Agenten wahrge-
– 111 –
nommen oder genutzt zu werden, ist also ein Konzept zu deren Beschreibung. Dennoch
erscheint es unnatürlich, die Services in die Conceptual Layer zu verlagern, da sie nicht
anwendungsbezogen sind, sondern eine implementierungsnahe Spezifikation der
vorhandenen Infrastruktur liefern. Services beschäftigen sich mit Ressourcenverwaltung, Nachrichtenübertragung, Agentenregistraturen oder Migration. Analog der
Hardwareabstraktionsschicht eines Betriebssystems bieten sie eine Abstraktion von der
konkreten Implementierung einer bestimmten Agentenplattform. Viele operativ
relevante Unterscheidungsmerkmale zwischen Agentensystemen können auf dieser
Ebene übersichtlich beschrieben werden.
Aglets bieten einen hierarchischen Adreßraum, asynchrone Kommunikation und
zustandslose Migration unter Mitnahme von Daten. Telescript besitzt einen linearen
Adreßraum und unterstützt nur synchrone Kommunikation, dafür aber zustandsbehaftete Migration.
Wie die in diesem Beispiel gewählten Kriterien bereits suggerieren, greift das Service
Model die Idee des Referenzmodells von Silva et al.71 auf. Die Infrastruktur, die von
einem Environment bereitgestellt wird, läßt sich anhand verschiedener, teilweise
orthogonaler Dienstkategorien beschreiben.
Im Folgenden werden konkrete Kategorien vorgeschlagen, in denen jeweils einige
Dienste beispielhaft aufgezählt werden. Aufgrund der großen Vielfalt der existierenden
Architekturen und der vergleichsweise spezifischen Natur der einzelnen Services kann
das Metamodell keine erschöpfende Aufzählung aller relevanten Dienste leisten. Selbst
eine vollständige Auflistung wäre insoweit problematisch, als daß die Abgrenzung bzw.
Zusammenfassung einzelner Leistungen zu Diensten niemals allen Architekturen
gerecht werden könnte.
Das Metamodell ist hier eher als Konzept einer Bibliothek zu verstehen: In den
verschiedenen Kategorien können Entwurfsmuster zur Implementation einzelner
Dienste definiert werden. Die Liste der Dienstbeschreibungen ist nicht statisch, sondern
71
Vgl. Abschnitt 2.4.1, S. 35.
– 112 –
kann, wie bei objektorientierten Entwurfsmustern, durch den Vorschlag zweckmäßig
erscheinender neuer Muster erweitert werden.
I.
Elemente
A.
Service
Ein Service ist die abstrakte Beschreibung eines nicht anwendungsspezifischen
Dienstes, der den Agents vom Environment angeboten wird. Ein Service kann auf
anderen Services aufsetzen.
Construction
Generation
n,p
Type
Management
Execution
Engine
Identity
Generation
Ressource
Allocation
Execution
Discovery
n,p
n,p
Agent Directory
Event
Propagation
Service Directory
Exception
Handling
Location
Management
Lifecyle
Managment
Management
n,p
Composition
Encoding
(0,n)
Service
(0,n)
Observation
Open Channels
n,p
Communication
n,p
Message
Transport
Exception
Handling
Address
Resolution
Serialization
Persistence
n,p
Agent
Transport
Migration
n,p
Reconstruction
Resource
Management
Authentication
Exception
Handling
Security
Interface
Access Control
n,p
n,p
User
Interface
Integrity
System
Interface
Privacy
Conversion
Wrapping
Abbildung 3.14 Klassifikationsschema für Services
– 113 –
Für einen Dienst kann definiert werden, welche Agenten ihn nutzen dürfen, welche
Entities von ihm betroffen sind, welche Vorbedingungen zu seiner Nutzung erfüllt sein
müssen und welche Garantien der Dienst über seine Ausführung macht.
Element Summary
Service
Hierarchical Name
Physical.Service
Definition
The abstract definition of a service provided by the Environment
Attributes
Identifier, Scope, Users, Preconditions, Postconditions
Relationships
Implemented by Facility or Enforcement Process
Event Classes
(Abstract)
Examples
Directory, messaging, addressing, security, scheduling, persistence
Die einzelnen Kategorien und Unterkategorien des Schemas werden im Weiteren kurz
beschrieben.
i.
Generation
Die Kategorie Generation beschäftigt sich mit Diensten zur Erstellung neuer Agenten.
Sie umfaßt etwa das Typsystem, das die Types, die Typdefinitionen von Agents und
Entities, verwaltet; die Mechanismen zum Laden und Instanzieren solcher Definitionen
und die Methoden zum Generieren eindeutiger Identifikatoren für Agenten.
Ein Typsystem und Methoden zum Instanzieren werden etwa von der JVM in Form des
Class Loaders geboten. Identifikatoren können zufällig, linear oder hierarchisch erzeugt
werden.
ii.
Execution
Execution umfaßt alle Aspekte, die für gewöhnlich von einer Laufzeitumgebung
behandelt werden. Darunter fallen die Zuteilung von Speicher und Rechenzeit und die
Verwaltung des Zugriffs auf andere Resources, und die eigentliche Ausführung von
Programmcode. Weiterhin kann die Ausführungsumgebung Dienste zum Behandeln
von Ausnahmen, zur Wahrung der Konsistenz (Transaktionen) oder zum Publizieren
von Ereignissen bieten.
– 114 –
Hier werden wichtige technische Details bezüglich der parallelen Ausführung von
Agenten, der Auflösung von Ressourcenkonflikten und der Fehlerverwaltung beschrieben, sowie grundlegende Fragen, etwa welche Art von Programmcode überhaupt
ausgeführt werden kann.
iii.
Management
Managementdienste dienen zur Verwaltung des Agentenlebenszyklus von außen, also
etwa zum Einfrieren oder Beenden von Agenten, und zur Überwachung der Ausführung
von Agenten, etwa durch ihren menschlichen Benutzer.
iv.
Discovery
Die Kategorie Discovery umfaßt Verzeichnisdienste zum Auffinden von Agenten und
Facilities. Im weiteren Sinne fällt auch die Dokumentation der Struktur der Entities
darunter, besonders, wenn diese zur Ortung lokaler Agenten relevant ist.
Diese Kategorie ist für jedes Multiagentensystem von zentraler Bedeutung. Der
überwiegende Teil des MASIF-Standard und viele Elemente des FIPA-Standards
befassen sich mit genau dieser Klasse von Diensten.
v.
Communication
Die umfangreiche Kategorie Communication enthält Dienste zum Kodieren von
Nachrichten, Versenden von Nachrichten und zum korrekten Auflösen von Adressen.
Fortgeschrittene Dienste befassen sich mit Kompensationsmaßnahmen bei Übertragungsfehlern und dem nichttrivialen Problem der Open Channels, der Erreichbarkeit
migrierender Agenten.
Relevante Charakteristika der Transportdienste sind etwa, wie Agenten adressiert
werden, ob sich einzelne und/oder Gruppen von Agenten ansprechen lassen oder
welchen Restriktionen der Inhalt von Nachrichten unterliegt. Die Dienste zur Fehlerkorrektur und zur Kommunikation mit migrierenden Agenten können aufwendige Algorithmen umsetzen (vgl. etwa [Murphy/Picco 2002]).
– 115 –
vi.
Persistence
Persistence ist eine sehr übersichtliche Kategorie: Sie umfaßt Dienste zur persistenten
Speicherung von Agenten, Ressourcen und zugehörigen Daten, und zur Wiederherstellung der gespeicherten Informationen in einen ausführbaren Zustand.
vii.
Migration
Migrationsdienste teilen üblicherweise mit Persistenzdiensten das Bedürfnis, den
aktuellen Zustand eines Agenten festhalten zu müssen. Weiterhin müssen sie die
Übertragung des Agenten ermöglichen, wobei Übertragungsfehler zu kompensieren
sind. Darüber hinaus sind sie noch für das Management der vom Agenten benötigten
Ressourcen verantwortlich. Ein erweiterter Dienst wäre die Erstellung einer Sicherheitskopie, die automatisch reaktiviert wird, wenn der Agent in einem fremden Environment verloren geht.
Bei Migrationsdiensten ist zum einen relevant, welche Daten bzw. Ressourcen in
welcher Aufteilung übertragen werden, zum anderen, welche Informationen über den
Ausführungszustand des Agenten überhaupt übertragen werden können.
viii.
Security
Security ist eine Kategorie, deren Dienste sich oft schwer monolithisch definieren
lassen, da sie oft eng mit anderen Diensten verflochten sind. Sie schließen die Authentifizierung von Agenten, die Zugriffsteuerung auf Resources und andere Entities, die
Überwachung der Integrität der Agentenplattform und einzelner, insbesondere mobiler
Agenten und die Verschlüsselung vertraulicher Informationen ein.
ix.
Interface
Die Kategorie Interface faßt alle Dienste zusammen, die sich mit Schnittstellen zur
Außenwelt befassen. Zum einen kann dies den Zugriff auf Funktionen des umgebenden
Systems oder die Interaktion mit einem menschlichen Benutzer bedeuten. In diesem
Falle sind die Facilities der Dienste gleichzeitig Proxies. Zum anderen bezieht sie sich
auf Dienste, die Konvertierungen jedweder Art vornehmen.
– 116 –
II.
Modellierung
Das Service Model ist das heterogenste Teilmodell der Physical Layer. Aufgrund der
Verschiedenartigkeit der erfaßten Services läßt es sich praktisch kaum sinnvoll mit
einem einheitlichen Formalismus modellieren.
In vielen Fällen ist die Beschreibung auf der Begriffsebene ausreichend. Basiert eine
Agentenplattform auf Java und der JVM, ist etwa eine detaillierte Modellierung des
Typsystems und des Klassenladers weitgehend überflüssig.
In manchen Fällen erscheint eine genauere Beschreibung relevant, etwa wenn Einschränkungen eines vorhandenen Dienstes Auswirkungen auf die Möglichkeiten selbst
implementierter Dienste oder die Anwendungsebene haben.
Javas eingeschränkte Fähigkeiten zur Introspektion erschweren etwa Migration unter
vollständiger Mitnahme des Ausführungszustandes erheblich.
Dienste mit einem komplexen Zustandsmodell, etwa zur Behandlung von Übertragungsoder Synchronisierungsfehlern, sollten durch entsprechende Diagramme spezifiziert
werden. Bei selbst implementierten Diensten ist die Angabe der oben definierten
Attribute eines Service, also seine Nutzer und die von ihm betroffenen Entities,
wünschenswert.
Der Vorteil des Service Model ist, daß im Zweifelsfall immer auf die Beschreibung der
konkreten Umsetzung des Services in Form einer Facility oder eines Enforcement
Process zurückgegriffen werden kann, wenn die anderen Spezifikationsmethoden zu
unspezifisch erscheinen. Auf diese Weise läßt sich das Teilmodell sowohl zur Formulierung eines groben Überblicks über die Fähigkeiten eines Systems als auch als ausreichend genaue Spezifikation zur Sicherstellung von Interoperabilität auf der technischen
Ebene verwenden.
– 117 –
3.3.1.5 Zusammenfassung der Physical Layer
Abschließend soll nochmals ein Überblick über die wichtigsten Elemente der Physical
Layer und die Zusammenhänge zwischen den Teilmodellen gegeben werden. Dabei
wurden der Übersichtlichkeit halber einige Spezialisierungsbeziehungen, Unterklassen
und Beziehungen unterdrückt.
(1,1)
(0,n)
(1,1)
Enforcement
Process
Autonomous
Process
Natural Law
defines
d,p
(0,n)
Sensor
generates
(1,1)
(0,1)
(0,n)
d,t
Mechnism
(1,1)
Context
possesses
Percept
Effector
emits
(0,1)
(1,1)
Composition
affects
(0,n)
perceives
defines
(1,1)
(0,n)
Process
describes
(1,1)
contains
(0,n)
(1,1)
(1,1)
(0,n)
runs
manipulates
(0,n)
possesses
(0,n)
(0,n)
Hierarchy
(0,n)
(0,n)
(0,n)
Environment
(0,n)
(0,n)
(0,1)
(0,n)
contains
(0,n)
(0,n)
Entity
d,t
(0,n)
Agent
receives
(0,n)
(0,n)
(0,n)
Structure
(0,n)
(0,n)
(1,1)
(0,n)
Message
(0,n)
(0,n)
Structure
Item
offers
represents
instantiates
Composition
(1,1)
implements
(0,n)
Service
(0,1)
(0,n)
(0,n)
(0,n)
requires
implements
(1,n)
Facility
(0,n)
Proxy
Type
Structure
(0,n)
(0,n)
(0,n)
Resource
n,p
Generation
Execution
Discovery
Management
Communication
Persistence
Migration
Security
Abbildung 3.15 Übersicht über die wichtigsten Elemente der Physical Layer
Interface
– 118 –
3.3.2 Conceptual Layer
Die Conceptual Layer72 leistet die Beschreibung des Zwecks und der anwendungsbezogenen Semantik des Systems. Sie argumentiert in sozialen, juristischen und mentalistischen Begriffen und soll dadurch eine präzise, aber möglichst anschauliche Beschreibung des komplexen Systemverhaltens ermöglichen.
Während die Physical Layer vom Allgemeinen zum Speziellen hin beschrieben wurde,
beginnt die Darstellung der Conceptual Layer mit der privaten Sicht eines Agenten, die
dann um zunehmend öffentliche und gesamtheitliche Perspektiven erweitert wird.
Das Mental Model beschreibt den Agenten aus einer klassischen mentalistischen
Perspektive. Inwieweit dabei die tatsächliche Implementierung des Agenten beschrieben
oder nur die Zuschreibung mentaler Eigenschaften als Argumentationshilfe verwendet
wird, liegt im Ermessen des Entwicklers.
Das Behavioral Model beschreibt das Verhalten und die Interaktionen der Agenten. In
diesem Zusammenhang wird die juristische Perspektive auf die unterstellten Absichten
eines Agenten verwendet. Das Modell ist die Brücke zwischen Mental Model und
Social Model, die sich (zur Verhinderung von unbewußt vorausgesetztem Gedankenlesen) nicht berühren.
Das Social Model steht in enger Verbindung mit dem Behavioral Model. Es beschreibt
die sozialen Normen der verschiedenen Subsysteme des Agentensystems, also im
Besonderen auch die Interpretation bestimmter Handlungen. Ähnlich wie Verfassungen,
Gesetze und Satzungen in menschlichen Gesellschaften definiert es die Systemstruktur
und die Regeln, die das System kontrollieren.
Das Application Model beschreibt zum einen die logische Struktur des Anwendungssystems, zum anderen seinen Zweck und seine Zielhierarchie.
Die Conceptual Layer ist primär ein konzeptionelles Werkzeug, das dem Entwickler bei
der Erstellung eines konsistenten Systems unterstützen soll. Während die Physical
72
Die Übersicht über die Elemente der Conceptual Layer wird durch Abbildung 3.22, S. 167, gegeben.
– 119 –
Layer sich noch vergleichsweise direkt auf ein objektorientiertes Modell zurückführen
läßt, fließen hier die Innovationen der Agententheorie ein, so daß diese Abbildung nicht
mehr trivial ist. Es wird allerdings angestrebt, daß die Elemente der Conceptual Layer
jeweils über eine möglichst genau definierte Abstützung auf die Physical Layer
verfügen. Es steht dem Entwickler zwar frei, während des Modellierungsprozesses über
das System in beliebig abstrakten Begriffen zu argumentieren, jedoch ist gerade mit
Bezug auf soziale Normen der angesprochene Punkt zu beachten, daß ihre explizite
Überprüfung im Rahmen des Laufzeitsystems auch eine konkrete Umsetzung erfordert.
3.3.2.1 Mental Model
Das Mental Model73 bietet den Rahmen für die Beschreibung eines Agenten im Sinne
der vorgestellten mentalistischen Theorien. Seine Begriffe sind dabei aber nur so
spezifisch, wie dies mit Bezug auf das Behavioral Model erforderlich ist.
Die Implementierung eventueller künstlicher Intelligenz der Agenten wird durch das
Metamodell nicht modelliert, da die Anforderungen und Ansätze der verschiedenen
Agentensysteme hier einfach zu komplex und zu unterschiedlich sind, um ihnen durch
eine einheitliche Beschreibung gerecht zu werden. Daher wird dieser Teil des Agenten
nur durch eine Black Box beschrieben, um die sich die explizit beschriebenen mentalen
Elemente anordnen.
I.
Elemente
A.
Outlook
Der Outlook eines Agenten beschreibt seine Erkenntnisse über die Welt. Er enthält zum
einen die interne Repräsentation des Environments, auf deren Grundlage der Agent
Entscheidungen trifft, und zum anderen Aussagen über den inneren Zustand des
Agenten.
73
Abbildung 3.16, S. 128, gibt einen Überblick über die Elemente des Mental Model.
– 120 –
Die Representation im Modell von Bölöni und Marinescu74, der Place im Modell von
Viroli und Omicini75 oder die Gesamtheit der mentalistischen Attribute eines BDIAgenten76 können als Outlook verstanden werden.
Der Outlook wird, sofern er nicht nur abstraktes Beschreibungsmittel ist, im Rahmen
des Agent Core implementiert. Er stellt ein geordnetes System von Statements dar, die
im Folgenden genauer beschrieben werden.
Element Summary
Outlook
Hierarchical Name
Conceptual.Outlook
Definition
An Agent’s internal representation of the world.
Relationships
Consists of Statements
Used by Agent Personality
Formalisms
Data structures, KIF
Grounding
Agent Core data structures
Examples
Knowledge representation, mentalistic attributes, internal object state
B.
Statement
Ein Statement ist das grundlegende Beschreibungselement des Outlooks, also eine
elementare Erkenntnis. Als ein Statement kann unabhängig von ihrer Form jede
Beschreibung eines Zustandes oder eines Zusammenhanges gewertet werden. Statements können natürlichsprachig, durch klassische oder modale Logik, durch Zustandsmodelle oder Objektattribute ausgedrückt werden. Ein Statement s o l lt e im Prinzip
einer Aussage im mathematisch-logischen Sinn entsprechen, muß aber nicht notwendigerweise wahr oder falsch sein. Unentscheidbare oder paradoxe Statements dürften
allerdings in den meisten Fällen zur Modellierung nicht hilfreich sein.
„Die Sonne scheint.“, „Der Agent möchte einen Fahrschein kaufen.“ oder das Paradox
„Ich lüge.“ sind natürlichsprachige Statements.
74
Siehe Abschnitt 2.4.2, S. 41.
Siehe Abschnitt 2.4.3, S. 44.
76
Siehe Abschnitt 2.3.2.3, S. 26.
75
– 121 –
Formalisierte Statements sind etwa Prädikate wie mensch(sokrates) oder rolle(agent,
rollenbezeichnung), aber auch Syllogismen oder Regeln, etwa mathematische Zusamn
n
n
menhänge wie die binomische Formel (a + b ) = ∑  a i b n −i .
i =0  i 
In einem objektorientierten System können Statements einfach Attribute wie etwa
Konto::stand = 150 oder Agent::directory = &pointer sein.
Statements können Hierarchien, Subsumptionsbeziehungen und andere Relationen
miteinander eingehen.
Statements lassen sich nach ihrem Ursprung in inhärente, kognitive und abgeleitete
Statements unterteilen. Orthogonal dazu ist die Unterscheidung zwischen faktischen
und durch modale Operatoren qualifizierten Statements.
Das Metamodell zielt auf die Konstruktion agentenbasierter Anwendungen und nicht
auf die Entwicklung einer Erkenntnistheorie für Agenten ab. Die Unterscheidung
zwischen den verschiedenen Erkenntnisquellen hat eine ganz konkrete technische
Signifikanz, obschon sie sich auf den Gegensatz zwischen der Sicht der Rationalisten
(Descartes, Leibniz) und dem Skeptizismus des Empiriker (Locke, Hume) zurückführen
läßt, der im Mittelpunkt von Kants Kritik der Reinen Vernunft ([Kant 1787]) steht.
Element Summary
Statement
Hierarchical Name
Conceptual.Statement
Definition
An insight, basic element of the description of an Agent’s mental state
Relationships
Makes up Outlook
Formalisms
Natural language, specification language, KIF, modal logic
Grounding
Agent Core data structure
Examples
Predicate, fact, belief, desire, intention, goal, assumption, variable binding
i.
Inherent Statement
Inherent Statements beschreiben Aussagen, über die ein Agent a priori verfügt. Sie
sind aus Sicht des Agenten unzweifelhaft wahre Erkenntnisse im Sinne der reinen und
nicht reinen Vernunft (d.h. abstrakte Aussagen bzw. Aussagen über die Welt).
Die Inherent Statements werden dem Agenten von seinem Entwickler eingegeben.
Entweder schlagen sie sich implizit in der Implementierung nieder, so daß der Entwick-
– 122 –
ler sie dem Agenten aus sich selbst heraus zuschreibt, oder sie werden dem Agenten
explizit in Gestalt einer Wissensrepräsentation mitgegeben.
Entsprechende Aussagen können statische Grundüberzeugungen des Agent, ein
Basismodell der Welt, technisch relevante Informationen oder auch einfach eine
Ausgangskonfiguration sein.
Das inhärente Wissen eines Agenten kann etwa seine Aufgabe, den Namen seines
Benutzers, die Adresse eines Verzeichnisdienstes und dessen Schnittstellen, eine
Ontologie der umgebenden Welt oder die Beschreibung einer Ausgangssituation
umfassen.
Darüber hinaus können Inherent Statements auch Entwurfsprinzipien und Grundregeln
beschreiben, etwa Entwurfsziele wie „versucht, das Verzeichnis aktuell zu halten“, vom
Agenten verwandte Syllogismen wie modus ponens und modus tollens, bezüglich des
Zustandes des Agenten gemachte Garantien oder unumstößliche Sicherheitsbestimmungen wie Asimovs First Law of Robotics [Asimov 1994].
Element Summary
Inherent Statement
Hierarchical Name
Conceptual.Statement.Inherent
Definition
A Statement known a priori by an Agent
Examples
First principles, laws, rules, safeguards, default values, ontology
ii.
Cognitive Statement
Cognitive Statements sind empirische Aussagen, zu denen der Agent aufgrund gegenwärtiger oder, falls er ein Gedächtnis für seine Wahrnehmungen besitzt, vergangener
Sensoraktivität gelangt ist.
Welche Cognitive Statements ein Agent erwerben kann, hängt somit davon ab, was er
nach Maßgabe seiner Sensoren und der seinen Context bestimmenden Regeln des
Environment wahrnehmen kann. Jedes Cognitive Statement läßt sich direkt auf eine
Sensoreingabe bzw. ein Percept zurückführen.
Geortete Hindernisse im Weg eines Roboters, Nachrichten anderer Agenten, Benutzereingaben, Informationen über den Ausführungszustand des Agenten oder Aussagen über
die Attribute anderer Entities werden alle durch Cognitive Statements beschrieben.
– 123 –
Cognitive Statements ist auf drei Ebenen mit einer gewissen Skepsis zu begegnen:
Zunächst kann der Wahrnehmungsprozeß die Umwelt verfälschen, da gerade in
physikalischen Systemen Wahrnehmung nie objektiv sein kann. Selbst bei semantisch
korrekter Wahrnehmung sind die abgeleiteten Cognitive Statements nicht unbedingt
wahr: die wahrgenommene Entity kann selbst eine unwahre Aussage ausdrücken.
Zuletzt bleiben wahre Aussagen nicht zwangsläufig wahr, sondern können schon nach
kurzer Zeit nicht mehr aktuell sein.
Ein Roboter im RoboCup verwechselt das rote T-Shirt eines Zuschauers mit dem Ball.
Ein Einkaufsagent kann die Nachricht eines anderen Agenten korrekt empfangen, der
andere Agent kann dabei aber trotzdem im Inhalt der Nachricht lügen. Ein mobiler
Agent will einen anderen Agenten lokal ansprechen, der inzwischen das System
verlassen hat.
Für jegliche Interaktion mit anderen Agenten und der Umwelt ist diese Klasse von
Aussagen essentiell. Welche Cognitive Statements möglich sind und vor allem welche
Relevanz ihnen zugemessen wird, ist somit eine wichtige Frage im Rahmen der
Implementierung der Agentenintelligenz.
Element Summary
Cognitive Statement
Hierarchical Name
Conceptual.Statement.Cognitive
Definition
A Statement acquired by an Agent’s Sensors
Grounding
Sensor input, possibly Percept
Examples
Internal representation of perceptions, received messages
iii.
Derived Statement
Derived Statements werden von der internen Logik des Agenten hergeleitet. Sie
ergeben sich als Schlußfolgerungen aus bereits vorhandenen Statements. Dabei hängt
ihre Glaubwürdigkeit von den zugrundegelegten Statements ab: Leiten sie sich nach
rationalen Prinzipien aus Inherent Statements ab, sind sie ebenfalls unzweifelhaft wahr.
Basieren sie dagegen auf Cognitive Statements, pflanzen sich eventuelle Fehler in ihnen
fort.
Die Schlußfolgerungen können in einer reinen Logik begründet oder auch durch
Heuristiken, subjektive Einschätzungen oder Nichtdeterminismus bestimmt sein.
– 124 –
Die klassische Aussage „Sokrates ist sterblich“ leitet sich logisch aus „Alle Menschen
sind sterblich“ und „Sokrates ist ein Mensch“ ab. Auktionsagent A kann als Folge aus
der Erkenntnis „Agent B hat die Lieferung nicht bezahlt“ die subjektive, normative
Aussage „Ich mache mit Agent B keine Geschäfte mehr“ ableiten.
Element Summary
Derived Statement
Hierarchical Name
Conceptual.Statement.Derived
Definition
A Statement that has been derived from other Statements by the Agent
Examples
Conclusions, resolutions
iv.
Factual Statement
Die zweite Differenzierung unterscheidet zwischen faktischen und modalen Aussagen.
Factual Statements sind im Sinne einer klassischen Aussagenlogik zu verstehen. Sie
sollen eine Tatsache über den Agenten oder die Welt ausdrücken. Sie sind nicht
notwendigerweise wahr. Sie sollten sich auf Attribute konkreter Entities abstützen.
Im Sinne der Programmierung lassen sich die Eigenschaften des Systemzustands, also
besonders die Werte sämtlicher Variablen, als faktische Aussagen verstehen. Reines
Wissen erster Ordnung läßt sich ebenfalls durch faktische Aussagen beschreiben.
Der Begriff wird aus pragmatischen Gründen definiert, da im Grunde ein Factual
Statement auch als modale Aussage geschrieben werden kann, dies aber für viele
Anwendungen unangemessen aufwendig erscheint.
Element Summary
Factual Statement
Hierarchical Name
Conceptual.Statement.Factual
Definition
A Statement supposed to state a fact about the world.
Grounding
Entity
Examples
Value of a variable, statement in Boolean logic
v.
Modal Statement
Ein Modal Statement ist ein durch modale Operatoren qualifiziertes Statement. Diese
Klasse von Aussagen ist für die Beschreibung eines Agenten im Sinne der meisten
Agententheorien unverzichtbar.
– 125 –
Typische Modal Statements sind Beliefs, Desires, Intentions, Uncertain Beliefs, Wants,
Needs und Assumptions.
Das Metamodell sieht solche Aussagen nur vor, macht aber keine inhaltlichen Aussagen
über ihre Semantik. Diese wird vom Modellierer durch assoziierte Semantics spezifiziert. Dementsprechend werden Modal Statements von anderen Teilen des Metamodells
nicht referenziert, sondern können in dieser Form nur für die interne Implementierung
der Agentenintelligenz von Belang sein.
Element Summary
Modal Statement
Hierarchical Name
Conceptual.Statement.Modal
Definition
A Statement qualified by a modal expression
Relationships
Uses Semantics
Formalisms
Tied to Semantics
Examples
Belief, desire, intention, goal, uncertain belief, assumption
a.
Semantics
Semantics definieren die Semantik eines Modal Statement. Die Wahl eines geeigneten
Formalismus liegt allein beim Modellierer.
Element Summary
Semantics
Hierarchical Name
Conceptual.Semantics
Definition
Defines the semantics of Modal Statements
Relationships
Used by Modal Statement
Formalisms
Informal semantics, modal logic
Examples
BDI, FIPA ACL, KQML
b.
Aim
Der Begriff Aim ist insoweit eine Ausnahme, daß er die einzige Klasse modaler
Aussagen beschreibt, deren Semantik durch das Metamodell beschrieben wird. Sinngemäß ist ein Aim mit Goals oder Desires vergleichbar. Es wird abweichend benannt, da
seine Definition nur vergleichsweise naiv ist: Ein Aim ist ein Statement, das wahr sein
soll, d.h. der Agent hat den Auftrag, das Zutreffen des Aim entweder zu erhalten oder,
falls es nicht schon wahr ist, herbeizuführen. Aims sind eine reine Argumentationshilfe
und können in der Anwendung auch durch eventuell vorhandene stärkere Formalismen
ersetzt werden.
– 126 –
Aim eines Thermostaten ist etwa, daß die gemessene Temperatur 23°C sein soll.
Da Aims Statements sind, gilt auch hier die Unterscheidung zwischen inhärenten und
abgeleiteten Aims. Inhärente Aims übersetzen die Entwurfsziele eines Agenten in seine
subjektive Perspektive und sind somit mit einer Mission77 assoziiert.
Aims können Hierarchien bilden und mit Gewichtungen versehen werden. Unter
Entlehnung des Begriffs aus dem Modell von Bölöni und Marinescu78 kann der entsprechende Ausschnitt des Outlook als Agenda bezeichnet werden.
Element Summary
Aim
Hierarchical Name
Conceptual.Statement.Modal.Aim
Definition
A Statement an Agent is supposed to make or keep true.
Relationships
Translates a Mission
Grounding
Entity
Examples
Temperature := 23°C
C.
Premeditation
Die Premeditation eines Agenten sind die geplanten Aktivitäten eines Agenten. Sie
wird durch eine Abfolge von Actions79 definiert und kann durch die Relationen in einem
gerichteten, azyklischen Graphen beschrieben werden.
Die Aktivitäten können mit Dauer, Anfangs- und Endzeiten versehen werden, so daß die
zeitliche Ordnung genau beschrieben werden kann. Die Premeditation erlaubt jedoch
keine Aussagen zur Finalität einzelner Aktivitäten. Insoweit beschreibt die Premeditation die Absichten eines Agenten nur auf einer rein behavioristischen Ebene.
Ein Auktionsagent schließt einen Kaufvertrag ab und plant daraufhin, binnen einer
Woche dem Verkäufer den Kaufpreis zu bezahlen.
77
Siehe Mission, S. 163.
Siehe Abschnitt 2.4.2, S. 41.
79
Siehe Action, S. 133.
78
– 127 –
Die Bedeutung der Premeditation wird bei der Beschreibung ihres öffentlichen
Gegenstücks, der Schedule, im Rahmen des Behavioral Model im Detail betrachtet.
Element Summary
Premeditation
Hierarchical Name
Conceptual.Premeditation
Definition
A dag describing the Actions an Agent has scheduled
Relationships
Contains Actions
Formalisms
Any scheduling formalism
Examples
Scheduled payments, project plan
D.
Agent Personality
Die Agent Personality faßt zum einen Outlook und Premeditation eines Agenten
begrifflich zusammen. Zum anderen ist die Agent Personality die Abstraktion von der
Implementierung der künstlichen Intelligenz des Agenten. Sie enthält somit die
Inferenzmaschine eines Agenten, entsprechend der Agent Internal Machinery bei Viroli
und Omicini80.
Die Agent Personality ist die konzeptionelle Beschreibung des Agent Core auf der
Physical Layer.
Element Summary
Agent Personality
Hierarchical Name
Conceptual.Agent.Personality
Definition
Abstraction for an Agent’s AI
Relationships
Connected to Outlook, Premeditation and Aims
Formalisms
Any modelling technique
Grounding
Agent Core
Examples
Specification of an agent’s AI
II.
Modellierung
Die Modellierung des Mental Model ist nicht mit wenigen Worten abdeckbar. Weite
Teile der meisten formalen Agententheorien fallen in seinen Bereich, so daß die Anzahl
der existierenden Methoden groß ist. Wie beschrieben kommen hier zumeist logische
80
Siehe Abschnitt 2.4.3, S. 44.
– 128 –
Spezifikationssprachen zum Einsatz. Daneben existieren Agenten mit sehr speziellen
Anforderungen, die sich zwar in Teilen durch Statements beschreiben lassen, im
Wesentlichen aber innerhalb der Agent Personality definiert sind und daher mit einer
geeigneten weiterführenden Methode beschrieben werden müssen.
Sprachbasierte Chatagenten benötigen zwar eine Repräsentation ihrer Weltsicht und
Erinnerungen an vorhergehende Gesprächsthemen und Bezugsobjekte, die sich als
Statements ausdrücken lassen. Die wesentliche Leistung der Agenten liegt jedoch in
ihrem Parser und der Generierung neuer Sätze, die auf dieser Ebene nicht beschrieben
werden können.
Inherent
Statement
Outlook
(0,n)
consists of
(0,n)
(0,n)
(1,1)
Statement
d,t
Derived
Statement
(0,n)
Structure
Cognitive
Statement
has
Factual
Statement
n,t
(1,1)
Agent
Personality
(0,n)
has
(0,n)
(0,1)
(1,1)
Modal
Statement
Aim
(0,n)
d,p
(1,1)
Hierarchy
has
using
(1,1)
Premeditation
(0,n)
(0,n)
plans
(0,n)
Action
Abbildung 3.16 Elementbeziehungen innerhalb des Mental Model
Semantics
– 129 –
Entsprechende spezielle Methoden lassen sich problemlos in Verbindung mit dem
Metamodell verwenden. Für modellinterne Zwecke genügen jedoch auch einfachere
Formalismen.
In einfachen Fällen kann eine natürlichsprachige Spezifikation durchaus ausreichend
sein. Unter Umständen ist auch eine direkte Modellierung mit den Methoden der
klassischen Softwaretechnik möglich. Ist das Modell komplexer, ist eine formalere
Beschreibung der Ontologie der Statements erforderlich. Wichtig ist hier die Abstützung auf Sensorwahrnehmungen bzw. indirekt Entities. Die Premeditation läßt sich
problemlos durch hergebrachte Netzplantechniken wie CPM oder PERT (vgl.
[West/Levy 1977]) beschreiben.
3.3.2.2 Behavioral Model
Das Mental Model beschreibt zwar die mentalen Einstellungen eines Agenten, macht
aber bislang noch keine Aussagen über deren beobachtbare Dynamik, zumal sich in
ihrem Zentrum in Form der Agent Personality eine Black Box befindet, von der
nichtdeterministische Änderungen ausgehen können. Das Behavioral Model fügt dem
nun die für eine externe Betrachtung erforderliche öffentliche Perspektive hinzu, wobei
die als Legal Stance eingeführte juristische Sichtweise zum Einsatz kommt.81
Behaviors beschreiben in Form von Bedingungen und Aktionen Verhaltensweisen. Für
ihren Einsatz als Mittel zur Beschreibung eines Agentensystems ist vor allem die Frage
von Belang, ob sich erkennen läßt, wann ein Agent sich konform zu einem Behavior
verhalten hat. Gerade in offenen Systemen ist die Definition und Erkennung a b w e i c he n d e n Verhaltens mindestens genauso wichtig wie die Definition normgerechter
Verhaltensweisen. Auch wenn es bei Behaviors natürlich nicht per se um schädliche
Verhaltensweisen geht, läßt sich hier daher eine interessante Parallele zum angelsächsischen Strafrecht ziehen. Sein zentraler Grundsatz ist actus non facit reum nisi mens sit
rea (‚Eine Tat macht keinen zum Schuldigen, wenn nicht sein Geist schuldig ist’). Eine
Verurteilung erfordert den Nachweis der Tat, actus reus, und des Vorsatzes, mens rea.
81
Für eine Übersicht über das Behavioral Model siehe Abbildung 3.17, S. 139.
– 130 –
Hinsichtlich des actus reus ist dies für Agentensysteme zumeist unproblematischer als
in menschlichen Gesellschaften. Einfache Actions haben eine exakte Entsprechung in
Form von Anwendungen von Effectors und Active Sensors auf der Physical Layer und
können als solche in der Regel wahrgenommen und dokumentiert werden. Problematisch ist hingegen der Nachweis des mens rea, also die Erfüllung der mentalen Vorbedingungen, die das Behavior erfordert.
Um dieses Problem zu lösen, werden Position und Schedule definiert. Die Position ist
die öffentliche Perspektive auf den Outlook eines Agenten, die Schedule publiziert
Teile der Premeditation. Im Idealfall sind die beiden jeweils identisch, in jedem Fall ist
jedoch anzustreben, daß sie jeweils konsistent sind, d.h. die öffentliche Beschreibung
eine echte Teilmenge der privaten Beschreibung ist.
Im Folgenden werden zunächst die beiden öffentlichen Sichten definiert. Im Anschluß
werden Actions und Behaviors beschrieben.
I.
Elemente
A.
Position
Die Position publiziert die Weltsicht eines Agent, um seine Handlungen im sozialen
Kontext vorhersagen und beurteilen zu können. Die Position ist ähnlich strukturiert wie
der Outlook und besteht aus einer Struktur von Statements. Daher fallen auch die
identischen drei Ursprungsklassen für Statements an.
Inherent Statements sind die am wenigsten problematische Klasse. Da sie schon in der
Spezifikation des Mental Model durch den Modellierer explizit abgebildet worden sind,
lassen sie sich in diesem Zusammenhang auch problemlos in der selben Form öffentlich
machen.
Cognitive Statements können nicht vorab in einem statischen Modell beschrieben
werden. Der Vorteil dieser Art von Statements ist jedoch, daß sie sich unter Kenntnis
der Regeln des Environment und der verfügbaren Sensors eindeutig herleiten und dem
Agenten zuschreiben lassen. Das einzige Problem hier sind nicht allgemein nachvollziehbare Wahrnehmungen, etwa eine private Konversation zwischen zwei Agenten. Die
Sicht der anderen Agenten auf die Position fragmentiert, was aber kein übermäßiges
– 131 –
Problem ist, solange das Verhalten des Agenten unstrittig ist. Die Regelung von
Konflikten erfordert allerdings eine Offenlegung der Kommunikation.
Agent A nimmt in einer privaten Nachricht an Agent B dessen Angebot an und schreibt
der Position von B somit Wissen über den geschlossenen Vertrag zu. Aus der Sicht von
Aufsichtsagent C enthält die Position von B keine solche Information. Wenn B nun
gegenüber A den Vertrag leugnet und somit lügt, muß A den Nachrichtenaustausch
nachweisen, um C davon zu überzeugen, Sanktionsmaßnahmen gegen B zu ergreifen.
Die meisten Probleme bereiten die Derived Statements, da ihre Herleitung Wissen über
die Inferenzkomponente des Agenten erfordert. Für den Entwickler, der die künstliche
Intelligenz eines Agenten selbst umsetzt, ist diese Information implizit vorhanden – in
offenen, heterogenen Systemen ist sie aber als solche nicht verfügbar, wenn sie nicht
gar als Geschäftsgeheimnis gehütet wird. Eine Beschreibung intelligenten Verhaltens ist
ohne sie jedoch undenkbar.
Der Lösungsansatz für dieses Problem wird in der weiteren Beschreibung des Behavioral Model geliefert werden: Wo diese für die Interaktion mit der Umwelt relevant
erscheinen, kann ein Agent in ergebnisorientierter Weise beschreiben, welche (Arten
von) Schlußfolgerungen er aus bestimmten Statements ziehen wird. Diese Beschreibungen haben die Form von Behaviors, deren Actions die Position modifizieren.
Ein Agent publiziert: ‚Wenn ich auf ein Angebot nicht binnen 5 Minuten eine Antwort
erhalten habe, schließe ich, daß der andere Agent nicht interessiert ist.’
Element Summary
Position
Hierarchical Name
Conceptual.Position
Definition
The legal stance perspective on an Agent’s Outlook
Relationships
Publishes Outlook
Referenced by Behavior
Examples
B.
Set of published beliefs and goals
Schedule
Die Schedule eines Agent gleicht dementsprechend seiner Premeditation und dokumentiert seine angekündigten bzw. erwarteten zukünftigen Handlungen. Sie dient der
Dokumentation seiner Absichten, die hier jedoch keine Beschreibung des angestrebten
– 132 –
Ziels im Sinne des Konzepts der Intention82 sind, sondern die konkret beabsichtigten
Handlungen auf dem Weg zu diesem Ziel angeben.
Diese Sichtweise ist zweifach motiviert: Zum einen besitzen die konkreten Handlungen
dank der möglichen Abstützung auf die Physical Layer eine präzise definierte Semantik. Zum anderen spiegelt es die Tatsache wider, daß Akteure in einem sozialen Umfeld
primär nach ihren Handlungen und erst nachgeordnet gemäß der unterstellten Motivation der Handlung beurteilt werden. Dies gilt analog auch für zukünftige Handlungen:
zunächst ist wichtig, ob überhaupt eine Handlung vorgesehen ist, die Frage nach der
Begründung dabei zumeist zweitrangig.
Problematisch ist bei dieser Betrachtungsweise lediglich die Handhabung von bewußter
Inaktivität. In diesem Falle muß die Untätigkeit als spezielle Form der Action in der
Schedule erfaßt werden.
Der willentliche Bruch eines Leistungsversprechens oder das klassische ‚perfekte
Verbrechen’, das nur durch tatenloses Zusehen begangen wird, werden beide durch
b e w u ß t e Untätigkeit definiert.
Die Schedule entspricht wiederum einem gerichteten, azyklischen Graphen, der
durchaus nichtdeterministische Übergänge enthalten kann. Für die meisten Anwendungsbereiche dürfte es sich aber als notwendig erweisen, den einzelnen Aktionen im
Sinne eines Projektplanes Zeitrahmen, insbesondere Deadlines, zuweisen zu können, da
die Ankündigung einer Handlung ‚irgendwann’ in der Zukunft in der Regel keinerlei
planerischen Wert hat.
Die Einträge der Schedule sind alle auf die eine oder andere Art abgeleitet. Zum einen
können reaktive Behaviors bestimmte Reaktionen vorsehen, die dann in die Schedule
eingetragen werden. Zum anderen kann ein Agent ähnlich wie für Derived Statements
auch eigene Behaviors definieren, die beschreiben, welche geplanten Handlungen er aus
welchen Statements ableitet.
82
Siehe Abschnitt 2.3.2.3, S. 26.
– 133 –
Ein mobiler Agent veröffentlicht: ‚Sobald ich zu dem Schluß gekommen bin, daß die
lokalen Ressourcen für die Erreichung meiner Ziele nicht ausreichen, werde ich auf ein
anderes System migrieren.’
Element Summary
Schedule
Hierarchical Name
Conceptual.Schedule
Definition
The legal stance perspective on an Agent’s Premeditation
Relationships
Publishes Premeditation
Referenced by Behavior
Examples
C.
A timetable of expected actions
Action
Die einzelnen Aktionen im Rahmen von Behaviors und der Schedule werden durch
Actions beschrieben. Eine Action ist ein atomares Verhaltensmuster eines Agenten, das
den Zustand der Welt beeinflußt. Dabei wird unterstellt, daß der Agent sein Verhalten
beabsichtigt, was jedoch nicht notwendigerweise einschließt, daß er alle Konsequenzen
und Implikationen ebenfalls beabsichtigt.
Bei Actions wird zwischen zwei Untertypen unterschieden: Physical Effect, einer
Änderung am Environment, und Mental Effect, einer Änderung am Mental Model
bzw. seiner publizierten Repräsentation.
Element Summary
Action
Hierarchical Name
Conceptual.Action
Definition
The basic behavioral building block, affecting the state of the world
Relationships
Contained by Behavior, Schedule, Premeditation
Examples
Sending a message, reading a file, scheduling an Action
i.
Physical Effect
Ein Physical Effect ist eine Action, die durch eine konkrete, inhaltlich abgeschlossene
Abfolge von Effector- und Sensor-Anwendungen auf der Physical Layer beschrieben
werden kann. Der Schwerpunkt liegt dabei auf Effectors, jedoch können Active Sensors
analog erfaßt werden.
Die oben erwähnte Inaktivität kann als Physical Effect mit einer leeren Anwendungsreihenfolge gesehen werden.
– 134 –
Element Summary
Physical Effect
Hierarchical Name
Conceptual.Action.Physical
Definition
An Action that consists of using an Effector or Active Sensor
Formalisms
Entity Model
Grounding
Effector or Active Sensor
Examples
Sending a message, deleting a file, moving a robot
ii.
Mental Effect
Ein Mental Effect ist eine Action, die die Position und/oder die Schedule verändert,
was nach Möglichkeit zu entsprechenden Änderungen an Outlook und Premeditation
führen sollte. Ein Mental Effect kann Statements bzw. Actions einfügen, verändern
oder löschen.
Element Summary
Mental Effect
Hierarchical Name
Conceptual.Action.Mental
Definition
An Action changing the Agent’s Position or Schedule
Relationships
Affects Position or Schedule
Examples
Drawing a conclusion, scheduling an action
D.
Behavior
Zuletzt kann nun das Behavior als der zentrale Baustein des Behavioral Model mit
seinen verschiedenen Untertypen definiert werden. Ein Behavior ist ein komplexes
Verhaltensmuster. Eine Menge von Behaviors erlaubt die Charakterisierung eines
Agenten in Anlehnung an den sozialpsychologischen Behaviorismus, wobei der Begriff
hier durch die Berücksichtigung von Denkprozessen und die Bezugnahme auf das
Mentalmodell allerdings weiter gefaßt ist.
Auf der technischen Ebene greift ein Behavior unter anderem den Gedanken der
Methodensignatur in der objektorientierten Welt auf, geht aber durch die Hinzunahme
von semantischen und pragmatischen Aspekten sowie Proaktivität und Nichtdeterminismus darüber hinaus. Ein Behavior beschreibt das Verhalten eines Agenten unter
bestimmten Umweltbedingungen. Behaviors publizieren somit, was die Umwelt von
einem Agenten erwarten kann.
Behaviors können dabei unterschiedlich stark nichtdeterministisch geprägt sein. Streng
deterministische Behaviors sind naturgemäß eher agentenuntypisch. Jedoch ist es
durchaus üblich, daß Behaviors nichtdeterministische Entscheidungen enthalten, in
– 135 –
anderen Bereichen aber ganz präzise Verhaltensgarantien formulieren und objektähnliches Verhalten zeigen. Deterministische Behaviors lassen sich oft als spezielle Ausprägung eines generischen nichtdeterministischen Behaviors verstehen.
Ein Behavior, das das Verhalten eines Verkäufers beschreibt, könnte etwa die Abfolge
‚Angebot’ – ‚Vertragsschluß’ – ‚Lieferung’ vorsehen. Durch einen konkreten Handel
würde eine konkrete Frist oder gar ein exakter Zeitpunkt für die Lieferung festgelegt.
Jedes Behavior beschreibt jeweils nur das Verhalten eines einzelnen Agenten. Soll eine
Interaktion beschrieben werden, müssen daher mehrere komplementäre Behaviors
verwendet werden.
Ein Behavior besteht aus einer geordneten zeitlichen Abfolge von Actions, die durch
Entscheidungsregeln und Vor- und Nachbedingungen verknüpft sind, die sich auf
Position und Schedule des Agenten beziehen. Behaviors können sehr einfach oder
beliebig komplex sein; ein Behavior kann sich auch aus mehreren einfacheren Behaviors zusammensetzen oder andere Behaviors auslösen.
Die Subsumption Architecture kann als System von Behaviors modelliert werden.
Das Konzept des Behaviors wird auf zwei Arten verwendet, die im Rahmen des Social
Model ausgiebig betrachtet werden: Zum einen können Agenten a priori Behaviors
selbst publizieren – zum anderen kann ein externer Beobachter a posteriori beschließen,
daß ein Agent durch sein Verhalten einem bestimmten Behavior entsprochen hat, was
eine Beobachtbarkeit des Behaviors voraussetzt.
Element Summary
Behavior
Hierarchical Name
Conceptual.Behavior
Definition
A sequence of rules stating pre- and postconditions for specific Actions
Relationships
Included by Role
Conditions reference Position and Schedule
Formalisms
Natural language, script or programming language, flowchart, formal logic
Examples
Interaction protocol, conversing, moving, thinking, reacting
Behaviors lassen sich entlang mehrerer orthogonaler Achsen klassifizieren. Sie können
proaktiv oder reaktiv ausgelöst werden. Sie können inneres oder äußeres Verhalten
– 136 –
beschreiben, also auf die Umwelt einwirken oder rein mental sein. Sie können Einzelaktivitäten oder Interaktionen mit anderen Agenten sein.
i.
Spontaneous Behavior
Ein Spontaneous Behavior wird durch einen agenteninternen Impuls angestoßen. Der
Agent initiiert es proaktiv selbst, sei es aufgrund eines nichtdeterministisch modellierten
Zustandsübergang innerhalb seiner Agent Personality oder als Konsequenz einer gemäß
veröffentlichter Regeln abgeleiteten Schlußfolgerung. Die Bezeichnung bezieht sich nur
auf den Auslöser des Behavior – in seinem weiteren Verlauf kann das Verhaltensmuster
durchaus Interaktion und Reaktion enthalten.
Agent A beschließt, eine Message mit einem Angebot an Agent B zu schicken.
Ein Spieler eröffnet in Quake mit seinem Avatar das Feuer auf einen NPC.
Element Summary
Spontaneous Behavior
Hierarchical Name
Conceptual.Behavior.Spontaneous
Definition
A Behavior proactively initiated by an Agent
Examples
Starting a conversation, placing an offer
ii.
Conditioned Behavior
Ein Conditioned Behavior ist eine Reaktion auf einen äußeren Reiz. Es wird durch ein
neues Cognitive Statement, also eine Sensorwahrnehmung, ausgelöst. Diese Wahrnehmung wird in vielen Fällen die Folge eines Physical Effect, also durch eine Effektorbenutzung eines anderen Agenten bedingt, sein.
Agent B sendet eine Message an Agent A zurück, in der er das Angebot ablehnt.
Der NPC in Quake duckt sich, weicht aus und erwidert das Feuer.
Element Summary
Conditioned Behavior
Hierarchical Name
Conceptual.Behavior.Conditioned
Definition
A Behavior triggered by an Action or a new Cognitive Statement
Relationships
Triggered by Action or Cognitive Statement
Examples
Conversation protocols, automated response
– 137 –
iii.
Manifestation
Jedes Behavior, das mindestens einen Physical Effect umfaßt, ist eine Manifestation.
Manifestations sind daher zumindest teilweise beobachtbar.
Element Summary
Manifestation
Hierarchical Name
Conceptual.Behavior.Manifestation
Definition
A Behavior having Physical Effect
Examples
Sending a Message, moving the robot around.
iv.
Deliberation
Ein Behavior, das mindestens einen Mental Effects enthält, ist eine Deliberation. Eine
reine Deliberation, die nicht gleichzeitig eine Manifestation ist, ist nicht beobachtbar,
da sie naturgemäß völlig selbstbezogen ist.
Der durch die Deliberation beschriebene Denkprozeß muß nicht deterministisch oder
vollständig spezifiziert sein. Es können auch nur die Entscheidungsgrundlage und eine
Auswahl möglicher Ergebnisse angegeben sein. Deliberations sollen lediglich die
Möglichkeit bieten, die Schlußfolgerungen eines Agenten so transparent zu machen, wie
dies für die Entwicklung des Gesamtsystems notwendig erscheint.
Deliberations können zusätzlich noch eine weitere interessante Information vermitteln:
Da sie Behaviors sind, lassen sie sich als zeitliche Abfolge mit einer spezifischen Dauer
verstehen. Damit läßt sich beschreiben, daß ein Agent zwar alle gemäß der ihm zur
Verfügung stehenden Syllogismen aus den verfügbaren Informationen ableitbaren
logischen Schlüsse ziehen könnte, in endlicher Zeit aber jeweils nur immer einen
begrenzten Ausschnitt dieser Gesamtmenge tatsächlich betrachten kann. Dadurch wird
das Problem der Berücksichtigung des beschränkten Erfahrungshorizonts eines Agenten, das in Verbindung mit Possible World Semantics auftritt (Logical Omniscience
Problem), elegant gelöst.
Element Summary
Deliberation
Hierarchical Name
Conceptual.Behavior.Deliberation
Definition
A Behavior having Mental Effect
Examples
Making plans, drawing conclusions
– 138 –
v.
Solitary Behavior
Ein Solitary Behavior ist ein Behavior, das bezüglich anderer Behaviors in sich
abgeschlossen ist, also keine direkten Verflechtungen mit dem Verhalten anderer
Agenten besitzt. Es ist jedoch nicht notwendigerweise reflexiv, sondern kann auf die
Umwelt, also andere Entities und Agents, einwirken.
Element Summary
Solitary Behavior
Hierarchical Name
Conceptual.Behavior.Solitary
Definition
A self-contained Behavior involving only a single active agent
Examples
Moving the robot around, thinking, reading a file, .suspending another agent
vi.
Interactive Behavior
Ein Interactive Behavior ist Teil einer Beschreibung der Interaktion zwischen mehreren
Agenten. Da jedes einzelne Behavior jeweils aus der Perspektive genau eines Agenten
formuliert ist, wird dabei die Interaktion in ihrer Gesamtheit durch mehrere miteinander
verwobene Interactive Behaviors beschrieben.
Bei der Spezifikation einer Interaktion in einem Swim Lane-Aktivitätsdiagramm würde
jede einzelne Spalte (Swim Lane) ein Interactive Behavior wiedergeben.
Element Summary
Interactive Behavior
Hierarchical Name
Conceptual.Behavior.Interactive
Definition
A Behavior that, combined with other Behaviors, describes an interaction
Relationships
Associated with connected Behaviors
Examples
Conversation protocol, swimlane in enhanced activity diagram
II.
Modellierung
Das Behavioral Model ist einer anschaulichen grafischen Modellierung sehr zugänglich
und kann sich auf eine große Auswahl existierender Formalismen abstützen.
Die Modellierung einer Action hängt von ihrem Typ ab. Ein Physical Effect kann durch
die zur Beschreibung der Physical Layer verwendeten Formalismen angemessen
beschrieben werden. Die Spezifikation eines Mental Effect hängt dagegen von der für
Position und Schedule eingesetzten Modellierungsmethode ab, die wiederum aus dem
Mental Model übernommen werden dürfte.
– 139 –
Physical
Effect
n,t
Position
Schedule
(0,n)
(0,n)
references
references
Mental
Effect
Action
(0,n)
Spontaneous
Behavior
comprises
d,t
Conditioned
Behavior
(0,1)
(0,1)
(1,n)
Composition
Manifestation
(0,n)
(0,n)
Behavior
n,t
(0,n)
Deliberation
(0,n)
Interweaving
Solitary
Behavior
d,t
Interactive
Behavior
Abbildung 3.17 Elementbeziehungen innerhalb des Behavioral Model
Das Behavior selbst kann mit einem beliebigen Formalismus ausgedrückt werden, der
die Angabe von Aktionen und Bedingungen erlaubt. Denkbar sind natürlichsprachige
Beschreibungen, Automatenmodelle, Aktivitätsdiagramme, Netzpläne, Pseudocode oder
ausführbare Spezifikationen.
Das Strukturmodel des Behavioral Model umfaßt nur sehr wenige ´Typen und Beziehungen und wird vor allem durch die große Zahl der Untertypen geprägt. Trotz seiner
scheinbaren Einfachheit sind die Zusammenhänge innerhalb des Teilmodells in der
Anwendung jedoch komplex, da hier ein großer Teil der Dynamik und Komplexität des
Systems erfaßt wird.
– 140 –
In einem agentenbasierten Produktionsplanungs- und Steuerungssystem (PPSSystem) existieren Agenten, die Aufträge repräsentieren (Job Control Agent) und
solche, die Ressourcen, hier im Besonderen Maschinen vertreten (Machine Control
Agent). Jeder Job Control Agent verfügt über eine Auftragsnummer und ein Arbeitsprogramm, das es umzusetzen gilt. Weiterhin wird er mit einem gewissen Startkapital an
Credits versehen, mit denen er Ressourcen kaufen kann. Jeder Machine Control Agent
ist einer bestimmten Maschine zugeordnet. Er führt über die noch verfügbare Maschinenlaufzeit Buch und verfolgt das Ziel, den Betrag der eingenommenen Credits zu
maximieren.
Im untenstehenden Diagramm ist vereinfacht eine konkrete Interaktion zwischen zwei
Agenten modelliert. Der Job Control Agent für Lot E-230-C18 muß eine Charge Achsen
herstellen lassen, wozu er laut Plan 1:23 h Maschinenlaufzeit auf einer CNCDrehmaschine benötigt. Er hat bereits etabliert, daß der Agent CNC B-12 eine passende
Maschine repräsentiert. Im Rahmen des Spontaneous Behaviors Acquire Ressource
schickt er daher eine entsprechende Anfrage. Deren Erhalt (in Form eines Cognitive
Statement) löst beim Machine Control Agent ein entsprechendes Conditioned Behavior
aus. Er prüft die verfügbare Arbeitszeit und schickt ein entsprechendes Angebot zurück.
Der Job Control Agent nimmt das Angebot in einer entsprechenden Nachricht an.
Daraufhin überweist er die geforderten Credits, wodurch sich sein wahrgenommener
Bestand an Credits entsprechend verringert. Nach Erhalt der Zahlung korrigiert der
Machine Control Agent zunächst durch einen Mental Effect den Betrag der verfügbaren
Zeit und setzt sofort danach den Arbeitsauftrag durch eine entsprechende Action in die
Tat um, die sich auf den Einsatz der Maschine als Operative Effector abstützt. Das
Applied-Event des Effectors markiert die Fertigstellung des Auftrags und signalisiert
dem Job Control Agent die Erreichung seines Ziels.
Die Notation des Diagramms entspringt einer informellen Verwendung der oben
definierten Modellbegriffe. Agents (blaßrotes Dreieck) besitzen eine Position (drei
Kreise), die aus als Schlüssel/Attribut-Paare ausgedrückten Statements (Kreis) und
Aims (Kringel) besteht (alle hellgrün). Diese können jeweils Inherent (I), Cognitive (C)
oder Derived (D) sein. Die Behaviors (zwei Dreiecke, ocker) sind hier beide Manifestations (M). Actions (Ausrufezeichen, ocker) haben Physical Effect (P) oder Mental
Effect (M) und können Zeitgrenzen tragen.
– 141 –
Job Control Agent
Machine Control Agent
M Acquire Resource
P Send Message
Position
Professed Intention
I agent
me
I identifier
0 0
C message
query
D recipient
CNC B-12
C sender
Lot E-230-C18
D query
1:23 h
C query
1:23 h
Lot E-230-C18
C credits
150
I complete
C agent
M Provide Resource
CNC Lathe
C identifier
C credits
P Send Message
offer
0 5
C sender
CNC B-12
D recipient
Lot E-230-C18
C query
52 credits
D offer
52 credits
P Send Message
5 6
CNC B-12
1:23 h
C message
response
D recipient
CNC B-12
C sender
Lot E-230-C18
D respnse
accept
C respnse
accept
me
CNC B-12
D available
4:53 h
C credits
150
I credits
C agent
I requirement Axle C-56
I CNC Lathe
I agent
I identifier
C message
Axle C-56
Position
Professed Intention
-> max!
150 Axles
C identifier
Lot E-230-C18
D available
3:30h
98
P Transfer Credits
C amount
6 7
C credits
202
52
M Update Availabilty 7 7
C complete
Axle C-56
P Manufacture
C duration
Abbildung 3.18
7 15
1:23 h
Behaviors zweier Agenten in einem PPS-System
Die Einrückungen drücken eine hierarchische Unterordnung aus. Die Behaviors sind
jeweils von oben nach unten zu lesen. Durchgezogene Linien markieren Abfolgen,
gestrichelte Linien beschreiben Seiteneffekte, also im Besonderen die Korrelation
zwischen den Aktionen des einen und der Wahrnehmung des anderen Agenten. Die
gepunkteten Linien innerhalb der Position beschreiben die Aktualisierung eines
Elements. Bezüglich der Dynamik der Position ist die Modellierung hier im Sinne der
Modelldefinition insoweit unvollständig, als daß eigentlich auch alle anderen Statements im Rahmen des Behaviors, also etwa das Cognitive Statement zum Empfang der
Nachricht, expliziter Teil der Position werden.
3.3.2.3 Social Model
Innerhalb des Behavioral Model klang zwar bereits die Bedeutung des Prozesses der
Veröffentlichung von Behaviors und der Überprüfung ihrer Einhaltung an, diese
wurden jedoch noch nicht formalisiert. Diese Funktion wird vom Social Model
übernommen.
– 142 –
Im Rahmen des Social Model werden die jeweiligen Regeln beschrieben, die das
Verhalten eines Systems von Agenten auf konzeptioneller Ebene bestimmen. Die
‚Kultur’ einer solchen ‚Gemeinschaft’ umfaßt die definierten Rollen, Kommunikationssprachen, Gesetze und Konventionen.83 Die Begriffswelt des Teilmodells ist naturgemäß
soziologisch geprägt.
I.
Elemente
A.
Culture
Eine Culture charakterisiert eine Gruppe von Agenten, eine Community. Culture wird
hier nicht im ethnologischen, sondern im organisationssoziologischen Sinne verstanden.
Sie bezeichnet dort die Gesamtheit der Hypothesen, die eine Gruppe zur Lösung äußerer
Probleme und zur internen Koordination entwickelt hat (vgl. etwa [Strategor 1997, S.
470ff]).
Eine Culture beschreibt die Regeln eines Typs von Gemeinschaft, etwa eines elektronischen Marktplatzes, einer Demokratie, eines Unternehmens, eines Lehrstuhls, eines
persönlichen Assistenten und seines Benutzer oder eines Diskussionsforums.
Cultures können verschachtelte Strukturen besitzen und untergeordnete Cultures
(‚Subkulturen’) definieren.
Alle Teilnehmer eines (Roboter-)Fußballspiels sind Teil einer Gemeinschaft mit einer
gemeinsamen Culture, die etwa die Spielregeln diktiert. Innerhalb dieses Systems
definiert jede Mannschaft wiederum eine eigene Culture, etwa welches Spielsystem
gespielt wird und wer welche Position übernimmt.
Die Definition einer Culture kann weiterhin durch Vererbung wiederverwendet und
spezialisiert werden. Dabei ist zu unterscheiden, ob die ursprüngliche Culture nur als
Vorlage verstanden wird, wobei beliebige Umdefinitionen zulässig sind, oder ob die
83
Abbildung 3.19, S. 157, gibt einen Überblick über das Social Model.
– 143 –
abgeleitete Culture in einer Spezialisierungsrelation zum Ursprungstyp stehen soll,
wozu die Festschreibung bestimmter Invarianten erforderlich ist.
Eine Auktionsplattform kann nach dem Vorbild eines Konkurrenten ihre Geschäftsbedingungen definieren, dabei aber beliebige Änderungen vornehmen. Eine Fußballmannschaft kann zwar das allgemeine Modell einer Mannschaft an ihre Bedürfnisse
anpassen, aber dabei nicht beschließen, den Ball zukünftig mit den Händen zu führen.
Die Definition einer Culture umfaßt vor allem Rollen und Normen. Diese beantworten
wichtige Fragen, etwa, wie Mitgliedschaft in der Gemeinschaft definiert ist, welches
Verhalten sozial erwünscht ist, wie dies überwacht wird und mit welchen Sanktionen
sozial unerwünschtes Verhalten belegt wird. Dabei spielen auch Konventionen eine
wichtige Rolle, die festlegen, welche Handlungen welche Absichten implizieren.
Sprache ist eine spezielle Art der sozialen Konvention. Die Implikationen der Handlungen werden formal durch Professed Intentions beschrieben.
Eine soziale Konvention legt etwa fest, daß die Abgabe eines Gebots bei einer Auktion
ein Versprechen zum späteren Kauf ist. Eine Norm legt fest, daß der Agent bei Bruch
dieses Versprechens vom Marktplatz ausgeschlossen wird.
Die Beschreibung der Rollen ist wesentlich zur Erfassung des Zwecks und der Ziele
einer Gemeinschaft. Weiterhin definieren die Rollen Strukturen und Beziehungen
innerhalb der Gemeinschaft. Im Rahmen des Social Simulation Approach84 [Castelfranchi
1990] stellt Castelfranchi dabei im Besonderen die Bedeutung von Machtstrukturen
heraus, wobei er sich auf die soziologische Standarddefinition von Macht als „jede
Chance, innerhalb einer sozialen Beziehung den eigenen Willen auch gegen Widerstreben durchzusetzen, gleichviel worauf diese Chance beruht“ von Weber (vgl. etwa [Weiß
1989]) und nicht nur auf institutionalisierte Macht bezieht. Im Metamodell kann direkte
Machtausübung durch einen entsprechenden Context auf der Physical Layer oder die
Garantie reaktiver Conditioned Behaviors auf der Conceptual Layer abgebildet
84
Siehe Abschnitt 2.1.1, S. 9.
– 144 –
werden, indirekte Macht hängt etwa mit der Kontrolle von Resources und Facilities
oder Befehlsgewalt über dritte Agenten mit entsprechenden Kompetenzen zusammen.
Element Summary
Culture
Hierarchical Name
Conceptual.Culture
Definition
A shared set of rules and concepts shared by a group of Agents
Relationships
Adopted by Community
Defines Roles, Language, Norm, Professed Intention
Examples
B.
Company guidelines, marketplace rules, team hierarchy
Role
Die von einer Culture festgelegten Rollen werden durch Roles beschrieben. Eine Role
ist immer nur im Rahmen einer Culture zu verstehen, kann aber durchaus auch von
mehreren Cultures verwendet werden.
Die Rolle des Kapitäns ist sehr unterschiedlich definiert, je nachdem ob sie sich auf ein
Schiff bzw. Flugzeug oder eine Fußball- oder Handballmannschaft bezieht.
Roles können genau wie Cultures umdefiniert und verfeinert werden, wobei wiederum
zu unterscheiden ist, ob die Role nur als Vorlage dient oder generischer Obertyp sein
soll.
Eine Role ist im Kern eine Menge Behaviors, die unter diesem Namen zusammengefaßt
sind. Durch das Übernehmen einer bestimmten Rolle erklärt ein Agent, daß er den
dadurch definierten Verhaltensmustern entsprechen wird. Die Bedingungen für die
Anwendung der einzelnen Behaviors sollten eindeutig und widerspruchsfrei sein. Im
Zweifel können Roles hierzu Meta-Behaviors im Stil der im nächsten Abschnitt
beschriebenen Rules definieren, die im Fall von Konflikten oder Zweideutigkeiten die
Auswahlkriterien klarstellen.
Die Verzeichnisdienstrolle in einem Multiagentensystem definiert zwei Behaviors: auf
den Empfang einer Anmeldung reagiert sie mit der Erstellung eines Registrierungseintrages, auf eine Anfrage durch die prompte Rückgabe des gesuchten Eintrages.
– 145 –
Wie einführend beschrieben wurde, werden in Verbindung mit einem evolutionären
Verständnis der Agentenorientierung Rollen oft als Entsprechung zum Begriff des
Interface in der Objektorientierung gesehen. Dies ist aus Sicht des Metamodells
durchaus haltbar. Ebenso wie ein Objekt mehrere Interfaces implementieren darf, kann
ein Agent mehrere Rollen gleichzeitig spielen. Sein Profil muß allerdings nicht statisch
sein, sondern kann unter Umständen nach Maßgabe sozialer Normen durch Annehmen
und Ablegen von Roles verändert werden. In aktuellen Softwaresystemen dürfte
allerdings die Obermenge der Roles, die ein bestimmter Agent potentiell spielen kann,
zum Zeitpunkt der Erstellung bereits festgelegt sein.
Roles können bestimmte Garantien, Rechte, Pflichten und Beschränkungen mit sich
bringen. Formal wird dies durch eine Assoziation mit Professed Intentions, die unten
detailliert eingeführt werden, ausgedrückt.
Darüber hinaus können mit einem bestimmten Zweck, ihrem Purpose, assoziiert sein,
der im Rahmen des Application Model näher beschrieben85 wird.
Element Summary
Role
Hierarchical Name
Conceptual.Role
Definition
A named and structured set of Behaviors
Relationships
Consists of Behaviors
Committed to by Agent
Associated with Professed Intentions
May have Purpose
Examples
C.
Buyer, Seller, Officer, Forward, Directory,
Norm
Eine Norm ist ganz allgemein jede explizite Festlegung zur Koordination der Struktur
und des Verhaltens in einer Culture. Dies schließt zum einen strukturelle Regeln wie
etwa die Festschreibung von Kardinalitäten oder notwendigen Beziehungen ein, zum
anderen Verhaltensmaßregeln im Sinne von Meta-Behaviors oder im Stil sozialer
Konventionen zur Interpretation von Verhalten und Nachrichten.
85
Siehe Purpose, S. 162.
– 146 –
Ein Schachspiel wird durch strukturelle Regeln (es gibt 64 Felder, schwarze und weiße
Figuren und jeweils 8 Bauern, einen König usw.), Rollen (die Figurentypen) mit
assoziierten Verhaltensweisen (Zugmöglichkeiten der Figurentypen), Verhaltensregeln
über erlaubte Züge und Ausgang des Spiels (eigene Figuren können nicht geschlagen
werden, Rochade ist nicht beim Ziehen durch ein Schachgebot möglich, dreimalige
Stellungswiederholung führt zu Remis) und soziale Konventionen (Umlegen des Königs
signalisiert Aufgabe) definiert.
Bei der Definition sozialer Normen ist die Frage von grundlegender Bedeutung, wer der
Adressat dieser Spezifikation ist. Normen können sich nur als Implementierungsrichtlinien an den – möglicherweise mit dem Modellierer identischen – Entwickler richten,
der sie dann implizit bei der Gestaltung des Systems berücksichtigt. Bei größeren
Projekten oder offenen Systemen erfordert dies eine systemexterne Evaluation der
Konformität, etwa durch ein Audit des Quellcodes. Alternativ kann, sofern das damit
verbundene Risiko tragbar ist, die Korrektheit der Implementierung auch erst zur Zeit
der Anwendung durch externe Beobachtung überprüft werden.
Ergänzungen zu kritischen geschlossenen Systemen wie etwa Produktionssteuerungen
werden vor dem praktischen Einsatz intensiv auf ihren Einfluß auf das Gesamtsystem
und ein der Intention des Entwurfs entsprechendes Verhalten überprüft werden. Der
Betreiber einer Auktionsplattform wird bei Hinweisen auf Regelverstöße die Protokolle kontrollieren, delinquente Agenten ausschließen und von dem verantwortlichen
Unternehmen Korrekturen und Wiedergutmachung verlangen.
Andererseits können Regeln auch im Kontext des Systems überprüft werden, was ihre
Abbildung auf die Physical Layer erfordert. Dabei ist nicht relevant, in welcher Form
die Regeln im System kodiert sind. Im Allgemeinen werden sie implizit im Entwurf des
Entity Model umgesetzt sein, denkbar sind jedoch auch eine explizite Darstellung der
Regeln und ihre Verarbeitung durch einen geeigneten Parser. Wichtig ist hingegen, wie
ihre Einhaltung überwacht wird, also sowohl, wie sie überprüft wird, als auch, wie sie
durchgesetzt wird. Eine zentralisierte Überwachung erscheint für Agentensysteme
vergleichsweise untypisch, da eine monolithische Wächterinstanz der Philosophie der
Verhaltensdekomposition zuwiderläuft und ein schwer handhabbares Maß an Komplexität an einer zentralen Stelle bündelt. Viele Regeln werden direkt durch Contexts auf
– 147 –
der Physical Layer umgesetzt werden, so daß verbotenes Verhalten gar nicht erst
möglich ist. Strukturelle Regeln können durch einen Enforcement Process garantiert
werden, der auch zur direkten Ahndung bestimmter Übertretungen verwendet werden
kann. Abstraktere Regeln können durch soziale Kontrolle geschützt werden, wobei die
Existenz von als inhärent vertrauenswürdig betrachteten Agenten hilfreich sein kann. Es
können auch dedizierte Agenten vorgesehen werden, die die Beachtung bestimmter
Teilaspekte des Regelwerks überprüfen und die Fähigkeit besitzen, geeignete Sanktionen zu verhängen. Zuletzt können Regeln auch durch eine freiwillige Selbstkontrolle
umgesetzt werden.
Ein Enforcement Process kann eine Suchanfrage, die die ihr zum Kauf von Rechenzeit
und anderen Ressourcen mitgegebenen Credits verbraucht hat, von einem Server
löschen. Soziale Systeme können etwa ein Rufsystem implementieren, in dem nichtkonforme Agenten sozial geächtet oder sogar aus der Agentengemeinschaft ausgeschlossen werden. Agenten merken selbst, wenn sie Opfer regelwidrigen Verhaltens,
etwa eines Vertragsbruches, werden und publizieren dies. Viele aktuelle soziale
Systeme beruhen auf einer Selbstkontrolle der Agenten, die beispielsweise zwar
Versprechen brechen dürfen, dafür aber dann eine Vertragsstrafe zahlen müssen.
Element Summary
Norm
Hierarchical Name
Conceptual.Norm
Definition
A social law
Relationships
Defined by Culture
Interprets Professed Intention
Grounding
May be implemented by an Enforcement Process
Examples
Chess is played by ‘black’ and ‘white’, with 16 pieces each. White moves first.
i.
Axiom
Eine strukturelle Regel wird als Axiom bezeichnet. Sie muß zwangsläufig erfüllt sein,
damit eine Gemeinschaft zu einer bestimmten Culture konform ist. Axioms quantifizieren häufig erforderliche Mengenrelationen bestimmter sozialer Elemente.
– 148 –
Eine Fußballmannschaft umfaßt 11 Spieler. Auf dem Marktplatz gibt es immer
mindestens einen Auktionator. Alle Mitglieder der Handelsplattform müssen zertifiziert sein. Keine zwei Agenten können die Datenbankverwalterrolle gleichzeitig
innehaben. Jeder Agent vertritt einen Benutzer.
Die Überprüfung von Axioms ist in der Regel weitgehend unproblematisch, da sie in
ihrem Anspruch nicht über die Erfordernisse klassischer Softwaretechnik oder Mengenlogik hinausgeht. Axioms können allerdings auch Entwurfsprinzipien sein, die weitergehende Garantien auf inhaltlicher Ebene beschreiben, deren Einhaltung nicht mehr
trivial ersichtlich ist.
Alle Agenten sind aufrichtig, d.h. ihre Position und ihr Outlook sind nicht im Widerspruch. Jeder Produktionsauftrag muß immer genügend Credits zurückbehalten, um
seine Fertigstellung zu Minimalpreisen finanzieren zu können.
Element Summary
Axiom
Hierarchical Name
Conceptual.Norm.Axiom
Definition
A Norm constraining the static structure and guarantees of the Culture
Examples
There is at least one coordinator in a team. Agents are truthful.
ii.
Rule
Eine Norm, die im Stil eines Gesetzes das Verhalten von Agenten einschränkt und
vorschreibt, wird als Rule bezeichnet. Rules beschreiben häufig auf einer Metaebene
Verhalten in Form von Behaviors. Sie können zum einen Konsequenzen bestimmter
Handlungen festschreiben, zum anderen definieren, welche Handlungen überhaupt
möglich sind.
Abweichen von den Behaviors einer publizierten Rolle führt zu Ausschluß aus der
Gemeinschaft. Das Behavior ‚Rücknahme eines Versprechens’ impliziert das Behavior
‚Zahlung einer Vertragsstrafe’. Wenn ein Agent ein Angebot veröffentlicht hat, kann er
es nicht mehr zurückziehen, bis seine Gültigkeit regulär abgelaufen ist.
Rules können dabei oft in ähnlicher Weise wie Behaviors beschrieben werden, können
aber zusätzlich auf der Ebene von Roles, Behaviors und Professed Intentions argumentieren. Die Überprüfung von Rules ist in der Regel um Größenordnungen komplexer als
– 149 –
die der Axioms, da hier nicht nur ein einzelner Zustand, sondern ein kompletter Ablauf
in Form seiner signifikanten Zwischenzustände betrachtet werden muß.
Eine Rule kann auch eine Konvention im bereits beschriebenen Sinne sein.
Das Abgeben eines Gebotes impliziert das Versprechen, einen Kauf zu tätigen.
Das System der Rules muß nicht zwangsläufig statisch sein. Komplexere soziale
Modelle können dessen Adaption an sich ändernde Umstände erfordern (vgl. etwa
[Excelente-Toledo et al. 2001]). Rules höherer Ordnung, die die Anwendbarkeit anderer
Rules in Abhängigkeit vom Systemzustand beschreiben, können diese Anforderungen
erfüllen.
Element Summary
Rule
Hierarchical Name
Conceptual.Norm.Rule
Definition
A Norm constraining the dynamics of the Culture through meta-behaviors
Examples
Breaking a promise costs a penalty. A permission cannot be revoked.
iii.
Language
Eine Language ist ganz allgemein die vereinbarte Definition der Bedeutung bestimmter
Zeichen, also einer Semantik. Sie bildet den konkreten Inhalt von Messages auf eine
Ontologie ab. Zudem kann sie auch im Sinne des oben verwendeten Konventionsbegriffs eine pragmatische Interpretation des Inhalts als Professed Intention vorschreiben.
KQML und FIPA ACL beschreiben die Bedeutung verschiedener Klassen von
Sprechakten und gehen dabei im Besonderen auf den beabsichtigten Effekt ein.
Der Begriff der Language ist hier aber im Grunde enger gefaßt als bei den meisten
ACLs, da er nur die Umsetzung in Cognitive Statements und Professed Intentions
beinhaltet und nicht auch die Definition der eigentlichen Ontologie oder der sozialen
Implikationen bestimmter Aussagen einschließt.
Element Summary
Language
Hierarchical Name
Conceptual.Language
Definition
Specification of the semantics of Messages
Formalisms
Natural language, formal logic
Examples
KQML, FIPA-ACL, mapping of method imvocations to Professed Intentions
– 150 –
D.
Professed Intention
Als letztes Element des Social Model soll nun die Professed Intention definiert werden,
deren Bedeutung sich schon in den Beschreibungen aller anderen Elemente angekündigt
hat.
Eine Professed Intention ist als Willenserklärung im juristischen Sinne zu verstehen.
Sie ist ein wichtiges Instrument, um bei der Verwendung des Konzepts des sozialen
Systems als Analogie für ein Multiagentensystem sinnvoll argumentieren zu können.
Auch für das Konzept des Legal Stance ist sie von zentraler Bedeutung.
Die Professed Intention erlaubt es nun, zu formalisieren, was damit gemeint ist, wenn
Agenten ‚Versprechen’ machen, Vorhaben ‚publizieren’ oder ‚Garantien’ geben. Ganz
allgemein gesehen ist eine Professed Intention eine öffentlich gemachte Aussage eines
Agenten, die das verfügbare Wissen der Gemeinschaft über seine mentalen Einstellungen erweitert.
Was eine Professed Intention ist, wird allein durch soziale Konventionen festgelegt. Sie
k a n n sich auf einen Sprechakt im klassischen Sinne beziehen, es kann sich dabei
jedoch auch um jede andere Aktion eines Agenten handeln. Die Essenz der Professed
Intention ist aber nicht der eigentliche Akt, sondern sein Ergebnis, das den Akt
dokumentiert.
Dies lehnt sich an die juristische Festlegung an, daß bestimmte Willenserklärungen der
Schriftform bedürfen. In Softwaresystemen, in denen es überhaupt keine im eigentlichen Sinne mündliche Kommunikation gibt, ist eine solche Anforderung trivial erfüllt.
Jede Professed Intention läßt sich auf Entities der Physical Layer zurückführen, was
auch explizit modelliert werden sollte.
Wird die Migration auf einen Server als Anerkennung der dortigen Geschäftsbedingungen akzeptiert, dokumentiert die Anwesenheit des Agenten diese Aussage. Sprechakte
sind durch die Messages dokumentiert, in denen sie ausgedrückt sind.
– 151 –
Dabei wird nicht verlangt, daß die Manifestationen der Professed Intentions persistent
gespeichert werden, etwa in einem Audit Trail ausgetauschter Nachrichten. Sieht der
Entwurf des Systems allerdings die Möglichkeit zu Konflikten, speziell Dispute
bezüglich unterstellter Professed Intentions, vor, sind entsprechende Aufzeichnungen
Voraussetzung für deren gerechte Beilegung.
Die sozialen Implikationen der Professed Intentions werden wiederum durch Norms
festgelegt, so daß deren genaue Bedeutung im Ermessen des Modellierers liegt. Um
aber bereits mit den Begriffen des Metamodells eine expressive Systembeschreibung zu
ermöglichen, wird schon eine Einteilung in sieben generische Klassen von Professed
Intentions umrissen. Diese spiegeln die grundlegenden Typen von Aussagen, die
Agenten kommunizieren können, wider, wie sie auch bei der Definition von ACLs
relevant sind. In Anlehnung an die von Singh86 identifizierten Sprechaktklassen wird hier
daher zwischen Assertion, Directive, Commitment, Permission, Interdiction, Declaration und Expression unterschieden. Diese werden in eigenen Unterabschnitten kurz
vorgestellt werden.
Bei der konzeptionellen Betrachtung des Systems lassen sich die Begriffe zunächst
intuitiv verwenden. Bei der Implementierung ist dann wie in Verbindung mit Norms
dargelegt zu entscheiden, ob diese abstrakt bleiben oder zur Laufzeit abfragbar umgesetzt werden sollen.
Existiert etwa eine Permission, die einem Agenten Zugriff auf eine Datenbank gewährt,
ist damit öffentlich auf der abstrakten Ebene klargestellt, daß der Versuch des Agenten,
einen Lesezugriff auf die Datenbank in seine Schedule einzufügen, zulässig ist.
Vor dem Hintergrund der Zielsetzung eines Brückenschlags zwischen KI und Softwaretechnik ist die Frage nach der exakten Definition einer sozialen Semantik und der
Abstützung auf das konkrete System von wesentlicher Bedeutung. Dies wird durch das
Metamodell zum einen unter Verwendung des Behavioral Model, zum anderen durch
die Verknüpfung der Professed Intentions mit Entities geleistet.
86
Siehe Abschnitt 2.3.4, S. 32.
– 152 –
Ein Agent trägt sich mit einem Physical Effect in Form eines Operative Effector in
einem Verzeichnis (Entity) als ein Broker ein. Dies wird durch eine Norm als Commitment an die Role Broker interpretiert. Dadurch verspricht der Agent also bestimmte
Behaviors, die etwa definieren, wie und in welchem Zeitrahmen er auf Vermittlungsgesuche reagieren wird. Andere Agenten können nun mit ihren Sensors den
Verzeichniseintrag wahrnehmen. Durch den Filter der sozialen Konvention gesehen
ergibt sich daraus ein entsprechendes Cognitive Statement, das das Commitment des
Agenten beinhaltet und somit anderen Agenten erlaubt, Erwartungen an sein Verhalten
zu formulieren.
Die abstrakte Bedeutung der Professed Intention wird erschöpfend allein mit den
Elementen der Conceptual Layer beschrieben. Auf diese Weise kann bei der Konzipierung mit aussagekräftigen abstrakten Konstrukten gearbeitet werden. Durch die
nachfolgende Abstützung auf die Elemente der Physical Layer wird jedoch die Gefahr
vermieden, Aussagen über das System machen zu wollen, die zur Laufzeit überhaupt
nicht möglich sind.
Die Idee einer Willenserklärung setzt zwingend voraus, daß die Erklärung von einer
Person abgegeben wird. In diesem Sinne ist auch jede Professed Intention einem
Urheber zugeordnet. Dies bezieht sich zunächst offensichtlich auf den Agenten, der mit
Effectors und durch den Versand von Messages direkt die Professed Intention bedingt.
Jedoch erscheint es zweckmäßig, auch den (menschlichen) Benutzern implizite oder an
explizite Eingaben gebundene Professed Intentions zuschreiben zu können, in denen
sie den Agenten etwa Aufträge (Directives) geben oder sie zu bestimmten Handlungen
autorisieren (Permissions). In diesem Sinne können einem Agenten oder einer bestimmten Role auch, vergleichbar mit Inherent Statements, vom Modellierer schon bestimmte Professed Intentions implizit mit auf den Weg gegeben werden.
Element Summary
Professed Intention
Hierarchical Name
Conceptual.Profession
Definition
The socially agreed interpretation of an Agent’s actions
Examples
Commitment to a role, permission to perform an action
– 153 –
i.
Explicitly Professed Intention
Eine Explicitly Professed Intention ist eine Professed Intention, die durch eine
Nachricht explizit geäußert wird. Sie entspricht somit einem klassischen Sprechakt. Ihre
Interpretation hängt von einer Language ab. Dokumentiert wird sie durch die entsprechende Message.
Element Summary
Explicitly Professed Intention
Hierarchical Name
Conceptual.Profession.Explicit
Definition
A Professed Intention expressed and documented by a Message
Relationships
Depends of Language
Grounding
Message
Examples
Sending a message, emitting a speech act
ii.
Implicitly Professed Intention
Eine Implicitly Professed Intention ist eine Professed Intention, die aus dem Verhalten
des Agenten abgeleitet wird. Sie wird in der Regel durch eine einzelne Action definiert
sein, kann jedoch auch von einem vollständigen komplexen Behavior abhängen, dessen
Ausführung eine bestimmte Absicht nahelegt. Implicitly Professed Intentions werden
durch Norms bzw. speziell Rules definiert und durch beobachtbare Änderungen an
beliebigen Entities dokumentiert.
Element Summary
Implicitly Professed Intention
Hierarchical Name
Conceptual.Profession.Implicit
Definition
A Professed Intention associated with behavior, documented by an Entity
Relationships
Associated with Action, Entity
Grounding
Modified Entity
Examples
Manipulating an Entity, performing a Behavior
iii.
Assertion
Eine Assertion ist die Erklärung eines Agenten, daß er eine bestimmte Aussage für wahr
hält. Sie ist eine Art öffentliches Glaubensbekenntnis, in dem ein Agent einen Teil
seines Outlook publiziert. Gegenstand einer Assertion ist somit ein Statement. Der
Agent erklärt durch eine Assertion, daß er dieses Statement für wahr hält, wodurch es
sich seiner Position zuschreiben läßt. Kann der Position gleichzeitig ein gegenteiliges
Statement zugeschrieben werden, lügt der Agent.
– 154 –
Assertions sind die wohl häufigste Klasse von Professed Intentions. Ein Großteil des
Informationsaustausches zwischen Agenten basiert auf ihnen.
Die Funktion eines Verzeichnisagenten hängt davon ab, daß andere Agenten seinen
Versicherungen bezüglich der Eigenschaften anderer Agenten vertrauen können.
Vertrauen ist ein wichtiger Aspekt von Assertions. Ein Agent verbürgt mit den Assertions, die er abgibt, seine Autorität und Vertrauenswürdigkeit. Wie Assertions vom
Empfänger in Cognitive Statements umgesetzt werden, hängt von seiner Einschätzung
der Vertrauenswürdigkeit des Urhebers ab.
Element Summary
Assertion
Hierarchical Name
Conceptual.Profession.Assertion
Definition
A Professed Intention asserting a Statement
Examples
The stock price is $4.30. This statement is true. We come in peace.
iv.
Directive
Eine Directive weist einen Agenten an, ein bestimmtes Behavior, also eine Folge von
Actions, auszuführen. Diese kann von anderen Agenten oder im Besonderen auch von
Seiten eines Benutzers ausgesprochen werden. Die zentrale Frage ist hier, ob der
Empfänger der Directive zur Kooperation bereit ist bzw. dies vorab etwa durch ein
Behavior veröffentlicht hat, oder ob der Urheber notfalls die nötige Macht besitzt, um
die Durchsetzung seiner Directive zu erzwingen.
Element Summary
Directive
Hierarchical Name
Conceptual.Profession.Directive
Definition
A Professed Intention asking another Agent for an Action
Examples
Return the requested information! Perform an action!
v.
Commitment
Ein Commitment ist eine Garantie eines Agenten bezüglich seines zukünftigen Verhaltens. Es ist etwa ein Versprechen, mit dem sich ein Agent an eine bestimmte Role
bindet, wodurch er anderen Agenten mitteilt, daß er den enthaltenen Verhaltensmustern
zu entsprechen gedenkt. Gerade Commitments sind häufig im Entwurf des Systems
impliziert. Sie bieten aber gleichzeitig den Mechanismus, der es Agenten erlaubt, zur
Laufzeit dynamisch Roles zu übernehmen.
– 155 –
Commitments sind nicht auf Roles beschränkt, sondern können sich in Abhängigkeit
von der gewünschten Granularität auch direkt auf Behaviors oder einzelne Actions
beziehen. Dabei kann ein Agent sich sowohl an generische Spezifikationen binden, etwa
die Beschreibung der notwendigen Vorbedingungen für eine bestimmte Action, als auch
an eine konkrete Instanz eines Behaviors oder einer Action, die sich somit in seiner
Schedule niederschlägt.
Die Unterscheidung zwischen generischen und konkreten Behaviors ist besonders von
Interesse, wenn Commitments zurückgenommen bzw. gebrochen werden sollen. Die
Zuwiderhandlung gegen ein versprochenes generisches Behavior unterläuft die
Spezifikation des Systems und stellt in den meisten Fällen unerwünschtes Verhalten dar.
Die Verletzung eines konkreten Versprechens kann dagegen durchaus als konstruktives
Element im Entwurf des Systems vorgesehen werden (vgl. etwa [Hogg/Jennings 1997])
und kann durch eine entsprechende Rule erfaßt werden. Ziel der Verhaltensspezifikation ist es, die ‚Ausnahmen’ auf eine möglichst konkrete Ebene zu verlagern.
Element Summary
Commitment
Hierarchical Name
Conceptual.Profession.Committment
Definition
A Professed Intention promising a Statement
Examples
Commitment to a role, promise to deliver a service
vi.
Permission
Eine Permission erlaubt einem Agenten eine Handlung – also die Ausführung bestimmter Actions im Environment. Inwieweit der die Erklärung abgebende Agent berechtigt
ist, dies zu erlauben, ist wieder eine Frage des Systems und seiner Norms. Eine
Permission kann auf allen Ebenen des Systems umgesetzt sein, sei es durch Zugriffsrechte auf der Ebene von Entities oder soziale Kontrolle.
Element Summary
Permission
Hierarchical Name
Conceptual.Profession.Permission
Definition
A Professed Intention allowing an Action
Examples
You have access to all files on the server. You may bid on this auction.
vii.
Interdiction
Eine Interdiction ist ein Verbot. Sie untersagt einem Agenten die Ausführung bestimmter Actions. Inwieweit ein Verbot bindend wirkt, hängt von der Autorität ihres Urhebers
und den Möglichkeiten des Systems ab. Implementiert der Entwickler eine Interdiction
– 156 –
auf der Physical Layer, so ist sie zwangsläufig unumstößlich. Kann ein Agent aufgrund
besonderer Rechte das Verbot durch Änderungen auf der Physical Layer durchsetzen,
ist es in der Regel ebenfalls bindend. Wird es dagegen durch Rules auf der Concepetual
Layer gestützt, kann nur seine Übertretung geahndet werden. Wird es überhaupt nicht
umgesetzt, ist es nur symbolisch.
Element Summary
Interdiction
Hierarchical Name
Conceptual.Profession.Interdiction
Definition
A Professed Intention prohibiting an Action
Examples
Access to database revoked. You may not send me any messages.
viii.
Declaration
Eine Declaration ist ein Sprechakt im reinsten Sinne. Technisch gesehen ist sie einfach
ein neues Statement, das mit seiner Abgabe wahr wird, sofern ihr Urheber über die
notwendige Autorität verfügt. Da Declarations sich oft etwa in Verzeichniseinträgen
niederschlagen, läßt sich diese Frage oft auf die Frage reduzieren, ob der Agent die
notwendigen Permissions besitzt, um den Eintrag an der relevanten Stelle vornehmen
zu können.
Element Summary
Declaration
Hierarchical Name
Conceptual.Profession.Declaration
Definition
A Professed Intention stating a declaration
Examples
I christen you to the name…; Game over!
ix.
Expressions
Eine Expression dient dem Ausdruck von Bewertungen und Emotionen. Im Grunde
genommen ist sie einfach ein Statement mit unklarem Wahrheitsgehalt. Die erwartete
Reaktion seitens anderer Agenten ist zumeist nicht klar definierbar. In aktuellen
Systemen mit ihrer schwach ausgeprägten verbalen und sozialen Intelligenz ist diese
Klasse noch weitestgehend verzichtbar.
Element Summary
Expression
Hierarchical Name
Conceptual.Profession.Expression
Definition
A Professed Intention expressing an emotion or an assessment
Examples
I wish it were night! What a terrible color!
– 157 –
II.
Modellierung
Das Social Model ist für die Beschreibung des Systemverhaltens von zentraler Bedeutung. Viele innovative Konzepte zur Koordination komplexer Agentensysteme, etwa zur
verteilten Optimierung des Gesamtnutzens (vgl. [Hogg/Jennings 1997,4]) oder zur
Verhinderung von parasitärem Verhalten in kooperativen Systemen (vgl. [Kalenka
2001]), werden auf dieser Ebene formuliert.
expressed in
Explicit
(1,n)
d,t
(0,n)
Implicit
(1,n)
Language
Norm
d,t
Rule
Assertion
Axiom
Directive
(0,n)
(0,n)
sets
interprets
Commitment
Structure
Structure
(0,n)
(0,n)
(0,n)
(0,n)
Role
(0,n)
(0,n)
(0,n)
defines
(0,n)
Culture
defines
(0,n)
(0,n)
Professed
Intention
d,t
Permission
(0,n)
(1,n)
(0,n)
associated with
Interdiction
guarantees
Declaration
(0,n)
Behavior
(0,n)
consists of
(0,n)
Action
(0,n)
implied by
Expression
Abbildung 3.19 Elementbeziehungen innerhalb des Social Model
Die Beschreibung der Roles und eingeschränkt auch der Rules kann auf die aus dem
Behavioral Model bekannten Mechanismen zurückgreifen. Zur Modellierung komplexerer sozialer Zusammenhänge existieren allerdings nur wenige, schon gar nicht
grafische Formalismen, da in ihren Ursprungsdisziplinen, den Rechtswissenschaften
und der Soziologie, der Schwerpunkt auf rein verbalen Beschreibungen liegt. Die
Umsetzung entsprechender Konzepte in logisch-mathematische Modelle ist zwar in
verschiedenen Fällen bereits erfolgreich geleistet worden, jedoch nicht unbedingt
– 158 –
trivial.87 In diesem Bereich liegt allerdings auch ein großer Teil des Potentials der
Agententechnologie.
3.3.2.4 Application Model
Das Application Model88 ist der letzte Baustein des Metamodells. Es bietet eine
gesamtheitliche (top down) Sicht auf das System und ordnet die Teilmodelle der
Conceptual Layer in ein Gesamtkonzept ein. Auf dieser Ebene werden nicht nur die
Gemeinschaften und Agenten des Systems definiert, sondern auch seine Ziele aus
Benutzersicht beschrieben. Bei der Modellierung konkreter Anwendungen werden seine
Elemente in vielen Fällen der Ausgangspunkt der Betrachtung sein.
I.
Elemente
A.
Agent
Ein Agent auf der konzeptuellen Ebene beschreibt die abstrakte Spezifikation eines
Agent auf der Physical Layer. Der Begriff selbst ist, abgesehen von der abstrakten
Identität des Agenten und einer etwaigen Beschreibung, vollkommen inhaltsleer. Der
Agent wird völlig durch seine Beziehungen beschrieben. Relevant ist er vor allem als
Besitzer einer Agent Personality, Träger bestimmter Roles, Urheber von Professed
Intention, Mitglied einer Gemeinschaft oder Vertreter eines Benutzers. Agent wird hier
als rein ideeller Begriff verwendet, so daß eine strikte Trennung zwischen Typen und
Instanzen in der Regel nicht vordringlich erscheint. Der Begriff Agent umfaßt also
sowohl die Class, eine ganze Klasse von Agenten, die auf der Physical Layer durch
einen Type umgesetzt wird, als auch das Individual, einen konkreten Agent. Die
jeweilige Verwendung sollte aus der Bezeichnung und dem jeweiligen Kontext deutlich
werden.
87
Der Erfolg der Suchmaschine Google beruht etwa darauf, daß durch ihren Algorithmus erfolgreich das
Konzept der Weiterempfehlung bzw. der Mundpropaganda mathematisch formalisiert und operationalisiert wird [Page et al. 1998].
88
Die Elemente des Application Model werden in Abbildung 3.20, S. 165, zusammengefaßt.
– 159 –
Element Summary
Agent
Hierarchical Name
Conceptual.Agent
Definition
Conceptual representation of an agent instance
Relationships
Member of Community
Owned by User
Fulfills Purpose
Carries Agent Personality
Implemented by Agent Core
Commits to Roles and Behaviors
Utters Professed Intentions
Grounding
Physical.Agent or Type
Examples
A marketplace member, a chat agent, …
B.
Community
Eine Community formalisiert den bereits verwendeten Gemeinschaftsbegriff. Sie ist
zum einen eine Menge von Agents, zum anderen die Instanz einer Culture.
Die Community ist ein wichtiges ordnungsstiftendes Element. Da sie konkreter Träger
der sozialen Regeln und Konventionen einer Culture ist, können Agenten nur durch
Mitgliedschaft in einer Community kommunizieren und koordiniert interagieren.
Weiterhin definieren die Hierarchie und anderen Beziehungen zwischen Communities
die Struktur und das generelle Verhalten des Systems.
Das bereits angeführte Fußballspiel ist als Community von 22 Spielern und den
Schiedsrichtern zu sehen, innerhalb derer zwei untergeordnete Communities von je 11
Spielern gegenläufige Ziele verfolgen.
Dabei sind Agents und Communities die strukturellen Bausteine des Gesamtsystems.
Wo dies angebracht erscheint, kann eine Community in ihrer Eigenschaft als Menge
von Agents auch agententypische Beziehungen eingehen. Zum einen ist es denkbar, daß
eine Community nicht nur in einer anderen Community als Teilmenge enthalten ist,
sondern dort selbst explizit als Mitglied auftritt. Zum anderen ist es denkbar, daß eine
Community selbst Professed Intentions abgibt. Diese können entweder so definiert
sein, daß sie für a l l e Agents der Community bindend sind, oder lediglich garantieren,
daß mindestens e i n Agent sie honorieren wird. Eine solche Verwendung des Begriffs
lehnt sich an das Prinzip der juristischen Person an. Ganz im Sinne dieser Analogie
– 160 –
kann dies praktisch so umgesetzt werden, daß stellvertretend für die Community ein
designierter Agent handelt.
Ein verteilter Verzeichnisdienst, etwa das System der DNS Root Server des Internet,
garantiert, daß jedes Mitglied der Gruppe unkompromittierte Informationen liefert. Er
garantiert weiter, daß bei einer undifferenzierten Anfrage an die gesamte Gruppe
(Broadcast) mindestens bzw. genau ein Server antworten wird.
Daneben kann eine Community auch eine wichtige Rolle auf der Ebene der Kommunikation spielen. Die Mitglieder einer Community müssen sich nicht zwangsläufig im
selben Environment befinden, so daß der Begriff es erlaubt, den kommunikativen
Kontext eines Agenten auch über die Grenzen seines Environment hinaus zu beschreiben. In diesem Sinne ergibt sich eine sehr praxisnahe Definition der Community als die
Menge der als ihre Mitglieder adressierbaren Agenten.
Eine von Agenten abonnierte Mailingliste ist eine einfache Form von Community.
Auf der Physical Layer läßt sich eine Community auf verschiedene Arten abbilden.
Einerseits sind Communities denkbar, die mit einem Environment deckungsgleich sind,
so daß Mitgliedschaft in ihnen durch ‚physikalische’ Anwesenheit begründet wird.
Ähnlich implizit sind Communities definiert, bei denen auf Mitgliedschaft nur aus
einem charakteristischen Attribut der einzelnen Agenten geschlossen werden kann.
Dies ist der Fall, wenn alle Agenten eines Typs oder einer Klasse, etwa die NPC bei
Quake, oder am selben ‚virtuellen Ort’, etwa einem Chatraum, eine Community bilden.
Eine Community kann aber auch explizit durch ein zentrales Verzeichnis in Form einer
Entity definiert werden, was die Möglichkeiten zum Ausschluß und zur selektiven
Aufnahme von Agenten verbessert. Schließlich kann sie auch völlig dezentral als
Netzwerk von Bekanntschaften organisiert sein, so daß jeder Agent nur jeweils einige
andere Mitglieder der Community kennt, was das Risiko der Fragmentierung der
Community birgt.
– 161 –
Element Summary
Community
Hierarchical Name
Conceptual.Community
Definition
A set of associated Agents
Relationships
Contains Agent
Governed by Culture
Grounding
Entity
Examples
A workgroup, a soccer team, a marketplace, a P2P network
C.
User
Der Begriff des User ermöglicht es, den oder die Besitzer eines Agenten zu beschreiben. Es muß nicht zwangsläufig für jeden Agent ein User modelliert werden, da der
Aspekt des stellvertretenden Handelns nicht bei jedem Agenten gleichermaßen wichtig
ist, auch wenn die Ausführung eines künstlichen Agenten, der sich nicht selbst schaffen
und aktivieren kann, immer zumindest mittelbar auf einen Menschen zurückzuführen
ist. Diese Bindung ist von elementarer Wichtigkeit, da die Agenten aus dieser Bindung
die Legitimation ihres Handelns beziehen.
Der Vertretungsaspekt ist gerade in Softwaresystemen insoweit von Bedeutung, als daß
sich die operativen Befugnisse des Agenten direkt von der Autorität des Benutzers
ableiten. Diese Übertragung von Rechten kann durch die oben erwähnte Verwendung
von Professed Intentions des Benutzers expliziert werden.
Dabei ist zu unterscheiden, in welcher Form der Benutzer im System selbst repräsentiert
ist. Er kann völlig abstrakt sein und sich nur auf der Ebene der Entities in Professed
Intentions manifestieren. Dies kann entweder implizit im Rahmen der Implementierung, oder explizit und dynamisch in Form eines Autonomous Process umgesetzt
werden. Letzteres dürfte in der überwiegenden Anzahl der Systeme der Fall sein, in
denen der Benutzer zur Laufzeit mit dem Agenten interagiert, sei es über eine grafische
Oberfläche, Konfigurationsdateien oder textuelle Befehle. Er kann allerdings auch
selbst durch einen Avatar in Form eines Agent, dessen Agent Core er darstellt, im
System vertreten sein.
Für die Entwicklung eines Systems ist das Konzept des Users von großer Bedeutung, da
in der Regel die Ziele eines Agenten in Verbindung mit diesem definiert werden. Seine
explizite Modellierung unterstützt eine an den Bedürfnissen der Benutzer orientierte
Herangehensweise, da der Entwickler dadurch immer im Blick behalten muß, auf
wessen Anforderungen ein bestimmter Lösungsansatz eigentlich abzielt.
– 162 –
Gerade bei persönlichen Agenten sind die Erfassung der Wünsche und Ziele und die
Kommunikation mit dem Benutzers von zentraler Bedeutung. Psychologische Aspekte
sind hier extrem wichtig – damit ein Agent akzeptiert wird, muß er dem Benutzer das
Gefühl der Kontrolle über das, was der Agent in seinem Namen tut, geben. Somit
müssen neue Informationen und besonders Zielvorgaben von Seiten des Benutzers mit
besonderer Aufmerksamkeit beachtet werden.
Die Interaktion des Benutzers mit dem Agenten läßt sich konkret durch Professed
Intentions, besonders Directives, Assertions und Permissions, modellieren, die der
Agent durch geeignete Sensors wahrnimmt.
Element Summary
User
Hierarchical Name
Conceptual.User
Definition
Representation of an Agent’s user
Relationships
Owns Agent
Grounding
Autonomous Process, Agent or Entity
Examples
The user of a filtering tool, an enterprise sending a trading agent
D.
Purpose
Der Purpose eines Agenten ist die Menge der Ziele, die der Modellierer bzw. der User
einem Agent vorgibt. Im übertragenen Sinne ist es auch möglich, daß eine Community
oder eine Role einen Purpose haben.
Der Purpose besteht aus einem System von Missions, die die strategischen und
operativen Ziele eines Agenten abbilden. Sie sollen die unterliegende Motivation des
Agenten beschreiben. Alle Missions leiten sich von einer externen Autorität ab. Sie
werden entweder durch den Modellierer oder den Benutzer vorgeschrieben – ein Agent
kann sich selbst keine originär neue Mission geben.
Die Missions können wechselseitige Abhängigkeiten besitzen, etwa, daß eine Mission
eine Vorbedingung einer anderen Mission darstellt oder zwei Missions nur gemeinsam
verfolgt werden können. Weiterhin können sie priorisiert und in einer Hierarchie
angeordnet werden, was bei Zielkonflikten oder Widersprüchen unabdingbar ist. Bei der
Modellierung eines Systems bietet sich dies oft als erster Entwurfsschritt an, wie dies
etwa die Goal Case-Technik [Kendall et al. 1998a] vorsieht.
– 163 –
Die abstrakten Missions eines Agenten sind zumeist durch seinem Entwurf festgelegt.
Dabei kann sich allerdings die Auswahl der aktiv verfolgten Ziele bei Agenten mit
komplexeren Zielhierarchien dynamisch ändern. Weiterhin wird es in der Regel
möglich sein, daß der Benutzer Instanzen abstrakter Missions erzeugt, indem er dem
Agenten einen konkreten Auftrag gibt.
Ein mobiler Einkaufsagent für elektronische Handelsplattformen verfolgt die abstrakte
Mission, für seinen User auf den Handelsplattformen die gewünschten Waren zum
minimalen Preis zu erstehen. Dabei existieren zwei inhärente Nebenziele, die unbedingt
erfüllt sein müssen: der Agent will die eigene Integrität und Ausführung sicherstellen
und seinen Benutzer getreulich vertreten, also insbesondere sein Vermögen vor
Mißbrauch schützen.
Beauftragt der User nun diesen Agenten, eine bestimmte Ware zu einem gegebenen
Höchstpreis zu beschaffen, erstellt er dadurch eine konkrete Instanz des abstrakten
Ziels.
Der Purpose macht keine weitergehenden Aussagen darüber, wie die formulierten Ziele
im Einzelnen erreicht werden sollen, so daß er die Autonomie des Agenten nur ansatzweise beschneidet. Er erlaubt also in der Regel keine streng deterministische Vorausberechnung des Agentenverhaltens, hilft aber dabei, die rationalen Erwartungen an das
Verhalten des Agenten sinnvoll einzuschränken.
Element Summary
Purpose
Hierarchical Name
Conceptual.Purpose
Definition
Defines objectives from an observer’s perspective
Relationships
Assigned to Agent, Role, Community
Examples
Produce goods; earn money; win the game
E.
Mission
Eine Mission ist ein einzelnes Element eines Purpose. Viele Missions dürften impliziter
Natur sein, sich also allein in der Implementierung des Agenten niederschlagen. In
dieser Form spielen Missions nur als Interpretationswerkzeug beim Entwurf und der
Wartung des Systems eine Rolle und sind zur Laufzeit unsichtbar und statisch.
– 164 –
Es ist allerdings auch möglich, Missions explizit im System umzusetzen. Für dynamisch
hinzugefügte Missions wie die erwähnten Zielinstanzen, die sich aus einem abstrakten
Ziel ableiten, ist dies sogar notwendig.
Mission werden aus der Sicht eines externen Beobachters in den ‚objektiven’ Begriffen
der Physical Layer bzw. auch direkt darauf abgestützten abstrakten Konzepten formuliert. Daher müssen sie, um für Agenten operationalisierbar zu sein, in deren subjektive
Begriffswelt übersetzt werden. Dort werden sie durch entsprechende Aims ausgedrückt,
die somit die Brücke zwischen Mental Model und Application Model, also im Besonderen zum User und seinen Wünschen, herstellen.
Element Summary
Mission
Hierarchical Name
Conceptual.Mission
Definition
An element of an Agent’s Purpose
Relationships
Contained by Purpose
Translated into Aim
Grounding
Entity Model
Examples
PPS: complete production schedule. Quake: Eliminate all other agents.
II.
Modellierung
Das Application Model spiegelt in gewisser Weise das Konzept des Bebauungsplans im
Environment Model wider, wenn auch der Betrachtungsgegenstand ein anderer ist. In
ähnlicher Weise lassen sich daher zur Modellierung der abstrakten Systemstruktur
Deployment- und andere Strukturdiagramme verwenden.
Die Erfassung der Benutzer und Ziele läßt sich mit etablierten High-LevelModellierungsmethoden wie etwa Use Cases oder den von Kendall vorgeschlagenen
Zielhierarchien [Kendall et al. 1998a] bewältigen.
Eine agentenbasierter elektronischer Marktplatz erlaubt es Unternehmen, eigene
Agenten auf den Marktplatz zu entsenden. Durch die Migration auf den Marktplatz
macht ein Agent (Enterprise Auction Agent) ein implizites Commitment, sich an die
Regeln des Marktplatzes zu halten, die in Form der Role Marketplace Trader definiert
sind. Diese Rolle wird hier nur in Ausschnitten dargestellt.
– 165 –
User
Purpose
(0,n)
(0,n)
consists of
(1,1)
(0,n)
owns
(1,1)
assigns
Mission
(0,1)
(0,n)
Hierarchy
(1,n)
(0,n)
Agent
(0,n)
d,p
(0,n)
Relations
Structure
(0,n)
member of
(0,n)
Community
(0,n)
Abbildung 3.20 Elementbeziehungen innerhalb des Application Model
Die Rolle bringt eine Permission von Seiten der Marktplatzleitung mit sich, die
Infrastruktur des Marktes, hier konkret die Verzeichnisdienste, nutzen zu dürfen.
Gleichzeitig impliziert sie auch eine Erlaubnis von Seiten des entsendenden Unternehmens, Gebote bis zu einem durch ein Inherent Statement mitgegebenes Limit abgeben
und Auktionen starten zu dürfen.
Als beispielhaftes Behavior wird definiert, daß Agenten auf beliebige Anfragen binnen
5 Zeiteinheiten antworten müssen. Die Beschreibung des Behaviors selbst unterscheidet
sich im Prinzip nicht von dem Beispiel aus dem Behavioral Model. Jedoch kommt hier
noch eine Interpretation der Handlungen durch soziale Konventionen hinzu, die sich
wiederum in Professed Intentions niederschlägt. Die Anfrage wird als Directive
interpretiert, die Antwort als Assertion. Letztere drückt aus, daß Agenten nicht lügen
dürfen, da sie sonst nicht die Rolle erfüllen und ihr implizit beim Betreten des Marktplatzes gemachtes Commitment brechen, was eine angemessene Sanktion nahelegt.
– 166 –
Marketplace
Enterprise Auction Agent
P Incoming Migration
Professed
acceptance
Intentionof Role
C Implied
Marketplace Trader
Marketplace Trader
Professed Intention
to place bids
P Permission
Represented Enterprise
P Place Bids
Professed Intention
to make offers
P Permission
Represented Enterprise
P Start Auction
I transactions ‚limit’
Professed Intention
to use directories
P Permission
Marketplace Administrator
P Query Directory
M Responsiveness
C message
query
C from
‚sender’
C ask*
‚item?’
Professed
Queried
Intention
Information
D Provide
‚Sender’ Agent
P Reply Message
0 5
C to
‚sender’
C reply*
‚item.’
P Reply Message
Professed
TruthIntention
A Assert
C reply
Abbildung 3.21
0 5
‚item.’
Definition einer Role auf einem elektronischen Marktplatz
Die Notation greift das für das Beispiel am Ende des Behavioral Model definierte
Format wieder auf. Als neue Elemente kommen die Community (drei blaßrote Dreiekke), der User (:)) sowie die Role (blaue Filmrolle) und die Professed Intention (drei
Rechtecke) hinzu. Professed Intention sind hier Assertions (A), Commitments (C),
Directives (D) und Permissions (P). Es muß jeweils ersichtlich werden, w e r die
Professed Intention äußert und w a s sie aussagt.
– 167 –
3.3.2.5 Zusammenfassung der Conceptual Layer
Abschließend soll wiederum die gesamte Ebene im Zusammenhang dargestellt werden.
Die Conceptual Layer ist weniger stark untergliedert als die Physical Layer, da sich,
abgesehen von der bewußten Trennung zwischen Mental Model und Social Model, alle
Teilmodelle in mehreren Punkten berühren.
Statement
(1,1)
Agent
Personality
(1,1)
(0,n)
(1,1)
(0,n)
Agent
(0,n)
member of
(0,n)
Relations
has
(0,n)
has
Aim
(0,1)
Community
(0,n)
(0,n)
(0,n)
(0,n)
has
consists of
(1,1)
implements
(0,n)
(1,n)
(1,1)
Structure
(1,1)
owns
adopts
Structure
(0,n)
(1,1)
(1,1)
Outlook
(0,n)
Premeditation
(1,1)
(0,n)
User
(1,1)
(0,n)
commits to
(0,n)
Culture
(0,n)
translates
(0,n)
(0,n)
(0,n)
defines
(0,n)
fufills
defines
(0,n)
publishes
publishes
plans
sets
defines
(0,n)
Norm
interprets
(1,1)
(1,1)
Position
(0,n)
Schedule
(1,n)
Action
Purpose
(0,1)
(0,1)
(0,n)
(0,n)
(0,n)
(0,n)
references
references
comprises
d,t
fulfills
consists of
Axiom
(0,1)
(0,1)
(0,n)
(0,n)
(1,n)
(0,n)
Mission
Structure
Composition
(0,n)
(0,n)
(0,n)
Behavior
(0,n)
(0,n)
(0,n)
(1,1)
guarantees
Rule
(0,n)
Professed
Intention
Role
(0,n)
Language
(0,n)
(0,n)
Interweaving
Directive
Commitment
Permission
d,t
d,t
Assertion
Interdiction
Declaration
Expression
Implicit
Explicit
Abbildung 3.22 Übersicht über die wichtigsten Elemente der Conceptual Layer
Im obigen Diagramm wurden wieder aus Gründen der Übersichtlichkeit einige wenige
Beziehungen und eine große Anzahl an Untertypen unterdrückt.
– 168 –
3.3.3 Zusammenfassung des Gesamtmodells
Damit ist die Beschreibung aller Modellelemente abgeschlossen. Die einzelnen
Teilmodelle sind bis ins Detail und durch zum Teil umfangreichere Beispiele illustriert
worden, wobei jeweils auch auf Beziehungen zwischen Teilmodellen und über Ebenengrenzen hinweg eingegangen wurde. Auf der Ebene des Gesamtmodells soll hier
dagegen auf die Angabe eines konkreten Beispiels verzichtet werden, da die Ausarbeitung eines für eine Überprüfung des Metamodells ausreichend detaillierten Anwendungsbeispiels vom Aufwand und Umfang her an dieser Stelle nicht möglich erscheint.
Zudem wäre der zusätzliche Erkenntnisgewinn durch ein isoliertes Beispiel insoweit
begrenzt, als daß kaum eine Anwendung zu ihrer Beschreibung das Metamodell in
seiner vollen Breite benötigen dürfte, sondern in der Regel den Schwerpunkt der
Betrachtung wieder in bestimmte Teilmodelle legen wird.
Conceptual Layer
Aim
Mission
Behavior
Statement
User
Action
Cognitive
Statement
Agent
Personality
Percept
Purpose
Agent
Community
Agent Core
Role
Norm
Culture
Language
Professed
Intention
Explicit
Agent
Message
Sensor
Effector
Agent Shell
Entity
Item
Process
Environment
Service
Facility
Physical Layer
Abbildung 3.23 Zentrale Modellbegriffe und Relationen
– 169 –
Daher sollen lediglich in einem semantisch reduzierten Diagramm die bedeutendsten
Modellbegriffe und die wichtigsten Abstützungsrelationen von der konzeptuellen auf
die konkrete Ebene nochmals überblicksartig dargestellt werden.
Zu den wichtigsten Abstützungsrelationen zählt die Fundierung des Behavioral Model
im konkreten Interaktionsmodell des Agenten, also der Actions in Anwendungen von
Effectors, und der konditionierenden Cognitive Statements in den Wahrnehmungen der
Sensors. Über die Beziehung zwischen Position und Outlook stellt das Mental Model
auf diese Weise nicht nur eine formalisierte Verbindung zum Social Model her, sondern
verankert seine Begriffswelt gleichzeitig in der (technischen, virtuellen) Realität.
Zum anderen stützen sich auch die wichtigen sozialen Konventionen auf die konkrete
Ebene ab – Professed Intentions entsprechen Messages oder von Operative Effectors
vorgenommenen Änderungen an beliebigen Entities und können somit in beiden Fällen
an Attributen von Entities festgemacht werden. Communities lassen sich in der Regel
ebenfalls zu Entities in Bezug setzen: Entweder wird die Community direkt durch eine
spezielle Entity, etwa ein Verzeichnis, abgebildet, oder sie wird indirekt durch Beziehungen zwischen Agenten oder eine charakteristische Eigenschaft der Agent Shell, also
wiederum Attribute von Entities, definiert.
Umgekehrt liefert die konzeptuelle Ebene in vielen Fällen erst die nötige Semantik, um
die Interaktionen auf der Physical Layer überhaupt interpretieren zu können. Die
Bedeutung von Messages hängt etwa im Allgemeinen von der verwendeten Language
aus dem Social Model ab. Dies gilt natürlich in herausragendem Maße für die Beziehungen zwischen dem konkreten und dem abstrakten Agenten, also im Kern zwischen
dem Agent Core und seiner Spezifikation in der Agent Personality, war doch der
Brückenschlag zwischen der abstrakten Perspektive der KI und der technischen
Herangehensweise der Softwareentwicklung ein zentrales Anliegen des Modells.
– 170 –
4
Studie zur operativen Umsetzung des Metamodells
Bei der Beschreibung der Entwurfsprinzipien des Metamodells wurden als die zentralen
Aussagen der Agentenorientierung die Kapselung von Verhalten und eine interaktionsorientierte Systemsicht herausgestellt. Im Rahmen des Metamodells wurde dementsprechend konkret mit Entitäten, Effektoren und Sensoren und abstrakt mit Verhaltensmustern, Rollen und der Publikation relevanten internen Verhaltens argumentiert. Der
Schwerpunkt der Betrachtung lag auf der Definition eines Strukturmodells der einzelnen
Begriffe, wobei aber zwangsläufig auch Prozesse und Austauschbeziehungen zwischen
den Elementen erörtert wurden. In Form der Ereignisklassen wurden bereits relevante
Zustandsübergänge herausgestellt, und in Verbindung mit dem Agentenlebenszyklus
wurde ein vollständiges Zustandsmodell aufgestellt. Die Dynamik des Gesamtsystems
wurde somit zwar implizit beschrieben, aber noch nicht einheitlich formalisiert dargestellt.
Es liegt in der Natur statischer Strukturen, daß sie einer eingängigen, übersichtlichen
Modellierung zugänglicher sind als komplexe Abläufe. Mit einem statischen Medium,
wie Papier es ist, lassen sich Zustandsänderungen eines Elements nicht an Ort und Stelle
darstellen. Der Zustand wird entweder nur implizit erfaßt (Quellcode, Kollaborationsdiagramme) oder muß durch Duplizierung des betroffenen Elements an anderer Stelle
ausgedrückt werden (ereignisgesteuerte Prozeßketten (ePK), Aktivitäts-, Zustands- oder
Flußdiagramme). Die resultierenden Modelle sind in der Regel umfangreicher, aufwendiger und unübersichtlicher als das korrespondierende Strukturmodell.
Gerade für nebenläufige Systeme, wie es Multiagentensysteme gemeinhin sind, ist eine
exakte Spezifikation des erwarteten Verhaltens jedoch unabdingbar. Als wesentliche
Herausforderung auf dem Weg zu einer weiten Verbreitung agentenorientierter
Technologien wird daher gesehen, Methoden zu entwickeln, die es einer breiten
Entwicklergemeinde erlauben, entsprechende Spezifikationen in effizienter Weise zu
erstellen. Dabei erscheint die Unterstützung durch grafische Beschreibungen und
geeignete Werkzeuge wünschenswert.
Geschickt gewählte Abstraktionen können es ermöglichen, auch komplexe Systeme für
den menschlichen Betrachter verständlich und in ihrer Korrektheit bewertbar zu
machen. Dies setzt jedoch voraus, daß die zugrundeliegende Methode selbst korrekt ist
und die wegabstrahierte Komplexität nicht einfach unterschlägt, sondern sie in erschöp-
– 171 –
fender Weise behandelt. Um die diesbezügliche Eignung des Metamodells zu bestätigen, wurde daher angestrebt, seine Dynamik mit Hilfe einer formalen Spezifikationssprache zu erfassen.
4.1
Vorgehensweise
4.1.1 Verwendete Modellierungsmethode
4.1.1.1 Anforderung und Auswahl
An die Methode zur Beschreibung des Metamodells wurden drei Anforderungen
gestellt: Sie sollte abstrakt genug sein, um dem flexiblen und umfassenden Charakter
des Metamodells gerecht zu werden, und gleichzeitig konkret genug, um die Dynamik
des Modells detailliert und präzise zu beschreiben. Zweitens sollte sie die Verifikation
des Modells ermöglichen, sei es durch formale Überprüfung oder durch simulierte
Ausführung. Gleichzeitig sollte sie aber einfach und anschaulich genug sein, um in
Ergänzung zum Strukturmodell als lesbare Dokumentation des Metamodells dienen zu
können.
Die Suche nach einer geeigneten Methode führte bald auf die von Gurevich entwickelten
Evolving Algebras, einem alternativen Verfahren zur Beschreibung der Semantik von
Algorithmen. Ihre Entwicklung ist durch die Überlegung motiviert, daß entsprechende
Turing-Maschinen zwar prinzipiell jeden Algorithmus simulieren können, dabei aber
gerade bei komplexeren, speziell logischen, Problemen keine adäquate Darstellung
mehr zulassen, da für einen inhaltlichen Berechnungsschritt des Algorithmus unverhältnismäßig viele Schritte der Maschine notwendig sind [Gurevich 1988]. Als Vorteil
gegenüber konkurrierenden alternativen Automatenmodellen wird angesehen, daß
Evolving Algebras nicht auf einem festgelegten Abstraktionsniveau arbeiten, sondern an
das jeweilige Problem angepaßt werden können, um jeweils eine möglichst weitgehende
Strukturgleichheit zwischen Algorithmus und simulierendem Automaten erreichen zu
können [Gurevich 1995].
Die entsprechenden Automaten werden als Abstract State Machines (ASM) bezeichnet.
Sie wurden bereits zur Spezifikation einer vielfältigen Auswahl an Hard- und Software-
– 172 –
systemen verwendet, unter anderem auch in den hier relevanten Bereichen verteilte
Systeme und Programmiersprachen. Das Augenmerk fiel dabei besonders auf die Arbeit
von Stärk, Schmid und Börger, die auf der Basis von ASM ein Modell der Programmiersprache Java [Gosling et al. 1996] und der zugehörigen Laufzeitumgebung, der Java
Virtual Machine (JVM), aufgestellt haben [Stärk et al. 2001]. Die erfolgreiche Anwendung der Methode auf ein Problem diesen Umfanges versprach, daß sie nicht nur für
isolierte Algorithmen geeignet sein, sondern auch auf komplexe Systeme wie das
vorliegende Metamodell skalieren würde. Zudem erschien der Ansatz mit dem dritten
Teilziel kompatibel, da die Arbeit von Stärk et al. explizit „Programmierer und Implementierer“ [ibid., S. 1] anspricht und „Praktikern“ ein klares Verständnis der „dunklen
Ecken“ der Java-Spezifikation bieten möchte [ibid., S. 2], somit also ebenfalls Wert auf
eine klare und eingängige Darstellung legt. Da die Methode somit vielversprechende
Ansätze bot, wurde ihre Eignung für den vorliegenden Fall näher untersucht.
4.1.1.2 Abstract State Machines
Konzept nach Gurevich
Die grundlegende Idee hinter Evolving Algebras ist es, Algorithmen als Übergänge
zwischen Zuständen zu beschreiben, wobei jeder Zustand durch eine Struktur erster
Ordnung, also eine Menge mit Funktionen und Relationen, beschrieben wird. Der
eigentliche Algorithmus wird dabei durch Transitionsregeln beschrieben, die den neuen
Zustand in Form einer beschränkten Anzahl von Änderungen am aktuellen Zustand
definieren.
Aus technischen Gründen bildet Gurevich die Relationen der Strukturen durch Funktionen ab, so daß die einzelnen Zustände konkret durch statische Algebren beschrieben
werden können, worin der Name der Methode begründet ist. Die Signatur bleibt über
alle Algebren hinweg konstant; es können also keine Funktionen entfernt oder hinzugefügt werden.89 Dabei sind Funktionen der Arität null erlaubt, mit deren Hilfe Konstanten
89
Sofern nicht entsprechende Kunstgriffe, wie die Behandlung von neuen Funktionen als Daten durch
eine apply(function, parameter)-Funktion, angewendet werden.
– 173 –
und Variablen abgebildet werden. Weiterhin sind alle Funktionen als total definiert.
Originär partielle Funktionen geben an den entsprechenden Stellen das spezielle
Element undef zurück.
Sämtliche Funktionen arbeiten auf einem gemeinsamen Superuniverse (Übergeordnetes
Universum bzw. Allklasse). Dieses wird allerdings durch charakteristische Funktionen
in verschiedene Universes (Universum bzw. Allklasse) partitioniert, so daß die Algebren faktisch als mehrsortig zu verstehen sind. Das Superuniverse bleibt ebenfalls
konstant; es können also keine neuen Elemente erzeugt werden. Um dennoch Universes
dynamisch erweitern zu können, kann ein spezielles, möglicherweise unendliches
Universum namens Reserve eingeführt werden, dem durch Umdefinition der charakteristischen Funktionen Elemente entnommen und zurückgegeben werden können.
Die Transitionsregeln beschränken sich somit darauf, die Funktionen der Signatur an
bestimmten Stellen umzudefinieren. Sie werden als bedingte Aktualisierungen formuliert. Dabei werden alle Aktualisierungen einer Regel gleichzeitig angewendet. Daraus
leitet sich ab, daß Aktualisierungen konsistent und frei von Widersprüchen sein müssen;
andernfalls hält die Ausführung an. Die parallele Anwendung wurde trotz der damit
verbundenen Entscheidbarkeitsprobleme bevorzugt, da sie die Erweiterung auf das
Gebiet nebenläufiger Systeme zu erleichtern versprach. Die Bedingungen und Aktualisierungen enthalten im Prinzip ausschließlich geschlossene, variablenfreie Funktionsterme. Variablen sind lediglich in Verbindung mit einem All- oder Existenzquantor in
der Bedingung zulässig. Zuletzt wird in Verbindung mit den Transitionsregeln zwischen
statischen internen, dynamischen internen und dynamischen externen Funktionen
unterschieden. Externe Funktionen werden nicht durch den Automaten selbst aktualisiert, ändern sich jedoch im Stil eines Orakels trotzdem, so daß sie etwa das Einlesen
von Benutzereingaben nachbilden können (vgl. [Gurevich 1995] und [Gurevich 1996]).
Verwendung gemäß Börger
Börger führt in seiner Sichtweise auf ASM verschiedene Erweiterungen ein [Stärk et al.
2001, S. 18-25]. Dabei nimmt er zahlreiche rein syntaktische, einer bequemeren
Anwendbarkeit dienende Ergänzungen vor. Vor allem aber erlaubt er Variablen in
Termen, die dann im Rahmen von Regeln an Werte gebunden werden können. Außerdem können Regeln im Stil von Methoden parametrisiert von anderen Regeln aufgeru-
– 174 –
fen werden. Dies scheint das unausgesprochene Ziel zu verfolgen, in der Anwendung
den ASM-Pseudocode einer klassischen funktionalen Programmiersprache möglichst
ähnlich zu machen. Es verwässert allerdings auch das Konzept der Evolving Algebras,
da zum einen die klare Unterscheidung zwischen Regeln (hier quasi ‚Methoden mit
Seiteneffekten) und Funktionen (‚Methoden ohne Seiteneffekte’) zumindest syntaktisch,
im Grunde aber auch semantisch verwischt wird, und zum anderen die Funktionen der
Arität null vielfach durch das Variablenkonstrukt verdrängt werden, was unter anderem
dazu führt, daß Regeln selbst Zustände haben können.
Entscheidend im aktuellen Zusammenhang war aber vor allem die pragmatische Frage,
inwieweit sich aus der Modellierung der JVM eine Eignung von ASM für die Spezifikation des Metamodells ableiten ließe. Die Arbeit von Stärk, Schmid und Börger kann an
dieser Stelle nicht umfassend diskutiert und gewürdigt werden; jedoch sollen einige für
den konkreten Betrachtungszweck relevante Beobachtungen herausgestellt werden.
Zunächst wird Java nicht vollständig modelliert. Um die Darstellung kompakt zu
halten, werden nur der Bequemlichkeit dienende syntaktische Konstrukte (hier bezeichnet als „expressive sugar“) wie alternative Kontrollstrukturen (switch, for),
Variableninitialisierung, konditionale Operatoren (&& und ||), Zuweisungsoperatoren
(+=, *=, etc.) und Pre- und Postinkrementoperatoren90 (++ und --) nicht modelliert.
Bei der Umsetzung des Modells in ausführbare ASM auf Basis des Werkzeugs ASMGofer, das eine grafische Umgebung zur Validierung von Programmen bieten soll,
fehlen diese Elemente allerdings ebenfalls, so daß eine Anwendung auf reale Programme nur sehr eingeschränkt möglich erscheint. Weiterhin werden Aspekte wie Packages,
Sichtbarkeit von Namen, Ein- und Ausgabe und Garbage Collection ausgeschlossen
[Stärk et al. 2001, S. 32].
Diese und weitere im Text eingestreute Vereinfachungen und Annahmen erschweren
eine eigenständige Beurteilung, inwieweit der geführte formale Korrektheitsbeweis für
90
Während sich kombinierte Zuweisungsoperatoren trivial expandieren lassen (a+=1 Ùa=a+1), stellt
die Semantik der Pre- und besonders Postinkrementoperatoren ein praktisch relevantes Problem dar, das
sowohl die Ursache zahlreicher Programmfehler als auch fundamentaler Mehrdeutigkeiten in der
Spezifikation der Sprache C ist, so daß ihre Einordnung als „expressive sugar“ zumindest erklärungsbedürftig erscheint.
– 175 –
reale Systeme relevant ist und Aussagen über die Validität und Sicherheit einer
tatsächlichen Java-Implementierung zuläßt. Weiterhin werden strukturelle Einschränkungen (Constraints) aufgestellt, von denen nicht deutlich wird, in welcher Form sie
sich im Code der ASM niederschlagen. Ohnehin erschweren handwerkliche Mängel das
Verständnis des Modells. Die verwendete Notation weicht von der im methodischen
Teil des Buches eingeführten Form ab. Die Beschreibung der Signatur enthält unkommentierte Vorwärtsreferenzen (etwa [ibid., S. 35]), was noch dadurch verschärft wird,
daß bestimmte Funktionen überhaupt nicht, also weder im Text noch im Anhang,
definiert werden (etwa [ibid., S. 41]).
Eine ernüchternde Erkenntnis bezüglich verteilter ASM ergab sich in Verbindung mit
der Modellierung von Java Threads. Verteilte ASM wurden bislang nur zur Modellierung von Algorithmen geringen Umfangs verwendet und können gegenwärtig auch
noch nicht ausgeführt werden. Daher werden zur Beschreibung des Threads herkömmliche sequentielle ASM verwendet. Dabei werden allerdings nicht einmal die Fähigkeiten zur parallelen Aktualisierung mehrer Funktionen genutzt, sondern die Threads
nacheinander von einem Multiplexer ausgeführt!
Abschließend wurde eine Erkenntnis deutlich, die sich auf die Beschreibung durch
Evolving Algebras generell bezieht: Jeder Einzelschritt eines Algorithmus wird durch
eine separate Regel beschrieben, so daß die Struktur des Algorithmus nicht unmittelbar
ersichtlich wird. Zwar lassen sich komplexe Strukturen wie Objekte oder Agenten
durchaus auch funktional beschreiben, hinsichtlich der Regeln unterstützen oder
zumindest befördern ASM jedoch per se keine strukturierte Darstellung. Dies war die
wesentliche Motivation, der derzeit unter der Leitung von Gurevich entwickelten
Abstract State Machine Language (AsmL) den Vorzug zu geben, die über diesbezüglich stärkere Ausdrucksmittel verfügt.
4.1.1.3 Abstract State Machine Language
AsmL ist ein Projekt der Forschungsabteilung Foundations of Software Engineering
von Microsoft [Microsoft 2003c]. Microsoft hat neben Gurevich auch Schulte, der
gemeinsam mit Börger Urheber des Projekts zur Modellierung von Java war, verpflichten können, so daß die Abteilung gegenwärtig ein führendes Zentrum der ASMbezogenen Forschung darstellt.
– 176 –
Mit AsmL wird das konkrete Ziel verfolgt, die Entwicklungsprozesse bei Microsoft zu
beschleunigen und qualitativ zu verbessern. Im Rahmen verschiedener Projekte wird
bereits versucht, AsmL in einem operativen Kontext einzusetzen [Microsoft 2003d]. Ein
Pilotprojekt betraf die Spezifikation des Protokolls für Universal Plug and Play (UPnP)
[Modeled Computation 2001].
Aufgrund dieser Zielsetzung ist AsmL eng mit dem Microsoft .NET Framework
[Microsoft 2003e] verknüpft. Der in die .NET Entwicklungsumgebung integrierte
AsmL-Compiler setzt AsmL-Code in C#-Code [Microsoft 2003f] um, der dann vom C#Compiler in ein eigenständiges Programm übersetzt wird. AsmL-Spezifikationen sind
somit ausführbar.
Um die Einstiegshürde für an ein objektorientiertes Paradigma gewöhnte Entwickler zu
verringern und die Methode besser an die konkreten Bedürfnisse der Softwareentwicklung bei Microsoft anzupassen, führt AsmL objektorientierte Konzepte wie Interfaces
und Klassen ein [Barnett/Schulte 2001]. Weiterhin sieht die Sprachreferenz in der
aktuellen Version 2.0 [Modeled Computation 2002] C#-spezifische Konstrukte wie
property oder delegate vor, die allerdings bislang nur rudimentär bzw. überhaupt nicht
implementiert sind. AsmL bietet eine einfache Klassenbibliothek [Grieskamp/Tillmann
2003], die im Wesentlichen die elementaren Datentypen, die drei Behältertypen Set
(ungeordnete Menge), Seq(uence) (geordnete Menge) und Map (mit einer Schlüsselmenge indizierte Menge) und minimalistische Ein- und Ausgabefunktionen für Dateien
und Konsole umfaßt.
Die Einführung objektorientierter Konstrukte hilft deutlich bei der strukturierten
Modellierung komplexer Systeme, führt aber auch die bereits bei Börger angemerkte
Entfernung von den mathematischen Grundlagen des Konzepts fort. Die Idee der
Signatur und die Beschreibung von Variablen als Funktionen der Arität null treten
komplett in den Hintergrund. Funktionen und Regeln werden einheitlich durch Methoden abgebildet. Dabei wird zwar prinzipiell zwischen Methoden mit Seiteneffekten
(procedure) und ohne Seiteneffekte (function) unterschieden, diese Differenzierung
wird jedoch von den derzeitigen Werkzeugen nicht überprüft [Modeled Computation
2002, S. 52].
Alle zur Arbeit mit AsmL benötigten Entwicklungswerkzeuge sind kostenlos über die
Internetseiten von Microsoft Research zu beziehen. Im vorliegenden Fall wurde AsmL
– 177 –
for Microsoft .NET in der Version 2.1.5.2 [Microsoft 2003a] zur Modellierung verwendet.91 Zusätzliche Details bezüglich der Sprache und der zugehörigen Werkzeuge
werden im Rahmen der Beschreibung des umgesetzten Entwurfes und des anschließenden Erfahrungsberichtes betrachtet werden.
4.1.2 Dekomposition und Strukturierung durch Zwischenziele
Bei der Planung des weiteren Vorgehens bezüglich der Implementierung des Modells
erschien es als vorteilhaft, das Projekt zweistufig anzugehen.
Erste Überlegungen bezüglich der Umsetzung von Sensoren und Effektoren hatten
schnell auf die Frage geführt, wie die Wahrnehmungen der Sensoren und die von den
Effektoren vorgenommenen Änderungen an Entities inhaltlich hinreichend detailliert
abzubilden wären. Vor dem Hintergrund der für die physikalische Ebene angestrebten
starken Verankerung in existierender Softwaretechnik lag es hier nahe, auf die Prinzipien der Objektorientierung zurückzugreifen. Die enge Verwandtschaft, die die Beschreibung der manipulierten Attribute und die Spezifikation der zu einer konkreten Benutzung von Effektoren und Sensoren anzugebenden Parameter mit objektorientierten
Konzepten, konkret Objektvariablen und Methodensignaturen, aufwiesen, war somit
nicht überraschend, sondern durchaus beabsichtigt.
Daher wurde beschlossen, zunächst eine objektorientierte Laufzeitumgebung mit AsmL
zu spezifizieren. Diese sollte dann in einem zweiten Schritt erlauben, Agenten, Entities,
Sensors, Effectors und Attribute auf Basis der abstrakt spezifizierten Objekte, Variablen und Methoden detailliert und präzise zu beschreiben, ohne dadurch das Metamo-
91
AsmL befindet sich offiziell noch im Beta-Stadium. Erste Experimente wurden mit AsmL Version
2.1.4 vom Oktober 2002 [Microsoft 2002] durchgeführt. Die themenbezogene Implementierungsarbeit
wurde auf Grundlage der Anfang Januar erschienenen Version 2.1.5.2 [Microsoft 2003a] vorgenommen.
Anfang März erschien die derzeit aktuelle Version 2.1.5.6 [Microsoft 2003b]. Auf der AsmL-Homepage
[Microsoft 2003d] sind leider weder die vorhergehenden Versionen noch Informationen bezüglich der
genauen Änderungen zwischen den verschiedenen Versionen (etwa in Form von Release Notes oder
einem Change Log) verfügbar.
– 178 –
dell in seinem allgemeinen Anspruch zu beschränken.92 Die Entscheidung hatte
allerdings nicht nur inhaltliche, sondern auch methodische Gründe. Aufgrund der
Tatsache, daß sowohl das Metamodell noch nicht praktisch erprobt worden war als auch
bislang noch keine eigenen Erfahrungen mit AsmL gesammelt worden waren, bot es
sich an, eine Unbekannte zu eliminieren und AsmL zunächst auf ein vertrautes, vielfach
bestätigtes Konzept, eben die Objektorientierung, anzuwenden. Um dabei gleichzeitig
schon ein Gefühl für die Herausforderungen bei der Spezifikation des ungleich komplexeren Konzeptes der Agentenorientierung zu gewinnen, wurde die objektorientierte
Laufzeitumgebung nicht strikt auf die für das agentenorientierte Modell unmittelbar
relevanten Teile beschränkt, sondern zum Test der Methode zunächst als vollwertiger
Betrachtungsgegenstand behandelt.
4.2
Aufbau der Spezifikation
Da AsmL-Spezifikationen sprachbasiert sind und sich syntaktisch nicht auf einer
höheren Abstraktionsebene bewegen als herkömmlicher objektorientierter Quellcode,
empfiehlt es sich in analoger Weise, vor einer konkreten Umsetzung zunächst die
Struktur der Spezifikation zu planen.
Zu diesem Zweck wurden als erster Schritt UML-Klassendiagramme der objektorientierten Laufzeitumgebung aufgestellt. Im folgenden Abschnitt sollen die zentralen
Elemente des entwickelten Modells vorgestellt und einige relevante Aspekte bezüglich
seiner praktischen Umsetzung in AsmL erörtert werden.
92
Die Beschreibung von Objektorientierung mittels einer objektorientierten Methode, wie AsmL es ist,
birgt gewisse (epistemologische) Probleme. Die inhaltliche und konzeptionelle Ähnlichkeit zwischen
den beiden Abstraktionsebenen stiftet leicht Verwirrung darüber, auf welche Ebene sich ein verwendeter Begriff bezieht. In diesem Sinne sei betont, daß hier die Metaebene, also die Elemente der physikalischen Ebene und ihre abstrakten Interaktionsbeziehungen, durch die Erweiterung objektorientierter
Konzepte modelliert wird (also etwa eine Entity als spezielles Objekt mit assoziierten Attributen), dies
aber keine Aussage über die Natur der Objektebene, also des beschriebenen Systems, macht (die
beschriebene Entity kann etwa in Wahrheit eine Kaffeemaschine sein, deren ‚Attribute’ ihr Betriebszustand und der Füllstand der Kanne sind).
– 179 –
4.2.1 Die objektorientierte Cb Laufzeitumgebung
Die auf den Namen Cb getaufte objektorientierte Laufzeitumgebung entlehnt Konzepte
aus den Sprachen Java [Gosling et al. 2000], C++ [Stroustrup 2000] und C# [Microsoft
2003f]. Da die Laufzeitumgebung ohnehin auf einer dreistufigen Emulation basiert (Cb
durch AsmL, AsmL durch C#, C# durch die C# Virtual Machine), wird die Aufmerksamkeit nicht auf Effizienz, sondern auf mächtige Ausdrucksmittel, die sich auf dieser
maschinenfernen Ebene leicht umsetzen lassen, gerichtet. Cb bietet Interfaces und
Garbage Collection wie Java, Mehrfachvererbung, Operatorüberladung und Unterscheidung zwischen Objekt- und Zeigertypen wie C++ und einen speziellen Funktionszeigertypen wie C#. Andere interessante Aspekte wie generische Typen oder Properties
sind hier irrelevant, da kein zugehöriger Compiler spezifiziert wird. Der praktische
Nutzwert der Laufzeitumgebung ist deswegen begrenzt, da auszuführende Programme
in umständlicher Notation indirekt in AsmL angegeben werden müssen. Dies ist auch
der Grund, weshalb die implementierte ‚Klassenbibliothek’ äußerst minimalistisch ist
und nur die unbedingt notwendigen Basistypen enthält.93
4.2.1.1 Strukturen
Die Struktur der Laufzeitumgebung wird vom Dualismus zweier spiegelbildlicher
Hierarchien bestimmt. Auf der einen Seite existiert die statische Spezifikation des
auszuführenden Programms, die etwa seine Klassen, Methoden und Variablen umfaßt.
Diesen steht zur Laufzeit ihre konkrete Realisierung durch Instanzen, Methodenaufrufe
und Speicheradressen gegenüber.
CompTiNE-Hierarchie
Die Objekte94 der statischen Beschreibung tragen alle einen eindeutigen, hierarchischen
Namen. Sie können bereits zur Erstellungszeit vom Compiler aus dem Quelltext
93
94
Der Quelltext der Spezifikation ist im Anhang der elektronischen Version dieser Arbeit verfügbar.
Um die Unterscheidung zwischen den beiden Verwendungsarten objektorientierter Begriffe, also
Klassen im Sinne von AsmL und Klassen im Rahmen von Cb, zu verdeutlichen, werden letztere kursiv
gedruckt. Bezeichner aus der Spezifikation werden in nichtproportionaler Schrift geschrieben.
– 180 –
abgeleitet bzw. in der vorliegenden Situation vom Benutzer manuell definiert werden.
Sie werden daher hier unter dem Begriff Compile Time Named Entity (CompTiNE)
zusammengefaßt. Ihre Beziehungen werden durch eine Hierarchie von Interfaces
definiert, die in Abbildung 4.1 dargestellt ist.
Der Basistyp dieser Hierarchie ist die CompTiNE, die einen einfachen und einen
qualifizierten (hierarchischen) Bezeichner besitzt. Sie muß, mit Ausnahme des globalen
Namensbereichs in seiner Rolle als Wurzelelement, in einem Scope enthalten sein. Ein
Scope ist eine CompTiNE, in deren Rahmen andere CompTiNE definiert werden
können.
«Interface»
«Schnittstelle»
CompTiNE
+identifier() : String
+qualifiedIdentifier() : String
+scope() : Scope
«Interface»
«Schnittstelle»
Scope
«Interface»
«Schnittstelle»
Variable
+validCompTiNE(in identifier : String) : CompTiNE
+localCompTiNE(in identifier : String) : CompTiNE
«Interface»
«Schnittstelle»
Namespace
+instanceType() : Type
+isMutable() : Boolean
+isSpecializable() : Boolean
+access() : Access
+instantiate(in context : Context) : Location
«Interface»
«Schnittstelle»
Block
+namespaceDefinition(in identifier : String) : Namespace
+typeDefinition(in identifier : String) : Type
+methodDefinition(in identifier : String) : Method
+variableDefinition(in identifier : String) : Variable
+instantiate(in context : Context) : StaticContext
+variableDefinition(in identifier : String) : Variable
+code()
+instantiate(in context : Context) : StackContext
«Interface»
«Schnittstelle»
Type
+isAbstractType() : Boolean
+isa(in t : Type) : Boolean
+inheritsDirectlyFrom() : Set of Type
+inheritsDirectlyFrom(in t : Type) : Type
+methodDefinition(in identifier : String) : Method
+variableDefinition(in identifier : String) : Variable
+instantiate(in ot : Objectable, in isMutable : Boolean) : Instance
«Interface»
«Schnittstelle»
Method
+returnType() : Type
+parameters() : Seq of Variable
+invariant() : Boolean
+isSpecializable() : Boolean
+access() : Access
+signature() : String
+invoke(in context : Context, in parameters : Seq of Instance) : Instance
Abbildung 4.1
Die Interfaces der CompTiNE-Hierarchie
– 181 –
Ein Type beschreibt eine Klasse oder ein Interface. Er kann Methods und Variables enthalten und von anderen Types erben. Ein Namespace erfaßt die Konzepte
der Kompilierungseinheit und des Namensbereichs aus C++ und der Package aus Java.
Er kann andere Namespaces, Types, Methods und Variables enthalten.
Prinzipiell entspricht jeder Type auch einem Namespace; es hat sich bei der Umsetzung jedoch als praktischer erwiesen, die statischen Elemente und inneren Klassen eines
Typs in einem separaten Namespace gleichen Namens abzubilden.
Ein Block ist ein Abschnitt im Quellcode, der einen eigenen Geltungsbereich für
lokale Variablen einführt. Eine Method ist ein spezieller Block, der parametrisiert
aufgerufen werden und einen Wert eines bestimmten Typs zurückgeben kann. Da
Methodennamen überladen werden können, wird eine Methode nur durch ihre Signatur
eindeutig identifiziert. Ist eine Member-Methode invariant, kann sie auf konstanten
Objektinstanzen aufgerufen werden.
Eine Variable ist eine CompTiNE, die den Typ und die Modifizierer (constant,
mutable) einer globalen, lokalen, Namensbereichs- oder Member-Variable beschreibt.
Für Member-Methoden und -Variablen läßt sich die Sichtbarkeit (public, protected,
private) und Spezialisierbarkeit (virtual, final) spezifizieren. Die Rückgabetypen
virtueller Methoden und die Typen virtueller Variablen können von abgeleiteten
Klassen verfeinert werden, wobei zwischen dem ursprünglichen und dem verfeinerten
Typ eine isa-Beziehung bestehen muß.
Die beschriebenen Interfaces werden von einer hier nicht näher beschriebenen parallelen Hierarchie von konkreten Klassen (BasicCompTiNE, BasicScope, etc.)
implementiert. Constructor und Destructor beschreiben spezielle Klassen von
Methoden und sind daher als Untertypen von BasicMethod definiert. Zur Definition
abstrakter Klassen bot sich erstmals eine spezielle Fähigkeit von AsmL, die Verwendung restringierter Typen, an. Der Typ BasicInterface hätte sich als BasicType, bei dem isAbstractType wahr ist, beschreiben lassen – dies wird von den
aktuellen Werkzeugen allerdings noch nicht unterstützt und funktioniert anscheinend
prinzipiell nur für eingebaute Typen.
– 182 –
RouTiNE-Hierarchie
Zur Laufzeit werden von der Laufzeitumgebung Instanzen der verschiedenen CompTiNE-Typen dynamisch erzeugt. Jede Instanz kann als die logische Beschreibung eines
bestimmten, hier natürlich nur abstrakten Speicherbereiches betrachtet werden und wird
daher als Run Time Named Entity (RouTiNE) bezeichnet. Die entsprechende Hierarchie wird nachfolgend in Abbildung 4.2 dargestellt.
Der Basistyp RouTiNE verweist auf die CompTiNE, die ihm als Vorlage gedient hat.
RouTiNE werden von der spezialisierten instantiate-Methode einer CompTiNE
erzeugt und können mittels ihrer eigenen dispose-Methode wieder zerstört werden.
Außer dem Wurzelelement sind wiederum alle RouTiNE jeweils in einem übergeordneten Context, der Instanz des entsprechenden Scope, enthalten.
«Interface»
RouTiNE
«Schnittstelle»
+identifier() : String
+template() : CompTiNE
+context() : Context
+dispose()
«Interface»
Context
«Schnittstelle»
«Interface»
Location
«Schnittstelle»
+createLocation(in identifier : String, in location : Location, in caller : Context)
+accessLocation(in identifier : String, in caller : Context) : Location
+accessMethod(in identifier : String, in caller : Context) : Method
+scope() : Scope
+content() : Instance
+content(in value : Instance) : Instance
+variable() : Variable
«Interface»
StaticContext
«Schnittstelle»
«Interface»
StackContext
«Schnittstelle»
+accessContext(in identifier : String) : StaticContext
+registerContext(in context : StaticContext)
+namespace() : Namespace
+inContext(in parent : Context) : Boolean
+execute()
+block() : Block
«Interface»
Instance
«Schnittstelle»
+object() : Instance
+objectable() : Objectable
+clone(inout duplicate : Objectable)
+location() : Location
+location(in address : Location)
+isMutable() : Boolean
+instanceof() : Type
«Interface»
Invocation
«Schnittstelle»
+method() : Method
Abbildung 4.2
Die Interfaces der RouTiNE-Hierarchie
– 183 –
Der Context spielt eine zentrale Rolle bei der späteren Umsetzung der Auswertung
von Ausdrücken und Befehlen. Ein Context erlaubt den Aufruf von Methoden und
den Zugriff auf abstrakte Speicherorte, also den Inhalt von Variablen.
Für jeden Namespace wird genau ein StaticContext erzeugt. Angefangen mit
dem globalen Namensbereich erzeugt die Laufzeitumgebung zu Beginn der Ausführung
den entsprechenden Baum aus StaticContexts und führt eventuellen Code zur
Initialisierung von Bereichsvariablen aus.
Ein StackContext ist die Instanz eines Block. Er bildet somit eine lokale Umgebung auf dem simulierten Stack ab. Der Aufruf einer Method, eine Invocation, ist
dementsprechend ein spezieller StackContext.
Die komplexeste RouTiNE ist die Instance, die Instanz eines Type. Eine Instance ist somit ein Objekt oder ein Teil eines Objekts. Im Fall von Vererbungsbeziehungen wird für jede Basisklasse eine eigene Instance erzeugt, so daß das eigentliche Objekt aus einer Struktur von Instances besteht. Da Mehrfachvererbung erlaubt
ist, werden die Instances nicht als Baumstruktur, sondern in einer Instanzentabelle
(Objectable) verwaltet. Zur Implementierung polymorpher Typen überlädt Instance die Methoden accessLocation und accessMethod aus Context und
wählt dynamisch die spezialisierteste Variable oder Methode aus. Alle Werte in Cb sind
Instances, einschließlich aller primitiven Typen und Literale.
Jedes Objekt belegt eine Location. Jede Location ist mit einer Variable
assoziiert, die ihren Type und ihre Modifikatoren beschreibt. Bei Zuweisungen und
allen vergleichbaren Operationen wird eine Typenprüfung vorgenommen. Dabei werden
Instances grundsätzlich by Value kopiert. Eine Übergabe von Instances by
Reference erfolgt mit Hilfe von explizit deklarierten Referenzen. Diese sind selbst als
Instances realisiert, die aus einer integrierten Vorlagenklasse erzeugt werden. Sie
können typsicher auf andere Instances oder auf Locations auf dem simulierten
Heap verweisen. Referenzen auf Methods sind in ähnlicher Weise realisiert. Für
Instances auf dem Heap wird unter Verwendung der Referenzen eine einfache
Garbage Collection durch Reference Counting realisiert.
– 184 –
4.2.1.2 Ausführbare Elemente
Der im engeren Sinne ausführbare Cb-Code besteht aus Ausdrücken (Expression)
und Befehlen (Imperative). Die eigentlichen Berechnungen eines Programmes
werden durch die Auswertung von Ausdrücken durchgeführt, Befehle steuern den
Ablauf der Ausführung. Ausdrücke können verschachtelt sein, sind dabei aber in
irgendeiner Form immer in einem Befehl verankert. Bestimmte Befehle können
ebenfalls andere Befehle enthalten. Mittelbar ist jeder Befehl Teil eines Block.
Die einzelnen Ausdrücke bzw. Befehle werden durch eigenständige Objekte repräsentiert. Der Baum aller Befehle und Ausdrücke eines Block (Parse Tree) wird durch den
sukzessiven Aufruf der Methoden evaluate bzw. execute auf diesen Objekten
abgearbeitet. Dabei ergibt sich das Problem der Explizierung des Kontextes. Bei einer
informellen oder rein abstrakten Beschreibung ist intuitiv klar, auf welches Objekt sich
eine Member-Methode bezieht oder welche Instanz einer bestimmten lokalen Variablen
bei einer Serie rekursiver Methodenaufrufe jeweils gemeint ist. Da AsmL jedoch nicht
auf einer logischen, sondern auf einer operativen Ebene arbeitet, sind sich die Elemente
des Modells ihres Kontextes nicht ‚bewußt’, sofern er ihnen nicht mitgeteilt wird. Daher
wird bei jedem Aufruf von evaluate bzw. execute der Context, in dem die
Auswertung stattfinden soll, explizit übergeben. 95
Ausdrücke
Jeder Ausdruck wertet zu einer RouTiNE bzw. CompTiNE aus. Dabei existieren vier
Klassen, die einen Context, eine Instance, eine Location bzw. eine Method
zurückgeben. Abbildung 4.3 gibt einen Überblick über eine Auswahl konkreter Typen.
95
Das explizite Mitführen des gesamten Zustandes in Aufrufparametern erinnert deutlich an funktionale
Programmierung. Im Prinzip i s t die Abarbeitung des Codebaums tatsächlich funktional gelöst, da
keinerlei Seiteneffekte auf die ausführenden Knoten auftreten, sondern nur die herumgereichte ‚Welt’
verändert wird. Die durchaus denkbare ‚objektorientierte’ Alternative, etwa beim Aufruf einer Method
den enthaltenen Code zu klonen und mit passenden Referenzen auf die zugehörige Invocation zu
versehen, verlagert den Kontext zwar in die Objekte, vermeidet aber ebenfalls nicht das Problem, sich
explizit mit ihm auseinandersetzen zu müssen. Praktisch scheitert dieser Ansatz weniger an mangelnder
Effizienz als an der Tatsache, daß AsmL prinzipbedingt weder Kopierkonstruktoren noch echte
Referenzen anbietet.
– 185 –
«Interface»
«Schnittstelle»
Expression
+evaluate(in context : Context)
«Interface»
«Schnittstelle»
ExpressionContext
+evaluateContext(in context : Context) : Context
«Interface»
«Schnittstelle»
ExpressionInstance
+evaluateInstance(in context : Context) : Location
+expressionType() : Type
«Interface»
«Schnittstelle»
ExpressionLocation
+evaluateLocation(in context : Context) : Location
+expressionType() : Type
«Interface»
«Schnittstelle»
ExpressionMethod
+evaluateMethod(in context : Context) : Method
+expressionMethod() : Method
ExpressionLocationContext
ExpressionLocationReference
-_context : ExpressionContext
-_identifier : Variable
-_reference : ExpressionInstance
ExpressionInstanceLiteral
ExpressionInstanceLocation
ExpressionInstanceAssign
ExpresssionInstanceInvocation
-_literal : Instance
-_location : ExpressionLocation
-_location : ExpressionLocation
-_instance : ExpressionInstance
-_context : ExpressionContext
-_method : ExpressionMethod
-_parameters : Seq of ExpressionInstance
Abbildung 4.3
Ausschnitt aus der Hierarchie der Ausdruckstypen
Reine Context-Ausdrücke ermitteln anhand eines qualifizierten Bezeichners vom
globalen Namensbereich aufsteigend den gesuchten StaticContext oder aus der
lokalen Umgebung durch verschachtelte Blocks absteigend den relevanten StackContext.
Da Instances ebenfalls Contexts sind, fungieren Instance-Ausdrücke gleichzeitig als Context-Ausdrücke, etwa beim Zugriff auf Member-Variablen. InstanceAusdrücke zeichnen sich für einen wesentlichen Teil der Instruktionen eines Programmes verantwortlich: Sie speichern Literale, erzeugen neue Instances, lesen Locations aus oder weisen ihnen Instances zu, werten Methodenaufrufe aus oder
nehmen Type Casts vor. Instance-Ausdrücke haben den Type ihres Ergebnisses.
Location-Ausdrücke dienen vor allem dazu, aus einem Bezeichner und einem
Context-Ausdruck eine konkrete Instanz einer Variable zu ermitteln. Sie werten
aber auch Referenzen aus, ermitteln die Location einer Instance und erzeugen die
Instanzen lokaler Variablen und neue Locations auf dem Heap.
Method-Ausdrücke ermitteln in ähnlicher Weise aus einem Context-Ausdruck und
einer Signatur oder einer Referenz die aufzurufende Methode.
– 186 –
Befehle
Die von der Laufzeitumgebung unterstützten Befehle werden in Abbildung 4.4 aufgeführt. Sie bieten nichts Außergewöhnliches und sollten weitgehend selbsterklärend sein.
«Interface»
«Schnittstelle»
Imperative
+execute(in context : Context)
ImperativeBlock
ImperativeEmpty
-_block : Block
+execute(in context : Context)
+execute(in context : Context)
ImperativeConditional
-_guard : ExpressionInstance
-_conditional : Imperative
-_alternative : Imperative
ImperativeReturn
-_expression : ExpressionInstance
+execute(in context : Context)
+execute(in context : Context)
ImperativeSequence
ImperativeExpresssion
-_code : Seq of Imperative
-_expression : ExpressionInstance
+execute(in context : Context)
+execute(in context : Context)
ImperativeLoop
-_guard : ExpressionInstance
-_body : Imperative
-_update : Imperative
ImperativeBreak
-_levels : Integer
+execute(in context : Context)
+execute(in context : Context)
ImperativeTry
-_code : Imperative
-_handlers : Seq of ImperativeCatch
+execute(in context : Context)
Abbildung 4.4
ImperativeContinue
-_levels : Integer
+execute(in context : Context)
ImperativeCatch
ImperativeThrow
-_handlingCode : Block
-_exceptionExpression : Variable
+execute(in context : Context)
-_expression : ExpressionInstance
+execute(in context : Context)
Übersicht über die unterstützten Befehlstypen
ImperativeBlock schiebt einen neuen StackContext auf den virtuellen Stack.
ImperativeSequence führt Befehle sequentiell aus. ImperativeExpression
wertet einen Ausdruck aus. ImperativeConditional bietet ein if-then-elseKonstrukt, wobei der else-Zweig auch nur die leere Anweisung ImperativeEmpty
enthalten kann. Die Bedingung muß ein Instance-Ausdruck vom Typ CbBoolean
sein, was in AsmL zwar durch den Befehl require als Vorbedingung spezifiziert werden
kann, jedoch bislang nicht überprüft wird. Gleiches gilt für ImperativeLoop, eine
while- oder for-Schleife. ImperativeReturn springt aus Methodenaufrufen.
ImperativeBreak und ImperativeContinue springen aus Blocks bzw. in
den nächsten Schleifendurchlauf, wobei in verschachtelten Strukturen auch über
– 187 –
mehrere Ebenen gesprungen werden kann. ImperativeTry und ImperativeCatch dienen zur Behandlung von mit ImperativeThrow ausgelösten Ausnahmen.
Die Implementierung der Befehle ist, das Befehlspaar try/catch einmal ausgenommen,
im Prinzip vollkommen trivial. Bei der Implementierung der Sprungbefehle war
allerdings problematisch, daß AsmL selbst aufgrund seiner funktionalen Herkunft
keinerlei Sprungbefehle anbietet. Die return-Anweisung legt etwa nur den Rückgabewert einer Funktion fest, ohne den Kontrollfluß zu beeinflussen.96 AsmL unterstützt
allerdings Exceptions, so daß erwogen wurde, bei der Ausführung einer ImperativeReturn eine ReturnException auszulösen und am Ort des Methodenaufrufs
aufzufangen. Dies scheitert allerdings daran, daß bei identischer Syntax die Semantik
der Exceptions fundamental von den aus objektorientierten Sprachen gewohnten
Konventionen abweicht: Beim Auslösen einer Exception werden alle bisherigen
Aktualisierungen innerhalb des try-Blocks zurückgenommen, so daß dieser stärkere
Ähnlichkeit mit einer Datenbanktransaktion als mit seinem Pendant in Java hat. Die
verwendete Lösung ist nicht elegant, aber effektiv: Die Cb-Sprungbefehle verändern
eine Variable der Laufzeitumgebung, den RunTimeState. Setzt etwa ein throwBefehl den Status auf RTSException, werden durch if-Abfragen alle weiteren
Befehle ausgelassen, bis ein passender catch-Befehl ihn wieder zu RTSExecute,
dem Normalwert, ändert.
4.2.1.3 Native Klassen
Eine Klassenbibliothek wird nur in dem Ausmaß definiert, wie diese für andere
Komponenten der Laufzeitumgebung zwingend notwendig ist. Der Namespace Cb
umfaßt die elementaren Typen CbBoolean, CbByte, CbInteger, CbDecimal
und CbCharacter, die einfache Wrapper um entsprechende AsmL-Typen sind,
96
Bei der Modellierung von Java lösen Stärk et al. das entsprechende Problem, indem sie alle Elemente
des Codebaums indizieren, den Index eines Funktionsaufrufes festhalten und dann beim returnBefehl nicht z u r ü c k k e h r e n , sondern in eine weitere Funktion hineinspringen, die die Ausführung
am festgehaltenen Index fortsetzt. Zur Umsetzung mit AsmL eignet sich diese Lösung allerdings nur
eingeschränkt, da auf diese Weise zwar der virtuelle Stack von Cb abgebaut, der reale Stack von AsmL
bzw. C# jedoch in einer nicht zurückkehrenden Rekursion immer weiter aufgebaut würde.
– 188 –
sowie CbVoid, CbObject, CbArray, CbString und die Referenztypen CbReference und CbFunctional. Zur Ein- und Ausgabe dienen die Befehle WriteLine
und ReadLine.
4.2.2 Zur Umsetzung des Metamodells
Die durch die Spezifikation der objektorientierten Laufzeitumgebung etablierten
Konzepte lassen sich vergleichsweise direkt auf die Physical Layer des agentenorientierten Metamodells übertragen. Die Umsetzung von Entities, Agents und Environments als spezialisierte Instances und von Sensors, Effectors und Mechanisms
durch verschiedene Arten von Methods wirft etwa keine gravierenden konzeptionellen
Probleme auf. Dieser Teil des Modells wird insoweit sogar einfacher, als daß die
Hierarchie der CompTiNE in wesentlichen Teilen wegfällt: Da Entities ungetypt sind,
sind Types einfach nur spezielle, als Vorlagen markierte Instances.
Die entsprechenden Strukturmodelle wurden bei der konzeptionellen Entwicklung des
Metamodells in Form der Beschreibungen, Zusammenfassungen und Diagramme
bereits in wesentlichen Teilen aufgestellt. Die Definition diverser Elemente kann in
einfacher Weise direkt mit den Mitteln von AsmL umgesetzt werden, etwa kann ein
Context als Set von Entities implementiert werden. Allerdings sind die Modelle
dahingehend zu überarbeiten, daß im Sinne des beschriebenen Problems des Kontextes
in AsmL wiederum alle Abhängigkeiten und Bezüge explizit darzustellen sind.
Weiterhin ist etwa die Unterscheidung, ob ein Sensor auf einer ‚realen’ Entity oder auf
einem dynamisch erzeugten ‚imaginären’ Percept operiert, im logischen Modell
nachrangig, während sie bei der operativen Umsetzung in AsmL eine explizite Fallunterscheidung und Implementierung in getrennten Untertypen erfordert. Notwendige
Differenzierungen dieser Art führen zu einer signifikanten Ausweitung der Klassenhierarchie.
Gänzlich problematisch wird dies bei der Spezifikation der Services. Während sich bei
einigen der Dienstklassen noch eine einheitliche Schnittstelle definieren läßt (etwa bei
Execution: Scheduling), wird in anderen Fällen (Security: Integrity) e i n e Lösung
kaum allen Ansprüchen gerecht werden. Sollen konkrete Systeme simuliert werden,
blähen unterhalb der ohnehin schon zahlreichen Dienstklassen jeweils noch diverse
konkrete Implementierungen die Klassenhierarchie weiter auf.
– 189 –
Die Conceptual Layer kann dagegen zumindest in ihren zentralen Strukturen vergleichsweise leicht beschrieben werden. Die Umsetzung des Social Model und des
Behavioral Model erfordert zwar eine ausführliche Auseinandersetzung mit den
verschiedenen bereits im konzeptionellen Teil eingeführten Untertypen, läßt sich
aufgrund des auf die Physical Layer abgestützten Entwurfs aber problemlos operationalisieren. Allerdings müssen auch hier verschiedene Implementierungsmöglichkeiten
beachtet werden, beispielsweise hinsichtlich der Frage, wie zur Ableitung von Professed Intentions das Verhalten der Agenten mit den entsprechenden Norms verglichen
wird.
In Verbindung mit dem Mental Model tritt wiederum das Problem auf, daß viele
inkompatible theoretische Ansätze bei der praktischen Umsetzung viele differenzierte
Implementierungen erfordern. Ein Problem prinzipieller Natur werfen sehr abstrakte
Konzepte wie etwa der Purpose auf. Seine Missions können natürlich durch die
Abbildung auf Aims in ein dynamisches Modell eingebunden werden, allerdings wird
dies seinem Anspruch allein nicht in vollem Maße gerecht. Da der Purpose die grundsätzliche Motivation eines Agent oder einer Role beschreibt, zieht er sich implizit durch
deren gesamte Umsetzung, so daß sich die Frage stellt, ob er überhaupt sinnvoll explizit
operationalisiert werden kann.
4.3
Erkenntnisse und Kritik
Auf ihrem abschließenden Entwicklungsstand bietet die objektorientierte Laufzeitumgebung die detaillierte Spezifikation einer möglichen Realisierung der zentralen
Konzepte der Objektorientierung. Zur Ausführung sinnvoller Programme fehlt allerdings nicht nur eine umfangreichere Klassenbibliothek, sondern vor allem eine Methode, um die Programme mit vertretbarem Aufwand überhaupt spezifizieren zu können.
Ferner wurde es nicht für sinnvoll erachtet, die Spezifikation des Metamodells mit
AsmL weiter zu verfolgen, da eine solche vor dem Hintergrund der bei der Implementierung des objektorientierten Modells gemachten Erfahrungen weder praktikabel noch
adäquat erschien. Die Gründe für diese Entscheidung sollen im Folgenden im Einzelnen
dargelegt werden, wobei zunächst auf die verfügbaren Werkzeuge, im Anschluß auf den
Entwurf von AsmL als Sprache und abschließend auf die prinzipielle Eignung von
– 190 –
Evolving Algebras und verwandten Ansätzen zur Modellierung abstrakter Modelle im
Stil des Metamodells eingegangen wird.
4.3.1 Zur Eignung von AsmL
4.3.1.1 Zur Eignung der verfügbaren Werkzeuge
AsmL for Microsoft .NET befindet sich offiziell noch im Beta-Stadium, was inhaltlich
auch durchaus gerechtfertigt erscheint. Verschiedene weiterführende Merkmale der
Sprache sind noch nicht implementiert, an anderen Stellen weist der Compiler formal
korrekten Code mit einem Verweis auf „Current Implementation Restrictions“ zurück.
Darüber hinaus enthält der Compiler noch zahlreiche oft schwerwiegende Fehler, die
leider teilweise extrem subtiler Natur sind. So führt etwa die Verwendung bestimmter
(selbstverständlich nicht reservierter) V a r ia b l e n n a m e n
in Musterausdrücken
reproduzierbar zu nur als bizarr zu bezeichnenden T y p f e h l e r n , die von einer
Kollision mit intern verwendeten Namen im generierten C#-Code herzurühren scheinen.
Diese Fehler machen die Erstellung eines Projekts vom Umfang der CbLaufzeitumgebung praktisch unmöglich. Nach einer langwierigen Fehlersuche, diversen
Umstellungen und der Implementierung von Behelfslösungen zum Umgehen technischer Beschränkungen wird die Spezifikation zwar vom AsmL-Compiler als korrekt
akzeptiert, erzeugt aber bei der weiteren Übersetzung in ausführbaren Code durch den
C#-Compiler in Abhängigkeit von der eingesetzten Version von AsmL unterschiedlichste Fehler, die etwa mangelnde Zugriffsrechte auf Objektattribute und in unzulässiger
Weise verwendete Schlüsselwörter oder Typen betreffen. So konnte die CbLaufzeitumgebung nur in Teilen, nicht aber in ihrer Gesamtheit praktisch getestet
werden.
Pro Projekt wird nur eine einzige Quelldatei unterstützt. AsmL-Code wird in XMLDateien gespeichert, was eine Vermischung von Code und verbalen Beschreibungen
befördern soll, aber auch gewisse syntaktische Einschränkungen, etwa bezüglich der
durch XML reservierten Zeichen (siehe [Bray et al. 2000]), mit sich bringt. Die Spezifikationen lassen sich im Prinzip in Microsoft Office-Dokumente konvertieren; die
diesbezüglichen Werkzeuge reagieren allerdings, wie auch der Compiler selbst, äußerst
sensibel auf von der erwarteten Norm abweichende Verzeichnisstrukturen.
– 191 –
Die Suche nach Laufzeitfehlern wird dadurch erschwert, daß für AsmL kein eigener
Debugger existiert, so daß nur der generierte – strukturell deutlich abweichende – C#Code mit dem entsprechenden Debugger untersucht werden kann. Die AsmLEntwicklungsumgebung versucht zwar, aus den Ausgaben des C#-Debuggers und C#Compilers die betroffene Stelle im AsmL-Code abzuleiten, was allerdings in der Regel
nicht gelingt und eher für zusätzliche Verwirrung sorgt.
4.3.1.2 Zur konzeptionellen Eignung der Sprache
Die technischen Probleme dürften sich bis zur Freigabe der ersten kommerziellen
Version noch deutlich reduzieren und zunehmend in den Hintergrund treten. Langfristig
erscheint daher vor allem die Konzeption der Sprache selbst für ihren Erfolg von
entscheidender Relevanz.
Als wesentlicher Vorzug von AsmL wird die Fundierung in einem exakten mathematischen Modell bezeichnet [Modeled Computation 2002, S. 2]. Praktisch gesehen sind der
Bezug zu den Evolving Algebras und die damit verbundene konzeptionelle Schlichtheit
allerdings verloren gegangen. Das Erscheinungsbild von AsmL wird vollständig von
den zahlreichen pragmatisch motivierten Erweiterungen geprägt, die zur Handhabung
umfangreicherer Modelle und zur stärkeren Annäherung an objektorientiert geprägte
Entwicklungsprozesse hinzugefügt wurden. AsmL ist im Kern eine funktional geprägte
Programmiersprache, auf die objektorientierte Konzepte und eine objektorientiert
gefärbte Syntax aufgesetzt worden sind. Die resultierende hybride Sprache soll die
Vorteile der beiden Paradigmen, ein mächtiges mathematisches Berechnungsmodell und
eine intuitive Strukturierung durch Objekte, verbinden, wird aber letztlich beiden
Konzepten nicht gerecht.
Erklärtes Ziel der Sprache ist es, mit geringem Aufwand die Erstellung von ausführbaren Prototypen zu erlauben, die dann vergleichsweise direkt mit einer herkömmlichen
Sprache in fertige Produkte umgesetzt werden können. Letzteres scheint nur auf den
ersten Blick trivial, da nominell und syntaktisch gleiche Konzepte sich semantisch
– 192 –
zwischen AsmL und C#97 oft fundamental unterscheiden. Die beschriebenen unterschiedlichen Interpretationen von Exceptions lassen sich etwa nicht aufeinander
abbilden. Dies setzt sich in anderen Bereichen fort, etwa bei der mathematisch definierten Gleichheitsrelation für Strukturen. Die anvisierte Zielgruppe dürfte dementsprechend einige Eigenheiten der Sprache zumindest als ungewohnt empfinden.
Besonders sticht hier die Handhabung von sequentiellen Befehlsfolgen heraus. Aus
‚pädagogischen’ Gründen [Barnett/Schulte 2001, S. 2] wurde zu deren Beschreibung
bewußt eine schwerfällige Syntax gewählt. Alle Befehle eines Blocks werden gleichzeitig ausgeführt, sofern dieser nicht durch wiederholte Verwendung des Schlüsselwortes
step in Einzelschritte partitioniert wird. Dies soll offenbar einen rein funktionalen
Programmierstil ohne Seiteneffekte befördern. Da die Verwendung von Objekten aber
im Grunde die Verwendung von Seiteneffekten voraussetzt, erfordern selbst einfache
Vorgänge oft so viele step-Befehle wie reguläre Operationen.
Für Zuweisungen an Variablen existieren zwei verschiedene Operatoren: = initialisiert
Variablen, := ändert bereits initialisierte Variablen. Interessanterweise ist es erlaubt, im
selben Schritt eine Variable zu deklarieren und dabei zu initialisieren und parallel mit
einem zweiten Befehl zu ändern. Da ‚verlorene Aktualisierungen’ (z.B. indem ein
return-Befehl noch den alten Wert zurückgibt) zu schwer lokalisierbaren Fehlern führen
können, bietet es sich generell an, lieber zu viele als zu wenige Steps zu verwenden. An
welcher Stelle in einem Block Variablen deklariert werden, soll ohne Bedeutung sein. In
diesem Zusammenhang trat allerdings ein verblüffender Implementierungsfehler auf:
Folgt in einem Block eine Deklaration auf eine Serie von Steps, werden die in den Steps
vorgenommenen Änderungen annulliert.
Bei der Suche nach entsprechenden Fehlern in der Blockstruktur wirkt erschwerend, daß
in AsmL Blöcke nicht durch Klammern, sondern einzig durch Einrückungen definiert
werden.
Letztlich zählt aber vor allem die Frage, welche Ausdrucksmittel die Sprache für die
effiziente und abstrakte Beschreibung eines Systems bietet. Zu nennen sind hier
97
Die nachfolgenden Vergleiche gelten zumeist in äquivalenter Weise für C#, C++ und Java.
– 193 –
nichtdeterministische Auswahl, Quantorausdrücke und Mustervergleich auf Typen und
Objekten sowie die parallele Ausführung von Befehlen. Letztere wird allerdings
notwendigerweise im generierten C#-Code durch sequentielle Abläufe nur simuliert.
Der einzige publizierte Fall, in dem die parallele Ausführung einen echten Vorteil
bietet, ist das beständig wiederholte Beispiel des unmittelbaren Vertauschens zweier
Variablen. Praktisch sind nichttriviale parallele Aktualisierungen immer riskant, weil
leicht wegen verborgener Seiteneffekte inkonsistente Aktualisierungen auftreten
können. Dies ist besonders bei Aufrufen von Objektmethoden zu bedenken, da Objektorientierung fast zwangsläufig zu einem nicht-funktionalen Programmierstil führt.
Mangels (für den praktischen Einsatz von Parallelität notwendiger) Synchronisierungsmechanismen führen entsprechende konkurrierende Änderungen zum Abbruch des
Programms.
Die Verifikation einer AsmL-Spezifikation erfolgt durch klassisches Testen. Mit den
mathematischen Grundlagen des Modells kommt der Entwickler nicht in Berührung, so
daß sich AsmL wie eine normale Programmiersprache präsentiert. Auch die zweifellos
nützlichen Ausdrucksmittel etablieren formal keine höhere Abstraktionsebene. Daher
muß sich AsmL den Vergleich mit ‚klassischen’ Programmiersprachen gefallen lassen.
Auch objektorientierte Sprachen erlauben es, das inhaltliche Abstraktionsniveau der
Beschreibung frei zu wählen und in einem Entwurfsprototypen weite Teile der Implementierung durch leere Methodenaufrufe oder Stümpfe wegzuabstrahieren. Die
zusätzlichen Ausdrucksmittel können in C++ oder Java leicht durch Hilfsfunktionen,
die mit der jeweiligen Klassenbibliothek in wenigen Zeilen umgesetzt werden können
(oder es bereits sind), hinzugefügt werden.
Umgekehrt bieten die objektorientierten Sprachen die Möglichkeit, auf die vorhandenen
Erfahrungen und Werkzeuge zurückzugreifen, sowie den Vorteil, die Spezifikation als
Grundlage der vollständigen Implementierung unmittelbar weiterverwenden zu können.
Die verfügbaren Klassenbibliotheken sind um Größenordnungen zahl- und umfangreicher und entsprechen zudem exakt den bei der späteren Implementierung verwendeten.
Es ist im Sprachentwurf allerdings zumindest vorgesehen, AsmL den Zugriff auf
externe COM-Objekte [Williams/Kindel 1994] zu erlauben [Barnett/Schulte 2001, S. 9].
Abschließend läßt sich sagen, daß die Verwendung von AsmL zumindest keine
deutlichen Vorteile gegenüber einer Spezifikation in einer herkömmlichen Hochsprache
– 194 –
aufweist. Konzeptionell vereinigt die Sprache eher die Nachteile als die Vorteile ihrer
beiden Vorbilder. Objektorientierte Prototypen können direkt in der Zielsprache
formuliert und ohne zusätzlichen Arbeitsaufwand in Form einer doppelt durchgeführten
Implementierung zum fertigen Produkt verfeinert werden. Funktionale Programmierung
mit objektorientierten Erweiterungen bietet Common LISP [Steele 1990] mit einem
deutlich höheren Reifegrad und besserer Werkzeugunterstützung.
4.3.2 Ausführbare Spezifikationen als Modellierungsmittel
Trotz der Kritik an AsmL werden ausführbare Spezifikationen dennoch nicht als
generell irrelevant angesehen. Wie bereits anklang, kann die Erstellung und Verfeinerung abstrakter Prototypen durchaus ein effizientes Vorgehensmodell darstellen. Wie im
vorliegenden Projekt umgesetzt, sollte der Implementierung allerdings die Aufstellung
von Strukturmodellen vorausgehen, da codebasierte Methoden prinzipbedingt zwar die
Dynamik eines Systems präzise beschreiben, dem menschlichen Betrachter aber keinen
unmittelbaren Überblick über die Systemstruktur erlauben.
Wichtig ist ferner die Einsicht, daß die Spezifikation zwar Teile der Implementierung
unterdrückt, sich aber nicht auf einer höheren Abstraktionsebene bewegt. Für konkrete
Systeme ist eine solche Beschreibung häufig sinnvoll, besonders, wenn sie kritische
Abläufe, aufwendige Algorithmen oder komplexe Protokolle enthalten, die auf diese
Weise vorab getestet werden können. Der Fall der Cb-Laufzeitumgebung macht
allerdings deutlich, daß eine vollständige und detaillierte Spezifikation dieser Form
einer Implementierung gleichkommt. Eine Sprache für ausführbare Spezifikationen
sollte daher mit einer Methodik zur sinnvollen Gliederung und Vereinfachung verbunden sein.
Eine Beschreibung des Metamodells durch eine ausführbare Spezifikation weist auf
zwei Ebenen Probleme auf. Um die angestrebte Validierung des Metamodells zu
erreichen, ist die Durchführung von Tests notwendig. Diese müßten die Form von
Simulationen konkreter agentenbasierter Anwendungssysteme annehmen, die die
Spezifikation des Metamodells als Laufzeitumgebung nutzen. Zu diesem Zweck müßte
die Spezifikation der Implementierung nicht nur einer, sondern gleich mehrerer
Agentenplattformen gleichkommen, was auch bei entsprechenden Vereinfachungen im
gegebenen zeitlichen Rahmen schlicht nicht umzusetzen ist.
– 195 –
Der zweite Einwand ist prinzipieller Natur. Das Metamodell und ausführbare Spezifikationen bewegen sich auf unvereinbaren Abstraktionsebenen, die durch ihre unterschiedlichen Aussageabsichten bedingt sind. Die Spezifikationen verfolgen das Ziel, die
Prozesse in einem System möglichst k o nk r e t und u n z w e i d e u t i g zu beschreiben.
Das Metamodell soll dagegen eine Begriffswelt definieren, die auf eine möglichst breite
Auswahl von Ansätzen anwendbar ist, was eine gewisse Dehnbarkeit der Begriffe
voraussetzt. Die Semantik der Begriffe und ihrer Beziehungen soll zwar ebenfalls
möglichst präzise beschrieben werden, dies geschieht jedoch auf der Ebene a b s t r a k t e r P r i n z i p i e n . Das Metamodell ließe sich wahrscheinlich in eine ausführbare
Spezifikation zwängen, wobei aber, wie etwa durch das Beispiel des Purpose illustriert
wird, jene abstrakteren Aspekte leiden würden, deren Rolle weniger operativ als
vielmehr methodisch-konzeptionell ist.
Dies läßt sich anschaulich mit einer Analogie rechtfertigen: UML Use Cases sind
zweifellos ein sinnvolles und populäres Element der Modellierungssprache. Sie dienen
einer konzeptionellen Strukturierung des betrachteten Systems und seiner Prozesse,
wobei die sehr einfache operative Semantik der entsprechenden Diagramme auf einer
primär nominalen Ebene arbeitet. Die Use Cases motivieren daher zwar die konkreteren
Klassen-, Sequenz- und Kollaborationsdiagramme, werden dort aber nicht für operative
Zwecke referenziert und sind konsequenterweise auch im implementierten System nur
abstrakt. Eine rein operative Beschreibung von UML würde daher zwar die einfachen
Beziehungen zwischen den Use Cases innerhalb des entsprechenden Teilmodells
abbilden, ihre konzeptionelle Rolle für das Gesamtmodell jedoch nicht erfassen. Somit
würde eine solche Spezifikation der Modellierungssprache einen wesentlichen Teil ihres
Konzepts und ihrer Ausdrucksfähigkeit unterschlagen.
Abschließend läßt sich ein Bogen zur Argumentation von McCarthy bezüglich der
Rechtfertigung einer mentalistischen Perspektive auf Programme98 schlagen: Auch
wenn durch den Quellcode eigentlich alles gesagt ist, kann eine abstraktere Beschreibung der zugrundeliegenden Konzepte in vielen Fällen zumindest hilfreich sein.
98
Siehe Abschnitt 2.3.2.1, S. 21.
– 196 –
5
Fazit und Ausblick
Auf der Grundlage des aktuellen Standes der Forschung ist ein umfassendes Metamodell der agentenorientierten Softwareentwicklung aufgestellt worden. Es definiert eine
Terminologie, die die exakte Beschreibung einer breitgefächerten Auswahl von
Ansätzen, Technologien und Anwendungen aus Theorie und Praxis erlaubt.
Als wesentliche Leistung des Metamodells wird die Überbrückung des Gegensatzes
zwischen der softwaretechnischen und der mentalistischen Sicht des Agentenbegriffes
angesehen, die durch die systematische Abstützung der abstrakten Konzepte der
konzeptuellen Ebene auf die implementierungsnahen Begriffe der technischen Ebene
erreicht wird. Das Process Model vermeidet elegant das Problem, aus jedem aktiven
Systemelement einen Agenten machen zu müssen. Das Service Model definiert ein
einheitliches Konzept zur Beschreibung der Infrastruktur verschiedener Agentenplattformen.
Einen innovativen Beitrag leistet das Metamodell primär auf der konzeptuellen Ebene,
wobei besonders das Behavioral Model und das Social Model herauszustellen sind. Die
Konzepte des Legal Stance, des Behaviors und der Professed Intention erlauben es
gemeinsam, diverse semantische Probleme mentalistischer Theorien, namentlich das
‚Gedankenlesen’ und die Entstehung von Idiolekten bei der Kommunikation und den
unbeschränkten Erfahrungshorizont und die nicht beabsichtigten Konsequenzen bei
Denkprozessen, zu umgehen.
Die anschließende Studie zur formalen Spezifikation der Dynamik des Metamodells hat
ergeben, daß eine Umsetzung in ein operatives Modell nicht nur nicht praktikabel,
sondern hinsichtlich der angestrebten Validierung des Metamodells auch inadäquat sein
dürfte.
Dessen ungeachtet bleibt das dargelegte Ziel, die Konsistenz und Aussagekraft des
Modells zu überprüfen, bestehen. Für das weitere Vorgehen liefert hier die zu Beginn
des Modellentwurfs zitierte Beobachtung99, daß der Erfolg einer Theorie primär von
99
Siehe Abschnitt 3.1.2, S. 58.
– 197 –
ihrer Fähigkeit zur adäquaten Beschreibung einer großen Anzahl von Phänomenen
abhängt, interessante Anregungen. Wird diese Überlegung als Grundlage eines Maßes
der Modellqualität genommen, liegt es nahe, die Eignung des Metamodells durch seine
praktische Anwendung auf eine möglichst vielfältige Auswahl realer Systeme zu
überprüfen. Interessant wäre hier unter anderem, das entsprechende Service Model für
den MASIF- bzw. FIPA-Standard aufzustellen.
Ein solches Projekt würde gleichzeitig einen idealen Rahmen bieten, um mit verschiedenen textuellen und grafischen Formalismen zur Beschreibung der einzelnen Teilmodelle zu experimentieren. Parallel könnten unterschiedliche Vorgehensmodelle getestet
werden, etwa eine von abstrakten Zielen ausgehende Modellierung im Gegensatz zu
einem inkrementellen, auf konkreten Wahrnehmungen aufbauenden Ansatz.
Die diversen genannten weiterführenden Arbeiten können insgesamt als Schritte in
Richtung eines mittelfristigen Ziels, der Schaffung einer neutralen Modellierungssprache zur Beschreibung agentenorientierter Systeme, gesehen werden. Ultimativ bestünde
die Hoffnung, durch eine etablierte Terminologie und anschauliche Formalismen dazu
beitragen zu können, daß Agententechnologie in der Weise allgemein anerkannt und
zwanglos eingesetzt wird, wie dies heute für die Objektorientierung der Fall ist.
– 198 –
Literaturverzeichnis
[Asimov 1994]
Asimov, Isaac: I, Robot. Nachdruck, Bantam Books, New York, 1994.
[Atkinson et al. 2000]
Atkinson, Rita L.; et al.: Hilgard's Introduction to Psychology. 13. Auflage, Harcourt Brace College Publishers, Orlando, 2000.
[Barnett/Schulte 2001]
Barnett, Michael; Schulte, Wolfram: The ABCs of Specification: AsmL, Behavior, and Components.
In: Informatica, 25 (4), November 2001.
[Bauer et al. 2001]
Bauer, Bernhard; Müller, Jörg P.; Odell, James: Agent UML: A formalism for specifying multiagent
interaction. In: Agent-Oriented Software Engineering. Hrsg.: Paolo Ciancarini, Michael Wooldridge. Springer, Berlin, S. 91-103, 2001.
[Becker/Schütte 1996]
Becker, Jörg; Schütte, Reinhard: Handelsinformationssysteme. Verlag mi Wissenschaft, Landsberg/Lech, 1996.
[Bellwood et al. 2002]
Bellwood, Tom; et al.: UDDI Version 3.0. Published Specification, 19. Juli 2002
URL: http://uddi.org/pubs/uddi-v3.00-published-20020719.htm Abrufdatum: 2003-03-01.
[BGB]
Bürgerliches Gesetzbuch (BGB) vom 18.08.1896. BGBl. III/FNA 400-2.
[Bonabeau et al. 1998]
Bonabeau, Eric; et al.: Routing in Telecommunication Networks with Smart Ant-Like Agents. In:
Proceedings of the Second International Workshop on Agents in Telecommunications Applications (IATA '98), 1998.
(CiteSeer: http://citeseer.nj.nec.com/bonabeau98routing.html).
[Booch 1994]
Booch, Grady: Object-oriented analysis and design with applications. Addison-Wesley, Reading,
1994.
[Booch et al. 1998]
Booch, Grady; Rumbaugh, James; Ivarson, Jacob: The Unified Modeling Language User Guide.
Addison-Wesley, Reading, 1998.
[Bölöni/Marinescu 1999]
Bölöni, Ladislaus; Marinescu, Dan C.: A Component Agent Model – from Theory to Implementation. Forschungsbericht, Computer Sciences Department, Purdue University, November 1999.
(CiteSeer: http://citeseer.nj.nec.com/392321.html).
[Boole 1847]
Boole, George: The Mathematical Analysis of Logic: Being an Essay towards a Calculus of Deductive Reasoning. Macmillan, Barclay, and Macmillan, Cambridge, 1847.
– 199 –
[Börger 1999]
Börger, Egon: High level system design and analysis using Abstract State Machines. In: Proceedings Current Trends in Applied Formal Methods (FM-Trends 98). Hrsg.: Dieter Hutter, Werner
Stephan, Paolo Traverso, Markus Ullmann. Lecture Notes in Computer Science 1641, S. 1-43,
Springer, Berlin, 1999.
[Bradshaw 1996]
Bradshaw, Jeffrey M.: KAoS: An Open Agent Architecture Supporting Reuse, Interoperability, and
Extensibility. In: Proceedings Tenth Knowledge Acquisition for Knowledge-Based Systems
Workshop, 1996.
[Bratman 1987]
Bratman, Michael E.: Intentions, Plans, and Practical Reason. Harvard University Press, Cambridge (USA), 1987.
[Bray et al. 2000]
Bray, Tim; Paoli, Jean; Sperberg-McQueen, C. M.; Maler, Eve: Extensible Markup Language
(XML) 1.0 (Second Edition). W3C Recommendation, 2. Auflage, 6. Oktober 2000.
URL: http://www.w3.org/TR/REC-xml/ Abrufdatum: 2003-03-01.
[Brazier et al. 1997]
Brazier, Frances M.T.; Dunin-Keplicz, Barabara M.; Jennings, Nicholas R.; Treur, Jan: DESIRE: Modelling Multi-Agent Systems in a Compositional Formal Framework. International Journal of
Cooperative Information Systems, 6 (1), S. 67-94, 1997.
[Bringsjord 1997]
Bringsjord, Selmer: Strong AI Is Simply Silly. AI Magazine, 18 (1), S. 9-10, 1997.
[Brooks 1986]
Brooks, Rodney A.: A robust layered control system for a mobile robot. In: IEEE Journal of Robotics and Automation, 2 (1), S. 14–23, 1986.
[Brooks 1990]
Brooks, Rodney A.: Elephants Don’t Play Chess. In: Designing Autonomous Agents. Hrsg.: Pattie Maes. S. 3-15, 1990.
[Brooks 1991]
Brooks, Rodney A.: Intelligence without representation. In: Artificial Intelligence 47, S. 139-159,
1991.
[Brooks 1995]
Brooks, Frederick P.: The Mythical Man-Month. Anniversary Edition, Addison-Wesley, Reading,
1995.
[Castelfranchi 1990]
Castelfranchi, Cristiano: Social Power: A Point Missed in Multi-Agent DAI and HCI. In: Decentralized AI. Hrsg.: Yves Demazeau, Jean-Pierre Muller. Elsevier Science, Amsterdam, S. 49-62,
1990.
[CERT 2001a]
CERT Coordination Center: CERT Advisory CA-2001-19 "Code Red" Worm Exploiting Buffer
Overflow In IIS Indexing Service DLL. 19. Juli 2001.
URL: http://www.cert.org/advisories/CA-2001-19.html Abrufdatum: 2003-02-15.
– 200 –
[CERT 2001b]
CERT Coordination Center: CERT Advisory CA-2001-26 Nimda Worm. 25. September 2001.
URL: http://www.cert.org/advisories/CA-2001-26.html Abrufdatum: 2003-02-15.
[Chen 1976]
Chen, Peter P.: The entity-relationship model: towards a unified view of data. In: ACM Transactions on Database Systems, 1 (1), S. 9-36, 1976.
[Christensen et al. 2001]
Christensen, Erik; et al.: Web Services Description Language (WSDL) 1.1. W3C Note, 15. März
2001. URL: http://www.w3.org/TR/2001/NOTE-wsdl-20010315 Abrufdatum: 2003-03-01.
[Cleve/Lämmel 2001]
Cleve, Jürgen; Lämmel, Uwe: Gottlob Frege - Logik und Grundlagenausbildung. UICEE Global
Journal of Engineering. Education, 5 (3), 2001.
[Coen 1995]
Coen, Michael H.: SodaBot: A Software Agent Construction System. MIT AI Lab, 1995.
(CiteSeer http://citeseer.nj.nec.com/coen95sodabot.html).
[Cohen/Levesque 1990]
Cohen, Philip R.; Levesque, Hector J.: Intention is choice with commitment. In: Artificial Intelligence, 42, S. 213–261, 1990.
[Copeland 2002]
Copeland, B. Jack: The Church-Turing Thesis. In: The Stanford Encyclopedia of Philosophy (Fall
2002 Edition). Hrsg.: Edward N. Zalta.
URL: http://plato.stanford.edu/archives/fall2002/entries/church-turing/ Abrufdatum: 2003-02-05.
[Dennett 1987]
Dennett, Daniel C.: The Intentional Stance. The MIT Press, Cambridge (USA), 1987.
[Duden 1990a]
o.V.: Agent. In: Duden Fremdwörterbuch. Hrsg.: Wissenschaftlicher Rat der Dudenredaktion. 5.
Auflage, Dudenverlag, Mannheim et al., 1990.
[Duden 1990b]
o.V.: Paradigma. In: Duden Fremdwörterbuch. Hrsg.: Wissenschaftlicher Rat der Dudenredaktion. 5. Auflage, Dudenverlag, Mannheim et al., 1990.
[eBay 2003]
eBay Inc.: Der eBay Bietagent. Online Hilfe, 2003.
URL: http://pages.ebay.de/help/buy/proxy-bidding.html Abrufdatum: 2003-02-15.
[Electronic Arts 2003a]
Electronic Arts Inc.: SimCity Classic Live.
URL: http://simcity.ea.com/play/simcity_classic.php Abrufdatum: 2003-02-20.
[Electronic Arts 2003b]
Electronic Arts Inc.: The Sims. URL: http://thesims.ea.com/ Abrufdatum: 2003-02-20.
– 201 –
[Excelente-Toledo et al. 2001]
Excelente-Toledo, Cora B.; Bourne, Rachel A.; Jennings, Nicholas R.: Reasoning about commitments and penalties for coordination between autonomous agents. Proceedings 5th International
Conference on Autonomous Agents (Agents-2001), Montreal, Canada, S. 131-138, 2001.
[Fallside 2001]
Fallside, David C. (Hrsg.): XML Schema Part 0: Primer. W3C Recommendation. 2. Mai 2001.
URL: http://www.w3.org/TR/xmlschema-0/ Abrufdatum: 2003-03-01.
[Ferstl/Sinz 1998]
Ferstl, Otto K.; Sinz, Elmar J.: Grundlagen der Wirtschaftsinformatik. 3. Auflage, Oldenbourg,
München, 1998.
[Fielding et al. 1999]
Fielding, Roy T.; et al: Hypertext Transfer Protocol – HTTP/1.1. Network Working Group, Request for Comments 2616, Juni 1999. URL: ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt
Abrufdatum: 2003-03-15.
[FIPA]
Federation for Intelligent Physical Agents: Offizielle Homepage.
URL: http://www.fipa.org Abrufdatum: 2003-02-15.
[FIPA C00001]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00001:
FIPA Abstract Architecture Specification.
URL: http://www.fipa.org/specs/fipa00001/ Abrufdatum: 2003-02-15.
[FIPA C00007]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00007:
FIPA Content Languages Specification.
URL: http://www.fipa.org/specs/fipa00007/ Abrufdatum: 2003-02-15.
[FIPA C00008]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00008:
FIPA SL Content Language Specification.
URL: http://www.fipa.org/specs/fipa00008/ Abrufdatum: 2003-02-15.
[FIPA C00009]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00009:
FIPA CCL Content Language Specification.
URL: http://www.fipa.org/specs/fipa00009/ Abrufdatum: 2003-02-15.
[FIPA C00010]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00010:
FIPA KIF Content Language Specification.
URL: http://www.fipa.org/specs/fipa00010/ Abrufdatum: 2003-02-15.
[FIPA C00011]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00011:
FIPA RDF Content Language Specification.
URL: http://www.fipa.org/specs/fipa00011/ Abrufdatum: 2003-02-15.
– 202 –
[FIPA C00023]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00023:
FIPA Agent Management Specification.
URL: http://www.fipa.org/specs/fipa00023/ Abrufdatum: 2003-02-15.
[FIPA C00025]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00025:
FIPA Interaction Protocol Library Specification.
URL: http://www.fipa.org/specs/fipa00025/ Abrufdatum: 2003-02-15.
[FIPA C00026-36]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00026
bis C00036: FIPA Interaction Protocol Specifications.
URL: http://www.fipa.org/specs/fipa00026/ etc. Abrufdatum: 2003-02-15.
[FIPA C00037]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00037:
FIPA Communicative Act Library Specification.
URL: http://www.fipa.org/specs/fipa00037/ Abrufdatum: 2003-02-15.
[FIPA C00061]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00061:
FIPA ACL Message Structure Specification.
URL: http://www.fipa.org/specs/fipa00061/ Abrufdatum: 2003-02-15.
[FIPA C00067]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00067:
FIPA Agent Message Transport Service Specification.
URL: http://www.fipa.org/specs/fipa00067/ Abrufdatum: 2003-02-15.
[FIPA C00086]
Federation for Intelligent Physical Agents: FIPA 2000 Standard Specification, Document C00086:
FIPA Ontology Service Specification.
URL: http://www.fipa.org/specs/fipa00086/ Abrufdatum: 2003-02-15.
[FIPA OS]
FIPA OS: Projekthomepage. URL: http://fipa-os.sourceforge.net/ Abrufdatum: 2003-02-15.
[Fisher 1993]
Fisher, Michael: Concurrent METATEM – A Language for Modeling Reactive Systems. In: Parallel Architectures and Languages, Europe (PARLE), München, Springer, 1993.
[Foner 1993]
Foner, Leonard N.: What's An Agent Anyway? A Sociological Case Study. MIT Media Laboratory, Boston, Technical Report, Agents Memo 93-01, 1993.
[Fou 2001]
Fou, John: Web Services and Mobile Intelligent Agents - Combining Intelligence with Mobility.
Oktober 2001.
URL: http://www.webservicesarchitect.com/content/articles/fou02.asp Abrufdatum: 2003-03-01.
– 203 –
[Franklin/Graesser 1997]
Franklin, Stan; Graesser, Art: Is it an Agent, or just a Program?: A Taxonomy for Autonomous
Agents. In: Proceedings of the Third International Workshop on Agent Theories, Architectures,
and Languages. Hrsg.: Jörg P. Müller, Michael Wooldridge, Nicholas R. Jennings. S. 21-36,
Springer, Berlin, 1997.
[Frege 1879]
Frege, Gottlob: Begriffsschrift, eine der arithmetischen nachgebildete Formelsprache des reinen
Denkens, Halle, Berlin, 1879.
[Gams 1995]
Matjaž Gams: Strong vs. Weak AI. In: Informatica, 19, S. 479-483, 1995.
[Gödel 1931]
Gödel, Kurt: Über formal unentscheidbare Sätze der Principia mathematica und verwandter Systeme I. Monatshefte für Mathematik und Physik, 38, S. 173-198, 1931.
[Gosling et al. 1996]
Gosling, James; Joy, Bill; Steele, Guy: The Java Language Specification. Addison-Wesley, Reading, 1996.
[Grieskamp/Tillmann 2003]
Grieskamp, Wolfgang; Tillmann, Nikolai: The AsmL Standard Library. Sprachreferenz, 6. Januar
2003. URL: http://research.microsoft.com/fse/AsmL/doc/AsmLStandardLibraryReference.doc
Abrufdatum: 2003-01-10.
[Gruber 1993]
Gruber, Tom R.: A translation approach to portable ontologies. Knowledge Acquisition, 5 (2),
S. 199-220, 1993.
[Gudgin et al. 2002a]
Gudgin, Martin; et al. (Hrsg.): SOAP Version 1.2 Part 1: Messaging Framework. W3C Candidate
Recommendation, 19. Dezember 2002.
URL: http://www.w3.org/TR/2002/CR-soap12-part1-20021219 Abrufdatum: 2003-03-01.
[Gudgin et al. 2002b]
Gudgin, Martin; et al. (Hrsg.): SOAP Version 1.2 Part 2: Adjuncts. W3C Candidate Recommendation, 19. Dezember 2002.
URL: http://www.w3.org/TR/2002/CR-soap12-part2-20021219 Abrufdatum: 2003-03-01.
[Gurevich 1988]
Gurevich, Yuri: Logic and the challenge of computer science. In: Current Trends in Theoretical
Computer Science. Hrsg.: Egon Börger. Computer Science Press, S. 1-57, 1988.
[Gurevich 1995]
Gurevich, Yuri: Evolving Algebra 1993: Lipari Guide. In: Specification and Validation Methods.
Hrsg.: Egon Börger. Oxford University Press, S. 9-36, 1995.
[Gurevich 1996]
Gurevich, Yuri: Evolving Algebras: An Attempt To Discover Semantics. Electrical Engineering
and Computer Science Department, University of Michigan, 1996.
URL: http://www.eecs.umich.edu/gasm/tutorial/tutorial.html Abrufdatum: 2003-01-02.
– 204 –
[Gurevich 2000]
Gurevich, Yuri: Sequential Abstract State Machines Capture Sequential Algorithms. ACM Transactions on Computational Logic, 1 (1), S. 77-111, 2000.
[Harrison 1995]
Harrison, Colin G.; Chess, David M.; Kershenbaum, Aaron: Mobile Agents: Are They a Good Idea?
Forschungsbericht RC 19887, IBM Research Division, T.J. Watson Research Center, Yorktown
Heights, New York, März 1995.
(CiteSeer: http://citeseer.nj.nec.com/chess95mobile.html).
[Hayes-Roth1995]
Hayes-Roth, Barbara: An Architecture for Adaptive Intelligent Systems. Artificial Intelligence:
Special Issue on Agents and Interactivity, 72, S. 329-365, 1995.
[Hewitt 1977]
Hewitt, Carl: Viewing control structures as patterns of passing messages. Journal of Artifical Intelligence, 8 (3), S. 323-363, 1977.
[Hintikka 1962]
Hintikka, Jaakko: Knowledge and Belief. Cornell University Press, Ithaca, 1962.
[Hogg/Jennings 1997]
Hogg, Lisa M.; Jennings, Nicholas R.: Socially Rational Agents. In: Proceedings AAAI Fall Symposium on Socially Intelligent Agents, Boston, S. 61-63, 1997.
[Hohl 1999]
Hohl, Fritz (Hrsg.): The Mobile Agent List. Universität Stuttgart, 1999.
URL: http://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole/mal/mal.html Abrufdatum:
2003-02-01.
[Holten 1999]
Holten, Roland: Entwicklung von Führungsinformationssystemen. Ein methodenorientierter Ansatz. Deutscher Universiätsverlag, Wiesbaden, 1999.
[Huget 2002a]
Huget, Marc-Philippe: Agent UML Class Diagrams Revisited. Technical Report ULCS-02-013,
Department of Computer Science, University of Liverpool, 2002.
(CiteSeer: http://citeseer.nj.nec.com/article/huget02agent.html).
[Huget 2002b]
Huget, Marc-Philippe: Extending Agent UML Protocol Diagrams. Technical Report ULCS-02014, Department of Computer Science, University of Liverpool, 2002.
(CiteSeer: http://citeseer.nj.nec.com/huget02extending.html).
[Huggins 2003]
Huggins, Jim: Abstract State Machines. A Formal Method for Specification and Verification.
URL: http://www.eecs.umich.edu/gasm/ Abrufdatum: 2003-01-16.
[IBM 1997]
IBM Research: IBM Aglets Software Development Kit. Technical Report Home Page, Tokyo Research Laboratory, 1997.
URL: http://www.ibm.co.jp/trl/aglets/ Abrufdatum: 2003-02-01.
– 205 –
[id Software]
id Software: Homepage. URL: http://www.idsoftware.com/ Abrufdatum: 2003-02-15.
[IKV 1998]
IKV++ Techonologies AG: GrassHopper, an intelligent mobile agent platform written in 100%
pure Java. 1998. URL: http://www.grasshopper.de/ Abrufdatum: 2003-02-01.
[IntelliOne 2001]
IntelliOne Technologies: AgentBuilder, Agent Construction Tools., 2001.
URL: http://www.agentbuilder.com/AgentTools/ Abrufdatum: 2003-02-01.
[JADE]
Java Agent DEvelopment Framework: Projekthomepage.
URL: http://sharon.cselt.it/projects/jade/ Abrufdatum: 2003-02-15.
[Jennings 1999]
Jennings, Nicholas R.: Agent-based Computing: Promise and Perils. Proceedings 16th International Joint Conference on Artificial Intelligence (IJCAI-99), Stockholm, S. 1429-1436, 1999.
[Jennings 2000]
Jennings, Nicholas R.: On Agent-Based Software Engineering. Artificial Intelligence, 117 (2),
S. 277-296, 2000.
[Jennings/Campos, 1997]
Jennings, Nicholas R.; Campos, Jesus R.: Towards a Social Level Characterisation of Socially Responsible Agents. In: IEE Proceedings on Software Engineering, 144 (1), S. 11-25, 1997.
[JFIPA]
Java FIPA: Projekthomepage. URL: http://www.jfipa.org/ Abrufdatum: 2003-02-15.
[Kaelbling 1986]
Kaelbling, Leslie P.: An architecture for intelligent reactive systems. In: Reasoning About Actions
& Plans – Proceedings of the 1986 Workshop. Hrsg.: Michael P. Georgeff, Amy L. Lansky.
Morgan Kaufmann Publishers, San Mateo, S. 395-410, 1986.
[Kalenka 2001]
Kalenka, Susanne: Modelling Social Interaction Attitudes in Multi-Agent Systems. Dissertation,
Department of Electronic Engineering, Queen Mary, University of London, London, 2001.
[Kalenka/Jennings 1995]
Kalenka, Susanne; Jennings, Nicholas R.: On Social Attitudes: A Preliminary Report. In: Proceedings First International Workshop on Decentralised Intelligent Multi-Agent Systems, Krakau,
S. 233-240, 1995.
[Kant 1787]
Kant, Immanuel: Kritik der reinen Vernunft. 2. Auflage, 1787. In: Kants Werke, Akademieausgabe, Band III, de Gruyter, Berlin, 1968.
[Kendall et al. 1997]
Kendall, Elisabeth. A.; Suresh, C. B.; Murali Krishna, P. V.; Pathak, C.V.: The Layered Agent Pattern
Language. In: Pattern Languages of Programming (Plop '97), September 1997.
– 206 –
[Kendall et al. 1998a]
Kendall, Elisabeth A.; Palanivelan, Uma; Kalikivayi, Panvalkar: Capturing and Structuring Goals:
Analysis Patterns. In: European Pattern Languages of Programming, (EuroPlop '98), Juli 1998.
[Kendall et al. 1998b]
Kendall, Elisabeth. A.; Suresh, C. B.; Murali Krishna, P. V.; Pathak, C.V.: An Application Framework
for Intelligent and Mobile Agents. In: Proceedings Autonomous Agents '98, Mai 1998.
[Kendall et al. 1999]
Kendall, Elisabeth. A.; Suresh, C. B.; Murali Krishna, P. V.; Pathak, C.V.: A Framework for Agent Systems. In: Implementing Applications Frameworks: Object Oriented Frameworks at Work. Hrsg.:
Mohamed Fayad, Douglas C. Schmidt, Ralph Johnson. Wiley & Sons, New York, 1999.
[Kitano et al. 1997]
Kitano, Hiroaki; et al.: RoboCup: A Challenge Problem for AI. AI Magazine, 18 (1), S. 73-85,
1997. (Vgl. auch: URL: http://www.robocup.org).
[Kripke 1963]
Kripke, Saul: Semantical analysis of modal logic. In: Zeitschrift für Mathematische Logik und
Grundlagen der Mathematik, 9, S. 67-96, 1963.
[KSE]
The Knowledge Sharing Effort (KSE): Offizielle Homepage.
URL: http://www.cs.umbc.edu/kse/ Abrufdatum: 2003-02-15.
[KSE 1993]
The Knowledge Sharing Effort (KSE): KQML Knowledge Query and Manipulation Language
Specification Document. 1993.
URL: http://www.cs.umbc.edu/kqml/kqmlspec.ps Abrufdatum: 2003-02-15.
[KSE 1995]
The Knowledge Sharing Effort (KSE): KIF Knowledge Interchange Format Specification Document. 1995. URL: http://logic.stanford.edu/kif/specification.html Abrufdatum: 2003-02-15.
[Kuhn 1996]
Kuhn, Thomas S. : The Structure of Scientific Revolutions. 3. Auflage, The University of Chicago
Press, Chicago, 1996.
[Labrou 2001]
Labrou, Yannis: Standardizing agent communication. In: Lecture Notes in Computer Science,
2086, S. 74-97, 2001.
[Labrou et al. 1999]
Labrou, Yannis; Finin, Tim; Peng, Yun: Agent communication languages: the current landscape.
In: IEEE Intelligent Systems, 14 (2), S. 45-52, 1999.
[Labrou/Finin 1997a]
Labrou, Yannis; Finin, Tim: A Proposal for a new KQML Specification. TR CS-97-03, Computer
Science and Electrical Engineering Department, University of Maryland, Baltimore, 1997.
– 207 –
[Labrou/Finin 1997b]
Labrou, Yannis; Finin, Tim: Comments on the specification for FIPA '97 Agent Communication
Language. URL: http://www.cs.umbc.edu/kqml/papers/fipa/comments.shtml Abrufdatum: 200302-05.
[Lawton 1996]
Lawton, George: Agents to roam the internet. In: SunWorld Online 10 (10), 1996.
URL: http://sunsite.uakom.sk/sunworldonline/swol-10-1996/swol-10-agent.html Abrufdatum:
2003-01-12.
[Lind 1998]
Lind, Jürgen: The EMS Model. Forschungsbericht TM-98-09 des Deutschen Forschungszentrums
für Künstliche Intelligenz, 1998.
(CiteSeer: http://citeseer.nj.nec.com/lind01specifying.html).
[Lind 2000]
Lind, Jürgen: Issues in Agent-Oriented Software Engineering. In: Proceedings of the First International Workshop on Agent-Oriented Software Engineering (AOSE2000), 2000.
[Lind 2001]
Lind, Jürgen: Specifying Agent Interaction Protocols with Standard UML. In: Proceedings Agent
Oriented Software Engineering (AOSE) 2001, S. 136-147, 2001.
(CiteSeer: http://citeseer.nj.nec.com/lind01specifying.html).
[Lingnau et al. 1995]
Lingnau, A.; Drobnik, O.; Domel, P.: An HTTP-based infrastructure for mobile agents. In: Proceedings WWW J. (Fourth International WWW Conference), Dezember 1995.
[Lionhead]
Lionhead Studios: Black & White Homepage.
URL: http://www2.bwgame.com/ Abrufdatum: 2003-02-15.
[Loebner 2001]
Loebner, Hugh G.: The Loebner Prize. Offizielle Homepage, 2001.
URL: http://www.loebner.net/Prizef/loebner-prize.html Abrufdatum: 2003-02-15.
[Maes 1994]
Maes, Pattie: Agents that reduce work and information overload. Communications of the ACM,
37 (7), S. 31-40, 1994.
[Maes 1995]
Maes, Pattie: Artificial Life Meets Entertainment: Life like Autonomous Agents. Communications
of the ACM, 38 (11), S. 108-114, 1995.
[McCarthy 1979]
McCarthy, John: Ascribing mental qualities to machines. In: Philosophical Perspectives in Artificial Intelligence. Hrsg.: Martin Ringle. Harvester Press, Brighton, 1979.
[Meyer 1997]
Meyer, Bertrand: Object-oriented Software Construction. 2. Auflage, Prentice-Hall, New York,
1997.
– 208 –
[Meyers 1987]
o. V.: Buridans Esel. In: Meyers Grosses Taschenlexikon. Hrsg.: Werner Digel, Gerhard Kwiatkowski. 2. Auflage, BI-Tachenbuchverlag, Mannheim et al., S. 158, 1987.
[Microsoft 1997]
Microsoft Corporation: New Features for the Microsoft Office 97 Product Family.
URL: http://support.microsoft.com/default.aspx?id=/support/office/content/office97/features.asp
Abrufdatum: 2003-02-05.
[Microsoft 2001]
Microsoft Corporation: Microsoft Clippy.
URL: http://www.microsoft.com/Office/clippy/ Abrufdatum: 2003-02-05.
[Microsoft 2002]
Microsoft Research: AsmL for Microsoft .NET. Version 2.1.4, 22. Oktober 2002.
URL: http://research.microsoft.com/fse/AsmL/download.aspx Abrufdatum: 2003-01-02.
[Microsoft 2003a]
Microsoft Research: AsmL for Microsoft .NET. Version 2.1.5.2, 13. Januar 2002.
URL: http://research.microsoft.com/fse/AsmL/download.aspx Abrufdatum: 2003-01-14.
[Microsoft 2003b]
Microsoft Research: AsmL for Microsoft .NET. Version 2.1.5.6, 28. Februar 2003.
URL: http://research.microsoft.com/fse/AsmL/download.aspx Abrufdatum: 2003-03-01.
[Microsoft 2003c]
Microsoft Research: Foundations of Software Engineering. Offizielle Homepage, 2003.
URL: http://research.microsoft.com/fse/ Abrufdatum: 2003-03-05.
[Microsoft 2003d]
Microsoft Research: AsmL. Offizielle Homepage, 2003.
URL: http://research.microsoft.com/fse/AsmL/ Abrufdatum: 2003-03-05.
[Microsoft 2003e]
Microsoft Corporation: Microsoft .NET Framework. Offizielle Homepage,
URL: http://msdn.microsoft.com/netframework/ Abrufdatum: 2003-03-05.
2003.
[Microsoft 2003f]
Microsoft Corporation: Microsoft Visual C# .NET. Offizielle
URL: http://msdn.microsoft.com/vcsharp/ Abrufdatum: 2003-03-05.
2003.
Homepage,
[Minsky 1968]
Minsky, Marvin L. (Hrsg.): Semantic Information Processing. MIT Press, Cambridge,1968.
[Modeled Computation 2001]
Modeled Computation LLC: Executable Specifications: Creating Testable, Enforceable Designs.
Whitepaper, 9. Februar 2001. URL: http://research.microsoft.com/fse/ESpecTesting.doc
Abrufdatum: 2003-01-15.
[Modeled Computation 2002]
Modeled Computation LLC: AsmL: The Abstract State Machine Language. Sprachreferenz,
7. Oktober 2002. URL: http://research.microsoft.com/fse/AsmL/doc/AsmL2_Reference.doc
Abrufdatum: 2003-01-02.
– 209 –
[Moore et al. 2003]
Moore, David et al.: The Spread of the Sapphire/Slammer Worm. Cooperative Association for
Internet Data Analysis (CAIDA), 4. Februar 2003.
URL: http://www.caida.org/outreach/papers/2003/sapphire/ Abrufdatum: 2003-02-18.
[Murphy/Picco 2002]
Murphy, Amy L.; Picco, Gian Pietro: Reliable Communication for Highly Mobile Agents.
In: Autonomous Agents and Multi-Agent Systems, 5, S. 81-100, 2002.
[Newell1982]
Newell, Adrian: The Knowledge Level. Artificial Intelligence 18, S. 87-127, 1982.
[Odell 1999]
Odell, James: Objects and agents: How do they differ? Working Paper Version 2.2, 1999.
URL: http://www.jamesodell.com/Agents_and_Objects.pdf Abrufdatum: 2003-01-12.
[Odell et al. 2000]
Odell, James; Parunak, H. Van Dyke; Bauer, Bernhard: Extending UML for Agents. In: Proceedings
of the Agent-Oriented Information Systems Workshop at the 17th National Conference on Artificial Intelligence, 2000.
(CiteSeer: http://citeseer.nj.nec.com/odell00extending.html).
[Odell et al. 2002]
Odell, James; Parunak, H. Van Dyke; Fleischer, Mitch; Breuckner, Sven: Modeling Agents and their
Environment. In: Proceedings AOSE Workshop at AAMAS 2002, Springer, Berlin, 2002.
[OMG]
Object Management Group: Offizielle Homepage.
URL: http://www.omg.org Abrufdatum: 2003-02-15.
[OMG 1998]
GMD FOCUS; IBM Corporation: Mobile Agent System Interoperability Facilities Specification.
Joint Submission, 1997. Hrsg.: OMG Revision Task Force, 1998.
URL: http://cgi.omg.org/cgi-bin/doc?orbos/98-03-09.pdf. Abrufdatum: 2003-02-15.
[OMG 2002]
Object Management Group: Common Object Request Broker Architecture: Core Specification.
Hrsg.: CORBA Core Revision Task Force. Version 3.0.2, 6. Dezember 2002.
URL: http://www.omg.org/cgi-bin/doc?formal/02-12-06.pdf. Abrufdatum: 2003-03-01.
[Ovum 1994]
Ovum Report: Intelligent agents: the new revolution in software, 1994.
[Page et al. 1998]
Page, Lawrence; Brin, Sergey; Motwani, Rajeev; Winograd, Terry: The PageRank citation ranking:
Bringing order to the Web. Stanford Digital Library Technologies Project, 1998.
(CiteSeer: http://citeseer.nj.nec.com/page98pagerank.html).
[Parsons et al. 2002]
Parsons, Simon; Jennings, Nicholas R.; Sabater, Hordi; Sierra, Carles: Agent specification using multi-context systems. In: Foundations and Applications of Multi-Agent Systems: UKMAS 19962000. Hrsg.: Mark d’Inverno et al. Springer, Berlin, S. 205-226, 2002.
– 210 –
[Parunak 2000]
Parunak, H. Van Dyke: A Practitioners' Review of Industrial Agent Applications. In: Autonomous
Agents and Multi-Agent Systems, 3, S. 389-407, 2000.
[Prasse/Rittgen 1998]
Prasse, Michael; Rittgen, Peter: Bemerkungen zu Peter Wegners Ausführungen über Interaktion
und Berechenbarkeit. In: Informatik Spektrum, 21 (3), S. 141 – 146, 1998.
[PopTop 2003]
PopTop Software: Tropico. URL: http://www.poptop.com/Tropico.htm Abrufdatum: 2003-02-20.
[Rao/Georgeff 1991]
Rao, Anand S. ; Georgeff, Michael P.: Modeling rational agents within a BDI-architecture. In: Proceedings of Knowledge Representation and Reasoning (KR&R-91). Hrsg.: Richard Fikes, Erik
Sandewall. Morgan Kaufmann Publishers, San Mateo, S. 473-484, 1991.
[Repenning 1993]
Repenning, Alexander: Agentsheets: A tool for building domain-oriented dynamic, visual environments. Technical Report CU-CS-693-93, Department of Computer Science, University of
Colorado at Boulder, 1993.
[RFC Editor]
o.V.: Request for Comments Editor. URL: http://www.rfc-editor.org Abrufdatum: 2003-02-15.
[Rosenschein/Genesereth 1985]
Rosenschein, Jeffrey S. ; Genesereth, Michael R.: Deals among rational agents. In: Proceedings of
the Ninth International Joint Conference on Artificial Intelligence (IJCAI-85), Los Angeles,
S. 91–99, 1985.
[Russell/Norvig 1995]
Russell, Stuart J.; Norvig, Peter: Artificial Intelligence: A Modern Approach. Prentice Hall, Englewood Cliffs, 1995.
[Schneider/Voß 2001]
Schneider, Bernd; Voß, Andreas: KI in der betrieblichen Anwendung: Einleitung. Lehrstuhl für
Wirtschaftsinformatik
und
Interorganisationssysteme,
Universität
Münster,
2001.
URL: http://www-wi.uni-muenster.de/wi/lehre/wbs/ws01-02/kiba-kapitel1.pdf Abrufdatum:
2003-02-05.
[Schütte 1998]
Schütte, Reinhard: Grundsätze ordnungsmäßiger Referenzmodellierung. Konstruktion konfigurations- und anmpassungsorientierter Modelle. neue betriebswirtschaftliche forschung (nbf),
Wiesbaden, 1998.
[Searle 1980]
Searle, John R.: Minds, Brains, and Programs. In: The Behavioral And Brain Sciences, 3, S. 417424, 1980.
[Searle 1990]
Searle, John R.: Is the Brain a Digital Computer? APA Proceedings, 64 (3), S. 21-37, 1990.
– 211 –
[Shieber 1994]
Shieber, Stuart M.: Lessons from a Restricted Turing Test. Communications of the ACM, 37 (6),
S. 70-78, 1994.
[Shoham 1990]
Shoham, Yoav: Agent-oriented programming. Technical Report STAN–CS–1335–90, Computer
Science Department, Stanford University, Stanford, 1990.
[Shoham 1993]
Shoham, Yoav: Agent-oriented programming. In: Artificial Intelligence, 60 (1), S. 51-92, 1993.
[Shortliffe 1976]
Shortliffe, Edward H.: Computer-Based Medical Consultation: MYCIN. Elsevier Science, Amsterdam, 1976.
[Silva 1999]
Silva, Alberto R.: AgentSpace Overview. INESC & IST Technical University of Lisbon, 1999.
URL: http://berlin.inesc.pt/agentspace/main-eng.html Abrufdatum: 2003-02-15.
[Silva et al. 2001]
Silva, Alberto R.; Romão, Artur; Deugo, Dwight; Da Silva, Miguel M.: Towards a Reference Model
for Surveying Mobile Agent Systems. In: Autonomous Agents and Multi-Agent Systems, 4,
S. 187–231, 2001.
[Singh 1998a]
Singh, Munidar P.: Agent communication languages: Rethinking the principles. In: IEEE Computer, 31 (12), S. 40-47, 1998.
[Singh 1998b]
Singh, Munidar P.: The Intentions of Teams: Team Structure, Endodeixis, and Exodeixis. In: Proceedings 13th European Conference on Artificial Intelligence. Hrsg.: Henri Prade. John Wiley
and Sons, Chichester, S. 303-307, 1998.
(CiteSeer: http;//citeseer.nj.nec.com/singh98intention.html).
[Slaney/Thiébaux 2001]
Slaney, John; Thiébaux, Sylvie: Blocks World revisited. In: Artificial Intelligence 125, S. 119-153,
2001.
[Smith et al. 1994]
Smith, David C., Cypher, Allen; Spohrer, Jim: (1994), KidSim: Programming Agents Without a
Programming Language. Communications of the ACM, 37 (7), S. 55-67, 1994.
[Strahringer 1996]
Strahringer, Susanne: Metamodellierung als Instrument des Methodenvergleichs - Eine Evaluierung am Beispiel objektorientierter Analysemethoden. Berichte aus der Betriebswirtschaft, Shaker, Aachen, 1996.
[Song et al. 1996]
Song, Hongjun; Franklin, Stan; Negatu, Aregahegn: SUMPY: A fuzzy software agent. In: Proceedings of the ISCA Conference on Intelligent Systems, Reno, S. 124-129, 1996.
– 212 –
[Stärk et al. 2001]
Stärk, Robert F.; Schmid, Joachim; Börger, Egon: Java and the Java virtual machine: definition,
verification, validation. Springer, Berlin et al., 2001.
[Strategor 1997]
Département Stratégie et Politique d’Entreprise du Groupe HEC: Strategor. Politique Générale de
l’Entreprise. 3. Auflage, Dunod, Paris, 1997.
[Steele 1990]
Steele, Guy L.: Common Lisp the Language, 2nd edition. Digital Press, Woburn, 1990.
[Stroustrup 2000]
Stroustrup, Bjarne: The C++ Programming Language, Special Edition. 3. Auflage, AddisonWesley, Reading, 2000.
[Sundsted 1998a]
Sundsted, Todd: An introduction to agents. In: JavaWorld, 3 (6), 1998. URL:
http://www.javaworld.com/javaworld/jw-06-1998/jw-06-howto.html Abrufdatum: 2003-01-12.
[Sundsted 1998b]
Sundsted, Todd: Agents on the move. In: JavaWorld, 3 (7), 1998. URL:
http://www.javaworld.com/javaworld/jw-07-1998/jw-07-howto.html Abrufdatum: 2003-01-12.
[Sun 2001]
Sun Microsystems: Java Remote Method Invocation Specification. Revision 1.8, 2001. URL:
http://java.sun.com/j2se/1.4/docs/guide/rmi/spec/rmiTOC.html Abrufdatum: 2003-03-01.
[Sunflowers 2003]
Sunflowers GmbH: Anno 1503. URL: http://www.anno1503.com Abrufdatum: 2003-02-20.
[Sycara 1998]
Sycara, Katia P.: Multiagent Systems. AI Magazine 19 (2), S. 79-92, 1998.
[Symantec 2003]
Symantec
Security
Response:
W32.Opaserv.Worm.
22.
Januar
2003.
URL:
http://securityresponse.symantec.com/avcenter/venc/data/w32.opaserv.worm.html Abrufdatum:
2003-02-18.
[TAHD 2000]
o.V.: Positivism. In: The American Heritage Dictionary of the English Language, 4. Auflage,
Houghton Mifflin, Boston, 2000.
[Teubner 1999]
Teubner, Rolf Alexander: Organisations- und Informationssystemgestaltung. Theoretische Grundlagen und integrierte Methoden. Gabler, Wiesbaden, 1999.
[Tveit 2001]
Tveit, Amund: A survey of Agent-Oriented Software Engineering. Report, Norwegian University
of Science and Technology, Mai 2000.
[Viroli/Omicini 2002a]
Viroli, Mirko; Omicini, Andrea: A Specification Language for Agents (sic) Observable Behaviour.
In: Proceedings International Conference on Artificial Intelligence (IC-AI'02). Hrsg.: Hamid R.
Arabnia, Youngsong Mun. CSREA Press, Las Vegas, S. 321-327, 2002.
– 213 –
[Viroli/Omicini 2002b]
Viroli, Mirko; Omicini, Andrea: Towards an Alternative Semantics for FIPA ACL. In: Proceedings
Cybernetics and Systems (EMCSR) 2002. Hrsg.: Robert Trappl. Austrian Society for Cybernetic
Studies, Wien, S. 689-694, 2002.
[Wallace 2001]
Wallace, Richard S. (Hrsg.): ALICE A. I. Foundation. Offizielle Homepage, 2001.
URL: http://www.alicebot.org/ Abrufdatum: 2003-02-15.
[Webster 2002a]
o.V.: Agent. In: Merriam-Webster Online Dictionary, Merriam-Webster, Inc., 2002.
URL: http://www.m-w.com/ Abrufdatum: 2003-02-05.
[Webster 2002b]
o.V.: Paradigm. In: Merriam-Webster Online Dictionary, Merriam-Webster, Inc., 2002.
URL: http://www.m-w.com/ Abrufdatum: 2003-02-05.
[Wegner 1997]
Wegner, Peter: Why interaction is more powerful than algorithms. Communications of the ACM,
40 (5), S. 80-91, 1997.
[Weiß 1989]
Weiß, Johannes (Hrsg.): Max Weber heute. Suhrkamp, Frankfurt am Main, 1989.
[West/Levy 1977]
West, Jerome D.; Levy, Ferdinand K.: Management Guide to PERT/CPM. Prentice Hall, Englewood Cliffs, 1977.
[White 1994]
White, J.: Telescript technology: The foundation for the electronic marketplace. Technical report,
General Magic, Inc., 1994.
[Williams/Kindel 1994]
Williams, Sara; Kindel, Charlie: The Component Object Model: A Technical Overview. Microsoft
Corporation, Oktober 1994. URL: http://msdn.microsoft.com/library/default.asp?url=/library/enus/dncomg/html/msdn_comppr.asp Abrufdatum: 2003-03-01.
[Winograd 1972]
Winograd, Terry: Understanding Natural Language. Academic Press, New York, 1972.
[Wolfram 1983]
Wolfram, Stephen: Cellular Automata. Los Alamos Science, 9, S. 2-21, Herbst 1983.
[Wood/Deloach 2001]
Wood, Mark F.; DeLoach, Scott A.: An overview of the multiagent systems engineering methodology. In: Agent-Oriented Software Engineering. Hrsg.: Paolo Ciancarini, Michael Wooldridge.
Springer, Berlin, S. 207-222, 2001.
[Wooldridge 1992]
Wooldridge, Michael: The Logical Modelling of Computational Multi-Agent Systems. Dissertation, Department of Computation, UMIST, Manchester, 1992.
– 214 –
[Wooldridge 1997a]
Wooldridge, Michael: Agent-based Software Engineering. In: IEE Proceedings on Software Engineering, 144 (1), S. 26-37, Februar 1997.
[Wooldridge 1997b]
Michael Wooldridge: Agents as a Rorschach Test: A Response to Franklin and Graesser.
In: Proceedings of the Third International Workshop on Agent Theories, Architectures, and
Languages. Hrsg.: Jörg P. Müller, Michael Wooldridge, Nicholas R. Jennings. S. 47-48, Springer, Berlin, 1997.
[Wooldridge 1998]
Wooldridge, Michael: Verifiable Semantics for Agent Communication Languages. In: Proceedings
of the Third International Conference on Multi-Agent Systems (ICMAS 98). Hrsg.: Yves Demazeau. IEEE Press, Juli 1998.
[Wooldridge et al. 2000]
Wooldridge, Michael; Jennings, Nicholas R.; Kinny, David: The Gaia Methodology for AgentOriented Analysis and Design. In: Autonomous Agents and Multi-Agent Systems, 3, S. 285-312,
2000.
[Wooldridge/Jennings 1995]
Wooldridge, Michael; Jennings, Nicholas R.: Intelligent agents: Theory and practice.
In: Knowledge Engineering Review, 10 (2), S. 115-152, 1995.
[Wooldridge/Jennings 1998]
Wooldridge, Michael; Jennings, Nicholas R.: Pitfalls of agent-oriented development.
In: Proceedings of the Second International Conference on Autonomous Agents (Agents ‘98).
Hrsg.: Katia P. Sycara, Michael Wooldridge. Minneapolis/St. Paul, MN, S. 385-391, Mai 1998.
[Wortmann 2002]
Wortmann, Felix: Konzeption und Implementierung einer Informationsklassifikationskomponente
auf der Basis von Neuronalen Netzen im Rahmen des PI-Agent Projektes. Diplomarbeit am
Lehrstuhl für Wirtschaftsinformatik und Informationsmangament, Universität Münster, Münster,
Januar 2002. (Vgl. auch: URL: http://www.pi-agent.com).
[W3C 2000]
World Wide Web Consortium: W3C Intellectual Rights Notice and Legal Disclaimers. Juni 2000.
URL: http://www.w3.org/Consortium/Legal/ipr-notice-20000612 Abrufdatum: 2003-02-15.
– 215 –
Abschließende Erklärung
Ich versichere hiermit, daß ich meine Masterarbeit Entwicklung eines Metamodells zur
Agentenorientierten Softwareentwicklung selbständig und ohne fremde Hilfe angefertigt
habe, und daß ich alle von anderen Autoren wörtlich übernommenen Stellen wie auch
die sich an die Gedankengänge anderer Autoren eng anlegenden Ausführungen meiner
Arbeit besonders gekennzeichnet und die Quellen zitiert habe.
Münster, den 20. März 2003
Florian Klein