4. OODB features required by PLINTH
In this section, we will discuss the specific features of OODB systems
that are needed by PLINTH, and those that are not, in order to have a
basis on which to select a suitable candidate (see the Appendix). Not
all available systems calling themselves OODBs have all the features
described above, and some provide many more. Conversely, some of the
features are not actually essential for PLINTH, though they would all be
useful if available.
4.1 Essential features
4.1.1 Object-orientation
Of the `mandatory' object-oriented features listed in
section 2, only
complex objects, object identity, and computational
completeness (in the sense that an API is provided) are absolutely
essential for PLINTH, since these are the only features provided directly by
Pop11 in the current implementation, as we saw in section
3. Extensible class hierarchies with inheritance and
overriding can be simulated by the application using ordinary object
attributes to represent classes, and encapsulation can be provided by
procedural wrappers if required. The API provided by the OODB must use the C
language, as we shall explain.
Although an OODB should be computationally complete, this is not the
same as being resource complete, i.e. having full access to the
machine's input and output devices. The OODB may not therefore be able
to express a complete application. However, this is generally quite
acceptable, since a well-designed system should keep its user-interface
and data storage modules distinct, allowing interaction only through a
tightly specified interface (see section 5).
PLINTH's own graphical user interface (GUI) is very complex, and is
written in Pop11 using its X Toolkit libraries. This need not change
when CONNEKT is moved onto an OODB platform if a Pop11 API to the OODB
can be provided. No existing OODB provides a Pop11 API directly, but
Pop11's facility for externally loading C library functions can be used
to write one, since many OODBs provide a C/API (Pop11 does not,
unfortunately, provide a C++ interface, which is even more common in
OODBs).
Choosing a C/API makes sense for another reason. Although Pop11
provides an excellent environment for prototyping and development,
it does not run on a wide range of platforms, and it is expected
that PLINTH will be eventually have be ported to a more widely used
language. Since the X Toolkit is also written in C, this language
would seem to be a good candidate. Moreover, Pop11's C interface
means that small PLINTH modules can be converted into C
independently, so that we can gradually migrate the system over time
from Pop11 to C, rather than having to start from scratch.
4.1.2 Database
Of the database features listed all but the ad hoc query language
(whether textual or graphical) are necessary. As we have seen, PLINTH
will take care of user-interface issues itself, accessing the data
through the OODB's API, and providing display and manipulation
facilities using the same window-based graphical toolkit as it currently
uses.
4.1.3 General
PLINTH currently runs on Sun SPARCStations, and a suitable OODB
would have to do the same. However, in order to maximise the scope
for porting PLINTH to new platforms in future, the more machines and
operating systems the OODB runs on now, the better.
4.2 Non-essential but desirable features
4.2.1 Schema evolution
`Schema evolution' refers to the ability to modify the class hierarchy
for an existing database, and to update at run-time the classes of the
objects that have already been created. Many databases do not provide
such facilities; the class hierarchy is defined and fixed before the
database is first opened, and the class of each object when it is
created, and these may not change subsequently. In PLINTH, however, the
user is allowed to change the class hierarchy for a net (defined in an
NCM - see [2]) and the classes of individual nodes and links at any
time, provided that the changes do not lead to inconsistencies.
Therefore, for PLINTH to make use of an OODB's class system, schema
evolution must be supported.
4.2.2 Versioning mechanism
A versioning mechanism records the history of objects, or allows
different views of them. With such a mechanism, each object is a
list or set of instances representing consecutive or alternative
states of the object (note that applications can use ordinary
relations between objects to achieve much the same effect). PLINTH
does not at present support historical versions, but applications
may need to deal with several drafts of a document, stages in the
design rationale process, etc. On the other hand, PLINTH does
provide multiple views of nets, consisting of alternative sets of
attributes for net, node and link objects. A versioning mechanism
could therefore be useful.
4.2.3 Convenient and efficient text storage
The database should not limit the size of object attributes to the
extent that the ability to associate very long text fragments with
PLINTH nodes is affected. Maximum sizes of the order of several
megabytes are quite acceptable.
4.2.4 Low cost
There are a number of public domain OODBs around. For experimental
purposes at least, PLINTH should use one of these if at all
possible.
4.2.5 Widespread use
There are two reasons for selecting a popular OODB. Firstly, more
widely used it is, the better its quality is likely to be. Secondly,
we might want to make PLINTH data available to other applications,
for example statistical and data profiling tools. The more popular
the OODB is, the more application packages we are likely to find.
4.3 Summary
An OODB which can be used by PLINTH should possess the following features:
- Essential features
- Complex objects and object identity
- Persistance, efficient secondary storage management, concurrency and recovery
- C language API
- Runs on SPARCstations
- Desirable features
- Extensible class hierarchies with overriding, overloading and late binding
- Schema evolution
- Encapsulation
- Versioning
- Low cost
- Widespread use
- Runs on a wide range of platforms
Re-engineering PLINTH to accommodate OODBs...