Tijs van der Storm

RASCAL: A Domain Specific Language for Source Code Analysis and Manipulation

Many automated software engineering tools require tight integration of techniques for source code analysis and manipulation. State-of-the-art tools exist for both, but the domains have remained notoriously separate because different computational paradigms fit each domain best. This impedance mismatch hampers the development of new solutions because the desired functionality and scalability can only be achieved by repeated and ad hoc integration of different techniques. Rascal is a domain-specific language that takes away most of this boilerplate by integrating source code analysis and manipulation at the conceptual, syntactic, semantic and technical level. We give an overview of the language and assess its merits by implementing a complex refactoring.

The State of the Art in Language Workbenches. Conclusions from the Language Workbench Challenge

Language workbenches are tools that provide high-level mechanisms for the implementation of (domain-specific) languages. Language workbenches are an active area of research that also receives many contributions from industry. To compare and discuss existing language workbenches, the annual Language Workbench Challenge was launched in 2011. Each year, participants are challenged to realize a given domain-specific language with their workbenches as a basis for discussion and comparison. In this paper, we describe the state of the art of language workbenches as observed in the previous editions of the Language Workbench Challenge. In particular, we capture the design space of language workbenches in a feature model and show where in this design space the participants of the 2013 Language Workbench Challenge reside. We compare these workbenches based on a DSL for questionnaires that was realized in all workbenches.

Evaluating and comparing language workbenches

Language workbenches are environments for simplifying the creation and use of computer languages. The annual Language Workbench Challenge (LWC) was launched in 2011 to allow the many academic and industrial researchers in this area an opportunity to quantitatively and qualitatively compare their approaches. We first describe all four LWCs to date, before focussing on the approaches used, and results generated, during the third LWC. We give various empirical data for ten approaches from the third LWC. We present a generic feature model within which the approaches can be understood and contrasted. Finally, based on our experiences of the existing LWCs, we propose a number of benchmark problems for future LWCs. HighlightsWe describe the challenges posed by the 4 Language Workbench Challenges run so far.We establish a feature model that captures the design space of language workbenches.We classify 10 language workbenches according to our feature model.We present empirical data on 10 implementations of a questionnaire DSL.We propose benchmark problems to be used in future Language Workbench Challenges.

Variability and component composition

In component-based product populations, variability has to be described at the component level to be able to benefit from a product family approach. As a consequence, composition of components becomes very complex. We describe how this complexity can be managed automatically. The concepts and techniques presented are the first step toward automated management of variability for web-based software delivery.

Continuous release and upgrade of component-based software

We show how under certain assumptions, the release and delivery of software updates can be automated in the context of component-based systems. These updates allow features or fixes to be delivered to users more quickly. Furthermore, user feedback is more accurate, thus enabling quicker response to defects encountered in the field.Based on a formal product model we extend the process of continuous integration to enable the agile and automatic release of software components component. From such releases traceable and incremental updates are derived.We have validated our solution with a prototype tool that computes and delivers updates for a component-based software system developed at CWI.

EASY meta-programming with Rascal

Rascal is a new language for meta-programming and is intended to solve problems in the domain of source code analysis and transformation. In this article we give a high-level overview of the language and illustrate its use by many examples. Rascal is a work in progress both regarding implementation and documentation. More information is available at http://www.rascal-mpl.org/.

Bringing domain-specific languages to digital forensics

Digital forensics investigations often consist of analyzing large quantities of data. The software tools used for analyzing such data are constantly evolving to cope with a multiplicity of versions and variants of data formats. This process of customization is time consuming and error prone. To improve this situation we present Derric, a domain-specific language (DSL) for declaratively specifying data structures. This way, the specification of structure is separated from data processing. The resulting architecture encourages customization and facilitates reuse. It enables faster development through a division of labour between investigators and software engineers. We have performed an initial evaluation of Derric by constructing a data recovery tool. This so-called carver has been automatically derived from a declarative description of the structure of JPEG files. We compare it to existing carvers, and show it to be in the same league both with respect to recovered evidence, and runtime performance.

Feature-Oriented programming with object algebras

Object algebras are a new programming technique that enables a simple solution to basic extensibility and modularity issues in programming languages. While object algebras excel at defining modular features, the composition mechanisms for object algebras (and features) are still cumbersome and limited in expressiveness. In this paper we leverage two well-studied type system features, intersection types and type-constructor polymorphism, to provide object algebras with expressive and practical composition mechanisms. Intersection types are used for defining expressive run-time composition operators (combinators) that produce objects with multiple (feature) interfaces. Type-constructor polymorphism enables generic interfaces for the various object algebra combinators. Such generic interfaces can be used as a type-safe front end for a generic implementation of the combinators based on reflection. Additionally, we also provide a modular mechanism to allow different forms of self-references in the presence of delegation-based combinators. The result is an expressive, type-safe, dynamic, delegation-based composition technique for object algebras, implemented in Scala, which effectively enables a form of Feature-Oriented Programming using object algebras.

Study of an API migration for two XML APIs

API migration refers to adapting an application such that its dependence on a given API (the source API) is eliminated in favor of depending on an alternative API (the target API) with the source and target APIs serving the same domain. One may attempt to automate API migration by code transformation or wrapping of some sort. API migration is relatively well understood for the special case where source and target APIs are essentially different versions of the same API. API migration is much less understood for the general case where the two APIs have been developed more or less independently of each other. The present paper exercises a simple instance of the general case and develops engineering techniques towards the mastery of API migration. That is, we study wrapper-based migration between two prominent XML APIs for the Java platform. The migration follows an iterative and test-driven approach and allows us to identify, classify, and measure various differences between the studied APIs in a systematic way.

Generic feature-based software composition

Bridging problem domain and solution in product line engineering is a time-consuming and error-prone process. Since both domains are structured differently (features vs. artifacts), there is no natural way to map one to the other. Using an explicit and formal mapping creates opportunities for consistency checking and automation. This way both the configuration and the composition of product instances can be more robust, support more product variants and be performed more often.