Algebraic implementation of abstract data types: a survey of concepts and new compositionality results

Abstract

In this paper we try to shed some light on the similarities and differences in the different approaches denning the notions of implementation and implementation correctness. For obvious reasons, we do not discuss all existing approaches individually. Instead, a formal framework is introduced in order to discuss the most important ones. Additionally, we discuss some issues, which in our opinion are often misunderstood, concerning transitivity of implementation correctness and its role in the software development process. In particular, on the one hand, we show that for reasonable notions of implementation, it is almost impossible to prove transitivity of implementation correctness at the specification level. On the other hand, we show that this is not really important if the programming language satisfies the properties of horizontal and vertical composition.

Hidden coinduction: behavioural correctness proofs for objects

“…Hidden algebra uses a loose behavioural semantics over a fixed data algebra. Unlike the case in Orejas et al (1996), there is no competition between this and initial algebra semantics, because they are used for different purposes.…”

“…A more sophisticated view of refinement (Goguen and Meseguer 1982;Sannella and Tarlecki 1988;Hennicker 1990;Orejas et al 1996) allows the concrete implementation to rename or even identify some of the abstract sorts and operations, thus giving rise to a hidden signature map from the abstract to the concrete signature.…”

Property Preserving Redesign of Specifications

“…Our notion of redesign is related to the concept of implementation ( [ONS96,ST88b]). The implementation of SP 1 by SP 2 , as defined in [ONS96] …”

TFL: an algebraic language to specify the dynamic behaviour of knowledge-based systems

“…In this framework, software development is seen as resulting from a stepwise refinement process starting from a "high-level requirements specification" SPQ to a "low level program" P. A suit of intermediate formal specifications SP\,..., SP m is produced during this process, which is called " implementation". The program P is said to be an implementation of each specification SPj (Orejas et al, 1992) and in this context, SPj is considered to be also an implementation SPj, whenever i > j . Different interpretations of "implementation" are available in this framework of software development.…”