Target Audience:

People connected with bioinformatics and molecular modelling come from a wide range of disciplines. Some are purely users of scientific software, such as experimental molecular biologists and medicinal chemists. Others, such as those working for software companies, only develop it. Many academics both develop and use scientific software. We hope that all three of these groups of people will, directly or indirectly, use of class library.

Some applications will be developed early on to demonstrate the use of the library, but on the whole it will be a while before the experimentalist will have access to many packages written using the library. Professional software engineers may wait for the library to be fully developed and stable before concidering whether to make use of it.

We envisage that the last group of people within our target audience will be the first to benefit from a class library of this kind. Academics will be able to take the classes as they appear in the library and extend them to suite their own needs. These class extentions, once tested, could then be fed back into the library for general usage.

Assumptions Concerning Hardware:

The rapid increase in the speed and size of memory of personal computers will probably continue over the coming few years. However, experience shows that people tend to use push what ever resourses they are provided with (including their salary) to their limit. Therefore, the efficiency of computer programs will still be important to scientists in the future.

On the other hand client-server architecture will probably play an important role in the near future. The users, rather than the developers, of applications need not have a powerful machine on their desk. They can simply use their computer to submit jobs on remote machines which send the results back to them. Advances in Web-browser technology have greatly simplified such communications and allow a very user-friendly interface for the scientist to interact with. Forms, in tandem with CGI scripts are already commonly used for providing services such as this, and the Java Internet programming language looks like it will revolutionize Internet client-server usage.

Choice of Programming Language:

There are a number of OOP languages available, the most commonly used ones are C++, Java, Smalltalk, Delphi and Eiffel. Two of these, C++ and Java, are by far the most commonly used in biocomputing.

Because of its provenance, C++ has significant non object- oriented content. Java, however, is an almost pure OO language. With this language, small applications (applets) can be written that can be downloaded via the Internet and executed within an Internet browser. This provides the means whereby applications written in Java can be made extremely accessible and user friendly. However, no international standard exist for Java and execution speed was not a high priority in its design. Standards are important if packages written in a language are to be portable across many platforms. Execution speed is important in biocomputing where long, central processing unit (CPU) intensive computing jobs are common.

We decided that the best language to use is C++ as it is still probably the most widely used OOP language amongst scientists. C++ is an extension of C, which is a language a large number of scientific programmers currently use. It is easy to learn C++, given a knowledge of C. Also, one can write extremely efficient code in C/C++. Perhaps the most important reason for choosing C++ is that a ISO/ANSI draft standard for this language was released in April last year. This should enable us to produce code that can be understood by any C++ compiler, so it can be used on practically any hardware platform.

However, we do intend to publish the design of our library in the form of language independent class diagrams. This will make it easy for a version of our library to be written in Java or some other language, should the need arise.

Graphic User Interface (GUI):

In our original grant proposal we stated that we intended to use Tcl/Tk for our GUI. Since this proposal was written, significant developments in web-browser technology have occurred. Specifically Java has exploded onto the scene. Since Java is an OO language it would seem a better choice for us than Tcl/Tk which procedural in structure. Until recently, Java also had the great advantage that programs written in it could be downloaded and run within modern web browser without the need for the use to install any special software. However, Tcl/Tk can now also be run within the same type browser. This feat can be achieved if the user has an easily installed browser plug-in . Sun (who provide both Java and Tcl/Tk) say this "We believe that where computational efficiency really matters, you want to use Java (e.g. doing joins on databases) but when you just want to display something quickly, Tk is better." ^ref. It may be that a combination of Java and Tcl/Tk (see the web-page on the subject by John Ousterhout) will be turn out best solution to our needs.

It is clear that new and better GUI solutions are constantly being developed. It is hoped that, with the arrival of the draft standard, the C++ language will remain more or less stable. Thus, this library should be designed to be interface independant.

Use of existing software:

Many of the algorithms used within the library will come from existing programs. The first programs to be incorporated will be those developed at UCL and Birkbeck. Programs, such as Procheck have proven worth and are well tested. The original source code for these programs will either be automatically translated into C or wrapper classes will be employed to enable them to be incorporated into C++ code. The input-output functions of the programs will have to be changed but we will leave the body of the original code unchanged.

Any questions and bug reports to Mark Williams. This page was last updated on the 25th of May 1999.