Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

02.05.1986 - 

Für Sie gelesen im Software Engineering Newsletter:

"Es ist keineswegs Trägheit, wenn DV-Anwender nicht in Massen von der dritten zur vierten Generation überlaufen"

Die Vorteile von Sprachen der vierten Generation sind hinreichend bekannt: Sie sind leicht zu lernen, kompakt, flexibel und, vor allem, mit der DB/DC-Umgebung integriert. Es wird auch argumentiert, daß die Anzahl der Anweisungen um den Faktor Zehn niedriger ist als die vergleichbare Anzahl der Anweisungen in einer Sprache der dritten Generation. Die gleichen Argumente kommen auch von den Basic- und APL-Anhängern. Analogie: die natürlichen Sprachen. Egal, welche Vorteile die deutsche Sprache aufweist, sie wird sich aufgrund der Machtkonstellation innerhalb der EG nie durchsetzen können.

Die Hauptfrage ist aber nicht, welche Sprache der vierten Generation sich durchsetzen wird. Viel wichtiger ist die Frage, ob Fundament oder Gerüst. Wer sich dafür entscheidet, sein Firmen-Know-how in eine nicht normierte Sprache einzubetonieren, wählt das Fundament, und er baut sein Softwaregebäude auf dieser Sprache auf. Mit jeder Änderung am Fundament wird es auch entsprechende Auswirkungen auf das darauf stehende Gebäude geben. Und die nicht normierten Sprachen der vierten Generation haben bekanntlich eine hohe Änderungsrate.

Anders sieht es mit den normierten Sprachen der dritten Generation und den Produkten des Marktführers aus. Es hat zehn Jahre gedauert, um den letzten Cobol-Standard durchzusetzen. Er ist aber jetzt weltweit akzeptiert und gilt als Norm sowohl in der PC- als auch in der Großrechnerwelt. Es ist jetzt schon möglich, Cobol-2-Module unverändert von einem Host auf einen Vorrechner zu übertragen; man kann also die Programme am Host entwickeln für den Einsatz auf einem Mikroprozessor. Es ist daher sehr unwahrscheinlich, daß der jetzige Cobol-Standard sich bald ändert.

Ähnlich sieht es mit den Produkten des Marktführers aus. Fast alles, was die IBM entwickelt hat, ist irgendwann zum De-facto-Industriestandard geworden, ob Betriebssystem oder Datenbanksystem. Mit DB2 und SQL wird es nicht anders gehen. Und wenn diese Entwicklungen sich durchgesetzt haben, lassen sie sich aufgrund der großen Kundenanzahl kaum ändern.

Was James Martin als Unbeweglichkeit anprangert, ist im Grunde genommen eine Segnung. Wer baut, möchte auf einem festen Fundament bauen und nicht auf einem Flußbett.

Wer aber seine Firmensoftware in eine der vielen Sprachen der vierten Generation, außer SQL, eingießt, geht einen gefährlichen Weg. Es ist nicht abzusehen, ob die Datenbanksysteme, auf denen diese Sprachen bauen, sich in Zukunft behaupten werden. Die IBM wird gewiß nicht zuschauen, wie ihr dieser wichtige Markt weggenommen wird.

Es ist daher keineswegs Trägheit oder Änderungsunfreundlichkeit, wenn die DV-Anwender nicht in Massen von der dritten zur vierten Generation überlaufen. Die vierte Generation ist eben nicht ausreichend gesichert, um darin so viel zu investieren,

insbesondere, wenn es dazu handfeste Alternativen gibt.

Eine solche Alternative ist eine Soltware-Produktionsumgebung als Gerüst mit einer international genormten Sprache als Fundament. Wichtig ist die Zielsprache. Die Programme müssen eine modulare, strukturierte Form haben, um unabhängig von den für die Konstruktion benötigten Werkzeugen weiterleben zu können.

Um die Abhängigkeit von der jeweiligen DB/DC-Umgebung zu gewährleisten, sollten die Onlineprogramme+ auch in einen variablen DB/ DC-Rahmen mit einer einheitlichen DC-Steuerung und einer relationalen Datenumsetzung eingebettet sein. Auf diese Weise läßt sich die Softwareinvestition der Anwender am besten langfristig schützen.

Die Programme selbst gleichen einem Gebäude, das auf einem festen Fundament steht. Die Produktionsumgebung ist ein Gerüst, das man benutzt, um das Gebäude zu errichten. Wenn es einmal steht, kann man das Gerüst jederzeit abbauen. Das Gebäude steht für sich. In Anbetracht der raschen technologischen Entwicklung ist man gut beraten, über diese Alternative nachzudenken.

Quelle: Software Engineering Newsletter, Heft 24, April 1986; herausgegeben von SES Software Engineering Service GmbH, Neubiberg.