Decision Structure
<\/span>Only IF a condition is true, complete the following statements; otherwise, jump to the ELSE<\/td> | IF Condition A is True
THEN implement Action A
ELSE implement Action B
ENDIF<\/code><\/td><\/tr>Case Structure<\/span>
A special type of decision structure in which the cases are mutually exclusive (if one occurs, the others cannot)<\/td> | IF Case #1 implement Action #1
ELSE IF Case #2
Implement Action #2
ELSE IF Case #3
Implement Action #3
ELSE IF Case #4
Implement Action #4
ELSE print error
ENDIF<\/code><\/td><\/tr>Iteration<\/span>
Blocks of statements that are repeated until done<\/td> | DO WHILE there are customers.
Action #1
ENDDO<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nA Structured English Example<\/h2>\n\n\n\nThe following example demonstrates how a spoken procedure for processing medical claims is transformed into structured English:<\/p>\n\n\n\n We process all our claims in this manner. First, we determine whether the claimant has ever sent in a claim before; if not, we set up a new record. The claim totals for the year are then updated. Next, we determine if a claimant has policy A or policy B, which differ in deductibles and copayments (the percentage of the claim claimants pay themselves). For both policies, we check to see if the deductible has been met ($100 for policy A and $50 for policy B). If the deductible has not been met, we apply the claim to the deductible. Another step adjusts for the copayment; we subtract the percentage the claimant pays (40 percent for policy A and 60 percent for policy B) from the claim. Then we issue a check if there is money coming to the claimant, print a summary of the transaction, and update our accounts. We do this until all claims for that day are processed.<\/em><\/p>\n\n\n\nIn examining the foregoing statements, one notices some simple sequence structures, particularly at the beginning and end. There are a couple of decision structures, and it is most appropriate to nest them, first by determining which policy (A or B) to use and then by subtracting the correct deductibles and copayments. The last sentence points to an iteration: Either DO UNTIL all the claims are processed or DO WHILE there are claims remaining.<\/p>\n\n\n\n Realizing that it is possible to nest the decision structures according to policy plans, we can write the structured English for the foregoing example (see illustration below). As one begins to work on the structured English, one finds that some logic and relationships that seemed clear at one time are actually ambiguous. For example, do we add the claim to the year-to-date (YTD) claim before or after updating the deductible? Is it possible that an error can occur if something other than policy A or B is stored in the claimant\u2019s record? We subtract 40 percent of what from the claim? These ambiguities need to be clarified at this point.<\/p>\n\n\n\n DO WHILE there are claims<\/span> remaining\n\tIF claimant<\/span> has not sent in a claim\n\t\tTHEN set up new claimant record<\/span>\n\tELSE continue\nAdd claim<\/span> to YTD Claim<\/span>\n\tIF claimant<\/span> has policy\u2013plan A<\/span>\n\t\tTHEN IF deductible<\/span> of $100.00 has not been met\n\t\t\tTHEN subtract deductible\u2013not\u2013met<\/span> from claim<\/span>\n\t\t\tUpdate deductible<\/span>\n\t\tELSE continue\n\t\tENDIF\n\t\tSubtract copayment of 40% of claim<\/span> from claim<\/span>\n\tELSE IF claimant<\/span> has policy\u2013plan B<\/span>.\n\t\tTHEN IF deductible<\/span> of $50.00 has not been met\n\t\t\tTHEN subtract deductible\u2013not\u2013met<\/span> from claim<\/span>\n\t\t\tUpdate deductible\n\t\tELSE continue\n\t\tENDIF\n\t\tSubtract copayment of 60% of claim<\/span> from claim<\/span>\n\tELSE continue\nELSE write plan\u2013error\u2013message<\/span>\n\tENDIF\nENDIF\nIF claim<\/span> is greater than zero\n\tTHEN print check<\/span>\nENDIF\nPrint summary for claimant<\/span>\nUpdate accounts<\/span>\nENDDO<\/code><\/pre>\n\n\n\nBesides the obvious advantage of clarifying the logic and relationships found in human languages, structured English has another important advantage: It is a communication tool. Structured English can be taught to and hence understood by users in the organization, so if communication is important, structured English is a viable alternative for decision analysis.<\/p>\n\n\n\n Data Dictionary and Process Specifications<\/h2>\n\n\n\nAll computer programs may be coded using the three basic constructs: sequence, selection (IF . . .THEN . . . ELSE and the case structure), and iteration or looping. The data dictionary indicates which of these constructs must be included in the process specifications.<\/p>\n\n\n\n If the data dictionary for the input and output data flow contains a series of fields without any iteration\u2014{ }\u2014or selection\u2014[ ]\u2014the process specification will contain a simple sequence of statements, such as MOVE, ADD, and SUBTRACT. Refer to the example of a data dictionary for the SHIPPING STATEMENT, see illustration below.<\/p>\n\n\n
| | |