SSA Software Documentation
This document describes the software written by the Scientific Support Systems (SSS) Team for the Expanded Very Large Array (EVLA
) Project. Its focus is on the design of the software, the application programmers' interfaces (APIs), the locations of the source code and associated documentation, and pre-release versions of the applications. This document contains:
- High level descriptions of the large scale breakdown of the software
- Unified Modeling Language (UML) diagrams
- Application programmer interfaces
- Links to source code repositories
- Links to web applications
- Compiled libraries in the form of java archive files
- A link to the SSS issue tracking site
The main audience for these documents is EVLA
software developers. However, there are other groups who may find parts of this documentation useful.
- NRAO Managers
- By skimming this documentation, managers will get a sense of the software the SSS team has developed and may find opportunities for reuse.
- EVLA Scientific Staff
- Scientists can use this document to better understand the applications that are in development, and can employ that understanding to help us to make them better. This audience should also be interested in the representation of the problem domain, as developed in the SSS Domain Model Software. The UML diagrams presented therein might be the best starting point.
- NRAO Developers, non-EVLA
- The SSS Utility Software is a single java archive file that contains general purpose objects. It is a lightweight library that is dependent on no other SSS software. This audience may be interested in incorporating this library into their own applications.
- EVLA Developers, non-SSS
- In addition to investigating the SSS Utility Software, this audience will likely want to become familiar with the SSS Domain Model Software.
The most important philosophy practiced by the SSS team is that all applications use the same underlying problem domain model -- they do not each solve the problem domain for themselves. If, for example, an application needs to work with the problem domain concept of source
, it does not matter whether the application in question creates proposals for observations, manages proposals, prepares observations for scheduling, allows creation of catalogs, executes observations, or exposes results to the outside world, it uses the single implementation of the source concept provided to it by the SSS Model Software.
Another very important philosophy is that our code be written in a truly object-oriented fashion. Objects should not be glorified data holders, but should instead provide real capabilities to their clients. This is especially important in the parts of our software that are shared by all applications.
The concept of loose-coupling is another core philosophy for SSS. At the application level we have two stand-alone programs that an observer may use to create catalogs. One of these creates catalogs of astronomical sources, the other creates catalogs of hardware configurations (or the science specifications that lead to hardware configurations). While each of these may be run on its own, each is used by the application that scientists use to prepare observations for scheduling. To the observer it appears as if the catalog tools were part of the observation tool, but that is not the case. Instead, these applications are coupled only by the XML messages that the pass to each other. Within an application, the duties of the business layer, persistence layer, and user interface layer are clearly separated. Even within one of our building block libraries we make an effort to keep from needlessly coupling the packages that comprise that part of the software.
The largest scale split in the SSS Software is between our applications and the building blocks that they use. The building blocks provide services to the applications, but are completely unaware of how they are being used. This split is illustrated in the menu on the left.
The building blocks are further partitioned into four libraries that have a fixed, one-way, relationship among themselves. That is, if library A knows about objects in library B, then the objects in library B must have no knowledge of library A.
The SSS Utility Software
is at the bottom level. It consists of very general objects and has no dependency on any other SSS software. As such it is very amenable to being used in other projects. The next level up is the SSS Domain Model Software
. These objects represent the problem domain and, with help from the utility libraries, the business logic. The model classes have no knowledge of the applications that use them, and they also have no nothing about the persistence mechanisms that might be used to store their state. All applications revolve around the model objects.
The SSS Data Access Software
is the data access layer for the model objects. The particular implementation we have at this time uses Hibernate
object/relational mappings to store our model in a relational database. The model itself neither knows nor cares that this is the case. Finally, the SSS Web Utility Software
provides objects that make the model more readily usable inside web-based applications. The web utility library depends on the utility and model libraries. It also has a small link to the data access software (two classes in the web utility packages access one class in the data access packages).
The applications listed below are in various stages of development. Each of them uses the building block software described above.
- Source Catalog Tool (SCT) - a browser-based application that allows an observer to view, create, and manipulate catalogs of astronomical sources.
- Resource Catalog Tool (RCT) - a browser-based application that allows an observer to view, create, and manipulate catalogs of hardware configurations for eventual use in observations.
- Observation Preparation Tool (OPT) - a browser-based application that allows an observer to prepare observations for execution. This tool has seemless integrations between itself and both the Source Catalog Tool and the Resource Catalog Tool.
- Observation Scheduling Tool (OST) - a desktop application that is used by telescope operators for scheduling observations to be executed. The scheduler dynamically assesses the current conditions for the pool of scheduling blocks and suggests to the operator the next observation.
- Parminator - a browser-based application that is used for maintaining various data points for the EVLA.
The SSS Team is using JIRA
to track requests for changes to our software. Our issues are held in the EVLA SSS
project (user name and password required).
The SSS Team is using Subversion
as its version control system. We have one repository for our building blocks
and another for our applications
(user name and password required). Each repository is split into a number of projects.
The software described herein is at different stages of development. The utility packages are the most stable, but we do add to them as needed, and occasionally refactor them. Within the domain model the areas that need the most work are the resource model and the scheduling block class. The data access layer will change only if we change a persisted property of the model. The web utility package may be updated with new functionality, but is unlikely to see many other types of changes.
With respect to the applications, the SCT is the most fully developed. We will soon add the last major feature, which is the ability to import and export catalogs from and to text. The alpha release of the OST, also known as the dynamic scheduler, is slated for July 1, 2007. The OPT is about two-thirds complete. It must be fully finished and capable of producing observing scripts before we receive our prototype correlator, which is scheduled for Spring 2008. The RCT needs the most work. At this point we have only the skeleton catalog capabilities, but nothing related to the actual configuration of the hardware.