interaction.rst 6.5 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107
  1. Basic Interaction
  2. =================
  3. As previously mentioned during the installation phase, the Modelverse is merely a collection of scripts.
  4. We briefly present how the Modelverse is structured, and introduce the most important scripts for general use.
  5. A more elaborate view on the architecture and the different scripts is only required for developers of the Modelverse.
  6. Simplified Architecture
  7. -----------------------
  8. The Modelverse architecture consists of three core concepts, which will be referred to throughout the documentation.
  9. Modelverse State (MvS)
  10. ^^^^^^^^^^^^^^^^^^^^^^
  11. The Modelverse State (MvS) is the memory of the Modelverse, and contains all data pertaining to it.
  12. This includes not only the different models created by the users, but also all metamodels, transformations, operations, but also all bootstrap files.
  13. Furthermore, it includes all execution state of operations being executed in the Modelverse.
  14. As such, the Modelverse State is the database of the Modelverse, which is the only component containing data.
  15. Only developers will ever have to directly interface with the Modelverse State.
  16. Modelverse Kernel (MvK)
  17. ^^^^^^^^^^^^^^^^^^^^^^^
  18. The Modelverse Kernel (MvK) is the execution core of the Modelverse, and connects to the Modelverse State to fetch the instructions to execute.
  19. All its execution information is stored in the MvS as well, and therefore it has to (theoretically) query the MvS for each and every instruction.
  20. It merely consists of a set of model transformation rules which take the current state of the MvS, and does a transformation on it, similar to model transformations.
  21. Only developers will ever have to directly interface with the Modelverse Kernel.
  22. Modelverse Interface (MvI)
  23. ^^^^^^^^^^^^^^^^^^^^^^^^^^
  24. The Modelverse Interface (MvI) is the actual interface used by most users of the Modelverse.
  25. It provides any type of interface, whether it be graphical, textual, or any other interface.
  26. While this is the component users interact with, there should be no (meta-)modelling knowledge whatsoever in this part, as it is only responsible for providing a user-friendly interface to the Modelverse operations.
  27. All meta-modelling related operations, such as model transformations, conformance checking, process enactment, and so on, are directly supported in the Modelverse and are available to the MvI through the use of the provided interface.
  28. This component can make use of the provided wrapper, which does the binding with the Modelverse.
  29. Necessary scripts
  30. -----------------
  31. The Modelverse consists of a set of scripts, stored in the *scripts* folder.
  32. For most users, there are only two relevant scripts, none of them taking mandatory parameters:
  33. 1. *run_tests.py*, which runs all tests.
  34. 2. *run_local_modelverse.py*, which starts up the Modelverse server, combining the MvS and MvK at the same machine. An optional argument can be passed to run the Modelverse on a specific port (default: 8001).
  35. While other scripts are present, they are mostly variations of the existing scripts or are only useful for Modelverse development purposes.
  36. Wrapper
  37. -------
  38. Most often, the Modelverse is not used using the raw interface it provides by default.
  39. Therefore, we additionally provide a simple Python-based wrapper for the Modelverse, which can be included in arbitrary scripts.
  40. As the Modelverse can run as a service, wrappers can be created in any language that supports XML/HTTPRequests.
  41. By default, a Python and SCCDXML wrapper are provided, of which the Python interface is discussed in this documentation.
  42. The SCCDXML wrapper forms the basis for the Python wrapper and is similar in use.
  43. These wrappers are used by a variety of MvI implementations supported today, and indeed themselves encompass an MvI if they are used directly by the user (e.g., in batch processing of models).
  44. Tools can include all Modelverse operations merely by including the *modelverse.py* file from the *wrappers* folder (or including the SCCDXML model in *wrappers/classes/modelverse.xml*).
  45. It is this interface that is used throughout this documentation, although other interfaces are highly similar.
  46. Note that the Python interface is a synchronous (i.e., blocking) interface, and therefore not recommended for use in Graphical User Interfaces (GUI).
  47. The SCCDXML wrapper is asynchronous and perfectly suited for use in GUIs.
  48. The wrapper provides all necessary (meta-)modelling operations that can be used by the MvI.
  49. As the Modelverse is independent of its (visual/textual) user interface, we only discuss the Modelverse wrapper in this documentation.
  50. For an example use of the wrappers, we refer to the tests of the Modelverse (using all functionality of the wrapper) and the `Modelverse prototype GUI <https://msdl.uantwerpen.be/git/yentl/modelverse_GUI.git>`_.
  51. The wrapper functions are explained further in this documentation through the use of examples, in a tutorial-like fashion.
  52. A full overview of all Python wrapper functions is provided at the end of the documentation.
  53. Note that the Modelverse makes use of exceptions to signal unexpected behaviour.
  54. These are not covered in this tutorial, as their meaning is obvious from their name.
  55. All Modelverse exceptions inherit from the *ModelverseException*, which can be used as a catch-all.
  56. Initializing the Modelverse
  57. ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  58. Before we start, we must connect to the Modelverse.
  59. This can be done throught the *init* function::
  60. >>> init("http://modelverse.uantwerpen.be")
  61. This assumes that there is a Modelverse running at the specified address.
  62. It is also possible to omit this optional argument, in which case a connection is made to localhost at port 8001 (i.e., the default when running locally).
  63. For that, you must first start up a Modelverse at your own system by invoking the command::
  64. python scripts/run_local_modelverse.py
  65. Afterwards, connect to the local Modelverse through the usual *init* operation.
  66. This call might block for some time if the Modelverse server is still starting up::
  67. >>> init()
  68. Logging in
  69. ^^^^^^^^^^
  70. Now that we are connected to the Modelverse, we need to log in before any operations can be invoked.
  71. To log in, use the *login* operation::
  72. >>> login("yentl", "secret password")
  73. The operation will succeed if it terminates normally, and throw a Python exception otherwise.
  74. When the username does not exist yet, it is created upon invocation.
  75. The provided password can be used in subsequent invocations of the Modelverse to login as this user again.
  76. If this command finished successfully, the Modelverse is ready to be used.
  77. The used operations will differ depending on the type of user you are.