Java-Implementation eines Werkzeugs zur Dienstplanerstellung im Rechenzentrum eines Bankenverbundes

Inhaltsverzeichnis

Abbildungsverzeichnis

I Einleitung

II Analyse
A Ausgangssituation
1 Problembeschreibung
1.1 Ist-Analyse
1.2 Soll-Konzept
2 „Make-Or-Buy“-Entscheidung
2.1 Buy-Option
2.2 Make-Option
B Grundlagen der Programmierung
1 Die Programmiersprache Java
2 Einführung in die Objektorientierung
2.1 Objekte
2.2 Klassen
2.3 Vererbung
3 Datenorganisation
4 Guter Stil / Programmierkonventionen

III Implementierung
A Klassenmodell
1 Vorstellung verwendeter Klassen
1.1 Menüklassen
1.2 Hilfsklassen
1.3 Objektklassen/ operative Klassen
B Algorithmen
1 Vorstellung zentraler Algorithmen
1.1 Traversierung von Vektoren
1.2 Die Klasse Kalenderblatt
1.3 Die Methodeerstellen()der Klasse Dienstplan
C Dokumentation

IV Zusammenfassung und Ausblick
A Zukunftsperspektiven
1 Erstellung einer GUI
2 Anbindung an eine Datenbank
3 Realisierung eines Client-Server Modells
4 Einführung des Programmes
B Fazit

V Anhang

Abbildungsverzeichnis

Kapitel II Analyse

Abbildung 1: Beispiel eines Dienstplans, erstellt mit dem Lotus Organizer

Abbildung 2: Phasen der Systementwicklung

Abbildung 3: datei- und datenbankorientierte Datenhaltung

Kapitel III Implementierung

Abbildung 4: Ansicht Hauptmenü Plan-R

Abbildung 5: Ansicht MitarbeitermenüPlan-R

Abbildung 6: Ansicht Dienstplan-MenüPlan-R

Abbildung 7: Ansicht OptionenmenüPlan-R

Abbildung 8: Auszug aus dem vorläufigen Mitarbeitermenü

Abbildung 9: Übersicht Menüklassen Plan-R

Abbildung 10: Auszug aus dem endgültigen Mitarbeitermenü

Abbildung 11: Hilfsklassen Dateioperation und Datei

Abbildung 12: Hilfsklassen Eingabe und Userabfrage

Abbildung 13: Hilfsklasse Fehleingabe

Abbildung 14: Mitarbeiterobjekt und Abwesenheitsobjekt

Abbildung 15: Einfache Darstellung der Klassenzusammenhänge

Abbildung 16: Klasse Schicht

Abbildung 17: Elternklasse Tag und Kindklasse Wochentag

Abbildung 18: ElternklasseWochenende und Kindklass Wochenendtag

Abbildung 19: Klasse Kalenderblatt

Abbildung 20: Klasse Dienstplan

Abbildung 21: Quellcode Traversierung eines Vektors

Abbildung 22: Quellcode Konstruktor des Kalendeblattobjekts

Abbildung 23: Quellcode der Methode holeWochenenden()

Abbildung 24: Quellcode Methode erstellen() in der Klasse Dienstplan

Kapitel V Anhang

Abbildung 25: Übersicht über die operativen Klassen

Abbildung 26: Übersicht über die Menüklassen

Abbildung 27: Übersicht über die Hilfsklassen

I Einleitung

Der technische Support in einem modernen Rechenzentrum eines Bankenverbundes muss sich nach dem Bedarf der ihm angeschlossenen Banken richten. Das heißt im Regelfall, dass Supportzeiten von mindestens 7 Uhr morgens bis 19 Uhr abends abgedeckt werden müssen. Diese Zeitspanne ist jedoch länger als die tariflich zulässige Arbeitszeit. Als Konsequenz muss ein Schichtenmodell eingeführt werden. Die anfallenden Dienste möglichst gerecht auf alle Mitarbeiter zu verteilen, ist eine zeitintensive Beschäftigung, wenn es manuell durchgeführt wird.¹

Inhalt dieser Arbeit ist es, den Lebenszyklus eines in Java implementierten Programmes zur automatischen Dienstplanerstellung zu zeigen.

„In Analogie zu dem in der Konsum- und Investitionsgüterindustrie gebräuchlichen Begriff „Produktlebenszyklus“ wird bei Anwendungssystemen der ge samte Zeitraum von der Begründung und Planung über die Entwicklung, Einführung und Nutzung bis zur späteren Ablösung durch ein neues System als Software-Lebenszyklus (software life cycle) bezeichnet.“²

Lediglich die Ablösung des Systems wird in dieser Arbeit nicht dargestellt, da sie erst in Zukunft geschehen wird und derzeit nicht vorhersehbar ist.

Hauptteil und Ziel dieser Arbeit ist die Erstellung eines in Java implementierten Programms zur automatischen Dienstplanerstellung.

Am Anfang steht die Analyse der momentane Situation bezüglich der Dienstplanerstellung. Im weiteren wird eine „Make-Or-Buy-Entscheidung“³ herbeigeführt. Darüber hinaus behandelt dieser Abschnitt die der eigentlichen Programmierung vorgelagerten Aufgaben, insbesondere das Definieren bestimmter Leitsätze.

Der Abschnitt Implementierung behandelt detailliert die verwendeten zentralen Klassen und Algorithmen. Anhand von Auszügen aus dem Programm wird seine Funktionsweise erläutert. Ein weiterer Bestandteil des Themengebietes Implementierung ist die Dokumentation von Software.

Im Abschnitt „Zusammenfassung und Ausblick“ wird ein Einblick in die zukünftige Entwicklung des Programmes gegeben und abschließend ein Fazit gezogen.

II Analyse

A Ausgangssituation

1 Problembeschreibung

Gegenstand der Untersuchung ist die Vorgehensweise bei der Erstellung von Dienstplänen im KundenInformationsCenter, im weiteren KIC genannt, der GAD (Gesellschaft für automatische Datenverarbeitung e. G. ).

1.1 Ist-Analyse

Die Ist-Analyse beinhaltet per Definition „die Erhebung und Darstellung eines Systemzustandes in Abhängigkeit des Systemumfeldes“⁴. Das heißt bezogen auf die IstAnalyse in diesem Fall, dass die momentane Dienstplanerstellung des KIC näher betrachtet und bewertet wird.

Das Verteilen der einzelnen Dienste auf die Mitarbeiter des KIC erfolgt zur Zeit mit Hilfe des Programmes Lotus Organizer. Da die Verteilung manuell erfolgt, ist sie sehr zeitaufwendig. Es braucht im Durchschnitt fünf bis sechs Stunden monatlich um einen Dienstplan zu erstellen und zu pflegen. Abbildung 1 zeigt beispielhaft einen solchen manuell erstellten Dienstplan. Es müssen pro Wochentag eine 7-Uhr-Schicht mit einem Mitarbeiter, eine 8-Uhr-Schicht mit zwei Mitarbeitern, eine 10-Uhr-Schicht mit zwei Mitarbeitern und eine 11-Uhr-Schicht mit einem Mitarbeiter belegt werden. Die Wochenenden werden mit jeweils zwei Mitarbeitern besetzt. Jede Schicht innerhalb der Woche wird derzeit manuell eingetragen und möglichst gerecht verteilt. Gerecht bedeutet in diesem Zusammenha ng, dass die Dienste rollierend vergeben werden. Dadurch ist sichergestellt, dass jeder Mitarbeiter gleich behandelt wird und jeder alle Schichten zugeteilt bekommt; auch die unbeliebten.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Beispiel eines Dienstplans, erstellt mit dem Lotus Organizer

Begleitend muss auf Urlaube und Seminare, also auf Abwesenheiten, der einzuteilenden Mitarbeiter geachtet werden. Da der Dienstplan in der Regel von einem Teamleiter erstellt wird, fallen mit dem Zeitaufwand durch den vergleichsweise hohen Stundenlohn entsprechend hohe Kosten an. Ungeplante Mitarbeiterausfälle, wie z. B. Krankheit, führen bei der manuellen Dienstplanerstellung zu großem zeitlichen Änderungsaufwand und sind folglich sehr kostenintensiv.

Das Anfertigen des Dienstplanes ist zum einen durch den hohen Zeitaufwand und zum anderen durch die Monotonie der Tätigkeit und der dadurch resultierenden Fehleranfälligkeit zu einer der unbeliebtesten Aufgaben in der Abteilung geworden. Zeitersparnis, Kosteneffizienz und eine Verbesserung der Abläufe waren die Motivation nach softwaregestützen Alternativen zu suchen und ein Projekt ins Leben zu rufen.

1.2 Soll-Konzept

Aus eigenen Erfahrungen mit der Erstellung des Dienstplanes und im Zwiegespräch mit den Teamleitern entstand ein Anforderungsprofil für die gesuchte Software. Dieses Anforderungsprofil wurde in einem Pflichtenheft festgehalten.⁵

Die Systemanalyse ergab, dass im KIC mehrere Betriebssysteme und unterschiedliche Hardware eingesetzt werden. Somit sind die ersten Anforderungen an das Programm Plattformunabhängigkeit und universelle Einsetzbarkeit. Ein positiver Begleitaspekt dieser Anforderungen ist, dass das Programm dadurch auch außerhalb des KIC in anderen Bereichen der Firma einsetzbar ist.

Nach Möglichkeit soll die Anwendung auf einem bereits vorhandenen Linux Server laufen, der zur Zeit eine Know-How-Datenbank für das KIC zur Verfügung stellt. Auf dem Rechner des Nutzers befände sich dann nur noch das Front-End der Anwendung, welches in einem Browser als Applet⁶ liefe.

Eine Eigenschaft der verteilten Anwendung ist, dass mehrere Nutzer auf denselben Datenbestand zugreifen und mit ihm arbeiten können.

Bei den zukünftigen Nutzern der Software handelt es sich um Mitarbeiter des Rechenzentrums in ausschließlich technischen Bereichen. Daher kann von einem sehr versierten und intuitiv handelnden Endanwender ausgegangen werden. In der Praxis wird der Dienstplan von Teamleitern und berufserfahrenen Mitarbeitern, nie aber von Berufsanfängern erstellt. Die Benutzeranalyse kann somit nur einen Typen von Endanwender ermitteln, den versierten Benutzer.

Diese Tatsache macht es einfacher, ein geeignetes Produkt zu finden oder selber zu programmieren, da von einem hohen Know-How der Endanwender ausgegangen werden kann.

Bei der erfolgten Inhaltsanalyse ging es um die Frage, welche Funktionalitäten das Programm besitzen sollte. Eine komplette Aufstellung der Leistungsmerkmale ist im Pflichtenheft⁷ zu finden. Die zentralen und entscheidenden Punkte sind:

- Erfassung geplanter Abwesenheitszeiten (Urlaube, Seminare etc.)
- Vollautomatische Erstellung eines Dienstplanes für den jeweils nächsten Monat mit den Restriktionen, dass nie zwei neue Mitarbeiter zusammen die 8- oder 10-Uhr- Schicht übernehmen und ein neuer Mitarbeiter nie allein eine 7- oder 11-Uhr- Schicht besetzt.
- Einen Gesamtdienstplan ausdrucken und optional einen pro Mitarbeiter, um seine Schichten auf einen Blick sehen zu können.
- Die Schichten müssen nach Erstellung des Dienstplanes für den betroffenen Monat manuell austauschbar sein.
- Bestimmte Schichten müssen fest vorbelegt werden können und dann bei der eigentlichen Dienstplanerstellung unberücksichtigt bleiben, wie z.B. Wochenenddienste.

2 „Make-Or-Buy“-Entscheidung

Nach der Erstellung eines Anforderungskataloges folgt automatisch die Fragestellung, ob es eine Standardsoftware gibt, die die Systemanforderungen erfüllt, oder ob eine Eigenentwicklung wirtschaftlicher ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 : Phasen der Systementwicklung⁸

Wie in Abbildung 2 zu sehen, ist die „Make-Or-Buy“-Entscheidung von zentraler Bedeutung, da sie bestimmte Handlungsschritte unabdingbar nach sich zieht.

2.1 Buy-Option

Umfangreiche Recherchen ermitteln die Kosten und Einsetzbarkeit von bereits existierender Software. Der wichtigere der beiden Aspekte ist zunächst die Einsetzbarkeit, also die Suche nach einer Software, die alle Anforderungen erfüllt, da die Kosten irrelevant werden, wenn das Kriterium der Einsetzbarkeit nicht erfüllt ist. In den heutigen Zeiten bieten sich viele verschiedene Recherchemöglichkeiten an, da Firmen um eine große Transparenz ihrer Produktpalette bemüht sind und somit viele verschiedene Marketingstrategien nutzen um ihre Produkte bekannt zu machen.

In diesem Fall eignete sich besonders gut die Internetrecherche, da sie schnell viel Information bringt.

Mit Hilfe der Suchmaschinen Google und Yahoo wurde nach dem Begriff Dienstplan gesucht. Die Ergebnisse der Suche sind im Anhang A.2 aufgelistet. Die Treffer der Suche nach „Dienstplan“ bewegen sich größtenteils im medizinischen Bereich, da dort sehr viel im Schichtenmodell gearbeitet wird.

Fast alle der dort verzeichneten Produkte sehen aber weiterhin ein manuelles Eintragen der Schichten vor und sind lediglich in Puncto Oberflächengestaltung etwas ansehnlicher als der Lotus Organizer. Zwei Produkte erstellen eine automatische Verteilung der Dienste, sind aber ausschließlich auf 24 Stunden- und Wechselschichten ausgelegt. Das ist für den Einsatz im KIC sehr unpraktikabel, da es sich hier, wie bereits eingangs erwähnt, um vier immer gleichbleibende Schichten handelt. Die Hälfte des Schichtplanes bliebe somit leer. Darüber hinaus erfüllen die Programme einige der im Sollkonzept festgehaltenen Anforderungen nicht.

So bieten sie z.B. keine Option, bestimmte Mitarbeiter nicht zusammen in einer Schicht arbeiten zu lassen; siehe Anforderungskatalog „nie zwei neue Mitarbeiter zusammen eine Schicht belegen lassen“.

Das dritte Kriterium, was zum Ausschluß der beiden Kandidaten aus dem medizinischen Bereich geführt hat ist die Tatsache, dass sie beide für das Betriebssystem Windows NT optimiert sind, also keine Plattformunabängigkeit bieten und eine Verteilung der Anwendung auf Client und Server somit nicht im gewünschten Umfang möglich ist.

Zusammenfassend läßt sich sagen, dass kein einziges Produkt den Anforderungen genügt hat. Aus diesem Grund kann eine Wirtschaftlichkeitsanalyse nicht erstellt werden.

In Ermangelung von Konkurrenzprodukten, fiel die Entscheidung zugunsten des „Make“ also einer Eigenentwicklung aus.

2.2 Make-Option

Die Eigenerstellung von Individualsoftware beinhaltet, wie in Abbildung 2 ersichtlich ist, den Entwurf und die Realisierung des Programmes. Der Entwurf richtet sich im wesentlichen nach den im Sollkonzept aufgestellten Anforderungen bzw. nach dem Pflichtenheft⁹.

Demnach sind für die Realisierung des Programmes einige Punkte zwingend vorgeschrieben.

Da das Programm plattformunabhängig und verteilt auf Client und Server laufen soll, kommt als höhere Programmiersprache nur Java in Betracht.

Die Datenhaltung wird zunächst in Dateiform erfolgen, soll aber in einer weiteren Ausbaustufe zu einer Datenbank umgewandelt werden.

Diese Datenbank wird sich in der Endstufe der Entwicklung des Programmes zusammen mit der Serversoftware auf dem bereits bestehenden Linux-Server befinden. Hierauf wird detaillierter in Kapitel IV.A eingegangen.

B Grundlagen der Programmierung

1 Die Programmiersprache Java

Java wurde von Sun Microsystems als offenes System hergestellt, das heißt, Sun veröffentlichte detailliert alle Spezifikationen. Die Historie von Java als Programmiersprache ist noch nicht sehr lang. Im Jahr 1995 hatte Java seine Geburtsstunde, als die seit 1993 entwickelte Programmiersprache Oak in Java umbenannt wurde. Als Sun 1996 seine Java-Compiler kostenlos über das Internet verbreitete, gewann Java an Popularität.

Ein sehr wesentlicher Aspekt im Zusammenhang mit Java ist seine Plattformunabhängigkeit. Java ist dem Design nach unabhängig von eingesetzter Hardware und genutzten Betriebssystemen, läßt sich also z. B. in einem Windows Umfeld programmieren und dann ohne weitere Anpassungen nach OS/2 portieren. „Zusammengefaßt in dem Slogan: Write once - run anywhere.“¹⁰ Java hat als Programmiersprache noch weitere einzigartige Eigenschaften. So ist es beispielsweise „schlank und doch objektorientiert“, „fördert GUI-Programme in Form von Webbrowser-gestützten Applets“ und „ erleichtert die Netzprogrammierung in vielerlei Hinsicht“.¹¹

Mit diesen Eigenschaften deckt Java die im Sollkonzept formulierten Anforderungen ab. Eine Plattformunabhängigkeit erfüllt die wohl dringlichste Auflage, dass nämlich die Anwendung auf verschiedenen Betriebssystemen laufen muss. Die Objektorientierung ist im Falle der modularen Programmierung ein Muss. Das zu erstellende Programm wird den Namen Plan-R tragen. Der Dienstplaner Plan-R macht in seiner Entstehung mehrere Entwicklungsstufen durch: von der textbasierten, lokalen Anwendung bis hin zur verteilten Anwendung die in einem Applet eine benutzerfreundliche GUI¹² bietet und über eine Datenbankanbindung verfügt. Der Anforderung, dass die Anwendung verteilt in einem Browser laufen soll, kann nur Java gerecht werden, da keine andere Sprache Applets kennt. Außerdem kümmert sich Java im Falle der verteilten Anwendung darum, dass der Zielrechner des Nutzers immer die neuste Version des Applets bekommt. Der Administrator eines Systems muss dadurch nicht alle Rechner manuell updaten und hat die Gewissheit, dass auch wirklich alle Rechner auf dem neusten Stand sind.

2 Einführung in die Objektorientierung

Die Objektorientierung ist eine Strategie, die es ermöglicht, komplexen und unübersichtlichen Anforderungen an Systeme durch Strukturierung zu begegnen.

Das wesentliche Prinzip hierbei ist es, die realen Objekte des Problemfeldes, in diesem Fall der Dienstplanerstellung, zu erkennen und abzubilden. Diese Objekte werden dann in gekapselte Einheiten verpackt, deren äußere Struktur detailliert festgeschrieben ist und die in ihrer inneren Struktur selber für ihre eigene Konsistenz sorgen. Diese „Verpackungstechnik“ ermöglicht es, ein sehr großes Problem in einzelne Teile zu zerlegen und logisch nachvollziehbar zu strukturieren.

Jedes einzelne dieser Pakete kann zu jeder Zeit wiederverwendet werden und die Sichtbarkeit der Elemente eines Paketes kann gezielt kontrolliert werden. Dadurch ist es einem Nutzer nicht möglich alle Bestandteile eines Paketes oder einer Klasse zu sehen, sondern nur die Teile die für eine Nutzung notwendig sind.

Das abstrakte Modell der Kapselung und Klassenbildung ist von menschlichen Denkstrukturen abgeleitet.

Auch der Mensch fasst Dinge über Ähnlichkeiten und Gemeinsamkeiten zusammen, und es werden durch Suchen von Gemeinsamkeiten in höheren Ebenen immer höhere Abstraktionsgrade erreicht. So werden z. B. Hund und Katze unterschieden, aber unter dem Begriff Säugetiere zusammengefasst.

Es ist selbstverständlich, dass sich Dinge aus anderen Dingen zusammensetzen: ein Auto besteht aus Rädern, Motor, Getriebe etc. Es ist aber nicht notwendig, alle Einzelteile genau zu kennen, wenn man sich über Autos unterhalten möchte. Bei der Kapselung werden Einzelteile zusammengefasst und dann als Ganzes einem Benutzer zur Verfügung gestellt, ohne dass dieser Kenntnis über die Einzelteile erlangt. So können sehr komplexe Dinge relativ einfach zu nutzen sein, wenn die Schnittstelle nur simpel genug gestaltet ist. Zum Anschauen der Nachrichten im Fernsehen z. B., bedarf es keines umfangreichen Wissens um die genaue Funktionsweise jedes einzelnen Bauteiles des Fernsehers, man muss nur die Fernbedienung zu handhaben wissen.

2.1. Objekte

Um Objekte zu verstehen, können sie als Individuen gesehen werden, wobei einige von ihnen aktiver sind als andere. Manche Objekte werden selber aktiv und andere warten nur darauf, von anderen Objekten genutzt zu werden.

Jedes Objekt hat ein Gedächtnis, welches durch seine Attribute dargestellt wird. Die Attribute merken sich den Zustand des Objektes.

Die bereits beschriebene Kapselung, die auch „information hiding“ genannt wird, verhindert aber, dass ohne weiteres auf diese Attribute von außen zugegriffen werden kann. Denn nur dadurch, dass kein direkter Zugriff auf die Attributwerte möglich ist, kann ein Objekt seine innere Konsistenz wahren und beschützen. Und nur ein System in dem sich alle Einheiten in einem konsistenten Zustand befinden, kann im Ganzen fehlerfrei arbeiten.

Objekte können sich aus anderen Objekten zusammensetzen und werden häufig als Instanzen bezeichnet. Als Instanz deswegen, weil sie eine konkrete Ausprägung einer Klasse darstellen.

2.2. Klassen

Eine Klasse kann als Bauplan für Objekte verstanden werden. In einer Klasse werden sowohl das Gedächtnis eines Objektes (die Attribute) als auch sein Verhaltensmuster (die Operationen bzw. Methoden) definiert.

Alle Objekt, die von einer Klasse erzeugt oder instantiiert werden, haben die gleichen Attribute und Operationen, mit denen sie arbeiten können. Das heißt im Umkehrschluß, dass sich Veränderungen an dieser Klasse auch auf die von ihr abgeleiteten Objekte auswirken. Es muss also vorab sichergestellt sein, dass die vorzunehmende Änderung für die betroffenen Objekte kompatibel ist.

2.3 Vererbung

Die Klassen eines Softwaresystems können in eine hierarchische Anordnung gebracht werden. Man spricht hierbei von Generalisierungsbeziehungen oder Vererbung. Bei der Vererbung befinden sich allgemeine und generelle Eigenschaften in einer Oberklasse. Von dieser Oberklasse können Spezialisierungen, also Klassen mit speziellen Eigenschaften abgeleitet werden.

Grundsätzlich muss die abgeleitete Klasse alle Eigenschaften der Oberklasse übernehmen und alle Elemente der Oberklasse enthalten. Es können dann weitere Operationen hinzugefügt, oder die von der Oberklasse geerbten überschrieben werden. Ein Objekt, das von einer Klasse instantiiert wurde, kann auch als Instanz der Oberklasse gesehen werden. Bei der Generalisierung wird auch von einer „Ist-ein“- Beziehung gesprochen. Wenn z. B. die Oberklasse Mensch gebildet wird und davon zwei Klassen Mann und Frau abgeleitet werden, dann ist ein Objekt Frau auch gleichzeitig immer vom Objekttyp Mensch.

Durch dieses Konzept werden Strukturen eines Systems verbindlich definiert und durch den Compiler überprüfbar gemacht.

Die Vererbung ist somit ein mächtiges Instrument, birgt aber auch tiefgreifende Gefahren, wie z. B. dass Änderungen in der Klassenhierarchie im Nachhinein sehr kompliziert sein können. Stellt man z. B. fest, dass ein Fehler in einer der Oberklassen auftritt, muss immer beachtetet werden, dass eine Änderung der Oberklasse auf alle Unterklassen und alle von ihnen instantiierten Objekte durchschlägt. Es müssen also alle direkten und indirekten Unterklassen der geänderten Oberklasse erneut getestet werden.

An dieser Stelle durchbricht die Vererbung streng genommen das Konzept der Kapselung, denn die Unterklassen kennen die Einzelteile der Oberklasse, haben diese übernommen und sich auf deren Richtigkeit verlassen.

3 Datenorganisation

Die Datenorganisation kann in einen logischen und einen physischen Bereich unterteilt werden.¹³ Der logische Zweig bezieht sich auf die Datenstrukturen und der physische Zweig auf die Datenhaltung eines Programmes.

Unter dem Begriff Datenstruktur können sowohl der Aufbau vo n Wertebereichen mit Hilfe von Konstruktoren, als auch Datentypen verstanden werden.¹⁴ An dieser Stelle sollen jedoch lediglich Datentypen vorgestellt werden, da die Betrachtung von Wertebereichen im Zusammenhang mit der Datenorganisation irrelevant ist. Ein Programm wie Plan-R muss eine Vielzahl von Informationen aufnehmen, verarbeiten, speichern und ausgeben. Es fließen viele Daten in diverse Richtungen und um ein effizientes und korrektes Arbeiten einer Software zu gewährleisten, müssen diese kanalisiert werden.

Ein stringentes Konzept was Datenstrukturen und Datenhaltung definiert, ist daher unerlässlich.

Bevor eine Entscheidung über Datentypen oder das Speichern von Daten getroffen werden kann, müssen zunächst zwei zentrale Fragen beantwortet werden. Zum einen die Frage, was für Daten bzw. Objekte es in dem System gibt und zum anderen, was mit ihnen im Laufe der Verarbeitung geschieht.

In Plan-R gibt es eine unbestimmte Anzahl von Objekten, die miteinander agieren und als Ergebnis neue Objekte erzeugen. Es ist folglich von großer Wichtigkeit, Objekte so abzulegen und zu bündeln, dass ein Zugriff auf einzelne Objekte jederzeit und ohne Umwege gewährleistet ist.

Genau diese Anforderung erfüllt die Vector-Klasse. In einem Vektor können Objekte gleichen Typs abgelegt werden. In dieser Beziehung ähnelt ein Vektor einem Feld (Array) sehr. Doch die Tatsache, dass ein Feld direkt beim Instantiieren mit einer Größe vorbelegt werden muss, macht Felder hier unbrauchbar. Die Größe eines Vektors hingegen kann nach Bedarf wachsen oder schrumpfen und sich damit der jeweiligen Problemsituation anpassen.¹⁵

Da ein Vector eine Klasse und nicht ein Teil der Java Syntax ist, kann die Array-Syntax nicht benutzt werden, sondern es müssen Methoden aufgerufen werden, die bestimmte Arbeiten erledigen.¹⁶ Mit Hilfe eines Iterators kann z. B., ein Vektor traversiert, d.h. durchlaufen, und einzelne Elemente herausgeholt werden.

Es gibt noch weitere Methoden, die z. B. Objekte hinzufügen, löschen, suchen und die Größe des Vektors ermitteln können.

Da Vector ein direkter Nachfahre des Urahnen Objekt ist, können alle erdenklichen Objekttypen in ihm abgelegt werden, jedoch immer nur ein Objekttyp pro Vektor. Wird ein Objekt aus einem Vektor wieder herausgeholt, so muss zunächst eine Hürde überwunden werden. Es ist eine Typenumwandlung (auch Casting genannt) für das Objekt durchzuführen, da der Vektor zwar das Objekt, aber nicht den dazugehörigen Objekttyp herausgibt.

In Plan-R muss eine Mitarbeiteranlage erfolgen, damit die Mitarbeiter später in einen Dienstplan eingeteilt werden können. Niemand kann im Voraus wissen, wie groß der Mitarbeiterbestand ist bzw. wieviele Mitarbeiter noch während des Betriebs des Programmes hinzukommen. Deswegen wurden die Mitarbeiterobjekte in einen Vektor gelegt und können von dort aus der Reihe nach ausgelesen werden. Wie im Pflichtenheft¹⁷ zu sehen ist, unterliegt Plan-R aus zeitlichen Gründen mehreren Ausbaustufen. Die Ausbaustufen berühren nur die Datenhaltung, die Datenstrukturen sind so gewählt, dass sie persistent bleiben können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: datei- und datenbankorientierte Datenhaltung¹⁸

[...]

---

¹ Die Abbildungen 9, 11, 12, 14, 16, 17, 18, 19, 20, 25, 26 und 27 wurden mit Hilfe des Tools Rational Rose erzeugt.

² Vgl. Stahlknecht, Peter: Einführung in die Wirtschaftsinformatik, Seite 252

³ Entscheidung zwischen Eigenentwicklung und Fremdbezug

⁴ Dr. Biethahn, Jörg: Ganzheitliches Informationsmanagement, Band I, Seite 319

⁵ Siehe Anhang A.3

⁶ Kurzform für „little applications“

⁷ Siehe Anhang A.3

⁸ Vgl. Stahlknecht, Peter: Einführung in die Wirtschaftsinformatik, Seite 255

⁹ Siehe Anhang A.3

¹⁰ Abts, Dietmar: Grundkurs Java , Seite 1

¹¹ Bishop, Judy: Java lernen, Seite 21f

¹² Graphical User Interface; zu deutsch: grafische Benutzeroberfläche

¹³ Vgl. Dr. Biethahn, Jörg : Ganzheitliches Informationsmanagement, Band II, Seite 21

¹⁴ Vgl. Duden : Informatik- ein Sachlexikon für Studium und Praxis, Seite 169

¹⁵ Vgl. Prof. Dr.-Ing. habil. Balzert, Helmut: Lehrbuch Grundlagen der Informatik, Seite 395

¹⁶ Vgl. Darwin, Ian F.: Java Kochbuch, Seite 183

¹⁷ Siehe Anhang A.3

¹⁸ Vgl. Dr. Biethahn, Jörg: Ganzheitliches Informationsmanagement, Band II, Seite 22