The Use of Artificial Intelligence for Program Development
To first understand some complex theories, one must have a fundamental understanding of the basic concepts of software engineering, artificial intelligence, and how they are applicable with each other. First, software engineering is "the field of computer science that deals with the building of software systems which are so large or so complex that they are built by a team or teams of engineers" (Ghezzi 1). Second, artificial intelligence is "the branch of computer science that is concerned with the automation of intelligent behavior" (Luger 1). More specifically, artificial intelligence is the branch of computer science that deals with imprecise, variable, dynamic, or nonlinear/counter-intuitive decision making. Artificial intelligence is related to the other fields of computer science by dynamically changing programming, logic, and dataflow to accommodate variable environmental conditions, especially by using non-preprogrammed comprehension responses. Also, techniques learned from artificial intelligence research makes advanced programming much simpler, especially with regards to information flow and control as a result of advances in knowledge representation. Therefore, the merging of these two concepts is the use of artificial intelligent programming in a specified domain "to study fundamental issues in knowledge representation and reasoning"; so that software engineers can apply these artificial intelligent techniques to help automate or assist the programming process (Partridge 155).
Currently, scientists are attempting to develop "a theory of how expert programmers analyze, synthesize, modify, explain, specify, verify, and document programs" to ultimately create an expert system to assist software engineers during several stages of software development (Partridge 155). Obviously, this theory of duplicating "human programming abilities" cannot be realistically applied in the near future, thus the short term goal is "to develop a system ... that will provide intelligent assistance in all phases of the programming task" (155-156). This promising proposal is called the Programmer's Apprentice Project (156).
The Programmer's Apprentice should have the capability of interacting with the human programmers exactly the same way as human assistants would, thereby hopefully increasing the productivity of the human programmers. Therefore, there would be a great need of clear communication on a high level between the human programmers and the Programmer's Apprentice, along with both having access to a programming environment that they both share. So that, a "substantial body of shared knowledge of programming technique" can be clearly communicated to each other. This should save an enormous amount of time for the programmers; rather than having to explain to the Apprentice from the very "first principles", whereby it would be easier to just program without the Apprentice (Partridge 157). At first, the Apprentice would only be able to handle "the simplest and most routine parts" of programming; however as time progresses and research continues, the Apprentice should be able to deal with more complicated tasks (157-158). Keep in mind, the human programmers will still be necessary to implement code of a 'tricky' nature (such as abstract reasoning or to better cater human preferences) that the Apprentice can not do.
There are two main principles and techniques that govern the Programmer's Apprentice. The first principle involves examining and possibly manipulating "commonly used combinations of elements with familiar names" which are called clichés. Each cliché is made up of roles and constraints. The roles consist of the distinctions between each of the clichés, thus allowing each cliché to maintain their individual properties while still upholding the generality between themselves. On the other hand, the constraints are the fixed elements that are present in every cliché structure. This allows for simple verification of possible structures that could be considered as new roles, and to easily "compute how to fill empty roles in a partially specified occurrence of a cliché" (Partridge 158). "Given a library of clichés, it is possible to perform many programming tasks by inspection rather than by reasoning from first principles. For example, in analysis by inspection, properties of a program are deduced by recognizing occurrences of clichés and referring to their known properties. In synthesis by inspection, implementation decisions are made by recognizing clichés in specifications and then choosing among various implementation clichés" (Partridge 158).
In other words, the Programmer's Apprentice uses specific inspection methods to attempt the automation of the programming process via a library of clichés. Even though clichés are only vague abstractions, they do appear to have the ability of effectively assisting human programmers and possibly speeding up the programming process. However, clichés are quite limited; in that, they are only able to inspect what human programmers have already developed and suggest possible new variants to help solve similar programming challenges. Thus, the Apprentice probably performs better when working with large programs of a repetitive nature, and the Apprentice is almost unproductive in the initial creation of software and totally useless for small programs. In conclusion, clichés should have a secure future in the implementation process of large and repetitive systems; however this technique should be applied and tested before final verification of its feasibility.
The second principle involves applying clichés to programs by representing clichés in a formal or "machine-usable form". This principle is called the Plan Calculus; and as the name implies, it "has both a graphical notation and a formal semantics used for reasoning". Therefore, the Programmer's Apprentice uses the Plan Calculus principle to attain general abstractions directly from the algorithms and data structures in a predefined form and manner, whereby the representation of "control and dataflow" of the clichés is used to simplify code implementation (Partridge 159). As a result, Plan Calculus makes the representation of clichés more tangible objects for the human programmers to work with, thus making clichés even more practical and feasible.
The other approach of artificial intelligence in software development is completely automated program synthesis. The most common type of automatic software synthesis is having human specialists write a complete and concise specification of the desired software; so that, an expert system can generate "functions, data structures, or entire programs" directly from the specifications (Hewett 77). However this method usually only develops applications of a very narrow nature. The main problem with creating a completely automated programming software is with the allowed generality of the specification language and the ability to implement it. Specifically, writing a complete and concise specification in a "general-purpose specification" language sometimes involves just as much work and thought as just writing the program. "Furthermore, there has been little success in developing automatic systems that compile efficient programs for such specifications" (Partridge 156). Thus, it is neither practical nor realistic to develop an expert system that can program a "broad range of applications" with a broad range of abilities in the near future (157).
There are four methods of automatic program synthesis, specifically: "theorem proving, derivational analogy, program transformations, and schema-based programming." In the schema-based programming, each schema is equivalent to an individual programming task, which is comparable to clichés in software assistance. When a familiar task is found within the software specifications, a library of schemas is accessed to determine if a similar task is on file. If an equivalent task is found, then it is retrieved and 'placed' into the software being constructed. However, the most "common problems with schema-based synthesis include acquisition of library of schemas, retrieval of relevant schemas, scaling, and selection of the most appropriate schema when more than one can be applied at the same time." The later problem can be considered as a "control problem", whereby a search algorithm would be needed to determine which schema to use. And currently, search algorithms such as these are being programmed by people, thus decreasing the efficiency of automated programming by another fold (Hewett 77). As a result, automated software development has the same types of problems as software assistance, along with more problems of their own. It can be concluded that automated software synthesis is not as realistic as one might hope for it to be. Maybe in the far future there might be some practical methods of automated programming, however it appears to be very bleak in the near future.
The two uses of artificial intelligence in software engineering are only similar in that they both attempt to increase the productivity and speed of the programming process. The similarities end there for software assistance and automatic software synthesis. Primarily, real automated programming uses "deductive synthesis or program transformations", unlike inspection methods that uses pattern recognition in the already existing code to develop permutations of the code for possible use (Partridge 158). Software assistance is a lot more feasible than automatic programming, because the Programmer's Apprentice Project has already developed a formal method to aid human programmers. On the other hand, automated programming synthesis appears too restrictive in specification requirements and too narrow in applications to be realistically applied presently or in the immediate future.
In conclusion, artificial intelligence in software engineering is a real possibility but extremely restrictive in practicality. However, both methods examined have shown some feasibility with programming assistance by being useful to programmers (at least for the present time). Fortunately, programmers should still have a job for quite some time and have very little to worry about computers replacing their jobs.
by Phil for Humanity
NOTE: This paper was first published in the Fall of 1999.
- Ghezzi, Carlo, Mehdi Jazayeri, and Dino Mandrioli. Fundamentals of Software Engineering. New Jersey: Prentice Hall, 1991.
- Hewett, Micheal, and Rattikorn Hewett. 1994 IEEE 10th Conference on Artificial Intelligence for Applications. California: IEEE Computer Society Press, 1994.
- Luger, George F., and William A. Stubblefield. Artificial Intelligence: Structures and Strategies for Complex Problem Solving. Second Edition. Univ. of New Mexico: Benjamin/Cummings, 1993.
- Partridge, Derek, ed. Artificial Intelligence and Software Engineering. New Jersey: University of Exeter, 1991.