E.W. Dijkstra. Notes on Structured Programming, pages 1--82. Academic Press, 1972.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....to ten years [6, 8] Development disciplines which accommodate the size of these modern architectures must address a number of issues. Of particular importance, and the focus of this paper, is the adoption of techniques which enable tractable reasoning. Our inability to do much is well recognized [3]. The techniques used to reason about small programs do not scale in the large. In an e#ort to keep the logical size of our programs as small as possible, software should be built from small, well understood components that Proceedings of the 6 th Component Based Software Engineering workshop ....

E. W. Dijkstra. Notes on structured programming. In O. Dahl, E. Dijkstra, and C. Hoare, editors, Structured Programming, number 8 in A.P.I.C. Studies in Data Processing, chapter 1, pages 1--82. Academic Press, 1971.

....diagram not only by edges, but also by vertices. During this process, the test cases will be also systematically and scalable collected. 19 5. Related Work and Conclusion Since E.W. Dijkstra s critics Program testing can be used to show the presence of bugs, but never to show their absence. [DIJ1], we have almost a religious belief in some part of the academic community that testing should never be used as a verification method [DIJ2, BOYE] Nevertheless, testing is the most accepted and widely used method in the industrial software development, not only for verification of the software ....

E.W. Dijkstra, "Notes on Structured Programming", in O.J. Dahl et al. (ed.), "Structured Programming ", Academic Press, London, pp. 1-82, 1972

....by which we may climb above the mounting complexity of our ever growing systems. One common misconception is that we appear to know how to reason about small systems, so therefore we should be able to apply the same techniques directly to large systems. In his Notes on Structured Programming [4], Dijkstra exposes the fallacy of this argument: Apparently we are too much trained to disregard di#erences in scale, to treat them as gradual differences that are not essential . We tell ourselves that what we can do once, we can also do twice and by induction we fool ourselves into ....

E. W. Dijkstra. Notes on structured programming. In O. J. Dahl, E. W. Dijkstra, and C. A. R. Hoare, editors, Structured Programming. Academic Press, London, 1972.

....Software Architecture Architecture begins where engineering ends. Walter Gropius, Architect While system architecture is the blueprint of the overall system, software architecture is the blueprint of the software in the center of the system. Originally conceptualized by Dijkstra and Parnas [Dij72, Par01a, Par01b] software architecture is concerned with the perspectives of: global organization as a composition of components, global control structures, communication protocols, and . physical locations over which the system is distributed [Tom99] 6 Analogous to traditional ....

E. W. Dijkstra. Notes on structured programming. In Structured Programming. Academic Press, London, England, 1972.

....Reconsidered Jason . Hallstrom, Scott M. Pike, and Nigamanth Sridhar Computer and Information Science Ohio State University 2015 Neil Ave Columbus OH 43210 1277 USA hallstro ,pike, nsridhar cis. ohio state. edu ABSTRACT Software developers arc eager to increase the scale of their sofware products at a rate proportional to the growth of computing resources. Witit memory, bandwidth, and computing power doubling roughly every eigtheen months, ....

....opportunity for breaking the principles of encapsulation. These various hazards arc briefly described, and several techniques for ensuring safe use of the pattern are explored. 1. GOD S LAW In March 2001, Silicon Valley hosted the flagship con ference ACMi: Beyond Cyberspace [10] Witit 14 ple nary speakers forecasting the next 50 years of computing, it was a veritable pep rally for the knights errant of technology. Like most crusades, there was a motivating belief behind which the movers and shakers could unite. In the case of ACM1, that belief was in Moore s Law: the ....

[Article contains additional citation context not shown here]

E. W. Dijkstra. Notes on structured programming. In O. J. Dahl, E. W. Dijkstra, and C. A. R. Hoare, editors, Structured Programtaint. Academic Press, London, 1972.

....in this way (exclusive, adjacent test failures) produces the formula in (eq. 3) Like f 2 , it shows a linear combination of harmonics of f 1 . Since bounding the fail probability with values above 1 is never going to be of interest, it is unnecessary to calculate the formula over the range [1,3]. Over the range [0,3] f 3 is a probability density function (pdf) but the formula in (eq. 3) is not a pdf, due to its restricted range. 1 , 0 [ 1 ( 2 1 ( 4 ) 3 1 ( 3 2 ) 3 ( 2 2 2 3 L L L L N N N N Figure 4 The form of f 2 (L 0,N) f 2 As N ....

Dijkstra E. "Notes on Structured Programming" in Structured Programming Dahl O, Dijkstra E, Hoare C (Eds.) Academic Press 1972

....testing the workflow specification with some example scenarios before using it in a WFMS. But since a workflow specification can have infinitely many scenarios due to loops and data, not every possible scenario can be tested. The main disadvantage of testing is that, as Dijkstra pointed out [52], it shows the presence of errors, but not their absence. In other words, if the workflow specification passes all tests, it is still uncertain whether or not the workflow specification satisfies the requirement. Another disadvantage of testing is that repairing an erroneous model can still be ....

E.W. Dijkstra. Notes on structured programming. In O.-J. Dahl, E.W. Dijkstra, and C.A.R. Hoare, editors, Structured Programming.Academic Press, 1972.

....and membership query that the dictionary permits. Sometimes we use the term data structure by itself; the context resolves whether we mean an abstract or concrete data structure. Distinguishing an abstract from a concrete data structure derives from the use of the term abstraction by Dijkstra [Dij72] and Hoare [Hoa72] Finally, an augmented data structure is an abstract data structure D that is derived from some other abstract data structure D by the addition of a new operation. For example, a rank dictionary is an augmented dictionary, allowing not only insert, delete, and ....

E. W. Dijkstra. Notes on structured programming. In C. A. R. Hoare, editor, Structured Programming, pages 1--82. Academic Press, London, 1972.

....give the prospects for future work. 2 RELATED WORK The refinement topic has been investigated in various fields such as structured programming, process theory, and theory of abstract data types. In the context of structured programming the concept of refinement already appeared in the Eighties [13, 40]. An abstract specification is translated into an efficient program via a sequence of correctness preserving refinement steps. Refinement techniques which preserve the properties of a program and rules for program transformation were subject of several studies (e.g. 19, 3] The weakest ....

E.W. Dijkstra. Notes on Structured Programming. In O.J. Dahl, E.W. Dijkstra, and C.A.R. Hoare, editors, Structured Programming, chapter 1, pages 1--82. Academic Press, 1971. A.P.I.C. Studies in Data Processing, No. 8.

....space of the problem is constrained or only a portion of the program is actually verified. General theorem provers, model checkers, state machine analyzers, and tools customized to particular applications have all been used to prove such systems. 6 3. 3 Software Testing : Dijkstra s criticism [21], Program testing can be used to show the presence of bugs, but never to show their absence is well known. From his point of view, any amount of testing represents only a small sampling of all possible computations and therefore never adequate to assure the expected behavior of the program under ....

E.W. Dijkstra, "Notes on Structured Programming", in O.J. Dahl, et al. (ed.), "Structured Programming", Academic Press, London, pp. 1-82, 1972.

....and changeable in ways that are difficult to manage, what shall we do One answer for all the above questions are creating program families. Program familyoriented software development was suggested by Dijkstra and others in the software Introduction 2 engineering literature as early as 1972 [11]. David L. Parnas described approaches for building software families in the mid 1970s [19] We take the definition of a program family from Parnas s paper [19] We consider a set of programs to constitute a family whenever it is worthwhile to study programs from the set by first studying the ....

Dijkstra, E. W., "Notes on Structured Programming". Structured Programming, O.J. Dahl, E.W. Dijkstra, C.A.R.Hoare, eds., Academic Press, London, 1972. Bibliography 79

....not be sure that a software system will continue to produce correct results for previously successful test cases. Moreover, it may also be difficult to reproduce erroneous results with test cases that exposed failures on previous executions. The limitations of testing have long been recognized [Dij] Formal verification techniques, based on theorem proving, were originally proposed to counter some of these limitations [Flo67] Formal verification techniques attempt # This research was partially supported by the U.S. Department of Defense Army and the Defense Advance Research Projects Agency ....

E. W. Dijkstra. Notes on Structured Programming, chapter 1, pages 1--82.

....how retrenchment can relate incompatible partial models to a more definitive consolidated model during the development of the contracted specification. 1. Introduction Formal refinement, in its various guises, has a long and distinguished history. From the early papers of Wirth, Dijkstra, Hoare [1, 2, 3], it has developed into a large and vibrant field of research. A comprehensive survey would be out of place here, but modern accounts in the spirit of the original work can be found in [4, 5] In all of these the assumption is that one knows already what the abstract model is, and all one has to ....

....(3.14) and (3.16) and a suitably relabelled (4.5) and (4.7) into (5. 3) After some simplification and further manipulation we get: E CF CH,connect n (u, w, o, q; i, k, u, w) busy(k) 1] k holtab fortab (k) z free(z) u = u o = NO q = OK w = calls n z , fortab, holtab) [2] (k holtab fortab (k) z free(z) u = u o = NO q = OK w = calls n z , fortab, holtab) 3] k holtab (fortab (k) z free(z) u = u w = w o = NO q = Our . hold. 100 ) 4] k holtab fortab (k) z free(z) u = calls n z w = w o = OK q = ....

[Article contains additional citation context not shown here]

Dijkstra E. W. (1972); Notes on Structured Programming. in: Structured Programming, Academic Press.

....reasonable to relax the requirement of observational equivalence somewhat, and to allow or even enforce certain improvements in behavior as well as optimization of non functional goals. This generalization puts refactoring close to the well known concept of re nement, as pioneered by Dijkstra [12], Wirth [34] and Bauer [2] Although many approaches use the concept of behavior preserving or re ning transformations, the rst approaches to explicitly make use of behavioral equivalence and re nement were algebraic speci cation techniques. For example, OBJ [14] employs hidden sorts that ....

....a class diagram notation (essentially a subset of today s UML [17] The goal is to improve the design of the system for further maintenance and extension. Re nement Calculus [1] is a framework for the stepwise derivation of imperative programs from a speci cation, based on early work of Dijkstra [12] and Wirth [34] As a veri cation methodology, re nement calculus is quite successful; as a software development methodology, it has its weak points, as pointed out by Michael Jackson [19] You must already have solved the problem before the solution process is begun . Computer Aided ....

E.W. Dijkstra. Notes on structured programming. In C.A.R. Hoare O. Dahl, E.W. Dijkstra, editor, Structured Programming. Academic Press, 1971.

....factor in this inability is inadequate techniques for organizing concerns and defining their composition. Ideally, each concern is encapsulated as a single, self contained software module. Several mechanisms for defining modules are in common practice. These include layering[1] stepwise refinement[2], and information hiding[8] These mechanisms underlie much of the progress in software engineering, and they are fundamental to the notion of objectoriented programming. An important insight is that standard practice allows only some concerns to be separated. The conventional mechanisms rely ....

E. W. Dijkstra, Notes on Structured Programming, In Structured Programming, Academic Press, pp. 1-82, 1972.

.... which seeks to incrementalize the copying of aggregates, in his purely functional programming language, EAS, a packaging of the typed calculus as extended with homogeneous sets [210, 211, 212] Transformational programming can be regarded as a formalization of Dijkstra s stepwise refinement [57, 58]. As Bloom and Paige [28] point out, the transformational methodology is able to do much more than merely optimize code, or translate a SETLlike language into a C like one. By helping the algorithm designer reason about time and space complexity in syntactic terms rather than only by means of ....

Edsger W. Dijkstra. Notes on structured programming. In Structured Programming, pages 1--82. Academic Press, 1972. 403

....line and they have no way for staging the resources they consume, so that an assessment of the principal feasibility and benefits of product line development can be performed with relatively little effort. On the other hand there are approaches around which provide this at least partially (cf. [3, 4]) They in turn lack the ability to be linked to an approach that provides a clear economic argument for a scope. Further, there are some additional requirements we find relevant to a scoping approach in order to make it practically useful. These are: A scoping approach should be integrated with ....

....useful. These are: A scoping approach should be integrated with an overall product line development approach, so that it is ensured that the results are directly useful to the development approach and so that no work is duplicated. As so far except for some domain scoping approaches (i.e. [3, 4]) all scoping approaches are not integrated with any domain engineering or product line development approach, this is a rather strong requirement. The approach should provide detailed guidance so that it is also applicable by somebody else but the developer of the method. This is actually a ....

[Article contains additional citation context not shown here]

E.W. Dijkstra, Notes on structured programming, O,J. Dahl, E.W. Dijkstra, C.A.R. Hoare, edss., Academic Press, London 1972.

....of the program and then filling in the details. The refinement process consists of a sequence of steps; in each refinement step, brief program names are replaced by more detailed descriptions until the text consists completely of executable code. Good illustrations of this idea can be found in [3, 21]. Stepwise refinement is undoubtedly useful during program development, but the structure becomes less visible with each refinement step. The final program is likely to be correct and well structured, but there is no record of the refinement steps in the code. Moreover, in the earlier steps, the ....

Dijkstra, E.W. "Notes on Structured Programming" Structured Programming, Dahl, O-J., Dijkstra, E.W., Hoare, C.A.R. (Ed.), Academic Press, 1972.

No context found.

E.W. Dijkstra. Notes on Structured Programming, pages 1--82. Academic Press, 1972.

No context found.

E. W. Dijkstra. Notes on structured programming. In O.-J. Dahl, E. W. Dijkstra, and C. A. R. Hoare, editors, Structured Programming, pages 1--82. Academic Press, 1972.

No context found.

Edsgar W. Dijkstra. Notes on structured programming. In O. J. Dahl, E. W. Dijkstra, and C. A. R. Hoare, editors, Structured Programming. Academic Press, 1972.

No context found.

E. W. Dijkstra. Notes on Structured Programming. In O.-J. Dahl, E. W. Dijkstra, and C. A. R. Hoare, editors, Structured Programming, pages 1--72. Academic Press, 1972.

No context found.

Edsger W. Dijkstra. Notes on structured programming. In Ole-Johan Dahl, Edsger W. Dijkstra, and C. A. R. Hoare, editors, Structured Programming, chapter 1, pages 1--82. Academic Press, London, 1972.

No context found.

E. W. Dijkstra, Notes on Structured Programming. London: Academic Press, 1972.

No context found.

Dijkstra E. W. (1972); Notes on Structured Programming. in: Structured Programming, Academic Press.

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