Modularization

Goals

Organize the continuous growth of the Toolkit
- Create system with a kernel of base-level code and topic modules
  - Hierarchy of modules?
- Kernel very rigorously supported and developed
- Possibly two classes of modules: Core and Extra
- Core modules also rigorously supported
- Extra modules less so
Simplify usage for application developers
- Package manager that allows user to choose exactly what functionality is desired
- Modules exist along logical boundaries

Issues

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

Ryppl
- http://ryppl.org/
- Package Manager - Multi-Platform
  - Requirements

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)