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 2815 by tim, Wed Jun 7 18:34:05 2006 UTC vs.
Revision 2826 by tim, Thu Jun 8 19:54:33 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 > 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* getInstance();
137 +    protected:
138 +      IntegratorFactory();
139 +    private:
140 +      static IntegratorFactory* instance_;
141 + };
142 +
143 + \end{lstlisting}
144 + The corresponding implementation is
145 + \begin{lstlisting}[float,caption={[A classic implementation of Singleton design pattern (II)] Implementation of {\tt IntegratorFactory} class.},label={appendixScheme:singletonImplementation}]
146 +
147 + IntegratorFactory::instance_ = NULL;
148 +
149 + IntegratorFactory* getInstance() {
150 +  if (instance_ == NULL){
151 +    instance_ = new IntegratorFactory;
152 +  }
153 +  return instance_;
154 + }
155 +
156 + \end{lstlisting}
157 + Since constructor is declared as {\tt protected}, a client can not
158 + instantiate {\tt IntegratorFactory} directly. Moreover, since the
159 + member function {\tt getInstance} serves as the only entry of access
160 + to {\tt IntegratorFactory}, this approach fulfills the basic
161 + requirement, a single instance. Another consequence of this approach
162 + is the automatic destruction since static data are destroyed upon
163 + program termination.
164 +
165   \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.
166  
167 + Categoried as a creational pattern, the Factory Method pattern deals
168 + with the problem of creating objects without specifying the exact
169 + class of object that will be created. Factory Method is typically
170 + implemented by delegating the creation operation to the subclasses.
171 +
172 + Registers a creator with a type identifier. Looks up the type
173 + identifier in the internal map. If it is found, it invokes the
174 + corresponding creator for the type identifier and returns its
175 + result.
176 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (I)].},label={appendixScheme:factoryDeclaration}]
177 +
178 + class IntegratorFactory {
179 +  public:
180 +    typedef std::map<string, IntegratorCreator*> CreatorMapType;
181 +
182 +    bool registerIntegrator(IntegratorCreator* creator);
183 +
184 +    Integrator* createIntegrator(const string& id, SimInfo* info);
185 +
186 +  private:
187 +    CreatorMapType creatorMap_;
188 + };
189 +
190 + \end{lstlisting}
191 +
192 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (II)].},label={appendixScheme:factoryDeclarationImplementation}]
193 +
194 + bool IntegratorFactory::unregisterIntegrator(const string& id) {
195 +  return creatorMap_.erase(id) == 1;
196 + }
197 +
198 + Integrator* IntegratorFactory::createIntegrator(const string& id,
199 +                                                SimInfo* info) {
200 +  CreatorMapType::iterator i = creatorMap_.find(id);
201 +  if (i != creatorMap_.end()) {
202 +    return (i->second)->create(info);
203 +  } else {
204 +    return NULL;
205 +  }
206 + }
207 +
208 + \end{lstlisting}
209 +
210 + \begin{lstlisting}[float,caption={[The implementation of Factory pattern (III)].},label={appendixScheme:integratorCreator}]
211 +
212 + class IntegratorCreator {
213 +  public:
214 +    IntegratorCreator(const string& ident) : ident_(ident) {}
215 +
216 +    const string& getIdent() const { return ident_; }
217 +
218 +    virtual Integrator* create(SimInfo* info) const = 0;
219 +
220 +  private:
221 +    string ident_;
222 + };
223 +
224 + template<class ConcreteIntegrator>
225 + class IntegratorBuilder : public IntegratorCreator {
226 +  public:
227 +    IntegratorBuilder(const string& ident) : 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 of a data structure. In
238 < this way, you can change the operation being performed on a
239 < structure without the need of changing the classes of the elements
240 < that you are operating on.
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.
245  
246 + \begin{figure}
247 + \centering
248 + \includegraphics[width=\linewidth]{visitor.eps}
249 + \caption[The architecture of {\sc OOPSE}] {Overview of the structure
250 + of {\sc OOPSE}} \label{appendixFig:visitorUML}
251 + \end{figure}
252 +
253 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (I)]Source code of the visitor classes.},label={appendixScheme:visitor}]
254 +
255 + class BaseVisitor{
256 +  public:
257 +    virtual void visit(Atom* atom);
258 +    virtual void visit(DirectionalAtom* datom);
259 +    virtual void visit(RigidBody* rb);
260 + };
261 +
262 + \end{lstlisting}
263 +
264 + \begin{lstlisting}[float,caption={[The implementation of Visitor pattern (II)]Source code of the element classes.},label={appendixScheme:element}]
265 +
266 + class StuntDouble {
267 +  public:
268 +    virtual void accept(BaseVisitor* v) = 0;
269 + };
270 +
271 + class Atom: public StuntDouble {
272 +  public:
273 +    virtual void accept{BaseVisitor* v*} {
274 +      v->visit(this);
275 +    }
276 + };
277 +
278 + class DirectionalAtom: public Atom {
279 +  public:
280 +    virtual void accept{BaseVisitor* v*} {
281 +      v->visit(this);
282 +    }
283 + };
284 +
285 + class RigidBody: public StuntDouble {
286 +  public:
287 +    virtual void accept{BaseVisitor* v*} {
288 +      v->visit(this);
289 +    }
290 + };
291 +
292 + \end{lstlisting}
293   \section{\label{appendixSection:concepts}Concepts}
294  
295   OOPSE manipulates both traditional atoms as well as some objects
# Line 144 | Line 297 | freedom.  Here is a diagram of the class heirarchy:
297   collections of atoms or atoms which have orientational degrees of
298   freedom.  Here is a diagram of the class heirarchy:
299  
300 < %\begin{figure}
301 < %\centering
302 < %\includegraphics[width=3in]{heirarchy.eps}
303 < %\caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
304 < %The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
305 < %selection syntax allows the user to select any of the objects that
306 < %are descended from a StuntDouble.} \label{oopseFig:heirarchy}
307 < %\end{figure}
300 > \begin{figure}
301 > \centering
302 > \includegraphics[width=3in]{heirarchy.eps}
303 > \caption[Class heirarchy for StuntDoubles in {\sc oopse}-3.0]{ \\
304 > The class heirarchy of StuntDoubles in {\sc oopse}-3.0. The
305 > selection syntax allows the user to select any of the objects that
306 > are descended from a StuntDouble.} \label{oopseFig:heirarchy}
307 > \end{figure}
308  
309   \begin{itemize}
310   \item A {\bf StuntDouble} is {\it any} object that can be manipulated by the
# Line 377 | Line 530 | Fig.~\ref{oopseFig:staticPropsProcess}.
530   \centering
531   \includegraphics[width=\linewidth]{staticPropsProcess.eps}
532   \caption[A representation of the three-stage correlations in
533 < \texttt{StaticProps}]{Three-stage processing in
534 < \texttt{StaticProps}. $S_1$ and $S_2$ are the numbers of selected
535 < stuntdobules from {\tt -{}-sele1} and {\tt -{}-sele2} respectively,
536 < while $C$ is the number of stuntdobules appearing at both sets. The
537 < first stage($S_1-C$ and $S_2$) and second stages ($S_1$ and $S_2-C$)
538 < are completely non-overlapping. On the contrary, the third stage($C$
539 < and $C$) are completely overlapping}
540 < \label{oopseFig:staticPropsProcess}
533 > \texttt{StaticProps}]{This diagram illustrates three-stage
534 > processing used by \texttt{StaticProps}. $S_1$ and $S_2$ are the
535 > numbers of selected stuntdobules from {\tt -{}-sele1} and {\tt
536 > -{}-sele2} respectively, while $C$ is the number of stuntdobules
537 > appearing at both sets. The first stage($S_1-C$ and $S_2$) and
538 > second stages ($S_1$ and $S_2-C$) are completely non-overlapping. On
539 > the contrary, the third stage($C$ and $C$) are completely
540 > overlapping} \label{oopseFig:staticPropsProcess}
541   \end{figure}
542  
543   The options available for {\tt StaticProps} are as follows:
# Line 462 | Line 615 | incremented, until all frame pairs have been correlate
615   incremented and the process repeated until the end of the
616   trajectory. Once the end is reached, the first block is freed then
617   incremented, until all frame pairs have been correlated in time.
618 + This process is illustrated in
619 + Fig.~\ref{oopseFig:dynamicPropsProcess}.
620  
621 + \begin{figure}
622 + \centering
623 + \includegraphics[width=\linewidth]{dynamicPropsProcess.eps}
624 + \caption[A representation of the block correlations in
625 + \texttt{dynamicProps}]{This diagram illustrates block correlations
626 + processing in \texttt{dynamicProps}. The shaded region represents
627 + the self correlation of the block, and the open blocks are read one
628 + at a time and the cross correlations between blocks are calculated.}
629 + \label{oopseFig:dynamicPropsProcess}
630 + \end{figure}
631 +
632   The options available for DynamicProps are as follows:
633   \begin{longtable}[c]{|EFG|}
634   \caption{DynamicProps Command-line Options}
# Line 489 | Line 655 | Dump2XYZ can transform an OOPSE dump file into a xyz f
655  
656   \subsection{\label{appendixSection:Dump2XYZ}Dump2XYZ}
657  
658 < Dump2XYZ can transform an OOPSE dump file into a xyz file which can
659 < be opened by other molecular dynamics viewers such as Jmol and
660 < VMD\cite{Humphrey1996}. The options available for Dump2XYZ are as
661 < follows:
658 > {\tt Dump2XYZ} can transform an OOPSE dump file into a xyz file
659 > which can be opened by other molecular dynamics viewers such as Jmol
660 > and VMD\cite{Humphrey1996}. The options available for Dump2XYZ are
661 > as follows:
662  
663  
664   \begin{longtable}[c]{|EFG|}
# Line 523 | Line 689 | The options available for Hydro are as follows:
689   \end{longtable}
690  
691   \subsection{\label{appendixSection:hydrodynamics}Hydro}
692 < The options available for Hydro are as follows:
692 >
693 > {\tt Hydro} can calculate resistance and diffusion tensors at the
694 > center of resistance. Both tensors at the center of diffusion can
695 > also be reported from the program, as well as the coordinates for
696 > the beads which are used to approximate the arbitrary shapes. The
697 > options available for Hydro are as follows:
698   \begin{longtable}[c]{|EFG|}
699   \caption{Hydrodynamics Command-line Options}
700   \\ \hline

Diff Legend

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