This action might not be possible to undo. Are you sure you want to continue?
HIERARCHICAL SOFTWARE DEVELOPMENT
Ogan Gurel Adams House 1-31 Computer Science 91r 5 January 1984
Prof. T.E. Cheatham, Jr., faculty advisor
Gordon McKay Professor of Computer Science Division of Applied Sciences
The recent interest in program development support environments has been partly a result of much research done on the nature and science of the programming process itself. This paper outlines some of the considerations that enter into the construction of a program development support environment and describes an ideal theoretical structure for such a generalized development system. Finally a system developed by the author that supports the hierarchical development of software for robot control is described.
TABLE OF CONTENTS
Dynamics of the Software Development Process Software Tools and Software Development Support Hierarchies in Software Development Systems Integrated Software Development Systems
The Environment of a Software Development System Theoretical Structure of a Generalized Software
Development Support Environment
An Integrated Development Support Environment for Robot Programming
Over the past few years, a great deal of research effort has been directed towards the development of advanced programming support environments. Many of these are, in fact, being used presently in the development of large software systems while others are still being actively pursued in the research stage.
In this paper we will focus our attention on five particular considerations that enter into the construction of these programming support environments. While, at first glance, it may appear that each of them constitute a distinct and independent aspect of
software development, it will be proposed that in combination these represent an important underlying theme of software development. Namely, our thesis rests on the idea of dynamic modularity which extends the
idea of structured, modular programming throughout the development of a software system.
Dynamic modularity is a concept that frees us from the unnecessary constraints imposed by structured modular programming. Yet, it still retains our most powerful
tool for the successful and efficient development of large software systems which is the idea of "divide and conquer." We divide our original problem into smaller pieces, each of which are much easier to solve than the
original composite problem. As far as experience tells us, this is our most effective methodology available for dealing with complexity; indeed, software systems represent some of the most complex inventions ever devised by man.
Our first task, then is to outline the five software development considerations that we will examine. When we take everything into account, we will outline the theoretical structure of a generalized software development support environment which incorporates the considerations we have discussed.
It turns out that the ideas that will be developed find their most cogent expression in the problems posed by robot programming. In this vein, we will describe an integrated development support environment for robot programming which was developed by the author.
Finally, we will utilize the ideas we have presented in a generalized program development environment that supports dynamic modularity.
Myers, G.J., Composite/Structured Design. Van Nostrand Reinhold Company, New York, 1978.
Yourdon, E., and Constantine, L.L., Structured Design. Prentice-Hall, Inc. Englewood Cliffs, N.J.,1979.
Stevens, W.P~, Myers, G.J., and Constantine, L.L., "Structured Design", IBM Systems Journal, Vol.13, No.2, 1974,115-139.
"Notes on Structured Programming." In: Dahl, O.J., Hoare, C.A.A., and Dijkstra, E.W., Structured Programming, Academic Press, New York, 1972.
Kernighan, B.W., and Plauger, P.J., The Elements of Programming Style., McGraw-Hill, New York, 1974.
II. DYNAMICS OF THE SOFTWARE DEVELOPMENT PROCESS
The process of software development can be conceived as one in which individual modules are written and integrated to produce the final system. A number of steps are taken to achieve this result. Such a step, for instance, is the compilation of a particular module; another is the testing of some other module; another may be link-editing several portions of the final program.
Each of these steps can be thought of as programming activities which a program development environment supports. To be more precise, these activities can include: revising, compiling, printing, transforming, aggregating, analyzing, probing, packaging, etc. as such categories were proposed as a means of comparing such programming support environments.
The ideas of structured design, however, lend certain constraints on the manner in which these activities are carried out and invoked. In particular, when we implement top-down development we follow
a supposedly straight-line path towards our final objective. In other words, we define our top-level
modules, coding them and testing them and then shift
our interest towards the lower-level modules. In the mean time we follow a specific sequence of programming activities: editing, compiling, linking, running, testing, debugging, etc. Often, the path is not a straight
line but an iterative one which, nonetheless, still retains the sequence of activities that characterizes
the straight-line approach.
As a programming methodology, top-down development was meant to simplify the programming process and provide a basis for the effective implementation of modular design techniques. But, in a sense, top-down development reflects the inadquacy of the program development technology. The programming support environments in which most programmers designed and wrote their programs were only equipped to handle the simple path from editing to final implementation. Any deviations from this simple sequence entailed consequences that invalidated all the benefits accrued by using top-down, structured design and development.
In fact, we see that during the life-cycle of a program, the most natural sequence of activities is rarely the simple sequence that we described earlier. Certainly, programming mistakes often cause us to backtrack; sometimes all the way back to the design phase of the project. But, not only mistakes compel us
to change our course of action. If we had our way, we might jump from activity to activity, backwards and forwards, among and between modules.
It is evident that this kind of jumping between programming activities presents many difficulties. As we focus on a particular problem in our program we create a certain context in which we operate in. Thus, for instance, as we simulate a certain module, we may produce intermediate results that may be important, or as we test a second module we may have other results that are significant. These may be called the primary contexts, in that, they reflect the conditions that are presently concerning us. As we switch between these programming activities, we must somehow retain these primary contexts for future use.
More importantly, though, are the secondary contexts which refIect changes in other modules that may be effectuated by our jumping from activity to activity. For example, if we optimize a particular module, then the optimization may effect other time-sensitive modules in the program. The development system must then, not only allow us the luxury of jumping from one programming activity to the other, but must also inform us of the need to edit these other time-sensitive modules.
Another example, may be changing the data coupling
between two specific modules. If these modules call,
or are called by other modules, then the coupling between these modules may also have to be altered. This should be done before we proceed with partial compilation as errors can easily creep in if such matters are neglected.
Thus a development system must not only contain the capability of switching between contexts, but also the intelligence to comprehend the effects, primary and secondary of such context switching. This means, as well, that the software database must also be structured in a manner which allows easy and directed searching for relevant contexts. This implies, as well, that as we switch between "programming activities" we must retain each context associated with the corresponding programming activity. Our software database, must then, be more complex than that implemented for most programming support environments.
Such a development system can be said to support
a "dynamic development environment". The whole philosophy behind such a system can be described as allowing the programmer unlimited and informed access to any and all of the programming activites available during any phase of the program development life-cycle.
The ideas sketched out in this section, namely
those of "programming activities", "primary contexts", "secondary contexts", "context switching", "dynamic development environment", etc. will be discussed in more depth and rigor later when we describe the basic structure of such an advanced program development support environment.
Dennis, J .B., "Modularity", In: Bauer, F.L., ed. Software Engineering., Springer-Verlag, New York, 1975.
Kernighan, B.W., and Plauger, P.J., The Elements of Programming Style, McGraw-Hill, New York, 1974.
Weinberg, G.M., The Psychology of Computer Programming. Van Nostrand Reinhold, New York, 1971.
Cheatham, T.E. "Comparing Programming Support Environments", In: Hunke, H, ed., Software Engineering Environments., North-Holland, Amsterdam, 1981.
Tichy, W.F., "Software Development based on Module Interconnection", In: Proceedings of the 4th International Conference on Software Engineering, September 17-19, 1979.
III. SOFTWARE TOOLS AND SOFTWARE DEVELOPMENT SUPPORT
In this section, we will outline some of the tools necessary to support the programming activities that
we mentioned earlier. We shall see that the range and scope of these tools is highly variable and that a system which encompasses all of these tools would be
a monstrosity in complexity; both to build and to use. From this, we have added incentive to develop a program development support environment structure that allows us the full range of tools without overwhelming both
the designer and the user of the program development environment.
What follows is a brief list of the range of tools currently offered in some form by a number of program development environments. Unfortunately, most development systems do not even provide a majority of the tools listed here; the goal of our generalized development system will be to describe a structure that can incorporate all of these tools.
1. Language translators (compilers/interpreters)
4. Development Control Language
5. Abstract Language Systems
7. Testing modules
8. Software libraries
9. Intelligent (knowledge-based) editors 10. Text processors (documentation aids)
Freedman, M.D., "Tools for the Effiecient Design
of Software". In: Hunke, H, ed., Software Engineering Environments, North-Holland, Amsterdam, 1981.
IV. HIERARCHIES IN SOFTWARE DEVELOPMENT SYSTEMS
The notion of hierarchical design is crucially important in software development. The top-down design methodology is based on a hierarchical design process. In fact, when we interpretively compile a higher-level language such as Pascal into a lower-level language such as p-code and ultimately into a target machine language we impose a hierarchy in programming our system.
Such a mUlti-language system is barely improved upon by contemporary operating systems that concurrently support a number of languages (both high-level and low-level) as well as allow the linking of machine code modules created independently from different source languages. When we mentioned that we aim to provide software tools that guide the programmer through the development process as well as support a particular programming methodology, we would like to see tools that directly support such hierarchical design techniques.
The crucial point, is that a many-language program development system must be aware of the relationships between the languages it supports. This means that dynamic context switching cannot be merely confined to a single language. In a hierarchical system, context
switching must be extended between language systems and the results of programming activities must be made global throughout the hierarchical language structure.
The primary reason for doing this is to simplify the program design and implementation process. If a program can be written in a very high-level language, then it can be compiled into a lower-level language, perhaps with input from the programmer as to the exact meaning of some of the more abstract instructions in the very high-level source code. Hence such abstract languages need not be entirely self-sufficient, and may, in fact, require significant interaction with the programmer during compilation/interpretation in order to supply details that become evident during the evolutionary development of the program.
Indeed, our hierarchy may incorporate a number of abstract languages, in which, the goal of our program development process would be to cascade down through abstract language levels until we reach a target language that can be executed by the computer. During each phase of the abstraction we can apply verification methods to ensure that the abstraction meets the original specifications.
A different research effort has been directed in the line of intelligent editors in order to implement
this hierarchy in program design. As in "The Programmer's Apprentice" system developed at MIT an interactive dialog with the development system is set up that allows a programmer to develop plans (as a form of an abstract language specification) which he can then modify in lieu of modifying the actual program. Thus the programmer can operate on the level of the abstraction rather than the level of the final implementation. These systems can be
implemented by using a sophisticated library of software modules which is handled by an intelligent linking editor.
Perhaps the most important benefits derived from using such higher-level abstract languages is that program reusability and portability can be better facilitated. While past efforts have been aimed at achieving portability at lower software levels it appears that the higher-level specification languages will circumvent the problem of implementation specific programming details. In fact, during the program transformation process, such details could be specified by the programmer during the interactive dialog
with the development system.
Goos, G.,"Hierarchies ", In: Bauer, F.L., ed. Software Engineering., Springer-Verlag, New York, 1975.
Liskov, B., "Modular Program Construction Using Abstraction", In: Bjorner, D., ed. Abstract Software Specifications, Springer-Verlag, Berlin, 1980.
Hewitt, C., "Evolutionary Programming", In: Hunke, H, Software Engineering Environments., Van Nostrand Reinhold, New York, 1981.
Waters, R.C., "The Programmers' Apprentice: KnowledgeBased Program Editing", MIT Artificial Intelligence Laboratory Report submitted to the IEEE Transactions on Software Engineering in March 1981.
Ershov, A.P., "Problems in Many-Language Systems", In: Samelson, K, and P.L. Bauer/ eds., Language Hierarchies and Interfaces., Springer-Verlag, Berlin, 1976.
V. INTEGRATED SOFTWARE DEVELOPMENT SYSTEMS
In the previous two sections we developed two aspects of software development systems that appear to increase the complexity of the development process. On one hand, we have a multitude of development tools that support a single language (editors, translators, the liek) and on the other hand, we have a multitude of languages. Conceivably, each of these languages has its own supporting set of tools. In such a system inconsistencies abound, and our concept of a dynamic development environment is hampered in its realization by the range and variety of such tools.
With the increasing complexity in the system itself, there is a concurrent increase in the complexity of the software database. Besides the problems confronting the programmer in keeping track of all the data elements of the development process,
it becomes difficult for the development system to maintain its own awareness of the interrelationships between different components of the software database.
A major consideration, then, in designing such a program development environment is that of integrating all of the system components and tools. This must also be accompanied by an integration of the software
Probably, the most prevalent method of achieving this integration is by a suitable program development control language. Such a language is not necessarily the same as the abstract higher-level languages that we originally described. Rather, the program development language allows one to systematically develop the program in a predetermined fashion. In this manner, development macros that combine the functions of a number of software development tools can be written to facilitate an integrate implementation of these tools. These macros should be able to span the entire hierarchy of software levels and capable of invoking all the software tools available to the programmer.
In particular, this development control language could be used in devising algorithmic approaches to program debugging. These "debuggin algorithms" could then be augmented with automated test procedures also written in the development control language. The present technology of such development control languages does not progress beyond simple macro definition systems. As such, the implementation of more powerful development control languages would greatly facilitate the development process as well as serve as a basis
for the integration of these software development systems.
In designing such a mUlti-language development system, a major problem is the integration of the differing program modules within the software database of the development system. What is required in such a case is a uniform development system structure that indicates clearly the contexts under which various components of the software database are used. Although such a structure will be discussed in greater detail later we can venture to say at this point that the structure of the software database should closely approximate the integrated structure of software tools as they are presented to the programmer. Components of the software database should correspond with teh programming activities that create and operate on them.
Van Leer, P., "Top-down development using a program design language", IBM Systems Journal, Vol.15, No.2, 1976, 155-170.
Pazel, C.P., Malhotra, A., and Markowitz, H.M.,
"The system architecture of EASE-E: An integrated programming and data language", IBM Systems Journal, Vol. 22, No.3, 1983, 188-198.
Standish, T.A., "ARCTARUS: An Advanced HighlyIntegrated Programming Environment", In: Hunke, H,
ed. Software Engineering Environments., North-Holland, 1981.
VI. THE ENVIRONMENT OF A SOFTWARE DEVELOPMENT SYSTEM
The user-interface is an important aspect of programming support environments. The requirements
vary according to application, but as in the case of
the robot program development system that will be discussed later, the need for an effective user-interface will become clearly apparent.
Briefly, we can outline five factors that we must consider when disigning the structure of program development system and its user-interface. While such matters as screen presentation and computer responses
are important, the underlying structure of the development systemLplays a critical part in the way the system is
used and perceived by the programmer. These five
factors are listed below and serve as guidelines
for the implementation of such development support environments.
* Human Factors
* Intelligent -22-
The idea of a dynamic development environment which we described before, fits into a system that is very flexible. In addition, when we discussed such considerations as hierarchical abstract languages and their interactive implementation (as in the MIT "Programmers' Apprentice system") we were implicitly incorporating such features as interactive user-system dialog and intelligence.
VII. THEORETICAL STRUCTURE OF A GENERALIZED SOFTWARE DEVELOPMENT SUPPORT ENVIRONMENT
We have spoken at some length about the importance of a program design methodology. After discussing various aspects involving software development systems we are now ready to elucidate what the sturcture of advanced program development support environments
should look like. In a sense, we have considered the foregoing analysis as a discussion of design principles that should guide our construction of an appropriate development system. At this point, then, it would be of value to summarize the points we have considered.
Perhaps the most important characteristic we wish to see in our development system is the capability for a dynamic development environmenb. This means that we are looking for a structure that provides a simple interface between the programming activites and the contexts in which they are used. At the same time
we must reduce the complexity that is being posed to the programmer by restricting his access to other tools and components of the software database while he is concentrating on the specific details of the task at hand.
Abstraction and structuring a~e two of the most
powerful tools we have for dealing with complexity.
What we would like to see in our program development system is the capability to support an abstraction and allow easy migration between hierarchical language levels. Furthermore, the structure of our development syste must indicate clearly the role played by modular design in the development of software. It must allow. easy description of module interfaces and module logic. In addition, we would like to be able to jump between external and internal module definitions in the same manner as we have seen with the dynamic development environment. In essence, we have a system that supports dynamic modularity.
Finally, we have to structure our program development support environment so that all the
elements are integrated into one cohesive whole. Although the languages and tools supported by the
system may be extremely varied, there must be some underlying theme that binds the whole system together. What must be presented to the progr~~er is not a well-intentioned but ill-structured package of tools but rather a system of tools that while different in function are similar in usage and conception. In the end result, such a system will be easier to implement than the package concept of a development support environment.
To start out with the description of our theoretical structure we should introduce some terminology to facilitate the discussion. The most important concept is that of a DOMAIN. A domain is, loosely speaking, a set of related software development tools. A text editor can be considered to be an example of such a domain. Another domain can be a simulator that allows one to interactively run portions of his program and test these portions. Each of these domains include a number of subsidiary tools, a primary example of which are the individual commands that form the interface between the system and the user.
The basic idea is that each domain encompasses all the tools used by the programmer during a particular programming activity. Essentially, when a programmer
is operating in a specific domain, he is shielded from the operations available to him in other domains. Thus, the programmer can effectively focus his
attention on the programming activity at hand. The
idea of the dynamic development environment is
important because it ensures that even though the programmer is confined to the operations in the present domain, nothing can stop him from freely "jumping" to another domain. Nor is he stuck to a particular sequence of domains during the development life-cycle of
The next idea that is inextricably linked with that of domains is the concept of a CONTEXT. A
context forms the primary constituent of the software database. It includes all the data structures that are used during a particular programming activity. In other words, each context is associated with one domain, which necessarily entails that contexts may differ from domain to doma. Each domain, then, operates on its own set of contexts and the programmer specifies the current context in which the domain is valid. The process of specifying this context for a particular domain is called ATTACHMENT and the converse process is called DETACHMENT. Hence, making available a context to a domain is called attaching that context to the domain. Strictly speaking, only one context can be attached to anyone domain.
To put these ideas in perspective it is useful to describe these domains and contexts in a more regorous manner with the following assertion:
Let f be a set of development tools that operate on a set of associated contexts (xl,x2' ... 'xn). Then f is a DOMAIN if and only if:
f(xl,X2,.~.,Xn) = y
and y is a distinct attached context.
In other words, each domain may operate on any number of contexts which form part of its associated context set, but there can only be one current context presently operated on by the domain and that is the currently attached context. This deterministic definition of a domain is meant to simplify the range
of operations performed by the domain and to
facilitate a simple interface between domains. Most importantly, when the programmer invokes another domain and then returns to his previously operating domain,
his environment is retained by defaulting the
currently attached context as the PENDING context.
A single language development system can then
be simply described as encompassing a number of domains. A mUltiple language/hierarchical system will involve a number of hierarchically ordered domain systems and their associated contexts. This is most accurately depicted in a picture which is shown in the accompanying figure indicating clearly each domain and its
Integrating the entire system is a development control language that has access to all the programming domains. Macros can be written to invoke the functions associated with each domain and to attach and detach contexts. In this way the power of the development
control language can be extended.
Finally, for each hierarchical elvel there are associated two CORE DOMAINS. One of these domains
is an intelligent full-screen editor that operatoes
on the internal logic of each module being written in
the system. This module is called the intra-module description domain. The second domain acts as an intelligent linking editor and operates on the interfaces or coupling between modules. This domain is called
the extra-module description domain and is implemented
as a graphical editor which depicts the relationships between the various modules. Dynamic modularity, thus becomes manifest as a design methodology as the programmer jumps between intra and extra module defintions, i.e. sometimes specifying the
relationships between modules before describing their internal logic or vice versa.
After describing this theoretical system we should examine some applications. This is done in the next section.
Single Domain System:
r--t I =i i
I • i
I • \
I • !
Multiple Domain/Single Language System:
I I r--1
Multiple Language/Hierarchical Domain system:
VIII. AN INTEGRATED DEVELOPMENT SUPPORT ENVIRONMENT FOR ROBOT PROGRAMMING
The robot program development system that was developed by the author demonstrates some
of the ideas that we have discussed. Some of these
ideas are particularly useful for a development
system focusing on robot programming. For example,
much research effort in robotics has centered on the development of higher-level robot manipulation languages. In addition, the programs that control robots operate naturally in an hierarchical manner. Thus multiple language systems might evolve as a necessity rather
than a luxury. Higher-level languages controlling higher-level functions and lower-level languages implementing lower-level functions.
Using the DOMAIN conc.,apt we defined we can easily describe the basic structure of a development system gerated towards the development of hierarchically related robot programs. In this example three languages are shown: AUTOPASS, which is a very high-level robot language that bases much of its operations on the existence of a world model of
the workspace, RMTM, a relatively high-level robot
language that uses the concept of high-level robot
verbs to execute instructions, and finally we have AMLEE, a relatively low-level (manipulator level) language that operates on a world model that is defined simply by points in the workspace. As of now, only the implementation for AMLEE has been completed. One of
the main restrictions on any further research work has been the fact that AUTOPASS and RMTM have not been completely defined.
As can be seen, each of these language levels is supported by three domains. These domains perform functions adapted especially for the languages they support; that is to say, the editor for one language is (similar in structure) but different in execution from the editor for another language. For instance, a command such as ADD an object to the workspace in the AUTOPASS workspace definition domain would allow the programmer
to add an object such as a hollow block to the
workspace description, while the same command in the AMLEE workspace definition domain would simply allow the programmer to define a single point in the workspace accessible by the robot arm.
The whole system is integrated by the DESIGN/AML language which serves as a general purpose macro
definition language. In this way development programs can be written that combine the functions of a number of domains. The dynamic development environment is essential to the implementation and use of this development control language.
Unfortunately, the system underwent its intial design without including a domain which defines the interfaces between modules. As we said earlier, such
a domain is an essential part of a program development system which supports modular programming. In addition, the idea of contexts was preceded by the more rigid specification of a file as the primary constituent of the software database.
The next figure (following this section) shows the typical flow diagram for the internal workings
of one of the domains in the robot program development syste. Each domain implementation structure contains its own file management program (FILELIST) which allows the user to specify which CONTEXT (in this case file) is to be used by the domain; the default being the pending context. The necessity for a separate file (context) management system becomes clear as we recognize that
from domain to domain the data structures implemented for the corresponding contexts can be vastly different.
In this way, we can add new domains to the system without being restricted to a particular context data structure.
Robot Program Development System Domain Structure:
AUTOPASS Workspace I
Con Edit I
RMTM Workspace I
AMLEE~ I Workspace
SYSTEM IMPLEMENTATION STRUCTURE
I _jrl PFHAND Ii
I I 'I I n
I READCMD PND
1 PNDHAND CMDS
CMDS FILES DIR
PREP ROC 1 U U
n MAC n
PROCCMD I I LIB PROCCMD I i
t- - - - - j :::_I I, II
Thus far we have examined some important considerations involved in the construction of program development support environments. From this discussion we describe a theoretical frameword for the structure of an idealized software development system.
Our next step should then be the refined implementation of such a system. As the paper shows, such an implementation involves research efforts from the entire spectrum of the computer science field.
Our most fruitful results will, however, come from focusing our attention on the five considerations we discussed. In particular, the most important aspect of the system is the facility for domain and context switching. This facility necessarily includes the logic detailing the relationships between individual domains and contexts. Only thus, can we achieve our chief aim, namely that of a dynamic development environment based on dynamic modularity.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue listening from where you left off, or restart the preview.