ViewVC Help
View File | Revision Log | Show Annotations | View Changeset | Root Listing
root/group/trunk/tengDissertation/Appendix.tex
(Generate patch)

Comparing trunk/tengDissertation/Appendix.tex (file contents):
Revision 2815 by tim, Wed Jun 7 18:34:05 2006 UTC vs.
Revision 2831 by tim, Thu Jun 8 21:02:53 2006 UTC

# Line 118 | Line 118 | The Singleton pattern ensures that only one instance o
118   OOPSE}.
119  
120   \subsection{\label{appendixSection:singleton}Singleton}
121 < The Singleton pattern ensures that only one instance of a class is
122 < created. All objects that use an instance of that class use the same
123 < instance.
121 > The Singleton pattern not only provides a mechanism to restrict
122 > instantiation of a class to one object, but also provides a global
123 > point of access to the object. Currently implemented as a global
124 > variable, the logging utility which reports error and warning
125 > messages to the console in {\sc OOPSE} is a good candidate for
126 > applying the Singleton pattern to avoid the global namespace
127 > pollution.Although the singleton pattern can be implemented in
128 > various ways  to account for different aspects of the software
129 > designs, such as lifespan control \textit{etc}, we only use the
130 > static data approach in {\sc OOPSE}. {\tt IntegratorFactory} class
131 > is declared as
132 > \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] Declaration of {\tt IntegratorFactory} class.},label={appendixScheme:singletonDeclaration}]
133  
134 + class IntegratorFactory {
135 +  public:
136 +    static IntegratorFactory* getInstance();
137 +    protected:
138 +      IntegratorFactory();
139 +    private:
140 +      static IntegratorFactory* instance_;
141 + };
142 +
143 + \end{lstlisting}
144 + The corresponding implementation is
145 + \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}]
146 +
147 + IntegratorFactory::instance_ = NULL;
148 +
149 + IntegratorFactory* getInstance() {
150 +  if (instance_ == NULL){
151 +    instance_ = new IntegratorFactory;
152 +  }
153 +  return instance_;
154 + }
155 +
156 + \end{lstlisting}
157 + Since constructor is declared as {\tt protected}, a client can not
158 + instantiate {\tt IntegratorFactory} directly. Moreover, since the
159 + member function {\tt getInstance} serves as the only entry of access
160 + to {\tt IntegratorFactory}, this approach fulfills the basic
161 + requirement, a single instance. Another consequence of this approach
162 + is the automatic destruction since static data are destroyed upon
163 + program termination.
164 +
165   \subsection{\label{appendixSection:factoryMethod}Factory Method}
126 – The Factory Method pattern is a creational pattern which deals with
127 – the problem of creating objects without specifying the exact class
128 – of object that will be created. Factory Method solves this problem
129 – by defining a separate method for creating the objects, which
130 – subclasses can then override to specify the derived type of product
131 – that will be created.
166  
167 + Categoried as a creational pattern, the Factory Method pattern deals
168 + with the problem of creating objects without specifying the exact
169 + class of object that will be created. Factory Method is typically
170 + implemented by delegating the creation operation to the subclasses.
171 +
172 + Registers a creator with a type identifier. Looks up the type
173 + identifier in the internal map. If it is found, it invokes the
174 + corresponding creator for the type identifier and returns its
175 + result.
176 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (I)].},label={appendixScheme:factoryDeclaration}]
177 +
178 + class IntegratorFactory {
179 +  public:
180 +    typedef std::map<string, IntegratorCreator*> CreatorMapType;
181 +
182 +    bool registerIntegrator(IntegratorCreator* creator) {
183 +      return creatorMap_.insert(creator->getIdent(), creator).second;
184 +    }
185 +
186 +    Integrator* createIntegrator(const string& id, SimInfo* info) {
187 +      Integrator* result = NULL;
188 +      CreatorMapType::iterator i = creatorMap_.find(id);
189 +      if (i != creatorMap_.end()) {
190 +        result = (i->second)->create(info);
191 +      }
192 +      return result;
193 +    }
194 +
195 +  private:
196 +    CreatorMapType creatorMap_;
197 + };
198 + \end{lstlisting}
199 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (III)]Souce code of creator classes.},label={appendixScheme:integratorCreator}]
200 +
201 + class IntegratorCreator {
202 +  public:
203 +    IntegratorCreator(const string& ident) : ident_(ident) {}
204 +
205 +    const string& getIdent() const { return ident_; }
206 +
207 +    virtual Integrator* create(SimInfo* info) const = 0;
208 +
209 +  private:
210 +    string ident_;
211 + };
212 +
213 + template<class ConcreteIntegrator>
214 + class IntegratorBuilder : public IntegratorCreator {
215 +  public:
216 +    IntegratorBuilder(const string& ident) : IntegratorCreator(ident) {}
217 +    virtual  Integrator* create(SimInfo* info) const {
218 +      return new ConcreteIntegrator(info);
219 +    }
220 + };
221 + \end{lstlisting}
222 +
223   \subsection{\label{appendixSection:visitorPattern}Visitor}
224 +
225   The purpose of the Visitor Pattern is to encapsulate an operation
226 < that you want to perform on the elements of a data structure. In
227 < this way, you can change the operation being performed on a
228 < structure without the need of changing the classes of the elements
229 < that you are operating on.
226 > that you want to perform on the elements. The operation being
227 > performed on a structure can be switched without changing the
228 > interfaces  of the elements. In other words, one can add virtual
229 > functions into a set of classes without modifying their interfaces.
230 > The UML class diagram of Visitor patten is shown in
231 > Fig.~\ref{appendixFig:visitorUML}. {\tt Dump2XYZ} program in
232 > Sec.~\ref{appendixSection:Dump2XYZ} uses Visitor pattern
233 > extensively.
234 >
235 > \begin{figure}
236 > \centering
237 > \includegraphics[width=\linewidth]{visitor.eps}
238 > \caption[The architecture of {\sc OOPSE}] {Overview of the structure
239 > of {\sc OOPSE}} \label{appendixFig:visitorUML}
240 > \end{figure}
241  
242 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
243 +
244 + class BaseVisitor{
245 +  public:
246 +    virtual void visit(Atom* atom);
247 +    virtual void visit(DirectionalAtom* datom);
248 +    virtual void visit(RigidBody* rb);
249 + };
250 +
251 + \end{lstlisting}
252 +
253 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
254 +
255 + class StuntDouble {
256 +  public:
257 +    virtual void accept(BaseVisitor* v) = 0;
258 + };
259 +
260 + class Atom: public StuntDouble {
261 +  public:
262 +    virtual void accept{BaseVisitor* v*} {
263 +      v->visit(this);
264 +    }
265 + };
266 +
267 + class DirectionalAtom: public Atom {
268 +  public:
269 +    virtual void accept{BaseVisitor* v*} {
270 +      v->visit(this);
271 +    }
272 + };
273 +
274 + class RigidBody: public StuntDouble {
275 +  public:
276 +    virtual void accept{BaseVisitor* v*} {
277 +      v->visit(this);
278 +    }
279 + };
280 +
281 + \end{lstlisting}
282 +
283   \section{\label{appendixSection:concepts}Concepts}
284  
285   OOPSE manipulates both traditional atoms as well as some objects
286   that {\it behave like atoms}.  These objects can be rigid
287   collections of atoms or atoms which have orientational degrees of
288 < freedom.  Here is a diagram of the class heirarchy:
289 <
290 < %\begin{figure}
291 < %\centering
292 < %\includegraphics[width=3in]{heirarchy.eps}
293 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
294 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
295 < %selection syntax allows the user to select any of the objects that
296 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
297 < %\end{figure}
298 <
288 > freedom.  A diagram of the class heirarchy is illustrated in
289 > Fig.~\ref{oopseFig:heirarchy}. Every Molecule, Atom and
290 > DirectionalAtom in {\sc OOPSE} have their own names which are
291 > specified in the {\tt .md} file. In contrast, RigidBodies are
292 > denoted by their membership and index inside a particular molecule:
293 > [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
294 > on the specifics of the simulation). The names of rigid bodies are
295 > generated automatically. For example, the name of the first rigid
296 > body in a DMPC molecule is DMPC\_RB\_0.
297 > \begin{figure}
298 > \centering
299 > \includegraphics[width=\linewidth]{heirarchy.eps}
300 > \caption[Class heirarchy for ojects in {\sc OOPSE}]{ A diagram of
301 > the class heirarchy.
302   \begin{itemize}
303   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
304   integrators and minimizers.
# Line 161 | Line 307 | DirectionalAtom}s which behaves as a single unit.
307   \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
308   DirectionalAtom}s which behaves as a single unit.
309   \end{itemize}
310 + } \label{oopseFig:heirarchy}
311 + \end{figure}
312  
165 – Every Molecule, Atom and DirectionalAtom in {\sc OOPSE} have their
166 – own names which are specified in the {\tt .md} file. In contrast,
167 – RigidBodies are denoted by their membership and index inside a
168 – particular molecule: [MoleculeName]\_RB\_[index] (the contents
169 – inside the brackets depend on the specifics of the simulation). The
170 – names of rigid bodies are generated automatically. For example, the
171 – name of the first rigid body in a DMPC molecule is DMPC\_RB\_0.
172 –
313   \section{\label{appendixSection:syntax}Syntax of the Select Command}
314  
315   The most general form of the select command is: {\tt select {\it
# Line 377 | Line 517 | Fig.~\ref{oopseFig:staticPropsProcess}.
517   \centering
518   \includegraphics[width=\linewidth]{staticPropsProcess.eps}
519   \caption[A representation of the three-stage correlations in
520 < \texttt{StaticProps}]{Three-stage processing in
521 < \texttt{StaticProps}. $S_1$ and $S_2$ are the numbers of selected
522 < stuntdobules from {\tt -{}-sele1} and {\tt -{}-sele2} respectively,
523 < while $C$ is the number of stuntdobules appearing at both sets. The
524 < first stage($S_1-C$ and $S_2$) and second stages ($S_1$ and $S_2-C$)
525 < are completely non-overlapping. On the contrary, the third stage($C$
526 < and $C$) are completely overlapping}
527 < \label{oopseFig:staticPropsProcess}
520 > \texttt{StaticProps}]{This diagram illustrates three-stage
521 > processing used by \texttt{StaticProps}. $S_1$ and $S_2$ are the
522 > numbers of selected stuntdobules from {\tt -{}-sele1} and {\tt
523 > -{}-sele2} respectively, while $C$ is the number of stuntdobules
524 > appearing at both sets. The first stage($S_1-C$ and $S_2$) and
525 > second stages ($S_1$ and $S_2-C$) are completely non-overlapping. On
526 > the contrary, the third stage($C$ and $C$) are completely
527 > overlapping} \label{oopseFig:staticPropsProcess}
528   \end{figure}
529  
530   The options available for {\tt StaticProps} are as follows:
# Line 462 | Line 602 | incremented, until all frame pairs have been correlate
602   incremented and the process repeated until the end of the
603   trajectory. Once the end is reached, the first block is freed then
604   incremented, until all frame pairs have been correlated in time.
605 + This process is illustrated in
606 + Fig.~\ref{oopseFig:dynamicPropsProcess}.
607  
608 + \begin{figure}
609 + \centering
610 + \includegraphics[width=\linewidth]{dynamicPropsProcess.eps}
611 + \caption[A representation of the block correlations in
612 + \texttt{dynamicProps}]{This diagram illustrates block correlations
613 + processing in \texttt{dynamicProps}. The shaded region represents
614 + the self correlation of the block, and the open blocks are read one
615 + at a time and the cross correlations between blocks are calculated.}
616 + \label{oopseFig:dynamicPropsProcess}
617 + \end{figure}
618 +
619   The options available for DynamicProps are as follows:
620   \begin{longtable}[c]{|EFG|}
621   \caption{DynamicProps Command-line Options}
# Line 489 | Line 642 | Dump2XYZ can transform an OOPSE dump file into a xyz f
642  
643   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
644  
645 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
646 < be opened by other molecular dynamics viewers such as Jmol and
647 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
648 < follows:
645 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
646 > which can be opened by other molecular dynamics viewers such as Jmol
647 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
648 > as follows:
649  
650  
651   \begin{longtable}[c]{|EFG|}
# Line 523 | Line 676 | The options available for Hydro are as follows:
676   \end{longtable}
677  
678   \subsection{\label{appendixSection:hydrodynamics}Hydro}
679 < The options available for Hydro are as follows:
679 >
680 > {\tt Hydro} can calculate resistance and diffusion tensors at the
681 > center of resistance. Both tensors at the center of diffusion can
682 > also be reported from the program, as well as the coordinates for
683 > the beads which are used to approximate the arbitrary shapes. The
684 > options available for Hydro are as follows:
685   \begin{longtable}[c]{|EFG|}
686   \caption{Hydrodynamics Command-line Options}
687   \\ \hline

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines