Guest editors' introduction: Special issue on Probabilistic Techniques for the Design and Analysis of Systems
The Journal of Logic and Algebraic Programming
Verification techniques as used traditionally focus on the functional behaviour of a system. This means that a system designer can detect an error in the system, claim that the system is deadlock free, or can say that eventually the system leaves the critical section, terminates or that the message is delivered. But in real-life systems not only functionality but also quantitative aspects of system behaviour are important. These quantitative aspects could be inherent to the algorithm, to the
... ironment where the system is located, or part of the specification requirements. In recent years, we have seen much progress in the specification, modeling and analysis of probabilistic behaviour. On the one hand, the so-called randomized algorithms, that is, algorithms that take decisions by tossing a coin rather than only based on collected information, give more efficient solutions than traditional (non-)deterministic ones, or even give solutions which are impossible within the non-deterministic world. For example, Aspnes and Herlihy's randomized consensus protocol proposes a polynomial solution to an otherwise exponential problem, and the leader election protocol within the IEEE 1394 'Firewire' solves the problem of electing a leader among several symmetric nodes without (unique) identification which has no solution otherwise. On the other hand, correctness properties for a given system can only be expressed in a quantified manner. For example, a usual correctness property for a protocol is "every message sent by the sender client is eventually received by the receiver client". Nevertheless, a bounded retransmission protocol would never satisfy this property since, after a bounded number of attempts, transmission is aborted. However, by including the loss probability of the transmission medium in the system model, a quantified correctness property could instead be required. For instance "every message sent by the sender client is eventually received by the receiver client with probability greater than 0.99". On the line of this second case, we can consider properties that refer to the performability (i.e. performance + dependability) of the system under study. Examples of these kind of properties are the throughput of job processing system or the average time a production plant is up and running.