%
% @file        laramee07projectGuideline.tex,
%              laramee10projectGuideline.tex
% @author      Robert S Laramee
%
%  start date: 25 July 2007
%      update: 9 May 2011
%      update: 11 Jan 2013
%      update: 25 July 2013
%
\documentclass[onecolumn,11pt]{article}
\usepackage[]{graphicx}
\usepackage{times}
% \usepackage[square,numbers]{natbib} % for single spaced bibliography
\usepackage{setspace} % for controlling bibliography spacing 
\usepackage{parskip}
%\usepackage{url}
\usepackage{hyperref}
\usepackage[]{natbib} % for citation style


%
% add more space per page
\setlength{\topmargin}{-1.0cm}
\setlength{\textwidth}{16.0cm}
\setlength{\textheight}{22.5cm}
\setlength{\oddsidemargin}{-0.5cm}
\setlength{\evensidemargin}{-0.5cm}
\setlength{\columnsep}{0.5cm}
%
% Eliminates inter-reference spaces!!
\let\oldthebibliography=\thebibliography
  \let\endoldthebibliography=\endthebibliography
  \renewenvironment{thebibliography}[1]{%
    \begin{oldthebibliography}{#1}%
      \setlength{\parskip}{0ex}%
      \setlength{\itemsep}{0ex}%
  }%
  {%
    \end{oldthebibliography}%
  }
%
\begin{document}
%
% \tolerance=90     % page 451 of TeX user guide
%
%
% \titlerunning{}
\title{Bob's Project Guidelines: \\
      Writing a Dissertation for a BSc or MSc\\ in Computer Science }
\author
 {Robert S. Laramee \\
  \small Visual and Interactive Computing Group \\
  \small School of Computer Science \\
  \small University of Nottingham, UK \thanks{
  \url{http://www.cs.nott.ac.uk/blaramee/}, 
  robert.laramee ``at'' nottingham.ac.uk (\today{})
} % end thanks
}
\date{}
%
\maketitle
%
%
\begin{abstract}

\vspace*{-3mm}
%
These detailed guidelines attempt to explain the mechanics of writing a 
third year project dissertation in Computer Science.
They serve as a useful starting point for students (and new
advisors) in their third or fourth year of study in the Computer 
Science Department of a UK-based university.
Afterall, no one is born knowing how to write a dissertation.
Yet, there are certain elements, a commonality, that can be found in 
virtually all good dissertations. 
We give our recommendations as to each section a good dissertation
consists of as well as what each section contains.
These guidelines are generic and can be customized to fit most
projects.
The guidelines are open and free to use at any university or institution
without permission.

We believe that the writing can start with the abstract,
however, in practice writing usually starts with the background
section. 
The abstract can be approximately 6-12 sentences.
It's a difficult starting point, but it forces the author
to write down a concise description of what it is they are researching
and the associated benefits.
Chances are, if the author can't write an abstract, then it 
is not clear in the author's mind what the project is about.
Of course the abstract will be refined and updated over the lifetime
of the project.
The abstract can concisely 
(1)~identify the project topic,
(2)~identify the benefits and advantages that result
(3)~and if there is novelty, describe the novelty of the presented work.
If there's a description of the project in a previously existing
project selection brochure then that can be used as a basis for an 
abstract.\footnote{These guidelines are a starting point only and are not a
  substitute for an advisor.
They have been refereed and published in an education 
journal.~\cite{laramee:bobsProject}
We recommend citing these guidelines in your dissertation to support
and justify your organizational choices.}
%
\end{abstract}
%
\newpage
\tableofcontents
\newpage
%
\vspace*{-4mm}
% ------ PART 1 ------
\section{Introduction (Motivation)\\ 
      \scriptsize [included in the 
                   Initial Document, 
                   Interim Document (if updated), and 
                   Final Dissertation]\normalsize}
\label{sec:intro}
\vspace*{-4mm}
%

Although the title of the starting section is \emph{``Introduction''}
it should really be \emph{Motivation}.  
In one or two paragraphs, introduce the topic.
This is followed immediately with \emph{why} this is a useful
project, including possible applications of the work.
\emph{``What is this dissertation topic good for?''} is really 
the question a good introduction attempts to answer.

After the motivation behind the subject is described, the benefits,
advantages, and possibly novelty of the dissertation 
are presented.
This is actually where a project could start.
It starts with an idea, and one key to evaluating how good an idea is
being able to identify its benefits and possibly novelty. 
Each benefit that reading this dissertation provides is 
identified very explicitly in a bulleted list.  
Possible points to mention include:
%
\begin{itemize}
%
\item \vspace*{-1mm}
      Does the presented work provide a software tool of some sort? 
%
\item \vspace*{-2mm}
      Does the presented system provide interactive features?
%
\item \vspace*{-2mm}
      Who will potentially benefit from the work?
%
\item \vspace*{-2mm}
      Does the tool or system provide new insight in some way?
%
\item \vspace*{-2mm}
     What does the reader potentially gain from reading this dissertation?
%
\end{itemize}
%
Words like, \emph{contribute}, \emph{benefit}, \emph{advantageous}, 
and possibly \emph{novel} are used in this list. 
An explicit bulleted list is used in order to make the subject black
and white to the reader. 
Otherwise, a reader might not understand the dissertation.
The \emph{goal} of the project has to be carefully considered in this context.
Describe the goal of the project here.

The presented work often builds on a previous system or algorithm.  
If so, your work may inherit benefits from the previous work.
Those inherited advantages may also be listed.

In order to achieve the amazing benefits your project has to offer,
specific challenges must be overcome, both conceptual and technical.
Those challenges can be mentioned here. 

The introduction section then concludes with how the rest of the 
dissertation is organized.
Section~\ref{sec:background} presents previous work on this topic.
Section~\ref{sec:specification} presents the project specifications
followed by the project plan in Section~\ref{sec:plan}.
Section~\ref{sec:design} presents the project design.
The Interim document is describe in Section~\ref{sec:interim}.
Section~\ref{sec:implementation} presents our system or method starting with 
an overview.
Section~\ref{sec:evaluation} presents an evaluation of our results both from
a performance point of view and memory point of view.
Section~\ref{sec:conclusion} completes the exposition with conclusions
and future work (Section~\ref{sec:future}).

\vspace*{-3mm}
% --------- FORMATTING ---------
\subsection{Formatting:}
\vspace*{-3mm}
%
The format of the dissertation can be very similar to this document:
11 or 12 point times (or similar) font, single column.
\emph{Excessive white space is to be avoided.}
Some authors try to pad their dissertation with a lot of unnecessary white 
space.
Sometimes there are blank pages, or pages that are only half occupied with 
content.
This is a waste. 
Don't start every new section or subsection on a new page in order to
make the documentation appear longer.
The goal of a dissertation is not to produce the thickest document possible,
but rather to focus on good quality.
If it looks like too much padding has been used, this may even reduce
the final score of dissertation.

%
\vspace*{-3mm}
% --------- ON LATEX...---------
\subsection{On \LaTeX:}
\vspace*{-3mm}
%

The best software for writing papers, dissertations, theses, and books 
is \LaTeX.
\LaTeX{} produces the highest quality, most professional-looking output.
See Kopka and Daly for an excellent \LaTeX{} reference 
guide~\cite{kopka:guide}.
This is one reason why virtually all conferences and journals provide
\LaTeX{} templates for paper submissions.
You can use the \LaTeX{} source from this guideline document if you
think it would help.  
Simply contact the author.
Also, \texttt{http://www.latex-project.org/} is a great online-guide
to \LaTeX{}.

\vspace*{-3mm}
% --------- Project Titles ...---------
\subsection{Project Titles:}
\vspace*{-3mm}
%
Regardless of the title of your dissertation, it will only be referred to using
two to three words.  For example, 
\emph{``Marching Cubes: A High Resolution 3D Surface Construction Algorithm''}
 is referred to simply as`
\emph{``The Marching Cubes''} paper~\cite{lorensen:marching}.
\emph{``Visual Analysis and Exploration of Fluid Flow in a Cooling Jacket''}
is referred to as
\emph{``The Cooling Jacket''} paper~\cite{laramee:visualAnalysis}.
On one hand the title of your project is ideally simple enough such 
that it can easily be remembered and referred to with two or three words.
On the other hand, a title is also long enough in order to convey some
sort of meaning and description to the reader.
This problem can usually be resolved using a {\bf title:subtitle} combination,
like in the case of Marching Cubes~\cite{lorensen:marching} (no pun intended).

%
\vspace*{-4mm}
% ------ BACKGROUND ------
\section{Background \\
      \scriptsize [included in the Initial Document, 
                   Interim Document (if updated), and 
                   Final Dissertation]\normalsize}
\label{sec:background}
\vspace*{-4mm}
%
This section describes the research the author has done in order to
prepare for the project.
The background section can be broken down into two sub-sections:
(1)~related work and
(2)~previous systems.

%
\vspace*{-4mm}
% ------ RELATED WORK ------
\subsection{Related Work}
\label{sec:related}
\vspace*{-3mm}
%

The related work section demonstrates to the reader that you have done 
your homework (research),
reviewed the previous literature, and now are ready to present your
contribution based on what has been previously published.

One of the difficult aspects of the related work section is choosing the
proper scope.
There is some subjectivity in choosing which
books or papers to refer to and also importantly, which previous 
literature not to refer to.
This is something an advisor is able to help with.
In short, each previous publication gets a one paragraph description.

We note that there is literature related to these 
guidelines~\cite{laramee:howToWrite-,laramee:howToWrite}.

%
\vspace*{-4mm}
% ------------ CITATIONS ------
\subsection{Citations}
\vspace*{-4mm}
%

Any figure, image, equation, number, or year that is taken from another 
source must be cited.
Content and terminology from other sources must also be cited.
For more information about citations and their use, see: \\
\texttt{http://www.plagiarism.org/}.  Click on the
``How to cite sources'' link.

When referring to previous work use names, not only numbers.
So, instead of writing, 
``In~\cite{jobard:creating}, an algorithm for the
creating of evenly-spaced streamlines is presented.'',
write, ``Jobard and Lefer present an algorithm for creating evenly-spaced
streamlines~\cite{jobard:creating}.''
The names are much more helpful to the reader than the numbers alone.
Also, the previous literature was written by real people.
Writing the names also shows a certain respect and appreciation for the
previous work that numbers alone do not.

References should be accurate and complete, i.e., with page numbers etc.
A paper without complete and correct references can leave a bad impression 
on the reader and detract from a dissertation or paper's credibility.
Errors can be interpreted as sloppy and can also be a sign of hastiness.

%
\vspace*{-4mm}
% --------- PREVIOUS SYSTEMS ------
\subsection{Previous Systems (or Similar Applications)}
\label{sec:previousSystems}
\vspace*{-3mm}
%

If you are building a piece of software, i.e., an application, then there's a
good chance that other closely-related applications already exist.
This section describes those applications.
For each previous system the following information is given:
%
\begin{enumerate}
%
\item the name of the system or application,
\item \vspace*{-2mm}
      the URL of the system,
\item \vspace*{-2mm}
      a screen shot of the application, and
%
\item \vspace*{-2mm}
      which platforms the application runs on,
%
\item \vspace*{-2mm}
      the duration time of the trial license, e.g., 30 days
%
%
\item \vspace*{-2mm}
      a one or two paragraph description of the application 
      including: 
%
\begin{itemize}
  \item 
        \emph{why} the application was written and 
  \item \vspace*{-2mm}
        \emph{for whom} (target users) it was written.
\end{itemize}
%
\end{enumerate}
%
Note that each screen shot is accompanied by a caption, including
a citation to the source of that screen shot, e.g., where the 
software comes from (
including company name,
web page author,
web page title,
URL, and last
access date, etc).
Some examples are given in the references section of this
document.

%
\vspace*{-4mm}
% --------- 
\subsection{Data Characteristics}
\label{sec:data}
\vspace*{-3mm}
%

If your project processes a specific or important data set(s), then a
description of that data is important.
Some very helpful questions to answer are:
Where does the data come from?
Who produced the data?
Why was the data collected in the first place?
In other words, what are the fundamental questions (or knowledge)
that we are trying to answer with the data?

A technical description of the data is also very helpful.
What is the size (or resolution) of the data set?  
For example, how many samples does it contain?
What is the range (minimum and maximum values) of the data samples?
What are the characteristics of the data?  Is it time-dependent?
Is it abstract data or scientific data?
Data is called ``scientific'' if every data sample has a given
position in space, i.e., ($x$,$y$,$z$) coordinates.
Abstract data has no position associated with its data samples,
e.g., financial data describing stock transactions such as
buying or selling.
How big is the file that stores the data?
What format is the data file in?
Provide a complete description of the data file format.

%
\vspace*{-4mm}
% ------ PROJECT SPECIFICATION ------
\section{Project Specification \\
      \scriptsize [included in the Initial Document, Interim Document, and 
                   Final Dissertation] \normalsize}
\label{sec:specification}
\vspace*{-3mm}
%

The Project Specification Section is broken down into two
sub-sections: the feature specification and technology choices.

%
\vspace*{-4mm}
% --------- FEATURE SPECIFICATION ------
\subsection{Feature Specification}
\label{sec:feature}
\vspace*{-3mm}
%

Recall the five stages of software development:
(1)~requirements specification,
(2)~software design,
(3)~implementation, 
(4)~testing, and
(5)~documentation, for both programmers and users.

This section is all about stage one--documenting the requirement
specification.
The requirement specification describes the functionality of your system.
What features is the software to have?
What will it be capable of doing?
The feature set is divided into two categories:
(1)~must-have features and
(2)~optional features.
Must-have features are the minimum set of requirements the system must
have in order to be useful whereas optional features are those that bring 
the level of the application up to outstanding quality.
\emph{Each feature in both the must-have and optional features sub-sections
is presented in a numbered (enumerated) list.}

%
\vspace*{-4mm}
% --------- TECHNOLOGY CHOICES ------
\subsection{Technology Choices}
\label{sec:technology}
\vspace*{-3mm}
%

This section outlines which tools and options are available for your
implementation.
Three basic decisions usually have to be made:
%
\begin{itemize}
%
 \item Which programming language to use.
%
 \item \vspace*{-2mm}
    Which GUI library to use.
    Some possible choices are
  \begin{enumerate} 
    \item The Java Swing Library (free, cross-platform), 
    \item The Fox Toolkit (free, open-source, cross-platform)~\cite{zijp:fox}, 
    \item QT (cross-platform, both commercial and free, open-source
              editions available)~\cite{blanchette:c++,trolltech:qt}, 
    \item FLTK (free)~\cite{spitzak:fltk},
    \item GLUI (free)~\cite{rademacher:glui}, 
    \item wxWidgets (free, cross-platform)~\cite{smart:wxwidgets},
    \item wxWinows (free, cross-platform)~\cite{neifer:looking},
    \item GTK+ (open source, cross-platform)~\cite{gtk:gtk}
    etc.
  \end{enumerate}

    One of these GUI libraries is suitable for your
    application for sure.
    There's a very nice description of how to use the wxWindows
    library in chapter 18 of Horstmann~\cite{horstmann:computing}.
    (The wxWidgets library is formally known as wxWindows.)
%
 \item \vspace*{-2mm}
    Which other (if any) libraries are used, e.g., OpenGL, DirectX, etc.
%
\end{itemize}

After describing the possible options, \emph{why} you have chosen those
options is given.
The best tools are: (1)~open source, (2)~cross-platform, and (3)~provide a
forum in which to ask questions, e.g., a mailing list.
It's nice if the description of technology choices includes a screen
shot of each GUI option.

%
\vspace*{-4mm}
% ------ PROJECT PLAN... ------
\section{Project Plan and Timetable \\
      \scriptsize [included in the Initial Document, 
                   updated in the Interim Document, and 
                   Final Dissertation] \normalsize}
\label{sec:plan}
\vspace*{-3mm}
%

This section describes your project plan.  
The project is broken down into smaller tasks (divide-and-conquer)
and these interim milestones are written down into a table.
There may already be a series of deadlines outlined in your
course handbook or project syllabus that can be included in 
the table:
%
\begin{enumerate}
%
\item initial project document deadline: Semester 1 Week 3,
%
\item \vspace*{-2mm} presentation deadline: Semester 1, late November,
%
\item \vspace*{-2mm} project review just before the Christmas holiday,
%
\item \vspace*{-2mm} interim document deadline: Semester 2 Week 2, and
%
\item \vspace*{-2mm}
  demonstration and viva deadline: Semester 2, Week 10.
%
\end{enumerate}
%

These are the absolute minimum milestones.
Then, each feature described in the Feature Specification Section
(Section~\ref{sec:feature}) is included in the table. 
See Table~\ref{tab:timeline} for an example.
The table describing the project plan and timeline can have
three columns.  
In the first column is a number, in the second column is a
description of the feature to be implemented and in the third
column is a date by which the feature is to be implemented.

\begin{table}[h]
\begin{tabular}[]{c|l|c|}
%
\multicolumn{3}{c}{{\bf Sample Project Timetable}} \\
           & {\bf Description} & {\bf Date} \\
\hline
%
1.      & Initial project  presentation (Gregynog)             & 19 Nov  07  \\
2.      & File Opener: User opens data file via the File menu  & 1  Dec  07  \\
3.      & User is able to view a 2D graph of time (x-axis) vs amplitude (y
axis). & 8  Dec  07  \\
4.      &  project review just before the Christmas holiday,   & 15 Dec  07
\\
5.      &  etc...   & 15 Jan  08  \\
%
\end{tabular}
%
\caption{\small
         A sample table with interim deadlines in this project.
         The timeline is broken down week-by-week.
         For each week there is some measure of progress.}
%
\label{tab:timeline}
\end{table}

Construction of Table~\ref{tab:timeline} is easy.
Simply cut and paste each feature listed in the Feature Specification
Section (Section~\ref{sec:feature}) and place it under the \emph{description}
column in the table.
Then add a completion date.
Features that are too big to be completed in one week can be broken down
into smaller pieces (sub-features).  Sub-features can be accomplished 
within one to two weeks.

%
\vspace*{-4mm}
\subsection{Time Management}
\vspace*{-3mm}

We recommend working on your 3rd year project for approximately ten
hours per week during your third year.
The project is worth 40 credits, or 30\% of your third year
(at Swansea University).
Also, the marks from your third year carry twice the weight as
the marks from your second year.
Thus the project can be thought of counting for \emph{60 credits} towards
your final degree.


%
\vspace*{-4mm}
% --------- AN ASIDE ON PROOFREADING.---------
\subsection{An Aside on Proofreading}
\vspace*{-3mm}
%

In the ideal world, the dissertation is proof read by someone outside 
the project before submission to look for typographical errors.  
Fresh new eyes that don't necessarily know the topic can be good for 
spotting these things, at least in our experience.

%
\vspace*{-4mm}
% ------ THE INTERIM DOCUMENT ------
\section{The Interim Document}
\label{sec:interim}

The interim document, due the third Monday of semester two, summarizes the 
project's progress up to that point in time.
\emph{The goal of the interim document is to provide the reader a
summary of progress since the initial document.}
Conceptually, the interim document is an extension of your initial
document. 
However, if you submit something that looks too much like your
initial document, you will \textit{not} earn the 25\% (formerly 30\%)
of the credit that this
portion of your project is worth.
Therefore, a table is included in your interim document
stating exactly how it is different from your initial document.
Table~\ref{tab:interim} shows an example.

\begin{table}[h]
\begin{tabular}[]{l|l|l|}
%
\multicolumn{3}{c}{{\bf Summary of Interim Document}} \\
           & {\bf Section} & {\bf Status} \\
\hline
%
1.      & Introduction          & This section has been updated with corrections since initial document. \\
2.      & Background             & This section has been updated and expanded
(since the initial document). \\
2.1     & Related Work           & This section was updated and expanded to include new literature.\\
2.2     & Previous Systems       & More previous systems were added. \\
3.      & Project Specification  & This section has been updated and expanded with more detail. \\
4.      & Project Design         & This is a new section (not featured in
initial document). \\
5.      & Project Implementation & This is another new section.  \\
6.      & \ldots                 & \ldots  \\
%
\end{tabular}
%
\caption{\small
         A sample summary of the interim document indicating what has
         been done since the initial document was submitted.}
%
\label{tab:interim}
\end{table}

Your table includes every section and subsection of your dissertation
that has changed, been updated, or introduced (new sections and sub-sections)
since the initial document.
If a section has not changed, such as the Introduction, it is not
included in the interim document.
You may use the minutes of meeting notes as a history of the project
because they document progress that has been made since the initial 
document~\cite{laramee:minutes}.

The table of contents in this document indicates which sections
are included in the initial document, interim document, and final
dissertation. 
This is to be used as a very general guideline and can be customized
to fit most projects. 
Also read the description of the interim document in your
Computer Science Department's Course Handbook.

The interim document also requires an updated time table.
The time table shows your temporal plan for the remainder
of the project.
See Section~\ref{sec:plan} for a sample time table.

%
\vspace*{-4mm}
% ------ PROJECT DESIGN ------
\section{Project Design \\
      \scriptsize [included in the Interim Document, and 
                   Final Dissertation] \normalsize}
\label{sec:design}
\vspace*{-3mm}
%

This section corresponds to the second stage of the software development
process~\cite{sommerville:software}: software design. 
Your design is most likely object-oriented.
The design starts with a list of classes and their responsibilities.
This is a very important starting point (the list of classes and 
descriptions).
It forces the programmer to start thinking about implementation.
After identifying a list of candidate classes and writing a short
description of each of them, e.g., 3--4 sentences,
the list is reviewed with the project supervisor before
proceeding onwards with the description of relationships between them.

\vspace*{-3mm}
% --------- DESIGN DIAGRAMS ---------
\subsection{Design Diagrams}
\label{sec:designDiagram}
\vspace*{-3mm}

The design also depicts the relationships between the classes
through class hierarchies and collaboration diagrams.
See also Laramee et al.~\cite{laramee:design} for some examples of this.

%
\begin{figure}[t]
\begin{center}
  \rotatebox{0}{
    \resizebox{90mm}{!}{
     \includegraphics[draft=false]{fig/system}
    }
  }
\end{center}
 \caption{This figure shows an example of a process diagram.
          For example, the CFD process is iterative and can be pipelined
          into modeling, simulation, and
          visualization stages. 
          Rounded boxes represent input/output
          data while processing stages are depicted as rectangles.
          All of the figures in this section were made with a program
          called \emph{Xfig} (http://www.xfig.org).
          \textit{Inkscape} 
          (http://www.inkscape.org)
          is another free and popular program for
          creating nice diagrams.
        }
  \label{fig:process}
\end{figure}%
%

Some types of diagrams that can be included in your design are
described here.
(1)~{\bf Process diagrams} that show different stages of processing along
 with input and output data in between stages (Figure~\ref{fig:process}).


\begin{figure*}[t]
\begin{center}
  \rotatebox{0}{
    \resizebox{90mm}{!}{
     \includegraphics[draft=false]{fig/visSystem}
    }
  }
\end{center}
 \caption{This is an example of a software system showing some
          of its subsystems.
          This example shows a schematic of the design for a visualization
          system.
          Only the major subsystems are illustrated.
        }
  \label{fig:system}
\end{figure*}%

(2)~{\bf System diagrams} that identify different sub-systems in your 
   software design
   and the relationship between them (Figure~\ref{fig:system}).
In modern, object-oriented software development, more
time is spent on software design~\cite{wirfs:designing} in
order to make software more robust, increase code re-use,
facilitate maintenance, and make it easier to extend.
The design of software is based on object-oriented
methodology.

The design of your system can use the notation of
Wirfs-Brock et al.~\cite{wirfs:designing}.
An example is shown in Figure~\ref{fig:system}.
A semicircle with an arrow pointing to it represents a contract.
A contract is a subsystem or class interface with other classes
or subsystems.
It represents the set of services that a subsystem or class
provides.
Figure~\ref{fig:system} illustrates the different subsystems
and the relationships they have with one another.

%
\begin{figure}[t]
 \begin{center}
  \rotatebox{0}{
    \resizebox{70mm}{!}{
     \includegraphics[draft=false]{fig/streamLineDesign}
    }
  }
 \end{center}
  \caption{This is an example of a class hierarchy diagram.
           This example is from a class hierarchy of streamline and geometric
           flow visualization options.
           UML notation is used.
        }
  \label{fig:classHierarchy}
\end{figure}%

%

(3)~{\bf Class hierarchy} diagrams are also very useful 
(Figure~\ref{fig:classHierarchy}).
Figure~\ref{fig:classHierarchy} shows different streamline
 rendering options displayed in the class hierarchy in which
 they were designed and implemented.
 The hierarchy, following UML notation~\cite{fowler:uml},
 illustrates the \emph{is-kind-of} relationship between 
 classes.
 At the top of the hierarchy we have an abstract base,
 {\bf Streamline Renderer} that describes the behavior
 and contains the interface that all streamline rendering
 objects implement.

%
\begin{figure}[t]
\begin{center}
  \rotatebox{0}{
    \resizebox{70mm}{!}{
     \includegraphics[draft=false]{fig/TBFVdesign}
    }
  }
\end{center}
%
 \caption{This is an example of a composition diagram. 
          For example, the major components of the texture-based
          flow visualization design.
          Here aggregation, or \emph{is-part-of}, relationships
          are shown.
        }
  \label{fig:composition}
\end{figure}%
%

(4)~{\bf Composition diagrams} are also very useful 
(Figure~\ref{fig:composition}). 
Figure~\ref{fig:composition} shows the class relationship between
the major components of a texture-based flow visualization
subsystem, again using UML notation.
However, rather than showing is-kind-of relationships as
in Figure~\ref{fig:classHierarchy} we show \emph{composition},
a variety of aggregation (is-part-of relationship).
With composition, the part object (sub-component) may belong to 
only one whole.
Furthermore, the parts are usually expected to live and die with
the whole~\cite{fowler:uml}.
For example, the {\bf Texture Stack} object is part of the
{\bf Texture-Based Flow Visualizer} object and the relationship
is one-to-one.
Furthermore, an instance of {\bf Texture Stack} may be in
an instance of {\bf Texture-Based Flow Visualizer} but not
the other way around.
This is indicated by the black diamond shape arrow.

\vspace*{-3mm}
% --------- FIGURES.AND IMAGES ---------
\subsection{Figures and Images}
\label{sec:figure}
\vspace*{-3mm}
%

Diagrams may be created with free drawing packages called
\textit{Inkscape} (\url{http://www.inkscape.org})
or \textit{Xfig} (\url{http://www.xfig.org}).
Figures, images and their captions are ``self-contained''.
By self-contained, we mean that the reader is able to look
at any figure or image, read its caption, and gain a basic understanding
\emph{without} having to read the main text.
Enough details are provided in the caption such that the
reader is not required to read the whole paper in order
to understand an image or figure.
Many readers will make a first pass through a document
simply by flipping through the pages, looking at the images and
captions, and already gain an impression.
This first pass may already influence the reader's opinion.
If the reader appreciates the images and can gain an understanding
of them from the captions, they may form a favorable first impression.

When a potential reader picks up any reading material, whether it be a 
newspaper, magazine, or book, they first flip through it to look
at the pictures.  
If they find an interesting picture, they read the caption.  
If they find interesting pictures and captions, they may then go on
to read the main text.

Pedagogic figures are good to include in your dissertation. 
The author will make their job easier if he makes all images, e.g.,
screen shots or frame buffer images, the same resolution, perhaps through
a user setting.
Also, a user setting that changes the background color to white is very
useful.
Images with a white background are best for papers in our opinion.
We refer the reader to Tufte~\cite{tufte:visual} for further stylistic
guidelines.

\vspace*{-4mm}
% ------ IMPLEMENTATION ------
\section{Implementation \\
      \scriptsize [started in the Interim Document and completed
                   in the Final Dissertation] \normalsize}
\label{sec:implementation}
\vspace*{-3mm}


Section~\ref{sec:implementation} is the main content of the dissertation
and thus occupies the most space. 
It is broken down into two sub-sections: the must-have features
and optional enhancements.

%
\vspace*{-4mm}
% --------- BASIC... ------
\subsection{Basic Implementation (Must-Have Features)}
\label{sec:basic}
\vspace*{-3mm}
%
This section describes the must-have features implemented from the 
specification (Section~\ref{sec:specification}) and how they were 
implemented. 
The implementation is based on your model from Section~\ref{sec:design}.
The name of Section 3 could be the name of your system or 
algorithm (if it has a name, e.g. Image Space Advection 
(ISA)~\cite{laramee:isa}).
Section~\ref{sec:implementation} 
can also be called simply \emph{Implementation}.

Section~\ref{sec:implementation} contains screen-shots of your
application as well as accompanying descriptions.
Some important questions to be addressed in this section are:
%
\begin{enumerate}
%
\item What are the different features and options your program offers?
%
\item \vspace*{-2mm}
  How does the application work?
%
\item \vspace*{-2mm}
  What data structures are used in the implementation?
%
\item \vspace*{-2mm}
  Were there any features that were particularly difficult to implement? Why?
%
\end{enumerate}
%
The reader then knows how your system (or algorithm) operates after reading
this section.  
The reader is given enough detail such that they can operate or implement the
system themselves.

%
\vspace*{-4mm}
% --------- ENHANCEMENTS ------
\subsection{Enhancements (or Extentions)}
\label{sec:enhancements}
\vspace*{-3mm}
%

After the must-have features of your system are presented
in Section~\ref{sec:implementation} a follow-up Section may be added
that includes enhancements or extentions to the must-have features.
This section presents the optional features that were first specified
in Section~\ref{sec:specification}.
The must-have features describe the features that are necessary in order
to get a passing note for your project.
The extensions describe the features that are necessary in
order to obtain a first (distinction) on the project.

\vspace*{-4mm}
% --------- COMMENTING ------
\subsection{Commenting Your Code}
\label{sec:comments}
\vspace*{-3mm}
%

The source code of your project is documented according to the guidelines
set forth in a separate document~\cite{laramee:bobs}, a copy
of which the reader asks for at the start of the implementation
phase.
For projects written in Java, \emph{javadoc} can be used to comment
the source code:\\
{\tt \small http://java.sun.com/j2se/javadoc}\\
For projects written in just about any language, e.g., C++, Java, etc
\emph{doxygen}: \\
{\tt \small http://www.doxygen.org} \\
may be used to comment the source code.
Doxygen or javadoc is then used to produce HTML output of your
code comments.
Doxygen provides the added benefit of automatically generated
diagrams~\cite{laramee:doxygen}.
This HTML output will be inspected by the project supervisor
and whoever else may assess the project.

\vspace*{-4mm}
% --------- CODING CONVENTIONS ------
\subsection{Coding Conventions}
\label{sec:code}
\vspace*{-3mm}
%

The source code of your project also follows the code commenting standards
outlined in a separate document~\cite{laramee:bobs}, a copy of
which the reader asks for at the start of the implementation.
Following these coding conventions yields several important benefits
including, but not limited to:
(1)~higher code legibility,
(2)~fewer bugs,
(3)~higher code quality, and
(4)~ultimately a better project.
The source code of your project will actually be inspected to see if
it conforms with the conventions.
In the end, following these coding conventions raises the final score
of your project.

%
\vspace*{-4mm}
% ------ TESTING AND EVALUATION ------
\section{Testing and Evaluation \\
      \scriptsize [included in the Final Dissertation] \normalsize}
\label{sec:evaluation}
\vspace*{-3mm} 
%

Evaluation is a very important part of your project (or any project).
A very important question to ask right from the beginning is,
\emph{``How is this project going to be evaluated?''}
Some important topics discussed in the evaluation are:
%
\begin{itemize}
%
 \item \vspace*{-1mm}
   \emph{Testing}: How is your software going to be tested?
                   What are the different test cases?
                   What sources of data will be used to test your system?
%
 \item \vspace*{-1mm}
   \emph{Performance:} How well does your application perform?
                       How fast (or slow) is your application?
                       How memory efficient (or inefficient) is your
                       algorithm or system?
%
\end{itemize}

%
\vspace*{-4mm}
\subsection{Results}
\vspace*{-4mm}
%
In this section, the nicest images of your system or algorithm are presented.
Your system is applied to interesting data sets and the insight 
provided is described in addition to a concise description of the data 
sets.
The characteristics of the test data sets is given.
Some possible things to describe are:
%
\begin{enumerate}
%
\item \vspace*{-1mm}
      Where did the data (what domain) come from?
%
\item \vspace*{-2mm}
      How large the are the data sets? What is their resolution in the case of 
      structured data?
%
\item \vspace*{-2mm}
      What are the spatial and temporal dimensionalities of the data?
%
\item \vspace*{-2mm}
      Is the data structured or unstructured?
%
\item \vspace*{-2mm}
      It the data multiresolution or adaptive resolution?
%
\end{enumerate}

Hopefully, you'll be able to show your algorithm being applied to
data sets from another domain, e.g., the visualization of simulation data,
in order to demonstrate that your software actually works. 

%
\vspace*{-4mm}
\subsection{Performance Analysis}
\vspace*{-4mm}
%
In most areas of computer science like visualization and computer graphics
there's always a trade-off between
quality and speed (or memory and speed).
Generally, the faster the performance, the lower the quality or
the higher the memory requirements.
The algorithm or system being presented likely has some free parameters that
can be adjusted to trade off quality for speed and vice-versa
or to trade off memory for performance and vice-versa.
Essentially, \emph{every} parameter whose value you are not sure of should be a
user-defined parameter--an option that can actually be changed by the user at
run time (not just compile time).

A table of performance times can report both aspects, optimized for speed,
i.e., exploration mode, and optimized for quality, i.e., presentation mode.
The best and most honest reports of performance times will show when the
algorithm or system reaches its limits, e.g., when it starts to run slow
due to perhaps large data sets.
Algorithms also usually trade off memory for speed.
In other words, faster algorithms often require more memory, basically
because more calculations are pre-processed and stored.

If your project is on the subject of visualization, remember, visualization 
is used for analysis, exploration, and presentation.
For presentation, the image quality must be at its highest, and thus
performance probably at its slowest.
The highest quality is used to generate the images for the paper,
presentation, and videos.
For exploration, the algorithms and systems are tuned for the fastest 
performance times possible.
All optional enhancements may be turned off (unless your algorithm always
runs at interactive frame rates).

See Laramee and Bergeron~\cite{laramee:isosurface} and
Laramee et al.~\cite{laramee:image,laramee:isa} for good examples
of detailed performance analysis that trades off between performance and 
quality or memory and speed.

\vspace*{-4mm}
% ------ CONCLUSIONS ------
\section{Conclusions 
      \scriptsize [included in the Final Dissertation] \normalsize}
\label{sec:conclusion}
\vspace*{-3mm}
%

The Conclusions Section just summarizes the 
presented work and lists the resulting advantages.
Remind the reader why the presented work is so good and what's
new.
Basically, it's like a concise, one page summary of the
abstract and introduction sections.

\vspace*{-4mm}
% ------ FUTURE WORK ------
\section{Future Work 
      \scriptsize [included in the Final Dissertation] \normalsize}
\label{sec:future}
\vspace*{-3mm}
%

The future work section is about possible extentions to the
presented work.

%
\vspace*{-4mm}
% ------ TURNING IN SOURCE CODE ------
\section{Turning in Source Code
\scriptsize[included in Final Dissertation]\normalsize
}
\vspace*{-3mm}

We recommend turning in your source code electronically when submitting
your interim and final documents.
Your source code can be simply placed online, on your local
computer science web server.  
As an example, instructions on how to do this at Swansea University 
are given on the CS\_235 (Software Engineering)
web page: \\
\url{http://cs.swan.ac.uk/~csbob/teaching/cs235-softEng/}

All undergraduates have accounts created when they start at 
University. They may have access to their own web space on
request.  Requests are sent to the computer science technicians:
\texttt{cosit ``at'' swansea.ac.uk}.
Within their home directories they have a folder called
\texttt{public\_html}.

Any files/web pages they place there are available on the web and 
can be accessed from: \\
\url{http://cos-ugrad.swansea.ac.uk/username}

where \texttt{$\tilde{~}$username} is the student's username 
e.g. \texttt{123456}

To create a directory inside your public\_html folder you can
use these commands:

\begin{verbatim}
%> cd public_html
%> mkdir myNewFolder
\end{verbatim}

Where "myNewFolder" is the name of the folder you would like
to create.  To copy a file into your public\_html folder you can 
use the command:

\begin{verbatim}
%> cp file.txt public_html
\end{verbatim}

Where "file.txt" is the name of a file you'd like to copy into 
your public\_html directory.

Don't forget to make files readable to everyone, e.g.,

\begin{verbatim}
%> chmod -R ugo+r *
\end{verbatim}

Also, don't forget to make any directories you create executable
by everyone, e.g., 

\begin{verbatim}
%> chmod ugo+x myNewFolder
\end{verbatim}

There's a program called WinSCP (google "WinSCP") that enables you 
to transfer files to/from the CS web server from a Windoze machine.  
No instructions are provided on how to do that here.  We only provide
support for the use of the Linux machines.  You are welcome to contact 
the CS technicians with questions (cosit "at" swansea.ac.uk) concerning
the use of any Windoze software.

The best possible thing a student can do is to place the doxygen
HTML output onto their web server
space~\cite{laramee:doxygen,laramee:bobs}. 
Don't forget to include the link to your source code in your
documentation.
See 
Sections~\ref{sec:comments} 
and~\ref{sec:code} 
for more on this topic.

Some students turn in an electronic copy of their source code
and application on CD at the end of their project.
We do not recommend printing out your source code at any point
since it wastes too much paper.  
Plus there's no guarantee that anyone will look at it.

\vspace*{-4mm}
% ------ ACKNOWLEDGEMENTS ------
\section{Acknowledgements 
      \scriptsize [included in the Final Dissertation] \normalsize}
\label{sec:ack}
\vspace*{-3mm}

This section mentions any people that may have contributed
in some way, e.g., with the implementation or with discussions or feedback.
It is tradition to mention your advisor here at minimum.
The Acknowledgements Section also thanks any agency or 
organization that may have contributed funding to the presented 
research, e.g., the EPSRC, KPlus, the NIH, the NSF, etc.
An example of a long and complicated acknowledgements section
can be found in previous work~\cite{laramee:phd}.

Thanks to Daniel O'Sullivan and Nicholas Hammett for providing the impetus 
behind these guidelines.
These guidelines are the result of approximately four years of third-year
project supervision in the Computer Science Department at Swansea
University.
We thank the following project students for their valuable discussions
and input:
Essam Farrag, 
Nicholas Hammett, 
Marc Harry, 
Daniel O'Sullivan.
Matt Reid, 
James Walker, and 
Ho Yuen Wan. 
We especially thank
Kingsley Hau and
Ferdinand Vesely, 
for their careful proof-reading.

Questions, comments, suggestions for improvement, contributions to
these guidelines, or any other feedback is not only welcome but encouraged.
If your department or organization uses these guidelines, we'd like to
hear about it.  
Please contact Robert S. Laramee.

\vspace*{-4mm}
% ------ APPENDIX ------
\section{Appendix--BCS Accreditation 
%      \scriptsize [included in the Final Dissertation] \normalsize
}
\label{sec:appendix}
\vspace*{-3mm}

The following text is taken from from the Computer Science Departmental
Handbook at Swansea University.

\textbf{Project Requirements}

The following requirements for projects to be acceptable for BCS Accreditation
is extracted 
from information supplied by the BCS. If you have any doubts as to whether
your project 
meets the requirements please discuss it with your supervisor.
For projects to meet the requirements for exemption, they must be passed at
the first attempt 
to gain the award, with no condonement and no referral.
All projects must involve a professional approach. The project should be
“real” in the sense 
that the product is for users other than the author. The report should
demonstrate an appropriate 
level of professional competence in the practical development of a suitable
application, tool or 
similar product. The report on the project should include:
\begin{itemize}
  \item  \vspace*{-2mm}
    elucidation of the problem and the objectives of the project;     
  \item  \vspace*{-2mm}
    an in-depth investigation of the context / literature / other similar
    products; 
  \item  \vspace*{-2mm}
     a clear description of the stages of the life cycle undertaken;
  \item  \vspace*{-2mm} 
    a description of the use of appropriate tools to support the development
    process; 
  \item  \vspace*{-2mm} 
    a description of how verification and validation were applied at all
    stages;   
  \item  \vspace*{-2mm}
     a critical appraisal of the project, indicating the rationale for design
     / implementation 
     decisions, lessons learnt during the course of the project, and
     evaluation (with hindsight) 
     of the product and the process of its production (including a review of
     the plan and any 
     deviation from it);    
  \item \vspace*{-2mm}
    in the case of group projects, a clear indication of the part played by
    the author in 
     achieving the goals of the project;
  \item  \vspace*{-2mm}
    references;
  \item  \vspace*{-2mm}
    appendices — technical documentation.
\end{itemize}

The specific criteria applicable to projects acceptable for full exemption
from the BCS 
Professional Examinations is that:
\begin{itemize}
  \item  \vspace*{-2mm}   it involves at least 150 hours of individual student effort;
  \item  \vspace*{-2mm}   
    the task should be to develop an IT solution to a practical problem, which
    would include 
    the production of a piece of software (which may be interpreted as some or
    all of a 
    specification, design or implementation of software);
  \item  \vspace*{-2mm}
    it exhibits a structured approach to information systems practice,
    involving a number of 
    stages in the life cycle;
  \item  \vspace*{-2mm}
    the product exhibits the attributes of quality, reliability, timeliness
    and maintainability; 
  \item  \vspace*{-2mm}
    it must involve the production of a professional report as described above;
  \item  \vspace*{-2mm}
    it must lead to a description of the process and of the product;
  \item  \vspace*{-2mm}
    it must contribute significantly to the overall award classification.
\end{itemize}

%
\addcontentsline{toc}{section}{References
\scriptsize[included in all documents]\normalsize
}
\vspace*{-4mm}
\small
% \footnotesize
% \scriptsize
\bibliographystyle{plain}
% \bibliographystyle{plainnat} % with natbib package
\bibliography{../../../masterBib/laramee11masterBib}
%
% \cleardoublepage
%
\end{document}
