The family of languages that builds the foundation of the MEMO method is intended to feature a high degree of inter-language integration. For this purpose, the languages need to share common concepts. In order to define concepts that are semantically equivalent, it is recommendable to use the same meta modelling language for specifying the MEMO modelling languages. The previous version of the meta modelling language used for this purpose needed a revision. At the same time, there was need to account for alternative approaches to specifying modelling languages, especially those offered by the OMG or the Eclipse foundation. This report starts with an analysis of requirements that should be accounted for by a meta modelling language. Subsequently, the UML infrastructure library and meta object facility (MOF) are evaluated against these requirements. In addition to that, the report presents an evaluation of the Ecore model, which serves to represent meta models within the Eclipse Graphical Modeling Framework (GMF). The evaluation of both approaches shows that none of them is satisfactory as a meta modelling language for enterprise modelling. Then, the new version of the MEMO meta modelling language (MML) is presented. The language specification consists of a meta meta model that specifies that semantics and abstract syntax and a corresponding graphical notation (concrete syntax). The new version features a concept called intrinsic features that allows for differentiating between features that apply to types and those that apply to instances. It also includes a modified graphical notation that supports a clear distinction of meta models from models on other levels of abstraction. Finally, the report presents the outline of a tool that supports the creation and editing of MEMO meta models as well as their transformation into representations which can be used in the Eclipse modelling framework.

Revised Version
This version was created on April 25th, 2010. The revision is restricted to a few changes. First, there are additional concepts to define data types of attributes (see Figure 6). In the previous version, the particular basic types such as Integer, String etc. were specified as specialisations of the generic type DataType. However, this is not appropriate: Using DataType in the meta meta model implies to instantiate it on the meta level. The instantiation of DataType was not meant to result in particular values, such as 35 or ‘Customer’, but in data types. To express this different abstraction, DataType was changed into MetaDataType and the specialisation relationships were changed into instantiation relationships. As a consequence, the meta meta model itself required a small modification, too: The single occurrence of DataType was changed into MetaDataType. Furthermore, the meta meta model is extended to provide for specifying attributes with enumerations and intervals. Second, the meta meta type MetaAttribute is extended by the attributes deferred, deferredExternal and simulation. They allow to express that corresponding values may be deferred from other parts of a model or from external sources – or that they may serve simulation purposes. Finally, the attribute isSingleton was added to MetaEntity to allow for specifying meta types as singletons.