CHEP Lassi A. Tuura, Northeastern University Analysing Software Dependencies With Ignominy Lucas Taylor Lassi A. Tuura Northeastern University, Boston

September, 2001 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

September, 2001 Lassi A. Tuura, Northeastern University 3Examples See 2_4_3/dependencies.html

September, 2001 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)

September, 2001 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, …

September, 2001 Lassi A. Tuura, Northeastern University 6Caveats 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!)

September, 2001 Lassi A. Tuura, Northeastern University 7 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)

September, 2001 Lassi A. Tuura, Northeastern University 8 Domain Test Plan

September, 2001 Lassi A. Tuura, Northeastern University 9 Package Impact Diagram “Used-by” dependencies

September, 2001 Lassi A. Tuura, Northeastern University 10 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

September, 2001 Lassi A. Tuura, Northeastern University 11 Static vs. Logical Logical dependencies from packages used through “Interfaces”

September, 2001 Lassi A. Tuura, Northeastern University 12 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

September, 2001 Lassi A. Tuura, Northeastern University 13 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

September, 2001 Lassi A. Tuura, Northeastern University 14 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)

September, 2001 Lassi A. Tuura, Northeastern University 15 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 ORCA Visualisation — needs most of the rest

September, 2001 Lassi A. Tuura, Northeastern University 16 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!

September, 2001 Lassi A. Tuura, Northeastern University 17 Analysis of Geant4 v Fairly large C++ project r Very fine-grained (and multi-level) package structuring r 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

September, 2001 Lassi A. Tuura, Northeastern University 18 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…

September, 2001 Lassi A. Tuura, Northeastern University 19 Analysis of ROOT… Binary only Binary + Source + Logical = Real

September, 2001 Lassi A. Tuura, Northeastern University 20 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 – Indicates testing/integration cost r NCCD = Measure of CCD compared to a balanced binary tree – A good toolkit’s NCCD will be close to 1.0 – < 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

September, 2001 Lassi A. Tuura, Northeastern University 21 Metrics: NCCD vs Cycles Toolkits & Frameworks ATLAS ORCA Anaphe IGUANA COBRA G4 ROOT

September, 2001 Lassi A. Tuura, Northeastern University 22 Metrics: NCCD vs Size Toolkits & Frameworks ATLAS ORCA Anaphe IGUANA COBRA G4 ROOT

September, 2001 Lassi A. Tuura, Northeastern University 23 Metrics: NCCD vs ACD Toolkits & Frameworks ATLAS ORCA Anaphe IGUANA COBRA G4 ROOT

September, 2001 Lassi A. Tuura, Northeastern University 24 Metrics: NCCD vs AID Toolkits & Frameworks ATLAS ORCA AnapheIGUANA COBRA G4 ROOT

September, 2001 Lassi A. Tuura, Northeastern University 25 Metrics: Packages vs Size Toolkits & Frameworks ATLAS ORCA Anaphe IGUANA COBRA G4 ROOT

September, 2001 Lassi A. Tuura, Northeastern University 26 Metrics: Packages vs Size Toolkits & Frameworks ATLAS ORCA Anaphe IGUANA COBRA G4 ROOT

September, 2001 Lassi A. Tuura, Northeastern University 27Summary v Ignominy is a rather simple tool—and as such tremendously helpful in keeping a project on track r Especially for keeping external software in check r Also for giving hard facts about the project itself v It provides tools to study a software system structure r It should not be used blindly, results must be understood and interpreted correctly; a human is certainly required! r We find it valuable—output is now a part of our release documentation v It doesn’t do everything, but what it does, it seeks to do well r Feedback, suggestions for improvements etc. would be most welcome! r Planning to add support for Java v Available for free at r See the IGUANA distributions (latest = recommended) r For questions please mail or