Abstract

SummaryAfter a number of success stories in safety‐critical domains, we are starting to witness applications of formal methods in contemporary systems and software engineering. However, one thing that is still missing is the evaluation criteria that help software practitioners choose the right formal method for the problem at hand. In this paper, we present the criteria for evaluating and comparing different formal methods. The criteria were chosen through a literature review, discussions with experts from academia and practitioners from industry, and decade‐long personal experience with the application of formal methods in industrial and academic projects. The criteria were then evaluated on several model‐oriented state‐based formal methods. Our research shows that besides technical grounds (eg, modeling capabilities and supported development phases), formal methods should also be evaluated from social and industrial perspectives. We also found out that it is not possible to generate a matrix that renders the selection of the right formal method an automatic process. However, we can generate several pointers, which make this selection process a lot less cumbersome.

Highlights

  • Numerous success stories in the safety-critical systems domain, and the availability of various “easy to use” methods and tools, formal methods are being applied to application domains that are not inherently safety critical in nature

  • One such example is the use of the formal method Temporal Logic of Actions (TLA)+1 at Amazon for specifying and model checking their web services.[2]

  • A cliché that formal methods would require specially trained, “expensive” personnel is well founded. It is one of the “Seven myths of formal methods” of Hall,[58] who claims that the mathematics involved in writing, eg, a Z specification, would require only the basic “high school math” one should expect from any “practicing engineer”; we found that even people with a PhD in computer science are often put off by a Z or B specification, and with ordinary developers, the picture looks even worse.‖ According to Alstom, besides a degree in mathematics and foundations in logic, a modeler should have the right “skills” and “talent.” Certainly, style of use matters a lot

Read more

Summary

INTRODUCTION

Numerous success stories in the safety-critical systems domain, and the availability of various “easy to use” methods and tools, formal methods are being applied to application domains that are not inherently safety critical in nature One such example is the use of the formal method TLA+1 at Amazon for specifying and model checking their web services.[2] choosing TLA+ was not a straightforward decision for Amazon, and they experimented with other methods before selecting one that satisfied their needs. The development of safety-critical systems needs elaborate evidence for compliance with safety requirements and standards, whereas other projects have budget and time restrictions that do not allow for expensive verification efforts It makes a difference whether engineers involved in the project are trained for a particular method and domain or whether their experiences are available for maintenance later on.

Research approach
Literature reviewed
Criteria for evaluating formal methods
Modeling criteria
Supported development phases
Technical criteria
Usability
Industrial applicability
Overview
Tables for comparison
Event-B
CONCLUSION AND FUTURE WORK
Full Text
Paper version not known

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call

Disclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.