Home
User
Dependencies for this release
Scientific Linux CERN 3: SLC3 (GCC 3.2.3)
About dependency diagrams
IGUANA includes a small utility, Ig_Infrastructure/IgNominy, to analyse software dependencies. Results of running that tool are included in each IGUANA release in the doc/deps directory. The directory contains a subdirectory for each platform the release was built on, usually linux and sunos. In that directory you can find the index page index.html that points to the analysis results in a convenient way.
The dependencies show exactly what each package depends on. The information is available both as a summary table and graphical diagrams. For example, to find out what Ig3DViewer depends on, follow the link ``Dependency statistics'' to the table, find the ``All dependencies'' table and see which columns are occupied. Alternatively, check the index page for a diagram named iguana-Ig3DViewer-dir-purpose, meaning Ig3DViewer direct source + binary dependencies coloured by package purpose (e.g. violet is 3D-related). It shows graphically the same information. You can also download PostScript versions of the diagrams from the index page.
IgNominy
ignominy: dishonour, disgrace, shame; infamy; the condition of being in disgrace, etc. (Oxford English Dictionary)
IgNominy examines package dependencies by examining a built source tree. It scans makefile dependency data (for header files the compiler actually saw), source code, binaries and dynamic loader information for possible dependencies, resolves them and outputs a simple textual database. If environment variable $VERBOSE is set, you will also get a very verbose log to your standard error output (see mkdeps in IgNominy for details). The information collected by IgNominy is then further processed by a number of presentation tools. The dependency diagrams are generated using the Graphviz package from AT&T.
In general, you would want to run IgNominy after having built the entire release, as described in the build instructions. Note that the location of external libraries and source code is determined automatically querying the SCRAM configuration by mkconfs. Some additional IGUANA-specific configuration is in the path.conf file in IgNominy package.
If you wish to create more dependency diagrams, edit the mkgraphs script in IgNominy (add the packages you want dependencies for to the list in the for-loop at the end of the script) and then run scram b dependencies. If you have already collected the dependencies and just want to create more diagrams, edit mkgraphs, go to the root of your SCRAM build area and run src/Ig_Infrastructure/IgNominy/mkgraphs linux-2.2 to regenerate the diagrams. You may also want to rerun mkgifs to regenerate the GIF versions and mkdirindex to regenerate the web index page (run them exactly the same way as mkgraphs above). Or more simply, simply comment out the stages you do not wish to redo in mkall and rerun scram b dependencies.
IgNominy Metrics
IgNominy also calculates some simple metrics following John Lakos: Large Scale C++ Software Design. While IGUANA does not yet have a comprehensive testing framework, these metrics give a rough idea of how good the physical partitioning of a release really is. The meatrics measure degree of component dependency, that is, the number of other (physical) components required to thoroughly and incrementally test a particular component. This also introduces the idea of package levels: packages on the lower levels must be tested before those on the higher levels (hence the incrementality).
The component dependency (which IgNominy calculates for packages, not individual classes) indicates how many other libraries must be linked into the test drivers of that package. The component dependency is cumulative: a package on level zero has no dependencies and hence cumulative component dependency (CCD) of 1 (it requires itself for testing) and the CCD of any other package is the sum of the CCDs of all the packages it uses. Essentially the CCD of a package tells how costly it is to test the package thoroughly. The CCD of the release is simply the sum of the CCD of all the packages in and used by the release. That is, the CCD IgNominy calculates includes the testing cost for all external software.
A couple of other numbers calculated by IgNominy are the average component dependency (ACD) and the normalized cumulative component dependency (NCCD). ACD is simply the release CCD divided by the number of packages involved, and indicates how many libraries are required on average in the tests. NCCD measures how the package dependencies compare to a balanced binary tree. NCCD less than one indicates that the package structure is more flat or horizontal than a balanced tree, and NCCD greater than one indicates that it is more vertical and/or tightly coupled. The NCCD value is followed by the minimum and maximum bounds: no interdependencies and total interconnectivity, respectively. A toolkit-like system such as IGUANA should have a NCCD less than 1.0, approximately 0.8. NCCD substantially greater than 1.0 would indicate that there may be significant cyclic physical coupling within the system.
Note however that Lakos has this to say about NCCD:
NCCD is not a measure of the relative quality of the system. NCCD is simply a tool for characterizing the degree of coupling within a subsystem. Increasing the number of components in a system could artificially reduce the NCCD. One way to do this is to eliminate completely valid reuse; this would likely not be an improvement. [...] Minimising CCD for a given set of components is a design goal. Reducing the CCD in a system of a given size is almost always desirable. Reducing the size (number of components) of a system is also desirable but not at the cost of introducing cyclic dependencies, inappropriately merging components, or creating unmanageably large translation units. [...] The precise numerical value of the CCD (or the NCCD) for a given system is not important. What is important is actively designing systems to keep the CCD for each subsystem from becoming larger than necessary.
Finally, IgNominy calculates another similar metric, the number of outgoing links for each package and the average over the system. Unlike ACD that measures all dependencies of a package, this number indicates the average number of direct dependencies.
