Abstract
In the previous chapter, we saw different techniques to validate properties about software. However, if software uses complicated data structures that we wish to provide guarantees about, these techniques are limited in what they can achieve. This chapter introduces specifications using the Design by Contract approach, which allows one to specify precisely the intended behaviour of software that involve complex data structures and have unbounded state spaces. Chapter 8 discusses how to combine Design by Contract with abstraction. Chapters 9 and 10 discuss techniques to validate an implementation w.r.t. such a specification, using runtime and static verification techniques.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Pronounced Aksel.
- 2.
See also this Wikipedia page: http://en.wikipedia.org/wiki/Design_by_contract, last visited on February 14, 2023.
- 3.
See http://www.sds.lcs.mit.edu/spd/larch, last visited on February 14, 2023.
- 4.
In fact, some of the Krakatoa developers (mentioned above) have also been involved in the development of Frama-c and Acsl.
- 5.
See for its specification http://www.eecs.ucf.edu/~leavens/JML-release/javadocs/java/lang/Object.html , last visited February 14, 2023.
- 6.
In Acsl \(\big {\backslash }{\texttt {true}}\) and \(\big {\backslash }{\texttt {false}}\) are introduced to write the values of the mathematical Boolean type, rather than using 0 for false, and 1 (or any other positive number) for true, as is usually done in C.
- 7.
A function is said to terminate normally if either it reached the end of its body, in a normal state, or it terminated because of a return instruction. Below, in Sect. 7.6 we discuss how in Jml we can specify which conditions hold if a function terminates because of an exception.
- 8.
Acsl uses two integer types: the computer type int and the mathematical integer type integer. The latter is typically used in specifications. For more details, we refer to the Acsl language specification [18].
- 9.
Not to be confused with loop invariants, which help to reason about the behaviour of a loop. Loop invariants are discussed in Chap. 10.
- 10.
In Jml, all invariants are weak.
- 11.
Unfortunately, at the time of writing, static annotation checking (see Chap. 10) for Acsl does not verify these type invariants yet.
- 12.
Again, typically only private constructors would be annotated as a helper constructor.
- 13.
And the desugaring procedure will explicitly repeat the specifications from the superclass.
- 14.
Acsl does not provide any support for exceptional behaviour, as C does not have an exception mechanism. However, the language could easily be extended following the same principles to give specifications about errors.
- 15.
This specification is typically used in combination with other specifications that describe the normal behaviour of a method.
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
Copyright information
© 2023 The Author(s), under exclusive license to Springer Nature Switzerland AG
About this chapter
Cite this chapter
Huisman, M., Wijs, A. (2023). Design by Contract Specification Languages. In: Concise Guide to Software Verification. Texts in Computer Science. Springer, Cham. https://doi.org/10.1007/978-3-031-30167-4_7
Download citation
DOI: https://doi.org/10.1007/978-3-031-30167-4_7
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-031-30166-7
Online ISBN: 978-3-031-30167-4
eBook Packages: Computer ScienceComputer Science (R0)