Index: trunk/doc/LaTex/DAM - Technical Design/DAM - Technical Design.tex
===================================================================
diff -u -r41 -r47
--- trunk/doc/LaTex/DAM - Technical Design/DAM - Technical Design.tex	(.../DAM - Technical Design.tex)	(revision 41)
+++ trunk/doc/LaTex/DAM - Technical Design/DAM - Technical Design.tex	(.../DAM - Technical Design.tex)	(revision 47)
@@ -94,232 +94,45 @@
 %\label{xxx}
 \begin{tabular}{|p{40mm}|p{\textwidth-40mm-24pt}|} \hline
 \textbf{Title} & \textbf{Content} \\ \hline
-Functional Design \newline  \citep{GrassUI_FunctionalDesign} & Description of the requirements and functional design. \\ \hline
-Technical Design \newline  \citep{GrassUI_TechnicalDesign} & Description of the implementation of the technical design of \ProgramName. \\ \hline
-Technical documentation \newline \citep{GrassUI_TechnicalDocumentation} & Description of the arguments and usage of different software components, generated from in-line comment with Doxygen. \\ \hline
-Test Plan (this document) & Description of the different regression and acceptation tests, including target values.  \\ \hline
-Test Report \newline \citep{GrassUI_TestReport} & Description of the test results (benchmarks and test scripts). \\ \hline
-User Manual  (included  \newline with the software) & Description of the different functionalites available in the \textit{User Interface} and background information. \\ \hline
+Functional Design \newline  \citep{DAM_FunctionalDesign} & Description of the requirements and functional design. \\ \hline
+Technical Design (this document) & Description of the implementation of the technical design of \ProgramName. \\ \hline
+Technical documentation \newline \citep{DAM_TechnicalDocumentation} & Description of the arguments and usage of different software components, generated from in-line comment with Doxygen. \\ \hline
+Test Plan \newline \citep{DAM_TestPlan} & Description of the different regression and acceptation tests, including target values.  \\ \hline
+Test Report \newline \citep{DAM_TestReport} & Description of the test results (benchmarks and test scripts). \\ \hline
+User Manual  \newline \citep{DAM_Manual} & Description of the different functionalites available in the \textit{User Interface} and background information. \\ \hline
 \end{tabular}
 \end{table}
 
 
-\section{Requirements} \label{sec:1.3}
+%------------------------------------------------------------------------------
+\chapter{System Architecture} \label{chapter2}
 
-\subsection{Functional requirements} \label{sec:1.3.1}
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
 
-In the Functional Design of the \textit{User Interface} \citep{GrassUI_FunctionalDesign}, the following requirements are defined and must be therefore tested. They will be tested at System Testing level (see \autoref{chapter4}). 
 
 
-\begin{longtable}{p{13mm}p{\textwidth-13mm-24pt}}
-\textbf{REQ 1} & The \textit{User Interface} must support the input of all required data. \\
-\textbf{REQ 2} & The \textit{User Interface} must support the validation of all required input data. \\
-\textbf{REQ 3} & The \textit{User Interface} must be able to start the Grass Run up Assessment calculation. \\
-\textbf{REQ 4} & The \textit{User Interface} must be able to retrieve the results of the Grass Run up Assessment calculation. \\
-\textbf{REQ 5} & The \textit{User Interface} must support the display of the results of the Grass Run up Assessment calculation. \\
-\textbf{REQ 6} & The \textit{User Interface} must be able to start the Grass Impact Assessment calculation. \\
-\textbf{REQ 7} & The \textit{User Interface} must be able to retrieve the results of the Grass Impact Assessment calculation. \\
-\textbf{REQ 8} & The \textit{User Interface} must support the display of the results of the Grass Impact Assessment calculation. \\
-\textbf{REQ 9} & The \textit{User Interface} must be able to read and write all data to its own file for storage and reuse of the data. \\
-\textbf{REQ 10} & The \textit{User Interface} must offer functionality to switch between all of its parts. \\
-\textbf{REQ 11} & The \textit{User Interface} must be available in Dutch. \\
-\textbf{REQ 12} & The \textit{User Interface} must offer simple visualization of the input for the Grass Impact Assessment Calculation. \\
-\textbf{REQ 13} & The \textit{User Interface} must offer simple visualization of the input for the Grass Impact Run up Calculation. \\
-\end{longtable}
 
-
-\subsection{Non-functional requirements} \label{sec:1.3.2}
-
-Besides the functional requirements, \ProgramNamePlusSpace must meet some non-functional requirements. These  non-functional requirements are the same as required for WTI software. All non-functional requirements (NFR, U, TAB, TOI, PSR, R, SLA and Top) are given in the spreadsheet that lists all WTI requirements \citep{WTINonFunctionalRequirementsList}. The non-functional requirements with relevance to the development of this application and its proposed use are listed in the Functional Design \citep{GrassUI_FunctionalDesign}.
-
-Not all non-functional requirements can be addressed via automatic tests or even by manual testing. Only the non-functional requirements given in \autoref{tab:NonFunctReqs} can be tested via unit/integration tests or test-scripts and will be therefore reported in the Test Report.
-
-\begin{table}[H]
-\caption{``Non-Functional Requirements'' relevant at Test level for \ProgramNamePlusSpace}
-\label{tab:NonFunctReqs} 
-\begin{tabular}{|p{15mm}|p{90mm}|p{\textwidth-105mm-36pt}|} \hline
-\rowcolor[gray]{.8} \textbf{Nr.} & \textbf{Requirement} & \textbf{Testing level} \\ \hline %& \textbf{Description of the test} \\ \hline
-
-NFR3 & Data definitions will follow existing and emerging standards such as IRIS as much as possible. & System Testing \\ \hline %&  The names and symbols of the input parameters used in the test-scripts must be conform the WTI parameter list \citep{WTIParameterList}. \\ \hline
-
-NFR6 &  Sufficient error checks on the validity and completeness of data during import or input, as well as during a computation.  & System Testing \\ \hline %& The valid interval of the input parameters and the other possible validation errors must be tested via test-script. \\ \hline
-
-NFR8 & Output of detailed deterministic results must enable all users to trace back the correctness of the implemented mechanism models. & System Testing \\ \hline %& See REQ 5 and REQ 8 in \autoref{xxx}. \\ \hline
-
-NFR12 & The user-interface may not cause crashes during regular usage. & System Testing \\ \hline %& The tester should not get crash when testing the program.  \\  \hline
-
-NFR14 & Consistency between the input data and the output data must be guaranteed. & System Testing \\ \hline %&  Can be tested via relevant test-script(s). \\ \hline
-
-NFR15 & The general required code coverage is 80\%, except for the Delta Shell Light components, therefore the code coverage of 60\% is required. & Component and Integration Testing \\ \hline %& See \autoref{chapter2} and \autoref{chapter3}. \\  \hline
-
-%U158 & Voor elke WTI applicatie moet worden aangetoond dat de netwerk-installatie ook werkt binnen een Citrix omgeving.
- 
-U123   & De WTI Software moet tot een eenduidig en reproduceerbaar resultaat leiden. & System Testing \\ \hline
-
-U124 & De WTI Software moet robuust zijn voor kleine variaties in de invoer. Onder 'robuust' wordt verstaan: nooit een software crash. Dus: ofwel een melding dat invoer onjuist is, ofwel een melding dat een som niet convergeert, ofwel een antwoord retourneert.  &  System testing  \\ \hline %&  Can be tested via relevant test-script(s). \\ \hline
-
-U129 & Alle componenten binnen een bibliotheek moeten foutcodes retourneren met een gestandaardiseerde (nog nader vast te stellen) betekenis of gebruiken excepties om fouten door te geven. & System testing \\ \hline %& Idem as NFR6. \\ \hline
-
-U131 & Om de bibliotheken te kunnen testen levert elke bibliotheek testsoftware mee in de vorm van unit tests. & Component and Integration Testing \\ \hline
-
-U132 & De IO laag sluit altijd aan op een intern bestand voor opslag van de invoer- en (tussen)resultaten. & System Testing \\ \hline %& See REQ 9 in \autoref{xxx}. \\ \hline
-
-U133 & De WTI tools worden standaard alleen uitgeleverd met een Nederlandstalige UI en met Nederlandstalige meldingen en rapportages. & System Testing \\ \hline %&  Can be tested via relevant test-script(s). \\ \hline
-
-U145 & De naamgeving van objecten, parameters, functies moet over alle applicaties heen consistent zijn. Voor dat doel moet gebruik worden gemaakt van de actuele versies van de terminologielijst en de parameterlijst. & System Testing \\ \hline %& Idem NFR3. \\ \hline
-
-TAB2 & De applicaties moeten door gebruikers gebruikt kunnen worden met standaardrechten. Het moet dus niet nodig zijn om de applicatie uit te voeren met administrator rechten, met uitzondering van installatie. & System Testing \\ \hline %& Can be tested via relevant test-script(s). \\ \hline
-
-Top 10 & De gebruiker kan bepalen waar de gegevens worden neergezet. & System Testing \\ \hline %& See REQ 9 in \autoref{xxx}. \\ \hline
-
-\end{tabular}
-\end{table}
-
-
-\section{Test levels} \label{sec:1.4}
-According to \cite{OverallTestPlanWTI}, the program \ProgramNamePlusSpace should be tested on four different levels (V-Model):
-\begin{enumerate}
-	\item Component Testing
-	\item Integration Testing
-	\item System Testing
-	\item Acceptance Testing
-\end{enumerate}
-
-\subsection*{Component Testing (Unit tests)}
-Component Testing is testing on code level using the unit tests. For each relevant function, a unit test is defined within the C\# solution\footnote{A C\# solution is essentially a collection of source files and their relations. This collection is used to build the actual program. Besides the source code for the program itself it also contains the source code for the unit and system tests.}. A relevant function is a function that actually performs part of the calculation, validation or I/O of the core. Properties and purely administrative functions do not have unit tests. \\
-Refer to \Cref{chapter2} for more information.
-
-\subsection*{Integration Testing (Integration tests)}
-Integration Testing is testing on functional level using integration tests. These types of tests combine multiple functions to prove that high level functionality works. For this, a unit test is defined within the C\# solution
- for each method with high level functionality.\\
-Refer to \Cref{chapter3} for more information.
-
-\subsection*{System Testing (Benchmarks and test scripts)}
-System Testing is testing the functioning of the complete system:
-\begin{itemize}%[no separator]
-	\item The main calculator must provide the correct answers to confirm its performance according to the functional design;
-	\item All possible errors must be handled and reported properly;
-	\item The \textit{User Interface} must function properly.
-\end{itemize}	
-Refer to \Cref{chapter4} for more information.
-
-\subsection*{Acceptation level (Acceptance tests)}
-The Acceptance Test of \ProgramNamePlusSpace will be covered in the acceptance test for the overall WTI system (which includes acceptance tests for the stand-alone tools) and will be reported in a so-called Acceptance Report \citep{AcceptatieTestPlan}.
-
-
-\section{Code coverage}\label{sec:1.5}
-
-Testing is considered to be ok when all the unit tests pass and when the code coverage of those tests is more than 60\% so as prescribed in \cite{OverallTestPlanWTI}.
-
-Note that within the context of this test plan the components which are not part of the program development, i.e. external component but also the DSL components, are not included in the test coverage.\footnote{For the DSL components separate test plans and test reports are available.}
-
-To determine the code coverage of the \textit{Calculation} components, the feature `Code coverage' of Visual Studio can be used. This tool shows the percentage of the code that was tested in each assembly, class, and method, and is visible on the build server.
-
-
-
-
-
 %------------------------------------------------------------------------------
-\chapter{Component Testing (Unit tests)} \label{chapter2}
+\chapter{Architectural Choices} \label{chapter3}
 
-The tests on code level are the unit tests. For each relevant function, a unit test is defined within the C\# solution. A relevant function is a function that actually performs part of the calculation, validation or I/O of the core. Properties and purely administrational functions do not have unit tests.
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
 
-These tests are considered to be ok when the unit tests pass and when the code coverage of those tests is more than 60\%, as prescribed in \cite{OverallTestPlanWTI} for UI solutions. For these tests, see the C\# solution.
 
-The following information must be provided in the Test Report:\footnote{Unit tests are related directly to the implementation in source code and therefore have no direct relation to the functional requirements, referred to above.}
-\begin{itemize}
-	\item Number of unit tests
-	\item Code coverage of the unit tests
-	\item Specify if all unit tests succeed or not
-\end{itemize}
 
-
-
-
-
 %------------------------------------------------------------------------------
-\chapter{Integration Testing (Integration tests)} \label{chapter3}
+\chapter{Data Model}  \label{chapter4}
 
-The tests on functional level are the integration tests. These types of tests combine multiple functions in the kernel to prove that high level functionality works. For this, an integration test is defined within the C\# solution for each method with high level functionality.
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
 
-These tests are considered to be ok when the integration tests pass. For these tests, see the C\# solution. Both the source code and the external data for these tests and the unit tests are an integral part of the delivery.
 
-The following information must be provided in the Test Report:
-\begin{itemize}
-	\item Number of integration tests
-	\item Code coverage of the integration tests
-	\item Specify if all integration tests succeed or not
-\end{itemize}
-
-
-
-
 %------------------------------------------------------------------------------
-\chapter{System Testing (Benchmarks and Test Scripts)}  \label{chapter4}
+\chapter{Data Description}  \label{chapter5}
 
-The tests on this level are to provide proof of the fact that the program meets its acceptation criteria:
-\begin{itemize}
-	\item all main functions must provide the correct answers;
-	\item all possible errors must be handled and reported properly;
-	\item the functionalities of the \textit{User Interface} listed in the functional requirements (\Sref{sec:1.3.1}) must be present and work properly;
-	\item the non-functional requirements listed in \Sref{sec:1.3.2} must be present and work properly.
-\end{itemize}
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
 
 
-\section{Test of the output} \label{sec:4.1}
-
-Based on the formula in the Functional Design of the Grass Run-up Zone and the Grass Wave Impact Zone kernels, benchmarks were created to test both kernels \citep{GrassWaveRunupKernel_TestReport_15_2_1, GrassWaveImpactKernel_TestReport_15_2_1}. The same benchmarks can be used to test \ProgramName.
-
-For the Grass Run-up calculation, there are 13 benchmarks:
-\begin{enumerate}
-	\item One stationary event, `not scaled' computation of cumulative overload
-	\item One stationary event, `scaled' computation of cumulative overload
-	\item One stationary event, `scaled' computation of cumulative overload, $z_{\text{eval}}$ = 2 m			
-	\item One stationary event, `scaled' computation of cumulative overload, $z_{\text{eval}}$ = 3 m
-	\item One stationary event, `scaled' computation of cumulative overload, $\alpha_{\text{M}}$ = 1.5
-	\item One stationary event, `scaled' computation of cumulative overload, $\alpha_{\text{S}}$ = 0.8
-	\item One stationary event, `scaled' computation of cumulative overload, $\alpha_{\text{S}}$ = 0.8 and $\alpha_{\text{M}}$ = 2
-	\item One stationary event, `scaled' computation of cumulative overload, small waves
-	\item One stationary event, `scaled' computation of cumulative overload, very small waves
-	\item One stationary event, `scaled' computation of cumulative overload, very large waves
-	\item Synthetic storm data (time series), `not scaled' computation of cumulative overload
-	\item Synthetic storm data (time series), `scaled' computation of cumulative overload
-	\item Direct input storm data, `scaled' computation of cumulative
-overload  	
-\end{enumerate}
-
-For the Grass Wave Impact calculation, there are 9 benchmarks:
-\begin{enumerate}
-	\item `Direct input' storm event (Vechtdelta deelgebied A-1) - closed sod
-	\item `Direct input' storm event (Vechtdelta deelgebied A-1) - open sod
-	\item `Direct input' storm event (Vechtdelta deelgebied A-1) - fragmented sod
-	\item `Direct input' storm event (Benedenrivierengebied) - closed sod
-	\item `Direct input' storm event (Benedenrivierengebied) - open sod
-	\item `Direct input' storm event (Kust) - open sod
-	\item `Synthetic' storm event (Time series Q-variant)
-	\item `Synthetic' storm event - Time series water level exceeds Q-Variant water level +0,03 m
-	\item `Direct input' storm event (Vechtdelta deelgebied A -1) - closed sod - $t_{\text{s,top}} < t_{\text{s,top,min}}$
-\end{enumerate}
-
-The output of those benchmarks will be checked via unit tests and the result will be visible on the build server.
-
-
-\section{Test of the error(s)/warning(s)} \label{sec:4.2}
-
-The error(s) generated by an incomplete input or input outside its limits can be tested at code level via the unit tests, see \Cref{chapter2}, using the valid intervals of the input parameters given in the Functional Design \citep{GrassUI_FunctionalDesign}. Results of those unit tests will be visible on the build server.
-
-
-
-\section{Test of the \textit{User Interface}} \label{sec:4.3}
-
-The test of the \textit{User Interface} will be executed by a tester using \textit{Test Script(s)}. All the requirements listed in the Functional Design of the program (\Sref{sec:1.3.1}) and all the relevant non-functional requirements (\Sref{sec:1.3.2}) must be tested. 
-
-A \textit{Test Script} describes a sequence of actions and the expected outcome. All the \textit{Test Scripts} are part of a so-called \textit{Test Document} that will be joined as Annex in the Test Report.
-
-
-
 %------------------------------------------------------------------------------
-\chapter{Literature}  \label{chapter5}
+\chapter{Literature}  \label{chapter6}
 
 \bibliography{../DAM_references/dam_references}
 
