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 2824 by tim, Thu Jun 8 15:44:14 2006 UTC vs.
Revision 2837 by tim, Fri Jun 9 02:20:39 2006 UTC

# Line 118 | Line 118 | The Singleton pattern not only provides a mechanism to
118   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 | static data approach in {\sc OOPSE}. {\tt IntegratorFa
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
132 < \begin{lstlisting}[float,caption={[A classic Singleton design pattern implementation(I)] Declaration of {\tt IntegratorFactory} class.},label={appendixScheme:singletonDeclaration}]
131 > static data approach in {\sc OOPSE}. IntegratorFactory class is
132 > declared as
133  
134 <  class IntegratorFactory {
135 <    public:
136 <      static IntegratorFactory* getInstance();
137 <    protected:
138 <      IntegratorFactory();
139 <    private:
140 <      static IntegratorFactory* instance_;
141 <  };
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
144 – \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}]
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() {
# Line 151 | Line 157 | IntegratorFactory* getInstance() {
157    }
158    return instance_;
159   }
160 +
161   \end{lstlisting}
155 – Since constructor is declared as {\tt protected}, a client can not
156 – instantiate {\tt IntegratorFactory} directly. Moreover, since the
157 – member function {\tt getInstance} serves as the only entry of access
158 – to {\tt IntegratorFactory}, this approach fulfills the basic
159 – requirement, a single instance. Another consequence of this approach
160 – is the automatic destruction since static data are destroyed upon
161 – 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 + 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 < Registers a creator with a type identifier. Looks up the type
171 < identifier in the internal map. If it is found, it invokes the
172 < corresponding creator for the type identifier and returns its
173 < result.
174 < \begin{lstlisting}[float,caption={[The implementation of Factory pattern (I)].},label={appendixScheme:factoryDeclaration}]
175 <  class IntegratorCreator;
176 <  class IntegratorFactory {
177 <    public:
178 <      typedef std::map<string, IntegratorCreator*> CreatorMapType;
185 > \begin{lstlisting}[float,caption={[The implementation of Parameterized Factory pattern (I)]Source code of IntegratorFactory class.},label={appendixScheme:factoryDeclaration}]
186  
187 <      bool registerIntegrator(IntegratorCreator* creator);
187 > class IntegratorFactory {
188 > public:
189 >  typedef std::map<string, IntegratorCreator*> CreatorMapType;
190  
191 <      Integrator* createIntegrator(const string& id, SimInfo* info);
192 <
184 <    private:
185 <      CreatorMapType creatorMap_;
186 <  };
187 < \end{lstlisting}
188 <
189 < \begin{lstlisting}[float,caption={[The implementation of Factory pattern (II)].},label={appendixScheme:factoryDeclarationImplementation}]
190 <  bool IntegratorFactory::unregisterIntegrator(const string& id) {
191 <    return creatorMap_.erase(id) == 1;
191 >  bool registerIntegrator(IntegratorCreator* creator) {
192 >    return creatorMap_.insert(creator->getIdent(), creator).second;
193    }
194  
195 <  Integrator*
196 <  IntegratorFactory::createIntegrator(const string& id, SimInfo* info) {
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 <      //invoke functor to create object
199 <      return (i->second)->create(info);
200 <    } else {
201 <      return NULL;
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 Factory pattern (III)].},label={appendixScheme:integratorCreator}]
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:
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:
219 > private:
220      string ident_;
221 <  };
221 > };
222  
223 <  template<class ConcreteIntegrator>
224 <  class IntegratorBuilder : public IntegratorCreator {
225 <  public:
226 <    IntegratorBuilder(const string& ident) : IntegratorCreator(ident) {}
227 <    virtual  Integrator* create(SimInfo* info) const {
228 <      return new ConcreteIntegrator(info);
229 <    }
230 <  };
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}
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 < 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.
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   \begin{figure}
253   \centering
254 < \includegraphics[width=\linewidth]{architecture.eps}
255 < \caption[The architecture of {\sc OOPSE}] {Overview of the structure
256 < of {\sc OOPSE}} \label{appendixFig:visitorUML}
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{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
260 <  class BaseVisitor{
261 <    public:
262 <      virtual void visit(Atom* atom);
263 <      virtual void visit(DirectionalAtom* datom);
264 <      virtual void visit(RigidBody* rb);
265 <  };
266 < \end{lstlisting}
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.
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{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
259 –  class StuntDouble {
260 –    public:
261 –      virtual void accept(BaseVisitor* v) = 0;
262 –  };
276  
277 <  class Atom: public StuntDouble {
278 <    public:
279 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
267 <  };
277 > class StuntDouble { public:
278 >  virtual void accept(BaseVisitor* v) = 0;
279 > };
280  
281 <  class DirectionalAtom: public Atom {
282 <    public:
283 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
284 <  };
281 > class Atom: public StuntDouble { public:
282 >  virtual void accept{BaseVisitor* v*} {
283 >    v->visit(this);
284 >  }
285 > };
286  
287 <  class RigidBody: public StuntDouble {
288 <    public:
289 <      virtual void accept{BaseVisitor* v*} {v->visit(this);}
290 <  };
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.  Here is a diagram of the class heirarchy:
369 <
370 < %\begin{figure}
371 < %\centering
372 < %\includegraphics[width=3in]{heirarchy.eps}
373 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
374 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
375 < %selection syntax allows the user to select any of the objects that
376 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
294 < %\end{figure}
295 <
296 < \begin{itemize}
297 < \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
298 < integrators and minimizers.
299 < \item An {\bf Atom} is a fundamental point-particle that can be moved around during a simulation.
300 < \item A {\bf DirectionalAtom} is an atom which has {\it orientational} as well as translational degrees of freedom.
301 < \item A {\bf RigidBody} is a collection of {\bf Atom}s or {\bf
302 < DirectionalAtom}s which behaves as a single unit.
303 < \end{itemize}
304 <
305 < Every Molecule, Atom and DirectionalAtom in {\sc OOPSE} have their
306 < own names which are specified in the {\tt .md} file. In contrast,
307 < RigidBodies are denoted by their membership and index inside a
308 < particular molecule: [MoleculeName]\_RB\_[index] (the contents
309 < inside the brackets depend on the specifics of the simulation). The
310 < names of rigid bodies are generated automatically. For example, the
311 < name of the first rigid body in a DMPC molecule is DMPC\_RB\_0.
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
317 < StuntDoubles (Atoms or RigidBodies) in {\sc OOPSE}. Expressions are
318 < composed of either name expressions, index expressions, predefined
319 < sets, user-defined expressions, comparison operators, within
320 < expressions, or logical combinations of the above expression types.
321 < Expressions can be combined using parentheses and the Boolean
322 < 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  
394   The logical operators allow complex queries to be constructed out of

Diff Legend

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