Die Zertifizierung von Kompilierern ist in den USA bereits unabdingbare Voraussetzung, um als Anbieter von Soft- und Hardware von den dortigen Bundesbehörden anerkannt und berücksichtigt zu werden. Für Europa strebt die Gesellschaft für Mathematik und Datenverarbeitung mbH (GMD) aus Bonn zusammen mit Instituten in Großbritannien und Frankreich und mit Unterstützung der Kommission der Europäischen Gemeinschaften (EG) in Brüssel Bedingungen für eine gegenseitige Anerkennung von Prüfergebnissen und Zertifikaten an. Siegfried Mahkorn, Mitarbeiter der GMD (Gesellschaft für Mathematik und Datenverarbeitung) und dort verantwortlich für Compiler-Validationen, beschreibt in selnem Beitrag die Notwendigkeit solcher Maßnahmen.
Warum müssen Kompilierer trotz der Normungserfolge bei den Programmiersprachen noch validiert werden? Die Normen für Programmiersprachen wie zum Beispiel Cobol (DIN 66 028) und Fortran (DIN 66 027) legen zwar die Syntax der Sprache fest, für die Implementation ist dies jedoch nicht immer ausreichend. Denn manchmal ist sogar bewußt noch eine Lücke in der Sprache offen gelassen worden; eventuell ist die Norm auch nicht eindeutig, oder sie wird nicht richtig verstanden. In all diesen Fällen muß der Implementierer sich jedoch für eine einzige Lösung entscheiden. In der Praxis führt dies zu Kompiliereren die unterschiedliche Ergebnisse liefern, das heißt zu Kompiliereren mit unterschiedlicher Semantik. Diese "Fehler" sind deshalb besonders heimtückisch, weil sie nicht schon frühzeitig durch einen Syntaxprüfer (Syntaxchecker) erkannt werden können, sondern oft erst zufällig entdeckt werden. Portable Quellprogramme (source decks) sind unter diesen Umständen so gut wie unmöglich oder reiner Zufall. Beides aber ist nicht Sinn der Normung! Ihr Ziel ist es ja gerade, die Portabilität eines Programms von der Rechenanlage A auf die Anlage B eines anderen Herstellers zu gewährleisten.
Hier setzt die Validation und Zertifikation von Kompilierern an. Unter Validation versteht man in diesem Zusammenhang die Überprüfung eines Kompilierers auf Einhaltung und Erfüllung der Norm. Bei genauerem Hinsehen müßte man besser von Falsifikation sprechen, denn es kann immer nur geprüft werden, ob ein Kompilierer in Testprogrammen keine "Fehler", das heißt Abweichungen vom erwarteten Ergebnis, liefert. Wenn keine Fehler mehr festgestellt werden, heißt dies natürlich noch nicht, daß dieser Kompilierer "fehlerfrei" ist.
Objektive Wertung ist kaum möglich
Wie soll aber ein so komplexes Programm, wie es ein Kompilierer nun einmal darstellt, validieren können? Unwillkürlich drängen sich Assoziationen zu vergleichenden Warentests bei Konsumgütern auf, die meist in eine eindeutige Wertung münden. Wie will man aber zum Beispiel bei einem Kompilierer objektiv das Fehlen eines Sprachelements der Norm bewerten, wenn es sich um ein wenig oder selten benutztes Element handelt und man auf andere Weise, vielleicht etwas umständlich, denselben Effekt erzielen kann? Der eine Benutzer hat es vielleicht sogar in seinen betriebsinternen Programmierregeln verboten, während es bei einem anderen Anwender sehr oft verwendet wird. Spätestens an dieser Stelle drängt sich die Meinung auf: Validation von Kompilierern ist unmöglich!
Beim Federal Software Testing Center werden seit 1972/73 Cobol-Kompilierer auf Einhaltung und Erfüllung der Norm geprüft; und wie die Erfahrung zeigt, mit sehr viel Erfolg. Das Federal Software Testing Center ist eine zentrale Bundesstelle für Datenverarbeitung innerhalb des Software Development Office in den Vereinigten Staaten von Amerika, welches dem Automated Data and Telecommunications Service der General Services Administration (GSA) untersteht.
Das Test-Center unterhält den Kompilierer-Prüfdienst für Cobol, Fortran und Minimal Basic zusammen mit den erforderlichen Funktionen zur Unterstützung der General Services Administration im Bereich der DV-Beschaffung sowie zur Durchsetzung von Beschaffungsrichtlinien zum Erwerb von Software durch Bundesbehörden. Allerdings steht das Beschaffungsamt der Regierung in nicht unerheblichem Maße für diesen Erfolg. Keine Bundesbehörde kann Hardware kaufen oder mieten, wenn nicht für den auf dieser Hardware laufenden Cobol-Kompilierer ein Validationsbericht (VSR: Validation Summary Report) beziehungsweise ein Zertifikat vorliegt.
Dieser individuelle Validationsbericht unterscheidet sich allerdings ganz erheblich von dem, was uns normalerweise als vergleichender Testbericht geläufig ist. In einem solchen Validationsbericht wird sine ira et studio aufgezeigt, was getestet und was, warum nicht getestet wurde. Ein Beispiel: Die Computeranweisung bleibt ungetestet, denn die Norm überläßt es dem Hersteller, mit welcher internen Genauigkeit Zwischenergebnisse ermittelt werden. Unter diesen Umständen kann es natürlich auf zwei unterschiedlichen Rechenanlagen verschiedener Hersteller zu unterschiedlichen Ergebnissen kommen. Letztlich sind diese internen Genauigkeiten nicht von der benutzten Programmiersprache, sondern von der Architektur und dem Betriebssystem des Rechners abhängig. Es istohne Zweifel ein Unterschied, ob ein "Wort" aus vier Bytes zu je acht Bits (3-2 Bits) oder aus vier Bytes zu je neun Bits (36 Bits) oder aus drei Bytes zu je 8 Bits (24 Bits) besteht.
Die Beschaffungsregeln für die amerikanischen Bundesbehörden sehen vor, daß nur validierte und zertifizierte Kompilierer und deren Hardware beschafft werden dürfen. Ein Zertifikat wird bei erstmaliger Validation (fast) immer erteilt, gleichgültig wie gut oder wie mangelhaft ein Kompilierer ist. Nur in einem Fall können sich die Mitarbeiter des Federal Software Testing Center daran erinnern, daß ein Kompilierer nicht zertifiziert wurde, weil er schon in den einfachsten Anweisungen zu viele Fehler aufwies. Vor kurzem wurde aus England bekannt, daß ein Cobol-Kompilierer der Firma ICL nicht validiert und damit auch nicht zertifiziert werden kann, weil noch nicht einmal das Validationssystem selbst implementiert werden konnte!
Ein solches Zertifikat ist auf die Dauer von zwölf Monaten begrenzt. Danach erlischt es automatisch, falls es nicht rechzeitig aufgrund einer nochmaligen Validation erneuert wird. Erst wenn bei einer solchen Folgevalidation noch Fehler aus der Vorgängervalidation vorhanden sind, wird kein neues Zertifikat erteilt. Neue Fehler oder Abweichungen berühren die Zertifizierung zunächst nicht. Das Zertifikat wird also auf Treu und Glauben erteilt; nämlich darauf, daß innerhalb eines Jahres die aufgetretenen Fehler beseitigt werden. Diese Methode trägt außerdem der Tatsache Rechnung, daß etwa 80 Prozent der Fehler in einem Kompilierer durch Verbesserung anderer Fehler verursacht werden.
Durch diese Maßnahme wird erreicht daß Validation und Zertifizierung überhaupt erst in vernünftiger Weise gehandhabt werden können. Außer den oben genannten Schwierigkeiten gibt es nämlich noch zwei weitere. Eigenschaften, die ohne diese Vorgehensweise einen Test abwerten könnten: Sowohl der Kompilierer wird geändert als auch die Testroutinen werden erweitert und präzisiert. Beide Tatsachen wirken sich aber erst bei einer Folgevalidation aus!
Ingesamt gesehen hat sich dieses System in den USA bestens bewährt, zeigt es einem Hersteller doch nicht nur die Schwachstellen seines Kompilierers gegenüber einer "amtlichen Testversion" auf, sondern motiviert ihn auch gleichzeitig zur Verbesserung seines Produkts innerhalb eines Jahres.
Jedermann, auch jeder Hersteller kann die letztgültigen Testroutinen gegen eine entsprechende Gebühr erwerben. Geliefert wird ein Handbuch und ein Magnetband mit den Routinen und einigem mehr. Auf diesem Band sind alle herstellerabhängigen Namen in den einzelnen Testprogrammen mit einem Pseudonamen angegeben. Mittels eines Aufbereitungsprogramms, welches ebenfalls auf dem Band enthalten ist, werden einzelne Programme oder mehrere zusammengehörige Programme selektiert und für die Kompilierung und Ausführung vor- und aufbereitet. Mittels einer herstellerspezifischen Datei werden die Pseudonamen durch den zutreffenden Funktionsnamen ersetzt. Gleichzeitig können die für die Kompilierung und Ausführung notwendigen Steuerkarten an den richtigen Stellen eingesteuert werden. Je nach Betriebssystem handelt es sich dabei um 5000 bis 20 000 ICL-Karten! Durch Angabe von Parametern können einige Sprachelemente aus dem Test herausgenommen werden (zum Beispiel VALUE OF . . . im FD-Eintrag).
Individuelle Eingriffe sind unseriös
Ergibt schon die Kompilierung ?????ler, so sind diese genau zu analysieren und unter Umständen so zu korrigieren, daß das Testergebnis nicht verfälscht wird. Solche Korrekturen können bestehen aus: Entfernen, Andern und Überschreiben von Anweisungen (= Zeilen im Quelltext). All dies wird über die oben genannte Datei gesteuert, so daß über alle Änderungen ein genaues Protokoll durch das Selektions- und Aufbereitungsprogramm erstellt werden kann. Jeder individuelle, manuelle Eingriff direkt am Quelltext entspricht nicht den strengen Maßstäben, die an eine seriöse Validation angelegt werden müssen.
Ist eine Kompilierung erfolgreich (und im Sinne der Validation richtig) abgeschlossen, kann es an die Ausführung gehen. Alle Testprogramme sind so aufgebaut, daß sie selbst einen Soll-Ist-Vergleich durchführen, ????fern dies möglich ist, und ein ent????rechendes Prüfprotokoll ausdrukken. Hierin sind Facts festgehalten wie etwa der Name des Programms Hinweise auf jeden durchgeführten Test mit "true" oder "fail" und die Paragraphenangabe, wo im Quellprogramm der Test codiert ist. Bei Abweichungen enthält der Output die Angaben "correct" und "computed" bei Übergehen von Tests einen entsprechenden Hinweis ("deleted") und am Schluß eine Summe für die Gesamtzahl der Tests im Programm sowie die Anzahl der übergangenen, fehlerhaften, fehlerfreien Tests.
Nur dort, wo es unumgänglich ist muß der Prüfer durch intensive manuelle Kontrolle die Prüfung vornehmen. Dies gilt für alle Write-Anweisungen in Verbindung mit dem Linage-Zusatz, alle Programme aus dem Modul "Communication" und für den Test mit dem ASCII-Code beschriebenen Bändern. Einige Tests müssen bei Anwesenheit des Validationsleiters im Rechenzentrum wiederholt werden, da es sich hierbei um Prüfungen von Funktionen handelt, die nur durch Augenschein auf ihre Richtigkeit überprüft werden können. Es handelt sich hierbei vor allem um die verschiedenen Bandwechselfunktionen .
Drei Wege führen zum Zertifikat
Will ein Hersteller seine Hard-oder Software an den größten Kunden der Welt, das Federal Government der USA, verkaufen oder vermieten, so muß er entsprechend der Regierungsausschreibung ein Zertifikat für die entsprechende Software (zum Beispiel Cobol - nach verschiedenen Aussagen mit 92 bis 97 Prozent Anteil die bedeutendste Programmiersprache in den USA -, eventuell Fortran und in Zukunft vielleicht auch für Minimal Basic) vorlegen. Dieses Zertifikat erteilt das Federal Software Testing Center. Es gibt drei verschiedene Wege für die einer jeden Zertifizierung vorausgehende Validation des entsprechenden Kompilierers. Die am häufigsten begangene und beste Möglichkeit ist die der Validation beim Hersteller selbst.
Eine zweite Möglichkeit ist über RJE-Stationen gegeben. Die dritte Möglichkeit ist die der "Postvalidation": Bei Abwesenheit von Mitarbeitern des Federal Software Testing Center wird die Validation vom und beim Hersteller durchgeführt, und das Listing dem Federal Software Testing Center zur Verfügung gestellt. Die zweite und dritte Möglichkeit stellen nur Notlösungen dar, die unter anderem nur bei Folgevalidationen akzeptiert werden.
Die Prozedur für eine Validation sieht so aus:
a) Einer jeden Validation geht ein entsprechender Vertrag voraus. Außerdem werden die üblichen Vereinbarungen festgelegt wie zum Beispiel die Validationskosten, die Termine für die Zusendung der Validationsunterlagen, das Validationsdatum (falls schon möglich) sowie die Zeitpunkte zur Vorlage des Entwurfs- und des endgültigen Validationsberichtes. Zusätzlich wird eine Regelung für den Fall getroffen, daß die ursprünglich geschätzten Kosten überschritten werden.
b) Spätestens dreißig Tage vor dem festgelegten Validationstermin erhält der Hersteller die zugehörigen Unterlagen. Sie bestehen aus einem Magnetband und einem Handbuch. Auf dem Band befinden sich alle für die Validation notwendigen Testprogramme einschließlich des Modifikations- und Selektionsprogramms. Im Handbuch wird die Installation und die Handhabung des Validationssystems beschrieben. Der Hersteller ist somit in der Lage, eine Validation durchzuführen und eventuell noch kleinere Änderungen im Kompilierer vorzunehmen. Der Hauptgrund ist jedoch der, daß der Hersteller die Validation in Ruhe vorbereiten kann (entsprechende Prozeduren, Änderungen von Programmen etc.).
c) Das Team bringt zur eigentlichen Validation alle notwendigen Unterlagen erneut mit. Nur mit diesen neuen Unterlagen wird die Validation durchgeführt.
d) Alle Listen werden dem Validationsleiter zur Verfügung gestellt Diese Aufstellungen, insbesondere die Protokolle des Selektions- und Modifikationsprogramms und die Ergebnislisten der einzelnen Testprogramme sind zu kontrollieren. Alle Unterlagen werden nach Abschluß der Validation an das Federal Software Testing Center geschickt. Sie dienen dort als Grundlage für den Validationsbericht. Nach Abschluß der Validation werden die Fehlerlisten für das Folgejahr und die dann fällige Folgevalidation aufbewahrt.
e) Der Validationsbericht wird innerhalb von vier Wochen nach Zusendung der Listen als Entwurf dem Vertragspartner zur Korrektur vorgelegt. Innerhalb von zwei Wochen muß dieser berechtigte Änderungswünsche angemeldet haben. Danach wird der endgültige Bericht in dreißig Exemplaren erstellt. Fünf Exemplare erhält der Hersteller, fünfzehn der National Technical Information Services (NTIS), fünf bleiben beim Federal Software Testing Center und die restlichen werden direkt an verschiedene Adressaten wie etwa Mabel Vickers, National Bureau of Standards (NBS) und Codasyl verschickt.
Für 1982 wurden 52 Cobol-, 29 Fortran und 8 Basic-Kompilierer erstmalig validiert und zertifiziert. 14 weitere Kompilierer standen zur Folgevalidation an. Nur dreimal wurde eine "Postvalidation" durchgeführt.
Nach einer Erstvalidation wird in aller Regel ein Zertifikat erteilt- bei Folgevalidationen erst dann, wenn die Fehler aus dem Vorjahr beseitigt sind. Ein neues Zertifikat wird ohne neue Validation und ohne neue Kosten erteilt, wenn innerhalb der letzten zwölf Monate weder der Kompilierer, noch das Betriebssystem noch die Validationsroutinen geändert wurden und der betreffende Kompilierer im Vorjahr ohne Fehler validiert wurde! Dies war zum Beispiel in 1982 bei einem Kompilierer der Firma Honeywell der Fall. Formal wird die Zertifizierung in einem Brief dem Hersteller mitgeteilt. Gleichzeitig erhält das National Bureau of Standards (dort ist das Beschaffungsamt beheimatet) eine Kopie des Zertifizierungsschreibens.
Alle zertifizierten Kompilierer werden in einer "Certified Compiler List" erfaßt, gegliedert nach Sprache (Cobol, Fortran, Minimal Basic), ob "ohne Fehler" oder "mit Fehlern" und nach dem geweiligen Subset. Daneben werden alle Kompilierer aufgeführt, die - aus welchen Gründen auch immer - aus der "Certified Compiler List" gestrichen wurden. Die Aufstellung erscheint alle zwei Monate.
Benötigt ein Hersteller dringend ein Zertifikat für seine Bewerbung auf eine Regierungsausschreibung und kann die Validation nicht mehr innerhalb der Bewerbungsfrist durchgeführt werden, so genügt vorläufig die Vorlage einer Bestätigung des Federal Software Testing Center daß ein entsprechender Validationsvertrag zum nächstmöglichen Termin abgeschlossen ist.
"Technical Report" als Zusatzinformation
Grundsätzlich gilt - und so wird es auch im Federal Software Testing Center gehandhabt -, daß alles erlaubt ist, was eine Zertifizierung ermöglicht und damit auf längere Sicht einer Verbesserung der Kompilierer dient; einzige Ausnahme: Fehler!
Unter diesem Aspekt ist auch die Handhabung von "Technical Reports" zu sehen. Fast alle Kompilierer verfügen heute über den Modul "Index", wenigstens in der Level-1-Version. Die FIPS-Levels (Federal Information Processing Standard) sehen diesen Modul jedoch nur in der High-Level-Version vor. Dieser Level wird zur Zeit aber nur von sehr wenigen Kompilierern abgedeckt, so daß in den meisten Zertifikaten der Modul "Index" nicht eingeschlossen ist. In solchen Fällen kann die Validation für diesen Modul unter den üblichen Bedingungen erfolgen und die Ergebnisse werden als "Technical Report" zusätzlich zum Validationsbericht zusammengefaßt.
Die GMD hat, wie auch Institutionen in Großbritannien und Frankreich, die in USA gebräuchlichen Validationsroutinen und -unterlagen erworben. Sinn und Zweck dieses Unterfangens sind die gegenseitige Anerkennung der Zertifikate, was durch Anwendung nicht nur der gleichen Elle, sondern auch der gleichen Prüfmethode zu vergleichbaren Ergebnissen führt, ohne daß ein Hersteller (Implementierer) mehrfache Validationskosten aufbringen muß. Ein Validationsdienst in Europa wird damit auch die Zertifizierung von europäischen Kompilierern erleichtern, die auf dem amerikanischen Markt vertrieben werden sollen.