Konzeption und Realisierung einer skalierbaren ...

FH-Düsseldorf - FB 3 Elektrotechnik - Informationstechnik 

Konzeption und Realisierung einer skalierbaren, 

datenbankgestützten Java EE Web-Applikation für freiwillige Feuerwehren 

vorgelegt von 

Lars Meisegeier 

16. Oktober 2006 

1. Prüfer: Prof. Dr. Wolfgang Lux, FH-Düsseldorf 

2. Prüfer: Dr. Tim Paehler, Cassini Consulting GmbH

Inhaltsverzeichnis 

1 EINLEITUNG..................................................................................................................... 1 

2 ANFORDERUNGSBESCHREIBUNG............................................................................... 2 

2.1 IST-Analyse............................................................................................................... 2 

2.1.1 Feuerwehr Leichlingen.......................................................................................2 

2.1.2 Mitgliederverwaltung.......................................................................................... 3 

2.1.3 Bestellprozess....................................................................................................3 

2.2 Software.....................................................................................................................4 

2.3 Projektteam................................................................................................................4 

2.4 Entwicklungsumgebung.............................................................................................4 

2.4.1 Integrated Development Environment (IDE)...................................................... 4 

2.4.2 Unified Modeling Language (UML).................................................................... 5 

2.4.3 Concurrent Versions System (CVS)...................................................................5 

2.5 Geschäftsprozess...................................................................................................... 5 

2.5.1 Bestellung.......................................................................................................... 6 

2.6 Vorstudie..................................................................................................................10 

2.6.1 Anwendung...................................................................................................... 10 

2.6.2 Benutzer...........................................................................................................11 

2.6.3 Funktionen....................................................................................................... 11 

2.6.3.1 Mitglieder.................................................................................................. 11 

2.6.3.2 Mitgliederverwaltung.................................................................................12 

2.6.3.3 Bestellung.................................................................................................13 

2.6.3.4 Bestellprozess.......................................................................................... 13 

2.6.4 Anforderungen................................................................................................. 15 

3 ANALYSE........................................................................................................................ 15 

3.1 Pflichtenheft............................................................................................................. 15 

3.1.1 Ziel................................................................................................................... 16 

3.1.2 Funktionen....................................................................................................... 16 

3.1.2.1 Mitgliederverwaltung.................................................................................16 

3.1.2.2 Materialverwaltung................................................................................... 20 

3.1.2.3 Bestellprozess.......................................................................................... 22 

3.1.3 Benutzeroberfläche.......................................................................................... 26 

4 ENTWURF.......................................................................................................................27 

4.1 Architektur................................................................................................................27 

4.2 Server...................................................................................................................... 27 

i

4.3 Persistenz................................................................................................................ 28 

4.4 Model-View-Controller (MVC)..................................................................................29 

4.5 Portable Document Format (PDF)........................................................................... 30 

4.6 E-Mail.......................................................................................................................31 

4.7 Logging.................................................................................................................... 31 

4.8 Übersicht..................................................................................................................32 

5 IMPLEMENTIERUNG..................................................................................................... 32 

5.1 Webprogrammierung............................................................................................... 32 

5.2 Hibernate und JavaServer Faces............................................................................ 33 

6 SCHLUSSBETRACHTUNG............................................................................................ 35 

7 QUELLEN........................................................................................................................36 

8 ANHANG......................................................................................................................... 38 

9 SELBSTSTÄNDIGKEISTERKLÄRUNG..........................................................................44 

ii

Lars Meisegeier FH-Düsseldorf 

1 EINLEITUNG 

Die vorliegende Bachelorarbeit wurde bei der Cassini Consulting GmbH angefertigt. Als 

Aufgabenstellung wurde die selbständige Entwicklung einer Software für die Freiwillige 

Feuerwehr Leichlingen definiert. Diese sollte so angelegt werden, dass sie auf die 

Anforderungen anderer freiwilliger Feuerwehren leicht angepasst werden kann. Die dafür 

notwendigen Techniken habe ich mir in meinem Praxisprojekt angeeignet. Dieses ging 

der Arbeit voraus und fand unter demselben Betreuer statt. 

Gegenstand dieser Arbeit ist die Beschreibung der einzelnen Phasen des Software- 

Entwicklungsprozesses, die für die Bearbeitung dieser Aufgabe durchlaufen wurden. 

In der ersten Phase, der Anforderungsbeschreibung, wird zunächst die Struktur der 

Freiwilligen Feuerwehr Leichlingen erläutert. Anschließend werden die zentralen 

Geschäftsprozesse beschrieben und die gewünschten Funktionen der späteren 

Anwendung in der Vorstudie kurz zusammengefasst. 

Auf der Anforderungsbeschreibung aufbauend werden in der zweiten Phase, der Analyse, 

die geforderten Funktionalitäten detailliert herausgearbeitet und im Pflichtenheft 

festgelegt. Die dadurch festgelegte Struktur wird gleichzeitig in ein Klassenmodell 

umgesetzt. 

In der dritten Phase, dem Entwurf, erfolgt ausgehend von den Anforderungen, die 

Auswahl einer geeigneten Architektur. Zudem werden die Technologien festgelegt, die für 

die Umsetzung des geforderten Funktionsumfangs eingesetzt werden sollen. 

Die vierte Phase, die Implementierung, beschreibt die Umsetzung der im Pflichtenheft 

festgelegten Funktionen mit den im Entwurf ausgewählten Techniken. Dabei beschränkt 

sich die Betrachtung auf die wesentlichen Strategien und Konzepte, die verwendet 

wurden. 

Weitere Phasen werden nicht beschrieben, da sich die Entwicklung erst in der Validierung 

befindet und diese noch nicht abgeschlossen ist. 

Diese Arbeit endet mit einer Schlussbetrachtung, die meine Erfahrungen während des 

Projekts zusammenfasst. 

1


2 ANFORDERUNGSBESCHREIBUNG 

2.1 IST-Analyse 

Als Grundlage für die Erstellung der IST-Analyse fand ein Interview mit einem 

sachkundigen Mitglied der Freiwilligen Feuerwehr Leichlingen statt. Die dabei 

gewonnenen Erkenntnisse werden nachfolgend erläutert. 

2.1.1 Feuerwehr Leichlingen 

Leichlingen ist eine Stadt mit ca. 30.000 Einwohnern, sie liegt zwischen Köln und 

Leverkusen und besitzt keine eigene Berufsfeuerwehr. Die Aufgaben der Feuerwehr 

werden daher ausschließlich von den rund 120 Mitgliedern der Freiwilligen Feuerwehr 

übernommen. 

Abbildung 1: Struktur Freiwillige Feuerwehr Leichlingen 

Das Stadtgebiet Leichlingens ist von der Freiwilligen Feuerwehr in vier Bereiche eingeteilt 

worden. Für jeden dieser Bereiche ist ein separater Löschzug zuständig. Alle Löschzüge 

haben daher eigene Standorte, Fahrzeuge, Ausrüstung, Material und verwalten sich 

weitestgehend autonom. 

Wehrführer 

Leiter Ausstattung 

Kleiderkammer Sachausstattung Atemschutzwerkstatt 

Löschzug I Löschzug II Löschzug III Löschzug IV 

Zusätzlich besitzt die Feuerwehr drei zentrale, übergeordnete Einrichtungen, die für die 

Beschaffung, Reinigung, Reparatur und Wartung von Material zuständig sind. Diese 

Einrichtungen unterscheiden sich abhängig vom Material in: 

2


● Kleiderkammer 

● Sachausstattung 

● Atemschutzwerkstatt 1 

All diese Einrichtungen haben einen gemeinsamen Vorgesetzten, der für die gesamte 

Ausstattung zuständig ist: den Leiter Ausstattung. 

Die höchste Instanz, die allen anderen übergeordnet und für sämtliche Belange der 

Feuerwehr verantwortlich ist, ist der Wehrführer. 

2.1.2 Mitgliederverwaltung 

Gegenwärtig erfolgt die Mitgliederverwaltung, also das Erfassen von personenbezogenen 

Daten, mit Hilfe von Excel-Tabellen. Diese Tabellen werden, bedingt durch die dezentrale 

Struktur der Feuerwehr, von jedem Löschzug eigenständig erfasst und müssen manuell 

zu einer Gesamttabelle zusammengefügt werden. Erschwerend kommt dabei hinzu, dass 

keine standardisierte, einheitliche Tabellenvorlage existiert. Daher variiert der Umfang und 

die Art der erfassten Daten sehr stark. Die Sicherstellung der Konsistenz der Daten ist 

somit sehr aufwendig und arbeitsintensiv. 

2.1.3 Bestellprozess 

Bestellungen von Material stellen einen der wichtigsten Geschäftsprozesse dar. Der 

Ablauf dieses Prozesses beinhaltet eine Vielzahl von Genehmigungsvorgängen, an dem 

Mitglieder aus allen Bereichen der Feuerwehr beteiligt sind. 

Die Bestellungen werden individuell in einem Textverarbeitungsprogramm erstellt. 

Anschließend erfolgt die Weiterleitung an ein anderes Mitglied zur Genehmigung; dies 

geschieht in der Regel per E-Mail. Alle Vorgänge, d.h. erfassen, genehmigen, weiterleiten 

müssen dabei von jedem Mitglied manuell durchgeführt werden. Darüber hinaus wird der 

Ablauf des Gesamtprozesses (z.B. hat diese Bestellung wann genehmigt?) nicht separat 

erfasst. 

1 Aus Gründen der Komplexität des Themas wird die Atemschutzwerkstatt in der weiteren 

Betrachtung nicht weiter berücksichtigt. 

3


2.2 Software 

Zur Entscheidung über das weitere Vorgehen wurden Softwarelösungen, die eigens für 

dieses Aufgabengebiet konzipiert sind, untersucht. 

Ein kommerzielles Softwareprodukt, das speziell für den Einsatz bei Feuerwehren 

entwickelt und dessen Anschaffung bei der Freiwilligen Feuerwehr Leichlingen zuletzt 

diskutiert wurde, ist AMEfire (vgl. www.amefire.de). 

AMEfires Funktionalität beschränkt sich im Wesentlichen auf reine Verwaltungsaufgaben, 

die bei einer Feuerwehr anfallen. Es ist als Einzelplatz-Anwendung konzipiert und eignet 

sich daher sehr schlecht für die dezentrale Struktur der Freiwilligen Feuerwehr 

Leichlingen. Zudem sieht es keine Möglichkeit vor, neue, individuelle Geschäftsprozesse 

in die Anwendung zu integrieren. Daher wurde die Entwicklung einer neuen, auf die 

Anforderungen der Freiwilligen Feuerwehr Leichlingen optimierte Anwendung 

beschlossen. 

2.3 Projektteam 

Projektleiter und zugleich Betreuer dieser Arbeit war Herr Dr. Paehler von dem IT- 

Beratungsunternehmen Cassini Consulting GmbH. Er besitzt langjährige Erfahrung in der 

Realisierung von IT-Projekten und brachte diese vor allem in der Kundenkommunikation 

und Projektplanung mit ein. Ferner überwachte er den Projektfortschritt und übernahm 

während der Implementierungsphase den Software-Test. 

Analyse, Entwurf, Implementierung und alle weiteren Aufgaben wurden von mir 

übernommen. Zur Unterstützung wurden dabei jederzeit Anregungen, Beratung und 

Hilfestellung vom Betreuer angeboten. 

2.4 Entwicklungsumgebung 

Die Entwicklungsumgebung umfasst die Programme, die für die Modellierung und spätere 

Implementierung eingesetzt wurden. 

2.4.1 Integrated Development Environment (IDE) 

Zentrale IDE für die Modellierung und Implementierung ist die Eclipse Web Tools Platform 

(WTP). Die WTP ist eine bewährte und verbreitet eingesetzte Umgebung, die u.a. eine 

Vielzahl von speziellen Editoren für alle Dateien, die man bei der Entwicklung von 

modernen Web-Applikationen benötigt (HTML, CSS, JavaSript, JSP, JSF, SQL, XML, 

4


DTD, XSD, WSDL etc.), anbietet. Darüber hinaus ermöglicht sie es, alle gängigen 

Webserver (Tomcat, JOnAS, JBoss, J2EE SDK, IBM WebSphere etc.) mit in die 

Entwicklungsumgebung zu integrieren. Für den Fall einer späteren, Fehlersuche stehen 

außerdem nützliche Tools wie Debugger und TCP/IP Monitor bereit (vgl. 

www.eclipse.org/webtools). 

2.4.2 Unified Modeling Language (UML) 

Unverzichtbar bei der zeitgemäßen Modellierung von Software ist der Einsatz von UML. 

Setzt man UML ein, so ist eine starke Interaktion zwischen UML-Modellierungstool und 

Entwicklungsumgebung gewünscht; um z.B. aus einem UML-Klassendiagramm ein 

Codegerüst zu generieren und umgekehrt aus einem Codegerüst ein entsprechendes 

Diagramm. Das Diagramm sollte immer dem aktuellen Code in der 

Entwicklungsumgebung entsprechen. 

Genau diese Funktionalität lässt sich durch das Omondo EclipseUML Plugin in die WTP 

integrieren. Nach Installation des Plugins ist man in der Lage, jede Art von UML- 

Diagramm innerhalb der Entwicklungsumgebung zu erstellen. Dabei werden, sofern 

möglich, automatisch entsprechende Codegerüste generiert. Erfolgen Änderungen am 

Code, so werden die zugehörigen Diagramme ebenfalls automatisch aktualisiert (vgl. 

www.omondo.com). 

2.4.3 Concurrent Versions System (CVS) 

Zur Vereinfachung der Versionsverwaltung und Weitergabe des Quellcodes wird ein 

zentraler CVS-Server genutzt. Dieser ist in ein Backup-Konzept integriert, so dass keine 

speziellen Sicherungskopien erstellt werden müssen. 

2.5 Geschäftsprozess 

Aufgrund des engen zeitlichen Rahmens beschränkt sich dieses Projekt in erster Linie auf 

den Hauptgeschäftsprozess Bestellung. Dabei wird jedoch die spätere Erweiterung um 

neue Geschäftsprozesse stets berücksichtigt. 

5


2.5.1 Bestellung 

Innerhalb der Feuerwehr übernehmen Mitglieder unterschiedliche Rollen. Rollen 

entsprechen dabei der Berechtigung, Aufgaben in einem eingeschränkten Tätigkeitsfeld 

durchführen zu können. Jedes Mitglied kann mehrere dieser Rollen übernehmen. 

Im Folgendem wird der Ablauf des Bestellprozesses mit dem an ihm beteiligten Rollen 

detailliert erläutert. 

Löschzug Bestellung erstellen 

erstellen 

Abbildung 2: Aktivitätsdiagramm 'Löschzug Bestellung erstellen', 'Löschzug Bestellung 

genehmigen' 

Bestellungen dürfen innerhalb eines Löschzuges nur von Mitgliedern mit der Rolle 

'Löschzug Bestellung erstellen' verfasst werden. 

Zur Verhinderung von Missbrauch werden alle Bestellungen anschließend einem Mitglied, 

das die Rolle 'Löschzug Bestellung genehmigen' übernimmt, vorgelegt. Dieses muss 

selbst Mitglied des gleichen Löschzuges sein und besitzt für den Fall, dass die Bestellung 

ungerechtfertigt ist, die Möglichkeit, sie abzulehnen. Ist sie begründet, erteilt er eine 

Genehmigung. 

Löschzug Bestellung genehmigen 

genehmigen 

ablehnen 

Abhängig vom bestelltem Artikel erfolgt nun die Weiterleitung der Bestellung an ein 

Mitglied mit der Rolle 'Kleiderkammer Bestellung genehmigen' (KK), 'Sachausstattung 

Bestellung genehmigen' (SA) oder 'Leiter Ausstattung' (LA). 

KK SA LA 

6


KK 

Abbildung 3: Aktivitätsdiagramm 'Kleiderkammer Bestellung genehmigen' 

Geht eine Bestellung für die Rolle 'Kleiderkammer Bestellung genehmigen' ein und der 

angeforderte Artikel ist vorrätig, so wird dieser ausgeliefert und die Bestellung ist 

erfolgreich abgearbeitet. Ist der Artikel nicht vorhanden, so kann die Beschaffung durch 

Genehmigung der Bestellung veranlasst werden. Die Bestellung wird in diesem Fall dem 

'Leiter Ausstattung' übergeben. 

Sind Änderungen an der Bestellung notwendig, so können diese durch Editieren 

vorgenommen werden. Die ursprüngliche Bestellung bleibt dabei zum Zweck der späteren 

Nachvollziehbarkeit unverändert erhalten. 

Erscheint eine Bestellung jedoch unbegründet, wird sie abgelehnt. 

Zusätzlich besteht die Möglichkeit, mehrere Bestellungen zu einer Sammelbestellung 

zusammenzufassen. Diese Sammelbestellung stellt eine neue, eigenständige Bestellung 

dar, die im Weiteren gesondert betrachtet wird. 

Nach dem Erstellen einer Sammelbestellung ist es möglich, weitere Bestellungen 

hinzuzufügen, vorhandene zu entfernen und einzelne Bestellungen zu editieren. Erfolgt 

die Genehmigung der Sammelbestellung, wird diese ebenfalls an den 'Leiter Ausstattung' 

weitergeleitet. 

editieren 

Kleiderkammer Bestellung genehmigen 

gruppieren 

genehmigen ablehnen auslief ern 

entf ernen 

hinzuf ügen 

Sammelbestellung 

editieren 

genehmigen 

LA LAs 

7


Abbildung 4: Aktivitätsdiagramm 'Kleiderkammer Bestellung erstellen' 

Mitglieder, die die Rolle 'Kleiderkammer Bestellung erstellen' haben, können z.B. zum 

Erhalt der Lagerbestände eigene Bestellungen für die Kleiderkammer verfassen. 

Bearbeitet werden diese Bestellungen analog zu den Bestellungen eines Löschzuges. 

Zum Schutz vor Missbrauch ist jedoch wieder darauf zu achten, dass der Verfasser einer 

Bestellung nicht auch Genehmiger sein darf. 

SA 

Abbildung 5: Aktivitätsdiagramm 'Sachausstattung Bestellung genehmigen' 

Funktionell besitzt die Sachausstattung mit den Rollen 'Sachausstattung Bestellung 

genehmigen' und 'Sachausstattung Bestellung erstellen' exakt die gleichen Möglichkeiten, 

eine Bestellung zu bearbeiten wie die Kleiderkammer. Nach Genehmigung einer 

Bestellung bzw. einer Sammelbestellung erfolgt auch hier die Weiterleitung an 'Leiter 

Ausstattung'. 

editieren 

Kleiderkammer Bestellung erstellen 

erstellen KK 

Sachausstattung Bestellung genehmigen 

gruppieren 

genehmigen ablehnen auslief ern 

entf ernen 

hinzuf ügen 


editieren 

genehmigen 

LA LAs 

8


LA 

Abbildung 6: Aktivitätsdiagramm 'Sachausstattung Bestellung erstellen' 

Abbildung 7: Aktivitätsdiagramm 'Leiter Ausstattung' 

Der 'Leiter Ausstattung' erhält Bestellungen und Sammelbestellungen. Für beide hat er 

die Möglichkeit, sie zu genehmigen oder abzulehnen. Genehmigt er sie, werden sie an die 

Rolle 'Wehrführer' weitergeleitet. 

WF 

genehmigen 

WF 

genehmigen 

ÜS 

Abbildung 8: Aktivitätsdiagramm 'Wehrführer' 

Sachausstattung Bestellung erstellen 

erstellen SA 


Wehrführer 


ablehnen ablehnen 

genehmigen 

WFs 


ablehnen ablehnen 

genehmigen 

ÜSs 

LAs 

WFs 

9


Die Rolle 'Wehrführer' besitzt ebenfalls die Möglichkeit, Bestellungen und 

Sammelbestellungen abzulehnen oder zu genehmigen. Findet eine Genehmigung statt, 

erfolgt eine Weiterleitung an die Rolle 'Übermittler an Stadt'. 

Abbildung 9: Aktivitätsdiagramm 'Übermittler an Stadt' 

Zur Fertigstellung einer Bestellung ist es erforderlich, dass diese in Schriftform persönlich 

oder über den Postweg bei der Stadt eingereicht wird. Hierfür besitzt die Rolle 'Übermittler 

an Stadt' die Möglichkeit, Bestellungen wie auch Sammelbestellungen auszudrucken. 

Um den Ablauf des Bestellprozesses zu beschleunigen, erfolgt nach jedem 

Genehmigungsvorgang der Versand einer E-Mail Benachrichtigung an alle Mitglieder, die 

aufgrund ihrer Rolle in der Lage sind, die Bestellung weiter zu bearbeiten. Zusätzlich 

bekommt der Ansprechpartner der Bestellung eine E-Mail, die ihn über den 

Prozessfortschritt informiert. 

Im Falle der Ablehnung einer Bestellung wird der Ansprechpartner per E-Mail über den 

Grund benachrichtigt. 

2.6 Vorstudie 

Die Vorstudie fasst alle erhaltenen Informationen stichpunktartig zusammen und wurde 

den Entscheidungsträgern der Freiwilligen Feuerwehr Leichlingen vorgelegt. Sie bildet 

daher die Grundlage für die nachfolgende Analyse. 

2.6.1 Anwendung 

Ziel der Anwendung ist es, den Ablauf des Bestellprozesses der Freiwilligen Feuerwehr 

Leichlingen zu vereinfachen und eine spätere Nachvollziehbarkeit zu ermöglichen. 

2.6.2 Benutzer 

Übermittler an Stadt 


ÜS drucken drucken 

ÜSs 

Konzipiert ist die Anwendung für Mitglieder der Freiwilligen Feuerwehr Leichlingen. Die 

10


Mitglieder unterscheiden sich dabei in den Rollen, die sie einnehmen. Rollen entsprechen 

der Berechtigung, Tätigkeiten innerhalb eines klar eingegrenzten Aufgabengebiets 

durchzuführen. Jedes Mitglied kann mehrere Rollen übernehmen. 2 

2.6.3 Funktionen 

2.6.3.1 Mitglieder 

Zu den personenbezogenen Daten, die von einem Mitglied erfasst werden, gehören: 

[V1] 3 Vorname [V2] Name 

[V3] Geschlecht [V4] Geburtsdatum 

[V5] Adresse [V6] Telefonnummern 

[V7] E-Mail Adressen [V8] Arbeitgeber 

[V9] Fahrerlaubnis [V10] Personalnummer der Feuerwehr 

[V11] Zugehöriger Löschzug [V12] Dienstgrad 

[V13] Dienstfunktion [V14] Absolvierte Ausbildungen 

[V15] Rollen 

2 Im Folgendem entspricht jeder Akteur in einem Anwendungsfalldiagramm einer einzelnen Rolle. 

3 Anforderungen der Vorstudie werden zur Vereinfachung der Kommunikation im Folgendem mit 

[V+Zahl] gekennzeichnet. 

11


Ein Klassenmodell, das diese Beziehungen abbildet, ist folgendes: 

Abbildung 10: Klassendiagramm Mitglied 

2.6.3.2 Mitgliederverwaltung 

Mitglieder können von einem Administrator angelegt [V16], editiert [V17] und angezeigt 

[V18] werden. 

Administrator 

Mitglied anzeigen 

Mitglied anlegen 

Mitglied editieren 

Abbildung 11: Anwendungsfalldiagramm 'Administrator' 

12


2.6.3.3 Bestellung 

Die Daten einer Bestellung umfassen folgende Angaben: 

[V19] Bestellte Artikel [V20] Anzahl des Artikels 

[V21] Typ der Bestellung [V22] Bestellnummer 

[V23] Datum der Bedarfsmeldung [V24] Erstellungsdatum 

[V25] Geschätzter Kostenrahmen [V26] Drei mögliche Lieferanten 

[V27] Verfasser [V28] Ansprechpartner 

[V29] Empfänger 

Daraus ergibt sich das folgende Klassenmodell: 

Abbildung 12: Klassendiagramm Bestellung 

2.6.3.4 Bestellprozess 

Bestellungen können von Mitgliedern mit den Rollen 'Löschzug Bestellung erstellen' [V30], 

'Kleiderkammer Bestellung erstellen' [V31] oder 'Sachausstattung Bestellung erstellen' 

[V32] verfasst werden. 

Löschzug 

Bestellung erstellen 


Kleiderkammer 


Abbildung 13: Anwendungsfalldiagramm 'Bestellung erstellen' 

Sachausstattung 


13


Für die weitere Abwicklung des Bestellprozesses (siehe Kapitel 2.5.1 Seite 6) werden die 

beteiligten Rollen mit ihren zugehörigen Möglichkeiten nachfolgend aufgelistet. 

Rolle 

Bestellung 

genehmigen 

Bestellung 

ablehnen 

Löschzug Bestellung genehmigen [V33] [V34] 

Bestellung 

gruppieren 

Kleiderkammer Bestellung genehmigen [V35] [V36] [V37] 

Sachausstattung Bestellung genehmigen [V38] [V39] [V40] 

Leiter Ausstattung [V41] [V42] 

Wehrführer [V43] [V44] 

Tabelle 1: Rollen Bestellprozess 

Löschzug 

Bestellung 

genehmigen 

Kleiderkammer 

Bestellung 

genehmigen 

Abbildung 14: Anwendungsfalldiagramm Bestellprozess 

Am Ende des Bestellprozesses besitzt die Rolle 'Übermittler an die Stadt' zudem die 

Möglichkeit, Bestellungen auszudrucken. 


Bestellung genehmigen 

Bestellung 

gruppieren 


Bestellung 

genehmigen 

Bestellung ablehnen 

Bestellung 

ausdrucken 

Leiter 

Ausstattung 

Abbildung 15: Anwendungsfalldiagramm 'Übermittler an Stadt' 

Wehrführer 

14


2.6.4 Anforderungen 

Oberstes Ziel, neben der Funktionsfähigkeit, ist die Benutzerfreundlichkeit. Um eine 

übersichtliche, intuitiv leicht zu bedienende, grafische Benutzeroberfläche [V45] zu 

erhalten, wird eine umfangreiche Menüstruktur angestrebt. 

Freiwillige Feuerwehr Leichlingen 

Anlegen Anzeigen Editeren 

Person 

Arbeitgeber 

Feuerw ehr 

Abbildung 16: Entwurf einer möglichen Menüstruktur 

3 ANALYSE 

In der Analyse wurden die Informationen aus der Anforderungsbeschreibung gegliedert 

und in eine logische bzw. funktionale Struktur gebracht. Anschließend wurden alle Details 

dieser Struktur ausgearbeitet und im Pflichtenheft festgeschrieben. 

3.1 Pflichtenheft 

Das Pflichtenheft umfasst die detaillierte Beschreibung aller geforderten Funktionen. Es 

bildet die Basis für die spätere Abnahme und ist daher für Kunden und Entwickler 

verbindlich. 

3.1.1 Ziel 

Ziel ist es, eine Anwendung zu entwickeln, die in der Lage ist, die Abwicklung des 

Hauptgeschäftsprozess Bestellung effektiv zu unterstützen. Dabei soll der Ablauf für die 

spätere Nachvollziehbarkeit lückenlos dokumentiert werden. Zudem sollen die 

Anknüpfungspunkte zwischen dem Bestellprozess und einer später zu implementierenden 

Materialverwaltung geschaffen werden. Für die Erfassung personenbezogener Daten ist 

desweiteren eine Mitgliederverwaltung zu erstellen. 

Mitglieder Bestellungen 

15


3.1.2 Funktionen 

3.1.2.1 Mitgliederverwaltung 

Daten der Mitglieder werden für den Ablauf des Bestellprozesses und die Umsetzung des 

Rollenkonzepts benötigt. Zu den personenbezogenen Daten gehören neben Vornamen 

[P1] 4 , Namen [P2], Geburtsdatum [P3] und Geschlecht [P4] sowie der aktuelle Wohnort 

[P5] mit Straße [P6] und Postleitzahl [P7]. Desweiteren können mehrere Telefonnummer 

[P8] und E-Mail Adressen [P9] angegeben werden. 

Telefonnummern besitzen dabei neben Vorwahl [P10] und Durchwahl [P11], eine 

optionale Beschreibung [P12] entsprechend nachfolgender Tabelle. 

Allgemein 

Mobil 

Privat 

Arbeitgeber 

Fax 

Tabelle 2: Telefonnummern Beschreibungen 

Ebenso wird erfasst, welche Fahrerlaubnis [P13] ein Mitglied besitzt. Die 

Führerscheinklassen können dabei entsprechend den alten oder neuen Klassen [P14] 

angegeben werden. Mögliche Werte sind: 

alt 1 1a 1b 2 3 4 5 6 

neu A1 A B C1 C D1 D BE C1E CE D1E DE M L T 

Tabelle 3: Führerscheinklassen 

Neben den persönlichen Angaben können auch die Daten des Arbeitgebers [P15] 

hinterlegt werden. Sie bestehen aus Namen [P16], Anschrift [P17] und einer oder 

mehreren Telefonnummern [P18]. 

Jedes Mitglied gehört einem Löschzug an [P19] und erhält eine eindeutige, vierstellige 

Personalnummer [P20], die wie folgt aufgebaut ist. 

4 Anforderungen der Vorstudie werden zur Vereinfachung der Kommunikation im Folgendem mit 

[P+Zahl] gekennzeichnet. 

16


Ziffer 1 Ziffer 2 Ziffer 3 Ziffer 4 

Feuerwehr 

Leichlingen (4) 

Tabelle 4: Aufbau Personalnummer 

Löschzugnummer Laufende Nummer 

innerhalb des Löschzuges 

Zu den Daten des Löschzuges zählen neben Namen [P21], Nummer [P22] und Kürzel 

[P23] auch die zu ihm gehörigen Gebäude [P24] und Fahrzeuge [P25]. Gebäude werden 

dabei mit Namen [P26] und Anschrift [P27], Fahrzeuge mit Funkrufname [P28] und 

Kennzeichen [P29] erfasst. 

Die Angaben zu einem Mitglied umfassen desweiteren den Dienstgrad [P30] und die 

Dienstfunktion [P31]. Dienstgrade unterscheiden sich, abhängig vom Geschlecht [P32], in 

ihrer Bezeichnung [P33] und im Kürzel [P34]. Mögliche Dienstgrade werden in der 

folgenden Tabelle aufgelistet. 

Männlich Weiblich 

Bezeichnung Kürzel Bezeichnung Kürzel 

Feuerwehrmann-Anwärter FMA Feuerwehrfrau-Anwärterin FFA 

Feuerwehrmann FM Feuerwehrfrau FF 

Oberfeuerwehrmann OFM Oberfeuerwehrfrau OFF 

Hauptfeuerwehrmann HFM Hauptfeuerwehrfrau HFF 

Unterbrandmeister UBM Unterbrandmeisterin UBM 

Brandmeister BM Brandmeisterin BM 

Oberbrandmeister OBM Oberbrandmeisterin OBM 

Hauptbrandmeister HBM Hauptbrandmeisterin HBM 

Brandinspektor BI Brandinspektorin BI 

Brandoberinspektor BOI Brandoberinspektorin BOI 

Stadtbrandinspektor StBI Stadtbrandinspektorin StBI 

Tabelle 5: Dienstgrade 

Dienstfunktionen unterscheiden sich ebenfalls, abhängig vom Geschlecht [P35], in ihrer 

Bezeichnung [P36]. Erlaubte Dienstfunktionen sind: 

17


Bezeichnung männlich Bezeichnung weiblich 

Jugendfeuerwehrwart Jugendfeuerwehrwart 

Kreisjugendfeuerwehrwart Kreisjugendfeuerwehrwart 

stellvertretender Gruppenführer stellvertretende Gruppenführerin 

Gruppenführer Gruppenführerin 

stellvertretender Zugführer stellvertretende Zugführerin 

Zugführer Zugführerin 

stellvertretender Leiter der Feuerwehr stellvertretende Leiterin der Feuerwehr 

Leiter der Feuerwehr Leiterin der Feuerwehr 

stellvertretender Kreisbrandmeister stellvertretende Kreisbrandmeisterin 

Kreisbrandmeister Kreisbrandmeisterin 

stellvertretender Bezirksbrandmeister stellvertretende Bezirksbrandmeisterin 

Bezirksbrandmeister Bezirksbrandmeisterin 

Tabelle 6: Dienstfunktionen 

Ferner ist es möglich, Ausbildungen [P37], die im Rahmen der Feuerwehr absolviert 

wurden, zu vermerken. Ausbildungen sind: 

F2 B2 MOD 1 TM 1 ABC 1 

F3 B3 MOD 2 TM 2 Kettensäge 

F4 B4 MOD 3 Maschinist 

F5 B5 MOD 4 

F6 B6 

Tabelle 7: Ausbildungen 

18


Mitglieder können zudem mehrere, unterschiedliche Rollen innerhalb der Feuerwehr 

übernehmen. Definierte Rollen sind: 

Löschzug Mitglieder anzeigen 

Löschzug Mitglieder verwalten 








Wehrführer 


Administration 

Tabelle 8: Rollen 

Daraus ergibt sich das folgende Klassendiagramm: 


19


Mitglieder können von einem Administrator angelegt [P38], editiert [P39] und angezeigt 

[P40] werden. Innerhalb eines Löschzuges können Mitglieder die Möglichkeit besitzen, 

Mitglieder des eigenen Löschzuges anzuzeigen [P41] oder zu verwalten. Das Verwalten 

beinhaltet neben dem Anzeigen das Anlegen [P42] und Editieren [P43] von Mitgliedern 

des eigenen Löschzuges. 

Abbildung 18: Anwendungsfalldiagramm Mitgliederverwaltung 

3.1.2.2 Materialverwaltung 

Die Abhängigkeit des Bestellprozess vom bestellten Artikel wird durch die 

Implementierung einer rudimentären Materialverwaltung abgebildet. Dabei werden 

ausschließlich die Funktionalitäten umgesetzt, die für den Bestellprozess erforderlich sind. 

Artikel 

Administrator 


Mitglied anlegen 

Mitglied editieren 

Artikel repräsentieren einen konkreten und eindeutigen Gegenstand (Entität), der 

entweder über den Bestellprozess beschafft wird oder bereits vorhanden ist. Jeder Artikel 

besitzt einen Artikelstandort [P44], an dem er sich befindet bzw. für den er vorgesehen ist. 

Als Standorte kommen Mitglieder [P45], Fahrzeuge [P46] oder Gebäude [P47] in Frage. 

Ein Artikel besitzt zudem eine Vielzahl von Eigenschaften mit bestimmten Werten. Anzahl 

und Art der möglichen Eigenschaften werden zentral in einem abstrakten Prototyp des 

Artikels, den Artikelstamm [P48], festgelegt. Neben einem Namen [P49] und beliebig 

vielen Eigenschaften [P50], verfügt der Artikelstamm über einen Verweis, zu welcher 

Artikelgruppe [P51] er gehört. Die Artikelgruppe dient dabei lediglich zur logischen 

Zusammenfassung der Artikelstämme in die Gruppen: 

Persönliche Schutzausrüstung 

Fahrzeugbeladung 

Bescheinigung 

Tabelle 9: Artikelgruppen 

Löschzug 

Mitglied verw alten 

Löschzug 


20


Ferner ist dem Artikelstamm zugeordnet, welche Einrichtung der Feuerwehr, im Falle 

einer Bestellung, für die Abwicklung zuständig ist [P52]. Mögliche Abwicklungsstellen 

sind: 

Kleiderkammer 



Tabelle 10: Abwicklungsstellen 

Artikel HAIX-Feuerwehr-Schuhe classic 

Artikelstamm Schuhe 

Artikelgruppe Persönliche Schutzausrüstung 

Artikelstandort Markus Mustermann 

Artikeleigenschaften Eigenschaft Wert 

Größe 45 

Stahlsohle Nein 

Stahlkappe Ja 

Tabelle 11: Beispiel eines Artikels innerhalb der Materialverwaltung 

Abbildung 19: Klassendiagramm Artikel 

21


Artikelstämme können vom Administrator angezeigt, editiert und neu angelegt werden: 

3.1.2.3 Bestellprozess 

Abbildung 20: Anwendungsfalldiagramm Artikelstämme 

Bestellungen und ihre Abläufe stellen einen Hauptgeschäftprozess der Freiwilligen 

Feuerwehr Leichlingen dar. Die Angaben einer Bestellung umfassen daher, neben den 

reinen Bestelldaten, Informationen zum Bestellungsablauf. 

Zu den Daten einer Bestellung gehören neben Erstellungsdatum [P53] und Verfasser 

[P54] auch die Angabe, um welchen Bestellungstyp [P55] es sich handelt. 

Bestellungstypen sind: 

Ersatzbeschaffung 

Neubeschaffung 

Inspektion/TÜV/TÜD 

Reparatur 

Tabelle 12: Bestellungstypen 

Weiterer Bestandteil ist der zu bestellende Artikel [P56]. Er wird mit den gewünschten 

Werten [P57] entsprechend seinen zugehörigen Artikelstamm-Eigenschaften erfasst. 

Zusätzlich zum Erstellungsdatum wird auch das Datum, an dem der Bedarf nach diesem 

Artikel [P58] gemeldet wurde, angegeben. Auch der spätere Artikelstandort [P59] wird 

hinterlegt. 

Beim Bestellprozess regelt ein Kostenstellensystem [P60] die Zuständigkeit zwischen 

Ersteller einer Bestellung bzw. Gruppierer einer Sammelbestellung und den möglichen 

Artikelstandorten Mitglieder [P61], Fahrzeuge [P62] oder Gebäude [P63]. Neben einer 

eindeutigen Nummer [P64] haben Kostenstellen einen Namen P[65]. Die der Freiwilligen 

Feuerwehr Leichlingen lauten: 

Administrator 

Artikelstamm 

anlegen 

Artikelstamm 

anzeigen 

Artikelstamm 

editieren 

22


Name Nummer 

Löschzug 1 11 




Kleiderkammer 20 

Kleiderkammer Sammelbestellung 21 

Sachausstattung 30 

Sachausstattung Sammelbestellung 31 

Tabelle 13: Kostenstellen der Freiwilligen Feuerwehr Leichlingen 

Kostenstellen werden zudem für die Verwaltung und Generierung eindeutiger 

Bestellnummern genutzt. Eine Bestellnummer ist achtstellig und setzt sich aus der 

Kostenstellennummer [P66], dem aktuellen Jahrzehnt und einer laufenden Nummer [P67] 

zusammen. 

Ziffer 1 Ziffer 2 Ziffer 3 Ziffer 4 Ziffer 5 Ziffer 6 Ziffer 7 Ziffer 8 

Kostenstelle Jahrzehnt Laufende Nummer der Kostenstelle 

Tabelle 14: Aufbau einer Bestellnummer 

Mit dem Anlegen erhält jede Bestellung eine Bestellnummer, entsprechend der 

Kostenstelle zugewiesen. 

Eine Bestellung beinhaltet zudem drei mögliche Lieferanten [P68] für den gewünschten 

Artikel. Die Angaben eines Lieferanten umfassen Namen [P69], Anschrift [P70] und, 

sofern vorhanden, mehrere Telefonnummern [P71]. 

Ferner wird der zu erwartende Kostenrahmen [P72] und die gewünschte Stückzahl [P73] 

mit aufgenommen. Weitere Informationen für die spätere Abwicklung sind ein Empfänger 

[P74], der den Artikel bei Lieferung erhalten soll, und ein Ansprechpartner [P75] für den 

Fall von Rückfragen. 

23


Daraus ergibt sich folgendes Klassendiagramm: 


Bestellungen können von Mitgliedern mit den Rollen 'Löschzug Bestellung erstellen' [P76], 

'Kleiderkammer Bestellung erstellen' [P77] oder 'Sachausstattung Bestellung erstellen' 

[P78] verfasst werden. 

Löschzug 



Kleiderkammer 


Abbildung 22: Anwendungsfalldiagramm 'Bestellung erstellen' 



Abhängig vom Ersteller durchläuft sie anschließend den Bestellprozess (siehe Kapitel 

2.5.1 Seite 6). Die daran beteiligten Rollen besitzen eine Reihe von Möglichkeiten, eine 

Bestellung zu bearbeiten; diese werden nachfolgend tabellarisch aufgeführt. 

24


Anwendungsfall 

Löschzug 

Bestellung 

genehmigen 

Kleiderkammer 

Bestellung 

genehmigen 


Bestellung 

genehmigen 

Leiter der 

Ausstattung 

Bestellung genehmigen [P79] [P80] [P81] [P82] [P83] 

Bestellung ablehnen [P84] [P85] [P86] [P87] [P88] 

Bestellung editieren [P89] [P90] 

Bestellung zu Sammelbestellung gruppieren [P91] [P92] 

Bestellung aus Sammelbestellung entfernen [P93] [P94] 

Bestellung zu Sammelbestellung hinzufügen [P95] [P96] 

Sammelbestellung genehmigen [P97] [P98] [P99] [P100] 

Sammelbestellung ablehnen [P101] [P102] 

Tabelle 15: Anwendungsfälle - Rollen Bestellprozess 



Bestellung 

editieren 

Bestellung zu 


hinzufügen 

Löschzug 


Bestellung aus 


entfernen 

Bestellung ablehnen 

Kleiderkammer 


Bestellung zu 


gruppieren 

Abbildung 23: Anwendungsfalldiagramm Bestellprozess 



genehmigen 

Wehrführer 

Wehrführer 


ablehnen 

Leiter der Ausstattung 

25


Erfolgt eine Genehmigung, so wird diese Freigabe mit Datum [P103] und Verweis auf das 

entsprechende Mitglied [P104] erfasst. Zudem werden alle Mitglieder, die die Bestellung 

aufgrund ihrer Rolle weiter bearbeiten können, per E-Mail benachrichtigt [P105]. Der 

Ansprechpartner der Bestellung wird ebenfalls via E-Mail über den Fortschritt informiert 

[P106]. 

Im Falle einer Ablehnung wird dies mit Begründung [P107], Datum [P108] und 

ausführendem Mitglied [P109] hinterlegt. Desweiteren erhält der Ansprechpartner der 

Bestellung eine E-Mail mit Begründung der Ablehnung [P110]. 

Am Ende des Bestellprozesses besitzt die Rolle 'Übermittler an Stadt' die Möglichkeit, 

Bestellungen [P111] sowie Sammelbestellungen [P112] in Papierform zu bringen. 

Bestellung 

ausdrucken 

Abbildung 24: Anwendungsfalldiagramm 'Übermittler an Stadt' 

3.1.3 Benutzeroberfläche 

Um die Übersichtlichkeit und somit den Bedienungskomfort zu erhöhen, werden für die 

späteren Nutzergruppen separate Benutzeroberflächen [P113] erstellt. Oberflächen und 

Rollen, für die sie bestimmt sind, werden nachfolgend aufgeführt. 

Benutzeroberfläche Rollen 

Löschzug 

Kleiderkammer 


Löschzug Mitglieder anzeigen 

Löschzug Mitglieder verwalten 




Leiter Ausstattung Leiter Ausstattung 

Wehrführer Wehrführer 

Administration Administration 

Tabelle 16: Benutzeroberflächen 



ausdrucken 




26


Bei den Benutzeroberflächen, die für mehrere Rollen bestimmt sind, werden jeweils nur 

die Bedienelemente angezeigt, die entsprechend der jeweiligen Rolle genutzt werden 

können [P114]. 

4 ENTWURF 

In der Entwurfsphase erfolgt die Entscheidung, welche Architektur und Technologien für 

die anschließende Implementierung verwendet werden sollen. 

4.1 Architektur 

Die Freiwillige Feuerwehr Leichlingen besitzt mit ihren vier Löschzügen eine geografisch 

dezentrale Struktur. Um dieser Struktur auch in der Abwicklung von Geschäftsprozessen 

gerecht zu werden, bietet sich die Client-/Serverarchitektur an. Sie ermöglicht es, 

Anwendung und Daten an einem zentralen Ort, dem Server, zu konzentrieren was die 

Konsistenz der Daten gewährleistet. Gleichzeitig kann die Anwendung von mehreren 

Clients aus unabhängig vom räumlichen Standort genutzt werden. 

4.2 Server 

Wichtige Kriterien für einen stabilen und sicheren Betrieb der späteren Anwendung ist die 

Auswahl einer zuverlässigen Servertechnologie. Sie bildet zugleich die Basis für die 

spätere Entwicklung und muss daher auch unter Berücksichtigung dieses Aspekts 

sorgsam ausgewählt werden. 

Java bietet auf diesem Gebiet mit seiner Spezifikation der Enterprise Edition (EE) ein 

umfangreiches Framework für dieses Aufgabengebiet. Es bietet Unterstützung für nahezu 

alle Technologien, die bei der Entwicklung von modernen, unternehmensweiten 

Anwendungen gebraucht werden. Dazu gehören neben einem Webserver mit 

entsprechenden Frontend Techniken, Persistenz-, Transaktions- und 

Authentifizierungsmechanismen. Zudem werden zahlreiche weitere Dienste wie z.B. Web 

Services, Mail und Namensdienste angeboten. Die Java EE ist leicht erweiterbar und hat 

sich in der Praxis bewährt, weshalb sie verbreitet eingesetzt wird (vgl. 

jcp.org/en/jsr/detail?id=244). 

Java als zugrunde liegende Programmiersprache gewährleistet darüber hinaus durch sein 

Konzept der virtuellen Maschine eine hohe Sicherheit und Stabilität beim späteren 

Betrieb. Prozesse und Objekte der realen Welt lassen sich Dank der gleichzeitigen 

27


Objektorientiertheit leicht im Programmcode nachbilden. 

Ausgehend von der Analyse hat sich ergeben, dass nur einige Teilfunktionen einer Java 

EE benötigt werden. Daher wird statt einer vollständigen Java EE ein e, modulares 

System verwendet deren Kern der Webserver bildet. Alle Funktionen, die zusätzlich 

benötigt werden, können dabei leicht hinzugefügt werden. 

Für dieses Vorgehen wurde der Java EE konforme Webserver Tomcat ausgewählt. Er ist 

ein vielfach eingesetzter Server und wird daher von vielen Projekten und 

Entwicklungstools unterstützt. Seine Konformität garantiert zudem, das entwickelte 

Anwendungen auf allen Java EE konformen Servern betrieben werden können (vgl. 

tomcat.apache.org). 

4.3 Persistenz 

Ein Vielzahl von Daten, die beim Betrieb der Anwendung entstehen, müssen persistent 

abgespeichert werden. Für diese Aufgabe wird eine Datenbank eingesetzt. 

Datenbanken stellen die Integrität der erfassten Daten sicher und bieten die Möglichkeit 

einer gezielten Suche. Zudem sind sie in der Lage, eine Vielzahl gleichzeitiger Zugriffe zu 

gestatten und garantieren mit ihren Mechanismen, wie Transaktionen und Sperren, die 

Konsistenz der Daten. 

Als Datenbank wurde die Oracle 10g Express ausgewählt. Sie ist eine kostenfreie, 

relationale Datenbank von einem der führenden Hersteller und besitzt einen erweiterten 

Funktionsumfang zu dem u.a. ein eigenes Web-Interface gehört. Für die Entwicklung 

stehen darüber hinaus viele weitere Datenbanktools bereit (vgl. 

www.oracle.com/technology/products/database/xe/). 

Daten werden in der Programmiersprache Java durch Objekte repräsentiert. Um sie in 

einer relationalen Datenbank ablegen zu können, müssen sie daher konvertiert werden. 

Diese Aufgabe können objektrelationale Mapper (OR-Mapper) übernehmen. 

OR-Mapper erlauben es durch Konfiguration festzulegen, wie Objekte in einer Datenbank 

abgelegt werden. Dazu wird definiert, in welcher Tabelle Objekte einer Klasse abgelegt 

werden bzw. in welche Spalten die entsprechenden Objekt-Attribute. Sollen Objekte in der 

Datenbank gespeichert werden, übergibt man sie dem Mapper. Dieser sorgt eigenständig 

für die richtige Umsetzung entsprechend der Konfiguration. Umgekehrt wandelt der 

Mapper beim Lesen aus der Datenbank die Daten wieder zurück in ein Objekt. 

Für das OR-Mapping wird das Framework Hibernate eingesetzt. Es ist ein verbreitet 

28


eingesetztes Framework, das kontinuierlich weiterentwickelt wird (vgl. hibernate.org). 

Hibernate lässt sich durch entsprechende Konfiguration mit allen gängigen Datenbank 

nutzen. Die Datenbankanbindung (Connection) verwaltet Hibernate dabei für die gesamte 

Anwendung eigenständig. Soll ein Datenbankzugriff erfolgen, so wird dafür das Hibernate 

Session-Konzept genutzt. Sessions können an beliebiger Stelle gestartet werden und 

ermöglichen das Ablegen und Auslesen von Objekten in der Datenbank (siehe oben). 

Diese Zugriffe können desweiteren mittels Transaktionen isoliert und atomar erfolgen. 

4.4 Model-View-Controller (MVC) 

Ziel bei der Realisierung moderner, grafischer Anwendung ist die Umsetzung des Model- 

View-Controller Paradigmas. Unter dem Modell versteht man dabei die Daten, die z.B. 

persistent abgelegt werden. View repräsentiert die grafische Benutzerschnittstelle und der 

Controller ist für die Verknüpfung von beiden zuständig. Dies klare Trennung erlaubt es, 

Änderungen an einer der drei Ebenen vorzunehmen, ohne die anderen modifizieren zu 

müssen. Wird z.B. die View verändert, hat dies keine Auswirkungen auf das Modell oder 

den Controller. Für die Umsetzung von MVC wird JavaServer Faces verwendet (vgl. 

www.jcp.org/en/jsr/detail?id=127). 

JavaServer Faces sind Teil der Java EE Spezifikation und speziell für die Realisierung 

von MVC bei Web-Applikationen konzipiert. Sie ermöglichen es, die View, d.h. 

Internetseiten, zu erstellen, ohne HTML zu benutzen. Dies wird durch Einführen einer 

Abstraktionsebene erreicht, in der statt HTML- 'JavaServer Faces'-Komponenten 

verwendet werden. Erst zur Laufzeit werden diese Komponenten von einem Renderer in 

HTML umgewandelt. Somit ist es möglich, das Aussehen von Seiten dynamisch 

anzupassen. Erfolgt der Aufruf einer Internetseite, z.B. über ein Smartphone, erscheint sie 

anders als bei einem PC (Haiges/May 2004, java.sun.com/javaee/). 

Innerhalb dieser Abstraktionsebene ist es möglich, auf spezielle Java-Objekte, die 

ManagedBeans, zuzugreifen. ManagedBeans entsprechen dem Controller und sind 

gewöhnliche JavaBeans, die durch Eintrag in einer Konfigurationsdatei von JavaServer 

Faces instanziiert werden können. Somit ist es letztlich möglich, diesen Mechanismus für 

den Zugriff auf beliebige Objekte zu nutzen. Aus diesem Grund werden einfache Java- 

Objekte für das Modell verwendet. 

JavaServer Faces bieten zudem viele weitere Funktionen, wie z.B. die Seitennavigation in 

einer Konfigurationsdatei zu bündeln, statt fest in jeder Seite zu hinterlegen. Auch die 

Validierung von Eingaben und das Generieren von Fehlermeldungen werden unterstützt. 

29


Um diese Technologie nutzen zu können, wird MyFaces, das eine Implementierung der 

JavaServer Faces Spezifikation darstellt, verwendet (vgl. myfaces.apache.org). 

Die Komponenten der JavaServer Faces entsprechen den von HTML (Tabellen, Buttons, 

etc.). Trinidad (vorher Oracle ADF Faces) erweitert diesen Komponentenumfang um über 

hundert weitere, z.B. für Farb- und Datumsauswahl. Daher wird auch Trinidad mit 

eingebunden 

(vgl. www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf). 

4.5 Portable Document Format (PDF) 

Um Daten der Anwendung, wie z.B. Bestellungen, in eine druckbare Form zu bekommen, 

werden aus ihnen PDF-Dokumente erstellt. 

PDF-Dokumente eignen sich hierfür besonders gut, da sie ein einheitliches Aussehen, 

unabhängig vom verwendeten Betrachtungsprogramm, garantieren. Dank der weiten 

Verbreitung des PDF-Formats ist somit auch das Ausdrucken unter verschiedenen 

Betriebssystemen problemlos möglich. 

Für die Umwandlung von Java-Objekten in PDF-Dokumente wird der Formatting Objects 

Processor (FOP) verwendet. FOP ermöglicht es, 'Extensible Stylesheet Language – 

Formatting Objects' (XSL-FO) in verschiedene, unabhängige Ausgabeformate zu 

konvertieren u.a. PDF, PS, SVG, und TXT (vgl. xmlgraphics.apache.org/fop). 

XSL-FO-Objekte werden dabei mit Hilfe der 'XML Stylesheet Language for 

Transformations' (XSLT) aus 'Extensible Markup Language' (XML) Dokumenten generiert. 

Diese Aufgabe übernimmt die 'Java API for XML Processing' (JAXP). 

Die notwendige Konvertierung von Java-Objekten in XML-Dokumente wird wiederum über 

die 'Simple API for XML' (SAX) erreicht. 

SAX XSLT 

FOP 

Java XML XSL-FO PDF 

JAXP 

Abbildung 25: Generierung eines PDF-Dokuments 

30


4.6 E-Mail 

Java stellt für den Versand von E-Mails die JavaMail API bereit. Ihre direkte Nutzung ist 

jedoch nicht sehr komfortabel. Daher wird für den Zugriff auf die JavaMail API Commons- 

Email verwendet. 

Commons-Email stellt eine komfortablere Schnittstelle bereit und hilft so den 

Programmcode zu reduzieren. Dies verringert die Entwicklungszeit und erhöht die 

Lesbarkeit des Codes. 

(vgl. java.sun.com/products/javamail, jakarta.apache.org/commons/email) 

4.7 Logging 

Das Protokollieren von Log-Meldungen ist eine wichtige Voraussetzung um Fehler, die im 

späteren Betrieb auftreten können, nachzuvollziehen. Zur Realisierung des Loggings gibt 

es für Java viele Bibliotheken, wobei alle einen vergleichbaren Funktionsumfang anbieten. 

Um sich nicht fest an eine Bibliothek zu binden, wird daher Commons-Logging verwendet 

(vgl. jakarta.apache.org/commons/logging). 

Commons-Logging erlaubt es, durch Änderung der Konfiguration, die verwendete Logging 

Bibliothek auszutauschen, ohne den Programmcode modifizieren zu müssen. Dies wird 

dadurch erreicht, dass Commons-Logging dem Nutzer eine feste Schnittstelle anbietet 

und selbst nur für die Umsetzung dieser auf die Logging Bibliothek entsprechend der 

Konfiguration sorgt. 

31


4.8 Übersicht 

Die nachfolgende Grafik illustriert die ausgewählten Technologien in Bezug auf ihre 

Einordnung in die Architektur. 

5 IMPLEMENTIERUNG 

In der Implementierungsphase werden die in der Analyse festgelegten Funktionen mit 

denen im Entwurf ausgewählten Techniken umgesetzt. Nachfolgend werden einige 

Strategien und spezielle Techniken erläutert, die dabei verwendet wurden. 

5.1 Webprogrammierung 

Client/Server Web-Anwendungen unterscheiden sich in der Programmierung grundlegend 

von herkömmlichen Anwendungen. Web-Anwendungen werden für die Verarbeitung von 

vielen, gleichzeitigen Anfragen ausgelegt. Dabei erfolgt die gesamte Verarbeitung, 

inklusive der Generierung der grafischen Benutzerschnittstelle für den Client, auf dem 

Server. 

Client 

Server 

Datenbank 

Browser 

Tomcat 

Oracle 10g 

Express 

JavaServer Faces 

Hibernate 

Clients nutzen zumeist einen Web-Browser um Requests (Anfragen) an den Server zu 

senden bzw. die entsprechende Response (Antworte) darzustellen. Die Kommunikation 

zwischen Client und Server erfolgt dabei in der Regel über das HTTP-Protokoll. 

32


HTTP ist ein statusloses Protokoll, d.h. jeder Request wird separat behandelt. Es gibt 

keine Informationen über vorherige oder nachfolgende. Somit ist es dem Server nicht 

möglich, Anfragen zuzuordnen, weshalb alle gleich behandelt werden. Heute übliche 

Funktionen, wie z.B. ein virtueller Warenkorb, lassen sich so nicht realisieren. 

Aus diesem Grund wurde das Konzept der Session 5 entworfen. Sendet ein Benutzer 

einen ersten Request an den Server, so startet dieser eine Session für ihn. Diese Session 

bleibt über die Request-Verarbeitung hinaus auf dem Server bestehen. Erst durch 

explizites Beenden durch den Benutzer oder Ablauf eines Timeouts wird die Session vom 

Server verworfen. 

Um dem Benutzer bei weiteren Requests seine Session zuordnen zu können, sendet der 

Server ein Cookie an den Client Browser. Dieses kann er bei nachfolgenden Requests 

wieder auslesen. Sollte der Browser keine Cookies akzeptieren, kann als Alternative URL- 

Rewriting betrieben werden (Hall/Brown 2004). 

Daten können somit individuell für jeden Benutzer über mehrere Requests an eine 

Session auf dem Server gebunden werden. Abhängig von den Nutzerzahlen und 

Datenmengen einer Session stellt dies jedoch eine große Belastung für den Server dar. 

Richtlinie für die Implementierung ist daher, die Verarbeitung wenn möglich innerhalb 

eines Request vorzunehmen. Daten werden nur an die Session gebunden, wenn 

unbedingt erforderlich. 

Die Bearbeitung innerhalb eines Request führt u.a. zu vermehrten Datenbankzugriffen. 

Eine Performance-Verbesserung kann an dieser Stelle durch den Einsatz des Hibernate 

Level Zwei Caches erreicht werden. 

5.2 Hibernate und JavaServer Faces 

Um Objekte mittels Hibernate aus einer Datenbank zu lesen, werden entsprechende 

Anfragen innerhalb einer Hibernate Session durchgeführt. Sessions werden entsprechend 

der Vorgabe, alle Anfragen innerhalb eines Request zu bearbeiten, für jede Anfrage neu 

erzeugt (session-per-request) (Bauer/King 2005). 

Die angeforderten Objekte werden anschließend mit ihren zugehörigen Attributen zurück- 

gegeben. Besitzen die angeforderten Objekte Collections oder Verweise auf andere 

Objekte in der Datenbank, so werden diese jedoch noch nicht mitgeladen. Erst bei einem 

Zugriff auf sie erkennt Hibernate ihr Fehlen und lädt sie eigenständig nach. Dieses 

5 Der hier verwendete Begriffe der Session hat keinen Bezug zu den Hibernate Session Konzept 

aus Kapitel 4.3 Seite 28. 

33


Verhalten wird als Lazy Load bezeichnet und ist nur möglich, solange die ursprüngliche 

Session noch geöffnet ist (Beeger/Haase,/Roock/Sanitz 2006). 

Erfolgt ein Request auf eine JavaServer Faces Seite, so werden die entsprechenden 

ManagedBeans instanziiert und die gewünschten Attribute für die spätere HTML 

-Generierung ausgelesen. 

Möchte man über JavaFaces direkt auf Objekte zugreifen, die von Hibernate geladen 

werden, ergibt sich ein Problem. Wird die entsprechende Hibernate Session zu früh 

geschlossen, funktioniert der Lazy Load Mechanismus nicht mehr. 

Um dies zu verhindern wird der Web-Server so konfiguriert, dass er nach Abarbeitung 

jedes Requests automatisch die entsprechenden Hibernate Sessions schließt. Dies 

erlaubt es, Sessions an beliebiger Stelle zu öffnen und das Schließen dem Server zu 

überlassen. Somit ist die Kombination aus Hibernate und JavaServer Faces problemlos 

möglich (Müller 2006). 

34


6 SCHLUSSBETRACHTUNG 

Diese Arbeite ermöglichte es mir, die aus dem Studium bekannten Phasen des 

Softwareentwicklungsprozesses unter sehr realistischen Bedingungen eigenständig zu 

durchlaufen. Dank weitgehender Freiheiten und Eigenverantwortlichkeit für die gesamte 

Arbeit konnte ich dabei sehr viel wertvolle Praxiserfahrung sammeln. Die Betreuung durch 

ein IT-Consulting Unternehmen garantierte dabei das professionelle Vorgehen und die 

Verwendung moderner Technologien. 

Ich hatte die Möglichkeit, die Problemstellung selbstständig in Gesprächen mit dem 

Kunden zu erfassen und darauf aufbauend, eigenständig die Analyse durchzuführen. 

Die Analyse erforderte eine Vielzahl von weitreichenden Überlegungen, um die spätere 

Skalierbarkeit zu gewährleisten. Gleichzeitig wurde dabei die technische Realisierbarkeit 

nicht außer acht gelassen. 

Aufgrund der guten, im Studium erworbenen Grundkenntnisse über Betriebssysteme, 

verteilte Systeme, Netzwerke, Protokolle, Objektorientierung und Java war ich in der 

Lage, mich schnell in neue Technologien einzuarbeiten und deren Nutzen zu erkennen. 

Die verwendeten Technologien ermöglichten es mir daher, eine moderne, skalierbare und 

durchgehend objektorientierte Softwarearchitektur zu entwerfen. Der gesamte 

Entwicklungsprozess konnte Dank des in die Entwicklungsumgebung integriertem UML- 

Plugin durchgehend mit UML Unterstützung erfolgen. 

Bedingt durch den zeitlich eng begrenzten Rahmen schließt diese Arbeit mit der 

Implementierung ab. Der Entwicklungsprozess, der sich gerade in der Validerung befindet 

wird jedoch weitergeführt, so dass nach erfolgreicher Validerungs- und Test-Phase die 

Anwendung in Betrieb genommen werden kann. Auch für später mögliche Erweiterungen 

ist die Anwendung durch ihren skalierbaren Entwurf und die verwendeten Techniken gut 

gerüstet. 

35


7 QUELLEN 

Beeger, Robert F. / Haase, Arno / Roock, Stefan / Sanitz, Sebastian (2006): Hibernate – 

Persistenz in Java-Systemen mit Hilbernte 3, dpunkt.verlag GmbH, Heidelberg. 

Bauer, Christian / King, Gavin (2005): Hibernate in Action, Manning Publications Co., 

Greenwich. 

Haiges, Sven / May, Marcel (2004): JavaServer Faces – Web Development mit dem 

Standard-Framework, Software & Support Verlag GmbH, Frankfurt. 

Hall, Marty / Brown, Larry (2004): core Servlets und JavaServer Pages, Markt + Technik 

Verlag, München. 

Müller, Bernd (2006) Kombination von JSF und Hibernate mit dem „Open Session in 

View“ Pattern. In: Javamagazin 7/06, Seite 70-72. 

INTERNET-QUELLEN 

ADF Faces / Trinidad 

http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/i 

ndex.html#Documentation (10.10.2006) 

AMEfire 

http://www.amefire.de (10.10.2006) 

Commons-Email 

http://jakarta.apache.org/commons/email/ (10.10.2006) 

Commons-Logging 

http://jakarta.apache.org/commons/logging/ (10.10.2006) 

Eclipse Web Tools Platform 

http://www.eclipse.org/webtools/ (10.10.2006) 

Formatting Objects Processor 

http://xmlgraphics.apache.org/fop/ (10.10.2006) 

http://xmlgraphics.apache.org/fop/0.92/embedding.html (10.10.2006) 

36


Hibernate 

http://www.hibernate.org/ (10.10.2006) 

Java EE 5 Tutorial 

http://java.sun.com/javaee/reference/tutorials/index.jsp (10.10.2006) 

JavaMail API 

http://java.sun.com/products/javamail/ (10.10.2006) 

JavaServer Faces Specification 

http://www.jcp.org/en/jsr/detail?id=127 (10.10.2006) 

JavaTM Platform, Enterprise Edition 5 (Java EE 5) Specification 

http://jcp.org/en/jsr/detail?id=244 (10.10.2006) 

MyFaces 

http://myfaces.apache.org (10.10.2006) 

Omondo EclipseUML Plugin 

www.omondo.com (10.10.2006) 

Oracle Database 10g Express Edition 

http://www.oracle.com/technology/products/database/xe/index.html (10.10.2006) 

Tomcat 

http://tomcat.apache.org (10.10.2006) 

37


8 ANHANG 

Im Anhang wird der Quelltext der Anwendung nicht aufgeführt, da er rund 24.600 Zeilen 

umfasst (Java: 11.562, XML: 5.726, JSP: 7.335). Stattdessen wird im Folgendem der 

Aufbau anhand von Klassendiagramme dargestellt. Die gesamte Anwendung inklusive 

Quelltext ist auf einer CD-ROM beigelegt. 

38



39


Abbildung 27: Klassendiagramm Löschzug 


40


Abbildung 29: Klassendiagramm Artikel 

Abbildung 30: Klassendiagramm ManagedBeans Mitglied 

41


Abbildung 31: Klassendiagramm ManagedBeans Bestellung 

Abbildung 32: Klassendiagramm ManagedBeans Lieferant 

42


Abbildung 33: Klassendiagramm ManagedBeans Artikel 

Abbildung 34: Klassendiagramm PDF Bestellung 

43


9 SELBSTSTÄNDIGKEISTERKLÄRUNG 

Hiermit versichere ich, dass ich diese Arbeit selbstständig angefertigt habe und außer den 

im Quellen- und Literaturverzeichnis, sowie in den Anmerkungen genannten Hilfsmitteln 

keine weiteren benutzt habe. Alle Stellen der Arbeit, die anderen Werken dem Wortlaut 

oder dem Sinn nach entnommen sind, habe ich unter Angabe der Quellen als Entlehnung 

kenntlich gemacht. 

________________________ 

Unterschirft 

44

Konzeption und Realisierung einer skalierbaren ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?