Browsing by Author "Jameson, Kevin W."
Now showing 1 - 7 of 7
Results Per Page
Sort Options
Item Open Access THE ARCHITECTURE OF EXTENSIBLE EDITING ENVIRONMENTS VOL. II: INTERPRETER ARCHITECTURES(1989-04-01) Jameson, Kevin W.No AbstractItem Open Access THE ARCHITECTURE OF EXTENSIBLE EDITING ENVIRONMENTS VOL. I: EDITOR ARCHITECTURES(1989-04-01) Jameson, Kevin W.This document was originally intended to contain more information than it currently does, but has been reduced to fit within the time constraints of a one-semester course which involved other term work. As a consequence, both volumes in this work lack smoothness and completeness; the changes between topics are often abrupt and there is much left unsaid between the lines. Nonetheless, the documents will be useful for those wishing to know more about the internals of extensible editing environments. They explain and compare in prose many techniques which can only be found and understood through many hours of figuring out poorly documented source code. Due to the limited time available for this project, discussions of the following subject areas have been entirely omitted or severely reduced in scope: Virtual terminals and their role in providing machine independent interfaces to video displays of various kinds and their effects on redisplay technology. On-line help systems from the simple Unix man system to the hierarchical GNU Emacs info system. Syntax tables and their role in interpreting special classes of characters (eg. whitespace) for operations such as searching, dispatching, and balancing. Searching and replacing from simple linear methods to incremental and regular expression techniques. Better explanations of modern conveniences, a more complete discussion of tag tables, directory editors, programming language editing modes, and special display modes. These functions are the reason that extensible editors are so highly valued.Item Open Access A MODEL FOR THE REUSE OF SOFTWARE DESIGN INFORMATION(1988-09-01) Jameson, Kevin W.This paper presents a general model for the representation and manipulation of module level software design information, leading to the effective reuse of software design information across different programming languages. Language independent design documents are represented as ASCII files containing tagged design information sufficient for the construction of a compilable program architecture. The resulting architecture is composed of documented module stubs which describe calling relationships, parameters, functional descriptions, and algorithms characteristic of the architecture. No executable code is included in the compilable modules. Frameworks of tagged locations in language dependent standard module templates are matched against corresponding tags in the ASCII design files, effectively blending language dependent and independent information into a compilable stub architecture. The process can be reversed to generate a language independent design file from an architecture in the standard tagged format, thus supporting the movement of design information across different programming languages.Item Open Access SEE: A SOFTWARE ENGINEERING ENVIRONMENT(1988-08-01) Jameson, Kevin W.The SEE Software Engineering Environment is a practical, portable, software development environment whose tools and concepts are nearly independent of the edited programming language and the supporting host editor environment. The SEE environment is a software engineering environment which manipulates components of the software lifecycle, in contrast to programming environments which manipulate structured programming languages. Three prominent features of SEE which distinguish it from other environments are the use of a standard software module structure to support lifecycle-oriented software tools, the use of source code as a vehicle for the collection and analysis of project size and time cost data, and the use of tools which preserve the developer's mental train of thought and display screen context. SEE supports the four major project activities of design, implementation, documentation, and project management by providing tools and procedures which simplify or automate many common tasks. The portability of the SEE environment is evaluated based on experiences gained in moving the core of the original environment from a Lisp-based mainframe editor to a C-based microcomputer editor, and the utility of the environment is evaluated on the basis of several commerical, institutional, real-time and application projects.Item Open Access A STEP-BY-STEP SOFTWARE DEVELOPMENT PROCESS MODEL(1990-04-01) Jameson, Kevin W.There are three things needed to increase productivity in the software development domain: software development knowledge, an advanced and general level of underlying software technology, and better software tools. The knowledge defines the goals, the technology allows and supports the development of better tools, and the tools implement and achieve the goals set by the knowledge. The order of the three is especially important to understand: the knowledge and purpose for the tool must precede its development. The purpose of this document is to advance knowledge, so that better tools can be built to improve software productivity. In particular, this document makes a relatively hard statement about how software should be developed, by providing a concrete, step-by-step description of the overall software development process. Tool builders can thereby make more assumptions about the software production process, and so can build more effective, more special purpose tools. As a beginning, the process model described in this essay only addresses a very small and limited class of software projects: single person "software tool" projects of up to 50K source lines in size. The following general project activities are discussed in this essay: project startup, analysis, preliminary design, detailed design, implementation, product evaluation, project shutdown, and periodic procedures. Template documents are included for the requirements specification, functional specification, and post mortem document. The appendices contain brief discussions on software cost estimation, on software component structure and design, and on change control systems. In the author's opinion, the process model described in this document meets the Level 2 maturity rating criteria established by the Software Engineering Institute, as described in [17] and [19]. It is important for the reader to understand that this document does not claim to be the only way, the best way, nor even the most appropriate way to develop software. Its only intention is to more concretely describe the general software development used by the author, so that new tools could be developed in the presence of stronger assumptions about the steps in the development process. The utility of this document to other developers, novice or expert, remains to be seen. Regrettably, many worthy topics have been omitted from this document due to unavoidable time constraints. A list of such topics is contained in the conclusion of the paper.Item Open Access Structured coding styles in software development(1990) Jameson, Kevin W.; Colijn, Anton W.Item Open Access A SURVEY OF RESEARCH IN MACHINE ASSISTED SOFTWARE DEVELOPMENT(1989-01-01) Jameson, Kevin W.In contrast to the recent research interest in development environments which support programming-in-the-large and programming-in-the-many, this report is interested in environments which can maximize the productivity of the individual developer. The goal of this report is to identify the most useful techniques for the machine-assisted generation of software programs in arbitrary domains, under the guidance of a single competent individual who is assumed to have a solid understanding of the program requirements. In other words, this report attempts to answer the question: What techniques hold the most promise for maximizing the productivity of the knowledgeable, motivated, \fIindividual\fR software developer? To answer the question, this report surveys machine-assisted software development approaches which are actively concerned with the generation and manipulation of compilable source code. Software development approaches which deal exclusively with early lifecycle activities such as requirements specification have been excluded, as have environments which exclusively emphasize project management activities. All environments discussed in this report are capable of producing source code. The body of the report contains four major sections. The first section introduces a set of evaluation criteria to serve as a basis for comparison, the second section discusses candidate environments, the third develops an idealized environment for the individual developer, and the fourth section summarizes the results, draws conclusions, and suggests future research directions.