top - metrics - download
⟦9fcd536ea⟧ Wang Wps File
Length: 8254 (0x203e)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN74.08«
Derivation
└─⟦84647c47a⟧ Bits:30005817 8" Wang WCS floppy, CR 0014A
└─⟦this⟧ »~ORPHAN74.08«
WangText
…02…SD/STD/005
…02…801020…02……02…#
SOFTWARE DESIGN GUIDELINE
…02……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 Documntation ......... 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 Simpliity .......................... 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 i 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 efined 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 an 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.2T̲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 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
) 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
andfit 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 procssing
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
canbe 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 n
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 oding.
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 ony 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 loer 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 ho)
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, nstead 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 canbe 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 lop
- 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 anydecision
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 my 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 documntation 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.
Furthr, 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̲ ̲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.
