Strucanalysis Wiki Index - PHP Title Chapter 1

Chapter 15 - Structured Analysis Wiki Page 1 of 17
Chapter 15
From Structured Analysis Wiki
Contents
1 Additional Modeling Tools
1.1 FLOWCHARTS AND THEIR VARIANTS
1.1.1 The Classic Flowchart
1.1.2 Variations on Flowcharts
1.2 SYSTEM FLOWCHARTS
1.3 HIPO DIAGRAMS
1.4 STRUCTURE CHARTS
1.5 VARIATIONS ON DATAFLOW DIAGRAMS
1.6 VARIATIONS ON ENTITY-RELATIONSHIP DIAGRAMS
1.7 SUMMARY
1.8 REFERENCES
1.9 QUESTIONS AND EXERCISES
1.10 ENDNOTES
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:
http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_15 4/30/2009
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.
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 Figure
15.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 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; source: Image:Figure152.graffle
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; source: Image:Figure154a.graffle
Figure 15.4(b): Parallel processing notation in Ferstl diagrams;

source: Image:Figure154b.graffle
Figure 15.5: A typical Hamilton-Zeldin diagram
Figure 15.6(a): Components of a PAD diagram; source:

Image:Figure156a.graffle
Figure 15.6(b): A typical PAD diagram; source: Image:Figure156b.graffle
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.
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; source: Image:Figure157.graffle
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; 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 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; source: Image:Figure1510.graffle
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
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
Figure 15.14(b): Data dictionary notation corresponding to the Jackson data

structure of Fig. 15.14(a)
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?
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"
Content is available under GNU Free Documentation License 1.2.

Privacy policy
About Structured Analysis Wiki
Disclaimers

Strucanalysis Wiki Index - PHP Title Chapter 1

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Strucanalysis Wiki Index - PHP Title Chapter 1

Uploaded by

Copyright:

Available Formats

Chapter 15 - Structured Analysis Wiki Page 1 of 17

Additional Modeling Tools

IN THIS CHAPTER, YOU WILL LEARN:

1. How to identify several variations on flowcharts;

Flowcharts and their variants

FLOWCHARTS AND THEIR VARIANTS

The Classic Flowchart

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

The notation shown in Figure 15.1 has only three components:

The rectangular box represents an executable computer instruction or a contiguous sequence of

Figure 15.2: An unstructured flowchart; source: Image:Figure152.graffle

Figure 15.3: A typical Nassi-Shneiderman diagram

Figure 15.4(a): A typical Ferstl diagram; source: Image:Figure154a.graffle

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; source:

Figure 15.6(b): A typical PAD diagram; source: Image:Figure156b.graffle

Figure 15.7: A typical system flowchart; source: Image:Figure157.graffle

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

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

Figure 15.10: A typical structure chart; source: Image:Figure1510.graffle

VARIATIONS ON DATAFLOW DIAGRAMS

Figure 15.11: A typical SADT diagram

VARIATIONS ON ENTITY-RELATIONSHIP DIAGRAMS

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

Figure 15.14(b): Data dictionary notation corresponding to the Jackson data

Number 2 (June 1970), pp. 119-146.

QUESTIONS AND EXERCISES

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

Content is available under GNU Free Documentation License 1.2.

You might also like