ТЕМА_2

Проектирование и
архитектуры
программных систем
Лектор : доктор технических наук,
профессор Назаров С.В.
[email protected], каб. 827, каф.
Архитектуры ПС
1
Операционные системы
Проектирование архитектуры
программных систем
Тематический расчет часов
Аудиторные часы
Лекции
20
Семинарские и
практические
занятия
20
Всего
40
Формы
текущего
контроля
Практические
занятия,
контрольные
работы, домашнее
задание
Самостоя Всего
-тельная часов
работа
68
108
2
Литература
Базовый учебник
1. Крылов Е.В. Техника разработки программ.: В 2 кн. Кн. 2 Технология,
надежность и качество программного обеспечения: Учебник / Е.В.
Крылов, В.А. Островский, Н.Г. Типикин. – М.: Высш. Шк., 2008
Основная
2. Гагарина Л.Г., Кокорева Е.В., Виснадул Б.Д. Технология разработки
программного обеспечения: учебное пособие / под ред. Л.Г. Гагариной. –
М.: ИД «Форум»: Инфра-М, 2008
3. Басс Л., Клементс П., Кацман Р. Архитектура программного обеспечения
на практике. 2-е издание. – СПб.: Питер, 2006
4. Полис Г., Огастин Л., Мадхар Д. Разработка программных проектов: на
основе Rational Unified Process (RUP). – М.: ООО «Бином-Пресс», 2009
5. Боггс У., Боггс М. UML и Rational Rose. «Лори», 2008
6. Кватрани Т., Палистрант Д. Визуальное моделирование с помощью IBM
Rational Software Architect и UML. Пер. с англ. – М.: КУДИЦ-ПРЕСС. –
2007
7. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. 2-е
изд.: Пер. с анг. – М.: ДМК Пресс, 2007.
8. Вендров А.М. Проектирование программного обеспечения экономических
информационных систем. Учебник для вузов. 2-е изд. – М.: Финансы и
статистика, 2006
3
Операционные системы
Дополнительная
9. Кериевски Д. Рефакторинг с использованием шаблонов.: Пер. с англ. –
М.: ООО «И.Д. Вильямс»,2008
10. Назаров С. В. Операционные системы специализированных
вычислительных комплексов: Теория построения и системного
проектирования. - М.: Машиностроение, 1989.
Боэм Б.У. Инженерное проектирование программного обеспечения: Пер. с англ. – М.: Радио и связь.
1985. – 512 с.
Жоголев Е.А.. Введение в технологию программирования (конспект лекций). - М.: "ДИАЛОГ-МГУ",
1994.
Зиглер К.. Методы проектирования программных систем: Пер. с англ. – М .: Мир, 1985. – 328 с.
Колин Ю. Применение Rational Software Architect в разработке, управляемой моделями: Часть 1. Обзор
парадигмы разработок, управляемых моделями с шаблонами.
http://www.ibm.com/developerworks/ru/library/1121_yu/index.html?S_TACT=105AGX63&S_CMP=NWLTR
&ca=dnn-rut2405
Колин Ю. Применение Rational Software Architect в разработке, управляемой моделями и на основе
шаблонов: Часть 2. Инструментальная поддержка разработки.
http://www.ibm.com/developerworks/ru/library/0116_yu/#author1
Калямин В.В. Технологии программирования. Компонентный подход. Учебное пособие. ИНТУИТ.РУ,
Бином. Лаборатория знаний, 2010
Майерс Г. Надежность программного обеспечения: Пер. с англ. – М .: Мир, 1980. – 360 с.
4
Операционные системы
Структура итоговой оценки по
учебной дисциплине:
Формы работы
Вклад в итоговую
оценку (%)
Работа на лекциях и практических занятиях
25
Домашнее задание
75
Зачет
5
Операционные системы
Тема 2. Архитектуры программных
систем
2.1. Понятие архитектуры программной системы (ПС)
2.2. Что определяет и на что влияет архитектура
2.3. Архитектурные структуры и представления
2.4. Отношения между структурами
2.5. Варианты архитектур программных систем
Литература: Л1 с. 4 – 14; Л2 с. 5 – 32; Л3 с. 38 – 77; Вендров А.М.
Проектирование программного обеспечения. – М.: Финансы и
статистика, 2000. с. 7 – 14, 322 – 335; Майерс Г. Надежность
программного обеспечения: Пер. с англ. – М .: Мир, 1980. с. 78 – 90.
6
Операционные системы
2.1. Понятие архитектуры ПС
Архитектура - это базовая организация системы, воплощенная в ее
компонентах, их отношениях между собой и с окружением, а также принципы,
определяющие проектирование и развитие системы. [IEEE 1471]
Система - это набор компонентов, объединенных для выполнения определенной
функции или набора функций. Термин "система" охватывает отдельные приложения, системы
в традиционном смысле, подсистемы, системы систем, линейки продуктов, семейства
продуктов, целые корпорации и другие агрегации, имеющие отношение к данной теме.
Система существует для выполнения одной или более миссий в своем окружении. [IEEE 1471]
Миссия - это применение или
действие, для которого одно или
несколько заинтересованных лиц
планируют использовать систему в
соответствии с некоторым набором
условий.
Окружение, или контекст, определяет
ход и обстоятельства экономических,
эксплуатационных, политических и
других влияний на систему.
Заинтересованное лицо - это физическое лицо, группа или
организация (или ее категории), которые заинтересованы в системе или
имеют связанные с ней задачи.
7
Операционные системы
В начале развития информационных технологий термин "архитектура"
применялся по отношению только к аппаратному обеспечению (архитектура
ЭВМ, вычислительных комплексов, сетей) и лишь позже стал применяться к
программному обеспечению. В настоящее время дисциплины о программных
архитектурах и их проектировании интенсивно развиваются. В любой
методологии
проектирования
(пожалуй,
кроме
экстремального
программирования) понятие "архитектура" занимает ключевое место.
Программная система - это совокупность системных, прикладных и сервисных
программ, обеспечивающих решение некоторой совокупности задач. ПС могут
входить в состав программных комплексов. Обычно это более масштабные системы
в рамках больших технических и организационных систем. Системы в свою очередь
могут состоять из подсистем. Архитектурные решения необходимы на каждом их
этих уровней.
В информационных технологиях архитектура используется в следующих
областях:
- функциональная архитектура (бизнес-архитектура);
- системная архитектура (программных систем);
- технологическая или инфраструктурная архитектура;
- информационная архитектура (организация данных).
8
Операционные системы
Большая часть определений архитектуры не определяет термин “компонент”.
IEEE 1471 намеренно оставляет это понятие неопределенным, чтобы
оно соответствовало множеству толкований, возможных в отрасли. Компонент
может быть логическим или физическим, технологически-независимым или
технологически-связанным, крупно - или мелкогранулированным.
Определение термина "компонент" по спецификации UML 2.0:
Компонентом называется модульная часть системы, которая инкапсулирует ее содержимое;
воплощение компонента является замещаемым в его окружении. Поведение компонента
определяется в терминах предоставляемого и требуемого интерфейсов. Таким образом,
компонент используется в качестве типа, соответствие которого описывается этими двумя
интерфейсами, предоставляемым и требуемым (объединяя как статическую, так и
динамическую их семантику).
В отрасли не существует общепризнанного определения понятия "архитектура”.
Архитектура – это:
1) набор значимых решений по поводу организации системы программного
обеспечения,
2) набор структурных элементов и их интерфейсов, при помощи которых
компонуется система, вместе с их поведением, определяемым во
взаимодействии между этими элементами,
3) компоновка элементов в постепенно укрупняющиеся подсистемы , а также
стиль архитектуры который направляет эту организацию -- элементы и их
интерфейсы, взаимодействия и компоновку. [Крачтен (Kruchten)]
9
Операционные системы
Архитектура программы или компьютерной системы - это структура или
структуры системы, которые включают элементы программы, видимые извне
свойства этих элементов и связи между ними. [Басс (Bass) и др.]
Архитектура - это структура организации и связанное с ней поведение
системы. Архитектуру можно рекурсивно разобрать на части,
взаимодействующие посредством интерфейсов, связи, которые соединяют
части, и условия сборки частей. Части, которые взаимодействуют через
интерфейсы, включают классы, компоненты и подсистемы. [UML 1.5]
Архитектура программного обеспечения системы или набора систем состоит
из всех важных проектных решений по поводу структур программы и
взаимодействий между этими структурами, которые составляют системы.
Проектные решения обеспечивают желаемый набор свойств, которые должна
поддерживать система, чтобы быть успешной. Проектные решения
предоставляют концептуальную основу для разработки системы, ее поддержки и
обслуживания. [Мак-Говерн (McGovern)]
Большинство определений указывают на то, что архитектура связана со
структурой и поведением, а также только со значимыми решениями, может
соответствовать некоторому архитектурному стилю, на нее влияют
заинтересованные в ней лица и ее окружение, она воплощает решения на
основе логического обоснования.
10
Операционные системы
2.2. Что определяет и на что влияет архитектура
Почему важна архитектура программной системы с технической точки зрения. В этом контексте
следует привести три основных фактора [Баас].
Взаимодействие между заинтересованными лицами. Программная архитектура – это
универсальная абстракция системы, на основе которой все или почти все в системе лица
могут искать взаимопонимания, вести переговоры, находить компромиссы.
Начальные проектные решения. Программная архитектура содержит сведения о том,
какие решения были приняты на ранних этапах разработки системы. Значимость
подобного рода сведений не ограничивается удельным весом этих этапов относительно
оставшихся операций разработки и сопровождения. Именно в это время впервые
появляется возможность анализа проектных решений, определяющих дальнейшую
разработку системы.
Переносимая абстракция системы. Программная архитектура – это
относительно небольшая вполне доступная для человеческого восприятия модель
структурирования системы и взаимодействия ее компонентов. Помимо прочего эта
модель обладает свойством переносимости из системы в систему. Например, ее
можно применять в отношении других систем, для которых характерны примерно те
же требования к атрибутам качества и функциональным возможностям, и тем самым
дать начало полноценному многократному применению.
11
Операционные системы
1. Архитектура определяет структуру. Структура является
важнейшей характеристикой архитектуры. Структурные аспекты архитектуры
проявляются многими способами, и в результате большинство определений
архитектуры сознательно оставляют их неопределенными. Структурный элемент
может быть подсистемой, процессом, библиотекой, базой данных, вычислительным
узлом, системой в традиционном смысле, готовым продуктом и так далее.
Многие определения архитектуры признают также не только сами структурные элементы,
но и композиции из структурных элементов, их связи (и любые соединительные звенья,
необходимые для поддержки этих отношений), интерфейсы и разбиение. И вновь, каждый из
этих элементов может быть представлен разными способами. Например, соединительное звено
может представлять собой сокет, быть синхронным или асинхронным, быть связанным с
конкретным протоколом и так далее.
Рис. 1
Пример некоторых структурных элементов показан на рис. 1. Изображена диаграмма классов UML,
содержащая некоторые структурные элементы, которые представляют систему обработки заказов. Представлено три класса -- OrderEntry, CustomerManagement и AccountManagement. Класс OrderEntry зависит от класса
CustomerManagement и от класса AccountManagement.
12
Операционные системы
2. Архитектура определяет поведение.
Наряду с определением
структурных элементов любая архитектура определяет взаимодействия между этими
структурными элементами. Это такие взаимодействия, которые обеспечивают желаемое
поведение системы. На рис. 2 представлена диаграмма сценария UML, которая показывает
несколько взаимодействий, которые в сумме позволяют системе поддерживать создание
заказа в системе обработки заказов.
Рис. 2
Сначала, деятель Sales Clerk создает заказ при помощи экземпляра класса OrderEntry. Экземпляр класса OrderEntry
получает сведения о клиенте при помощи экземпляра класса CustomerManagement. Затем экземпляр класса OrderEntry
использует экземпляр класса AccountManagement для того, чтобы создать заказ, внести в него элементы заказа, а затем
разместить заказ.
13
Операционные системы
3. Архитектура концентрируется на значимых элементах.
Хотя архитектура определяет структуру и поведение, она определяет не все в структуре и не все в
поведении. Она занимается только такими элементами, которые оцениваются как значимые.
Значимые элементы – это главные структурные элементы, связанные с основным поведением и
элементы, которые определяют значимые свойства, такие как надежность и масштабируемость.
Архитектурную значимость можно назвать экономической значимостью, поскольку главный
признак, по которому некоторые элементы оцениваются выше остальных - это стоимость
создания и стоимость изменения.
Поскольку архитектура фокусируется только на значимых элементах, она предлагает конкретную
перспективу оцениваемой системы - перспективу, которая наиболее значима для разработчика архитектуры. В
этом смысле архитектура - это некоторое обобщение системы, помогающее разработчику архитектуры
управлять сложностью.
Набор значимых элементов не является статичным и может измениться с течением времени. Он может
измениться при уточнении результата требований, идентификации рисков, создании исполняемой программы.
Однако относительная стабильность архитектуры несмотря на изменения, в некоторой степени является
признаком хорошей архитектуры, хорошо отлаженного процесса разработки и хорошего разработчика. Если
архитектура требует постоянного пересмотра при относительно небольших изменениях, это плохой признак.
4. Архитектура уравновешивает потребности
заинтересованных лиц. Архитектура создается для удовлетворения комплекса
потребностей заинтересованного лица. Однако часто невозможно выполнить все выраженные
пожелания. Например, заинтересованное лицо может попросить, чтобы некоторая функциональность укладывалась в определенный временной промежуток, но эти две потребности
(функциональность и промежуток времени) являются взаимоисключающими.
14
Операционные системы
Потребности нескольких заинтересованных лиц:
• Конечный пользователь заинтересован в интуитивно понятном и корректном поведении,
производительности, надежности, удобстве использования, доступности и безопасности;
Системный администратор заинтересован в интуитивно понятном поведении, управлении и
инструментах мониторинга;
• Специалист по маркетингу заинтересован в конкурентоспособных функциях, времени до выхода
программы, позиционировании среди других продуктов и в стоимости;
•
•
Клиент заинтересован в цене, стабильности и возможности планировать;
Разработчик заинтересован в понятных требованиях и простом и непротиворечивом принципе
проектирования;
•
Руководитель проекта заинтересован в предсказуемости хода проектирования, планировании,
продуктивном использовании ресурсов и бюджета;
• Специалист по сопровождению заинтересован в понятном, непротиворечивом и документируемом
принципе проекта, а также в легкости, с которой можно вносить изменения.
•
Многие пункты из списка интересов являются нефункциональными, т.е. не влияют на функциональность системы
(например, интерес по отношению к цене и планированию). Тем не менее, такие интересы формулируют свойства или
ограничения системы. Нефункциональные требования очень часто являются самыми значимыми требованиями, поскольку в них
заинтересован разработчик архитектуры.
При выборе архитектуры необходимо учитывать основные факторы, определяющие:
1. Трудоемкость разработки - масштаб; сложность (техническую и логическую); ясность
целей.
2. Основные цели разработки (цели продукта), вытекающие из требований к системе эффективность; расширяемость (масштабируемость, облегчение добавления новых свойств);
адаптируемость (облегчение смены требований); простота (понимания, реализации);
надежность (отсутствие ошибок).
3. Цели проекта - удобство сопровождения; стоимость; сроки реализации и т.п.
15
Операционные системы
5. Архитектура воплощает решения на основе логического
обоснования. Важный аспект архитектуры – это ее логическое обоснование. Важно обеспечить документирование решений, которые привели к созданию этой архитектуры, и логические
обоснования таких решений. Эта информация является значимой для многих заинтересованных лиц,
особенно для тех, кто должен обслуживать систему. Она часто имеет ценность для разработчика архитектуры, когда ему нужно пересмотреть логические обоснования принятых решений. Например, эта
информация используется при пересмотре архитектуры, а разработчику нужно объяснить принятые ранее
решения.
6. Архитектура может соответствовать некоторому архитектурному
стилю. Архитектурный стиль определяет семейство систем в терминах шаблона
организации структуры. Архитектурный стиль определяет номенклатуру компонентов и
типов соединительных звеньев, а также набор условий, в соответствии с которыми они
могут соединяться [Шоу и Гарлан (Show and Garlan)].
Большинство архитектур построены на основе систем, которые используют сходные наборы
интересов. Сходство может быть определено как архитектурный стиль или как особый вид
шаблона, хотя этот шаблон часто является сложным и составным. Архитектурный стиль
представляет собой кодификацию опыта, который удобно использовать многократно. Примеры
архитектурных стилей включают распределенный стиль, стиль клиент-сервер, стиль "каналы и
фильтры", стиль с централизованной обработкой данных, стиль, построенный на правилах и так
далее. Конкретная система может демонстрировать более одного архитектурного стиля.
В терминах UML шаблон - это общее решение общей проблемы в данном контексте.
Применение архитектурного стиля (или шаблона) несколько облегчает жизнь разработчиков,
поскольку стиль обычно документирован в терминах рационального обоснования его
использования (меньше придется обдумывать) и в терминах его структуры и поведения
(придется выработать меньше документации по архитектуре, поскольку вместо этого можно
просто обратиться к стилю).
16
Операционные системы
7. На архитектуру оказывает влияние ее окружение. Система размещается в
некотором окружении, и это окружение оказывает влияние на архитектуру. Окружение определяет
границы, в которых должна работать система, а это влияет на архитектуру. Факторы окружения,
влияющие на архитектуру - это миссия бизнеса, заинтересованные в системе лица, внутренние и
внешние технические ограничения.
8. Архитектура оказывает влияние на свое окружение. Создание архитектуры
изменяет окружение с технологической точки зрения - может также изменить среду в терминах навыков,
доступных в пределах организации.
Когда речь идет о преимущественно программных системах, то следует учитывать конкретные
аспекты окружения. Для того чтобы ПС работала, ее запускают на некотором аппаратном
обеспечении. Поэтому результирующая система представляет собой сочетание программного и
аппаратного обеспечения, и именно это сочетание позволяет добиться таких характеристик, как
надежность и производительность.
Стандарт IEEE Std 12207-1995, IEEE Standard for Information Technology -- Software Life
Cycle Processes определяет систему иначе, чем определение стандарта IEE 1471 (которое
концентрируется на преимущественно-программных системах), но при этом согласуется с
определением системы в области системного проектирования: Системой называется
интегрированный комплекс, состоящий из одного или более процессов,
аппаратных устройств, программ, средств и людей, предоставляющий
возможность удовлетворить данную потребность или условие.
17
Операционные системы
Техническое описание “A configuration of the Rational Unified Process for
System Engineering (RUP SE)” содержит похожее определение: Системой
называется набор ресурсов, предоставляющий сервисы, которые
используются предприятием для выполнения цели или миссии
бизнеса. Компоненты системы обычно состоят из аппаратного
обеспечения, программного обеспечения, информационных ресурсов
и сотрудников.
В области системного проектирования компромисс достигается за счет
реализации системы в большей или меньшей степени теми или иными
компонентами. Так, если ключевой фактор – производительность, то
принимается решение реализовать определенные элементы системы
аппаратными устройствами. Чтобы предоставить удобную для покупателей
систему, принимается решение предоставить клиентский интерфейс не
программой, а человеком.
Системное проектирование особенно заинтересовано в том, чтобы
рассматривать программное, аппаратное обеспечение и людей как
равноценные понятия, избегая, таким образом, неверных заключений, в
которых аппаратные устройства рассматриваются как элементы второго сорта
по сравнению с программными или наоборот.
18
Операционные системы
9. Архитектура оказывает влияние на структуру коллектива. Архитектура
определяет группировки родственных элементов, которые адресуют данный набор интересов.
Например, архитектура системы обработки заказов может иметь определенные группировки
элементов для ввода заказов, ведения счетов, работы с клиентами, выполнения заказа,
интеграции с внешними системами и безопасности.
Каждая из этих группировок может требовать различных наборов навыков. Поэтому имеет
смысл выровнять структуры групп разработчиков ПС в соответствии с архитектурой после того, как
она будет определена. Однако чаще встречается ситуация, когда первоначальная группа
разработчиков оказывает влияние на архитектуру, а не наоборот. Это ошибка, которой следует
избегать, поскольку в результате обычно получается архитектура, далекая от идеала. "Закон
Конвея" утверждает, что "если у вас есть четыре группы, работающих над компилятором, то вы
получите четырехпроходный компилятор". Практически часто непреднамеренно создаются
архитектуры, которые являются отражением организации, создающей архитектуру.
10. Архитектура помогает в процессе обучения. Архитектура, содержащая описание
взаимодействия элементов в рамках требуемого поведения, может послужить своеобразной инструкцией,
вводящей новых участников проекта в курс дела. Этим дополнительно подтверждается утверждение о
том, что одной из основных функций программной архитектуры является организация и содействие
общению между представителями различных заинтересованных групп.
11. Архитектура представлена в каждой системе. Каждая система имеет архитектуру,
даже если эта архитектура формально не документирована или система слишком проста. Обычно
документирование архитектуры представляет собой очень ценное средство. Документированные
архитектуры имеют тенденцию быть более продуманными - а, следовательно, более эффективными, чем
недокументированные, поскольку процесс записи архитектуры естественным образом ведет к
всестороннему обдумыванию.
19
Операционные системы
2.3. Архитектурные структуры и представления
Рассматривая представления архитектуры, часто употребляют связанные между собой понятия структуры
(structure) и представления (view) [Басс]. Представление – это отображение ряда связанных архитектурных
элементов в том виде, в котором им оперируют заинтересованные в системе лица. Структура – это
собственно ряд элементов, существующих в раках программного или аппаратного обеспечения.
Архитектурные структуры подразделяются на три общие группы, в каждую из которых включаются
элементы определенного характера [Басс].
Модульные структуры. Элементы таких структур – модули
(блоки реализации). Модули предполагают
рассмотрение системы с точки зрения программного кода. Они позволяют отвечать на такие вопросы, как: “Какие
функциональные требования выполняет данный модуль? К каким программным элементам он может
обращаться? Какое программное обеспечение он фактически использует? Между какими модулями установлены
отношения обобщения или специализации (например, наследования)?
Структуры “компонент и соединитель”. Элементами являются компоненты (основные единицы
вычислений) и соединители (инструменты взаимодействия между компонентами) периода прогона (выполнения).
Среди вопросов, на которые отвечают структуры “компонент и соединитель”, такие, например, как: “Каковы
основные исполнительные компоненты и как происходит их взаимодействие? Каковы основные совместно
используемые хранилища данных? Какие части системы воспроизводятся? Каким образом по системе проходят
данные? Какие элементы системы способны выполняться одновременно? Какие структурные изменения
происходят в системе во время ее исполнения?”
Структуры распределения. Структуры распределения демонстрируют связь между программными
элементами, с одной стороны, и элементами одной или нескольких внешних сред, в которых данное
программное обеспечение создается и исполняется, - с другой. Они отвечают на вопросы: “На каком процессоре
исполняется данный программный элемент? В каких файлах каждый элемент хранится в ходе разработки,
тестирования и конструирования системы? Каким образом программные элементы распределяются между
группами разработчиков?”
20
Операционные системы
Перечисленные три структуры соответствуют трем универсальным типам
решений, применяемым в ходе архитектурного проектирования:
1) каким образом следует структурировать совокупность блоков кода (модулей) системы?
2) каким образом следует структурировать совокупность элементов системы, обладающих поведением
(компоненты) и демонстрирующих взаимодействие (соединители) в период прогона?
3) каким образом установить связи между системой и непрограммными структурами среды
( например, с процессорами, файловыми системами, сетями, группами разработчиков и т. д.)?
21
Операционные системы
Модульные структуры делятся на следующие
разновидности.
Декомпозиция. В качестве блоков выступают модули, между
которыми установлены отношения “является подмодулем…”. Таким
образом, крупные модули в рекурсивном порядке разлагаются на
меньшие, и этот процесс завершается только тогда, когда меньшие модули
становятся вполне понятными.
Варианты использования. Блоками этой
структуры могут быть
модули, либо (когда требуется более мелкая структура) процедуры или
ресурсы интерфейсов модулей. Между такими блоками устанавливаются
отношения использования. Структура использования полезна при
конструировании систем, которые легко расширяются дополнительными
функциями, либо предлагают возможность извлечения полезных
функциональных подмножеств.
Многоуровневые. Если отношения использования в рамках этой структуры находятся под строгим,
особым образом осуществляемом контроле, возникает система уровней – внутренне связанных наборов
родственных функций. В рамках строгой многоуровневой структуры уровень N может обращаться к
услугам только в том случае, если они представлены уровнем N-1. Уровни во многих случаях
проектируются в виде абстракций (виртуальных машин), которые, стараясь обеспечить переносимость,
скрывают детали своей реализации нижележащих уровней от вышележащих.
Класс или обобщение. Блоки модулей в рамках этой структуры называются классами.
Отношения между ними строятся по образцам “наследуют от…” и “являются экземпляром…”. Данное
представление способствует анализу коллекций сходного поведения или сходных возможностей (например,
классов, которые наследуют от других классов) и параметрических различий, фиксация которых
производится путем определения подклассов. Структура классов позволяет анализировать вопросы
повторного использования и инкрементного введения функциональности.
22
Операционные системы
Структуры “компонент и соединитель”.
Процесс или сообщающиеся процессы. Является ортого-
нальной по отношению к модульным структурам, так как связана с
динамическими аспектами исполняемой системы. В качестве блоков
выступают процессы или потоки, связь между которыми устанавливается передачей данных, синхронизации и/или операций исключения.
Здесь действует отношение прикрепления, демонстрирующее связь
компонентов друг с другом. Структура процессов облегчает
конструирование рабочей производительности и готовности системы.
Параллелизм. Позволяет выявлять перспективы параллелизма и локализовать возможности
состязаний за ресурсы. В качестве блоков выступают компоненты, а соединители играют роль
“логических потоков”. Логический поток – это последовательность вычислений, которую
впоследствии, в ходе процесса проектирования, можно связать с отдельным физическим потоком.
Структура параллелизма задействуется на ранних этапах проектирования и способствует выявлению
требований к организации параллельного исполнения.
Совместно используемые данные или репозиторий. В состав данной структуры
входят компоненты и соединители, обеспечивающие создание, хранение и обращение к данным
постоянного хранения. Она наилучшим образом приспособлена к таким ситуациям, когда система
структурирована на основе одного или нескольких репозиториев совместно используемых данных.
Клиент-сервер.
Эта структура предназначена для систем, сконструированных в виде группы
взаимодействующих клиентов и серверов. В качестве компонентов в данном случае выступают
клиенты и серверы, а соединителями являются протоколы и сообщения, которыми они обмениваются
в процессе обеспечения работоспособности системы. Такая структура требуется для разделения задач,
физического распределения и выравнивания нагрузок.
23
Операционные системы
Структуры “распределения”
Размещение.
Структура размещение отражает распределение программной системы между элементами аппаратной обработки
(компьютерами) и передачи данных. Отношения устанавливаются
по распределению и демонстрируют физические устройства, на
которых размещаются программные элементы. Возможны также
отношения миграции в случае динамического распределения,
например, в системах виртуальных машин. Настоящее
представление позволяет инженерам анализировать
производительность, целостность данных, готовность и
безопасность. Все эти характеристики чрезвычайно важны в
условиях распределенных и параллельных систем.
Реализация. Данная структура демонстрирует отображение программных элементов
(обычно модулей) на файловую структуру (структуры) в условиях разработки системы, интеграции
и управления конфигурациями. Это крайне важно в контексте разработки и процессов
конструирования.
Распределение функций. Данная структура обеспечивает распределение обязанностей по
реализации и интеграции модулей между соответствующими группами разработчиков. Наличие в
составе архитектуры структуры распределения функций делает очевидным, что при принятии
соответствующих решений учитывались как архитектурные, так и организационные факторы.
Архитектору должно быть известно, какие именно навыки требуются от разных групп
разработчиков.
24
Операционные системы
2.4. Отношения между структурами
Все системы состоят из множества структур. Как правило, структура системы анализируется с точки
зрения ее функциональности. При этом часто забывают о других ее свойствах: физическом распределении, взаимодействии процессов и синхронизации и др. Все эти свойства обязательно должны учитываться на уровне архитектуры. Каждая структура содержит метод анализа тех или иных атрибутов
качества. К примеру, чтобы создать легко расширяемую или сокращаемую систему, необходимо сконструировать структуру использования (именно сконструировать, а не просто зафиксировать). Структура
процессов конструируется с целью исключения взаимоблокировки и расширения “узких мест”.
Структура декомпозиции модулей конструируется в расчете на производство модифицируемых систем
и т.д.
Рассмотренные структуры предполагают различные представления и подходы к проектированию
программной системы. Элементы одной структуры связаны с элементами прочих, и на эти отношения
следует обратить внимание. В частности, модуль в структуре декомпозиции может декларироваться как
отдельный компонент, как часть отдельного компонента или несколько компонентов в рамках одной из
структур “компонент и соединитель”, отражая, таким образом, своего представителя периода прогона.
Каждая рассмотренная структура снабжает архитектора оригинальным представлением системы и
дополнительной базовой точкой проектирования. Заметим, что современные CASE-средства
проектирования архитектуры ПС, например, Rational Software Architect реализуют именно подобный
подход при разработке программных систем, позволяя представлять архитектуру системы множеством
взаимосвязанных моделей.
В рамках отдельных проектов одна структура считается основной, а остальные структуры, если это
возможно и нужно, определяются в ее категориях. Часто, хотя и не всегда, в качестве доминантной
структуры выступает декомпозиция модулей. Объясняется это вполне разумно – декомпозиция модулей
порождает структуру проекта.
Структуры – это основные базовые точки конструирования архитектуры. Отдельные структуры
отвечают за те или иные атрибуты качества. Они выражают принцип разделения задач при создании
архитектуры, а также при ее последующем анализе и изложении для заинтересованных лиц.
25
Операционные системы
2.5. Варианты архитектур программных систем
Архитектуры программных систем менялись по мере развития информационных техологий. В 60-е
годы ХХ века значительный процент систем составляли пакетные системы, которые представляли собой
ряд автономных последовательных программ, общающихся через файлы во вторичной памяти. Выделялись лишь два похода к построению систем: метод уровней абстракции и метод портов. Позже получил
развитие модульно-интерфейсный подход – один из методов структурного проектирования, затем подходы,
основанные на потоках данных, независимых компонентах, объектно-ориентированном проектировании и
др.
2.5.1. Архитектура, основанная на уровнях абстракций
Наиболее мощный инструмент, дающий разработчику возможность справиться со сложностью системы –
это понятие абстракции. Абстракция представляет собой описание системы или ее части, в котором не
указываются абсолютно все детали. Она обеспечивает разработчику общий “макроскопический” обзор
системы, в силу чего дает представление о глобальных связях и свойствах основных элементов системы,
которое трудно достичь, когда учитываются все подробности.
Для каждой системы имеется множество возможных абстракций. Каждая абстракция дает разработчику
различную точку зрения на то, как выглядит система и что она делает. Абстракции системы могут быть
тесно связаны. Так, например, одна абстракция а(2) может быть уточнением абстракции а(1). Если
абстракция а(2) уточняет абстракцию а(1), то абстракция а(2) описывает все, что описывает абстракция
а(1), но уровень детализации в абстракции а(2) всегда не меньше, чем в абстракции а(1). Другими словами
абстракция а(2) является равномерно более детализированным описанием, чем а(1).
Концепция уровней абстракции была предложена Дейкстрой в 1968году. Программа разбивается на
различные иерархически упорядоченные части L(1), L(2),…,L(n), называемые слоями , удовлетворяющие
определенным проектировочным критериям. Каждый уровень является группой тесно связанных модулей.
Идея уровней призвана минимизировать сложность системы за счет такого их определения, которое
обеспечивает высокую степень независимости уровней друг от друга. Это достигается благодаря тому, что
свойства объектов такой системы (ресурсы, представления данных и т. п.) упрятываются внутрь каждого
уровня, что позволяет рассматривать каждый уровень как абстракцию этих объектов.
26
Операционные системы
Концепция слоев — одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной
системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики
микросхем. В среде сетевого взаимодействия протокол FТР работает на основе протокола ТСР, который, в
свою очередь, функционирует "поверх" протокола IР, расположенного "над" протоколом Ethernet.
27
Операционные системы
Основные причины интереса к слоям архитектуры программных систем:
Слои легко формализуются. Интуитивно понятно, что если система разбита на ряд слоев, то слой n – это компоненты
системы, которые используют только компоненты слоя n-1 и могут быть использованы только компонентами слоя n+1.
Слои обладают простой и наглядной семантикой. В архитектуре программной системы слои представляют уровни
абстракции.. Слой n скрывает (инкапсулирует) логику работы с понятиями определенными на этом слое, позволяя, таким образом,
слою n+1 реализовать работу с более сложными понятиями, организовать более сложную логику, используя выразительные
средства нижележащего слоя.
Слои широко распространены. Большое количество программных систем, особенно если речь идет о программных системах
масштаба предприятия, имеют именно слоистую структуру.
Альтернативная реализация. Можно выбирать альтернативную реализацию базовых слоев – компоненты верхнего слоя
способны работать без каких-либо изменений в нижележащих слоях, при условии сохранения интерфейсов.
Минимизация интерфейсов. Зависимость между слоями можно свести к минимуму. Между уровнями можно организовать
четкий интерфейс.
Любой слой достаточно просто модифицировать, не затрагивая другие слои и не меняя межслойные интерфейсы.
28
Операционные системы
Возможные две общие структуры таких уровней
Рис. 1
Рис. 2
На рис. 1 показан такой подход, когда задача рассматривается как создание “машины пользователя”,
начиная с самого низшего уровня аппаратуры (или возможно операционной системы). Последовательность уровней, называемых абстрактными машинами, определяется так, что каждая следующая
машина строится на предыдущих, расширяя их возможности. Каждый уровень может ссылаться только
на один, отличный от него самого уровень (вызвать его), а именно тот, который непосредственно ему
предшествует.
В структуре по рис. 2 уровни не являются полными абстракциями более низких уровней, каждый из
них может ссылаться на любой предшествующий уровень.
Одной из первых программных систем, основанных на уровнях абстракции, была операционная
система THE. Она является пакетной системой с мультипрограммированием и виртуальной памятью.
Система включает пять уровней абстракции, структура которых близка к изображенной на рис. 2.
29
Операционные системы
На рис. 1 и 2 изображена последовательность слоев L(0), L(1),…, L(n), причем L(0) – аппаратура, а
L(1) – первый слой программ. Рассмотрим вариант, когда слой L(i) может иметь доступ только к
средствам виртуальной машины, определяемой слоем L(i -1). Если слою L(i) потребуется какое-либо
средство слоя L(i-2), то слой L(i -1) должен также предоставить это средство.
Рассмотрим теперь другой вариант, когда слой L(i) может использовать все средства, предоставляемые слоями L(1), L(2),…, L(i-1). Таким образом, виртуальная машина, определяемая слоем L(i)
включает все команды до слоя L(i) и команды, реализуемые слоем L(i).
Третий вариант является промежуточным между двумя первыми. В этом случае слою L(i)
разрешается использовать только некоторые из команд, обеспечиваемых слоями L(1), L(2),…, L(i-1).
В некоторых системах (например, в
операционных системах) первый слой
является единственным слоем, который
может выдавать привилегированные
команды аппаратному оборудованию.
На рис. 3 представлена возможная
многоуровневая иерархическая
структура операционной системы, в
которой машинно-зависимые модули
ядра (уровень L(1)) и базовые
механизмы ядра (уровень L(2))
используют привилегированные
команды процессора. Другие слои могут
выполнять непривилегированные
команды плюс команды нижележащих
слоев в соответствии с одним из трех
рассмотренных выше вариантов.
Рис. 3
Операционные системы
30
Каждый вариант имеет свои достоинства и недостатки. Для их рассмотрения обратимся к рис. 4.
Здесь показано два варианта возможной структуры операционной системы: слева (рис. 4-а) вариант
структуры с многоуровневым модульным ядром и справа (рис. 4-б) – вариант структуры с компактным
микроядром. Если в варианте 4-а каждый слой имеет доступ к командам только одного слоя, разработчик должен иметь в виду только предыдущий слой. Хотя с точки зрения проектирования этот вариант
кажется привлекательным, он может оказаться очень неэффективным.
Рис. 4-а
Рис. 4-б
Например, если некоторое средство, предоставляемое слоем L(2) – базовые механизмы ядра –
потребуется в слое L(i), то каждый из слоев L(3), L(4),..., L(i-1) должен обеспечить это средство. Это значит,
что запрос данного средства слоем L(i) должен “просачиваться” вниз через слой L(i-1), пока не достигнет
слоя L(2), который способен выполнить запрос. Эти трудности, связанные с проблемой эффективности,
могут склонить к принятию структуры, в которой каждый слой L(i), где 2< I < n, может непосредственно
обращаться к слою L(2), реализующему базовые механизмы ядра. Так, например, организована
операционная система Windows 2000/2003/XP (рис. 5).
31
Операционные системы
Рис. 5
32
Операционные системы
Рассмотрим теперь вариант по рис. 4 б). В данном случае выделено три слоя (два в микроядре) и
третий – остальные модули системы. При этом, если какой либо компонент (модуль) третьего слоя
потребует функцию другого компонента этого же слоя, то такая услуга может быть получена только
через микроядро. В данном случае взаимодействие модулей слоев организовано по принципу клиентсерверной архитектуры (рис.6), эффективность которого может быть выше по сравнению с вариантом
по рис. 4а) при условии доступа модулей слоя L(i) только к слою L(i-1).
Рис. 6
Однако производительность микроядерной ОС в целом ниже производительности архитектуры,
приятой в упомянутых системах Windows 2000/2003/XP по причине возможного многократного
переключения работы компьютера из пользовательского режима в режим ядра при выполнении
системных вызовов.
33
Операционные системы
Рис. 7
Схема архитектурных слоев обладает и определенными недостатками:
Каскадные изменения. Слои способны удачно инкапсулировать многое, но не все: модификация одного слоя
подчас связана с необходимостью внесения каскадных изменений в остальные слои. Классический пример из
области корпоративных программных приложений: поле, добавленное в таблицу базы данных, подлежит
воспроизведению в графическом интерфейсе и должно найти соответствующее отображение в каждом
промежуточном слое.
Падение производительности. Наличие избыточных слоев снижает производительность системы. При
переходе от слоя к слою данные подвергаются преобразованиям из одного представления в другое.
34
Операционные системы
В заключение данного раздела отметим, что можно построить древовидную
структуру слоев системы (рис. 8), в которой каждый слой может иметь доступ
только к тем слоям, которые соответствуют его предшественникам по дереву.
Дерево частей такой программы представляет на самом деле дерево
виртуальных машин. Такая организация была впервые использована при
создании ядра операционной системы SUE, разработанной в университете
Торонто в 1972 году для семейства машин IBM/360 [Цикритзис].
35
Операционные системы
2.5.2. Архитектуры, основанные на портах
При использовании механизма портов программная система делится на несколько подсистем,
каждая из которых может иметь один или несколько входных портов (очередей). Порт – это текущий
список входных сообщений для подсистемы. Каждая подсистема рассматривается как асинхронный
процесс, т.е. все подсистемы работают параллельно. Если одна из них хочет передать некоторые данные
другой, она посылает их во входной порт этой другой подсистемы. Если подсистема готова обрабатывать
какие-то данные, она читает их из своих входных портов. Для организации такой связи используются
операции ПОСЛАТЬ и ПОЛУЧИТЬ.
На рис. 8 изображена подсистема
программной системы (процесс), имеющий
несколько первичных входных портов, по
одному для каждой функции процесса.
Процесс может выполнять команды типа
ПОЛУЧИТЬ_ПОРТi (A,B,C), по которой из
входного порта ПОРТi выбирается
очередное сообщение и выделенные из него
аргументы присваиваются параметрам
A,B,C. Процесс, показанный на рис. 8, –
часть прямой конфигурации. Каждый
такой процесс осуществляет связь
посылкой сообщения прямо во входной
порт другого процесса.
Рис. 8
Процесс может послать данные другим процессам в результате выполнения команд
ПОСЛАТЬ_УПРДАННЫМИ (Х, У), по которой из аргументов Х, У формируется сообщение, пересылаемое в порт по имени УПРДАННЫМИ. У процесса может быть и другой набор портов – вторичные
порты. Они используются для связи с подчиненными процессами. Например, подчиненный процесс
может поставлять данные из базы данных.
36
Операционные системы
На рис. 9 изображен процесс, являющийся
частью непрямой конфигурации. Процессы этого
типа имеют выходные порты. Вместо того чтобы
посылать сообщения во входные порты других
процессов, они посылают сообщения в свои
выходные порты. Выходной порт связывается с
входными портами других процессов посредством
специальных указаний, например в компьютерах
третьего поколения, на языке управления
заданиями. Физически выходные порты не
существуют, это абстрактные наименования для
входных портов других процессов.
Рис. 9
Рис. 10
На рис. 10 приведена схема информационнопоисковой системы, использующей прямую
конфигурацию. Управление терминалами – это
непрерывно выполняемый процесс, который
опрашивает терминалы пользователей и,
получив команду с терминала, посылает
сообщение подсистеме интерпретации команд.
Сообщение состоит из двух аргументов:
идентификатора терминала и команды.
Управление терминалом выполняет также
функцию выдачи на терминал выходных строк.
Получив команду с терминала подсистема
интерпретации команд, использует две
подчиненные системы, чтобы подготовить ключ
для поиска и осуществить поиск в базе данных.
Когда поиск закончен, она посылает результат
вместе с идентификатором терминала
подсистемы редактирования и выдачи.
37
Операционные системы
2.5.3. Архитектуры, основанные на потоках данных
По сути эти архитектуры являются современным вариантом рассмотренных
архитектур, управляемых портами сообщений. В общем случае архитектуры,
основанные на потоках данных, представляются как совокупность процессов, каждый
из которых принимает данные из различных источников, а также возвращает данные в
другие источники или хранилища данных. Процессы проектируются независимо друг от
друга. Такие архитектуры давно используются и изображаются с помощью диаграмм
потоков данных (DFD-диаграммы). Метамодель диаграммы потоков данных приведена
на рис. 11.
Рис. 11
Как разновидность таких архитектур рассматриваются архитектуры типа каналы и
фильтры, в которых процессы называются фильтрами, а потоки направляются через каналы.
38
Операционные системы
2.5.4. Архитектуры независимых компонентов
Программные системы такой архитектуры состоят из независимо работающих компонентов,
время от времени общающихся друг с другом. Компонент, называемый клиентом, выдает запрос для
выполнения какого-либо действия к другому компоненту, называемому сервером. Такое отношение
называется клиент-серверным. Преобладание таких отношений характерно для клиент-серверной
архитектуры. Классическая двухуровневая архитектура клиент-сервер постоянно усложнялась
добавлением новых уровней. Отдельный уровень может управлять процедурами (сервер приложений),
другой - данными (сервер баз данных в трехуровневой архитектуре).
Значительную роль в разработке систем на основе архитектуры независимых компонентов
сыграл международный консорциум OMG (Object Management Group). Дело в том, что в мире
существует громадное количество готовых к использованию информационно-вычислительных
ресурсов. Они создавались в разное время, для их разработки использовались разные подходы. Почти
всегда при разработке новой информационной системы можно найти подходящие по своим функциям
уже работающие готовые компоненты. Проблема состоит в том, что при их создании не учитывались
требования интероперабельности. Эти компоненты не понимают друг друга и не могут работать
совместно. Желательно иметь набор механизмов, которые позволят сделать такие ресурсы
интероперабельными.
Основной задачей OMG является разработка архитектуры и методов реализации программного
обеспечения, которое в объектно-ориентированном стиле позволило бы выполнить интеграцию
существующих и заново разрабатываемых (не обязательно объектно-ориентированных)
информационно-вычислительных ресурсов.
Основными составляющими подхода OMG являются базовая объектная модель (Core Object
Model), эталонная модель архитектуры (OMA - Object Management Architecture) и более приближенная
к реализации общая архитектура брокера объектных заявок (CORBA - Common Object Request Broker
Architecture).
39
Операционные системы
На рис. 12 приведена эталонная модель метаобъектного средства OMG. На нижнем уровне находятся
отдельные объекты. Объектные типы определяют общие свойства схожих объектов. Объектные типы в
свою очередь являются экземплярами метаобъектной модели. С помощью этой метамодели описываются
архитектуры OMG/CORBA, Microsoft/COM и Java/RMI (RMI – Remote Method Invocation) —
программный интерфейс вызова удаленных методов ).
Рис. 12
Идея CORBA довольно проста. Она заключается в следующем. Во-первых, в каждый объект,
который должен быть включен в интегрированную объектную систему, добавляется специальный
программный код, обеспечивающий принципиальную возможность взаимодействия объектов. Этот
код генерируется автоматически за счет использования определенного OMG языка определения
объектных интерфейсов IDL (Interface Definition Language). В исходный текст программы
включаются спецификации интерфейса на языке IDL. Затем этот текст должен быть обработан
специальным прекомпилятором, который и генерирует дополнительный программный код.
На сегодняшний день в документах OMG определены правила встраивания конструкций IDL в
далеко не все языки программирования, но, по крайней мере, определены правила встраивания для
таких популярных языков как Си и Си++.
40
Операционные системы
2.5.5. Сервис-ориентированные архитектуры
К основным характеристикам SOA, отличающим ее от других архитектур информационных
систем, следует отнести:
 распределенность;
 слабосвязанные интерфейсы (отсутствие жестких связей между элементами системы), что
упрощает конфигурирование системы и координирование работы ее элементов;
 базирование архитектуры на международных открытых стандартах;
 возможность динамического поиска и подключения нужных функциональных модулей;
 построение систем с расчетом на процессы с использованием сервисов, ориентированных на
решение определенных бизнес-задач.
Метамодель SOA (рис.13) включает следующие модели:
 модель политик (PОM) определяет политики, связанные с архитектурой, в основном она представляет
собой ограничения, накладываемые на поведение агентов и сервисов, в том числе ограничения, связанные
с требованиями безопасности и качества обслуживания;
 модель, ориентированная на сервисы (SOM), сосредоточена на действиях, выполняемых сервисами;
 модель, ориентированная на ресурсы (ROM), сосредоточена на системных ресурсах;
 модель, ориентированная на сообщения (MOM), сосредоточена на сообщениях, их структуре, способах
транспортировки и других компонентах, никак не связанных с причинами обмена сообщениями и их
семантикой.
41
Операционные системы
Семинар на тему: Архитектурные типы и структуры
1. Двухуровневые и многоуровневые клиент-серверные архитектуры
2. Архитектуры, основанные на потоках данных
3. Архитектуры независимых компонентов
4. CORBA – архитектура
5. Сервис-ориентированные архитектуры
Содержание выступлений
Достоинства и недостатки архитектуры
Сфера применения
Сложность разработки
Возможность повторного использования кода
Наличие и развитость инструментальных средств
Экономическая целесообразность
42
Операционные системы