Louis Barnett is president of MetaLogic Corporation, a 10-year-old microsystems consulting firm specializing in a variety of fields. He has been involved in microcomputers since the early '70s. Contact Louis at 3566 Vigilance Dr., Rancho Palos Verdes, CA 90274 (213) 544-1278.
A system developer's job description should include a sentence about bringing order out of chaos and complexity. Even though some popular CASE (Computer Aided Systems Engineering) tools are genuinely useful, the CASE approach is often more useful at promoting a processor methodology — and producing methodology-specific diagrams — than at producing results.
Choosing A Case Tool
Frequently, design methodologies break down when they are stresstested with large scale, complex problems (read "real-world"). Perhaps the methodology isn't quite flexible enough to let you model your system the way it should be. Perhaps the final result is increasingly obscure output. The bottom line is that many CASE tools, techniques and methodologies get in the way of clear thinking.Therefore, I have developed a simple set of standards to help me judge whether a particular approach is useful to me. When I evaluate a tool, I ask:
There are other criteria, but these questions seem to me to be the most relevant.
- Is it easy to learn and apply?
- Does it enhance the expression of my ideas; does it help me express them more succinctly, clearly and accurately?
- Does the methodology adapt to my evolving understanding of a problem? It shouldn't break down or become cumbersome as complexity increases.
- Does it complement other techniques with which I have become comfortable — is there a net gain?
- Are the end results better than those possible by other means? That is, are the results more complete, robust and reliable?
Action Diagrams
I discovered action diagrams some time ago. They satisfy the five criteria listed above, and I've used them in my consulting practice with excellent results. So let me tell you what action diagrams are, and why they have worked well for me.At first glance, action diagrams are simply outlines with brackets (see Figure 1) . Beyond that, though, I believe they are a language that promotes more effective and efficient thinking. Action diagrams will help you organize and structure your thinking — something that's critical when you're confronted with new and complex problems. Put another way, action diagrams are a language for talking about and modeling systems.
A closer look at Figure 1 shows an algorithm for a topological sort in action diagram format. Notice that comments, preceded by *, serve the usual purpose of explaining what is going on. The single line brackets (also called control brackets) delimit the entire algorithm, the initialization section, and the algorithm itself. This major categorization serves to clarify the organization of the diagram by grouping related details.
Within the initialization bracket you see a double-lined bracket that represents iteration. In this case, the steps within the bracket's scope are performed for each ordered pair in the input, analogous to a for loop in C. Once the loop terminates, a single sequential action is performed.
The final section, in which the topological sort order is actually constructed, relies predictably on nested loops and includes a conditional If statement.
There are several lessons here. First, the algorithm is clearly and concisely described in a language-independent fashion. The logic of the algorithm is easy to follow thanks to the control structure brackets; action diagrams are very visual. Finally, action diagrams aren't hard to create; they're succinct, high-level aids to structured programming.
Action diagrams are typically created by building up layers of detail, using the brackets to signify logical groupings, repetition and decisions. As the diagram evolves, lower levels of detail can be nested within higher level control brackets.
My action diagrammer program inserts control brackets for the standard control structures into a diagram. The program can also stretch the brackets to enclose other structures, or delete, copy and move brackets, along with everything that is contained within their scope. Additionally, I can define my own language (C, Modula, structured English, etc.) to correspond to the bracket styles. Illustrations of the various bracket styles using C as the design language are found in Figure 2.
What isn't obvious from Figure 1 is the ease with which it was constructed using an automated action diagrammer. The one I use (called Action Designer, which I wrote) allows me to view my work at any level of detail with just a few keystrokes. That is, I can hide or display the diagram at the desired level of detail. It works like a special outline processor, one that knows the rules of structured design and programming. As you can probaly guess, I can also insert, delete and modify control brackets as needed.
From Concept To Code
Going a step further, suppose that I need to design some functions to implement queues (called for in the sort) in C. I could do this as an extension of the sort diagram, but I'll show it as a separate diagram for clarity.No matter what programming language I use, the first step is to specify and design the algorithm (Figure 3) . My first cut is very clean. Keeping things simple and high level, I define the general method and data structures. I defer the implementation details until I'm ready to describe them.
Now, I'd like to proceed from design to code in smooth steps, adding detail incrementally (Figure 4) . As you can see, I've used C programming constructs instead of the more generic English of Figure 1.
At this level, coding proceeds pretty much as it would without the diagram — with an important exception. As I work, I'm able to suppress lower-level detail to examine the design or to print the specification only (Figure 5) . The view from Figure 5 is helpful in two ways: I can always collapse the diagram to figure out where I am and where I want to be. Such a view essentially comprises the program's external (printed) documentation. It should be obvious that action diagrams and C go well together since they share the same highly structured notation.
In Figure 6, I have embedded the design in the finished code. In fact, my internal (embedded) documentation and external documentation are always consistent — change the program and you can immediately generate up-to-date documentation. This may be one of the most important benefits of action diagrams. Can you cite many examples of internal and external (if it exists) documentation being up-to-date and consistent?
To generate the code, the brackets are stripped from the diagram, generic comments are converted to programming comments, and since everything else is programming code, the result is compilable code. An automated action diagrammer lets me do all that.
The Payoff
How did the action diagram help? Well, I was able to design top down and implement incrementally. That is, I started with the program's overall design as a general framework and then coded incrementally — modularly, if you prefer. I didn't feel restricted to programming in a linear fashion. In other words, I jumped around. I was able to move back and forth between high and low levels of detail as needed. Furthermore, if I need to explain my program to either a potential client or a colleague, I can collapse the diagram to the appropriate level of detail.Action diagrams help in another way. If my diagrammer is set up for the programming language that I use, then it will always insert proper control structures. In C, for example, braces will always be balanced. Action diagrams can help enforce structured design and programming rules.
These advantages may not seem to be particularly relevant for small tasks. But remember that the specification and design phases of most large projects comprise one third to one half of the project life cycle. A good portion of this time is typically spent going over what has been done and still needs to be done. Then a lot of effort is expended converting what has been written for analysts and users into something that programmers need. Well, that's the way it is supposed to work. We know better. So, wouldn't it be smarter to use a tool like an action diagram to record specifications and designs and use them as the basis for coding?
In practice, I don't do all my coding using Action Designer. When I need to, I import code developed elsewhere. Usually, I use action diagrams to prepare specifications and designs. But action diagrams are also very effective in working out complex algorithms. I've also found them to be especially useful when I need to clarify a procedure or policy with a client. However, the end result is almost always a clearly written and documented program — and one that's easy to maintain.
Future Directions
In spite of what I've said above, I'm no advocate of programming low-level code within an action diagrammer. Most programmers I know just don't work that way. However, some action diagramming software contains CASE-like enhancements that actually generate code from a specification. Others go beyond simple syntax checking and perform some correctness analysis.To ensure correctness, a diagrammer could incrementally validate process (function and procedure) inputs and outputs, build a data dictionary as coding proceeds and validate function and variable usage on the fly. It could ensure that function parameters and return values were used elsewhere in a type-safe manner. This isn't trivial, of course, but it's not impossible either.
To add an integrated ability to reuse code, simply establish hot links to a source code control system. Then, to use a proven piece of code, you would reference it in the diagram — just as library functions are referenced in C. Generating code directly from specifications requires a lot more work, but action diagrams could provide a suitable environment.
I'm extending Action Designer to facilitate hot linking code modules so that more flexible code generation will be possible. I'm also exploring other enhancements such as hyper links to support "hyper navigation" through related diagrams and reusable logic modules.
Action diagrams are not my only CASE tool; I also use data flow and state diagrams, structure charts, and other tools as required.
Available Tools
There are a few commercial action diagrammers. The one with which I am most familiar is Action Diagrammer from Database Design Inc., which sells for about $495. Other commercial diagrammers are available, but usually as only a small component of very large and expensive CASE systems. You can obtain the shareware version of Action Designer (for MS-DOS) on CompuServe in the Computer Languages (CLMFORUM) and IBM Applications (IBMAPP) forums and from BIX (SOFT.ENG).For more about action diagrams, I suggest you read Action Diagrams by James Martin and Carma McClure (Prentice-Hall).
Something For Everyone
Before closing, I'd like to point out that action diagrams aren't limited to programming. Database designers will find them useful in working out and documenting their data models. Management professionals can use action diagrams to design policies and procedures for their operations whether automated or not. Technical writers can use them to describe how to do almost anything. Even trainers will find them helpful in teaching complicated tasks.