language parallax

Here’s the poster session extended abstract that I’ll be showing at OOPSLA ‘07. Here’s the abstract and first section with a link to the full pdf below:

ABSTRACT

Web applications exemplify the need for generative programming techniques in part due to the many languages, artifacts, and groups of developers involved. Some problems remain, including those that that arise from the interplay with versioning. This paper proposes addressing these problems with structured program transformations, and explores a framework for the co-evolution of platform artifacts and the models that generate them.

1. INTRODUCTION

Web application platforms are plagued by scaffolding – artifacts in many different languages which must be synchronized. During application evolution, these scattered dependencies provide abundant opportunities for amplifying human error. The simplest example of such a dependency is the name of JSP files, which are referenced in numerous XML descriptor files, in addition to the filesystem’s reference. Figure 1 illustrates the variety of artifacts and their shared references.

A common method of dealing with the problems posed by scaffolding is generating source code from domain specific languages (DSLs) designed to succinctly model the behavior of the system. One variant of code generation from a DSL is known as model-driven software development (MDSD). For a given instance of the DSL, D, and a set of platform artifacts P1 . . . PN, the generation of artifacts from D can be thought of as a function called “project”:

P1 … PN= project(D)

This solves many of the problems posed by scaffolding, but it leaves others.

2. RESEARCH PROBLEM

2.1 Model-Driven Co-Evolution

The use of structured refactoring has been shown by MolhadoRef to aid program merging, history preservation, and understanding of evolution. Languages for defining refactorings in other languages such as JunGL are a promising way to implement efficient, correct program transformations. They demonstrate the usefulness of authoring refactorings and other common evolutionary steps as endogenous (within the same language) transformations apart from any particular usage. The same issues arise when refactoring the DSL.

Platform artifacts which are always generated from the DSL will escape these problems. In general, however, some of the platform artifacts will contain non-derived information. In those cases, structured transformations offer the same benefits that they do to any versioned artifact.

For a well-defined endogenous transformation, t, in the DSL, the normal workflow after creating the initial P1 … PN is:

D’ = t(D)

P’1 … P’N = project(D’)

To address the need for structured transformations, a function evolve computes a set of transformations for the platform artifacts such that evolve(t, D) applied to the platform artifacts is the same as project(t(D)).

D’ = t(D)

t1 … tN = evolve(t, D)

P’i = ti(Pi) forall ti

2.2 Platform-Driven Co-Evolution

Another difficulty of MDSD is support for editing artifacts downstream from the DSL. Object/Relational Mapping (ORM) tools such as Hibernate demonstrate the importance of propagating changes from either side of the map. Complex debugging and optimizations of database performance, for instance, are sometimes best understood and solved within the relational database paradigm. The least error-prone way of including the resulting changes into the system is by making the change there and propagating it “backwards” into the other parts of the platform or DSL. This ability is often referred to as round tripping in ORMs. Antkiewicz and Czarnecki discuss the importance of round-trip engineering as it applies to complex Eclipse API’s.

JSP pages are examples of artifacts that include both generated code such as forms as well as developer-written code. The generated parts are placed within protected regions, making them either read-only or modifiable in a limited way. We propose that they be available for participation in transformations that are bound to DSL-level transformations. The function coevolve computes the corresponding DSL-level transformation for platform-level transformations.

For a developer-initiated transformation, ti on artifact Pi:

t = coevolve(ti, Pi)

t1 … tN = evolve(t, D)

D’ = t(D)

P’i = ti(Pi) forall ti

Here’s the full pdf. It’s a little light on details, but that’s all that fit into 2 pages! I’ll write much more in the next few months.