System Concepts for Process Modeling



Process Concepts

 Process Logic  Decomposition diagrams and data flow diagrams will prove very effective tools for identifying processes, but they are not good at showing the logic inside those processes.

 We need to specify detailed

instructions

for the elementary processes on a data flow diagram.  To address this problem, we require a tool that marries some of the advantages of natural English with the rigor of programming logic tools.



Structured English

is a language and syntax, based upon the relative strengths of structured programming and natural English, for specifying the underlying logic of elementary processes on process models (such as

data flow diagrams

).

* * * * * * * * * * Many of us do not write well, and we also tend not to question our writing abilities.

Many of us are too educated! It’s often difficult for a highly educated person to communicate with an audience that may not have had the same educational opportunities. For example, the average college graduate (including most analysts) has a working vocabulary of 10,000 to 20,000 words; on the other hand, the average non-college graduate has a working vocabulary of around 5,000 words.

Some of us write everything like it was a program. If business procedures required such precision, we’d write everything in a programming language.

Too often, we allow the jargon and acronyms of computing to dominate our language.

English statements frequently have an excessive or confusing scope. How would you carry out this procedure: “If customers walk in the door and they do not want to withdraw money from their account or deposit money to their account or make a loan payment, send them to the trust department.” Does this mean that the only time you should not send the customer to the trust department is when he or she wishes to do all three of the transactions? Or does it mean that if a customer does not wish to perform at least one of the three transactions, that customer should not be sent to the trust department?

We overuse compound sentences Consider the following procedure: “Remove the screws that hold the outlet cover to the wall. Remove the outlet cover. Disconnect each wire from the plug, but first make sure the power to the outlet has been turned off.” An unwary person might try to disconnect the wires prior to turning off the power!

Too many words have multiple definitions.

Too many statements use imprecise adjectives. For example, an loan officer asks a teacher to certify that a student is in good academic standing. What is good?

Conditional instructions can be imprecise. For example, if we state that “all applicants under the age of 19 must secure parental permission,” do we mean less than 19, or less than or equal to 19?

Compound conditions tend to show up in natural English. For example, if credit approval is a function of several conditions: credit rating, credit ceiling, annual dollar sales for the customer in question, then different combinations of these factors can result in different decisions. As the number of conditions and possible combinations increases, the procedure becomes more and more tedious and difficult to write.

1.

For each CUSTOMER NUMBER in the data store CUSTOMERS : a.

For each LOAN in the data store LOANS that matches the above CUSTOMER NUMBER : 1) Keep a running total of NUMBER OF LOANS for the CUSTOMER NUMBER .

2) Keep a running total of ORIGINAL LOAN PRINCIPLE for the CUSTOMER NUMBER .

3) Keep a running total of CURRENT LOAN BALANCE for the CUSTOMER NUMBER .

4) Keep a running total of AMOUNTS PAST DUE for the CUSTOMER NUMBER .

b.

If the TOTAL AMOUNTS PAST DUE for the customer number is greater than 100.00 then 1) Write the customer number and data in the data flow LOANS AT RISK .

Else 1) Exclude the customer number and data from the data flow LOANS AT RISK .

System Concepts for Process Modeling



Process Concepts

 Process Logic (continued)  The overall structure of a Structured English specification is built using the fundamental constructs that have governed structured programming for nearly three decades.

 These constructs are: • • A

sequence

of simple, declarative sentences – one after another. A

conditional

or

decision structure

indicate that a process must perform different actions under well specified conditions. • A

iteration

or

repetition

structure specifies that a set of actions should be repeated based on some stated condition. There are two variations on this construct.

System Concepts for Process Modeling



Process Concepts

 Process Logic (continued)  The

sequence

construct: • Compound sentences are discouraged because they frequently create ambiguity. • Each sentence uses strong, action verbs such as GET, FIND, RECORD, CREATE, READ, UPDATE, DELETE, CALCULATE, WRITE, SORT, MERGE, or anything else recognizable or understandable to the users. • A formula may be included as part of a sentence (e.g., CALCULATE GROSS PAY = HOURS WORKED X HOURLY WAGE.)

System Concepts for Process Modeling



Process Concepts

 Process Logic (continued)  The

conditional

or

decision structure

construct: • There are two variations (and a departure) on this construct.

– The IF-THEN-ELSE construct specifies that one set of actions should be taken if a specified condition is ‘true’, but a different set of actions should be specified if the specified condition is false. – The CASE construct is used when there are more than two sets of actions to choose from. – For logic that based on multiple conditions and combinations of conditions,

decision tables

are a far more elegant logic modeling tool.

System Concepts for Process Modeling



Process Concepts

 Process Logic (continued)  The

iteration

or

repetition

construct: • There are two variations on this construct.

– The DO-WHILE construct indicates that certain actions (usually expressed as one or more

sequential

and/or

conditional

statements) are repeated zero, one, or more times based on the value of the stated condition. – The REPEAT-UNTIL constructs indicates that certain actions (again, usually expressed as one or more

sequential

and/or

conditional

statements) are repeated one or more times based on the value of the stated condition.

System Concepts for Process Modeling



Process Concepts

 Process Logic (continued)  Structured English places the following restrictions on process logic: • • Only strong, imperative verbs may be used.

Only names that have been defined in the project repository may be used. • • State formulas clearly using appropriate mathematical notations. Undefined adjectives and adverbs are not permitted unless clearly defined in the project repository as legal values for data attributes.

• Blocking and indentation are used to set off the beginning and ending of constructs and to enhance readability.

• When in doubt, user readability should always take precedence over programmer preferences.

Construct Sequence of actions –

unconditionally perform a sequence of actions.

Simple condition actions

– if the specified condition is true, then perform the first set of actions.

Otherwise, perform the second set of actions.

Use this construct if the condition has only two possible values.

(Note: The second set of conditions is optional.)

Complex condition actions

– test the value of the condition and perform the appropriate set of actions.

Use this construct if the condition has more than two values.

Multiple conditions –

test the value of multiple conditions to determine the correct set of actions.

Use a

decision table

instead of nested if-then-else Structured English constructs to simplify the presentation of complex logic that involves A decision table is a

tabular presentation of complex logic in which rows represent conditions and possible actions, and columns indicate which combinations of conditions result in specific actions.

One-to-many iteration –

Repeat the set of actions until the condition is false.

Use this construct if the set of actions must be performed at least once, regardless of the condition’s initial value.

Zero-to-many iteration –

Repeat the set of actions until the condition is false.

Use this construct if the set of actions are conditional based on the condition’s initial value.

[ Action 1 ] [ Action 2 ] … [ Action n ]

If

[ truth condition ]

then else End If Do While End Do Sample Template

[ sequence of actions or other conditional actions ] [ sequence of actions or other conditional actions ]

Do the following based on

[ condition ]:

Case 1: If

[ condition] = [value] then [ sequence of actions or other conditional actions ]

Case 2: If

[ condition] = [value] then [ sequence of actions or other conditional actions ] …

Case n: If

[ condition] = [value] then [ sequence of actions or other conditional actions ]

End Case DECISION TABLE

[ Condition ] [ Condition ] [ Condition ] [ Sequence of actions or conditional actions ] [ Sequence of actions or conditional actions ] [ Sequence of actions or conditional actions ] Rule value value value X Rule value value value X Rule value value value X Rule value value value X

Although it isn’t a Structured English construct, a decision table can be named, and referenced within a Structured English procedure.

Repeat the following until

[truth condition]: [ sequence of actions or conditional actions ]

End Repeat

[truth condition]: [ sequence of actions or conditional actions ]

- OR For

[truth condition]: [ sequence of actions or conditional actions ]

End For

System Concepts for Process Modeling



Process Concepts

 Process Logic (continued)  Many processes are governed by complex combinations of conditions that are not easily expressed with Structured English.  This is most commonly encountered in business policies.

• A

policy

is a set of rules that govern some process in the business.

 In most firms, policies are the basis for decision making.  Policies consist of

rules

that can often be translated into computer programs if the users and systems analysts can accurately convey those rules to the computer programmer.

System Concepts for Process Modeling



Process Concepts

 Process Logic (continued)  One way to formalize the specification of policies and other complex combinations of conditions is by using a

decision table

.

• A

decision table

is a tabular form of presentation that specifies a set of conditions and their corresponding actions.

 A decision table consists of three components: • Condition stubs (the upper rows) describe the conditions or factors that will affect the decision or policy.

• Action stubs (the lower rows) describe, in the form of statements, the possible policy actions or decisions.

• Rules (the columns) describe which actions are to be taken under a specific combination of conditions.

A SIMPLE POLICY STATEMENT

CHECK CASHING IDENTIFICATION CARD

A customer with check cashing privileges is entitled to cash personal checks of up to $75.00 and payroll checks of from companies pre-approved by

LMART LMART

. This card is issued in accordance with the terms and conditions of the application and is subject to change without notice. This card is the property of and shall be forfeited upon request of

LMART

.

A1: Cash the check SIGNATURE

EXPIRES May 31, 1998

THE EQUIVALENT POLICY DECISION TABLE

Conditions and Actions

C1: Type of check C2: Check amount less than or equal to $75.00

C3: Company accredited by

LMART

A2: Don’t cash the check

Rule 1

personal yes doesn’t matter X

Rule 2

payroll doesn’t matter yes X

Rule 3

personal no doesn’t matter X

Rule 5

payroll doesn’t matter no X