Inauguraldissertation
zur Erlangung des akademischen Grades
eines Doktors der Wirtschaftswissenschaften
des Fachbereichs Wirtschaftswissenschaften
der Universität Osnabrück
Agentenbasierte Assistenz für Management Support Systeme
- Konzeption und prototypische Realisierung -
vorgelegt von
Dipl.-Kffr. Heike Dalinghaus
Dekan: Prof. F. Westermann, Ph.D.
Referent: Prof. Dr. B. Rieger
Korreferent: Prof. Dr. Th. Witte
Tag der mündlichen Prüfung: 30.03.2009
Vorwort
Diese Arbeit entstand während meiner Lehr- und Forschungstätigkeit am Fachgebiet
BWL/Management Support und Wirtschaftsinformatik des Instituts für Informations-
management und Unternehmensführung (IMU) im Fachbereich Wirtschaftswissen-
schaften der Universität Osnabrück.
Mein Dank gilt vor allem meinem Doktorvater Herrn Prof. Dr. Bodo Rieger für die
wissenschaftliche Betreuung der Arbeit und seine weitreichende Unterstützung. Er
stand mir während der Erstellung dieser Arbeit mit konstruktiver Kritik und vielen
Anregungen zur Seite und gewährte mir stets die nötigen Freiräume. Herrn Prof. Dr.
Thomas Witte danke ich für die Übernahme des Korreferats.
An dieser Stelle möchte ich mich darüber hinaus bei allen Menschen in meiner Arbeits-
wie persönlichen Umgebung bedanken, die mich direkt oder indirekt bei der Entstehung
dieser Arbeit unterstützt und zum Gelingen beigetragen haben.
Heike Dalinghaus
Inhaltsverzeichnis Abbildungsverzeichnis.................................................................................................... III Tabellenverzeichnis ......................................................................................................... V Abkürzungsverzeichnis................................................................................................... VI 1 Einleitung..................................................................................................................... 1
1.1 Problemstellung und Zielsetzung.......................................................................... 1 1.2 Aufbau der Arbeit ................................................................................................. 2 I Assistenzbedarf von Management Support Systemen 2 Management Support Systeme .................................................................................... 5
2.1 Ziele und Definition von MSS.............................................................................. 5 2.2 Klassifikation der MSS......................................................................................... 9 2.3 Funktionsspektrum von MSS-Werkzeugen ........................................................ 13 3 Beispiel-Szenario für den MSS-Einsatz .................................................................... 16
3.1 Managementspektrum der Universität Osnabrück ............................................. 16 3.2 IT-Infrastruktur der Universität Osnabrück........................................................ 19 3.3 Ein typisches MSS-gestütztes Beispiel-Szenario der Universität Osnabrück .... 25 4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario.............................................. 28
4.1 Identifikation und Analyse des Unterstützungsbedarfs ...................................... 28 4.2 Klassifikation des Unterstützungsbedarfs........................................................... 32 4.3 Anforderungen/Charakteristika einer Assistenz ................................................. 34 II Agentenbasiertes Konzept einer MSS-Assistenz 5 Gestaltungspotenziale des agentenbasierten Paradigmas .......................................... 38
5.1 Definition und Eigenschaften von Agenten........................................................ 38 5.2 Klassifikationsansätze von Agenten ................................................................... 40 5.3 Architekturmodelle von Agenten........................................................................ 43 5.4 Kommunikationsverfahren und -protokolle........................................................ 45 5.5 Kooperationsformen und -protokolle.................................................................. 49
Inhaltsverzeichnis II
6 MSS-Assistenz Konzept ............................................................................................ 55
6.1 Gesamtkonzept.................................................................................................... 55 6.2 Architekturkomponenten .................................................................................... 57 6.2.1 Assistant Agent ......................................................................................... 57 6.2.2 Vermittlungsagent..................................................................................... 58 6.2.3 Funktionsagenten ...................................................................................... 59 6.2.4 MSS-Metadatenbasis ................................................................................ 61 6.3 Zusammenspiel der Komponenten ..................................................................... 63 III Prototypische Realisierung einer agentenbasierten MSS-Assistenz 7 Entwicklungs- und Domänenumgebung des Prototyps ............................................. 66
7.1 Entwicklungsumgebungen des Prototyps ........................................................... 66 7.1.1 Java Agent Development Framework....................................................... 66 7.1.2 Java Expert System Shell.......................................................................... 69 7.2 MSS-Domänenumgebung................................................................................... 73 7.2.1 Cognos ReportNet / Cognos PowerPlay................................................... 73 7.2.2 MSS-Metadatenmodell ............................................................................. 79 7.2.3 MSS-Metadaten-Bewirtschaftung ............................................................ 81 8 Beschreibung des Prototyps....................................................................................... 88
8.1 Klassenmodell des MSS-Assistenzsystems ........................................................ 88 8.2 Dokumentation der einzelnen Komponenten ..................................................... 89 8.2.1 MSSAssistanceAgent................................................................................ 89 8.2.2 BrokerAgent.............................................................................................. 91 8.2.3 InterpretationAgent ................................................................................... 96 8.2.4 QueryAgent............................................................................................... 97 8.2.5 SearchAgent.............................................................................................. 99 8.2.6 NavigationAgent..................................................................................... 100 8.3 Koordination des BrokerAgent......................................................................... 103 9 Einsatz des implementierten MSS-Assistenzsystems.............................................. 106
9.1 Übersicht der Anwendungsfälle........................................................................ 106 9.2 Anwendungsfälle .............................................................................................. 106 9.2.1 Fall 1: MSS-Werkzeug-übergreifende Informationssuche ..................... 106 9.2.2 Fall 2: Metadatensuche ........................................................................... 113 9.2.3 Fall 3: Automatische Informationsgenerierung ...................................... 115 9.3 Bewertung des Prototyps .................................................................................. 119 10 Zusammenfassung und Ausblick ........................................................................... 123 Literaturverzeichnis ...................................................................................................... 126 Anhang.......................................................................................................................... 139
Abbildungsverzeichnis
Abb. 2-1: Einordnung unterschiedlicher Facetten von BI [vgl. Gluc01, S. 7] ............... 8
Abb. 3-1: Professionelle Bürokratie nach Mintzberg [vgl. Mint79, S. 355] ................ 17
Abb. 3-2: Management Information System der Universität Osnabrück ..................... 21
Abb. 3-3: Screenshot eines analytischen Berichts der Studierendendaten ................... 23
Abb. 3-4: Screenshot eines Standardberichts über die Prüfungstermin-Belegung....... 24
Abb. 4-1: Beispiel einer analytischen Berichtssicht über die Prüfungsbelastung ........ 30
Abb. 4-2: Angepasste Berichtssicht über die Prüfungsbelastung ................................. 31
Abb. 5-1: Klassifikation von Gilbert et al. [GAA+95] [vgl. Brad97, S. 9] .................. 41
Abb. 5-2: Klassifikation von Franklin und Graesser [FrGr97, S. 31] .......................... 42
Abb. 5-3: Klassifikation von Nwana [vgl. Nwan96] .................................................... 43
Abb. 5-4: Aufbau eines Blackboard-Systems [BZW98, S. 97] .................................... 46
Abb. 5-5: Kommunikationsprinzip nachrichtenorientierter
Systeme [BZW98, S. 102] ............................................................................ 47
Abb. 5-6: Kooperationstypologie von Franklin [DFJN97, S. 2] .................................. 50
Abb. 5-7: FIPA Request Interaction Protocol Specification [FIPA02c, S. 1] .............. 53
Abb. 6-1: Agentenbasiertes Konzept der MSS-Assistenz ............................................ 56
Abb. 7-1: Allgemeine interne Architektur eines JADE-Agenten
[vgl. Bell01, S. 12]....................................................................................... 69
Abb. 7-2: Aufbau eines typischen regelbasierten Systems [vgl. Frie03, S. 20] ........... 72
Abb. 7-3: Cognos ReportNet-Architektur [vgl. Cogn06a, S. 13] ................................. 74
Abb. 7-4: Cognos PowerPlay-Architektur [vgl. Cogn04a, S. 10-11] ........................... 76
Abb. 7-5: Datenmodell der MSS-Metadatenbasis ........................................................ 79
Abb. 7-6: Aufbau der manuellen Komponente zur Konfiguration und Befüllung
der MSS-Metadatenbasis .............................................................................. 82
Abb. 7-7: Dialog-Fenster der Funktion „add Information object“ ............................... 83
Abb. 7-8: Dialog-Fenster der Funktion „edit Information object“ ............................... 84
Abb. 7-9: Schematischer Aufbau der (teil-)automatisierten Komponente zur
MSS-Metadaten-Bewirtschaftung ................................................................ 85
Abb. 7-10: Auszüge aus einer MDL-Datei ..................................................................... 86
Abb. 8-1: Ausschnitt des Klassenmodells nur mit den Agentenklassen....................... 89
Abb. 8-2: Behaviour-Klassen des MSSAssistanceAgent ............................................. 90
Abbildungsverzeichnis IV
Abb. 8-3: JADE- und JESS-Codeausschnitte des BrokerAgent zur Ermittlung
einer Strategie ............................................................................................... 93
Abb. 8-4: Behaviour-Klassen des BrokerAgent ........................................................... 94
Abb. 8-5: Behaviour-Klassen des InterpretationAgent................................................. 96
Abb. 8-6: Behaviour-Klassen des QueryAgent (Qagent1) ........................................... 98
Abb. 8-7: Behaviour-Klassen des SearchAgent ......................................................... 100
Abb. 8-8: Behaviour-Klassen des NavigationAgent................................................... 102
Abb. 8-9: Arbeitsweise des BrokerAgent ................................................................... 104
Abb. 9-1: Aufbau des Tasks-Menü des MSS-Assistenzsystems ................................ 107
Abb. 9-2: Dialogfenster der Task „Comprehensive Search“...................................... 108
Abb. 9-3: Dialogfenster der Anwenderrückfrage ....................................................... 109
Abb. 9-4: Präsentation der Ergebnisse der Task „Comprehensive Search“ ............... 110
Abb. 9-5: Dialogfenster der Task „OLAP Search“..................................................... 111
Abb. 9-6: Nachrichtenaustausch bei der Task „Comprehensive Search“................... 112
Abb. 9-7: Dialogfenster der Task „Access Metadata“................................................ 114
Abb. 9-8: Nachrichtenaustausch bei der Task „Access Metadata“ ............................ 115
Abb. 9-9: Dialogfenster der Task „Generate OLAP Report“ ..................................... 116
Abb. 9-10: Beispiel einer mittels „Generate OLAP Report“
erzeugten Berichtssicht .............................................................................. 117
Abb. 9-11: Dialogfenster zum Editieren der Metadaten eines neuen
OLAP-Berichtes.......................................................................................... 118
Abb. 9-12: Nachrichtenaustausch bei der Task „Generate OLAP Report“ .................. 119
Tabellenverzeichnis
Tab. 3-1: Zuordnung der Managementaufgaben zu den Organisationsbereichen ........ 19
Tab. 4-1: Mögliche MSS-Unterstützungsfunktionen.................................................... 34
Tab. 5-1: Parameter einer FIPA-ACL Nachricht [vgl. FIPA02a, S. 2] ........................ 48
Tab. 5-2: Beispiele der Performative in FIPA-ACL [vgl. FIPA02b, S. 2] ................... 49
Tab. 6-1: Übersicht über die Funktionsagenten des Assistenzsystems ........................ 59
Tab. 6-2: Übersicht über die MSS-Metadaten .............................................................. 61
Tab. 7-1: Systembefehle von JESS............................................................................... 71
Tab. 8-1: Funktionen des MSSAssistanceAgent .......................................................... 89
Tab. 8-2: Standardstrategien des BrokerAgent............................................................. 92
Tab. 8-3: Berichtstemplates des NavigationAgent ..................................................... 102
Abkürzungsverzeichnis
AMS Agent Management System
ACL Agent Communication Language
ASCII American Standard Code for Information Interchange
BI Business Intelligence
BLOB Binary Large Object
BSC Balanced Scorecard
CBR Case Based Reasoning
CLIPS C Language Integrated Production System
CO Controlling
CPU Central Processing Unit
CRM Customer Relationship Management
CSV Comma Separated Version
DBMS Datenbankmanagementsystem
DF Directory Facilitator
DSS Decision Support System
DV Datenverarbeitung
DWH Data Warehouse
EDV Elektronische Datenverarbeitung
EIS Executive Information System
ERP Enterprise Resource Planning
ESS Executive Support System
ETL Extraktion, Transformation, Laden
FI Finance
FIPA Foundation for Intelligent Physical Agents
FM Facility Management
FSM Finite State Machine
GA Genetische Algorithmen
GUI Graphical User Interface
HIS Hochschulinformationssystem
HR Human Resource
HRG Hochschulrahmengesetz
Abkürzungsverzeichnis VII
HTML Hypertext Markup Language
i. e. S. im engeren Sinne
IBM International Business Machines
IT Informationstechnologie
IuK Information und Kommunikation
IWUI Interactive Web-based University Information System
JADE Java Agent Development Framework
JESS Java Expert System Shell
KI Künstliche Intelligenz
KQML Knowledge Query and Manipulation Language
LGPL Lesser General Public License
LHS Left-Hand Side
LISP List Processing
MDC Multidimensional Cube
MDL Model Definition Language
MIS Management Information System
MSS Management Support System
NHG Niedersächsisches Hochschulgesetz
OCLC Online Computer Library Center
OLAP Online Analytical Processing
PICA Project of Integrated Catalogue Automation
PDF Portable Document Format
POS Prüfungsorganisationssystem
PPR PowerPlay Report
PPX PowerPlay Portable Report
PSM Public Sector Management
RHS Right-Hand Side
RMA Remote Monitoring Agent
SAP Systeme, Anwendungen und Produkte in der Datenverarbeitung
SOS Studentenorganisationssystem
SQL Structured Query Language
SS Sommersemester
Stud.IP Studienbegleitender Internetsupport von Präsenzlehre
TILAB Telecom Italia Lab
Abkürzungsverzeichnis VIII
UB Universitätsbibliothek
UML Unified Modeling Language
URL Uniform Resource Locator
virtUOS Zentrum für Informationsmanagement und virtuelle Lehre
WS Wintersemester
WWW World Wide Web
XML Extensible Markup Language
ZUL Zulassungssystem
1 Einleitung
1.1 Problemstellung und Zielsetzung
Zur Lösung der vielfältigen Planungs- und Entscheidungsaufgaben stehen dem Manage-
ment inzwischen häufig mehrere unterschiedliche Management Support System-(MSS-)
Werkzeuge zur Verfügung. Jedes einzelne MSS-Werkzeug bietet dabei ein umfang-
reiches Spektrum an Funktionen an. Durch die zunehmende Funktionsvielfalt je MSS-
Werkzeug, aber auch durch die steigende Anzahl an MSS-Werkzeugen werden immer
höhere Anforderungen an die Anwender im Umgang mit diesen Werkzeugen gestellt.
Die Problemlösung bzw. Entscheidungsfindung erfordert zumeist den kombinierten
Einsatz unterschiedlicher MSS-Werkzeuge und MSS-Funktionen. Zur Unterstützung
bei Auswahl und Einsatz stehen den Anwendern oft nur die von den MSS-Werkzeug-
Anbietern mitgelieferten Online-Hilfen und Dokumentationen zur Verfügung. Diese
sind punktuell und anwendungsunabhängig ausgerichtet, d. h. sie bieten Hilfestellungen
für einzelne MSS-Funktionen, nicht aber für den gesamten Prozess der Problemlösung.
Wie Erfahrungen im MIS-Projekt1 an der Universität Osnabrück gezeigt haben, bereitet
jedoch häufig dieser Lösungsprozess den Anwendern Schwierigkeiten.
Mittels des Wissensmanagement wurde bereits versucht, dem Management eine Unter-
stützung dafür zu bieten. Die Möglichkeiten beschränken sich jedoch überwiegend dar-
auf, zusätzliche Informationen bzw. Informationsquellen dem Anwender zur Verfügung
zu stellen, indem das Erfahrungswissen einzelner menschlicher Experten fallbezogen
erhoben, gesammelt und aufbereitet wird [vgl. MeRi01a, S. 102-105; Ment03, S. 36-
44]. Dies entspricht somit nicht dem Unterstützungsbedarf von MSS-Werkzeugen, da es
sich dabei nur um einzelfallbezogene Informationen handelt.
Ziel dieser Arbeit ist es, das Konzept einer agentenbasierten MSS-Assistenz vorzustel-
len, das es ermöglicht, dem Management in allen Phasen des gesamten Problem-
lösungsprozesses und für alle Typen von MSS-Werkzeugen eine Unterstützung anzu-
bieten. Anhand repräsentativer Anwendungsbeispiele des besonders stark verbreiteten
und erklärungsbedürftigen, analytischen Berichtswesens (OLAP2) werden potenzielle
Defizite der Anwender bei der Nutzung von MSS identifiziert und in Form eines
1 Das Projekt „MIS“ wurde vom Stifterverband für die Deutsche Wissenschaft im Rahmen seines Pro-
gramms „Reformuniversitäten“ von 1998-2000 gefördert. Der Name MIS steht hierbei als Abkürzung für den Projekttitel „Entwicklung eines Management-Informations-Systems zur Verbesserung der Leitungs- und Entscheidungsgrundlagen“ [vgl. Rieg00, S. 1-2].
2 Die Abkürzung OLAP steht für Online Analytical Processing.
1 Einleitung 2
Spektrums möglicher Assistenzfunktionen zusammengetragen. Als Lösungsansatz für
die Implementierung dieser Assistenzfunktionen wurde das Agentenparadigma gewählt,
mit dem Ziel, die Anwendbarkeit der agentenbasierten Konzepte zu untersuchen.
1.2 Aufbau der Arbeit
Die Arbeit gliedert sich in drei Blöcke. Schwerpunkt des ersten Blocks ist die Ermitt-
lung des Assistenzbedarfs von Management Support Systemen. Dazu wird zunächst im
zweiten Kapitel die Systemklasse MSS bezüglich Definition, Zielen, sowie verschie-
dener Klassifizierungen untersucht. Anhand einer ausgewählten MSS-Klassifikation
erfolgt anschließend die detaillierte Beschreibung des Funktionsspektrums einzelner
MSS-Werkzeugklassen.
Die Identifizierung des MSS-Unterstützungsbedarfs erfolgt falltypbezogen am Beispiel
der Universität Osnabrück. Hierzu wird im dritten Kapitel ein repräsentatives Beispiel-
Szenario angeführt. Das Kapitel beginnt mit einer Beschreibung des Managementspek-
trums der Universität Osnabrück. Es folgt die Vorstellung der bestehenden IT-Infra-
struktur. Sowohl die Komponenten der Infrastruktur, als auch deren Zusammenwirken
werden dokumentiert. Für eine genaue Identifikation potenzieller Defizite beim Um-
gang mit den MSS-Werkzeugen ist es erforderlich, typische Management-Szenarien zu
betrachten, welche den Umgang mit MSS-Werkzeugen vorsehen bzw. verlangen. Als
konkretes Beispiel werden für den Einsatz von MSS-Werkzeugen im Rahmen einer
Managementaufgabe, wie z. B. der Unterstützung von Bleibeverhandlungen, die
Anwendungsfälle skizziert.
Das vierte Kapitel konzentriert sich auf die Untersuchung des Unterstützungsbedarfs.
Anhand des ausgewählten Beispiel-Szenarios werden die Probleme und Schwierigkei-
ten, die die Anwender im Umgang mit MSS-Werkzeugen im Allgemeinen und mit
OLAP-Systemen im Speziellen haben, beschrieben und analysiert. Aus der Analyse
ergibt sich eine Klassifikation des potenziellen Unterstützungsbedarfs in inhaltliche und
funktionale Unterstützungsbereiche. Da bei der Problemlösung stets mehrere der Unter-
stützungsfunktionen fallspezifisch kombiniert ausgeführt werden müssen, lassen sich
eine Reihe von Charakteristika ableiten, die ein MSS-Assistenzsystem erfordert. Die
festgestellten Anforderungen gehen über die Eigenschaften konventioneller Systeme
hinaus, so dass die Agententechnologie als ein geeigneter Lösungsansatz angesehen
1 Einleitung 3
wird. Daher wird in dieser Arbeit eine Lösung basierend auf der Agententechnologie
untersucht.
Der zweite Block befasst sich mit dem Konzept einer agentenbasierten Assistenz für
Management Support Systeme. Im fünften Kapitel erfolgt zunächst ein allgemeiner
Überblick über die Technologie der Agenten. Es wird die in dieser Arbeit verwendete
Definition von Agent und Multi-Agentensystem präsentiert, auf die Eigenschaften, so-
wie auf die verschiedenen Arten der Klassifizierung von Agenten eingegangen. Des
Weiteren werden die unterschiedlichen Architekturen, Kommunikations- und Koopera-
tionsformen von Agentensystemen vorgestellt. Die Beschreibungen über die Agenten-
konzepte dienen dazu die Gestaltungsspielräume aufzuzeigen, die zur Konzeption eines
agentenbasierten MSS-Assistenzsystems herangezogen werden können.
Im sechsten Kapitel wird das MSS-Assistenz Konzept entwickelt. Dazu wird das Ge-
samtkonzept vorgestellt, welches auf Basis der Analyse des Szenarios erstellt wurde.
Dann werden die einzelnen vorgesehenen Architekturkomponenten betrachtet und das
geplante Zusammenspiel der Komponenten beschrieben.
Gegenstand des dritten Blocks ist die prototypische Realisierung der agentenbasierten
MSS-Assistenz. In Kapitel sieben werden die für die Implementierung des Prototyps
verwendeten Entwicklungsumgebungen JADE und JESS3 vorgestellt. Des Weiteren
wird die gewählte MSS-Domänenumgebung, die durch das Standard-Reporting-Werk-
zeug Cognos ReportNet, das OLAP-Werkzeug Cognos PowerPlay und eine MSS-Meta-
datenbasis gekennzeichnet wird, beschrieben.
Der Schwerpunkt des achten Kapitels liegt in der systemtechnischen Beschreibung des
Prototyps. Nach der Dokumentation des Klassenmodells des MSS-Assistenzsystems
folgt eine detaillierte Beschreibung der insgesamt sechs Architekturkomponenten. Das
konzipierte Systemverhalten wird schließlich anhand der Koordinationsabläufe der
zentralen Architekturkomponente dokumentiert.
Im neunten Kapitel wird der Einsatz des implementierten MSS-Assistenzsystems be-
schrieben. Dies geschieht anhand von drei ausgewählten Anwendungsfällen, die hin-
sichtlich der betrachteten Fragestellung detailliert dargestellt werden. Auf Basis der
beschriebenen Fälle erfolgt eine Bewertung des Prototyps. Die Arbeit schließt in Kapi-
tel zehn mit einer Zusammenfassung und einem Ausblick.
3 JADE ist die Abkürzung für Java Agent Development Framework und JESS steht für Java Expert
System Shell.
TEIL I
ASSISTENZBEDARF VON
MANAGEMENT SUPPORT
SYSTEMEN
2 Management Support Systeme
2.1 Ziele und Definition von MSS
Unter dem Begriff Management Support System (MSS)1 wird „...jegliche Kombination
von Informations- und Kommunikationstechnologie zur Unterstützung von Manage-
ment-Aufgaben(trägern)“ [KMR01, S. 287] verstanden. Als Oberbegriff fasst MSS ver-
schiedenste IT-basierte Konzepte und Systeme zusammen, die im Laufe der Jahre mit
dem Ziel entwickelt wurden, das Management bei seinen vielfältigen Planungs- und
Steuerungsaufgaben zu unterstützen [vgl. GGC97, S. 1; Gabr99, S. 419; GaGl97a, S.
308-309; GGD08, S. 15]. Neben der generellen Versorgung des Managements mit
Informationen umfasst die Unterstützung durch MSS auch die Bereitstellung von
Methoden und Modellen zur Lösung konkreter Entscheidungsprobleme. Das im Laufe
der Jahre entstandene MSS-Werkzeugspektrum „...reicht von datenorientierten Infor-
mationssystemen bis zu Problemlösungssystemen für verschiedenste Problemklassen“
[GaGl97a, S. 310]. Durch die Rechnerunterstützung soll das Management in die Lage
versetzt werden, schnell bzw. zeitnah Entscheidungen treffen zu können, die eine hohe
Qualität besitzen [vgl. GaGl97a, S. 310].
Mit dem Begriff Management werden in der Literatur der Managementforschung [vgl.
Stae99, S. 71; StSc93, S. 5-6] zwei unterschiedliche Begriffsinhalte verbunden: „Mana-
gement im funktionalen Sinn“ [Stae99, S. 71] und „Management im institutionalen
Sinn“ [Stae99, S. 71]2. Im funktionalen Sinn steht Management für die Aufgaben, d. h.
die Tätigkeiten, die zur Steuerung der betrieblichen Leistungsprozesse in einer Organi-
sation bzw. Unternehmung auszuführen sind [vgl. StSc93, S. 6]. Zu den typischen
Management-Aufgaben bzw. -Funktionen zählen dabei die Planung, Organisation, Füh-
rung und Kontrolle [vgl. Stae99, S. 71], die grundsätzlich auf allen Ebenen in allen
Bereichen einer Organisation anfallen [vgl. StSc93, S. 7]. Aus institutionaler Sicht wird
mit Management der Personenkreis beschrieben, der in der Organisation Entscheidungs-
1 Mit „Management Support Systems (MSS) is the use of computers and related Information
Technologies to support managers” [Scot83, S. 5] definierte Scott Morton Anfang der 80er Jahre als Erster diesen Begriff. Laut Scott Morton gehören nur die Informations- und Kommunikationssysteme (IuK-Systeme) zu MSS, die dem Management eine Unterstützung bieten. „It is ’support’ that differentiates MSS from so many other applications of information technology“ [Scot83, S. 3].
2 Während der funktionale Ansatz auf die Arbeit von Fayol [Fayo16] zurückzuführen ist, basiert der jüngere institutionale Ansatz auf der empirischen Managementforschung von Carlson [Carl51] [vgl. Stae99, S. 80].
2 Management Support Systeme 6
kompetenz und Weisungsbefugnis besitzt [vgl. StSc93, S. 6] und die oben genannten
Management-Aufgaben wahrnimmt. Das Spektrum dieser im Weiteren auch als Mana-
gement-Aufgabenträger benannten Personengruppe umfasst dabei alle leitenden und
führenden Positionen auf allen Hierarchie-/Managementebenen einer Organisation,
„...angefangen vom Meister bis zum Vorstandsvorsitzenden“ [StSc93, S. 6].
Für die Gestaltung von MSS sind beide Sichtweisen, die funktionale und die institu-
tionale, relevant. Zum einen werden Management-Aufgaben zumeist von mehreren
Management-Aufgabenträgern gemeinsam wahrgenommen, ein MSS muss also bei
einer Aufgabe gleichzeitig unterschiedlichen Aufgabenträgern dienen bzw. deren
Zusammenarbeit koordinieren. Zum anderen ist jeder Management-Aufgabenträger in
der Regel in mehrere Management-Aufgaben involviert, deren wechselseitige Abhän-
gigkeiten vom MSS berücksichtigt werden müssen. Die strenge Orientierung an jeweils
nur einer der beiden Managementperspektiven bei der Gestaltung von MSS ist daher
wenig sinnvoll. Aus diesem Grund wird in der vorliegenden Arbeit mit dem Begriff
Management die institutionale und die funktionale Sichtweise stets zusammenhängend
betrachtet.
Zu ergänzen ist ferner die Prozessperspektive. Bei der Ausübung der Managementauf-
gaben durchläuft das Management prinzipiell mehrere Phasen der Entscheidungsfin-
dung bzw. Problemlösung. Der Prozess beginnt mit der Problemerkennung und Prob-
lemanalyse in der Anregungsphase („intelligence activity“ [Simo77]). Anschließend
folgt die Suchphase („design activity“ [Simo77]), in der alternative Lösungsmöglich-
keiten entwickelt und bewertet werden. Die Auswahl und Umsetzung einer dieser
Handlungsalternativen zur Problemlösung ist schließlich Gegenstand der Entschei-
dungsfindungsphase („choice activity“ [Simo77]). Zum Abschluss eines Entschei-
dungsprozesses und dem möglichen Anstoß eines neuen kommt es in der Kontrollphase
(„review activity“ [Simo77]), in der die getroffenen und durchgeführten Entscheidun-
gen und Maßnahmen gemäß ihres Zielerreichungsgrades beurteilt werden [vgl. Simo77,
S. 40ff; Adam96, S. 32]3.
In jeder einzelnen Phase des Entscheidungsprozesses bzw. über alle Phasen hinweg
werden unterschiedliche Informationen und Unterstützungsmethoden benötigt. Während
3 „Diese Phasen werden keineswegs streng sequentiell durchlaufen, vielmehr sind Rückverweise in
bereits durchlaufene Phasen die Regel bzw. müssen bereits erledigte Teilaufgaben erneut durchgeführt werden, um Ergebnisse der Phasen auf den Entscheidungsprozess rückzukoppeln...“ [KMM03, S. 128].
2 Management Support Systeme 7
beispielsweise in der Anregungsphase zumeist Fakten genügen, sind in der Suchphase
kausale Modellzusammenhänge erforderlich. Ein MSS muss den phasenspezifischen
Informations- und Methodenbedarf als auch die phasenübergreifende Koordination
berücksichtigen. Aufgrund der unterschiedlichen Anforderungen an Datenstrukturen
und Methoden je Phase erscheint die Entwicklung eines alle Funktionen umfassenden,
phasenübergreifenden MSS-Werkzeuges zur Unterstützung des Management nicht rea-
lisierbar [vgl. MeRi01a, S. 101]. Wegen der zu erwartenden höheren Komplexität des
Systems und der damit einhergehenden erschwerten Handhabung wäre dies auch nicht
erstrebenswert. Eine optimale Managementunterstützung ist demzufolge „nur“ durch
den kombinierten Einsatz der einzelnen, spezialisierten MSS-Werkzeuge und deren
MSS-Funktionen zu erreichen [vgl. MeRi01a, S. 101].
Die Herausforderung des Managements besteht also darin, die richtige Kombination der
Werkzeuge und Funktionen zur Lösung seiner Aufgaben zu finden. Da dem Manage-
ment (synonym: Anwender) zumeist mehrere MSS-Werkzeuge und MSS-Funktionen
zur Verfügung stehen und diese zur Problemlösung zumeist selektiv und iterativ ange-
wandt werden müssen [vgl. MeRi01a, S. 101], gestaltet es sich oft sehr schwer, die
richtige Auswahl zu treffen. Eine direkte Unterstützung dafür gibt es bisher nicht.
Neben dem klassischen Begriff MSS ist seit den 90er Jahren mit „Business Intelli-
gence“4 (BI) ein neuer Begriff für die rechnergestützte Managementunterstützung auf-
gekommen [vgl. KMU04, S. 2]. Dahinter steckt jedoch kein neues Konzept [vgl.
Gluc01, S. 5; ChGl04, S. 119] oder System, vielmehr handelt es sich „...um eine
begriffliche Klammer [...], die eine Vielzahl unterschiedlicher Ansätze zur Analyse
geschäftsrelevanter Daten zu bündeln versucht“ [Gluc01, S. 5].
Für den BI-Begriff existiert keine einheitliche Definition [vgl. Gluc01, S. 5], vielmehr
liegen unterschiedliche Meinungen/Auffassungen darüber in der Literatur vor. Mertens
ermittelte bei seiner Recherche zum Thema BI gleich sieben unterschiedliche BI-Ver-
ständnisse [vgl. Mert02, S. 66-67]. Bei der Mehrzahl der gefundenen Definitionen er-
folgte die Abgrenzung anhand der eingesetzten Systeme [vgl. KMU04, S. 3].
Neben der werkzeugorientierten Sichtweise ist in der Literatur auch ein prozessorien-
tiertes Begriffsverständnis von BI zu finden [vgl. Gluc01, S. 6-7]. Grothe und Gentsch
4 „Der Begriffsteil „Intelligence“ muss hier im Sinne von Einsicht, Verständnis oder Aufklärung
interpretiert werden [...]“ [CGPS04, S. 112].
2 Management Support Systeme 8
beispielsweise definieren BI als „...den analytischen Prozess, der – fragmentierte -
Unternehmens- und Wettbewerbsdaten in handlungsgerichtetes Wissen über die Fähig-
keiten, Positionen, Handlungen und Ziele der betrachteten internen oder externen
Handlungsfelder (Akteure und Prozesse) transformiert“ [GrGe00, S. 19].
Mit Hilfe eines zweidimensionalen Ordnungsrahmens strukturiert und positioniert Glu-
chowski die unterschiedlichen Sichtweisen des BI-Begriffs [vgl. Gluc01, S. 7] (siehe
Abbildung 2-1). Entlang der vertikalen Achse sind dabei die Phasen des analytischen
Datenverarbeitungsprozesses (von der Datenbereitstellung bis zur Datenauswertung)
abgetragen, entlang der horizontalen Achse der Schwerpunkt der BI-Systemkategorien
(Technik oder Anwendung) [vgl. Gluc01, S. 7]. Wie in Abbildung 2-1 zu sehen, erge-
ben sich aus der Einordnung der unterschiedlichen BI-Facetten insgesamt drei Defini-
tionsansätze von BI.
Analytische CRM
Data Mining
Text Mining
Ad hoc Kennzahlen-/BSC-Systeme
Planung/ Konsolidierung
OLAPMIS/EIS
StandardReporting
Data Warehouse
ETL Daten-bereit-stellung
Prozess-phase
Daten-auswert-ung
Anwendung Technik
Schwer-punkt
Enges BI-Verständnis
Weites BI-Verständnis
Analyseorientiertes BI-Verständnis
Abb. 2-1: Einordnung unterschiedlicher Facetten von BI [vgl. Gluc01, S. 7]
Das enge BI-Verständnis beinhaltet nur Systeme der unmittelbaren Informationsversor-
gung. Dazu gehören Systeme wie Online Analytical Processing (OLAP), Management
Information Systeme (MIS) und Executive Information Systeme (EIS)5.
5 Auf die hier und im Folgenden genannten Systeme wird in den Abschnitten 2.2 und 2.3 detaillierter
eingegangen.
2 Management Support Systeme 9
Das analyseorientierte BI-Verständnis erweitert den engen BI-Begriff um alle modell-
und methodenbasierten Anwendungen. Neben den drei zuvor genannten Systemen zäh-
len Text Mining, Data Mining, Ad-hoc Reporting, Balanced Scorecard (BSC) und
Customer Relationship Management Systeme (CRM) dazu, sowie Systeme zur Planung
und Konsolidierung. BI im weitesten Sinn umfasst schließlich alle Werkzeuge und
Systeme, die zu einer Unterstützung beitragen. Zusätzlich zu den zuvor aufgezählten
Systemen kommen hier Extraktions-, Transformations- und Lade-Werkzeuge (ETL) zur
Datenaufbereitung und Data Warehouse (DWH) zur Datenspeicherung dazu [vgl.
KMU04, S. 3-4].
Da der weite BI-Begriff inhaltlich die gleiche Bedeutung/Ausrichtung hat wie der klas-
sische MSS-Begriff, und zwar die Managementunterstützung mittels Informations- und
Kommunikationstechnologie, wird in dieser Arbeit das weite BI-Verständnis gleichge-
setzt mit Management Support Systeme. Im Zusammenhang mit Managementunterstüt-
zungssystemen wird im Weiteren nur noch der klassische Begriff MSS verwendet.
2.2 Klassifikation der MSS
Bei den existierenden Systemen zur Managementunterstützung wurden unterschiedliche
Schwerpunkte in der Gestaltung bezüglich der Perspektiven (institutionale, funktionale
und Prozess-Perspektive) gesetzt, sie lassen sich nach unterschiedlichen Kriterien in
verschiedene Klassen bzw. Gruppen klassifizieren [vgl. KrBa93, S. 64; KRZ92, S. 3ff;
Maur00, S. 13-27]. Im Folgenden werden einige der bedeutendsten MSS-Klassifika-
tionen aufgeführt.
Krallmann et al. differenzieren MSS hinsichtlich der Unterstützungsart (Data Support
und Decision Support) und der Anwenderebene (Management und Topmanagement)
[vgl. KMR01, S. 287], also funktional und institutional. Systeme die dem Data Support
zugerechnet werden, dienen der reinen Informationsversorgung, während Systeme des
Decision Support dem Management computergestützte Modelle zur Verfügung stellen,
die Unterstützung in semi- oder unstrukturierten Entscheidungssituationen bieten [vgl.
MeGr00, S. 12]. Bei der Dimension Anwenderebene heben Krallmann et al. die Füh-
rungskräfte (Executives) als eine spezielle Teilmenge des Management hervor. Daher
werden Data Support und Decision Support Systeme speziell für Führungskräfte unter-
schieden [vgl. KMR01, S. 287]. Hierfür haben sich die Begriffe Executive Information
2 Management Support Systeme 10
System (EIS) und Executive Support System (ESS) etabliert, wobei zur Anwender-
gruppe der Executives auch deren Assistenzkräfte gezählt werden.
Zusätzlich zu der Differenzierung der MSS-Systeme in Data Support und Decision
Support unterteilen Chamoni, Gabriel und Gluchowski in ihrer MSS-Klassifikation die
Dimension Unterstützungsart noch in die Klasse Communication Support [vgl. GGC97,
S. 244; GGD08, S. 85]. Dem Communication Support ordnen sie dabei alle Bürokom-
munikationssysteme zu, die Funktionen wie z. B. E-Mail bereitstellen [vgl. GGC97, S.
222; GGD08, S. 85; BeMu98, S. 16].
Kleinhans unterscheidet insgesamt sechs Dimensionen, die zur MSS-Klassifikation an-
gewendet werden können. Neben der bereits bekannten anwenderorientierten Dimen-
sion, zählen dazu die problemorientierte, die organisatorisch-funktionale, die organi-
sations-, die daten- und die computertechnische Dimension [vgl. Klei89, S. 108]. Wäh-
rend sich bei der organisatorisch-funktionalen Dimension die Unterstützung nach den
Unternehmensbereichen (Produktion, Vertrieb, Marketing usw.) richtet, erfolgt die
Klassifizierung bei der problemlösungsorientierten Dimension bezüglich der einzelnen
Phasen des Problemlösungs- bzw. Entscheidungsfindungsprozesses (vgl. Abschnitt 2.1).
Die computertechnische Dimension berücksichtigt hard- und softwaretechnische Kri-
terien, während die datentechnische Dimension eine Differenzierung nach der Daten-
haltung und -manipulation vorsieht. Bei der organisationstechnischen Dimension
bezieht sich die Unterstützung auf den innerbetrieblichen Aufbau des Management-
unterstützungssystems (Verteilung und Organisation der Datenbasen) [vgl. Klei89, S.
108-110; GrZa92, S. 22-24; KRZ92, S. 5-7].
Von Maur führt in seinen Darstellungen über MSS-Klassifikationen mit der Produktart6
ein an den Funktionen von MSS-Werkzeugen orientiertes Klassifizierungskriterium ein
[vgl. Maur00, S. 20-27]. „MSS-Werkzeuge bestehen aus einer Reihe von Funktions-
bündeln und weisen in der Regel eine Schwerpunktsetzung auf, wodurch die Einord-
nung in Kategorien möglich wird“ [Maur00, S. 20]. Aufgrund der zahlreichen Funk-
tionsüberschneidungen, die häufig zwischen den einzelnen MSS-Werkzeugen bestehen,
wird jedoch eine genaue Abgrenzung erschwert [vgl. Maur00, S. 21].
6 Das Kriterium Produktart kann als eine an real existierenden MSS-Werkzeugen orientierte Vermischung
der bisher betrachteten, theoretisch reinen Kriterien aufgefasst werden.
2 Management Support Systeme 11
Im Folgenden werden einige der wichtigsten, in Literatur und Praxis meist genannten
Produktarten hinsichtlich Intention und Aufgabenschwerpunkt vorgestellt. Dazu zählen
Berichtsgeneratoren, MIS, EIS, OLAP, Decision Support Systeme (DSS), Data Mining,
Text Mining, CRM, BSC, ETL und DWH.
Unter Berichtsgeneratoren werden Systeme zusammengefasst, die über die reine Daten-
abfragefunktionalität hinaus Formatierungsmöglichkeiten der Abfrageergebnisse bieten.
Aufgrund der zahlreichen Gestaltungsoptionen, die die Berichtsgeneratoren dem An-
wender zur Verfügung stellen, wie z. B. die Einbindung von Kopf-/Fußzeilen, von Sei-
tenzahlen, grafischen Objekten usw., werden sie üblicherweise für den Aufbau eines
Standardberichtswesens eingesetzt [vgl. Gluc06, S. 216-217].
Mit Management Information Systemen (MIS) werden Systeme bezeichnet, die Ent-
scheidungsträger auf verschiedenen Hierarchieebenen mit detaillierten und verdichteten
Informationen aus den operativen Systemen versorgen [vgl. BeMu98, S. 17; GaGl97b,
S. 422]. Im Wesentlichen basieren sie auf Standardberichten.
Zur Berücksichtigung der besonderen inhaltlichen und bedientechnischen Belange
haben sich hieraus in den 1990er Jahren die Executive Information Systeme (EIS) ent-
wickelt. Sie sind gekennzeichnet durch graphische Benutzeroberflächen und Kommuni-
kationselemente, mittels denen sowohl interne als auch externe Daten in hoch aggre-
gierter Form den Entscheidungsträgern zur Verfügung gestellt werden. Sie werden
sowohl zur frühzeitigen Erkennung von bedeutsamen Entwicklungstendenzen in den
frühen Phasen eingesetzt als auch in der Kontrollphase zur Überprüfung der Folgen
durchgeführter Maßnahmen [vgl. GGC97, S. 203].
Schwerpunkt von Online Analytical Processing (OLAP)-Systemen ist die multidimen-
sionale Analyse konsolidierter Daten, auf die die Manager interaktiv Zugriff erhalten
[vgl. GGC97, S. 282]. Die Multidimensionalität bezieht sich dabei auf die Anordnung
der Daten, die die Analyse von Kennzahlen (z. B. Absatz und Umsatz) entlang mehrerer
unterschiedlicher Dimensionen (z. B. Region, Kunde, Produkt, Zeit) und Dimensions-
hierarchien (z. B. Zeit: Jahr, Monat, Tag) erlauben [vgl. ChGl00, S. 334]. Zur Vorstel-
lung der multidimensionalen Datenstruktur wird die Metapher eines „Würfels“ (Daten-
Würfels) herangezogen, wobei die Anzahl der Dimensionen nicht auf drei beschränkt
ist. Als analytische Berichte (synonym: mehrdimensionale Berichte) werden alle
2 Management Support Systeme 12
gespeicherten oder potenziell erstellbaren Berichtssichten auf einem OLAP-Würfel
bezeichnet.
Bei den Decision Support Systemen (DSS) handelt es sich um „...interaktive EDV-
gestützte Systeme, die Manager (Entscheidungsträger) mit Modellen, Methoden und
problembezogenen Daten in ihrem Entscheidungsprozess bei der Lösung von Teilauf-
gaben in eher schlecht-strukturierten Entscheidungssituationen unterstützen“ [GGC97,
S. 168].
Data Mining-Systeme haben zum Ziel, große und umfangreiche Datenbestände zu
durchsuchen und darin vermutete auffällige bzw. bedeutsame Muster zu identifizieren,
von denen sie die signifikantesten Muster dem Anwender schließlich präsentieren [vgl.
BiHa01, S. 130-131]. Unter dem Begriff Text Mining werden alle Systeme zusammen-
gefasst, die sich speziell mit der Analyse von unstrukturierten Textdaten- bzw. Doku-
mentensammlungen beschäftigen, unter anderem mit dem Ziel die Dokumente geeignet
zu klassifizieren und zu gruppieren, sowie Informationen daraus zu extrahieren und
automatische Zusammenfassungen zu generieren [vgl. Meie01, S. 473-474].
Für den Aufbau und die Pflege von langfristigen Kundenbeziehungen werden analy-
tische Customer Relationship Management (CRM) Systeme eingesetzt [vgl. Gluc01, S.
12-14]. Sie basieren auf statistischen Methoden [vgl. Gluc01, S. 6], die auf die Kunden-
daten angewandt werden, um so genauere Erkenntnisse bzw. Informationen über das
Kundenverhalten zu gewinnen.
Balanced Scorecard (BSC)7 Systeme entsprechen Analysesystemen, die es ermöglichen,
die Unternehmensziele anhand verschiedener Messgrößen bereichsübergreifend, d. h.
aus verschiedenen Blickwinkeln (wie z. B. aus Finanz-, Kunden-, Geschäftsprozess-
und Lern- und Innovationsperspektive) zu betrachten, zu überwachen und zu steuern
[vgl. SBM99, S. 79]. Ziel einer BSC ist es dabei, ein ausgeglichenes, gleichberechtigtes
Verhältnis zwischen den Blickwinkeln zu schaffen [vgl. DiBu06, S. 36].
Neben den bisher vorgestellten anwendungszentrierten Produktarten zur Datenauswer-
tung existieren die technikgetriebenen Produktarten der Datenbereitstellung, zu denen
Extraktions-, Transformations-, und Lade-Werkzeuge (ETL), sowie Data Warehouses
zählen [vgl. Gluc01, S. 7].
7 Das Konzept bzw. die Methode der Balanced Scorecard wurde zu Beginn der 1990er Jahre von Kaplan
und Norton [KaNo92] entwickelt [vgl. DiBu06, S. 36].
2 Management Support Systeme 13
Ein Data Warehouse8 (i. e. S.) ist eine eigenständige Datenbank, die von den operativen
Datenverarbeitungssystemen (DV-Systemen) getrennt betrieben wird. Sie beinhaltet
(integriert) alle entscheidungsunterstützenden Informationen einer Unternehmung und
stellt somit die Datenbasis für alle Formen managementunterstützender Systeme dar
[vgl. MuBe00b, S. 6].
ETL-Werkzeuge werden zur Datenbewirtschaftung9 eingesetzt [vgl. MeRi01b, S. 141].
Ihre Aufgaben bestehen unter anderem darin, Daten aus verschiedenen Quellsystemen
zu extrahieren, die Daten falls erforderlich zu bereinigen und zu transformieren, um sie
dann in einem neuen, integrierten und konsistenten Zielsystem wie z. B. einem Data
Warehouse wieder zusammenzuführen.
Real verfügbare MSS-Werkzeuge stellen dem Management somit unterschiedliche
Funktionsbündel zur Verfügung. Diese muss das Management bei der Auswahl und
Einsatzentscheidung alle kennen, da die Funktionsbündel in der Regel zur Problem-
lösung kombiniert eingesetzt werden müssen. Nicht nur je Werkzeug, sondern auch
Werkzeug-übergreifend, besteht damit ein potenzieller Unterstützungsbedarf seitens des
Managements. Zur Identifikation des konkreten Assistenzbedarfs bzw. der konkreten
Unterstützungsbereiche ist es deswegen notwendig, die einzelnen Funktionen bzw. den
Aufbau der Funktionsbündel je MSS-Werkzeug genauer zu untersuchen. Für die Ermitt-
lung des MSS-Assistenzbedarfs wird von den vorgestellten MSS-Klassifikationen, auf-
grund der Orientierung an den MSS-Werkzeugen, die Klassifikation nach dem Kri-
terium Produktart herangezogen und im folgenden Abschnitt für eine Auswahl von
MSS-Werkzeugklassen das bereitgestellte Funktionsspektrum beschrieben.
2.3 Funktionsspektrum von MSS-Werkzeugen
Das Spektrum der Funktionen von MIS-Werkzeugen beschränkt sich primär auf das
einfache Standardberichtswesen, d. h. die periodische Versorgung des Management mit
Berichten basierend auf historischen, aggregierten Daten aus den Administrations- und
Dispositionssystemen. Erweiterungen gehen schließlich in Richtung flexibles Reporting
und der Möglichkeit der Ad-hoc-Auswertung [vgl. ChGl06b, S. 6-7].
8 „A data warehouse is a subject-oriented, integrated, time-variant, nonvolatile collection of data in
support of management’s decision-making process…“ [InHa94, S. 2]. 9 „Unter Datenbewirtschaftung wird die regelmäßige Versorgung aller Ebenen eines Data Warehouse mit
Daten (und Metadaten) verstanden“ [MeRi01b, S. 141].
2 Management Support Systeme 14
Zum typischen Funktionsspektrum von EIS gehören das Exception Reporting (Aus-
nahme-Berichtswesen) und die Drill-Down-Technik. Das Exception Reporting dient
dazu, durch markierende oder signalisierende Kennzeichnung das Management sehr
früh auf kritische Abweichungen in den Daten hinzuweisen. Der Manager kann dabei
individuell und der momentanen Datenkonstellation entsprechend das Margenspektrum,
d. h. den oberen und den unteren Grenzwert für Ausnahmeereignisse, festlegen. Mit
dem Drill-Down wird die Möglichkeit geboten, auf die Daten eines niedrigeren Granu-
laritätsniveaus zu wechseln, um so Einblick in detailliertere Informationen zu erhalten.
Auf diese Weise kann das Management die potenziellen Ursachen der Abweichungen in
den Daten untersuchen und aufdecken [vgl. ChGl06b, S. 8].
Neben der Definition von Ausnahmen und dem Drill-Down bzw. Drill-Up stehen bei
OLAP-Systemen zur Analyse der Datenwürfel weitere Techniken wie Slicing, Dicing
und Drill-Through zur Verfügung. Während mit Slicing die Analyse auf einzelne Aus-
schnitte des Würfels eingegrenzt werden kann, kann mittels Dicing der Betrachtungs-
winkel bezüglich der Daten verändert werden, indem durch Kippen oder Drehen des
Würfels die Dimensionen neu angeordnet werden [vgl. ChGl00, S. 370-371]. Bei der
Ausführung eines Drill-Through erfolgt ein Durchgriff auf die Detaildaten, z. B. aus den
operativen Systemen, die nicht in dem Datenwürfel enthalten sind [vgl. Mart98, S. 429].
Die Gesamtheit dieser OLAP-Funktionen bietet dem Manager (bei geeigneter Kombi-
nation) die Möglichkeit, schnell und flexibel auf die aktuell entscheidungs-relevanten
Daten zuzugreifen und aus der Betrachtung verschiedener Perspektiven neue Erkennt-
nisse zu gewinnen.
Bei DSS steht die aktive Unterstützung der Manager im Vordergrund. Aus diesem
Grund stellen DSS Modelle und Methoden für die Problemstrukturierung, Alternativen-
generierung und -bewertung zur Verfügung. Mit Elementen der Simulation ist es dem
Manager möglich, sowohl Auswirkungen von vorgegebenen Maßnahmen abzuschätzen
(What-if-Rechnungen) als auch notwendige Maßnahmen zur Erreichung vorgegebener
Ziele im Rahmen vorgegebener Handlungsspielräume generieren zu lassen (How-to-
achieve- bzw. Ziel-Rechnungen) [vgl. MeGr00, S. 6].
Data Mining Systeme umfassen eine große Anzahl unterschiedlicher Methoden bzw.
Verfahren, die zum einen Teil aus der mathematischen Statistik (wie z. B. Korrelations-,
Regressions- und Cluster-Analyse), zum anderen Teil aus der Künstlichen Intelligenz
(KI) (wie z. B. Maschinelles Lernen, Neuronale Netze oder Genetische Algorithmen)
2 Management Support Systeme 15
stammen [vgl. Mert02, S. 67]. Die einzelnen Methoden können jeweils für unterschied-
liche Aufgabenstellungen eingesetzt werden. Beispielsweise kann das Entscheidungs-
baumverfahren für die Erstellung von Klassifikations- und Regressionsmodellen ange-
wendet werden. Neuronale Netze sind darüber hinaus noch für die Segmentierung bzw.
Clusterbildung geeignet. Ein typisches Data Mining Verfahren für die Entdeckung von
Abhängigkeiten ist die Assoziationsanalyse [vgl. BeCh06, S. 267].
Balanced Scorecard-Werkzeuge unterstützen den Anwender beim Aufbau und der
Implementierung einer BSC anhand unterschiedlicher Funktionen. Einige Funktionen
ermöglichen die Modellierung und Abbildung der verschiedenen BSC-Perspektiven
[vgl. JLW04, S. 8] und ihren zugeordneten Kennzahlen bzw. Indikatoren. Mit Hilfe so
genannter Ursache-Wirkungsketten bieten BSC-Werkzeuge die Möglichkeit, Zusam-
menhänge und Abhängigkeiten zwischen den unternehmerischen Einzelzielen zu
modellieren und zu visualisieren [vgl. JLW04, S. 17]. Durch diese Form der Dokumen-
tation sind die von der Organisation bzw. vom Manager getroffenen Entscheidungen
und Maßnahmen nachvollziehbar und überprüfbar [vgl. Sche02, S. 13].
Jedes der hier beschriebenen MSS-Werkzeug-spezifischen Funktionsbündel ist durch
eine große Vielfalt und Komplexität gekennzeichnet. Die Bestimmung des konkreten
MSS-Unterstützungsbedarfs soll im Folgenden anhand der Beschreibung eines Beispiel-
Szenarios erfolgen. Als Untersuchungsobjekt für die Analyse wird die Universität
Osnabrück betrachtet. Dieses Beispiel ist für die Untersuchung repräsentativ, da die
Universität Osnabrück sowohl institutional als auch funktional gesehen ein breites
Managementspektrum umfasst und mit einer modernen informations- und kommuni-
kationstechnologischen Infrastruktur zur Managementunterstützung ausgestattet ist.
3 Beispiel-Szenario für den MSS-Einsatz
3.1 Managementspektrum der Universität Osnabrück
Zur Bestimmung eines geeigneten MSS-Beispiel-Szenarios ist es erforderlich, den
MSS-Unterstützungsbedarf organisations-, aufgaben- und prozess-übergreifend zu iden-
tifizieren. Dazu wird zunächst das funktionale Management- bzw. Leistungsspektrum,
sowie der organisatorische Aufbau der Universität Osnabrück näher betrachtet. Auf der
Grundlage dieser Informationen werden dann je Organisationsbereich Management
relevante Aufgaben, die eine MSS-Werkzeug Unterstützung erfordern oder die für eine
MSS-Werkzeug Unterstützung geeignet sind, zugeordnet. Während im Abschnitt 3.2
die Beschreibung der an der Universität Osnabrück vorliegenden IT-Infrastruktur mit
den dort eingesetzten MSS-Werkzeugen erfolgt, wird schließlich im Abschnitt 3.3 aus
der Menge der an der Universität Osnabrück anfallenden Managementaufgaben eine
Aufgabe, die eine MSS-Unterstützung erfordert, ausgewählt und detailliert beschrieben.
Für die Auswahl einer MSS-relevanten Aufgabe wird auf die Vorarbeiten von Postert
[Post00] zurückgegriffen. Dieser hat auf Basis eines Dokumentenstudiums der einschlä-
gigen Gesetzestexte (wie z. B. Hochschulrahmengesetz (HRG) und Niedersächsische
Hochschulgesetz (NHG)) und Verordnungen (wie z. B. Grundordnung, Organisations-
und Geschäftsverteilungsplan usw.) MSS-relevante Aufgaben an der Universität Osna-
brück identifiziert und den Management-Ebenen nach Mintzberg [Mint79] zugeordnet
[vgl. Post00, S. 33-38 und S. 91]. Laut Mintzbergs Organisationstypologie setzt sich
eine Organisation im Allgemeinen aus den fünf Teilbereichen operativer Kern („opera-
ting core“), mittleres Linienmanagement („middle line“), strategische Spitze („strategic
apex“), Technostruktur („technostructure“) und unterstützende Einheiten („support
staff“) zusammen, die je nach Strukturtyp unterschiedlich stark ausgeprägt sein können
[vgl. Mint79, S. 19-20; Mint89, S. 109-110]. Öffentliche Einrichtungen wie Universi-
täten entsprechen dem Strukturtyp der „professionellen Bürokratie“ [vgl. Mint79,
S.348ff; Hart84, S. 33; Seid92, S. 24]. Kennzeichnend für diesen Typ ist ein dominanter
operativer Kern, eine hierarchisch relativ flache mittlere Ebene, eine minimale Techno-
struktur, große unterstützende Einheiten sowie eine gering ausgeprägte strategische
Spitze [vgl. Mint79, S. 355; Mint89, S. 123] (siehe Abbildung 3-1).
3 Beispiel-Szenario für den MSS-Einsatz 17
Abb. 3-1: Professionelle Bürokratie nach Mintzberg [vgl. Mint79, S. 355]
Bezogen auf die Universität Osnabrück entsprechen dabei dem operativen Kern die
Fachgebiets- und Institutsleiter, die wissenschaftlichen und nicht-wissenschaftlichen
Mitarbeiter, d. h. alle Personen, die im Bereich der Forschung und Lehre tätig sind und
infolgedessen für die primäre Leistungserstellung der Universität - der Heranbildung
des wissenschaftlichen Nachwuchs - die Verantwortung tragen [vgl. Hart84, S. 33;
Seid92, S. 24; Post00, S. 37 und S. 90].
Das mittlere Linienmanagement verbindet über eine Autoritätshierarchie den operativen
Kern mit der strategischen Spitze [vgl. Mint79, S. 19; Mint89, S. 109-110]. Diesem
Bereich der Universität gehören die Dekane und die Mitglieder der Selbstverwaltungs-
gremien der Fachbereiche (Dekanat und Fachbereichsrat) an [vgl. Hart84, S. 34-35;
Seid92, S. 25; Post00, S. 37 und S. 90]. Gemäß dem Niedersächsischen Hochschul-
gesetz (NHG) sind sie zuständig für alle Angelegenheiten der Forschung und Lehre des
Fachbereichs wie z. B. die Bestimmung des Lehrangebots und der Lehraufgaben. Zu-
dem obliegt ihnen die Beschlussfassung über die verschiedenen Ordnungen des Fachbe-
reichs wie z. B. die Studien-, Prüfungs-, Promotions- und Habilitationsordnungen [vgl.
NHG07, §43 und §44].
Repräsentanten der strategischen Spitze der Universität sind die Hochschulleitung1 und
die zentralen Selbstverwaltungsgremien (Senat und Hochschulrat) [vgl. Hart84, S. 33-
34; Seid92, S. 25; Post00, S. 37 und S. 90]. Ihre Aufgabe besteht darin, die Universität
zu leiten sowie die Hochschulstrukturen und -ordnungen zu gestalten und zu bewahren
[vgl. NHG07, §37ff, §41 und §52].
Die Technostruktur der Universität wird unter anderem gebildet von Stäben für Pla-
nung, Forschung und Studienangelegenheiten. Zwei konkrete Beispiele dafür sind die
1 Die Hochschulleitung der Universität Osnabrück wird durch das Präsidium repräsentiert, bestehend aus
einem Präsidenten und drei Vizepräsidenten (Vizepräsident für Studium und Lehre, Vizepräsidentin für Forschung und Nachwuchsförderung und Vizepräsident für Personal und Finanzen) [vgl. UOS08].
3 Beispiel-Szenario für den MSS-Einsatz 18
Stabsstelle Zentrales Berichtswesen und die Stabsstelle für Weiterbildung und Wis-
senstransfer [vgl. UOS08]. Durch die Anwendung analytischer Methoden und Techni-
ken sollen sie die strukturelle und prozessuale Gestaltung der Universität unterstützen
und verbessern [vgl. Hart84, S. 35; Seid92, S. 25]. Aus diesem Grund sind sie der
Hochschulleitung direkt unterstellt.
Den unterstützenden Einheiten sind die Mitarbeiter und Angestellten der zentralen
Verwaltung (bestehend aus den Dezernaten für Personalangelegenheiten, Finanzen,
Studentische Angelegenheiten und Justitiariat, Gebäudemanagement und Hochschul-
entwicklung) und der zentralen Einrichtungen (bestehend aus u. a. Rechenzentrum, Stu-
dentenwerk, Universitätsbibliothek und dem Zentrum für Informationsmanagement und
virtueller Lehre (virtUOS)) zuzuordnen [vgl. Post00, S. 90; UOS08]. Deren Hauptauf-
gabe ist es, einerseits andere Organisationsbereiche bei ihren regelmäßig anfallenden
administrativen Tätigkeiten zu unterstützen, andererseits Dienstleistungen zu erbringen,
die von der primären Leistungserstellung unabhängig sind [vgl. Seid92, S. 25; Post00,
S. 37-38]. Beispielsweise gehören dazu die Essensausgabe der Mensa oder das zur Ver-
fügung stellen von Fahrzeugen für Geschäftsreisen bzw. zum Transfer.
Tabelle 3-1 zeigt eine für die Zwecke dieser Arbeit vereinfachte Form der Zuordnung
Management relevanter Aufgaben zu den von Mintzberg [Mint79] aufgeführten Organi-
sationsbereichen. Sie bestätigt die in 2.1 aufgestellte These, dass einerseits ein Organi-
sationsbereich wie z. B. der operative Kern mehrere Management-Aufgaben wie z. B.
die Ressourceneinsatzplanung (Personal und Mittel) und Lehrveranstaltungsplanung zu
lösen hat, andererseits eine Management-Aufgabe von mehreren Organisationsbe-
reichen gemeinsam wahrgenommen wird. Ein Beispiel dafür ist die Einführung neuer
Studiengänge im Rahmen der Hochschulentwicklungs- und Strukturplanung. Das
Dekanat und der Fachbereichsrat entwerfen den Aufbau und die Rahmenbedingungen
des neuen Studiengangs (Welche Fächerkombination der Studiengang beinhaltet, wie
lang die Regelstudienzeit ist, welche Fachgebiete am Lehrprogramm beteiligt sind
usw.). Die Hochschulleitung prüft das entwickelte Studiengangskonzept, z. B. bezüglich
Finanzierbarkeit oder ob es eine zukunftsträchtige Ausbildungsrichtung im langfristigen
Zielportfolio der Universität darstellt und stimmt über dessen Einführung und/oder
Änderung ab.
3 Beispiel-Szenario für den MSS-Einsatz 19
ausgewählte Managementaufgaben operativer Kern
mittleres Linien-management
unterstütz-ende Einheiten
Techno-struktur
strategische Spitze
strukturelle Rahmenbedingungen
Hochschulentwicklungs- und Strukturplanung x x
Kapazitätsplanung x x
Studiengangsplanung x x x
Berufungsverhandlungen x x x
Bleibeverhandlungen x x x x
Ausstattungs- und Ressourceneinsatzplanung
Stellen x x x
Personal x x x x x
Mittel x x x x x
Räume x x x
Studium und Lehre
Lehrveranstaltungsplanung x x
Prüfungsabwicklung x x
Forschung
Bildung von Forschungsschwerpunkten x x
Planung von Forschungsprojekten x x
Tab. 3-1: Zuordnung der Managementaufgaben zu den Organisationsbereichen
Zur Bewältigung der umfangreichen Managementaufgaben benötigen die Entschei-
dungsträger der Universität Osnabrück viele unterschiedliche Informationen wie z. B.
Studierenden- und Absolventendaten, Stellen- und Haushaltsdaten usw., die zumeist nur
verteilt in verschiedenen operativen Systemen vorliegen. Damit die Entscheidungsträger
diese Informationen für die Entscheidungsfindung nutzen können, müssen sie die
Informationen aus den einzelnen Systemen extrahieren und manuell zusammenfügen
und aufbereiten.
Mit dem Ziel, den Informationsbedarf und die Informationsbeschaffung auf allen Mana-
gementebenen der Universität Osnabrück zu verbessern und zu unterstützen, wurde
Mitte des Jahres 1998 mit der Entwicklung und Implementierung einer informations-
technologischen Infrastruktur begonnen. Die Beschreibung der Architektur und ihrer
einzelnen Komponenten ist Gegenstand des folgenden Abschnitts.
3.2 IT-Infrastruktur der Universität Osnabrück
Zur Abwicklung der einzelnen Geschäftsprozesse innerhalb der Universität Osnabrück
wie z. B. der Immatrikulation und der Rückmeldung von Studierenden, der Prüfungs-
anmeldung, der Raumbelegungsplanung, der Stellen- und Personalverwaltung sowie der
Bestellung von Lehrbüchern und der Buchung von Ausgaben werden spezifische ope-
rative Anwendungssysteme eingesetzt [vgl. Rieg99, S. 284]. Für die Finanzbuchhaltung
3 Beispiel-Szenario für den MSS-Einsatz 20
einschließlich Beschaffung, Kostenrechnung, Anlagenbuchhaltung, Personal- und Stel-
lenverwaltung hat die Universität Osnabrück die Enterprise Resource Planning (ERP)
Standardsoftware SAP R3 mit ihren Modulen Finanzbuchhaltung (Modul FI), Control-
ling (Modul CO), Haushaltsmanagement (Modul PSM) und Personalwirtschaft (Modul
HR) im Einsatz. Die Studierendenverwaltung erfolgt mit dem Studentenorganisations-
system (SOS), die Prüfungsdatenverwaltung mit dem Prüfungsorganisationssystem
(POS) und die Bewerbung und Einschreibung der Studieninteressenten mit dem Online-
Zulassungssystem (ZUL) der Firma HIS (Hochschulinformationssystem) GmbH. Für
die Verwaltung und Bewirtschaftung der universitären Gebäude und Anlagen wird des
Weiteren die Standardsoftware conject Facility Management (FM) der Firma conject
GmbH genutzt. Bei der Budget- und Bestellverwaltung der Universitätsbibliothek (UB)
kommt das Bibliothekssystem PICA (Project of Integrated Catalogue Automation) der
Organisation OCLC PICA (Online Computer Library Center PICA) zur Anwendung.
Zur Unterstützung der Planung und Organisation von Lehrveranstaltungen steht den
Universitätsmitgliedern die Open-Source-Software Stud.IP2 zur Verfügung3.
Um eine umfassende und übergreifende Informationsbasis über alle operativen Systeme
zu schaffen, zu der alle Entscheidungsträger aller Ebenen der Universität Osnabrück
Zugang haben und die sie bei ihren vielfältigen Managementaufgaben nutzen können,
wurde im Jahr 1998 in dem Projekt „MIS“ [Rieg00] mit dem Aufbau eines dem State of
the Art entsprechenden Data Warehouse-gestützten Management Information Systems
begonnen. Mit der Entwicklung einer auf modernem technologischem Stand basieren-
den Informations-Infrastruktur, die allen Universitätsmitgliedern die für sie relevanten
Informationen einfach und in konsistenter Form bereitstellt [vgl. Rieg99, S. 284], kann
eine verbesserte Entscheidungsunterstützung und damit eine höhere Entscheidungs-
qualität erreicht werden.
Der Aufbau der entwickelten Informations-Infrastruktur der Universität Osnabrück (im
Folgenden kurz als MIS bezeichnet) ist in Abbildung 3-2 dargestellt.
2 Stud.IP ist die Kurzbezeichnung für „Studienbegleitender Internetsupport von Präsenzlehre“. Es handelt
sich dabei um ein Lern-, Informations- und Projekt-Management-System, das speziell für Bildungsein-richtungen und Hochschulen entwickelt wurde. Neben Lehrveranstaltungs- und Personalverzeichnis und einem Anmeldeverfahren für teilnehmerbeschränkte Veranstaltungen umfasst es auch eine Raum- und Ressourcenverwaltung [vgl. Stud08].
3 Es sei angemerkt, dass diese Auflistung der an der Universität Osnabrück im Einsatz befindlichen operativen Anwendungssysteme keinesfalls abgeschlossen ist.
3 Beispiel-Szenario für den MSS-Einsatz 21
Die Kernkomponente dieser Architektur stellt das Data Warehouse (DWH) dar, d. h. ein
zentraler Datenpool, der auf einer Oracle Datenbank implementiert wurde, in dem alle
für die Planungs- und Steuerungsaufgaben relevanten Daten einheitlich und konsistent
integriert sind. Von den von der Universität Osnabrück eingesetzten operativen Syste-
men werden bisher die Daten aus dem Buchungs- und Kostenrechnungssystem der
Standardsoftware SAP R3, aus dem Studenten- und Prüfungsverwaltungssystem (HIS-
SOS und -POS) der HIS GmbH, aus dem Bibliotheksystem PICA, aus dem Stud.IP-
System sowie aus Eigenentwicklungen der Universität Osnabrück zur rechner-gestütz-
ten Fachbereichs- und Lehrveranstaltungs-Evaluation ins Data Warehouse geladen und
aufbereitet. Das Data Warehouse integriert dabei sowohl quantitative Daten z. B. Sach-
mittel, Studierende und Absolventen als auch qualitative Informationen wie z. B.
Beschreibungen von Kennzahlen und Evaluationsergebnisse von Forschung und Lehre
[vgl. Rieg01, S. 147].
Abb. 3-2: Management Information System der Universität Osnabrück
Die Extraktion, Bereinigung und Aufbereitung der Daten in das DWH erfolgt weitest-
gehend automatisiert mittels des ETL-Werkzeuges PowerCenter der Firma Informatica.
Neben Datenkonvertierungen wie z. B. der Umwandlung der Semester-ID (z. B. 20072)
in die entsprechende Sommersemester- oder Wintersemester-Bezeichnung (z. B. WS
07/08), werden zusätzlich umfangreiche Transformationen zur Ableitung neuer Kenn-
zahlen und Auswertungsmerkmale durchgeführt. Es handelt sich dabei um Merkmale
3 Beispiel-Szenario für den MSS-Einsatz 22
und Kennzahlen, die in den operativen Systemen nicht bzw. nicht in der für Analysen
benötigten Form vorliegen. Dazu zählen bei den Immatrikulationsdaten beispielsweise
die unterschiedlichen Zählweisen der Studierenden (pro Kopf, pro Studiengang und pro
Fach) und die Zuordnung der Semester zu einem Studienjahr [vgl. Rieg01, S. 148-149].
Aufbauend auf dem Data Warehouse wurde ein web-basiertes Berichts- und Analyse-
system konzipiert und implementiert, das die unterschiedlichen Informationsanfor-
derungen der Management-Aufgaben und -Aufgabenträger hinsichtlich Aktualität und
Aggregationsniveau der Daten berücksichtigt.
Für die Immatrikulations- und Absolventendaten, die stichtagsbezogen ins Data Ware-
house geladen werden, wurden dem OLAP-Prinzip entsprechende, mehrdimensionale,
individuell gestaltbare Analyseberichte(-würfel) erstellt. Mit diesen ist es möglich, his-
torisierte Auswertungen über die Entwicklung der Studierendenzahl oder Absolventen-
zahl anhand unterschiedlicher Merkmale wie z. B. Semester, Studienfach, Abschluss,
Fachbereich, Lehreinheit, Staatsangehörigkeit, Geschlecht usw. durchzuführen. „Alle
Berichtsdimensionen bieten multiple Aggregationen über alternative Hierarchien“
[Rieg00, S. 4].
Zur Analyse der Immatrikulations- und Absolventendaten stehen dem Anwender die
typischen mehrdimensionalen Funktionalitäten (vgl. Abschnitt 2.3) des OLAP-Werk-
zeuges Cognos PowerPlay (Web und Windows) von der Firma Cognos (seit 2008 zu
IBM gehörend) zur Verfügung. Vordefinierte Berichtssichten können damit aufgerufen
und flexibel und interaktiv gemäß den eigenen Anforderungen bzw. der aktuellen
Fragestellung angepasst und erweitert werden, beispielsweise durch das Setzen weiterer
Filterbedingungen (Slice), durch das Detaillieren einer Dimension (Drill down)
und/oder durch das Tauschen der Dimensionen in den Berichtsachsen (Dice) [vgl.
Rieg01, S. 149]. Für bestimmte Auswertungszwecke sind Berichtssichten auf den
OLAP-Würfeln erstellt und gespeichert worden, die von den Anwendern bei Bedarf
abgerufen werden können. Zur Abschätzung des erwartbaren Studienbeitragsvolumens
je Fachbereich dient beispielsweise die in Abbildung 3-3 dargestellte Sicht auf den Stu-
dierendenwürfel. Dabei werden die zahlungspflichtigen (nicht Beurlaubte) Studie-
rendenköpfe bei dem jeweils zum Hauptstudienfach gehörenden Fachbereich gezählt.
3 Beispiel-Szenario für den MSS-Einsatz 23
Abb. 3-3: Screenshot eines analytischen Berichts der Studierendendaten
Im Gegensatz zu den Studierendendaten, bei denen sowohl die Datenhistorie als auch
das breite Merkmalsspektrum bei der Analyse eine wichtige Rolle spielen, sind bei den
Haushaltsdaten aus dem SAP R3-System, deren Auswertungsstrukturen relativ klar und
stabil beschreibbar sind, auch aktuelle bzw. wöchentlich aktualisierte Eck-Daten wie
z. B. die Ausgaben je Finanzstelle, Fonds und Handelspartner und die verfügbaren Mit-
tel (Budgets) je Finanzstelle, Fonds und Herkunft (z. B. Drittmittel) von Interesse.
Daher sind für diese Daten neben analytischen Berichten auch starre und parameter-
gesteuerte Standardberichte entwickelt worden, über die die Mitglieder der Universität
(wie Professoren, Sekretariatsangestellte, Verwaltungsangestellte usw.) ihre aktuellen
Budgetdaten, Plan-Ist-Daten, Finanzdaten usw. abrufen können. Außer der Änderung
der abgefragten Parameter (wie z. B. des Fonds oder des Monats) können seitens des
Anwenders keine weiteren Änderungen an der Berichtssicht und dessen Einstellungen
vorgenommen werden.
Diese Haushaltsberichte wurden mittels des MSS-Werkzeugs Cognos Report Studio
von der Firma Cognos entwickelt und implementiert. Hierbei handelt es sich um einen
web-basierten Berichtsgenerator (vgl. Abschnitt 2.2), der die Ergebnisse verschiedener
einzelner Datenabfragen kombinieren und in einem sehr flexibel gestaltbaren Berichts-
layout darstellen kann. Publiziert bzw. bereitgestellt werden die Berichte über das Web-
Portal des Cognos ReportNet Servers.
3 Beispiel-Szenario für den MSS-Einsatz 24
Genauso wie bei den Haushaltsdaten werden ebenfalls Standardberichte über Prüfungs-
detaildaten, wie z. B. Anmeldungen zu Prüfungen, Prüfungsergebnisse je Student und
Semester usw., die aus dem Prüfungsverwaltungssystem HIS-POS stammen, über das
Management Information System zur Verfügung gestellt. Neben der operativen Grund-
versorgung liegt der Schwerpunkt des MIS hier auf analytischen Auswertungen zur
Lösung dispositiver und/oder strategischer Planungsprobleme. Abbildung 3-4 zeigt ein
Beispiel zur Bestimmung geeigneter Prüfungstermine auf Basis der aggregierten Ter-
minvakanzen aller angemeldeten Teilnehmer einer Prüfung unter Berücksichtigung ver-
fügbarer ausstattungs- und größen-adäquater Raumressourcen.
Abb. 3-4: Screenshot eines Standardberichts über die Prüfungstermin-Belegung
Eine weitere wichtige Komponente des MIS der Universität Osnabrück ist die eigen-
entwickelte web-basierte Kommunikations-Infrastruktur IWUI4 (Interactive Web-based
University Information System) [vgl. Rieg00, S. 4]. Hierbei handelt es sich um eine
zusätzliche (Meta-) Datenbasis mit typisierten Informationsobjekten (d. h. Texte,
Dokumente, Grafiken, Links, Berichtssichten, Datenwürfel usw.), die über eine web-
basierte Interaktions-/Navigationsschnittstelle abgefragt und durchsucht, gepflegt und
erweitert werden kann [vgl. Rieg01, S. 151]. Neben quantitativen Informationen wie
z. B. Berichtssichten über die Studierenden-, Prüfungs- und Haushaltsdaten werden
auch qualitative Informationen wie z. B. Evaluationsergebnisse, Definitionen von Kenn-
zahlen, Beschreibungen von Auswertungsmerkmalen und Berichtskommentare über das
4 Das IWUI-System wird über folgende Web-Seite aufgerufen: http://sansibar.oec.uos.de/pls/stift/iwui
(Stand 08.10.2008).
3 Beispiel-Szenario für den MSS-Einsatz 25
IWUI-System zielgruppen-spezifisch bereitgestellt. Die Informationsobjekte können
über die Definition von Verknüpfungen bzw. Referenzen beliebig zueinander in Bezie-
hung gesetzt werden [vgl. Rieg01, S. 151], wodurch Zusammenhänge bzw. Zusammen-
gehörigkeiten zwischen den Informationsobjekten abbildbar sind. Problem-spezifisch
können die Universitätsmitglieder Informationen von dieser (Meta-)Datenbasis abrufen,
des Weiteren aber auch die Datenbasis um weitere Informationen ergänzen und somit
auch anderen Nutzern zur Verfügung stellen, die in konkreten Entscheidungssituationen
danach suchen können. Es bietet damit die Grundstrukturen für den Ausbau zu einem
Wissensmanagement-System [vgl. Ment03, S. 57 und S. 125-126].
3.3 Ein typisches MSS-gestütztes Beispiel-Szenario der Universität Osnabrück
Gemäß der zu Beginn erläuterten Vorgehensweise bei der Untersuchung des MSS-
Unterstützungsbedarfs ist nun im nächsten Schritt die Auswahl und Beschreibung eines
konkreten MSS-Beispiel-Szenarios durchzuführen. Anhand des ausgewählten Beispiels
werden dann detailliert die Unterstützungsbereiche identifiziert. Im Folgenden werden
die Management-Aufgaben des mittleren Linienmanagement der Universität Osna-
brück, speziell die Aufgaben eines Dekans gemäß Hochschulgesetz, näher betrachtet.
Wie in Abschnitt 3.1 bereits erwähnt, ist der Dekan eines Fachbereichs laut dem Nieder-
sächsischen Hochschulgesetz zuständig für alle Angelegenheiten seines Fachbereichs
[vgl. NHG07, §43]. Nach dem Gesetz gehören dazu z. B. die Förderung und Koordina-
tion von Forschungsvorhaben, die Regelung und Überwachung der ordnungsgemäßen
Durchführung der Lehr- und Prüfungsverpflichtungen sowie die Abwicklung und
Überwachung der Geschäfte der laufenden Verwaltung seines Fachbereichs. Als spe-
zielle Tätigkeiten/Aufgaben, die eher unregelmäßig und ad-hoc anfallen, obliegt es dem
Dekan, Bleibe- und Berufungsverhandlungen zu führen. Bei einem Berufungsverfahren
hat er zusammen mit der Berufungskommission die schwierige Aufgabe zu lösen, einen
geeignet qualifizierten Bewerber unter Berücksichtigung der finanziellen und personel-
len Möglichkeiten des Fachbereichs hinsichtlich der Ausstattung der/des neu zu beset-
zenden Stelle/Lehrstuhls mit Mitteln, Personal und Räumen zu finden. Ähnlich intensiv
bzw. aufwendig gestaltet sich die Aufgabenlösung des Dekans bei Bleibeverhand-
lungen. Im Unterschied zu Berufungsverhandlungen ist in diesem Fall jedoch der Ver-
handlungspartner bekannt, da er schon seit einer bestimmten Zeit am Fachbereich tätig
3 Beispiel-Szenario für den MSS-Einsatz 26
ist. Dem Dekan stehen daher in der Regel mehr und detailliertere Informationen über
die Person zur Verfügung.
Zur Vorbereitung auf die Verhandlungsgespräche kann der Dekan ganz unterschiedliche
Informationen über die Person benötigen, wie z. B. welche Mittel und Ressourcen
besitzt er (der Lehrstuhlinhaber) bereits, wie sehen seine Lehrtätigkeiten aus (Anzahl
Vorlesungen, Seminare und Praktika/Projekte), wie aktuell ist sein Forschungsgebiet,
wie viele Forschungsprojekte wurden von ihm durchgeführt, wie viele Drittmittel
wurden von ihm eingeworben, wie viele Studenten studieren sein Fach und wie hoch ist
seine Prüfungsbelastung.
Die Mehrzahl der obigen Informationen ist im Informationspool des MIS enthalten und
darüber abrufbar. Sie liegen dort jedoch in unterschiedlicher Form vor, z. B. als Stan-
dardbericht, als analytischer Bericht, als Textinformation oder als Dokument (Word,
Excel, PDF). Zur Beurteilung der Prüfungsbelastung der Person könnte der Dekan bei-
spielsweise die Standardberichte über die Prüfungsanmeldungen je Lehrveranstaltung
und Semester heranziehen. Der Dekan könnte dazu aber auch auf die OLAP-Berichte
zur HIS-POS-Prüfungsstatistik, in der z. B. die Anzahl an bestandenen und nicht-
bestanden Prüfungen je Lehrveranstaltung einsehbar sind, zurückgreifen. Über den
Abruf der SAP-Haushaltsdaten des Fachbereichs kann der Dekan des Weiteren Einblick
in die historische und aktuelle Personal- und Ressourcenausstattung des Lehrstuhls der
Person bzw. des Fachbereichs erhalten. Mit diesen Informationen und den Dokumenten
über die zukünftigen Festlegungen des Fachbereichs könnte der Dekan schließlich
abwägen, in welcher Form eine Erhöhung der Ausstattung überhaupt möglich und
gerechtfertigt wäre. Ebenfalls für die Verhandlung nützliche Informationsquellen wären
Ranking-Berichte und Evaluationsergebnisse.
Zur Bestimmung des MSS-Unterstützungsbedarfs werden im folgenden Abschnitt 4.1
die Arbeitsschritte bei der Informationsbeschaffung, beim Informationsabruf und bei
der Informationsauswertung, die ein/der Dekan der Universität üblicherweise bei Blei-
beverhandlungen durchführen könnte, detailliert betrachtet. Insbesondere wird dabei der
Schwerpunkt auf den Abruf und das Verstehen von analytischen Berichten gelegt. Im
Gegensatz zu Standardberichten, die eine feste Berichtsstruktur besitzen, meistens nur
über einen recht eingeschränkten Informationsgehalt verfügen und darüber hinaus nur
Dateneinschränkungen über die Auswahl/das Filtern von Merkmalen ermöglichen,
umfassen diese häufig eine Fülle an Auswertungsdimensionen und vordefinierten
3 Beispiel-Szenario für den MSS-Einsatz 27
Kennzahlen, die jederzeit individuell und flexibel, je nach aktueller Fragestellung er-
weitert und gestaltet werden können. Der Umgang mit analytischen Berichten und deren
Werkzeugen stellt höhere Anforderungen an die Anwender. Dies soll im Folgenden
dargestellt/verdeutlicht und bestätigt werden.
4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario
4.1 Identifikation und Analyse des Unterstützungsbedarfs
Ausgangssituation der folgenden Spezifizierung des Szenarios ist, dass ein Professor
einen Ruf an eine andere Universität erhalten hat und der Dekan des betreffenden Fach-
bereichs der Universität Osnabrück dazu aufgefordert wurde, Bleibeverhandlungen mit
dem Professor zu führen. Im Rahmen der Vorbereitung auf die Verhandlungsgespräche
können nun folgende Unterstützungsfälle/-situationen auftreten:
Für die Verhandlungen benötigt der Dekan sowohl Informationen über die Ist-Ausstat-
tung und das Leistungsprofil des Professors als auch über die finanziellen Handlungs-
spielräume des Fachbereichs. Diese und weitere Informationen sind über das MIS der
Universität verfügbar, so dass der Dekan dort nach den relevanten Informationen über
den Professor und den Fachbereich suchen könnte. Eine typische Schwierigkeit, die an
dieser Stelle auftreten könnte, ist, dass der Dekan gar nicht alle Informationsquellen
(Datenwürfel, Standardberichte usw.) kennt, die im MIS der Universität Osnabrück zur
Verfügung stehen und die er nach relevanten Informationen durchsuchen könnte, und
dass er nicht weiß, wo er gezielt bestimmte Informationen wie z. B. über den Professor,
finden und wie er darauf zugreifen kann1. „Diese Objekte sind nur zugänglich, wenn
dem Entscheidungsträger bekannt ist, dass sie existieren, wo und wie sie zu finden sind,
und vor allem, dass sie inhaltlich im aktuellen Kontext relevant sind“ [MeRi01a, S.
106]. Aus diesen Gründen kann es vorkommen, dass die reine Informationsbeschaffung
schon sehr viel Zeit beansprucht. Da diese Zeit selten einem Management-Aufgaben-
träger wie z. B. dem Dekan zur Verfügung steht, wird zumeist nur auf die schon be-
kannten Informationsquellen zurückgegriffen. Geeignete Suchhilfen können verhindern,
dass die Recherche auf vordergründig bekannte Informationsquellen beschränkt bleibt
und die erarbeitete Informationsbasis für die Verhandlungsgespräche nur suboptimal ist.
Eine weitere Unterstützungssituation kann sich ergeben, wenn der Dekan die gesammel-
ten Informationen, wie z. B. die Standardberichte über das Prüfungsangebot je Prüfer
und die Personalhistorie sowie die analytischen Berichte zur Prüfungsstatistik, Prü-
fungsbelastung und Stellenbesetzung, sichtet und die relevanten Informationen für die
Verhandlungsgespräche herausarbeitet. Während der Unterstützungsbedarf bei Stan-
1 Mentrup und Rieger stellten bereits 2001 heraus, dass dieses Wissen über die Informationsobjekte für
die effiziente Nutzung von MSS eine zentrale Rolle spielt [vgl. MeRi01a, S. 106-107].
4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario 29
dardberichten im Wesentlichen auf deren Aktualitätsprüfung und inhaltliche Interpreta-
tion, z. B. Abkürzungen, Formelbeschreibungen usw. beschränkt ist, kommen bei analy-
tischen bzw. OLAP-Berichten Hilfestellungen in Bezug auf Parametereinstellungen
hinzu. Im Gegensatz zu Standardberichten ist bei analytischen Berichten der implizite
Informationsgehalt zumeist viel höher und die Darstellung der Informationen dazu auch
variabel gestaltbar. Folgende Abbildung 4-1 zeigt ein Beispiel einer analytischen
Berichtssicht, die über das OLAP-Werkzeug Cognos PowerPlay Web Explorer abrufbar
ist. Die Sicht zeigt die Prüfungsbelastung je Fachgebiet über einen Zeitraum von sechs
Semestern (vom SS 2004 bis zum WS 2006/2007) gemessen anhand der Kennzahl
„AnzEcht2SWSnetto“. Aufgrund der Komplexität der Anwendung und der vielfältigen
Einstellmöglichkeiten hat der Dekan, der im Umgang mit dem OLAP-Werkzeug eher
ungeübt ist, da er das Werkzeug nur gelegentlich nutzt, sehr viel Mühe, die Informa-
tionen aus dem Bericht richtig abzulesen. Der Dekan benötigt dafür Kenntnisse über
den Aufbau des Werkzeugs, dass z. B. die Informationen in Form einer Kreuztabelle
dargestellt werden, wobei die gerade betrachtete Kennzahl in der oberen linken Ecke
der Tabelle ausgewiesen wird. Des Weiteren muss er wissen, dass über die Dimen-
sionsleiste (direkt über der Kreuztabelle) Filter gesetzt sein könnten, die die Datensicht
auf bestimmte Merkmale eingrenzen. Zum Beispiel würde die Dimension Semester auf
„20062“ gesetzt bedeuten, dass nur die Daten des Wintersemesters 2006/2007 betrachtet
werden. Verständnis- und Interpretationsprobleme können auch auftreten, wenn das
Hintergrundwissen bzw. die Zusatzinformationen fehlen, wie z. B. die Formellogik der
Kennzahl „AnzEcht2SWSnetto“ definiert ist. Ohne Metadaten über die Berichte, wie
z. B. die Bedeutung der einzelnen Merkmale oder die Berechnungsvorschriften der
Kennzahlen, kann es zu Fehlinterpretationen der Informationen kommen und damit zu
einer schlechten Verhandlungsposition aufgrund falscher oder fehlender Argumenta-
tionshilfen. Auch wenn der Dekan alle nötigen Informationen zur korrekten Interpreta-
tion der Berichtssicht erarbeitet hat, könnte es ihm dennoch schwer fallen, die Sicht
entsprechend zu beschreiben und den Kontext wiederzugeben. Je nach Einstellung kön-
nen ganz unterschiedliche Aussagen aus einem Bericht abgeleitet werden.
4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario 30
Abb. 4-1: Beispiel einer analytischen Berichtssicht über die Prüfungsbelastung
Bei der Begutachtung der gefundenen Informationen (Berichte) könnte es nun passie-
ren, dass der Dekan die Informationen in der vorliegenden Form zur Vorbereitung auf
die Verhandlungsgespräche als nur wenig bis gar nicht geeignet beurteilt. Dies hat zur
Folge, dass der Dekan für seine konkrete Fragestellung einen vorhandenen Bericht
selbst anpassen oder sich einen ganz neuen Bericht zusammenstellen müsste. Zum Bei-
spiel könnte der Dekan folgende Informationen wissen wollen: Wie verteilen sich bei
dem Professor die Studierenden auf die einzelnen Leistungspunkttypen (d. h. Klausuren,
Seminare, Abschlussarbeiten) über die Semester? Um für diese Fragestellung einen
Bericht zu erzeugen, muss der Dekan zusätzlich zum Wissen über die zur Verfügung
gestellten Inhalte Kenntnisse über die Funktionalität des Werkzeugs haben, also wo und
wie Daten ausgewählt, gefiltert, neuberechnet und dargestellt werden können. Ausge-
hend von der Berichtssicht aus Abbildung 4-1 muss der Anwender zur Anpassung der
Einstellungen folgende Schritte durchführen:
Zunächst muss er die Fragestellung interpretieren, d. h. zu den in der Fragestellung vor-
kommenden Merkmalen die passenden Äquivalente im Berichtswerkzeugs identifizie-
ren, also dass z. B. mit „die Studierenden“ die Kennzahl „AnzEcht“ gemeint ist. An-
schließend muss er zu der betreffenden Kennzahl bzw. zu den betreffenden Dimensio-
nen navigieren und dann die entsprechenden Merkmalswerte selektieren. Die Kennzahl
4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario 31
muss in diesem Fall von der „AnzEcht2SWSNetto“ auf „AnzEcht“ umgestellt und die
in den Zeilen angezeigte Dimension Fachgebiet („ZuFachgebiet“) durch die Dimension
Leistungspunkttyp („LPTyp“) ersetzt werden. Des Weiteren muss eine Dimension nach
einem bestimmten Merkmalswert gefiltert werden, und zwar die Dimension Dozent
(„ZuDozent“) auf den Namen des Professors2. Das Ergebnis der Berichtsanpassungen
ist in der Abbildung 4-2 dargestellt.
Abb. 4-2: Angepasste Berichtssicht über die Prüfungsbelastung
Das Wissen über die einzelnen auszuführenden Funktionen (Navigation, Selektion, Fil-
tern, Sortieren usw.) kann zwar über die mitgelieferte Online-Hilfe erworben werden.
Wie Erfahrungen bei der Einführung des MIS an der Universität Osnabrück gezeigt
haben, ist diese Form der Unterstützung jedoch nicht ausreichend. Die von den MSS-
Werkzeugen bereitgestellten Online-Hilfesysteme bieten nur punktuelle und anwen-
dungsunabhängige Hilfestellungen an. Das heißt konkret am Beispiel des MSS-Werk-
zeugs Cognos PowerPlay Web Explorer, dass für jede einzelne Funktion eine allge-
meine Beschreibung zur Verfügung gestellt wird, sowie Erläuterungen über die Vorge-
hensweise bei deren Anwendung gegeben werden. Stellenweise werden auch noch zu
einigen Funktionen Hinweise und Tipps angeboten. Die Anwender wie z. B. der Dekan
stehen aber vor dem Problem, dass sie nicht wissen, wie sie mit dem MSS-Werkzeug an
so eine Fragestellung herangehen sollen. Ihnen fehlt das Wissen über die Vorgehens-
weise bzw. den Prozess der Problemlösung, also wohin sie navigieren müssen, um eine
ganz bestimmte Auswahl zu treffen, wie sie Filter und welche Filter sie setzen und wel-
2 Aus Datenschutzgründen wurde der Name des selektierten Professors unkenntlich gemacht.
4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario 32
che Berechnungen sie durchführen müssen. Zur Beantwortung so einer Fragestellung
müssen stets mehrere Einzelschritte/-funktionen kombiniert ausgeführt werden. Die
Online-Hilfesysteme bieten bei der Frage, welche genau und in welcher Reihenfolge,
keine entsprechende Unterstützung, der Anwender ist somit auf sich allein gestellt.
4.2 Klassifikation des Unterstützungsbedarfs
Aus der im vorherigen Abschnitt 4.1 durchgeführten Analyse der Probleme und
Schwierigkeiten, die ein Anwender wie z. B. ein Dekan der Universität Osnabrück im
Umgang mit MSS-Werkzeugen hat, ergibt sich eine Klassifikation des potenziellen
MSS-Unterstützungsbedarfs in zwei Bereiche, und zwar
1. inhaltliche Unterstützung und
2. funktionale bzw. technische Unterstützung.
Bei der inhaltlichen Unterstützung geht es primär darum, dem Anwender beim Verste-
hen der Daten und bei der Interpretation der Daten (z. B. eines Berichtes) zu helfen,
z. B. um die Eignung einer Kennzahl für die konkrete Fragestellung festzustellen. Dies
kann beispielsweise erreicht werden, indem dem Anwender bestimmte Zusatzinforma-
tionen (z. B. die Beschreibung eines Merkmals oder die Definition einer Kennzahl) an-
geliefert werden. Oder dadurch, dass gewisse abgeleitete Daten, wie die Beschrei-
bungen der einzelnen Elemente einer Kennzahlendefinition oder Dokumente/Text-
stellen, in denen auf die gerade betrachtete Berichtssicht verwiesen wird, ermittelt und
dem Anwender zur Verfügung gestellt werden. Eine weitere Form der inhaltlichen Un-
terstützung wäre die automatische Generierung einer Beschreibung der Berichtssichten.
Gelingt es, den Berichtskontext zumindest partiell automatisch zu ermitteln und daraus
einen Beschreibungstext als Vorschlag zu generieren, könnte dieser Vorschlag dem
Anwender beim Verstehen der Zusammenhänge helfen und als Dokumentation genutzt
werden. Zusätzlich würde damit das Wiederauffinden einer vom Anwender selbst oder
von anderen früher erstellten Berichtssichten unterstützt werden.
Unter funktionaler bzw. technischer Unterstützung ist die gesamte Anwendungslogik
von MSS-Werkzeugen zu verstehen. Sie umfasst Hilfestellungen bei der Bedienung der
Werkzeuge sowie beim Konfigurieren und Selektieren der dargebotenen Funktionen.
Der Anwender könnte beispielsweise bei der Nutzung der Software geführt und bei der
Auswahl und Vorgabe von Daten unterstützt werden. Die Unterstützungsleistung
4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario 33
könnte sogar soweit gehen, dass auf Basis der vom Anwender gemachten Informations-
bedarfsbeschreibung die notwendigen Einstellungen des Werkzeuges automatisch vor-
genommen werden. Bei einem OLAP-Werkzeug z. B. könnte dem Anwender dann
direkt die fertig eingestellte Berichtssicht präsentiert werden.
Eine andere Art der funktionalen Unterstützung liegt im Bereich der Informationssuche.
Hier könnte der Anwender sowohl bei der Suche nach Informationen innerhalb eines
MSS-Werkzeugs, aber auch MSS-Werkzeug-übergreifend unterstützt werden. Letzterer
Bereich spielt wegen des Zeitaspekts eine große Rolle. Bei der Informationssuche muss
der Anwender gewöhnlich jedes MSS-Werkzeug einzeln aufrufen und die dort vorge-
haltenen (die MSS-Werkzeug eigenen) Suchfunktionen nutzen. Je nachdem wie viele
unterschiedliche MSS-Werkzeuge dem Anwender zur Verfügung stehen, muss er somit
dieselbe Suchanfrage mehrmals spezifizieren, häufig auch auf unterschiedliche Art und
Weise, was viel Zeit in Anspruch nimmt. An dieser Stelle wäre eine Unterstützung
wünschenswert, die es ermöglicht, einmalig die Suchanfrage zu definieren, die dann auf
alle möglichen Informationsquellen (MSS-Werkzeug-übergreifend) angewendet werden
kann und im Ergebnis dem Anwender eine Menge an Informationen, die aus unter-
schiedlichen Informationsquellen stammen können, zurückliefert.
Den beiden identifizierten Unterstützungsbereichen (inhaltlich und funktional) lassen
sich, abgeleitet aus den vorherigen Beschreibungen, verschiedene potenzielle Unterstüt-
zungsfunktionen zuordnen (siehe Tabelle 4-1). Zu den inhaltlichen Unterstützungs-
funktionen zählen beispielsweise Beschreibung, Interpretation, Erklärung und Analyse.
Unterstützungsfunktionen des funktionalen Bereiches sind Werkzeug-übergreifende
Suche, Präsentation und Navigation. Da bei einer Problemlösung stets mehrere dieser
Unterstützungsfunktionen fallspezifisch kombiniert benötigt werden, muss ein MSS-
Unterstützungs- bzw. Assistenzsystem besondere Charakteristika aufweisen. Welche
Eigenschaften dies sind, wird im folgenden Abschnitt dargelegt.
4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario 34
Inhaltlich Funktional
• Beschreibung
• Interpretation
• Erklärung
• Analyse
• ...
• Suche (Werkzeug-übergreifend)
• Präsentation
• Navigation
• ...
Tab. 4-1: Mögliche MSS-Unterstützungsfunktionen
4.3 Anforderungen/Charakteristika einer Assistenz
Aufgrund der variierenden und iterativ ablaufenden Schritte, die üblicherweise ein An-
wender während einer Problemlösung mittels MSS ausführt, muss ein System zur
Unterstützung des Anwenders ähnlich flexibel gestaltet sein. Die identifizierten Unter-
stützungsfunktionen wie Interpretation, Erklärung, Navigation, Suche usw. müssen
selektiv und kombiniert abrufbar sein, um dem Anwender eine bestmögliche Unter-
stützung zu bieten. Ein Assistenzsystem zur Unterstützung des Anwenders im Umgang
mit MSS muss daher folgende Charakteristika aufweisen:
• Flexibilität
• Dynamik
• Adaptivität
• Rekombination.
Flexibilität im Sinne der Informationstechnik entspricht der „Fähigkeit eines DV-Sys-
tems auf Änderungen (z. B. der Systemumgebung oder Betriebsweise [...]) schnell und
entgegenkommend zu reagieren“ [Haup97, S. 328]. Aufgrund der Vielgestaltigkeit, die
Problemstellungen im MSS-Umfeld in der Regel aufweisen, und der jeweils variieren-
den Ausgangssituation gibt es keine einheitliche bzw. routinemäßige Vorgehensweise
für deren Lösung. Die einzelnen zur Bearbeitung notwendigen Funktionen werden
vielmehr aufgabentyp- und fallspezifisch zusammengestellt und ausgeführt. Das Assis-
tenzsystem muss daher die Möglichkeit besitzen, sich ebenfalls flexibel auf wechselnde
Entscheidungssituationen einzustellen und sich schnell und effektiv an die geänderten
Gegebenheiten anzupassen.
Mit dem Begriff Dynamik wird in dieser Arbeit die Eigenschaft beschrieben, dass bei
Hard- und Softwaresystemen die Anforderungen z. B. an deren Verhalten bzw. Funk-
4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario 35
tionalität nie abgeschlossen und stabil vorliegen, sondern sich in einer stetigen Ent-
wicklung an neue bzw. veränderte Anforderungen befinden. Eine vom Anwender zu
bearbeitende Problemstellung ist selten eindeutig und starr definiert. Vielmehr wird sie
aufgrund des sich stetig verändernden Wissenstandes des Anwenders im Entscheidungs-
prozess fortwährend variiert bzw. modifiziert. Daher muss das Assistenzsystem eben-
falls auf Veränderungen seitens des Anwenders dynamisch reagieren können. Wird bei-
spielsweise eine Anfrage des Anwenders bereits vom Assistenzsystem bearbeitet, der
Anwender verändert jedoch aufgrund zusätzlicher Informationen die Angaben seiner
Fragestellung, so muss das System die neuen bzw. erweiterten Angaben in seinem lau-
fenden Bearbeitungsprozess berücksichtigen. Sind neue Informationsquellen hinzu-
gekommen, so müssen diese ebenfalls vom Assistenzsystem sofort mit berücksichtigt
werden, z. B. im Falle einer Suche oder Abfrage.
Der Begriff Adaptivität steht allgemein „für die Eigenschaft eines Systems, sich an eine
verändernde Umwelt selbst anzupassen oder aber entsprechend den Bedürfnissen anpas-
sen zu lassen“ [Schr01, S. 6-7]. Bezüglich des Assistenzsystems wird mit dieser Eigen-
schaft gefordert, dass das System die Fähigkeit besitzt, eigenständig auf modifi-
zierte/wechselnde Bedingungen zu reagieren. Führt beispielsweise die Bearbeitung
einer Problem- bzw. Fragestellung gemäß der zuvor ermittelten Vorgehensweise zu
keinen oder zu nicht befriedigenden Ergebnissen, muss das System in der Lage sein,
neue Lösungswege zu erarbeiten und auszuführen. Ohne die Fähigkeiten der Anpassung
und Erweiterbarkeit kann das Assistenzsystem sich nicht auf geänderte Funktionalitäten
der MSS-Werkzeuge und/oder geänderte Anforderungen der Anwender einstellen.
Das Prinzip der Rekombination findet in der Informationstechnik vor allem im Bereich
der genetischen Algorithmen3 Anwendung. Hierbei werden für ein Entscheidungspro-
blem eine Menge von Lösungen (Ausgangspopulation) zufällig erzeugt, mutiert und
kombiniert, um daraus neue Lösungen zu generieren, die einem bestimmten Gütekri-
terium (Fitnesswert) am besten entsprechen [vgl. Kopf01, S. 209-210].
Im Rahmen dieser Arbeit soll damit die Eigenschaft von Systemen beschrieben werden,
ihre bereitgestellten Funktionen beliebig bei der Aufgabenlösung zu kombinieren. Auf-
grund der zumeist sehr unterschiedlich gestalteten Frage- bzw. Problemstellungen, die
die Anwender im MSS-Umfeld zu bearbeiten haben, muss ein Assistenzsystem fähig
3 „Ein Genetischer Algorithmus (GA) ist ein Suchverfahren zur Lösung komplexer Optimierungs-
probleme, das auf der Selektion und Reproduktion von Lösungen basiert“ [Kopf01, S. 209].
4 MSS-Unterstützungsbedarf an dem Beispiel-Szenario 36
sein, die von ihm zur Verfügung gestellten Unterstützungsfunktionen frei (d. h. unab-
hängig von einer festen Reihenfolge der Funktionsaufrufe) anzuwenden. Die Bearbei-
tung einer Fragestellung kann beispielsweise zunächst eine Interpretation (Interpreta-
tionsfunktion) erfordern, um so die zu berücksichtigenden, relevanten Merkmale zu
identifizieren. Im nächsten Schritt ist dann die Suche (Suchfunktion) und Abfrage (Ab-
fragefunktion) von bereits vorliegenden Informationen zu der Problemstellung, z. B. in
Form von Berichtssichten oder Beschreibungen, notwendig. Eine andere Problem-
stellung dagegen kann als erstes die Erzeugung eines neuen Berichtes (Navigations-
funktion) erfordern, dessen Kontext anschließend noch interpretiert (Interpretations-
funktion) und beschrieben (Erklärungsfunktion) werden muss.
Durch Konzepte wie Autonomie, Kooperation und Intelligenz soll in der Agententech-
nologie die Entwicklung solcher dynamischer und flexibler Systeme möglich sein [vgl.
Nwan96; WoJe95a, S. 22]. Aus diesem Grund soll eine Lösung basierend auf der Agen-
tentechnologie untersucht werden. In den folgenden Abschnitten wird dazu auf das
Paradigma der Agententechnologie eingegangen und die Gestaltungsmöglichkeiten
agentenbasierter Systeme beschrieben.
TEIL II
AGENTENBASIERTES KONZEPT
EINER MSS-ASSISTENZ
5 Gestaltungspotenziale des agentenbasierten Paradigmas
5.1 Definition und Eigenschaften von Agenten
Für den Begriff „Agent“ bzw. „Softwareagent“ liegt in der Forschung und Praxis keine
einheitliche und allgemein akzeptierte Definition vor. Vielmehr existieren unterschied-
liche Auffassungen bezüglich der Eigenschaften (wie z. B. Autonomie, Intelligenz,
Mobilität, Reaktivität, Kommunikation und Kooperation), die ein Agent besitzen sollte
[vgl. FrGr97, S. 21 ff; Wool97, S. 47-48; Brad97, S. 5 ff]. Zurückzuführen ist dies vor
allem auf die hohe Interdisziplinarität des Agenten-Ansatzes aufgrund der Einflüsse aus
den Forschungsrichtungen Künstliche Intelligenz (KI), Informations- und Kommunika-
tionssysteme, Informatik und Sozialwissenschaft [vgl. BZW98, S. 21]. Wooldridge und
Jennings beispielsweise, die auf dem Gebiet der Künstlichen Intelligenz tätig sind,
charakterisieren einen Agenten als eine Hard- oder Softwareeinheit, die über folgende
Eigenschaften verfügen muss [vgl. WoJe95b, S. 116]:
• „autonomy: agents operate without the direct intervention of humans or others, and
have some kind of control over their actions and internal state […];
• social abilitiy: agents interact with other agents (and possibly humans) via some kind
of agent-communication language […];
• reactivity: agents perceive their environment (which may be the physical world, a
user via a graphical user interface, a collection of other agents, the Internet, or
perhaps all of these combined), and respond in a timely fashion to changes that
occur in it;
• pro-activeness: agents do not simply act in response to their environment, they are
able to exhibit goal-directed behaviour by taking the initiative.” [WoJe95b, S. 116].
Diese auch als „Weak Notion of Agency“ bekannte Definition von Wooldridge und
Jennings wurde von Shoham [Shoh93] noch verschärft (zur sogenannten „Stronger
Notion of Agency“), indem er einem Agenten zusätzlich auch „mentalistische“ Eigen-
schaften wie Überzeugungen (beliefs), Absichten (intentions), Verpflichtungen (obliga-
tions) usw. zuschreibt [vgl. WoJe95b, S. 116-117].
Im Kontext der Agententechnologie werden eine Vielzahl weiterer Eigenschaften dis-
kutiert [vgl. WoJe95b, S. 117; FrGr97, S. 29; Brad97, S. 8; BZW98, S. 25-33; Alba98,
S. 3; Burk03, S. 951-953]. Zu den am häufigsten genannten Eigenschaften gehören
Mobilität, Kommunikation, Kooperation und Lernfähigkeit (Intelligenz). Diese werden
5 Gestaltungspotenziale des agentenbasierten Paradigmas 39
im Folgenden näher erläutert, da sie bei der Gestaltung flexibler und dynamischer
Systeme eine große Rolle spielen.
Die Eigenschaft Mobilität beschreibt die Fähigkeit eines Agenten, sich in einem elek-
tronischen Netzwerk von einem System/Rechner zu einem anderen System/Rechner
bewegen zu können [vgl. Brad97, S. 8; BZW98, S. 30]. Ein mobiler Agent verfügt so-
mit, im Gegensatz zu einem stationären Agenten, der an einem bestimmten Ort/Rechner
gebunden ist [vgl. BZW98, S. 30], über „räumliche Autonomie“1 [Eyma03, S. 22].
Kommunikationsfähigkeit bedeutet, dass ein Agent in der Lage ist, mit seiner Umwelt
(d. h. mit menschlichen Anwendern und/oder mit anderen Agenten und/oder IuK-
Systemen) zu interagieren und Informationen auszutauschen [vgl. BZW98, S. 31]. Für
die Kommunikation zwischen Agenten sind bestimmte Voraussetzungen zu schaffen.
Welche dies sind und welche Kommunikationsverfahren es gibt, ist Gegenstand des
Abschnitts 5.4.
Mit Kooperation wird die Fähigkeit bezeichnet, dass Agenten bei der Lösung von
Problemen mit anderen Agenten zusammenarbeiten können [vgl. Alba98, S. 3]. Da die
Ressourcen eines einzelnen Agenten beschränkt sind, können durch die Kooperation mit
anderen Agenten Probleme bzw. Aufgaben (vor allem solche komplexerer Art) häufig
besser und in kürzerer Zeit gelöst werden [vgl. BZW98, S. 31], z. B. indem die unter-
schiedlichen Arbeits-/Lösungsschritte auf die einzelnen Agenten aufgeteilt werden.
Welche Formen der Kooperation es gibt, wird im Abschnitt 5.5 dargestellt. Damit
Agenten miteinander kooperieren können, müssen sie über die Fähigkeit der Kommuni-
kation verfügen (siehe Abschnitt 5.4) [vgl. Alba98, S. 3].
Die Eigenschaft des Lernens befähigt Agenten aus der Beobachtung der Umwelt heraus
zu lernen und sich bei Veränderungen der Umwelt entsprechend anzupassen. Dies setzt
voraus, dass die Agenten einen gewissen Grad an (künstlicher) Intelligenz haben, also
über eine interne Wissensbasis verfügen, sowie Schlussfolgerungsmechanismen besit-
zen mittels derer sie ihre Aktionen mit der Umwelt umsetzen und ihre interne Wissens-
basis erweitern [vgl. BZW98, S. 27-28].
Je nachdem für welchen Zweck die Softwareagenten entwickelt und eingesetzt werden
(z. B. Netzmanagement, Informationsmanagement, Electronic Commerce, usw.), wer-
den unterschiedliche Schwerpunkte gesetzt und andere Anforderungen bezüglich der
1 Eymann verbindet mit „räumliche Autonomie“ die Eigenschaft, dass ein Agent den Ort seiner Aus-
führung frei bestimmen/wählen kann [vgl. Eyma03, S. 22].
5 Gestaltungspotenziale des agentenbasierten Paradigmas 40
Eigenschaften an die Agenten gestellt. Der in dieser Arbeit verfolgte Zweck des Agen-
teneinsatzes ist die Unterstützung der Anwender beim Umgang mit MSS-Werkzeugen.
In Anlehnung an Brenner et al. wird ein intelligenter Softwareagent definiert als „...ein
Softwareprogramm, das für einen Benutzer bestimmte Aufgaben erledigen kann und
dabei einen Grad an Intelligenz besitzt, der es befähigt, seine Aufgaben in Teilen auto-
nom durchzuführen und mit seiner Umwelt auf sinnvolle Art und Weise zu interagie-
ren.“ [BZW98, S. 23]. Ein Agent gemäß dieser Definition zeichnet sich vor allem durch
Eigenschaften wie Intelligenz, Autonomie und Kooperationsfähigkeit aus, was den in
dieser Arbeit gestellten Anforderungen an eine MSS-Assistenz entspricht (vgl. Ab-
schnitt 4.3).
Zur Lösung umfangreicher Probleme bzw. Aufgaben werden zumeist sehr viele Infor-
mationen und sehr viel Wissen benötigt, so dass sich der Aufbau eines Agenten sehr
komplex gestalten würde. Aus diesem Grund haben sich neben Ein-Agent-Systemen,
bei denen ein Agent nur mit seiner Umwelt, d. h. seinem Benutzer und den ihm
bekannten Informationsquellen wie z. B. Datenbanken, kommuniziert, Multi-
Agentensysteme durchgesetzt, die sich aus mehreren voneinander unabhängigen
Agenten zusammensetzen, die miteinander kommunizieren und interagieren [vgl.
BZW98, S. 35]. Ziel eines Multi-Agentensystems ist es, durch den Zusammenschluss
von Agenten vielschichtige und umfassende Probleme zu lösen, die von einem
einzelnen Agenten aufgrund seiner vergleichsweise geringen Ressourcen2 nicht zu
bewältigen sind [vgl. Zarn99, S. 77].
5.2 Klassifikationsansätze von Agenten
In der Literatur existiert eine Vielzahl an Klassifikationsansätzen für Agenten [vgl.
Brus91; GAA+95; SDP+96; FrGr97, S. 29ff; Nwan96], die zumeist unterschiedliche
Kriterien zur Einordnung der Agenten verwenden. Bei einigen Ansätzen, wie z. B. bei
[GAA+95], erfolgt die Klassifikation anhand der Eigenschaften (siehe Abschnitt 5.1),
die Agenten besitzen sollen. Andere Ansätze (wie z. B. [SDP+96] und [FrGr97, S. 31])
ordnen Agenten anhand ihrer Aufgabenschwerpunkte ein [vgl. Zarn99, S. 24].
„Agents may also be classified by the range and sensitivity of their senses, or by the
range and effectiveness of their actions, or by how much internal state they possess.“
2 Als Beispiele für die Ressourcen eines Agenten nennt Ferber [Ferb01] Dinge wie „...Energie, eine CPU,
Speicher, Zugang zu bestimmten Informationsquellen usw.“ [Ferb01, S. 30].
5 Gestaltungspotenziale des agentenbasierten Paradigmas 41
[FrGr97, S. 29]. Im Folgenden werden die Klassifikationen von Gilbert et al.
[GAA+95], Franklin und Graesser [FrGr97] und Nwana [Nwan96] vorgestellt, da auf
diese Klassifikationen in der Literatur am häufigsten verwiesen wird [vgl. Brad97, S. 9-
11; Zarn99, S. 24; Vulk99, S. 71-72].
Gilbert et al. [GAA+95] klassifizieren intelligente Agenten mit Hilfe eines mehrdimen-
sionalen Raumes, bestehend aus den drei Eigenschaften Agentenfähigkeit (Agency),
Intelligenz (Intelligence) und Mobilität (Mobility) (siehe Abbildung 5-1) [vgl. Brad97,
S. 9]. „Agency is the degree of autonomy and authority vested in the agent, and can be
measured at least qualitatively by the nature of the interaction between the agent and
other entities in the system” [Zitat von GAA+95 in Brad97, S. 9]. Während die Eigen-
schaft der Mobilität den Grad der Beweglichkeit, die ein Agent innerhalb eines Netz-
werkes besitzt, beschreibt (von statisch bis mobil), wird mit Intelligenz der Ausprä-
gungsgrad des Schlussfolgerns und des Lernens eines Agenten wiedergegeben [vgl.
Brad97, S. 9]. Als Mindestanforderung wird hier die Existenz von Präferenzen und ein
Schlussfolgerungsmechanismus, der danach handelt, vorausgesetzt. Auf den oberen
Stufen der Intelligenz sind dann solche Systeme angesiedelt, die in der Lage sind zu
lernen und sich in ihrer Umgebung anzupassen [vgl. GAA+95]. Gemäß der Klassi-
fikation von Gilbert et al. gestaltet sich ein Agent umso komplexer, je höher seine
Werte auf den einzelnen Achsen sind.
IntelligencePreferences
Reasoning Planning
Learninig
Agency
Service interactivity
Application interactivity
Data interactivitiy
Representation of user
Asynchrony
Mobility Static Mobile scripts Mobile objects
Expert Systems
Fixe
d-Fu
nctio
nA
gent
s Intelligent Agents
Abb. 5-1: Klassifikation von Gilbert et al. [GAA+95] [vgl. Brad97, S. 9]
Learning
Zur Klassifikation von Agenten wendeten Franklin und Graesser das in Abbildung 5-2
dargestellte biologische Taxonomie-Modell an [vgl. FrGr97, S. 30]. „The biological
5 Gestaltungspotenziale des agentenbasierten Paradigmas 42
taxonomy takes the form of a tree with “living creatures“ at the root and individual spe-
cies at the leaves” [FrGr97, S. 30]. Auf der obersten Ebene der Hierarchie sind die
Autonomen Agenten (Autonomous Agents) angeordnet. Diese unterteilen sich auf der
darunter liegenden Ebene in Biologische Agenten (Biological Agents), Roboter Agen-
ten (Robotic Agents) und Rechnergestützte Agenten (Computational Agents). Bei den
zuletzt genannten Agenten erfolgt wiederum eine Unterteilung in die beiden Klassen
Softwareagenten (Software Agents) und Künstliche Agenten (Artificial Life Agents).
Auf der untersten Stufe werden die Softwareagenten schließlich noch in die Unterklas-
sen aufgabenspezifische Agenten (Task-specific Agents), Unterhaltungsagenten (Enter-
tainment Agents) und Viren (Viruses) gegliedert. Die Einordnung der entwickelten
Agenten in die verschiedenen Klassen erfolgt zum Teil auf Basis subjektiver Ein-
stellungen über die Agenten. Daher ist das Klassifikationsmodell von Franklin und
Graesser nicht unumstritten [vgl. Kreu01, S.18].
Viruses Task-specific Agents
Artificial Life Agents
Autonomous Agents
Software Agents
Computational Agents Robotic AgentsBiological Agents
Entertainment Agents
Abb. 5-2: Klassifikation von Franklin und Graesser [FrGr97, S. 31]
Im Gegensatz zu den zwei vorherigen Klassifikationen verwendet Nwana in seiner
Typologie sowohl das Kriterium der Eigenschaften als auch das Kriterium der Aufga-
benschwerpunkte [vgl. Zarn99, S. 24]. Als erstes definiert Nwana die drei Eigen-
schaften Kooperation (Cooperate), Lernfähigkeit (Learn) und Autonomie (Autonomous)
(vgl. Abschnitt 5.1) [vgl. Nwan96]. Auf der Grundlage dieser drei als “ideal and
primary” eingestuften Eigenschaften ordnet er schließlich den Agenten Aufgaben-
schwerpunkte zu. Insgesamt unterscheidet Nwana vier Typen von Agenten und zwar
Interface Agenten (Interface Agents), Kooperative Agenten (Collaborative Agents),
Intelligente Agenten (Smart Agents) und Kooperative Lern-Agenten (Collaborative
Learning Agents) (vgl. Abbildung 5-3) [vgl. Nwan96]. Während Interface Agenten
durch die Eigenschaften Autonomie und Lernfähigkeit gekennzeichnet werden, weisen
5 Gestaltungspotenziale des agentenbasierten Paradigmas 43
Kooperative Agenten die Eigenschaften Kooperation und Autonomie auf. Einzig Intel-
ligente Agenten besitzen nach Nwana alle drei Eigenschaften [vgl. Nwan96].
Learn
Autonomous
Cooperate
InterfaceAgents
Collaborative Learning Agents
Smart Agents
Collaborative Agents
Abb. 5-3: Klassifikation von Nwana [vgl. Nwan96]
Zur Bestimmung der für das Lösungskonzept (zur MSS-Assistenz) in Frage kommen-
den Agententypen wird die von Nwana aufgestellte Typologie herangezogen, weil die
relevanten Anforderungen darin am explizitesten wiederzufinden sind. Da für das Assis-
tenzsystem vor allem die Eigenschaften Kooperation und Autonomie eine große Rolle
spielen, kommen für die spätere Umsetzung nur Agenten der Klassen Kooperative
Agenten und Intelligente Agenten in Betracht.
5.3 Architekturmodelle von Agenten
Bezüglich der softwaretechnischen Realisierung eines Agenten werden drei Typen von
Architekturen in der Literatur unterschieden und zwar deliberative, reaktive und hybride
[vgl. WoJe95a, S. 23-33; BZW98, S. 52-60; Eyma03, S. 31-35].
• Deliberative Architektur
Der Ansatz dieser Architektur geht auf das klassische Paradigma der Symbolverar-
beitung aus der Künstlichen Intelligenz zurück. Eine deliberative Architektur ist dem-
nach gekennzeichnet durch das Vorhandensein eines expliziten symbolischen Modells
der Umwelt und dadurch, dass Entscheidungen, z. B. über zukünftige Handlungen,
durch logische oder logik-ähnliche Denk- bzw. Schlussfolgerungsprozesse getroffen
werden, die auf Symbolverarbeitung basieren [vgl. WoJe95a, S. 12]. Die Fähigkeit zur
logischen Schlussfolgerung benötigt ein deliberativer Agent, um auf Basis des Wissens
aus seinem Umweltmodell seinen internen bzw. mentalen Zustand (bestehend aus Über-
zeugungen, Wünschen und Intentionen) anpassen zu können. Aufgrund der hohen
5 Gestaltungspotenziale des agentenbasierten Paradigmas 44
Komplexität der Repräsentationen, sowohl des Umweltmodells als auch des internen
Zustandes ist eine praktische Umsetzung der deliberativen Architektur sehr schwierig.
Bedingt durch ihre eher starre Struktur (vorab definiertes Umweltmodell, welches nur
minimal angepasst werden kann) ist ein Einsatz in dynamischen Umgebungen außer-
dem nur eingeschränkt möglich [vgl. BZW98, S. 56].
• Reaktive Architektur
Diese Architektur wurde als Alternative zu dem schwer realisierbaren symbolischen
Ansatz entwickelt. Im Gegensatz zur deliberativen Architektur besitzen reaktive Agen-
ten weder ein internes symbolisches Modell der Umwelt noch die Fähigkeit komplexe
symbolische Schlussfolgerungen zu ziehen [vgl. WoJe95a, S. 14]. Der reaktive Ansatz
geht davon aus, dass die Agenten ihre Intelligenz nicht auf Basis von internen Model-
len, sondern durch die Interaktion mit der Umwelt beziehen. Über Sensoren nehmen sie
Veränderungen ihrer Umwelt wahr, ermitteln bestehende Abhängigkeiten und verar-
beiten diese mittels aufgabenspezifischer Module, die dann entsprechende Aktionen
durchführen [vgl. BZW98, S. 57]. Da die einzelnen Verarbeitungsmodule nur für ganz
bestimmte abgegrenzte Aufgaben konzipiert sind, lassen sich mit dieser Architektur im
Gegensatz zur deliberativen Architektur sehr kompakte und bzgl. einzelner Aufgaben
flexible Agenten erstellen. Aufgrund der dezentralen Struktur sind reaktive Agenten in
ihrem Verhalten auch fehlertoleranter und robuster, da selbst bei Ausfall eines Moduls
die anderen, meist unabhängig ausgelegten Module, weiterhin funktionieren [vgl.
BZW98, S. 59]. Schwierigkeiten ergeben sich bei dieser Architektur jedoch bei der
Unterstützung eines komplexen Verhaltens. Dafür ist eine große Zahl von Modulen
notwendig, was einen erhöhten Synchronisations- und Verwaltungsaufwand zur Folge
hat [vgl. BZW98, S. 85].
• Hybride Architektur
Der Versuch, die Vorzüge der beiden vorherigen Ansätze zu verbinden, führte zur Ent-
wicklung der hybriden Architektur. Dabei handelt es sich um eine Art Mischform, die
sich aus einer deliberativen Komponente zur Planung und Entscheidungsfindung und
einer reaktiven Komponente zur Interaktion mit der Umwelt zusammensetzt [vgl.
BZW98, S. 60]. Durch diese Kombination wird ein robustes, effektives Reagieren zu-
sammen mit einem planvollen, zielgerichteten Vorgehen unterstützt. Die reaktive Kom-
ponente wird dabei für Aufgaben mit hoher Reaktionsgeschwindigkeit und die delibe-
rative Komponente für planerische und andere komplexe Prozesse herangezogen.
5 Gestaltungspotenziale des agentenbasierten Paradigmas 45
5.4 Kommunikationsverfahren und -protokolle
Grundvoraussetzung für die Zusammenarbeit der Agenten in einem Multi-Agenten-
system ist die Fähigkeit der Agenten, in irgendeiner Form miteinander zu kommuni-
zieren, um Informationen auszutauschen. „Kommunikation zwischen Agenten erfordert
zum Einen die Definition von Kommunikationsprotokollen, innerhalb derer Struktur,
Sprache und Inhalte der Kommunikation exakt spezifiziert werden, und zum Anderen
die Auswahl eines Kommunikationsverfahrens, das den Ablauf des eigentlichen Kom-
munikationsprozesses festlegt...“ [Zarn99, S. 80].
In der Literatur werden grundsätzlich zwei verschiedene Ansätze von Kommunikations-
verfahren unterschieden und zwar der blackboardorientierte (Shared Memory) und der
nachrichtenorientierte Ansatz (Message Passing) [vgl. AlBu93, S. 66-71; BZW98, S.
96-105; Zarn99, S. 81-86]. Während Blackboard-Systeme über einen gemeinsamen
Speicherbereich verfügen, über den die Agenten ihre Informationen austauschen, erfolgt
der Informationsaustausch bei nachrichtenorientierten Systemen durch das Versenden
von Nachrichten [vgl. Albu93, S. 67; Zarn99, S. 81-82]. Beide Kommunikationsverfah-
ren können sowohl einzeln als auch kombiniert eingesetzt werden [vgl. Zarn99, S. 82].
Im Folgenden werden die beiden Verfahren näher erläutert.
• Blackboard-Systeme
Beim Blackboard-System wird die Kommunikation über eine zentrale Datenbank (das
so genannte Blackboard) vollzogen, in die alle Agenten eines Multi-Agentensystems
Informationen eintragen und auslesen können [vgl. Eyma03, S. 56] (siehe Abbildung 5-
4).
Ein Kommunikationsvorgang beginnt damit, dass ein Agent einen Eintrag auf das
Blackboard schreibt und so Informationen für alle anderen Agenten des Multi-Agenten-
systems zur Verfügung stellt. Die Agenten prüfen regelmäßig, ob neue Informationen
auf dem Blackboard vorliegen und lesen diese gegebenenfalls aus [vgl. BZW98, S. 96-
97]. Während der schreibende Agent die Informationen einfach auf das Blackboard ab-
legt, ohne genau die Adressaten festzulegen, obliegt es den lesenden Agenten zu ent-
scheiden, ob die Informationen für sie relevant sind [vgl. AlBu93, S. 67].
5 Gestaltungspotenziale des agentenbasierten Paradigmas 46
Agent Agent
Agent
Agent Agent
Agent Agent
Agent
Blackboard
Abb. 5-4: Aufbau eines Blackboard-Systems [BZW98, S. 97]
Neben Blackboard-Systemen, bei denen die Agenten selbst in regelmäßigen Zeitinter-
vallen das Blackboard auslesen, gibt es auch Blackboard-Systeme bei denen das Black-
board selbst die Agenten über den Eingang neuer Informationen benachrichtigt oder
dafür spezialisierte Filteragenten diese Funktion übernehmen [vgl. Eyma03, S. 56-57].
Außer der Variante nur eines Blackboards können auch mehrere dieser Speicherbe-
reiche innerhalb eines Blackboard-Systems existieren. Der Zugang auf ein bestimmtes
Blackboard ist den Agenten erst nach der Registrierung an einer zentralen Stelle mög-
lich. Dadurch werden unberechtigte Zugriffe auf die einzelnen Blackboards unterbun-
den [vgl. BZW98, S. 97].
Da mit steigender Anzahl an Agenten innerhalb eines Blackboard-Systems, die zu ver-
waltende Datenmenge auf dem Blackboard ebenfalls stark anwächst, wird bei neueren
Blackboard-Ansätzen das Blackboard zusätzlich in unterschiedliche Bereiche aufgeteilt.
Dadurch müssen die einzelnen Agenten nicht mehr das gesamte Blackboard nach für sie
relevanten Informationen durchsuchen, sondern können sich auf die für sie wichtigen
Bereiche beschränken, so dass ein gezielter und schneller Zugriff ermöglicht wird [vgl.
Zarn99, S. 83].
Insgesamt bieten Blackboard-Systeme eine flexible und einfache Möglichkeit zur
Kommunikation zwischen Agenten, bei der keine hohen Anforderungen an die Agen-
tenarchitektur gestellt werden. Ein Nachteil von diesem zentralisierten Kommuni-
kationsverfahren ist jedoch, dass das Netzwerk aufgrund der fortlaufenden Speicherung
von Daten auf dem Blackboard und durch das permanente Abrufen von Informationen
der im System verteilten Agenten sehr stark belastet wird. Daher gewinnen die nach-
richtenorientierten Systeme immer mehr an Bedeutung [vgl. BZW98, S. 101].
5 Gestaltungspotenziale des agentenbasierten Paradigmas 47
• Nachrichtenorientierte Systeme
Im Gegensatz zu den Blackboard-Systemen, bei denen die Kommunikation zwischen
den Agenten nur indirekt über das Blackboard stattfindet, kommunizieren bei den nach-
richtenorientierten Ansätzen die Agenten direkt miteinander. Die folgende Abbildung
5-5 stellt das zugrunde liegende Prinzip nachrichtenorientierter Kommunikation dar.
Agent A (Sender)
Agent B (Empfänger)
Nachricht
Abb. 5-5: Kommunikationsprinzip nachrichtenorientierter Systeme [BZW98, S. 102]
Wie in der Abbildung 5-5 zu sehen, schickt Agent A, in der Rolle des Senders, dem
Agenten B, der in diesem Fall die Rolle des Empfängers einnimmt, eine Nachricht zu.
Da der Sender explizit den Empfänger seiner Nachricht spezifiziert und die Nachricht
direkt an ihn übermittelt, hat nur dieser Zugriff auf die in der Nachricht enthaltenen
Informationen [vgl. AlBu93, S. 70]. Einzige Ausnahme bilden hier Broadcast-Systeme,
bei denen die Nachrichten an sämtliche Agenten des Systems übermittelt werden, so
dass alle Agenten über die gleichen Informationen verfügen, d. h. den gleichen Wis-
sensstand besitzen [vgl. Eyma03, S. 56].
Innerhalb eines Multi-Agentensystems werden in der Regel Nachrichten nicht nur iso-
liert voneinander übertragen, sondern wechselseitig zwischen zwei oder auch mehreren
beteiligten Agenten ausgetauscht [vgl. BZW98, S. 104]. Bei dieser als Dialog bezeich-
neten Form der Nachrichtenübermittlung nehmen die Beteiligten abwechselnd die Rolle
des Senders und des Empfängers ein, und eine Nachricht bezieht sich zumeist auf eine
vorherige Nachricht. Die einfachste Form eines Dialog stellt ein Frage-Antwort-Dialog
zwischen zwei Agenten dar [vgl. AlBu93, S.74].
Notwendige Voraussetzung für die Kommunikation zwischen Agenten ist die Existenz
eines Kommunikationsprotokolls, in dem das Format, die Sprache und der Ablauf der
Kommunikation genau definiert sind [vgl. Zarn99, S. 84-85]. Die Nachricht als Kern-
bestandteil der Kommunikation wird durch ein Format und eine Semantik gekenn-
zeichnet [vgl. AlBu93, S. 71]. Während durch das Format Aufbau und Syntax der Nach-
richt explizit beschrieben werden, wird über die Semantik die inhaltliche Bedeutung der
Nachricht festgelegt. Gemäß der von Austin [Aust62] entwickelten Sprechakttheorie
umfasst Kommunikation nicht nur die Übermittlung von Informationen, vielmehr
werden dadurch auch einzelne Aktionen bzw. Handlungen angestoßen [vgl. AlBu93, S.
71]. Ein Sprechakt besteht demnach aus drei Teilen, dem lokutionären Akt, der die reine
5 Gestaltungspotenziale des agentenbasierten Paradigmas 48
Informations-Äußerung bzw. -Übermittlung darstellt, dem illokutionären Akt, der die
mit der Äußerung verbundene Intention des Absenders wie z. B. eine Aufforderung,
eine Bitte oder eine Frage wiedergibt, und dem perlokutionären Akt, der die aufgrund
des Sprechaktes ausgelösten Handlungen beschreibt [vgl. BZW98, S. 103].
Auf Grundlage der Sprechakttheorie sind zwei bedeutende Kommunikationsprotokolle
entwickelt worden: die Knowledge Query and Manipulation Language (KQML)3 und
die FIPA4 Agent Communication Language (FIPA-ACL) [vgl. Eyma03, S. 59]. Je
Protokoll wird das Format der Nachricht, sowie die Form der Nachrichtenübertragung
definiert. Die Grundstruktur einer Nachricht setzt sich aus einer Menge an Parametern,
die die Nachricht, den Inhalt und die Kommunikation näher beschreiben, zusammen
[vgl. BZW98, S. 105-106]. In der Tabelle 5-1 sind als Beispiel die möglichen Parameter
einer FIPA-ACL-Nachricht aufgelistet. Mit Ausnahme der Parameter sender, receiver,
content und performative können die anderen Parameter optional verwendet werden
[vgl. FIPA02a, S. 2]. Parameter Beschreibung Kategorie performative Nachrichtentyp Typ des Sprechaktes sender Absender receiver Empfänger reply-to Antwortempfänger
Teilnehmer der Kom-munikation
content Inhalt der Nachricht language Sprache für den Nachrichteninhalt encoding Codierung des Nachrichteninhalts ontology Ontologie für die Wissensinterpretation
Inhaltsbeschreibung
protocol Interaktionsprotokoll conversation-id Kennung der Interaktion reply-with Kennung für eine Antwort in-reply-to Bezug auf eine vorhergehende Nachricht reply-by Zeitangabe, bis wann eine Antwort gewünscht wird
Interaktionskontrolle
Tab. 5-1: Parameter einer FIPA-ACL Nachricht [vgl. FIPA02a, S. 2]
Über den Parameter performative erfolgt die Typisierung des Sprechaktes einer Nach-
richt, also ob es sich bei der Nachricht z. B. um eine Frage, eine Antwort oder eine Auf-
forderung handelt. [vgl. Kreu01, S. 24]. Insgesamt bietet jedes Kommunikationsproto-
koll ein umfassendes Spektrum an Sprechakttypen (Performative). Während bei der
FIPA-ACL 22 Performative definiert sind [vgl. FIPA02b, S. 3-28], stehen bei der
KQML sogar bis zu 40 verschiedene Sprechakttypen zur Verfügung [vgl. Ferb01, S.
3 Die Knowledge Query and Manipulation Language wurde an der Universität von Maryland innerhalb
des Knowledge Sharing Efforts Projektes entworfen [vgl. Zarn99, S. 152]. 4 Bei der Foundation for Intelligent Physical Agents (FIPA) handelt es sich um eine internationale
Organisation, die 1996 gegründete wurde, mit dem Ziel, die Entwicklung von Agententechnologie durch die Spezifikation von Standards zu fördern. Zu ihren Mitgliedern zählen namhafte Unternehmen wie z. B. France Telecom, IBM, Siemens, Toshiba und Universitäten aus dem IT-Sektor [vgl. FIPA08].
5 Gestaltungspotenziale des agentenbasierten Paradigmas 49
368]. Einen Auszug der verfügbaren Sprechakttypen in einer FIPA-ACL-Nachricht
zeigt die Tabelle 5-2. Performative Beschreibung accept proposal Annahme eines existierenden Angebots agree Zustimmung zu einer vorgeschlagenen Aktion cancel Absage einer schon akzeptierten Aktion cfp (call for proposal) Anforderung eines Angebots confirm Bestätigung einer Aussage (positiv) disconfirm Bestätigung einer Aussage (negativ) failure Fehlerhafte Ausführung einer Aktion inform Benachrichtigung über eine Information propose Erstellung eines Angebot query-if Anfrage ob eine Aussage wahr ist request Aufforderung zu einer Aktion subscribe Interesse an bestimmten Ereignissen anmelden
Tab. 5-2: Beispiele der Performative in FIPA-ACL [vgl. FIPA02b, S. 2]
5.5 Kooperationsformen und -protokolle
Zur Lösung komplexer Aufgaben ist ein einzelner Agent aufgrund von Ressourcenbe-
schränkungen oder Zeitvorgaben meistens nicht in der Lage, so dass solche Aufgaben
oft nur durch das Zusammenwirken von mehreren Agenten gelöst werden können [vgl.
Nwan96]. Unter Kooperation wird die Fähigkeit eines Agenten verstanden, bei der
Lösung eines Problems/einer Aufgabe mit anderen Agenten zusammenzuarbeiten [vgl.
Alba98, S. 3]. In Form von Interaktionsprozessen stimmen die Agenten ihre Aktivitäten
bei der Lösung der Aufgaben aufeinander ab [vgl. AlBu93, S. 55].
Im Zusammenhang mit Multi-Agentensystemen werden unterschiedliche Kooperations-
formen unterschieden. Franklin stellt in seiner Typologie acht unterschiedliche Formen
von Kooperationen gegenüber (siehe Abbildung 5-6) [vgl. DFJN97, S. 2]. Wie in der
Abbildung 5-6 dargestellt, nimmt Franklin auf der obersten Ebene zunächst eine Unter-
scheidung in unabhängige (Independent) und kooperative (Cooperative) Agentensys-
teme vor. „A multi-agent system is independent if each agent pursues its own agenda
[...] independently of the other“ [DFJN97, S. 2]. Unabhängige Agenten agieren somit
alleine bei der Verfolgung ihrer eigenen Ziele. Haben die Ziele der unabhängigen
Agenten außerdem keine Beziehung zueinander, spricht Franklin von diskreten (Dis-
crete) Systemen. Ein Agent in einem diskreten Agentensystem filtert beispielsweise E-
Mails, während ein anderer Agent nach Informationen im Web sucht [vgl. DFJN97, S.
2]. Bei der scheinbaren Kooperation (Emergent Cooperation) wird nach Außen nur der
Eindruck einer Zusammenarbeit hervorgerufen, ohne dass jedoch eine explizite Ko-
5 Gestaltungspotenziale des agentenbasierten Paradigmas 50
operation vorliegt. Diese Form tritt beispielsweise auf, wenn mehrere Agenten das glei-
che Ziel verfolgen und zwar unabhängig voneinander [vgl. BZW98, S. 111].
Negotiating
Non-communicative
Multi-Agent Systems
Communicative
CooperativeIndependent
Deliberative
Emergent Cooperation
Discrete
Abb. 5-6: Kooperationstypologie von Franklin [DFJN97, S. 2]
Im Gegensatz zu den unabhängigen Agentensystemen arbeiten in kooperativen Agen-
tensystemen die Agenten zusammen. Nach Franklin kann dabei die Kooperation ent-
weder kommunikativ (Communicative) oder nicht-kommunikativ (Non-communicative)
erfolgen. Während bei der kommunikativen Kooperation die Agenten direkt über das
Versenden und Empfangen von Nachrichten miteinander agieren, findet bei der nicht-
kommunikativen Kooperation die Zusammenarbeit indirekt über Beobachtung der Um-
welt/des Verhaltens der anderen Agenten und Reaktion auf Umweltänderungen statt
[vgl. DFJN97, S. 2]. Bei den kommunikativen Agentensystemen werden noch delibera-
tive (Deliberative) von verhandlungsorientierten (Negotiating) Formen unterschieden.
Während bei deliberativen Systemen die Agenten ihre Aktivitäten gemeinsam planen
und abstimmen, verfügen verhandlungsorientierte Systeme zusätzlich noch über eine
Wettbewerbskomponente. Durch das Führen von Verhandlungen können somit bei
verhandlungsorientierten Systemen Auseinandersetzungen untereinander geklärt und
Aufgaben vergeben werden [vgl. BZW98, S. 110-111].
Im Gegensatz zu Franklin unterscheiden Albayrak und Bussmann nur zwei Formen der
Kooperation, und zwar die Arbeitsteilung (Task-sharing) und die Ergebnispartizipation
(Result-sharing) [vgl. AlBu93, S. 58-59]. Beim Task-sharing erfolgt die gegenseitige
Unterstützung der Agenten, indem Aufgaben bzw. Teilaufgaben an andere Agenten zur
Bearbeitung abgegeben werden, die über das zur Lösung der Teilaufgabe erforderliche
Wissen verfügen. Die Teilaufgabe kann dabei direkt an einen Agenten übertragen wer-
den, von dem bekannt ist, dass er die Fähigkeiten zur Lösung der Teilaufgabe besitzt. Ist
ein solcher Agent nicht bekannt, werden alle Agenten der Gruppe über die Teilaufgabe
5 Gestaltungspotenziale des agentenbasierten Paradigmas 51
informiert, in der Hoffnung, dass sich mindestens ein Agent findet, die Teilaufgabe zu
lösen [vgl. AlBu93, S. 60].
Falls mehrere Agenten zur Lösung einer Teilaufgabe in Frage kommen, besteht die
Schwierigkeit eine eindeutige Zuordnung der Teilaufgabe zu einem Agenten vorzuneh-
men, der für die Lösung der Teilaufgabe am kompetentesten ist, d. h. den geringsten
Zeit- und Ressoucenaufwand zur Lösung der Teilaufgabe benötigt [vgl. BZW98, S. 94-
95]. In der Literatur wird dieses Zuordnungsproblem unter dem Begriff Connection
Problem beschrieben [vgl. AlBu93, S. 57]. Einen Ansatz zur Lösung des Connection
Problem bietet z. B. das Kooperationsprotokoll Kontraktnetz-Protokoll (Contract Net
Protocol) [vgl. AlBu93, S. 57], auf das weiter unten in diesem Abschnitt eingegangen
wird.
Bei der Kooperationsform Result-sharing erfolgt die gegenseitige Unterstützung der
Agenten, indem bereits ermittelte Teillösungen eines Agenten an die anderen Agenten
der Gruppe weitergereicht werden [vgl. AlBu93, S. 60]. Dieser Austausch von Teiler-
gebnissen kann zum Einen zu einer Arbeitserleichterung der anderen Agenten führen,
zum Anderen können dadurch auch Widersprüche in den Teillösungen oder falsche
Teillösungen rechtzeitig aufgedeckt werden [vgl. BZW98, S. 95]. Voraussetzung für
das Result-sharing ist, dass die Verteilung der Teilaufgaben auf die Agenten zuvor
stattgefunden hat und somit kein Connection Problem mehr vorliegt [vgl. BZW98, S.
95]. Welche der beiden Kooperationsformen Task-sharing oder Result-sharing zum
Einsatz kommt, ist abhängig von dem konkret zu lösenden Problem, möglich sind je-
doch auch Mischformen [vgl. AlBu93, S. 60].
Mittels Kooperationsprotokolle (Interaktionsprotokolle) werden in Multi-Agentensys-
temen die Abläufe bzw. Mechanismen für die Zusammenarbeit zwischen den Agenten
festgelegt. Im Folgenden werden zwei der bekanntesten Verfahrensweisen vorgestellt,
und zwar die Auktion [McMc87] und das Kontraktnetz [Smit80].
„An auction is a market institution with an explicit set of rules determining resource
allocation and prices on the basis of bids from the market participants” [McMc87, S.
701]. Bei einer Auktion handelt es sich somit um einen Koordinationsmechanismus, bei
dem ein Objekt zur Versteigerung angeboten wird und eine Menge von Bietern Gebote
dafür abgeben können. Wie die Gebote abgegeben werden (offen oder verdeckt) und
welchen Preis der Bieter, der die Versteigerung gewonnen hat, zahlen muss, wird durch
den der Auktionsform zugrunde liegenden Mechanismus festgelegt [vgl. RuNo03, S.
5 Gestaltungspotenziale des agentenbasierten Paradigmas 52
782]. Folgende Auktionsformen können unterschieden werden [vgl. McMc87, S. 702-
703]:
• Englische Auktion (English Auction)
Bei dieser Auktionsform erhöht der Auktionator den Preis solange, bis nur noch ein
Bieter den Preis mitbietet. Die Gebote werden offen abgegeben, so dass zu jedem Zeit-
punkt jeder Bieter den aktuell höchsten Preis kennt. Die Auktion ist beendet, wenn es
keine Mitbieter mit einem höheren Gebot gibt. Der zu zahlende Preis entspricht dem
letzten Gebot des Bieters, der die Auktion gewonnen hat.
• Holländische Auktion (Dutch Auction)
Bei der Holländischen Auktion wird ebenfalls offen geboten. Im Gegensatz zur Eng-
lischen Auktion beginnt der Auktionator jedoch mit einem Höchstpreis und reduziert
diesen solange, bis sich ein Bieter meldet, der den aktuellen Preis annimmt.
• Vickery Auktion (Vickery Auction)
Anders als bei den vorherigen beiden Auktionsformen werden bei der Vickery Auktion
die Gebote verdeckt abgegeben. Jeder Bieter kann nur ein verdecktes Gebot machen.
Der Bieter mit dem höchsten Gebot gewinnt die Auktion, bezahlt jedoch nur das zweit-
höchste Gebot.
Bei dem Kontraktnetz-Protokoll handelt es sich um eine Koordinationsmethode zur
Aufgabenverteilung, in der Agenten (in den Rollen Auftraggeber und Auftragnehmer)
Verhandlungen darüber führen, wer die Durchführung einer Aufgabe, d. h. eines Teil-
problems übernimmt [vgl. AlBu93, S. 63-65]. Der Verhandlungsablauf zwischen den
Agenten ist dabei wie folgt definiert [vgl. BZW98, S. 111-116]: Ein Agent in der Rolle
des Auftraggebers (bzw. Managers) schreibt eine Teilaufgabe zur Bearbeitung aus. Die
Ausschreibung wird von den anderen Agenten (den potenziellen Auftragnehmern) ein-
gesehen und daraufhin überprüft, ob ihre zurzeit zur Verfügung stehenden Ressourcen
zur Lösung der Aufgabe ausreichen. Sind genügend Ressourcen vorhanden, so bewer-
ben sich die Agenten um die ausgeschriebene Aufgabe. Der Auftraggeber evaluiert die
eingehenden Bewerbungen, wählt den Agenten mit der höchsten Bewertung aus und
schickt diesem den Kontrakt/Vertrag zu. Der ausgewählte Agent/Auftragnehmer nimmt
den Vertrag an, führt die Problemlösung der Aufgabe durch und übermittelt seine erar-
beiteten Ergebnisse schließlich an den Auftraggeber.
5 Gestaltungspotenziale des agentenbasierten Paradigmas 53
Die Rollen Auftraggeber und Auftragnehmer sind den beteiligten Agenten während des
Verhandlungsablaufs nicht starr zugewiesen. Beispielsweise könnte ein Agent, der zu-
nächst die Rolle des Auftragnehmers innehat, feststellen, dass seine Ressourcen zur
Lösung der zugewiesenen Aufgabe doch nicht ausreichen. Er kann dann die Aufgabe
weiter in Teilaufgaben zerlegen und diese selbst ausschreiben. Der Agent würde somit
gleichzeitig die Rolle des Auftragsnehmers als auch die Rolle des Auftraggebers ein-
nehmen [vgl. Zarn99, S. 90-91].
Genauso wie bei den Kommunikationsprotokollen sind auch bei den Kooperationspro-
tokollen Standards von der FIPA entwickelt worden, z. B. das FIPA Request Interaction
Protocol [FIPA02c], das FIPA Contract Net Interaction Protocol [FIPA02d], das FIPA
English Auction Interaction Protocol [FIPA02e] usw. Je Kooperationsprotokoll-Spezi-
fikation ist dabei die Abfolge der Kommunikationsakte (Performative) festgelegt wor-
den, die während des Nachrichtenaustausches auftreten können [vgl. Eyma03, S. 69].
Ein Beispiel so einer FIPA-Spezifikation ist in der Abbildung 5-7 dargestellt.
Abb. 5-7: FIPA Request Interaction Protocol Specification [FIPA02c, S. 1]
5 Gestaltungspotenziale des agentenbasierten Paradigmas 54
Die Abbildung 5-7 zeigt die Spezifikation des FIPA Request Interaction Protocols. Der
Ablauf des Protokolls ist sehr einfach gestaltet. Er beginnt damit, dass ein Agent (der
Initiator) eine Request-Nachricht an einen anderen Agenten (den Participant) schickt
und ihn damit auffordert, eine bestimmte Aktion durchzuführen. Auf die gestellte An-
frage stehen dem Participant nun zwei Antwortmöglichkeiten zur Verfügung. Mit dem
Versenden einer Refuse-Nachricht, lehnt der Participant die Anfrage ab, während er
mittels einer Agree-Nachricht die Anfrage annimmt. Bei Annahme der Anfrage, führt
der Participant schließlich die Aktion aus. Konnte der Participant die Anfrage erfolg-
reich bearbeiten, so schickt er dem Initiator eine Inform-Nachricht. Im Falle einer fehl-
geschlagenen Bearbeitung erhält der Initiator eine Failure-Nachricht vom Participant
[vgl. FIPA02c, S. 1]. Das FIPA Request Interaction Protocol stellt somit eine einfache
Verfahrensweise zur Verfügung, über die ein Agent einen anderen Agenten zur Ausfüh-
rung einer Aufgabe auffordern kann [vgl. FIPA02c, S. 1].
6 MSS-Assistenz Konzept
6.1 Gesamtkonzept
Zur Unterstützung des Managements bzw. Anwenders bei seiner Arbeit mit den ihm zur
Verfügung stehenden MSS-Werkzeugen ist die Entwicklung eines Assistenzsystems
vorgesehen, das eine inhaltliche und funktionale Unterstützung bietet (siehe Abschnitt
4.2), sowohl MSS-Werkzeug-spezifisch, als auch MSS-Werkzeug-übergreifend. Wäh-
rend sich die Werkzeug-spezifische Unterstützung auf die Hilfe des Anwenders im
Umgang mit den einzelnen Ausprägungen von MSS-Werkzeugen (wie z. B. Cognos
PowerPlay, Cognos ReportNet, Business Objects, MicroStrategy OLAP Services,
Informatica PowerCenter usw.) bezieht, steht bei der Werkzeug-übergreifenden Unter-
stützung die Hilfe bei der richtigen Kombination der einzelnen MSS-Werkzeuge bzw.
deren Funktionen (wie z. B. Suchen, Navigieren, Interpretieren usw.) im Vordergrund.
Obwohl gewisse Abhängigkeiten zu den eingesetzten MSS-Werkzeugen (bezüglich der
MSS-Funktionen) bestehen, soll das MSS-Assistenzsystem als eigenständige Kompo-
nente entwickelt werden, die wechselseitig mit dem Anwender und den MSS-Werkzeu-
gen interagiert. Die Entwicklung als eigenständiges System hat den Vorteil, dass man
sich bei der Umsetzung auf eine Entwicklungsumgebung beschränken kann und sich
nicht die verschiedenen Techniken, die bei den einzelnen MSS-Werkzeugen genutzt
werden, aneignen muss. Außerdem stellt nicht jedes MSS-Werkzeug geeignete Schnitt-
stellen zur Implementierung von benutzerdefinierten Funktionserweiterungen zur
Verfügung oder bietet diese nur gegen zusätzliches Kosten an.
Für das agentenbasierte Konzept des Assistenzsystems stehen grundsätzlich zwei Arten
der Modellierung zur Auswahl. Auf der einen Seite könnte das Assistenzsystem in Form
eines einzelnen Agenten modelliert werden, der das notwendige Wissen und die Funk-
tionen in sich vereinigt. Auf der anderen Seite steht die Möglichkeit der Modellierung
des Assistenzsystems in Gestalt eines Multi-Agentensystems, bei dem das Wissen und
die Funktionen auf mehrere Agenten verteilt implementiert wird (siehe Abschnitt 5.1).
Bei der ersten Variante des Ein-Agent-Systems besteht die Gefahr, dass aufgrund der
Vielzahl an zu unterstützenden Funktionen die Komplexität der Implementierung nicht
mehr überschaubar und handelbar ist und spätere Funktionserweiterungen nur recht
schwer oder gar nicht mehr umzusetzen sind. Für die Lösung mittels eines Multi-Agen-
tensystems spricht, dass bei Funktionsänderungen primär nur die betroffenen Agenten
angepasst werden müssen. Funktionserweiterungen können einfach durch das Hinzufü-
6 MSS-Assistenz Konzept 56
gen eines neuen Agenten erzeugt werden. Aus diesen Gründen wird das agentenbasierte
Konzept der MSS-Assistenz als Multi-Agentensystem modelliert, mit einer hybriden
Architektur (vgl. Abschnitt 5.3).
Um den zuvor gestellten Anforderungen an das Assistenzsystem (siehe Abschnitt 4.3)
gerecht zu werden, eine flexible und erweiterbare Unterstützung zu bieten und eine
maximale Kombinierbarkeit der Assistenzfunktionen zu erreichen, wurde ein primär
funktionsorientiertes Design gewählt, bei dem für jede Unterstützungs-/Assistenzfunk-
tion (wie Interpretation, Navigation usw.) ein Agententyp mit werkzeugspezifischen
Exemplaren konzipiert wird, der stellvertretend für den Anwender die dazugehörigen
Aktionen durchführt. Für das Suchen nach Informationen gibt es z. B. einen Such-
Agenten, während für das Verschicken eines SQL-Statements an eine Datenbank ein
Abfrage-Agent zum Einsatz kommt.
Abbildung 6-1 zeigt das resultierende Konzept der agentenbasierten MSS-Assistenz. Im
rechten Bereich der Abbildung ist die interne Struktur des Multi-Agentensystems, wel-
ches dem MSS-Assistenzsystem zugrunde liegt, vereinfacht dargestellt. Insgesamt
besteht das Agentensystem aus drei Typen von Agenten, einem Graphical User Inter-
face Agenten (kurz: GUI-Agent bzw. Assistant Agent), einem Vermittlungsagenten
(Broker Agent) und einer Vielzahl von so genannten Funktionsagenten (Query Agent,
Search Agent, Help Agent, Interpretation Agent und Navigation Agent), die anbieter-
spezifische Varianten umfassen können und die zusammen den Funktionspool des
Assistenzsystems bilden. Die Kommunikation zwischen den Agenten des MSS-Assis-
tenzsystems erfolgt über den Austausch von Nachrichten (vgl. Abschnitt 5.4).
MSS-
Werkzeug MSS-
Werkzeug
MSS-
Werkzeug
Anwender MSS-
Assistenz- system
interagiert mit
interagiert mit
interagiert mit
BrokerAgent
HelpAgent
InterpretationAgent
NavigationAgent
Query-Agent
SearchAgent
AssistantAgent
MSS- Meta- daten-basis
Abb. 6-1: Agentenbasiertes Konzept der MSS-Assistenz
6 MSS-Assistenz Konzept 57
Damit das agentenbasierte Assistenzsystem dem Anwender eine Unterstützung im Um-
gang mit MSS-Werkzeugen bieten kann, ist es erforderlich, dass die Agenten Wissen
über die zur Verfügung stehenden MSS-Werkzeuge und MSS-Informationen besitzen.
Unter dem Begriff MSS-Informationen werden dabei alle Informationen zusammenge-
fasst, die mit Hilfe eines MSS-Werkzeuges entstehen und darüber zugänglich sind.
Dazu zählen z. B. die Standardberichte eines Berichtsgenerators, die analytischen
Berichte eines OLAP-Werkzeuges, als auch die einzelnen Auswertungsmerkmale bzw.
Kennzahlen dieser Berichte. Die Agenten müssen unter anderem Kenntnisse darüber
haben, welche MSS-Informationen von welchem MSS-Werkzeug bereitgestellt werden,
um welche Informationen im Detail es sich handelt und wie sie die Informationen ab-
rufen können. Auf diese im Folgenden als MSS-Metadaten bezeichneten Informationen
müssen prinzipiell alle Agenten des MSS-Assistenzsystems zugreifen können, da sie
zumeist dieselben MSS-Metadaten zur Lösung ihrer Aufgaben benötigen. Deshalb
werden im agentenbasierten Konzept diese Metadaten nicht je Agent spezifiziert,
sondern als zentrale Serverkomponente in Gestalt einer MSS-Metadatenbasis zur
Verfügung gestellt, die alle MSS-spezifischen Informationen beinhaltet und auf die alle
Agenten des MSS-Assistenzsystems Zugriff haben. Der Metadatenbedarf der Agenten
ist dabei äquivalent zu sehen zu dem Metadatenbedarf, den auch die Benutzer im Data
Warehouse-Bereich benötigen und fordern.
Im Folgenden wird auf die einzelnen Agenten-Typen und die MSS-Metadatenbasis
detaillierter eingegangen und deren Zusammenspiel beschrieben.
6.2 Architekturkomponenten
6.2.1 Assistant Agent
Bei dem Assistant Agent (GUI-Agent) handelt es sich um einen reaktiven Agenten
(siehe Abschnitt 5.3), der die graphische Benutzeroberfläche des MSS-Assistenzsys-
tems, über die der Anwender mit dem System interagiert, zur Verfügung stellt. Neben
der Befragung des Anwenders nach einer Beschreibung seines Problems z. B. in Form
von Stichworten, ist der GUI-Agent ausschließlich für die Präsentation der von den
anderen Agenten erarbeiteten Ergebnisse zuständig. Als weiteren Agenten des Multi-
Agentensystems kennt der GUI-Agent nur den Vermittlungsagenten, mit dem er wäh-
rend der Bearbeitung der Benutzeranfrage in permanenter Interaktion per Nachrichten-
austausch steht. Der GUI-Agent bildet somit die Schnittstelle zwischen dem Anwender
6 MSS-Assistenz Konzept 58
und dem Vermittlungsagenten. Da er nur die Daten zwischen den beiden Parteien trans-
feriert, benötigt er außer Funktionen zur Präsentation der Daten und zum Dialog keine
weiteren Fähigkeiten.
Durch die Konzeption eines GUI-Agenten wird eine strikte Trennung von graphischer
Benutzeroberfläche und der Funktionslogik erreicht. Diese Art der Modellierung mittels
separater Agenten für Benutzeroberfläche und Funktionslogik hat den Vorteil, dass die
Gestaltung der Benutzeroberfläche den Wünschen und Bedürfnissen des Anwenders
angepasst werden kann, ohne dass gleichzeitig Änderungen an der Funktionslogik not-
wendig werden.
6.2.2 Vermittlungsagent
Der Vermittlungsagent (Broker Agent) spielt im agentenbasierten MSS-Assistenz-Kon-
zept eine zentrale Rolle, da er die Schnittstelle zwischen dem GUI-Agent und den Funk-
tionsagenten bildet. Er ist für die Planung und Steuerung der Prozesse zuständig, die bei
der Bearbeitung einer Anfrage eines Anwenders anfallen. Als eine zentrale Komponente
muss der Vermittlungsagent mit sehr viel Wissen (Intelligenz) ausgestattet werden.
Zunächst muss er die Fähigkeit besitzen, die Angaben des Anwenders zu analysieren
und zu interpretieren, um daraus Erkenntnisse über das Problem zu gewinnen. Des
Weiteren muss er fähig sein, Schlussfolgerungen zu ziehen im Hinblick auf mögliche
Lösungswege, d. h. entscheiden, welcher bzw. welche Funktionsagenten zur Erarbei-
tung einer Lösung geeignet sind und in welcher Reihenfolge er diese aktiviert. Die
möglichen Lösungswege werden im agentenbasierten Assistenz-Konzept als Strategien
bezeichnet und sollen praktisch das Verhalten eines erfahrenen realen MSS-Assistenten
repräsentieren. Der Vermittlungsagent stellt die deliberative Komponente der hybriden
Agenten-Architektur dar (siehe Abschnitt 5.3) und ist gemäß der Typologie von Nwana
[Nwan96] der Klasse der Intelligenten Agenten zuzuordnen (siehe Abschnitt 5.2).
Die Modellierung des Vermittlungsagenten erfolgt aus Effektivitätsgründen. Da es nur
eine zentrale Stelle, den Vermittlungsagenten, gibt, von der aus die Prozesse kontrolliert
und gesteuert werden, bleibt die Systeminteraktion überschaubar. Des Weiteren wäre
der Anwender selbst damit überfordert zu entscheiden, welchen speziellen Funktions-
agenten er gerade für sein Problem bzw. für seine Fragestellung aktivieren muss. Insbe-
sondere erfordert eine komplexe Fragestellung meistens den Einsatz von mehreren
unterschiedlichen Funktionsagenten. Der Vermittlungsagent kennt alle Funktionsagen-
6 MSS-Assistenz Konzept 59
ten, so dass er je Problemstellung die Agenten beauftragen kann, die diejenigen Funk-
tionen unterstützen, die zur Lösung der Problemstellung benötigt werden. Er kann auch
(als spätere Erweiterung) die Erfahrungen aus der Bearbeitung ähnlicher Fälle sammeln,
auswerten und verarbeiten, z. B. den Erfolg bestimmter Einsatzreihenfolgen von Funk-
tionsagenten.
6.2.3 Funktionsagenten
Die so genannten Basis-Assistenz-Funktionsagenten (kurz: Funktionsagenten) sind je-
weils für die Lösung einer ganz bestimmten, abgegrenzten Aufgabe zuständig, z. B.
Suchen (Search Agent), Abfragen (Query Agent), Navigieren (Navigation Agent) usw.
Einen Überblick über mögliche Funktionsagenten des MSS-Assistenzsystems zeigt die
Tabelle 6-1. Je Agentenklasse wird eine allgemeine Beschreibung gegeben sowie darauf
eingegangen, welche Assistenzfunktionen abgebildet werden und welches Wissen sie
zur Erfüllung ihrer Aufgaben besitzen müssen.
Name Beschreibung Funktionen Wissen
Query Agent Funktionsagent, der Abfra-gen für einen bestimmten Datenbank-Typ (z. B. MySQL, Oracle, Informix) formulieren kann.
- Analysieren der übergebenen Benutzerangaben
- Spezifizieren einer Abfrage für den jeweiligen Datenbank-Typ
- Ausführen der Abfrage - Weiterleiten der Ergebnisse
- über den Datenbank-Typ - über die Syntax der dazuge-
hörigen Abfragesprache - über die MSS-Metadatenbasis
Search Agent
Funktionsagent, der die Suche nach beliebigen Informationen aus mehreren unterschiedlichen Daten-quellen (z. B. Datenbank, Internet) unterstützt.
- Analysieren der übergebenen Benutzerangaben
- Auswählen geeigneter Daten-quellen zur Suche
- Spezifizieren der Suchparameter- Starten der Suchanfrage - Weiterleiten der Ergebnisse
- über die Auswahlkriterien der Suche
- über die Datenquellen, die durchsucht werden können
- über den Typ von Informa-tionen (Bild, Text, Bericht)
- über die Query Agents - über die MSS-Metadatenbasis
Help Agent Funktionsagent, der Hilfe-stellungen bei Fehlermel-dungen gibt.
- Analysieren der übergebenen Fehlermeldung
- Suchen einer entsprechenden Lösungsalternative
- Weiterleiten der Vorschläge
- über bekannte Fehlermel-dungen des MSS-Werkzeugs
- über Maßnahmen zur Problembehebung
- über die MSS-MetadatenbasisInterpreta-tion Agent
Funktionsagent, der Hilfe-stellungen bei der Interpre-tation von Informationen gibt.
- Analysieren der übergebenen Benutzerangaben
- Ableiten von Zusammenhängen - Weiterleiten der Ergebnisse
- über Zuordnungsregeln - über die MSS-Metadatenbasis
Navigation Agent
Funktionsagent, der für eine beliebige Fragestellung mit einem bestimmten MSS-Werkzeug „interagiert“, indem eine zur Fragestel-lung passende Berichtssicht eingestellt wird.
- Scannen der Einstellungen des MSS-Werkzeugs
- Analysieren der übergebenen Benutzerangaben
- Selektieren und Filtern bestimm-ter Merkmale
- Sortieren und Präsentieren der Informationen
- über das MSS-Werkzeug und die von ihm unterstützten Funktionen
- über Schlussfolgerungsregeln - über den Query Agent - über die MSS-Metadatenbasis
Tab. 6-1: Übersicht über die Funktionsagenten des Assistenzsystems
6 MSS-Assistenz Konzept 60
Im Gegensatz zum Vermittlungsagenten verfügen die Funktionsagenten über weniger
Intelligenz. Sie besitzen nur das spezielle Wissen für ihre Funktion. Eine weitere wich-
tige Eigenschaft, die die Funktionsagenten in diesem Konzept benötigen, ist die Fähig-
keit der Kooperation bei der Problemlösung, z. B. Task-sharing, Result-sharing (vgl.
Abschnitt 5.1 und Abschnitt 5.5). Dies bedeutet, Teilaufgaben eventuell an andere
Agenten, die dafür besser geeignet sind, zu delegieren bzw. ihre Aktionen miteinander
zu kombinieren. Beispielsweise kann ein Such-Agent, der vom Vermittlungsagenten die
Aufgabe erhalten hat, Informationen zu einem bestimmten Sachverhalt zu suchen,
direkt selbst ein oder mehrere Abfrage-Agenten damit beauftragen, den Inhalt der ihnen
zugewiesenen Datenbank ebenfalls danach abzufragen, da nur die Abfrage-Agenten
wissen, wie die notwendigen Abfrage-Statements für ihre Datenbank definiert sein müs-
sen. Ein Hilfs-Agent, der den Auftrag vom Vermittlungsagenten bekommen hat, eine
Problemlösung für eine Fehlermeldung zu erarbeiten, könnte wiederum einen Interpre-
tation-Agent beauftragen, zusätzliche Informationen aus der Fehlermeldung abzuleiten,
die der Hilfs-Agent zur Erstellung der Lösungsbeschreibung benötigt. Als Koopera-
tionsformen kommen dabei sowohl das Task-sharing als auch das Result-sharing zur
Anwendung (vgl. Abschnitt 5.5). Bei den Funktionsagenten handelt es sich um reaktive
Agenten, die gemäß der Typologie von Nwana zu der Klasse der Kooperativen Agenten
zählen (siehe Abschnitt 5.2).
Einen besonderen Typen von Funktionsagent stellt der Navigation-Agent dar. Es han-
delt sich hierbei um einen MSS-Werkzeug-spezifischen Agenten, der über das spezielle
Wissen über die Arbeitsweise und die bereitgestellten Funktionen eines bestimmten
MSS-Werkzeugs verfügt, so dass er in der Lage ist, mit dem bestimmten MSS-Werk-
zeug zu kommunizieren und zu interagieren.
Durch die Art der Modellierung des Assistenzsystems als Multi-Agentensystem, bei
dem jede Assistenzfunktion durch einen Funktionsagenten abgebildet wird, kann das
Spektrum an Assistenzfunktionen relativ einfach erweitert und verfeinert werden. Für
eine neue Assistenzfunktion muss nur ein neuer Agent, der die entsprechenden Funk-
tionalitäten bereitstellt, entwickelt und in den Funktionspool des Assistenzsystems
integriert werden. Zum Beispiel ist bisher in der Modellierung des agentenbasierten
MSS-Assistenz-Konzepts je MSS-Werkzeug nur ein darauf spezialisierter Navigation-
Agent vorgesehen. Da jedoch ein MSS-Werkzeug zumeist mehrere MSS-Funktionen in
sich vereint (vgl. Abschnitt 2.3), wäre es auch denkbar, dass je Funktionsbündel (wie
6 MSS-Assistenz Konzept 61
z. B. filtern und sortieren) eigenständige Agenten entwickelt werden (z. B. als Filter-
Agent, Sort-Agent) und somit ein MSS-Werkzeug gleich von mehreren Funktionsagen-
ten angesprochen werden kann. Die Integration eines neuen Funktionsagenten wird
dabei dadurch vollzogen, dass der Vermittlungsagent und eventuell auch andere Funk-
tionsagenten, die direkt mit dem Agenten kommunizieren sollen, über die Existenz des
neuen Funktionsagenten und dessen Funktionen in Kenntnis gesetzt werden.
6.2.4 MSS-Metadatenbasis
Um eine MSS-spezifische und MSS-übergreifende Unterstützung seitens des agenten-
basierten Assistenzsystems zu gewährleisten, ist im Konzept eine zentrale Metadaten-
basis vorgesehen, die den Agenten MSS-spezifisches Wissen zur Verfügung stellt. In
dieser so genannten MSS-Metadatenbasis werden sowohl Metadaten über die MSS-
Informationen als auch über die MSS-Werkzeuge gespeichert. Einen Überblick über die
möglichen Metadaten, die je MSS-Werkzeug und je MSS-Information in der MSS-
Metadatenbasis vorgehalten werden, zeigt die Tabelle 6-2.
Bei jedem MSS-Werkzeug wird z. B. in der Produktart (vgl. Abschnitt 2.2) festgehalten,
um welche Art von MSS-Werkzeug es sich handelt (z. B. OLAP-Werkzeug oder
Berichtsgenerator). Des Weiteren wird unter dem Befehlsaufruf zum Öffnen der
Anwendungspfad des MSS-Werkzeuges erfasst, bei einem Web-Client z. B. in Form
einer URL. Je MSS-Information werden unter anderem das MSS-Werkzeug, mit dem
die Information erstellt wurde, in der MSS-Metadatenbasis gespeichert sowie der Typ
der MSS-Information. Beispiele für Informationstypen sind OLAP-Würfel, Standard-
Kategorie Metadaten MSS-Werkzeug - Name
- Produktart - Befehlsaufruf zum Öffnen - bereitgestellte Funktionen - Befehl zum Funktionsaufruf - …
MSS-Information - Bezeichnung - Beschreibung - MSS-Werkzeug - Typ - Erstellungsdatum - Ersteller - Befehlsaufruf zum Öffnen - Kontext - …
Tab. 6-2: Übersicht über die MSS-Metadaten
6 MSS-Assistenz Konzept 62
Berichtssicht, Perspektive, strategische Geschäftseinheit, Dimension oder Kennzahl.
Damit für eine konkrete Fragestellung nach passenden MSS-Informationen in der MSS-
Metadatenbasis gesucht werden kann und diese auch (wieder) gefunden werden, besteht
zusätzlich die Notwendigkeit, in strukturierter Form den jeweiligen Kontext von MSS-
Informationen in der MSS-Metadatenbasis vorzuhalten. Unter dem Kontext1 einer
MSS-Information werden in dieser Arbeit all die Informationen zusammengefasst, die
die Bedeutung einer MSS-Information wiedergeben und zum Verständnis und zur kor-
rekten Interpretation der MSS-Information benötigt werden. Nur durch die Beschrei-
bung des Kontextes ist es möglich, gezielt für einen bestimmten Sachverhalt passende
MSS-Informationen aus der Metadatenbasis abzurufen. Bei einem analytischen Bericht
wird der Kontext durch Elemente wie z. B. die aktuell eingestellten Dimensionen,
Kennzahlen und Filter beschrieben. Der Kontext einer spezifischen Balanced Scorecard
kann sich unter anderem aus der gerade selektierten Strategischen Geschäftseinheit und
der gewählten Perspektive zusammensetzen. Wie die beiden Beispiele zeigen, können je
MSS-Werkzeugklasse sowohl die Anzahl an Kontextelementen, als auch die Typen der
Kontextelemente (Dimension vs. Perspektive) unterschiedlich sein. Aber auch innerhalb
einer MSS-Werkzeugklasse kann die Struktur des Kontextes variieren, z. B. indem eine
unterschiedliche Anzahl an Elementen zur Beschreibung des Kontextes verwendet wird.
In einem analytischen Bericht kann zum Beispiel das Kontextelement Filter unbesetzt
sein, so dass der Kontext nur durch die Elemente Dimension und Kennzahl beschrieben
wird. Durch das Setzten eines Filters in einem analytischen Bericht verändert sich die
Datenansicht und entsprechend dazu der Kontext des Berichtes.
Da zum Entwicklungszeitpunkt des Assistenzsystems nicht überschaubar ist, was alles
an Datenstrukturen und Dateninhalten im Datenmodell der MSS-Metadatenbasis abge-
bildet werden muss, ist als Lösungsansatz ein generisches Datenmodell vorgesehen. Das
zu entwickelnde Datenmodell sollte dabei so konzipiert werden, dass es die Unter-
schiede der MSS-Informationen z. B. bezüglich deren Struktur, berücksichtigt. Des
Weiteren muss es möglich sein, dass kontinuierlich neue MSS-Werkzeuge und MSS-
Informationen, die auch andere Typen von Informationen beinhalten, in die MSS-Meta-
datenbasis hinzugefügt werden können, ohne das Änderungen am Datenmodell vorge-
nommen werden müssen. Der Aufbau der MSS-Metadatenbasis und dessen Inhalte
werden im Abschnitt 7.2.2 beschrieben. 1 Der Begriff Kontext stammt vom lateinischen Wort „contextus“ ab und bedeutet im Allgemeinen
„...Zusammenhang im Inhalt e. Schriftstückes; Umgebung e. Schriftstelle, die ihren Sinn deutlich
6 MSS-Assistenz Konzept 63
6.3 Zusammenspiel der Komponenten
Auf Basis der in den vorherigen Abschnitten vorgestellten Architekturkomponenten
sollen in diesem Abschnitt die Abläufe innerhalb des MSS-Assistenzsystems und somit
das vorgesehene, prinzipielle Zusammenspiel der Komponenten mit Hilfe eines abstrak-
ten Anwendungsszenarios beschrieben werden.
Ausgangssituation des Szenarios ist, dass der Anwender Informationen zur Beantwor-
tung einer bestimmten Fragestellung benötigt. Er ruft das MSS-Assistenzsystem auf und
aktiviert damit den GUI-Agenten. Diesem teilt er das Problem mit, indem er beispiels-
weise gewisse Stichwörter angibt oder aus vorgegebenen Elementen bestimmte Optio-
nen auswählt. Der GUI-Agent leitet die erhaltenen Angaben des Anwenders mittels
einer Nachricht an den Vermittlungsagenten weiter. Mit Hilfe der in der MSS-Meta-
datenbasis enthaltenen Metadaten analysiert der Vermittlungsagent die Angaben und
ermittelt zunächst eine Lösungsstrategie (vgl. Abschnitt 6.2.2). Diese gibt ihm vor,
welche Funktionen durchgeführt werden müssen, d. h. welche Funktionsagenten er in
welcher Reihenfolge beauftragen muss, um einen bestimmten Dienst/eine bestimmte
Funktion auszuführen. Der Vermittlungsagent benachrichtigt dann den oder die
Agenten aus dem Funktionspool des MSS-Assistenzsystems, die gemäß der Strategie
gerade in Frage kommen. Er teilt den entsprechenden Funktionsagenten die vom
Anwender erhaltenen Angaben zum Problem mit, stellt eventuell den Kontakt zwischen
den Agenten her und stößt die Aktionen der Agenten an. Mit den Informationen des
Anwenders versuchen die Funktionsagenten, eine Lösung zu erarbeiten und teilen ihre
Ergebnisse dem Vermittlungsagenten mit. Dieser reicht zum Schluss die erarbeiteten
Ergebnisse an den GUI-Agenten weiter, der die Ergebnisse aufbereitet und dem
Anwender auf dem Bildschirm präsentiert.
Eine mögliche Lösungsstrategie des Vermittlungsagenten könnte zum Beispiel vor-
sehen, dass nach einer Analyse der Benutzerangaben nach bestimmten Merkmalen wie
Dimensionen, Kennzahlen, usw. der Such-Agent (Search Agent) beauftragt wird, nach
schon existierenden Standard- oder analytischen Berichten mit gleichen bzw. ähnlichen
Merkmalen/Inhalten zu suchen. Mit den vom Vermittlungsagenten erhaltenen Such-
kriterien (-informationen) richtet sich der Such-Agent dann beispielsweise an die
Abfrage-Agenten (Query Agent). Diese spezifizieren aus den vom Such-Agenten über-
mittelten Informationen eine für ihre Datenquelle entsprechende Abfrage und starten
diese. Falls passende Informationen zur Suchanfrage gefunden werden, übermitteln die
macht...“ [vgl. Kien82, S. 229].
6 MSS-Assistenz Konzept 64
Abfrage-Agenten diese dem Such-Agenten, der die Ergebnisse sammelt und schließlich
an den Vermittlungsagenten weiterreicht. War die Suche in den Datenquellen erfolglos,
d. h. es wurden keine zutreffenden Informationen (keine passenden Berichte) gefunden
bzw. die verfolgte Strategie führte zu keinen Ergebnissen, so ermittelt der Vermitt-
lungsagent eine neue Strategie oder wählt die nächste Strategie in einer Prioritätenliste
aus. Eine neue Strategie könnte im ersten Schritt den Navigation-Agenten (Navigation
Agent) für das gerade verwendete MSS-Werkzeug vorsehen, der den Auftrag erhält,
eine für die Fragestellung passende Berichtssicht zu bauen. Dazu analysiert der Naviga-
tion-Agent auf Basis der Metadaten in der MSS-Metadatenbasis die vom Vermittlungs-
agenten erhaltenen Benutzerangaben im Hinblick auf die Einordnung als Dimension,
Kennzahl oder Filterattribut. Mit diesen Kenntnissen und dem Wissen über die Funk-
tionalität des MSS-Werkzeugs ist der Navigation-Agent schließlich in der Lage, eine
Berichtssicht zu erstellen. Über seine Auswahl- und Filterfunktionen stellt er die Be-
richtssicht gemäß den Informationen ein und leitet das Ergebnis über den Vermittlungs-
agenten an den GUI-Agenten weiter, der dem Anwender die gebaute Berichtssicht
präsentiert.
Bevor im Kapitel 8 der entwickelte Prototyp beschrieben wird, werden im folgenden
Kapitel 7 zunächst die zugrunde liegenden Konzepte und Funktionalitäten der Techno-
logien kurz vorgestellt, die bei der Implementierung des Prototyps eingesetzt wurden.
TEIL III
PROTOTYPISCHE REALISIERUNG
EINER AGENTENBASIERTEN
MSS-ASSISTENZ
7 Entwicklungs- und Domänenumgebung des Prototyps
7.1 Entwicklungsumgebungen des Prototyps
7.1.1 Java Agent Development Framework
Für die Entwicklung des Multi-Agentensystems zur MSS-Assistenz wurde das Java
Agent Development Framework (JADE)1 [vgl. JADE08; JADE07a; JADE07b; BCG07]
in der Version 3.6 (05.05.2008) verwendet. Zusätzlich zu einer Agentenplattform (d. h.
der physischen Infrastruktur/Laufzeitumgebung für Agenten), die einen umfangreichen
Satz an FIPA-konformen Systemdiensten (wie z. B. white page service, yellow page
service und message transport service) und Agenten (wie z. B. Agent Management
System (AMS) Agent und Directory Facilitator (DF) Agent) zur Verfügung stellt [vgl.
FIPA04], bietet JADE bei der Entwicklung eine Vielzahl von Werkzeugen zur Unter-
stützung der Debugging- und Entwicklungsphase (Introspector Agent, Dummy Agent,
Sniffer Agent, Log Manager Agent) an, sowie eine Benutzeroberfläche zur Fernwartung
der Konfiguration (Remote Monitoring Agent (RMA)) [vgl. JADE08; JADE07a, S. 5;
JADE07b, S. 27-36; BCG07, S. 42-47].
Jeder Agent in JADE basiert auf einer vom Programmierer definierten Java-Klasse, die
Unterklasse der JADE Klasse Agent im Paket jade.core ist [vgl. JADE07a, S. 10]. Von
der Klasse Agent werden einige grundlegende Eigenschaften und Methoden bereitge-
stellt (vererbt), die sowohl die Interaktionen mit der Agentenplattform, als auch die
Implementierung und Ausführung des Agentenverhaltens über alle Phasen des Agenten-
lebenszyklus hinweg unterstützen [vgl. JADE07a, S. 10]. Gemäß dem FIPA Standard
Agent Management Specification (SC00023K, [FIPA04]) kann ein Agent sich innerhalb
seines Lebenszyklus in verschiedenen Zuständen wie z. B. initialisiert, aktiv, wartend
usw. befinden [vgl. FIPA04; siehe Anhang A-1]. Die möglichen Zustände, die ein
Agent einnehmen kann, sind bei JADE in der Klasse Agent mittels Konstanten definiert
worden.
Eine spezielle Unterklasse der Klasse Agent, die die JADE-Entwicklungsumgebung
zusätzlich zur Verfügung stellt, ist die Klasse GuiAgent [vgl. JADE07a, S. 17]. Sie ist
im Paket jade.gui enthalten und bietet dem Programmierer die Möglichkeit, die JADE-
1 JADE wird von der Telecom Italia Lab (TILAB) entwickelt und als Open Source Software unter den
Bedingungen der Lesser General Public License (LGPL Version 2) vertrieben [vgl. JADE08].
7 Entwicklungs- und Domänenumgebung des Prototyps 67
Agenten mit graphischen Benutzeroberflächenelementen auszustatten und interagieren
zu lassen [vgl. JADE07a, S. 17].
Zur Modellierung des Agentenverhaltens benutzt JADE das Konzept der Behaviours
[vgl. JADE07a, S. 24-30; BCG07, S. 57-61]. Behaviours sind logische Einheiten von
Aktionen (Aktivitätseinheiten), die auf unterschiedliche Weise kombiniert werden
können, um komplexe Ausführungsmuster zu erhalten. JADE stellt standardmäßig eine
Menge von Behaviour-Klassen wie z. B. SimpleBehaviour, CyclicBehaviour, Com-
positeBehaviour und FSMBehaviour in dem Paket jade.core.behaviours zur Verfügung
(siehe Anhang A-2), die beliebig kombiniert und auch erweitert werden können [vgl.
JADE07a, S. 26-27; BCG07, S. 91-100]. Für die Modellierung eines einfachen Verhal-
tens, d. h. bei dem der JADE-Agent nur eine einzelne Aufgabe ausführen soll, kann die
Klasse SimpleBehaviour verwendet werden. Das einfache Verhalten kann wiederum auf
zwei Arten spezialisiert werden. Während bei der Unterklasse OneShotBehaviour die
Aufgabe nur einmal ausgeführt wird, kommt bei der Unterklasse CyclicBehaviour das
Verhalten wiederholt zum Einsatz, die Ausführung wird somit nie beendet [vgl.
JADE07a, S. 28; BCG07, S. 59-60]. Die Abbildung eines komplexen Agentenverhal-
tens, d. h. einer Aufgabe, die sich aus mehreren anderen Aufgaben zusammensetzt, die
z. B. parallel oder sequentiell ausgeführt werden, ist mittels der Klasse CompositeBeha-
viour und deren Unterklassen möglich. Mit der Unterklasse FSMBehaviour kann bei-
spielsweise eine komplexe Aufgabe so modelliert werden, dass die Unteraufgaben den
Aktivitäten entsprechen, die von einem endlichen Zustandsautomaten2 (engl. finite state
machine, FSM) verrichtet werden [vgl. JADE07a, S. 27; BCG07, S. 93-95].
Alle Behaviours werden von dem JADE Laufzeitsystem ausgeführt, so dass der Pro-
grammierer nur dafür verantwortlich ist, das Verhalten zu spezifizieren. Jeder Agent
kann ein oder mehrere Behaviours besitzen. Mittels eines Schedulers, der das round-
robin non-preemptiv Verfahren3 anwendet [vgl. JADE07a, S. 25], werden die Behavi-
ours kooperativ geplant und ausgeführt.
2 Ein Zustandsautomat entspricht einem Verhaltensmodell, welches durch Zustände, Transitionen (Zu-
standsübergänge) und Aktionen beschrieben wird. Ausgehend von einem Anfangszustand werden durch das Eintreten unterschiedlicher Ereignisse Zustandswechsel hervorgerufen, die zur Ausführung von Aktionen führen. Der gesamte Vorgang ist beendet, wenn ein Endzustand erreicht wurde [vgl. Balz99, S. 78-83].
3 Bei dem round-robin non-preemptiv Verfahren handelt es sich um einen Scheduling Mechanismus, bei dem die Prozesse „reihum“ zur Ausführung kommen, also jeder Thread dieselbe Priorität hat und bei dem laufende Prozesse nicht unterbrochen werden können, damit die CPU einem anderen Prozess zu-geteilt werden kann [vgl. Tane95, S. 80-81].
7 Entwicklungs- und Domänenumgebung des Prototyps 68
Die Agentenkommunikation erfolgt bei JADE durch Nachrichtenaustausch (message
passing) (siehe Abschnitt 5.4). Als Sprache, in der die Nachrichten definiert werden und
über die die Agenten ihr „Wissen“ austauschen, wird die FIPA Agent Communication
Language (ACL) (SC00061G, [FIPA02a]) verwendet. Jeder Agent verwaltet selbst
seine private Queue/Inbox von ACL-Nachrichten, in der die Laufzeitumgebung JADE
nur die eingehenden Nachrichten einfügt, ohne den Agentencode aufzurufen [vgl.
BCG07, S. 65-67]. Für den Zugriff auf die eigene Nachrichten-Inbox bzw. auf eine
einzelne Nachricht stehen dem Agenten in JADE verschiedene Methoden wie z. B.
pattern matching, polling-based usw. zur Verfügung [vgl. Bell01, S. 12].
Die allgemeine interne Architektur eines JADE-Agenten setzt sich wie in der Abbildung
7-1 dargestellt zusammen. Während der grau hinterlegte Bereich den anwendungs-
abhängigen Teil der Architektur wiedergibt, handelt es sich bei dem Rest um die grund-
legenden Komponenten, die jeder Agent aufweist. Der anwendungs-spezifische Teil
umfasst die Fähigkeiten und Überzeugungen der Agenten, die je Anwendungsdomäne
variieren. Zur Unterstützung der anwendungs-abhängigen Implementierung stellt JADE
eine umfangreiche Bibliothek von Interaktionsprotokollen und Behaviour-Klassen zur
Verfügung, die der Programmierer nur noch gemäß seinen Anforderungen anpassen
muss. Zu den festen Bestandteilen der Architektur zählen die bereits oben beschrie-
benen Komponenten: die Nachrichten-Queue, die Behaviour-Queue und der Behaviour
Scheduler. Für die Verwaltung des Agentenlebenszyklus gibt es standardmäßig den
Lebenszyklus-Manager. Dieser beobachtet und kontrolliert die verschiedenen Zustände
des Agenten [vgl. Bell01, S. 11-12].
Die Entscheidung für die Entwicklungsumgebung JADE wurde aufgrund ihrer umfang-
reichen Klassenbibliotheken zur Agentenverwaltung und -Kommunikation als auch
wegen ihrer fortlaufenden Konformität zu den FIPA-Spezifikationen getroffen. Durch
die Verwendung eines FIPA kompatiblen Frameworks wie JADE braucht der Pro-
grammierer sich keine Gedanken mehr über die Kommunikation und Infrastruktur des
Agentensystems machen, sondern kann sich vollständig auf die anwendungsorientierten
Aspekte der Implementierung konzentrieren.
7 Entwicklungs- und Domänenumgebung des Prototyps 69
private inbox ofACL messages
scheduler ofbehaviours
patte
rn m
atch
ing
life-cyclemanager
applicationdependent
agent resources
beliefs
capabi-lities
beha
viou
r 1
beha
viou
r 2
beha
viou
r n
…
activeagent behaviours(i.e. agent intentions
or agent tasks)
acce
ss m
ode
timeo
ut-b
ased
bloc
king
-bas
ed
patte
rn m
atch
ing
polli
ng-b
ased
JADE library ofinteraction protocolsand of generic agent behaviours
Abb. 7-1: Allgemeine interne Architektur eines JADE-Agenten [vgl. Bell01, S. 12]
7.1.2 Java Expert System Shell
Bei der Java Expert System Shell (JESS)4 handelt es sich um eine regelbasierte System-
Shell (rule engine) und Skript-Sprache, die in Java geschrieben wurde und die Ent-
wicklung von regelbasierten Expertensystemen ermöglicht [vgl. Frie05]. „A rule-based
system is a system that uses rules to derive conclusions from premises“ [Frie03, S. 17].
Mit JESS sollen die Agenten des MSS-Assistenzsystems um die Fähigkeit, eigenständig
Schlussfolgerungen zu ziehen, ergänzt werden. Das Agentenwissen hätte auch mittels
einer anderen Technik wie z. B. dem Fallbasierten Schließen (Case Based Reasoning
CBR) modelliert werden können. Die Entscheidung für einen regelbasierten Ansatz zur
Modellierung des Agentenwissens wurde getroffen aufgrund der explizit(er)en Formu-
lierbarkeit und der leichteren Erweiterbarkeit des Agentenwissens, durch das einfache
Hinzufügen von neuen Fakten und Regeln. Für die Implementierung des MSS-Assis-
tenzsystems wurde JESS in der Version 6.1p4 (07.08.2003)5 verwendet.
4 JESS wurde von Ernest Friedman-Hill an den Sandia National Laboratories in Kalifornien entwickelt
[vgl. JESS08]. Die Entwicklung von JESS orientierte sich an der CLIPS-(C Language Integrated Production System) Expertensystem-Shell [vgl. Rile08], weshalb die JESS-Syntax der Skriptsprache LISP (List Processing) [vgl. Grah93, S. 44; Kurb92, S. 114ff] ähnelt [vgl. Frie03, S. 32].
5 Aktuell ist JESS in der Version 7.1p1 verfügbar. Während für den kommerziellen Einsatz eine Lizenz erforderlich ist, ist die wissenschaftliche Nutzung kostenlos [vgl. JESS08].
7 Entwicklungs- und Domänenumgebung des Prototyps 70
Im Folgenden werden die wesentlichen Konzepte von JESS, die im Rahmen dieser Ar-
beit von Bedeutung sind, kurz vorgestellt. Als eine Entwicklungsumgebung für regelba-
sierte Systeme stellen die Kernbestandteile von JESS Fakten und Regeln dar.
Fakten werden als Listen modelliert, die eine beliebige Anzahl an Merkmalseinträgen
(slots) beinhalten können. Insgesamt existieren in JESS drei Typen von Fakten, und
zwar ordered facts, unordered facts und shadow facts, die sich hinsichtlich ihrer Struk-
tur und Verwendung unterscheiden. Während ordered facts einfache Listen darstellen,
denen keine benannte Struktur zugrunde liegt (z. B. (person "Jens Müller" 29 175 70),
wird die Struktur von unordered facts durch die Benennung der Merkmalseinträge fest-
gelegt und beschrieben (z. B. (person (name "Jens Müller") (alter 29) (groesse 175)
(gewicht 70)). Im Gegensatz zu den ordered facts ist es so möglich, die Merkmale die-
ser Fakten in einer beliebigen Reihenfolge anzuordnen [vgl. Frie03, S. 81]. Um mit
unordered facts zu arbeiten, muss zuvor deren Struktur mittels des JESS-Konstrukts
deftemplate definiert werden (z. B. (deftemplate person (slot name) (slot alter) (slot
groesse) (slot gewicht))) [vgl. Frie03, S. 82]. Bei shadow facts handelt es sich um eine
spezielle Form von unordered facts, die (insbesondere) dazu verwendet werden, eine
Verbindung zwischen der JESS-Umgebung und der Java-Anwendung, die JESS be-
nutzt, herzustellen [vgl. Frie03, S. 87-88]. Die Fakten werden mit dem JESS-Befehl
assert einzeln in die Faktenbasis übernommen [vgl. Frie03, S. 76]. Um eine Faktenbasis
anfänglich mit einer größeren Menge an Fakten zu befüllen (z. B. mit Produktdaten ei-
nes Produktkatalogs), gibt es in JESS zusätzlich noch das Konstrukt deffacts. Mit def-
facts wird die Liste mit den initialen Fakten definiert, die dann beim Aufruf des reset-
Befehls, durch den die Faktenbasis initialisiert wird, auf einmal in die Faktenbasis hin-
zugefügt werden [vgl. Frie03, S. 80].
Regeln werden in JESS mit dem Ausdruck defrule angelegt [vgl. Frie03, S. 96]. Ihre
prinzipielle Struktur ähnelt der eines IF-THEN-Konstrukts. Der IF-Teil (LHS: left-hand
side) einer Regel beinhaltet dabei eine oder mehrere Bedingungen bzw. Prämissen, die
erfüllt sein müssen, damit die Regel zur Ausführung kommt. Der THEN-Teil (RHS:
right-hand side) dagegen setzt sich aus einer oder mehreren Funktionsaufrufen zusam-
men, den Aktionen bzw. Schlussfolgerungen, die bei Erfüllung der Bedingungen ausge-
führt werden [vgl. Frie03, S. 17]. Zur Trennung des IF-Teils vom THEN-Teil wird in
JESS in der Regeldefinition das Symbol „=>“ verwendet [vgl. Frie03, S. 97].
7 Entwicklungs- und Domänenumgebung des Prototyps 71
Neben der Definition von Fakten und Regeln besteht in JESS die Möglichkeit, über das
Konstrukt defquery Abfragen zu implementieren, mit denen die Faktenbasis nach Fak-
ten, die bestimmte Kriterien erfüllen, durchsucht werden kann [vgl. Frie03, S. 128-129].
Durch Spezifikation von Übergabeparametern sind diese Abfragen sehr flexibel gestalt-
bar.
Mit dem Konstrukt deffunction ist es in JESS möglich, eigene benutzerdefinierte Funk-
tionen zu definieren. Jede Funktion besteht aus einem Namen, über den der Funktions-
aufruf erfolgt, optionalen Übergabeparametern, einem oder mehreren Ausdrücken (wie
z. B. IF-THEN-Konstrukten und/oder anderen Funktionsaufrufen) und einem Rück-
gabewert, der entweder explizit durch den Befehl return eingeführt wird oder implizit
das Auswertungsergebnis des letzten Ausdrucks in der Funktion darstellt [vgl. Frie03,
S. 56]. Die Definition von Funktionen macht z. B. Sinn für bestimmte Aktionen und Be-
rechnungen, die häufiger bzw. in unterschiedlichen Regeln benötigt werden [vgl.
Frie03, S. 55] oder um generell den Programmcode übersichtlicher zu gestalten durch
die Modularisierung des Codes. Einige weitere wichtige Systembefehle von JESS sind
in der Tabelle 7-1 wiedergegeben.
Systembefehl von JESS Beschreibung des Befehls assert Fügt einen Faktwert in die Faktenbasis hinzu run Startet die Regelauswertung (JESS-Engine) bind Variablenzuweisung store Speichert das/die Ergebnis/se in einer Variablen declare Variablendeklaration fetch Ruft einen Faktwert, der in einer Variable gespeichert wurde, ab retract Entfernt einen Faktwert aus der Faktenbasis
Tab. 7-1: Systembefehle von JESS
Zur Regelauswertung verwendet JESS den Rete-Algorithmus6. Die Inferenz erfolgt in
JESS grundsätzlich vorwärts, d. h. es werden für vorgegebene (asserted) und daraus
abgeleitete Fakten alle ausführbaren Regeln ermittelt und ausgeführt, bis ein vorgege-
benes Ziel (Fragestellung) erreicht oder keine Regel mehr ausführbar ist. Eine Rück-
wärtsverkettung, bei der umgekehrt geprüft wird, ob ein vorgegebenes Ziel mit den
vorhandenen Fakten erschlossen werden kann, ist auch möglich, wird aber innerhalb des
Rete-Algorithmus durch eine Vorwärtsverkettung simuliert [vgl. Frie03, S. 117].
6 Rete (rete lat. Netz) bildet das Kernstück von JESS [vgl. Frie03, S. 136-139] und ist ein Mechanismus,
um hochkomplexe „N:M“-Vergleichsprobleme, die zwangsläufig bei der Regelauswertung entstehen, zu lösen [vgl. Forg82, S. 17-37].
7 Entwicklungs- und Domänenumgebung des Prototyps 72
Die Architektur von JESS gleicht dem Aufbau typischer regelbasierter Systeme. Wie in
der Abbildung 7-2 dargestellt, besteht die Architektur aus den Komponenten Regel-
Interpreter (Inference Engine), Arbeitsspeicher (Working Memory), Regelbasis (Rule
Base) und Laufzeitsystem (Execution Engine) [vgl. Frie03, S. 20]. Während in der
Working Memory die Fakten gesammelt werden, werden in der Rule Base die Regeln
gespeichert. Die Inference Engine setzt sich aus dem Pattern Matcher und der Agenda
zusammen. Der Pattern Matcher vergleicht (IF-Teile) alle(r) Regeln mit den Inhalten
der Working Memory und entscheidet welche der Regeln zur Ausführung kommen. Die
ausführbaren Regeln werden in der Agenda aufgelistet. Diese ist dafür verantwortlich,
festzulegen, in welcher Reihenfolge die Regeln ausgeführt werden. Für die eigentliche
Ausführung der Regeln ist schließlich die Execution Engine zuständig.
Inference-Engine
Execution Engine
(f1, f2) r1
Pattern Matcher
(f1, f2) r1 (f2, f3) r2
Agenda
(fact f1 (fact f2 (fact f3) Working Memory
) )
(rule (rule (rule
Rule Base
r3) r1) r2)
Abb. 7-2: Aufbau eines typischen regelbasierten Systems [vgl. Frie03, S. 20]
Da JESS in Java programmiert ist, ist es möglich, JESS-Funktionen auch in anderen
Java-Anwendungen einzubinden und sie damit um Schlussfolgerungsfunktionalitäten zu
erweitern. Dazu muss einfach in der Java-Anwendung eine Instanz der JESS-Klasse
Rete erzeugt werden. Jede Rete-Instanz stellt eine eigene JESS-Engine dar und bildet
die zentrale Zugriffsstelle für die Nutzung der JESS-Funktionalitäten [vgl. Frie03, S.
307].
Für eine Integration in die JADE-basierten Agentenstrukturen des MSS-Assistenzsys-
tems ist JESS sehr gut geeignet, da JESS genauso wie JADE vollständig in Java imple-
mentiert ist, so dass kein Systembruch und somit keine Kompatibilitätsprobleme zwi-
schen den beiden Technologien existieren.
7 Entwicklungs- und Domänenumgebung des Prototyps 73
7.2 MSS-Domänenumgebung
7.2.1 Cognos ReportNet / Cognos PowerPlay
Unter dem Begriff MSS-Domänenumgebung wird in dieser Arbeit die anwendungsspe-
zifische Ausgestaltung des agentenbasierten Assistenzsystems zusammengefasst. Ge-
staltungsspielräume liegen hier sowohl in der Auswahl der MSS-Werkzeuge, für die das
Assistenzsystem dem Anwender eine Unterstützung bieten soll, als auch im Aufbau der
MSS-Metadatenbasis (siehe Abschnitt 6.2.4) vor. In diesem Abschnitt werden die MSS-
Werkzeuge beschrieben, für die das Assistenzsystem konfiguriert ist. Auf das MSS-
Metadatenmodell, welches der MSS-Metadatenbasis zugrunde liegt, wird im Abschnitt
7.2.2 detaillierter eingegangen. Woher und wie die MSS-Metadaten für die MSS-Meta-
datenbasis gewonnen werden können, ist Gegenstand des Abschnitts 7.2.3.
Zur Veranschaulichung der potenziellen MSS-übergreifenden Unterstützungsleistung
durch das agentenbasierte MSS-Assistenzsystem wurden aus dem an der Universität
Osnabrück vorliegenden Spektrum an MSS-Werkzeugen (siehe Abschnitt 3.2) das Stan-
dardberichts-Werkzeug Cognos ReportNet und das OLAP-Werkzeug Cognos Power-
Play, die beide von der Firma Cognos (seit 2008 zu IBM gehörend) [vgl. Cogn08]. ver-
trieben werden, ausgewählt. Die Entscheidung für Cognos PowerPlay wurde getroffen,
da es ein MSS-Werkzeug repräsentiert, welches aufgrund seiner Informations- und
Funktionsvielfalt sehr hohe Anforderungen an die Anwender im Umgang stellt (siehe
Abschnitt 4.1) und daher am dringendsten eine Unterstützung erfordert. Cognos
ReportNet gehört einer anderen Produktart als Cognos PowerPlay an, so dass durch die
Auswahl auch der MSS-Werkzeug-übergreifende Unterstützungsaspekt berücksichtigt
werden kann. Je Werkzeug werden im Folgenden die zugrunde liegende Architektur
und die enthaltenen Konzepte beschrieben, um darzustellen, wo Informationen entste-
hen, die für das MSS-Assistenzsystem und die MSS-Metadatenbasis relevant sind, um
welche Informationen es sich dabei handelt und welche Möglichkeiten die MSS-Werk-
zeuge bieten, diese Informationen abzurufen.
Cognos ReportNet ist ein webbasiertes Werkzeug zur Administration und Verwaltung
von Standardberichten, das auf einer Multi-Tier-Architektur basiert (siehe Abbildung 7-
3). Die erste Schicht bildet der Web-Server, auf dem das Cognos Gateway installiert ist
[vgl. Cogn06a, S. 16]. Dieser leitet alle eingehenden Anfragen an die zweite Schicht,
den Cognos ReportNet Server, weiter, der die nachgefragten Berichte und Abfragen
ausführt. Der ReportNet Server umfasst zwei Komponenten und zwar den Dispatcher
7 Entwicklungs- und Domänenumgebung des Prototyps 74
und den Content Manager [vgl. Cogn06a, S. 17]. Während der Dispatcher für die Ver-
waltung und die Ausführung der verschiedenen Dienste wie z. B. Präsentationsdienst,
Berichtsdienst, Protokolldienst usw. zuständig ist, besteht die Aufgabe des Content
Manager darin, alle ReportNet-Informationen wie z. B. Serverkonfigurationsinforma-
tionen, Modellinformationen, Berichtsspezifikationen, Berichtsausgaben usw. zu ver-
walten und zu speichern [vgl. Cogn06a, S. 18-20]. Die ReportNet-Informationen wer-
den vom Content Manager in einer Content Store Datenbank, die auf der dritten Schicht
der Architektur angesiedelt ist, gespeichert [vgl. Cogn06a, S. 19]. Es handelt sich hier-
bei um eine relationale Datenbank, in der alle Informationen vorgehalten werden, die
Cognos ReportNet zur Ausführung benötigt. Die meisten dieser Informationen wie z. B.
die Berichtsspezifikationen und die Verbindungsinformationen zu Datenquellen liegen
im XML-Format vor und werden im Content Store als Binary Large Objects (BLOBs)7
abgelegt [vgl. Cogn06a, S. 21].
Tier 1: Web server
Tier 2: Application
Tier 3: Data
Cognos user interfaces
Content store Query databases
Web server
ReportNet server
JDBC
Cognos Gateway
API
Framework Manager
Windows
Cognos Connection
Cognos Report Studio
Query Studio
Web browser
Dispatcher Content Manager
firewall
firewall
firewall
Abb. 7-3: Cognos ReportNet-Architektur [vgl. Cogn06a, S. 13]
Für den Benutzer stellt Cognos ReportNet verschiedene web- und windows-basierte
Client-Komponenten zur Verfügung. Query Studio ist ein web-basierter Berichtsgene-
rator, mit dem einfach und schnell ad-hoc-Berichte erstellt werden können [vgl.
7 Bei Binary Large Object (BLOB) handelt es sich um einen Datentyp, „der als eine beliebige Folge von
Binärwerten [...] definiert ist [HHR04, S. 130]. Er wird vor allem bei komplexen und unstrukturierten Daten (wie z. B. technischen Zeichnungen, Bilddaten) eingesetzt [vgl. HHR04, S. 130].
7 Entwicklungs- und Domänenumgebung des Prototyps 75
Cogn06a, S. 15]. Zum Erstellen von komplexen Berichten ist der web-basierte Berichts-
generator Report Studio vorgesehen. Mit diesem Werkzeug kann der Benutzer unter-
schiedliche Typen von Berichten spezifizieren wie z. B. Listenberichte, Kreuztabellen-
berichte und graphenbasierte Berichte [vgl. Cogn06b, S. 43], die wiederum in unter-
schiedlichen Ausgabeversionen wie z. B. HTML, PDF, CSV usw. präsentiert werden
können [vgl. Cogn06b, S. 35]. Die Erzeugung eines Berichtes mit Report Studio ent-
spricht dabei der Definition einer Berichtsspezifikation. In einer Berichtsspezifikation
werden sowohl die Abfragen definiert, mit denen die Daten aus den Datenquellen abge-
rufen werden und die Datenelemente bestimmt, die im Bericht enthalten sein sollen, als
auch das Format und das Layout festgelegt, in dem die Daten im Bericht dargestellt
werden sollen [vgl. Cogn06b, S. 29]. Durch die Definition von Filtern in Report Studio
können die Informationen im Bericht zusätzlich auf bestimmte Daten eingeschränkt
werden, wie z. B. ein bestimmtes Geschäftsjahr und/oder eine bestimmte Finanzstelle.
Im Gegensatz zu dieser statischen und starren Variante der Festlegung von Filterkrite-
rien bietet Report Studio mittels der Definition von Eingabeaufforderungen auch die
Möglichkeit, dynamisch und flexibel Filterkriterien zu selektieren und zu setzen. Für
jedes Eingabeaufforderungselement in der Berichtsspezifikation wird gleichzeitig ein
Parameter erzeugt, der als Platzhalter für das später vom Benutzer selektierte Merkmal
steht und die Daten entsprechend filtert. Bei jedem Aufruf eines Berichtes mit in-
tegrierter Eingabeaufforderung kann der Benutzer so jedes Mal von Neuem die
Informationen des Berichtes interaktiv auf seine Bedürfnisse einstellen bzw. einschrän-
ken [vgl. Cogn06b, S. 117ff].
Die Datengrundlage für die Berichte, die mit Report Studio generiert werden können,
wird mittels des Windows-Client Framework Manager definiert. Es handelt sich hierbei
um ein Modellierungs-Werkzeug, mit dem Metadatenmodelle erstellt werden können
[vgl. Cogn06c, S. 13]. In einem Modell werden dabei die Quelltabellen und Datenele-
mente, die die relevanten unternehmensspezifischen Informationen für die Berichte ent-
halten, und die zwischen diesen bestehenden Beziehungen festgelegt. Zum Einen kön-
nen diese Metadaten aus den zugrunde liegenden Datenquellen importiert werden. Zum
Anderen hat der Benutzer aber auch die Möglichkeit, dort neue Datenelemente und
Beziehungen zu erzeugen. Damit der Benutzer auf der Basis des Metamodells Berichte
erstellen kann, muss das Modell als so genanntes Package auf dem ReportNet Server
veröffentlicht (publish) werden [vgl. Cogn06c, S. 209-210]. Erst durch die Veröffent-
lichung werden die Metadaten in den Cognos Content Store geschrieben und damit zu-
7 Entwicklungs- und Domänenumgebung des Prototyps 76
gänglich für die anderen Client-Komponenten wie z. B. Report Studio. Im Framework
Manager werden die Modelldaten selbst auf dem lokalen Rechner im XML-Format ge-
speichert.
Der Zugriff auf die Berichte erfolgt über Cognos Connection, dem zugehörigen Web-
Portal von Cognos ReportNet [vgl. Cogn06d, S. 7]. Über dieses kann der Benutzer ge-
mäß seinen Berechtigungen bestehende Berichte anzeigen lassen, die Eigenschaften der
Berichte (wie z. B. Name, Beschreibung, Berichtsoptionen, Eingabeaufforderungs-
werte) ändern, neue Berichte mittels Report Studio generieren und veröffentlichen und
nach Berichten, die bestimmte Merkmale beinhalten, suchen [vgl. Cogn06d, S. 7].
Die Client-Komponenten speichern nicht nur ihre Spezifikations-, Anwendungs- und
Prozessdaten in der Content Store Datenbank, sondern rufen diese Daten daraus auch ab
und tauschen diese Daten darüber aus. Der Content Store stellt somit den zentralen,
gemeinsamen Speicher für die Ablage von Metadaten und Content-Daten von Cognos
ReportNet dar.
Bei Cognos PowerPlay handelt es sich um ein OLAP-Werkzeug, mit dem mehrdimen-
sionale Datenanalysen durchgeführt werden können. Die Architektur besteht aus den
Komponenten Web-Server, Cognos PowerPlay Enterprise Server und mehreren Win-
dows- und web-basierten Client-Werkzeugen (siehe Abbildung 7-4) [vgl. Cogn04a, S.
9-10].
Databases
Web server
PowerPlay Enterprise Server
(Cognos Gateway)
PowerPlay for Windows
Windows Clients Web Client
(Dispatcher, Report Processor)
PowerPlay for Excel
PowerPlay Web (Explorer, Viewer)
PowerPlay Transformer
PowerCubes
Abb. 7-4: Cognos PowerPlay-Architektur [vgl. Cogn04a, S. 10-11]
7 Entwicklungs- und Domänenumgebung des Prototyps 77
Auf dem Web-Server ist äquivalent zu Cognos ReportNet das Cognos Gateway instal-
liert. Seine Aufgabe ist es, die eingehenden Anfragen an den PowerPlay Enterprise Ser-
ver weiterzuleiten. Der Cognos PowerPlay Enterprise Server umfasst zwei Kompo-
nenten, den Dispatcher und den Report Prozessor. Während der Dispatcher die einge-
henden Anfragen verwaltet und an den Report Prozessor weiterreicht, führt der Report
Prozessor die Anfrage aus und bereitet die ermittelten Ergebnisse für die Client-Kom-
ponenten auf. Von dem Report Prozessor können mehrere Instanzen gleichzeitig laufen.
Eine Beschränkung der Prozessoranzahl wird nur durch den verfügbaren Speicher
gesetzt [vgl. Cogn04a, S. 11].
Die Datenbasis von Cognos PowerPlay bilden so genannte (Daten-)Würfel (Power-
Cubes), die über den Cognos PowerPlay Enterprise Server zum Abruf für die Client-
Werkzeuge zur Verfügung gestellt werden können. Jedem Würfel liegt ein mehrdimen-
sionales Datenmodell zugrunde, in dem festgelegt ist, welche Daten Dimensionen und
welche Kennzahlen darstellen. Für die Modellierung des mehrdimensionalen Daten-
modells und die Generierung des Daten-Würfels kommt das Windows-basierte Werk-
zeug PowerPlay Transformer zum Einsatz [vgl. Cogn04b, S. 7]. Je Modellierungs-
element (Datenquelle, Dimension und Kennzahl) stellt PowerPlay Transformer einen
eigenen Definitionsbereich zur Verfügung. Im Bereich Datenquellen werden zunächst
die Metadaten der Datenquellen importiert (z. B. die Spaltennamen einer Tabelle oder
die Select-Elemente einer SQL-Abfrage), auf deren Basis der Aufbau des Würfel
modelliert wird, d. h. die Dimensionen, Dimensionshierarchien und Kennzahlen
definiert werden. In der Dimensionsübersicht werden die Dimensionen abgebildet. Sie
können hierarchisch oder nicht-hierarchisch modelliert werden. Bei einer hierarchischen
Dimension werden die Merkmale in so genannten Ebenen eingeteilt, die unterschied-
liche Aggregations-/Verdichtungsstufen der Daten darstellen. Im Bereich Kennzahlen
werden die Kennzahlen bestimmt, die der Datenwürfel umfassen soll. Neben Kenn-
zahlen, die direkt aus den Metadaten der im Datenwürfel definierten Datenquellen über-
führt werden, können in PowerPlay Transformer über die Definition von Formeln auch
neue Kennzahlen berechnet werden [vgl. Cogn04b, S. 8-10].
Bei der Erzeugung der Datenwürfel werden über die im Modell spezifizierten Daten-
quellen bzw. Abfragen die Daten (Merkmalsausprägungen) als so genannte Kategorien
ins Modell eingelesen. Während die generierten Datenwürfel in einem proprietären
(binären) Datenformat (.MDC) gespeichert werden, kann die Spezifikation des mehr-
dimensionalen Datenmodells bestehend aus den Strukturelementen des Modells (wie
7 Entwicklungs- und Domänenumgebung des Prototyps 78
z. B. Dimension, Ebene, Kategorie, Kennzahl usw.) und den Daten (Merkmalsaus-
prägungen) zusätzlich zum Standard-Binärformat (.PYI) noch in Form einer ASCII-
Datei (.MDL) abgelegt werden. In dieser Modelldefinitionsdatei liegen die Metadaten
des Modells in einem lesbaren Textformat vor.
Nach dem Einstellen der Datenwürfel auf dem Cognos PowerPlay Enterprise Server
kann der Benutzer über die windows-basierten Client-Werkzeuge PowerPlay für Win-
dows und PowerPlay für Excel und über das web-basierte Client-Werkzeug PowerPlay
Web auf die Würfel zugreifen [vgl. Cogn04a, S. 10] und Analysen der Daten durch-
führen. Beim Öffnen eines Würfels mit einem der Client-Werkzeuge (wie z. B. dem
PowerPlay Web Explorer) werden dem Benutzer die Daten im Würfel standardmäßig in
Form einer Kreuztabelle präsentiert, bei der in den Zeilen und Spalten die ersten beiden
Dimensionen und in den Zellen die Werte der ersten Kennzahl des mehrdimensionalen
Datenmodells dargestellt werden. Oberhalb der Kreuztabelle befindet sich die so ge-
nannte Dimensionsleiste, in der alle für die Analyse zur Verfügung stehenden Dimen-
sionen aufgeführt sind. Der Benutzer kann die Einstiegssicht mit den vom Client-Werk-
zeug bereitgestellten OLAP-Funktionalitäten (siehe Abschnitt 2.3) gemäß seinen Anfor-
derungen anpassen und gestalten. Beispielsweise kann er die in der Kreuztabelle dar-
gestellten Dimension gegen andere Dimensionen austauschen oder um andere Dimen-
sionen erweitern. Ebenso kann er die bisher ausgewählte Kennzahl durch eine andere
ersetzen. Über die Dimensionsleiste hat der Benutzer des Weiteren die Möglichkeit,
Filter zu setzen und damit die angezeigten Daten einzuschränken. Dazu muss der Be-
nutzer nur die Dimensionen in der Dimensionsleiste auf bestimmte Ausprägungen ein-
stellen. Hat der Benutzer alle für seine Auswertungszwecke notwendigen Änderungen
an der Einstiegssicht vorgenommen, so kann er die neu erzeugte Berichtsansicht als so
genannten analytischen Bericht speichern. Bei den windows-basierten Client-Werkzeu-
gen kann die Berichtsspezifikation in einem binären Format (.PPR) oder einem XML-
Format (.PPX) abgelegt werden [vgl. Cogn04c, S. 11]. Eine mit dem PowerPlay Web
Explorer erzeugte Berichtsansicht kann hingegen nur über die Generierung eines Lese-
zeichen (Bookmark) in Form einer URL gespeichert und für einen späteren Zugriff vor-
gehalten werden.
7 Entwicklungs- und Domänenumgebung des Prototyps 79
7.2.2 MSS-Metadatenmodell
Das MSS-Metadatenmodell dient dazu, MSS-Informationen wie z. B. einen Standard-
bericht und alle seine Inhalte strukturiert abzulegen, um sie automatisiert (per Agenten)
wieder finden zu können. In der Abbildung 7-5 ist das der MSS-Metadatenbasis
zugrunde liegende relationale Datenmodell dargestellt. Es handelt sich um ein gene-
risches Datenmodell, welches insgesamt sechs Tabellen umfasst. Die Tabelle MSS-
CATEGORIES enthält die beiden in Abschnitt 6.2.4 genannten Kategorien MSS-Werk-
zeug und MSS-Information. Darüber wird die Zugehörigkeit einer Information zu einer
der beiden Klassen (MSS-Tool oder MSS-Information) beschrieben. In der Tabelle
MSSTYPES werden die verschiedenen MSS-Informationstypen gespeichert, die eine
Information im Detail darstellt. Als mögliche Informationstypen sind bis jetzt die fol-
genden 13 Merkmale definiert: Category, Level, Dimension, Measure, Cube, OLAP
Report, Data Item, Parameter, Standard Report, Perspective, Goal, Balanced Scorecard
und MSS-Tool. Jedem Informationstyp können wiederum eine oder mehrere Eigen-
schaften wie z. B. Name (Name), Beschreibung (Description), Kontext (Context), Pro-
grammaufruf (Programcall) usw. zugeordnet werden. Da eine Eigenschaft für mehrere
Informationstypen zutreffend sein kann (z. B. Beschreibung (Description) für die In-
formationstypen Dimension, Cube, OLAP Report usw.), eine andere Eigenschaft jedoch
nur genau für einen bestimmten Informationstyp definiert ist (z. B. Formel (Formula)
für den Informationstyp Measure), werden die Eigenschaften separat in der Tabelle
MSSPROPERTIES und die Zuordnungen der Eigenschaften zu den Informationstypen
in der Tabelle MSSTYPEPROPERTIES verwaltet.
Abb. 7-5: Datenmodell der MSS-Metadatenbasis
Eine zentrale Rolle im MSS-Metadatenmodell spielt die Tabelle MSSOBJECTS. Hier
wird für jede einzelne Information (OID) festgehalten, welchen Namen sie hat (OB-
JECTNAME), welcher Kategorie sie angehört (CID), zu welchem Informationstyp sie
7 Entwicklungs- und Domänenumgebung des Prototyps 80
zählt (TID), zu welcher direkt übergeordneten Information sie gehört (POID) und wel-
cher Basisinformation sie zugeordnet ist (ROOTID).
Für einen analytischen (OLAP-)Bericht wie z. B. „Bericht über die Entwicklung der
Gesamtstudierendenzahl je Studiengang, Fachsemester und Geschlecht“ können fol-
gende Metadaten/Zusatzinformationen in einem Eintrag in der Tabelle MSSOBJECTS
hinterlegt werden: Bei der Information (OID=34564) handelt es sich um eine MSS-
Information (CID=1), mit dem Namen „Bericht über die Entwicklung der Gesamtstu-
dierendenzahl je Studiengang, Fachsemester und Geschlecht“ (=OBJECTNAME), die
vom Informationstyp OLAP Report (TID=11) ist. Da eine Information vom Informa-
tionstyp OLAP Report keine direkte übergeordnete Information besitzt, wird in dem
Feld POID die eigene OID eingetragen (POID=34564). Als Basisinformation (ROOT-
ID) ist die OID des Datenwürfels abgelegt, auf dessen Grundlage der Bericht generiert
wurde. In diesem Fall ist das die MSS-Information „Studierenden-Daten“ (OID=2), die
selbst vom Informationstyp Cube (TID=5) ist.
Die einzelnen Kontextelemente eines OLAP-Berichtes (d. h. die Dimensionen, Ebenen,
Kategorien und Kennzahlen) werden ebenfalls in der Tabelle MSSOBJECTS abgelegt
und zwar jeweils in Form eines eigenen Datensatzes. Für ein analytisches Auswertungs-
merkmal wie z. B. das Merkmal „Biologie“ werden dabei folgende Metadaten in der
Tabelle MSSOBJECTS vorgehalten: Die Information mit dem Namen „Biologie“
(=OBJECTNAME) und der OID=379113 entspricht einer MSS-Information (CID=1)
vom Informationstyp Category (TID=1). Sie ist der MSS-Information „Studienfach“
(POID= 409), die vom Informationstyp Level ist, direkt untergeordnet. Die zugrunde
liegende Basisinformation entspricht der MSS-Information „Studierenden-Daten“
(ROOTID=2), welche den Informationstyp Cube besitzt.
Über die Tabelle MSSOBJECTPROPERTIES werden jeder MSS-Information noch
Eigenschaften mit ihren Werten zugeordnet. Für das obige Beispiel der MSS-Informa-
tion vom Informationstyp OLAP Report können dort neben den Eigenschaften Id
(=34564), Name (=Bericht über die Entwicklung der Gesamtstudierendenzahl je
Studiengang, Fachsemester und Geschlecht) und Description (=Eine Ansicht auf den
Datenwürfel Studierenden-Daten, der die Verteilung der Gesamtstudierendenzahl
(Fachfälle) auf die Fachsemester darstellt, ohne Beurlaubte und ohne Gasthörer je Stu-
diengang und Geschlecht.), die bei allen Informationstypen gesetzt werden können,
noch weitere Eigenschaften angegeben werden, wie z. B. Context (=|C|Studierenden-
7 Entwicklungs- und Domänenumgebung des Prototyps 81
Daten|D|Studiengang|D|Fachsemester|D|Geschlecht|D|Beurlaubungsgrund|F|Beurlaub-
ungsgrund*Nicht-Beurlaubt|F|Hörerstatus*Haupt-/Nebenhörer|M|AnzahlFachFälle) und
Programcall (=http://localhost/cognos/cgi-bin/ppdscgi.exe?DC=Q&E=/Studierenden-
Daten&TX=Studiengang%09Studiengang%09Fachsemester%09Fachsemester%09Gesc
hlecht%09Geschlecht%09Beurlaubungsgrund%09Nicht-Beurlaubt%09KENNZAH-
LEN%09AnzahlFachFälle).
Bei einer Information der Kategorie MSS-Tool (CID=2) wie z. B. „PowerPlay Enter-
prise Server 7.0“ (OID=4) entsprechen die POID und die ROOTID der OID, da es dafür
keine übergeordneten Informationen gibt. Als Informationstyp ist MSS-Tool (TID=14)
eingetragen. Zusätzlich zu den Eigenschaften Name (=PowerPlay Enterprise Server 7.0)
und Id (=4) spielen hier noch Eigenschaften wie z. B. Programcall (=http://localhost-
/cer4/cgi-bin/ppdscgi.exe?DC=Q&E=) für den Informationsabruf und Producttype
(=OLAP-Tool) für die Assistenzfunktion eine wichtige Rolle.
Durch diese Konzeption des MSS-Metadatenmodells als generisches Modell wurde die
Möglichkeit geschaffen, flexibel auf Änderungen seitens der MSS-Metadaten reagieren
zu können, ohne Änderungen an der Struktur des Datenmodells vornehmen zu müssen.
Neue MSS-Informationstypen werden einfach in die Tabelle MSSTYPES hinzugefügt
und die Tabelle MSSPROPERTIES wird um die Eigenschaften der neuen Informations-
typen ergänzt. Welche Informationstypen genau welche Eigenschaften umfassen, wird
erst durch das Setzen der Referenzen in der Tabelle MSSTYPEPROPERTIES be-
stimmt. Diese Freiheiten bei der Festlegung der Beziehungen (zwischen Informations-
typ und Eigenschaften) gibt es auch bei der Zuordnung der Eigenschaften zu einer In-
formation. Hier werden die Verbindungen erst durch die entsprechenden Einträge in der
Tabelle MSSOBJECTPROPERTIES definiert.
7.2.3 MSS-Metadaten-Bewirtschaftung
Im Folgenden wird beschrieben, wie die MSS-Metadatenbasis mit Metadaten befüllt
werden kann und welche Metadaten woher und wie aus den für das MSS-Assistenz-
system ausgewählten MSS-Werkzeugen Cognos ReportNet und Cognos PowerPlay
(vgl. Abschnitt 7.2.1) gewonnen werden können.
Die MSS-Metadaten-Bewirtschaftung umfasst sowohl
- eine manuelle als auch
- eine (teil-)automatisierte Komponente.
7 Entwicklungs- und Domänenumgebung des Prototyps 82
Bei der manuellen Komponente handelt es sich um eine Client-Anwendung, die auf
Basis des MSS-Metadatenmodells mittels Microsoft Access und Visual Basic ent-
wickelt wurde (siehe Abbildung 7-6).
Abb. 7-6: Aufbau der manuellen Komponente zur Konfiguration und Befüllung der MSS-Metadatenbasis
2 3 1
4 5
Die Anwendung besteht aus einem Formular, das fünf Seiten beinhaltet (siehe die
Nummern in der Abbildung 7-6), die über Reiter aufgerufen werden und über die der
Anwender einerseits die MSS-Metadatenbasis konfigurieren, andererseits aber auch mit
MSS-Informationen befüllen kann. Über die ersten drei Seiten können die Basis-Ele-
mente der MSS-Metadatenbasis, d. h. die Kategorien (Categories), Informationstypen
(Information types) und Eigenschaften (Properties) definiert werden. Der Anwender
kann jeweils neue Elemente hinzufügen (add), bestehende Elemente ändern (edit)
und/oder bestehende Elemente löschen (delete). Auf der vierten Seite (Properties
Assignments) hat der Anwender die Möglichkeit, die Zuordnung der Eigenschaften
(Properties) zu den Informationstypen (Information types) festzulegen. Mit Hilfe einer
Auswahl-Box wird der Informationstyp ausgewählt, bei dem neue Eigenschaften zuge-
wiesen oder bestehende Zuweisungen wieder rückgängig gemacht werden sollen. Über
die fünfte und damit letzte Seite der Anwendung kann der Anwender schließlich die in
der MSS-Metadatenbasis enthaltenen MSS-Informationen und deren Details einsehen.
Er kann darüber sowohl neue MSS-Informationen in die MSS-Metadatenbasis hinzu-
7 Entwicklungs- und Domänenumgebung des Prototyps 83
fügen, bestehende MSS-Informationen und deren Eigenschaften ändern als auch be-
stehende MSS-Informationen aus der MSS-Metadatenbasis löschen. Um die Liste mit
den dargestellten MSS-Informationen übersichtlicher zu gestalten, wurde eine Filter-
funktion auf Basis der Informationstypen in die Seite eingebaut.
In der Abbildung 7-7 ist der Dialog der Funktion „add“ dargestellt, über die eine neue
MSS-Information in der MSS-Metadatenbasis angelegt werden kann. Die Id der neuen
MSS-Information wird systemseitig vorgegeben. Je MSS-Information kann der Anwen-
der den Namen („Biologie“), die übergeordnete MSS-Information (Parent object) („Stu-
dienfach“), den Informationstyp („Category“), die zugehörige Basis-MSS-Information
(Root object) („Studierenden-Daten“) und die Kategorie („MSS-Information“) festle-
gen. Während der Name frei definiert werden kann, können die anderen Merkmale einer
MSS-Information nur über Auswahllisten bestimmt werden. Bei der Auswahlliste zur
Festlegung der übergeordneten MSS-Informationen werden dem Anwender nur MSS-
Informationen vom Informationstyp Level und Dimension angeboten. Zur Bestimmung
der Basis-MSS-Information stehen nur MSS-Informationen der Typen Cube und MSS-
Tool zur Verfügung. Trifft der Anwender bei der übergeordneten MSS-Information und
bei der Basis-MSS-Information keine Auswahl, so wird als Referenz die eigene OID
gesetzt. Dies ist immer dann der Fall, wenn eine neue Basis-MSS-Information wie z. B.
eine neue MSS-Information vom Typ Cube oder MSS-Tool angelegt wird.
Abb. 7-7: Dialog-Fenster der Funktion „add Information object“
7 Entwicklungs- und Domänenumgebung des Prototyps 84
Über die Funktion „edit“ können jeder neuen MSS-Information eine Menge von Eigen-
schaften und deren Werte zugewiesen werden bzw. von bestehenden MSS-Informa-
tionen der Name geändert, die Werte der Eigenschaften geändert und/oder zugewiesene
Eigenschaften gelöscht werden (siehe Abbildung 7-8). Zum Ändern des Wertes einer
bereits zugewiesenen Eigenschaft muss der Anwender die Eigenschaft in der Liste
(„Information object details“) markieren, damit sie im darunter liegenden Textfeld an-
gezeigt und editiert werden kann. Durch Klicken auf „update Property“ wird der Wert
der Eigenschaft schließlich aktualisiert. Um einer MSS-Information weitere Eigen-
schaften zuzuweisen, gibt es eine Auswahlliste, die alle noch nicht zugewiesenen Eigen-
schaften („available Properties“) des entsprechenden MSS-Informationstyps beinhaltet.
Nach Auswahl der Eigenschaft, die zugewiesen werden soll, und Eintrag des Eigen-
schaftswertes in dem darunter liegenden Textfeld wird über das Klicken auf „add
Property“ die Eigenschaft mit ihrem Wert in die Detail-Liste übernommen. Zum
Löschen einer bereits zugewiesenen Eigenschaft muss der Anwender diese einfach in
der Detail-Liste auswählen und auf „delete Property“ klicken.
Abb. 7-8: Dialog-Fenster der Funktion „edit Information object“
Da eine reine manuelle Befüllung der MSS-Metadatenbasis sehr (zeit-)aufwendig und
aufgrund der Masse an MSS-Informationen, die abzubilden sind, auch kaum zu leisten
wäre, ist zusätzlich eine (teil-)automatisierte Komponente zur MSS-Metadatenbewirt-
schaftung entwickelt worden. Bei der (teil-)automatisierten Komponente handelt es sich
um mittels des ETL-Werkzeuges PowerCenter der Firma Informatica definierte ETL-
Prozesse, über die, auf Grundlage der in den beiden ausgewählten MSS-Werkzeugen
7 Entwicklungs- und Domänenumgebung des Prototyps 85
Cognos ReportNet und Cognos PowerPlay vorliegenden Speicherkonzepte (siehe
Abschnitt 7.2.1), die für die MSS-Metadatenbasis relevanten Metadaten extrahiert
werden. Die Abbildung 7-9 stellt skizzenhaft den Aufbau der (teil-)automatisierten
Komponente dar.
Content store
Cognos ReportNet
MSS-Meta-datenbasis
*.mdl -Datei
Cognos PowerPlay
ETL-Prozess
ETL-Prozess
Abb. 7-9: Schematischer Aufbau der (teil-)automatisierten Komponente zur MSS-Metadaten-Bewirtschaftung
Bei Cognos PowerPlay liegen die Metadaten nur verteilt in den einzelnen Modelldefini-
tionsdateien (.mdl) vor. Diese enthalten die Spezifikationen der mehrdimensionalen
Modelle, auf deren Basis die Datenwürfel generiert werden. Die MDL-Dateien bilden
somit bei Cognos PowerPlay die Grundlage für die Gewinnung der MSS-Metadaten. In
der Abbildung 7-10 sind einzelne Abschnitte der Spezifikation aus einer MDL-Datei
dargestellt. Der Aufbau der MDL-Datei kann in einzelne Definitionsbereiche unterteilt
werden, die durch bestimmte Schlüsselwörter eingeführt werden. Die in der Abbildung
7-10 fettgedruckten Bezeichnungen wie Dimension, Levels, Category und Measure ent-
sprechen solchen Schlüsselwörtern. Anhand dieser Schlüsselwörter werden die Da-
ten/Merkmale den einzelnen Strukturelementen (OLAP-Konzepten) des mehrdimen-
sionalen Modells zugeordnet. Bei dem Merkmal „Studienjahr->PrfSemester“ handelt es
sich laut Abbildung 7-10 demnach um eine Dimension, während das Merkmal „Stu-
dienjahr“ einer (Hierarchie-)Ebene (Levels) einer Dimension entspricht. Mit dem
Schlüsselwort „Category“ werden in der MDL-Datei die einzelnen Ausprägungen einer
Dimension bzw. einer Dimensionsebene gekennzeichnet. Beispielsweise stellen die
Merkmale „2006“ und „2007“ Kategorien der Dimensionsebene „Studienjahr“ dar. Eine
Kennzahl wie z. B. „AnzahlPrüfungen“ wird innerhalb der MDL-Datei mit dem Schlüs-
selwort „Measure“ eingeleitet. Neben diesen bisher beschriebenen Haupt-/Kern-Schlüs-
selwörtern, gibt es in der MDL-Datei noch weitere Begriffe, über die bestimmte Infor-
mationen besonders gekennzeichnet werden. Hierzu zählen zum Beispiel die Begriffe
7 Entwicklungs- und Domänenumgebung des Prototyps 86
„DimInfo“, „LevelInfo“ und „MeasureInfo“, über die eine Beschreibung des jeweiligen
Merkmals (Dimension, Level oder Measure) eingeführt wird.
Name "Prüfungsanalyse" CharacterSet "nlsCSWindows_1252" AutoAccess False Synchronize False SynchroCycle 0 SynchroStamp 0 UpdateCycle 141 ModelStamp 958378307 … Dimension 297 "Studienjahr->PrfSemester" DimType Regular NewCatsLock False ExcludeAutoPartitioning False DimDefaultCategory 0 DimInfo "Studienjahr der Prüfung, detaillierbar (drill-down) auf die (zugehörigen) Semester, z.B. 1999->WS98/99 und SS99." ... Levels 309 "Studienjahr" Blanks "( Leerstelle )" DateFunction None Generate Need RefreshLabel False RefreshDescription False RefreshShortName False NewCatsLock False Timerank 0 UniqueCategories False UniqueMove False LevelInfo "Studienjahr (Erfassungssemester)" Associations 146715 "Studienjahr (Erfassungssemester)" AssociationType Type_Query AssociationRole Role_Source AssociationReferenced "Studienjahr (Erfassungssemester)" ... Levels 43599 "Erfassungssemester-ID" Blanks "( Leerstelle )" DateFunction None Generate None RefreshLabel True RefreshDescription True RefreshShortName True NewCatsLock False Timerank 0 UniqueCategories True UniqueMove False LevelInfo "Erfassungssemester" Associations 146725 "Erfassungssemester" AssociationType Type_Query AssociationRole Role_Source AssociationReferenced "Erfassungssemester" ... Category 373171 "2006" Parent 301 Levels 309 OrderBy Drill 301 Value "2006" Label "2006" ShortName "2006" Lastuse 20071205 SourceValue "2006" Filtered False Suppressed False Sign False HideValue False IsKeyOrphanage False IsTruncated False Blanks False CatInfo "2006" Category 373199 "2007" Parent 301 Levels 309 OrderBy Drill 301 Value "2007" Label "2007" ShortName "2007" Lastuse 20071205 SourceValue "2007" Filtered False Suppressed False Sign False HideValue False IsKeyOrphanage False IsTruncated False Blanks False CatInfo "2007" ... Measure 469 "AnzahlPrüfungen" Label "AnzahlPrüfungen" ShortName "AnzahlPrüfungen" Rollup Count Storage Default OutPutScale 0 Decimals 0 ReverseSign False IsCurrency False IsFolder False MeasureInfo "Prüfungsanzahl" DrillThrough False EndList Associations 147063 "MatrikelNr (anonym)" AssociationType Type_Query AssociationRole Role_Source AssociationReferenced "MatrikelNr (anonym)" ...
Abb. 7-10: Auszüge aus einer MDL-Datei
Auf Basis des Wissens über den Aufbau und die Inhalte einer MDL-Datei wurden meh-
rere ETL-Prozess-Schritte zur Gewinnung der MSS-Metadaten aus einer MDL-Datei
definiert. In einem ersten Prozess-Schritt (Mapping) werden zunächst die Daten aus der
MDL-Datei ausgelesen und zeilenweise in einer Datenbanktabelle temporär geladen.
Aus dieser Tabelle werden dann in weiteren Prozess-Schritten die relevanten Spezifi-
kationsdaten wie z. B. Dimensionen, Ebenen, Kategorien und Kennzahlen über die ent-
sprechenden Schlüsselwörter (Dimension, Levels usw.) extrahiert. Des Weiteren
werden Querbezüge zwischen den Strukturelementen wie z. B. zwischen Levels und
Dimension und zwischen Category und Levels ermittelt und temporär festgeschrieben.
Bei den letzten Prozess-Schritten werden schließlich die temporär aufbereiteten Meta-
daten in die beiden Tabellen MSSOBJECTS und MSSOBJECTPROPERTIES des
MSS-Metadatenmodells überführt. Die hier beschriebenen ETL-Prozess-Schritte zur
7 Entwicklungs- und Domänenumgebung des Prototyps 87
Gewinnung der Metadaten für die MSS-Metadatenbasis müssen für jede einzelne MDL-
Datei durchgeführt werden.
Bei Cognos ReportNet werden (fast) alle Informationen (d. h. Spezifikations-, Anwen-
dungs- und Prozessdaten) in der Content Store Datenbank verwaltet und gespeichert
(vgl. Abschnitt 7.2.1). Aus diesem Grund bildet hier die Content Store Datenbank den
Ausgangspunkt für die Gewinnung der MSS-Metadaten (siehe Abbildung 7-9). Dem
Content Store liegt ein relationales Datenmodell mit ca. 123 Tabellen zugrunde, die
jedoch nicht alle für die MSS-Metadatenbasis relevante Metadaten enthalten. Zur
Befüllung der MSS-Metadatenbasis werden nur die folgenden sechs Tabellen der Con-
tent Store Datenbank abgefragt: CMCLASSES, CMDATA, CMOBJECTS, CMOBJ-
NAMES_BASE, CMOBJPROPS13 und CMOBJPROPS3_BASE. Auf Basis dieser
Tabellen werden in einem ersten ETL-Prozess-Schritt zunächst alle dort definierten
Berichte und Berichtsansichten mit Namen, Beschreibung und Programmaufruf extra-
hiert und temporär in eine Datenbanktabelle geschrieben. Ausgehend von dieser Tabelle
werden in weiteren Prozess-Schritten die Informationen aufbereitet und schließlich in
die Tabellen MSSOBJECTS und MSSOPBJECTPROPERTIES des MSS-Metadaten-
modells geladen.
Da die (Meta-)Daten bei Cognos ReportNet im Gegensatz zu Cognos PowerPlay zentral
in der Content Store Datenbank vorgehalten werden, sind hier weniger ETL-Prozess-
Schritte zur Gewinnung und zur Aufbereitung der MSS-Metadaten erforderlich. Außer-
dem können die Metadaten alle in einem ETL-Vorgang in die MSS-Metadatenbasis ge-
laden werden.
Durch die MSS-Metadaten-Bewirtschaftung, d. h. die Überführung der Metadaten der
einzelnen MSS-Werkzeuge in das MSS-Metadatenmodell, wird eine MSS-Werkzeug-
übergreifende Vereinheitlichung der Metadatenstrukturen erreicht und der proprietäre
Charakter der Daten der einzelnen MSS-Werkzeuge überwunden.
8 Beschreibung des Prototyps
8.1 Klassenmodell des MSS-Assistenzsystems
Bei dem mit JADE entwickelten Prototypen1 einer agentenbasierten MSS-Assistenz
handelt es sich um ein Multi-Agentensystem mit einer hybriden Architektur, das ins-
gesamt sechs (konkrete) Agenten-Klassen umfasst, die jeweils einem der drei im Kon-
zept vorgesehenen Agenten-Typen (GUI-Agent, Vermittlungsagent und Funktions-
agent) (vgl. Abschnitt 6.1 und 6.2) zugeordnet werden können. Für ein MSS-Assistenz-
system sind im einfachsten Fall je ein GUI-Agent (Klasse MSSAssistanceAgent), ein
Vermittlungsagent (Klasse BrokerAgent) und fünf Funktionsagenten vorgesehen. Zu
den Funktionsagenten gehören ein Interpretation-Agent (Klasse InterpretationAgent),
ein Such-Agent (Klasse SearchAgent), ein Navigation-Agent (Klasse NavigationAgent)
und zwei Abfrage-Agenten (Klasse QueryAgent). Während der GUI-Agent von der
JADE Klasse GuiAgent (siehe Abschnitt 7.1.1) abgeleitet ist, sind sowohl der Vermitt-
lungsagent als auch die Funktionsagenten Unterklassen der Klasse GeneralAgent, die
wiederum eine Unterklasse der JADE Klasse Agent ist. GeneralAgent stellt ihren Unter-
klassen ein paar allgemeine, grundlegende Agentenfunktionen zur Verfügung wie z. B.
die Registrierung beim Directory Facilitator Agent (register()) und die Suche von
Agenten mit bestimmten Diensten (searchDF()). Abbildung 8-1 zeigt den Kern des
Klassendiagramms mit den Agentenklassen2 des MSS-Assistenzsystems.
In den folgenden Abschnitten wird nun auf jede der sechs Agentenklassen genauer ein-
gegangen und deren Zweck und Ziele beschrieben, welches Wissen sie besitzen und
schließlich über welche Kompetenzen bzw. welches Verhalten sie verfügen.
1 Der Start und die Initialisierung des agentenbasierten MSS-Assistenzsystems erfolgt über den Aufruf
der Klasse StartMSSAssistanceModul. Es handelt sich hierbei um eine einfache JAVA-Klasse, in deren main()-Methode, die JADE-Agentenplattform mit den spezifischen Agenten gestartet wird.
2 Ein ausführlicheres Klassenmodell des MSS-Assistenzsystems befindet sich im Anhang A-3.
8 Beschreibung des Prototyps 89
Abb. 8-1: Ausschnitt des Klassenmodells nur mit den Agentenklassen
8.2 Dokumentation der einzelnen Komponenten
8.2.1 MSSAssistanceAgent
Der MSSAssistanceAgent (kurz: Assistant) ist der GUI-Agent des Multi-Agentensys-
tems. Er stellt die graphische Benutzeroberfläche des MSS-Assistenzsystem-Prototyps
bereit und ist für die Interaktion mit dem Anwender und dem Vermittlungsagenten
(BrokerAgent; kurz: Broker) verantwortlich (vgl. Abschnitt 6.2.1). Als Schnittstelle
zwischen Anwender und Vermittlungsagent regelt er deren Informations- bzw. Daten-
austausch.
Interner Name der Task Beschreibung der Task METADATASEARCH Suche nach Metadaten (wie z. B. Definitionen, Zusatzinformationen)
auf Basis der Benutzerangaben COMPREHENSIVESEARCH MSS-Werkzeug-übergreifende Suche (über alle Informationstypen)
nach existierenden Informationen auf Basis der Benutzerangaben OLAPSEARCH Suche nach existierenden OLAP-Berichtssichten zu einem
bestimmten OLAP-Würfel auf Basis der Benutzerangaben NAVIGATION Generierung einer neuen OLAP-Berichtssicht auf Basis der
Benutzerangaben SAVEREPORTS
Speicherung einer zuvor automatisch generierten OLAP-Berichtssicht
SEARCHREPORTS Suche nach existierenden Berichtssichten auf Basis der Benutzerangaben
CONFIRMATION Aufforderung zur erneuten Auswahl von Merkmalen, aufgrund fehlender eindeutiger Übereinstimmung der Benutzerangaben mit den Informationen in der MSS-Metadatenbasis
Tab.: 8-1: Funktionen des MSSAssistanceAgent
8 Beschreibung des Prototyps 90
Die Benutzeroberfläche des GUI-Agenten besteht aus einem Hauptanwendungsfenster,
über das die vom Prototyp bereitgestellten Funktionen (im Folgenden auch als Tasks
benannt) aufgerufen werden können. Der entwickelte Prototyp stellt dem Anwender die
in Tabelle 8-1 dargestellten Tasks, die sich an dem zuvor identifizierten Unterstützungs-
bedarf orientieren, direkt oder indirekt zum Abruf zur Verfügung.
Für fast jede Task ist ein eigenes Dialogfenster implementiert worden, über das der
Anwender seine Problemstellung über Eingabe von Stichwörtern oder über Auswahl-
boxen spezifizieren und an das Agentensystem übergeben kann. Die vom Anwender
erhaltenen Daten leitet der Assistant an den Broker weiter, der mit Hilfe der anderen
Agenten (Funktionsagenten) die Anwenderanfrage bearbeitet. Nach Bearbeitung der
Anfrage präsentiert der Assistant dem Anwender die erarbeiteten Ergebnisse, die er
vom Broker erhalten hat, entweder direkt in dem Dialogfenster oder in einem Browser-
fenster.
Außer dem Broker kennt der Assistant keinen weiteren Agenten des Systems. Für die
Interaktion mit dem Broker stehen ihm zwei Haupt-Behaviour zur Verfügung, und zwar
RequestBrokerBehaviour und HandleBrokerResponsesBehaviour (siehe Abbildung 8-
2).
Abb. 8-2: Behaviour-Klassen des MSSAssistanceAgent
Mittels des RequestBrokerBehaviour (Klasse SimpleBehaviour), das durch eine vom
Anwender ausgelöste Dialog-Aktion (einem GUI-Event z. B. in Form eines Button-
Klick) aktiviert wird, erzeugt der Assistant eine neue Request Nachricht (Performa-
tive=Request) (vgl. Abschnitt 5.4), die zwei wichtige Informationen enthält. Zum Einen
stehen im Parameter Nachrichteninhalt (Content) die Angaben, die der Anwender über
8 Beschreibung des Prototyps 91
den Dialog eingegeben hat, d. h. die Anfrageparameter des Anwenders. Zum Anderen
wird in dem Parameter Conversation-Id3 der Nachricht der Name der Task, die der An-
wender gerade aufgerufen hat, vorgehalten.
Die mit diesen Informationen ausgestattete Nachricht schickt der Assistant schließlich
an den Broker mit der Aufforderung, die notwendigen Schritte zur Bearbeitung der
Anwenderanfrage einzuleiten.
Über das HandleBrokerResponsesBehaviour (Klasse CyclicBehaviour) verarbeitet der
Assistant alle vom Broker eingehenden Nachrichten. Je nachdem von welchem Typ
(Performative, z. B. Agree, Inform, Request usw.) die Nachricht ist und/oder welchen
Wert die Conversation-Id (z. B. COMPREHENSIVESEARCH, METADATA-
SEARCH, NAVIGATION usw.) der Nachricht besitzt, d. h. welche Task gerade ausge-
führt wird bzw. wurde, werden unterschiedliche Aktionen vom Assistant durchgeführt.
Der Erhalt einer Agree Nachricht beispielsweise führt unabhängig vom Wert der Con-
versation-Id dazu, dass der Assistant das Verhalten InformUserBehaviour (Klasse
SimpleBehaviour) aufruft und damit den Anwender durch Öffnen eines kleinen Hin-
weisfensters informiert, dass seine Anfrage jetzt bearbeitet wird. Das Hinweisfenster
bleibt dabei solange geöffnet, bis der Assistant eine weitere Antwortnachricht vom Bro-
ker erhält. Handelt es sich bei der eingehenden Nachricht um eine Inform Nachricht,
prüft der Assistant, welche Conversation-Id in der Nachricht des Broker steht, also wel-
che Task des MSS-Assistenzsystems gerade ausgeführt wurde und präsentiert die
empfangenen Ergebnisse entweder im gerade geöffneten Dialog oder, ausgelöst durch
das Verhalten DisplayResultsBehaviour (Klasse SimpleBehaviour), in einem eigenen
Browserfenster.
8.2.2 BrokerAgent
Bei dem BrokerAgent (kurz: Broker) handelt es sich um den im Konzept vorgesehenen
Vermittlungsagenten, der die zentrale Schnittstelle zwischen dem GUI-Agenten Assis-
tant und den Funktionsagenten im MSS-Assistenzsystems bildet (vgl. Abschnitt 6.2.2).
Er ist für die Planung und Steuerung der zur Bearbeitung einer Anwenderanfrage durch-
3 Der Nachrichtenparameter Conversation-Id wird im Prototyp dazu verwendet, zwei verschiedene Arten
von Kontextinformationen vorzuhalten. Während bei der Kommunikation zwischen dem Assistant und dem Broker dort der Name der vom Anwender aufgerufenen Funktion (Task) eingetragen wird, steht bei der Kommunikation zwischen dem Broker und den Funktionsagenten dort der Name des gerade angefragten Dienstes (Service), z. B. interpretation, query, calculate, searching usw.
8 Beschreibung des Prototyps 92
zuführenden Aufgaben zuständig. Das bedeutet, er ermittelt die zur Lösung der einzel-
nen Aufgaben benötigten Funktionsagenten und beauftragt sie, die gerade erforderliche
Funktion auszuführen. Des Weiteren reicht er die erarbeiteten Ergebnisse an den
Assistant weiter oder informiert diesen darüber, dass zur Bearbeitung der Anfrage wei-
tere Informationen vom Anwender erforderlich sind.
Zur Erfüllung dieser Planungs- und Koordinationsaufgaben besitzt der Broker eine in
JESS (vgl. Abschnitt 7.1.2) implementierte Wissens- bzw. Regelbasis mit einer vorge-
gebenen, aber erweiterbaren Menge an vordefinierten Strategien (vgl. Abschnitt 6.2.2
und 6.3), die angeben, welche Funktionen (im Folgenden auch Dienste genannt) in
welcher Reihenfolge für eine bestimmte Anwenderanfrage vorzunehmen sind. Jede
einzelne Strategie (deftemplate strategy) umfasst neben einem Namen (slot name), der
einer eindeutigen Kennung entspricht, und einer Beschreibung (slot description) daher
eine Liste mit Diensten (slot services), die in der vorgegebenen Reihenfolge durchzu-
führen sind. Insgesamt stehen dem Broker zurzeit fünf unterschiedliche Standardstrate-
gien (als Faktwerte) in der Wissensbasis zur Auswahl zur Verfügung (siehe Tabelle 8-
2).
Name (name) Beschreibung (description) Dienste (services) S_ONE Strategie, die die Interpretation von Benutzerangaben sowie
die Suche nach existierenden Informationen (Beschrei-bungen, Berichtssichten usw.) zu den Benutzerangaben vorsieht (Task COMPREHENSIVESEARCH und Task OLAPSEARCH).
interpretation searching
S_TWO Strategie, die zur Erstellung eines neuen OLAP-Berichtes angewendet werden kann (Task NAVIGATION).
interpretation navigation
S_THREE Strategie, die das Abrufen von Metadaten (d. h. Zusatzinfor-mationen wie z. B. Definitionen, Kommentaren, Berech-nungsvorschriften usw.) aus der MSS-Metadatenbasis unterstützt (Task METADATASEARCH).
interpretation
S_FOUR Strategie, die das Speichern von Berichtssichten in die MSS-Metadatenbasis ermöglicht (Task SAVEREPORT).
transferresults
S_FIVE Strategie, die das Suchen nach Berichten in unterschied-lichen Datenquellen unterstützt (Task SEARCHREPORT).
searching
Tab. 8-2: Standardstrategien des BrokerAgent
Durch das gewählte Konzept einer regelbasierten Wissensbasis ist es möglich, die
Anzahl an möglichen Strategien (vgl. Abschnitt 6.2.2) jederzeit manuell zu erweitern,
z. B. bei System- bzw. Funktionserweiterungen. Angelegt wird die Wissensbasis durch
Aufruf eines JESS-Skripts während der Initialisierung des Brokers. Zusätzlich zu den
Fakten S_ONE, S_TWO usw. und Regeln, die die einzelnen Fakten erschließen, werden
in der Wissensbasis noch Queries und Funktionen angelegt.
8 Beschreibung des Prototyps 93
Für jede Anwenderanfrage, die der Assistant an den Broker weiterleitet, ermittelt der
Broker zunächst eine geeignete Strategie aus seinem Set von Standardstrategien, nach
deren Anleitung er die Anfrage bearbeitet. Die Auswahl der Strategie erfolgt dabei auf
Basis der Conversation-Id-Information (d. h. des Namens der Task, die gerade vom
Anwender aufgerufen wurde), die in der Request Nachricht vom Assistant enthalten ist.
Die Abbildung 8-3 veranschaulicht anhand einzelner Quellcode-Ausschnitte die im Fol-
genden beschriebenen Programmabläufe bei der Strategie-Ermittlung und demonstriert
gleichzeitig beispielhaft das Zusammenspiel von JADE und JESS4.
public Strategy chooseStrategy(String task){ Strategy s=null; s= new Strategy(); try {
jess.executeCommand("(assert (task (name "+task+")))"); jess.run();
Value v=jess.fetch("STRATEGY"); Fact f = v.factValue(jess.getGlobalContext()); s.setName(f.getSlotValue("name").stringValue(null)); s.setDescription(f.getSlotValue("description")
.stringValue(null)); ValueVector vv=f.getSlotValue("services").listValue(null); Vector sv=new Vector(); for (int i=0; i<vv.size(); ++i) { String service=vv.get(i).stringValue(null); sv.addElement(service); } s.setServices(sv); } catch (JessException e1) { e1.printStackTrace();
} return s; }
((defrule strategy1 ?t <- (task (name ?n&: (or(eq ?n comprehensive-exact) (eq ?n comprehensive-inexact) (eq ?n olapsearch))))
=> (assert (strategyname S_ONE)) (retract ?t)) (defrule strategy2
?t <- (task (name ?n&: (eq ?n navigation)))
=> (assert (strategyname S_TWO)) (retract ?t) )...
(defrule chooseStrategy ?sn <- (strategyname ?n) => (bind ?token (run-query query-strategy ?n)) (bind ?fact (getFact ?token)) ;(printout t "Result "?fact) (store STRATEGY ?fact) (retract ?sn))
(defquery query-strategy (declare (variables ?sn)) (strategy (name ?n&:(eq ?n ?sn))))
1
3 2
4
Abb. 8-3: JADE- und JESS-Codeausschnitte des BrokerAgent zur Ermittlung einer Strategie
In der Java-Funktion chooseStrategy() ruft der Broker über seine JESS-Engine die
JESS-Funktion assert auf und fügt damit den Tasknamen (z. B. OLAPSEARCH) als
einen neuen Faktwert vom Typ task in seine Faktenbasis ein (1). Die Auswertung des
Vorwärtsalgorithmus stellt fest, dass die Bedingung einer der Strategie-Regeln wie z. B.
strategy1, die die Existenz einer bestimmten Task in der Faktenbasis vorsieht, erfüllt
wird, so dass die Regel durch Aufruf des JESS-Befehls run „gefeuert“ wird, d. h. zur 4 Der graue Kasten beinhaltet den JAVA-Quellcode der Funktion chooseStrategy() des JADE-Agenten
Broker. Bei den weiß hinterlegten Kästen handelt es sich um JESS-Quellcode aus der Regelbasis des Brokers.
8 Beschreibung des Prototyps 94
Ausführung kommt (2). Als erste Aktion, die in der Konklusion der Strategie-Regel
strategy1 definiert ist, wird ein bestimmter Strategiename als Faktwert (hier z. B. strate-
gyname S_ONE) in die Faktenbasis hinzugefügt. Des Weiteren wird der zuvor einge-
fügte Task-Faktwert wieder aus der Faktenbasis gelöscht. Das Hinzufügen des neuen
Faktwertes wie z. Β. S_ONE hat zur Folge, dass die Bedingung der (variablen) JESS-
Regel chooseStrategy erfüllt ist und diese somit ausgeführt wird. Über die in der Kon-
klusion der Regel chooseStrategy definierte Query query-strategy (3) wird auf Basis des
Strategienamens, der entsprechende Strategie-Faktwert (S_ONE) aus der Faktenbasis
abgefragt und in der JESS-Variablen STRATEGY zwischengespeichert. Mittels des
JESS-Befehls fetch kann der Broker schließlich diesen Strategie-Faktwert aus der Fak-
tenbasis heraus abrufen und dessen Slot-Werte (insbesondere die Liste der auszuführen-
den Dienste) einlesen (4). Die von einer Strategie vorgegebenen Dienste sind in dem
Slot-Listen-Attribut services hinterlegt. In der Reihenfolge der dort angegebenen
Dienste, sucht der Broker jeweils nach den Funktionsagenten, die den laut Strategie
geforderten Dienst bereitstellen, und fordert diese auf, das nachgefragte Verhalten aus-
zuführen.
Abb. 8-4: Behaviour-Klassen des BrokerAgent
Wie in der obigen Abbildung 8-4 zu sehen, verfügt der Broker insgesamt über fünf un-
terschiedliche Behaviour. Mit dem ReceiveRequestBehaviour (Klasse CyclicBehaviour)
ruft er regelmäßig seine Nachrichten-Queue nach Request Nachrichten ab, die er vom
Assistant zugesandt bekommen hat. Handelt es sich bei der Request Nachricht um eine
8 Beschreibung des Prototyps 95
neue Anwenderanfrage (d. h. die Conversation-Id hat nicht den Wert CONFIRMA-
TION) (siehe Abschnitt 8.2.1), schickt der Broker dem Assistant eine Agree Nachricht
mit der Information, dass er die Bearbeitung der Anfrage übernimmt.
Vor der Strategieermittlung werden zunächst die Benutzereingaben (d. h. die Stich-
wörter, die der Anwender vereinfacht in einem Texteingabefeld mit einem Semikolon
getrennt als Anfrage definiert) mit den Daten der MSS-Metadatenbasis abgeglichen.
Dazu ruft der Broker das Verhalten ParseUserInputBehaviour (Klasse SimpleBeha-
viour) auf, über das er prüft, ob die Stichwörter des Anwenders so oder in ähnlicher
Form und Schreibweise in der MSS-Metadatenbasis enthalten sind. Der Broker ver-
gleicht dazu jedes einzelne Stichwort mit den Inhalten (konkret mit den Einträgen in der
Spalte OBJECTNAME) der MSS-Metadatentabelle MSSOBJECTS (siehe Abschnitt
7.2.2) und sammelt alle passenden Einträge aus der Tabelle in einer Liste. Im nächsten
Schritt ermittelt er dann (wie oben bereits beschrieben) die Strategie, mit der er am
besten die Anwenderanfrage lösen kann und ruft das RequestFunctionAgentsBehaviour
(Klasse SimpleBehaviour) auf. In diesem Behaviour greift er zuerst auf sein Send-
RequestBehaviour (Klasse SimpleBehaviour) und dann auf sein ReceiveInformBeha-
viour (Klasse SimpleBehaviour) zu. Entsprechend der in der ermittelten Strategie vor-
gegebenen Liste der auszuführenden Dienste wird zunächst der Dienst angefordert, der
an der ersten Position in der Service-Liste steht. Dazu sucht der Broker in dem Send-
RequestBehaviour mit Hilfe des Directory Facilitator Agenten (siehe Abschnitt 7.1.1)
nach dem Funktionsagenten, der den Dienst bereitstellt und schickt ihm eine Request
Nachricht mit der Aufforderung, den Dienst auszuführen. Neben den (gegen die MSS-
Metadatenbasis geprüften) Stichwörtern des Anwenders im Parameter Content enthält
die Nachricht im Parameter Conversation-Id als Kontextinformation diesmal den
Namen des gerade angeforderten Dienstes (z. B. interpretation, query usw.). Mit dem
ReceiveInformBehaviour wartet der Broker schließlich auf eine Inform Antwort von
den zuvor angesprochenen Funktionsagenten. Hat der Broker eine Inform Nachricht
erhalten, prüft er, ob noch weitere Dienste gemäß der Strategie durchzuführen sind oder
ob eventuell weitere Informationen vom Anwender zur Bearbeitung der Anfrage erfor-
derlich sind. In dem Fall, dass die Liste der Dienste noch nicht vollständig abgearbeitet
ist, ruft der Broker in seinem ReceiveInformBehaviour erneut das RequestFunction-
AgentsBehaviour auf. Falls die Strategie abgearbeitet ist, sendet der Broker dem
Assistant die von den Funktionsagenten erarbeiteten Ergebnisse mittels einer Inform
Nachricht zu.
8 Beschreibung des Prototyps 96
8.2.3 InterpretationAgent
Der InterpretationAgent (kurz: IPAgent) ist vom Typ Funktionsagent. Seine Aufgabe
besteht darin, die vom Anwender eingegebenen Daten zu interpretieren und dazuge-
hörige Metadaten aus der MSS-Metadatenbasis, in der alle zur Verfügung stehenden
MSS-Informationen vorliegen (siehe Abschnitt 7.2.2), abzurufen (Service „interpre-
tation“). Für jedes Stichwort bzw. für jedes ausgewählte Merkmal des Anwenders sucht
der IPAgent zunächst nach äquivalenten MSS-Informationen in der MSS-Metadaten-
basis. Zu jeder gefundenen MSS-Information ermittelt er dann die zugehörigen MSS-
Metadaten (siehe Abschnitt 7.2.2) wie z. B. den Informationstyp und die Beschreibung.
Die Zuordnung der Metadaten je MSS-Information basiert dabei auf den beiden Tabel-
len MSSOBJECTS und MSSOBJECTPROPERTIES der MSS-Metadatenbasis. Als
Ergebnis liefert der IPAgent zu jedem Merkmal des Anwenders die in der MSS-Meta-
datenbasis gefundenen Übereinstimmungen an MSS-Informationen samt Metadaten
zurück.
Zur Erfüllung seiner Aufgabe stehen dem IPAgent das ReceiveRequestBehaviour
(Klasse CyclicBehaviour) und das InterpretDataBehaviour (Klasse SimpleBehaviour)
zur Verfügung (siehe Abbildung 8-5).
Abb. 8-5: Behaviour-Klassen des InterpretationAgent
Mittels des ReceiveRequestBehaviour fragt der IPAgent wiederholt seine Nachrichten-
Queue danach ab, ob er eine Request Nachricht vom Broker erhalten hat. Ist dies der
Fall, ruft er im nächsten Schritt das Verhalten InterpretDataBehaviour auf. Über dieses
Verhalten erfolgt die Zuordnung der Anwenderangaben zu den MSS-Informationen in
der MSS-Metadatenbasis. Der IPAgent sucht dazu für jedes einzelne Merkmal des An-
wenders passende MSS-Informationen aus der MSS-Metadatenbasis und sammelt diese
in einer Liste. Die Liste mit den gefundenen Übereinstimmungen schickt er schließlich
mittels einer Inform Nachricht an den Broker zurück.
8 Beschreibung des Prototyps 97
8.2.4 QueryAgent
Eine weitere Agentenklasse vom Typ Funktionsagent ist der Abfrage-Agent Query-
Agent (kurz: QAgent). Es handelt sich dabei um einen Agenten, der Datenabfragen an
eine ihm bekannte Datenbank bzw. Datenquelle stellen kann. Kennzeichnend für diese
Klasse ist, dass jedem Exemplar bei der Initialisierung genau eine Datenquelle zugeord-
net wird. Die Gründe für diese Art der Implementierung liegen darin, dass im Allge-
meinen verschiedene Datenquellen/-banken als Informationsquellen zur Verfügung
stehen, die auf unterschiedliche Art und Weise angesprochen werden und die zumeist
unterschiedliche Datenstrukturen und -Inhalte aufweisen. Eine Implementierung eines
QueryAgent, der alle Typen von Datenquellen abfragen kann, erscheint daher so gut
wie unmöglich bzw. nicht wirklich effektiv und effizient, so dass je Datenquelle genau
ein spezifischer QueryAgent vorgesehen ist.
In der Agentenplattform des Prototyps existieren zwei Ausprägungen (Exemplare) von
QAgent. Bei dem einen Agenten mit dem Namen QAgent1 handelt es sich um den für
die MSS-Metadatenbasis des MSS-Assistenzsystems (siehe Abschnitt 7.2.2) (Daten-
quelle: MSSKB) speziell konzipierten QueryAgent. Dieser kann im Gegensatz zu den
anderen Agenten des MSS-Assistenzsystems nicht nur Informationen aus der MSS-
Metadatenbasis abfragen, sondern auch Informationen in die MSS-Metadatenbasis
schreiben. Der QAgent1 kann somit nicht nur nach existierenden Informationen wie
z. B. Berichtssichten in der MSS-Metadatenbasis suchen, sondern zusätzlich diese um
neu erstellte Berichtssichten ergänzen.
Der zweite QueryAgent (Name: QAgent2) ist zuständig für Abfragen auf der Daten-
basis der im Abschnitt 3.2 beschriebenen IWUI-Komponente (Datenquelle: MISKB),
die Bestandteil der MIS-Infrastruktur der Universität Osnabrück ist (siehe Abschnitt
3.2). Es handelt sich hierbei um eine Metadatenbank, in der ähnlich wie in der MSSKB-
Datenquelle ebenfalls Informationen unterschiedlicher Typen wie z. B. Definitionen,
Grafiken und kommentierte Berichtssichten gespeichert sind. Während bei der MSSKB-
Datenquelle Informationen nur über die Agenten des MSS-Assistenzsystems abgerufen
und gespeichert werden können, hat der Anwender bei der MISKB-Datenquelle die
Möglichkeit, über eine Web-Schnittstelle selbst Informationen in der Datenbank zu än-
dern bzw. zu ergänzen.
Alle Instanzen der QueryAgent Klasse besitzen die Fähigkeit, Datenabfragen an ihre
Datenquelle zu stellen (Service „query“). Der QAgent1 bietet zusätzlich dazu noch die
8 Beschreibung des Prototyps 98
Möglichkeit, statistische Auswertungen auf den Metadaten in der MSS-Metadatenbasis
durchzuführen (Service „calculate“) und Ergebnisse wie z. B. neue Berichtssichten in
der MSS-Metadatenbasis zu speichern (Service „transferresults“). Zu dem Verhalten
HandleSearchRequestBehaviour (Klasse FSMBehaviour), das alle QueryAgent-
Exemplare besitzen, kommen beim QAgent1 deswegen neben dem ReceiveRequest-
Behaviour (Klasse CyclicBehavoiur) noch das SaveResultBehaviour (Klasse Simple-
Behaviour), sowie das CalculateDataBehaviour (Klasse SimpleBehaviour) hinzu. Die
Abbildung 8-6 stellt alle vom QAgent1 bereitgestellten Behaviour dar.
Abb. 8-6: Behaviour-Klassen des QueryAgent (QAgent1)
Bei dem HandleSearchRequestBehaviour prüft der QAgent, ob er auch vom Such-
Agent (SearchAgent, kurz: SAgent) (siehe Abschnitt 8.2.5) eine Request Nachricht
erhalten hat, mit der Aufforderung seine eigene Datenquelle nach Berichtssichten zu
durchsuchen, die zu den in der Nachricht enthaltenen Informationen passen. Nachdem
der QAgent den Eingang einer Request Nachricht mit einer Agree Nachricht bestätigt
hat, ermittelt er auf Basis der übergebenen Daten alle Berichte aus seiner Datenquelle,
die diese Daten vollständig oder zum Teil enthalten. Dazu prüft der QAgent den Kon-
text der in seiner Datenquelle vorliegenden Berichte auf Übereinstimmung mit den vor-
gegebenen Merkmalen und zählt je Bericht die Häufigkeit der Übereinstimmungen. Die
gefundenen Berichte werden schließlich in einer Liste gesammelt und in einer Inform
Nachricht dem SAgent als Antwort zugesandt.
Mit dem ReceiveRequestBehaviour regelt der QAgent1 den Eingang von Request
Nachrichten, die er nicht vom SAgent erhalten hat. In Abhängigkeit des Senders der
8 Beschreibung des Prototyps 99
Nachricht oder des darin übermittelten Wertes der Conversation-ID führt der QAgent1
dann ein anderes Verhalten aus.
Handelt es sich bei dem Sender um den Broker mit der Aufforderung, Ergebnisse - kon-
kret sind damit Berichtssichten gemeint - in die eigene Datenquelle MSSKB zu spei-
chern (Conversation-Id=transferresults), so kommt das Verhalten SaveResultsBehaviour
zum Einsatz. Bei diesem Verhalten fügt er die neue Berichtssicht, d. h. die neue MSS-
Information, mit den zugehörigen MSS-Metadaten in die Tabellen MSSOBJECTS und
MSSOBJECTPROPERTIES der MSS-Metadatenbasis hinzu. Die Inform Nachricht, die
der QAgent1 dem Broker schließlich als Antwort zusendet, enthält den gerade neu
eingefügten Bericht.
Erhält der QAgent1 vom Navigation-Agent (NavigationAgent, kurz: NAgent) (siehe
Abschnitt 8.2.6) eine Request Nachricht, führt er das CalculateDataBehaviour (Klasse
SimpleBehaviour) aus. Zunächst schickt er dem NAgent eine Agree Nachricht als
Bestätigung, dass er die angefragte Aufgabe übernimmt. Dann erarbeitet er für den
NAgent die geforderten zusätzlichen Metadaten über die in der Nachricht erhaltenen
Informationen. Zum Beispiel sucht der QAgent1 zu einer Information vom Informa-
tionstyp Kategorie (Category) (vgl. Abschnitt 7.2.2) die dazugehörige Dimension oder
zählt die Anzahl der Kategorien, die eine bestimmte Dimension umfasst. Die ermittelten
Zusatzinformationen schickt der QAgent1 schließlich dem NAgent in Form einer
Inform Nachricht zurück.
8.2.5 SearchAgent
Der SearchAgent (kurz: SAgent) ist ebenfalls vom Typ Funktionsagent. Er ist für die
Suche nach Berichten (Service „searching“) in den zur Verfügung stehenden Daten-
quellen verantwortlich. Dazu beauftragt er alle Agenten, die den Dienst query unter-
stützen (d. h. alle Agenten vom Typ QueryAgent), ihre Datenquellen nach Berichts-
sichten, die die in den übergebenen Parametern spezifizierten Informationen enthalten,
abzufragen. Die gefundenen Berichtssichten sammelt er und eliminiert eventuell aufge-
tretene Berichtsduplikate.
8 Beschreibung des Prototyps 100
Der SAgent umfasst drei Behaviour (siehe Abbildung 8-7). Mit dem Behaviour
ReceiveRequestBehaviour (Klasse CyclicBehaviour) ruft der SAgent seine Nachrich-
ten-Queue nach eingehenden Request Nachrichten vom Broker ab. Der Eingang einer
solchen Nachricht bedeutet für den SAgent, dass er den Auftrag erhalten hat, nach
Berichten zu suchen, die die in der Nachricht übermittelten Informationen beinhalten.
Er ruft daher das Verhalten SearchReportsBehaviour (Klasse SimpleBehaviour) auf.
Über das Verhalten RequestQueryAgentBehaviour (Klasse FSMBehaviour), das im
SearchReportsBehaviour aufgerufen wird, ermittelt der SAgent zunächst mit Hilfe des
Directory Facilitator Agenten alle Abfrage-Agenten, d. h. alle Agenten, die den Dienst
„query“ unterstützen. Allen gefundenen Abfrage-Agenten sendet er dann eine Request
Nachricht mit der Aufforderung, die eigene Datenquelle nach Berichtssichten zu durch-
suchen, die die im Nachrichteninhalt (Content) enthaltenen Daten beinhalten. Im Wei-
teren wartet er alle eingehenden Inform Nachrichten der Abfrage-Agenten ab und prüft
die von ihnen erhaltenen Berichtssichten auf Duplikate. Die Prüfung findet auf Basis
des Vergleichs der Kontextinformation (vgl. Abschnitt 6.2.4 und Abschnitt 7.2.2) zwi-
schen den Berichtssichten statt. Wenn der Kontext eines Berichtes mit einem anderen
übereinstimmt, wird dieser nicht mehr in die Ergebnis-Liste aufgenommen. Nach
Abschluss der Prüfung schickt der SAgent die Liste der Berichtssichten in einer Inform
Nachricht an den Broker.
Abb. 8-7: Behaviour-Klassen des SearchAgent
8.2.6 NavigationAgent
Bei dem Funktionsagent NavigationAgent (kurz: NAgent) handelt es sich um einen
Agenten des MSS-Assistenzsystems, der speziell für die Interaktion mit einem be-
stimmten MSS-Werkzeug konzipiert und implementiert wurde. Neben dem Wissen, wie
8 Beschreibung des Prototyps 101
er das MSS-Werkzeug ansprechen bzw. aufrufen kann, besitzt der NAgent Kenntnisse
über den Aufbau und die Gestaltbarkeit der mit dem MSS-Werkzeug erstellbaren MSS-
Informationen (z. B. Berichtssichten) und wie diese von dem MSS-Werkzeug präsen-
tiert werden. Auf Basis der Anwenderangaben - ergänzt um zusätzliche Daten - ist der
NAgent in der Lage, eine neue MSS-Information zu erzeugen, die dann mit dem MSS-
Werkzeug angezeigt werden kann (Service „navigation“).
Der NAgent des MSS-Assistenzsystems wurde für das OLAP-Werkzeug Cognos
PowerPlay (siehe Abschnitt 7.2.1) konzipiert. Die Entscheidung, den einen NAgent des
MSS-Assistenzsystems speziell für Cognos PowerPlay zu konfigurieren und nicht für
das zweite MSS-Werkzeug Cognos ReportNet (siehe Abschnitt 7.2.1), liegt darin
begründet, dass der Umgang mit OLAP-Werkzeugen und analytischen Berichten höhere
Anforderungen an die Anwender stellen (siehe Abschnitt 4.1) und daher ein erhöhter
Unterstützungsbedarf vorliegt.
Wie in Abschnitt 7.2.1 bereits beschrieben, können mit Cognos PowerPlay OLAP-
Berichte erstellt werden. Diese Berichte basieren auf einer Kreuztabellen-Struktur, in
der in den Zeilen und Spalten die Ausprägungen der gerade eingestellten Dimensionen
dargestellt werden und in den Zellen der Kreuztabelle die Werte der ausgewählten
Kennzahl stehen. Des Weiteren können über die Dimensionsleiste Filter eingestellt sein,
die die Daten auf bestimmte Merkmale beschränken.
Zur Definition der OLAP-Berichtssichten benutzt der NAgent so genannte Berichts-
templates. Ein Berichtstemplate setzt sich in dieser Arbeit vereinfacht aus einem Zeilen-
element (row), einem Spaltenelement (column) und einer Kennzahl (measure) zusam-
men, sowie optional aus einem oder mehreren Filterelementen (filter). Die Auswahl
eines passenden Berichtstemplates erfolgt im NAgent auch durch eine in JESS pro-
grammierte, regelbasierte Komponente (vgl. Abschnitt 7.1.2). Diese umfasst derzeit nur
eine Regel und zahlreiche Funktionen und Abfragen (Queries), über die aufgrund
spezifischer Daten-Charakteristika ein geeignetes Berichtstemplate abgeleitet wird. Die
Auswahl eines Berichtstemplates erfolgt einerseits auf Basis der Anzahl an
Dimensionen und Kennzahlen, die in den Benutzerangaben enthalten sind bzw. die
daraus hergeleitet werden konnten, andererseits aber auch auf Basis der Anzahl der
Kategorien, die die einzelnen Dimensionen umfassen. Das Berichtstemplate A wird bei-
spielsweise immer dann ausgewählt, wenn in den Benutzerangaben mindestens zwei
Dimensionen, höchstens eine Kennzahl und keine oder beliebig viele Filtermerkmale
8 Beschreibung des Prototyps 102
enthalten sind. In der aus dem Template A hergeleiteten Berichtssicht wird dann die
Dimension mit der höchsten Kategorienanzahl in den Zeilen und die Dimension mit der
geringsten Kategorienanzahl in den Spalten dargestellt. Die Wissensbasis des NAgent
unterscheidet insgesamt vier verschiedene Berichtstemplates (siehe Tabelle 8-3).
Anzahl Berichtstemplate Dimensionen Kennzahlen Filter
Template A (row=maxDim, column=minDim) >=2 <=1 >=0 Template B =1 <=1 >=0 Template C =0 <=1 >=0 Template D >=1
Tab. 8-3: Berichtstemplates des NavigationAgent
Wie die Abbildung 8-8 zeigt, besitzt der NAgent die drei Behaviour ReceiveMessage-
Behaviour (Klasse CyclicBehaviour), RequestQueryAgentBehaviour (Klasse Simple-
Behaviour) und GenerateReportBehaviour (Klasse SimpleBehaviour).
Abb. 8-8: Behaviour-Klassen des NavigationAgent
Über das ReceiveMessageBehaviour ruft der NAgent seine Nachrichten-Queue nach
eingehenden Nachrichten ab und führt in Abhängigkeit des Nachrichtensenders ein be-
stimmtes Verhalten aus. Beim Erhalt einer Request Nachricht vom Broker kommt z. B.
das RequestQueryAgentBehaviour zur Ausführung. Darüber schickt der NAgent dem
QueryAgent1 eine Request Nachricht mit dem Auftrag, ihm weitere Metadaten aus der
MSS-Metadatenbasis über die ihm vorliegenden Daten zu liefern (Service „metadata“).
Erhält der NAgent dagegen eine Inform Nachricht vom QueryAgent1, so wird das
GenerateReportBehaviour ausgeführt. Aus den vom QueryAgent1 erhaltenen statis-
tischen Angaben ermittelt der NAgent ein geeignetes Berichtstemplate, das den Aufbau
des Berichtes vorgibt. Die Templateinformationen bilden die Linkinformation der neu
8 Beschreibung des Prototyps 103
erzeugten Berichtssicht. Den neuen Bericht schickt der NAgent dann mittels einer
Inform Nachricht an den Broker zurück.
8.3 Koordination des BrokerAgent
Da der Vermittlungsagent Broker für die Planung und Steuerung der Bearbeitung der
Anwenderanfrage verantwortlich ist und somit eine zentrale Rolle im Multi-Agenten-
system des MSS-Assistenzsystems spielt, wird das generelle Systemverhalten, d. h. das
Zusammenspiel der Agenten, im Folgenden noch einmal zusammenfassend anhand
seiner Aktivitäten erläutert. Wie in Abbildung 8-9 dargestellt, beginnen die Aktivitäten
des Broker mit dem Erhalt einer Request Nachricht vom Assistant. Im ersten Schritt
überprüft er, ob es sich bei der eingegangenen Request Nachricht um eine neue Anfrage
(Task) des Anwenders handelt (d. h. der Nachrichtenparameter Conversation-Id ist
ungleich CONFIRMATION) oder ob es die Aufforderung zur Fortsetzung einer bereits
begonnenen Anfragenbearbeitung ist (d. h. der Nachrichtenparameter Conversation-Id
ist gleich CONFIRMATION). Entspricht die Nachricht einer neuen Anfrage, so ant-
wortet der Broker dem Assistant mit einer Agree Nachricht und teilt ihm so mit, dass er
die Anfrage bearbeiten wird. Im nächsten Schritt analysiert der Broker zuerst die Daten
des Anwenders und prüft, ob diese Daten so oder in ähnlicher Form und Schreibweise
in der MSS-Metadatenbasis enthalten sind (Behaviour ParseUserInput). Alle gefunde-
nen Übereinstimmungen sammelt er schließlich in einer Liste. Der darauffolgende
Schritt des Brokers sieht die Ermittlung einer zur Lösung der Fragestellung geeigneten
Strategie vor (Funktion chooseStrategie). Durch das Hinzufügen des Tasknamen als
Faktwert in seine Wissensbasis leitet der Broker eine für die Task geeignete Strategie
aus dem vorliegenden Set von Standardstrategien her. Die in der ermittelten Strategie
angegebene Reihenfolge an Diensten in der Slot-Variable services liest der Broker aus
und arbeitet sie mit dem Behaviour RequestFunctionAgents schrittweise ab. Als erstes
ruft er den Namen des Dienstes an der Stelle Step (zu Beginn mit 0 initialisiert) aus der
Liste ab und befragt den Directory Facilitator Agenten nach allen Agenten, die diesen
Dienst bereitstellen. Den vom Directory Facilitator Agenten gefundenen Funktionsagen-
ten schickt der Broker dann eine Request Nachricht mit den Daten des Anwenders bzw.
mit bereits modifizierten Informationen. Die Aktivität des Brokers ruht schließlich so-
lange, bis er von den Funktionsagenten eine Inform Antwortnachricht erhält. Ist dies der
Fall, prüft der Broker, ob die von der Strategie vorgegebenen Funktionen alle abgear-
8 Beschreibung des Prototyps 104
beitet wurden, d. h. der letzte Dienst aus der Liste gerade ausgeführt wurde (current-
Step=maxStep), oder ob ein weiterer Dienst in der Liste steht, der als nächstes ausge-
führt werden muss. Im Fall, dass kein weiterer Dienst in der Liste steht (cur-
rentStep=maxStep), schickt der Broker dem Assistant eine Inform Nachricht mit den
von den Funktionsagenten erarbeiteten Ergebnisdaten. Stehen noch ein oder mehrere
weitere Dienste in der Liste, führt der Broker erneut das Behaviour RequestFunction-
Agents aus, wobei er dieses Mal allen Agenten eine Request Nachricht mit den zu bear-
beitenden Daten schickt, die den Dienst an der Stelle currentStep+1 besitzen.
Abb. 8-9: Arbeitsweise des BrokerAgent
8 Beschreibung des Prototyps 105
Bei der Abarbeitung der in einer Strategie vorgesehenen Dienste kann es in zwei Situa-
tionen beim Broker zu einer Unterbrechung kommen, und zwar bei der Bearbeitung der
beiden Tasks COMPREHENSIVESEARCH und NAVIGATION. Falls in diesen beiden
Fällen der Broker vom InterpretationAgent als Ergebnis keine eindeutigen Zuordnungen
der vom Anwender eingegebenen Daten zu den Daten in der MSS-Metadatenbasis
erhält, schickt er dem Assistant die mehrdeutigen Daten in einer Inform Nachricht (mit
dem Nachrichtenparameter Conversation-Id gleich CONFIRMATION gesetzt) zurück,
mit dem Hinweis, dass der Anwender nochmals eine exaktere Auswahl bezüglich der
Stichwörter treffen muss. Per Dialog stellt der Assistant dem Anwender die alternativen
Benennungen, die in der MSS-Metadatenbasis gefunden wurden, zur Auswahl zur Ver-
fügung. Nachdem der Anwender seine Auswahl abgeschlossen und die Fortführung der
Bearbeitung angestoßen hat, sendet der Assistant dem Broker erneut eine Request
Nachricht, nun mit den eindeutigen Begriffen, und fordert die Weiterbearbeitung der
Anwenderanfrage. Da es sich in diesem Fall um keine neue Anfrage handelt, sondern
um eine die schon bearbeitet wird, muss der Broker dieses Mal keine Analyse der Daten
vornehmen und auch keine neue Strategie ermitteln, sondern er führt einfach den
nächsten Schritt aus, d. h. er beauftragt die Agenten mit der Funktion an der Stelle cur-
rentStep+1.
9 Einsatz des implementierten MSS-Assistenzsystems
9.1 Übersicht der Anwendungsfälle
Die Einsatzmöglichkeiten des implementierten Multi-Agentensystems zur Unterstüt-
zung des Anwenders beim Arbeiten mit MSS-Werkzeugen sollen im Folgenden anhand
dreier Anwendungsfälle beschrieben werden. Bei den Anwendungsfällen handelt es sich
um die bei der Analyse des MSS-Unterstützungsbedarfs in Abschnitt 4.2 identifizierten
Unterstützungsfälle. Dazu gehören:
- die MSS-Werkzeug-übergreifende Suche nach Informationen,
- die Suche nach Zusatzinformationen über ganz bestimmte Informationen, sowie
- die automatische Generierung neuer bzw. modifizierter Informationen, z. B. in Form
einer neuen, angepassten Berichtssicht.
Je Anwendungsfall erfolgt zunächst eine Beschreibung der konkreten Fallsituation, d. h.
der Problem- bzw. Fragestellung, die der Anwender gerade zu lösen hat. Es wird das
konkrete Problem dargestellt, auf welches der Anwender in dieser Fallsituation stoßen
kann. Anschließend wird darauf eingegangen, welche Funktion (Task) des entwickelten
Prototyps in dieser Situation dem Anwender die beste Unterstützung bietet und wie
diese Unterstützung aussieht. Es wird dabei detailliert beschrieben, wie das System vor-
geht, d. h. die Agenten zusammenarbeiten, um dem Anwender eine geeignete Lösung
zu präsentieren.
Im Abschnitt 9.3 wird schließlich auf Basis der Beschreibungen der Anwendungsfälle
eine Bewertung des Prototyps durchgeführt. Es wird dabei beurteilt, inwiefern und in
welchem Umfang der Prototyp eine Unterstützung leistet und wie die Unterstützung in
weiteren Entwicklungsstufen des Agentensystems verbessert werden kann.
9.2 Anwendungsfälle
9.2.1 Fall 1: MSS-Werkzeug-übergreifende Informationssuche
Im Fall 1 der MSS-Werkzeug-übergreifenden Informationssuche benötigt der Anwen-
der Informationen für eine bestimmte Managementaufgabe, z. B. zur Vorbereitung für
Berufungs- oder Bleibeverhandlungen (siehe Abschnitt 3.3) bzw. für eine Senats- oder
Kommissionssitzung. Aus der Vielzahl unterschiedlicher Informationsquellen (Doku-
mente, Standardberichte, analytische Berichte usw.), die ihm zur Verfügung stehen und
die (zumeist) über unterschiedliche MSS-Werkzeuge bereitgestellt werden, muss er die
9 Einsatz des implementierten MSS-Assistenzsystems 107
für den aktuellen Sachverhalt relevanten Informationen ausfindig machen und zusam-
mentragen. Da der Anwender in den seltensten Fällen genau weiß, in welchen Informa-
tionsquellen er nach den benötigten Daten suchen muss bzw. welche Informationsquel-
len relevante Daten enthalten und wo er diese Informationsquellen finden und abrufen
kann [vgl. MeRi01a, S. 106], gestaltet sich die Informationsbeschaffung bzw. der
Informationsbeschaffungsprozess häufig zu einer aufwendigen und zeitraubenden Auf-
gabe.
Das MSS-Assistenzsystem1 kann dem Anwender in diesem Fall durch seine MSS-
Werkzeug-übergreifende Informationssuche, die im Wesentlichen durch die Such-
Agenten auf den verschiedenen (Meta-)Datenbanken erfolgt, eine Unterstützung bieten.
Dazu muss der Anwender das MSS-Assistenzsystem starten und aus dem Tasks-Menü
des Prototyps die Task „Comprehensive Search“ auswählen (siehe Abbildung 9-1).
Abb. 9-1: Aufbau des Tasks-Menü des MSS-Assistenzsystems
Über das Dialog-Fenster (siehe Abbildung 9-2), das sich nach dem Aufruf der Task
„Comprehensive Search“ öffnet, wird der Anwender aufgefordert, stichwortartig die
gesuchten Informationen zu seiner Frage- bzw. Problemstellung zu beschreiben und in
einem Texteingabefeld (jeweils mit einem Semikolon getrennt) einzugeben. Mit der
Check-Box „exactly search“ kann der Anwender zusätzlich festlegen, ob die von ihm
1 Das Funktionsspektrum des MSS-Assistenzsystems umfasst zur Zeit die drei Funktionen „Search
Informations“, „Access Metadata“ und „Generate OLAP Report“, die über den Menüpunkt Tasks auf-gerufen werden können. Bei der Funktion „Search Informations“ werden zwei verschiedene Varianten der Informationssuche angeboten und zwar „Comprehensive Search“ (entspricht der MSS-Werkzeug-übergreifenden Informationssuche) und „OLAP Search“ (entspricht der spezialisierten Suche nach ana-lytischen (OLAP-)Berichten).
9 Einsatz des implementierten MSS-Assistenzsystems 108
angegebenen Stichwörter bei der Suche genau in der Schreibweise verwendet oder ob
ähnliche Ausdrücke der Stichwörter ebenfalls bei der Suche berücksichtigt werden sol-
len. Eine Deaktivierung der Check-Box bietet sich immer dann an, wenn der Anwender
die genaue Benennung bzw. Schreibweise der relevanten Merkmale nicht kennt.
Abb. 9-2: Dialogfenster der Task „Comprehensive Search“
Sucht der Anwender beispielsweise Informationen zu der Fragestellung „Wie verteilen
sich die ausländischen Studierenden (Kennzahl Fachfälle), die weder beurlaubt noch
exmatrikuliert sind, je Geschlecht auf die einzelnen Fachbereiche für das Sommer-
semester 2007?“, so könnte eine stichwortartige Beschreibung dieser Fragestellung wie
folgt aussehen: „fach; geschlecht; ausländer; nicht-beurlaubt; nicht-exmatrikuliert; ss
2007; fachfälle;“. Im Fall der Bleibeverhandlung, wo der Dekan unterschiedliche Infor-
mationen über den Professor benötigt, wie z. B. über seine Lehr- und Forschungstätig-
keiten und seine bereits zugewiesenen Personal- und Raum-Ressourcen, könnten die
Stichwörter wie folgt gewählt werden: „anzahl; wissenschaftliche mitarbeiter; ausstat-
tung; lehrveranstaltungen; klausuren; professor heinemann; seminar; diplomarbeit; for-
schungsprojekte;“.
Die Bearbeitung der Suchanfrage wird durch das Klicken auf den Start Search-Button
gestartet. In dem Fall, dass die angegebenen Stichwörter nicht genau einem bestimmten
Merkmal in der MSS-Metadatenbasis zugeordnet werden können oder mehrere Über-
einstimmungen dort vorliegen, wird der Anwender über einen weiteren Dialog dazu
aufgefordert, eine Auswahl seiner Merkmale aus den gefundenen Metadaten zu treffen.
Wie in der Abbildung 9-3 zu sehen, bietet der Dialog über eine Auswahlbox dem An-
wender die Möglichkeit, eines seiner Stichwörter auszuwählen, um sich dann in der dar-
unter stehenden Liste alle zu dem selektierten Stichwort gefundenen Werte aus der
MSS-Metadatenbasis anzeigen zu lassen. Zu jedem selektierten Wert aus der Liste wird
dem Anwender eine Beschreibung präsentiert, die ihm nähere Auskunft über den Be-
griff gibt, wie z. B. um welchen Informationstyp (Dimension, Category, Level, Cube,
9 Einsatz des implementierten MSS-Assistenzsystems 109
Measure, Data Item, Perspective, Goal, usw.) (vgl. Abschnitt 7.2.2) es sich bei dem
Begriff handelt. Gemäß den Beschreibungen kann der Anwender jetzt die Merkmale aus
der Liste auswählen und in die darunter stehende Liste überführen, die zur Beschrei-
bung seiner Fragestellung am ehesten geeignet sind. Nach der Auswahl aller für die
gerade betrachtete Fragestellung relevanten Merkmale wird durch Klicken des Continue
Task-Button die Bearbeitung der Suchanfrage fortgesetzt.
Abb. 9-3: Dialogfenster der Anwenderrückfrage
Wenn zu den Angaben des Anwenders passende Informationen in den Datenbanken
gefunden werden, werden ihm diese in einem Browserfenster (siehe Abbildung 9-4)
präsentiert. Gefundene Berichte bzw. Berichtssichten werden dabei gemäß der Häufig-
keit der Übereinstimmungen zwischen den Anwenderangaben und den jeweiligen
Berichtskontexten aufgelistet. Je Bericht werden die Berichtsbezeichnung und eine
Beschreibung über den Inhalt und/oder Zweck des Berichtes dargestellt, sowie ein Link
zum Aufrufen des Berichtes angeboten. Zusätzlich wird noch die Datenquelle (z. B. der
9 Einsatz des implementierten MSS-Assistenzsystems 110
Datenwürfel), auf der die Berichte basieren und eine Beschreibung je Anfrage-Merkmal
im Ergebnisfenster dargestellt.
Abb. 9-4: Präsentation der Ergebnisse der Task „Comprehensive Search“
Im Gegensatz zu der Task „Comprehensive Search“, bei der der Anwender eine freie
Eingabe der für die Fragestellung relevanten Merkmale spezifizieren und eine MSS-
Werkzeug-übergreifende Suche über alle Informationstypen und -quellen vornehmen
kann, wird über die Task „OLAP Search“ dem Anwender die Möglichkeit geboten, eine
Suche speziell nur nach analytischen Berichten bzw. Berichtssichten durchzuführen.
Wie in Abbildung 9-5 zu sehen, umfasst hier die Definition einer Berichtssicht die
Auswahl eines Datenwürfels (Cube), die Auswahl einer Kennzahl (Measure) und die
Selektion eines oder mehrerer Merkmale (Dimensionen).
Je nachdem welchen Datenwürfel der Anwender selektiert, werden nur noch die dazu-
gehörigen Kennzahlen und Dimensionen zur Auswahl angeboten. Des Weiteren wird zu
jedem selektierten Element eine Beschreibung angezeigt. Ebenso wie bei der Task
„Comprehensive Search“ wird hier über den Start Search-Button die Bearbeitung der
Suchanfrage ausgelöst und die Ergebnisse, d. h. die gefundenen analytischen Berichte
dem Anwender im Browserfenster präsentiert (siehe Abbildung 9-4).
9 Einsatz des implementierten MSS-Assistenzsystems 111
Abb. 9-5: Dialogfenster der Task „OLAP Search“
Die systeminternen Abläufe des MSS-Assistenzsystems während der Suchanfrage, d. h.
der Nachrichtenaustausch, der zwischen den Agenten stattfindet, ist in der Abbildung 9-
6 in einem UML-Sequenz-Diagramm dargestellt.
9 Einsatz des implementierten MSS-Assistenzsystems 112
Abb. 9-6: Nachrichtenaustausch bei der Task „Comprehensive Search“
Neben dem Broker und dem Assistant Agent kommen bei dieser Task vier Funktions-
agenten zum Einsatz. Nachdem der Broker die Angaben des Anwenders analysiert hat,
beauftragt er als erstes den Interpretation Agent (IPAgent) die Daten zu interpretieren
und zu typisieren. Um herauszufinden, um was für einen Informationstyp es sich bei
den Angaben des Anwenders handelt, also ob es ein OLAP-Merkmal (wie z. B. Dimen-
sion, Category, Measure usw.) oder ob es einfach ein Standard-Berichtsmerkmal (Data
item) ist, greift der IPAgent auf die MSS-Metadatenbasis zu, die diese Informationen
beinhaltet. Mit den vom IPAgent ermittelten Ergebnissen kann nun eine genauere Such-
anfrage an den Search Agent (SAgent) gestellt werden. Je nachdem welche Informa-
tionen gesucht werden, beauftragt er die speziellen Query Agents (QAgent), in ihren
Datenbanken nach den Informationen zu suchen. Ein Query Agent sucht beispielsweise
nur nach analytischen Berichten, ein anderer befragt seine Datenbank nach Standard-
berichtssichten, die die Angaben des Anwenders in ihrer Kontext-Beschreibung bein-
halten. Die von den Query Agents erhaltenen Ergebnisse werden schließlich vom
Search Agent gesammelt und dann an den Broker übermittelt, der sie wiederum an den
Assistant weiterleitet. Der Assistant bereitet die Informationen auf und präsentiert sie
dem Anwender zur Auswahl.
9 Einsatz des implementierten MSS-Assistenzsystems 113
9.2.2 Fall 2: Metadatensuche
Bei diesem Fall (der Metadatensuche) geht es darum, die inhaltliche Aussage eines Be-
richts korrekt zu identifizieren. Dies ist insbesondere dann notwendig, wenn es sich um
einen für den Anwender neuen oder nur gelegentlich (monatlich) genutzten Bericht
handelt. Um die für ihn gerade relevanten Informationen aus dem Bericht abzulesen,
muss der Anwender sich zunächst den gesamten Berichtskontext erarbeiten. Das be-
deutet er muss herausfinden, welche Informationen in der Berichtssicht dargestellt sind,
welche Daten welche Merkmale repräsentieren, welche Dateneinschränkungen (Filter)
eventuell vorgenommen wurden, was die dargebotenen Kennzahlen ausdrücken und wie
sie berechnet wurden. Da es in den meisten Fällen zu einer Berichtssicht keine detail-
lierte inhaltliche Dokumentation gibt und keine Beschreibungen über die enthaltenen
Auswertungsmerkmale vorliegen, die vom Anwender bei Bedarf direkt aus dem Be-
richtskontext abgerufen werden können, muss der Anwender sich für die Berichts-
auswertung intensiv und zeitaufwendig mit der Berichtssicht auseinandersetzen. Even-
tuell sind umfangreiche persönliche Recherchen/Nachfragen bei Experten notwendig.
Die richtige Interpretation eines Berichtes wird zumeist dadurch erschwert, dass die
Bezeichnungen der dargestellten Merkmale abgekürzt wurden (z. B. FB für Fachbe-
reich) oder speziellen Fachtermini aus der Anwendungsdomäne entsprechen (z. B. Bil-
dungsinländer: kennzeichnet alle Ausländer, die ihre Hochschulzugangsberechtigung in
Deutschland erworben haben), die ein fachfremder Anwender nicht kennt bzw. deren
Bedeutung einem gelegentlichen Anwender entfallen sein können.
In diesen Fällen, in denen der Anwender Zusatzinformationen über gewisse Daten be-
nötigt, wie z. B. die Langbezeichnung einer Abkürzung, die Definition eines Merkmals
oder die Berechnungsformel einer Kennzahl, stellt das MSS-Assistenzsystems dem
Anwender eine Unterstützung über die Task „Access Metadata“ zur Verfügung.
Über den in Abbildung 9-7 dargestellten Dialog gibt der Anwender den ihm unbekann-
ten Begriff ein und lässt das MSS-Assistenzsystem in seiner MSS-Metadatenbasis nach
einer Beschreibung zu dem Begriff suchen. Es werden dem Anwender dabei alle aus der
MSS-Metadatenbasis gefundenen Übereinstimmungen in einer Liste präsentiert. Durch
Selektion eines Elementes in der Liste wird dem Anwender unterhalb der Liste die
dazugehörige Beschreibung angezeigt.
9 Einsatz des implementierten MSS-Assistenzsystems 114
Abb. 9-7: Dialogfenster der Task „Access Metadata“
Zusätzlich zum reinen Abruf einer Beschreibung eines Merkmals kann der Anwender
über diesen Dialog auch noch nach Berichten bzw. Berichtssichten, die bestimmte
Merkmale umfassen, suchen. Dazu wählt er aus den gefundenen Merkmalen zu seinen
gesuchten Begriffen die aus, die für seine Fragestellung relevant sind und sammelt sie
in der darunter aufgeführten Liste. Über den Search Reports-Button kann dann die Be-
richtssuchanfrage gestartet werden. Die vom MSS-Assistenzsystem gefundenen Be-
richte werden dem Anwender wie üblich im Browserfenster präsentiert.
Der Nachrichtenaustausch der zwischen den Agenten des MSS-Assistenzsystems bei
der Ausführung der Task „Access Metadata“ stattfindet, ist in der Abbildung 9-8 dar-
gestellt.
9 Einsatz des implementierten MSS-Assistenzsystems 115
Abb. 9-8: Nachrichtenaustausch bei der Task „Access Metadata“
Über die Dialogeingabe erhält der Assistant Agent vom Anwender den Begriff, für den
Zusatzinformationen aus der MSS-Metadatenbasis gesucht werden sollen. Diese Infor-
mation schickt er an den Broker, der nach der Analyse den Interpretation Agent akti-
viert. Der Interpretation Agent interpretiert die Information und ermittelt die in der
MSS-Metadatenbasis vorliegenden Zusatzinformationen über den Begriff des Anwen-
ders. Die gefundenen Informationen schickt der Interpretation Agent an den Broker
zurück, der die Informationen dann an den Assistant weiterreicht. Der Anwender be-
kommt die Beschreibung zu seinem Begriff schließlich im Dialogfenster angezeigt.
Der Nachrichtenaustausch, der beim Suchen nach Berichten bzw. Berichtssichten auf
Basis der in der Liste gesammelten Merkmale stattfindet, ist in der Abbildung 9-8 nicht
dargestellt, da die Abläufe denen in der Abbildung 9-6 entsprechen.
9.2.3 Fall 3: Automatische Informationsgenerierung
In diesem Fall (der automatischen Informationsgenerierung) hat der Anwender wieder
die Aufgabe erhalten, Informationen über einen bestimmten Sachverhalt (z. B. „Wie
verteilen sich die ausländischen Studierenden (Kennzahl Fachfälle), die weder beurlaubt
noch exmatrikuliert sind, je Geschlecht auf die einzelnen Fachbereiche für das Sommer-
semester 2007?“) zusammenzutragen. Dazu durchsucht er zunächst den Informations-
pool existierender Berichte nach einem zur Beantwortung der Fragestellung geeigneten
Bericht. Die Informationssuche (vgl. Fall1) hat jedoch keinen passenden Bericht gefun-
den, so dass der Anwender selbst einen neuen Bericht erstellen muss. Der Ablauf ohne
Assistenzsystem wäre nun wie folgt: Da zumeist mehrere Datenwürfel vorliegen, von
denen auch einige ähnliche Dateninhalte enthalten, muss der Anwender zuerst den rich-
tigen Datenwürfel für die Fragestellung identifizieren. Ist der passende Datenwürfel
9 Einsatz des implementierten MSS-Assistenzsystems 116
gefunden worden, wird der Würfel mit dem dazugehörigen MSS-Werkzeug geöffnet. In
der Regel wird dem Anwender nach dem Öffnen eine Standardberichtssicht präsentiert,
die in den seltensten Fällen schon die Informationen anzeigt, die zur Beantwortung
einer Fragestellung benötigt werden. Daher muss der Anwender mit dem MSS-Werk-
zeug arbeiten und die Berichtssicht seiner Fragestellung entsprechend anpassen. Dies
setzt voraus, dass der Anwender einerseits Wissen über die dargestellten Inhalte des
Datenwürfels hat, andererseits aber auch Kenntnisse im Umgang mit dem MSS-Werk-
zeug besitzt, also weiß, wie die Einstellungen im Bericht, wie z. B. die angezeigten
Auswertungsmerkmale und die Filter, geändert werden können. Für einen Anwender,
der nur gelegentlich mit dem MSS-Werkzeug arbeitet und somit nicht so geübt im Um-
gang mit dem Werkzeug ist, stellt dies jedes Mal eine neue Herausforderung dar.
In diesem Fall bietet das MSS-Assistenzsystem über die Task „Generate OLAP Report“
eine Unterstützung. Der Anwender kann über diese Task eine neue analytische
Berichtssicht erzeugen lassen. Die Eingabe der Merkmale, die die Berichtssicht bein-
halten soll, erfolgt dabei wie bei der Task „Comprehensive Search“ in Form von Stich-
wörtern. Die Abbildung 9-9 zeigt das Dialogfenster, über das der Anwender seine
Angaben spezifiziert.
Abb. 9-9: Dialogfenster der Task „Generate OLAP Report“
Das MSS-Assistenzsystem prüft (äquivalent zu der Task „Comprehensive Search“) zu-
nächst wieder, ob zu den angegebenen Stichwörtern Übereinstimmungen in der MSS-
Metadatenbasis vorliegen. Falls die Begriffe eindeutig Merkmalen in der MSS-Meta-
9 Einsatz des implementierten MSS-Assistenzsystems 117
datenbasis zugeordnet werden können, ermittelt das System aus den Angaben zunächst
den geeigneten Datenwürfel. Auf Basis des Datenwürfels wird dann ein möglicher Be-
richtsaufbau evaluiert. Der Link zum Zugriff auf den Bericht wird schließlich definiert
und dem Anwender zur Auswahl im Dialogfenster angeboten. Für den Fall, dass die
Begriffe nicht eindeutig einem Begriff in der MSS-Metadatenbasis zugewiesen werden
können, findet auch hier über den in der Abbildung 9-3 dargestellten Dialog eine Rück-
frage beim Anwender statt (siehe Abschnitt 9.2.1).
Den in der Liste aufgeführten neuen Bericht kann sich der Anwender durch Selektion
des Berichtes und Klicken auf den Open Report-Button anzeigen lassen. Dabei ruft das
MSS-Assistenzsystem das MSS-Werkzeug auf und übergibt ihm den erarbeiteten Be-
richtskontext. Der neu erzeugte Bericht wird dem Anwender dann im Browserfenster
präsentiert (siehe Abbildung 9-10).
Abb. 9-10: Beispiel einer mittels „Generate OLAP Report“ erzeugten Berichtssicht
Wenn der Anwender den neuen Bericht zur Beantwortung seiner Fragestellung als ge-
eignet beurteilt, hat er über den Button Save Report die Möglichkeit, die Berichtssicht
in der MSS-Metadatenbasis zu speichern, so dass er jederzeit wieder auf die Berichts-
sicht zurückgreifen bzw. nach der Berichtssicht suchen kann. Nach dem Klicken auf
den Button öffnet sich das in der Abbildung 9-11 dargestellte Dialogfenster, über das
9 Einsatz des implementierten MSS-Assistenzsystems 118
der Anwender die Möglichkeit hat, einige der Metadaten des neuen Berichtes, konkret
dessen Namen und die Beschreibung, zu editieren. Bei dem im Beschreibungsfeld
bereits gesetzten Text handelt es sich um einen Vorschlag, der seitens des MSS-Assis-
tenzsystems automatisch aus dem Berichtskontext generiert wird und den der Anwender
gemäß seinen Anforderungen anpassen und ergänzen kann.
Abb. 9-11: Dialogfenster zum Editieren der Metadaten eines neuen OLAP-Berichtes
Die internen Kommunikationsabläufe des MSS-Assistenzsystems, die im Rahmen der
Task „Generate OLAP Report“ ausgeführt werden, zeigt die Abbildung 9-12. Wie auch
bei den anderen Tasks, informiert der Assistant Agent zunächst den Broker über die neu
eingegangene Anfrage des Anwenders und übergibt dem Broker gleichzeitig die An-
wenderangaben. Die vom Broker evaluierte Strategie zur Bearbeitung der Anfrage sieht
im ersten Schritt vor, dass der Interpretation Agent die Angaben des Anwenders inter-
pretiert und um weitere und genauere Informationen aus der MSS-Metadatenbasis er-
gänzt. Die vom Interpretation Agent erhaltenen Informationen sendet der Broker
schließlich dem Navigation Agent (NAgent) zu, mit dem Auftrag einen neuen Bericht
zu erstellen. Für die Generierung der Berichtssicht benötigt der Navigation Agent je-
doch weitere Informationen, so dass er den Query Agent der MSS-Metadatenbasis
selbst noch einmal beauftragt, ihm weitere Informationen, wie z. B. die Anzahl an Ka-
9 Einsatz des implementierten MSS-Assistenzsystems 119
tegorien je Dimension zu liefern. Erst mit den vom Query Agent zusätzlich erhaltenen
Informationen ist es dem Navigation Agent möglich, ein geeignetes Berichtstemplate zu
evaluieren und dieses mit den ermittelten Werten zu belegen. Als Ergebnis übermittelt
der Navigation Agent dem Broker den Berichtslink, den dieser an den Assistant weiter-
leitet. Der Assistant Agent stellt dem Anwender schließlich den Bericht im Dialogfens-
ter zur Auswahl zur Verfügung.
Abb. 9-12: Nachrichtenaustausch bei der Task „Generate OLAP Report“
Für das Speichern der neuen Berichtssicht wird nur der Query Agent der MSS-Meta-
datenbasis beansprucht. Der vom Assistant Agent informierte Broker übergibt die Be-
richtsspezifikation an den Query Agent (QAgent1), damit dieser den Bericht und seine
Metadaten in der MSS-Metadatenbasis speichern kann.
9.3 Bewertung des Prototyps
Das agentenbasierte MSS-Assistenzsystem in seiner jetzigen Form bietet dem Anwen-
der eine gute Unterstützung bei der MSS-Werkzeug-übergreifenden Informationssuche
(siehe Abschnitt 9.2.1) sowie bei der Suche nach Zusatzinformationen (siehe Abschnitt
9.2.2). Schon auf Basis eines bzw. einiger weniger Stichwörter, die der Anwender über
die Eingabe in einem Textfeld an das Agentensystem übergibt, können dem Anwender
9 Einsatz des implementierten MSS-Assistenzsystems 120
eine Vielzahl unterschiedlicher Informationen zu den Stichwörtern präsentiert werden.
Dies natürlich nur unter der Voraussetzung, dass die MSS-Metadatenbasis ausreichend
mit Metadaten des betreffenden/gefragten Sachverhalts befüllt ist. Sowohl bei der Task
„Comprehensive Search“ als auch bei der Task „Access Metadata“ muss der Anwender
nur einmal seine Suchanfrage spezifizieren. Alle verfügbaren Datenquellen werden
dann nach Informationen zu der Anfrage durchsucht, die Ergebnisse gesammelt und
dem Anwender dargeboten; eventuell unterschiedliche Kommunikationsschnittstellen
der Datenquellen werden vom MSS-Assistenzsystem bewältigt/harmonisiert. Über die
Task „OLAP Search“ wird dem Anwender eine auf analytische Berichte spezialisierte
Suchfunktion zur Verfügung gestellt. Nach Auswahl des Datenwürfels, für den der An-
wender Berichte sucht, werden die anderen zur Auswahl stehenden Selektionsmerkmale
(Dimensionen und Kennzahlen) auf die für den Datenwürfel relevanten Merkmale
eingeschränkt. Damit wird verhindert, dass der Anwender bei der Spezifikation seiner
Anfrage Merkmale, die verschiedenen Sachverhalten und damit unterschiedlichen
Datenwürfeln angehören, miteinander vermischt. Dadurch wird die Suche präziser und
zielgenauer, so dass auch die Suchergebnisse eine höhere Relevanz und dadurch eine
bessere Qualität besitzen.
Die vom Prototyp bereitgestellte Unterstützung bei der automatischen Generierung von
neuen bzw. modifizierten Informationen, wie z. B. einer neuen analytischen (OLAP-)
Berichtssicht (siehe Abschnitt 9.2.3) weist noch eine Reihe von Erweiterungspoten-
zialen auf. Die mittels der Task „Generate OLAP Report“ automatisch generierten
Berichtssichten besitzen zurzeit nur einen sehr vereinfachten Aufbau, bestehend aus
einer Kreuztabelle, die genau ein Zeilenelement und ein Spaltenelement umfasst. Eine
komplexe analytische Berichtssicht, die zumeist einen höheren Informationsgehalt
bietet, dadurch dass gleich mehrere Dimensionen verschachtelt in den Zeilen und/oder
Spalten dargestellt werden, kann bislang mittels des Prototyps nicht erstellt werden.
Insgesamt ist die Leistungsfähigkeit, d. h. die Höhe des Unterstützungspotenzials, des
Prototyps von den folgenden Aspekten direkt oder indirekt abhängig:
- dem Datenmodell und dem Inhalt der MSS-Metadatenbasis,
- der Zahl durch spezifische Agenten unterstützten MSS-Werkzeuge und
- dem zur Verfügung stehenden Funktionsumfang eines Agenten bzw. des Agenten-
systems insgesamt.
9 Einsatz des implementierten MSS-Assistenzsystems 121
In die MSS-Metadatenbasis wurden bisher nur die Metadaten von zwei MSS-Werkzeu-
gen, die unterschiedlichen Produktarten (OLAP-Werkzeug und Berichtsgenerator)
angehören, überführt und dadurch vereinheitlicht. Um das zugrunde liegende Daten-
modell der MSS-Metadatenbasis als ein generisches Modell zu evaluieren, müssen die
Metadaten und -strukturen weiterer MSS-Werkzeuge in die einheitliche Struktur der
MSS-Metadatenbasis eingebunden werden. Hierfür sollten sowohl MSS-Werkzeuge der
gleichen Produktart, aber verschiedener Hersteller, als auch MSS-Werkzeuge einer
anderen Produktart (z. B. ein Balanced Scorecard-Werkzeug) verwendet werden. Neben
dem Datenmodell, d. h. der Struktur und Organisation der Metadaten, spielen noch
stärker die Dateninhalte der MSS-Metadatenbasis eine entscheidende Rolle im Hinblick
auf die Brauchbarkeit des agentenbasierten MSS-Assistenzsystems. Denn nur wenn alle
relevanten Metadaten in der erforderlichen Qualität und Aktualität in der MSS-Meta-
datenbasis vorliegen, können sie dem Anwender eine Unterstützung bei der Bearbeitung
seiner Fragestellungen bieten. Eine Kernaufgabe bei der Betreuung des agentenbasier-
ten MSS-Assistenzsystems wird/muss daher in der Wartung und Pflege der MSS-
Metadatenbasis (über die hierzu entwickelten Clients resp. Extraktoren (vgl. Abschnitt
7.2.3)) liegen.
Das Potenzial des agentenbasierten MSS-Assistenzsystems wird erst durch die Anbin-
dung/Integration weiterer MSS-Werkzeuge voll ausgeschöpft. Die MSS-Werkzeuge
müssen dabei sowohl eine Möglichkeit anbieten, ihre Metadaten und Daten zu extra-
hieren (z. B. wie bei Cognos ReportNet idealer Weise aus einer zentralen Repository-
Datenbank oder zumindest wie bei Cognos PowerPlay aus einer Spezifikationsdatei),
als auch eine Schnittstelle zur Verfügung stellen, über die externe Systeme wie das
agentenbasierte MSS-Assistenzsystem auf das MSS-Werkzeug und dessen Funktiona-
litäten zugreifen können, z. B. über die Spezifikation einer URL. An den beiden Bei-
spielen Cognos ReportNet und Cognos PowerPlay hat sich jedoch gezeigt, dass eine
Integration aufwendige Implementierungen erfordern kann.
Weiterhin von Bedeutung für die Leistungsfähigkeit des agentenbasierten MSS-Assis-
tenzsystems ist das vom Agentensystem bereitgestellte/abrufbare Spektrum an Unter-
stützungsfunktionen, sowohl die verfügbaren Funktionalitäten eines einzelnen Agenten,
als auch das Zusammenspiel des gesamten Funktionsspektrums des Agentensystems.
Durch die Modellierung und Instanziierung weiterer Abfrage-Agenten können leicht
neue externe Datenquellen in das agentenbasierte MSS-Assistenzsystem integriert wer-
den (wie bei der im Prototyp realisierten Anbindung der IWUI-Datenbank geschehen).
9 Einsatz des implementierten MSS-Assistenzsystems 122
Bei der MSS-Werkzeug-übergreifenden Informationssuche werden die neuen Daten-
quellen sofort bei der Suche mit einbezogen.
Eine Leistungssteigerung der derzeitigen Implementierung des agentenbasierten MSS-
Assistenzsystems könnte durch den Ausbau folgender Punkte erreicht werden:
- Die Funktionalität des Navigation Agent könnte beispielsweise dahingehend er-
weitert werden, dass er dem Anwender anstelle nur eines analytischen Berichtes
mehrere Berichte auf Basis unterschiedlicher Berichtstemplates zur Auswahl
anbietet.
- Die Interpretations-Funktion des Interpretation Agent könnte um eine Recht-
schreibprüfung und ein Wörterbuch für synonyme Suchbegriffe ergänzt werden,
so dass die Suche schneller (z. B. ohne erneute Rückfrage beim Anwender auf-
grund falsch geschriebener Stichwörter) und sachgerechter (d. h. durch die Ein-
beziehung von Fachbegriffen konkreter auf den gerade betrachteten Sachverhalt
ausgerichtet) gestaltet werden kann.
- Vorstellbar wäre auch ein Such-Agent, der die Suchfähigkeiten bzw. den Such-
algorithmus einer Suchmaschine nutzt. Damit könnte dem Anwender die Mög-
lichkeit geboten werden, nach Informationen zu seiner Anfrage auch im Intra-
und/oder Internet zu suchen.
- Das zurzeit implementierte Problemlösungswissen des Vermittlungsagenten
(Broker) besteht nur aus fünf Standardstrategien, die dem Broker die Reihen-
folge der aufzurufenden Dienste zur Abarbeitung einer Benutzeranfrage vorge-
ben. Denkbar wäre, dass der Broker neben den Standardstrategien in Fällen, in
denen diese nicht so gut passen, alternativ auch dynamisch und flexibel die Rei-
henfolge der zur Bearbeitung der Anfrage notwendigen Funktionen (und damit
verbunden die erforderlichen Funktionsagenten) ermittelt, beispielsweise unter
Verwendung von Heuristiken oder auf Basis von früheren, ähnlichen Bearbei-
tungsfällen. Ferner wäre denkbar, andere Kooperationsformen zwischen den
Agenten zum Einsatz zu bringen.
10 Zusammenfassung und Ausblick
Der Umgang mit Management Support Systemen stellt immer höhere Anforderungen an
die Anwender (bzw. das Management). Einerseits aufgrund des stetig wachsenden
Funktionsspektrums je MSS-Werkzeug, andererseits aber auch durch die Anzahl an
unterschiedlichen MSS-Werkzeugen, die dem Anwender bei der Problemlösung gleich-
zeitig zur Verfügung stehen. Die von den MSS-Werkzeugen bereitgestellten Online-
Hilfen bieten dem Anwender für die Anwendung einzelner Funktionen eine Unter-
stützung. Direkte, auf die konkrete Problemsituation und den (konkreten) Problem-
lösungsprozess bezogene Hilfen fehlen jedoch bisher.
Mit dem in dieser Arbeit entwickelten Konzept der agentenbasierten Assistenz für
Management Support Systeme wurde das Ziel verfolgt, dem Anwender im Umgang mit
MSS-Werkzeugen während verschiedener Phasen des Problemlösungsprozesses eine
Unterstützung im Kontext der aktuellen Problemstellung zur Verfügung zu stellen.
Im ersten Teil der Arbeit wurde der Assistenzbedarfs von Management Support
Systemen bestimmt. Dazu wurde auf die Definitionen, Klassifikationen und Funktions-
umfänge von Management Support Systemen eingegangen. Es wurde das Management-
spektrum und die IT-Infrastruktur der Universität Osnabrück, die als Untersuchungs-
objekt diente, beschrieben und das Führen von Bleibeverhandlungen als ein typisches,
universitäres Beispiel-Szenario für den MSS-Einsatz ausgewählt. Auf Basis des Bei-
spiel-Szenarios wurden schließlich der potenzielle Unterstützungsbedarf identifiziert,
die Unterstützungsfunktionen inhaltlich und funktional klassifiziert und als Charakteris-
tika für eine MSS-Assistenz die Eigenschaften Flexibilität, Dynamik, Adaptivität und
Rekombination ermittelt.
Im zweiten Teil der Arbeit wurde das agentenbasierte Konzept der MSS-Assistenz
entwickelt. Hierfür wurde auf die Gestaltungspotenziale des agentenbasierten Paradig-
mas eingegangen, und es wurden verschiedene Klassifikationsansätze, Architektur-
modelle, Kommunikationsverfahren und Kooperationsformen beschrieben. Auf dieser
Grundlage wurde ein Gesamtkonzept der agentenbasierten MSS-Assistenz entwickelt,
bestehend aus den Agenten Assistant Agent, Vermittlungsagent und den Funktions-
agenten und der MSS-Metadatenbasis. Nach einer Darstellung von Aufbau und Funk-
tionsumfang dieser Architekturkomponenten wurde deren Zusammenspiel anhand eines
Anwendungsszenarios erläutert.
10 Zusammenfassung und Ausblick 124
Im dritten Teil der Arbeit erfolgte die prototypische Realisierung der agentenbasierten
MSS-Assistenz. Es wurde die Entwicklungs- und Domänenumgebung des Prototyps
beschrieben, bestehend aus den Entwicklungsumgebungen JADE und JESS und der
Domänenumgebung, die sich ihrerseits aus den MSS-Werkzeugen Cognos ReportNet
und Cognos PowerPlay und dem MSS-Metadatenmodell zusammensetzt. Die Beschrei-
bung des agentenbasierten Prototyps folgte, beginnend mit dem zugrunde liegende
Klassenmodell, den einzelnen Architekturkomponenten (MSSAssistance Agent,
BrokerAgent, InterpretationAgent, QueryAgent, SearchAgent, NavigationAgent) und
abschließend mit den Koordinationsabläufen innerhalb des Systems. Anhand dreier (an
den Analyseergebnissen des MSS-Unterstützungsbedarfs zu Beginn der Arbeit ange-
lehnten) Anwendungsfälle wurden schließlich die Einsatzmöglichkeiten des implemen-
tierten MSS-Assistenzsystems aufgezeigt und bewertet.
Das in dieser Arbeit vorgestellte Konzept der agentenbasierten Assistenz für Manage-
ment Support Systeme zeichnet sich dadurch aus, dass es einen (ersten) agentenbasier-
ten Ansatz für eine einheitliche, MSS-Werkzeug-übergreifende Unterstützung darstellt.
Der im Prototyp implementierte Unterstützungsumfang ist zwar für reale Anwendungen
noch recht begrenzt. Im Vordergrund der Entwicklung stand jedoch mehr, eine erwei-
terbare, agentenbasierte Infrastruktur zu schaffen, die von entsprechenden Experten für
MSS-Werkzeuge bzw. (betriebliche) Anwendungs-Domänen kontinuierlich (auf)gefüllt
werden kann. Beispiele hierfür sind die Input-Schnittstellen für die verschiedenen Meta-
datenbanken, insbesondere die Dokumentations- und Speicherfunktion für generierte
OLAP-Berichte, die unmittelbar den Suchagenten für die Beantwortung zukünftiger
Anfragen zur Verfügung stehen. Auch die Auslegung des Vermittlungsagenten als
regelbasiertes System gestattet es, kontinuierlich neue, verfeinerte Problemlösungs-
strategien von MSS-Experten aufzunehmen.
Bereits für das in dieser Arbeit gewählte universitäre MSS-gestützte Beispiel-Szenario
(„Führen von Bleibeverhandlungen“) gibt es zahlreiche, äquivalente betriebswirtschaft-
liche Szenarien in Unternehmungen. Dazu zählen z. B. das Führen von Mitarbeiter-
gesprächen oder die Verhandlungsgespräche mit Lieferanten im Rahmen des Supply
Chain Management. Auch in diesen Fällen werden verschiedenste Informationen, die
zumeist in unterschiedlichen Systemen zur Verfügung stehen, über die Gesprächsteil-
nehmer zur Vorbereitung auf die Gespräche benötigt.
10 Zusammenfassung und Ausblick 125
Bei den in dieser Arbeit betrachteten MSS-Werkzeugen Cognos ReportNet und Cognos
PowerPlay, für die das agentenbasierte MSS-Assistenzsystem konfiguriert wurde, han-
delt es sich um (marktführende) MSS-Werkzeuge mit starker und wachsender Verbrei-
tung in Unternehmungen. Daher ist der am Beispiel der IT-Landschaft der Universität
Osnabrück entwickelte und erprobte Ansatz der agentenbasierten Assistenz für Mana-
gement Support Systeme nicht nur auf den hochschulöffentlichen Bereich anwendbar,
sondern in hohem Maße auch unmittelbar auf betriebswirtschaftliche Entscheidungs-
situationen in Unternehmungen übertragbar.
Literaturverzeichnis
[Adam96] Adam, D.: Planung und Entscheidung: Modelle, Ziele, Methoden, Mit
Fallstudien und Lösungen. 4., vollst. überarbeitete und wesentlich
erweiterte Auflage, Gabler, Wiesbaden, 1996.
[Alba98] Albayrak, S.: Introduction to Agent Oriented Technology for
Telecommunications. In: Albayrak, S. (Hrsg.): Intelligent Agents for
Telecommunications Applications: Basics, Tools, Languages and
Applications, IOS Press, Berlin et al., 1998, S. 1-18.
[AlBu93] Albayrak, S./Bussmann, S.: Kommunikation und Verhandlungen in
Mehragenten-Systemen. In: Müller, J. (Hrsg.): Verteilte Künstliche
Intelligenz: Methoden und Anwendungen, BI-Wissenschaftsverlag,
Mannheim et al., 1993, S. 55-81.
[Aust62] Austin, J. L.: Zur Theorie der Sprechakte (How to do things with Words),
2. Auflage, Stuttgart, 1998.
[Balz99] Balzert, H.: Lehrbuch der Objektmodellierung: Analyse und Entwurf.
Spektrum Akademischer Verlag, Heidelberg, Berlin, 1999.
[BCG07] Bellifemine, F./Caire, G./Greenwood, D.: Developing Multi-Agent
Systems with JADE. Wiley Series in Agent Technology, John Wiley &
Sons Ltd., West Sussex et al., 2007.
[BeCh06] Beekmann, F./Chamoni, P.: Verfahren des Data Mining. In: [ChGl06a],
S. 263-282.
[Bell01] Bellifemine, F.: JADE - Java Agent Development Framework - what it is
and what it is next (slides). Invited speech at ETAPS 2001, Workshop on
Models and Methods of Analysis for Agent Based Systems (MMAABS),
Genf, April 2001, <http://jade.tilab.com/papers/JADEEtaps2001.pdf>
(08.10.2008).
Literaturverzeichnis 127
[BeMu98] Behme, W./Mucksch, H.: Die Notwendigkeit einer
entscheidungsorientierten Informationsversorgung. In: [MuBe98], S.3-
31.
[BiHa01] Bissantz, N./Hagedorn, J.: Data Mining. In: [Mert01], S. 130-131.
[Brad97] Bradshaw, J. M.: An Introduction to Software Agents. In: Bradshaw, J.
M. (Hrsg.): Software Agents. American Association for Artificial
Intelligence (AAAI) Press / MIT Press, Menlo Park et al., 1997, S. 3-46.
[Brus91] Brustoloni, J. C.: Autonomous Agents: Characterization and
Requirements. Technical Report CMU-CS-91-204, School of Computer
Science, Carnegie Mellon University, Pittsburgh, 1991.
[Burk03] Burkhard, H.-D.: Software-Agenten. In: Görz, G./Rollinger, C.-
R./Schneeberger, J. (Hrsg.): Handbuch der Künstlichen Intelligenz. 4.,
korrigierte Auflage, Oldenbourg, München, Wien, 2003, S. 943-1020.
[BZW98] Brenner, W./Zarnekow, R./Wittig, H.: Intelligente Softwareagenten -
Grundlagen und Anwendungen. Springer, Berlin et al., 1998.
[Carl51] Carlson, S.: Executive Behaviour: A study of the work load and the
working methods of managing directors, Strömberg, Stockholm, 1951.
[CGPS04] Chamoni, P./Gluchowski, P./Philippi, J./Schulze, K.-D.: Empirische
Bestandsaufnahme zum Einsatz von Business Intelligence - Business
Intelligence Maturity Modell (biMM). In: Chamoni, P. et al. (Hrsg.):
Multikonferenz Wirtschaftsinformatik (MKWI) 2004, Universität
Duisburg-Essen. 9.-11. März 2004, Band 2, INFIX, Berlin, 2004, S. 111-
124.
[ChGl99] Chamoni, P./Gluchowski, P. (Hrsg.): Analytische Informationssysteme -
Data Warehouse, On-Line Analytical Processing, Data Mining. 2.,
neubearbeitete Auflage, Springer, Berlin et al., 1999.
[ChGl00] Chamoni, P./Gluchowski, P.: On-Line Analytical Processing (OLAP). In:
[MuBe00a], S. 333-376.
Literaturverzeichnis 128
[ChGl04] Chamoni, P./Gluchowski, P.: Integrationstrends bei Business-
Intelligence-Systemen – Empirische Untersuchung auf Basis des
Business Intelligence Maturity Model. In: Wirtschaftsinformatik, 46. Jg.,
2004, Nr. 2, Vieweg, Wiesbaden, 2004, S. 119-128.
[ChGl06a] Chamoni, P./Gluchowski, P. (Hrsg.): Analytische Informationssysteme -
Business Intelligence-Technologien und -Anwendungen, 3., vollständig
überarbeitete Auflage, Springer, Berlin et al., 2006.
[ChGl06b] Chamoni, P./Gluchowski, P.: Analytische Informationssysteme -
Einordnung und Überblick. In: [ChGl06a], S. 3-22.
[Cogn04a] Cognos Incorporated: Cognos Enterprise BI Series Cognos PowerPlay -
Enterprise Server Guide. 2004.
[Cogn04b] Cognos Incorporated: Cognos Enterprise BI Series Cognos Transformer -
Entdecken Sie Transformer. 2004.
[Cogn04c] Cognos Incorporated: Cognos Enterprise BI Series Cognos PowerPlay
für Windows - PowerPlay Benutzerhandbuch. 2004.
[Cogn06a] Cognos Incorporated: Cognos 8 Business Intelligence Architecture and
Planning Guide. 2006.
[Cogn06b] Cognos Incorporated: Cognos 8 Business Intelligence Report Studio -
User Guide. 2006.
[Cogn06c] Cognos Incorporated: Cognos 8 Framework Manager - User Guide.
2006.
[Cogn06d] Cognos Incorporated: Cognos 8 Business Intelligence Einführung. 2006.
[Cogn08] Cognos an IBM Company, 2008, <http://www.cognos.com>
(07.01.2008).
[DFJN97] Doran, J. E./Franklin, S./Jennings, N. R./Norman, T. J.: On Cooperation
in Multi-Agent Systems. In: The Knowledge Engineering Review, Vol.
12, No. 3, 1997, S. 309-314. Online veröffentlicht durch Cambridge
University Press, 2001
Literaturverzeichnis 129
<http://journals.cambridge.org/action/displayFulltext?type=1&fid=70990
&jid=&volumeId=&issueId=03&aid=70989> (08.10.2008).
[DiBu06] Dinter, B./Bucher, T.: Business Performance Management. In:
[ChGl06a], S. 23-50.
[Eyma03] Eymann, T.: Digitale Geschäftsagenten: Softwareagenten im Einsatz.
Springer, Berlin et al., 2003.
[Fayo16] Fayol, H.: Administration industrielle et générale. Paris, 1916. Aus dem
Franz. übersetzt von Reineke, K.: Allgemeine und industrielle
Verwaltung. Internationales Rationalisierungs-Institut (Hrsg.),
Oldenbourg, Berlin u. München, 1929.
[Ferb01] Ferber, J.: Multiagentensysteme - Eine Einführung in die Verteilte
Künstliche Intelligenz. Deutsche Übersetzung von Stefan Kirn, Addison-
Wesley, München et al., 2001.
[FIPA02a] Foundation for Intelligent Physical Agents (FIPA): FIPA ACL Message
Structure Specification. Genf, 2002,
<http://www.fipa.org/specs/fipa00061/SC00061G.pdf> (08.10.2008).
[FIPA02b] Foundation for Intelligent Physical Agents (FIPA): FIPA Communicative
Act Library Specification. Genf, 2002,
<http://www.fipa.org/specs/fipa00037/SC00037J.pdf> (08.10.2008).
[FIPA02c] Foundation for Intelligent Physical Agents (FIPA): FIPA Request
Interaction Protocol Specification. Genf, 2002,
<http://www.fipa.org/specs/fipa00026/SC00026H.pdf> (08.10.2008).
[FIPA02d] Foundation for Intelligent Physical Agents (FIPA): FIPA Contract Net
Interaction Protocol Specification. Genf, 2002,
<http://www.fipa.org/specs/fipa00029/SC00029H.pdf> (08.10.2008).
[FIPA02e] Foundation for Intelligent Physical Agents (FIPA): FIPA English
Auction Interaction Protocol Specification. Genf, 2002,
<http://www.fipa.org/specs/fipa00031/XC00031F.pdf> (08.10.2008).
Literaturverzeichnis 130
[FIPA04] Foundation for Intelligent Physical Agents (FIPA): FIPA Agent
Management Specification. Genf, 2004,
<http://www.fipa.org/specs/fipa00023/SC00023K.pdf> (08.10.2008).
[FIPA08] Foundation for Intelligent Physical Agents (FIPA), 2008,
<http://www.fipa.org> (08.10.2008).
[Forg82] Forgy, C.: Rete: A Fast Algorithm for the Many Pattern/Many Object
Pattern Match Problem. In: Artificial Intelligence Nr. 1, Vol. 19,
Elsevier, Amsterdam, 1982, S. 17-37.
[FrGr97] Franklin, S./Graesser, A.: Is it an Agent, or just a Program?: A
Taxonomy for Autonomous Agents. In: [MWJ97], S. 21-35.
[Frie03] Friedman-Hill, E.: Jess in Action: Rule-based Systems in Java. Manning,
Greenwich, 2003.
[Frie05] Friedman-Hill, E.: Jess, The Rule Engine for the Java Platform (Version
6.1.p8), 2005, <http://www.jessrules.com/jess/docs/61/> (08.10.2008).
[GAA+95] Gilbert, D./Aparicio, M./Atkinson, B./Brady, S./Ciccarino, J./Grosof, B./
O’Connor, P./Osisek, D./Pritko, S./Spagna, R./Wilson, L.: IBM
Intelligent Agent Strategy. IBM Corporation, 1995.
[Gabr99] Gabriel, R.: Strategische Bedeutung der analytischen
Informationssysteme. In: [ChGl99], S. 417-426.
[GaGl97a] Gabriel, R./Gluchowski, P.: Management-Support-Systeme, Teil I. In:
Wirtschaftswissenschaftliches Studium WiSt, Band 26, Heft 6, Vahlen,
Frankfurt, M., 1997, S. 308-313.
[GaGl97b] Gabriel, R./Gluchowski, P.: Management-Support-Systeme, Teil II. In:
Wirtschaftswissenschaftliches Studium WiSt, Band 26, Heft 8, Vahlen,
Frankfurt, M., 1997, S. 422-427.
[GGC97] Gluchowski, P./Gabriel, R./Chamoni, P.: Management Support Systeme -
Computergestützte Informationssysteme für Führungskräfte und
Entscheidungsträger. Springer, Berlin et al., 1997.
Literaturverzeichnis 131
[GGD08] Gluchowski, P./Gabriel, R./Dittmar, C.: Management Support Systeme
und Business Intelligence - Computergestützte Informationssysteme für
Fach- und Führungskräfte, 2., vollständig überarbeitete Auflage,
Springer, Berlin et al., 2008.
[Gluc01] Gluchowski, P.: Business Intelligence - Konzepte, Technologien und
Einsatzbereiche. In: HMD - Praxis der Wirtschaftsinformatik 222,
dpunkt, Heidelberg, 2001, S. 5-15.
[Gluc06] Gluchowski, P.: Techniken und Werkzeuge zum Aufbau betrieblicher
Berichtssysteme. In: [ChGl06a], S. 207-226.
[Grah93] Graham, P.: OnLisp - Advanced Techniques for Common Lisp. Prentice
Hall, 1993, <http://lib.store.yahoo.net/lib/paulgraham/onlisp.pdf>
(06.10.2008).
[GrGe00] Grothe, M./Gentsch, P.: Business Intelligence - Aus Informationen
Wettbewerbsvorteile gewinnen. Addison Wesley, München et al., 2000.
[GrZa92] Greschner, J./Zahn, E.: Strategischer Erfolgsfaktor Information. In:
[KPR92], S. 9-28.
[Hart84] Hartmann, E.: Hochschulmanagement - Informationssysteme für die
Hochschulorganisation. de Gruyter, Berlin et al., 1984.
[Haup97] Haupt, D:. Flexibilität. In: Schneider, H.-J. (Hrsg.): Lexikon der
Informatik und Datenverarbeitung. 4., aktualisierte und erweiterte
Auflage, Oldenbourg, München et al., 1997, S. 328.
[HHR04] Heinrich, J./Heinzl, A./Roithmayr, F.: Wirtschaftsinformatik-Lexikon. 7.,
vollständig überarbeitete und erweiterte Auflage, Oldenbourg, München
et al., 2004, S. 130.
[InHa94] Inmon, W. H./Hackathorn, R. D.: Using the Data Warehouse. Wiley,
New York et al., 1994.
[JADE08] Java Agent Development Framework (JADE), 2008,
<http://jade.tilab.com> (08.10.2008).
Literaturverzeichnis 132
[JADE07a] Bellifemine, F./Caire, G./Trucco, T./Rimassa, G.: JADE Programmer’s
Guide (Version 3.5), TILAB S.p.A., Italien, Juni 2007,
<http://jade.tilab.com/doc/programmersguide.pdf> (08.10.2008).
[JADE07b] Bellifemine, F./Caire, G./Trucco, T./Rimassa, G./Mungenast, R.: JADE
Administrator’s Guide (Version 3.5), TILAB S.p.A., Italien, Juni 2007,
<http://jade.tilab.com/doc/administratorsguide.pdf> (08.10.2008).
[JESS08] Jess, the Rule Engine for the Java Platform, 2008,
<http://www.jessrules.com> (08.10.2008).
[JLW04] Jonen, A./Lingnau, V./Weinmann, P.: Lysios: Auswahl von Software-
Lösungen zur Balanced Scorecard. In: Lingnau, V. (Hrsg.): Beiträge zur
Controlling-Forschung, Lehrstuhl für Unternehmensrechnung und
Controlling. Technische Universität Kaiserslautern, Nr. 2, Kaiserslautern,
2004.
[KaNo92] Kaplan, R. S./Norton, D. P.: The Balanced Scorecard - Measures That
Drive Performance. In: Harvard Business Review (HBR), 70. Jg., Heft 1,
Harvard Business School, Boston Massachusetts, 1992, S. 71-79.
[Kien82] Kienle, von R.: Fremdwörterlexikon. Xenos, 1982, S. 229.
[Klei89] Kleinhans, A. M.: Wissensverarbeitung im Management: Möglichkeiten
und Grenzen wissensbasierter Managementunterstützungs-, Planungs-
und Simulationssysteme. Lang, Frankfurt am Main et al., 1989.
[KMM03] Klesse, M./Melchert, F./von Maur, E.: Corporate Knowledge Center als
Grundlage integrierter Entscheidungsunterstützung. In: Reimer, U.;
Abecker, A./Staab, S./Stumme, G. (Hrsg.): Professionelles
Wissensmanagement - Erfahrungen und Visionen (WM'2003), 02.-
04.04.2003, Luzern, GI-Edition - Lecture Notes in Informatics (LNI), P-
28. Köllen, Bonn, 2003, S. 127-136.
[KMR01] Krallmann, H./Mertens, P./Rieger, B.: Management Support System
(MSS). In: [Mert01], S. 287-288.
Literaturverzeichnis 133
[KMU04] Kemper, H.-G./Mehanna, W./Unger, C.: Business Intelligence -
Grundlagen und praktische Anwendungen - Eine Einführung in die IT-
basierte Managementunterstützung. Vieweg, Wiesbaden, 2004.
[Kopf01] Kopfer, H.: Genetischer Algorithmus. In: [Mert01], S. 209-210.
[KPR92] Krallmann, H./Papke, J./Rieger, B. (Hrsg.): Rechnergestützte Werkzeuge
für das Management, Grundlagen, Methoden, Anwendungen, E.
Schmidt, Berlin, 1992.
[KrBa93] Krcmar, H./Barent, V.: Computer Aided Team Werkzeuge als
Bestandteile von Führungsinformationssystemen – Bereitstellung
notwendiger Teamfunktionalität für Führungskräfte. In: Behme,
W./Schimmelpfeng, K. (Hrsg.): Führungsinformationssysteme. Gabler,
Wiesbaden, 1993, S. 63-71.
[Kreu01] Kreuder, A. C. S.: Software-Agenten: Eine Einführung. In: Schiefer, G.
(Hrsg.): Informationsmanagement in Agrar- und Ernährungswirtschaft.
Bericht A - 01/2, ILB, Bonn, 2001.
[KRZ92] Kleinhans, A./Rüttler, M./Zahn, E.: Management-
Unterstützungssysteme: Eine vielfältige Begriffswelt. In: Hichert,
R./Moritz, M. (Hrsg.): Management-Informationssysteme. Springer,
Berlin et al., 1992, S. 1-14.
[Kurb92] Kurbel, K.: Entwicklung und Einsatz von Expertensystemen - Eine
anwendungsorientierte Einführung in wissensbasierte Systeme. 2.,
verbesserte Auflage, Springer, Berlin et al., 1992.
[Mart98] Martin, W. (Hrsg.): Data Warehousing: Data Mining - OLAP.
International Thomson Publication, Bonn, 1998.
[Maur00] von Maur, E.: Object Warehouse - Konzeption der Basis
objektorientierter Management Support Systems am Beispiel von
Smalltalk und dem ERP Baan. Dissertation, Universität Osnabrück,
2000, <http://elib.ub.uni-osnabrueck.de/publications/diss/E-
Diss78_thesis.pdf>, (08.10.2008).
Literaturverzeichnis 134
[McMc87] McAfee, R. P./McMillan, J.: Auctions and Bidding. In: Journal of
Economic Literature, Vol. 25, No. 2, American Economic Association
1987, S. 699-738. <http://www.jstor.org/stable/pdfplus/2726107.pdf>
(08.10.2008).
[MeGr00] Mertens, P./Griese, J.: Integrierte Informationsverarbeitung 2 - Planungs-
und Kontrollsysteme in der Industrie. 8. Auflage, Gabler, Wiesbaden,
2000.
[Meie01] Meier, M.: Text Mining. In: [Mert01], S. 473-474.
[Ment03] Mentrup, A.: Wissensorientiertes Informationsmanagement für
Management-Aufgabenträger: Konzeption, empirische Untersuchung von
Gestaltungsfaktoren und prototypische Realisierung. Dissertation
Universität Osnabrück, Shaker, Aachen, 2003.
[MeRi01a] Mentrup, A./Rieger, B.: MSS und Wissensmanagement: Dimensionen
und Perspektiven der Integration. In: Schnurr, H.-P., Staab, St., Studer,
R., Stumme, G., Sure, Y. (Hrsg.): Professionelles Wissensmanagement -
Erfahrungen und Visionen (WM'2001). 14.-16.3.2001, Shaker, Baden-
Baden, 2001, S. 99-112.
[MeRi01b] Mentrup, A./Rieger, B.: Datenbewirtschaftung. In: [Mert01], S. 141.
[Mert01] Mertens, P. et al. (Hrsg.): Lexikon der Wirtschaftsinformatik. 4. Auflage,
Springer, Berlin et al., 2001.
[Mert02] Mertens, P.: Business Intelligence - Ein Überblick. In: Information
Management & Consulting (IM), Imc GmbH, Saarbrücken, 2002, S. 65-
73.
[Mint79] Mintzberg, H.: The structuring of organizations. Prentice-Hall,
Englewood Cliffs, 1979.
[Mint89] Mintzberg, H.: Mintzberg on management : inside our strange world of
organizations, New York et al., 1989; aus dem Amerikanischen übersetzt
von Meyer, H.-P.: Mintzberg über Management - Führung und
Organisation, Mythos und Realität, Gabler, Wiesbaden, 1991.
Literaturverzeichnis 135
[MuBe98] Mucksch, H./Behme, W.(Hrsg.): Das Data Warehouse-Konzept -
Architektur - Datenmodelle - Anwendungen, 3. überarbeitete Auflage,
Gabler, Wiesbaden, 1998.
[MuBe00a] Mucksch, H./Behme, W.(Hrsg.): Das Data Warehouse-Konzept -
Architektur - Datenmodelle - Anwendungen. 4., vollständig überarbeitete
und erweiterte Auflage, Gabler, Wiesbaden, 2000.
[MuBe00b] Mucksch, H./Behme, W.: Das Data Warehouse-Konzept als Basis einer
unternehmensweiten Informationslogistik. In: [MuBe00a], S. 3-80.
[NHG07] Niedersächsisches Hochschulgesetz (NHG) in der Fassung vom 26.
Februar 2007, geändert durch Artikel 3 des Gesetzes vom 13. September
2007, Nds. GVBl. S. 444,
<http://cdl.niedersachsen.de/blob/images/C43064554_L20.pdf>,
(08.10.2008).
[Nwan96] Nwana, H. S.: Software Agents: An Overview. In: Knowledge
Engineering Review, Vol. 11, No 3, Cambridge University Press, 1996,
S. 205-244;
[Post00] Postert, St.: Gestaltungspotenziale eines MSS-gestützten Hochschul-
Controllings am Beispiel der Universität Osnabrück. Dissertation,
Universität Osnabrück, 2000, <http://elib.ub.uni-
osnabrueck.de/publications/diss/E-Diss102_thesis.pdf>, (08.10.2008).
[Rieg99] Rieger, B.: Potentiale und kritische Erfolgsfaktoren der Informations-
und Kommunikationstechnologie zur betriebswirtschaftlichen Evolution
von Unternehmungen am Beispiel der Universität Osnabrück. In: Künzel,
R. (Hrsg.)/Ipsen, J./Kambas, C./Trapp, H. W.: Profile der Wissenschaft -
25 Jahre Universität Osnabrück, Rasch, Osnabrück, 1999, S. 283-297.
[Rieg00] Rieger, B.: Entwicklung und Einführung eines Management-
Informations-Systems (MIS) zur Verbesserung der Leitungs- und
Entscheidungsgrundlagen. Projekt-Abschlussbericht, Universität
Osnabrück, 2000, <http://www.oec.uni-osnabrueck.de/pabmis>,
(08.10.2008).
Literaturverzeichnis 136
[Rieg01] Rieger, B.: Data Warehouse-gestützte Management-Informations-
Systeme. In: von Knop, J./Haverkamp, W.(Hrsg.): Innovative
Anwendungen in Kommunikationsnetzen. 15. DFN-Arbeitstagung über
Kommunikationsnetze, GI-Edition - Lecture Notes in Informatics (LNI),
P-9, Köllen, Bonn, 2001, S. 147-154.
[Rile08] Riley, G.: What is CLIPS?. 2008,
<http://clipsrules.sourceforge.net/WhatIsCLIPS.html>, (11.08.2008).
[RuNo03] Russel, St./Norvig, P.: Künstliche Intelligenz: Ein moderner Ansatz. 2.
Auflage, deutsche Übersetzung der englischen Fassung: Artificial
Intelligence: A Modern Approach, Pearson Education, Prentice Hall,
München et al., 2003.
[SBM99] Schinzer, H./Bange, C./Mertens, H.: Data Warehouse und Data Mining -
Marktführende Produkte im Vergleich. 2., völlig überarbeitete und
erweiterte Auflage, Vahlen, München, 1999.
[Sche02] Scherer, A. G.: Besonderheiten der strategischen Steuerung in
Öffentlichen Institutionen und der Beitrag der Balanced Scorecard. In:
Scherer, A. G./Alt, J. M. (Hrsg.): Balanced Scorecard in Verwaltung und
Non-Profit-Organisationen, Schäffer-Poeschel, Stuttgart, 2002, S. 3-25.
[Schr01] Schrader, G.: Adaptivität. In: [Mert01], S. 6-7.
[Scot83] Scott Morton, M. S.: State of the Art of Research in Management
Support Systems, Center for Information Systems Research (CISR) 107,
Sloan School of Management, Massachusetts Institute of Technology,
Cambridge Massachusetts, 1983. Als Manuskript gedruckt.
[SDP+] Sycara, K./Decker, K./Pannu, A./Williamson, M./Zeng, D.: Distributed
Intelligent Agents. In: IEEE Expert, Nr. 6, Vol. 11, 1996, S. 36-46.
[Seid92] Seidenschwarz, B.: Entwicklung eines Controllingkonzept für öffentliche
Institutionen - dargestellt am Beispiel einer Universität. Vahlen,
München, 1992.
Literaturverzeichnis 137
[Shoh93] Shoham, Y.: Agent-oriented programming. In: Artificial Intelligence 60
(1), 1993, S. 51-92.
[Simo77] Simon, H. A.: The New Science of Management Decision. Revised
Edition, Englewood Cliffs, New Jersey, 1977.
[Smit80] Smith, R. G.: The contract net protocol: High level communication and
control in a distributed problem solver. In: IEEE Transactions on
Computers, Vol. 29, No. 12, 1980, S. 1104-1113.
[Stae99] Staehle, W.: Management: eine verhaltenswissenschaftliche Perspektive.
8. Auflage, überarbeitet von Conrad, P./Sydow, J., Vahlen, München,
1999.
[StSc93] Steinmann, H./Schreyögg, G.: Management: Grundlagen der
Unternehmensführung: Konzepte - Funktionen – Fallstudien. 3.,
überarbeitete und erweitere Auflage, Gabler, Wiesbaden, 1993.
[Stud08] Stud.IP, <http://www.studip.de>, (08.10.2008).
[Tane95] Tanenbaum, A. S.: Moderne Betriebssysteme. Die dt. Ausg. besorgten
Rademacher, R. und Baumgarten, U. 2. verbesserte Auflage, Hanser,
München, 1995.
[UOS08] Universität Osnabrück: Web-Auftritt der Universität Osnabrück,
<http://www.uni-osnabrueck.de> (08.10.2008).
[Vulk99] Vulkan, N.: Economic Implications of Agent Technology and E-
Commerce. In: The Economic Journal, Blackwell Publishing, Vol. 109,
No. 453, S. 67-90, 1999.
<http://www.jstor.org/stable/pdfplus/2565586.pdf> (08.10.2008).
[WoJe95a] Wooldridge, M. J./Jennings, N. R.: Agent Theories, Architectures and
Languages: A Survey. In: Wooldridge, M. J./Jennings, N. R. (Hrsg.):
Intelligent Agents. Proceedings of the ECAI-94 Workshop on Agent
Theories, Architectures, and Languages (ATAL) Amsterdam, Holland,
August 8-9, 1994, 2. Auflage, Springer, Berlin et al., 1995, S. 1-22.
Literaturverzeichnis 138
[WoJe95b] Wooldridge, M. J./Jennings, N. R.: Intelligent agents: theory and
practice. In: The Knowledge Engineering Review, Vol. 10, No. 2,
Cambridge University Press, 1995, S. 115-152.
[Wool97] Wooldridge, J.: Agents as a Rorschach Test: A Response to Franklin and
Graesser. In: [MWJ97], S. 47-48.
[Zarn99] Zarnekow, R.: Softwareagenten und elektronische Kaufprozesse:
Referenzmodelle zur Integration. Gabler, Wiesbaden, 1999.
Anhang A-1: Agenten Lebenszyklus [FIPA04, S. 14]
A-2: UML-Modell der JADE Behaviour-Klassen [vgl. JADE07a, S. 27]
Anhang 140
A-3: Erweitertes Klassenmodell des MSS-Assistenzsystems