APT Data Model Task
Meeting Summary

Date: 19-Jan-2000

Attendees: C. Burkhardt, R. Douglas, K. Peterson, D. Shaw, H. Shukla

Administration

The APT Data Model (DM) Group will meet weekly. Meeting summaries will be posted on the APT Web site. The DM group will construct a Web page of links to important documents and other information; this page will be linked from the main APT project page, and will be maintained outside of the firewall. The DM group will also set up an e-mailing list for group members, which initially should include the above-named attendees, plus Tony Krueger.

Action Items
All Send to Dick times when you can support a regular, weekly meeting. [DONE]
Dick Schedule a meeting time and arrange for the venue. [DONE]
Chris Set up a Web page outside the firewall that all in the DM group can modify. This will require using the new Unix group for the APT developers. [DONE]
Chris Set up an "apt_dm" e-mailing list. [DONE]
Dick Write up and distribute a summary of this meeting. [DONE]

Group Interfaces

The DM group will need to work closely in the future with the Infrastructure/Architecture group as the data modelling progresses; this is particularly important as we identify databases and other external resources that require I/O. It is not clear whether interactions at the weekly APT project meetings will suffice, but additional group-to-group meeting can be scheduled if necessary. Rob is part of the IA group, so he will provide an information conduit.

Our understanding is that the "Stakeholder Support" group membership has yet to be finalized, and the first meeting of that group is not likely to take place before the end of this month. The DM group will be in need of some input from the SS group by mid-February, and there is some concern that our need for firm requirements could grow at a rate much faster than the SS group will be able to generate them. To mitigate this risk, we propose the following:

  1. Identify key areas in which the data modelling/design efforts are especially vulnerable to changing requirements. Pose these issues directly to the SS group so that they may be addressed early on.

    The first, most serious concern is whether and to what extent the requirements will call for the APT to interact with RPS2 prior to the replacement within APT of the RPS2 functionality.

  2. Generate a list of tools that we think are most likely to be developed first, and focus our modelling/design efforts there initially. (This list should be blessed by the SS group at the earliest opportunity.) We anticipate that the VTT concept will proceed first, with a target deployment in time for Cycle 10, Phase 1 preparation. The ETCs are a likely next choice, though the deployment may not occur before Cycle 10, Phase 2.

  3. If the requirements documents are not finalized before we are ready to start the detailed design in earnest, then generate a draft of the requirements for the initial tool, and propose that to the SS group as a starting point.

Action Items
All Continue thinking about key vulnerabilities of the DM efforts to volatile requirements.

DM Development Plan

The high-level development plan consists of the following stages:

Start-up activities:

Collect the data models used on other, relevant projects (such as RPS2, SEA, and SpecView) for study by the DM group. These models should be represented graphically, where possible, and linked to the DM Web page.

Finalize the choice of IDE and the UML tool for the DM work. Document the choices and the evaluation criteria on the APT Web site. Finalize the configuration strategy.

Construct an initial timeline with target dates for the conclusion of various activities.

Initial data model development:

We can proceed immediately with preliminary work on the data models since we are fairly familiar with the problem domain. The models used in heritage systems will provide the inspiration for the initial activity, which is the preliminary specification of needed classes, and class heirarchies. This specification will be captured primarily in UML diagrams, with other diagrams and text as necessary.

One activity with great potential for re-use beyond APT is an information resource that captures the valid instrument configurations, and the relationships between the various optical elements and detectors. There are a number of systems (including STSDAS/synphot, RPS2, the CGI-based ETCs, the SEA/ETCs, OPUS, to name a few) that have a need for this kind of information. Unfortunately, all of these systems implement independent mechanisms for storing this information (often in obscure formats), and for representing it internally. This creates needless maintenance problems, and could be cured with a sufficiently thoughtful solution.

Detailed design of initial tools:

Detailed analysis of the requirements (and iteration as necessary with the SS group) to finalize the requirements. Detailed analysis of the Architecture to understand the context of the system. This marks the begining of the detailed design phase for the early tools, which will produce various products that collectively will document the design. This will be followed by a formal design review, and any needed follow-up work to address issues from the review.

Steady-state efforts:

We will re-visit the modelling/design efforts as various new tools are defined by the requirements group.

 
Action Items
Dick Construct a preliminary timeline for the DM efforts, and report that to Tony.
Chris Write a summary of available UML tools and IDEs for Java, and place on the APT Web site. Offer a recommendation for each, and specify the selection criteria. [Due by Tuesday, 1/25.]
Construct a graphical representation of the data models used in:
Rob RPS2
Dick SpecView. Also put the SpecView design doc on the Web.
Chris SEA, particularly the VTT.
Hemant SEA/ETCs (with help from Chris & Dick as needed).

Copyright© 2000 The Association of Universities for Research in Astronomy, Inc. All Rights Reserved.