CHAPTER 7
CONCLUSION AND FUTURE DIRECTIONS
Despite the fact that the acceptability of the integrated environment of Small Ada itself was not being measured, it was observed that no subject experienced difficulty in using it. The subjects had only ten minutes of instruction to learn the basics of editing, compiling and running the programs. In addition, the subjects of the experimental group had to spend extra time on learning how to use ADAT.
From the results obtained, one can conclude that the use of ADAT to identify bugs in concurrent programs proved to be an effective approach, at least for novice concurrent programmers. The findings provide strong evidence that systems like ADAT can be a valuable tool for teaching novice concurrent programmers.
Very high-level debugging of concurrent programs is a promising area of research. Making tools perform deductions about the programmer's intentions by using only the source code is a challenging issue. Programming languages are well-defined abstractions for communicating algorithms to computers. The semantics of each construct must be well-documented and enforced by translator systems. However, what can be said about the semantics of a block of statements? Usually, the creator of these statements is the only one who can readily explain their meaning.
Empirical studies of programmers have found that expert programmers can better understand programs written by others. There is evidence that these programmers use their knowledge, obtained through previous experience, to recognize chunks of code in order to make assumptions about the purpose of a program. Having information on the purpose of a program and its building blocks is an essential requirement for debugging. When working with a faulty program written by someone else, an expert programmer may reach two distinct conclusions about the feasibility of correcting the program: it can or can not be corrected. If it can not be corrected, all the work is lost. This may occur due to the way a program is written. Programs without structure are potential candidates for rejection. Well-designed programs allow better understanding. In the concurrency scenario, this problem becomes even more acute. By looking at a filtered view of a program, it is possible to analyze just what is filtered. If one filters only task interaction information, it is possible to supply a diagnosis about the condition of a concurrent program. This is the approach followed by ADAT. Hathorn [Hath88] introduced the concept of structured concurrent processes, a concept analogous to sequential structured programming [Bohm66].
The present research focused on a debugging tool designed for novice concurrent programmers. In this scenario, it is possible to enforce the concept of structured concurrent processes. Only two types of processes are used. According to Hathorn, a calling process only makes entry calls. A service process only accepts them. This may seem to be a severe limitation, but a mixed process may only be required in the implementation of a complex problem. ADAT can then be extended to deal with problems such as the one presented by Luckham and Helmbold [Luck85] in the Gas Station program. The customer task should be transformed in a calling task and the others adapted accordingly.
A related issue that can be further addressed is a study on how expert concurrent programmers develop, implement and maintain concurrent programs, especially Ada programs. By performing such an in-depth study, it may be possible to document and synthesize vital information on task interaction protocols and then generate a set of formal rules on how to express concurrency correctly in all known scenarios. The ideas raised in this research could then be further extended to cover a larger spectrum of problems, their identification, as well as procedures for solving these problems. There seems to be empirical evidence that in programming, much activity consists merely of reinventing the wheel in the many aspects of the software development cycle. Carrying out the task proposed above might be a step toward making one programming field, concurrent programming, more scientific and efficient.
The ideas presented in the present research may lead to the development of not only very sophisticated debuggers, but also to the development of conversion rules for intertask communications. These conversion rules would be analogous to the conversion rules commonly employed by translators when dealing with real and integer variables, for example. When identifying the presence of the server anomaly, the programmer could be notified by receiving a warning and perhaps some additional explanations that a server was being implemented by the translator.
Just as sentences express thoughts, feelings, and intentions that are understood by others, a complete set of program fragments can express the program's purpose. It is difficult to understand someone else's code, but not impossible. The activity of creating software allows for the expression of a problem's solution in a large number of ways. This is due to the flexibility that is given to programmers to express their ideas. In other fields, like architecture and engineering, this flexibility is less possible. First, these fields are regulated by law. For instance, the construction of even a simple house must have a plan, written in standard terminology, approved by a set of experts. What would happen if such plans were written using arbitrary notation and terminology? The cost of construction and maintenance would reach astronomical proportions, just as the costs are soaring in software design, implementation and maintenance. All activity related to software must be regulated and standards must be defined. In the architecture field, for example, there exists a well-defined set of materials in a variety of specifications, all of which are expressed in a common and well-understood terminology. The same is true in the field of electrical engineering, where one of the most simple and evident conventions are the colors used in wires to represent positive and negative currents. There is no enforcement of a methodology in programming other style. By borrowing from the above mentioned fields, the entire field of software development could be greatly improved. This improvement could be achieved by documenting all software components already built (as mentioned earlier in Chapter One, other fields have well-documented algorithms for performing specific tasks). Programs and systems would then be built from software parts, where each part also contain complete semantic information that could be used by automated systems to perform integration and to check consistency. Databases of software parts would then become available and facilitate, through interactive tools, the semi-automation of software design, implementation and maintenance. In this scenario, the idea of generics implemented in Ada is of immense importance. The debugging activity could be confined within software factories which would employ highly trained and specialized personnel.