Keywords

1 Introduction

The methodology of Domain Specific Modelling (DSM) becomes more and more popular today, allowing to overcome the known issues of the “universal” modelling approach [1]. The sense of DSM is development of Domain Specific Languages (DSLs), applicable for modelling properties of particular domains. A DSL is built inside a so called metamodel, defining the concrete syntax of the language. The abstract syntax of a DSL is defined in the frame of the meta-metamodel as e.g. MOF [2], GOPPRR [3], MGA [4] etc.

Emphasizing the power of the existing DSM approaches, they have a number of issues, caused by the lack of generalisation and formalisation:

  • the metamodel based DSLs are mostly descriptive, i.e. not expressive for the definition of methods for solving domain specific tasks;

  • the applicability of a DSL by the generation of software data and code is limited;

  • while the DSM approach is intended for using by domain experts, the obligatory involvement of IT specialists for development of code generators is needed;

  • for code generation an additional external language should be used, which is not linked with specifics of a modelled domain;

  • the meta-metamodel, used for metamodels development, does not reflect the mathematical structure of a considered domain and is hardcoded inside a DSM tool.

Let’s consider the principles of the proposed approach to the metamodels development, allowing to overcome the specified above issues:

  • the formal definition of the object of modelling—the domain, as the set of entities, linked by the forming mathematical structure and the domain specific relationships;

  • the definition of the meta-metamodel and the metamodel as the formal systems, allowing to fix correspondingly the structural and domain specific properties;

  • the mathematical structure of a domain is defined at the meta-metamodel level and next is used as the carrier of domain specific properties;

  • the additional level of the metamodelling architecture is introduced, which allows to develop the meta-metamodels, having different mathematical semantics.

While the existing metamodelling approaches use the predefined mathematical formalisms (mostly, graphs) for structuring domain properties, here the development of meta-metamodels in the different mathematical semantics is possible. Additional level of the metamodelling architecture allows to express properties of domains in terms of set theory and to reflect different mathematical structures (algebraic, topological, differential, geometrical etc.). Corresponding mathematical operations are integrated in the metamodel and used for solving domain specific tasks. Generation of software data and code becomes the partial case of the proposed metamodelling approach.

The paper is organized as follows. First the new metamodelling architecture is discussed in comparison with existing approaches. Section 97.3 of the paper shows applicability of the proposed approach for producing the graph based metamodels for modelling software systems. Section 97.4 expands the practical applications for requirements engineering, business process modelling and solving tasks of multidimensional physical domains. The conclusion, plan of future research and references list finalize the paper.

2 Metamodelling Architectures

The methodology MOF (Meta Object Facility) [2] was used by the OMG (Object Management Group) consortium for development of the Unified Modelling Language (UML). MOF has the four levels of the metamodelling architecture. The top level is the meta-metamodel (M3), defining the language for development of the metamodels (having the level M2). The level M2 (here, UML) used for development of the domain models of the level M1 (the UML-models). The last is the level of data (M0), describing the concrete instances of M1. The MOF architecture is based on the object-oriented methodology of software systems design.

The meta-metamodel GOPPRR (Graph-Object-Property-Port-Role-Relationship) allows to produce metamodels inside the graph based notations, by means of connection of objects by relationships, definition of domain properties (attributes) and roles [3]. Each of the GOPPRR concepts a metatype is called. As MOF, the metamodelling architecture of the GOPPRR in four levels can be shown (see the Fig. 97.1).

Fig. 97.1
figure 1

The GOPPRR metamodelling architecture

Full size image

The proposed approach also has the multiple-level metamodelling architecture, but it semantics differs from the existing methodologies. All of the metamodels are considered to be formal systems; they contain an alphabet of types, a grammar and operations. We introduce the additional level of the metamodelling architecture—the meta-meta-metamodel (M4), as a formal system, that is built on the basis of set theory. M4 includes the meta-metatype “element of a set”, set operations and grammar rules, which (taken together) allow us to specify a set structure. This approach allows us to consider a domain as a set of heterogeneous entities, having domain specific properties and linked by different kinds of mathematical structures.

Formally, we define a domain as a set of entities D, linked by structural S and domain specific P relationships:

$$ D = \{ d_{1} ,d_{2} \ldots d_{N} \} ,\,\,S,P \subseteq D \times D $$
(97.1)

where N is a power of D. Each element of D can have attributes, which we consider as unary relationships on D. 0-ary relationships are used to identify elements of D. Binary and other relationships are used to fix mathematical structure of D.

All of the levels of the proposed metamodelling architecture contain not only descriptive elements, such as in MOF or GOPPRR, but also procedural part, implemented with software functions.

Following our proposal, the architecture for development of the graph based metamodel on the Fig. 97.2 is shown. Here a node and an edge of a graph serve as the mathematical metatypes for development of domain specific metamodels types (an attribute is the inherent part of a node and of an edge). The node and the edge are produced from the meta-meta-metamodel as the having algebraic structure subsets of the composing domain entities. Note, while GOPPRR [3] and MGA [4] also use the graphs for structuring domain specific properties, this is a partial case of the proposed approach, where development and using the different mathematical structures is possible.

Fig. 97.2
figure 2

The levels of the proposed metamodelling architecture

Full size image

The implementation of mathematical operations of the metamodels at all levels of the proposed architecture, forms the Application Program Interface (API) of the corresponding software tool. The API of M4 contains the methods for manipulation with the elements of a set of composing domain entities. The API of M3 is the operations with subsets (e.g., with a node and an edge of a graph, and in the general case with any model objects of the considered domain). For M2, the API contains the metamodel processing routines (here, the metatypes of the level M3 become domain-specific types, i.e., to the mathematical subsets the semantics of the domain is assigned). M1 contains instances of the types and definitions of domain-specific methods, implemented with the APIs of all the previous levels. M0 is data values and processes in the computer memory (instances of the methods, defined at the level M1).

3 Development of Graph-Based Metamodels

Let us consider the mathematical method for producing the graph-based meta-metamodel in the context of proposed approach. Its alphabet includes the metatypes node N and edge E of the graph Gr = (N, E); the grammar G Gr is the set of rules, defining the possibility {true, false} of the connection of nodes n i , n j by the edge e k  = (n i , n j ), n ϵ N, e ϵ E

$$ G_{Gr} = \left\{{\left({n_{i} ,n_{j} } \right)|g_{k}\,\epsilon\,\left\{{true,\,false} \right\},n_{i} ,n_{j}\,\epsilon\,N,i,j = 1..M,k= 1..K} \right\} $$
(97.2)

where M is a power of N. The number of rules K depends on the properties of the graph Gr (is it directed, are loops possible, etc.).

At the level of metamodel development, to the nodes and the edges of the meta-metamodel the semantics of domain is assigned. For example, the node N can be the metatype for definition of the types of software tasks and synchronization objects, and the edge E can be the metatype for definition of the types of channels (communication protocols) between tasks and synchronization objects. This metamodel will include the alphabet, containing typical for parallel programming synchronisation objects (critical section, mutex, semaphore, resource, FIFO etc.) and software tasks (driver, application etc.); the grammar rules, specifying the valid interactions of software tasks via synchronisation objects, and operations, used for definition of code generation functions.

Table 97.1 shows an example of the definition of the metamodel for modelling the parallel concurrent software system inside the graph based meta-metamodel.

Table 97.1 Levels of metamodelling architecture for a software system modelling
Full size table

In this example, a Node and an Edge are the mathematical metatypes of graph based meta-metamodel M3. Domain specific types are the nodes Task, Sync and the edges PutData, GetData, which compose the alphabet of M2 metamodel and are used to create instances at the M1 level. M2 also defines the grammar rules for combining instances of the types by using predicates PutData(Task, Sync) and GetData(Sync, Task). These grammar rules correspond to the edges of the graph-based meta-metamodel and are used for development of code generation methods (implemented by walking the graph based model M1). The M1 model of software system includes instances of Task 1 , Task 2 … Task T and synchronization objects Sync 1 , Sync 2 … Sync S , linked by the channels of interaction PutData, GetData (where T, S—are the number of tasks and the number of synchronization objects in the model respectively).

For the interesting reader, to show the applicability of described graph based metamodel, we can refer to the metamodel of interacting entities [5], which was used for development of a real-time operation system [6] and for modelling distributed parallel real-time software [7].

The definition of the metamodel alphabet as the set of attributed types and the domain model as the instances of the types, having the concrete values of attributes, make possible the formal checking a model in its state space. Due to including mathematical methods in the metamodel the checking properties of behaviour of a real-time system (e.g. absence of deadlocks) was applied. The graph based methods (e.g. Dijkstra’s algorithm) for development of the code generation functions (e.g. routing table of a real time operation system) were used.

4 Other Applications of the Metamodelling Approach

Except development of graph-based metamodel for software systems design, the applicability of the proposed approach was proven for the next domains:

  • requirements engineering (RE), where conceptual metamodelling for systems specification was used. The set of the typical for the RE concepts formed the alphabet of the metamodel, which symbols were the types for instantiation—definition of the concrete statements describing a system properties and behaviour. The methods of the graph based meta-metamodel were used to check correspondence of the graph of architectural decomposition to the graph of initial requirements, generate the document of systems specifications, made the control of versions etc. The conceptual metamodel was further expanded by the Finite State Machine formalism [5]. This allows us to build the domain specific models of processes on the base of the ontology of a domain. To each concept of ontology the state transition attribute was added. The process grammar was the set of rules, defining the state transitions of conceptual model of a system description. e.g. only after capturing requirements user can move to the specification stage, next to the phase of architectural modelling etc. Such the approach allows us to manage users activity to achieve the goal of a process in a given time (up to deadline);

  • development of the metamodel, based on the vector algebra and the logic of syllogisms. Here vectors were used as the metatypes for producing the logical types of the metamodel alphabet. In the practical implementation [8], the alphabet of the metamodel on the base of the types of categorical syllogisms was developed. Due to using vector algebra for the definition of the metamodel, the operations on syllogisms as operations on vectors in linear vector space were implemented. This allows us to develop the algorithm for automatic geometrical theorem proving. The approach was used for development of the logic for optical computers, where at physical level vectors were implemented as laser beams;

  • development of the metamodel for multidimensional physical domains [9]. The alphabet of the meta-metamodel was defined as the set of the basic (corresponding to the dimensions of the physical space) geometrical objects, i.e. point, line, surface and 3D region. For metamodels development we set distributions of physical properties among the defined with the meta-metamodel geometrical structures. Due to considering objects as the sets of geometrical points in the physical space, the grammar of the metamodel in the terms of Boolean operations on geometrical subsets was defined. This grammar limits the possible compositions of the geometrical objects in the 3D space. The mathematical methods of the metamodel correspond to the solutions of multidimensional tasks of the integral and deferential calculus. As the interesting application of the metamodelling approach for physical domains the design of metamaterials (artificial composites with specific optical properties) can be mentioned [10].

5 Plan of Future Research

The plan of research is further exploring the properties of the metamodels, allowing to fix different mathematical structures:

  • the formal definition of the metamodels, the mathematical structure of its types, grammars and operations at all levels of the metamodelling architecture;

  • learning the linguistic properties of the metamodels, incl. the possibility of reduction of the grammars into the normal Chomsky form;

  • definition of the method for metamodels composition, allowing to combine the declarative and imperative constructs (alphabet, grammar and operations);

  • exploring the textual and the visual forms of expression of metamodels and development of the method for its combination;

  • expansion of the approach on the other types of mathematical structures (metric, geometrical, differential, topological, etc.).

6 Conclusion

The new approach for metamodels development is proposed. The metamodelling architecture is decomposed into the layers, allowing to fix the structural and the domain specific properties. This allows to take into account the mathematical structure of considered domains. The additional set-based level of the metamodelling architecture is introduced, which allows to define the meta-metamodels in the different mathematical semantics.