UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine1 CSE 503 – Software Engineering Lecture 7: Process calculi and refinement Rob DeLine 19 Apr 2004

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine2 From model checking to math Promela describes concurrent, communicating processes  we use it to describe whole (closed) systems  no support for compositional reasoning Spin checks properties encoded in LTL  very rich properties, but hard for non-experts to understand  for example (from Dwyer et al): “S precedes P after Q” □  Q  ◊ (Q  (  P U (S  □  P))) Process calculi can address both these shortcomings  provide a way to reason about processes in isolation  check whether a process “behaves like” another (simpler) process also  provide a foundational computing model like Turning machines  form a huge intellectual field, which we will sample

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine3 Reasoning about processes We want a conformance relation ≤ that supports...  Substitutability Impl ≤ Spec  Spec|P is “safe”  Impl|P is “safe” (any P)  Modular reasoning Impl 1 ≤ Spec 1  Impl 2 ≤ Spec 2  (Impl 1 |Impl 2 ) ≤ (Spec 1 |Spec 2 ) Substitutability  Reasoning about Spec is easier than reasoning about Impl  Spec can be treated as a contract by anyone implementing P Modular reasoning  The process Impl 1 |Impl 2 can be too large for model checking  If Spec 1 |Spec 2 is “safe” then so is Impl 1 |Impl 2 We define conformance precisely in a process calculus

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine4 Process calculi: a healthy competition CSP Communicating Sequential Processes Invented by Tony Hoare Semantics based on traces Has many applications in the SE research community CCS Calculus of Communicating Systems Invented by Robin Milner Semantics based on transition rules Famously led to the π calculus Precisely capturing the differences between them is still an open problem!

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine5 Biggest difference: nondeterminism Do these two machines “behave” the same? a a a a b c a c b Do they have the same traces? the same refusals? (refusals are the actions the machine will not take in a given state) Does the difference matter?

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine6 The difference might matter if the machine is Milner’s drink machine CCS distinguishes these machines, CSP does not We’ll study CCS in order to use Zing’s conformance 2p tea coffee 2p coffee tea

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine7 CCS processes P ::= 0 A α.P α.P P|Q new a P with equations A(a 1,...,a n ) = P and labels L = {a,b,c,...,a,b,c,...} α in L + {τ} (similar Promela definition) proctype Zero () { } proctype Call () { run A(a1,...,an); } proctype Choice () { if ::... :: fi } proctype Para () { run P(); run Q(); } proctype Hide () { chan c = [n]of{t}; run P(c); }

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine8 Label decorations Labels a and a are flip sides of the same action  This is the single form of process coordination in CCS  E.g. a = read and a = write, a = send and a = receive Picture the button on our drink machine pushing the button is one action seen from two perspectives

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine9 Internal vs external choice Who determines what a process does next?  The process itself? P = τ.Q + τ.R + τ.S P = Q # R # S (in paper)  Or the environment? P = a.Q + b.R + c.S CSP also makes this distinction: P □ Q vs P ┌┐ Q proctype P () { if :: run Q(); :: run R(); :: run S(); fi } proctype P () { int x; if :: a?x -> run Q(); :: b?x -> run R(); :: c?x -> run S(); fi }

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine10 Example: drink machines A = 2p.B B = tea.A + 2p.C C = coffee.A W = τ.W1 + τ.W2 W1 = 2p.X W2 = 2p.Y X = 2p.Z Y = tea.W Z = coffee.W 2p tea coffee A B C 2p coffee tea W X Y Z 2p coffee tea W2 X Y Z W W1 τ τ A(2p,tea,coffee) = 2p.B B(2p,tea,coffee) = tea.A + 2p.C C(2p,tea,coffee) = coffee.A

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine11 CCS definition 1/2 The syntax distinguishes processes that are really “the same” Structural congruence (  ) defines that “sameness”  new a P  new b (P[b/a]) (alpha conversion, a free in P)  P + Q  Q + P(reorder terms in sum)  P|0  P  P|Q  Q|P  P|(Q|R)  (P|Q)|R  new a (P|Q)  P|(new a Q)(a not free in P)  new a 0  0  new a new b P  new b new a P

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine12 CCS definition 2/2 Labeled transition system defines operational semantics

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine13 Processes shouldn’t get “stuck” Informally, a process is stuck if  It wants to do an input and no other process can do the dual output  It wants to do an output and no other process can do the dual input  (The latter is particularly interesting for error codes.) Formally, process P stuck on ã if  new a P is an end-state (no applicable transition rules)  exists label λ and process P’ such that P  P’ and λ or λ in ã  where ã is a sequence of labels Stuck-free is our “safe” condition for conformance Impl ≤ Spec  Spec|P is stuck-free  Impl|P is stuck-free (any P) λ

UW CSE 503 ▪ Software Engineering ▪ Spring 2004 ▪ Rob DeLine14 Definition of conformance P ≤ Q is the largest relation such that  If P  P’, then exists Q’ such that Q  Q’ and P’ ≤ Q’  If P can refuse X while ready on Y, then Q can refuse X while ready on Y where P refuses X  L iff  P is stable (no P’ such that P  P’   {a | P  P’ for some P’ } & { a | a  X } =  P can refuse X iff  exists P’ s.t. P  P’ and P’ refuses X P ready on Y (for singleton or empty Y) iff  P is stable  exists P’ such that P  P’ for λ in Y a τ* λ τ* τ τ* λ λ