Trotz der Normung von Programmiersprachen und der damit festgelegten Sprachsyntax reicht dies für eine Portable Implementierung auf mehreren Rechenanlagen in der Regel nicht. Daraus resultieren Compiler mit unterschiedlicher Semantik, die zu nicht direkt erkennbaren Fehlern führen. Durch eine Normkonformitätsprüfung soll die Portabilität eines Programmes sicherer gemacht werden.

Die Normen für Programmiersprachen wie Cobol (DIN 66 028) und FORTRAN (DIN 66 027) legen die Syntax der Sprache fest. Für die Implementation jedoch ist dies nicht immer hinreichend. Denn manchmal ist sogar absichtlich noch eine Lücke in der Sprache gelassen worden; eventuell ist die Norm auch nicht eindeutig oder sie wird nicht richtig verstanden. In all diesen Fällen muß der Implementiere sich jedoch für eine einzige Lösung entscheiden. In der Praxis führt dies zu Compilern, die unterschiedliche Ergebnisse liefern, das heißt, zu Compilern mit unterschiedlicher Semantik. Diese "Fehler" sind deshalb besonders heimtückisch, weil sie nicht schon -frühzeitige durch einen Syntaxprüfer erkannt werden können, sondern oft erst zufällig entdeckt werden. Portable Quellprogramme 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 einer Rechenanlage auf eine Anlage eines anderen Herstellers zu gewährleisten.

Güteprüfung basiert auf "Falsifikation"

Hier setzt die Validation und Zertifikation von Compilern an. Unter Validation versteht man in diesem Zusammenhang die Überprüfung eines Compilers 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 Compiler in Testprogrammen keine "Fehler" liefert. Wenn keine Fehler mehr festgestellt werden, heißt dies natürlich noch nicht, daß dieser Kompilierer "fehlerfrei" ist.

Es stellt sich die Frage, wie ein so komplexes Programm validiert werden kann. 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!

Die Prüfstelle in den USA, das Federal Software Testing Center (FSTC) prüft seit 1972/73 Cobol-Kompilierer auf Einhaltung und Erfüllung der Norm. Diese Stelle ist eine zentrale Bundesstelle für Datenverarbeitung innerhalb des Software Development Office in den Vereinigten Staaten von Amerika, welches der General Services Administration (GSA) untersteht. Das Federal Software Testing 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 und Durchsetzung von Beschaffungsrichtlinien hinsichtlich des Erwerbs 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-Compiler ein Validationsbericht (VSR: Validation Summary Report) oder ein Zertifikat vorliegen.

Dieser individuelle Validationsbericht unterscheidet sich allerdings ganz erheblich von dem, was uns als vergleichender Testbericht geläufig ist. In einem solchen Validationsbericht wird aufgezeigt, was getestet wurde und was warum nicht getestet wurde. Ein Beispiel: die COMPUTE-Anweisung in Cobol wird nicht getestet. Grund: Die Norm überläßt es dem Hersteller, mit welcher internen Genauigkeit Zwischenergebnisse ermittelt werden.

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 Compiler 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. In jüngster Zeit konnte ein Cobol-Compiler in Europa nicht validiert und damit auch nicht zertifiziert werden, weil noch nicht einmal das Validationssystem selbst installiert werden konnte!

Ein solches Zertifikat ist auf die Dauer von zwölf Monaten begrenzt. Danach erlischt es, falls es nicht rechtzeitig aufgrund einer erneuten Validation erneuert wird. Erst wenn bei einer solchen Folgevalidation noch Fehler aus einer 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 berücksichtigt außerdem die Tatsache, daß etwa 80 Prozent der Fehler in einem Kompilierer durch Verbesserung anderer Fehler verursacht werden.

Durch diese Maßnahme erreicht man, daß Validation und Zertifizierung überhaupt erst in vernünftiger Weise zu handhaben sind. Außer den obengenannten Schwierigkeiten gibt es nämlich noch zwei weitere Eigenschaften, die ohne diese Vorgehensweise einen Test abwerten könnten: der Übersetzer wird geändert oder die Testroutinen werden erweitert und prozessiert. Beide Tatsachen wirken sich aber erst bei einer Folgevalidation aus!

Insgesamt 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 werden 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 eingesetzt werden. Je nach Betriebssystem handelt es sich dabei um 5000 bis 20 000 Steuerkarten! Durch Angabe von Parametern können einige Sprachelemente aus dem Test herausgenommen werden (in Cobol zum Beispiel VALUE OF . . . im FD Eintrag).

Manuelle Eingriffe widersprechen der Seriosität

Ergibt schon die Kompilierung Fehler, so sind diese genau zu analysieren und unter Umständen so zu korrigieren, daß das Testergebnis nicht verfälscht wird. All dies wird über die obengenannte Datei gesteuert, so daß über alle Änderungen ein genaues Protokoll durch das Selektion- und Aufbereitungsprogramm erstellt werden kann. Ein individueller, manueller Eingriff direkt am Quelltext entspräche nicht den strengen Maßstäben, die an eine seriöse Validation angelegt werden müssen.

Ist eine Kompilierung erfolgreich abgeschlossen, kann es an die Ausführung gehen. Alle Testprogramme sind so aufgebaut, daß sie selbst einen Soll/Ist-Vergleich durchführen, sofern dies möglich ist, und ein entsprechendes Prüfungsprotokoll ausdrucken. Hierin sind zum Beispiel festgehalten: Name des Programms, Hinweis auf jeden durchgeführten Test mit "pass" oder "fail" und die Angabe der Stelle, wo im Quellprogramm der Test codiert ist, bei Abweichen die Angaben "correct" und "computed", bei Übergehen von Tests ein entsprechender Hinweis ("deleted") und am Schluß je eine Summe für Gesamtzahl Tests im Programm, Anzahl der übergangenen Tests, Anzahl der fehlerhaften und der fehlerfreien Tests. Nur dort, wo es unumgänglich ist, muß der Prüfer manuell kontrollieren. 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 im 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.

Zertifikat ist Grundlage für US-Behördenauftrag

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 - Cobol ist nach verschiedenen Aussagen mit 92 Prozent bis 97 Prozent Anteil die bedeutendste Programmiersprache in den USA -, Fortran oder Minimal Basic und im militärischen Bereich auch Ada) 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 "Briefvalidation", das heißt, die Validation wird ohne Anwesenheit von Mitarbeitern der Prüfstelle vom und beim Hersteller durchgeführt und die Listen werden dem Federal Software Testing Center zugesandt. Die letzten beiden Möglichkeiten werden nur bei Folgevalidationen akzeptiert.

Die Prozedur für eine Validation sieht so aus:

Jeder solchen Güteprüfung geht ein entsprechender Vertrag voraus in dem die üblichen Vereinbarungen und Termine festgelegt werden.

Spätestens dreißig Tage vor dem festgelegten Validationstermin erhält der Hersteller die Validationsunterlagen. Sie bestehen aus einem Magnetband und einem Handbuch. Auf dem Band befinden sich alle für die Güteprüfung 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 Güteprüfung in Ruhe vorbereiten kann (entsprechende Prozeduren, Änderungen von Programmen etc.).

Das Validationsteam bringt zur eigentlichen Güteprüfung alle notwendigen Unterlagen erneut mit. Nur mit diesen neuen Unterlagen wird die Validation durchgeführt.

Der Validationsleiter kontrolliert alle Listen. Insbesondere sind die Protokolle des Selektions- und Modifikationsprogramms und die Ergebnislisten der einzelnen Testprogramme zu kontrollieren. Alle diese Listen gehen nach Abschluß der Güteprüfung als Grundlage für den Bericht an die Prüfstelle.

Der Validationsbericht wird innerhalb von vier Wochen nach Zusendung der Listen als Entwurf dem Vertragspartner zur Korrektur vorgelegt. Nur innerhalb von zwei Wochen kann dieser berechtigte Änderungswünsche anmelden. Danach wird der endgültige Bericht in dreißig Exemplaren erstellt.

Im Jahre 1984 wurden insgesamt 72 Cobol-, 48 Fortran-, 25 Basic-, sechs Ada- und in Großbritannien vier Pascal-Kompilierer geprüft und zertifiziert. Falls möglich, werden während einer Reise mehrere Kompilierer geprüft. Unter den vorstehend genannten Normkonformitätsprüfungen befinden sich nur drei "Briefvalidationen".

Nach einer Erstvalidation für Cobol oder Fortran wird in aller Regel ein Zertifikat erteilt. Bei Folgevalidationen wird das Zertifikat nur dann erstellt, wenn alle Fehler aus früheren Validationen beseitigt sind. Ein neues Zertifikat wird dann ohne neue Güteprüfung 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. Im Jahre 1984 Wurden zum Beispiel 107 Kompilierer "ohne Fehler" befunden.

"The good, the bad and the ugly" stehen in der CCL

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 Compiler werden in einer "Certified Compiler List" erfaßt. Diese Liste erscheint alle zwei Monate. Es werden alle Kompilierer ausgewiesen, gegliedert nach Sprache (Cobol, Fortran, Minimal Basic, Ada), ab "ohne Fehler" oder "mit Fehlern" und nach dem jeweiligen Subset (bei Cobol: Low, Low-lntermediate, High-Intermediate oder High). Daneben werden alle Übersetzer aufgeführt, die - aus welchen Gründen auch immer -aus der "Certified Compiler List" gestrichen wurden.

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 Compiler dient, einzige Ausnahme: Fehler für mehr als zwölf Monate und Fehler bei Ada!

Vergleichbare Prüfergebnisse werden angestrebt

Unter diesem Aspekt ist auch die Handhabung von "Technical Reports" (TR) zu sehen. In solchen TRs werden die Ergebnisse der Prüfungen für jene Modulen festgehalten, die über dem geprüften Subset liegen und für die der Hersteller die Normkonformitätsprüfung wünscht. Beispiel: Fast alle Compiler für Cobol verfügen heute über den Modul INDEX, wenigstens in der Level-1Version. Die FIPS-Levels (Federal Information Processing Standard) sehen diesen Modul jedoch nur im Subset HIGH vor. Dieser Subset wird zur Zeit aber nur von sehr wenigen Kompilierern abgedeckt, so daß in den meisten Zertifikaten das Modul INDEX nicht eingeschlossen ist. In solchen Fällen kann die Validation für dieses Modul unter den üblichen Bedingungen erfolgen, und die Ergebnisse werden als "Technical Report" zusätzlich zum Validationsbericht zusammengefaßt.

Die Gesellschaft für Mathematik und Datenverarbeitung mbH (GMD) hat wie auch Institutionen in Großbritannien und Frankreich nicht nur die in USA gebräuchlichen Validationsroutinen und -unterlagen erworben, sondern auch einen Mitarbeiter dort schulen lassen. Sinn und Zweck dieses Unterfangens sind die gegenseitige Anerkennung der Zertifikate, was durch Anwendung der gleichen Prüfmethode zu vergleichbaren Ergebnissen führt, ohne daß ein Hersteller (Implementiere) mehrmals die Validationskosten aufbringen muß. In den USA zum Beispiel ist dieses Zertifikat unabdingbare Voraussetzung, um als Anbieter von Soft- und Hardware von den dortigen Bundesbehörden anerkannt und berücksichtigt zu werden.

*Siegfried Mahkorn ist wissenschaftlicher Angestellter der GMD Gesellschaft für Mathematik und Datenverarbeitung mbH, Bonn..