The SSS Domain Model Software is an implementation of the objects and entities in the domain within which all our applications work, namely the construction and execution of astronomical observations. The objects in this section, along with those in the SSS Utility Software, implement the business logic for our programs.
We often break our domain model into component models when speaking or writing about it. These models are: the source model, the resource model, the proposal model, the project model, and the scan model (which we sometimes say is really part of the product model, but is rich enough to view as a separate model). As was mentioned in the main SSS document page, the SSS team adheres to a philosophy of loose coupling. This is manifested in the interaction between the various models. For example, neither the source model nor the resource model know of any of the other models. (That is, their java code contains no imports of classes from other models.) The proposal model is permitted to know about the source and resource models, but not about the project and scan models. Only the combined project / scan model knows of all the other models.
The domain model classes neither know nor care how a given application chooses to persist it. The domain model is completely decoupled from our data access layer. To support those situations where one model class may need to find objects of another model class, we have XxxProvider interface classes (e.g., ProjectProvider, SourceProvider). Objects in the data access layer may implement these interfaces, and applications can then pass these data access objects to the model objects disguised as the domain model provider interfaces. This decoupling of our model from how and where it is stored will allow us to replace our current persistence layer with no impact at all on our domain model classes.
Each of the major model objects can be told to write itself to, or read itself from, XML. We are using JAXB-2.x to do most of the work that is required to serialize our objects to, and deserialize them from, XML. The work that is left for us to do is surprisingly minimal. JAXB-2.x makes use of java 1.5's annotation capabilities. We use these annotations on those properties of our objects that we wish to express in XML. To validate XML data we have a collection of XML Schema files. Our current convention (which is not yet finalized) is to have one schema file for each package in the domain model. The name of the schema file is package-name.xsd. For example, the schema file for package edu.nrao.sss.model.project is project.xsd.
Most of these diagrams were reverse engineered from our java classes, so they represent the actual capabilities of those classes at the time the diagrams were produced. Each diagram is focused on a particular aspect of the model and, as such, many of the details (supporting objects, methods not important to that aspect, and so on) are suppressed. For a detailed look at any of the classes, consult the API documentation.
The following links are to documents that concentrate on a particular aspect of the domain model.
The application programmers' interface for all domain model classes may be seen by going to the API overview.
The source code for the classes of these packages, the test classes written for them, and all other supporting files are held in a subversion repository (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 Models Repository.
The SSS Domain Model Software is dependent on the SSS Utility Software, but on no other SSS software. It is also dependent on some third party software. 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 files may be found in the Models Repository.