RESEARCH CONTNBUTIONS p~:~ ....... .... Program Design by Informal English Descriptions ~ S S ~ , L Jo ~ The Aerospace Corp. and California State University Russell 1. Abbott is a Professor of Computer Science at California State University, Northridge and a member of the professional staff at the Aerospace Corporation. His current interests include object-oriented and dataflow approaches to software architecture and the application of knowledge acquisition techniques to requirements analysis. Author's Present Address: Russell J. Abbott, Computer Science Department, California State University-- Northridge, Northridge, CA 91330 The Aerospace Corporation, MI-106, P.O. Box 92957, Los Angeles, CA 90009 ARPANET: Abbott @ Aero. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. �� 1983 ACM 0001-0782/83/1100-0882 75�� 1. INTRODUCTION This article discusses data types and their use in program design. A data type is a category of beings or things, Data types are useful for the logical organization of information and most people use them naturally in their everyday activities. Most people are not aware, however, that this familiar method of dividing the world into classes of objects can be directly related to the programming language notion of data types. This article illustrates the use of data types in program design by demonstrating how an arbitrary procedure, initially stated in English, can be transformed into a program written in Ada. 1 The resulting program corresponds quite closely to the original English algorithm. Most striking is the parallel between the noun phrases ~n the original and the data types and program objects in the program. The bulk of this article is a discussion of that correspondence and of how to make the transformation between noun phrases and data types and objects. We discuss program development from the traditional viewpoint of program design--where a program is a sequence of processing steps. We focus on the process by which one creates a program to achieve a programming goal, having been given an intuitive description of the goal. Most program- mers find themselves in this situation most of the time. In solving such a problem, one must develop both a process to be performed and a collection of objects on which to perform it. Development of the process proceeds in parallel with the development of the object definitions. Although certainly not as formal as the methods of Dijkstra [3], Hoare [6], Wirth [10], and others, the focus is similar--the development of precise and understandable programs. The method presented extends and makes more intuitive the approaches of, for example, Parnas [8] and Liskov [7]. In particular, the paper identifies common nouns as a natural ' Ada is a registered trademark of the Department of Defense. ABSTRACT: A technique is presented for developing programs from informal bat precise English descriptions. The technique shows how to derive data types from common nouns, variables from direct references, operators from verbs and attribates, and control structures from their English equivalents. The primary contribation is the proposed relationships between common nouns and data types the others follow directly. Ada is used as the target programming language because it has useful program design constructs. 882 Communications of the ACM November 1983 Volume 26 Number 11

RESEARCH CONTRIBUTIONS language analog to the programming language notion of ab- stract data types. This extends the current understanding of data types as follows. A type is currently understood as a collection of values and a collection of operations applicable to those values [4, 5]. Common nouns are more than that. A common noun names a class or concept even though there may be no values or operations yet defined for that class or concept. Common nouns provide a conceptual hook for a concept that may not be fully formed they permit one to declare the existence of a concept whose details have yet to be worked out. In natural language, one frequently creates and uses a common noun before the details of the concept are thought through. Program design methodologies have not been so forgiving about data types, insisting that a data type is exactly the values and operations defined for them. As used in natural language, common nouns permit the need for a concept to be established before the concept itself is fully defined. Associating common nouns with data types also makes the notion of data types more intuitive. Most people already have an intuitive understanding of common nouns. They will un- derstand data types better when seen as analogous to com- mon nouns. This article is organized into 11 sections. Section 2 intro- duces the example through which the approach will be dem- onstrated. It also provides an overview of the approach. Sec- tion 3 discusses various classes of nouns and noun phrases. Section 4 derives the example problem data types. Section 5 derives the example problem data objects. Section 6 is a dis- cussion of the difference between noun phrases that refer directly to objects and noun phrases that describe objects without guaranteeing a referent. Section 7 derives the opera- tors of the example problem. Section 8 completes the transfor- mation of the English statement of the problem solution into a program. Section 9 segments that solution into an problem specific part and a data type package. Section 10 applies the same method to another problem: the KWIC indexing prob- lem. Section 11 presents some concluding thoughts. 2. AN APPROACH TO PROGRAM DEVELOPMENT We present our technique by means of an example. Consider the following easy problem: Write a function subprogram that, given two dates in the same year, returns the number of days between the two dates. This is certainly a simple enough problem. The only difficulty is in specifying the calendar by which days are counted. Our current calendar is quite ad hoc. Its specification involves various rules and tables for dealing with special situations, e.g., leap year. A good approach to this and similar situations is to create a calendar module (or package in Ada) in which calendar con- cepts are defined. Such a calendar package provides defini- tions for calendar data types and makes available operations on calendar objects of those types. Using those type and oper- ation definitions, one then writes the desired program in terms of them. In this approach, the calendar concepts and operations are encapsulated within the calendar package, and only the data types and the operations on objects of those types are visible outside the package. Although this paper is not primarily about package construction methodology, it is about the use of packages for the definition of data types. Thus, a few brief words about packages may be appropriate. (For a further discussion of data types and their use in pro- gramming, see [1-8, 10]). A package encapsulating a data type or a related collection of data types permits the separation of two levels of program- ming concerns. 1. It permits one to separate (a) the details of the calendar that are important for any program dealing with calendar problems, that is, "how many days there are in February," from (b) the concern with the particular problem to be solved, that is, "how many days there are between two given days." 2. It also permit one to separate (a) the definitions of the data types and operators use- ful for solving a problem, that is, calendar data types and operators, from (b) considerations of how those data types and opera- tors are actually implemented. The use of a package containing the data types for a prob- lem solution leads to a program of the following general struc- ture: package DATA_TYPE_PACKAGE is - - The package "visible part" in which the data types and - - operators on objects of those types declared. This part - - should also provide a concept,ial model of the defined - - types. The conceptual model should provide enough in- - - formation so that the types and their operations can be - - used in other programs. end DATA_TYPE_PACKAGE package body DATA_TYPE_PACKAGE is - - The package body in which the operators are imple- - - mented. The user of the package need never consult this - - part as long as he or she understands the conceptual - - model. Package bodies are not discussed further in this - - article. end DATA_TYPE_PACKAGE with DATA_TYPE_PACKAGE - - Provides access to the - - package facilities. procedure PROBLEM_SOLUTION is - - The particular problem is solved in terms of the declara- - - tions in the data type package. end PROBLEM_SOLUTION This article shows how an analysis of the English statement of the problem and its solution can be used to guide the devel- opment of both the visible part of a useful package and the particular algorithm used for the given problem. The approach focuses initially on the concrete, that is, on the solution to the given problem. Rather than first specifying the calendar package and then writing the program using capabilities from that package, we first write the program in terms of our intuitive understanding of the calendar and later formalize that understanding in the process of writing the program. Once finished with the program, we segregate the general calendar information from the problem-specific algo- rithm and offer it as a separate Ada calendar package. The resulting program and package will be similar to the one we might have developed had we approached it the other way, that is, by writing the package first the difference is only in the way we get there. We take this approach not because we November 1983 Volume 26 Number 11 Communications of the ACM 883