%************************************************************************
%
% 		TemplateComp.tex
%
% Template file for all component descriptions to be processed using ddd.sty.
% An edited version of this file should be created for each component, 
% subcomponent, subsubcomponent etc. that you write. Each executable gets its
% own chapter and is introduced by \component for the main function. The 
% functions called from the main function are \subcomponent and the functions
% they call are \twosubcomponent .......all the way down to \fivesubcomponent.
% Each executable will have a mini table of contents at the beginning of its
% chapter showing all the components it contains right down to the lowest
% level. The main table of contents at the beginning of the DDD will only show
% where each executable can be found, though individual components will be
% findable using the index at the back. If you need even more levels of
% nesting let me know.
%
% You need to edit every field surrounded by !....! Please remove all my
% instructional comments if you don't need them.
%
% Carol Anne Oxborrow 10/6/99
%
% Version 2.0 10/10/99: Trimmed down version of the original
%			Should be easier to maintain, and produce a 
%			reasonable amount of output
%
%************************************************************************

\(one/two/three/sub)component{!NameOfComponent!}
% Every executable gets a whole chapter to itself. 
% Subcomponents get a section etc.
% ddd.sty allows for fives nested layers of subcomponents. Let me know if
% this is not enough.

\responsibletype{!Type!}{!language!}{!responsible institution!}
% First argument is type of component: executable, or function.
%  Second argument is programming languge 
% and third is the responsible institution.

\filename{!name of component file!}
% This gives the name of the file (all lower case letters to be CTS-compliant)
% which may, after all, be different from the name of the actual function

\compintro{!version!}{!date!}{!coder!}
% First argument is delivered version of component. Second argument is date this
% version was delivered to ISDC. Third argument is the name of the person or people
% who wrote the source code for the component.

\compitem{Function:}{!Function of the component in some detail!}
% Do not change first argument of this command

\compitem{ISDC Context}{!Description of where this component appears in ISDC 
	top-level ADD!}
% Again, don't change first argument in this command.
	
\compitem{Required Libraries and headers}{!List all the libraries and headers 
	that are used by the component!}
% Again, don't change first argument in this command.


\diagram{scale=0.8}{*****.eps}{Sample diagram to show component structure}
% A diagram to show which functions call which other functions is very welcome

% First argument specifies scaling that may be neccesary to fit diagram on page
% If your diagram already fits nicely just put scale=1.0
% Second argument is the filename
% ***.eps must be found in subdirectory /graphics
% Diagrams are not completely neccesary, but are needed if your component has
% many subcomponents and lots of nesting
% Third argument is the caption for the diagram

%*** Environment for making changes-to-component table ********

\begin{compchanges}

	\changeitem{!date of change!}{!version being created!}{!description!}
	% Every change is a component that has already been delivered needs
	% a \changeitem entry. It has three arguments:
	% date the change was coded
	% Version that is being edited (if you've delivered version 1.0 of your
	% component and ISDC demands certain changes be made, then you are
	% editing version 1.0, on the way to creating delivered version 2.0)
	% Description of the change. This can be quite detailed.
	
	%\changetablebreak
	% If the change table becomes quite long, and you have problems because
	% the table needs to be broken across two (or more) pages, put this
	% command in between separate \changeitem commands at the point where
	% you need a break. Breaks cannot occur within a \changeitem command.

\end{compchanges}

%**** Environment for listing components that call this component ******

\begin{parents}

	\parent{!Name of calling component!}
	% Every calling component needs a separate \parent command

\end{parents}

%***** Environment to list subcomponents used by component ***

\begin{children}

	\child{!Subordinate component name!}
	% As for ADD
	% Each called compononent requires its own \child entry

\end{children}

%******* Processing environment,***********************

\begin{processing}

	% Tab stops have been defined in this environment so you only need to
	% use \> each time you want an indent for a nested loop or similar.
	% Each line of pseudocode must end with \\

\end{processing}

%***** Lists arising from component pseudo code **********


%****** Environment to list data input structures ******

\begin{datain}

	\initem{!Name of data input structure!}{!Repository number!}{!location
			of sub directory!}
	% As for ADD with addition of repository and location fields

\end{datain}

%******* Environment to list data output structures ********

\begin{dataout}

	\outitem{!Name of data output structure!}{!Repository number!}{!location
			of sub directory!}
	% As for ADD with addition of repository and location fields
	
\end{dataout}

%******* Environment to list parameters used ********

\begin{paramsin}

	\paramitem{!name!}{!type!}{!mode!}{!default!}{!minimum!}{!maximum!}{!prompt!}		
	% Each parameter, listed with \paramitem requires 7 arguments:
	% name; type; mode; default; min; max; prompt
	% This format follows that for IRAF parameter files
		
\end{paramsin}

%******* Environment to list special resources used ********

\begin{resources}

	\resitem{!Description of resource!}
	% Each separate resource needs its own \resitem entry
	
\end{resources}

%****** Environment to list design remarks ********

\begin{remarks}

	\remitem{!BRIEF header!}{!Remarks as detailed as humanly possible!}
	%Each remark requires its own \remitem entry
	% The first argument should not exceed 2--3 words
	% while the second argument should be as detailed as possible
	
\end{remarks}

%******* Environment for listing error codes for this component ****

\begin{errorconditions}
	\erroritem{!Condition causing error!}{!Error code!}{!ASCII string!}
%	Each error requires a separate erroritem entry. The condition described
%	can be as long as you want. 
%	The error code should be negative.
%	The ASCII string must conform to CTS specifications.
\end{errorconditions}