Inhaltsverzeichnis

1  Aufgabenstellung.  1

2  Erläuterung der Aufgabenstellung.  2

2.1  Bezug zur Lehrveranstaltung  2

2.2  Lesbarkeit und Aufbau der Dokumentation  2

2.3  Interpretation der Praktikumsaufgabe.  3

2.4  Objektorientierung und Polymorphie.  4

3  Darstellung des Lösungsmodells  6

3.1  Darstellung der Lösungsidee  7

3.1.1  Klasse CDate.  8

3.1.2  Klasse CBankDocument.  9

3.1.3  Klasse CForm  10

3.1.4  Klasse CStandingOrder.  11

3.1.5  Klasse CContract.  12

3.1.6  Polymorphe Methoden  13

3.2  Darstellung der Architektur des Programmsystems.  16

4  Programmtechnische Realisierung des Lösungsmodells.  18

4.1  Namenskonventionen.  18

4.2  Realisierungskonzeption  20

4.3  Testplan und Testergebnisse.  22

5  Wertung des erreichten Ergebnisses.  25

A  Anhang  26

A.1  Anhang zur Aufgabenstellung.  26

A.2  Die Quelltexte des Praktikums.  34

A.2.1  Quelltexte package date  34

A.2.2  Quelltexte package bankproject.  39

A.2.3  Quelltexte package bankprojecttest.  54

A.3  Abbildungsverzeichnis.  80

A.3.1  UML package date.  80

A.3.2  UML package bankproject.  81

A.3.3  UML package bankprojecttest.  84

A.4  Literaturverzeichnis  89

A  5 Eidesstattliche Erklärung  90

Aufgabenstellung 1

1 Aufgabenstellung

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

Erläuterung der Aufgabenstellung 2

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 htigen 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 Spezifikation des Softwareprodukts und beinhaltet Anforderungen an die Struktur des Softwaresystems und qualitätssichernde Bestandteile. Der Nachweis der geforderten Qualitä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 angepasst. Als Standardschrift wurde Arial in Größe 11 und einem Zeilenabstand von 15 Punkten, als Absatzabstand weitere 6 Punkte verwendet. In der Praktikumsdokumentation 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 ob-jektorientierten Programmiersprache Java verwendet. Sollte ein Begriff eingeführt bzw. nicht üblich verwendet werden, so wird in der Dokumentation an der betreffenden Stel- le darauf eingegangen.

Erläuterung der Aufgabenstellung 3

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 darstellt. 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 vereinbarten 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 gegenüber der Aufgabenstellung, zusätzlich eingeführte Klassen bzw. Vor- und Nachbedingungen 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 (CBank- Document), 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 die- se auf die zweite Etappe des Praktikums im Sommersemester verschoben.

Erläuterung der Aufgabenstellung 4

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

In den Beschreibungen sind die geforderten Klassenattribute und Methodendeklarationen 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 wegen der nicht geforderten Persistenzhaltung (EqualKey() und KeyOf()) und zum Weiteren aufgrund meiner Wahl der Entwicklungsumgebung Java, in welcher eine Methode equal() für die Identität von Objekten durch equals() bereits gegeben ist.

Da Java über ein automatisches Speichermanagement verfügt, kommt den Destruktoren 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 Abständen findet automatisch eine Speicherbereinigung (garbage collection) statt. Aus diesem Grund entfallen weiterhin die in der Aufgabenstellung beschriebenen Methoden -CBankDocument(), -CForm(), -CStandingOrder() und -CContract().

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 erzeugt 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 (pri- vat,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 Instanziierungsbeziehung (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.

Erläuterung der Aufgabenstellung 5

Eine weitere Beziehung ist die Nachrichtenaustauschbeziehung, d.h. Klassen und I nstanzen 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 Vererbungsbeziehung (inherit, is_a, extends) bedeutet, dass die Unterklasse alle I nstanzvariablen und Methoden ihrer Oberklasse erbt, was eine Möglichkeit zur Wiederverwendung bietet. In Java kann eine Klasse durch das Schlüsselwort extends eine (Ober-)Klasse erweitern. Dabei werden alle sichtbaren (public und protected) Eigenschaften der Oberklasse auf die Unterklasse übertragen. In Java ist auf direktem Weg nur die Einfachvererbung erlaubt, d.h. eine Klasse kann lediglich eine andere erweitern [Ull01 S. 255f]. Somit werden Klassen in einer Vererbungshierarchie geordnet. Andere Programmiersprachen bieten zusätzlich noch Mehrfachvererbung bzw. wiederholte 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. Dabei kann eine solche Methode in der erbenden Klasse eine andere Methodendeklaration 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 überschreibt die Methode der Oberklasse. Wird jedoch ein Empfänger der Oberklasse angesprochen, 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 Methoden 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üchgabewertes 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 (implizite Beziehung). Dazu muss in der Klasse A die Klasse B zunächst importiert werden. Dies geschieht in Java durch das Schlüsselwort import [Hor02 S. 135]. In diesem Zusammenhang sein noch die Möglichkeit erwähnt, thematisch zusammengehöri- ge Klasse in Gruppen, Pakete genannt, zu ordnen (packages) [Ull01 S. 308f].

Darstellung des Lösungsmodells 6

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 Instanzvariablen 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 Ma ppe erstellt werden, die eine Vielzahl verschiedener Dokumententypen verwalten bzw. persistent speichern kann. Dann erlaubt die Mengenklasse CFolder die Verwaltung von Instanzen von CBankDocument, CForm, CStandingOrder und CContract, welche die gemeinsame Wurzel CBankDocument haben. Diesen Sac hverhalt bezeichnen wir als polymorphe Menge (polymorphic set). Ein Vorteil dieser Organisation 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 referenziert 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 Dokumentenhierarchie 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ültig 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, jedes Dokument entsprechend seines Typs mit Show() auszugeben [S. 5].

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

Darstellung des Lösungsmodells 7

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. Nicht-polymorphe 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 CEDL-Beschreibung 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 Datums- und Zeitangaben der Erstellung (DateOfFoundation in CBankDocument) oder der Änderung (AlterationDate alle außer CBankDocument) eines Bankdokuments benötigt. Die Anpassung der Datumsattribute erfolgt vom System automatisch, so dass weder in den Konstruktoren bzw. in den Methoden eine manuelle Anpassung 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 automatisch 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 get- Methoden für Klassenattribute vertraut sind.

Darstellung des Lösungsmodells 8

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 HTML-Dokumentation 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 übergeben. Bei dem ersten sind das nur die Datumsangaben (die Zeitattribute werden generiert) und bei zweiten werden alle sechs Attribute parametrisiert.

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

Darstellung des Lösungsmodells 9

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 S chaltjahr 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 CDate-Objekts auf das aktuelle Objekt übergeben werden. Dazu wird geprüft, ob es überhaupt 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 e ine 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- gebankproject). 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), DateOfFoundation ( CDate für das Erstellungsdatum), Title (String für den Titel des Dokuments) und Key (String für einen Registrierungsschlüssel). Somit geht CBankDocument eine Benutzungsbeziehung mit der Klasse CDate ein [S. 5].

Da nicht vorgesehen ist, diese Attribute zu einem späteren

Zeitpunkt zu ändern, sind keine set-Methoden für die Klassenvariablen 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 Erstellungsdatum initialisiert wird und der somit keine Klasseninvariante (kein gültiges Dokument) darstellt, ein Initialiserungskonstruktor, in dem Autor, Title und Key mit den übergebenen Parametern und das Erstellungsdatum automatisch initialisiert werden

Darstellung des Lösungsmodells 10

(nur klasseninvariant wenn Strings nicht leer) und der Kopierkonstruktor, der mit Hilfe der copy()-Methode die Werte eines klasseninvarianten Objektes vom Typ CBank-Document auf das Neue kopiert (auch das Erstellungsdatum).

Die polymorphen Methoden isClassInvariant(), equalValue(), copy() und show() tauchen 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 (boo- lean fürden Unterschriftszustand).

Das Formular dient als Erweiterung für weitere Bankdo-

kumente, 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 gegebenen Konstruktoren um einen erweitert.

Der Standardkonstruktor ruft den Standardkonstruktor

der Elternklasse auf (Initialisierung von DateOfFoundation) und initialisiert seinerseits Proved und Signed.

Da alle anderen Klassenvariablen noch nicht initialisiert wurden, entsteht ein CForm-Objekt, 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-

Darstellung des Lösungsmodells 11

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 updateAlterationDate() (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 d en 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.

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 dekla- rierten Klassenattribute werden wie üblich verwendet.

Darstellung des Lösungsmodells 12

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 CBank-Document die Attribute und Methoden, wobei die poly-morphen 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 Änderungsdatum), 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 Integer 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 überschrieben [S. 13].

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 wieder 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.

Darstellung des Lösungsmodells 13

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() erläutert werden. Diese werden dann in den erbenden Klassen überschrieben, haben aber in allen Klassen eine ähnliche Struktur. In CDate sind die Methoden zwar implementiert, aber nicht polymorph, d.h. CDate gehört nicht zur polymorphen Menge (pa- ckagebankproject).

Ein Vorteil solcher Methoden ist auch, dass in überschreibenden Methoden von Unterklassen die überschriebenen Methoden der direkten Oberklasse aufgerufen werden können (in Java mit super). Damit kann man sehr viel Quellcode einsparen bzw. wieder 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 CForm- Objektauch 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 Objektes. 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 CForm- Objektauf, ist alles klar. Hier wird die Methode aus CForm aufgerufen.

Was passiert aber, wenn ein CForm-Objekt form ein Objekt bdoc vom Typ CBankDocument zum Wertvergleich aufruft (form.equalValue(bdoc))? Da in Java keine überladenen Methoden mit gleicher Parameteranzahl möglich sind [S. 4], ist eine Bindung der Methode equalValue() an die Klasse CForm nicht möglich, da hier nur Parameter 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.

Darstellung des Lösungsmodells 14

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 Objekte 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 Wertgleichheit getestet werden soll und dieses Ergebnis (boolean) als Kopierergebnis zurückgegeben wird, muss auch hier nochmals überprüft werden, ob die beiden Objekte von derselben Klasse abstammen. Sonst kann der Polymorphieeffekt wie er für equalValue() beschrieben wurde auftreten und als Ergebnis des nicht erfolgten Kopiervorganges 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 Dokument 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 neuer Dauerauftrag oder ein neuer Vertrag eines alten Kunden angelegt werden soll. Diese Kopiermethode ohne Klassentest wird hier jedoch nicht implementiert.

public virtual ClassInvariant(out t: Boolean)

* Diese Methode überprüft, ob das aktuelle Objekt mit * gültigen Werten belegt ist. Ist dies der Fall, ist das * Objekt gültig oder klasseninvariant. * Ist ein Objekt klasseninvariant, wird "TRUE" zurückgegeben. * Die gültigen Werte für die einzelnen Objekte sind in den Aus* führungen der einzelnen Klassen oder in den Kommentaren im Quell* text nachzulesen.

* Die Bindung erfolgt an den Typ des Empfängers. * Parameter: * keine; * Rückgabe: * Gibt "TRUE" zurück, wenn die Klassenattribute gültige * Werte besitzen. * Gibt auch "FALSE" zurück, wenn einer der Klassenattribute * noch nicht initialisiert ist (z.B. durch Standardkonstruktor). * Vorbedingungen: * keine; * Nachbedingungen: * keine;

public virtual equalValue(in obj: object, out t: Boolean) * Überprüft, ob die Klassenattribute des aktuellen Objektes * die gleichen Werte wie die Attribute eines zweiten Objektes * haben. Test auf Identität (Referenz- oder Adressgleichheit) * erfolgt mit equals().

* Subklassen können diese Methode mit super-Aufruf nutzen, * wenn sie überschrieben werden.

* Bei dem Aufruf der Methode mit typverschiedenen Objekten der * polymorphen Menge BankProject, erfolgt die Bindung jeweils * an den Typ der beiden Objekte, der in der Hierarchie weiter * oben steht.

Darstellung des Lösungsmodells 15

* Dabei werden also nur die Attribute verglichen, die in der * obersten Klasse der beiden Objekte enthalten sind. * Parameter: * obj - Referenz auf das zu vergleichende Objekt, * Rückgabe: * Gibt "TRUE" zurück, wenn die Attribute der in der * obersten Klasse enthaltenen Attribute übereinstimmen, * sonst "FALSE". * Vorbedingungen: * Liefert bereits equals "TRUE", so liefert auch equalValue() * "TRUE"; * Nachbedingungen: * keine

public virtual copy(in obj: object, out t: Boolean) * Kopiert den Inhalt des übergebenen Dokuments obj in das * in das aktuelle Dokument, das die Methode aufruft * (Empfänger). Allerdings wird nur kopiert, wenn * (1) obj vom selben Typ (Klasse) ist, wie das aktuelle * Objekt (Empfänger) ist,

* (2) obj ein klasseninvariantes Objekt seiner Klasse ist, * (3) die beiden Objekte nicht schon gleich sind, * (4) und die copy()-Methode der Oberklasse (super.copy()) * "TRUE" liefert.

* Das Änderungsdatum in CForm und CContract wird mitkopiert. * Parameter: * obj - Referenz auf das zu vergleichende Objekt, * Rückgabe: * Gibt "TRUE" zurück, wenn erfolgreich kopiert wurde, * sonst "FALSE", * Vorbedingungen: * keine; * Nachbedingungen: * Liefert copy()"TRUE", so sind beiden Objekte wertgleich, d.h. * equalValue() liefert "TRUE".

public virtual show(out str: String)

* Gibt die Inhalte der Dokumente als formatierten String * zurück. * Parameter: * keine, * Rückgabe: * String str, * Vorbedingungen: * keine; * Nachbedingungen: * Die Instanzvariablen wurden als String übergeben.

Darstellung des Lösungsmodells 16

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 ob-jektorientierten Programmierung [S. 4]. Diese Beziehungen sollen im Folgenden genauer analysiert bzw. dargestellt werden.

Zwischen den Klassen gibt es neben den öffentlichen Vererbungsbeziehungen (inhe- rit,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:

Das vorliegende System ist ein objektorientiertes System mit (polymorphen) Vererbungsbeziehungen 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-

Darstellung des Lösungsmodells 17

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, CStandingOrder und CContract wurden in den vorangegangen Kapiteln bereits Aussagen getroffen. 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 angesprochen werden.

Ursprünglich sollte auch noch die polymorphe Methode equals() implementiert werden. Eine solche Methode wird aber von Java bereitgestellt. Diese vergleicht zwei Objekte 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 ei- ner grafischen Benutzeroberfläche (GUI) geht.