Opel-Tobias by fanzhongqing

VIEWS: 0 PAGES: 22

									           Seminararbeit



                  Thema:

Model Checking Beispiele aus der Praxis




                    von

    Tobias Opel Matr.-Nr. 6154379

                2. Mai 2004


                 Seminar:
Qualität von Software und Software-Modellen


      G. Engels, W. Schäfer, J. Küster
                               Inhaltsverzeichnis



1 Einleitung................................................................................. 3
2 Was ist Model Checking? .......................................................... 6
    2. 1 Symbolisches Model Checking............................................ 7
    2. 2 Binary Decision Diagramms ............................................... 7
3 Praxisbeispiele ......................................................................... 9
     3. 1 TCAS II .......................................................................... 9
     3. 2 Vorgehensweise beim Model Checking von TCAS II ............. 10
     3. 3 Hindernisse beim Model Checking von TCAS II ................... 11
     3. 4 Ergebnisse .................................................................... 12
     3. 5 Schlussfolgerungen ........................................................ 14
     3. 6 A-7E Aircraft ................................................................. 16
4 Bedeutung von Model Checking für die Softwarequalität ........ 17
5 Fazit....................................................................................... 20
Abbildungsverzeichnis .............................................................. 21
Literatutverzeichnis .................................................................. 22




Model Checking Beispiele aus der Praxis                                                             2
1 Einleitung

Nach Ghezzi et al. [4] versteht man unter Softwarequalität, dass ein
System bzw. Programm folgende als intern und extern gegliederte
Merkmale besitzen sollte.
Externe Qualitätsmerkmale von Software, d.h. sichtbar für den Benutzer,
sind:
   •    Korrektheit
   •    Zuverlässigkeit
   •    Robustheit
   •    Effizienz
   •    Benutzerfreundlichkeit


Interne Qualitätsmerkmale von Software, d.h. sichtbar für den Entwickler,
sind:
   •    Wartbarkeit
   •    Wiederverwendbarkeit
   •    Portierbarkeit
   •    Verständlichkeit
   •    Interoperabilität


Um diese Merkmale zu sichern bzw. zu messen bedarf es diverser
Vorbereitungen und Methoden, die sowohl beim Entwurf, der Entwicklung
als auch bei der nachträglichen Betrachtung von Softwaresystemen
angewandt werden.


Einige ausgewählte Methoden, die zur Wahrung und Verifizierung von
Softwarequalitätsmerkmalen dienen sind:
   •    Modellierung
   •    Testen
   •    Simulation
   •    Dokumentation
   •    Model Checking



Model Checking Beispiele aus der Praxis                                 3
Mittels    Modellierung     (bspw.        UML-Diagramme        bei   objektorientierten
Problemstellungen) können in der Phase des Entwurfs unter anderem die
Merkmale Robustheit und Erweiterbarkeit schon im Ansatz betrachtet
werden. So können im Vorfeld unter dem Gesichtspunkt der Robustheit,
unvorhersehbare        Umstände,     die     beim   fertigen      Programm   auftreten
können, bereits zu diesem frühen Zeitpunkt schon in Betracht gezogen
werden. Ähnliches trifft auch auf die Erweiterbarkeit zu, da neue
Anforderungen und geplante Module, die möglicherweise für das System
vorgesehen sind, bei der Modellierung gefunden und definiert werden
können.
Im weiteren Verlauf der Systementwicklung können Testverfahren je nach
Testaufbau       zum     Messen     eines     jeden     Softwarequalitätsmerkmales
herangezogen werden. So kann z.B. die Effizienz durch eine vorher in Art
und Menge festgelegte Eingabe mittels eines Testverfahrens am bereits
entwickelten System überprüft werden. Die Benutzerfreundlichkeit wird
durch den Rücklauf der Erfahrungen von Betatestern mit dem System
gemessen und kann dadurch gegebenenfalls verbessert werden. Da
Testverfahren meist schon im Laufe der Entwicklung der Software
angewandt werden, ist es zu diesem Zeitpunkt noch schwierig etwas über
die Wiederverwendbarkeit und Verständlichkeit des Systems auszusagen,
denn diese Merkmale sind erst beim fertigen System repräsentativ.
Eine andere Methode zur Verifikation von Softwarequalitätsmerkmalen
während der Entwicklung stellt die Simulation da. Während man beim
Testen am zu entwickelnden System auf realen Daten arbeitet, wird eine
Simulation anhand einer Abstraktion bzw. einem Modell durchgeführt.
Auch      bei   der   Simulation    kann    durch     die   Art   des   Aufbaus   jedes
Qualitätsmerkmal überprüft werden.
Die    Dokumentation         wird    im      ganzen     Systementwicklungsprozess
angewandt und noch nach dessen Fertigstellung weitergeführt. Diese
Methode dient vor allem dazu die internen Softwarequalitätsmerkmale zu
bewahren und besser bewerten zu können.




Model Checking Beispiele aus der Praxis                                               4
Um    für   bestehende      Systeme       bestimmte   Softwarequalitätsmerkmale
verifizieren zu können, könnte die Technik des Model Checkings benutzt
werden, da sie geeignet ist bestimmte Eigenschaften in einem System zu
überprüfen. Bei größeren Systemen wird dabei auf das so genannte
symbolische Model Checking zurückgegriffen. Auf diese Technik wird in
Kapitel 2 näher eingegangen.
Anhand von zwei Beispielen wird in Kapitel 3 der Einsatz von Model
Checking zur Messung und Wahrung von Softwarequalität gezeigt.
Inwieweit die Technik des Model Checkings für die Entwicklung von
qualitativ hochwertiger Software geeignet ist, wird in Kapitel 4 erläutert
und bewertet.




Model Checking Beispiele aus der Praxis                                       5
2. Was ist Model Checking?

Nach Clarke et al. [3] ist Model Checking eine Technik zur Verifizierung
endlicher         „state        reactive      systems“.        Die   Spezifikationen   bzw.
Anforderungen werden in temporaler Logik angegeben und das „reactive
system“ wird durch einen Zustandsübergangsgraphen (z.B. endlicher
Automat) modelliert. Eine effiziente Suchprozedur entscheidet dabei
automatisch,              ob      die      angegeben          Spezifikationen   von    dem
Zustandsübergangsgraphen erfüllt werden. Der Model Checker terminiert
entweder mit dem Ergebnis Wahr, welches anzeigt, dass die angegebene
Spezifikation vom Zustandsübergangsgraphen erfüllt wird, oder das
Ergebnis der Terminierung ist ein Gegenbeispiel, das angibt, warum die
Formel vom modellierten Graphen nicht erfüllt wurde. Die Technik des
Model Checking wird in Abb. 1 vereinfacht dargestellt.



        Anforderungen/
                                            System
        Eigenschaften




        Spezifikation /                    Modell als
         Formeln in                        Zustands-
       Temporaler Logik                 übergangsgraph




                             Modell
                            Checker



      Wahr                                    Gegenbeispiel


 Abb. 1 Technik des Model Checkings




Diese Technik zeigt nur bei kleineren Systemen zeitnahe Lösungen, da bei
der Modellierung von größeren Systemen das Zustandsexplosionsproblem
auftritt,        d.h.          der      Zustandsraum           nimmt     exponential    zur
Systembeschreibung zu. Um dennoch größere Systeme mit der Model
Checking Technik zu verifizieren benutzt man effiziente Datenstrukturen


Model Checking Beispiele aus der Praxis                                                   6
wie Binary Decision Diagramms (Binäre Entscheidungsdiagramme). Mit
diesen Datenstrukturen und dem Model Checking Algorithmus erhält man
eine neue Technik die symbolisches Model Checking genannt wird. Diese
Technik und die BDDs werden im Folgenden näher erläutert.


2. 1 Symbolisches Model Checking


Während beim expliziten Model Checking [5] einzelne Zustände im
Zustandsraum betrachtet werden, werden beim symbolischen Modell
Checking mehrere Mengen von Zuständen gleichzeitig betrachtet. Die
einzelnen Mengen können als Prädikate behandelt werden. Bei Prädikaten
handelt es sich um Formeln von booleschen Variablen, welche die
expliziten    Zustände      repräsentieren.      Diese   Formel   werden   beim
symbolischen Model Checking durch Binary Decision Diagrams dargestellt.


2. 2 Binary Decision Diagramms
Binary Decision Diagrams, genauer Reduced Ordered Binary Decision
Diagrams (Reduzierte geordnete binäre Entscheidungsdiagramme, kurz
ROBBDs) sind ähnlich zu den binären Entscheidungsbäumen, wie sie bei
Clarke et al. [3] beschrieben werden. Die Struktur eines ROBDD ist ein
Directed Acyclic Graph, dessen Variablen bzw. Knoten nach der Länge des
Weges von der Wurzel aus geordnet sind. Sie repräsentieren eine
kanonische Form von booleschen Formeln, wobei diese Darstellung
kompakter ist als die konjunktive bzw. disjunktive Normalform, um
logische Operatoren in polynomieller Zeit berechnen zu können.
Ist eine bestimmte Belegung gegeben, d.h. jeder Variable wurde ein Wert
zugewiesen, wird die Formel, repräsentiert durch einen ROBDD, wie folgt
berechnet: Beginnend bei der Wurzel wird für jeden Knoten die Kante als
Übergang      ausgewählt,      deren      Wert   der   zum   Knoten   gehörenden
Variablenbelegung entspricht.
Jeder Knoten wird dabei höchstens einmal betrachtet und die Reihenfolge,
in der die Knoten besucht werden ist immer gleich.




Model Checking Beispiele aus der Praxis                                        7
In Abbildung 2 ist ein ROBBD abgebildet, der die boolesche Formel (a ∧ b)
∨ (c ∧ d) darstellt, wobei die Variablen die Reihenfolge a < b < c < d
besitzen.




   Abb. 2 ROBBD für (a ∧ b) ∨ (c ∧ d)




Model Checking Beispiele aus der Praxis                                 8
3 Praxisbeispiele


Im     Folgenden     wird      am     Beispiel     von   TCAS       II    gezeigt,     welche
Softwarequalitätsmerkmale mit Model Checking bestimmt und verifiziert
werden     können.     Darüber        hinaus      werden     auch    einige      Hindernisse
aufgeführt, die beim Model Checking auftreten können.
Die Wirtschaftlichkeit und Effizienz des Einsatzes eines Model Checkers
wird    anhand      der       Verifikation       der   Softwarevoraussetzungen           des
Militärflugzeuges A-7E Aircraft näher beleuchtet.


3 1 TCAS II


Das Traffic Alert and Collision Avoidance System II (TCAS II) ist ein
Kollisionswarnsystem [6], welches heutzutage Bestandteil in jedem
Verkehrsflugzeug       ist.     Dieses     System      überwacht         den   umgebenden
Luftraum      des   Flugzeugs,         liefert    Informationen      darüber      und    hilft
Zusammenstösse und gefährliche Annäherungen zu vermeiden. In einem
bestimmten      Umkreis        kommunizieren           TCAS-Computer           verschiedener
Flugzeuge     miteinander.          Unterschreitet     ein   anderes      Flugzeug      einen
festgelegten Abstand zum eigenen Flugzeug, so wird das eindringende
Flugzeug auf einem Display im Cockpit dargestellt. Darüber hinaus
erscheint neben dem Flugzeug noch die relative Höhenangabe und ob das
andere Flugzeug im Begriff ist zu sinken oder zu steigen. Kommt das
andere Flugzeug noch näher, verändert sich im Display die Farbe des
Objektes und es ertönt ein akustisches Signal, welches als Traffic Advisory
bezeichnet wird, um die Aufmerksamkeit der Besatzung auf dieses Objekt
zu lenken. Sollte ein Zusammenstoss vom TCAS II berechnet werden, so
gibt    das    System         ca.     35     Sekunden        vor    der    Kollision     eine
Ausweichempfehlung (Resolution Advisory), die entweder einen Sink- bzw.
Steigflug beinhaltet oder eine Kursbeibehaltung vorschlägt.




Model Checking Beispiele aus der Praxis                                                     9
Eine Verletzung der externen Softwarequalitätsmerkmale vom TCAS II vor
allem Korrektheit, Zuverlässigkeit, Robustheit und Effizienz kann im
schlimmsten Fall die Gefährdung von Menschenleben nach sich ziehen.
Eine genauere Überprüfung dieser Merkmale ist daher unabdingbar.
Ein Versuch des Model Checkings von TCAS II wurde von Chan et al. [2]
unternommen. Sie übersetzten einen bedeutsamen Teil einer Frühversion
von TCAS II, um herauszufinden, wie effektiv Model Checking bei
Software Systemen angewandt werden kann. Dabei waren die gewonnen
Erfahrungen wichtiger als die eigentlichen Ergebnisse.


3. 2 Vorgehensweise beim Model Checking von TCAS II


Um das TCAS II mit einem Model Checker zu verifizieren, haben Chen et
al. [2] die Spezifikationen der Systemvorrausetzungen, dargestellt in der
„Requirements State Machine Language“ (kurz RSML), in eine Eingabe für
den symbolischen Model Checker umgewandelt. RSML ist eine Sprache für
Zustandsmaschinen,         die   auf      hierarchischen   Statechart-Diagrammen
basiert.   Zustandshierarchien         heißt,   dass   jeder   Zustand   Z   einen
Unterzustand haben kann und Z für jeden dieser Unterzustände als
Superzustand bezeichnet wird. Eingaben für die RSML Maschine werden
von der Umwelt erzeugt. Die Zustände in RSML werden durch Ereignisse
synchronisiert, die entweder von der Umwelt (externe Ereignisse) oder
von der RSML Maschine selbst (interne Ereignisse) ausgelöst werden. Ein
Übergang ist eine gerichtet Kante zwischen zwei Zuständen. Tritt ein
auslösendes Ereignis, welches sowohl intern als auch extern sein kann,
und eine Bedingung, in Abhängigkeit eines Zustandes und/oder einer
Eingabe, für einen Übergang ein, wird dieser erlaubt. Wenn es keine
anderen erlaubten Übergänge, die mit diesem kollidieren, gibt, so wird
dieser Übergang genommen und eventuell werden neue Ereignisse
(interne) erzeugt.




Model Checking Beispiele aus der Praxis                                         10
Der von Chen et al. [2] benutzte Modell Checker ist der „Symbolic Model
Viewer“ (kurz SMV). SMV benutzt BDDs um Mengen von Zuständen und
Übergangsbeziehungen zu repräsentieren.
Bei der Übersetzung von RSML in SMV wurde wie folgt vorgegangen:
Ereignisse wurden in boolesche Variablen übersetzt. Bei den Zuständen
wurden nur die atomaren Zustände, d.h. die Zustände, die keine
Unterzustände besitzen, als boolesche Variablen übersetzt. Eingaben
bekamen in SMV einen Wertebereich zugewiesen, in der der Wert der
Eingabe liegen kann.
Übergänge wurden in SMV so definiert, dass sie alle Bedingungen erfüllen
müssen unter denen sie erlaubt sind. Zusätzlich wurden noch die
Zustandsänderungen und die Ereignisse in SMV spezifiziert, die bei einem
genommenen Übergang ausgelöst werden.


3. 3 Hindernisse beim Model Checking von TCAS II


Probleme die im Zusammenhang mit dem Model Checking von TCAS II
auftraten,      waren      die     Größe         der     in     RSML     spezifizierten
Systemvoraussetzungen            von      TCAS    II,    Inkonsistenzen       bei   den
Wertebereichen der numerischen Variablen, die Größe der BDDs und die
Dauer beim Finden von Gegenbeispielen. Das erste Hindernis wurde
dadurch beseitigt, dass nur das eigene Flugzeug verifiziert wurde und
dieses auch nur mit einem anderen Flugzeug interagierte. Dadurch
wurden nur 30 Prozent der Spezifikation benutzt.
Diese    Einschränkung        führte      dann    aber        auch   dazu,   dass   die
Softwarequalitätsmerkmale Korrektheit, Zuverlässigkeit, Robustheit und
Effizienz nur eingeschränkt auf dieses übersetzte Fallbeispiel bewertet
werden konnten. So kann es sein, dass der übersetzte Teil korrekt
arbeitet, aber das eigentliche System sich nicht hundertprozentig so
verhält, wie es in den Anforderungen definiert ist. Dieser Sachverhalt kann
ebenso    auf   die   übrigen     drei    Softwarequalitätsmerkmale          übertragen
werden, denn sie können in der Übersetzung als vollständig verifiziert
werden, obwohl sie es im eigentlichen System nicht sind.


Model Checking Beispiele aus der Praxis                                              11
Die Inkonsistenzen wurden durch den Einsatz von begrenzten Integer
behoben, die für alle Eingaben als Wertebereich definiert wurden. Somit
wurde durch diese Änderung das Qualitätsmerkmal Robustheit in der
Eingabe gegenüber der Spezifikation aufgewertet und gewährleistet.
Die großen BDDs wurden durch Mechanismen, die in SMV zusätzlich
implementiert sind, wie Neuordnung von Variablen und konjunktive
Partitionierung [1], wesentlich reduziert. Um die Dauer beim Auffinden
von     Gegenbeispielen     zu   reduzieren,   wurde     der    Model   Checker   so
modifiziert, dass die Methode zum Suchen nach dem Gegenbeispiel auf die
Informationen der Falsifizierung der Formel zurückgreift.


3. 4 Ergebnisse


Die Eigenschaften des TCAS II, die mithilfe von SMV verifiziert wurden,
lassen sich in zwei Kategorien einteilen: Generelle Eigenschaften der
Spezifikationen von RSML und domainspezifische Eigenschaften. Erstere
sollten für jedes zu verifizierende System wahr werden, während Letztere
Eigenschaften sind, die nur auf das zu testende System zu treffen.


Die generellen Eigenschaften, die von Chen et al. [2] aufgeführt wurden
sind Übergangskonsistenz, Funktionskonsistenz und Schrittterminierung.
Diese    drei   Eigenschaften      finden   sich    im   Softwarequalitätsmerkmal
Korrektheit wieder, d.h. wenn ein System sich korrekt verhält, müssen
unter anderem diese drei Eigenschaften erfüllt sein.
Bevor auf die Überprüfung der Gewährleistung der Übergangskonsistenz
eingegangen wird, müssen zuerst zwei unterschiedliche Arten von
nondeterministischen Übergängen erläutert werden. Auf der einen Seite
gibt es gewollte nondeterministische Übergänge, die von der Logik her in
den Spezifikationen auftauchen oder die durch die Abstraktion in SMV
implementiert         wurden.        Andererseits        gibt     es     ungewollte
nondeterministische Übergänge, die in den Spezifikationen auftauchen und
die aufgedeckt werden sollen, weil ansonsten die korrekte Verifizierung
durch den SMV Model Checker gefährdet ist. Beispielsweise erlauben es


Model Checking Beispiele aus der Praxis                                           12
einige    dieser    Übergänge,      dass     unter      gleichen       Bedingungen          zwei
verschiedene       Aktionen    ausgeführt        werden.       Unter     dem    Aspekt       der
Korrektheit bedeutet diese Inkonsistenz, dass das System sich nicht
korrekt verhält, da dieses Verhalten in bestimmten Situationen nicht
vorhersehbar ist. Da die Merkmale Zuverlässigkeit und Korrektheit eng
miteinander verbunden sind, ist in diesem Falle auch die Zuverlässigkeit
nicht vollständig gewährleistet. Diese bekannte Inkonsistenz wurde von
Chen et al. [2] in einer frühen Version von TCAS II gefunden und es
wurde nachgewiesen, dass sie in späteren Versionen nicht mehr auftrat.
An dieser Stelle konnte anhand einer frühen Version des zu verifizierenden
Systems erfolgreich eine Verletzung der Merkmale Korrektheit und
Zuverlässigkeit mittels Model Checking aufgezeigt werden.
Die Funktion „Displayed-Model-Goal“ hat acht Fälle definiert, die sich
gegenseitig ausschließen. Der Model Checker fand dazu ein Gegenbeispiel
und nach sorgfältiger Untersuchung war es das Modell des „anderen“
Flugzeugs, welches den Fehler verursachte. Nach der Änderung des
Modells     wurde      kein     Gegenbeispiel           mehr      gefunden         und       die
Funktionskonsistenz für „Displayed-Model-Goal“ war gewährleistet. Die bei
diesem Ergebnis nachgewiesene Verletzung der Korrektheit ist auf eine
unzureichende Modellierung im Model Checking Prozess zurückzuführen.
Trotzdem ließ sich dieser Fehler anhand der Auswertung der Ergebnisse
des Model Checkers nachvollziehen und beheben.
Das      Model   Checking     ergab       außerdem,       dass    die     Formel      für    die
Schrittterminierung      erfüllt    wurde        und    damit     wurde        eine   weitere
Eigenschaft der Korrektheit bewiesen.


Eine      domainspezifische        Eigenschaft         betrifft    die     Sperrung          der
Ausweichempfehlung fürs Sinken. Die Spezifikationen besagen, dass alle
Ausweichempfehlungen           fürs       Sinken       unter      1000     ft     und       alle
Ausweichempfehlung für den verstärkten Sinkflug unter 1450 ft nicht
ausgegeben         werden     dürfen      [2].    Mittels      Model      Checker       wurde
herausgefunden, dass die erste Eigenschaft erfüllt, aber die Zweite
verletzt wurde. Das Gegenbeispiel des Model Checkers zeigte einen


Model Checking Beispiele aus der Praxis                                                       13
typographischen Fehler in den Spezifikationen (> anstelle von ≤). Die
Auswirkung dieses Fehlers könnte somit die Sicherheit des Flugzeuges
gefährden. Bei diesem Fehlverhalten des Programms, konnte sowohl eine
Verletzung       als         auch     die     Ursache      der     Verletzung      des
Softwarequalitätsmerkmals Korrektheit nachgewiesen werden.
Die     Übereinstimmung             der     Ausgaben     wird    als    eine    weitere
domainspezifische            Eigenschaft     angesehen.     Zwei       Ausgaben    mit
Anweisungen für den Piloten, müssen aufgrund von sicherheitskritischen
Aspekten übereinstimmen. Hier wurde vom Model Checker, wie beim
Beispiel Funktionskonsistenz, ein Gegenbeispiel gefunden, welches nach
genauerer Untersuchung und Änderung des Modells des „anderen“
Flugzeugs, welches der Grund für den Fehler war, nicht wieder auftrat. Die
Wiederholung einer Verletzung der externen Softwarequalitätsmerkmale
durch die Abstraktion des Systems zeigt, dass, obwohl die Ursachen
mittels    Model       Checkings      aufgedeckt       werden    können,   durch    die
Übersetzung der Spezifikationen sich die Merkmale der Softwarequalität
ändern können, was zu einer Verfälschung der Messergebnisse führen
kann.


3. 5 Schlussfolgerungen


Die Verifizierung von TCAS II mithilfe symbolischen Model Checkings
durch Chen et al. [2] zeigt, wie mächtig diese Technik ist, vorausgesetzt
man weiß im Vorfeld welche Eigenschaften bzw. Spezifikationen überprüft
werden     sollen.     Für    eine   Bewertung     der    Softwarequalitätsmerkmale
bedeutet dies, dass man die zu einem Merkmal gehörenden Eigenschaften
genau definieren und deren Allgemeingültigkeit bei der Übertragung der
Eigenschaften auf das Merkmal überprüfen sollte.
Einige Problembereiche wurden ebenfalls beim Model Checking von TCAS
II aufgezeigt, z.B. dass größere Systeme abstrahiert werden müssen und
dass Model Checking nur auf endliche Zustände angewendet werden kann.
Ansonsten muss aus einem System mit unendlichem Zustandsraum ein
Endliches abstrahiert werden. Durch diese Abstraktion ist dann eine


Model Checking Beispiele aus der Praxis                                              14
hundertprozentig übertragbare Bewertung der Qualität des Systems nicht
mehr gegeben.
Chen et al. [2] zeigt weiterhin auf, dass die Model Checking Technik schon
während     der    Entwicklung     eingesetzt     werden    sollte,    da    dies   zwei
entscheidende Vorteile mit sich bringt. Erstens ist der Entwickler dadurch
schon frühzeitig in der Lage Fehler zu finden, zu analysieren und zu
beheben. Diese Anwendung von Model Checking würde vor allem die
externen Softwarequalitätsmerkmale bewahren und damit die Qualität des
Systems erhöhen. Der zweite Vorteil ist, dass der Entwickler mithilfe der
Gegenbeispiele das System und seine internen Schnittstellen näher
kennen lernt und dadurch besser in der Lage ist das System zu
dokumentieren. Dies bringt den Vorteil, dass dadurch auch interne
Softwarequalitätsmerkmale, wie die Verständlichkeit und Wartbarkeit
beachtet werden.
Auf der anderen Seite nutzt es wenig, wenn ein fertiges System, welches
durchaus als Komplex bezeichnet werden kann, mit der Model Checking
Technik verifiziert wird. Zu diesem Zeitpunkt muss das System abstrahiert
werden, um es zu überprüfen. Wenn Fehler gefunden werden, sind diese
nicht mehr so einfach zu beheben, wie bei einem System, welches sich
noch in der Entwicklung befindet. Änderungen, die dazu beitragen, dass
ein Softwarequalitätsmerkmal erfüllt wird, können zu diesem Zeitpunkt
Verletzungen eines anderen Merkmals nach sich ziehen.


Wie    am    Beispiel    von    TCAS      II   gezeigt,   lassen      sich   bestimmte
Softwarequalitätsmerkmale mit Model Checking verifizieren, wobei auch
einige Probleme dargestellt wurden. Diesbezüglich stellt sich die Frage, ob
es noch weitere Grenzen gibt, die die Anwendung eines Model Checkers in
der Systementwicklung unnötig machen?
Um diese Frage zu beantworten, wird im Folgenden auf ein weiteres
Beispiel der Anwendung von Model Checkung eingegangen.




Model Checking Beispiele aus der Praxis                                               15
3. 6 A-7E Aircraft


Anhand der Softwarevoraussetzungen des A-7E Flugzeuges wurden von
Sreemani et al. [7] die Möglichkeiten von Model Checking getestet. Dabei
ging es hauptsächlich darum, das Einsatzgebiet des SMV Model Checkers
und    dessen      Effektivität    und    Effizienz     zu    erproben.     Aus    der
Softwarevoraussetzung des A-7E ließen sich fünf sicherheitsrelevante
Eigenschaften ableiten, die überprüft werden sollten. Da die gesamte
Fallstudie    automatisiert       ablaufen    sollte,     wurde      ein   Programm
implementiert welches die Spezifikation der Voraussetzungen in die
Eingabe für SMV umwandelte. Um akkurate und bessere Ergebnisse zu
erzielen, musste im Vorfeld die Spezifikation des A7-E Flugzeuges einigen
Änderungen unterzogen werden. Auch die für den SMV benötigten BDDs
mussten      während      des     Prozesses   neu       angeordnet     werden,     um
Speicherplatz und Rechenleistung einzusparen.
Für die Verifikation der Softwarequalität wurde an diesem Beispiel gezeigt,
dass Model Checking ein automatisiertes Werkzeug ist, mit welchem in
relativ kurzer Zeit Softwarequalitätsmerkmale gemessen werden können.
Dabei muss jedoch eine gründliche Vorarbeit anhand von formaler
Spezifikation     der    Softwarevoraussetzungen            vorhanden,     sowie   ein
Programm implementiert sein, welches die Spezifikation in die Eingabe
des Model Checkers übersetzen kann. Unter Umständen muss zusätzlich
eine manuelle Nachbearbeitung der BDDs in Kauf genommen werden. Der
zusätzliche Aufwand durch Vor- und Nacharbeitung sollte dabei in einem
wirtschaftlich     verträglichen      Verhältnis      zum     Gesamtaufwand        der
Systementwicklung stehen.




Model Checking Beispiele aus der Praxis                                             16
4      Bedeutung                        von           Model                 Checking         für     die
Softwarequalität


Die Beispiele aus dem letzten Kapitel haben gezeigt, dass Model Checking
als Technik zur problemlosen Wahrung von Softwarequalität unter
gewissen Einschränkungen durchaus einsetzbar ist.
Diese Einschränkungen, Hindernisse und offene Fragen aber auch Vorzüge
und Einsatzmöglichkeiten sollen im Folgenden vorgestellt werden.


Model Checking kann nur einen Teil, wie in Abbildung 3 dargestellt, der
von Ghezzi et al. [4] definierten Softwarequalitätsmerkmalen überprüfen.
Darunter fallen die externen Merkmale Korrektheit, Zuverlässigkeit,
Robustheit und Effizienz, sowie die Wartbarkeit und die Verständlichkeit.



       Anforderungen/
                                                                 System
       Eigenschaften




       Spezifikation /                                           Modell als
        Formeln in               Verständlichkeit                Zustands-
      Temporaler Logik                                        übergangsgraph




                                        Modell
                                                                        Effizienz
                                       Checker




          Korrektheit                                         Wartbarkeit




                     Zuverlässigkeit             Robustheit



  Abb. 3 Verifizierte Softwarequalitätsmerkmale durch Model Checking




Korrektheit und Zuverlässigkeit liegen eng beieinander, denn ein korrektes
System         ist      vollständig          zuverlässig.           Werden          vom   Model   Checker



Model Checking Beispiele aus der Praxis                                                                17
Eigenschaften des Systems, die auch Eigenschaften der Korrektheit sind,
wie z.B. Terminierung oder Konsistenz, überprüft und bewertet, so lassen
sich diese Aussagen auch auf die Zuverlässigkeit übertragen.
Das Softwarequalitätsmerkmal Robustheit kann durch die Fähigkeit des
Model Checkers eine Eigenschaft als Falsch zu bewehrten und dazu noch
ein Gegenbeispiel anzubringen erheblich verbessert werden. Durch diese
Gegenbeispiele lässt sich die Menge von nicht erwarteten, aber dennoch
möglichen, Eingabedaten erheblich reduzieren, vorausgesetzt, dass die
entsprechenden Eigenschaften des Systems verifiziert werde.
Effizienz    kann,      wenn   auch       mittels    anderer   Techniken,       wie   z.B.
Testverfahren, effizienter überprüfbar, durch geeignete Eigenschaften und
genügend große Eingabemengen vom Model Checker gemessen werden.
Dabei können anhand der Resultate keine Aussagen über die Effizienz des
Systems, sondern nur über die Effizienz der übersetzten Eingabe für den
Model Checker getroffen werden. Diese Ergebnisse können aber dazu
dienen Schlussfolgerungen über die Effizienz des eigentlichen Systems,
z.B. dessen Ressourcenverbrauch oder das Verhalten des Systems bei
bestimmten Größen von Eingaben, zu ziehen.
Da     das     letzte     externe         Merkmal      der     Softwarequalität,      die
Benutzerfreundlichkeit, ein subjektiv zu beurteilendes Merkmal ist, ist hier
eine Bewertung mittels Model Checker unangemessen.
Allein die Anwendung eines Model Checkers, um bestimmte Eigenschaften
zu überprüfen, hilft das interne Softwarequalitätsmerkmal Wartbarkeit zu
bewahren, denn dadurch werden Fehler aufgezeigt und durch die
gefundenen Gegenbeispiele können diese korrigiert werden. Weiterhin
kann man zusätzlich zur angegebenen Spezifikation des Systems neue
Anforderungen modellieren und mittels Model Checker überprüfen.
Das   Merkmal        Verständlichkeit      wird     zum   einen   durch   die    formale
Dokumentation der Spezifikation als Vorarbeit der Übersetzung der
Eingabe eines Model Checkers, zum anderen durch dessen Benutzung
selbst, bewahrt und verbessert. Um diese Technik anzuwenden, werden
Kenntnisse über das System benötigt, denn aus diesem werden die zu
verifizierenden Eigenschaften abgeleitet.


Model Checking Beispiele aus der Praxis                                                18
Über     die     Merkmale       Wiederverwendbarkeit,            Portierbarkeit    und
Interoperabilität kann mittels Model Checking wenig ausgesagt werden, da
diese das System und nicht eine Übersetzung bzw. Abstraktion betreffen.


Einen Vorteil den symbolisches Model Checking mit sich bringt ist, dass es
große komplexe Systeme verifizieren kann. Wobei dann das System in
manchen Fällen abstrahiert werden muss und die Verifikation sich nur auf
einige Teile des Systems beziehen kann. Somit kann Model Checking
sowohl im Verlauf der Softwareentwicklung als auch nach Vollendung des
Systems eingesetzt werden, um nachträglich die Qualität der Entwicklung
zu verbessern.


Durch    die    eventuelle    Abstraktion        und   durch   die   Übersetzung   der
Spezifikation fällt zusätzliche Arbeit im Softwareentwicklungsprozess an,
die möglicherweise den Ressourcenrahmen der Entwicklung überschreiten
würde. Darüber hinaus können durch die Vorbereitungen für den Model
Checker Fehler in der Übersetzung auftreten, die durch ihn zwar entdeckt
werden können, aber den Arbeitsaufwand unnötigerweise erhöhen und
gegebenenfalls das Ergebnis verfälschen.


Eine automatisierte Verwendung der Model Checking Technik ist gegeben,
nur müssen dafür noch einige Vorkehrungen getroffen werden. Zum einen
muss die vorhandene Spezifikation der Systemvorrausetzungen formal
dokumentiert werden, so dass sie mittels eines zusätzlich implementierten
Programms in die Eingabe des Model Checkers übersetzt werden können.
Andererseits müssen die dem Model Checker zugrunde liegenden BDDs
optimiert      werden   damit    schnell    Ergebnisse     erzielt   und   Ressourcen
eingespart werden können. Diese Arbeit könnte durch den Model Checker
übernommen         werden,       um       eine     stärkere    Automatisierung      zu
gewährleisten. Die Dokumentation der Vorrausetzungen des Systems liegt
dennoch weiterhin bei den Entwicklern und sollte deswegen gründlich und
gewissenhaft erledigt werden.




Model Checking Beispiele aus der Praxis                                             19
5 Fazit


Mittels Model Checking gewinnt die Systementwicklung eine Technik, mit
der, in Verbindung mit anderen Methoden, die Qualität von Software
bewahrt und verbessert werden kann. Vor allem bei der Entwicklung von
großen, komplexen Systemen in Verbindung mit einer gründlichen
Vorarbeit bietet Model Checking eine schnelle und genaue automatisierte
Methode, mit der die Mehrzahl der Softwarequalitätsmerkmale gemessen
und verbessert werden können.




Model Checking Beispiele aus der Praxis                              20
Abbildungsverzeichnis
Abb. 1: Technik des Model Checkings................................................ 6
Abb. 2: ROBBD für (a ∧ b) ∨ (c ∧ d) .................................................. 8
Abb. 3: Verifizierte Softwarequalitätsmerkmale durch Model Checking .. 17




Model Checking Beispiele aus der Praxis                                                21
Literatutverzeichnis
[1] J. R. Burch, E. M. Clarke, D. E. Long, K. L. McMillan und D. L. Dill:
Symbolic     model     checking     for   sequential   circuit   verification.   IEEE
Transactions on Computer-Aided Design of Integrated Circuits, 13(4):401-
424, April 1994


[2] W. Chan, R.J. Anderson, P. Beame, S. Burns, F. Modugno, D. Notkin
und J.D. Reese: Model Checking Large Software Specifications. IEEE TSE,
24(7):498-519, Juli 1998


[3] E. Clarke, O. Grumberg und D. Long: Model Checking. http://www-
2.cs.cmu.edu/~modelcheck/pubs.htm


[4] C. Ghezzi, M. Jazayeri, D. Mandrioli: Fundamentals of Software
Engineering. Pearson Prentice-Hall, Upper Saddle River, NJ, 1991


[5] D. Notkin: Symbolic Model Checking for Large Software Specifications.
www.isr.uci.edu/events/dist-speakers00-01/notkin01.ppt,              University    of
Washington, April 2001


[6] M. Rohrer: TCAS - Schutzengel der Luftfahrer. Wissen Lexikon,
http://www.vpfa.ch/wissen/wi_lexikon_TCAS.htm, Nov 2002


[7] T. Sreemani, J. M. Atlee: Feasibility of Model Checking Software
Requirements: A Case Study. 11th Annual Conference on Computer
Assurance, Juni 1996




Model Checking Beispiele aus der Praxis                                            22

								
To top