
diff -r 706257e41de3 -r 189c28168c97 book/src/analysis.tex
--- a/book/src/analysis.tex	Fri Mar 25 00:10:33 2011 +0100
+++ b/book/src/analysis.tex	Fri Mar 25 15:57:06 2011 +0100
@@ -23,7 +23,7 @@
 Die Konfiguration der Abflugplanungskomponente hat Einfluss auf die Verarbeitungsprozesse und ist somit weit möglichst auf Korrektheit zu prüfen. Die Prüfung der Konfiguration soll in der Initialisierungsphase des Systems stattfinden, um die sichere Operation eines Systems zu garantieren, \cite{iec_61508}. Bei statisch typisierten Sprachen werden bereits beim Übersetzen die Datentypen festgelegt und somit überprüfbar gemacht. Dies ermöglicht es, eine große Anzahl an möglichen Fehlern in der Konfiguration zu erkennen, bei denen ungültige Kombinationen von Operation und Datentyp bestehen.\\\\
 Jede Funktionalität eines Systems muss stets überwacht werden. Bei Fehlverhalten soll eine Wiederaufnahme der Funktionalität gewährleistet werden, ohne die Datenintegrität oder andere Prozesse des Systems zu gefährden. 
 
-Zur Sicherung der Daten wird eine strikte Trennung von Daten und informationsverarbeitenden Prozessen durchgeführt. Jeder Transaktion wird geprüft, protokolliert und redundant propagiert. In der Flugsicherung ist die redundante Auslegung von Komponenten Kernbestandteil bei der Sicherung der Verfügbarkeit eines Systems. Die letzte Option bei dem Auflösen eines Systemkonflikts liegt in der Abschaltung und Neuinitialisierung eines Systems, während die redundante Auslegung weiterhin die Funktionalität sicherstellt. 
+Zur Sicherung der Daten wird eine strikte Trennung von Daten und informationsverarbeitenden Prozessen durchgeführt. Jede Transaktion wird geprüft, protokolliert und redundant propagiert. In der Flugsicherung ist die redundante Auslegung von Komponenten Kernbestandteil bei der Sicherung der Verfügbarkeit eines Systems. Die letzte Option bei dem Auflösen eines Systemkonflikts liegt in der Abschaltung und Neuinitialisierung eines Systems, während die redundante Auslegung weiterhin die Funktionalität sicherstellt. 
 
 \subsubsection{Statusmeldungen}
 Durch das \emph{Watchdog}-Protokoll ist es möglich die Vitalität einer Komponente zu über\-wachen. In periodischen Abständen wird dabei von einem Überwachungsprozess eine Anfrage an alle Komponenten gestartet, die innerhalb einer bestimmten Zeit beantwortet werden muss. Die Antwort kann detaillierte Informationen über den Status einer Komponente enthalten, oder lediglich deren Aktivität bestätigen. 
@@ -51,7 +51,7 @@
 Die Bezeichnungen für die Start- und Ladebahnen -- Englisch \emph{Runway} -- können lokal vergeben werden und sind meist eine Kombination aus mehreren Buchstaben und darauf folgenden Zahlen, z.B. RWY01. Es sind bis zu fünf Zeichen für die Identifikation erlaubt, die Abkürzung \emph{RWY} soll das Feld in der Sprache bezeichnen.
 
 \subsubsection{Aircraft Type}
-\emph{ICAO} legt einen vierstelligen Identifikationskode für die Flugzeugtypen fest. Die Kodierung erlaubt sowohl  Buchstaben als auch Zahlen. Beispielkodierungen sind A332 für den \emph{Airbus A330-200} oder B744 für eine \emph{Boeing 747-400}. Gebräuchliche Abkürzung ist \emph{ATYP}. In der Sprache soll das Schlüsselwort \emph{ATYP} für den Flugzeugtyp reserviert sein, zulässige werden sollen alle Zeichenkette der Länge vier darstellen.
+\emph{ICAO} legt einen vierstelligen Identifikationskode für die Flugzeugtypen fest. Die Kodierung erlaubt sowohl  Buchstaben als auch Zahlen. Beispielkodierungen sind A332 für den \emph{Airbus A330-200} oder B744 für eine \emph{Boeing 747-400}. Gebräuchliche Abkürzung ist \emph{ATYP}. In der Sprache soll das Schlüsselwort \emph{ATYP} für den Flugzeugtyp reserviert sein, zulässige Werte sollen alle Zeichenkette der Länge vier darstellen.
 
 \subsubsection{Flight Type}
 Der \emph{Flight Type} beschreibt den Einsatztyp des Fluges, sei es ein Passagierflug, Transportflug oder ein militärischer Einsatz. Hierfür wird ein Zeichen zur Identifizierung genutzt. Die Abkürzung hierfür ist \emph{FTYP}. Die Sprache soll als Wertemenge alle Zeichen akzeptieren.
@@ -134,5 +134,5 @@
 \section{Dokumentation}
 Alle ermittelten Anforderungen werden in der sog. System Requirements Specification festgehalten. Das SRS ist die Basis aller folgenden Entwicklungsschritte. Es dient später zur Testfallerzeugung, da hierbei alle Anforderungen mindestens einmal abgedeckt werden müssen.
 
-Das SRS ist das Referenzdokument für die Abnahme vor Ort und dem Kunden und muss deshalb auch vom Kunden abgenommen werden. Jede Änderung im System muss gegen die Anforderungen geprüft werden, gegebenenfalls müssen neue Anforderungen hinzugefügt werden oder alte angepasst, Beides hat zur Folge, dass eine erneute Abnahme vom Kunden fällig wird.\\\\
+Das SRS ist das Referenzdokument für die Abnahme vor Ort und muss deshalb auch vom Kunden abgenommen werden. Jede Änderung im System muss gegen die Anforderungen geprüft werden, gegebenenfalls müssen neue Anforderungen hinzugefügt werden oder alte angepasst, beides hat zur Folge, dass eine erneute Abnahme vom Kunden fällig wird.\\\\
 Im SRS wird für jede Anforderung eine Identifikationsnummer allokiert, diese wird in den weiteren Phasen des Projekts referenziert. Nach \cite{iec_61508} bildet die Dokumentation die Basis der Nachvollziehbarkeit der Entscheidungsfindung und dadurch auch die Grundlage einer erfolgreichen Zertifizierung.




