VMTL supports model-to-model transformations on source models expressed using a host modeling language (e.g. UML, BPMN, or a domain-specific modeling language). The target model of a VMTL transformation may be expressed using the same or a different host modeling language.

The structure of VMTL transformations, the mapping of this structure to host modeling language constructs, and the operational semantics of VMTL are described in the following paragraphs.

In VMTL, a transformation consists of one or more rules. Each rule has an execution priority expressed as a positive integer, with 0 as a default value. Rules with higher priority take precedence over rules with lower priority. In case the highest priority is shared by several rules, one of the rules is randomly selected for execution.

In turn, VMTL rules consist of one or more patterns, where a pattern is a model fragment expressed in the host modeling language. The following patterns are defined:

• Find Patterns represent the left-hand side (LHS) of a rule. A rule may contain at most one Find Pattern. The role of the Find Pattern is to determine where a rule may be applied: each successful match of this pattern triggers a new execution of the rule.
• Produce Patterns represent the right-hand side (RHS) of a rule. A rule may contain at most one Produce Pattern. The role of the Produce Pattern is to modify the source model at locations where the Find Pattern is successfully matched in the source model, thus creating the target model.
• Update Patterns are concise representations resulting from merging the Find and Produce Patterns of a rule into a single pattern. A rule may contain at most one Update Pattern, if and only if it does not contain a pair of Find and Produce Patterns. Update Patterns are used for conciseness, typically in simple transformations limited to creating or deleting model elements.
• Require Patterns are used to express positive application conditions (PACs). A rule can contain any number of Require Patterns. In order for the rule to be triggered, all of its Require Patterns must be matched in the source model, regardless if its Find Pattern is matched or not.
• Forbid Patterns are used to express negative application conditions (NACs). A rule can contain any number of Forbid Patterns. In order for the rule to be triggered, none of its Forbid Patterns must be matched in the source model, regardless if its Find Pattern is matched or not.

At a minimum, a rule must contain either an Update Pattern or a pair of Find and Produce Patterns.

In addition to any element of the host modeling language, patterns may contain any number of annotations. Typically, annotations are expressed using the comment facility of the host modeling language. Annotations have a dedicated, logic programming-inspired syntax.

The metamodel described above is not implemented by direct instantiation into a model transformation Domain-Specific Language (DSL), as is the case with most existing transformation languages. Instead, the elements of the VMTL metamodel are weaved as a transformation aspect into the host modeling language.

Elements of the VMTL metamodel are mapped to elements of the host modeling language metamodel, and a different mapping exists for each VMTL-compatible host language. As a consequence, VMTL has some requirements from potential host languages:

• The host language must support an annotation mechanism, and it must be possible to anchor annotations to individual model elements. For example, comments are a typical annotation mechanism.
• The host language must support a scoping construct, used to separate the multiple rules and patterns included in a transformation. For example, packages are a typical scoping construct.

There are only four elements of the VMTL metamodel that must be mapped to elements of the host language: transformations, rules, patterns, and annotations. The first three correspond to model fragments, and are mapped to the scoping construct of the host language. Annotations are mapped to host language comments.

As an example, consider the Unified Modeling Language (UML) and Business Process Modeling Language (BPMN) as host languages. When weaving VMTL into UML, transformations, rules, and patterns are mapped to Packages, while annotations are mapped to Comments. When weaving VMTL into BPMN, transformations, rules, and patterns are mapped to Packages, while annotations are mapped to BPMN Annotations.

The mapping between VMTL and host language metamodel elements can be implemented in two ways: using profiles or using naming conventions. Profiles are the preferred method. The VM* profile for UML defines dedicated stereotypes for each VMTL metamodel element, as illustrated in the table bellow. Note that some stereotypes can be applied to both UML Packages and Comments. Applying the stereotypes to appropriate Packages is sufficient for transformation definition. However, the same stereotype may optionally be applied to Comments contained in a Package (and displayed in a diagram contained in that package) in order to provide a visual illustration of the role played by that Package in the transformation. When these stereotypes are applied to Comments, the standard UML Comment notation is replaced by the icons listed in the table.

Stereotype	Extends	Description	Icon
<<VM Annotation>>	Comment	Stereotype applicable to Comments containing annotations specified by any VM* language (VMTL, VMCL, or VMTL).	–
<<VM Transformation>>	Package	Stereotype applicable to Packages containing one VMTL Transformation.	–
<<VM Rule>>	Package	Stereotype applicable to Packages containing one VMTL Rule.	–
<<VM Find>>	Package, Comment	Stereotype applicable to Packages containing one Find Pattern. The Stereotype can also be applied to Comments included in Find Patterns, in which case the Stereotype Icon replaces the standard Comment notation.
<<VM Produce>>	Package, Comment	Stereotype applicable to Packages containing one Produce Pattern. The Stereotype can also be applied to Comments included in Produce Patterns, in which case the Stereotype Icon replaces the standard Comment notation.
<<VM Update>>	Package, Comment	Stereotype applicable to Packages containing one Update Pattern. The Stereotype can also be applied to Comments included in Update Patterns, in which case the Stereotype Icon replaces the standard Comment notation.
<<VM Forbid>>	Package, Comment	Stereotype applicable to Packages containing one Forbid Pattern. The Stereotype can also be applied to Comments included in Forbid Patterns, in which case the Stereotype Icon replaces the standard Comment notation.
<<VM Require>>	Package, Comment	Stereotype applicable to Packages containing one Require Pattern. The Stereotype can also be applied to Comments included in Require Patterns, in which case the Stereotype Icon replaces the standard Comment notation.

Some host modeling languages do not provide support for stereotypes and profiles. For such host languages, naming conventions must be used. For instance, in the case of BPMN, VMTL transformations must be contained in Packages having names prefixed by the “[VM Transformation]” string.

VMTL transformations are executed following the multi-step process described bellow:

• Step 1: Rules are placed in a priority queue.
• Step 2: If the priority queue is empty, the transformation terminates. Otherwise, the highest-priority rule is dequeued.
• Step 3: All matches of the highest-priority rule in the source model are identified. If no matches are found, Step 2 is executed.
• Step 4: Application conditions for all identified matches of the highest-priority rule are checked. If none of the matches' application conditions are satisfied, Step 2 is executed.
• Step 5: The highest-priority rule is applied to the source model at all matching locations where the application conditions are satisfied. A new execution of Step 1 on the updated source model follows.

The process described above implies that transformations are executed in-place. However, VMTL transformations can be executed following either an in-place or an out-place semantics. To achieve an in-place semantics, the updated source model is persisted to its original location. To achieve an out-place semantics, the updated source model is persisted to a new location (i.e. the target model).