Is CASE dead? Various among the pontiffs of programming have declared the death, but for every mourner there is an optimistic resurrectionist, for every detractor, a jubilant convert. Guided by this zeitgeist, in 1994 the Australian Computer Society assembled in Melbourne two stellar teams of Aussie consultants and practitioners led by supporter Graeme Simsion and skeptic Rob Thomsett. “The great CASE debate,” as it was styled, argued the pros and cons of the question “Is there a case for CASE in Australia?” The debate proved to be a big event for the Victorian ACS, outdrawing the book launching by a former prime minister held in the same hall earlier that day. For reasons unknown, I had been recruited to round out the negative team. Thomsett, described by Simsion as Australia's most feral consultant, guided our team to victory, although both sides finished on notes of suspiciously similar pitch.
Rumors of the imminent interment of CASE are disturbing indeed, since CASE is no more than computer-aided software engineering. Is it that computers have ceased their aid? Or is it software engineering that has died? Neither, we hope. CASE is not dead and not doomed, although it may be distinctly déclassé. In the never-ending propensity of industry pundits to euphemize or eulogize what they once elevated to sainthood, CASE is out and “integrated development environments” are in. Or at least they were last month.
Certainly part of the problem has been unreasonable expectations sparked by the hype of software vendors mixed with the hopes of wishful thinkers. With nearly everyone in our business forever in search of a code-cutting Excalibur, the keenest of real tools will always disappoint. Part of the problem is that the developers and vendors of CASE tools have often understood neither models and modeling nor the methods their tools purport to support. Even more to the point, CASE tools are simply not what is really needed to speed and refine development. What is needed is both more and less than what most CASE tools provide. We need to look to visual development environments to understand what CASE should have been and may yet become.
Visual development environments comprise one of the most colorful and energetic strands in the skein of contemporary development practices and products. Visual development refers to a variety of tools and approaches that allow developers to generate code by direct manipulation of visual objects on a graphical user interface. The oldest and best known of this genre is Microsoft's Visual Basic. Later products, for example, IBM's VisualAge and Borland's Delphi, began to hint at the full potential of what visual development could someday become. Although most such products were originally aimed principally at applications developers, the visual development paradigm may be in everybody's future.
Visual development software is just technology, but technology that could dramatically alter how software developers work. In its purest form, visual development allows you to create complete working systems largely or exclusively by moving visible objects around on your monitor screen. Direct manipulation of graphical elements is an obvious approach for designing GUIs, and that is just where visual development began—with so-called GUI builders. The problem with many of the earliest tools was that once you dropped beneath the slick GUI surface, what you ran into was some of the ugliest Basic or messiest C++ ever conceived, all spread around in an undisciplined clutter behind the screen. You had to wallow around a lot in this muck to get anything significant to actually work.
When the systems under construction become really complex, developers begin to long for the ability to build models at higher levels of abstraction, to represent and review the architecture of the system, not just the actual construction and not just the surface manifestations at the user interface. What you want is to make the programming units and their relationships visual as well. You want to be able to see the modules, the classes and objects, and the messages and references that interconnect them. You want to be able to see the structure of your code based on familiar notation and move through it using what J. D. Hildebrand has called a visual browser (Hildebrand 1994). You want to be able to send a message from here to there by drawing a line or to be able to move a method from one class to another by a drag-and-drop. In effect, you want a continuously active CASE tool with code conversion built in dynamically so that whatever you do in pictures is immediately reflected in code. And vice versa.
In other words, you want a truly integrated visual development environment, the convergence of CASE and WYSIWYG applications builders resulting from the continued addition of CASE-like capability to application development environments and from the tighter integration of GUI building and code generation within CASE tools. VisualAge represents the trend toward direct modeling in application builders, already allowing you to draw lines to interconnect GUI objects as well as nonvisible objects that lurk behind the scenes. On the more vanilla CASE side of things, tools like Together C++ keep the implementation model—the code—and the design models—the diagrams—in synch.
Instead of code-generation as something apart from model building and graphics design, a true visual development environment would maintain the visible features of a system (the GUI), the visualized architecture (the analysis and design diagrams), and the underlying code in perfect synch, so that the developer can move smoothly back and forth between design and implementation models, speaking in code or in pictures as fits the problem and priorities or the mood of the moment. This would carry development tools a lot closer to how humans solve problems. People typically think in both words and pictures and bounce back and forth between the clarity of higher-level abstractions and the dirty grit of solution details. (See also Chapter 18.)
Visual development in this fullest form is a significant new paradigm for the relationship between programmers and computers. Potentially it allows analysts and designers to use the same mental and manual skills to describe a problem, design a solution, and construct the system. That may sound like a return to yesteryear, when code was designed by writing code, but in this case, designs could become coded simply by designing. The real difference in the newer paradigm is that visual development allows the creation and manipulation to take place at a higher level, in bigger chunks, with more visible connections and consequences. It can literally allow you to see where you are, what you are doing, and how it all fits into the larger scheme of the system under construction.
Visual development allows thinking to take place in two modes simultaneously—one being the analytical, sequential reasoning mode that goes with using language and expressing processes in code, the other being the visual-spatial mode that is invoked when we draw pictures or build things with Legos or try to figure out a diagram. Visual programming is, thus, like a CPU upgrade to your brain, increasing your mental processing power and allowing you to tackle larger problems or build systems faster.
Visual development environments also hold the potential for changing how development proceeds. Promoters of object technology say it enables a “seamless” development process, in large part because the same concepts and vocabulary that are used to describe a problem and to interact with users and clients are also used to design and to express the software solution. It's all just objects. Delivery on this promise is another matter, however, and traditional object-oriented development tools have not in themselves been all that seamless. The combination of visual development with object-oriented design and programming may finally turn the trick. Not only do you get to accomplish the whole task through direct manipulation of objects, but the coming generation of tools may allow you to restructure and extend the tools themselves using the same visual programming methods you use to build applications.
Instead of seeing CASE in a coffin, maybe it's a matter of visualizing development.
From Software Development, Volume 3, #5, May 1995.