0,00 €
Mehr erfahren.
- Herausgeber: GRIN Verlag
- Sprache: Deutsch
- Veröffentlichungsjahr: 2004
Praktikumsbericht / -arbeit aus dem Jahr 2003 im Fachbereich Informatik - Programmierung, Note: 1,3, Universität Potsdam (Informatik), Veranstaltung: Grundlagen der Softwareentwicklung, Sprache: Deutsch, Abstract: 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. Zur Dokumentation gehören auch alle Klassen des Java-Projektes.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Ähnliche
Page 1
Page 3
Aufgabenstellung 1
1 Aufgabenstellung
Vorgegebene Prozedurparameternamen und ihre Semantik sowie die CEDL- Beschreibungen der geforderten Klassen sind im Anhang[S. 38]zu finden.
Page 4
Erläuterung der Aufgabenstellung 2
2 Erläuterung der Aufgabenstellung
2.1Interpretation 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 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 Mengevon Softwarebauelementen (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 WurzelklasseCBankDocumenthaben. 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 eineIteratorklasse(CFol-der)fürdie Mengenverwaltung geschaffen. Des Weiteren sind abhängig von Benutzungsszenariengrafische BenutzerschnittstellenundEreignisbehandlungen(Event Handling) zu schaffen. Die kursiv dargestellten Begriffe stellen Konzepte (Patterns undFrameworks)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
Page 5
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() oderkeyOf())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.2Lesbarkeit und Aufbau der Dokumentation
Als Grundlage für die Erarbeitung der Dokumentation wurde die Word-VorlageBelegdoku.dotvon Herrn Schubert verwendet, welche aber um einige Gliederungs- 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 werdenkursivgeschrieben. Für Dateinamen wurde die SchriftartTahomagewählt. Auszüge aus Quelltexten, insbesondere Bezeichner für Va- und Methoden, werden inCourier Newdargestellt. 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-
Page 6
Erläuterung der Aufgabenstellung 4
Browser des JBuilders standardgemäßeget-undset-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.3Bezug 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 dieAusnahmebehandlung(Exception Handling),Applikationsrahmen(Application Framework),Grafische Benutzerschnittstellen
Page 7
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.1Iterator
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()undshow()).SolcheIteratoren ü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 umIteratormethodenerweitert, welche
Iteratoren 2. Art: Hier werdenIteratorklasseneingeführt, welche Steuerkonstrukte und
Das Management von Instanzen der vorliegenden polymorphen Menge erfolgt in der zweiten Etappe durch einen Iterator der 2. Art, der in CEDL vorgebenenIteratorklasseCFolder[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()undscratch()).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 Objekterzeugunggenerate())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.2Persistenzhaltung
Ein weiterer Schwerpunkt der Vorlesung war diePersistenzhaltungvon 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-
Page 8
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.3MVC-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 derApplikationsrahmen(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:
DasModelist 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.
DasViewist 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-
Page 9
Erläuterung der Aufgabenstellung 7
schiedene Bankdokumente, um jeweils bestimmte Teilaspekte optimiert darstellen zu können.
DerControllerü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.
DieApplicationvereinigt 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 auchModel-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.4Grafische Benutzerschnittstellen (GUI)
Softwareprodukte haben heutegrafische Benutzerschnittstellen.Die Bildschirmoberfläche stellt die Arbeitsfläche (desktop) dar. Das Grundelement einer Arbeitsfläche ist dasFenster.
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.
Page 10
Erläuterung der Aufgabenstellung 8
Eine Fensterstruktur besteht aus typverschiedenen Elementen. Der CUA (CommonUser 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 dieEreignisbehandlung(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 dasAbstract Windowing Toolkit (AWT)und dasSwing Toolset).
2.3.5Nutzung von Klassenbibliotheken
KlassenbibliothekenstellenDatenstrukturen, KonzepteundAlgorithmenbereit, 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 Javajava.util.Vector).Für die Serialisierung sind für das Einlesen aus bzw. Schreiben in eine Datei Kommunikationsmechanismen erforderlich (in Javajava.io.Serializable).Gerade das Einlesen ist zusätzlich auf die Fähigkeit einer dynamischen Objekterzeugung angewiesen.
Page 11
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 Javajava.awtundjava.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 Hardware-Ressourcen (in Javajava.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 KlasseCDate.
Page 12
Darstellung des Lösungsmodells 10
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 IteratorklasseCFolderzu 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.1Darstellung der Lösungsidee
3.1.1Iteratorklasse CFolder
Im folgenden Abschnitt wird die in der Aufgabenstellung beschriebene SchnittstelleCFolderbeschrieben. 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 sindCursor(Integer für das aktuelle Dokument der Dokumentmenge),CustomerInformation(String für den Kundenname),DateOfFoundation(CDate für das Erstellungsdatum der Mappe) undSetOfBankDocuments(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ö- 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-
Page 13
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 TypCBankDocumentsind,
sind die polymorphen Methoden in dieser Menge auf demCBankDocumentrealisierbar. 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 MengeSetOfBankDocumentsrealisieren. Ausführliche Beschreibungen der MethodengetCard(), insert(), getFirst(), getNext(), find(), getActual()undscratch()(Bezeichnungen angepasst lt. Namenskonventionen) sind im Anhang unter Quelltexte[S. 46]zu finden. Neben den geforderten Methoden auf die Menge wird eine MethodegetElementAt()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 MethodengetFirst(), getNext()undgetActual()gegenüberder Aufgabenstellung abgeändert. Diese sollten neben dem geforderten Bankdokument auch einen Boolean für den Erfolg der Aktion zurückgeben. „DieAuswertung 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äßeget-undset-Methodenfü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.2Benutzungsszenarien 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 manBenutzungsszenarien.
Page 14
Darstellung des Lösungsmodells 12
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.
Page 15
Darstellung des Lösungsmodells 13
Ausgehend von diesen Benutzungsszenarien und der CUA können nun das Haupt- fenster und verschiedene Dialogansichten entworfen werden.
Page 16
Darstellung des Lösungsmodells 14
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 Arbeitsbereich.
Abbildung 3 - leere Arbeitsoberfläche
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, EditundHelp.
Im Menü „File“ finden sich Funktio-
