FRAME (MANAGEMENT) CLASSES 
Management of User Interactions 
There is, indeed, only a limited number of different 
actions a user needs to perform. He needs to identify 
some options (words) or some position (x,y), to end 
pausing states (e.g. by typing a carriage return), or to 
enter some strings or numbers as values. From this 
point of view, it is easy to construct an interface 
transferring information from the user interface to the 
autonomous classes. 
The problem is the other, the prompting side. Early 
single-line promptings developed to graphical user 
interfaces (GUIs) presenting the user with a wealth of 
details such as windows with drop down menues, scroll 
bars, dialogue boxes, radio buttons, etc. /BM's Systems 
Application Architecture (SAA) specifications created a 
widely accepted standard (OS/2 Presentation Manager, 
MS Windows, X-Window, DEC-Window, and many 
others). Recently, there are cross-platform tools 
commercially available providing a single interface to all 
these systems, and realizing an acceptable compromise 
of the common denominator to them. 
Development, or sometimes fashion, do not stand still, 
however. With regard to Smalltalk and Macintosh type 
user interfaces, the SAA standard appears to be 
antiquated. And | do not doubt that further stages are 
following in a rapid sequence, considering, e.g., the 
exploding importance of multimedia technology. 
It is, therefore, imperative to separate the GUI from the 
classes to be controlled by it. There is an interface 
necessary, somewhat similar to the resource file 
statements as originally formulated by IBM for the PM. 
Interpreting such statements, the autonomous class 
"Management of User Interactions' can compose the 
graphical user interface to appear on the screen in using 
the latest cross-platform development tools and 
libraries. This way, the user interface can be kept to 
correspond, though with severe compromize, to the 
fashion of the time. 
The class 'Management of User Interactions' is to 
support the user interface: where possible, a GUI, and 
everywhere, a command language interface - as a 
choice, and as a necessity for batch processing. Via this 
interface, the user can invoke the major classes, and 
keep more than one of them active at a time. This class 
is overwhelmingly machine bound for it has much to do 
with the GUI, with foreign libraries, with graphics and 
device drivers, and, in invoking other autonomous 
classes, with operating system calls. Therefore, it has to 
be implemented in C+ +. It is the tip of the iceberg - it 
is the ROOT or MAIN class of the DTM system. 
Database Management 
Database management plays a central and multiple role 
in this system's architecture: it is managing data for all 
the different classes. Besides of dealing with sets of 
original (input) data including digital images and overlays 
of the DTM surface, it should carry tables and matrices 
with overviews of previous and current stages and 
peculiarities of the processing, of data changes within 
individual patches (tiles) with date and time, objects of 
graphics output, matrices and tables of error and 
message history, 3-D enclaves, and much more. The 
class 'Database Management' is not directly accessible 
by the user; such access is only granted via other 
classes. These last ones are considered to /ogically 
encapsulate the data managed by them. 
There is every reason to go on with the SCOP 
964 
philosophy to reflect various aspects of terrain 
characteristics by building multiple models of the same 
area rather than having more than one function value at 
each location of a single model. This allows to have 
independent structures and densities of the models 
covering the same area, e.g. those reflecting elevations 
belonging to different epochs, or soil quality, or indeed 
any characteristics capable of sorting on an ascending 
scale. 
For this purpose, in the system as proposed, database 
management should handle multiple overlapping terrain 
models structured independently of each other (this is 
solved in SCOP's current DTMLIB routines already). 
These can serve then either as overlays, or as operands 
in expressions of DTM Algebra resulting in operations 
identical or similar to those provided in the current 
SCOP.INTERSECT module. 
Most probably, the class 'Database Management' is to 
comprise more than one sub-class to fit different 
purposes. TOPDB and DTMLIB to be described next will 
be integrated as such sub-classes. A further sub-class 
to manage graphic objects may become necessary. 
TOPDB (Loitsch, Molnar, 1991) is a fully re/ational 
database management system capable of dealing with 
data, attributes, and arrays of these (including pixel 
arrays). TOPDB is specifically designed to be efficient in 
performing spatial and topological queries according to 
2-D criteria on large amounts of data distributed in a 
"two and a half" dimensional space. It is treating 
topology in terms of relationality. It is controlled by 
TOPSQL, a major subset of the Structured Query 
Language (SOL) extended by topological operators. 
TOPDB tables can be created and discarded on the fly, 
at run time. TOPDB has hardly any limitations 
concerning the amount of data to be treated. The major 
sources of its efficiency are multiple continuously 
balanced binary trees, and extensive buffering. - Further 
development is necessary concerning TOPDB's 
capabilities to function as a server in a multitasking 
and/or networked environment. - TOPDB has been 
developed in FORTRAN by using the totally incredible 
compiler and workbench created by A. Koestli of the 
SCOP team in Stuttgart (Koestli, 1990). 
DTMLIB is a main library of the current edition of SCOP. 
It contains the database management system for the 
random access DTM. It is designed to access multiple 
individually structured DTMs concurrently. It contains 
routines available to user-written programs (FORTRAN). 
DTMLIB should be further developed to deal with 
irregular patches of the surface rather than just with 
regular computing units. It should be extended to work 
in concert with TOPDB, especially with regard to vector 
type data such as break lines, borderlines, highs and 
lows, etc., to be managed in the new system by TOPDB 
only. 
Project Management 
This class is supervising the entire project. It is to 
manage records of data security, of archiving (saving), 
of limiting polygons, matrices of coverage, etc. The 
Error and Message Management belongs here, as well, 
both to send and to administer these messages, and to 
build up a history of them, for analysis, and for 
summaries. - Most records are stored on TOPDB tables. 
Graphics Management 
Graphics Management is to receive data via interprocess 
data communication (memory pipes, shared memory 
areas, binary files). These data are to be displayed, 
-— P^ ma | woe ehe 
- my emg IL 
Q >> > rTomáAo— LL - 4.9 0 0 NN A YSN en 
€) Cr OO (f OCHO FFT 0) od lad 
— = 
— nd 
-