Nothing Special   »   [go: up one dir, main page]
Skip to main content
Springer Nature Link
Log in

Specification

  • Published:
Minds and Machines Aims and scope Submit manuscript

Abstract

The specification and implementation of computational artefacts occurs throughout the discipline of computer science. Consequently, unpacking its nature should constitute one of the core areas of the philosophy of computer science. This paper presents a conceptual analysis of the central role of specification in the discipline.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Subscribe and save

Springer+ Basic
$34.99 /Month
  • Get 10 units per month
  • Download Article/Chapter or eBook
  • 1 Unit = 1 Article or 1 Chapter
  • Cancel anytime
Subscribe now

Buy Now

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1

Similar content being viewed by others

Explore related subjects

Discover the latest articles, news and stories from top researchers in related subjects.

Notes

  1. Extreme programming, and even cowboy coding, may have very loose design strategies and no specified methodology of development, but they still have some goals.

  2. We shall not try and be precise about the notion of a functional specification. This rough characterisation will serve our purpose. Nor shall we be concerned with the full range of practical aspects of software engineering that involve requirements capture and design methodologies. Here we shall concentrate on what we take to be the central philosophical issue.

  3. “The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them.” (Bass 2003).

  4. Indeed, they are candidates for computer science examples of artificial kinds (Franssen 2009). There is much more that needs to be explored here, but it requires more space than we presently have.

  5. With more complex specifications we have to work much harder. While choosing the appropriate underlying ontological setting makes it possible to make precise most aspects of a specification (Turner R, Computable Models, 2009), it is a non-trivial task.

  6. One might suggest that ostensive definitions may be used as the basis of specification, and these may be based on physical devices. Suppose I request you to build me a stick of length one metre. Is this not to use a physical object, the stick in Paris, as the basis of a specification? Not in the sense that no abstract notion or device is involved. The length Metre is not something that changes with the length of the Paris stick. Once baptized, the length is fixed; it is the same in all possible worlds. There is clearly much more that might be said here, but it would take us too far afield.

  7. Perhaps the artificial kinds of computer science are encoding some notion of real essence for these artefacts and thereby determine what fit for use might be taken to be.

  8. This is not intended to be the same as the so called software/hardware distinction (Moor 1978).

  9. Much the same is true of those object-oriented approaches to software design e.g. (Eden 2011).

  10. Something akin to this is implicitly asserted in terms of clients and programmers, in (Morgan 1990).

  11. …the other is to interpret rules and axioms of form (C) as empirical claims concerning the possible behaviour of the target machine thereby described… (Fetzer 1988).

    … (C) is actually a prediction of what will occur when statement S is ultimately executed…It is a static prediction of its later dynamic execution (Colburn 2000).

  12. We shall now go more deeply into the debate about the nature of explanation and its connection with causation. The main focus here is in the role of testing and verification of scientific theories.

  13. Of course, specifications and designs do employ scientific and other knowledge; knowledge about how to construct the artefact. Often the difference is characterized as the difference between knowing how and knowing that (McCarthy 2006).

  14. The difference between a model and a theory is controversial and not that significant for the present discussion since the central point may be phrased in terms of theories or models. Anguis (2010) contains a very clear account of this distinction as applied to program construction.

References

  • Abrial, J. (1996). The B-book. Cambridge: Cambridge University Press.

    Book  MATH  Google Scholar 

  • Aho, A. S. (1985). Compilers principles, techniques and tools. Reading, Massachusetts: Addison-Wesley.

    Google Scholar 

  • Alan, J. (1994). Natural language understanding. London: Addison Wesley.

    Google Scholar 

  • Anguis, N. (2010). Abstraction and idelization in the verification of computer programs. Forthcoming.

  • Asperti, A. (2009). Social processes, program verification and all that. Mathematical Structures in Computer Science, 19(5), 877–896.

    Article  MathSciNet  MATH  Google Scholar 

  • Baier, C. J. (2008). Principles of model checking. Cambridge, MA.: MIT Press.

    MATH  Google Scholar 

  • Bass, L. C. (2003). Software architecture in practice. Pittsburgh: SEI.

    Google Scholar 

  • Bengt Nordström, K. P. (1990). Programming in Martin-Löf’s type theory. Oxford: Oxford University Press.

    MATH  Google Scholar 

  • Boghossian, P. (1989). The rule-following considerations. Mind, 98(392), 507–549.

    Article  MathSciNet  Google Scholar 

  • Chalmers, A. (1999). What is this thing called science. Maidenhead: Open University Press.

    Google Scholar 

  • Colburn, T. R. (2000). Philosophy and computer science. Explorations in philosophy, series. New York: M.E. Sharpe.

  • Dawes, J. (1991). The VDM-SL reference guide. London: Pitman.

    Google Scholar 

  • De Millo, R. A., & Lipton, R. J. (1979). Social processes and proofs of theorems and programs. Communications of the ACM, 22, 271–280.

    Article  MATH  Google Scholar 

  • Diller, A. Z. (1990). An introduction to formal methods. London: Wiley.

    MATH  Google Scholar 

  • Eden, A. (2011). Codecharts: Roadmaps and blueprints for object-oriented programs. Hoboken, NJ: Wiley-Blackwell.

    Google Scholar 

  • Edmund, M., & Clarke, J. O. (1999). Model checking. Boston: MIT Press.

    Google Scholar 

  • Fernandez, M. (2004). Programming languages and operational semantics: An introduction. London: King’s College Publications.

    MATH  Google Scholar 

  • Fetzer, J. (1988). Program verification: The very idea. Communications of the ACM, 31(9), 1048–1063.

    Article  Google Scholar 

  • Franssen, M. (2009). The philosophy of technology. Retrieved from Stanford encyclopedia of philosophy. http://plato.stanford.edu/entries/technology/.

  • Fuchs, N. (1992). Specifications are (preferably) executable. Software Engineering Journal, 7(5), 323–334.

    Article  Google Scholar 

  • Gluer, K. W. (2008). The normativity of meaning and content. Retrieved from Stanford encyclopedia of philosophy. http://plato.stanford.edu/entries/meaning-normativity/.

  • Grady Booch, J. R. (1999). The unified modeling language. Reading, Massachusetts: Adison Wesley.

    Google Scholar 

  • Gupta, A. (2008). Stanford encyclopedia of philosophy. Retrieved from definitions. http://plato.stanford.edu/entries/definitions/.

  • Hale, B. (1987). Abstract objects. Oxford: Basil Blackwell.

    Google Scholar 

  • Hale, B. (2001). The reason’s proper study. Oxford: Clarendon Press.

    Book  MATH  Google Scholar 

  • Horty, J. (2007). Frege on definitions. New York: Oxford University Press.

    Google Scholar 

  • Jacquette, D. (2002). Ontology. Chesham: Acumen Publishing Ltd.

    Google Scholar 

  • Jones, C. (1986). Systematic software development using VDM. Hemel Hemstead: Prentice Hall.

    MATH  Google Scholar 

  • Jones, C. (1990). Specifications are not (necessarily) harmful. Software Engineering Journal, 330–339.

  • Kripke, S. (1982). Wittgenstein on rules and private language. Boston: Harvard University Press.

    Google Scholar 

  • Kroes, P., & Meijers, A. (Eds.). (2006). The dual nature of technical artifacts. Special issue of Studies in History and Philosophy of Science, 37, 1–158.

  • McCarthy, N. (2006). Philosophy in the making. Ingenia, issue 26.

  • Milner, R. (1978). A theory of type polymorphism in programming. Jcss, 17, 348–375.

    MathSciNet  MATH  Google Scholar 

  • Moor, J. (1978). Three myths of computer science. British Journal for the Philosophy of Science, 29, 213–222.

    Google Scholar 

  • Morgan, C. (1990). Programming from specifications. London: Prentice Hall.

    MATH  Google Scholar 

  • O’Hearn, P. W. (2010). Abductive, inductive and deductive reasoning about resources. In csl: DBLP conference 2010. (pp. 49–50).

  • Pierce, B. (2002). Types and programming languages. London: The MIT Press.

    Google Scholar 

  • Plotkin, G. (2004). A structural approach to operational semantics. Journal of Logic and Algebraic Programming, 60–61, 17–139.

    MathSciNet  Google Scholar 

  • Potter, B. S. (1991). An introduction to formal specification and Z. New Jersey: Prentice Hall.

    MATH  Google Scholar 

  • Robinson, R. (1950). Definition. Oxford: Clarendon Press.

    Google Scholar 

  • Rosen, G. (2001). Abstract objects. Retrieved from Stanford encyclopedia of philosophy. http://plato.stanford.edu/entries/abstract-objects/.

  • Rosenberg, A. (2000). The philosophy of science. London: Routledge.

    Google Scholar 

  • Spivey, J. (1998). Understanding Z. Cambridge: Cambridge University Press.

    Google Scholar 

  • Stoy, J. (1977). Denotational semantics. Massachusetts: MIT.

    Google Scholar 

  • Turner, R. (1991). Constructive foundations for functional languages. New York: Prentice Hall.

    Google Scholar 

  • Turner, R. (2007). Understanding programming languages. Minds and Machines, 17(2), 129–133.

    Article  Google Scholar 

  • Turner, R. (2009). Computable models. New York: Springer.

    Book  MATH  Google Scholar 

  • Turner, R. (2010). Programming languages as mathematical theories. In J. Valllverdu, Thinking machines and the philosophy of computer science. IGI Global Publishers.

  • Vallverdu, J. (2010). Thinking machines and the philosophy of computer science. IGI Global.

  • Van Vliet, H. (2008). Software engineering: Principles and practice. Chichester: John Wiley.

    Google Scholar 

  • Woodcock, J. (1996). Using Z- specifications, refinement and proof. New Jersey: Prentice Hall.

    Google Scholar 

  • Zalta, E. (1983). Abstract objects. Dordrecht, New York: D. Reidel.

    Google Scholar 

Download references

Author information

Authors and Affiliations

  1. CSEE, Essex University, Colchester, Essex, CO79NB, UK

    Raymond Turner

Authors
  1. Raymond Turner
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Raymond Turner.

Rights and permissions

Reprints and permissions

About this article

Cite this article

Turner, R. Specification. Minds & Machines 21, 135–152 (2011). https://doi.org/10.1007/s11023-011-9239-x

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s11023-011-9239-x

Keywords

Search

Navigation