Elektrotechnik und Informatik - elib.dlr.de · Im Rahmen der Diplomarbeit sollen Konzept und Design für ein Open Sour- ce Werkzeug realisiert werden, mit dessen Hilfe WebDAV-Anwendungen

Elektrotechnik und Informatik

DIPLOMARBEIT

Entwicklung eines grafikunterstützten Debugging-Werkzeugszur Implementierung von WebDAV-Applikationen

vorgelegt von:

Hans Jochen WüstMatr.-Nr.: 609058

betreut von:

Prof. Dr.-Ing. habil. Hans WojtkowiakDr.-Ing. Bernd Klose(Universität Siegen)

Dipl.-Math. Andreas SchreiberDipl.-Inform. Markus Litz

(Deutsches Zentrum für Luft- und Raumfahrt - Köln)

Tag der Ausgabe: 14.12.2007 Tag der Abgabe: 13.06.2008

Abstract

This document presents the results of the diploma thesis „Entwicklung ei-nes grafikunterstützten Debugging-Werkzeugs zur Implementierung vonWebDAV-Applikationen“. In cooperation with the German Aerospace Cen-ter an open source tool will be realized to graphically test and evaluate thecommunication between WebDAV applications. First of all the necessarybasics are discussed. Following this the developed solution is introducedand the concepts of the various subsystems are explained. Based on theseresults the design and implementation of the subsystems are described. Acase of application shows the practical use of the developed concepts. Fi-nally problems having occurred in the course of the development will beexamined, and an outlook for possible developments and optimizing of theprototype will be given.

Im Rahmen dieser Ausarbeitung werden die Ergebnisse der Diplomar-beit „Entwicklung eines grafikunterstützten Debugging-Werkzeugs zur Im-plementierung von WebDAV-Applikationen“ präsentiert. In Kooperationmit dem Deutschen Zentrum für Luft- und Raumfahrt wird ein Open-Source-Werkzeug realisiert, mit dessen Hilfe die Kommunikation zwischenWebDAV-Anwendungen grafikunterstützt getestet und ausgewertet wer-den kann. Zunächst werden die benötigten Grundlagen erörtert. Im An-schluss daran wird das entwickelte Lösungskonzept vorgestellt und die Ent-würfe der verschiedenen Subsysteme werden dargelegt. Das darauf aufbau-ende Design und die Umsetzung der Entwürfe werden beschrieben. Die Pra-xistauglichkeit der erarbeiteten Konzepte wird anhand eines Anwendungs-falls belegt. Abschließend werden im Laufe der Entwicklung aufgetreteneProbleme betrachtet und ein Ausblick auf mögliche Weiterentwicklungenund Optimierungen des Prototypen skizziert.

Inhaltsverzeichnis

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Grundlagen 52.1 Software Engineering . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Vorgehensmodelle . . . . . . . . . . . . . . . . . . . . . . 62.1.2 Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . 11

2.2 Open Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Lizenzmodelle . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 SourceForge.net . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Architektur- und Entwurfsmuster . . . . . . . . . . . . . . . . 192.3.1 Einzelstück-Muster . . . . . . . . . . . . . . . . . . . . . 202.3.2 Beobachter-Muster . . . . . . . . . . . . . . . . . . . . . 212.3.3 Dekorierer-Muster . . . . . . . . . . . . . . . . . . . . . 222.3.4 Model-View-Controller-Muster . . . . . . . . . . . . . . 23

2.4 Netzwerkprotokolle . . . . . . . . . . . . . . . . . . . . . . . . . 252.4.1 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.4.2 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.4.3 WebDAV . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.6 Extensible Markup Language . . . . . . . . . . . . . . . . . . . 402.7 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.7.1 Vererbung und Polymorphie . . . . . . . . . . . . . . . . 432.7.2 Netzwerk-Kommunikation . . . . . . . . . . . . . . . . . 47

I

Inhaltsverzeichnis

2.7.3 Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3 Konzept 51

3.1 Marktanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2 Gesamtkonzept . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.3 Gliederung des Entwurfs . . . . . . . . . . . . . . . . . . . . . . 56

3.3.1 Grafische Benutzeroberfläche . . . . . . . . . . . . . . . 573.3.2 Netzwerkfunktionalität . . . . . . . . . . . . . . . . . . 583.3.3 Nachrichtenhistorie . . . . . . . . . . . . . . . . . . . . . 593.3.4 Plugin-Architektur . . . . . . . . . . . . . . . . . . . . . 603.3.5 Konzepte für Plugins . . . . . . . . . . . . . . . . . . . . 613.3.6 Sonstige Konzepte . . . . . . . . . . . . . . . . . . . . . 63

3.4 Arbeitsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . 653.5 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 68

4 Design und Implementierung 69

4.1 Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.2 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.2.1 Relais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.2.2 Nachrichtenhistorie . . . . . . . . . . . . . . . . . . . . . 774.2.3 Plugin-Verwaltung . . . . . . . . . . . . . . . . . . . . . 814.2.4 Grafische Benutzeroberfläche . . . . . . . . . . . . . . . 854.2.5 Protokollierung . . . . . . . . . . . . . . . . . . . . . . . 89

4.3 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.3.1 Kopfdaten-Plugin . . . . . . . . . . . . . . . . . . . . . . 914.3.2 XML-Ansicht-Plugin . . . . . . . . . . . . . . . . . . . . 944.3.3 XML-Baum-Plugin . . . . . . . . . . . . . . . . . . . . . 964.3.4 Aufzeichnungs-Plugin . . . . . . . . . . . . . . . . . . . 984.3.5 Bearbeitungs-Plugin . . . . . . . . . . . . . . . . . . . . 99

4.4 Internationalisierung . . . . . . . . . . . . . . . . . . . . . . . . 1014.5 Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 1034.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 105

II

Inhaltsverzeichnis

5 Ergebnisse 1075.1 Voraussetzungen und Umgebung . . . . . . . . . . . . . . . . . 1075.2 Konfiguration des DAVInspectors . . . . . . . . . . . . . . . . . 1095.3 Einsatz im Anwendungsfall . . . . . . . . . . . . . . . . . . . . 111

6 Zusammenfassung und Ausblick 119

Literaturverzeichnis 123

Glossar 133

CD-ROM 141

A Softwarekonfigurationsmanagement 143

B Programmierrichtlinien 147

C Lastenheft 151

D Marktstudie 187

E Pflichtenheft 233

III

Inhaltsverzeichnis

IV

1 Einleitung

Die rechnerbasierte Verarbeitung und Bereitstellung von Daten verlangtaufgrund von stetig wachsenden Anforderungen und immer größer werden-den Datenmengen nach neuen Lösungskonzepten. Komplexe Projektstruk-turen, stetig größer werdende Datenmengen und auch räumlich verteilteArbeitsgruppen erfordern effektive Werkzeuge zur Unterstützung und Op-timierung der Datenverwaltung [AGG03].

Das HTTP-Protokoll ist ein weit verbreitetes und stabiles Protokoll, das eserlaubt, Informationen vielen Nutzern ohne großen technischen Aufwandzur Verfügung zu stellen. Allerdings sind die Benutzer damit nicht direktin der Lage auch Daten zu bearbeiten und zu verwalten. An dieser Stellesetzt das WebDAV-Protokoll als Erweiterung des HTTP-Protokolls an undstellt die nötigen Funktionalitäten zur Verfügung.

Da sich das WebDAV-Protokoll derzeit noch in der „Etablierungsphase“befindet, ist die Zahl der Anwendungen mit Unterstützung des WebDAV-Protokolls begrenzt, und auch entsprechende Entwicklungswerkzeuge sindnoch nicht für alle Anwendungsfälle vorhanden. So existieren zwar Pro-dukte für den Test von WebDAV-Server-Anwendungen, und auch allge-meine Netzwerkanalyse-Programme sind verfügbar, jedoch kein Werkzeug,das die Möglichkeit der Fehlersuche sowohl für Client- als auch Server-Anwendungen in Hinblick auf das WebDAV-Protokoll bietet. Ziel der vorlie-genden Arbeit ist es, die Basis für solch ein Werkzeug zu schaffen. Diesessoll dem Entwickler von WebDAV-Applikationen die Fehlersuche und denTest von Server- und Client-Anwendungen erleichtern.

Die vorliegende Arbeit entstand im Rahmen einer Kooperation zwischendem Deutschen Zentrum für Luft- und Raumfahrt e.V. (DLR) und der Uni-versität Siegen. Betreut wurde die Arbeit auf universitärer Seite durch

1

1 Einleitung

die Fachgruppe Technische Informatik, geleitet von Prof. Dr.-Ing. habil.Hans Wojtkowiak. Ansprechpartner war Dr.-Ing. Bernd Klose. Ansprech-partner in der Einrichtung „SC – Verteilte Systeme und Komponenten-software“ des Deutschen Zentrums für Luft- und Raumfahrt waren Ab-teilungsleiter Dipl.-Math. Andreas Schreiber und Dipl.-Inform. MarkusLitz.

1.1 Motivation

Das deutsche Zentrum für Luft- und Raumfahrt ist eine Forschungseinrich-tung der Bundesrepublik Deutschland mit den Schwerpunkten Luftfahrt,Raumfahrt, Energie und Verkehr. Das Spektrum der Forschungen reichtvon der Grundlagenforschung bis hin zu fertigen Produkten und Anwen-dungen. Hierbei werden sowohl nationale, internationale als auch industri-elle Kooperationen umgesetzt.

Wissenschaftliche Einrichtungen müssen in der Regel eine große Mengevon Daten verwalten. Hierbei sind üblicherweise sowohl die Menge der Da-ten als auch die vielen verschiedenen Formate und Prozesszugehörigkei-ten der Daten problematisch. Zu einem Experiment gehören zum BeispielDokumentationen der verschiedenen Arbeitsschritte, Eingabe- oder Mess-daten, Modelle sowie Ergebnisdaten. Zusätzlich können die Daten nochin verschiedenen Versionen vorliegen. Für das Management dieser Datenwird im DLR auf Clientseite die Anwendung „DataFinder“ auf Grundla-ge des WebDAV-Protokolls eingesetzt. Als Server kann dafür jede Server-Software eingesetzt werden, welche die WebDAV-Spezifikation [RFC4918]hinreichend implementiert. Neben kommerziellen Servern (z. B. „Tami-no“ der Software AG oder „SharePoint“ von Microsoft) werden zunehmendOpen Source Produkte eingesetzt. Im DLR wird daher an dem Open Sour-ce WebDAV-Server „Catacomb“ mitentwickelt. Für das Entwickeln des Ser-vers und des Clients sind genaue und automatisierte Tests sowie eine ein-fache Möglichkeit zur Fehlersuche eine wichtige Hilfe.

2

1.2 Aufgabenstellung

1.2 Aufgabenstellung

Im Rahmen der Diplomarbeit sollen Konzept und Design für ein Open Sour-ce Werkzeug realisiert werden, mit dessen Hilfe WebDAV-Anwendungengrafikunterstützt getestet und ausgewertet werden können. Dabei soll dasWerkzeug als Proxy zwischen Client und Server fungieren, um eine Analyseder Kommunikation zwischen Server und Client zu ermöglichen. Die Reali-sierbarkeit soll durch eine prototypische Implementierung des Werkzeugsbelegt werden. Lasten- und Pflichtenheft sind obligatorischer Bestandteilder Arbeit (siehe Anhang).

Weiterhin soll eine Marktstudie (siehe Anhang) durchgeführt werden, inderen Rahmen zu ermitteln ist, welche Werkzeuge bereits auf dem Marktangeboten werden und ob eines dieser Werkzeuge für die geplanten Er-weiterungen als Basis genutzt werden kann oder ob eine Eigenentwick-lung nötig wird. Falls Letzteres der Fall sein sollte, muss noch eineEntscheidung über die zu verwendende Programmiersprache gefällt wer-den.

1.3 Gliederung

Kapitel 2 befasst sich mit den verwendeten Technologien und Prinzipien.Dieses Kapitel soll dem Leser das nötige theoretische Basiswissen vermit-teln, um sich mit den restlichen Teilen der Ausarbeitung auseinanderset-zen zu können. Kapitel 3 erläutert die Ideen und Überlegungen, die derUmsetzung zugrunde liegen. Danach werden in Kapitel 4 das Design unddie Implementierung der Anwendung betrachtet. Besonderes Augenmerkwird dabei auf die Realisierung der in Kapitel 3 vorgestellten Konzepte ge-legt. Kapitel 5 stellt die Ergebnisse der validierten Arbeit vor. Weiterhinwird ein Anwendungsszenario der Software präsentiert. Kapitel 6 bildetden Abschluss der Ausarbeitung und fasst alle Ergebnisse zusammen. DesWeiteren werden bei der Erstellung der Anwendung gesammelte Erfahrun-gen und mögliche zukünftige Entwicklungen aufgezeigt.

3

1 Einleitung

4

2 Grundlagen

In diesem Kapitel werden die theoretischen Grundlagen, die für das Ver-ständnis der Arbeit und die Nachvollziehbarkeit der Entscheidungen nötigsind, erörtert. Hierbei wird auf die jeweiligen Technologien und Konzeptein nötiger Detailtiefe eingegangen. Für weiterführende Informationen seider Leser auf die angegebene Literatur verwiesen.

2.1 Software Engineering

Als Konsequenz aus der sogenannten „Softwarekrise“ der 1960er Jahre[SOM01] wurden Techniken und Methoden entwickelt, die es dem Erstellervon Software erlauben, die Kontrolle über das Produkt auch bei komplexenund umfangreichen Aufgaben zu behalten. So ist der damals geprägte Be-griff „Software Engineering“ mittlerweile nicht nur als technische Disziplinzu verstehen, sondern Software Engineering umfasst zum Beispiel auchProjektverwaltung oder die Entwicklung von Methoden und Werkzeugenzur Unterstützung bei der Durchführung von Softwareprojekten. Weiterhindeckt Software Engineering alle Phasen des Zustandes einer Software ab,beginnend mit der Erstellung der Anforderungen bis hin zur Wartung desfertigen Produktes. Die verschiedenen Konzepte des Software Engineeringsbefinden sich in einer stetigen Weiterentwicklung, und die Einführung mo-derner Paradigmen, wie etwa das der Objektorientierung, ermöglichen einintuitives Vorgehen und stellen den Menschen und seine Wahrnehmungin den Mittelpunkt der Betrachtung. Die Verfahren der objektorientiertenAnalyse und des objektorientierten Designs erlauben in Verbindung mitder Unified Modeling Language (UML) heutzutage nahtlose Übergänge zwi-schen den verschiedenen Sichten und Phasen der Modelle. Zudem erleich-

5

2 Grundlagen

tert die objektorientierte Entwicklung die Wiederverwendung von bereitserstellten Komponenten.

Die Methoden des Software Engineerings beinhalten Modellbildungen, No-tationen und Regeln, Anleitungen und Vorschläge. Sie ermöglichen demSoftwareentwickler ein systematisches und strukturiertes Vorgehen bei derErstellung und Betreuung einer Software. Allerdings gibt es keine allge-meingültige, ideale Kombination dieser Methoden, sondern der Entwicklermuss für das jeweilige Projekt die passenden Methoden und Hilfsmittelwählen. Dies kann je nach Projektumfeld zu sehr unterschiedlichen Zusam-menstellungen von Methoden führen.

Im Folgenden wird näher auf die im Rahmen dieser Arbeit verwende-ten Vorgehensmodelle und Methoden zur Qualitätssicherung eingegan-gen.

2.1.1 Vorgehensmodelle

Ein Vorgehensmodell betrachtet ein Projekt aus einem bestimmten Blick-winkel und unterteilt es in verschiedene Abschnitte. Dies hat zur Folge,dass mit einem Vorgehensmodell nie alle Details eines Projektes erfasstwerden können. Die Verwendung eines solchen Modells bietet dem Nut-zer jedoch den Vorteil, die komplexen Zusammenhänge eines großen Pro-jektes zu strukturieren und somit beherrschbar zu gestalten. Im Folgen-den werden die für dieses Projekt wichtigen Prozessmodelle kurz erläu-tert.

Wasserfall-ModellDas Wasserfall-Modell ist ein sehr bekanntes Vorgehensmodell und wird al-ternativ auch als Softwarelebenszyklus bezeichnet [ROY70]. Alle wichtigenAktivitäten bei der Softwareentwicklung sind hierbei in einer festen Rei-henfolge und ohne Wiederholungen kaskadiert: Analyse und Spezifikation,Entwurf, Implementierung, Test, Betrieb und Wartung. Das Hauptproblemdieses Modells ist die starre Aufteilung in die verschiedenen Phasen. Dies

6


hat zur Folge, dass sehr früh die genauen Spezifikationen fest stehen müs-sen und die Anpassung von Anforderungen zu einem späteren Zeitpunktnur schwierig durchzuführen ist.

Evolutionäre-EntwicklungBei diesem Vorgehensmodell wird aufgrund von groben Vorgaben ein Proto-typ der Software erstellt. Dieser wird dem Kunden zur Verfügung gestelltund von ihm kritisiert. Auf Basis dieser Kritik werden die Anforderungenverfeinert und ein weiterer Prototyp erstellt. Das Modell lässt sich in zweiKategorien unterteilen (siehe Bild 2.1):

Bild 2.1: Arten von Prototyping nach [SOM01]

1. Evolutionäre Prototypen: Hierbei werden die erstellten Prototypen auf-grund der genaueren Anforderungen bei jedem Schritt verbessert. End-ergebnis dieses Prozesses ist das fertige System.

2. Explorative-Prototypen: Die Explorativen-Prototypen dienen dazu dieAnforderungen des Kunden zu spezifizieren und werden nach der Be-nutzung nicht weiter verwendet. Diese Prototypen werden auch alsWegwerf-Prototypen bezeichnet.

Wenn man die erstellten Prototypen als Produkte betrachtet, kann mandiese auch anhand der Art des Produktes charakterisieren [KLO07]:

• Fachliche Prototypen: Hierbei werden Teile der fachlichen Anforde-rung realisiert und einer Überprüfung unterzogen.

7

2 Grundlagen

• Labormuster: Mit Labormustern können Architekturen und Techni-ken auf Programmierebene validiert werden.

• Demonstrationsprototyp: Diese Art von Prototyp dient dem Test vonnicht funktionaler Logik und des Look & Feels einer Anwendung.

• Pilotsystem: Hierbei wird ein Basissystem realisiert und inkrementellzum fertigen Produkt ausgebaut.

Entwicklung unter WiederverwendungBei diesem Modell wird davon ausgegangen, dass bereits eine große An-zahl von fertigen Komponenten zur Verfügung steht. So ist der Hauptein-satzzweck dieses Modells die Suche und der Einsatz von passenden Kompo-nenten für das zu entwickelnde System. Hierbei werden die Anforderungenteilweise an die Eigenschaften vorhandener Komponenten angepasst. Die-ser Prozess ermöglicht nicht immer die vollständige Abdeckung der Kun-denwünsche, bietet jedoch eine Verringerung der Kosten und Risiken durchdie Verwendung bereits fertiger Komponenten.

Die hier aufgeführten Vorgehensmodelle besitzen je nach Projekt und Auf-gabe Vor- und Nachteile. Allen drei Modellen gemeinsam ist das Feh-len einer übergreifenden Wiederholung der Prozessschritte. Als Konse-quenz daraus wurden zwei Ansätze entwickelt, die speziell Wiederholun-gen berücksichtigen und verschiedene der Entwicklungsmodelle unterstüt-zen:

Inkrementelle EntwicklungBei der inkrementellen Entwicklung wird versucht die Vorteile der evolutio-nären Entwicklung und die des Wasserfall-Modells zu verbinden. Hierbeierfolgt zu Beginn lediglich eine grobe Spezifikation und danach eine Auf-gliederung des Problems in Teilsysteme. Diese werden dann nach Prioritätgeordnet umgesetzt. Die Realisierung der Teilsysteme kann dabei je nachReifegrad der Spezifikationen evolutionär oder dem Wasserfall-Modell ent-sprechend erfolgen. Ein fertig gestelltes Teilsystem wird dem Kunden zurVerfügung gestellt, und die daraus resultierenden Erfahrungen können fürweitere Teilsysteme und die Verbesserung der Spezifikationen genutzt wer-den.

8


Bild 2.2: Inkrementelle Softwareentwicklung, angelehnt an [SOM01]

Dieses Vorgehen wird in Bild 2.2 veranschaulicht. Eine Weiterentwicklungdieses Ansatzes ist die „Extremprogrammierung“ [BEC00].

Spiralförmige EntwicklungDas Spiralmodell wurde 1988 von Boehm vorgeschlagen und ist ein sehrverbreitetes Vorgehensmodell [BOE88]. Hierbei wird die Entwicklung invier Segmente unterteilt:

1. Zieldefinition

2. Risikoabschätzung

3. Entwicklung und Validierung

4. Planung

Die einzelnen Phasen des Softwareprozesses repräsentieren jeweils eineWindung der Spirale und bauen aufeinander auf. Eine Phase besteht je-weils aus den oben aufgeführten vier Segmenten. Weiterhin kann für je-de Phase ein passendes Entwicklungsmodell gewählt werden. Als einzigesVorgehensmodell beinhaltet das Spiralmodell eine Risikoabschätzung. Dieskann sich insbesondere in Verbindung mit einem entsprechenden Projekt-management als Vorteil erweisen.

Allgemein sei noch angemerkt, dass bei den Ansätzen der evolutionärenEntwicklung die Systemspezifikationen erst mit dem Fortschreiten des Pro-jektes verfeinert und vervollständigt werden. Dies verhindert die Verwen-dung dieser Modelle bei Verträgen, die die Systemspezifikationen bereitszu Beginn vollständig enthalten müssen [SOM01].

9

2 Grundlagen

Es existieren noch weitere Vorgehensmodelle und im Folgenden werdenzwei davon kurz betrachtet und ein Zusammenhang zu den bisher disku-tierten Modellen hergestellt [MUE99] [BUH04]:

V-Modell 97Das V-Modell wurde im Auftrag der Bundeswehr der BundesrepublikDeutschland entwickelt, und später wurden auch alle Behörden zur Ver-wendung dieses Modells verpflichtet. Das V-Modell ist eine komplexe Wei-terentwicklung des Wasserfall-Modells und besteht aus vier verschiedenenSubmodellen: System-/Softwareerstellung (SE), Projektmanagement (PM),Qualitätssicherung (QS) und Konfigurationsmanagement (KM). Die Sub-modelle sind stark miteinander verwoben, und deren Prozesse können fürjedes Projekt individuell angepasst werden. Dieses Modell spezifiziert zu-dem Entwicklungs- und Methodenstandards sowie Anforderungen an dieverwendeten Werkzeuge.

Rational Unified Process (RUP)Dieses Vorgehensmodell wurde von der Firma Rational entwickelt und istdurch zwei zueinander orthogonale Einteilungen strukturiert. Die stati-sche Einteilung wird dabei als „Methodenachse“ bezeichnet und setzt sichaus verschiedenen Prozessbereichen zusammen. Es existieren vier Haupt-prozessbereiche: Erfassung der Anforderungen, Analyse & Design, Imple-mentierung und Test. Weiterhin gibt es drei unterstützende Bereiche: Ma-nagement, Verteilung und Umgebung. Die zweite Einteilung nimmt einezeitliche Aufteilung des Projektes vor. Hierbei werden vier Phasen unter-schieden: Zieldefinition, Entwurfsphase, Realisierung und Übergangspha-se. Jede Phase wird dabei in mehrere Iterationen aufgeteilt, und in jederPhase werden Methoden aus unterschiedlichen Prozessbereichen angewen-det, ähnlich einem vereinfachten Wasserfall-Modell. Dieses Vorgehensmo-dell kann an die Anforderungen des jeweiligen Projektes angepasst werden.In Bild 2.3 ist dieses Vorgehensmodell schematisch dargestellt.

Beide Vorgehensmodelle unterstützen objektorientierte Softwareentwick-lung und iteratives Vorgehen. Zudem ist in beiden Modellen die Nutzungvon UML-Techniken vorgesehen beziehungsweise bei RUP ein integralerBestandteil.

10


Bild 2.3: Rational Unified Process (RUP)

Weiterhin definieren beide Modelle im Zuge des Projektmanagements Vor-gehen zur Risikoabschätzung und Risikominimierung. Qualitätssicherungund Änderungsmanagement werden beim V-Modell 97 als eigenes Submo-dell in den Prozess integriert. Wiederverwendung erlaubt dieses Vorge-hensmodell durch die Integration von Fertigprodukten. Beim RUP werdenformale Regeln und Workflows definiert, die die Qualität und die Konsis-tenz der Prozessergebnisse sicherstellen sollen. Die Verwendung von kom-ponentenbasierten Architekturen ermöglicht Wiederverwendung bei Nut-zung des Rational Unified Process.

2.1.2 Qualitätssicherung

„Unter Softwarequalität versteht man die Gesamtheit der Merk-male und Merkmalswerte eines Softwareproduktes, die sich aufdessen Eignung beziehen, festgelegte oder vorausgesetzte Erfor-dernisse zu erfüllen.“ [BAL98]

Dieses Zitat bezieht sich auf die Produktqualität, die Prozessqualität ist je-doch ebenso wichtig. Denn es ist davon auszugehen, dass mittels qualitativhochwertiger Prozesse auch hochwertige Produkte erstellt werden können.

11

2 Grundlagen

Sowohl auf die Produktqualität, als auch auf die Prozessqualität soll imFolgenden näher eingegangen werden.

Zunächst aber werden Merkmale, die gute Software auszeichnen, de-finiert. Neben der offensichtlichen Funktionalität spielen das Laufzeit-verhalten, die Struktur der Quellen und die Dokumentation eine eben-so große Rolle für die Qualität. Welche Kriterien im Einzelnen an dieSoftware angelegt werden, hängt zudem noch von dem gewünschtenEinsatzgebiet der Software ab. Die wichtigsten Qualitätsmerkmale sind[ISO9126]:

• FunktionalitätDas Merkmal „Funktionalität“ spiegelt wieder, ob und in welcher Qua-lität eine Software den geforderten Funktionsumfang erfüllt.

• ÄnderbarkeitEs ist mit hoher Wahrscheinlichkeit davon auszugehen, dass Softwarewährend ihres Lebenszyklus an geänderte Anforderungen angepasstoder erweitert werden muss. Deshalb sollte gute Software von Beginnan so realisiert werden, dass Modifikationen ohne großen Aufwanddurchgeführt werden können.

• ZuverlässigkeitDie Software sollte keine Daten verfälschen oder durch Fehlfunktio-nen Schäden verursachen.

• EffizienzDie Software sollte möglichst effizient arbeiten, also keine Systemres-sourcen verschwenden.

• BenutzbarkeitDieses Merkmal trifft hauptsächlich auf die Benutzerschnittstelle zu.So sollte eine Software sich an bestimmte Standards der Benutzerfüh-rung halten und eine ausreichende Hilfestellung für Benutzer bieten.

• ÜbertragbarkeitDieses Merkmal gibt wieder, ob die Software auch in anderen Syste-mumgebungen (Hard- und Software) verwendet werden kann.

12


Diese Merkmale können nochmals je nach ihrer Bedeutung für die Softwareund ihren Einsatzzweck gewichtet werden.

Um die Einhaltung dieser Merkmale sicherzustellen, gibt es verschiedeneMethoden. Diese können wiederum kombiniert werden. Wie bereits im vor-herigen Kapitel erwähnt, ist die iterative Softwareentwicklung eine dieserMethoden.

Testgetriebene-EntwicklungZiel dieser Methode ist es bereits vor der Erstellung des eigentlichen Pro-grammcodes Tests zu definieren. Diese werden genutzt, um bei der Entwick-lung des Programms regelmäßig und teilweise automatisiert die Funktiondes Programms zu überprüfen. Eine konkrete Umsetzung dieser Techniksind zum Beispiel Modultests. Diese werden auch als Unit-Tests bezeich-net.

ReviewsEin Review ist ein Treffen einer Gruppe von Entwicklern. Diese analysie-ren gemeinsam zum Beispiel Teile des Quellcodes eines Programms oderdie Architektur eines Systems. Durch dieses Vorgehen können Fehler ent-deckt werden, und ein einheitlicher Stil bei der Entwicklung wird gefördert.Ein zusätzlicher Nutzen ist die dabei stattfindende Verteilung von Wissenauf alle Teilnehmer. Als Ergebnis eines solchen Treffens entsteht, per Handoder mit Werkzeugunterstützung, ein Dokument, in dem die Kritikpunktezusammengefasst sind [PRE87].

StandardsDie Anwendung von Standards kann in vielen Bereichen des Software En-gineerings helfen konkrete Qualitätskriterien umzusetzen. Die Standardslassen sich wiederum in zwei Gruppen aufteilen: Produkt- und Prozessstan-dards. Produktstandards betreffen zum Beispiel den Stil der Codierungund Dokumentation oder eine einheitliche Gestaltung von Schnittstellen.Prozessstandards garantieren einen einheitlichen Ablauf von Tätigkeiten,wie etwa dem Erstellen einer Software-Version. Standards stellen geeig-nete Praktiken und Richtlinien zur Verfügung, die eine Stetigkeit im Le-benszyklus der Software schaffen. Dadurch fällt es anderen Entwicklernleichter, sich in Projekte wieder oder neu einzuarbeiten [SOM01].

13

2 Grundlagen

2.2 Open Source

„Ich denke, dass jede allgemein nützliche Information frei seinsollte. Mit „frei“ beziehe ich mich nicht auf den Preis, sondern aufdie Freiheit, Informationen zu kopieren und für die eigenen Zwe-cke anpassen zu können. Wenn Informationen allgemein nützlichsind, wird die Menschheit durch ihre Verbreitung reicher, ganzegal, wer sie weitergibt und wer sie erhält.“

[GRA04, Richard Stallman, ca. 1990]

Die Begriffe „Open Source“ und „freie Software“ sind eng miteinander ver-wandt, und oft sind die genauen Definitionen und Unterschiede den meis-ten Anwendern und Entwicklern nicht bekannt. Deswegen soll an dieserStelle eine genaue Definition der beiden Begriffe vorgenommen werden. Indiesem Zusammenhang sind zwei Organisationen von besonderer Bedeu-tung. Zum einen ist dies die „Free Software Foundation“ (FSF, [FSF08]),eine Stiftung zur Förderung der freien Software. Zum anderen existiert die„Open Source Initiative“ (OSI, [OSI08]), eine Organisation zur Förderungvon Open Source Software. Einen umfassenden Überblick zu diesem The-ma gewährt Volker Grassmuck in seinem Buch „Freie Software – ZwischenPrivat- und Gemeineigentum“ ([GRA04]).

2.2.1 Definition

In diesem Kapitel werden insgesamt drei Definitionen gegeben. Zum einendie Definition des Begriffs „freie Software“, die des Begriffs „Open Sour-ce“ und die Definition des Begriffs „Copyleft“. Zum anderen soll der Un-terschied zwischen freier Software und Open Source verdeutlicht wer-den.

„Freie Software“ wurde von Richard Stallmann im Zuge des GNU-Projektesfolgendermaßen definiert:

14

2.2 Open Source

• Freiheit 0: Das Programm darf zu jedem Zweck ausgeführtwerden.

• Freiheit 1: Das Programm darf studiert und verändert wer-den.

• Freiheit 2: Das Programm darf verbreitet werden.• Freiheit 3: Das Programm darf verbessert und verbreitet wer-

den, um damit einen Nutzen für die Gemeinschaft zu erzeu-gen.

[GFS08, Definition freier Software nach GNU]

Die Definition von „Open Source“ nach der Open Source Initiative fällt et-was umfangreicher aus. Lizenzen, die die Definition erfüllen, dürfen dengeschützten Titel „Open Source™“ tragen. Im Folgenden sind die zehn Kri-terien frei übersetzt wiedergegeben:

1. Die Software darf beliebig kopiert, verbreitet und genutztwerden.

2. Die Software liegt in einer für den Menschen lesbaren undverständlichen Form vor.

3. Die Software darf verändert werden und in der verändertenForm weitergegeben werden, auch unter den gleichen Lizenz-bestimmungen wie das Basisprodukt.

4. Die Lizenz darf die Weitergabe von verändertem Quellcodenur einschränken, wenn „Patch-Dateien“ erlaubt sind. [. . . ]

5. Es dürfen keine Personen oder Gruppen diskriminiert wer-den.

6. Das Anwendungsgebiet darf nicht eingeschränkt werden.7. Die Lizenz muss in sich abgeschlossen sein.8. Die Lizenz muss produktneutral sein.9. Die Lizenz ist nur auf den Geltungsbereich der lizenzierten

Software anwendbar.10. Die Lizenz muss technologieneutral sein.

[OSD08, Definition freier Software nach OSI (OSD), verkürzt]

15

2 Grundlagen

Die Definition des Begriffs „Open Source“ basiert auf der Definition von„freier Software“. Jedoch ist der Begriff der Freiheit in der ursprüngli-chen Definition von „freier Software“ wesentlich schärfer formuliert. Daaußerdem frei oftmals mit kostenlos verwechselt wurde, ist der Begriffauch zwecks besserer Vermarktung eingeführt worden. Das sollte helfendiese Art von Software auch bei kommerziellen Entwicklern zu etablie-ren.

Die Definition des Begriffs „Copyleft“ ist für das Verständnis der weiterunten aufgeführten Lizenzen wichtig. Deshalb folgen nun einige Erläute-rungen hierzu. Der Begriff „Copyleft“ entstammt dem Umfeld des Urhe-berrechts. Im Gegensatz zum „Copyright“, das kopieren, verändern undweiterverbreiten von geschütztem Material ausdrücklich verbietet, erlaubtdas Copyleft dieses explizit. Weiterhin fordert das Copyleft bei Modifizie-rung von ursprünglich mit Copyleft versehenem Material von dem verän-derten Werk die gleichen Rechte ein wie von dem Ursprungswerk. Damitsoll verhindert werden, dass ursprünglich freie Werke als Basis für un-freie Werke genutzt werden können. Um diese Forderung durchzusetzen,nutzt das Copyleft interessanterweise das Copyright. Ausführlichere undweitergehende Informationen zum Copyleft können [GCP08] entnommenwerden.

2.2.2 Lizenzmodelle

Im Folgenden werden die wichtigsten Open Source Lizenzmodelle (weite-re unter [OSL08]) aufgeführt und kurz erläutert. Diese kurze Übersichterhebt allerdings keinen Anspruch auf Vollständigkeit.

• GPL – GNU General Public LicenseDie GNU General Public License ist wohl die bekannteste Open Sour-ce Lizenz und wurde von der Free Software Foundation [FSF08] for-muliert. Das Werk des Autors wird durch diese Lizenz geschützt, unddarauf aufbauende Werke müssen ebenfalls zwingend unter GPL ver-öffentlicht werden. Weiterhin muss der Quellcode einer unter GPL ste-henden Applikation veröffentlicht werden. Diese Bedingungen führen

16

2.2 Open Source

Lizenz GPL LGPL BSD ApacheMischung mit kommerziellem Code Nein Ja Ja Jabei Mischung muss Quellcode beiliegen Ja Ja Nein NeinCopyleft Ja Ja Nein NeinGPL-kompatibel (v3) Ja Ja Nein JaOSI-kompatibel Ja Ja Ja Ja

Tabelle 2.1: Open Source Lizenzen, Vgl. [NUE00] und [GWO06]

dazu, dass diese Art der Lizenz bei kommerziellen Softwareentwick-lern unbeliebt ist. Weitere Informationen können [GPL3] entnommenwerden.

• LGPL – GNU Lesser General Public LicenseDie GNU Lesser General Public License ermöglicht durch einen Pas-sus auch kommerziellen Entwicklern die Verwendung dieser Lizenz.Anders als bei der GPL ist es bei der LGPL erlaubt, eine Bibliothek,die unter LGPL steht, für ein kommerzielles Produkt zu nutzen. Derhierbei entstandene Quellcode muss nicht veröffentlicht werden undnicht unter LGPL stehen. Siehe auch [LGPL3].

• BSD – Berkley Software DistributionDie BSD-Lizenz ist ebenfalls für kommerzielle Nutzer geeignet undüberzeugt durch Kürze und Einfachheit. Sie erlaubt die Verwendung,Weitergabe und Modifikation des Produktes. Lediglich die Lizenzselbst, Vermerke im Quellcode und entsprechende Dokumentationmüssen vollständig vorhanden sein. Die BSD-Lizenz bildet unter an-derem die Basis für die Apache Lizenz. Weitere Informationen unter[BSD08].

• Apache – Apache License, Version 2.0Die Apache Lizenz ist ebenfalls eine einfache und kurze Lizenz. DieVerwendung, Verteilung und Modifikation von Software unter ApacheLizenz ist frei. Der Quellcode eines Produktes muss nicht im Paketenthalten sein und Produkte, die auf Bibliotheken unter Apache Li-zenz basieren, müssen nicht zwingend ebenfalls unter Apache Lizenz

17

2 Grundlagen

veröffentlicht werden. Der genaue Wortlaut ist unter [APA07] einseh-bar. Weitere Informationen zu den Unterschieden zwischen der Apa-che Lizenz und der GPL sind in [ASF08] verfügbar.

Alle Lizenzen besitzen einen Abschnitt, der einen Haftungssauschluss ent-hält. Einen kurzen Überblick gibt Tabelle 2.1.

2.2.3 SourceForge.net

Das Webportal „SourceForge.net“ (engl. Quellcodeschmiede), im Weite-ren als SF bezeichnet, ist ein Anwendungsdienstleister für Open-Source-Projekte. Bei der Realisierung von Open-Source-Projekten werden dieSoftware-Entwickler durch eine reichhaltige Auswahl an Diensten unter-stützt. Die Nutzung dieser Dienste ist kostenlos [SFN08]. Betrieben wirddas Portal von der Firma SourceForge. Im Folgenden werden die wichtigs-ten der Dienste aufgeführt:

• Softwarekonfigurationsmanagement (SCM): CVS oder Subversion

• Tasks: Verwaltung und Planung von Aufgaben

• Wiki: Information und Dokumentation

• Forum: Diskussion und Dokumentation

• Mailinglisten: Information und Diskussion

• Bug-Tracker: Erfassung von Fehlern und Änderungswünschen

• Webspace: Speicherplatz für die Homepage des Projektes

Die von SF zur Verfügung gestellte Infrastruktur ermöglicht den Entwick-lern sich auf ihre eigentliche Tätigkeit, die Realisierung von Software, zukonzentrieren. Weiterhin ist SF eine Kommunikationsplattform für Ent-wickler, aber auch Anwender können und sollen in Projekte integriert wer-den. Dadurch soll die Qualität und Verfügbarkeit einer Software über einenlangen Zeitraum verbessert werden.

18

2.3 Architektur- und Entwurfsmuster


„Jedes Muster beschreibt ein in unserer Umwelt beständig wieder-kehrendes Problem und erläutert den Kern der Lösung für diesesProblem, so dass Sie diese Lösung beliebig oft anwenden können,ohne sie jemals ein zweites Mal gleich auszuführen“

Christopher Alexander in [ALE77]

Architektur- und Entwurfsmuster (engl. design patterns) sind bewährte Lö-sungsvorschläge und Schemata für bestimmte Architektur- und Entwurfs-probleme. Die Bezeichnung „Entwurfsmuster“ stammt ursprünglich ausdem Bereich der Architektur. Diesem Bereich ist auch obiges Zitat entnom-men. Der Begriff wurde dann in Anlehnung an die ursprüngliche Verwen-dung in der Softwareentwicklung eingeführt [QUI99]. Ein Muster bietetdem Entwickler die Möglichkeit, mit einem erprobten Konzept jeweils ei-ne bestimmte Klasse von Problemen in der Entwicklung zu lösen. Weiter-hin können durch die Verwendung von Mustern abstraktere Strukturensichtbar werden, und innerhalb einer Entwicklergruppe wird eine gemein-same Begriffsbasis geschaffen. Diese Basis ist als Grundlage für Diskussio-nen unter Entwicklern und die Einarbeitung neuer Entwickler von Vorteil.Im Allgemeinen sind Muster zudem unabhängig von der verwendeten Pro-grammiersprache [BRD04].

Muster können, wie die Überschrift auch schon andeutet, nochmals in ver-schiedene Kategorien eingeteilt werde. So gibt es nicht mehr nur die „klassi-schen“ Entwurfsmuster, sondern etwa auch Muster für die Analyse, Archi-tektur, Kommunikation und weitere. Die Klassifizierung hängt dabei vonder Granularität und Abstraktionsebene des jeweiligen Musters ab. Archi-tekturmuster beinhalten zum Beispiel komplette Software-Architekturenin ihren Lösungsvorschlägen.

Eine ganz eigene Gruppe von Mustern stellen die Antimuster (engl. antipatterns) dar. Diese Muster haben das Gegenteilige zum Inhalt, denn siedokumentieren fehlerhafte Lösungen. Sie können als Beispiele betrachtetwerden, wie man ein Problem nicht lösen sollte. Antimuster sollen daher als

19

2 Grundlagen

Negativbeispiel ebenso zur Verbesserung von Softwarequalität beitragenwie die eigentlichen Muster [FRE04].

Im Folgenden wird auf vier Muster näher eingegangen, die jeweils in demStandardwerk für Entwurfsmuster „Design Patterns - Elements of Reusa-ble Object-Oriented Software“ der „Gang of Four“ (GOF) – auch als „Vierer-bande“ bezeichnet – beschrieben sind [GAM96]. Diese wurden im Rahmender Arbeit verwendet und sollen kurz diskutiert werden.

2.3.1 Einzelstück-Muster

Das Einzelstück-Muster (engl. singleton pattern) ist ein GOF Entwurfs-muster, genauer ein Erzeugermuster, und wird zum Beispiel bei derRealisierung von Protokollklassen (Logger) verwendet. Das Singleton-Entwurfsmuster stellt sicher, dass von einer Klasse genau nur eine Instanzerzeugt werden kann. Dies wird durch eine dedizierte Methode zum Zugriffauf diese Klasse erzwungen.

Bild 2.4: Das Einzelstück-Muster

In Bild 2.4 ist die UML-Notation einer solchen Klasse dargestellt. Wie mandem Bild entnehmen kann, besitzt diese Klasse keinen öffentlichen Kon-struktor, sondern die Klasse ist selbst für die Instanziierung verantwort-lich. Sowohl die Instanz als auch die Zugriffsmethode auf diese Instanzsind statisch und damit auch global zugänglich.

20


2.3.2 Beobachter-Muster

Das Beobachter-Muster (engl. observer pattern) ist ebenfalls ein GOF-Entwurfsmuster, in diesem Fall ein Verhaltensmuster. Dieses Muster wirdauch als „Veröffentlicher/Abonnenten“-Muster bezeichnet (engl. publisher/-subscriber pattern) und dient der Weitergabe einer Änderung des Zustan-des von einem Objekt an viele Objekte. Zur Umsetzung dieser Aufgabe wirdder Ansatz der losen Kopplung verwendet. Dieses Konzept sorgt für einemöglichst geringe Abhängigkeit der Komponenten voneinander. Dadurchlassen sich diese Objekte leichter trennen und flexibler kombinieren. Inder Praxis wird dies durch die Nutzung von Schnittstellen (engl. interface)realisiert.

Bild 2.5: Das Beobachter-Entwurfsmuster

In Bild 2.5 ist die UML-Notation dieses Musters dargestellt. Das Subjekthat einen Zustand, der für andere Objekte von Interesse ist. Das Subjekt be-sitzt Methoden zum An-, Abmelden und Benachrichtigen von Beobachtern.Damit die Beobachter sich registrieren können, müssen sie die entsprechen-de Beobachter-Schnittstelle verwirklichen. Diese Schnittstelle beinhaltetnormalerweise nur die Methode „aktualisiere()“. Wenn sich der Zustanddes Subjekts geändert hat, wird diese Methode vom Subjekt bei allen ange-meldeten Beobachtern aufgerufen.

21

2 Grundlagen

2.3.3 Dekorierer-Muster

Ein weiteres Muster der „Gang of Four“ ist das Dekorierer-Muster. Es er-laubt das dynamische Hinzufügen von Zuständigkeiten zu einem Objektund gehört zur Kategorie der Strukturmuster (engl. structural pattern).Um die Funktionalität einer Klasse zu erweitern, kann auch Unterklas-senbildung verwendet werden, jedoch bietet das Dekorierer-Muster denVorteil, das zur Laufzeit gesteuert werden kann, wann und wie die Funk-tionalität erweitert wird. Dabei wird das Basisobjekt von einem anderenObjekt, dem Dekorierer, umschlossen. Methoden können durch den Deko-rierer entweder in ihrer Funktionalität verändert werden oder an das Ba-sisobjekt delegiert werden. Dekorierer können geschachtelt werden underlauben so die unbeschränkte Erweiterung der Funktionen eines Objek-tes.

Bild 2.6: Das Dekorierer-Muster

Die UML-Notation veranschaulicht das oben beschriebene Muster in Bild2.6. Hierbei fällt auf, dass sowohl die Komponenten als auch die Dekoriererdie gleiche Schnittstelle besitzen. Dadurch ist die Verwendung von Deko-rierern für den Nutzer transparent. Die Aufrufe von Methoden werden an

22


die Komponente weitergeleitet, zuvor und/oder danach können aber auchweitere Methoden des Dekorierers ausgeführt werden. Dekorierer könnensowohl die Funktionalität als auch den Zustand einer Komponente erwei-tern. Die Dekorierer speichern dabei den Bezug zur Komponente in einerInstanzvariablen.

2.3.4 Model-View-Controller-Muster

Das Model-View-Controller-Muster („Modell-Präsentation-Steuerung“) istein zusammengesetztes Muster. Es gehört auch nicht zu den Entwurfsmus-tern, sondern in die Gruppe der Architekturmuster. Es besteht aus dreiKomponenten, auch in Bild 2.7 dargestellt:

• Modell (Model)Das Modell speichert die zu verarbeitenden Daten und Zustände. Jenach Realisierung und Ausprägung kann das Modell auch die Logikund Kernfunktionalität bereitstellen. Das Modell ist unabhängig vonden zwei übrigen Teilen und alleine funktionsfähig.

• Präsentation (View)Die Präsentation stellt die Daten des Modells dar. Bei Änderungen derDaten benachrichtigt das Modell die Präsentation. Diese aktualisiertdaraufhin die Darstellung der Daten. Die Präsentation ist auf Modellund Steuerung angewiesen.

• Steuerung (Controller)Die Steuerung kontrolliert die Präsentation, nimmt die Benutzerak-tionen entgegen und verarbeitet diese. Allerdings ändert die Steue-rung selbst keine Daten, sondern entscheidet, welches Modell seineDaten aktualisieren muss. Weiterhin kann die Steuerung die in derPräsentation vorhandenen Manipulationsmöglichkeiten für die Datendes Modells einschränken.

Präsentation und Steuerung bilden normalerweise ein Paar. Ein Modellkann von mehreren solcher Paare genutzt werden. Wie oben bereits an-gemerkt, kombiniert dieses Architekturmuster mehrere Entwurfsmuster.

23

2 Grundlagen

Bild 2.7: Das Model-View-Controller-Muster

Wenn das Modell seine Daten aktualisiert oder seinen Zustand ändert, wer-den diese Änderungen mittels des Beobachter-Musters gemeldet. Die Prä-sentation, üblicherweise eine grafische Benutzeroberfläche, realisiert das– in dieser Arbeit nicht näher betrachtete – Kompositum-Muster. In Kurz-form ist dies zum Beispiel eine Zusammensetzung von mehreren grafischenElementen (Eingabefelder, Menüs, etc.) zu einem Formular. Ein ebenfallsnicht in dieser Ausarbeitung betrachtetes Muster nutzt die Steuerung inVerbindung mit der Präsentation. Das hier verwendete Entwurfsmusterwird als Strategie-Muster bezeichnet. Kurz gesagt stellt die Steuerung fürdie Präsentation eine Strategie für ihr Verhalten bereit. Wird eine andereSteuerung verwendet, resultiert dies in einem anderen Verhalten der Prä-sentation.

Ziel der Kombination all dieser Muster ist es, die drei Komponenten die-ses Architekturmusters so unabhängig wie möglich voneinander zu halten.Dies ermöglicht eine einfache Erweiterung und erleichterte Wiederverwen-dung der Applikation oder ihrer Module.

24

2.4 Netzwerkprotokolle


Ein Netzwerkprotokoll ist eine Vereinbarung von Regeln und Formaten,die es zwei durch ein Netzwerk verbundenen Kommunikationspartnernermöglicht, Daten auszutauschen. Da ein einzelnes Protokoll für alle derdazu erforderlichen Aufgaben viel zu komplex wäre, wurden die Aufgabenauf verschiedene Protokolle aufgeteilt. Diese Protokolle sind wiederum inSchichten angeordnet. Es existieren zwei wichtige Modelle für die Anord-nung und Aufteilung dieser Schichten, das OSI-Referenzmodell [ISO7498]und das DoD-Schichtenmodell [RFC1122]. Beiden Modellen gemeinsam ist,dass die jeweils höhere Schicht die Funktionen der darunter angeordnetenSchicht nutzt. Die dabei entstehende Struktur wird auch als Protokollsta-pel bezeichnet. In Bild 2.8 ist die Aufteilung der verschiedenen Protokolleauf die Schichten der zwei Modelle dargestellt.

Bild 2.8: OSI-Referenzmodell und DoD-Schichtenmodell

Ein Netzwerkprotokoll legt im Allgemeinen den Aufbau eines Datenpakets,der kleinsten übertragbaren Informationseinheit, fest. Ein solches Paketbesteht mindestens aus der Adresse des Absenders und der des Empfän-gers, dem Pakettyp und den eigentlichen Daten. Des Weiteren kann dasProtokoll noch bestimmte Abfolgen von Paketen festlegen, die zum Beispielzur Verbindungssteuerung genutzt werden.

In diesem Zusammenhang wird kurz auf ein wichtiges Konzept der Netz-werkprogrammierung eingegangen, das Client-Server-Modell. Das Client-Server-Modell ist das am häufigsten verwendete Konzept für die Erstel-

25

2 Grundlagen

lung von netzwerkfähigen Applikationen. Dabei bietet ein als Server be-zeichnetes Programm Dienste an, die von einem oder mehreren als Cli-ent bezeichneten Programmen genutzt werden. Ein Aufruf eines solchenDienstes durch einen Client wird als Anfrage (engl. Request) bezeich-net, die Antwort des Servers auf diesen Aufruf als Antwort (engl. Re-sponse). Die Server unterteilt man noch in zwei Kategorien (siehe auch[STE94]):

• Iterative ServerDiese Realisierung eines Servers nimmt eine Anfrage eines Clients an,verarbeitet diese und steht dann für erneute Anfragen zur Verfügung.Gleichzeitige Anfragen werden nacheinander verarbeitet.

• Nebenläufige ServerNebenläufige Server bearbeiten gleichzeitige Anfragen, indem sie fürjede Anfrage einen eigenen Prozess erzeugen. Dieser arbeitet die An-frage ab und beendet sich dann. (Je nach Implementierung und Be-triebssystem können statt Prozessen auch Threads verwendet wer-den.)

In den folgenden Kapiteln werden jetzt die für diese Arbeit entschei-denden Protokolle vorgestellt und ihre Beziehungen zueinander darge-stellt.

2.4.1 TCP/IP

Der Ursprung von TCP/IP liegt in den späten 1960ern. Damals wurdedurch ein von den Vereinigten Staaten Amerikas finanziertes Forschungs-projekt über paketvermittelte Netzwerke der Grundstein für das heutigeInternet gelegt. Deshalb wird TCP/IP im allgemeinen Sprachgebrauch auchhäufig als Bezeichnung für den Protokollstapel beim Datenaustausch zwi-schen verschiedenen Rechnern verwendet. Diese Verwendung entsprichtdem DoD-Schichtenmodell aus dem vorherigen Abschnitt. In diesem Kapi-tel sollen aber nur zwei Protokolle der mittleren Schichten dieses Modells

26


betrachtet werden, nämlich das Internet Protocol (IP) und das Transmis-sion Control Protocol (TCP). Diese beiden Protokolle spielen im weiterenVerlauf eine wichtige Rolle.

Internet Protocol – IPIP befindet sich auf der Vermittlungsschicht, sowohl im OSI-Referenzmodell als auch im DoD-Schichtenmodell. IP stellt als zentraleBasis für alle weiteren Protokolle einen vom Netzwerkzugang unabhän-gigen, unzuverlässigen, verbindungslosen Paketvermittlungsdienst bereit.Unzuverlässig bedeutet in diesem Zusammenhang, dass IP nicht garan-tiert, dass ein Paket auch seinen Empfänger erreicht. Verbindungslosbesagt, dass IP auch keine Informationen über den Status der Verbin-dung speichert oder die Reihenfolge der Pakete beibehält. Weiterhinstellt IP weltweit eindeutige, logische Adressen bereit, die es ermögli-chen Netzwerke zu strukturieren und Datenpakete gezielt zu vermitteln(Stichwort: Routing). Hier ein Beispiel für eine gültige IP-Adresse (IPv4):Adresse: 123.12.1.112 Die detaillierte Definition des Internet Proto-cols findet sich in [RFC791].

Transmission Control Protocol – TCPTCP ist eine Implementierung der Transportschicht. Auch in diesemFall besteht kein Unterschied in der Einordnung zwischen dem OSI-Referenzmodell und dem DoD-Schichtenmodell. Im Gegensatz zu IP bie-tet TCP einen zuverlässigen und verbindungsorientierten Dienst zurDatenübertragung an. TCP kann Fehler in der Übertragung erkennen,stellt die Einhaltung der Reihenfolge der Pakete sicher und bietet Fluss-kontrolle. Damit Daten mit TCP übertragen werden können, müssenzwei Kommunikationspartner eine Verbindung aufbauen. Nach Beendi-gung des Datenaustausches wird diese Verbindung geschlossen. Die ein-deutige Adressierung eines Kommunikationsendpunktes erfolgt bei TCPdurch die Kombination einer IP-Adresse mit einer Portnummer. Die TCP-Adresse eines Webservers könnte zum Beispiel folgendermaßen aussehen:Adresse: 123.12.1.112:80. Die Portnummer kann im Bereich von 0bis 65535 liegen. Der Bereich zwischen 0 und 1023 unterliegt Beschrän-kungen und wird von der Internet Assigned Numbers Authority (IANA)

27

2 Grundlagen

verwaltet [IAN08]. Weitere Einzelheiten zu TCP sind unter [RFC793] ver-fügbar.

Andere Netzwerkprotokolle dieser Schichten sollen aus Gründen derÜbersichtlichkeit nicht betrachtet werden (UDP, ICMP, etc.). Hier seiauf die einschlägige Fachliteratur verwiesen ([STE94], [COM95] und[TAN03]).

2.4.2 HTTP

Das Hypertext Transfer Protocol (HTTP) ist eines der wichtigsten undmeist benutzten Protokolle der Anwendungsschicht der Referenzmodelle.Webserver nutzen HTTP, um die auf ihnen angebotenen Inhalte an die Cli-ents, auch als Browser bezeichnet, auszuliefern. HTTP wurde 1989 von TimBerners-Lee in Verbindung mit einem Protokoll zum eindeutigen Zugriffauf Ressourcen (siehe URI/URL) und einer Textauszeichnungssprache (sie-he HTML) am CERN entworfen und bildet seitdem die Basis des WorldWide Web.

Das Hypertext Transfer Protocol kann benutzt werden, um die unterschied-lichsten Inhalte, wie etwa HTML-Dateien, Bilder oder Videos, auszutau-schen. Durch die Nutzung des Transmission Control Protocols ist eine siche-re, fehlerfreie und in der Reihenfolge der Daten unveränderte Übertragunggarantiert.

Eine HTTP-Transaktion besteht immer aus einer Client-Anfrage und einerServer-Antwort. Die Nachrichten, die dabei ausgetauscht werden, bezeich-net man als HTTP-Nachrichten. Dabei enthält eine Client-Nachricht im-mer eine HTTP-Methode. Diese Methode bestimmt die gewünschte Aktion,die der Server ausführen soll. Zum Beispiel weist die GET-Methode den Ser-ver an, eine bestimmte Datei an den Client auszuliefern. Eine Antwort desServers wiederum enthält immer einen Statuscode. Dieser Statuscode isteine dreistellige Zahl und zeigt dem Client an, ob seine Anfrage mit Erfolgausgeführt werden konnte oder ein Fehler aufgetreten ist. So bedeutet einStatuscode mit dem Wert „200“ zum Beispiel eine erfolgreiche Verarbeitungder Anfrage.

28


Die Funktionsweise des Protokolls soll an einem kleinen Beispiel verdeut-licht werden. Nachdem der Client die IP-Adresse des Servers ermittelt hat,baut der Client eine TCP-Verbindung zu dem Server auf und sendet die An-frage gemäß Listing 2.1. Der Server sendet daraufhin die Antwort, darge-stellt in Listing 2.2, an den Client zurück. Danach wird die Verbindung ge-schlossen. Es sei noch darauf hingewiesen, dass die Schritte zur Ermittlungder IP-Adresse zur Vereinfachung weggelassen wurden.

1 GET /path/file.html HTTP/1.1

2 Host: www.someserver.net:8080

3 User-Agent: SomeBrowser

Listing 2.1: HTTP-Client Anfrage, vgl. [RFC2616]

1 HTTP/1.1 200 OK

2 Date: Fri, 25 Jan 2008 23:59:59 GMT

3 Content-Type: text/html

4 Content-Length: 1354

5

6

7

8 [more file content ...]

9

10

Listing 2.2: HTTP-Server Antwort, vgl. [RFC2616]

In den beiden oben ersichtlichen Nachrichten und der Darstellung des all-gemeinen Aufbaus in Listing 2.3 lassen sich die elementaren Bestandteileeiner HTTP-Nachricht erkennen [GOT02]:

• StartzeileDie erste Zeile einer jeden HTTP-Nachricht enthält bei einer Anfra-ge die auszuführende Aktion und die zugehörige Ressource. Bei einerAntwort ist hier der Status der ausgeführten Aktion hinterlegt. In bei-den Fällen enthält die Zeile noch die verwendete Protokollversion. Inden Beispielen 2.1 und 2.2 entspricht dies jeweils der ersten Zeile.

• KopfzeilenNach der Startzeile können keine oder beliebig viele Kopfzeilen folgen.

29

2 Grundlagen

Eine Kopfzeile enthält ein Schlüsselwort gefolgt von einem Doppel-punkt und dem zugehörigen Wert (Listing 2.1 Zeilen 2 und 3, Listing2.2 Zeile 2 bis 4). Das Ende des Nachrichtenkopfes wird immer durcheine Leerzeile angezeigt (Listing 2.2 Zeile 5).

• RumpfNach dieser Leerzeile folgen die Daten des Rumpfes (Listing 2.2 Zei-len 6 bis 10). Es gibt aber auch HTTP-Nachrichten, die ohne Rumpfgültig sind (siehe Listing 2.1). Beim so genannten „chunked encoding“werden die Daten des Rumpfes in mehrere Blöcke aufgeteilt, die je-weils einzeln übertragen werden. Diese Blöcke sind dann durch eineLeerzeile voneinander getrennt, und die erste Zeile eines Blockes ent-hält jeweils dessen Länge in hexadezimalem Format.

1 Message = Request-Line | Status-Line

2 *(Message-Header CRLF)

3 CRLF

4 [ Message-Body ]

Listing 2.3: HTTP-Nachricht nach RFC 2616

Um HTTP in Verbindung mit anderen Protokollen oder Applikationen zunutzen, die kein HTTP unterstützen, oder auch flexiblere Netzstrukturenzu ermöglichen, wurden verschiedene Konzepte entwickelt (nach [GOT02]und [RFC2616]):

• ProxyEin Proxy besitzt mindestens zwei Netzwerkschnittstellen und be-nutzt für alle Schnittstellen das gleiche Protokoll. Der Proxy agiertan der Schnittstelle zum Client als Server und an der Schnittstellezum Server als Client. Ein Proxy kann als Zwischenspeicher, Zugriffs-steuerung und/oder Filter genutzt werden.

• GatewayEin Gateway (auch Protokollumsetzer) besitzt ebenfalls mindestenszwei Netzwerkschnittstellen. Jedoch ist ein Gateway in der Lage einProtokoll in ein anderes Protokoll zu „übersetzen“. Ein Gateway kann

30


zum Beispiel verwendet werden, um zwei unterschiedliche Netzwerkezu verbinden.

• TunnelTunnel ermöglichen es Applikationen, die HTTP nicht unterstützen,trotzdem über das Internet und vor allem durch Firewalls hindurch,zu kommunizieren. Dabei wird das jeweilige Applikationsprotokoll inHTTP „verpackt“. Der Tunnel beeinflusst die eigentliche Kommunika-tion nicht.

• RelaisEin Relais (Relay oder auch Repeater) ist eine sehr starke Verein-fachung eines Proxies. Allerdings „versteht“ ein Relais das jeweiligeNetzwerkprotokoll nicht. Dies kann, je nach Protokoll, zu Problemenführen. Den eigentlichen Datenverkehr verändert ein Relais nicht.

Zur Verdeutlichung sind diese vier Konzepte noch einmal grafisch in Bild2.9 dargestellt.

31

2 Grundlagen

Bild 2.9: Grafische Darstellung von Proxy, Gateway, Tunnel und Relais

32


2.4.3 WebDAV

Web-based Distributed Authoring and Versioning (WebDAV) ist eine Erwei-terung des Hypertext Transfer Protocols. Ein Webserver stellt, wie in Kapi-tel 2.4.2 bereits erläutert, Dateien zum Betrachten im Browser oder Herun-terladen bereit. HTTP bietet nur wenige Befehle zum Manipulieren von die-sen Inhalten an. Insbesondere existieren keine Befehle für die Ordnerver-waltung und es fehlt auch die Unterstützung für verteilte Zusammenarbeit.Die von HTTP in dieser Hinsicht angebotenen Befehle, wie etwa DELETEzum Löschen einer Datei, sind bei vielen Webservern zudem nicht imple-mentiert. So ist das World Wide Web hauptsächlich ein Nur-Lese-Mediumund zusätzliche Protokolle, zum Beispiel das File Transfer Protocol (FTP),müssen verwendet werden, um die Inhalte auf den Webservern zu verwal-ten [DUS04].

WebDAV schließt diese Lücke und bietet dem Benutzer umfangreiche Be-fehle zur Manipulation der Inhalte eines Webservers. Weiterhin erlaubtWebDAV verteiltes Editieren, verteiltes Dokumentenmanagement und Ver-sionskontrolle. Initiiert wurde die Entwicklung 1996 durch Bildung einerArbeitsgruppe aus Mitgliedern der Internet Engineering Task Force (IETF)und des World Wide Web Consortium (W3C) unter Führung von Jim White-head. Die Ergebnisse dieser Arbeitsgruppe wurden offiziell 1999 von derIETF bestätigt.

Insgesamt besteht WebDAV nicht aus einem einzelnen Standard, son-dern es wurden mehrere Standards mit jeweils unterschiedlichen Schwer-punkten geschaffen. Die Basis bildet dabei RFC 4918, die aktuelleVersion des Basis WebDAV-Protokolls. Im Folgenden sind die zu Web-DAV gehörenden Standards mit einer kurzen Beschreibung aufgeführt[WDA08]:

• RFC 3253 – Versioning Extensions [RFC3253]Die Versioning Extensions (DeltaV) beinhaltet die Definitionen fürdas Versionsmanagement von WebDAV.

33

2 Grundlagen

• RFC 3648 – Ordered Collections [RFC3648]Das WebDAV Ordered Collections Protocol beschreibt, wie Daten-sammlungen geordnet serverseitig abgelegt werden können.

• RFC 3744 – Access Control Protocol [RFC3744]Das Access Control Protocol (ACP) erlaubt es Clients, Zugriffsbe-schränkungen des Servers zu lesen und zu bearbeiten.

• RFC 4316 – Datatypes Properties – experimentell [RFC4316]Dieser Standard beschreibt eine Menge von Datentypen, die WebDAV-Clients und Server verwenden können.

• RFC 4331 – Quota [RFC4331]Die Definition von WebDAV Quotas dient der serverseitigen Umset-zung von Beschränkungen des zur Verfügung stehenden Speicherplat-zes.

• RFC 4437 – Redirect – experimentell [RFC4437]Der WebDAV-Redirect-Standard ermöglicht dem Client das Anlegenund Bearbeiten von Weiterleitungen.

• RFC 4709 – Mount – informativ [RFC4709]Diese Empfehlung soll Client- und Browser-Entwicklern helfen, eineinheitliches Verhalten im Umgang mit WebDAV-Ressourcen zu erzie-len.

• RFC 4791 – CalDAV [RFC4791]Die WebDAV Calendaring Extension (CalDAV) beschreibt einen aufdem iCalendar-Format basierenden Zugriff auf Ressourcen von Kalen-dern und Terminplanern.

• RFC 4918 – WebDAV [RFC4918]Dies ist die aktuelle Version der HTTP Extensions for Web DistributedAuthoring and Versioning (WebDAV). Dieser Standard dient als Basisfür alle vorherig aufgezählten Definitionen.

34


• DAV Searching and Locating – DASL [DAS08]DASL ist eine Erweiterung des WebDAV-Protokolls, die das Durchsu-chen und Auffinden von Ressourcen ermöglicht. Diese Erweiterunghat allerdings noch nicht den Reifegrad eines Standards erreicht.

Umgesetzt wird das WebDAV-Protokoll inzwischen von vielen Applikatio-nen, allerdings selten in allen Teilen. So unterstützen populäre kommerzi-elle Programme, wie etwa Microsoft Windows und Office oder Adobe Photo-shop, WebDAV. Weiterhin werden zahlreiche WebDAV-fähige Open SourceAnwendungen angeboten, beispielsweise der KDE Desktop, DAVExploreroder Subversion [WDP08].

Es folgt ein kleines Beispiel, an dem der Aufbau der WebDAV-Nachrichtenerläutert wird. Der allgemeine Aufbau gleicht dem von HTTP-Nachrichten.Hinzugekommen sind zusätzliche Methoden und Stati. Der wichtigste Un-terschied besteht allerdings im Aufbau des Nachrichtenrumpfes. Diesernutzt bei WebDAV-Nachrichten immer das XML-Format zur Übertragungder Daten [RFC4918]. In Listing 2.4 ist beispielhaft eine Client-Anfragedargestellt. Listing 2.5 zeigt die entsprechende Antwort des Servers. DerRumpfteil der Antwort wurde dabei aus Gründen der Übersichtlichkeit ge-kürzt. Bei der dargestellten Anfrage wird die Methode PROPFIND genutzt(Zeile 1 Listing 2.4). Diese liefert die Eigenschaften einer Datei oder einesVerzeichnisses zurück. Wie aus Zeile 4 Listing 2.5 ersichtlich, nutzt die Ant-wort auf diese Anfrage „chunked encoding“. Einen Block einer so kodiertenAntwort bilden die Zeilen 7 bis 29, auch als „chunk“ bezeichnet. Hierbeigibt Zeile 7 die Länge des Blockes in Byte an. Zeile 29 trennt diesen Blockvom nächsten Block.

1 PROPFIND /slide/files/ HTTP/1.1

2 Host: localhost:9999

3 Content-type: text/xml

4 Content-length: 345

5

6

7

8

9

10

35

2 Grundlagen

11

12

13

14

15

16

17

Listing 2.4: WebDAV-Client Anfrage

1 HTTP/1.1 207 Multi-Status

2 Server: Apache-Coyote/1.1

3 Content-Type: text/xml;charset=UTF-8

4 Transfer-Encoding: chunked

5 Date: Tue, 29 Apr 2008 11:45:14 GMT

6

7 61b

8

9

10

11 /slide/files

12

13

14 files

15

16

17

18

19

20

21

22 [...]

23

24

25

26 HTTP/1.1 200 OK

27

28

29

30 [...]

Listing 2.5: WebDAV-Server Antwort (gekürzt)

36

2.5 Multithreading

2.5 Multithreading

Moderne Betriebssysteme erlauben mehreren Benutzern und/oder Applika-tionen gleichzeitig die vorhandenen Ressourcen, wie etwa Speicher, Prozes-sor und Festplatte, zu nutzen. Die Fähigkeit aktueller Rechner mehrereAufgaben zu erledigen hat sich in den letzten Jahren durch die breite Ein-führung von Mehrkernprozessoren erheblich verbessert. Um dieses Poten-zial optimal nutzen zu können, müssen bei dem Entwurf von Applikationenbestimmte Regeln berücksichtigt werden.

Im Allgemeinen wird eine Applikation in einem Betriebssystemkontextausgeführt. Der Betriebssystemkontext besteht dabei aus Hauptspeicher,Rechenzeit und Zugriff auf andere Ressourcen. Diese werden jeweils vomBetriebssystem bereit gestellt und koordiniert. Eine solche Umgebung be-zeichnet man auch als Prozess oder Task und sie steht einer Anwendungexklusiv zur Verfügung. Die Abarbeitung der Anwendung innerhalb einersolchen Umgebung wird auch als Ausführungsstrang oder Thread bezeich-net. Innerhalb eines Prozesses können mehrere Threads vorhanden sein.Diese werden je nach vorhandenen Ressourcen und Aufgaben abgearbei-tet.

Um, wie oben bereits erwähnt, die Ressourcen optimal zu nutzen, istes sinnvoll, verschiedene Aufgaben innerhalb einer Applikation auf ver-schiedene Ausführungsstränge zu verteilen. Zur Verdeutlichung ein Bei-spiel:

Ein Programm mit grafischer Schnittstelle ermöglicht dem Be-nutzer Anfragen an entfernte Rechner über eine Netzwerk-schnittstelle zu senden. Gleichzeitig soll der Benutzer aber auchin der Lage sein, die bisher empfangenen Daten auszuwerten.

Eine Anwendung mit nur einem Ausführungsstrang würde beimWarten auf die Antwort eines anderen Rechners blockieren, dasheißt aus der Sicht des Benutzers nicht mehr reagieren.

Durch die Verwendung von eigenen Ausführungssträngen fürdie einzelnen Aufgaben, etwa der Verarbeitung der Benutzerin-

37

2 Grundlagen

teraktion und des Netzwerkverkehrs, wird eine Parallelisierungund Entkopplung der Aufgaben erreicht.

Bild 2.10: Threadzustände, vgl. [OEC01]

Anders als bei Prozessen steht der jeweilige Betriebssystemkontext allenAusführungssträngen gemeinsam zur Verfügung. Dies hat sowohl Vor- alsauch Nachteile. So ist die Erzeugung von Threads und der Wechsel zwi-schen Threads wesentlich günstiger als bei Prozessen, da das Betriebssys-tem bei einem Wechsel zwischen Threads keinen Kontextwechsel durchfüh-ren muss und bei der Erzeugung eines neuen Threads kein neuer Kontexterstellt werden muss [TAN02]. „Günstiger“ bedeutet in diesem Zusammen-hang schneller und weniger ressourcenintensiv. Andererseits muss der Pro-grammierer bei der Verwendung von mehreren Threads selbst dafür Sorgetragen, dass die verschiedenen Ausführungsstränge sich nicht gegenseitigblockieren oder gleichzeitig auf dieselbe Speicherstelle zugreifen. Auch derDatenaustausch zwischen verschiedenen Threads eines Prozesses muss ko-ordiniert werden. Dies bezeichnet man auch als Synchronisation. Es exis-

38

2.5 Multithreading

tieren verschiedene Modelle (Semaphore, Mutexe, etc.) zur Lösung dieserAufgabe (siehe [KRY02] und [OAW04]).

Zum besseren Verständnis des Ablaufs werden kurz die verschiedenenThreadzustände erläutert, siehe auch Bild 2.10:

• bereitNach der Erzeugung und Start des Threads befindet sich dieser im Zu-stand „bereit“ und wartet auf die Zuteilung von Rechenzeit. Bekommtdieser Thread Rechenzeit zugeteilt, wechselt er in den Zustand „rech-nend“.

• rechnendWird ein Thread abgearbeitet, ist er im Zustand „rechnend“. Wird derThread vom Betriebssystem angehalten, wechselt er wieder in denZustand „bereit“. Muss der Thread auf eine Ressource oder Ergebnisseeines anderen Threads warten, geht er in den Zustand „wartend“ über.Ist eine Berechnung abgeschlossen und sind keine weiteren Aufgabenzu bearbeiten, wechselt der Thread in den Zustand „beendet“.

• wartendIm Zustand „wartend“ ist der Thread blockiert. Die Blockierung wirderst gelöst, wenn die entsprechenden Daten oder Ressourcen verfüg-bar sind.

• beendetDer Zustand „beendet“ markiert das Lebensende eines Threads. Die-ser Zustand kann nicht mehr verlassen werden.

Falls in einem der Threadzustände ein Fehler auftreten sollte, wird derThread in den Zustand „beendet“ versetzt.

39

2 Grundlagen

2.6 Extensible Markup Language

Der globale Erfolg des Internets ist nur durch offene Standards wieTCP/IP, HTTP und HTML ermöglicht worden. Ebenfalls in dieser Reihesteht die „Extensible Markup Language“, kurz XML. Während die vor-herig aufgezählten Protokolle für eine maschinenunabhängige Übertra-gung und Präsentation von Informationen sorgen, war zunächst kein Stan-dard für die strukturierte Auszeichnung von Daten verfügbar. Diese Lückefüllt die von dem Word-Wide-Web-Konsortium (W3C) eingeführte Spra-che XML [XML08]. Da das W3C sich bereits für die anderen Standardsverantwortlich zeichnet, wurde auch dieser Standard durch das W3C eta-bliert.

Da die Extensible Markup Language keine Elemente für die Steuerung desKontrollflusses eines Programms enthält, kann sie nicht den Programmier-sprachen zugeordnet werden. Andererseits ist XML aber auch mehr alsnur eine Auszeichnungssprache wie etwa die Hypertext Markup Langua-ge (HTML). So können in XML eigene Elemente definiert werden, die dieeinfache Abbildung auch von komplexen Strukturen erleichtern. XML istalso erweiterbar. Weiterhin beschreiben diese Elemente nicht die Darstel-lung der enthaltenen Daten, sondern deren Bedeutung. So lässt sich durchdie Nutzung von XML auch eine Trennung von Struktur, Inhalt und Dar-stellung von Daten erzielen. Insgesamt lässt sich XML wohl am ehesten alsInhaltsbeschreibungssprache bezeichnen [VON07].

Die Extensible Markup Language wurde aus der Standard GeneralizedMarkup Language (SGML) abgeleitet und ermöglicht sowohl Menschenals auch Maschinen den Inhalt eines XML-Dokumentes zu lesen und zuverarbeiten. Die Form eines XML-Dokumentes muss deswegen streng de-finiert sein. Die Struktur der Daten in einem XML-Dokument entsprichteiner Baumstruktur. Als Knoten kommen Elemente und Attribute inFrage, und es existiert genau nur ein Wurzelelement. Wenn ein XML-Dokument diesen Definitionen entspricht, wird es als „wohlgeformt“ be-zeichnet. Des Weiteren wird eine genaue Vorgabe durch die Verwendungvon Strukturbeschreibungen erzielt. Die Strukturbeschreibungen sind wie-derum XML-Dokumente einer speziellen Form. Zurzeit gibt es hiervon zwei

40

2.6 Extensible Markup Language

Ausprägungen, die Document Type Definition (DTD) und XML-Schema.Die Gültigkeit eines XML-Dokumentes kann mit einer solchen Struk-turbeschreibung überprüft werden. Entspricht das Dokument der jewei-ligen Strukturbeschreibung und erfüllt es die übrigen Regeln der XML-Definition, so wird das Dokument als „valide“ bezeichnet ([VON07] und[GOL99]).

Zur Verdeutlichung soll ein Adressbuch mit den Daten in einer XML-Dateiund einer zugehörigen XML-Schema-Datei dienen. Der Inhalt der XML-Datei ist in Listing 2.6 abgebildet, die zugehörige Schema-Datei in Listing2.7.

1

2

5

6 Rolf

7 Herbert

8 Müller

9 Köln

10

11

12 Horst

13 Meier

14

15

Listing 2.6: Ein einfaches XML-Dokument

1

2

6

7

8

9

11

41

2 Grundlagen

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

Listing 2.7: Ein einfaches XML-Schema-Dokument

Der Aufbau des XML-Dokumentes ist dabei sehr einfach gehalten. Fürdas Wurzelelement wird das zugehörige Schema (Zeile 2-4) angegeben. Danach folgen keine oder beliebig viele Elemente des Typs. Dies wird durch die Zeilen 9 und 10 des Schemas festgelegt. DieUnterelemente von wiederum sind im Schema in Zeile 15 bis 23definiert, die Datentypen dieser Elemente in den Zeilen 25 bis 27. So kanndas Element minimal gar nicht und maximal dreimal vorhan-den sein (Zeile 18). Weiterhin ist das Element vom Datentyp„String“ (Zeile 25). Das XML-Dokument enthält zwei Personen. Die Personmit dem Nachnamen „Müller“ besitzt zwei Elemente des Typs und die Person „Meier“ lediglich eins. Auf diese Weise kann die Datenstruk-tur eines XML-Dokumentes überprüft werden.

42

2.7 Java

2.7 Java

Die Programmiersprache Java, ursprünglich unter dem Namen Oak (Ob-ject Application Kernel) entwickelt, wurde 1995 von Sun Microsystems ver-öffentlicht. Java ist aber mehr als eine Programmiersprache und wird vonSun Microsystems auch als Java-Technologie bezeichnet. Im Einzelnen be-steht die Java-Technologie aus der Programmiersprache Java und verschie-denen Laufzeitumgebungen.

Eine in der Sprache Java geschriebene Anwendung wird normalerweisevon einem Java-Compiler in Bytecode übersetzt. Dies ist ein binäres Zwi-schenformat, das unabhängig vom jeweiligen Betriebssystem ist und so-mit über Systemgrenzen hinaus genutzt werden kann. Der Bytecode wirddann auf dem Zielsystem durch die entsprechende Laufzeitumgebung, alsJava Runtime Environment (JRE) bezeichnet, ausgeführt. Die Laufzeitum-gebung besteht wiederum aus dem Interpreter, der Java Virtual Maschine(JVM), und den entsprechenden Bibliotheken.

Die Programmiersprache Java selber ist eine objektorientierte Sprache undunterstützt bereits in der Grundversion Multithreading, Netzwerkprogram-mierung, grafische Oberflächen und Ausnahmen. Weiterhin werden eineautomatische Speicherbereinigung (Garbage Collection) und Laufzeitumge-bungen für die unterschiedlichsten Plattformen angeboten. Zusätzlich ge-hören noch umfangreiche Klassenbibliotheken zum Lieferumfang der ver-schiedenen Ausgaben.

2.7.1 Vererbung und Polymorphie

Eines der elementaren Konzepte der Objektorientierung ist die Vererbung.Im Folgenden wird dieses Konzept in Bezug auf die ProgrammierspracheJava betrachtet. Die Essenz dieses Konzeptes ist es, gemeinsame Eigen-schaften von Objekten zu finden und diese in einer Klasse – Oberklasseoder Basisklasse – zusammen zu fassen. Eigenschaften, die nicht durchdiese Abstraktion abgedeckt werden, werden in einer davon abgeleiteten,

43

2 Grundlagen

spezialisierten Klasse – Unterklasse – realisiert. Die daraus resultierendeHierarchie wird auch als Klassenhierarchie bezeichnet.

Die Unterklasse erhält durch die Vererbung alle Attribute, Methoden undBeziehungen der Oberklasse. Die Eigenschaften der Oberklasse könnensomit auch ohne weiteren Aufwand von der Unterklasse genutzt werden.Neue Eigenschaften können in der Unterklasse problemlos hinzugefügtwerden und bei Bedarf können in der Unterklasse auch Eigenschaften derOberklasse neu definiert werden. Letzteres bezeichnet man auch als „über-schreiben“ [JOB02].

Bild 2.11: Ein Beispiel für Vererbung

Ein einfaches Beispiel ist in Bild 2.11 dargestellt. Die Klasse „Person“ be-sitzt das Attribut „Name“ und die Methode „essen()“. Da die Klassen „Stu-dent“ und „Professor“ von der Klasse „Person“ abgeleitet wurden, stehendiesen ebenfalls die Attribute und Methoden von „Person“ zur Verfügung.Zusätzlich realisieren die Unterklassen noch andere Attribute und Metho-den.

Wenn eine Unterklasse von mehr als einer Oberklasse erben soll, was inBild 2.12 dargestellt ist, bezeichnet man dies als Mehrfachvererbung. Indem dargestellten Beispiel erbt die Klasse „Hausboot“ sowohl von der Klas-se „Haus“ als auch von der Klasse „Boot“. Dies kann man in der Program-miersprache Java nur durch die Nutzung von Schnittstellen (interfaces)umsetzten. Dabei werden bei der Definition der Schnittstelle die Methoden

44

2.7 Java

Bild 2.12: Ein Beispiel für Mehrfachvererbung

festgelegt, die eine Implementierung der Schnittstelle realisieren muss. Al-lerdings können so keine Attribute und Methodenrümpfe vererbt werden,sondern diese müssen von jeder Schnittstellen-Implementierung selbst ver-wirklicht werden. Dieses Konzept wird auch als Schnittstellenvererbungbezeichnet. Das in Bild 2.12 dargestellte Beispiel ist in Listing 2.8 in derSprache Java umgesetzt1.

1 // Klasse Boot

2 public class Boot {

3 public Object tiefgang;

4 public void starteMotor() {

5 // tu etwas

6 }

7 }

8

9 // Schnittstelle Haus

10 public interface Haus {

11 void öffneTür();

12 }

13

14 // Klasse HausBoot

15 public class HausBoot extends Boot implements Haus {

1Anmerkung: Die Klassen- und Schnittstellendefinitionen müssen bei Java in separatenDateien abgelegt werden. Aus Platzgründen wurden diese hier in einem Listing zusam-men gefasst.

45

2 Grundlagen

16 public Object anzahlTüren;

17 public void öffneTür() {

18 // tu etwas anderes

19 }

20 }

Listing 2.8: Beispiel für Mehrfachvererbung in Java

Hierbei wurde der Typ „Boot“ als Klasse realisiert und der Typ „Haus“als Schnittstelle. So kann die Klasse HausBoot nun sowohl von der Klas-se Boot erben als auch die Methoden der Schnittstelle Haus realisie-ren.

Bild 2.13: Ein Beispiel für Inklusionspolymorphie

Ein weiteres Kernkonzept der Objektorientierung ist die Polymorphie (Viel-gestaltigkeit). Es existieren verschiedene Ausprägungen dieses Konzeptes.Inklusionspolymorphie bedeutet, dass eine Methode in der Vererbungs-hierarchie immer die gleiche Bezeichnung erhält, diese Methode jedochvon jeder Klasse auf unterschiedliche Weise realisiert wird. Daraus ist zufolgern, dass erst zur Laufzeit des Programms anhand des konkret vor-handenen Objektes entschieden werden kann, welche Implementierungder Methode auszuführen ist. Dies wird als „späte Bindung“ bezeichnet[JOB02].

Bild 2.13 verdeutlicht diese Zusammenhänge. Das Beispiel enthält dieSchnittstelle „Display“ mit den zwei Methoden „updateView()“ und „set-

46

2.7 Java

Data()“. Die Klassen „TextDisplay“ und „GraphicDisplay“ verwirklichenjeweils diese Schnittstelle. Abhängig von der konkreten Klasse sinddie Methoden jedoch unterschiedlich implementiert. So erzeugt die Me-thode „updateView“ der Klasse „TextDisplay“ eine Textausgabe unddie der Klasse „GraphicDisplay“ eine grafische Repräsentation der Da-ten.

Eine weitere Form der Polymorphie ist die „Überladung“. Bei dieser sind ineiner Klasse zwei oder mehr Methoden mit der selben Bezeichnung, aberunterschiedlichen Signaturen vorhanden. Hier wird die auszuführende Me-thode durch den Typ der Parameter bestimmt.

2.7.2 Netzwerk-Kommunikation

Für die Netzwerk-Kommunikation stehen in Java verschiedene Typen von„Sockets“ zur Verfügung. Als „Socket“ bezeichnet man eine bidirektionale,vollduplexfähige Schnittstelle für die Interprozess-Kommunikation. DieseSchnittstelle ist ein Kommunikationsendpunkt, der durch eine Adresse,zum Beispiel eine Kombination von IP-Adresse und Port-Nummer (sieheKapitel 2.4.1), eindeutig bestimmt ist. Weiterhin stellt diese Schnittstelle,in Java entspricht dies der Klasse Socket, dem Programmierer in der Basis-variante folgende Methoden bereit:

• Ein Socket kann eine Verbindung zu einem entfernten Rechner her-stellen.

• Ein Socket kann Daten versenden.

• Ein Socket kann Daten empfangen.

• Ein Socket kann eine Verbindung trennen und schließen.

Dies vereinfacht die Nutzung von Netzwerkverbindungen für den Entwick-ler erheblich. Ein Socket stellt einen Ein- und Ausgabestrom bereit. DerProgrammierer muss sich daher nicht um die korrekte Reihenfolge vonDatenpaketen, Fehlererkennung, Fragmentierung der Daten und ähnlicheProblematiken der Netzwerkebene kümmern [HAR05].

47

2 Grundlagen

Ein Socket wird Hauptsächlich für Clients verwendet. Ein typischer Ablaufder Kommunikation einer Client-Anwendung besteht aus den folgendenSchritten:

1. Die Anwendung erstellt einen Socket.

2. Der Socket baut eine Verbindung zu dem entfernten Rechner auf.

3. Sobald eine Verbindung hergestellt ist, können der lokale und ent-fernte Rechner über den Ein- und Ausgabestrom des Sockets Datenaustauschen.

4. Sind alle Daten übertragen, schließen beide Kommunikationspartnerdie Verbindung.

Da eine Client-Applikation ohne eine entsprechende Server-Applikation we-nig sinnvoll ist, existiert speziell für Server-Anwendungen in Java die Klas-se ServerSocket. Diese Klasse bietet als Ergänzung zu den Methoden derBasisvariante nachstehende Funktionen an:

• Ein ServerSocket kann an einen bestimmten Port gebunden werden.

• Ein ServerSocket kann auf eingehende Verbindungen warten.

• Ein ServerSocket kann Verbindungen von entfernten Rechnern aufdem gebundenen Port akzeptieren.

Der Ablauf einer Server-Applikation unter Verwendung der Klasse Server-Socket besteht aus den folgenden Schritten:

1. Die Anwendung erstellt einen ServerSocket. Dieser ist an einen be-stimmten Port gebunden.

2. Der ServerSocket wartet auf eingehende Verbindungen.

3. Sobald eine eingehende Verbindung existiert, erzeugt der Server-Socket ein normales Socket-Objekt. Dieses ist dann für den eigentli-chen Datenaustausch zwischen Client- und Server-Anwendung ver-antwortlich.

4. Daten zwischen Client- und Server-Anwendung können ausgetauschtwerden.

48

2.7 Java

5. Sind alle Daten übertragen, schließen beide Kommunikationspartnerdie Verbindung.

6. Die Anwendung kehrt zurück zu Schritt 2.

2.7.3 Swing

Swing ist ein Teil von insgesamt fünf Bibliotheken der Java FoundationClasses (JFC)2 und bietet dem Entwickler die Möglichkeit, plattformun-abhängige grafische Benutzerschnittstellen zu verwirklichen. Die Swing-Bibliothek wurde erstmals 1998 veröffentlicht und besteht aus einer Viel-zahl von Klassen und Komponenten. Das Aussehen und Verhalten (Look &Feel) der grafischen Elemente lässt sich zur Laufzeit verändern und somitan die jeweilige Plattform anpassen.

Gegenüber dem Advanced Windowing Toolkit (AWT), der älteren Standard-Bibliothek für grafische Oberflächen, bietet Swing zahlreiche Erweiterun-gen und Verbesserungen [LOY03]:

• Anpassbares Aussehen und Verhalten (Look & Feel)

• Verbesserte und zusätzliche Komponenten, wie etwa Bäume, Tabellenund Unterfenster.

• Verwendung von Tastenkombinationen für Befehle von Komponen-ten.

• Mehrere Dokumente können innerhalb eines Fensters dargestellt wer-den (Multiple Document Interface – MDI).

• Leichtgewichtige Komponenten, das heißt die Komponenten sindselbst für die grafische Darstellung zuständig und nutzen hierzu Gra-fikprimitive der Java eigenen Grafik-Bibliothek.

• Die Realisierung der Komponenten erfolgt nach dem Modell-View-Controller-Muster (siehe Kapitel 2.3.4). Dies erleichtert die Wartungund Erweiterung der Komponenten.

2Die übrigen Bestandteile der JFC sind: Advanced Windowing Toolkit (AWT), Accessibi-lity (Barrierefreiheit), 2D Application Programming Interface (API), Drag and Drop

49

2 Grundlagen

Swing ist nicht thread-sicher und es müssen daher bei der Verwendungvon Threads entsprechende Sicherungsmaßnahmen vorgenommen werden.Weiterhin existieren noch alternative Bibliotheken zur Erstellung von gra-fischen Oberflächen mit Java:

• Advanced Windowing Toolkit (AWT) [SDT08]AWT ist eine Bibliothek, die schwergewichtige und plattformunabhän-gige grafische Komponenten zur Verfügung stellt. Schwergewichtigbedeutet, dass die Bibliothek zum Erstellen und Zeichnen der grafi-schen Elemente direkt auf entsprechende Funktionen des jeweiligenBetriebssystems zurück greift. AWT ist Bestandteil der Standardaus-gabe von Java.

• Standard Widget Toolkit (SWT) [SWT08]Das Standard Widget Toolkit war ursprünglich eine Entwicklung derFirma IBM für die Entwicklungsumgebung „eclipse“. Diese Bibliothekstellt, ähnlich AWT, ebenfalls plattformunabhängige und schwerge-wichtige grafische Komponenten bereit. Da SWT kein Bestandteil derStandardausgabe von Java ist, muss der jeweilige plattformabhängi-ge Teil der Bibliothek mitgeliefert werden.

• Qt Jambi [QTJ08]Qt Jambi baut auf der Bibliothek Qt der Firma Trolltech auf und stelltderen Funktionalität unter Java zur Verfügung. Qt ist wiederum ei-ne in C++ geschriebene, plattformunabhängige Grafik-Bibliothek. FürOpen-Source-Projekte muss die GPL verwendet werden, bei kommer-ziellen Projekten müssen entsprechende Lizenzen erworben werden.Diese Bibliothek befindet sich zurzeit in der Beta-Phase und eignetsich somit noch nicht für den produktiven Einsatz.

Swing zeichnet sich gegenüber diesen Produkten durch die gute Integrati-on der Bibliothek in die Java Standardausgabe und die einfache Anpassbar-keit sowie die Reife des Produktes aus.

50

3 Konzept

In diesem Kapitel werden die Lösungsansätze und Ideen beschrieben, diezur Umsetzung des Prototypen, zukünftig als DAVInspector bezeichnet,genutzt werden. Zunächst erfolgt eine Präsentation der Ergebnisse derin diesem Rahmen durchgeführten Marktstudie und anschließend wer-den die Schlussfolgerungen daraus erläutert. Danach folgt ein Überblicküber die Konzeption der Applikation. Die Ideen und Skizzen zu einzel-nen Komponenten werden in eigenen Abschnitten ausführlicher erläu-tert. Abschließend erfolgt eine kompakte Zusammenstellung der Ergebnis-se.

3.1 Marktanalyse

Nach einer Besprechung der Thematik zu Beginn des Projektes bestanddie Aufgabe zunächst darin zu ermitteln, ob und in welcher Form bereitsexistierende Anwendungen zur Lösung der Aufgabenstellung herangezo-gen oder erweitert werden könnten. Die dabei erstellte und hier vorliegendeMarktstudie (siehe Anhang D) gliedert sich in zwei Teile.

Im ersten Teil werden verfügbare Anwendungen zum Debuggen von HTTP-und WebDAV-Nachrichten sowie Applikationen zur Analyse von Netz-werkverkehr untersucht. Die dabei zugrunde liegenden Anforderungensind:

• Die Lizenz der Software muss eine Erweiterung des Produktes zulas-sen und von Seiten des Auftraggebers (DLR) akzeptiert sein.

• Die Software soll plattformunabhängig sein.

• Auswertung und Manipulation des Datenverkehrs soll möglich sein.

51

3 Konzept

• Die Software soll eine grafische Oberfläche zur Bedienung bieten.

Bewertet werden die betrachteten Werkzeuge nach den Kriterien:

• Funktionsumfang

• Einsatzzweck

• Erweiterbarkeit

• Aufwand für eine Erweiterung

Das Ergebnis dieser Studie weist ein Werkzeug als besonders geeignet füreine Erweiterung aus: die Software „NetTool“ des Autors Neil O’Tool. Die-se Software hat alle technischen Anforderungen erfüllt, jedoch konnte dieLizenz nicht eindeutig geklärt werden. Weiterhin war zum Zeitpunkt derMarktstudie nur eine sehr alte Version des Quellcodes der Anwendung ver-fügbar. Da eine zeitnahe Lösung der Aufgabe angestrebt wurde, fiel die Ent-scheidung zugunsten einer vollständigen Eigenentwicklung des Werkzeugs.Einzelne Merkmale und Eigenschaften der Produkte „NetTool“, „Fiddler“und „HTTP Probe“ sollten jedoch in der Eigenentwicklung besonders be-rücksichtigt werden. Eine genaue Erläuterung dazu findet sich in Kapitel2.3 der Marktstudie. Eine aktuellere Version des Quellcodes von „NetTool“wurde vom Autor der Software leider zu spät – die Arbeit an der Eigen-entwicklung war schon fortgeschritten – zur Verfügung gestellt und hattesomit keinen Einfluss mehr auf diese Arbeit.

Aufgrund der im ersten Teil der Marktstudie getroffenen Entscheidung füreine Eigenentwicklung setzt sich der zweite Teil der Marktanalyse mit ei-ner Auswahl an Programmiersprachen auseinander, die unter den gegebe-nen Randbedingungen als geeignet erscheinen. Auch hier werden die ge-wünschten Anforderungen definiert und Kriterien zur Bewertung festge-legt:

• Eine verbreitete Programmiersprache als optimale Voraussetzung füreine breite Nutzer- und Entwicklerbasis.

• Die Plattformunabhängigkeit soll einfach umzusetzen sein.

52

3.2 Gesamtkonzept

• Bibliotheken für Netzwerkprogrammierung, grafische Oberflächen,WebDAV- und XML-Verarbeitung sollen verfügbar sein.

Von der Seite des DLR wurden als Ausgangspunkt die Programmierspra-chen Java, Python und C/C++ und deren Kombination vorgegeben. Die ein-zelnen Kriterien werden für jede Sprache im Rahmen der Marktstudie erör-tert und schließlich die Entscheidung zugunsten der ProgrammierspracheJava begründet. Die wichtigsten Argumente sind an dieser Stelle kurz zu-sammengefasst: Java hat einen hohen Verbreitungsgrad bei Nutzern undEntwicklern. Dies erleichtert die Distribution der Anwendung und erhöhtdie Chancen, weitere Entwickler für das Projekt zu finden. Weiterhin istim Lieferumfang der Java-Entwicklungsumgebung schon eine Vielfalt anBibliotheken enthalten, und die Integration in verschiedene Plattformengestaltet sich ebenfalls sehr einfach.

3.2 Gesamtkonzept

In diesem Abschnitt werden das Gesamtkonzept der Software und die Ide-en und Vorgehensweisen beim Entwurf erörtert. Wie im vorherigen Kapi-tel beschrieben, existierte bereits zu Beginn der Arbeit eine Ideensamm-lung und ein grobes Anforderungsprofil an die gewünschte Software. DieErgebnisse der Marktstudie konnten zu einer Präzisierung der Leistungs-merkmale genutzt werden, und verschiedene Eigenschaften der untersuch-ten Produkte dienten als Anregung bei der Entwicklung des DAVInspec-tors.

Zunächst ist aufgrund des E

Documents

Elektrotechnik und Informatik - elib.dlr.de · Im Rahmen der Diplomarbeit sollen Konzept und Design für ein Open Sour- ce Werkzeug realisiert werden, mit dessen Hilfe WebDAV-Anwendungen