...

As we have already seen, everything in EMF begins with the metamodel. Metamodels can be imported from specified in different formats: XSD (XML Schema Definition), UML, Ecore models,... In this tutorial, we will be using Ecore diagrams models to specify our metamodels. Take a moment to think about this: we're creating an Ecore model by drawing a diagram, and this model will then be used as the metamodel for our Turing Machine models. So, let's start by creating an Ecore diagram.

...

Now that we have an empty Ecore diagram it's time to get to the interesting part: defining the metamodel for your Turing Machines. You will later write a simulator that will execute Turing Machines specified as models following this metamodel; keep that in mind while designing the metamodel. This is a complex and interesting task that will require some thought on your part. Feel free to discuss this with other participants: talking about a problem with other people usually leads to better designs and helps you think about problems that you might have overlooked otherwise. Here's some first suggestions for design decisions you're facing to get you started:

• Do you model the state machine? If so, what distinguishes initial states from regular statesinformation do you need to specify states and transitions?
• How will your simulator know which state to start in?
• Do you model the Turing Machine's tape?In what detail do you model transition labels? Simple Strings, or more complex expressions over the input alphabet?

Model Elements

You will need the following Ecore model elements:

...

One last thing before you get started: While working on your model, save and validate it regularly (Edit -> Validate). This will help you find potential problems with your model while you're still able to fix them easily.

Code Generation

 In order to work with the data structures you specified in your metamodel conveniently, the model must be translated into Java code. For this purpose EMF provides a Java code generation facility that takes the metamodel as its input. Hence, you need a metamodel specified in one of the supported formats. Luckily, Ecore models are a supported format...

The Ecore model, however, is not sufficient to generate the code since it does not contain any information about, e.g., where the code is to be generated. Therefore EMF uses generator models to preserve such information. Here, we will create such a model from our Ecore model automatically.

Generating a Generator Model

1. Add a new EMF Generator Model to the model folder. Give it the same name as the Ecore model, but choose .genmodel as the extension. Choose Ecore model as the importer and select your Ecore model file. Make sure your turingmachine package is selected and click Finish. You get a new model file, which is mainly a copy of the Ecore model augmented with additional information required for code generation.
   Note: The generator model file is now synchronized to the Ecore model file, which in turn is synchronized to the Ecore diagram file. Once the generator model is created, changes in the diagram will also be applied to the generator model, removing the need for you to regenerate the generator model every time you change something in the original model.
2. Open the generator model, select your package, and open the Properties view.
3. Enter a meaningful Base Package, that is, the package where the generated Java classes will be placed in. A meaningful package name would be the project name.

Generating the Code

This is a very laborious task:

1. Right-click the root node in the tree editor and click Generate All.
2. Wait.

EMF should now have generated (automatically and hopefully without errors) code in folders and even new projects for you:

• Folder src of the original project: This is the Java implementation of your metamodel. The most important code. It allows to instantiate your model.
• Project ...edit: This project contains helper classes for eclipse to present model elements in Eclipse widgets like tables, trees, etc.
• Project ...editor: This is a ready-to-use tree editor for model instances of your metamodel. (Nothing graphical though...)
• Project ...tets: This is a set of skeletons for JUnit tests for your model. However, you have to implement the test methods yourself. We won't use it now, but feel free to have a look at it.

Note that the generated code is not synchronized to your models. If you make changes to your models, you have to re-generate your code. If you don't take care, manual changes in the generated code will get lost.

Launching the Tree Editor

You will of course be anxious to try out your new tree editor:

1. Launch an Eclipse application with all your workspace plug-ins.
2. In the new Eclipse instance, create a new empty project.
3. Create a new model instance (File -> New -> Other -> Example EMF Model Creation Wizards -> Turingmachine Model), choosing your root element as the model object.
4. Edit the model with the tree editor. Use the context menu to create new child elements, and the Properties view to configure elements.
5. Save the model.
6. Open the file with a text editor (your simple text editor, for example: right-click the model file and use the Open with menu).
7. To prepare for the next task, copy the model file you just created to your original developer workspace, into the root folder of the project where your model files are stored.

Saving and Loading Models

...

This is where all the model design and model generation pays off and where we will establish the link to the first second tutorial: you will write an IHeadController implementation that can simulate Turing Machines specified as models following the metamodel you just designed. Your simulator should be able to execute arbitrary instances of your metamodel.

...

1. Add a new class to one of your plug-ins named TuringHeadController. Make sure it implements the IHeadController interface we defined in the first second tutorial and register it with the appropriate extension point.
2. Add a new method initialize() to your controller that loads a Turing Machine model from a fixed path.
3. Implement the nextCommand() and reset() methods:
   
   • You can access all references and attributes of model elements using generated getter methods.
   • reset() selects a state that is marked as being an initial state of the Turing Machine and saves it as the current state in a private field of the controller. (You did think about modeling initial states, right? If not, don't be frustrated, that's not too big of a deal. Just make the necessary changes to your metamodel and regenerate the code.)
   • nextCommand() analyzes the outgoing transitions of the currently active state and takes the first one that matches the current character. It then selects the target state of that transition as the new active state and returns the actions of the transition as HeadCommand. If there is no transition that matches the current input, return a command that does nothing.
   • At the beginning of nextCommand(), check if there is an active state. If not, call initialize() and reset() before doing the simulation.
   • Remember that if you add the new controller to the de.cau.cs.rtprak.login.simple plug-in, you will have to add a dependency to the ...turingmodel plug-in and make sure the latter exports the required packages.

...

1. Create a Turing Machine model using the tree editor. Assuming that the initial head position is 1, the machine shall copy the input text infinitely often. That is, if the tape initially contains the word "hello", the machine should generate "hellohellohellohe..." You might remember this task from the first second tutorial. To avoid an explosion of the number of states, select a rather small input alphabet for your machine, e.g. h, e, l, and o.

2. Save the model to the fixed path defined in your controller.

3. Select the new head controller in the Tape view and test it with input from your editor.

...