Neighbors, James M., "Tutorial: Metacompilers Part 1", August 20, 2008. Tutorial HTML Metacompiler Workshop HTML Tutorial PDF (45 pages) |
Abstract:This tutorial provides a step-by-step process of building a metacompiler that incorporates a domain-specific language for specifying compilers. The tutorial is aided by the Metacompiler Workshop which is a webpage capable of building and running the compilers using JavaScript in Frames. We start with META II by D.V. Schorre in 1964 and end with a completely self-contained metacompiler implemented as a single JavaScript object. You will be able to use the Metacompiler Workshop to cross compile any of the metacompilers to your language of choice. Along the way we will experience the strength of using a domain-specific language independent of its implementation. |
Neighbors, James M., "Where Does Reusable Generative Knowledge Come From?", Invited talk Generative Programming Workshop (GP2002), de Jonge, Merijn and Visser, Joost, editors, at Seventh International Conference on Software Reuse (ICSR7), Austin, TX, April 2002. SLIDES |
Abstract:This talk provides a brief history of computing from the 1940s through 2002 to answer the question "How has knowledge been gained and evolved into reusable generative forms in the past?" An evolutionary process of ideas is discussed and historic lessons for generators are presented. Finally, we relate generators to the never ending problem of building "intelligence amplifiers" and suggest that artifacts other than program code should also be targets for generation. |
Neighbors, James M., "Techniques for Generating Communicating Systems", Generative Programming Workshop (GP2002), de Jonge, Merijn and Visser, Joost, editors, at Seventh International Conference on Software Reuse (ICSR7), Austin, TX, April 2002. PAPER or SLIDES |
Abstract:This position paper presents a simple triad model for generating communicating systems. We show a simple architectural and instance example of the model as web services. This example demonstrates the inherent danger presented by detail, version and configuration in attempting to maintain a model of concrete implementation instances by the generator. We point out that in the past generators have solved this problem by forming private simple abstractions of implementation instances. Currently meta-definitional forms such as XML are enjoying resurgence. Because of market forces these meta forms have complex version and configuration spaces. We have found that the old technique of forming private simple abstractions of meta forms still works well to isolate the details, version, and configurations of instance meta forms such as XML. Finally we discuss our belief that the formation of these private abstractions is the creation of domain hierarchies. |
Neighbors, James M., "Transforming Experiences", International Workshop on Software Transformation Systems (STS'99), at 21st International Conference on Software Engineering (ICSE21), Sant'Anna, M., editor, Los Angeles, May 1999. PAPER or SLIDES |
Abstract:This paper describes our experience with program transformation systems from 1974 to the present. It provides a rationale for how our use of the technique has evolved. |
Neighbors, James M., "Domain Analysis and Generative Implementation", Panel: Linking Domain Analysis and Domain Implementation, Frakes, W., moderator Fifth International Conference on Software Reuse (ICSR5), Devanbu, P., and Poulin, J., editors, pp. 356-357, June 1998, Victoria, Canada, IEEE Press, 1998. PAPER or SLIDES |
Excerpt:Automatic Programming research in the 1970s rated their techniques using a power function. The power function of a technique is the ratio of effort required to develop a system using the technique over the effort required to develop the same system using conventional techniques. Software Reuse recognizes that large gains in the power function are achieved by reusing system artifacts. Domain Analysis recognizes that large gains in reuse are achieved by reusing as much analysis and design as possible. The Draco approach recognizes that large gains from DA are achieved by having the domains reuse each other. The power function fails to recognize the expense of putting the technique in place. |
Neighbors, James M., "Find Out What Isn't Reusable and Don't Use It", Panel: How to Solve the Reuse Problem, Neighbors, J., moderator Fifth International Conference on Software Reuse (ICSR5), Devanbu, P., and Poulin, J., editors, pp. 366-367, June 1998, Victoria, Canada, IEEE Press, 1998. PAPER or SLIDES |
Abstract: The title of this position paper might seem a foolish answer but inverting the problem makes it easier to see the reuse constraints. In the discussion that follows, "It" pertains to all of the reusable artifacts and techniques that we discuss in software reuse. 1) It isn't reusable if it doesn't compile, link, and execute as it used to. 2) It isn't reusable if you don't understand what it does. 3) It isn't reusable if it doesn't address the user's problem. 4) It isn't reusable if it can't interface to existing systems. A "Magic Bullet" reuse technology is one that meets all of the above constraints in all system development cases. Clearly, we cannot expect such a technology to exist. |
Neighbors, James M., "Finding Reusable Software Components in Large Systems", Third Working Conference on Reverse Engineering, pp. 1-9, November 1996, IEEE Press, 1996. PAPER or SLIDES |
Abstract:
The extraction of reusable software components from existing systems is an attractive idea. The
goal of the work in this paper is not to extract a component automatically, but to identify its tightly
coupled region (subsystem) for extraction by hand or knowledge-based system. Much of our
experience is anecdotal. Our experience with scientific systems differs from much of the work in
reverse engineering that focuses on COBOL systems.
Module and data interconnection was collected from three large scientific systems over a 12 year
period from 1980 to 1992. The interconnection data was analyzed in an attempt to identify
subsystems that correspond to domain-specific components. The difficulties of dealing with large
scientific systems and their organizations are discussed. The failures and successes of various
subsystem analysis methods is discussed. A simple algorithm for the identification of subsystems is
presented. A pattern of object hierarchies of subsystems is briefly mentioned.
The average subsystem is surprisingly large at 17,000 source lines and 35 modules. The concept of
a subsystem is informally validated by developers from subsystem interconnection diagrams. The
actual reusability of these identified components is not assessed. Comment: A preliminary version of this work was give as a talk at MCC in 1987. |
Neighbors, James M., "It's Not My Fault", Panel: Domain Analysis: From Tarpit Extraction to Object Mania?, Fraser, S., moderator Fourth International Conference on Software Reuse (ICSR4), Filled in for a panelist so there is no position paper in the proceedings, Orlando, Florida, April 1996. SLIDES |
Excerpt: Concepts I did not advocate: complex domain analysis methodologies, object-oriented domain analysis, and domain analysis focussed on objects. Concepts I did advocate: focus on user problem domain rather than implementing KB technologies, reuse analysis and design not code, use domain languages over libraries for reuse, refine to other domains, and optimize within the domain. Integrate collections of objects, frameworks/architectures, and domain-specific languages into domain hierarchies. |
Neighbors, James M., "The Benefits of Generators for Reuse", Panel: On the Future of Generators, Baxter, I., moderator Fourth International Conference on Software Reuse (ICSR4), Sitaraman, M., editor pp. 217, April 1996, Orlando, Florida, IEEE Press, 1996. PAPER or SLIDES |
Excerpt: Generators aid system description using domain concepts; avoid code corrosion; allow for implementation variation; allow implementation goal variation; and provide optimization above the code level. |
Neighbors, James M., Keynote Address: "An Assessment of Reuse Technology after Ten Years", Third International Conference on Software Reuse (ICSR3), Frakes, W., editor pp. 6-13, November 1994, Rio de Janeiro, IEEE Press, 1994. PAPER or SLIDES |
Abstract: More than ten years ago the first major workshop on "Reusability in Programming" was held. Since that time some technologies have advanced and come into successful commercial use while others have gone unused. New management and abstraction techniques have aided reuse. Interfacing to huge abstractions, now in common use, has made reuse more difficult. This paper is not a formal survey of reuse technology but instead discusses the evolution of early concepts and the issues they raise. Much of the research of the original workshop participants is just now becoming relevant. In some cases the research of the past points to problems and solutions for the present. As part of this examination the activities in reuse for the next ten years will be forecast and a guide of hard questions to ask purveyors of reuse technology will be provided. |
Neighbors, James M., "Reuse so Far: Phasing in a Revolution", Panel: Reuse Results so Far, Biggerstaff, T., moderator Third International Conference on Software Reuse (ICSR3), Frakes, W., editor pp. 191-192, November 1994, Rio de Janeiro, IEEE Press, 1994. PAPER or SLIDES |
Abstract: This paper presents a lifecycle model that corresponds to a factor of ten improvement in software development productivity. It is argued that this level of productivity may be met today without aiding the general software crisis. Success and failure in software is not just a matter of improving software development productivity. Software flexibility for a changing world must also be maintained. |
Neighbors, James M., "The Commercial Application of Domain Analysis", 5th Annual Workshop on Software Reuse (WISR92), Palo Alto, California, October 26-29, 1992. PAPER, PAPER(ASCII), or SLIDES |
Abstract:
My interest and experience with reusable software components and automatic
programming led me to the concept of domain analysis as a basis for reuse.
The key domain analysis idea is the reuse of concepts not just program
code. This approach was embodied in an experimental system called Draco
which has been well documented and will not be further discussed here.
My current interest in reuse follows along the same lines. Use domain
analysis but from a different psychological set. All
of my previous work really emphasized the tool, deemphasized the domains,
and completely ignored the users. My current interest is how to deliver
the power of a problem-specific domain to a user without making the user
into problem domain expert, tool expert, or modeling domain expert. Comment:Provides the reasons for founding Bayfront Technologies, Inc. |
Neighbors, James M., "The Evolution from Software Components to Domain Analysis", International Journal of Software Engineering and Knowledge Engineering, Vol. 2, No. 3, pp. 325-354, October 1992.
|
Abstract:
More than twenty years ago the idea of producing software systems from
reusable software components was proposed. Since that time many changes
have taken place in Computer Science and Software Engineering, but
software systems are still built as one-of-a-kind craftsman efforts. A
method for software construction using components is derived using
experience from software components, program transformations, system
architecture, industrial large systems, automatic programming and program
generation. Experience with the method is discussed. The limiting factors
of the method that prevent the widespread use of reusable software
components are identified. Comment:The paper provides the best rationalization for the Draco approach to constructing software from reusable software components. |
Neighbors, James M., Chapter 12: "Draco: A Method for Engineering Reusable Software Systems", in Software Reusability, Volume I: Concepts and Models, Ted Biggerstaff and Alan Perlis, Editors, ACM Frontier Series, Addison-Wesley, 1989.
|
Comment:The paper provides the best overall view of the mechanics of the Draco approach to constructing software from reusable software components. The approach, domain descriptions, inter-domain structures, transformation/refinement management, and experience are discussed. These are a bit different from earlier reports. Problems with other approaches such as wide-spectrum languages and component libraries are presented. The individual constituent parts of a domain (parsers, prettyprinters, optimizations, components, generators, and analyzers) are rationalized and discussed. |
Neighbors, James M. "Reverse Engineering and Reusing Software", excerpts from unfunded 1989 SBIR research proposal, System Analysis, Design, and Assessment (SADA), 1989. PAPER |
Abstract: Software Reuse is a key technique for achieving significant increases in programmer productivity. However, the reuse of software will only succeed if the engineering decisions made during the construction of the software are understood. Reverse Software Engineering (RSE) creates such an understanding. This project will develop a knowledge representation capable of describing systems from different algorithmic languages (e.g., Ada, CMS, Pascal). The initial phase of the project will focus on extracting system architecture ("How") descriptions of working systems from their source code and supporting documentation. Later phases will integrate system requirement ("What") and system performance models ("How many") into the representation. It will be shown that many of the workproducts of the forward software engineering life cycle may be constructed from the representation. The problems of system validation, program translation, maintenance programming, systems programming and parallel computation of existing system function will be formulated as problems across the system requirement, architecture, and performance representation. |
Neighbors, James M., moderator "Report on the Domain Analysis Working Group Session", unpublished report from 1988 Workshop on Software Reuse, Rocky Mountain Institute for Software Engineering (RMISE), Boulder, Colorado, 1988. PAPER |
Comment: Until this point I'd been almost entirely focussed on practice and mechanism (e.g., "How do I get domains and how do I get a domain-specific language specification refined to executable code?"). This stems from my belief that no one should pay any attention to a software development technique that cannot create operating software. The Domain Analysis Working Group at this workshop considered DA methodologies, domain rationalization and education. |
Neighbors, James M. The Structure of Large Systems or "What are all those people I'm paying too much doing anyway?", unpublished talk given at MCC, Microelectronics and Computer Technology Corporation, August 1987. SLIDES |
Comment: Late in the 1970's I had come to the conclusion that the assembly of large system structures seemed significantly different from the assembly small program structures. Draco 1.0 had a very weak sense of these system structures. We examined module interconnection languages in this connection. I also embarked on a journey of examining real, large systems in the commercial world. This informal presentation presents my preliminary results and speculations. At this time my source code tools were not capable of examining C code so these results only include the FORTRAN and Pascal code of these large systems. I still find the system growth patterns and exponential subsystem embedding correlation interesting and unexplained. The final result of these large system examinations was published in the Third Working Conference on Reverse Engineering in 1996. |
Prieto-Diaz, Ruben, and Neighbors, James M., "Module Interconnection Languages", The Journal of Systems and Software, No. 6, pp. 307-334, Elsevier Science Publishing Co., Inc., 1986.
DRAFT or SUMMARY for Ada newsletter Comment: Final version is copyright Elsevier and is available from them. This is a copy of a 1983 draft with comments from a referee. The paper was also published as UCI-ICS-TR-189. |
Abstract:
Module Interconnection Languages are considered essential
tools in the development of large software systems.
Current software development practice follows the principle
of the recursive decomposition of larger problems
that can be grasped, understood, and handled by specialized
and usually independent teams of software engineers.
After teams succeed in designing and coding their
respective subsystems, they are faced with different but
usually more difficult issues; how to integrate independently
developed subsystems or modules into the originally planned complete system.
Module Interconnection Languages (MILs) provide formal grammar constructs for
describing the global structure of a software system and
for deciding the various module interconnection specifications
required for its complete assembly. Automatic
processing of these formal descriptions results in a verification
of system integrity and intermodule compatibility.
This paper is a survey of MILs that are specifically designed
to support module interconnection and includes
brief descriptions of some software development systems
that support module interconnection. Comment: MILs are a domain-specific language up the structural abstraction hierarchy rather than the functional problem domain abstraction hierarchy. We submitted the initial version of this paper in August of 1982. It was sent for review to language designers who in the era of Ada fever were not anxious to bless the concept that some descriptive form above the low level of general purpose language might be required to define large systems. There were many revisions. Ultimately JSS published the paper four years later on first submission without revision. MILs are now regarded as the initial work on system architectures. |
Neighbors, James M., "The Draco Approach to Constructing Software from Reusable Components", IEEE Transactions on Software Engineering, Vol SE-10, No. 5, pp. 564-574, Sept 1984.
|
Abstract: This paper discusses a approach called Draco to the construction of software systems from reusable software parts. In particular we are concerned with the reuse of analysis and design information in addition to programming language code. The goal of the work on Draco has been to increase the productivity of software specialists in the construction of similar systems. The particular approach we have taken is to organize reusable software components by problem area or domain. Statements of programs in these specialized domains are then optimized by source-to-source program transformations and refined into other domains. The problems of maintaining the representational consistency of the developing program and producing efficient, practical programs are discussed. Some examples from a prototype system are also given. |
Neighbors, James M., "The Draco Approach to Constructing Software from Reusable Components", Proceedings 1983 Workshop on Reusability in Programming, pp. 167-178, ITT Programming, September 1983. PAPER |
Abstract:
This paper discusses a mechanism called Draco which aids in the
construction of software systems. In particular we are concerned
with the reuse of analysis and design information in addition to
programming language code. The goal of the work on Draco has been to increase the productivity of software specialists in the construction of similar systems. The particular approach we have taken is to investigate the construction of software from reusable software components which are organized by problem domain. The experimental method used was to hypothesize a scheme based on previous work and experiment with example problems on a prototype system. Comment: This paper was shortened and revised for the TSE article above. Sigmund Sundfor's Tactical Display Domain example was left out of the proceedings by mistake and handed out at the workshop. It is included in the PDF here. |
Neighbors, James M., "Libraries vs. Languages in the Reusability of Programming", unpublished position paper submitted to the 1983 Workshop on Reusability in Programming, 1983. PAPER |
Excerpt: When we talk about the reuse of existing programs we must be careful in describing the goals of the reuse. In some cases a programmer on a project is looking for a program part which can just be "plugged in" without modification. In other cases the programmer is looking for a program part which can be modified before use. This is an important distinction for someone contemplating the construction of a library of reusable program parts. In the first instance only what the program part does need be stored while in the second instance both what the part does and how it does it need be stored. The reuse of program parts without modification has been terribly successful in the past and has been invisible to the programmers requesting the reuse. The reuse of program parts with modification with the aid of a machine has not been investigated very much as such. In the author's opinion significant increases in "programmer" productivity will only come from the reuse of program parts with the aid of a machine. We believe that a major part of the solution to the "software crisis" will be the reuse of software. Further, we believe that in the long term the key to the reuse of software is to reuse analysis and design; not code. |
Sundfor, Sigmund, Draco Domain Analysis for a Real Time Application: The Analysis, Reuse Project Technical Report RTP 015, Department of Information and Computer Science, University of California, Irvine, June 1983. REPORT (102 pages) |
Abstract:
This report analyzes the domain of ship borne gun control systems as a focus for defining the more
general domains found in real-time embedded systems.
The analysis was done by a domain expert attempting to
define his domain using the Draco approach. This is an experiment to see if such complex domains can
be defined using the approach. Comment: Sigmund Sundfor is a great guy who visited our research group from A/S Kongsberg Vapenfabrikk and the Royal Norwegian Council for Scientific and Industrial Research. He managed to do a domain definition on a creaky prototype tool largely by himself. His analysis shows how we did Domain Analysis then and how we continue to do it today. This analysis could be picked up today to build new ship systems, simulations, or games. This is the point of reusing analysis and design. |
Sundfor, Sigmund, Draco Domain Analysis for a Real Time Application: Discussion of the Results, Reuse Project Technical Report RTP 016, Department of Information and Computer Science, University of California, Irvine, June 1983. REPORT (36 pages) |
Abstract: This report discusses the successes and failures of using the Draco approach in the analysis of ship borne gun systems and embedded real-time systems in general. It is written from the point of view of a domain expert attempting to determine if the approach is practical for real world problems. |
Neighbors, James M., Draco 1.2 User Manual, Technical Report UCI-ICS-TR-230 (version 1.3), Department of Information and Computer Science, University of California, Irvine, 1983. HTML or PDF |
Abstract: This manual describes the operation of the Draco 1.2 system as it existed on the DEC20 in the Department of Information and Computer Science at the University of California, Irvine in 1983. The system addresses the problem of developing systems out of reusable program components. The details of the theory are discussed in Neighbors' 1980 UCI dissertation Software Construction Using Components. The details of implementing the theory are discussed in this manual. Transcripts of operating the system are provided to give the reader the feel of using the system. |
Neighbors, James M., Software Construction using Components, Ph.D. Dissertation, Technical Report UCI-ICS-TR-160, Department of Information and Computer Science, University of California, Irvine, 1980. HTML or PDF |
Abstract: It is the thesis of this work that many computer software systems being
built today are similar and should be built out of reusable software
components.
The appropriate use of software components is investigated by analogy to the classical engineering question of whether to build an object out of custom-made parts or standard parts and assemblies. The same analogy is used to explain some of the problems with previous work on reusable software. The result of reasoning with the engineering analogy is that the reuse of software results only from the reuse of analysis, design, and code; rather than just the reuse of code. The concept of domain analysis is introduced to describe the activity of identifying the objects and operations of a class of similar systems in a particular problem domain. A domain analysis is represented by a domain-specific language, a prettyprinter, source-to-source transformations, and software components. A domain's software components map statements from the domain into other domains which are used to model the objects and operations of the domain. Software components represent implementation choices. The components are managed using a module interconnection language to insure usage constraints. The source-to-source transformations represent domain-specific optimizations, independent of any implementation, which are used to optimize statements in the domain. The transformations are useful primarily when the domain is used as a modeling domain. A method of automatically producing metarules for a set of transformations is described. The metarules remove the burden of having to suggest individual transformations from the user. A formal model of the usage constraints and modeling possibilities of a set of domains is presented. It is shown that the reusability question ("Can a particular domain-specific program be refined into an executable language using a given a set of domains?") can be answered using the formal model. Experiments using a prototype system, Draco 1.0, which embodies the concepts described, are presented and the results discussed. The largest example results in approximately 20 pages of source code and uses eight modeling domains. Each object and operation in the resulting program may be explained by the system in terms of the program specification. Related work in the areas of automatic programming, program generation, programming languages, software engineering, and transformation systems is presented. Finally, some future work in this area is outlined. |
Kibler, Dennis F., Standish, T. and Neighbors, James M., "Program Manipulation via an Efficient Production System", Proceeding of Conference on Pattern Directed Inference Systems, SIGPLAN Notices 12(8):163-173, August 1977. PAPER |
Excerpt: The work reported here deals with the development of a transformation system based on a production system. To keep the system within a manageable size, we have not incorporated the techniques of global flow analysis and algebraic simplification although they would fit into the framework of a production based program manipulation system. The first section discusses the use of production systems and the second section shows how an interactive program manipulation system was implemented using a production system. The first appendix is an example worked out in detail, the second appendix contains a sample of the transformations in the system, and the third appendix contains example outputs from the system. |
Standish, T., Harriman, D., Kibler, Dennis F., and Neighbors, James M., "Improving and Refining Programs by Program Manipulation", Proceedings of the ACM National Conference, pp 509-516, ACM, 1976. PAPER |
Abstract: By manipulating programs to reorganize the way they compute their results, it is possible to improve program performance in certain desirable directions. Further, using certain laws of exchange, it is possible to transform concise, abstract, high-level programs into efficient, concrete, underlying representations. This paper explores the notion of using source-to-source transformations interactively as a basis for an approach to program improvement and refinement. Examples of program manipulation are presented that convey both the flavor of the approach and it requirements. |
Standish, T., Harriman, D., Kibler, Dennis F., and Neighbors, James M., The Irvine Program Transformation Catalogue, Technical Report UCI-ICS-TR-161 Department of Information and Computer Science, University of California, Irvine, January 1976. CATALOG Comment: This is my marked up copy of version 0.1 which was the last version to my knowledge. |
Excerpt:
The Irvine Program Transformation Catalogue
is basically a source book of ideas for improving programs.
By casual browsing, the reader may discover a number of
useful techniques for transforming programs into better ones.
When the moment comes to apply a particular technique, the
Catalogue can be referenced for details. Comment: After defining these programs transformations and working with Kibler on a system which implemented them I determined that we were working at the wrong level of abstraction in most instances. In general programming language programs the problem domain information is mostly gone. The structural information about how the system is built and flows is also mostly gone. Truly powerful optimizations always require domain knowledge - whether it is problem or implementation knowledge. |