lect-4-electrifying-specs

lect-4-electrifying-specs - 4/8/2011 Formal methods 2...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
4/8/2011 1 CSE503: SOFTWARE ENGINEERING ELECTRIFYING SPECIFICATIONS David Notkin Spring 2011 Formal methods 503 11sp © UW CSE • D. Notkin 2 We’ve covered some of the basics, although there is much more out there – we’ll get to some of that One thing is clear so far: programs execute – they are kinetic – while formalisms just sit there – they represent potential This property makes many formalisms less attractive to many people, as the benefits are harder to see It is easier to change the specification to fit the program than vice versa .” Perlis Electrifying formalisms 503 11sp © UW CSE • D. Notkin 3 Daniel Jackson (and others) have worked on addressing this concern by “electrifying” formalisms – that is, making them “executable” in some sense, or at least providing useful feedback to a developer quickly Alloy is Jackson’s core approach to this, but it’s not the only one out there Executable specifications 503 11sp © UW CSE • D. Notkin 4 One way to electrify a formalism is to execute it – many formalisms represent high-level programs Google Scholar found ~95K entries to “executable specifications” Many such executable specifications look a lot like (various kinds of) logic programs or functional programs; much of this work is related to automatic programming The execution gives insight into what the specification means Performance of these “programs” is usually poor And automated refinement techniques to evolve from an executable specification to an efficient program seem to be limited This work goes back to at least 1976 with Darlington, Burstall, Manna and others
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
4/8/2011 2 Type checking 503 11sp © UW CSE • D. Notkin 5 Type checking is a good example of an electrified formalism – based on the type system and proof rules, the compiler reports immediately on situations where the program may be misusing typed values This is also a good example of an alternative style of electrification Rather than executing to “see what it does,” it rather compares two different views of the computation – what the types constrain and whether the program satisfies those constraints Comparing 503 11sp © UW CSE • D. Notkin 6 I believe that this comparative approach is extremely powerful – more powerful than the “let’s make higher-level specifications that we can execute” in the long-run In some sense, that was the idea of proving desirable properties from axioms – the axioms described relationships of an ADT, and the posited properties were alternative views of what should be true for that ADT But this wasn’t electrified in any sense Model checking 503 11sp © UW CSE • D. Notkin 7 Model checking is one of the bases for electrifying comparisons of program views We’ll look at this first from the high-level notion of model checking, then look at Alloy as an instance of electrified (bounded) model checking, and then look
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 02/24/2012 for the course CSE 503 taught by Professor Davidnotikin during the Spring '11 term at University of Washington.

Page1 / 9

lect-4-electrifying-specs - 4/8/2011 Formal methods 2...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online