В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 31
Текст из файла (страница 31)
Фильтр обычно потребляет и выдает данные некоторыми порциями.Канал обеспечивает передачу данных, их буферизацию и синхронизацию обработки ихсоседними фильтрами (например, если оба соседних фильтра активны, работают впараллельных процессах). Если никакой дополнительный буферизации и синхронизации нетребуется, канал может представлять собой простую передачу данных в виде параметраили результата вызова операции.99Рисунок 45. Пример структуры классов для образца каналы и фильтры.На Рис.
45 показан пример диаграммы классов для данного образца, в котором 3 каналареализованы неявно — через вызовы операций и возвращение результатов, а один — явно.Из участвующих в этом примере фильтров источник и потребитель данных, а также Filter 1запрашивают входные данные, Filter 3 сам передает их дальше, а Filter 2 и запрашивает, ипередает данные самостоятельно.Filter 1Filter 2send dataFilter 3process datasend dataРисунок 46. Сценарий работы проталкивающего фильтра.Filter 1Filter 2get dataFilter 3get dataprocess dataРисунок 47.
Сценарий работы вытягивающего фильтра.Динамика. Возможны три различных сценария работы одного фильтра — проталкиваниеданных (push model, фильтр сам передает данные следующему компоненту, а получает ихтолько в результате передачи предыдущего), вытягивание данных (pull model, фильтртребует данные у предыдущего компонента, следующий сам должен затребовать данные у100него) и смешанный вариант. Часто реализуется только один вид передачи данных для всехфильтров в рамках системы.
Кроме того, канал может буферизовать данные исинхронизовать взаимодействующие с ним фильтры. Сценарии работы системы в целомстроятся в виде различных комбинаций вариантов работы отдельных фильтров.Filter 1Pipeprocess dataFilter 2read datawrite dataprocess datawrite dataprocess dataread dataРисунок 48. Сценарий работы буферизующего и синхронизующего канала.Реализация. Основные шаги реализации следующие.• Определить шаги обработки данных, необходимые для решения задач системы.Очередной шаг должен зависеть только от выходных данных предшествующегошага.• Определить форматы данных при их передаче по каждому каналу.• Определить способ реализации каждого канала, проталкивание или вытягиваниеданных, необходимость дополнительной буферизации и синхронизации.• Спроектировать и реализовать необходимый набор фильтров.
Реализовать каналы,если для их представления нужны отдельные компоненты.• Спроектировать и реализовать обработку ошибок. Обработку ошибок приприменении этого стиля достаточно тяжело организовать, поэтому ею частопренебрегают. Однако, требуется, как минимум, адекватная диагностикаслучающихся на разных этапах ошибок.Могут быть выделены специальные каналы для передачи сообщений об ошибках.При возникновении ошибок ввода соответствующий фильтр может игнорироватьдальнейшие входные данные до получения определенного разделителя,гарантирующего, что после него идут данные, не связанные с предыдущими.• Сконфигурировать необходимый конвейер обработки данных, собрав вместенужные фильтры и соединяющие их каналы.Следствия применения образца.Достоинства.• Промежуточные данные могут не храниться в файлах, но могут и храниться, еслиэто необходимо для каких-то дополнительных целей.• Фильтры можно легко заменять, переиспользовать, менять местами, переставлять икомбинировать, реализуя множество функций на основе одних и тех жекомпонентов.• Конвейерные системы обработки данных могут быть разработаны очень быстро,если имеется богатый набор фильтров.• Активные фильтры могут работать параллельно, давая в результате болееэффективное решение на многопроцессорных системах.101Недостатки.• Управление обработкой с помощью большого общего состояния, которое иногданеобходимо, не может быть эффективно реализовано с помощью этого стиля.• Часто параллельная обработка не приносит никакого повышенияпроизводительности, поскольку передача данных между фильтрами может бытьдостаточно дорогой, фильтры могут требовать всех входных данных, прежде чемвыдадут хоть что-то, и их синхронизация с помощью каналов может приводить кзначительным простоям.• Часто фильтры большее время тратят на преобразование формата поступающихвходных данных, чем на их обработку.
Использование одного формата, например,текстового, также зачастую снижает эффективность их использования.• Обработка ошибок в рамках данного стиля очень сложна. В том случае, еслиразрабатываемая система должна быть очень надежной, а возвращение к самомуначалу работы в случае обнаружения ошибки, так же как ее игнорирование неявляются допустимыми сценариями, использовать этот стиль не стоит.Примеры.
Наиболее известный пример использования данного образца — система утилитUNIX [8], пополненная возможностями оболочки (shell) по организации каналов междупроцессами. Большинство утилит могут играть роль фильтров при обработке текстовыхданных, а каналы строятся при помощи соединения стандартного ввода одной программысо стандартным выводом другой.Другим примером может служить часто используемая архитектура компилятора какпоследовательности фильтров, обрабатывающих входную программу — лексическогоанализатора (лексера), синтаксического анализатора (парсера), семантическогоанализатора, набора оптимизаторов и генератора результирующего кода.
Таким способомможно достаточно быстро построить прототипный компилятор для несложного языка.Более производительные компиляторы, нацеленные на промышленное использование,строятся по более сложной схеме, в частности, используя элементы стиля «Репозиторий».Многоуровневая системаНазвание. Многоуровневая система (layers).Назначение. Реализация больших систем, которые имеют большое количестворазноплановых элементов, использующих друг друга. Некоторые аспекты работы такихсистем могут включать в себя много операций, выполняемых разными компонентами наразных уровнях (т.е.
одна задача решается за счет последовательных обращений междуэлементами разных уровней, другая — тоже, но участвующие в решении этих задачэлементы могут быть различны). При этом нужно принимать во внимание следующиефакторы.Действующие силы.• Изменения в требованиях к решению одной из задач не должны приводит кизменениям в коде многочисленных компонентов, желательно, чтобы они сводилиськ изменениям внутри одного компонента. То же касается и изменений платформы,на которой работает система.• Интерфейсы между компонентами должны быть стабильными или дажесоответствовать имеющимся стандартам.• Части системы должны быть заменяемы. Компоненты должны быть заменяемыдругими, если те реализуют такие же интерфейсы. В идеале может дажепотребоваться в ходе работы переключиться на другую реализацию, даже если приначале работы системы она не была доступна.• Низкоуровневые компоненты должны позволять разрабатывать другие системыбыстрее.102•Компоненты с похожими областями ответственности должны быть сгруппированыдля повышения понятности системы и удобства внесения в нее изменений.• Нет возможности выделить компоненты некоторого стандартного размера: одни изних решают достаточно сложные задачи, другие — совсем простые.• Сложные компоненты нуждаются в дальнейшей декомпозиции.• Использование большого числа компонентов может отрицательно сказаться напроизводительности, поскольку данным придется часто преодолевать границымежду компонентами.• Разработка системы должна быть эффективно поделена между отдельнымиразработчиками.
При этом интерфейсы и зоны ответственности компонентов,передаваемых разным разработчикам, должны быть очень четко определены.Решение. Выделяется некоторый набор уровней, каждый из которых отвечает за решениесвоих собственных подзадач. Для этого он использует интерфейс, предоставляемыйпредыдущим уровнем, предоставляя, в свою очередь, некоторый интерфейс дляследующего уровня.Каждый отдельный уровень может быть в дальнейшем декомпозирован на более мелкиекомпоненты.Структура. Основными компонентами являются уровни. Иногда выделяют клиентов,использующих интерфейс самого верхнего уровня. Каждый уровень предоставляетинтерфейс для решения определенного множества задач.