Mittwoch, 30. Mai 2007

Agile Language Engineering

This is about the idea to apply agile methods to language engineering. We discuss the agile principle, why it is interesting for language engineering, what is needed to actually realise an agile language engineering process, and what can already be done with the technology at hand.

The agile method is popular in general software engineering. It promises better products, more efficient development, and above all more fun for all participants. Agility basically means to use a lightweight, very adaptive, and dynamic development process that: (1) concentrates on developers and customers, their needs above fix processes; (2) short development cycles that concentrate on the most important changes and maintain a software product that is testable and executable at all times; (3) use a single software description, which is usually the program code, as the only artifact; (4) include the customer into the process, have him use the software extensively during development, and embrace whatever feedback he/she can provide. More about the agile principle and agile methods can be learned from the agile manifesto.

How can we apply this general philosophy for (software) engineering to the engineering of languages; and why would we like to do so? The why first: domain specific languages. These are languages that provide functionality to domain experts in an outfit that is suitable to them: this basically means to provide concepts and notations as they are already used within the domain. The problem with these languages is that they are only used by a small group of people, these language have a short life-cycle, are hard to understand by the computer scientist that design them, and are subject to regular changes. All these problems are taken care of by agile methods: rigorous user/developer exchange, embrace change, short development cycles with fast results.

When you accept that language engineering could benefit from agile methods, you will ask what do I need to conduct agile language engineering? Lets look at a development cycle, typical for an agile process. The whole process usually starts with a user story: he/she needs a whole new language. You sit down with the user and scribble a few example models, which we call reference models. Now, you're going to implement the language, meaning that you create language tools (editors, simulators, code-generators, etc.; depending on the language). You do implementing until you reach the point where all the reference models can be successfully handled by your tools. You can always test your tools using the reference models. Now you have a working version of the language and can give it to the user. He/she will try the language, while you start refactoring what you have build. After a while the user comes back to you with a new story, requesting a new feature or to change an existing language feature. The whole cycle starts again.

All this sounds like a normal agile process, what is so language specific about it? We identified three technologies that are obviously necessary to realise this process. You need these reference models as a specific form of testing. These reference models are the base for your automated language tests. We would like to know whether the reference models cover the whole language. We summarize these research aspects under the name language testing. The next thing is that we need ways to develop language tools efficient. We propose the term language modelling which uses (meta-)models at a high-level of abstraction to describe certain language aspects rather than implementing language tools manually. The meta bubble is full of examples: OCL can be used for static language semantics, our own MOF Action Semantics can be used to define operational semantics, GMF or TEF can be used to define graphical or textual editors, and so on and so on. These technologies allow you to create language tools fast. In agile language engineering the language often changes. User come up with new ideas or we have to refactor our language. We need a third technology to change meta-models in such away that we can co-evolve all the models and other descriptions that are based on the meta-model. This research aspects is known as meta-model adaptation and model co-adaptation. With all these technologies available and aligned to each other, one could actually exercise agile language development.

We are currently trying to align all our tools to realise an example language project based on the agile method. We have meta-modelling, OCL, and MOF Action Semantics to effecient develop a language with operational semantics. A college of mine, is currently realising a meta-model refactoring and co-adaptation tools suit based on the eclipse refactoring framework. Another college is looking into the reference model test issue. Theoretically, we have everything needed for a first experiment on a toy language. I hope to present some results of this experiment soon.

Freitag, 25. Mai 2007

Welcome to the Meta Bubble

I will use the meta-bubble as platform to inform you about news, changes, insight thoughts, and discussions that rank arround my current projects. Of course I try to promote my work on other media media as well: like on web-sites, open source project sites, eclipse update sites, and in the futures they might by even more sites. But, non of these allow you to instantly get informed about new features, documentations, tutorials, or simply about new ideas that get into the projects. And of course, the meta bubble does not only inform, it also allows you to participate, to put your thoughts and ideas into the projects or simply discuss meta-issues. So, from know on I like to call them our projects.

We only want to give a very short introduction to our projects here; there is much more information at our main web-site. We have several projects that will help you to model languages. As you probably know, computer languages can be described with computer models. The best known technique might be meta-modelling with languages like MOF or EMF's ECore., and, as you already know, these meta-language are very good at describe language structures; they are used to model the abstract syntax of a language. This already allows you to handle your models, programm with them, or store them as files. But still, there a several other language aspects to cover:
Depending on your language, you want to have editors, statical analysers, compilers/code-generators, or interpreters/simulators. We think that each of these aspects can be described using an owned specific meta-languags.

We developed A MOF 2 for Java (AMOF2 or AMOF), a CMOF (MOF2) based model programming environment. AMOF also has comprehensive OCL facilities, using the OSLO OCL interpreter for invariants and implementations for derived attributes and query operations. AMOF supports user defined implementations of operations and derived attributes in several languages. We already mentioned OCL, but you can also use Java, or a specific kind of UML activities that we developed for the modelling of operational semantics.

This is actually our next project, called MOF Action Semantics (MAS) . Here we use meta-models to describe the abstract syntax and runtime structures of an executable language. These structures can be augmented with behaviour, which leads to immediate executeability of your models. We are about to extend this project with an "all-you-need" eclipse support that you allows to define your language, execute your models based on your language, and debug your operational language semantics.

The Textual Editor Framework (TEF) is an eclipse based programming framework to create semantic richt text editors for your EMF models. It allows you to define an arbitrary concrete syntax for your existing ECore meta-models. Your editor can be supplemented with syntax-highlighting, code completion, error annotations, etc. We are currently working on an comprehensive OCL editor, which can be used for any EMF based model, and also comes in handy for most of our other projects heavily depending on OCL.

I hope you got a good first view on what we are doing here. More details can be found at our sites: meta-tools, berlios-project site for AMOF, berlios-project site for TEF, my home page. And of course, I hope to give further inside with each additional post in the meta bubble. So, you better stay tuned and subscribe to this blog.