Dissertaç ˜ao de Mestrado Mestrado em Engenharia Informática Jo ...

3. AN APPLICATION RECONFIGURATION FRAMEWORK 3.3. Original to Generic syntax Converter
Listing 3.1: User Interface proposed interface
interface UI {
void processFiles(String[] fileNames);
void submitGrammar();
byte[] getTentativeGrammar();
void approveParser();
boolean importParser();
void haltSession();
void recoverSession();
}
described. The interfaces that every component should implement are also presented, in a
Java-like syntax. Enforcing every component to implement an interface not only allows any
component to be completely remade without having any effect on other components, it also
aids the integration process of SmART with other tools.
User Interface
The User Interface (UI, Listing 3.1) is the tool’s front-end, through which the user interacts with
the tool. It is invoked by the user and receives an array of configuration file locations at boot
time, although it only processes one at a time.
For each file, UI summons the Configuration File Parser to make an attempt at
parsing a configuration file with the parsers in the Parser Repository. Two outcomes are
possible: either a parser manages to recognize the totality of a file or none does.
The first case is the ideal case, where at least one of the parsers in the Parser Repository
manages to fully recognize the configuration file. In this situation, UI displays the representa-
tion of the generic syntax, as returned by the Configuration File Parser, to let the user
validate the generated structure. At this point, the configuration file in generic syntax is stored
in memory, so UI must save it to a file to let file modification take place.
The second case, where the configuration file was not completely parsed by any available
parser, requires user intervention. If the file could not be totally recognized by any parser,
another parser which recognizes this new language must be generated. For this endeavour,
UI provides the user with a friendly interface which allows him to define a new grammar
that recognizes the configuration file language. The user must also be allowed to build a new
grammar from an existing one. This is useful in the case where a parser managed to parse a
configuration file almost entirely. In this case, the new parser might be ready just by tuning an
existing one, instead of having to build it from scratch.
As soon as a grammar is defined, the user triggers its compilation with the Grammar
Compiler’s submitGrammar call. Any grammar compilation errors should be displayed to
the user. To ease parser generation, the user must have access to the previously tested gram-
mars. This allows for the rollback of changes in grammars in an easy way. To accomplish
this, every time the user submits a new grammar, UI sends it to the Tentative Grammar
27