sdt-book-2006 (1133574), страница 31
Текст из файла (страница 31)
Здесьнужно помнить, что с помощью несколько большего, чем минимальнонеобходимый, набора интерфейсных операций нижнего уровня можно добитьсязначительного повышения производительности системы в целом.• Определить компоненты и их взаимодействие в рамках каждого отдельного уровня.• Определить способы взаимодействия соседних уровней. Можно использоватьпроталкивание, вытягивание данных или комбинацию этих подходов.• Отделить соседние уровни. В идеале нижние уровни не должны знать ничего оверхних, каждый уровень должен знать только о непосредственно предшествующемему.
Для этого передачу данных с нижнего уровня можно организовать в видеобратных вызовов (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).Назначение. Интерактивные приложения с гибким интерфейсом пользователя. Требованияк пользовательскому интерфейсу в интерактивных приложениях меняются чаще всего.Разные пользователи имеют разные наборы требований. В несколько меньшей степени этокасается методов обработки данных, лежащих в основе таких приложений, — визуальноепредставление управляющих элементов может меняться вместе с интерфейсом, а самивыполняемые действия зависят от бизнес-логики и предметной области, и поэтому болееустойчивы. Наименее подвержена изменениям модель данных, с которыми работаетприложение.Поэтому для увеличения гибкости и удобства изменений в таких приложениях необходимосоответствующим образом разделить их компоненты.
При этом нужно принимать вовнимание следующие факторы.Действующие силы.• Одна и та же информация может быть представлена по-разному и в несколькихместах для удобства доступа к ней многих различных пользователей, имеющихразные привычки и разные навыки работы с информацией.• Изменения в данных должны немедленно отображаться в различных представленияхэтих данных.• Внесение изменений в пользовательский интерфейс должно быть максимальнопростым, иногда оно даже должно быть возможно прямо во время работыприложения.• Поддержка различных стандартов пользовательского интерфейса и его переносмежду платформами не должны влиять на код, связанный с методами работы сданными и структурой данных приложения.Решение. Выделяется три набора компонентов.
Первый набор — данные, модель данныхили просто модель (model) — соответствует структуре данных предметной области, вкоторой работает приложение. Обязанности этих компонентов: представлять в системеданные и базовые операции над ними. Компоненты второго набора — представления (view)— соответствуют различным способам представления данных в пользовательскоминтерфейсе. Для одних и тех же данных может иметься несколько представлений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
