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.