[Draco] [Bayfront Technologies] [Technology]

Software Reuse, Domain Analysis and Draco Information

The Draco approach to constructing similar systems from reusable software components is one of the core techniques Bayfront Technologies uses to construct products. The approach was developed in the late 1970s. These documents present the approach as it originally appeared and how it has evolved over the years. There is ongoing scientific discussion of the techniques as they continue to evolve.

Questions Answered in these Papers

Isn't using problem domain-specific languages resulting from domain analysis a new unproven technique?
Common versions of these languages such as SQL, OpenGL, HTML, XML, and OS shell scripting languages are in use every day. In fact it's a very old idea as we discuss in Tutorial: Metacompilers Part 1 where an implementation independent domain-specific language for implementing compilers is described and evolved.

Why can't I just use a library of executable language (e.g., C, Java, or Ada) software components?
While a library is a good first step it quickly runs into the limitations described in Libraries vs. Languages in the Reusability of Programming.

The Draco Approach advocates domains over libraries. What exactly is a domain?
The definition of a domain has become more general over the years. Domain Analysis and Generative Implementation presents the most recent and brief description. Draco: A Method for Engineering Reusable Software Systems provides a more detailed description.

Where did this whole "Draco Approach" with domain analysis, domain languages, optimizations and refinements come from?
The best rationalization of the approach is presented in The Evolution from Software Components to Domain Analysis.

How do you do domain analysis?
Sigmund Sundfor, a domain expert, visited our research group and did an analysis and discussed the results using the style of analysis we still prefer.

Won't systems refined using these high-level, general domains be terribly inefficient?
On the contrary we find the resulting systems to be at least as efficient as hand-built systems. Optimizers can only optimize concepts they understand. In Program Manipulation via an Efficient Production System we studied compiler-like optimizations using source-to-source program transformations. Far too many low-level transformations were required to achieve goals that at a domain with a higher level of abstraction were easy to achieve with very few transformations. Transforming Experiences provides a simple illustration of this effect. Further, Software Construction using Components shows that variation in implementation architecture can also achieve time and/or space efficiencies.

What am I losing by exclusively using executable language (e.g., C, Java, or Ada) software components?
A software development approach isn't even worth considering until it has shown it can actually create non-trivial programs. That having been said, much more than just executable language code should be expected from a realistic software development approach. The Benefits of Generators for Reuse briefly discusses how education, documentation, simulation, significant optimization, architecture variation, and avoidance of code corrosion are all achieved by not exclusively using low-level executable code components.

What system architecture guidelines should a software component assembly mechanism be concerned with?
Finding Reusable Software Components in Large Systems discusses the structures above programming language used to create large systems. These subsystem structures will need to be interfaced with and synthesized. Software Construction using Components discusses the details of knitting together architectures during refinement.

Paper Titles by Date

2008Tutorial: Metacompilers Part 1
2002Where Does Reusable Generative Knowledge Come From?
2002Techniques for Generating Communicating Systems
1999Transforming Experiences
1998Panel on Domain Analysis and Implementation: Domain Analysis and Generative Implementation
1998Panel on How to Solve the Reuse Problem: Find Out What Isn't Reusable and Don't Use It
1996Finding Reusable Software Components in Large Systems
1996Panel on Domain Analysis: It's Not My Fault
1996Panel on the Future of Generators: The Benefits of Generators for Reuse
1994An Assessment of Reuse Technology after Ten Years
1994Panel on Reuse so Far: Phasing in a Revolution
1992The Commercial Application of Domain Analysis
1992The Evolution from Software Components to Domain Analysis
1989Draco: A Method for Engineering Reusable Software Systems
1988Reverse Engineering and Reusing Software
1988Report on the Domain Analysis Working Group Session
1987The Structure of Large Systems or "What are all those people I'm paying too much doing anyway?"
1986Module Interconnection Languages
1984The Draco Approach to Constructing Software from Reusable Components
1983The Draco Approach to Constructing Software from Reusable Components (long workshop version)
1983Libraries vs. Languages in the Reusability of Programming
1983Draco Domain Analysis for a Real Time Application: The Analysis
1983Draco Domain Analysis for a Real Time Application: Discussion of the Results
1983Draco 1.2 User Manual
1980Software Construction using Components
1977Program Manipulation via an Efficient Production System
1976Improving and Refining Programs by Program Manipulation
1976The Irvine Program Transformation Catalog

Paper Contents, Presentations, Abstracts, Excerpts, and Comments by Date

Neighbors, James M.,
"Tutorial: Metacompilers Part 1",
August 20, 2008.

Tutorial HTML Metacompiler Workshop HTML
pdficon 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.

pdficon 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.

pdficon PAPER or pdficon 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.

pdficon PAPER or pdficon 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.

pdficon PAPER or pdficon 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.

pdficon PAPER or pdficon 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.

pdficon PAPER or pdficon 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.

pdficon 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.

pdficon PAPER or pdficon 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.

pdficon PAPER or pdficon 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.

pdficon PAPER or pdficon 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.

pdficon PAPER, PAPER(ASCII), or pdficon 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.
Preprinted Keynote Address:V Simposio Brasileiro de Engenharia de Software,
Sociedade Brasileira de Computacao,
Imprensa Universitaria, Universidade Federal de Minas Gerais, Brazil 1992.
pdficon PAPER or pdficon SLIDES
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.
ReprintedDomain Analysis: A Tutorial,
Guillermo Arango and Ruben Prieto-Diaz, Editors,
IEEE Tutorial Series, IEEE Press, 1991.
pdficon PAPER
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.

pdficon 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.

pdficon 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.

pdficon 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.
ReprintedSoftware Reusability,
Peter Freeman, Editor,
IEEE Tutorial Series, IEEE Press, 1987.

pdficon DRAFT or pdficon 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.
ReprintedProgramming Productivity: Issues for the Eighties 2/e,
Capers Jones, Editor,
IEEE Tutorial Series, IEEE Press, 1986.
ReprintedArtificial Intelligence and Software Engineering,
Charles Rich and Richard Waters, Editors,
Morgan Kaufmann Publishers, 1986.
ReprintedSoftware Design Techniques 4/e,
Peter Freeman, Editor,
IEEE Tutorial Series, IEEE Press, 1989.

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.

pdficon 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.

pdficon 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.

pdficon 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.

pdficon 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 pdficon 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 pdficon 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.

pdficon 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.

pdficon 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.

pdficon 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.
[index] Back to index page

Valid HTML 4.01 Transitional
copyright © 2008 Bayfront Technologies, Inc.