S. Letovsky. Plan analysis of programs. Research Report 662, Yale University,December 1988. PhD.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....to help manage the reverse engineering process. The role of a reverse engineer is to understand a program and to express that understanding using a well defined representation mechanism. To do this, the reverse engineer must answer two kinds of questions: what questions and how questions [8]. What questions concern the goals and requirements of the program; whereas how questions concern the design decisions made by the original developers and how these decisions are manifested in the code [11] The adequacy of a representation indicates the extent to which the representation ....

S. Letovsky. Plan Analysis of Programs. Ph.D. Thesis, Yale University, (1988).

....skills based on the cognitive model of programming knowledge. Even for programs not exceeding 30 to 40 lines of code, the underlying interpretation process is very complex [Bertels et al..93] 2.2.3. Program Transformation 2.2.3.1. CPU Letovsky s Cognitive Program Understander (CPU) Letovsky88] Letovsky86] uses a lambda calculus representation for program. CPU uses transformations to standardize (i.e. make more canonical) the program s syntax and to simplify expressions. However, Letovsky generalizes canonicalization to be the entire means of program recognition. Canonicalization ....

S. I. Letovsky, "Plan analysis of programs," tech. rep., Yale University, 1988. PhD Thesis.

....to help manage the reverse engineering process. The role of a reverse engineer is to understand a program and to express that understanding using a welldefined representation mechanism. To do this, the reverse engineer must answer two kinds of questions: what questions and how questions [8]. What questions concern the goals and requirements of the program; whereas how questions concern the design decisions made by the original developers and how these decisions are manifested in the code [11] The adequacy of a representation indicates whether the representation completely and ....

S. Letovsky. Plan Analysis of Programs. Ph.D. Thesis, Yale University, (1988).

....recognition, provides a short cut to understanding a program s design. It bypasses complex reasoning about how behaviors and properties arise from certain combinations of language primitives. Several researchers have shown the feasibility and usefulness of automating recognition, most recently [1, 9, 10, 12, 15, 16, 24, 25]. A primary motivation for automating recognition is to facilitate tasks requiring program understanding, such as maintaining, debugging, and reusing software. We have developed an experimental recognition system, called GRASPR ( GRAph based System for Program Recognition ) 25] to automate ....

....that can be expressed within our graph grammar formalism. GRASPR is able to recognize structured programs and clich es containing conditionals, loops with any number of exits, recursion, aggregate data structures, and simple side effects due to variable assignments. With the exception of CPU [12], existing recognition systems cannot handle aggregate data structure clich es and a majority do not handle recursion. Side effects to mutable data structures still present an open problem in program recognition, but see [25] for future directions in interleaving dataflow analysis with the ....

[Article contains additional citation context not shown here]

S. Letovsky. Plan analysis of programs. Research Report 662, Yale University, December 1988.

....analyzers capture the syntactic structure of systems, they do not present a higher level, conceptual view of code, systems, and architectures. The AI approach to greater system understanding is to attempt to recognize patterns in code (Kozaczynski, 1992; Kozaczynski, 1994; Wills, 1990; Rich, 1990; Letovsky, 1988; Ning, 1993; Ning, 1994, Quilici, 1994) While such systems can deal with code, they lack attachment to the modeled domain. This theme has been explored by Biggerstaff et al. Biggerstaff, 1994) who argue that parsing based technology lends itself to recognizing programming oriented concepts ....

Letovsky, S. 1988. Plan Analysis of Programs. Ph.D. thesis, Yale University.

....[9] 15] 24] Note that a plan is not necessarily stereotypical or used repeatedly; it may be novel or idiosyncratic, as is the idiom shown in Example 8. Several techniques have been developed for automating the recognition of standard, stereotypical plans (or clich s [15] such as [1] 6] 7][10][11] 12] 14] 16] 26] Experiments with these recognition systems have shown the benefits of uncovering plans in programs to form a basis for understanding the programs. Our categorization of knowledge atoms encompasses plans in addition to other forms of knowledge that are valuable in ....

S. Letovsky. Plan Analysis of Programs. Research Report 662, Ph.D. thesis, Yale University, 1988.

....is very time consuming. The time needed to annotate code makes this approach unworkable for large software systems. 2.5. 2 Finding higher level abstractions Automated program recognition systems parse a program and try to match the code to known clich es to gain an understanding of the program [Letovsky, 1988, Wills, 1990, Lutz, 1992, Wills, 1992] These systems are still in their infancy and only handle short lengths of code. However, it is conceivable that they will evolve to handle larger systems in the future. Once such a system understands a program, it can in principle decide the best ....

Letovsky, S. (1988). Plan analysis of programs. Technical Report Research Report No. 662, Yale University.

....is not as desirable as a textual description of that component. An example of such a situation would be the case when some users of the library are not trained to understand formal specifications. 2.3.1.2. The Cognitive Program Understander (CPU) Letovsky The Cognitive Program Understander [73][82] employs the reverse program transformation method. The reverse program transformation method is similar to automatic program synthesis, but with the direction of the transformation rules reversed. The Cognitive Program Understander uses lambda calculus as its program representation language. ....

....to automate the identification and qualification process as much as possible. Thus the previously described algorithmic approach [24] which normally requires the intervention of a software engineer, was not appealing. The transformational approach suffered from the previously mentioned problems [73]: rules must be matched only to strict syntactic form, which makes the knowledge base very large; also, it is possible to have a transformation cycle, where part of a program is transformed back into its original form; and 59 finally, a transformation rule can not match to non adjacent program ....

Letovsky, S.I., Plan Analysis of Programs, doctoral dissertation, Yale University, December, 1988.

....visibility of a system, building this KB is an intensive task, the automation of which would be a difficult but worthy goal. Various researchers [ 7; 49; 24 ] have addressed the task of scanning code automatically and deriving various kinds of information about the function of the code. Letovsky [ 24 ] and Wills [ 49 ] are concerned with recognizing pieces of code that correspond to simple algorithmic fragments, such as loops, accumulations, etc. Biggerstaff [ 7 ] attacks a different problem; he seeks to mimic the process by which a programmer experienced in writing, say, device drivers, might ....

Letovsky, S., Plan Analysis of Programs, Ph.D. Thesis, Yale University, New Haven, CT, 1988.

....The idea in this representation scheme is to define a semantic function which maps each syntactic entity to its meaning in terms of the effects it induces when is computed. In the denotational semantics approach there is a semantic clause for each of the basic syntactic constructs of the language [Letovsky88]. For composite syntactic constructs there is a semantic clause which is defined in terms of semantic clauses for the immediate constituents of the composite construct. The approach of denotational semantics is to use the static structure to organize the presentation of the dynamical or behavioral ....

Letovsky, S. "Plan Analysis of Programs", Ph.D thesis, Yale University, New Haven CT, Dept. of Computer Science, YALEU/CSD/RR662, December 1988.

....Report from Hill Air Force base [80] and the Software Engineering Institute s planned Best Bractices Guidebook both collect experiences from actual reengineering projects. Theses: recent theses have been published in the area by Allemang [91] Callis [92] Griswold [93] Hartman [94] Letovsky [95], Ning [96] and Wills [43] Finally, a World Wide Web page that contains pointers to work in the area can be found at URL http: www.cc.gatech.edu reverse . IX. ....

S. Letovsky. Plan Analysis of Programs. Ph.D. Thesis, Yale University, 1988.

....and understanding the code requires more effort than actually making the changes [9] But we don t know what makes understanding the code itself so difficult. Letovsky has observed that programmers engaged in software understanding activities typically ask how questions and why questions [17]. The former require an in depth knowledge of the programming language and the ways in which programmers express their software designs. This includes knowledge of common algorithms and data structures and even concerns style issues such as indentation and use of comments. Nevertheless, the ....

....definitions in [18, 28, 34] Note that a plan is not necessarily stereotypical or used repeatedly; it may be novel or idiosyncratic. Following [28, 34] we reserve the term clich e for a plan that represents a standard, stereotypical form, which can be detected by recognition techniques, such as [12, 17, 16, 25, 29, 40]. SUBROUTINE NPEDLN ( A, B, C, LINEPT, LINEDR, PNEAR, DIST ) C IF ( RETURN ( THEN RETURN ELSE CALL CHKIN ( NPEDLN ) END IF C CALL UNORM ( LINEDR, UDIR, MAG ) IF ( MAG .EQ. 0 ) THEN CALL SETMSG( Line direction vector is the zero vector. CALL SIGERR( SPICE(ZEROVECTOR) CALL CHKOUT( ....

[Article contains additional citation context not shown here]

S. Letovsky. Plan analysis of programs. Research Report 662, Yale University, December 1988. PhD.

....an efficient means of reconstructing and understanding a program s design. It bypasses complex reasoning about how behaviors and properties arise from certain combinations of language primitives. Several researchers have shown the feasibility and usefulness of automating recognition, most recently [9, 10, 12, 13, 20, 25, 26]. A primary motivation for automating recognition is to facilitate tasks requiring program understanding, such as maintaining, debugging, and reusing software. We have developed an experimental recognition system, called GRASPR ( GRAphbased System for Program Recognition ) 26] to automate ....

....approach by experimenting with two realworld simulator programs, written in Common Lisp by parallel processing researchers [3] These programs are in the 500 to 1000 line range. The largest program recognized by any other existing recognition system is a 300 line database program recognized by CPU[13]. All other systems work with toy programs on the order of tens of lines. We empirically and analytically studied the computational cost of GRASPR s parsing algorithm with respect to the simulator programs. GRASPR is performing a constrained search for matches of clich es for each rule of ....

[Article contains additional citation context not shown here]

S. Letovsky. Plan analysis of programs. Research Report 662, Yale University, December 1988. PhD Thesis.

....program s code and design. 1 Introduction The standard goal of most program understanding efforts is a tool that takes source code and extracts all of its underlying design. The standard approach to this design extraction is to try to recognize the instances of a library of known code patterns [7, 19, 5, 16, 4, 13, 8, 11, 6]. Unfortunately, there are two fundamental problems with trying to apply this approach to large, real world legacy systems: 1. This approach requires enormous libraries of code patterns, since each new domain requires its own set of domain specific patterns. 2. This approach is doomed to ....

....mechanism for automatically extracting some of this object oriented design from the source code. Significant technical progress has been made in the area of program understanding in dealing with specific problems such as code variability and in finding algorithms for locating patterns in the code [7, 19, 20, 5, 8, 11, 6]. These previous approaches, however, have made two key assumptions: 1. The library of code patterns needed to automatically extract a program s design is small. 2. The knowledge base describing a program s design that results from this process is static. Neither of these assumptions holds in ....

S. Letovsky. "Plan Analysis of Programs". Ph.D. Thesis, Yale University, New Haven, CO, 1988.

....tasks including software transformation, re engineering, and software reuse the systems try to understand the whole program. The overhead involved limits most systems to work with toy size programs only. Moreover, these systems cannot handle many program fea tures, like pointers. Letovsky [42] and Ambras and O Day [6] suggest that the use of dynamic information can ease the understanding of poorly structured code and can possibly recognize more plans. 2.4 Locate Faults without Program Understanding The system can identify the bugs without any understanding of the code, if it has ....

Stanley Letovsky. Plan Analysis of Programs. PhD thesis, Yale University, New Haven, CT, 1988.

.... The third dimension is the familiarity of the plans interleaved: are they clich es (i.e. stereotypical, frequently used plans) or are they unfamiliar plans (i.e. novel, idiosyncratic, or not used repeatedly) When what is interleaved is familiar (i.e. a clich e) clich e recognition (e.g. [10, 12, 13, 14, 18, 28]) is a useful detection mechanism. 3 In fact, most recognition systems deal explicitly with the recognition of clich es that are interleaved in specific ways with unrecognizable code or other clich es. One of the key features of GRASPR [28] for instance, is its ability to deal with ....

S. Letovsky. Plan analysis of programs. Research Report 662, Yale University, December 1988. PhD.

....arises from using a chart parsing algorithm which makes control and search strategies explicit. 1. 1 Previous Recognition Work Several researchers have shown the feasibility of automating recognition and the usefulness of its results, most recently Bertels [1] Hartman [6] Johnson [8] Letovsky [10], Murray [12] Ning [13] and Wills [18] See [19] for a more detailed description of these systems and earlier research in this area. All existing recognition systems are isolated, standalone systems which are not expected to interact with people or with other reverse engineering techniques. ....

....or with other reverse engineering techniques. They all are committed to a rigid control strategy, typically targeting a particular application, such as debugging, restructuring, or documentation. Some [8, 12] have cost cutting heuristics built in which are chosen on a trial and error basis. Some [8, 10, 12] search for a single best interpretation of the program, while permanently cutting off alternatives, so their power cannot be incrementally increased. They also cannot generate multiple views of the program when desired, nor provide partial information when only near misses of clich es are ....

[Article contains additional citation context not shown here]

S. Letovsky. Plan analysis of programs. Research Report 662, Yale University, December 1988. PhD Thesis.

No context found.

S. Letovsky. Plan analysis of programs. Research Report 662, Yale University,December 1988. PhD.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC