SEKE 2012 Proceedings - Knowledge Systems Institute

engineer may also create other specialized entities having
algorithms such as th e Gaussian filter, Proportional-Integral-
Derivative (PID) controller, etc.
A DSL may have multiple diagram kinds. When creating
the language model, the domain engineer must know what kind
of diagrams the DSL should have. The engineer should look at
the Language Model in order to analyze if all entities can be
addressed into only one diagram. If some entities cannot stay
together, either because they are totally independent from each
other or they could yield polluted diagrams, then the domain
engineer should separate them into different diagrams. When
separating entities into diagrams, there should be a balance
between correlated entities and diagram pollution.
Create code generation templates. In this activity, the
domain engineer shall implement templates that are roughly
fixed code with variation points. A domain framework could be
created as well. It serves as a foundation for the generated code
and provides artifacts that are common to all applications that
can be generated.
The process’ control flow may go back to the prior activity
“Create Language Model”, because changes may be required in
the language model depending on the code generation
technology used. In Java Emitter Templates framework (JET),
for example, a model is traversed as a graph. Commands that
traverse instances of a pa rticular entity cannot guarantee the
order they are processed. If the order is a must, the engineer
should change the language model to assure it, for example, by
adding an initial node that connects to the first instance and
adding a relationship between instances that specifies the next
to be processed. The process’ control flow may also go back to
the activity “Identify domain abstractions”, because during
template confection, it is common to n ote missing or even
incorrect domain abstractions.
Create language notation. The language notation is its
concrete syntax, that is, how it visually represents its elements,
relationships and properties. These representations must be
meaningful to the users of the DSL. Choosing the most
appropriate visual representations contributes significantly to
the DSL success; however, this is beyond the scope of this
paper.
III. PROOF OF CONCEPT: A DSL FOR THE LEGO
MINDSTORMS
In this section, we describe how we conducted our process
to create a DSL that generates code for LEGO Mindstorms.
Figure 3. The generic language model
Pick or build an application. Our mobile robot application
has the following requirements: i) It must seek for opened
doors along an aisle; ii) a sound alert shall be played when it
finds one; and iii) when it reaches the end of the aisle, the robot
should turn back and begin seeking again. We implemented our
application using the LeJOS API [5].
Identify domain abstractions. We extracted the domain
abstractions and built the tree shown in Fig. 4. We divided the
main objective into three nodes: “walk along aisle”, “detect
open doors” and “sound alert if door is open”.
After extracting the domain abstractions, we shall choose
which ones will comprise the DSL. As mentioned before, one
could pick abstractions from different levels—at the bottom
lies the less abstracted ones and hence more flexible. We chose
all from the “How to do” level but the “play sequence of
tones”. Instead we chose its parent node. The next step is to
categorize the chosen abstractions into concerns. We classified
into Movement those that manipulate the motors, and into
Detection those that use the sensors. The one that left was
classified into the Communication concern since its goal is to
notify someone about an opened door.
Create language model. We created the language model
shown in Fig. 5. There is the generic language model extended
with our DSL entities, which are in bold. We also added
properties to the generic entities, which are underlined.
Create code generation templates. We used the Java
Emitter Templates Framework (JET) to create the templates for
code generation. The model built with the DSL is passed as an
input to the templates and their tags traverse its elements to
extract and process information, producing application’s code.
We also created a domain framework that implements all the
behaviors, for the generated code only instantiates and
configures what is m odeled. The process of creating the
domain framework reuses a significant part of the application
developed in the first activity.
Create language notation. In this activity, we created the
notations of the DSL. To make it simple, choosing the best
notations is out of the scope of our proof of concept.
IV. RELATED WORK
Günther et al. [9] show an agile and lightweight process for
engineering DSLs embedded in dynamic languages. The
process is divided into three phases: Domain Design, Language
Design and Language Implementation. They also present
several DSL-engineering patterns to be used in the last phase,
which are strongly related to the following DSL engineering
concerns: Language Modeling (what language constructs
implement domain concepts), Language Integration (how to
easily integrate the DSL with other components) and Language
Purification (how to optimized e.g. readability).
Robert et al. [10] define a lightweight process for designing
UML profiles. The process has three activities: Problem
description, Refinement restriction and Profile definition. Their
resulting artifacts are respectively a Problem model, a Domain
model and a Profile. There are two actors: the domain expert
and the language expert. The former is responsible for the first
activity, and the latter, for the last one; they both work in the
497