Peter Naur. Proof of algorithms by general snapshots. BIT, 6:310-316, 1966.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Verification The first approach to the development of correct software, known as verification, was to write a program and then try to prove that it meets its specification. Examples of post development correctness arguments can be found as early as 1966 with Naur s work on general snapshots [Nau66] The difficulty of performing such proofs quickly led to attempts at their automation. Examples of such program verification systems include the following: m EVES [Gru91b, ORA90] MALPAS [RTP90] and GVE [You87] Typically, verification tools take a specification and a program, and calculate the ....

Peter Naur. Proof of algorithms by general snapshots. BIT, 6:310--316, 1966.

....after van Wijngaarden s talk (see Section 2.2) The year 1966 saw a crucial step forward: the papers by Robert W Floyd (b1936) and Peter Naur (b1928) have a major in uence on subsequent work. It appears that Naur and Floyd developed their ideas independently of each other. 12 Naur s paper [Nau66] includes a nal note Similar concepts have been developed independently by Robert W. Floyd (unpublished paper, communicated privately) This is presumably a reference to the mimeographed version 9 Edsger Wybe Dijkstra (b1930) described in his Turing Award lecture [Dij72] how his decision to ....

....their publications were not a ected. Floyd s paper has been more in uential than Naur s largely because the former presents a more formal foundation, but it is clear that these independent contributions were both of great signi cance to research on program veri cation. Naur s General Snapshots [Nau66] are written as comments in the text of Algol 60 programs and are clear statements about the relationships between variables without being expressions in a formal language (see Figure 2) The arguments as to why they should be believed are similarly careful rather than formal. Naur s paper opens ....

P. Naur. Proof of algorithms by general snapshots. BIT, 6:310-316, 1966.

....with respect to program statements. 3 by sufficiently clear and informative sentences, or by combination of both. The important point is that the programmer has the means to gain clarity about the interface conditions between the building blocks out of which he composes his program [15]. An example of operation (S) is any whitebox component in Figure 1, with embedded starting and terminating points represented as Begin and End task primitives, redefined formally as BeginFork and EndJoin in the next section. Major requirements that are to be supported by the taskflow ....

....ffl InputPortList ffl InOutPortList ffl OutInPortList ffl OutputPortList ffl TaskInstanceList ffl TaskGraph MultiTaskBody ffl BeginFork ffl TaskInstance1 ffl TaskInstance2 ffl . ffl EndJoin ffl DataGraph Figure 4: A schema to represent taskflow layers. user composes his program [15], not on program verification. The main goals of this section are: 1) to present a taskflow schema based on the proposed taskflow architecture, and (2) to introduce a simple but effective taskflow scheduling algorithm. 4.1 Taskflow Schema The schema to construct a taskflow consists of mainly ....

P. Naur. Proof of Algorithms by General Snapshots. BIT, 6(4):310--316, 1966.

....of reasoning about component behavior Working Groups: Rigorous Behavioral Specification as an Aid to Reuse, Component Certification Tools, Frameworks and Processes Heym 1 1 Background Formal bases for methods of reasoning about the behavior of sequential programs have existed for some time. [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13] However, if you have explored these methods (based on the work of Floyd, Hoare, and Dijkstra) you may have doubts about their applicability to the ways you usually reason about programs. Recently, we developed a new formal basis, called the indexed method, and argued that, unlike the traditional ....

P. Naur, "Proof of algorithms by general snapshots," BIT, vol. 6, pp. 310--316, 1966.

.... sequential programs was made simpler by annotating them with properties about program states at specific points [Ran73] In the late sixties, Floyd, Hoare and Naur proposed axiomatic techniques for proving the consistency between sequential programs and such properties, called specifications [Flo67, Hoa69, Nau69]. Dijkstra showed how a formal calculus over such specifications could be used constructively to derive nondeterministic programs that meet them [Dij75] Specific techniques were also proposed to formally express intended properties for special kinds of programs, notably, datastructured ....

P. Naur, "Proofs of algorithms by General Snapshots", BIT Vol. 6, 1969, 310-316.

....logical constraints. Unlike executable specifications, run time assertions do check for the correctness of the output. Run time assertions (or simply assertions ) are based on either the requirements or the specification. Some of the earliest writing concerning assertions can be traced to [5, 9], and more recent research into giving programs the ability to check themselves during execution can be found in [12, 13, 2, 16] Further, Bieman and Yin recently discussed using assertions to increase fault detectability [1] however our contribution furthers the idea of run time assertions by ....

P. NAUR. Proof of algorithms by general snapshots. BIT, 6(4)310--316, 1966.

....the depth of function calls. Milner, 1972 [20] and Milner and Weyhrauch, 1972 [21] describe a proof checker for Scott s Logic for Computable Functions (Scott, 1970 [25] which uses computational induction. The most commonly used method is for flow diagram languages and was suggested by Naur, 1966 [23] and Floyd, 1967 [10] In this approach, inductive assertions are attached to points in a program and are used to generate verification conditions, which are theorems that must be proved to establish the correctness of the program. King 1969 [15] Good, 1970 [12] Cooper, 1971 [5] Gerhart, 1972 ....

Naur, P. Proof of algorithms by general snapshots. BIT 6 (1966), 310316.

....trust in ABS is based on the programming practice of using software assertions. Traditional run time assertion checking enhances software validation by helping to ensure that program states satisfy certain semantic constraints. Some of the earliest documentation on assertions can be traced to [9, 14], and more recent research into giving programs the ability to check themselves during execution can be found in [18, 19, 3, 1] While these ideas have generally addressed fault detection, our contribution to assertion theory is to modify it and apply it to increasing trust in ABS. The conjecture ....

P. NAUR. Proof of algorithms by general snapshots, BIT, 6(4):310--316, 1966.

No context found.

Peter Naur. Proof of algorithms by general snapshots. BIT, 6:310-316, 1966.

No context found.

Naur, P. Proof of algorithms by general snapshots. BIT 6, 310--316, 1966.

No context found.

Naur, P. Proof of Algorithms by General Snapshots. BIT, Vol. 6, 1966, pp 310-316.

No context found.

P. Naur. Proof of algorithms by general snapshots. BIT, 6:310--316, 1966.

No context found.

P. Naur. Proof of algorithms by general snapshots. BIT, 6:310--316, 1966.

No context found.

P. Naur. Proof of algorithms by general snapshots. BIT, 6:310--316, 1966.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC