workflows.txt 6.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107
  1. .. _workflows:
  2. Workflows
  3. ================================
  4. A Workflow is MDE-based solution where the user defines a “workflow” that can be parametrized at run-time and executed. This Workflow is a DSL for defining activities that can be performed in MDE tools. In the next subsections, we explain how to create and use these elements.
  5. An activity is composed of tasks, to define concrete actions to be performed. we want to automate user’s activities as much as possible, therefore most of the tasks are automatic: they do not require human interaction. For example, loading a formalism to create a metamodel is a task that can be automated, since the location of that formalism is known.
  6. .. image:: img/activities.png
  7. An activity conforming to the metamodel starts from the initial node and terminates at the final node. Tasks can be sequenced one after the other.
  8. Using Workflows
  9. -----------------------------
  10. Using a workflow is easy, and requires you to make use of the *Workflow* toolbar:
  11. .. image:: img/workflows_toolbar.png
  12. You must perform each of the following activities:
  13. #. Selects which workflow you desire to enact.
  14. #. Set the run-time parameters.
  15. #. Execute the workflow
  16. Opening the workflow
  17. ---------------------
  18. To open a Workflow, press the fifth button of the *MainMenu* toolbar :ref:`overview`. Opening a templeate model replaces the currently opened model, if any. If there are any unsaved changes in the currently opened model, you will receive a warning.
  19. * Click on Open Model button :ref:`overview`
  20. * Select *Formalism/Workflows/Templates…*
  21. * Select the file.
  22. * Click on Ok button
  23. .. image:: img/templates.png
  24. Setting the run-time parameters
  25. ---------------------------
  26. A prerequisite to execute a workflow is to set the run-time parameters. To do this, the user pushes the *LoadParameters* button, the first button on the *Workflow* toolbar . This creates an instance of the parameter object and pops up a dialog prompting for all required parameters. Write these parameters and push the ok button.
  27. .. image:: img/parameters.png
  28. .. note:: Each parameter must be typed without extension. For example, the class diagram toolbar location is: "/Formalisms/__LanguageSyntax__/SimpleClassDiagram/SimpleClassDiagram.umlIcons.metamodel", then we should type: "/Formalisms/__LanguageSyntax__/SimpleClassDiagram/SimpleClassDiagram.uml", where Icons.metamodel was predefined by the designer of this template.
  29. Execute the workflow
  30. ---------------------
  31. Click on the *Resume Process* button, the second button on the *Workflow* toolbar. This executes the worklow autonomously. When a manual task is reached, a new AToMPM window is opened with all necessary toolbars pre-loaded.
  32. A message describing the manual task to perform is displayed to the user and the simulation stops.
  33. After the user has completed the task, the user pushes the third button (*CompleteTask* button) . Then, the window closes and the simulation restarts.
  34. Dependency
  35. -------------
  36. Workflow parameters are specified once per workflow; however, run-time parameters must be manually specified each time the workflow is executed. Therefore, a *Dependency* link can be specified between different tasks that share the same run-time parameters.
  37. A dependency link specifies which attribute from the target task gets its value from an attribute in the source task. For example, the location of the *SaveModel task is the same as the location of the \texttt{OpenModel}when saving a model we just opened and modified.
  38. Example Workflow for Creating a DSL
  39. -----------------------------------
  40. .. image:: img/create_dsl.png
  41. The image shows the workflow that specifies how to create a DSL and generate a modeling environment for it in AToMPM.
  42. The first task is *LoadToolbar*.
  43. Its location parameter is already predefined with the class diagram toolbar, since this is the standard formalism with which one creates a metamodel in AToMPM.
  44. The following task is *EditModel*.
  45. In this manual task, the user creates the metamodel of the DSL using class diagrams.
  46. .. image:: img/create_as.png
  47. Once this is complete, the workflow restarts executing from that task and proceeds with *SaveModel*.
  48. This task requires a run-time parameter to specify the location of where the metamodel is saved.
  49. The user sets the value in the popup dialog wizard.
  50. .. image:: img/create_dsl_parameters.png
  51. Now that the metamodel is created, a fork node proposes two flows: one for creating the concrete syntax of the DSL and one to generate the abstract syntax from the metamodel.
  52. Recall that the simulation chooses one flow and then the other in no specific order.
  53. Suppose the former flow is chosen.
  54. Then, a *LoadToolbar* task is executed to load the concrete syntax toolbar, the standard formalism in AToMPM.
  55. This is followed by an *EditModel* so the user can manually create the shapes of each element of the metamodel.
  56. Once this is complete, the workflow restarts and proceeds with a *SaveModel* task.
  57. Recall that the location is a run-time parameter to save the concerte syntax model with a predefined extension.
  58. The following task in this flow is *GenerateCS*.
  59. .. image:: img/create_cs.png
  60. It takes as run-time parameter the location of where the generated artifact must be output.
  61. Specifically, the name used will be also the name of the toolbar that will be used to create a model with this DSL.
  62. Therefore, the location of the generated concrete syntax is the same as the location of the concrete syntax model the user created manually.
  63. The dependency link prevents the user from having to duplicate parameter values in the pop-up wizard.
  64. When the join node is reached, the simulation notices that the second flow was not executed yet.
  65. Therefore the next task to be executed is *GenerateAS*.
  66. Its location parameter uses the same value of the location attribute of *SaveModel*, as depicted by the dependency link between these two tasks.
  67. When the join node is reached again, this time all flows were executed and proceeds with the final task *LoadToolbar*.
  68. .. image:: img/create_model.png
  69. As stated before, its location parameter use the same value of the location attribute of previous *SaveModel* domain-specific model.
  70. The simulation ends on a new window open with the new DSL loaded, ready for the user to create his domain-specific model.