Project Plan 4/21/99

Primary Goals

Two main features are vitally important. These are:

1. Efficient memory management. Currently the test cases are being stored in upwards of 200MB files. It is the client's wish that this be reduced so that larger test cases can be run, and so that the search space is not as large. Thus any significant reduction of size of storage (by at least some constant factor) is desired. Because of the sheer size of the data there may be limitations as to what platforms and what software are available to use.

2. No loss of information. There must be no loss of any information that is currently kept or planned to be used in the immediate future. Any information that is currently kept by the inefficient dictionary system must be able to be either directly accessed or calculated from our storage space.

Back to top

Secondary Goals

Other features that would be "nice" to have in the client's eyes:

1. Timestamping. Currently there is no way to make any temporal relationship tests. With very efficient memory management this becomes a feasible goal. This will however increase the size of the data immensely, it is predicted. Research into how much of an increase is required before implementation.

2. Invariant queries. It is not necessary, according to the client, to absolutely have the invariants as part of the query structure. It is only necessary to be able to get the major tuples out of the database. It would however be nice to be able to use the inherent abilities of the database to find relationships between sets of tuples, without having to resort to an outside system.

3. User interface. The client has expressed virtually no interest in a nice, easy user interface. However, most databases have some kind of nice user interface, as this makes debugging easier, it makes the client's life easier, and it incorporates abstraction and encapsulation of data better. Depending on the platform, a clean user interface can be very easy or very hard, and thus will be platform independent.

4. Platform. The client's main platform used are Sun systems. However, the client has expressed interest in other platforms, and does not mind what platform eventually gets used, so long as it is a platform that the program already runs on. It is currently the plan to use NT as our main platform. It may be nice to be able to make the program at least portable easily to other platforms.

Back to top

Finished Project overview

The Database project will consist of three modules, in it's current form. The first module translates the data that comes out of the dynamic invariant program and converts it to a form that our database can understand. The second module is the database itself; a separate instance of the database will be created for every run of the client's program. The final module will be the interface to the database. It will handle returning information from the database in the form that the client expects and possibly even return the information in the finished product, the invariants.

Back to top

Platform Specifications

For software, currently the group is leaning towards using MySQL as the DBMS, a free SQL server/database program. This program has several advantages. One is that it is extraordinarily portable. There are versions that run on NT, Linux, Solaris, *BSD, and others. This is a good thing, as our client uses a Sun as their primary platform, and it would be desired to have the database on the same platform as the program it is designed to run with.

MySQL is also a familiar interface. There is an API for all of the platforms mentioned above, it is primarily programmable in C/C++, and is not hard to understand. Thus, we can use any platform we choose for development, so long as that platform supports MySQL.

MySQL satisfies all our requirements for a database program save one - it cannot use arrays as data structures in the tables, that we've seen. However, it can create tables on the fly, it can store arbitrary-sized strings, can be accessed remotely easily, and has reasonably decent data storage size.

Finally, several people in the department have knowledge of MySQL, including the TA Ryan Satogata. Thus, we will be able to get support for the DBMS.

There are other requirements for software on the front end of the system. One module that must be constructed is the script that takes the text output of the invariant program and transforms it into something our database can understand. Currently a scripting language such as Perl or Python are the top runners. However, we have not discussed this fully.

Hardware specifications have not been made. This is because for the most part the hardware specifications would be dependent on the software, and we had not fully decided as to what software we would use.

The client expressed some interest in having the database reside locally on their Sun. However, the only current specifications that we have for this are that the hardware must support decent network connectivity and be accessible via the client's machine. We are leaning towards a Sun as the primary platform of choice; this is dependent on the client's wishes.

Back to top

Back to top