by Arthur Chance, Richard G. Newell & David G. Theriault

Abstract

The current generation of software tools is inadequate to satisfy the wide diversity
of GIS requirements in a seamless manner. In addition the tools provided to develop
user applications or to customise current GIS offerings exacerbate the problem.
Object oriented programming systems (OOPS) are now recognised as a key component
in building powerful applications which are robust and maintainable and which are
also to be seamlessly extendible. Unfortunately, many myths surround OOPS: that
they are difficult, simply fashionable, or inherently slow. This paper will propose
that an OOPS coupled with an interactive programming environment can be highly
effective when applied to the demanding requirements of GIS. It describes a rich,
but user-friendly, polymorphic, exemplar- based environment which supports today’s
emerging standards and which has proven highly appropriate to the development and
implementation of GIS.

Introduction

The largest costs incurred for any organisation embarking on the implementation
of a GIS are data conversion, hardware and software, and system implementation,
particularly customisation. It is now recognised that no GIS on the market today
does it all, thus implying that the missing functionality has to be added to the
base system in order to satisfy any particular customer. Yet rarely do you see,
in the many papers describing how to choose a GIS, the need for assessing the ability
of a system to be customised. It is common for the next most expensive item after
data conversion to be customisation.

Most checklists for choosing a GIS concentrate on long lists of superficial functionality,
and little is said of an assessment of the quality of basic system fundamentals
and foundations. The most important fundamentals to get right in a technology as
complex as GIS are the basic database architecture, and the data models implemented
within that architecture together with the software architecture needed to extend
the system at low cost.

During the last ten years or so, enormous strides have been made in the development
of hardware. Processors are at least 20 times faster, memory is 500 times bigger,
disks are hundreds of times bigger. The advance in hardware has fuelled a parallel
advance in fundamental database software. The relational model has advanced from
the era when there were doubts as to whether it could be made to work at all to
now being the dominant technology.

In contrast, the advance in the development of tools to develop and adapt software
systems is nothing like so dramatic. We all know that most of the world’s commercial
software is still written in Cobol, most of the technical software is still written
in Fortran. Even “modern” languages such as C do not give a whole lot more in productivity
and maintainability when compared to the huge advances in other technologies.

The advent of CASE tools and 4GLs make some attempt to address the issue. It is
our belief that the fundamental system architecture itself has to be rethought
if large strides are to be made. This paper proposes an interactive hybrid object-oriented,
procedural language as a key component of such an architecture. We are well aware
that the term “object-oriented” is frequently bandied about with very few people
understanding what it means. We also attempt in this paper to explain what the
technology means, and why it should be of significance to the implementation of
GIS.

Conventional System Structure

Traditionally, large interactive systems were developed in a non-interactive procedural
language, such as Fortran or C. In order that an end user could drive such a system,
an interactive command language was provided so that the user could type in his
commands. Many command languages evolved into programming languages sometimes by
borrowing the programming concepts of Basic. In more modern user interfaces, this
command language may well be hidden behind a system of screen menus, tablet menus
or other input devices. Large modular systems were glued together using an operating
system commands or script (see Figure 1). Within the system, developers and customisers
had a number of other languages available to them to define such things as syntax,
menus, data descriptions, graphic codes, etc, all running as different processes
communicating by files.

The structure of such systems was commonly organized at the highest level around
the command syntax and complex commands were structured in a top down approach
from there. If one examines systems that have been put together in this manner
over the last five to ten years they all suffer a number of difficulties:

• Development is slow. Users’ requests for enhancement have to wait for the next
  release, which is usually over a year away.
• They are difficult and expensive to maintain. During the life cycle of the
  system, probably 90% of development goes into maintenance.
• Major restructuring in the light of five or ten years of hindsight is unthinkable.
• Customisation is arbitrarily done in one or more of the many languages used
  to put the system together, typically Fortran or the command language.
• Integration with other systems is nearly impossible.

[ Figure 1 not available ]

Much effort has gone into toolkits for developing and customising systems including
standard graphics libraries, user interface managers, data managers, windowing
systems, etc. However, if one wishes to get in and program or customise any of
these systems, one is confronted with operating system commands, Fortran, C, SQL,
embedded SQL, some online command language, domain specific 4GLs or a combination
of these; not to mention auxiliary
“languages” to define user syntax, menus, data definitions, data dictionaries,
etc. With these kinds of programming tools it can take many man-months of skilled
programmer effort to achieve even modest system customisation.

Development Languages

It is a common problem with systems that contain parts that are front ended by
different languages that it is not possible to integrate them properly. For example,
a graphics system for mapping, which is “hooked into” a database, typically does
not allow the full power of the database to be accessed from within the graphics
command language, nor can the power of the graphics system be invoked from within
the database query language. What is really needed is a system such that all data
and functions can be accessed and manipulated in one seamless programming environment
(Butler 1988).

What has been shown by a number of organisations is that the same development
carried out with an on-line object orientated programming language can cut such
development times by a very large factor (e.g. 20). Object orientation does not
just mean that there is a database with objects in it, but that the system is organised
around the concept of objects which have behaviour (methods). Objects belong to
classes which are arranged in a hierarchy (preferably a heterarchy). Subclasses
inherit behaviour and communication between objects is via a system of message
passing thereby providing very robust interfaces.

Firstly, such a language should be able to provide facilities covering the normal
requirements of an operating system, customisation, applications programming and
most systems programming. Secondly, the language should have a friendly syntax
that allows casual users to write simple programs for quick online customisation.
Larger programs should be in a form that is easily readable and debuggable. Thirdly,
the language must be usable in an interactive mode.

There are several languages around which satisfy some of these requirements: Basic
is alright for simple programs (large impressive systems have been implemented
using some of the more advanced modern Basics); Lisp has much of the power and
speed, but is hardly readable (however, much of the success of Autocad may be attributed
to Autolisp). Smalltalk has both speed and object orientation, but with the total
exclusion of any other programming construct. Postscript is very widely used and
has a number of the desired features, but is another write-only language (i.e. “unreadable” by
anyone, including the original programmer). Hypertalk is wonderful, but you would
not write a large system in it. C++ has much of the required syntax and semantics,
but it is not available as a front end language and can therefore only be accessed
by a select few system builders, normally employed by the system vendor.

Having dismissed most of the well known languages developed during the last 30
years, then what is required? It is an on line programming language, with a friendly
Algol-like control structure and the powerful object oriented semantics of languages
like Smalltalk.

What Is Object Orientation?

The dominant style of programming has always been procedural, the structure of
the program being organised around the functions being performed, usually in a
top down hierarchy of procedure calls. An object oriented programming language
is one where the program is organised around the objects being processed, usually
in a hierarchy of objects which can share (inherit) the procedures (methods) belonging
to other objects.

Object-orientation is not an easy concept to explain, however, its importance
is not in doubt. Object orientation will become the dominant approach to structuring
and building large complex systems in the future.

Efficiency in the development of computer systems depends on how easily they are
modified and enhanced. Changes in an evolving system are either concerned with
changes in function or changes in data structure. Procedural programming does a
reasonable job in localising changes to function by means of such devices as routine
libraries, but changes to data structures usually mean a cascade of side effects
as the data structures are referred to in many parts of the system. Object-oriented
programming goes a long way to localising these changes also.

An object comprises two things, its own state (manifested as a set of instance
variables) which no other part of the system can access directly and a set of procedures
(called methods) which describe its behaviour. Everything about an object is encapsulated
within it and the only way of getting data out of it, or changing it, or getting
it to do something is by sending messages to it. An object is a rather sophisticated
extension of the concept of variable in other languages.

Quite frequently, objects of different classes might be similar, in that one class
might exhibit all the behaviour of another plus some additional behaviour. In other
words, one class may share a number of other classes’ methods, but also has a different
version of some methods and some new methods of its own. In these cases one class
can be defined as a subclass of another so that it can inherit the shared behaviour.

Object orientation, which embodies the above concepts of encapsulation and inheritance
brings the following benefits:

• Code sharing is greatly increased, thereby increasing programmer productivity.
• System modules communicate via well defined interfaces, which means it is easier
  to find bugs.
• It is easier to maintain software: both minor enhancements and sometimes major
  restructuring. Maintenance costs are reduced.
• The environment is not only extremely good for prototyping, but also can be
  used as a base for a production system.
• User interfaces can be iterated to their optimum much more easily.
• Object orientation is very suited to the manipulation of heavily structured
  data.

One of the commonest reservations echoed about object orientation is whether it
can be made to work with acceptable performance. One recalls the same remarks being
made about relational databases nearly 15 years ago.

It is true, object oriented languages do run slower than procedural ones. This
is mainly because the message expression may take more time to evaluate and also
programming style tends to lead to large numbers of messages being sent (procedures
being called) to rather small methods (procedures). This performance issue is now
considerably offset by improved compiler techniques, faster hardware, and using
a procedural approach where appropriate.

In any case, much customisation today is carried out by writing macros in the
system command language. As these are run via an interpreter, they are far slower
to execute than a properly implemented object-oriented language.

At the end of the day, the benefits to the system customiser are that he can perform
major system enhancements in a fraction of the time taken with a conventional system,
and for the end user, a much richer functionality in his system and far fewer delays
in waiting for enhancements.

Object Oriented Databases

One often hears the term object-oriented applied (sometimes wrongly) to many kinds
of systems. So what does the term object-oriented database mean? At first sight
it seems strange for a term which was originally used to describe a programming
language, usually in comparison to procedural languages.

Now when one comes to databases, all conventional databases are (sort of) object-based.
In a relational database, the objects around which the data are organised are tables,
records and fields. There are some higher level objects, such as views, but there
is no explicit representation of the highest level objects such as real world things.
Much of the more recent development has been how to embody high level semantics
in the model, but still, the database itself does not embody itself any of the
behaviour definitions of the objects it contains (Oxborrow 1989).

Now, one doesn’t often hear the term procedural applied to databases, although
one recalls the work by Martin Newell (Newell 1975) on procedure models, in which
he built a modelling system out of procedures, and all operations on the model
(such as rendering) made calls to the procedure models. These then made the right
responses and did the required things when asked. The behaviour of the objects
to be rendered was encapsulated within the procedure models and not within the
rendering algorithms. This is similar to the encapsulation concept of object-oriented
programming languages.

The term object-oriented database is commonly used to mean that the unit of communication
to the database is an object: you put an object in, and you get an object out.
But this is a facile use of the term, since the crucial thing about object-orientation
is that the objects contain their own behaviour and therefore the database needs
to manage the procedures (methods) that define that behaviour. Further, communication
with the database should be by a system of message passing where the user is isolated
from the actual internal representations of the objects.

One view of an object-oriented database is that it is an extension of an object-oriented
language to handle persistence, queries, concurrency (multi-user), security and
integrity. Another view is that it is an extension of a conventional database to
handle procedures, inheritance and message passing. It is a moot point as to whether
the conventional divide between the ephemeral working data of the programming environment
and the persistent data in the database should be maintained or not.

Commercial object-oriented database systems are only just beginning to appear
in the market place. Relational databases suffer a number of serious short-comings
for applications in GIS (Egenhofer 1989, Frank 1988, Oxborrow 1989). Some of these
problems stem from the particular features of the implementation of current commercial
relational databases, not using the facilities of those databases in the most appropriate
manner, and the awful syntax and current limitations of SQL (Herring et al 1988).
However, the absence of real world semantics in the relational model itself means
that the tools provided are at a very low level.

All implementations of the relational model compromise to some extent Codd’s rules,
from those which are no more than tabular representations to the ones that satisfy
most. In particular, the semantics of range queries and versions are missing. However,
tabular representations are a good way to make an efficient engine for managing
persistent data. It is therefore our belief at the moment, that a practical way
to implement an object-oriented database across many platforms is to combine relational
(or tabular) technology with an object-oriented language. This allows higher level
semantics to be embodied in the object-oriented environment of the language.

The Magik Object-Oriented Programming Environment

Magik is an extremely powerful language for the implementation of large interactive
systems. The language is a hybrid of the procedural and object oriented approaches
and program development is carried out in an interactive environment. The interactive
environment allows changes to the system to be immediately tested, without a prolonged
linking process and regardless of the size of the system.

We have implemented Magik in order to build an open, seamless development environment.
The way this is achieved is by embodying the following features in the language
and its development environment:

• There is but one language for system, application and customisation development.
• Both object orientation and procedural methodologies are supported.
• Development is in an interactive environment.
• The language is expressive and very readable.
• There is an extensive library of standard object classes, methods and procedures.
• The language is built as a platform suitable for delivering commercial systems.
• Applications can be transferred with a minimum of effort between hardware platforms.

It is our belief that the presence of all these features is essential if commercial
systems are to be developed, maintained and customised with a minimum of programmer
effort. It is the lack of a viable language with a sufficient subset of these facilities
that has stimulated us to produce our own which embodies all of them.

[ Figure 2 not available ]

Magik allows programs to be developed in one seamless environment, meaning that
systems programming, applications development, system integration, and customisation
are all written in one environment in the same language. Thus, end users who wish
to customise the system can be confident in the quality of the tools provided because
they are identical to the development tools used by the core and application system
developers. Further, existing systems, such as most database management systems,
can be fully integrated so that to the user they appear as part of one homogeneous
system.

The Virtual Database

It has been said that GIS could be regarded as an integrating technology providing
a window into many disparate distributed databases. If this goal is to be achieved
then an architecture is needed in which the databases to be integrated need to
be set up as servers to the single client GIS.

There is a number of shortcomings in existing available database technology for
the building of a GIS. Nevertheless, there are now many organisat-ions which have
committed in a big way to one of the emerging de facto standard database systems.
It is not acceptable for a GIS vendor to try to displace such a database with something
else tuned for GIS applications. It is necessary to engineer a solution which preserves
the user’s investment while at the same time doing as good a job as possible in
providing a GIS capability. As mentioned above, if one tries to handle all data
in the commercial DBMS, then it is highly likely that a serious performance problem
will result. If one runs a geometric DBMS alongside, then serious problems of backout,
recovery and integrity may result. It would seem that what is needed is some “virtual
DBMS” which can act as a front end to two or more physical DBMSs, and that this
should handle versioning (Easterfield et al 1990, Newell et al 1990) and have a
knowledge of all aspects to do with data dictionary, integrity, and access to the
various data. Data modelling of objects allows the user’s models to be built with
full recognition of their semantic content a key feature not provided in the relational
world (Worboys et al 1989).

We have built a low level interface between the object-oriented and tabular worlds
in which a table maps onto an object class, a record maps onto an instance and
a field maps onto a slot. Higher level abstractions are then modelled wholly in
the object-oriented world. Such a representation is ideal for many of the navigational
style queries that one undertakes in a GIS.

The User’s View Of An Object-Oriented GIS

Any system built using an object-oriented environment could also be built by other
methods, and the end user may well be hard pressed to tell the difference. Sometimes,
systems claim to be object-oriented, because they are built out of an object-oriented
language which is non-interactive. In such systems, end users are denied the major
merit of the approach, which is the ability to modify and extend the system on
line. The claim to object-orientation may be valid, but, so what, if the rest of
the world cannot use it.

Icon driven user interfaces are sometimes called object-oriented. This description
might be justified if the icons represent data objects and when clicked they know
what to do. For example on the Macintosh, clicking on a document icon results in
the appropriate word processor (drawing program, spread sheet, etc.) being started.
This differs from function icons to which you must later supply the data.

For a GIS to deserve the term object-oriented it needs rather more than an object-oriented
systems language and user interface.

The customiser of a system built with an interactive object-oriented front end
language is provided with an extremely open architecture in which he can access
and use many existing classes and their methods. He is provided with browsers to
explore this rich environment of existing functionality in order that he can utilise
it and modify it to make his own extensions to the system. The analogy has been
made to the hardware designer who is given an extensive library of standard components
of which he knows how they perform to given inputs, even though it is unnecessary
to know how they work internally. However, in the object oriented world he can
also make his own components (classes) which can borrow behaviour from one or more
existing classes (multiple inheritance).

The GIS applications programmer perceives all items as objects which have their
own behaviour. Although the data and behaviour may eventually be stored in separate
locations (in our case, in a Magik object library and an underlying database),
from the user’s point of view the objects are self contained items.

As a simple example, consider the following fragment from a GIS shown in Figure
3.

The object type BUILDING understands messages, which are relevant for all types
of building, such as foot print (square metres) and volume (cubic metres), which
are then automatically inherited by HOUSE and OFFICE.

House extends the behaviour of BUILDING with, for example, approximate gas consumption
according to the rules used by the gas board knowing the volume of the house and
the number of occupants.

[ Figure 3 not available ]

From the application programmer’s point of view, he can retrieve HOUSEs from the
database using queries on stored or calculated values.

Within a GIS context, for all these objects, spatial properties such as AREA may
be inherited from SPATIAL_BEHAVIOUR. BUILDING and its sub-classes could understand
and respond to messages like ADJACENT_TO, CONTAINED_IN, NEAR_TO, etc. Should a
user wish to enforce his own definition of say, NEAR_TO for a HOUSE he could do
so.

One step further is that geometry (one of the spatial attributes) is also treated
as an attribute of an object. That is the geometry of a HOUSE can be retrieved
or changed by using methods which operate on the object HOUSE, the fact that the
actual geometry may be stored in many separate tables in an underlying database
is irrelevant for the GIS applications programmer.

Conclusions

We have been engaged in developing a new kind of software architecture for building
and maintaining large, interactive, databased applications such as GIS. The main
issue that we have tried to address is the large costs involved in developing such
systems and particularly the costs of implementation and customisation. It is our
conclusion, that object-oriented programming technology is sufficiently well understood
and gives such astounding benefits that now is the time to apply it to real commercial
systems. We strongly advocate that such an environment itself should be interactive
and that access to all objects in the system should be available in the user interface,
and not hidden deep in the bowels of the system where only the vendor’s system
programmers have access.

We advocate implementing an object-oriented database capability by front ending
a version managed tabular datastore with an object-oriented language. Existing
databases should also be accommodated in the same way, as large amounts of data
are already committed to these databases.

We observe that GIS is particularly well suited to object-orientation, and so
the benefits of the approach are considerable.

References

Butler, R. (1988). The Use of Artificial Intelligence in GIS. Mapping Awareness
and Integrated Spatial Information Systems, Vol. 2, No. 3.

Easterfield, M. E., Newell, R. G. and Theriault, D. G. (1990). Version Management
in GIS Applications and Techniques. Conference Proceedings, EGIS, Amsterdam, April
1990.

Egenhofer, M. J., and Frank, A. U. (1989). Object-Oriented Modelling in GIS: Inheritance
and Propagation. Auto- Carto 9, Baltimore, April 1989.

Frank, A. U. (1988). Requirements for a Database Management System for a GIS.
PE & RS Vol. LIV, No. 11, November 1988.

Herring, J. R., Larsen, R. C. and Shivakumar, J. (1988). Extensions to the SQL
Query Language to Support Spatial Analysis in a Topological Database. Proceedings
of GIS/LIS ï88, Vol. 2, San Antonio, Nov 1988.

Newell, M. E. (1975), The Utilization of Procedure Models in Digital Image Synthesis.
Doctoral Dissertation, Dept. of Comp. Science, University of Utah, Summer 1975.

Newell, R. G., Theriault, D. G. and Easterfield, M. E. (1990). Temporal GIS Modelling
the Evolution of Spatial Data in Time. Conference Proceedings, GIS Design Models
and Functionality, Leicester, March 1990.

Oxborrow, E. and Kemp, Z. (1989). An Object-Oriented Approach to the Management
of Geographical Data. Conference Proceedings: Managing Geographical Information
Systems and Databases, Lancaster University, September 1989.

Worboys, M., Hearnshaw, H. and Maguire, D. (1989). The IFO Object-Oriented Data
Model. Conference Proceedings: Managing Geographical Information Systems and Databases,
Lancaster University, September 1989.