25 September 1983 Computer Science 91r -- Ogan Gurel Prof. T.E.Cheatham, faculty advisor Towards a philosophy of a system that supports the modular development (design, coding, testing, and debugging) of computer programs. I feel that the domain architecture that I proposed as a part of the Integrated Development Support Environment for Robot Programming is very relevant in the case of computer programming in general. In particular, I want to focus on the development process as being the successive refinement of both the interrelationships and intrarelationships of modules. In other words, structured design is considered to — play a critical role in the development of computer programs. Therefore, we wish to implement a system that supports structured design in both allowing the user to specify the internal workings of a particular module, and the external relationships between modules. Thus, programming is seen as encompassing two separate (at least superficially) domains. The first domain is, of course, that of specifying the actual design, and coding for each module in the program. The second domain is specifying how these modules are to communicate and interact with each other. But, as we all know, programming is NOT a simple two step process,but rather an iterative one, where one finds himself in between two extremes of programming: a linear path from problem to solution, or an oscillatory path to nowhere. I intend, therefore, to implement the system in the form of two domains (remember, of course, that each domain constitutes a related set of development tools, that together help the programmer refine particular aspects of the program), in which the user can easily jump between domains © and, in turn, the system is cognizant of the ramifications of such "jumping". I call this type of domain architecture a dynamic development support environment. One domain will support the tools for the development of the internal workings of each module whatever role it may play within the system. The major component of this domain is a highly intelligent editor, that responds interactively to abstract high-level specifications that we will call high-level programming verbs. The user will specify parts of the program by referring to the actual functions that the program will perform, Each of these functions represents coding skeletons in the target language that the user may refine using the full- screen capability intelligent editor.These coding skeletons may be defined in the domain primitive library or may be user defined for particular applications. The major point is that thouroughly abstract specifications define each of these program functions such that no conflict will occur when these are strung together to form the final version of the program module. The most obvious advantages of this scheme is that these functions ease the programming process, concentrating the efforts of the programmer on defining the high-level characteristics of the program module, and reusability, which is inherent in the idea that primitive and user-defined high-level verbs are completely portable and language independent. The second domain will support the dynamic conglomeration of modules into a fully developed program or maybe a partially developed program, the point being that it need not be at the end of the development process when the program is then put together. ‘The system will then modify portions of the relevant modules (telling the user of the modifications) in order to facilitate the combination and interaction of those modules. In a sense, this domain functions as a very intelligent linking editor/loader, but its role now plays an integral part throughout the development process. The implementation will be in the form of a full-screen graphical editor which will allow the modules and their relationships*be displayed and edited graphically.An important (but as of yet, undetermined) part of the system will be the measurement and evaluation of such quantities important to the modular structure of the program as binding and coupling. Binding refers to the relationship between elements in a single module and coupling refers the the relationships, and the extent thereof, between different modules. (Stevens, Myers and Constantine). The system will thus be able to tell the user exactly how modular the system is, and how improvements can be effectuated in the overall and individual modular strduture of the system. The philosophy of the dynamic development environment means that the user will be using each of these domains throughout the development process, and that the system must possess adequate intelligence to deal with such vagaries as the user may impose on it. ‘Thus the user may define the overall structure of his program before coding, or may, in fact, implement the coding before combining his modules into a coherent whole, or,(an even more possible scenario) alternate system integration and coding througput the development process. I feel that this system will be a significant step towards the support of the two critical features of software engineering: 1) structured design, and 2) abstract language specifications.