|
DataMuseum.dkPresents historical artifacts from the history of: Rational R1000/400 Tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about Rational R1000/400 Tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: S T
Length: 111878 (0x1b506)
Types: TextFile
Names: »SP1TEST_SRC«
└─⟦180fe333a⟧ Bits:30000405 8mm tape, Rational 1000, SW CATALOG, 10_20_0
└─⟦180fe333a⟧ Bits:30000537 8mm tape, Rational 1000, SW Catalog 10_20_0
└─⟦5cb1d1d7f⟧ »DATA«
└─⟦3b1ee7bd8⟧
└─⟦this⟧
::::::::::
speller_tst.dis
::::::::::
TESTONE.DCT
TESTTWO.DCT
TESTTHREE.DCT
USERON.DCT
USERTW.DCT
TESTFILEONE.TXT
TESTFILETWO.TXT
TEST1.TXT
TEST3.TXT
TEST4.TXT
--USER4:[REA.NOSC]TEST.MEM
speltest.doc
--
-- The following outlines the output from the test matrix.
--
TEST1_1.DCT
TEST1_2.DCT
TEST2_1.DCT
--TESTS 2_2 THRU 2_5 (No output other than interactive)
TEST2_6.DCT
TEST2_7.DCT
TEST2_8.DCT
TEST2_9.DCT
TEST2_10.DCT
TEST3_1.DCT
TEST4_1.DCT
TEST4_2.DCT
TEST4_3.DCT
TEST4_4.DCT
TEST4_5.DCT
TEST4_6.DCT
TEST4_7.DCT
TEST4_8.DCT
TEST4_9.DCT
TEST4_10.DCT
TEST4_11.DCT
TEST4_12.DCT
TEST4_13.DCT
TEST5_1.DCT
TEST5_2.DCT
TEST5_3.DCT
--TEST6 Interactive
--TEST7 Interactive
--TEST8 Interactive
--TEST9 Interactive
--TEST10 Interactive
--TEST11 Interactive
TEST12_1.TXT
TEST13_1.TXT
TEST14_1.DCT
TEST14_2.DCT
TEST15_1.DCT
TEST15_2.DCT
TEST15_3.DCT
TEST16_1.DCT
TEST17_1.DCT
TEST17_2.DCT
TEST18_1.DCT
TEST18_2.DCT
TEST18_3.DCT
TEST19_1.DCT
TEST20_1.DCT
TEST20_2.DCT
TEST21_1.DCT
--
--Tests labeled as interactive must be verified by the output to the
--terminal. No output test files have been included for these tests.
--
--BATCH TESTS
--
--For the most part these tests are the same as their interactive
--counterparts. There may be some slight differences in the output
--caused by a different input dictionary being used.
--
TESTB1_1.DCT
--TEST 1_2 NOT APPLICABLE
--TEST SERIES 2 NOT APPLICABLE
TESTB3_1.DCT
TESTB3_2.DCT
TESTB4_1.DCT
TESTB4_2.DCT
TESTB4_3.DCT
TESTB4_4.DCT
TESTB4_5.DCT
TESTB4_6.DCT
TESTB4_7.DCT
TESTB4_8.DCT
TESTB4_9.DCT
TESTB4_10.DCT
TESTB4_11.DCT
TESTB4_12.DCT
TESTB4_13.DCT
TESTB5_1.DCT
TESTB5_2.DCT
TESTB5_3.DCT
--TEST 6 INTERACTIVE
--TEST 7 INTERACTIVE
--TEST 8 INTERACTIVE
--TEST 9 INTERACTIVE
--TEST 10 INTERACTIVE
--TEST 11 INTERACTIVE
--TEST 12 INTERACTIVE
--TEST 13 INTERACTIVE
TESTB14_1.DCT
TESTB14_2.DCT
TESTB15_1.DCT
TESTB15_2.DCT
TESTB15_3.DCT
TESTB16_1.DCT
TESTB17_1.DCT
TESTB17_2.DCT
TESTB18_1.DCT
TESTB18_2.DCT
TESTB18_3.DCT
TESTB19_1.DCT
--TEST 20 NOT APPLICABLE
TESTB21_1.DCT
::::::::::
TESTONE.DCT
::::::::::
Whether
introduce
type
for
arrays
OMORROW
very
on
abstract
each
If
are
of
array
complete
its
right
we
use
::::::::::
TESTTWO.DCT
::::::::::
name
particular
depends
WORK
much
abstract
situation
we
thinking
::::::::::
TESTTHREE.DCT
::::::::::
This
will
be
third
dictionary
::::::::::
USERON.DCT
::::::::::
this
maybe
job
listing
wordspell
end
ask
why
would
upyors
nome
nots
knots
name
nepo
nape
nate
nats
nazs
nabs
nass
noss
noes
::::::::::
USERTW.DCT
::::::::::
second
dictionarylist
mostanythinggoes
PHILLIP
Phillipe
telephone
telegraph
telegraphy
telephoney
DAY
coaxial
serial
ribbon
parallel
misspelled
lexicon
graphically
sketch
drafting
longing
logging
afterwards
maybeso
::::::::::
TESTFILEONE.TXT
::::::::::
Whether we introduce name particular type for arrays very on depends much
abstract each If are of array situation thinking array complete its use.
This will be a third dictionary.
::::::::::
TESTFILETWO.TXT
::::::::::
Whether we introduce name particular type for arrays very on depends much
abstract each If are of array situation thinking array complete its use.
This will be a third dictionary.
DCS Ada and other acronyms added to the file AFW NSA
::::::::::
TEST1.TXT
::::::::::
Whether we introduce a type name for a particular arrays depends very much
on the abstract view of each situation. If we are thinking of the array
as a complete object in its own rigt then we should use a type name. If on
the other hand we are thinking of the array as merely an indexable conglomer
This line is for DCS, ACSL ATB and other Ada words.
ate not related as a whole to other arrays then it should probably be of an
anonymous type.
Arays lik OMORROW n WORK_DAY f te las setion re ood exmples
of arrays which are of the anonymous rigt category. To be forced to introduct
a tpe ame fr sch arays woud intoduce unecessary clter nd a possbly
false sense of abstraction.
On the other hand if we are manipulating lots of arrays of reals of length
6 hen thre is a comon unerlying abstrac tye ad so it shold be naed.
The model for array types intorduced so far is still not satis
factory. It does not allow us to represent an abstract view that embraces th
ommonality between arrays which has
have different bounds but are otherwise of the same type. In particular
it would not allow the writing of subprograms rigt which could take an array
of arbitrary bounds as an actual parameter. This is generally recognised
as a major difficulty with Pascal. So the concept of an unconstrained array typ
e
is introduced in which the constraints for the indexes are not given. Consider
::::::::::
TEST3.TXT
::::::::::
An important point to notice is that an array type or subtype must give all
the bounds or none at all. It would be perfectly legal to introduct an
alternative name for matrix by creating it with no bounds. We could not have
a type or subtype that just gave the bounds for one dimension but not the
other.
::::::::::
TEST4.TXT
::::::::::
An impoetant point to notce is that an array type or suctype must give all
the boonds or none at all. It would be perfectly legal to introduct an
elternative name for matrix by creating it with no bounfs. We could not have
a type or subtype that just gave the boueds for one diminsion but not the
other.
::::::::::
speltest.doc
::::::::::
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
Program Design
Specification for an
Interactive
Spelling Corrector
in Ada
Prepared for: |||||||||||||||||||||||||
|||||||||||||||||||||||||
Advanced Computer Systems Lab |||||||| |||| ||||||||
Texas Instruments |||||||| ||| ||||||||
|||||||| | || ||||||||
|||||||| || | ||||||||
|||||||| |||| ||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||| ||||||||
|||||||| ||||| ||||||||
|||||||| ||||| ||||||||
|||||||| ||||| ||||||||
|||||||| ||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||| ||||||||
|||||||| |||||||||||||||
|||||||| ||||||||
||||||||||||||| ||||||||
|||||||| ||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
Equipment Group - ACSL |||||||| ||||||||
P.O. Box 801, M.S. 8007 |||||||| |||||||||||||||
McKinney, Texas 75069 |||||||| |||||||||||||||
14 March 1985 |||||||| |||||||||||||||
|||||||| ||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
TEXAS INSTRUMENTS
INCORPORATED
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
|||||||||||||||||||||||||
\f
CHAPTER 1
INTRODUCTION
1.1 PURPOSE
This Computer Program Test Procedures document describes the
acceptance test procedures for the Ada Spelling Corrector computer
program. This research and development is being done for the
Naval Ocean Systems Center (NOSC) under contract N66001-84-R0030.
Within this document, the Ada Spelling Corrector is referred to as
the Spelling Corrector.
This acceptance test procedures document has been prepared in
accordance with the Navy Data Item Description for a Computer
Program Test Procedures document [NAV78].
1.2 SCOPE
This document describes the procedures for testing the
Spelling Corrector after it is developed. The test procedures
defined in this document will show compliance with the
requirements of the Proposal to Design and Implement a Spelling
Corrector in Ada [TI84].
1.3 SUMMARY
The objective of this document is to explain the test
procedures that are necessary for acceptance testing of the
Spelling Corrector. Acceptance testing will demonstrate that the
requirements of the Proposal to Design and Implement a Spelling
Corrector in Ada [TI84] have been satisfied. A list of the
requirements that must be verified is provided in the Requirements
Cross Reference Matrix in Appendix B.
\f
CHAPTER 2
APPLICABLE DOCUMENTS
[BEI84] Beizer, Boris, Software System Testing and Quality
Assurance, Van Nostrand Reinhold Co., New York, 1984.
[BRU82] Bruce, Phillip and Sam M. Pederson, The Software
Development Project, John Wiley and Sons, Inc., New
York, 1982.
[EVA84] Evans, Michael W., Productive Software Test Management,
John Wiley and Sons, Inc., New York, 1984.
[MYE79] Myers, Glenford J., The Art of Software Testing, John
Wiley and Sons, Inc., New York, 1979.
[NAV78] Navy, "Data Item Description, Computer Program Test
Procedures", Navy DI-T2144, 29 November 1978.
[TI84 ] Texas Instruments, "Proposal to Design and Implement an
Ada Style Standards Checking Tool," Lewisville, Tx,
January 1984.
\f
CHAPTER 3
TESTING REQUIREMENTS
3.1 GENERAL
Acceptance testing of the Spelling Corrector must verify the
requirements in the proposal [TI84] for the Spelling Corrector. A
summary of the requirements from the proposal document is provided
in Appendix B in the Requirements Cross Reference Matrix.
Verifying that the requirements have been satisfied is a process
involving three main steps. A description of each step is given
below.
1. Develop Test Specifications - The first step is to develop
test specifications based on the requirements. The test
specifications outline the testing criteria that is necessary
to show that the Spelling Corrector satisfies its original
objectives. Appendix A contains the test specifications for
the Spelling Corrector.
2. Create Test Data - The second step is to create test data to
satisfy the test specifications. The test data is a library
of Ada source programs, user and system dictionaries, and
input files used to implement the testing criteria in the test
specifications. The Ada source programs, user and system
dictionaries, and input files are used as input to the
Spelling Corrector. There are various expected output files
generated by the Spelling Corrector, depending on the options
used to run it and the mode (batch or interactive) in which it
is being run. The output may be a new dictionary, the input
file with any number of words marked as possible spelling
errors, a simple list of the words from the input file which
might be misspelled, the listing of a dictionary which was
already in existence at the start of the program's run, or a
set of user prompts.
3. Analyze Results - The third step is to conduct testing and
analyze the results. The Spelling Corrector is executed with
the test data, input files, and dictionaries that were created
in step 2. The results are analyzed and the appropriate
matrices are updated.
TESTING REQUIREMENTS Page 3-2
Some of the ideas from Myers [MYE79] were used to facilitate
the development of the test specifications. Specifically, the
facility test category defined by Myers was used to help define
the test specifications. Myers' definition for facility testing
is provided below.
Facility Facility testing is the determination of whether each
facility or function is actually implemented. The
procedure is to scan the requirements sentence by
sentence and when the sentence specifies a "what"
(e.g., "syntax should be consistent ...", "user should
be able to specify a range of locations ..."),
determine if the program satisfies the "what".
3.2 SPELLING CORRECTOR ACCEPTANCE/PREOPERATING PROCEDURES
The following paragraphs explain the necessary preparations
and procedures for acceptance testing of the Spelling Corrector.
3.3 EQUIPMENT PREPARATION
In order to complete acceptance testing, the Spelling
Corrector must be available on a Data General MV 10,000 running
under AOS/VS.
3.4 DIGITAL PROCESSOR PREPARATION
In order to complete acceptance testing, the ROLM/Data
General Ada Development Environment (ADE) must be available.
3.5 TESTING PROCEDURE
The procedure for acceptance testing is to fulfill all the
test specifications in Appendix A. This can be accomplished by
completing the second and third steps from Section 3.1.
As noted in step 2, input files for the Spelling Corrector
(Ada source programs, system and user dictionaries, and input
files) must be created to satisfy all of the test specifications
in Appendix A. In addition, the expected output files for the
Spelling Corrector (new dictionaries, word lists, altered input
files, etc.) must be created based on the input files. Then, when
the Spelling Corrector tool is ready to undergo acceptance
testing, step 3 is started. Thus, the input files and
dictionaries are executed with the tool. The output files that
are generated are compared with the expected output files, which
have already been established as correct. The file names for the
test data library and the corresponding test specifications that
are satisfied need to be documented in the Test Data Matrix in
Appendix C. Finally, the results of testing are analyzed and the
Test Specification Matrix in Appendix B is updated.
TESTING REQUIREMENTS Page 3-3
NOTE
One Ada source program and corresponding Style
Parameter file may be used to satisfy a number of
test specifications in Appendix A. In other
words, it is not necessary to create a separate
set of input files for each test specification in
Appendix A.
\f
CHAPTER 4
TEST MANAGEMENT
The Spelling Corrector development team is responsible for
management of the testing described in this document. The
Spelling Corrector development team responsibilities are to:
o create test data according to the test specifications in
Appendix A, and record the test data information in the Test
Data Matrix in Appendix B,
o conduct the test procedures described in the Testing
Requirements section,
o maintain the Test Specifications Matrix in Appendix B, and
o write an internal test report.
\f
CHAPTER 5
PERSONNEL REQUIREMENTS
The software development team for the Spelling Corrector is
the only personnel required to complete the acceptance testing
described in this document.
\f
CHAPTER 6
HARDWARE REQUIREMENTS
The acceptance testing described in this document shall be
conducted on a Data General MV 10,000 running under AOS/VS.
\f
CHAPTER 7
SOFTWARE REQUIREMENTS
The acceptance testing described in this document requires
the ROLM/Data General Ada Development Environment (ADE).
\f
CHAPTER 8
TESTING SCHEDULE
The acceptance testing described in this document will take
1-2 weeks to complete, at most.
\f
CHAPTER 9
QUALITY ASSURANCE
ACSL personnel will be responsible for the following Quality
Assurance and Configuration Management tasks:
o verifying that the test data satisfies the test
specifications,
o verifying that the documentation of each test is complete, and
o maintaining configuration control of all software undergoing
test.
\f
APPENDIX A
TEST SPECIFICATIONS
This appendix contains the test specifications for the
Spelling Corrector. Each test specification includes a list of
the requirements that are satsified, a description of the test,
assumptions for the test, and a test synopsis. The test synopsis
describes the input and expected results for the test. The test
categories that are used for each test specification are also
provided in the synopsis. A description of the various test
categories is provided in the Testing Requirements section.
A.1 TEST SERIES 1
A.1.1 Requirements Met By Test
1. The user will be able to enable an auxiliary dictionary
search. (BOTH)
Proposal Section: 2.3.1
A.1.2 Description Of Test
Basically, this test checks for the capability to use a
certain type of file for a given purpose. Words from several
dictionaries should appear in the file being checked, because
using words from only the auxiliary dictionary being used for this
test would not guarentee that that particular auxiliary dictionary
is enabled. See Requirement Number 16, which requires that if no
dictionary is enabled, then all words in the input file will be
marked as possible errors.
A.1.3 Assumptions
The MASTER and ACRONYM dictionaries are disabled.
A.1.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
TEST SPECIFICATIONS Page A-2
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 With auxiliary Only words not in Facility
dictionary disabled, auxiliary
give the order to dictionary should
enable it; search an be marked as mis-
input file with mis- spelled
spelled words from
that auxiliary
dictionary and other
dictionaries
2 With auxiliary Same as above, Facility
dictionary search no error message
enabled, give the should result from
command to enable it; enabling a
perform the same dictionary which is
search as in Part 1 already enabled
TEST SPECIFICATIONS Page A-3
A.2 TEST SERIES 2
A.2.1 Requirements Met By Test
2. The program will be able to merge two or more user-specified
dictionaries, provided that those dictionaries exist before the
attempted merge operation. See also Requirement 20, which
is related. (INTERACTIVE)
Proposal Section: 2.3.1
A.2.2 Description Of Test
This series of tests consists of supplying the program with
the types of dictionaries indicated under the INPUT DATA column,
below, giving the command to merge them, and checking for the
results described in EXPECTED OUTPUT, also below. A "valid"
dictionary is one which exists at the time that the command is
given; likewise, an "invalid" dictionary is one which does not
exist at the time that the command is given.
A.2.3 Assumptions
A.2.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Two valid dictionaries Dictionaries Facility
should be merged,
and no error
messages should
result
2 One valid and Merger should not Facility
one invalid be attempted, and
dictionary, an error message
in that order should be given
for the invalid
dictionary name
3 One invalid and Same result as Facility
one valid Test # 2, just
dictionary, above
in that order
TEST SPECIFICATIONS Page A-4
4 One invalid Merger should not Facility
dictionary or one be attempted, and
valid dictionary error messages
should be given
for insufficient
number of
arguments and/or
invalid dictionary
name
5 No arguments at all Merger should not Facility
be attempted
6 Three dictionaries, Merger should be Facility
two valid and one done on the two
invalid, in that order valid dictionaries,
and an error
message should be
output for the
invalid
dictionary
7 Three dictionaries, Same as # 6, Facility
one valid, one above
invalid, and one
valid, in that
order
8 Three dictionaries, Same as # 6, Facility
one invalid, two above
valid, in that
order
9 Three or more valid Merger should be done Facility
dictionaries. on all three diction-
aries.
10 Two valid dictionaries One valid dictionary Facility
defined as the union
of the two input dic-
tionaries.
TEST SPECIFICATIONS Page A-5
A.3 TEST SERIES 3
A.3.1 Requirements Met By Test
3. The program will be able to list the contents of a user-specified
dictionary, provided that that dictionary exists when the program
is given the command to perform that listing. (BOTH)
Proposal Section: 2.3.1
A.3.2 Description Of Test
This test consists of giving the LIST DICTIONARY command,
with the data as shown in the INPUT DATA section, below. A
"valid" dictionary is one which exists at the time that the
command is given; likewise, an "invalid" dictionary is one which
does not exist at the time that the command is given.
A.3.3 Assumptions
A.3.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 A valid dictionary The dictionary's Facility
contents should be
listed
2 An invalid dictionary No listing should Facility
be attempted, and
an error message
should be given
for an invalid
argument
TEST SPECIFICATIONS Page A-6
A.4 TEST SERIES 4
A.4.1 Requirements Met By Test
4. The program will be able to search either the MASTER and ACRONYM
dictionaries, both dictionaries, or neither dictionary. (BOTH)
Proposal Section: 2.3.1
A.4.2 Description Of Test
This testing series involves commanding the search of various
combinations of enabled dictionaries, as specified in the INPUT
DATA section below. The input file should contain some words from
both the MASTER and ACRONYM dictionaries, as well as some words
that are not in those dictionaries.
A.4.3 Assumptions
A.4.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Enable search on Only words from Facility
MASTER and ACRONYM, the MASTER
then command dictionary should
disablement of MASTER be flagged, and there
and perform search should be no
undesirable side
effects
2 Enable MASTER and Only words from Facility
ACRONYM, then disable the ACRONYM
ACRONYM and perform dictionary
search should be flagged,
and there should be
no undesirable side
effects
3 Enable search on All words should be Facility
MASTER and ACRONYM, flagged, since no
then disable both dictionary was enabled,
and perform search and there should be no
undesirable side
effects
4 Disable MASTER and Same as above, plus no Facility
ACRONYM dictionary undesirable side
searches, then command effects arising from
TEST SPECIFICATIONS Page A-7
disablement of MASTER the redundant command
dictionary and perform
search
5 Disable MASTER and Same as # 4, above Facility
ACRONYM dictionary
searches, then command
disablement of ACRONYM
dictionary and perform
search
6 Disable MASTER and Same as # 4, above Facility
ACRONYM dictionary
searches, then command
disablement of ACRONYM
and MASTER dictionaries
and perform search
7 Enable MASTER search, Same as # 3, above Facility
then command
disablement of MASTER
search
8 Enable MASTER search, Only words not from the Facility
then command MASTER dictionary
disablement of ACRONYM should be flagged, and
search and perform there should be no
search undesirable side
effects
9 Enable MASTER search, All words should be Facility
then disable ACRONYM flagged, and there
and MASTER searches should be no
and perform search undesirable side
effects
10 Enable ACRONYM search, Only ACRONYM words Facility
attempt MASTER should not be flagged
disablement, and
perform search
11 Enable ACRONYM search, All words should be Facility
disable ACRONYM flagged
search, perform search
12 Enable ACRONYM search, All words should be Facility
disable ACRONYM and flagged
MASTER searches,
perform search
13 Enable MASTER and Words from the MASTER Facility
ACRONYM searches, and ACRONYM
perform search dictionaries should not
be flagged
TEST SPECIFICATIONS Page A-8
A.5 TEST SERIES 5
A.5.1 Requirements Met By Test
5. The program will check the words in the specifed input file
against all of the enabled dictionaries in the order: MASTER
dictionary first, then ACRONYM dictionary, then user
dictionaries. (BOTH)
Proposal Section: 2.3.2
A.5.2 Description Of Test
Three runs of the test text will be needed. Each run will be
performed with various combinations of the dictionaries enabled.
An input file with misspelled words will be needed. The
misspelled words will have to be unique to each of the three
dictionaries, i.e., the correct spelling for each misspelled word
should be found in only one of the test dictionaries.
A.5.3 Assumptions
A.5.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 File of misspelled List of misspelled Facility
words described in words not contained in
Description of Test the MASTER dictionary
2 File of misspelled List of misspelled Facility
words as in # 1, words not contained in
above. the MASTER or ACRONYM
dictionaries
3 File of misspelled List of misspelled Facility
words as in # 1 & 2, words not contained in
all three dictionaries
TEST SPECIFICATIONS Page A-9
A.6 TEST SERIES 6
A.6.1 Requirements Met By Test
6. The program will indicate each word suspected of being misspelled
by displaying the line in which that word occurs, with a pointer
to that word. In addition, the program will prompt the user for
further actions. (INTERACTIVE)
Proposal Section: 2.3.2
A.6.2 Description Of Test
The test file should contain several lines on which
misspellings occur. There should be at least three lines with all
words misspelled, one line with the first word being the only
misspelling on the entire line, one line with the last word being
the only misspelling on the entire line, and two lines where a
word which is not normally hyphenated if it is on only one line is
split between two lines.
A.6.3 Assumptions
A.6.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Test input file as All words which are Facility
described in misspelled should be
Description of Test marked, including the
section above. word split between two
lines. Also, each
time a line with a
misspelled word is
displayed, the prompt
for further action
should also be
displayed. See also
Requirement # 7, below
TEST SPECIFICATIONS Page A-10
A.7 TEST SERIES 7
A.7.1 Requirements Met By Test
7. The program will offer the user three options accompanying the
prompt for the further actions, and those options will be:
1. The user may request a list of possible correct
spellings for the word suspected of being misspelled.
2. The user may leave the word unchanged.
3. The user may enter the correct spelling for the word
suspected of being misspelled.
(INTERACTIVE)
Proposal Section 2.3.2
A.7.2 Description Of Test
This requirement is basically an extension of the previous
requirement, and no separate testing runs are needed. Only the
additional checking described in the Test Synopsis section below
should be required. Note that this particular requirement
specifies only that the options described will be displayed, not
necessarily that they will work. The proper functioning of the
three options is covered by the requirements immediately following
this one.
A.7.3 Assumptions
A.7.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Same as for An indication of the Facility
Requirement Number 6 offering of the three
options specified in
the requirement
TEST SPECIFICATIONS Page A-11
A.8 TEST SERIES 8
A.8.1 Requirements Met By Test
8. When the user requests a list of possible correct spellings, as
described in option # 1 of Requirement # 7 above, the program
will perform an incremental search of all enabled dictionaries.
(INTERACTIVE)
Proposal Section 2.3.2
A.8.2 Description Of Test
Run the program with various combinations of enablement and
disablement of the system and two made-up private dictionaries.
The input file should have words which do not appear in any of the
dictionaries involved in the test series, as well as words which
do appear in those dictionaries.
A.8.3 Assumptions
A.8.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Enable MASTER only and Only the words from Facility
run the MASTER dictionary
should be listed
2 Enable ACRONYM only Only the words from Facility
and run the ACRONYM dictionary
should be listed
3 Enable MASTER and Only the words from Facility
ACRONYM and run the MASTER and ACRONYM
dictionaries should
be listed
4 Enable MASTER, Only the words from Facility
ACRONYM, a private the MASTER, ACRONYM,
dictionary, and run and enabled private
dictionary should be
listed
5 Enable all Only the words from Facility
dictionaries and run the MASTER, ACRONYM,
and enabled private
dictionaries should
be listed
TEST SPECIFICATIONS Page A-12
6 Enable MASTER and one Only the words from Facility
private dictionary and the MASTER and enabled
run private dictionaries
should be listed
7 Enable MASTER and both Only the words from Facility
private dictionaries the MASTER and enabled
and run private dictionaries
should be listed
8 Enable ACRONYM and one Only the words from Facility
private dictionary and the ACRONYM and
run enabled private
dictionaries should
be listed
9 Enable ACRONYM and Only the words from Facility
both private the ACRONYM and
dictionaries and run enabled private
dictionaries should
be listed.
TEST SPECIFICATIONS Page A-13
A.9 TEST SERIES 9
A.9.1 Requirements Met By Test
9. When the user requests a list of possible correct spellings
the program will locate all dictionary entries containing
the prefix as an initial substring. (INTERACTIVE)
Proposal Section 2.3.2
A.9.2 Description Of Test
Run the same test series as for Requirement Number 8, but for
this series, provide prefix strings for the misspellings.
A.9.3 Assumptions
A.9.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Enable MASTER only and Only the words from Facility
run the MASTER dictionary
should be listed
2 Enable ACRONYM only Only the words from Facility
and run the ACRONYM dictionary
should be listed
3 Enable MASTER and Only the words from Facility
ACRONYM and run the MASTER and ACRONYM
dictionaries should
be listed
4 Enable MASTER, Only the words from Facility
ACRONYM, a private the MASTER, ACRONYM,
dictionary, and run and enabled private
dictionary should be
listed
5 Enable all Only the words from Facility
dictionaries and run the MASTER, ACRONYM,
and enabled private
dictionaries should
be listed
6 Enable MASTER and one Only the words from Facility
private dictionary and the MASTER and enabled
run private dictionaries
TEST SPECIFICATIONS Page A-14
should be listed
7 Enable MASTER and both Only the words from Facility
private dictionaries the MASTER and enabled
and run private dictionaries
should be listed
8 Enable ACRONYM and one Only the words from Facility
private dictionary and the ACRONYM and
run enabled private
dictionaries should
be listed
9 Enable ACRONYM and Only the words from Facility
both private the ACRONYM and
dictionaries and run enabled private
dictionaries should
be listed.
TEST SPECIFICATIONS Page A-15
A.10 TEST SERIES 10
A.10.1 Requirements Met By Test
10. When the requested search of the dictionaries (see Specification
9) is completed, the program will display an alphabetized,
sequentiallly-numbered list of all discovered possible correct
spellings. (INTERACTIVE)
Proposal Section 2.3.2
A.10.2 Description Of Test
This test is, in effect a continuation of the testing for
Requirement Number 9, immediately preceding. Merely inspect the
output lists to ascertain that they are alphabetized and
sequentially numbered. This testing is "Facility" testing.
A.10.3 Assumptions
A.10.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
See the Test Synopsis for Requirement Number 9, inspecting the output
list for alphabetic order and sequential numbering
TEST SPECIFICATIONS Page A-16
A.11 TEST SERIES 11
A.11.1 Requirements Met By Test
11. When the requested search of the dictionaries is completed, in
addition to displaying the list specified immediately above,
the program will allow the user to choose one of the following
options:
1. The user may select one of the alternatives from the
displayed list
2. Directly enter the correct spelling of the word.
3. The user may leave the word unchanged and continue.
(INTERACTIVE)
Proposal Section 2.3.2
A.11.2 Description Of Test
This test is, in effect a continuation of the testing for
Requirement Numbers 9 and 10, immediately preceding. Merely
inspect the screen after the completion of each search to make
certain that the three options specified are offered. This
testing is "Facility" testing. Note that this particular
requirement specifies only that the options described will be
displayed, not necessarily that they will work. The proper
functioning of the three options is covered by the requirements
immediately following this one.
A.11.3 Assumptions
A.11.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
See the Test Synopsis for Requirement Number 9, inspecting the screen
for a display of the three options
TEST SPECIFICATIONS Page A-17
A.12 TEST SERIES 12
A.12.1 Requirements Met By Test
12. If the user chooses to leave the word suspected of being
misspelled unchanged, as in option # 3 of Requirement 11,
the program will not change the current spelling of the word
under consideration. (INTERACTIVE)
Proposal Section 2.3.2
A.12.2 Description Of Test
This test series will require two identical files, one an
input file and the other a comparison file. The input file is the
one which should be run, and the comparison file is used to detect
any changes which might have occurred in the input file. These
files should have the same misspelled word as the first and last
word on the first line of the file, the first and last word on a
line somewhere in the middle of the file, and the first and last
word on the last line of the file. When the option to change each
misspelling is offered, the tester should indicate that the word
should be left unchanged. There should be no change in the input
file after that choice. A comparison utility, such as the UNIX
operating system's "diff" would expedite this testing, by
comparing the input file after each choice with the comparison
file.
A.12.3 Assumptions
A.12.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 An input file, as No change in the input Facility
described in the file should occur
Description of Test
section. The program
should be run on that
entire file, and the
no-change option
selected for each
misspelling
TEST SPECIFICATIONS Page A-18
A.13 TEST SERIES 13
A.13.1 Requirements Met By Test
13. If the user chooses to change the spelling of the word suspected
of being misspelled, as in option # 1 or option # 2 of
Requirement 11, each occurrence of the same suspected misspelling
will be changed to the choice made by the user. (INTERACTIVE)
Proposal Section 2.3.2
A.13.2 Description Of Test
The program should be run on a file with the same word
misspelled several different ways, e.g., "diferent", "differant",
"defferent", etc. Each misspelling should occur several times in
the input file, preferably in different positions on a line of
text. The input file should be examined after every change is
made, to insure that only the exact same misspellings as the
misspelling which was displayed are the ones which are changed.
Using the preceding example, if the misspelling being changed is
"diferent", then only the occurrences of "diferent" being examined
and those elsewhere in the file should be changed. The
"differant", "defferent", and other variant misspellings should be
left unchanged.
A.13.3 Assumptions
A.13.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 File as described in Only the exact same Facility
Description of Test misspelling as the
section, above misspelling under
consideration should
be changed. See the
Description of Test
section above for an
example.
TEST SPECIFICATIONS Page A-19
A.14 TEST SERIES 14
A.14.1 Requirements Met By Test
14. If the MASTER and ACRONYM dictionaries are both disabled, only
the user's enabled private dictionaries will be searched.
(BOTH)
Proposal Section 2.3.3.1
A.14.2 Description Of Test
There should be two private dictionaries available. The
input file should contain misspelled words from the MASTER and
ACRONYM dictionaries, as well as from two private dictionaries,
After the program is run, the processed input file should be
examined to see which words are marked as errors.
A.14.3 Assumptions
A.14.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Disable MASTER and Only words from the Facility
ACRONYM dictionaries, enabled private
if they are not dictionaries should not
already disabled. be marked as errors
Enable more than one
private dictionary
and run the program
2 Disable one of the Only words from the Facility
private dictionaries private dictionary
and run the program which is still enabled
should not be marked as
errors
TEST SPECIFICATIONS Page A-20
A.15 TEST SERIES 15
A.15.1 Requirements Met By Test
15. If the MASTER dictionary is disabled and the ACRONYM dictionary
is enabled, the ACRONYM dictionary and any enabled private
dictionaries will be searched. (BOTH)
Proposal Section 2.3.3.2
A.15.2 Description Of Test
The ACRONYM dictionary should be enabled and the MASTER
dictionary disabled. The same file as that used to test
Requirement Number 14 may be used. The processed input file
should be examined to see which words were marked as errors.
A.15.3 Assumptions
A.15.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Make sure that the The marked words Facility
ACRONYM dictionary is should be words not
enabled and the MASTER from the ACRONYM and
dictionary disabled, enabled private
and enable two private dictionaries
dictionaries. Run the
program
2 Disable one of the The marked words Facility
private dictionaries should not be words
and run the program from the ACRONYM
dictionary and
the private
dictionary which is
still enabled
3 Disable the private The marked words Facility
dictionary which is should not be words
still enabled and run from the ACRONYM
dictionary.
TEST SPECIFICATIONS Page A-21
A.16 TEST SERIES 16
A.16.1 Requirements Met By Test
16. If no dictionary is enabled, the program will label all words as
suspected of being misspelled. (BOTH)
Proposal Section 2.3.3.2
A.16.2 Description Of Test
Disable all dictionaries and run the program.
A.16.3 Assumptions
A.16.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Disable all All words should be Facility
dictionaries, both marked as possible
system and private misspellings
and run the program
TEST SPECIFICATIONS Page A-22
A.17 TEST SERIES 17
A.17.1 Requirements Met By Test
17. If the user disables all dictionaries, specifies the output file
option, and runs the program on an error-free file, the program
will produce a file that can be used as a private dictionary.
(BOTH)
Proposal Section 2.3.3.2
A.17.2 Description Of Test
Same basic procedure as Requirement Number 16, immediately
above, with the difference that the output file option is
specified. The object to examine will be a newly-created file
which should subsequently be usable as a private dictionary. The
first input file should contain no misspellings. The second input
file should contain the same words as the first input file, but
the words should be misspelled. This test has two parts, and the
second part depends on the first part. In the first one, the
ability of the program to create a file from the
no-existing-dictionaries-enabled output-file-option-specified
condition is checked. The second part checks to see if the file
thus created is usable as a private dictionary.
A.17.3 Assumptions
A.17.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Ensure that all A new file containing Facility
dictionaries are all of the input
disabled, and run the file's words should
program with the be present after the
"output file" option. program has run
2 Enable the file which The errors in the Facility
resulted from the input file should be
above run as a private flagged
dictionary. Run the
program again with the
input file containing
the errors
TEST SPECIFICATIONS Page A-23
A.18 TEST SERIES 18
A.18.1 Requirements Met By Test
18. If the MASTER dictionary is enabled and the ACRONYM dictionary
is disabled, the MASTER dictionary and any enabled private
dictionaries will be searched. (BOTH)
Proposal Section 2.3.3.3
A.18.2 Description Of Test
Enable the MASTER dictionary and disable the ACRONYM
dictionary. Run with zero, one, and two or more private
dictionaries enabled.
A.18.3 Assumptions
A.18.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Enable the MASTER Only words not Facility
dictionary and disable contained in the
the ACRONYM dictionary MASTER dictionary
and all private should be marked as
dictionaries and run possible misspellings.
2 Enable one of the Only words not from Facility
private dictionaries the MASTER and en-
and run again abled private
dictionaries should be
marked as possible
misspellings
3 Enable another Only words not from Facility
private dictionary the MASTER and en-
and run again abled private
dictionaries should be
marked as possible
misspellings
TEST SPECIFICATIONS Page A-24
A.19 TEST SERIES 19
A.19.1 Requirements Met By Test
19. If the user specifies the LIST DICTIONARY option, the program
will compact the contents of the dictionary given by the user
as the input file and write the result to another file. (BOTH)
Proposal Section 2.3.3.4
A.19.2 Description Of Test
Give the program a user dictionary, a filename to write the
results to, specify the LIST DICTIONARY option, and run the
program.
A.19.3 Assumptions
A.19.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Run the program on a A new file which is Facility
user dictionary, a compacted version of
specifying the list the input file and
dictionary option and with the given output
giving the name of the filename
desired output file
TEST SPECIFICATIONS Page A-25
A.20 TEST SERIES 20
A.20.1 Requirements Met By Test
20. If the user specifies the MERGE DICTIONARY option, the program
will merge the input files together and, thereafter, use the
resultant file as an auxiliary dictionary. (INTERACTIVE)
Proposal Section 2.3.3.5
A.20.2 Description Of Test
Run the program with two user dictionaries, specifying the
"merge dictionary" option, and supplying an output filename for
the program to write to. The output file should be usable as a
private dictionary. The test will necessarily have two parts. In
the first part, the object is to see if the program will merge two
dictionaries, and in the second, to see if the resulting output
file is usable as a user dictionary. The second part of the test
will require an input textfile to be checked, and that file should
contain words from both of the original user dictionaries.
A.20.3 Assumptions
A.20.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Run the program with A file with the Facility
the "merge dictionary" specified output
option on two user filename
dictionaries, and
specify an output
filename
2 Run the program to A list of words from Facility
check the spelling the input file which
on an input textfile might be misspelled
TEST SPECIFICATIONS Page A-26
A.21 TEST SERIES 21
A.21.1 Requirements Met By Test
21. The program will generate an output file containing all of the
words in the input file which are suspected of being misspelled.
(BOTH)
Proposal Section 2.3.3.7
A.21.2 Description Of Test
Run the program on a file containing misspelled words,
instructing it to generate the described list. For this test,
supply a filename for the list to be written to.
A.21.3 Assumptions
A.21.4 Test Synopsis
The following table summarizes the test data, expected
outputs, and test categories addressed by the associated test
data.
INDEX INPUT DATA EXPECTED OUTPUT CATEGORIES
===== ========== =============== ==========
1 Run the program on a A file with the name Facility
file containing supplied by the
misspelled words, tester which contains
and give a filename the misspelled words
for the list which the in the input file
program should create
\f
APPENDIX B
CROSS REFERENCE MATRIX
This appendix contains three cross reference matrices that
show the relationship between the test specifications in Appendix
A, the requirements from the proposal for the Spelling Corrector
[TI84], and the test data files developed to satisfy the test
specifications.
The Test Specifications Matrix lists the test specifications
and shows which requirements are satisified with each test
specification. In addition, the Test Specifications Matrix
contains two columns for check off and comments to fill in as the
test specifications are fulfilled.
The second matrix, the Requirements Cross Reference Matrix,
provides a quick reference of how each requirement is satisfied.
The acceptance requirements are listed along with the test
specifications that satisfy each requirement. In addition, the
specific section from the Proposal to Design and Implement an Ada
Spelling Standards Checking Too [TI84] where the requirement is
described is listed.
The third matrix, the Test Data Matrix, shows the
relationship between the test data and the test specifications in
Appendix A. The file names included in the test data library that
are developed by the Spelling Corrector development team will be
listed along with the test specifications that they satisfy.
CROSS REFERENCE MATRIX Page B-2
B.1 TEST SPECIFICATIONS MATRIX
------------------------------------------------------------------
| TEST SPEC | REQUIREMENTS | CHECK | COMMENTS |
|============|================|=======|==========================|
| A.1 | 1 |3-17-85| Testfileone.txt |
| | | | Testone.dct, Testtwo.dct |
| | | | Testthree.dct |
|------------|----------------|-------|--------------------------|
| A.2 | 2 |3-17-85| Testone.dct, Testtwo.dct |
| | | | Useron.dct, Usertw.dct |
|------------|----------------|-------|--------------------------|
| A.3 | 3 |3-17-85| Testone.dct, Testtwo.dct |
|------------|----------------|-------|--------------------------|
| A.4 | 4 |3-17-85| Testone.dct, Testtwo.dct |
| | | | Testfileone.txt |
| | | | Testfiletwo.txt |
|------------|----------------|-------|--------------------------|
| A.5 | 5 |3-17-85| Testone.dct, Testtwo.dct |
| | | | Testthree.dct |
|------------|----------------|-------|--------------------------|
| A.6 | 6 |3-17-85| Test1.txt |
|------------|----------------|-------|--------------------------|
| A.7 | 7 |3-18-85| Speller_master.dct |
|------------|----------------|-------|--------------------------|
| A.8 | 8 |3-18-85| Test1.txt, Useron.dct |
| | | | Usertw.dct |
| | | | Speller_master.dct |
| | | | Speller_acronym.dct |
| | | | |
|------------|----------------|-------|--------------------------|
| A.9 | 9 |3-18-85| Same as 8 |
|------------|----------------|-------|--------------------------|
| A.10 | 10 |3-18-85| Same as 8 |
|------------|----------------|-------|--------------------------|
| A.11 | 11 |3-18-85| Same as 8 |
|------------|----------------|-------|--------------------------|
| A.12 | 12 |3-18-85| Test1.txt |
| | | | Speller_acronym.dct |
| | | | Speller_master.dct |
|------------|----------------|-------|--------------------------|
| A.13 | 13 |3-18-85| Test1.txt |
|------------|----------------|-------|--------------------------|
| A.14 | 14 |3-18-85| Testone.dct, Testtwo.dct |
| | | | Testthree.dct |
| | | | Speller_master.dct |
| | | | Speller_acronym.dct |
|------------|----------------|-------|--------------------------|
| A.15 | 15 |3-18-85| Same as 14 with |
| | | | Testfiletwo.txt |
|------------|----------------|-------|--------------------------|
CROSS REFERENCE MATRIX Page B-3
| A.16 | 16 |3-18-85| Testfileone.txt |
|------------|----------------|-------|--------------------------|
| A.17 | 17 |3-18-85| Test3.txt, Test4.txt |
|------------|----------------|-------|--------------------------|
| A.18 | 18 |3-18-85| Speller_master.dct |
| | | | Speller_acronym.dct |
| | | | Useron.dct, Usertw.dct |
| | | | Test1.txt, Testone.dct |
| | | | Testtwo.dct |
|------------|----------------|-------|--------------------------|
| A.19 | 19 |3-18-85| Usertw.dct |
|------------|----------------|-------|--------------------------|
| A.20 | 20 |3-18-85| Useron.dct, Usertw.dct |
|------------|----------------|-------|--------------------------|
| A.21 | 21 |3-18-85| Test1.txt |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|----------------------------------------------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
|------------|----------------|-------|--------------------------|
| | | | |
CROSS REFERENCE MATRIX Page B-4
|----------------------------------------------------------------|
CROSS REFERENCE MATRIX Page B-5
B.2 REQUIREMENTS CROSS REFERENCE MATRIX
The acceptance test requirements that were used to develop
the test specifications in Appendix A are listed below. Specific
sections from the Proposal to Design and Implement an Ada Style
Standards Checking Tool [TI84] are referenced with each
requirement. The proposal sections represent the section numbers
in the proposal document where the requirement is described.
REQUIREMENT PROPOSAL SECTION
=========== ================
1. The user will be able to enable an 2.3.1
auxiliary dictionary search. (BOTH)
2. The program will be able to merge 2.3.1
two or more user-specified
dictionaries, provided that those
dictionaries exist before the
attempted merge operation.
See also Requirements 21 and 22,
which are related. (BOTH)
3. The program will be able to list 2.3.1
the contents of a user-specified
dictionary, provided that that
dictionary exists when the program
is given the command to perform
that listing. (BOTH)
4. The program will be able to search 2.3.1
either the MASTER and ACRONYM
dictionaries, both dictionaries,
or neither dictionary. (BOTH)
5. The program will check the words in 2.3.2
the specifed input file against all
of the enabled dictionaries in the
order: MASTER dictionary first,
then ACRONYM dictionary, then user
dictionaries. (BOTH)
6. The program will indicate each word 2.3.2
suspected of being misspelled by
displaying the line in which that word
occurs, with a pointer to that word.
In addition, the program will prompt
the user for further actions.
(INTERACTIVE)
7. The program will offer the user 2.3.2
three options accompanying
CROSS REFERENCE MATRIX Page B-6
the prompt for the further actions,
and those options will be:
1. The user may request a list
of possible correct spellings
for the word suspected of
being misspelled.
2. The user may leave the word
unchanged.
3. The user may enter the correct
spelling for the word suspected
of being misspelled.
(INTERACTIVE)
8. When the user requests a list of 2.3.2
possible correct spellings, as
described in option # 1 of
Requirement # 7 above,
the program will perform an
incremental search of
all enabled dictionaries.
(INTERACTIVE)
9. When the user requests a list of 2.3.2
possible correct spellings and/or
provides a correct prefix of
the word suspected of being misspelled,
the program will locate all
dictionary entries containing
that prefix as an initial substring.
(INTERACTIVE)
10. When the requested search of 2.3.2
the dictionaries (see Specification 9)
is completed, the program will display
an alphabetized, sequentiallly-numbered
list of all discovered possible
correct spellings. (INTERACTIVE)
11. When the requested search of the 2.3.2
dictionaries is completed, in addition
to displaying the list specified
immediately above, the program will
re-prompt the user for the
correct spelling of the word
suspected of being misspelled and
will present the user with three options:
1. The user may select one of the
alternatives from the displayed list
2. The user may enter another spelling
CROSS REFERENCE MATRIX Page B-7
which is not on the displayed list.
3. The user may leave the word
unchanged.
(INTERACTIVE)
12. If the user chooses to leave the 2.3.2
word suspected of being misspelled
unchanged, as in option # 3 of
Requirement 11, the program will not
change the current spelling of
the word under consideration.
(INTERACTIVE)
13. If the user chooses to change the 2.3.2
spelling of the word suspected of
being misspelled, as in option # 1 or
option # 2 of Requirement 11,
each occurrence of the same suspected
misspelling will be changed to
the choice made by the user.
(INTERACTIVE)
14. If the MASTER and ACRONYM dictionaries 2.3.3.1
are both disabled, only the user's
enabled private dictionaries
will be searched. (BOTH)
15. If the MASTER dictionary is disabled 2.3.3.2
and the ACRONYM dictionary is enabled,
the ACRONYM dictionary and any enabled
private dictionaries will be searched.
(BOTH)
16. If no dictionary is enabled, 2.3.3.2
the program will label all words as
suspected of being misspelled. (BOTH)
17. If the user disables all dictionaries, 2.3.3.2
specifies the output file option,
and runs the program on an
error-free file, the program will
produce a file that can be used
as a private dictionary. (BOTH)
18. If the MASTER dictionary is enabled 2.3.3.3
and the ACRONYM dictionary is disabled,
the MASTER dictionary and any enabled
private dictionaries will be searched.
(BOTH)
19. If the user specifies the 2.3.3.4
LIST DICTIONARY option, the program will
compact the contents of the dictionary
CROSS REFERENCE MATRIX Page B-8
given by the user as the input file
and write the result to another file.
(BOTH)
20. If the user specifies the 2.3.3.5
MERGE DICTIONARY option, the program will
merge the input files together and,
thereafter, use the resultant file
as an auxiliary dictionary.
See Requirements 2, above, and 22,
below, related. (BOTH)
21. The program will generate an output file 2.3.3.7
containing all of the words
in the input file which are
suspected of being misspelled. (BOTH)
CROSS REFERENCE MATRIX Page B-9
B.3 TEST DATA MATRIX
The expression "TESTS" in the matrix below refers to the Test
Series number which identifies the series of tests designed to
check for compliance with the requirement with which the Test
Series number is matched.
REQUIREMENTS TESTS
============ =====
1. The user will be able to enable an 1
auxiliary dictionary search. (BOTH)
2. The program will be able to merge 2
two or more user-specified
dictionaries, provided that those
dictionaries exist before the
attempted merge operation.
See also Requirements 21 and 22,
which are related. (BOTH)
3. The program will be able to list 3
the contents of a user-specified
dictionary, provided that that
dictionary exists when the program
is given the command to perform
that listing. (BOTH)
4. The program will be able to search 4
either the MASTER and ACRONYM
dictionaries, both dictionaries,
or neither dictionary. (BOTH)
5. The program will check the words in 5
the specifed input file against all
of the enabled dictionaries in the
order: MASTER dictionary first,
then ACRONYM dictionary, then user
dictionaries. (BOTH)
6. The program will indicate each word 6
suspected of being misspelled by
displaying the line in which that word
occurs, with a pointer to that word.
In addition, the program will prompt
the user for further actions.
(INTERACTIVE)
7. The program will offer the user 7
three options accompanying
the prompt for the further actions,
and those options will be:
CROSS REFERENCE MATRIX Page B-10
1. The user may request a list
of possible correct spellings
for the word suspected of
being misspelled.
2. The user may leave the word
unchanged.
3. The user may enter the correct
spelling for the word suspected
of being misspelled.
(INTERACTIVE)
8. When the user requests a list of 8
possible correct spellings, as
described in option # 1 of
Requirement # 7 above,
the program will perform an
incremental search of
all enabled dictionaries.
(INTERACTIVE)
9. When the user requests a list of 9
possible correct spellings and/or
provides a correct prefix of
the word suspected of being misspelled,
the program will locate all
dictionary entries containing
that prefix as an initial substring.
(INTERACTIVE)
10. When the requested search of 10
the dictionaries (see Specification 9)
is completed, the program will display
an alphabetized, sequentiallly-numbered
list of all discovered possible
correct spellings. (INTERACTIVE)
11. When the requested search of the 11
dictionaries is completed, in addition
to displaying the list specified
immediately above, the program will
re-prompt the user for the
correct spelling of the word
suspected of being misspelled and
will present the user with three options:
1. The user may select one of the
alternatives from the displayed list
2. The user may enter another spelling
which is not on the displayed list.
CROSS REFERENCE MATRIX Page B-11
3. The user may leave the word unchanged.
(INTERACTIVE)
12. If the user chooses to leave the 12
word suspected of being misspelled
unchanged, as in option # 3 of
Requirement 11, the program will not
change the current spelling of
the word under consideration.
(INTERACTIVE)
13. If the user chooses to change the 13
spelling of the word suspected of
being misspelled, as in option # 1 or
option # 2 of Requirement 11,
each occurrence of the same suspected
misspelling will be changed to
the choice made by the user.
(INTERACTIVE)
14. If the MASTER and ACRONYM dictionaries 14
are both disabled, only the user's
enabled private dictionaries
will be searched. (BOTH)
15. If the MASTER dictionary is disabled 15
and the ACRONYM dictionary is enabled,
the ACRONYM dictionary and any enabled
private dictionaries will be searched. (BOTH)
16. If no dictionary is enabled, 16
the program will label all words as
suspected of being misspelled. (BOTH)
17. If the user disables all dictionaries, 17
specifies the output file option,
and runs the program on an
error-free file, the program will
produce a file that can be used
as a private dictionary. (BOTH)
18. If the MASTER dictionary is enabled 18
and the ACRONYM dictionary is disabled,
the MASTER dictionary and any enabled
private dictionaries will be searched. (BOTH)
19. If the user specifies the 19
LIST DICTIONARY option, the program will
compact the contents of the dictionary
given by the user as the input file
and write the result to another file. (BOTH)
20. If the user specifies the 20
MERGE DICTIONARY option, the program will
CROSS REFERENCE MATRIX Page B-12
merge the input files together and,
thereafter, use the resultant file
as an auxiliary dictionary.
See Requirements 2, above, and 22,
below, related. (BOTH)
21. The program will generate an output file 21
containing all of the words
in the input file which are
suspected of being misspelled. (BOTH)
::::::::::
TEST1_1.DCT
::::::::::
This
be
depends
dictionary.
much
name
particular
situation
thinking
third
will
::::::::::
TEST1_2.DCT
::::::::::
This
be
depends
dictionary.
much
name
particular
situation
thinking
third
will
::::::::::
TEST2_1.DCT
::::::::::
If
OMORROW
WORK
Whether
abstract
are
array
arrays
complete
depends
each
for
introduce
its
much
name
of
on
particular
right
situation
thinking
type
use
very
we
::::::::::
TEST2_6.DCT
::::::::::
If
OMORROW
WORK
Whether
abstract
are
array
arrays
complete
depends
each
for
introduce
its
much
name
of
on
particular
right
situation
thinking
type
use
very
we
::::::::::
TEST2_7.DCT
::::::::::
If
OMORROW
WORK
Whether
abstract
are
array
arrays
complete
depends
each
for
introduce
its
much
name
of
on
particular
right
situation
thinking
type
use
very
we
::::::::::
TEST2_8.DCT
::::::::::
If
OMORROW
WORK
Whether
abstract
are
array
arrays
complete
depends
each
for
introduce
its
much
name
of
on
particular
right
situation
thinking
type
use
very
we
::::::::::
TEST2_9.DCT
::::::::::
If
OMORROW
WORK
Whether
abstract
are
array
arrays
ask
complete
depends
each
end
for
introduce
its
job
knots
listing
maybe
much
nabs
name
nape
nass
nate
nats
nazs
nepo
noes
nome
noss
nots
of
on
particular
right
situation
thinking
this
type
upyors
use
very
we
why
wordspell
would
::::::::::
TEST2_10.DCT
::::::::::
If
OMORROW
WORK
Whether
abstract
are
array
arrays
complete
depends
each
for
introduce
its
much
name
of
on
particular
right
situation
thinking
type
use
very
we
::::::::::
TEST3_1.DCT
::::::::::
Whether introduce type for
arrays OMORROW very on
abstract each If are
of array complete its
right we use
::::::::::
TEST4_1.DCT
::::::::::
If
This
Whether
abstract
are
array
arrays
be
complete
depends
dictionary.
each
for
introduce
its
much
name
of
on
particular
situation
thinking
third
type
use.
very
we
will
::::::::::
TEST4_2.DCT
::::::::::
AFW
Ada
DCS
NSA
::::::::::
TEST4_3.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST4_4.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST4_5.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST4_6.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST4_7.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST4_8.DCT
::::::::::
AFW
Ada
DCS
NSA
::::::::::
TEST4_9.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST4_10.DCT
::::::::::
AFW
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST4_11.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST4_12.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST4_13.DCT
::::::::::
AFW
NSA
::::::::::
TEST5_1.DCT
::::::::::
AFW
Ada
DCS
NSA
::::::::::
TEST5_2.DCT
::::::::::
AFW
NSA
::::::::::
TEST5_3.DCT
::::::::::
AFW
NSA
::::::::::
TEST12_1.TXT
::::::::::
Whether we introduce a type name for a particular arrays depends very much
on the abstract view of each situation. If we are thinking of the array
as a complete object in its own rigt then we should use a type name. If on
the other hand we are thinking of the array as merely an indexable conglomer
This line is for DCS, ACSL ATB and other Ada words.
ate not related as a whole to other arrays then it should probably be of an
anonymous type.
Arays lik OMORROW n WORK_DAY f te las setion re ood exmples
of arrays which are of the anonymous rigt category. To be forced to introduct
a tpe ame fr sch arays woud intoduce unecessary clter nd a possbly
false sense of abstraction.
On the other hand if we are manipulating lots of arrays of reals of length
6 hen thre is a comon unerlying abstrac tye ad so it shold be naed.
The model for array types intorduced so far is still not satis
factory. It does not allow us to represent an abstract view that embraces th
ommonality between arrays which has
have different bounds but are otherwise of the same type. In particular
it would not allow the writing of subprograms rigt which could take an array
of arbitrary bounds as an actual parameter. This is generally recognised
as a major difficulty with Pascal. So the concept of an unconstrained array
type
is introduced in which the constraints for the indexes are not given. Consider
::::::::::
TEST13_1.TXT
::::::::::
Whether we introduce a type name for a particular arrays depends very much
on the abstract view of each situation. If we are thinking of the array
as a complete object in its own right then we should use a type name. If on
the other hand we are thinking of the array as merely an indexable conglomer
This line is for DCS, ACSL ATB and other Ada words.
ate not related as a whole to other arrays then it should probably be of an
anonymous type.
Arays lik OMORROW n WORK_DAY f te las setion re ood exmples
of arrays which are of the anonymous right category. To be forced to introduct
a tpe ame fr sch arays woud intoduce unecessary clter nd a possbly
false sense of abstraction.
On the other hand if we are manipulating lots of arrays of reals of length
6 hen thre is a comon unerlying abstrac tye ad so it shold be naed.
The model for array types intorduced so far is still not satis
factory. It does not allow us to represent an abstract view that embraces th
ommonality between arrays which has
have different bounds but are otherwise of the same type. In particular
it would not allow the writing of subprograms right which could take an array
of arbitrary bounds as an actual parameter. This is generally recognised
as a major difficulty with Pascal. So the concept of an unconstrained array
type
is introduced in which the constraints for the indexes are not given. Consider
::::::::::
TEST14_1.DCT
::::::::::
ACSL
ATB
Ada
Arays
Consider
DCS
In
It
Pascal.
So
The
To
WORK
abstrac
abstraction.
actual
ad
allow
ame
an
and
anonymous
arays
arbitrary
as
ate
between
bounds
but
category.
clter
comon
concept
conglomer
constraints
could
depends
different
difficulty
does
embraces
exmples
f
factory.
false
far
forced
fr
generally
given.
hand
has
have
hen
in
indexable
indexes
intoduce
intorduced
introduced
introduct
is
it
las
length
lik
line
lots
major
manipulating
merely
model
much
n
naed.
nd
not
object
ommonality
ood
other
otherwise
own
parameter.
particular
possbly
probably
re
reals
recognised
related
represent
rigt
same
satis
sch
sense
setion
shold
should
situation.
so
still
subprograms
take
te
th
that
the
then
thinking
thre
to
tpe
tye
types
unconstrained
unecessary
unerlying
us
view
which
whole
with
words.
woud
writing
::::::::::
TEST14_2.DCT
::::::::::
ACSL
ATB
Ada
Arays
Consider
DCS
In
It
Pascal.
So
The
To
WORK
abstrac
abstraction.
actual
ad
allow
ame
an
and
anonymous
arays
arbitrary
as
ate
be
between
bounds
but
category.
clter
comon
concept
conglomer
constraints
could
depends
different
difficulty
does
embraces
exmples
f
factory.
false
far
forced
fr
generally
given.
hand
has
have
hen
in
indexable
indexes
intoduce
intorduced
introduced
introduct
is
it
las
length
lik
line
lots
major
manipulating
merely
model
much
n
naed.
nd
not
object
ommonality
ood
other
otherwise
own
parameter.
particular
possbly
probably
re
reals
recognised
related
represent
rigt
same
satis
sch
sense
setion
shold
should
situation.
so
still
subprograms
take
te
th
that
the
then
thinking
thre
to
tpe
tye
types
unconstrained
unecessary
unerlying
us
view
which
whole
with
words.
woud
writing
::::::::::
TEST15_1.DCT
::::::::::
AFW
NSA
This
acronyms
added
and
be
dictionary.
file
other
the
third
to
will
::::::::::
TEST15_2.DCT
::::::::::
AFW
NSA
This
acronyms
added
and
be
depends
dictionary.
file
much
name
other
particular
situation
the
thinking
third
to
will
::::::::::
TEST15_3.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TEST16_1.DCT
::::::::::
If
This
Whether
abstract
are
array
arrays
be
complete
depends
dictionary.
each
for
introduce
its
much
name
of
on
particular
situation
thinking
third
type
use.
very
we
will
::::::::::
TEST17_1.DCT
::::::::::
An
It
We
all
all.
alternative
an
array
at
be
bounds
bounds.
but
by
could
creating
dimension
for
gave
give
have
important
introduct
is
it
just
legal
matrix
must
name
no
none
not
notice
one
or
other.
perfectly
point
subtype
that
the
to
type
with
would
::::::::::
TEST17_2.DCT
::::::::::
boonds
boueds
bounfs.
diminsion
elternative
impoetant
notce
suctype
::::::::::
TEST18_1.DCT
::::::::::
ACSL
ATB
Ada
Arays
DAY
DCS
OMORROW
WORK
abstrac
ame
arays
clter
comon
conglomer
exmples
f
fr
intoduce
intorduced
introduct
las
lik
n
naed.
nd
ommonality
ood
possbly
recognised
rigt
satis
sch
setion
shold
te
th
thre
tpe
tye
unecessary
unerlying
woud
::::::::::
TEST18_2.DCT
::::::::::
ACSL
ATB
Ada
Arays
DAY
DCS
WORK
abstrac
ame
arays
clter
comon
conglomer
exmples
f
fr
intoduce
intorduced
introduct
las
lik
n
naed.
nd
ommonality
ood
possbly
recognised
rigt
satis
sch
setion
shold
te
th
thre
tpe
tye
unecessary
unerlying
woud
::::::::::
TEST18_3.DCT
::::::::::
ACSL
ATB
Ada
Arays
DAY
DCS
abstrac
ame
arays
clter
comon
conglomer
exmples
f
fr
intoduce
intorduced
introduct
las
lik
n
naed.
nd
ommonality
ood
possbly
recognised
rigt
satis
sch
setion
shold
te
th
thre
tpe
tye
unecessary
unerlying
woud
::::::::::
TEST19_1.DCT
::::::::::
second dictionarylist mostanythinggoes PHILLIP
Phillipe telephone telegraph telegraphy
telephoney DAY coaxial serial
ribbon parallel misspelled lexicon
graphically sketch drafting longing
logging afterwards maybeso
::::::::::
TEST20_1.DCT
::::::::::
DAY
PHILLIP
Phillipe
afterwards
ask
coaxial
dictionarylist
drafting
end
graphically
job
knots
lexicon
listing
logging
longing
maybe
maybeso
misspelled
mostanythinggoes
nabs
name
nape
nass
nate
nats
nazs
nepo
noes
nome
noss
nots
parallel
ribbon
second
serial
sketch
telegraph
telegraphy
telephone
telephoney
this
upyors
why
wordspell
would
::::::::::
TEST20_2.DCT
::::::::::
If
Whether
abstract
are
array
arrays
be
complete
depends
dictionary.
each
for
introduce
its
much
of
on
particular
situation
thinking
third
type
use.
very
we
will
::::::::::
TEST21_1.DCT
::::::::::
ACSL
Arays
abstrac
ame
arays
clter
comon
conglomer
exmples
f
fr
intoduce
intorduced
introduct
las
lik
n
naed.
nd
ommonality
ood
possbly
recognised
rigt
satis
sch
setion
shold
te
th
thre
tpe
tye
unecessary
unerlying
woud
::::::::::
TESTB1_1.DCT
::::::::::
This
be
depends
dictionary.
much
name
particular
situation
thinking
third
will
::::::::::
TESTB3_1.DCT
::::::::::
If
OMORROW
Whether
abstract
are
array
arrays
complete
each
for
introduce
its
of
on
right
type
use
very
we
::::::::::
TESTB3_2.DCT
::::::::::
Document <<INVALID.DCT>> is invalid.
This operation is terminated.
::::::::::
TESTB4_1.DCT
::::::::::
If
This
Whether
abstract
are
array
arrays
be
complete
depends
dictionary.
each
for
introduce
its
much
name
of
on
particular
situation
thinking
third
type
use.
very
we
will
::::::::::
TESTB4_2.DCT
::::::::::
AFW
Ada
DCS
NSA
::::::::::
TESTB4_3.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB4_4.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB4_5.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB4_6.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB4_7.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB4_8.DCT
::::::::::
AFW
Ada
DCS
NSA
::::::::::
TESTB4_9.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB4_10.DCT
::::::::::
AFW
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB4_11.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB4_12.DCT
::::::::::
AFW
Ada
DCS
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB4_13.DCT
::::::::::
AFW
NSA
::::::::::
TESTB5_1.DCT
::::::::::
AFW
Ada
DCS
NSA
::::::::::
TESTB5_2.DCT
::::::::::
AFW
NSA
::::::::::
TESTB5_3.DCT
::::::::::
AFW
NSA
::::::::::
TESTB14_1.DCT
::::::::::
ACSL
ATB
Ada
Arays
Consider
DAY
DCS
In
It
Pascal.
So
The
To
WORK
abstrac
abstraction.
actual
ad
allow
ame
an
and
anonymous
arays
arbitrary
as
ate
between
bounds
but
category.
clter
comon
concept
conglomer
constraints
could
depends
different
difficulty
does
e
embraces
exmples
f
factory.
false
far
forced
fr
generally
given.
hand
has
have
hen
in
indexable
indexes
intoduce
intorduced
introduced
introduct
is
it
las
length
lik
line
lots
major
manipulating
merely
model
much
n
naed.
name
name.
nd
not
object
ommonality
ood
other
otherwise
own
parameter.
particular
possbly
probably
re
reals
recognised
related
represent
rigt
same
satis
sch
sense
setion
shold
should
situation.
so
still
subprograms
take
te
th
that
the
then
thinking
thre
to
tpe
tye
typ
types
unconstrained
unecessary
unerlying
us
view
which
whole
with
words.
woud
would
writing
::::::::::
TESTB14_2.DCT
::::::::::
ACSL
ATB
Ada
Arays
Consider
DAY
DCS
If
In
It
OMORROW
On
Pascal.
So
The
To
WORK
Whether
abstrac
abstract
abstraction.
actual
ad
allow
ame
an
and
anonymous
arays
arbitrary
are
array
arrays
as
ate
between
bounds
but
category.
clter
comon
complete
concept
conglomer
constraints
could
depends
different
difficulty
does
e
each
embraces
exmples
f
factory.
false
far
for
forced
fr
generally
given.
hand
has
have
hen
if
in
indexable
indexes
intoduce
intorduced
introduce
introduced
introduct
is
it
its
las
length
lik
line
lots
major
manipulating
merely
model
much
n
naed.
name
name.
nd
not
object
of
ommonality
on
ood
other
otherwise
own
parameter.
particular
possbly
probably
re
reals
recognised
related
represent
rigt
same
satis
sch
sense
setion
shold
should
situation.
so
still
subprograms
take
te
th
that
the
then
thinking
thre
to
tpe
tye
typ
type
type.
types
unconstrained
unecessary
unerlying
us
use
very
view
we
which
whole
with
words.
woud
would
writing
::::::::::
TESTB15_1.DCT
::::::::::
AFW
NSA
acronyms
added
and
depends
file
much
name
other
particular
situation
the
thinking
to
::::::::::
TESTB15_2.DCT
::::::::::
AFW
NSA
This
acronyms
added
and
be
depends
dictionary.
file
much
name
other
particular
situation
the
thinking
third
to
will
::::::::::
TESTB15_3.DCT
::::::::::
AFW
If
NSA
This
Whether
abstract
acronyms
added
and
are
array
arrays
be
complete
depends
dictionary.
each
file
for
introduce
its
much
name
of
on
other
particular
situation
the
thinking
third
to
type
use.
very
we
will
::::::::::
TESTB16_1.DCT
::::::::::
If
This
Whether
abstract
are
array
arrays
be
complete
depends
dictionary.
each
for
introduce
its
much
name
of
on
particular
situation
thinking
third
type
use.
very
we
will
::::::::::
TESTB17_1.DCT
::::::::::
An
It
We
all
all.
alternative
an
array
at
be
bounds
bounds.
but
by
could
creating
dimension
for
gave
give
have
important
introduct
is
it
just
legal
matrix
must
name
no
none
not
notice
one
or
other.
perfectly
point
subtype
that
the
to
type
with
would
::::::::::
TESTB17_2.DCT
::::::::::
boonds
boueds
bounfs.
diminsion
elternative
impoetant
notce
suctype
::::::::::
TESTB18_1.DCT
::::::::::
ACSL
ATB
Ada
Arays
DAY
DCS
OMORROW
WORK
abstrac
ame
arays
clter
comon
conglomer
e
exmples
f
fr
intoduce
intorduced
introduct
las
lik
n
naed.
nd
ommonality
ood
possbly
recognised
rigt
satis
sch
setion
shold
te
th
thre
tpe
tye
typ
unecessary
unerlying
woud
::::::::::
TESTB18_2.DCT
::::::::::
ACSL
ATB
Ada
Arays
DAY
DCS
WORK
abstrac
ame
arays
clter
comon
conglomer
e
exmples
f
fr
intoduce
intorduced
introduct
las
lik
n
naed.
nd
ommonality
ood
possbly
recognised
rigt
satis
sch
setion
shold
te
th
thre
tpe
tye
typ
unecessary
unerlying
woud
::::::::::
TESTB18_3.DCT
::::::::::
ACSL
ATB
Ada
Arays
DAY
DCS
abstrac
ame
arays
clter
comon
conglomer
e
exmples
f
fr
intoduce
intorduced
introduct
las
lik
n
naed.
nd
ommonality
ood
possbly
recognised
rigt
satis
sch
setion
shold
te
th
thre
tpe
tye
typ
unecessary
unerlying
woud
::::::::::
TESTB19_1.DCT
::::::::::
DAY
PHILLIP
Phillipe
afterwards
coaxial
dictionarylist
drafting
graphically
lexicon
logging
longing
maybeso
misspelled
mostanythinggoes
parallel
ribbon
second
serial
sketch
telegraph
telegraphy
telephone
telephoney
::::::::::
TESTB21_1.DCT
::::::::::
ACSL
Arays
DAY
OMORROW
WORK
abstrac
ame
arays
clter
comon
conglomer
e
exmples
f
fr
intoduce
intorduced
introduct
las
lik
n
naed.
nd
ommonality
ood
possbly
recognised
rigt
satis
sch
setion
shold
te
th
thre
tpe
tye
typ
unecessary
unerlying
woud