Persistente Verwaltung der Daten einer Dokumentenmappe (Teil 2
Werbung
Informatik Nico Helweg Persistente Verwaltung der Daten einer Dokumentenmappe (Teil 2) Praktikumsbericht / -arbeit Universität Potsdam Institut für Informatik Professur Informatik II Lehrveranstaltung Grundlagen der Softwareentwicklung II Praktikumsdokumentation Aufgabe: Persistente Verwaltung der Daten einer Dokumentenmappe Autor: Nico Helweg Basismaschine: Microsoft Windows XP / Service Pack 1 Java(TM) 2 SDK, Standard Edition 1.4.2-b28 Borland JBuilder Personal 9.0.125.113 Compiler des JBuilder "Borland Make" Potsdam, 14.10.2003 Bearbeitungsvermerk: Inhaltsverzeichnis 1 Aufgabenstellung .................................................................................................. 1 2 Erläuterung der Aufgabenstellung ...................................................................... 2 2.1 Interpretation der Praktikumsaufgabe.................................................................. 2 2.2 Lesbarkeit und Aufbau der Dokumentation.......................................................... 3 2.3 Bezug zur Lehrveranstaltung ............................................................................... 4 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 3 Darstellung des Lösungsmodells ...................................................................... 10 3.1 Darstellung der Lösungsidee ............................................................................. 10 3.1.1 3.1.2 3.1.3 3.1.4 3.2 4 Iterator .............................................................................................................. 5 Persistenzhaltung............................................................................................. 5 MVC-Konzept ................................................................................................... 6 Grafische Benutzerschnittstellen (GUI) ............................................................ 7 Nutzung von Klassenbibliotheken .................................................................... 8 Iteratorklasse CFolder .................................................................................... 10 Benutzungsszenarien und Dialogansichten ................................................... 11 Anforderung an Klassenbibliotheken zur Realisierung des MVC-Konzepts... 16 Anforderung an Klassenbibliotheken zur Realisierung der Persistenz........... 17 Darstellung der Architektur des Programmsystems........................................... 18 Programmtechnische Realisierung des Lösungsmodells .............................. 23 4.1 Namenskonventionen ........................................................................................ 23 4.2 Realisierungskonzeption.................................................................................... 25 4.3 Testplan und Testergebnisse............................................................................. 34 5 Wertung des erreichten Ergebnisses ................................................................ 37 A Anhang ................................................................................................................. 38 A.1 Anhang zur Aufgabenstellung............................................................................ 38 A.2 Die Quelltexte des Praktikums........................................................................... 46 A.2.1 A.2.2 A.2.3 A.2.4 A.3 A.3.1 A.3.2 A.3.3 A.3.4 A.3.5 Quelltexte package gse2.model ..................................................................... 46 Quelltexte package gse2.view........................................................................ 76 Quelltexte package gse2.controller ................................................................ 89 Quelltexte package gse2.test ....................................................................... 116 Abbildungsverzeichnis ..................................................................................... 152 UML package gse2.model............................................................................ 152 UML package gse2.model............................................................................ 153 UML package gse2.view .............................................................................. 157 UML package gse2.controller....................................................................... 160 UML package gse2.test................................................................................ 166 A.4 Literaturverzeichnis.......................................................................................... 172 A.5 Eidesstattliche Erklärung ................................................................................. 173 Aufgabenstellung 1 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 CBankDocument CForm CStandingOrder CContract CFolder Wurzelklasse der Dokumentenhierarchie allgemeines Formular Dauerauftrag Vertrag Mappe von Dokumenten für einen Kunden 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. Erläuterung der Aufgabenstellung 2 Erläuterung der Aufgabenstellung 2.1 Interpretation der Praktikumsaufgabe 2 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 Speicherung. 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 CForm, CStandingOrder und CContract), 2. Mengenverwaltung (CFolder), 3. Persistenzhaltung der Menge und 4. grafische Benutzeroberfläche (GUI). (CBankDocument, Mit der Aufgabenstellung wurde zu jedem Teilsystem 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ängigen Mitteln [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 Softwarebauelementen 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ähiges Softwaresystem zum Erstellen, Ändern, Löschen und Speichern (Objektpersistenz) von Instanzen der bereits vorliegenden Menge. Dazu wird eine Iteratorklasse (CFolder) für die Mengenverwaltung geschaffen. Des Weiteren sind abhängig von Benutzungsszenarien 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 Erläuterung der Aufgabenstellung 3 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 automatisierten 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 Gliederungspunkte 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 Variablen 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 Farbe ausgegeben. In der Dokumentation werden Begriffe inhaltlich wie in der Vorlesung bzw. in der objektorientierten Programmiersprache Java verwendet. Sollte ein Begriff eingeführt bzw. nicht üblich verwendet werden, so wird in der Dokumentation an der betreffenden Stelle darauf eingegangen. Die in der Dokumentation dargestellten UML-Grafiken wurden mit der Trial-Version des Borland JBuilders 9 Enterprise Trial erstellt. Zu beachten ist dabei, dass der UML- Erläuterung der Aufgabenstellung 4 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 vereinbarten Einschränkungen dargestellt bzw. wiedergegeben. Des Weiteren wird auf Iteratoren, 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 verwendenden Klassenbibliotheken für die Persistenz, das MVC-Konzept und die Mengenhaltung 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 Lehramtsstudenten im vierten Semester (SS 2003) des Erweiterungsstudiums Informatik an der Universität Potsdam an. Diese Lehrveranstaltung vermittelte im zweiten Teil Anforderungen an objektorientierte Architekturen aus Sicht der Wiederverwendung (z.B. Persistenzhaltung, Polymorphe Mengen) und eine Einführung in die Grundideen der Sprache 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 Erläuterung der Aufgabenstellung 5 (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 Typdefinition 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- Erläuterung der Aufgabenstellung 6 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öglichkeiten: 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 relevanter 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- Erläuterung der Aufgabenstellung 7 schiedene Bankdokumente, um jeweils bestimmte Teilaspekte optimiert darstellen zu können. Der Controller übernimmt die Interaktion mit dem Benutzer und organisiert das Zusammenspiel 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 oder 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. Erläuterung der Aufgabenstellung 8 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 vereinheitlicht 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 dazugehörigen Algorithmen. In der vorliegenden Problemstellung kann die Mappe CFolder auf Basis eines Vectors realisiert werden (in Java java.util.Vector). Für die Serialisierung sind für das Einlesen aus bzw. Schreiben in eine Datei Kommunikationsmechanismen erforderlich (in Java java.io.Serializable). Gerade das Einlesen ist zusätzlich auf die Fähigkeit einer dynamischen Objekterzeugung angewiesen. Erläuterung der Aufgabenstellung 9 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 Umsetzung von Fenstern, Menüs, Beschleunigertasten (Hotkeys), Bildern etc.. Problematisch ist, dass diese Elemente dynamisch zur Laufzeit nur eher umständlich verändert werden können. Der Controller benötigt für die Interaktion mit dem Nutzer Zugriff auf HardwareRessourcen (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 Nachrichtenkommunikation. 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. Darstellung des Lösungsmodells 3 10 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 Aufgabenstellung beschriebene Schnittstelle CFolder beschrieben. Im Großen und Ganzen habe ich mich bei der Umsetzung an die gegebene CEDL-Beschreibung dieser Klasse [S. 38] gehalten. Die Attribute dieser Klasse sind Cursor (Integer für das aktuelle Dokument der Dokumentmenge), CustomerInformation (String für den Kundenname), DateOfFoundation (CDate für das Erstellungsdatum der Mappe) und SetOfBankDocuments (Vector für die Bankdokumentmenge). In der nachzunutzenden Klassenbibliothek Vektor wird die Menge von Bankdokumenten abgelegt. Demzufolge werden an diese Bibliothek verschiedene Anforderungen 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, Abbildung 2 – um ein beliebiges Element zurückgeben zu können. Klasse CFolder.java • Die Elemente der Menge können verschiedene Ty- Darstellung des Lösungsmodells 11 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 realisierbar. Während der Laufzeit wird dann die entsprechende Methode dem Typ des Mengenelements gewählt. 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(), getActual() 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 Softwaresystem zu interagieren. Dazu müssen Aktionen des Benutzers stets das gewü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.
