Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

Наши друзья и партнеры

UnixForum
Беспроводные выключатели nooLite купить дешевый 
компьютер родом из Dhgate.com

Lines Club

Ищем достойных соперников.

Библиотека сайта или "Мой Linux Documentation Project"

ITK

Глава 9 из книги "Архитектура приложений с открытым исходным кодом", том 2.

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

Модульность

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

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

Следовательно, модульность реализуется на трех основных уровнях в рамках ITK:
  • Уровень фильтра
  • Уровень семейства фильтров
  • Уровень группы семейств фильтров
На уровне фильтра обработки изображений ITK содержит около 700 фильтров. Учитывая то, что фреймворк ITK реализован с использованием языка программирования C++, это уровень, на котором каждый из этих фильтров реализован с помощью класса C++ в соответствии с шаблонами объектно-ориентированного проектирования. На уровне семейства фильтров ITK группирует фильтры в соответствии с характером обработки изображения, которую они выполняют. Например, все фильтры, выполняющие преобразования Фурье, будут объединены в рамках модуля. На уровне языка C++ модули ставятся в соответствие директориям в дереве исходного кода и библиотекам после компиляции исходного кода в бинарный формат. ITK содержит около 120 таких модулей. Каждый модуль содержит:
  1. Исходный код фильтров изображений, принадлежащих рассматриваемому семейству.
  2. Набор файлов конфигурации, которые описывают метод сборки модуля и содержат список зависимостей между рассматриваемым и сторонними модулями.
  3. Набор модульных тестов, соответствующих каждому из фильтров.

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

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

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

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

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

Модульная архитектура ITK позволяет выполнить и упрощает:
  • Сокращение количества и четкое выявление зависимостей между модулями
  • Принятие кода от сообщества разработчиков
  • Определение качественных параметров модуля (например, степени покрытия кода)
  • Сборку выбранных частей тулкита
  • Упаковку выбранных частей тулкита для повторного распространения
  • Поддержание постоянного развития тулкита путем добавления новых модулей

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

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

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


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


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

Комментарии отсутствуют