1.1 --- a/book/src/impl.tex	Mon Mar 28 21:39:52 2011 +0200
     1.2 +++ b/book/src/impl.tex	Mon Mar 28 23:37:03 2011 +0200
     1.3 @@ -96,7 +96,7 @@
     1.4  \lstinputlisting[label=flex_config6, caption=ATCCL \texttt{flex}-Konfiguration: \texttt{Constraint}-Token,language=TeX]{flex_config6.txt}
     1.5  Das yylval wird in der \texttt{bison}-Konfiguration als \texttt{union} von \texttt{integer, double} und \texttt{char*} deklariert. Dadurch wird eine typensichere Wertübertragung von Konstanten in die Syntaxanalyse ermöglicht.\\
     1.6  \lstinputlisting[label=flex_config7, caption=ATCCL \texttt{flex}-Konfiguration: Basisdatentypen,language=TeX]{flex_config7.txt}
     1.7 -Zur zusätzlichen Unterstützung der nachfolgenden Analyse wird eine Regel für die Regeldefinitionsidentifikation gestellt und die Kommentare lokalisiert. Der Kommentarinhalt wird nicht übergeben sondern ignoriert. Die letzte Regel leitet alle Zeichen weiter, die bisher in keiner Regel aufgefangen wurde, wie z.B. die Klammern.\\
     1.8 +Zur zusätzlichen Unterstützung der nachfolgenden Analyse wird eine Regel für die Regeldefinitionsidentifikation gestellt und die Kommentare lokalisiert. Der Kommentarinhalt wird nicht übergeben sondern ignoriert. Die letzte Regel leitet alle Zeichen weiter, die bisher in keiner Regel aufgefangen wurde, wie z.B. die Klammern.\newpage
     1.9  \lstinputlisting[label=flex_config8, caption=ATCCL \texttt{flex}-Konfiguration: IDs und Kommentare,language=TeX]{flex_config8.txt}
    1.10  Eine Besonderheit in der \texttt{flex}-Konfiguration stellt die letzte Zeile dar, die bei Zeilenende den Inhalt der Zeile in einem Puffer zwischenspeichert und einen Zeilenzähler inkrementiert. Diese Regel dient der Fehlerbehandlung. Durch das Puffern der Zeilen ist im Fehlerfall eine weitere Analyse möglich, außerdem kann man durch die Zeilenangabe den Fehler lokalisieren.\\
    1.11  \lstinputlisting[label=flex_config9, caption=ATCCL \texttt{flex}-Konfiguration: Fehlerbehandlung,language=TeX]{flex_config9.txt}
    1.12 @@ -115,10 +115,14 @@
    1.13  Zur Realisierung der DFLOW-Komponente konnte man auf den großen Funktionsumfang von PRISMA zugreifen. So war es nicht notwendig eigene Routinen zur Erstellung der Prognosen über die Überflugzeiten zu entwickeln, diese Funktion wurde bereits von \emph{CalcEstimates} bereitgestellt. FPATH übernimmt als FPDS-Komponente die Aktualisierung solcher Routentabellen samt prognostizierter Zeiten entsprechend dem realen Flugverlauf. Die Ergänzung der Flugroute unmittelbar nach dem Startvorgang wurde mit Hilfe von SID-Lookup-Tabellen realisiert, eine Erklärung zur Bedeutung der SIDs befindet sich in Abschnitt \ref{grundlagen:routensystem}. Die SID-Wegpunkte sind für jede Kombination von Flughafen, Startbahn und Routenverlauf festgelegt und statisch.
    1.14  
    1.15  \subsection{FDPS}
    1.16 -Die DFLOW-Komponente wurde in den FDPS integriert. Die Komponente ist eine flugplanverarbeitende Instanz und interagiert mit anderen Komponenten des FDPS oder auch den Displays durch das DMAP-Protokoll. Sog. \emph{Notifier}-Klassen implementieren das Observer Pattern für bestimmte Datensätze der DMAP-Datenbank. \emph{Storage}-Klassen bieten eine transparente Zugriffsschicht auf DMAP-Datensätze. Durch die beiden Klassentypen ist es möglich, Event-getrieben und dadurch effektiv auf der DMAP zu arbeiten und gleichzeitig jederzeit volle Zugriffsmöglichkeit mit Hilfe von transparenten Transaktionen auf alle notwendigen Datensätze zu haben.
    1.17 +Die DFLOW-Komponente wurde in den FDPS integriert. Die Komponente ist eine flugplanverarbeitende Instanz und interagiert mit anderen Komponenten des FDPS oder auch den Displays durch das DMAP-Protokoll. 
    1.18 +
    1.19 +Sog. \emph{Notifier}-Klassen implementieren das Observer Pattern für bestimmte Datensätze der DMAP-Datenbank. \emph{Storage}-Klassen bieten eine transparente Zugriffsschicht auf DMAP-Datensätze. Durch die beiden Klassentypen ist es möglich, Event-getrieben und dadurch effektiv auf der DMAP zu arbeiten und gleichzeitig jederzeit volle Zugriffsmöglichkeit mit Hilfe von transparenten Transaktionen auf alle notwendigen Datensätze zu haben.
    1.20  
    1.21  \subsection{Node Manager}
    1.22 -Der Node Manager ist für die Kontrolle der Vitalität der einzelnen PRISMA-Komponen\-ten zuständig. Basierend auf dem Watchdog-Verfahren werden Prozesse aktiv angesprochen um die Reaktionszeiten zu messen. Ist die Vitalität des Systems durch eine Komponente gefährdet, so kann der Node Manager den Neustart oder die Deaktivierung der identifizierten Komponente mit Fehlfunktion veranlassen. Der Node Manager bietet für dessen Protokoll eine Klasse an, die eine voll automatisierte Lösung des Watchdog-Verfahrens auf Client-Seite darstellt.
    1.23 +Der Node Manager ist für die Kontrolle der Vitalität der einzelnen PRISMA-Komponen\-ten zuständig. Basierend auf dem Watchdog-Verfahren werden Prozesse aktiv angesprochen um die Reaktionszeiten zu messen. 
    1.24 +
    1.25 +Ist die Vitalität des Systems durch eine Komponente gefährdet, so kann der Node Manager den Neustart oder die Deaktivierung der identifizierten Komponente mit Fehlfunktion veranlassen. Der Node Manager bietet für dessen Protokoll eine Klasse an, die eine voll automatisierte Lösung des Watchdog-Verfahrens auf Client-Seite darstellt.
    1.26  
    1.27  \subsection{AWP}
    1.28  Die AWP bietet eine Reihe strategischer Displays als integrierte Lösung an. Ein Planer hat u.a. die Aufgaben Flugpläne den Startern zuzuordnen, Prognosen über Verkehrsaufkommen zu analysieren und basierend darauf Entscheidungen zu treffen.