Advertisement

Some Interdisciplinary Observations about Getting the “Right” Specification

  • Cliff B. Jones
Part of the Lecture Notes in Computer Science book series (LNCS, volume 4171)

Abstract

One can use formal approaches either post facto to try to show that a program has desirable properties or one can aim for verified by construction (VxC). The former approach tends to focus on specific properties such as avoiding the dereferencing of null pointers; the latter is more likely to address the question of whether the steps of design satisfy some overall specification. I not only prefer the latter but I have also argued that this is the main way to get formal methods to pay off: there is more mileage in getting a clean architecture than in trying to debug a bad design by retrofitting a proof.

Keywords

Null Pointer Advisory System Batch Processor Psychological Type Mammogram Image 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

References

  1. [Bjø05]
    Bjørner, D.: Software Engineering (3 vols.). Springer, Heidelberg (2005)MATHGoogle Scholar
  2. [DG06]
    Da Cunha, A.D., Greathead, D.: Does personality matter? an analysis of code-review ability. In: Communications of the ACM (in press, 2006)Google Scholar
  3. [HJJ03]
    Hayes, I., Jackson, M., Jones, C.: Determining the specification of a control system from that of its environment. In: Araki, K., Gnesi, S., Mandrioli, D. (eds.) FME 2003. LNCS, vol. 2805, pp. 154–169. Springer, Heidelberg (2003)CrossRefGoogle Scholar
  4. [JHJ06]
    Jones, C., Hayes, I., Jackson, M.: Specifying systems that connect to the physical world. Acta Informatica (submitted, 2006)Google Scholar
  5. [JJLM91]
    Jones, C.B., Jones, K.D., Lindsay, P.A., Moore, R.: mural: A Formal Development Support System. Springer, Heidelberg (1965)MATHGoogle Scholar
  6. [Jon96]
    Jones, C.B.: A rigorous approach to formal methods. IEEE, Computer 29(4), 20–21 (1996)MathSciNetCrossRefGoogle Scholar
  7. [Jon05]
    Jones, C.B.: Reasoning about the design of programs. Royal Soc. Phil. Trans. R Soc. A 363(1835), 2395–2396 (2005)CrossRefMATHGoogle Scholar
  8. [Mac94]
    MacKenzie, D.: Computer-related accidental death: an empirical exploration. Science and Public Policy 21, 233–248 (1994)Google Scholar
  9. [Mac01]
    MacKenzie, D.: Mechanizing Proof: Computing, Risk, and Trust. MIT Press, Cambridge (2001)MATHGoogle Scholar
  10. [Mac06]
    MacKenzie, D.: An Engine, Not a Camera: How Financial Models Shape Markets. MIT Press, Cambridge, Mass (2006)CrossRefGoogle Scholar
  11. [Per99]
    Perrow, C.: Normal Accidents. Princeton University Press, Princeton (1999)Google Scholar
  12. [Rea90]
    Reason, J.: Human Error. Cambridge University Press, Cambridge (1990)CrossRefGoogle Scholar
  13. [Rea97]
    Reason, J.: Managing the Risks of Organisational Accidents. Ashgate Publishing Limited (1997)Google Scholar
  14. [Rus99]
    Rushby, J.: Using model checking to help discover mode confusions and other automation surprises. In: Proceedings of 3rd Workshop on Human Error. HESSD 1999, pp. 1–18 (1999)Google Scholar
  15. [SPA03]
    Strigini, L., Povyakalo, A., Alberdi, E.: Human machine diversity in the use of computerised advisory systems: A case study. In: DSN 2003-IEEE International Conference on Dependable Systems and Networks, San Francisco, USA, pp. 249–258 (2003)Google Scholar
  16. [Wei71]
    Weinberg, G.M.: The Psychology of Computer Programming. Van Norstrand (1971)Google Scholar
  17. [WWW06]
    WWW (2006), www.dirc.org.uk

Copyright information

© Springer-Verlag Berlin Heidelberg 2008

Authors and Affiliations

  • Cliff B. Jones
    • 1
  1. 1.Newcastle UniversityNewcastleUK

Personalised recommendations