Jump to: navigation, search

Difference between revisions of "AMW FAQ"

Line 20: Line 20:
 
[http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/AMW/org.eclipse.weaver.doc.user/web/gs/tutorial/use_wizard.html AMW wizard] proposes to choose one root element.
 
[http://dev.eclipse.org/viewcvs/indextech.cgi/org.eclipse.gmt/AMW/org.eclipse.weaver.doc.user/web/gs/tutorial/use_wizard.html AMW wizard] proposes to choose one root element.
  
class Model extends WModel {
+
class Model extends WModel {
   
+
 
     -- @subsets wovenModel
 
     -- @subsets wovenModel
 
     reference leftModel container : WModelRef;
 
     reference leftModel container : WModelRef;
Line 48: Line 48:
  
 
====WElementRef====
 
====WElementRef====
 +
The ''WElementRef'' extensions are the elements that ''point'' to the elements of the woven models (woven elements). The weaving model has one ''WElementRef'' for every woven element.
  
 +
The ID of the woven element is stored in the ''ref'' attribute. The format of the ID depends on the type of the containing ''WModelRef''. The exact type of the ''WModelRef'' is specified in the ''wmodelRefType'' annotation. This annotation is necessary because a ''WElementRef'' element may be referenced by different ''WModelRef''s.
  
 
  -- @wmodelRefType ModelRef
 
  -- @wmodelRefType ModelRef

Revision as of 09:08, 2 March 2007

< To: AMW

This is the AMW wiki FAQ.

How to create weaving metamodel extensions?

The AMW prototype is developed based on the core weaving metamodel. The weaving metamodel extensions that are used by the prototype must extend this core, or extend other weaving extensions.

We illustrate the development of metamodel extensions using the metamodel extension. This extension is the simplest extension provided by the weaver, supporting generic link management.

The following classes of the core metamodel can be extended: WModel, WModelRef, WElementRef, WLink, WLinkEnd, WElementRef.

WModel

The WModel extensions are the root element of a weaving model. The references leftModel and rightModel refer to the woven models. They must subset the wovenModel reference from the core weaving metamodel.

The subsets annotation means that these references are derived from the wovenModel reference. The AMW prototype uses this annotation to load the woven models correctly.

If a weaving metamodel has more than one extension of WModel, the second page of the AMW wizard proposes to choose one root element.

class Model extends WModel {

    -- @subsets wovenModel
    reference leftModel container : WModelRef;
    
    -- @subsets wovenModel
    reference rightModel container : WModelRef;
}

Obs.: The annotations must be defined after a blank line. This is due to some limitations on the parser.

WModelRef

The WModelRef extensions are used to identify the woven models. A different extension to WModel must be created for every different identification mechanism that we want to support. For instance, the ModelRef class is used to identify model elements through XPointers, and ModelRefXMI uses XMI IDs.

When creating a weaving model using the AMW wizard, the user selects the WModelRefs he wants to create in the third page of the AMW wizard. This page is also used to set up the ref attribute. This attribute stores the URI of the woven models.

The -- @welementRefType ElementRef annotation indicates the type of WElementRef that is created in the ownedElementRef reference.

-- @welementRefType ElementRef
class ModelRef extends WModelRef {
}

-- @welementRefType ElementRefXMI
class ModelRefXMI extends WModelRef {
}	

WElementRef

The WElementRef extensions are the elements that point to the elements of the woven models (woven elements). The weaving model has one WElementRef for every woven element.

The ID of the woven element is stored in the ref attribute. The format of the ID depends on the type of the containing WModelRef. The exact type of the WModelRef is specified in the wmodelRefType annotation. This annotation is necessary because a WElementRef element may be referenced by different WModelRefs.

-- @wmodelRefType ModelRef
class ElementRef extends WElementRef {
}	

-- @wmodelRefType ModelRef
class ElementRefXMI extends WElementRef{
}

WLink

class Link extends WLink {
 
   -- @subsets end
   reference left container : WLinkEnd oppositeOf link;

   -- @subsets end
   reference right container : WLinkEnd oppositeOf link;
}

WLinkEnd

class LinkEnd extends WLinkEnd {
}	

What are the dependencies of AMW? Which are the other plugins that should be installed?

AMW depends on two plugins from ATL and AM3 plugins:

  • org.atl.eclipse.engine
  • org.atl.eclipse.km3

However, it is advisable to install all ATL and KM3 plugins, because AMW contains complex scenarios that use all the components of the AMMA platform, such as ATL transformations, or AM3 Ant Tasks.

Where can I find more information about the model management tasks used in AMW examples?

More information can be found in the AM3 Ant Tasks page.

Which version of AMW, AM3 and ATL should be installed to avoid version problems?

The required versions of the three plugins are mentioned in the corresponding download pages: AMW, AM3, ATL.

Why the menu "Extract ATL-0.2 model into ATL-0.2 file" does not appear when I try to extract an ATL model that was created from a weaving model?

Specific extraction and injection menus are available only in the "AM3 Resource Navigator", not in the "Package Explorer" view.

Why I have an "antlr/tokenstream" error?

AMW depends on the ATL plugins. So the ATL engine must be installed follwing the ATL installation guide. This error happens because the ATL engine cannot find antlr.jar. This file must be copied in "lib" folder of "org.atl.eclipse.engine" plugin.

How to develop higher-order transformations to transform a weaving model into a transformation model?

This answer uses the ForeignKey2Nested example as illustration.

The main requirement is to know well the input metamodel (the weaving metamodel) and the output metamodel (the ATL metamodel). The weaving metamodel varies according to the application scenario. The ATL metamodel is fixed.

In the example, the weaving metamodel is created based by the right metamodel, i.e., with nested structure. The weaving model has "Nested" subjects (which is under a link between "BookRcd" and "Book"). Then, we have the input values as equality of "FK"s.

So, usually there are extensions of "WLink"s and "WLinkEnd"s in the weaving metamodel, and rules, input and output patterns in the ATL metamodel.

Consider this simple example:

module A2B;
create OUT : B from IN : A;

an ATL has a "Module" as root element. A module has a "name". Than it has the input and output models and metamodels (In, A, OUT, B).

After that, a module contains a set of rules:

rule A2B { <- this corresponds to a "rule" in the ATL metamodel

from
  in : A!Class  <- this is the "input pattern"
to
  out : B!Table ( <- this is the "output pattern"
     name <- in.name,     <- these are the "bindings"
     value <- in.value    <- bindings
  )
}

The initial part (module and input models), is usually fixed, so they can be created using a single rule.

- The rules will be based in the weaving model, so WLinks and its extensions in rules. In the keys to nested example, this corresponds to the "ElementLink" element. - The input pattern is a "left" WLinkEnd. - The output pattern is a "right" WLinkEnd.

The bindings are child links ("Equals" are bindings).

Finally, one hint to better understand the ATL metamodel (that is a key point) is to write a simple transformation by hand and to click over some element in the debug mode. The outline in the right shows the corresponding model elements.

Why the weaving panel raises an exception when I create a new weaving model using an Ecore metamodel and not a KM3 extension?

It is not possible to extract a weaving metamodel that was completely created in KM3 (mwcore + extension) using the AM3 menus. The weaving metamodel contains specific annotations that are not yet handled by the injector (this will be corrected).

To be able to load a weaving metamodel from an Ecore file, it is necessary to extract the metamodel using the menus available in the weaving panel.