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 2829 by tim, Thu Jun 8 20:24:39 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 +
184 +    Integrator* createIntegrator(const string& id, SimInfo* info);
185 +
186 +  private:
187 +    CreatorMapType creatorMap_;
188 + };
189 +
190 + \end{lstlisting}
191 +
192 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (II)].},label={appendixScheme:factoryDeclarationImplementation}]
193 +
194 + bool IntegratorFactory::unregisterIntegrator(const string& id) {
195 +  return creatorMap_.erase(id) == 1;
196 + }
197 +
198 + Integrator* IntegratorFactory::createIntegrator(const string& id,
199 +                                                SimInfo* info) {
200 +  CreatorMapType::iterator i = creatorMap_.find(id);
201 +  if (i != creatorMap_.end()) {
202 +    return (i->second)->create(info);
203 +  } else {
204 +    return NULL;
205 +  }
206 + }
207 +
208 + \end{lstlisting}
209 +
210 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (III)].},label={appendixScheme:integratorCreator}]
211 +
212 + class IntegratorCreator {
213 +  public:
214 +    IntegratorCreator(const string& ident) : ident_(ident) {}
215 +
216 +    const string& getIdent() const { return ident_; }
217 +
218 +    virtual Integrator* create(SimInfo* info) const = 0;
219 +
220 +  private:
221 +    string ident_;
222 + };
223 +
224 + template<class ConcreteIntegrator>
225 + class IntegratorBuilder : public IntegratorCreator {
226 +  public:
227 +    IntegratorBuilder(const string& ident) : IntegratorCreator(ident) {}
228 +    virtual  Integrator* create(SimInfo* info) const {
229 +      return new ConcreteIntegrator(info);
230 +    }
231 + };
232 + \end{lstlisting}
233 +
234   \subsection{\label{appendixSection:visitorPattern}Visitor}
235 +
236   The purpose of the Visitor Pattern is to encapsulate an operation
237 < that you want to perform on the elements of a data structure. In
238 < this way, you can change the operation being performed on a
239 < structure without the need of changing the classes of the elements
240 < that you are operating on.
237 > that you want to perform on the elements. The operation being
238 > performed on a structure can be switched without changing the
239 > interfaces  of the elements. In other words, one can add virtual
240 > functions into a set of classes without modifying their interfaces.
241 > The UML class diagram of Visitor patten is shown in
242 > Fig.~\ref{appendixFig:visitorUML}. {\tt Dump2XYZ} program in
243 > Sec.~\ref{appendixSection:Dump2XYZ} uses Visitor pattern
244 > extensively.
245  
246 + \begin{figure}
247 + \centering
248 + \includegraphics[width=\linewidth]{visitor.eps}
249 + \caption[The architecture of {\sc OOPSE}] {Overview of the structure
250 + of {\sc OOPSE}} \label{appendixFig:visitorUML}
251 + \end{figure}
252 +
253 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
254 +
255 + class BaseVisitor{
256 +  public:
257 +    virtual void visit(Atom* atom);
258 +    virtual void visit(DirectionalAtom* datom);
259 +    virtual void visit(RigidBody* rb);
260 + };
261 +
262 + \end{lstlisting}
263 +
264 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
265 +
266 + class StuntDouble {
267 +  public:
268 +    virtual void accept(BaseVisitor* v) = 0;
269 + };
270 +
271 + class Atom: public StuntDouble {
272 +  public:
273 +    virtual void accept{BaseVisitor* v*} {
274 +      v->visit(this);
275 +    }
276 + };
277 +
278 + class DirectionalAtom: public Atom {
279 +  public:
280 +    virtual void accept{BaseVisitor* v*} {
281 +      v->visit(this);
282 +    }
283 + };
284 +
285 + class RigidBody: public StuntDouble {
286 +  public:
287 +    virtual void accept{BaseVisitor* v*} {
288 +      v->visit(this);
289 +    }
290 + };
291 +
292 + \end{lstlisting}
293 +
294   \section{\label{appendixSection:concepts}Concepts}
295  
296   OOPSE manipulates both traditional atoms as well as some objects
297   that {\it behave like atoms}.  These objects can be rigid
298   collections of atoms or atoms which have orientational degrees of
299 < freedom.  Here is a diagram of the class heirarchy:
300 <
301 < %\begin{figure}
302 < %\centering
303 < %\includegraphics[width=3in]{heirarchy.eps}
304 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
305 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
306 < %selection syntax allows the user to select any of the objects that
307 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
308 < %\end{figure}
309 <
299 > freedom.  A diagram of the class heirarchy is illustrated in
300 > Fig.~\ref{oopseFig:heirarchy}. Every Molecule, Atom and
301 > DirectionalAtom in {\sc OOPSE} have their own names which are
302 > specified in the {\tt .md} file. In contrast, RigidBodies are
303 > denoted by their membership and index inside a particular molecule:
304 > [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
305 > on the specifics of the simulation). The names of rigid bodies are
306 > generated automatically. For example, the name of the first rigid
307 > body in a DMPC molecule is DMPC\_RB\_0.
308 > \begin{figure}
309 > \centering
310 > \includegraphics[width=\linewidth]{heirarchy.eps}
311 > \caption[Class heirarchy for StuntDoubles in {\sc OOPSE}]{ The class
312 > heirarchy of StuntDoubles in {\sc OOPSE}.
313   \begin{itemize}
314   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
315   integrators and minimizers.
# Line 161 | Line 318 | DirectionalAtom}s which behaves as a single unit.
318   \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
319   DirectionalAtom}s which behaves as a single unit.
320   \end{itemize}
321 + } \label{oopseFig:heirarchy}
322 + \end{figure}
323  
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 –
324   \section{\label{appendixSection:syntax}Syntax of the Select Command}
325  
326   The most general form of the select command is: {\tt select {\it
# Line 377 | Line 528 | Fig.~\ref{oopseFig:staticPropsProcess}.
528   \centering
529   \includegraphics[width=\linewidth]{staticPropsProcess.eps}
530   \caption[A representation of the three-stage correlations in
531 < \texttt{StaticProps}]{Three-stage processing in
532 < \texttt{StaticProps}. $S_1$ and $S_2$ are the numbers of selected
533 < stuntdobules from {\tt -{}-sele1} and {\tt -{}-sele2} respectively,
534 < while $C$ is the number of stuntdobules appearing at both sets. The
535 < first stage($S_1-C$ and $S_2$) and second stages ($S_1$ and $S_2-C$)
536 < are completely non-overlapping. On the contrary, the third stage($C$
537 < and $C$) are completely overlapping}
538 < \label{oopseFig:staticPropsProcess}
531 > \texttt{StaticProps}]{This diagram illustrates three-stage
532 > processing used by \texttt{StaticProps}. $S_1$ and $S_2$ are the
533 > numbers of selected stuntdobules from {\tt -{}-sele1} and {\tt
534 > -{}-sele2} respectively, while $C$ is the number of stuntdobules
535 > appearing at both sets. The first stage($S_1-C$ and $S_2$) and
536 > second stages ($S_1$ and $S_2-C$) are completely non-overlapping. On
537 > the contrary, the third stage($C$ and $C$) are completely
538 > overlapping} \label{oopseFig:staticPropsProcess}
539   \end{figure}
540  
541   The options available for {\tt StaticProps} are as follows:
# Line 462 | Line 613 | incremented, until all frame pairs have been correlate
613   incremented and the process repeated until the end of the
614   trajectory. Once the end is reached, the first block is freed then
615   incremented, until all frame pairs have been correlated in time.
616 + This process is illustrated in
617 + Fig.~\ref{oopseFig:dynamicPropsProcess}.
618  
619 + \begin{figure}
620 + \centering
621 + \includegraphics[width=\linewidth]{dynamicPropsProcess.eps}
622 + \caption[A representation of the block correlations in
623 + \texttt{dynamicProps}]{This diagram illustrates block correlations
624 + processing in \texttt{dynamicProps}. The shaded region represents
625 + the self correlation of the block, and the open blocks are read one
626 + at a time and the cross correlations between blocks are calculated.}
627 + \label{oopseFig:dynamicPropsProcess}
628 + \end{figure}
629 +
630   The options available for DynamicProps are as follows:
631   \begin{longtable}[c]{|EFG|}
632   \caption{DynamicProps Command-line Options}
# Line 489 | Line 653 | Dump2XYZ can transform an OOPSE dump file into a xyz f
653  
654   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
655  
656 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
657 < be opened by other molecular dynamics viewers such as Jmol and
658 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
659 < follows:
656 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
657 > which can be opened by other molecular dynamics viewers such as Jmol
658 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
659 > as follows:
660  
661  
662   \begin{longtable}[c]{|EFG|}
# Line 523 | Line 687 | The options available for Hydro are as follows:
687   \end{longtable}
688  
689   \subsection{\label{appendixSection:hydrodynamics}Hydro}
690 < The options available for Hydro are as follows:
690 >
691 > {\tt Hydro} can calculate resistance and diffusion tensors at the
692 > center of resistance. Both tensors at the center of diffusion can
693 > also be reported from the program, as well as the coordinates for
694 > the beads which are used to approximate the arbitrary shapes. The
695 > options available for Hydro are as follows:
696   \begin{longtable}[c]{|EFG|}
697   \caption{Hydrodynamics Command-line Options}
698   \\ \hline

Diff Legend

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