--- trunk/tengDissertation/Appendix.tex	2006/04/03 18:07:54	2685
+++ trunk/tengDissertation/Appendix.tex	2006/04/04 04:32:24	2688
@@ -1,22 +1,83 @@
 \chapter{\label{chapt:appendix}APPENDIX}
 
+Designing object-oriented software is hard, and designing reusable
+object-oriented scientific software is even harder. Absence of
+applying modern software development practices is the bottleneck of
+Scientific Computing community\cite{wilson}. For instance, in the
+last 20 years , there are quite a few MD packages that were
+developed to solve common MD problems and perform robust simulations
+. However, many of the codes are legacy programs that are either
+poorly organized or extremely complex. Usually, these packages were
+contributed by scientists without official computer science
+training. The development of most MD applications are lack of strong
+coordination to enforce design and programming guidelines. Moreover,
+most MD programs also suffer from missing design and implement
+documents which is crucial to the maintenance and extensibility.
+
 \section{\label{appendixSection:desginPattern}Design Pattern}
 
+Design patterns are optimal solutions to commonly-occurring problems
+in software design. Although originated as an architectural concept
+for buildings and towns by Christopher Alexander \cite{alexander},
+software patterns first became popular with the wide acceptance of
+the book, Design Patterns: Elements of Reusable Object-Oriented
+Software \cite{gamma94}. Patterns reflect the experience, knowledge
+and insights of developers who have successfully used these patterns
+in their own work. Patterns are reusable. They provide a ready-made
+solution that can be adapted to different problems as necessary.
+Pattern are expressive. they provide a common vocabulary of
+solutions that can express large solutions succinctly.
 
-\subsection{\label{appendixSection:visitorPattern}Visitor Pattern}
+Patterns are usually described using a format that includes the
+following information:
+\begin{enumerate}
+  \item The \emph{name} that is commonly used for the pattern. Good pattern names form a vocabulary for
+  discussing conceptual abstractions. a pattern may have more than one commonly used or recognizable name
+  in the literature. In this case it is common practice to document these nicknames or synonyms under
+  the heading of \emph{Aliases} or \emph{Also Known As}.
+  \item The \emph{motivation} or \emph{context} that this pattern applies
+  to. Sometimes, it will include some prerequisites that should be satisfied before deciding to use a pattern
+  \item The \emph{solution} to the problem that the pattern
+  addresses. It describes how to construct the necessary work products. The description may include
+  pictures, diagrams and prose which identify the pattern's structure, its participants, and their
+  collaborations, to show how the problem is solved.
+  \item The \emph{consequences} of using the given solution to solve a
+  problem, both positive and negative.
+\end{enumerate}
 
-\subsection{\label{appendixSection:templatePattern}Template Pattern}
+As one of the latest advanced techniques emerged from
+object-oriented community, design patterns were applied in some of
+the modern scientific software applications, such as JMol, OOPSE
+\cite{Meineke05} and PROTOMOL \cite{} \textit{etc}.
 
-\subsection{\label{appendixSection:factoryPattern}Factory Pattern}
+\subsection{\label{appendixSection:factoryMethod}Factory Method}
+The Factory Method pattern is a creational pattern which deals with
+the problem of creating objects without specifying the exact class
+of object that will be created. Factory Method solves this problem
+by defining a separate method for creating the objects, which
+subclasses can then override to specify the derived type of product
+that will be created.
 
-\section{\label{appendixSection:hierarchy}Hierarchy}
 
-\section{\label{appendixSection:selectionSyntax}Selection Syntax}
+\subsection{\label{appendixSection:visitorPattern}Visitor}
+The purpose of the Visitor Pattern is to encapsulate an operation
+that you want to perform on the elements of a data structure. In
+this way, you can change the operation being performed on a
+structure without the need of changing the classes of the elements
+that you are operating on.
 
-\section{\label{appendixSection:hydrodynamics}Hydrodynamics}
 
+\subsection{\label{appendixSection:templateMethod}Template Method}
+
+
 \section{\label{appendixSection:analysisFramework}Analysis Framework}
 
-\subsection{\label{appendixSection:staticProps}Factory Properties}
+\section{\label{appendixSection:hierarchy}Hierarchy}
 
+\subsection{\label{appendixSection:selectionSyntax}Selection Syntax}
+
+\subsection{\label{appendixSection:hydrodynamics}Hydrodynamics}
+
+\subsection{\label{appendixSection:staticProps}Static Properties}
+
 \subsection{\label{appendixSection:dynamicProps}Dynamics Properties}