ITK/Release 4/Modularization: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4
Jump to navigationJump to search
No edit summary
Line 15: Line 15:
= Issues =
= Issues =


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


= Tools =
= Tools =

Revision as of 19:02, 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

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)