% $Id: dsml.tex,v 1.10 2005/11/02 13:44:16 kitty Exp $
\section{Domain-Specific Modeling Languages}
\label{dsml}

DSMLs are the backbone for realizing the vision of Model-Integrated
Computing (MIC), a variant of MDD.  One difference between other variants
of MDD like MDA and MIC is the emphasis on the ``domain-specific'' aspect
of the modeling languages.  This section provides an overview of DSMLs and
explains the steps needed to create a DSML.

\subsection{Overview of DSML}
\label{dsml_overview}

The domain of interest of a DSML can range from something very specific,
such as the elements of a radar system, or can be as broad as the set of
all the component-based middleware applications built using platforms such
as EJB, or CCM.  The key idea behind DSMLs is their ability to capture the
elements of the domain as {\em first-class objects}.

A DSML can be viewed as a five-tuple~\cite{Janos:03} consisting of:
\begin{enumerate}
\item {\bf Concrete Syntax (C)}, which defines the specific notation
  (textual or graphical) used to express domain elements,
\item {\bf Abstract Syntax (A)}, which defines the concepts, relationships
  and integrity constraints available in the language,
\item {\bf Semantic Domain (S)}, which defines the formalism used to map
  the semantics of the models to a particular domain,
\item {\bf Syntactic Mapping (M$_{C}$: A$\rightarrow$C)}, which assigns
  syntactic constructs ({\em e.g.}, graphical and/\-or textual) to elements
  of the abstract syntax, and
\item {\bf Semantic Mapping (M$_{S}$: A$\rightarrow$S)}, which relates the
  syntactic concepts to those of the semantic domain.
\end{enumerate}

Thus the abstract syntax determines all the (syntactically) correct
``sentences'', \ie, models, in the language.  A DSML is also known as a
``metamodel'', since a DSML is (itself) a model that defines all the
possible models that can be built using it.  To support the development of
DSMLs, we have developed a ``meta-programmable'' modeling environment
called Generic Modeling Environment (GME).

% Figure~\ref{fig:metamodel} shows an example metamodel defined in GME.

% \begin{figure}[htbp]
%   \centering
%   \includegraphics[width=\columnwidth]{ecsl-sl}
%   \caption{A metamodel in GME}
%   \label{fig:metamodel}
% \end{figure}

% \begin{figure*}[htbp]
%   \centering
%   \includegraphics[width=3.5in]{MetaModel}
%   \caption{A metamodel in GME}
%   \label{fig:metamodel}
% \end{figure*}


\BeginSidebar{Generic Modeling Environment}
\label{gme}

Generic Modeling Environment (GME) is an open-source, visual, configurable
design environment for creating DSMLs and program synthesis environments,
available for download from
\url{escher.isis.vanderbilt.edu/downloads?tool=GME}.  A unique
feature of GME is that it is a {\em meta-programmable} environment.  By
{\em meta-programmable}, we refer to the fact that GME is not only used to
build DSMLs, but also to build models that conform to a DSML.  In fact, the
environment used to build DSMLs in GME is itself built using another DSML
(also known as the {\em meta-metamodel}) called ``MetaGME''.  GME provides
the following elements to define a DSML:
\begin{itemize}
\item {\bf Project}, which is the top-level container in a DSML,
\item {\bf Folders}, which are used to group collections of similar elements
  together,
\item {\bf Atoms}, which are the indivisible elements of a DSML, and used
  to represent the leaf-level elements in a DSML,
\item {\bf Models}, which are the compound objects in a DSML, and are used
  to contain different types of elements like References, Sets, Atoms,
  Connections {\em et al.} (the elements that are contained by a Model are
  known as {\em parts}),
\item {\bf Aspects}, which are primarily used to provide a different
  viewpoint of the same Model (every part of a Model is associated with an
  Aspect),
\item {\bf Connections}, which are used to represent relationships between
  the elements of the domain,
\item {\bf References}, which are used to refer to other elements in
  different portions of a DSML hierarchy (unlike connections which can be
  used to connect elements within a Model),
\item {\bf Sets}, which are containers whose contained elements are defined
  within the same aspect and have the same container as the owner.
\end{itemize}

\EndSidebar

\subsection{Creating a DSML using GME}
\label{dsml_creation}

DSMLs are defined visually in GME.  The following are the typical steps in
creating a DSML using GME:

\noindent{\bf 1. Identifying the domain elements and their relationships.}
The first step in creating a DSML is to identify the different elements of
the domain that we want to model, and their relationships.  This is usually
done with inputs from a domain expert.  It is unlikely that all the
elements are defined in a single iteration.  Just like software
development, MDD is also an iterative process, and any MDD tool
infrastructure should allow modification of the elements (or relationships
between elements) with ease.

\noindent{\bf 2. Mapping the elements of the domain to concepts in GME.}
Sidebar~\ref{gme} provides more information about the GME concepts.  Once
we have enumerated the elements of the domain, we need to map these domain
concepts to GME concepts like Models, Atoms, {\em et al}.  This process is
very similar to defining the types in a program when coding using a
language like C/C$++$.

\noindent{\bf 3. Using GME concrete syntax to realize the mapping.} With
the mapping of elements of the domain to concepts in GME complete, the next
step is to use the concrete syntax of GME, \ie, UML class diagrams,
% Kitty, are these UML class diagrams? - andy
% Yes, MetaGME uses UML class diagram notations. - kitty.
to capture the elements of the DSML.  It is important to note that the
concrete syntax of the elements of your DSML, i.e., visualization of
elements of the DSML, is defined when you are defining the types of your
% Kitty, if we are short on space, these lines can be commented out - andy
% Andy, decorators are a powerful concept, and one of the key differences
% between UML and DSMLs. - kitty.
your DSML.  GME provides the ability to customize the concrete syntax,
\ie, customize the visualization of elements in your DSML.  Customization
of visualization is done using {\em decorators} in GME.  A {\em
  decorator} is a component (written using a traditional programming
language) that implements a set of standard callback interfaces.  Once a
decorator is registered with GME, GME invokes the callbacks whenever GME
needs to display the element.

\noindent{\bf 4. Defining static semantics of the DSML.} The use of UML
class diagrams as the notation for concrete syntax of DSMLs in GME allows
capturing some semantics of the association between the different elements.
This is because some semantics like cardinality of associations can be
sufficiently represented using the notations offered by UML class diagrams.
For constraining the associations between elements further, GME provides a
built-in constraint manager.  GME's constraint manager allow definition of
constraints using OMG's Object Constraint Language (OCL)~\cite{OCL:03}.
The semantics of the DSML that are enforceable using OCL can be viewed as
{\em static semantics}, since they do not take the system dynamics into
account.

\noindent{\bf 5. Generating the DSML environment.} Now that we have defined
the elements of the DSML and the associated {\em static semantics}, we
instruct GME to generate our customized DSML environment.  This is done
using a process called {\em meta-interpretation}.  Meta-interpretation
takes the definition of the DSML from the previous step, runs a set of
standard transformations (which ensure consistency of the language) just
like a traditional compiler and creates a {\em paradigm}.  The paradigm
% Kitty, what are these standard transformations - Andy
% I have added some text. - kitty.
file, which actually defines the DSML, is then registered with the GME
environment.  It is now possible to create models that conform to the
DSML that we have built using GME.

\noindent{\bf 6. Defining dynamic semantics of the DSML.} Though we have
defined the elements, relationships and the static semantics of the DSML,
it is necessary to define {\em dynamic semantics} to make the DSML useful
for complex real-world applications.  Dynamic semantics of a DSML can be
enforced using {\em interpreters}.  An interpreter is a component that is
written using a traditional programming language like C++, Python or Java.
Interpreters need to be registered with GME.  When an interpreter is
invoked, it is given access to the model hierarchy by GME, and can be used
to perform different kinds of validation and generative operations on the
models.  One such operation can include generating platform-specific
artifacts like code directly from the models.

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "IEEE06"
%%% End:
