top - download
⟦77adf7c87⟧ Wang Wps File
Length: 19677 (0x4cdd)
Types: Wang Wps File
Notes: Detailed Des.Spec.Guidel.
Names: »1404A «
Derivation
└─⟦c9afadba6⟧ Bits:30006061 8" Wang WCS floppy, CR 0093A
└─ ⟦this⟧ »1404A «
WangText
…02…CPS/AUX/017
…02…KNN/811028…02……02…#
DETAILED DESIGN SPECIFICATION GUIDELINES
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 INTRODUCTION ................................
1.1 APPLICABLE DOCUMENTS ....................
2 DETAILED DESIGN SPECIFICATION
(DDS) TABLE OF CONTENTS OUTLINE .............
3 STRUCTURE OF DDS ............................
4 GUIDELINES FOR SECTION 4 of DDS .............
4.1 PACKAGE OVERVIEW ........................
4.1.1 Functional Specification ............
4.1.2 Software Specification ..............
4.1.3 Data Flow and Control Logic .........
4.1.4 Common Package Data .................
4.1.5 Common Package Procedures ...........
4.1.6 Global Data .........................
4.1.7 Interfaces ..........................
4.1.7.1 External Interfaces .............
4.1.7.2 Package Interfaces ..............
4.1.7.3 Sub-Package Interfaces ..........
4.2 Subpackage (X) Specification ............
4.2.1.1 Functional Specification ........
4.2.1.2 Software Structure ..............
4.2.1.3 Data Flow and Control
Logic within Subpackage .........
4.2.1.4 Module Specifications ...........
4.2.1.4.1 Module Y Specification ......
4.2.1.4.1.1 Functional Specification.
4.2.1.4.1.2 Module Interface ........
4.2.1.4.1.3 Module Components .......
4.2.1.4.1.4 Data Description ........
4.2.1.4.1.5 Module Design ...........
4.2.1.5 Common Subpackage Data ..........
4.2.1.6 Common Subpackage Procedures ....
4.2.1.7 Subpackage Interfaces ...........
4.3 MEMORY LAYOUT ...........................
1̲ ̲ ̲I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
This note presents the general guidelines to be fulfilled
by all detailed design specifications.
The note begins by presenting an outline to a table
of contents for detailed design specifications.
Next the structure of the DDS and the major DDS sections
are discussed in terms of contents and scope.
1.1 A̲P̲P̲L̲I̲C̲A̲B̲L̲E̲ ̲D̲O̲C̲U̲M̲E̲N̲T̲S̲
- Package Design specification Guidelines
CPS/AUX/010
- SW Design Guidelines
SD/STD/005
- SW Doc. Standards
o SD/STD/008
o SD/STD/013
- SE Eng. Requirements
CAMPS Standard Manual Vol. B, M.
2̲ ̲ ̲D̲D̲S̲ ̲T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲ ̲O̲U̲T̲L̲I̲N̲E̲
The table of contents presented overleaf may be expanded
into sub-sections (max. index level is 6).
The sections listed are mandatory in all package specifications.
Sections which do not apply to a package shall contain
a N/A (not applicable)
PACKAGE DESIGN SPECIFICATION…01……01…TABLE OF CONTENTS OUTLINE
1 GENERAL
1.1 PURPOSE AND SCOPE
1.2 APPLICABLE DOCUMENTS AND PROJECT REFERENCES
1.2.1 APPLICABLE DOCUMENTS
1.2.2 PROJECT REFERENCES
1.3 TERMS AND ABBREVIATIONS
1.3.1 TERMS
1.3.2 ABBREVIATIONS
2 SUMMARY OF REQUIREMENT
2.1 PACKAGE DESCRIPTION
2.2 PACKAGE FUNCTIONS
2.2.1 MAIN FUNCTIONS (NORMAL OPERATION)
2.2.2 FUNCTIONAL RESPONSIBILITIES
2.2.2.1 INITIALIZATION, CLOSE DOWN, AND RESTART
2.2.2.2 CHECK POINTING AND RECOVERY
2.2.2.3 ERROR DETECTINg AND ERROR HANDLING
2.2.2.4 INTEGRITY OF OPERATION
2.2.2.5 DATA COLLECTION (LOG, STATISTICS, AND
REPORTS)
2.2.2.6 SECURITY
2.3 CHARACTERISTICS
2.3.1 TIMING
2.3.2 THROUGHPUT
2.3.3 FLEXIBILITY
2.3.4 ACCURACY
3 ENVIRONMENTS
3.1 EQUIPMENT
3.2 SOFTWARE
3.2.1 SYSTEM SOFTWARE
3.2.2 DEVELOPMENT SUPPORT SOFTWARE
3.3 INTERFACES
3.3.1 EXTERNAL INTERFACES
3.3.2 PACKAGE INTERFACE
3.4 FUNCTIONS MAINTAINED BY OTHER PACKAGES
4 PACKAGE DESIGN
4.1 PACKAGE OVERVIEW
4.1.1 FUNCTIONAL SPECIFICATION
4.1.2 SOFTWARE SPECIFICAION
4.1.3 DATA FLOW AND CONTROL LOGIC
4.1.4 COMMON PACKAGE DATA
4.1.5 COMMON PACKAGE PROCEDURES
4.1.6 GLOBAL DATA
4.1.7 INTERFACES
4.1.7.1 EXTERNAL INTERFACES
4.1.7.2 PACKAGE INTERFACES
4.1.7.3 SUB-PACKAGE INTERFACES
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 Specifications
4.2.X.4.Y Module Y Specification
4.2.X.4.Y.1 Functional Specification
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 Common Subpackage Data
4.2.X.6 Common Subpackage Procedures
4.2.X.7 Subpackage Interface
4.3 MEMORY LAYOUT
3̲ ̲ ̲S̲T̲R̲U̲C̲T̲U̲R̲E̲ ̲O̲F̲ ̲T̲H̲E̲ ̲D̲D̲S̲
The DDS has been divided into four chapters. The objectives
for each chapter are presented below.
Chapter 1 shall contain a presentation (purpose and
scope) of the specification, define the baseline documents
and define terms/abbreviations used within the specification.
Chapter 2 shall define the package functions and characteristics
to be implemented. The functions shall be described
at a level similar to the SRS. Chapter 2 shall define
what functions are to be implemented and not how these
are implemented.
Chapter 3 shall define what the package environments
are. How interfaces are implemented shall not be described
in chapter 3.
Chapter 4 shall contain the actual design which implements
the functional requirements described in chapter 2
and 3.
For the contents of DDS chapter 1-3, please refer CPS/AUX/010
and for the contents of DDS chapter 4 please refer
to chapter 4 of this document.
4̲ ̲ ̲G̲U̲I̲D̲E̲L̲I̲N̲E̲S̲ ̲F̲O̲R̲ ̲C̲H̲A̲P̲T̲E̲R̲ ̲4̲ ̲O̲F̲ ̲D̲D̲S̲
This chapter describes the contents of the sections
in chapter 4 of the DDS.
4.1 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲1̲:̲
P̲a̲c̲k̲a̲g̲e̲ ̲O̲v̲e̲r̲v̲i̲e̲w̲
Section 4.1 presents an overview at subpackage level
of concurrent and sequential processing within the
package with clear definition of the role of each sub-package
which are described more detailed in section 4.2.X.
4.1.1 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲1̲.̲1̲:̲
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The package functions described in DDS section 2.2.1
and 2.2.2 should be broken down to the level functional
which justifies allocation of the subpackages described
further in section 4.2.X.
4.1.2 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲1̲.̲2̲:̲
S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
This section describes Software structure and the allocation
of functions onto the software elements such processes,
shared procedures (between two processes), monitor
procedures (only for CSF, SSC, and DAMOS) or co-routines.
Based on the above software structure sub-packages
shall be defined.
For each of the sub-packages the following elements
shall be contained.
1) Functions allocated to the subpackage (refer 4.1.1).
2) Software structure (Software hierarchy) which corresponds
with the functional break-down of section 4.1.1.
The software structure shall be presented by a chart
which shows the software break-down. (Similar to chart
presented in section 4.1.1).
4.1.3 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲1̲.̲3̲:̲
D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Data flow and control logic related to major transaction
within a package shall be described at the sub-package
level (Interaction between subpackage)
The tools to document flow/logic are block diagrams
for process or coroutine synchronization/communication
and HIPO's and/or flowgrams for sequential processing.
For the highest level of design description HIPO shall
be used for sequential processing and block diagrams
for concurrent processing.
At lower levels of the design flowgrams will be the
most relevant design documentation method.
At intermediate levels of design a mixture of HIPO
and flowgram shall be used.
The question is however "at what level do we start
using flowgram?"
There is not a 100% definite answer, but some guidelines
are presented.
In the area of design description techniques there
exists two categories. One is data flow oriented and
the other is functional oriented.
HIPO is data flow oriented and flowgram is functional
oriented.
Which method to use depends on:
1) Whether it is preliminary design or in detailed
design.
2) What type of application that is designed.
If we take a look on the CAMPS applications we have
two extremes, one which is functional oriented (CSF,
TMP) and another which is data flow oriented (LOG,
STP, SAR).
A functional oriented application shall only use HIPO
at the higher levels of design description and flowgrams
at all levels below.
A data flow oriented application shall use HIPO to
a lower level of design than the functional oriented
application and only flowgrams at the lowest levels.
In other words you shall "gear" your design description
method towards the design problem you are trying to
describe.
4.1.4 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲1̲.̲4̲:̲
C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
This section shall contain a detailed description of
data common to subpackages within the package.
4.1.5 D̲D̲S̲ ̲S̲E̲C̲T̲I̲O̲N̲ ̲4̲.̲1̲.̲5̲:̲
C̲o̲m̲m̲o̲n̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲
This section shall contain a description of a̲l̲l̲ procedures
common to subpackages within the package. Each procedure
gets its own section 4.1.5.X. The common procedures
shall be documented as described in the following.
Where common package procedures within the later DDS
design sections are used a reference shall be made
to section 4.1.5.X.
Section 4.1.5.X shall contain the following elements
- 4.1.5.X.1: Functional Specification
- 4.1.5.X.2: Interface Definition
- 4.1.5.X.3: Data Description
- 4.1.5.X.4: Procedure Design
The functional specification shall be a 5-15 lines
of narrative description.
The interface definition shall be defined as for modules
in section 4.2.X.4.2 (i.e. call definition for flowgram
and SWELL and register conventions).
Data descriptions are only required if the common procedure
operate on data structures external to itself
Procedure design (flowgram) is only required when procedures
are greater than 20-30 SWELL statements and/or the
procedure control logic is complex.
4.1.6 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲1̲.̲6̲:̲
G̲l̲o̲b̲a̲l̲ ̲D̲a̲t̲a̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
This should refer to data shared with other packages
which are defined in CPS/DBD/001.
4.1.7 D̲D̲S̲ ̲S̲E̲C̲T̲I̲O̲N̲ ̲4̲.̲1̲.̲7̲:̲
I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
The section shall identify external interfaces as well
as software package to package interfaces (excl. DAMOS
IOC, CSF, and SFM). The minimum documentation is a
reference to the appropriate ICDs.
Sub-package interfaces shall furthermore be identified
but not specified in details, as this shall take place
in section 4.2.X.7.
G̲e̲n̲e̲r̲a̲l̲ ̲C̲o̲m̲m̲e̲n̲t̲s̲ ̲t̲o̲ ̲4̲.̲1̲.̲4̲,̲ ̲4̲.̲1̲.̲6̲ ̲a̲n̲d̲ ̲4̲.̲1̲.̲7̲
In order to obtain a selfcontained and readable document
it may be necessary to include detailed information
in section 4.1.4 - 4.1.7. It shall, however, be emphasized
that the master source for definition of data and package
interfaces are the CAMPS data base design document
and the CAMPS software interface control document (CPS/DBD/001
and CPS/ICD/009)4.2.1
D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲x̲:̲
S̲u̲b̲-̲p̲a̲c̲k̲a̲g̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
This section shall expand the subpackage design, described
in section 4.1, to a level where all modules (less
than 250 source statements) and procedures common to
the subpackage are specified.
4.2.1.1 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲1̲:̲
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Section 4.2.X.1 describes w̲h̲i̲c̲h̲ functions are performed
whereas 4.2.X.4 describes h̲o̲w̲ the functions are performed.
This section shall contain a functional break-down
to such a level that all SW modules and procedures
common to the subpackage can be identified taking all
functional areas defined in DDS section 2.2 and 4.1.1
into account. It is important to include errorprocessing,
initialization etc. in this section.
4.2.1.2 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲2̲:̲
S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
This section shall contain a static description (hierarchical
presentation) which identifies all software subpackage
components (modules and common procedures) to be implemented
(Refer 4.1.2).
Section 4.2.X.2 presents a static description of the
software, while section 4.2.X.3 presents a dynamic
description.
4.2.1.3 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲3̲:̲
D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲
Data flow and control logic related to transactions
within a subpackage (interaction between modules) shall
be described in this section.
Detailed description of module shall not be contained
in this section but included in section 4.2.X.4.Y.5.
References to the module descriptions in section 4.2.X.4.Y
shall, however, be included whenever modules are mentioned
in the design description in section 4.2.X.3.
For design description methods please refer to section
4.1.3.
4.2.1.4 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲4̲:̲
M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This section shall contain a specification of modules.
Each module gets it own section 4.2.X.4.Y, which is
further described in the following.
A short module definition is presented below.
1) A software module s̲h̲a̲l̲l̲ be less than 250 SWELL
source statements.
2) Shared or common procedures shall not be defined
as modules. They shall be described in section
4.1.5 or 4.2.X.6 where common procedures are described.
Software modules can contain (use) common procedures.
3) Software modules can exist at all levels in the
software hierarchy.
4) A software module can include more than one procedure.
This shall be transparent to the user of the module.
All users of a multiple procedure module shall
only interface to one procedure, (i.e. the mainprocedure,
root software components).
5) Software modules shall provide the same services
to all users of the module. Input parameters and
their ranges are the o̲n̲l̲y̲ ̲b̲a̲s̲i̲s̲ for module processing.
Who is calling a module or from where a module
is called s̲h̲a̲l̲l̲ ̲n̲o̲t̲ affect the processing of the
module.
4.2.1.4.1 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲4̲.̲Y̲:̲
M̲o̲d̲u̲l̲e̲ ̲Y̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This section (4.2.X.4.Y.1 - 4.2.4.Y.5) contains the
following elements:
- a functional specification
- a module interface def.
- a module component description
- a data description
- a module design description (flowgram)
Examples of module documentation are given in Int.Med.No.222.
4.2.1.4.1.1 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲4̲.̲Y̲.̲1̲:
F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This section shall contain a narrative description.
The description shall contain "normal" functions, initialization
and errorprocessing functions.
Section 4.2.X.4.Y.1 describes w̲h̲i̲c̲h̲ functions are performed,
whereas section 4.2.X.4.Y.5 describes h̲o̲w̲ the functions
are performed.
4.2.1.4.1.2 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲4̲.̲Y̲.̲2̲:̲
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̲
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 specification 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̲:̲ ̲ W̲a̲i̲t̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲S̲e̲m̲a̲p̲h̲o̲r̲e̲ (Interface def.)
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
4.2.1.4.1.3 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲4̲.̲Y̲.̲3̲:̲
M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
This section shall contain an identification of all
software components (procedures) and a 5 - 10 lines
of functional description of each.
4.2.1.4.1.4 D̲D̲S̲ ̲S̲E̲C̲T̲I̲O̲N̲ ̲4.2.X.4.Y.4:
D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
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 subparagraph.
Variables shall be defined as described in INT.MED.
No. 222 B3.
4.2.1.4.1.5 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲4̲.̲Y̲.̲5̲:̲
M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
This section contains a design description of the modules.
Modules design shall be documented using flowgrams.
The flowgrams shall reflect a̲l̲l̲ system calls, and a̲l̲l̲
module and common procedure calls.
The detailed design s̲h̲a̲l̲l̲ ̲n̲o̲t̲ contain CR80 register
manipulation.
In addition to the flowgrams a narrative design description
shall be contained in this section to make the design
more readable and understandable.
4.2.1.5 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲5̲:̲
C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
This section defines in detail all data common to modules
within the subpackage.
4.2.1.6 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲6̲:̲
C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
This section shall contain a description of a̲l̲l̲ procedures
common to the subpackage.
Each procedure gets its own section 4.2.X.6.Y. The
documentation requirements for common subpackage procedures
are the same as described in DDS section 4.1.5 (common
package)
4.2.1.7 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲2̲.̲X̲.̲7̲:̲
S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
This section shall specify subpackage interfaces between
subpackages within the package. Package interfaces
or external interfaces shall be defined in the appropriate
ICDs and/or in section 4.1.7.
4.3 D̲D̲S̲ ̲S̲e̲c̲t̲i̲o̲n̲ ̲4̲.̲3̲
M̲e̲m̲o̲r̲y̲ ̲L̲a̲y̲o̲u̲t̲
This section shall contain a memory layout of data
and code areas.
