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
We are looking at certain techniques which are used in the design of
programs - particularly within the context of design of the design of
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.)
Diagrams - a quick review
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:
The fully decomposed model contains within it a sub-set of process boxes
which cannot be decomposed into lower level processes.
the main processes and activities (sub-systems) within the system are identified
each of the subsystems is decomposed into constituent sub-systems or processes
The identified sub-systems can then be decomposed further until we have
a set of diagrams for the system which cannot be decomposed further.
This set of non-decomposable diagrams is a model of the system.
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:
In this example, the target system has been shown in a diagram (A)
as having four top-level activities/processes.
The top-level process modelled as (box) 2 is shown here decomposed
in a new diagram
The new diagram (B) shows that the parent process ('box' 2)
is made up of three sub-processes. The sub-processes in diagram B
are given the numbers 2.1, 2.2, and 2.3.
The process shown as box 2.3 is further decomposed in a lower level
diagram (C) to show the 4 processes which make up the 2.3 activity;
and these processes are numbered 2.3.1, 2.3.2, etc.
These are, then, all processes at the lowest (final) level of decomposition.
|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
( 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
|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'
We now formally describe (and define) the low level units which make up
the target system.
The notation used must be able to describe the step-by-step flow and logic
within the process.
The formal definition of the process/unit is usually in a format which
is easily (and often mechanically) translatable into program code - if
a software implementation of that process is feasible, or required.
Thus we can specify the (typically) small pieces of code, or units, which
will eventually be linked together to form the programs which will be the
software of the target system.
|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,
In the figure below, box 2.3.3 from
the model above is identified as the process : 'Calculate
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
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
However, imprecise as it is, we will still use this description as the
basis for examples to demonstrate the use of more formal techniques.
English as Descriptive Language
An example: Description of Discount
If a purchase is for less than £100, then we give a discount
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)
Structured English is also known
(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
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.
The example on the right uses a more rigidly defined pseudocode format
similar to one which is used in the Jackson Structured Programming methodology.
Pseudocode in this format can be typed into a program editor and is practically
already in program code (with ready-made in-line comments).
Pseudocode can include sequences,
Decision trees are really quite straightforward methods of representing
the logic of a process.
Logic flowcharts can also describe these three programming constructs.
Decision Trees and Decision Tables are primarily for definition of selections
(eg: IF statements.)
The example process which we are using here, 'Calculate Discount', is a
set of choices and decisions.
A Decision Tree or Table would be an appropriate technique to use for describing
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.
The process starts with a question and branches to nodes
At these nodes further questions may be asked.
The question asked at any decision node can only be answered by 'yes' or
An answer may then provide a branch to another node, and so on
The final branch leads to the action which is the result of that set of
Another decision tree
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;
all possible conditions are
written in the top left section; known as the 'Condition Stub'
all possible actions which would
be the result of combinations of the conditions are listed in the bottom
left section - also known as the 'Action Stub'.
'rules' are created in the top
A 'rule' uses 'Y's or 'N's set against the conditions in a column.
The column of 'Y's and 'N's identifies a particular combination of conditions.
in the lower right section, 'X's are placed to show actions which are valid
for a given rule.
Rules creation is quite straightforward
(even if it doesn't appear so at first):
Although only 3 conditions are shown in the above figure, the process
'Calculate Discount' actually has 5 conditions (giving a total of 25,
= 32, rules).
the total number of rules is 2n where 'n' is the number of conditions.
Thus, in the diagram there are 23 rules (ie: 8 columns which
may contain 'Y's or 'N's.)
the lowest condition in the condition section has a row of entries in the
rules section made up of 'Y' followed by 'N' followed by 'Y' etc.
the next condition up has a doubled-up pattern of 'Y's and 'N's against
- ie: 2 'Y's followed by 2 'N's etc.
and the next condition up has the previous pattern doubled-up
- ie: 4 'Y's followed by 4 'N's etc.
and the doubling-up continues for however many conditions there are.
The figure below contains all the 'possible' rules for our 5 conditions.
On examination, however, some of the combinations are seen to be impossible.
For some combinations not all the conditions are relevant.
The Decision Table in the above box, is rationalized in the box which
Where it does not matter if the entry is 'Y' or 'N', a dash is used in
Note that all the rules shown in the above figure are
represented in the figure below:
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
The first flowchart, shown below, departs from our example in order to
show a less complex logic flow.
In a DFD the arrows represent the flow of data.
In flowcharts the arrows represent flow of control.
The flowchart above shows a part of a program. The notation symbols
used are shown on the left. They are again straightforward.
the diamond symbol (which shows a decision) has one point of entry - but
has two (only) points of exit.
The 'exit' from the decision is either 'yes' or 'no'.
In the diagram the principle part of the program has been described as
one action - 'Do Main'
The 'Do Main' action could be decomposed in another flowchart diagram.
The following diagram uses a logic flowchart to describe the
'Calculate Discount' process, and includes all the
conditions and actions.
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.
Construct a decision table to reflect the above decision making process.
Describe the above decision making process using a flowchart.
Describe the above decision making process using Structured English.
Which of the above techniques is most appropriate for describing the example
decision making process. Explain.
Which of the techniques described in this page are suitable for creation
of algorithms? Why?