Partial implementations of abstract data types: A dissenting view on errors

Refinement is reviewed, highlighting in particular the distinction between its use as a specification constructor at a high level, and its use as an implementation mechanism at a low level. Some of its shortcomings as a specification constructor at high levels of abstraction are pointed out, and these are used to motivate the adoption of retrenchment for certain high level development steps. Basic properties of retrenchment are described, including a justification of the operation proof obligation, simple examples, its use in requirements engineering and model evolution, and simulation properties. The interaction of retrenchment with refinement notions of correctness is overviewed, as is a range of other technical issues. Two case study scenarios are presented. One is a simple digital redesign control theory problem, and the other is an overview of the application of retrenchment to the Mondex Purse development.

show abstract

“…Related to this approach is a body of work on partiality in algebraic specification, e.g. [46,47,91,48,74].…”

Section: Previous Workmentioning

confidence: 99%

Engineering and theoretical underpinnings of retrenchment

Banach

Poppleton

Jeske

et al. 2007

Science of Computer Programming

View full text Add to dashboard Cite

show abstract

“…Classical examples of this kind of 'simulation' are the implementation of sets by sequences or the implementation of stacks by arrays and pointers. Most of the implementation approaches in the literature fall into this category (for example, Goguen et al (1976), Guttag et al (1978), Ehrig et al (1978), Orejas (1981), Ehrich (1982), Ehrig et al (1982), Goguen and Meseguer (1982), Ehrig and Kreowski (1983), Ganzinger (1983), Kamin and Archer (1984), Orejas (1985), Bernot et al (1986), Broy et al (1986), Poigne (1984), Bernot (1989)). However, some others (for example, Sannella and Wirsing (1982), Sannella and Tarlecki (1988a), Schoett (1987), Hennicker (1989)) prefer to mix the two notions of refinement and simulation: SP' implements SP if the models of SP' behave like some models of SP.…”

Section: What Is An Implementation?mentioning

confidence: 99%

“…In 1972 Hoare presented the first notion of data type implementation in the literature. This was the beginning of a long series of papers dealing with the same concept (without trying to be exhaustive we may cite Goguen et al (1976), Guttag et al (1978), Ehrich and Lipeck (1980), Orejas (1981), Ehrich (1982), Ehrig et al (1982), Goguen and Meseguer (1982), Sannella and Wirsing (1982;, Ehrig and Kreowski (1983), Ganzinger (1983), Kamin and Archer (1984), Poigne (1984), Orejas (1985), Bernot et al (1986), Broy et al (1986), Schoett (1987), 1988a), Hennicker (1989), Bernot (1989), Ehrig (1989), Ehrig and Adametz (1991). Why have there been such a number of different approaches?…”

Section: Implementations: Syntax and Semanticsmentioning

confidence: 99%

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

Orejas

Navarro

Sánchez

1996

Math. Struct. Comp. Sci.

View full text Add to dashboard Cite

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.

show abstract

“…A module is developed and shown correct relative to a representation invariant I, a predicate that relates abstract and concrete values. A relation is less restrictive than the usual function from concrete to abstract values (as first given in [3], see also [5]). Although I will usually specify a function, it need not, and it is usually simpler to state as a relation.…”

Section: Module Eorreetnessmentioning

confidence: 99%

“…The proof obligation incurred by an implementation directive is then reduced to establishing the truth of a series of implications. This possibility is also considered in [5], but in a setting that requires the construction of data-type algebras.…”

Section: P(s/ T R) = ~(S -~P(r -R))mentioning

confidence: 99%

A new notion of encapsulation

Gries

PrinsJan

1985

SIGPLAN Not.

View full text Add to dashboard Cite

Generally speaking, a “module” is used as an “encapsulation mechanism” to tie together a set of declarations of variables and operations upon them. Although there is no standard way to instantiate or use a module, the general idea is that a module describes the implementation of all the values of a given type. We believe that this is too inflexible to provide enough control: one should be able to use different implementations (given by different modules) for variables (and values) of the same type. When incorporated properly into the notation, this finer grain of control allows one to program at a high level of abstraction and then to indicate how various pieces of the program should be implemented. It provides simple, effective access to earlier-written modules, so that they are useable in a more flexible manner than is possible in current notations. It generalizes to provide the ability to indicate structural transformations, in a disciplined fashion, in order to achieve efficiency with respect to time or space. However, the program will still be understood at the abstract level and the transformations or implementations will be looked at only to deal with efficiency concerns. Finally, some so-called “data types” (e.g. stack and subranges of the integers) can more properly be looked upon simply as restricted implementations of more general types (e.g. sequence and integer ). Thus, the notion of subtype becomes less important.

show abstract

Partial implementations of abstract data types: A dissenting view on errors

Cited by 7 publications

References 14 publications

Engineering and theoretical underpinnings of retrenchment

Engineering and theoretical underpinnings of retrenchment

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

A new notion of encapsulation

Contact Info

Product

Resources

About