DOCSLIB.ORG

CALIFORNIA STATE UNIVERSITY, NORTHRIDGE the EVOLUTION of SOFTWARE DESIGN IDEAS a Thesis Submitted in Partial Satisfaction Of

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
CALIFORNIA STATE UNIVERSITY, NORTHRIDGE the EVOLUTION of SOFTWARE DESIGN IDEAS a Thesis Submitted in Partial Satisfaction Of CALIFORNIA STATE UNIVERSITY, NORTHRIDGE THE EVOLUTION OF SOFTWARE DESIGN IDEAS A thesis submitted in partial satisfaction of the requirements for the degree of Master of Science in Computer Science by David J. Koepke May 1985 The thesis of David J. Koepke is approved: Professor Diane Schwartz Professor Russell '1:1;;'{t;Chair California State University, Northridge 11 ACKNOWLEDGEMENTS I would like to express my sincere gratitude to Professor Russ Abbott for all the enlightening conversations, suggestions, and generous extended use of his software design books and articles. I would also like to thank Pat Morales for her vital assistance in typing and revising this thesis, typing and distributing the inquiry letters, and her moral support throughout this project. A special thanks to Larry Constantine, Edsger Dijkstra, C.A.R. Hoare, James Emery and Donald Knuth for their responses to my questions on the history of software design. iii TABLE OF CONTENTS Page List of Figures ..................................... vii Abstract . Vlll Chapter 1 INTRODUCTION . 1 1.1 Overview of Thesis . 3 1.2 Previous Historical Texts 4 1.3 Historical Errors . 4 1.4 Design Influences of the Past 6 Chapter 2 ABSTRACTION 9 2.1 Early Abstraction 10 2.2 Top-Down Design/Stepwise Refinement 14 2.3 Levels of Abstraction . 20 2.4 Program Families 22 2.5 Abstract Data Types 24 2.6 Summary 32 Chapter 3 MODULARITY 34 3.1 Early Modularity 35 3.2 Information Hiding ..•.....• 42 3.3 Object-Oriented Programming 46 3.4 Summary ................................ 53 iv Chapter 4 STRUCTURED PROGRAMMING 54 4.1 Genesis of Structured Programming . 56 4.2 GOTO Controversy······~················· 58 4.3 Summary ............•...................... 65 Chapter 5 CONCURRENCY ........... ~ .. ~ ............... 66 5.1 Shared Variable Based Concurrency 68 5.1.1 Busy Waiting 70 5.1.2 Semaphores ....... •· ..... 71 5.1.3 Critical Regions . .. 72 5.1.4 Monitors 73 5.2 Message Based Concurrency ••.••• 74 5.2.1 Communicating Sequential Processes . 75 5.2.2 Distributed Processes . 77 5.2.3 Ada 78 5.3 Summary . 80 Chapter 6 DATA FLOW ............................... 81 6.1 Early Data Flow 81 6.2 Data Flow Computers and Languages 87 6.3 Summary 90 Chapter 7 FUTURE PROGRAM DESIGN . 91 7.1 Conventional Languages 91 7.2 Non-Conventional Languages 93 v Chapter 8 CONCLUSIONS AND COMMENTS •••.•••..••.•... 96 8.1 Software Design Trends . • . • • • . • . • • . • 96 8.2 Origin of Design Ideas •..•....•...•..... 107 8.2.1 Refinement of a Vague Idea ...•... 107 8.2.2 Reapplication of a Proven Idea ... 108 8.3 Understanding the Ideas •..••...•....••.. 109 References 112 Appendix - Letters .................................. 122 Vl LIST OF FIGURES AND TABLES Figures Figure 2.1 Abstract Flowchart 13 Figure 2.2 Abstract Data Type - Stack ............. 25 Figure 2.3 Axiomatic Queue Specification .•......... 31 Figure 3.1 Emery's Module Hierarchy Chart . ·-· ...... 40 Figure 5.1 Evolution of Concurrency 69 Figure 5.2 CSP Correspondence···········~·········· 77 Figure 5.3 Ada Rendezvous_ • • • • • • • • • • . • • • • • • • • • • • • . • 7 9 Figure 6.1 Early Data Flow Diagram . • • • . 82 Figure 6.2 Adams' Data Flow Graph 84 Figure 6.3 First Design Data Flow Diagram .......•.. 85 Figure 6.4 Serial Data Flow • . • . • . 86 Figure 6.5 Multiple Data Flow 87 Figure 8.1 Procedural Program Mode 1 ••..•.•.••••..•• 97 Figure 8.2 Object Program Model . • . 97 Figure 8.4 Evolution of High-Level Data Abstraction 99 Figure 8.5 Evolution of Concurrency Constructs ..... 101 Figure 8.6 Evolution of Information Hiding ......•.. 102 Tables Table 8.3 Action vs. Object Model . • . • . 98 vii ABSTRACT THE EVOLUTION OF SOFTWARE DESIGN IDEAS by David J. Koepke Master of Science in Computer Science This th~esis is a study of how software design ideas have evolved from the invention of the flowchart in 1947 to the present. The intent of this study is to accurately record software design history, to discover how new design ideas are conceived, and to recognize historial trends that may suggest future software design ideas. The specific design ideas discussed are abstraction, top-down design, levels of abstraction, program families, abstract data types, modularity, information hiding, object-oriented programming, structured programming, concurrency, and data flow. Each idea is defined and a step-by-step history of how it evolved is given. Also included is a brief discussion of future program design. viii Chapter 1 INTRODUCTION The importance of software design has been recognized since the NATO-Sponsored Conference on Software Engineering in 1968 [Dijk 72b]. Its importance is realized by considering that design significantly affects both the cost of developing and maintaining software. For example, in 1979 the annual cost of software in the u.s. was about 20 billion dollars [Boeh 79]. Approximately one third of this amount was used to develop software, of which design is an important step. The remaining two thirds of this 20 billion was spent on software maintenance: correcting errors, enhancing functionality, and improving performance [Wulf 79]. All of these activities are directly affected by a program's design. This thesis is a study of the evolution of software design ideas. Design ideas or design principles are general guidelines that program designers use in transforming the specification of a problem into a well-structured program. The design ideas discussed 1n this text are abstraction, levels of abstraction, program families, abstract data types, modularity, top-down design, information hiding, object-oriented programming, structured programming, concurrency and data flow. 1 2 The purpose of this thesis is to see what can be learned from studying the evolution of software des ig.n ideas. In particular, to observe past and present software design trends and to extrapolate from these trends to perhaps discover where software design is headed. Also, by observing how present design ideas have originatedi insight may be gained and used to develop future software design ideas. In other words, this thesis is a study of the human learning process applied specifically to design and the programming community of the past thirty five years. A second goal is to accurately record software design history: who first stated an idea, when they said it, in what book or article it first appeared, and how the idea has developed. A list of common historical misconceptions is given in Section 1.3. Portions of software design history have been reintroduced in some of the chapters to present each idea's history separately, so that maximum continuity of idea development would be obtained. The dates of origin given to the ideas discussed are based on the date of publication of an article or technical report or when it was first presented at a conference. The actual date of origin of an idea preceeds the published date. 3 1.1 Overview of Thesis This thesis is presented in four conceptual sections: the process of abstraction (Chapter 2), object or module abstraction (Chapter 3), control abstraction (Chapters 4, 5, 6), and future abstraction (Chapter 7). The chapters are organized as follows: Chapter 2 discusses abstraction, the major design technique of programming. Subtopics include the techniques for applying abstraction: top-down design/stepwise refinement, levels of abstraction, program families, and abstract data types. Chapter 3 discusses modularity. Modules are program sub-units that contain desired abstractions. The subtopics of this chapter are information hiding, the idea which has greatly influenced the module concept, and object-oriented programming, the latest form of modularity Chapter 4 covers structured programming. This idea has been presented in a separate chapter because it is a design philosophy that contains some of the other ideas within it. The main thrust of this chapter is the use of GOTOs. Chapter 5 discusses concurrency and is presented 1n two major sections, shared variable concurrency and message based concurrency. Shared variable concurrency discusses the ideas of busy waiting, semaphores, critical regions, and monitors. Message based concurrency discusses 4 communicating sequential processes, distributed processes, and ADA tasks. Chapter 6 explains data flow, the idea that program control should be based on the availability of data. Subsections of this chapter discuss early data flow concepts and recent uses of data -flow to facilitate concurrency. Chapter 7 presents a brief look at software design in the future. Chapter 8, the conclusion, discusses the benefits gained from studying the evolution of software design ideas. 1.2 Previous Historical Texts The research of current literature on software design did not reveal any general papers or books on the history of software design ideas (i.e., none covering a broad range of design ideas). However, papers by Shaw on abstraction [Shaw 84], by Yourdon on structured pro·gramming [Your 79], and by Gehani [Geha 84] and Andrews [Andr 83] on concurrency each covered the history of a single idea. 1.3 Historical Errors The few historical inaccuracies that were found during research were very slight in that credit was usually given to the second person in a sequence of developers of an 5 idea. For example, structured programming is often claimed, [McCr 73], [Shaw 84] to have begun with Dijkstra's 1968 letter to the ACM, "GOTO Statement Considered Harmful" [Dijk 68a], because it triggered a GOTO controversy. Perhaps a more accurate genesis of structured programming is Dijkstra's 1965 article, "Programming Considered as a Human Activity" [Dijk 65a]. This article not only contains arguments against the use of GOTOs but also presents the concepts of modularity and stepwise refinement within the general goal of program correctness (see Section 4.1 for more detail). Larry Constantine is often credited [Cons 84] with the invention of the data flow diagram because of the 1974 paper "Structured Design" [Stev 74]. In fact, he was the first to apply this type of diagram (which had been used as a model for the analysis of parallel computations in 1963), to software design (see Section 6.1 for more detail).
Load more

Recommended publications
  • PMR 5020 Modelagem Do Projeto De Sistemas Aula 2: Sistemas E Seu Processo De Projeto Prof
    PMR 5020 Modelagem do Projeto de Sistemas Aula 2: Sistemas e seu processo de projeto Prof. José Reinaldo Silva [email protected] PMR5020 Escola Politécnica da USP 1 O Design Mecatrônico (Mechatronic Design) Sistema de informação Sistema Mecânico Artefato Mecatrônico Sistema de controle Sistema Eletrônico Prof. José Reinaldo Silva PMR5020 Escola Politécnica da USP 2 O noso artefato alvo… Sistemas Não tem fronteiras óbvias Não tem um “corpo” material Geralmente acoplado Prof. José Reinaldo Silva PMR5020 Escola Politécnica da USP 3 Um sistema é um conjunto de objetos distinguíveis – não necessariamente homogêneo – que trabalham em conjunto para atingir um objetivo coletivo. Eventualmente cada um dos elementos constituintes pode ser também um sistema menor do que o sistema que o contém. Assim a definição é recursiva e convergente. Existem uma (ou mais) categorias de elemento constituinte tal que não vale a pena imergir nos detalhes internos deste, isto é, a precisão dos detalhes não contribui em nada seja para o funcionamento do sistema, seja para entender a sua funcionalidade. Prof. José Reinaldo Silva PMR5020 Escola Politécnica da USP 4 Teoria de sistemas Proposta em 1940 por Ludwig von Bartalanffy Em busca da unificação da ciência X reducionismo Prof. José Reinaldo Silva PMR5020 Escola Politécnica da USP 5 Sistema: uma definição holônica Um sistema é definido pelo par ordenado S=(A, R) onde A é um conjunto de elementos constituintes (objetos) relevantes A e R o conjunto R de relações definidas entre estes objetos. Eventual- mente um elemento de A tem as mesmas características do sistema e é chamado de sub-sistema de S.
    [Show full text]
  • Chapter 1: Introduction
    Just Enough Structured Analysis Chapter 1: Introduction “The beginnings and endings of all human undertakings are untidy, the building of a house, the writing of a novel, the demolition of a bridge, and, eminently, the finish of a voyage.” — John Galsworthy Over the River, 1933 www.yourdon.com ©2006 Ed Yourdon - rev. 051406 In this chapter, you will learn: 1. Why systems analysis is interesting; 2. Why systems analysis is more difficult than programming; and 3. Why it is important to be familiar with systems analysis. Chances are that you groaned when you first picked up this book, seeing how heavy and thick it was. The prospect of reading such a long, technical book is enough to make anyone gloomy; fortunately, just as long journeys take place one day at a time, and ultimately one step at a time, so long books get read one chapter at a time, and ultimately one sentence at a time. 1.1 Why is systems analysis interesting? Long books are often dull; fortunately, the subject matter of this book — systems analysis — is interesting. In fact, systems analysis is more interesting than anything I know, with the possible exception of sex and some rare vintages of Australian wine. Without a doubt, it is more interesting than computer programming (not that programming is dull) because it involves studying the interactions of people, and disparate groups of people, and computers and organizations. As Tom DeMarco said in his delightful book, Structured Analysis and Systems Specification (DeMarco, 1978), [systems] analysis is frustrating, full of complex interpersonal relationships, indefinite, and difficult.
    [Show full text]
  • Users, Roles, and Personas (PDF)
    Constantine & Lockwood, Ltd. PREPRINT Users, Roles, and Personas Larry Constantine, IDSA Chief Scientist, Constantine & Lockwood, Ltd. You cannot think outside the box when you are trying to represent a box. Brian Hayes To do effective design you need to understand your users and their needs. While no credible school of thought in design would take serious exception, opinions vary considerably on how best to gain that understanding and how to record and communicate it once you do. Models of one form or another are the medium for the message in most design methods. Models function as intermediaries between the often ambiguous, overwhelmingly complex reality of actual users and the more narrowly focused and specific needs of designers. In usage-centered design (see sidebar, “Users or Usage”), user roles capture and carry the essential understanding about users. User roles, one of the three core models of usage-centered design, are close cousins of personas but differ in a number of ways of potential significance to designers. In an attempt to sound a counterpoint to complement the main themes of the book, this chapter introduces user roles in the context of usage-centered design and explores the relationships between user roles and personas. Compared to typical personas as presented in this book and elsewhere, user roles are a more compact and concise representation that is more finely focused on issues with direct relevance for visual and interaction design. For these reasons, user role models can also be simpler and faster to develop. Although roles and personas can complement each other, user role models may also, under some circumstances and for some purposes, offer distinct advantages for designers.
    [Show full text]
  • Contents U U U
    Contents u u u ACM Awards Reception and Banquet, June 2018 .................................................. 2 Introduction ......................................................................................................................... 3 A.M. Turing Award .............................................................................................................. 4 ACM Prize in Computing ................................................................................................. 5 ACM Charles P. “Chuck” Thacker Breakthrough in Computing Award ............. 6 ACM – AAAI Allen Newell Award .................................................................................. 7 Software System Award ................................................................................................... 8 Grace Murray Hopper Award ......................................................................................... 9 Paris Kanellakis Theory and Practice Award ...........................................................10 Karl V. Karlstrom Outstanding Educator Award .....................................................11 Eugene L. Lawler Award for Humanitarian Contributions within Computer Science and Informatics ..........................................................12 Distinguished Service Award .......................................................................................13 ACM Athena Lecturer Award ........................................................................................14 Outstanding Contribution
    [Show full text]
  • Survey of Pen-And-Paper Computing
    Human-Computer Interaction Series Editors-in-chief John Karat Jean Vanderdonckt, Université Catholique de Louvain, Belgium Editorial Board Gaëlle Calvary, LIG-University of Grenoble 1, France John Carroll, Penn State University, USA. Gilbert Cockton, Northumbria University, Newcastle, UK Larry Constantine, University of Madeira, Portugal Steven Feiner, Columbia University, USA Peter Forbrig, Universität Rostock, Germany Elizabeth Furtado, University of Fortaleza, Brazil Hans Gellersen, Lancaster University, UK Robert Jacob, Tufts University, USA Hilary Johnson, University of Bath, UK Dianne Murray, Putting People Before Computers, UK Kumiyo Nakakoji, University of Tokyo, Japan Philippe Palanque, Université Paul Sabatier, France Oscar Pastor, University of Valencia, Spain Fabio Pianesi, Istituto Trentino di Cultura, Italy Costin Pribeanu, National Institute for Research & Development in Informatics, Romania Gerd Szwillus, Universität Paderborn, Germany Manfred Tscheligi, Center for Usability Research and Engineering, Austria Gerrit van der Veer, Vrije Universiteit Amsterdam, The Netherlands Shumin Zhai, IBM Almaden Research Center, USA Thomas Ziegert, SAP Research CEC Darmstadt,Germany Human-computer interaction is a multidisciplinary field focused on human aspects of the de- velopment of computer technology. As computer-based technology becomes increasingly per- vasive – not just in developed countries, but worldwide – the need to take a human-centered approach in the design and development of this technology becomes ever more important. For roughly 30 years now, researchers and practitioners in computational and behavioral sciences have worked to identify theory and practice that influences the direction of these technologies, and this diverse work makes up the field of human-computer interaction. Broadly speaking it includes the study of what technology might be able to do for people and how people might interact with the technology.
    [Show full text]
  • Algorithms (One of the Following) L Buy the Book -  Introduction to Algorithms, Thomas H
    Level 9 Reading List [ladder home page] [ladder overview] [reading list] [pyramid] Required reading Recommended Reading Appropriate Optional Reading The top list is a recommendation by category. Detailed book descriptions follow the summary table. R Algorithms (one of the following) L Buy the book - Introduction to Algorithms, Thomas H. Cormen, et al Buy the book - Data Structures and Algorithms, Aho, Hopcraft, and Ullman Buy the book - Algorithms in C++, Robert Sedgewick Buy vol.1 Buy vol.2 - The Art of Computer Programming (vols. 1-3), Donald Knuth Buy vol.3 Construction Practices Buy the book A Code Complete, Steve McConnell Buy the book A Programming Pearls, Jon Bentley Buy the book - Practice of Programming, Brian Kernighan and Rob Pike Buy the book - Writing Solid Code, Steve Maguire Buy the Book - Programming on Purpose: Essays on Software Design, P. J. Plauger Buy the book - Programmers at Work, Susan Lammers Software Development Overview Buy the book. A 201 Principles of Software Development, Alan M. Davis Get the article A "The Humble Programmer," Edsger Dijkstra "Software Engineering Programmes are not Computer Science Programmes," David Get the article A Parnas Get the article A "They Write the Right Stuff ," Charles Fishman Buy the book - Software Engineering, Ian Sommerville Buy the book - Software Engineering: A Practitioner's Approach, Roger Pressman Professional Ethics Get the code A Software Engineering Code of Ethics and Professional Practice, ACM/IEEE-CS Periodicals Subscribe - Software Development Subscribe - IEEE Software Algorithms Introduction to Algorithms, Thomas H. Cormen, et al. This comprehensive book contains an exhaustive discussion of specific algorithms, algorithm analysis, and algorithm design (though not as exhaustive as Knuth's seven volume series).
    [Show full text]
  • From Customer Value Constellation to Service Experience Blueprinting
    Journal of Service Research 000(00) 1-21 ª The Author(s) 2011 Multilevel Service Design: Reprints and permission: sagepub.com/journalsPermissions.nav From Customer Value Constellation DOI: 10.1177/1094670511401901 to Service Experience Blueprinting http://jsr.sagepub.com Lia Patrı´cio1, Raymond P. Fisk2, Joa˜o Falca˜o e Cunha1, and Larry Constantine3 Abstract The proliferation of complex service systems raises new challenges for service design and requires new methods. Multilevel Service Design (MSD) is presented as a new interdisciplinary method for designing complex service systems. MSD synthesizes contributions from new service development, interaction design, and the emerging field of service design. MSD enables integrated development of service offerings at three hierarchical levels: (a) Designing the firm’s service concept with the customer value constellation of service offerings for the value constellation experience; (b) Designing the firm’s service system, comprising its architecture and navigation, for the service experience; and (c) Designing each service encounter with the Service Experience Blueprint for the service encounter experience. Applications of the MSD method are described for designing a new retail grocery service and for redesigning a bank service. MSD contributes an interdisciplinary service design method that accommodates the cocreative nature of customer experiences and enables experience integration from the design of the service concept through the design of the service system and service encounter. Keywords service system design, customer experience, value constellation, blueprint, technology-enabled multi-interface services Introduction cocreate value (Maglio et al. 2009). For example, customers can cocreate value by combining service offerings from multi- The rapid evolution of service systems raises new challenges ple firms, such as credit and insurance in the case of a home for service design.
    [Show full text]