Language descriptions are a multi-level issue. In particular, the denition and handling of instantiation semantics connects three levels. This paper looks at two language workbenches without support for multi-level modelling and their handling of the multi-level part of language descriptions. From these observations, the importance of runtime instantiation in terms of an underlying machine is established.
Levels in modelling and in programming are typically considered in a hierarchy
that is given by instantiation. Generally, the main idea of multi-level modelling
is to provide ways to not only inuence the instances of a model, but also the
instances of these, as observed in [
Therefore, instantiation semantics, also known as structural semantics, is a
multi-level issue. The same is true for execution semantics, which is based on
the instantiation semantics since executions are sequences of instance structures.
This paper will not discuss execution semantics; the interested reader is pointed
to [
The problem of instantiation semantics is approached by observing two tools,
LanguageLab [
The experience with the tools is used to propose a framework for the
discussion of instantiation semantics and multi-level modelling. The framework is
used to revisit two old problems of non-multi-level approaches as discussed in
[
This kind of problems has lead to the idea that the OMG architecture is
broken and has to be xed. Multi-level modelling [
Our experience with the tools shows that language descriptions can be handled in the OMG architecture based on the concept of runtime environment.
This paper continues with Sect. 2 which explains levels and their relation to language descriptions. Section 3 looks into tool handling of instantiation semantics. In Sect. 4, underlying machines and instantiation are considered. Section 5 introduces runtime environments, leading to a discussion of the two problems in Sect. 6. Finally, the paper is summarized in Sect. 7. 2
OMG has dened model-driven architecture (MDA) for using models in the
development process, see [
Examples
Grammar example OCL example M3 = meta languages MOF EBNF M2 = languages UML metamodel Java grammar M1 = models UML model a program M0 = instances objects of UML classes a run MOF OCL language a formula a truth value the lowest level. It contains concrete (runtime) objects. The next level (M1) includes the models that describe the M0 objects. On top of M1 there is a level describing how models are formed, which is a meta-model or language level, called M2. Finally, the architecture is closed with a level M3 (meta-language) that is supposed to both describe M2 as well as describing itself. 2.1
The relation between levels is the denition-use relation, where the higher level
provides the denition and the lower level includes the use. This is the
instantiation relation (meta-relation) as for example stated in [
Denition and use refer to roles, not to absolute properties. This means that
the same entity can be both use and denition depending on context, which leads
to the notion of clabjects in [
The denition-use relation is also known as type-element pattern, where a denition (type) gives rise to a number of uses (elements). The connection between denition and use is provided by a semantic function, associating the denition with a set of possible uses. The denition-use relation also appears between compile time (denition) and runtime (use). Typically, the denition is read-only while the use is read/write. 2.2
Formal language descriptions on OMG level M2 have the aspects structure,
syntax, and semantics ([
Language structure denes the concepts of the language and their relation to each other, maybe as a MOF class diagram. This way, the structure aspect allows describing all possible instances in a generative way. In addition, constraints restrict the possible instances by rejecting some of them as invalid.
The syntax aspect can have dierent kinds of presentation, e.g. textual, graphical, and tabular presentations and a mixture of them. It is often dened by the specication of a presentation domain and a one-to-one mapping between presentation domain and structure.
The semantics (meaning) can be given in several dierent ways. For example, semantics can dene language instance execution (operational semantics), or dene a mapping into another language (transformation semantics). An important part of operational semantics is instantiation semantics, i.e. the way how instances of the language are instantiated.
Each language aspect requires a meta-language for its description, which amounts to a potentially large number of meta-languages. MOF is an example of a meta-language for structure, while OCL is an example for constraints.
In this paper, instantiation semantics is most important. It is dened by the language itself (on M2) and might depend on the actual program (on M1). It describes how to create objects at runtime (M0). This way it is a multi-level issue. In fact, none of the other language aspects are multi-level, as structure, syntax, and transformation do only cross one level boundary.
With instantiation semantics, the language bridges three levels, see [
2. the user specication, or the model, and 3. objects of the model.
After the two-level denition-use, this introduces a three-level pattern that is repeated in MDA: M2-M1-M0, M3-M2-M1, M3-M3-M2. 3 3.1
MPS
Meta-Programming System (MPS) [
The general philosophy of MPS can be explained in connection with the OMG four-level architecture. The meta-languages (M3) in MPS are predened by the platform and xed. Being a professional tool, MPS has a large variety of meta-languages to describe all aspects of languages.
The rst main activity in MPS is the description of a language on M2 using the M3 languages. This language description is translated by MPS into MPS internal Java code thereby creating an IDE for the language described. An example is the denition of a Petrinet language with the MPS meta-languages for structure, constraints, text syntax, transformation, intentions, and behaviour.
The second main activity in MPS is the denition of programs or specications on M1 in the IDE for the language dened on M2. MPS provides a projectional editor starting from the internal objects and showing either a default view or a language-dened view. If the programs written should be executable, a transformation has to be provided, typically into Java. If this is the case, then user programs are transformed into standard Java programs.
Finally, MPS does not care for M0, as it relies on the built-in execution and instantiation as given by Java (or C++, if C++ code is generated). This way, M0 need not be handled in MPS.
For the levels M3-M2 and M2-M1, MPS uses its built-in instantiation semantics, which is accessible using an internal language called S (for structure). For instantiation between M1 and M0, the instantiation semantics of the generated code is used. 3.2
LanguageLab [
An example is the basic structure meta-language, which is dened using the basic meta-languages for structure, text syntax and transformation.
LanguageLab favours a relative approach and does not use absolute levels as MDA. In particular, all the levels M3, M2, M1, and M0 are similar in LanguageLab. This is achieved by a modular approach, where the main entity is a module, which can be a language or a specication or a meta-language. Modules come with two sets of interfaces: provided interfaces (lower interfaces) in the sense of denitions, that are available for use, and required interfaces (upper interfaces), which are uses of denitions on the next upper level. This way, LanguageLab mirrors the denition-use relation.
LanguageLab is implemented in Java, but the user has no access to the implementation. The user only sees the languages provided. This is achieved by the denition of a platform, which is the underlying abstract runtime machine of LanguageLab. This platform provides instantiation, presentation and mapping primitives and thus allows languages to be dened and executed. LanguageLab uses the same platform instantiation between any two adjacent levels. 3.3
Both MPS and LanguageLab claim to be bootstrapped, i.e. the meta-languages given in them are dened in the platform itself.
LanguageLab has two parts of the tool, the platform and the languages. The semantics of the languages is provided by mapping them to the elements of the platform. So an editor description is mapped to a runtime editor in the platform. Normally, LanguageLab modules are dened by other LanguageLab modules, but it is not a problem to dene them by themselves. In this case, the upper module is read-only, while the lower one is read/write. For bootstrap, the meta-languages are dened using a read-only version of themselves, which is then translated to the platform primitives. Execution in the platform is given by the underlying LanguageLab machine.
MPS bootstrapping is more tricky. The MPS meta-languages are translated into Java. This Java code is related to several interfaces and stubs for the MPS tool platform. When these interfaces are used, the platform ensures the correct result. In addition to the interfaces, MPS also uses the specications in the languages for cross-referencing and similar purposes.
In order to achieve bootstrapping in MPS, the previous generated code is stored and used for generating the new version of the code. Then, the new code is compiled and a new version of the platform is provided. Again, the old version of the module is used in a read-only way in order to produce the new one. The trick is to generate the same code as before, in particular the same concept identiers, because otherwise it would not be possible to connect the old instances of concepts to the new generated concepts. 4
Semantics, in particular instantiation semantics, is based on an underlying
mechanism that provides basic execution and instantiation. This mechanism could be
very low level as in machine code, where an indication of a memory area leads to
the provision of an actual memory (simple instantiation). It could also be more
high level as in a virtual machine that features class instantiation. In this paper,
the basis is a mechanism that provides general object-oriented instantiation with
the name MOF-VM (see also [
Figure 1 shows the underlying MOF-VM instantiation on the right-hand side. A class RT_ActiveClass is instantiated and yields an object :RT_ActiveClass with the attribute name being Factory . That instantiation is internal.
The left-hand-side shows the language instantiation with Factory being an instance of ActiveClass. While the right bottom shows the default presentation coming from the platform, the left bottom shows the language-dened presentation. Both presentations show the same internal object. The last relation in the gure called applied mapping is explained in Sect. 5.
In Fig. 1, language instantiation is a composition of three relations: applied mapping, MOF-VM instantiation , and presentation. The MOF-VM instantiation is built-in and provides the level-crossing relation in the OMG architecture. By using the MOF-VM instantiation, language denitions do not need to cross levels in order to dene their (linguistic) instantiation.
Instantiation in MOF as a language works in the same way - using the built-in MOF-VM instantiation. MOF-VM instantiation is related to the MDA platform denition and not the language denition of MOF. This means that apart from linguistic and ontological instantiation, there is also MOF-VM (runtime) instantiation, which is used to achieve linguistic instantiation. It is crucial to keep these three apart when trying to understand instantiation semantics.
An important point is the presentation in Fig. 1. The objects on the righthand side (grey) do not have any presentation, because they are objects of the underlying machine (MOF-VM). The notation used in Fig. 1 is therefore just an ad-hoc presentation of these objects.
Even though MOF-VM provides execution and instantiation, it is abstract. There will be a target platform below MOF-VM used as concrete real machine for execution. There are known and proven techniques and methods to achieve this mapping onto a real machine, and this paper does not go into these details. 5
As discussed in Sect. 2, each language has to dene how to instantiate its
elements, e.g. what are instances of classes, modules, methods, and variables. The
structures (possible states) existing at runtime are commonly called runtime
environment (RTE). RTE states are purely structural and runtime state changes
are based on them, see also [
Global elements are runtime elements coming from the language, e.g. predened libraries, program counter, and exception storage. They are xed by the language on M2, and are independent of the specic program. Local elements relate to language concepts and describe how these are instantiated at runtime. They are related to their respective concepts, but are xed on the level of the language (M2), like storage areas for static variables. For any language concept, the instantiation can yield none (1:0), one (1:1), or many (1:n) runtime elements depending on the language.
Dependent elements are similar to local elements, but they depend on the specic program. Objects of classes and stack frames for methods are two examples. They cannot be dened statically on level M2. Instead, on M2 a mapping from the language concepts to the runtime structures can be dened. Again, the mapping can be 1:0, 1:1 and 1:n.
In Fig. 1, the instantiation from M2 to M1 is dened by a (meta-)language on M3. MOF-VM knows by means of an applied mapping that it should use RT_ActiveClass in order to instantiate ActiveClass (Fig. 1). The applied mapping (M2) is a use of the dened mapping (M3), see Fig. 2. All the dierent kinds of runtime elements can be captured with such a dened mapping .
Similarly, the instantiation semantics of a language description (RTE structure) is dened at M2 as a mapping from the program on M1 to the MOF-VM classes on M1, which then get instantiated at M0 as MOF-VM objects.
Based on the concepts presented in Sect. 5, we revisit the two problems mentioned in the introduction: use of non-multi-level approaches leads to (1) ambiguous classication and (2) replication of model elements.
MPS and LanguageLab are not multi-level, but still they do not have these problems. What is their solution? For the problem (2), both tools use a relative approach, where languages are not placed on xed levels, but denitions of languages are placed relative to their uses.
For the solution to problem (1), we have to look more closely into the three
kinds of instantiation. Figure 3 shows the combination of the relations dened
mapping (D), applied mapping (A), and presentation (P). On the left of the gure,
the user view of instantiation is presented. On level M0, a dummy presentation
of the runtime object for Factory is used, in order to make the gure complete.
Most often, the objects on M0 have no language-dened presentation. To the
right, there are the three instances of the language denition and use pattern
stretching over three levels each: M2-M1-M0, M3-M2-M1, and M4-M3-M2. All
level-crossing on the right part is MOF-VM instantiation. A similar pattern is
also used quite often in [
The important part of Fig. 3 is the level M2, as here we have three relations at the same time. The same would be true for any higher levels, but Fig. 3 does not show all these relations. In particular, there is a presentation relation on each level, connecting the runtime view and the language view. These two are separate, therefore there is no ambiguous classication. Clabjects show these two in one presentation, which blurs the dierence between them. BTW, clabjects would look dierently on levels M1 and M0.
When it comes to expressing the mappings, there are many ways to do this. A simple way to dene a mapping for local elements and maybe even for global elements are attributes with potency 2 in a deep modelling context.
A modelling language on M2 may provide as many ontological levels as
needed, see also [
This paper has reviewed the multi-level needs for language descriptions, in particular instantiation semantics. MOF-VM (runtime) instantiation as a basis for linguistic instantiation was found to be the backbone of the OMG four-level architecture and strict meta-modeling.
The denition of runtime environment is essentially the denition of instantiation semantics. RTE is not dened out of thin air, but related to an underlying machine, which is MOF-VM in this article. Several possible kinds of instantiation relations between specication and RTE were identied. They are specied for a language as a mapping between specication and MOF-VM, which is dened at language level and used at specication level.
There are three kinds of instantiation: linguistic, ontological, and runtime instantiation.