Kontrolliertes Englisch für Anforderungsspezifikationen

42 Kapitel 2
Anforderungen und SpeziÞkationen 41
dungsspezialisten entscheiden kšnnen, ob die intendierten Sachverhalte in der formalen
Sprache korrekt beschrieben sind. Das †berprŸfen der Korrekheit erfordert eine
gute Lesbarkeit und VerstŠndlichkeit der SAS fŸr alle Beteiligten. Um diesem Anspruch
gerecht zu werden, erzeugt der RA fŸr die Validierung der SAS eine Zusammenfassung
in voller natŸrlicher Sprache, so dass die Anwendungsspezialisten die
QualitŠt der SAS durch manuelle Techniken ŸberprŸfen kšnnen. Es gibt jedoch keine
Garantie dafŸr, dass die natŸrlich-sprachliche Zusammenfassung nicht wiederum
mehrdeutig ist und der Intention der Anwendungsspezialisten und Softwareent-
wickler entspricht.
[Lee & Sluizer 87] verfolgen in ihrer Arbeit einen sachverhaltsorientierten Modellierungsansatz,
in dem die Namen der einzelnen Objekte und Relationen fŸr die formale
Sprache direkt aus dem Anwendungsbereich Ÿbernommen werden. Die entstehende
SXL Spezifikation ist fŸr den Softwareentwickler gut lesbar und verstŠndlich.
Dagegen dŸrfte die formale Sprache fŸr die Anwendungsspezialisten zu anspruchsvoll
sein, wenn sie die SAS validieren mŸssen, da sich bestimmte Relationen auf
Operationen abstŸtzen, die Kenntnisse der zugrundeliegenden Maschinerie verlangen.
Die SXL Spezifikation ist ausfŸhrbar, so dass das Systemverhalten im Prinzip
durchgespielt werden kann. Der Nachteil bei der Sprache SXL ist, dass die Zwischenergebnisse
der symbolischen AusfŸhrung formal-sprachlich sind, was die †berprŸfbarkeit
der Korrektheit, VollstŠndigkeit und Konsistenz der SAS durch die Anwendungsspezialisten
erschwert.
[Lee & Sluizer 87] und [Wing 87] interpretieren den verbalen Ausdruck last checked out
aus der 5. Transaktion unterschiedlich. (Nebenbei: [Rich et al. 87] sprechen dieses Problem
nicht an). [Lee & Sluizer 87] unterscheiden bei ihrer Interpretation den Ausdruck
currently checked out aus der 4. Transaktion vom Ausdruck last checked out. Die 5.
Transaktion der SXL Spezifikation gibt entweder den gegenwŠrtigen Ausleiher zurŸck,
wenn eine Buchkopie ausgeliehen ist, oder den letzten Ausleiher, wenn die Buchkopie
nicht ausgeliehen ist. Bei dieser Interpretation ist die Menge der gegenwŠrtig
ausgeliehenen Buchkopien eine Teilmenge der zuletzt ausgeliehenen Buchkopien. Im
Gegensatz dazu ist fŸr [Wing 87] der Ausdruck currently checked out gleichbedeutend
mit dem Ausdruck last checked out, obwohl die beiden temporalen Adverbien currently
und last in der Problembeschreibung eine Ungleichheit anzuzeigen scheinen. Diese
zweite Interpretation hat zur Konsequenz, dass die 5. Transaktion in der Larch Spezifikation
den gegenwŠrtigen Ausleiher einer Buchkopie als Resultat zurŸckgibt. Ausser
diesen beiden Interpretationen ist noch eine dritte Interpretation denkbar. Dabei wird
davon ausgegangen, dass die beiden SŠtze Ÿber zwei disjunkte Mengen von Buchkopien
Aussagen machen. Bei dieser Interpretation gibt die 5. Transaktion den letzten
Ausleiher nur dann als Resultat zurŸck, wenn die Buchkopie (gegenwŠrtig) nicht
ausgeliehen ist [vgl. Rueher 87:131].
Wir ŸberprŸfen nun zum einen, wie solche unterschiedlichen Interpretationen fŸr den
Anwendungsspezialisten in den drei Beispielspezifikationen sichtbar werden, und
zum anderen, wie gut die Spezifikationen im allgemeinen den QualitŠtsattributen
(korrekt, eindeutig, vollstŠndig, verifizierbar, konsistent und verstŠndlich) genŸgen.
Leider erlauben es die veršffentlichten Darstellungen nicht, fŸr jedes einzelne qualitative
Attribut eine abschliessende Beurteilung zu machen.
[Wing 87] spezifiziert das Bibliotheksproblem mit einer formalen Spezifikationssprache,
die es erlaubt, modulare und wiederverwendbare SASen zu schreiben. Die
formale PrŠzision von Spezifikationssprachen wie Larch ermšglichen erst die
automatische KonsistenzprŸfung und die Programmverifikation durch BeweisfŸhrung.
[Wing 87] zeigt, dass die mathematische PrŠzision einer formalen Spezifikationssprache
dem Softwareentwickler hilft, Fehler, Mehrdeutigkeiten und FŠlle von †berspezifikation
in der Problembeschreibung zu entdecken. Das Entdecken von MŠngeln
und die korrekte Behebung dieser MŠngel sind jedoch zwei unterschiedliche Dinge.
Die Behebung der MŠngel verlangt Feedback von den Anwendungsspezialisten. Larch
Spezifikationen sind komplexe mathematische Objekte, die nur von Softwareentwicklern
mit entsprechender Ausbildung geschrieben und verstanden werden kšnnen.
[Wing 87] verwendet zwar fŸr die Visualisierung des Bibliotheksmodells eine Statechart,
die sie - nebenbei bemerkt - wiederum in natŸrlicher Sprache erklŠrt. Leider ist
die Beziehung zwischen der Statechart und der Larch Spezifikation nur informell, so
[Rich et al. 87] betonen in ihrer Arbeit, dass sie mit dem Requirements Apprentice (RA)
ein Werkzeug anbieten, das die konzeptionelle LŸcke zwischen einer informellen Problembeschreibung
und einer formalen SAS schliessen soll. Dieser Anspruch wird aber
nur zum Teil erfŸllt, da die Anwendungsspezialisten vom eigentlichen Spezifikationsprozess
weitgehend ausgeschlossen sind. WŠhrend des Spezifikationsprozesses greift
der RA auf grosse Mengen von Weltwissen zurŸck, das in einer ClichŽ-Bibliothek
verfŸgbar ist. Unklar ist, von wem dieses formalisierte Wissen stammt und inwieweit
dieses Wissen den Anwendungsbereich Ÿberhaupt adŠquat widerspiegelt. Der RA
ŸberprŸft die Konsistenz und die VollstŠndigkeit der entstehenden SAS aufgrund
seines Hintergrundwissens und verlangt bei Bedarf Entscheidungshilfen vom Analytiker.
Es ist schwierig, die Korrektheit der SAS zu ŸberprŸfen, da allein die Anwen-