Warnier/Orr Program Design Tutorial
© Copyright 1990-2002 by Dave Higgins. All rights reserved.

This tutorial on the Warnier/Orr Data Structured Program Design methodology was originally written with the assumption that the reader would be using the Warnier/Orr diagrammer Brackets® , an outlining program with the capability of generating COBOL programs from completed designs. Brackets is a registered trademark of TLA Systems and Education, LTD, and for more information see their web site at www.brackets.com. In addition to generating COBOL, Brackets also generates C, Java as well as Microsoft Word® and Microsoft PowerPoint® compatible file formats. While Brackets has the ability to generate other languages, no C or Java examples are included in this tutorial at this time.

Although originally written for a COBOL audience, the program design concepts presented in the following tutorial apply to all languages.

Section 1: Introduction 

Why Program Design? 
Traditional programs are created by an intuitively iterative process. The programmer begins by coding a rough draft of the program and completes it by gradually refining it little by little until it is done (meaning that the programmer can no longer find any obvious errors).

Unfortunately, this seat-of-the-pants programming method has its drawbacks. First and foremost, it tends to generate bad programs: i.e., programs that do not work correctly (they have bugs) and that are hard to modify. It also leads to wildly different programming styles, making communication between different programmers difficult at best. It generates little or no documentation as a by-product of the development process. And, it simply fails when applied to problems more complex than the programmer's intuition.

Since no reputable programmer ever intentionally creates a bad program, we must conclude that it is the traditional programming process responsible for bad programs, not the programmer.

The Warnier/Orr systems development methodology (also known as DSSD: Data Structured Systems Development) was developed in part to address these problems. Although the methodology covers all facets of system development from Planning to Installation, the portion which concerns us in this tutorial is called Data Structured Program Design (DSPD). It comprises only a small part of the entire Warnier/Orr methodology.

Much of DSPD can be traced to the work of the late French researcher Jean-Dominique Warnier, who created a method called LCP (Logical Construction of Programs) in the late 1960's. Warnier's diagraming tool and many of his ideas on data structured programming were championed in the English-speaking world by Ken Orr. The DSPD method you are about to learn about is a hybrid method based on ideas from Warnier, Orr, Dave Higgins, Kirk Hansen, and many other developers around the world. The method incorporates many different ideas, all of which have a common thread: they are practical, proven ideas that work in the average programming environment.

Design vs. Construction 
All responsible engineering professions make a distinction between design and construction. A design is always created first, and it defines what is to be constructed. This is so for many reasons. One reason is cost: it is much less expensive to change a feature in the design rather than change the real-world feature to which it corresponds. Another reason is quality: there are simply too many things which might be left out or assembled incorrectly if there is no design to guide the construction. Many of these design features are critical enough that the failure of a single component can cause the catastrophic failure of the entire construction.

The same is true of programming. Writing code without working from a design is working without a net, and leaves the programmer helpless against massive cost overruns as new requirements become known. And like engineering it leaves them open the very real possibility of a catastrophic failure. (While many programmers do not tend to take program "bugs" very seriously, it should be pointed out that "bugs" in financial systems have caused company failures, and "bugs" in avionics systems have cost human lives.)

Therefore DSPD stresses very strongly the need for design before construction, and the bulk of the method involves the creation of correct and maintainable designs.

This is especially true if you are using Brackets to create COBOL programs. The designs which are created will begin at a very high level, and more and more layers of detail are added as the design progresses. When the design is complete, Brackets has the ability to automatically translate the design into COBOL code. And, although it is not a compiler, Brackets has some built in features which help you locate mistakes in the design: if, for instance, your COBOL compiler tells you that you have a mistake on line 237 of your generated program, you can use the "search" option in Brackets to locate the design feature that generated line 237.

One of the very nice features of Brackets is that the design and the code never get out of sync. Anytime there is a change to the program, the design can be updated and the code can be regenerated.

In practice when using Brackets, there is very little reason to look at the actual COBOL code which is generated; nearly everything you need to do to create, debug, and modify code can be done directly in Brackets.