EMF Model Transactions

EMF III – Seminar Paper02162 Software Engineering 2

Written byMartin Bouladour (s081034)Olga Dmitricenko (s061242)Mohamed Gasmi (s081195)

DTU - IMM -2008

Eclipse Model Framework III

Table of Contents

1 Command Factory ............................................................................................................ ........... 4

2 Editing domains and commands ................................................................... ............................ 5

2.1 Example ...................................................................................................... ........................... 6

2.2 Creating commands .................................................................................. ............................. 7

2.3 Overriding Commands ...................................................................................................... ...... 8

3 Transactions ......................................................................................................... .................... 10

4 Multithreading ................................................................................................................... ......... 11

4.1 Yielding Read-only Transactions .................................................................................. ......... 11

4.2 Sharing Read/Write Transactions ........................................................... .............................. 11

5 Model Transaction Tutorial ................................................................................... .................... 12

6 Conclusion .......................................................................................................................... ....... 16

2 / 1 6


Introduction

The Eclipse Modeling Framework (EMF) is in many ways a step toward in model driven architecture (MDA), you can specify a model and implementations are done automatically. The EMF combine in itself UML, Java and/or XML technologies, it provides a way of converting one type of model into one of the mentioned before types. This EMF’s extensive code generator makes the development-process of applications more efficient and more model-focused.

This paper is a part of EMF seminar and is a 3rd and final. We recommend for better understanding at first to read EMF I and EMF II, because this paper is covering only the Model Transaction in EMF. The code generation with EMF is out of scope of this paper, for more information about Ecore see EMF II and more general overview is in EMF I.

All participants have reviewed all parts of the paper, each person in the group have been responsible for the following part:

• Introduction;

• Editing Domains and Commands;

• Transactions;

• Multi-Threading;

• Model Transaction Tutorial;

• Conclusion.

3 / 1 6


1 Command FactorySoftware developer can generate code with EMF framework, this code is simple and efficient. The code has only necessary components of the structure and the most important it is correct. The EMF models can be viewed using content and label providers, but in this paper we will talk about how to change, or edit, a model. The EMF.Edit framework support command-based editing of an EMF model, including fully automatic undo and redo.

The EMF framework commands could be divide into two categories: the common command framework and the EMF.Edit commands. The common framework defines basic/general command interfaces and provides some implementation classes like a basic command stack, those commands are independent from Edit.EMF and are implementation classes specifically for editing EObjects.(for more information about Ecore, see EMF II). It is commands like Add, Remove, CompoundCommand,etc.

The EMF.Edit includes a full set of generic command implementation classes that, using the reflective EObject API, provide support for any kinds of modifications to a model: SetCommand , AddCommand, RemoveCommand, MoveCommand ReplaceCommand, CopyCommand. In addition to the basic commands, the EMF.Edit command framework includes some higher-level commands that are built using the basic commands along with some of the classes from the common command component.

4 / 1 6


2 Editing domains and commandsAn editor accesses the model object via two read providers: A content provider and a label provider. This access is a read only access; These two providers can't be used to modify the model. Thus, an editor needs a write provider. As you can see on the picture below, the editing domain is the write provider. It uses a command stack.

An EditingDomain can manage one or more model. The models are maintained in the form of a ResourceSet object where each resource represents a document in which a model is stored. Among other things, it provides methods to browse the model (getChildren(), getParent(), treeIterator()) and to create commands (createCommand(), createOverrideCommand()). The CommandStack can be accessed via the getCommandStack() method.

A command stack is an undoable stack of commands. The CommandStack execute() method is used to execute a command within a stack.

Commands are used to modify a model. AddCommand, RemoveCommand and MoveCommand are examples of generic commands. A command can be tested for executability, it can be executed, it can be tested for undoability, it can be undone, and can then be redone. A command also provides access to a result collection, an affected-objects collection, a label, and a description.

Though the model can be directly accessed and modified, using commands to do so is much more better. Actually every modification must be done using commands. In this way, the EMF.edit framework provides all its functionalities (such as undo commands, etc.).

5 / 1 6


2.1 Example

Let assume we have a simple model as this one:

In our actual instance, there is a company that contains several departments. If we want to remove one department, we could simply write the following code:

Department d = ...Company c = ...c.getDepartments().remove(d);

In that way, the department is indeed removed from the company, and nothing else.

Now, let's do it using the EMF.edit remove command, the editing domain and its command stack:

Department d = ...Company c = ...EditingDomain ed = ...RemoveCommand cmd =

new RemoveCommand(ed, c, CompanyPackage.eINSTANCE.getCompany_Departments(), d);ed.getCommandStack().execute(cmd);

Here, the department is also removed from the company. However, deleting a department this way has one big advantage: The deletion can be undone using the ed.getCommandStack().undo() method.

Moreover, using commands and a command stack allows the stack to be checked to find out if a model is dirty or not, and commands validity can be tested before being executed (using the canExcecute() method of the Command interface).

6 / 1 6


2.2 Creating commands

In the previous example, the command we've created just remove a department from a company. If we want to create a more reusable command that can remove any kind of object, we can do that by using the editing domain's createCommand() method.

public interface EditingDomain {...Command createCommand(Class commandClass, CommandParameter commandParameter);...

}

To use this method, we need to create a CommandParameter object first, set command parameters into it, and then call the create method passing it the command class we want (for instance RemoveCommand.class) and the parameters.

To simplify the command creation, every command class contains a static convenience create() method. See:

Department d = ...EditingDomain ed = ...Command cmd = RemoveCommand.create(ed, d);ed.getCommandStack().execute(cmd);

This is just a small syntactic change (RemoveCommand.create() instead of new RemoveCommand), but there are fundamental differences. We only passed one argument (that is, the object being removed), aside from the editing domain, instead of the three arguments previously. Notice how this piece of code can now be used to remove any kind of object. By delegating the creation of the command to the editing domain, we're letting it fill in the missing arguments.

7 / 1 6


2.3 Overriding Commands

Now we can override existing commands to change the behaviour of the editor. Here is a simple model that implements the composite design pattern:

A box can contain things or other boxes, recursively. The root object of this model is a box.

In the generated editor, we can draw something like that:

Then, if we want to remove a box, the box and all the objects that it contains will be removed. It's the behaviour of the existing remove command of the framework.

Now, say we want to change this behaviour. When a bow is deleted, then all the objects it contains will be move in the parent box.

To do so, we have to replace the remove command of a box with a new command. This command will extends the CompoundCommand class. A compound command is a command that is composed of other commands. If the object to remove is a Box, this new command will first move the objects

8 / 1 6


contained in the box to the parent box (using RemoveCommand and AddCommand) and then will remove the wanted box. If it is a Thing, then the command will just remove that thing (using RemoveCommand).

The doExecute() method must be overridden

public class RemoveObjectCommand extends CompoundCommand {

private EditingDomain domain;private emf3.Object owner;private EStructuralFeature feature;private Collection<emf3.Object> collection;

// constructor that initializes the four instance variables:

public void execute() {Iterator<emf3.Object> it = this.collection.iterator();emf3.Object objectToRemove;// for each object to removewhile (it.hasNext()) {

objectToRemove = (emf3.Object)it.next();if (objectToRemove instanceof Box) {

// if the object is a Box,// then move its children to the parent BoxCollection<emf3.Object> children =

(Collection<emf3.Object>)this.domain.getChildren(objectToRemove);

this.appendAndExecute(new RemoveCommand(this.domain, objectToRemove,objectToRemove.eContainingFeature(), children));

this.appendAndExecute(AddCommand.create(this.domain, this.owner,this.owner.eContainingFeature(), children));

}// remove the objectthis.appendAndExecute(

new RemoveCommand(this.domain, this.owner, this.feature,objectToRemove));

}}

}

One naïve way to move the object is to directly modify the model (i.e. removing the objects from the contents collection of the box to be deleted, and then adding then to the contents collection of the parent box). However, doing so won't allow the user to undo that change (by doing undo, the removed box will be retrieved, but the children objects won't be moved back into it). That's why the EMF.edit commands has to be used.

Once the command is created, the createRemoveCommand() method of the ObjectItemProvider class must be overridden too, so that the command returned is the our RemoveObjectCommand.

public class ObjectItemProvider implements ... {

...

protected Command createRemoveCommand(EditingDomain domain, EObject owner,EStructuralFeature feature, java.util.Collection<?> collection) {

return new RemoveObjectCommand(domain, owner, feature,(Collection<emf3.Object>)collection);

}}

Now, when a box is removed, then all its contained objects are moved in the parent box.

9 / 1 6


3 Transactions The transaction component provides the following capabilities:

1. Multi-threading - Supports a protocol for clients to read and write EMF models on multiple threads.

2. Model Integrity - Semantic integrity is ensured by automatic validation to detect invalid changes and semantic procedures to proactively maintain correctness of semantic dependencies.

3. Batched Events - Clients are notified of groups of related changes in batches, rather than as a stream of EMF notifications. In particular, this allows applications to analyze change sets in their entirety.

4. Undo/Redo - For a simplified programming model, the API automatically tracks changes applied to models without the need for client code to use EMF edit Commands. These changes are encapsulated in transactions/operations that can undo and redo themselves.

5. Editing Domain - Support cooperative editing of models by multiple editors/applications. EMF resources can be shared amongst different editing domains.

6. Eclipse Workspace - The API provides traceability between EMF resources and workspace resources. Multi-threaded access is coordinated via the Eclipse jobs API and its integration with the workspace.

7. Eclipse Operations - The API supports the Eclipse operation history as an undo stack for undo/redo of resource changes. The API provides a framework for undoable operations that automatically capture undo/redo information, which can be interleaved on the same history with dependent operations that do not modify the EMF model.

A Transaction is a discrete unit of work in a ResourceSet. This work may be reading and writing the resource set contents or simply reading. Transactions provide model integrity guarantees:

• Isolation of concurrent threads to prevent data corruption;

• Validation of changes on commit, rolling back (undoing those changes) automatically when data integrity is violated;

• Automatic execution of triggers on commit, to proactively maintain data integrity.

1 0 / 1 6


4 MultithreadingA program or process can contain multiple threads that execute instructions according to program code. Like multiple processes that can run on one computer, multiple threads appear to be doing their work in parallel. The threads share the same address space; that is, they can read and write the same variables and data structures. In a multithreaded program, threads are obtained from the pool of available ready-to-run threads and run on the available system CPUs. The OS can move threads from the processor to either a ready or blocking queue. In Java programming to manage multithreads use lock. To prevent multiple accesses, threads can acquire and release a lock before using resources.

In EMF model the transactions are owned by threads. The initial owner of a transaction is the thread in which context it was created. For the duration of a transaction, the owner thread has exclusive access to the contents of the editing domain's resource set, except as described below. The EMF Transaction API provides two mechanisms for multiple threads to cooperatively share access to the resource set: yielding and privileged runnables. Both mechanisms maintain the single-threaded model of EMF by ensuring that only one thread at a time is ever reading or writing.

4.1 Yielding Read-only Transactions

The read-only operations are typically long running, for example validation or searching. For this kind of operation Eclipse provides the Job API and progress monitors to do work in the background and keep the user up to date about current situation.

The transactions in a TransactionalEditingDomain lock the resource set for exclusive access by a single thread; a read-only transaction that runs for a long time can affect the application's UI if refreshes require reading the EMF data. To improve the situation, the TransactionalEditingDomain provide a yield() method. This method suspend the current transactions to allow the next thread (if it is read-only thread) waiting for a read-only transaction to star. Yielding (suspending) any transaction to a writer would result in the data that a reader has already read being changed.

4.2 Sharing Read/Write Transactions

To complete the task threads are required to synchronously communicate with another thread, for example updating of UI widgets from background threads or jobs. It is required that all modification to widgets will be done on a thread designated as the Display thread.

When read/write transaction in progress and thread needs to execute code on the UI thread in a Display.syncExec() call, and this synchronous runnable need to read the resource set or modify it. The thread that owns a transaction can wrap an operation (encapsulated in a Runnable) in a privileged runnable. This privileged runnable, when executed on some other thread, borrows the original owning thread's transaction for the duration of its execution, the execution time is delegated to the wrapped runnable.

Privileged runnables can only be used with synchronous inter-thread communication mechanisms such as Display.syncExec(). The attempt of asynchronous runnables (as with Display.asyncExec()) will cause an illegal transaction state. This mechanism can be used for both read-only and read/write transactions, because it involves only a single transaction.

The privilege method differs from yield in being directed at a specific other thread, which then returns the transaction directly back to the original owner. There is not multiple independent threads creating transactions for their own purposes, but rather a thread that deliberately continues a synchronous operation on another thread during some interval. Note that a thread executing a privileged runnable can, in turn, lend the transaction to yet another thread via another privileged runnable. This can be repeated an arbitrary number of times, even cycling back to a thread that is already lending the transaction away in a privileged runnable.

1 1 / 1 6


5 Model Transaction Tutorial

Step 1: (Start the plug-in)

1 2 / 1 6


Step 2: (importing the example of the wires)

1 3 / 1 6


Step 3: (The example has been imported)

Step 4: (Bound the simulator with a dashboard diagram)

A: All the files of the example (Component Definition File / Diagrams / Dashboard …)B: The Dashboard viewC: The plug-in toolsD: The simulator manager

1 4 / 1 6


Step 5: (The Simulation board)

A: Create a new instance of simulationB: Start / Pause / Stop / One Step (simulation options)C: To choose a sensor (rainSensor / switch)D: To change the state of the sensorE: Set the simulation speed

Step 6: (Start the simulation)This is the simulation of the wire for a simulation speed (1 Step / Sec) and for a light rain.

Step 7: (Start the simulation)

1 5 / 1 6


6 ConclusionThis paper is giving an explanation of the EMF Model Transaction technology, both theoretical and practical approach. We have tried to explain, EMF as a useful way of software engineering with the focus on the model development compared to the actual programming. Describing how to use EMF build-in functions, like Domain Editing and Transactions, as well explaining the different approach of multi-threading managing in EMF.

If a reader would like to know more about EMF technologies, we can recommend the official book written by the developers of EMF: “Eclipse modeling framework: A developer’s guide”. The book writers uses a very practical approach by giving an explanation in examples of Java code and provide full references of EMF API. If reader are seeking more up-to-date information we recommend to visit Eclipse official web-page http://www.eclipse.org/modeling/emf/

1 6 / 1 6

http://www.eclipse.org/modeling/emf/

EMF Model Transactions

Documents

Transcript of EMF Model Transactions