Danksagung

Microsoft, Windows, Windows NT/2000/XP, Visual C++ und/oder andere Produkte von Microsoft, auf die hier Bezug genommen wird, sind Marken oder eingetragene Marken von Microsoft. Alle hier erwähnten Firmen- und Produktnamen sind Marken der jeweiligen Eigentümer. Hier genannte Beispiele für Unternehmen, Organisationen, Produkte, Personen und Veranstaltungen sind frei erfunden. Übereinstimmungen mit tatsächlichen Unternehmen, Organisationen, Produkten und Personen oder Veranstaltungen sind rein zufällig und nicht beabsichtigt.

Alle hier nicht ausdrücklich eingeräumten Rechte bleiben behalten.

© 2005-2006 Copyright Pascal Fritz

Pascal Fritz

Alle Rechte vorbehalten.

Diese Diplomarbeit ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verfassers unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen, Einspeicherung und Bearbeitung in elektrischen Medien.

2

Danksagung

Danksagung

An dieser Stelle möchte ich allen, die an dieser Arbeit beteiligt waren, meinen Dank aussprechen.

Mein erster Dank geht an Herrn Prof. Dr. Th. Eppler, der mir dieses interessante Thema angeboten hat und mir nützliche Tipps bei der Ausarbeitung gab.

Der zweite Dank geht an Frau Prof. Dr. U. Matecki, die mir immer einen guten Rat bei speziellen Problemen hatte.

Ferner möchte ich mich bei Herrn Dipl.-Ing. (FH) Ch. Ehinger, Herrn Dipl.-Ing. (FH) I. Biehl und Herrn Dipl.-Ing. (FH) T. Kübler, die mir in der Zeit der Diplomarbeit mit Rat und Tat zur Seite standen, bedanken.

Natürlich gilt mein Dank auch den Professoren, Dozenten und Assistenten der Hochschule Albstadt-Sigmaringen, mit denen ich eine schöne Studienzeit verbringen durfte.

Des Weiteren möchte ich Herrn H. Srivistava, Herrn M. Oudot, Herrn G. Auroy und Herrn O. Paty danken, von denen ich nicht nur viel Praxiswissen vermittelt bekommen habe!

Ein herzliches Dankeschön geht auch an meine Familie und meinen Freundeskreis, die mir schon vor Beginn meines Studiums zur Seite standen, mich überall unterstützten und mich aufheiterten, wenn es mal nicht so gut lief.

Besonderer Dank gilt auch meiner Freundin N. Möller, die für mich immer ein offenes Ohr hatte, für ihr Verständnis und die Geduld, vor allem im letzten Abschnitt der Diplomarbeit.

4

Eidesstattliche  Erklärung  

Inhaltsverzeichnis

Danksagung   3

Abbildungsverzeichnis   7

Tabellenverzeichnis   8

Listingverzeichnis   9

1  Einführung  10

1.1  Einleitung  10

1.2  Ziel der Diplomarbeit  10

1.3  Aufbau der Diplomarbeit  12

2  Grundlagen  13

2.1  Programmfehler  13

2.2  Protokollierung  15

2.3  Reproduzierbarkeit / Nachvollziehbarkeit  15

3  Das vorhandene Informationserfassungssystem  16

3.1  Protokollierungskomponente  16

3.2  Monitoring-Komponente  17

4  Motivation  18

5  Anforderungen an das neue Informationserfassungssystem  19

5.1  Flexible Datenhaltung  19

5.2  Schnellere Identifizierung  19

5.3  Die Daten  20

5.3.1  Log-Daten  20

5.3.2  Monitoring-Daten  20

5.4  Die Datendarstellung.  20

5.5  Performance  22

5.6  Implementierung  22

5.7  Konfigurierbarkeit  22

6  Entwicklung eines Lösungsansatzes  24

6.1  Einführendes Beispiel  24

6.2  Client-Server-Architektur  27

6.3  Interprozesskommunikation  28

6.4  Nebenläufigkeit und Synchronisation  30

6.5  Daten  31

6.5.1  Log-Daten  31

6.5.2  Monitoring-Daten  32

6.6  Datenbank  32

6.7  Performance  33

6.8  Zusammenfassung.  36

7  Entwurf des Lösungsansatzes  37

7.1  Datenbank der Protokollierungskomponente  37

5

Eidesstattliche  Erklärung  

7.2  Datenbank der Monitoring-Komponente  42

7.3  Klassendiagramm Informationserfassungssystem  46

7.3.1  Allgemeines  47

7.3.2  Beschreibung des Klassendiagramms  47

7.3.2.1  Der grüne Bereich  48

7.3.2.2  Der blaue Bereich  48

7.3.2.3  Der gelbe Bereich  49

7.3.2.4  Der orange Bereich  50

7.3.2.5  Der pinke Bereich  50

7.3.2.6  Restliche Klassen  51

7.4  Beschreibung der verwendeten Software-Muster.  53

7.4.1  Singleton  53

7.4.2  Wrapper-Facade  54

7.4.3  Scoped Locking  56

7.4.4  Double-Checked Locking Optimization  57

7.4.5  Thread-Safe Interface  59

8  Ergebnisse  62

8.1  Allgemein  62

8.2  Anwendungsbeispiel  63

8.3  Performance-Test  67

8.3.1  Testsergebnisse  68

8.3.2  Erkenntnisse Performance-Test  72

8.3.3  Verbesserungsvorschlag  73

8.4  Compiler-Test  74

9  Zusammenfassung  75

9.1  Allgemein  75

9.2  Zukunftsvorstellung  75

9.2.1  Empfehlungen zur 1. Generation  76

9.2.2  Die 2. Generation  77

9.3  Fazit  79

Glossar   80

Literatur  - und Quellenverzeichnis  84

Abk  ürzungsverzeichnis  85

Anhang   86

6

Abbildungsverzeichnis   

Abbildungsverzeichnis   

Abbildung  1: Informationserfassungssystem  

Abbildung  2: Einführendes Beispiel (Konferenzführung 3)  

Abbildung  3: Client-Server-Architektur  

Abbildung  4: Weg eines Log-/Monitoring-Eintrages  

Abbildung  5: Weg eines Log-/Monitoring-Eintrages über einen Puffer  

Abbildung  6: Grafische Darstellung Lösungsansatz  

Abbildung  7: Datenbankmodell Logging-Komponente  

Abbildung  8: Datenbankmodell Monitoring-Komponente  

Abbildung  9: Statisches Klassendiagramm.  

Abbildung  10: Struktur Singleton-Muster  

Abbildung  11: Struktur des Wrapper-Facade-Musters, Quelle: Loui02  

Abbildung  12: Sequenzdiagramm Clientseite  

Abbildung  13: Grafische Gegenüberstellung Clientseite  

Abbildung  14: Grafische Gegenüberstellung Serverseite  

Abbildung  15: Logging-System 1. Generation  

Abbildung  16: Die 2. Generation  

Abbildung  17: Konfiguration in der 2. Generation  

7

Tabellenverzeichnis   

Tabellenverzeichnis   

Tabelle 1:  Ergebnis Beispielabfrage  21

Tabelle 2:  Ergebnis Beispielabfrage 2  21

Tabelle 3:  Interprozesskommunikationsmechanismen  28

Tabelle 4:  SQL-Standard  33

Tabelle 5:  Direkte Eintragung in Datenbank  34

Tabelle 6:  Zwischenpufferung  35

7DEHOOH'DWHQEDQNWDEHOOH³2ULJLQ)LOH³   39

7DEHOOH'DWHQEDQNWDEHOOH³2ULJLQ³   39

7DEHOOH'DWHQEDQNWDEHOOH³/HYHO³   40

7DEHOOH9RUEHOHJXQJ'DWHQEDQNWDEHOOH³/HYHO³   40

7DEHOOH'DWHQEDQNWDEHOOH³0HVVDJH³   40

7DEHOOH'DWHQEDQNWDEHOOH³&DWHJRU\³   41

7DEHOOH9RUEHOHJXQJ'DWHQEDQNWDEHOOH³&DWHJRU\³   41

TaEHOOH  'DWHQEDQNWDEHOOH ,QIR/RJ  42

7DEHOOH'DWHQEDQNWDEHOOH³3URSHUW\³   44

7DEHOOH'DWHQEDQNWDEHOOH³&RPSRQHQW³   44

7DEHOOH'DWHQEDQNWDEHOOH³7\SH³   44

7DEHOOH9RUEHOHJXQJ'DWHQEDQNWDEHOOH³7\SH³   45

7DEHOOH'DWHQEDQNWDEHOOH³0RQLWRU/RJ³   45

7DEHOOH.ODVVHQEHVFKUHLEXQJ³JU  QHU HUHLFK  48

TabellH.ODVVHQEHVFKUHLEXQJ  EODXHU HUHLFK  48

7DEHOOH.ODVVHQEHVFKUHLEXQJ³JHOEHU%HUHLFK³   49

Tabelle 23:  KlassenbeschreibunJ RUDQJHU HUHLFK  50

7DEHOOH.ODVVHQEHVFKUHLEXQJ³SLQNHU%HUHLFK³   51

7DEHOOH.ODVVHQEHVFKUHLEXQJ³UHVWOLFKH.ODVVHQ³   52

Tabelle 26:  Testergebnisse ohne Puffer  68

Tabelle 27:  Testergebnisse mit Puffer  69

Tabelle 28:  Verantwortlichkeitsmatrix  86

8

Listingverzeichnis   

Listingverzeichnis   

Listing  1: Datendarstellung Protokollierungskomponente  16

Listing  2: Datendarstellung Beispielabfrage.  21

Listing  3: Datendarstellung Beispielabfrage 2  21

Listing  4: Beispiel Singleton-Muster C  54

Listing  5: Beispiel Wrapper-Facade-Muster C  56

Listing  6: Beispiel Wächterklasse C -Idiom Scoped Locking  57

Listing  7: Double-Checked Locking Optimization 1  58

Listing  8: Double-Checked Locking Optimization 2  59

Listing  9: Thread-Safe Interface  60

Listing  10: Anwendungsbeispiel Logging- und Monitorkomponente  64

Listing  11: Normaler Aufruf Log-Methode  64

Listing  12: Defines.h  87

Listing  13: Datenbankskript MLDB.sql  88

Listing  14: Datenbankskript InfoLog.sql  90

Listing  15: Datenbankskript MonitorLog.sql  92

Listing  16: Datenbankskript TableLevel.sql  93

Listing  17: Datenbankskript TableType.sql  93

9

Einführung

1 Einführung

In diesem Kapitel erhalten Sie in Abschnitt 1.1 eine Einleitung in das Projekt, gefolgt von der Zieldefinition der Diplomarbeit in Abschnitt 1.2. Zum Abschluss des Kapitels kommt es mit dem Abschnitt 1.3 ³Aufbau dHU'LSORPDUEHLW³.

1.1 Einleitung

Wie werden Programmfehler und Ausnahmen systematisch und konsistent behandelt? Kann ein System wieder in einen konsistenten Zustand gelangen, nachdem ein Fehler auftrat? Kann dies automatisch geschehen oder ist ein manueller Eingriff erforderlich?

Mit diesen Fragen beschäftigt sich auch der Hersteller eines Warenwirtschaftssystems (fortfolgend auch WWS bezeichnet).

Da dieser Aspekt etwas mit Protokollierung, im Englischen auch als Logging und Tracing bezeichnet, zu tun hat, wurde für diesen Zweck eine Diplomarbeit ausgeschrieben. Im Rahmen dieser sollte ein neues Konzept zur Informationserfassung für die Softwareentwickler des WWS erstellt und implementiert werden.

1.2 Ziel der Diplomarbeit

Die Hauptaufgabe der Diplomarbeit besteht darin, das vorhandene

Informationserfassungsystem neu zu konzipieren und danach zu implementieren.

Die bisher eingesetzte Protokollierungskomponente soll durch eine neue Überarbeitete ersetzt werden. Es muss also ein neues Konzept und dessen Implementierung für die neue Protokollierungskomponente, mit der Programmabläufe protokolliert werden können, erstellt werden. Des Weiteren soll das Warenwirtschaftssystem überwacht werden. Dies bedeutet, dass die Prozessorauslastung, Speichernutzung usw. in einer geeigneten Form festgehalten wird. Auch soll die Größe der Datenbank überwacht

10

Einführung

werden, die vom Warenwirtschaftssystem verwendet wird. Eine Komponente, mit der die Netzwerkverbindung zu anderen Teilnehmern des WWS überprüft wird, soll ebenfalls, wenn die Zeit es zulässt, auch noch implementiert werden.

Nochmals kurz zusammengefasst ergeben sich folgende Aufgabenstellungen:

a) Programmabläufe des Warenwirtschaftssystems protokollieren b) Warenwirtschaftsystem überwachen c) Datenbankgröße regelmäßig kontrollieren d) Netzwerkverbindungen überprüfen

Die Aufgabenstellung a) wird auch als Protokollierungskomponente bezeichnet. b), c) und d) werden, da sie alle etwas mit Überwachen bzw. Überprüfen zu tu haben, zu einer Monitoring-Komponente (Überwachungskomponente) zusammengefasst.

Zur besseren Vorstellung des Informationserfassungssystems soll die folgende Abbildung dienen:

Die Abbildung 1 zeigt das zu entwerfende Informationserfassungssystem, das aus den Komponenten ³Protokollierung³ und ÄMonitoring³ aufgebaut ist. Die Komponenten sind zu Beginn der Diplomarbeit als Blackboxen dargestellt, da ihre Struktur zum jetzigen Zeitpunkt noch unbekannt ist.

Einführung

1.3 Aufbau der Diplomarbeit

Die Diplomarbeit ist in 9 Kapitel aufgeteilt.

Das Kapitel 1 (dieses Kapitel) soll als Einführung dienen und einen ersten Überblick der Diplomarbeit geben.

In Kapitel 2 wird ein Einblick in die Grundlagen des Protokollierens von Programmabläufen gegeben.

In Kapitel 3 wird das bisher eingesetzte Informationserfassungssystem analysiert.

In Kapitel 4 wird die Motivation wiedergegeben.

In Kapitel 5 werden die Anforderungen an das neue Informationserfassungssystem erläutert.

In Kapitel 6 folgt die Entwicklung des Lösungsansatzes.

In Kapitel 7 wird der Entwurf des Lösungsansatzes gezeigt.

In Kapitel 8 werden die Ergebnisse des entwickelten Informationserfassungssystems vorgestellt.

In Kapitel 9 und letzten Kapitel werden die Zukunftsaussichten,

Weiterentwicklungsmöglichkeiten und die Arbeit mit einem Fazit abgeschlossen.

12

Grundlagen

2 Grundlagen

Dieses Kapitel stellt Grundlagen vor, die zum Entwurf und zur Implementierung des Informationserfassungssystems notwendig sind.

In Abschnitt 2.1 wird erklärt, was Programmfehler überhaupt sind. Der Abschnitt 2.2 soll ]HLJHQ ZDV KLQWHU GHP :RUW ³3URWRNROOLHUXQJ³ VWHFNW Mit der Beschreibung zu Reproduzierbarkeit/Nachvollziehbarkeit (Abschnitt 2.3) wird Kapitel 2 abgeschlossen.

2.1 Programmfehler

Ein Programm- oder Softwarefehler, im Englischen auch einfach Bug (Wanze, Käfer, Insekt; Aussprache: Bagg) genannt, ist ein Ausdruck aus dem EDV-Bereich. Ein Programmfehler tritt in Computerprogrammen auf, wenn der Programmierer einen bestimmten Zustand in der Programmlogik nicht berücksichtigt hat oder wenn die Laufzeitumgebung an sich fehlerhaft arbeitet. Auch Unvollständigkeit, Fehler, Ungenauigkeiten, Mehrdeutigkeiten oder ähnliches in der Spezifikation des Programms können zu Bugs führen bzw. als solche interpretiert werden. (Quelle: [WiKi06])

In der Softwaretechnik wird zwischen folgenden Typen von Fehlern in Programmen unterschieden:

Syntaxfehler: Sie verhindern bereits die Kompilierung eines Programms. Sie sind Verstöße gegen die grammatischen Regeln der benutzten Programmiersprache.

Laufzeitfehler: Die Ursache für sie liegt in den meisten Fällen in einer inkorrekten Implementierung der gewünschten Funktionalität im Programm. Sie werden auch als Bugs bezeichnet und sind alle Arten von Fehlern, die auftreten können, während das Programm abgearbeitet wird. Da diese Fehler die Programmlogik und damit die Bedeutung des Programmcodes betreffen, spricht man hier auch von semantischen Fehlern.

Grundlagen

Laufzeitfehler können sich auf die unterschiedlichsten Arten zeigen. Oftmals zeigt das Programm ungewünschtes Verhalten, im Extremfall wird die Ausführung des Programms abJHEURFKHQ³$EVWXU]³oder das Programm geht in einen Zustand über, in dem es keine BenXW]HUHLQJDEHQPHKUDN]HSWLHUW³(LQIULHUHQ³³+lQJHQ³ Gelegentlich tritt als Ursache auch eine ungeeignete Laufzeitumgebung auf (z.B. eine falsche Betriebssystem-Version). Wird in Programmiersprachen ohne Garbage Collection (etwa C oder C++) Speicher nach der Verwendung nicht mehr freigegeben, so wird durch das Programm auf Dauer immer mehr Speicher belegt. Diese Situation wird Speicherleck genannt. Aber auch in Programmiersprachen mit Garbage Collection (etwa Java oder C#) können ähnliche Probleme auftreten, wenn zum Beispiel Objekte unkontrolliert in einer Liste angesammelt werden.

Designfehler: Dies sind Fehler im Grundkonzept, entweder bei der Definition der Anforderungen an die Software oder bei der Entwicklung des Softwaredesigns, auf dessen Grundlage das Programm entwickelt wird. Fehler bei der Anforderungsdefinition beruhen oft auf mangelnder Kenntnis des Fachgebietes, für das die Software geschrieben wird oder auf Missverständnisse zwischen Nutzern und Entwicklern.

Fehler direkt im Softwaredesign hingegen sind oft auf mangelnde Erfahrung der Softwareentwickler oder auf Folgefehler durch Fehler in der Anforderungsspezifikation zurückzuführen. In anderen Fällen ist das Design historisch gewachsen und wird mit der Zeit unübersichtlich, was wiederum zu Designfehlern bei Weiterentwicklungen des Programms führen kann. Vielen Programmierern ist das Softwaredesign auch lästig, so dass oftmals ohne richtiges Konzept direkt entwickelt wird, was dann insbesondere bei steigendem Komplexitätsgrad der Software unweigerlich zu Designfehlern führt. Sowohl für Fehler in der Anforderungsdefinition als auch im Softwaredesign können darüber hinaus vielfach Kosten oder Zeitdruck in Frage kommen.

Regressionsbug: Als Regressionsbug, kurz Regression, bezeichnet man einen Fehler, der in einer früheren Programmversion bereits behoben wurde, der aber in einer späteren Programmversion wieder auftaucht.

14

Grundlagen

2.2 Protokollierung

In der Softwareentwicklung hat das Wort ³Protokollieren³ die Bedeutung, Programmabläufe oder Ergebnisse (z.B. einer Berechnung) aufzuzeichnen, sei es als Ausgabe auf dem Bildschirm oder auf einen Datenträger, wie z.B. die Festplatte.

Es gibt zwei Ausprägungen der Protokollierung, zum einen das Logging, zum anderen das Tracing. Bei beiden werden Funktions- oder Methodenaufrufe in das Programm aufgenommen, die zur Laufzeit über den Status des Programms Auskunft geben.

In der Praxis gibt es zwischen Logging und Tracing allerdings sehr wohl Unterschiede:

1. Logging kann eine fachliche oder technische Protokollierung sein oder eine beliebige Kombination von beidem.

2. Tracing soll Debugging-Informationen für Entwickler oder Supportmitarbeiter liefern. Es dient primär zur Fehlersuche und -analyse.

2.3 Reproduzierbarkeit / Nachvollziehbarkeit

Bei der Softwareentwicklung ist Reproduzierbarkeit eine wesentliche Hilfe bei der Beseitigung von Programmier- oder Programmfehlern (siehe auch Abschnitt 2.1). Man versucht, den Ablauf der zu einem Fehler oder bestimmten Verhalten geführt hat, so exakt wie möglich nachzuvollziehen, so dass durch einen Versuch dieser Ablauf wieder reproduziert/simuliert und damit ein Problem eingegrenzt werden kann. Um diese Möglichkeit zu haben, ist Logging oder Tracing (Abschnitt 2.2) unverzichtbar.

Das vorhandene Informationserfassungssystem

3 Das vorhandene Informationserfassungssystem

Hier wird das bisher eingesetzte Informationserfassungsystem erläutert. Es wird ein Einblick in dessen Protokollierungskomponente und deren Funktionalität (Abschnitt 3.1) gegeben. In Abschnitt 3.2 kommt ein Wort zur Monitoring-Komponente.

3.1 Protokollierungskomponente

Bisher werden im Warenwirtschaftssystem Programminformationen, wie z.B. Fehler im Programmablauf, durch einen einfachen Eintrag in eine Log-Datei festgehalten. Für den Softwareentwickler oder Servicemitarbeiter des WWS hat dies den Nachteil, dass dieser die Datei selbst nach den wichtigen Informationen, die er auswerten möchte, durchsuchen und interpretieren muss. Die Log-Einträge in der Datei werden schlecht und uneinheitlich dargestellt und sind somit unübersichtlich (siehe auch Listing 1).

Die Identifizierung ist mit Suchen von Informationen verbunden, da die Einträge keine stichfesten Informationen, wie z.B. Art, Kategorie oder schlecht zu findende Hinweise auf Code-Abschnitte, geben. Die Identifizierung ist somit zeitaufwendig.

Listing 1: Datendarstellung Protokollierungskomponente

16

Das vorhandene Informationserfassungssystem

Das obige Listing 1 zeigt einen Ausschnitt der aktuell vom WWS erstellten Log-Datei. Man stelle sich den Abschnitt nun noch mal sehr viel größer vor. Es wird klar, dass es sehr schwierig sein kann, dann noch Informationen, die z.B. zu einem Fehler im Programmablauf geführt haben, herauszufinden.

Der eine oder andere mag vielleicht GHQNHQ ÄMan kann doch die Suchfunktion des Editors verwenden, mit dem man die Log-Datei anschaut³. Könnte man! Aber nach was soll man suchen und wie oft müsste man diese Suchfunktion aufrufen und verwenden?

Ein Beispiel: Es sollen alle Programmstarts aufgelistet werden um zu kontrollieren wie oft dies geschehen ist. Mit einem Editor und dessen Suchfunktion gänzlich unmöglich.

3.2 Monitoring-Komponente

Eine Monitoring-Komponente war bisher nicht Bestandteil des alten

Informationserfassungssystems. Es konnten also keine Aussagen über den Speicherverbrauch, die Prozessorauslastung usw. der Anwendung bzw. des Warenwirtschaftssystems gemacht werden. Auch war es bisher nicht möglich, die Größe der Datenbank, die das Warenwirtschaftssystem verwendet, zu überwachen. Folglich gab es für den letzten Punkt der Aufgabenstellungen (Kapitel 1, Abschnitt 1.2 d)) auch keine Möglichkeit.

Motivation

4 Motivation

Das momentan eingesetzte Informationserfassungssystem dient mit der Protokollierungskomponente (Kapitel 3, Abschnitt 3.1) lediglich dem unstrukturierten Protokollieren von Informationen. Jeder Entwickler kann einfach einen willkürlichen Log-Eintrag in die Log-Datei machen. Das Lesen und Auswerten der Log-Datei ist nicht gerade das, was man komfortabel nennt und Monitoring-Daten, über Speicherverbrauch und Prozessauslastung oder andere Systemressourcen, gibt es nicht.

Dies soll nun durch ein neues Konzept geändert und verbessert werden, da das alte längst nicht mehr einem guten Informationserfassungssystem entspricht. Das neue Konzept soll nach Fertigstellung implementiert werden und danach das alte Informationserfassungssystem nach und nach ablösen. Es soll den Entwicklern des WWS helfen, aussagekräftige Protokollierungen leicht und einfach zu implementieren. Dies soll durch das Bereitstellen von vorgefertigten Klassen und Methoden geschehen. Durch eine Speicherung der Daten in einer Datenbank soll das Auswerten komfortabel gemacht werden, was heißen soll, dass diese gezielt nach benötigten Informationen abgefragt werden kann. Natürlich gehört zum neuen Informationserfassungsystem auch die Möglichkeit, Daten, wie z.B. Speicherverbrauch einer Anwendung oder die Prozessorauslastung, zu protokollieren.

18

Anforderungen an das neue Informationserfassungssystem

5 Anforderungen an das neue

Informationserfassungssystem

In diesem Kapitel werden die Anforderungen, die an das neue

Informationserfassungssystem gestellt werden, vorgestellt. Beginnend mit der flexiblen Datenhaltung in Abschnitt 5.1, geht es über zu den Daten in Abschnitt 5.3 und der Datendarstellung in Abschnitt 5.4. In Abschnitt 5.2 geht es um die Identifizierung, wobei in Abschnitt 5.5 die Anforderungen an die Performance beschrieben werden. Beendet wird das Kapitel 5 mit den Abschnitten 5.6 Implementierung und 5.7 Konfigurierbarkeit.

5.1 Flexible Datenhaltung

Im neuen Informationserfassungsystem sollen Log-Einträge oder nun auch Monitoring-Einträge nicht mehr, wie bisher, in einer einfachen Log-Datei, sondern unter anderem auch in einer Datenbank protokolliert werden. Eine Log-Datei soll natürlich weiterhin erzeugt werden können. Diese kann unter Umständen auch als Rettungsanker eingesetzt werden, falls die Datenbank, die die Log-/Monitoring-Einträge entgegen nehmen soll, nicht erreichbar ist. Die Datenhaltung (die Ausgabeart/das Ausgabemedium) soll so konfigurierbar sein, ob eine Datei oder eine Datenbank zur Protokollierung der Log-Einträge verwendet werden soll oder beide.

5.2 Schnellere Identifizierung

Der Zeitaufwand für die Identifizierungsabläufe der einzelnen Log-Informationen soll verbessert und somit gegenüber dem jetzigen System stark verringert werden. Nicht nur die Datenhaltung in einer Datenbank, die mit geeigneten Datenbank-Queries abgefragt werden kann, soll dazu beitragen, sondern auch die Darstellung der Daten (vgl. hierzu auch nachfolgende Abschnitte 5.3 und 5.4).