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.

18.07.1986

Kritik an der umstrittenen Sprache gerät zunehmend ins Hintertreffen:Ada reduziert Teilphasen um bis zu 50 Prozent

Enthusiasmus und heftige Kritik an der Programmiersprache Ada halten sich derzeit in der DV-Welt noch die Waage. Eine Benutzerumfrage über laufende Ada-Projekte bei fünfzehn Unternehmen in Europa und den USA ergab jedoch ein eindeutig positives Ergebnis für die ersten Abschnitte im Lebenszyklus der relativ jungen Sprache.

Bereiche der Untersuchung waren in erster Linie solche, die zu Bedenken oder gar Ablehnung von Projektleitern von auszuführenden oder neuen Projekten führen, in denen Ada verwendet werden soll. Zu nennen sind hier Training, Programmierer-Produktivität, Portierbarkeit der in Ada geschriebenen Programme, Wiederverwendbarkeit und die Vor- und Nachteile einer Programmierumgebung (ASPE).

Die gesammelten Erfahrungswerte beziehen sich auf reine Industrieprojekte. Compilerprojekte wurden bei dieser Untersuchung ebenfalls nicht berücksichtigt.

Nach Ausschluß der Zahlen für Pilotprojekte verblieben zwölf quantitative Schätzungen in bezug auf die relative Produktivität von Ada im Vergleich zu anderen höheren Programmiersprachen. Diese Schätzwerte gelten zumindest für die Zeitspanne vom Entwurf bis zur Endprüfung, berücksichtigen jedoch nicht die Pflegephase, wo Ada vermutlich die positivsten Auswirkungen haben wird. Die Zahlen entkräften in jeder Hinsicht die Behauptung, daß Ada schlechter als andere Programmiersprachen sei; folglich bleibt zu überlegen, ob Ada nicht möglicherweise besser ist. Um eine konservative abschließende Schätzung sicherzustellen, wurde von folgenden Annahmen ausgegangen:

- Wird die relative Produktivität als Verhältnis der Zahlen "Zeilen pro Zeiteinheit" berechnet, gilt Ada (wegen der Datendefinitionen) als 25 Prozent langatmiger als andere Programmiersprachen und wird folglich niedriger eingestuft.

- Wird die Wiederverwendbarkeit von Ada-Code als beitragender Faktor angegeben, wird die relative Produktivität vermindert, um sie entsprechend der üblichen Definition von Produktivität auszuschließen.

- Alle Zahlen bis auf zwei enthalten Zeit für die Gewöhnung an Ada nach der formellen Ausbildung sowie in anderen Fällen auch für die Umstellung auf eine neue Entwurfsmethode, aber die Daten werden in keiner Weise zugunsten von Ada geschönt.

- Umfaßt der Schätz- oder Meßwert auch Analysenzeit, wird keine Berichtigung vorgenommen, wodurch die relative Produktivität gegen eins tendieren würde (auf der Basis, daß die Analyse unabhängig von der Programmiersprache stets die gleiche ist).

Unter den vorgenannten Bedingungen ergibt sich die mittlere relative Produktivität von Ada gegenüber anderen höheren Programmiersprachen mit 1,35. Da die Produktivität ein Multiplikator ist, handelt es sich hierbei um ein geometrisches, kein arithmetisches Mittel.

Aus technischen Gründen hat das (arithmetische) Mittel der relativen Produktivität einen höheren Wert, nämlich 1,59. Die Standardabweichung beträgt 0,84.

Bei der Frage nach den Unterschieden, die Ada gegebenenfalls für die verschiedenen Phasen eines Projekts mit sich bringt, gaben die Anwender unterschiedliche, jedoch letztlich positive Antworten (siehe Tabelle).

Sechs verfügbare Zahlen für die Entwurfszeit lassen erkennen, daß im Vergleich zu anderen höheren Programmiersprachen ein Mehraufwand von 50 Prozent zu berücksichtigen ist. In dieser zusätzlichen Zeit wird ein Entwurf im allgemeinen gründlicher durchdacht, und die Schnittstellen zwischen den Komponenten werden mit Maschinen geprüft, woraus sich in den späteren Phasen die Ada-spezifischen Vorteile ergeben. Die Entwurfszeit muß jedoch sorgfältig überwacht werden, denn Unerfahrenheit mit der Methodik hat schon in mehreren Fällen zu unannehmbaren Überschreitungen der geplanten Entwurfsdauer geführt.

Die Codierung kann bei kleineren Projekten langsamer gehen, vielleicht weil trotzdem so viele Datendefinitionen eingegeben werden müssen. Bei umfangreicheren Projekten kann davon ausgegangen werden, daß das Codieren schneller geht.

Die Integration ist eine relativ einfache Aufgabe bei Ada-Projekten, da praktisch alle erforderlichen Prüfungen und Kontrollen schon vorher durchgeführt werden.

Die Zeit zur Behebung von Problemen ist den Angaben zufolge bei Ada wesentlich kürzer (zum Teil wegen des symbolischen Debuggers). Die Prüfung geht im allgemeinen schneller, aber die Prüfung auf Wiederverwendbarkeit beansprucht zusätzliche Zeit.

Aus sechs verfügbaren Angaben ergibt sich eine durchschnittliche Zeitersparnis von 50 Prozent in den Phasen Codierung, Integration und Prüfung gegenüber anderen Programmiersprachen. Dieser Wert kann jedoch nur mit einem Satz guter Tools erreicht werden, was insbesondere für die Integration und Prüfung wichtig ist.

Diese Zahlen können sich möglicherweise noch verbessern, wenn das Personal mit Ada und den Prinzipien des Software-Engineering besser vertraut ist.

Erfahrung in der Übertragung von Ada besitzen den Angaben zufolge 14 Anwender, und einige weitere wollen in Zukunft eine Übertragung vornehmen. Etwa eine halbe Million Code-Zeilen wurden bereits mit Erfolg übertragen (doppelt gezählt, wenn zwei verschiedene Compiler oder Zielgeräte beteiligt sind). Die erforderlichen Änderungen liegen im allgemeinen bei einem bis zwei Prozent oder darunter, wenn der gleiche Front-end-Prozessor verwendet wird.

Für den Übertragungsaufwand liegen nur zwei Angaben vor, die darauf hindeuten, daß einschließlich der erforderlichen Neucodierung etwa 5000 bis 10000 Zeilen pro Mann-Woche übertragen werden können.

Bei etwa 30000 bis 35000 Code-Zeilen ist die Übertragung aus einem der folgenden Gründe fehlgeschlagen:

- Der Compiler konnte den Programmumfang (mit zwei unterschiedlichen, validierten Compilern) nicht bewältigen.

- Probleme aufgrund der Übertragung auf (nicht validierte) Teil-Compiler.

- Verwendung von zuvor festgelegten numerischen Typen.

- Die zugeteilte Maschinenzeit erlaubte nach Behebung kleinerer Probleme kein Neucompilieren mehr.

- Der von einem validierten Compiler generierte Code versagte bei der Prüfung.

Nur das letztgenannte Problem ist wirklich schwerwiegend. Das vorletzte Problem ist auf Managementfehler zurückzuführen, und die übrigen Schwierigkeiten können durch Schulung und bessere Erstellung des Compilers gelöst werden.

Viele der Leistungsmerkmale von Ada und APSE werden verschiedentlich als Gründe für die hohe Produktivität angeführt. Mangelnde Produktivität hingegen wird meist auf Unerfahrenheit zurückgeführt. Die Mehrzahl der an diesen Projekten beteiligten Leute arbeiteten erstmals mit Ada, so daß die Ergebnisse die Behauptung der Skeptiker Lügen strafen, "Ada sei zu kompliziert".

Obwohl Zahlen über die Ada-Schulung nur schwierig zu erhalten und zudem ungenau sind, konnte festgestellt werden, daß die befragten Stellen, intern und extern, über 1200 Mitarbeiter aus den verschiedenen Programmdisziplinen ausgebildet haben, von denen zwischen 30 und 40 Prozent tatsächlich in laufenden Ada-Projekten eingesetzt werden. Es ist zu bedenken, daß diese Zahlen nicht mit den weit über eine Million in der Einführung genannten Code-Zeilen in Beziehung gesetzt werden dürfen, da ein Großteil dieser ausgebildeten Personen an Ada-Projekten mitgewirkt haben, die in der vorliegenden Arbeit nicht einbezogen sind.

Mindestens drei Stellen glauben, daß unterschiedliche Schwierigkeiten beim Erlernen von Ada auftreten, und zwar in Abhängigkeit von der jeweiligen Erfahrung der betreffenden Person. Programmierer im kommerziellen Bereich (zum Beispiel Cobol, RPG, Business Basic) haben vermutlich die größten Probleme, gefolgt von denen, die mit unstrukturierten wissenschaftlichen Programmiersprachen (zum Beispiel Fortran, Scientific Basic, Assembler) gearbeitet haben, während Personen, die Erfahrung mit blockstrukturierten Programmiersprachen (zum Beispiel Pascal, C, Coral) haben, Ada am einfachsten finden.

*Andreas Schneider ist Systemingenieur bei der Rolm Mil-Spec Computers GmbH, Schwalbach, Taunus. Der Beitrag ist eine stark gekürzte Fassung des Vortrags, der auf dem 2. Deutschen Ada-Anwendungskongreß Ende April 1986 in München gehalten wurde.

Assembler

Englisches Wort für betrügerischen Pokerspieler, der Asse im Ärmel seiner Jacke sammelt.

Basic

Neumodische Fremdsprache, die die heutige Jugend besser beherrscht als ihre Muttersprache. Basis der Unmöglichkeit, daß die Eltern heutzutage ihre Kinder überhaupt verstehen.

Cobol

Äußerlich menschenähnliches Zwerglein mit übersinnlichen Fähigkeiten, das zwischen den integrierten Schaltkreisen wohnt, dort seine Kreise zieht und für ungeahnte Scherze und Überraschungen im Programmablauf sorgt.

Lisp

Sprachfehler des in den fünfziger Jahren in Computerkreisen sehr berühmten John McCarthy. Er entwickelte Programme, mit denen der Computer erstmals in der Lage war, vernünftig zu reagieren, wenn der Operator spinnt.

Aus: "Computer", Tomus Verlag, München