Kontrolliertes Englisch für Anforderungsspezifikationen

46 Kapitel 3
InformalitŠt und FormalitŠt im Einklang 45
3.1 Textuelle Sichten auf formale Spezifikationen
Um die informellen und die formalen Aspekte beim Schreiben einer SAS in deklarativen
Einklang zu bringen, fŸhren wir textuelle Sichten (Views) auf formale Spezifikationen
in Logik ein. Textuelle Sichten erscheinen informell und werden direkt auf
dem Computer in einer anwendungsspezifischen Benutzersprache B erstellt. Zwischen
einer textuellen Sicht V und der entsprechenden formalen Spezifikation Spez
besteht eine Korrespondenz. Die Korrespondenz kommt durch eine Abbildung der
textuellen Sicht V auf die formale Spezifikation Spez mit Hilfe einer eindeutigen
†bersetzungsfunktion f: V -> Spez zustande. Diese †bersetzungsfunktion weist der
Sicht V die formale Semantik [[a]] M der aus der logischen Sprache L konstruierten
Spezifikation Spez zu, und zwar relativ zu einem vorgegebenen Modell M. Die inverse
Abbildung der formalen Spezifikation Spez auf die textuelle Sicht V entsteht durch die
Umkehrfunktion f-1 , die die formale Spezifikation Spez in der anwendungsspezifischen
Benutzersprache B paraphrasiert.
3. InformalitŠt und FormalitŠt im Einklang
Die Praxis zeigt, dass die Benutzer und Anwendungsspezialisten die faktischen Anforderungen
an ein zu entwickelndes Softwareprodukt vorzugsweise informell beschreiben.
Sie verwenden dazu die natŸrliche Sprache als Spezifikationssprache mit der aus
dem Anwendungsbereich vertrauten fachsprachlichen Terminologie. Das fŸhrt zu
zwei Nachteilen: Erstens ist die natŸrliche Sprache mehrdeutig und vage und zweitens
ist die Fachterminologie fŸr die Softwareentwickler oft nur schwer zugŠnglich. Das hat
zur Konsequenz, dass die Konzepte und die akzeptierten Verfahrensweisen aus dem
Anwendungsbereich fŸr die Softwareentwickler nicht immer klar erkennbar sind.
Die Softwareentwickler haben die schwierige Aufgabe die informelle Problembeschreibung
in eine formale SAS zu ŸberfŸhren. Bei diesem †bergang werden die AusdrŸcke
der natŸrlichen Sprache in eine formale (logikbasierte) Sprache Ÿbersetzt und
modelltheoretisch interpretiert oder allenfalls beweistheoretisch hergeleitet [vgl. Kowalski
94]. Das Resultat ist eine eindeutige formale SAS, die die SystemfunktionalitŠt
in erster Linie aufgrund der intendierten Interpretation der Softwareentwickler festlegt
und nicht aufgrund der Vorstellungen der Anwendungsspezialisten.
Die Autoren der SAS schreiben ihre faktischen Anforderungen direkt auf der Sichtebene
mit Hilfe eines Editors, der den Schreibprozess unterstŸtzt. Sie verwenden dazu
eine wohldefinierte Teilmenge der natŸrlichen Sprache als Benutzersprache, die aus
einem anwendungsspezifischen Vokabular, einer eingeschrŠnkten Grammatik und
einer Menge von Schreibprinzipien besteht. Die Autoren entscheiden, welche AusdrŸcke
der eingeschrŠnkten Sprache die Sachverhalte hinreichend exakt beschreiben
und bauen das inhaltsbezogene Vokabular fŸr die SAS selber auf. Durch diese Vorgehensweise
kann die Vagheit von AusdrŸcken mit Bezug auf die Situation und den
Kontext abgefedert werden. Die Schreibprinzipien haben die Funktion von Kontrollstrukturen,
denn sie reduzieren die Menge der lexikalischen, syntaktischen, semantischen
und pragmatischen AmbiguitŠten der vollen natŸrlichen Sprache bereits vor
der maschinellen Analyse, so dass die auf der Sichtebene erstellte SAS eindeutig in
eine (ausfŸhrbare) logische Spezifikation Ÿbersetzt werden kann. Die Autoren brauchen
die zugrundeliegende formale Sprache nicht zu kennen, sondern sie mŸssen
bloss mit den Schreibprinzipien vertraut sein. Die automatische †bersetzung macht
die scheinbar informelle textuelle Sicht formal, ohne dass die interne formale ReprŠsentation
fŸr die Autoren sichtbar wird. Die Interpretation der textuellen Sicht wird
durch eine Paraphrase auf der textuellen Ebene verdeutlicht. Zwei textuelle Sichten
sind Paraphrasen voneinander, wenn sie in den verwendeten AusdrŸcken oder den
syntaktischen Strukturen voneinander abweichen, aber dieselbe modelltheoretische
Interpretationen haben. Paraphrasierung wird hier als ein syntaktisches Verfahren
verstanden, bei dem das Ergebnis durch kontrollierte Ersetzung und Einsetzung von
SASen sind Schnittstellen zwischen den faktischen Anforderungen aus dem Anwendungsbereich
und dem prozeduralen Verhalten eines Computers. Wenn an dieser
Schnittstelle bei der Formalisierung Fehler passieren oder bereits vorschnell Entwurfsentscheidungen
getroffen werden und die Anwendungsspezialisten keine Mšglichkeit
haben, das Dokument zu ŸberprŸfen und die Sachverhalte richtig zu stellen, weil
sie mit der formalen Spezifikationsmethode nicht vertraut sind, dann wird der Computer
die geforderte FunktionalitŠt im Anwendungsbereich nicht erbringen kšnnen.
Unter welchen Rahmenbedingungen kann man eine formale Spezifikationssprache
den Anwendungsspezialisten zugŠnglich machen? Auf der einen Seite mšchte man
von den Eigenschaften einer formalen Spezifikationssprache profitieren, um die Validierung
und die Verifikation maschinell unterstŸtzen zu kšnnen. Auf der anderen
Seite muss man aber feststellen, dass formale Spezifikationssprachen fŸr Leute aus
dem Anwendungsgebiet, die nicht Ÿber die nštigen mathematische Grundlagen verfŸgen,
kaum zugŠnglich sind. Wir schlagen deshalb vor, dass man eine anwendungsspezifische
Spezifikationssprache einfŸhrt, mit der die faktischen Anforderungen auf
eine natŸrliche Weise eindeutig dargestellt werden kšnnen. Die Sprache soll informell
erscheinen, aber die gleichen formalen und operationalen Eigenschaften wie eine
logikbasierte Spezifikationssprache haben [vgl. Fuchs & Robertson 96].