В.В. Кулямин - Технологии программирования. Компонентный подход (1134162), страница 32
Текст из файла (страница 32)
Сам он решает их, опираясь наинтерфейс предшествующего уровня.На каждом уровне может находиться много более мелких компонентов.Рисунок 49. Пример структуры многоуровневой системы. Классы для уровней условные, они обычнодекомпозируются на наборы более мелких компонентов.Динамика. Сценарии работы системы могут быть получены компоновкой следующихчетырех. Часто в виде многих уровней реализуются коммуникационные системы, две такиесистемы могут взаимодействовать через самый нижний уровень — при этом парасимметричных сценариев (по подъему-спуску обращений) выполняется в рамках одногообщего сценария на разных машинах.• Обращение клиента к верхнему уровню инициирует цепочку обращений с верхнегоуровня до самого нижнего.• Событие на нижнем уровне (например, приход сообщения по сети или нажатие накнопку мыши) инициирует цепочку обращений, идущую снизу вверх, вплоть донекоторого события самого верхнего уровня, видимого клиентам.• Обращение клиента к верхнему уровню приводит к цепочке вызовов, которая,однако, не доходит до самого низа.
Такая ситуация реализуется, если, например,один из уровней кэширует ответы на запросы и может выдать ответ на ранее ужеподававшийся запрос без обращения к более низким уровням.103•То же самое может произойти и с событием, которое передается с самого нижнегоуровня. Дойдя до некоторого уровня, оно может поглотиться им (с изменениемсостояния каких-то компонентов), потому что не соответствует никакому событиюна более высоких уровнях.
Например, нажатие клавиши Capslock не приводит самопо себе ни к каким реакциям программы, но изменяет значение нажимаемых послеэтого клавиш, меняя их регистр на противоположный.ClientLayer 2sendmessagesendpacketsendpacketLayer 1send rawdatasend rawdataLayer 1Layer 2ClientreceivepacketreceivepacketreceivemessageРисунок 50. Составной сценарий пересылки сообщения по сети.Реализация. Основные шаги реализации следующие.• Определить критерии группировки задач по уровням.
Это критически важный шаг.Неправильное распределение задач, скорее всего, приведет к необходимостиперепроектировать систему.• Определить количество уровней, которые будут реализованы, и их имена. Частоприходится объединять концептуально различные задачи, чтобы добиться большейэффективности системы. С другой стороны, произвольное смешение задач на уровневедет к непонятной архитектуре и к системе, очень неудобной для сопровождения.При возможности поместить некоторую задачу на несколько уровней, стоитразмещать ее на самом высоком уровне из тех, где она может быть решена сдостаточной производительностью.• Определить интерфейсы, предоставляемые нижними уровнями верхним.
Здесьнужно помнить, что с помощью несколько большего, чем минимальнонеобходимый, набора интерфейсных операций нижнего уровня можно добитьсязначительного повышения производительности системы в целом.• Определить компоненты и их взаимодействие в рамках каждого отдельного уровня.• Определить способы взаимодействия соседних уровней. Можно использоватьпроталкивание, вытягивание данных или комбинацию этих подходов.• Отделить соседние уровни. В идеале нижние уровни не должны знать ничего оверхних, каждый уровень должен знать только о непосредственно предшествующемему. Для этого передачу данных с нижнего уровня можно организовать в видеобратных вызовов (callbacks) — указатель на функцию, которую нужно вызвать дляпередачи сообщения наверх, верхний уровень может передавать в качествепараметра при предшествующих запросах.• Спроектировать и реализовать обработку ошибок.
Ошибки лучше обрабатывать насамом нижнем уровне, который в состоянии их заметить.Следствия применения образца.Достоинства.• Возможность легко заменять и переиспользовать компоненты одного уровня, неоказывая влияния на остальные уровни. Возможность отлаживать и тестироватьуровни по отдельности.104•Поддержка стандартов. Многоуровневость системы делает возможной поддержкустандартных интерфейсов, таких как POSIX.Недостатки.• Изменение функциональности одного уровня может привести к каскадномуизменению всех уровней. Существенный рост производительности нижнего уровняи требование обеспечить соответствующий рост производительности на болеевысоких уровнях также могут привести к переопределению всех интерфейсов.• Падение производительности из-за необходимости все вызовы и данные проводитьчерез все уровни.• Часто уровни дублируют работу друг друга, например, при обработке ошибок,поскольку они разрабатываются независимо и не имеют информации о деталяхреализации друг друга.• Большое количество уровней может привести к существенному повышениюсложности системы и падению ее производительности.
С другой стороны, слишкоммалое число уровней (например, два) часто не позволяет обеспечить необходимуюгибкость и переносимость.Примеры. Наиболее известный пример использования данного образца — стандартнаямодель протоколов связи открытых систем (Open System Interconnection, OSI) [9]. Онасостоит из 7-ми уровней.• Самый нижний уровень — физический. Он отвечает за передачу отдельных битов поканалам связи. Основные его задачи — гарантировать правильное определение нуляи единицы разными системами, определить временные характеристики передачи (закакое время передается один бит), обеспечить передачу в одном или двухнаправлениях, и т.п.• Второй уровень — канальный или уровень передачи данных.
Его задача —предоставить верхним уровням такие сервисы, чтобы для них передача данныхвыглядела бы как посылка и прием потока байт без потерь и без перегрузок.• Третий уровень — сетевой. Его задача — обеспечить прозрачную связь междукомпьютерами, не соединенными непосредственно, а также обеспечиватьнормальную работу больших сетей, по которым одновременно путешествует оченьмного пакетов данных.• Четвертый уровень — транспортный.
Он обеспечивает надежную передачу данныхверхних уровней словно по некоторой трубе — пакеты приходят обязательно в тойже последовательности, в которой они были отправлены. Заметим, что канальныйуровень решает такую же задачу, но только для непосредственно связывающихсядруг с другом машин.• Пятый, сеансовый уровень предоставляет возможность устанавливать сеансы связи(или сессии), содержащие некоторый набор передаваемых туда и обратносообщений, и управлять ими.• Шестой, уровень представления, определяет форматы передаваемых данных.Например, именно здесь определяется, что целое число будет представляться 4-мябайтами, причем старшие биты числа идут раньше младших, первый битинтерпретируется как знак, а отрицательные числа представляются вдополнительной системе (т.е.
0x0000000f обозначает 15, а 0x80000000f —-2147483633 = -(231-15)).• Наконец, седьмой уровень — прикладной — содержит набор протоколов, которыминепосредственно пользуются программы и с которыми работают пользователи —HTTP, FTP, SMTP, POP3 и пр.Модель OSI оказалась все же слишком сложна для использования на практике. Сейчаснаиболее широко применяемые наборы протоколов строятся по урезанной схеме OSI — в105ней отсутствуют пятый и шестой уровни, прикладные протоколы пользуютсянепосредственно службами протоколов транспортного уровня.Другой пример многоуровневой архитектуры — архитектура современныхинформационных систем или систем автоматизации бизнеса. Она включает следующиеуровни [3].• Интерфейс взаимодействия с внешней средой.Чаще всего этот уровень рассматривается как интерфейс пользователя.
В его рамкахопределяется представление данных для передачи другим системам илипользователям, набор экранов, форм и отчетов, с которыми имеют делопользователи.• Бизнес-логика. На этом уровне реализуются основные правила функционированияданного бизнеса, данной организации.• Предметная область. Данный уровень содержит концептуальную схему данных, скоторыми имеет дело организация. Эти же данные могут использоваться и другимиорганизациями в своей работе.• Уровень управления ресурсами.На нем находятся все ресурсы, которыми пользуется система, в том числе другиесистемы.
Очень часто используемые ресурсы сводятся к набору баз данных,необходимых для работы организации. На этом уровне определяется структураиспользуемых ресурсов и способы управления ими, в частности, конкретноеразмещение данных по таблицам реляционной базы данных или классам объектнойбазы данных и соответствующий набор индексов. Чаще всего схемы баз данныхоптимизируются под конкретный набор запросов, и поэтому их структуранесколько отличается от концептуальной схемы данных, находящейся напредыдущем уровне.Часто два средних уровня объединяются в один — уровень функционированияприложений, что дает в результате широко используемую трехзвенную архитектуруинформационных систем.Литература к Лекции 7[1] Э.
Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированногопроектирования. Паттерны проектирования. СПб.: Питер-ДМК, 2001.[2] M. Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997.[3] М. Фаулер и др. Архитектура корпоративных программных приложений. М.: Вильямс,2004.[4] Mars Climate Orbiter Mishap Investigation Board Phase I Report.Доступен по адресу ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf[5] M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Discipline.
PrenticeHall, Englewood Cliffs, NJ, 1996.[6] M. Shaw and P. Clementz. A Field Guide to Boxology: Preliminary Classification of ArchitecturalStyles for Software Systems. Proceeding of COMPSAC, Washington, D.C., August 1997.[7] F. Buschmann, R. Meunier, H. Rohnert, P.