ITK/Release 4/Modularization: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
(→Goals) |
No edit summary |
||
Line 4: | Line 4: | ||
* Organize the continuous growth of the Toolkit | * 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 | * Simplify usage for application developers | ||
** | ** Package manager that allows user to choose exactly what functionality is desired | ||
** Modules exist along logical boundaries | |||
** | |||
= 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
- 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)