Additional Modeling Tools

“The need to discover inefficiency early makes it important to externalize (that is, make visible) an evolvingdesign at each stage. Engineering blueprints, for instance, serve this purpose and are useful not only for a designerby calling his attention to trouble spots and potential inconsistencies, but also for a team or an entire organizationdeveloping 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 theprogram; and they must be efficient during the multiple iterative steps.”

-- L.A. BeladyForeword 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 mayencounter 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

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

FLOWCHARTS AND THEIR VARIANTS

The Classic Flowchart

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

Figure 15.1: A typical flowchart; source: Image:Figure151.graffle

If you have been exposed to computers, or programming, or data processing in any form, chances are that youhave had at least some informal exposure to flowcharts. We will not discuss them in detail in this book and willonly 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. Andthat is where flowcharts are used most, though the introduction of high-level programming languages in the 1960sand 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 youalready: some systems analysts use flowcharts as a way of documenting process specifications (i.e., as analternative 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 effectivelycommunicates that policy is acceptable. Thus, if the user enjoys reading flowcharts and if the flowchartsaccurately 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 areseveral 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.

Nassi-Shneiderman diagrams (sometimes referred to as Chapin charts) were introduced in the 1970s (see [Nassiand Shneiderman, 1973] and [Chapin, 1974]) as a way of enforcing a strict structured programming approach. Atypical 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 boxesdrawn 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]. Atypical Ferstl diagram is shown in Figure 15.4(a). In addition to showing normal, sequential program logic, theFerstl diagram can also be used to show parallel processing; the Ferstl notation for parallel processing is shown inFigure 15.4(b).

Hamilton-Zeldin diagrams were developed as part of the software development activities for NASA’s SpaceShuttle project; see [Hamilton and Zeldin, 1972]. A typical Hamilton-Zeldin diagram, sometimes referred to as astructured design diagram, is shown in Figure 15.5. In Hamilton-Zeldin diagrams, the rectangular boxes have thesame meaning as a rectangular box in an ANSI flowchart: an executable statement or contiguous group ofexecutable 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 anditerations (DOs and REPEATs), which proceed from left to right.

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

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

SYSTEM FLOWCHARTS

The various flowchart approaches in the previous section are useful for showing detailed logic, either within acomputer program or within a process specification for an individual bubble in a DFD. However, a high-levelview of the organization of a system can be shown by another kind of flowchart: the system flowchart. A typicalsystem 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 physicalfiles (e.g., magnetic tape files or disk files). And it may show the presence of on-line terminals andtelecommunication links.

The system flowchart is often a very useful diagram for the systems designers who must develop an overallsystems architecture of hardware and software to implement the user requirements. However, I feel that it is notan appropriate modeling tool for systems analysis, for the simple reason that it emphasizes physicalimplementation details that the user and systems analyst should not be discussing. Rather than talking about a diskfile, for example, the systems analyst and user should be discussing the content of the file; rather than talkingabout 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 systemsanalysis 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 thatmust 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 theinteraction between the system and its human users).

HIPO diagrams were developed by IBM in the 1970s (see [HIPO, 1974] and [Katzan, 1976]) and have been usedby some systems analysts to present a high-level view of the functions performed by a system, as well as thedecomposition 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 familiarorganization chart that describes the hierarchy of managers, submanagers, and so on. However, the diagram doesnot 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 canbe described in further detail in an IPO (or input-process-output) diagram; a typical IPO diagram is shown inFigure 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 varioussystem components.

Figure 15.8: A typical HIPO diagram; source: Image:Figure158.graffle

Figure 15.9: A typical IPO diagram; source: Image:Figure159.graffle

STRUCTURE CHARTS

A variation on HIPO diagrams that is in wide use is the structure chart. A typical structure chart is shown inFigure 15.10; notice that in addition to showing the functional hierarchy, it also shows the data interfaces betweenthe components. Unlike many of the previous diagrams, the rectangular box in a structure chart does not representa single computational statement or a contiguous group of statements; instead, it represents a module. (Commonexamples of modules are FORTRAN subroutines, C procedures, COBOL subprograms, and SECTIONs.) Thearrows connecting the modules do not represent GOTO statements, but instead represent subroutine calls; thenotation 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 ofsystems analysis. Why? Because it is used as a design tool to model a synchronous hierarchy of modules in asystem; by synchronous, we mean that only one module is executing at any given time, which is an accuraterepresentation 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 iseffectively accomplished with the leveled set of dataflow diagrams. The structure chart is extensively used inprogram design; we will discuss it in more detail in Chapter 22.

VARIATIONS ON DATAFLOW DIAGRAMS

As mentioned in Chapter 9, there are various “cosmetic” differences between the dataflow diagrams in this bookand the dataflow diagrams shown in other textbooks. The primary differences usually involve such things as theuse of a rectangle or oval instead of a bubble to show the functions carried out by a system; dataflow diagramsdrawn 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 SADTdiagram and was developed at Softech (see [Ross and Schoman, 1977]). Figure 15.11 shows a typical SADTdiagram.

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

Figure 15.11: A typical SADT diagram

VARIATIONS ON ENTITY-RELATIONSHIP DIAGRAMS

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

One of the more common forms of data model is the Bachman diagram, first developed by Charles Bachman inthe 1960s. A typical Bachman diagram is shown in Figure 15.12. Note that it is similar to the entity-relationshipdiagram discussed in Chapter 12, but does not explicitly show the relationship between objects. Note also thedouble-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 typicaldata 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 thedata dictionary.

Though Jackson’s data structure diagrams are not widely used in the United States at the present time, they arequite popular in England, Europe, and other parts of the world; Jean-Dominique Warnier, [Warnier, 1976] andKen 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 providea graphical means of showing the hierarchical structure of a single object. The components of a Jackson diagramare shown in Figure 15.14(a); note that this same hierarchical structure can also be documented directly in a datadictionary using the notation presented in Chapter 11, as shown in Figure 15.14(b).

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

The list of modeling tools shown in this chapter is not a complete one, nor have any of these alternative modelingtools 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 exceptionof the ubiquitous flowchart); thus, I would advise against becoming intimately familiar with Hamilton-Zeldindiagrams, PAD diagrams, Ferstl diagrams, and so on, unless you find yourself working on a project where theyare required.

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

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?

ENDNOTES

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. ↑ 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. ↑ 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.

Retrieved from "http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_15"