Persistente Verwaltung der Daten einer Dokumentenmappe (Teil 2)

Inhaltsverzeichnis

1 Aufgabenstellung

2 Erläuterung der Aufgabenstellung
2.1 Interpretation der Praktikumsaufgabe
2.2 Lesbarkeit und Aufbau der Dokumentation
2.3 Bezug zur Lehrveranstaltung
2.3.1 Iterator
2.3.2 Persistenzhaltung
2.3.3 MVC-Konzept
2.3.4 Grafische Benutzerschnittstellen (GUI)
2.3.5 Nutzung von Klassenbibliotheken

3 Darstellung des Lösungsmodells
3.1 Darstellung der Lösungsidee
3.1.1 Iteratorklasse CFolder
3.1.2 Benutzungsszenarien und Dialogansichten
3.1.3 Anforderung an Klassenbibliotheken zur Realisierung des MVC-Konzepts..
3.1.4 Anforderung an Klassenbibliotheken zur Realisierung der Persistenz
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 gse2.model
A.2.2 Quelltexte package gse2.view
A.2.3 Quelltexte package gse2.controller
A.2.4 Quelltexte package gse2.test
A.3 Abbildungsverzeichnis
A.3.1 UML package gse2.model
A.3.2 UML package gse2.model
A.3.3 UML package gse2.view
A.3.4 UML package gse2.controller
A.3.5 UML package gse2.test
A.4 Literaturverzeichnis
A.5 Eidesstattliche Erklärung

1 Aufgabenstellung

Universität Potsdam Institut für Informatik Professur Software Engineering Prof. Dr. Erika Horn

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

Entwickeln Sie eine objektorientierte Lösung für die Problemstellung "persistente Verwaltung der Daten einer Dokumentenmappe" in den Programmiersprachen Object Pascal, 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. 38].

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),
2. Etappe: Implementation aller Klassen, einschließlich Persistenzhaltung und grafischer Benutzeroberfläche (Leistung des Sommersemesters Æ Gegenstand dieser Praktikumsdokumentation).

Für jede Etappe ist eine Praktikumsdokumentation zu erarbeiten.

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

2 Erläuterung der Aufgabenstellung

2.1 Interpretation der Praktikumsaufgabe

Ziel der Praktikumsaufgabe ist die Entwicklung eines Softwaresystems für die persistente Verwaltung der Daten einer Dokumentenmappe. Dabei ist die Problemstellung der Verwaltung verschiedener Formulare an das Bankgewerbe angelehnt.

Aber nicht nur in diesem Sektor kommt der systematischen Informationsverarbeitung und -speicherung aufgrund der stark zunehmenden Datenströme bzw. Datenbestände eine immer größere Bedeutung zu. Neben der papiergebundenen Verarbeitung nutzen Unternehmen in zunehmendem Maße die elektronische Verarbeitung und Speiche- rung.

Das zu erstellende Softwaresystem kann jedoch nur Modellcharakter besitzen, da bei weitem nicht alle Aspekte einer „Banksoftware“ berücksichtigt werden können. Die Vereinfachung besteht dabei aus der Reduzierung einer solchen Software auf das, was für die Bearbeitung der Praktikumsaufgabe von Bedeutung ist. Diese kann in folgende Teile zerlegt werden:

1. polymorphe Menge von Softwarebauelementen (CBankDocument, CForm, CStandingOrder und CContract),
2. Mengenverwaltung (CFolder),
3. Persistenzhaltung der Menge und
4. grafische Benutzeroberfläche (GUI).

Mit der Aufgabenstellung wurde zu jedem Teilsystem 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ängigen Mit- teln [Hor02 S. 54].

In der ersten Etappe des Praktikums (WS 2002/2003) entstand bereits die polymorphe Menge, zur Verwaltung von Instanzen verschiedener Dokumente, die die gemeinsame Wurzelklasse CBankDocument haben. Die vollständige Darstellung zu diesen Soft- warebauelementen befindet sich in der entsprechenden Praktikumsdokumentation [Hel03].

Vererbungsbeziehungen, Gleichheitsrelationen, Vererbung und Polymorphie sind damit nicht mehr Gegenstand dieser Arbeit. Notwendige Erweiterungen und Änderungen in der polymorphen Menge werden dargestellt und erläutert.

Mit der vorliegenden Arbeit werden die Punkte 2 bis 4 erarbeitet und somit ein lauffähi- ges Softwaresystem zum Erstellen, Ändern, Löschen und Speichern (Objektpersistenz) von Instanzen der bereits vorliegenden Menge. Dazu wird eine Iterator klasse (CFol- der) für die Mengenverwaltung geschaffen. Des Weiteren sind abhängig von Benut- zungsszenarien grafische Benutzerschnittstellen und Ereignisbehandlungen (Event Handling) zu schaffen. Die kursiv dargestellten Begriffe stellen Konzepte (Patterns und Frameworks) der Wiederverwendung von Wissen dar [Hor02, S. 200f].

Zur Qualitätssicherung sind Anforderungen an die Softwarebauelemente gegeben [Hor97, S. 6-1] [Hel03, S. 2]. Für die analytische Qualitätssicherung sind Vor- und Nachbedingungen für Methoden oder Sequenzen auf Instanzen zu formulieren und in einer Testumgebung zu implementieren, die eine Prüfung der definierten Bedingungen ermöglicht. Bereits im ersten Teil der Arbeit wurde dazu die Testumgebung JUnit (www.junit.org) für Java verwendet. Die dort implementierten Tests wurden wieder aufgenommen bzw. an neue Bedingungen bei Änderung (z.B. equalValue()) oder Hinzunahme (getKey() oder keyOf()) von Methoden angepasst. Solche automati- sierten Tests werden jedoch nur für die polymorphe Menge und die Mengenverwaltung durchgeführt.

Für einen automatisierten Test der Oberfläche müssen komplexe Hilfsmittel eingesetzt werden, die nicht Gegenstand der Vorlesung waren und auch nicht Gegenstand dieser Arbeit sind. Hier können nur die verschiedenen Szenarien „durchgespielt“ werden, um zu prüfen, ob die vordefinierten Ereignisse auch ausgelöst werden.

Diese Praktikumsarbeit ist also eine Fortführung der Arbeit vom vorhergehenden Semester. Somit gelten die in der dazugehörenden Praktikumsdokumentation [Hel03] dargestellten Ausführungen.

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. Des Weiteren halte ich mich bei der Namensvergabe für Bezeichner und Methoden an die in der ersten Praktikumsdokumentation unter 4.1 beschriebenen Konventionen [Hel03, S. 18f].

Literaturangaben im Text werden mit eckigen Klammern unter Angabe der Quelle und Seitenzahlen gegeben, z.B. [Quelle S.1]. Die Quelltexte im Anhang [S. 46] werden mit Hilfe des Borland JBuilders 9 Enterprise Trial in Standardschrift mit Syntax und in Far- be 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 9 Enterprise Trial erstellt. Zu beachten ist dabei, dass der UML- Browser des JBuilders standardgemäße get- und set- Methoden im Diagramm nicht 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 ver- einbarten Einschränkungen dargestellt bzw. wiedergegeben. Des Weiteren wird auf Ite- ratoren, das MVC-Konzept, die Persistenzhaltung, auf grafische Benutzerschnittstellen und auf die Wiederverwendung von Klassenbibliotheken in der Softwarenetwicklung eingegangen.

Aus diesem Gliederungspunkt heraus wird im 3. Abschnitt der Dokumentation ein Lö- sungsmodell für die Aufgabe entworfen. Hier werden Benutzerszenarien und daraus Dialogansichten entworfen. Des Weiteren werden Anforderungen an die zu verwen- denden Klassenbibliotheken für die Persistenz, das MVC-Konzept und die Mengenhal- tung formuliert.

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. 46]. Es werden eine Teststrategie und ein Testplan entworfen, mit dem ein protokollierter Test durchgeführt wird.

Am Schluss der Dokumentation [S. 37] 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 der Lösung verbessert werden kann.

2.3 Bezug zur Lehrveranstaltung

Die vorgestellte Praktikumsaufgabe in der zweiten Etappe schließt an die von Prof. Dr. E. Horn gehaltene Vorlesung „Grundlagen der Softwareentwicklung II“ für Lehramts- studenten im vierten Semester (SS 2003) des Erweiterungsstudiums Informatik an der Universität Potsdam an. Diese Lehrveranstaltung vermittelte im zweiten Teil Anforde- rungen an objektorientierte Architekturen aus Sicht der Wiederverwendung (z.B. Per- sistenzhaltung, Polymorphe Mengen) und eine Einführung in die Grundideen der Spra- che Java.

Die Vorlesung im ersten und zweiten Semester der Erweiterungsstudiums ging im Wesentlichen auf die Konzepte [Hor02, S. 200f] Object Construction, Polymorphic Set, Iterator, Persistence Management und Root Class ein.

Jedoch wurden neben den polymorphen Mengen auch die Schlüsseleigenschaften erst im zweiten Semester behandelt, während diese Inhalte aber bereits im ersten Beleg abverlangt wurden.

Dagegen nicht besprochen wurde die Ausnahmebehandlung (Exception Handling), Applikationsrahmen (Application Framework), Grafische Benutzerschnittstellen (Graphical User Interface). Diese Konzepte der Wiederverwendung werden jedoch gerade für die zweite Etappe der Praktikumsarbeit benötigt (Framework und GUI).

2.3.1 Iterator

Iteratoren „durchmustern“ die Objektmenge und wenden dann (zum Teil polymorphe) Methoden auf diese an. Solche Methoden wurden bereits in der ersten Etappe implementiert (isClassInvariant(), equalValue(), copy() und show()).Solche Iteratoren übernehmen den Durchlauf durch eine Objektmenge (hier verschiedene Bankdokumente) und die Versendung von Nachrichten zur Ausführung von polymorphen Methoden der Objekte [Hor03, S. 1-68], [Hor02, S. 226].

Es gibt zwei Arten von Architekturlösungen von Iteratoren:

Iteratoren 1. Art: Die Mengenklassen werden um Iteratormethoden erweitert, welche dann auf jedes Element der Menge, das einer festgelegten Typdefini- tion genügt, die Operation ausführt.

Iteratoren 2. Art: Hier werden Iteratorklassen eingeführt, welche Steuerkonstrukte und Platzhalter für Methoden enthalten. Diese Methoden werden auf der Instanzebene mit den Mengenklassen verbunden.

Das Management von Instanzen der vorliegenden polymorphen Menge erfolgt in der zweiten Etappe durch einen Iterator der 2. Art, der in CEDL vorgebenen Iteratorklasse CFolder [Hel03, S. 4].

Diese muss über Methoden für das Bereitstellen, Aktualisieren und Löschen der Mengenelemente verfügen (laut Aufgabenstellung: insert(), getFirst(), getNext(), getActual() und scratch()). Des Weiteren verfügt der Iterator über eine Variable und Methoden für einen Index und die Kardinalität.

Wichtig dabei ist auch, dass polymorphe Methoden (z.B. show() oder für die dynamische Objekterzeugung generate()) für alle von diesem Iterator referenzierbaren Mengenelemente existieren (Existenz der Schnittstellenmethoden).

Das Konzept der Iteratoren ist in den meisten Klassenbibliotheken von Entwicklungsumgebungen integriert.

2.3.2 Persistenzhaltung

Ein weiterer Schwerpunkt der Vorlesung war die Persistenzhaltung von Objekten, also das Aufheben des Zustandes von Objekten über ihre Lebensdauer im Programm hinaus [Hor02, S. 230f].

Im allgemeinen Fall liegt das Problem darin, dass die Instanzvariablen verschiedene Typen haben und somit ein unterschiedlicher Speicherbedarf für diese Typen existiert. Dazu müssen die Strukturen der Instanzen serialisiert und deserialisiert werden.

Die Serialisierung von Instanzen erfolgt dabei zum Beispiel durch die Abbildung auf Strings. Dabei müssen die Instanzbestandteile eindeutig getrennt werden, da eine De- serialisierung sonst nicht möglich ist. Für die Deserialisierung kann es auch erforderlich sein, Instanzen- und Klassennamen mit im String abzulegen bzw. nach der Wiederherstellung das Element typgerecht zu casten.

Auch dieses Konzept wird von den meisten Entwicklungsumgebungen durch Klassenbibliotheken unterstützt, wobei die Serialisierung und Deserialisierung von diesen Bibliotheken übernommen wird.

2.3.3 MVC-Konzept

Dieses Konzept war nicht Gegenstand der Vorlesung und wurde auch nicht direkt in der Aufgabenstellung gefordert. Trotzdem bietet sich dieses Konzept bei der Umsetzung der Anwendungssoftware an.

Das Konzept der Applikationsrahmen (Application Framework) umfasst vorgefertigte Klassen und Beziehungen, die auch das Grundgerüst für Anwendungsprogramme mit grafischer Benutzerschnittstelle enthalten [Hor02, S. 247f].

Bei dem vorliegenden Projekt handelt es sich um ein Softwaresystem, das aus Klassen und Instanzen besteht, die Daten des Gegenstandsbereichens verwalten (Model), aus Benutzerschnittstellen, die der Kommunikation mit dem Benutzer dienen (View), und aus Softwarebauelementen, die den Ablauf und den Zugriff zu Daten entsprechend den Benutzerangaben vermitteln (Controller).

Das Model-View-Controller-Konzept (kurz MVC-Konzept) bietet hierfür Lösungsmög- lichkeiten:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 - MVC-Konzept

Das Model ist das Abbild des Gegenstandbereichs. In unserer Dokumentenmappe umfasst das Model die Datenstrukturen für einfache Dokumente, Verträge, Formulare und Daueraufträge sowie die Mappe, in der Erstere enthalten sind. Das Modell bietet Methoden an, mit dem sich der aktuelle Zustand erfragen und ändern lässt.

Das View ist die grafische Darstellung des Models. Eine Änderung des Models führt somit zu einer Änderung des View. Dazu ist eine angepasste Repräsentation relevan- ter Datenstrukturen notwendig, was wiederum alle genannten Arten von Dokumenten sowie die Mappe sind. Somit verfügt ein Model über verschiedene Views, z.B. für ver- schiedene Bankdokumente, um jeweils bestimmte Teilaspekte optimiert darstellen zu können.

Der Controller übernimmt die Interaktion mit dem Benutzer und organisiert das Zu- sammenspiel von Model und View. Er wertet Eingaben aus und ruft Funktionen von Model und View auf. Um diese Tätigkeit durchführen zu können, muss er sowohl Zugriff auf das Model (Vornehmen von Änderungen) als auch auf das View (Anzeige der Änderungen) haben. Des Weiteren übernimmt der Controller die Persistenzhaltung des Models.

Die Application vereinigt Model, View und Controller zu einem vollwertigen Programm. Hier wird die Initialisierung, der Programmlauf und die Terminierung gehandhabt. Das Betriebssystem kommuniziert nur mit der Application.

Aus der Abbildung 1 sind mögliche Importbeziehungen und der Informationsaustausch zu entnehmen. Die use-Beziehungen im vorliegenden Projekt werden auch in den UML-Grafiken des Softwaresystems verdeutlicht.

Da sich die Teilsysteme des MVC-Konzepts als Objekte gestalten lassen, können sie auch objektorientiert implementiert werden.

Das MVC-Konzept trennt ganz klar die Bereiche ab. Der große Vorteil dabei ist, dass sich alle drei Teile unterschiedlich entwickeln, einsetzen und weiterentwickeln lassen.

Es kann bei umfangreichen Softwareprodukten aber zu Problemen führen [Ull01, S. 825]. View und Controller sind meist eng verbunden, so dass es zusätzlichen Schnittstellenaufwand für die Implementierung gibt. Das zweite Problem ist der erhöhte Kommunikationsaufwand zwischen Objekten. Wenn sich Ergebnisse in der Darstellung o- der dem Modell ergeben, führt dass immer über den Controller.

Es kann also Sinn machen, View und Controller zu einer Komponente zu verschmelzen, um die komplexe Interaktion zu vereinfachen. In Swing haben die Entwickler der JVC (Java Foundation Classes) diese Verschmelzung implementiert. Damit lassen sich Benutzeroberflächen einfacher programmieren. Dieses neue Modell wird anstatt MVC auch Model-View-Presenter (MVP-Pattern) genannt. Dieses Konzept wird z.B. bei der Entwicklung in Java mit Borlands JBuilder umgesetzt.

Für das vorliegende Softwaresystem wird jedoch das MVC-Konzept bevorzugt, um die klare Trennung zwischen View und Controller zu verdeutlichen.

2.3.4 Grafische Benutzerschnittstellen (GUI)

Softwareprodukte haben heute grafische Benutzerschnittstellen. Die Bildschirmoberflä- che stellt die Arbeitsfläche (desktop) dar. Das Grundelement einer Arbeitsfläche ist das Fenster.

Das Fenster ist in der OOP zunächst ein Objekt, das Attribute zur grafischen Reprä- sentation verwaltet und die Darstellung auf grafische Ausgabemedien vornimmt. Ein Fenster ist mit Eingabeereignissen (Tastatur und Maus) versehen, die zum Aufruf von Methoden führen.

Eine Fensterstruktur besteht aus typverschiedenen Elementen. Der CUA (Common User Access)-Standard (IBM 1989) definiert das Aussehen, die Anordnung und die Bennutzung grafischer Benutzeroberflächen [Hor02, S. 253]. Dieser Standard verein- heitlicht das Aussehen und die Bedienung von Applikationen, so dass jeder Benutzer diese intuitiv bedienen kann. Ausgewählte Elemente des CUA-Standards sind z.B. die beschriftetete Schaltfläche (button), das Auswahlmenü (choice), das Kontrollfeld (checkbox), der Cursor, das Interaktionsfenster (dialog), die Auswahlliste (menu).

In diesem Zusammenhang ist auch die Ereignisbehandlung (Event Handling) von gro- ßer Bedeutung. Denn auf Benutzereingaben soll die Applikation natürlich reagieren.

Für beide Konzepte GUI und Ereignisbehandlung sind in den Entwicklungsumgebungen natürlich auch wieder Klassen zur Nachnutzung vorgesehen (z.B. in Java das Abstract Windowing Toolkit (AWT) und das Swing Toolset).

2.3.5 Nutzung von Klassenbibliotheken

Klassenbibliotheken stellen Datenstrukturen, Konzepte und Algorithmen bereit, die die Umsetzung des MVC-Modells in ein lauffähiges Programm unterstützen. Sie sind vielfach getestet und erprobt, was mir einen Großteil der Qualitätssicherung erspart, so dass man sich auf das Wesentliche konzentrieren kann.

Allerdings schränken Klassenbibliotheken auch den Entwickler durch Vorgaben in seinen Möglichkeiten und seiner Flexibilität ein. Dieser Nachteil muss in Kauf genommen werden, da die Vorteile doch stark überwiegen.

Auch teilsystemübergreifende - und damit MVC-unabhängige - Konzepte werden durch Klassenbibliotheken geprägt. An erster Stelle steht dabei der Aufbau der internen Fehlererkennung und -behandlung. Darunter hat man die Sicherstellung von Invarianten und die Ausgabe von Objektzuständen zu verstehen.

Ebenso werden objektorientierte Entwurfskonzepte entscheidend beeinflusst, da viele Bibliotheken Mehrfachvererbung nicht erlauben (wie Java) und auch eigene Objekterzeugungsmechanismen anbieten und verlangen.

Ähnlich sieht es mit Typinformationen aus, die über die in Java standardmäßig eingebauten hinausgehen.

Nicht zu verachten sind die diversen Tools, die die Arbeit mit Klassenbibliotheken vereinfachen und beschleunigen, aber dadurch auch dem Programmierer Schranken auferlegen. So ist es nicht ohne Umwege möglich, mit Design-Werkzeugen entworfene Oberflächen zu portieren oder nachträglich entscheidend zu ändern.

Das Model profitiert insbesondere von vorgefertigten Containerklassen und den dazu- gehörigen Algorithmen. In der vorliegenden Problemstellung kann die Mappe CFolder auf Basis eines Vectors realisiert werden (in Java java.util.Vector). Für die Se- rialisierung sind für das Einlesen aus bzw. Schreiben in eine Datei Kommunikations- mechanismen erforderlich (in Java java.io.Serializable). Gerade das Einlesen ist zusätzlich auf die Fähigkeit einer dynamischen Objekterzeugung angewiesen.

Die konkrete Darstellung der Daten auf dem Bildschirm wird durch eine Kapselung in einem View erreicht. Dieses kann auf Klassen zurückgreifen, die Standardelemente zur Verfügung stellen, wie z.B. Schaltflächen oder Tabellenansichten (in Java java.awt und java.swing). Idealerweise kann die Klassenbibliothek derart abstrakt sein, dass dabei die verwendete Shell des Betriebssystems oder das Betriebssystem selber für die Programmierung des Views irrelevant sind.

Die Klassenbibliothek sollte den Datenaustausch zwischen den Oberflächenelementen (z.B. einem Eingabefeld) und den dazugehörigen Variablen im Programm automatisiert unterstützen.

Gerade beim Entwurf des Views spielt die Verwendung von Design-Tools eine große Rolle. Sie werden meist als Ressourcen-Editoren bezeichnet und erlauben die Umset- zung von Fenstern, Menüs, Beschleunigertasten (Hotkeys), Bildern etc.. Problematisch ist, dass diese Elemente dynamisch zur Laufzeit nur eher umständlich verändert wer- den können.

Der Controller benötigt für die Interaktion mit dem Nutzer Zugriff auf Hardware- Ressourcen (in Java java.io.*). Die Klassenbibliothek kann hier helfen, indem sie Datenfluss-Standards gewährleistet, die unabhängig von der beim Nutzer installierten Hardware sind.

Ebenso stellt sie Datenstrukturen und Klassen zur Verfügung, die die Weiterleitung von Informationen an das View und/oder das Model unterstützen. Der dazu verwendete Mechanismus wird in aller Regel vorgegeben und beruht meist auf Nachrichtenkom- munikation.

Abschließend ist auch die Application auf eine Klassenbibliothek angewiesen, um die Initialisierung, den Ablauf und die Beendigung der Teilsysteme Model, View und Controller zu gewährleisten. Dabei bedient sie sich vorgefertigter Algorithmen zur Registrierung im Betriebssystem.

Die Nutzung vorgefertigter Klassenbibliotheken beschleunigt also den Entwicklungsprozess bei Softwareprodukten. Jedoch können diese meistens nicht 1:1 eingesetzt bzw. nachgenutzt werden. Sie können jedoch bzw. müssen angepasst bzw. erweitert werden, wie die im ersten Teil implementierte Klasse CDate.

3 Darstellung des Lösungsmodells

In der Aufgabenstellung geht es um das Erstellen einer objektorientierten Applikation, wie sie im Bankwesen auftreten könnte. Dabei ist zunächst das Model um eine Iteratorklasse CFolder zu erweitern, mit welcher die Menge typverschiedener Bankdokumente verwaltet werden kann.

Im Anschluss werden das View und der Controller anhand von Benutzerszenarien und Dialogansichten erarbeitet bzw. erläutert. Des Weiteren soll der Controller Methoden zur Persistenzhaltung bereitstellen.

Für alle diese Komponenten sollen vorgefertigte Klassenbibliotheken der gewählten Entwicklungsumgebung genutzt werden. Damit ergeben sich für die Realisierung des Lösungsmodells bestimmte Anforderungen an diese Bibliotheken.

Ich werde im Folgenden nicht mehr auf die Klassen eingehen, die bereits im ersten Teil des Praktikums entstanden sind.

3.1 Darstellung der Lösungsidee

3.1.1 Iteratorklasse CFolder

Im folgenden Abschnitt wird die in der Aufgabenstel- lung beschriebene Schnittstelle CFolder beschrieben. Im Großen und Ganzen habe ich mich bei der Umset- zung an die gegebene CEDL-Beschreibung dieser Klasse [S. 38] gehalten.

Die Attribute dieser Klasse sind Cursor (Integer für das aktuelle Dokument der Dokumentmenge), Custo- merInformation (String für den Kundenname), DateOfFoundation (CDate für das Erstellungsda- tum der Mappe) und SetOfBankDocuments (Vector für die Bankdokumentmenge).

In der nachzunutzenden Klassenbibliothek Vektor wird die Menge von Bankdokumenten abgelegt. Demzufol- ge werden an diese Bibliothek verschiedene Anforde- rungen gestellt:

- Auf der Menge gibt es eine eindeutige Ordnung (laut Aufgabenstellung „… ordered set of …“).
- Die Bibliothek stellt Methoden für das Einfügen, Lö- schen, Austauschen, Suchen usw. bereit.
- Wahlfreier Zugriff auf einzelne Elemente der Menge, um ein beliebiges Element zurückgeben zu können.
- Die Elemente der Menge können verschiedene Ty- pen sein. Es muss jedoch sichergestellt werden können, dass bei einer Rückgabe, das Element wieder typgerecht gecastet werden kann.
- Da durch die Vererbung alle Elemente der Menge vom Typ CBankDocument sind, sind die polymorphen Methoden in dieser Menge auf dem CBankDocument reali- sierbar. Während der Laufzeit wird dann die entsprechende Methode dem Typ des Mengenelements gewählt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 - Klasse CFolder.java

Mit Hilfe einer solchen Klassenbibliothek lassen sich dann die geforderten Methoden auf die Menge SetOfBankDocuments realisieren. Ausführliche Beschreibungen der Methoden getCard(), insert(), getFirst(), getNext(), find(), getActu- al() und scratch() (Bezeichnungen angepasst lt. Namenskonventionen) sind im Anhang unter Quelltexte [S. 46] zu finden. Neben den geforderten Methoden auf die Menge wird eine Methode getElementAt() implementiert. Mit Hilfe dieser Methode wird das an dem übergebenden Index stehende Element zurückgegeben, falls dies möglich ist. Diese wird zum Teil von den vorhergehend genannten Methoden benutzt.

Um Seiteneffekte zu verhindern, werden die Methoden getFirst(), getNext() und getActual()gegenüber der Aufgabenstellung abgeändert. Diese sollten neben dem geforderten Bankdokument auch einen Boolean für den Erfolg der Aktion zurückgeben. „ Die Auswertung eines Ausdruckes soll einen Wert liefern und keinen Seiteneffekt. “[Gum02, S. 110]. Die geforderten Methoden verlangen jedoch zwei Rückgabewerte (ein Bankdokument und ein Boolean). Genau dieses wäre in Java aber nur über einen solchen Seiteneffekt möglich. Die Abänderung der Methoden gegenüber der Aufgabenstellung ist mit dem Quellcode zu vergleichen.

Neben diesen Methoden auf das Mengenset gibt es auch Methoden für den Vergleich zweier Mappen (equals(), equalValue(), equalKey()), für den Test auf Klasseninvarianz (isClassInvariant()) und zum Kopieren (copy()). Des Weiteren gibt es standardgemäße get- und set-Methoden für die Klassenattribute. Auch diese werden gegenüber der Aufgabenstellung um einige ergänzt. All diese werden in der Dokumentation zum Quelltext mit Vor- und Nachbedingungen beschrieben.

Als Konstruktoren stehen der Klasse der Standard-, ein Initialisierungs- und der Kopierkonstruktor zur Verfügung.

Dem Initialisierungskontruktor wird nur der Kundenname übergeben, sonst wird wie beim Standardkonstruktor das aktuelle Datum als Erstellungsdatum, das Mengeset als neuer leerer Vektor und der Cursor mit -1 initialisiert.

3.1.2 Benutzungsszenarien und Dialogansichten

Die grafische Oberfläche dient dazu, es dem Benutzer zu ermöglichen, mit dem Soft- waresystem zu interagieren. Dazu müssen Aktionen des Benutzers stets das ge- wünschte Ereignis voraussetzen. Der Aufbau einer Oberfläche lässt sich als vollständig aus der endlichen Menge von erzielbaren Ereignissen ableiten. Die Verknüpfung von Aktionen und gewünschten Ergebnissen nennt man Benutzungsszenarien.

Diese Benutzungsszenarien werden in der Aufgabenstellung nicht formuliert. Sie stecken allein in dem Begriff „Verwaltung“ der Daten einer Dokumentenmappe. Demzufolge werden Benutzerszenarien wie in ähnlichen Softwareprodukten gefordert.

Abbildung in dieser Leseprobe nicht enthalten

Ausgehend von diesen Benutzungsszenarien und der CUA können nun das Hauptfenster und verschiedene Dialogansichten entworfen werden.

Nach dem Programmstart soll der Anwender durch einen leeren und aufgeräumten virtuellen Schreibtisch begrüßt werden, auf dem bereits eine neue Mappe geöffnet wurde (New). Von hieraus ist er in der Lage, diese zu bearbeiten oder eine vorhandene Mappe zu öffnen (Open).

Die Arbeitsfläche unterteilt sich in eine Menüleiste, eine Symbolleiste und dem Arbeits- bereich.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 - leere Arbeitsoberfläche

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4 - Arbeitsoberfläche mit geöffneter

Der Inhalt der Menüleiste richtet sich nach den Benutzerszenarien und die Anordnung der Menüpunkte an verbreitete Konventionen.

Der Großteil der Szenarien wird auf drei Menüs abgebildet: File, Edit und Help.

Im Menü „File“ finden sich Funktio- nen, die auf die gesamte Mappe oder den Programmlauf abzielen. Die Be- zeichnung der einzelnen Menüpunkte erfolgt nach dem Schlüssel der Benut- zungsszenarien. Die Szenarien Open und SaveAs benötigen einen Dateina- men. Dazu wird bei Aktivierung ein sys- temüblicher Datei-Auswahl-Dialog an- gezeigt (FileChooser).

Im Menü „Edit“ werden Funktionen abgelegt, die sich auf die einzelnen Elemente der Mappe beziehen. Dazu zählen Operationen wie das Hinzufü- gen neuer Dokumente (Szenarien- schlüssel Bankdocument, Form, Standing Order und Contract), das Ändern eines ausgewählten Do- kuments (Szenarienschlüssel Change selected document) und das Lö- schen eines ausgewählten Dokuments (Szenarienschlüssel Delete selec- ted document).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5 - Menü „File“

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 - Menü „Edit“

Im Menü „Help“ ist lediglich ein Menü- punkt zur Anzeige der so genannten „About-Box“ (Benutzungsszenario A- bout) untergebracht.

Besonders häufig verwendete Funktio- nen werden in der Symbolleiste (Tool- bar) über mit Piktogrammen versehe- nen Schaltern zur Verfügung gestellt. Dabei werden den einzelnen Schaltern (Buttons) in der abgebildeten Reihen- folge folgende Szenarien zugeordnet: New, Open, Save, SaveAs, Change selected document, Delete se- lected document und About.

Beim Erzeugen und Ändern neuer Doku- mente (Szenarienschlüssel Bankdocu- ment, Form, Standing Order und Contract) müssen Attribute vom Benut- zer festgelegt werden. Um diese Werte zu erfragen, wird ein Dialog angezeigt, der bearbeitet werden muss, bevor die Abar- beitung des Programms fort fährt. Die Eingabe der Attributwerte erfolgt im Ar- beitsbereich des Dialoges. Um den Dialog abzuschließen und ein neu angelegtes Dokument abzulegen bzw. ein vorhande- nes Dokument zu ändern, bestätigt der Benutzer dies mit dem OK-Button. Soll der Vorgang abgebrochen werden, so ist „Cancel“ auszuwählen. Die Initialisierung des Dialogs ist natürlich abhängig von dem zu bearbeitendem Bankdokument.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7 - Menü „Help“

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8 - Toolbar

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9 - Dialog zum Erzeugen eines neuen Bankdocuments

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10 - Dialog zum Editieren eines vorhandenen Formulars

Je nach Typ sind mehr oder weniger Dialogfelder zum Bearbeiten vorhanden. Im betrachteten Programmsystem treten jedoch nur drei unterschiedliche Datentypen auf: Zahlen, Text und Wahrheitswerte. Für die ersten beiden Attribut-Typen wird ein einfaches Textfeld verwendet, zur Erfassung von Wahrheitswerten dient ein Kästchen („Checkbox“), das per Mausklick mit einem Haken versehen werden kann.

Einige Eigenschaften, wie Type und DateOfFoundation, werden durch das Pro- gramm vorgegeben und sind nicht änderbar. Andere sind nur bei der Neuerstellung ei- nes Dokuments editierbar und nach der Ablage nicht mehr zu ändern, z.B. Author und Title. Daher ist es notwendig, die jeweiligen Eingabemechanismen für Änderun- gen sperren zu können. In den meisten Systemen zur Erstellung von grafischen Benut- zeroberflächen wird dies durch einen Grauschleier dargestellt (siehe Abbildung 9).

Die gewählten Attribut-Werte können aus unterschiedlichen Gründen unzulässig sein. So darf es beispielsweise keine Dokumente ohne Titel geben. Nachdem der Benutzer „OK“ im Dialog gewählt hat, werden die Werte mit Hilfe der Methode isClassInva- riant() geprüft - verstoßen diese gegen eine Gültigkeitsregel wird ein weiterer mo- daler Dialog erzeugt, durch den der Benutzer über seinen Fehler informiert wird. Nach Bestätigung dieses Dialoges können die falschen Werte korrigiert werden.

Nun zurück zum Arbeitsbereich (Abbildungen 3 und 4). Dieser befindet sich unter der Toolbar und teilt sich in drei Bereiche: Eigenschaften der Mappe(Kundeninformation und Erstellungsdatum), Liste (Tabelle) aller in der Mappe vorhandenen Dokumente und einem Eigenschafts-Bereich, der die Attribute des gewählten Dokuments anzeigt.

In der Liste werden die gemeinsamen Attribute Type, Author, Title, Key und DateOfFoundation aller in der Mappe enthaltenen Dokumente in Tabellenform angezeigt. In dieser Tabelle kann man dann auch ein enthaltendes Dokument mit der Maus auswählen (Select), welches im Eigenschaftsbereich sofort angezeigt wird.

Der Eigenschaftsbereich kann den Arbeitsbereich des Dialogs zur Erstellung und Änderung nutzen, da dieser denn gleichen Aufbau hat, aber lediglich nur der Anzeige dient. Keines der Felder im Eigenschaftsbereich ist editierbar.

Sollten im Ablauf des Programms beim Öffnen, Speichern oder bei der Eingabe Fehler auftreten, öffnen sich Message- Dialoge, die über dieses Fehler informie- ren.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11 - Message-Dialog

3.1.3 Anforderung an Klassenbibliotheken zur Realisierung des MVC-Konzepts

Aus der im vorgegangenen Abschnitt beschriebenen Lösungsidee für die grafische Be- nutzeroberfläche erwächst der folgende Katalog an Anforderungen, anhand dessen ei- ne Klassenbibliothek als geeignet oder ungeeignet für die Problemstellung eingestuft werden kann.

Eine Klassenbibliothek muss zur Umsetzung der grafischen Oberfläche folgende Bauelemente bereitstellen

Abbildung in dieser Leseprobe nicht enthalten

Die Klassenbibliothek zur Umsetzung des Controllers und damit der Benutzungsszenarien muss eine Ereignisbehandlung (Event Handling) für die oben genannten Bauelemente der Oberfläche besitzen: Action Listener für Menüs und Textfelder, Selection Listener für die Tabelle und Window Adapter.

Für die Umsetzung des Models wird, wie bereits beschrieben, die Klassenbibliothek Vector genutzt. Die Anforderungen an diese wurden bereits auf [S. 10] beschrieben. Das Problem hier liegt in der Polymorphie der Mengenelemente.

3.1.4 Anforderung an Klassenbibliotheken zur Realisierung der Persistenz

Auch das Hauptproblem bei der Persistenzhaltung ist die Polymorphie der Mengenelemente. So muss es möglich sein, dass neben den Attributwerten auch zusätzliche Objektinformationen, wie seine Klassenzugehörigkeit, abgespeichert werden. Idealerweise geschieht dies nicht durch explizite Implementierung durch den Programmierer, sondern ist bereits in der Klassenbibliothek vorhanden.

So müsste es bei der Klassennachnutzung für die Persistenz (aber auch für die Mengenhaltung im Vektor) möglich sein, durch ein Casting auf die oberste Klasse CBankDocument den ursprünglichen Typ zu realisieren.

Des Weiteren müssen die abzulegenden Objekte serialisierbar sein. Unter Serialisie- rung wollen wir die Fähigkeit verstehen, ein Objekt, das im Hauptspeicher der Anwen- dung existiert, in ein Format zu konvertieren, das es erlaubt, das Objekt in eine Datei zu schreiben oder über eine Netzwerkverbindung zu transportieren. Dabei wollen wir natürlich auch den umgekehrten Weg einschließen, also das Rekonstruieren eines in serialisierter Form vorliegenden Objekts in das interne Format der laufenden Java- Maschine.

Auch hier soll eine Klasse nachgenutzt werden, die die Serialisierung übernimmt. Diese Klasse muss die implementierten Datentypen serialisieren. Das sollte aber kein Problem sein, da im Model nur Integer, Strings und Booleans vorhanden sind.

Zu Beginn jeder Datei werden dann CustomerInformation und DateOfFoundati- on geschrieben. Daran schließen sich dann die Mengenelemente der Mappe an. Die- se werden nicht als Vector abgelegt, sondern einzeln in einer Schleife als Objekte ab- gelegt. Beim Auslesen müssen die Objekte der Mappenelemente gecastet werden.

Des Weiteren sollte die Klassenbibliothek einen so genannten FileChosser zur Verfügung stellen, der das Auswählen für das Speichern und Öffnen in bestimmten Verzeichnissen übernimmt.

3.2Darstellung der Architektur des Programmsystems

Da in dem zweiten Teil die Umsetzung der Applikation mit Hilfe des MVC-Konzepts ge- fordert ist, werden die im ersten Teil [Hel03] implementierten Packages für das Model und die Testumgebung zunächst umbenannt und die zugehörenden Klassen neu zu- geordnet.

Alle entwickelten Klassen sind im Teilsystem gse2 abgelegt. Ein Teilsystem dient der logi- schen Gruppierung einer Menge von inhaltlich abgeschlossenen Softwarebauelementen. Der Name entspricht den für Teilsysteme (Packa- ges) der gewählten Programmiersprache ver- einbarten Konventionen.

Startpunkt der gesamten Anwendung ist die Klasse CApplication. Sie wurde im voran- gegangenen Text nicht behandelt, da sie bis auf die Erzeugung eines Bausteines vom Typ CMainController keine weiteren Funktio- nen wahrnimmt. Die einzelnen Teilsysteme werden nun schrittweise behandelt

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12 - Architektur im Überblick

Begonnen wird mit den Klassen des Gegenstandsbereiches. Diese sind im Teilsystem model abgelegt. Das folgende Diagramm zeigt Vererbungs- und Benutzbeziehungen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13 - Architektur des Models

Es wird deutlich, dass die Klasse CBankDocument die oberste Klasse für die polymorphe Menge der Bankdokumente ist. Alle anderen erben direkt oder indirekt von ihr. Des Weiteren nutzen/importieren alle Klassen die Datumsklasse für das Erstellungs- und das Änderungsdatum.

Die Iteratorklasse nutzt dagegen nur die Klasse CBankDocument der polymorphen Menge. Da alle anderen Dokumente durch Vererbung auch ein CBankDocument sind, reicht das so. Jedoch müssen die Methoden, welche für alle Dokumente in der Klasse CFolder verfügbar sein sollen, in der Menge polymorph implementiert sein.

Die folgende vom JBuilder erzeugte UML-Grafik verdeutlicht die Nutzung externer Java-Bibliotheken des Models.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 14 - Nutzung externer Bibliotheken des Models

Ich gehe hier aber nur auf die wichtigsten Beziehungen ein. Die Packages java.text, java.util.Date und java.util.GregorianCalendar werden nur von der Klasse CDate für die Darstellung und Erzeugung des Datums genutzt. Die Klasse java.io.Serializable wird von den Klassen CBankDocument, CDate und CFolder zur Persistenzhaltung implementiert. Die anderen Klassen des Models erben diese Serialisierbarkeit von CBankDocument. Der Iterator java.util.Iterator wird von der Klasse CFolder für das Auslesen der Mappe benutzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 15 - Architektur des View ohne Benutzungsbeziehungen

Die Klassen im Teilsystem View repräsentieren Bereiche der grafischen Oberfläche. In der gewählten Klassenbibliothek gibt es unterschiedliche Bereichstypen: Einfache Be- reiche, die ineinander eingesetzt werden können (wie JPanel) und so genannte „Top- Level-Container“. Diese können nur Elemente aufnehmen, nicht aber selbst in andere eingesetzt werden. Zu dieser Gruppe zählt der Baustein JFrame (Anwendungshaupt- fenster). Für die restlichen Bausteine des Teilsystems view ist die Vererbung jedoch Bedingung, da sie selbst in CMainView eingesetzt werden sollen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 16 - Nutzung von externen Klassenbibliotheken des View

Zur Realisierung der grafischen Oberfläche verwenden die Klassen aus dem Teilsystem view zahlreiche Elemente der Bibliothek javax.swing. Diese Komponenten realisieren sichtbare Benutzeroberflächenelemente.

Außerdem wurden eine Reihe von Klassen aus dem Teilsystem java.awt nachgenutzt, deren Aufgabenbereich das „Layout-Management“ ist. Verändert sich die Größe eines Bereiches, zum Beispiel weil der Benutzer ein Fenster vergrößert, ist es meist wünschenswert, auch die Ausrichtung der Komponenten innerhalb des Bereiches zu verändern, da nun mehr Platz für sie zur Verfügung steht. Dafür gibt es unterschiedliche Strategien, die in der gewählten Klassenbibliothek in so genannten „Layout- Managern“ gekapselt werden. In dieser Arbeit wurden zwei Layout-Manager verwendet: GridBagLayout und BorderLayout.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 17 - Architektur des Controllers mit Vererbungs- und Benutzungsbeziehungen innerhalb des gse2-packages.

Hier wird die zentrale Stellung des Controllers deutlich. Dieser verbindet das Model mit dem View und umgekehrt. Dabei übernimmt die Klasse CMainController die Haupt- funktion, indem er die CFolder des Models und CMainView des Views instanziiert.

Man erkennt, dass CMainController alle weiteren Controller zur Delegation verwendet. Alle Bausteine des Controllers greifen auf die Teilsysteme model und view zu, da sie gemäß des speziellen MVC-Modells zwischen diesen „vermitteln“.

Die Klasse CApplication ist, wie bereits erwähnt der Startpunkt der Anwendung. Dazu erzeugt sie nur eine Instanz von Typ CMainController.

Die folgende Grafik verdeutlicht, wie gehabt, die Wiederverwendung externer Klassenbibliotheken

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 18 - Nutzung von externen Klassenbibliotheken des Controllers

Die Klassenbibliotheken java.awt und java.swing werden für Dialoge zur Eingabe eines neuen oder Änderung eines vorhandenen Dokuments benötigt. Es wäre möglich, diesen Dialog auch ins View zu legen. Da dieser Dialog aber Eingaben kontrolliert, die über die Panels erfolgen, ist es im Controller besser aufgehoben. Des Weiteren wer- den über diese Klassenbibliothek Message-Dialoge an den Nutzer ausgegeben.

Die Event-Klassenbibliotheken java.awt.event und javax.swing.event dienen der Ereignisbehandlung. Der Iterator liest die Dokumentmenge aus dem Vector des CFolder aus. Zur Darstellung dieser Mengenelemente wird die Klassenbibliothek javax.swing.table nachgenutzt.

Für die Persistenzhaltung, das heißt für das Schreiben der Mappe in eine Datei und das Auslesen werden die in der Bibliothek java.io aufgeführten Klassen genutzt.

Ausführliche UML-Grafiken der einzelnen Klassen des Packages gse2 mit Wiederverwendung von Klassenbibliotheken sind im Anhang zu finden [S. 152].

4 Programmtechnische Realisierung des Lösungsmodells

Im bisherigen Verlauf dieser Dokumentation wurden technische Aspekte weitestgehend ausgeklammert. Nachdem das logische Modell nun vollständig beschrieben ist, geht es in diesem Kapitel um die Abbildung auf reale technische Konstrukte. Von herausragender Bedeutung ist dabei die Wahl der Programmiersprache.

Zur Realisierung des Entwurfes habe ich die Programmiersprache Java gewählt. Diese Entscheidung traf ich ausschließlich aufgrund meiner persönlichen Vorliebe; das Lösungsmodell ist bewusst allgemein gehalten, so dass es sich wohl mit jeder objektorientierten Programmiersprache umsetzen ließe.

An Java schätze ich insbesondere die folgenden Eigenschaften:

- Plattformunabhängigkeit: Ein kompiliertes Java-Programm ist auf allen Rech- nertypen, für die eine JavaVirtual Machine (JVM) existiert, lauffähig.
- Umfangreiche Standardbibliothek: Die in der Java Standard Library enthaltenen Klassen bieten Schnittstellen zu allen wichtigen Systemkomponenten wie Da- teisystem, Netzwerk und Grafikausgabe. Darüber hinaus sind zahlreiche Lö- sungen für Standardprobleme und Hilfsklassen enthalten. Der Entwickler kann sich darauf verlassen, dass diese Bibliothek auf der Zielplattform vorhanden ist. Diese zulässige Annahme erleichtert die Auslieferung („Deployment“) enorm.

Wie in den folgenden Abschnitten gezeigt werden wird, erfüllt die Klassenbibliothek „Java Foundation Classes“ (JFC) alle zuvor aufgestellten Anforderungen bezüglich grafischer Oberfläche, Persistenzhaltung und Mengenverwaltung.

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. 38] 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 ihren 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 beliebig fortgesetzt werden (ohne Leer- und Sonderzeichen). Java unterscheidet zwischen Groß- und Kleinschreibung.
-Bezeichner müssen in ihrem Gültigkeitsbereich eindeutig sein.

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 cust). 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.

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.38].

Die auf der Seite 38 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(), Show(), Insert(), Find()und Scratch() werden mit einem kleinen Buchstaben begonnen (equalValue(), copy(), show(), insert(), find()und scratch()). 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.2Realisierungskonzeption

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 Ver- sion 1.4.2-b28 (www.java.sun.com). Somit standen die im SDK integrierte Klassenbib- liotheken von Java zur Verfügung. Des Weiteren wurde für die Testumgebung das Pa- ckage JUnit 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 Klas- senbibliothek eingetragen werden.

Die Entwicklungsoberfläche (Plattform) war in erster Linie der Borland JBuilder 9 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 9 Enterprise Tri- al, u.a. für die Erstellung der ausführbaren Dateien, der UML-Grafiken und die HTML- Dokumentation. Die Klassen wurden mit JBuilder und dem Compiler des JBuilder "Bor- land 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.

Grundlegende Konzepte

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

Java arbeitet außer bei primitiven Datentypen mit stark typisierten Zeigern (Pointer), somit sind die verwendeten Attribute alle Referenzvariablen, die ihren Typ nicht ändern können.

Da man auf die Klassenbibliothek des SDKs zurückgreifen kann, benötigt man die in der CEDL beschriebene Methode equal() nicht. Eine solche ist bereits mit e- quals() in der Klasse java.lang.Object vorhanden.

Ebenso wird bei der Implementation der Datentypen auf vorhandene java.lang.* zurückgegriffen. So nutzen die geforderten Strings die Klasse java.lang.String.

Für die geforderten Ordinal-Typen (ganze Zahlen) stehen meiner Erkenntnis nach in Java keine entsprechenden Datentypen (unsigned int) zur Verfügung. Deshalb nutzen diese Attribute den primitiven Datentyp int. Da aber für die Dokumente nur die positiven Integer-Zahlen benötigt werden, wird diese Forderung in der Methode isClassInvariant() überprüft. Die Wahrheitswerte des Softwaresystems werden als boolean deklariert. Diese Datentypen stehen in Java automatisch zur Verfügung, da jede Klasse in Java stets java.lang.Object importiert.

Auf die Darstellung der Schnittstellen der Klassen und die Deklaration wichtiger Methoden wird im Folgenden verzichtet. Diese kann man den ausführlich kommentierten Quelltexten zum Projekt im Anhang [S.46] entnehmen.

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:\gse2\doc\index.html].

Spezielle Konzepte

Dieser Abschnitt beschäftigt sich mit ausgewählten Details der Implementierung. Dabei muss im Interesse eines überschaubaren Umfanges zwangsläufig eine Vorauswahl getroffen werden. Näher beleuchtet werden die folgenden Aspekte:

- Mengenverwaltung: Auswahl eines geeigneten Bausteines aus der Bibliothek, Realisierung wesentlicher Mechanismen.
- Grafische Oberfläche: Aufbau des View -Bausteines, Ereignisbehandlung und Interna der Controller.
- Persistenzhaltung.

Alle anderen Aspekte wurden bereits im ersten Teil des Praktikums beschrieben.

Mengenverwaltung

Im Abschnitt „3.1.1 Iteratorklasse CFolder“ sind detaillierte Anforderungen an den einzusetzenden Mengenverwaltungs-Baustein formuliert.

Am besten geeignet ist die Klasse java.util.Vector. Die Elemente eines Vector sind voll geordnet und schneller wahlfreier Zugriff ist gegeben. Diese Eigenschaften werden natürlich mit einigen Nachteilen erkauft (eventuell langsame EinfügeOperation), die aber gemäß der vorangegangenen Charakterisierung des benötigten Bausteines toleriert werden können.

Obwohl alle Klassen des Gegenstandsbereiches Möglichkeiten zur Klonierung anbieten (über die Methode Generate()), wurde darauf verzichtet, durch Mechanismen in CFolder eine Menge aus Kopien zu implementieren. Dadurch wird der notwendige Kodieraufwand reduziert.

Betrachten wir nun die Integration von java.util.Vector im Detail. Zunächst die Instanziierung.

Abbildung in dieser Leseprobe nicht enthalten

Beim Anlegen einer neuen Instanz von CFolder wird auch der notwendige leere Vector erzeugt. Hier hätte man anstatt des leeren Konstruktors auch einen wählen können, mit dem eine initiale Größe des Vector festgelegt wird. Dadurch ließen sich sehr teure Vergrößerungen des alloziierten Speicherbereiches sparen. Für den betrachteten Anwendungsfall ist ein solcher Wert aber kaum anzugeben.

Über die Kardinalität wird nicht selbst Buch geführt, sondern auf die Fähigkeiten des Vector zurückgegriffen.

Abbildung in dieser Leseprobe nicht enthalten

Elemente werden nur dann der Menge hinzugefügt, wenn sie nicht schon enthalten sind. Um dies zu prüfen, kann nicht auf vorgefertigte Funktionalität zurückgegriffen werden, die Menge muss eigenhändig durchsucht werden. Dazu dient die Hilfsfunktion find(). Da diese Methode in CFolder die Methode setElementAt() von Vector nutzt bzw. überschreibt, ist eine Ausnahmebehandlung meinerseits nicht notwendig.

Abbildung in dieser Leseprobe nicht enthalten

Die Hilfsfunktion find() greift auf die Vector-Methode indexOf() zurück. indexOf() gibt denn Index des gesuchten Dokuments zurück, falls es im Set enthalten ist, sonst -1. Ist das Dokument enthalten, gibt find() true zurück, sonst false.

Abbildung in dieser Leseprobe nicht enthalten

Auf Elemente zugegriffen werden kann über die Methode getElementAt(). Liegt der Index außerhalb des zulässigen Intervalls oder lässt sich Objekt nicht als CBankDocument casten, wird eine Nullreferenz zurückgegeben. Wie bereits erwähnt, gibt diese Methode keinen Wahrheitswert zurück um Seiteneffekte zu verhindern.

Abbildung in dieser Leseprobe nicht enthalten

Für das Entfernen von Elementen stellt Vector die Methode removeElementAt() zur Verfügung.. Ist das Löschen nicht möglich, gibt scratch() false zurück, ande- renfalls true.

Abbildung in dieser Leseprobe nicht enthalten

Die gesamte Interaktion mit java.util.Vector findet in den oben beschriebenen Methoden statt. Alle Weiteren greifen nur auf diese zu.

View

Die Klasse CMainView ist sehr einfach aufgebaut. Sie besteht neben der Definition von Instanzvariablen nur aus zwei Methoden: Einem Standard-Konstruktor und einer Methode jbInit(). In dieser werden die Benutzeroberflächenelemente konfiguriert und dem entsprechenden Bereich hinzugefügt.

Abbildung in dieser Leseprobe nicht enthalten

Die anderen Klassen im Teilsystem view sind ebenfalls sehr einfach aufgebaut. Sie bestehen neben der Definition von Instanzvariablen nur aus zwei Methoden: Einem Standard-Konstruktor und einem Parameter-Konstruktor. Der Parameter-Konstruktor definiert die Editierbarkeit von Textfeldern und initialisiert Labels und Textfelder. In ei- nem neuen Dokument sind alle auszufüllenden Felder editierbar, in einem zu ändern- den Dokument nur bestimmte. Dies wird über einen Parameter editable (boolean) realisiert. Der Standard-Konstruktor nutzt den Parameter-Konstruktor mit dem Parame- ter true.

Dazu ein Beispiel aus CBankDocumentPanel:

Abbildung in dieser Leseprobe nicht enthalten

Alle grafischen Elemente der Benutzeroberfläche, auf die von außen durch den jeweili- gen Controller zugegriffen wird, sind als öffentlich deklariert. Dazu zählen beispielswei- se Textfelder.

[...]