On the inevitable intertwining of specification and implementation

Abstract

Contrary to recent claims that specification should be completed before implementation begins, this paper presents two arguments that the two processes must be intertwined. First, limitations of available implementation technology may force a specification change. For example, deciding to implement a stack as an array (rather than as a linked list) may impose a fixed limit on the depth of the stack. Second, implementation choices may suggest augmentations to the original specification. For example, deciding to use an existing pattern-match routine to implement the search command in an editor may lead to incorporating some of the routine's features into the specification, such as the ability to include wild cards in the search key. This paper elaborates these points and illustrates how they arise in the specification of a controller for a package router.

References

1. 1 Balzer, R. M. Dataless programming. Full Joint Computer Conference, 1967, pp. 535-545.]]
2. 2 Balzer, R. M., N. M. Goldman, and D. S. Wile. On the transformational implementation approach to programming. Proceedings of the Second International Conference on Software Engineering, October 1976, pp. 337-344.]]
3. 3 Balzer, R. M., and N. M. Goldman. Principles of good software specification and their implications for specification languages. Proceedings of the Specifications of Reliable Software Conference, Boston, Massachusetts, April, 1979, pp. 58-67. (Also presented at the National Computer Conference, 1981.)]]
4. 4 Balzer, R. M. Transformational implementation: An example. IEEE Trans. Software Engineering 7, 1 (Jan. 1981), 3-14. Also published as USC/Information Sciences Institute RR-79-79, May 1981.]]
5. 5 Bauer, F. L. Programming as an evolutionary process. Proceedings of the Second International Conference on Software Engineering, Oct. 1976, pp. 223-234.]]
6. 6 Burstall, R. M., and J. Darlington. Some transformations for developing recursive programs. Proceedings of the International Conference on Reliable Software, Los Angeles, Calif., April 1975, pp. 465-472.]]
7. 7 Dijkstra, E. W. Notes on structured programming. In Structured Programming, Academic Press, New York, 1972.]]
8. 8 Hommel, G. (Ed.) Vergleich verschiedener Spezifikationsverfahren am Beispiel einer Paketverteilanlage. Kernforschungszentrum Karlsruhe GmbH, August, 1980. PDV- Report, KfK-PDV 186, Part 1.]]
9. 9 Knuth, D. E. Structured programming with goto statements. Computing Surveys 6, 4 (Dec. 1974).]]
10. 10 Parnas, D. L. On the criteria to be used in decomposing systems into modules. Comm. ACM 15, 12 (Dec. 1972), 1053-1058.]]
11. 11 Wirth, N. Program development by step-wise refinement. Comm. ACM 14, 4 (Aril 1971).]]

Index Terms

• Software and its engineering

  • Software creation and management

    • Software development process management

      • Software development methods