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...