Leseprobe
Inhaltsverzeichnis
Abstract
1 Einfuhrung
1.1 Motivation
1.2 Aufbau der Diplomarbeit
2 Analyse
2.1 Workflow-Anwendung
2.1.1 Workflow
2.1.2 Architektur
2.2 Systemuberwachung
2.2.1 Uberwachungsablauf
2.2.2 Architektur
3 Konzeption und Entwurf des Expertensystems
3.1 Abstrakte Architektur
3.2 Basisschnittstelle
3.3 Systemkern
3.3.1 Wissensbasis
3.3.2 Steuerungssystem
3.3.2.1 Tnferenzkomponente
3.3.2.2 Erklarungskomponente
3.3.3 Diagnostische Auswertung
3.4 Regeleditor
3.5 Ansatze zur Optimierung
3.5.1 Temporale Tnferenz
3.5.2 Automatische Schwellwertbestimmung
4 Prototypisierung
4.1 Wissensbasis
4.2 Tnferenzkomponente
4.2.1 Kontrollsystem
4.2.2 Regelinterpreter
4.3 Diagnostische Auswertung
4.4 Regeleditor
4.4.1 Regeleingabe
4.4.2 Transfer zur Datenbank
4.4.3 Auslesen der Faktentabelle
4.4.4 Eingabe potentieller Diagnosen
5 Bewertung
6 Zusammenfassung und Ausblick
Literaturverzeichnis
Abkurzungsverzeichnis
Abbildungsverzeichnis
Abstract
In den letzten Jahren haben verschiedene Programme zur Systemuberwachung Einzug in Unternehmen und Verwaltungen gehalten. Die Sichtweise solcher Oberwachungen ist jedoch hardwareorientiert und beschrankt sich auf die Erfassung und Auswertung technischer Ereignisse. Fur Anwendungsbetreuer die Fachanwendungen betreuen bedeutet dies, dass eine Sicht vorherrscht die die Diagnose von Anwendungsstorungen erschwert. Es fehlt eine zentrale Sicht auf das Betriebsverhalten von Softwareanwendungen. Zudem sind die Auswertungsfunktionen einer Systemuberwachung nur eingeschrankt zur Diagnose von Anwendungen geeignet.
Ziel dieser Diplomarbeit ist deshalb eine ganzheitliche maschinelle Anwendungs- uberwachung, die Storungsursachen feststellen und bewerten kann. Fur die plausibelste Ursache soil ein Therapievorschlag angezeigt werden, der dem Anwendungsbetreuer erklart welche MaBnahmen notwendig sind. in der Diplomarbeit werden zunachst eine komplexe Workflow-Anwendung und deren Oberwachung analysiert. Die resultierenden Problembereiche werden durch Konzeption und Entwurf eines Expertensystems gelost. Bei der theoretischen Losung werden wissensbasierte Methoden und neuronale, sowie mathematische Ansatze verwendet.
Die praktische Umsetzbarkeit der theoretischen Losung wird durch einen Prototypen validiert. Um Entwicklungszeit einzusparen wird der Systemkern in eine Datenbank implementiert. in der Programmiersprache Java wird ein vom Systemkern getrennter Regeleditor entwickelt.
Der Prototyp wird bewertet. Weiterfuhrende Verbesserungsmoglichkeiten werden aufgezeigt.
1 Einfuhrung
Das „Robotermarchen“ des polnischen Philosphen Stanislaw Lem befasst sich mit den Themen Wissen und Information. Der Autor erzahlt die Geschichte der Raumfahrer Klapaucius und Trurl, die von einem Rauber gefangen genommen werden. Dem Rauber steht der Sinn nicht nach Gold und Silber, sondern nach den Schatzen des Wissens. Die Astronauten konstruieren fur ihn eine Maschine, die am laufenden Band Informationen generiert und auswirft. SchlieBlich lasst der Rauber die Beiden laufen und beginnt, die generierten Informationen zu lesen. So erfahrt er zum Beispiel, dass die Tochter des Konigs Petricius aus Laubaudien Garbunda hieB, und er erfahrt die Anzahl der Elektronenhullen eines Termionoliumatoms. SchlieBlich stellt der Rauber jedoch fest, dass ihm die Informationen nichts nutzen. Er kann fur sich aus den Informationen keinen positiven Vorteil ableiten.[1]
Umgangssprachlich werden die Begriffe „Wissen“ und „Information“ oftmals gleichwertig behandelt. Doch die philosophische Geschichte zeigt, dass zwischen den Begriffen „Wissen“ und „Information“ durchaus ein Unterschied besteht. In der Ausdrucksweise der mathematischen Informationstheorie wird der Begriff „Information“ als das Neue an einer Nachricht definiert. Der Begriff „Wissen“ hingegen kennzeichnet die praktische Anwendbarkeit bzw. den Nutzen der Information.[2]
Der philosophischen Geschichte kann auch entnommen werden, dass es in einer bestimmten Situation nicht einfach ist, an die Informationen zu gelangen, die gerade von Bedeutung sind. Der Zugriff auf Informationen erscheint manchmal weniger problematisch, als die Abgrenzung des Relevanten. Solch eine Abgrenzung kann ggf. lange dauern und teuer sein.
Die Filterung von Informationen ist historisch betrachtet ein relativ zeitloses Gebiet. Zudem existiert ein breiter industrieller Hintergrund. Beispielsweise wurde in den ersten Automobilen der Fahrer noch eher als Maschinist betrachtet. Moderne Fahrzeuge hingegen teilen dem Fahrer genau mit, wo sich eine Storung befindet und was zu tun ist, um den Normalbetrieb wieder herzustellen. Inzwischen verfugen sogar Kaffeemaschinen uber Anzeigen, die vom Anwender bestimmte MaBnahmen fordern, um den Betrieb aufrecht zu erhalten.
In vielen teehnisehen Geraten befinden sich heute „Expertensysteme“. Solche Expertensysteme verfugen uber genugend Wissen, um die fur den Anwender relevanten informationen herauszufiltern und aufzubereiten. Dem Anwender wird eine definierte Schnittstelle nach auBen angeboten, sodass er sich um interna nicht mehr kummern muss.[3] Das Ziel solcher Systeme ist die Vereinfachung von Bedienung und Wartung - gerade bei sehr komplexen Vorgangen.
Neben technischen bzw. medizinischen Einsatzmoglichkeiten ist der Einsatz von Expertensystemen auch in der informationstechnologie moglich, denn bei Anwendungsstorungen kann das Ableiten von Ursachen und Therapievorschlagen ebenfalls durch ein Expertensystem erfolgen.
infrastruktur- und Anwendungsmanagement haben unterschiedliche Sichtweisen auf den Support. Die Administratoren betreuen Systemsoftware wie Betriebs-, Speicher- und Rechnersysteme. Anwendungsbetreuer pflegen die Fachanwendungen. ihre Arbeit setzt funktionsfahige Systemsoftware und Hardware voraus, jedoch sind Hardwarezustande fur einen Anwendungsbetreuer von sekundarer Bedeutung. Hier stehen die Konfigurationen und Funktionen von Fachanwendungen im Mittelpunkt. Folglich ist ein anderer Blickwinkel bzw. ein Wissen uber die betreffenden Anwendungen notwendig.
Doch dieses Wissen allein genugt nicht. Die Reaktionszeiten, die Fehlerbehebungszeiten und die Verfugbarkeiten von Anwendungen werden zunehmend vertraglich durch Service Level Agreements (SLAs) fixiert.[4] Bei Nichteinhaltung drohen Vertragsstrafen. Dies erfordert, dass das benotigte Wissen auch zuganglich, verstandlich und nachvollziehbar hinterlegt wird. Eine moglichst kurze Auswertungszeit und eine kostengunstige Automatisierung sind erwunscht.
Der Einsatz eines Expertensystems zur Anwendungsdiagnose lasst sich somit begrunden.
1.1 Motivation
Die Relevanz einer umfassenden Oberwaehung der informationsinfrastruktur wird zunehmend erkannt. in den letzten Jahren haben verschiedene Oberwaohungsprogramme in Unternehmen und Verwaltungen Einzug gehalten. Kostenlose Open-Source-Programme, wie zum Beispiel „Nagios“ erlangen immer mehr Beliebtheit. Die kostgunstige Beschaffung der Software und eine modular erweiterbare Architektur begunstigen die Verbreitung.[5]
Das Oberwachungsprogramm Nagios ist besonders fur offentliche Einrichtungen interessant. Durch den Haushalt und die Budgetierung sind die finanziellen Mittel begrenzt. Bei notwendigen Anschaffungen muss hier besonders auf deren Wirtschaftlichkeit geachtet werden. Einer Fachzeitschrift lasst sich entnehmen, dass der Deutsche Bundestag und das Bundesverwaltungsamt bereits eine Nagios-Oberwachung verwenden und damit sehr zufrieden sind.[6]
Trotz der Zufriedenheit vieler Betreiber muss festgestellt werden, dass die Nagios-Software auf die Oberwachung von Hardware und Betriebssystemen fixiert ist. Sie wurde speziell fur eine Systemuberwachung (engl. system monitoring) entwickelt. im Mittelpunkt der Oberwachung und Ergebnisvisualisierung stehen die Hardware-Ereignisse von technischen Systemen. Diese Sichtweise ist deshalb nur bedingt zur Oberwachung von Anwendungen geeignet. Bei der Betreuung von Anwendungen stehen die Konfigurationen und Funktionen der verteilten Anwendungskomponenten im Vordergrund. informationen uber Zustande von Rechnern und Netzwerkabschnitten sind bei der Anwendungsbetreuung nur von sekundarer Bedeutung.
Diese Erkenntnis motiviert zur innovation. Ziel dieser Diplomarbeit ist es deshalb, eine ganzheitliche Konzeption fur ein Expertensystem zur Anwendungsdiagnose zu erarbeiten. Sinn und Zweck ist die Entwicklung eines Systems zur automatisierten Ursachensuche mit anschlieBendem Therapievorschlag. im Mittelpunkt steht dabei die Sicht auf die Anwendungen. Die bereits bestehende Systemuberwachung ist im Entwurf zu berucksichtigen und beizubehalten. Die Konkretisierung des Entwurfs erfolgt am Beispiel eines komplexen, verteilten informationssystems. Dadurch wird sichergestellt, dass die erarbeitete Losung einen ganzheitlichen Charakter aufweist. Letztlich soil die theoretische Losung prototypisiert werden. Die praktische Umsetzbarkeit ist zu bewerten.
1.2 Aufbau der Diplomarbeit
Zunachst wird das Umfeld analysiert. Die Erarbeitung des Expertensystems erfolgt am Beispiel einer ausgewahlten, komplexen Workflow-Anwendung. Die Workflow-Anwendung befindet sich auf einer Hardware, welche an eine Nagios-Systemuberwachung angebunden ist. Die Anwendung und die Systemuberwachung werden systematisch in kleinere Bestandteile zerlegt. Wahrend der Analyse wird das Problem in Problembereiche unterteilt, die spater durch die Konzeption und den Entwurf des Expertensystems gelost werden. Zunachst wird deshalb eine abstrakte Expertensystem-Architektur entworfen. Die Komponenten der Expertensystem-Architektur werden dann konkretisierend beschrieben. Auch weiterfuhrende Ansatze zur Optimierung des Expertensystems werden aufgezeigt. Es wird auf wissensbasierte, neuronale und differenzialdiagnostische Methoden zuruckgegriffen.
Im Anschluss an die Erarbeitung der theoretischen Losung erfolgt die praktische Prototypisierung. Ausgewahlte Funktionen des Systemkerns werden in eine Datenbank implementiert. Dies reduziert die Entwicklungsdauer. In der Programmiersprache Java wird die graphische Oberflache eines Regeleditors entwickelt.
Nach der praktischen Umsetzung werden die realisierten Funktionen zwischen Anwendungsexperte, Anwendungsbetreuer und Entwickler diskutiert. Der Konsens wird in einer Bewertung schriftlich festgehalten. Die Ergebnisse werden zusammengefasst und ein Ausblick wird gegeben.
2 Analyse
lm Folgenden wird ein informationssystem ausgewahlt, das ein Ordnungswidrigkeits- verfahren unterstutzt (siehe 2.1). Stellvertretend fur andere kommunale informationssysteme wird eine komplexe Workflow-Anwendung (1. Untersuehungsobjekt) untersucht. Dadurch wird sichergestellt, dass die erarbeitete Losung einen ganzheitlichen Charakter aufweist.
Die hardwareorientierte Systemuberwachung (2. Untersuchungsobjekt) der Anwendung ist ebenfalls von Bedeutung. Die Architektur und der Oberwachungsablauf von Nagios (bereits unter 1.1 erwahnt) werden deshalb eingehend beschrieben (siehe 2.2).
Die nun folgende Analyse bildet die Grundlage fur Konzeption und Entwurf des Expertensystems (siehe 3). Zunachst wird die Workflow-Anwendung untersucht.
2.1 Workflow-Anwendung
Bei dem ausgewahlten Informationssystem handelt es sich um eine „Workflow-Anwendung“. Eine Workflow-Anwendung „steuert den Arbeitsfluss (Workflow) zwischen beteiligten Stellen nach den Vorgaben einer Ablaufspezifikation (Workflow-Schema).“[7] Die kommerzielle Anwendung „Public Marius OWI“ (PMOWI) ist eine solche Anwendung. Sie ist Kernbestandteil eines komplexen, raumlich verteilten und weitgehend automatisiert ablaufenden Prozesses. Im Folgenden wird ein Oberblick uber den Workflow (siehe 2.1.1) gegeben und die komplexe, raumlich verteilte Architektur (siehe 2.1.2) aufgezeigt.
2.1.1 Workflow
Ein Workflow (Arbeitsfluss) ist „eine zum Teil automatisierte, gesteuert ablaufende Gesamtheit von Aktivitaten, die sich auf Teile eines Geschaftsprozesses beziehen.“[8] Ausgehend vom gesetzlichen Rahmen wird nun der Workflow fur Verkehrsdelikte beschrieben:
Die StraBenverkehrsordnung (StVO) ist eine Rechtsnorm, die vom Bundesministerium fur Verkehr, Bau und Stadtentwicklung verfasst wird. innerhalb der StVO werden grundlegende Verhaltensregeln fur die Teilnahme am StraBenverkehr festgelegt. Die Umsetzung der Rechtsnorm wird durch eine Verwaltungsvorschrift geregelt. Bei der Kommune Mannheim erfolgt deren Umsetzung im Fachbereich „Sicherheit und Ordnung“. Die PMOWi-Anwendung steuert den Workflow.
Die Polizeihostessen stehen am Anfang des Arbeitsflusses. Sie weisen den Verkehrsteilnehmern Verwarnungen zu, wenn gesetzliche Halte- und Parkverbote nicht beachtet werden. Durch die Ausstellung einer Verwarnung wird ein komplexer Verarbeitungsprozess (Verfahren) angeregt. Das Verfahren bearbeitet auch Geschwindigkeitsuberschreitungen die durch Radargerate erfasst werden.
Die folgende Abbildung zeigt das Verfahren fur Verkehrsdelikte:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Deliktverfahren
In einem Vorverfahren werden informationen uber potentielle Delikte durch mobile Datenerfassungsgerate (MDEs) bzw. Laptops in die Anwendung importiert. Die Schwerpunkte des Vorverfahrens sind die Datensammlung und Datenaufbereitung. Die Schnittstelle zwischen Vorverfahren und Hauptverfahren sind Dateien. Diese werden zu fixen Zeiten ins Hauptverfahren importiert. im Hauptverfahren ubernimmt die automatische, ereignis- und zeitgebundene Ablaufsteuerung der PMOWi-Anwendung die Kontrolle uber die Unterprozesse. Beispielsweise druckt die Anwendung selbsttatig Briefe, beschafft Halter- informationen und kommuniziert mit der Kassenstelle.
2.1.2 Architektur
Die Anwendung ist in der Stadt Mannheim verteilt angeordnet. Die Verteilung der Anwendung resultiert aus den ortlichen Gegebenheiten und kostenrechnerischen Oberlegungen. Die raumlich verteilten Anwendungsteile sind funktional miteinander verbunden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: Raumlich verteilte PMOWi-Anwendung
Die Bestandteile der Anwendung haben untersehiedliehe Aufgaben; Auf den File-Servern (1 und 2) befinden sich Fotos und Dokumente, die in dem beschriebenen Verfahren erzeugt werden. Die Daten auf „SV1“ werden regelmaBig mit den Daten von „SV2“ abgeglichen (Redundanz). Auf einem anderen Server (3) befindet sich eine Datenbank. Die Verbindung der verschiedenen Anwendungsteile wird durch Router (4) realisiert. Die Anzahl der aktiven Clients (5) ist variabel und abhangig von der personellen Besetzung im Fachbereich. Gelegentlich werden Drucker (6) aufgrund der Wartung vom Netzwerk getrennt. Auf die soeben erwahnten Bestandteile wird spater, bei der Konzeption der Wissensbasis (siehe 3) naher eingegangen.
Die Verbindungsgrundlage fur die einzelnen Anwendungsteile ist das Metropolitan Area Network (MAN) der Kommune Mannheim. Die raumliche Trennung beeinflusst das Anwendungsverhalten nicht und wird deshalb nicht explizit betrachtet. Sie hat jedoch Auswirkungen auf die Anwendungsuberwachung (siehe 3).
2.2 Systemuberwachung
Aufgrund von rechtlichen Konsequenzen ist es wichtig, dass Verfahrensfehler festgestellt bzw. vermieden werden. Ein Verfahrensfehler entsteht durch menschliches oder technisches Versagen. Damit ein technisches Versagen der PMOWI-Anwendung festgestellt werden kann, wird die beteiligte Hardware durch Nagios uberwacht. Zunachst werden deshalb der Oberwachungsablauf (siehe 2.2.1) und die Architektur (siehe 2.2.2) von Nagios eingehender betrachtet.
Die Diskrepanz zwischen dem Ist-Zustand der bestehenden Systemuberwachung und der Soll-Vorstellung wird „Problem“ genannt. Das Problem besteht aus verschiedenen „Problembereichen“[9]. Im Folgenden werden die Problembereiche definiert.
2.2.1 Oberwachungsablauf
Durch Nagios konnen Informationen uber technische Systeme gesammelt werden. Bisher erfolgt auch die Oberwachung der Workflow-Anwendung durch das Produkt Nagios. Die Abhangigkeit von den Auswertungsfunktionen des Produktes ist hier jedoch nicht erwunscht (1. Problembereich).
Der komplette Oberwaehungsablauf wird in Abbildung 4 dargestellt und in Ebenen unterteilt;
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3; Oberwaehungsablauf
Auf der 1. Ebene erfolgt die Sammlung von Informationen aus einem oder mehreren Systemen. Unter dem Begriff „System“ wird „eine in sieh strukturierte, organisierte und geordnete Menge eng miteinander weehselwirkender Elemente“[10] verstanden. Die Menge „erweist sieh aufgrund einer gegebenen Funktion und aufgrund einer spezifisehen Struktur objektiv als ein einheitliehes, ganzheitliehes Gebilde.“[11] Diese Definition ist sehr weit gefasst - ebenso wie die Erfassungsmogliehkeiten von Nagios. Die Starke von Nagios ist die umfangreiehe Informationssammlung. Hierzu greift Nagios auf ein sehr groBes und dem aktuellen Stand der Teehnik entspreehendes Repertoire von Methoden zuruek.[12]
In der 2. Ebene werden die einkommenden Informationen gefiltert. Nur ausgewahlte (selektierte) Informationen werden im weiteren Ablauf berueksiehtigt.
in der 3. Ebene werden die selektierten Systeminformationen in Zustande uberfuhrt. Im Zusammenhang mit Nagios wird der Begriff „Zustand“ als Status-Differenzierung von Komponenten verstanden.[13] Die Differenzierung erfolgt durch definierte Schwellwerte. Die moglichen Zustandsauspragungen sind: „Ok“, „Critical“ und „Warning“. Die manuelle Definition von Schwellwerten ist ggf. umstandlich, wenn es innerhalb eines Netzwerkes zu Veranderungen kommt. Die manuelle Anpassung der Schwellwerte erfolgt ggf. mit teilweise erheblichem Zeitversatz. Eine automatisierte Losung ware von Vorteil (2. Problembereich).
In der 4. Ebene werden die Oberwachungsergebnisse in einer Web-Oberflache dargestellt. Ein Administrator erarbeitet ggf. selbst eine Losung, da die Auswertungsfunktionen von Nagios sehr begrenzt sind. Es fehlen Funktionen, die eine weiterfuhrende Ursachensuche fur Anwendungen ermoglichen (3. Problembereich). Zudem kann Nagios keinen Therapievorschlag unterbreiten (4. Problembereich). Das Wissen von Anwendungsexperten kann nicht berucksichtigt werden (5. Problembereich).
2.2.2 Architektur
Die Abbildung 4 zeigt die modulare Architektur von Nagios, die zur informationssammlung verwendet wird. Der Nagios-Server (1) besteht aus dem Nagios-Kern (2) und einer variablen Anzahl an Plugins (3). Durch die Plugins wird der Nagios-Server auf Betriebssystemebene um die Funktionalitaten externer Programme erweitert. Die PMOWI-Anwendung (4) besteht aus verteilten Anwendungsteilen, weshalb sich der Einsatz von „Nagios-Clients“ (5) anbietet. Ein Nagios-Client ist ein „Softwareagent“[14], der sich auf der raumlich entfernten Zielplattform befindet und dort informationen sammelt bzw. Aktionen ausfuhrt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Nagios-Architektur
Auf dem Server „SV3“ (siehe Abbildung 2) befindet sich solch ein Nagios-Client. Dieser sammelt Informationen, welche an das zustandige Plugin des Nagios-Servers gesendet werden. Es findet eine „passive 0berwachung“ statt.
Die Informationssammlung auf den Servern „SV1“ und „SV2“ erfolgt durch das Simple Network Management Protocol (SNMP). Es existiert deshalb jeweils ein aktivierter SNMP- Dienst, der Informationen in einer definierten Datenstruktur sammelt. Die Datenstruktur heiBt „Management Information Base“ (MIB). Ein Nagios-Plugin fuhrt durch ein externes Programm eine SNMP-Anfrage an den entfernten SNMP-Dienst aus. Als Antwort erhalt das Plugin die MIB-Informationen in einem Informationsstrom. Es findet eine „aktive 0berwachung“ statt.
Die Informationssammlung fur Router erfolgt ebenfalls durch SNMP. Fur Clients und Drucker existiert bisher keine Informationssammlung, da die Aktivierungszeitpunkte unregelmaBig bzw. unsicher sind (6. Problembereich).
3 Konzeption und Entwurf des Expertensystems
Die nun folgende Konzeption bearbeitet und lost die in der Analyse besehriebenen Problembereiehe.[15] Die Problembereiehe sind:
1. Die Abhangigkeit von der Nagios-Auswertungsfunktion ist aufzulosen.
2. Eine Losung fur die automatisehe Definition von Sehwellwerten ist aufzuzeigen.
3. Bei Anwendungsstorungen ist die plausibelste Ursaehe abzuleiten.
4. Ein zur Ursaehe passender Therapievorsehlag muss angezeigt werden.
5. Die Eingabe von Wissen muss fur Anwendungsexperten moglieh sein.
6. Eine Losung fur Komponenten mit unsieherer Aktivierung ist aufzuzeigen.
Ziel ist eine masehinellen Losung. Deshalb muss Wissen uber die Problembereiehe in einem System hinterlegt sein (Wissensdarstellung). Aueh Aktionen auf das hinterlegte Wissen mussen im System vorhanden sein (Wissensverarbeitung). Wird nun die Wissensdarstellung der Problembereiehe von der Wissensverarbeitung getrennt, so entsteht ein „wissensbasiertes System“. Stammt das hinterlegte Wissen eines solehen Systems von einem Experten (einem Spezialisten der Problembereiehe), so liegt ein „Expertensystem“ vor.[16] Im Folgenden wird ein solehes Expertensystem entworfen, das dureh das hinterlegte Wissen von Anwendungsexperten den Betrieb komplexer Anwendungen beurteilt.
Beim Entwurf (Design) des Expertensystems wird die Methodik der Abstraktion und der ansehlieBenden Konkretisierung angewendet.[17] Es wird deshalb eine neue, abstrakte Arehitektur erarbeitet.
Im Anschluss an den Entwurf dieser abstrakten Arehitektur werden deren Komponenten konkretisiert. Hierbei wird auf bekannte, wissensbasierte Methoden bzw. mathematisehe Ansatze zuruekgegriffen. Die Konkretisierung der Komponenten erfolgt am Beispiel der bereits unter 2.1.2 erlauterten komplexen Arehitektur der PMOWI-Anwendung.
[...]
[1] Vgl. [Le82] und Vgl. [BHS07] S.1,2
[2] Vgl. [BK00] S.419
[3] Siehe [BHS07] S.6
[4] Vgl. [HK08] S.36
[5] Vgl. [PI07] S.37
[6] Vgl. [HK08] S.34 und 35
[7] Siehe [BJS97] S. 491
[8] Siehe [BJS97] S. 490
[9] Vgl. [BKOO] s.10
[10] Siehe [GS84] S.23
[11] Siehe [GS84] S.23
[12] Vgl. [Kr08] S.7-10
[13] Vgl. [Ba05] S.72
[14] Vgl. [KHL06] S.21-23
[15] Vgl. [BFP96] S.26
[16] Vgl. [BKOO] S.10
[17] Vgl. [GS84] S. 177