Agentenbasierte Assistenz für Management Support Systeme · BI Business Intelligence BLOB Binary Large Object BSC Balanced Scorecard CBR Case Based Reasoning ... ERP Enterprise Resource

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


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


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.


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


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.


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


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


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


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)


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


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.


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


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.


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


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.


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.


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


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


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


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.


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


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.


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


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.


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-


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


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


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


[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


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


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


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


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


• 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


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


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-


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


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.


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.


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]


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


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


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-


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.


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


- 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


- 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


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


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


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


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


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.


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


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


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


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


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


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-


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]


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


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


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-


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.


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-


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“


Ü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


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


„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


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


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


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.


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.


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.


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


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


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


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.


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


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


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


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-


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


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


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,


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


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


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.


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


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.


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


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-


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


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-


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


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.


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


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.


[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


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


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


[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,


[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).


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


[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).


[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,


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


[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).


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


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


[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

Documents

Agentenbasierte Assistenz für Management Support Systeme · BI Business Intelligence BLOB Binary Large Object BSC Balanced Scorecard CBR Case Based Reasoning ... ERP Enterprise Resource