Section 5: Physical Design 

Introduction 
After finishing the Logical Output Mapping described at the end of the last section, you have reached the conclusion of Logical Design phase. This is due to the fact that you cannot continue development of the design without considering the physical environment: you must now begin to add details which are specific to a programming language and to input and output devices.

This does not mean, however, that you are necessarily "halfway done" with the design; the physical design stage can be much shorter than logical design (if the constraints are few) or can be much longer (if the constraints are many and complex).

The Physical Design phase consists of three steps:

• Augmenting the Logical Output Mapping 
• Developing the Physical Output Mapping 
• Developing the Physical Input Mapping

These steps are explained in the following sections.

Augmenting Logical Output Mappings 

Introduction 
The first step in Physical Design is the addition of some physical details to the Logical Output Mapping just completed.

Step Three(A): Add to the Logical Output Mapping two physical features: the tests necessary to control repetition and alternation, and the initialization of control fields necessary for those tests. The Logical Output Mapping with these features added is called an "augmented" Logical Output Mapping, and is technically the first deliverable in physical design.

Adding Tests and Control Field Initialization 
Any time a "0,n", "1,n", or "0,1" set is seen on a Logical Output Mapping, there is a departure from simple sequence required (in other words, there must be an associated test to control a loop or an if statement). Therefore as a first step in this process, we will go through the diagram an find all the repetitive and alternative sets.

In the example we have been following, there are two such sets: the Attorney set occurs "0,n" times, and the Client set occurs "1,n" times.

For repetitive sets, we will describe the test which much be done to know when to "stop repeating" (under the assumption that it doesn't take much to get a loop started, but that it does take some intelligence to get it to stop correctly). For the Attorney loop, therefore, we will detail the test done to know when to stop processing Attorneys for the firm.

Notice that since this is part of physical design, we are allowed (or rather, required) to state the test in a manner consistent with the language we will eventually be using to code the program. This is done by adding the following to the Attorney element in Brackets (assuming we wish to generate COBOL)...

Attorney `#0,a `?No-More-Attorneys

The conditional expression "No-More-Attorneys" must be a syntactically valid COBOL boolean expression (if we intend to generate COBOL). Assuming for the moment that we intend to define "No-More-Attorneys" as a level-88 data item in our data division, the addition of the physical test for this level is complete. Our Brackets diagram will generate the following in COBOL:

PERFORM ATTORNEY UNTIL NO-MORE-ATTORNEYS.

Notice that the "No-More-Attorneys" data item is almost the same as a traditional "end of file" switch; we will shy away from "end of file" as a data item name, however, for two reasons: first, it is not very "output oriented" and second, it turns out that the end of the "ideal file" does not necessarily coincide with the end of the "real" files (more about this in the design of the Physical Input Mapping). Since setting the "No-More-Attorneys" switch off and on is related to processing the input, the actual moving of data to the switch will be done in the Physical Input Mapping portion of the program (inside the "get" statements visible at this level).

Continuing with the augmentation process, we move on to the Client set. In this case, we wish to answer the question "when is it appropriate to stop processing clients for a single attorney." The test will be something like the following...

Client `#1,c `?Next-Attorney is not = Current-Attorney or No-More-Attorneys

In other words, after we are done processing one client for an attorney, we must check to see if the next Client record we read inside the Client process was for the same attorney. If the attorney is the same on the next record as the attorney on the record record we just processed, then the client loop should not stop, but repeat. Whenever an client record is read containing a different attorney, the Client loop should stop for that attorney.

Since we must save the "Current-Attorney" data to compare to incoming "Next-Attorney" data, the initialization of that control field will be added to our diagram at the beginning of the Attorney level, as shown on the following diagram...

The "Current-Attorney" control field should contain enough Attorney information so that no two Attorneys ever have the same identical data for the control field. "Next-Attorney" is that same data as read in on the Client record.

Notice on this diagram that the test to quit the processing of Clients within Attorney must contain the test to quit the processing of Attorneys. This "nesting" of tests will continue for as many levels as are shown (if, for instance, we were processing multiple Invoices within Client for an Attorney, the test to quit the processing of Invoices within Client would be "until Next-Client is not = Current-Client OR Next-Attorney is not = Current-Attorney OR No-More-Attorneys".

Since there are no other repetitive sets or alternative sets on the LOM, and there are no other "control fields" to initialize, the augmentation process is complete. The diagram shown above is the finished "Augmented Logical Output Mapping."