Another problem with design databases is that of long transactions in a multi-user environment. Whilst a design process almost always involves several designers whose activities are closely intertwined, they should not be allowed to change each other's designs in an uncontrolled manner. On the other hand, extensive use of locking in the design data would lead to overheads, deadlocks, a lack of visibility of necessary data, or prevent some designers from doing useful work until others have completed theirs.
actively search for and test existing database systems to see how they would support CASE data management,
develop and test simple strategies for version control in design data (both over time and for different configurations),
develop and implement simple and user-oriented strategies for maintaining design data integrity, i.e. transaction protocols,
develop and implement an interface for design front-end tools so that they can store data in the database and retrieve it from the database using a more powerful high-level protocol.
First, an extensive survey of available object-oriented and network databases was carried out (Rissanen and Rossi 1992) based on which a database management system was chosen for test use. However, as the implementation environment of the project needed to be changed from Actor to Smalltalk, the issue had to be reassessed. This led to another study in which the choice was narrowed down to two possibilities, GemStone, an object-oriented database with an interface to Smalltalk, and ArtBASE, an object store that extends Smalltalk by the ability to make objects persistent (i.e. stored in the repository) and perform locking etc. actions on them. In the end, considerations of the possibilities for use in further research outweighed the other factors, and GemStone was rejected on the grounds that it always required a Unix machine as a server, whereas ArtBASE could run both server and client within a single PC. ArtBASE was also significantly less expensive, and promised more flexibility and a tighter, more dynamic link between the classes contained in memory and the database `schema': a vital factor for incremental method engineering.
ArtBASE has now been tested on both single and multi-user versions, although there has been no testing with many users accessing the same data simultaneously, as the locking strategy for tools is yet to be implemented. The operations on the conceptual GOPRR data now automatically produce the correct database actions, and changes of metamodels have been successfully tested. Such success is remarkable: previous relational, network, and object-oriented databases would have been unable to cope with such interference with the schema while the database was running.
A user-centred transaction protocol has been designed. This enables the program to infer from user actions which data should be locked, thus maintaining consistency and ensuring the possibility of transaction commit without transferring to the user the burden of explicitly declaring locks as his transaction proceeds. In the implementation it is intended to allow such explicit locking, although normal users should not need to use it.
Second, the master's project on version management problems has generated useful discussion and provided a possible design of a versioning system (Pyykkö, 1994). The implementation of this is currently postponed.
Third, a partial implementation of a high-level protocol for data exchange in the current MetaEdit environment was done by another master's project (Jukola and Väätäinen 1992). An alternative solution was also drafted, but not realised because of portability issues.
It is however hoped that the tools can call generic locking routines in the MetaEngine, rather than explicitly executing say a read lock. Thus it will be possible to control the locking strategy centrally, even if not to trigger it based only on actions on conceptual design elements. With the basic locking calls implemented, an analysis will be made of the efficiency of various locking strategies within a metaCASE environment.