Die Fehlersuche in einer/m Software/Programm welches keine Debuginformationen enthalten, gestaltet sich schwierig. Zu diesem Zweck wurden C++ Klassen entwickelt welche es ermöglichen, im Falle eines Fehlers während des Programmablauf einer Release-Version, festzustellen in welche Sourcedatei der Fehler auftrat. Das Verhalten der Klassen kann so angepasst werden, dass mehr Fehler protokolliert werden oder weniger, sprich man kann verschieden Loglevel angeben z.B. INFO, WARN, CRITICAL oder ERROR. Der Speicherort für die Log-/Monitoring-Daten kann eine Datenbank oder eine Textdatei sein. Die Klassen sind so entworfen, dass die auch leicht erweitert werden können z.B. XML-Datei.
Inhaltsverzeichnis
Danksagung
Abbildungsverzeichnis
Tabellenverzeichnis
Listingverzeichnis
1 Einführung
1.1 Einleitung
1.2 Ziel der Diplomarbeit
1.3 Aufbau der Diplomarbeit
2 Grundlagen
2.1 Programmfehler
2.2 Protokollierung
2.3 Reproduzierbarkeit / Nachvollziehbarkeit
3 Das vorhandene Informationserfassungssystem
3.1 Protokollierungskomponente
3.2 Monitoring-Komponente
4 Motivation
5 Anforderungen an das neue Informationserfassungssystem
5.1 Flexible Datenhaltung
5.2 Schnellere Identifizierung
5.3 Die Daten
5.3.1 Log-Daten
5.3.2 Monitoring-Daten
5.4 Die Datendarstellung
5.5 Performance
5.6 Implementierung
5.7 Konfigurierbarkeit
6 Entwicklung eines Lösungsansatzes
6.1 Einführendes Beispiel
6.2 Client-Server-Architektur
6.3 Interprozesskommunikation
6.4 Nebenläufigkeit und Synchronisation
6.5 Daten
6.5.1 Log-Daten
6.5.2 Monitoring-Daten
6.6 Datenbank
6.7 Performance
6.8 Zusammenfassung
7 Entwurf des Lösungsansatzes
7.1 Datenbank der Protokollierungskomponente
7.2 Datenbank der Monitoring-Komponente
7.3 Klassendiagramm Informationserfassungssystem
7.3.1 Allgemeines
7.3.2 Beschreibung des Klassendiagramms
7.3.2.1 Der grüne Bereich
7.3.2.2 Der blaue Bereich
7.3.2.3 Der gelbe Bereich
7.3.2.4 Der orange Bereich
7.3.2.5 Der pinke Bereich
7.3.2.6 Restliche Klassen
7.4 Beschreibung der verwendeten Software-Muster
7.4.1 Singleton
7.4.2 Wrapper-Facade
7.4.3 Scoped Locking
7.4.4 Double-Checked Locking Optimization
7.4.5 Thread-Safe Interface
8 Ergebnisse
8.1 Allgemein
8.2 Anwendungsbeispiel
8.3 Performance-Test
8.3.1 Testsergebnisse
8.3.2 Erkenntnisse Performance-Test
8.3.3 Verbesserungsvorschlag
8.4 Compiler-Test
9 Zusammenfassung
9.1 Allgemein
9.2 Zukunftsvorstellung
9.2.1 Empfehlungen zur 1. Generation
9.2.2 Die 2. Generation
9.3 Fazit
Glossar
Literatur- und Quellenverzeichnis
Abkürzungsverzeichnis
Anhang
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.
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
Tabellenverzeichnis
Tabelle 1: Ergebnis Beispielabfrage
Tabelle 2: Ergebnis Beispielabfrage 2
Tabelle 3: Interprozesskommunikationsmechanismen
Tabelle 4: SQL-Standard
Tabelle 5: Direkte Eintragung in Datenbank
Tabelle 6: Zwischenpufferung
Tabelle 7: Datenbanktabelle "OriginFile"
Tabelle 8: Datenbanktabelle "Origin"
Tabelle 9: Datenbanktabelle "Level"
Tabelle 10: Vorbelegung Datenbanktabelle "Level"
Tabelle 11: Datenbanktabelle "Message"
Tabelle 12: Datenbanktabelle "Category"
Tabelle 13: Vorbelegung Datenbanktabelle "Category"
Tabelle 14: Datenbanktabelle "InfoLog"
Tabelle 15: Datenbanktabelle "Property"
Tabelle 16: Datenbanktabelle "Component"
Tabelle 17: Datenbanktabelle "Type"
Tabelle 18: Vorbelegung Datenbanktabelle "Type"
Tabelle 19: Datenbanktabelle "MonitorLog"
Tabelle 20: Klassenbeschreibung "griiner Bereich"
Tabelle 21: Klassenbeschreibung "blauer Bereich"
Tabelle 22: Klassenbeschreibung "gelber Bereich"
Tabelle 23: Klassenbeschreibung "oranger Bereich"
Tabelle 24:Klassenbeschreibung "pinker Bereich"
Tabelle 25: Klassenbeschreibung "restliche Klassen"
Tabelle 26: Testergebnisse ohne Puffer
Tabelle 27: Testergebnisse mit Puffer
Tabelle 28: Verantwortlichkeitsmatrix
Listingverzeichnis
Listing 1: Datendarstellung Protokollierungskomponente
Listing 2: Datendarstellung Beispielabfrage
Listing 3: Datendarstellung Beispielabfrage 2
Listing 4: Beispiel Singleton-Muster C++
Listing 5: Beispiel Wrapper-Facade-Muster C++
Listing 6: Beispiel Wächterklasse C++-Idiom Scoped Locking
Listing 7: Double-Checked Locking Optimization 1
Listing 8: Double-Checked Locking Optimization 2
Listing 9: Thread-Safe Interface
Listing 10: Anwendungsbeispiel Logging- und Monitorkomponente
Listing 11: Normaler Aufruf Log-Methode
Listing 12: Defines.h
Listing 13: Datenbankskript MLDB.sql
Listing 14: Datenbankskript InfoLog.sql
Listing 15: Datenbankskript MonitorLog.sql
Listing 16: Datenbankskript TableLevel.sql
Listing 17: Datenbankskript TableType.sql
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 der Diplomarbeit".
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 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:
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1: Informationserfassungssystem
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.
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.
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 zeigen, was hinter dem Wort "Protokollierung" steckt. 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.
Laufzeitfehler können sich auf die unterschiedlichsten Arten zeigen. Oftmals zeigt das Programm ungewünschtes Verhalten, im Extremfall wird die Ausführung des Programms abgebrochen ("Absturz") oder das Programm geht in einen Zustand über, in dem es keine Benutzereingaben mehr akzeptiert ("Einfrieren", "Hangen"). 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.
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.
- Fachliche Protokolle werden gewöhnlich anwenderspezifisch aufbereitet und übersetzt. Sie dienen Endbenutzern, Administratoren oder Betreibern von Softwaresystemen und liefern Informationen über die vom Programm abgewickelten Geschäftsprozesse.
- Technische Protokolle sind Informationen für Betreiber oder Entwickler. Sie dienen der Fehlersuche sowie der Systemoptimierung.
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.
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.
Abbildung in dieser Leseprobe nicht enthalten
Listing 1: Datendarstellung Protokollierungskomponente
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 denken: ,,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.
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.
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).
5.3 Die Daten
Eine der wichtigsten Anforderungen ist es, brauchbare Daten (Informationen) bereitzustellen. Wie die Daten für einen Log- bzw. für einen Monitoring-Eintrag im Einzelnen aussehen könnten, wird in den Abschnitten 5.3.1 bzw. 5.3.2 gezeigt.
5.3.1 Log-Daten
Ein Log-Eintrag könnte z.B. aus folgenden Daten zusammengesetzt sein:
Für einen Log-Eintrag wird zur Identifizierung ein Zeitstempel sowie ein Bezug auf einen Ursprung (Quellcode) benötigt. Des Weiteren sollte es möglich sein, die Daten eines Log-Eintrags in verschiedene Kategorien (z.B. Übertragungsfehler oder Verbindungsaufbaufehler) sowie auch in verschiedene Einstufungen, wie z.B. leicht-normal-kritisch, einzuteilen.
5.3.2 Monitoring-Daten
Die Daten für die Monitoring-Einträge könnten Folgendes beinhalten:
Von Bedeutung ist der Name der Komponente (z.B. Festplatte oder Prozessor) sowie deren Standort (z.B. Rechner1 oder PC2). Natürlich muss auch ein Wert (z.B. GB oder %-CPU-Auslastung) Bestandteil der Monitoring-Daten sein.
5.4 Die Datendarstellung
Eine gut definierte Datenbank in Bezug auf die Daten (Abschnitt 5.3) trägt zu einheitlichen Log-/Monitoring-Einträgen bei, wodurch die Identifizierung, siehe auch Abschnitt 5.2, komfortabler und schneller wird.
Im Folgenden wird gezeigt, wie eine Abfrage der Datenbank aussehen könnte:
SELECT * FROM LogDatabase
Listing 2: Datendarstellung Beispielabfrage
Das obige Listing 2 zeigt, wie mit einem einfachen SQL-Kommando die Log-Datenbank bzw. Protokollierungskomponente abgefragt werden kann.
Tabelle 1: Ergebnis Beispielabfrage
Abbildung in dieser Leseprobe nicht enthalten
In Tabelle 1 wird das Ergebnis der SQL-Abfrage aus Listing 2 dargestellt.
SELECT * FROM MonitoringDatabase WHERE Standort LIKE ='PC1'
Listing 3: Datendarstellung Beispielabfrage 2
Obiges Listing 3 zeigt, wie eine Abfrage der Monitoring-Komponente bzw. deren Datenbank aussehen könnte.
Tabelle 2: Ergebnis Beispielabfrage 2
Abbildung in dieser Leseprobe nicht enthalten
Die Tabelle 2 zeigt das Ergebnis der SQL-Abfrage aus Listing 3.
Man sieht in den obigen 2 Tabellen, welche Verbesserung die Datendarstellung gegenüber dem alten Informationserfassungssystem (Kapitel 3) erhalten soll. Die Darstellung ist übersichtlicher. Die Identifizierung durch das gezielte Abfragen ist schneller als beim derzeitigen System.
5.5 Performance
Die Performance spielt auch eine wichtige Rolle, da die Softwarekomponente, die das neue Informationserfassungssystem einsetzt (implementiert), nicht durch das Tätigen eines Log-Eintrages beeinträchtigt werden darf. Der Performance-Impact (Leistungsauswirkung negativ) darf also nicht oder nur sehr gering eintreten. Dies bedeutet, dass der Benutzer der Anwendung (WWS) durch das Tätigen eines Log-Eintrages nicht bei der Arbeit gestört bzw. aufgehalten werden darf.
5.6 Implementierung
Da das Warenwirtschaftssystem unter dem Betriebssystem "Windows" läuft und das Programm mit dem C++-Builder von Borland in der Version 5 entwickelt wird, ergibt sich somit die Anforderung, dass das neue Konzept in der Programmiersprache C++ implementiert wird. Da es jedoch nicht ausgeschlossen ist, dass es eine Portierung auf Unix-/Linux-Plattform geben könnte bzw. bestimmte Komponenten des Warenwirtschaftssystems immer in C++ entwickelt werden oder auch eine Änderung der Entwicklungsumgebung (des Compilers) stattfinden kann, ist es sehr wichtig, die Implementierung in ANSI C++ durchzuführen!
Die Implementierung soll also Betriebssystem- und Compiler-Unabhängig sein, um das neue Informationserfassungssystem auch in anderen Softwareprojekten einsetzen zu können.
5.7 Konfigurierbarkeit
Das neue Informationserfassungssystem soll konfigurierbar sein. Wie schon in Abschnitt 5.1 erwähnt, soll konfiguriert werden können, welches Ausgabemedium (Datei, Datenbank) verwendet werden soll. Des Weiteren soll es möglich sein, anzugeben, welche Einstufungen (Levels), vgl. auch Abschnitt 5.3, mitprotokolliert werden sollen und welche nicht. Die Konfiguration soll über eine Konfigurationsdatei erfolgen.
6 Entwicklung eines Lösungsansatzes
Hier wird die Entwicklung des Lösungsansatzes für die Anforderungen aus Kapitel 5 gezeigt. Durch die Anforderungen ergeben sich auch einige Probleme, die bei der Entwicklung des Lösungsansatzes beachtet werden müssen. Auf diese wird in den einzelnen Kapiteln hingewiesen.
Begonnen wird dieses Kapitel mit einem einführenden Beispiel in Abschnitt 6.1. In Abschnitt 6.2 wird die angestrebte Architektur beschrieben, in Abschnitt 6.3 geht es um die Kommunikationsmechanismen und in Abschnitt 6.4 wird das Problem der Nebenläufigkeit und Synchronisation aufgezeigt. Weiter geht es mit Abschnitt 6.5, in dem es um die Log- und Monitoring-Daten geht, gefolgt von Abschnitt 6.6 "Datenbanken". Der Abschnitt 6.7 stellt den vorletzten Teil ("Performance") dieses Kapitels dar, wohingegen mit Abschnitt 6.8 "Zusammenfassung" das Kapitel 6 abgeschlossen wird.
Bei dem Wort "Informationserfassungssystem" ragen zwei Punkte besonders hervor:
1. Abschicken von Informationen (Log-/Monitoring-Einträge)
2. Entgegennehmen von Informationen (Protokollieren)
Durch diese Punkte wirft sich folgender Gedanke auf: „Soll dies im selben Programm geschehen?"
Um dies zu beantworten, wird im Abschnitt 6.1 ein einführendes Beispiel aus einem anderen Bereich wie der Softwareentwicklung herangezogen.
[...]
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.