We envision a repeated cycle of analysis, design and implementation. The end product of any cycle is a model of the system and its implementation. The corresponding tangible deliverables are documentation describing the model and its usage and the code itself. The model serves both as a tool to aid in analysis and design and as means of communicating the results of this process. Inevitably, the implementation stage reveals inadequacies of the model and the model is updated to reflect design changes during implementation.
The model consists of two major views: the logical and the physical. The former describes the classes and their associations and how objects interact with one another. The latter defines how the code is organized: where files reside and how they depend on one another.
In order for the model and code to be useful, there must be documentation to tie it all together. The documentation is web-based and has its entry point at http://www.bonner.rice.edu/adams/trf++ . It provides access to the model diagrams and to a recent version of the code. Note that this code access is intended for documentation purposes only and may no be complete. Please contact the author to obtain the current code. Members of D0 should obtain the code from the D0 CVS repository.
The physical model defines how the code is organized into files and the dependencies between these files. We follow Lakos and organize the code into components which are assigned to packages. Previous to version 0.3, the code and documentation was organized by Runbaugh's class categories.
Each component consists of a header file defining the interface, a source file providing definitions and a test file. Where needed, there is also a template definition file. The test consists of a main program which should fully exercise the functions defined in the interface and returns nonzero if an error is found. Typically a component defines one class although it might include other closely related classes or external functions.
We follow Lakos and organize the components and packages so that they have well-defined acyclic dependencies. Within a package, components are organized into levels and each component only depends on those coponents at a lower level. Packages are organized in the same way: the components in a package only depend on external components in packages at a lower package level. This structure allows us to contruct and test components one at a time working from lowest to highest levels.
The physical model is defined by files associated with the packages and is illustrated in physical dependency diagrams. The documentation is organized by packages in order of dependency.
For the logical, we follow OMT (Rumbaugh) and ask for three views: object, dynamical and functional. These are in order of importance. Respectively, these views define the classes and their associations, describe how their objects interact, and show how data flows. This and other methodologies also emphasize starting with a problem statement which may be refined as work progresses.
We focus mostly on the object model because TRF++ (and its extensions) comprise a fairly complicated set of classes and associations. One top-level class diagram shows the major classes and their associations while a class diagram for each package shows all its classes and associations. The header files document the interface for each class.
The dynamic view tells how and when objects interact with one another. These interactions are carried out by sending messages which are associated with the class operations. This view is important for demonstrating how the classes are used and for discovering the operations and assigning them to classes. We have found event trace diagrams to be most useful for showing these interactions and made considerable use of these when building up our original model. Perhaps these diagrams should be updated for the current model.
We provide little discussion of the functional model because it is rather simple: clusters flow into our system and tracks flow out.
As described above, the code is divided into packages which are made up of components. Each package is in a separate directory. In the D0 CVS repository, each package corresponds to a CVS module. Each package contains a file LIBRARIES which lists the packages upon which it depends. Each package also contains a file COMPONENTS which list all the conponents ordered by dependency and grouped by level. The signatures and comments in the header files serve as documentation for the components.
The above organization of code was introduced in version 0.30. More information can be found here.
Please send questions or comments to adams@phsics.rice.edu.