Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA2/Model Space"
m (VIATRA2 Model Space moved to VIATRA2/Model Space: Refactor into VIATRA2 namespace.) |
(moved content from modelediting page, that page redirects here) |
||
| Line 1: | Line 1: | ||
| − | = | + | = Model space = |
| − | Models and metamodels are all stored uniformly in the | + | Models and metamodels are all stored uniformly in the '''VPM model space''', which provides a very flexible and general way for capturing languages and models on different meta-levels and from various domains (or technological spaces). |
| − | '''Special features''' of the VPM model space | + | '''Special features''' of the VPM model space, uncommon in other modelling environments: |
| − | * enumerate all instances of a metamodel element (in addition to access the class from an instance model element) | + | * every model element has a locally unique name, and thus a globally unique fully qualified name induced by the containment hierarchy |
| − | * navigate references (relations) in both directions | + | * you can enumerate all instances of a metamodel element (in addition to access the class from an instance model element) |
| − | * assign multiple types for a model element (multi-domain editing) | + | * you can navigate all references (relations) in both directions |
| + | * you can assign multiple types for a model element (multi-domain editing) | ||
| + | * models and metamodels are represented in the same model space | ||
* reliable and simultaneous manipulation of metamodels and models (to enable generic / higher-order transformations) | * reliable and simultaneous manipulation of metamodels and models (to enable generic / higher-order transformations) | ||
| + | * metamodels can adhere to a metamodel themselves | ||
| + | * edges (relations) can connect other edges and even individual attribute values | ||
| + | * elements can be dynamically retyped | ||
| − | + | Here we focus on the manual editing possibilities of the model spaces although it is possible (and preferred) to populate the model space by [[VIATRA2/UseCases/ModelExportImport|importing]] existing models. | |
| − | * | + | |
| − | * | + | ===The structure of the Model Space=== |
| − | * | + | The model elements of the VPM model space can either be entities or relations. '''Entities''' represent the basic concepts of the modeling domain, while '''Relations''' describe the associations between Entities. Apart from Relations, three special relationships are modeled in a distinct way: |
| + | * <code>instanceOf</code> relationships represent the connection between model and metamodel elements, | ||
| + | * <code>supertypeOf</code> relationships are used to create a type inheritance hierarchy (with subset semantics) and | ||
| + | * containment relationships are used to create an explicit containment hierarchy. | ||
| + | |||
| + | [[Image:VIATRA2_GettingStarted_VPM.png|The VPM metamodel]] | ||
| + | |||
| + | Entities can have entity types, relations can have relation types. A relation type connects the metamodel elements that are the source and destination types of the particular relation type. Instance relations connect model elements conforming to these types (i.e. connected by ''instanceOf'' to the appropriate type, or one of its subtypes). Attribute values are represented as entities, connected by a relation to a host entity; the value itself (actually a character string representation) can be stored as the '''value''' of the attribute entity. Conversely, attribute data types (e.g. integer) are also entites, see the ''datatypes'' namespace for suggested metamodel types of attribute entities; of course, there are also relation types that connect the host entity type to the attribute data type. It is important to point out that Relations connect arbitrary model elements, thus they can also connect other Relations. All this flexibility is in place so that the Model Space can act as a common ground for integrating models from various sources. | ||
| + | |||
| + | ==Creating and editing model spaces== | ||
| + | A model space can be created using the '''Create VPM Model Space''' wizard under the ''File/New...'' menu item. The wizard is capable of generating model fragments into the model, e.g. the VPM metamodel or the UML metamodel. | ||
| + | |||
| + | [[Image:VIATRA2_GettingStarted_NewVPMModelSpace.png|Adding model space fragments]] | ||
| + | |||
| + | When opening a model space, the contents of the model space is presented in a tree editor (similar to e.g. the EMF tree editor): in a tree structure the contents of the model space is displayed organized the containment relationships. To edit existing model elements, the ''Properties'' view has to be used, where it is possible to set the name attribute and the instanceOf and supertypeOf relationships of all model elements, and the end points of the relations. To help editing, the view gives some hints about the possible values usable as the currently edited value (''autocomplete'' functionality). | ||
| + | |||
| + | New entities or relations can be added using the context menu of the model elements, where an ''Add Entity'' and ''Add Relation'' items are present. | ||
| + | |||
| + | [[Image:VIATRA2_GettingStarted_ModelSpaceEditing.png|Editing model spaces]] | ||
| + | |||
| + | In addition to the tree editor a [[VIATRA2/ExtraFeatures/ModelVisualisation|graph visualisation component]] can be used to display the contents of the model space without the strict hierarchy enforced by the containment / namespace structure of the model space, thus giving a more meaningful overview of the models. The visualisation does not provide extra editing facilities, but the editing facilities of the ''Properties'' view are usable. | ||
Revision as of 05:19, 17 March 2010
Model space
Models and metamodels are all stored uniformly in the VPM model space, which provides a very flexible and general way for capturing languages and models on different meta-levels and from various domains (or technological spaces).
Special features of the VPM model space, uncommon in other modelling environments:
- every model element has a locally unique name, and thus a globally unique fully qualified name induced by the containment hierarchy
- you can enumerate all instances of a metamodel element (in addition to access the class from an instance model element)
- you can navigate all references (relations) in both directions
- you can assign multiple types for a model element (multi-domain editing)
- models and metamodels are represented in the same model space
- reliable and simultaneous manipulation of metamodels and models (to enable generic / higher-order transformations)
- metamodels can adhere to a metamodel themselves
- edges (relations) can connect other edges and even individual attribute values
- elements can be dynamically retyped
Here we focus on the manual editing possibilities of the model spaces although it is possible (and preferred) to populate the model space by importing existing models.
The structure of the Model Space
The model elements of the VPM model space can either be entities or relations. Entities represent the basic concepts of the modeling domain, while Relations describe the associations between Entities. Apart from Relations, three special relationships are modeled in a distinct way:
-
instanceOfrelationships represent the connection between model and metamodel elements, -
supertypeOfrelationships are used to create a type inheritance hierarchy (with subset semantics) and - containment relationships are used to create an explicit containment hierarchy.
Entities can have entity types, relations can have relation types. A relation type connects the metamodel elements that are the source and destination types of the particular relation type. Instance relations connect model elements conforming to these types (i.e. connected by instanceOf to the appropriate type, or one of its subtypes). Attribute values are represented as entities, connected by a relation to a host entity; the value itself (actually a character string representation) can be stored as the value of the attribute entity. Conversely, attribute data types (e.g. integer) are also entites, see the datatypes namespace for suggested metamodel types of attribute entities; of course, there are also relation types that connect the host entity type to the attribute data type. It is important to point out that Relations connect arbitrary model elements, thus they can also connect other Relations. All this flexibility is in place so that the Model Space can act as a common ground for integrating models from various sources.
Creating and editing model spaces
A model space can be created using the Create VPM Model Space wizard under the File/New... menu item. The wizard is capable of generating model fragments into the model, e.g. the VPM metamodel or the UML metamodel.
When opening a model space, the contents of the model space is presented in a tree editor (similar to e.g. the EMF tree editor): in a tree structure the contents of the model space is displayed organized the containment relationships. To edit existing model elements, the Properties view has to be used, where it is possible to set the name attribute and the instanceOf and supertypeOf relationships of all model elements, and the end points of the relations. To help editing, the view gives some hints about the possible values usable as the currently edited value (autocomplete functionality).
New entities or relations can be added using the context menu of the model elements, where an Add Entity and Add Relation items are present.
In addition to the tree editor a graph visualisation component can be used to display the contents of the model space without the strict hierarchy enforced by the containment / namespace structure of the model space, thus giving a more meaningful overview of the models. The visualisation does not provide extra editing facilities, but the editing facilities of the Properties view are usable.