ITK

Оригинал: ITK
Авторы: Luis Ibanez, Brad King
Перевод: А.Панин

Модульность

Модульность является одной из основных характеристик ITK. Это требование, которое вытекает из метода работы членов сообщества специалистов по анализу изображений при решении поставленных перед ними задач. Большинство задач по анализу изображений подразумевает обработку одного или нескольких изображений с помощью комбинации фильтров для улучшения качества или выделения определенной информации из изображения. Следовательно, не существует одного большого объекта для обработки изображений, а вместо него используется несметное количество малых объектов. Из этого структурного характера задачи обработки изображений логически вытекает необходимость реализации программного обеспечения в виде большой коллекции фильтров для обработки изображений, которые могут комбинироваться различными способами.

Также в данном случае некоторые фильтры для обработки изображений объединяются в семейства, внутри которых некоторые из особенностей их реализации могут отличаться. Это позволяет произвести изначальное разделение фильтров для обработки изображений на модули и группы модулей.

Рисунок 9.3: Иерархическая структура групп, модулей и классов

На уровне групп производится в большей степени концептуальное деление, не зависящее от характеристик программного обеспечения и упрощающее поиск фильтров в дереве исходного кода. Группы ассоциированы с такими высокоуровневыми концепциями, как фильтрация (Filtering), сегментация (Segmentation), геометрическая коррекция (Registration) и ввод/вывод (IO). Иерархическая структура показана на Рисунке 9.3. В данный момент в комплекте поставки ITK насчитывается 124 модуля, которые в свою очередь распределены между 13 основными группами. Модули значительно различаются в размерах. Распределение размеров модулей в байтах отображено на Рисунке 9.4.

Рисунок 9.4: Распределение размеров 50 наиболее больших модулей ITK в КБ

Применяющийся в ITK модульный подход также справедлив и в случае сторонних библиотек, которые не являются частью тулкита, но от которых зависит его работа и которые распространяются в комплекте поставки тулкита вместе с остальным кодом для удобства пользователей. Отдельными примерами этих сторонних библиотек являются библиотеки для работы с файлами изображений различных форматов: HDF5, PNG, TIFF, JPEG и OpenJPEG, а также другие. Вопрос о сторонних библиотеках поднимается по той причине, что на их счет приходится около 56 процентов размера комплекта поставки ITK. Это обстоятельство отражает обычной подход, применяемый при сборке приложений с открытым исходным кодом для существующих платформ. Распределение размеров сторонних библиотек не обязательно соответствует архитектурным особенностям ITK, так как мы используем эти полезные библиотеки в том виде, в каком они были разработаны. Однако, сторонний код перераспределяется вместе с кодом тулкита и его отделение являлось одной из ключевых директив процесса формирования модулей.

Распределение размеров модулей было приведено выше, так как оно является мерой качества разделения кода на модули. Можно заметить, что модульность кода представлена в виде непрерывного диапазона от экстремума, соответствующего расположению всего кода в одном модуле в виде монолитной версии до экстремума разделения всего кода на очень большой набор модулей одинакового размера. Распределение размеров было инструментом, используемым для отслеживания степени выполнения процесса разделения кода на модули, особенно для уверенности в том, что не было оставлено больших блоков кода в одном и том же модуле в случае, когда не имеется реальных логических зависимостей для такой группировки.

Процесс разделения кода на модули позволил четко идентифицировать и описать зависимости между различными частями тулкита, так как они были перенесены в модули. Во многих случаях эта деятельность позволила выявить искусственные или некорректные зависимости, которые были заданы в рамках тулкита в течение длительного промежутка времени и не были замечены тогда, когда большая часть кода находилась в файлах из нескольких групп большого размера.

Польза от получения качественных параметров двояка. Во-первых, появляется возможность сделать разработчиков ответственными за модули, развитие которых они поддерживают. Во-вторых, появляется возможность занятия инициативами по очистке кода, в ходе которых несколько разработчиков в течение короткого времени работают над повышением качества определенного модуля. При работе с небольшими частями тулкита проще оценивать эффективность своей работы и поддерживать интерес и мотивацию разработчиков.

В качестве повторения отменим, что структура тулкита отражает организацию сообщества разработчиков, а также в некоторых случаях процессы, которые были введены для постоянного развития и контроля качества программного обеспечения.

Продолжение статьи: Конвейер данных