Warnier-Orr diagrams

By -

Warnier-Orr diagrams

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 (Chapter 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 (Chapter 4). See Chapters 25 and 43 for explanations of key data-related concepts. Entity-relationship diagrams (Chapter 26) and data normalization (Chapter 28) are useful tools for planning data structures. See Chapter 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 (Chapter 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, Chapter 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.)

33-01
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.2shows the data structure for an invoice.

33-02
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 chapter 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.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

Nassi-Shneiderman charts

By -
Image
Nassi-Shneiderman charts 56.1 Purpose Nassi-Shneiderman charts were developed by Nassi and Shneiderman as an alternative to traditional logic flowcharts. Their intent was to provide a structured, hierarchical, graphical view of the flow of logic through a program, a routine, a module, or a process. Nassi-Shneiderman charts are used to document, plan, and design detailed program logic. 56.2 Strengths, weaknesses, and limitations A properly prepared Nassi-Shneiderman chart can illustrate the flow of logic through a module or routine at a glance. Nassi-Shneiderman charts are useful for describing or planning relatively small modules, routines, or processes. They can be used to clearly show nesting and recursion, and are easily converted to structured code. Nassi-Shneiderman charts should not be used for documenting complete programs or large routines. As a general rule, Nassi-Shneiderman charts should be limited to a single page with no more than 20 subdivisions. For larger rout...
Read more