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.

14.07.1995

Eine kurze Geschichte der Software-Entwicklung (Teil 2 und Schluss) Homogene Programmerstellung bleibt ein unerfuellbarer Traum

14.07.1995

Von Reinhold Thurner*

Die Vorgehensweise nach dem Wasserfallmodell stiess Anfang der 80er Jahre an ihre Grenzen: Sie bot keine Unterstuetzung fuer Entwicklungssprachen der vierten Generation (4GL). Die Befuerworter des Rapid Application Development (RAD) bemuehen sich neuerdings wieder um einen groesseren Ansatz. Aber voellig homogene Umgebungen sind illusorisch.

Mit der zunehmenden Verbreitung von Online-Systemem wurde die Schwerfaelligkeit der technischen Systeme zu einem immer groesseren Aergernis. Das betraf nicht nur das Projektvorgehen, sondern auch den Methodenansatz im allgemeinen: Waehrend sich die Methodiker mit anspruchsvollen Systemfragen der Optimierung von Ablaufnetzen befassten, drueckte den Anwendungsentwicklern der Schuh bei elementaren Problemen der Online-Programmierung. Der teilweise absurde Aufwand fuer die Aenderung eines einzigen Feldes, die Programmierung der Oberflaeche, die Einhaltung der Schnittstellen, die Verwaltung der Transaktionen und Datendefinitionen - das waren die Probleme, mit denen er in der Praxis zu kaempfen hatte.

In diese Bresche sprangen die Programmiersprachen der vierten Generation. Sie setzten dem Wasserfall-Modell ihren "Prototyping- Ansatz" entgegen und erweiterten die isolierte Programmsicht zu einer umfassenden Daten-System-Sicht. Die unkontrollierten Programmbibliotheken wurden durch die Speicherung der 4GL- Programme in der Datenbank ersetzt, die Programmierung erfolgte online unter Kontrolle des Datenbanksystems.

"Natural" und "Ideal" machten es vor. Sie zeigten, wie rasch und einfach sich eine Abfrage, eine Auswertung, ein Update-Programm oder ein Menue erstellen und sofort in Produktion ueberfuehren liess. Die "normierte Programmierung" fuer die Online-Programmierung war gefunden - einfach, effizient und optimal an die Aufgabe angepasst.

PC-Tools fordern die 4GLs heraus

James Martin verkuendete die Zukunft des Rapid Application Development. Sein Buch "Programming without Programmers" (1984) wurde zum Bestseller in den Chefetagen. Bei Informationssystemen, die sich im wesentlichen auf Datenpflege und -abfragen beschraenkten, sollte das Konzept auch funktionieren.

Doch bei den Endbenutzern erwuchs den grossen Sprachen der vierten Generation unerwartet Konkurrenz durch die PC-Software. Diese Werkzeuge waren in ihrer Einfachheit nicht zu schlagen. Damit waren die 4GL-Anbieter gezwungen, sich auf ihre Mainframe-Pfruende zurueckzubesinnen und ins "normale" Projektgeschaeft einzusteigen.

Die Sprachen wurden erheblich erweitert (und dadurch nicht eben einfacher). Generatoren fuer Natural, Ideal etc. tauchten auf und wurden als 4GL-Uebersprachen deklariert. Und damit waren sie mit den ueblichen Problemen komplexer Projekte konfrontiert.

Der PC unter DOS wurde lange Zeit lediglich als Text- und Tabellenkalkulations-Maschine verwendet. Aber um die Mitte der 80er Jahre entstanden ploetzlich immer mehr Anwendungen unter Dbase und Turbo-Pascal. Mit der Verfuegbarkeit von Windows und immer leistungsfaehigerer Hardware machte der Microprozessor-basierte Rechner das End-User-Computing zusehens fuer anspruchsvolle Aufgaben tauglich.

Mit seinen Grafikfaehigkeiten, seiner weiten Verbreitung und seinem erschwinglichen Preis wurde der PC auch die ideale Maschine fuer ein Heer von Einzel-Software-Entwicklern, die sich die teure Infrastruktur eines Mainframes nicht leisten konnten. So begann - zunaechst mit Dbase und Pascal - eine ganz neue Entwicklerkultur heranzuwachsen. Sie wurde von den Softwarespezialisten, die "ernsthafte Entwicklung" betrieben, zunaechst belaechelt, aber sie war nahe am Kunden, weil sie ihm die Flexibilitaet einer raschen Ad-hoc-Loesung liefern konnte.

Auch die Grossrechnerwelt entdeckte den PC als Entwicklungsumgebung: CASE-Tools wurden bald nur mehr fuer den PC entwickelt. Der PC wurde durch die Emulatoren von Micro Focus und Realia vor allem in den USA zur Cobol-Entwicklungsmaschine fuer Mainframe-Anwendungen.

Mit den PC-CASE-Tools wurden die schon ad acta gelegten strukturierten Methoden wieder aus dem Schrank geholt. Dazu trug nicht zuletzt die Abkehr der Datenbankhersteller vom einseitigen "Rapid-Prototyping"-Gedanken und ihre Hinwendung zu den Methodenansaetzen bei.

Die CASE-Systeme brachten den Teams, die die Methoden beherrschten, tatsaechlich eine erhebliche Steigerung der Qualitaet und der Produktivitaet ein - und zwar nicht nur, was die Zahl der Codezeilen betraf, sondern auch in Form besserer, kundengerechterer Systeme. Nur waren die Methodenkenntnisse duenn gesaet, denn es bedurfte einer langen Ausbildungs- und Anlaufzeit, um dieses Know-how zu erwerben. Der Methodenstreit zwischen einer Vielzahl von Gurus erleichterte die Wahl und Ausbildung auch nicht gerade.

Die CASE-Hersteller sahen sich deshalb genoetigt, CASE "einfach" zu machen: Statt des Erlernens komplizierter Methoden ein "Maustreiber-Kurs", und schon waren die schoensten Diagramme und Bilder auf dem Bildschirm. Ohne das notwendige methodische Wissen blieb der Erfolg jedoch aus, und die Entaeuschung war entsprechend herb. CASE geriet in der Folge zunehmend in Verruf, und fuer die Hersteller brachen harte Zeiten an.

Versuch einer Totalintegration

Ploetzlich hiess es, CASE sei unbefriedigend, weil damit nur die Modellierung in den fruehen Entwicklungsphasen moeglich sei, bei der Realisierung jedoch ein Bruch entstehe. Folglich koenne keine Verbindung mehr hergestellt werden zwischen den Modellen der fruehen Phasen und der Implementierung. "Integration von Design und Realisierung" lautete der Anspruch, und gemeint war der nahtlose Uebergang von einer Entwicklungsphase in die naechste innerhalb desselben Systems.

Die Datenbankhersteller hatten die Bedeutung der methodischen Basis fuer ihr Geschaeft rasch erkannt. Als "Besitzer" der Daten und mit den Moeglichkeiten der 4GL-Technik ausgestattet, waren sie in der besten Position, die Fruechte der Methodik zu ernten. Waehrend die isolierten PC-CASE-Tools mit immer groesseren Schwierigkeiten kaempften, fand die Wiederentdeckung methodischer Ansaetze bei den Datenbankmogulen statt. Sie integrierten CASE in ihr Angebot mit dem Ziel, eine "durchgaengige Loesung" anzubieten.

Die Software AG suchte die Loesung in der Zusammenarbeit mit Ploenzke und integrierte die Methode "Isotec" mit ihrem 4GL-System Natural. Zum Begriff geworden ist auch "Oracle-CASE". IBM versuchte den grossen Wurf mit "AD/Cycle", dessen Kernstueck das Datenbanksystem DB2 und ein darauf basierendes umfassendes Repository sein sollten.

Nur wenige selbstaendige CASE-Tools vermochten sich zu halten: Dazu zaehlen "IEF" fuer Grosscomputer-Anwender und "Systems Engineer" von LBMS als PC-Netzwerkloesung.

Das Projekt-Management spielt wieder eine Rolle

Nach 1982 war es ziemlich still geworden um das Thema Projektabwicklung und strukturierte Entwicklung. Der Verlust der Projektkontrolle bei grossen Online-Projekten und Migrationen rueckte das Problem jedoch wieder in das Bewusstsein. ISO 9000, das Fuenf-Stufen-Modell der Softwarereife nach Watt S. Humphrey, die Entwicklung der Euromethode durch Verschmelzung von Merise und einem voellig ueberarbeiteten SSADM sowie der deutsche Beitrag mit dem V-Modell fielen alle in die Jahre 1989 bis 1994.

Mittlerweile sahen sich die Entwickler einer immer groesseren Komplexitaet der Komponenten und ihrer Zusammenhaenge gegenueber. Ueberdies wurde es immer schwieriger, die Arbeit vieler Spezialisten zu koordinieren. Ein steigender Anteil an "organisatorischer Abstimmung", dazu unproduktive Sitzungen, Missverstaendnisse und Qualitaetsmaengel uebten den notwendigen Druck aus, damit sich die Anwenderunternehmen wieder mit Projektabwicklungsfragen befassten.

Die Nachfrage nach modernen Benutzeroberflaechen und das Client- Server-Modell fuegten der gesamten Methodenwelt einen Bruch zu. Die Modularisierungskonzepte und Werkzeuge taten sich sehr schwer mit der Komplexitaet der ereignisgesteuerten Systeme und der Aufteilung von Applikationen nach dem Client-Server-Modell.

Die Benutzer waren verwoehnt von den grafischen Benutzeroberflaechen ihrer PCs und forderten Anwendungen auf der gleichen Basis. Klassische Terminalloesungen litten unter drastischem Imageschwund, galten als antiquiert und wurden zunehmend unverkaeuflich.

Kometenhaft stiegen neue Sterne am Softwarehimmel auf: allen voran Microsoft mit dem sich als Standard etablierenden Windows und der Office-Suite. Im Entwicklungsbereich waren es wieder die Programmierwerkzeuge (und nicht CASE), die Furore machten.

Visual Basic erreichte eine schier unglaubliche Verbreitung und schuf mit den VBX/OCX-Controls einen Standard und einen Komponentenmarkt, wie man ihn noch nie gekannt hatte. Powerbuilder und SQLwindows verdraengten die althergebrachten Programmiersprachen auf dem PC. Borland kam relativ spaet - aber technisch eindrucksvoll - mit Delphi. Eine Stufe anspruchsvoller sind die Smalltalk-basierten Systeme von Digitalk, Parkplace, IBM und Enfin.

Diese Werkzeuge durchbrachen viele der liebgewordenen Grenzen zwischen Analyse, Design und Programmierung. Protoyping wurde nun wirklich machbar und erbrachte fuer einen gestandenen traditionellen Programmierer absolut niederschmetternde Erfolge. Zu allem Ueberfluss fanden auch die Kunden die Ergebnisse der neuen Tools viel einfacher und besser.

Die methodische Grundlage aller dieser Systeme ist der objektorientierte Ansatz, der ein inkrementelles Entwicklungsvorgehen foerdert. Das System wird als ein Netz kommunizierender Objekte verstanden, die alleinige Oberhoheit ueber ihre jeweiligen Daten besitzen und Nachrichten miteinander austauschen. Durch Klassenbildung und Vererbung wird es moeglich, umfangreiche realisierte Teile (ganze "Klassenbibliotheken") zu uebernehmen. Dabei muessen nur die notwendigen Veraenderungen durchgefuehrt werden, ohne die beerbten Codeteile zu veraendern.

Die Objektorientierung hat fuer die Frage nach rascherer Entwicklung eine neue und einleuchtende Anwort bereit - Mehrfachverwendung. Statt immer alles neu zu entwickeln, sollen vorgefertigte Objekte und Methoden (nicht einfach nur Code!) aus einer Klassenbibliothek vererbt werden. Das hat nichts mehr mit dem Copy-and-edit-Verfahren der alten Welt zu tun, sondern ist systematische industrielle Komponenten-Entwicklung.

Keine eindeutige Antwort auf die Verfahrensfrage

Fuer viele Programmierer ist aber bereits der erste Schritt in diese Welt ein Problem: Es ist eine Sache, ein Programm mit minimaler Benutzer-Interaktion (zwoelf Funktionstasten) zu schreiben, das durch ein selbstgeschriebenes Hauptprogramm gesteuert wird. Ein ander Ding ist es, fuer Hunderte moeglicher Ereignisse eine angemessene Reaktion in Event-Prozeduren vorzusehen. Einen ebenso grossen Unterschied macht es, ob ich ein Programm in allen Teilen selbst schreibe oder eine OO-Prozedur (sprich Methode) entwickle, die einen Grossteil ihrer Funktionalitaet erbt und ihre Aufgaben durch Absetzen von Nachrichten an andere Objekte delegiert. Doch wer die Methoden der strukturierten Welt zu beherrschen gelernt hat und sich mit Bausteintechnik und Macros vertraut gemacht hat, wird sich auch in der neuen Umgebung rasch zurechtfinden.

Welches Verfahren heute anzuwenden sei, um Software zu entwickeln, ist zu einer nicht mehr eindeutig beantwortbaren Frage geworden. Software ist in zu unterschiedlicher Gestalt vorhanden. Die Zeit der homogenen Entwicklung ist wohl vorbei.

Ein Unternehmen benutzt die Office Suite von Microsoft - und hat damit automatisch ja zu Visual Basic gesagt. Aber bereits fuer mittlere Anwendungen scheint sich Visual Basic nicht zu eignen. Also ist ein weiteres Werkzeug fuer umfangreichere Entwicklungen auf dem PC notwendig. Dieses ist aber moeglicherweise nicht geeignet, um Software fuer den Host oder die Transaktionsumgebung zu schreiben - also benoetigt man... Und ueberdies hat man dann noch diese oder jene Standardsoftware im Haus mit ihrer eigenen, oft antiquarischen Entwicklungsumgebung.

Gesetzt den Fall, die Entwickler beherrschen die Programmierung mit einem Werkzeug - wie gehen sie nun grosse und massive Projekte an? Die Geschichte wiederholt sich. Auch die objektorientierte Programmierung mausert sich ueber kurz oder lang zum objektorientierten Software-Engineering (vgl. Rumbaugh 1991, Jacobson 1992 etc.) mit umfassendem Anspruch. Und entsprechend emsig wird an der objektorientierten Metamorphose der CASE- Werkzeuge, der Datenbanken und der Middleware gearbeitet.

*Dr. Reinhold Thurner ist Unternehmensberater im schweizerischen Herrliberg. Der erste Teil seines Beitrages wurde in CW Nr. 27 vom 7. Juni 1995 auf Seite 31 veroeffentlicht.