Visit Planner Design Review

I would like to walk everyone through the most important classes for the Visit Planner. A primary goal of this design is to reduce the dependency between components as much as possible in as logical a manner as possible. Familiarity with UML will help to read the diagrams.

Requirements

I assume that everyone is familiar with the Visit Planner Requirements. The APT review presentation of the requirements and the requirements themselves are available under “Presentation Slides” and “Detailed Requirements” on the Visit Planner Web Page:

http://ra.stsci.edu/apst/apt/apt-visit-planner

I’ve included at the end a glossary of terms which I will use indiscriminately.

Packages (See figure label Packages)

The system is divided into packages in a manner similar to a Model-View-Controller architecture. In addition, there are two packages for the servers that will provide schedulability data. The Visit Planner packages will be sub-packages to edu.stsci. The five sub-packages are: 1) visitplanner, 2) visitplanner.view, 3) visitplanner.model, 4) visitplanner.engine, 5) visitplanner.engine.spike

The visitplanner package is the controller which will respond to user requests to compute schedulability, invoking a server engine to do that. The visitplanner will then update the data model.

The visitplanner.model package will contain all the schedulability data for visits as well as bookkeeping data.

The visitplanner.view package is mostly pure view. It’s primary function is to display data in the visitplanner.model package. It’s only pro-active function is to provide a GUI component to allow the user to actively request an update of the schedulability data.

The visitplanner.engine package is an interface between the visitplanner and any server which provides a schedulability engine which can determine schedulability for visits

The visitplanner.engine.spike package is the actual bridge from the visitplanner to Spike.

Package Descriptions

The packages are discussed here in order of increasing dependency: model, view, engine & engine.spike, visitplanner.

Package edu.stsci.visitplanner.model

<<VpData>> holds all the data of the Visit Planner. It maintains all computed schedulability data and constraints used to compute the data.

Starting from the second diagram of the data model working from the bottom of the dependency tree:

· <<SchedulingWindow>> A single interval of time with an associated “schedulability” value which is a quantitative indication of the schedulability over the time interval.

· <<SchedulingWindows>>: A contiguous, ordered list of <<SchedulingWindows>>. Such a list is used to describe the total or partial schedulability of a visit over an observing cycle.

· ObserverRequirementDescription: A description of an observer requirement used to compute schedulability. It’s purpose is to hold a parameter name used to query the APT data model for user parameters need to compute schedulability. It is expected that the schedulability engine will provide the list of required observer requirements. A set of observer requirements together with a set of observatory restrictions specify a scheduling constraint.

· ObservatoryRestrictionDescription: A description of an observatory restriction used to compute schedulability. The Visit Planner does not actually use this, but it is included for completeness in describing a scheduling constraint. It is expected that schedulability engine knows about all observatory restrictions. This is certainly the case for Spike.

· ConstraintDescription: A combination of observer requirements and observatory constraints that affect when a visit can or cannot schedule. Eventually, (not in the initial version), users of the Visit Planner will be able to “explore” the schedulability of their visits by turning off and on the constraints which do affect schedulability.

· <<ConstraintSchedulingWindows>>: The partial scheduling windows for a visit with regard to a single scheduling constraint.

· <<VisitSchedulingWindows>>: Contains all the schedulability data for a visit including the total schedulability as well as all the <<ConstraintsSchedulingWindows>> for all relevant scheduling constraints. In addition, it contains any <<AuxilaryData>> returned by the schedulability engine. The <<AuxilaryData>> is a mechanism for the schedulability engine to provide any additional information which the Visit Planner need not understand. However, the <<AuxilaryData>> must provide a means to display itself, i.e., a JComponent since the Visit Planner is not expected to know how to display it.

· <<VpVisit>>: A “visit” as specified in the observer’s proposal. It is actually an element in the APT proposal specification document. Currently, the interface <<SchedulingUnit>> is imposed on document elements that can be processed in the Visit Planner since that is a more generic term. But, Visit make more sense with the Visit Planner.

· <<VisitData>>: A convenience object which associates a visit and its schedulability data. It also keeps track if the schedulability data is up to date with the visit data.

· <<VisitDataListener>>: An interface for any objects that wish to listen for changes to the data model. Visit Planner views will listen to the data model.

(See first data model diagram)

· <<VpData>>: The top level Visit Planner data object which contains all schedulability data for all visits and lists of all constraints.

· VisitList: <<VpData>> contains two lists of visits: “Active” visits which are in the current APT inferred context and a cache of “Inactive” visits for which the Visit Planner has computed schedulability, but are not in the current APT inferred context.

· ConstraintList: <<VpData>> contains two lists of constraints: “Active” constraints which are the current user selected lists of constraints to be used to compute schedulability and “Available” constraints which is the list of all constraints which the user can select from. For the initial version of the Visit Planner, the user will not have the capability to pick and choose constraints. All constraints will always be included.

Package edu.stsci.visitplanner.view

· <<VpView>>: Responsible for providing a graphical view of the <<VpData>>. It implements <<VisitDataListener>> to be able to update the view when the data model changes.

· VpToolView: An actual implementation of <<VpView>>.

· <<SchedulingWindowsRenderer>>: A GUI component for displaying <<SchedulingWindows>> objects.

· TextualSchedulingWindowsRenderer: A textual representation of <<SchedulingWindows>>.

· GraphicalSchedulingWindowsRender: A graphical representation of <<SchedulingWindows>>.

· <<VpViewListener>>: An interface for any objects that wish to a <<VpView>>. The Visit Planner Tool will listen for when users wish to update the schedulability data.

· VpViewFactory: Creates different types of <<VpView>>s. Early in development, the views will be text based. Later on, the text based views will be swapped out with graphical ones.

Packages edu.stsci.visitplanner.engine, edu.stsci.visitplanner.engine.spike

The engine package provides a buffer between the visitplanner package and any schedulability engines. The Visit Planner will not depend on any implementation specific details of a schedulability engine.

The engine package contains the <<VpEngine>> interface through which the Visit Planner will request schedulability computations and obtain constraint descriptions. In addition, the engine package contains a VpEngineFactory for providing instances of schedulability engines to the VisitPlanner.

The engine.spike package provides the java bridge between the Visit Planner and Spike. It includes adapters which support any interface to Spike we wish to have. Initially, the Spike interface will use files. Later on we may consider CORBA or some other form of inter-process communication. These adapters will generate the <<VisitSchedulingWindows>> objects which go into the Visit Planner data model.

Package edu.stsci.visitplanner

The visitplanner package is the overall controller. It interacts with all the other packages. The VpTool obtains views from the VpViewFactory and then listens to the <<VpView>> for user requests to update the schedulability data.

The VpTool obtains a schedulability engine from the VpEngineFactory. User requests to update the schedulability data are passed on to the <<VpEngine>>. The resulting data are assembled into VpToolData and VpVisitData objects which are implementations of data model objects.

Glossary

· Link:

A relationship among 2 or more visits.

· Observer Requirements:

The requirements which observers place on observations to meet science goals.

· Observatory Restrictions:

The restrictions which an observatory places on observations as a matter of policy or physical limitations

· Observation Constraint:

An Observer Requirement or Observatory Restriction that constrains the circumstances under which a visit may be scheduled.

· Scheduling Constraint:

Any Observation Constraint or combination of Observation Constraints that affects when a visit can or cannot schedule.

· Scheduling Windows:

The periods of time that a visit can or cannot schedule due to scheduling constraints.

· Total Scheduling Windows:

A set of scheduling windows that accounts for all scheduling constraints.

· Partial Scheduling Windows:

A set of scheduling windows that takes into account a subset of scheduling constraints..

· Schedulable/Unschedulable Window:

A period of time over which a visit can or cannot schedule.

· Visit: Any grouping of observations which can be scheduled as a unit.