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.
SB Overview Diagram
Susan is starting to look at this part of model for use with scheduling.
Anticipate additions to, deletions from, and rearrangements within
this package. Philosophy: the model should try to make life as easy as
possible for applications that will use it, without compromising its
integrity. We should expect the SchedulingBlock in particular to
acquire new methods related to scheduling.
on inter-SB dependencies. We currently have simplistic
prerequisites. Is this good enough, or should we model something more
Scheduling Status Transitions. Discussion:
- A class without a lot of substance.
- Main job: allow a project to be split into pieces where each
piece is for a different telescope configuration.
The telescope configuration is one of the properties of
- Holds scheduling blocks.
- Has same prerequisite construct as SchedulingBlock.
- Created from one proposal. (A proposal, though, could lead to
- Is on a single telescope.
- Has a limited amount of telescope time allocated to it.
- Holds one or more program blocks.
This package is full of debris. There are several reasons for this debris:
- This package was created during my first weeks at NRAO.
- There are place-holders for Proposal Model classes that are not
currently used for anything.
- We've used different sources of information for constructing these
classes without looking closely enough at areas of overlap.
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
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.
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?
One of these could probably be eliminated and its uses replaced by references
to the other.
Keep these as they are? There's nothing inherently wrong with some overlap,
but i'd like more information on the purpose of ObservingType.
It seems like we need only one of these.
Goal: keep packages as independent as possible.
Do not create new linkages between packages without first thinking
carefully about it. See:
- In depth look at the
- Use of JAXB 2.0 Annotations in Model
- JUnit 4.0 Unit Testing Framework
- Generics in Java
- Capable Java Enumerations