ACAT 2002 ACAT 2002 June, 2002 Lassi A. Tuura, Northeastern University http://iguana. cern . ch Ignominy Ignominy Tool for Analysing Software Dependencies and Tool for Analysing Software Dependencies and For Reducing Complexity in Large Software For Reducing Complexity in Large Software Systems Systems On behalf of CMS On behalf of CMS Collaboration Collaboration Lassi A. Tuura Lassi A. Tuura Northeastern University, Boston
27
Embed
On behalf of CMS Collaboration Lassi A. Tuura Northeastern University, Boston
Ignominy Tool for Analysing Software Dependencies and For Reducing Complexity in Large Software Systems. On behalf of CMS Collaboration Lassi A. Tuura Northeastern University, Boston. Motivation. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ACAT 2002ACAT 2002
June, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
IgnominyIgnominyTool for Analysing Software Dependencies and Tool for Analysing Software Dependencies and
For Reducing Complexity in Large Software For Reducing Complexity in Large Software SystemsSystems
On behalf of CMS CollaborationOn behalf of CMS Collaboration
2June, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
MotivationMotivation IGUANA is largely an integrator for CMS: we need to have a
good grasp of the external software before its inclusion into our system By and large we are not seeking to select one product… but are trying to merge the strengths of several packages into a very good
physics analysis environment… and are seeking to provide feedback to component authors
We are interested in, among others: How much of the external package we would use Its impact on our physical software structure How well it fits in with the philosophy of CMS software and other imports—in
design and architecture, usage patterns, GUI, … What other software it depends in Commitment required, possibility of varying how much we use
Make dependency data produced by the compilers (*.d files) Source code for #includes (resolved against the ones actually seen) Shared library dependencies (“ldd” output) Defined and required symbols (“nm” output)
And maps… Source code and binaries into packages #include dependencies into package dependencies Unresolved/defined symbols into package dependencies
And warns… about problems and ambiguities (e.g. multiply defined symbols or dependent shared libraries not found)
Produces a simple text file database for the different dependencies: source only, binaries only, combined, forward and reverse, by package, by domain, …
June, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
Analysis of ATLASAnalysis of ATLAS Torture-test exercise for the tool
Large release size (~50% F77, ~50% mainly C++ but also C, Java) Near the limit of Ignominy’s ability to discover software structure Pictures below illustrate analysis difficulties
Visible (and known) problems Many cleanly designed packages shadowed by a cycle with very unpleasant
effects on the overall structure A number of places show poor packaging and/or lack of abstract interfaces
June, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
Analysis of CMS/COBRA, IGUANA Analysis of CMS/COBRA, IGUANA COBRA
CMS Reconstruction, analysis and simulation framework Recently successfully split off from ORCA Quite many small packages
Has helped with modularity– Some issues with partitioning: some small cycles, certain package groups
appear quite frequently
IGUANA Generic data analysis environment with CMS focus Many fairly small packages with targeted purpose (similar to Anaphe) Project focus as an integrator and glue provider is fairly evident We too have some rats nests to clean up, but at least they are small… Has had the advantage of considerable monitoring!
June, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
Analysis of ROOTAnalysis of ROOT ROOT developers have done a formidable job of breaking
binary (shared library) dependencies, but… It makes dubious use of its internal scripting facility For example: By static analysis, nothing seems to use the postscript
package directly (no incoming dependencies), but there is this code:void TPad::Print (const char *filename, Option_t *option) { […]
Taking these and global objects into account makes the dependency diagrams very different—and cast doubt on usefulness of binary-only dependency diagrams for ROOT
Sign of fast growth? Need a “next evolutionary step”? So “coherent” that replacing parts could get painful…
Size = total amount of source code (roughly—not normalised across projects!) ACD = average component dependency (~ libraries linked in) CCD = sum of single-package component dependencies over whole release: test cost NCCD = Measure of CCD compared to a balanced binary tree
– < 1.0: structure is flatter than a binary tree (= independent packages)– > 1.0: structure is more strongly coupled (vertical or cyclic)– Aim: Minimise NCCD for given software/functionality (good toolkit: ~ 1.0)
June, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
CaveatsCaveats Ignominy does only static dependencies, not dynamic ones
Indirect calls through pointers, virtual function calls State dependencies: Data reads and writes, thread synchronisation, …
The analysis of external software is heuristic; exact information from the build system helps considerably
Difficulties are posed by copied code (copy and paste or merged libraries) and defaults dependent on link-order (“dummies” that are supposed to be overridden by client) Most headaches so far with FORTRAN code
Ignominy must guess software structure when in doubt Based on project-defined heuristic search rules, usually works fine In face of an ambiguity Ignominy warns and assumes the worst
– Multiply defined symbol: dependency on all definitions– Multiple header matches: dependency on all (but correct with compiler-
June, 2002 Lassi A. Tuura, Northeastern Universityhttp://iguana.cern.ch
StatusStatus Run for every IGUANA release as a part of release build Canned configuration for any SCRAM-based project
Needs project specific colouring etc. configurations Works with many other project structures
Tried on G4, ROOT and ATLAS
Plans Consolidate scripts and fold in all the documentation Make it somewhat easier to use and configure Java support with Mark Donszelmann’s jneeds
Available for free at http://iguana.cern.ch/ See the IGUANA distributions (latest = 3.1.0 recommended) Questions? Please mail [email protected] or [email protected]