19.12.WinterSim.LanguageEngineeringTutorial/proposal.tex

%**************************************************************************
%*
%*  Paper: ``INSTRUCTIONS FOR AUTHORS OF LATEX DOCUMENTS''
%*
%*  Publication: 2019 Winter Simulation Conference Author Kit
%*
%*  Filename: wsc19paper.tex
%*
%*  Date: February 15, 2019
%*
%*  Word Processing System: TeXnicCenter and MiKTeX
%*
%*
%*  All files need the following
%\input{wsc19style.tex}     % download from author kit.  Style files for wsc formatting. Don't remove this line - required for generating the final paper!

\documentclass{wscpaperproc}
\usepackage{latexsym}
%\usepackage{caption}
\usepackage{graphicx}
\usepackage{mathptmx}

%
%****************************************************************************
% AUTHOR: You may want to use some of these packages. (Optional)
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{amsbsy}
\usepackage{amsthm}
%****************************************************************************


%
%****************************************************************************
% AUTHOR: If you do not wish to use hyperlinks, then just comment
% out the hyperref usepackage commands below.

%% This version of the command is used if you use pdflatex. In this case you
%% cannot use ps or eps files for graphics, but pdf, jpeg, png etc are fine.

\usepackage[pdftex,colorlinks=true,urlcolor=blue,citecolor=black,anchorcolor=black,linkcolor=black]{hyperref}

%% The next versions of the hyperref command are used if you adopt the
%% outdated latex-dvips-ps2pdf route in generating your pdf file. In
%% this case you can use ps or eps files for graphics, but not pdf, jpeg, png etc.
%% However, the final pdf file should embed all fonts required which means that you have to use file
%% formats which can embed fonts. Please note that the final PDF file will not be generated on your computer!
%% If you are using WinEdt or PCTeX, then use the following. If you are using
%% Y&Y TeX then replace "dvips" with "dvipsone"

%%\usepackage[dvips,colorlinks=true,urlcolor=blue,citecolor=black,%
%% anchorcolor=black,linkcolor=black]{hyperref}
%****************************************************************************



\usepackage{subcaption}
		



%
%****************************************************************************
%*
%* AUTHOR: YOUR CALL!  Document-specific macros can come here.
%*
%****************************************************************************

% If you use theoremes
\newtheoremstyle{wsc}% hnamei
{3pt}% hSpace abovei
{3pt}% hSpace belowi
{}% hBody fonti
{}% hIndent amounti1
{\bf}% hTheorem head fontbf
{}% hPunctuation after theorem headi
{.5em}% hSpace after theorem headi2
{}% hTheorem head spec (can be left empty, meaning `normal')i

\theoremstyle{wsc}
\newtheorem{theorem}{Theorem}
\renewcommand{\thetheorem}{\arabic{theorem}}
\newtheorem{corollary}[theorem]{Corollary}
\renewcommand{\thecorollary}{\arabic{corollary}}
\newtheorem{definition}{Definition}
\renewcommand{\thedefinition}{\arabic{definition}}

% comments
\newcommand{\boxedtext}[2]{\colorbox{#1}{\scriptsize\bfseries\textsf{#2}}}
\newcommand{\nota}[3]{
   \boxedtext{#2}{#1}
       {$\blacktriangleright${#3}$\blacktriangleleft$}
}
\newcommand\source[1]{\nota{Source}{green}{#1}}
\newcommand\todo[1]{\nota{TODO}{magenta}{#1}}
\newcommand\placeholder[1]{\textless\textless#1\textgreater\textgreater}


%#########################################################
%*
%*  The Document.
%*
\begin{document}

%***************************************************************************
% AUTHOR: AUTHOR NAMES GO HERE
% FORMAT AUTHORS NAMES Like: Author1, Author2 and Author3 (last names)
%
%		You need to change the author listing below!
%               Please list ALL authors using last name only, separate by a comma except
%               for the last author, separate with "and"
%
\WSCpagesetup{Van Mierlo and Vangheluwe}

% AUTHOR: Enter the title, all letters in upper case
\title{THE FUNDAMENTALS OF DOMAIN-SPECIFIC SIMULATION LANGUAGE ENGINEERING}

% AUTHOR: Enter the authors of the article, see end of the example document for further examples
\author{Simon Van Mierlo\\
\vspace{12pt}
Hans Vangheluwe \\
Department of Mathematics and Computer Science \\
University of Antwerp - Flanders Make vzw \\
Middelheimlaan 1 \\
Antwerp, BELGIUM
}

\maketitle

\section*{ABSTRACT}
%\todo{This can only be 150 words long.} \\

Simulationists use a plethora of modelling languages.
General-purpose languages such as C extended with simulation constructs give the user access to abstractions
for general-purpose computation and modularization.
The learning curve for experts in domains that are far from programming is steep however.
Languages such as Modelica, and DEVS allow for a more intuitive definition of models, 
often through visual notations and with libraries of reusable components for various domains.
The semantics of these languages is fixed. While libraries can be created,
it is not possible to adapt the language's syntax and semantics to suit the needs of a particular domain.
Modelling Language Engineering allows one to explicitly model all aspects --in particular, syntax and semantics-- 
of a modelling and simulation language and to subsequently synthesize visual modelling interfaces, simulators, 
and debuggers.
This is demonstrated by means of a simple railway network language using AToMPM, a (meta)modelling tool.

\section{INTRODUCTION}
\label{sec:intro}
This tutorial introduces the fundamentals of language engineering for creating domain-specific simulation languages.

\subsection{Why Domain-Specific Language for Simulation?}
The complexity of the systems we develop is continuously increasing.
To overcome this complexity, the designers of the system can employ simulation techniques, building virtual prototypes if the system that allow for the quick evaluation of candidates.
The structure and behaviour of these prototypes are expressed in \emph{models} of the system: abstractions that specify a particular view on, or a part of the system.
Such models are implemented in a \emph{modelling language}, often a general-purpose programming language such as C or Java.
This may lead to certain issues.
The domain expert, on the other hand, has deep knowledge of the problem domain, but only a limited understanding of computer programs.
This can result in communication problems, such as the programmer making false assumptions about the domain, or the domain expert to gloss over details when explaining the problem to the programmer.
Furthermore, the domain experts will finally receive a software component that they don't fully understand, making it difficult for them to validate and modify if necessary.
There is a conceptual gap in effect between the two domains, hindering productivity.

Model-Driven Engineering (MDE)~\cite{MandS} tries to bridge this gap, by shifting the level of specification from computing concepts (the ``how'') to conceptual models or abstractions in the problem domain (the ``what'').
Domain-Specific Modelling (DSM)~\cite{Kelly2008} in particular makes it possible to specify these models in a Domain-Specific Modelling Language (DSML), using concepts and notations of a specific domain.
The goal is to enable domain experts to develop, understand, and verify models more easily, without having to use concepts outside of their own domain.
It allows the use of a custom visual syntax, which is closer to the problem domain, and therefore more intuitive.
Models created in such DSMLs are used, among others, for simulation, (formal) analysis, documentation, and code synthesis for different platforms.
There is, however, still a need for a language engineer to create the DSML, which includes defining its syntax, and providing the mapping between the problem domain and the solution domain.

\begin{figure}
    \includegraphics[width=\textwidth]{figure1.pdf}
    \caption{Terminology}
    \label{fig:terminology}
\end{figure}

This tutorial introduces language engineering for domain-specific simulation languages.
A DSML is fully defined~\cite{Kleppe} by:
\begin{enumerate}
\item Its \textbf{abstract syntax}, defining the DSML constructs and their allowed combinations.
    This information is typically captured in a metamodel.
\item Its \textbf{concrete syntax}, specifying the visual representation of the different constructs.
    This visual representation can either be graphical (using icons), or textual.
\item Its \textbf{semantics}, defining the meaning of models created in the domain~\cite{SemanticsOfSemantics}.
    This encompasses both the \textbf{semantic domain} (\textit{what} is its meaning), and the \textbf{semantic mapping} (\textit{how} to give it meaning).
\end{enumerate}

For example, $1 + 2$ and $(+~1~2)$ can both be seen as textual concrete syntax (\textit{i.e.}, a visualization) for the abstract syntax concept ``addition of 1 and 2'' (\textit{i.e.}, what construct it is).
The semantic domain of this operation is the set of natural numbers (\textit{i.e.}, what it evaluates to), with the semantic mapping being the execution of the operation (\textit{i.e.}, how it is evaluated).
Therefore, the semantics, or ``meaning'', of $1 + 2$ is $3$.

This definition of terminology can be seen in Fig.~\ref{fig:terminology}.
Each aspect of a formalism is modelled explicitly, as well as relations between different formalisms.

\subsection{Multi-Paradigm Modelling}
Multi-Paradigm Modelling (MPM)~\cite{Mosterman_MPM} aims to support the modelling of complex systems by combining three different directions of research:
\begin{itemize}
    \item \emph{Meta-Modelling}, which is the process of modelling formalisms.
    \item \emph{Model Abstraction}, concerned with the relationship between models at different levels of abstraction.
    \item \emph{Multi-Formalism Modelling}, concerned with the coupling of and transformation between models described in different formalisms.
    \item \emph{Process Modelling}, allowing to describe system development workflows.
\end{itemize}
This allows developers to model every aspect of interest explicitly, using the most appropriate formalism(s), at the most appropriate level(s) of abstraction, with processes explicitly modelled.

In many cases, an appropriate formalism (with respect to some properties such as the expressiveness, tool support, and other pragmatics such as the knowledge the development team has of the language) is readily available.
Examples include Matlab/Simulink for specifying the dynamics of system using a block-diagram abstraction, Modelica for modelling the physics of systems in an acausal way, and DEVS for discrete-event systems such as queuing systems.
In other cases, such a language is not readily available and one has to be created to serve for a specific domain, or to solve a specific problem.
Within MPM, meta-modelling allows a language engineer to efficiently build such languages and generate domain-specific modelling environments; by specifying the semantics, languages are given a meaning.

\subsection{Example: Railway Simulation}
The tutorial uses an example from the railway domain as an application of the presented techniques.
When designing railway networks, domain experts create the network by connecting railway building blocks, such as:
\begin{itemize}
    \item \emph{Stations}, where people can get on an off the trains.
    \item \emph{Track Segments}, connecting other track segments to each other, as well as to stations.
    \item \emph{Straights}, a special type of track that has exactly one incoming segment and one outgoing segment.
    \item \emph{Turnouts}, a special type of track that splits into two other tracks.
    \item \emph{Junctions}, a special type of track that merges two other tracks.
    \item \emph{Lights}, controlling whether or not a train can enter the next track segment.
\end{itemize}
Such models might be subject to evaluation trough virtual experiment (simulation) to see whether some performance metric is optimal.
For example, one could ask the question what the optimal track length is, given a specific railway network.
The track length influences the total cost of the system: very long tracks mean less infrastructure has to be built (since there are less lights to put next to the tracks), but it also means that trains might have to wait very long before they are admitted to enter the next track, potentially causing delays.

\begin{figure}
    \centering
    \includegraphics[width=0.5\textwidth]{problem.pdf}
    \caption{The optimal track length problem illustrated.}
    \label{fig:problem}
\end{figure}

To answer such questions, the models are typically encoded in an appropriate modelling language, where such answers can be easily given.
The optimal track length problem is illustrated in Figure~\ref{fig:problem}.
Domain experts might be more comfortable with such visual models, instead of a simulation language that is specifying \emph{how} to run the simulation.
This can improve understandability, both for expressing the problem correctly, and for interpreting the results of simulation.

\section{WHAT IS A DOMAIN-SPECIFIC MODELLING LANGUAGE?}
A domain-specific modelling language is a modelling language, tailored to a specific domain.
The concept of domain-specificity is relative: a language such as HTML/CSS can be viewed as domain-specific, since it is tailored to the specification of the structure and layout of webpages.
However, these languages are very general, and can specify solutions in many domains.
The explanations that follow can be applied to modelling languages in general, regardless of whether they are viewed as domain-specific or not.

In the following subsections, we explain the building blocks of domain-specific languages.

\subsection{Syntax}
A syntax defines whether elements are valid in a specified language or not.
It does not, however, concern itself with what the constructs mean.
With syntax only, it would be possible to specify whether a construct is valid, but it might have invalid semantics.
A simple, textual example is the expression $\frac{1}{0}$.
It is perfectly valid to write this, as it follows all structural rules: a fraction symbol separates two recursively parsed expressions.
However, its semantics is undefined, since it is a division by zero.

\subsubsection{Abstract Syntax}
The abstract syntax of a language specifies its constructs and their allowed combinations, and can be compared to grammars specifying parsing rules.
Such definitions are captured in a metamodel, which itself is again a model of the metametamodel~\cite{MattersOfMetamodelling}.
Most commonly, the metametamodel is similar to UML Class Diagrams, as is also the case in our case study.
The metametamodel used in the examples makes it possible to define classes, associations between classes (with incoming and outgoing multiplicities), and attributes.

While the abstract syntax reasons about the allowable constructs, it does not state anything about how they are presented to the user.
In this way, it is distinct from textual grammars, as they already offer the keywords to use~\cite{Kleppe}.
It merely states the concepts that are usable in the domain.

% TODO: Explain a bit more maybe.

\subsubsection{Concrete Syntax}
The concrete syntax of a model specifies how elements from the abstract syntax are visually represented.
The relation between abstract and concrete syntax elements is also modelled: each representable abstract syntax concept has exactly one concrete syntax construct, and vice versa.
As such, the mapping between abstract and concrete syntax needs to be a bijective function.
This does not, however, limit the number of distinct concrete syntax definitions, as long as each combination of concrete and abstract syntax has a bijective mapping.
The definition of the concrete syntax is a determining factor in the usability of the DSML~\cite{Usability}.

Multiple types of concrete syntaxes exist, though the main distinction is between \textbf{textual} and \textbf{graphical} languages.
Both have their advantages and disadvantages: textual languages are more similar to programming languages, making it easier for programmers to start using the DSML.
On the other hand, visual languages can represent the problem domain better, due to the use of standardized symbols, despite them being generally less efficient~\cite{TextualVsGraphical}.
An overview of different types of graphical languages is given in~\cite{VisualLanguages}.
Different tools have different options for concrete syntax, depending on the expected target audience of the tool.
For example, standard parsers always use a textual language, as their target audience consists of computer programmers who specify a system in (textual) code.

While the possibilities with textual languages are rather restricted, graphical languages have an almost infinite number of possibilities.
In~\cite{PhysicsOfNotation}, several ``rules'' are identified for handling this large number of possibilities.
As indicated beforehand, a single model can have different concrete syntax representations, so it is possible for one to be textual, and another to be graphical.

\subsection{Semantics}
For a domain-specific language to be called a formalism~\cite{Giese_SummaryMPM}, it requires a semantic definition.
Since the syntax only defines what a valid model looks like, we need to give a meaning to the models.
Even though models might be syntactically valid, their meaning might be useless or even invalid.

It is possible for humans to come up with intuitive semantics for the visual notations used (\textit{e.g.}, an arrow between two states means that the state changes from the source to the destination if a certain condition is satisfied).
There is, however, a need to make the semantics explicit for two main reasons:
\begin{enumerate}
    \item Computers cannot use intuition, and therefore there needs to be some operation defined to convey the meaning to the machine level.
    \item Intuition might only take us that far, and can cause some subtle differences in border cases.
    Having semantics explicitly defined makes different interpretations impossible, as there will always be a ``reference implementation''.
\end{enumerate}

Semantics consists of two parts: the domain it maps to, and the mapping itself.
While many categories of semantic mapping exist, as presented in~\cite{SurveySemantics}, we only focus on the two main categories relevant to our case study:
\begin{enumerate}
    \item \textbf{Translational semantics}, where the semantic mapping translates the model from one formalism to another, while maintaining an equivalent model with respect to the properties under study.
          The target formalism has semantics (again, either translational or operational), meaning that the semantics is ``transferred'' to the original model.
    \item \textbf{Operational semantics}, where the semantic mapping effectively executes, or simulates, the model being mapped.
          Operational semantics can be implemented with an external simulator, or through model transformations that simulate the model by modifying its state.
          The advantage of in-place model transformations is that semantics are also defined completely in the problem domain, making it suitable for use by domain experts.
          For our case study, this means implementing a simulator using model transformations.
\end{enumerate}

Both the semantic domain and the possible semantic mappings (operational and translational) will be covered in the next subsections. 

\subsubsection{Semantic Domain}
The semantic domain is the target of the semantic mapping.
As such, the semantic mapping will map every valid language instance to a (not necessarily unique) instance of the semantic domain.
Many semantic domains exist, as basically every language with semantics of its own can act as a semantic domain.
The choice of semantic domain depends on which properties need to be conserved.
For example, \textsf{DEVS}~\cite{CDEVS} can be used for simulation, \textsf{Petri nets}~\cite{PetriNets} for verification, \textsf{Statecharts}~\cite{Statecharts} for code synthesis, and \textsf{Causal Block Diagrams}~\cite{CBD} for continuous systems using differential equations.
A single model might even have different semantic domains, each targeted at a specific goal.

For the example simulation language developed during the tutorial, we will use \textsf{DEVS} as the semantic domain; we want to run several simulations to analyze the optimal track length, which requires to look at the overall cost of the system using the throughput of the track by regarding it as a queueing system.
\textsf{DEVS} is a popular formalism for modelling complex dynamic systems using a discrete-event abstraction.

Atomic DEVS models are the behavioural atomic blocks of a DEVS model.
Their structure is described by:
\begin{gather*}
    AM = \langle X, Y, S, q_{init}, \delta_{int}, \delta_{ext}, \lambda, ta\rangle \\
    \begin{aligned}
        &X                                                      &\textit{set of input events} \\
        &Y                                                      &\textit{set of output events} \\
        &S                                                      &\textit{set of sequential states} \\
        &q_{init} \in Q                                         &\textit{initial total state} \\
        &    Q = \{(s, e) | s \in S, 0 \leq e \leq ta(s)\}\hspace{-1cm} &\textit{set of total states} \\
        &\delta_{int} : S \to S                                 &\textit{internal transition function} \\
        &\delta_{ext} : Q \times X \to S                        &\textit{external transition function} \\
        &\lambda : S \to Y \cup \{\phi\}                        &\textit{output function} \\
        &ta : S \to \mathbb{R}^+_{0,+\infty}                    &\textit{time advance}
    \end{aligned}
\end{gather*}
Simulating an atomic DEVS model results in a (discrete-event) trace of output events.
This allows a modeller to check the behaviour of the system by, for example, computing some performance metric.

Coupled DEVS models as the structuring concept of DEVS.
Their structure is described by:
\begin{gather*}
    CM = \langle X_{\textit{self}}, Y_{\textit{self}}, D, MS, IS, ZS, \textit{select} \rangle \\
    \begin{aligned}
        &X_{\textit{self}}                                      &\textit{set of input events} \\
        &Y_{\textit{self}}                                      &\textit{set of output events} \\
        &D                                                      &\textit{set of model instance labels} \\
        &MS = \{AM_i | i \in D\}                                 &\textit{set of submodels} \\
        &IS = \{I_i | i \in D \cup \{\textit{self}\}\} \hspace{-0.2cm}&\textit{topology} \\
        &I_i = 2^{D \cup \{\textit{self}\} \setminus \{i\}} &\textit{set of influencees' labels} \\
        &ZS = \{Z_{i,j} | i \in D \cup \{\textit{self}\}, j \in I_i\}\hspace{-1.5cm} &\textit{translation} \\
        &Z_{\textit{self},j} : X_\textit{self} \to X_j          &\textit{input-to-input translation} \\
        &Z_{i,j} : Y_i \to X_j                                  &\textit{output-to-input translation} \\
        &Z_{i,\textit{self}} : Y_i \to Y_\textit{self}          &\textit{output-to-output translation} \\
        &\textit{select} : 2^D \to D                            &\textit{select function}
    \end{aligned}
\end{gather*}
DEVS is closed under coupling, so models can be nested up to arbitrary depth.

The semantics of DEVS, a discrete-event formalism are well known~\cite{CDEVS} and implemented in a number of tools such as PythonPDEVS~\cite{DistributedPythonPDEVS}.
In the tutorial, we will use DEVS as the semantic domain for our railway language to evaluate its behaviour by looking at it as a queuing network and extracting throughput information from the different scenarios.

\subsubsection{Translational Semantics}
With translational semantics, the source model is translated to a target model, expressed in a different formalism, which has its own semantic definition.
The (partial) semantics of the source model then correspond to the semantics of the target model.
As the rule uses both concepts of the problem domain and the target domain (\textsf{DEVS} in our case), the modeller should be familiar with both domains.

% TODO: explain some more here maybe.

\subsubsection{Operational Semantics}
A formalism is operationalized by defining a simulator for that formalism.
This simulator can be modelled as a model transformation that executes the model by continuously updating its state (effectively defining a ``stepping'' function).
The next state of the model is computed from the current state, the information captured in the model (such as state transitions and conditions), and the current state of the environment.
Contrary to translational semantics, the source model of operational semantics is often augmented with runtime information.
This requires the creation of both a ``design formalism'' and a ``runtime formalism''.
In our case study, for example, the runtime formalism is equivalent to the design formalism augmented with information on the current state and the simulated time, as well as a list of inputs from the environment.

% TODO: explain some more here maybe.

\subsubsection{Terminology}
The difference between a \emph{language} and a \emph{formalism} is not always clear.
To scope our work, we define the vocabulary that we use:
\begin{itemize}
    \item A \emph{language} is the set of abstract syntax models. No meaning is given to these models.
    \item A \emph{concrete language} comprises both the abstract syntax and a concrete syntax mapping function. Obviously, a single language may have several concrete languages associated with it.
    \item A \emph{formalism} consists of a language, a semantic domain and a semantic mapping function giving meaning to model in the language.
    \item A \emph{concrete formalism} comprises a formalism together with a concrete syntax mapping function.
\end{itemize}
Whenever we use the term \emph{domain-specific language} in this tutorial, we assume it is a \emph{concrete formalism}; this ensures that the commonly known term \emph{DSL} is used.

\section{HOW IS A DOMAIN-SPECIFIC LANGUAGE CREATED?}
Now that we explained how a DSL is built up of syntax and semantics, we show technology with which it is possible to define these building blocks.
By defining a DSL, a language engineer has the intention of building a \emph{tool} that allows users of the language to build models, check whether they are valid instances of the model, simulate them, debug them, \ldots
To efficiently do this, metamodelling environments offer a framework within which the syntax can be described in a metamodel, and the semantics using model transformation.

This section explains how to create a new DSL, both its syntax and its semantics.
We use the metamodelling environment AToMPM~\cite{AToMPM} to demonstrate these language engineering techniques.
The presented techniques are general enough to apply them in other metamodelling environments with similar capabilities as AToMPM.

\subsection{Generating a Syntax-Directed Modelling Environment}
\begin{figure}
    \centering
    \includegraphics[width=\textwidth]{example_model.png}
    \caption{Example model in the domain-specific editing environment for the railway language.}
    \label{fig:example_model}
\end{figure}
The idea behind a domain-specific language is generating a domain-specific editing environment.
This environment is a tool, used by domain experts, that helps them to define models that are valid according to the rules defined in the language.
One way of achieving this is offering a free-hand editor (such as a text editor), equipped with parsers, syntax checkers, and compilers configured for the language.
These work in a similar way to integrated development environments, such as Eclipse.
They offer freedom with respect to the editing of the syntax, but, as a downside, one can only confirm the model is correct with respect to the language definition after a manual ``check'' is performed.
Another way of achieving this is through a so-called \emph{syntax-directed modelling environment}.
These environments are specifically configured to the modelling language and have a model of its syntax that is continuously checked.
This allows for the environment to only allow operations on the model that lead to a syntactically valid model.
This constrains the user more, but since the language is tailored to a specific domain, the domain's constraints can be encoded in this way and improve the efficiency of users.
Often, such environments are graphical; they offer the user a set of domain-specific icons and links in a toolbar that can be placed on a canvas.
For domain experts, this often coincides with their intuition, especially for technical drawings in the electrical, mechanical, \ldots domains.

We focus in this tutorial on generating syntax-directed graphical modelling environments.
An example, for the railway language, is shown in Figure~\ref{fig:example_model}.
It consists of a toolbar, listing the valid language element that the user of the language can instantiate.
For the railway language, this includes the notions of straights, junctions, turnouts, stations, lights, and trains.
On the canvas, the modeller can instantiate the graphical representation of these elements.
In the example, a railway network is built consisting of a number of segments that connect stations.

\begin{figure}
    \centering
    \begin{subfigure}[t]{0.55\textwidth}
        \centering
        \includegraphics[width=\textwidth]{train_metamodel.png}
        \caption{The metamodel of the railway language.}
        \label{fig:train_metamodel}
    \end{subfigure}
    \hfill
    \begin{subfigure}[t]{0.42\textwidth}
        \centering
        \includegraphics[width=\textwidth]{train_concretesyntax.png}
        \caption{The icon definition of the railway language.}
        \label{fig:train_concretesyntax}
    \end{subfigure} 
    \caption{The syntax definition of the railway language.}
    \label{fig:railway_syntax}
\end{figure}
To obtain such a modelling environment, we need to specify the syntax of the language in a metamodel, shown in Figure~\ref{fig:railway_syntax}, and a definition of the icons, shown in Figure~\ref{fig:train_concretesyntax}.
The metamodel defines the language constructs of the railway language.
It also lists the allowed associations between abstract syntax elements (\emph{e.g.}, a train cannot be connected to a light, but a segment can be connected to a train).
While we don't yet give semantics to our language, we already limit the set of valid models (\textit{i.e.}, for which semantics need to be defined).
By preventing ambiguous situations in the abstract syntax, we do not need to take them into account in the semantic definition, as they represent invalid configurations.

This language definition, together with the concrete syntax definition, is used by AToMPM
to generate a domain-specific syntax-directed modelling environment, which means that only valid instances can be created.
For example, if the abstract syntax model specifies that a segment can only be connected to one light, trying to connect that segment to a second light will result in an error.
This maximally constrains the modeller and ensures the models are (syntactically) correct by construction.

A possible concrete syntax for the railway language, shown in Figure~\ref{fig:train_concretesyntax}, assigns an icon to each langauge element. 
Each of the constructs shown in the concrete syntax model corresponds to the abstract syntax element with the same name.
Every construct receives a visual representation that tries to be as close as possible to the mental model of the domain experts using the language.
In case of standardized icons or symbols, it would be trivial to define a new concrete syntax model.
Once we have defined the concrete and abstract syntax of the language, we can generate a graphical modelling environment, shown in Figure~\ref{fig:example_model}.

\subsection{Modelling the Operational Semantics}
\begin{figure}
    \includegraphics[width=\textwidth]{operational_rule.png}
    \caption{Example rule of the operational semantics.}
    \label{fig:operational_rule}
\end{figure}
The operational semantics of a language define a simulator for that language, which defines a number of simulation \emph{steps} that a model has to go through.
It allows to obtain a simulation trace from any valid model in the language.
The operational semantics are commonly expressed using model transformations, which are often called the heart and soul of Model-Driven Engineering~\cite{Transformations}.
A model transformation is defined using a set of transformation rules, and a schedule.

A rule consists of a Left-Hand Side (LHS) pattern (transformation pre-condition), Right-Hand Side (RHS) pattern (transformation post-condition), and possible Negative Application Condition (NAC) patterns (patterns which, if found, stop rule application).
The rule is applicable on a graph (the host graph), if each element in the LHS can be matched in the model, without being able to match any of the NAC patterns.
When applying a rule, the elements matched by the LHS are replaced by elements of the RHS in the host graph.
Elements of the LHS that don't appear in the RHS are removed, and elements of the RHS that don't appear in the LHS are created.
Elements can be labelled in order to correctly link elements from the LHS and RHS.

A schedule determines the order in which transformation rules are applied.
For our purpose, we use MoTiF~\cite{MoTiF}, which defines a set of basic building blocks for transformation rule scheduling.
We limit ourself to three types of rules: the \textit{ARule} (apply a rule once), the \textit{FRule} (apply a rule for all matches simultaneously), and the \textit{CRule} (for nesting transformation schedules).

An example rule of the operational semantics of the railway formalism is shown in Figure~\ref{fig:operational_rule}.
The left-hand side of the rule tries to find two connected tracks, where a train is currently on one of the tracks.
In the right-hand side of the rule, the train is moved to the next track.
This rule would appear in a schedule, that implements the complete semantics of the language.
The schedule operationalizes a railway network by switching lights to red when a train enters a track, and to green again when the train leaves the track.
It then moves trains along the network according to which station they want to go to, and how they want to get there (their schedule).
It makes sure to check that no trains will collide by entering a track at the same time (in particular also when two trains want to enter a junction).
These operational semantics ``bring the system to life'' and allows for users to quickly assess the behaviour of the system by visually inspecting the trace.
The simulator can, moreover, compute metrics while the simulation is running, for analysis.

\subsection{DEVS as a Semantic Domain for Simulation}
DEVS~\cite{CDEVS} can be used to build queuing systems, and analyze their behaviour.
For the railway system language, a particular analysis might look at the railway network as a queuing system, by looking at the tracks as connected nodes with a specific capacity; trains travel between these nodes from a start to end destination.
In between, they might have to wait for red lights, causing a delay in their arrival.
To analyze such properties, we could make use of the operational semantics of the language, encoding the appropriate behaviour.
But sometimes, it might be easier to map to a language that already has capabilities (both syntactically and semantically) for analyzing such properties.
That allows us to reuse existing infrastructure, avoiding the overhead of having to reimplement it.

%\begin{figure}
%    \includegraphics[width=\textwidth]{denotational_rule.png}
%    \caption{Example rule of the translational semantics.}
%    \label{fig:denotational_rule}
%\end{figure}

\begin{figure}
    \includegraphics[width=\textwidth]{devs_overview.pdf}
    \caption{Result of mapping a railway model to DEVS.}
    \label{fig:railway_devs_example}
\end{figure}
As with operational semantics, we make use of model transformations for realizing this mapping.
The basic idea of the mapping is to take each building block of the model (in our case, segments, trains, and lights) and map them onto building blocks of a model in the target language.
The result of mapping a particular railway segment, modelled in our domain-specific language, to DEVS, is shown in Figure~\ref{fig:railway_devs_example}.
The queuing system consists of a generator, that generates trains according to some distribution.
The trains then flow through the network of segments (represented by atomic DEVS models) until they reach the collector (or end station).
Along the way, a train will travel through a track by trying to accelerate (at some predefined maximum acceleration) to its preferred speed.
When the train is close to the next segment, a query will be sent to the next segment, for checking whether or not the segment can be entered (\emph{i.e.}, its light is green).
If the light is red, the train will start to slow down, potentially stopping altogether.
Once the light becomes green, a message will be sent, signifying that the train can continue.

\begin{figure}
    \centering
    \includegraphics[width=0.5\textwidth]{simulation_results.png}
    \caption{Analyzing the results of simulation.}
    \label{fig:simulation_results}
\end{figure}

While the simulation is running, multiple metrics are collected, such as the average speed of trains, the average time it takes them to traverse the complete railway network, the average time spent in one segment, etc.
Such metrics can be used to calculate a cost metric.
In our example, cost is calculated by looking at the average time it takes trains to pass through the complete railway network, as well as the track length.
These two properties are in conflict: as tracks become longer, the cost goes down, but the travel time will go up as trains will frequently be waiting for a red light.
Looking at the simulation results, shown in Figure~\ref{fig:simulation_results}, there is a mimimum at a segment length of around 200 meter: the simulations were run for a complete tack length of 10 kilometers, and the local minimum is at around 50 track segments.

By mapping the model onto a language with known semantics, we can perform analysis of certain behavioural properties by reusing the semantics and the tooling (in particular, simulators) of that formalism.

%\section{RELATED WORK}
% TODO: is this actually necessary?

\section{CONCLUSION}
In this tutorial, we presented the use of domain-specific modelling languages for simulation.
We motivated the use of such languages in specific domains to improve understanding and to improve the efficiency of domain experts in defining their models, instead of having to use general-purpose languages.

We presented the different aspects of a domain-specific modelling language:
\begin{enumerate}
\item abstract syntax to define the allowable constructs;
\item concrete syntax to define the visual representation of abstract syntax constructs;
\item semantic domain to define the domain in which the semantics is expressed;
\item semantic mapping to define the mapping to a model in the semantic domain that defines the (partial) semantics of the domain-specific model.
\end{enumerate}

Each of these aspects was explained and applied to our case study: modelling the behaviour of a nuclear power plant controller and its subcomponents.
The behaviour of the nuclear power plant interface is defined using both operational semantics (``simulation'') and translational semantics (``mapping'').
A generative approach is used, in order to limit the development overhead.

% Reducing font size (to 9pt) for References & Author Biagraphies
\footnotesize

% Please don't exchange the bibliographystyle style
\bibliographystyle{wsc}

% AUTHOR: Include your bib file here
\bibliography{bibliography}

\section*{AUTHOR BIOGRAPHIES}

\noindent {\bf SIMON VAN MIERLO}  is a post-doctoral researcher at the University of Antwerp (Belgium). He is a member of the modeling, Simulation and Design (MSDL) research lab. For his PhD thesis, he developed debugging techniques for modeling and simulation formalisms by explicitly modeling their executor's control flow using Statecharts. He is the main developer and maintainer of SCCD, a hybrid formalism that combines Statecharts with class diagrams. His e-mail address is \email{simon.vanmierlo@uantwerpen.be}. \\

\noindent {\bf HANS VANGHELUWE} is a Professor at the University of Antwerp - Flanders Make (Belgium)
%, an Adjunct Professor at McGill University (Canada) and an Adjunct Professor at the National University of Defense Technology (NUDT) in Changsha, China. 
He heads the modeling, Simulation and Design (MSDL) research lab.  In a variety of projects, often with industrial partners, he develops and applies the model-based theory and techniques of Multi-Paradigm modeling (MPM). 
%His current interests are in domain-specific modeling and simulation, including the development of graphical user interfaces for multiple platforms. To model such reactive systems, he advocates the use of Statecharts to describe their behaviour. 
His e-mail address is \email{hans.vangheluwe@uantwerpen.be}. \\

\end{document}