System Software
|
Home General Staff Contact Partners Alumni Research Areas Projects Papers Books Reports Awards Teaching Lectures Exams B.Theses M.Theses PhD Theses Go Abroad Misc Talks Library Gallery Links Search Webmaster |
Oberon-DOn Adding Database Functionality to an Object-Oriented Development Environment Mag.Dipl.-Ing. Markus Knasmüller While object-orientation has become a standard technique in modern software engineering, most object-oriented systems lack persistence of objects. This is rather surprising because many objects (e.g. objects in a graphical editor) have a persistent character. Nevertheless, most systems require the programmer to implement, load and store operations for the objects. In this Ph.D. work we demonstrate the seamless integration of database functionality into an object-oriented development environment, in which, the survival of objects is for free.Persistence is obtained by a persistent heap on the disk. Persistent objects are on this heap, while transient objects are in the transient memory. Transient and persistent objects can access each other mutually. Accessing a persistent object leads to loading the object into the transient heap. It it is not accessed from transient objects any more, it will be written back to the persistent heap. A transient object becomes persistent as soon as it can be reached from a persistent root. Every object may become a persistent root if it is registered with the function Persisten.SetRoot (obj, key), where obj is (a pointer to) an object and key is a user-defined unique alpha-numerical key. If not defined otherwise, all objects directly or indirectly referenced by a persistent root are automatically persistent as well. Persistent objects which are not referenced by other persistent objects are reclaimed by a Stop & Copy garbage collector. This algorithm uses two heaps (files) and copies all accesible objects from the full heap fromHeap to the empty heap toHeap. The idea of this work is to offer the impression of an indefinitely large dynamic store on which all objects live. The programmer does not have to distinguish between "internal" and "external" objects. All objects can be referenced and sent messages as if they were in main memory. The underlying language does not have to be extended. Other database features, such as schema evolution or recovery are embedded in this persistent environment. Scheme evolution, for example, is done during the persistent garbage collection run. In this phase it is checked, if the type definition of any object has been modified since the last garbage collection run. If this is the case the object is read from the fromHeap by using the old type definition and is written to the toHeap by using the new type definition. Furthermore, an Oberon binding for ODL/OQL is implemented as part of this work. ODL is a specification language for defining interfaces to object types that conform to the Object Model of the Object Database Management Group. OQL is an object query language supporting this model. A proof-of-concept implementation, named Oberon-D, has been done in the Oberon system, which offers powerful mechanisms for extending software in an object-oriented way. However, any other object-oriented operating system, which offers garbage collection and exception handling, could be used instead of Oberon. The work includes some novel aspects, e.g., the implementation of user-defined mappers, the integration of garbage collection and schema evolution and the translation of OQL code into Oberon code. Betreuer: Prof. Dr. H. Mössenböck |