Experience in developing the mCRL2 toolset

J.F. Groote J.J.A. Keiren F.P.M. Stappers J.W. WesselinkT.A.C. Willemse

Department of Mathematics and Computer ScienceTechnische Universiteit Eindhoven

22 February 2010

1/20

mCRL2, what is it?

Toolset for verification of software

Process algebra based

Explicit state model checking + symbolic transformations

Support for modal µ-calculus with data + time

2/20

mCRL2, overview

3/20

Example

Process that merges two streams of natural numbers, producing alocally ascending output sequence

356

8 5 1

152

r1

Merge s

r2

4/20

Example: specification

356

8 5 1

152

r1

Merge s

r2

Merge =∑m : N. (r1(m) ·Merge1(m)

+r2(m) ·Merge2(m))Merge1(n : N) =

∑m : N. r2(m) ·Merge3(n,m)

Merge2(m : N) =∑n : N. r1(n) ·Merge3(n,m)

Merge3(n,m : N) = n 6 m→ s(n) ·Merge2(m)+m 6 n→ s(m) ·Merge1(n)

5/20

Example: linear process

356

8 5 1

152

r1

Merge s

r2

Merge(σ, i1, i2 : N)= ∑

m : N. σ = 0→ r1(m) ·Merge(2,m, i2)+

∑m : N. σ = 0→ r2(m) ·Merge(1, i1,m)

+∑m : N. σ = 1→ r1(m) ·Merge(3,m, i2)

+∑m : N. σ = 2→ r2(m) ·Merge(3, i1,m)

+∑m : N. σ = 3 ∧ i1 6 i2 → s(i1) ·Merge(1, i1, i2)

+∑m : N. σ = 3 ∧ i2 6 i1 → s(i2) ·Merge(2, i1, i2)

6/20

Example: property

356

8 5 1

152

r1

Merge s

r2

If the input streams are ascending, then the output stream isascending.Modal formula:

(νX(j1, j2, o:N := 0, 0, 0).∀l:N. ([r1(l)](l ≥ j1 ⇒ X(l, j2, o))∧[r2(l)](l ≥ j2 ⇒ X(j1, l, o))∧[s(l)](l ≥ o ∧X(j1, j2, l))))

7/20

Example: parameterised Boolean equation system

Combining LPS and formula, and applying simplifications, we get

νX(σ, i1, i2, j1, j2, o:N) = ∀l:N(σ = 0⇒ l ≥ j1 ⇒ X(2, l, i2, l, j2, o))∧(σ = 0⇒ l ≥ j2 ⇒ X(1, i1, l, j1, l, o))∧(σ = 1⇒ l ≥ j2 ⇒ X(3, i1, l, j1, l, o))∧(σ = 2⇒ l ≥ j1 ⇒ X(3, l, i2, l, j2, o))∧((σ = 3 ∧ i1 ≤ i2)⇒ (i1 ≥ o ∧X(1, i1, i2, j1, j2, i1)))∧((σ = 3 ∧ i2 ≤ i1)⇒ (i2 ≥ o ∧X(2, i1, i2, j1, j2, i2))))

Observe that i1 = j1 ∧ i2 = j2 ∧ o ≤ min(i1, i2) is an invariant, nowthis can automatically be solved, and the property holds forMerge(0, 0, 0)

8/20

History of mCRL2

Based on µCRL

Development started in 2004, using code from µCRL

22 developers with commit access

Currently 240949 Lines of code (obtained using SLOCcount)

9/20

Process related issues

1 Rapid turnover of resources

2 Programming not 1st priority

Three kinds of developers:

Scientific programmers: long period of time (3+ years),dedicated time available

(Bachelor + Master) students: short period of time (3-6months), little time for programming

Other staff: long period of time (3+ years), little time forprogramming, not 1st priority

Leads to single components that have been modified by 10 people indisjoint time spans

10/20

Commits made per developer

11/20

Consequences

Poorly documented code

Lack of user documentation

Most code not maintained by original author(s)

Multiple ad-hoc solution attaining same goal; code duplication

Little attention for refactoring/restructuring code

12/20

Code base related issues

1 Adopting an existing code base

Fixes major design choicesBased on ATerm library (having untyped interfaces)Low level of abstractionInheriting other people’s choices/bugsPoorly programmed (heavy use of unsafe type casts)

13/20

Code base related issues

2 Poor documentation of code

Hardly any explicit documentation; choices exists in developer’smindsBig trouble when developers leave!

3 Supporting multiple platforms

Was problematic with legacy code

14/20

Lessons learned

1 Document properlyFour kinds of documentation:

1 User documentation (aimed at tool users)2 User documentation (aimed at library users)3 Source code documentation (using Doxygen)4 Algorithm documentation (detailed algorithm descriptions)

Documentation is reviewed by another developer

Results:

Decrease learning curve for new developersDecrease source code duplication

15/20

Lessons learned

2 Perform systematic tests

New components are equipped with unit testsUnit test added for each bugPerformance of tools monitored using real-life examplesTests and performance measurements run automatically on adaily basis, with web reports availableFor performance measurements: historic data, observe trends

16/20

Online regression test results

17/20

Online performance measurements

0

50

100

150

200

250

300

350

4000 4500 5000 5500 6000 6500 7000 7500

Use

r +

Sys

tim

e (s

ec)

SVN Revision

Time consumption of lps2lts -rjittyc

1394-finabp

allowblock

brpcabp

chatboxclobberdining8

domineeringlift3-final

lift3-initmagic_square

othello

18/20

Lessons learned

3 Enhance reusability of code

Generate code from smaller specificationsUse high level of abstraction:

Transition legacy code from C to C++Use object oriented techniquesUse generic programming techniques (now + future)

4 Use generic, cross-platform libraries (BOOST, wxWidgets)

5 Strictly adhere to C++ standard

19/20

Future directions

Systematically generating code from specifications (started)

Allow flexibility in supported input languageAvoid tedious handwriting of uniform sections of codePrevent typo’s and copy-paste mistakes

Perform testing with random inputs

Increase use of generic programming techniques

20/20