ITK/Release 4/Modularization: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4
Jump to navigationJump to search
Line 36: Line 36:
= Tools =
= Tools =


== Ryppl ==
* ''' Ryppl '''
** http://ryppl.org/
** Package Manager - Multi-Platform
*** [http://ryppl.org/files/2010/07/IMG_1290.jpg Requirements]


* http://ryppl.org/
* ''' Source Navigator '''
* Package Manager - Multi-Platform
** http://sourcenav.berlios.de/
** [http://ryppl.org/files/2010/07/IMG_1290.jpg Requirements]
** Static analysis tool
 
** Builds detailed database of code elements and interactions
== Source Navigator ==
** Programmable tcl API (also c++ but less well documents and/or out of date)
* 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)

Revision as of 19:04, 30 July 2010

Modularization

Goals

  • Organize the continuous growth of the Toolkit
    • Create system with a kernel base code and topic 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

Tools

  • 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)