Transformation Systems:
Domain-Oriented Component and Implementation Knowledge Reuse

Ira D. Baxter

Software reuse is intended to = lower the cost of obtaining some software engineering artifact due to = the high cost of constructing such artifacts. Methods for performing = software reuse are themselves often composed of a mixture of manual = procedures and software, e.g., some informal approach for acquiring a = domain analysis, and a tool for encoding the domain knowledge, and a = tool for generating an application from the encoded knowledge. Since = constructing a reuse method is itself expensive, we clearly want to = reuse as many of the methodological aspects and artifacts as we can. = (Reuse conferences are an attempt to make knowledge of such approaches = reusable). Which reuse technologies are the most reusable?

We see the reuse problem as one = of finding a coherent set of solutions to the following set of = problems:

1. Discovering a vocabulary for referring to problem concepts and a = means of stating some abstract problem to be solved
   ("domain analysis")
2. Defining a problem specification language
3. Acquiring methods for solving problems stated in the specification = language
4. Encoding the problem solving methods in a tool (or process)
   ("domain engineering")
5. Acquiring a problem specification instance
6. Matching the specification instance with a subset of solving = methods
7. Choosing and applying a particular solver method

A serious unsolved problem with reuse is the maintenance = problem. If the original problem specification changes, how are = those changes reflected into the system integrating the = reusably-derived part?

1. Provide a vehicle (see 2-7) for experimenting with domain = definitions
2. Allow the formal definition of a problem specification language of = arbitrary sophistication, from keyword lists to constraint = equations
3. Provide a vehicle for testing proposed solutions (see 4-7).
4. Enable the coding of a set of transformations to map specifications = to (possibly many) programs that implement those specifications.
5. Check syntax, semantics, consistency and possibly aid software = engineer in validating specification
6. Transformations choose portions of specifications to which they = apply
7. Execution of transformations carries out the generation of a = desired artifact

As with most reuse schemes, an up front investment must be made = before there is any payoff. In the case of transformation systems, one = must first acquire a useful transformational platform even before = beginning to perform any domain engineering or analysis. Fortunately, = transformation systems are a problem domain themselves, and so one can = use reuse methods, especially transformational ones, to aid in = bootstrapping. A theory detail but a requirement for serious software = engineering is operation on practical scale; software systems are = growing in size as microprocessors continue to grow in support = application needs.

Our position is that library approaches to reuse will never scale = nor integrate well, and that fixed-framework methods (those that = compose components at runtime, such as object oriented and/or = architecture-methods) are too rigid to be effective in the long run. = The ability to compose code and retrace that composition will be a = necessity. Transformation systems will be the eventual reuse = technology of choice.

Building DMS is a complex = project. We are (re)using DMS to aid its own construction. The = PARLANSE parser is implemented in DMS, and a completed PARLANSE domain = coupled with a generic parallelism domain will eventually allow us to = use DMS as its own PARLANSE compiler. The DMS parser is used to = implement SPECTRUM, which defines (some) preconditions on transforms. = The rewrite engine is used to apply transforms and used to simplify the = transform preconditions. The lexer generator and the attribute = evaluator are both implemented as domains.

To date, DMS has been used mostly to aid its own = construction. It has been applied experimentally to large-scale = boolean equation simplification for automated generation of causal = model diagnostics. In a test of its flexibility, it has been used to = analyze another generator's synthesis specifications for errors, mostly = by looking for context errors. An application of the DMS infrastructure = to locate clones in legacy codes surprisingly showed that clone = detection may be an interesting tool for domain engineering = [BaxterEtAl98].

While we are designing DMS from a reuse = perspective, and expect to use DMS for domain-specific application = synthesis, our main motivation for DMS is the reuse of the domain = engineering knowledge to aid software maintenance by abstracting and = re-implementing [BaxMeh97]. The reverse and re-engineering communities = have not yet really discovered the conceptual power that a forward = synthesis engine offers the reverse engineer. We expect to try scale = reengineering tasks with DMS in 1999.

We contend that many workers in = reuse are moving in the direction of transformational generators.

The basic DMS perspective on domain and transforms is obviously = inspired by the Draco approach [Neighbors84], but DMS differs in = attempting to generalize the model of domains to arbitrary = specifications, both tree and graphical, to bring more semantics to = bear, and attempting to scale. The notion of transformational control = came from work on transformational developments [Wile83]. Reusing = transformational derivations by simply replay was originally suggested = by Gold [Gold90], but there was not method for recovering from = transformation steps that do not apply in new circumstances. We = suggest how to do that in [Baxter92], and part of the purpose of DMS is = to provide a platform in which to test out that theory. The = computational foundation of DMS is induced by paranoia caused by 48 = hour synthesis cycles generating 5000 lines programs from a previous = research project of of this author.

The infrastructure is similar to the technology underlying Lucent's = FAST application generation process [Weiss98] applied to telecom = switching commands. DMS could be used to replicate that work by = defining a telecom command domain as input, using a C domain as output, = and encoding the translation as XCL metaprograms.

Batory's Genvoca models always used a "type expression" to control = the generated program. Our perspective has always been that these = type expressions were a peculiar kind of transformational metaprogram. = It is interesting that Batory is moving directly to transformational = infrastructure (abstract syntax trees and gluing operations on them) = [Batory98] for his generators.

The patterns community [Gamma94] suggest that knowledge about = program aspects (pipes, persistance, =85) may be added to existing = object oriented programs by codifying the aspect as an expected = behavioral aspect and an informal method for integrating code to carry = out that behavior into an application. This seems like a pragmatic = approach for practicing software engineers with few tools, at the price = of high learning curves and the error rate of manual methods. We feel = that formalizing these patterns as transformation rules will make them = more precise, more accurate and enable them to be deployed much more = quickly. Our intuition is that these ideas should be captured at a = high level of abstraction than frameworks.

Dr. Baxter has been involved with computing since 1966, and = implemented one of the first minicomputer timesharing systems on a Data = General Nova in 1970. He received his B.S. in Computer Science (1973), = and worked for a number of years in industry both as a consultant and = as owner of Software Dynamics, a systems software house, where he = designed compilers, time-sharing and network operating systems. In = 1990, he received a Ph.D. in Computer Science from the University of = California at Irvine, where he studied Software Engineering, focusing = on design reuse using transformational methods. Dr. Baxter spent = several years with Schlumberger, working on a PDE-solver generator for = supercomputers (Sinapse). In 1994, he founded Semantic Designs, to = build commercial tools that intended to radically enhance the method = and economics of software maintenance. Through Semantic Designs, he = provides consulting to Fortune 100 companies on domain-specific = software transformation and synthesis methods. Dr. Baxter is the = principal architect of Semantic Designs' Design Maintenance System = (DMS), and is also the principal designer and compiler implementer of = PARLANSE, Semantic Designs' parallel programming language.

Dr. Baxter has served as committee member for numerous = computer-science conferences, especially those focused on software = engineering and reusability. Recently, he was Program CoChair of the = 1997 Working Conference on Reverse Engineering (WCRE4) (October, 1997), = and was General CoChair for the Fifth International Conference on = Software Reusability (ICSR5) (June, 1998). Dr. Baxter is presently on = the Program Committee for the Intenational Conference on Software = Maintenance (ICSM'99) (August, 1999) and the 5th IEEE Working = Conference on Reverse Engineering (WCRE5) (October, 1998). He is chair = of the Software Transformations Systems workshop at ICSE99 (May, = 1999).