Projekt Message-Logger

Transkript

1 M o d u l S o f t w a r e k o m p o n e n t e n T A. S W K. F Projekt Message-Logger S y s t e m s p e z i f i k a t i o n Horw,

2 Projekt Dokument Schule Modul Projektteam Dozenten Letzte Änderung Projekt Message-Logger Systemspezifikation, TA.SWK.F1001 Galliker Thomas Studiengang Informatik (BB) Panorama 6123 Geiss Tel Stocker Elias Studiengang Informatik (BB) Schybenacherweg Hitzkirch Tel Prof. Jud Martin 6. Juni 2010, 19:19:00 Uhr Gasser Martin Studiengang Informatik (BB) Mettenwilhöhe Ballwil Tel martin.gasser@stud.hslu.ch Änderungsprotokoll Version Datum Autor Beschreibung gat Initialversion von Vorlage erstellt ste Konfigurationsmanagement gat Systemübersicht gat Komponentendiagramm gat Klassendiagramme, Schnittstellenspezifikation gat Sequenzdiagramme gat Deploymentdiagramm gat Anpassungen für Iteration gam Designentscheide eingefügt

3 Inhalt 1 Einleitung Ziel & Zweck dieses Dokuments Begriffe & Abkürzungen Systemübersicht Softwarearchitektur Komponenten Klassen Test-Applikation Logger CorbaLogger...7 Viewer Server Sequenzielle Abläufe Softwareverteilung Schnittstellenspezifikation Design-Entscheide Persistieren der Log-Messages...13 Abbildungsverzeichnis Abbildung 1: Systemübersicht als Komponentendiagramm...5 Abbildung 2: Komponentendiagramm...6 Abbildung 3: Klassendiagramm der Test-Applikation...7 Abbildung 4: Klassendiagramm der Logger-Komponente...7 Abbildung 5: Klassendiagramm der Viewer-Komponente...8 Abbildung 6: Klassendiagramm der Server-Komponente...8 Abbildung 7: Sequenzdiagramm Aufzeichnen von Log-Nachrichten...9 Abbildung 8: Sequenzdiagramm Anzeigen von Log-Nachrichten...9 Abbildung 9: Deployment-Diagramm...10 Abbildung 10: Klassendiagramm der definierten Schnittstellen...12 Tabellenverzeichnis Tabelle 1: Begriffserklärungen...4 Tabelle 2: Abkürzungserklärungen...4 Tabelle 3: Interne und externe Schnittstellen...11

4 Systemspezifikation Einleitung 1 Einleitung 1.1 Ziel & Zweck dieses Dokuments In diesem Dokument ist der Aufbau der Loggerkomponente und deren Umsysteme beschrieben. Ein wichtiger Teil davon ist die Softwarearchitektur. 1.2 Begriffe & Abkürzungen Begriff Erklärung Tabelle 1: Begriffserklärungen Abkürzung Erklärung HSLU SWK "Softwarekomponenten"; Modulbezeichnung HSLU gat Namenskürzel für Galliker Thomas ste Namenskürzel für Stocker Elias gam Namenskürzel für Gasser Martin STASS Steuerungsausschuss RMI Remote Method Invocation CORBA Common Object Request Broker Architecture Tabelle 2: Abkürzungserklärungen TA.SWK.F1001 Projekt Message-Logger Team 10 4 / 13

5 Systemspezifikation Systemübersicht 2 Systemübersicht Das gesamte System besteht aus total vier Komponenten, welche über definierte Schnittstellen miteinander kommunizieren. Nachfolgende Abbildung illustriert das System mit den Komponenten und den dazwischen bestehenden Abhängigkeiten grafisch: Abbildung 1: Systemübersicht als Komponentendiagramm Eine Anwendung (hier: Test-Applikation) möchte verschiedene Informationen als Log-Nachrichten an einen Log-Server senden. Dafür verwendet sie eine Logger Komponente. Für diese Logger Komponente wurde ein Logger Interface spezifiziert, welches die Design-Eigenschaften der Logger Komponente beeinflusst. Die Logger Komponente implementiert schliesslich Methoden zur Übermittlung von Log Nachrichten an die Server Komponente. Die Server Komponente ihrerseits ist verantwortlich für den Empfang und das persistente Ablegen von Log Nachrichten. Sie stellt aber auch Methoden zum Auslesen von Log Nachrichten zur Verfügung. Zur Visualisierung der Log Nachrichten wird eine Viewer Komponente entwickelt. Mit Hilfe dieser Viewer Komponente können Nachrichten aufgelistet, sortiert und gefiltert werden. TA.SWK.F1001 Projekt Message-Logger Team 10 5 / 13

6 3 Softwarearchitektur 3.1 Komponenten Softwarearchitekturen bergen oft einen hohen Grad an Komplexität in sich. Um sich einen Überblick über die Architektur zu verschaffen ist eine Grafik sehr hilfreich. Um eine Softwarearchitektur zu visualisieren gibt es viele verschiedene Methoden, wovon eine davon das Komponentendiagramm ist. Das nachfolgend abgebildete Komponentendiagramm zeigt eine bestimmte Sicht auf die Struktur des Gesamtsystems. Es beinhaltet sowohl logische Programmeinheiten (Components) sowie Schnittstellen (Interfaces). Abbildung 2: Komponentendiagramm In der Iteration 2 wurde das Komponentensystem um eine weitere Komponente, "CorbaLogger", erweitert. Die Komponente "CorbaLogger" implementiert die CORBA Schnittstelle zum Message-Logger Server. Im Komponentendiagramm ist diese neue Komponente blau eingefärbt. 3.2 Klassen Um die Komponenten einwenig detaillierter darzustellen, wurde ein Klassendiagramm erstellt. Ein Klassendiagramm zeigt den Aufbau von Klassen mit deren Methoden und Attributen. Zwischen den Klassen werden auch ihre Beziehungen untereinander dargestellt. Ebenfalls ersichtlich sind die Details der Interfaces. Um eine bessere Übersicht zu gewährleisten wurden die Klassendiagramme auf einzelne Teildiagramme entsprechend der jeweiligen Komponenten aufgetrennt Test-Applikation Die Test-Applikation instanziiert die Logger Komponente und generiert in unregelmässigen Abständen Fehlermeldungen. Wird eine Fehlermeldung geworfen, ruft die Test-Applikation die Methode log(loglevel, String) der Logger Komponente auf. Die Fehlermeldungen werden mithilfe der Klasse MessageThread geworfen. Zusätzlich instanziiert die Test-Applikation die Klasse LoggerConfig, welche zur Konfiguration des Loggers benötigt wird. Über das GUI der Test-Applikation kann die Logger Komponente konfiguriert werden. Dies beinhaltet die Änderung des LogLevels und der ServerUri des Loggers. TA.SWK.F1001 Projekt Message-Logger Team 10 6 / 13

7 Abbildung 3: Klassendiagramm der Test-Applikation Logger Die Klasse Logger implementiert das vom Interface-Team definierte Interface "ILogger". ILogger gibt die Designvorgabe, dass Logger die Methode "log(loglevel, String)" implementieren muss. Die zweite Abhängigkeit führt zum Interface IServerTeam10. Dieses Interface dient seinerseits zur Abstrahierung der Implementation der Server-Komponente. Logger nutzt die Implementation von IServerTeam10 um Nachrichten von der Applikation zum Server weiterzuleiten. Als Übertragungstechnologie wird das Remote Computing Framework "RMI" (Remote Method Invocation) genutzt. Die gemeinsam genutzten RMI Methoden wurden nach einem Refactoring in die statische Klasse "RMI" abgelegt. Abbildung 4: Klassendiagramm der Logger-Komponente CorbaLogger Die Klasse CorbaLogger implementiert das zu Beginn der Iteration 2 definierte CORBA Interface. TA.SWK.F1001 Projekt Message-Logger Team 10 7 / 13

8 Viewer Der Viewer dient dem Monitoring der Fehlermeldungen der Test Applikation. Der Viewer nutzt die Implementation von IServerTeam10, um die Fehlermeldungen vom Server zu holen. Mithilfe des zusätzlichen kleinen GUIs ViewerSettings können die Meldungen gemäss ihrem LogLevel gefiltert werden. Abbildung 5: Klassendiagramm der Viewer-Komponente Server Die Klasse ServerTeam10 implementiert das Interface IServerTeam10 mit den vorgegebenen Methoden "getlogmesssages()", "getlogmessages(int)" sowie "log(message)". Die beiden erstgenannten Methoden werden von der Klasse Viewer genutzt, um Log-Nachrichten anzuzeigen. Die letztgenannte Methode wird von der Klasse Logger genutzt, um Nachrichten von der Client-Applikation an den Server zu senden. Die Klasse ServerTeam10 nutzt als Übertragungstechnologie "Remote Method Invocation" (RMI). Wie alle anderen Klassen, welche RMI nutzen, werden auch in ServerTeam10 Methoden aus der gemeinsamen RMI- Codebasis "common.rmi" verwendet. Abbildung 6: Klassendiagramm der Server-Komponente TA.SWK.F1001 Projekt Message-Logger Team 10 8 / 13

9 3.3 Sequenzielle Abläufe Während Klassen- und Komponentendiagramme den funktionellen Umfang des Softwareprodukts zeigen, werden nachfolgend zwei Sequenzdiagramme abgebildet, welche das Verhalten und die Interaktion zwischen den Komponenten wiedergeben soll. Das erste Sequenzdiagramm zeigt den sequenziellen Ablauf der Log-Prozedur. Der Benutzer hat die Möglichkeit, über die Test-Applikation das Generieren von Log- Nachrichten zu starten und zu stoppen. Abbildung 7: Sequenzdiagramm Aufzeichnen von Log-Nachrichten Das Auslesen der Nachrichten mit Hilfe des Viewers wird in der nachfolgenden Abbildung illustriert: Abbildung 8: Sequenzdiagramm Anzeigen von Log-Nachrichten TA.SWK.F1001 Projekt Message-Logger Team 10 9 / 13

10 3.4 Softwareverteilung Nirgends ist die Planung der Softwareverteilung (engl. "Software Deployment") so wichtig wie bei verteilten Systemen. Aus diesem Grund wurde der Thematik erhöhte Priorität geschenkt. Die Minimalkonfiguration des vorliegenden Projektsystems besteht aus drei unabhängigen Deployment- Instanzen: Ein Computer auf welchem die Test-Applikation ausgeführt wird, ein Computer auf welchem der Viewer ausgeführt wird, sowie ein Server, welcher als Message-Logger Server und Log-Nachrichten Speicher genutzt wird. Die Applikationen auf den beiden erstgenannten Computern können einschränkungslos auch auf demselben physischen System ausgeführt werden. Die nachfolgende Grafik stellt den Sachverhalt in einem Deployment-Diagramm darzustellen. Abbildung 9: Deployment-Diagramm 3.5 Schnittstellenspezifikation In der nachfolgenden Tabelle werden sämtliche interne und externe Schnittstellen in und um das Message- Logger Projekt festgehalten und beschrieben. Teilweise wurden die Schnittstellen vom Interface-Komitee festgelegt. Schnittstelle Domäne Beschreibung Benutzerschnittstelle "Test-App" Benutzerschnittstelle "Viewer" extern extern Über die Benutzerschnittstelle der Test-Applikation hat der Benutzer grundsätzlich zwei Möglichkeiten: 1) eine grafische Konfigurationsmöglichkeit, um die Logger-Komponente zu konfigurieren, d.h. z.b. den Log-Server oder den LogLevel festzulegen und 2) eine grafische Darstellung der generierten Log-Nachrichten Die Komponente Viewer enthält eine Benutzerschnittstelle, über welche der Benutzer die geloggten Nachrichten einsehen kann. Die Log- Nachrichten können je nach eingestelltem LogLevel-Filter angezeigt werden. TA.SWK.F1001 Projekt Message-Logger Team / 13

11 ILogger intern Die technische Schnittstelle ILogger gibt Designvorschriften für die Implementation der Logger Komponente. Sie definiert, dass die Komponente Logger mindestens die Methode "log(loglevel, String)" implementieren muss. ILoggerConfig intern Die technische Schnittstelle ILoggerConfig gibt Designvorschriften für die Implementation der LoggerConfig Komponente. Sie definiert, dass die Komponente LoggerConfig mindestens die Methoden "getconfig()" und setconfig(config) implementieren muss. IServerTeam10 intern Die technische Schnittstelle IServerTeam10gibt Designvorschriften für die Implementation der ServerTeam10 Komponente. Sie definiert, dass die Komponente ServerTeam10 mindestens die Methoden "getlogmesssages()", "getlogmessages(int)" sowie "log(message)" implementieren muss. IServerTeam10 wurde Team-intern definiert und enthält keine Restriktionen und Vorgaben des Interface-Komitees. ILoggerServerFactory intern Diese Schnittstelle wurde in Iteration 2 mit der Umsetzung des CORBA Loggers eingeführt. Sie wird von der Komponente "CorbaLogger" bereitgestellt und kann von Applikationen zur Implementierung des CorbaLoggers genutzt werden. ILoggerServerPOA intern Diese Schnittstelle wurde in Iteration 2 mit der Implementierung des CORBA Loggers eingeführt. Konfigurationsdatei intern Die Konfigurationsdateien "logger_config.config" (genutzt von Klasse Logger) sowie "server_config.config" (genutzt von Klasse ServerTeam10) stellen Software-interne Schnittstellen dar, welche in Format und Speicherort verbindliche Richtlinien erfüllen müssen. Log-Speicher intern Die von der Logger Komponente an den Server gesendeten Nachrichten müssen auf einem persistenten Speicher abgelegt werden. Dafür nutzt die Komponente Server eine Klasse "LogEntryGroup", welche Methoden zum Lesen und Schreiben von Log-Nachrichten implementiert. Tabelle 3: Interne und externe Schnittstellen TA.SWK.F1001 Projekt Message-Logger Team / 13

12 Abbildung 10: Klassendiagramm der definierten Schnittstellen TA.SWK.F1001 Projekt Message-Logger Team / 13

13 Systemspezifikation Design-Entscheide 4 Design-Entscheide 4.1 Persistieren der Log-Messages Die Hauptaufgabe des Logger-Servers ist es, die Nachrichten, welche geloggt werden, zu persistieren. Für diesen Zweck sind DBMS prädestiniert, jedoch ist die Verwendung einer Datenbank in der Aufgabenstellung explizit ausgeschlossen. Bei der Umsetzung einer Datei-Basierenden Lösung haben wir auf folgendes geachtet: Es soll nicht bei jeder geschriebenen Log-Nachricht eine grosse Datei neu geschrieben werden. Es soll möglich sein die letzten n Nachrichten vom Server zu lesen ohne dass das gesamte Log ins RAM gelesen werden muss. Dies wird in unserer Lösung dadurch erreicht, dass in einer einzelnen Log-Datei eine maximale Anzahl Einträge gespeichert wird. Ist die Datei "voll", wird automatisch eine neue Log-Datei angelegt. Jede Log- Datei hat das Erstelldatum im Dateinamen. Dadurch lässt sich leicht feststellen, welches die aktuellsten Log- Dateien sind und es müssen nicht alle Dateien gelesen werden, wenn der Viewer eine Anfrage für die aktuellsten Messages stellt. TA.SWK.F1001 Projekt Message-Logger Team / 13