Next: The Stellar Spectra Acquisition, Reduction, and Archiving Systems at the Ondejov Observatory 2-meter Telescope
Up: Software Applications
Previous: Redesign and Reimplementation of XSPEC
Table of Contents -
Subject Index -
Author Index -
Search -
PS reprint -
PDF reprint
Wolk, N. RA. 2001, in ASP Conf. Ser., Vol. 238, Astronomical Data Analysis Software and Systems X, eds. F. R. Harnden, Jr., F. A. Primini, & H. E. Payne (San Francisco: ASP), 419
A Flexible Object Oriented Design for Page Formating
Nancy R. Adams-Wolk
Harvard-Smithsonian Center for Astrophysics, Cambridge MA, 02138
Abstract:
The
Chandra standard data processing now includes a group of
summary pages that offer a synopsis of the observation.
Chandra's instrument and grating combinations form many different spacecraft configurations.
For each configuration, a specific summary of the observation is
required. We need a flexible and expandable page formatter to handle
this situation.
One result of this development is the
sum_format_page
tool. This C++ tool is built on object oriented design principles and
constrain the flexibility to produce multiple output file formats. Here we discuss the
motivations for the tool, the design and implementation, and future
enhancements that need to be considered.
The Chandra X-ray Observatory provides two science
instruments, a transmission grating, and multiple spacecraft configurations
for observers to explore the X-ray universe.
The cost of the convenience to the observers
is the challenge of developing software
that can process these data with minimal human intervention.
Chandra's Standard Data Processing now creates a data product
that summarizes the observation for the principal investigator. The
software written for this task needs to be configurable, and fairly
simple to update when there are changes in spacecraft operations or
enhancement requests. One component of this software is the sum_format_page
tool. This C++ tool is designed to work with the configurable nature
of the summary package.
Since this tool is a portion of a larger suite, we need to look at the
specifications for the entire package. The specification process for
an observation summary product can be subjective. Each scientist has
their own view of what data are important
and how these data should be presented.
The specification process for the summary products involves polling
several scientists for their opinion of what the summary of an observation
should contain.
The design is based on the items that most scientists
want; images, details of the instrument and observing setup, sources, and
a quick extracted spectrum if the observation included a grating.
Finally, all tools we write need to conform to the Chandra X-ray Center
Data System (CXCDS) standards.
The result of our discussions with scientists set up the initial
requirements. To control the arrangement of the items,
we employ an ASCII layout template. The main document classes are
designed around this template. Figure 1 displays the
relationships between the major document classes.
Each row of the layout template represents an item. Items are the
input information from which a document is created. An item contains
information about the specific input formats and can be written in
all valid output formats.
The row class contains items. We allow multiple items
in a row instead of implementing a column class. Since the user may want
separate pages, rows are stored in pages and the pages are stored in
the document. The main function of the program reads the template then
populates the document and writes the document in the requested
format.
Each specific section of the design is programmed as a class. Here we
discuss the basic design of the major classes.
Figure 1:
The relationship between the main document classes
 |
Two classes work to parse and store the ASCII layout template.
The first class, sumTemplateReader, reads each line in
the template, passing then to a new instance
of the sumTemplateLine. This class parses the line and stores
the item size, type, title, and file information within the class.
Each sumTemplateLine is returned and stored in standard template Vector
in the sumTemplateReader class.
The ASCII template format allows the user to customize the
document arrangement. Each line describes the item type, size,
position within the row, an optional title, and the file that
contains the item.
The sumTemplateReader is passed back to the main to be used in the
document class.
The document is built from the sumTemplateReader class. The document
class only contains methods to populate itself,
check the physical sizes to ensure it will fit on a hardcopy, and
write itself to a file. In populating the document, the layout
template is read and each page in the document is filled by creating
the rows and items to be used in the document.
Each row of the document can contain multiple items which allows for
columns, with the caveat that the row size cannot exceed the page size
for hardcopy formats. The row is responsible for creating the
individual item classes and stores the resulting objects in a vector.
Items are the specific inputs to the document. Some are predefined in the
source code, such as a horizontal line. Other items are stored in
files that are inserted into the document.
A figure is an example of this type of item. Figures
are expected to be in the correct format for the requested output.
For the LATEX
format, this is PostScript or Encapsulated PostScript. In the case of
an HTML output, the format can be any graphic type allowed in HTML.
The currently available input types are lines, new rows, new pages,
figures, embedded files, links and table of contents (TOC).
Embedded types are files that
are in the format of the output file. These are copied verbatim
from the source to the output file. The links and TOC items are only
used in the HTML format to allow links to other documents and to
create local links between the pages and items.
The item classes utilize the polymorphic nature of C++.
The item classes are all derived from a singular base
class. This class contains virtual functions for writing the outputs
in the different formats. The goal of this design is to have the row
iterate over its container, writing each item without having to know
its type. This design has worked well so far, but
recent design discussions have suggested another method of handling
item classes as detailed below.
One of the design goals of the sum_format_page is to make
enhancements and upgrades fairly simple. The input formats and file
types may change in the future as well as the output formats.
For these reasons, the design is flexible enough to simply handle
changes to the input and output formats if there are new requirements.
If a new input type or file is needed, the code can be modified to accept new
formats. The changes are fairly well contained.
A new item class will need to be defined that is derived from the
sumPageItem base class. This class will need all of the virtual
functions that are defined in the base class. Once the
class is written, the sumTemplateLine will need a new identifier in
the enumeration of the item types, the ASCII template will need a new
identifier to specify the type, and the row class will need to be updated
with the new item class to be filled.
At the ADASS X meeting, Ben Dorman (private communication) suggested
using a registry to store the input types. Any future upgrades would
involve a change in the registry and overloading of
functions instead of creating a new class. This is incorporated in the
redesign of XSPEC (Dorman et al. 2001) and merits future exploration.
The current output formats may become obsolete in time and
a new set of output formats will be needed. In this case,
the changes involve adding new functions to write the output format
to each of the item classes and the base item class. The parameter
file will need to be updated to accept the new format as a valid
parameter.
The summary package is a powerful set of tools used in the standard
data processing to create the summary data product distributed to
Chandra observers. It could not have been possible without the
flexibility of the sum_format_page tool. While discussions
have shown that we can make the tool even easier to upgrade with
future input types, the current design is robust and works well with the
multiple templates used in standard data processing.
We expect this tool, and the other tools in the summary package suite,
to be used for the remainder of the mission with only minor
updates. New configurations of the telescope can be handled with
changes in building the ascii layout templates, while new data formats can be added by
updating the sum_format_page tool.
The author would like to thank Douglas McElroy and Kenny Glotfelty for
assistance and discussions in the design phase of this project.
This work was funded by the Chandra X-Ray Center NASA contract
NAS8-39073.
References
Dorman, B. & Arnaud, K. 2001,
this volume, 415
© Copyright 2001 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA
Next: The Stellar Spectra Acquisition, Reduction, and Archiving Systems at the Ondejov Observatory 2-meter Telescope
Up: Software Applications
Previous: Redesign and Reimplementation of XSPEC
Table of Contents -
Subject Index -
Author Index -
Search -
PS reprint -
PDF reprint
adass-editors@head-cfa.harvard.edu