transformations.rst 15 KB

  1. Model transformations
  2. =====================
  3. A next step in the Modelverse is the use of model transformations.
  4. Model transformations are implemented using RAMification, and are therefore also modelled explicitly.
  5. As such, all previous modelling concepts are again useful.
  6. Specification
  7. -------------
  8. To create a model transformation, users must specify a set of source metamodels and target metamodels.
  9. The model transformation will afterwards get a signature of these models.
  10. To create a simple Petri Net simulation transformation, we use the operation *transformation_add_MT* as follows::
  11. >>> transformation_add_MT({"PN": "formalisms/PetriNets"}, {"PN": "formalisms/PetriNets"}, "models/pn_simulate", open("pn_simulate.mvc", "r").read())
  12. The first dictionary we pass, is the input dictionary: it specifies the name the model elements will get in the LHS, and the expected type of them.
  13. Similarly, the output dictionary specifies the name of output elements and their types.
  14. The actual metamodel in which the model transformation executes is defined as the merger of the keys in both the input and output dictionary.
  15. Note that in the transformation, all types are renamed by prepending the tag of their signature.
  16. For example, all types in the previous model transformation will be renamed by prepending *"PN/"* (e.g., *PN/Place*, *PN/P2T*).
  17. All types are renamed, in order to make multiple inputs with the same type possible.
  18. For example, when combining two models, both of the same type, but one of them being the *master*, it is possible to do the following::
  19. >>> transformation_add_MT({"master": "formalisms/PetriNets", "slave": "formalisms/PetriNets"}, {"result": "formalisms/PetriNets"}, "models/pn_merge", open("pn_merge.mvc", "r").read())
  20. In this case, the LHS can match specifically for elements of the master (e.g., *master/Place*).
  21. The output dictionary is interesting as well: multiple output models are possible, and these are based on the tags as well.
  22. When model elements do not match any tags, an exception is raised.
  23. When a model element matches a tag, it is put into that specific output model.
  24. More information on tags can be found in the *invocation* subsection.
  25. We will now continue on how to specify a model transformation through modelling.
  26. RAMification
  27. ^^^^^^^^^^^^
  28. To support model transformation, the Modelverse makes use of RAMification.
  29. In RAMification, the original metamodel is Relaxed, Augmented, and Modified.
  30. As such, the new metamodel can be used to define model transformation rules.
  31. This consists of the following three phases:
  32. 1. The metamodel is **Relaxed**, such that lower cardinalities are no longer applied. Similarly, constraints are removed, and abstract entities can be instantiated. This is done because in model transformations, we only use a specific part of the metamodel.
  33. 2. The metamodel is **Augmented**, such that new attributes and concepts are added. These new attributes are *label* and *constraint* in the LHS, and *label* and *action* in the right hand side. New concepts that are added, are the LHS and RHS entity. These are the containers for all elements of the LHS and the RHS, respectively.
  34. 3. The metamodel is **Modified**, such that existing attributes are renamed and their types are altered. All attributes have to become constraints on that specific attribute in the LHS (name prepended with *constraint_*), and actions for the new value in the RHS (name prepended with *value_*). For example, the *tokens* attribute of a place becomes a constraint function (returning True or False), instead of an attribute of type integer.
  35. RAMification happens in the background in the Modelverse.
  36. Users can, of course, open the RAMified metamodel just like any other metamodel.
  37. As RAMification makes a distinction between the LHS and RHS, all entities in the metamodel are effectively duplicated: the LHS entities are prefixed with *Pre_*, and the RHS entities are prefixed with *Post_*.
  38. Similarly, the names of all attributes are prefixed with *constraint_* and *value_*, respectively.
  39. Implicit merge
  40. ^^^^^^^^^^^^^^
  41. As a model transformation considers multiple languages, both for its input and output, it must be possible somewhere to join them.
  42. For example, a transformation from PetriNets to a ReachabilityGraph formalism, makes use of entities from both metamodels, in the same model.
  43. To allow for this, all used metamodels are implicitly merged before RAMification.
  44. Therefore, the metamodel becomes a combination of all metamodels that were originally specified, making it possible to use all of them in a single model.
  45. Note, however, that the metamodels might use similar concepts: both a PetriNet and a ReachabilityGraph have the notion of a *Place*, but it means something different in both cases.
  46. Therefore, the elemens are prepended with the tag that was used to define them.
  47. As such, the model transformation has no notion of *Place*, but only of *PetriNets/Place* and *ReachabilityGraph/Place*.
  48. In all operations in the transformation, it is necessary to use this notation.
  49. As the same metamodel might be used multiple times, but in different contexts (i.e., with different tags), the metamodels are sometimes added multiple times.
  50. Each time, however, a different tag is prepended.
  51. This allows model transformations that combine, or alter, models of the same type, while still distinguishing between the two of them.
  52. Recall the *master/Place* discussion from the beginning of this section.
  53. Rule specification
  54. ^^^^^^^^^^^^^^^^^^
  55. Now we actually get to define a rule.
  56. Rules are themselves just models of the RAMified (and merged) metamodel.
  57. As such, they are created just like any other model.
  58. This is the code parameter of the *transformation_add_MT* operation, which takes a Modelverse model.
  59. An example specification is shown below, which will copy the highest number of tokens between places that have the same name, assuming that only one has a non-zero number of tokens::
  60. LHS {
  61. Pre_PetriNets/Place {
  62. label = "pn_place_master"
  63. constraint_tokens = $
  64. Boolean function constraint(value : Integer):
  65. return value > 0!
  66. $
  67. }
  68. Pre_PetriNets/Place {
  69. label = "pn_place_slave"
  70. constraint_tokens = $
  71. Boolean function constraint(value : Integer):
  72. return value == 0!
  73. $
  74. constraint = $
  75. Boolean function constraint(host_model : Element, mapping : Element):
  76. return value_eq(read_attribute(host_model, mapping["pn_place_master"], "name"), read_attribute(host_model, mapping["pn_place_slave"], "name"))!
  77. $
  78. }
  79. RHS {
  80. Pre_PetriNets/Place {
  81. label = "pn_place_master"
  82. }
  83. Pre_PetriNets/Place {
  84. label = "pn_place_slave"
  85. value_tokens = $
  86. Integer function value(host_model : Element, name : Element, mapping : Element):
  87. return read_attribute(host_model, mapping["pn_place_master"], "tokens")!
  88. $
  89. }
  90. }
  91. Some remarks, specifically in relation to users of AToMPM:
  92. 1. Unspecified constraint attributes in the LHS are always fulfilled (i.e., *result = True* in AToMPM notation).
  93. 2. Unspecified value attributes in the RHS are always copied as-is (i.e., *result = get_attr()* in AToMPM notation).
  94. 3. Just like in AToMPM, labels are strings and can be used as such.
  95. 4. While *mapping* contains a mapping for the labels to their elements in the host model, all elements of the host model an technically be used, even those not occuring in the LHS.
  96. 5. During rewriting, it is possible to access the values of all elements of the host model, including those matched before in the LHS. Newly created elements in the RHS can of course not be referenced. Elements removed in the RHS can no longer be referenced either, though this will likely be updated in future versions.
  97. Schedule
  98. ^^^^^^^^
  99. The rule we have previously applied, does not yet do much in itself: it needs to be scheduled.
  100. Scheduling consists of defining in which order rules are executed, but also defining how the rule is to be executed: as a query (*Query*), for one match (*Atomic*), or for all matches (*ForAll*).
  101. For scheduling purposes, each rule has a *onSuccess* and *onFailure* association.
  102. *onSuccess* associations are followed when the rule has been applied successfully (i.e., at least one match was found), and the *onFailure* association is followed otherwise.
  103. Rules can also be composites, in which case they define a schedule themselves.
  104. Each schedule, including the main schedule, has exactly one *Initial* element, and possibly (some) *Success* and *Failure* elements.
  105. When the *Success* (*Failure*) node is reached, the composite rule is said to succeed (fail).
  106. On the topmost schedule, success indicates that the model transformation is to be applied.
  107. When the topmost schedule ends in a failure node, the model transformation as a whole is deemed to fail, and all changes are reverted.
  108. As such, users are guarenteed that an intermediate model will never be visible, or corrupt previous models.
  109. An example schedule, which applies the previous rule for as long as it matches, is shown below::
  110. Composite composite {
  111. ForAll copy_tokens {
  112. LHS {
  113. ...
  114. }
  115. RHS {
  116. ...
  117. }
  118. }
  119. Success success {}
  120. }
  121. Initial (composite, copy_tokens) {}
  122. OnSuccess (copy_tokens, copy_tokens) {}
  123. OnFailure (copy_tokens, success) {}
  124. Invocation
  125. ----------
  126. The actual binding is only done later on, upon invocation, and goes as follows::
  127. >>> transformation_execute_MT("models/pn_simulate", {"PN": "models/my_pn"}, {"PN": "models/my_pn"})
  128. In this case, the model transformation takes the model *my_pn* as input for the *pn_simulate* model transformation, and writes out the result in *my_pn*.
  129. As the output model matches the input model, the model transformation is effectively in-place.
  130. For out-place transformations, it is possible to specify a different output model, in which case the model is implicitly copied as well::
  131. >>> transformation_execute_MT("pn_simulate", {"PN": "models/my_pn"}, {"PN": "models/my_simulated_pn"})
  132. Model transformation invocation has no effect on the original model in this case.
  133. Also, model transformations always happen on a copy of the original model.
  134. As such, it is also possible to restore the model to before the transformation.
  135. When a model transformation fails (i.e., the schedule ends in a *Failure*), no output models are written and the models are left untouched.
  136. Signature
  137. ^^^^^^^^^
  138. After a model transformation is defined, it is easy to forget exactly which parameters it takes, and what were the types of these parameters.
  139. Therefore, the *transformation_read_signature* function can be used to read out the signature of model transformations::
  140. >>> transformation_read_signature("models/pn_simulate")
  141. ({"pn": "formalisms/PetriNets"}, {"pn": "formalisms/PetriNets"})
  142. >>> transformation_read_signature("models/pn_merge")
  143. ({"master": "formalisms/PetriNets", "slave": "formalisms/Petrinets"}, {"result": "formalisms/PetriNets"})
  144. Querying
  145. ^^^^^^^^
  146. Similarly, it is often easy to forget which transformations are supported between a source and target metamodel.
  147. Therefore the *transformation_between* function can be used to query for all transformations that take a certain metamodel as input, and generate another metamodel as output::
  148. >>> transformation_between({"PN": "formalisms/PetriNets"}, {"PN": "formalisms/PetriNets"})
  149. ["models/pn_optimize", "models/pn_simulate", "models/pn_rename", "models/pn_combine"]
  150. >>> transformation_between({"PN": "formalisms/PetriNets"}, {"Reachability": "formalisms/ReachabilityGraph"})
  151. ["models/pn_analyze"]
  152. Note that this operation does not take into account other input or output metamodels::
  153. >>> transformation_between({"PN": "formalisms/PetriNets"}, {"result": "formalisms/Boolean"})
  154. ["models/analyze_query", "models/is_safe", "models/conforms"]
  155. Traceability links
  156. ------------------
  157. As the metamodels are merged together into a single metamodel, models can contain elements from both.
  158. It is often useful to create some kind of link between these different metamodels.
  159. However, a simple merge does not allow for this, as the different metamodels form their own "islands".
  160. To create links between them, for example for matching or traceability, we need traceability links.
  161. Definition
  162. ^^^^^^^^^^
  163. Traceability links, or links between different metamodels, can be created by passing a callback function.
  164. As the intermediate merged metamodels are not designed to be modified by users (though they can be), the callback operation is executed on the merged metamodel.
  165. Only after the changes in the callback function are applied, is the metamodel RAMified.
  166. This callback function takes a single parameter *model*, which is the intermediate model on which operations are to be done.
  167. In the function, the usual modelling operations can be done, and they should happen on the passed model.
  168. While technically other operations are possible as well, this use case is not supported and untested.
  169. For example, to define a traceability link between a *PetriNets/Transition* and *ReachabilityGraph/Transition*, we can do the following when defining the transformation::
  170. >>> def callback(model):
  171. ... instantiate(model, "Association", edge=("PetriNets/Transition", "ReachabilityGraph/Transition"), ID="PN2RG_Transition")
  172. >>> transformation_add_MT({"PetriNets": "formalisms/PetriNets"}, {"ReachabilityGraph": "formalisms/ReachabilityGraph"}, "models/pn_analyse", open("models/pn_analyse.mvc", "r").read(), callback)
  173. As the forward slash (/) is already used to distinguish between the metamodel tag and the original entity, entities defined through a callback function should not contain this same symbol in their ID.
  174. Use
  175. ^^^
  176. In the transformation, it is now possible to use all (RAMified) entities of the *PetriNets* metamodel (e.g., *PetriNets/Place*, *PetriNets/Transition*), the *ReachabilityGraph* metamodel (e.g., *ReachabilityGraph/Transition*, *ReachabilityGraph/State*), and the newly defined *PN2RG_Transition* element.
  177. As specified in the callback, the *PN2RG_Transition* association connects only the *PetriNets/Transition* and *ReachabilityGraph/Transition* elements.
  178. Therefore, no links can be created between any other elements.
  179. This new entity can be used in the rules like any other, either in the LHS, RHS, or the NACs::
  180. LHS {
  181. Pre_PetriNets/Transition pre_pn_t {
  182. ...
  183. }
  184. }
  185. RHS {
  186. Post_PetriNets/Transition post_pn_t {
  187. ...
  188. }
  189. Post_ReachabilityGraph/Transition post_rg_t {
  190. ...
  191. }
  192. Post_PN2RG_Transition (post_pn_t, post_rg_t) {
  193. ...
  194. }
  195. }
  196. This is in contrast to AToMPM, where there was a notion of *GenericLink*, which could connect all entities, but was not defined at the domain-specific level.
  197. In the Modelverse, these traceability links are also modelled explicitly, such that their use is also governed by the usual conformance rules.
  198. When the transformation is finished, all entities in the model are split across the multiple tagged metamodels.
  199. Tracability links, not belonging to any of them, are stored in a separate model, typed by the *Tracability* metamodel.
  200. Future model merge operations can pass this traceability model, in order to restore the original model that was split.
  201. This is mostly useful to developers of the Modelverse, and is not elaborated here.