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 2837 by tim, Fri Jun 9 02:20: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  
122 + The Singleton pattern not only provides a mechanism to restrict
123 + instantiation of a class to one object, but also provides a global
124 + point of access to the object. Currently implemented as a global
125 + variable, the logging utility which reports error and warning
126 + messages to the console in {\sc OOPSE} is a good candidate for
127 + applying the Singleton pattern to avoid the global namespace
128 + pollution.Although the singleton pattern can be implemented in
129 + various ways  to account for different aspects of the software
130 + designs, such as lifespan control \textit{etc}, we only use the
131 + static data approach in {\sc OOPSE}. IntegratorFactory class is
132 + declared as
133 +
134 + \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] The declaration of of simple Singleton pattern.},label={appendixScheme:singletonDeclaration}]
135 +
136 + class IntegratorFactory {
137 + public:
138 +  static IntegratorFactory*
139 +  getInstance();
140 + protected:
141 +  IntegratorFactory();
142 + private:
143 +  static IntegratorFactory* instance_;
144 + };
145 +
146 + \end{lstlisting}
147 +
148 + The corresponding implementation is
149 +
150 + \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] The implementation of simple Singleton pattern.},label={appendixScheme:singletonImplementation}]
151 +
152 + IntegratorFactory::instance_ = NULL;
153 +
154 + IntegratorFactory* getInstance() {
155 +  if (instance_ == NULL){
156 +    instance_ = new IntegratorFactory;
157 +  }
158 +  return instance_;
159 + }
160 +
161 + \end{lstlisting}
162 +
163 + Since constructor is declared as protected, a client can not
164 + instantiate IntegratorFactory directly. Moreover, since the member
165 + function getInstance serves as the only entry of access to
166 + IntegratorFactory, this approach fulfills the basic requirement, a
167 + single instance. Another consequence of this approach is the
168 + automatic destruction since static data are destroyed upon program
169 + termination.
170 +
171   \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.
172  
173 + Categoried as a creational pattern, the Factory Method pattern deals
174 + with the problem of creating objects without specifying the exact
175 + class of object that will be created. Factory Method is typically
176 + implemented by delegating the creation operation to the subclasses.
177 + Parameterized Factory pattern where factory method (
178 + createIntegrator member function) creates products based on the
179 + identifier (see List.~\ref{appendixScheme:factoryDeclaration}). If
180 + the identifier has been already registered, the factory method will
181 + invoke the corresponding creator (see List.~\ref{integratorCreator})
182 + which utilizes the modern C++ template technique to avoid excess
183 + subclassing.
184 +
185 + \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}]
186 +
187 + class IntegratorFactory {
188 + public:
189 +  typedef std::map<string, IntegratorCreator*> CreatorMapType;
190 +
191 +  bool registerIntegrator(IntegratorCreator* creator) {
192 +    return creatorMap_.insert(creator->getIdent(), creator).second;
193 +  }
194 +
195 +  Integrator* createIntegrator(const string& id, SimInfo* info) {
196 +    Integrator* result = NULL;
197 +    CreatorMapType::iterator i = creatorMap_.find(id);
198 +    if (i != creatorMap_.end()) {
199 +      result = (i->second)->create(info);
200 +    }
201 +    return result;
202 +  }
203 +
204 + private:
205 +  CreatorMapType creatorMap_;
206 + };
207 + \end{lstlisting}
208 +
209 + \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (III)]Source code of creator classes.},label={appendixScheme:integratorCreator}]
210 +
211 + class IntegratorCreator {
212 + public:
213 +    IntegratorCreator(const string& ident) : ident_(ident) {}
214 +
215 +    const string& getIdent() const { return ident_; }
216 +
217 +    virtual Integrator* create(SimInfo* info) const = 0;
218 +
219 + private:
220 +    string ident_;
221 + };
222 +
223 + template<class ConcreteIntegrator>
224 + class IntegratorBuilder : public IntegratorCreator {
225 + public:
226 +  IntegratorBuilder(const string& ident)
227 +                   : 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}
134 – The purpose of the Visitor Pattern is to encapsulate an operation
135 – that you want to perform on the elements of a data structure. In
136 – this way, you can change the operation being performed on a
137 – structure without the need of changing the classes of the elements
138 – that you are operating on.
235  
236 < \section{\label{appendixSection:concepts}Concepts}
236 > The visitor pattern is designed to decouple the data structure and
237 > algorithms used upon them by collecting related operation from
238 > element classes into other visitor classes, which is equivalent to
239 > adding virtual functions into a set of classes without modifying
240 > their interfaces. Fig.~\ref{appendixFig:visitorUML} demonstrates the
241 > structure of Visitor pattern which is used extensively in {\tt
242 > Dump2XYZ}. In order to convert an OOPSE dump file, a series of
243 > distinct operations are performed on different StuntDoubles (See the
244 > class hierarchy in Fig.~\ref{oopseFig:hierarchy} and the declaration
245 > in List.~\ref{appendixScheme:element}). Since the hierarchies
246 > remains stable, it is easy to define a visit operation (see
247 > List.~\ref{appendixScheme:visitor}) for each class of StuntDouble.
248 > Note that using Composite pattern\cite{Gamma1994}, CompositVisitor
249 > manages a priority visitor list and handles the execution of every
250 > visitor in the priority list on different StuntDoubles.
251  
252 < OOPSE manipulates both traditional atoms as well as some objects
253 < that {\it behave like atoms}.  These objects can be rigid
254 < collections of atoms or atoms which have orientational degrees of
255 < freedom.  Here is a diagram of the class heirarchy:
252 > \begin{figure}
253 > \centering
254 > \includegraphics[width=\linewidth]{visitor.eps}
255 > \caption[The UML class diagram of Visitor patten] {The UML class
256 > diagram of Visitor patten.} \label{appendixFig:visitorUML}
257 > \end{figure}
258  
259   %\begin{figure}
260   %\centering
261 < %\includegraphics[width=3in]{heirarchy.eps}
262 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
263 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
264 < %selection syntax allows the user to select any of the objects that
265 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
261 > %\includegraphics[width=\linewidth]{hierarchy.eps}
262 > %\caption[Class hierarchy for ojects in {\sc OOPSE}]{ A diagram of
263 > %the class hierarchy.
264 > %\begin{itemize}
265 > %\item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
266 > %integrators and minimizers.
267 > %\item An {\bf Atom} is a fundamental point-particle that can be moved around during a simulation.
268 > %\item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
269 > %\item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
270 > %DirectionalAtom}s which behaves as a single unit.
271 > %\end{itemize}
272 > %} \label{oopseFig:hierarchy}
273   %\end{figure}
274  
275 < \begin{itemize}
157 < \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
158 < integrators and minimizers.
159 < \item An {\bf Atom} is a fundamental point-particle that can be moved around during a simulation.
160 < \item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
161 < \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
162 < DirectionalAtom}s which behaves as a single unit.
163 < \end{itemize}
275 > \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
276  
277 < Every Molecule, Atom and DirectionalAtom in {\sc OOPSE} have their
278 < own names which are specified in the {\tt .md} file. In contrast,
279 < 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.
277 > class StuntDouble { public:
278 >  virtual void accept(BaseVisitor* v) = 0;
279 > };
280  
281 + class Atom: public StuntDouble { public:
282 +  virtual void accept{BaseVisitor* v*} {
283 +    v->visit(this);
284 +  }
285 + };
286 +
287 + class DirectionalAtom: public Atom { public:
288 +  virtual void accept{BaseVisitor* v*} {
289 +    v->visit(this);
290 +  }
291 + };
292 +
293 + class RigidBody: public StuntDouble { public:
294 +  virtual void accept{BaseVisitor* v*} {
295 +    v->visit(this);
296 +  }
297 + };
298 +
299 + \end{lstlisting}
300 +
301 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
302 +
303 + class BaseVisitor{
304 + public:
305 +  virtual void visit(Atom* atom);
306 +  virtual void visit(DirectionalAtom* datom);
307 +  virtual void visit(RigidBody* rb);
308 + };
309 +
310 + class BaseAtomVisitor:public BaseVisitor{ public:
311 +  virtual void visit(Atom* atom);
312 +  virtual void visit(DirectionalAtom* datom);
313 +  virtual void visit(RigidBody* rb);
314 + };
315 +
316 + class SSDAtomVisitor:public BaseAtomVisitor{ public:
317 +  virtual void visit(Atom* atom);
318 +  virtual void visit(DirectionalAtom* datom);
319 +  virtual void visit(RigidBody* rb);
320 + };
321 +
322 + class CompositeVisitor: public BaseVisitor {
323 + public:
324 +
325 +  typedef list<pair<BaseVisitor*, int> > VistorListType;
326 +  typedef VistorListType::iterator VisitorListIterator;
327 +  virtual void visit(Atom* atom) {
328 +    VisitorListIterator i;
329 +    BaseVisitor* curVisitor;
330 +    for(i = visitorList.begin();i != visitorList.end();++i) {
331 +      atom->accept(*i);
332 +    }
333 +  }
334 +
335 +  virtual void visit(DirectionalAtom* datom) {
336 +    VisitorListIterator i;
337 +    BaseVisitor* curVisitor;
338 +    for(i = visitorList.begin();i != visitorList.end();++i) {
339 +      atom->accept(*i);
340 +    }
341 +  }
342 +
343 +  virtual void visit(RigidBody* rb) {
344 +    VisitorListIterator i;
345 +    std::vector<Atom*> myAtoms;
346 +    std::vector<Atom*>::iterator ai;
347 +    myAtoms = rb->getAtoms();
348 +    for(i = visitorList.begin();i != visitorList.end();++i) {{
349 +      rb->accept(*i);
350 +      for(ai = myAtoms.begin(); ai != myAtoms.end(); ++ai){
351 +        (*ai)->accept(*i);
352 +    }
353 +  }
354 +
355 +  void addVisitor(BaseVisitor* v, int priority);
356 +
357 +  protected:
358 +    VistorListType visitorList;
359 + };
360 +
361 + \end{lstlisting}
362 +
363 + \section{\label{appendixSection:concepts}Concepts}
364 +
365 + OOPSE manipulates both traditional atoms as well as some objects
366 + that {\it behave like atoms}.  These objects can be rigid
367 + collections of atoms or atoms which have orientational degrees of
368 + freedom.  A diagram of the class hierarchy is illustrated in
369 + Fig.~\ref{oopseFig:hierarchy}. Every Molecule, Atom and
370 + DirectionalAtom in {\sc OOPSE} have their own names which are
371 + specified in the {\tt .md} file. In contrast, RigidBodies are
372 + denoted by their membership and index inside a particular molecule:
373 + [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
374 + on the specifics of the simulation). The names of rigid bodies are
375 + generated automatically. For example, the name of the first rigid
376 + body in a DMPC molecule is DMPC\_RB\_0.
377 +
378   \section{\label{appendixSection:syntax}Syntax of the Select Command}
379  
380 < The most general form of the select command is: {\tt select {\it
381 < expression}}. This expression represents an arbitrary set of
382 < StuntDoubles (Atoms or RigidBodies) in {\sc OOPSE}. Expressions are
383 < composed of either name expressions, index expressions, predefined
384 < sets, user-defined expressions, comparison operators, within
385 < expressions, or logical combinations of the above expression types.
386 < Expressions can be combined using parentheses and the Boolean
387 < operators.
380 > {\sc OOPSE} provides a powerful selection utility to select
381 > StuntDoubles. The most general form of the select command is:
382 >
383 > {\tt select {\it expression}}.
384 >
385 > This expression represents an arbitrary set of StuntDoubles (Atoms
386 > or RigidBodies) in {\sc OOPSE}. Expressions are composed of either
387 > name expressions, index expressions, predefined sets, user-defined
388 > expressions, comparison operators, within expressions, or logical
389 > combinations of the above expression types. Expressions can be
390 > combined using parentheses and the Boolean operators.
391  
392   \subsection{\label{appendixSection:logical}Logical expressions}
393  
# Line 502 | Line 710 | Dump2XYZ can transform an OOPSE dump file into a xyz f
710  
711   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
712  
713 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
714 < be opened by other molecular dynamics viewers such as Jmol and
715 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
716 < follows:
713 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
714 > which can be opened by other molecular dynamics viewers such as Jmol
715 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
716 > as follows:
717  
718  
719   \begin{longtable}[c]{|EFG|}
# Line 536 | Line 744 | The options available for Hydro are as follows:
744   \end{longtable}
745  
746   \subsection{\label{appendixSection:hydrodynamics}Hydro}
747 < The options available for Hydro are as follows:
747 >
748 > {\tt Hydro} can calculate resistance and diffusion tensors at the
749 > center of resistance. Both tensors at the center of diffusion can
750 > also be reported from the program, as well as the coordinates for
751 > the beads which are used to approximate the arbitrary shapes. The
752 > options available for Hydro are as follows:
753   \begin{longtable}[c]{|EFG|}
754   \caption{Hydrodynamics Command-line Options}
755   \\ \hline

Diff Legend

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