Formal methods

In computer science, formal methods are mathematically rigorous techniques for the
specification, development, analysis, and verification of software and hardware systems.[1] The
use of formal methods for software and hardware design is motivated by the expectation that,
as in other engineering disciplines, performing appropriate mathematical analysis can contribute
to the reliability and robustness of a design.[2]

Formal methods employ a variety of theoretical computer science fundamentals, including logic
calculi, formal languages, automata theory, control theory, program semantics, type systems,
and type theory.[3]

Background
Semi-formal methods are formalisms and languages that are not considered fully "formal". It
defers the task of completing the semantics to a later stage, which is then done either by human
interpretation or by interpretation through software like code or test case generators.[4]

Taxonomy
Formal methods can be used at a number of levels:
Level 0: Formal specification may be
undertaken and then a program
developed from this informally. This has
been dubbed formal methods lite. This
may be the most cost-effective option in
many cases.
Level 1: Formal development and formal
verification may be used to produce a
program in a more formal manner. For
example, proofs of properties or
refinement from the specification to a
program may be undertaken. This may
be most appropriate in high-integrity
systems involving safety or security.
 Level 2: Theorem provers may be used
to undertake fully formal machine-
checked proofs. Despite improving tools
and declining costs, this can be very
expensive and is only practically
worthwhile if the cost of mistakes is
very high (e.g., in critical parts of
operating system or microprocessor
design).
Further information on this is expanded below.

As with programming language semantics, styles of formal methods may be roughly classified
as follows:

Denotational semantics, in which the

meaning of a system is expressed in the
mathematical theory of domains.
Proponents of such methods rely on the
well-understood nature of domains to
give meaning to the system; critics point
out that not every system may be
intuitively or naturally viewed as a
function.
Operational semantics, in which the
meaning of a system is expressed as a
sequence of actions of a (presumably)
simpler computational model.
Proponents of such methods point to
the simplicity of their models as a
means to expressive clarity; critics
counter that the problem of semantics
has just been delayed (who defines the
semantics of the simpler model?).
 Axiomatic semantics, in which the
meaning of the system is expressed in
terms of preconditions and
postconditions that are true before and
after the system performs a task,
respectively. Proponents note the
connection to classical logic; critics
note that such semantics never really
describe what a system does (merely
what is true before and afterwards).

Lightweight formal methods

Some practitioners believe that the formal methods community has overemphasized full
formalization of a specification or design.[5][6] They contend that the expressiveness of the
languages involved, as well as the complexity of the systems being modelled, make full
formalization a difficult and expensive task. As an alternative, various lightweight formal
methods, which emphasize partial specification and focused application, have been proposed.
Examples of this lightweight approach to formal methods include the Alloy object modelling
notation,[7] Denney's synthesis of some aspects of the Z notation with use case driven
development,[8] and the CSK VDM Tools.[9]
Uses
Formal methods can be applied at various points through the development process.

Specification
Formal methods may be used to give a description of the system to be developed, at whatever
level(s) of detail desired. This formal description can be used to guide further development
activities (see following sections); additionally, it can be used to verify that the requirements for
the system being developed have been completely and accurately specified, or formalising
system requirements by expressing them in a formal language with a precise and
unambiguously defined syntax and semantics.

The need for formal specification systems has been noted for years. In the ALGOL 58 report,[10]
John Backus presented a formal notation for describing programming language syntax, later
named Backus normal form then renamed Backus–Naur form (BNF).[11] Backus also wrote that
a formal description of the meaning of syntactically valid ALGOL programs was not completed in
time for inclusion in the report. "Therefore the formal treatment of the semantics of legal
programs will be included in a subsequent paper." It never appeared.

Development
Formal development is the use of formal methods as an integrated part of a tool-supported
system development process.

Once a formal specification has been produced, the specification may be used as a guide while
the concrete system is developed during the design process (i.e., realized typically in software,
but also potentially in hardware). For example:
 If the formal specification is in
operational semantics, the observed
behavior of the concrete system can be
compared with the behavior of the
specification (which itself should be
executable or simulatable). Additionally,
the operational commands of the
specification may be amenable to direct
translation into executable code.
If the formal specification is in
axiomatic semantics, the preconditions
and postconditions of the specification
may become assertions in the
executable code.

Verification
Formal verification is the use of software tools to prove properties of a formal specification, or
to prove that a formal model of a system implementation satisfies its specification.

Once a formal specification has been developed, the specification may be used as the basis for
proving properties of the specification, and by inference, properties of the system
implementation.

Sign-off verification
Sign-off verification is the use of a formal verification tool that is highly trusted. Such a tool can
replace traditional verification methods (the tool may even be certified).

Human-directed proof
Sometimes, the motivation for proving the correctness of a system is not the obvious need for
reassurance of the correctness of the system, but a desire to understand the system better.
Consequently, some proofs of correctness are produced in the style of mathematical proof:
handwritten (or typeset) using natural language, using a level of informality common to such
proofs. A "good" proof is one that is readable and understandable by other human readers.

Critics of such approaches point out that the ambiguity inherent in natural language allows
errors to be undetected in such proofs; often, subtle errors can be present in the low-level details
typically overlooked by such proofs. Additionally, the work involved in producing such a good
proof requires a high level of mathematical sophistication and expertise.

Automated proof
In contrast, there is increasing interest in producing proofs of correctness of such systems by
automated means. Automated techniques fall into three general categories:

Automated theorem proving, in which a

system attempts to produce a formal
 proof from scratch, given a description
of the system, a set of logical axioms,
and a set of inference rules.
Model checking, in which a system
verifies certain properties by means of
an exhaustive search of all possible
states that a system could enter during
its execution.
Abstract interpretation, in which a
system verifies an over-approximation
of a behavioural property of the
program, using a fixpoint computation
over a (possibly complete) lattice
representing it.
Some automated theorem provers require guidance as to which properties are "interesting"
enough to pursue, while others work without human intervention. Model checkers can quickly
get bogged down in checking millions of uninteresting states if not given a sufficiently abstract
model.
Proponents of such systems argue that the results have greater mathematical certainty than
human-produced proofs, since all the tedious details have been algorithmically verified. The
training required to use such systems is also less than that required to produce good
mathematical proofs by hand, making the techniques accessible to a wider variety of
practitioners.

Critics note that some of those systems are like oracles: they make a pronouncement of truth,
yet give no explanation of that truth. There is also the problem of "verifying the verifier"; if the
program that aids in the verification is itself unproven, there may be reason to doubt the
soundness of the produced results. Some modern model checking tools produce a "proof log"
detailing each step in their proof, making it possible to perform, given suitable tools,
independent verification.

The main feature of the abstract interpretation approach is that it provides a sound analysis, i.e.
no false negatives are returned. Moreover, it is efficiently scalable, by tuning the abstract domain
representing the property to be analyzed, and by applying widening operators[12] to get fast
convergence.

Applications
Formal methods are applied in different areas of hardware and software, including routers,
Ethernet switches, routing protocols, security applications, and operating system microkernels
such as seL4. There are several examples in which they have been used to verify the
functionality of the hardware and software used in data centres. IBM used ACL2, a theorem
prover, in the AMD x86 processor development process. Intel uses such methods to verify its
hardware and firmware (permanent software programmed into a read-only memory). Dansk
Datamatik Center used formal methods in the 1980s to develop a compiler system for the Ada
programming language that went on to become a long-lived commercial product.[13][14]

There are several other projects of NASA in which formal methods are applied, such as Next
Generation Air Transportation System, Unmanned Aircraft System integration in National
Airspace System,[15] and Airborne Coordinated Conflict Resolution and Detection
(ACCoRD).[16]B-Method with Atelier B,[17] is used to develop safety automatisms for the various
subways installed throughout the world by Alstom and Siemens, and also for Common Criteria
certification and the development of system models by ATMEL and STMicroelectronics.
Formal verification has been frequently used in hardware by most of the well-known hardware
vendors, such as IBM, Intel, and AMD. There are many areas of hardware, where Intel have used
formal methods to verify the working of the products, such as parameterized verification of
cache-coherent protocol,[18] Intel Core i7 processor execution engine validation [19] (using
theorem proving, BDDs, and symbolic evaluation), optimization for Intel IA-64 architecture using
HOL light theorem prover,[20] and verification of high-performance dual-port gigabit Ethernet
controller with support for PCI express protocol and Intel advance management technology
using Cadence.[21] Similarly, IBM has used formal methods in the verification of power gates,[22]
registers,[23] and functional verification of the IBM Power7 microprocessor.[24]

In software development
In software development, formal methods are mathematical approaches to solving software
(and hardware) problems at the requirements, specification, and design levels. Formal methods
are most likely to be applied to safety-critical or security-critical software and systems, such as
avionics software. Software safety assurance standards, such as DO-178C allows the usage of
formal methods through supplementation, and Common Criteria mandates formal methods at
the highest levels of categorization.

For sequential software, examples of formal methods include the B-Method, the specification
languages used in automated theorem proving, RAISE, and the Z notation.

In functional programming, property-based testing has allowed the mathematical specification

and testing (if not exhaustive testing) of the expected behaviour of individual functions.

The Object Constraint Language (and specializations such as Java Modeling Language) has
allowed object-oriented systems to be formally specified, if not necessarily formally verified.

For concurrent software and systems, Petri nets, process algebra, and finite state machines
(which are based on automata theory; see also virtual finite state machine or event driven finite
state machine) allow executable software specification and can be used to build up and validate
application behaviour.

Another approach to formal methods in software development is to write a specification in

some form of logic—usually a variation of first-order logic—and then to directly execute the logic
as though it were a program. The OWL language, based on description logic, is an example.
There is also work on mapping some version of English (or another natural language)
automatically to and from logic, as well as executing the logic directly. Examples are Attempto
Controlled English, and Internet Business Logic, which do not seek to control the vocabulary or
syntax. A feature of systems that support bidirectional English–logic mapping and direct
execution of the logic is that they can be made to explain their results, in English, at the business
or scientific level.

Formal methods and

notations
There are a variety of formal methods and notations available.

Specification languages

Abstract State Machines (ASMs)

A Computational Logic for Applicative
Common Lisp (ACL2)
Actor model
Alloy
ANSI/ISO C Specification Language
(ACSL)
Autonomic System Specification
Language (ASSL)
B-Method
CADP
Common Algebraic Specification
Language (CASL)
Esterel
Java Modeling Language (JML)
Knowledge Based Software Assistant
(KBSA)
Lustre
mCRL2
Perfect Developer
Petri nets
Predicative programming
Process calculi
CSP
LOTOS
π-calculus
RAISE
Rebeca Modeling Language
SPARK Ada
Specification and Description Language
TLA+
USL
VDM
 VDM-SL
VDM++
Z notation

Model checkers

ESBMC[25]
MALPAS Software Static Analysis
Toolset – an industrial-strength model
checker used for formal proof of safety-
critical systems
PAT – a free model checker, simulator
and refinement checker for concurrent
systems and CSP extensions (e.g.,
shared variables, arrays, fairness)
SPIN
 UPPAAL

Solvers and competitions

Many problems in formal methods are NP-hard, but can be solved in cases arising in practice.
For example, the boolean satisfiability problem is NP-complete by the Cook–Levin theorem, but
SAT solvers can solve a variety of large instances. There are "solvers" for a variety of problems
that arise in formal methods, and there are many periodic competitions to evaluate the state-of-
the-art in solving such problems.[26]

The SAT competition is a yearly

competition that compares SAT
solvers.[27] SAT solvers are used in
formal methods tools such as Alloy.[28]
CASC is a yearly competition of
automated theorem provers.
SMT-COMP is a yearly competition of
SMT solvers, which are applied to
formal verification.[29]
 CHC-COMP is a yearly competition of
solvers of constrained Horn clauses,
which have applications to formal
verification.[30]
QBFEVAL is a biennial competition of
solvers for true quantified Boolean
formulas, which have applications to
model checking.[31][32]
SV-COMP is an annual competition for
software verification tools.[33]
SyGuS-COMP is an annual competition
for program synthesis tools.[34]

Organizations

BCS-FACS
 Formal Methods Europe
Z User Group

See also

Abstract interpretation
Automated theorem proving
Design by contract
Formal methods people
Formal science
Formal specification
Formal verification
Formal system
Methodism
Methodology
 Model checking
Scientific method
Software engineering
Specification language

References

1. Butler, R. W. (2001-08-06). "What is Formal

Methods?" (http://shemesh.larc.nasa.gov/f
m/fm-what.html) . Retrieved 2006-11-16.
2. Holloway, C. Michael. "Why Engineers
Should Consider Formal Methods" (https://
web.archive.org/web/20061116210448/htt
p://klabs.org/richcontent/verification/hollo
way/nasa-97-16dasc-cmh.pdf) (PDF). 16th
Digital Avionics Systems Conference (27–
30 October 1997). Archived from the
original (http://klabs.org/richcontent/verific
ation/holloway/nasa-97-16dasc-cmh.pdf)
(PDF) on 16 November 2006. Retrieved
2006-11-16. {{cite journal}}: Cite
journal requires |journal= (help)

3. Monin, pp.3-4
4. X2R-2, deliverable D5.1.
5. Daniel Jackson and Jeannette Wing,
"Lightweight Formal Methods" (http://peopl
e.csail.mit.edu/dnj/publications/ieee96-rou
ndtable.html) , IEEE Computer, April 1996
. Vinu George and Rayford Vaughn,
"Application of Lightweight Formal Methods
in Requirement Engineering" (http://www.st
sc.hill.af.mil/crosstalk/2003/01/George.ht
ml) Archived (https://web.archive.org/we
b/20060301022259/http://www.stsc.hill.af.
mil/crosstalk/2003/01/George.html)
2006-03-01 at the Wayback Machine,
Crosstalk: The Journal of Defense Software
Engineering, January 2003
7. Daniel Jackson, "Alloy: A Lightweight Object
Modelling Notation" (http://people.csail.mit.
edu/dnj/publications/alloy-journal.pdf) ,
ACM Transactions on Software Engineering
and Methodology (TOSEM), Volume 11,
Issue 2 (April 2002), pp. 256-290
. Richard Denney, Succeeding with Use
Cases: Working Smart to Deliver Quality,
Addison-Wesley Professional Publishing,
2005, ISBN 0-321-31643-6.
 9. Sten Agerholm and Peter G. Larsen, "A
Lightweight Approach to Formal Methods"
(http://home0.inet.tele.dk/pgl/fmtrends98.
pdf) Archived (https://web.archive.org/we
b/20060309041943/http://home0.inet.tele.
dk/pgl/fmtrends98.pdf) 2006-03-09 at the
Wayback Machine, In Proceedings of the
International Workshop on Current Trends
in Applied Formal Methods, Boppard,
Germany, Springer-Verlag, October 1998
10. Backus, J.W. (1959). "The Syntax and
Semantics of the Proposed International
Algebraic Language of Zürich ACM-GAMM
Conference". Proceedings of the
International Conference on Information
Processing. UNESCO.
11. Knuth, Donald E. (1964), Backus Normal
Form vs Backus Naur Form.
Communications of the ACM, 7(12):735–
736.
12. A. Cortesi and M. Zanioli, Widening and
Narrowing Operators for Abstract
Interpretation (http://www.dsi.unive.it/~cort
esi/paperi/CL_2011.pdf) . Computer
Languages, Systems and Structures.
Volume 37(1), pp. 24–42, Elsevier,
ISSN 1477-8424 (https://www.worldcat.or
g/search?fq=x0:jrnl&q=n2:1477-8424)
(2011).
13. Bjørner, Dines; Gram, Christian; Oest, Ole N.;
Rystrøm, Leif (2011). "Dansk Datamatik
Center". In Impagliazzo, John; Lundin, Per;
Wangler, Benkt (eds.). History of Nordic
Computing 3: IFIP Advances in Information
and Communication Technology. Springer.
pp. 350–359.
14. Bjørner, Dines; Havelund, Klaus. "40 Years
of Formal Methods: Some Obstacles and
Some Possibilities?". FM 2014: Formal
Methods: 19th International Symposium,
Singapore, May 12–16, 2014. Proceedings
(http://www.imm.dtu.dk/~dibj/2014/tokyo/
tokyo-s.pdf) (PDF). Springer. pp. 42–61.
15. Gheorghe, A. V., & Ancel, E. (2008,
November). Unmanned aerial systems
integration to National Airspace System. In
Infrastructure Systems and Services:
Building Networks for a Brighter Future
(INFRA), 2008 First International
Conference on (pp. 1-5). IEEE.
1 . Airborne Coordinated Conflict Resolution
and Detection,
http://shemesh.larc.nasa.gov/people/cam/
ACCoRD/
17. "Atelier B" (http://www.atelierb.eu/en/) .
www.atelierb.eu.
1 . C. T. Chou, P. K. Mannava, S. Park, "A simple
method for parameterized verification of
cache coherence protocols (https://www.st
udent.cs.uwaterloo.ca/~cs745/paper-pres/
simparam.pdf) ", Formal Methods in
Computer-Aided Design, pp. 382–398,
2004.
19. Formal Verification in Intel® Core™ i7
Processor Execution Engine Validation,
http://cps-vo.org/node/1371 , accessed at
September 13, 2013.
20. J. Grundy, "Verified optimizations for the
Intel IA-64 architecture", In Theorem
Proving in Higher Order Logics, Springer
Berlin Heidelberg, 2004, pp. 215–232.
21. E. Seligman, I. Yarom, "Best known
methods for using Cadence Conformal LEC
(http://citeseerx.ist.psu.edu/viewdoc/downl
oad?doi=10.1.1.108.2381&rep=rep1&type=
pdf) ", at Intel.
22. C. Eisner, A. Nahir, K. Yorav, "Functional
verification of power gated designs by
compositional reasoning (ftp://nozdr.ru/bibl
io/kolxo3/Cs/CsLn/Computer%20Aided%2
0Verification,%2020%20conf.,%20CAV%202
008(LNCS5123,%20Springer,%202008)(ISB
N%209783540705437)(573s)_CsLn_.pdf#p
age=449) ", Computer Aided Verification,
Springer Berlin Heidelberg, pp. 433–445.
23. P. C. Attie, H. Chockler, "Automatic
verification of fault-tolerant register
emulations (https://core.ac.uk/download/p
df/82434920.pdf) ", Electronic Notes in
Theoretical Computer Science, vol. 149, no.
1, pp. 49–60.
24. K. D. Schubert, W. Roesner, J. M. Ludden, J.
Jackson, J. Buchert, V. Paruthi, B. Brock,
"Functional verification of the IBM POWER7
microprocessor and POWER7
multiprocessor systems (https://ieeexplore.
ieee.org/abstract/document/5756329/) ",
IBM Journal of Research and Development,
vol. 55, no 3.
25. "ESBMC" (http://esbmc.org/) . esbmc.org.
2 . Bartocci, Ezio; Beyer, Dirk; Black, Paul E.;
Fedyukovich, Grigory; Garavel, Hubert;
Hartmanns, Arnd; Huisman, Marieke;
Kordon, Fabrice; Nagele, Julian; Sighireanu,
Mihaela; Steffen, Bernhard; Suda, Martin;
Sutcliffe, Geoff; Weber, Tjark; Yamada,
Akihisa (2019). Beyer, Dirk; Huisman,
Marieke; Kordon, Fabrice; Steffen, Bernhard
(eds.). "TOOLympics 2019: An Overview of
Competitions in Formal Methods" (https://li
nk.springer.com/chapter/10.1007/978-3-03
0-17502-3_1) . Tools and Algorithms for the
Construction and Analysis of Systems.
Lecture Notes in Computer Science. Cham:
Springer International Publishing: 3–24.
doi:10.1007/978-3-030-17502-3_1 (https://
doi.org/10.1007%2F978-3-030-17502-3_1) .
ISBN 978-3-030-17502-3.
27. Froleyks, Nils; Heule, Marijn; Iser, Markus;
Järvisalo, Matti; Suda, Martin (2021-12-01).
"SAT Competition 2020" (https://www.scien
cedirect.com/science/article/pii/S0004370
221001235) . Artificial Intelligence. 301:
103572. doi:10.1016/j.artint.2021.103572
(https://doi.org/10.1016%2Fj.artint.2021.10
3572) . ISSN 0004-3702 (https://www.worl
dcat.org/issn/0004-3702) .
2 . Cornejo, César (2021-01-27). "SAT-based
arithmetic support for alloy" (https://doi.or
g/10.1145/3324884.3415285) .
Proceedings of the 35th IEEE/ACM
International Conference on Automated
Software Engineering. ASE '20. New York,
NY, USA: Association for Computing
Machinery: 1161–1163.
doi:10.1145/3324884.3415285 (https://doi.
org/10.1145%2F3324884.3415285) .
ISBN 978-1-4503-6768-4.
29. Barrett, Clark; Deters, Morgan; de Moura,
Leonardo; Oliveras, Albert; Stump, Aaron
(2013-03-01). "6 Years of SMT-COMP" (http
s://doi.org/10.1007/s10817-012-9246-5) .
Journal of Automated Reasoning. 50 (3):
243–277. doi:10.1007/s10817-012-9246-5
(https://doi.org/10.1007%2Fs10817-012-92
46-5) . ISSN 1573-0670 (https://www.world
cat.org/issn/1573-0670) .
30. Fedyukovich, Grigory; Rümmer, Philipp
(2021-09-13). "Competition Report: CHC-
COMP-21" (http://arxiv.org/abs/2109.0463
5) . Electronic Proceedings in Theoretical
Computer Science. 344: 91–108.
arXiv:2008.02939 (https://arxiv.org/abs/20
08.02939) . doi:10.4204/EPTCS.344.7 (http
s://doi.org/10.4204%2FEPTCS.344.7) .
ISSN 2075-2180 (https://www.worldcat.or
g/issn/2075-2180) .
31. Shukla, Ankit; Biere, Armin; Pulina, Luca;
Seidl, Martina (November 2019). "A Survey
on Applications of Quantified Boolean
Formulas" (https://ieeexplore.ieee.org/docu
ment/8995437/) . IEEE: 78–84.
doi:10.1109/ICTAI.2019.00020 (https://doi.
org/10.1109%2FICTAI.2019.00020) .
ISBN 978-1-7281-3798-8. {{cite
journal}}: Cite journal requires
|journal= (help)
32. Pulina, Luca; Seidl, Martina (2019-09-01).
"The 2016 and 2017 QBF solvers
evaluations (QBFEVAL'16 and QBFEVAL'17)"
(https://www.sciencedirect.com/science/ar
ticle/pii/S0004370218301450) . Artificial
Intelligence. 274: 224–248.
doi:10.1016/j.artint.2019.04.002 (https://do
i.org/10.1016%2Fj.artint.2019.04.002) .
ISSN 0004-3702 (https://www.worldcat.or
g/issn/0004-3702) .
33. Beyer, Dirk (2022). Fisman, Dana; Rosu,
Grigore (eds.). "Progress on Software
Verification: SV-COMP 2022" (https://link.sp
ringer.com/chapter/10.1007/978-3-030-995
27-0_20) . Tools and Algorithms for the
Construction and Analysis of Systems.
Lecture Notes in Computer Science. Cham:
Springer International Publishing: 375–402.
doi:10.1007/978-3-030-99527-0_20 (http
s://doi.org/10.1007%2F978-3-030-99527-0
_20) . ISBN 978-3-030-99527-0.
34. Alur, Rajeev; Fisman, Dana; Singh, Rishabh;
Solar-Lezama, Armando (2017-11-28).
"SyGuS-Comp 2017: Results and Analysis"
(http://arxiv.org/abs/1711.11438) .
Electronic Proceedings in Theoretical
Computer Science. 260: 97–115.
arXiv:1611.07627 (https://arxiv.org/abs/16
11.07627) . doi:10.4204/EPTCS.260.9 (http
s://doi.org/10.4204%2FEPTCS.260.9) .
ISSN 2075-2180 (https://www.worldcat.or
g/issn/2075-2180) .

Further reading

Jonathan P. Bowen and Michael G. Hinchey,

Formal Methods. In Allen B. Tucker, Jr. (ed.),
Computer Science Handbook, 2nd edition,
Section XI, Software Engineering, Chapter
106, pages 106-1 – 106-25, Chapman & Hall /
CRC Press, Association for Computing
Machinery, 2004.
Hubert Garavel (editor) and Susanne Graf.
Formal Methods for Safe and Secure
Computer Systems (https://www.bsi.bund.de/
SharedDocs/DE/Publikationen/Studien/form
al_methods_study_875/study_875.html) .
Bundesamt für Sicherheit in der
Informationstechnik, BSI study 875, Bonn,
Germany, December 2013.
Garavel, Hubert; ter Beek, Maurice H.; van de
Pol, Jaco (29 August 2020). "The 2020
Expert Survey on Formal Methods". Formal
Methods for Industrial Critical Systems: 25
International Conference, FMICS 2020 (http
s://hal.inria.fr/hal-03082818/file/Garavel-terB
eek-vandePol-20.pdf) (PDF). Lecture Notes
in Computer Science (LNCS). Vol. 12327.
Springer. pp. 3–69. doi:10.1007/978-3-030-
58298-2_1 (https://doi.org/10.1007%2F978-3
-030-58298-2_1) . ISBN 978-3-030-58297-5.
S2CID 221381022 (https://api.semanticschol
ar.org/CorpusID:221381022) .* Michael G.
Hinchey, Jonathan P. Bowen, and Emil
Vassev, Formal Methods. In Philip A. Laplante
(ed.), Encyclopedia of Software Engineering,
Taylor & Francis, 2010, pages 308–320.
Marieke Huisman, Dilian Gurov, and
Alexander Malkis, Formal Methods: From
Academia to Industrial Practice – A Travel
Guide (http://arxiv.org/abs/2002.07279) ,
arXiv:2002.07279, 2020.
 Gleirscher, Mario; Marmsoler, Diego (9
September 2020). "Formal methods in
dependable systems engineering: a survey of
professionals from Europe and North
America" (https://doi.org/10.1007%2Fs1066
4-020-09836-5) . Empirical Software
Engineering. Springer Nature. 25 (6): 4473–
4546. arXiv:1812.08815 (https://arxiv.org/ab
s/1812.08815) . doi:10.1007/s10664-020-
09836-5 (https://doi.org/10.1007%2Fs10664-
020-09836-5) .
Jean François Monin and Michael G.
Hinchey, Understanding formal methods,
Springer, 2003, ISBN 1-85233-247-6.

External links
Formal Methods Europe (http://www.fm
europe.org/) (FME)
Formal Methods Wiki (https://formalmet
hods.wikia.org/)
Formal methods (http://foldoc.org/form
al+methods) from Foldoc (https://foldo
c.org/)
Archival material

Formal method (https://web.archive.or

g/web/20130404202524/http://academ
ic.research.microsoft.com/Keyword/14
916) keyword on Microsoft Academic
Search via Archive.org
Evidence on Formal Methods uses and
impact on Industry (https://web.archive.
 org/web/20170713233230/http://www.f
m4industry.org/index.php/Evidence_on_
Formal_Methods_uses_and_impact_on_I
ndustry) supported by the DEPLOY (htt
p://www.deploy-project.eu) Archived (ht
tps://web.archive.org/web/2012060806
3125/http://www.deploy-project.eu/)
2012-06-08 at the Wayback Machine
project (EU FP7) in Archive.org

Retrieved from
"https://en.wikipedia.org/w/index.php?
title=Formal_methods&oldid=1193932620"

This page was last edited on 6 January 2024, at

09:55 (UTC). •
Content is available under CC BY-SA 4.0 unless
otherwise noted.