Introduction to SSS Problem Domain Models
Session 4 – The Project Model
David M. Harland

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.


  1. SB Overview Diagram
  2. Basic Attributes
  3. 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.
  4. Class Documentation
  5. Discussion on inter-SB dependencies. We currently have simplistic prerequisites. Is this good enough, or should we model something more complicated?
  6. Scheduling Status Transitions. Discussion: postponed SBs.


  1. A class without a lot of substance.
  2. 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 ProgramBlock.
  3. Holds scheduling blocks.
  4. Has same prerequisite construct as SchedulingBlock.


  1. Created from one proposal. (A proposal, though, could lead to multiple projects.)
  2. Is on a single telescope.
  3. Has a limited amount of telescope time allocated to it.
  4. Holds one or more program blocks.

Project Package

Discussion. This package is full of debris. There are several reasons for this debris:

  1. This package was created during my first weeks at NRAO.
  2. There are place-holders for Proposal Model classes that are not currently used for anything.
  3. 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 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?

  1. In depth look at the measure package.
  2. Use of JAXB 2.0 Annotations in Model
  3. JUnit 4.0 Unit Testing Framework
  4. Generics in Java
  5. Capable Java Enumerations