David Lorge Parnas

On the criteria to be used in decomposing systems into modules

This paper discusses modularization as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time. The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules. A system design problem is presented and both a conventional and unconventional decomposition are described. It is shown that the unconventional decompositions have distinct advantages for the goals outlined. The criteria used in arriving at the decompositions are discussed. The unconventional decomposition, if implemented with the conventional assumption that a module consists of one or more subroutines, will be less efficient in most cases. An alternative approach to implementation which does not have this effect is sketched.

A technique for software module specification with examples

This paper presents an approach to writing specifications for parts of software systems. The main goal is to provide specifications sufficiently precise and complete that other pieces of software can be written to interact with the piece specified without additional information. The secondary goal is to include in the specification no more information than necessary to meet the first goal. The technique is illustrated by means of a variety of examples from a tutorial system.

Concurrent control with “readers” and “writers”

The problem of the mutual exclusion of several independent processes from simultaneous access to a “critical section” is discussed for the case where there are two distinct classes of processes known as “readers” and “writers.” The “readers” may share the section with each other, but the “writers” must have exclusive access. Two solutions are presented: one for the case where we wish minimum delay for the readers; the other for the case where we wish writing to take place as early as possible.

The Modular Structure of Complex Systems

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.

Scheduling processes with release times, deadlines, precedence and exclusion relations

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. >

Functional documents for computer systems

Although software documentation standards often go into great detail about the format of documents, describing such details as paragraph numbering and section headings, they fail to give precise descriptions of the information to be contained in the documents. This paper does the opposite; it defines the contents of documents without specifying their format or the notation to be used in them. We describe documents such as the “System Requirements Document”, the “System Design Document”, the “Software Requirements Document”, the “Software Behaviour Specification”, the “Module Interface Specification”, and the “Module Internal Design Document” as representations of one or more mathematical relations. By describing those relations, we specify what information should be contained in each document.

Evaluation of safety-critical software

Methods and approaches for testing the reliability and trustworthiness of software remain among the most controversial issues facing this age of high technology. The authors present some of the crucial questions faced by software programmers and eventual users.

A rational design process: How and why to fake it

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.

Wikipedia risks

The Wikipedia (WP; en.wikipedia.org/wiki/) applies the wiki technology (from a Hawaiian word for “quick”) to the encyclopedia, a venerable form of knowledge organization and dissemination. Wikipedia provides a fast and flexible way for anyone to create and edit encyclopedia articles without the delay and intervention of a formal editor or review process. The WP’s over 750,000 articles are written and edited by volunteers. WP founder Jimmy Wales believes WP’s free, open, and largely unregulated process will evolve toward an Encyclopædia Britannica or better quality. But will this process actually yield a reliable, authoritative reference encompassing the entire range of human knowledge? Opinions are mixed. WP claims to be the most popular reference site on the Internet. It has been hailed as the quintessence of the “wisdom of crowds,” as a model of democratized information, and as a nail in the coffin of the “stodgy old commercial encyclopedia.” Others are concerned about the reliability of an uncontrolled reference work that may include any number of purposeful or accidental inaccuracies. Some observers wonder why anyone would accept information from anonymous strangers of unknown qualifications. WP’s first editor in chief, Larry Sanger, believes that an anti-expertise bias among “Wikipedians” foreshadows the death of accuracy in scholarship (“Why Wikipedia Must Jettison Its Anti-Elitism”; www.kuro5hin.org/story/2004/12/30/142458/25). Robert McHenry, former editor of Encyclopædia Britannica, is even more blunt in asserting that the community-accretion process of Wikipedia is fundamentally incapable of rising to a high standard of excellence (“The Faith-Based Encyclopedia”; www.techcentralstation.com/111504A.html). Regardless of which side you’re on, relying on Wikipedia presents numerous risks: • Accuracy: You cannot be sure which information is accurate and which is not. Misinformation has a negative value; even if you get it for free, you’ve paid too much. • Motives: You cannot know the motives of the contributors to an article. They may be altruists, political or commercial opportunists, practical jokers, or even vandals. • Uncertain Expertise: Some contributors exceed their expertise and supply speculations, rumors, hearsay, or incorrect information. It is difficult to determine how qualified an article’s contributors are; the revision histories often identify them by pseudonyms, making it difficult to check credentials and sources. • Volatility: Contributions and corrections may be negated by future contributors. One of the coauthors of this column found it disconcerting that he had the power to independently alter the Wikipedia article about himself. Volatility creates a conundrum for citations: Should you cite the version of the article that you read (meaning that those who follow your link may miss corrections and other improvements), or the latest version (which may differ significantly from the article you saw)? • Coverage: Voluntary contributions largely represent the interests and knowledge of a self-selected set of contributors. They are not part of a careful plan to organize human knowledge. Topics that interest the young and Internet-savvy are wellcovered, while events that happened “before the Web” may be covered inadequately or inaccurately, if at all. More is written about current news than about historical knowledge. • Sources: Many articles do not cite independent sources. Few articles contain citations to works not digitized and stored in the open Internet. The foregoing effects can pollute enough information to undermine trust in the work as a whole. The WP organizers are aware of some of these risks, acknowledging that “Wikipedia contains no formal peer review process for fact-checking, and the editors themselves may not be well-versed in the topics they write about.” The organizers have established a background editorial process to mitigate some of the risks. Still, no one stands officially behind the authenticity and accuracy of any information in WP. There is no mechanism for subject-matter authorities to review and vouch for articles. There are no processes to ferret out little-known facts and include them, or to ensure that the full range of human knowledge, past and present, is represented. The Wikipedia is an interesting social experiment in knowledge compilation and codification. However, it cannot attain the status of a true encyclopedia without more formal content-inclusion and expert review procedures.

Using test oracles generated from program documentation

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.