...

1. Create a new Empty EMF Project named de.cau.cs.rtprak.login<login>.turingmodel. Remember to create the project in your Git repository if you're working with one. Once you click the Finish button, the Empty EMF Project wizard creates a new plug-in project for you, complete with a src folder for Java source files, the MANIFEST.MF file we have encountered before, and, most importantly, a models folder that you will store your modeling files in. If you open the manifest file in the Plugin Manifest Editor, you will see that the wizard already added a dependency to org.eclipse.emf.ecore, which all EMF projects depend on.
2. Create a new Ecore diagram Model in the models folder by right-clicking the folder and clicking clicking New   -> > Other..., and then selecting Ecore Diagram from the Ecore Tools category. Note that the category Other also contains an entry Ecore Diagram. However, the editor we will be using has more features and is more user-friendly than the one in the Other category.
3. In the New Ecore Diagram wizard, check Create a new model and choose turingmachine.ecore as the Domain file name. Once you click Finish, the wizard will generate two files for you:
   
   • turingmachine.ecore contains the information about the data structures in your Turing Machine models. In effect, it is your metamodel in Ecore format.
   • turingmachine.ecorediag is the diagram you're editing and contains things like coordinates of the different data structures, and bend points of the relations between them – in short, everything the graphical editor needs to know to display the diagram.
4. You will need the Properties view to edit your model properly. This view shows detailed information about the currently selected model element and lets you edit them. It also shows general information about the model if no specific element it selected. Summon the Properties view now by right-clicking into your diagram and selecting Show Properties View.
5. Now that the Properties view is visible, switch to its Model tab and set the following properties:
   
   • Name: Model elements are grouped into packages, and this is the package name. Set to turingmachine.
   • Ns Prefix: Namespace prefix that will be used in the XML representation of your models later on. Use something short, e.g. turing.
   • Ns URI: While the package name need not be unique, namespace URI's are used to uniquely identify stuff. The usual convention is to use a name following the format http://project_name_part/packagename. Thus, set this to something like http://de.cau.cs.rtprak.login/turingmachine.

Modeling Your Turing Machines

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 information 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?

Model Elements

You will need the following Ecore model elements:

• EClass – Create one for every item that you want to be in your model. Make sure that you have exactly one root element, that is, an element that represents your Turing Machine (perhaps TuringMachine would actually be a good name for it...) and provides access to other elements.
• EAttribute – Add attributes to classes to give them properties, e.g. a name attribute for states in state machines. The most important property of attributes is their type, which you can configure in the Properties view.
• EEnum – Create enumerations to define simple enumeration types that you can then use as the type of attributes. Each item of the enumeration is an EEnumLiteral.
• Inheritance Relations – Use these as you would in UML class diagrams or ye plain ol' Java.
• EReference – Use references to provide links between classes. Here's a few things about references:
  
  • Every class (except the root class) requires exactly one Containment reference that specifies where it belongs to and where it will be stored later on when you save your models to XML files.
  • Set lower and upper bounds on references to control how many instances of a class can be referenced (just like multiplicities in UML class diagram associations).
  • Consider whether a reference should have an opposite reference: a second reference in the other direction to be able to navigate back and forth between the model objects. Let's take two classes as an example to illustrate this: Parentand Child, where Parent can reference multiple Child objects. To be able to ask the Parent about all its children, we would add a reference children from Parent to Child with the containment flag active (that is, Child is part of itsParent). To be able to ask a Child about its Parent, we would add a second reference from Child to Parent with the EOpposite set to the children reference.

For this task, you won't need any more model elements.

...

1. selecting Ecore Model from the Eclipse Modeling Framework category. 
2. In the Ecore Model Wizard name your model turingmachine.ecore. The wizard will then create a new Ecore model file for you. Open the model file and select the unnamed package in it.
3. You will need the Properties view to edit your model properly. This view shows detailed information about the currently selected model element and lets you edit them. It also shows general information about the model if no specific element it selected. Summon the Properties view now by right-clicking into your diagram and selecting Show Properties View.
4. Now that the Properties view is visible, switch to its Model tab and set the following properties:
   
   • Name: Model elements are grouped into packages, and this is the package name. Set to turingmachine.
   • Ns Prefix: Namespace prefix that will be used in the XML representation of your models later on. Use something short, e.g. turing.
   • Ns URI: While the package name need not be unique, namespace URI's are used to uniquely identify stuff. The usual convention is to use a name following the format http://project_name_part/packagename. Thus, set this to something like http://de.cau.cs.rtprak.<login>/turingmachine.

Modeling Your Turing Machines

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 information 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?

Model Elements

You will need the following Ecore model elements:

• EClass – Create one for every item that you want to be in your model. Make sure that you have exactly one root element, that is, an element that represents your Turing Machine (perhaps TuringMachine would actually be a good name for it...) and provides access to other elements.
• EAttribute – Add attributes to classes to give them properties, e.g. a name attribute for states in state machines. The most important property of attributes is their type, which you can configure in the Properties view.
• EEnum – Create enumerations to define simple enumeration types that you can then use as the type of attributes. Each item of the enumeration is an EEnumLiteral.
• Inheritance Relations – Use these as you would in UML class diagrams or ye plain ol' Java.
• EReference – Use references to provide links between classes. Here's a few things about references:
  
  • Every class (except the root class) requires exactly one Containment reference that specifies where it belongs to and where it will be stored later on when you save your models to XML files.
  • Set lower and upper bounds on references to control how many instances of a class can be referenced (just like multiplicities in UML class diagram associations).
  • Consider whether a reference should have an opposite reference: a second reference in the other direction to be able to navigate back and forth between the model objects. Let's take two classes as an example to illustrate this: Parentand Child, where Parent can reference multiple Child objects. To be able to ask the Parent about all its children, we would add a reference children from Parent to Child with the containment flag active (that is, Child is part of itsParent). To be able to ask a Child about its Parent, we would add a second reference from Child to Parent with the EOpposite set to the children reference.

For this task, you won't need any more model elements. You can add these model elements by right-clicking at a package or class and selecting New child... or New Sibling...

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.

Alternative route - Graphical creation of your metamodel

It is entirely possible to model your metamodel graphically. Since the graphical editing of EMF models has changed in the last Eclipse version, this is only mentioned here as alternative route. To generation an Ecore Diagram proceed as mentioned before. Now, right-click on your model file and select Initialize Ecore Diagram... from the context menu. Create a new Design -> Entities representation and select your package in the following step. You can now create all and link all the model elements mentioned in the section before. The changes will be integrated in your Ecore model automatically. However, as mentioned before you don't need to edit your model graphically. This procedure is only described for the sake of completeness.

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...

...