Michael is a senior computer scientist at Computer Sciences Corporation and can be reached at 27911 Berwick Drive, Carmel, CA 93923-8518.
For many programmers and software engineers, the thought of using CASE tools conjures up nightmares of large teams of programmers working on massive defense department projects for years on end. While there's been some truth to this in the past, primarily because of the cost, CASE tools are becoming available that provide the functionality needed for big projects at the cost of a good PC compiler.
Moreover, most engineers assume that the only time to begin using a CASE tool is in a project's design stage -- once coding begins, there really isn't any need for design tools, and if there is, it's too late to go back. This article presents a contrary view by describing a project in which design considerations and CASE tools entered the picture only after the coding was well underway and the product was looking like something no one wanted.
The project began as an effort to acquire a computer-based vertical application to provide information on the availability of rental housing using voice-text (similar to voice mail) technology. I signed on as the firm's tech weenie, primarily to keep the principles from getting fleeced by fast-talking vendors and, where appropriate, to provide technical guidance.
My two clients were quite capable in their own fields. One had extensive experience in property management and in running a Watson-based computerized rental-housing information service; the other had run a successful service business. My role was to help them select and manage the vendor who would actually produce the system. For all practical purposes, I was to act as the technical intermediary between my clients and an undetermined contractor (the vendor).
The vendor we selected was a small firm that had already developed and installed a rental hotline. While this system addressed the correct market, it was considerably different, and much less comprehensive, than the system we had in mind. Nevertheless, we signed with the vendor on the understanding that these differences would be worked out and that we would receive an improved version which would meet the standards we had set.
As the project progressed, it became apparent that the vendor was not moving in the direction we wanted, but was driven by either ease-of-implementation concerns or a lack of content knowledge. My clients' efforts to redirect the project were frustrating at best, so I decided to break the impasse by going back to first principles. (Isn't that what we all do when we find that winging it just doesn't work as well as we had hoped?)
At that point, we took stock of what we had, what we wanted, and what it would take to achieve it. Clearly, we did not yet have software anywhere close to a usable system, and the vendor did not appear capable of understanding how to build it. We reviewed our goals, limiting the scope of the project to "the acquisition of an efficient and easily maintained system which would provide relatively unsophisticated users with continuously updated voice-text information about the availability of rental housing, meeting their specific requirements through a 900/800 touch-tone telephone service."
Having clarified the scope, we now needed some way of specifying how the vendor should implement the system in terms that all parties (client and vendor) could understand. We had tried pseudocode and notes pointing out differences between what the vendor had done and want we wanted, but to no avail. The client wasn't well enough versed to understand pseudocode and the vendor clearly did not understand the context of the application.
I decided that EasyCase Plus, a PC-based CASE tool I had used in past projects, would provide the Rosetta stone I needed to bridge the gap between the two sides.
First I had to extract from my clients a mental picture of how the system would work. Next, this picture had to be refined to eliminate any impossible or outlandishly expensive features. I based these limitations upon an educated hunch of what things were possible within the current technology. It was my responsibility to transform this mental picture into a physical representation, which depicted how the pieces they understood fitted together, using concepts familiar to my clients. In the process, my clients had to learn to be much more rigorous in considering features of the system and the interaction among those features.
Once we were satisfied with the specification, I had to hand it over to the vendor and ensure that he truly understood it, educating him in the "design" process as well. This turned out to be a difficult task, because the vendor was apparently unfamiliar with the most basic principles of software engineering. He preferred to be told what was wrong in one specific place so he could fix that, then go on to the next, rather than attempt to embrace the overall flow and structure of the system all at once.
My role in this process was analogous to an architect's when you ask to have a house designed and built for you. The tasks of explanation, specification, reflection, analysis, design, approval, implementation, and acceptance are present in both software system development and housing construction. In order to relate the specifications of the client's dream to the builder in a language he could understand, I became the software architect.
The system consisted of a finite-state machine in which the states are voice messages and the transitions between states are accomplished by pressing the keys on the phone (events). The most appropriate graphic representation is a State Transition Diagram (STD), which is supported by the EasyCase tool. Unlike other CASE diagram representations, the STD is fairly simple, consisting of only one kind of box (states) and their interconnecting lines (transitions).
To make this work, each of the states (messages) we knew about was defined independently of the others. The state was placed on the diagram (see Figure 1), named, and described to the data dictionary; the text associated with that state was entered into an "explosion" of its identified box. (Exploding is the ability to link an object on a diagram to another diagram type.) EasyCase provides a facility to link text files to chart objects within its structures and provides easy access to an editor to create and modify that text. To gild the lily, we could have stored actual voice text and linked it to the chart object, rather like the "blob" capability of some database systems, but that would have required a separate voice-text editor with audio cut and paste.
Reviewing the states was illuminating for all of us. States which either we thought or the vendor indicated were absolutely mandatory turned out to be superfluous when placed along side of the others. States were rapidly merged, split, added, and deleted as needed. Late recognition of certain mandatory legal requirements added several extremely verbose states, which, in turn, required additional states to allow the user the option to skip the legalese. After all, the user of the system was going to be billed in increments of one tenth of a minute. The text of the messages was revised over and over to achieve a high level of vocabulary and syntax consistency. The bulk of the effort in this phase was directed toward reducing both the number and the complexity of the words used. (We even found a nonpracticing lawyer who was capable of compressing and simplifying text, rather than expanding and opacifying it!)
Once, most of the states had been defined, the next task was to specify the interconnections (transitions) among the boxes (states) on the diagram. For STDs, the interconnection is fairly simple: "On this key-press, go to this box unconditionally." What was difficult was not selecting which keys did what, but specifying an easily remembered, consistent pattern of key usage that would make sense to the users. After all of the effort invested in making the text consistent, it would be foolish to overlook this critical area. While the vendor had provided at least two different patterns of transition, each context sensitive, it was imperative that we have only one. States had to transition to other states in a smooth, predictable fashion, to make the system seem as though it were produced by one hand rather than from a collection of unrelated pieces.
The specification of the transitions was more complex than we had anticipated. It was necessary to predict all the actions, including inactions, that a user would want to take while in a given state. Some states, for example, supplied only information and, upon conclusion, flowed directly into another state. Other states offered menus of keys, which upon pressing a particular key transferred to another state. Additionally, we had to decide what to do should the user not press a key from among those offered within a given period of time. The system had to have some way to remind the user of his choices, should he forget.
The STD could have been broken neatly into two pieces: the top half taking care of the introduction, instructions, and legal requirements, and the bottom half providing the information the user was paying for. Curiously, the amount of effort in defining states and transitions was almost exactly opposite for the two halves. The top half had few complex transitions and huge amounts of invariant text, while the bottom half had little invariant text, many menu-based transitions, and a tree of variable-length lists containing voice text of the listings users wanted to hear.
This last part, the tree of variable-length lists, seemed at odds with the overall structure. Traditionally, STDs do not contain recursive structures. The structure was a simple hierarchy with divisions for house/apartment, number of bedrooms, location, and price. I was convinced that a hierarchical structuring of the stored data was correct. Reviewing several texts got me nowhere. The flexibility of EasyCase gave me an out. I could place the "off-chart" connectors, normally reserved for linking different diagrams together, inside the box representing the "tree," and use the tool's exploding capability to hide this complexity. Inside this box was a hierarchy of STDs providing all of the branches and levels, along with their associated menuing text.
This use of off-chart connectors was extremely helpful and very painful. EasyCase allowed the easy disconnection and rerouting of the transitions and even the movement of the endpoints, except for off-chart connectors. This bug has since been fixed, but it required the manual removal and reinstallation of the connectors each of the many times the box was moved. In spite of the extra work this "feature" caused, however, I believed that this was the correct structuring mechanism and forced the tool to work as I wanted it to.
At first blush, this doesn't seem to be much of a breakthrough, but it pushed the recursive nature of the menus governing the tree directly into the vendor's view. In all of the earlier discussions, the vendor had kept focusing on the tree, seeing it as a relatively flat data structure; we had drawn it out to five levels deep with between three and eight branches at each level, linking the listings describing the various properties on the terminal nodes of the tree. On the primary STD, only one box appears for the entire tree, decoupling the data from the overall system structure.
The organization of the data tree was developed by my clients totally on their own. They selected all the levels and branches based upon their educated intuition of how users would cut up the world of rental housing. Certain divisions were obvious at the start; others became obvious only after considerable research and reflection.
At this point, the system was completed -- at least on paper. Now was the time to sell it back to the vendor. We believed that the reorganization and respecification had improved the product considerably by making it much more general and easily supported. The vendor, however, disagreed. At first he refused to look at the diagram, requesting instead that each change be described separately. We balked at this, insisting that only by looking at the changes within the context of the whole system could we be certain that errors were not introduced elsewhere. He relented after we gave examples of errors which had already been introduced in the process of "correction."
The vendor expressed concern that this representation of the system could conceal errors of our own making: "States could be left either undefined or unconnected to other states," he said. Using EasyCase's analysis capability, I verified that all of the states we had defined were active, noted the states that had been deleted, and cataloged all of the transitions. The thoroughness of the tool in noting inconsistencies quieted his concern. The remainder of the changes were installed and, by the time this article is published, the system will have been running for two months. Its completion was six months late, but we got the system the clients really wanted.
EasyCase Plus Evergreen CASE Tools 16710 N.E. 79th Street Suite 105 Redmond, WA 98052 206-881-5149 Version 2: $295 Professional Pack: $395 System Requirements: IBM PC with 640K RAM mouse, Hercules/EGA/VGA
What was learned from this effort? First, it is always dangerous to assume that what works in one arena can be made to work in another. Things unplanned take longer than things planned. Good design makes for good products. These are all reasonable conclusions, but the important lesson I learned from the project, painfully at that, is that it's never too late to begin using structured techniques and tools, even if it means going back a step to accommodate the effort.
Although they are incredibly helpful (I would not go through this effort again without a tool like EasyCase), tools alone are not the answer. As the EasyCase manual warns:
"It is important to remember that a CASE tool is not a "magical" solution to perfect, on-time, on-budget system development. What is important is a firm understanding of structured development methods and their advantages, disadvantages, and limitations. CASE simply provides a means of automating the structured development life cycle.
In fact, it is highly likely that a system that has been badly designed using traditional unstructured or even nonautomated, structured methods will also be badly designed using a CASE tool. The only advantage here is that inherent disasters may become apparent sooner, perhaps enabling a system redefinition or redesign before it is too late.
In other words, if you do not know how to properly (with regard to budgets, schedule, quality, meeting customer requirements, etc.) develop a system prior to using a CASE tool, you will most likely be unable to develop a system properly using a CASE tool.
Tools, coupled with an understanding of the process of system development, can produce specifications which represent not only the client's intents made concrete, but a working set of blueprints for a contractor and his journeyman programmers. Such use of tools, combined with intensive client involvement and rigor of specification, characterizes the endeavor of the software architect.
Copyright © 1991, Dr. Dobb's Journal