operations.rst 16 KB

  1. Activities
  2. ==========
  3. While model transformations are in many tools considered to be the only types of activity on models, this is not necessarily the case in the Modelverse.
  4. Indeed, MPM advocates to use the most appropriate formalism, and, as model transformations are models themselves, this should also apply to specifying activities.
  5. As such, we extend the notion of model transformations to more general activities.
  6. Activities come in three types, depending on how they are ideally specified: model transformations, manual activities, and action language.
  7. In the remainder of this section, we will show all types, and what situation they are ideally suited for.
  8. Model Transformations
  9. ---------------------
  10. When model matching and rewriting is involved, model transformations are clearly the ideal solution in most cases.
  11. The LHS is used to match elements in the host model, and the RHS is put in its place.
  12. As this could also be combined with a visual concrete syntax, it could even become possible for domain experts to create a model transformation without too much programming knowledge.
  13. Nonetheless, model transformations are a completely different paradigm, based solely on matching and rewriting.
  14. Some formalisms have a long history in computer science, and have therefore efficient and/or simple procedural algorithms.
  15. For example, computing the reachability graph of a PetriNets instance can certainly be done with model transformations, but will be overly difficult.
  16. On the other hand, procedural algorithms are relatively easy (when implemented naively).
  17. The functions on model transformations are exposed using the *transformation_add_MT* and *transformation_execute_MT* operations.
  18. Examples as shown in the previous section::
  19. >>> def callback(model):
  20. ... instantiate(model, "Association", edge=("PetriNets/Transition", "ReachabilityGraph/Transition"), ID="PN2RG_Transition")
  21. >>> transformation_add_MT({"PetriNets": "formalisms/PetriNets"}, {"ReachabilityGraph": "formalisms/ReachabilityGraph"}, "models/pn_analyse", open("models/pn_analyse.mvc", "r").read(), callback)
  22. A situation in which model transformations are effective, is when the transformation is to map a Domain Specific Language (DSL) to a General Purpose Language (GPL).
  23. For example, when defining a mapping between a RPGame DSL and the PetriNets formalism, to facilitate formal analysis::
  24. >>> def callback(model):
  25. ... instantiate(model, "Association", edge=("RPGame/Tile", "PetriNets/Place"), ID="Tracability_link")
  26. >>> rule = \
  27. ... """
  28. ... Composite composite {
  29. ... {Contains} ForAll create_places_for_tiles {
  30. ... LHS {
  31. ... Pre_RPGame/Tile pre_t1 {
  32. ... label = "tile"
  33. ... }
  34. ... }
  35. ... RHS {
  36. ... Post_RPGame/Tile post_t1 {
  37. ... label = "tile"
  38. ... }
  39. ... Post_PetriNets/Place post_p1 {
  40. ... label = "place"
  41. ... }
  42. ... Post_Tracability_link (post_t1, post_p1) {
  43. ... label = "tracability"
  44. ... }
  45. ... }
  46. ... }
  47. ... ...
  48. ... }
  49. ... Initial (composite, create_places_for_tiles) {}
  50. ... OnSuccess (create_places_for_tiles, ...) {}
  51. ... OnFailure (create_places_for_tiles, ...) {}
  52. ... ...
  53. ... """
  54. >>> transformation_add_MT({"RPGame": "formalisms/RPGame"}, {"PetriNets": "formalisms/PetriNets"}, "models/rpg_to_pn", rule, callback)
  55. >>> transformation_execute_MT("models/rpg_to_pn", {"RPGame": "models/my_rpg"}, {"PetriNets": "models/exported_rpg"})
  56. Action Language
  57. ---------------
  58. Doing operations in a procedural way is supported in the Modelverse through the use of action language models.
  59. As action language is explicitly modelled, we can create models consisting solely of action language.
  60. They are therefore similar to model transformations, which are also models, but only define a different operational semantics.
  61. Instead of having a model transformation interpreter apply the schedule and rules, we merely call the action language functions enclosed in the model.
  62. The functions on action language are exposed using the *transformation_add_AL* and *transformation_execute_AL* operations.
  63. Their signature is identical to that of model transformations.
  64. The action language model itself requires a single *main* function, or it will execute the topmost function in the specified code.
  65. This function should take a single argument, being the merged model.
  66. From this model, the merged metamodel can easily be accessed.
  67. As with model transformations, the names of model entities are prefixed with their tags.
  68. For example, when defining the PetriNets analysis in action language, which is a much better match than model transformations::
  69. >>> def callback(model):
  70. ... instantiate(model, "Association", edge=("PetriNets/Transition", "ReachabilityGraph/Transition"), ID="PN2RG_Transition")
  71. >>> code = \
  72. ... """
  73. ... include "primitives.alh"
  74. ... include "modelling.alh"
  75. ... ...
  76. ...
  77. ... Element function explore_state(model : Element, state : Element):
  78. ... ...
  79. ...
  80. ... Boolean function main(model : Element):
  81. ... String initial
  82. ... initial = instantiate_node(model, "ReachabilityGraph/Initial")
  83. ... instantiate_attribute(model, initial, "name", "state_0")
  84. ... ...
  85. ... return True!
  86. ... """
  87. >>> transformation_add_AL({"PetriNets": "formalisms/PetriNets"}, {"ReachabilityGraph": "formalisms/ReachabilityGraph"}, "models/pn_analyse", code, callback)
  88. >>> transformation_execute_AL("models/pn_analyse", {"PetriNets": "models/my_pn"}, {"ReachabilityGraph": "models/generated_reachability"})
  89. An activity will have to return a boolean, similar to how a model transformation had to end in either success or failure.
  90. If the boolean is true, the activity is deemed to have terminated successfully and the changes are made to the models listed in the output dictionary.
  91. If the boolean is false, the activity is deemed to have failed and no changes are made to the models in the output dictionary.
  92. Manual Activities
  93. -----------------
  94. Some activities simply cannot be automated.
  95. For example, translating natural language descriptions of requirements of a model to the actual model is not something that can trivially be automated.
  96. The only solution, therefore, is to do this manually, thereby requiring user intervention.
  97. Even though they are manual, they can still be partially automated: merging and splitting based on tags can still be done before and after the manual activity.
  98. The functions on action language are exposed using the *transformation_add_MANUAL* and *transformation_execute_MANUAL* operations.
  99. Their signature is identical to that of model transformations, except that now there is no model to provide with the *transformation_add_MANUAL*.
  100. As with model transformations, the names of model entities are prefixed with their tags.
  101. This has to be taken into account when doing the manual changes to the model.
  102. For example, when defining an activity to refine or revise a model in a DSL with respect to the requirements, such as the PetriNets language from before::
  103. >>> def callback(model):
  104. ... instantiate(model, "Association", edge=("Requirements/Actor", "PetriNets/Place"))
  105. >>> transformation_add_MANUAL({"PetriNets": "formalisms/PetriNets", "Requirements": "formalisms/Requirements"}, {"PetriNets": "formalisms/PetriNets"}, "revise_pn", callback)
  106. Its execution, however, differs significantly from before, as we will see next.
  107. Manual activities are deemed to always terminate successfully, and must therefore not return a boolean.
  108. Execution callbacks
  109. ^^^^^^^^^^^^^^^^^^^
  110. As specified before, manual activities require user intervention during execution.
  111. The *transformation_execute_MANUAL* operation is therefore not a simple function that is executed and returns after some time: user input must be given.
  112. For this, an additional argument is provided as callback function.
  113. This callback function can be any sequence of operations again, such that it is possible to create or alter the model.
  114. Certainly, if it were to be possible automatically, we could have done it that way in the Modelverse.
  115. Therefore, the callback function can do much more than just these calls: all expressive power of Python is available, such as the possibility for user input (*raw_input()*).
  116. Based on this, the callback can define whatever structure is desired, possibly even going as far as starting up a dialog box or using a graphical interface.
  117. As before, the first parameter of the operations (*model_name*) should be set to *None*.
  118. For example, to specify the operations that have to be done in a manual operation, all in Python syntax::
  119. >>> def callback(model):
  120. ... places = [instantiate(model, "PetriNets/Place") for _ in range(100)]
  121. ... ...
  122. >>> transformation_execute_MANUAL("revise_pn", {"PetriNets": "models/my_pn", "Requirements": "models/pn_requirements"}, {"PetriNets": "models/my_pn"}, callback)
  123. Alternatively, the operations might only be known at runtime, thereby requiring user interaction.
  124. Note that, in this case, the code in the callback is effectively the user interface offered to the user in this specific context.
  125. As such, the code can be completely tailored to the domain and problem at hand::
  126. >>> def callback(model):
  127. ... while True:
  128. ... print("Please perform operation on PetriNet!)"
  129. ... inp = raw_input()
  130. ... if inp == "new place":
  131. ... instantiate(model, "PetriNets/Place")
  132. ... ...
  133. ... ...
  134. >>> transformation_execute_MANUAL("revise_pn", {"PetriNets": "models/my_pn", "Requirements": "models/pn_requirements"}, {"PetriNets": "models/my_pn"}, callback)
  135. Manual activities are not the only operations which might require user input.
  136. Model transformations and action language can just as well query the users for input.
  137. This is done the same way: by defining a callback.
  138. Note that they are slightly different, in the sense that their callback is not a function in Python, but governed by a Statechart, as discussed next.
  139. Statechart callbacks
  140. ^^^^^^^^^^^^^^^^^^^^
  141. While manual activities can refer to a Python function as callback, this is not the case for the execution of a model transformation or action language fragment.
  142. In this case, a more complex interaction is required, which depends on the use of SCCD (Statecharts + Class Diagrams).
  143. When executing the activity, a reference to a running statechart is passed, instead of a callback function.
  144. This statechart can have an input and output port, which can be used to communicate with the Modelverse.
  145. Data sent on the output port will arrive in the running activity (in the *input()* call), and data sent out in the activity with *output(X)* will be received on the input port.
  146. An example is given below of a model transformation that prints out a Petri Net using a model transformation::
  147. >>> ctrl = log_output.Controller(keep_running=False)
  148. >>> thrd = threading.Thread(target=ctrl.start)
  149. >>> thrd.daemon = True
  150. >>> thrd.start()
  151. >>> transformation_execute_MT("test/print_pn", {"PetriNet": "test/my_pn"}, {}, (ctrl, "inp", "outp"))
  152. This command starts up the model transformation and immediately connects it to a running Statechart called *log_output*.
  153. Its definition is shown below::
  154. <?xml version="1.0" encoding="UTF-8"?>
  155. <diagram author="Yentl Van Tendeloo" name="Logging">
  156. <description>
  157. Print all incoming data
  158. </description>
  159. <inport name="inp"/>
  160. <outport name="outp"/>
  161. <class name="Logging" default="true">
  162. <scxml initial="init">
  163. <state id="init">
  164. <transition event="input" port="inp" target=".">
  165. <parameter name="value"/>
  166. <script>
  167. print(value)
  168. </script>
  169. </transition>
  170. <transition after="0.1" target="."/>
  171. <transition event="terminate" port="inp" target="../finished">
  172. <script>
  173. print("Terminating")
  174. </script>
  175. </transition>
  176. </state>
  177. <state id="finished"/>
  178. </scxml>
  179. </class>
  180. </diagram>
  181. Similarly, the SCCD model could have raised input to its output port (*outp*), which would then be received in the activity.
  182. Note that the call to *transformation_execute_MT* is always blocking and always returns whether or not the activity was successfully terminated.
  183. Process Model
  184. -------------
  185. A next logical step is the chaining of these various operations, or activities.
  186. For this reason, the FTG+PM was previously developed.
  187. The Modelverse provides both modelling and enactment support for the FTG+PM.
  188. When modelling, the FTG+PM is just a metamodel like all others, and instances can easily be created of it.
  189. There are notions of activities, decision nodes, forks, joins, and so on.
  190. Apart from control flow, an FTG+PM also specifies data flow: which models are used in this scope, and how are they interrelated.
  191. Indeed, we could define the sequence of activities to execute, but we still need information on what are the input models of the various activities.
  192. For example, the same activity might execute multiple times, but each time on different input models and generating different output models.
  193. A simple process model is shown, which executes the operations stored in *models/A* and *models/B* in parallel.
  194. Both operations use some data, where *models/A* modifies one of its data inputs in-place, and *models/B* generates new data::
  195. Start start {}
  196. Finish finish {}
  197. Fork fork1 {}
  198. Exec activity_A {
  199. name = "models/A"
  200. }
  201. Exec activity_B {
  202. name = "models/B"
  203. }
  204. Join join1{}
  205. Data data_a1 {
  206. name = "models/data_a1"
  207. type = "formalisms/Bottom"
  208. }
  209. Data data_a2 {
  210. name = "models/data_a2"
  211. type = "formalisms/Bottom"
  212. }
  213. Data data_b1 {
  214. name = "models/data_b1"
  215. type = "formalisms/SimpleClassDiagrams"
  216. }
  217. Data data_b2 {
  218. name = "models/data_b2"
  219. type = "formalisms/Bottom"
  220. }
  221. Next (start, fork1) {}
  222. Next (fork1, activity_A) {}
  223. Next (fork1, activity_B) {}
  224. Next (activity_A, join1) {}
  225. Next (activity_B, join1) {}
  226. Next (join1, finish) {}
  227. Consumes (activity_A, data_a1) {
  228. name = "First"
  229. }
  230. Consumes (activity_A, data_a2) {
  231. name = "Second"
  232. }
  233. Produces (activity_A, data_a2) {
  234. name = "Second"
  235. }
  236. Consumes (activity_B, data_b1) {
  237. name = "input"
  238. }
  239. Produces (activity_B, data_b2) {
  240. name = "output"
  241. }
  242. This simple Process Model is equivalent to the following statements in the code.
  243. Note that we do not know the type of the activity in the operations, and therefore put an asterisk (\*) there.
  244. Also, the order in which these operations execute is undefined, as either order is fine.
  245. We therefore leave it up to the Modelverse to decide upon an order::
  246. >>> execute_transformation_*("models/A", {"First": "my_models/data_a1", "Second": "my_models/data_a2"}, {"Second": "my_models/data_a2"})
  247. >>> execute_transformation_*("models/B", {"input": "my_models/data_b1"}, {"output": "my_models/data_b2"})
  248. In this case, it doesn't seem useful to use processes, though it is possible for such processes to contain *Decision* nodes, which can be used for arbitrary control flows.
  249. As everything runs on the Modelverse, instead of constantly requiring communication with the client, performance should be higher due to reduced network latency.
  250. When enacting, the FTG+PM is executed by starting at the initial node.
  251. The first element it points to is executed, thereby branching, deciding, or executing an activity.
  252. Due to the branching, it is possible for multiple activities to be scheduled concurrently.
  253. As for now, the Modelverse sequentializes the various activities internally.
  254. When executing an activity, which can either be a model transformation, action language, or manual operation, the operation is executed with the required operation.
  255. More information on enactment was previously given.