Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....styles. A heavyweight specification is a complete specification with a well defined meaning for each specification clause; in particular, an omitted specification clause is interpreted as either true or false. By default, a heavyweight method specification is a total correctness specification [41]. In a lightweight specification, an omitted specification clause defaults to not specified, which means no interpretation is given. Thus, a lightweight specification can be used to state just what is desired by writing individual clauses that one is interested in. By default, a lightweight ....

....clause defaults to not specified, which means no interpretation is given. Thus, a lightweight specification can be used to state just what is desired by writing individual clauses that one is interested in. By default, a lightweight method specification is a partial correctness specification [41]. An informational description is another mechanism to escape from formality [87] JML s wealth of features o#ers many interesting challenges to runtime assertion checking, some of these features will be discussed in Section 1.3. 1.2 Objectives My ultimate research objective is to help ....

[Article contains additional citation context not shown here]

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, Inc., Englewood Cli#s, N.J., 1976.

....objects. We use logic meta programs to compose these composite aspect objects. Composition issues are more di#cult to resolve when we can dynamically add and remove aspects in an application. Modularization to manage complexity has always been one of the most important goals in computer science[Dij76, Par72]. This has been expressed with the development of new programming languages, i.e. crude assembly languages have been replaced with object oriented programming languages over the years. However, it has come to the attention that not all concerns can be easily modularized in the current programming ....

....such as procedural programming, structured programming, functional programming, logic programming and object oriented programming. These programming paradigms strive for better decomposition and modularization of programs. A better decomposition attributes to a better separation of concerns [Dij76, Par72]. Separation of concerns in a program has many benefits and is claimed to enhance the quality attributes of the source code [FBLL02, OT99] Adaptability: the lifespan of software increases and there is a need to let software evolve and adapt to new requirements. A better separation of concerns ....

Edsger W. Dijkstra. A Discipline of Programming. PrenticeHall, Englewood Cli#s, New Jersey, 1976.

....and program with concurrency in systems without these limitations, including improved implementations of Java. 1.2 As a Branch of Mathematics The second approach is to teach programming as a branch of mathematics. In this approach, the science is either limited to a restricted language, as in [13], or too fundamental to be of practical use, as in [37, 20, 29] The approach given by Dijkstra in [13] is practical but it only treats a restricted set of concepts. A promising continuation of [13] would be to extend it to more concepts. This is part of our approach, which is explained in ....

....of Java. 1.2 As a Branch of Mathematics The second approach is to teach programming as a branch of mathematics. In this approach, the science is either limited to a restricted language, as in [13] or too fundamental to be of practical use, as in [37, 20, 29] The approach given by Dijkstra in [13] is practical but it only treats a restricted set of concepts. A promising continuation of [13] would be to extend it to more concepts. This is part of our approach, which is explained in Section 2. 1.3 In Terms of Concepts The third approach is to teach programming in terms of the underlying ....

[Article contains additional citation context not shown here]

Edsger W. Dijkstra. A discipline of programming. Prentice Hall, 1997. Original publication in 1976.

....powerful our approach is, but look forward to a fruitful discussion at the workshop. 3 Technical Approach To define the semantics of our object oriented language in the full paper, we translate it into a more primitive language (cf. 11] which has a semantics defined by weakest preconditions [5, 15]. An object oriented program is deemed correct if and only if the resulting primitive program is correct. In this section, we make a few remarks about the full system. We require a kind of prefix closure property of declared components: for any subexpression p.f occurring in Comp(T , self) or ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Cliffs, NJ, 1976.

.... errors, we translate the source language into a verification condition in two steps [17] we first desugar the source language into a more primitive intermediate language and then compute verification conditions from the intermediate language according to the semantics of weakest preconditions [7, 21]. 1.0 Source language The source language operates on (implicitly declared) variables whose type is either integer or array of integer. The grammar of the source language is shown in Figure 0. To keep the language as simple as possible, an array A can be used only in the special Stmt : Id : ....

....off the hook if the inappropriate branch is chosen. 1.2 Verification conditions Verification condition formulas follow the same grammar as the predicates in the intermediate language shown in Figure 1. To translate from the intermediate language into formulas, we use weakest preconditions [7, 21]. For any command C and predicate R on the post state of C , the weakest precondition of C with respect to R , written 5 wp(C , R) characterizes the set of pre states of C from which execution terminates normally in a state satisfying R or terminates miraculously. Formally, we define wp over the ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Cliffs, NJ, 1976.

.... Pratt s string matcher Reconstructing the KMP appears to be a favorite in the program transformation community, in some sense following Knuth s steps since he obtained the behavior of the KMP by calculating it from Cook s construction [39, page 338] Examples include Dijkstra s use of invariants [24], Bird s tabulation technique [8] Takeichi and Akama s equational reasoning [53] Colussi s use of Hoare logic [17] and just recently Hernandez and Rosenblueth s logic program derivation [31] Further variants of the KMP can be found, e.g. in Watson s PhD thesis [54] and in Crochemore and ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

.... information 5 Related work The Knuth Morris Pratt matcher has been reconstructed many times in the program transformation community since Knuth s own construction (he ob9 tained it by calculating it from Cook s construction [24, page 338] Examples of the methods used are Dijkstra s invariants [12], Bird s recursion introduction and tabulation [5] Takeichi and Akama s equational reasoning [33] Colussi s Hoare logic [9] and Hernandez and Rosenblueth s logic program derivation [18] Bird s recursion introduction and tabulation is our closest related work. Bird derives the Morris Pratt ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

....hope that our argument provides a general foundation for checking program e#ects. To show the correctness of our technique, we give a formal semantics to programs and specifications, using the refinement calculus. The refinement calculus [2] is a framework based on weakest precondition calculus [8]. It allows expressing both programs and specifications in a unified notation with precise semantics based on higher order logic. Sets of states are modeled in the refinement calculus as predicates, here denoted by Pred. Programs and specifications are modeled as predicate transformers, here ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, Inc., 1976. 1

....by ocially admitted tools) However, an ocially admitted tool (like a compiler or theorem prover) is not necessarily fully veri ed. So for instance a compiler just needs to pass an ocial validation test suite. It is well known, that such tests do not suce nor replace correctness proofs [Dij76] Ocial IT certi cation prescriptions like those published by BSI in 1989 90 94 [ZSI89, ZSI90, BSI94] require: The compilers employed must be ocially validated and be admitted as implementation tools for Q7 systems by an ocial evaluation board. The terminus validated reveals that for tools ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

....way in which execution may terminate, and each must hold if the statement in question terminates in the given way. King and Morgan only consider one form of interruption statement, which they call exit. Translating King and Morgan s presentation of a wp semantics in the style of Dijkstra [Dij76] to one of Hoare style triples , we get the following rules (the [ brackets are used to trap abnormal executions in the same way as T in our C semantics) skip P # P exit # P Q Q [ s] Q # I Q I # B Q P # B The ....

Edsger W. Dijkstra. A discipline of programming. Prentice-Hall, 1976.

....they are allegedly telling us the results of all of the observations that we might make about some value p, but to which they are giving us no direct access. Must we accept their word that there really is some value p behind P First, there are certain healthiness conditions that P must satisfy [Dij76, Chapter 3]. These are rather like testing the plausibility of someone s alibis: was it really possible for someone to have been in these places at these times 1.5. Remark. The application of observations to a value p respects the lattice operations on the algebra of observations: truth: If the ....

Edsger Dijkstra. A Discipline of Programming. Prentice--Hall, 1976.

....noninterference is not sucient to prevent probabilistic information ows. Instead, we now need a probabilistic noninterference property, joint distribution of possible nal values of L variables [9] In the next section, we develop this idea more formally. The term is due to Dijkstra [3]. This observation can be credited to McLean [7] and Wittbold and Johnson [11] 4 Multi Threaded Programs as Markov Chains We assume that threads are written in a simple imperative language: c : skip j x : e j c 1 ; c 2 j if e then c 1 else c 2 j while e do c Integers are the only ....

Edsger Dijkstra, \A Discipline of Programming," Prentice Hall, 1976.

....the Proceedings of the 11th IEEE Computer Security Foundations Workshop, Rockport, MA, pages 34 43, June 1998. This material is based upon activities supported by DARPA and by the National Science Foundation under Agreement Nos. CCR 9612176 and CCR 9612345. Dijkstra calls an erratic daemon [3]. More realistically, we would expect a mechanicallyimplemented scheduler to be probabilistic. But with a probabilistic scheduler, a possibilistic noninterference property is no longer sucient indeed, it now becomes easy to construct well typed programs with probabilistic timing channels. We ....

Edsger Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

....Since then inference rules have been developed for function calls [23] non local branching [1] distributed [26] programs, functional programs [12] etc. Many of these were developed for simple, invented languages to clearly demonstrate a principle with a minimum of distracting detail. Dijkstra ([17], pp. 56 57) advocates that code should be designed for clear verification even if that makes failure characteristics worse. However the most reliable systems are built with experience and conservative, almost pessimistic or even redundant, design. Formal methods do not provide guidance about ....

....proof techniques become available, and even then will not be easy. 2.1.3 Dijkstra Dijkstra proposed constructing programs by simultaneously deriving and verifying them from the termination condition rather than the verification afterward orientation of Floyd and of Hoare. His 1976 book [17] explains how to use 5 his weakest precondition (wp) algebra and a simple nondeterministic specification language to develop software. This correct by construction philosophy is seen today in such things as the Cleanroom Approach [18] and the Spark Approach [4, p. vii] The general scheme of ....

[Article contains additional citation context not shown here]

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, Inc., 1976.

....with the invention of (what is now called) Hoare logic. However, his work was aimed at verifying that a program satisfies a specification, rather than deriving a program that satisfies a given specification. An important step forward came with the calculus of weakest preconditions, by Dijkstra [11]; this enabled the programmer to derive a program from a goal assertion that must be established. To this day, this is the most effective way of deriving imperative programs operating on arrays. A second step forward was the style of constructive functional programming introduced by Bird and ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

....counting: the preceding optimization could simulate the instruction counter by a single addition for each basic block. If the instruction counter must be checked for each instruction, the test can be performed once in advance of each basic block (e.g. by computing the weakest precondition [Dij75, Dij76] Because this latter optimization aborts executions early, the code producer may want control over how it is employed. A nal complication stems from including natural numbers and nite maps in the logic. These can be approximated by arbitrary precision arithmetic and functional data ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

....other classes cannot be expected to construct an industrial scale program for a course. Even if they could, one experience is insufficient. Because the project ends when the semester is over, students do not have the experience of needing to modify their code six months later. 2 Edsger Dijkstra [Dijkstra76] and David Gries [Gries81] suggest approaches to teaching programming that closely integrate proof techniques. Despite the elegance and apparent benefits of this approach, it has met with limited success. Students generally only use proof techniques when they are required to do so on small ....

Edsger Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

....to constructing programs top down. The idea of synthesising programs from constructive proofs has been used e.g. by Manna and Waldinger [ Takasu [9] and is also extensively used by Constable and his coworkers at Cornell University [1] Our example is Dijkstra s problem of the Dutch national flag [2]: construct a program, that given a sequence of objects, each having one of the colours red, white or blue, rearranges the objects so that they appear in the order of the Dutch flag. Programming Methodology Group, Dept. of Computer Sciences, Univ. of Goteborg, 412 96 Goteborg, Sweden. 1 In ....

.... List(A) List elimination C(nil) W [l 2 List(A) if achieved by a C(cons(x; y) W [l 2 List(A) x 2 A; y 2 List(A) z 2 C(y) if achieved by b(x; y; z) then achieved by listrec(l; a; b) 5 3 A Partitioning Problem In this section, we will derive a program for the Dutch flag problem [2] using lists. We will use the following general assumptions about the problem: We assume that A is a type, that Red, W hite and Blue are type valued functions (propositional functions) defined on A and that colour(x) is a (proof )object of the type (proposition) Red(x) W hite(x) Blue(x) In ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976. 13

....1.2 Strength reduction Incrementalization generalizes a basic programming technique found in virtually all treatments of programming, however formal. The motivating illustration below comes an undergraduate textbook written in 1978 [18] which credits Dijkstra for the phrase strength reduction [3]. We want an algorithm to compute the integer square root of an input x; that is, an S such that f0 xg S fz 2 x (z 1) 2 g. The and in the postcondition suggests a loop with one conjunct providing the test and the second an invariant [5] z : 0; while x (z 1) 2 do fz 2 xg ....

Edsger Wybe Dijkstra. A Discipline of Programming. Prentice-Hall, Englewood Cliffs, N.J., 1976.

....est d efini par un pr edicat sur les variables du mod ele. A chaque variable nous associons une modalit e choisie parmi les op erateurs de connaissance r epartie d efinis par Halpern [HM90] Les etats sont reli es entre eux par des transitions auxquelles sont associ ees des commandes gard ees [Dij76] Afin de mettre en evidence le m ecanisme de preuve associ e a la sp ecification, nous ajoutons a chaque transition une pr e et une post assertion. Elles d efinissent respectivement les hypoth eses a partir desquelles la transition est envisageable et l etat qui r esulte de l ex ecution de ....

Edsger Wybe Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

....Strength reduction Incrementalization generalizes a basic programming technique found in virtually all approaches to program refinement, however formal. The illustration below comes from an undergraduate textbook written in 1978 [20] which credits Dijkstra for the phrase strength reduction [3]. We use the notation fPgS fQg to express partial correctness, If precondition P holds then execution of program S establishes postcondition Q. We want an algorithm to compute the integer square root of an input x; that is, an S such that f0 xg S fz 2 x (z 1) 2 g The and in the ....

Edsger Wybe Dijkstra. A Discipline of Programming. Prentice-Hall, Englewood Cliffs, N.J., 1976.

....to gure out where in the system s program the requirements are addressed. To make this job easier all important requirements in a program should be addressed clearly and separately from other requirements. This is an important principle in software engineering, known as separation of concerns [31, 21]. The currently adopted way to achieve separation of concerns is modular decomposition. The goal is to decompose a system into smaller, relatively independent modules. When decomposed well, each module will handle a subset of the initial requirements and each requirement will be handled by only ....

....that a part of a decomposition is less complex when it deals with less concerns. Furthermore, none of the parts should deal with a concern that is already dealt with in another part. This principle is known as Separation of Concerns and is generally attributed to either Parnas [46] or Dijkstra [21]. A design process provides software engineers with conceptual techniques for decomposing a system so as to achieve separation of concerns. It is often believed that a design process should result in just one decomposition of a system. Bass et al. have the following two remarks on this: 1. There ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

....the standard object oriented programming language in industry, and because it is one of the most formal methods hostile languages in common use. This also shows students that the techniques can be applied to any language, not just one with clean semantics like Dijkstra s guarded command language [Dij76] Our overall goal is to expose students to formal speci cation techniques that are leading edge yet practical, and at the same time reinforce traditional software engineering skills. This ensures that even those students who will never use formal speci cations again will go away from the course ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976. 19

....as an excellent example of the design of algorithms that are non trivial, correct by construction, and yet within the scope of an introductory module on (formal) program design. The main simpli cation in our design is the use of Dijkstra s solution to the so called Dutch National Flag Problem [Dij76] rather than Hoare s partitioning program [Hoa61] Additionally, we re ne the invariant property used in the algorithm. This enhances the functionality of the algorithm in the sense that not only does it determine the K th smallest value in an array of values (as does Hoare s algorithm) but it ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

....which has the form proc m is S and declares that m is the name of a procedure with body S. A procedure body is a source statement in the simple untyped language shown in the left hand column of Figure 1. The language is a variation of the guarded command language in 5 troduced by Dijkstra [4], with some more recent additions (see, e.g. 11,0] It includes assignments, assert and assume statements, sequential composition, demonic choice, local variable introduction, and procedure calls. For simplicity, loops are not included, but recursion is allowed. An execution of a source ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Cli#s, NJ, 1976.

....a small intermediate language whose formal semantics is easy to define. Such a translation task is comparable to the compiler task of translating a source language into a more primitive intermediate language (like three address codes [0] We have used a variation of Dijkstra s guarded commands [10] as our intermediate language [23] An intermediate language is good at capturing the essence of executable code in the source language, but may not be well suited for capturing all important information in the source language, especially if the intermediate language lacks declarations and types. ....

....produces the intermediate language command assert is(s, T ) t = s That is, before the actual assignment of s to t, the command explicitly checks that the value of s is assignable to type T . After applying the semantics of the intermediate language, for example using weakest preconditions [10], the verification condition takes the shape . T : 1 S # ( # o, U : is(o, U) # . # . is(s, T ) # . This illustrates that one needs to prove is(s, T ) from the background predicate and from what is known about s. As alluded to above, ESC Modula 3 and ESC Java ....

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Cli#s, NJ, 1976.

....3 Instead, we now need a probabilistic noninterference property, which says that changing the initial values of H variables cannot change the joint distribution of possible final values of L variables [9] In the next section, we develop this idea more formally. 2 The term is due to Dijkstra [3]. 3 This observation can be credited to McLean [7] and Wittbold and Johnson [11] 4 Smith and Volpano 4 Multi Threaded Programs as Markov Chains We assume that threads are written in a simple imperative language: c : skip j x : e j c 1 ; c 2 j if e then c 1 else c 2 j while e do c ....

Edsger Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

....and related ideas in topology and category theory. In this paper we adopt a di#erent tack, taking as a cue various remarks made regarding the concept of an algorithm [Mac] as being in some sense a trajectory through some form of space. The notion of algorithm or program state space is not new [Dij76, p10] [DS89, pp4 5] but here we attempt to use diagrams to visualise the behaviour of di#erent algorithms, particularly those that implement the same function. A key goal here is to explore the notion of a geometry of algorithms as an aid to seeing the relationships between those of interest. The ....

Edsger W. Dijkstra. A Discipline of Programming. Automatic Computation. Prentice-Hall, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

No context found.

Edsger Dijkstra. The Discipline of Programming, Prentice-Hall, 1976.

No context found.

Edsger W. Dijkstra. The Discipline of Programming. Prentice Hall, Inc., Englewood Cli#s, NJ, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

No context found.

Edsger W. Dijkstra. The Discipline of Programming. Prentice Hall, Inc., Englewood Clis, NJ, 1976. 98

No context found.

Edsger W. Dijkstra. A Discipline of Programming (Prentice-Hall, Englewood Cli#s, N.J., 1976).

No context found.

Edsger Wybe Dijkstra. A Discipline of Programming. Prentice-Hall, Englewood Clis, New Jersey, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming (Prentice-Hall, Englewood Cli#s, N.J., 1976).

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Cli#s, NJ, USA, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Cli#s, NJ, USA, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming, chapter 27, In Retrospect, pages 209--217. Prentice-Hall, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Cliffs, NJ, 1976.

No context found.

Edsger Dijkstra. A Discipline of Programming. Prentice Hall, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice Hall, Englewood Cli#s, NJ, 1976.

No context found.

Edsger W. Dijkstra, A Discipline of Programming, Prentice-Hall, New Jersey, 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, Inc., Englewood Clis, N.J., 1976.

No context found.

Edsger W. Dijkstra. A Discipline of Programming. Prentice-Hall, 1976.

First 50 documents  Next 50

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