Inhaltsverzeichnis I

Inhaltsverzeichnis   

Inhaltsverzeichnis   I

Abbildungsverzeichnis   II

Abk  ürzungsverzeichnis  III

1.  Einleitung  1

1.1.  Problemstellung  1

1.2.  Ziele der Diplomarbeit  1

1.3.  Aufbau der Diplomarbeit  2

2.  Analyse des Geschäftsprozesses  3

3.  Software-Modellierung  4

3.1.  United Modelling Language  4

3.2.  UML-Diagramme  5

3.3.  Anwendungsfall  6

3.4.  Beziehungen zwischen Anwendungsfällen  7

3.4.1.  include-Beziehungen  7

3.4.2.  extend-Beziehungen  8

3.4.3.  Generalisierungsbeziehung  10

3.6.  Anwendungsfalldiagramm „Veranstaltungskalender“  12

3.7.  schriftliche Erläuterung der Anwendungsfälle  13

3.7.1.  Use Case “Login  14

3.7.2.  Use Case „Gesamtliste abfragen“  16

3.7.4.  Use Case „Datensätze anzeigen lassen“  18

3.7.5.  Use Case „einzelnen Datensatz bearbeiten“  19

3.7.6.  Use Case „Einzelnen Datensatz löschen“  20

4.  Datenbank - Modellierung  22

4.1.  ERM  22

4.2.  Beziehungen  23

4.3.  Dantenbankmodell „Veranstaltungskalender“  26

5.  Programmierung  28

5.1.  Die Programmiersprache  28

5.1.1.  Entstehung und Darstellung einer Klasse  29

5.1.2.  Methoden  33

5.1.2.1.  Objektmethoden  33

5.1.2.2.  Klassenmethoden  34

5.1.3.  Dokumentation des Quellcodes  35

5.2.  Erläuterung des Formulars zur Dateneingabe  36

5.3.  Formular zur Datenänderung  38

6.  Fazit  42

Literaturverzeichnis   43

Abbildungsverzeichnis   

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 für die Generalisierungsbeziehung zwischen  

Anwendungsf  ällen  

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:-MBeziehung  

Abbildung  12: ERM N:-MBeziehung zwischen Event und OrganisationUnit  

Abbildung  13: ERM N:-MBeziehung zwischen Event und Category  

Abbildung  14: Darstellung von PHP Scripten im Browser  

Abbildung  15: Screenshot „Eingabeformular für neue Datensätze“  

Abbildung  16: Screenshot „Veranstaltungsliste“  

Abbildung  17: Screenshot "Datensatz bearbeiten oder löschen"  

Abbildung  18: Screenshot "Veranstaltungen bearbeiten" Teil 1  

Abbildung  19: Screenshot "Veranstaltungen bearbeiten" Teil 2  

Abkürzungsverzeichnis

HTML Hypertext Markup Language PHP PHP Hypertext Preprocessor MySQL My Structured Query Language KIT Kommunikation, Innovation, Transfer URL Uniform Resource Locator UML United Modelling Language z.B. zum Beispiel PIN persönliche Identifikationsnummer EC Euro Check Ggf. gegebenenfalls ERM Entity-Relationship-Modell Vgl. vergleiche

Das Internet wird in heutiger Zeit immer mehr ein wichtiger Bestandteil jeder Einrichtung. Somit verfügt auch die Fachhochschule Bochum über eine sehr breit gefächerte Internetseite. Mit dieser Internetseite sollen die Professoren und Studenten über sämtliche Veranstaltungen und Aktivitäten an der Fachhochschule Bochum informiert werden. Dafür existieren für alle Fachbereiche diverse Veranstaltungskalender. Für die Aktualisierung dieser Veranstaltungskalender müssen die Verantwortlichen bisher immer im Sourcecode die aktuellen Termine eintragen. Somit mussten HTML-Kenntnisse vorausgesetzt werden. Des weiteren sind noch die meisten Internetseiten der Fachhochschule Bochum statisch. Da seit Frühjahr 2000 der Fachbereich Wirtschaft ein dynamisches Informationssystem, speziell für den Fachbereich Wirtschaft, entwickelt und einführt, lag es nahe, im Rahmen meiner Diplomarbeit, ein dynamisches System für die Veranstaltungskalender zu entwickeln.

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 für die Pflege der Veranstaltungskalender sowie leichtere Bedienung für die Anwender durch einen geschützten Administrationsbereich

4. Allgemeiner, für alle Fachbereiche geltender Administrationsbereich, trotz verschiedener Themen in den Fachbereichen. 5. Die Programmierungen objektorientiert durchzuführen 6. Implementierung mit Hilfe von Open-Source-Software (PHP und MySQL). Somit fallen keine Kosten an

7. Das neue Programm lückenlos in das schon bestehende Informationssystem / Intranet / Internet unter Berücksichtung aller Codier- und Dokumentationsvorschriften einfügen

Für die Realisierung dieses Projektes wird eine Datenbank benötigt, die alle Informationen für einen solchen Veranstaltungskalender speichert. Von dieser Datenbank aus, können dann die Daten weiterverwendet, bearbeitet und gelöscht werden. Mit Hilfe der Datenbank und der oben aufgeführten Software können auch die Daten für die Außendarstellung der jeweiligen Fachbereiche genutzt werden. Somit kann jeder Fachbereich gezielt seinem Publikum die aktuellsten Veranstaltungen online präsentieren und zu jeder Zeit ohne großen Aufwand über einen Administrationsbereich mit Hilfe von Eingabemasken die Veranstaltungen bearbeiten, löschen oder neue Veranstaltungen hinzufügen.

1.3. Aufbau der Diplomarbeit

In Kapitel Eins erfolgt eine kurze Einführung in die Problematik sowie Auflistung und Erläuterung der Ziele dieser Diplomarbeit. Das Kapitel Zwei beschäftigt sich mit der Analyse des Geschäftsprozesses und in Kapitel Drei wird auf die Software-Modellierung eingegangen. Nach der Datenbank-Modellierung in Kapitel Vier wird in Kapitel Fünf die Programmierung der Anwendungen erläutert. Das Schlusswort in Kapitel Sechs rundet anschließend diese Diplomarbeit ab.

2. Analyse des Geschäftsprozesses

Zur Analyse des Projektes wurden Dipl.-Ing. Manfred Krane von der Abteilung KIT und Prof. Dr. Blümel aus dem Fachbereich Wirtschaft mit einbezogen. Bei den Besprechungen haben wir festgelegt, welche einzelnen Felder für die Eingabemasken im Administrationsbereich benötigt werden. Da die Veranstaltungskalender der verschiedenen Fachbereiche alle die gleichen Informationen benötigen, 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 für die Veranstaltung

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

UML ist eine Modellierungssprache zum Spezifizieren, Konstruieren, Visualisieren und Dokumentieren von Softwaresystemen sowie Geschäftsprozessen. Diese Software-Modellierungssprache wird in graphischen Elementen ausgedrückt, die in verschiedenen Diagrammtypen verwendet werden. „Die dabei entstehenden graphischen Repräsentationen beschreiben auf einer vorgegebenen Abstraktionsebene einen bestimmten Aspekt des Problembereichs oder des zu realisierenden Systems, wie z.B. die involvierten Objekte und ihre Beziehungen, die Interaktionen zwischen den Objekten und die Verteilung auf unterschiedliche Rechner.“ 1

UML ist hauptsächlich für die objektorientierte Softwareentwicklung gedacht. Denn es bietet als Modellierungssprache wesentliche Modellierungskonzepte sowie eine intuitive graphische Repräsentation für die Konstruktion und Entwicklung von objektorientierten Softwaresystemen. Auch wenn die, wie in diesem Projekt, verwendete Programmiersprache PHP nur zu einem geringen Teil die Objektorientierung unterstützt, ist es sehr sinnvoll, die Modellierungssprache UML für das Projekt einzusetzen. Denn durch die graphische Repräsentation in Use-Case Diagrammen, stößt man bei der Analyse von Prozessen auf Einzelheiten, die ohne Einsetzung von UML erst viel später entdeckt würden. Use-Case-Diagramme sind Anwendungsfälle, die die An-forderungen erfassen und die Funktion der zu entwickelten Software spezifizieren. Die Erstellung von Use-Case-Diagrammen erfolgt als graphische sowie schriftliche Beschreibung. Die graphische Beschreibung eignet sich gut, um Dritten den Ablauf und die Funktion der entwickelten Software verständlich darzustellen. Somit können Laien in kurzer Zeit überblicken, wie der Prozess der Software abläuft. Außerdem kann den Softwareanwendern mit Hilfe der graphischen Beschreibung erläutert werden, wie die Software genau programmiert wird.

Die schriftliche Beschreibung ist die ausführlichere Version von Use-Case-Diagrammen. Da die schriftliche Darstellung von Use-Case-Diagrammen zu

¹ Martin Hitz, Gerti Kappe; UML @ Work Von der Analyse zur Realisierung, 1. Auflage 1999,

S.6

einem späteren Zeitpunkt in dieser Diplomarbeit ausführlich 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 können somit helfen, die Übersicht bei komplexen Systemen zu behalten. Da jedes UML-Diagramm andere Aspekte der abstrakten Modelle hervorhebt, stellen diese somit auch verschiedene Sichten auf das Datenmodell dar. Daraus folgt, dass abhängig von dem Kontext die Schwerpunkte der gewählten Diagrammarten unterschiedlich sind.

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

² Object Management Group: Unified Modelling Language Specification Version 1.3, März

2000

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

3.3. Anwendungsfall

Use-Cases werden auch Anwendungsfälle genannt. Um sich vorstellen zu können, wie ein Anwendungsfall auszusehen hat, wird ein solcher Fall an einem sehr alltäglichen Beispiel erklärt.

Fast jeder Mensch besitzt in der heutigen Zeit eine EC Karte. Mit dieser EC Karte können mehrere Prozesse vollzogen werden. Zum einen kann man im Geschäft per Lastschriftverfahren ³ seine Waren bezahlen oder auch durch Eingabe der PIN Nummer, Geld direkt vom Konto abbuchen lassen. Das sind die zwei üblichsten Prozesse bei der Benutzung einer EC Karte im Geschäft. Um jedoch etwas Bargeld zu erhalten, muss man an einem Geldautomaten einen gewünschten Betrag abheben. Dieser Prozess dürfte jedem bekannt sein. Man fährt zum Geldautomaten der eigenen Bank, um die Abhebungsgebühren zu sparen. Als nächstes wird die EC Karte in die vorgesehene Vorrichtung des Geldautomaten eingeschoben. Daraufhin fordert der Geldautomat den Benutzer auf, seine PIN Nummer anzugeben, um sich zu identifizieren. Danach erscheint ein Auswahlmenu. Dort kann dann ausgewählt werden zwischen

• vorgegebenen Beträgen (50 €, 100 €, 150 €, 200 €) • selbst einen eigenen Betrag eingeben • oder sogar erst seinen Kontostand anzeigen lassen.

Nachdem man seinen Kontostand anzeigen ließ, entscheidet sich diese Person, ggf. 50 € abzuheben. Somit klickt man auf das Feld 50 € und der Automat beginnt, den Auftrag zu bearbeiten. Am Ende des Geschäftsprozesses bekommt man seine EC Karte wieder zurück und der Geldbetrag kann entnommen 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 gegliedert. Genau nach diesem Prinzip werden Anwendungsfälle definiert. Das

³ bei einem Lastschriftverfahren muss auf der Rückseite des Kassenbons unterschrieben

werden und mit der Unterschrift willigt diese Person dem Lastschriftverfahren zu.