1.1 Binary file book/out/buchblock.pdf has changed

     2.1 --- a/book/src/analysis.tex	Fri Mar 25 00:10:33 2011 +0100
     2.2 +++ b/book/src/analysis.tex	Fri Mar 25 15:57:06 2011 +0100
     2.3 @@ -23,7 +23,7 @@
     2.4  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.\\\\
     2.5  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. 
     2.6  
     2.7 -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. 
     2.8 +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. 
     2.9  
    2.10  \subsubsection{Statusmeldungen}
    2.11  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. 
    2.12 @@ -51,7 +51,7 @@
    2.13  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.
    2.14  
    2.15  \subsubsection{Aircraft Type}
    2.16 -\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.
    2.17 +\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.
    2.18  
    2.19  \subsubsection{Flight Type}
    2.20  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.
    2.21 @@ -134,5 +134,5 @@
    2.22  \section{Dokumentation}
    2.23  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.
    2.24  
    2.25 -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.\\\\
    2.26 +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.\\\\
    2.27  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.

     3.1 --- a/book/src/document.log	Fri Mar 25 00:10:33 2011 +0100
     3.2 +++ b/book/src/document.log	Fri Mar 25 15:57:06 2011 +0100
     3.3 @@ -1,4 +1,4 @@
     3.4 -This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.1.10)  25 MAR 2011 00:07
     3.5 +This is pdfTeX, Version 3.1415926-1.40.10 (TeX Live 2009/Debian) (format=pdflatex 2011.1.10)  25 MAR 2011 15:56
     3.6  entering extended mode
     3.7   restricted \write18 enabled.
     3.8   %&-line parsing enabled.
     3.9 @@ -1274,6 +1274,12 @@
    3.10  
    3.11  <use images/hybrid_compiler.pdf> [22 <./images/compiler.pdf> <./images/interpre
    3.12  ter.pdf>]
    3.13 +Overfull \hbox (2.08266pt too wide) in paragraph at lines 144--147
    3.14 +[]\OT1/lmr/m/n/12 uber-pr[]uft, um aus dem va-li-den Co-de die []Uberf[]uhrung 
    3.15 +in das Back-End zu gew[]ahrleisten.
    3.16 + []
    3.17 +
    3.18 +
    3.19  Underfull \hbox (badness 10000) in paragraph at lines 144--147
    3.20  
    3.21   []
    3.22 @@ -2173,7 +2179,7 @@
    3.23  usr/share/texmf/fonts/type1/public/lm/lmtk10.pfb></usr/share/texmf/fonts/type1/
    3.24  public/lm/lmtt12.pfb></usr/share/texmf/fonts/type1/public/lm/lmtti10.pfb></usr/
    3.25  share/texmf/fonts/type1/public/lm/lmtto10.pfb>
    3.26 -Output written on document.pdf (107 pages, 1865484 bytes).
    3.27 +Output written on document.pdf (107 pages, 1865467 bytes).
    3.28  PDF statistics:
    3.29   2505 PDF objects out of 2984 (max. 8388607)
    3.30   811 named destinations out of 1000 (max. 500000)

     4.1 Binary file book/src/document.pdf has changed

     5.1 --- a/book/src/research.tex	Fri Mar 25 00:10:33 2011 +0100
     5.2 +++ b/book/src/research.tex	Fri Mar 25 15:57:06 2011 +0100
     5.3 @@ -111,7 +111,7 @@
     5.4  Eine Programmiersprache soll die Kommunikation zwischen Mensch und Computer erleichtern. Die Sprache ist an die
     5.5  menschlichen Bedürfnisse angepasst und erlaubt im besten Fall eine Abstraktion über das darunter liegende System.
     5.6  Das Übersetzen des Programms in ein Programm in Maschinensprache ermöglicht letztendlich das Ausführen des Programms auf einem Computer.\\\\
     5.7 -In manchen Situationen bietet es sich an eine weitere plattformunabhängige Schicht dazwischen zu setzen, die sog. Virtuelle Maschine. Diese Schicht bedient sich der Schnittstellen des Systems und bietet dafür eine abstrahierte Laufzeitumgebung an. Eine Virtuelle Maschine kann somit plattformunabhängigen Bytecode auf verschiedenen System ausführen.\\\\
     5.8 +In manchen Situationen bietet es sich an, eine weitere plattformunabhängige Schicht dazwischen zu setzen, die sog. Virtuelle Maschine. Diese Schicht bedient sich der Schnittstellen des Systems und bietet dafür eine abstrahierte Laufzeitumgebung an. Eine Virtuelle Maschine kann somit plattformunabhängigen Bytecode auf verschiedenen System ausführen.\\\\
     5.9  Eine wichtige Rolle eines Compilers ist es, Fehler im Programmcode zu berichten, die während der Übersetzung
    5.10  entdeckt wurden. Zur effektiven Auflösung von auftretenden Fehlern gilt es eine möglichst genaue Beschreibung und Lokalität des Fehlers zu liefern. Zur Reduzierung von wiederholten Übersetzungsvorgängen ist es hilfreich möglichst viele Fehler in einem Durchlauf zu erkennen. Hierfür ist es notwendig Richtlinien zu setzen, die eine Fortsetzung des Übersetzungsvorgangs ermöglichen und das Entstehen von Seiteneffekten durch vorhergegangene Fehler vermeiden.
    5.11  
    5.12 @@ -141,7 +141,7 @@
    5.13  \end{figure}
    5.14  
    5.15  \subsection{Werkzeugunterstützung}
    5.16 -In der Analysephase eines Übersetzers wird der Eingabecode analysiert und auf Fehler über"-prüft um aus dem validen Code die Überführung in das Back-End zu gewährleisten.
    5.17 +In der Analysephase eines Übersetzers wird der Eingabecode analysiert und auf Fehler über"-prüft, um aus dem validen Code die Überführung in das Back-End zu gewährleisten.
    5.18  Das Front-End eines Compilers wird auch Parser genannt. Die Geschichte der Compiler-Entwick"-lung hat seit dem ersten Compiler im Jahre 1952, welches von Grace Hopper entwickelt wurde, die später auch an der Entwicklung von \emph{COBOL} beteiligt war, enorme Fortschritte gemacht. Mittlerweile stehen für die Entwicklung eines Übersetzers eine Vielzahl an Werkzeugen zur Verfügung, die jede Phase des Compilers abdecken.\\\\
    5.19  Für die Entwicklung des Compilers für die Konfigurationssprache wurden verschiedene Technologien evaluiert:
    5.20  \begin{itemize}
    5.21 @@ -185,5 +185,5 @@
    5.22  Der \emph{PATS Departure Manager} realisiert laut \cite{eurocontrol_dman} 2.3.3 keine Optimierung des Flugverlaufs hinsichtlich der weiterführenden Route und deren Verkehrsflussdichten. Auch die Separation nach Flugfläche ist nicht Bestandteil der Funktionalität.
    5.23  
    5.24  \subsection{Departure Manager Frankfurt}
    5.25 -Eine weitere Entwicklung im Bereich Abflugmanager stellt der \emph{darts4D DMAN} von der Firma \emph{Delair} dar. Das System soll verbindliche Aussagen über die Startzeit, bzw. die sog. \emph{Off-Block Time}, unter Berücksichtigung aller Prozesse und Richtlinien des Flughafens machen. Der Departure Manager wurde im April 2007 in Frankfurt in Betrieb genommen und aufgrund von Beeinträchtigung des Abflugmanagements wenige Monate später wieder aus dem System genommen \cite{flugleiter_dman}.\\\\
    5.26 -Interessant hierbei sind die genannten Gründe für den Fehlschlag: eine unausreichende Einbindung der Endanwender und Domänenexperten in den Entwicklungsprozess sollen laut \cite{flugleiter_dman} die Hauptgründe für die fehlerhafte Konzeption gewesen sein. Ein weiterer Grund werden die komplexen Abhängigkeiten der vielen Parameter sein, die zum erfolgreichen Mikromanagement eines Abflugs in die Berechnung aufgenommen werden. Die Eingangsparameter sind zudem durch äußere und menschliche Einflüsse höchst dynamisch, was die Zuverlässigkeit der Prognosen reduziert.
    5.27 +Eine weitere Entwicklung im Bereich Abflugmanager stellt der \emph{darts4D DMAN} von \emph{Delair} dar. Das System soll verbindliche Aussagen über die Startzeit, bzw. die sog. \emph{Off-Block Time}, unter Berücksichtigung aller Prozesse und Richtlinien des Flughafens machen. Der Departure Manager wurde im April 2007 in Frankfurt in Betrieb genommen und aufgrund von Beeinträchtigung des Abflugmanagements wenige Monate später wieder aus dem System genommen \cite{flugleiter_dman}.\\\\
    5.28 +Interessant hierbei sind die genannten Gründe für den Fehlschlag: eine unausreichende Einbindung der Endanwender und Domänenexperten in den Entwicklungsprozess sollen laut \cite{flugleiter_dman} die Hauptgründe für die nicht optimale Konzeption gewesen sein. Ein weiterer Grund werden die komplexen Abhängigkeiten der vielen Parameter sein, die zum erfolgreichen Mikromanagement eines Abflugs in die Berechnung aufgenommen werden. Die Eingangsparameter sind zudem durch äußere und menschliche Einflüsse höchst dynamisch, was die Zuverlässigkeit der Prognosen reduzieren kann.