Computer Software Cannot Be Engineered
Norman Young
Computer software cannot be engineered because there is no science of computer programs. Science is essential to engineering. The application of scientific models through engineering judgment defines the essence of engineering. Computer programs, as mathematical objects, are not subject to scientific laws. Consequently, by definition, computer software cannot be engineered.
The application of scientific models through engineering judgement,defines the essence of engineering. Engineering itself involves the creation of useful artifacts. What distinguishes engineering from other creative professions is the use of scientific models in creating those artifacts. Engineering judgement chooses among a number of available models to use in solving a problem, balancing risk of failure with the effort of analysis. What characterizes engineering is the scientific underpinnings of at least some of the available models.
Computer programs are mathematical objects. In particular, individual computer programs are specific values in a discretely parameterized model of the computer that executes them. ill The physical computers which execute computer programs have scientific meaning, but the programs themselves have no physical meaning apart from the meaning attributed to them by the computer. Consequently, computer programs are not subject to scientific laws.
As purely mathematical objects, with no underlying science, computer programs and computer software cannot be engineered.
Mathematics is important but in itself not sufficient to characterize engineering
Mathematics is important to engineering but in itself not sufficient to distinguish engineering from other vocations [Davis. M.]. Engineering uses mathematics to express engineering problems, and to reason about the scientific models used in solving engineering problems. Specifically, all mathematical statements used in engineering have some physical interpretation, relating various quantitative aspects of a problem or its candidate solutions. The scientific basis of all mathematical statements found in engineering is part of what distinguishes engineering from other activities, not merely the use of mathematics itself.
In contrast, other fields use mathematics, but not necessarily in stating scientific properties about the physical world. For example, the commercial activities of accounting and finance use mathematics, but the mathematical statements used in these fields are based on conventions about the value of goods and services. Accountants and economists derive models based on these conventions and use mathematics to express ideas and reason about problems represented in these models, but the models themselves have no physical scientific meaning. The models and related mathematical statements only have meaning within the commercial conventions on which they are based.
Consequently, the use of mathematics is in itself not sufficient to characterize an activity as engineering. Permitting the use of mathematics as a sufficient basis to qualify an activity as engineering is the same as saying that whenever anyone is using mathematics then they are applying engineering. The statement must be further qualified. Whenever someone is using mathematics to reason about a scientific model in building a useful artifact, then they are applying engineering.
Engineering without science is craftsmanship
Like engineering, other professions use models and apply judgment to create useful artifacts. For example, many creative trades, from industrial design to pipe-fitting, use physical prototypes to analyse problems and evaluate alternative candidate solutions to those problems. These trades apply judgement in balancing the value and insight that the models provide with the effort of developing and analyzing them. Many professions also apply predefined models and conventional solutions manifest through the historical traditions of their respective trades. The practitioners use judgement similar to engineering judgement to choose among the many known and newly-developed models available for use in solving the design problem at hand.
What distinguishes engineering from other creative professions is the use of models based on scientific laws [~]. Models based on scientific laws often provide more accurate predictions than other available models, thereby allowing engineering to develop solutions to unprecedented problems. The universality of scientific laws allows engineers to predict how candidate solutions will perform under scientifically-modeled conditions, before building physical prototypes or the solution itself. This often saves construction costs, and sometimes allows engineers to address new problems which have not been solved before. Most importantly, it reduces risk to life and property by allowing for evaluation of alternative solutions before putting any candidate solution into direct use.
Disciplines of engineering are characterized by their underlying branch of science
Each discipline of engineering is characterized by its underlying branch of science. Civil engineering is based on the laws of statics and strength of materials. Mechanical engineering is based on kinetics and mechanical properties of materials. Chemical engineering is based on the laws of mass and energy transfer. Electrical engineering is based on the laws of electricity and magnetism. In general, the science underlying each discipline of engineering is the science of the materials or objects used in constructing the respective discipline's artifacts.
Consequently, engineers specialize in their work through a corresponding specialization in some branch of natural science. The choice of scientific specialization characterizes the engineer's work because it defines the limits of their competence and practice. For example, the laws of electricity and magnetism generally apply to a radio circuit design, but do not apply in the design of interstate highways. Likewise, statics and strengths of materials apply directly to bridge design, but do not necessarily help in the design of a digital calculator. As these examples illustrate, these two branches of science characterize their corresponding disciplines of engineering.
The importance of science in engineering cannot be overstated. The thorough and accurate understanding of natural phenomena offered by scientific models underpins all advanced and many routine results of engineering. Advances in science directly contribute to new engineering methods, just as many engineering problems motivate new areas of scientific research. Furthermore, the measure of competence in engineering often rests on some definition of the practitioner's understanding of scientific principles. Science is central to both the practice and professional institution of engineering.
Computer science is not science, but mathematics
Computer programs are mathematical objects. In particular, individual computer programs are instances of sets of values in discretely parameterized mathematical models of the physical computers that execute them. A computer program has no physical meaning apart from the interpretation given to it by the computing machine during execution. Computer programs, in themselves, are mathematical objects.
Computer science concerns the study of computer programs and the activity of computer programming. As such, many cite computer science as an appropriate basis for an engineering discipline of computer software. However, computer science necessarily cannot provide such a basis.
All work undertaken in the field of computer science falls into one of three categories. The first category specifically recognizes that computer programs are mathematical objects and does not claim authority as a form of science. The second category applies the scientific method to the study of computer programs, but without sufficient control to provide a sound basis for scientific research. The third category produces results which may be scientifically sound (to the extent that it recognizes the limitations of the first two categories), but which are statements about the psychology of computer programmers, not about the properties of computer programs.
The first cat~gory is generally known as theoretical computer science. Theoretical computer science studies computer programs as objects in themselves. The concepts of algorithms, universal Turing machines, and finite automata are examples of important ideas at the foundation of theoretical computer science. These ideas aim to separate the study of computer programs from consideration of the machines that execute the programs. That is, these ideas aim to separate the theory of computer programs, as objects of study in themselves, from the practice, represented by the execution of these programs by physical computers. Most computer science researchers recognize that these fundamental concepts define theoretical computer science as a branch of mathematics.
The vast majority of work in computer science falls in the second category [McKee]. The second category applies the scientific method, but without sufficient experimental control to yield sound scientific results. In particular, research in the second category involves formulating hypotheses and conducting experiments to refute or corroborate hypotheses. However, the experiments lack control over the objects of study, that is, over the computer programs themselves. The consequent variability disqualifies the second category's results as the basis for sound scientific models.
The problem of variability arises because there does not currently exist a practical means of completely and unambiguously specifying computer programs to the degree required for experimental control. Existing specification techniques are either impractical or imprecise (see Mathematics will reclaim the foundation for a notable exception). The techniques that are sufficiently precise for sound scientific research are not practical for large programs, and the techniques that researchers use with more complex computer programs do not specify all relevant properties of the programs under study.
Furthermore, the practical difficulties of applying the scientific method to the study of computer programs distracts many researchers in this second category from the fact that the objects of study are not amenable to scientific research. Computer programs are mathematical objects. The meaning of computer programs are necessarily defined in terms of the physical computers that execute the programs. Any variation in experimental results can only be attributed to variations in the executing machines.
These inherent difficulties in applying the scientific method to the study of computer programs gives rise to the third category of work in the field of computer science. Research undertaken in this third category responds to the problem of specifying computer programs by avoiding it, and attempts to control the process of writing computer programs instead of the programs themselves. Researchers in this category argue that control over the behaviour of the individuals who write computer programs should provide sufficient control over the programs that they produce. (This line of reasoning -controlling outcome by controlling behaviour -also provides the rationale for most of the work in the field of software engineering, discussed below in Software engineering is largely technical management and Software engineering research is,applied psychology.)
The reasoning applied in this third category of computer science disqualifies it as the basis for a discipline of engineering, regardless of the soundness of its scientific results. AS discussed above in the section Disciplines of engineering are characterized by their underlying branch of science. the science underlying engineering is necessarily about the materials and objects used in constructing the discipline's artifacts. For the work of computer science to provide the basis of a discipline of software engineering its results must describe the properties of computer programs, not the behaviour of the individuals writing the programs. Consequently, the results of this third category of computer science disqualify it as the basis for an engineering discipline of software.
Furthermore, the rationale underlying this third category of computer science leads to circular reasoning. In particular, the work in the third category aims to control the properties of computer programs by controlling the behaviour of the computer programmers who write the programs. However, the only relevant measure of the programmer's behaviour are the properties of the programs that they create. Attempting to compare the programs leads to the inherent difficulties described above under the second category. Therefore, controlling the process of computer programming offers no substantial improvement in control over research about computer programs themselves.
Computer engineering is currently a specialization of electrical engineering
Just as computer ~science does not provide the basis as for a discipline of software engineering, it also does not provide the basis for a discipline of computer engineering. However, unlike software engineering, the term computer engineering denotes a sound concept, but only to the extent that the term computer refers to the engineering of a physical device.
Where computer refers to the physical device, computer engineering is well founded, but is necessarily a specialization of some other discipline of engineering, such as electrical engineering. Where computer refers to the mathematical idea of a computer, the concept of computer engineering is unfounded, because there can be no science of computers as mathematical objects.
The scientific basis for a discipline of computer engineering lies in the science of the materials and objects used in building computing machines. Currently, this branch of science is largely synonymous with the same branch as underlies electrical engineering, since the vast majority of physical computers designed today are electronic devices. However, this contemporary characterization of computer engineering is purely historical, arising from the prevalence of electronics in contemporary computer designs. It was not always this way, as evident in the mechanical design of early computing devices, and it may change again in the future, as optics or some other alternative technology supersedes electronics. This makes the engineering significance of the term computer engineering dependent on historical context.
However, just as there is no science of computer programs, there is no scientific basis of computers as mathematical objects. The complementary ideas of a computer program and a computer that executes the program are mathematical conventions, useful in modeling the behaviour of complex devices. The ideas of computers and computer programs have no scientific meaning in themselves. Consequently, the idea of computer engineering is only as sound as the corresponding conventional discipline 9f engineering applied in designing the physical computing machine. Computer engineering, as a discipline of engineering, is necessarily confined to the bounds of some other scientifically-based discipline of engineering.
Software engineering is a statement of ambition, not of accomplishment
The term software engineering was coined at a NATO science committee conference in the 1960's [NAIO]. It has since been used as a rallying cry to encourage computer programmers to use more engineering-like discipline in their work. Advocates claim that by adopting practices similar to civil, mechanical, chemical, and electrical engineering, computer programmers will realize a substantial improvement in their work, both in their own efficiency, and in the quality of the computer-based systems that they help produce.
The precept has met with broad appeal. Engineering-like discipline is widely heralded as a means of lifting computer programming practice out of what has come to be known as the software crisis. However, many programmers, researchers, and educators have adopted the term software engineering to describe their work without scrutinizing whether it qualifies as engineering. The result is a large body of knowledge that bears a superficial resemblance with scientifically-based engineering, and which is regarded by many as the basis for an emerging discipline of software engineering. However, like the work of computer science, the software engineering body of knowledge does not qualify as the basis for an engineering discipline of computer programming because it does not describe a science of computer programs.
Software engineering is largely technical management
The body of knowledge cited by many as the basis for a discipline of software engineering largely concerns technical management. The field's emphasis on management arises from its historical origins, and is reinforced by the difficulties of achieving experimental control. In this respect, software engineering research shares the same inherent limitations as computer science. However, in contrast with the mathematical origins of computer science, which emphasize computer programs as objects of study in themselves, software engineering research arises from an institutional and commercial tradition, which emphasizes controlling management-related aspects of computer programming activities.
At the core of the software engineering literature are a number of software development life-cycle models [Sommerville, Boehm88]. Most work in software engineering is organized around these models, according to how the work's results contribute to one or more of the models' phases. For example, the waterfall model describes the phases of analysis, design, implementation, and verification. Most work in software engineering can be classified according to how it contributes to one or more of these phases. The contributions are often stated in management-related terms, such as reduced development costs, improved product quality, or better project control. The method of improvement is often described by how it affects the practitioners' activities of analysis, design, implementation, and verification.
Software engineering's emphasis on development life-cycle models heavily influences its historical development. Most software engineering work is based on the premise that computer programming can be controlled by controlling the behaviour of individuals or groups who write computer programs. This is the same premise of control as described above in characterizing the third category of computer science. However, software engineering research generally takes this premise a step further, by combining it with some form of a software development life-cycle model. The result is typically a set of management guidelines or tools, supported by arguments about how the guidelines or tools improve results in one or more phases of the corresponding life-cycle model. However, like computer science research, these software engineering research results do not qualify as the basis for an engineering discipline in computer programming because they do not describe a science of computer programs.
For example, an often-cited claim in the software engineering literature is that a mistake made anywhere in a computer program's development life-cycle leads to exponentially increasing costs the later that it is found and corrected [Boehm76]. The literature characterizes this claim with the following (simplified) explanation: if a mistake costs $1 to find and correct during analysis, then the consequences of the same mistake will cost about $10 to correct during design, about $100 to correct during implementation, about $1,000 during verification, and so on. Like most statements in software engineering, this software engineering principle is expressed in terms of management concepts, such as programmer effort and development schedules [:Qavis. A.].
This well-known claim also forms the basis for a large sub-field of software engineering research called requirements engineering. Requirements engineering researchers argue that programming resources are most productively focused on the early life-cycle phases, where they should yield several orders of magnitude better results than when applied in later phases. These same researchers describe tools for computer programmers to use in specifying and analyzing computer program requirements. They also describe management guidelines for organizing a programming team's analysis activities.
This example from requirements engineering is typical of the software engineering body of knowledge. Practically all of the software engineering literature deals with similar management-related issues [Brooks74, HumQhrex]. For example, many researchers aim to determine the optimum development team size and communication structures meMarco&Lister]. Others have attempted to quantify and analyze project cost and risk factors, with the intention of identifying patterns and developing general predictive models [Boehm81 ]. Many refer to development life-cycle models in motivating their work. Comparatively few treat computer programs as mathematical objects [Mills et al.]. Even fewer treat computer programming as a branch of mathematics [Woodcock&Loomes].
Software engineering research is applied psychology
As mentioned above, software engineering suffers from the same inherent limitations as computer science research with respect to experimental control. No practical specification techniques used in software engineering provide a sufficiently precise description of the computer programs under study. Without a practical and precise means of specifying computer programs, there can be no objective experimental control. Without experimental control, it is impossible to reliably determine which management guidelines and tools actually produce better computer programs.
Most software engineering researchers respond to the lack of experimental control by ignoring it. Many cite anecdotal evidence as an alternative basis in comparing their experimental results [fuk-Y]. Some recognize the need for experimental control and attempt to quantify their experimental results in mathematical and statistical terms [~].
However, regardless of the degree of control accomplished, no software engineering research results can form the basis for a discipline of engineering because computer programming is necessarily an intellectual activity involving only the manipulation of mathematical objects. Any experimental results about the activities associated with computer programming necessarily depend only on the psychology of the computer programmers involved [Weinberg].
Software engineering's emphasis on management techniques and lack of scientific basis puts it in stark contrast with the established disciplines of engineering. As a point of comparison, offering the P1ost scientifically-oriented results from software engineering as the basis for a discipline of engineering is akin to predicting whether a new rocket engine will deliver sufficient thrust to launch a satellite by analysing its design team's average IQ and project management style.
Software engineering and computer science are tenuous institutions
Despite the lack of a sound scientific basis, software engineering and computer science are growing institutions. Their growth is primarily fueled by the widespread and increasing reliance on computer-based systems in almost all aspects of human life. Increased reliance on computer-based systems is generating increased demand for more computer programmers, and higher demands on the programmers already working. Researchers have responded with attempts to improve programmer productivity. Educators have responded by increasing enrollment in computer science and software engineering programs.
Demand for accountability will reinforce institutional growth
The increased reliance on computer-based systems also brings increased demands for accountability in the systems' correct and safe operation. This will further reinforce the growth of computer science and software engineering as institutions. The public perceive these institutions as offering technical authority in assessing computer programs, and in assessing the competence of the computer programmers who write the programs. Computer science has responded by establishing specializations such as computer security and formal methods. Software engineering has responded by establishing specializations such as software reliability and software quality assurance. Both computer science and software engineering produce graduate and undergraduate degrees claiming technical authority in these areas.
Additionally, some traditional professional engineering bodies are seeking jurisdiction over computer programmers who program computer-based systems that affect public safety, and also over those who use titles such as software engineer in their work [lliki!!]. These professional bodies are aiming to preserve their authority in regulating technical competence on issues affecting public safety, while expanding their scope to include new disciplines that might be perceived by the public as a form of engineering [Bilanski]. Both goals reinforce the general perception of computer science and software engineering as technically authorized institutions.
These institutional responses are being pursued based on the misguided assumption that the decisions involved have some grounding in a scientific body of knowledge. However, because there is no science of computer programs, there is no such scientific basis for most of this institutional work.
Failure will undermine the trend
Without a sound scientific basis, these attempts to advance, teach, and regulate computer programming will achieve only very limited success. For example, many authors cite the common failings of commercial computer programming projects as evidence of the institutional methods' inherent limitations. Numerous projects have failed to deliver adequate results, while consistently exceeding cost and schedule estimates [~].
The cyclical nature of some computer science and software engineering research topics can also be attributed to the lack of an appropriate set of fundamental principles. These research topics are characterized by initial claims for dramatic improvements in programmer productivity; but are eventually demonstrated to provide only incremental advances, at best. The claims arise and survive because there is no objective frame of reference in which to evaluate their truthfulness. Only repeated failure to deliver on their claims in practice can be used to refute their accuracy. Automatic programming, object-oriented programming, and component-based reuse are examples [Brooks].
The lack of an objective frame of reference also limits the effectiveness of education and training. Computer science and software engineering educators deliberate at length about what material should be taught because there is no consistent set of underlying principles with which to evaluate the importance of any given topic. Some educators emphasize formal methods whereas others emphasize management practices. Some focus on testing methods whereas others favour requirements analysis [Education].
In contrast, although educators in the traditional disciplines of engineering often disagree about the importance of teaching student about any particular application area, few differ with the need for a solid foundation in science and mathematics. Consequently, engineering educators design their courses around the scientific body of knowledge on which their discipline is based. Computer science and software engineering educators have no corresponding frame of reference on which to base their work. The result represents a wide divergence in curricula content, and produces significant disparity in the level of understanding achieved by the graduating students.
Consequently, regulators will experience serious difficulties in trying to organize their work in this context. Professional engineering bodies will discover that computer science and software engineering courses generally do not contain sufficient scientific content to compare with courses from traditional engineering programs. The divergence in educational content will frustrate attempts to qualify practitioners based on training. Furthermore, regulators will find no consistent scientific body of knowledge with which to assess practitioner competence, or to use in judging alleged cases of malpractice. The lack of an objective scientific frame of reference will seriously undermine any institutional attempts to hold computer programmers accountable for their work.
The lack of a sound scientific basis for computer science and software engineering will ultimately limit these institutions' growth. In the meantime, however, until the appropriate alternative framework is discovered and established, computer science and software engineering will continue to grow, because they are the only resources available for technical knowledge and training.
Traditional specializations will reabsorb the practice through mathematics
Mathematics will ultimately prove to be the only appropriate basis for work that involves computer programming. A more appropriate form of mathematics will develop as more researchers reveal and address the perceived difficulties of using mathematics in computer programming. The resulting branch of mathematics will provide the objective foundation that is currently lacking, and will eventually all but eliminate the issues outlined in this essay.
The effects of an appropriate mathematical basis for computer programming will indeed be far-reaching. Most importantly, it will equip computer system designers with a reliable means of demonstrating program correctness. This advance alone will dramatically change how individuals and organizations approach the problem of computer programming, as well as improve the efficiency and cost effectiveness of the computer-based systems they produce. Programming projects that apply mathematical approaches will require fewer programmers and produce predictably better results than today's methods.
Furthermore, as a mathematical approach to computer programming fully develops, computer programming itself will become routine. Emphasis will shift away from the problems of programming and towards the application areas. Mathematics will make reliable programming methods accessible to non-specialists. Consequently, many fewer practitioners will regard themselves as programming specialists working in particular application areas. Rather, application specialists will acquire the mathematical knowledge required to apply computers in their work.
In this way, computer programming, as a form of applied mathematics, should follow a similar evolution as other branches of applied mathematics, and eventually be taught as a specific tool available from a selection of generally useful mathematical techniques. For example, mathematics for computer programming could become as pervasive and as widely understood as plane geometry and differential calculus.
Mathematics will reclaim the foundation
Current mathematical approaches to computer programming have failed to achieve widespread use because the available approaches do not properly address three important aspects of the problem. First, they do not necessarily include mathematically complete descriptions of the computer executing the program [2.]. Second, they do not appeal to the intuition of the computer programmers using the descriptions [l]. Third, they do not scale up to the size of computer programming problems found in common practice [.4].
One potential exception to this general failing of mathematics to achieve widespread acceptance may be found in the work of Dr. David raffias and his colleagues ~amas86]. Dr. raffias characterizes the problem of computer system design as equivalent to the derivation of a well-defined set of documents. Each document specifically describes some aspect of the design problem within a general mathematical framework [Pamas91 , Pamas92b ]. The computer-based systems and programs developed following this approach can be objectively demonstrated as correct by the original programmer or an independent second party, by verifying the consistency of the mathematical relationships expressed in the documents [~].
Unlike other mathematical approaches, Dr. raffias' work specifically addresses the three limitations outlined above. First, it includes mathematically complete descriptions of both the computer program and the computer executing the program. Second, it uses a form of mathematical expression which is accessible to anyone familiar with common first-order logic ~arnas92a]. Third, the structure of the documents and the forms of mathematical notation used are specifically designed to scale up to design problems of arbitrary size [Janicki].
Dr. Parnas' work and related results have the potential to establish the mathematical foundation currently missing from common computer programming practice.
Practitioners will specialize by application area
The establishment of a general practical mathematical approach to computer programming will eventually eliminate the role of software engineering as an institution, and refocus computer science on its mathematical roots. These institutions will no longer be needed for training large numbers of computer programmers because the mathematical principles underlying computer programming will be accessible to non-specialists. Specialization by application area will become the dominant factor in organizing the work. Practitioners will train in whatever application area is their first interest, and will generally only acquire the mathematical knowledge and programming skills necessary to apply computers in their chosen area of specialty.
These predictions for the institutions of computer programming are based on the observation of a similar pattern in the historical development of other branches of applied mathematics. For example, Fourier's transform for spectral estimation was originally discovered and applied in solving engineering-related heat transfer problems. As real-world practice repeatedly demonstrated its value, mathematicians took an increasing interest in its mathematical basis and eventually proved Fourier's transform as mathematically sound [Robinson]. Today, Fourier's transform is taught to all undergraduate engineering students, and is routinely applied in almost all areas of engineering and science.
Many other areas of applied mathematics have followed a similar evolution, from plane geometry to differential calculus. Although these branches of mathematics were each originally associated with their particular area of application, their general underlying principles were eventually discovered and articulated as the basis for a new but accessible specialization within mathematics. Computer programming should follow a similar evolution, as more researchers and practitioners recognize the significance of computer programs as mathematical objects.
Endnotes
[1] This essay's comments apply to analogue computers, as well as digital- [Back]
This essay uses the term computer in the current sense of the word, that is, meaning a stored-program digital device in which both space and time are modeled as discrete quantities. However, the essay's discussion and conclusions apply equally well to the less commonly used sense of the word as an analogue computer, in which spatial or temporal quantities are modeled as real-valued functions.
[2] Operational specifications do not describe the executing computer -[Back]
Operational specification users may take issue with this essay's implication that their techniques do not describe the computer executing the program [~]. For example, ROOM and .snL specify programs by way of an abstract machine. Programs are specified by describing their behaviour as it would be represented on the abstract machine. The specification's execution on the abstract machine represents the corresponding program's requirements. The abstract machine necessarily includes idealizations, such as infinite memory capacity and infinite execution speed.
Companies such as Ob~iecTime and Telelogic offer specification interpreters as tools for use in program development. These interpreters allow programmers to execute their specifications, to see if the specifications reflect the program's desired behaviour. ObjecTime also offers a run-time environment which allows a representation of the specification to execute on a target computer. The interpreters a!1d run-time environment define the relationship between the abstract machine's idealizations and the real computer.
However, the operational specification approach, as it is represented in these tools, defers the description of the executing computer to the interpreter or run-time environment. Programmers must still take the limitations of the eventual target computer into account when using these tools. The idealizations used in the operational specification approach merely postpone the description of the executing computer to the definition of the interpreter or run-time environment.
[3] Other mathematical notations are not intuitive -[Back]
Formal methods users may take issue with this essay's implication that other mathematical specification languages, such as the Z notation, are not intuitive to programmers. For example, Woodcock and Davies introduce their book on using Z with a description of how Z was successfully used on a project by programmers with no former training in mathematically-based program specifications.
Measures of intuitiveness are necessarily subjective. The consequent debates about various computer-related languages' appeal to programmers' intuition are largely unproductive, and historically irrelevant. (For example, consider the current popularity of Cobol and Ada, two languages specifically designed to exploit intuition, with the continued and growing demand for C/C++ and Java, two languages designed by programmers.)
However, Dr. Pamas' work offers at least one important distinction in appealing to practicing computer programmers when compared to other mathematically-motivated specification techniques, such as Z. Dr. Pamas' predicate logic does not prescribe a particular notation. Programmers are free to adopt whatever notation is convenient, provided its semantics are well-defined with respect to the underlying predicate logic. For example, expressions in Dr. Pamas' predicate logic can be expressed using the syntax of the C programming language, with an interpretation that is consistent with both the underlying formal logic and C.
This flexibility has at least three major practical advantages. First, it allows the methods to be adopted to the programming languages currently used in any particular application area (not the other way around). Second, it avoids a significant portion of the effort in teaching the methods. Third, it allows for building tools based on existing programming language tools, such as parsers and text-based source code editors.
It also has one major pragmatic advantage, which ultimately will render mute any corresponding debate. The methods will very likely be perceived as more intuitive, because the methods can exploit notations which existing programmers already understand. This final advantage underlies this essay's implication about comparative intuitiveness.
[4] Other mathematical notations, do not scale up -[Back] ,
Formal methods users may take issue with this essay's implication that other mathematical
specification languages, such as the Z notation, do not scale up to large programs. For example, Woodcock and Davies introduce their book on using Z with a description of how Z was successfully used in a large commercial programming project.
However, Dr. Parnas' guiding principle of separating representation from interpretation yields important practical advantages over other mathematically-based techniques, especially in applying the methods to large programs.
For example; the display method extends the flexibility of notation discussed above [1], to the verification method itself. The display method naturally accommodates the program's own modular decomposition by allowing the programmer to choose and change the hierarchical decomposition while working with the program. Furthermore, each display presents exactly the information required for verifying the program text. Consequently, the display method combines the convenience of source code comments with the precision of mathematical notation.
The tabular representation also extends the methods' flexibility. First, it allows the programmer to choose the density of expression best suited for any given situation, that is, using I-dimensional text or 2-dimensional tables. Second, it allows for conveniently representing expressions of arbitrary complexity, because the tables themselves represent terms in an expression, and can in turn, contain tables or ordinary expressions.
These factors, combined with the flexibility of notation discussed above [1] gives Dr. Parnas' methods significant practical advantages when using them with large programs.
Bibliography
[Basali] -~
Editorial by Victor Basali of the Experimental Software Engineering Group at the University of Maryland Computer Science Department, Empirical Software Engineering (Vol. 1 no. 2) 1996.
[Bauer] -~
"Experience with the Use of Precise Documentation," Brian Bauer, David Pamas. McMaster University Communications Research Laboratory (CRL Report No. 293), August 1994, (abstract)
[Bilanski] -~
"Steering the right course for software engineering education," Walter Bilanski (president, PEa) Engineering Dimensions, Professional Engineers Ontario reEO), January/February 1999
[Boehm76] -~
"Software Engineering," Ba!!y Boehm, IEEE Translations on Computers, December 1976 (Vol. 25, no. 12), pp. 1226-1241
[Boehm81] -[Back]
Software Engineering Economics, Bar!:y Boehm, Prentice-Hall, 1981
[Boehm88] -~
"A Spiral Model of Software Development and Enhancement," Ba!!y Boehm, IEEE Computer, May 1988 (Vol. 21, no. 5), pp. 61-72
[Brooks74] -~
The Mythical Man-Month, Frederick Brooks Jr., Addison-Wesley, 1974
[Brooks86] -~
"No Silver Bullet: Essence and Accidents of Software Engineering," Frederick Brooks Jr., Information Processing '86, Elsevier Science Publishers B. V. (edited by H. J. Kugler)
[Dakin] -~
"Software Engineer? Time Will Tell," Karl Dakin, IEEE Software, May/June 1997 (Vol. 14, no. 3), pp. 105-106
[Davis, A] -[Back]
201 Principles of Software Engineering, Alan Davis, McGraw-Hill Inc., 1995
[Davis, M.] -~
"Defining Engineer: How To Do It and Why It Matters," Michael Davis, Journal of Engineering Education, April 1996, (Vol. 85, no. 2) pp. 97-101
(DeMarco&Lister] -illllil
Peopleware: Productive Projects and Teams. 2nd ed., Tom DeMarco, Timothy Lister, Dorset House Publishing
[Education] -illllil
"Training for Tomorrow," Special issue on software engineering education, IEEE Software, November/December 1997 (Vol. 14, no. 6)
[Gibbs] -~ '
"Software's Chronic Crisis," W. Wayt Gibbs, Scientific American, September 1994, pp. 86-95
[Haley] -~
"Software Process Improvement at Raytheon," Thomas Haley, IEEE Software, November 1996 (Vol. 13, no. 6), pp. 33-41
[Humphrey] -mack]
A Discipline for Software Engineering, ~), Watts Humphrey, Addison-Wesley
[Iglewski] -ill
"Documentation Paradigms (A Progress Report)," Michal Iglewski, Jan Madey, David Pamas, Philip
Kelly, McMaster University Communications Research Laboratory (CRL Report No. 270), July
1993
[Janicki] -illllil- ill
"Tabular Representation in Relational Documents," Ryszard Janicki, David Pamas, Jeffery Zucker, McMaster University Communications Research Laboratory (CRL Report No. 313), November 1995 (abstract)
[McKee] -mack]
"Computer science, or simply computics?" George McKee, IEEE Computer, December 1995 (Vol. 28, no. 12), p. 136
[Mills et al.] -illllil
Principles of Computer Programming: A Mathematical Approach, Harlan Mills, Victor Basali, John Gannon, Richard Hamlet, Allyn & Bacon, 1987
[NATO] -illllil
"Software Engineering: Report on a conference by the NATO Science Committee," Editors: Peter Naur and Brian Randell, January 1969
[Parnas86] -mack]
"On the Criteria to be Used in Decomposing Systems in Modules," David Pamas, Paul Clements,
IEEE Transactions on Software Engineering, February 1986 (Vol. 12, no. 2) pp. 251-257
[parnas91] -illllil
"Functional Documentation for Computer Systems Engineering," David Pamas, Jan Madey, McMaster University Communications Research Laboratory (CRL Report No. 237), September 1991 (abstract)
[pamas92a] -[Back] .
"Predicate Logic for Software Engineering," David Parnas, McMaster University Communications
Research Laboratory (CRL Report No. 241.1), February 1992 (abstract)
[parnas92b] -mack]
"Formal Documentation or Well-Structured Programs," David Parnas, Ian Madey, Michal Iglewski. McMaster University Communications Research Laboratory (CRL Report No. 259), September 1992
also
"Precise Documentation of Well-Structured Programs," David Parnas, Ian Madey, Michal Ielewski. IEEE Transactions on Software Engineering, December 1994 (Vol. 20, no. 12) pp. 948-976
[Robinson] -I~
"A Historical Perspective of Spectrum Estimation," Enders A. Robinson, Proceedings of the IEEE, September 1982 (Vol. 70, no. 9) pp. 885-907
[ROOM] -ill
Real-Time Object-Oriented Modeling, Bran Selic, Jim McGhee, Garth Gullekson Wiley, 1993 (see also Ob~iecTime)
[SDL] -ill
Specification and Description Language, International Telecommunication Union (ITU) Recommendation Z.1 00, SDL Forum
[Shaw] -~
"Prospects for an Engineering Discipline of Software," Ma!:y Shaw, IEEE Software, November 1990 (Vol. 7, no. 6), pp. 15-24
[Sommerville] -[Back]
Software Engineering, 3rd ed., Ian Sommerville, Addison-Wesley
[Weinberg] -~
The Psychology of Computer Programming. Silver Anniversary!y Edition, Gerald Weinberg. Dorset House Publishing
[W oodcock&Davies] -ill- ill
Usin ation Proo and Re mement, Jim Woodcock, Jim Davies, Prentice-Hall, 1996
[Woodcock&Loomes] -[Back]
Software Engineering Mathematics, Jim Woodcock, Martin Loomes, Addison-Wesley, 1988
[Zave] -ill
"The Operational versus the Conventional Approach to Software Development", Pamela Zave. Communications of the ACM, February 1986 (Vol 27., No.2) pp. 104-118
Anyone may reproduce and redistribute this work, in whole or part, with the following conditions:
1. Reproductions of the whole work, or substantial portions thereof, bear this copyright
notice, 2. Reproductions of smaller excerpts cite the author, and 3. The work is not altered, except by annotations that can easily be distinguished from the
original.
The author may revoke these privileges at any time, without notice.
Anyone interested in distributing this work for fee or profit should contact the author.
