In the end we came up with: Some statistics of the project activity (1), a news aggregator (2), and a condensed (53 secs) introductory screencast (3).

The updated Xtext website displays commit statistics (1), recent blog posts plus other web content (2) and a brand-new introductory screencast (3)

Our project website attracted some attention since it has been launched this June. The AMP project reuses its layout and Denis from the Eclipse webmaster team embraces the results, too. From there, the bugzilla 235828 discusses whether the Xtext website should serve as the standard template for new Eclipse projects.

Currently, you can see such an “empty Xtext website” at eclipse.org/default - how cool is that!

The Bells and Whistles

Even if Denis, Matt & Karl will provide a standard template based on the Xtext website you might want to adapt some of our additional features, too. To support you in doing so, I will summarize the underlying technology of the recently introduced features.

To produce the commit stats (1) the page leverages the commit statistics of Xtext and renders the polished data with the Google Chart API on order to match our visual expectations.

The news section has been built with Yahoo Pipes to scan, filter and aggregate different web resources asynchronously. You can even subscribe to the news feed directly to always stay up to date.

For both the commit stats as well as the news section Denis allowed me to install a cronjob that fetches and stores the results independently from the http requests.

The screencast has been recorded and edited with ScreenFlow. Also, thanks to Sven for the audio equipment!

Let me know if you want me to provide more details.

Nearly 200 attendees, 29 talks on 2 days and 3 winners of the best German iPhone App contest at the iPhone Developer Conference in Cologne

I had the chance to introduce the iPhonical project that applies model-driven techniques to produce parts of iPhone applications automatically. The presentation first describes a way to separate generated code from manually written source with the Objective-C concept of categories. From there, I demonstrated that even with powerful frameworks such as ObjectiveResource (an adapter to connect iPhone apps with Rails applications) one can benefit from code generation. With the help of the iPhonical DSL (implemented with Xtext) keeping data-centric classes in sync with the web application was way easier than coding them by hand.

The iPhoneDevCon was a very informative event. Many passionated developers or leads, growing studios and enthusiastic marketing representatives shared their ideas and during the breaks you could easily discuss different viewpoints of today’s opportunities and approaches.

Apart from the 3 winners of the “best German iPhone app” (according to iPhone & Co) a brand-new iPhone and Mac magazine, mac-developer, has been announced. As the name suggests it concentrates on developers and its first issue is quite promissing.

Links

• iPhone Developer Conference website
• Slides “iPhonical and model-driven software development for the iPhone” on SlideShare
• iPhonical project website
• mac-developer magazine (German)

Frank Zimmermann explained how Eclipse Modeling and Xtext in particular can be used to produce SAP applications. He even gave a live-presentation of the tools his students developed during a research project.

Simon Zambrovski took some photos at the EWiTa

Since the slides I used at the EWiTa were an excerpt from a former talk at the Code Generation 2009 in Cambridge I will only list the related talks I mentioned in the end:

• Xtext Workshop
  Eclipse Summit Europe – 27 October 2009 – Ludwigsburg
• Mastering differentiated MDSD Requirements at Deutsche Börse AG
  W-JAX 09 - 10 November 2009 – Munich
  
• Experience Report by Deutsche Börse AG
  Eclipse DemoCamp Frankfurt – 26 November 2009 – Frankfurt
• Combining Graphics and Text in Model Editors
  Eclipse DemoCamp Hamburg – 04 December 2009 – Hamburg

Links

Meet us at the Eclipse Modeling Days in New York and Toronto

Personally, I am looking forward to the talks

• “Modeling on an Enterprise Scale” (read: “Learn more about CDO”)
  by Eike Stepper and
• “Agent-Based Computer Simulation for Operational Risk Analysis”
  by Ed MacKerrow

to learn more about two exciting topics I am curious about. Of course, itemis will be there as well. Make sure you don’t miss

• “Converging Textual and Graphical Editors”
  by Moritz Eysholdt and
• “Building DSLs with Xtext”
  presented by myself.

Head over to the wiki page to browse the abstracts and register for one of these free events or read some other announcements.

Looking forward to seeing you over there!

Elmshorner Wirtschaftsinformatiktag at Nordakademie near Hamburg

Other talks such as

• “Collaborative Modeling of Business Processes” (Mathias Weske),
• “Test-Driven and Model-Driven combined with openArchitectureWare” (Arne Michael Törsel) or
• “Being Skeptic about MDSD” (Hartmut Herde)

show great promise for interesting discussions. Please note that the aforementioned talks as well as every other talk will be held in German (I freely translated the titles for you).

There’s no conference fee and the organizers will be happy to welcome you at the Nordakademie if you register before October 23rd. So, if you happen to be around Hamburg that Friday don’t miss the 1st EWiTa!

Output of the profiler from the Xpand Sample-Project

If you stay with the text-based GProf output format (another option to dump the collected data) you can also use tools like Gprof2Dot to visualize hot spots with colors and callees as painted connections.

Same workflow visualized with Gprof2Dot without reduction of nodes with no impact

The updated documentation explains how you can integrate the profiler into your workflow. Also, the Xpand Sample-Project Wizard creates a second workflow “generatorWithProfiler.mwe” where I have generated the above results from.

In a real-world project we were able to reduce the execution time of a workflow that originally took nearly half an hour down to less than 3 minutes using an earlier version of this profiler. It can also help you detecting unwanted indirections and recursions.

openArchitectureWare moved to Eclipse

The homepage of the working group at Eclipse offers links to ready-to-use distributions and we are working on update sites, too.

I want to thank Peter and Karsten for their help with this. Hopefully, this public notice will encourage even more users to migrate to the more stable and feature-rich version at Eclipse. Again, if you need professional support around oAW itemis will be glad to assist you.

MDSD process shortens development cycles where the customer expects specific applications to calculate different classes of estimation bids

My work as the “technical facilitator” was mainly enjoying the progress and providing alternatives during the sprint review and planning meetings (yes, the group decided to go with Scrum). Without excessive help the students were able to develop a DSL that is able to

• make simple and complex existing data types of the SAP system available to the editor,
• express business formulas based on variables of these types,
• provide a comfortable editor that checks many constraints and guides the expert, and
• describe layout of the UI based on these values.

From this input some Xpand templates generate

• a testbed for these formulas that allows domain experts to capture their expectations within a spread sheet application,
• database table descriptions to store estimates for reference,
• a dynpro frontend including search masks to fill in the needed dimensions and displaying results in real-time, and
• the needed ABAP code to perform the calculations as well as glue code for the SAP system.

Prof. Frank Zimmermann published a short description of this project in the in-house magazine Capusforum of the Nordakademie (German). There will be more material on these results soon: The students are preparing a publication addressing MDSD for Enterprise systems in a larger German magazine. The cimt AG and itemis will use this project to demonstrate the possibilities as well.

For me, this research project is just a proof of concept. I am sure the vast majority of SAP projects can benefit from MDSD principles. Thanks again to Prof. Zimmermann from the Nordakademie, Michael Neuenstadt, Michael Flemming as well as Dr. Kuhlmann from cimt AG and last not least the students. It was a pleasure to work with you!

If you have detailed questions -technical or commercial- don’t hesitate to contact me or the responsible sales representative, Asaf Ikram.

iX Magazin issue 08/2009 prints my article about Xtext

But this is not the only publication that discusses Xtext: Next week the German Eclipse Magazin (issue 5.2009) will start a series by Jan Köhnlein and Sebastian Zarnekow that explains the technology in detail. And Sven Efftinge sums up the recent events around the Eclipse Modeling Project (including Xtext) in the very same issue (online version of this article already available).

Lars Corneliussen and Markus Völter started a series about DSLs in the in dotnetpro (so far, issue 05/2009 and 07/2009). Even though the focus is on .net platform the former version of Xtext (oAW 4.3) plays a significant role.

Unfortunately, all these publications are in German. If you are interested in writing an English article and need someone to review your work or if you have strong connections to English publishers who might be interested in an article written by us, please contact us via xtext at itemis dot com or comment this blog post.

That said, I want to thank the reviewers of my iX article for their valuable feedback!

Links

• Online version of the iX Article
• Links mentioned in the iX Article

If you are looking for a challenge and wanted to play around with Xtext since you heard about it this one is definitely for you. Pimp Xtext the way you want, combine it with colors, graphical aspects or any other technology, work with huge models, come up with a new programming language – your mind is the limit.

Be creative, use unusual techniques, explore your skills, do whatever it takes – we want you to get really excited about it so we will be excited as well.

You will have two months to submit an inspiring solution based on Xtext. And, with a bit of luck, you will not only win an Xtext T-shirt but program your next Java project for an Android mobile phone or meet other Eclipse enthusiasts at the Summit in Ludwigsburg.

Feel free to comment if you have any questions. Good luck!

The webinar will start at 5:00 pm GMT (convert to local time) and will take approximately one hour. We will offer a chat to answer your questions either live or in the end of the show. And since the program is not yet completely settled, it’s your chance to declare anything as a must-see. Just leave your comments here.

Update

The webinar was a great success! With the help of Sebastian and Moritz we were able to inform and entertain 130 Attendees. You can watch the replay at any time and follow some useful links either via its website or directly here:

• Slides (via SlideShare)
• Chess Example (not there, yet)
• Domain Model and Index (via Svens Blog)
• Xtext and GMF (via Jans Blog)

Also, here you will find the final poll results. Thank you for you help, Lynn!

Do you have any experience with modeling? (99 Answers)

What do you think about Xtext? (59 Answers)

This time I tried to spread the idea of DSLs with chess and different ways of expressing moves within the game. In the first part of my presentation I processed cryptic notations like “Rd2-c2″ or more natural equivalents such as “rook at d2 moves to c2″ to work with them as true Java objects and eventually visualized chess fields. Second, I tried to emphasize the value of DSLs in today’s software projects where we implemented another DSL live at the DemoCamp in the end. You will find my slides at SlideShare again.

It was quite informative to chat with the Eclipse folks in London afterwards. Most of them have a pragmatic view at modeling and tools in general. I really appreciate this! Thank you, Neil, for organizing this event and inviting via twitter.

Links

• Slides at SlideShare
• Video Podcast at Skills Matter
• Review at InfoQ

Source Code

Loading chess DSL text files as Java objects:

package org.xtext.example.chess;

import org.eclipse.emf.common.util.URI;
import org.eclipse.emf.ecore.resource.Resource;
import org.eclipse.emf.ecore.resource.ResourceSet;
import org.eclipse.xtext.resource.XtextResourceSet;
import org.xtext.example.ChessStandaloneSetup;

public class JavaTest {

	public static void main(String[] args) {
		String filename = "some/path/MyModel.chess";
		Game g = getGame(filename);
		System.out.println(g.getWhitePlayer() + " vs. " + g.getBlackPlayer());
		for (Move m : g.getMoves())
			System.out.println(m.getSource() + " to " + m.getDest());
	}

	private static Game getGame(String filename) {
		ChessStandaloneSetup.doSetup();
		ResourceSet rs = new XtextResourceSet();
		Resource res = rs.getResource(URI.createFileURI(filename), true);
		return (Game) res.getContents().get(0);
	}

}

The first conference day on Tuesday…

…started with a smooth introduction on modeling, DSLs and all the other terms specific to our focal point. It’s always interesting to see how other experts try to explain what we are doing and Juha-Pekka Tolvanen (MetaCase) did a great job even though he nearly ignored alternatives to graphical models.

Second, Sven and Sebastian talked about challenges in textual DSL design and concentrated on topics such as reusing languages and using models beyond the description of structures. If you follow their blogs you will certainly find out what they are interested in. This was the second time I noticed that the audience here at #CG2009 acts a bit more open-minded towards UML models and my coworkers sometimes had to play hardball with questioners.

Karsten and me skipped the next time slot to prepare ourselves for our own talk “Mastering Differentiated MDSD Requirements at Deutsche Boerse AG” we gave at the end of the day. We packed a lot material into 75 minutes but still managed to come up with a short demo that shows how Xtext can interact with graphical models. You can download the slides at slideshare but the demo is not yet ready, sorry (the attendees asked for this, please drop me a mail or comment on this post so I can inform you later on).

Punting in Cambridge (Foto by Karsten Thoms)

After a stressful day, the organized punting trip along the Cam made this day perfect to me.

Wednesday…

…was a completely different story to me. Instead of listening to or presenting well-known ideas I had the opportunity to get some deep insights of concepts I only read about before. After an amusing staged fight between Markus Völter (textual modeling) and Steven Kelly (graphical modeling) my day started with the well-prepared hands-on session about MetaEdit+ Juha-Pekka Tolvanen, Risto Pohjonen and Steven Kelly gave. From what I have seen I would say that this software is the most sophisticated graphical modeling tool at the market today.

The session I have joined afterwards was not that impressive but I compensated for this with today’s highlight: Language Definition, Extension and Composition with MPS. Markus Völter and Konstantin Solomatov complemented one another and impressed the audience deeply with the upcoming version of MPS. This was the first time I have seen a live presentation on this little pearl of modeling.

Some lightning sessions about Fit4oaw, MBase, UMLCanvas and GWT made the end of the technical part. A nice dinner with french impressions made the night a big success again.

I want to thank Mark Dalgarno and Andy Moorly for organizing this event. Questions about the room plan, the need for a different stage setup, giving up their seat at the dinner or ad hoc money exchange for thirsty attendees – no problems for them. Your upfront organization as well as your courteous appearance is simply overwhelming!

Update: This post has been published at The Model Driven Software Network, too.

Links

• Slides of the session at slideshare
• Pictures of the conference at flickr
• Twitter tweeds about the conference

People are just starting to explore the possibilities and sometimes it is difficult for them to find the right word to name a concept or share an idea. We do our best to support those seekers and are glad to do away with a common uncertainness: The right spelling is “Xtext” and from today its logo does reflect this.

The new Xtext logo starts with a capital X

Beside every other wrong spelling “xtext” was the most prominent. It took us a while to find out why this was the case. Eventually, we realized that the omnipresent logo started with a lower-case “x” (convince yourself). So it was our own fault!

With the help of Carsten Oltmann we are proud to present the new version of the Xtext logo. Feel free to place it into your presentations, on your blogs or as a sticker at your laptop.

Downloads

I will provide the logo in four different flavours and in two different formats. You can download a vector graphic and a PNG in suitable sizes. The background color of the thumbnails are for reference only, the provided graphics are transparent.

EPS (vector)	EPS (vector)	EPS (vector)	EPS (vector)
PNG (800px)	PNG (800px)	PNG (800px)	PNG (800px)
PNG (300px)	PNG (300px)	PNG (300px)	PNG (300px)
PNG (100px)	PNG (100px)	PNG (100px)	PNG (100px)

Beside the talks from Moritz Eysholdt (Patching Models and Evolving Meta Models), Simon Zambrovski (Playing with Eclipse Common Navigator Framework) and Markus Alexander Kuppe (Distributed OSGi, RFC 119 – The ECF way) there was a talk about ObjectTeams again. Marco Mosconi demonstrated how one can weave manually written code into generated GMF editors with an aspect-oriented approach. Nice!

Me talking about Xtext at the Eclipse DemoCamp in Hamburg

I had the opportunity to talk about Xtext in front of an audience that mostly had not seen it before. Playing with expectations and trying out some new ideas was great fun. Xtext becomes more stable and doing live presentations is no risk but a pleasure.

For those who do not want to miss the pizza recipe nor the class schedule DSL, you will find attached the slides. Peter’s photos and Simon’s album give a visual impression of the event. Also, please note that we have just published ready-to-use distributions with the current Xtext RC2 release. Nothing should stop you from implementing your very own grammar. And if you come up with a textual DSL to avoid wrong IDs in your plugin.xml, let me know

Downloads

• Slides at SlideShare (German)
• Eclipse SDK 3.5RC2 with Xtext 0.7RC2 (Linux-gtk)
• Eclipse SDK 3.5RC2 with Xtext 0.7RC2 (MacOS X-carbon)
• Eclipse SDK 3.5RC2 with Xtext 0.7RC2 (MacOS X-cocoa)
• Eclipse SDK 3.5RC2 with Xtext 0.7RC2 (Win32)

Figure 1: The Generation Gap Pattern

Separating generated files from manually written code is best practice for many reasons. It enables you to use version control wisely and makes the distinction between generated and manually written code easy. The Eclipse EMF Modeling Workflow Engine together with M2T Xpand allows you to accomplish this goal in different ways.

In this post, I will present three different approaches that share some common ideas. Each strategy uses a dedicated directory for generated class files whereas manually written subclasses are stored for themselves in a different directory.

General Directory Layout

Both sets of classes belong to the same package but reside in different source folders. Framework classes should be kept in yet another directory and might be placed in a package specific for the framework as seen in Figure 2.

Figure 2: Schematic directory layout of an Eclipse Java project

In Eclipse you can configure such a project structure by adding new source folders (New → Source Folder…) or by declaring ordinary folders as source folders in the project properties (Properties → Java Build Path → Source).

Please note that folder names such as src-generatedClasses are meant to be schematically and stand for a category of folders each. In real world projects you might have several source folders that contain generated artifacts and you might deal with many folders or even projects that contain manually written classes. In the following sections you will see how these categories of folders can be used in practice.

Generate Once

Peter describes a directory layout many Xtext users are familiar with. Generated artifacts go into a folder src-gen whereas manually written classes will be stored in a folder src-once. Each time you run the generator the content of folder src-gen will be purged and generated again whereas the the content of src-once will remain untouched.

Figure 3: Generate Once collects one-time generated artifacts for future editing

Since each model element A leads to two classes AbstractA and ConcreteA (Generation Gap Pattern) you can reduce the amount of manual work by generating the class ConcreteA if it does not exist, yet. During the next run of the generator the class ConcreteA won’t be generated again, hence the name “once”.

Configure an additional outlet in your EMF MWE file:

<component class="org.eclipse.emf.mwe.utils.DirectoryCleaner" directory="src-gen"/>
<component class="org.eclipse.xpand2.Generator">
   <metaModel idRef="mm">
   <expand value="MyTamplate::main FOR model">
   <outlet overwrite="true" path="src-gen">
   <outlet name="MANUAL" overwrite="false" path="src-once">
</component>

Using M2T Expand you can than refer to the outlet MANUAL where appropriate

«DEFINE ConcreteClass FOR Element»
   «FILE this.fileName() MANUAL»
   ...
«ENDDEFINE»

This approach works well in many scenarios but has its limits. As seen in Figure 3 problems arise whenever you delete or rename a model element. In these cases each concrete artifact at src-once that does not correspond to a model element anymore is abandoned and will remain with compile errors. This is desired for classes that hold manual code but is cumbersome for those that do not.

Figure 4: Generate Once in package explorer

For scenarios where a huge amount of generated classes is customized only in a few cases the “Generate Once” approach leads to unwanted manual refactoring effort including file movement. Life is getting worse when you are working with a complex folder structure instead of a single flat directory. Figure 4 might give you an idea of how things will look for growing models.

Conditional Generation 1 (with one gen-folder)

The following approach plays well when only a small subset of classes has to be extended with manual code. According to the Generation Gap Pattern for each model element A there is a generated class AbstractA as well as an concrete class ConcreteA. But in contrast to the “Generate Once” approach both files will be placed in the very same folder src-gen and therefore deleted and regenerated for each generator run.
There is one exception to this behavior. Whenever the generator finds a file ConcreteA in the folder src-man it skips the generation process for this particular file. This is how you introduce manual code.

Figure 5: Conditional Generation 1 reduces manual refactoring effort

At first glance this approach seems to be similar to the solution above. But when deleting or moving model elements this approach really pays off. Each concrete class that does not contain manual code will be deleted and regenerated. Therefore, when moving or deleting the model elements no additional manual work has to be done. Also, a quick look at src-man reveals any code that has been written manually.

Figure 6: Conditional Generation 1 in package explorer

To implement the desired behavior of the generator users of MWE can configure an outlet with a special veto strategy. Please note that the outlet MANUAL does not need to keep files (overwrite=”true”), they will be purged by the directory cleaner anyway.

<component class="org.eclipse.emf.mwe.utils.DirectoryCleaner" directory="src-gen"/>
<component class="org.eclipse.xpand2.Generator">
  <metaModel idRef="mm" />
  <expand value="MyTamplate::main FOR model"/>
  <outlet overwrite="true" path="src-gen" />
  <outlet name="MANUAL" overwrite="true" path="src-gen">
    <vetoStrategy class="your.package.CondGenVetoStrategy" path="src-man"/>
  </outlet>
</component>

Such a veto strategy would read like:

public class CondGenVetoStrategy implements VetoStrategy, VetoStrategy2 {

	private String path;

	public void setPath(String value) {
		path = value;
	}

	public String getPath() {
		return path;
	}

	public boolean hasVeto(FileHandle fileHandle) {
		URI fileToBeGenerated = fileHandle.getTargetFile().toURI();
		URI pathToGenerateInto = new File(fileHandle.getOutlet().getPath()).getAbsoluteFile().toURI();
		URI relativeFileName = pathToGenerateInto.relativize(fileToBeGenerated);
		File potentiallyExistingFile = new File(this.getPath(), relativeFileName.toString());

		return potentiallyExistingFile.exists();
	}

	public boolean hasVetoBeforeOpen(FileHandle handle) {
		return hasVeto(handle);
	}
}

oAW 4.x: VetoStrategy2 has been introduced with oAW 4.3.1.

Unfortunately, the advantages of this approach do not come for free: Compared to “Generate Once” it is more difficult to introduce manual code since it is harder to understand the needed steps. One has to create a concrete class in the src-man folder manually (or move it from src-gen and remove all comments that mark them as generated) where no class exists, yet. This might seem to be a no-brainer but can lead into trouble when defining a process for large projects. This is especially true for the unlikely case that you check-in generated code of src-gen.

Conditional Generation 2 (with two gen-folders)

A slighty different way that basically follows the same idea introduces yet another folder src-gencond.

Figure 7: Conditional Genration 2 lists classes that can implemented manually

As you can see in Figure 7 the generated artifacts are split into the folder src-gen where the abstract classes reside and the newly introduced folder src-gencond. The latter contains only the concrete classes that could be replaced by manually implemented classes. In contrast to the “Conditional Generation 1” approach the users are now able to find classes that can be augmented be manual implementations without any challenge. Users still have to move classes from src-gencond to src-man by hand but it is simpler to communicate the necessary steps.

Figure 8: Conditional Generation 2 in package explorer

As you can see in Figure 8 one can easily identify that there are two classes that could be implemented by hand. Such a folder structure can pay off when different groups of developers are dealing with a fairly large and scattered set of classes.

In order to realize “Conditional Generation 2″ you simply reconfigure the outlet MANUAL to write its output to src-gencond. Also, a second directory cleaner removes all files from this directory before code generation starts.

<component class="org.eclipse.emf.mwe.utils.DirectoryCleaner" directory="src-gen"/>
<component class="org.eclipse.emf.mwe.utils.DirectoryCleaner" directory="src-gencond"/>
<component class="org.eclipse.xpand2.Generator">
  <metaModel idRef="mm" />
  <expand value="MyTamplate::main FOR model"/>
  <outlet overwrite="true" path="src-gen" />
  <outlet name="MANUAL" overwrite="true" path="src-gencond">
    <vetoStrategy class="your.package.CondGenVetoStrategy" path="src-man"/>
  </outlet>
</component>

Comparison

Each of these solutions do their job in real world MDSD projects. Where projects with rather stable interfaces go with the “Generate Once” approach larger projects address growing maintenance effort with the “Conditional Generatation 1/2”  solution. The move from “Conditional Generatation 1” towards “Conditional Generatation 2” is rather trival and can smoothly be taken within a running project.

I’d be happy to read about your experience with these or different project setups.

We know about bugs and missing features but with good cause I want to draw your attention to this release. Apart from the constantly improved core documentation we are beginning with documents like “Getting Started” or ”Migration from oAW Xtext“. The latter is far from being finished and will summarize the lessons we have learned together with our customers that have be been using TMF Xtext since M5 and earlier.

Xtext users might be glad to hear that the API of Xtext is reliable. To accomplish this goal we leverage the annotation @java.lang.Deprecated for parts of the API that won’t be supported in future. But more interesting is the newly introduced annotation @org.eclipse.xtext.Stable. An interface tagged this way is not truly stable itself since we might introduce new methods in future but the annotation might help you anyway. It directs you to an abstract class that you should derive from. Whenever a new method will be introduced in future this class will complement your work with a null implementation your can override as necessary (does anyone know how this pattern is called?).

Interface with @stable and corresponding abstract class

So, even if you won’t try out TMF Xtext at this stage this documentation material might give you a preview of what you can expect in June. Check out the New and Noteworthy Page for a general overview of this release.

Feedback is welcome through the news group and bugzillas.

• Tutorial (75 minutes, Tuesday morning)
  Challenges in DSL Design
  Sven Efftinge, Sebastian Zarnekow
• Case study (75 minutes, Tuesday afternoon)
  Mastering differentiated MDSD requirements at Deutsche Boerse AG
  Heiko Behrens, Karsten Thoms
• Hands-On (180 minutes, Thursday midday)
  Xtext Workshop
  Heiko Behrens Jan Köhnlein, Moritz Eysholdt, Sebastian Zarnekow

Apart from those, there’s a think tank that might strive oAW, too. Interested in Microsoft’s and JetBrains’ accompanists I am looking forward to the “Introduction to the Microsoft Oslo Modeling Platform” as well as “Language Definition, Extension and Composition with MPS”.

This project generates about 1.500+ Java and C++ files as well as some X(HT)ML and plain text. It consists of 250+ Xtend functions and 200+ Xpand defines in more than 80 files. See below the runtime characteristics while generating the artefacts of the very same project using oAW 4.3.1, the Eclipse milestone M5 without and with the recently introduced polymorphic dispatch caching enabled:

Execution time (code generation only)

Looking just at these numbers, I would confidently say that the upcoming Eclipse M2T Xpand runs significantly faster than the good ol’ oAW Xpand!

Read more about the the M2T profiler in this post.

The following diagrams are geared to the UML notation. Boxes are types in this context whereas an arrow indicates a supertype relationship.

Figure 1

In Figure 1, A is the direct supertype of B where C is a direct and E an indirect subtype of A. Each type is compatible with A. Type E and F are compatible with B, which is also the least common super type of E and F. Every type is compatible to itself and the least common compatible type of D and G is D again.

So far, this is pretty obvious. The difficulties arise when dealing with Ecore, or EMF in the context of Eclipse. The meta-model of EMF says, that any EClass (read: Type) can have any number of supertypes. This leads into potential scenarios of multiple-inheritance where things are not so obvious anymore.

Figure 2

Figure 2 illustrates a simple scenario, where D and E have more than one supertype. Both, D and E are compatible with B and C. One can argue whether B or C should be called the common compatible type of D and E. It’s even harder to tell, whether B or C is the least common compatible type. Or are they both?

In the context of Xtext it was necessary to name a single type that works not only as an arbitrary compatible type in general (where both B and C would fit) but would unambiguously be the least common compatible type. In Figure 2 this would be A.

A more complex scenario can be seen in Figure 3. Different associates came up with different proposals each time I asked for, say, the Least Unambiguous Common Compatible Type (LUCCT) of D and F.

Figure 3

Some argued B is as “tight” as C. Others said, the absence of a unique root causes some sort of ambiguity. In the end we agreed that neither C nor B nor A would be “unambiguous enough” to fulfill the requirements of a so-called LUCCT. We also agreed that this question is more challenging than picking the most specific type that is compatible with F and D.

After thinking about this it turns out that a proper solution is not easy but it is no rocket science either.

1. First, find the intersection of all compatible types of the inspected types.
2. Next, concentrate on this set only and find all types that are directly or indirectly connected to every other type in the set. These are the LUCCT candidates.
3. Last, select the most specific candidate of step 2 as the result. If there are no candidates there’s no LUCCT for the inspected types. Yes, there is always a most specific candidate otherwise it would not be a candidate.

Figure 4

In the given scenario of Figure 4 where one wants to determine the LUCCT of G and I the set of compatible types consists of A, B, C, D, E and F. These types on their own are all directly or indirectly subtypes or supertypes of A and D whereas pairwise compared B and C or E and F are not. Since D is more specific than A the LUCCT of G and I is D, voilà!

The gentle reader may apologize the absence of terms like graph reduction or isthmus to explain this method.

More or less accidentally while working with Eclipse and CVS and its function “Compare with latest from HEAD” I stumbled on a grayed menu item that says “…with each other”.

It turns out that Eclipse supports comparing arbitrary files two-way and even three-way. You simply have to select the files to compare and invoke the context menu. Those files only need to be in your workspace. It is not necessary to have them under revision control. Great!

Olivier demonstrates Wazaabi 2.0 to me

On Wednesday, Olivier Moïses, the lead of wazaabi, gave me a demonstration of his ideas about models and UIs. While the Eclipse E4 team at the E4 Symposium still had a strong argue whether modeling would be an advantage that justifies another layer on top of RCP Olivier already did it! Have a look at the preview of Wazaabi 2.0 and you will see how such a live model based on EMF could work.

Jeff gives a great presentation on Ludwig and refactorings with the LTK

Jeffrey Overbey overwhelmed me on different levels. First, his elegant presentation style and confident appearance towards the audience made the rather theoretic topic “refactoring” an entertaining joy (Read Peter’s Post about this). Second, Jeff concentrates on topics where Xtext will advance in the near future, too. On top of his own framework parser/AST generator Ludwig and the Eclipse LTK he will concentrate on refactorings of arbitrary languages. Third, he seems to be as friendly as all the other modeler guys are  Hopefully, his work and Xtext will cross-fertilize.

During the day there were some great contributions including “COPE: Coupled Evolution of Metamodels and Models for EMF” from Markus Herrmannsdoerfer and a felicitous closing by Jos Warner. He discussed “Big Models – An Alternative Approach”. As it turned out in the Open Space Sessions afterwards, working with big models seems to be one of the current challenges in the modeling world.

Unfortunately, the presented papers cannot be downloaded from a central location but are beeing shared via email between the attendees. To make at least our contribution available to the public you can download the paper as well as the presentation slides right here.

Still, two more days full of interesting sessions to come.

Downloads

• Position Paper: Primary Storage Formats for Textual DSLs
• Presentation Slides: Primary Storage Formats for Textual DSLs

Automatische Whitebox-Tests für .net

Das Projekt Pex (Programm EXploration) soll den manuellen Aufwand bei der Gestaltung von Unit-Tests im .net-Umfeld signifikant verringern.

MDSD Today

Von morgen bis Freitag findet in Elmshorn die MDSD today 2008 an der Nordakademie statt. Auch über Xtext wird bei dieser Gelegenheit gesprochen. Peter und Sven erzählen uns, warum textuelle DSLs Freiheit bedeuten und Schmetterlinge im Bauch flattern lassen…

Dokumentation zu Ecore

Als Bestandteil des Eclipse EMF findet das (Meta-) Metamodell Ecore an vielen Orten Erwähnung. Leider bleibt es dabei häufig nur bei dessen Nennung. Neben pragmatischer Dokumentation auf den Seiten von Eclipse könnte die Arbeit “Vergleich von Metametamodellen” von Marcel Hoyer ein wenig Hintergrundwissen bieten.

Lexerregeln in Xtext

Möchte man eigene Lexerregeln in oAW Xtext erstellen, geht das über sogenannte Native rules. In der TMF Xtext-Version, an der wir derzeit arbeiten, funktioniert das mit den Lexer rules schon deutlich besser. Insbesondere in Kombination mit Return Types und eigenen Value Convertern gewinnt dieses Feature spürbar an Wert.

Xtext im Standalone-Editor

Gerade wenn das Tagesgeschäft nicht mit Eclipse realisiert wird, stellt sich die Frage, wie man in den Genuss des generierten Xtext-Editors kommen kann ohne auf Eclipse umsatteln zu müssen. Eine Antwort darauf bieten die Seiten zur Produkterstellung und zum -Export in der Hilfe von Eclipse. Schließlich handelt es sich bei dem Editor um ein einfaches Eclipse-Plug-in.