No description available.

No description available.

No description available.

No description available.

No description available.

No description available.

No description available.

The purpose of this project was to develop, using Object Oriented Development (OOD), a software tool identified as the Ada Module Description Tool (AMDT). The AMDT provides an automated way to get a module level description of Ada code. A module level description will identify packages, subprograms, objects and type declarations and relationships. This software tool also has the ability to compare Ada source code with a module level description. The comparison shall identify any object, type, subprogram, or package declared in the module level description that does not match the provided source code.The AMDT is made up of two executable programs that run on a VAX/VMS system. The Module Description Generator (MDG) generates a module level description from a set of Ada source code files. The Module Description Checker (MDC) compares a module level description to the Ada source code. Ada is the required High Order Language for the Department Of Defense. The development methodology used was basically Object Oriented Development as described in the book Software Engineerinq With-AAA by Grady Booch and the Software Standards and Procedure Manual for Object Oriented Development (SSPM-M02.04 Draft).Booch's book is a description of Object Oriented Development methodology, while the SSPM is a set of instructions and standard format to implement the methodology. The total design of the AMDT is documented in five segments. The SSPM defines a segment as the code and documentation resulting from a pass through the OOD process. From a Software Quality Engineer's point of view the AMDT would save time in not having to check module descriptions by hand. From the Software Engineer's point of view, when the code is updated a new module description can be generated easily to keep the documentation current with the code. The AMDT tool as written does not find object declarations in the code. Fortunately the effect is minor because the module descriptions needs to be edited anyway. The module description generated by the MDG may have too much information in it. The designer wants only the types, objects, and operations that aid in the understandability of the design and how it is implemented. The only checks the MDC makes are to see if an identifier on the module description is in the code. It does not check to see if there are extra items in the code that should be required in the module description. / Department of Computer Science

The purpose of this dissertation was to write and make available a small set of PL/1 computer subroutines that can be used in other computer programs attempting to do any kind of analysis of natural language data. The subroutines present in the dissertation are for some of the housekeeping, that is the jobs that must be done before analysis can begin.Four subroutines were written and tested: a subroutine called FINDONE (find one) that isolateswords in an input string of characters, and three subroutines, called the LAGADOs, that find words or word parts on lists of words or word parts. The reliability of the subroutines was tested in small testing programs and in a larger lexical diversity program that was modified to use the subroutines.FINDONE finds graphemic words and punctuation marks in an input character string. In addition, it truncates the input string from the left so that repeated calls of the subroutine finds the words in the input string in sequence. FINDONE takes as parameters the name of the input string and a name to be associated with the word found.The three LAGADO functions search for words on lists of words. Each of the functions is designed to search a list of a certain structure. LAGADO1 searches an alphabetized list where to length of the list is known. It uses the economical binary search technique. LAGADO1 takes as parameters the name of the word searched for, the name of the list to be searched and the length of the list to be searched.LAGADO2 searches a list in any order that is alphabetically indexed by an indexing array. LAGADO2 takes as parameters the name of the word being searched for, the name of the list being searched, the name of the indexing array, and the length of the list being searched.LAGAD03 searches any list that has an end-of-list symbol. LAGADO3 uses a linear search technique and looks at each element of the list being searched in order until it either finds the word being searched for or the final boundary symbols. LAGADO3 takes as parameters the name of the word searced for, the name of the list being searched, and the name of the end-of-list symbol.Each of the LAGADO functions returns a positive value equal to the subscript of the list element that matches the input word if the input word is matched, or a negative number whose absolute value is the subscript of the location of the cell where the input word would have to be inserted into the list if the input word is not matched.Two of the subroutines, FINDONE and LAGADO2, were tested by being incorporated into SUPRFRQ, a lexical diversity program developed from an earlier program written by Robert Wachal. An Appendix includes the documented texts of he subroutines and of the lexical diversity program. In addition, the appendix includes the result of a run of SUPRFQ on for short dialect texts collected, by Charles Houck in Leeds, England.

A Scott/Strachey style denotational semantics intended to describe pure LISP is examined. I present evidence that it is an accurate rendering of the language described in chapter 1 of the LISP 1.5 Programmer's, Manual, in particular I show that call-by-value and fluid variables are correctly handled. To do this I have: (1) written an operational 'semantics' of pure LISP and shown it equivalent to the denotational one (2) Proved that, relative to the denotational semantics, the LISP functions apply,eval,...,etc. correctly compute meanings. The proof techniques used are derived from the work of Wadsworth; roughly one first proves the results for a class of 'finite' programs and then extends them to all programs by a limiting argument. Conceptually these arguments are inductions on length of computation and to bring this out I've formulated a rule of inference which enables such operational reasoning to be applied to the denotational semantics.