ITK/Release 4/Modularization: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4
Jump to navigationJump to search
 
(74 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Why Modularization==
Modularization is a common design answer to the problem of managing complexity and growth.


'''Modularization'''
From the Linux Kernel:
http://www.ibm.com/developerworks/linux/library/l-lkm/index.html?ca=dgr-lnxw07LinuxLKM&S_TACT=105AGX59&S_CMP=GR


= Goals =
to KDE:
https://wiki.archlinux.org/index.php/KDE_Packages#Terminology


[[ITK_Release_4/Modularization/Goals|Goals]]
to Boost:
http://ryppl.github.com/index.html


* '''Organize the continuous growth of the Toolkit'''
to Qt:
** Create system with a kernel of base-level code and topic modules
http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/
*** Hierarchy of modules?
http://labs.qt.nokia.com/2011/01/21/status-of-qt-modularization/
** 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 =
Details on the goals of modularization were presented here: http://www.itk.org/Wiki/ITK_Release_4/Modularization/Tcon-2010-12-03
In particular in:
http://www.itk.org/Wiki/images/1/16/ITKv4-Modularization-2010-12-03.odp
http://www.itk.org/Wiki/images/7/75/ITKv4-Modularization-2010-12-03.pdf


* '''Automatic code analysis and initial segmentation'''
== Main  Goals of Modularization ==
** 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 =
1) Find / label / remove the trash in ITK.


* ''' Ryppl '''
2) Organize the ~2,330 files into conceptual cohesive groups.
** http://ryppl.org/
** Package Manager - Multi-Platform
*** [http://ryppl.org/files/2010/07/IMG_1290.jpg Requirements]
*** Same system should also be able to host modules (dlls and python scripts) for Slicer.   Does ParaView, VTK, IGSTK, VolView or any of our other systems plan on having modules (code, dlls, executables, data, tutorials, documents) that a user can single-click download during build (as a companion to cmake) or at runtime?
*** The primary upload should be to the IJ (along with the associated paper and data and testing results).  Once the code passes the IJ build process, it could then be made available via ryppl or the MIDAS API (web, c++, cdash).
*** Update the IJ build system (which sends dashboards as submission reviews) to also use ryppl.


* ''' Source Navigator '''
3) Test and label each group according to measures of quality control :
** http://sourcenav.berlios.de/
Code coverage, correctness, style, dynamic testing, documentation...
** Static analysis tool
 
** Builds detailed database of code elements and interactions
4) Raise the quality bar for critical components.
** Programmable tcl API (also c++ but less well documents and/or out of date)
For example, the itkObject must have 100% code coverage, while we could live with the Blox classes having 30%.
 
5) Maintain that level of quality as more code is added to the toolkit.
 
6) Facilitate the use of add-ons with ITK (External and Remote Modules) without having to include them in the toolkit.
 
== Module Dependency Visualization ==
 
* [[ITK_Release_4/Modularization/Module Dependency Visualization|Module Dependency Visualization]]
 
== Information for  ITK Users ==
 
* [[ITK_Release_4/Modularization/Configure and build ITK|Configure and build ITK]]
 
== Information for ITK Developers ==
* [[ITK_Release_4/Modularization/ Add tests|Add tests]]
 
* [[ITK_Release_4/Modularization/Add an external module (external module)|Add an External or Remote module]]
 
* [[ITK_Release_4/Modularization/ Add a module|Add a module (internal module)]]
 
* [[ITK_Release_4/Modularization/Add new classes|Add a new class]]
 
== A Collection of Use Cases ==
 
* [[ITK_Release_4/Modularization/Use Cases|Use Cases]]
 
== Code Reviews ==
 
* [[ITK_Release_4/Modularization/Code Reviews|Code Reviews]]
 
== Modular Dashboard ==
 
* [[ITK_Release_4/Modularization/Modular Dashboard|Modular Dashboard]]
 
== Development history==
 
Initial plan  [[ITK_Release_4/Modularization/Purposes|Steps and tools]]
 
Prototype  [Iowa Meeting, Nov, 2010]  [[ITK_Release_4/Modularization/Prototype|Prototype]]
 
Progress  report in TCon  [[ITK_Release_4/Modularization/Tcon-2010-12-03|2010-12-03]]
 
Major progress report [Boston Meeting  Feb 3, 2011]    [[Media:ITKBostonModularization.pptx|PPTX]]
 
Transition [[ITK_Release_4/Modularization/Transition Plan|Transition Plan]]

Latest revision as of 18:48, 14 July 2012

Why Modularization

Modularization is a common design answer to the problem of managing complexity and growth.

From the Linux Kernel: http://www.ibm.com/developerworks/linux/library/l-lkm/index.html?ca=dgr-lnxw07LinuxLKM&S_TACT=105AGX59&S_CMP=GR

to KDE: https://wiki.archlinux.org/index.php/KDE_Packages#Terminology

to Boost: http://ryppl.github.com/index.html

to Qt: http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/ http://labs.qt.nokia.com/2011/01/21/status-of-qt-modularization/

Details on the goals of modularization were presented here: http://www.itk.org/Wiki/ITK_Release_4/Modularization/Tcon-2010-12-03 In particular in: http://www.itk.org/Wiki/images/1/16/ITKv4-Modularization-2010-12-03.odp http://www.itk.org/Wiki/images/7/75/ITKv4-Modularization-2010-12-03.pdf

Main Goals of Modularization

1) Find / label / remove the trash in ITK.

2) Organize the ~2,330 files into conceptual cohesive groups.

3) Test and label each group according to measures of quality control : Code coverage, correctness, style, dynamic testing, documentation...

4) Raise the quality bar for critical components. For example, the itkObject must have 100% code coverage, while we could live with the Blox classes having 30%.

5) Maintain that level of quality as more code is added to the toolkit.

6) Facilitate the use of add-ons with ITK (External and Remote Modules) without having to include them in the toolkit.

Module Dependency Visualization

Information for ITK Users

Information for ITK Developers

A Collection of Use Cases

Code Reviews

Modular Dashboard

Development history

Initial plan Steps and tools

Prototype [Iowa Meeting, Nov, 2010] Prototype

Progress report in TCon 2010-12-03

Major progress report [Boston Meeting Feb 3, 2011] PPTX

Transition Transition Plan

Retrieved from "https://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Modularization&oldid=48395"