diff --git a/CaseStudies/gamephys/docs/Design/MG/GamePhysicsMG.pdf b/CaseStudies/gamephys/docs/Design/MG/GamePhysicsMG.pdf index 8d727726..32ff715b 100644 Binary files a/CaseStudies/gamephys/docs/Design/MG/GamePhysicsMG.pdf and b/CaseStudies/gamephys/docs/Design/MG/GamePhysicsMG.pdf differ diff --git a/CaseStudies/gamephys/docs/Design/MG/GamePhysicsMG.tex b/CaseStudies/gamephys/docs/Design/MG/GamePhysicsMG.tex index f91c877f..f331d011 100644 --- a/CaseStudies/gamephys/docs/Design/MG/GamePhysicsMG.tex +++ b/CaseStudies/gamephys/docs/Design/MG/GamePhysicsMG.tex @@ -4,9 +4,12 @@ \usepackage[round]{natbib} \usepackage{multirow} \usepackage{booktabs} +\usepackage{tabularx} \usepackage{graphicx} +\usepackage{float} \usepackage{hyperref} + \hypersetup{ bookmarks=true, % show bookmarks bar? colorlinks=true, % false: boxed links; true: colored links @@ -15,6 +18,8 @@ filecolor=magenta, % color of file links urlcolor=cyan % color of external links } + +\input{../../Comments} \newcounter{acnum} \newcommand{\actheacnum}{AC\theacnum} \newcommand{\acref}[1]{AC\ref{#1}} @@ -27,33 +32,61 @@ \newcommand{\mthemnum}{M\themnum} \newcommand{\mref}[1]{M\ref{#1}} -%% Comments -\newif\ifcomments\commentstrue - -\ifcomments -\newcommand{\authornote}[3]{\textcolor{#1}{[#3 ---#2]}} -\newcommand{\todo}[1]{\textcolor{red}{[TODO: #1]}} -\else -\newcommand{\authornote}[3]{} -\newcommand{\todo}[1]{} -\fi - -\newcommand{\wss}[1]{\authornote{magenta}{SS}{#1}} +%\newcommand{\wss}[1]{\authornote{magenta}{SS}{#1}} +\newcommand{\olu}[1]{\authornote{red}{OO}{#1}} +\newcommand{\progname}{Tamias2D} \begin{document} -\title{Module Guide for Chipmunk2D Game Physics Library} -\author{Alex Halliwushka and Luthfi Mawarid} +\title{Module Guide for Tamias2D Physics Library} +%update project name- olu +\author{Alex Halliwushka and Luthfi Mawarid and Olu Owojaiye} \date{\today} \maketitle +~\newpage + +\pagenumbering{roman} + +\section{Revision History} + +\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X} +\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\ +\midrule +2018-12-11 & 1.3 & updated with github feedback\\ +2018-11-12 & 1.2 & Updated program name\\ +2018-11-4 & 1.1 & Update with feedback notes\\ +2018-10-30 & 1.0 & Modification to existing file\\ +%Date 2 & 1.1 & Notes\\ +\bottomrule +\end{tabularx} + +~\newpage + \tableofcontents +\listoftables + +\listoffigures + +\newpage + +\pagenumbering{arabic} + \section{Introduction} -Decomposing a system into modules is a commonly accepted approach to developing software. A module is a work assignment for a programmer or programming team~\citep{ParnasEtAl1984}. In the best practices for scientific computing, \citet{WilsonEtAl2013} advise a modular design, but are silent on the criteria to use to decompose the software into modules. We advocate a decomposition based on the principle of information hiding~\citep{Parnas1972a}. This principle supports design for change, because the ``secrets'' that each module hides represent likely future changes. Design for change is valuable in SC, where modifications are frequent, especially during initial development as the solution space is explored. \\ -\newline +Decomposing a system into modules is a commonly accepted approach to developing +software. A module is a work assignment for a programmer or programming +team~\citep{ParnasEtAl1984}. In the best practices for scientific computing, +\citet{WilsonEtAl2013} advise a modular design, but are silent on the criteria +to use to decompose the software into modules. We advocate a decomposition +based on the principle of information hiding~\citep{Parnas1972a}. This principle +supports design for change, because the ``secrets'' that each module hides +represent likely future changes. Design for change is valuable in SC, where +modifications are frequent, especially during initial development as the +solution space is explored. + Our design follows the rules laid out by \citet{ParnasEtAl1984}, as follows: \begin{itemize} \item System details that are likely to change independently should be the @@ -115,22 +148,16 @@ \subsection{Anticipated Changes} \label{SecAchange} \item[\refstepcounter{acnum} \actheacnum \label{acBody}:] The data structure of the physical properties of an object such as the object's mass, position and velocity. \item[\refstepcounter{acnum} \actheacnum \label{acShape}:] The data structure of the -surface properties of an object such as the object's friction and elasticity. +surface properties of an object such as the object's elasticity/ Coefficient of restitution. \item[\refstepcounter{acnum} \actheacnum \label{acSpace}:] How all the rigid bodies and shapes interact together. \item[\refstepcounter{acnum} \actheacnum \label{acCollision}:] The data structure containing collision information such as the objects that collide and their mass. -\item[\refstepcounter{acnum} \actheacnum \label{acControl}:] How the overall - control of the simulation is orchestrated, including the input and output of data. +%\item[\refstepcounter{acnum} \actheacnum \label{acControl}:] How the overall + %control of the simulation is orchestrated, including the input and output of data. \item[\refstepcounter{acnum} \actheacnum \label{acVector}:] The implementation of mathematical vectors. \item[\refstepcounter{acnum} \actheacnum \label{acBBox}:] The implementation of bounding box structures. -\item[\refstepcounter{acnum} \actheacnum \label{acTrans}:] The implementation of transformation matrices. -\item[\refstepcounter{acnum} \actheacnum \label{acSpatialIndex}:] How the simulation space is spatially indexed. \item[\refstepcounter{acnum} \actheacnum \label{acSolver}:] The algorithm used for solving collisions. -\item[\refstepcounter{acnum} \actheacnum \label{acSeqDS}:] The implementation - for the sequence (array) data structure. -\item[\refstepcounter{acnum} \actheacnum \label{acLinkDS}:] The implementation for the linked (tree) data structure. -\item[\refstepcounter{acnum} \actheacnum \label{acAssocDS}:] The implementation - for the associative (hash table) data structure. + \end{description} \subsection{Unlikely Changes} \label{SecUchange} @@ -144,8 +171,9 @@ \subsection{Unlikely Changes} \label{SecUchange} followed by a number. \begin{description} -\item[\refstepcounter{ucnum} \uctheucnum \label{ucIO}:] Input/Output devices - (Input: Keyboard and/or mouse, Output: Memory and/or Screen). +%\item[\refstepcounter{ucnum} \uctheucnum \label{ucIO}:] Input/Output devices + % (Input: Keyboard and/or mouse, Output: Memory and/or Screen). + % \\olu: removed UC1 \item[\refstepcounter{ucnum} \uctheucnum \label{ucInput}:] There will always be a source of input data external to the software. \item[\refstepcounter{ucnum} \uctheucnum \label{ucOutput}:] Output data are displayed to the output device. @@ -167,23 +195,14 @@ \section{Module Hierarchy} \label{SecMH} followed by a number. \begin{description} -\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Hardware-Hiding Module -\item [\refstepcounter{mnum} \mthemnum \label{mBody}:] Rigid Body Module -\item [\refstepcounter{mnum} \mthemnum \label{mShape}:] Shape Module -\item [\refstepcounter{mnum} \mthemnum \label{mCircle}:] Circle Module -\item [\refstepcounter{mnum} \mthemnum \label{mSegment}:] Segment Module -\item [\refstepcounter{mnum} \mthemnum \label{mPoly}:] Polygon Module -\item [\refstepcounter{mnum} \mthemnum \label{mSpace}:] Space Module -\item [\refstepcounter{mnum} \mthemnum \label{mCollision}:] Arbiter Module -\item [\refstepcounter{mnum} \mthemnum \label{mControl}:] Control Module -\item [\refstepcounter{mnum} \mthemnum \label{mVector}:] Vector Module -\item [\refstepcounter{mnum} \mthemnum \label{mBBox}:] Bounding Box Module -\item [\refstepcounter{mnum} \mthemnum \label{mTrans}:] Transform Matrix Module -\item [\refstepcounter{mnum} \mthemnum \label{mSpatialIndex}:] Spatial Index Module -\item [\refstepcounter{mnum} \mthemnum \label{mSolver}:] Collision Solver Module -\item [\refstepcounter{mnum} \mthemnum \label{mSeqDS}:] Sequence Data Structure Module -\item [\refstepcounter{mnum} \mthemnum \label{mLinkDS}:] Linked Data Structure Module -\item [\refstepcounter{mnum} \mthemnum \label{mAssocDS}:] Associative Data Structure Module +\item [\refstepcounter{mnum} \mthemnum \label{mHH}:] Hardware-Hiding +\item [\refstepcounter{mnum} \mthemnum \label{mBody}:] Rigid Body +\item [\refstepcounter{mnum} \mthemnum \label{mShape}:] Shape +\item [\refstepcounter{mnum} \mthemnum \label{mCircle}:] Circle +\item [\refstepcounter{mnum} \mthemnum \label{mPoly}:] Polygon +\item [\refstepcounter{mnum} \mthemnum \label{mSpace}:] Space +\item [\refstepcounter{mnum} \mthemnum \label{mVector}:] Vector +\item [\refstepcounter{mnum} \mthemnum \label{mSolver}:] Collision Solver \end{description} \noindent Note that \mref{mHH} is a commonly used module and is already implemented by the operating @@ -203,30 +222,22 @@ \section{Module Hierarchy} \label{SecMH} & Rigid Body Module \\ & \multirow{3}{0.3\textwidth}{Shape Module} & Circle Module \\ -& &Segment Module \\ -& &Polygon Module \\ +& &Polygon Module \\ & Space Module \\ -& Arbiter Module \\ -& Control Module \\ +%& Control Module \\ \midrule -\multirow{8}{0.3\textwidth}{Software Decision Module} +\multirow{3}{0.3\textwidth}{Software Decision Module} & Vector Module \\ -& Transform Matrix Module \\ -& Bounding Box Module \\ -& Spatial Index Module \\ & Collision Solver Module \\ -& Sequence Data Structure Module \\ -& Linked Data Structure Module \\ -& Associative Data Structure Module \\ \bottomrule - \end{tabular} \caption{Module Hierarchy} \label{TblMH} \end{table} -\section{Connection Between Requirements and Design} \label{SecConnection} +~\newpage +\section{Connection Between Requirements and Design} \label{SecConnection} The design of the system is intended to satisfy the requirements developed in the SRS. In this stage, the system is decomposed into modules. The connection between requirements and modules is listed in Table \ref{TblRT}. @@ -237,8 +248,7 @@ \section{Module Decomposition} \label{SecMD} proposed by \citet{ParnasEtAl1984}. The \emph{Secrets} field in a module decomposition is a brief statement of the design decision hidden by the module. The \emph{Services} field specifies \emph{what} the module will do -without documenting \emph{how} to do it. For each module, a suggestion for the implementing software is given under the \emph{Implemented By} title. If the entry is \emph{OS}, this means that the module is provided by the operating system or by standard programming language libraries. If the entry is \emph{Chipmunk}, this means that the module will be implemented by the -game physics library. +without documenting \emph{how} to do it. For each module, a suggestion for the implementing software is given under the \emph{Implemented By} title. If the entry is \emph{OS}, this means that the module is provided by the operating system or by standard programming language libraries. If the entry is \emph{\progname}, this means that the module will be implemented by the game physics library. % should reference a command for the name, in case it changes If a dash (\emph{--}) is shown, this means that the module is not a leaf and will not have to be implemented. Whether or @@ -266,7 +276,7 @@ \subsection{Behaviour-Hiding Module} the system as specified in the software requirements specification (SRS) documents. This module serves as a communication layer between the hardware-hiding module and the software decision module. The programs in this module will need to change if there are changes in the SRS. -\item[Implemented By:] -- +\item[Implemented By:] -- {\progname} \end{description} \subsubsection{Rigid Body Module (\mref{mBody})} @@ -276,7 +286,7 @@ \subsubsection{Rigid Body Module (\mref{mBody})} \item[Services:]Stores the physical properties of an object, such as mass, position, rotation, velocity, etc, and provides operations on rigid bodies, such as setting the mass and velocity of the body. -\item[Implemented By:] Chipmunk +\item[Implemented By:] {\progname} \end{description} \subsubsection{Shape Module (\mref{mShape})} @@ -284,8 +294,8 @@ \subsubsection{Shape Module (\mref{mShape})} \begin{description} \item[Secrets:]The data structure of a collision shape. \item[Services:]Stores the surface properties of an object, such as friction or elasticity, and provides operations on shapes, such as setting its friction or elasticity. -\item[Children:] Circle Module, Segment Module, Polygon Module -\item[Implemented By:] Chipmunk +\item[Children:] Segment Module, Polygon Module +\item[Implemented By:] {\progname} \end{description} \paragraph{Circle Module (\mref{mCircle})} @@ -293,23 +303,16 @@ \subsubsection{Shape Module (\mref{mShape})} \begin{description} \item[Secrets:] The data structure of a circle shape. \item[Services:] Provides operations on circles such as initializing a new circle, calculating moment and area, etc. - \item[Implemented By:] Chipmunk + \item[Implemented By:] {\progname} \end{description} -\paragraph{Segment Module (\mref{mSegment})} - -\begin{description} - \item[Secrets:] The data structure of a segment shape. - \item[Services:] Provides operations on segments such as initializing a new segment, calculating moment and area, etc. - \item[Implemented By:] Chipmunk -\end{description} \paragraph{Polygon Module (\mref{mPoly})} \begin{description} \item[Secrets:] The data structure of a polygon shape. \item[Services:] Provides operations on polygons such as initializing a new polygon, calculating moment, area and centroid, etc. - \item[Implemented By:] Chipmunk + \item[Implemented By:] {\progname} \end{description} \subsubsection{Space Module (\mref{mSpace})} @@ -317,26 +320,21 @@ \subsubsection{Space Module (\mref{mSpace})} \begin{description} \item[Secrets:] The container for simulating objects. \item[Services:]Controls how all the rigid bodies and shapes interact together. - \item[Implemented By:] Chipmunk + \item[Implemented By:] {\progname} \end{description} - -\subsubsection{Arbiter Module (\mref{mCollision})} - -\begin{description} -\item[Secrets:]The data structure containing collision information. -\item[Services:]Stores all collision data, such as which bodies -collided and their masses. -\item[Implemented By:] Chipmunk -\end{description} -\subsubsection{Control Module (\mref{mControl})} - -\begin{description} -\item[Secrets:] The algorithm for coordinating the running of the program and the interface for receiving inputs and sending outputs. -\item[Services:] Provides the main program. -\item[Implemented By:] Chipmunk -\end{description} - +%<<<<<<< HEAD +%======= +%\subsubsection{Control Module (\mref{mControl})} +\olu{removed control module} \wss{okay}\\ + +%\begin{description} +%\item[Secrets:] The algorithm for coordinating the running of the program %and the interface for receiving inputs and sending outputs. +%\item[Services:] Provides the main program. +%\item[Implemented By:] Chipmunk +%\end{description} +%\\olu: removed the above +%>>>>>>> c8802be2592e48f7d9e18b8049bcc504c32b0601 \subsection{Software Decision Module} \begin{description} @@ -344,9 +342,9 @@ \subsection{Software Decision Module} facts, or programming considerations. The secrets of this module are \emph{not} described in the SRS. \item[Services:] Includes data structure and algorithms used in the system that do not provide direct interaction with the user. - % Changes in these modules are more likely to be motivated by a desire to - % improve performance than by externally imposed changes. -\item[Implemented By:] -- + Changes in these modules are more likely to be motivated by a desire to + improve performance than by externally imposed changes. +\item[Implemented By:] -- {} \end{description} \subsubsection{Vector Module (\mref{mVector})} @@ -354,67 +352,18 @@ \subsubsection{Vector Module (\mref{mVector})} \begin{description} \item[Secrets:] The data structure representing vectors. \item[Services:] Provides vector operations such as addition, scalar and vector multiplication, dot and cross products, rotations, etc. - \item[Implemented By:] Chipmunk + \item[Implemented By:] {\progname} \end{description} -\subsubsection{Bounding Box Module (\mref{mBBox})} - -\begin{description} - \item[Secrets:] The data structure for representing bounding boxes. - \item[Services:] Provides constructors for bounding boxes and operations such as merging boxes, calculating their centroids and areas, etc. - \item[Implemented By:] Chipmunk -\end{description} - -\subsubsection{Transform Matrix Module (\mref{mTrans})} - -\begin{description} - \item[Secrets:] The data structure representing transformation matrices. - \item[Services:] Provides constructors for affine transformation matrices, matrix operations such as inverse, transpose, multiplications, and operations for applying transformations to vectors and bounding boxes. - \item[Implemented By:] Chipmunk -\end{description} - -\subsubsection{Spatial Index Module (\mref{mSpatialIndex})} - -\begin{description} - \item[Secrets:] The data structures and algorithms for spatially indexing the simulation space. - \item[Services:] Provides spatial indexing operations and tracks the positions of bodies in the simulation space. - \item[Implemented By:] Chipmunk -\end{description} \subsubsection{Collision Solver Module (\mref{mSolver})} \begin{description} \item[Secrets:] The data structures and algorithms for detecting collisions. - \item[Services:] Fast collision filtering, primitive shape to shape collision detection. - \item[Implemented By:] Chipmunk -\end{description} - -\subsubsection{Sequence Data Structure Module (\mref{mSeqDS})} - -\begin{description} -\item[Secrets:] The data structure for a sequence data type. -\item[Services:] Provides array manipulation operations, such as building an array, accessing a specific entry, slicing an array, etc. -\item[Implemented By:] Chipmunk -\end{description} - -\subsubsection{Linked Data Structure Module (\mref{mLinkDS})} - -\begin{description} -\item[Secrets:] The data structure for a linked data type. -\item[Services:] Provides tree manipulation operations, such as building a tree, accessing a specific entry, etc. -\item[Implemented By:] Chipmunk -\end{description} - -\subsubsection{Associative Data Structure Module (\mref{mAssocDS})} - -\begin{description} -\item[Secrets:] The data structure for an associative data type. -\item[Services:] Provides operations on hash tables, such as building a hash table, accessing a specific entry, etc. -\item[Implemented By:] Chipmunk + \item[Services:] This module implements the operations and algorith for collision detection and collision response such as Fast collision filtering, primitive shape to shape collision detection e.t.c. + \item[Implemented By:] {collision.py} \end{description} -~\newpage - \section{Traceability Matrix} \label{SecTM} This section shows two traceability matrices: between the modules and the @@ -428,14 +377,15 @@ \section{Traceability Matrix} \label{SecTM} \toprule \textbf{Req.} & \textbf{Modules}\\ \midrule - R1 & M\ref{mSpace}, M\ref{mControl}, M\ref{mSeqDS} \\ - R2 & M\ref{mBody}, M\ref{mControl}, M\ref{mVector}, M\ref{mTrans} \\ - R3 & M\ref{mShape}, M\ref{mCircle}, M\ref{mSegment}, M\ref{mPoly}, M\ref{mControl}, M\ref{mVector} \\ - R4 & M\ref{mBody}, M\ref{mShape}, M\ref{mCircle}, M\ref{mSegment}, M\ref{mPoly}, M\ref{mSpace}, M\ref{mControl} \\ - R5 & M\ref{mBody}, M\ref{mSpace}, M\ref{mVector}, M\ref{mTrans} \\ - R6 & M\ref{mBody}, M\ref{mSpace}, M\ref{mVector}, M\ref{mTrans} \\ - R7 & M\ref{mBody}, M\ref{mSpace}, M\ref{mBBox}, M\ref{mSpatialIndex}, M\ref{mSolver}, M\ref{mLinkDS}, M\ref{mAssocDS} \\ - R8 & M\ref{mBody}, M\ref{mSpace}, M\ref{mVector}, M\ref{mTrans}, M\ref{mCollision} \\ + R1 & M\ref{mSpace} \\ + R2 & M\ref{mBody}, M\ref{mVector} \\ + R3 & M\ref{mShape},M\ref{mCircle}, M\ref{mPoly}, M\ref{mVector} \\ + R4 & M\ref{mBody}, M\ref{mShape},M\ref{mCircle}, M\ref{mPoly}, M\ref{mSpace} \\ + R5 & M\ref{mBody}, M\ref{mSpace}, M\ref{mVector} \\ + R6 & M\ref{mBody}, M\ref{mSpace}, M\ref{mVector} \\ + R7 & M\ref{mBody}, M\ref{mSpace}, M\ref{mSolver}\\ + R8 & M\ref{mBody}, M\ref{mSpace}, M\ref{mVector}, + M\ref{mSolver} \\ \bottomrule \end{tabular} \caption{Trace Between Requirements and Modules} @@ -450,18 +400,13 @@ \section{Traceability Matrix} \label{SecTM} \midrule AC\ref{acHardware} & M\ref{mHH} \\ AC\ref{acBody} & M\ref{mBody} \\ - AC\ref{acShape} & M\ref{mShape}, M\ref{mCircle}, M\ref{mSegment}, M\ref{mPoly} \\ + AC\ref{acShape} & M\ref{mShape}, M\ref{mCircle}, M\ref{mPoly} \\ AC\ref{acSpace} & M\ref{mSpace} \\ - AC\ref{acCollision} & M\ref{mCollision} \\ - AC\ref{acControl} & M\ref{mControl} \\ + AC\ref{acCollision} & M\ref{mSolver} \\ AC\ref{acVector} & M\ref{mVector} \\ - AC\ref{acBBox} & M\ref{mBBox} \\ - AC\ref{acTrans} & M\ref{mTrans} \\ - AC\ref{acSpatialIndex} & M\ref{mSpatialIndex} \\ + AC\ref{acBBox} & M\ref{mShape} \\ AC\ref{acSolver} & M\ref{mSolver} \\ - AC\ref{acSeqDS} & M\ref{mSeqDS} \\ - AC\ref{acLinkDS} & M\ref{mLinkDS} \\ - AC\ref{acAssocDS} & M\ref{mAssocDS} \\ + \bottomrule \end{tabular} \caption{Trace Between Anticipated Changes and Modules} @@ -473,31 +418,53 @@ \section{Traceability Matrix} \label{SecTM} \section{Use Hierarchy Between Modules} \label{SecUse} In this section, the uses hierarchy between modules is -provided. \citet{Parnas1978} said of two programs A and B that A {\em uses} B if correct execution of B may be necessary for A to complete the task described in its specification. That is, A {\em uses} B if there exist situations in which the correct functioning of A depends upon the availability of a correct implementation of B. Figure \ref{Fig_uses} illustrates the use relation between the modules. It can be seen that the graph is a directed acyclic graph (DAG). Each level of the hierarchy offers a testable and usable subset of the system, and modules in the higher level of the hierarchy are essentially simpler because they use modules from the lower levels. As the modules M\ref{mVector}, M\ref{mBBox} and M\ref{mTrans} are used by many other modules, their uses have been color-coded for clarity. +%<<<<<<< HEAD +provided. \citet{Parnas1978} said of two programs A and B that A {\em uses} B if correct execution of B may be necessary for A to complete the task described in its specification. That is, A {\em uses} B if there exist situations in which the correct functioning of A depends upon the availability of a correct implementation of B. Figure \ref{Fig_uses} illustrates the use relation between the modules. It can be seen that the graph is a directed acyclic graph (DAG). Each level of the hierarchy offers a testable and usable subset of the system, and modules in the higher level of the hierarchy are essentially simpler because they use modules from the lower levels. +%======= +provided. \citet{Parnas1978} said of two programs A and B that A {\em uses} B if +correct execution of B may be necessary for A to complete the task described in +its specification. That is, A {\em uses} B if there exist situations in which +the correct functioning of A depends upon the availability of a correct +implementation of B. Figure \ref{Fig_uses} illustrates the use relation between +the modules. It can be seen that the graph is a directed acyclic graph +(DAG). Each level of the hierarchy offers a testable and usable subset of the +system, and modules in the higher level of the hierarchy are essentially simpler +because they use modules from the lower levels. +%>>>>>>> c8802be2592e48f7d9e18b8049bcc504c32b0601 +~\newpage \begin{figure}[htbp] \begin{center} %\rotatebox{-90} { - \includegraphics[width=0.71\textwidth]{uses} + \includegraphics[width=0.71\textwidth]{uses1} } \caption{\label{Fig_uses}Use hierarchy among Modules} \end{center} \end{figure} -\section{Inheritance Hierarchy Between Modules} \label{SecInheritance} -In this section the inheritance hierarchy between modules is provided (Figure \ref{Fig_Inheritance}). -Modules in the lower level of the hierarchy inherit properties from the higher levels. -\begin{figure}[htbp] -\begin{center} -%\rotatebox{-90} -{ - \includegraphics[width=0.75\textwidth]{inherit.png} -} -\caption{\label{Fig_Inheritance}Inheritance hierarchy among Modules} -\end{center} -\end{figure} +%======= +\wss{As we discussed, remove the implementation design decisions modules. We + can reduce the number of modules and simplify the problem.} +\olu{updated} + +%\section{Inheritance Hierarchy Between Modules} \label{SecInheritance} +% +%In this section the inheritance hierarchy between modules is provided (Figure \ref{Fig_Inheritance}). +%Modules in the lower level of the hierarchy inherit properties from the higher levels. +%\begin{figure}[htbp] +%\begin{center} +%%\rotatebox{-90} +%{ +% \includegraphics[width=0.75\textwidth]{inherit.png} +%} +%\caption{\label{Fig_Inheritance}Inheritance hierarchy among Modules} +%\end{center} +%\end{figure} +%\olu{This section is not in the MG template but provides more info. about the Shape module} +%>>>>>>> c8802be2592e48f7d9e18b8049bcc504c32b0601 +~\newpage \bibliographystyle {plainnat} \bibliography {../../../refs/Physics_Game_Library} diff --git a/CaseStudies/gamephys/docs/Design/MG/uses1.png b/CaseStudies/gamephys/docs/Design/MG/uses1.png new file mode 100644 index 00000000..b4108b66 Binary files /dev/null and b/CaseStudies/gamephys/docs/Design/MG/uses1.png differ diff --git a/CaseStudies/gamephys/docs/SRS/SysCtxV2.png b/CaseStudies/gamephys/docs/SRS/SysCtxV2.png new file mode 100644 index 00000000..2b882afc Binary files /dev/null and b/CaseStudies/gamephys/docs/SRS/SysCtxV2.png differ diff --git a/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/Makefile b/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/Makefile new file mode 100644 index 00000000..e8ce3000 --- /dev/null +++ b/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/Makefile @@ -0,0 +1,19 @@ +# Makefile +# From https://danielkaes.wordpress.com/2009/03/14/compiling-latex-documents-using-makefiles/ + +PROJECT=SystVnVPlan +TEX=pdflatex +BIBTEX=bibtex +BUILDTEX=$(TEX) $(PROJECT).tex + +all: + $(BUILDTEX) +# $(BIBTEX) $(PROJECT) +# $(BUILDTEX) + $(BUILDTEX) + +clean-all: + rm -f *.dvi *.log *.bak *.aux *.bbl *.blg *.idx *.ps *.eps *.pdf *.toc *.out *~ + +clean: + rm -f *.log *.bak *.aux *.bbl *.blg *.idx *.toc *.out *.lof *.lot *~ \ No newline at end of file diff --git a/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/README.md b/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/README.md new file mode 100644 index 00000000..2c8b6b82 --- /dev/null +++ b/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/README.md @@ -0,0 +1,5 @@ +# Test Plan + +The folders and files for this folder are as follows: + +Describe ... diff --git a/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/SystVnVPlan.pdf b/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/SystVnVPlan.pdf new file mode 100644 index 00000000..3b7f4df3 Binary files /dev/null and b/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/SystVnVPlan.pdf differ diff --git a/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/SystVnVPlan.tex b/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/SystVnVPlan.tex new file mode 100644 index 00000000..e411f57b --- /dev/null +++ b/CaseStudies/gamephys/docs/VnVPlan/SystVnVPlan/SystVnVPlan.tex @@ -0,0 +1,467 @@ +\documentclass[12pt, titlepage]{article} + +\usepackage{booktabs} +\usepackage{tabularx} +\usepackage{hyperref} +\hypersetup{ + colorlinks, + citecolor=black, + filecolor=black, + linkcolor=red, + urlcolor=blue +} +\usepackage[round]{natbib} + +\input{../../Comments} + +\begin{document} + +\title{TamiasMini2D: System Verification and Validation Plan} +\author{Oluwaseun Owojaiye} +\date{\today} + +\maketitle + +\pagenumbering{roman} + +\section{Revision History} + +\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X} +\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\ +\midrule +2018-10-15 & 1.0 & Initial draft\\ +%Date 2 & 1.1 & Notes\\ +\bottomrule +\end{tabularx} + +~\newpage + +\section{Symbols, Abbreviations and Acronyms} +\renewcommand{\arraystretch}{1.2} +\begin{tabular}{l l} + \toprule + \textbf{symbol} & \textbf{description}\\ + \midrule + IM & Instance Model\\ + R & Requirement\\ + T & Test\\ + TBD & To be determined\\ +2D & Two-dimensional\\ +SRS & System Requirement Specification\\ + \bottomrule +\end{tabular}\\ + +For symbols and their meanings please refer to: https://github.com/smiths/caseStudies/blob/master/CaseStudies/gamephys/docs/SRS/GamePhysicsSRS.pdf +%\wss{symbols, abbreviations or acronyms -- you can simply reference the %SRS tables, if appropriate} + +\newpage + +\tableofcontents + +\listoftables + +\listoffigures + +\newpage + +\pagenumbering{arabic} + +This document provides a high-level verification and validation plan for TamiasMini2D - a 2D rigid body physics library. This document is based on the System Requirement Specification Document(SRS) located in the following project repository link: \url{https://github.com/smiths/caseStudies/tree/master/CaseStudies/gamephys}. It discusses the verification and validation requirements for TM2D, and describes the test strategy and methods that will be used to evaluate the software. The verification and validation of the software utilizes review, analysis, and testing method to determine whether a software product complies with the specifed requirements. These requirements include both functional and non-functional. +%This document ... \wss{provide an introductory blurb and roadmap of the + % Verification and Validation plan} + +\section{General Information} + +\subsection{Summary} +The software being tested is TamiasMini2D. It is a 2D rigid body physics library designed to simulate the interaction between rigid bodies. Since physics libraries are an important part of video game development, game developers will be able to make use of this library in their products. +%\wss{Say what software is being tested. Give its name and a brief %overview of its general functions.} + +\subsection{Objectives} + +The purpose of verification and validation activities are to find bugs and defects in the TM2D physics library software and also to determine if it has met all the required functionality. It is also to verify that software meets the required standard and that the end product conforms with the software requirements based on the SRS. The objectives of VnV activities for TM2D are to: + \begin{itemize} + \item Build confidence in software correctness and performance. + \item Verify the degree maintainability of the software. + based of efficiency by which this product can be enhanced, modified + and reused. + \item Verify and demonstrate the ease of use and learning of the software. + \end{itemize} + + +%\wss{State what is intended to be accomplished. The objective will be %around the qualities that are most important for your project. You might %have something like: ``build confidence in the software correctness,'' +%``demonstrate adequate usability.'' etc. You won't list all of the %qualities,just those that are most important.} + +\subsection{References} + +\begin{itemize} + \item[1.] \url {https://github.com/smiths/caseStudies/blob/GamePhy_Olu/CaseStudies/gamephys/docs/SRS/GamePhysicsSRS.pdf} +\end{itemize} + +%\wss{Reference relevant documentation. This will definitely include your SRS} + +\section{Plan} + +\subsection{Verification and Validation Team} +The verification and validation team consists of a one member team: Olu Owojaiye +%\wss{Probably just you. :-)} + +\subsection{SRS Verification Plan} +The SRS for the project will be reviewed by Dr. Smith and coursemates and feedback will be provided.Some SRS feedback for this project have been provided and addressed using github issue tracker. Also once the software has been implemented, the SRS will be reviewed to ensure that software has met all the specified requirements in SRS and more feedback will be provided via github. + +%\wss{List any approaches you intend to use for SRS verification. This may %just be ad hoc feedback from reviewers, like your classmates, or you may %have something more rigorous/systematic in mind..} + +\subsection{Design Verification Plan} +To ensure that the Design Specification has been properly specified and meets software requirements, Dr. Smith and my coursemates will be verifying the software design.The Module Guide and Module Interface Specification will contain information about the software design. Feedback is expected to be rovided by reviewers via github issue tracker. +%\wss{Plans for design verification} + +\subsection{Implementation Verification Plan} + The implementation of TM2D will involve inspection of the software to ensure that all the required features have been implemented successfully and are functional. Once the development activities are completed, Dr Smith and my some of CAS761 coursemates will perform the implementation verification activities. The software will be installed by the testers and system test cases specified in Section 5 will be run. Reviewers are expected to verify both functional and non-functional requirements specified below. Exploratory testing should also be performed by testers. + Any implementation verification issues will be reported and tracked via github issue tracker and these issues will be resolved in order of severity by myself. After the issues raised have been fixed, they will be sent back to reviewrs for re-verification. +%\wss{You should at least point to the tests listed in this document and %the unit testing plan.} + +\subsection{Software Validation Plan} + + There is currently no software validation plan for TM2D. +%\wss{If there is any external data that can be used for validation, you %should point to it here. If there are no plans for validation, you %should state that here.} + +\section{System Test Description} + +\subsection{Tests for Functional Requirements} + +%\wss{Subsets of the tests may be in related, so this section is divided %into different areas. If there are no identifiable subsets for the %tests, this level of document structure can be removed.} + +\subsubsection{Translational Motion Testing} + +\paragraph{} + +\begin{enumerate} + +\item{TC1: Static rigid body velocity-position calculation\\} + +Description:Calculate the position and velocity of a 2D rigid body that is static after t secs. Gravity is not applied. The object does not move, hence velocity and position does not change based on IM1.Varying positive input parameters can be used in TC1 for each of the parameters + +Control: Automatic + +Initial State: New session - Static 2D rigid body(body is not moving) + +Input: $\mathbf{p_i}$$\mathbf{(t_0)}$ = (0, 0) ;This is the initial position of body - (x,y) coordinate position\\ + \hspace*{1.3cm}$\mathbf{v_i}$$\mathbf{(t_0)}$ = 0\\ + \hspace*{1.3cm}$\mathbf{F_i}$$\mathbf{(t_0)}$ = 0\\ + \hspace*{1.3cm}$\mathbf{m_i}$$ \mathbf{}$ = 10\\ + \hspace*{1.3cm}$\mathbf{g}$$\mathbf{}$ = 0 (acceleration due to gravity does not apply on a static body)\\ + +Output: $\mathbf{p_i}$$\mathbf{(t)}$ = (0, 0); + $\mathbf{v_i}$$\mathbf{(t)}$ = (0, 0); after t secs where t= 3 + +How test will be performed: Unit testing with PyUnit + +\item{TC2: Dynamic 2D rigid body falling from a height velocity-position calculation\\} + +Description: Calculation of the new position and velocity of a dynamic body. Force of gravity is in effect and we apply a horizontal force F. The new position and velocity is calculated. This test can be applied to a set of rigid bodies falling from a height at the same different time t. + +Control: Automatic + +Initial State: New session - see Input below + +Input: $\mathbf{p_i}$$\mathbf{(t_0)}$ = (20, 20) this is the (x,y) coordinate position\\ + \hspace*{1.3cm}$\mathbf{v_i}$$\mathbf{(t_0)}$ = 0\\ + \hspace*{1.3cm}$\mathbf{F_i}$$\mathbf{(t_0)}$ = 10\\ + \hspace*{1.3cm}$\mathbf{m_i}$$ \mathbf{}$ = 100\\ + \hspace*{1.3cm}$\mathbf{g}$$\mathbf{}$ = 9.8 (acceleration due to gravity)\\ + + +Output: $\mathbf{p_i}$$\mathbf{(t)}$ = (20.9, 20.882); + $\mathbf{v_i}$$\mathbf{(t)}$ = (0.3, 0.294); after t secs, where t= 3 + +How test will be performed: Unit testing with PyUnit + +\item{TC3: Projectile motion of dynamic 2D rigid velocity-position calculation\\} + +Description:``Projectile motion is a form of motion experienced by an object or particle (a projectile) that is thrown near the Earth's surface and moves along a curved path under the action of gravity only''. The rigid object is falling from a height specified in input. In horizontal direction, velocity is constant. + +Control: Automatic + +Initial State: New session - see Input below + +Input: $\mathbf{p_i}$$\mathbf{(t_0)}$ = (0, 125) this is the (x,y) coordinate position\\ +\hspace*{1.3cm}$\mathbf{v_i}$$\mathbf{(t_0)}$ = (10,0)\\ +\hspace*{1.3cm}$\mathbf{F_i}$$\mathbf{(t_0)}$ = 10\\ +\hspace*{1.3cm}$\mathbf{m_i}$$ \mathbf{}$ = 10\\ +\hspace*{1.3cm}$\mathbf{g}$$\mathbf{}$ = 9.8 (acceleration due to gravity)\\ +**Need to doublecheck this calculation\\ +Output: $\mathbf{p_i}$$\mathbf{(t)}$ = (50, 0); +$\mathbf{v_i}$$\mathbf{(t)}$ = (10, 50); after t secs, where t= 5 + +How test will be performed: Unit testing with PyUnit + +\end{enumerate} + +\subsubsection{Rotation of 2D Rigid Body Simulation} +This test is to simulate the rotation of a 2D rigid body about its axis. +\paragraph{} +\begin{enumerate} + + \item{TC4: 2D Rigid body rotation about its axis\\} + + Description: In rotational motion of 2D rigid bodies, Torque $\tau$ is the force which produces rotation. It has magnitude and direction.This test can also be used for multiple set of rigid bodies.(IM2) + + Control: Automatic + + Initial State: New session - see Input below + + Input: $\mathbf{m_i}$$\mathbf{}$ = 100\\ + \hspace*{1.3cm}$\mathbf{g}$$\mathbf{}$ = 0\\ + \hspace*{1.3cm}$\phi$$_i\mathbf{(t_0)}$ = 50\\ + \hspace*{1.3cm}$\omega$$_i\mathbf{(t_0)}$$ \mathbf{}$ = 0.3\\ + \hspace*{1.3cm}$\tau$$\mathbf{}$ = 1000 \\ + \hspace*{1.3cm}$\mathbf{I}$$\mathbf{(i)}$ = 10000 + + Output: $\phi$$\mathbf{(t)}$ = 50.9; + $\omega$$\mathbf{(t)}$ = 0.3; after t secs where t= 3 + + How test will be performed: Unit testing with PyUnit + + + +\end{enumerate} + +\subsubsection{Rotation of 2D Rigid Body Simulation} +This test is to simulate the collision of 2D rigid bodies. +\paragraph{} +\begin{enumerate} + + \item{TC5: Dynamic rigid body collision with static body test\\} + + Description: This is to test a set of rigid bodies that collide. This test case will test for collision of a dynamic object falling from a height with a static object. At collision the static object does not move, the dynamic object's velocity, position, angular velocity, orientation is calculated.Momentum is conserved. + + Control: Automatic + + Initial State: New session - see Input below + + Input: $\mathbf{m_k}$$\mathbf{}$ = TBD (to be determined)\\ + \hspace*{1.3cm}$\mathbf{p_k}$$\mathbf{(t_0)}$ = TBD\\ + \hspace*{1.3cm}$\mathbf{v_k}$$\mathbf{(t_0)}$ = TBD\\ + \hspace*{1.3cm}$\phi$$_k\mathbf{(t_0)}$ = TBD\\ + \hspace*{1.3cm}$\omega$$_k\mathbf{(t_0)}$$ \mathbf{}$ = TBD\\ + \hspace*{1.3cm}$\mathbf{C_R}$$\mathbf{}$ = TBD \\ + + + Output: $\mathbf{v_k}$$\mathbf{(t)}$ = TBD \\ + \hspace*{1.3cm}$\mathbf{p_k}$$\mathbf{(t)}$ = TBD\\ + \hspace*{1.3cm}$\phi$$_k\mathbf{(t)}$ = TBD\\ + \hspace*{1.3cm}$\omega$$_k\mathbf{(t)}$$ \mathbf{}$ = TBD\\ + after t secs(t, TBD) + + + How test will be performed: Unit testing with PyUnit + + \item{TC6: Dynamic rigid Body collision test(set of bodies)\\} + +Description: This is to test a set of rigid bodies that collide. This test case will test for collision of a set of dynamic object falling from a height with a static object. At collision bodies' velocity, position, angular velocity, orientation is calculated. Momentum is conserved. The input and output set generated is determined by the number of bodies added in space.Multiple objects will be simulated to fall at different times fro a height so we can simulate collision. + +Control: Automatic + +Initial State: New session - see Input below + +Input: $\mathbf{m_k}$$\mathbf{}$ = TBD (to be determined)\\ +\hspace*{1.3cm}$\mathbf{p_k}$$\mathbf{(t_0)}$ = TBD\\ +\hspace*{1.3cm}$\mathbf{v_k}$$\mathbf{(t_0)}$ = TBD\\ +\hspace*{1.3cm}$\phi$$_k\mathbf{(t_0)}$ = TBD\\ +\hspace*{1.3cm}$\omega$$_k\mathbf{(t_0)}$$ \mathbf{}$ = TBD\\ +\hspace*{1.3cm}$\mathbf{C_R}$$\mathbf{}$ = TBD \\ + + +Output: $\mathbf{v_k}$$\mathbf{(t)}$ = TBD \\ +\hspace*{1.3cm}$\mathbf{p_k}$$\mathbf{(t)}$ = TBD\\ +\hspace*{1.3cm}$\phi$$_k\mathbf{(t)}$ = TBD\\ +\hspace*{1.3cm}$\omega$$_k\mathbf{(t)}$$ \mathbf{}$ = TBD\\ +after t secs(t, TBD) + + +How test will be performed: Unit testing with PyUnit + + + +\end{enumerate} + + + +\subsection{Tests for Nonfunctional Requirements} + +\subsubsection{Usability Test for TM2D} + +\paragraph{Usability test} + +\begin{enumerate} + +\item{TC7\\} + +Type: Usability test + +Initial State: + +Input/Condition: + +Output/Result: + +How test will be performed: Users/reviewers of TM2D will be asked to install the library and use it. They will be asked to complete the survey in the Appendix section for Usability. + +\end{enumerate} + + +\subsubsection{Correctness/Performance Test for TM2D} + +\paragraph{Correctness/Performance} + +\begin{enumerate} + +\item{TC8\\} + +Type: Dynamic + +Initial State: + +Input: + +Output: + +How test will be performed: Correctness/performance will be measured by comparing output results with ODEs related to each requirement/function. +\end{enumerate} + +\subsubsection{Reusability} + +\paragraph{Reusability test} + +\begin{enumerate} + +\item{TC9\\} + +Type: Dynamic + +Initial State: + +Input: + +Output: + +How test will be performed: Users/reviewers will be asked to see if they can extend the library and use for other purposes. +... +\end{enumerate} + +\subsubsection{Understandability/Maintainability} + +\paragraph{Understandability/Maintainability test} + +\begin{enumerate} + + \item{TC9\\} + + Type: Dynamic + + Initial State: + + Input: + + Output: + + How test will be performed: Users/reviewers will be asked to see check some see if they are able to find the space module and update the body parameters are desired. Users will be asked on the scale of 1 to 5 how easy it was to find the code, understand it and make changes. + ... +\end{enumerate} + + +\subsection{Traceability Between Test Cases and Requirements} +The purpose of the information in Table 1 below is to provide a mapping between the test cases and the requirements in the SRS for easy reference and verification. +%\wss{Provide a table that shows which test cases are supporting which %requirements.} +\begin{table} + + \caption{Requirements Traceability Matrix} + + \label{Table:Table_Traceability} + + \begin{tabular}{|c|p{5cm}|p{5cm}|} + + \hline + + \textbf{Testcase Number} & \textbf{Instance Models} & \textbf{CA Requirements}\\ + + \hline + + TC1& IM1 & R1, R2, R4, R5 \\ \hline + + TC2& IM1 & R1, R2, R4, R5 \\ \hline + + TC3& IM1 & R1, R2, R4, R5 \\ \hline + + + + TC4& IM2 & R1, R2, R4, R6 \\ \hline + + TC5& IM3 & R1, R3, R4, R7, R8 \\ \hline + + + + TC6& IM3 & R1, R3, R4, R7, R8 \\ \hline + + TC7& & NFR3 \\ \hline + + + + TC8& & NFR1, NFR2 \\ \hline + + TC9& & NFR5 \\ \hline + + TC10& & NFR4, NFR6 \\ \hline + + + + + \end{tabular}\\ + +\end{table} + +\section{Static Verification Techniques} +Code review and inspection will be used as the method for implementation verification. +%\wss{In this section give the details of any plans for static verification of the implementation. Potential techniques include code walkthroughs, code inspection, static analyzers, etc.} + +\bibliographystyle{plainnat} + +\bibliography {../../../refs/References} +\begin{itemize} +\item{http://www.physicstutorials.org/home/mechanics/1d-kinematics/projectile-motion?start=1} +\item{https://en.wikipedia.org/wiki/Projectile-motion} +\item{R. A. BROUCKE. "Equations of motion of a rotating rigid body", Journal of Guidance, Control, and Dynamics, Vol. 13, No. 6 (1990), pp. 1150-1152.} +\item{https://github.com/smiths/caseStudies/blob/master/CaseStudies/gamephys/docs/SRS/GamePhysicsSRS.pdf} + +\end{itemize} + + +\newpage + +\section{Appendix} + +This is where you can place additional information. + +\subsection{Symbolic Parameters} + +The definition of the test cases will call for SYMBOLIC\_CONSTANTS. +Their values are defined in this section for easy maintenance. + +\subsection{Usability Survey Questions?} + +%\wss{This is a section that would be appropriate for some projects.} +\begin{enumerate} + +\item {On the scale of 1 - 5, 1 being very difficult and 5 being very easy, How easy was it to install the program using the installation guide? + +Comment on what can be improved:} + +\item On a scale of 1 - 5, how easy were you able to update the parameters in a space? e.g change the velocity of a body + +\item Did the program return the expected output based on the testcase and input values? + +If no, please add comments explaining issues encountered: + + +\end{enumerate} + +\end{document} \ No newline at end of file diff --git a/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/Makefile b/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/Makefile new file mode 100644 index 00000000..bb068f93 --- /dev/null +++ b/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/Makefile @@ -0,0 +1,19 @@ +# Makefile +# From https://danielkaes.wordpress.com/2009/03/14/compiling-latex-documents-using-makefiles/ + +PROJECT=UnitVnVPlan +TEX=pdflatex +BIBTEX=bibtex +BUILDTEX=$(TEX) $(PROJECT).tex + +all: + $(BUILDTEX) +# $(BIBTEX) $(PROJECT) +# $(BUILDTEX) + $(BUILDTEX) + +clean-all: + rm -f *.dvi *.log *.bak *.aux *.bbl *.blg *.idx *.ps *.eps *.pdf *.toc *.out *~ + +clean: + rm -f *.log *.bak *.aux *.bbl *.blg *.idx *.toc *.out *.lof *.lot *~ \ No newline at end of file diff --git a/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/README.md b/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/README.md new file mode 100644 index 00000000..2c8b6b82 --- /dev/null +++ b/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/README.md @@ -0,0 +1,5 @@ +# Test Plan + +The folders and files for this folder are as follows: + +Describe ... diff --git a/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/UnitVnVPlan.pdf b/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/UnitVnVPlan.pdf new file mode 100644 index 00000000..02c9e65a Binary files /dev/null and b/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/UnitVnVPlan.pdf differ diff --git a/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/UnitVnVPlan.tex b/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/UnitVnVPlan.tex new file mode 100644 index 00000000..07c9f653 --- /dev/null +++ b/CaseStudies/gamephys/docs/VnVPlan/UnitVnVPlan/UnitVnVPlan.tex @@ -0,0 +1,242 @@ +\documentclass[12pt, titlepage]{article} + +\usepackage{booktabs} +\usepackage{tabularx} +\usepackage{hyperref} +\hypersetup{ + colorlinks, + citecolor=black, + filecolor=black, + linkcolor=red, + urlcolor=blue +} +\usepackage[round]{natbib} + +\input{../../Comments} + +\begin{document} + +\title{Project Title: Unit Verification and Validation Plan} +\author{Author Name} +\date{\today} + +\maketitle + +\pagenumbering{roman} + +\section{Revision History} + +\begin{tabularx}{\textwidth}{p{3cm}p{2cm}X} +\toprule {\bf Date} & {\bf Version} & {\bf Notes}\\ +\midrule +Date 1 & 1.0 & Notes\\ +Date 2 & 1.1 & Notes\\ +\bottomrule +\end{tabularx} + +~\newpage + +\section{Symbols, Abbreviations and Acronyms} + +\renewcommand{\arraystretch}{1.2} +\begin{tabular}{l l} + \toprule + \textbf{symbol} & \textbf{description}\\ + \midrule + T & Test\\ + \bottomrule +\end{tabular}\\ + +\wss{symbols, abbreviations or acronyms -- you can reference the SRS tables if needed} + +\newpage + +\tableofcontents + +\listoftables + +\listoffigures + +\newpage + +\pagenumbering{arabic} + +This document ... \wss{provide an introductory blurb and roadmap of the + unit V\&V plan} + +\section{General Information} + +\subsection{Purpose} + +\subsection{Scope} + +\subsection{Overview of Document} + +\section{Plan} + +\subsection{Software Description} + +\subsection{Test Team} + +\wss{Probably just you. :-)} + +\subsection{Automated Testing Approach} + +\subsection{Verification Tools} + +\wss{Thoughts on what tools to use, such as the following: unit testing + framework, valgrind, static analyzer, make, continuous integration, test + coverage tool, etc.} + +% \subsection{Testing Schedule} + +% See Gantt Chart at the following url ... + +\subsection{Non-Testing Based Verification} + +\wss{List any approaches like code inspection, code walkthrough, symbolic + execution etc. Enter not applicable if that is the case.} + +\section{System Test Description} + +\subsection{Tests for Functional Requirements} + +\subsubsection{Area of Testing1} + +\paragraph{Title for Test} + +\begin{enumerate} + +\item{test-id1\\} + +Type: Functional, Dynamic, Manual, Static etc. + +Initial State: + +Input: + +Output: + +How test will be performed: + +\item{test-id2\\} + +Type: Functional, Dynamic, Manual, Static etc. + +Initial State: + +Input: + +Output: + +How test will be performed: + +\end{enumerate} + +\subsubsection{Area of Testing2} + +... + +\subsection{Tests for Nonfunctional Requirements} + +\subsubsection{Area of Testing1} + +\paragraph{Title for Test} + +\begin{enumerate} + +\item{test-id1\\} + +Type: + +Initial State: + +Input/Condition: + +Output/Result: + +How test will be performed: + +\item{test-id2\\} + +Type: Functional, Dynamic, Manual, Static etc. + +Initial State: + +Input: + +Output: + +How test will be performed: + +\end{enumerate} + +\subsubsection{Area of Testing2} + +... + +\subsection{Traceability Between Test Cases and Requirements} + +% \section{Tests for Proof of Concept} + +% \subsection{Area of Testing1} + +% \paragraph{Title for Test} + +% \begin{enumerate} + +% \item{test-id1\\} + +% Type: Functional, Dynamic, Manual, Static etc. + +% Initial State: + +% Input: + +% Output: + +% How test will be performed: + +% \item{test-id2\\} + +% Type: Functional, Dynamic, Manual, Static etc. + +% Initial State: + +% Input: + +% Output: + +% How test will be performed: + +% \end{enumerate} + +% \subsection{Area of Testing2} + +% ... + +\section{Unit Testing Plan} + +\wss{Unit testing plans for internal functions and, if appropriate, output + files} + +\bibliographystyle{plainnat} + +\bibliography{SRS} + +\newpage + +\section{Appendix} + +This is where you can place additional information. + +\subsection{Symbolic Parameters} + +The definition of the test cases will call for SYMBOLIC\_CONSTANTS. +Their values are defined in this section for easy maintenance. + +\subsection{Usability Survey Questions?} + +This is a section that would be appropriate for some teams. + +\end{document} \ No newline at end of file