Unidirectional Model Transformation with eMoflon::IBeX
Learn how to specify unidirectional model transformations with eMoflon::IBeX-GT
Sokoban(warehouse keeper)
eMoflon::IBeX-GT is a tool for specifying unidirectional model transformations of EMFmodels using graph transformation and incremental pattern matching based on the Democlespattern 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 have completed our first handbook +Meta-Modelling with eMoflon::IBeX and thus have an installed IBeX and know your way around a bit.
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. SokobanExample: 2from 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 choosingFile → 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 graphconstraints 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.
OpenSokobanRules.javain 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 fileto BoardPatterns.gt, open it, and delete the default contents of the file. Now type import and use code completion(Ctrl+Space) to obtainthe 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 addthe meta-model project as a dependencybyopening theMETA-INF/MANIFEST.MFfile:
Then, click on“Dependencies”:
and selectingSokobanLanguage 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.gtfile with the following contents:
✈️ Some (starting) assumptions we make
Get to know the Sokoban GUI a bit better
Validating models using graph constraints
pattern oneSokoban { sokoban: Sokoban}package SokobanRules;
import java.io.File;import org.eclipse.emf.common.util.URI;