|
| Figure 1. Source code for function in_list |
GRASP (Graphical Representations of Algorithms, Structures, and Processes) is a software engineering tool which provides for the automatic generation of Control Structure Diagrams (CSD's) from Ada 95 source code. The CSD is intended to increase the comprehensibility of Ada 95 source code. CSD's are useful both when designing and implementing new software, as well as when reading existing source code. GRASP also serves as a graphical interface to GNAT (GNU Ada Translator), an Ada 95 compiler used by many companies, universities and colleges. Programmers may create and edit source files, generate CSD's for source code, print source code and CSD's, and compile and run Ada programs, all from within the GRASP environment. From a research point of view, we are interested in seeing how the GRASP environment in general and the CSD features in particular are used by programmers. This paper describes the CSD and the GRASP/Ada 95 environment, which is freely available.
Computer professionals have long promoted the idea that graphical representations of software can be extremely useful as comprehension aids when used to supplement textual descriptions and specifications of software, especially for large complex systems [1, 2, 3, 4, 5, 6]. The general goal of the GRASP/Ada research project is the investigation, formulation and generation of graphical representations of algorithms, structures, and processes for Ada [7, 8, 9]. The research is currently focused on the generation or reverse engineering of Control Structure Diagrams (CSDs) from Ada 95 source code.
The primary motivation for the generation of graphical representations is increased support for software life cycle activities ranging from design through maintenance with emphasis on visual verification and measurement. These activities should be greatly facilitated by an automatically generated set of "formalized diagrams and graphs" to supplement the source code and other forms of existing documentation. The GRASP/Ada 95 software tool has the potential to be a powerful aid in any environment where Ada 95 is expected to be read and/or written.
The tool is particularly suitable for activities during detailed design, implementation, testing, maintenance and reengineering. The CSD is expected to be a valuable aid in comprehension and analysis of overall program structure and flow of control. The following sections describe the control structure diagram and the GRASP/Ada 95 prototype.
Figure 1 contains the source code for an Ada function called in-list. The purpose of in-list is to determine if a string is present in a linked list where the string and linked list are passed to the function as parameters. If the string is found, in- list returns true; otherwise, it returns false. Figure 2 contains the CSD for in-list. This is a simple example, but it demonstrates the CSD for the three basic control constructs: sequence, selection, and iteration. The various levels of control within the program are also illustrated. At level one, we have a total of three statements being executed: an assignment statement, a while loop, and a return statement. The while loop defines a second level of control consisting of a single if statement. The if statement defines two separate sequences at a third level of control. The true path consists of a return statement, and the false path is a single assignment statement.
|
|
| Figure 1. Source code for function in_list |
|
| Figure 2. CSD for function in_list |
Now that each of the basic control flow constructs has been introduced, the variations of these constructs are described in more detail. Sequential program flow is well demonstrated in Figure 2. The individual statements on a particular level of control are marked with small horizontal lines attached to the vertical line that represents that level of control.
Selection in Ada is accomplished one four basic control constructs: the if statement, the if...else statement, the if...elsif statement, and the case statement. The CSD notation for each of these is shown in Figure 3. The connotation of each CSD selection construct is identical. The condition for selection is marked with a small diamond, just as in a flowchart. The statements to be executed if the condition is true are marked by a solid line leading from the right of the diamond. The control path for a false condition is marked with a dotted line leading from the bottom of the diamond to the next executable statement, either another decision diamond, an else clause, an others clause,or the end of the decision statement.
|
| Figure 3. CSD's for selection |
|
| Figure 4. CSD's for iteration |
Iteration in Ada is provided by three looping constructs: the for loop, the while loop, and the basic loop. The CSD construct for each denotes where the iteration begins and ends, as shown in Figure 4. In the basic loop, an exit statement may be used to terminate the iteration. The exit statement is denoted in the CSD by an arrow which points to the control level where the program should continue its execution after the loop is exited. When the exit statement indicates a specific loop (by name), the exit arrow is drawn at the appropriate level.
The CSD uses five different types of open-ended boxes to identify the major Ada program units. These are called the single box, the double box, and the slanted box, and the single and double boxes with dashed lines. Each particular box represents a specific group of Ada program units. Collectively these are referred to the CSD Box Notation as illustrated in Figure 5. The first of these boxes is the single box, which is shown encasing the statement "procedure maximum is" in Figure 2. This symbol is used to identify both specifications and bodies for Ada subprograms (functions and procedures), protected types, exception handlers, and task entries. The double box is used to identify both package specifications and package bodies in Ada. The slanted box is used to identify the body and specification of the Ada unit known as the task. Finally, the CSD identifies generic packages and subprograms with a dashed single box for generic subprograms and a dashed double box for generic packages.
|
-- subprograms, exception -- handlers, task entries -- and protected specs. & -- bodies |
|
-- package specifications -- and bodies |
|
-- task specifications -- and bodies |
|
-- generic subprograms |
|
-- generic packages |
| Figure 5. CSD Box Notation | |
CSD unit symbols, illustrated in Figure 6, provide the user with the option of specializing the program unit identified by the box notation. These are patterned after Booch's module notation [10] but include additional original symbols for task entry, protected specification and body, and exception handler. The CSD shown in Figure 2 uses the subprogram unit symbol combined with the box notation, but it could have been just as easily shown using only the box symbols. As programs increase in size and complexity, the CSD unit symbols become more useful in comprehending the Ada source since they can provide a direct visual cue with the architectural diagrams of the system.
|
-- subprogram specification, body |
|
-- package specification, body |
|
-- task specification, body |
|
-- generic units |
|
-- protected specification, body |
|
-- exception handler |
| Figure 5. CSD Box Notation | |
GRASP is a software engineering tool generates the CSD for a given Ada program unit, and provides a seamless integration with GNAT to perform other functions associated with code development. GRASP is used to create, edit, compile, and run Ada programs. This section introduces GRASP and provides a brief overview of its most common features.
|
| Figure 7. GRASP Control Panel |
The GRASP/Ada 95 Version 4.4 prototype, provides a Control Panel, shown in Figure 7, for the overall coordination of the environment. From the Control Panel, the user can open one or more CSD windows. The CSD window, shown in Figure 8, is a full-function text editor with the additional capability to generate, display, edit, and print CSDs. The File and Edit options are similar to traditional text editors. View allows the user to select any combination (or none) of the following: the standard CSD Box notation, program unit symbols, and line numbers. The Template option opens a tear-off menu of selectable Ada templates. When a template name is clicked, the source code for it is inserted at the point of the cursor. The CSD in Figure 9 is the result of clicking on templates for package body, task body, procedure body, while loop, and if then else. The user may add custom templates to the list.
|
| Figure 8. GRASP CSD Window |
|
| Figure 9. Using Ada Templates |
When a file containing an Ada program unit is loaded, the CSD is automatically generated if Auto (next to Generate CSD on tool bar) is turned on. Otherwise, the user may generate the CSD on demand by clicking the Generate CSD button (or ctrl-g or F1), which is usually done routinely during the course of editing to redraw the diagram. All white space and comments in the source code are preserved with the exception of indentation, which is replaced by the CSD. If a parse error is encountered during CSD generation, the cursor is moved to the highlighted line containing the error to aid the user in making corrections. When the user saves a file, the CSD is filtered so that only the Ada source code is retained. The CSD generation and display cycle is extremely fast (approx. 5,000 lines/sec on a Sparc 10). The net result is that the CSD window can be used in place of a traditional program editor to generate, display, edit, and print CSDs with virtually no overhead; i.e., the CSD is essentially free.
Version 4.4 is coupled with the GNAT Ada 95 compiler [11]. The CSD window allows the user to invoke GNAT directly for the current program unit to perform a Make, Compile, or Semantic Check. When an error is reported by the compiler, the offending line of code is highlighted in the diagram. In Figure 10, line 12 is highlighted to indicate that counter has not been defined.
|
| Figure 10. GRASP Message Box |
Note the error message returned by GNAT is displayed in the GRASP Message window also shown in Figure 10. The Compile option allows the user to set compiler flags via the Flag Setup dialog box as illustrated in Figure 11.
After making an executable, the user may run the file directly from the CSD Window by selecting Run, Run Previous, or Run File. Run assumes the user wants to run the executable file associated with the source file in the current CSD window. Run Previous runs the file that was executed by the most recent of the Run options. Run File opens up a file select dialog box, and allows the user to run an existing executable. The Grasp Run Shell Window is opened for input/output to the executing program as shown in Figure 12. This shell runs as a separate process so that the execution of the user's program cannot affect GRASP. A Grasp Run Control dialog box, also shown in Figure 12, allows the user to send various signals to the program (e.g., interrupt or kill).
|
| Figure 11. Compiler Flag Dialog |
|
| Figure 12. GRASP Run Shell and Run Control Dialog |
Version 4.4 is currently being used as a front-end for GNAT in three to five computer science and engineering courses per quarter at Auburn University. The use of the GRASP environment in these courses is being studied to assess its overall utility. The local version has been instrumented to automatically collect usage data, which will be analyzed to determine how and how much GRASP is being used. A survey is planned in which students will be asked to indicate how they used GRASP and their preferences for its different modes. The survey data will be compared to the actual usage data. Of particular interest, will be the students' utilization of the CSD rather than plain text for displaying and printing their source code. The results of this study will be presented in a future paper. GRASP runs under Solaris and is available via the internet at the following URL.