The first design requirement for the GDMS project, was that it be licensed under the GNU General Public License. The reason for this is to allow access to the software by people who are not necessarily in a position to use proprietary software. The GDMS package is complex and relies on a number of external libraries for mathematical and graphical functionality. Similar proprietary libraries can be very expensive. Another issue influencing our design methodology was the the need to have a package which is as platform independent as possible. This contributed significantly to the choice of programming language. In using ANSI ISO compliant C++, the GDMS package is intended to run on most Unix based operating systems. It should also be noted that most modern windowing toolkits require C++. The choice of user interface toolkit also maximised the cross platform capabilities of the application. WxWindows was therefore chosen as it has been specifically built to be easily ported, and currently runs on the following platforms:- Microsoft Windows Unix (including BSD and SystemV)/GTK+ Unix (including BSD and SystemV)/Motif and X11 MacOS OS/2 The next important design decision involves the methodologies used to design implement the GDMS package. Given the complexity of the system, the Object Oriented approach was deemed the most suitable. Using OO, the package lends itself well to future enhancements, maintenance and extensibility. In fact, throughout the implementation process, changes in design were required to suit the requirements of the growing system. These changes, although not always trivial, were facilitate by the use of OO methodology. The following figure is a deployment diagram for the GDMS. Note that the Error handling has not been connected in the diagram in order to preserve clarity. With few exceptions, all of the GDMS modules use the error handling sub-system. There are a number of reasons for this. The first is our desire to ensure that maximum possible stability of this system. This can only be achieved through efficient and appropriate error handling. For example, errors that are not fatal to the application will not cause termination, instead provide feedback on the error, before returning to a stable state. In addition, most operations use the matrix class which often invokes dynamic memory allocation and it is vital to handle any errors that may arise as a result for stability reasons. Therefore, there needs to be constant tracking to ensure an error has not occurred.

eqimgdeployment.png

The next digram is that of the error handling sub-system described above. In addition, each error is logged to file in order to facilitate debugging.

eqimgerror_handling.png

The modular design of the GDMS increases the potential for future improvements to the application, such as facilitating the addition of new mathematical functionality. The OO design can be built on by employing techniques such as inheritance. This technique has already been incorporated into the windowing sub-system of the GDMS and could used again in similar situations, where broad definitions can be defined for functionality, then specific classes can be derived from these higher level modules.