Computer-Aided Software Engineering, CASE, is no longer the hottest topic in software and applications development. Even the vendors of CASE tools are retitling their products, calling them “integrated development environments” or just “tool suites.” Whatever they are called, the development tools we use or fail to use can have a lot to do with what we accomplish as developers.
I happen to be a strong proponent of tools. Admittedly, many of those available today are relatively primitive, often misconceived systems produced by misguided tool vendors who neither understand nor use the software engineering methodologies their tools support. Still, they can be effective tools in much the same way that a stone ax beats bare hands for felling trees.
Not surprisingly, you often hear something like this: “We don't have time to use CASE; we have a deadline to meet.” Some of these protesters are the same programmers, now balding or graying, who resisted higher level languages. They probably never flow chart or draw a data flow diagram and will insist that they, unlike us ordinary mortals, can keep track of everything in their heads. On the other hand, many critics of CASE tools really do try to practice some kind of reasonable design and development discipline. Unfortunately, many of the CASE tools, rather than helping the process of methodical problem solving or creative engineering, actually hinder it.
What's wrong with this picture? You see a high-salary software engineer, in an office with a six-thousand-dollar workstation, running a twelve-thousand-dollar CASE tool, and he's drawing on his desk pad, making notes on a yellow tablet of recycled notepaper. Finally, after much crossing out, erasing, and redrawing, he puts mitt to mouse and begins to enter what he's worked out, effectively reducing the sophisticated tool suite on his workstation to an elaborate electronic drafting board.
What's wrong is this: Rather than working with the software engineer and how engineers think, the tool is probably working against him. Instead of supporting natural ability and the habits sharpened through training, the CASE tool is interfering with them. To understand the exact nature of this failure, we need to look at how people, especially engineer-type people, solve problems.
We know, for example, that many of the better software engineers, analysts, and designers do their finest work by sketching out a broad-brushed picture of what they want to do, then going back to fill in details or elaborate. Look over the shoulder of such a problem solver and watch what she does. She might start a design by drawing a whole collection of component symbols. Then she begins to fill in the relationships among some of these blank boxes, drawing lines and arrows among them. Finally, she labels the components and specifies some details of the interconnections.
What about typical CASE tools? In many of them, you select a diagram symbol with the mouse from a collection of icons, position the cursor, again with the mouse, where you want the symbol to appear in the diagram being developed, and then click to drop the symbol in place. At this point, a dialogue box opens up and asks you to name the thing, which you must do in compliance with whatever general and corporate standards are being enforced for the naming of such symbols. Next you are called on to describe it, specify its interfaces, and maybe choose among several variants. Only after all this is completed in conformance with the syntax checking in force are you allowed to return to the drawing. By this time you have probably forgotten what you earlier knew you were going to do next. Worse, the general conception of the content and structure of the problem that seemed so clear when you reached for the mouse is now lost, erased from your mental map by the CASE tool's preoccupation with distracting details.
All engineering is trade-offs. There is research going back over thirty years showing that more effective engineers typically compare two or more alternative approaches to each significant design problem. This strategy applies just as well to software engineering as to our older sister professions. (My thesis at M.I.T. was on just this subject.) The comparison between alternative approaches may be quick and mostly mental, or it may involve elaborate description and modeling of each alternative, with careful analysis and evaluation of the consequences. A clear winning strategy may emerge, but sometimes what is chosen is a creative synthesis of more than one alternative, sometimes a compromise. The essential part of the process is the weighing of alternatives, being able to eyeball two designs or interpretations side-by-side. Current CASE tools do not, for the most part, support having two versions of the same system, diagram, or model simultaneously active and accessible, certainly not for side-by-side comparisons.
I've seen some pretty clever subterfuges used to get around this limitation of CASE tools. At one firm, a systems analyst had two workstations in his office, one processing a dummy project record, so that he could keep two full-fledged versions of the same systems design in front of him to analyze their advantages and disadvantages. More commonly, one of the alternatives is on paper, the other in the CASE repository.
Here's a scenario you may have seen or acted out yourself. The software engineer using a CASE tool tells the tool to print or plot one model of the system being designed, perhaps a data flow diagram, runs down the hall to the print server and retrieves the output, then returns to the office to call up another model of the same system, maybe a structure chart. The software engineer then keeps going back and forth between the model on the screen and the one on the paper.
Even the so-called “integrated” CASE “tool suites” do not generally support simple, rapid shifting among alternative views or models of the same system-in-progress. It should be at most a keystroke between views. Better yet would be true, side-by-side comparison. And windows just don't quite cut it. By the time you have two windows up in a CASE tool that operates in a windowed mode or environment, there isn't enough screen left to actually see anything useful. Either you get a little peek at a small part of each diagram, or you get an overview of tiny, unreadable symbols and text. Hardly a computer aid to software engineering!
Among the worst offenders in interfering with the thought processes of software developers are some of the more advanced tools, such as the context-sensitive program editors that do syntax checking on entry, or the CASE tools that support and enforce a software development “methodology” by constraining the CASE user to entering only proper diagrams and descriptions in precisely the order defined by some definitive text by some definitive methodology guru.
In the early days of computer-supported word processing, spell-checkers were separate programs, so slow and inefficient that you never checked a document more than absolutely necessary, and often you “forgot.” But, the computers and the search techniques got faster. Spell-checkers were integrated with the word processors. Pretty soon some programmer with time on his hands thought of doing spell-checking “on-the-fly,” as words were actually being entered. After all, during text entry, the processor is idle most of the time anyway, and the lookup can proceed, letter by letter, between keystrokes. Clever idea, right? Wrong!
If you have ever used a word processor or electronic typewriter with a real-time spell-checker, you know. The little gremlin is constantly interrupting to tell you about some alleged misspelling, popping up like an over-eager puppy or beeping liking a bar-code scanner at the grocery checkout. Even when it is right and you're wrong, you don't care, you just want to get your thoughts on paper without being interrupted by the mishuganah spell-checking smarty.
One of the rules of the simple but powerful technique of brainstorming is that no one is allowed to criticize or comment on any idea until the entire process is completed and all ideas are on the table. Separating the process of creation from the process of evaluation improves problem solving.
A CASE tool that fits with how people think would not criticize while you are creating. In fact, it would allow you to draw and specify all sorts of things that “aren't proper” because these “framebreaking” departures from the rules are often crucial steps along the way to finding better solutions. And it would allow you to depart from the prescribed sequence for entering things, because the “methodologies” in the books are not necessarily the last word on software engineering. (In fact, many methodologies are really quite wrong in terms of human problem solving, but that's another subject.)
Should we abandon hope and leave the CASE tools on the shelf? No, there's still hope. Present-day CASE tools are the primitive precursors of the tools we really need. They'll evolve.
It's a little like the early word processing programs, such as Electric Pencil or the first versions of WordStar. By today's standards of functionality and convenience, they were not much. You had to wait for minutes to go between one end of a document and another, the keystrokes to accomplish common tasks were obscure and complicated, and format control was limited, but they were so very much better than handwriting on foolscap or typing and retyping and retyping.
Besides, some of those who create CASE tools may be listening.
From Computer Language Magazine, Volume 9, #1, January 1992.