Laserfiche WebLink
or no debugging) by setting a global variable initialized in the "debug.h" include file. The third <br />routine is called to print a debug message. The first argument is the debug level for the message (it <br />must be less than or equal to the global debug level for the message to be printed; the second <br />argument is the routine where the message is being printed; the third argument is the message to be <br />printed. Programs developed by RTi generally allow a debug command line argument such as "- <br />debug #" so that the debug level can be set at runtime by developers and users. This feature is very <br />useful for allowing users to determine problems at their sites and report them to developers. Note <br />that although these routines use global variables, the scope of the variables is confined to the three <br />simple routines and is never directly accessed by other routines. Note also that this type of <br />debugging may only be implemented in new code because changes to existing code may require <br />extensive coding. The debug messages could be printed to the screen or could be displayed in an <br />area of a GUI devoted to debug messages. This issue will be studied further in Phase II. <br />All code should be tested first by the developer, at which time the code will be fully documented. <br />Template test programs will be developed to test individual routines where possible. For example, <br />routines that read from the database will be tested using a template program that queries the database <br />and then prints the information that is retrieved. The documented code and the results of the test will <br />then be reviewed by a knowledgeable RTi staff person to verify the accuracy of the documentation <br />and the results of the code. Additional review by State personnel can be made, if requested. Finally, <br />the full application will be tested on the prototype machine at RTi. Once validated, the prototype on <br />the RTi machine will be copied to the Briefing Room machine at the State (see Task Memorandum <br />1.05-22). Users will then be able to run the prototype and report bugs back to the RTi team through <br />mechanisms set in place by the user involvement program. <br />3.0 CONCLUSIONS AND RECOMMENDATIONS <br />Debugging is an effort that must encompass all levels of development, from design, to coding, to <br />operation. Developers and users must be willing to take the time to address program flaws because <br />such flaws inevitably cause bigger problems later (e.g., by being a "broken link" in a process, by <br />forcing alternate procedures to be used, and by giving a bad impression to users). The following <br />recommendations are made regarding code and system debugging in the CRDSS: <br />dbx lint <br />Developers will debug code by using debugging software tools such as , , and <br />? <br />Purify <br />. Template programs will be used to test individual routines. Debugging will be <br />facilitated by using modular code and by documenting code extensively. Code and <br />documentation will be reviewed by RTi staff and optionally by State personnel. <br />Users will debug code by running full applications (e.g., on the Briefing Room machine) <br />? <br />and will report problems to developers using communications avenues set in place by the <br />user involvement program. The implementation of a command-line argument to turn <br />debugging on will allow users (and developers) to trace program execution. <br />The overall system will be debugged by first testing the prototype system at RTi. Once <br />? <br />validated, the system will be copied to the Briefing Room machine, at which time users can <br />test the system. Comments will be communicated to developers via the user involvement <br />program. <br />3 <br />A275 05.10.94 1.05-3 Malers <br />