ITK/Release 4/Modularization: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
No edit summary |
(→Issues) |
||
Line 15: | Line 15: | ||
= Issues = | = Issues = | ||
* '''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''' | |||
** 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
- Develop accurate graph of code 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
- 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)