Procedure Definitions
Last edit November 2001
We will look at four description  techniques:
  • One example is used to demonstrate each technique.
  • The example is introduced after a review of Data Flow Diagramming

    • Introduction

    We are looking at certain techniques which are used in the design of programs - particularly within the context of design of the design of software systems.

    Remember that when we are talking here about programs and software, we do not generally mean packaged software (the software you can buy in shops). The larger part of the software in the world is custom-built, and typically the result of analysis and design methodologies. (This is not to say that packaged software is not the result of analysis and design.)

    Data Flow Diagrams - a quick review

    See also: Data Flow Diagrams (DFDs)
    Data Flow Diagram (DFD) modelling is a top-down decomposition technique which results in Process Descriptions - the central topic of this lecture. 'Process Descriptions' are in essence 'Program-Code descriptions'

    We call the system which is being analysed the 'target system'. Using DFDs we can address the complexities of the target system as follows:

    1. the main processes and activities (sub-systems) within the system are identified
    2. each of the subsystems is decomposed into constituent sub-systems or processes
    3. The identified sub-systems can then be decomposed further until we have a set of diagrams for the system which cannot be decomposed further.
    4. This set of non-decomposable diagrams is a model of the system.
    The fully decomposed model contains within it a sub-set of process boxes which cannot be decomposed into lower level processes.
     
    The above figure shows the decomposition process. If, for the sake of an example, we were to take the decomposition in the above figure as representing a fully decomposed model, then we can identify the sub-set of process boxes which cannot be decomposed further. These are:
    boxes 1 and 3 in the top level diagram 
    boxes 2.1 and 2.2 in the middle diagram 
    boxes 2.3.1, 2.3.2, 2.3.3, and 2.3.4
    These are, then, all processes at the lowest (final) level of decomposition.

    ( Another way of looking at it, is that these processes are, in total, all the discrete activities (processes) which occur within the system - at least all those which we are going to include within, or which are relevant to, the proposed computer system)

    DFD modelling results in specifications for program units
     
    Note that we have not yet looked at identification of data structures - the other major activity in system analysis

    If we assume that the model represented in the above figure is the final model in our design, then we have reached the stage of detailed design.

    At this level - process description - we are in effect designing algorithms, - sets of 'steps which can be followed to reach a desired outcome or result'
     
    Arriving at algorithms
    • By a process of decomposition the system is first modelled in a structured and comprehensible form; and then that model is transformed into a set of process descriptions. 
    • Each of these process descriptions is an algorithm - whether or not it describes a process which is going to be computerized. 
    • Where a process is suitable for implementation in software, we now have a specification for that software component - ie: a specification for a (small) piece of program code. 

    Large computer programs are made up of smaller units

    At this stage of system description we are often defining the activity in the process box in terms of a computer program or program component.
    It should be remembered that computer programs are typically made up of smaller units, which themselves contain smaller components; eg: procedures, modules.


    The example process

    In the figure below, box 2.3.3 from the model above is identified as the process : 'Calculate Discount'.

    WHAT versus HOW

    So far we have a box name which tells us WHAT the process (activity) is. In our description of the process will we will attempt to deal with the HOW. 

    We will use this process as the primary example in examining the four process-description techniques which are the subject of this lecture. 

    We start, in the figure below with a natural English description of the process (along the lines of the description we might obtain in an interview). This example shows some of the difficulties inherent in an ordinary English description. 
     

    English as Descriptive Language

    An example: Description of Discount Policy
    • If a purchase is for less than £100, then we give a discount of 5%
    • If it's a special offer then the discount is 7.5% (except if it's less than £2 we give that instead).
    • Customers who pay within 7 days get an extra 1% if the price after discounts is over £45
    • For items over 100 it's 8% (or 9 for payment within 7 days)
    However, imprecise as it is, we will still use this description as the basis for examples to demonstrate the use of more formal techniques.

    Structured English (Pseudocode)

    Structured English is also known as pseudocode.
     
    (In the above diagram, red lines are used to make the nesting of the IF statements more obvious - such lines are not part of the Structured English technique)

    In the above figure, a simplified form of Structured English is shown on the left, and an abbreviated, more formal, version is shown on the right.

    Note that pseudocode can be used to describe a whole program.

    Decision Trees

    Pseudocode can include sequences, selections, anditerations.

    Decision trees are really quite straightforward methods of representing the logic of a process.
     

    Two alternative formats are shown here.

    In the example above:

    The second example below shows nodes as the possible decisions which can result from the previous node - 'states' to which the logic leads.

    Another decision tree

    Decision Tables

    The example we are using has quite a complicated set of conditions and is perhaps better described using a Decision Table.
     
    Decision Tables are easy to use. To demonstrate,  the figure here describes the example we are using
    (with a reduced set of conditions).

    Decision Tables have four sections, 
    created by two crossed lines;

     

    Logic Flowcharts

    The flowcharts we are looking at here are called 'logic' or 'program' flowcharts to differentiate them from 'system' flowcharts, which use an expanded notation to include input, output, and storage devices.

    Note that Flowcharts are not like Data Flow Diagrams.

    The first flowchart, shown below, departs from our example in order to show a less complex logic flow.

    The flowchart above shows a part of a program. The notation symbols used are shown on the left. They are again straightforward.

    Note that

    The following diagram uses a logic flowchart to describe the 'Calculate Discount' process, and includes all the conditions and actions.
     

    Questions
    1. Decisions: A person should never go to work if it is raining in December. On the days that she does go to work, she should take an umbrella when it is raining and an overcoat when it is windy. Unless it is windy, she must always take her hat when going to work. If it is windy in December, she should switch on her central heating.
      1. Construct a decision table to reflect the above decision making process.
      2. Describe the above decision making process using a flowchart.
      3. Describe the above decision making process using Structured English.
      4. Which of the above techniques is most appropriate for describing the example decision making process. Explain.
      5. Which of the techniques described in this page are suitable for creation of algorithms? Why?
    Tony Drewry
     
    Tony's Home Page