David J. Maguire
Application customisation is often one of the most time-consuming and expensive elements of implementing a GIS. It is also one of the keys to a successful GIS. This paper reviews the principal issues involved in customising a GIS and discusses the facilities that are available within ArcInfo to facilitate the process. The use of AML, ArcTools and the ADF is described.
Over the past twenty-five years or so many people have become aware of the benefits which accrue from organising and integrating data geographically. Indeed, such has been the success of this approach that Geographical Information Systems (GIS) have been applied to an extremely wide range of application areas. In order to satisfy the requirements of this diverse community, many GIS software developers have adopted the strategy of developing a generic suite of multi-purpose software routines, together with some type of customisation programming capability. This allows core GIS software developers to concentrate effort on engineering robust and reliable generic routines. The task of creating specific-purpose, end-user (or vertical application) customisations is usually seen as the domain of application developers. These application developers may belong to the core software developer's organisation, the user's organisation, or some independent organisation.
In recent months Esri has undertaken a survey of the GIS customisation requirements of its existing and potential users and developers. The main requirements listed are shown in Figure 1 along with Esri's ArcInfo facilities.
In essence it seems that users and developers want a GIS customisation environment that is easy to use and highly productive, yet offers access to powerful and sophisticated tools. Throughout the evolution of its software products Esri has always attempted to build systems which fulfil these goals. This paper seeks to discuss the key issues and tasks associated with successfully implementing a GIS application customisation and outlines Esri's strategy for meeting developer requirements.
It is essential that any GIS application development activity meets user requirements and that it is on time, in budget and in accordance with quality standards. These goals will be greatly facilitated if a rigorous software engineering approach is adopted. The basic idea in software engineering is that development is split up into a series of independent steps which are carried out in sequence (Figure 2). In this software development lifecycle (also called the waterfall model) each step is well defined and leads to a definite product (often a piece of paper), thus allowing the correctness of each step to be checked. An excellent introduction to software engineering is provided by Bell, Morrey and Pugh (1992).
The first stage in the software development lifecycle is to establish user requirements. Essentially, this involves a dialogue between one or more representatives from the user and application developer groups (usually called an analyst). Initially ideas will be loose and vague in part, but over time they will become clearly defined. This is arguably the most important and sometimes difficult stage of application development
User requirements need to be formally specified if they are to be of use as a description of the application to be developed. They also form the basis of an acceptance test which will determine if the system meets its requirements. Formal specification is all about describing what an application will do not how it will do it; this should be left to the discretion of the programmer.
The design stage involves the application developer in creating conceptual, logical and physical designs of the system. Theses stages progressively refine the application design from being implementation independent to being system specific. In GIS application development the design stage will typically address the user interface, the database and the methods (procedures) employed. There are various tools available to assist in this process. These include data flow modelling (Jackson 1975) and various database diagramming techniques such as entity-relational modelling and object modelling technique (Chen 1976, Rumbaugh et al. 1991).
There is now almost universal agreement amongst software developers that applications (indeed all software systems) should be designed and implemented using structured programming techniques, and that an application should be created as a series of independent modules. Modular software development is preferred because it supports software reuse and co-operative development, maintenance, testing and debugging.
Implementation is all about coding, testing and debugging the design. In the past this is what people have thought of as "programming". The implementation stage usually concludes with a period of acceptance testing and bug fixing, before final sign-off.
The last stage is the operation and maintenance of an application. This will typically involve a period of user training, system enhancement, bug fixing and, of course, system use.
The software engineering scheme for application development outlined above is traditional in its approach. In recent years there have been a number of refinements and enhancements, probably the most important of which is the introduction of prototyping (the creation of subsets of a system for user education and evaluation). The classical approach outlined above assumes that users have an idea about what they want and that they understand what is possible with current technology. In a relatively new and fast moving field like GIS this is not always the case. An alternative to the waterfall model is to develop applications incrementally as a series of prototypes that can be discussed and amended as appropriate. In addition to helping users and developers specify and design systems, other advantages of prototyping include the availability of early results and deliverables, as well as reduced costs because the right application is developed. On the downside, prototyping is not helpful for providing fixed prices for development, nor is it appropriate for small jobs.
On balance most technical GIS people would agree that all GIS application development projects require a clear implementation plan which identifies a sequence of well defined tasks. Whether the classical waterfall approach is adopted, or whether prototyping is used, is open to discussion by the user and developer. Further details about the use of prototyping in GIS may be found in the Esri White Paper Prototyping AM/FM/GIS Applications: quality/schedule trade-offs (Esri 1994).
Esri's product family comprises a series of three software products designed to meet the diverse needs of the GIS user community.
ArcInfo is Esri's full featured professional GIS software system. It comprises an integrated collection of geo-processing tools capable of dealing with data entry, management, manipulation, analysis, display and plotting. ArcInfo is available on popular UNIX platforms and VMS. A substantial subset of the software is available for PCs running DOS or MS Windows.
ArcCAD is an engineering GIS solution which adds some of the database, cartography and spatial analysis capabilities of ArcInfo into the AutoCAD user interface. Like ArcInfo, ArcCAD is a stand alone GIS solution.
ArcView is a desk top GIS product offering easy access to spatial data. It operates both as a stand alone solution and as a client to an ArcInfo server, supporting both distributed data access and processing. ArcView is particularly suited to spatial data integration, display and query, as well as simple analysis and plotting.
All these three products are designed according to the same basic principles of providing a strong collection of generic geo-processing tools, together with an application development language which can be used to create specific-purpose applications. Currently, ArcInfo is the main platform for developing large application customisations and so the remaining part of this paper will concentrate on this software product. Many of the points are, however, appropriate to all Esri software products.
From the application developer's viewpoint a GIS application is normally thought of as a GUI, some processing tools and a data management system. ArcInfo offers a comprehensive data management capability and set of specific tools which can be combined together to create an application (Figure 3). Applications are developed using the Arc Macro Language (AML), a 4GL programming language. To assist application developers Esri has developed two suites of higher level tools, called ArcTools and the Application Development Framework (ADF). The next section discusses each of these in more detail.
For completeness is also necessary to discuss briefly the ArcSdl specialist lower level application customisation capability. ArcSdl is a collection of low level object code libraries. These comprise a series of C and FORTRAN software modules and an API (Application Programming Interface). ArcInfo itself is built by Esri from these software libraries. Application developers can embed some or all of them in their own applications or else use them to embed other software routines in ArcInfo.
AML is the language through which users communicate with
ArcInfo. AML provides full programming capabilities and a set of
tools to tailor the user interface to create general and specific purpose
applications. AML can be used throughout ArcInfo to perform a
variety of tasks. It allows users to:
AML is an integrated part of ArcInfo, it recognises objects (such as coverages, libraries and route systems) and can provide information about them as well as specific ARC environments. AML is a high level, user oriented language supporting actions such as branching, variable manipulation, subroutines and argument transfer.
AML is available anywhere, at anytime in ARC, as an interactive language. Alternatively, commands and AML instructions can be entered into a file using a standard system editor. These AML files can then be executed. AML is an interpreted language (AML encryption is available as an option to prevent users changing code). AMLs can consist of only ArcInfo commands, or they can combine ArcInfo commands and other AML-specific elements which result in sophisticated and powerful actions. These elements are intrinsic features of the language, such as line continuation, directives (similar to programming statements, for example &TYPE and &RUN), functions ([SHOW], [ABS], [GETSYMBOL], etc.) and variables. Although it has very powerful facilitates which experienced users can incorporate into well organised, sophisticated and efficient applications, it is relatively easy for the beginner to create productive programs and applications.
One of the most useful and highly visible features of AML is the ability to create menu-based user interfaces. These are based on the OpenLook and OSF/Motif window manager standards. AML supports seven different types of menu: pulldown, sidebar, matrix, key, tablet, digitiser and form. The instructions to create a menu are entered into a file which is then executed. Menus can contain user-defined icons that, when selected, can perform operations such as building topology and describing coverage features. In addition, menus can contain widgets (high level interactive graphical tools) allowing users to interact with the menu before execution. ArcInfo supports a range of widgets including choice fields, slider bars, buttons, scrolling lists, check boxes and display fields. Using these widgets, users can choose a value for a variable interactively and then pass this value to a command for execution. For example, the name of a coverage to be described can be selected from a scrolling list (itself determined interactively by searching a workspace). The name of the coverage can then be used as an argument to the DESCRIBE command in ArcInfo.
AML can interface to other external programs using inter-application communication functions based on Remote Procedure Calls (RPCs). This allows AML to run external subroutines written in FORTRAN or C and to communicate with external programs (including other ArcInfo systems). Arguments can be passed to the external program and values can be returned to AML for further processing.
Menu interfaces created using AML can be multi-threaded, that is, they can accept input from multiple sources. For example, an urban application might present several menus on screen, each one containing a logical group of functionality. One menu might let the user select actions, another present the status of the application tasks to be performed and a third used to input environment settings. Pressing a button in one menu could update the display of another menu.
An important part of AML is the ability for application developers to create form menus interactively using the FormEdit graphical design tool. FormEdit combines the graphical component of menu layout and design, with the descriptive or syntactic component that defines the operation of the individual objects, or widgets, in the menu. FormEdit can be used to create new menus or edit existing ones. It greatly simplifies the creation and editing process, allowing users to concentrate on menu design rather than syntax. Once initiated, FormEdit displays two windows: a widget palette and a menu canvas (Figure 4). Users create new menus by dragging widgets on to the blank canvas. The widgets can then be resized and moved interactively using the mouse. Double clicking on the widget pulls up the widget property sheet. This contains information about the actions of the widget. Default values are presented wherever possible so that the user simply has to enter values into the form, rather than try and remember specific syntax. Once saved, menus created using FormEdit can be called by any AML programs.
Figure 4 shows ArcInfo's graphical development environment. The display shows two menus from an application under development (Labelled "Map Tools" and "LINE Theme Properties") and a display window (labelled "ARCPLOT"). In the bottom left-hand corner is a text dialogue window in which messages and text dialogue will appear. In the centre of the screen there is a Text Editor window which is used to edit programs and, optionally, menu descriptions in ASCII format. Below this is the File Browser window (labelled "Select a Coverage"). This is used to navigate the system filestore in order to locate workspaces and specific files. The two clipped windows on the right- hand side are the FormEdit interactive graphical menu-builder. The upper window ("ArcInfo Form Editor") is a widget palette showing the types of widgets which users can place in menus. The lower window shows the FormEdit menu canvas for the menu labelled "LINE Theme Properties") on the left-hand side of the screen. Changes made using FormEdit can be run straight away in the application to determine their impact and to assist debugging. This greatly facilitates the application development process.
Figure 4 has been designed to show the main types of tools available to developers. Usually only a selection of the windows are open at anyone time. Most application developers prefer instead to close or iconise windows until they are needed.
ArcTools can be considered both the default menu-driven GUI for ArcInfo and a suite of object oriented extensions. Since standard ArcTools provides for Graphical and Attribute Data Editing, Query, Map Composition, Raster Geo-processing, 3-d Modelling and Network Analysis, most of the main areas of user activity are covered. Once initiated, these tools provide a fully interactive collection of menus offering access to all the principal ArcInfo functions.
ArcTools has been developed using an object oriented style in
which methods (programs) are encapsulated with objects (menu
widgets). Each ArcTool is, therefore, an independent object. The tool
objects are generic and reusable building blocks suitable for assembly
into large applications. Each tool comprises four elements:
interface - a user view of a tool (form menu);
engine (methods which perform the actual operations (AML);
Icon - a graphical representation of the tool;
Help - ASCII file concerning information about the tool.
ArcTools is built using the Arc Macro Language (AML) described above. It provides users with easy access to the powerful range of ARC, ARCEDIT, ARCPLOT, GRID, TIN, Network, ArcScan, ArcStorm and INFO/DBMS commands via a suite of menus. A standard set of tools is provided for file browsing, checking access, changing workspaces, etc.
ArcTools comprises a set of individual tools grouped into five Tool
Sets, divided as follows:
Some examples of ArcTools are shown in Figure 5.
The ArcTools menu system not only provides a menu driven interface, but also includes ways of maintaining information about certain parameters or properties the user has specified for displaying data, creating a map, editing a coverage, or creating a GRID Model. The ArcTools menu system is object-oriented, allowing the user to define various GIS objects and their properties, and perform operations on those objects. An example of the object oriented approach is the development of a theme. Instead of specifying all the properties required to display a set of data every time it is to be displayed or queried, ArcTools creates a 'Theme' which stores the properties about which data source is displayed, what symbols are to be used and what attributes can be accessed. Other objects include map objects (legends, scale bars, north arrows etc.) for map layouts, and steps (slope functions, re-classify functions etc.) for models.
In addition to providing easy access to the functionality of ArcInfo. ArcTools exists as a set of stand alone tools that can be incorporated into in-house applications. Each tool is designed to run independently, therefore ArcTools can be easily customised to include specific functionality by adding or deleting tools. ArcTools adheres to strict standards for variable names, argument passing, naming conventions and standard routines.
The Application Development Framework (ADF) is a ‘rapid application development’ methodology that uses a modular suite of reusable application software tools, structured around a cohesive data management philosophy. The ADF can be used to create customised applications on top of ArcInfo. Physically, the ADF comprises documentation and a series of core interoperable modules: software tools; data catalogue; task engine; and management shell. The ADF is available to application developers by agreement with Esri.
Detailed evaluation of the GIS usage of many organisations has revealed that most database and mapping activity involves several core functions. These activities are supported by a collection of software tools which include: data input/export; thematic mapping; map format composition; map library management; editing; quality control; query management; and report format generation.
The Data Catalogue is a series of tables describing both the physical structure of an organisation's ArcInfo and/or RDBMS databases, and any logical user views of the data. The Data Catalogue supports data validation, user naming and theme (user view) creation and use.
Many of the operational activities which users routinely perform involve carrying out a sequential task. The Task Engine applies a process-oriented approach to these applications, by executing, tracking and controlling these steps. Most of the custom applications built using the ADF software tools are divided into tasks and implemented as one or more processing strips.
The Management Shell is a simple, interactive, menu-driven system module that provides a common and consistent user interface between systems. It provides both a standard entry/exit point and acts as a security system.
The earlier description reveals that ArcInfo offers application
developers a wealth of facilities for customising the basic tool box.
Essentially, three approaches are available:
The later two offer the advantage of providing existing software tools and methodologies which can be readily utilised in application development. Whichever route is chosen the application developer can implement an application using the waterfall method of development (with or without rapid prototyping). If properly designed (for example, using the ArcTools style guide) then the application should be highly productive and easy to use.
The development of applications is greatly facilitated by the use of AMLs interactive form menu builder, the close integration with databases (via the Database Integrator) and structures for developing reusable software modules. Developers can also interface with other software systems and applications using Remote Procedure Calls (standard implementation of IAC on workstations). Once applications have been developed they can be protected by encryption. Esri's capabilities for handling key application developer requirements were shown in Figure 1.
Bell D, Morrey I and Pugh J (1992) Software engineering: a programming approach. 2nd edn. Prenctice-Hall, New York
Chen P P (1976) The entity-relationship model: towards a unified view of data. ACM Transactions on Database Systems 1(1): 9-35
Rumbaugh J, Blaha M, Premerlani W, Eddy F, Lorensen W (1991) Object oriented modelling and design Englewood Cliffs, New Jersey: Prentice-Hall
Esri (1994) Paper Prototyping AM/M/GIS. Applications: quality/schedule trade-offs Esri White Paper Esri, Redlands