jgrasp handbook

DRAFT, February 18, 2003, Page 87
System Info – Displays information about the operating system and Java version under which jGRASP is
running.
Run Garbage Collector - frees unused memory (in jGRASP itself) immediately.
17.7 UML Menu
Show UML Window - Brings up the UML window.
Generate/Update UML - Brings up the UML window and updates the UML diagram.
17.8 Open File Dialog
A dialog for opening files.
Filters for the languages supported by jGRASP are provided, as well as the "all files" filter. Note that
language filters classify files based on the extension only if they have not been opened in jGRASP before.
Once a file is opened, jGRASP remembers that language. The default language for files with a ".h"
extension can be set to C++ or C only (not both) by changing the extension settings for C or C++ (see
settings).
You can also type a list of extensions into the "Filter Extensions" field to filter by extensions. These must
be separated by whitespace, and can start with ".", "*.", or nothing. For example: "*.c *.cpp", ".c .cpp", and
"c cpp" will all show only files that end in ".c" or ".cpp".
The language may be forced at load time using the language pulldown menu. This only applies to files
that have not been previously opened in jGRASP. Once a file is opened, its language is remembered.
The Text / Binary radio buttons allow the file to be opened in text mode (UNIX, DOS, and Mac. line
terminators accepted) or binary mode (only newlines are line terminators).
17.9 Autotest Dialog
This dialog will self-test jGRASP CSD generation against a batch of selected files. You can help us test
CSD generation by running autotest on your code. If autotest indicates an error, load the file that caused
the problem into jGRASP (probably by clicking on the error message) and generate a CSD. Note if a CSD
will not generate, or if there is an obvious error in the CSD diagram. If you believe your source code is
valid (and there is not a diagram error caused by a macro or include file in C or C++ code), you can send
us the code that shows the problem (or a mocked-up piece of code, if that is not possible). The chances
are good that we will fix the problem quickly.
Note that autotest may take some time if you apply it to a lot of code.
Here are the tests performed on each file, and for various combinations of CSD properties (boxes on/off,
forced newlines on/off, etc.):
A CSD is generated, which tests the validity of the parser (assuming the source code is valid).
The CSD is compared to the original code to make sure the code was not altered (this test is
done every time a CSD is generated).
The CSD diagram is tested against a set of rules for a well-constructed CSD. C and C++ code
that uses macros or has partial structures in include files may fail this test, and this may not
indicate a problem.
A second CSD is generated from the first to test for stability. That is, to make sure
CSD(CSD(source) = CSD(source).