ITK/Release 4/Modularization/Purposes

• Automatic code analysis and initial segmentation
  • Develop accurate graph of code dependencies
    • Use "#include" as edge in graph
    • Need to remove unnecessary includes (non-trivial problem)
  • Segment the code into a kernel and modules
    • Use graph clustering/segmentation methods
    • Develop good cost function for the segmentation
    • High cost for code in the kernel
    • High cost for weak modular dependencies
• Manual segmentation improvement
  • Ensure that modules divided logically
  • Good granularity so that modules provide a benefit
    • Too many modules is too complex
    • Too few modules is pointless
    • Goal: ~20 modules
  • Only logical modular dependencies
    • "Advanced Registration" depends on "Registration" is OK
    • "Segmentation" depends on "Registration" because they share one non-kernel file is BAD

Tools

• Ryppl
  • http://ryppl.org/
  • Package Manager - Multi-Platform
    • Requirements
    • Same system should also be able to host modules (dlls and python scripts) for Slicer.   Does ParaView, VTK, IGSTK, VolView or any of our other systems plan on having modules (code, dlls, executables, data, tutorials, documents) that a user can single-click download during build (as a companion to cmake) or at runtime?
    • The primary upload should be to the IJ (along with the associated paper and data and testing results). Once the code passes the IJ build process, it could then be made available via ryppl or the MIDAS API (web, c++, cdash).
    • Update the IJ build system (which sends dashboards as submission reviews) to also use ryppl.

• Source Navigator
  • http://sourcenav.berlios.de/
  • Static analysis tool
  • Builds detailed database of code elements and interactions
  • Programmable tcl API (also c++ but less well documents and/or out of date)