GrASP

GrASP - Graphical Representations of Algorithms, Structures, and Processes - is a graphical notation for procedural control flow, and the software environment that generates it automatically from source code. It was built at Auburn University from the late 1980s onward under contracts from NASA, ARPA and the Defense Information Systems Agency, and its central artifact, the Control Structure Diagram, is one of the few software visualization notations of that era still in daily use, though almost always under the name of its successor, jGRASP.

GrASP occupies an unusual place in a catalogue of programming languages. It is not a language you write programs in. It is a language you read programs in: a compact, formally defined set of graphical constructs that is superimposed on Ada, C, C++, Java or VHDL source without displacing it. The project began, however, with an explicitly linguistic ambition - the first NASA final report, in 1989, is titled A Graphically Oriented Specification Language for Automatic Code Generation, and the stated goal was a notation that could be reverse-engineered from Ada source and forward-engineered back into it.

A Note on Identification

Several unrelated things are called GRASP: a 1980s DOS animation package (Graphics Animation System for Professionals), a set of object-oriented design principles (General Responsibility Assignment Software Patterns), a family of combinatorial optimization heuristics (greedy randomized adaptive search procedure), a SAT solver, an atomic-structure physics code, and a contemporary graphical Scheme editor. This page covers only the Auburn University software visualization project, which is the GrASP that appears in language catalogues with an education classification and a procedural paradigm.

Catalogues commonly date GrASP to 1998. That year is defensible as the point at which the system reached maturity and public evaluation - the Empirical Software Engineering paper and the SIGAda 98 paper both appeared then - but the notation itself is a decade older. The front matter here dates first appearance to 1989 and notes the 1998 convention.

History and Origins

The work started as a three-phase NASA-sponsored effort at Auburn, with James H. Cross II as principal investigator. Phase 1, reported in September 1989 as NASA CR-183212, concentrated on deriving an algorithmic-level diagram from Ada source code and Ada PDL. The problem it was chosen to attack was specific and expensive: the Department of Defense had committed enormous programs to Ada, and the cost of that software was dominated not by writing it but by later engineers reading it.

The 1991 report, NASA CR-190231, describes how the idea was hardened. The first phase applied the diagram by hand to small programs. The second built a prototype, ported it to Unix workstations, and scaled it up to programs of several hundred to several thousand lines. The third prepared Version 3.0 for distribution. The generator was installed and demonstrated on a Sun workstation at Marshall Space Flight Center in September 1991, and put to use in Auburn software engineering courses.

Through the 1990s the tool broadened. Release 4.3 was integrated with GNAT, the GNU Ada 95 compiler. A January 1996 CrossTalk article by Cross, Kai H. Chang and T. Dean Hendrix presented the Ada 95 system and introduced a companion visualization, the Complexity Profile Graph, which showed statement-level complexity synchronised line-for-line with the diagram. By the 1998 SIGAda paper, GRASP was generating CSDs for Ada 95, C, C++, Java and VHDL, and had added syntax coloring and source code folding.

Design Philosophy

The governing principle is stated plainly in the SIGAda paper: the graphical constructs should supplement the source code without disrupting its familiar appearance. The CSD should look like a natural extension of the code, and the code should look like a natural extension of the diagram.

This is a sharper constraint than it sounds, and it is what separates the CSD from the diagram traditions it grew out of. Flowcharts replace the code with boxes and arrows on a separate page, so they drift out of date the moment the code changes and they consume enormous space. Nassi-Shneiderman charts keep structure and code together but force the program into nested rectangles, which breaks down badly on deep nesting and on languages with rich exception and concurrency constructs. The CSD instead claims only the left margin. Control constructs are drawn as a thin tree of stems and marks in the space that indentation would otherwise waste, so by design a diagrammed listing occupies essentially the same number of lines as the plain one, at the cost of a few columns of margin. The project made no quantitative space or speed claims that are reproducible from the published reports alone.

Three consequences follow from that choice, and they are the reasons the notation survived:

• It can be generated, never drawn. Because the diagram is a deterministic function of the parse tree, it is regenerated on every keystroke and cannot go stale. There is no separate artifact to maintain.
• It is lossless in both directions. The source is still there, verbatim. Reverse engineering an existing codebase costs nothing and risks nothing.
• It scales to real programs. Visualizations that need their own page fail at thousands of lines. A notation that fits in the gutter does not.

The Control Structure Diagram

The CSD marks control flow directly in the listing. Sequence, selection, iteration and exit are each given a distinct graphical stem, so that a reader can see the shape of a routine - where the loops are, how deeply the conditionals nest, where control leaves early - before reading a single identifier. Because the constructs are drawn rather than inferred from whitespace, the diagram is immune to the misleading indentation that causes real defects in C-family code.

The project treated diagram design as an empirical question rather than an aesthetic one. The 1998 Empirical Software Engineering paper by Cross, Maghsoodloo and Hendrix was an overview and initial evaluation of the notation - an attempt to establish whether the comprehension benefit that visualization researchers had long asserted actually appeared under measurement. That instinct, that a visualization is a claim to be tested rather than a picture to be admired, is the intellectual contribution of the project that has aged best.

Beyond the Diagram

Later versions layered further representations over the same parse:

The synchronisation is the interesting part. Reading the CSD and the CPG together lets a maintainer locate not merely where a routine is complicated but which statements within it carry the complexity - a question that a single whole-function number such as cyclomatic complexity cannot answer.

Evolution and Dormancy

GRASP existed in two native implementations: GRASP for Linux and UNIX, and pcGRASP for Windows, both written in C and C++. Maintaining two native codebases against five host language grammars proved to be the limiting factor, and around 2002 the project was rewritten from scratch in Java as jGRASP, distributed as a Java desktop application and therefore far less tied to a particular operating system than the native builds had been. A jGRASP handbook draft dated 2 June 2002 circulated with introductory course materials of the period.

The rewrite also changed the sponsor and the audience. The original GRASP was defense and aerospace research funded by NASA, ARPA and DISA, aimed at Ada maintenance. jGRASP has been supported by the National Science Foundation and is aimed squarely at education, adding object viewers that draw linked lists, stacks and trees from live debugger state, plus interactive UML for Java.

The GRASP name is therefore dormant rather than dead. No new GRASP or pcGRASP releases have appeared, but the notation remains under active development: as of this writing the jGRASP site lists release 2.1.0_01, dated 6 July 2026, with supported host languages reportedly including Java, C, C++, Objective-C, Python, Ada and VHDL.

Why It Matters

GrASP is a useful counterexample to the assumption that program visualization means replacing text with pictures. Almost every graphical programming system of the 1980s and 1990s asked developers to give up their source code; nearly all of them are gone. GrASP asked for the left margin and nothing else, and the result is still shipping to students more than thirty-five years after the first NASA report.

It also anticipated a shape that modern editors now take for granted. Automatically generated, always-current, inline structural annotation - the folding markers, the bracket-pair guides, the indent rails, the inlay hints in a contemporary IDE - is the CSD idea, arrived at independently and usually in a weaker form. The insight that the compiler already knows the program structure and that the editor should therefore draw it, rather than asking the programmer to maintain a separate diagram, was worked out at Auburn under a NASA contract before most of those editors existed.

For a language catalogue, GrASP is a reminder that not everything called a language is something you type. Some notations exist to be read, and this one was built by people who took the reading seriously enough to measure it.