An eXecutable metamodelling facility for domain specific language design.

Syntax The abstract syntax of a language describes the vocabulary of concepts provided by the language and how they may be combined to create models or programs. It consists of a definition of the concepts, the relationships that exist between concepts and may also include rules that say how the concepts may be legally combined. It is important to emphasize that a language’s abstract syntax is independent of its concrete syntax and semantics. Abstract syntax deals solely with the form and structure of concepts in a language without any consideration given to their presentation or meaning. Semantics The semantics of a language describes what models or programs in the language actually mean and do. In the context of programming languages, an execution semantics is essential in order to run programs written in the language. Semantics are also important in the context of modeling languages. Without semantics, modeling languages like UML offer little more than a collection of notations and their usefulness is reduced. Language Definition and Metamodels The need to capture languages independently in a platform independent format is not new. One of the most widely known standards for this purpose is the MOF (the Meta Object Facility) [3]. The purpose of the MOF is to define a common way of capturing meta-data. Languages expressed in terms of MOF can be related to each other simply because they are defined in the same way. For example, if one wants to move from a model written in UML to a model that describes a Java program, the process is greatly eased because they are represented in the same way. The way that MOF describes languages is through metamodels. Typically, a metamodel is a model of the concepts that are provided by the standard. In this case of UML, this might include such concepts as Class, Attribute, Operation, and so on. Although the MOF is a good starting point for defining languages, it has a number of limitations: • It is not rich enough to capture semantic concepts in a platform independent way. For instance, the execution of a state machine or a business process cannot be expressed in MOF. The tool designer must resort to implement these aspects in an external implementation technology such as Java. • MOF does not provide a means of expressing the concrete syntax of a language, whether it is a textual or diagrammatical syntax. Whilst MOF models can be exported in terms of XML, this is of limited use to modellers, who require a more human readable form. • MOF does not provide abstractions for capturing user interfaces and tools in a generic fashion. This means that either the language designer has little control over the user interface of a tool that supports the language, or these aspects must be encoded in a platform specific way. • There is currently no way of defining both uni-directional and synchronised mappings between MOF models. These are essential to describe language transformations and the synchronisation of language elements. Whilst the QVT standard is aiming to address the issue of a uni-directional language, the need for a synchronised mapping language is paramount in order to describe synchronisation between language elements and diagram editors, user interfaces, and so on. An eXecutable Metamodelling Facility While a simple meta-data approach to defining language is insufficient, what can be done to address the issue? How can we rapidly create the rich modelling languages that are required for language driven development? What is required is a metamodelling environment that is sufficiently rich to capture all aspects of a language in a platform independent way. Moreover, this language should be self describing and self-supporting, thus making it possible for any language to be defined completely independently of external technology. A central feature of such an environment is executability – this must be built in from the start in order to be able to capture the operational semantics of languages, and to be able to define the semantics of the metamodelling language itself. Without it, language definitions become reliant on external implementation technologies in order to define language semantics. To support domain specific language definition, we propose the following components of an executable metamodelling facility (an overview is shown in figure 1): • A virtual machine for executing metamodels. Its purpose is to act as a platform independent execution environment for language definitions. • A small, precise, executable metamodelling language that is bootstrapped independently of any implementation technology. It should support the minimum language definition capabilities necessary to be self-supporting. Thus includes a generic parsing language and diagramming language, a compiler and interpreter, and a collection of core executable MOF modelling action primitives. Such a language can be built on top of MOF with the addition of appropriate executable primitives. • A layered language definition architecture, in which increasingly richer languages and development technologies are defined in terms of more primitive languages via operational definitions of their semantics or via compilation to more primitive concepts or extension of existing concepts: These will include: o Definitions of richer metamodelling languages, such as mapping languages (QVT), UI languages, constraint languages, testing languages and pattern languages. o Definitions of general-purpose language primitives such as components, aspects, patterns, etc, that can be combined into general purpose modelling languages such as UML. o Definitions of bespoke, domain specific languages that are built from the above definitions. • Support for the rapid deployment of metamodels into working tools. This involves linking the UI metamodels with appropriate user-interface technology. An open source toolset like Eclipse and GEF can be used for this purpose. The aim is to build support from the ground up for language definition in a layered fashion. Using the facility it is possible to rapidly implement many different modelling languages and associated tools in a platform independent way. In other words, the metamodel becomes a complete definition of the language and tool that supports it. Figure 1: A Metamodel Facility that supports Language Driven Development Uses/ Extends Runs on UI Definition Language Virtual Machine Core Executable Metamodelling Languages Uses/ Extends Rich Metamodelling Languages Rich Development Languages