1 |
|
\chapter{\label{chapt:appendix}APPENDIX} |
2 |
|
|
3 |
+ |
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 |
|
\section{\label{appendixSection:desginPattern}Design Pattern} |
18 |
|
|
19 |
+ |
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 |
|
|
31 |
< |
\subsection{\label{appendixSection:visitorPattern}Visitor Pattern} |
31 |
> |
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 |
|
|
48 |
< |
\subsection{\label{appendixSection:templatePattern}Template Pattern} |
48 |
> |
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 |
> |
\cite{Meineke05} and PROTOMOL \cite{} \textit{etc}. |
52 |
|
|
53 |
< |
\subsection{\label{appendixSection:factoryPattern}Factory Pattern} |
53 |
> |
\subsection{\label{appendixSection:factoryMethod}Factory Method} |
54 |
> |
The Factory Method pattern is a creational pattern which deals with |
55 |
> |
the problem of creating objects without specifying the exact class |
56 |
> |
of object that will be created. Factory Method solves this problem |
57 |
> |
by defining a separate method for creating the objects, which |
58 |
> |
subclasses can then override to specify the derived type of product |
59 |
> |
that will be created. |
60 |
|
|
12 |
– |
\section{\label{appendixSection:hierarchy}Hierarchy} |
61 |
|
|
62 |
< |
\section{\label{appendixSection:selectionSyntax}Selection Syntax} |
62 |
> |
\subsection{\label{appendixSection:visitorPattern}Visitor} |
63 |
> |
The purpose of the Visitor Pattern is to encapsulate an operation |
64 |
> |
that you want to perform on the elements of a data structure. In |
65 |
> |
this way, you can change the operation being performed on a |
66 |
> |
structure without the need of changing the classes of the elements |
67 |
> |
that you are operating on. |
68 |
|
|
16 |
– |
\section{\label{appendixSection:hydrodynamics}Hydrodynamics} |
69 |
|
|
70 |
+ |
\subsection{\label{appendixSection:templateMethod}Template Method} |
71 |
+ |
|
72 |
+ |
|
73 |
|
\section{\label{appendixSection:analysisFramework}Analysis Framework} |
74 |
|
|
75 |
< |
\subsection{\label{appendixSection:staticProps}Factory Properties} |
75 |
> |
\section{\label{appendixSection:hierarchy}Hierarchy} |
76 |
|
|
77 |
+ |
\subsection{\label{appendixSection:selectionSyntax}Selection Syntax} |
78 |
+ |
|
79 |
+ |
\subsection{\label{appendixSection:hydrodynamics}Hydrodynamics} |
80 |
+ |
|
81 |
+ |
\subsection{\label{appendixSection:staticProps}Static Properties} |
82 |
+ |
|
83 |
|
\subsection{\label{appendixSection:dynamicProps}Dynamics Properties} |