trunk/tengDissertation/Appendix.tex

\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.

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}

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{Matthey05} \textit{etc}.

\subsection{\label{appendixSection:singleton}Singleton}
The Singleton pattern ensures that only one instance of a class is
created. All objects that use an instance of that class use the same
instance.

\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.


\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.


\subsection{\label{appendixSection:templateMethod}Template Method}

\section{\label{appendixSection:analysisFramework}Analysis Framework}

\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}
Revision:	2693
Committed:	Wed Apr 5 03:44:32 2006 UTC (19 years, 7 months ago) by tim
Content type:	application/x-tex
File size:	4458 byte(s)
Log Message:	minor fix
#	User	Rev	Content
1	tim	2685	\chapter{\label{chapt:appendix}APPENDIX}
2
3	tim	2688	Designing object-oriented software is hard, and designing reusable
4			object-oriented scientific software is even harder. Absence of
5			applying modern software development practices is the bottleneck of
6			Scientific Computing community\cite{wilson}. For instance, in the
7			last 20 years , there are quite a few MD packages that were
8			developed to solve common MD problems and perform robust simulations
9			. However, many of the codes are legacy programs that are either
10			poorly organized or extremely complex. Usually, these packages were
11			contributed by scientists without official computer science
12			training. The development of most MD applications are lack of strong
13			coordination to enforce design and programming guidelines. Moreover,
14			most MD programs also suffer from missing design and implement
15			documents which is crucial to the maintenance and extensibility.
16
17	tim	2685	\section{\label{appendixSection:desginPattern}Design Pattern}
18
19	tim	2688	Design patterns are optimal solutions to commonly-occurring problems
20			in software design. Although originated as an architectural concept
21			for buildings and towns by Christopher Alexander \cite{alexander},
22			software patterns first became popular with the wide acceptance of
23			the book, Design Patterns: Elements of Reusable Object-Oriented
24			Software \cite{gamma94}. Patterns reflect the experience, knowledge
25			and insights of developers who have successfully used these patterns
26			in their own work. Patterns are reusable. They provide a ready-made
27			solution that can be adapted to different problems as necessary.
28			Pattern are expressive. they provide a common vocabulary of
29			solutions that can express large solutions succinctly.
30	tim	2685
31	tim	2688	Patterns are usually described using a format that includes the
32			following information:
33			\begin{enumerate}
34			\item The \emph{name} that is commonly used for the pattern. Good pattern names form a vocabulary for
35			discussing conceptual abstractions. a pattern may have more than one commonly used or recognizable name
36			in the literature. In this case it is common practice to document these nicknames or synonyms under
37			the heading of \emph{Aliases} or \emph{Also Known As}.
38			\item The \emph{motivation} or \emph{context} that this pattern applies
39			to. Sometimes, it will include some prerequisites that should be satisfied before deciding to use a pattern
40			\item The \emph{solution} to the problem that the pattern
41			addresses. It describes how to construct the necessary work products. The description may include
42			pictures, diagrams and prose which identify the pattern's structure, its participants, and their
43			collaborations, to show how the problem is solved.
44			\item The \emph{consequences} of using the given solution to solve a
45			problem, both positive and negative.
46			\end{enumerate}
47	tim	2685
48	tim	2688	As one of the latest advanced techniques emerged from
49			object-oriented community, design patterns were applied in some of
50			the modern scientific software applications, such as JMol, OOPSE
51	tim	2693	\cite{Meineke05} and PROTOMOL \cite{Matthey05} \textit{etc}.
52	tim	2685
53	tim	2693	\subsection{\label{appendixSection:singleton}Singleton}
54			The Singleton pattern ensures that only one instance of a class is
55			created. All objects that use an instance of that class use the same
56			instance.
57
58	tim	2688	\subsection{\label{appendixSection:factoryMethod}Factory Method}
59			The Factory Method pattern is a creational pattern which deals with
60			the problem of creating objects without specifying the exact class
61			of object that will be created. Factory Method solves this problem
62			by defining a separate method for creating the objects, which
63			subclasses can then override to specify the derived type of product
64			that will be created.
65	tim	2685
66
67	tim	2688	\subsection{\label{appendixSection:visitorPattern}Visitor}
68			The purpose of the Visitor Pattern is to encapsulate an operation
69			that you want to perform on the elements of a data structure. In
70			this way, you can change the operation being performed on a
71			structure without the need of changing the classes of the elements
72			that you are operating on.
73	tim	2685
74
75	tim	2688	\subsection{\label{appendixSection:templateMethod}Template Method}
76
77	tim	2685	\section{\label{appendixSection:analysisFramework}Analysis Framework}
78
79	tim	2688	\section{\label{appendixSection:hierarchy}Hierarchy}
80	tim	2685
81	tim	2688	\subsection{\label{appendixSection:selectionSyntax}Selection Syntax}
82
83			\subsection{\label{appendixSection:hydrodynamics}Hydrodynamics}
84
85			\subsection{\label{appendixSection:staticProps}Static Properties}
86
87	tim	2685	\subsection{\label{appendixSection:dynamicProps}Dynamics Properties}