It has been said that a picture is worth a thousand words, nowhere is that more true than in the design of computer systems. It's a known fact that almost everyone--programmer/analysts included--grasps concepts easier if they are presented in a graphical form instead of a textual one. This is the reason that all of the popular structured design methodologies are based upon diagrams.

This article is a buyer's guide of sorts. It's a buyer's guide that presents a brief explanation of 14 different diagramming techniques. The focus is on diagrams rather than the structured methodologies they are used in since many methodologies use the same diagramming techniques. This article is not meant to train you in any particular diagramming methodology, but simply to offer a brief introduction to available techniques, and their strengths and weaknesses.

In the past, diagramming techniques weren't a big part of the midrange programmer's life. With the advent of CASE and 4GL tools for the midrange, however, more and more midrange programming software is using some sort of diagramming technique. Also, as IBM's AD/Cycle becomes increasingly sophisticated on the AS/400, there will be an enlarging number of structured design products available. These products will also incorporate diagramming techniques.

The following list of diagramming methods begins with an illustrated sample of the diagram, followed by some key points about the diagram and then a brief explanation of the diagramming methodology. The key points are as follows:

* Level--the level of a design that a diagram is targeted at.

* Detailed--the diagram is meant to be used for a very detailed view of an activity; usually results in code.

* Overview--the diagram is meant to be used to create a general view of an activity; overview diagrams are usually a prelude to detailed diagrams.

* Scope--the type of activity a diagram is meant to convey.

* Data--a diagram is meant for the design of a file of database.

* Procedures--a diagram is intended for the design of systems or programs.

* Pros and Cons--a brief list of the advantages and disadvantages of a diagramming method.

These key points are not intended as the final word on a diagram. You will often see a detailed, data diagram used as an overview, procedures diagram. Programmer/analysts have a tendency to use what is familiar to them even if it doesn't exactly fit. The information listed is what the main intention of a diagramming method is, not necessarily how it is always used.

 Action Diagrams Level: Detailed Overview Scope: Data Procedures Pros: Easy to understand Easy to implement Covers all design phases Used in many CASE and 4GL products 

Cons:

Most diagramming techniques cover only one section of a design, either the high level system view or the low level program logic. Only a few, Warnier- Orr and Michael Jackson among them, allow for both levels of design. Even with these approaches, there are some areas that these techniques can't handle. Action diagrams were created as an answer to this problem. Action diagrams allow for all levels of design and are easily implemented in a computer-based system. Many midrange CASE products use action diagrams as their design methodology. Action diagrams are easy to learn and allow the programmer/analyst to learn just one technique to cover most types of design problems.

Action diagrams are composed of brackets which contain a series of actions to be performed. These brackets can contain other brackets. This allows a problem to be gradually decomposed from a high-level system view all the way down to a program code level. The idea behind action diagrams is that the low-level design of a system should be an extension of the high level, and not a completely separate process.

Data Flow Diagrams

 Level: Overview Scope: Data Pros: Easy to understand Widely used Cons: Large diagrams can be difficult to follow 

A data flow diagram (DFD) shows the flow of data through a particular set of processes. This is a common type of dependency diagram. At its highest level, a DFD shows the processes of an organization and the transactions that are generated by these processes. This higher level represents manual as well as computerized processes. At lower levels, a DFD can represent the flow of data through programs. There are two different diagramming methods used to represent DFDs. The first is the one used by the Yourdon and De Marco methodologies; the other is the notation used by the Gane and Sarson methodology. The Gane and Sarson notation is popular since its' number of diagramming symbols is more complete than the other notation.

DFDs are one of the most widely used diagramming techniques in structured design. Their main use should be to chart the flow of documents and data in complex systems, although sometimes they are used to represent the internal flow of programs. This should be avoided since other methodologies are much better suited to this task.

 Data Structure Diagrams Level: Detailed Scope: Data Pros: Widely used Cons: 

Most diagramming techniques represent data, if they represent it at all, in a hierarchical manner. This tree structure representation of data can lead to the data being shown redundantly and certain types of relationships not being shown at all. With the advent of normalized databases, it became necessary to have a diagramming technique exclusively for the design of databases. The basis of data structure diagrams are bubble charts which provide a way to represent the associations between data items. Data structure diagrams represent data at a low level of design.

Data structure diagrams show the relationships between data items. These relationships can be one-to-one, one-to-many and many-to-many. Other attributes that data structure diagrams show are optional data items, keys, data attributes, derived data and almost any other type of relationship or attribute of a modern database.

 Decision Trees and Decision Tables Level: Detailed Scope: Procedures Pros: Makes complex selection logic easier to understand Cons: Limited to specialized uses 

Decision trees and decision tables are not strictly a computer-related diagramming technique; they can be found in many other areas of science from biology to physics. A decision tree or table is a representation of a process where the value of a variable or a group of variables determines what specific action is to be taken. One of the newer programming tools available for Windows 3.0, ObjectVision, utilizes this method to control program logic.

Decision trees and tables are usually used to represent only complex conditional types of program logic. They can make certain sections of a program's logic much easier to understand, although they aren't really appropriate for the complete design of a program.

 Decomposition Diagrams Level: Detailed Overview Scope: Data Procedures Pros: Easy to understand Cons: Cumbersome for large projects 

The decomposition diagram is one of the most simple and basic diagrams in a programmer/analyst's tool box. This diagram allows a high level of function to be gradually decomposed. Each lower level of the diagram allows for a greater level of detail. An ideal example of this type of diagram is an organizational chart.

Structured design employs decomposition in almost all of its phases. In decomposition diagrams, each level is completely composed of the levels below it. In other words, each level contains the entire answer to a question--it's just that each level has a different amount of detail.

Decomposition diagrams can be used to represent organizational structures; the structure of an entire system; the structure of just one program; the organization of a database; or the structure of a report.

 Dependency Diagrams Level: Detailed Overview Scope: Data Procedures Pros: Easy to understand Cons: Cumbersome for large projects 

Dependency diagrams show how two processes depend on each other so that they both can complete their assigned tasks. In other words, process 1 must complete before process 2. There are three reasons that one process would depend on another process: First, is resource dependency. This is when process 1 creates or modifies a resource that process 2 requires. For example, a magazine can't be mailed (process 2) until it first has been printed (process 1). Second, is data dependency. This is when process 1 creates or modifies data that process 2 uses. A mailing label can't be printed (process 2) until the subscriber's information has been entered (process 1). Third, is constraint dependency. This is when process 2 is dependent on a constraint or condition that was set in process 1. This type of dependency should be avoided since it means that there is a direct link between the internal workings of process 1 and process 2. Good structured design should encapsulate the black box concept. That is, a process should function independently of other processes as long as the same data is passed to the process.

When dependency diagrams are used for data design, they are usually used to show an "if I have this I must have that" type of relationship. For example, if there is a detail line for an invoice there must be an associated header.

 Entity-Relationship Diagrams Level: Overview Scope: Data Pros: Widely used Cons: 

Entity-relationship diagrams represent the data of an organization at a high level. This data is represented as entities. Entities are things that we store data about, such as customers, subscribers, employees, almost anything in an organization. Entities-relationship diagrams are concerned with the concept, not the detail. They show the entities and how they interact with each other. These can get very large and complicated, depending upon the size and complexity of the organization.

Entity-relationship diagrams are composed of a set of rectangular boxes that represent the entities in an organization. These boxes are connected by lines indicating what type of link exists between the entities.

 Flowcharts Level: Detailed Overview Scope: Procedures Pros: Easy to understand Widely used Cons: Cumbersome on large projects Not structured 

Flowcharts are one of the oldest methods of diagramming programming logic. Long before structured methodologies were ever imagined, programmer analysts were producing page after page of program flowcharts. For many programmers, this is still the modus operandi. Flowcharts can represent two facets of a design: the system view and the program view. The system view shows how specific processes and entities interact with each other. For example, program A produces file B. This level of a flowchart shows the what, not the how. The program design flowchart shows the specific logic of an individual program. In other words--the how.

While flowcharts were once acceptable for program design, they just do not measure up to today's newer diagramming techniques. Since they are not a structured diagramming technique, flowcharts are difficult and cumbersome to maintain. Anyone who has used flowcharts for anything but a small project will likely agree.

HIPO Diagrams

Level: Detailed

Overview

Scope: Procedures

Pros: Easily understood

Cons: Cumbersome for large projects No built-in guidelines

Hierarchical Input-Process-Output (HIPO) diagrams show the input, output and processing of a system or program. HIPO diagrams can be used to represent a high level overview or detailed view of a system.

HIPO diagrams are composed of an input box, a process box and an output box. The input box is the left-hand box and represents the inputs to the process. This can be an entire file, a list of parameters, or a single field depending upon the requirements of the process. The process box is the middle box. It contains a list of the functions that need to be performed to transform the input into the required output. The output box is the right hand box. It contains the products of the process. It can be a file, a field, a report, a screen--or whatever is required.

HIPO diagrams are limited in their usefulness. They are only effective for small programs as they become cumbersome and difficult to work with as a program increases in size and complexity. In addition, HIPO diagrams don't have any built-in guidelines for structured design.

 Michael Jackson Diagrams Level: Detailed Overview Scope: Data Procedures Pros: Covers all phases of design Cons: Not good for complex logic No database constructs, only flat file 

No, not that Michael Jackson. Michael Jackson diagrams are based on the premise that the structure of a program should be derived from the structure of its data. One of the main differences is that while Warnier-Orr diagrams utilize a horizontal structure, Michael Jackson diagrams utilize a tree structure approach similar to a structure chart. Michael Jackson diagrams are also the basis of a structured design methodology, Jackson System Design (JSD). In this methodology, precise and correct representations of input and output result in the structure of the program.

Michael Jackson diagrams view a system and its associated programs and data as a tree-type structure. This structure is very similar to a standard decomposition diagram. Michael Jackson diagrams add a set of symbols that allows for the representation of all of the structured constructs as well has many types of data relationships. The main drawback of this diagramming method is that it does not allow for modern databases--only traditional flat files.

 Nassi-Shneiderman Charts Level: Detailed Scope: Procedures Pros: Easy to understand Converts easily to code Cons: Cumbersome on large projects Can be difficult to draw 

Nassi-Shneiderman (N-S) charts were created by two men, I. Nassi and B. Shneiderman, who tried to offer a flowchart alternative. Their alternative allows for a structured, hierarchical approach to program design. N-S charts show program logic that has one entry point, one exit point and utilizes the three basic structured programming constructs: sequence, selection and iteration.

N-S charts comprise a box that contains other boxes. Each of these boxes represents the logic of a particular section of a program. While this technique can show what happens in a particular program segment, N-S charts can't show how a program segment interacts with other program segments. N-S charts offer a structured alternative to flowcharts, but are still not as useful as many of the other diagramming techniques.

Pseudocode

Level: Detailed

Scope: Procedures

Pros: Easy to understand

Cons: Cumbersome on large projects

No definitive standard

Pseudocode, or structured English, is not really a diagramming technique but a method of representing a program's logic with everyday English. This English must conform to a set of rules, usually made up by the programmer, that will allow the logic of a program to be easily understood and avoid certain ambiguities. Pseudocode doesn't require that you learn the ins and outs of a particular methodology--it can be understood by almost anyone. Therein lies its biggest drawback. A good diagramming technique allows you to grasp a system graphically and enforces certain standards. While pseudocode may appear easier, it can lead to more work in the long run.

 Structure Charts Level: Overview Scope: Procedures Pros: Widely used Cons: Can't show control structures sequence, selection, iteration 

Structure charts are a type of decomposition diagram. They are one of the two types of charts used by one of the most popular methods of structured design. (The other type of chart is a data flow diagram.) Just as a data flow diagram represents the data within a system, structure charts represent the overall structure of a program. This is done by showing the modules of the program and how these modules interact.

Structure charts are composed of rectangular boxes and arrows that connect the boxes. A box represents a module. A module is one specific function of a program, such as: read a record or verify a transaction code. The arrows show the ways that the modules interact. The arrows represent either data being passed to and/or from a module or control information being passed. Structure charts can represent the overall flow of a program, not the low-level functions of a module.

 Warnier-Orr Diagrams Level: Detailed Overview Scope: Data Procedures Pros: Easy to understand Covers all phases of design Easily converted to structured code Cons: Can't relate data to procedure 

Warnier-Orr diagrams, named for Jean-Dominique Warnier in France and Kenneth Orr in the United States, are more than just diagrams--they are the basis of an entire methodology, data structured design. Warnier-Orr diagrams can represent anything from a high-level system overview to a detailed program view. The concept behind Warnier-Orr diagrams is that the driving force behind design should be the structure of the data, not the processes that manipulate this data.

Warnier-Orr diagrams graphically represent a system, program, file or report in a horizontal fashion that uses brackets across the page. Think of an organizational chart laid on its' side. Warnier-Orr diagrams are similar in many ways to action diagrams. The diagrams are only a small part of an entire design methodology. This methodology has been one of the most popular in recent years.

Bibliography:

Martin, James/McClure, Carma. Diagramming Techniques for Analysts and Programmers, Prentice-Hall, 1985.