ITK/Release 4/Modularization: Difference between revisions

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


* Organize the continuous growth of the Toolkit
* Organize the continuous growth of the Toolkit
** Develop accurate graph of code dependencies
** Create system with a kernel base code and topic modules
*** Use "#include" as edge in graph
** Kernel very rigorously supported and developed
*** Need to remove unnecessary includes (non-trivial problem)
** Possibly two classes of modules: Core and Extra
** Segment the code into a kernel and modules
** Core modules also rigorously supported
*** Code in the kernel will be rigorously maintained
** Extra modules less so
*** High cost for code in the kernel
*** Modules will be divided by firm boundaries
* Simplify usage for application developers
* Simplify usage for application developers
** Modules divided logically
** Package manager that allows user to choose exactly what functionality is desired
** Good granularity so that modules provide a beneft
** Modules exist along logical boundaries
*** 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


= Issues =
= 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 =
= Tools =

Revision as of 18:54, 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)