<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Using Small-Step Refinement for Algorithm Verification in Computer Science Education</article-title>
      </title-group>
      <contrib-group>
        <aff id="aff0">
          <label>0</label>
          <institution>Danijela Petrovic ́ Faculty of Mathematics University of Belgrade Belgrade</institution>
          ,
          <country country="RS">Serbia</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Stepwise program refinement techniques can be used to simplify program verification. Programs are better understood since their main properties are clearly stated, and verification of rather complex algorithms is reduced to proving simple statements connecting successive program specifications. Additionally, it is easy to analyze similar algorithms and to compare their properties within a single formalization. Usually, formal analysis is not done in an educational setting due to complexity of verification and a lack of tools and procedures to make comparison easy. Verification of an algorithm should not only give a correctness proof, but also better understanding of an algorithm. If the verification is based on small step program refinement, it can become simple enough to be demonstrated within the university-level computer science curriculum. In this paper we demonstrate this and give a formal analysis of two well known algorithms (Selection Sort and Heap Sort) using the proof assistant Isabelle/HOL and program refinement techniques.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Introduction</p>
      <p>
        There are many tools for automated program verification. Many of early results in mechanical
program verification were carried out by Boyer and Moore using their theorem prover. Today,
verification uses SMT solvers [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ],[
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] and systems such as ESC/Java [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], CBMC [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ], Astre´e [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ], PEX [
        <xref ref-type="bibr" rid="ref19">19</xref>
        ],
KLEE [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ], Calysto [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ] and there are many more that are less used. Some are specialized for verification
of C-programs [
        <xref ref-type="bibr" rid="ref17">17</xref>
        ]. However these tools still require significant annotations from the programmer to
construct a proof. Many of them cannot verify complex systems. Several tools attempt to uncover design
flaws using test vectors to examine specific executions of a software system. Some tools, on the other
hand, can check the behavior of a design for all input vectors.
      </p>
      <p>
        Proving full functional correctness of a program has been and still is a great challenge for fully
automated systems, and for this purpose, usually an interactive approach is applied. Formalized mathematics
and interactive theorem provers (sometimes referred to as proof assistants) have made great progress in
recent years. Many classical mathematical theorems have been formally proved and proof assistants have
been intensively used in hardware and software verification. Theorem provers that are most commonly
used for program verification nowadays are Isabelle [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ], Isabelle/HOL [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ], Coq [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ], PVS [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ], HOL
Light [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], etc.
      </p>
      <p>Using program verification within computer science education. Program verification is usually
considered to be too hard and long process that acquires good mathematical background. A verification of
a program is performed using mathematical logic. Having the specification of an algorithm inside the
logic, its correctness can be proved again by using the standard mathematical apparatus (mainly
induction and equational reasoning). These proofs are commonly complex and the reader must have some
knowledge about mathematical logic. The reader must be familiar with notions such as satisfiability,
validity, logical consequence, etc. Any misunderstanding leads into a loss of accuracy of the verification.
These formalizations have a common disadvantage, they are too complex to be understood by students,
and this discourages students most of the time. Therefore, programmers and their educators rather use
traditional (usually trial-and-error) methods.</p>
      <p>
        However, many authors claim that nowadays education lacks the formal approach and it is clear why
many advocate in using proof assistants [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ]. This is also the case with computer science education.
Students are presented many algorithms, but without formal analysis, often omitting to mention when
algorithm would not work properly. Frequently, the center of a study is implementation of an algorithm
whereas understanding of its structure and its properties is put aside. Software verification can bring more
formal approach into teaching of algorithms and can have some advantages over traditional teaching
methods.
      </p>
      <p>Verification helps to point out what are the requirements and conditions that an algorithm satisfies
(pre-conditions, post-conditions and invariant conditions) and then to apply this knowledge during
programming. This would help both students and educators to better understand input and output
specification and the relations between them.</p>
      <p>Though a program might work in general, it can happen that it does not work for some inputs and
students must be able to detect these situations and to create software that works properly for all
inputs.</p>
      <p>It is suitable to separate the abstract algorithm from its specific implementation. Students can
compare properties of different implementations of the same algorithms, to see the benefits of one
approach or another. Also, it is possible to compare different algorithms for the same purpose
(for example, for searching element, sorting, etc.) and this could help in overall understanding of
algorithm construction techniques.
Therefore, lessons learned from formal verification of an algorithm can improve someones style of
programming.</p>
      <p>Modularity and refinement. The most used languages today are those who can easily be compiled
into efficient code. Using heuristics and different data types makes code more complex and seems like
a perplex mixture to novices of many new notions, definitions, concepts. These techniques and methods
in programming makes programs more efficient but are rather hard to be intuitively understood. On
the other hand, modularity is a highly accepted principle in nowadays programming. Adhering to this
principle enables programmer to easily maintain the code.</p>
      <p>
        The best way to apply modularity on program verification and to make verification flexible enough to
add new capabilities to the program keeping current verification intact is program refinement. Program
refinement is the verifiable transformation of an abstract (high-level) formal specification into a concrete
(low-level) executable program. It starts from the abstract level, describing only the requirements for
input and output. Implementation is obtained at the end of the verification process (often by means of
code generation [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]). Stepwise refinement allows this process to be done in stages. There are many
benefits of using refinement techniques in verification.
      </p>
    </sec>
    <sec id="sec-2">
      <title>It gives a better understanding of programs that are verified.</title>
    </sec>
    <sec id="sec-3">
      <title>The algorithm can be analyzed and understood on different level of abstraction.</title>
      <p>It is possible to verify different implementations for some part of the program, discussing the
benefits of one approach or another.</p>
      <p>It can be easily proved that these different implementation share some same properties which are
proved before splitting into two directions.</p>
      <p>It is easy to maintain the code and the verification. Usually, whenever the implementation of the
program changes, the correctness proofs must be adapted to these changes, and if refinement is
used, it is not necessary to rewrite the entire verification, just add or change a small part of it.
Using refinement approach makes an algorithm suitable for a case study in teaching. Properties
and specifications of the program are clearly stated and it helps teachers and students better to
teach or understand them.</p>
      <p>We claim that the full potential of refinement comes only when it is applied stepwise, and in many
small steps. If the program is refined in many steps, and data structures and algorithms are introduced
one-by-one, then proving the correctness between the successive specifications becomes easy.
Abstracting and separating each algorithmic idea and each data-structure that is used to give an efficient
implementation of an algorithm is a very important task in programmer education.</p>
      <p>As an example of using small step refinement, in this paper we analyze two widely known algorithms,
Selection Sort and Heap Sort. There are many reasons why we decided to use them.</p>
      <p>They are largely studied in different contexts and they are studied in almost all computer science
curricula.</p>
      <p>They belong to the same family of algorithms and they are good example for illustrating the
refinement techniques. They are a nice example of how one can improve on a same idea by introducing
more efficient underlying data-structures and more efficient algorithms.</p>
      <p>Their implementation uses different programming constructs: loops (or recursion), arrays (or lists),
trees, etc. We show how to analyze all these constructs in a formal setting.</p>
      <p>There are many formalizations of sorting algorithms that are done both automatically or interactively
and they undoubtedly proved that these algorithms are correct. In this paper we are giving a new approach
in their verification, that insists on formally analyzing connections between them, instead of only proving
their correctness (which has been well established many times). Our central motivation is that these
connections contribute to deeper algorithm understanding much more than separate verification of each
algorithm.</p>
      <p>The paper gives a clear picture of central ideas relevant for verification by means of small step
refinement. We give all definitions, but some proofs and implementations are omitted, and can be found
in Isabelle/HOL formalization1.
2</p>
    </sec>
    <sec id="sec-4">
      <title>1Available http://www.matf.bg.ac.rs/ danijela/ssort.zip</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>Alessandro</given-names>
            <surname>Armando</surname>
          </string-name>
          , Jacopo Mantovani &amp; Lorenzo
          <string-name>
            <surname>Platania</surname>
          </string-name>
          (
          <year>2009</year>
          ):
          <article-title>Bounded model checking of software using SMT solvers instead of SAT solvers</article-title>
          .
          <source>International Journal on Software Tools for Technology Transfer</source>
          <volume>11</volume>
          (
          <issue>1</issue>
          ), pp.
          <fpage>69</fpage>
          -
          <lpage>83</lpage>
          , doi:10.1007/11691617 9.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>Domagoj</given-names>
            <surname>Babic</surname>
          </string-name>
          &amp;
          <string-name>
            <surname>Alan J Hu</surname>
          </string-name>
          (
          <year>2008</year>
          )
          <article-title>: Calysto</article-title>
          . In: Software Engineering,
          <year>2008</year>
          . ICSE'08. ACM/IEEE 30th International Conference on, IEEE, pp.
          <fpage>211</fpage>
          -
          <lpage>220</lpage>
          , doi:10.1145/1368088.1368118.
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>Yves</given-names>
            <surname>Bertot</surname>
          </string-name>
          &amp;
          <article-title>Pierre Caste´ran (</article-title>
          <year>2004</year>
          )
          <article-title>: Interactive theorem proving and program development: Coq'Art: the calculus of inductive constructions</article-title>
          . springer, doi:10.1007/978-3-
          <fpage>662</fpage>
          -07964-5.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>Armin</given-names>
            <surname>Biere</surname>
          </string-name>
          , Alessandro Cimatti, Edmund M Clarke,
          <string-name>
            <given-names>Ofer</given-names>
            <surname>Strichman</surname>
          </string-name>
          &amp; Yunshan
          <string-name>
            <surname>Zhu</surname>
          </string-name>
          (
          <year>2003</year>
          ):
          <article-title>Bounded model checking</article-title>
          .
          <source>Advances in computers 58</source>
          , pp.
          <fpage>117</fpage>
          -
          <lpage>148</lpage>
          , doi:10.1016/S0065-
          <volume>2458</volume>
          (
          <issue>03</issue>
          )
          <fpage>58003</fpage>
          -
          <lpage>2</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>Bruno</given-names>
            <surname>Blanchet</surname>
          </string-name>
          , Patrick Cousot, Radhia Cousot, Je´roˆme Feret, Laurent Mauborgne, Antoine Mine´,
          <string-name>
            <given-names>David</given-names>
            <surname>Monniaux</surname>
          </string-name>
          &amp; Xavier
          <string-name>
            <surname>Rival</surname>
          </string-name>
          (
          <year>2002</year>
          )
          <article-title>: Design and implementation of a special-purpose static program analyzer for safety-critical real-time embedded software</article-title>
          .
          <source>In: The Essence of Computation</source>
          , Springer, pp.
          <fpage>85</fpage>
          -
          <lpage>108</lpage>
          , doi:10.1007/3-540-36377-7
          <fpage>5</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>Cristian</given-names>
            <surname>Cadar</surname>
          </string-name>
          , Daniel Dunbar &amp;
          <string-name>
            <surname>Dawson R Engler</surname>
          </string-name>
          (
          <year>2008</year>
          )
          <article-title>: KLEE: Unassisted and Automatic Generation of High-Coverage Tests for Complex Systems Programs</article-title>
          .
          <source>In: OSDI, 8</source>
          , pp.
          <fpage>209</fpage>
          -
          <lpage>224</lpage>
          . Available at https: //www.usenix.org/legacy/events/osdi08/tech/full_papers/cadar/cadar_html/.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>Edmund</given-names>
            <surname>Clarke</surname>
          </string-name>
          , Daniel Kroening &amp; Flavio
          <string-name>
            <surname>Lerda</surname>
          </string-name>
          (
          <year>2004</year>
          )
          <article-title>: A tool for checking ANSI-C programs</article-title>
          .
          <source>In: Tools and Algorithms for the Construction and Analysis of Systems</source>
          , Springer, pp.
          <fpage>168</fpage>
          -
          <lpage>176</lpage>
          , doi:10.1007/978-3-
          <fpage>540</fpage>
          -24730-2
          <fpage>15</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>Cormac</given-names>
            <surname>Flanagan</surname>
          </string-name>
          ,
          <string-name>
            <surname>K Rustan M Leino</surname>
            ,
            <given-names>Mark</given-names>
          </string-name>
          <string-name>
            <surname>Lillibridge</surname>
          </string-name>
          , Greg Nelson,
          <string-name>
            <surname>James B Saxe &amp; Raymie Stata</surname>
          </string-name>
          (
          <year>2002</year>
          ):
          <article-title>Extended static checking for Java</article-title>
          .
          <source>In: ACM Sigplan Notices</source>
          ,
          <volume>37</volume>
          , ACM, pp.
          <fpage>234</fpage>
          -
          <lpage>245</lpage>
          , doi:10.1145/543552.512558.
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <surname>Robert</surname>
            <given-names>W Floyd</given-names>
          </string-name>
          (
          <year>1967</year>
          ):
          <article-title>Assigning meanings to programs</article-title>
          .
          <source>Mathematical aspects of computer science</source>
          <volume>19</volume>
          (
          <fpage>19</fpage>
          -
          <lpage>32</lpage>
          ), p.
          <volume>1</volume>
          ,
          <issue>doi</issue>
          :10.1007/
          <fpage>978</fpage>
          -94-011-1793-7
          <fpage>4</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>Florian</given-names>
            <surname>Haftmann</surname>
          </string-name>
          (
          <year>2008</year>
          ):
          <article-title>Code generation from Isabelle/HOL theories</article-title>
          .
          <source>doi:10.1.1.278</source>
          .5329. Available at http://www.cl.cam.ac.uk/research/hvg/Isabelle.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <given-names>John</given-names>
            <surname>Harrison</surname>
          </string-name>
          (
          <year>2009</year>
          )
          <article-title>: HOL light: An overview</article-title>
          .
          <source>In: Theorem Proving in Higher Order Logics</source>
          , Springer, pp.
          <fpage>60</fpage>
          -
          <lpage>66</lpage>
          , doi:10.1007/978-3-
          <fpage>642</fpage>
          -03359-9
          <fpage>4</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12]
          <string-name>
            <given-names>Charles</given-names>
            <surname>Antony Richard Hoare</surname>
          </string-name>
          (
          <year>1969</year>
          )
          <article-title>: An axiomatic basis for computer programming</article-title>
          .
          <source>Communications of the ACM</source>
          <volume>12</volume>
          (
          <issue>10</issue>
          ), pp.
          <fpage>576</fpage>
          -
          <lpage>580</lpage>
          , doi:10.1145/357980.358001.
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13] Ce´sar
          <string-name>
            <given-names>A</given-names>
            <surname>Munoz &amp; Ramiro A Demasi</surname>
          </string-name>
          (
          <year>2012</year>
          )
          <article-title>: Advanced Theorem Proving Techniques in PVS and Applications</article-title>
          .
          <source>In: Tools for Practical Software Verification</source>
          , Springer, pp.
          <fpage>96</fpage>
          -
          <lpage>132</lpage>
          , doi:10.1007/978-3-
          <fpage>642</fpage>
          -35746-6
          <fpage>4</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <given-names>Tobias</given-names>
            <surname>Nipkow</surname>
          </string-name>
          (
          <year>2012</year>
          )
          <article-title>: Teaching semantics with a proof assistant: No more LSD trip proofs</article-title>
          . In: Verification,
          <string-name>
            <given-names>Model</given-names>
            <surname>Checking</surname>
          </string-name>
          , and Abstract Interpretation, Springer, pp.
          <fpage>24</fpage>
          -
          <lpage>38</lpage>
          , doi:10.1007/978-3-
          <fpage>642</fpage>
          -27940-9
          <fpage>3</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <surname>Tobias</surname>
            <given-names>Nipkow</given-names>
          </string-name>
          , Lawrence C Paulson &amp; Markus Wenzel (
          <year>2002</year>
          )
          <article-title>: Isabelle/HOL: a proof assistant for higherorder logic</article-title>
          . 2283, Springer, doi:10.1007/3-540-45949-9.
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [16]
          <string-name>
            <surname>Lawrence</surname>
            <given-names>C Paulson</given-names>
          </string-name>
          (
          <year>1994</year>
          ):
          <article-title>Isabelle: A generic theorem prover</article-title>
          . 828, Springer, doi:10.1007/BFb0030541.
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [17]
          <string-name>
            <given-names>Junyan</given-names>
            <surname>Qian</surname>
          </string-name>
          &amp; Baowen
          <string-name>
            <surname>Xu</surname>
          </string-name>
          (
          <year>2007</year>
          ):
          <article-title>Formal verification for C program</article-title>
          .
          <source>Informatica</source>
          <volume>18</volume>
          (
          <issue>2</issue>
          ), pp.
          <fpage>289</fpage>
          -
          <lpage>304</lpage>
          . Available at http://www.mii.lt/informatica/pdf/INFO672.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [18]
          <string-name>
            <given-names>Gregory</given-names>
            <surname>Tassey</surname>
          </string-name>
          (
          <year>2002</year>
          ):
          <article-title>The economic impacts of inadequate infrastructure for software testing</article-title>
          .
          <source>National Institute of Standards and Technology, RTI Project</source>
          <volume>7007</volume>
          (
          <issue>011</issue>
          ). Available at http://www.nist.gov/ director/planning/upload/report02-
          <fpage>3</fpage>
          .pdf.
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [19]
          <string-name>
            <given-names>Nikolai</given-names>
            <surname>Tillmann &amp; Jonathan De Halleux</surname>
          </string-name>
          (
          <year>2008</year>
          ):
          <article-title>Pex-white box test generation for. net</article-title>
          .
          <source>In: Tests and Proofs</source>
          , Springer, pp.
          <fpage>134</fpage>
          -
          <lpage>153</lpage>
          , doi:10.1007/978-3-
          <fpage>540</fpage>
          -79124-9
          <fpage>10</fpage>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>