Formal Speciications in General, and Some Current Research Topics in Algebraic Speciications

1 The choice of formal speciications The importance of formal methods in software manufacturing is growing up. The use of formal methods becomes a sort of \label of quality" which is often considered as a guarantee of a certain level of software reliability. Of course, such an approach only takes sense if the objective itself is formally identiied. Consequently, formal methods rely on some formal speciications which state clearly what has to be formally ensured. This requires a lot of competences and investments; it is the reason why the critical parts of software engineering projects are the best \clients" for formal speciications and formal methods. The rst role of a speciication is to establish as clearly as possible what has to be done. It is a sort of contract to be fulllled, which has to be known before thinking about how to realize it. In practice, it is often diicult to write \unbiased" speciications at each level, i.e., speciications that stay within the boundaries of this \what," without premature choices which mention a unnecessary \how" part. Most of the time, making speciications abstract enough is a strong discipline, a sort of \pedagogical" eeort. However this eeort is prootable, especially if the speciied component is used (or reused) several times: the abstraction eeort to understand the purpose of the component has not to be done several times by numerous readers. Moreover, if we want to rigorously treat the question of software correctness, it is necessary to associate a rigorous semantics (mathematically deened) to each statement (i.e., to the syntax) of a speciication. Formal speciications deene unambiguously what the correctness of a program signiies and they are indeed the only way to have a rigorous deenition of correctness. Consequently, formal speciications must be used if we want to consider \entirely proved programs ," \zero-default softwares," etc. From a logical point of view, the notion of correctness of a program, without a formal speciication of it, is a nonsense. Slogan: To prove a theorem, it must be rigorously stated. To reach software cor-rectness, it must be formally speciied. Indeed, the fact that formal speciications are the only way to rigorously deene software correctness is not the main motivation. In practice, for the crucial parts of a software project,