The VM* Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 1. UML Use Case model refactoring ======

===== 1.1. Scenario description =====

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 [[http://www.omg.org/spec/UML/|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.

===== 1.2. VMTL implementation =====

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.

{{ :vmtl:delete_association_update.png?direct&400 |}}

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.

====== 2. UML Class Diagram refactoring ======

===== 2.1. Scenario description =====

This example shows how VMTL can be used to implement a complete version of the well-known "[[http://refactoring.com/catalog/pullUpField.html|Pull Up Attribute]]" refactoring. The specification of this refactoring states that if all subclasses of Class //C// own an Attribute //a<sub>1</sub>// with name //n//, type //t//, and visibility //v//, then //a<sub>1</sub>// must be removed from the subclasses, and a new Attribute //a<sub>2</sub>// 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<sub>2</sub>// must be set to "protected", so that subclasses of //C// may access it.

===== 2.2. VMTL implementation =====

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.

{{ :vmtl:pull_up_update.png?direct&500 |}}

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.

{{ :vmtl:pull_up_forbid.png?direct&300 |}}

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''.

{{ :vmtl:pull_up_require.png?direct&300 |}}

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.

{{ :vmtl:remove_duplicate_update.png?direct&350 |}}

====== 3. BPMN Process Diagram refactoring ======

===== 3.1. Scenario description =====

In a [[http://www.omg.org/spec/BPMN/2.0.2/|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.

===== 3.2. VMTL implementation =====

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.

{{ :vmtl:example_bpmn_addendevent_forbid.png?direct&350 |}}

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.

{{ :vmtl:example_bpmn_addendevent_create.png?direct&300 |}}
The VM* Wiki

User Tools

Site Tools

Page Tools
