Lecture07 (1133564), страница 4
Текст из файла (страница 4)
Использование одного формата, например,текстового, также зачастую снижает эффективность их использования.• Обработка ошибок в рамках данного стиля очень сложна. В том случае, еслиразрабатываемая система должна быть очень надежной, а возвращение к самомуначалу работы в случае обнаружения ошибки, так же как ее игнорирование неявляются допустимыми сценариями, использовать этот стиль не стоит.Примеры. Наиболее известный пример использования данного образца — система утилитUNIX [8], пополненная возможностями оболочки (shell) по организации каналов междупроцессами.
Большинство утилит могут играть роль фильтров при обработке текстовыхданных, а каналы строятся при помощи соединения стандартного ввода одной программысо стандартным выводом другой.Другим примером может служить часто используемая архитектура компилятора какпоследовательности фильтров, обрабатывающих входную программу — лексическогоанализатора (лексера), синтаксического анализатора (парсера), семантическогоанализатора, набора оптимизаторов и генератора результирующего кода.
Таким способомможно достаточно быстро построить прототипный компилятор для несложного языка.Более производительные компиляторы, нацеленные на промышленное использование,строятся по более сложной схеме, в частности, используя элементы стиля «Репозиторий».Многоуровневая системаНазвание. Многоуровневая система (layers).Назначение. Реализация больших систем, которые имеют большое количестворазноплановых элементов, использующих друг друга. Некоторые аспекты работы такихсистем могут включать в себя много операций, выполняемых разными компонентами наразных уровнях (т.е. одна задача решается за счет последовательных обращений междуэлементами разных уровней, другая — тоже, но участвующие в решении этих задачэлементы могут быть различны). При этом нужно принимать во внимание следующиефакторы.Действующие силы.• Изменения в требованиях к решению одной из задач не должны приводит кизменениям в коде многочисленных компонентов, желательно, чтобы они сводилиськ изменениям внутри одного компонента.
То же касается и изменений платформы,на которой работает система.• Интерфейсы между компонентами должны быть стабильными или дажесоответствовать имеющимся стандартам.• Части системы должны быть заменяемы. Компоненты должны быть заменяемыдругими, если те реализуют такие же интерфейсы. В идеале может дажепотребоваться в ходе работы переключиться на другую реализацию, даже если приначале работы системы она не была доступна.• Низкоуровневые компоненты должны позволять разрабатывать другие системыбыстрее.• Компоненты с похожими областями ответственности должны быть сгруппированыдля повышения понятности системы и удобства внесения в нее изменений.• Нет возможности выделить компоненты некоторого стандартного размера: одни изних решают достаточно сложные задачи, другие — совсем простые.• Сложные компоненты нуждаются в дальнейшей декомпозиции.• Использование большого числа компонентов может отрицательно сказаться напроизводительности, поскольку данным придется часто преодолевать границымежду компонентами.• Разработка системы должна быть эффективно поделена между отдельнымиразработчиками.
При этом интерфейсы и зоны ответственности компонентов,передаваемых разным разработчикам, должны быть очень четко определены.Решение. Выделяется некоторый набор уровней, каждый из которых отвечает за решениесвоих собственных подзадач. Для этого он использует интерфейс, предоставляемыйпредыдущим уровнем, предоставляя, в свою очередь, некоторый интерфейс дляследующего уровня.Каждый отдельный уровень может быть в дальнейшем декомпозирован на более мелкиекомпоненты.Рисунок 49.
Пример структуры многоуровневой системы. Классы для уровней условные, они обычнодекомпозируются на наборы более мелких компонентов.Структура. Основными компонентами являются уровни. Иногда выделяют клиентов,использующих интерфейс самого верхнего уровня. Каждый уровень предоставляетинтерфейс для решения определенного множества задач.
Сам он решает их, опираясь наинтерфейс предшествующего уровня.На каждом уровне может находиться много более мелких компонентов.Динамика. Сценарии работы системы могут быть получены компоновкой следующихчетырех. Часто в виде многих уровней реализуются коммуникационные системы, две такиесистемы могут взаимодействовать через самый нижний уровень — при этом парасимметричных сценариев (по подъему-спуску обращений) выполняется в рамках одногообщего сценария на разных машинах.• Обращение клиента к верхнему уровню инициирует цепочку обращений с верхнегоуровня до самого нижнего.• Событие на нижнем уровне (например, приход сообщения по сети или нажатие накнопку мыши) инициирует цепочку обращений, идущую снизу вверх, вплоть донекоторого события самого верхнего уровня, видимого клиентам.• Обращение клиента к верхнему уровню приводит к цепочке вызовов, которая,однако, не доходит до самого низа.
Такая ситуация реализуется, если, например,один из уровней кэширует ответы на запросы и может выдать ответ на ранее ужеподававшийся запрос без обращения к более низким уровням.• То же самое может произойти и с событием, которое передается с самого нижнегоуровня. Дойдя до некоторого уровня, оно может поглотиться им (с изменениемсостояния каких-то компонентов), потому что не соответствует никакому событиюна более высоких уровнях. Например, нажатие клавиши Capslock не приводит самопо себе ни к каким реакциям программы, но изменяет значение нажимаемых послеэтого клавиш, меняя их регистр на противоположный.ClientLayer 2sendmessagesendpacketsendpacketLayer 1send rawdatasend rawdataLayer 1Layer 2ClientreceivepacketreceivepacketreceivemessageРисунок 50. Составной сценарий пересылки сообщения по сети.Реализация.
Основные шаги реализации следующие.• Определить критерии группировки задач по уровням. Это критически важный шаг.Неправильное распределение задач, скорее всего, приведет к необходимостиперепроектировать систему.• Определить количество уровней, которые будут реализованы, и их имена. Частоприходится объединять концептуально различные задачи, чтобы добиться большейэффективности системы. С другой стороны, произвольное смешение задач на уровневедет к непонятной архитектуре и к системе, очень неудобной для сопровождения.При возможности поместить некоторую задачу на несколько уровней, стоитразмещать ее на самом высоком уровне из тех, где она может быть решена сдостаточной производительностью.•Определить интерфейсы, предоставляемые нижними уровнями верхним.
Здесьнужно помнить, что с помощью несколько большего, чем минимальнонеобходимый, набора интерфейсных операций нижнего уровня можно добитьсязначительного повышения производительности системы в целом.• Определить компоненты и их взаимодействие в рамках каждого отдельного уровня.• Определить способы взаимодействия соседних уровней.
Можно использоватьпроталкивание, вытягивание данных или комбинацию этих подходов.• Отделить соседние уровни. В идеале нижние уровни не должны знать ничего оверхних, каждый уровень должен знать только о непосредственно предшествующемему. Для этого передачу данных с нижнего уровня можно организовать в видеобратных вызовов (callbacks) — указатель на функцию, которую нужно вызвать дляпередачи сообщения наверх, верхний уровень может передавать в качествепараметра при предшествующих запросах.• Спроектировать и реализовать обработку ошибок. Ошибки лучше обрабатывать насамом нижнем уровне, который в состоянии их заметить.Следствия применения образца.Достоинства.• Возможность легко заменять и переиспользовать компоненты одного уровня, неоказывая влияния на остальные уровни.
Возможность отлаживать и тестироватьуровни по отдельности.• Поддержка стандартов. Многоуровневость системы делает возможной поддержкустандартных интерфейсов, таких как POSIX.Недостатки.• Изменение функциональности одного уровня может привести к каскадномуизменению всех уровней. Существенный рост производительности нижнего уровняи требование обеспечить соответствующий рост производительности на болеевысоких уровнях также могут привести к переопределению всех интерфейсов.• Падение производительности из-за необходимости все вызовы и данные проводитьчерез все уровни.• Часто уровни дублируют работу друг друга, например, при обработке ошибок,поскольку они разрабатываются независимо и не имеют информации о деталяхреализации друг друга.• Большое количество уровней может привести к существенному повышениюсложности системы и падению ее производительности.
С другой стороны, слишкоммалое число уровней (например, два) часто не позволяет обеспечить необходимуюгибкость и переносимость.Примеры. Наиболее известный пример использования данного образца — стандартнаямодель протоколов связи открытых систем (Open System Interconnection, OSI) [9]. Онасостоит из 7-ми уровней.• Самый нижний уровень — физический. Он отвечает за передачу отдельных битов поканалам связи.
Основные его задачи — гарантировать правильное определение нуляи единицы разными системами, определить временные характеристики передачи (закакое время передается один бит), обеспечить передачу в одном или двухнаправлениях, и т.п.• Второй уровень — канальный или уровень передачи данных. Его задача —предоставить верхним уровням такие сервисы, чтобы для них передача данныхвыглядела бы как посылка и прием потока байт без потерь и без перегрузок.•Третий уровень — сетевой.
Его задача — обеспечить прозрачную связь междукомпьютерами, не соединенными непосредственно, а также обеспечиватьнормальную работу больших сетей, по которым одновременно путешествует оченьмного пакетов данных.• Четвертый уровень — транспортный. Он обеспечивает надежную передачу данныхверхних уровней словно по некоторой трубе — пакеты приходят обязательно в тойже последовательности, в которой они были отправлены. Заметим, что канальныйуровень решает такую же задачу, но только для непосредственно связывающихсядруг с другом машин.• Пятый, сеансовый уровень предоставляет возможность устанавливать сеансы связи(или сессии), содержащие некоторый набор передаваемых туда и обратносообщений, и управлять ими.• Шестой, уровень представления, определяет форматы передаваемых данных.Например, именно здесь определяется, что целое число будет представляться 4-мябайтами, причем старшие биты числа идут раньше младших, первый битинтерпретируется как знак, а отрицательные числа представляются вдополнительной системе (т.е.
0x0000000f обозначает 15, а 0x80000000f —-2147483633 = -(231-15)).• Наконец, седьмой уровень — прикладной — содержит набор протоколов, которыминепосредственно пользуются программы и с которыми работают пользователи —HTTP, FTP, SMTP, POP3 и пр.Модель OSI оказалась все же слишком сложна для использования на практике. Сейчаснаиболее широко применяемые наборы протоколов строятся по урезанной схеме OSI — вней отсутствуют пятый и шестой уровни, прикладные протоколы пользуютсянепосредственно службами протоколов транспортного уровня.Другой пример многоуровневой архитектуры — архитектура современныхинформационных систем или систем автоматизации бизнеса. Она включает следующиеуровни [3].• Интерфейс взаимодействия с внешней средой.Чаще всего этот уровень рассматривается как интерфейс пользователя.
В его рамкахопределяется представление данных для передачи другим системам илипользователям, набор экранов, форм и отчетов, с которыми имеют делопользователи.• Бизнес-логика. На этом уровне реализуются основные правила функционированияданного бизнеса, данной организации.• Предметная область. Данный уровень содержит концептуальную схему данных, скоторыми имеет дело организация. Эти же данные могут использоваться и другимиорганизациями в своей работе.• Уровень управления ресурсами.На нем находятся все ресурсы, которыми пользуется система, в том числе другиесистемы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
