UUID from simulink blocks is ignored by EcoreCreator.m

[GoogleCodeExporter]

To reproduce the problem:
1. Convert a model from ecore to simulink
2. Convert it back from simulink to ecore with a new filename.

The UUID for the same element should have the same UUID.

Each time an ecore model is created, new UUIDs are generated.
To solve this, you need to modify setUUIDinUserData, in Utils.m.

One problem is the repository in EcoreModelCreator.java, that will still 
include a key with the old UUID.

Original issue reported on code.google.com by alex%sch...@gtempaccount.com on 8 Apr 2010 at 4:39

[GoogleCodeExporter]

One solution to the repository problem (in EcoreModelCreator.java) is to use 
the 
Observer pattern , where ProtoObject notifies the repository when its UUID has 
changed.

Look into org.eclipse.emf.common.notify for this functionality. Section 15.3 in 
the 
book, page 395.

In EMF terminology, ProtoObject is the notifier, and the repository is an 
Adapter.

Original comment by alex%sch...@gtempaccount.com on 9 Apr 2010 at 7:17

[GoogleCodeExporter]

Here there is some background info, but no examples.
http://sites.google.com/site/zhaochenting2/designpatterninemf

Quoted from there:

  The notifier system is already build by EMF, however, how can I create a class to 
be the observer of an EMF model class? It’s very easy. You just need to have 
your 
class implement Adapter interface. 

The adapter class should have a notifier class target as a attribute, and 
implement 
get/setTarget(), isAdapterForType(Object), and the most important method: 
notifyChange(), this method receive a notification as a parameter. In the 
method, you 
can switch the featureId in the notification to do corresponding update of your 
own 
information.

// Adapter interface definition
interface Adapter{  
   private Notifier target;
   public setTarget(Notifier target);
   public Notifier getTarget();
   public boolean isAdapterForType(Object type);
   public void notifyChange(Notification notification);
}

Then you need to use the eAdapters().add() method of your considering model to 
put 
this adapter into the list of the model observer. 

Original comment by alex%sch...@gtempaccount.com on 9 Apr 2010 at 7:37

[GoogleCodeExporter]

Example:

An observer can be attached to any EObject (for example, book) by adding to the 
eAdapters 
list like this:

  Adapter bookObserver = ...
  book.eAdapters().add(bookObserver);

To handle notifications in an adapter we need to override the eNotifyChanged() 
method, 
which is called on every registered adapter by eNotify(). 

A typical adapter implements eNotifyChanged() to perform some action for some 
or all of 
the notifications, based on the notification's type.

Sometimes adapters are designed to adapt a specific class (for example, Book). 
In this 
case, the notifyChanged() method might look something like this:

  public void notifyChanged(Notification notification)
  {
    Book book = (Book)notification.getNotifier();
    switch (notification.getFeatureID(Book.class))
    {
      case LibraryPackage.BOOK__TITLE:
        // book title changed
        doSomething();
        break;
      caseLibraryPackage.BOOK__CATEGORY:
        // book category changed
        ...
      case ...
    }
  }

Original comment by alex%sch...@gtempaccount.com on 9 Apr 2010 at 8:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

EMF's EStructuralFeature and EAttribute are subclasses of EObject, and thus 
implement 
the Notify interface.

This might mean, that I could use the observer pattern with a single attribute 
instead 
of the whole object...

Original comment by alex%sch...@gtempaccount.com on 9 Apr 2010 at 8:15

[GoogleCodeExporter]

Another implication of this is that the blocks in the Simulink Ecore library 
and model file needs to be changed and updated before each transformation.

Original comment by carljoha...@gmail.com on 16 Aug 2010 at 8:11