Introduction to SSS Problem Domain Models
Summary of Session 1 for Use in Session 2
2006-Nov-2
David M. Harland

Recap of Session 1

The audience has expanded since the first session, so we'll take the first ten minutes and review very quickly material from Session 1.

  1. Purpose: familiarize others with problem domain models.

  2. Main models & their status:
    1. Project. Developed to a fair degree, though details of some objects not fully fleshed out.
    2. Scan. Really a subset of Project, but rich enough to treat separately. Well along in development, but with several to-do items.
    3. Source. Of the models, this is the most complete. Independent of all other models.
    4. Resource. In earliest stages of development. Should also be independent of other models. Will not be covered in these sessions (unless we have more sessions than anticipated).

  3. UML: The documentation includes many UML Class Diagrams and Sequence Diagrams, and may soon include Object Diagrams (aka Instance Diagrams), Package Diagrams, and more. The conventions for class and sequence diagrams were covered in Session 1 and will not be repeated in this recap.

  4. Model, Data Access, Presentation, Applications. One key to the code in the model layer is that it is 100% divorced from data access and presentation code. The model packages (along with some utility-type packages) may be lifted away from the rest of our code base can compiled independently, making it usable by other applications.

  5. How to Learn the Models. The java SDK comes with a tool, javadoc, that produces HTML documentation on the packages, classes, and methods of our models. It also allows us to link in documentation built by other means. The proper place to go to learn the model APIs is the documentation, not the code. A snapshot of this documentation may be found here: SSS Models Documentation. We will focus only Models and Utilities tables on the overview page.

  6. Code Structure and Location. The key layering of the code was mentioned in point 4, above. The actual package names can be considered strawmen for now. E.g., we're not really "e2e" anymore, the use of "commons" is not universally loved, etc. At the time of Session 1 i mentioned that the model code could not be found in the main CVS repository. Brian Truitt has since put our code there. It's in /home/asg/cvs/NRAO/SSS. A separate movement is afoot to look at source code repositories, code sharing, and the build processes. We do not want to take time in these meetings to discuss those issues.

  7. Depth of Coverage. It is up to the audience members to decide how deep to go on any single topic. We'll usually start with class diagrams, but from there we can go to the public API in the javadocs, and even to code if desired.