1 Einleitung

ImOktober 1998 wurde zwischen der Me-dizinischen Klinik und Poliklinik mitSchwerpunkt Kardiologie, Angiologie undPulmologie des Universit�tsklinikumsCharit�, dem Lehr- und ForschungsgebietK�nstliche Intelligenz des Instituts f�r In-formatik der Humboldt-Universit�t zuBerlin und der GMD – Forschungszen-trum Informationstechnik GmbH eineKooperationsvereinbarung getroffen. Diegenerelle Erwartung an dieses Forschungs-projekt war die Verbesserung der Koor-dination zwischen den Stationen, der Poli-klinik und den Funktionsbereichen derkardiologischen Klinik (Klinik I) durchden Einsatz eines Softwaresystems. Es solleine bessere Ressourcenauslastung der di-agnostischen Bereiche, eine Minimierungder Patientenwartezeiten und eine bessereInformiertheit aller Beteiligten erreichtwerden. Da das geschaffene System zumt�glichen Einsatz kommen soll, ist die pro-fessionelle Weiterentwicklung und Betreu-ung �ber den Rahmen eines Forschungs-prototyps hinaus notwendig. F�r diesenAufgabenteil zeichnet der industrielle Ko-operationspartner, die NTeam GmbH ver-antwortlich.

Im Rahmen dieser Kooperation istChariTime, ein agentenorientiertes Soft-waresystem, entstanden. Seit Dezember2000 befindet sich dieses System in seinerEinf�hrungsphase in der Klinik I der Cha-rit�. ChariTime wird als Produkt von derNTeam GmbH kommerziell vermarktet.In Zusammenarbeit mit dem zentralen Re-chenzentrum der Charit� soll das Produktso erweitert werden, dass es in allen Klini-ken des Universit�tskrankenhauses einge-setzt werden kann.

In der kardiologischen Klinik der Cha-rit� wird eine Vielzahl komplexer medizi-nischer Beratungs-, Diagnose- und Thera-pieleistungen erbracht. Bedingt durch denqualitativen und quantitativen Umfangdieser Leistungen und die r�umliche Auf-gliederung der Klinik ist eine funktionaleAufteilung der station�ren, poliklinischenund diagnostischen Abteilungen entstan-den, die gravierende Koordinierungspro-blememit sich brachte.

In der Klinik stellen die einzelnen Be-reiche autonom agierende Einheiten dar,die ihre Termine selbstst�ndig koordinie-ren und das dazu notwendige Wissen lokalverwalten. Eine Abbildung dieser Abtei-

lungen auf Agenten, die als ihre Interessen-vertreter an der Terminkoordination teil-nehmen, liegt deshalb nahe. Auch die Pa-tienten werden in ChariTime durch Agen-ten vertreten. An diesem Punkt wird imSoftwaresystem von der Realit�t abge-wichen, insofern dort die Stationen bzw.Sprechstunden die Interessen der Patientenvertreten. Die Patienteninteressen fließenjetzt explizit beim Softwareentwurf durchdie Modellierung des Patienten-Agentenin die Terminkoordination ein. So soll einsolcher Agent beispielsweise versuchen,zusammenh�ngende und kurzfristige Ter-mine zu beschaffen und die Einhaltungvereinbarter Termine zu �berwachen.

2 Systemaufbau

2.1 GrundlegendeSystemanforderungenDie an die Software gestellten Anforde-rungen machen die Entwicklung eines of-fenen und verteilten Systems zur Termin-koordination notwendig. Oberfl�chen-komponenten m�ssen an verschiedensten(heterogenen) Arbeitspl�tzen zur Ver-

f�gung stehen und das zur Terminkoordi-nation notwendige Wissen sollte (zur Ver-meidung von Redundanzen etc.) in derObhut der entsprechenden Bereiche (bzw.ihrer Agenten) verbleiben, die dann f�r diePflege ihrer Daten zust�ndig sind.

Der Aufbau des agentenorientiertenSystems orientiert sich teilweise an denVorschl�gen der FIPA in [FIPA98]. UnterAgenten werden in ChariTime gekapselteSoftwareeinheiten verstanden, die �ber ei-nen eigenen Zustand, eigenes Verhaltenund eigene Rechenzeit verf�gen. DieseAgenten k�nnen mit anderen Einheitenwie Agenten bzw. menschlichen Anwen-dern interagieren, um ihre Ziele zu errei-chen. Ein Agent unterscheidet sich hiervon einer passiven Komponente dadurch,

Dipl. Inform. InesM�nch,Humboldt Universit�t zu Berlin,Institut f�r Informatik, Lehrstuhlf�r K�nstliche Intelligenz, Unter denLinden 6, D-10099 Berlin, E-Mail:muench@informatik.hu-berlin.de;Dipl. Inform.Marcel Gnoth,NTeamGmbH, Lietzenburger Str. 127,D-10707 Berlin,E-Mail: mgnoth@nteam.de

Char iTime –Ein agentenor ient ier tes

Softwaresy stemzur Terminplanung

im Krankenhaus

Ines M�nch, Marcel Gnoth

WI – Innovative Produkte

WIRTSCHAFTSINFORMATIK 43 (2001) 2, S. 183–187 183

dass er die M�glichkeit hat, Nachrichtenzu verschicken und zu empfangen, um se-mantisch motivierte Aufgaben zu erf�llen.Rein passive Komponenten nehmen nichtam Nachrichtenaustausch teil und erledi-gen innerhalb des Systems nur technischrelevante Funktionen im Rahmen der Auf-gaben der Agenten.

Ein Weg, ein solches agentenorientier-tes System zu konstituieren, ist die Umset-zung von Agenten, die miteinander direktkommunizieren k�nnen. F�r die Realisie-rung der einzelnen Aspekte eines solchenSystems m�ssen konkrete Bedingungen er-f�llt sein:

, Die Agenten m�ssen �ber Aufgabenbzw. daraus resultierende Ziele ver-f�gen.

, Um eine aufgabenspezifische Kom-munikation zu erm�glichen, muss eingemeinsames Verst�ndnis der Interakti-onspartner (Agenten) �ber ihre Be-griffswelt existieren (Ontologie).

, Sollen die Agenten die Interessen realerOrganisationseinheiten vertreten, musseine entsprechende Zust�ndigkeit ihrer-seits f�r diese definiert werden.

, F�r die Kommunikation ben�tigen sieein gemeinsam verwendbares Kom-munikationssystem, innerhalb dessen

es eine eindeutige Adressverwaltunggeben muss, deren Erreichbarkeit je-demAgenten bekannt ist.

Alle Agenten k�nnen Basisinformationen(in erster Linie die Adressen der Nachrich-tenwarteschlangen) der anderen Agentenabfragen. Es m�ssen Aufgaben der admi-nistrativen Systemverwaltung von zentra-len Komponenten erledigt werden, wobeidas aufgrund der Interessenvertretungdurch die Agenten notwendige Zust�ndig-keitsmanagement gesondert ber�cksichtigtwird. Diese Dienste werden von Directo-ryFacilitator (DF) und SystemManage-mentAgent (SMA) �bernommen. Der DF�bernimmt alle Standardaufgaben des t�g-lich anfallenden, gr�ßtenteils fachlich ge-pr�gten Managements. Der SMA hingegenist haupts�chlich f�r die technische Ver-waltung der KnowledgeAgents (s. u.) undihrer „Lebensr�ume“ (Workspaces) ver-antwortlich und kontrolliert das Hinzuf�-gen bzw. L�schen aller am System beteilig-ten Agenten.

Die Agenten kommunizieren aus-schließlich �ber asynchrone Nachrichtenmiteinander. Dies ist Voraussetzung f�r dieIntegration weiterer Agenten zu jedem be-liebigen Zeitpunkt. Diese Form der Kom-munikation verhindert außerdem, dassAgenten Aufgaben nicht erledigen k�n-nen, wenn die Erreichbarkeit einzelner In-teraktionspartner nicht gegeben ist. (Esk�nnen in diesem Fall beispielsweise ande-re Interaktionspartner gesucht werden.)Die Kommunikation der Agenten wirddurch passive Komponenten unterst�tzt,die diverse Basisfunktionen zur Verf�gungstellen.

2.2 Agentenmodell

Im Agentenmodell von ChariTime gibt eszwei Agententypen, die �ber ihre auf-gabenbezogenen Verantwortlichkeiten be-z�glich der zu vertretenen Personen bzw.Personengruppen (im weiteren Text auchOrganisationseinheiten genannt) im Sys-tem definiert sind.

Die Informationen zu den einzelnenOrganisationseinheiten werden vonKnowledgeAgents verwaltet. Diese leistendie inhaltliche anwendungsbereichsbezo-gene Arbeit, vertreten also die Interessender beteiligten Personen bzw. Abteilungenbei der Terminkoordination. Sie arbeitendabei mit dem Fachwissen �ber die einzel-nen Organisationseinheiten. Ein Know-

DirectoryFacilitator

User Agent 1

User Agent 2

Workspace ofKnowledgeAgents

asynchronous Messages

util Shared

Graphical User Interface

HTML 3.2

(Thin Client)

Graphical User Interface

Win 32

(Fat Client)

UA

Database

DF

KA

KA

util Message

Data Classof DK

DomainKnowledge

KA5 KA7

OU1 OU2 OU3

util Transfer Msg

Web Server

http

://...

UA

CommunicationChannel

OU4

DomainInfo

Data Classof DF

Data Classof DI

SystemManagement

Agent

SMA

Data Classof SMA

Message Queue

Object Reference

LegendOrgUnit - Object

InProcess Component (DLL)

OutProcess Component (EXE) OU

Bild 1 Systemarchitektur von ChariTime

Ines M�nch, Marcel Gnoth

184

ledgeAgent kann f�r mehrere Organisati-onseinheiten zust�ndig sein, w�hrend esf�r eine Organisationseinheit immer genaueinen zust�ndigenKnowledgeAgent gibt.

Die UserAgents bilden die Schnittstel-len zum Anwender und nehmen ihreHandlungsanweisungen auf bzw. leitendiese weiter. UserAgents fordern von denKnowledgeAgents Wissen an, um es demNutzer �ber eine grafische Oberfl�che an-zeigen zu lassen. Ein UserAgent kann dasWissen mehrerer KnowledgeAgents an denAnwender weitergeben. (Dabei regelt eineRechteverwaltung die Verf�gbarkeit vonInformationen f�r dieUserAgents.)

2.3 Systemarchitektur

ChariTime ist als komponentenbasiertesSoftwaresystem implementiert. Die einzel-nen Komponenten sind objektorientiertaufgebaut. Das System besteht aus aktivenKomponenten (Agenten), die �ber dieM�glichkeit verf�gen, Nachrichten zu ver-schicken und passive Komponenten, diedies nicht k�nnen.

Die aktiv am System beteiligten Kom-ponenten (UserAgents und Knowledge-Agents, DirectoryFacilitator und System-ManagementAgent) k�nnen Nachrichtenerhalten und verschicken. Dies ist durcheine „Nachrichtentonne“ in der Grafikverdeutlicht. Der DirectoryFacilitator undder SystemManagementAgent sind alszentrale Komponenten in einer Instanz imSystem vertreten. Sie legen Informationenmit Hilfe ihrer Datenklassen in einer Da-tenbank ab. Die Datenspeicher von Chari-Time sind der Nachrichten- und der Da-tenbankserver.

Die grafische Oberfl�che ist derzeit so-wohl in Form einesWin32-Clients als auchin Form eines wesentlich „schlankeren“HTML-Clients implementiert bzw. ent-worfen worden. Die beim Anwender zuinstallierende Oberfl�che richtet sich letzt-endlich nach den dort angetroffenen tech-nischen Gegebenheiten. Grunds�tzlichsind plattformunabh�ngig alle Arten vonOberfl�chen denkbar, die mit der Schnitt-stelle des UserAgent interagieren k�nnen.An jedem Computer-Arbeitsplatz wirddurch den Anwender zusammen mit dergrafischen Oberfl�che genau ein User-Agent gestartet. Dieser steuert die gra-fische Oberfl�che zur Interaktion mit demAnwender, kontrolliert die Nachrichten-warteschlange und kommuniziert mit den

anderen Agenten. Dies sind haupts�chlichdie KnowledgeAgents, die den UserAgentmit dem erforderlichen Fachwissen �berdie Organisationseinheiten versorgen.

Die KnowledgeAgents „leben“ inWorkspaces und sind zust�ndig f�r denZugriff auf das Fachwissen ihrer COrgU-nit–Objekte. Daf�r existieren die beidenKomponenten CTDomainKnowledge (f�rterminierungsrelevante Angaben) undCTInfoData (f�r rein informative Anga-ben) mit ihrenDatenklassen. Das Fachwis-sen aller KnowledgeAgents wird derzeitnoch zentral in einer Datenbank gespei-chert. Die Zugriffsrechte f�r das Fachwis-sen sind jedoch eindeutig (anhand der Zu-st�ndigkeit f�r Organisationseinheiten)unter den KnowledgeAgents aufgeteilt, sodass das Fachwissen bei Bedarf auch ver-teilt abgelegt werden kann.

Es gibt drei technischeHilfskomponen-ten, die von fast allen anderen Komponen-ten ben�tigt werden:

– CTUtilShared (enth�lt eine Reihe vonHilfsfunktionen, die alternativ auch re-dundant in den auf sie angewiesenen an-deren Komponenten implementiertwerden k�nnten);

– CTUtilTransferMsg (kapselt den Zu-griff auf das verwendete Nachrichten-system und erm�glicht seine prinzipiel-le Austauschbarkeit);

– CTUtilMessage (gew�hrleistet ein ein-heitliches Format der Nachrichten, ent-h�lt die Aufz�hlungen aller m�glichenNachrichtentypen und Dienste derAgenten und erm�glicht die Kontrolleder Einhaltung der syntaktischen Kom-munikationsprotokolle).

Da im Mittelpunkt dieser Ausf�hrungender inhaltliche Entwurf des Systems steht,wird hier nicht n�her auf die konkrete Im-plementation der einzelnen Komponenteneingegangen.

3 Interessenvertretungdurch Agenten

3.1 Fachwissen der Agenten

Beide beschriebenen Agententypen arbei-ten mit dem Fachwissen der Organisati-onseinheiten. Das Fachwissen ist in Formeines Objektmodells implementiert wor-den. Der zu persistierende Anteil der kon-kreten Informationen wird in einer relatio-nalen Datenbank abgelegt.

Zwischen den einzelnen Organisations-einheiten sind die verschiedensten Bezie-hungen denkbar. Alle Typen von Bezie-hungen zwischen Organisationseinheiten

Kernpunkte f�r dasManagement

Unter der Zielsetzung, die Kundenzufriedenheit (hier der Patienten) zu erh�hen,gestattet es das beschriebene System ChariTime, mehr feste Termine zu planenund aktuelle Informationen umgehend den Betroffenen zu �bermitteln. Zudemerm�glicht es ein solches Terminmanagementsystem, einen �berblick �ber dieterminliche Auslastung der einzelnen Abteilungen zu gewinnen, allerdingsunter der Voraussetzung, dass es von diesen als alleiniges Medium f�r dieseAufgaben verwandt wird.

Der Einsatz eines agentenorientierten Softwaresystems mit integriertemNachrichtensystem bietet:, Agentengest�tzte Ber�cksichtigung der Kundeninteressen bei Termin-

vergabe / und -verschiebung,, Informationsgewinn insbesondere auf der Seite der Dienstleistungsnehmer,, �berblick �ber die terminliche Auslastung der einzelnen Abteilungen,, Verbesserung der abteilungs�bergreifenden Terminkoordination.

Stichworte: Kundenzufriedenheit, Interessenvertretung durch Agenten,Informationsgewinn

ChariTime – Ein agentenorientiertes Softwaresystem

185

werden mit einer Beschreibung der m�gli-chen Kardinalit�ten zwischen den an derBeziehung beteiligten Organisationsein-heiten festgehalten. So ist z. B. die Abbil-dung einer Organisationsstruktur (einebzw. mehrere aufgabenbezogene organisa-torisch verantwortliche Einheiten) m�g-lich.

Das Wissen �ber eine Organisations-einheit (OrgUnit) ist rollenspezifisch auf-gebaut. F�r jede OrgUnit kann �ber dieEigenschaften IsProvider, IsClient, IsRe-quester und IsSeller festgelegt werden,welche Rollen sie bez�glich des Dienstleis-tungsmanagements potenziell einnehmenkann. Dementsprechend verf�gt sie �berden zur Wahrnehmung dieser Rolle not-wendigen Anteil an Informationen. Kon-kret sind dies die bei der Terminierung ei-ner Dienstleistung zu ber�cksichtigenFakten.

Beispielhaft wird im folgenden f�r dieRolle Leistungserbringer erkl�rt, welcheAngaben die Agenten ben�tigen und wiesich diese imObjektmodell widerspiegeln.

Der potenzielle Leistungserbringer ver-f�gt �ber das Spektrum der durch ihn erb-ringbaren Leistungen (AvailableServices)einschließlich ihrer durchschnittlichenAusf�hrungsdauer.

Jede Leistungsart enth�lt einen Verweisauf die „typisierte Bezeichnung“ Service-Type, unter der sie den erreichbaren Leis-tungsnehmern angeboten wird. Es muss si-chergestellt sein, dass eine gemeinsameVorstellung der Kommunikationspartnervon den sich hinter diesen Dienstleistungs-

arten verbergenden Leistungen herrscht,d.h. sie m�ssen gegebenenfalls noch �f-fentlich beschrieben werden.

Es werden die regelm�ßigen Arbeitszei-ten und Auszeiten (pro Wochentag) in denSperrzeiten f�r die Leistungserbringung(ProviderOffTimes) erfasst, die die gene-relle (Nicht-) Verf�gbarkeit des Leistungs-erbringers kennzeichnen. Zudem legt jederLeistungserbringer fest, welches m�glicheZeitr�ume sind, in denen Dienstleistungendurch das System terminiert werden d�r-fen (ProviderAppointmentTimes). DieseZeiten k�nnen sowohl in Form von Zeit-regeln als auch in Form von konkretenZeitr�umen angegeben werden.

Zur zeitlichen Einordnung der Dienst-leistungen sind neben der generellen Ver-f�gbarkeit die speziellen Sperrzeiten inForm der f�r andere Ereignisse bereits re-servierten Zeitr�ume wichtig (andere Leis-tungen inkl. ihrer Eigenschaften Begin undDuration). Zus�tzlich zu diesen offen-sichtlichen zeitlichen Einschr�nkungensollen sowohl personelle als auch ger�te-technische Beschr�nkungen ber�cksichtigtwerden, die als Einsch�tzungen der aus ih-nen resultierenden Leistungsf�higkeit desLeistungserbringers einfließen (Limits).

Alle terminierungsrelevanten Angabenwerden durch einen Transformationspro-zess in pr�dikatenlogische Ausdr�cke�berf�hrt (siehe [HaM�00]) und vomKnowledgeAgent zur Realisierung seinerAufgaben im Rahmen der Terminkoordi-nation verwendet.

3.2 Verarbeitung desWissensdurch die AgentenKnowledgeAgents verf�gen nur �ber dasWissen der Organisationseinheiten, die ih-nen zugeordnet sind. Sie haben keine In-formationen �ber Organisationseinheitenanderer KnowledgeAgents. Diese m�ssensie bei Bedarf von den anderen Agenten�ber das Nachrichtensystem erfragen.

Auf Grund der Verantwortung desKnowledgeAgent f�r reale Organisations-einheiten muss er aktiv Umweltbedingun-gen im System �berwachen und unter Um-st�nden selbstst�ndig aktiv werden (z. B.nach Notfall wird der Funktionsbereichgeschlossen, er muss sowohl UserAgentsbenachrichtigen als auch einen neuen Ter-min aushandeln bzw. alternative Dienst-erbringer suchen). Dieses Verhalten wirddurch eine BDI-Architektur des Know-ledgeAgent realisiert (siehe [RaGe95]).DerKnowledgeAgent hat ein Umweltwissen(Belief), leitet daraus W�nsche (Desire) abund versucht, diese W�nsche mit konkre-tenHandlungen (Intentions) umzusetzen.

In Abh�ngigkeit von den Rechten derUserAgents werden die Informationen f�rdie entsprechenden Organisationseinhei-ten an der grafischen Oberfl�che pr�sen-tiert. Dabei werden die zwischen den Or-ganisationseinheiten bestehenden Bezie-hungen ber�cksichtigt. Auf der Seite derPatientenverwalter und Anforderer ist diesdie organisatorische Verantwortlichkeitf�r Patienten, auf der Seite des Anbietersdie Zusammensetzung der diagnostischenBereiche aus einzelnen Untersuchungs-pl�tzen. Das Recht zur Ansicht der jeweils�bergeordneten Organisationseinheitschließt das Recht auf die Informationenderart „untergeordneter“ Organisations-einheiten ein.

F�r die Visualisierung der Daten einerOrganisationseinheit k�nnen mehrereUserAgents registriert werden. So ist eszum Beispiel denkbar, dass leitende Per-sonen sich alle Daten aller Organisations-einheiten anzeigen lassen, w�hrend paralleldazu an den anderen Computer-Arbeits-pl�tzen nur die dort ben�tigte (Teil-) An-sicht an Organisationseinheiten sichtbarist.

Einen Ausschnitt der Sicht an einemzentralen Arbeitsplatz (hier z. B. f�r alleFunktionsbereiche der Klinik I ) zeigt Bild3. F�r die Anwender der anbietenden Ab-teilungen (Funktionsbereiche und Sprech-stunden) werden in einer kalendarischen

Successor

Provider

Time

Time

AvailableServiceLimit

ServiceTypeTitleRemarkInfoSpecification

ServiceStatePriorityBegin

VariabilityProviderClientRequester

11

Predecessor0..1

ProviderSequence of Calls

0..1

AvailableServiceAverageDuration 110..*

Provider

AvailableServices0..*

ProviderAppointmentTimes

0..*

ProviderOffTimes

0..* Providing /Provided Services0..*

LimitTitleValue 0..* 0..*

0..*Limits

Provider

Duration

Bild 2 Klassendiagramm der Angaben eines Leistungserbringers

Ines M�nch, Marcel Gnoth

186

�bersicht alle vereinbarten Termine bzw.die abzurufenden Patienten angezeigt.Hier sollen durch die Anwender unter an-derem die Zeiten, in denen Knowledge-Agents selbstst�ndig Termine eintragend�rfen, freigegeben werden (bezeichnet als„Zeitraum f�r automatische Terminver-gabe“).

F�r die Anwender der anforderndenAbteilungen (Stationen und Sprechstun-den) beinhalten diese die Patientendatenund alle Angaben �ber ihre Untersuchun-gen. Die Stationsschwester legt f�r dieKnowledgeAgents der Patienten die Rah-menbedingungen f�r die Terminkoordina-tion fest. Dazu geh�rt beispielsweise diemaximal zumutbare Wartezeit zwischenzwei Untersuchungen.

4 Zusammenfassung

Mit ChariTime ist ein agentenorientiertesSoftwaresystem entstanden, in dem Agen-ten als Interessenvertreter von Personenbzw. Personengruppenmiteinander intera-gieren k�nnen, um bestimmte Aufgabenzu erf�llen. Die beschriebene Kombinati-on von Konzepten zur Terminkoordinati-on von Organisationseinheiten und derDefinition von Verantwortlichkeiten undRollen der Agenten kann als grundlegen-des Modell f�r die �bertragung vonHandlungstr�gerschaft des Menschen aufAgenten verwendet werden. Die Agentensind nicht nur in der Lage, Dienstleistun-gen in der Klinik I der Charit� zu mana-

gen, sondern dieses System kann auch per-spektivisch in mehreren Kliniken oderVerwaltungsbeh�rden mit komplexenStrukturen eingesetzt werden. Die demSystem zugrunde liegenden Konzepte undImplementationsstrategien erm�glicheneine vielseitige Vermarktung des entstan-denen Produktes.

Literatur

[Booc99] Booch, G.; Rumbaugh J.; Jacobson, I.:The Unified Modeling Language User Guide.Addison-Wesley, 1999.

[FIPA98] FIPA: FIPA 98 Specification Version1.0. http://www.fipa.org

[Fowl99] Fowler, M.: Analysemuster Wiederver-wendbare Objektmodelle. Addison-Wesley,1999.

[GnM�99] Gnoth, M.; M�nch I.: ChariTime Sys-tementwurf. Studienarbeit am Institut f�r In-formatik der HU Berlin, Lehrstuhl f�r KI,1999.

[HaM�00] Hannebauer, M.; M�nch I.: Transfor-ming Object-Oriented Domain Models intoDeclarative CLP Expressions. Accepted forWLP 2000,W�rzburg.

[M�nc00] M�nch, I.; Lindemann v. Trzebia-towski, G.: ChariTime – Concepts of Analysisand Design of an Agent-Oriented System forAppointment Management. Fundamenta In-formaticae, 2000.

[JeWo98] Jennings, N.R.; Wooldridge, M.J.:Agent Technology – Foundations, Applica-tions, andMarkets. Springer, 1998.

[RaGe95] Rao, A.S.; Georgeff, M.P.: BDI Agents:From Theory to Practice. In: Lesser,V.~ed.~Proceedings of the 1st InternationalConference on Multi-Agent Systems (ICMAS),MIT Press, 1995, S. 312–319.

[Step98] Stephens, Larry M.; Dowell M.L.; Bon-nell R.D:Using ADomain-Knowledge Ontol-ogy as a Semantic Gateway among InformationResources. In: Huhns, M. N.; Singh, M. P.(eds.): Readings in Agents. Morgan KaufmannPublishers Inc., San Francisco, CA 1998,S. 255–260.

Bild 3 Bildschirmmaske aus Sicht der anbietenden Bereiche

ChariTime – Ein agentenorientiertes Softwaresystem

187