[FMFP] Restructure summary

2026-07-28 03:39:08 +02:00 · 2026-07-06 09:49:27 +02:00
parent 67500a14cb
commit 294363f3c8
66 changed files with 127 additions and 101 deletions
@@ -0,0 +1,23 @@
+\subsection{Model Checking}
+\begin{definition}[]{Model Checking}
+    Model checking is an automated technique that, given
+    a finite-state model of a system and a formal property,
+    systematically checks whether this property holds for
+    (a given state in) that model.
+\end{definition}
+
+Model checkers enumerate all possible states of a system, either through explicitly representing state through concrete values or symbolically through (boolean) formulas.
+
+They are primarily used to analyze system \bi{designs}, and not implementations and are often used to analyze deadlocks, the reachability of undesired states and protocol violations.
+
+
+\subsubsection{The Model Checking Process}
+The first and most important phase is the \bi{modeling phase}, where we model the system in the description language of the model checker (here Promela).
+It also includes formalizing the properties to be checked in said language.
+
+Next, we run the model checker to check the validity of the model. 
+In the case of this course, we use \texttt{spin}, and we can run a promela model using \texttt{spin -x <promela file>.pml},
+which wraps \texttt{spin -a <promela file>.pml}, \texttt{gcc <promela file>.c} and \texttt{./a.out} into a single command.
+
+After running, it is time to analyze the output of the model checker. If the property is violated, analyze the found conter example.
+If the mdeol is too large, it can happen that the checker runs out of memory. In that case, reduce the model and try again.
@@ -0,0 +1,17 @@
+\subsection{Promela}
+Promela has \texttt{C}-like syntax, and its main objects are processes, channels, and variables.
+
+An important consideration always is the number of states there are for each model, if spin can complete executing.
+
+The number of states is given by
+\[
+    \prod_{i = 1}^N (l(p_i) \times \prod_{\texttt{var} x_i \in p_i} |\texttt{dom}(x_i)|) \times \prod_{j = 1}^{K} |\texttt{dom}(c_j)|^{\texttt{cap}(c_j)}
+\]
+where $l(p_i)$ returns the number of program locations for process $i$, $|\texttt{dom}(x_i)|$ denotes the number of values a variable can take,
+$\texttt{dom}(c_j)$ denotes the number of values each message in the channel can take and $\texttt{cap}(c_j)$ returns the capacity of the buffer fo the channel.
+
+\shade{orange}{THUS:} \hl{Keep the model as small as possible} to prevent the above, which is called \bi{state space explosion}
+
+\newpage
+
+\inputcode{promela}{code/promela/00_basics.pml}
@@ -0,0 +1,23 @@
+\subsubsection{Expressions}
+Expressions in Promela can be:
+\begin{itemize}
+    \item Variables, constants, and literals
+    \item Structure and array accesses
+    \item Unary and binary expressions with operators. The operators correspond to the \texttt{C} operators
+    \item Function applications
+    \item Ternary operators / conditional expressions \texttt{E1 -> E2 : E3}
+\end{itemize}
+Promela has a number of built in functions, which are:
+\begin{multicols}{5}
+    \begin{itemize}
+        \item \texttt{len()}
+        \item \texttt{empty()}
+        \item \texttt{nempty()}
+        \item \texttt{full()}
+        \item \texttt{nfull()}
+        \item \texttt{run <proc>}
+        \item \texttt{eval()}
+        \item \texttt{enabled()}
+        \item \texttt{pcvalue()}
+    \end{itemize}
+\end{multicols}
@@ -0,0 +1,26 @@
+\subsubsection{Statements}
+The following statement types are supported by Promela:
+\begin{itemize}
+    \item \texttt{skip}: Does not change the state (except the location counter). Always executable
+    \item \texttt{assert(E)}: Aborts execution if \texttt{E} evaluates to zero, otherwise is equivalent to \texttt{skip}. Always executable
+    \item Assignment: \texttt{x = E} assigns value of \texttt{E} to variable \texttt{x}. For arrays, use \texttt{a[n] = E}. Always executable
+    \item \texttt{s1;s2} (Sequential composition): Executable if \texttt{s1} is executable
+    \item Expression statement: Evaluates expression \texttt{E}, executable if \texttt{E} evaluates $\neq 0$. \texttt{E} must be \bi{side effect free}.
+\end{itemize}
+
+In addition, selection statements (i.e. if / switch) and repetitions (loops) are supported:
+\begin{code}{promela}
+    if
+    :: s1 -> code;
+    :: s2 -> code;
+    :: code; // The else statement, executes if no other option executable
+    fi
+
+    do
+    :: s1 -> loop_body_1; // We can use this technique to combine if and loops
+    :: s2 -> loop_body_2;
+    :: else -> break;
+    od
+\end{code}
+
+Then, we have atomic statements, which has signature \texttt{atomic \{ s \}}, which executes \texttt{s} atomically.
@@ -0,0 +1,5 @@
+\subsubsection{Macros}
+Promela does \textit{not} support procedures. However, many of the effects (apart from recursion) can be achieved with macros.
+
+We define them using \mint{promela}|inline name(arg1, arg2) { /* body */ }|
+As is the case in \texttt{C}, they are simply replaced in the code and thus have no new variable scope, support no recursion and have no return value.
@@ -0,0 +1,102 @@
+% TOOD: Some more intuition
+\newpage
+\subsection{Linear Temporal Logic}
+\subsubsection{Transition System of a Promela Model}
+For the transition systems, compared to earlier, we use a fixed initial configuration because we only model one program or system,
+as opposed to all programs of a programming language, as previously.
+In addition, we omit terminal configurations from the definition, which simplifies the theory, and termination can be modelled by a transition into a special state,
+the \bi{sink state}, which only allows further transitions back to itself.
+
+
+\paragraph{Converting a Promela model into a transition system}
+
+The configurations are the states of the model, such as global variables and channels, as well as per active process the local variables, channels, and location counters.
+
+The initial configuration is the initial state of the model.
+
+The transition relation is defined by the operational semantics of the statements. They are kept informal in this course.
+
+A Promela model has a finite number of states, since there are a finite number of allowed active processes (255), as well as finite numbers of variables and channels,
+finite ranges of variables and finite buffers of channels.
+
+
+\shade{gray}{Computations}
+
+$S^\omega$ is the set of infinite sequences of elements of set $S$ and $s_{[i]}$ denotes the $i$-th element of the sequence $s \in S^\omega$
+
+$\gamma \in \Gamma^\omega$ is a \bi{computation} of a transition system if:
+\begin{itemize}
+    \item $\gamma_{[0]} = \sigma_I$
+    \item $\gamma_{[i]} \rightarrow \gamma_{[i + 1]}$ (for all $i \geq 0$)
+\end{itemize}
+Note that we use $\sigma$ to range over the states $\Gamma$ of a transition system. Here $\gamma_{[i]}$ denotes the $i$-th element in $\gamma = \sigma_0 \sigma_1 \ldots$
+
+We use $\cC(TS)$ to denote the set of all computations of a transition system $TS$
+
+
+
+\subsubsection{Linear Time Properties}
+LT-Properties can be used to specify the permitted computations of a transition system.
+A linear time property $P$ over $\Gamma$ is a subset of $\Gamma^\omega$, where $P$ specifies a particular set of infinite sequences of configurations.
+
+A transition system $TS$ \bi{satisfies} the LT-Property $P$ (over $\Gamma$), denoted $TS \models P$, if and only if $\cC(TS) \subseteq P$.
+Intuitively, this means that all computations of $TS$ belong to the set $P$.
+
+LT-Properties \bi{precisely} express properties of computations.
+Non-termination is handled using infinite sequences and non-determinism is handled by considering each computation separately.
+
+To make notation cleaner and quicker, we define \bi{atomic propositions} (AP) for a transition system $TS$, which is a proposition that does not contain any logical connectives.
+For example, $AP = \{ open, closed \}$ (for files).
+
+We then provide a \bi{labeling function} $L : \Gamma \rightarrow \cP(AP)$ that maps configurations to sets of atomic propositions from AP.
+$L(\sigma)$ is called an \bi{abstract state}. AP and $L$ are both considered to be \hl{part of the transition system}.
+
+
+\paragraph{Traces}
+A trace is an abstraction of a computation, which only observes the propositions of each state, not the concrete state itself.
+It is an infinite sequence of abstract states $\cP(AP)^\omega$.
+
+$t \in \cP(AP)^\omega$ is a trace of a transition system $TS$ if $t = L(\gamma_{[0]} L(\gamma_{[1]}) \ldots$ and $\gamma$ is a computation of $TS$.
+The set of all traces of $TS$ is $\cT(TS)$.
+The LT-Properties are typically specified over infinite sequences of abstract states, rather than over sequences of configurations.
+
+
+\paragraph{Safety Properties}
+\inlinedefinition An LT-property $P$ is a safety property if for all infinite sequences $t \in \cP(AP)^{\omega}$:
+if $t \notin P$ then there is a finite prefix $\hat{t}$ of $t$ such that for every $t'$ with prefix $\hat{t}$, $t \notin P$.
+
+\inlineintuition More informally, it \textit{does not allow anything bad to happen}. Or, more exhaustively, if a sequence $t$ is no allowed by the LT-property,
+then there exists a finite prefix $\hat{t}$, which contains everything that makes the sequence violate the LT-property.
+Thus, whatever sequence we append to it, it will always remain in violation of the property $P$.
+
+
+\paragraph{Liveness Properties}
+\inlinedefinition An LT-property $P$ is a liveness property if every finite sequence $\hat{t} \in \cP(AP)^*$ is a prefix of an infinite sequence $t \in P$
+
+\inlineintuition More informally, it states that \textit{something good will happen eventually}.
+Or, more exhaustively, if every finite sequence of atomic propositions can be extended to a sequence that is allowed by the LT-property.
+
+
+\paragraph{On proves and examples}
+Some remarks for common exam multiple-choice questions
+\begin{itemize}
+    \item Safety Property and Liveness Property: Only \texttt{true} is such an example
+    \item Neither: There are no examples, since every LT-property is a conjunct of a safety and liveness property and every LT-property can be rewritten as such a conjunct.
+\end{itemize}
+
+Typically, the exam includes questions on whether or not a given LT-property $\varphi$ is a liveness property, safety property or a conjunct of both.
+To determine that, use the following flow chart:
+\begin{center}
+    \begin{tikzpicture}[node distance = 0.5cm and 0.5cm, >={Classical TikZ Rightarrow[width=7pt]}]
+        \node (start) {Is $\varphi$ safety property?};
+        \node (safety) [below left=of start] {Safety Property};
+        \node (isliveness) [below right=of start] {Is $\varphi$ a liveness property?};
+        \node (liveness) [below left=of isliveness] {Liveness Property};
+        \node (conjunct) [below right=of isliveness] {Conjunct};
+
+        \draw[arrows = ->, distance = 1.5pt] (start) -- node [above left] {\scriptsize Yes} (safety);
+        \draw[arrows = ->, distance = 1.5pt] (start) -- node [above right] {\scriptsize No} (isliveness);
+        \draw[arrows = ->, distance = 1.5pt] (isliveness) -- node [below right] {\scriptsize Yes} (liveness);
+        \draw[arrows = ->, distance = 1.5pt] (isliveness) -- node [below left] {\scriptsize No} (conjunct);
+    \end{tikzpicture}
+\end{center}
@@ -0,0 +1,52 @@
+\subsubsection{Linear Temporal Logic}
+This is used to formalize LT-properties of traces.
+
+\paragraph{Operators}
+The basic operators are, with $p$ a proposition from $AP \neq \emptyset$ and $\Phi$ and $\Psi$ LTL formulas:
+\begin{itemize}
+    \item $p$ states that it is true ``\textit{now}''
+    \item $\Phi U \Psi$ states that $\Phi$ holds ``\textit{until}'' $\Psi$ holds. I.e. there are no other valid propositions that hold in between.
+    \item $\bigcirc \Phi$ states that the $\Phi$ holds for the ``\textit{next}''
+\end{itemize}
+
+
+\paragraph{Semantics}
+$t \models \Phi$ expresses that a trace $t \in \cP(AP)^\omega$ satisfies the LTL formula $\Phi$
+\begin{multicols}{2}
+    \begin{itemize}
+        \item $t \models p$ if and only if $p \in t_{[0]}$
+        \item $t \models \neg \Phi$ if and only if not $t \models \Phi$
+        \item $t \models \Phi \land \Psi$ if and only if $t \models \Phi$ and $t \models \Psi$
+        \item $t \models \Phi U \Psi$ if and only if there is a $k \geq 0$ with $t_{(\geq k)} \models \Psi$ and $t_{(\geq j)} \models \Phi$ for all $j$ with $0 \leq j \leq k$
+        \item $t \models \bigcirc \Phi$ if and only if $t_{(\geq 1)} \models \Phi$
+    \end{itemize}
+\end{multicols}
+
+
+\paragraph{Derived operators}
+There are a number of handy derived operators defined here that we can use, unless otherwise specified.
+\begin{itemize}
+    \item Eventually: $\Diamond \Phi \equiv (\texttt{true}\; U \Phi)$
+    \item Always (from now on): $\Square \Phi \equiv \neg \Diamond \neg \Phi$
+\end{itemize}
+
+Precedences are unary operators (such as $\Diamond \Phi \Rightarrow \Psi$ means $(\Diamond \Phi) \Rightarrow \Psi$), but we use parenthesis to avoid ambiguities.
+
+
+\newpage
+\paragraph{Useful patterns}
+\begin{itemize}
+    \item Strong invariant $\square \Psi$: $\Psi$ always holds and this is a safety property if $\Psi$ is a safety property.
+          For instance, a file is always open or closed ($\square(\texttt{open} \lor \texttt{closed})$)
+    \item Monotone invariant $\square(\Psi \Rightarrow \square \Psi)$: Once $\Psi$ is \texttt{true}, it will always be \texttt{true}.
+          It is a safety property if $\Psi$ is a safety property.
+          For instance, once information is public, it can never be private again ($\square(\texttt{public} \Rightarrow \square \texttt{public}$)
+    \item Establishing an invariant $\Diamond \square \Psi$: Eventually, $\Psi$ will \textit{always} hold. It is a liveness property if $\Psi$ is satisfiable.
+          For instance, system initialization starts server ($\Diamond \square \texttt{serverRunning}$)
+    \item Responsiveness $\square(\Psi \Rightarrow \Diamond \Phi)$: Every time that $\Psi$ holds, $\Phi$ will eventually hold.
+          It is a liveness property if $\Phi$ satisfiable.
+          For instance, all opened files must be closed eventually ($\square(\texttt{open} \Rightarrow \Diamond \texttt{closed})$)
+    \item Fairness $\square \Diamond \Psi$: $\Psi$ holds infinitely often.
+          It is a liveness property if $\Psi$ is satisfiable.
+          For instance, a producer does not wait infinitely long before entering the critical section ($\square \Diamond \texttt{critical}$)
+\end{itemize}