Java Language Days auf der JAX

At next year's JAX conference there will be a two-day special track on new and interesting languages on the JVM (see here). The days are organized by Dierk König and myself. We still have free slots, as well as a budget to invite people. So please let me know who you want to hear speak at this event.  permalink    0 comments

 

Software Engineering Method and Theory

SEMAT is an initiative that wants to

support a process to refound software engineering based on a solid theory and best practices.

This certainly sounds interesting. If they can keep it relevant for practitioners, this is certainly interesting to follow.  permalink    1 comments

 

SEACON 2010 - Call for Speakers

The 2010 edition of the SEACON is in the process of being prepared (I am on the PC, this is why I blog about it :-)). The conference, taking place on June 28 and 29 in Hamburg, focusses on Interaction Design, Communication, Domain-Oriented Software Development and Test Automation. So, I encourage you to take a look at the CfP and submit something!  permalink    0 comments

 

PLE Track at OOP 2010

At this year's OOP conference there will be a two day track on product line engineering, organized by Christa Schwanninger of SIEMENS. The two days are packad with a number of really interesting and relevant talks, going beyond only the technical aspects (such as variant management). So if you're interested in PLE, take a look at the talks and consider joining :-)  permalink    0 comments

 

The Role of Domain Experts in *designing* DSLs

One of the advantages of using DSLs is - so people say - that the communication between domain experts and software developers is improved. However, a good "business" DSL is one where the business or domain folks can do the coding themselves and then they run the generator to build the executable software. Where in this picture is the communication between the domain expert and the developer that the DSL should improve? In an ideal scenario, business people, after creating the models, press a button. No need to communicate to a developer.

However, there's of course another take at this problem: before domain users can use the DSL to write down their domain specific programs or models, the DSL needs to be created! This DSL creation, and the development of the generators, etc. is of course something a developer does! So the communication between domain experts and developers happens during language creation and evolution!

So, where does this leave us? We need to improve the domain expert/developer collaboration during DSL creation! How can DSL tools help with that? After all, they are designed for developers, right? Are we back to the same old "domain experts write it down in Word, throw it over the fence, and then the devs build the DSL"-kind of scenario? Something that DSLs aim at avoiding in the first place?

Here are some ideas and examples of how domain experts can play a role in language development.

When building a DSL with Xtext, language definition is so quick and straight forward that the domain expert can provide input, the developer builds the grammar, and then the domain expert can use the resulting language/editor to try out whether the language can represent his ideas. Because Xtext is so lightweight, such a round-trip can happen in a couple of minutes. Consequently, it is absolutely feasible to put a domain expert and a developer in front of a machine to develop a language together. There's no real need to write a "language specification".

Intentional has emphasized this idea for a while now. They encourage language developers to start new domains/languages by first just writing down domain concepts (essentially, words at this time) and their relationships. At this point, without defining sophisticated custom projections, models can be edited using a default projection. After an hour or two of pair-language-development the dev can spend the rest of the day alone implementing the fancy custom projections. But at least a first rough cut at defining models based on the new language is available immediately.

With MetaEdit+, the graphical shapes representing the concepts in a diagram can be defined with a nice graphical editor. Again, this shape definition is something that can involve domain experts.

So what do we take from this? Quick turn-around during DSL development is essential to be able to include the domain expert in this crucial phase. When selecting a DSL tool, you should take into account this concern - it hasn't been discussed much AFAIK, and most DSL tools don't make this a priority. Maybe this should change.  permalink    10 comments

 

Learn about DSLs and Schwäbisch at the same time: MID Insight 09 Keynote

Two weeks ago I gave a keynote at the MID Insight 09 conference. I talked about "Programming and Modeling - Two worlds?" The folks at MID filmed the keynote and I uploaded it to vimeo. So here is the video and the slides are here.

By the way: While the slides are in English, the talk and the video are in German (Schwäbisch).  permalink    0 comments

 

Tutorial @ SE 2010: Software Engineering mit Domänenspezifischen Sprachen und Language Workbenches

I was just notified that my (and Peter Friese's) tutorial for SE 2010 has been accepted: Software Engineering with DSLs and Language Workbenches. This is a German conference and a German tutorial, so here's the German abstract:

Als Softwareentwickler sind wir daran gewöhnt, uns mithilfe existierender Programmiersprachen auszudrücken, also die Fachlichkeit des zu erstellenden Systems mittels objektorientierter, funktionaler, oder andere Ausdrucksmittel der Implementierungssprache zu beschreiben. In den letzten Jahren haben sich allerdings Werkzeuge entwickelt, mit denen es möglich ist, eigene Sprachen zu bauen beziehungsweise existierende Sprachen zu erweitern. In diesem Tutorium gehen wir darauf ein, wie sich Softwareentwicklung ändert wenn man die Möglichkeit hat die Sprache an die Domäne anzupassen, und nicht gezwungen ist, sich im Rahmen existierender Programmiersprache zu bewegen. Im ersten Teil des Tutoriums erläutern wir Grundlagen zu domänenspezifischen Sprachen und Spracherweiterungen und erläutere einige wichtige Anwendungsfälle für diese Technologien. Im zweiten Teil werden wir zwei Werkzeuge zeigen mit denen Sprachbau mit vertretbarem Aufwand möglich ist (Eclipse Xtext, JetBrains MPS). Der zweite Teil besteht zum Großteil aus praktischen Übungen.

By the way: it does not overlap with the PIK 2010 workshop, so you can actually come and join us for both :-)  permalink    2 comments

 

Thoughts on Migrating Model-Driven Solutions between Tools

This week I was at a customer who started MDD a couple of years ago. They started with oAW 3.x and at some point migrated to oAW 4.x, using the Classic mode. This means that the meta model was implemented as Java classes. Because the decided to generate from UML, the meta classes were subclasses of the UML 1.x meta model implemented in Java that shipped with oAW classic.

The model defines the core data structures of a large scientific instrument, and it serve as a data exchange layer between systems implemented in several programming languages. Consequently, they have code generators for seven different target languages, i.e. they have put quite a bit of effort into the generators. The meta model structure is reasonably simple, but the behaviour, or derived attributes if you will, implemented in Java is quite non trivial.

Now they decided to migrate to the most current oAW, i.e. using EMF for the meta model and models, and Xtend for the derived behaviour. Consequently, all the meta classes implemented as subclasses of UML 1.x classes don't work anymore. Generally, the behaviour implemented in Java is obsolete and cannot be directly reused. A manual migration of the behaviour from Java to Xtend (or to whatever other platform) is required. This is a lot of work - almost prohibitive!

So what can we do to avoid situations like these?

There is no simple solution. Dependencies on tools, no matter which kinds of tools, are always a problem. If you wanted to migrate your system from one database/middleware/UI framework to another, this is also a lot of work. What can we do specifically in MDD tools to tackel this problem? I think there are a couple of things that are a good starting point:

Instead of writing the code generators directly against the UML meta model, you should introduce an intermediate domain specific layer. Code generators are written against this domain specific meta model, and a model-to-model transformation transforms the profiled UML model to the domain specific meta model. This has several benefits: generators become simpler because the are written against a simpler meta model. Simpler generators are easier to migrate. The complexity of handling UML (they used a couple of non-trivial conventions) is encapsulated in the one M2M transformation instead of being repeated into seven code generators. Also, a migration from UML 1 to 2 (or to a real DSL, throwing away UML) would be simpler, because the differences would all be handled in one single place. No change to the code generstors required.


As a second point, you should use declarative approaches wherever possible. Things like validations, scopes, type systems etc. should not be implemented in "procedural" code. Turing complete, procedural code is hard to "understand" with a tool (other than a compiler) and hence is complex to transform into another representation when you want to migrate the code. The more declarative, restricted and structured such descriptions are, the easier it is to work with them. This is of course the whole point about models in the first place! So maybe I should say it differntly: make sure that as many aspects of meta models, validations, scopes, generators and transformations are themselves described as a model! In oAW 3.x/Classic this is clearly not the case - it is the case to a larger degree (not enough!) with more current versions of Eclipse Modeling and oAW.


Finally, assuming you use models for all these things, make sure it is models based on the same tools/formalisms as your application models. This makes them "just another model" which you can (relatively) easily process in a migration with the tools you are working with anyway. In tools like MPS and Intentional, all aspects of DSLs are defined with models expressed in other MPS/Intentional DSLs. It is turtles all the way down :-)

So what do I take away from this: First, migrations are always hard, also in case of MDD tools. They are especially hard if the effort is put into the generators (for multiple platforms) and not so much into the models (note that we actually added an intermediate domain-specific meta model now; introducing this is just two or three days of work). The second takeaway is that we need to enhance tools such as Xtext
(or EMF in general) to describe more aspects of DSLs as models. Validations, scopes and type systems, as well as model navigation and queries ("give me all types of all public attributes of all classes in this file") are important candidates. There will of course always remain some aspects that need to be described with turing-complete implementation code. But by keeping this to a minimum, the tool lock-in and migration effort is minimized.  permalink    0 comments

 

Eclipse Demo Camp Stuttgart Location Change

If you are planning to join, please take a look at this page to see the new updated location at the airport.  permalink    0 comments

 

Oslo becomes SQL Server Modeling - my 2 cents

Here are my two cents why I am disappointed by Microsoft's decision to change Oslo to SQL Server Modeling. In this eWeek article Doug Purdy is being quoted as follows:

"The great irony to all these (negativ, ed.) comments is that all we did was change the name from 'Oslo' to ... SQL Server Modeling and now we get the #fail tag. If we had called it Windows Modeling or .NET Modeling would it have been #success?"

When I saw Oslo and M, I was always disturbed by the focus on SQL Server integration. I always wondered, why, during talks and demos, the SQL Server aspect was emphasized. Sure, a scalable repository is good and useful. But I always considered it only one option of storing models, basically a "persistence backend" of the nice and cool DSL facilities. I hoped MS would keep the DSL infrastructure indepedent of SQL Server.

This most recent move changes the picture. Now Oslo is basically an API for SQL Server. SQL Server is not merely one of many persistence backends but rather the reason why M & Co exist. And consequently, future decisions in M & Co will be driven by the data community and not by the needs of the DSL community.

So yes, I am somewhat disappointed. Oslo will probably still be a cool and useful tool for data modeling and programming on the SQL server. But it has lost its appeal to me as a general purpuse DSL tooling (at least until I get convinced otherwise :-))  permalink    0 comments

 

PIK 2010: Produktlinien im Kontext

Here some information about an interesting workshop at the SE 2010 conference in Paderborn.

Produktlinien sind heute in vielen Bereichen der Software-Industrie vertreten, von Embedded Systems bis zu betrieblichen Informationssystemen. Sie ermöglichen höhere Produktivität, steigern die Qualität und verbessern die strategischen Positionen der Unternehmen. Zugleich sind Produktlinien noch eine relativ junge Technologie, die für viele Unternehmen noch bedeutende Herausforderungen und Risiken birgt.

Der Workshop PIK 2010 beleuchtet aktuelle Erfahrungen mit Software-Produktlinien und fördert den Dialog zwischen Praxis und anwendungsorientierter Forschung. Im Mittelpunkt steht das Wechselspiel zwischen technischen Fragestellungen und den geschäftlichen, organisatorischen und Prozessaspekten. Daneben werden auch neue technologische Entwicklungen vorgestellt und diskutiert.

If you consider joining, please read the Call for Papers.  permalink    2 comments

 

Eclipse Modeling: Models Getting Bigger

If you take a look at the more recent activities at Eclipse Modeling you can clearly see a focus on scalability, teamwork, and big or many models.

CDO, the database-based persistence and collaboration layer for EMF models has been extremely popular at this year's Eclipse Summit. I heard about several projects that consider using CDO as the backend for an enterprise wide modeling infrastructure.

What's currently is still missing in EMF (and to some extent also in CDO) is a flexible and scalable query facility. A query language is needed and EMF resources need to provide an API against which queries can be executed. The model query project, spearheaded by SAP, aims at providing this.

In the file/text based environment scalability is also an issue. Modern IDE is, for example, build an index of symbols and the resources in which they're defined to support efficient linking and lookup. The EMF index project, led by the itemis folks in Kiel provides this capability specifically for use by Xtext.

Finally, the ARTOP project has created a number of facilities to work with EMF/XMI models that are several hundred megabytes in size (the tools are not publicly available right now).

All of these projects and developments are a clear signal that Eclipse modeling is picking up momentum in "real" environments. It is a good sign if a technology leaves behind the "it works" phase and addresses "how to use it large scale".  permalink    2 comments

 

Programming, Modeling, DSLs and Language Workbenches

More and more I am getting to the point where I think that there should be no difference between modeling and programing. What we really want is to program ... at different levels of abstaction ... from different viewpoints ... all viewpoints integrated ... … with different degrees of domain-specificity ... with suitable notations ... with suitable level of expressiveness ... and always precise and tool processable.

I am talking about this idea quite a bit. Some slides towards this point are at slideshare and as PDFs on my website.

I will blog about some of the thoughts from these slides in the next couple of weeks.  permalink    1 comments

 

William Cook on Industry and Academia

You should really read William Cook's ECOOP 2009 Banquet Speech on Industry and Academia. Very good! Here's an excerpt:

The way I see it is that industry generally has more problems than they do solutions, but academia often has more solutions than problems. As an academic, I think everyone here will realize the value of a good problem. So if nothing else, we should revise the technology transfer story to include flows in both directions. Industry could transfer problems to academia, and academia could provide solutions to industry. I want to emphasize that both these flows are of high value.

Exactly how I see it, too!  permalink    1 comments

 

A few thoughts on code generation with MPS

Here is a typical scenario that I use when working with classical external DSLs: I describe certain structures in the model. From the model I generate all kinds of code, infrastructure, glue code, and also an API (e.g. superclasses) against which I then implement the manually-written business logic.

Here is an important thing: if I want to enforce certain constraints, for example visiblities or dependencies, then it is not enough to enforce these constraints on model level. I must make sure, through generation of suitable code structures, that in the manually written parts I cannot violate these constraints. For example, I need to prevent the creation of depenencies that have been prevented on DSL level. Consequently, I have to put a lot of thought into the structure of the generated code and sometimes I need to use "tricks" to enforce these constraints on code level. Or I need to use static analysis tools.

Contrast this with the approach in MPS: here you code *everything* in the model, because you can use Java (or other languages we're working on) directly on the model level. You don't implement code against some kind of generated API. So you can enforce the constraints mentioned above only in the model! The generated code is really not important here (sure, it should be readable and debuggable, but it's not something against you program). This simplifies the design of the generated code, and hence the code generator, quite a bit.  permalink    0 comments

 

Training on DSLs, Product Lines and Language Workbenches

On February 3 and 4 2010 I will run a course on Domain Specific Languages (for Product Lines) at Sioux Embedded Systems in Eindhoven, The Netherlands. In addition to concepts, I will cover Xtext as well as MPS.

I invite you to join, even if you already know one of the tools - maybe especially if you already one of the tools, so you can learn another approach. This will certainly deepen your understanding about DSL and the technologies used to implement them.

If we get a nice group, this could be a very interesting, productive and fun training.  permalink    0 comments

 

Practical Product Lines 2009

I just returned from the PPL 2009 conference in Amsterdam. Although small, the conference was very good: nice program, competent participants, nice venue, good food. I will definitely go back next year. It is also better value for money than SPLC if you're interested mainly in practical aspects of PLE.

To get an impression of what the conference was like, take a look at the Twitter #ppl2009 stream.  permalink    0 comments

 

Slides uploaded to slideshare.net

I have just uploaded a couple of my currently relevant presentations to http://slideshare.net. All of them had been online at my website, too, but I decided I wanted to participate in the slideshare community.  permalink    0 comments

 

Type Systems for Xtext DSLs

I recently implemented a type system for an Xtext DSL. I wanted to give you a couple of pointers of how to do it, if you have to.

What is a type system? A type system is essentially a set of sophisticated constraints. I.e. it is a way of determining whether a model is correct beyond its structure. We all know type systems from programming languages. If you try to add an int and a String, you'll get a type error.

So, in principle, you could simply implement a type system as a set of Check constraints. This is true, but for non trivial type systems and languages, this can grow complex. A more principled approach is recommended, and it consists of three ingredients.

The type meta model: the structure of types and their relationship often warrants its own meta model. For example, an array type isn't trivial: It has to express that it is an Array, it has to contain the size, and it has to point to the type of the elements in the array. The array type itself is structured. Hence, it is a good idea to create a meta model, or language, to capture the types. In the context of Xtext, you can either do this as a separate EMF meta model that you reference from the Xtext DSL, or you simply add additional rules to the language that represent the types once they are transformed to Ecore. Make sure that the grammar structure does not allow you to actually "write down" the types in models - you want to work with them behind the scenes.

So how do you associate the type of an element with the element itself? A good way is simply to create a bunch of Xtend functions. I usually call it typeof(...) and define it polymorphically for all the language elements for which I want to have a type. These functions typically do one of two things: for atomic elements (e.g. an integer literal or an array declaration) the typeof(...) extension simply returns the type object, i.e. instances of the type meta model (or language) defined above. For non-atomic elements (let's say, a comparison operation that compares the result of a constant and a plus expression) the typeof function contains a type derivation rule. For example, for a plus expression, it returns the type of one of the operands (the types of the two operands have to be the same, see below). For a comparison
operation, it simply returns boolean.

Finally, once you have these two ingredients in place, you can now implement the actual type constraints. For example, it a type constraint might say that for a plus expression, the typeof(...) the left operand and the typeof(...) the right operand need to be the same. Note that by calling the typeof(...) function for both operands, the resulting type is calculated correctly even if the two operands are, for example, multiplication operations themselves.

One last comment: usually, types don't have to be the same for a constraint to be correct, but they have to be "compatible", whereas compatible is defined specficially for each type. To incorporate this problem, simply create an isCompatible(t1, t2) Xtend function, which you polymorphically override for all relevant type combinations.

That's it! Using this approach gives you a scalable, and maintainable type system implementation.

PS: MPS uses the same approach. It even comes with a separate DSL for defining type systems, including a set of operators for type inference and type compatibility. Very nice!  permalink    6 comments

 

MPS Workshop at itemis

Last week, we had a workshop about JetBrains MPS at itemis in Pforzheim. Konstantin Solomatov, MPS' lead developer, was kind enough to spend a whole week with the team in Pforzheim to teach us MPS to a level of detail where I feel comfortable to start using the tool in real projects (thank you very much, Konstantin!).

We have built a couple of example languages, all of them extensions of Java. Remember that one of the benefits of MPS is the ability to extend existing languages, in particular, the version of Java (called BaseLanguage) they ship with MPS: we have extended Java classes with state machines, we've added pre- and postconditions to Java interfaces, we implemented a new type to represent money and we've built a way to express product line variability for arbitrary languages.

Once we got used to some of the particularities of MPS, working with the tool was actually very productive and comfortable. In the time we had, we got further along than I had expected. JetBrains have done a really good job with making the projecting editor "feel" as much as text as possible. Within a week or two, you can easily get used to working with this approach.

Because MPS is a projectional editor, you can be extremely flexible regarding modularization and combination of languages. The four example languages we have built can be combined arbitrarily in a single program. Of course the drawback is, that programs are not stored as plain text, but rather as an abstract representation (XML). This means, that you can edit MPS programs only with MPS. However, the projectional approach does give you a significant amount of additional flexibility over storing the concrete syntax. In other words: there are many environments where storing the textual syntax is preferable, in which case tools like Xtext are the better choice. But there are also a number of scenarios where you don't care as much about how programs are stored, and you want to exploit the benefits regarding flexibility that projectional editors deliver. In those scenarios MPS is a very interesting candidate and certainly worth considering (remember, that it is also open source).

In the next weeks, I will continue my evaluation of the Intentional Domain Workbench to complete my picture about the three most interesting DSL tools out there: Eclipse Xtext, JetBrains MPS and the Intentional Domain Workbench. These tools are different enough to warrant familiarity with each of them. They all have a particular sweet spot regarding where and how they should be used.

Stay Tuned!  permalink    0 comments

 

The future of openArchitectureWare

Over the last couple of months, many people have asked me about the status of openArchitectureWare. I have blogged about this before. Here is some update. Heiko and Peter have created a succinct summary at openarchitectureware.org.  permalink    0 comments

 

Profiler for XPand and Xtend

Heiko Behrens has blogged about the Xpand/Xtend Profiler that will be part of the next 0.8 M2 release. Using the profiler, you can substantially improve the performance of Xpand-based code generation and/or Xtend based model transformations. If you have issues with oAW performance, take a look!  permalink    0 comments

 

Website down

It seems my website http://www.voelter.de is currently down. My provider says they're working on it... they said this 5 hours ago. Let's see if it's up again by tomorrow morning.  permalink    0 comments

 

Using Scala for Xtext scope definitions

Over the last couple of days I have experimented with using Scala for a XText scope definitions. In my opinion, the current API for defining reference scopes in Xtext has two problems: first, because it is based on naming conventions, there is no compiler error if you change the name of the referencing feature; your scope definition simply isn't invoked anymore. The second problem is that Java is not necessarily the ideal language to write more or less complex model navigation and query code.

My Scala implementation addresses both of these problems. Scala, through its functional programming flavor, is much better suited for model navigation and query. Also, I've decided to generate a base class with empty scope definition methods and you provide the customized implementation in a subclass. Since Scala requires the use of the override modifier if you want to override a method in a subclass, you get a compiler error if you change the name of the referencing feature (and hence, the name of the generated method in the base class).

In the rest of this post I explain how I built this, and also discuss my experiences, and whether I recommend using this approach or not.

The first you have to do is to install the Scala IDE for Eclipse. Then you have to Scala-enable your language project, since you want to put scala code into it. I have described here how you do this.

Then you need to make sure that the base class with the generated scope methods is generated as part of the language generation process. To do this, I have written a plug-in that contains an additional Xtext generator fragment that generates this code. Generator fragments are plug-ins into the Xtext generator. You get the language grammar as an EMF model, and then you can generate whatever you want from it.

Based on this infrastructure, you can then implement your own scope in Scala.

Should you use this approach? In principle, yes. Scala really is much nicer than Java, particularly for the task at hand. And the fact that you get compiler errors if you rename properties is really useful.

However, in practice there are two problems that really make me recommend do not use this approach at this time: the first one is that the EMF data structures don't play well with Scala's collection API. You have to write a lot of conversion functions. While this is in principle possible (and actually, quite nice to do due to Scala's implicit methods) you do pay a performance penalty. However, I think this issue can be solved.

The second problem is the Scala IDE for Eclipse. At least in this scenario, where you mix Java and Scala code, and where you use it for plug-in development, the IDE really is not good enough. For example, code completion doesn't work (at least on my machine), you have to do a full rebuild constantly to make sure changes in the Scala code make it to the class files, a compiler error in the Scala file "destroys" the classpath, preventing Xtext from generating the language, there is no "organize imports" for Scala, etc. etc.

Now, my goal here is not at all to bash the Scala IDE. I got good support from Miles Sabin who is the main person behind it. He said that by the end of the year the Scala IDE should be roughly comparable to the Java IDE in Eclipse (and he's looking for help in reaching this goal!). So I guess, I will check back later, when the 2.8 release of the IDE is available. I really think, once the Scala tooling in Eclipse has matured, using Scala for scopes is a good idea.  permalink    0 comments

 

MDE Diploma in Nantes

The folks at Nantes (Ecole de Mines and INRIA) have started something interesting: an MDE Diploma. They describe it as

The MDE International post-graduate specialization Diploma in Model Driven Engineering (MDE) for Software Management is offered by Ecole des Mines de Nantes. Its objective is to train engineers to manage complex projects in various IT fields with the latest cutting-edge modeling technologies.

Sounds good! So if you're interested in enhancing your academic education, and want to do it in the context of model-driven stuff, you should take a look!  permalink    0 comments

 

Xtext Helios Roadmap

... on Sven's Blog. Let him know if you have comments, suggestions or input!  permalink    0 comments