В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 32
Текст из файла (страница 32)
Составной сценарий пересылки сообщения по сети.Реализация. Основные шаги реализации следующие.• Определить критерии группировки задач по уровням. Это критически важный шаг.Неправильное распределение задач, скорее всего, приведет к необходимостиперепроектировать систему.• Определить количество уровней, которые будут реализованы, и их имена. Частоприходится объединять концептуально различные задачи, чтобы добиться большейэффективности системы.
С другой стороны, произвольное смешение задач на уровневедет к непонятной архитектуре и к системе, очень неудобной для сопровождения.При возможности поместить некоторую задачу на несколько уровней, стоитразмещать ее на самом высоком уровне из тех, где она может быть решена сдостаточной производительностью.• Определить интерфейсы, предоставляемые нижними уровнями верхним. Здесьнужно помнить, что с помощью несколько большего, чем минимальнонеобходимый, набора интерфейсных операций нижнего уровня можно добитьсязначительного повышения производительности системы в целом.• Определить компоненты и их взаимодействие в рамках каждого отдельного уровня.• Определить способы взаимодействия соседних уровней. Можно использоватьпроталкивание, вытягивание данных или комбинацию этих подходов.• Отделить соседние уровни.
В идеале нижние уровни не должны знать ничего оверхних, каждый уровень должен знать только о непосредственно предшествующемему. Для этого передачу данных с нижнего уровня можно организовать в видеобратных вызовов (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. Sommerlad, M. Stal. Pattern-Oriented SoftwareArchitecture. A System of Patterns. Wiley, 2002.[8] Э. Таненбаум. Современные операционные системы. 2-е издание. СПб.: Питер, 2002.[9] Э. Таненбаум. Компьютерные сети. 4-е издание. СПб.: Питер, 2003.[10] Л. Басс, П. Клементс, Р. Кацман. Архитектура программного обеспечения на практике.СПб.: Питер, 2006.[11] Э. Дж. Брауде. Технология разработки программного обеспечения. СПб.: Питер, 2004.106Лекция 8. Образцы проектирования (продолжение)АннотацияРассматриваются дополнительные примеры образцов: архитектурный стиль «данные–представление–обработка», ряд образцов проектирования, идиом и образцов организации работ.Ключевые словаОбразец проектирования, архитектурный стиль, идиома, образец организации, образец процесса,архитектурный стиль «данные-представление-обработка», образец проектирования «подписчик»,идиома «шаблонный метод», инспекция программ по Фагану.Текст лекцииВ этой лекции мы продолжим разбирать примеры образцов — рассмотрим детальноархитектурный стиль «Данные–представление–обработка», а также примеры тех видов образцов,которые не уместились в предыдущую лекцию: образцов проектирования в узком смысле, идиом иобразцов организации.Данные–представление–обработкаНазвание.
Данные–представление–обработка (model–view–controller, MVC).Назначение. Интерактивные приложения с гибким интерфейсом пользователя. Требованияк пользовательскому интерфейсу в интерактивных приложениях меняются чаще всего.Разные пользователи имеют разные наборы требований. В несколько меньшей степени этокасается методов обработки данных, лежащих в основе таких приложений, — визуальноепредставление управляющих элементов может меняться вместе с интерфейсом, а самивыполняемые действия зависят от бизнес-логики и предметной области, и поэтому болееустойчивы. Наименее подвержена изменениям модель данных, с которыми работаетприложение.Поэтому для увеличения гибкости и удобства изменений в таких приложениях необходимосоответствующим образом разделить их компоненты.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
