Sprachen der vierten Generation können zu ungewollten Abhängigkeiten führen:"User-Hersteller-Ehe" ist nur schwer zu lösen

15.11.1985

Parallel zur steigenden Akzeptanz von Software der vierten Generation durch die Anwender steigt auch die Zahl der angebotenen Systeme. Der Interessent hat die Qual der Wahl, da jedes System seine Vor- und Nachteile besitzt. Hat sich ein Anwender beispielsweise für ein DB-System entschieden - wobei das System zur Anwendungsentwicklung einfach dazugehört - tritt hier nach Meinung von Volker Raschke, Systementwickler aus Berlin, erstmalig die Frage nach der Abhängigkeit vom System und dessen Hersteller auf.

Zwangsläufig stellt sich dem User die Frage, was mit den bereits realisierten Anwendungen geschieht, wenn er zu einem späteren Zeitpunkt seine Systemwahl korrigieren will. Sei es, weil er sich geirrt hat oder weil durch die Weiterentwicklung der Software-Technologie ein leistungsfähigeres System mit einer besseren Philosophie auf den Markt kommt. Das ein Wechsel sehr kostspielige Neuentwicklungen aller Anwendungen nach sich ziehen kann, haben vor etwa zehn Jahren diejenigen Anwender erfahren müssen, die von RPG auf Cobol umgestellt haben.

Häufig wird das Argument vorgebracht, ein 4GL-System sei so komfortabel, daß der Aufwand für die Neuerstellung der alten Anwendungen kaum ins Gewicht falle. Doch hier schlägt uns die Praxis ein Schnippchen, denn die meisten der mit den "alten" Softwaresystemen entwickelten Applikationen sind Adhoc-Anwendungen, so daß keine oder nur eine sehr unzureichende Dokumentation existiert. Nach den bisherigen Erfahrungen besteht deshalb der Umstellungsaufwand für bestehende Applikationen zu 80 bis 90 Prozent aus der Analyse, was die alte Anwendung macht oder tun soll. Daß heißt, der Komfort der 4GL-Systeme für die eigentliche Neuerstellung wirkt sich nur auf 10 bis 20 Prozent des Umstellungsaufwandes aus. Durch die Abhängigkeit der Anwendungen vom System entstehen deshalb bei einer Umstellung hohe Folgekosten.

Gibt es eine Alternative dazu, daß Komfort und Hardwareunabhängigkeit durch Softwareabhängigkeit erkauft werden müssen? Eine Normierung der Sprachelemente von Hochsprachen ist nicht praktikabel, da die Unterschiede der Sprachelemente auch den Unterschied in der Leistungsfähigkeit ausmachen. Es gibt jedoch eine Sprache, die weitgehend normiert ist: Cobol ist in seiner Anwendung in hohem Maße unabhängig von irgendwelchen momentan in Mode befindlichen Philosophien oder Methoden. Das ist nicht immer von Vorteil, weshalb derzeit auch Aktivitäten unternommen werden, noch stärker strukturorientierte Sprachelemente im Cobol-Standard zu integrieren. Das ist aber die Voraussetzung dafür, daß Cobol die am stärksten normierte und die noch heute am weitesten verbreitete Sprache ist.

Oft schon ist Cobol totgesagt worden, weil am Software-Himmel eine neue, bessere Sprache aufstieg. Viele dieser Sprachen sind mittlerweile wieder in Vergessenheit geraten oder zu Exotensprachen geworden - was aber nichts darüber aussagt, ob sie nicht eventuell wirklich besser waren.

Es soll an dieser Stelle nicht bestritten werden, daß die reine Cobol-Programmierung ohne Tool heutzutage nicht mehr das Nonplusultra der Softwareentwicklung darstellt. Andererseits würde ein Vergleich zwischen Cobol und einer "modernen Sprache" ohne Berücksichtigung der für Cobol existierenden Tools zu einem nicht brauchbaren Ergebnis führen.

Dabei wäre es doch möglich, unter Berücksichtigung der heutigen Software-Technologie, Cobol als gemeinsame, universelle Basissprache zu betrachten.

Somit würde ein Anwender den Komfort der modernen SW-Technologie mit der Flexibilität von Cobol verknüpfen, ohne eine unauflösliche Verbindung mit einem Tool eingehen zu müssen. Applikationen könnten auch über die Begrenzungen des Tools hinaus erweitert und unabhängig vom Tool auch an andere Benutzer weitergegeben werden.

Da bei den meisten Anwendern von modernen Werkzeugen oder Hochsprachen sowieso Cobol neben dem Tool für die Realisierung komplexer Anwendungen im Einsatz ist, würde durch ein Tool, das Cobol-Programme erzeugt, gleichzeitig eine Vereinheitlichung in der Programmierung erreicht. Voraussetzung dafür wäre natürlich, daß das Werkzeug ein qualitativ hochwertiges, wartungsfreundliches Cobol-Programm erstellt, was beileibe nicht von allen Tools, die Cobol-Programme erzeugen, behauptet werden kann.

Das wäre auch ein Ausweg aus dem Umstellungskreislauf. Solange das Tool im Einsatz und für Anwendungen sinnvoll ist, wird die Pflege über das Tool durchgeführt, danach kann die Pflege der erzeugten Cobol-Programme auch manuell fortgesetzt werden.

Diese Gründe führten zur Entwicklung von Tools, die mit nicht-prozeduralen Sprachelementen der 4. Generation wartungsfreundliche Cobol-Programme erstellen.

Diese Tools sind tatsächlich Werkzeuge: Der Anwender kann entscheiden, ob er die damit erstellten Applikationen weiter mit dem Tool pflegen will, was einige Vorteile hat; er kann jedoch die Wartung der erzeugten Programme auch in herkömmlicher Weise durchführen, etwa mittels Dateiaufbereiter.

Wirtschaftliche Potenz ist kein Allheilmittel

Da dieser Gedanke des Toolkonzepts sich durchzusetzen beginnt, sehen sich inzwischen auch Vertreter der "Load-and-go"-Systeme veranlaßt, zu diesem Thema Stellung zu nehmen.

Wenn sie dabei das Problem der Herstellerabhängigkeit bei entsprechender wirtschaftlicher Potenz des Herstellers als gelöst ansehen, kann das nur auf einem Mißverständnis beruhen. Was nützt dem Anwender die wirtschaftliche Potenz des Herstellers, wenn er die "User-Hersteller-Ehe" auflösen will?