Chapter 15: Additional Modeling Tools

 

“The need to discover inefficiency early makes it important to externalize (that is, make visible) an evolving design at each stage. Engineering blueprints, for instance, serve this purpose and are useful not only for a designer by calling his attention to trouble spots and potential inconsistencies, but also for a team or an entire organization developing a product. Blueprints are the major medium of communication, criticism, and collective refinement. Moreover, representation methods must be relatively simple and direct in bridging the gap between reality and the program; and they must be efficient during the multiple iterative steps.”

— L.A. Belady
Foreword to Software Design, [Peters, 1981]

IN THIS CHAPTER, YOU WILL LEARN:

  1. How to identify several variations on flowcharts;
  2. How to draw HIPO diagrams and structure charts;
  3. How to identify several variations on DFD diagrams; and
  4. How to identify several variations on ERD diagrams.

The modeling tools presented in the last several chapters should be sufficient for any project that you work on. However, you should also be familiar with some additional modeling tools; even if you don’t use them, you may encounter them in your work, and you should at least know how to read and interpret them.

The additional modeling tools that we will discuss in this chapter include the following:

  • Flowcharts and their variants
  • System flowcharts
  • HIPO diagrams and structure charts
  • Variations on dataflow diagrams
  • Variations on entity-relationship diagrams

The purpose of this chapter is not to make you an expert in any of these modeling tools, but merely to show you that they exist as possible alternatives; there’s a good chance that you may encounter them if you work in an IT organization that has decided to use structured analysis for its projects [1]. Additional details on each modeling tool can be found in the references at the end of the chapter.

15.1 FLOWCHARTS AND THEIR VARIANTS

15.1.1 The Classic Flowchart

One of the earliest and best known modeling tools is the classic flowchart; a typical flowchart is shown in Figure 15.1.

Figure 15.1: A typical flowchart

 

If you have been exposed to computers, or programming, or data processing in any form, chances are that you have had at least some informal exposure to flowcharts. We will not discuss them in detail in this book and will only look at a subset of the diagramming notation. For details on flowchart notation, refer to [Chapin, 1970].

The notation shown in Figure 15.1 has only three components:

  • The rectangular box represents an executable computer instruction or a contiguous sequence of instructions.
  • The diamond-shaped box represents a decision; in the simple case, it represents a binary decision.
  • The arrows connecting the boxes represent the flow of control. There can be only one arrow flowing out of a rectangular box; that is, when a computer instruction finishes its execution, it can proceed to any one single next instruction or decision. Similarly, there can be only two arrows emanating from a decision.

As you can see, the flowchart allows us to graphically represent the procedural logic of a computer program. And that is where flowcharts are used most, though the introduction of high-level programming languages in the 1960s and 1970s has eliminated much of the need for detailed flowcharts.

But if flowcharts are a programming tool, why discuss them in this book? The answer may have occurred to you already: some systems analysts use flowcharts as a way of documenting process specifications (i.e., as an alternative to structured English and the other tools presented in Chapter 11). As you may recall from Chapter 11, my feeling is that any documentation technique that accurately describes the user’s policy and effectively communicates that policy is acceptable. Thus, if the user enjoys reading flowcharts and if the flowcharts accurately describe the policy carried out within a bubble in a dataflow diagram, they can be used.

However, very few systems analysts actually do use detailed flowcharts for process specifications. There are several reasons for this:

  • Unless great care is taken, the flowchart can become incredibly complicated and difficult to read [2]. An example of a typical unstructured flowchart is shown in Figure 15.2.
  • Though automated support (with PC-based drawing tools) is now available, it still requires considerable work to develop the graphics of a flowchart. And if the user’s detailed policy changes, or if the systems analyst has to change it several times before he has something that the user will accept as correct, it will be time consuming and tedious to redraw the flowchart each time. If the process specification has been represented in some textual form that can be manipulated with a word processor, changes are usually much easier
  • Graphical models are usually most effective as a way of illustrating a multidimensional reality. Dataflow diagrams, for example, vividly illustrate the fact that all the bubbles in the system can be active at the same time. But the flow of control in a program or an individual process specification can be described in a one-dimensional form; that is, the logic can be arranged so that it flows uniformly from “top to bottom.” [3] Because of this, graphics are unnecessary.

Figure 15.2: An unstructured flowchart

 

15.1.2 Variations on Flowcharts

While the classic flowcharts are the ones most commonly used — when they are used at all! — there are some variations that you should be aware of. We will mention four:

  1. Nassi-Shneiderman diagrams
  2. Ferstl diagrams
  3. Hamilton-Zeldin diagrams
  4. Problem analysis diagrams

Nassi-Shneiderman diagrams (sometimes referred to as Chapin charts) were introduced in the 1970s (see [Nassi and Shneiderman, 1973] and [Chapin, 1974]) as a way of enforcing a strict structured programming approach. A typical Nassi-Shneiderman diagram is shown in Figure 15.3. As you can see, the diagram is easy to read. However, one could argue that Nassi-Shneiderman diagrams are just structured English statements with boxes drawn around them.

Figure 15.3: A typical Nassi-Shneiderman diagram

 

Ferstl diagrams are another variation on the classic flowchart; a full description is provided in [Ferstl, 1978]. A typical Ferstl diagram is shown in Figure 15.4(a). In addition to showing normal, sequential program logic, the Ferstl diagram can also be used to show parallel processing; the Ferstl notation for parallel processing is shown in Figure 15.4(b).

Hamilton-Zeldin diagrams were developed as part of the software development activities for NASA’s Space Shuttle project; see [Hamilton and Zeldin, 1972]. A typical Hamilton-Zeldin diagram, sometimes referred to as a structured design diagram, is shown in Figure 15.5. In Hamilton-Zeldin diagrams, the rectangular boxes have the same meaning as a rectangular box in an ANSI flowchart: an executable statement or contiguous group of executable statements. An elongated pentagon is used to show both IF statements and DO-WHILE/REPEAT-UNTIL iterations. Control normally flows from top to bottom of the diagram, except in the case of IF tests and iterations (DOs and REPEATs), which proceed from left to right.

Problem analysis diagrams (PAD), developed at the Hitachi Corporation (see [Futamura, Kawai, Horikoshi, and Tsutsumi, 1981]), are a two-dimensional, tree-structured representation of program logic. The components of a PAD diagram are shown in Figure 15.6(a). As with the Hamilton-Zeldin diagrams, PAD diagrams are read from top to bottom, with IF constructs and iterations being shown left to right; an example is shown in Figure 15.6(b).

Figure 15.4(a): A typical Ferstl diagram

 

Figure 15.4(b): Parallel processing notation in Ferstl diagrams

 

Figure 15.5: A typical Hamilton-Zeldin diagram

 

Figure 15.6(a): Components of a PAD diagram

 

Figure 15.6(b): A typical PAD diagram

 

Like the Ferstl diagrams, a PAD diagram can show parallel processing; it also uses a combination of vertical display of sequential flow with a horizontal display of nesting levels (e.g., loops within loops within loops) that is similar to the Hamilton-Zeldin diagrams.

15.2 SYSTEM FLOWCHARTS

The various flowchart approaches in the previous section are useful for showing detailed logic, either within a computer program or within a process specification for an individual bubble in a DFD. However, a high-level view of the organization of a system can be shown by another kind of flowchart: the system flowchart. A typical system flowchart is shown in Figure 15.7.

Note that the rectangular boxes represent operational aggregates of computer software (e.g., computer programs, job steps, runs, or other units of computer software). The system flowchart also shows various kinds of physical files (e.g., magnetic tape files or disk files). And it may show the presence of on-line terminals and telecommunication links.

The system flowchart is often a very useful diagram for the systems designers who must develop an overall systems architecture of hardware and software to implement the user requirements. However, I feel that it is not an appropriate modeling tool for systems analysis, for the simple reason that it emphasizes physical implementation details that the user and systems analyst should not be discussing. Rather than talking about a disk file, for example, the systems analyst and user should be discussing the content of the file; rather than talking about individual computer programs, they should be talking about the functions to be carried out.

There is one situation where the system flowchart could be a useful modeling tool: at the end of the systems analysis activity, when the user implementation model is being developed. At this point, the user, the systems analyst, and the implementation team (designers and programmers) discuss those implementation constraints that must be imposed upon the system; these include such things as the determination of the automation boundary (what parts of the system will be automated and what parts will be manual) and the human interface (details of the interaction between the system and its human users).

Figure 15.7: A typical system flowchart

 

15.3 HIPO DIAGRAMS

HIPO diagrams were developed by IBM in the 1970s (see [HIPO, 1974] and [Katzan, 1976]) and have been used by some systems analysts to present a high-level view of the functions performed by a system, as well as the decomposition of functions into subfunctions, and so on. A typical HIPO diagram is shown in Figure 15.8.

In some user environments, HIPO diagrams can be useful modeling tools, because they look like the familiar organization chart that describes the hierarchy of managers, submanagers, and so on. However, the diagram does not show the data used by, or produced by the system; while it is understandable that one might want to de-emphasize data relationships in a model, I don’t feel that it helps to eliminate all information about the data.

Actually, there is a second component of the HIPO diagram that does show the data. The diagram shown in Figure 15.8 is known as a VTOC, or visual table of contents. Each function represented by a rectangular box can be described in further detail in an IPO (or input-process-output) diagram; a typical IPO diagram is shown in Figure 15.9.

While the details of the data are indeed shown at this level, they are not shown on the high-level VTOC diagram. Thus, anyone looking at an overview of the system has no easy way of seeing the interfaces between the various system components.

Figure 15.8: A typical HIPO diagram

 

Figure 15.9: A typical IPO diagram

 

15.4 STRUCTURE CHARTS

A variation on HIPO diagrams that is in wide use is the structure chart. A typical structure chart is shown in Figure 15.10; notice that in addition to showing the functional hierarchy, it also shows the data interfaces between the components. Unlike many of the previous diagrams, the rectangular box in a structure chart does not represent a single computational statement or a contiguous group of statements; instead, it represents a module. (Common examples of modules are FORTRAN subroutines, C procedures, COBOL subprograms, and SECTIONs.) The arrows connecting the modules do not represent GOTO statements, but instead represent subroutine calls; the notation implies that a subroutine will exit, or return, to its caller when it has finished carrying out its function.

While the structure chart is generally preferred over the HIPO diagram, it still has no real use in the area of systems analysis. Why? Because it is used as a design tool to model a synchronous hierarchy of modules in a system; by synchronous, we mean that only one module is executing at any given time, which is an accurate representation of the way things work on most common computers today. The systems analyst, on the other hand, needs a modeling tool that allows him or her to show a hierarchy of asynchronous networks of processes; this is effectively accomplished with the leveled set of dataflow diagrams. The structure chart is extensively used in program design; we will discuss it in more detail in Chapter 22.

Figure 15.10: A typical structure chart

 

15.5 VARIATIONS ON DATAFLOW DIAGRAMS

As mentioned in Chapter 9, there are various “cosmetic” differences between the dataflow diagrams in this book and the dataflow diagrams shown in other textbooks. The primary differences usually involve such things as the use of a rectangle or oval instead of a bubble to show the functions carried out by a system; dataflow diagrams drawn with ovals are frequently referred to as Gane-Sarson diagrams.

However, there is at least one significant variation on the classic dataflow diagram; it is known as the SADT diagram and was developed at Softech (see [Ross and Schoman, 1977]). Figure 15.11 shows a typical SADT diagram.

While similar in nature to the dataflow diagrams presented in this book, the SADT diagrams distinguish between data flow and control flow by the placement of the arrows on the rectangular boxes. While this can certainly be done, it does place some topological constraints on the diagram, which many systems analysts find awkward.

Figure 15.11: A typical SADT diagram

 

15.6 VARIATIONS ON ENTITY-RELATIONSHIP DIAGRAMS

The entity-relationship diagrams presented in Chapter 12 are considered by most systems analysts to be the most general, abstract way of representing data relationships. However, there are at least three other popular data structure notations:

  • Bachman diagram
  • DeMarco’s data structure diagrams
  • Jackson’s data structure diagrams

One of the more common forms of data model is the Bachman diagram, first developed by Charles Bachman in the 1960s. A typical Bachman diagram is shown in Figure 15.12. Note that it is similar to the entity-relationship diagram discussed in Chapter 12, but does not explicitly show the relationship between objects. Note also the double-headed arrow: this indicates a one-to-many relationship (e.g., a customer can own more than one home, but (in this model) a home can only be owned by one customer).

The DeMarco data structure diagrams have achieved considerable popularity during the past ten years; a typical data structure diagram is shown in Figure 15.13. Note that in addition to showing each object in the data model, the diagram shows the key field; as you will recall, the convention used in this book is to show the key field in the data dictionary.

Though Jackson’s data structure diagrams are not widely used in the United States at the present time, they are quite popular in England, Europe, and other parts of the world; Jean-Dominique Warnier, [Warnier, 1976] and Ken Orr, [Orr, 1977[ have developed similar data models, which are somewhat more popular in the United States. Rather than concentrating on the relationship between different objects in a system, the Jackson diagrams provide a graphical means of showing the hierarchical structure of a single object. The components of a Jackson diagram are shown in Figure 15.14(a); note that this same hierarchical structure can also be documented directly in a data dictionary using the notation presented in Chapter 11, as shown in Figure 15.14(b).

Figure 15.12: A typical Bachman diagram

 

Figure 15.13: A typical DeMarco data structure diagram

 

Figure 15.14(a): A typical Jackson data structure diagram

 

X = {A} + B + E
B = [C | D]

Figure 15.14(b): Data dictionary notation corresponding to the Jackson data structure of Fig. 15.14(a)

 

15.7 SUMMARY

The list of modeling tools shown in this chapter is not a complete one, nor have any of these alternative modeling tools been discussed in detail; to find out more, you will have to consult the references at the end of the chapter. However, keep in mind that you may never see any of these diagrams in a real project (with the likely exception of the ubiquitous flowchart); thus, I would advise against becoming intimately familiar with Hamilton-Zeldin diagrams, PAD diagrams, Ferstl diagrams, and so on, unless you find yourself working on a project where they are required.

Keep in mind also that you may be exposed to some entirely idiosyncratic diagramming techniques that are not discussed in this book (and possibly not described in any book!). This should not concern you: there is nothing particularly sacred about the modeling tools used in this book. However, there is a difference between good modeling tools and bad modeling tools; if you are faced with new diagramming techniques, reread Chapter 8 to identify the criteria for good modeling tools.

REFERENCES

  1. Ned Chapin, “Flowcharting with the ANSI Standard: A Tutorial,” ACM Computing Surveys, Volume 2, Number 2 (June 1970), pp. 119-146.
  2. Corrado Böhm and Guiseppe Jacopini, “Flow Diagrams, Turing Machines and Languages with Only Two Formation Rules,” Communications of the ACM, Volume 9, Number 5 (May 1966), pp. 366-371. Also published in Classics in Software Engineering, E. Yourdon (editor). New York: YOURDON Press, 1979.
  3. I. Nassi and B. Shneiderman, “Flowchart Techniques for Structured Programming,” ACM SIGPLAN Notices, Volume 8, Number 8 (August 1973), pp.12-26.
  4. Ned Chapin, “New Format for Flowcharts,” Software — Practice and Experience, Volume 4, Number 4 (October-December 1974), pp. 341-357.
  5. O. Ferstl, “Flowcharting by Stepwise Refinement,” ACM SIGPLAN Notices, Volume 13, Number 1 (January 1978), pp. 34-42.
  6. M. Hamilton and S. Zeldin, Top-Down, Bottom-Up, Structured Programming, and Program Structuring, Charles Stark Draper Laboratory, Document E-2728. Cambridge, Mass: Massachusetts Institute of Technology, December 1972.
  7. Y. Futamura, and others, “Development of Computer Programs by PAD (Problem Analysis Diagram),” Proceedings of the Fifth International Software Engineering Conference. New York: IEEE Computer Society, 1981, pp. 325-332.
  8. HIPO — A Design Aid and Documentation Technique, IBM Corp., Manual No. GC20-1851-0. White Plains, N.Y.: IBM Data Processing Div., October 1974.
  9. Harry Katzan, Jr., Systems Design and Documentation: An Introduction to the HIPO Method. New York: Van Nostrand Reinhold, 1976.
  10. Doug Ross and Ken Schoman, “Structured Analysis for Requirements Definition,” IEEE Transactions on Software Engineering, Volume SE-3, Number 1, January 1977, pp. 6-15. Also reprinted in Classics in Software Engineering, E. Yourdon (editor). New York: YOURDON Press, 1979.
  11. C.W. Bachman, “Data Structure Diagrams,” Data Base, The Quarterly Newsletter of the Special Interest Group on Business Data Processing of the ACM, Volume 1, Number 2 (Summer 1969), pp. 4-10.
  12. Tom DeMarco, Structured Analysis and Systems Specification. New York: YOURDON Press, 1978.
  13. Michael Jackson, Principles of Program Design. London: Academic Press, 1975.
  14. Larry Peters, Software Design: Methods and Techniques. New York: YOURDON Press, 1981.
  15. Ken Orr, Structured Systems Development. New York: YOURDON Press, 1977.
  16. Jean-Dominique Warnier, Logical Construction of Programs, 3rd ed., translated by B. Flanagan. New York: Van Nostrand Reinhold, 1976.

QUESTIONS AND EXERCISES

  1. Why is it important to be familiar with modeling tools other than the DFD, ERD and STD?
  2. What are the three major components of a flowchart?
  3. Research Project: What additional icons are sometimes used in flowcharts. Consult Chapin [Chapin, 1970] for more information?
  4. How many arrows can emanate from a process box in a flowchart?
  5. What is the difference between a flowchart and a dataflow diagram?
  6. Draw a flowchart for a binary search algorithm.
  7. Draw a flowchart for a simple interchange sort algorithm.
  8. Draw a flowchart for Newton-Raphson approximation for computing the square root.
  9. What are the three major reasons why flowcharts aren’t used?
  10. What are the four major variations on flowcharts?
  11. What is a Nassi-Shneiderman diagram? What is a common synonym for the Nassi-Shneiderman diagram?
  12. Draw a Nassi-Shneiderman diagram for a binary search algorithm.
  13. Draw a Nassi-Shneiderman diagram for a simple interchange sort.
  14. Draw a Nassi-Shneiderman diagram for the Newton-Raphson method for approximating the square root function.
  15. What is a Ferstl diagram?
  16. Draw a Ferstl diagram for a binary search algorithm.
  17. Draw a Ferstl diagram for a simple interchange sort.
  18. Draw a Ferstl diagram for the Newton-Raphson method for approximating a square root.
  19. Why is a Ferstl diagram different from a flowchart? What can it show that a flowchart cannot?
  20. What is a Hamilton-Zeldin diagram? What is a synonym for a Hamilton-Zeldin diagram? Where was it developed?
  21. Draw a Hamilton-Zeldin diagram for a binary search algorithm.
  22. Draw a Hamilton-Zeldin diagram for a simple interchange sort.
  23. Draw a Hamilton-Zeldin diagram for the Newton-Raphson method for approximating a square root.
  24. What is a PAD diagram? Where was it developed?
  25. Draw a PAD diagram for a binary search algorithm.
  26. Draw a PAD diagram for a simple interchange sort.
  27. Draw a PAD diagram for the Newton-Raphson method for approximating a square root.
  28. What features do Ferstl diagrams and PAD diagrams have in common?
  29. What is a system flowchart? What is it used for?
  30. At what stage in the development of an information system is a system flowchart likely to be used?
  31. What is a HIPO diagram? Where was it developed?
  32. Draw a HIPO diagram showing the design of a program to play tic-tac-toe.
  33. What is an input-process-output (IPO) diagram. What is the relationship between an IPO diagram and the HIPO concept?
  34. Draw an IPO diagram for a binary search algorithm.
  35. Draw an IPO diagram for a simple interchange sort.
  36. Draw an IPO diagram for the Newton-Raphson method for approximating a square root.
  37. What is a structure chart?
  38. What is the difference between a structure chart and a HIPO diagram?
  39. Draw a structure chart for a simple program that plays tic-tac-toe.
  40. Why is a structure chart usually insufficient as a systems analysis modeling tool?
  41. What is an SADT diagram? What is the difference between an SADT diagram and a dataflow diagram?
  42. What is a Bachman diagram? What is the difference between a Bachman diagram and an entity-relationship diagram?
  43. What is a DeMarco data structure diagram? What is the difference between a DeMarco data structure diagram and an entity-relationship diagram?
  44. What is a Jackson data structure diagram? What is the difference between a Jackson data structure diagram and an entity-relationship diagram?

FOOTNOTES

  1. [1] However, we do not include a discussion of diagrams and notations for object-oriented analysis and design (OOAD) — primarily because there are so many of them that an adequate discussion would fill a book of its own. Chances are that if you work on a project using OOAD, it will not incorporate the diagramming models discussed in this book; and conversely, the SA/SD projects typically do not use OO technique, except perhaps at the level of detailed design and programming.
  2. [2] As a consequence of this, a specification developed with flowcharts would be enormously larger than a specification developed with the other modeling tools discussed in this book.
  3. [3] The fact that any arbitrary flowchart logic can be rearranged into an equivalent top-to-bottom flow is the basis of structured programming. Böhm and Jacopini [2] first proved that this could be done in flowchart terms; in programming terms, it means that any program can be written in a Pascal-like language without GOTO statements.

 

  
 

www.yourdon.com

©2006 Ed Yourdon