Unidirectional Model Transformation with eMoflon::IBeX
Learn how to specify unidirectional model transformations with eMoflon::IBeX-GT

eMoflon::IBeX-GT is a tool for specifying unidirectional model transformations of EMF models using graph transformation and incremental pattern matching based on the Democles pattern matching engine.  It is integrated into the eMoflon::IBeX toolsuite, which also supports bidirectional transformations via Triple Graph Grammars.  In our first handbook +Meta-Modelling with eMoflon::IBeX we got to know the puzzle game Sokoban and spent some time learning how to metamodel it with the Eclipse Modelling Framework (EMF) and eMoflon::Core.  In this second part of our handbook we’ll be concentrating on graph constraints which we’ll be using to validate Sokoban boards, and graph transformations which we’ll be using to move Sokoban around and push boxes correctly (according to the rules of the game or its semantics).   

✈️ Some (starting) assumptions we make

  • You’ll start with a fresh workspace. Yes, we know you’d like to perhaps continue where you left off, but if you do so you’re on your own so don’t complain later (you’ve been warned).  The problem here is that each handbook starts off with a particular version of the workspace and some of the same projects.  Eclipse refuses, however, to import projects that already exist in the workspace so your old versions of projects won’t get updated.  So please — just take a fresh workspace for every handbook.
  • You avoid white spaces and umlauts in the path to your Eclipse workspace, especially on Windows.

Get to know the Sokoban GUI a bit better

Although you tried out our Sokoban GUI at the ending of the previous handbook, let’s take some time to find out what features we’ll be improving in this handbook.  In your fresh workspace, go ahead and check out the prepared workspace I. Sokoban Example: 2 from our eMoflon cloud drop-down menu (The Team Project Set file is also available here).  Start the GUI as described in the first handbook.  Recall that you can create blocks, boulders, and Sokoban figures by right-clicking a field and making the appropriate choice in the pop-up menu:
After populating a board to your liking, you can start the game by choosing File → Play Game!
This transitions from the edit mode to the play mode. In the play mode, you can choose items by clicking on them, and then move them by clicking the destination field.  If you feel like editing the board again, you can always transition back to the edit mode by choosing File → Edit.  Finally, you can clear the current board, as well as create a new board with dimensions of your choice.

Validating models using graph constraints

When switching from edit to play mode, notice that a reassuring “Everything seems to be ok…” is displayed in the status bar.  This is nice but not really true at the moment.  You can create all kinds of silly boards right now and still be able to “play” with them.  In the first part of this handbook, we’ll learn how to use graph constraints to validate our boards and prevent users from transitioning to the play mode if the board doesn’t make sense (with respect to the rules of Sokoban).  Later in the handbook we’ll also check that valid moves are only executed (you can move anything to anywhere right now in play modus) using graph transformation rules

Open SokobanRules.java in the SokobanGUI project to inspect the two relevant FIXMEs we’ll be handling very soon:
Note that you could directly program the required checks in good old Java code, operating on the EMF objects (Figure, Field) directly.  Go ahead and do this if you want to and just can’t help yourself.  The whole point of using a standardised modelling framework such as EMF is, however, that you can use a suitable declarative language to do this instead:     

Create an eMoflon Graph Transformation Project via the red/green project button in the toolbar (only visible in the eMoflon perspective):
Enter SokobanRules as project name and click Finish:
Rename the automatically generated Rules.gt file to BoardPatterns.gt, open it, and delete the default contents of the file.  Now type import and use code completion (Ctrl+Space) to obtain the suggested URI to your meta-model SokobanLanguage and hit enter:

Create your first pattern by entering the following (we’ll explain the syntax in a moment). Remember to hit ctrl+space wildly and constantly for code completion.  Also note that the outline and visualisation are populated with your new pattern, and that you can also choose the type Sokoban and press F3 to navigate to the relevant EClass in your metamodel:

pattern oneSokoban {
  sokoban: Sokoban

You might have noticed that the project has some compilation errors.  To get rid of them add the meta-model project as a dependency by opening the META-INF/MANIFEST.MF file:
Then, click on “Dependencies”:
and selecting SokobanLanguage from the drop-down menu.  Accept by clicking OK and save the file.  If you did everything right the project should compile now.  If this is not the case make sure you’ve enabled “Build Automatically” (under Project in the Eclipse menu bar) and try refreshing, cleaning, and building all your projects from scratch.

Let’s now use our pattern to check if a board has at least one Sokoban on it.  If it does not, then there’s really no point in trying to play Sokoban with it, right?  Go ahead and create a new Java class SokobanValidator next to the BoardPatterns.gt file with the following contents:

package SokobanRules;

import java.io.File;
import org.eclipse.emf.common.util.URI;