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.

19.01.1990 - 

Ob bei der Wartung oder bei der Neuentwicklung

4GLs sind eher ein Werkzeug als eine Programmiersprache

Es klingt widersprüchlich, doch wer heute von Sprachen der vierten Generation spricht meint weniger die Programmiersprache als das Werkzeug. Nicht auf die Sprache, in der ein Programmcode entsteht, kommt es laut Marc Hirschleber an, sondern auf ein ausgeteiltes Entwicklungs- oder Re-Engineering-Konzept.

Der Begriff der 4GL, insofern damit eine Sprache bezeichnet wird, ist konzeptionell zu eng gefaßt. Als reine Sprache der vierten Generation bleiben entsprechende Produkte auf kleinere Anwendungen wie Ad-hoc-Abfragen oder Reports beschränkt.

Das Software-Engineering-Konzept ist, und bleibt der entscheidende Punkt. Ob 4GL, CASE, ICASE, Software-Engineering mit mehr oder weniger Computerunterstützung oder Re-Engineering, in jedem Fall dreht es sich um die Lösung einer zumeist betriebswirtschaftlichen Aufgabenstellung mit Hilfe entsprechender Software. Fest steht, daß die entscheidende Bedeutung sowohl in der Neuentwicklung als auch im Wartungsfall dem zugrundeliegenden Konzept der Software-Erstellung zugutekommt: dem Engineering. Die vielfach angesprochene methodische Integration unterstützender Werkzeuge ist dann nur noch eine konsequente Fortführung zur Erzielung eines hohen Automatisierungs- und damit Produktivitätsgrades.

Über Software-Engineering-Konzepte (Phasenmodell, ADE, SPU, IPSE, und so weiter) wurde an anderen Stellen bereits vieles gesagt (vergleiche CW Nr. 24 vom 9. Juni 1989, Seite 30-43); wichtig sind die Rahmenbedingungen, mit denen wir unweigerlich konfrontiert werden und nicht der "Schall und Rauch" der obengenannten Begriffshülsen.

Standards, Automation und ingenieurmäßiges Vorgehen sind die Basis, um zu einem einheitlichen Anwendungsentwicklungsprozeß zu gelangen, in welchem die vorhandenen Hilfsmittel methodisch integriert werden. Für die einzubindenden Tools wie 4GLs heißt das, eine offene Architektur anzubieten und sich an Standards der DV-Welt zu orientieren. Der Zugriff auf eine zentrale Informationsbasis (dem Repository) bedeutet aktuelle und umfassende Kommunikation zwischen Entwicklern, Entwicklern und Endanwendern, Werkzeugen auf der Workstation, Werkzeugen des Host's und Kooperation zwischen Host und Work-Station.

Neben dem Repository ist ein Standard hinsichtlich einheitlicher Benutzeroberfläche unerläßlich, um im Software-Erstellungsprozeß zu portablen, wartungsfreundlichen Programmsystemen zu kommen.

Das Angebot an Software-Engineering-Tools ist unüberschaubar, der Zuwachs an Re-Engineering-Werkzeugen enorm. Reine MS-DOS-basierende Tools (Workstation) werden genausowenig überleben wie Produkte, die die genannten Rahmenbedingungen nicht erfüllen können.

Re-Engineering ist hervorgetreten durch den hohen Bedarf an zu überarbeitender Software (Wartung). Hierbei handelt es sich sowohl um Fehlerkorrekturen wie auch Anpassung an wirtschaftliche Gegebenheiten ein somit immerwährender Prozeß, der auch durch qualitativ hochwertigere Software nie ausgeschaltet werden wird. Mit herkömmlichen, manuellen Methoden wenden Unternehmen bis zu 80 Prozent ihres Personals für das Weiterpflegen bestehender Software auf. Damit ist eine generelle Daseins-Berechtigung entsprechender Werkzeuge gegeben, um die zu wartenden Programme zumindest besser und schneller zu verstehen. Wie kann Re-Engineering uns bei der Programmpflege unterstützen? Indem wir

1. die Grundprinzipien des Software-Engineering beachten

2. uns nicht mit reinem Reverse-Engineering zufriedengeben

3. nicht blind den Versprechungen der Re-Engineering-Toolanbieter Glauben schenken

4. Re-Engineering nicht als Projekt verstehen, mit dem global das gesamte Unternehmen "umgestellt" werden kann.

Nehmen wir als Beispiel ein Kraftfahrzeug: Das physikalische Design läßt sich zerlegen (Reverse-Engineering) in Reifen, Gangschaltung, Motor, Fahrgestell, Fenster, und so weiter. Doch diese Bestandteile ergeben durch neue Zusammensetzung kein besseres Kraftfahrzeug. Erst über das logische Design eines Fortbewegungsmittels verstehen wir das Wesentliche des Engineering-, und nur aus diesem Verständnis heraus können wir zu einem "besseren" Kraftfahrzeug gelangen.

Re-Engineering verbessert kein schlechtes Design

Ersatz bestehender Software-Systeme durch automatisierte Reverse-Engineering-Tools hat nicht viel Effektivität bewiesen, da wir weiterhin mit schlechtem Design dastehen können. Auf jeden Fall müssen Elemente zusätzlichen System-Design's einfließen, um zu einem besseren System zu gelangen.

Viele am Markt erhältliche Werkzeuge unterstützen uns, das vorliegende Programm zu verstehen und verbessern die optische Struktur des Programmablaufes. Damit allein ist ein schlechtes System nicht in ein gutes zu verwandeln. Der Ansatz für das Re-Engineering liegt

1. im Erkennen der vorhandenen Abläufe und Datenstrukturen (Analyse zu wartender Programme) und

2. in der Übergabe dieser Informationen an ein Analyse-/Design-System zur (gewohnten) Weiterverarbeitung (Software-Engineering)

Während Punkt 1 von einigen Produkten bereits zufriedenstellend gelöst wird, stellt die Informationsweitergabe für viele Firmen ein Buch mit sieben Siegeln dar. Erwähnenswert scheinen mir das Via/Center-Konzept von GEI, die Bachman-Tools und die von Pansophic vertriebene Produktreihe Pathvu/Retrofit/Datatec. Leichter fällt es dabei Softwarehäusern, die seit Jahren an einem zukunftsträchtigen Software-Engineering-Gesamtkonzept arbeiten, in das es die Informationen des Re-Engineering einfließen zu lassen gilt.

Firmenweite Lösungen sind bisher nicht erprobt

Entsprechende Tools, die lediglich isoliert Programme analysieren, werden auch in Zukunft MS-DOS-basiert bleiben, die analysierte Daten nicht im Repository ablegen können und damit keine geeignete Schnittstelle zu anderen Werkzeugen anbieten, bringen dem Anwender mittel- bis langfristig mehr Probleme als Vorteile ein.

Ansätze, die Re-Engineering als betriebsweite Problemlösung verstehen, entbehren jeglicher Praxiserfahrung. Derartige Projekte können - wenn sie überhaupt beendet werden ihre Investition nicht rechtfertigen. Der äußere Einfluß diktiert jeder Unternehmung ständige Anpassungen auf, die entweder unberücksichtigt bleiben müssen oder dazu führen, daß das Projekt nie endet.

Weiterhin suggerieren Software-Anbieter dem Anwender ein komplettes Tool an die Hand geben zu können, das den Prozeß des Analysierens zu wartender Programme und den darauffolgenden Engineering-Part durchgängig unterstützt, alle Aspekte des eigenen Konzepts berücksichtigt und zudem auch noch das "beste" Werkzeug darstellt. Die Umsetzung dieser Argumentation entsprechender Software-Anbieter und Beratungsgesellschaften schlägt beim Recycling genauso fehl, wie vor Jahren auch in der Software-Neuentwicklung (Engineering).

Weiterpflegen alter Programme können wir prinzipiell bejahen, aber nicht ohne die Wirkungen auf den weiteren Engineering-Prozeß zu beachten. Die Übergabe von Analyse-Informationen aus dem Re-Engineering an Analyse-/Design-Systeme zu realisieren, bedeutet, die vorhandene Entwicklungsbasis zu überprüfen beziehungsweise ein neues Konzept aufzubauen.

Eine Tool-Infrastruktur vorausgesetzt sie ist methodisch integriert - kann heute bereits sehr viel bewirken, wenn grundlegende Aspekte Berücksichtigung finden: Neben Standards. Repository und SAA, die die Rahmenbedingungen der Software-Erstellung abstecken tritt der Software-Lebenszyklus als solcher.

Ob Neuentwicklung oder Pflege vorhandener Programme, die Frage der Weitergabe von Informationen nach der Analyse, Speicherung im Repository und Umwandlung in Design-Informationen ist von Relevanz. Dabei heißt es, im Design lediglich zu spezifizieren, was der aus Produktivitätsgründen folgende Generator in eine standardisierte Sprache (zum Beispiel Cobol, PL/1) übersetzt. Pseudo-Code können wir hier genausowenig gebrauchen wie neue Makro- oder 4G1--Sprachen, da der Pflegeaufwand dieser Informationen im Repository zu Verhältnissen führen wird, wie wir sie jetzt bei der allgemeinen Wartung von Programmsystemen vorfinden (einmal abgesehen von den anderen Nachteilen, die derartige Sprachen dem Benutzer bescheren).

In Zukunft werden wir unsere gesamten Design-Infomationen in deklarativer Form ablegen. Bei der Fill-in-the-blank-Technik, die den Benutzer bei seiner Problem-Spezifizierung größtmögliche Unterstützung zukommen läßt, erfolgt die Ablage der Design-Informationen im Repository, auf das leistungsfähige Generatoren zugreifen können und somit standardisierten, pflegeleichten Code erstellen. Repository und IRDS-Standard ermöglichen das Kommunizieren der Tools untereinander, so daß keine Abhängigkeit von Anbietern beziehungsweise Werkzeugen entstehen kann und somit freie Wahl beziehungsweise Ersatz entsprechender Tools möglich wird. Der Benutzer kann sich für die individuell beste Tool-Kombination entscheiden!

Heißt es nun generell mit Hilfe des Generators neu zu entwickeln? Diese Fragestellung ist irrelevant. Der Generator bringt uns Produktivität (vorrangig in der Wartung) durch Standardisierung. Er ist ein Teil unseres Engineering-Konzeptes, das die bedeutenden Phasen zuvor bereits definiert. So ist nach der Analyse eines alten wie auch neu zu entwickelnden Programmes das Design oder Re-Design von entscheidender Bedeutung. Re-Engineering ohne Re-Design wirft die Frage auf, warum dann Oberhaupt Re-Engineering? Nur um der möglicherweise schlechten Lesbarkeit abzuhelfen. Sicherlich nicht. Um die Programme unter Zuhilfenahme eines Generators auf einen einheitlichen Standard zu bringen. Dafür dürften bei den meisten Firmen wohl die Kapazitäten fehlen, auch wenn dieser Aspekt wünschenswert erscheint.

Der einzelne Wartungsfall sollte die Entscheidung bringen, ob sich der Re-Engineering-Aufwand lohnt. Sind die Änderungswünsche zu umfangreich, ist - eine Neuentwicklung zu empfehlen. Dabei ist generell zu berücksichtigen, daß die "Neu-Analyse" im Verhältnis zur "Alt-Analyse" wesentlich aufwendiger ausfallen kann. Im Re-Engineering-Fall sprechen wir prinzipiell von Weiterpflegen. Genaugenommen müßten wir von Weiterpflegen und Neuentwickeln sprechen, wenn wir die Re-Engineering-Informationen in den (gewohnten) Entwicklungs-Prozeß einfließen lassen.