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 2835 by tim, Thu Jun 8 22:39:54 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)] The declaration of of simple Singleton pattern.},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)] The implementation of simple Singleton pattern.},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 + {\tt Integrator} class Parameterized Factory pattern where factory
173 + method ({\tt createIntegrator} member function) creates products
174 + based on the identifier (see
175 + List.~\ref{appendixScheme:factoryDeclaration}). If the identifier
176 + has been already registered, the factory method will invoke the
177 + corresponding creator (see List.~\ref{integratorCreator}) which
178 + utilizes the modern C++ template technique to avoid subclassing.
179 + \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of {\tt IntegratorFactory} class.},label={appendixScheme:factoryDeclaration}]
180 +
181 + class IntegratorFactory {
182 + public:
183 +  typedef std::map<string, IntegratorCreator*> CreatorMapType;
184 +
185 +  bool registerIntegrator(IntegratorCreator* creator) {
186 +    return creatorMap_.insert(creator->getIdent(), creator).second;
187 +  }
188 +
189 +  Integrator* createIntegrator(const string& id, SimInfo* info) {
190 +    Integrator* result = NULL;
191 +    CreatorMapType::iterator i = creatorMap_.find(id);
192 +    if (i != creatorMap_.end()) {
193 +      result = (i->second)->create(info);
194 +    }
195 +    return result;
196 +  }
197 +
198 + private:
199 +  CreatorMapType creatorMap_;
200 + };
201 + \end{lstlisting}
202 + \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (III)]Source code of creator classes.},label={appendixScheme:integratorCreator}]
203 +
204 + class IntegratorCreator {
205 + public:
206 +    IntegratorCreator(const string& ident) : ident_(ident) {}
207 +
208 +    const string& getIdent() const { return ident_; }
209 +
210 +    virtual Integrator* create(SimInfo* info) const = 0;
211 +
212 + private:
213 +    string ident_;
214 + };
215 +
216 + template<class ConcreteIntegrator>
217 + class IntegratorBuilder : public IntegratorCreator {
218 + public:
219 +  IntegratorBuilder(const string& ident)
220 +                   : IntegratorCreator(ident) {}
221 +  virtual  Integrator* create(SimInfo* info) const {
222 +    return new ConcreteIntegrator(info);
223 +  }
224 + };
225 + \end{lstlisting}
226 +
227   \subsection{\label{appendixSection:visitorPattern}Visitor}
228 +
229   The purpose of the Visitor Pattern is to encapsulate an operation
230 < that you want to perform on the elements of a data structure. In
231 < this way, you can change the operation being performed on a
232 < structure without the need of changing the classes of the elements
233 < that you are operating on.
230 > that you want to perform on the elements. The operation being
231 > performed on a structure can be switched without changing the
232 > interfaces of the elements. In other words, one can add virtual
233 > functions into a set of classes without modifying their interfaces.
234 > Fig.~\ref{appendixFig:visitorUML} demonstrates the structure of
235 > Visitor pattern which is used extensively in {\tt Dump2XYZ}. In
236 > order to convert an OOPSE dump file, a series of distinct and
237 > unrelated operations are performed on different StuntDoubles.
238 > Visitor allows one to keep related operations together by packing
239 > them into one class. {\tt BaseAtomVisitor} is a typical example of
240 > visitor in {\tt Dump2XYZ} program{see
241 > List.~\ref{appendixScheme:visitor}}. In contrast to the operations,
242 > the object structure or element classes rarely change(See
243 > Fig.~\ref{oopseFig:heirarchy} and
244 > List.~\ref{appendixScheme:element}).
245  
246 +
247 + \begin{figure}
248 + \centering
249 + \includegraphics[width=\linewidth]{visitor.eps}
250 + \caption[The UML class diagram of Visitor patten] {The UML class
251 + diagram of Visitor patten.} \label{appendixFig:visitorUML}
252 + \end{figure}
253 +
254 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
255 +
256 + class BaseVisitor{
257 + public:
258 +  virtual void visit(Atom* atom);
259 +  virtual void visit(DirectionalAtom* datom);
260 +  virtual void visit(RigidBody* rb);
261 + };
262 +
263 + class BaseAtomVisitor:public BaseVisitor{ public:
264 +  virtual void visit(Atom* atom);
265 +  virtual void visit(DirectionalAtom* datom);
266 +  virtual void visit(RigidBody* rb);
267 + };
268 +
269 + \end{lstlisting}
270 +
271 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
272 +
273 + class StuntDouble {
274 + public:
275 +  virtual void accept(BaseVisitor* v) = 0;
276 + };
277 +
278 + class Atom: public StuntDouble {
279 + public:
280 +  virtual void accept{BaseVisitor* v*} {
281 +    v->visit(this);
282 +  }
283 + };
284 +
285 + class DirectionalAtom: public Atom {
286 + public:
287 +  virtual void accept{BaseVisitor* v*} {
288 +    v->visit(this);
289 +  }
290 + };
291 +
292 + class RigidBody: public StuntDouble {
293 + public:
294 +  virtual void accept{BaseVisitor* v*} {
295 +    v->visit(this);
296 +  }
297 + };
298 +
299 + \end{lstlisting}
300 +
301   \section{\label{appendixSection:concepts}Concepts}
302  
303   OOPSE manipulates both traditional atoms as well as some objects
304   that {\it behave like atoms}.  These objects can be rigid
305   collections of atoms or atoms which have orientational degrees of
306 < freedom.  Here is a diagram of the class heirarchy:
307 <
306 > freedom.  A diagram of the class heirarchy is illustrated in
307 > Fig.~\ref{oopseFig:heirarchy}. Every Molecule, Atom and
308 > DirectionalAtom in {\sc OOPSE} have their own names which are
309 > specified in the {\tt .md} file. In contrast, RigidBodies are
310 > denoted by their membership and index inside a particular molecule:
311 > [MoleculeName]\_RB\_[index] (the contents inside the brackets depend
312 > on the specifics of the simulation). The names of rigid bodies are
313 > generated automatically. For example, the name of the first rigid
314 > body in a DMPC molecule is DMPC\_RB\_0.
315   %\begin{figure}
316   %\centering
317 < %\includegraphics[width=3in]{heirarchy.eps}
318 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
319 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
320 < %selection syntax allows the user to select any of the objects that
321 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
317 > %\includegraphics[width=\linewidth]{heirarchy.eps}
318 > %\caption[Class heirarchy for ojects in {\sc OOPSE}]{ A diagram of
319 > %the class heirarchy.
320 > %\begin{itemize}
321 > %\item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
322 > %integrators and minimizers.
323 > %\item An {\bf Atom} is a fundamental point-particle that can be moved around during a simulation.
324 > %\item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
325 > %\item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
326 > %DirectionalAtom}s which behaves as a single unit.
327 > %\end{itemize}
328 > %} \label{oopseFig:heirarchy}
329   %\end{figure}
330  
156 – \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}
164 –
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 –
331   \section{\label{appendixSection:syntax}Syntax of the Select Command}
332  
333   The most general form of the select command is: {\tt select {\it
# Line 502 | Line 660 | The options available for DynamicProps are as follows:
660  
661   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
662  
663 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
664 < be opened by other molecular dynamics viewers such as Jmol and
665 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
666 < follows:
663 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
664 > which can be opened by other molecular dynamics viewers such as Jmol
665 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
666 > as follows:
667  
668  
669   \begin{longtable}[c]{|EFG|}
# Line 536 | Line 694 | converted. \\
694   \end{longtable}
695  
696   \subsection{\label{appendixSection:hydrodynamics}Hydro}
697 < The options available for Hydro are as follows:
697 >
698 > {\tt Hydro} can calculate resistance and diffusion tensors at the
699 > center of resistance. Both tensors at the center of diffusion can
700 > also be reported from the program, as well as the coordinates for
701 > the beads which are used to approximate the arbitrary shapes. The
702 > options available for Hydro are as follows:
703   \begin{longtable}[c]{|EFG|}
704   \caption{Hydrodynamics Command-line Options}
705   \\ \hline

Diff Legend

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