A future programmer may look less like a writer laying down words and more like an electrician wiringtogether circuit components
Peter D. Varhol
With the arrival of programming tools such as Visual Basic, the term visual programming has entered the lexicon of mainstream computing. However, the term means very different things to different people. For many, Visual Basic--and its cousin, Visual C++--may be all they know, or expect to know, about visual programming. To others, Visual Basic is hardly representative of the vast array of different technologies that share the label of visual. Among the other alternatives are Digitalk's Parts, Powersoft's PowerBuilder, Meta Software's Design/CPN, and Novell's Visual AppBuilder.
The goal of all of these different approaches is the same: to make programming easier for programmers and accessible to nonprogrammers. Some are used for rapid prototyping and rapid applications development, others are used for systems or applications design, and still others can produce stand-alone applications for distribution. In all cases, visual languages and visual programming let users put more effort into solving their particular problem rather than learning about the computer or about a programming language. This way, an engineer, for example, does not also have to be a computer programmer to simulate a complex control system.
The term visual programming strongly implies graphics. Although it is possible to "program visually" in a textual environment, you lose much of the visual aspects of the program in doing so. It also implies an object-oriented--or at least an object-like--view of a program. There's nothing like representing every program activity as a screen object to reinforce object-
oriented principles, even if a component is not an object in the strictest sense.
Visual User-Interface Builders and Beyond
The best-known approach to visual programming is the interface builder, typified by Visual Basic and HyperCard. These tools provide a set of screen objects, such as buttons, scroll bars, and menus. You position these constructs on a form and describe their behavior through the use of a scripting language associated with each one.
Visual Basic goes beyond being a simple screen builder to being a component builder, because its components (called VBXes), which can be quite complex, can be abstracted from one application and placed in another (see "Componentware," May BYTE). You might call this a visual environment for program construction.
The ability to do this has been available commercially since the mid-1980s, but it became widely known with Visual Basic. What you are doing is visualizing the software design from the user interface down and then implementing it.
Visual Basic and similar tools constrain you to think of an application in terms of the user interface, making it more likely that the program will be very user-centered.
However, Visual Basic and Apple's HyperCard lack the ability to extend predefined objects by inheriting their characteristics. You can add new components, but only with conventional programming techniques.
Visual System Modeling
A second category of visual languages might be thought of as visual modeling tools. You can use these to create visual models of systems, programs, or data. But what separates these from simple drawing packages is that it becomes possible to "execute" the model to simulate the operation of a program or a system. Products such as i-Logix's Statemate and Meta Software's Design/CPN do just this.
Both of these products support the system-design process. Statemate uses state charts, while Design/CPN employs colored Petri nets. State charts work best when modeling the transition of a system from one
state to another, while colored Petri nets are more useful for modeling the flow of control in a system. Both of these design formalisms have a logical structure that makes the resulting models deterministic, meaning that there is only one set of outputs for any set of inputs.
Visual Solutions' VisSim gives you a predefined set of engineering and mathematical functions to visually create a continuous state simulation, such as the flight path of a ballistic missile. These functions are encapsulated into visual boxes on the screen. You wire these boxes together to create a flow of data. VisSim lets you extend its language by writing DLLs that translate into additional screen boxes, and you can generate C code from the simulation and compile it to run in stand-alone or embedded applications.
Physically, these visual models bear no resemblance to the actual or proposed system. What they do is represent an important aspect of the system, such as the flow of data or control. Rather than being static,
these tools can also simulate that aspect, helping the designer to see whether or not the design works and to make adjustments based on the simulated results.
My own experience with visual languages falls into this category. Seeking to simulate the transmission of packets on computer networks, I developed a visual toolkit for discrete event simulation. This toolkit, which works in conjunction with Visual Solutions' VisSim, provides a set of high-level visual boxes, such as a Queue and a Server, that represent major queuing functions. To create a simulation, you simply select the appropriate boxes from the menu, place them on the display, and use wire connectors to indicate the flow of packets in the simulation (see the screen). Other boxes let you generate random numbers and collect statistics.
Visual-Programming Activities
While you visually assemble the screen in Visual Basic, you still have to write some traditional code to operate the interface and to provide the necessary computational
engine for the application. Although this represents what might be the most popular form of visual programming today, perhaps the greatest potential resides in performing actual programming tasks through visual means.
Among the commercial applications falling into this category are Prograph International's Prograph, Novell's Visual AppBuilder (formerly Serius Developer), and Digitalk's Parts. With these applications, you are actually programming with visual expressions. Visual AppBuilder provides a number of high-level programming constructs, such as menus and menu items, windows, buttons, text and numbers, and pictures. To write a program, you position these constructs on the screen and connect outputs from one to inputs to others, depending on your flow of data or control. Each construct uses dialog boxes that allow you to define the activity that is performed when a particular event occurs.
Even this approach, however, cannot get entirely away from traditional programming. Visual AppBuilder l
ets you use C or Pascal to write your own constructs, which can then be compiled into your own customized visual library. This would probably be necessary for many customized applications. I was a beta tester for Serius Developer before the company was acquired by Novell, and while I liked the idea of programming visually, I found that I had to write several of my own objects in Pascal to create the kind of applications I wanted.
This type of visual programming works well for specialized tasks. Adept, from Symbologic, uses the concept of connecting visual objects together to produce expert systems. Screens, modules, and expert rules are created through the use of icons and dialog boxes. Some database tools, such as PowerBuilder, let you use objects to define database activities, such as database queries and even database files themselves.
These categories of visual-programming approaches are not mutually exclusive. Digitalk's Parts, for example, combines a sophisticated visual-interface builder
with object-oriented operations. Parts, based on Smalltalk/V, is truly object-oriented. You construct your user interface out of predefined objects and then connect them to other objects that define the activities of the user interface. For example, the multiplication button on a calculator user interface can be connected to a multiplication object that actually performs the work. Parts also gives you the ability to create your own visual components and to inherit characteristics from existing components.
Given the power of this object-oriented visual approach, it is likely that the other tools described here, such as Visual Basic, will grow in this direction. Increasingly, users need to decouple an object from the underlying operating environment and share it across applications and systems. Object extension and inheritance will likely make their way into even the interface builders.
The question remains as to whether visual languages can be used in large-scale software development efforts. On
e corporate user of Easel Corp.'s Easel told me that its visual environment became hopelessly complex after about 300 objects. Visual languages that interact with existing technologies may turn out to be the most useful solution. For example, Parts lets programmers encapsulate existing Cobol code as a Parts object, allowing them to abstract an existing engine and visually extend it to include a GUI and other functions.
So What is Truly a Visual Language?
While purists may argue over whether any of these methods are truly visual languages, there is no refuting their utility. Few people deny that Visual Basic and similar tools are worthwhile for at least prototyping and, as the tools get better and computers get faster, for actually delivering production applications.
Programming with visual expressions excites many people as possibly being the future of programming in general. Parts and AppBuilder both support the emerging design and development methodology known as JAD/RAD (Joint Application
Design/Rapid Application Design). With this methodology, members of a small team of users interact in very specified roles to decide exactly what they want in an application, which can often be produced as they watch.
One caution that must be heeded while working with any of these tools is that they constrain the user to view a program in a particular way, as I noted earlier with regard to Visual Basic. This is not necessarily a bad thing; we can certainly use more user-centered programs like the ones produced by Visual Basic.
But a form with user-interface gadgets steers you into thinking about an application as one screen at a time, which may not always be appropriate. Parts and Visual AppBuilder provide a somewhat different perspective, focusing on the interrelationship between the user interface and the resulting program activities.
The products mentioned here are by no means the only ones that support some aspect of visual programming. Others include GUIdance Technologies' Choreograp
her, Easel's Enfin, and Computer Associates' CA-Realizer. Many traditional programming tools, such as Borland C++, are beginning to adopt many of these visual principles. The visual approach to programming is clearly an emerging technology that promises to make systems and software designers more productive and make software development activities accessible to more people.
Illustration: An example of the author's visual toolkit at work inside VisSim. On display is the simulation of a multiple-queue, single-server system.
Peter D. Varhol is chair of the graduate computer science department at Rivier College (Nashua, NH). You can contact him on the Internet or BIX
at
pvarhol@bix.com
.
Visual Programming's Many Faces
