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