APT Architecture/Infrastructure Design/Requirements Assumptions

This document records the assumptions made about the requirements in providing the design. Certain aspects of the design may not be usable if these assumptions do not hold true.

Requirements assumed in the design:

1. Tools

   The following tools will need to be included in order to replace RPS2:

   • VTT
   • ETC - one for each valid instrument
   • Legal configuration manager - determines legal options based on current configuration
   • Exposure/orbit planning - determines overheads and provides information on orbit filling
   • Visit planning - allows constraints between visits and provides schedulability feedback

   The following tools are also desired:

   • Starview II/VTT
   • Phase I submission
   • Finder chart generator
   • Parallel planner
     

2. Help

   Help will be available as follows:

   • HTML documentation provided for full help, with access from within the environment
   • Tooltips on each button for quick description
   • Wizards willbe provided to help new users through common tasks

3. Plug-in support

   It is assumed that the APT tool set will be extensible, and that there will be a way to include as yet undefined tools in the APT. These tools will not be noticeably different from tools that were built with APT. As not all tools will be written in the initial phases, some of these tools will be written by the APT team later and some may be written by outside developers who will follow a published API for plugging into the APT.

4. Data sharing

   It is assumed that tools written specifically for the APT shall share their data in a manner that is transparent to the user. It is acceptable for tools to run in the same process space in order to share this data or the data may be shared through an infrastructure, as long as the user does not have to manage the transference of data from one tool to another.

5. Syntax checking

   Syntax checking should be performed instantaneously during data entry. For example if an integer is required but a real is supplied it will be flagged right away. Currently, in RPS2, this is handled in batch by the PP, but with this model, syntax checking will be spread across many tools.

6. Persistence of data

   A persistent data model will be supported. This means that data entered into a tool can be saved and restored the next time the tool is run.

7. Interoperability with legacy systems

   It is assumed that APT will need to be able to communicate and operate with legacy systems. These systems may not be platform independent or even distributed with the APT, and the APT will manage the communication with those systems in such cases.

8. Network dependence

   Network dependence will be tool dependent. This means that the APT architecture does not require a network connection. However the individual tools may.

Features deemed to be too risky/costly to be included in the design:

1. ASCII support

   APT will not be required to parse any ASCII input file unless that file was written by an APT or RPS2 tool. There will be no support for hand-editing of RPS2 files, for example. This mimics the use of graphical tools today, where the saved data files are only editable from within the tool.

2. DG removed

   There will not be one integrated display of the information currently displayed by the DG. The function of the DG will be spread across the various tools, which will each provide their own graphical input and output.

3. Distributed computing

   Unlike RPS2 and the DOC, general support for running tools remotely will NOT be supported. Use of CORBA should be minimized. Most tools should run natively in the APT environment. In te prior systems, remote processing was assumed for all tools, with local processing being performed as a simplified form of remote processing. However, this incurs a significant overhead which can be avoided if remote processing is limited only to applications as necessary.

4. Multiple user/collaborative support

   A multi-user shared data pool is NOT required. In other words, the APT will not facilitate having multiple users develop the same proposal simultaneously from different APT sessions and share changes.

5. APT applet

   APT will not need to be run as a web applet.

6. Multi-platform support

   A specific set of platforms will be listed as supported platforms. While APT may work on other platforms, only the listed platforms will have APT certified to run on them. Initially the supported platforms will be:

   • Solaris 5.5.1 - 5.7
   • Windows NT

   In the near term the following additional platforms will be added:

   • Linux
   • Windows98/2000

The following are design decisions made so far:

1. Validity checking

   Validity checking of data will be performed in the Data Model, as objects are created.

2. Help

   Help will be handled as follows:

   • Data Model has specification and definition of objects
   • Individual tools have the specific uses for the information from objects

3. Metrics

   Support for collecting certain metrics will be built into the APT.

4. XML output

   All datafile output from APT will be in XML only.

(Updated 02/14/2000 by Rob Douglas)
(Updated 02/16/2000 by Karla Peterson)
(Updated 05/11/2000 by Rob Douglas)