ITK/Release 4/Modularization: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4
Jump to navigationJump to search
No edit summary
No edit summary
Line 1: Line 1:
==  Goals ==
== 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 ==


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

Revision as of 23:19, 5 February 2011

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

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 without having to include them in the toolkit.

Latest Progress

How to get modularized ITK?


What itk-developers need to know about contributing to modularized ITK?


What users need to know about using modularized ITK?

Development history

Initial Goals Steps and tools

Prototype [Iowa Meeting] Prototype

TCon 2010-12-03