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 2835 by tim, Thu Jun 8 22:39:54 2006 UTC vs.
Revision 2839 by tim, Fri Jun 9 02:41:58 2006 UTC

# Line 113 | Line 113 | the modern scientific software applications, such as J
113   As one of the latest advanced techniques emerged from
114   object-oriented community, design patterns were applied in some of
115   the modern scientific software applications, such as JMol, {\sc
116 < OOPSE}\cite{Meineke05} and PROTOMOL\cite{Matthey05} \textit{etc}.
117 < The following sections enumerates some of the patterns used in {\sc
118 < OOPSE}.
116 > OOPSE}\cite{Meineke2005} and PROTOMOL\cite{Matthey2005}
117 > \textit{etc}. The following sections enumerates some of the patterns
118 > used in {\sc OOPSE}.
119  
120   \subsection{\label{appendixSection:singleton}Singleton}
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
# Line 127 | Line 128 | designs, such as lifespan control \textit{etc}, we onl
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}. {\tt IntegratorFactory} class
132 < is declared as
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 {
# Line 142 | Line 144 | class IntegratorFactory { (private)
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;
# Line 155 | Line 159 | IntegratorFactory* getInstance() {
159   }
160  
161   \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.
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}
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 < {\tt Integrator} class Parameterized Factory pattern where factory
178 < method ({\tt createIntegrator} member function) creates products
179 < based on the identifier (see
180 < List.~\ref{appendixScheme:factoryDeclaration}). If the identifier
181 < has been already registered, the factory method will invoke the
182 < corresponding creator (see List.~\ref{integratorCreator}) which
183 < 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}]
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;
# Line 199 | Line 205 | class IntegratorFactory { (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 {
# Line 226 | Line 233 | class IntegratorBuilder : public IntegratorCreator { (
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. 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 < Fig.~\ref{appendixFig:visitorUML} demonstrates the structure of
242 < Visitor pattern which is used extensively in {\tt Dump2XYZ}. In
243 < order to convert an OOPSE dump file, a series of distinct and
244 < unrelated operations are performed on different StuntDoubles.
245 < Visitor allows one to keep related operations together by packing
246 < them into one class. {\tt BaseAtomVisitor} is a typical example of
247 < visitor in {\tt Dump2XYZ} program{see
248 < List.~\ref{appendixScheme:visitor}}. In contrast to the operations,
249 < the object structure or element classes rarely change(See
250 < Fig.~\ref{oopseFig:heirarchy} and
244 < List.~\ref{appendixScheme:element}).
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  
246 –
252   \begin{figure}
253   \centering
254   \includegraphics[width=\linewidth]{visitor.eps}
# Line 251 | Line 256 | diagram of Visitor patten.} \label{appendixFig:visitor
256   diagram of Visitor patten.} \label{appendixFig:visitorUML}
257   \end{figure}
258  
259 < \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
259 > \begin{figure}
260 > \centering
261 > \includegraphics[width=\linewidth]{hierarchy.eps}
262 > \caption[Class hierarchy for ojects in {\sc OOPSE}]{ A diagram of
263 > the class hierarchy. } \label{oopseFig:hierarchy}
264 > \end{figure}
265  
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 –
266   \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
267  
268 < class StuntDouble {
274 < public:
268 > class StuntDouble { public:
269    virtual void accept(BaseVisitor* v) = 0;
270   };
271  
272 < class Atom: public StuntDouble {
279 < public:
272 > class Atom: public StuntDouble { public:
273    virtual void accept{BaseVisitor* v*} {
274      v->visit(this);
275    }
276   };
277  
278 < class DirectionalAtom: public Atom {
286 < public:
278 > class DirectionalAtom: public Atom { public:
279    virtual void accept{BaseVisitor* v*} {
280      v->visit(this);
281    }
282   };
283  
284 < class RigidBody: public StuntDouble {
293 < public:
284 > class RigidBody: public StuntDouble { public:
285    virtual void accept{BaseVisitor* v*} {
286      v->visit(this);
287 +  }
288 + };
289 +
290 + \end{lstlisting}
291 +
292 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
293 +
294 + class BaseVisitor{
295 + public:
296 +  virtual void visit(Atom* atom);
297 +  virtual void visit(DirectionalAtom* datom);
298 +  virtual void visit(RigidBody* rb);
299 + };
300 +
301 + class BaseAtomVisitor:public BaseVisitor{ public:
302 +  virtual void visit(Atom* atom);
303 +  virtual void visit(DirectionalAtom* datom);
304 +  virtual void visit(RigidBody* rb);
305 + };
306 +
307 + class SSDAtomVisitor:public BaseAtomVisitor{ public:
308 +  virtual void visit(Atom* atom);
309 +  virtual void visit(DirectionalAtom* datom);
310 +  virtual void visit(RigidBody* rb);
311 + };
312 +
313 + class CompositeVisitor: public BaseVisitor {
314 + public:
315 +
316 +  typedef list<pair<BaseVisitor*, int> > VistorListType;
317 +  typedef VistorListType::iterator VisitorListIterator;
318 +  virtual void visit(Atom* atom) {
319 +    VisitorListIterator i;
320 +    BaseVisitor* curVisitor;
321 +    for(i = visitorList.begin();i != visitorList.end();++i) {
322 +      atom->accept(*i);
323 +    }
324 +  }
325 +
326 +  virtual void visit(DirectionalAtom* datom) {
327 +    VisitorListIterator i;
328 +    BaseVisitor* curVisitor;
329 +    for(i = visitorList.begin();i != visitorList.end();++i) {
330 +      atom->accept(*i);
331 +    }
332 +  }
333 +
334 +  virtual void visit(RigidBody* rb) {
335 +    VisitorListIterator i;
336 +    std::vector<Atom*> myAtoms;
337 +    std::vector<Atom*>::iterator ai;
338 +    myAtoms = rb->getAtoms();
339 +    for(i = visitorList.begin();i != visitorList.end();++i) {{
340 +      rb->accept(*i);
341 +      for(ai = myAtoms.begin(); ai != myAtoms.end(); ++ai){
342 +        (*ai)->accept(*i);
343 +    }
344    }
345 +
346 +  void addVisitor(BaseVisitor* v, int priority);
347 +
348 +  protected:
349 +    VistorListType visitorList;
350   };
351  
352   \end{lstlisting}
# Line 303 | Line 356 | collections of atoms or atoms which have orientational
356   OOPSE manipulates both traditional atoms as well as some objects
357   that {\it behave like atoms}.  These objects can be rigid
358   collections of atoms or atoms which have orientational degrees of
359 < freedom.  A diagram of the class heirarchy is illustrated in
360 < Fig.~\ref{oopseFig:heirarchy}. Every Molecule, Atom and
359 > freedom.  A diagram of the class hierarchy is illustrated in
360 > Fig.~\ref{oopseFig:hierarchy}. Every Molecule, Atom and
361   DirectionalAtom in {\sc OOPSE} have their own names which are
362   specified in the {\tt .md} file. In contrast, RigidBodies are
363   denoted by their membership and index inside a particular molecule:
# Line 312 | Line 365 | body in a DMPC molecule is DMPC\_RB\_0.
365   on the specifics of the simulation). The names of rigid bodies are
366   generated automatically. For example, the name of the first rigid
367   body in a DMPC molecule is DMPC\_RB\_0.
368 < %\begin{figure}
369 < %\centering
370 < %\includegraphics[width=\linewidth]{heirarchy.eps}
371 < %\caption[Class heirarchy for ojects in {\sc OOPSE}]{ A diagram of
372 < %the class heirarchy.
373 < %\begin{itemize}
374 < %\item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
375 < %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}
368 > \begin{itemize}
369 > \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
370 > integrators and minimizers.
371 > \item An {\bf Atom} is a fundamental point-particle that can be moved around during a simulation.
372 > \item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
373 > \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
374 > DirectionalAtom}s which behaves as a single unit.
375 > \end{itemize}
376  
377   \section{\label{appendixSection:syntax}Syntax of the Select Command}
378  
379 < The most general form of the select command is: {\tt select {\it
380 < expression}}. This expression represents an arbitrary set of
381 < StuntDoubles (Atoms or RigidBodies) in {\sc OOPSE}. Expressions are
382 < composed of either name expressions, index expressions, predefined
383 < sets, user-defined expressions, comparison operators, within
384 < expressions, or logical combinations of the above expression types.
385 < Expressions can be combined using parentheses and the Boolean
386 < operators.
379 > {\sc OOPSE} provides a powerful selection utility to select
380 > StuntDoubles. The most general form of the select command is:
381 >
382 > {\tt select {\it expression}}.
383 >
384 > This expression represents an arbitrary set of StuntDoubles (Atoms
385 > or RigidBodies) in {\sc OOPSE}. Expressions are composed of either
386 > name expressions, index expressions, predefined sets, user-defined
387 > expressions, comparison operators, within expressions, or logical
388 > combinations of the above expression types. Expressions can be
389 > combined using parentheses and the Boolean operators.
390  
391   \subsection{\label{appendixSection:logical}Logical expressions}
392  

Diff Legend

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