9.8: Dependencies On Other Project Components
$Id: depends.html,v 1.5 1996/03/14 22:05:04 de Exp de $
By its nature the information management component depends on
and interacts with virtually every other module of the software
(and hardware) implementation to varying degrees:
- Mask Generation: the IM software accepts and also provides information
during mask production, checkin, and use in the instrument, and documents
the mask library
- Spectrograph Control: the IM software accepts or solicits status
information from the spectrograph control software, and documents many
physical components of the spectrograph
- Guider/Object Acquisition: the IM software accepts and offers information
about the guider image
- CCD Control: the IM software accepts information about CCD status and
documents the CCDs themselves
- Data Storage Formats: the IM software must both write and read the basic
data formats established for DEIMOS
- Image Display and QuickLook: the IM software provides and accepts WCS
transform data to facilitate quick-look reduction and image display; it
may also provide data for various overlaid graphics
- Environmental Monitoring and Alarms: the IM software logs all environmental
data and alarms, and may be the source of some alarms
- Pipeline Data Reduction: the IM software provides data used in the pipeline
reduction process
Here are some concrete examples of the impact of this entwinement
(of the IM component with the rest of the software) on the software
development process:
The schema design must incorporate FITS keyword lists established
for DEIMOS data as well as lists of keywords recognized by all machine
control and monitoring processes (which in turn are constrained by actual
hardware design decisions).
The observer interface must be integrated
seamlessly into the general DEIMOS user interface, using identical
look/feel conventions.
The information management programmer must
work and closely with the data storage (FITS) designer and the
user interface designer, both to comply with their requirements
and to provide them with additional features and tools.
In addition, the information management system must be almost complete by the time
the instrument is lab-tested, as it will be used first by the hardware
and software engineers as they construct and test each component of
the instrument. Their requirements will evolve as the testing process
continues, so the info management software will undergo gradual continuous
revision from lab test through commissioning and into first real
observational use of the instrument. The information management
designer must work closely with the hardware and software engineers,
both to integrate software with their modules and components and
to provide them with early information management services.
The information management component, in short,
- depends on and interacts with every other major software component,
- cannot be fully tested until commissioning, and
- has a GUI whose style must be consistent with other DEIMOS GUI.
Much of the schema
can be prototyped well in advance of lab testing, but cannot be finalized
until after commissioning. Much of the software can be prototyped
in advance of lab testing, but cannot be tested until the rest of the
machine control and data taking code is working. The IM designer must
cooperate closely with all of the other engineers and designers, and
cannot produce a working system without constant reference to their
progress and requirements.
In general the IM software might best be developed as a "final layer"
on top of completed control and monitoring systems. Other subsystems
can be developed and tested using I/O to flat files, after which the
database interface replaces the flat file I/O.
de@ucolick.org
webmaster@ucolick.org
De Clarke
UCO/Lick Observatory
University of California