Automatic GUI Creation
Generating Java source code from formal descriptions

3. Component Selection

This section explains how the prototype application selects graphical components for the plug-in interface. The first part details how a plug-in interface is structured and how the MIB fields are mapped to components. The second part describes how the user can interact and change components while creating the plug-in. A number of screenshots from the prototype are also included.

3.1 The plug-in interface

A plug-in in the operation and maintenance system should be divided into several layers of functionality. In the lowest layer the actual SNMP transactions are handled, and in the highest layer data is presented to the user in a graphical user interface (GUI). Between these two extremes are the other layers, responsible for interface logic, temporary data storage, and data dependencies.

In a standard MIB file the number of fields is quite high, making it impossible to show them all at once. A normal plug-in interface therefore consists of a set of tabs, as can be seen in figure 1. Each tab contains a reasonable number of related fields with some usable layout.

Java interface components

A graphical user interface in Java is constructed as a hierarchy of special objects called components. Each component can be either simple, as a label or a text field, or a compound of other components, as a tab panel. The simple components are layout inside the compound ones using special layout information that can be provided inside the program.

There are two component hierarchies in Java—the older AWT components, and the newer Swing components. Both are included in the modern Java platforms and the Swing components can also be mixed with the AWT components without much trouble. As Swing is a newer and more feature-rich solution it is the recommended choice for most applications, especially if they are not required to run from any old web browser.

The plug-in interfaces use the Swing components as they provide a richer set of features and are more extensible. Some additional components have been written to handle specialized data, as numeric IP addresses, and to fill some gaps missing in the Swing framework. Especially input verification in the components is needed for the plug-ins.

From fields to components

It is worth noting that many data fields require several components in the interface, as labels are sometimes necessary to for provide information about the data presented (see for example figure 1). This means that the mapping from MIB fields to components in the plug-in interface cannot be one-to-one, as several components will have to be generated on some occasions.

The mapping from data type to component is not always obvious, and on some occasions it may also be impossible to do by automated means, at least with a satisfying result. The choice of interface components is normally a decision that involves aspects of human-computer interaction, which means that it is not easily formalized into simple rules. The result of the automatic mapping from data type to component will therefore sometimes be mistaken, as it does not take the data semantics and context into account.

In table 1 the default mapping from data type to component is shown. Some of the components specified in reality also refer to additional labels, as such are needed in some cases. The mapping is not trivial and contains several special cases for data that may only be read.

3.2 Interaction in the prototype

Although a lot of information can be extracted from the MIB files, it is not reasonable to generate the plug-ins in a fully automated fashion. The grouping of the fields rarely corresponds to the structure in the MIB files, and the default field to component mapping may cause problems. It is therefore hardly sufficient with the simple command line syntax most compilers have, as such an interface would be far too complex.

Instead, the interaction called for is that of a graphical user interface, allowing the user to see the various component selections as well as information about each field. Using such an interface also gives an easy way to collect the additional information needed for the code generation, such as the plug-in name, output package, and output path.

The prototype created therefore provides an interactive graphical interface, instead of more standard command-line options. The main application window contains fields for entering all the plug-in creation parameters, as can be seen in figure 2. The window also displays which MIB files are currently loaded and a list of the field groups, called “tabs”. The MIB files and the tabs can then be further viewed in separate dialogs.

Having a richer interaction also provides natural open and save functions, allowing plug-in generation parameters to be stored to file for later usage. This also provides some level of iteration to the plug-in development, as the previous choices can be stored until processing the next version of the MIB.

Structuring the fields

The structuring of the fields into tabs is difficult to do automatically, as the structure inside the MIB files does not provide a division that is recommendable to use for the interface. The tabs are therefore created manually in the prototype.

Tabs are constructed in two steps; first the tab is created and named, and second a set of fields is assigned to the tab. The tab creation is done in the lower left part of the main window (see figure 2), and new tabs can be created at any time. If a MIB file has been loaded, the fields from it can also be assigned to one of the tabs, something normally done in the tab edit dialog (see figure 3).

By default the fields don’t belong to any tab, meaning that they will be ignored when generating the output plug-in. Each field may only belong to one single tab, and will thus be included in the output code for the plug-in and that specific tab.

Fields may also be loaded from several MIB files, which is sometimes necessary to allow common fields to be reused among several network components. An important restriction to the capability to load several MIB files in the current prototype is that no two fields may have the same name. If field names are equal, the generated output code may contain duplicate variable names.

Changing the component mapping

Once a field has been assigned to a specific tab, a component is automatically chosen with the default field mapping presented previously. The chosen component can then be changed to any other component supported by the system, allowing the user to correct mistakes made in the automated process.

The changing of components is done in the MIB dialog (see figure 4), where all the fields in the MIB are presented along with analysis information. The tree structure of the MIB files is used for presenting the fields to the user, although this information is not used when actually generating the plug-in.

There is no one-to-one mapping between the components available for selection, and the components in the underlying Java Swing framework. The components available are really component generators, as they are also capable of generating source code for the component. The component generators also handle the creation of several components where needed, without the need for manual interaction. Several Swing components are also missing as they have little usage in a plug-in interface, and some new components have been added, such as an integer field and an IP address field. The user can also choose to not generate a component for a specific field.

When choosing to not generate a component, the field will be excluded from the graphical interface, but code will still be generated for lower layers in the plug-in. The exclusion of a field from the interface does not mean that the data will not be accessible, as it will still be present in the lower plug-in layers.