Figure 1. Environmental Toolbox Architecture
Over the two years that preceded the release of the 1.0 Beta release, the developers of the Environmental ToolBox faced many challenges in the design and implementation of the system. In the process of developing and implementing the Environmental ToolBox, many lessons were learned. We hope to share some of those lessons with the user community to aid others in the development of complex applications.
Another area that presents some unique challenges in Avenue is that of user interface design. Integrating your application’s needs with the extensive functionality inherent in ArcView can present some difficulties including the need to anticipate a large number of possible user interactions and how that effects the application’s state. In addition, the limited set of control types and the large number of scripts required to handle the various events can make an application difficult to manage. In tackling these issues, we have discovered several techniques and design guidelines that may provide some benefit.
Additionally, testing and debugging extensions can be a difficult and time consuming task because there are many instances where the standard ArcView error handling does not return sufficient information to locate the offending code and often the built-in debugging tools are not available when testing the extension. In response, we have developed some testing/debugging guidelines and a tool to provide a detailed trace of the execution.
Figure 1. Environmental Toolbox Architecture
The dependencies of six of these extensions are shown in Figure 1. Some of these extensions are purely computational. They present no user interface components to the user and thus, are used only by other extensions. An example here is the Data Manager extension that provides a common set of utilities needed by several of the other higher level extensions to perform common tasks such as data import and route polygon generation. The extensions at the top most level in the diagram are those which provide user interface components. One of the key design features in the Environmental Toolbox was the desire to provide a common framework for doing any type of impact analysis such as noise, air pollution, etc. The assessment manager extension provides this common framework by presenting the user with a new document type called a scenario which allows the user to perform common operations, such as selection of a population and definition of the annual set of operations in the area. The interface provided by this extension is itself then extended by the Noise Analysis and Noise Reports extensions to provide functionality particular to environmental noise analysis. The Noise Analysis extension was in turn designed to accept multiple underlying computational extensions to handle the actual noise prediction calculation. The MRNMAP extension implements the standard interface which is required by the Noise Analysis extension and acts as a wrapper for the text file driven application software. ArcView manages all the dependencies at load time. For instance, if the user selected the Noise Analysis extension to be loaded, ArcView would automatically load the Assessment Manager, Data Manager, and MRNMAP extensions as well. There are several advantages to this approach versus a monolithic extension. The first is the flexibility in the design to easily incorporate new functionality in the future. The second is the ability to have developers working on each of these components in parallel. To accomplish this, it is important to clearly identify each script as public or private and to exactly specify the input parameter and the return value. This is essentially the contract between the extension developer and any other developer who might use it. Another advantage that will be addressed later is that it is much easier to test these extensions in isolation rather than having to debug the whole application at once.
Figure 2. AVCVS
To ease its use for ArcView development, we developed an extension called AVCVS that provides the functionality of CVS from within an ArcView project. It stores each Script, Dialog, DocGUI, or other supporting file independently in the CVS repository. This makes looking at source code differences much more useful and allows finer grain tracking of who edited what object and when. A browser provides a quick view of all the objects in the project with current version number and status information. Controls are provided in the browser and within the individual script and dialog editing interfaces to check-in changes, merge updates from the repository, get change logs and version differences, and add and remove objects from the repository. In addition, CVS supports a tag mechanism that can be used to identify the particular set of object versions which went into a particular build of the extension. This allows you to reconstruct any prior release of the extension or use a particular release number as a reference for looking at differences. This has proven to be extremely useful in tracking down the bugs that are inevitably introduced into the code as features are added between revisions.
The technique outlined above works well for extending many object classes which have a visual aspect and which don’t require a great deal of modification. Another technique that can be applied is taken from other traditionally non-OO languages. Originally, perl was not designed as an object oriented language, but was later extended. Essentially perl uses a normal data structure, which maintains the state information, to reference an object. The data structure is "blessed" into a class to allow the new OO operators to access the methods. While this is close to the right idea, it isn’t possible to extend ArcView’s syntax in the same way. A better example is the technique used in many GUI toolkits such as the Gimp Tool Kit (GTK) which are accessed from the C language. In a similar manner, a data structure is used to maintain the state of a particular object instance. The key is in the standard way in which the methods are invoked. A method is simply implemented as a function named using its class name followed by its method name. The function is always called with the first parameter set to the data structure containing the state of that particular object instance. This technique was successfully used in Avenue to implement a Union class that allows multiple VTabs to be accessed as if they were a single VTab. The class was implemented as a new extension that consists of a set of scripts whose names all begin with the word "Union" followed by the standard method name from the VTab class. The input parameter is always a list containing a Dictionary object that maintains all the state information for the instance, followed by the other standard parameters which are required by the method. The return value is the same as that normally returned by the similarly named VTab method. The one exception to this rule is the "UnionMake" script, which accepts information about the VTabs that are to be used and constructs and returns a new Dictionary object for the new instance. The Dictionary structure maintains handles to the individual VTabs, a list of the common field names, the VTab to be used when adding new records, etc. While it is obviously not possible to use this Dictionary data structure as a parameter for other Avenue requests which require a VTab, it does provide a useful construct in many circumstances. Because the method’s names, input parameters, and return values are all identical to a normal VTab, it requires minimal communication between the developer of this extension and any developers who need to use it in their work. One particular use of this extension was in the selection of the population points from two independent shapefiles, one of which contains the initial set of locations and the other containing additional user defined locations. The selection Bitmap used in the new methods is a concatenation of the individual Bitmap objects from the underlying VTabs. This Bitmap can be used to perform a query on the union, loop through the records, and perform updates to the underlying VTabs for instance.
While running your extension outside the development project can avoid the loss of hard work, it also limits the use of the built-in debugging tools. Additionally there are many circumstances where ArcView’s error reporting does not provide sufficient information to locate the offending code. To resolve these limitations, an extension was developed to trace the execution of a running Avenue application. When loaded, the extension shadows all the existing system and extension scripts and provides a detailed log of the execution.
Figure 3. Trace Log
The log identifies the name of the script being executed, the input parameter, and return value. Each entry is indented to show the chain of execution and the input and return values are list expanded and identify the class and value of each item. This tool has proven extremely useful in understanding the execution of event scripts and delayed runs and has helped identify many problems which result in a segmentation fault or "AVARRAY" error, for instance.
Figure 4. Mission List Dialog
As one can see, there are a variety of Dialog Designer controls in use for this dialog. An interesting feature of this dialog and its underlying code is seen in the "Operations" control. This user interface component mimics a simple spreadsheet for the input of annual mission operations. Through Avenue scripts, the user can select either a single entry or an entire column for input. Although it would have been nice for Dialog Designer to have included a spreadsheet widget as part of the supplied controls, we have demonstrated that at least some rudimentary functionality can be achieved through concerted Avenue programming.
As far as advice to users of Dialog Designer in the development of more complex user interfaces, we would offer these points:
One other area to investigate is the implementation of event scripts. If you discover that you have a large number of event scripts and/or these event scripts have similar code, you can look at consolidating these into a single script. This can be done by embedding code in the event script to check for the name of the control that initiated it. Avoid taking this to extremes by consolidating every event into one script for instance. There is some additional overhead in the script to determine what control invoked it and one giant event script can be even more difficult to interpret than the sea of event scripts with which you started.
At this point, we may ask, "How could Dialog Designer be better?" We offer a few suggestions to make Dialog Designer a more complete product:
The second method is more appropriate when the new document type should provide a restrictive environment to the user. In the Environmental Toolbox, the Mission Sets document type was implemented in this manner. A Mission Set document manages all the operational data for a particular region. Because of its focused usage, many of the tools provided by ArcView for a View document are unnecessary and it is in fact difficult to anticipate the complex impact the use of these controls will have on the state of the application.
In contrast, the first method was used in the implementation of the Scenario document type. Because Scenarios are intended to provide an open mechanism for the analyst to evaluate a variety of environmental impacts, it is desirable for the user to have access to the full functionality of ArcView and its other extensions. For these reasons, the Scenario DocGUI is constructed in the installation script. This retains all the built-in functionality of a View and any functionality that has been added by any additional extensions.
There are clear advantages and disadvantages to both approaches and they must be weighed independently for each application.
Raymond L. Gates
Computer Scientist, Computer Sciences Corporation
NASA/LaRC GIS Team
MS 445
NASA Langley Research Center
Hampton VA 23681
Tel: 757-864-6993
Fax: 757-864-8463
Email: raymond.l.gates