ITK/Release 4/Modularization: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
(→Issues) |
(→Goals) |
||
Line 3: | Line 3: | ||
= Goals = | = Goals = | ||
* Organize the continuous growth of the Toolkit | * '''Organize the continuous growth of the Toolkit''' | ||
** Create system with a kernel base code and topic modules | ** Create system with a kernel base code and topic modules | ||
** Kernel very rigorously supported and developed | ** Kernel very rigorously supported and developed | ||
Line 9: | Line 9: | ||
** Core modules also rigorously supported | ** Core modules also rigorously supported | ||
** Extra modules less so | ** 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 | ** Package manager that allows user to choose exactly what functionality is desired | ||
** Modules exist along logical boundaries | ** Modules exist along logical boundaries |
Revision as of 19:03, 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)