Meta Metamodel
The meta2-model builds the core of the entire metamodeling platform. The meta2-model provides the basic concepts to create metamodels and mechanisms. Due to the missing 3D capabilities of traditional metamodeling platforms, we decided to introduce a new meta2-model, which will be described in the following. For the sake of comprehensibility, we separated the meta2-model into two parts: the meta-layer and the instance layer.
A scene_type is the entry point for every metamodel. Scene_types can have attributes and contain classes, relationclasses and can have ports. Furthermore, a scene_type has a property defining whether it is a view with the "is-view" property. Views can restrict which visual concepts are available to show in this view. Scenes can be defined as subscene of other scene_types with the is_sub_scene relationship.
A class is the most basic concept of the metaobject sub-concepts. This concept is identical to the known class concept described in Karagiannis et al. (2002). Considering known modeling languages such as ER diagrams (Chen, 1976), the concepts "Entity," "Attribute," and "Relationship" would be typical instances of the M3 concept class in the new meta²-model. A class can specify the properties "is-reusable" and "is-abstract". The class concept has three sub-concepts: Relationclass, Aggregator Class, and Decomposable Class.
A relationclass is the typical concept to connect multiple other concepts in a metamodel with a visual connector. Considering again the well-known modeling language of ER diagrams, the drawn lines between entities, relationships, and attributes are typical examples of the relationclass concept. In contrast to most other meta²-models, we propose not to link relationclasses directly with the source and target concept of a relation, but to use an intermediate concept for more flexibility. Thus, a relationclass always specifies exactly one from_role and one to_role (refer to Section Roles).
A decomposable class is a concept for allowing the further decomposition of modeling concepts. This concept is similar to the GOPPRR meta²-model of MetaEdit+ or the GME meta²-model of WebGME for abstracting complex metamodel concepts. A typical example of such a decomposition would be a BPMN task into a subtask, which can define a whole separate BPMN process. Thus, a BPMN class "subtask" would be a decomposable_class which defines in what class concepts or scene_type concepts the subtask can be decomposed.
An aggregator class is the concept to describe spatial relationships between classes. For example, is_inside, contains, or touches. A typical use case where this is useful would be the pool class of the BPMN specification. A pool can contain multiple other classes. Thus, a BPMN pool class would be an aggregator_class. Decomposable_class and aggregator_class are both decorator-like extensions of class to define additional attributes that may be needed.
The role concept is a very generic helper concept. Roles are used to connect other meta-concepts of the meta²-model. Thereby, a role can allow for references to classes, relationclasses, scene_types, and ports. All of these references specify a min and max cardinality for the specific reference, i.e., the source or the target end of a relation. This role concept is referenced by the above-mentioned relationclass concept and the attribute_type concepts (refer to Section Attribute Type).
Scene_types, classes, and ports have attributes. The has_attribute relationships can specify the sequence and a UI component value for potential connected graphical user interfaces during modeling. Attributes can have a default value, a min and max property to specify the minimal or maximum number of instances for this attribute, and a facet property to further constrain attribute values. Attributes can be constrained for editing by the attribute_editing_constraint relationship. Every attribute is of exactly one attribute_type.
An attribute_type defines the data type of an attribute. It has a boolean value specifying if an attribute_type is pre-defined and a RegExRule (Regular Expression) to specify the rule for valid values for a specific attribute_type.
A special type of attribute_type is the table_attribute. Attribute_types can have other attributes of any attribute_type assigned to specify the columns of the table_attribute via the has_table_attribute relationship. There, the sequence number of each attribute (column of the table) are defined. One can assign any kind of attribute as column. Thus, potential tables in tables are possible.
Further, an attribute_type can reference a role with the has_reference_role, thus referencing very generically other classes, relationclasses, scene_types, and ports. This concept is similar to the INTERREF concept of the ADOxx meta²-model.
A port can be seen as an interface on top of scene_types and classes. Instead of connecting roles from relationclasses and attribute_types directly to a class or scene_type, they can be connected to a port that is placed on a scene_type or class. This allows the connection options to be restricted more granularly.
Unlike the design for the generic architecture of metamodeling platforms in Karagiannis et al. (2002), mechanisms and algorithms are not strictly separated from the meta²-model. In the following, the integration of mechanisms and algorithms into the meta²-model is described.
An algorithm is a concept to run a predefined procedure upon user request on a conceptual model. Algorithms are stored in the procedure concept. Procedures are once defined and assigned to a scene_type. They are always specific for exactly one scene_type. A procedure has a property definition specifying the algorithm's definition. An example of a modeling method-specific algorithm is the simulation of a business process model in BPMN 2.0 or the token game of a Petri Net. The definition of such algorithms is not restricted to a certain syntax. The interpretation of the value stored in the definition property is left to the metamodeling platform interpreting the meta²-model. However, the "Expression" concept can be used that delivers a set of pre-defined methods.
In contrast to algorithms, a mechanism is a concept used to run a process on instances of scene_types or classes. They are generically defined in the meta²-model in the attribute concept with the default_value property. Since relationclasses are subclasses of the class concept, mechanisms are also applicable for relationclasses. The idea behind mechanisms is that they should be run on every change of a concept attached to the respective attribute_type (has_mechanism relationship). This means that whenever an instance of an attribute is modified, or a new instance of an attached class, relationclass, or scene_type is created or deleted, all attached mechanisms should be executed. The execution of these mechanisms is not subject of the meta²-model itself, but of the implementing metamodeling platform. However, the "Expression" concept can be used that delivers a set of pre-defined methods.
Access rights are managed via the user_group and user concept. All metaobjects can be restricted via a user_group by assigning read_access, modify_rights, and create_rights.
The management of users is based on the user concept. Each user has a login, consisting of a username and a password. Additionally, a user can have one or more user_roles assigned to them through the has_user_role relationship with a user_group.
A generic_constraint is a concept to add additional constraints or rules to a metamodel that cannot be enforced by the main concepts of the meta²-model. For example, to limit the number of allowed start elements in a BPMN model. Generic_constraints are independent of the metaobject concept and therefore have their own UUID, as well as a name and a value property. The content of this value property is not restricted, and the interpretation and execution of the defined rules is handled independently of the meta²-model.
meta2-model-instance-diagram.pdf
The instance-layer of the M2AR meta²-model shows how instances of models (M1-level), conforming to metamodels (M2-level), are instantiated. On the meta-layer introduced before, modeling languages, i.e., metamodels are defined. For example, an instance of a class on the meta-layer is an instance in a metamodel (M2-level). Thereby, the construct class is the M3-level concept on meta²-model level. An instance of an M2-level concept, e.g., an instance of a class in a metamodel, is an instance in a model (M1-level).
The main concepts in the meta²-model on the instance-layer inherit the general properties of the superconcept instanceobject. Each instanceobject has exactly one subconcept that is an instance of the according meta-layer concept, i.e., class, relationclass, role, scene_type, attribute, attribute_type, or port.
Every instanceobject has a UUID for identification and a name, as well as a description. Further, each instanceobject has 2D coordinates for positioning in a 2D modeling environment, as well as relative 3D coordinates (relativeCoordinates3D) for positioning objects in 3D environments relative to the user position. These positions may differ from the coordinates used for the 2D screen representation. Further, each instanceobject can have absolute 3D coordinates (absoluteCoordinates3D) for the positioning of objects using absolute coordinate systems. In addition to the different coordinates, there is a property for the rotation of metaobjects, as well as a visibility property and a property for storing custom_variables. Further, instanceobjects hold a geometry property for storing visualization information which do not hold for all instances (definition on meta-layer), but only for one specific instance. It should be noted that properties on the instance-layer, unlike properties on the meta-layer, are separately specified for every instance.
The scene_instance is the entry point of every model instance. It defines the closed space of a model instance, i.e., a conceptual model. A scene_instance has a direct link to the meta-layer, i.e., to the scene_type concept of the meta²-model. A scene_instance can have connected port_instances, as well as assigned attribute_instances for specific attribute definition (assigned_to relation).
A class_instance is the most basic concept of the instanceobject sub-concepts. A class_instance can, but is not required to be assigned to different scene_instances. Furthermore, a class_instance can be decomposed into another scene_instance or other class_instances via class_decomposition_reference and scene_decomposition_reference relations. This corresponds to the instantiation of the meta-layer concept of decomposable_class. The same is true for aggregations via the class_aggregation_reference. In addition, the class_instance has a subclass relationclass_instance which relates to the meta-layer concept relationclass.
The relationclass_instance has an additional property called linepoints. Linepoints specify the references to all the points of a visual relationclass_instance, which can be any class_instance, as long as this is specified on the meta-layer for the metamodel. Further, a relationclass_instance specifies two references to a role_instance (UUID_relationclass_class_instance) which correspond to the allowed from_role and to_role instances specified in the meta²-model.
The role_instance concept relates to the role concept on the meta-layer. Role_instances are used to connect other instances, such as class_instances, relationclass_instances, attribute_instances, port_instances, and scene_instances.
Attribute_instances correspond to the attribute concept of the meta²-model. They are used to attach specific attribute values to other instances, such as scene_instances, class_instances, and port_instances. An attribute_instance can be used inside a table instance via the table_attribute_reference. If an attribute_instance is used inside a table, the property table_row must be assigned to specify the row inside the table. Furthermore, an attribute_instance can reference a role_instance via the has_role_instance to reference other instances, such as class_instances, relationclass_instances, attribute_instances, port_instances, and scene_instances.
A port_instance relates to the port concept of the meta²-model. It is used as an interface on scene_instances and class_instances via the connected_to_class_instance and connected_to_scene_instance relations. Port_instances can be connected via role_instances to other instances, i.e., relationclass_instances and attribute_instances.
Karagiannis, D., Kühn, H. (2002). Metamodelling Platforms. In: Bauknecht, K., Tjoa, A.M., Quirchmayr, G. (eds) E-Commerce and Web Technologies. EC-Web 2002. Lecture Notes in Computer Science, vol 2455. Springer, Berlin, Heidelberg. https://doi.org/10.1007/3-540-45705-4_19
Li, M., Huang, B., Tian, G. (2022). A comprehensive survey on 3D face recognition methods. Engineering Applications of Artificial Intelligence, Volume 110, 104669. ISSN 0952-1976. https://doi.org/10.1016/j.engappai.2022.104669