Konzeption und Entwicklung einer datenbankgestützten Intranetanwendung zur Dynamisierung der Newsbereiche der Internetauftritte der FH Bochum

Inhaltsverzeichnis

Abbildungsverzeichnis

Abkurzungsverzeichnis

1. Einleitung
1.1. Problemstellung
1.2. Ziele der Diplomarbeit
1.3. Aufbau der Diplomarbeit

2. Analyse des Geschaftsprozesses

3. Software-Modellierung
3.1. United Modelling Language
3.2. UML-Diagramme
3.3. Anwendungsfall
3.4. Beziehungen zwischen Anwendungsfallen
3.4.1. include-Beziehungen
3.4.2. extend-Beziehungen
3.4.3. Generalisierungsbeziehung
3.6. Anwendungsfalldiagramm „Veranstaltungskalender“
3.7. schriftliche Erlauterung der Anwendungsfalle
3.7.1. Use Case “Login”
3.7.2. Use Case „Gesamtliste abfragen"
3.7.4. Use Case „Datensatze anzeigen lassen“
3.7.5. Use Case „einzelnen Datensatz bearbeiten"
3.7.6. Use Case „Einzelnen Datensatz loschen"

4. Datenbank - Modellierung
4.1. ERM
4.2. Beziehungen
4.3. Dantenbankmodell „Veranstaltungskalender“

5. Programmierung
5.1. Die Programmiersprache
5.1.1. Entstehung und Darstellung einer Klasse
5.1.2. Methoden
5.1.2.1. Objektmethoden
5.1.2.2. Klassenmethoden
5.1.3. Dokumentation des Quellcodes
5.2. Erlauterung des Formulars zur Dateneingabe
5.3. Formular zur Datenanderung

6. Fazit

Literaturverzeichnis

Abbildungsverzeichnis

Abbildung 1: Diagrammarten der UML-Spezifikation (Version 1.3)

Abbildung 2: include Beziehung

Abbildung 3: extend-Beziehung

Abbildung 4: Use-Case-Diagramm mit einer extend Beziehung

Abbildung 5: Beispiel fur die Generalisierungsbeziehung zwischen Anwendungsfallen

Abbildung 6: Anwendungsfalldiagramm "Veranstaltungskalender"

Abbildung 7: Elemente des ERM

Abbildung 8: Beziehungen im ERM

Abbildung 9: 1:1 Beziehung

Abbildung 10: 1:N Beziehung

Abbildung 11: N:M-Beziehung

Abbildung 12: ERM N:M-Beziehung zwischen Event und OrganisationUnit 26 Abbildung 13: ERM N:M-Beziehung zwischen Event und Category

Abbildung 14: Darstellung von PHP Scripten im Browser

Abbildung 15: Screenshot „Eingabeformular fur neue Datensatze"

Abbildung 16: Screenshot „Veranstaltungsliste“

Abbildung 17: Screenshot "Datensatz bearbeiten oder loschen"

Abbildung 18: Screenshot "Veranstaltungen bearbeiten" Teil 1

Abbildung 19: Screenshot "Veranstaltungen bearbeiten" Teil 2

Abkurzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1. Einleitung

1.1. Problemstellung

Das Internet wird in heutiger Zeit immer mehr ein wichtiger Bestandteil jeder Einrichtung. Somit verfugt auch die Fachhochschule Bochum uber eine sehr breit gefacherte Internetseite. Mit dieser Internetseite sollen die Professoren und Studenten uber samtliche Veranstaltungen und Aktivitaten an der Fach­hochschule Bochum informiert werden. Dafur existieren fur alle Fachbereiche diverse Veranstaltungskalender. Fur die Aktualisierung dieser Veranstal- tungskalender mussen die Verantwortlichen bisher immer im Sourcecode die aktuellen Termine eintragen. Somit mussten HTML-Kenntnisse vorausge- setzt werden. Des weiteren sind noch die meisten Internetseiten der Fach­hochschule Bochum statisch. Da seit Fruhjahr 2000 der Fachbereich Wirt- schaft ein dynamisches Informationssystem, speziell fur den Fachbereich Wirtschaft, entwickelt und einfuhrt, lag es nahe, im Rahmen meiner Diplom- arbeit, ein dynamisches System fur die Veranstaltungskalender zu entwi- ckeln.

1.2. Ziele der Diplomarbeit

Ziel dieser Diplomarbeit ist:

1. Umstellung der Veranstaltungskalender von statisch auf dynamisch
2. Anpassung an das dynamische Informationssystem
3. Erleichterung fur die Pflege der Veranstaltungskalender sowie leichte- re Bedienung fur die Anwender durch einen geschutzten Administrati- onsbereich
4. Allgemeiner, fur alle Fachbereiche geltender Administrationsbereich, trotz verschiedener Themen in den Fachbereichen.
5. Die Programmierungen objektorientiert durchzufuhren
6. Implementierung mit Hilfe von Open-Source-Software (PHP und MySQL). Somit fallen keine Kosten an
7. Das neue Programm luckenlos in das schon bestehende Informati- onssystem / Intranet / Internet unter Berucksichtung aller Codier- und Dokumentationsvorschriften einfugen

Fur die Realisierung dieses Projektes wird eine Datenbank benotigt, die alle Informationen fur einen solchen Veranstaltungskalender speichert. Von die- ser Datenbank aus, konnen dann die Daten weiterverwendet, bearbeitet und geloscht werden. Mit Hilfe der Datenbank und der oben aufgefuhrten Soft­ware konnen auch die Daten fur die AuGendarstellung der jeweiligen Fachbe- reiche genutzt werden. Somit kann jeder Fachbereich gezielt seinem Publi- kum die aktuellsten Veranstaltungen online prasentieren und zu jeder Zeit ohne groGen Aufwand uber einen Administrationsbereich mit Hilfe von Ein- gabemasken die Veranstaltungen bearbeiten, loschen oder neue Veranstal- tungen hinzufugen.

1.3. Aufbau der Diplomarbeit

In Kapitel Eins erfolgt eine kurze Einfuhrung in die Problematik sowie Auflis- tung und Erlauterung der Ziele dieser Diplomarbeit. Das Kapitel Zwei be- schaftigt sich mit der Analyse des Geschaftsprozesses und in Kapitel Drei wird auf die Software-Modellierung eingegangen. Nach der Datenbank- Modellierung in Kapitel Vier wird in Kapitel Funf die Programmierung der An- wendungen erlautert. Das Schlusswort in Kapitel Sechs rundet anschlieGend diese Diplomarbeit ab.

2. Analyse des Geschaftsprozesses

Zur Analyse des Projektes wurden Dipl.-Ing. Manfred Krane von der Abtei- lung KIT und Prof. Dr. Blumel aus dem Fachbereich Wirtschaft mit einbezo- gen. Bei den Besprechungen haben wir festgelegt, welche einzelnen Felder fur die Eingabemasken im Administrationsbereich benotigt werden. Da die Veranstaltungskalender der verschiedenen Fachbereiche alle die gleichen Informationen benotigen, konnten wir uns schnell auf eine Einheitsmaske einigen.

Somit sind folgende Punkte festgehalten worden:

- Organisationseinheit
- Veranstaltungsart
- Bild
- Titel der Veranstaltung
- Datum Beginn
- Datum Ende
- Uhrzeit Beginn
- Uhrzeit Ende
- Ort
- URL des Ortes
- Raum
- URL des Raumes
- Inhalt
- URL der Veranstaltung
- Anmeldungs-URL fur die Veranstaltung

Daraufhin wird ein gemeinsamer Administrationsbereich erstellt, der nach der Einfuhrung von allen Fachbereichen genutzt werden kann. Unterschieden werden die eingegebenen Veranstaltungen durch die Angabe des Fachbe- reiches.

3. Software-Modellierung

3.1. United Modelling Language

UML ist eine Modellierungssprache zum Spezifizieren, Konstruieren, Visuali- sieren und Dokumentieren von Softwaresystemen sowie Geschaftsprozes- sen. Diese Software-Modellierungssprache wird in graphischen Elementen ausgedruckt, die in verschiedenen Diagrammtypen verwendet werden. „Die dabei entstehenden graphischen Reprasentationen beschreiben auf einer vorgegebenen Abstraktionsebene einen bestimmten Aspekt des Problembe- reichs oder des zu realisierenden Systems, wie z.B. die involvierten Objekte und ihre Beziehungen, die Interaktionen zwischen den Objekten und die Ver- teilung auf unterschiedliche Rechner."^[1]

UML ist hauptsachlich fur die objektorientierte Softwareentwicklung gedacht. Denn es bietet als Modellierungssprache wesentliche Modellierungskonzepte sowie eine intuitive graphische Reprasentation fur die Konstruktion und Ent- wicklung von objektorientierten Softwaresystemen. Auch wenn die, wie in diesem Projekt, verwendete Programmiersprache PHP nur zu einem gerin- gen Teil die Objektorientierung unterstutzt, ist es sehr sinnvoll, die Modellie­rungssprache UML fur das Projekt einzusetzen. Denn durch die graphische Reprasentation in Use-Case Diagrammen, stoGt man bei der Analyse von Prozessen auf Einzelheiten, die ohne Einsetzung von UML erst viel spater entdeckt wurden. Use-Case-Diagramme sind Anwendungsfalle, die die An- forderungen erfassen und die Funktion der zu entwickelten Software spezifi­zieren. Die Erstellung von Use-Case-Diagrammen erfolgt als graphische so­wie schriftliche Beschreibung. Die graphische Beschreibung eignet sich gut, um Dritten den Ablauf und die Funktion der entwickelten Software verstand- lich darzustellen. Somit konnen Laien in kurzer Zeit uberblicken, wie der Pro- zess der Software ablauft. AuGerdem kann den Softwareanwendern mit Hilfe der graphischen Beschreibung erlautert werden, wie die Software genau programmiert wird.

Die schriftliche Beschreibung ist die ausfuhrlichere Version von Use-Case- Diagrammen. Da die schriftliche Darstellung von Use-Case-Diagrammen zu einem spateren Zeitpunkt in dieser Diplomarbeit ausfuhrlich besprochen wird, gehe ich in diesem Abschnitt nicht weiter darauf ein.

3.2. UML-Diagramme

UML-Diagramme stellen verschiedene Aspekte der antizipierten Anwendung dar und konnen somit helfen, die Ubersicht bei komplexen Systemen zu be- halten. Da jedes UML-Diagramm andere Aspekte der abstrakten Modelle hervorhebt, stellen diese somit auch verschiedene Sichten auf das Daten- modell dar. Daraus folgt, dass abhangig von dem Kontext die Schwerpunkte der gewahlten Diagrammarten unterschiedlich sind.

In der nachfolgenden Grafik findet man eine Ubersicht von den existierenden UML-Diagrammen mit einer kurzen Beschreibung:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Diagrammarten der UML-Spezifikation (Version 1.3)^[2]

In dieser Diplomarbeit werden nur die Use-Case-Diagramme zur Software- entwicklung verwendet. Die Use-Case-Diagramme werden auch in der UML- Sprache als Anwendungsfalldiagramme bezeichnet.

3.3. Anwendungsfall

Use-Cases werden auch Anwendungsfalle genannt. Um sich vorstellen zu konnen, wie ein Anwendungsfall auszusehen hat, wird ein solcher Fall an einem sehr alltaglichen Beispiel erklart.

Fast jeder Mensch besitzt in der heutigen Zeit eine EC Karte. Mit dieser EC Karte konnen mehrere Prozesse vollzogen werden. Zum einen kann man im Geschaft per Lastschriftverfahren^[3] seine Waren bezahlen oder auch durch Eingabe der PIN Nummer, Geld direkt vom Konto abbuchen lassen. Das sind die zwei ublichsten Prozesse bei der Benutzung einer EC Karte im Geschaft. Um jedoch etwas Bargeld zu erhalten, muss man an einem Geldautomaten einen gewunschten Betrag abheben. Dieser Prozess durfte jedem bekannt sein. Man fahrt zum Geldautomaten der eigenen Bank, um die Abhebungs- gebuhren zu sparen. Als nachstes wird die EC Karte in die vorgesehene Vor- richtung des Geldautomaten eingeschoben. Daraufhin fordert der Geldauto- mat den Benutzer auf, seine PIN Nummer anzugeben, um sich zu identifizie- ren. Danach erscheint ein Auswahlmenu. Dort kann dann ausgewahlt werden zwischen

- vorgegebenen Betragen (50 €, 100 €, 150 €, 200 €)
- selbst einen eigenen Betrag eingeben
- oder sogar erst seinen Kontostand anzeigen lassen.

Nachdem man seinen Kontostand anzeigen lieR>, entscheidet sich diese Per­son, ggf. 50 € abzuheben. Somit klickt man auf das Feld 50 € und der Auto­mat beginnt, den Auftrag zu bearbeiten. Am Ende des Geschaftsprozesses bekommt man seine EC Karte wieder zuruck und der Geldbetrag kann ent- nommen werden. Diesen Prozess kennt wohl jeder. Somit hat man seinen ersten Anwendungsfall. Diesen Gesamtprozess kann man als „Geld abholen" bezeichnen. Das komplette Prozedere wird in einzelne Teilprozesse geglie- dert. Genau nach diesem Prinzip werden Anwendungsfalle definiert. Das

Beispiel „Geld abheben" beinhaltet die Teilprozesse, den Kontostand aus- wahlen und die Eingabe der PIN Nummer zur Identifikation. Somit werden die Prozesse, die den Gesamtprozess bilden, in lauter einzelne Teilprozesse zerlegt. Bei der Analyse von Anwendungsfallen konnen naturlich auch Ab- weichungen, so genannte Fehlermeldungen, entstehen,. Diese Fehlermel- dungen sind Vorgange, die nicht fehlerfrei ablaufen. In unserem Beispiel konnte das sein, dass die PIN Nummer nicht richtig eingegeben wurde oder die EC Karte nicht lesbar ist. Um solche fehlerhaften Vorgange zu vermeiden oder vorab zu reduzieren, sollte man sich bei jedem Schritt in einem Anwen- dungsfall fragen: Was tritt ein, wenn dieser Teilschritt nicht fehlerfrei verlauft? Durch welche Alternativen kann der Anwendungsfall dennoch zum Erfolg gebracht werden? Zur Analysierung eines Anwendungsfalls sollte vorab ge- klart werden, wie weit ein solcher Anwendungsfall analysiert werden soll. Fur solche Entscheidungen lasst UML sehr viele Freiheiten.

Die verschiedenen Teilanwendungsfalle eines Anwendungsfalldiagramms konnen graphisch oder textuell dargestellt werden. Diese konnen nicht nur eine Kommunikationsbeziehung zu Akteuren haben, sondern konnen auch untereinander in Beziehung stehen.

3.4. Beziehungen zwischen Anwendungsfallen

Bei den Beziehungen zwischen den Anwendungsfallen unterscheidet man drei verschiedene Beziehungsarten:

- die include-
- die extend-
- und die Generalisierungsbeziehung.

3.4.1. include-Beziehungen

Die include-Beziehung ist eine gerichtete Beziehung zwischen zwei Anwen­dungsfallen. Somit ist der Anwendungsfall B (eingeschlossen) vom Anwen­dungsfall A (einschlieGend) abhangig und das Geschehen im Anwendungs­fall B wird in den Anwendungsfall A eingefugt. Die include-Beziehung dient somit auch zur Redundanzvermeidung. Grafisch wird die include-Beziehung durch einen Abhangigkeitspfeil zwischen den beiden Anwendungsfallen dar- gestellt. Unterhalb des Pfeils wird er mit dem Schlusselwort „include“ be- schriftet.

Abbildung in dieser Leseprobe nicht enthalten

Beispiel:

In dem Administrationsbereich fur die Veranstaltungskalender konnen Be- rechtigte neue Datensatze einfugen, andern oder loschen. Wird in dem An- wendungsfall ein neuer Datensatz eingefugt, so wird automatisch der Veran­staltungskalender mit dem Datensatz aktualisiert. Bei dieser Anwendung handelt es sich um eine include-Beziehung zwischen zwei Anwendungsfal- len. Das heiGt, jedes Mal, wenn „neuen Datensatz einfugen" ausgefuhrt wird, wird auch der Anwendungsfall „Veranstaltungskalender aktualisieren" ausge­fuhrt.

3.4.2. extend-Beziehungen

Die extend-Beziehungen sind genauso wie die include-Beziehungen, gerich- tete Beziehungen zwischen zwei Anwendungsfallen. Bei einer extend- Beziehung von Anwendungsfall B nach Anwendungsfall A kann das Verhal- ten von B in A eingefugt werden. Sie ermoglicht, Erweiterungen von Anwen­dungsfallen darzustellen, die von bestimmten Bedingungen abhangen. Es handelt sich um optionale Erweiterungen. Grafisch wird diese Beziehung wie bei der include Beziehung mit einem Abhangigkeitspfeil dargestellt, der mit der Notation „extend“ beschriftet ist. Die Bedingung wird unter einer waage- rechten Linie unter der Erweiterung notiert.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: extend-Beziehung

Beispiel:

Da es bei dem Projekt in meiner Diplomarbeit keine extend-Beziehung gibt, betrachten wir ein anderes Beispiel. Wir mochten ein Hotelzimmer buchen. Der Portier pruft uber das Computersystem, ob noch ein Zimmer frei ist. Merkt er aber, dass das Zimmer jedoch noch nicht gesaubert wurde, kommt somit eine extend-Beziehung in Betracht, da der Portier nunmehr einen Zu- satzauftrag an die Putzkolonne geben muss. Grafisch wird das folgenderma- R>en ausgedruckt:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Use-Case-Diagramm mit einer extend Beziehung

3.4.3. Generalisierungsbeziehung

Die dritte Beziehungsart zwischen Anwendungsfallen ist die Generalisierung. Sie modelliert die Vererbungsstruktur eines Systems und kann sowohl bei Akteuren als auch bei Anwendungsfallen eingesetzt werden. Somit erlaubt die Generalisierung abstrakte Funktionsbeschreibungen und spezielle Reali- sierungen. Ist die definierte Grenze eines Anwendungfalles erreicht, so wird der Anwendungsfall durch eine Generalisierung von einem anderen Anwen- dungsfall uberschrieben, wobei er das uberschriebene Verhalten verandern und erganzen kann. Grafisch wird die Generalisierung durch einen Pfeil mit einem nicht ausgefullten gleichseitigen Dreieck als Spitze dargestellt, der mit der Notation „Generalisierung" beschrift ist. Dieser Pfeil fuhrt von dem spe- zielleren zum generischeren Konstrukt.

Generalisierungsbeziehungen konnen nicht nur zwischen Anwendungsfallen, sondern auch zwischen Klassen und Paketen auftreten.

Beispiel:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Beispiel fur die Generalisierungsbeziehung zwischen Anwendungsfallen

Der Anwendungsfall A ist der Hauptanwendungsfall „Base Use Case". Dieser Anwendungsfall kann separat ausgefuhrt werden. Der Anwendungsfall B ist ein Unterandwendungsfall „Sub Use Case". Dieser benotigt den Anwen­dungsfall A und ubernimmt die Grundfunktionalitat von A. Der Anwendungs­fall B entscheidet bei der Generalisierungsbeziehung, was von A ausgefuhrt beziehungsweise geandert wird.

[...]

^[1] Martin Hitz, Gerti Kappe; UML @ Work Von der Analyse zur Realisierung, 1. Auflage 1999, S.6

^[2] Object Management Group: Unified Modelling Language Specification Version 1.3, Marz 2000

^[3] bei einem Lastschriftverfahren muss auf der Ruckseite des Kassenbons unterschrieben werden und mit der Unterschrift willigt diese Person dem Lastschriftverfahren zu.