head	1.16;
access;
symbols;
locks; strict;
comment	@% @;


1.16
date	92.11.11.08.38.01;	author lacey;	state Exp;
branches;
next	1.15;

1.15
date	92.11.11.08.19.03;	author malingka;	state Exp;
branches;
next	1.14;

1.14
date	92.11.11.08.05.55;	author lacey;	state Exp;
branches;
next	1.13;

1.13
date	92.11.11.08.02.46;	author malingka;	state Exp;
branches;
next	1.12;

1.12
date	92.11.11.07.59.53;	author gaubert;	state Exp;
branches;
next	1.11;

1.11
date	92.11.11.05.02.39;	author gaubert;	state Exp;
branches;
next	1.10;

1.10
date	92.11.11.04.32.30;	author lacey;	state Exp;
branches;
next	1.9;

1.9
date	92.11.11.02.43.48;	author gaubert;	state Exp;
branches;
next	1.8;

1.8
date	92.11.11.02.42.51;	author malingka;	state Exp;
branches;
next	1.7;

1.7
date	92.11.10.22.02.51;	author malingka;	state Exp;
branches;
next	1.6;

1.6
date	92.11.10.19.54.56;	author gaubert;	state Exp;
branches;
next	1.5;

1.5
date	92.11.10.17.01.58;	author malingka;	state Exp;
branches;
next	1.4;

1.4
date	92.11.10.03.13.53;	author gaubert;	state Exp;
branches;
next	1.3;

1.3
date	92.11.10.00.36.06;	author gaubert;	state Exp;
branches;
next	1.2;

1.2
date	92.11.09.09.21.29;	author lacey;	state Exp;
branches;
next	1.1;

1.1
date	92.11.07.22.42.44;	author lacey;	state Exp;
branches;
next	;


desc
@@


1.16
log
@*** empty log message ***
@
text
@%
% Put a \input{filename}, as in:
%
% \input{module-GUI}
%
% for each of your modules.

\input{module-database}
\input{module-GUI}
\input{read_procedure_etc}
\input{write_procedure_etc}
\input{procedure-calc}
\input{procedure-pert}
\input{procedure-gantt}


@


1.15
log
@done
@
text
@d8 1
a8 1
%DATABASE GOES HERE
a11 1
%CALCULATIONS GO HERE
@


1.14
log
@*** empty log message ***
@
text
@d13 1
@


1.13
log
@*** empty log message ***
@
text
@d7 3
d12 1
a12 1

@


1.12
log
@*** empty log message ***
@
text
@d9 1
@


1.11
log
@bla bla
@
text
@d9 2
a10 2


@


1.10
log
@*** empty log message ***
@
text
@d7 2
@


1.9
log
@hjklhkj
,
@
text
@a0 17
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% From the information described in the Test plan, give the 
% actual procedure for carrying out the plans.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Test Procedure}










%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% For each top level module:
d2 1
a2 1
%	0. Describe the top level module
d4 1
a4 2
%	1. List the low-level modules that are invoked by the
% 	top level module
d6 1
a6 4
%	2. Discuss integration provisions and outline integration tests
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Order of integration}
\paragraph{Purpose}
a8 2
\input{read-file-integ}
\input{write-file-integ}
a9 31
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Describe (briefly) the modules that are to be tested.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\paragraph{Modules to be tested}


%
% Guys --- put in an input line like the one below for each module
% that you have.
%\input{moduleX}
%

%
%   This is the input files for the read functions and modules.
%   This module must come after the database tests.    
%
\input{moduleread-file}
\input{module-yyparse}
\input{module-yylex}
%
%    This is the modules for the write file routines, these modules must 
%  come after the database and the read modules.
%
\input{module-write-file-setup}
\input{module-write-file}
%
%   Calculation subsystem's modules.
%
%\input{module-gen-calc.tex}
%\input{module-gantt-calc.tex}
%\input{module-date-calc.tex}
@


1.8
log
@*** empty log message ***
@
text
@d56 1
a57 1
\input{module-write-file-setup}
@


1.7
log
@*** empty log message ***
@
text
@d61 3
a63 3
\input{module-gen-calc.tex}
\input{module-gantt-calc.tex}
\input{module-date-calc.tex}
@


1.6
log
@This version has all on the include files.
@
text
@d61 4
a64 1
\input{moduleCalc}
@


1.5
log
@add \input{moduleCalc.tex}
@
text
@d30 2
a31 6
%
%   This is Brians read module explaning the integration of this module
%  with the modules that it calls and the integration of the modules that
%  calls it 
%
\paragraph{Read File Module}
a32 84
  The read-file module will be used to set up the file pointer yyin
and to call the function yyparse. This module will also error check
the file to make sure that the file exist and that it is a valid file.
After the file pointer is set up, the function yyparse is called. This
function will call yylex a number of times until the file is
successfully scanned or until there is an error. If there should be an
error in either the scanning or the parsing of the file, the function
yyparse will return a value of 1 to its caller. Thus at this time the
read-file module will notify the user that the file used is an invalid
file.  At the time that the read is taking place, the functions create
a list, create a node, add to the end of the list, to pop the node
from the stack, push the node onto the stack, to create task info, to
create a resource list, and add to the resource list will be called.

  Since the Bison tool function yyparse is automatically set up for
calling the yylex function, there will be no test for intergration
here. However, integration test will be used in the call to yyparse
from the read-file module and tests will be made to insure that the
file is getting scanned and parsed correctly. More over, the database
functions will be coded and tested before the read functions will be
integrated. The read function will also be tested with a driver
function and stubs for the database functions that it calls. This
testing will be done before the integration of the read file 
and database functions.

  Integration of the read file module and all of the modules that it
calls, with the exception of the database functions,  will done after
a unit test of each of the modules are made. Test cases for the
integration of these modules will show the values of the parameters
that the function passes from one function to another. These functions
will consist of the pop and push routines. Tests will also be made
within the yyparse and yylex functions. Within the scanner, yylex, the
token code numbers will printed out to the screen. Within the function
yyparse, the number of the production rule that applies to the
particular event from the file will be printed. The integration test
between the yyparse and yylex functions will consist of making sure the parser
is recieving the correct tokens for the production rules that it
passes over within the file. The used of hand made test files will be
made for these tests. 

%
%   This is the integration of the write modules. It will explain the 
%   the modules that each function calls and the functions that call it.
%
\paragraph{Write File module}


  There has been a slight deviation in the write-file module, since
the write-file module is recursive, a write-file-setup module must be
present to retrieve the filename and the top of the main task list.
The call to write-file will only have the parameter of a pointer taat
points to the top of the main task list. If the file is unsuccessful
at the time of the open statement an error will be sent back to the
caller. 

  The write-file module will traverse through the main task list and
printout all of the tasks and that tasks subtasks until the routine
reaches a null pointer to a main task list. This module will create
two task list pointers, one to keep track of the main task list that
the function is currently on and the other to go through the subtasks
of the task list that the function is currently on. There will be a
function that will get the filename from the user interface and will
set up the file pointer to point to the top of the main task list.
From here there will be a cell to implememt the recursive write-file
function. The function will only call itself if there are subtasks
within the task that it is currently on. When the write-file goes into
a recursive state, there are subtasks in the task, the function will
be called with the pointer of the subtask list. This process will
happen until the subtask list is exhausted. At this point, both of the
temperary pointers will point to the next task in the main list.

  The only module that will be called from the write-file modules is
the get-main-task-list function which returns the pointer to the top
of the main task list.

  The integration of this module will depend on the database
being in working order and that the user interface has made retrieved
the filename from the user and has made the call to the write-file-setup
module with that filename. 

\paragraph{Purpose}



d49 3
a51 3
\input{moduleread-file.tex}
\input{module-yyparse.tex}
\input{module-yylex.tex}
d56 2
a57 2
\input{module-write-file.tex}
\input{module-write-file-setup.tex}
d61 1
a61 1
\input{moduleCalc.tex}
@


1.4
log
@ I have included the write-file modules, and the order of integration of these modulex.
@
text
@d146 4
@


1.3
log
@I have included the purpose of the testing for the read-file module and all
of its lower level modules and have included the module name files for the modulex
to be tested
@
text
@d77 5
d84 33
d135 2
a136 1
%    By Brian Gaubert
d140 6
@


1.2
log
@*** empty log message ***
@
text
@d27 1
d30 6
d37 42
d94 7
@


1.1
log
@Initial revision
@
text
@a39 45


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% The following subsubsection should be repeated for each module that
% is invoked by the top-level module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Unit tests for module X} 
\begin{description}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Describe the test for the module.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Description of test for module X:}] \hfill \\



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Use of stubs or other software to facilitate the test
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Overhead software description:}] \hfill \\




%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% What data did you use to conduct the tests?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{\bf Test case data:}] \hfill \\


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Briefly, what type of results do you expect?
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\item[{Expected Results:}] \hfill \



\end{description}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% DO NOT FILL OUT THE FOLLOWING SECTION FOR THE TESTING SPEC DELIVERABLE!!
% The testing results will be turned when the practice demo is given.
d41 4
a44 3
% For each top level module, describe the testing results.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 
%\subsubsection{Actual Test Results}
@
