Although the computer field is changing rapidly, some papers on software design have retained their relevance many decades after they were published. The author of three papers that were designated influential by the editors of the IEEE Transactions on Software Engineering discusses why they were written and why they are still considered influential. It also summarizes their messages for today's software developers, software engineering educators, and researchers.

Tabular expressions have been proposed as a notation to document mathematically precise but readable software specifications. One of the many roles of such documentation is to guide testers. This paper 1) explores the application of four testing strategies (the partition strategy, decision table-based testing, the basic meaningful impact strategy, and fault-based testing) to tabular expression-based specifications, and 2) compares the strategies on a mathematical basis through formal and precise definitions of the subsumption relationship. We also compare these strategies through experimental studies. These results will help researchers improve current methods and will enable testers to select appropriate testing strategies for tabular expression-based specifications.

This paper discusses the importance of requirements documents and the reasons that the requirements documentation methods commonly applied in industrial software development are inadequate. The use of functional methods and tabular expressions for producing precise requirements documentation is explained and illustrated. This includes:

Tabular expressions have been used in industry for many years to precisely document software in a readable notation. In this paper, we propose a fault-based testing technique that traces the propagation of faults from the expression in each cell of a tabular expression to the output of the program under test. The technique has been formalized in the form of abstract test case constraints also represented by tabular expressions, so that it can be easily applied and automated.

Anyone developing a Software Engineering curriculum is faced with several dilemmas: Should it emphasize fundamental principles or current technology? Should it teach about a wide variety of approaches or how to use a few important methods? When discussing how the software industry does things, should we teach that this is what to do or what not to do? How should we balance "Core Engineering' vs. "Software Engineering' This talk will discuss one set of answers to these questions and outline a curriculum that implements them.

This paper describes the application of the Trace Function Method to specify the requirements of a software component. We illustrate the method on a software component of a telecommunications system that was developed by Ericsson. Beginning with incomplete informal descriptions, we analysed the requirements of the system and wrote a description that contains all pertinent information in one easily used reference document. The resulting documentation is more compact and complete than traditional software documentation and provides precise information that will be useful for testing and inspection.

The use of several distinct recovery procedures is one of the techniques that can be used to ensure high availability and fault-tolerance of computer systems. This method has been applied to telecommunications systems and usually uses redundant hardware and special recovery software to restore the system after hardware and software failures. We propose a simple practical analytical approach to availability evaluation of systems with several recovery procedures based on a new 'segregated failures' model. To illustrate this method, it is applied to availability evaluation of a Lucent Technologies Reliable Clustered Computing application. Detailed numerical results are provided and the impact of various types of failures and coverage factors on down time is analysed.

Due to the complexity of the code, software is released with many errors. In response, both software practitioners and software researchers need to improve the reputation of the software. Inspection is the only way to improve the quality of software. Inspection methods can be more effective but success depends on having a sound and systematic procedure for conducting the inspection. The Workshop on Inspection in Software Engineering (WISE), a satellite event of the 2001 Computer Aided Verification (CAV '01) Conference, brought together researchers, practitioners, and regulators in the hope of finding effective approaches to software inspection. The workshop included invited lectures and paper presentations in the form of panel discussions on all aspects of software inspection. Submissions explained how practitioners and researchers were performing inspections, discussed the relevance of inspections, provided evidence of how inspections could be improved through refinement of the inspection process and computer aided tool support and explained how careful design of software could make inspections easier or more effective.

Before designing safety- or mission-critical real-time systems, a specification of the required behavior of the system should be produced and reviewed by domain experts. After the system has been implemented, it should be thoroughly tested to ensure that it behaves correctly. This is best done using a monitor, a system that observes the behavior of a target system and reports if that behavior is consistent with the requirements. Such a monitor can be used both as an oracle during testing and as a supervisor during operation. Monitors should be based on the documented requirements of the system. If the target system is required to monitor or control real-valued quantities, then the requirements, which are expressed in terms of the monitored and controlled quantities, will allow a range of behaviors to account for errors and imprecision in observation and control of these quantities. Even if the controlled variables are discrete valued, the requirements must specify the timing tolerance. Because of the limitations of the devices used by the monitor to observe the environmental quantities, there is unavoidable potential for false reports, both negative and positive, This paper discusses design of monitors for real-time systems, and examines the conditions under which a monitor will produce false reports. We describe the conclusions that can be drawn when using a monitor to observe system behavior.

A summary form only given. When writing a requirements document, it is almost impossible to know when you are done. If one works with a list of assertions (whether formal or informal) checking for completeness and consistency is almost impossible. This tutorial explains how an application of the Four Variable Model and Tabular Notation allows one to produce documents that are demonstrably complete and consistent.

Before designing safety- or mission-critical real-time systems, a specification of the required behaviour of the system should be produced and reviewed by domain experts. After the system has been implemented, it should be thoroughly tested to ensure that it behaves correctly. This is best done using a monitor, a system that observes the behaviour of a target system and reports if that behaviour is consistent with the requirements. Such a monitor can be used both as an oracle during testing and as a supervisor during operation. Monitors should be based on the documented requirements of the system.

The paper illustrates how software can be described precisely using LD-relations, how these descriptions can be presented in a readable manner using tabular notations, and one way such descriptions can be used to test programs. The authors describe an algorithm that can be used to generate a test oracle from program documentation, and present the results of using a tool based on it to help test part of a commercial network management application. The results demonstrate that these methods can be effective at detecting errors and greatly increase the speed and accuracy of test evaluation when compared with manual evaluation. Such oracles can be used for unit testing, in situ testing, constructing self-checking software, and ensuring consistency between code and documentation.

A perennial concern of those who teach about computers is the rapid change that we see in our field. The hardware and software that dominated the field just four years ago are not even considered interesting today. When we think about our students, we must wonder how we can teach anything that will be relevant when they graduate or five years later. While the pace of change in computing is unprecedented, the problem of teaching engineers in rapidly changing fields is not. When I received my electrical engineering education in the late 60’s, my teachers were as concerned about rapid change as we are today. When I entered engineering, the “real world” was vacuum tubes, and some people told me that semiconductor physics was “useless theory.” The wise members of the faculty recognized that what we taught had to be useful now, as well as in the future. Today, teaching in an engineering environment once again (after a hiatus of two decades) I can see the wisdom of their choices. The engineering books on my shelves, purchased in the late 50’s, are still true and relevant. In contrast, most of the computer books on my shelves dated in the 80’s, are out of date, irrelevant, archaic, and in many cases, obviously wrong. Things have changed quickly in both areas, but what I learned two decades ago was fundamental and has remained important. As long as I have been observing computer science education, there has been concern about keeping up-to-date. The ACM curriculum recommendations are frequently updated and conference discussions are full of the latest buzzwords and references to the latest research papers. The engineering education tradition, however, is different: it stressed focusing on fundamentals and avoiding fads. In contrast, currently, “teaching new research results” is a scathingly negative comment in all but the most advanced undergraduate engineering courses. In this talk, I will propose and defend a list of fundamental concepts that should be taught in software engineering courses. I will argue that only by not teaching the latest fads, can we give our students an education that will stand them in good stead a decade or two from now. Proceedings of the 10th Conference on Software Engineering Education and Training (CSEE&T'97) 0-8186-7886-0/97 $10.00 © 1997 IEEE

A fundamental assumption of software testing is that there is some mechanism, an oracle, that will determine whether or not the results of a test execution are correct. In practice this is often done by comparing the output, either automatically or manually, to some pre-calculated, presumably correct, output [17]. However, if the program is formally documented it is possible to use the specification to determine the success or failure of a test execution, as in [1], for example. This paper discusses ongoing work to produce a tool that will generate a test oracle from formal program documentation.

Describes a new form of program documentation that is precise, systematic and readable. This documentation comprises a set of displays supplemented by a lexicon and an index. Each display presents a program fragment in such a way that its correctness can be examined without looking at any other display. Each display has three parts: (1) the specification of the program presented in the display, (2) the program itself, and (3) the specifications of programs invoked by this program. The displays are intended to be used by software engineers as a reference document during inspection and maintenance. This paper also introduces a specification technique that is a refinement of H.D. Mills's (1975) functional approach to program documentation and verification; programs are specified and described in tabular form.>

The trace assertion method is a module interface specification method based on the finite state machine model. To support this method, we plan to develop a specification simulation tool, a trace simulator, that symbolically interprets trace assertions of trace specifications and simulates the externally observable behavior of the modules specified. We first present the trace assertion method. Then we formally define trace rewriting systems and show how trace rewriting, a technique similar to term rewriting, can be applied to implement trace simulation.>

A functional approach to specifying the requirements of a computer system is discussed. The method allows system requirements to be documented, whether the system is implemented using a computer and peripheral devices, or, for example, relays and analog components. The method is a refinement of the method used in the A-7 aircraft software requirements model document. The approach is illustrated with examples derived from a software requirements document for a water level monitoring system.>

The interpretations of logical expressions found in most introductory textbooks are not suitable for use in software engineering applications because they do not deal with partial functions. More advanced papers and texts deal with partial functions in a variety of complex ways. This paper proposes a very simple change to the classic interpretation of predicate expressions, one that defines their value for all values of all variables, yet is almost identical to the standard definitions. It then illustrates the application of this interpretation in software documentation.>

The authors explain why pre-run-time scheduling is essential if one wishes to guarantee that timing constraints will be satisfied in a large complex hard-real-time system. They examine some of the major concerns in pre-run-time scheduling and consider what formulations of mathematical scheduling problems can be used to address those concerns. This work provides a guide to the available algorithms.>

Corrected versions are presented for tables I and III that appear in the above-titled paper (see ibid,. vol.19, no.1, p.70-84, 1993).>

The wheel is repeatedly reinvented because it is a good idea. Perhaps Anson's "A Generalized Iterative Construct and Its Semantics" [1] confirms that “A Generalized Control Structure and Its Formal Definition” [2], and the earlier “An Alternative Control Structure and its Formal Definition” [3] presented good ideas. However, there are several misstatements in [1] that should be corrected. The discussion of these issues is made a bit academic by the four-year delay between Anson's submission of his paper (which apparently coincided with the publication of [2]) and the publication of [1]. In that time a generalization of both schemes has been published as a Technical Report [6] and has been submitted for publication. In this generalization the decision about whether a command is iterating or terminating can be made during execution, and the semantics must be that of DO TERM. Further generalizations make the seman tics of the constructs more practical, since side-effects are accurately treated in all cases. A method for reducing the length of guards and avoiding duplicated subexpressions is also provided.

An algorithm that finds an optimal schedule on a single processor for a given set of processes is presented. Each process starts executing after its release time and completes its computation before its deadline and a given set of precedence relations and exclusion relations defined on ordered pairs of process segments are satisfied. This algorithm can be applied to the important and previously unsolved problem of automated pre-run-time scheduling of processes with arbitrary precedence and exclusion in hard-real-time systems.>

Many have sought a software design process that allows a program to be derived systematically from a precise statement of requirements. It is proposed that, although designing a real product in that way will not be successful, it is possible to produce documentation that makes it appear that the software was designed by such a process. The ideal process and the documentation that it requires are described. The authors explain why one should attempt to design according to the ideal process and why one should produce the documentation that would have been produced by that process. The contents of each of the required documents are outlined.

A careful reader, Max Stern of Teradata Corporation, has brought to our attention two errors in the above paper.1On page 253 in the second paragraph under point 4) the text reads, “A purely digital or purely hybrid computer is a special case of this general module.” It should read, “A purely digital or purely analog computer is a special case of this general model.”

This paper discusses the organization of software that is inherently complex because of very many arbitrary details that must be precisely right for the software to be correct. We show how the software design technique known as information hiding, or abstraction, can be supplemented by a hierarchically structured document, which we call a module guide. The guide is intended to allow both designers and maintainers to identify easily the parts of the software that they must understand, without reading irrelevant details about other parts of the software. The paper includes an extract from a software module guide to illustrate our proposals.

Designing software to be extensible and easily contracted is discussed as a special case of design for change. A number of ways that extension and contraction problems manifest themselves in current software are explained. Four steps in the design of software that is more flexible are then discussed. The most critical step is the design of a software structure called the " uses" relation. Some criteria for design decisions are given and illustrated using a small example. It is shown that the identification of minimal subsets and minimal extensions can lead to software that can be tailored to the needs of a broad variety of users.

Program families are defined (analogously to hardware families) as sets of programs whose common properties are so extensive that it is advantageous to study the common properties of the programs before analyzing individual members. The assumption that, if one is to develop a set of similar programs over a period of time, one should consider the set as a whole while developing the first three approaches to the development, is discussed. A conventional approach called "sequential development" is compared to "stepwise refinement" and "specification of information hiding modules." A more detailed comparison of the two methods is then made. By means of several examples it is demonstrated that the two methods are based on the same concepts but bring complementary advantages.

The authors are engaged in a project to produce a precise description of a design for a family of operating systems. The design decisions ue being expressed by means of formal module specifications. In an attempt to write a concise specification of one of the most critical modules, a "virtual memory mechanism," some previously discussed specification techniques proved to be inadequate. The specification was much too large. Through a series of improvements in both the design and the specification techniques we have achieved a much more compact description. This paper begins with the motivation for the design, explains the problems discovered in earlier approaches, and describes the improvements that were made. Finally, the design and its specification are explained.

This is a report on a course entitled, “Software Engineering Methods”, which I have taught to undergraduate students at the Carnegie-Mellon University twice during the 1970-71 academic year. The course is “project oriented” and aims to educate by providing experience in the use of the techniques taught.