Effizientes Model-Checking für CTL - Institut für Theoretische ...

Effizientes Model-Checking für CTL 

Diplomarbeit 

im Studiengang Mathematik mit Studienrichtung Informatik 

Julia Gerock 

Mtr.-Nr. 2294990 

Institut für Theoretische Informatik 

Fakultät für Elektrotechnik und Informatik 

Leibniz Universität Hannover 

Prüfer: Prof. Dr. Heribert Vollmer 

Zweitprüfer: Prof. Dr. Rainer Parchmann 

Betreuer: M. Sc. Arne Meier 

26. Oktober 2009

Danksagung 

Ich bedanke mich ganz herzlich bei Herrn Arne Meier für die hervorragende Betreuung 

und Unterstützung meiner Diplomarbeit.

Inhaltsverzeichnis 

1 Einführung 1 

1.1 Motivation und Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . 1 

1.2 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 

2 Theoretische Grundlagen 3 

2.1 Model-Checking-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 

2.2 Kripke-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 

2.3 CTL als eine von temporalen Logiken . . . . . . . . . . . . . . . . . . . . . . 5 

2.4 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

2.5 Komplexitätstheorie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

3 Model-Checking für CTL 13 

3.1 Formulierung des Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

3.2 Komplexität des Model-Checking-Problems für CTL . . . . . . . . . . . . . 14 

3.3 Model-Checking für CTL und CTLpos . . . . . . . . . . . . . . . . . . . . . 15 

3.3.1 CTL-MC(ALL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.3.2 CTLpos-MC(EX, EG, EU, ER) . . . . . . . . . . . . . . . . . . . . 17 

4 Design und Implementierung 21 

4.1 Basisprogramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

4.2 Neue Klassenstruktur und die Implementierungsaspekte . . . . . . . . . . 22 

4.3 Bedienungsanleitung zum Programm . . . . . . . . . . . . . . . . . . . . . . 30 

5 Auswertung von Algorithmen 36 

5.1 Allgemeine Beschreibung der Experimente . . . . . . . . . . . . . . . . . . . 36 

5.1.1 Testsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

5.1.2 Testdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5.1.3 Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 

5.2 Zwei Implementierungen des CTLpos-Algorithmus . . . . . . . . . . . . . . 38 

5.3 Auswertung von CTLpos- und CTL-Algorithmen . . . . . . . . . . . . . . . 40 

5.4 Laufzeit des CTL-Algorithmus für Kripke-Strukturen mit bis zu 300 Zuständen 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

6 Zusammenfassung und Ausblick 48 

Literaturverzeichnis 54

1 Einführung 

1.1 Motivation und Aufgabenstellung 

Heutzutage werden Software- und Hardware-Systeme so gut wie in jedem Gebiet eingesetzt 

und haben sich in unserem Leben fest etabliert. Somit wird die Abhängigkeit 

von der Zuverlässigkeit dieser Systeme immer größer. Andererseits wird es schwieriger, 

die Funktionsweise fehlerfrei zu gewährleisten, da sich der Umfang und die Komplexität 

der Systeme auch ständig steigern. Mithilfe der Standardmittel wie Testen oder Simulation 

werden Fehlerfälle oft unvollständig abgedeckt. Und sogar bei einer vollständigen 

Abdeckung kann das System weitere Fehler enthalten, die nicht entdeckt wurden. 

Deswegen ist die Notwendigkeit entstanden, neue, möglichst effiziente Methoden zu 

entwickeln, um mit deren Hilfe die Korrektheit und somit die Qualität eines Systems 

zu sichern und beweisen zu können. Dies kann ermöglicht werden, indem ein zu entwickelndes 

System sowie dessen relevante Eigenschaften formalisiert werden, und es durch 

Verifikation überprüft wird, ob die gewünschten Eigenschaften im System erfüllt sind. 

Model-Checking als eine dieser Methoden basiert auf diesem Prinzip. Dabei werden 

ein Modell M, als eine Beschreibung des Systems, und eine logische Formel ϕ, als eine 

Spezifikation des Systems, verifiziert (M ⊧ ϕ). 

Je nach der Art der Formeln 1 werden diverse Klassen von Model-Checking-Problemen 

unterschieden. Diese Arbeit befasst sich mit dem Model-Checking-Problem für CTL 

(Computation Tree Logic). 

Ziel der Arbeit besteht darin, dieses Problem in Bezug auf seine Effizienz auszuarbeiten. 

Als Basis werden die im Institut für Theoretische Informatik der Leibniz Universität 

Hannover entstandenen Ergebnisse der Forschung des Model-Checking-Problems verwendet, 

die weiter unten dargestellt sind. Das Model-Checking-Problem für CTL ist als 

P-vollständig bekannt. Zugehörigkeit eines Problems zu einer Komplexitätsklasse kann 

durch Angeben eines Algorithmus bewiesen werden, der dieses Problem entscheidet und 

selbst in dieser Komplexitätsklasse liegt. Ein weiteres Ziel der Arbeit ist es, diverse Algorithmen 

des Model-Checking-Problems für CTL vorzustellen, zu implementieren und 

ihre Effizienz zu vergleichen. 

1 In Abhängigkeit davon, welche Operatoren erlaubt bzw. welche Constraints festgelegt sind (z. B. CTL, 

CTL*, LTL). 

1

1.2 Gliederung 

1 Einführung 

In der vorliegenden Arbeit wird nach der Einleitung in Kapitel 2 auf theoretische 

Grundlagen eingegangen. Hier werden wichtige Grundbegriffe definiert, die für diese Arbeit 

benötigt werden. Danach wird ein Beispiel präsentiert, um ein intuitives Verständnis 

zu schaffen. 

Kapitel 3 bildet den Hauptteil dieser Arbeit. Hier wird das Model-Checking-Problem 

für CTL konkretisiert. Dabei wird untersucht, mit welcher Effizienz dieses Problem gelöst 

werden kann und welche Schwierigkeiten sich dabei ergeben. In Abschnitt 3.3.1 wird 

das Model-Checking-Problem auf die gesamte Klasse CTL verallgemeinert und ein Algorithmus 

aus [CGP99] präsentiert, der in Polynomialzeit arbeitet. In Abschnitt 3.3.2 

wird ein speziell definiertes Fragment CTLpos betrachtet. Für dieses wird hier ein weiterer 

Entscheidungsalgorithmus aus [BMT + ] vorgestellt. 

In Kapitel 4 wird behandelt, wie die in Kapitel 3 geschilderten Algorithmen implementiert 

werden können. Diese werden als eine Erweiterung eines existierenden Programms 

([Sol09]) realisiert. Das Programm wird hier auch kurz erläutert. 

In Kapitel 5 wird die Laufzeit der Algorithmen für CTL und CTLpos untersucht und 

verglichen. Experimente und deren Ergebnisse werden hier veranschaulicht. 

Kapitel 6 enthält eine Zusammenfassung und einen Ausblick der Diplomarbeit. 

2

2 Theoretische Grundlagen 

In diesem Kapitel werden die für diese Arbeit relevanten Begriffe wie Model-Checking, 

Kripke-Struktur, temporale Logik und insbesondere CTL eingeführt und in Anlehnung 

an [CGP99] definiert. Diese werden anschließend mittels eines Beispiels verdeutlicht. 

Um die Effizienz des Model-Checking-Problems untersuchen zu können, werden auch 

die für dieses Thema wichtigsten Resultate der Komplexitätstheorie in diesem Kapitel 

zusammengefasst. 

2.1 Model-Checking-Prozess 

Model-Checking ist als eine Verifikationsmethode von endlichen zustandsbasierten Systemen 

bekannt, die die Korrektheit eines Systems bezüglich seiner Spezifikation beweist 

oder widerlegt und dabei automatisch abläuft. Diese zwei vorteilhaften Aspekte unterscheiden 

Model-Checking von den anderen Verifikationsverfahren (z. B. deduktive Verifikation) 

sowie von dem Testen und der Simulation erheblich (vgl. [Sch]). Der Begriff wurde 

in den 80 Jahren geprägt. Diese Methode ist bereits für den Korrektheitsnachweis beim 

Entwurf von komplexen sequentiellen Schaltungen und von Kommunikationsprotokollen 

erfolgreich praktisch eingesetzt worden (vgl. [CGP99]). Mit Hilfe des Model-Checkings 

können zur Zeit sowohl Hardware- als auch Software-Systeme untersucht werden. 

Im Allgemeinen gliedert sich das Model-Checking in drei Schritte: 

1. Modellierung 

2. Spezifizierung 

3. Verifikation 

Im ersten Schritt muss ein zu analysierendes System S in eine vereinbarte Form gebracht 

werden. Somit wird ein Modell M des Systems S erzeugt. Hier ist es wichtig, 

relevante von nicht relevanten Eigenschaften des Systems zu trennen und nur die signifikanten, 

diese aber alle, abzubilden. Außerdem ist es zu entscheiden, ob das System zum 

Anwenden des Model-Checkings tauglich, d. h. zustandsbasiert und endlich (mit einem 

endlich repräsentierbaren Zustandsraum) ist. Dabei kann eine Zustandsexplosion entstehen. 

In den letzten zehn Jahren wurden aber erhebliche Fortschritte zur Behandlung 

dieses Problems erreicht (siehe [CGP99]). 

Es gibt mehrere Methoden, um ein System in ein Modell zu überführen. In dieser 

Arbeit erfolgt dies mittels Konstruierens einer Kripke-Struktur, die in Abschnitt 2.2 

erläutert wird. 

3


In der Spezifikationsphase werden geforderte Eigenschaften des Systems S formal erfasst. 

Somit entsteht eine Spezifikation als eine Menge von Regeln, die das System erfüllen 

muss. Bei der Erstellung der Spezifikation spielt ihre Vollständigkeit eine zentrale Rolle, 

da nur diejenigen Eigenschaften mit dem Modell verifiziert werden, die in der Spezifikation 

vorkommen. Wenn nicht alle relevanten Systemanforderungen in der Spezifikation 

abgebildet sind, werden sie bei der Verifikation nicht beachtet. Dies kann allerdings zu 

einer falschen Entscheidung führen, dass das Modell die Systemanforderungen erfüllt, 

obwohl das nicht vollständig geprüft wurde. 

Meistens wird temporale Logik als Spezifikationssprache von den Software- und Hardware-Systemen 

benutzt. Temporale Logik ermöglicht es, zeitliche Abläufe des Systems zu 

beschreiben. In diesem Fall wird die Spezifikation als eine Menge von temporal-logischen 

Formeln ϕ formuliert. Jede Formel drückt das nachzuweisende Verhalten des Systems 

über die Zeit aus. In Abschnitt 2.3 wird auf die temporale Logik genauer eingegangen. 

Im letzten Schritt werden spezielle Model-Checking-Algorithmen angewendet, um 

nachzuweisen oder zu widerlegen, dass das Modell M die Spezifikation ϕ erfüllt. Dieser 

Schritt erfolgt größtenteils automatisch, menschliche Teilnahme wird in der Praxis nur 

bei der Analyse der Verifikationsergebnisse gefordert. 

Das Model-Checking-Problem kann folgendermaßen formuliert werden. Sei S ein zu 

analysierendes System. 

Eingabe: ein Modell M des Systems S 

Frage: 

eine nachzuweisende Eigenschaft ϕ, die das System S haben muss 

” Erfüllt das Modell M die Spezifikation ϕ?“ 

(M ⊧ ϕ?) 

Eine genauere Definition für das für die vorliegende Arbeit auszuarbeitende Model- 

Checking-Problem für CTL wird in Abschnitt 3.1 gegeben, nachdem die Begriffe ” Kripke- 

Struktur“ und ” CTL“ in den nächsten Abschnitten eingeführt werden. 

2.2 Kripke-Struktur 

Zum Modellieren von endlichen zustandsbasierten Systemen werden beim Model-Checking 

Kripke-Strukturen verwendet. Diese ermöglichen, Eigenschaften eines Systems in 

verschiedenen Zuständen zu beschreiben, indem bestimmte Aussagen über das System 

den Zuständen zugeordnet werden. Beispielsweise ist eine Ampel (ein System) in einem 

Zustand ” rot“, und dabei wird ein ” Tonsignal“ abgegeben. In diesem Fall wird dieser 

Zustand beim Modellieren der Ampel mit den beiden Aussagen ” rot“ und ” Tonsignal“ 

markiert. 

Eine Kripke-Struktur ist wie folgt definiert (vgl. [CGP99], [BMT + ]). 

4


Definition 2.2.1 (Kripke-Struktur) Sei AP eine Menge der atomaren Aussagen 

(atomic propositions). Eine Kripke-Struktur K über AP ist ein 4-Tupel K = (W, W0, R, 

η), wobei 

1. W eine endliche Menge der Zustände ist; 

2. W0 ⊆ W die Menge der Start-Zustände ist; 

3. R ⊆ W × W eine totale Transitionsrelation ist, d. h. für jeden Zustand w ∈ W gibt 

es einen Zustand w’ ∈ W mit (w, w’) ∈ R; 

4. η ∶ W → P(AP ) eine Beschriftungsfunktion (labelling function) ist, die jedem 

Zustand die Menge der atomaren Aussagen zuordnet, die in diesem Zustand erfüllt 

sind. 

Bemerkung: 

• Manchmal wird die Menge der Start-Zustände nicht explizit angegeben. In diesen 

Fällen wird W0 aus der Definition ausgelassen. 

• Üblicherweise wird die Menge der atomaren Aussagen AP im Hinblick auf die 

gewünschte Spezifikation konstruiert. (vgl. [Sch]) 

In Abschnitt 2.4 ist ein Beispiel zu finden, wie sich ein System als eine Kripke-Struktur 

gestalten lässt. 

2.3 CTL als eine von temporalen Logiken 

Temporale Logik wurde als eine Erweiterung der Aussagenlogik mit dem Ziel definiert, 

zeitliche Änderungen beschreiben zu können. Die Zeit wird hier als Folge (oder später als 

Pfad) von Zuständen betrachtet. In diversen Zuständen können Aussagen verschiedene 

Wahrheitswerte annehmen. Temporale Logik ermöglicht es, für eine logische Aussage ϕ 

solche Beziehungen zu modellieren, wie z. B. ” ϕ gilt immer“, ” ϕ wird nie wahr“, ” ϕ wird 

zum nächsten Zeitpunkt gelten“ usw. Dies erfolgt mittels der sogenannten temporalen 

Operatoren. Um auszudrücken, dass eine Eigenschaft des Systems gelten muss bzw. 

kann, werden die Pfad-Quantoren A bzw. E verwendet. Temporale Operatoren und 

Pfad-Quantoren sind in den Tabellen 2.1 und 2.2 aufgelistet und erläutert. 

Temporale Logik wurde im Jahr 1977 in der Arbeit von A. Pnueli ” The Temporal Logic 

of Programs“ als eine Formalisierungssprache für Spezifikation und Verifikation von 

vergleichbaren Programmen zum ersten Mal vorgestellt und hat sich als eine Spezifikationsmethode 

zur Erfassung von Systemanforderungen beim Model-Checking etabliert. 

5


Operator Syntax Bedeutung Semantik Beispielpfad 

F F ϕ 

” in the 

future“ oder 

” eventually“ 

ϕ gilt irgendwann 

auf dem nachfolgenden 

Pfad 

G G ϕ 

X X ϕ 

U ϕ U ψ 

R ϕ R ψ 

” globally“ 

oder 

” always“ 

ϕ gilt in jedem Zustand 

auf dem Pfad 

” next time“ ϕ gilt im nächsten 

Zustand 

” until“ ϕ gilt in jedem Zustand, 

bis der Zustand 

erreicht wird, 

in dem ψ wahr ist 

” release“ ψ gilt bis zu einem 

Zustand, in dem ϕ 

gilt oder für immer, 

wenn ϕ immer 

falsch ist 

Tabelle 2.1: Temporale Operatoren. ϕ, ψ sind temporal-logische Formeln 

Quantor Syntax Name Semantik 

A A ϕ Allquantor Für alle Pfade gilt ϕ 

E E ϕ Existenzquantor Es existiert ein Pfad, für den ϕ gilt 

Tabelle 2.2: Pfad-Quantoren 

In Abhängigkeit von verwendeten Operatoren und von deren Semantik werden folgende 

Klassen von temporalen Logiken unterschieden: 

LTL: Linear Temporal Logic betrachtet die Zeit als eine lineare Abfolge von Zeitpunkten 

bzw. Zuständen 

CTL: Computational Tree Logic charakterisiert die Zeit als ein verzweigender Ablauf von 

Zuständen 

CTL*: Extended Computation Tree Logic. CTL* ⊃ LTL ∪ CTL. Ausdruckskraft von CTL*, 

CTL und LTL ist nicht vergleichbar, da sich nicht jede in einer Logik formulierte 

6


Aussage in eine äquivalente Aussage in der anderen Logik transformieren lässt. 

Beispiele dazu sind in [CGP99], [Sol09] zu finden. 

Da das Model-Checking-Problem für diese Arbeit auf CTL eingeschränkt ist, wird diese 

Logik hier genauer betrachtet. CTL wurde von Emerson und Clarke eingeführt. Wie die 

anderen temporalen Logiken beinhaltet sie folgende Bausteine: 

• atomare Aussagen 

• boolesche Operatoren ¬(NOT), ∧(AND) und ∨(OR) 

• temporale Operatoren F, G, X, U, R 

• Pfad-Quantoren A, E 

Die Sprache, die aus diesen Operatoren und Quantoren besteht, heißt CTL*. Aus 

diesen Komponenten werden CTL*-Formeln gestaltet. CTL* ist in [CGP99] und [Sol09] 

ausführlich beschrieben. 

Eine CTL-Formel ist eine CTL*-Formel mit einer Einschränkung auf die Verwendung 

von temporalen Operatoren und Pfad-Quantoren. Jeder temporale Operator darf nur 

nach einem Pfad-Quantor auftreten, und jeder Pfad-Quantor darf nur gefolgt von einem 

temporalen Operator in den CTL-Formeln vorkommen. Die Operatoren AF, AG, AX, 

AU, AR werden universale Operatoren genannt, EF, EG, EX, EU, ER heißen existenzielle 

Operatoren. Universale und existenzielle Operatoren bilden die Menge ALL 

von allen CTL-Operatoren. 

Weiter wird eine CTL-Formel induktiv definiert. 

Definition 2.3.1 (CTL-Formel) Sei AP eine Menge von atomaren Aussagen, Q ∈ 

{A, E}. Die Symbole ⊺ und repräsentieren die Wahrheitswerte ” wahr“ und ” falsch“. 

• ⊺, sind CTL-Formeln. 

• Ist p ∈ AP , so ist p eine CTL-Formel. 

• Sind ϕ, ψ CTL-Formeln, dann sind (ϕ), ¬ϕ, ϕ ∧ ψ, ϕ ∨ ψ, QF ϕ, QG ϕ, QX ϕ, 

Q(ϕ U ψ), Q(ϕ R ψ) auch CTL-Formeln. 

Man unterscheidet zwei Arten von Formeln: Zustand- und Pfad-Formeln. Zustand- 

Formeln beschreiben Eigenschaften, die in einem Zustand gelten, und Pfad-Formeln 

charakterisieren Eigenschaften entlang eines Pfades. 

Definition 2.3.2 (Zustand-Formel) 

• ⊺, sind Zustand-Formeln. 

• Ist p ∈ AP , so ist p eine Zustand-Formel. 

• Sind ϕ, ψ Zustand-Formeln, dann sind (ϕ), ¬ϕ, ϕ ∧ ψ, ϕ ∨ ψ Zustand-Formeln. 

• Ist χ eine Pfad-Formel, so ist Aχ eine Zustand-Formel. 

7

Definition 2.3.3 (Pfad-Formel) 

• Ist ϕ eine Zustand-Formel, so ist ϕ auch eine Pfad-Formel. 


• Sind χ, π Pfad-Formeln, dann sind (χ), ¬χ, χ ∧ π, χ ∨ π, Xχ und χ U π Pfad- 

Formeln. 

Weiterhin ist {EX, EU, EG} eine minimale Menge der CTL-Operatoren, da jede 

CTL-Formel in eine äquivalente Formel konvertiert werden kann, in der nur die CTL- 

Operatoren EX, EU, EG sowie die booleschen Operatoren ¬ und ∨ verwendet werden. 

In der Tabelle 2.3 sind die entsprechenden Regeln aufgelistet. 

Regel № Allgemeine Form Konvertierte Form 

1 E ϕ ¬A¬ϕ 

2 ϕ ∧ ψ ¬(¬ϕ ∨ ¬ψ) 

3 EF ϕ E(⊺ U ϕ) 

4 E(ϕ R ψ) EG ψ∨ E (ψ U ¬(¬ϕ ∨ ¬ψ)) 

5 AF ϕ ¬ EG(¬ϕ) 

6 AX ϕ ¬ EX(¬ϕ) 

7 AG ϕ ¬ EF(¬ϕ) 

8 A(ϕ U ψ) ¬ (EG (¬ψ)∨ E (¬ψ U ¬(ϕ ∨ ψ))) 

9 A(ϕ R ψ) ¬ E (¬ϕ U ¬ψ) 

Tabelle 2.3: Darstellung der CTL-Formeln durch die Operatoren EX, EU, EG, ¬, ∨ 

CTL, als eine CTL*-Logik, basiert auf der Kripke-Struktur. Um Systemanforderungen 

mittels CTL-Formeln zu spezifizieren, müssen diverse Eigenschaften des Systems in verschiedenen 

Zeitpunkten beschrieben werden. Die Zeitskala wird als Pfad von Zuständen 

in der das System repräsentierenden Kripke-Struktur interpretiert. Weiter wird ein Pfad 

definiert. 

Definition 2.3.4 (Pfad) Sei K = (W, W0, R, η) eine Kripke-Struktur. Ein Pfad x in 

der Kripke-Struktur K ist eine unendliche Sequenz von Zuständen x = (x1, x2, ...) ∈ W ω , 

so dass (xi, xi+1) ∈ R ∀i ≥ 1. 

In Abschnitt 2.4 wird mittels eines Beispiels gezeigt, wie Systemanforderungen als 

CTL-Formeln erfasst werden können. 

2.4 Beispiel 

Ein Model-Checking-Prozess kann in folgenden Schritten kurz gefasst werden. Sei S ein 

zu analysierendes System. 

1. Modellierung: im ersten Schritt wird ein Modell M vom System S erstellt. M ist 

eine formale Beschreibung des Systems und spiegelt relevante Eigenschaften von S 

wider. Als Modellierungsmechanismus wird hier Kripke-Struktur eingesetzt. 

8


2. Spezifizierung: hier werden Systemanforderungen Φ = {φj ∣ j = 0, 1, ...} erfasst. Für 

diese Arbeit sind solche Eigenschaften von Systemen relevant, die über verzweigende 

Zeit festgelegt werden sollen. Diese werden mittels CTL-Formeln formalisiert. 

3. Verifikation: anschließend wird durch das Anwenden eines Algorithmus das Model- 

Checking-Problem entschieden, das folgendermaßen formuliert werden kann: 

” Erfüllt das Modell M die Spezifikation Φ?“ 

An dieser Stelle wird ein Beispiel vorgestellt, mit dem gezeigt wird, wie Model-Checking 

angewendet werden kann. 

Es handelt sich um das bekannte ” Speisende Philosophen“-Problem (siehe Abbildung 

2.1). 5 Philosophen A, B, C, D und E sitzen um einen Tisch. Es gibt fünf Teller mit 

dem Essen für jeden Philosophen, und zwischen je zwei Tellern liegt eine Gabel. Jeder 

denkt nach und isst abwechselnd. Zum Essen benötigen sie jeweils die beiden Gabeln 

neben sich. Es können somit maximal zwei Personen, die nicht nebeneinander sitzen, 

gleichzeitig speisen (vgl. [Har02]). 

Abbildung 2.1: Speisende Philosophen (vgl. [Sch]) 

Dieses Problem kann als ein zu analysierendes System S betrachtet werden. S kann mit 

Hilfe eines Graphen G (Abbildung 2.2) oder als eine entsprechende Kripke-Struktur K 

(Abbildung 2.3) modelliert und durch bestimmte Regeln (Systemanforderungen) ρj,j=0,1,..., 

die mittels temporal-logischer Formeln (hier CTL-Formeln) ϕj beschrieben werden, spezifiziert 

werden. 

Die Bezeichnungen der Zustände sind so gewählt, dass man erkennen kann, welche 

Philosophen in diesem Moment essen (bis auf den Ausnahmezustand S). Das heißt, im 

Zustand A isst der Philosoph A, im Zustand AC speisen die Philosophen A und C, im Zustand 

S in der Mitte denken alle Philosophen nach. Die Übergänge zwischen den Zuständen 

stellen die Aktionen der Philosophen dar. Wenn ein Philosoph I ∈ {A, B, C, D, E} 

eine Gabel vom Tisch aufnimmt (pick up) bzw. zurückgibt (return), wird der entsprechende 

Übergang mit Ip bzw. Ir beschriftet. 

Wenn man das System S in eine Kripke-Struktur K über AP überführt, ist sie wie 

folgt definiert und in Abbildung 2.3 dargestellt. 

9


Abbildung 2.2: Speisende Philosophen als ein Modell([Har02]) 

K = (W, {S}, R, η), wobei 

• AP = {a, b, c, d, e} die Menge der atomaren Aussagen ist, die den Namen der 

speisenden Philosophen entsprechen; 

• W = {S, A, B, C, D, E, AC, DA, DB, EB, EC} die Menge der Zustände ist; 

• R = {(S, A), (S, B), (S, C), (S, D), (S, E), (A, S), (B, S), (C, S), (D, S), 

(E, S), (A, AC), (A, DA), (B, EB), (B, DB), (C, AC), (C, EC), (D, DB), 

(D, DA), (E, EC), (E, EB), (EB, B), (EB, E), (AC, A), (AC, C), (DB, B), 

(DB, D), (EC, C), (EC, E), (DA, A), (DA, D)} die Transitionsrelation ist; 

• η ∶ W → P(AP ), für p ∈ AP, w ∈ W gilt: p ∈ η(w), falls der Philosoph mit dem 

Namen P ( ” groß p“) in dem Zustand w isst. Z. B. wenn der Philosoph A in dem 

Zustand w speist, dann ist a ∈ η(w). 

Das System S muss unter anderen z. B. folgende Eigenschaften erfüllen: 

• ρ0 = ” Die Philosophen A und B dürfen nie gleichzeitig essen.“ 

• ρ1 = ” Philosoph A isst als erster.“ 

• ρ2 = ” Wenn Philosoph D nichts gegessen hat, kann er irgendwann zusammen mit 

B etwas essen.“ 

10


Abbildung 2.3: Speisende Philosophen als eine Kripke-Struktur 

• ρ3 = ” Immer, wenn Philosoph D fertig gegessen hat, muss er solange nachdenken 

oder warten, bis Philosoph E auch etwas gegessen hat.“ 

Die entsprechenden CTL-Formeln sehen wie folgt aus: 

• ϕ0 = AG ¬(a ∧ b); 

• ϕ1 = A (¬(b ∨ c ∨ d ∨ e) U a); 

• ϕ2 = ¬d → EF(d ∧ b) = d ∨ EF(d ∧ b); 

• ϕ3 = AG(¬d → A(¬d U e)) = AG(d ∨ A(¬d U e)); 

Somit ist K ein Modell des Systems S und Φ = {ϕi ∣ i = 0, ..., 3} ist eine Spezifikation. 

Die Frage, ob das Modell K die Spezifikation Φ erfüllt, kann beantwortet werden, indem 

K und jede φ ∈ Φ verifiziert werden. Dies erfolgt mittels spezieller Model-Checking- 

Algorithmen, die in Kapitel 3 vorgestellt und erläutert werden. 

11

2.5 Komplexitätstheorie 


Da der Verifikationsschritt beim Model-Checking größtenteils automatisch verläuft, ist 

die Frage der Berechnungskomplexität dieses Entscheidungsproblems hoch interessant. 

Die Komplexität von Model-Checking für diverse temporale Logiken wurde in [CES86], 

[Sch02], [EL87] untersucht. Das Model-Checking ist für CTL* PSPACE-vollständig und 

für CTL P-vollständig. Theoretische Hintergründe dafür werden in diesem Abschnitt 

einbezogen. 

Die Komplexitätsklasse P (PTIME), die Klasse der Probleme mit effizienten Algorithmen, 

wird oft als die Klasse der ” effizient lösbaren“ Probleme bezeichnet. Sie besteht 

aus allen Sprachen L, die einen Polynomialzeit-Entscheidungsalgorithmus haben. Ein 

Problem A heißt P-vollständig, falls A ∈ P und jedes andere Problem in P auf A reduzierbar 

ist. P-vollständige Probleme werden manchmal als inhärent sequentiell (inherently 

sequential) bezeichnet, da sie (wenn P ≠ NC) keine NC-Algorithmen haben. 

NC-Algorithmen laufen polylogarithmisch (in O(log c n), c konstant) an einem Parallelcomputer 

mit einer polynomiellen Anzahl von Prozessoren. Die Komplexitätsklasse 

NC beinhaltet die parallel effizient lösbaren Entscheidungsprobleme. Daher lassen sich 

P-vollständige Probleme nicht parallelisieren (wenn P ≠ NC). 

Es gibt einen NC-Algorithmus zum Parsen von kontextfreien Sprachen (CFL), d. h. 

CFL ⊆ NC. Deswegen ist die Klasse LOGCFL bei der Untersuchung der Komplexität des 

Model-Checkings für CTL von großem Interesse. Diese Klasse enthält alle mit logarithmischem 

Speicheraufwand auf CFL reduzierbaren Probleme. Daher gilt LOGCFL⊆NC. 

Andererseits können Sprachen in LOGCFL von nichtdeterministischen Turing Maschinen 

in Polynomialzeit entschieden werden, die ein Arbeitsband logarithmischer Größe 

und zusätzlich einen Stack unendlicher Größe haben (siehe [BMT + ]). Diese Eigenschaft 

von LOGCFL wird bei der Analyse der Komplexität vom Model-Checking-Problem für 

CTL erzielt. 

Im Rahmen dieser Arbeit werden aber nur die Algorithmen aus P ausgearbeitet. 

12

3 Model-Checking für CTL 

Im vorherigen Kapitel wurde der allgemeine Model-Checking-Prozess aufgeführt. Ziel 

dieses Kapitels ist es, diesen Prozess auf CTL zu präzisieren. Nachdem das Model- 

Checking-Problem für CTL definiert wird, wird seine Komplexität in Betracht gezogen. 

Dabei werden die in [BMT + ] (eine vorläufige, unveröffentlichte Version von [BMT + 09]) 

präsentierten Hauptresultate sowie zwei Model-Checking-Algorithmen CTLpos-MC(EX, 

EG, EU, ER) und CTL-MC(ALL) vorgestellt, die in Polynomialzeit arbeiten. Die praktische 

Aufgabe der vorliegenden Arbeit besteht darin, diese Algorithmen zu implementieren 

und ihre Effizienz zu vergleichen. 

3.1 Formulierung des Problems 

In Abschnitt 2.3 wurde die Menge ALL von allen CTL-Operatoren erwähnt. Mit 

CTL(ALL) wird dann die Menge von CTL-Formeln bezeichnet. Bei Aufklärung der Komplexitätsfragen 

ist es hilfreich, nicht nur die gesamte Menge ALL, sondern auch kleinere 

Teilmengen davon zu betrachten. 

Definition 3.1.1 (CTL(T )) Sei T ⊆ ALL eine Menge von CTL-Operatoren. Mit 

CTL(T) wird die Menge von CTL-Formeln bezeichnet, in denen nur die booleschen Operatoren 

{¬, ∧, ∨} und die CTL-Operatoren aus T erlaubt sind. 

Ferner können beliebige eingeschränkte Fragmente von CTL(T ) definiert werden. Für 

die vorliegende Arbeit wird das Fragment CTLpos (T ) benötigt, in dem CTL-Operatoren 

im Bereich einer Negation nicht auftreten dürfen: für a, b ∈ AP gilt 

• ¬EX a ∉ CTLpos (T ) 

• ¬(a ∧ ¬b) ∨ EX a ∈ CTLpos (T ) 

In Abschnitt 2.1 wurde das Model-Checking-Problem in der Frage formuliert, ob ein 

Modell eine Spezifikation erfüllt. Weiterhin muss das auf eine Kripke-Struktur (Modell) 

und eine CTL-Formel (Spezifikation) übertragen werden. Anschließend wird die Erfüllbarkeit 

einer CTL-Formel in Bezug auf eine Kripke-Struktur definiert. 

13


Definition 3.1.2 (Model-Checking-Problem) Sei L ∈ {CTL, CTLpos }. 

Problem: L-MC(T) 

Eingabe: ⟨K, w, ϕ⟩, wobei für die einzelnen Komponenten gilt: 

K = (W, R, η) ist eine Kripke-Struktur, 

w ∈ W ist ein Zustand, 

ϕ ist eine L(T)-Formel. 

Frage: Erfüllt K im Zustand w die Formel ϕ, also K, w ⊧ ϕ? 

Definition 3.1.3 (Semantik) Seien K, w wie in der Definition 3.1.2 und x = (x1, 

x2, ...) ∈ W ω ein Pfad. Ferner seien ϕ, ψ Zustand- und χ, π Pfad-Formeln. Die Evaluierung 

einer Formel zu wahr wird folgendermaßen induktiv definiert. 

K, w ⊧ ⊺ immer, 

K, w ⊧ nie, 

K, w ⊧ p falls p ∈ AP und p ∈ η(w), 

K, w ⊧ ¬ϕ falls K, w ⊧/ ϕ, 

K, w ⊧ (ϕ ∧ ψ) falls K, w ⊧ ϕ und K, w ⊧ ψ, 

K, w ⊧ (ϕ ∨ ψ) falls K, w ⊧ ϕ oder K, w ⊧ ψ, 

K, w ⊧ Aχ falls K, x ⊧ χ ∀x = (x1, x2, ...) mit x1 = w, 

K, w ⊧ χ falls K, x1 ⊧ χ, 

K, w ⊧ Xχ falls K, x2 ⊧ χ, 

K, w ⊧ [χUπ] falls ∃k ∈ IN, so dass K, xk ⊧ π und K, xi ⊧ χ∀1 ≤ i < k. 

Die Erfüllbarkeit der Formeln, in denen die übrigen CTL-Operatoren verwendet werden, 

kann mittels der in Tabelle 2.3 aufgelisteten Umwandlungsregeln überprüft werden. 

Außerdem sagt man, eine Zustand-Formel ϕ wird von einer Kripke-Struktur K erfüllt, 

wenn es einen Zustand w ∈ W gibt, so dass K, w ⊧ ϕ. Und analog, eine Pfad-Formel χ 

wird von einer Kripke-Struktur K erfüllt, wenn es einen Pfad x = (x1, x2, ...) gibt, so 

dass K, x ⊧ χ. Geschrieben: 

• K ⊧ ϕ ⇐⇒ ∃w ∈ W ∶ K, w ⊧ ϕ 

• K ⊧ χ ⇐⇒ ∃x = (x1, x2, ...) ∶ K, x ⊧ χ 

3.2 Komplexität des Model-Checking-Problems für CTL 

Im Allgemeinen gilt Model-Checking für CTL als P-vollständig. Obwohl es in Polynomialzeit 

lösbar ist, lässt das Problem sich nicht parallelisieren (falls P ≠ NC). Daher werden 

Fragmente von CTL betrachtet, um leichtere Teilprobleme zu finden, die effizienter zu 

lösen sind. 

Die in [BMT + ], [BMT + 09] erhaltenen Resultate können folgendermaßen zusammengefasst 

werden. 

14


1. Nicht-parallelisierbare Fälle: P-Vollständigkeit liegt für alle CTL-Fragmente vor, in 

denen mindestens ein CTL-Operator benutzt wird. 

2. Trivialfall: Für Fragmente ohne temporale Operatoren stimmt das Model-Checking-Problem 

mit der Auswertung einer aussagenlogischen Formel überein, und 

dieses Problem ist NC 1 -vollständig, d. h. parallelisierbar. NC 1 ist eine NC-Klasse 

der Sprachen, die in O(log 1 n)-arbeitende Entscheidungsalgorithmen haben (siehe 

[BMT + 09]). 

3. Parallelisierbare und nicht-triviale Fälle: Model-Checking-Problem CTLpos-MC(T ) 

ist LOGCFL-vollständig, falls ∅ ⊊ T ⊆ {EX, EF} oder ∅ ⊊ T ⊆ {AX, AG} (vgl. 

[BMT + 09]). 

Für diese Arbeit ist der erste Fall relevant. Auf diesen wird in Abschnitt 3.3 genauer 

eingegangen. 

3.3 Model-Checking für CTL und CTLpos 

Dieser Abschnitt enthält wichtigste Ergebnisse zur Komplexität von Model-Checking für 

CTL und für das in Abschnitt 3.1 definierte negationsbeschränkte Fragment CTLpos . Die 

entsprechenden Entscheidungsalgorithmen werden hier vorgestellt und erörtert. 

3.3.1 CTL-MC(ALL) 

Satz 3.3.1 CTL-MC(ALL) ∈ P 

In [CGP99] wurde ein Algorithmus vorgestellt, der das Problem CTL-MC(ALL) in 

Polynomialzeit entscheidet. Dieser wird im Weiteren beschrieben. Seien K = (W, R, 

η) eine Kripke-Struktur und ϕ eine CTL-Formel. Der Algorithmus bestimmt, in welchen 

Zuständen aus W die Formel ϕ erfüllt wird. Die Formel ϕ wird in die Teilformeln zerlegt. 

Unter einer Teilformel wird hier eine Formel verstanden, aus der mit Hilfe der Operatoren 

die betrachtete Formel konstruiert wird. Z. B. für ϕ = γ ∧ λ oder für ϕ = EXγ sind γ, λ 

die Teilformeln von ϕ. Jeder Zustand w wird mittels einer Menge label(w) markiert, zu 

der alle Teilformeln hinzugefügt werden, die in w erfüllt sind. Anfangs gilt: label(w) = 

η(w). Der Algorithmus läuft mehrere Stufen durch. Die Anzahl der Stufen entspricht dem 

Verschachtelungsgrad 1 (Anzahl der vorkommenden Operatoren) der Formel ϕ. In der i-en 

Stufe sind Teilformeln des Verschachtelungsgrades i-1 bereits abgearbeitet. Nachdem eine 

Teilformel γ behandelt wurde, wird sie zu der Menge label(w) von denjenigen Zuständen 

w hinzugefügt, in denen γ wahr ist. Sobald der Algorithmus terminiert, gilt K, w0 ⊧ ϕ, 

falls ϕ ∈ label(w0). 

In Abschnitt 2.3 wurde beschrieben, dass jede CTL-Formel durch atomare Aussagen 

und die Operatoren ¬, ∨, EX, EU und EG konstruiert werden kann. Deswegen müssen 

in jeder Stufe sechs Fälle behandelt werden. Seien φ eine CTL-Formel und w ein Zustand, 

die auf der i-en Stufe betrachtet werden. 

1 Verschachtelungsgrad ist 0, falls f ∈AP 

15


1. φ ∈ AP: φ wird akzeptiert, falls φ ∈ label(w). 

In diesem Fall wird keine Markierung vorgenommen, da label(w) mit η(w) initialisiert 

wird; 

2. φ = ¬γ: markiert werden die Zustände, die mit γ nicht markiert sind. 

∀v ∈ W, γ ∉ label(v): label(v) = label(v) ∪ φ. 

3. φ = γ ∨ λ: betroffen sind diejenigen Zustände, die mit γ oder mit λ markiert sind. 

∀v, u ∈ W, γ ∈ label(v), λ ∈ label(u): label(v) = label(v)∪φ, label(u) = label(u)∪φ. 

4. φ = EXγ: markiert werden direkte Vorfahren der mit γ markierten Zustände. 

∀v, u ∈ W, γ ∈ label(v), (u, v) ∈ R: label(u) = label(u) ∪ φ 

5. φ = E(γUλ): markiert werden die Zustände, von denen aus ein Pfad existiert, 

der aus den mit γ markierten Zuständen besteht und mit dem mit λ markierten 

Zustand endet. Die Pfade werden rückwärts von den mit λ markierten Zuständen 

konstruiert. Dieser Fall wird in Algorithmus 1 behandelt. 

Algorithmus 1 Procedure CheckEU K, w0 ⊧ ϕ 

Eingabe: eine Kripke-Struktur K = (W, R, η), w0 ∈ W , ϕ = E(αUβ) 

1: T ← {s ∣ β ∈ label(s)} 

2: for all s ∈ T do 

3: label(s) ← label(s) ∪ {E(αUβ)} 

4: end for 

5: while T is not empty do 

6: choose s ∈ T 

7: T ← T /{s} 

8: for all t such that (t, s) ∈ R do 

9: if ϕ ∉ label(t) and α ∈ label(t) then 

10: label(t) ← label(t) ∪ {E(αUβ)} 

11: T ← T ∪ {t} 

12: end if 

13: end for 

14: end while 

6. φ = EGγ: hier werden diejenigen Zustände markiert, von denen aus ein Pfad 

existiert, entlang dessen nur die mit γ markierten Zustände vorkommen. Um solche 

Pfade zu finden, wird aus der Kripke-Struktur eine reduzierte Kripke-Struktur 

K ′ = (W ′ , R ′ , η ′ ) konstruiert, in die nur die mit γ markierten Zustände aus W und 

zugehörige Relationen aufgenommen werden. Formal: W ′ = {w ∈ W, γ ∈ label(w)}, 

R ′ = R∣W ′ ×W ′ und η′ = η∣W ′. K′ wird mit Hilfe des Algorithmus von Tarjan 

[AHU74] in nicht triviale Zusammenhangskomponenten zerlegt. Eine Zusammenhangskomponente 

(strong connected component) C ist ein maximaler Teilgraph, 

in dem jeder Knoten in C von jedem anderen Knoten aus C über einen gerichteten 

16


komplett in C verlaufenden Pfad erreichbar ist. C ist nicht trivial, falls sie entweder 

aus mehr als einem Knoten oder aus nur einem Knoten mit einer Selbstschleife 

besteht (C = {v ∈ W ′ }, (v, v) ∈ R ′ ). Nachdem K ′ partitioniert wurde, wird nach 

den Zuständen gesucht, die zu nicht trivialen Zusammenhangskomponenten gehören. 

Dabei wird rückwärts über R ′ abgearbeitet, und die erforderlichen Zustände 

werden markiert. Diesen Fall stellt Algorithmus 2 dar. 

Algorithmus 2 Procedure CheckEG K, w0 ⊧ ϕ 

Eingabe: eine Kripke-Struktur K = (W, R, η), w0 ∈ W , ϕ = EGα 

1: S ′ ← {s ∣ α ∈ label(s)} 

2: SCC ← {C ∣ C is a nontrivial SCC of S ′ } 

3: T ← ⋃C∈SCC{s ∣ s ∈ C} 

4: for all s ∈ T do 

5: label(s) ← label(s) ∪ {EGα} 

6: end for 

7: while T is not empty do 

8: choose s ∈ T 

9: T ← T /{s} 

10: for all t such that t ∈ S ′ and (t, s) ∈ R do 

11: if ϕ ∉ label(t) then 

12: label(t) ← label(t) ∪ {EGα} 

13: T ← T ∪ {t} 

14: end if 

15: end for 

16: end while 

Das Abarbeiten jeder der Teilformeln von ϕ benötigt O(∣W ∣ + ∣R∣)-Zeit 2 . Die Komplexität 

des gesamten Algorithmus beträgt somit O(∣ϕ∣ ⋅ (∣W ∣ + ∣R∣)) (Polynomialzeit), 

wobei ∣ϕ∣ die Anzahl der verschiedenen Teilformeln von ϕ ist. 

3.3.2 CTLpos -MC(EX, EG, EU, ER) 

Es ist bemerkenswert, dass sich jede obere Grenze für CTL-MC(T ) auch auf 

CTLpos -MC(T ) (für alle T ) übertragen lässt. Dennoch lässt sich die Komplexität von 

CTLpos-MC(T ) verbessern, wenn in T nur bestimmte Operatoren verwendet werden (vgl. 

[BMT + 09]). Dies ist eine zentrale Idee bei der Untersuchung des CTLpos-Fragmentes. Außerdem 

steht im Hintergrund die Eigenschaft von LOGCFL-Sprachen, dass sie sich mit 

einer nichtdeterministischen Turing Maschine in Polynomialzeit entscheiden lassen, die 

ein Arbeitsband logarithmischer Größe und einen unendlichen Stack besitzt. In diesem 

2 Im ersten Fall wird O(∣W ∣ + ∣AP ∣)-Zeit beansprucht, aber es wird angenommen, dass das zu analysierende 

System in Bezug auf das Zusammenspiel zwischen den Komponenten(|R|) im Vergleich zu der 

Anzahl der Eigenschaften des Systems (|AP |) genügend komplex ist. Deswegen wird die Komplexität 

auf O(∣W ∣ + ∣R∣) verallgemeinert. 

17


Abschnitt wird aber ein in Exponentialzeit arbeitender Algorithmus CTLpos-MC(T ) vorgestellt, 

der dem in Abschnitt 3.3.1 aufgeführten Algorithmus CTL-MC(T ) in Bezug auf 

ihre Effizienz weiter unten gegenübergestellt wird. 

Satz 3.3.2 Sei T eine Menge von CTL-Operatoren, so dass alle Operatoren in T existenziell 

oder alle Operatoren in T universal sind. Dann ist CTLpos-MC(T) ∈ P. 

Als Erstes wird der Fall betrachtet, dass in T nur existenzielle Operatoren erhältlich 

sind. O. B. d. A. sei T ∈ {EX, EG, EU, ER}. Es wird behauptet, dass Algorithmus 3 

entscheidet, ob die Kripke-Struktur K = (W, R, η) die CTLpos(T )-Formel ϕ im Zustand 

w0 ∈ W erfüllt. S sei ein Stack zum Speichern von Paaren (ϕ, w) ∈ CTLpos(T ) × W . 

Jede Formel wird ähnlich wie im CTL-MC(ALL)-Algorithmus abgearbeitet. Sie wird 

je nach dem verwendeten Operator in die Teilformeln zerlegt und entsprechend behandelt. 

Ein deutlicher Unterschied liegt in dem Fall vor, wenn eine Pfad-Formel überprüft 

werden muss, z. B. ϕ = EGα oder ϕ = E(αUβ). Hier muss ein Pfad aus allen möglichen 

aus dem betrachteten Zustand ausgehenden Pfaden nichtdeterministisch gefunden werden. 

α wird dann in jedem Zustand entlang dieses Pfades geprüft. Im CTL-MC(ALL)- 

Algorithmus werden für solche Formeln erst die Zustände gefunden, in denen α erfüllt 

wird. Danach werden aus diesen Zuständen starke Zusammenhangskomponenten und 

aus diesen Ergebnispfade konstruiert. 

Die Konstruktion des Algorithmus macht die oben erwähnte Eigenschaft der LOGCFL- 

Sprachen erkennbar. Der Algorithmus lässt sich mit einer Turing Maschine mit einem 

Stack und einem Arbeitsband logarithmischer Größe entscheiden. Wenn der Algorithmus 

in Polynomialzeit arbeiten würde, dann könnte man das Problem 

CTLpos-MC(EX, EG, EU, ER) zu LOGCFL-Sprachen einordnen. Das ist aber für den 

Fall ϕ = EGα oder ϕ = E(αUβ) unmöglich. Das Problem liegt für die Formeln vor, die 

nach dem folgenden Schema geschachtelt sind. Sei ϕ = EGα0, wobei α0 eine Formel ist, 

die als Teilformel EGα1 enthält usw. Z. B. ϕ = EG(x0∨EG(x1∧EG(x2...))). Für jede 

Teilformel αi,i=0,... wird ein neuer Pfad geraten und jeweils |W|-mal auf den Stack gelegt. 

Analog gilt dies auch für die EU-Formeln. Dies führt zum exponentiellen Bedarf in der 

Stackgröße. Der Algorithmus benötigt exponentielle und nicht mehr polynomielle Zeit, 

wie es bei LOGCFL gefordert wird. ER-Formeln stellen eine Kombination von EG- und 

EU-Formeln dar. EX-Formeln können polynomiell mit der Turing Maschine abgearbeitet 

werden. Die übrigen Formeln repräsentieren Trivialfälle. Für die EG-, EU-Formeln 

besitzt der Algorithmus folgende Komplexität. Um alle Pfade abzuarbeiten, braucht 

man O(2 n ) Zeit. Bei geschickter Implementierung mit dem direkten Zugriff auf Teilformeln 

im Stack ergibt sich O(2 log(n) ) = O(n O(1) ) Bedarf. Folglich ist der Algorithmus für 

CTLpos-MC(EX, EG, EU, ER) theoretisch polynomiell. 

Die Tatsache, dass der Algorithmus immer terminiert, folgt daraus, dass jede Teilformel 

von ϕ nicht mehr als |W |-mal im Stack S gespeichert wird. Außerdem zeigt die 

Induktivität der Struktur von Formeln, dass der Algorithmus genau dann false zurückgibt, 

wenn für alle aus dem Stack S geladenen Paare (φ, w) K, w ⊭ φ gilt. Folglich 

terminiert der Algorithmus mit true, genau dann wenn K, w ⊧ ϕ. 

18

Algorithmus 3 Entscheide, ob K, w ⊧ ϕ 

Eingabe: eine Kripke-Struktur K = (W, R, η), w0 ∈ W , ϕ ∈ CTLpos (T) 

Ausgabe: true (falls K, w ⊧ ϕ) oder false (sonst) 

1: push(S, (ϕ, w0)) 

2: while S is not empty do 

3: (ϕ, w) ← pop(S) 

4: if ϕ is a propositional formula then 

5: if ϕ evaluates to false in w under η then 

6: return false 

7: end if 

8: else if ϕ = α ∧ β then 

9: push(S, (β, w)) 

10: push(S, (α, w)) 

11: else if ϕ = α ∨ β then 

12: nondet. push(S, (α, w)) or push(S, (β, w)) 

13: else if ϕ = EXα then 

14: nondet. choose w ′ ∈ {w ′ ∣ (w, w ′ ) ∈ R} 

15: push(S, (α, w ′ )) 

16: else if ϕ = EGα then 

17: guess a path (wi)1≤i≤∣W ∣ such that w1 = w 

18: for all 1 ≤ i ≤ ∣W ∣ do 

19: push(S, (α, wi)) 

20: end for 

21: else if ϕ = E(αUβ) then 

22: guess k ≤ ∣W ∣ and a path (wi)1≤i≤k such that w1 = w 

23: for all 1 ≤ i < k do 

24: push(S, (α, wi)) 

25: end for 

26: push(S, (β, wk)) 

27: else if ϕ = E (αRβ) then 

28: guess γ ∈ {EGβ, E(βU(α ∧ β))} 

29: push(S, (γ, w)) 

30: end if 

31: end while 

32: return true 

19 

3 Model-Checking für CTL


Bei der Implementierung dieses Algorithmus kollidiert man mit den Problemen, die 

sich durch den in den Zeilen 12, 14, 17, 22, 28 vorkommenden Nichtdeterminismus bekunden. 

Außerdem, um bessere Effizienz zu erreichen, müssen die Pfade in den Zeilen 

15, 19, 24 auf dem Stack knotenweise und nicht als Ganzes gespeichert und bearbeitet 

werden. Diese sowie weitere Besonderheiten bezüglich der Implementierung werden in 

Kapitel 4 besprochen. 

Der Fall, wenn alle Operatoren in T universal sind, folgt aus Abgeschlossenheit von P 

unter dem Komplement und kann analog gelöst werden (Eϕ ≡ ¬A¬ϕ). 

20

4 Design und Implementierung 

Im vorigen Kapitel wurden die Model-Checking-Algorithmen für CTL-MC(ALL) und 

CTLpos-MC(EX, EG, EU, ER) präsentiert. Diese werden im Rahmen dieser Diplomarbeit 

in Java implementiert. In diesem Kapitel werden Implementierungsaspekte erläutert. 

Dabei wird ein existierendes Programm um weitere Funktionalitäten erweitert. Dieses 

Programm wird in Abschnitt 4.1 vorgestellt. Die ausführliche Beschreibung findet man 

in [Sol09]. Die geänderte Klassenstruktur und die neuen Möglichkeiten des Programms 

werden auch in diesem Kapitel veranschaulicht. 

4.1 Basisprogramm 

Als Basis wurde ein Programm verwendet, das im Rahmen einer anderen Diplomarbeit 

am Institut für theoretische Informatik der Leibniz Universität Hannover entstanden ist. 

Dieses Programm wurde mit dem Ziel entwickelt, einige Model-Checking-Algorithmen 

für LTL zu realisieren. Die Benutzeroberfläche des Hauptfensters ist in Abbildungen 4.1 

zu sehen. 

Das Hauptfenster besteht aus drei Bereichen, die sich auf Kripke-Struktur, Formel 

und Algorithmen beziehen. In jedem Bereich gibt es Buttons zum Aufrufen diverser 

Aufgaben und ein Textfeld, in dem eine Kripke-Struktur, eine Formel oder Ergebnisse der 

Algorithmen veranschaulicht werden. Folgende Funktionalitäten sind bereits vorhanden: 

• Erstellung einer neuen Kripke-Struktur bzw. einer neuen Formel; 

• Speicherung einer Kripke-Struktur bzw. einer Formel in einer Datei; 

• Laden einer Kripke-Struktur bzw. einer Formel aus einer Datei; 

• Zeichnen einer Kripke-Struktur; 

• Starten der Model-Checking-Algorithmen für LTL angewendet auf die erstellte/geladene 

Kripke-Struktur und die erstellte/geladene Formel. 

Die implementierte Datenstruktur, die eine Kripke-Struktur repräsentiert, und alle zugehörigen 

Funktionalitäten werden übernommen. Die Visualisierung der Kripke-Struktur 

wird überarbeitet und um einige Funktionen ergänzt. Da das Basisprogramm speziell 

für das Model-Checking für LTL entwickelt wurde, müssen die Operationen zur Bearbeitung 

der Formeln angepasst und erweitert werden, um CTL-Formeln zu erfassen, um die 

in dieser Arbeit auszuarbeitenden Model-Checking-Algorithmen verwenden zu können. 

Weiter unten werden diese und andere Erweiterungen des Basisprogramms erörtert. 

21


Abbildung 4.1: Das Hauptfenster des Basisprogramms (Bild aus [Sol09]) 

4.2 Neue Klassenstruktur und die 

Implementierungsaspekte 

In diesem Abschnitt wird die erweiterte Klassenstruktur des Programms erläutert. Abbildung 

4.2 stellt die Programmlogik dar, und Abbildung 4.3 zeigt die Klassenstruktur der 

Benutzerschnittstelle. Die für diese Arbeit relevanten Klassen des Basisprogramms werden 

ohne Attribute bzw. Operationen abgebildet. Die komplett übernommenen Klassen 

sind in schwarz und die erweiterten Klassen sind in grün dargestellt. Die neuen Klassen 

sind in blau hervorgehoben. Die get- und set-Methoden werden übersichtshalber nicht 

dargestellt. 

22

#not: boolean 

#and: boolean 

#or: boolean 

#EX: boolean 

#EG: boolean 

#EU: boolean 

#ER: boolean 

FormulaCTLpos 

+isProposition(): boolean 

+stringToFormula(String): FormulaCTLpos 

+stringInPrefixToFormula(String): FormulaCTLpos 

+formulaToString(): String 

+formulaToStringInPrefix(): String 

#getIndexOfMainOperator(String): int 

-modifyAccordingDeMorgan() 

-getToken(String): String 

ModelCheckingCTLpos 

-formulaCTLpos: FormulaCTLpos 

-kripke: Kripke 

-state: State 

-paths: ArrayList 

-result: boolean 

+modelCheckingCTLposArrayList(Kripke,FormulaCTLpos, 

State): boolean 

+modelCheckingCTLposTree(Kripke,FormulaCTLpos, 

State): boolean 

State 

-key: int 

-name: String 

-initial: boolean 

-propositions: String[] 

-transitions: ArrayList 

-computaionTree : TreeNode 

-paths: ArrayList 

-index: int 

-lowLink: int 

...() 

+evaluatePropositionalFormula(FormulaCTLPos): booelan 

+getPredecessorStates(Kripke): HashMap 

+getSuccStates(Kripke): int[] 

+formPaths(int,Kripke) 

+createComputationTree(Kripke): TreeNode 

0..1 

TreeNode 

-value: T 

-parent: TreeNode 

-leftChild: TreeNode 

-rightSibling: TreeNode 

-depth: int 

0..2 

+addChild(T): TreeNode 

+addRightSibling(T): TreeNode 

+getChildren(): ArrayList 

Proposition 

1..* 

2 

0..1 

1..* 

1 

-EF: boolean 

-AF: boolean 

-AX: boolean 

-AG: boolean 

-AU: boolean 

-AR: boolean 


0..2 

FormulaCTL 

+isProposition(): boolean 

+stringToFormula(String): FormulaCTL 

+stringInPrefixToFormula(String): FormulaCTL 

+formulaToString(): String 

+formulaToStringInPrefix(): String 

+convert() 

-getToken(String) 

ModelCheckingCTL 

-formulaCTL: FormulaCTL 


-labeledStates: HashMap 

+modelCheckingCTL(FormulaCTL): HashMap 

-checkPropositions(Proposition): HashMap 

-checkNot(HashMap): HashMap 

-checkOr(HashMap,HashMap): HashMap 

-checkEX(HashMap): HashMap 

-checkEU(HashMap,HashMap): HashMap 

-checkEG(HashMap): HashMap 

-getSCC(HashMap): ArrayList 

Kripke 

-... 

-allTransVector: ArrayList 

...() 

+edit() 

+createRandomKripke(int,int,int) 

-getRandomPropositions(int): String[] 

1 

Transition 

Abbildung 4.2: Klassendiagramm für Programmlogik 

23

State 

FormulaCTLpos 

ModelCheckingCTLpos 

SettingsFrame 

-formulaFile: File 

-kripkeFile: File 

+loadProperties() 

+saveProperties() 

Kripke-Struktur 

FormulaCTL 

ModelCheckerCTL 

-formulaCTL: FormulaCTL 

-formulaCTLpos: FormulaCTLpos 


-result: boolean 

-selectedStates: ArrayList 

+labelTrueStatesInGraph() 

-getStatesList(): ArrayList 

-setClickedStatesInGraph(ArrayList) 

Kripke 

Formula 

ModelChecker 

ModelCheck 


ModelCheckingCTL 

Abbildung 4.3: Klassendiagramm der Benutzerschnittstelle 

GraphVisualization 

+draw(Kripke) 

+saveImage(Kripke) 

Die Klasse Kripke stellt eine Kripke-Struktur als eine Liste von Zuständen dar, die 

mittels der Klasse State realisiert werden. Jeder Zustand hat eine eindeutige Identifikationsnummer, 

einen Namen und eine Liste der atomaren Aussagen, die in diesem 

Zustand gelten. Das Attribut initial gibt an, ob ein Zustand der Startzustand in der 

Kripke-Struktur ist. Übergänge zwischen den Zuständen in der Kripke-Struktur werden 

mittels der Klasse Transition gespeichert. Neben den übernommenen Funktionalitäten, 

die Kripke-Struktur zu erstellen/speichern/laden, kann sie jetzt auch geändert werden 

(edit()). Außerdem wird ermöglicht, eine zufällige Kripke-Struktur generieren zu lassen 

(createRandomKripke(int, int, int)). Als Argumente werden die Anzahl von Zuständen 

S, die Anzahl von Übergängen T , die aus jedem Zustand ausgehen, sowie die maximale 

Anzahl von atomaren Aussagen P , die jedem Zustand zugeordnet werden. Die Generierung 

geschieht folgendermaßen. 

1. Es wird eine Menge der Größe S von Zuständen erzeugt. Als Namen werden die 

natürliche Zahlen vergeben. 

2. Jedem Zustand werden Übergänge hinzugefügt. Die Anzahl der Übergänge T ist 

für jeden Zustand fest. Die Endzustände von Übergängen werden mittels einer 

Zufallsfunktion ermittelt. 

24


3. Jeder Zustand wird mit einer Menge von atomaren Aussagen beschriftet. Diese 

werden auch zufällig mittels getRandomPropositions(int) generiert. Als atomare 

Aussagen werden hier die Buchstaben des lateinischen Alphabets verwendet. Das 

heißt, dass jeder Zustand maximal 26 atomare Aussagen haben kann. Für jeden 

Buchstaben wird eine Zufallszahl generiert. Wenn diese Zahl größer als 0,5 ist, 

wird dieser Buchstabe dem aktuellen Zustand zugeordnet. Der letzte mögliche 

Buchstabe entspricht dem übergebenen Parameter P . Mit anderen Worten: jeder 

Zustand wird mit keinen oder mit maximal S ersten Buchstaben des lateinischen 

Alphabets beschriftet. 

Die Klasse State wurde um die Attribute index und lowLink erweitert, die den Aufbau 

von den für Algorithmus 2 notwendigen Zusammenhangskomponenten ermöglichen. Eine 

weitere relevante Methode getPredecessorStates(Kripke), die zu einem Zustand sämtliche 

direkten Vorfahren findet, wird auch in dieser Klasse implementiert. Mittels der Methode 

evaluatePropositionalFormula(FormulaCTLpos) wird überprüft, ob eine CTLpos-Formel, 

in der keine CTL-Operatoren, sondern nur die booleschen Operatoren {¬, ∧, ∨} vorhanden 

sind, in dem aktuellen Zustand erfüllt wird. 

Algorithmus 3 benötigt bei der Analyse von EG-, EU-Formeln aus einem Zustand 

ausgehende Pfade. Diese können mittels der vom Basisprogramm übernommenen Methoden 

getSuccStates(Kripke) und formPaths(int, Kripke) ermittelt werden. formPaths(...) 

konstruiert solche Pfade. Jeder Pfad ist eine Liste von Zuständen. Alle aus einem Zustand 

ausgehenden Pfade werden als eine Liste von solchen Listen gespeichert. In Abschnitt 

3.3.2 wurde erwähnt, dass man eine bessere Effizienz erreichen kann, wenn Zustände auf 

den Pfaden knotenweise gespeichert werden. Um dies zu ermöglichen, wurde die Klasse 

TreeNode entwickelt, die einen Baum als Datenstruktur realisiert und alle nötigen 

Methoden bereitstellt. Jeder Zustand ist ein Knoten im Baum. Die von ihm erreichbaren 

Zustände sind seine Kinderknoten usw. Die Methode createComputationTree(Kripke) 

erzeugt einen Berechnungsbaum, in dem alle ausgehenden Pfade durch Tiefendurchlauf 

rekonstruiert werden können. In der Instanzvariable computaionTree wird der Wurzelknoten 

des Berechnungsbaumes gepeichert. Algorithmus 3 wird zweimal implementiert, 

um die beiden Möglichkeiten zu vergleichen, Pfade als Liste von Listen und als einen 

Baum abzuarbeiten. 

CTL-Formel 

CTL-Formeln werden im Hinblick auf Definition 2.3.1 mit Hilfe der Klassen Proposition, 

FormulaCTLpos und FormulaCTL implementiert. Jede CTL-Formel ist eine Instanz 

der Klasse FormulaCTLpos bzw. FormulaCTL und besteht aus CTL-Teilformeln, die 

in einer Liste gespeichert werden. Der verwendete Operator wird registriert, indem das 

entsprechende Attribut der Klasse FormulaCTLpos bzw. FormulaCTL auf ” wahr“ 

gesetzt wird. Dabei gelten die üblichen Prioritätsregeln, und alle binären Operatoren 

sind linksassoziativ. Jede Formel mit einem binären Operator (z. B. OR, AND, EU, 

AR) wird somit als eine Liste mit zwei Elementen und jede Formel mit einem unären 

Operator (z. B. NOT, EX, AG) mit einem Element dargestellt. 

25


Die einfachste Form einer CTL-Formel ist eine atomare Aussage. Solche Formel wird 

als eine Liste mit einem Element, einer Instanz der Klasse Proposition, erzeugt. Alle 

Attribute werden in diesem Fall mit ” falsch“ initialisiert. Formeln dieser Art können mit 

Hilfe der Methode isProposition() identifiziert werden. 

Jede FormulaCTLpos- oder FormulaCTL-Formel besteht folglich entweder aus 

einem Objekt der Klasse Proposition oder aus einer Liste mit einem oder zwei Objekten 

der Klasse FormulaCTLpos bzw. FormulaCTL. 

Durch die Klasse FormulaCTLpos können CTLpos-Formeln erzeugt werden, in denen 

CTL-Operatoren nicht negiert werden dürfen. Außerdem ist die Menge der CTL- 

Operatoren auf die Menge {EX, EG, EU, ER} eingeschränkt, da nur diese für den Algorithmus 

3 benötigt werden. Die Klasse FormulaCTL enthält sowohl die von 

FormulaCTLpos geerbten Attribute als auch weitere Attribute, die es zusammen 

ermöglichen, beliebige CTL-Formeln zu bilden. Die Formeln können über eine Benutzerschnittstelle 

in textueller Form in der Infix- oder Präfix-Notation eingegeben werden. 

Das Erstellen der Formeln aus dem Eingabetext geschieht mittels der Methoden 

StringToFormula(String) und StringInPrefixToFormula(String). Dies erfolgt, indem die 

Eingabe analysiert wird und ein Operator der Formel mittels der 

getIndexOfMainOperator(String) und getToken(String) gefunden wird. Folglich werden 

die Teilformeln der Formel ermittelt, die weiterhin analog in ” die Tiefe“ geparst werden. 

Die Konvertierung in die andere Richtung passiert mittels FormulaToString() bzw. 

FormulaToStringInPrefix(). 

Die Methode modifyAccordingDeMorgan() bringt eine CTLpos -Formel nach den De 

Morganschen Gesetzen in so eine Form, dass die Negationen nur direkt von den atomaren 

Aussagen stehen. Diese Umwandlung vereinfacht die Auswertung der Formel in 

Algorithmus 3: K, w0 ⊧ ¬p, wenn p ∈ AP und p ∉ η(w0). Dies ermöglicht die Methode 

evaluatePropositionalFormula(FormulaCTLpos) in der Klasse State. 

Die Methode convert() in der Klasse FormulaCTL wandelt eine CTL-Formel in eine 

äquivalente um, die aus atomaren Aussagen und den Operatoren ¬, ∨, EX, EU und 

EG besteht. Diese Methode ist für CTL-MC(ALL) von großer Bedeutung, da diese Operatoren 

eine minimale Menge der Operatoren bilden, um alle möglichen CTL-Formeln 

konstruieren zu können. Die Konvertierung erfolgt mittels der in der Tabelle 2.3 aufgeführten 

Regeln. 

Algorithmen 

Die Klassen ModelCheckingCTLpos und ModelCheckingCTL bilden den Kern des 

Programms. Sie enthalten nämlich die Model-Checking-Algorithmen CTLpos -MC(EX, 

EG, EU, ER) bzw. CTL-MC(ALL). 

Um den CTLpos-Algorithmus ausführen zu können, müssen eine Kripke-Struktur, ein 

Zustand in der Kripke-Struktur und eine zu prüfende CTLpos-Formel bekannt sein. Diese 

Argumente werden in den entsprechenden Instanzvariablen gespeichert. Die Methoden 

modelCheckingCTLposArrayList(Kripke, FormulaCTLpos, State) und modelChecking- 

CTLposTree(Kripke, FormulaCTLpos, State) stellen die zwei oben vorgestellten Implementierungsmöglichkeiten 

des Algorithmus 3 dar. Die Ergebnisse des Model-Checkings 

26


werden in den Variablen result und paths gespeichert. result wird auf ” wahr“ gesetzt, 

falls die Kripke-Struktur kripke die Formel formulaCTLpos im Zustand state erfüllt. In 

Abhängigkeit davon, ob es um eine Zustands- oder Pfad-Formel handelt, werden in paths 

Zustände bzw. Pfade verfasst, in denen die Erfüllbarkeit vorliegt. 

In Abschnitt 3.3.2 wurden die Implementierungsschwierigkeiten des Algorithmus 3 

erwähnt. Hier liegt das Problem vor, dass man nichtdeterministisch mehrere Teilformeln 

oder Zustände abarbeiten ( ” nondet. choose“) oder aus mehreren einen Pfad oder 

einen Zustand aussuchen ( ” guess“) muss, in denen eine bestimmte Eigenschaft – d. h. 

eine Formel – erfüllt wird. Dieser Nichtdeterminismus wird durch die Überprüfung jeder 

Teilformel, jedes Zustandes und jedes Pfades der Reihe nach ersetzt, die in Frage 

kommen. Da es sich um die existentiellen Formeln handelt, kann man die Abarbeitung 

abbrechen, sobald eine Forderung (ein Zustand für die EX- oder ein Pfad für die EGbzw. 

EU-Formeln) erfüllt wurde. Im schlimmsten Fall müssen aber alle Kandidaten 

überprüft werden. 

Betrachten wir den Fall ϕ = EGα. Wenn man alle aus einem Zustand w0 ausgehenden 

Pfade betrachtet, hat man die exponentielle Anzahl von Möglichkeiten: ∣T ∣ ∣T ∣ , wobei 

∣T ∣ die Anzahl aus einem Zustand ausgehender Übergänge ist. Die Laufzeit der Abarbeitung 

der Pfade ist entsprechend groß. Wenn die Pfade als ArrayList 

gespeichert sind, wird jeder Pfad vom ersten bis zum letzten Zustand auf die Erfüllbarkeit 

der Formel α geprüft. Die Situation ändert sich, wenn die Pfade in einem Baum 

gefasst sind. Abbildung 4.4 zeigt diese zwei Abarbeitunsmöglichkeiten. Oben ist eine 

Kripke-Struktur dargestellt. Die Zustände sind mit den atomaren Aussagen versehen. 

Sei ϕ = EGa. Unten links ist die Liste mit den Pfaden, rechts davon ist der entsprechende 

Berechnungsbaum. Die Pfade sowie der Berechnugsbaum sind unendlich, werden 

aber auf die Anzahl von Zuständen in der Kripke beschränkt, da die Pfade sonst einen 

Zyklus enthalten. Der gestrichelte Pfeil zeigt die Reihenfolge, in der die Zustände überprüft 

werden, ob die Formel α = a in diesen gilt. Bei der zweiten Implementierung wird 

nach einem ” falschen“ Zustand, in dem die Teilformel α nicht gilt, zu seinem rechten 

Geschwister übergegangen. Das wird solange durchgeführt, bis es noch solche vorhanden 

sind und noch kein Pfad gefunden wurde. Dies wird mittels des iterativen Tiefendurchlaufs 

(siehe [AUH82]) realisiert, bei dem zu jedem Knoten seine rechten Geschwister in 

einem Stack gespeichert werden. Im Gegensatz zu der ersten Implementierung wird somit 

die Überprüfung in allen vorherigen Zuständen gespart. Eine weitere Möglichkeit an 

der Laufzeit zu gewinnen, ist die Speicherung von Ergebnissen des Model-Checkings in 

den geprüften Zuständen. Das bedeutet, dass nachdem die Zustände ” a“, ” a,b“ und ” b“ 

geprüft wurden, wird für die Formel α = a gespeichert, dass sie in den Zuständen ” a“ 

und ” a,b“ erfüllt wird. Wenn der zweite Pfad im Baum analysiert wird, muss der Model- 

Checking-Algorithmus im nächsten potenziellen Zustand nicht mehr ausgeführt werden. 

Die schon ermittelten Ergebnisse müssen nur gelesen werden. Dieser Ansatz beansprucht 

einen zusätzlichen Speicher, vermindert aber die Laufzeit. 

Weiterhin setzt der Algorithmus einen Stack ein. Um den Nichtdeterminismus zu lösen, 

müssen alle möglichen Zustände bzw. Pfade sowie entsprechende Formeln im Stack 

gespeichert werden. Zusätzlich muss der Typ der Formeln bei der Speicherung ihrer Teilformeln 

mit angegeben werden, was jedoch für die Formeln ohne temporale Operatoren 

27

a 

a 

a,b a,b 

a 

a 

b a,b 

Kripke-Struktur 

a 

b a 

a,b a 

b 

a a,b 

ArrayList) hat als Argument eine Menge von Zuständen, 

die mit der Teilformel markiert wurden und selektiert diejenigen Zustände 

der Kripke-Struktur, die nicht in der Menge sind. 

28 

a 

a


• checkOr(HashMap < Number, State >, HashMap < Number, State >) gibt eine Vereinigung 

der beiden Argumente zurück. 

• checkEX (HashMap < Number, State >) markiert alle direkten Vorfahren von den in 

der Argument-Menge enthaltenen Zuständen. Diese werden mit Hilfe der Methode 

getPredecessorStates(Kripke) der Klasse State gefunden. 

• checkEU (HashMap < Number, State >, HashMap < Number, State >) hat als Argumente 

zwei Mengen der Zustände, in denen die erste bzw. die zweite Teilformel 

gilt und implementiert den Algorithmus 1. 

• checkEG(HashMap < Number, State >) realisiert den Algorithmus 2. Als Erstes 

müssen hier alle nicht trivialen Zusammenhangskomponenten von den Zuständen 

aus der Argument-Menge gefunden werden. Dies erfolgt mittels der Methode 

getSCC (HashMap < Number, State >). 

Parallel zur Implementierung werden die entwickelten Datenstrukturen und Algorithmen 

mit Hilfe von JUnit ständig getestet. 

Benutzerschnittstelle 

Im Basisprogramm wird eine Benutzerschnittstelle über die Klasse ModelChecker realisiert, 

die das Hauptfenster des Programms darstellt. Auf dieses werden neue Bedien- 

Elemente hinzugefügt, um die neuen Funktionalitäten ansprechen zu können. Außerdem 

wird das Fenster benutzerfreundlicher gestaltet, indem ein anderes Swing-Layout, nämlich 

das GridBag-Layout, verwendet wird. Alle geänderten bzw. neuen Benutzeroberflächen 

werden in Abschnitt 4.3 veranschaulicht. 

Die neue Klasse SettingsFrame verwaltet die Benutzereinstellungen. Hierbei kann 

man jeweils eine Datei mit einer Kripke-Struktur und einer Formel angeben, die bei 

jedem Start des Programms geladen werden. 

Im Basisprogramm gab es die Möglichkeit, die Kripke-Struktur mit Hilfe des Frameworks 

JUNG 1 in Form eines Graphen zeichnen zu lassen. Die Möglichkeit wird beibehalten, 

wird aber mit einer neueren Version (2.0) des Frameworks umgesetzt und um 

die neuen Funktionalitäten wie die Skalierung des Graphen und die Verschiebung der 

Knoten erweitert. Für diese Funktionalität ist die Methode draw(Kripke) in der Klasse 

GraphVisualization verantwortlich. Außerdem werden zu den Knoten entsprechende 

atomare Aussagen angezeigt. Die Speicherung des Graphen (saveImage(Kripke)) wird 

beibehalten, als Format wird aber PNG statt JPEG benutzt, um die JPEG-Artifakte zu 

vermeiden. 

Die Klasse ModelCheckerCTL stellt die notwendigen Bedienelemente zum Vorbereiten 

der zu analysierenden Daten und zum Ausführen der beiden Model-Checking- 

Algorithmen CTL-MC(ALL) und CTLpos-MC(EX, EG, EU, ER) bereit. Die eingegebene 

Formel wird in den Instanzvariablen formulaCTL und formulaCTLpos gespeichert, falls 

sie den Einschränkungen von CTLpos genügt. Die Kripke-Struktur kripke wird hier auch 

1 http://jung.sourceforge.net/ 

29


visualisiert, und es besteht die Möglichkeit, die Zustände im Graphen oder in einer Liste 

auszuwählen. Diese werden in selectedStates gespeichert. In diesen Zuständen wird die 

Formel mittels der Algorithmen überprüft. Nach dem Ablauf der Algorithmen wird das 

Ergebnis result ” wahr“, falls die überprüfte Formel in mindestens einem Zustand erfüllt 

wird. Die Zustände werden im Graphen mit Hilfe von labelTrueStatesInGraph() farblich 

hervorgehoben. 

4.3 Bedienungsanleitung zum Programm 

In diesem Abschnitt wird eine kurze Anleitung zur Verfügung gestellt, wie das neue 

Programm bedient werden kann. Anhand eines Beispiels wird die graphische Benutzeroberfläche 

des Programms veranschaulicht. Dabei werden die geänderten und die 

neuen Bestandteile akzentuiert. Die vom Basisprogramm übernommenen Komponenten 

wurden in Abschnitt 4.1 vorgestellt. 

Das geänderte Hauptfenster wird in Abbildung 4.5 dargestellt. 

Abbildung 4.5: Das geänderte Hauptfenster des Programms 

Die Grundstruktur des Programms wurde in Abschnitt 4.1 beschrieben. Es hat sich 

das Layout geändert. Die drei Bereiche für Kripke-Struktur, Formel und Algorithmen 

wurden durch die Rahmen hervorgehoben. Der Einheitlichkeit halber haben alle Buttons 

die gleiche Größe und einen gleichmäßigen Abstand zueinander erhalten. 

30


Die Einstellungen des Programms sind über das Menü Datei→Einstellungen abrufbar. 

In Abbildung 4.6 ist veranschaulicht, dass man die Kripke-Struktur- und Formelenthaltenen 

Dateien auswählen kann, die beim Starten des Programms automatisch geladen 

werden. Diese Funktionalität kann nützlich sein, wenn man z. B. diverse Formeln 

auf einer bestimmten Kripke-Struktur öfters prüfen will oder umgekehrt. Nach dem Betätigen 

des OK-Buttons werden die Datei-Namen, falls sie selektiert wurden, in einer 

INI-Datei gespeichert und beim nächsten Start des Programms geladen. Die INI-Datei 

befindet sich im selben Verzeichnis wie das Programm oder wird erzeugt. 

Mittels des Buttons Kripke-Struktur generieren wird ein neuer Dialog geöffnet, in 

dem die Anzahl von Zuständen, Übergängen und atomaren Aussagen eingegeben werden 

kann. Mit diesen Parametern wird eine zufällige Kripke-Struktur erzeugt. 

Abbildung 4.7 zeigt die neue Graph-Visualisierung einer Kripke-Struktur, die sich 

über den Button Kripke-Struktur zeichnen im Hauptfenster erscheinen lässt. Jeder 

Zustand wird mit seinem Namen sowie mit den atomaren Aussagen beschriftet, die in 

diesem Zustand gelten. Es besteht die Möglichkeit, den Kripke-Graphen zu manipulieren. 

Durch ” Drag and Drop“ können einzelne sowie mehrere ausgewählte Knoten verschoben 

werden. Selektion der Knoten erfolgt durch das An- bzw. Abwählen der Knoten mit dem 

linken Mausklick oder durch das Ziehen eines Rechtecks über die interessierenden Zustände. 

Mehrfachauswahl geschieht, wenn dazu gleichzeitig eine SHIFT-Taste gedrückt 

wird. Skalierung erfolgt mit Hilfe vom Scrollrad. Diese Funktionalitäten sind behilflich, 

wenn man mit einer komplexen Kripke-Struktur arbeitet, deren automatische Visualisierung 

unübersichtlich vorkommen kann. Die Speicherung des Bildes erfolgt wie im 

Basisprogramm über das Menü Datei→Bild speichern. 

Abbildung 4.6: Das Fenster mit den Einstellungen des Programms 

31


Abbildung 4.7: Graphische Darstellung einer Kripke-Struktur 

Bei der Erstellung einer neuen CTL-Formel ist Folgendes zu beachten. Die temporalen 

Operatoren müssen groß und ohne Leerzeichen geschrieben werden (z. B. EX für EX 

usw.). Eine AU-Formel muss in der Form A(α U β) eingegeben werden. Die gleiche Regel 

gilt auch für die AR-, EU- und ER-Formeln. Die booleschen Operatoren ¬, ∧ und ∨ 

sind als ” ∼“, ” AND“ bzw. ” OR“ einzugeben. Alle übrigen Zeichenketten werden als atomare 

Aussagen interpretiert. Wenn man mit LTL-Formeln arbeitet, sind die dazu spezifischen 

Eingaberegeln zu berücksichtigen, die in [Sol09] aufgeführt sind. Allerdings findet 

die Eingabe sämtlicher Formeln im selben Fenster statt, das durch das Betätigen des 

Buttons neue Formel erstellen abrufbar ist. Danach wird intern entschieden, ob die 

eingegebene Formel die CTL-, insbesondere CTLpos- und/oder LTL-Kriterien erfüllt. Auf 

LTL-Formeln sind die Algorithmen anwendbar, die durch die Buttons ModelCheckV 

und ModelCheckL aus dem Basisprogramm ausgelöst werden können. Für CTL- und 

CTLpos-Formeln ist ein neu hinzugekommener Button ModelCheckCTL vorgesehen. 

Folglich wird Benutzer beim Versuch, einen unzulässigen Algorithmus auszuführen, entsprechend 

benachrichtigt. 

Im Formel-Bereich sind zwei Textfelder zu sehen. Im ersten wird die eingegebene bzw. 

geladene Formel angezeigt. Wenn eine CTL-Formel vorliegt, wird sie im zweiten Textfeld 

in der konvertierten Form dargestellt, in der nur die Operatoren aus der minimalen 

Menge {¬, ∨, EX, EU, EG} vorkommen. 

32


Das Anklicken des ModelCheckCTL-Buttons löst das Öffnen eines neuen Fensters 

aus, in dem das Model-Checking für CTL und insbesondere für CTLpos gesteuert werden 

kann. Abbildung 4.8 repräsentiert dieses Fenster. 

Abbildung 4.8: Model-Checking-Fenster für CTL vor dem Ausführen des CTL- 

MC(ALL)-Algorithmus 

Hier wird die Kripke-Struktur graphisch dargestellt und kann wie im oben erläuterten 

Visualisierungsfenster manipuliert werden. Außerdem werden alle ihre Zustände in einer 

Liste aufgezählt. Dies dient dazu, die zu prüfenden Zustände bequem auszuwählen. In 

der Liste werden sie mit dem linken Mausklick selektiert und mit einem wiederholten 

deselektiert. Wenn die Liste den Fokus besitzt, können alle Zustände durch die Tastenkombination 

STRG+A hervorgehoben werden. In Graph-Darstellung werden Zustände 

mit einem Doppelklick und bei Mehrfachauswahl mit gedrückter SHIFT-Taste selektiert. 

Beim (De-)Selektieren der Zustände in der Liste werden diese auch im Graphen farblich 

hervorgehoben und umgekehrt. 

Unter der Liste sind zwei Buttons für die CTLpos-MC(EX, EG, EU, ER)- und CTL- 

MC(ALL)-Algorithmen zu sehen. Wenn im Hauptfenster eine CTL-Formel erstellt/geladen 

wurde, die den CTLpos -Einschränkungen nicht genügt, wird der Button Model- 

CheckingCTLpos nicht aktiv sein. 

33


Um den CTLpos-Algorithmus starten zu können, muss man mindestens einen zu prüfenden 

Zustand auswählen. Für CTL-MC(ALL)-Algorithmus wird das nicht verlangt. 

Wenn kein Zustand ausgewählt und der Button ModelCheckingCTLall betätigt wurden, 

wird das Programm es so interpretieren, dass der Algorithmus die Formel überprüft 

und als Ergebnis alle Zustände aufzählt, in denen die Formel zu ” wahr“ evaluiert. Dieses 

unterschiedliche Verhalten liegt an der Besonderheiten der Funktionsweise von Algorithmen. 

Wenn die Algorithmen ausgeführt sind, werden Ergebnisse im Ergebnisfeld ausgegeben. 

Außerdem werden die untersuchten Zustände im Graphen grün oder rot markiert, 

um die Zustände zu betonen, in denen die Formel erfüllt bzw. nicht erfüllt wird. Das 

wird in Abbildung 4.9 veranschaulicht. 

Abbildung 4.9: Model-Checking-Fenster für CTL nach dem Ausführen des CTL- 

MC(ALL)-Algorithmus 

Der CTLpos -Algorithmus liefert nicht nur eine positive und/oder negative Antwort 

zu jedem Zustand, sondern auch Zustände für Zustand-Formeln oder Pfade für Pfad- 

Formeln, in denen sie erfüllt werden. Die Abbildungen 4.10 und 4.11 repräsentieren diese 

zwei Fälle. In der ersten Zeile in Abbildung 4.11 ist das Ergebnis des CTL-MC(ALL)- 

Algorithmus zu sehen, der vor dem CTLpos-Algorithmus ausgeführt wurde. 

34


Das Ändern der zu analysierenden Daten findet im Hauptfenster des Programms statt, 

in das man durch Schließen des CTL-Model-Checking-Fensters zurückkehrt. 

Abbildung 4.10: Model-Checking-Fenster für CTL nach dem Ausführen des CTLpos - 

MC(EX, EG, EU, ER)-Algorithmus für eine EX-Formel 

Abbildung 4.11: Model-Checking-Fenster für CTL nach dem Ausführen des CTLpos - 

MC(EX, EG, EU, ER)-Algorithmus für eine EG-Formel 

35

5 Auswertung von Algorithmen 

Ziel dieses Kapitels ist es, Laufzeit der vorgestellten Algorithmen anhand der Experimente 

zu analysieren und zu vergleichen. Nachdem das Testsystem, Ablauf der Experimente 

sowie verwendete Testdaten beschrieben werden, werden die Ergebnisse der Experimente 

mit bestimmten Laufzeiten vorgestellt. Die Experimente werden in drei Gruppen eingeteilt, 

die den folgenden Zielsetzungen entsprechen: 

• Auswertung der Laufzeiten von zwei Implementierungsarten des CTLpos-MC(EX, 

EG, EU, ER)-Algorithmus 1 : modelCheckingCTLposArrayList(...) und model- 

CheckingCTLposTree(...). 

• Vergleich der Laufzeiten von CTL-MC(ALL)-Algorithmus 2 und von der effizienteren 

Implementierung des CTLpos-Algorithmus angewendet auf die Formeln des 

Fragmentes CTLpos(EX, EG, EU, ER) und ” kleine“ Kripke-Strukturen. 

• Auswertung des CTL-Algorithmus für diverse Formeln und ” größere“ Kripke-Strukturen. 

5.1 Allgemeine Beschreibung der Experimente 

5.1.1 Testsystem 

Algorithmen werden auf dem folgenden System getestet: 

• CPU: Intel Core Duo T5500 1,66 GHz 

• RAM: 1 GB (DDR2 SDRAM) 

• Mainboard: ASUSTek Computer Inc. F3JC 

• OS: Microsoft Windows XP 

• Java: J2SE Version 1.6 

1 weiter als ” CTLpos-Algorithmus“ genannt 

2 weiter als ” CTL-Algorithmus“ genannt 

36

5.1.2 Testdaten 


Zum Testen der Algorithmen werden verschiedene Kripke-Strukturen und Formeln benötigt. 

Um allgemeine Auswertung zu ermöglichen, werden zufällig erzeugte Kripke- 

Strukturen verwendet. Das Prinzip der Generierung wurde in Abschnitt 4.2 erläutert, 

da diese Funktion (createRandomKripke(int, int, int)) zu den Funktionalitäten des Programms 

gehört. Für die Experimente werden die Kripke-Strukturen mit unterschiedlicher 

Anzahl von Zuständen, Übergängen aus jedem Zustand und atomaren Aussagen 

automatisch erzeugt. Alle diese Kennzahlen werden für jedes Experiment aufgezeichnet 

und mit den Ergebnissen aufgelistet. In den Experimenten, in denen der CTLpos 

-Algorithmus analysiert wird, werden ” kleine“ Kripke-Strukturen generiert, die aus bis zu 

9 Zuständen bestehen. Diese Grenze wurde experimentell herausgefunden und ist genügend, 

um festzustellen, ob sich die Vermutung bestätigen lässt, dass die Laufzeit des 

CTLpos-Algorithmus mit der Anzahl von Zuständen und Übergängen beim Untersuchen 

der Pfad-Formeln exponentiell wächst. Bei der Analyse des CTL-Algorithmus werden 

auch ” größere“ Kripke-Strukturen mit bis zu 300 Zuständen untersucht, da dieser Algorithmus 

in Polynomialzeit arbeitet. 

Die zu testenden Formeln werden nicht zufällig erzeugt, sondern explizit definiert. Das 

ist wichtig, um die Algorithmen in Abhängigkeit von der Art der Formel (Pfad- oder 

Zustand-Formel), vom verwendeten Operator und vom Verschachtelungsgrad der Formel 

beurteilen zu können. 

5.1.3 Ablauf 

Jedes Experiment basiert auf folgenden Schritten. 

1. Erzeuge eine Kripke-Struktur mit W Zuständen, T Übergängen und maximal P 

atomaren Aussagen in jedem Zustand. Je nach Experiment werden verschiedene 

Werte für W und T eingesetzt. Für alle Experimente wird P = 5 verwendet, da die 

Evaluierung einer aussagenlogischen Formel NC 1 -vollständig ist. Deswegen kann die 

Laufzeit der Algorithmen durch einen größeren Wert von P nicht beeinträchtigt 

werden. 

2. Wähle eine Formel ϕ aus den Testformeln (siehe Tabelle 5.1). 

3. Für jede Kripke-Struktur und jede Formel ϕ rufe CTLpos- und/oder CTL-Algorithmus 

in jedem Zustand auf. 

4. Messe die Laufzeit der Algorithmen. Dabei wird die Methode currentTimeMillis() 

aus der Standardklasse java.lang.System benutzt, die die Laufzeit in Millisekunden 

misst. 

5. Speichere Ergebnisse: charakteristische Kennzahlen der Testdaten W , T , P , die 

analysierte Formel ϕ sowie die Laufzeiten von Algorithmen und die Anzahl der zu 

” wahr“ evaluierten Zustände. Diese werden in einer .csv-Datei gespeichert, um die 

Auswertung zu erleichtern. 

37


In manchen Experimenten werden Kripke-Strukturen mit bestimmten Vorgaben (W , T ) 

mehrmals erzeugt und auf dieselbe Formel angewendet. Das ermöglicht, Ergebnisse mit 

verschiedener Anzahl von ” wahr“-Zuständen und mit unterschiedlichen Laufzeiten für 

gleich-große Kripke-Strukturen zu beobachten. Die Kennzahlen von Testdaten sowie die 

Anzahl der Durchläufe, in denen solche Kripke-Strukturen erzeugt werden, werden für 

jedes Experiment tabellarisch aufgeführt. Die getesteten Formeln, die Anzahl der ” wahr“- 

Zustände sowie die Laufzeiten werden graphisch veranschaulicht. In allen folgenden Abbildungen 

stehen auf der Y-Achse Laufzeiten in Millisekunden. In den Abbildungen, in 

denen jeweils nur eine Formel dargestellt ist, sind auf der X-Achse drei Reihen von Werten 

zu sehen. Die untere bzw. die mittlere Reihe repräsentiert die Anzahl von Zuständen 

bzw. Übergängen von generierten Kripke-Strukturen. Die obere Reihe gibt die Anzahl 

von ” wahr“-Zuständen an. Diese entfällt für die Abbildungen, in denen mehrere Formeln 

erfasst sind. 

a AND b (EX a) OR (a AND b) 

EX a AX a 

EG b AG b 

E(c U d) A(c U d) 

E(c R d) A(c R d) 

EF c AF c 

EG(e AND EX a) AG(e AND AX a) 

EG(EG b) AG(AG b) 

∼AG(∼e AND AX a) EG (b OR ∼b) 

EX ∼a EX(a AND ∼a) 

Tabelle 5.1: Test-Formeln 

5.2 Zwei Implementierungen des CTLpos -Algorithmus 

In diesem Abschnitt werden zwei Implementierungen (ArrayList 

und TreeNode) des CTLpos-Algorithmus unter der Anwendung der Pfad-Formeln 

gegenübergestellt. Hier werden zwei Experimente durchgeführt. In Tabelle 5.2 sind die 

Testsparameter sowie die überprüften Formeln aufgelistet. Die Ergebnisse sind in Abbildungen 

5.1, 5.2, 5.3 und 5.4 zu sehen. 

Im ersten Experiment wird die Laufzeit in Abhängigkeit von der Anzahl der Zustände 

gemessen. Im zweiten werden Kripke-Strukturen mit jeweils 9 Zuständen erzeugt. Die 

Anzahl der Übergänge wird variiert. Abbildung 5.1 ist ein Ausschnitt aus Abbildung 5.2. 

Das Verhalten von beiden Implementierungen ist für die Kripke-Strukturen mit bis zu 

7 Zuständen ähnlich. Danach wächst die Laufzeit der ” List“-Implementierung exponentiell. 

Für größere Kripke-Strukturen steigt die ” Tree“-Implementierung langsamer, aber 

auch exponentiell an. Dies ist in den Abbildungen 5.3 und 5.4 ersichtlich, in denen die 

Laufzeiten in Abhängigkeit von der Anzahl der Übergänge dargestellt sind. In diesen 

38


Abbildungen besteht die Möglichkeit, das Verhalten des Algorithmus in Bezug auf die 

Anzahl der zu ” wahr“ evaluierten Zustände zu analysieren, die in der obersten Zeile auf 

der X-Achse dargestellt sind. 

Wegen der exponentiellen Laufzeit und des Mangels an Ressourcen können ” größere“ 

Kripke-Strukturen nicht getestet werden. Wenn eine Pfad-Formel auf einer Kripke- 

Struktur mit 9 Zuständen und 9 Übergängen mittels der modelCheckingCTLpos- 

ArrayList(...) geprüft wird, tritt ein ” java.lang.OutOfMemoryError“ Fehler auf. Beim Verwenden 

der Methode modelCheckingCTLposTree(...) tritt dieses Problem für Kripke- 

Strukturen mit 15 Zuständen und 6 Übergängen aus jedem Zustand auf. In Abbildung 

5.3 ist zu sehen, dass die Laufzeit von der Tree-Implementierung langsamer, aber auch 

exponentiell wächst. 

Experiment I Experiment II 

Anzahl der Zustände W 2..8 9 

Anzahl der Übergänge ⌊ W ⌋ 2 2..4 

Anzahl der Durchläufe 5 3 

Getestete Formeln EG b, E(c U d) EG b 

Abbildungen 5.1, 5.2 5.3, 5.4 

Tabelle 5.2: Experimentendaten für zwei Implementierungen des CTLpos-Algorithmus 

Abbildung 5.1: Zwei Implementierungen des CTLpos -Algorithmus: EG- und EU- 

Formeln, Zustände 2..7 

39


Abbildung 5.2: Zwei Implementierungen des CTLpos -Algorithmus: EG- und EU- 

Formeln, Zustände 2..8 

Abbildung 5.3: Zwei Implementierungen des CTLpos -Algorithmus: EG-Formel, 9 

Zustände 

5.3 Auswertung von CTLpos - und CTL-Algorithmen 

Hier werden die CTLpos- und CTL-Algorithmen verglichen. Wir führen zwei Experimente 

durch, in denen, wie im vorigen Abschnitt, die Abhängigkeit von der Anzahl der Zustände 

und der Übergänge anhand den Abbildungen herausgestellt wird. Um Algorithmen 

vergleichen zu können, werden Formeln betrachtet, die die CTLpos-Bedingungen erfüllen. 

40


Abbildung 5.4: Tree-Implementierung des CTLpos-Algorithmus: EG-Formel, 9 Zustände 

Die Tabelle 5.3 enthält die Testsdaten von diesen Experimenten. 

Anzahl der Zustände 

W 


2..8 5 

Anzahl 

Übergänge 

der ⌊ W ⌋ 2 2..5 

Anzahl 

Durchläufe 

der 5 5 

Getestete For- a AND b, EG b, (EX a) OR (a AND b), EX a, EG b 

meln 

EG(e AND EX a), EG(EG b) 

Abbildungen 5.5, 5.6, 5.7 5.9, 5.8 

Tabelle 5.3: Experimentendaten für CTLpos- und CTL-Algorithmen 

In Abbildung 5.5 werden die Laufzeiten von Zustand-Formeln präsentiert. Die Laufzeit- 

Kurven der beiden Algorithmen verlaufen ähnlich. Die herausragenden spitzigen Buckel 

stellen die Laufzeiten für diejenigen Kripke-Strukturen und Formeln dar, die in jedem 

Zustand erfüllt werden. Die Laufzeiten der beiden Algorithmen nehmen für diese Formeln 

auf diesem Intervall zu und tendieren zur linearen Laufzeit. Eine andere Situation 

ist in Abbildung 5.6 zu beobachten. Die Laufzeit des CTLpos-Algorithmus ist nicht mehr 

” linear“. Der CTL-Algorithmus ist für die EG-, EU-Formeln deutlich schneller als der 

CTLpos-Algorithmus. Die Kurven des CTL-Algorithmus sind kaum zu erkennen, da seine 

Laufzeit für diese Formeln zwischen 0 und 0,8 Millisekunden schwankt (siehe Abbildung 

5.7). 

41


Die Abbildungen 5.9, 5.8 zeigen das Verhalten der Algorithmen für Kripke-Strukturen 

mit jeweils 5 Zuständen und mit variierter Anzahl von Übergängen. Das exponentielle 

Wachstum des CTLpos-Algorithmus lässt sich noch nicht erkennen. 

Abbildung 5.5: Vergleich der CTLpos - und CTL-Algorithmen: Zustand-Formeln, 2..8 

Zustände 

Abbildung 5.6: Vergleich der CTLpos- und CTL-Algorithmen: EG- und EU-Formeln, 2..8 

Zustände 

42


Abbildung 5.7: Vergleich der CTLpos- und CTL-Algorithmen: Ausschnitt aus 5.6 mit den 

Laufzeiten des CTL-Algorithmus, 2..8 Zustände 

Abbildung 5.8: Vergleich der CTLpos - und CTL-Algorithmen: EG-Formel, 5 Zustände, 

2..5 Übergänge 

5.4 Laufzeit des CTL-Algorithmus für Kripke-Strukturen 

mit bis zu 300 Zuständen 

Ziel dieses Abschnitts ist die Analyse des CTL-Algorithmus für ” große“ Kripke-Strukturen. 

Im ersten Experiment beschränken wir uns auf die Kripke-Strukturen mit bis zu 

100 Zuständen. Abbildungen 5.10, 5.11, 5.12 zeigen die Laufzeiten je nach der Art der 

43


Abbildung 5.9: Vergleich der CTLpos - und CTL-Algorithmen: EX-Formel, 5 Zustände, 

2..5 Übergänge 

Operatoren (existenzielle oder universelle) bzw. in Abhängigkeit vom Verschachtellungsgrad 

der Formeln. Da jede Formel immer mittels der Operatoren der minimalen Menge 

{¬, ∨, EX, EU, EG} umgewandelt wird, bevor der CTL-Algorithmus gestartet wird, 

dienen die Abbildungen 5.11 und 5.12 nur zum Überblick und stellen die Laufzeiten für 

die Formeln größeres Verschachtellungsgrades im Vergleich zu den Formeln aus Abbildung 

5.10 dar. Das zweite Experiment (Abbildung 5.13) visualisiert das polynomielle 

Verhalten des CTL-Algorithmus abhängig von der Anzahl der Zustände. Hier werden 

die Formeln betrachtet, die erzwingen, dass die entweder in keinem oder in allen Zuständen 

erfüllt werden. Die Laufzeit für die Formel EX ∼ a ist kleiner als für die Formel 

EG(b OR ∼ b), da die letzte mehr Zeit für den Aufbau der Zusammenhangkomponenten 

beansprucht. Die Laufzeiten für die Formeln, die nie erfüllt werden, betragen maximal 

fünf Millisekunden. Allerdings demonstrieren alle Abbildungen polynomielle Laufzeit des 

CTL-Algorithmus. 

44

Anzahl der 

Zustände 

W (Schritt) 

Anzahl der 

Übergänge 

Anzahl der 

Durchläufe 

Getestete Formeln 



10..100(10) 50..300(25) 

⌊ W 

W 

⌋ ⌊ 2 2 ⌋ 

5 1 

EG b, (EX a), E(c U d), E(c R d), EF c, 

AG b, (AX a), A(c U d), A(c R d), AF c, 

EG(EG b), AG(AG b), AG(e AND AX 

a), AG( e AND AX a) 

Abbildungen 5.10, 5.11, 5.12 5.13 

EX a, EX ( a 

AND a), EG (b 

OR b), EG (a 

AND a) 

Tabelle 5.4: Experimentendaten für den CTL-Algorithmus mit ” großen“ Kripke-Strukturen 

Abbildung 5.10: Vergleich der Laufzeiten des CTL-Algorithmus: Formeln mit existentiellen 

Operatoren, 10..100 Zustände 

45


Abbildung 5.11: Vergleich der Laufzeiten des CTL-Algorithmus: Formeln mit universalen 

Operatoren, 10..100 Zustände 

Abbildung 5.12: Vergleich der Laufzeiten des CTL-Algorithmus: Formeln verschiedenes 

Verschachtellungsgrades, 10..100 Zustände 

46


Abbildung 5.13: Vergleich der Laufzeiten des CTL-Algorithmus: EX- und EG-Formeln, 

50..300 Zustände 

47

6 Zusammenfassung und Ausblick 

Die Aufgabe dieser Diplomarbeit ist es, das Model-Checking-Problem für CTL auszuarbeiten. 

Als Erstes wurde der allgemeine Model-Checking-Prozess betrachtet, und dessen 

grundlegende Begriffe wurden eingeführt. Insbesondere wurde die Kripke-Struktur definiert, 

mit deren Hilfe endliche zustandsbasierte Systeme modelliert werden können. 

Anforderungen an die Systeme werden mittels einer Spezifikationssprache formalisiert. 

Im Rahmen dieser Arbeit wurde auf die temporale Logik CTL (Computation Tree Logic) 

näher eingegangen, die für die Spezifikation verwendet wird. Die theoretischen Grundlagen 

wurden anhand von Beispielen veranschaulicht. 

Ein weiteres Ziel besteht darin, die Komplexität des Model-Checking-Problems für 

CTL zu untersuchen. Dieses Problem ist als P-vollständig bekannt ([CES86], [Sch02]). 

Es wird versucht, leichtere Teilprobleme zu finden, die effizienter zu lösen sind. Dafür 

wurde CTLpos , ein Fragment von CTL, betrachtet, in dem die Negation nicht auf die 

temporalen Operatoren angewendet werden darf. Außerdem werden nur bestimmte temporale 

Operatoren erlaubt. 

Weiterhin wurden zwei Model-Checking-Algorithmen vorgestellt, und zwar für CTL 

allgemein und für CTLpos. Als praktischer Teil dieser Arbeit wurden sie in Java implementiert. 

Dabei wurde ein schon existierendes Programm erweitert, in dem die Datenstruktur 

für die Kripke-Struktur vorhanden war. Dieses Programm wurde für Model-Checking für 

eine andere temporale Logik entwickelt. Deswegen wurden die Datenstrukturen für CTLund 

CTLpos-Formeln geschaffen. Die beiden Algorithmen haben polynomielle Laufzeit. 

Im Algorithmus für CTLpos musste man nichtdeterministisch eine Entscheidung treffen. 

Dies wurde dadurch ersetzt, dass alle in Frage kommenden Möglichkeiten der Reihe 

nach untersucht wurden, bis eine Lösung gefunden wurde. Im schlimmsten Fall müssen 

aber alle Möglichkeiten überprüft werden. Dies führt zu der exponentiellen Laufzeit des 

implementierten Algorithmus. Als Verbesserung der exponentiellen Laufzeit wurde eine 

weitere Implementierung vorgenommen, in der Berechnungspfade in einer baumartigen 

Struktur gespeichert und entsprechend traversiert werden. 

Außerdem wurde ein großer Wert auf die Benutzerschnittstelle des Programms gelegt. 

Insbesondere wurde die graphische Benutzeroberfläche überarbeitet. Es wurden neue 

Funktionalitäten eingeführt, die unter anderem dem Benutzer ermöglichen, Zustände in 

der Kripke-Struktur per Mausklick zu (de-)selektieren und die Algorithmen für diverse 

Zustände auszuführen. Die Ergebnisse der Algorithmen werden nicht nur im Text, 

sondern auch graphisch angezeigt. Weiterhin kann der Benutzer das Programm so einzustellen, 

dass bestimmte Kripke-Struktur und Formel beim Öffnen des Programms automatisch 

geladen werden. Es besteht jetzt auch die Möglichkeit, Kripke-Strukturen mit 

bestimmter Anzahl der Zustände, der Übergänge und der atomaren Aussagen zufällig 

zu generieren. 

48

6 Zusammenfassung und Ausblick 

Anschließend wurden die betrachteten Algorithmen anhand der zufälligen Testdaten 

untersucht und ausgewertet. Die Laufzeiten wurden graphisch veranschaulicht. 

Die Auswertung der Algorithmen hat das polynomielle Verhalten des CTL- und das 

exponentielle Verhalten des implementierten CTLpos -Algorithmus für das betrachtete 

Fragment der temporalen Operatoren {EX, EG, EU, ER} anhand der Visualisierungen 

der Laufzeiten bestätigt. 

Um eine bessere Komplexität des Model-Checking-Problems für CTL zu erreichen, 

könnte man weitere Fragmente von CTL untersuchen. Da sich der CTL-Algorithmus als 

effizient erwiesen hat, kann er für das Model-Checking für CTL eingesetzt werden. 

Das Programm kann weiterentwickelt werden. Dabei können die bestehenden Datenstrukturen 

einerseits für weitere Model-Checking-Algorithmen verwendet, andererseits 

für andere temporale Logiken modifiziert werden. 

Weiterhin könnte man das Erstellen und das Ändern der Kripke-Struktur direkt in 

ihrer Visualisierung als Graphen ermöglichen, damit der Benutzer Zustände und Übergänge 

per Mausklick hinzufügen und löschen könnte. 

49

Abbildungsverzeichnis 

2.1 Speisende Philosophen (vgl. [Sch]) . . . . . . . . . . . . . . . . . . . . . . . 9 

2.2 Speisende Philosophen als ein Modell([Har02]) . . . . . . . . . . . . . . . . 10 

2.3 Speisende Philosophen als eine Kripke-Struktur . . . . . . . . . . . . . . . 11 

4.1 Das Hauptfenster des Basisprogramms (Bild aus [Sol09]) . . . . . . . . . . 22 

4.2 Klassendiagramm für Programmlogik . . . . . . . . . . . . . . . . . . . . . . 23 

4.3 Klassendiagramm der Benutzerschnittstelle . . . . . . . . . . . . . . . . . . 24 

4.4 Zwei Abarbeitungsmöglichkeiten bei der Untersuchung von Pfad-Formeln 28 

4.5 Das geänderte Hauptfenster des Programms . . . . . . . . . . . . . . . . . 30 

4.6 Das Fenster mit den Einstellungen des Programms . . . . . . . . . . . . . 31 

4.7 Graphische Darstellung einer Kripke-Struktur . . . . . . . . . . . . . . . . 32 

4.8 Model-Checking-Fenster für CTL vor dem Ausführen des CTL-MC(ALL)- 

Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 

4.9 Model-Checking-Fenster für CTL nach dem Ausführen des CTL-MC(ALL)- 

Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 

4.10 Model-Checking-Fenster für CTL nach dem Ausführen des CTLpos-MC(EX, 

EG, EU, ER)-Algorithmus für eine EX-Formel . . . . . . . . . . . . . . . 35 

4.11 Model-Checking-Fenster für CTL nach dem Ausführen des CTLpos-MC(EX, 

EG, EU, ER)-Algorithmus für eine EG-Formel . . . . . . . . . . . . . . . 35 

5.1 Zwei Implementierungen des CTLpos-Algorithmus: EG- und EU-Formeln, 

Zustände 2..7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

5.2 Zwei Implementierungen des CTLpos-Algorithmus: EG- und EU-Formeln, 

Zustände 2..8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 

5.3 Zwei Implementierungen des CTLpos-Algorithmus: EG-Formel, 9 Zustände 40 

5.4 Tree-Implementierung des CTLpos-Algorithmus: EG-Formel, 9 Zustände . 41 

5.5 Vergleich der CTLpos- und CTL-Algorithmen: Zustand-Formeln, 2..8 Zustände 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

5.6 Vergleich der CTLpos- und CTL-Algorithmen: EG- und EU-Formeln, 2..8 

Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 

5.7 Vergleich der CTLpos- und CTL-Algorithmen: Ausschnitt aus 5.6 mit den 

Laufzeiten des CTL-Algorithmus, 2..8 Zustände . . . . . . . . . . . . . . . . 43 

5.8 Vergleich der CTLpos- und CTL-Algorithmen: EG-Formel, 5 Zustände, 2..5 

Übergänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 

5.9 Vergleich der CTLpos- und CTL-Algorithmen: EX-Formel, 5 Zustände, 2..5 

Übergänge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 

50

Abbildungsverzeichnis 

5.10 Vergleich der Laufzeiten des CTL-Algorithmus: Formeln mit existentiellen 

Operatoren, 10..100 Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

5.11 Vergleich der Laufzeiten des CTL-Algorithmus: Formeln mit universalen 

Operatoren, 10..100 Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

5.12 Vergleich der Laufzeiten des CTL-Algorithmus: Formeln verschiedenes Verschachtellungsgrades, 

10..100 Zustände . . . . . . . . . . . . . . . . . . . . . 46 

5.13 Vergleich der Laufzeiten des CTL-Algorithmus: EX- und EG-Formeln, 

50..300 Zustände . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 

51

Tabellenverzeichnis 

2.1 Temporale Operatoren. ϕ, ψ sind temporal-logische Formeln . . . . . . . . 6 

2.2 Pfad-Quantoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

2.3 Darstellung der CTL-Formeln durch die Operatoren EX, EU, EG, ¬, ∨ . 8 

5.1 Test-Formeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 

5.2 Experimentendaten für zwei Implementierungen des CTLpos-Algorithmus 39 

5.3 Experimentendaten für CTLpos- und CTL-Algorithmen . . . . . . . . . . . 41 

5.4 Experimentendaten für den CTL-Algorithmus mit ” großen“ Kripke-Strukturen 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

52

Literaturverzeichnis 

[AHU74] Aho, A. V., J. E. Hopcroft und J. D. Ullmann: The Design and Analysis 

of Computer Algorithms. Addison-Wesley Publishing Company, London, 

England, 1974. 

[AUH82] Aho, A. V., J. D. Ullman und J. E. Hopcroft: Data Structures and 

Algorithms. Addison Wesley Pub Co Inc, 1982. 

[BMT + ] Beyersdorff, O., A. Meier, M. Thomas, H. Vollmer, M. Mundhenk 

und T. Schneider: Model Checking for CTL Fragments Made Efficiently 

Parallel. Unveröffentlichte, vorläufige Version von [BMT + 09]. 

[BMT + 09] Beyersdorff, O., A. Meier, M. Thomas, H. Vollmer, M. Mundhenk 

und T. Schneider: Model Checking CTL is Almost Always 

Inherently Sequential. Proc. of the 16th International Symposium 

on Temporal Representation and Reasoning, IEEE Computer Society 

Press, 2009. http://www.thi.uni-hannover.de/fileadmin/forschung/ 

publikationen/daten/be-me-mu-sc-th-vo-09.pdf. 

[CES86] Clarke, E., A. E. Emerson und A. Systla: Automatic verification of 

finite-state concurrent systems using temporal logic specifications. ACM Transactions 

on Programming Languages and Systems, 1986. 

[CGP99] Clarke, E. M., O. Grumberg und D. A. Peled: Model Checking. The 

MIT Press, Cambridge, Massachusetts, London, England, 1999. 

[EL87] Emerson, A. E. und C.-L. Lei: Modalities for model checking: Branching 

time logic strikes back. Science of Computer Programming, 1987. 

[Har02] Hartmann, A.: Ein grafisches Werkzeug zur Unterstützung von Model- 

Checking-Prozessen. Diplomarbeit, Universität Rostock, Fachbereich Informatik, 

2002. http://www.cocooncenter.org/index/thesis_hartmann. 

pdf. 

[Sch] Schwoon, S.: Model-Checking. http://www.fmi.uni-stuttgart.de/szs/ 

teaching/ss2004/modelchecking/modelchecking.pdf. 

[Sch02] Schnoebelen, P.: The complexity of temporal logic model Checking. Advances 

in Modal Logic, 2002. 

53

Literaturverzeichnis 

[Sol09] Soldatova, M.: Effizientes Model-Checking für CTL*. Diplomarbeit, Universität 

Hannover, 2009. http://www.thi.uni-hannover.de/fileadmin/ 

forschung/arbeiten/soldatova-da.pdf. 

54

Erklärung 

Hiermit versichere ich, dass ich die vorliegende Arbeit und die zugehörige Implementierung 

selbständig verfasst und dabei nur die angegebenen Quellen und Hilfsmittel verwendet 

habe. 

Hannover, 26. Oktober 2009 

Julia Gerock

Effizientes Model-Checking für CTL - Institut für Theoretische ...

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?