Entwicklung eines konfigurierbaren Softwaretools für Kreditinstitute auf Internetbasis

Dialoge des Systems VorteX Inet sind spezielle Fenster, die die Kommunikation mit dem Anwender realisieren. Ein Dialog ermöglicht die Bereitstellung von Informationen in Abhängigkeit von Benutzereingaben. Die Eingabedaten dienen hierbei als Parameter für auszuführende Transaktionen, deren Ergebnisse dem Benutzer innerhalb des Dialogs übermittelt werden. Ein Dialog wird ebenfalls mit Hilfe der Skriptsprache erstellt. Dabei stehen dem Programmierer verschiedene Komponenten zur grafischen Gestaltung zur Verfügung. Im einzelnen sind dies Labels zur Beschriftung, Knöpfe zum Auslösen von Skriptaktionen und Ein- bzw. Ausgabefelder für Text, Kalenderdatum, Personalausweisnummer, Kontonummer, Geldbetrag und Tabelle. Sofern es möglich ist, werden Benutzereingaben beim Verlassen eines Felds syntaktisch geprüft, bei der Ausweisnummer wird beispielsweise ein Prüfalgorithmus angewandt und die errechnete Prüfziffer mit der eingetippten Zahl verglichen. Entspricht die Eingabe den Vorschriften, dann wird sie formatiert ausgegeben, im gegenteiligen Fall wird der Zustand, den die Komponente vor der nicht akzeptierten Eingabe besaß, wieder hergestellt. Mit dem Verlassen von Feldern oder dem Drücken eines Knopfes können Ereignisse ausgelöst werden, welche Auswirkungen auf verschiedene Dialogkomponenten haben können, beispielsweise die Formatierung der Eingabe oder das Löschen eines anderen Eingabefelds. Aufgrund der Ereignisse, die ebenfalls im Skript programmiert werden, können aber auch Transaktionen gestartet oder weitere Dialoge eröffnet werden. [...]

Zur Ausführung von VorteX-Inet-Applikationen steht dem Anwender ein Java-Applet, genannt Navigator, zur Verfügung. Dieser präsentiert sich in Form eines vertikal zweigeteilten Fensters, die linke Seite zeigt einen Hierarchiebaum, anhand dessen der Anwender die Navigation durch die Anwendung vornimmt, während die rechte Seite zur Ausgabe von Daten an den Benutzer dient. Der Hierarchiebaum setzt sich aus Knoten zusammen, welche ihrerseits Unterknoten enthalten können. Die Darstellung eines Knotens besteht aus einem Icon und dem Knotennamen. Die Hierarchiestufe eines Knotens wird durch Einrückungen, also dem Abstand des Icons vom Fensterrahmen, verdeutlicht. Das Icon zeigt an, ob ein Knoten geöffnet oder geschlossen ist. Das Öffnen bzw. Schließen eines Knotens wird per Mausklick erzielt. Das Erscheinungsbild und die Funktionalität eines Hierarchiebaums werden durch ein Skriptprogramm bestimmt. Das Öffnen eines Knotens kann mehrerlei Folgen haben. Enthält ein Knoten Unterknoten, so werden diese beim Öffnen des übergeordneten Knotens im Hierarchiebaum angezeigt. Außerdem kann das Knotenöffnen einige weitere, beliebig zu kombinierende Aktionen auslösen, welche ebenfalls durch das Skript definiert werden. So können Transaktionen durchgeführt, Dialogfenster geöffnet, andere Bäume oder Teilbäume sowie dynamische, als Transaktionsergebnisse erhaltene Unterknoten angezeigt werden. Jeder Knoten besitzt potentiell die gleiche Funktionalität, sei es ein Haupt-, ein Unterknoten oder ein dynamisch erhaltener Knoten. Für die Ausführung und Kombination der oben erläuterten Aktionen können Variablen innerhalb eines Knotens verwaltet werden. Im Unterschied zum alten System VórteX, wo sämtliche Variablen als Strings gehandhabt werden, besitzt das System VorteX Inet einige speziell für die zu bewältigenden Aufgaben festgelegte Datentypen. Diese Neuerung hielten wir für nötig, um das System besser zu strukturieren und Programmierfehlern durch die unterschiedlich mögliche Deutung eines Strings entgegenzuwirken. Eine bisher nicht erwähnte mögliche Aktion, die durch das Öffnen eines Knotens hervorgerufen werden kann, ist die formatierte Anzeige von Daten im rechten Fenster des Navigators. Die im rechten Fenster anzuzeigenden Daten werden unterhalb eventuell bereits vorhandener Daten dargestellt, so daß früher angezeigte Informationen weiterhin zugänglich bleiben. Übersteigt die Menge der im Fenster darzustellenden Informationen dessen Größe, so können nicht mehr angezeigte Informationen mit Hilfe einer Scrollbar erneut sichtbar gemacht werden. Für die Formatierung derartig auszubreitender Daten stehen dem Skriptprogrammierer verschiedene VorteX-InetKomponenten zur Verfügung, siehe nachfolgenden Abschnitt Die Funktionalität von Dialogen. Hinsichtlich des rechten Navigatorfensters unterscheidet sich die Funktionalität des Prototypen VorteX Inet vom System VórteX. VórteX zeigt zum Beispiel Unterknoten nicht nur innerhalb des Hierarchiebaums, sondern zusätzlich im rechten Fenster an. Dadurch ergibt sich die Möglichkeit, veranlaßt durch das Anklicken eines Knotens im linken Fenster, den selben Knoten im rechten [...]

Für den zu entwickelnden Prototypen mußte eine eingeschränkte Funktionalität bezogen auf das bisherige System festgelegt werden. Während der Modellierungsphase war es von entscheidender Wichtigkeit, die spätere Implementierung von im Prototypen nicht enthaltener Funktionalität zu berücksichtigen. Hierzu einige Beispiele: anders als beim bisherigen System kann von einem Client des Prototypen kein Druckauftrag abgesetzt werden. Wie im Abschnitt Sicherheitsmechanismen von Java im Kapitel Untersuchung internetgeeigneter Technologien beschrieben, ist es jedoch möglich, hierfür eine Lösung zu implementieren. Der Prototyp verwirklicht kein Sicherheitskonzept, unsere diesbezüglichen Vorschläge sind jedoch im Abschnitt Datensicherheit im System VorteX Inet im selben Kapitel aufgeführt. Im Prototypen ebenfalls nicht realisiert sind die Implementierung eines Cache zur Vermeidung unnötigen Netzwerkverkehrs sowie eines Store-and-Forward-Mechanismus, der den OfflineEinsatz von VorteX Inet ermöglichen soll. Wie im Abschnitt Technologien für den VorteX-InetServer zu sehen ist, wurde unter anderem der Cache als Argument gegen die Implementierung von verteilten Serverobjekten genannt, obwohl auch für diesen Fall die Weiterentwicklung des Prototypen zum fertigen Produkt durchdacht und vorbereitet war. Die Nichtimplementierung verteilter Serverobjekte hielt als Cambio Uno ([span.] Änderung eins) Einzug in die Geschichte der VorteX-Inet-Modellierung, die Auswirkungen dieser Änderung werden im Abschnitt Auswahl zur Implementierung verwendeter Technologien erörtert. Bei den anfänglichen Gesprächen bezüglich der Funktionalität des neu zu entwickelnden Systems war die Rede davon, die Konfiguration der Benutzeroberflächen möglichst wie im System VórteX mit einer Skriptsprache zu steuern. Doch schon bei der Präsentation des ersten grob entwikkelten Modells des neuen Systems wurde die Kompatibilität einer neuen Skriptsprache gefordert, um deren Koexistenz neben den bereits eingesetzten Skriptsprachen und somit einen problemlosen Umstieg auf das neue System zu ermöglichen. Die darauffolgenden weiteren Überlegungen zur Modellierung des neuen Systems gingen daher lange Zeit von der Notwendigkeit dieser Kompatibilität aus, bis wir aufgrund weiterer Untersuchungen zu der Erkenntnis gekommen sind, daß die Kompatibilität der Skriptsprachen sich nicht mit den ursprünglichen Projektzielen vereinbaren läßt - siehe unten in diesem Abschnitt -, und Cambio Dos ([span.] Änderung zwei), die Einführung einer unabhängigen Skriptsprache für VorteX Inet, unumgänglich wurde. Die verschiedenen Pflichtenheftversionen, die während der Modellierungsphase für unterschiedliche Modelle erarbeitet wurden, sprechen zunächst von der Weiterverwendung der bisherigen Skriptsprachen im neuen System, dann von deren Verbesserung durch Erweiterung um zusätzliche Funktionalität. Später ist von einer neuen Sprache die Rede, wobei alte Skripts vollständig in die neue Sprache übersetzt werden können, bis schließlich die neue, VórteX ähnliche, nicht kompatible Skriptsprache in Erscheinung tritt, welche die beiden ehemaligen Sprachen ersetzt, aber nicht die identische Funktionalität aufweist, weshalb ein Umwandlungsmechnismus zwar möglichst viele Informationen aus alten Skripts in neue Skripts übertragen könnte, der fehlende Rest jedoch manuell programmiert werden müßte. Ausschlaggebend für die Einführung einer neuen, unabhängigen Skriptsprache war die komplexe und für einen objektorientierten Entwurf nicht geeignete Struktur von VórteX, dessen Module [...]