mCRL2 is a language with a toolset for formal analysis of behaviour of concurrent systems. It is developed in an academic research group to support process algebra based verification in an academic as well as an industrial setting. This paper provides an insight into the experiences and practises in developing and maintaining the mCRL2 toolset

Groote, J.F.

Keiren, J.J.A.

Stappers, F.P.M.

Wesselink, J.W.

Willemse, T.A.C.

English

Pure OAI Repository

 Experience in developing the mCRL2 toolsetCitation for published version (APA):Groote, J. F., Keiren, J. J. A., Stappers, F. P. M., Wesselink, J. W., & Willemse, T. A. C. (2010). Experience indeveloping the mCRL2 toolset. In F. Gervais, & B. Fraikin (Eds.), Informal Proceedings of the 1st Workshop onTool Building in Formal Methods (TBFM'10, Orford, Québec, Canada, February 22, 2010; in conjunction withABZ 2010) (pp. 1-3)Document status and date:Published: 01/01/2010Document Version:Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)Please check the document version of this publication:• A submitted manuscript is the version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and pagenumbers.Link to publicationGeneral rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.            • Users may download and print one copy of any publication from the public portal for the purpose of private study or research.            • You may not further distribute the material or use it for any profit-making activity or commercial gain            • You may freely distribute the URL identifying the publication in the public portal.If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverneTake down policyIf you believe that this document breaches copyright please contact us at:openaccess@tue.nlproviding details and we will investigate your claim.Download date: 16. Nov. 2023Experience in developing the mCRL2 toolsetJ.F. Groote, J. Keiren, F.P.M. Stappers, J.W. Wesselink, and T.A.C. WillemseTechnische Universiteit EindhovenDepartment of Mathematics and Computer ScienceP.O. Box 513, 5600 MB Eindhoven, The Netherlands{j.f.groote, j.j.a.keiren, f.p.m.stappers, j.w.wesselink,t.a.c.willemse}@tue.nlIntroduction mCRL2 is a language with a toolset [3] for formal analysis of behaviourof concurrent systems. It is developed in an academic research group to support processalgebra based verification in an academic as well as an industrial setting. This paperprovides an insight into the experiences and practises in developing and maintainingthe mCRL2 toolset.History. Experience in applying the µCRL toolset [1] to real world systems uncoveredmajor shortcomings. These shortcomings led to the development of the richer modellinglanguage mCRL2, with its associated toolset, in 2002. A motivation for the developmentof mCRL2 is described in [2]. In an attempt to keep development effort to a minimum,code from µCRL was reused with minimal changes required to support the extendedlanguage.The decision to reuse µCRL code fixed important design decisions like the use ofC code in the project, and the use of ATerm library [4] based data structures for thepurpose of maximal subterm sharing.In this paper we identify the challenges in the development process, and describethe development principles and coding mechanisms that we have adopted.Development and maintenance issues In an academic environment, people tend tocome and go in quick succession. Additionally writing scientific papers instead of writ-ing code is core business. This introduces the following maintenance problems in thedevelopment process:– documentation solely exists in the minds of the developers;– code written by other developers needs to be maintained and debugged;In general these issues turn out to be time consuming, especially if one takes into ac-count that the code base consists of 273864 lines of code in 1214 files, contributed byover 20 developers. Some components have been substantially modified by 10 or moredevelopers in disjoint time spans. Changes in core components of the mCRL2 toolsethave caused bugs that remained undetected for extensive periods of time. Similarly,small changes have shown to cause dramatic decreases in performance of the tools.We can identify the following problems in our code base:– we adopted existing C code, based on the ATerm library, with untyped interfaces,low abstraction level and heavy use of unsafe type casts;– interfaces of the µCRL code were not well-documented;2– portability issues in the existing code obstructed our ambition to have the mCRL2toolset available as a cross-platform tool.The combination of these issues induces a steep learning curve for new developers,often requiring assistance from more experienced developers. The lack of documen-tation, a high level interface, and general purpose algorithms inadvertently led eachdeveloper to introduce his own ad-hoc solution for general problems, and this led toa copy-paste-adjust mentality. Generalising these ad-hoc implementations into a singleimplementation has shown to be virtually impossible without major changes to the al-gorithms that use them. On the other hand generalised implementations are required tomake progress in implementing new or overhauled parts of the code. Overcoming theseissues badly constrains development of new features, and hence the ability to closelyfollow developments in the theory. An additional issue introduced by the large amountof code duplication is lack of consistent behaviour between tools.Adopted process and coding guidelines Based on the issues that we have observed,we give an insight in the development guidelines we have since adopted.One of the main issues that we have run into process-wise is the lack of documenta-tion. To address this issue, developers are required to explicitly design their componentsprior to implementing. Furthermore the implementation needs to be accompanied withextensive source code and interface documentation.1 To make sure that all documen-tation is of sufficient quality, it is now reviewed by at least one other developer. Styledifferences among code from various authors are reduced using coding guidelines.In the development of a formal methods toolset correctness, reliability and per-formance are key issues. Therefore developers are required to write unit tests for thecomponents they implement. Furthermore bug fixes must always be accompanied withtests that show the bug is fixed. All tests are run on a daily basis on all supported plat-forms. We experienced that changes in the core of the toolset can have an unanticipatedbut vast effect on the performance of individual tools, hence we run the core tools inour toolset on a selection of examples on a daily basis. Historical running times areaccumulated for comparison. This data is used to examine tool performance trends overtime.On source code level we have run into the following issues: (1) the compiler notassisting us in finding straightforward mistakes in the code because of the untyped in-terfaces, (2) duplication of code, and (3) the lack of cross-platform support. These issueshave been addressed by transitioning the code to C++. This addressed our problems asfollows. A framework of C++ classes and interfaces was designed for the most commondata structures and algorithms. This allows the compiler to do stricter checking on types.All new code has been written using this framework, leading to more comprehensiblecode at a higher abstraction level. A lot of existing code has gradually been adapted touse this framework, or whenever necessary been rewritten from scratch. By now thereare only a few pieces of code that still need to be migrated. In this migration process alot of duplicate code has been removed. The most striking example of this is the newimplementation of our tools. Every tool in our toolset is a class which inherits from1 Note that all documentation, and test and performance measurement results that we mentionare available through the project website (http://www.mcrl2.org)3an abstract base class that implements parsing command line arguments, printing helpmessages, as well as some default options. This reuse reduced the code base by severalthousand lines of code, and enabled a uniform treatment of command-line argumentsacross the tools. By using external libraries that are available for all supported plat-forms, and by adhering to the C++ standard in our implementation, we have succeededin porting our toolset to Windows, Linux and MacOSX. This offers the advantage ofhaving different checks from different compilers, which again helps in improving sta-bility of the toolset. In practice the overhead required for supporting multiple platformsis relatively low.Currently interfaces are generalised using techniques from generic programming.This allows to create uniform interfaces with a high degree of flexibility. In an academicenvironment, where people require prototypes of new or altered functionality, this is avery useful property, as more time needs to be spent on experimenting, and less oncoding.Conclusions We have described the challenges that occur in developing a formal meth-ods toolset in an academic environment. Some of the issues discussed are widely knownin the software development process in general, and not only in academia. Others, likethe quick turnover in development resources and the urge to experiment with differentimplementations, as well as the low focus on tool development, are more specific to anacademic environment, and require generalised solutions.For the issues that were raised we have discussed the solutions that we have imple-mented so far, as well as changes that are currently going on.The key to more understandable and reliable implementations, as well as a moreswift development process lie in a high level of abstraction in the code and (more)detailed design and source code documentation.References1. S.C.C. Blom, W.J. Fokkink, J.F. Groote, I. v. Langevelde, B. Lisser, and J.C. v.d. Pol. µCRL:A toolset for analysing algebraic specifications. In Proc. of CAV’01, volume 2102 of LNCS,pages 250–254, 2001.2. J.F. Groote, A.H.J. Mathijssen, and Y.S. Usenko M.J. v. Weerdenburg. From µCRL tomCRL2: Motivation and outline. In Proc. of APC 25, volume 162 of ENTCS, pages 191–196, 2006.3. J.F. Groote, A.H.J. Mathijssen, M.A. Reniers, Y.S. Usenko, and M.J. v. Weerdenburg. Anal-ysis of distributed systems with mcrl2. In M. Alexander and W. Gardner, editors, ProcessAlgebra for Parallel and Distributed Processing, pages 99–128. Chapman Hall, 2009.4. M.G.J. v.d. Brand, H.A. d. Jong, P. Klint, and P.A. Olivier. Efficient Annotated Terms. Soft-ware – Practice & Experience, 30:259–291, 2000.

Experience in developing the mCRL2 toolset

https://pure.tue.nl/ws/files/3377053/Metis246406.pdf

Experience in developing the mCRL2 toolset

Abstract

Similar works

Full text

Available Versions

Pure OAI Repository