Tool zur Überwachung von Windows-Diensten im Versicherungswesen: Graphische Umsetzung mit SWT

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1. Einleitung
1.1 Aufbau der Arbeit
1.2 Beschreibung des Praxisunternehmens

2. Hintergründe und Vorwissen
2.1 Das Ebenenkonzept
2.2 Concurrent Versions System
2.3. Definition Plug-in
2.4 Graphische Benutzeroberflächen
2.4.1 Java Foundation Classes
2.4.2 Standard Widget Toolkit und JFace
2.4.3 Vergleich Swing und SWT
2.5 Die Rich-Client-Plattform von Eclipse

3. Analyse
3.1 Ist-Zustand
3.2 Soll-Zustand

4. Entwurf und Umsetzung
4.1 Umsetzung als Plug-in mit Hilfe von Eclipse
4.2 Graphische Umsetzung mit SWT

5. Fazit und Ausblick

Anhang
Anhangsverzeichnis
Anhang 1: Standorte
Anhang 1: Standorte
Anhang 2: Screenshot – Services
Anhang 3: Screenshot – Ebenen
Anhang 4: Screenshot – Server
Anhang 5: Screenshot – Gestoppt
Anhang 6: Plugin.xml

Glossar

Quellenverzeichnis

Abbildungsverzeichnis

Abbildung 1: Das Ebenenkonzept 10

Abbildung 2: Screenshot CVS 13

Abbildung 3: Java Plug-in [int03]14

Abbildung 4: Bestandteile der JFC 17

Abbildung 5: MVC Ansatz 18

Abbildung 6: Vergleich Swing und Windows Look-and-Feel [int05]19

Abbildung 7: Client-Server-Modell [int07]20

Abbildung 8: Eclipse RCP Bestandteile 21

Abbildung 9: Screenshot Windows-Dienste 22

Abbildung 10: UML-Fachklassendiagramm Hilfsanwendung 23

Abbildung 11: Anwendungsfall 24

Abbildung 12: Manifest-Datei 26

Abbildung 13: Screenshot Extensions 27

Abbildung 14: Screenshot Graphische Oberfläche 29

Tabellenverzeichnis

Tabelle 1: Bestandteile der JFC und deren Funktion 17

Tabelle 2: Vergleich Swing und SWT 20

Tabelle 3: SWT-Klassen und deren Funktion 28

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1 Aufbau der Arbeit

Diese Projektarbeit gliedert sich in fünf Kapitel. Im ersten Kapitel wird das Praxisunternehmen, indem dieses Projekt durchgeführt wird, näher beschrieben. Das zweite Kapitel liefert Hintergründe und Vorwissen, die relevant sind, um die Realisierung der Praxisaufgabe zu verstehen und nachvollziehen zu können. Kapitel drei befasst sich mit der genaueren Analyse der Aufgabe. Es wird beschrieben, wie die momentane Situation ist und wie sie zukünftig aussehen soll. In Kapitel vier folgt die Beschreibung der konkreten Umsetzung. Die Arbeit endet im fünften Kapitel mit einem Fazit und einem Ausblick zu dieser Projektaufgabe.

Fachbegriffe und erklärungsbedürftige Ausdrücke werden im nachfolgenden Glossar näher erläutert. Sie sind beim ersten Auftreten kursiv und mit Sternchen markiert. Verwendete Abkürzungen, können im Abkürzungsverzeichnis nachgeschlagen werden und stehen beim ersten Auftreten im Text in Klammern hinter dem dazugehörigen Ausdruck. Quellenangaben sind mit eckigen Klammern und kursiv kenntlich gemacht.

1.2 Beschreibung des Praxisunternehmens

Die untersuchte Versicherung wurde als Haftpflichtversicherungsanstalt gegründet und ist mittlerweile nicht nur Spezialversicherer der Bauwirtschaft, sondern auch einer der größten deutschen Auto- und Haftpflichtversicherer.

Der Hauptsitz befindet sich in Hannover und weitere Niederlassungen sind in Berlin und München zu finden. Des Weiteren ist die untersuchte Versicherung mit drei Regionaldirektionen und über 30 Geschäftsstellen in Deutschland vertreten (siehe Anhang 1).

Der Informatikbereich der Versicherung in Hannover umfasst zurzeit ca. 230 Mitarbeiter und gliedert sich in die Abteilungen Ressourcenmanagement (IRM), Anwendungssysteme (IAS), Produktion Betrieb (IPB) und Produktion Service (IPS).

Die Aufgabe dieser Projektarbeit wurde in der GruppeZentrale Dienstegestellt, die unter anderem für Kobra^[1], Fachdatenextraktion^[2], Druckprogramme und für digitalisierte Schriftstücke (Images) im Allgemeinen zuständig ist.

2. Hintergründe und Vorwissen

2.1 Das Ebenenkonzept

Das Ebenenkonzept unterstützt den Softwareentwicklungszyklus bei der untersuchten Versicherung. Es ist relevant für die Aufgabenstellung dieser Projektarbeit, einerseits weil sich die Windows-Dienste, die überwacht werden sollen, auf verschiedenen Ebenen befinden und andererseits weil die gewünschte Anwendung diesem Prinzip entsprechend umgesetzt wird.

Das Ebenenkonzept sieht vier Ebenen vor, nämlich Entwicklung (E), Test (T), Systemintegration (S) und Produktion (P). Bevor ein neues oder geändertes Softwareprodukt den Sachbearbeitern der Versicherung zur Verfügung gestellt wird, muss es diese vier Ebenen durchlaufen, damit gesichert wird, dass nur zuverlässige und fehlerfreie Programme zur Bewältigung des täglichen Geschäfts genutzt werden.

Die folgende Graphik veranschaulicht die Reihenfolge der Ebenen und verdeutlicht, welche Personengruppen auf welche Ebene hauptsächlich Zugriff haben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Das Ebenenkonzept

Die erste der vier Ebenen ist die Entwicklungsebene. Hier geschieht die eigentliche Programmierung und Umsetzung. Der Programmcode wird geschrieben undkompiliert*. War dieser Vorgang erfolgreich und ist das Programm lauffähig, erfolgt der nächste Schritt, nämlich das ausführliche Testen auf der Testebene. Dafür wird das Programm von der Entwicklungsebene auf die Testebene geschoben.

Auf der Testebene wird von den Informatikkoordinatoren, die die Schnittstelle zwischen Entwicklern und Fachbereich-Mitarbeitern bilden, getestet, ob das Programm alle gestellten Anforderungen und Erwartungen erfüllt und fehlerfrei abläuft. In dieser Phase ist eine enge Zusammenarbeit zwischen Informatikkoordinatoren, Fachbereich und Entwicklern erforderlich.

Anschließend wird das Programm auf die Integrationsebene geschoben. Hier finden Tests in der gegebenLaufzeitumgebung*statt. Die Zusammenarbeit zwischen dem neuen Programm und anderen Softwareprodukten und Modulen wird getestet und eventuelle Konflikte festgestellt. Außerdem werden die Mitarbeiter, die zukünftig mit diesem Programm arbeiten sollen, im Umgang mit der neuen Software geschult und auf die Neuheiten vorbereitet.

Verläuft auch auf dieser Ebene alles erfolgreich und zufrieden stellend, folgt der letzte Schritt, das Schieben des Programms auf die letzte Ebene, die so genannte Produktionsebene. Das ist die Ebene, auf der die Sachbearbeiter arbeiten und reale Kundendaten und Verträge erfassen.

Dieses eben beschriebene Ebenenkonzept des untersuchten Versicherungsunternehmens hat viele Vorteile. Zum einen eröffnet es den Entwicklern die Möglichkeit, neue Softwareprodukte zu erstellen, zu testen und einzuführen, ohne dass dafür die Arbeit der Sachbearbeiter unterbrochen werden muss. Zum anderen, bieten die verschiedenen Ebenen eine realistische Testumgebung, da sie der Produktionsebene sehr ähneln. Durch das ausführliche Testen auf der Testebene kommt es nur selten dazu, dass ein fehlerhaftes Programm in Produktion geht und die Arbeit der Sachbearbeiter behindert. Ein weiterer Vorteil ist die Tatsache, dass grobe Fehler, z.B. das versehentliche Löschen einer Datenbank, die auf der Produktionsebene fatale Folgen hätten, auf den anderen Ebenen keine große Auswirkung haben und leicht rückgängig gemacht werden können.

Alles in allem besteht der größte Vorteil des Ebenenkonzepts folglich darin, dass Entwickler, Programmtester und Sachbearbeiter unabhängig voneinander und parallel arbeiten können.

2.2 Concurrent Versions System

Eine andere Technologie, die in der untersuchten Versicherung verwendet wird, um den Softwareentwicklungszyklus zu unterstützen, ist das Concurrent Versions System (CVS), ein Versionsverwaltungssystem, das hauptsächlich im Zusammenhang mit Software-Quelltext verwendet wird. CVS wird überwiegend für zwei Aufgaben eingesetzt, nämlich Historienverwaltung und Zusammenarbeit bzw. Programmierung im Team.

Die Historienverwaltung ermöglicht es, den momentanen Zustand eines Programms mit seinem Zustand an einem bestimmten anderen Zeitpunkt zu vergleichen und gegebenenfalls das Programm in einen früheren Zustand zurückzuversetzen. Die Verwaltung erfolgt dadurch, dass die verschiedenen Versionen desQuellcodeseines Software-Projekts an einer zentralen Stelle, dem so genanntenRepository*gespeichert werden. Bei Veränderungen bleiben so trotzdem alle früheren Versionen erhalten und sind nicht nur einsehbar, sondern auch widerherstellbar.

Der zweite Einsatzbereich von CVS ist die Koordination der Arbeit von mehreren Entwicklern am gleichen Projekt. Das geschieht dadurch, dass die Teammitglieder ihre Arbeit in ihren eigenen Arbeitsbereichen isoliert von den anderen erledigen und ihre Ergebnisse anschließend allgemein verfügbar machen. Das funktioniert, indem die Entwickler eine Arbeitskopie des Projekts von CVS anfordern, dieser Vorgang wird auch alsChecking out(deutsch:ausleihen) bezeichnet. Nun kann jeder Entwickler frei und ohne Konflikte mit anderen Programmierern an seiner Arbeitskopie arbeiten Es gibt keine Konflikte, weil alle Kopien unabhängig voneinander sind. Beendet ein Entwickler seine Veränderungen, sendet er diese mit einem Kommentar, der beschreibt, was der Zweck der Veränderung war, an den CVS-Server mit Hilfe des Befehlscommit(deutsch:übergeben).

Wenn nun andere Teammitglieder CVS abfragen, werden sie herausfinden, dass die Hauptkopie kürzlich verändert wurde und sie haben die Möglichkeit, ihre eigenen Arbeitskopien von CVS aktualisieren zu lassen. Damit dieses Prinzip funktioniert, verwendet CVS ein Verzweigungsmodell zur Unterstützung mehrerer Arbeitszyklen, die isoliert, aber dennoch abhängig voneinander sind. Eine Verzweigung entspricht etwa einem gemeinsamen Arbeitsbereich, der von den Teammitgliedern im Fall von Änderungen an einem Projekt aktualisiert wird. Eine spezielle Verzweigung namensHEAD(deutsch:Kopf / Spitze), stellt den Hauptteil der Arbeit im Repository dar. Abbildung 2 zeigt ausschnittsweise die HEAD Verzweigung der Versicherung.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Screenshot CVS

Ein besonderer Fall besteht dann, wenn zwei Entwickler in ihren Arbeitskopien unterschiedliche Veränderungen an dem gleichen Stück Quellcode vornehmen und beide ihre Veränderungen mittelscommitabschicken. Diese Situation wird als Konflikt bezeichnet und von CVS entdeckt und markiert, damit die beiden betroffenen Entwickler darauf aufmerksam gemacht werden.

Es ist empfehlenswert, dass die Hauptkopie immer in einem funktionsfähigen Zustand ist. Deshalb ist eine übliche Strategie bei Projekten, immer erst eine Aktualisierung zu machen, bevor die Arbeit an größeren Veränderungen begonnen wird und einencommiterst dann zu machen, wenn die Veränderungen vollständig getestet und lauffähig sind. [int01]

Zusammenfassend ermöglicht CVS gleichzeitiges Arbeiten an demselben Projekt und erleichtert die Übersicht und Integration von Veränderungen.

Bei der Aufgabe dieser Projektarbeit wurde CVS eingesetzt, einerseits, um die verschiedenen Versionen in unterschiedlichen Entwicklungszeitpunkten zu verwalten und andererseits, um die Anwendung den Auftraggebern, also den IAS Mitarbeitern, zur Verfügung zu stellen.

2.3. Definition Plug-in

Ein Plug-in ist ein Programm, das ein Softwareprodukt und dessen Funktionalität erweitert. Das WortPlug-instammt vom englischento plug inund bedeuteteinstöpselnbzw. anschließen. Andere Bezeichnungen für Plug-in sind Add-on, Extension, Erweiterungsmodul oder Zusatzmodul.

Eine Vielzahl an Softwareprodukten verfügt über definierte Datenschnittstellen, die das Einbinden von Plug-ins erlauben. [int02]. Es gibt verschiedene Arten von Plug-ins, z.B. Server Plug-ins und Browser Plug-ins, die die Funktionsweise eines Server- bzw. Browserdienstes erweitern. Ein wichtiges Plug-in ist das Java Plug-in (siehe Abbildung 3), eine Softwarekomponente, mit der man Java Applets in einem Webbrowser ablaufen lassen kann. Java Applets sind Java Programme, die benötigt werden, um Graphikeffekte zu erzeugen oder Spiele in Webbrowsern auszuführen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Java Plug-in [int03]

Andere bekannte und weit verbreitete Plug-ins sind derAdobe Reader, der das Betrachten und Drucken von PDF-Dokumenten^[3]ermöglicht undQuickTimezur Wiedergabe von Videos innerhalb eines Webbrowsers.

Die Definition eines Plug-ins ist für diese Projektarbeit nötig, da das zu erstellende Werkzeug als Plug-in realisiert werden soll.

2.4 Graphische Benutzeroberflächen

Eine Software-Komponente, die die Interaktion zwischen Computernutzer und Maschine über graphische Symbole ermöglicht, wird alsgraphische Benutzeroberflächebezeichnet. Synonyme Bezeichnungen sind der englische BegriffGraphical User Interface (GUI)und dessen wörtliche Übersetzunggraphische Benutzerschnittstelle.

Vor dem Konzept von GUIs, das aus den 1970er Jahren stammt, gab es noch keine graphische Interaktionsmöglichkeiten und der Benutzer konnte dem Computer nur über die Tastatur Befehle geben. Ein Beispiel für so ein System ist Microsofts erstes Betriebssystem MS-DOS (Microsoft Disk Operating System). Die Interaktion mit der Maschine über graphische Symbole erleichtert das Arbeiten am Computer erheblich und steigert die Benutzerfreundlichkeit von Programmen.

Bei GUI-Anwendungen öffnet sich zunächst ein Hauptfenster, wenn das Programm gestartet wird. GUI ermöglicht es, solch ein Fenstersystem auszublenden, es an die gesamte Bildschirmgröße anzupassen oder dessen Größe und Position zu verändern.

Ein Fenster enthält graphische Elemente und Darstellungen, die die GUI- Anwendungssoftware bedienbar machen. Sie werden Steuerelemente oder Widgets^[4]genannt und können mittels eines Zeigegeräts, meistens einer Maus, gesteuert werden.

Jedes GUI-Element wird durch eineKlasse*repräsentiert, von derObjekte*erzeugt und für die eigene Anwendung genutzt werden können. Es können bereits programmierteMethoden*übernommen werden oder eigene Methoden erstellt werden, die das Verhalten der Anwendung bei Benutzer-Aktivität festlegen.

Eine graphische Benutzeroberfläche und ihr Verhalten bei Benutzer-Interaktion werden auch alsLook-and-Feeleiner Anwendung bezeichnet.

2.4.1 Java Foundation Classes

Für die Erstellung graphischer Benutzeroberflächen mit Java stehen dieStandardklassenbibliotheken*Java Foundation Classes (JFC)zur Verfügung. Sie sind in einem Gemeinschaftsprojekt der Unternehmen Sun, Netscape, IBM und Apple entstanden. Ursprünglich wurde für die Erstellung graphischer Benutzerschnittstellen dasAbstract Window Toolkit (AWT)verwendet, das in dem Java-Paket*java.awtenthalten ist und die Implementierung graphischer Benutzeroberflächen mit Fenstern, Buttons, Feldern usw. ermöglicht. Dabei wird jede Komponente als Objekt von einer eigenen Klasse erzeugt und verfügt über entsprechende eigene Methoden, z.B. um Beschriftungen anzubringen.

AWT lässt jedoch noch einige Wünsche offen, denn um die Programmierung plattformunabhängiger graphischer Oberflächen zu ermöglichen, stehen nur Widgets zur Verfügung, die auf allen Plattformen unterstützt werden und komplexere Oberflächenelement wie Bäume und Tabellen, welche nicht auf allen Betriebssystemen vorhanden sind, wurden nicht in das AWT aufgenommen. Das hatte zur Folge, dass viele und umfangreiche herstellerbezogene Bibliotheken entstanden, die die Defizite des AWT ausgleichen sollten. Eine davon ist das von Sun geschaffene Swing, das im Paketjavax.swingzur Verfügung gestellt wird und erstmals Ende 1997 als externe Bibliothek ausgeliefert wurde. Swing ist demnach eine Weiterentwicklung von AWT und ermöglicht die Verwendung komplexer graphischer Oberflächen wie Bäume oder Tabellen.

Swing-Klassen beginnen immer mit dem BuchstabenJ, um sich von den gleichnamigen Klassen des AWT zu unterscheiden, z.B. heißt die Fenster-Klasse im AWT-PaketFrameund entsprechend im Swing-PaketJFrame.

Zusammenfassend entstanden die JFC also mit der Intention das Entwickeln komplexer, interaktiver Applikationen zu vereinheitlichen und das Entstehen von zahlreichen herstellerbezogenen Bibliotheken zu verhindern. Seit Ende 1998 sind sie fester Bestandteil der Java-Laufzeitumgebung und enthalten folgende Programmierschnittstellen für die Erstellung von GUIs:

Abbildung in dieser Leseprobe nicht enthalten^{[5] [6]}

Abbildung 4: Bestandteile der JFC

Die nachfolgende Tabelle erläutert, welche Funktion die einzelnen Komponenten innerhalb der JFC haben[int04]:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Bestandteile der JFC und deren Funktion

Java2D ermöglicht die Darstellung und Modifikation 2-dimensionaler Objekte.

Mit Accessibility wird ein Paket zur Verfügung gestellt, das die Anpassung von Benutzerschnittstellen an Benutzer mit Behinderungen oder mit eingeschränkten Interaktionsfähigkeiten erlaubt. Es umfasst spezielle Bildschirmdarstellungen und die Verwendung bestimmter Ein- und Ausgabegeräte (z.B. Mikrofone, Spezialtastaturen).

Das Verfahren Drag & Drop ermöglicht den Transport von Daten zwischen Komponenten, dazu werden die Daten beim Datentransfer verpackt und mit einer plattformunabhängigen Datentyp-Beschreibung versehen.

2.4.2 Standard Widget Toolkit und JFace

Im Jahr 2001 entschied sich das Team von IBM gegen die JFC und entwickelte stattdessen für die Eclipse*-Plattform dasStandard Widget Toolkit (SWT), das kontinuierlich gepflegt wird. SWT ist der Hauptkonkurrent von AWT und Swing und stellt GUI-Komponenten über native^[7]Komponenten des Betriebssystems zur Verfügung.

JFace erweitert die Funktionen von SWT und dient als Schnittstelle zwischen SWT und der Eclipse-Plattform. Es setzt aus den von SWT gelieferten Basiskomponenten komplexere Widgets zusammen und erleichtert die Entwicklung von Desktop-Anwendungen auf SWT-Basis, indem es SWT um den Model-View-Controller Ansatz (MVC) ergänzt. MVC gliedert ein Programm in drei Anwendungsschichten, nämlich Model, View und Controller. Das Model verwaltet die Daten und die Verarbeitungslogik, eine View stellt die Daten des Models für den Benutzer an der Bildschirmoberfläche dar und ein Controller verbindet die Views mit dem Model. [plug-in]

Die nachfolgende Abbildung verdeutlicht den Zusammenhang zwischen den drei Schichten:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: MVC Ansatz

2.4.3 Vergleich Swing und SWT

Bei der graphischen Umsetzung einer Anwendung muss eine Entscheidung getroffen werden zwischen einer Umsetzung mit JFC oder mit SWT. Fällt die Entscheidung auf JFC, wird meist das moderne Swing gewählt und nicht das veraltete AWT. Da die Unterschiede zwischen AWT und Swing bereits erläutert wurden, wird im Folgenden nur ein Vergleich zwischen Swing und SWT aufgestellt.

Der größte Unterschied zwischen Swing und SWT besteht darin, dass SWT nicht nur Widgets anbietet, die auf allen Zielplattformen zur Verfügung stehen, sondern auch plattformspezifische, die nur auf einer bestimmten Plattform fehlerfrei verarbeitet werden können. Es enthält also zum einen native Widgets für ein originäres Look-and-Feel (wie AWT) und stellt zum anderen auch komplexe Widgets für moderne GUIs zur Verfügung (wie Swing). Da SWT Komponenten des Systems einbindet, werden seine Elemente alsheavyweight(schwergewichtig) bezeichnet. Swing-Elemente werden hingegenlightweight (leichtgewichtig) genannt, weil Swing alle Widgets selbst zeichnet. Damit ist Swing zwar plattformunabhängig, bietet aber nie die Möglichkeit eine Anwendung zu entwickeln, deren Look-and-Feel identisch zu den originären Plattform-Widgets ist, wie Abbildung 6 zeigt. Der rechte Taschenrechner hat das originäre Windows Look-and-Feel, von dem sich der linke Taschenrechner, dessen Graphik mit Swing programmiert wurde, deutlich unterscheidet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Vergleich Swing und Windows Look-and-Feel [int05]

Die folgende Tabelle listet im Vergleich wichtige Eigenschaften von Swing und SWT auf, wobei die Vorteile dick hervorgehoben werden[int06]:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Vergleich Swing und SWT

Es wird deutlich, dass beide Technologien sowohl Vor- als auch Nachteile haben. Für jede Anwendung muss individuell eine Entscheidung getroffen werden, abhängig davon auf welche Kriterien man besonders Wert legt.

In dieser Projektarbeit erfolgt die Umsetzung mit SWT, weil die Aufgabe als Plug-in innerhalb der Eclipse-Plattform realisiert wird und SWT (wie im nächsten Abschnitt näher erläutert wird) ein Bestandteil der Eclipse Rich-Client-Plattform ist.

[...]

^[1]Software zum Suchen und Anzeigen von Kundendaten und Verträgen

^[2]System zum Herausfiltern von Daten aus digitalisierten Schriftstücken mit Hilfe definierter Regeln

^[3]Portable Document Format (deutsch: portables Dokumentenformat), ein plattformunabhängiges Dateiformat für Dokumente

^[4]zusammengesetztes Wort auswindow(deutsch:Fenster) undgadget(deutsch:Zubehörgerät)

^[5]deutsch:Barrierefreiheit

^[6]deutsch:Ziehen & Fallenlassen

^[7]in Bezug auf Betriebssysteme „im Lieferumfang enthalten“