Programming used to mean just one thing: typing endless strings of ASCII characters into bottomless files. Luckily, you no longer have to extrude your software designs through the linear-sequential filter of text-based programming tools. Now you can work like an engineer, drawing a compilable diagram of what your design is rather than crafting a list of steps that it must perform.

The difference between textual programming and diagrammatic programming is the difference between a description and a mug shot, between a list of directions and a map, between a formula and a graph. In diagrammatic programming, the ideal is the real; the documentation is the program.

Diagrammatic-programming systems spring from elegant, clear ideas in the minds of their designers. These designers have taken the paradigms for their diagrammatic-programming systems from proven engineering practice, such as networked instruments; directed graphs ("bubble charts"); and DSP, circuit, and control-system diagrams. New diagrammatic compilers, based on diagrammatic software-analysis tools, are on the horizon.

Using diagrammatic programming, you can create what the computer-science mainstream has vainly sought for years: comprehensible software. Diagrammatic programming produces comprehensible software because diagrammatic programming taps the unsurpassed creative and analytical power of the visual hemisphere of the human brain. Simply stated, while humans cannot even begin to approach computers' text-handling ex- pertise, humans can still easily beat computers' pattern-re- cognition abilities.

Although programming-language designers pay lip service to human readability, the consumer they have in mind is clearly their compiler, not the poor programmers. All programming languages require humans to order their thoughts in a fashion easily ingested by computers. Therefore, programming languages introduce a high level of what Jeff Kodosky, inventor of National Instruments' LabView, terms "artificial complexity" into programming, making large programs literally incomprehensible to normal humans.

Diagrammatic programming can make easy what were once difficult software tasks. Writing, debugging, and verifying real-time software is, with the possible exception of DSP, probably the most difficult kind of software to write. But with diagrammatic programming, developing multitasking or multithreaded programs is effortless. You simply draw two lines of execution.

The technique of drawing programs is so new and its applications, so diverse, that the technique has no name. People label the technique "pictorial, "graphical," "iconic," or "diagrammatic" programming. Pointing up the lack of language skills in visually oriented people, some call the technique, oxymoronically, "visual language."

Although diagrammatic programming requires a good graphical user interface (GUI), don't confuse diagrammatic programming with a GUI itself or with software that merely creates GUIs, such as XVT's. Diagrammatic-programming systems are in the same league as programming languages.

Obviously, if you are going to draw a program, the computer you are working on must have high-resolution graphics. Indeed, the inspiration for many diagrammatic-programming systems was the Macintosh. Without a host computer such as the Mac, with its high-resolution graphics and graphics-oriented operating system, or a Unix computer running the X Window System, crafting a diagrammatic-programming system would be difficult. Because of its once-clunky graphics, the IBM PC was the last to acquire any diagrammatic-programming systems.

Diagrammatic programming is inherently better than text-based programming for two reasons: Humans, especially visually oriented engineers, can generate and comprehend pictures much more easily than they can linear lists of text. And, the linear structure of a text-based program simply does not match the structure of real programs. A multidimensional picture can model a complex program much more elegantly and succinctly than can any linear list.

Text-based programming languages, on the other hand, are a jumble of unrelated oddments. Programming languages confound constructs that loosely mirror mathematics with structures that mimic paperwork. Also thrown in the pot are commands derived from the innate testing and looping abilities of certain CPUs—C's increment operator, "++," being an egregious example. Tellingly, even the most modern software metaphor from the text-based world is no more than a messy pile of papers on a desk—windows, in other words. The computer-science mainstream periodically proclaims yet another variation on text-based programming that will magically transform programming from a craft into an engineering discipline. Remember "structured programming?" The latest such fad is "object-oriented" programming (OOP).

OOP takes as its model the hierarchy. (We can thank the Roman emperor Diocletian for the idea of hierarchy. He organized his empire into a rigid rank structure, which the Catholic Church adopted. Later, biologists employed the hierarchy concept in classifying plants and animals into a coherent scheme.)

Hierarchies have their limitations, however. As worthwhile as the biologists' ongoing task of classifying all plants and animals into a hierarchy is, such a scheme tells you nothing about ecology. That is, if you know the location of birds and worms in the hierarchy, you still don't know that birds eat worms for a living and not vice versa. Similarly, OOP does wonders for packaging like functions and deriving new offspring from their forebears. But the familial history of functions tells you little about how they interact when a program actually runs.

Because all these variations on text-based programming tools depend on human beings' feeble reading, writing, and text-comprehension abilities, the latest, hottest textual-programming method just never seems to pan out. And progress in hardware is making the situation worse: Advances in hardware engineering continue to outrace any advances in software engineering.

A common and very effective optimizing technique points up how incomprehensible large programs really are. All optimizing compilers perform "dead-code removal" as part of their bag of tricks. This optimization technique searches for and deletes all subroutines and functions that never get called. Compiler writers include this optimization technique because it is very simple for a computer to perform and because experience shows that all large programs are riddled with dead code like raisins in an oatmeal cookie.

Think for a minute, though: How does dead code come about? Clearly, at one point, a programmer took the time to craft a function or subroutine. That programmer would not have written that code for the fun of it. The programmer must have felt the code to be necessary. Yet other programmers working on the project who could have taken advantage of that code either forgot about it or never needed it.

If programmers used diagrammatic programming instead of textual programming, dead code would be as unlikely as civil engineers' drawing up blueprints for a road to nowhere. Comparing graphical tools that engineers use with programmers' development tools proves telling. Engineers' diagrams have two characteristics that set them apart. First, engineers' tools depend on powerful, formal systems of mathematics. Consider such graphical tools as Smith charts, Bode plots, pole-zero plots, and root-locus plots. Although these tools are intensely graphical, they suppress powerful mathematics.

The second distinguishing characteristic of engineers' graphical tools is that they allow easy bidirectional travel between the real and the ideal domains. Take a pole-zero plot, for example. Engineers can extract such a plot by analyzing a physical system. They can also tell much about a system by glancing at its pole-zero plot. But this process is eminently reversible. Engineers can dispose poles and zeros on a pole-zero plot in any fashion they choose to create an ideal system that has the performance characteristics they want. Then from this pole-zero plot, engineers can synthesize the specs for real components that, when assembled properly, yield a system that performs according to the idealized pole-zero plot.

Conventional software tools do not exhibit these characteristics. The tools do not rest on powerful, formal mathematics, and they are not bidirectional. Until recently, you could only diagram a program. But to realize the program, you still had to concoct linear lists of unfathomable text. Now, with diagrammatic programming, you can actually compile your diagram. With the ability to compile software diagrams, the need to go back and forth from the ideal and real domains disappears.

No text-based software-development system displays this level of bidirectionality or this kind of automatic optimization. In fact, in the programmers' lexicon, "optimization" means taking a stab at making a program as fast or as small as possible, not making the program achieve a complex, formally defined, performance specification.

Proponents of text-based systems can point to relative improvements in their craft with pride. However, in absolute terms, text-based programmers produce the most fault-ridden technological products available. Error rates in the percentages (of lines written) are the norm for large programs (Refs 1 and 3). Hardware projects of a similar level of complexity have error rates in the parts per million.

Advocates of text-based tools argue that new programs have high defect rates because all the components of the programs are crafted from scratch, whereas a complex new piece of hardware—an airplane, for example—is created out of existing components using established design methods.

Even if you grant the textually minded their view, just why does software development have to differ from other forms of technological development? According to proponents of text-based tools, the answer is that software is inherently much more flexible than hardware; hardware is very constrained, presumably giving hardware designers fewer wrong turns to take compared with the virtually infinite ways that software can go wrong. This observation merely raises another question: How did hardware come to be constrained in the first place? This constraint did not happen naturally to the hardware components as they ripened, hardening like nuts on a tree, nor will it happen naturally to software components. Indeed, the only evidence for software's peculiar properties is software itself.

Consider that for all new technological fields, except text-based programming, rapid progress at exponential rates followed an initial period of confusion. Examples are automobiles, aviation, and—of course—electronics. But in all the time that text-based programmers have been hacking away, they have not been able to accumulate the powerful mixture of art (practice) and science that practitioners in other technological fields have. For example, reusable software components, such as Unix utilities and Fortran scientific subroutines that have been in use for more than 30 years, are still full of bugs.

Looking Ahead

Text-based programming systems have a crucial weakness that renders them unfit for engineering: While a drawing can mimic, or symbolize, the actual structure of a device having parallel paths or feedback loops, a linear string of text is inherently a poor way to represent such structures. Anyone who has ever tried to write a real-time program can attest to how hard representing a complex control system in the form of a linear string of text is. "Hardware-description languages" are an even more gruesome method of representing these structures. Then why have we been forced until recently to use text as a basis for a technological tool? Text-based tools are not designed with technologists' unique and powerful visual intelligences in mind. No, a passing familiarity with the arcane class of tools known as "compiler compilers" would reveal that the real consumer that these text-based tools are designed for is the compiler, not the technologist. Those text-based-tool proponents who think that they need do no more than change some outdated "preferences" to gain acceptance of their products by technologists are trivializing a very fundamental and very important problem. Creating technology takes extraordinary visual intelligence. Therefore, technologists' use of visual tools is not a mere "preference" any more than left-handedness or skin color is a preference. Engineers' visual tools have the form that they do because the tools have evolved over long periods of time to resonate with technologists' innate, genetically endowed type of intelligence. Remember, engineering predates not only programming but writing itself. Writing, debugging, and verifying a text-based program is the devil's own curse. Very few humans have the ability and the inclination to putter with such a headache. With luck, these much more humane diagrammatic-programming tools will become prevalent, leaving text-based programming to those chosen few who have been gifted with the kind of intelligence that can handle such a chore. After all, we'll always need a few text-based programmers to write compilers. Luckily, the availability of inexpensive but powerful PCs and workstations means that visual programming will become prevalent over the next few years. As a result, a terrific opportunity exists for visually oriented design tools that really suit the way technologists think and work.

Engineers and programmers who have worked by themselves or on very small development teams might protest that they don't need any diagrammatic-programming systems. After all, high-quality, bug-free text-based software is possible. Lone programmers pursuing concrete goals, using languages and machines with which they are familiar, can do good jobs on small projects—if they have enough time and if their employers are willing to live with a 80:20% or worse software/hardware division of design effort.

The problem with text-based methods is that you cannot scale them up to large projects. An analogy would be building with mud bricks. You can build a perfectly satisfactory 2- or 3-story building from mud bricks if you site the building in an arid region. But don't build a mud-brick, 20-story hotel on a tropical seashore: It would wash away during the first heavy rainstorm if it didn't first collapse under its own weight. The technique just doesn't scale up.

Robert Troy, chairman and managing director of Verilog, agrees that something is wrong with the current state of software practice (Fig 1a). Writing software line by line is a craft comparable with building a wall brick by brick, says Troy. Further, text-based programming is not an engineering discipline, even if engineers are writing the software. But software practice is only half of the problem Troy sees. Engineers at least realize that writing software must become a form of engineering. Management contributes to the problem by continuing to view software as a service rather than as a product.

Fig 1b diagrams Troy's schema for engineered software. Here, engineers fashion software systems at the engineering level by designing and assembling software components. These engineers use diagrammatic-programming systems, writing absolutely no code at all. Management directs the engineers to produce usable software components as products. Management also sets up a crucially important new certifying organization that ensures that the software components are useful, functional, and bug free. Without the certifying organization, reusable software will continue to be just a dream.

Although Verilog already makes computer-aided software-engineering (CASE) tools for OOP and real-time systems, the company is working with Aerospatiale to develop general-purpose compilers that accept charts, graphs, and diagrams as inputs. Conventional CASE tools do produce lots of charts, graphs, and specifications but no actual software beyond header files and function prototypes. Consequently, engineers who use conventional CASE tools labor mightily to produce a detailed design at the front end of a project. Then they go off for a year or two to code the design. Typically, at the end of the project, the resulting program bears no resemblance to the original design's documentation. As Troy sees it, the solution to this problem is to make the CASE material compilable.

The company will not field-test its diagrammatic compilers until mid-1994, and they will not be commercially available until late 1994. Verilog's software-analysis and reverse-engineering tool, Logiscope ($8000 to $15,000), provides a hint of what the company's version of diagrammatic programming might look like. Logiscope extracts graphs, histograms, and tables from a program to illuminate the program's structure, however large. The tool understands 90 programming languages and dialects, including Ada, C, C++, Fortran, and Pascal. It determines test coverage and recasts the structure of a program from one language to another. It runs under the Open Software Foundation's Motif specification.

A quick tour of some of the available diagrammatic-programming systems discloses that they fall into the following four broad categories—with some products overlapping categories:

• data-acquisition (instrument-con trol), analysis, and display software
• engineering simulators
• special-purpose program generators
• debugging tools

National Instruments began work on its diagrammatic-programming system, LabView ($1995), in 1984, qualifying the company as the undisputed pioneer of diagrammatic programming. When developing LabView, inventors Kodosky and James Truchard had a vision of "virtual instruments"—software entities that would plug together as easily as lab instruments do. Kodosky chose the data-flow diagram as a visual metaphor.

Conventional software diagrams, such as the data-flow diagram, invariably prove inadequate as compilable program descriptions. In National's case, the company's programmers had to immediately extend the data-flow diagram to make it into a complete program specification. For example, as soon as the first prototype was working, the need for icons that performed looping and iterating became painfully apparent. These icons perform the functions of common software constructs such as While, For, and Do loops. The company also concocted icons for control that correspond to CASE statements as well as an icon that impresses a sequential execution order upon segments of the data-flow diagram.

LabView's evolution is a story of continued improvement. It began life as an interpreted application program that ran only on Macs. But because National told LabView users that the product would allow them to simply draw programs, users expected the program to be as easy to work with as MacPaint. MacPaint cuts and pastes mere pixel fields; enhancing LabView to allow cutting and pasting program elements proved much harder to effect.

Next, LabView became a compiled application instead of an interpreted one to raise execution speed. Soon after, the need for a "runtime" version became apparent as users began to ship LabView systems as products rather than as services. The latest version of LabView is a true compiler, producing programs that run stand-alone. It also calls test routines written in other languages. The software now runs on Sun workstations and Windows PCs as well as Macs.

With LabView, as with other diagrammatic-programming systems, multitasking is effortless and crystal clear. If your application demands multitasking, you simply draw multiple streams of execution. Using textual programming for real-time programming results in murky code that rivals in incomprehensibility old-fashioned Fortran "spaghetti" code.

Note that National Instruments did not abandon text-based programming. The company finds that a certain percentage of test-program writers simply cannot use a diagrammatic-programming system. Lacking a foundation in cognitive psychology, National takes a stab at explaining this phenomenon by positing that some programmers are too used to text-based tools to be able to switch to diagrams. For these programmers, the company has a semiautomatic text-based program generator, called Lab Windows.

Wavetek's WaveTest ($1995 for PCs, $6490 to $7995 for various Digital Equipment Corp computers) has evolved into a similar diagrammatic-programming system for IEEE-488, VXI, and RS-232C instruments. The latest version runs under Microsoft's Windows and supports dynamic data exchange (DDE). Wavetek combines two visual metaphors: The data-acquisition portion of the software employs the flow chart as a visual metaphor, and the analysis portion—a product developed by DEC—uses the data-flow diagram.

Wavetek had to add enhanced case, looping, and branching icons to the standard flow-chart symbols. The company also added an interesting real-time construct to handle asynchronous service requests (SRQs) from IEEE-488 instruments. To set up a prioritized interrupt handler, you simply expand the SRQ icon and fill in a table. This table provides a clean and concise solution to what is a nasty bit of coding in other programming systems.

To accommodate text-based programmers, the company's VIP ($695) allows text-based programs to link to WaveTest's 200+ instrument-control drivers. The program includes a front-panel editor.

Also bridging data acquisition and display, as well as general-purpose simulation, is Hewlett-Packard's VEE (simulator, $995; IEEE-488 control, $5000). This software runs on HP 9000 computers under HP-UX (HP's Unix) and the X Window System. The visual metaphor for VEE (pronounced "vee") is the data-flow diagram. You draw your program by connecting icons. The software also comes with icons for engineering and mathematical operations. The icons themselves are examples of OOP and tend to be more complex and powerful than LabView's or WaveTest's. For example, the simple-seeming multiplication icon can perform any mathematically allowable multiplication. The icon can sense the types of the data that appear at its front end. The icon can multiply integers, floating-point numbers, complex numbers, and matrixes without specific instructions.

Not all test-software generators take a diagrammatic-programming tack. Capital Equipment's TestPoint ($995) takes an adamant anti-icon stance. This Microsoft Windows test-program generator reduces text-based OOP to the barest possible minimum. To concoct a test program, you drag and drop named objects from various collections into your "action list" (program). Some of the objects require you to type a few parameters. But you set up most objects in your action list for an application by selecting options from pop-up menus.

The software can multitask IEEE-488 and RS-232C instruments. One interesting feature is its ability to mix test results, schematics, and pictorial information. You can use this feature to make computerized equivalents of the famous Sam's "Photofact" annotated circuit diagrams. That is, you could aid test technicians by combining a circuit diagram showing a test point with a photo of a pc board. You could also display the required readings against the actual readings at that test point.

Keithley MetraByte's Visual-DAS ($99) takes a similar approach. The software allows a programmer to incorporate test routines for the company's data-acquisition boards into Microsoft Visual Basic for Windows programs simply by selecting and customizing objects. Meanwhile, Intelligent Instrumentation's Visual Designer adheres to the the diagrammatic-programming paradigm.

Since DSP engineers have always manually diagrammed their designs, it's not surprising that several vendors have developed diagrammatic compilers for DSP. Without a diagrammatic compiler, DSP is a programmer's nightmare that combines arcane mathematical algorithms, abstruse physics, and quirky µP instruction sets into a horrific witch's brew.

Comdisco's Signal Processing WorkSystem ($25,000), which runs on Unix workstations, began life as a simulator. The simulator accepted simulation programs drawn on workstation screens using engineers' DSP function blocks. Comdisco's visual metaphor is the engineers' familiar block diagram. Now that C compilers are available for DSP µPs, the system has evolved into a program generator as well.

Similarly, when Star Semiconductor developed its SPROC DSP chip, it also fielded its SPROClab diagrammatic-programming system ($5460). The IBM PC software allows you to interconnect standard function blocks to build signal-flow diagrams. It then compiles these diagrams directly over the DSP chip's hardware. (You can call these functions from programs written in other languages.) The software package also includes a debugger.

Other diagrammatic-programming tools for DSP come from Analog Devices, The Athena Group, Compass Design Automation (includes VHDL entry), Dynetics, Hyperception, Multiprocessor Toolsmiths, and Signal Technology.

However, diagrammatic programming isn't limited to test systems and DSP. Extend V2.0 ($695) from Imagine That Inc allows you to simulate complex systems on a Mac. This general-purpose dynamic-system simulator comes with function-block icons for amplifiers, filters, digital gates, and control functions as well as icons for mechanical systems and economics. The latest version has extensions ($990 each) for business-process reengineering and manufacturing. It also has data-analysis and display icons so that you can see the results of your simulation.

Integrated Systems' Matrix_X ($2500 to $63,000) includes a diagrammatic-programming system exclusively for control engineers. The software, which runs on Unix workstations, accepts program specifications in the form of control engineers' block diagrams. Underlying the simple-seeming blocks are rigorous mathematical analytical engines for linear-system analysis. A fuzzy-logic system is also available.

The system first creates a non-real-time simulation from the block diagram. You can run this simulation from a virtual front panel, observing the simulation's response. The program displays outputs in graphical forms familiar to control engineers, such as Bode, root-locus, and Nichols plots. The software also incorporates measured data to simulate real-world devices and generates real-time source programs in C or Ada. The company also makes a Multibus-based simulator on which you can run programs in real time.

Another example of diagrammatic-programming systems are neural networks—the epitome of parallelism. For example, NeuralWare's NeuralWorks ($3995 to $7995) allows you to select any one of 28 major neural-network paradigms and dozens of variations. The software, which runs on PCs and common workstations, displays a diagram of the network you have chosen and lets you customize the network via a menu. As you train your network, the software displays diagrams of the network's evolving structure and outputs. Only when you are finished training your network does the software generate the C code that realizes your network.

A little-remarked-upon deficiency of text-based programming tools is that they suppress time. Not surprisingly, timing analyzers for digital circuits such as those from Chronology and Dr Design feature powerful graphical means for describing timing relationships.

If you've a hankering to try diagrammatic programming, you are not confined to grandiose, high-level projects such as designing an ASIC. Tao Research's GDS-11 ($1725) is a diagrammatic-programming system for the 68HC11 single-chip microprocessor that includes a compiler, a simulator, and a symbolic debugger. The software currently runs only on the Macintosh, but versions for Microsoft Windows and the 68HC16 are in the works.

Just like other diagrammatic-programming systems, GDS-11 makes multitasking effortless. You simply draw a state-transition diagram for each independent process. The state-transition diagrams act as visual metaphors and follow usual engineering practice with a few extensions. One minor change is that the states are in rectangular boxes instead of ovals because boxes are easier for a computer to draw than ovals. More important, you can subsume a collection of states and their relationships under a single state. That is, you can have submachines hierarchically ranked beneath a parent state machine. This facility proves handy when a state machine becomes too big or unwieldy to display on a Mac's screen.

As the capacities of gate arrays and field-programmable gate arrays grow, the need for special-purpose compilers that can handle such devices grows apace. One class of special-purpose digital-device compilers are "hardware-description languages" (HDLs). In a classic case of "give a carpenter a job to do and he'll think of a solution in terms of hammer and nails," textually oriented proponents of HDLs are bucking the trend toward making programming more like engineering; they want to turn digital engineering into programming. Instead of drawing a symbolic representation of what an electronic device is, HDL proponents would have digital engineers enter a text description of what it does.

The rationale for the switch from diagrammatic to textual methods is that gate-level symbolic systems are too cumbersome for large designs, necessitating a shift to a form of programming. And, of course, "programming" can only mean entering long strings of ASCII text into bottomless files.

Or does it? Consider architecture—a visually oriented profession if ever there was one. When architects design a house, they produce blueprints detailing every brick, every nail in every truss, every doorknob, and every hinge. But if architects are designing a large shopping center or planning a city, they don't abandon blueprints for text. They continue to produce visual designs but on a different scale and a different level of detail than when building a house.

Because HDLs must describe inherently parallel hardware elements with a sequential stream of ASCII characters, the "artificial complexity" of HDLs is even higher than that of conventional programming languages. So complex are HDLs that even experienced users caution against using more than a tiny, proven subset of an HDL's full range of expressiveness.

Further, even ardent HDL advocates admit that HDLs do a poor job of handling random logic. HDLs fare best on regular hardware structures, providing an easy way to size such structures for specific applications by changing a few parameters. But stripped of the artificial complexity of a text-based programming language, such scalable HDL constructs reduce to a fill-in-the-blanks chart—a staple of diagrammatic-programming systems.

One vendor, i-Logix Inc, has pursued a diagrammatic path to "synthesizing" digital designs. The company chose a prodigiously enhanced state-transition diagram as one of its visual metaphors. The company's booklet (Ref 2) describing the enhancements is worth reading to improve your manually drawn state-transition diagrams. Along with the enhanced state-transition charts, the software provides an activity chart for diagramming process views, functions, activities, interfaces, and data flow. Last, a module chart shows how the components of the architecture relate physically.

The company's first product, Statemate V5.0 ($20,000 to $40,000), simulates finite-state machines on Unix workstations. You draw a state-transition diagram and other supporting documentation on a workstation screen. You then link your state machine to a simulated operator's control panel, and "operate" your state machine. Recent improvements allow you to use a finite-state-machine chart as a template with which you can instantiate multiple examples of that chart. The software now also aids you in correlating system requirements with the state machines you have designed. Such "requirements traceability" is easy because it lets you directly compile engineering documents rather than using an HDL. Similarly, Ractive Concepts' Betterstate ($995) turns enhanced state charts into C code.

Another product from i-Logix, Express VHDL V3.0 ($32,500), turns your state machine into an HDL listing in VHSIC HDL (VHDL). You can then compile the resulting VHDL listing into an ASIC. In other words, you can realize an elegant finite-state machine in an ASIC at the press of a key without writing any code.

Charting a slightly different course, Redwood Design Automation's Reveal ($65,000) takes VHDL and Verilog HDL text files as inputs. The software then abstracts the HDL elements in compact, visual representations. You can manipulate the structure of these representations as well as simulate the diagrammed systems.

Diagrammatic tools can also help you make sense of text-based source code. For example, Procase's Smartsystem ($35,000) can convert an ugly, undocumented, 1-million-line C program into a comprehensible directed graph (bubble chart). The software has facilities for navigating through this directed graph of call dependencies and homing in on selected sections of the program being analyzed. It also automatically finds dead code and a variety of syntax errors.

Another debugging tool, Pure Software's Quantify ($1198), analyzes a program to determine "watchpoints." Thus, it comprehensively analyzes the execution of an entire program, including calls to shared and third-party libraries. Setting a flag during Make operations enables the performance measuring; it requires no recompilations or special libraries. The software, which runs on Sun workstations, graphically displays the gathered performance information in a striking "river of time," pinpointing the routines that consume the most processing time.

Finally, Wind River Systems' WindView ($4995) graphs with 1-msec resolution the dynamic behavior of multitasking software systems. The software presents a time line of the actual sequence of high-level system activities, such as task switching, interrupts, semaphore operations, and message passing.

1. Schindler, Max, Computer Aided Software Engineering, McGraw-Hill, New York, NY, 1981.
2. "The Languages of Statemate," STCON-01, i-Logix Co, Burlington, MA.
3. Wiener, Lauren Ruth, Why We Should Not Depend on Software, Addison-Wesley, Reading, MA, 1993.

Manufacturers of diagrammatic-programming systems
For free information on diagrammatic-programming systems such as those described in this article, circle the appropriate numbers on the postage-paid Information Retrieval Service card or use EDN's Express Request service. When you contact any of the following manufacturers directly, please let them know you read about their products in EDN.
Analog Devices Norwood, MA (617) 329-4700	The Athena Group Gainesville, FL (904) 371-2567	Capital Equipment Corp Burlington, MA (617) 273-1818
Chronology Inc Redmond, WA (206) 869-4227	Comdisco Systems Inc Foster City, CA (415) 574-5800	Compass Design Automation San Jose, CA (408) 734-7990
Dr Design San Diego, CA (619) 457-4545	Dynetics Inc Huntsville, AL (205) 922-9230	Hewlett-Packard Co Loveland, CO (303) 679-5000
Hyperception Dallas, TX (214) 343-8525	i-Logix Inc Burlington, MA (617) 272-8090	Imagine That Inc San Jose, CA (408) 365-0305
Integrated Systems Inc Santa Clara, CA (408) 980-1500	Intelligent Instrumentation Tucson, AZ (602) 573-0887	Keithley Metrabyte Taunton, MA (508) 880-3000
Multiprocessor Toolsmiths Nepean, ON, Canada (613) 599-6565	National Instruments Co Austin, TX (512) 794-0110	NeuralWare Pittsburgh, PA (412) 787-8222
Procase San Jose, CA (408) 433-9500	Pure Software Sunnyvale, CA (408) 720-1600	Ractive Concepts Cupertino, CA (408) 252-2808
Redwood Design Automation San Jose, CA (408) 291-3650	Signal Technology Inc Weymouth, MA (617) 337-8823	Star Semiconductor San Jose, CA (408) 526-2160
Tao Research Corp Fremont, CA (510) 770-1344	Verilog Inc Dallas, TX (214) 241-6595	Verilog SA Toulouse, France 33 61 19 29 39
Wavetek Inc San Diego, CA (619) 279-2200	Wind River Systems Alameda, CA (510) 748-4100	XVT Boulder, CO (303) 443-4223