ACAT Lassi A. Tuura, Northeastern University 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

June, 2002 Lassi A. Tuura, Northeastern University 2Motivation v IGUANA is largely an integrator for CMS: we need to have a good grasp of the external software before its inclusion into our system r 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 v We are interested in, among others: r How much of the external package we would use r Its impact on our physical software structure r How well it fits in with the philosophy of CMS software and other imports—in design and architecture, usage patterns, GUI, … r What other software it depends in r Commitment required, possibility of varying how much we use

June, 2002 Lassi A. Tuura, Northeastern University 3Examples See 3_1_0/dependencies.html

June, 2002 Lassi A. Tuura, Northeastern University 4 ignominy: dishonour, disgrace, shame; infamy; the condition of being in disgrace, etc. (Oxford English Dictionary)Ignominy v Model v Examines and reports on direct and transitive source and binary dependencies v Creates reports of the collected results r As a set of web pages r Numerically r Graphically r As tables Source Code Build Products Metrics Graphs Tables Dependency Database User-defined logical dependencies + ignominy: a suite of perl and shell scripts plus a number of configuration files (IGUANA)

June, 2002 Lassi A. Tuura, Northeastern University 5 Dependency Analysis v Ignominy scans… r Make dependency data produced by the compilers (*.d files) r Source code for #includes (resolved against the ones actually seen) r Shared library dependencies (“ldd” output) r Defined and required symbols (“nm” output) v And maps… r Source code and binaries into packages r #include dependencies into package dependencies r Unresolved/defined symbols into package dependencies v And warns… about problems and ambiguities (e.g. multiply defined symbols or dependent shared libraries not found) v 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 University 6 Single Package Dependencies Cmscan/IgCmscan Testing Level:5 Outgoing edges:6 -from includes:6 (145 files) -from symbols:4 (636 symbols) Incoming edges:1 -from includes:1 (1 file) -from symbols:1 (1 symbol)

June, 2002 Lassi A. Tuura, Northeastern University 7 Domain Test Plan

June, 2002 Lassi A. Tuura, Northeastern University 8 Package Impact Diagram “Used-by” dependencies

June, 2002 Lassi A. Tuura, Northeastern University 9 An Extra Dependency Bad dependency in prototype code; was resolved to be from bad class placement 1IgSoReaderAppDriver  IgQtTwigBrowser via IgQtTwigModel.h 1IgSoReaderAppDriver  IgQtTwigBrowser via IgQtTwigRep.h

June, 2002 Lassi A. Tuura, Northeastern University 10 Static vs. Logical Logical dependencies from packages used through “Interfaces”

June, 2002 Lassi A. Tuura, Northeastern University 11 Discovering Forms of Modularity v A fairly good tool for discovering “philosophical structure” r IGUANA and Geant4 mostly use direct abstract interfaces – The interfaces normally generate “correct” functional dependencies: interface definitions are in packages that obviously imply the function r “Plug in one implementation of this interface” – Some use in Lizard/AIDA and ROOT r All interfaces bundled into “interface” (or framework) packages – Used by Lizard/AIDA and ROOT r Explicit dynamic loading to solve modularity issues – Used extensively by ROOT r Fall back on scripts or commands evaluated at run-time – Some use in Geant4 – Used quite a bit in ROOT

June, 2002 Lassi A. Tuura, Northeastern University 12 Analysis of Anaphe v Distribution of tools and utilities for LHC era physics r Combination of commercial, free and HEP software r Claims to be a toolkit v Appears to live up to its toolkit claims r Good work on modularity r Clean design is evident in many places r Dependency diagrams often split naturally into functional units

June, 2002 Lassi A. Tuura, Northeastern University 13 Analysis of ATLAS v Torture-test exercise for the tool r Large release size (~50% F77, ~50% mainly C++ but also C, Java) r Near the limit of Ignominy’s ability to discover software structure r Pictures below illustrate analysis difficulties v Visible (and known) problems r Many cleanly designed packages shadowed by a cycle with very unpleasant effects on the overall structure r A number of places show poor packaging and/or lack of abstract interfaces Known by build system Misconfigured analysis (1.3.2) Improved analysis (1.3.7)

June, 2002 Lassi A. Tuura, Northeastern University 14 Analysis of CMS/ORCA v Large C++ project v Deliberately fast development shows in places r Good design in key parts has helped v Recognised problems r Especially with the length of the release sequence r Clean-up/restructuring necessary soon – To some extent starting already v Large metric fluctuations from version to version ORCA Visualisation — needs most of the rest

June, 2002 Lassi A. Tuura, Northeastern University 15 Analysis of CMS/COBRA, IGUANA v COBRA r CMS Reconstruction, analysis and simulation framework r Recently successfully split off from ORCA r Quite many small packages íHas helped with modularity – Some issues with partitioning: some small cycles, certain package groups appear quite frequently v IGUANA r Generic data analysis environment with CMS focus r Many fairly small packages with targeted purpose (similar to Anaphe) r Project focus as an integrator and glue provider is fairly evident r We too have some rats nests to clean up, but at least they are small… r Has had the advantage of considerable monitoring!

June, 2002 Lassi A. Tuura, Northeastern University 16 Analysis of Geant4 v Fairly large C++ project r Very fine-grained (and multi-level) package structuring r Structure seems quite clean from the preliminary analysis v Fine package subdivision helps in many ways but makes analysis and code understanding more complicated v One subsystem seems strongly coupled and needs attention v Need to study the use of the internal command system

June, 2002 Lassi A. Tuura, Northeastern University 17 Analysis of ROOT v ROOT developers have done a formidable job of breaking binary (shared library) dependencies, but… r It makes dubious use of its internal scripting facility r 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) { […] TVirtualPS *psave = gVirtualPS; if (gROOT->LoadClass("TPostScript","Postscript")) return; gROOT->ProcessLineFast("new TPostScript()"); gVirtualPS->Open(psname,pstype); gVirtualPS->SetBit(kPrintingPS); […] } r 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 v Sign of fast growth? Need a “next evolutionary step”? r So “coherent” that replacing parts could get painful…

June, 2002 Lassi A. Tuura, Northeastern University 18 Analysis of ROOT… Binary only Binary + Source + Logical = Real

June, 2002 Lassi A. Tuura, Northeastern University 19 Package Metrics r Size = total amount of source code (roughly—not normalised across projects!) r ACD = average component dependency (~ libraries linked in) r CCD = sum of single-package component dependencies over whole release: test cost r 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 University 20 Metrics: NCCD vs Cycles Toolkits & Frameworks ATLAS ORCA4 Anaphe IGUANA COBRA G4 ROOT ORCA6

June, 2002 Lassi A. Tuura, Northeastern University 21 Metrics: NCCD vs Size Toolkits & Frameworks ATLAS ORCA4 Anaphe IGUANA COBRA G4 ROOT ORCA6

June, 2002 Lassi A. Tuura, Northeastern University 22 Metrics: NCCD vs ACD Toolkits & Frameworks ATLAS ORCA Anaphe IGUANA COBRA G4 ROOT

June, 2002 Lassi A. Tuura, Northeastern University 23 Metrics: NCCD vs AID Toolkits & Frameworks ATLAS ORCA Anaphe IGUANA COBRA G4 ROOT

June, 2002 Lassi A. Tuura, Northeastern University 24 Metrics: Packages vs Size Toolkits & Frameworks ATLAS ORCA6 Anaphe IGUANA COBRA G4 ROOT ORCA4

June, 2002 Lassi A. Tuura, Northeastern University 25 Metrics: Packages vs Size Toolkits & Frameworks ATLAS ORCA6 Anaphe IGUANA COBRA G4 ROOT ORCA4

June, 2002 Lassi A. Tuura, Northeastern University 26Caveats v Ignominy does only static dependencies, not dynamic ones r Indirect calls through pointers, virtual function calls r State dependencies: Data reads and writes, thread synchronisation, … v The analysis of external software is heuristic; exact information from the build system helps considerably v 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) r Most headaches so far with FORTRAN code v Ignominy must guess software structure when in doubt r Based on project-defined heuristic search rules, usually works fine r 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- generated dependency data!)

June, 2002 Lassi A. Tuura, Northeastern University 27Status v Run for every IGUANA release as a part of release build v Canned configuration for any SCRAM-based project r Needs project specific colouring etc. configurations v Works with many other project structures r Tried on G4, ROOT and ATLAS v Plans r Consolidate scripts and fold in all the documentation r Make it somewhat easier to use and configure r Java support with Mark Donszelmann’s jneeds v Available for free at r See the IGUANA distributions (latest = recommended) r Questions? Please mail or