|
|
@@ -65,13 +65,47 @@ This can be done with the *alter_context* operation::
|
|
|
Note that this operation executes locally, as it only alleviates the user from having to specify this all the time.
|
|
|
As such, there is no error checking on the provided parameters.
|
|
|
|
|
|
+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.
|
|
|
+
|
|
|
+Sometimes, it might be necessary to remove all context information, for which a dedicated operation is provided::
|
|
|
+
|
|
|
+ >>> reset_context()
|
|
|
+
|
|
|
+Note that for our Python wrapper, the Modelverse will automatically search for all defined metamodels if no context is set.
|
|
|
+
|
|
|
Tool Semantics
|
|
|
--------------
|
|
|
|
|
|
-Metamodel Finding
|
|
|
------------------
|
|
|
+Another aspect of model conformance, and the third entry in the *model_types* operation, is the tool semantics to use.
|
|
|
+The Modelverse considers not only syntactical differences at the M3 level, but also semantical differences.
|
|
|
+For example, different tools might convey different semantics for the inheritance relation, such as in the case of multiple inheritance.
|
|
|
+In the Modelverse, the conformance semantics is also explicitly modelled, and can therefore be altered.
|
|
|
+When checking for conformance, it is possible to define multiple such conformance relations.
|
|
|
+And thanks to the use of multi-conformance, it might very well be possible that a model conforms with different tool semantics as well.
|
|
|
|
|
|
-TODO
|
|
|
+New conformance relations can be defined as activities, which take a model, a type mapping, and a metamodel.
|
|
|
+An example for (a subset of) AToMPM and MetaDepth conformance semantics is presented in the *examples/* folder of the Modelverse.
|
|
|
+In this example, the same model is checked with both AToMPM and MetaDepth conformance semantics, which yields different results.
|
|
|
+
|
|
|
+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.
|
|
|
+
|
|
|
+Type Mapping Finding
|
|
|
+--------------------
|
|
|
+
|
|
|
+In several cases, the type mapping model can be automatically found by the Modelverse itself.
|
|
|
+Indeed, if only a single such type mapping would make sense, it can greatly aid users if this is automatically found.
|
|
|
+For now, this is only the case for several simple metamodels, such as *formalisms/Bottom* and *formalisms/TypeMapping*.
|
|
|
+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::
|
|
|
+
|
|
|
+ >>> model_types("type_mappings/20")
|
|
|
+ [("formalisms/TypeMapping", None, None)]
|
|
|
+ >>> element_list_nice("type_mappings/20")
|
|
|
+ [...]
|
|
|
+ >>> model_types("type_mappings/20")
|
|
|
+ [("formalisms/TypeMapping", "type_mappings/21", None)]
|
|
|
+
|
|
|
+A type mapping will be automatically detected if the given model has an incomplete type mapping to the selected metamodel.
|
|
|
+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.
|
|
|
|
|
|
Conformance Bottom
|
|
|
------------------
|
