next up previous contents
Next: 7.3.1 Dynamical Instantiation Up: 7. Implementation of SIESTA Previous: 7.2.3.0.6 Menus.

7.3 Persistent Storage of Objects

The desire for an intelligent and user friendly TCAD environment is raising a strong demand for as much programming support as possible. A service which implements the persistent storage of data is one of the features which relieves the designer of a simulation application from saving and restoring application data.

Persistence means that the lifetime of objects is beyond the lifetime of the applications that are using them. Since a user typically deals with basically the same or similar problems during subsequent usage of an application, the objects which are modeling these problems should survive an intermediate termination of the application.

The Persistence Module was specifically created to meet this demand. It was inspired by concepts also available in CORBA [52]. Arbitrary objects are registered, or in some sense requested, from the Persistent Storage Manager of the Persistence Module, by using a unique path of names to identify them, and a default initialization pattern, in case it was requested the first time. Once this registration has been performed, the object is automatically stored to disk before the application terminates, and it is restored when it is requested again. Each user of SIESTA owns a separate database of persistent objects.

Using this name service, multiple modules can access the same object without knowing anything about each other. This is necessary to decouple modules from each other. Given that two modules need to share some data, one of them, which can be considered the server, instantiates the object and registers it with the Persistent Storage Manager, and the other one simply asks for that object. Thereby, the latter module does not even need to know where the object came from. Thus, the name service contributes to a strict de-coupling of SIESTA's modules.




next up previous contents
Next: 7.3.1 Dynamical Instantiation Up: 7. Implementation of SIESTA Previous: 7.2.3.0.6 Menus.
Rudi Strasser
1999-05-27