Article from: EDN
Author: Charles H Small
A host of
diagrammatic-programming and debugging tools allows you to picture
what your program is rather than making you describe in words what it
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.
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
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.
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
expertise, humans can still easily beat computers'
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' Lab View, terms "artificial
complexity" into programming, making large programs literally
incomprehensible to normal humans.
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.
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."
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
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.
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.
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.
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).
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.)
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
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
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.
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.
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.
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.
the ideal to the real and back
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.
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
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.
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.
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.
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.
programming once had its place
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 enought time and if
their employers are willing to live with a 80:20% or worse
software/hardware division of design effort.
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.
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
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.
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.
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.
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 ($800 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.
quick tour of some of the available diagrammatic-programming systems
discloses that they fall into the following four board
categories--with some products overlapping categories:
data-acquisition (instrument-con trol), analysis, and display
special-purpose program generators
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.
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
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.
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.
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 realtime programming results in murky code
that rivals in incomprehensibility old-fashioned Fortran "spaghetti"
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.
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
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.
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.
bridging data acquisition and display, as well as general-purpose
simulation, is Hewlett-Packard's VEE (simulator, $995; IEEE-488
control, $500). 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 fron end. The icon can multiply integers, floating-point
numbers, complex numbers, and matrixes without specific instructions.
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
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.
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
addresses specific tasks
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 [mu]P instruction sets into a horrific witch'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
[mu]Ps, the system has evolved into a program generator as well.
when Star Semiconductor developed its SPROC DSP chip, it also fielded
its SPRCOClab 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
diagrammatic-programming tools for DSP come from Analog Devices, The
Athena Group, Compass Design Automation (includes VHDL entry),
Dynetics, Hyperception, Multiprocessor Toolsmiths, and Signal
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
Systems' [Matrix.sub.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.
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.
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
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.
you've a hankering to try diagrammatic programming, you are not
confined to grandiose, high-level projects such as designing as 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 version for Microsoft Windows and the 68HC16
are in the works.
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.
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.
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.
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.
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.
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.
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.
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 charts 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.
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.
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.
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.
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.
Wind River Systems' WindView ($4995) graphs with 1-[mu]sec resolution
the dynamic behavior of multitasking software systems. The software
presents a time line of the actual sequence of high-level systems
activities, such as task switching, interrupts, semaphore operations,
and message passing.