top - download
⟦5df3c0c3d⟧ Wang Wps File
Length: 19370 (0x4baa)
Types: Wang Wps File
Notes: Software. design guidel.
Names: »0085A «
Derivation
└─⟦84647c47a⟧ Bits:30005817 8" Wang WCS floppy, CR 0014A
└─ ⟦this⟧ »0085A «
WangText
…02…SD/STD/005
…02…810526…02……02…#
SOFTWARE
DESIGN
GUIDELINE
…02…ISSUE
1…02…GENERAL
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE ....................................... 4
2 PURPOSE ..................................... 4
3 DESIGN GUIDELINES ........................... 4
to 18
3.1 DEFINITION ............................... 4
3.2 THE DESIGN PROCESS ....................... 5
3.3 TOP DOWN DESIGN .......................... 6
3.3.1 Hierarchical Structure ............... 6
3.3.2 Level by Level Documentation ......... 6
3.3.3 Final Documentation .................. 8
3.3.4 Elementary Processes ................. 8
3.4 STRUCTURED DESIGN ........................ 9
3.4.1 Control Structures ................... 9
3.4.2 Modularity ........................... 11
3.4.2.1 Module Strength .................. 11
3.4.2.2 Module Coupling .................. 13
3.4.2.3 Reference ........................ 14
3.5 OTHER MEASURES ............................15
3.5.1 Simplicity .......................... 15
3.5.2 Visibility .......................... 15
3.5.3 Module Size ......................... 15
3.5.4 Common Subfunctions ................. 16
3.6 ACTIVE DEFENSIVE MEASURES ................ 16
3.6.1 General ............................. 16
3.6.2 Credibility Check ................... 16
3.6.3 Traceability Counters ............... 17
3.6.4 Checksum ............................ 17
3.7 VERIFICATION ............................. 17
3.7.1 Verifiable Design .................... 18
3.7.2 Definition of Verification ........... 18
1̲ ̲ ̲S̲C̲O̲P̲E̲
This standard is a derivative of software standard
manual SD/STM/003 and has the same scope and applicability.
2̲ ̲ ̲P̲U̲R̲P̲O̲S̲E̲
The purpose of this standard is to define a series
of aspects of software design which is critical for
the attainment of reliable software and therefore must
be considered carefully by software designers.
3̲ ̲ ̲D̲E̲S̲I̲G̲N̲ ̲G̲U̲I̲D̲E̲L̲I̲N̲E̲S̲
3.1 D̲E̲F̲I̲N̲I̲T̲I̲O̲N̲
Software design can be defined as a process in which
the requirements of a software product is transformed
into a description of software which will actually
be able to perform the required functions.
The outcome of this transformation shall be a set of
documents which can be utilized directly as the input
for the programmers who shall implement the software.
The produced documentation must be complete except
for general information on such items as
programing language
compiler/assembler
hardware
other development tools
3.2 T̲H̲E̲ ̲D̲E̲S̲I̲G̲N̲ ̲P̲R̲O̲C̲E̲S̲S̲
The design of a unit shall be a process in which the
designer performs at least the following functions:
a) evaluates the input
b) defines the functions to be performed by the unit
c) defines a split of the function into a number of
subfunctions
d) defines the structure of the control flow within
the unit.
e) defines the interaction which the unit must have
with other units
f) produces documentation of the unit
g) defines input to and output from the unit
h) defines data to be used in the unit
i) defines the test(s) to be necessary to verify the
design.
No specific methodology will be prescribed for the
design process except as follows:
a) The resulting documentation must comply to standard
and fit into the hierarchical structure.
b) The material produced must be kept in accordance
with the UDF standard
c) The following guidelines shall be considered seriously
and be followed to the largest possible extend.
3.3 T̲O̲P̲ ̲D̲O̲W̲N̲ ̲D̲E̲S̲I̲G̲N̲
Software Design shall proceed in a top down manner,
that is, the overall aspects of the product shall be
processed first, continuing with succesive steps processing
an increasing level of details in each step.
3.3.1…02…H̲i̲e̲r̲a̲r̲c̲h̲i̲c̲a̲l̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The design shall result in a split of the product into
a number of units (modules). Interrelations between
units shall be defined in such a way that the system
can be described as a treelike hierarchical structure
as the example shown in fig. 1.
The number of levels in the hierarchy shall be as many
as necessary to give a clear and understandable description
of the system, with units which can be described in
independent entities of documentation of reasonable
size.
The lowest level of the tree shall represent units
which are to be coded as separate code units and the
description of those units must be detailed enough
to be used as direct input for coding.
All interaction between two branches must be defined
within the unit where the branches meet. No interaction
is allowed at lower levels.
3.3.2 L̲e̲v̲e̲l̲ ̲b̲y̲ ̲L̲e̲v̲e̲l̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Each unit shall be designed as an independent entity.
The only input which shall be necessary to design a
unit shall be the documentation of its parent unit
and its ancestors. The design of a unit must therefore
result in a documentation which can serve as such input
to the design of the units of the next lower level.
fig. 1
The documentation of a unit shall be able to answer
the following questions in a clear and unambiguous
way:
a) what am I part of
b) what am I
c) who do I interact with (and how)
d) what do I consist of
3.3.3 F̲i̲n̲a̲l̲ ̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
The final software documentation may be organized in
only a few levels (1 to 3 typically) for practical
reasons. This shall not limit the design break down
to the same low number of levels, instead several levels
of design breakdown shall be fitted into each documentation
level.
3.3.4 E̲l̲e̲m̲e̲n̲t̲a̲r̲y̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
The Top down breakdown shall eventually lead to a breakdown
of the system into elementary processes.
Elementary processes can be of 3 types:
a) Decisive processes:
A process containing one single decision point
with the associated examination of a data item.
A decisive process may when coding be translated
into
- an if-then-else construct
- the control of a loop
- a case construct.
b) Data handling processes.
A process which performs some kind of transformation
on an elementary data item (an elementary data
item in this context is a single ... or a group
of closely related data items) without any decision
points enclosed. The transformation in question
may be any which can be translated into a short
piece of purely sequential code.
c) Simple compound processes.
Compound processes will be such which are composed
of two or more of the above defined strictly elementary
processes. A simple compound process may be considered
elementary and thus needs no further breakdown
in the design provided:
- it contains only a few elements
- it have low complexity
- it has only one entry and one exit
- it handles only one elementary data item.
The documentation resulting from the design shall
contain descriptions of all elementary processes
in plain language. This description shall be phrased
in such a way that a programmer can understand
it and translate it into code without difficulty.
Further, the description shall fit into the source
code as a comment to the code performing the process.
In all diagrams (HIPO and flowgrams) the elementary
processes shall be represented with each one entry.
3.4 S̲T̲R̲U̲C̲T̲U̲R̲E̲D̲ ̲D̲E̲S̲I̲G̲N̲
3.4.1 C̲o̲n̲t̲r̲o̲l̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲s̲
When defining the control flow within a software module
the principles known as "Structured Design" shall be
applied.
These principles prescribe that the control flow must
be a combination of only 3 simple control flow structures
a) Sequence
b) Loop
c) Branching (IF THEN ELSE or CASE)
Fig 2 shows the flow charts describing those structure.
fig 2.
More complicated structures may be built by combining
those structures or/and by replacing the function boxes
of the simple structures by other incarnations of the
simple structure.
When defining the control structure the designer shall
always aim at producing the simplest possible control
structure, which is sufficient to perform the required
functions
3.4.2 M̲o̲d̲u̲l̲a̲r̲i̲t̲y̲
The optimal modular design is one in which the relationships
among elements not in the same module are minimized.
There are two ways of achieving this: minimizing the
relationships among modules and maximizing relationsips
among elements in the same module. These two methods
are complementary and are used together. Module coupling
is used to minimize the relationships among modules.
Module strength is used to maximize the relationships
among elements in individual modules.
3.4.2.1 M̲o̲d̲u̲l̲e̲ ̲S̲t̲r̲e̲n̲g̲t̲h̲
The second method, maximizing relationships among elements
in the same module, is the subject of this paragraph.
Element in this sense means any form of a piece of
the module, such as a statement, a segment, or a subfunction.
Any program has certain relationships among all of
its elements. The basic intent of module strength is
to organize these elements so that closely related
elements fall into a single module and unrelated elements
fall into separate modules.
The measure of module strength is one of the most important
measures of a modular design. The scale of strength,
from highest to lowest, is: functional, informational,
communicational, procedural, classical, logical, and
coincidental. This scale is not linear. Functional
strength and informational strength are much stronger
than all the rest, and the last three are much weaker
than all the rest.
In the following each type of strength will be defined:
a) COINCIDENTAL:
There are no meaningful relationships among the
elements of a module.
b) LOGICAL:
There are some logical relationships among the
elements of a module. The module performs, at each
invocation, one of a class of related functions.
c) CLASSICAL:
Classical strength is the same as logical strength,
except that the elements are also related in time.
Thus a module with classical strength performs
a class of functions where the functions are also
related in time.
d) PROCEDURAL:
Procedural-strength modules perform more than one
function where the functions are related in respect
to the procedure of the problem. Procedural- strength
modules are often the result of flowcharting the
problem to be solved and then defining modules
to represent one or more blocks in the flowchart.
e) COMMUNICATIONAL:
A module with communicational strength is a module
with procedural strength and an additional characteristic-all
of the elements "communicate" with one another.
That is, the elements in the module either reference
the same set of data or they pass data among themselves:
for example, the output of one element is the input
of another element.
f) INFORMATIONAL:
A module with informational strength performs multiple
functions where the functions, represented by entry
points in the module, deal with a single data structure.
In other words, this module
represents the physical packaging together (into
one module) of two or more modules having functional
strength.
g) FUNCTIONAL:
Functional strength is at the top of the strength
scale. In a functional-strength module all of the
elements are related to the performance of a single
function.
A question that always arises at this point is,
what is a function? In mathematics y = f(x) is
read "y is a function f of x". The function f defines
a transformation, or mapping of the independent
(or input) variable x into the dependent (or output)
variable y. Hence a function describes a transformation
from some input data to some output data. In terms
of programming this, definition is expanded to
allow functions with no input data and functons
with no output data.
3.4.2.2 M̲o̲d̲u̲l̲e̲ ̲C̲o̲u̲p̲l̲i̲n̲g̲
Coupling is the second measure of the independence
of modules. Since a highly modular design is achieved
by maximizing the relationships among the elements
of a module and minimizing the relationships among
modules, the scale for coupling is inverse to the scale
for strength. Thus the goal is achieving high strength
and low coupling. The scale of coupling, form lowest
coupling (best) to highest (worst), is data coupling,
stamp coupling, control coupling, external coupling,
common coupling, and content coupling. Following the
pattern of the previous paragraph, this paragraph will
define each type of coupling.
a) CONTENT:
Two modules are content coupled if one module makes
a direct reference to the contents of the other
module.
b) COMMON:
A group of modules is common coupled if they reference
a shared global data structure (a common environment)
c) EXTERNAL:
Two modules are external coupled if they both reference
the same externally declared symbol. External coupling
is similar to common coupling except that, in external
coupling, the references between modules are to
individual data items, not to data structure.
d) CONTROL:
Two modules are control coupled if one module passes
elements of control as arguments to the other module.
An element-of-control argument directly influences
the execution of the called module. Typical elements
of control are function codes, flags, and switches.
e) STAMP:
Two modules are stamp coupled if they reference
the same data structure, providing that this data
structure is not global (not in the common environment).
f) DATA:
Two modules are data coupled if one calls the other
and they are not content, common, external, control,
or stamp coupled. In other words, all input and
output to and from the called module is passed
as arguments. Also, all of the arguments are data
elements, not control elements or data structures.
3.4.2.3 R̲e̲f̲e̲r̲e̲n̲c̲e̲
Further explanation of the above defined concepts as
well as other useful desing guidelines can be found
in
Glenford J. Myers:
Reliable Software through Composite Design
3.5 O̲T̲H̲E̲R̲ ̲M̲E̲A̲S̲U̲R̲E̲S̲
3.5.1 S̲i̲m̲p̲l̲i̲c̲i̲t̲y̲
An obvious means of obtaining a good design is to keep
anything as simple as possible.
Whenever more than one solution fulfil the requirements
of a module the simplest shall be chosen as the simple
solution, being easier to understand, has a more possitive
effect on the future maintenance and modification costs
of the module.
3.5.2 V̲i̲s̲i̲b̲i̲l̲i̲t̲y̲
When defining the control flow, data structures, interactions,
etc. within a software unit, structures shall be chosen
which facilitates visibility.
Visibility in this context means that it shall be possible
to produce documentation of the design, which is easily
understandable for personnel with the proper background.
All "tricks" and "smart" utilization of programming
language features must be avoided if such utilization
makes the design obscure and ununderstandable.
3.5.3 M̲o̲d̲u̲l̲e̲ ̲S̲i̲z̲e̲
The size of modules shall be kept as low as possible
as this measure also enhance simplicity, visibility
and independance of the module.
No module may exceed 250 statements unless a positive
argumentation herefore has been presented to and approved
by QA.
3.5.4 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
Common subfunctions such as the square root function
in fig. 1 shall be designed (and coded) with special
care in order to avoid side effects, and in order to
ensure that the subfunction can be performed correctly
independent of the calling function.
Thus all input to such subfunctions must be passed
through parameters at the call and all output from
such subfunctions passed through parameters at the
return to the caller.
Access to global data from common subfunctions shall
be avoided if ever possible. If not possible the utmost
care shall be exercised in order to avoid unwanted
coupling between callers of the common subfunction
through unexpected modification of the shared data.
Control flow may never be changed by the call of a
common subfunction. Return shall always be to the same
place from where the function was invoked.
3.6 A̲C̲T̲I̲V̲E̲ ̲D̲E̲F̲E̲N̲S̲I̲V̲E̲ ̲M̲E̲A̲S̲U̲R̲E̲S̲
3.6.1 G̲e̲n̲e̲r̲a̲l̲
The previous chapter has been concerned with "passive
measures" that is mainly rules which aim at reducing
the risk for unintended inclusion of harmfull factors
in the produced software.
Software must also actively assist its own integrity
by performing checks within each module. As such checks,
however, means extra use of computer resources it is
necessary to perform a careful evaluation in each case
of a check and its potential degradation of performance.
3.6.2 C̲r̲e̲d̲i̲b̲i̲l̲i̲t̲y̲ ̲C̲h̲e̲c̲k̲
Each module should contain credibility check to contain
the effects of corrupt or inaccurate input data. It
shall be a design aim to utilize such checks in such
a
way that a fault developing in one module is unable
to propagate through the system and affect transactions
taking place elsewhere or at a later time.
3.6.3 T̲r̲a̲c̲e̲a̲b̲i̲l̲i̲t̲y̲ ̲C̲o̲u̲n̲t̲e̲r̲s̲
Traceability of module usage shall be provided by the
accessing within the module of discreet counters. Each
such counter is a single integer variable within a
common data area dedicated this purpose.
At least one such counter shall be designed into each
module in order to record the number of times entry
is affected to the module.
Dependent on the functions of the module other counters
which will be useful in enhancing traceability of module
execution shall be designed.
One module of a software system shall be dedicated
the function of outputting the content of the counters
as required.
3.6.4 C̲h̲e̲c̲k̲s̲u̲m̲
All software modules shall as their object form shall
contain a checksum making it possible to detect any
corruption of the module.
The software system shall contain means for utilizing
this checkcum to detect and replace corrupted modules.
3.7 V̲E̲R̲I̲F̲I̲C̲A̲T̲I̲O̲N̲
Verification shall be taken into account during design
as described below. Further details of the subject
is found in Software Verification Guideline SD/STD/012.
3.7.1 V̲e̲r̲i̲f̲i̲a̲b̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The structure of a software unit shall be chosen in
a way which makes verification as easy as possible.
Structures which cannot be verified must be avoided.
3.7.2 D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲o̲f̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The activities (test, analysis, etc.) which are necessary
to verify a unit shall be defined as part of the design
activity, and the necessary test procedures shall be
part of the documentation which are produced.
