SEKE 2012 Proceedings - Knowledge Systems Institute

Figure 1. The process for engineering DSLs for mobile robot applications
II.
A PROCESS FOR ENGINEERING DSLS
In this section we present our process, which has five
activities. We detail them below. The process overview can be
seen as a SADT diagram in Fig. 1. The main focus of this paper
is on the second and third activities because of space
limitations.
Pick or build an application. In this activity, the domain
engineer shall builds a robot application or take an existi ng
one. He/she must have knowledge about its requirements and
the software libraries used in the implementation.
Identify domain abstractions. This activity is divided in
two steps which are explained below.
Extract domain abstractions from requirements. In this
step, the domain engineer shall analyze the application’s
requirements to extract domain abstractions, which will
comprise the DSL abstractions. This activity consists of
structuring the application’s requirements as a tree, as can be
seen in Fig. 2, where the first node represents the application’s
main objective. The first level of children nodes is called
“What to do” level, since they state what the robot must
perform in order to achieve the main objective. The second
level is called “How to do” level and its nodes describe what
the robot does to perform what is stated in their parent nodes.
The “How to do” nodes shall be created considering how
actuators and sensors are utilized to perform such action. For
example, if the main objective is following a wall, there may be
a first level node stating “walk near the wall”, and it could have
children nodes stating “walk” and “keep parallel to wall”. A
node may also have children nodes in the same level.
After creating this tree, which is the resulting artifact from
this activity, the domain engineer shall choose which
abstractions will comprise the intended DSL. If he/she chooses
the leaf nodes, the resulting DSL will be more flexible but
more verbose and less related to the application domain. But if
Figure 2. Illustration of requirements structured as a tree
the “What to do” nodes is chosen, the DSL will be closely
related to the application domain and will be more expressive
but too rigorous and limited. It’s also possible to choose
abstractions from different node levels—usually, the more
abstract ones results in less flexible DSL elements.
Classify domain abstractions into concerns. In this step,
one shall create a table categorizing the chosen abstractions
into concerns. These concerns must be related to the mobile
robots’ domain. The most common concerns are domainindependent,
for example, Movement, Communication and
Recognition. However, the domain engineer can elect domainspecific
concerns as well. For example, abstractions that state
the robot must move, like following a line or a path, should
belong to Movement concern, yet abstractions such as finding
the best path should be classified into the Planning concern,
and so on. The resulting artifact of this activity is called Table
of Domain Abstractions and it is the input for the next activity.
Create language model. In this activity, the domain
engineer shall iterate the concerns and for each of them he/she
identifies common and variant parts of its abstractions. Then
these parts are added to t he Language model. Here, the
engineer must know the APIs used in the implementation of the
application, as we mentioned earlier. It is important to know
how the physical parts of the robot, such as sensors and motors,
are programmatically represented, because the Language
Model should be aware of implementation details, even though
they will not be visible to developers. These details are
important for code generation issues.
As a r esult of our study, we created a generic language
model that could be used as a foundation for new mobile robot
DSLs. That is, the domain engineer could simply extend our
generic language model to fit his/her needs.
Our generic language model is shown in Fig. 3. The main
entity is Robot. It contains behaviors, belief states, sensors and
variables. This model is based on the Behavior model [6] and
its way of programming robots consists roughly of specifying
behaviors for the robot, and each of them has a condition to be
executed. Just one behavior will run at a time—the one whose
condition is satisfied at the moment. In our model, the
conditions are specified as belief states; the expression property
is intended to contain comparisons of sensors’ data and
variable values. The expression may use functions of sensors
and variables. For example, an ultrasonic sensor may have the
“distance” function which returns a float value. The domain
496