Lecture 4: Various Formal Methods Luigia Petre

Åbo Akademi University, Turku, Finland Faculty of Technology

Department of Information Technologies

Availability and Formal Methods for Dependable Systems

Remainder from the plan 26.4: Availability Classical (measurable) availability Constructive availability Service availability

27.4: Formal methods and availability Several classical formal methods Action systems Network availability with action systems Exercises..

Starting point

Software-based systems Embedded in multiple fields Financial, commercial, medical, nuclear, etc

More and more complex We are software dependent We need systematic methods of construction We need dedicated verification methods

Formal Methods Fault-avoidance (prevention) techniques for constructing

trustworthy systems Consist of a specification language and a construction

and/or verification method Mathematical basis Specification language Based on logics and mathematics (has SEMANTICS!!) Allows the devising of models for the system to be built by

using a specific syntax Construction/verification method can allow The specification of the required properties for verifying that

A model correctly captures a set of requirements A more detailed model correctly develops a less detailed model of the

same system Various analysis types based on the devised models

Some formal methods CSP (Communicating Sequential Processes) CCS (Calculus of Communicating Systems) π-calculus

Ambient calculus UNITY Z B Action systems

CSP For modeling concurrent systems formal language for describing patterns of

interaction in concurrent systems CSP system = a set of processes Each process has its own interface of events and

typed channels Events: for process synchronization Channels: for data communication among channels

Operational semantics Transition rules for each process type

Denotational semantics Traces (special sequences of events)

Constructing CSP systems CSP specifications Describe the allowed behavior of the processes

CSP implementations Describe the actual behavior of the processes

Trace-based refinement Ensure that every trace of an implementation is also

a trace of the corresponding specification

CSP Extensions For hybrid systems and for time-dependent

systems Timed CSP: continuous model of time Tock – regularly marks the passing of time Tools

Software tools Model checker FDR Animator ProBE

Original CSP In Hoare's original 1978 paper: essentially a concurrent

programming language Substantially different syntax than later versions of CSP Did not have mathematically defined semantics Unable to represent unbounded nondeterminism Programs in the original CSP:

a parallel composition of a fixed number of sequential processes

communicating with each other strictly through synchronous message-passing

each process was assigned an explicit name the source or destination of a message was defined by

specifying the name of the intended sending or receiving process

Original CSP example

COPY = *[c:character; west?c → east!c]

[west::DISASSEMBLE || X::COPY || east::ASSEMBLE]

Process algebraic CSP CAR Hoare, Stephen Brookes, A. W. Roscoe

developed and refined the theory of CSP into its modern, process algebraic form

Influenced by Milner’s work on CCS and vice versa 1984: paper on the theory of CSP, 1985: book Third most cited computer science reference in 2006

(source citeseer) changes to the theory motivated by the advent of

automated tools for CSP process analysis and verification Theory and practice of CSP (1997)

CSP Primitives Events communications or interactions indivisible and instantaneous atomic names (e.g. on, off), compound names (e.g.

valve.open, valve.close), or input/output events (e.g. mouse?xy, screen!bitmap)

Primitive processes: fundamental behaviours STOP (the process that communicates nothing, also called

deadlock) SKIP (successful termination).

The CSP formalism

The evolution of processes is based on a sequence of events or actions Visible actions Σ

Interaction with other processes, communication

Invisible action τ Internal computation steps

The CSP language: Syntax Inaction: Stop

Termination, deadlock, incapability of performing any action, either internal or external

Input: in ? x : A P(x) Execute an input action on channel in, get message x of type A,

then continue as P(x) Output: out ! m P(x)

Execute an output action on channel out, send message m, then continue as P(x)

Recursion: P(y1,…,yn) = Body(y1,…,yn) Process definition. P is a process name, y1,…,yn are the

parameters, Body(y1,…,yn) is a process expression

Example: Copy = in ? x out ! m Copy

The CSP Syntax

External (aka guarded, deterministic) choice: P [] Q Execute a choice between P and Q. Do not choose a process

which cannot proceed

Example: (a ? x P(x)) [] (b ? x Q(x)) Execute one and only one input action. If only one is available

then choose that one. If both are available than choose arbitrarily. If none are available then block. The unchosen branch is discarded (commitment)

Internal choice (non-deterministic): P + Q Execute an arbitrary choice between P and Q. It is possible to

choose a process which cannot proceed

The CSP Syntax Parallel operator w/synchronization: P || Q

P and Q proceed in parallel and are obliged to synchronize on all the common actions

Example: (c ? x P(x)) || (c ! m Q) Synchronization: the two processes can proceed only if their

actions correspond Handshaking: sending and receiving is simultaneous (clearly an

abstraction. Buffered communication can anyway be modeled by implementing a buffer process)

Communication: m is transmitted to the first process, which continues as P(m).

Broadcasting: c ! m is available for other parallel processes P ||AQ

P and Q are obliged to synchronize only on the common actions in A They interleave on all the actions not in A

The CSP Syntax Interleaving P ||| Q

completely independent concurrent activity behaves as both P and Q simultaneously the events from both processes are arbitrarily interleaved in time

Hiding: P \ A P \A behaves as P except that all the actions in A are

turned into invisible actions. So they cannot be used anymore to synchronize with other processes.

One possible use of this mechanism is to avoid that external processes interfere with the communication channels in P. (Internalization of communication in P.)

Renaming: P[y/x] P[x/y] behaves as P except that all the occurrences of x

are renamed by y. Typically this serves to create different instances of the

same process scheme

Communicating Systems ? Two related questions: What is a function? Sequential machines Models for computation: lambda-calculus

What is a process? Coffee Machines, Xboxes, distributed systems. Models for interaction: CCS/CSP [80s], Pi [90s]

How to model concurrent behaviours? How to describe processes in a compositional manner? When are two processes equivalent?

Divergence is not necessarily bad. Operational, rather than denotational.

Why Using a Calculus ? A calculus, rather than a purely descriptive model “Calculate” = reason on processes

in a systematic manner using equations. State and prove correctness properties. Reuse basic tools, such as observational

equivalences and proof techniques.

.

CCS Also for modeling concurrent systems CCS system: parallel composition of processes They can synchronize and communicate by using

pre-established links π-calculus CCS extension Links can communicate values AND links First technique for modeling mobility

Mini CCS

Examples Reduction

Value-Passing CCS

Interaction on free channels, as before Convenient, but not essential: could use more channels

The Pi Calculus

Channel names can be communicated Communication becomes dynamic

Name Mobility “The dynamic creation of new links between active

processes” [Milner]

At a suitable level of abstraction, the location of a process is determined by its links to other processes.

CCS and π-calculus: semantics and constructing systems Operational semantics Labeled transition systems Many variants

Constructing systems We can develop abstract and concrete models Bisimilarity (weak and strong) Behavioral equivalence Ensures that 2 models correspond to each other

Extensions and software for π-calculus Many extensions Exp: OO based on a type system in terms of sorts

Software tools Model checker Mobility WorkBench Verifies also bisimilarity properties

Programming languages based on π-calculus Pict, Nomadic Pict, Piccola

Semantic model for concurrent calculus

Ambient calculus For modeling computations over Internet Ambient Administrative domain in Internet Place where various computations take place Can contain sub-ambients or be contained in a

parent-ambient Sibling ambients can communicate locally Mobility – most important feature Need to cross barriers Stepwise

Mobility postulates Separate locations exist. They may be difficult to

reach. Since different locations have different properties,

both people and programs (and sub-locations!) will want to move between them.

Barriers to mobility will be erected to preserve certain properties of certain locations.

Some people and some programs will still need to cross those barriers.

This is the situation Wide-Area Languages have to cope with

The web

Mobile Computing Mobile devices also move computations. In this

sense, we cannot avoid the issues raised by mobile computation.

Modeling mobility It’s all about barriers: Locality = barrier topology. Process mobility = barrier crossing. Security = (In)ability to cross barriers. Interaction by shared position within a barrier, with

no action at a distance.

Formalisms for concurrency/distribution CSP/CCS. (Static/immutable connectivity.) π-calculus. (Channel mobility.) N.B. "mobility" in this context is not process mobility. Process mobility is reduced to channel mobility.

Ambient Calculus: Process mobility = Barrier crossing.

In π In the π-calculus (our starting point): processes exist in a single contiguous location interaction is by shared names, used as I/O

channels there is no direct account of access control

In ambient calculus: processes exist in multiple disjoint locations interaction is by shared position, with no action at a

distance capabilities, derived from ambient names, regulate

access

Ambients Capture in an abstract way: notions of locality, of

mobility, and of ability to cross barriers. An ambient is a place, delimited by a boundary,

where computation happens. Ambients have a name, a collection of local

processes, and a collection of subambients. Ambients can move in an out of other ambients,

subject to capabilities that are associated with ambient names.

Ambient names are unforgeable (as in π).

The ambient calculus

An entry capability

Exit capability

Open capability

Enter reduction

Exit reduction

Open reduction

Ambient calculus: semantics and analysis methods Operational semantics Can express both π-calculus as well as λ-

calculus Expressing properties Communication and mobility types Ensure that communication is correct (well-typed) Mobility can be restricted if desired

Decidable modal logic Model checking for various process properties

(More complex) modal logic for mobility Can express time and space Mobility: change of spatial configurations over time

UNITY State-based formalism for modeling distributed

systems System state

Described by variables Modified by conditional assignments An assignment can be chosen for execution only when its

guarding condition holds Choosing between several executable assignments is weakly

fair UNITY system: more programs

Homonym variables are shared Assignments can execute synchronously or asynchronously

UNITY: semantics and constructing systems Denotational semantics Transition systems

Reasoning about programs Temporal logic: safety and liveness properties can

be expressed and proved wrt the UNITY models Structuring techniques Union and superposition refinement

Mobility in UNITY Mobility Mobile UNITY: specialization of UNITY Programs have “location” variables Specialized conditional assignments execute as

long as their conditions hold centralized “Interactions” section coordinates the

programs The section contains the sharing and synchronization

conditions Dynamic style of computing

Context in UNITY Context-UNITY Specialized version of Mobile UNITY Models environment-sensitive applications “Interactions” section replaced by several “Context”

sections One per program Contain coordination rules

Very flexible systems can be modeled

Z Oldest state-based formalism Modeling systems based on abstract data

types Z-System: variables and operations Variables have types, invariants and initializations Operations are expressed as predicates describing

the system state before and after the operation Z-Schemas (syntactical structures)

Semantics and analysis in Z Semantics based on values Schema S corresponds to θS θS – characteristic binding of S Each declared component is associated with its current

value

Proofs and refinements Based on set theory and logics

Extensions of Z Timed refinement calculus

Z extended with total continuous functions of time Object-Z

Enhances the structuring of Z specifications Class-schema contains all the schemas concerning an

abstract data type Refinement of classes with simulation techniques Reference-based semantics

Variables refer values instead of directly representing them Extra semantics in terms of transition systems

Combinations Timed refinement calculus and Object-Z Object-Z and CSP (and their timed extensions)

B State-based formalism for Modeling, refinement, validation, and

implementation of software systems B specification unit: abstract machine Variables and operations that can evaluate and

modify variables Invariants: Constrain variables Must be preserved by the operations

Modularity, validation and refinement in B Fundamental features of B Modularity System: a collection of machines that are

independently developed Refinement Algorithmic or data refinement

Validation Discharging the proof “obligations” generated in the

refinement process

B supported by software tools Validation Highly automated due existing associated tools

(theorem provers) Atelier-B and B Toolkit

Many proof obligations are discharged automatically by the software

The remaining obligations can be interactively proved

When all the proof obligations are discharged code can be generated in C or ADA

Semantics and extensions in B Semantics Based on an extension of the weakest-precondition

calculus, set theory, logics Extensions Distributed and reactive systems (Event-B) Complex systems (software and hardware)

Event-B A formalism with its roots in the B Method and the

Action Systems framework Development is stepwise from abstract

specification to concrete implementation Models contain static parts, contexts, and

dynamic parts, machines Machines contain variables, invariants, and

events that evaluate and modify variables

Example

Event-B To achieve a reliable system we use

superposition refinement We add new variables and functionality without

disturbing the previous functioning Each step of the refinement process is proven

mathematically The Rodin Platform provides integrated support

for modelling and proving

Conclusions We have plenty of formal tools to choose from They can model “anything” How to choose? Integrate formal methods? (UML?)

Do they scale? Do they have associated tools?

The motto

The sciences do not try to explain, they hardly even try to interpret, they mainly make models.

John von Neumann

Assignments 1. Describe the fundamental concepts behind

availability and discuss the relationships between the various availability approaches (1-2 pages)

2. What do the components of the service availability measure X=(X1, X2) stand for? Elaborate in 0.5 pages.

3. Write a short essay with the following topic: “Formal methods for dependable system development” (1-2 pages)