top - download
⟦66604995a⟧ Wang Wps File
Length: 9757 (0x261d)
Types: Wang Wps File
Notes: Intern meddelelse nr. 222
Names: »1320A «
Derivation
└─⟦0f7ba544d⟧ Bits:30006063 8" Wang WCS floppy, CR 0095A
└─ ⟦this⟧ »1320A «
WangText
…00……00……00……00……00…3…86…1 …02… …02… …02…
…02…
…02…KNN/811023…02……02…#
INTERN MEDDELELSE NR. 222
…02……02…CAMPS
To: SW Team
Cc: GJ, FE
Fm: KNN
S̲u̲b̲j̲e̲c̲t̲:̲ ̲D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲
I̲n̲t̲r̲o̲d̲u̲c̲t̲i̲o̲n̲
This note replaces INTERN MEDDELELSE NR. 219.
Detailed design guidelines previously contained in
INTERN MEDDELELSE NR. 196 and 206 have been replaced
by CPS/AUX/017.
This note supplements the above documents with very
specific examples of detailed design documentation/
layout, which should be used by everybody as guidelines
to document their design.
D̲E̲T̲A̲I̲L̲E̲D̲ ̲D̲E̲S̲I̲G̲N̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲E̲X̲A̲M̲P̲L̲E̲S̲
The examples are:
- module interface definition
- module data definition
- variable definition
- flowgram symbols (relation operators)
M̲O̲D̲U̲L̲E̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲ ̲D̲E̲F̲I̲N̲I̲T̲I̲O̲N̲
A software module interface will be described in section
4.1.6, 4.2.X.6, and/or 4.2.X.4.Y.2. Section 4.1.6 and
4.2.X.6 do only apply to package/subpackage interface
modules.
The interface specification contains three parts which
are:
- Flowgram call spec.
- FORMAL SWELL call spec.
- Register convention
The flowgram call spec. shall highlight
- FUNCTION (INPUT)(OUTPUT)
The formal SWELL call spec. is the description as it
appears in a SWELL program.
The register convention shall describe which registers
that are kept and which are destroyed.
E̲x̲a̲m̲p̲l̲e̲:̲ ̲"̲S̲e̲c̲t̲i̲o̲n̲"̲ ̲W̲a̲i̲t̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲S̲e̲m̲a̲p̲h̲o̲r̲e̲
4̲.̲2̲.̲X̲.̲4̲.̲Y̲.̲1̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Waits for the next operation in an operation semaphore.
If the semaphore is in the open state, the first operation
will be delivered to the calling coroutine. Otherwise
the coroutine will be chained the semaphore and set
into waiting state.
The procedure has a waiting point.
4̲.̲2̲.̲X̲.̲4̲.̲Y̲.̲2̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
C̲a̲l̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
a) WAIT ̲OPERATION ̲SEMAPHORE
(SEMAPHORE: COROUTINE ̲SEMAPHORE)
(OPERATION: COROUTINE ̲OPERATION):
OK
b) COMON(WAIT ̲OPSEM, R4, R5, R6):OK
R̲E̲G̲I̲S̲T̲E̲R̲ ̲C̲O̲N̲V̲E̲N̲T̲I̲O̲N̲
C̲a̲l̲l̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R4 Pointer to SEMAPHORE (KEPT)
R6 LINK (DESTROYED)
R̲e̲t̲u̲r̲n̲ ̲R̲e̲g̲i̲s̲t̲e̲r̲s̲
R5 Pointer to OPERATION
R6 Pointer to current COROUTINE
R0-R3,R7 DESTROYED
F̲a̲t̲a̲l̲ ̲E̲r̲r̲o̲r̲s̲
None
Interface types shall be defined in:
4.1.4 and 4.1.5 For Package Interfaces
4.2.X.5 For Subpackage Interfaces
4.2.X.4.Y.4 For Module Interfaces
For Wait Operation Semaphore the following definitions
exist in 4.1.6:
COROUTINE ̲SEMAPHORE = RECORD
NEXT,
PREVIOUS: POINTER;
"The link fields to
the list of operations
or coroutines"
COUNT: INTEGER;
"If positive it is
the number of operation
list. If negative,
it is the number of
waiting coroutines.
END;
COROUTINE ̲OPERATION= RECORD
.
.
.
END;
COROUTINE ̲RECORD= RECORD
.
.
.
END;
M̲O̲D̲U̲L̲E̲ ̲D̲A̲T̲A̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
4.2.X.4.Y.4: Data Description
This paragraph shall contain a description of/or reference
to the data used by the module Y contained in subpackage
X. The description may be divided into the following
3 parts:
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲:̲
Contains the symbolic names of data-areas (buffers,
arrays, records, etc.) applicable to the module,
and a reference to the document and/or section
where supplementary descriptions can be found for
each data-area.
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲
Contains the specific symbolic names of external
data-elements read or modified by the module.
If an external data-element is modified, this shall
be indicated by an (M).
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲
Contains a specification of the local data used
by the module (and its procedures).
If these data are specifed elsewhere (and described
as reference data), they can be described like
external data; otherwise a type-definition plus
supplementary comments shall be specified.
Note that local data of one module can be external
data to a lower level module in the same structure.
The parameters received by the module need not
be specified as local data if that data are kept
in the registers. In most cases parameters should
be saved in local variables and therefore be defined
in this subpara.
E̲x̲a̲m̲p̲l̲e̲ ̲F̲L̲2̲-̲A̲n̲a̲l̲y̲s̲i̲s̲ ̲M̲o̲d̲u̲l̲e̲
4.2.X.4.Y.4: Data Description
a) D̲a̲t̲a̲ ̲R̲e̲f̲e̲r̲e̲n̲c̲e̲s̲:̲
FIELD1-RECORD (DBD/001 section 10)
LOCAL-RI-TABLE (DBD/001 section 7)
RI-LIST (Section 4.2.1.4.X)
STATUS-RECORD (Section 4.2.1.4.X)
b) E̲x̲t̲e̲r̲n̲a̲l̲ ̲D̲a̲t̲a̲:̲
FIELD1.ACTION ̲PRECEDENCE (m)
RILIST.RI (m)
RILIST.LINE (m)
STATUS.RILIST ̲RECORD (m)
STATUS.LINE
STATUS.PILOT
STATUS.INCOMING
STATUS.REENTERED
STATUS.STOP (m)
c) L̲o̲c̲a̲l̲ ̲D̲a̲t̲a̲:̲
POINT-RI: INTEGER; address of RI FL2
PRECEDENCE: BYTE; precedence to be analysed
BELL ̲SIGNAL: BOOLEAN; bell-signal identified
PREC-FOUND: BOOLEAN; precedence found
B3: D̲E̲T̲A̲I̲L̲E̲D̲ ̲D̲E̲S̲I̲G̲N̲ ̲D̲E̲F̲I̲N̲I̲T̲I̲O̲N̲ ̲O̲F̲ ̲V̲A̲R̲I̲A̲B̲L̲E̲S̲
In the data section 4.2.X.5, 4.2.X.4.Y.4, 4.1.4, or
4.1.5 in detailed design type and variable definition
are specified together.
The following standard is used:
VAR IDENTIFIER : TYPE
"Reference to type def.
INIT IDENTIFIER = INITVALUES
"Description"
Type may be:
- A global type identified in DBD section 4.1
- a type common for the package or subpackage.
Package common types are defined in SDS section 4.1.5.
Subpackage common type is defined in SDS section 4.2.X.5.
Single type definitions are defined directly.
For arrays and records, word level diagrams may also
be used.
For records containing different formats the different
records are defined separately. A general type definition
is specified at first. Refer to example 3.
E̲x̲a̲m̲p̲l̲e̲ ̲1̲
VAR: MAX ̲FREE ̲CP: 1..MAX ̲CPS;
"MAX ̲CPS=4
INIT: MAX ̲FREE ̲CP = 1
"No. of outstanding checkpoints
E̲x̲a̲m̲p̲l̲e̲ ̲2̲
VAR: CLASS ̲TABLE: ARRAY 0..127 OF
RECORD
GROUP: 1..10;
VALUE: LONG
END
"initialization value: undefined
"description: narrative
WORD LEVEL DIAGRAM:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
0 CLASS ̲TYPE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
127 ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 GROUP
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2
VALUE
3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
E̲X̲A̲M̲P̲L̲E̲ ̲3̲
TYPE CP ̲TYPE = (LOG, CIF);
LOG ̲CHECKPOINT = RECORD
RECORD ̲TYPE: CP ̲TYPE;
CP ̲DATA: ARRAY 1..MAX ̲LOG
OF INTEGER
"MAX ̲LOG = 5
END
CIF ̲CHECKPOINT = RECORD
RECORD ̲TYPE: CP ̲TYPE;
CP ̲DATA: RECORD
CP ̲NO: (1..150);
DATA: ARRAY 1..512
OF INTEGER
END
END
"The field RECORD ̲TYPE DEFINES if the record
"is of type LOG ̲CHECKPOINT OR CIF ̲CHECKPOINT
"Initializaton value: undefined
"description: diller daller
WORD ̲LEVEL ̲DIAGRAM:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 CP-TYPE = LOG
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2
CP ̲DATA
6 ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
1 CR ̲TYPE = CIF
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
2 CP-NO
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
3
CP-DATA
512+2 ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
B4: R̲E̲L̲A̲T̲I̲O̲N̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲A̲R̲I̲T̲H̲M̲E̲T̲I̲C̲ ̲O̲P̲E̲R̲A̲T̲I̲O̲N̲ ̲I̲N̲
̲F̲L̲O̲W̲G̲R̲A̲M̲S̲
Due to the text processing system capabilities, the
following notation shall be used:
= NE
= EQ
GT
= GE
LT
= LE
* Multiplication
/ Division
+ Addition
- Subtraktion
A: A̲ ̲S̲T̲R̲U̲C̲T̲U̲R̲E̲ ̲O̲F̲ ̲S̲E̲C̲T̲I̲O̲N̲ ̲4̲.̲2̲.̲X̲ ̲I̲N̲ ̲D̲E̲T̲A̲I̲L̲E̲D̲ ̲D̲E̲S̲I̲G̲N̲
̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲S̲
4.2.X Subpackage (X) Specification
4.2.X.1 Functional Specification
4.2.X.2 Software Structure
4.2.X.3 Data Flow and Control Logic Within Subpackage
4.2.X.4 Module Specification
4.2.X.4.Y Module Y Specification
4.2.X.4.Y.1 Functional Description
4.2.X.4.Y.2 Module Interface
4.2.X.4.Y.3 Module Components
4.2.X.4.Y.4 Data Description
4.2.X.4.Y.5 Module Design
4.2.X.5 Subpackage Data
4.2.X.6 Subpackage Interfaces
Note 1: Contents of 4.2.X.4.Y.1 - 4.2.X.4.Y.5 are
described in INTERN MEDDELELSE NR. 206
Note 2: Section 4.2.X.3 shall only reflect dataflow
and conrol logic between modules as the
module internal processing is described
in section 4.2.X.4.Y.5.
Note 3: Functional Specification section 4.2.X.1
and 4.2.X.4.1.1 shall always consider initialization
error processing etc. (refer CPS/AUX/010
section 2.2.2)
Note 4: Functional descriptions contained in 4.2.X.1
and 4.2.X.4.Y.1 describe w̲h̲a̲t̲ functions
the software performs, while section 4.2.X.3
and 4.2.X.4.Y.5 describe h̲o̲w̲ the software
performs the functions.
Note 5: Sections 4.2.X.2 and 4.2.X.4.Y.3 present
a s̲t̲a̲t̲i̲c̲ picture of the software components
while section 4.2.X.3 and 4.2.X.4.Y.5 describe
the dynamic aspects of the software.