![](bg3.png)
string comes back to the initial node and the same process
takes place again.)
@A={X,S,a,b,o,O} // Alphabet
@N= {final}+ {n{symbol}:symbol->{X,S,O}}
/* Nodes associated with non terminal symbols */
@c{n{X}}={X} // Initial content of the axiom node
@r{n{X}}= {X-->SO} // Deriving rules for the axiom
@r{n{S}}= {S-->aSb, S-->ab}
@r{n{O}}= {O-->o, O-->oO, O-->Oo}
@C=@complete // The graph is complete
@S={ @non_emtpy_node={final} }
// Stopping conditions
(NEPsLingua program for a NEP for parsing the grammar
implicit in the rules of the nodes, X is the axiom)
Figure 1 shows an example of ANTLR with the
grammar defined for NEPsLingua. You can see the
rules defining some of the elements of a NEP. Specifi-
cally you can see a fragment that describes the differ-
ent classes of set of nodes in NEPsLingua: individual
and indexed.
4 AN EXAMPLE OF MODEL
DRIVEN APPROACH FOR NEPs
One of the platforms that supports MDA is
conformed by the modelling plug-ins of Eclipse
(http://www.eclipse.org). Although the reader could
find in its website different options, this paper only
describes the following:
• Emfatic, for the model extended with visual syn-
tax
• Xtext, for adding textual syntax
• Some features added by Eclipse to the integrated
development environment
We will show in this paper some fragments of
Eclipse files describing our languages for NEPs. A
complete description of the characteristics of these
tools is out of the scope of this work and can be found
in http://www.eclipse.org
Definition of the Basic UML Model
Eclipse provides a graphic interface to draw the ba-
sic UML model. It contains the typical elements of
every UML classes diagram (classes, interfaces, re-
lationships, attributes, etc.). This models are named
Ecore diagrams by Eclipse.
In the present work we have not defined an explicit
Ecore diagram. We describe above the technique used
instead.
Definition of the UML Model and its
Visual Appearance
In this paper we will show how to define he model
(with its visual appearance at the same time) by means
of the Emfatic plug-in. When the model is defined as
an Ecore diagram, the user has to manually add to
the textual representation of the Ecore diagram some
emfatic annotations to add the visual syntax.
In our example we will represent the processors,
the filters and the rules by means of respectively rect-
angles, round rectangles and ovals. Permitting filters
are coloured in green, while forbidden in red.
It is easy to find in the following fragment of Em-
fatic code the annotations that specify these visual ap-
pearances (in particular rules and colours of filters).
@gmf.node(label = "contentName", figure="ellipse")
class ContentRules {
attr String contentName;
@gmf.link(style="dash")
ref Processor ownerRules;
@gmf.compartment(foo="bar")
val Rule[*] rules;
}
...
@gmf.node(border.color = "0,255,0")
class PermittingInputFilter extends InputFilter{}
@gmf.node(border.color = "255,0,0")
class ForbbidingInputFilter extends InputFilter{}
(A fragment of the emfatic code with visual annotations for
NEPs)
Adding the Textual Appearance
Eclipse provides a procedure to automatically asso-
ciate the following default textual syntax for its mod-
els: each element should be preceded by its name and
its possible contents appears between brackets.
It is easy to realize after reading the following
fragment of the Xtext file for NEPs that it is very
similar to the context free grammar associated with
the default syntax. It is easy also to identify the
standard Xtext syntax: words ’NEP’, ’processors’,
’rules’, ’Processor’ and symbols ’{’, and ","
have to be literally written in the programs and could
be (easily) changed by simply editing this file.
NEP returns NEP:
{NEP} ’NEP’
’{’ (’processors’ ’{’ processors+=Processor
( "," processors+=Processor)* ’}’ )?
...
(’rules’ ’{’ rules+=ContentRules
( "," rules+=ContentRules)* ’}’ )?
... ’}’;
DifferentApproachesforDevelopmentToolsforNaturalComputers-GrammarDrivenvs.ModelDrivenApproaches
489