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 2816 by tim, Wed Jun 7 19:51:57 2006 UTC vs.
Revision 2832 by tim, Thu Jun 8 21:09:22 2006 UTC

# Line 118 | Line 118 | OOPSE}.
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*
137 +  getInstance();
138 + protected:
139 +  IntegratorFactory();
140 + private:
141 +  static IntegratorFactory* instance_;
142 + };
143 +
144 + \end{lstlisting}
145 + The corresponding implementation is
146 + \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}]
147 +
148 + IntegratorFactory::instance_ = NULL;
149 +
150 + IntegratorFactory* getInstance() {
151 +  if (instance_ == NULL){
152 +    instance_ = new IntegratorFactory;
153 +  }
154 +  return instance_;
155 + }
156 +
157 + \end{lstlisting}
158 + Since constructor is declared as {\tt protected}, a client can not
159 + instantiate {\tt IntegratorFactory} directly. Moreover, since the
160 + member function {\tt getInstance} serves as the only entry of access
161 + to {\tt IntegratorFactory}, this approach fulfills the basic
162 + requirement, a single instance. Another consequence of this approach
163 + is the automatic destruction since static data are destroyed upon
164 + program termination.
165 +
166   \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.
167  
168 + Categoried as a creational pattern, the Factory Method pattern deals
169 + with the problem of creating objects without specifying the exact
170 + class of object that will be created. Factory Method is typically
171 + implemented by delegating the creation operation to the subclasses.
172 +
173 + Registers a creator with a type identifier. Looks up the type
174 + identifier in the internal map. If it is found, it invokes the
175 + corresponding creator for the type identifier and returns its
176 + result.
177 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (I)].},label={appendixScheme:factoryDeclaration}]
178 +
179 + class IntegratorFactory {
180 + public:
181 +  typedef std::map<string, IntegratorCreator*> CreatorMapType;
182 +
183 +  bool registerIntegrator(IntegratorCreator* creator) {
184 +    return creatorMap_.insert(creator->getIdent(), creator).second;
185 +  }
186 +
187 +  Integrator* createIntegrator(const string& id, SimInfo* info) {
188 +    Integrator* result = NULL;
189 +    CreatorMapType::iterator i = creatorMap_.find(id);
190 +    if (i != creatorMap_.end()) {
191 +      result = (i->second)->create(info);
192 +    }
193 +    return result;
194 +  }
195 +
196 + private:
197 +  CreatorMapType creatorMap_;
198 + };
199 + \end{lstlisting}
200 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (III)]Souce code of creator classes.},label={appendixScheme:integratorCreator}]
201 +
202 + class IntegratorCreator {
203 + public:
204 +    IntegratorCreator(const string& ident) : ident_(ident) {}
205 +
206 +    const string& getIdent() const { return ident_; }
207 +
208 +    virtual Integrator* create(SimInfo* info) const = 0;
209 +
210 + private:
211 +    string ident_;
212 + };
213 +
214 + template<class ConcreteIntegrator> class IntegratorBuilder : public
215 + IntegratorCreator {
216 + public:
217 +  IntegratorBuilder(const string& ident)
218 +                     : IntegratorCreator(ident) {}
219 +  virtual  Integrator* create(SimInfo* info) const {
220 +    return new ConcreteIntegrator(info);
221 +  }
222 + };
223 + \end{lstlisting}
224 +
225   \subsection{\label{appendixSection:visitorPattern}Visitor}
226 +
227   The purpose of the Visitor Pattern is to encapsulate an operation
228 < that you want to perform on the elements of a data structure. In
229 < this way, you can change the operation being performed on a
230 < structure without the need of changing the classes of the elements
231 < that you are operating on.
228 > that you want to perform on the elements. The operation being
229 > performed on a structure can be switched without changing the
230 > interfaces  of the elements. In other words, one can add virtual
231 > functions into a set of classes without modifying their interfaces.
232 > The UML class diagram of Visitor patten is shown in
233 > Fig.~\ref{appendixFig:visitorUML}. {\tt Dump2XYZ} program in
234 > Sec.~\ref{appendixSection:Dump2XYZ} uses Visitor pattern
235 > extensively.
236 >
237 > \begin{figure}
238 > \centering
239 > \includegraphics[width=\linewidth]{visitor.eps}
240 > \caption[The architecture of {\sc OOPSE}] {Overview of the structure
241 > of {\sc OOPSE}} \label{appendixFig:visitorUML}
242 > \end{figure}
243 >
244 > \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
245 >
246 > class BaseVisitor{
247 > public:
248 >  virtual void visit(Atom* atom);
249 >  virtual void visit(DirectionalAtom* datom);
250 >  virtual void visit(RigidBody* rb);
251 > };
252 >
253 > \end{lstlisting}
254 >
255 > \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
256 >
257 > class StuntDouble {
258 > public:
259 >  virtual void accept(BaseVisitor* v) = 0;
260 > };
261 >
262 > class Atom: public StuntDouble {
263 > public:
264 >  virtual void accept{BaseVisitor* v*} {
265 >    v->visit(this);
266 >  }
267 > };
268 >
269 > class DirectionalAtom: public Atom {
270 > public:
271 >  virtual void accept{BaseVisitor* v*} {
272 >    v->visit(this);
273 >  }
274 > };
275 >
276 > class RigidBody: public StuntDouble {
277 > public:
278 >  virtual void accept{BaseVisitor* v*} {
279 >    v->visit(this);
280 >  }
281 > };
282  
283 + \end{lstlisting}
284 +
285   \section{\label{appendixSection:concepts}Concepts}
286  
287   OOPSE manipulates both traditional atoms as well as some objects
288   that {\it behave like atoms}.  These objects can be rigid
289   collections of atoms or atoms which have orientational degrees of
290 < freedom.  Here is a diagram of the class heirarchy:
291 <
292 < %\begin{figure}
293 < %\centering
294 < %\includegraphics[width=3in]{heirarchy.eps}
295 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
296 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
297 < %selection syntax allows the user to select any of the objects that
298 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
299 < %\end{figure}
300 <
290 > freedom.  A diagram of the class heirarchy is illustrated in
291 > Fig.~\ref{oopseFig:heirarchy}. Every Molecule, Atom and
292 > DirectionalAtom in {\sc OOPSE} have their own names which are
293 > specified in the {\tt .md} file. In contrast, RigidBodies are
294 > denoted by their membership and index inside a particular molecule:
295 > [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
296 > on the specifics of the simulation). The names of rigid bodies are
297 > generated automatically. For example, the name of the first rigid
298 > body in a DMPC molecule is DMPC\_RB\_0.
299 > \begin{figure}
300 > \centering
301 > \includegraphics[width=\linewidth]{heirarchy.eps}
302 > \caption[Class heirarchy for ojects in {\sc OOPSE}]{ A diagram of
303 > the class heirarchy.
304   \begin{itemize}
305   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
306   integrators and minimizers.
# Line 161 | Line 309 | DirectionalAtom}s which behaves as a single unit.
309   \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
310   DirectionalAtom}s which behaves as a single unit.
311   \end{itemize}
312 <
313 < 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.
312 > } \label{oopseFig:heirarchy}
313 > \end{figure}
314  
315   \section{\label{appendixSection:syntax}Syntax of the Select Command}
316  
# Line 502 | Line 644 | The options available for DynamicProps are as follows:
644  
645   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
646  
647 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
648 < be opened by other molecular dynamics viewers such as Jmol and
649 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
650 < follows:
647 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
648 > which can be opened by other molecular dynamics viewers such as Jmol
649 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
650 > as follows:
651  
652  
653   \begin{longtable}[c]{|EFG|}
# Line 536 | Line 678 | converted. \\
678   \end{longtable}
679  
680   \subsection{\label{appendixSection:hydrodynamics}Hydro}
681 < The options available for Hydro are as follows:
681 >
682 > {\tt Hydro} can calculate resistance and diffusion tensors at the
683 > center of resistance. Both tensors at the center of diffusion can
684 > also be reported from the program, as well as the coordinates for
685 > the beads which are used to approximate the arbitrary shapes. The
686 > options available for Hydro are as follows:
687   \begin{longtable}[c]{|EFG|}
688   \caption{Hydrodynamics Command-line Options}
689   \\ \hline

Diff Legend

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