ria 
h other 
1g with 
chwise 
asking, 
system 
atform 
)y nOW 
to the 
rtise all 
ear per 
or there 
imputer 
TRAN: 
ifferent 
cal user 
tabases 
e. The 
ide any 
rtantly, 
and the 
These 
nguage 
iented 
ularity, 
of the 
xndable 
tion to 
rained, 
erating 
1d with 
igence, 
riented 
<, even 
wever, 
ructure 
jaining 
' ones, 
ses to 
rithms) 
ssages 
lled by 
ygrams 
ymmon 
ms, on 
+ type 
grated 
s. This 
r most 
ith the 
terms 
> name 
> then, 
riented 
one. Object-oriented on the surface, it is capable of 
integrating modules belonging to both the procedural 
and the object oriented world. 
Implementing Autonomous Classes 
An autonomous class is, in the most general terms, a 
complex object incorporating (and encapsulating) data, 
instructions, and hardware. Full implementation of such 
classes is possible in distributed processing (network; 
specialized hardware on PC boards). But member 
programs integrated into a system and running in 
parallel in a multitasking environment represent the 
most typical, though not full, implementation of 
autonomous classes. 
The main programming languages to be used are C+ + 
and FORTRAN. Within one autonomous class, mixing 
them is to be avoided as far as possible (for reasons of 
portability). The choice of the language depends on: 
- the class being machine bound (preference for C+ +), 
- the class performing mainly numerics (mild preference 
for FORTRAN), 
- the availability of re-usable routines (usually 
FORTRAN), 
- the experience of the programmer (in most cases 
FORTRAN). 
An autonomous class is invoked by the user, or by other 
classes. It may command over any number of 
autonomous sub-classes thus building a family of 
autonomous classes. To enable the invocation of an 
autonomous class in different environments, different 
heading statements have to be provided by conditional 
compilation ("ifdef"-s). In FORTRAN, a PROGRAM 
statement enables SPAWN-type invocation in a 
multitasking environment. An alternative SUBROUTINE 
statement allows to build large linked systems, e.g., on 
mainframes, or the invocation of classes stored in 
dynamic link libraries (DLLs). In C+ +, similar 
techniques are possible in using corresponding CLASS 
statements and names. In the future, special headers for 
Object Request Brokers (ORBs) may become necessary, 
so to enable invocation by some Distributed Object 
Management technology. 
Communication among classes is via messages 
(strings). These are reminiscent of simplified directives 
of a command language. Simplicity is partly due to 
polymorphism: the object knows how to react to the 
same message in different cases, it itself knows best 
the stage and ways of processing, etc. - In the case of 
the autonomous class for topological database 
management (TOPDB), messages acquire the syntax of 
TOPSQL (Loitsch, Molnar, 1991). Autonomous classes 
should be able to handle simultaneous requests (I/O 
queues, buffering, priority handling, managing 
asynchronous communication with other classes, record 
locking, periodic checking of external requests to pause 
or abort, etc.). Multithreaded operating systems (0S/2) 
provide fine means to keep an autonomous class alert to 
messages while working on a task. Data communication 
should proceed either via the database management 
class (TOPDB), or via binary files, memory pipes, shared 
memory, and similar means. Synchronization via 
semaphores, flags, etc. becomes very important - e.g. if 
one class is processing a patch (tile) of data, and the 
database class is simultaneously retrieving data for the 
next patch. 
The developer should clearly differentiate between 
classes 
- mainly machine bound, and 
- practically machine independent, 
963 
and furthermore, concerning invocation: 
- public classes, to be invoked 
- by the user, 
- by (other classes of) the system, and 
- private ones, being subclasses to some other class. 
For a system integrating autonomous classes, "lazy" 
processing is characteristic: without user requests, there 
happens nothing, and in answering requests, there 
happens the minimum necessary. This principle of 
laziness is a sometimes shortsighted but generally 
advantageous principle of economy. 
APPLYING THE CLASS-ORIENTED ARCHITECTURE 
TO BUILD A DTM SYSTEM 
Instead of an Introduction: 
DTMX, and Hints on an Object-Oriented View of DTMs 
DTMX was to be a modular system of software tools 
operating on a (transitory) database, designed to provide 
a highly flexible interface between DTMs of different 
structure and origin (Molnar, 1984). It never 
materialized as a whole but its definitions of a 
sequential data exchange format became widely used in 
Austria (data in this format cover many times the 
territory of the country). 
The database of DTMX was to contain patches of data 
with a code characterizing the level of processing 
achieved on them ("lazy" processing). Examples of such 
levels are 'raw data', 'data edited', 'DTM grid', 'contour 
lines interpolated', etc. Modules have been foreseen to 
perform the upward transition from one level of 
processing to the next. With some system on the input 
side yielding data of one level (e.g. raw data), and the 
system on the output side requesting another level (e.g. 
contour lines), DTMX was thought to perform this 
transition automatically by piping internally the 
corresponding tools. 
So, the design of DTMX did have the potential to result 
in a fully-fledged DTM-ing system. Looking at it in an 
object-oriented way, a DTM is a complex object 
encapsulating both data and processing code, uniting 
information with intelligence. DTMX corresponds to this 
definition. - It is the origin of some major principles to 
follow here. 
Classifying Autonomous Classes of the DTM 
According to their role, the autonomous classes of the 
DTM can be classified as 
- FRAME (or Management) classes such as 
Management of User Interactions (including on-line 
context-sensitive help), Database Management, 
Project Management including Error and Message 
History, Graphics Management, and others; 
- KERNEL (or Application) classes such as Input 
Data, DTM Surfaces, Graphic Sheets, 
Isolines/Zones/Distributions, Views, the products 
of DTM-Algebra, of DTM Classification, of DTM 
Exploration - and numerous other classes. 
In thinking of an autonomous class (e.g. in planning 
one), the main consideration should be given to its 
instances (i.e. to its data records); the methods 
(algorithms) operating on them should be considered as 
means. This corresponds to the aspects of the user, and 
to an object-oriented analysis and modeling of the task. 
In this sense, notes on some of the classes of the DTM 
follow.