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