AMW FAQ

< 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 {
}	

Obs.: This elements are not explicitly shown in the AMW prototype. They are automatically created after the wizard is executed.

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{
}

Obs.: This elements are not explicitly shown in the AMW prototype. They are automatically created when creating different WLinkEnd elements.

WLink

The extensions of WLink elements are of major importance in a weaving model. This is because these elements define the domain specific linking semantics. Usually, all new extensions of the weaving core have a different extension of WLink.

The Link below defines basic link management. It is used to link a left and a right elements. The WLink extensions may have references that subsets the end reference, e.g., the left and right references below. These references specify which kind of elements are linked, and their cardinality. A WLink can also have child links through the child reference.

There are many different kinds of links that can be defined, for instance Equality, Equivalence, Annotation, Merge, etc. Metamodels extensions with different kinds of links can be found in the weaving metamodel zoo.

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

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

WLinkEnd

The WLinkEnd elements specify the end points of a WLink. In other words, it indicates the type of elements that are linked. The reference element refers to the WElementRef elements, which contain the identifiers of the woven elements. The WElementRef are not referenced directly by WLinks because it is possible to refer the same woven model element by different link endpoints. For example, one model element may be linked by more than one WLink.

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.

Why when I select a WLinkEnd in the weaving panel, the corresponding element in the woven panel is not selected?

This happens due to one of the reasons below:

• The user created a weaving model with the wrong WModelRef elements. For instance, if the identification mechanisms used is XMI IDs, the weaving model must have ModelRefXMI elements, and not ModelRef elements (that uses XPointer).

• Now the woven resources are identified according to their URIs. Some examples were not yet updated to support this change. The user can do it by himself, by changing the value of the ref property of the woven models. The number before the URI is no longer used.

Old ref value:

<rightM xsi:type="_1:ModelRef" name="rightM" ref="1_/AMW_Match_ATL/models/BookNew.ecore">

New ref value:

<rightM xsi:type="_1:ModelRef" name="rightM" ref="/AMW_Match_ATL/models/BookNew.ecore">