ITK/Release 4/Modularization: Difference between revisions

From KitwarePublic
< ITK‎ | Release 4
Jump to navigationJump to search
No edit summary
 
(47 intermediate revisions by 4 users not shown)
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 of Modularization ==


1) Find / label / remove the trash in ITK.
1) Find / label / remove the trash in ITK.
Line 5: Line 26:
2) Organize the ~2,330 files into conceptual cohesive groups.
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,
3) Test and label each group according to measures of quality control :  
  dynamic testing, documentation...
Code coverage, correctness, style, dynamic testing, documentation...


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


5) Maintain that level of quality as more code is added to the toolkit.
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.
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]]


==  Latest Progress ==
== Information for ITK Users ==
[[ITK_Release_4/Modularization/Modulizer|How to get modularized ITK?]]
 


* [[ITK_Release_4/Modularization/Configure and build ITK|Configure and build ITK]]


What '''itk-developers''' need to know about contributing to modularized 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)]]


What '''users''' need to know about using modularized ITK?
* [[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==
== Development history==


Initial Goals [[ITK_Release_4/Modularization/Purposes|Steps and tools]]
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]]


Prototype [Iowa Meeting] [[ITK_Release_4/Modularization/Prototype|Prototype]]
Major progress report [Boston Meeting Feb 3, 2011]   [[Media:ITKBostonModularization.pptx|PPTX]]


TCon [[ITK_Release_4/Modularization/Tcon-2010-12-03|2010-12-03]]
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