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:
The main audience for these documents is EVLA software developers. However, there are other groups who may find parts of this documentation useful.
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.
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.