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 |
|
|
\cite{Meineke05} and PROTOMOL \cite{} \textit{etc}. |
52 |
tim |
2685 |
|
53 |
tim |
2688 |
\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 |
tim |
2685 |
|
61 |
|
|
|
62 |
tim |
2688 |
\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 |
tim |
2685 |
|
69 |
|
|
|
70 |
tim |
2688 |
\subsection{\label{appendixSection:templateMethod}Template Method} |
71 |
|
|
|
72 |
|
|
|
73 |
tim |
2685 |
\section{\label{appendixSection:analysisFramework}Analysis Framework} |
74 |
|
|
|
75 |
tim |
2688 |
\section{\label{appendixSection:hierarchy}Hierarchy} |
76 |
tim |
2685 |
|
77 |
tim |
2688 |
\subsection{\label{appendixSection:selectionSyntax}Selection Syntax} |
78 |
|
|
|
79 |
|
|
\subsection{\label{appendixSection:hydrodynamics}Hydrodynamics} |
80 |
|
|
|
81 |
|
|
\subsection{\label{appendixSection:staticProps}Static Properties} |
82 |
|
|
|
83 |
tim |
2685 |
\subsection{\label{appendixSection:dynamicProps}Dynamics Properties} |