1e real 
As a 
scribes 
closer 
ides a 
ework 
sed in 
r user 
eople 
1, the 
1 their 
icepts 
of the 
in one 
ion of 
ntity 
ctural 
"our 
n do). 
must 
ations 
> state 
| state 
ystem 
world 
with. 
tware 
ortant 
vorld, 
bject- 
icons 
puter 
it the 
Or a 
inter- 
| and 
ject- 
s of 
these 
ich is 
more 
is the 
f the 
efine 
stem, 
y the 
ssage 
what 
stems 
g the 
an be 
identified. The implementation system is the programme 
itself — a collection of software components which define 
how the GIS works. The environment system is what the 
user sees when the GIS is running, and is defined by the 
user interface. The model system is the representation of the 
real world with which the user interacts — through the 
environment system. Any of these systems can be looked at 
through a pair of object-oriented glasses (0-0) — as a 
collection of objects. 
2.2 Implementation System — O-O Programming 
The implementation system (the ‘programme’) may be built 
using an object-oriented programming language, 
such as Smalltalk or Eiffel. Object-oriented programmers 
develop their software by defining classes. At run-time, the 
software system consists of a collection of interconnected 
objects, generated from the class definitions. 
The state of a software object is the data it stores, and takes 
the form of a collection of attributes. These may consist of 
links to other objects, or direct internal representations (as 
with an integer object, for example). The behaviour of an 
object is the set of operations (often called methods) 
defined for it by its class. These methods are defined by 
routines written by the programmer, and are the only means 
of manipulating the data stored in the object. The operations 
which may be defined by a class for linked list objects, for 
example, may include append, insert and delete, for adding 
and removing items to and from a list. From this 
description, it can be seen why objects are said to 
encapsulate data storage capabilities along with the 
functionality to manipulate the data. 
The execution of an object-oriented software system occurs 
through message passing. When a message is received 
by an object, it matches it with one of its methods or 
attributes. An attribute would then return a value, while a 
method would start executing. Methods can include 
messages to other objects, and execution spreads through the 
System as messages are passed from one object to the next. 
When a method finishes executing, control is returned to the 
object that sent the message. 
In addition to providing the concept of encapsulation, most 
object-oriented programming languages also support 
information hiding. This allows an interface to be 
specified for a class. An interface defines exactly what form 
messages sent to objects of that class should take. All access 
to the state and behaviour of an object must be made through 
its interface. As a result, the interface can control what 
attributes and methods are actually available to other objects. 
The interface is separate from the implementation of state 
and behaviour. It defines what messages an object will 
respond to, the form those messages must take, and what 
results will be yielded. It mentions nothing about how the 
results are obtained — that is left to the implementation. 
Information hiding, then, means that one object can in no 
way be dependant on how another acheives results. 
Object-oriented programming languages incorporate a 
mechanism known as inheritance which facilitates 
specialisation and generalisation. One class can be made to 
inherit the state and behaviour of another, without having to 
define them itself. The subclass can then modify inherited 
attributes and methods, and add new ones of its own. Most 
inheritance mechanisms do not support specialisation and 
generalisation, because they do not enforce any constraints 
on the interfaces of classes. A subclass may inherit from a 
superclass, but it need not appear anything like it through its 
interface. The messages that it responds to may be entirely 
different, meaning that it can’t be treated in the same way. 
755 
In some situations, it is important for the interface to be 
inherited rather than (or as well as) the implementation. 
Some programming languages address this problem, while 
others do not. The difference between inheritance and 
generalisation/specialisation leads to some conflict between 
the ideas behind object-oriented programming and object- 
oriented modelling. 
2.3 Model System — O-O Modelling 
A GIS allows a model of a real world system to be stored 
and analysed. The model represents the real world by 
storing information about it. The structure of the model 
system dictates how users interact with it to retrieve 
information or perform analyses. 
A wide variety of schemes exists for structuring information 
about the real world. Structures based on line graphs are 
commonly used for representing positional information, 
while for textual information, table or record structures are 
common. Knowing the organisation of the tables and/or 
graphs, a user can retrieve the information required, and use 
that to perform analyses. Interacting with a model structured 
in this way is not particularly intuitive for a human — a 
translation must be made between the human conception of 
the real world system and the table/graph structured 
conception of the model system. The problem here, for the 
users, is that too much emphasis is given to the storage of 
information about things, and not enough to representing the 
things themselves. 
To be more useful to users, model systems and the real 
world systems they represent should correspond more 
directly. Acheiving this has been referred to as "closing the 
semantic gap", and object-oriented modelling of the real 
world is one way of making this possible. Taking such an 
approach allows users to conceive of the model system in 
terms of objects, each with a defined state and behaviour. 
Some of these objects may correspond directly to things of 
interest in the real world, while others may be dedicated to 
storing certain kinds of information. 
Object-oriented models allow a kind of information hiding. 
Although object structures for storing information (such as 
line graphs and tables) may still be used, they can be hidden 
from users to a certain degree. If users can interact with the 
model through the objects directly representing things in the 
real world, and if such interaction can be performed using 
real world terminology, then the underlying representations 
and processes can be largely concealed — and users can 
obtain results without knowing too much about the 
underlying structures. 
An object-oriented model of a real world system need not 
necessarily be implemented using an object-oriented 
programming language — as long as the required concepts 
are visible to users. This overloading of the term ‘object- 
oriented’ tends to cause some confusion. Programmers 
often think of it as being ‘their’ term, and that other people 
should therefore refrain from using it. Its use in such a 
manner can be justified, however, if we think of object- 
orientation as supplying some basic concepts. We can then 
apply those concepts to different systems — programmes, 
models and environments. 
2.4 Environment System — O-O User Interfaces 
Computers create and present us with an environment within 
which to work. In a GIS, we find a model of a real world 
system located within this environment. The way we 
interact with the model system is dictated by the nature of the 
environment and the way users can interact with it.