Modern user interfaces employ object-oriented concepts.
The “point & click” paradigm of today’s graphical user
interfaces is basically object-oriented in nature —
corresponding directly to the object & message concept.
Metaphorical objects (such as windows, icons, menus,
buttons, pointers and dialogue boxes) are given a physical
presence on a screen. Users can send messages to the
objects by moving a pointing device and clicking buttons,
and this is how users communicate with the computer.
Generalisation/Specialisation can be found among interface
objects. There are many different kinds of window, for
example, but many have common features. Most have a
‘close’ button, for example, and many have scroll-bars. A
window class hierarchy can be formed with the most general
kind at the top, and application specific ones at the bottom (a
text editor window being one example).
2.5 A Final Remark on Object-Orientation
The view of object-orientation presented here is perhaps
more general than those presented elsewhere. Many views
are restricted only to the application of object-orientation to
software construction. There can be little argument about the
impact of the approach on this field. In fact, the concepts
behind object-orientation largely grew out of developments
in programming languages. The concepts have, however,
found application in other fields, and this is why object-
orientation has been presented here simply as a way of
looking at systems.
3. FRAMEWORK DESIGN
The framework which has been developed is for building
and storing models of the real world. Ideally, the user’s
view of a model system should correspond as closely as
possible to the view of the real world system it represents.
This should make manipulation and analysis of the model as
intuitive as possible. The things that users perceive as being
important in the real world, therefore, should be easily
perceived in the model. This means that users should be
able to view the model as being formed of components
which directly correspond the things we are interested in.
In GIS, the interest is in storing information about entities
(such as roads or rivers) — including their lócations and
spatial distributions. The relationships between these entities
also tend to be of some importance, and therefore need to be
modelled. Modelling the spatial variation of phenomena
such as temperature or population is another important
capability. A framework for storing geographic information
should therefore allow models to be built from components
which explicitly represent these items of interest.
The framework which has been developed may be described
as the core of a fledgling database management system.
Using database terminology, the framework is based on the
Entity/Relationship (ER) Data Model. It allows entity types,
relationship types and attribute value types to be defined.
These types are then used to create actual entities,
relationships and attribute values. These can in turn be
put together to build a model. Note that the concept of
classification is involved in the relationship between entities,
for example, and entity types.
Each entity in a model represents the existence of something
of interest, such as a river ora forest. Entities can be
associated with one another by relationships. A
flows into relationship might associate a river entity
with a lake entity. Both entities and relationships may
756
have attributes which describe them in some way by linking
to an attribute value. À river entity might have three
attributes — name, position and length. An attribute
must have a declared type which states what kind of value
can be attached to it. The attribute name, for example, may
have the type string declared for it.
The generalisation/specialisation of entities is added to the
basic concepts supplied by the ER Data Model. This is
acheived by allowing a hierarchy of entity types to be
defined, rooted at the most general type, entity. A more
specialised type may first be defined, called water-body.
This might specify the attributes name, position and
permanance. Á river type may then be defined as a
descendant of water-body, so it would have all the
attributes of that type. In addition, however, it may have the
attribute length. A lake type may also be defined as a
descendan of water-body, and have the attribute area
added.
À hierarchy of entities is useful in several respects. It can be
useful in the selection of features for further investigation.
Rather than having to say “select all rivers and lakes”, for
example, the more concise “select all water-bodies”
would suffice. Relationships can be used more effectively
too. À river, for example, may flow into a Lake or
another river. By making the flows into relationship
associate a river entity with any water-body entity
(rather than being more specific and allowing it only to relate
a river to a lake), the real world situation can be
modelled more flexibly.
A similar hierarchy of relationships can be defined, rooted at
the most general type, relationship.
In many database management systems, the capabilities for
handling different types of attribute value are rather limited.
A few basic types are allowed, such as integer, character,
string and real. The support for handling more complex
types is often restricted to the ability to group together two or
more attribute values, each of basic types. For example, a
real and a string taken together may represent a distance (a
magnitude and a unit). This framework is more flexible, in
that new types can be designed and ‘plugged in’, allowing
different kinds of attribute value to be stored. A distance
type may be designed, a value of which would include a
magnitude and a unit. Functionality would also be
incorporated, however. Some operations may be for setting
the initial distance, converting the distance from one unit to
another, or for adding two distances, regardless of whether
they are have the same units or not. An addition operation
would obviously have to include a conversion process if the
units were different.
The ability to put storage capabilities and functionality
together in a type like this is obviously the same idea as the
concept of encapsulation which was mentioned earlier. In
fact, attribute value types are not the only ones which can
have operations specified for them. Entity types and
relationship types can too. Some basic functionality is
included in the definitions for the general types entity and
relationship — the functionality to allow an entity to
have an attribute value attached to it, for example, or for an
entity to enter into a relationship with another. Further
operations can be added for more specialised entities and
relationships, but more will be said about this later.
The concept of generalisation/specialisation can also be
applied to attribute values and this would appear to hold