sdt-book-2006 (1133574), страница 30
Текст из файла (страница 30)
Основные шаги реализации следующие.• Определить шаги обработки данных, необходимые для решения задач системы.Очередной шаг должен зависеть только от выходных данных предшествующегошага.• Определить форматы данных при их передаче по каждому каналу.• Определить способ реализации каждого канала, проталкивание или вытягиваниеданных, необходимость дополнительной буферизации и синхронизации.• Спроектировать и реализовать необходимый набор фильтров. Реализовать каналы,если для их представления нужны отдельные компоненты.• Спроектировать и реализовать обработку ошибок.
Обработку ошибок приприменении этого стиля достаточно тяжело организовать, поэтому ею частопренебрегают. Однако, требуется, как минимум, адекватная диагностикаслучающихся на разных этапах ошибок.Могут быть выделены специальные каналы для передачи сообщений об ошибках.При возникновении ошибок ввода соответствующий фильтр может игнорироватьдальнейшие входные данные до получения определенного разделителя,гарантирующего, что после него идут данные, не связанные с предыдущими.• Сконфигурировать необходимый конвейер обработки данных, собрав вместенужные фильтры и соединяющие их каналы.Следствия применения образца.Достоинства.• Промежуточные данные могут не храниться в файлах, но могут и храниться, еслиэто необходимо для каких-то дополнительных целей.• Фильтры можно легко заменять, переиспользовать, менять местами, переставлять икомбинировать, реализуя множество функций на основе одних и тех жекомпонентов.• Конвейерные системы обработки данных могут быть разработаны очень быстро,если имеется богатый набор фильтров.• Активные фильтры могут работать параллельно, давая в результате болееэффективное решение на многопроцессорных системах.101Недостатки.• Управление обработкой с помощью большого общего состояния, которое иногданеобходимо, не может быть эффективно реализовано с помощью этого стиля.• Часто параллельная обработка не приносит никакого повышенияпроизводительности, поскольку передача данных между фильтрами может бытьдостаточно дорогой, фильтры могут требовать всех входных данных, прежде чемвыдадут хоть что-то, и их синхронизация с помощью каналов может приводить кзначительным простоям.• Часто фильтры большее время тратят на преобразование формата поступающихвходных данных, чем на их обработку.
Использование одного формата, например,текстового, также зачастую снижает эффективность их использования.• Обработка ошибок в рамках данного стиля очень сложна. В том случае, еслиразрабатываемая система должна быть очень надежной, а возвращение к самомуначалу работы в случае обнаружения ошибки, так же как ее игнорирование неявляются допустимыми сценариями, использовать этот стиль не стоит.Примеры. Наиболее известный пример использования данного образца — система утилитUNIX [8], пополненная возможностями оболочки (shell) по организации каналов междупроцессами.
Большинство утилит могут играть роль фильтров при обработке текстовыхданных, а каналы строятся при помощи соединения стандартного ввода одной программысо стандартным выводом другой.Другим примером может служить часто используемая архитектура компилятора какпоследовательности фильтров, обрабатывающих входную программу — лексическогоанализатора (лексера), синтаксического анализатора (парсера), семантическогоанализатора, набора оптимизаторов и генератора результирующего кода. Таким способомможно достаточно быстро построить прототипный компилятор для несложного языка.Более производительные компиляторы, нацеленные на промышленное использование,строятся по более сложной схеме, в частности, используя элементы стиля «Репозиторий».Многоуровневая системаНазвание.
Многоуровневая система (layers).Назначение. Реализация больших систем, которые имеют большое количестворазноплановых элементов, использующих друг друга. Некоторые аспекты работы такихсистем могут включать в себя много операций, выполняемых разными компонентами наразных уровнях (т.е.
одна задача решается за счет последовательных обращений междуэлементами разных уровней, другая — тоже, но участвующие в решении этих задачэлементы могут быть различны). При этом нужно принимать во внимание следующиефакторы.Действующие силы.• Изменения в требованиях к решению одной из задач не должны приводит кизменениям в коде многочисленных компонентов, желательно, чтобы они сводилиськ изменениям внутри одного компонента. То же касается и изменений платформы,на которой работает система.• Интерфейсы между компонентами должны быть стабильными или дажесоответствовать имеющимся стандартам.• Части системы должны быть заменяемы.
Компоненты должны быть заменяемыдругими, если те реализуют такие же интерфейсы. В идеале может дажепотребоваться в ходе работы переключиться на другую реализацию, даже если приначале работы системы она не была доступна.• Низкоуровневые компоненты должны позволять разрабатывать другие системыбыстрее.102•Компоненты с похожими областями ответственности должны быть сгруппированыдля повышения понятности системы и удобства внесения в нее изменений.• Нет возможности выделить компоненты некоторого стандартного размера: одни изних решают достаточно сложные задачи, другие — совсем простые.• Сложные компоненты нуждаются в дальнейшей декомпозиции.• Использование большого числа компонентов может отрицательно сказаться напроизводительности, поскольку данным придется часто преодолевать границымежду компонентами.• Разработка системы должна быть эффективно поделена между отдельнымиразработчиками.
При этом интерфейсы и зоны ответственности компонентов,передаваемых разным разработчикам, должны быть очень четко определены.Решение. Выделяется некоторый набор уровней, каждый из которых отвечает за решениесвоих собственных подзадач. Для этого он использует интерфейс, предоставляемыйпредыдущим уровнем, предоставляя, в свою очередь, некоторый интерфейс дляследующего уровня.Каждый отдельный уровень может быть в дальнейшем декомпозирован на более мелкиекомпоненты.Структура.
Основными компонентами являются уровни. Иногда выделяют клиентов,использующих интерфейс самого верхнего уровня. Каждый уровень предоставляетинтерфейс для решения определенного множества задач. Сам он решает их, опираясь наинтерфейс предшествующего уровня.На каждом уровне может находиться много более мелких компонентов.Рисунок 49.
Пример структуры многоуровневой системы. Классы для уровней условные, они обычнодекомпозируются на наборы более мелких компонентов.Динамика. Сценарии работы системы могут быть получены компоновкой следующихчетырех. Часто в виде многих уровней реализуются коммуникационные системы, две такиесистемы могут взаимодействовать через самый нижний уровень — при этом парасимметричных сценариев (по подъему-спуску обращений) выполняется в рамках одногообщего сценария на разных машинах.• Обращение клиента к верхнему уровню инициирует цепочку обращений с верхнегоуровня до самого нижнего.• Событие на нижнем уровне (например, приход сообщения по сети или нажатие накнопку мыши) инициирует цепочку обращений, идущую снизу вверх, вплоть донекоторого события самого верхнего уровня, видимого клиентам.• Обращение клиента к верхнему уровню приводит к цепочке вызовов, которая,однако, не доходит до самого низа.
Такая ситуация реализуется, если, например,один из уровней кэширует ответы на запросы и может выдать ответ на ранее ужеподававшийся запрос без обращения к более низким уровням.103•То же самое может произойти и с событием, которое передается с самого нижнегоуровня. Дойдя до некоторого уровня, оно может поглотиться им (с изменениемсостояния каких-то компонентов), потому что не соответствует никакому событиюна более высоких уровнях. Например, нажатие клавиши Capslock не приводит самопо себе ни к каким реакциям программы, но изменяет значение нажимаемых послеэтого клавиш, меняя их регистр на противоположный.ClientLayer 2sendmessagesendpacketsendpacketLayer 1send rawdatasend rawdataLayer 1Layer 2ClientreceivepacketreceivepacketreceivemessageРисунок 50. Составной сценарий пересылки сообщения по сети.Реализация.
Основные шаги реализации следующие.• Определить критерии группировки задач по уровням. Это критически важный шаг.Неправильное распределение задач, скорее всего, приведет к необходимостиперепроектировать систему.• Определить количество уровней, которые будут реализованы, и их имена. Частоприходится объединять концептуально различные задачи, чтобы добиться большейэффективности системы. С другой стороны, произвольное смешение задач на уровневедет к непонятной архитектуре и к системе, очень неудобной для сопровождения.При возможности поместить некоторую задачу на несколько уровней, стоитразмещать ее на самом высоком уровне из тех, где она может быть решена сдостаточной производительностью.• Определить интерфейсы, предоставляемые нижними уровнями верхним.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
