Process Specification

1
Process Specification

• DFDs model the processes that exist in a system.
  But, they do
• not allow us to record detailed information about
  these processes.
• To record detailed information about processes/to
  specify
• processes, process specification techniques are
  used.
• These techniques specify the precise nature of
  decision
• processes and specify the exact sequence of
  actions to be taken
• in a particular process.

2
Why Process Specification?

• Why not use plain English to specify processes?
  English is not
• used because
• It is verbose (i.e. long-winded) and unclear.
• There are many ways of saying the same thing.
• It is ambiguous and can lead to
  misinterpretation.
• When we write specifications, they must be
  concise, precise,
• clear, unambiguous, and standard.

3
Why Process Specification?

• For example
• Multiply x by y unless y is negative, in which
  case multiply x by z.
• If the value of y is less than zero, you should
  multiply x by z. If the value of y is greater
  than zero, then you should multiply x by y.
• These statements look different but mean the same
  thing gt
• there is no standard way of saying things.
• Statement 2 is longer and more verbose which
  obscures the
• meaning gt it is not concise or clear.

4
Why Process Specification?

• For example
• Orders for less than 20 items and for local
  delivery or for less than 50 get shipped the
  same day.
• Do orders for less than 50 get shipped the same
  day? It
• depends. Read with emphasis on or it appears
  they do. Read
• with emphasis on and, its not clear.
• Maths and PLs, have rules of precedence which
  govern and and
• or. English does not gt it is ambiguous, leads
  to
• misinterpretation, and is not precise.

5
Process Specification Techniques

• To overcome these problems, we use process
  specification
• techniques. Three such techniques are
• Structured English (SE)
• Decision Tables
• Decision Trees

6
Structured English

• Structured English (SE) is a form of English with
  a limited
• number of constructs and a limited vocabulary.
  Most programs
• are made up of just three structures
• Sequence
• Selection
• Iteration
• As process specifications are eventually
  converted into programs, it means we only need
  these constructs.

7
Structured English

• So, we can limit the vocabulary and constructs
  within specs to
• Imperative verbs e.g. multiply, calculate, print.
  No adjectives or adverbs are allowed.
• Data dictionary terms. The data dictionary
  records data about a systems data, just as
  process specs record data about a systems
  processes.
• Construct words e.g and, or.
• A small amount of English, for readability.
• Mathematical symbols e.g. , , -.
• Labels which divide specs into logical sections
  as function headers do in programming languages.

8

• DO Calculate-Invoice-Total
• Calculate-Invoice-Total
• IF delivery is local
• IF order-value gt 50
• then add 5 to invoice-total
• ELSE
• add 10 to invoice-total
• ENDIF
• ELSE
• add 20 to invoice-total
• ENDIF

9
Structured English

• A number of different styles of SE are possible,
  three of which
• are
• A narrative style (paragraphs).
• An outline style.
• A pseudocode style.
• There are examples of each of these in the
  lecture notes.

10
Structured English

• SE is very similar to pseudocode in a lot of
  ways, but it is not
• pseudocode.
• Pseudocode is often used for program specs. It
  is not considered
• suitable for non-technical end-users.
• So, SE is better when we need to express a
  process spec where
• the main concern is user communication.
• A drawback about SE is its not so good when the
  process has
• many decisions. Then its better to use decision
  tables or
• decision (in conjunction with SE).

11
Decision Tables

• Decision tables are used as a method of defining
  the logic of a
• process in a compact manner.
• Convenient to use in a program where a large
  number of logical
• alternatives exist (i.e. assume that a process
  being specified
• equates roughly to a program in the system). The
  basic format of
• the decision table consists of four quadrants

Condition stub
Condition entry
Action stub
Action entry
12
Decision Tables

• Condition Stub specifies values of the data we
  wish to test for.
• Condition Entry specifies what the above values
  may be.
• The condition stub and condition entry show what
  values an item
• of data might have, that the program should test
  for.
• The condition entry is divided into columns, each
  column
• representing a distinct 'rule' or unique result
  of all the
• conditions.

13
Decision Tables

• Action Stub - specifies the actions that may be
  taken.
• Action Entry - shows the action or actions that
  will be performed
• for each rule (in the condition entry). The
  columns are marked
• with an 'X' opposite the action(s) to be taken.
• Sometimes it is possible to optimise a decision
  table i.e.minimise
• or reduce its size. Optimisation is normally
  achieved by
• removing impossible combinations AND/OR,
• combining rules which result in identical actions.

14
Decision Tables

• When constructing a decision table from a
  narrative or case
• study, you should follow the steps
• 1. List the conditions.
• 2. List the actions.
• 3. Calculate the number of rules (2n where n
  number of
• conditions). Draw up the required number of
  columns.
• 4. Apply the halving rule.
• 5. Work down the actions and for each rule,
  enter 'X' against each appropriate action.

15
Decision Trees

• When a decision table is not too complex, it may
  be presented
• graphically as a decision tree to help our
  understanding of the
• logic.
• Like decision tables, decision trees show how
  conditions are
• related to actions.
• However, the tree format shows how conditions are
  combined to
• lead to a particular action. This is the only
  advantage trees have
• over the more compact tables.

16
Decision Trees

• Decision trees
• Usually drawn from un-optimised, limited entry
  decision tables.
• Often used in preference to decision tables where
  there are not too many decision points and each
  action applies to only one case.
• Can be formed from very complex process logic,
  but this is difficult as their construction tends
  to be less structured than that of decision
  tables.

17
Decision Trees

• A decision tree is written (and read) from left
  to right.
• It will have a list of actions recorded at the
  extreme right.
• It is conventional to structure the decisions so
  that each only has two outcomes. This can lead
  to several problems, such as an inefficient
  program, if it is designed according to the tree.

18
Title
19
Overview

• Structured English is best used wherever the
  problem involves combining sequences of actions
  with decisions and loops.
• Decision Tables are best used for problems
  involving complex combinations of up to 5 or 6
  decisions. However, large numbers of
  combinations of conditions can make decision
  tables unwieldy.
• Decision Trees are best used for logic
  verification or moderately complex decisions
  which result in up to 10-15 actions. They are
  also useful for presenting the logic of a
  decision table to users.