conformance.rst 9.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146
  1. Conformance
  2. ===========
  3. The conformance relation takes a central role in the Modelverse.
  4. In contrast to most other tools, the conformance relation is, as all other things, explicitly modelled.
  5. As such, it can be altered quite easily and offers many degrees of flexibility not found in other tools.
  6. The primary operation to use is *model_types*, which lists the types with which the model is typed::
  7. >>> model_types("models/my_pn")
  8. [("metamodels/PetriNets", "type_mappings/1234", None)]
  9. This operation returns a list containing tuples.
  10. In the tuple, the first entry denotes the metamodels location in the Modelverse.
  11. The second entry denotes the type mapping used to conform to this specific metamodel.
  12. The third and last entry denotes the conformance semantics that is used for this conformance, and will be discussed separately.
  13. The type mapping relation is itself a model, typed by the *formalisms/TypeMapping* metamodel.
  14. As such, it is possible to open the model denoted over there and even alter it, thereby directly altering the type mapping in the model.
  15. This is useful in a variety of scenarios, where direct access to the type mapping relation is required.
  16. Note that these conformance relations are the result of the stored links, which might be correct.
  17. Indeed, the local and global constraints might be invalidated later on, or even in the context of language evolution, where for example the metamodel changes, these relations can be out of date.
  18. To verify that the relation still holds, users can invoke the *verify* operation with the model and metamodel::
  19. >>> verify("models/my_pn", "metamodels/PetriNets")
  20. "OK"
  21. If the result is the string "OK", everything is fine.
  22. Otherwise, the string value denotes the error message, which contains the name of the element that violates conformance (e.g., which has no type anymore).
  23. While the metamodel has to be specified in the verify operation, the type mapping is automatically determined based on the stored information of the *model_types* operation.
  24. Multi-Conformance
  25. -----------------
  26. As indicated by the fact that the *model_types* operation returns a list,
  27. The Modelverse supports multiple conformance relations to hold simultaneously.
  28. Upon creation, every model is typed by the metamodel used for its instantiation.
  29. For example, when creating a PetriNets metamodel::
  30. >>> model_add("formalisms/PetriNets", "models/my_pn")
  31. >>> model_types("models/my_pn")
  32. [("metamodels/PetriNets", "type_mappings/1234", None)]
  33. Additionally, different conformance relations can be defined.
  34. For example, if there is a new metamodel called *formalisms/PetriNets_inhibitor*, it is possible to force a conformance relation there as well::
  35. >>> conformance_add("models/my_pn", "formalisms/PetriNets_inhibitor")
  36. >>> model_types("models/my_pn")
  37. [("metamodels/PetriNets", "type_mappings/1234", None),
  38. ("metamodels/PetriNets_inhibitor", None, None)]
  39. Although the relation has been added, it cannot be guaranteed that this relation actually holds.
  40. Indeed, the type mapping model is undefined, meaning that there is no way to verify this relation in itself.
  41. Therefore, the *conformance_add* operation is only to be used to ensure that the necessary links are created and that it is possible to add a type mapping model or further specify it.
  42. Whenever an operation is being made that opens the model (e.g., instantiation of new elements), a metamodel has to be additionally specified, such that the model can be opened in the correct context.
  43. In the Python wrapper, this is abstracted to alleviate the user of constantly having to specify the metamodel every operations.
  44. When an operation is executed that gives information on the metamodel (e.g., *model_add*, *transformation_execute*), this information is stored and used behind the scenes.
  45. Nonetheless, it is possible that the user wants to switch the context manually.
  46. This can be done with the *alter_context* operation::
  47. >>> alter_context("models/my_pn", "formalisms/PetriNets_inhibitor")
  48. Note that this operation executes locally, as it only alleviates the user from having to specify this all the time.
  49. As such, there is no error checking on the provided parameters.
  50. When a model is used without prior creation (e.g., reusing a model defined by another user), the user must specify the context in advance, also using the *alter_context* operation.
  51. Sometimes, it might be necessary to remove all context information, for which a dedicated operation is provided::
  52. >>> reset_context()
  53. Note that for our Python wrapper, the Modelverse will automatically search for all defined metamodels if no context is set.
  54. Tool Semantics
  55. --------------
  56. Another aspect of model conformance, and the third entry in the *model_types* operation, is the tool semantics to use.
  57. The Modelverse considers not only syntactical differences at the M3 level, but also semantical differences.
  58. For example, different tools might convey different semantics for the inheritance relation, such as in the case of multiple inheritance.
  59. In the Modelverse, the conformance semantics is also explicitly modelled, and can therefore be altered.
  60. When checking for conformance, it is possible to define multiple such conformance relations.
  61. And thanks to the use of multi-conformance, it might very well be possible that a model conforms with different tool semantics as well.
  62. New conformance relations can be defined as activities, which take a model, a type mapping, and a metamodel.
  63. An example for (a subset of) AToMPM and MetaDepth conformance semantics is presented in the *examples/* folder of the Modelverse.
  64. In this example, the same model is checked with both AToMPM and MetaDepth conformance semantics, which yields different results.
  65. Although multiple conformance relations can be defined, all built-in Modelverse operations (e.g., *all_instances*) are based solely on the built-in Modelverse conformance relation for performance reasons.
  66. Type Mapping Finding
  67. --------------------
  68. In several cases, the type mapping model can be automatically found by the Modelverse itself.
  69. Indeed, if only a single such type mapping would make sense, it can greatly aid users if this is automatically found.
  70. For now, this is only the case for several simple metamodels, such as *formalisms/Bottom* and *formalisms/TypeMapping*.
  71. When automatic detection is possible, users can indeed just execute an *alter_context* operation, after which the model can be opened immediately, even without a type mapping being specified::
  72. >>> model_types("type_mappings/20")
  73. [("formalisms/TypeMapping", None, None)]
  74. >>> element_list_nice("type_mappings/20")
  75. [...]
  76. >>> model_types("type_mappings/20")
  77. [("formalisms/TypeMapping", "type_mappings/21", None)]
  78. A type mapping will be automatically detected if the given model has an incomplete type mapping to the selected metamodel.
  79. This can be the case if no type mapping is specified at all, or if the current type mapping is pruned for deleted elements in the metamodel (removing an element in the metamodel does not automatically remove the instances in the model), or if new elements are added at the model level without specifying a type.
  80. Conformance Bottom
  81. ------------------
  82. The Modelverse makes the Physical Type Model (PTM) available in the linguistic dimension in the form of the Conformance Bottom relation.
  83. For each model, it is possible to open it using its defined metamodels, but also as an instance of the *formalisms/Bottom* model.
  84. This metamodel has no special definition in the Modelverse, but it is relatively simple and does not constrain anything.
  85. As such, it is guaranteed that each model in the Modelverse will conform to it.
  86. Additionally, the model is very simple, meaning that it is possible to automatically deduce the type mapping::
  87. >>> model_types("models/my_pn")
  88. [("formalisms/PetriNets", "type_mappings/123", None)]
  89. >>> element_list_nice("models/my_pn")
  90. [{"__id": "__1", "__type": "Place", "tokens": 1, "name": "my_place"}]
  91. >>> alter_context("models/my_pn", "formalisms/Bottom")
  92. >>> element_list_nice("models/my_pn")
  93. [{"__id": "__1", "__type": "Node"},
  94. {"__id": "__234", "__type": "Node"},
  95. ...]
  96. As the conformance bottom relation can be automatically deduced, this detection can also be triggered when executing activities.
  97. Indeed, when an activity is executed that consumes a model conforming to *formalisms/Bottom*, any possible model can be passed to it, and the conversions will happen automatically and the conformance bottom relation will also be stored explicitly afterwards::
  98. >>> model_types("models/my_pn")
  99. [("formalisms/PetriNets", "type_mappings/123", None)]
  100. >>> transformation_execute_MT("models/count_nodes", {"model": "models/my_pn"}, {})
  101. >>> model_types("models/my_pn")
  102. [("formalisms/PetriNets", "type_mappings/123", None),
  103. ("formalisms/Bottom", "type_mappings/456", None)]
  104. Note that the same is true for other metamodels to which conformance can be automatically deduced, such as the type mapping metamodel.
  105. When changes are made to the model in the context of conformance bottom, no typing information is created for the other metamodels, as indeed there is no notion of typing upon creation.
  106. As such, previously conforming models will no longer conform without also specifying the type of the newly created elements.
  107. In the future, we intend to add completely automated type mapping completion, thereby automatically finding an applicable type for the new elements.
  108. For now, the type mapping model has to be manually extended with typing information for the missing elements.
  109. A model with an incomplete type mapping will not be opened by the Modelverse, as it cannot guarantee that all operations would work!