1. CHEP 2001 http://iguana.cern.chSeptember, 2001 Lassi A. Tuura, Northeastern University Analysing Software Dependencies With Ignominy Lucas Taylor Lassi A. Tuura Northeastern University, Boston

2. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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

3. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 3Examples See http://iguana.cern.ch/ 2_4_3/dependencies.html

4. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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)

5. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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, …

6. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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!)

7. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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)

8. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 8 Domain Test Plan

9. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 9 Package Impact Diagram “Used-by” dependencies

10. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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

11. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 11 Static vs. Logical Logical dependencies from packages used through “Interfaces”

12. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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

13. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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

14. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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)

15. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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

16. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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!

17. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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

18. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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…

19. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 19 Analysis of ROOT… Binary only Binary + Source + Logical = Real

20. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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

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

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

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

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

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

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

27. September, 2001 Lassi A. Tuura, Northeastern University http://iguana.cern.ch 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 http://iguana.cern.ch/http://iguana.cern.ch/ r See the IGUANA distributions (latest = 2.4.3 recommended) r For questions please mail lassi.tuura@cern.ch or iguana-interest@cern.chlassi.tuura@cern.chiguana-interest@cern.ch