Algorithm Analysis and the Transition to Software

ACM Computing Surveys, 2001

A "refinement" is a functionality addition to a software project that can affect multiple dispersed implementation entities (functions, classes, etc.). In this paper, we examine large-scale refinements in terms of a fundamental object-oriented technique called collaboration-based design. We explain how collaborations can be expressed in existing programming languages or can be supported with new language constructs (which we have implemented as extensions to the Java language). We present a specific expression of large-scale refinements called mixin layers, and demonstrate how it overcomes the scalability difficulties that plagued prior work. We also show how we used mixin layers as the primary implementation technique for building an extensible Java compiler, JTS. The definition of "refinement" that seems closest to our intended meaning is "the act of making improvement by introducing subtleties or distinctions" (Merriam-Webster's Dictionary). Formal approaches to programming use the term "refinement" to denote the elaboration of a program by adding more implementation detail until a fully concrete implementation is reached. The set of behaviors (i.e., the legal variable assignments) of a "refined" program is a subset of the behaviors of the original "unrefined" program. This appears to be different from our use of the term. Our "refinements" follow the dictionary definition by adding "subtleties or distinctions" at the design level. At the implementation level, however, a refinement can yield dramatic changes: both the exported functionality (semantics of operations) and the exported interface (signatures of operations) may change. Thus, unlike the use of "refinement" in formal approaches to programming, the set of allowed behaviors of our "refined" program might not be a subset of the behaviors of the "unrefined" program.

1997

Algorithms and programming : problems and solutions I Alexander Shen. p. cm. Includes bibliographical references and index.

1993

2007

This book contains information obtained from authentic and highly regarded sources. Reprinted material is quoted with permission, and sources are indicated. A wide variety of references are listed. Reasonable efforts have been made to publish reliable data and information, but the author and the publisher cannot assume responsibility for the validity of all materials or for the consequences of their use. No part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers.

1997

This book is intended for a broad second course in computer science, one emphasizing principles wherever it seems possible at this level. While this course builds and amplifies what the student already knows about programming, it is not limited to programming. Instead, it attempts to use various programming models to explicate principles of computational systems. Before taking this course, the student should have had a solid one-semester course in computer programming and problem-solving, ideally using the Java language, since some of the presentation here uses Java. The philosophy taken in this course is that computer science topics, at an introductory level, are best approached in an integrated fashion (software, theory, and hardware) rather than as a series of individual isolated topics. Thus several threads are intertwined in this text.

Table of Contents 1. Introduction 1.1 General 1.2 Overview of this book 1.3 Exercises 2. Mathematical model of a program and its execution 2.1 Program variables 2.2 Data environments 2.3 Values of variables and expressions in the context of a data environment 2.3.1 The value of an ordinary variable in a data environment 2.3.2 The value of an expression in a data environment 2.3.3 The value of an array variable in a data environment 2.4 Boolean expressions and sets of data environments 2.5 Program statements and constructs as functions on ID to ID 2.5.1 The assignment statement 2.5.1.1 Assignment to an ordinary variable 2.5.1.2 Assignment to an array variable 2.5.1.3 Multiple assignment statement 2.5.1.4 The exchange statement 2.5.2 The declare statement 2.5.3 The release statement 2.5.4 The null (empty) statement 2.5.5 The sequence of statements 2.5.6 The if statement 2.5.7 The while loop 2.5.8 The subprogram call without formal parameters 2.5.9 Basic vs. compound program statements 2.5.10 Other loop structures 2.5.11 The subprogram call with formal parameters 2.5.12 Input/output 3. Preconditions and postconditions 3.1 Ordinary preconditions MRSD eTextbook Robert L. Baber-3-6. Designing correct programs 6.1 General 6.2 The interface specification 6.3 Applying the rules to deduce the program statement types 6.3.1 Assignment and declare statements 6.3.2 Sequence of program segments 6.3.3 If statement 6.3.4 While loop 6.3.4.1 The loop invariant 6.3.4.2 The initialization 6.3.4.3 The while condition 6.3.4.4 The loop body 6.3.5 The subprogram call 6.4 Design example: a program segment to sum the elements of an array 6.4.1 An informal design approach 6.4.2 A more formal design approach 6.5 Design example: partitioning with pointers, deriving a program from its specification 6.5.1 Specification for the subprogram "twopartition" 6.5.2 Overview of the design steps 6.5.3 The loop invariant 6.5.4 The initialization of the loop 6.5.5 The loop condition 6.5.6 The body of the loop 6.5.7 Other required parts of twopartition 6.5.8 The complete subprogram twopartition 6.5.9 Termination 7. Rules for strict preconditions 7.1 Rules for the assignment statement 7.1.1 Rule AS1 7.1.2 Rule AS2 7.2 Rules for the declare statement 7.2.1 Rule DS1 7.2.2 Rule DS2 7.3 Rules for the release statement 7.3.1 Rule RS1 7.3.2 Rule RS2 7.4 Rule NS for the null statement 7.5 Rule SS for the sequence of statements 7.6 Rules for the if statement 7

IEEE Transactions on Software Engineering, 1985

Algorithm design is a challenging intellectual activity that provides a rich source of observation and a test domain for a theory of problem-solving behavior. This paper describes a model of the algorithm design process based on observations of human design. The adaptation of that model to automation in the DESIGNER system helps us understand human design better, and the automation process helps validate the model. Issues discussed include the problem spaces used for design, the loci of knowledge and problem-solving power, and the relationship to other methods of algorithm design and to automatic programming as a whole I. The Algorithm Design Task