Transformation Systems:

Domain-Oriented Component and Implementation Knowledge

Reuse

Ira D. Baxter

Semantic Designs, Inc.

12636 Research Blvd, #C214

Tel: (512) 250-1018, fax: (512)250-1191

Email: idbaxter@semdesigns.com

URL: http://www.semdesigns.com

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?

Transformation systems [Agresti86] [Partsch90] are systems that apply rules to modify syntactic structures. Because this is the basis of mathematics, they offer a particularly reusable technology to solve reuse problems. Transformation systems solve the problems above in the following ways:

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. Check syntax, semantics, consistency and possibly aid software engineer in validating specification
5. Transformations choose portions of specifications to which they apply
6. 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.

The maintenance problem may be solved by reuse of design histories the series of transformation steps taken [Wile83] and their justification [Baxter92].

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.

Semantic Designs is building a sophisticated transformation system called the "Design Maintenance System". There are two challenges to implementing a DMS-like vision. First one must have sufficient integrated infrastructure to carry out the steps. Second, it must scale reasonably well.

Required infrastructure includes the following:

• Methods for defining notations. DMS has lexer/parser generator system that automatically generates a backtracking parser (that produces ASTs ) and pretty-printers from a grammar definition . A structure editor for graphical languages is planned, driven from graph grammars. These are used for defining both the input specification language, and the language to be produced for a constructed product.
• Built-in notations for common structures in software engineering. DMS offers an algebraic specification notation [SPECTRUM] for defining the basic computations of discrete mathematics and/or abstract data types. This gives a domain engineer a means for explaining the semantics of his domain concepts.
• A means for representing specifications/programs. A hyper-graph substrate is used to encode language-specific graph representations. This allows tree and graph languages to be encoded on the same foundation. Means for analyzing programs and spreading information. The value of a specification is its conciseness, often by stating information just once. Code generation requires that information in one part of a specification code induced by another part. DMS offers attribute grammar-driven analyzers to move information around ASTs.
• Tree/graph rewrite engine to apply individual transformations to the program representation enhanced with the ability to record, view and revise design histories. The tree rewriting engine doubles as an algebraic simplifier, driven by SPECTRUM specifications. (Such rewriting could be used to compute inferences from a specification, which can in turn help a domain engineer validate his specification.)
• Means for specifying translation from specifications to target code. One must define individual transforms, and methods for composing series of transforms to carry out complex translations. DMS will have a metaprogramming language, XCL, which treats transforms as primitive actions, and can sequence transformations based on performance measures defined in SPECTRUM (space, computational complexity, etc.)

Such tools will not have long term impact if they cannot operate on the scale of large software engineering projects. To support scale, DMS provides:

• Knowledge Representation Scale. Many synthesis systems are limited to one input specification language and one target output language. DMS is being designed around an extended notion of Draco domains [Neighbors84]. Each domain defines an external syntax, and internal graph, optional/partial semantics, performance measures and, source-to-source transforms, refinement to other domains, and metaprograms composing transforms and refinements to carry out performance-achieving objectives. We eventually expect to have domains for standard computer science areas, such as databases, graphics, communications, parallel computation, as well as generic application arenas, such as navigation, accounting, Modularizing the knowledge used in the generation task will allow the domains to be reused for other applications, spreading the cost of domain engineering across many applications. This will be a key driver in the success of transformation systems as the ultimate reuse engines.
• Representational Scale. Previous experience with a partial differential equation solver generator showed that generation 5,000 line programs could consume over 100Mb RAM; careful design for scale is needed. We are designing to handle over a million lines in a single AD 2000 workstation having 1Gb RAM.
• Computational scale. Microprocessors are poor at symbolic programming, and realistic programs are hundreds of thousands of lines or larger. DMS is implemented in a parallel programming language, PARLANSE, running on commodity SMP platforms. As an example, the attribute evaluators are compiled to partial-order parallel programs.
• Support for widely used programming languages. It presently has full parsers for ANSI C, C++, COBOL (as well as PARLANSE).

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 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,) 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.

[Agresti86] William W. Agresti, What are the New Paradigms?, New Paradigms for Software Development, William W. Agresti, IEEE Press, 1986, ISBN 0-8186-0707-6.

[Batory98] D. Batory, B. Lofaso, and Y. Smaragdakis, JTS: Tools for Implementating Domain Specific Languages, Fifth International Conference on Software Reuse, IEEE, 1998.

[Baxter92] I. Baxter. 1992. Design Maintenance Systems, Communications of the ACM 35(4), April, 1992, Association for Computing Machinery, New York. (Not available online).

[BaxterEtAl98] I. Baxter, A. Yahin, A., L. Moura, M. Sant'anna, L. Bier. Clone Detection Using Abstract Syntax Trees -Proceedings of International Conference on Software Maintenance '98, 1998, IEEE Press.

[BaxMeh97] I. Baxter and M. Mehlich. Reverse Engineering is Reverse Forward Engineering. 4th Working Conference on Reverse Engineering, 1997, IEEE

[BaxPidg97] I. Baxter and C. Pidgeon. Software Change Through Design Maintenance. Proceedings of International Conference on Software Maintenance 97, 1997, IEEE Press.

[Gamma94] E. Gamma, R. Helm, R Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Systems, Addison-Wesley, 1994.

[Gold90] A. Goldberg. Reusing Software Developments. ACM SIGSOFT Symposium on Software Development Environments. Kestrel Institute Technical Report KES.U.90.2, 1990.

[MehBax97] Mehlich, M. and I. Baxter. Mechanical Tool Support for High Integrity Software

Development. Proceedings of Conference on High Integrity Systems 97, 1997, IEEE Press.

[Neighbors84] J. Neighbors. The Draco Approach to Constructing Software from Components. IEEE

Transactions on Software Engineering 10(5):564-574, 1984.

[Partsch90] Helmut A. Partsch, Specification and Transformation of Programs. Springer-Verlag, 1990, ISBN 3-540-52589-0.

[SPECTRUM] M. Broy, C. Facchi, R. Grosu, R. Hettler, H. Hußmann, D. Nazareth, F. Regensburger, O. Slotosch, and K. Stølen. The Requirements and Design Specification Language Spectrum: An Informal Introduction, Version 1.0. Technical Reports TUM-I-9311 and TUM-I9312, Technische Universität München, 1993.

[Weiss98] D. Cuka and D. Weiss. Engineering Domains: Executable Commands as an Example. Fifth

International Conference on Software Reuse, IEEE, 1998.

[Wile83] D. Wile, Program Developments: Formal Explanations of Implementations, CACM 26(11), Nov. 1983.

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