Lecture06 (Лекции по Технологии программирования. Компонентный подход)

Технологии программирования. Компонентный подходВ. В. КуляминЛекция 6. Архитектура программного обеспеченияАннотацияРассматривается понятие архитектуры ПО, влияние архитектуры на свойства ПО, а также методыоценки архитектуры. Рассказывается об основных элементах унифицированного языкамоделирования UML.Ключевые словаАрхитектура ПО, компонент архитектуры, представление архитектуры, сценарий использования,методы оценки архитектуры, диаграммы классов, диаграммы взаимодействия, диаграммысценариев, диаграммы компонентов, диаграммы развертывания.Текст лекцииАнализ области решенийДопустим, мы разобрались в предметной области, поняли, что требуется от будущейпрограммной системы, даже зафиксировали настолько полно, насколько смогли, требования ипожелания всех заинтересованных лиц ко всем аспектам качества программы.

Что делать дальше?На этом этапе (а точнее, гораздо раньше, обычно еще в ходе анализа предметной области)исследуются возможные способы решения тех задач, которые поставлены в требованиях. Невсегда бывает нужно специальное изучение этого вопроса — чаще всего имеющийся опытразработчиков сразу подсказывает, как можно решать поставленные задачи. Однако иногда, всетаки, возникает потребность сначала понять, как это можно сделать и, вообще, возможно ли этосделать и при каких ограничениях.Таким образом, явно или неявно, проводится анализ области решений.

Целью этойдеятельности является понимание, можно ли вообще решить стоящие перед разрабатываемойсистемой задачи, при каких условиях и ограничениях это можно сделать, как они решаются, еслирешение есть, а если нет — нельзя ли придумать способ его найти или получить хотя быприблизительное решение, и т.п. Обычно задача хорошо исследована в рамках какой-либо областичеловеческих знаний, но иногда приходится потратить некоторые усилия на выработкусобственных решений. Кроме того, решений обычно несколько и они различаются по некоторымхарактеристикам, способным впоследствии сыграть важную роль в процессе развития иэксплуатации созданной на их основе программы. Поэтому важно взвесить их плюсы и минусы иопределить, какие из них наиболее подходят в рамках данного проекта, или решить, что все онидолжны использоваться для обеспечения большей гибкости ПО.Когда определены принципиальные способы решения всех поставленных задач (быть может, вкаких-то ограничениях), основной проблемой становится способ организации программнойсистемы, который позволил бы реализовать все эти решения и при этом удовлетворитьтребованиям, касающимся нефункциональных аспектов разрабатываемой программы.

Искомыйспособ организации ПО в виде системы взаимодействующих компонентов называютархитектурой, а процесс ее создания — проектированием архитектуры ПО.Архитектура программного обеспеченияПод архитектурой ПО понимают набор внутренних структур ПО, которые видны сразличных точек зрения и состоят из компонентов, их связей и возможных взаимодействий междукомпонентами, а также доступных извне свойств этих компонентов [1].Под компонентом в этом определении имеется в виду достаточно произвольный структурныйэлемент ПО, который можно выделить, определив интерфейс взаимодействия между этимкомпонентом и всем, что его окружает.

Обычно при разработке ПО термин «компонент» (см.далее при обсуждении компонентных технологий) имеет несколько другой, более узкий смысл —это единица развертывания, самая маленькая часть системы, которую можно включить или невключить в ее состав. Такой компонент также имеет определенный интерфейс и удовлетворяетнекоторому набору правил, называемому компонентной моделью. Там, где возможнынедоразумения, будет указано, в каком смысле употребляется этот термин. В этой лекции дообсуждения UML мы будем использовать преимущественно широкое понимание этого термина, ав дальше — наоборот, узкое.В определении архитектуры упоминается набор структур, а не одна структура. Это означает,что в качестве различных аспектов архитектуры, различных взглядов на нее выделяютсяразличные структуры, соответствующие разным аспектам взаимодействия компонентов.

Примерытаких аспектов — описание типов компонентов и типов статических связей между ними припомощи диаграмм классов, описание композиции компонентов при помощи структурссылающихся друг на друга объектов, описание поведения компонентов при помощимоделирования их как набора взаимодействующих, передающих друг другу некоторые события,конечных автоматов.Архитектура программной системы похожа на набор карт некоторой территории.

Карты имеютразные масштабы, на них показаны разные элементы (административно-политическое деление,рельеф и тип местности — лес, степь, пустыня, болота и пр., экономическая деятельность и связи),но они объединяются тем, что все представленные на них сведения соотносятся с географическимположением. Точно так же архитектура ПО представляет собой набор структур илипредставлений, имеющих различные уровни абстракции и показывающих разные аспекты(структуру классов ПО, структуру развертывания, т.е. привязки компонентов ПО к физическиммашинам, возможные сценарии взаимодействий компонентов и пр.), объединяемыхсопоставлением всех представленных данных со структурными элементами ПО. При этом уровеньабстракции данного представления является аналогом масштаба географической карты.Рассмотрим в качестве примера программное обеспечение авиасимулятора для команднойтренировки пилотов.

Задачей такой системы в целом является контроль и выработка необходимыхдля безопасного управления самолетом навыков у команд летчиков. Кроме того, отрабатываютсянавыки поведения в особых ситуациях, связанных с авариями, частичной потерей управлениясамолетом, тяжелыми условиями полета, и т.д.Симулятор должен:• Моделировать определенные условия полета и создавать некоторые события, к которымотносятся следующие.o Скоростной и высотный режим полета, запас горючего, их изменения со временем.o Модель самолета и ее характеристики по управляемости, возможным режимам полета искорости реакции на различные команды.o Погода за бортом и ее изменения со временем.o Рельеф и другие особенности местности в текущий момент, их изменения со временем.o Исходный и конечный пункты полета, расстояние и основные характеристики рельефамежду ними.o Исправность или неисправность элементов системы контроля полета и управлениясамолетом, показатели системы мониторинга и их изменение со временем.o Наличие пролетающих вблизи курса самолета других самолетов, их геометрические искоростные характеристики.o Чрезвычайные ситуации, например, террористы на борту, нарушение герметичностикорпуса, внезапные заболевания и «смерть» отдельных членов экипажа.При этом вся совокупность условий должна быть непротиворечивой, выглядеть иразвиваться подобно реальным событиям.

Некоторые условия, например, погода, должныизменяться достаточно медленно, другие события — происходить внезапно и приводить ксвязанным с ними последствиям (нарушение герметичности корпуса можетсопровождаться поломками каких-то элементов системы мониторинга или «смертью»одного из пилотов). Если приборы показывают наличие грозы по курсу и они исправны,через некоторое время летчики должны увидеть грозу за бортом и она может начатьоказывать влияние на условия полета.• Принимать команды, подаваемые пилотами, и корректировать демонстрируемыехарактеристики полета и работы системы управления самолетом в зависимости от этихкоманд, симулируемой модели самолета и исправности системы управления.

Например,при повороте на некоторый угол вправо, показываемый пилотам «вид из кабины» долженпереместиться на соответствующий угол влево со скоростью, соответствующей скоростиреакции симулируемой модели самолета и исправности задействованных элементовсистемы управления.Понятно, что одним из элементов симулятора служит система визуализации обстановки забортом — она показывает пилотам «вид за окнами». Пилоты в ходе полета ориентируются попоказателям огромного количества датчиков, представленных на приборной панели самолета. Всяих работа тоже должна симулироваться.

Наличие и характеристики работы таких датчиков могутзависеть от симулируемой модели, но их расположение, форма и цвет служат слишком важнымиэлементами выработки навыков управления самолетом, поэтому требуется поддерживать этихарактеристики близкими к реальным. Представлять их только в виде изображений на некоторойпанели неудобно, поскольку они должны располагаться и выглядеть максимально похоже нареальные прототипы. Значит, симулировать можно только небольшое семейство самолетов спрактически одним и тем же наборов приборов на приборной панели.Подсистемавизуализацииобстановки забортомПодсистемауправленияпоказаниямиприборовПодсистемамоделированияисправностиприборовПилотыЭкранЭлементыуправленияПриборыПодсистемарегистрацииусловий исобытийКамеры имикрофоныПодсистемаприемакомандпилотовПодсистемамоделированияисправностиэлементовуправленияОператорПодсистемамоделированиярежима полета ивнешней средыГенераторсобытийИнтерфейсоператораРисунок 27.