Unidirectional Model Transformation with eMoflon::TIE-GT
In this handbook, you will learn how to specify programmed, unidirectional model transformations with eMoflon::TIE-GT. If this sounds just like an academic buzzword to you, don’t worry!

Some background information: eMoflon:TIE-GT is a tool for specifying unidirectional model transformations of Eclipse Modelling Framework (EMF) models based on the Democles pattern matching engine. In our first handbook +Meta-Modelling with eMoflon::IBeX, we got to know the puzzle game Sokoban and spent some time learning how to meta-model it with EMF and eMoflon::Core. 
In this handbook, we’ll be concentrating on patterns, 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). Alongside with that, we will present how to implement the control flow, which defines the execution order of graph transformation rules to validate the Sokoban boards as well as to execute moves correctly.

✈️ Some starting assumptions we make

  • You have completed our first handbook and thus have an installed eMoflon::Core 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 (you’ve been warned).
  • 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

You got in touch with the Sokoban GUI at the ending of the meta-modelling handbook. let’s take some time to find out what features we’ll be improving in this handbook.

  1. Import the initial team project set (Import… → Team/Team Project Set).
  1. Your workspace now contains two projects: SokobanGUI and SokobanLanguage.
  1. Start the Sokoban GUI by right-clicking SokobanGUI/SokobanGUI.launch and selecting Run as → SokobanGUI.

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.

A game without rules

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 only valid moves are executed (you can move anything to anywhere right now in play mode) using graph transformation rules

Go ahead, check out the prepared workspace eMoflon::TIE-GT Handbook, and open SokobanRules.java (project SokobanGUI, package org.moflon.tutorial.sokobangamegui.rules) 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 plain Java, operating on the EMF objects (Figure figure, Field 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.

Project setup 

Next, create a new eMoflon::TIE-GT project named SokobanRules. Please make sure that an Emfatic project (*.emf) is selected, and then press Finish.
Now, copy everything below the line package SokobanLanguage; from SokobanLanguage/model/SokobanLanguage.emf to SokobanRules/model/SokobanRules.emf. If you save the .emf file now, eMoflon should place generated code in SokobanRules/gen. 

In the remainder of this handbook, we will be working with SokobanRules (instead of SokobanLanguage). The reason for working with only one project is that eMoflon::TIE-GT allows you not only to generate classes and packages, but also to specify the implementation of operations! Go ahead and open the manifest file SokobanGUI/META-INF/MANIFEST.MF, remove the dependency to SokobanLanguage, and add the dependency to SokobanRules, as shown in the following screenshot. You can now close SokobanLanguage (Right-Click → Close Project).

The SokobanGUI project will now contain compile errors because its code references classes from the package SokobanLanguage. This problem can be solved quickly as follows: Select the folder SokobanGUI/src, open Search → Search (Ctrl+H), and replace “SokobanLanguage” in all .java files of the “Resource selected in ‘Package Explorer’” with “SokobanRules, as shown in the following screenshots.
This is a useful trick that can also help you when you are renaming packages etc. because Emfatic does not offer any refactoring support.

A final note on the SokobanRules project: You can, of course, start immediately with a fresh eMoflon::TIE-GT project when creating your own fancy project. This section shows you how to transition from an eMoflon EMF project to an eMoflon::TIE-GT project.

Creating a validator for boards and moves

(introducing operations in Emfatic, .gt files, and .mcf files)

OK, now let’s start to implement our first validation rule: a board shall contain one sokoban. We start with the relaxed condition that a board shall contain at least one sokoban. We will implement this check in a separate class called SokobanValidator.
Open the file SokobanRules/model/SokobanRules.emf and insert the new class SokobanValidator. In addition, specify two operations (more precisely: EOperations, but we call them operations in the following for short):
@GenModel(documentation="Validates board states and moves")
class SokobanValidator {