Updated old documentation of the process enactment

doc/process_enactment.rst

@@ -15,16 +15,16 @@ Enacting process models
 
 To enact the process model, such as *query_state_space*, you must execute the following operation::
 
-    >>> process_execute("models/query_state_space", "my_", {})
+    >>> process_execute("models/query_state_space", {"pn": "models/my_pn"}, {})
 
 There are three parameters to this function, the first obviously being the name of the process model.
-The second parameter is a prefix for the models used in the process model.
-When executing a process model, data is processed and produced.
-By providing a prefix, the names of these models are first prefixed with the prefix, before they are resolved.
-As such, it becomes possible to execute a process in different contexts.
-
-.. note::
-   This behaviour is likely to change in the future, with the process taking a mapping from the terms in the process model, to actual names.
+The second parameter is a mapping between elements in the process and the actual location in the Modelverse.
+When executing a process model, models are processed and produced, and when a binding is made to an actual model in the Modelverse, this model is actually stored and made available outside of the process.
+For example, in this case we bind the model called *pn* to the model at location *models/my_pn*.
+In the process, every occurence of *pn* is therefore processed at that location, both for input models (e.g., when chosing the Petri net to operate on) and output models (e.g., when this is the result).
+It is not necessary to define such a mapping, as it is perfectly possible that all models are created inside the process and are intended to stay in there.
+For example, in the power window case study, all DSMs are created during the process and we are only interested in the verification result, meaning that no models ``escape`` the process.
+If we were to retain the DSMs, for example to push them into another process later on, we could bind all these models to an actual location in the Modelverse.
 
 The third parameter is a dictionary of callbacks.
 For each activity, it is possible for users to define a callback function.