BALL has been designed to be easy to use, robust, open, and provide a broad functionality. It is as a tool for rapid software prototyping in molecular modeling and drug design. Its development started in 1996, initially as a tool box for protein-protein docking. It rapidly evolved into a large framework covering a broad range of applications. When designing BALL, we had four major design goals in mind. This document gives more details about these design goals.
Ease of use
Ease of use is crucial for the acceptance of a new tool, especially if this tool claims to be designed for Rapid Software Prototyping. First of all, the user should be able to use the software rather intuitively - as far as this is possible for a framework of this size. It should therefore employ a standardized and widely used programming language (we decided to use C++). Furthermore, it should provide an intuitive, well documented, and consistent interface. Here, consistency means that the user can generalize anything he learned to all parts of the framework. For example naming conventions should be globally applicable and functions with the same name should have the same or comparable effects.
Functionality is of obvious importance. We can only expect wide acceptance of our software, if it is able to save the potential user a major amount of time. Thus, it should provide most of the standard functionality and leave only the implementation of specialized or new techniques to the user. And even there the user should be able to take advantage of existing data structures to speed up the development.
Since we cannot provide all functionality and we also do not want to re-implement existing algorithms, it was also an important aim to provide a sufficient openness, meaning compatibility with other class libraries but also compatibility with the Standard Template Library. Furthermore, openness implies extendibility and modularity, i.e. it should be simple to add new functionality and data structures without changing the existing code.
The term robustness describes the code's ability to cope with unexpected or faulty data. A good example of such faulty data is the PDB file format. While PDB is the most common format for structural data of proteins and is well standardized, only very few files circulating among scientists adhere to this standard for historical as well as for practical reasons. Strange as it may seem, but the implementation of a robust code for reading these files is a very demanding task. Implementing a file reader accepting standard compliant files is simple enough, but is not sufficient as only very few files could be read. Reliable reading of non-compliant files requires quite some biochemical knowledge and non-trivial heuristics to extract as much of the data as possible.