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

5. FRAMEWORK EVALUATION 5.1. Functional Validation
After the user submits a number of files to the tool, they are processed and, if not fully
recognized, the user is able to manually define a grammar, or pass the tool a file containing the
grammar for the generation of new parser.
Non-functional requirements:
Usability: The grammar definition syntax should be a broadly adopted one.
JavaCC grammar interpreter supports the Extended Backus-Naur Form and allows Java
code, for more commodity.
Usability: To ease the parser generation process, the user must be able to iterate through the previ-
ously built grammars so as to roll back any change made on a grammar.
Every time the user tries a newly created parser on a configuration file, the grammar used
for it is stored in a repository and can be recovered at any time.
3. The user must be able to produce a parser from a grammar.
As soon as the user finishes declaring a grammar, the latter is passed to the tool, which
compiles it on an external parser generator.
Non-functional requirements:
Extensibility: The user must be able to add parsers built outside the tool to support other configura-
tion file paradigms (e.g., Windows registry files, binary files, etc.).
The parser repository implements the importParser method which allows the user to
store an external parser. However, the parser must implement the interface presented in List-
ing 3.8.
4. The user must have access to the parser compilation trace.
When a grammar is compiled, its compilation trace is shown in case there any error ocurred,
or a success message is displayed, otherwise.
Non-functional requirements:
Usability: The error messages must clearly identify the source of the error.
The error messages contain the source of the compilation error.
5. The user must receive information relative to the grammar fitness with a given config-
uration file.
Any time a parser is tested with a configuration file, the percentage of parsed file with that
parser is displayed.
Non-functional requirements:
Usability: The sections of the configuration file that were parsed and those that were not must be
clearly identified.
When a parser is tested with a configuration file, the regions of the file recognized by it are
highlighted in a graphical environment.
6. The user must be able to store a functional parser generated by the tool, in order to be
used on later tool runs.
52