Meeting Format
The previous sessions have all been presentations of work that has already been done. This session will begin in the same way, but will intersperse collaborative discussions about the particulars of the Project Model and, perhaps, its relation to the Proposal Model.
Ground Covered Previously
We have looked in detail at the Source Model and the Scan Model (really just a portion of the Project Model). In a sense we have been working from the bottom upward. We'll continue that trend here by beginning with the SchedulingBlock. First, though, let's review the high level view of the project model: Project Overview Diagram.
SchedulingBlock
ProgramBlock
Project
Project Package
Discussion. This package is full of debris. There are several reasons for this debris:
One part of the mess that i'd like to clean up relates to the proliferation of enumerations that represent types or statuses. Perhaps the first step is to move the proposal classes to their own package? (If this made the project package small enough, i'd consider moving the scan classes back here from the project.scan pkg.)
May we replace ProjectStatus with SchedulingStatus? If not, why not? What do we want to know about the project's status other than where it is in its life cycle? If need be, we could add more elements to SchedulingStatus (that make sense) to accommodate the status needs of Project.
ScientificPriority is one of the weirdest classes out there. (The reason for using an enumeration instead of an integer was related to the way GBT assigned priority -- an A, B, C list instead of a 1, 2, 3 list. This class gave the ability to deal with GBT and VLA priorities in their own languages.) Suggestions?
Compare ScientificType to SourceCategory. One of these could probably be eliminated and its uses replaced by references to the other.
Compare ObservingType to ScanMode and ObservingMode. Keep these as they are? There's nothing inherently wrong with some overlap, but i'd like more information on the purpose of ObservingType.
Compare ProjectType to SchedulingType. It seems like we need only one of these.
Package Relationships
Time permitting.
Goal: keep packages as independent as possible. Do not create new linkages between packages without first thinking carefully about it. See: Package Diagrams.
Future Topics?