Consider a UML Use Case model in which an Actor is connected by Associations to two Use Cases, one of which extends the other. The described scenario is a refactoring candidate, since according to the UML standard the extending Use Case “typically defines behavior that may not necessarily be meaningful by itself”. Deleting the Association between the Actor and the extending Use Case is therefore recommended.

The offending Association can be removed using a single-rule VMTL transformation consisting of an Update Pattern. In this pattern, the delete annotation is applied to the Association connecting the Actor to the extending Use Case. The annotation implies that any match of this Association in the source model will be deleted.

Notice the «VM Update» stereotype applied to the Comment in the top-right of the diagram, replacing the standard notation for Comments with the Update pattern icon. The presence of this comment is optional. It serves a presentation purpose, enabling readers to identify the pattern type. For the transformation to be well-formed, another instance of the same stereotype must be applied to the Package containing the Update pattern.

This example shows how VMTL can be used to implement a complete version of the well-known “Pull Up Attribute” refactoring. The specification of this refactoring states that if all subclasses of Class C own an Attribute a₁ with name n, type t, and visibility v, then a₁ must be removed from the subclasses, and a new Attribute a₂ with the same name, type, and visibility must be added to C. The transformation may only be applied if C does not already own an Attribute named n. Furthermore, if v = “private”, the visibility of a₂ must be set to “protected”, so that subclasses of C may access it.

The “Pull Up Attribute” refactoring can be implemented in VMTL using two rules: Pull Up and Remove Duplicate.

The Pull Up rule has a higher execution priority, and is applied at most once for each Class in the source model. The rule contains an Update Pattern named Pull Up. This pattern states that if two subclasses ($sub1, $sub2) of the considered Class ($super) own Attributes with the same name, type, and visibility, these Attributes should be deleted from the subclasses, and a new Attribute with the same name and visibility should be added to their superclass. This is accomplished via a delete and a create clause, respectively. The conditional if operator is used to determine the type of the newly created Attribute.

The Pull Up rule also has two application conditions: a negative application condition specified using a Forbid Pattern, and a positive application condition specified using a Require Pattern. The Forbid Pattern, called Attribute in Superclass, is shown bellow. It states that Class $super must not already own an Attribute with the same name ($attr) as the Attribute to be pulled up from its subclasses. This condition is imposed due to the fact that a UML Class cannot own two Attributes of the same name.

The Require Pattern, called Attribute in all Subclasses, states that all subclasses of Class $super must contain an Attribute with name $attr, visibility $v, and type $t.

The Remove Duplicate rule is applied zero or more times following a successful application of the Pull Up rule. The role of this second rule is to handle situations in which the $super Class has more than two subclasses. Since the $attr Attribute has already been pulled up to the $super Class, the counterparts of this attribute must be removed from all of its subclasses. The rule consists of a single Update Pattern, called Remove Duplicate, displayed bellow.

In a Business Process Model and Notation (BPMN) Process Diagram, the execution order of Tasks is determined by directed Sequence Flows. Typically, a Task has both incoming and outgoing Sequence Flows. Although legal, the absence of outgoing Sequence Flows from a Task may be considered a design anti-pattern, since the execution of this task will implicitly lead to the termination of the Process. In this scenario, Process termination can be made explicit by applying a refactoring which ensures that an End Event is executed after each Task with no outgoing Sequence Flows.

The described refactoring can be specified using a single VMTL transformation rule consisting of a Forbid Pattern and an Update Pattern.

The Forbid Pattern, called Forbid Existing Flow, prevents the application of the refactoring to Tasks that already have an outgoing Sequence Flow. The pattern makes use of the type special variable to ensure that all types of Flow Nodes (e.g. Tasks, Gateways, Events) are allowed as targets of this Sequence Flow. Since the BPMN standard does not support stereotypes, the VMTL annotation is differentiated from regular Text Annotations by the [VM Annotation] prefix included in its text.

The Update Pattern, called Create End Event, applies the desired refactoring by creating a new End Node and Sequence Flow pair for every Task not matching the Forbid Pattern. The create clause is employed for this purposed.