Gruende: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „=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äu…“) |
|||
Zeile 18: | Zeile 18: | ||
Daraus resultierte die Anforderung, die Entwicklungsgeschwindigkeit um etwa den Faktor 5 bis 10 zu erhöhen. | Daraus resultierte die Anforderung, die Entwicklungsgeschwindigkeit um etwa den Faktor 5 bis 10 zu erhöhen. | ||
− | ==Anforderungen== | + | ==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 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, mehrzeile 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 Datenbankspalte 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. |
Version vom 11. August 2020, 18:12 Uhr
Inhaltsverzeichnis
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 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, mehrzeile 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 Datenbankspalte 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.