<ch32 toc ch34>

33 Warnier-Orr diagrams

33.1 Purpose
33.2 Strengths, weaknesses, and limitations
33.3 Inputs and related ideas
33.4 Concepts
33.4.1 In-out diagrams
33.4.2 Data structures
33.4.3 Program (logic) structures
33.5 Key terms
33.6 Software
33.7 References

33.1 Purpose

A Warnier-Orr diagram, a graphical representation of a horizontal hierarchy with brackets separating the levels, is used to plan or document a data structure, a set of detailed logic, a program, or a system.

33.2 Strengths, weaknesses, and limitations

Warnier-Orr diagrams are excellent tools for describing, planning, or documenting data structures. They can show a data structure or a logical structure at a glance. Because only a limited number of symbols are required, specialized software is unnecessary and diagrams can be created quickly by hand. The basic elements of the technique are easy to learn and easy to explain. Warnier-Orr diagrams map well to structured code.

The structured requirements definition methodology (# 4) and, by extension, Warnier-Orr diagrams are not as well known as other methodologies or tools. Consequently, there are relatively few software tools to create and/or maintain Warnier-Orr diagrams and relatively few systems analysts or information system consultants who are proficient with them.

33.3 Inputs and related ideas

Before a Warnier-Orr diagram is created, the system’s primary data entities and major tasks must be known. The necessary information is collected during the problem definition and information gathering stage (Part II). A Warnier-Orr diagram is an important tool in the structured requirements definition methodology (# 4). See #s 25 and 43 for explanations of key data-related concepts. Entity-relationship diagrams (# 26) and data normalization (# 28) are useful tools for planning data structures. See # 62 for more on software design and program structures.

33.4 Concepts

The Warnier-Orr design methodology, also known as the structured requirements definition methodology (# 4), was developed in the early 1970s by Warnier and extended to system design by Orr. The first step in the methodology is to create entity diagrams (simplified entity-relationship diagrams, # 26) for each major user. The entity diagrams are then merged to create a system entity diagram, and the major tasks that must be performed are derived from the system’s data requirements.

33.4.1 In-out diagrams

A Warnier-Orr diagram shows a data structure or a logical structure as a horizontal hierarchy with brackets separating the levels. Once the major tasks are identified, the systems analyst or information system consultant prepares an in-out Warnier-Orr diagram to document the application’s primary inputs and outputs.

For example, Figure 33.1 shows an in-out diagram for a batch inventory update application. Start at the left (the top of the hierarchy). The large bracket shows that the program, Update Inventory, performs five primary processes ranging from Get Transaction at the top to Write Reorder at the bottom. The letter N in parentheses under Update Inventory means that the program is repeated many (1 or more) times. The digit 1 in parentheses under Get Transaction (and the next three processes) means the process is performed once. The (0, 1) under Write Reorder means the process is repeated 0 or 1 times, depending on a run-time condition. (Stock may or may not be reordered as a result of any given transaction.)


Figure 33.1  An in-out Warnier-Orr diagram.

Data flow into and out from every process. The process inputs and outputs are identified to the right of the in-out diagram. For example, the Get Transaction process reads an Invoice and passes it to a subsequent process. The last column is a list of the program’s primary input and output data structures. Note how the brackets indicate the hierarchical levels.

33.4.2 Data structures

After the in-out diagram is prepared, the data structures are documented. For example, Figure 31.2 shows the data structure for an invoice.


Figure 33.2  A Warnier-Orr diagram of the Invoice data structure.

The highest level composite, Invoice, is noted at the left. The N in parentheses under the data name means that there are many (one or more) invoices. Moving to the right of the first bracket are the components that make up an invoice. Invoice number, Date-of-sale, Customer telephone, Subtotal, Sales tax, and Total due are data elements, while Customer name, Customer address, and Item purchased are composite items that are further decomposed.

Consider the composite item Customer name. The composite name appears at the left separated from its lower-level data elements by a bracket. Three of the data elements that make up Customer name are conditional; Customer title (Dr, Mr., Ms.), Customer middle (not everyone has a middle name), and Customer suffix (Sr., Jr., III) may or may not be present on a given Invoice. The entry (0, 1) under a data element name indicates that it occurs 0 or 1 times.

A given sales transaction might include several different products, so Item purchased is a repetitive data structure that consists of one or more sets of the data elements Stock number, Description, Units, Unit price, and Item total. The letter M in parenthesis under Item purchased indicates that the substructure is repeated an unknown number of times. (Note: M and N are different values.) The composite item, Units, can hold either Weight or Quantity, but not both. The “plus sign in a circle” is an exclusive or symbol.

33.4.3 Program (logic) structures

A key principle of the Warnier-Orr methodology is that the structure of a well-written program is tied to the structure of its data. For example, because the number of invoices is unknown, the primary structure of an inventory update program designed to process the data described in Figure 33.2 will be a repetitive loop. At the second level, the number of items purchased is unknown, suggesting another loop structure to compute and accumulate the item costs. Finally, the exclusive or and the conditional items at the data element level suggest selection logic.

33.5 Key terms

Composite —
A set of related data elements.
Data element —
An attribute that cannot be logically decomposed.
Data structure —
A set of related data elements.
Entity —
An object (a person, group, place, thing, or activity) about which data are stored.
Entity diagram —
A simplified entity-relationship diagram that uses bubbles instead of rectangles and ignores cardinality.
Entity-relationship diagram —
A model of a system’s data that shows how the primary data entities are related.
In-out diagram —
A Warnier-Orr diagram that documents the application’s primary inputs and outputs.
Warnier-Orr diagram —
A diagramming technique that shows a data structure or a logical structure as a horizontal hierarchy with brackets separating the levels.

33.6 Software

The Warnier-Orr diagrams in this # were prepared using Visio. Other graphing tools, such as Micrografx’s Flowcharter provide comparable support. Most popular paint or drawing programs incorporate text and brackets and thus can be used to create Warnier-Orr diagrams. Some CASE products support Warnier-Orr diagrams.

33.7 References

1.  Davis, W. S., Business Systems Analysis and Design, Wadsworth, Belmont, CA, 1994.
2.  Davis, W. S., Systems Analysis and Design: A Structured Approach, Addison-Wesley, Reading, MA, 1983.
3.  Orr, K. T., Structured Requirements Definition, Ken Orr and Associates, Topeka, KS, 1981.
4.  Orr, K. T., Structured Systems Development, Yourdon, New York, 1977.
5.  Warnier, J. D., The Logical Construction of Programs, Van Nostrand Reinhold, New York, 1976.
6.  Warnier, J. D., Program Modification, Martinus Nijhoff, London, 1978.
<ch32 toc ch34>