Sind die in Abschnitt 4.2 von den Werkzeugen gefundenen Fehler behoben, wird es möglich, eine SDL-Spezifikation an das generierte SDL-Werkzeug zu übergeben und von diesem ein AsmL-Programm generieren zu lassen. Auch hierbei können wiederum verschiedene Probleme aufgedeckt werden.
4.3.1 Fehler in der Definition der abstrakten Syntax 0
Zur Formalisierung der statischen Semantik ist es erforderlich, dass die abstrakte Syntax 0 alle Aspekte der ursprünglichen SDL-Spezifikation erfasst. Falls das nicht der Fall ist, muss die ab-strakte Syntax geändert werden.
Beispiel 9. In der konkreten textuellen Syntax treten Schlüsselworte oft paarig auf. Beispiels-weise wird eine Prozedurdefinition von procedure eingeleitet und von endprocedure be-endet. Hinter procedure muss der Prozedurname angegeben werden; hinter endprocedure kann er angegeben werden. Sind beide Namen angegeben, so müssen sie übereinstimmen.
Leider erfasst die abstrakte Syntax 0 nicht den hinter endprocedure angegebenen Namen, da er eigentlich redundant ist. Damit kann der Test, ob die Namen gleich sind, nicht imple-mentiert werden. Dieses Problem ist bislang ungelöst; zur Lösung könnte etwa in jeden be-troffenen Knoten der abstrakten Syntax 0 ein weiterer Kindknoten eingefügt werden. Diese Lösung hätte allerdings zur Folge, dass jedes Vorkommen der geänderten Knoten angepasst werden müsste.
4.3.2 Überprüfung statischer Bedingungen für die Abstrakte Syntax
Ein Kern der statischen Semantikanalyse ist die Überprüfung von semantischen Regeln (well-formedness conditions). Falls diese nicht erfüllt sind, gilt die Eingabespezifikation als falsch. In diesem Fall ist die weitere Verarbeitung der SDL-Spezifikation sinnlos.
Falls angenommen werden kann, etwa durch Inspektion der Spezifikation, dass die Spezifi-kation allen Regeln entspricht, ist die Überprüfung der Regeln für die Funktion der Werkzeug-kette nicht zwingend erforderlich. Nach Analyse der statischen Bedingungen in der formalen Semantikdefinition zeigte sich, dass diese Formeln eine große Zahl der in Abschnitt 4.2 erläu-terten Probleme aufweisen, dass also diese Formeln nicht ohne massive Änderungen durch SDLC verarbeitet werden können. Da die Funktion der Werkzeugkette nicht essentiell von die-sen Bedingungen abhängt, wurde auf ihre Integration in das Referenzwerkzeug verzichtet.
Die folgende Liste möglicher Probleme ist also spekulativ. Sie ergeben sich lediglich durch Inspektion der Regeln, nicht jedoch durch Überprüfung mit Werkzeugen. Trotzdem erscheint es dem Autor wahrscheinlich, dass bei Integration dieser Bedingungen einige dieser Probleme tat-sächlich auftreten würden.
Die potentiellen Fehler in den statischen Bedingungen unterteilen sich in drei Kategorien:
1. Die Regel lehnt richtige Spezifikationen fälschlich ab.
2. Die Regel akzeptiert fälschlich richtige Spezifikationen.
3. Die Regel terminiert für eine gegebene Spezifikation nicht.
Beobachtet man nun, dass eine Spezifiikation abgelehnt wird, so kann das folgende Ursachen haben:
• Fehler in der Spezifikation
Im Idealfall zeigt das Scheitern eines Prädikats einen tatsächlichen Fehler in der Spezifika-tion an. Die statische Semantikanalyse leistet dann das Verlangte: Sie zeigt Fehler in der sta-tischen Semantik auf.
• Fehler der Formalisierung
Ein Prädikat kann auch scheitern, weil die in der informalen Semantik angegebene Regel nicht richtig formalisiert wurde. In diesem Fall muss die Formel korrigiert werden. Eventu-ell wurde die informale Regel fehlinterpretiert. Dann muss auch die englische Formulierung überarbeitet werden.
• Fehler der informalen Semantik
Weiterhin kann ein Prädikat scheitern, weil die informale Regel falsch oder zu streng ist. In diesem Fall müssen die Autoren des Sprachstandards entscheiden, ob die formulierte Regel tatsächlich so gemeint war, und ob in Konsequenz also die Eingabespezifikation tatsächlich als falsch gelten soll. Ist das nicht der Fall, muss die Sprachdefinition revidiert werden, sowohl in ihrem informalen als auch in ihrem formalen Teil.
• Fehler im Abarbeitungsmodell
Schließlich ist es denkbar, dass ein Prädikat nur zu gewissen Zeitpunkten in der Verarbei-tungskette erfüllt ist. So sind beispielsweise zahlreiche Prädikate für die abstrakte Syntax 0 formuliert. Die in dieser Syntax vorliegende Eingabe wird jedoch auf verschiedene Weise transformiert, so dass ursprünglich geltende Eigenschaften ungültig werden oder geforderte Eigenschaften erst nach einigen Transformationsschritten gültig werden. Es ist nicht bekannt, ob dieser Fall tatsächlich auftreten kann, oder wie in diesem Fall zu verfahren wäre. Eine mögliche Strategie wäre, für jede dieser Bedingungen anzugeben, nach welchem Transformationsschritt sie zu überprüfen ist. Eine andere Strategie wäre dagegen, zu versu-chen, die Bedingungen so umzuformulieren, dass sie, für eine bestimmte Spezifikation, ent-weder stets oder nie gelten (der genaue Zeitpunkt der Überprüfung also irrelevant ist).
Sollte letztere Strategie verfolgt werden, so ist es eine Beweisverpflichtung, nachzuweisen, dass die Bedingungen ihren Wert während der Verarbeitung tatsächlich nicht ändern.
Neben diesen Ursachen für ein Scheitern der Überprüfung von Bedingungen ist es weiterhin möglich, dass Fehler in den Werkzeugen zu einer Fehlevaluierung von Bedingungen führen.
Wie in Abschnitt 2.5 erläutert, werden solche Fehler systematischer Art sein und sich beispiels-weise auf bestimmte Konstrukte beziehen. Da die in den Bedingungen verwendeten Konstrukte im Wesentlichen die gleichen sind, die auch in den anderen Teilen der formalen Semantikdefi-nition verwendet werden und da diese schon intensiv getestet wurden, kann man davon ausge-hen, nur noch wenige derartiger Probleme zu finden.
Nun kann nicht nur das Scheitern einer Bedingung ein Fehler sein. Die Berechnung der Be-dingung könnte auch fälschlich den Wert „wahr“ liefern, oder sie könnte nicht terminieren. Der erste Fall einer fälschlich erfüllten Bedingung lässt sich nur schwer entdecken. Gibt man eine Spezifikation ein, von der nicht bekannt ist, ob sie richtig oder falsch ist, kann man nur erhoffen, dass eine falsche Spezifikation im Laufe des Verarbeitungsprozesses noch weitere Fehler (so-genannte Folgefehler) provoziert. Die Analyse der Folgefehler kann dann zu der Einsicht füh-ren, dass diese Spezifikation gar nicht hätte verarbeitet werden dürfen. In manchen Fällen wird diese Information vorab bekannt sein, beispielsweise wenn ein anderes Werkzeug die Spezifi-kation bereits abgelehnt hat. Dann ist zu untersuchen, ob das Problem in der Formalisierung der Bedingung, in der Bedingung selbst oder aber in dem anderen Werkzeug liegt.
Falls die Berechnung einer Bedingung nicht terminiert, so wird das hingegen relativ schnell offensichtlich: die Verarbeitung der Spezifikation dauert bedeutend länger als die Verarbeitung
„vergleichbarer“ Spezifikationen. In diesem Fall ist zunächst zu untersuchen, ob nicht vielleicht doch noch mit einer Terminierung der Berechnung zu rechnen wäre und lediglich ein Algorith-mus zum Einsatz kommt, der eine große Komplexität besitzt. Auch wenn dieses Problem als das Halteproblem bekannt ist [Tur36], und damit im Allgemeinen unlösbar ist, hat der Autor doch die Erfahrung gemacht, dass sich in der Praxis diese Frage immer leicht beantworten lässt. Ur-sache hierfür ist die kompositionale Struktur der Übersetzung der Formeln: Jede Formel besteht aus Ausdrücken, für die oft klar ist, ob sie stets terminieren oder nicht. Die Berechnung der Ge-samtformel terminiert bestimmt dann, wenn alle Teilausdrücke terminieren und der Kompositi-onsoperator auch stets terminiert. Eine Ausnahme sind natürlich rekursiv definierte Funktionen, für die oft nicht so einfach zu beantworten ist, ob sie terminieren – diese sind aber relativ selten, und oft auch in ihrer Rekursion überschaubar.
Unter den in der formalen Semantik verwendeten Konstrukten gibt es einige, die potentiell nicht terminieren. Insbesondere terminiert die Berechnung von Quantoren unter Umständen nicht, wenn die Basismenge unendlich ist. Gerade in den Bedingungen wird stark Gebrauch von Quantoren gemacht. Beispielsweise wird die Forderung
Exactly one of the <start>s shall be unlabelled.
durch die Formel
∀ csg ∈ <composite state body>:
∃!s ∈ <start>: (s.parentAS0 = csg) ∧ (s.s-<name> = undefined)
formalisiert: Für alle Knoten csg des Typs <composite state body> (auf die sich Forderung be-zog) gibt es je genau einen Knoten <start>, dessen Elternknoten csg ist und dessen <name>-Kind undefiniert ist. Zur Überprüfung dieser Regel müssen alle Knoten des Typs <start> inspi-ziert werden. Es reicht nicht, abzubrechen, wenn ein derartiger Knoten gefunden wurde. Diese Berechnung terminiert, weil die Menge aller <start>-Knoten in einer Spezifikation endlich ist.
Es gab in der Semantikdefinition allerdings auch Fälle, in denen eine Quantifizierung unend-licher Mengen vorgenommen wird, beispielsweise Forderungen der Art „Es gibt eine Zahl, so dass ...“ Wenn diese Forderungen durch Quantifizierung über die Menge der natürlichen Zahlen formalisiert wurden, würde die Berechnung nicht terminieren. Der Generator SDLC erkennt eine Reihe solcher Fälle und zeigt sie als Fehler an.
4.3.3 Die Abarbeitung von Transformationsregeln
Die Transformationsregeln, die einen Baum der abstrakten Syntax in einen anderen umformen, können keine Fehler im eigentlichen Sinn produzieren. Trotzdem wurden beim Test der Werk-zeuge folgende Fehlerfälle erkannt:
• Endlosschleifen
Eine Transformation wird immer wieder ausgeführt, weil der Baum, der am Ende der Trans-formation entsteht, wieder die Vorbedingung der Anwendung der TransTrans-formationsregel erfüllt. Dabei ist sowohl der Fall beobachtet worden, dass der Baum im Rahmen der Trans-formation nicht verändert wurde, als auch, dass er vergrößert wurde. Im ersten Fall liegt der Fehler klar in der Formalisierung der Transformationsregel, da die formalisierte Version offenbar überhaupt keinen Effekt hat. Im zweiten Fall muss vielleicht auch die englische Formulierung überarbeitet werden, falls sie für den Fall des rekursiven Anwendens der Regel keine klaren Regelungen trifft.
• Auslassen von Transformationen
Eine Transformation, die ausgeführt werden müsste, wird nicht ausgeführt. Dies fällt in der
Regel erst in späteren Verarbeitungsschritten auf, wenn etwa die Abbildung auf die Abs-trakte Syntax 1 Knoten in der Baumstruktur vorfindet, für die keine Abbildung vorgesehen ist, weil sie eigentlich durch eine Transformation hätten ersetzt werden müssen. Die Ursa-chen für dieses Problem können vielfältig sein, so kann es beispielsweise erforderlich sein, die Reihenfolge der Tranformationen zu ändern oder die Vorbedingungen für die Regel zu korrigieren.
4.3.4 Die Generierung und Verarbeitung von AsmL
Nach Abarbeitung der Transformationen und Konstruktion der abstrakten Syntax 1 wird durch die Kompilationsfunktion AsmL-Quelltext erzeugt. Dieser Quelltext wird dann vom AsmL-Compiler weiterverarbeitet und schließlich durch das Microsoft .NET-Laufzeitsystem ausgeführt.
Bei der Übersetzung des AsmL-Quelltextes waren die Probleme vorwiegend folgender Na-tur:
• Von AsmL nicht unterstützte Konstrukte
Die erste Version des AsmL-Compilers hat eine Reihe von Konstrukten nicht unterstützt, die in der SDL-Semantikdefinition an zahlreichen Stellen verwendet wurden (beispiels-weise Vereinigungsdomänen). Daraufhin wurde von der Verwendung von AsmL 1.5 Abstand genommen und statt dessen mit einer Beta-Version von AsmL 2 gearbeitet, die im Wesentlichen alle benötigten Konstrukte bereitstellt. Manche Aspekte der SDL-Semantik werden von AsmL gar nicht unterstützt, etwa die Verteilung des Systems auf mehrere Agen-ten oder der Begriff der Systemzeit. Um diese Aspekte auf AsmL abzubilden, wurde eine zentrale Ablaufsteuerung geschaffen, die Zeit- und Agentensemantik nachbildet.
• Typfehler im AsmL-Code
Der AsmL-Compiler hat Typfehler gemeldet. Hauptursache des Problems ist, dass AsmL getypte Variablen verwendet, während die SDL-Semantikdefinition ungetypte Variablen und Funktionen verwendet (alle Funktionen sind partiell auf einer Grundmenge X definiert und liefern den Wert undefined für Argumente außerhalb ihres eigentlichen Definitionsbe-reichs). Glücklicherweise wurde von diesem Verzicht auf Typisierung nur an wenigen Stel-len Gebrauch gemacht, so dass durch Einführung von Typdeklarationen an wenigen StelStel-len das Typsystem von AsmL zufrieden gestellt werden konnte.
• Fehler im AsmL-Compiler
Der AsmL-Compiler hat Fehler gezeigt (beispielsweise Abstürze). Diese Probleme mussten zusammen mit den Autoren des Compilers behoben oder umgangen werden.