Introduction - Eclipse Modeling Project: A Domain-Specific Language Toolkit - page 4

As David Frankel pointed out in Model Driven Architecture: Applying MDA
to Enterprise Computing [45], a critical aspect of the success of MDSD is using
a common metamodel. In our case, Eclipse Modeling Framework's (EMFs) Ecore
is this metamodel (or meta-metamodel, depending on your perspective).
Beginning with Ecore (and leveraging the facilities of EMF for defining, editing,
querying, and validating models), I describe how a Toolsmith can begin to
develop a DSL. Using several of the other Modeling projects, you will add dia-
gramming, transformation, and generation capabilities to a DSL, resulting in a
full-featured toolset that a Practitioner can use. Throughout the topic, I use the
roles Toolsmith and Practitioner to distinguish between those who develop DSL
tools using the Modeling project and those who use these tools in practice.
Terminology
Before going further, it's important to understand some key terminology used in
this topic.The structure of a DSL is captured in its metamodel, commonly referred
to as its abstract syntax. A metamodel is just a model that provides the basis for
constructing another model. Although both are models, one is expressed in terms
of the other; in other words, one model is an instance of or conforms to the other.
In this topic, a DSL's abstract syntax is defined using EMF's Ecore model, which is,
therefore, its metamodel and the model used to define all DSLs in this topic. A
model created in terms of our DSL's abstract syntax is commonly referred to as
an instance model; the DSL is then the metamodel, which makes Ecore the meta-
metamodel.The Ecore model is expressed in terms of itself, but this topic doesn't
give this a name or assign an absolute numbering scheme to the levels, as the
Object Management Group (OMG) does. For our purposes, you can simply think
of Ecore as the metamodel that a Toolsmith uses to define a DSL's abstract syntax,
leaving the Practitioner to create instance models of the DSL.
The term abstract syntax refers to a metamodel, so it often has a corresponding
concrete syntax in the form of text or diagram notation. These are referred to as
textual concrete syntax and graphical concrete syntax, respectively. A textual syntax
enables users to work with instance models just as they would other text-based
programming languages. A graphical syntax enables users to work with instance
models using a diagram surface; the most popular is the UML. Abstract syntaxes
are defined using Ecore models, which themselves are persisted in XMI format—
this could technically be considered a concrete syntax, although it's sometimes
called a serialization syntax.