- Building Blocks
- Model Presentations
SSS Utility Software
The SSS Utility Software is a collection of java classes organized by purpose
into several packages. These classes are very general in nature and have no
dependencies on any other SSS software. This makes these utility packages
very light weight and very easy to use by other projects. As with all
SSS software, the classes are not merely a collection of getters
and setters. That is, they do not just persist state, but also do
useful work for their clients. A pure object-oriented approach was followed
in the implementation of each of these packages.
The following are brief descriptions of the packages that comprise the
SSS Utility Software. For more details on a particular package, follow
the link to that package.
Classes related to general astronomical classes are found here.
Some examples of these are: EphemerisTable, PolarizationParameter,
A generic catalog construct. A Catalog holds a collection of
CatalogItems and, optionally, a collection of CatalogItemGroups.
A CatalogItemGroup also holds CatalogItems. For a retailer,
the group concept would be used for things like electronics,
furniture, sporting goods, etc. An item may belong to multiple
Clients may use a SimpleCatalog of objects in the same way they
would use one of the classes from java's Collections Framework
(List, Set, Map, etc.). A library, for example, might have
SimpleCatalog<Book>. Alternatively, clients may wish to
subclass the abstract catalog classes in order to specialize them.
In the SSS Model Software, these catalog classes are used to support
the SourceCatalog and ResourceCatalog concepts, which are in turn
used by the Source Catalog Tool (SCT) and Resource Catalog Tool (RCT).
Observers use these tools to access standard observatory catalogs
and to develop their own. Entries from these catalogs may then be
used in the Observation Preparation Tool (OPT).
Support for copy / paste operations.
Support for HyperText Markup Language reading and writing.
Mathematical concepts such as Polynomial and CubicSpline.
Measures and their units. This is probably the most important, and most
heavily used, package in this group. These classes relieve the model and
the applications of the burdens associated with handling measurements.
From the applications' viewpoints, the nicest feature of the measurements
is that they all know how to parse themselves from text in a variety of
units, and often in a variety of formats. They also know how to express
themselves as text, again, often in various formats.
A major feature of the measures classes is that they let client code
completely ignore units, if they so choose. For example, if client code
has an Angle, a1, from which another Angle, a2, must be subtracted, the
client does not have to care that a1 might be expressed in degrees and
a2 might be expressed in radians. The client merely tells a1 to subtract
from itself a2 (a1.subtract(a2)), and the Angle class has the
responsibility of making sure the units are taken into account. Of course,
should a client want to deal with the units, it can. All measures are
capable of converting themselves to other units
(a1.convertTo(ARC_MINUTE)), and of expressing their values in other
units without actually converting themselves internally
(double arcMin = a1.toUnits(ARC_MINUTE)).
Many of the measures classes have corresponding range, or interval, classes.
For example, there is both a Frequency class and a FrequencyRange class.
The range classes have the same parsing and text expression abilities as
their corresponding primitive classes, but they also add a lot more functionality.
Most ranges can test for overlap, containment, and contiguousness with another
range. They can also be interesected and merged with another range.
The goal, as always, is to provide services to clients without forcing those
clients to get themselves dirty with the details.
Support for sorting collections. The main focus of this package is to
help support sorting where multiple keys (primary, secondary, etc.)
are needed. The CompoundComparator is the class that handles the
multiple-keys concept. The other classes provide support for how
each key should behave. Should a given key sort in an ascending,
descending, or custom order? If text is being sorted, should the
comparison be case-sensitive?
A catch-all for useful objects that do not belong to one of the other
packages. We often move things out of this package and into one of their
own, once we have enough to warrant separation. (This is how the math
package was born.)
A framework for checking the internal consistency of an object.
Unlike the situation with the SSS Model classes, the Utility classes tend to be
related to very few other classes. For this reason there is not much utility to
producing diagrams for these classes. There are, however, a few places where such
diagrams add value, and these are given below:
- SkyPosition and Its Implementations
- Simplest Implementation
- Ephemeris Table Implementation
- Orbital Elements Implementation
- Internal Ephemeris Implementation
- Polynomial Implementation
- Table of Polynomials Implementation
- Polynomial Position: Use of Polynomial Class
- Validation Package
- Validation Failure
- Creating an EphemerisTable from a JPL File
The application programmers' interface for all utility classes may be seen by
going to the
The source code for the classes of these packages, the test classes written
for them, and all other supporting files are held in a
(user name and password required).
Various versions of the
jar files that contain the compiled classes that correspond
to this documentation may be found in the
As mentioned in the Introduction, the SSS Utility Software classes are
dependent on no other SSS software. There are some dependencies, though,
on third party software, such as Apache's log4j, Sun's JAXB 2.0, and
(for the test classes only) JUnit.
The full set of dependencies may be found in the
pom.xml file that we use in our Maven 2 build process.
Various versions of these may be found in the
Friday, 08-May-2009 08:18:02 MDT