Gruende

Gründe für die Entwicklung von BAF/BAL

Programmiersprachen gibt es wie "Sand am Meer". Warum es jetzt noch eine weitere gibt, soll auf dieser Seite erläutert werden.

Historie

Die Ursprünge von BAF/BAL liegen bei einem Reiseveranstalter. Ausgangssituation war die Folgende:

• COBOL-System
• Oracle-Datenbank
• Ein mit Delphi geschriebener Client, der die COBOL-Masken auf Windows-PCs darstellte
• Einige später hinzu gefügte Delphi-Formulare, die direkt mit der Oracle-Datenbank agierten.

Von zwei COBOL-Entwicklern war einer bereits im Ruhestand und nur noch für einzelne Wochen verfügbar, der andere COBOL-Entwickler würde voraussichtlich in 4 Jahren in den wohlverdienten Ruhestand gehen. Die Option, einen weiteren Entwickler in COBOL einzuarbeiten, war in der Überlegung. Allerdings hatte das über Jahrzehnte gewachsene System zwar durchaus auch seine Stärken, aber eben auch seine Schwächen.

Die Alternative lag in einer kompletten Neu-Entwicklung. Diese muss jedoch parallel zum laufenden Betrieb mit näherungsweise der gegebenen Entwickler-Mannschaft erfolgen. Nach grober Schätzung hätte der Zeitaufwand bei der bisherigen Entwicklungsgeschwindigkeit bei etwa 20 bis 30 Jahren gelegen.

Daraus resultierte die Anforderung, die Entwicklungsgeschwindigkeit um etwa den Faktor 5 bis 10 zu erhöhen.

Anforderungen und Wünsche

An die zu findende Lösung gab es die folgenden harten Anforderungen:

• Massive Reduzierung der Entwicklungszeit (auf 10% bis 20% der bisherigen Zeit)
• Die gegebene Komplexität muss abgebildet werden können. (Eine Lösung, welche Trivialaufgaben um den Faktor 5 bis 10 beschleunigt, aber die Lösung komplexer Probleme verlangsamt oder gar unmöglich macht, bringt insgesamt keinen Vorteil. Ebenso bringt es letztlich keinen Vorteil, wenn die gefundenen Lösungen dann die Arbeit des Endanwenders mit dem System verlangsamen, weil um Unzulänglichkeiten des Frameworks herum entwickelt werden muss. Die Reduzierung der Entwicklungszeit muss sich über die komplette Ablösung des COBOL-Altsystems realisieren lassen, dabei muss die Arbeit und die Komplexität für den Endanwender zurückgehen.
• Die Entwicklung des Frameworks selbst darf nicht viel Zeit beanspruchen
• Die Lösung einer Stichtagsumstellung wurde vom Management als zu riskant verworfen. Das bisherige System muss somit modulweise abgelöst werden. Daraus resultierte die Anforderung, dass sowohl mit den alten als auch den neuen Tabellen parallel und gemischt gearbeitet werden kann.

Zudem flossen unter anderem folgende Wünsche in die Entwicklung ein:

• Unabhängigkeit von der Datenbank, so dass eine Alternative besteht, wenn die Lizenzpolitik von Oracle zu schmerzhaft wird.
• Weg vom typischen COBOL-Terminal Look&Feel hin zu einem moderneren UI (Nachschlagelisten, mehrzeilige Textfelder, ...)
• Voll-Historisierung der Daten, Historisierung kann auch vom Anwender eingesehen werden (bislang gab es Historisierung ausgewählter Tabellenspalten, die Historisierung konnte nur mit händisch angepassten SQL-Statements eingesehen werden, also nur von den Entwicklern).
• Rechteverwaltung bis auf die einzelne Spalte im Grid hinunter (bislang gab es Rechteverwaltung auf Formular-Ebene, teilweise nur auf Modul-Ebene).

Vorbild SQL

Auch wenn die Sprache BAL komplett anders aussieht als SQL - SQL hat bei der Entwicklung als Vorbild gedient:

• Mit SQL kann man mit wenigen und vergleichsweise kurzen Befehlen komplexe Operationen durchführen.
• SQL ist flexibel genug, dass man die meisten Probleme damit sehr schnell lösen kann.
• SQL beschreibt eher das gewünschte Ergebnis als dass eine Abfolge von nacheinander auszuführenden Schritten durchgeführt werden soll.

Design-Entscheidungen

Unter anderem wurden die folgenden Design-Entscheidungen vorgenommen:

Interpreter und Code in der Datenbank

Entwicklungszeit ist nicht nur Arbeitszeit der Entwickler, sondern auch die Zeit zwischen der Entscheidung zu einer Änderung oder Neuentwicklung und der Einsetzbarkeit durch die Anwender. Bei kompilierten Code muss nach einer Änderung das Ergebnis kompiliert werden, auf das Netzlaufwerk kopiert werden, anschließend müssen die Anwender ihren Client neu starten. Mit dem bisherigen System haben wir die Zeit zwischen "Go" (Entscheidung für die Änderung) und "Use" (Anwender können damit arbeiten) nur in wenigen Fällen (Berichtigung von Rechtschreibfehlern oder so) unter 20 Minuten bekommen. Das ist zwar nicht wirklich schlecht, aber auch nicht gut genug. Zudem es massiv ärgerlich ist, wenn viele Anwender wegen einer Änderung ihr System neu starten müssen.

Bei BAF/BAL ist Kompilierung nur erforderlich, wenn das Framework oder der Client erweitert/verbessert wird. Der BAL-Code liegt in der Datenbank, eine Änderung erreicht die Anwender quasi sofort, ohne dass ein Neustart erforderlich ist. (Für den Code gibt es genau genommen eine Cache, der verhindern soll, dass bei Massenbearbeitungen mehrmals pro Sekunde derselbe Code aus der Datenbank geladen wird; die maximale Haltedauer liegt jedoch bei einer Minute).

Erfahrungswerte (bei einem Entwickler, der in seinem Code "zuhause" ist):

• Bei der Behebung von Rechtschreibfehlern oder ähnlich kleinen Anpassungen liegt die Go2Use-Zeit bei etwa einer halben Minute
• Hinzufügen eines neuen Datenbankfeldes (aus dem geänderten CREATE TABLE-Statements werden händisch die ALTER TABLE-Statements für die Daten- und die History-Tabelle abgeleitet, der Trigger zur Befüllung der History-Tabelle wird aus dem CREATE-TABLE-Statment vom Wizzard abgeleitet, die Seite im BAF-Client wird händisch um das hinzugefügte Datenbank-Feld ergänzt): Go2Use-Zeit etwa zwei Minuten.

Entwicklungsumgebung im Client

Der BAF-Client enthält auch die Entwicklungsumgebung (freilich nur zugänglich für User mit Entwickler-Rechten). Somit besteht die Möglichkeit, kleinere Änderungen auch beim Anwender am Platz oder während eines Meetings durchzuführen.

Modularität

Der BAL-Interpreter wurde modular aufgebaut. Damit hat der Entwickler stets die Möglichkeit, eigene Funktionalität über eigene Module zu ergänzen, ohne bestehende Module zu beeinflussen oder Hindernisse für die Verwendung neuerer Versionen zu schaffen.