Verwaltung der Daten von Dokumenten einer Bank (Teil 1)

Inhaltsverzeichnis

1 Aufgabenstellung

2 Erläuterung der Aufgabenstellung
2.1 Bezug zur Lehrveranstaltung
2.2 Lesbarkeit und Aufbau der Dokumentation
2.3 Interpretation der Praktikumsaufgabe
2.4 Objektorientierung und Polymorphie

3 Darstellung des Lösungsmodells
3.1 Darstellung der Lösungsidee
3.1.1 Klasse CDate
3.1.2 Klasse CBankDocument
3.1.3 Klasse CForm
3.1.4 Klasse CStandingOrder
3.1.5 Klasse CContract
3.1.6 Polymorphe Methoden
3.2 Darstellung der Architektur des Programmsystems

4 Programmtechnische Realisierung des Lösungsmodells
4.1 Namenskonventionen
4.2 Realisierungskonzeption
4.3 Testplan und Testergebnisse

5 Wertung des erreichten Ergebnisses

A Anhang
A.1 Anhang zur Aufgabenstellung
A.2 Die Quelltexte des Praktikums
A.2.1 Quelltexte package date
A.2.2 Quelltexte package bankproject
A.2.3 Quelltexte package bankprojecttest
A.3 Abbildungsverzeichnis
A.3.1 UML package date
A.3.2 UML package bankproject
A.3.3 UML package bankprojecttest
A.4 Literaturverzeichnis
A.5 Eidesstattliche Erklärung

1 Aufgabenstellung

Universität Potsdam Institut für Informatik Professur Software Engineering

Aufgaben für das Praktikum zur Lehrveranstaltung "Grundlagen der Softwareentwicklung I"

Entwickeln Sie eine objektorientierte Lösung für die Problemstellung "persistente Verwaltung der Daten einer Dokumentenmappe" in den Programmiersprachen Object Pas - cal, C++ oder Java.

Die Bausteine des Programmsystems sollen in Teilsystemen abgelegt werden. Bausteine des Programmsystems sind mindestens die Klassen

Abbildung in dieser Leseprobe nicht enthalten

Die Beschreibung der Klassen ist als Anhang beigefügt [S. 26].

Bestimmen Sie aus der Beschreibung die Klassen- und Teilsystemstruktur sowie die notwendigen Polymorphiebeziehungen.

Treffen Sie Implementationsentscheidungen hinsichtlich der Interfaces der Klasse. Bestimmen Sie die Vor- und Nachbedingungen der Methoden.

Zur Absicherung von Softwarequalitätsparametern des Programmsystems ist eine Testumgebung, die eine von Ihnen zu bestimmende Teststrategie unterstützt, zu entwerfen und zu implementieren.

Die Bearbeitung der Aufgabenstellung ist in zwei Etappen zu vollziehen.

1. Etappe: Implementation der Klassen CBankDocument, CForm, CStandingOrder und CContract ohne Persistenzhaltung (Leistung des Wintersemesters à Gegenstand dieser Praktikumsdokumentation),
2. Etappe: Implementation aller Klassen, einschließlich Persistenzhaltung und grafi- scher Benutzeroberfläche (Leistung des Sommersemesters).

Für jede Etappe ist eine Praktikumsdokumentation zu erarbeiten.

Vorgegebene Prozedurparameternamen und ihre Semantik sowie die CEDLBeschreibungen der geforderten Klassen sind im Anhang [S. 26] zu finden.

2 Erläuterung der Aufgabenstellung

2.1 Bezug zur Lehrveranstaltung

Die Erarbeitung der vorgestellten Praktikumsaufgabe schließt an die von Prof. Dr. E. Horn gehaltene Vorlesung „Grundlagen der Softwareentwicklung I“ für Lehramtsstudenten im dritten Semester (WS 2002/2003) des Erweiterungsstudiums Informatik an der Universität Potsdam an. Diese Lehrveranstaltung vermittelt theoretische Grundlagen, Spezifikationssprachen, programmiersprachliche Konzepte und Methoden für die Entwicklung modularer und objektorientierter Softwarearchitektur.

Bei der Entwicklung von Software sind verschiedene Qualitätsmerkmale zu berücksic h- tigen bzw. abzusichern. Die Gesamtheit dieser Qualitätsmerkmale bezeichnet man als Softwarequalität. Dazu gehören Korrektheit (Grad der Übereinstimmung), Flexibilität (Änderungen, Wiederverwendbarkeit), Verständlichkeit (Güte der Dokumentation), Stabilität (Produkt funktioniert auch bei partiellen Ausfällen und Falscheingaben) und Effizienz (Auslastung von Speicherplatz und Rechenzeit) [Hor97 S. 6-1].

Konstruktive Qualitätssicherung erfolgt durch quantitative Aussagen bei der Spezifika- tion des Softwareprodukts und beinhaltet Anforderungen an die Struktur des Software- systems und qualitätssichernde Bestandteile. Der Nachweis der geforderten Quali- tätsmerkmale durch die Analyse der Produkte wird als Analytische Qualitätssicherung bezeichnet, wozu das Testen von Softwaresystemen gehört [Hor97 S. 6-1].

2.2 Lesbarkeit und Aufbau der Dokumentation

Als Grundlage für die Erarbeitung der Dokumentation wurde die Word-Vorlage Belegdoku.dot von Herrn Schubert verwendet, welche aber um einige Gliederungs- punkte erweitert wurde. Die Schriftart/-größe wurde an persönliche Bedürfnisse ange- passt. Als Standardschrift wurde Arial in Größe 11 und einem Zeilenabstand von 15 Punkten, als Absatzabstand weitere 6 Punkte verwendet. In der Praktikumsdokumenta- tion erfolgt die Dokumentation von Variablen und Methoden in deutscher Sprache. In Quelltexten im Anhang wurden diese jedoch standardmäßig in Englisch dokumentiert.

Besonders wichtige Wörter werden kursiv geschrieben. Für Dateinamen wurde die Schriftart Tahoma gewählt. Auszüge aus Quelltexten, insbesondere Bezeichner für Va- riablen und Methoden, werden in Courier New dargestellt. Bei Methodennamen folgt immer ein Klammernpaar, wobei die Parameter nicht immer aufgeführt werden.

Literaturangaben im Text werden mit eckigen Klammern unter Angabe der Quelle und Seitenzahlen gegeben, z.B. [Quelle S.1]. Die Quelltexte im Anhang [S. 34] werden mit Hilfe des JBuilders 7 Personal in Standardschrift mit Syntax und in Farbe ausgegeben.

In der Dokumentation werden Begriffe inhaltlich wie in der Vorlesung bzw. in der objektorientierten Programmiersprache Java verwendet. Sollte ein Begriff eingeführt bzw. nicht üblich verwendet werden, so wird in der Dokumentation an der betreffenden Stelle darauf eingegangen.

Die in der Dokumentation dargestellten UML-Grafiken wurden mit der Trial-Version des Borland JBuilders 8 Enterprise (30-Tage-Test) erstellt. Zu beachten ist dabei, dass der UML-Browser des JBuilders get- und set- Methoden im Diagramm nicht immer dar- stellt. Jedoch lässt sich mit dem UML-Browser die Klassenstruktur des Projektes sehr gut darstellen.

Der Aufbau der Praktikumsdokumentation teilt sich in fünf Gliederungspunkte und dem Anhang auf. Im ersten Punkt ist die Aufgabenstellung zu diesem Praktikum dargestellt [S. 1]. Im zweiten Abschnitt wird die Aufgabenstellung mit eigenen Worten und mit ver- einbarten Einschränkungen dargestellt bzw. wiedergegeben. Des Weiteren wird kurz auf Objektorientierung und Polymorphie in der objektorientierten Softwarenetwicklung eingegangen.

Aus diesem Gliederungspunkt heraus wird im 3. Abschnitt der Dokumentation ein Lö- sungsmodell für die Aufgabe entworfen. Hier werden Änderungen zu Signaturen ge- genüber der Aufgabenstellung, zusätzlich eingeführte Klassen bzw. Vor- und Nachbe- dingungen für wichtige Methoden beschrieben. Des Weiteren wird die Architektur des Softwaresystems, d.h. die Klassenstruktur und Polymorphiebeziehungen dargestellt.

In Punkt 4 wird die programmtechnische Umsetzung beschrieben, u.a. verwendete Programmiersprache und -umgebung, Regeln für die Namensvergaben von Methoden und Variablen. Die zugehörigen Quelltexte sind im Anhang [S. 34]. Es werden eine Teststrategie und ein Testplan entworfen, mit dem ein protokollierter Test durchgeführt wird.

Am Schluss der Dokumentation [S. 25] wird über das Erreichte reflektiert. Hier wird in Bezug auf die Aufgabenstellung aufgezeichnet, was erreicht wurde und was nicht. Es soll auch ein Ausblick darüber gegeben werden, wodurch die Softwarequalität [S. 2] der Lösung verbessert werden kann.

2.3 Interpretation der Praktikumsaufgabe

Ziel des Praktikums ist die Entwicklung eines objektorientierten Softwaresystems für die Verwaltung der Daten von Dokumenten einer Bank. Laut Aufgabenstellung gehören dazu Softwarebauelemente für die Verwaltung von elementaren Dokumenten (CBankDocument), Formularen (CForm), Daueraufträgen (CStandingOrder) und Verträgen (CContract). Zusätzlich zu diesen Klassen wird noch ein Teilsystem (CDate) für die Abbildung von Datums- und Zeitangaben gefordert.

Die erste Etappe der Aufgabenbearbeitung im Wintersemester reduziert die vorliegende Aufgabenstellung um die Klasse CFolder, in der die Dokumente wie in einer Kartei verwaltet werden können. Mit dieser Klasse entfällt auch die Persistenzhaltung der Dokumente in einer Datei, d.h. dass die Inhalte der Bankdokumente nicht wiederherstellbar auf einem Datenträger gespeichert werden müssen.

Ebenso wie die Persistenzhaltung war die Implementation einer grafischen Benutzeroberfläche noch nicht Gegenstand der Vorlesung. Aus diesem Grund wurde auch diese auf die zweite Etappe des Praktikums im Sommersemester verschoben.

Mit der Aufgabenstellung wurde zu jedem Teilssystem eine CEDL-Beschreibung gege- ben, welche mit Hilfe einer objektorientierten Sprache wie Object Pascal, C++ oder Ja- va umzusetzen ist. CEDL (Construction Element Definition Language) ist eine allge- meine Sprache für Softwarebaulemente mit programmiersprachenunabhänigen Mitteln [Hor02 S. 54].

In den Beschreibungen sind die geforderten Klassenattribute und Methodendeklaratio- nen mit Über- und Rückgabeparametern zu erkennen. Von diesen Methoden werden in der Bearbeitung dieses Teils des Praktikums einige (noch) nicht benötigt, zum Teil we- gen der nicht geforderten Persistenzhaltung (EqualKey() und KeyOf()) und zum Weiteren aufgrund meiner Wahl der Entwicklungsumgebung Java, in welcher eine Me- thode equal() für die Identität von Objekten durch equals() bereits gegeben ist.

Da Java über ein automatisches Speichermanagement verfügt, kommt den Destrukto- ren hier eine viel geringere Bedeutung zu als in anderen objektorientierten Sprachen. Anders als etwa in C++ oder Object Pascal muss sich der Entwickler in Java nicht um die Rückgabe von belegtem Speicher kümmern [Ull01 S. 253]. In unregelmäßigen Ab- ständen findet automatisch eine Speicherbereinigung (garbage collection) statt. Aus diesem Grund entfallen weiterhin die in der Aufgabenstellung beschriebenen Methoden

Abbildung in dieser Leseprobe nicht enthalten

2.4 Objektorientierung und Polymorphie

Im Mittelpunkt der objektorientierten Programmierung steht ein Objekt (Object). Wenn dieses Objekt Mittel bereitstellt, um Objekte zu erzeugen und zu vernichten, wird es als Klassenobjekt oder kurz als Klasse bezeichnet. Ein Objekt, das selbst keine Objekte erzeugen kann, heißt Instanzenobjekt oder kurz Instanz der Klasse [Hor02 S. 123].

Klassen sind somit spezielle benutzerdefinierte Datentypen, von denen Instanzen er- zeugt werden können. In den Klassen werden neben Klassenattributen (-variablen oder -instanzen) auch Methoden definiert, mit welchen man die Attribute beeinflussen kann. Ein wichtiges Kriterium dabei ist die Sichtbarkeit von Attributen und Methoden (privat, protected und public) von anderen Klassen auf die Betreffende.

Programmiersprachen wie C++, Object Pascal oder Java, die diese objektorientierte Darstellung erlauben, nennt man objektorientierte Programmiersprache.

Die Beziehungen zwischen Klassen untereinander bzw. zwischen Klassen und Instanzen sind vielfältig. Ich möchte nur auf die Beziehungstypen (Konnektoren) eingehen, die in Hinblick auf die Bearbeitung der Praktikumsaufgabe und der Verwendung der Programmiersprache Java von Bedeutung sind.

Werden Instanzen von Klassen erzeugt, spricht man von einer Instanziierungsbezie hung (instance_of) [Hor02 S. 127f]. Da das geforderte Softwaresystem mit der Programmiersprache Java erstellt wird, steht die dynamische Erzeugung von Instanzen im Vordergrund. Java arbeitet mit Referenzen, d.h. stark typisierte Zeiger (Pointer), die ihren Typ nicht ändern können [Ull01 S. 45]. Wie oben beschrieben, braucht man sich in Java nicht um die Freigabe von Speicherplatz (Destruktoren) kümmern.

Eine weitere Beziehung ist die Nachrichtenaustauschbeziehung, d.h. Klassen und In- stanzen können miteinander mit Hilfe von Methoden kommunizieren. Ein(e) Nachricht / Methodenaufruf besteht aus drei Teilen: Empfänger.Methodenname(Argumente).

Die Vererbung von Klassen wird durch Verweise zu Oberklassen realisiert. Eine Verer- bungsbeziehung (inherit, is_a, extends) bedeutet, dass die Unterklasse alle In- stanzvariablen und Methoden ihrer Oberklasse erbt, was eine Möglichkeit zur Wieder- verwendung bietet. In Java kann eine Klasse durch das Schlüsselwort extends eine (Ober-)Klasse erweitern. Dabei werden alle sichtbaren (public und protected) Ei- genschaften der Oberklasse auf die Unterklasse übertragen. In Java ist auf direktem Weg nur die Einfachvererbung erlaubt, d.h. eine Klasse kann lediglich eine andere er- weitern [Ull01 S. 255f]. Somit werden Klassen in einer Vererbungshierarchie geordnet. Andere Programmiersprachen bieten zusätzlich noch Mehrfachvererbung bzw. wieder- holte Vererbung an.

Werden durch eine Vererbungsbeziehung in der Unterklasse Methoden mit demselben Bezeichner wie in der Oberklasse verwendet, sprechen wir von einer Vererbung mit Polymorphie (Vielgestaltigkeit). Den Klassen werden dabei polymorphe Methoden zu- geordnet, deren Funktionsweise durch den Empfänger der Methode bestimmt ist. Da- bei kann eine solche Methode in der erbenden Klasse eine andere Methodendeklarati- on haben {Hor02 S. 131].

Da in Java mit virtuellen Methoden gearbeitet wird, erfolgt die Bindung des Aufrufes an ein Objekt zur Laufzeit (dynamisch). Die polymorphe Methode der Unterklasse über- schreibt die Methode der Oberklasse. Wird jedoch ein Empfänger der Oberklasse an- gesprochen, erfolgt die Bindung an die Methode der Oberklasse. In Java können als static, private oder final deklarierte Methoden nicht überschrieben werden und sind daher nicht polymorph.

Eine weitere Möglichkeit der Polymorphie bieten ü berladene Methoden, das sind Me- thoden mit gleichem Namen, aber verschiedene Parameterlisten. Möglich wäre erstens eine gleiche Anzahl von Parametern, aber für den Compiler unterscheidbare Typen, oder zweitens eine unterschiedliche Anzahl von Parametern. In Java steht für diese Art der Polymorphie nur der der zweite Fall zur Verfügung, etwa bei der Deklaration von Konstruktoren für Klassen, wobei diese Methoden den gleichen Typ des Rüchgabewer- tes haben müssen [Ull01 S. 120f].

Zuletzt sei noch die Benutzungsbeziehung (use) genannt. Eine Klasse A benutzt eine andere Klasse B, wenn eine Instanzvariable der Klasse A vom Typ der Klasse B ist (explizite Beziehung) oder wenn ein Parameter einer Methode von A vom Typ B ist (explizite Beziehung) oder in der Implementation von A die Klasse B benutzt wird (im- plizite Beziehung). Dazu muss in der Klasse A die Klasse B zunächst importiert wer- den. Dies geschieht in Java durch das Schlüsselwort import [Hor02 S. 135]. In die- sem Zusammenhang sein noch die Möglichkeit erwähnt, thematisch zusammengehöri- ge Klasse in Gruppen, Pakete genannt, zu ordnen (packages) [Ull01 S. 308f].

3 Darstellung des Lösungsmodells

In der Aufgabenstellung geht es um das Erstellen einer Dokumentenhierarchie, wie sie im Bankwesen auftreten könnte, mittels objektorientierter Programmierung. Eine solche Hierarchie ist ständigen Änderungen der Dokumente ausgesetzt. Eine objektorientierte Lösung dieser Aufgabe vereinfacht es dem Programmierer bei der Realisierung und Anpassung der Dokumentenhierarchie.

Dem Programmierer stehen somit alle Mittel der objektorientierten Entwicklung von Softwaresystemen zur Verfügung (Klassen, Objekte, Vererbung, Polymorphie). Auf- grund der Vererbung mit Polymorphie braucht er nicht Quellcode ändern, wenn neue Dokumente hinzukommen oder alte gelöscht werden. Des Weiteren können Instanzva- riablen und nicht-polymorphe Methoden von Klassen vererbt werden und die erbende Klasse kann diese ohne Einschränkung nutzen, wie Datumsangaben, Bearbeiter usw.. Im Gegenzug werden polymorphe Methoden immer an den Typen des Empfängers gebunden, so dass als Parameter jeweils auch andere Typen erlaubt sind [S. 4].

Durch diese Vererbung können „… ist ein …“-Beziehungen (is_a) gebildet werden. Das allgemeinste Bankdokument CBankDocument ist die Wurzel der Hierarchie. Alle anderen Dokumente (CForm, CStandingOrder, CContract) sind durch Vererbungen somit auch Bankdokumente vom Typ CBankDocument. D.h. aber auch, dass ü- berall, wo ein CBankDocument erwartet bzw. angesprochen wird, auch eines der anderen Dokumente auftreten kann [S. 4].

Durch den Aufbau der Hierarchie kann in der zweiten Etappe des Praktikums eine Mappe erstellt werden, die eine Vielzahl verschiedener Dokumententypen verwalten bzw. persistent speichern kann. Dann erlaubt die Mengenklasse CFolder die Verwal- tung von Instanzen von CBankDocument, CForm, CStandingOrder und CContract, welche die gemeinsame Wurzel CBankDocument haben. Diesen Sac h- verhalt bezeichnen wir als polymorphe Menge (polymorphic set). Ein Vorteil dieser Or- ganisation besteht darin, dass nur eine Mengeninstanz für die Verwaltung aller poly- morphen Objekte existieren muss. Eine solche Mappe speichert dann Objekte vom Typ CBankDocument, wobei aber auch alle anderen bankrelevanten Dokumente referen- ziert sein können [Hor02 S. 223].

Da in der Aufgabenstellung eine Vererbung mit Polymorphie gefordert und diese für die Aufgabenstellung auch sinnvoll ist, muss es polymorphe Methoden der Dokumenten- hierarchie geben, die in allen Dokumenten auftauchen. Laut Aufgabenstellung sind dies die fünf Methoden ClassInvariant(), Equal(), EqualValue(), Copy() und Show(). Jedes Dokument kann mit ClassInvariant() überprüft werden, ob es gül- tig für die weitere Verarbeitung bzw. Anwendung ist. Des Weiteren können Dokumente verglichen werden, ob sie wertgleich (EqualValue()) oder identisch (Equal()) sind. Dokumente können ihre gültigen Inhalte (ClassInvariant()) auf ein Dokument gleichen Typs mit Copy() kopieren. Und zuletzt sei noch die Möglichkeit erwähnt, je- des Dokument entsprechend seines Typs mit Show() auszugeben [S. 5].

Jedoch dient diese letzte polymorphe Methode nur zu Testzwecken, da die Benutzeroberfläche (Grafical User Interface - GUI) zur Verwaltung und Speicherung von Mappen und die in ihnen enthaltenen Dokumenten erst in der zweiten Etappe des Praktikums erarbeitet werden.

Neben polymorphen Methoden enthalten die Klassen aber auch nicht-polymorphe Methoden. Dazu gehören Standardmethoden für das Ändern (setAttribute()) und das Zurückgeben (getAttribute()) von Klassenattributen, die standardmäßig als privat deklariert werden. Für die vorliegende Dokumentenhierarchie werden diese Methoden aber nicht für alle Klassenattribute definiert, sondern nur solche, die laut Aufgabenstellung gefordert sind bzw. für die Lösung benötigt werden. Nichtpolymorphe Methoden werden in der Reihenfolge der Vererbung von der erbenden Klasse nicht überschrieben. Sie stehen somit, wie die Klassenattribute der vererbenden Klasse, in allen Unterklassen zur Verfügung.

Genauere Beschreibungen der Klassen der Dokumentenhierarchie [S. 16] und ihrer Struktur [S. 16], sowie über polymorphe und nicht-polymorphe Methoden folgen in den nächsten Kapiteln. Erläuterungen zur Umsetzung der Lösungsidee mit der objektorientierten Programmiersprache Java folgen im Abschnitt 4 [S. 18].

3.1 Darstellung der Lösungsidee

Im folgenden Abschnitt werden die Schnittstellen der in der Aufgabenstellung geforderten Teilsysteme beschrieben. Im Großen und Ganzen habe ich mich bei der Umsetzung der Praktikumsaufgabe in die Programmiersprache Java an die gegebene CEDLBeschreibung der Klassen [S. 26] gehalten.

Reduzierungen von darin enthaltenen Methoden wurden bereits in 2.3 [S. 3] begründet. Auf Änderungen bei der Namensvergabe für Variablen und Methoden gehe ich im Abschnitt 4.1 [S. 18] genauer ein.

Da das Teilsystem CDate nicht genauer beschrieben ist, wurde ein eigener Ansatz für die Umsetzung gewählt. Das Datumsattribut wird in verschiedenen Klassen für Da- tums- und Zeitangaben der Erstellung (DateOfFoundation in CBankDocument) oder der Änderung (AlterationDate alle außer CBankDocument) eines Bankdo- kuments benötigt. Die Anpassung der Datumsattribute erfolgt vom System automa- tisch, so dass weder in den Konstruktoren bzw. in den Methoden eine manuelle An- passung durchgeführt wird.

Für das Änderungsdatum AlterationDate wurde in den Klassen CForm und CContract die Methode updateAlterationDate() hinzugenommen. Mit dieser Methode wird dann bei der Änderung eines Attributes das Änderungsdatum automa- tisch angepasst.

Da über die Bedeutung des Änderungsdatums in der Aufgabenstellung keine weiteren Aussagen gemacht wurden, habe ich es so in das System implementiert, dass es zu dem Dokument dazugehört, d.h. es wird beim Kopieren mitkopiert und beim Vergleich auf Wertgleichheit berücksichtigt.

Im Folgenden gehe ich auf die Klassen einzeln ein, werde ich mich aber bei der Beschreibung von Vor- und Nachbedingungen nur auf wichtige Methoden beschränken und setze voraus, dass diese Bedingungen für standardgemäße set- und getMethoden für Klassenattribute vertraut sind.

Die ClassInvariant()-Methode der Aufgabenstellung wurde umbenannt in isClassInvariant() und wurde somit den Namenskonventionen von Java gerechter. Weitere Änderungen von Namen werden im Abschnitt 4.1 [S. 18] beschrieben. Des Weiteren wird die geforderte Methode equal() durch die bereits in Java vorhandene Methode equals() bereitgestellt und braucht nicht implementiert werden.

Wenn nicht anders beschrieben, sind die vorgestellten Methoden alle public und wie in Java üblich virtuell. Die Klassenattribute werden üblicherweise als private deklariert.

Ausführliche Beschreibungen der Attribute und Methoden, sowie deren Vor- und Nachbedingungen sind im Anhang unter Quelltexte [S. 34] des Praktikums als Kommentare im Quelltext zu finden, sowie auf der CD in der von JavaDoc generierten HTMLDokumentation des Projekts.

3.1.1 Klasse CDate

Da die Klasse CDate [S. 34] in der Aufgabenstellung nicht weiter spezifiziert ist, implementiere ich sie nach meinen Vorstellungen.

Für die Datum- und Zeitangaben werden die Klassenattribute Tag (Day), Monat (Month), Jahr (Year), Stunde (Hour), Minute (Minute) und Sekunde (Second) als Ganzzahlen mit einer privaten Sichtbarkeit (private int) implementiert.

Als Konstruktoren von CDate-Objekten stehen der Stan- dard-, zwei Initialisierungs- und ein Kopierkonstruktor zu Verfügung.

Der Initialisierungskonstruktur ohne Parameter erzeugt ein Datumsobjekt und übergibt die aktuelle Zeit bzw. das aktuelle Datum an das Objekt.

Bei den Initialisierungskonstruktoren werden dem neu er- zeugten CDate-Objekt die Parameter als Attribute überge- ben. Bei dem ersten sind das nur die Datumsangaben (die Zeitattribute werden generiert) und bei zweiten werden alle sechs Attribute parametrisiert.

Abbildung in dieser Leseprobe nicht enthalten

Auszug aus Abbildung 3: UML-Diagramm Klasse CDate.java [S. 80]

Der Kopierkonstruktor erzeugt mit einem vorhandenen, gültigen CDate-Objekt ein Neues und kopiert dessen Werte auf das neue Objekt.

Da das Datum im Softwaresystem automatisch generiert wird, sind nur der Standard- konstruktor und der Kopierkonstruktor für das Projekt von Bedeutung. Für eine weitere Verwendung meiner CDate-Klasse wurden auch die anderen beiden implementiert.

Die Klasse CDate gehört nicht mit zum Paket (package) der Bankdokumente. Sie eröffnet für eine weitere Nutzung ein neues Paket (package date).

Neben den standardmäßigen get-Methoden (in UML-Beschreibung nicht dargestellt) für die als privat deklarierten Klassenattribute werden weiteren Methoden implemen- tiert. Diese erhalten in Hinsicht auf die Aufgabenstellung die gleichen Namen, wie die polymorphen Methoden des Softwaresystems Bankdokumente, da sie denselben Zweck verfolgen.

Die erste Methode (isClassInvariant()) überprüft, ob ein CDate-Objekt gültig ist (true oder false), d.h. die Datums- und Zeitangaben korrekt sind. Dazu werden die einzelnen Werte anhand gültiger Intervalle (z.B. 0<=Hour<24) überprüft. Da auch auf Schaltjahre geachtet werden muss, enthält die Klasse zusätzlich die Methode isLeapYear(), welche true zurückgibt, wenn das Datum im Schaltjahr liegt, anderenfalls false.

Eine weitere Methode ist equalValue(). Sie überprüft, wie bei den anderen Klassen der Aufgabenstellung die Wertgleichheit (nicht die Identität oder Referenzgleichheit) und gibt in diesem Fall true zurück.

copy() ist die dritte Methode. Mit dieser können die Werte eines übergebenden CDa- te-Objekts auf das aktuelle Objekt übergeben werden. Dazu wird geprüft, ob es über- haupt sinnvoll ist zu kopieren (Klassengleichheit, Klasseninvarianz, Wertgleichheit schon vorhanden). Der Rückgabewert bei erfolgreichem Kopieren ist true, ansonsten false.

Die letzte wichtige Methode der Klasse ist show(), welche eine Zeichenkette (String) liefert, mit der das Datum und die Zeit des aktuellen Objektes ausgegeben werden kann.

3.1.2 Klasse CBankDocument

Das Basisdokument der Dokumentenhierarchie ist die Klasse CBankDocument und eröffnet das Paket, welches die geforderten Bankdokumente zusammenfasst (packa- ge bankproject). Sie repräsentiert ein allgemeines Bankdokument.

Die anderen Klassen des Pakets erben direkt bzw. indirekt die Klassenattribute dieser Klasse. Dazu gehören Author (String für den Ersteller des Dokuments), DateOfFoun- dation (CDate für das Erstellungsdatum), Title (String für den Titel des Dokuments) und Key (String für einen Registrierungsschlüssel). Somit geht CBankDo- cument eine Benutzungsbeziehung mit der Klasse CDate ein [S. 5].

Abbildung in dieser Leseprobe nicht enthalten

Auszug aus Abbildung 5:UML-Diagramm Klasse CBankDocument.java [S. 81]

Da nicht vorgesehen ist, diese Attribute zu einem späteren Zeitpunkt zu ändern, sind keine set-Methoden für die Klas- senvariablen vorgesehen. Methoden für die Rückgabe der als privat deklarierten Variablen werden standardgemäß implementiert.

Die Konstruktoren der Klasse sind der Standardkonstruktor, in welchem nur das Erstel- lungsdatum initialisiert wird und der somit keine Klasseninvariante (kein gültiges Do- kument) darstellt, ein Initialiserungskonstruktor, in dem Autor, Title und Key mit den übergebenen Parametern und das Erstellungsdatum automatisch initialisiert werden (nur klasseninvariant wenn Strings nicht leer) und der Kopierkonstruktor, der mit Hilfe der copy()-Methode die Werte eines klasseninvarianten Objektes vom Typ CBankDocument auf das Neue kopiert (auch das Erstellungsdatum).

Die polymorphen Methoden isClassInvariant(), equalValue(), copy() und show() tau- chen mit einem ähnlichen Aufbau auch in den anderen Klassen des Package auf, und werden daher gesondert im Abschnitt 3.1.6 [S. 13] beschrieben. Für alle Klassen kann man zudem Vor- und Nachbedingungen in den Kommentaren des Quelltextes [S. 34] bzw. in der HTML-Dokumentation des Projektes [CD:\JavaDoc\ î ndex.html] genauer nachlesen.

3.1.3 Klasse CForm

Die Klasse CForm ist eine konkrete Unterklasse von CBankDocument und erbt somit dessen Attribute und Methoden. Sie gehört mit zum package bankproject und repräsentiert die Erweiterung des allgemeinen Bankdokuments zu einem Bankformular.

Dazu werden weitere Attribute eingeführt, wie AlterationDate (CDate für das Änderungsdatum), Formality (String für Beschreibung oder Formalitäten), Proved (boolean für den Prüfzustand) und Signed (boolean für den Unterschriftszustand).

Das Formular dient als Erweiterung für weitere Bankdokumente, so erbt in unserer Hierarchie CStandingOrder (Dauerauftrag) direkt von CForm.

Da dieses Formular als Grundlage weiterer Dokumente dienen kann, habe ich die in der Aufgabenstellung gege- benen Konstruktoren um einen erweitert.

Der Standardkonstruktor ruft den Standardkonstruktor der Elternklasse auf (Initialisierung von DateOfFounda- tion) und initialisiert seinerseits Proved und Signed.

Abbildung in dieser Leseprobe nicht enthalten

Auszug aus Abbildung 6: UML-Diagramm Klasse CForm.java [S. 82]

Da alle anderen Klassenvariablen noch nicht initialisiert wurden, entsteht ein CFormObjekt, welches nicht klasseninvariant ist.

Des Weiteren ist der Initialisierungskonstruktor #1 gefordert, der die Attribute Author, Title, Key, Proved, Signed und Formality übergeben bekommt und diese neben AlterationDate (=aktuelles Datum / Systemzeit) initialisiert.

Da der Prüf- und Unterschriftszustand bei einem neuen Formular stets false sein dürfte, habe ich einen Initialisierungskonstruktor #2 eingeführt, der Proved und Signed bei Erstellung des Formulars nicht übergeben bekommt, sondern dann auf false setzt.

Der vierte Konstruktor, der Kopierkonstruktor, erstellt mit Hilfe eines vorhandenen, klasseninvarianten Formulars und der copy()-Methode ein neues Formular. Wie bei allen Kopierkonstruktoren würde die equals()-Methode ein false und die isEqual- Value()-Methode ein true liefern, werden das neue Objekt und das Kopierte mit diesen Methoden verglichen.

Ein Formular ist nach isClassInvariant() gültig, wenn die aus CBankDocument vererbten Attribute gültig sind (super.isClassInvariant()), das Änderungsdatum gültig (AlterationDate.isClassInvariant()) und der Formality-String nicht leer ist.

Neben den polymorphen Methoden, die in 3.1.6 [S. 13] dargestellt werden, und den normalen get-Methoden sind spezielle set-Methoden und eine Methode updateAlte- rationDate() (protected) implementiert. Werden Proved oder Signed geändert, so wird updateAlterationDate() aufgerufen und das Änderungsdatum aktualisiert.

3.1.4 Klasse CStandingOrder

Der Dauerauftrag ist wiederum eine Erweiterung eines Formular, somit erbt diese Klasse alle Attribute und Methoden (wenn nicht überschrieben) von CForm (und CBankDocument). Die Klasse gehört zum package bankproject.

Zu den bekannten Variablen führt diese Klasse Amount (Integer für Zahlungsbetrag), Interval (Integer für Zahlungsintervall), Recipient (String für Empfänger), Source (String für den Auftraggeber) und Subject (String für den Betreff) ein.

Ein Dauerauftrag ist nur dann klasseninvariant, wenn zum Einen die vererbten Attribute gültig sind und zum Anderen dürfen die neu eingeführten Strings nicht leer und die Integer nicht kleiner als Eins sein. Für die Integer sind in der Aufgabenstellung Ordinal- Zahlen (natürliche Zahlen) gefordert. Da Java einen solchen Zahlentyp nicht bereitstellt, muss man auf Integer (ganze Zahlen) zurückgreifen und absichern, dass diese größer als Null sind.

Abbildung in dieser Leseprobe nicht enthalten

Auszug aus Abbildung 7: UML-Diagramm Klasse CStandingOrder.java [S. 82]

Die geforderten Konstruktoren wurden wieder um einen Iinitialisierungskonstruktor erweitert, der das Setzen von Proved und Signed aus genanntem Grund auf false selbst übernimmt. Der Standardkonstruktor erzeugt ein nicht klasseninvariantes Objekt durch Verwendung des Konstruktors der Elternklasse und der Initialiserung von Amount und Interval auf 0.

Der Kopierkonstruktor kann nur ein neues Objekt erzeugen, wenn das Quellobjekt klasseninvariant ist, wegen der Überprüfung der Klasseninvarianz in der copy()- Methode.

Bei den set-Methoden für Amount und Interval wird das Änderungsdatum mit updateAlterationDate() wieder aktualisiert. Die get-Methoden für die privat deklarierten Klassenattribute werden wie üblich verwendet.

Die genannten polymorphen Methoden werden wieder überschrieben [S.13].

3.1.5 Klasse CContract

Der Bankvertrag erweitert das allgemeine Bankdokument in eine andere Richtung. Es erbt demzufolge von CBankDocument die Attribute und Methoden, wobei die polymorphen Methoden überschrieben werden [S.13]. Die Klasse gehört zum package bankproject.

Ähnlich wie CForm erweitert diese Klasse das allgemeine Bankdokument um AlterationDate (CDate für Ände- rungsdatum), Proved (boolean für Prüfstatus) und Signed (boolean für Unterschriftsstatus). Anstatt dem Formality-Attribut finden wir jetzt ein Wording, das ist ein String für den Vertragstext. Zusätzlich wird ein In- teger RegistrationNumber für eine Registriernummer implementiert.

Für die in der UML-Grafik nicht (???) aufgeführten set- Methoden (setProved(), setSigned() und setWor- ding()) benötigt die Klasse wiederum eine Methode zum Anpassen des Änderungsdatums (updateAlteration- Date).

Die Methoden isClassInvariant(), equalValue(), copy() und show() aus CBankDocument werden über- schrieben [S. 13].

Abbildung in dieser Leseprobe nicht enthalten

Auszug aus Abbildung 8: UML-Diagramm Klasse CContract.java [S. 83]

Implementiert werden der Standardkonstruktor, zwei Initialisierungskonstruktoren und ein Kopierkonstruktor. Der Standardkonstruktor setzt neben den Werten des Super- konstruktors Proved und Signed auf false und die RegistrationNumber auf 0. Ein damit erzeugtes Objekt ist also zunächst nicht klasseninvariant. Der erste Initialise- rungskonstruktor ist der in der Aufgabenstellung Geforderte. Der Zweite reduziert wie- der um Proved und Signed und setzt diese automatisch auf false. Der Kopier- konstruktor erzeugt mit den Werten eines klasseninvarianten Objekts ein neues.

Ein Vertragsobjekt ist klasseninvariant, wenn alle Strings nicht leer, alle CDates klasseninvariant und die RegistrationNumber größer 0 ist.

3.1.6 Polymorphe Methoden

Im Folgenden sollen nun für die Klassen des Projekts die Vor- und Nachbedingungen für die Methoden isClassInvariant(), equalValue(), copy() und show() er- läutert werden. Diese werden dann in den erbenden Klassen überschrieben, haben aber in allen Klassen eine ähnliche Struktur. In CDate sind die Methoden zwar imple- mentiert, aber nicht polymorph, d.h. CDate gehört nicht zur polymorphen Menge (pa- ckage bankproject).

Ein Vorteil solcher Methoden ist auch, dass in überschreibenden Methoden von Unter- klassen die überschriebenen Methoden der direkten Oberklasse aufgerufen werden können (in Java mit super). Damit kann man sehr viel Quellcode einsparen bzw. wie- der verwenden.

Die Bindung der Objekte an die entsprechende polymorphe Methode (Methode aus CBankDocument, CForm, CStandingOrder oder CContract) erfolgt zur Laufzeit und hängt in erster Linie natürlich von Typ des Objektes ab, der diese Methode aufruft (Empfänger).

An dieser Stelle bedarf es nun einer großen Vorsicht, denn in der polymorphen Menge BankProject sind durch Vererbung auch die Typen „vererbt“. So ist jedes CFormObjekt auch vom Typ CBankDocument, jedes CStandingOrder-Objekt auch vom Typ CForm und damit auch ein CBankDocument und ein Vertrag (CContract) ist natürlich auch ein Bankdokument (CBankDocument).

Damit relativiert sich natürlich wieder die Bindung einer Methode an den Typ eines Ob- jektes. Die virtuelle Maschine versucht natürlich die Bindung an der untersten Klasse zu finden, z.B. wird beim Aufruf von show() mit einem CStandingOrder-Objekt die Methode der zugehörigen Klasse aufgerufen und nicht die Methode aus CForm oder CBankDocument.

Anders verhält es sich bei den polymorphen Methoden mit Parameter, hier equalValue() und copy(). Ruft ein CForm-Objekt einen Werte-Vergleich mit einem CFormObjekt auf, ist alles klar. Hier wird die Methode aus CForm aufgerufen.

Was passiert aber, wenn ein CForm-Objekt form ein Objekt bdoc vom Typ CBankDo- cument zum Wertvergleich aufruft (form.equalValue(bdoc))? Da in Java keine überladenen Methoden mit gleicher Parameteranzahl möglich sind [S. 4], ist eine Bin- dung der Methode equalValue() an die Klasse CForm nicht möglich, da hier nur Pa- rameter vom Typ CForm möglich sind. Aber in der Klasse CBankDocument ist eine Methode equalValue() implementiert, die Parameter vom Typ CBankDocument kennt. Allerdings erfolgt der Aufruf dieser Methode nur mit einem Objekt vom Typ CBankDocument. Doch ein solches ist unser CForm-Objekt form (Empfänger) durch Vererbung aber gerade. Demzufolge erfolgt der Wertevergleich in diesem Fall mit der Methode aus CBankDocument.

Wenn im Gegensatz zum gerade gezeigten Beispiel das CForm-Objekt form einen Wertevergleich mit einem CStandingOrder-Objekt sord aufruft, erfolgt die Bindung an die Methode der Klasse CForm, da das CStandingOrder-Objekt sord auch ein CForm ist.

Hier ist zu erkennen, das equalValue() die Bindung der Methode an die oberste Klasse der Vererbungshierarchie erfolgt. Dies kann man in der Datenbank z.B. dazu nutzen, alle Dokumente verschiedenen Typs eines Kunden zu suchen.

Um diese polymorphe Erscheinung bei der copy()-Methode abzufangen, muss, bevor der Kopiervorgang gestartet wird, überprüft werden, ob Empfänger und Parameter Ob- jekte der gleichen Klasse sind. Wird mit einem Objekt A (Empfänger) vom Typ einer Oberklasse ein copy() mit einem Parameter B vom Typ einer Unterklasse aufgerufen (A.copy(B)), so wird nicht kopiert. Da am Ende des Kopiervorganges auf Wertgleich- heit getestet werden soll und dieses Ergebnis (boolean) als Kopierergebnis zurückge- geben wird, muss auch hier nochmals überprüft werden, ob die beiden Objekte von derselben Klasse abstammen. Sonst kann der Polymorphieeffekt wie er für equalVa- lue() beschrieben wurde auftreten und als Ergebnis des nicht erfolgten Kopiervor- ganges erhalten wir true.

Wird in der Kopiermethode dieser Klassentest nicht vollführt, kann man eine weitere Kopiermethode deklarieren, die die Vererbung der Klassen nutzt und ein neues Doku- ment einer Oberklasse auf der Grundlage einer Unterklasse erzeugt. Dabei werden dann nur die Attribute der Oberklasse kopiert. Die ist z.B. dann sinnvoll, wenn ein neu- er Dauerauftrag oder ein neuer Vertrag eines alten Kunden angelegt werden soll. Die- se Kopiermethode ohne Klassentest wird hier jedoch nicht implementiert.

public virtual ClassInvariant(out t: Boolean)

Abbildung in dieser Leseprobe nicht enthalten

public virtual equalValue(in obj: object, out t: Boolean)

Abbildung in dieser Leseprobe nicht enthalten

public virtual copy(in obj: object, out t: Boolean)

Abbildung in dieser Leseprobe nicht enthalten

public virtual show(out str: String)

Abbildung in dieser Leseprobe nicht enthalten

3.2 Darstellung der Architektur des Programmsystems

Da die geforderten Dokumente als Klassen eines objektorientierten Softwaresystems zu realisieren sind, gibt es zwischen den Klassen verschiedene Beziehungen der objektorientierten Programmierung [S. 4]. Diese Beziehungen sollen im Folgenden genauer analysiert bzw. dargestellt werden.

Zwischen den Klassen gibt es neben den öffentlichen Vererbungsbeziehungen (inherit, is_a) auch die so genannten Benutzungsbeziehungen (use) [S. 5]. Die folgende Abbildung in der UML (erzeugt mit Jumli V. 1.2) zeigt diese Beziehungen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: UML-Diagramm zum Softwaresystem BankProject

Das vorliegende System ist ein objektorientiertes System mit (polymorphen) Verer- bungsbeziehungen und Benutzungsbeziehungen. Die Menge der Komponenten des Systems bilden die Klassen CDate, CBankDocument, CForm, CStandingOrder und CContract, wobei die letzten vier Klassen eine polymorphe Menge (polymorphic set) [S. 6] bilden.

Aus diesem Grund wurden diese in dem Package bankproject [S.81] zusammengefasst und CDate in ein eigenes Package date [S. 80] gesteckt.

Die Menge der Konnektoren (Benutzungsbeziehungen) bilden wie gesagt die Beziehungen use und inherit (extends).

Aus der UML-Grafik lassen sich somit die folgende Menge der Verbindungen bilden:

- CBankDocument uses CDate (DateOfFoundation),

- CForm uses CDate (AlterationDate),
- CContract uses CDate (AlterationDate),
- CForm extends CBankDocument,
- CStandingOrder extends CForm,
- CContract extends CBankDocument,

Die Klasse CBankDocument stellt wie bereits erwähnt die Basisklasse der Dokumen- tenhierarchie dar. Die am Weitesten von dieser abgeleiteten Klasse ist CStandingOr- der, welche CForm erweitert und somit auch von CBankDocument erbt. Einen weiteren Zweig der Vererbung vom Basisdokument bildet CContract.

CDate wird von den Klassen CBankDocument, CForm und CContract importiert. Die Klasse CStandingOrder importiert CDate nicht, da sie keine eigene Instanzvariable vom Typ CDate besitzt, sondern auf die CDates DateOfFoundation und Alteration über Vererbung zugreifen kann.

Zu Polymorphiebeziehungen der Klassen CBankDocument, CForm, CStandingOr- der und CContract wurden in den vorangegangen Kapiteln bereits Aussagen getrof- fen. Hier sein nur noch erwähnt, dass die Methoden isClassInvariant(), equal- Value(), copy() und show() die polymorphen Methoden des Systems darstellen. Diese werden in der Reihenfolge der Vererbung überschrieben. Auf die Methode der direkten Oberklasse kann innerhalb der Methode durch den super-Aufruf angespro- chen werden.

Ursprünglich sollte auch noch die polymorphe Methode equals() implementiert wer- den. Eine solche Methode wird aber von Java bereitgestellt. Diese vergleicht zwei Ob- jekte auf Identität mittels des zugehörigen Hashcodes der Objekte [Ull01 S. 458]. Wenn zwei Zeigerobjekte auf das gleiche Objekt zeigen, so ist der Hashcode des Objektes für beide Zeiger gleich.

Durch den Aufbau des Programmsystems lassen sich sehr schnell neue Bankdokumente implementieren, die die vorhandenen zum Teil erweitern. Des Weiteren bildet das System eine gute Grundlage für die zweite Etappe des Praktikums, in der es um die Persistenzhaltung der Dokumente in einer Mappe (CFolder) und die Erstellung einer grafischen Benutzeroberfläche (GUI) geht.

4 Programmtechnische Realisierung des Lösungsmodells

4.1 Namenskonventionen

Im folgenden Abschnitt werde ich auf die verwendeten Bezeichner für Variablen und Methoden eingehen. Zunächst sollen die für diese Arbeit verwendeten Namenskonventionen beschrieben werden. Im Anschluss gehe ich dann auf Namensänderungen gegenüber der CEDL-Vorlage ein.

Namenskonventionen

Die in der CEDL [S. 26] verwendete Syntax wurde in erster Linie an die verwendete Programmiersprache Java und den Konventionen zur Verwendung von Namen in Java angepasst.

Für die Verwendung von Bezeichnern in Java gelten folgende Regeln:

-Bezeichner benennen Pakete, Klassen, Konstanten, Variablen und Methoden in ih- ren Java-Programmen.
-Bezeichner können beliebig lang sein, wobei immer der gesamte Bezeichner zur Unterscheidung mit anderen herangezogen wird (alle Stellen sind signifikant).
- Bezeichner müssen mit 'a’ .. 'z’, 'A’ .. 'Z’, '_’ oder $' beginnen und können dann be- liebig fortgesetzt werden (ohne Leer- und Sonderzeichen). Java unterscheidet zwi- schen Groß- und Kleinschreibung.
- Bezeichner müssen in ihrem Gültigkeitsbereich eindeutig sein.

International haben sich folgende Namenskonventionen für Bezeichner in Java durch- gesetzt:

Abbildung in dieser Leseprobe nicht enthalten

Ich habe hier nur solche Konventionen beschrieben, die für das System von Bedeutung sind. Ich lege sehr großen Wert auf ausgeschriebene Namen, um so ein schnelleres Verständnis des Quelltextes zu ermöglichen ("selbstsprechende Bezeichner"). Da Java zwischen Groß- und Kleinschreibung der Bezeichner unterscheidet, verwende ich die als Methodenvariablen stets kleingeschriebene Klassenattribute (Klassenvariable Author à Methodenvariable author). Damit sind die Eindeutigkeit der Namen und ein schnelles Verständnis des Quelltextes gewahrt.

Die Sprache der Bezeichner ist, wie international üblich, englisch. Um diesen Standard fortzusetzen werden auch die Kommentare im Quelltext in englischer Sprache verfasst. An dieser Stelle möchte ich darum bitten, mir mein "very bad english" zu entschuldigen. Die Dokumentation des Softwaresystems erfolgt ebenso nach einem Standard, der JavaDoc-Syntax [Ull01 S. 1150], so dass mit Hilfe von JavaDoc eine HTMLDokumentation der Klassen möglich wird [CD:\JavaDoc \index.html].

Namensänderungen

Um diese Konventionen für Bezeichner in Java zu berücksichtigen, entschloss ich mich für einige Änderungen der Namen gegenüber der Aufgabenstellung [S. 26].

Die auf der Seite 26 dargestellten Prozedurparameter werden an die eben vorgestellten Konventionen angepasst. Das heißt, in den Methoden werden ausgeschriebene Parameternamen verwendet, die an die Namen der Klassenattribute angelehnt sind. Die Beschreibungen der einzelnen Parameternamen kann man in der Dokumentation des Quelltextes nachlesen.

Die Methode ClassInvariant() wird ebenfalls angepasst und lautet nun isClassInvariant(). Die Bedeutung der Methode bleibt damit erhalten.

Die Methoden EqualValue(), Copy() und Show() werden mit einem kleinen Buchstaben begonnen (equalValue(), copy() und show()). Der Inhalt der Methoden wird dadurch nicht geändert. Ebenso beginnen alle get- und set-Methoden mit kleinen Buchstaben, gefolgt vom Bezeichner der geforderten bzw. zu ändernden Klassenattribute (z.B. setAuthor(), getAuthor()).

4.2 Realisierungskonzeption

Ich implementiere das Softwaresystem, wie bereits erwähnt, in der objektorientierten Programmiersprache Java von Sun Microssystems, da ich darin die meisten Erfahrungen habe. Weitere Eigenschaften der Sprache sind: einfach zu erlernen, stabil, leistungsfähig, plattformunabhängig, thread-fähig und portabel [Her00 S.4].

Die Entwicklungsumgebung des Projektes ist Java(TM) 2 SDK, Standard Edition 1.4.1_01 (www.java.sun.com). Somit stand die im SDK integrierte Klassenbibliothek von Java zur Verfügung. Des Weiteren wurde für die Testumgebung das Package JU- nit in der Version 3.8.1 verwendet (www.junit.org), diese muss zum Testen des System in den Classpath eingebunden (set classpath=%classpath%; c:\pfad\zu\ junit\ junit.jar) oder im Projekt des JBuilders als benötigte Klassenbibliothek eingetragen werden.

Die Entwicklungsoberfläche (Plattform) war in erster Linie der Borland JBuilder 7 Per- sonal Edition, der kostenlos zu erhalten ist (www.borland.de/jbuilder). Neben diesem nutzte ich die auf 30 Tage befristete Testversion der Borland JBuilder 8 Enterprise Tri- al, u.a. für die Erstellung der UML-Grafiken und die HTML-Dokumentation. Die Klassen wurden mit JBuilder und dem Compiler des JBuilder "Borland Make" kompiliert, dabei wurden in der Implementation keine compiler-spezifischen Eigenheiten verwendet, so dass jeder mit dem SDK kompatible Compiler mit dem Quellcode zurecht kommen müsste.

Da es in der Software Unterschiede zwischen den einzelnen Versionen geben kann, liste ich hier die Verwendeten nochmals auf:

Abbildung in dieser Leseprobe nicht enthalten

Damit ergeben sich für die Umsetzung des Softwaresystems in Java verschiedene Konsequenzen. Auf einige dieser Konsequenzen wurde bereits, da es an den entsprechenden Stellen notwendig war, eingegangen.

Java ist eine Programmiersprache die aufgrund ihrer virtuellen Maschine nur mit virtu- ellen Methoden arbeitet. Um dies zu verhindern, kann man diese als final deklarie- ren, damit sind Variablen nicht überschreibbar (z.B. Konstanten), Methoden nicht mehr veränderbar und finale Klassen können nicht vererbt werden. Im Projekt wird aber nicht mit final gearbeitet, so dass alle Klassen weiter vererbbar sind und die in ihnen imp- lementierten Methoden sind virtuell, d.h. in erbenden Klassen grundsätzlich überschreibbar.

Da Java ein automatisches Speichermanagement besitzt, brauchen keine Destruktoren implementiert werden, dies übernimmt der Garbage Collector (GC).

[...]