Hardware Reference
In-Depth Information
If you can answer with an unqualified 'yes' to the majority of the foregoing
questions, you can be assured that the language under consideration is an ideal
candidate for software development in the control and instrumentation field.
Coupled with an Integrated Development Environment (editor and debugger)
it should be able to cope with almost anything!
With modern operating systems the
Protected Mode
environment provides an
environment which can support true multi-tasking and this allows
event-driven
programs
to be developed. Such programs allow a
main process
to exist along
with a number of
sub-processes
, each of which shares some of the processor's
time. We shall return to this important theme a little later in this chapter.
Software development
Software development should normally be a top-down process in which one
moves from the general to the specific. The process can be divided into a
number of identifiable phases which generally include:
1 Problem
analysis
, leading to
2a
software specification
.
3 Development of an
algorithm
and
4a
program definition
.
5
Coding
and
6
testing
(against the specification) and
7
debugging
.
8
Implementation
and
9
evaluation
.
10
Finally, there will be a need for
ongoing maintenance
.
In practice, Steps (5), (6), and (7) will invariably be repeated a number of times
in order to refine the software and eliminate errors made during the coding
phase. At this stage, it is perhaps worth examining each of the phases in the
software development cycle
in a little more detail.
The first two stages (problem analysis and the production of a software speci-
fication) involve first determining the user's requirements, and then itemizing
the functions and facilities expected of the software. The specification should,
of course, be agreed with the user. Furthermore the initial stages will normally
require a dialogue with the user in order to establish the parameters within
which the system should operate. Very few users are able to give a precise
definition of their requirements and, since it is important to consider all eventu-
alities, it is important to explore with the user what should happen in abnormal
circumstances as well as in routine situations.
As an example, consider the case of the operator of an aggregate processing
plant that comprises several conveyor belts, processing drums, and a washing
plant. The problem essentially involves delivering various grades of aggregate
at rates which are sufficient to ensure that the capacity of the stockpile is not
exceeded and that a certain minimum amount of each grade of material is
always available. The software specification (agreed with the operator) will
involve delivery rates and volumes. However, the plant operator may forget
to mention that, in the event of an interruption of the water supply, part of
the plant must shutdown with a consequent and drastic change in delivery
rates.
