Automatic GUI Creation
Generating Java source code from formal descriptions
5. Evaluation and Future Work
This section evaluates the results obtained and outlines the further work needed on the prototype. The first part mentions the known problems and simpler improvements remaining to be done. The second part discusses a number of future extensions that could make the tool more powerful. The last part concludes that it was possible to automate large parts of the plug-in creation.
5.1 Implementation improvements
There are several possible improvements to the current prototype implementation, both in the user interface and in some of the internal data structures. Some of these issues are known and have been detected in late stages of the development, leaving too little time to correct them. In the following, the known improvements are listed along with an estimation of how much time it would take to implement them. The time estimates refer to a developer familiar with the prototype code organization, algorithms and data structures.
Closing the dialogs (4 hours)
Neither the tab nor the MIB edit dialogs contain close buttons, something that may be confusing to some users. It would therefore be good if such buttons could be inserted without making the interface more complicated than it already is.
Reordering the tabs (1 day)
The tabs are currently sorted in alphabetical order, which is clearly not the order in which they should be generated to the plug-in. The ordering should instead be possible to change by dragging and dropping in the tab list.
Multiple MIB dialogs (1 day)
It should be possible to view various MIB files at a time, which means making the MIB dialog non-modal. It should not be possible to have several dialogs viewing the same MIB, which can happen in the current implementation if the user doubleclicks the button. There are also some problems deciding what shall happen if the user unloads a MIB currently viewed or loads another plug-in. This must be solved before making the MIB dialog non-modal.
Better error handling (5 days)
Errors encountered in the MIB files are displayed immediately, but the original text is not shown. Storing the text inside the parse tree would require much additional work, but reading the file again is probably both possible and fast enough. Warnings should be handled in the same way, and should also be displayed immediately in a separate dialog or window. Ideally the application should launch a MIB editor allowing the user to correct the mistakes in the file.
Symbol data structure change (5 days)
The symbol data structure, used for handling the MIB fields and data types internally, is too closely modeled after the ASN.1 syntax. Some new models need to be defined for symbol and type information, making the symbols easier to use in the code generation. A third pass in the MIB analysis would have to be added, translating the old symbol model into the new one.
5.2 Future extensions
There are several parts remaining to be designed and implemented in the prototype application, especially to generate the data access and data logic layers. In the following, most of the possible extensions are listed along with an estimation of how much time it would take to implement them. The time estimates refer to a developer familiar with the prototype code organization, algorithms and data structures.
Modularize the plug-in data layer (3 days)
The data layer of the generated plug-in should not be a monolithic class, but split into separate modules. A better modularization would save much work and increase speed, as the data is currently transferred in whole blocks to the network element currently configured. This separation could be made from the branches in the MIB, but might require that the internals of the MIB symbols be somewhat improved.
Convert field data to component data (unknown)
The low-level data representation is not always the same as the one used in the components. Some kind of intelligent type conversion must therefore be inserted in the business layer of the generated plug-in. Of course such a conversion would not be able to handle all conversions correctly, as it is not always clear what the mapping would be.
Generating user interface tooltips (5 days)
The generated plug-in user interface should contain tooltips, i.e. explanatory texts that are displayed when the user hoovers over the component with the pointer. This information could be extracted automatically from the field comments in the MIB, but must be possible to edit as the comments are not always suitable. This of course also means changing the file format when storing plug-in generation data, as the new text would have to be stored along with other information.
Editing the interface labels (3 days)
The labels that some components have in the interface should be editable. This of course also means changing the file format when storing plug-in generation data, as the new text would have to be stored along with other information.
One field in various tabs (4 days)
A field from the MIB files should be possible to include in various tabs, as it is needed in some plug-ins. Apart from changing inside the symbols, this would also require that the tab edit dialog be reimplemented to support an additional view of the fields. In the code generation special care would also have to be taken not to duplicate information in the lower plug-in layers.
Preview of tabs (2 days)
Currently example components are shown for each field, but it would also be good to be able to test the whole plug-in interface and all the tabs simultaneously. Ideally such a preview would also allow dragging the components, thereby generating a draft layout.
Generating SNMP agent (unknown)
The SNMP requests sent by the plug-in client are received by an agent (or server) in the other end of the communication. This agent is normally written in C and contains separate functions for each of the fields in the MIB. It would be of great value if stub code for these functions could be generated automatically, assuring that all fields used by the plug-in would also be handled by the SNMP agent. The most time consuming part of this would probably be creating a C syntax layer in the code generation.
5.3 Evaluation of the results
The overall results from the prototype have been very encouraging—a user interface could be created from the MIB files and the lower layers of the plug-in seem viable for automation. The prototype application addresses several issues not originally planned, as the creation of language resource files and data layer stubs, and produces code of a higher quality than originally thought possible.
Most of the troubles have been caused by the MIB parsing, something not anticipated before embarking on it. The component selection, on the other hand, proved almost trivial once the right approach was taken. The code generation layering was developed in an iterative fashion and was very successful in solving many of the problems with dependencies in the code.
Somewhat discouraging, though, has been the weak support from the organization. The plug-in developers have shown little interest in the prototype, resulting in a product that has not been tested in a real-world setting. Several bugs and mistakes will probably be revealed once such testing is actually performed.
