В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 24
Текст из файла (страница 24)
Там, где возможнынедоразумения, будет указано, в каком смысле употребляется этот термин. В этой лекции дообсуждения UML мы будем использовать преимущественно широкое понимание этого термина, ав дальше — наоборот, узкое.В определении архитектуры упоминается набор структур, а не одна структура.
Это означает,что в качестве различных аспектов архитектуры, различных взглядов на нее выделяютсяразличные структуры, соответствующие разным аспектам взаимодействия компонентов. Примерытаких аспектов — описание типов компонентов и типов статических связей между ними припомощи диаграмм классов, описание композиции компонентов при помощи структурссылающихся друг на друга объектов, описание поведения компонентов при помощимоделирования их как набора взаимодействующих, передающих друг другу некоторые события,конечных автоматов.Архитектура программной системы похожа на набор карт некоторой территории. Карты имеютразные масштабы, на них показаны разные элементы (административно-политическое деление,рельеф и тип местности — лес, степь, пустыня, болота и пр., экономическая деятельность и связи),но они объединяются тем, что все представленные на них сведения соотносятся с географическимположением. Точно так же архитектура ПО представляет собой набор структур илипредставлений, имеющих различные уровни абстракции и показывающих разные аспекты(структуру классов ПО, структуру развертывания, т.е.
привязки компонентов ПО к физическиммашинам, возможные сценарии взаимодействий компонентов и пр.), объединяемыхсопоставлением всех представленных данных со структурными элементами ПО. При этом уровеньабстракции данного представления является аналогом масштаба географической карты.Рассмотрим в качестве примера программное обеспечение авиасимулятора для команднойтренировки пилотов. Задачей такой системы в целом является контроль и выработка необходимыхдля безопасного управления самолетом навыков у команд летчиков. Кроме того, отрабатываютсянавыки поведения в особых ситуациях, связанных с авариями, частичной потерей управлениясамолетом, тяжелыми условиями полета, и т.д.Симулятор должен:• Моделировать определенные условия полета и создавать некоторые события, к которымотносятся следующие.o Скоростной и высотный режим полета, запас горючего, их изменения со временем.o Модель самолета и ее характеристики по управляемости, возможным режимам полета искорости реакции на различные команды.o Погода за бортом и ее изменения со временем.o Рельеф и другие особенности местности в текущий момент, их изменения со временем.o Исходный и конечный пункты полета, расстояние и основные характеристики рельефамежду ними.o Исправность или неисправность элементов системы контроля полета и управлениясамолетом, показатели системы мониторинга и их изменение со временем.o Наличие пролетающих вблизи курса самолета других самолетов, их геометрические искоростные характеристики.o Чрезвычайные ситуации, например, террористы на борту, нарушение герметичностикорпуса, внезапные заболевания и «смерть» отдельных членов экипажа.При этом вся совокупность условий должна быть непротиворечивой, выглядеть иразвиваться подобно реальным событиям.
Некоторые условия, например, погода, должныизменяться достаточно медленно, другие события — происходить внезапно и приводить ксвязанным с ними последствиям (нарушение герметичности корпуса можетсопровождаться поломками каких-то элементов системы мониторинга или «смертью»одного из пилотов). Если приборы показывают наличие грозы по курсу и они исправны,через некоторое время летчики должны увидеть грозу за бортом и она может начатьоказывать влияние на условия полета.76•Принимать команды, подаваемые пилотами, и корректировать демонстрируемыехарактеристики полета и работы системы управления самолетом в зависимости от этихкоманд, симулируемой модели самолета и исправности системы управления. Например,при повороте на некоторый угол вправо, показываемый пилотам «вид из кабины» долженпереместиться на соответствующий угол влево со скоростью, соответствующей скоростиреакции симулируемой модели самолета и исправности задействованных элементовсистемы управления.Понятно, что одним из элементов симулятора служит система визуализации обстановки забортом — она показывает пилотам «вид за окнами».
Пилоты в ходе полета ориентируются попоказателям огромного количества датчиков, представленных на приборной панели самолета. Всяих работа тоже должна симулироваться. Наличие и характеристики работы таких датчиков могутзависеть от симулируемой модели, но их расположение, форма и цвет служат слишком важнымиэлементами выработки навыков управления самолетом, поэтому требуется поддерживать этихарактеристики близкими к реальным.
Представлять их только в виде изображений на некоторойпанели неудобно, поскольку они должны располагаться и выглядеть максимально похоже нареальные прототипы. Значит, симулировать можно только небольшое семейство самолетов спрактически одним и тем же наборов приборов на приборной панели.Кроме того, все команды пилотов должны восприниматься соответствующими компонентамисимулятора и встраиваться в моделируемые условия. В симулятор должен быть включенгенератор событий, зависящий от текущей ситуации, а также интерфейс мониторинга иуправления, с помощью которого внешний оператор мог бы создавать определенные события вовремя симуляции полета наблюдать за всем, что происходит. Все события и действия пилотовдолжны протоколироваться с помощью камер и микрофонов для дальнейшего разбора полетов.Подсистемавизуализацииобстановки забортомПодсистемауправленияпоказаниямиприборовПодсистемамоделированияисправностиприборовПилотыЭкранЭлементыуправленияПриборыПодсистемарегистрацииусловий исобытийКамеры имикрофоныПодсистемаприемакомандпилотовПодсистемамоделированияисправностиэлементовуправленияОператорПодсистемамоделированиярежима полета ивнешней средыГенераторсобытийИнтерфейсоператораРисунок 27.
Примерная архитектура авиасимулятора.Рис. 27 показывает набросок архитектуры такого авиасимулятора. Каждый из указанныхкомпонентов решает свои задачи, которые необходимы для работы всей системы. В совокупностиони решают все задачи системы в целом. Стрелками показаны потоки данных и управления междукомпонентами. Пунктирные стрелки изображают потоки данных, передаваемых дляпротоколирования.Архитектура определяет большинство характеристик качества ПО в целом.
Архитектураслужит также основным средством общения между разработчиками, а также междуразработчиками и всеми остальными лицами, заинтересованными в данном ПО.77Выбор архитектуры задает способ реализации требований на высоком уровне абстракции.Именно архитектура почти полностью определяет такие характеристики ПО как надежность,переносимость и удобство сопровождения. Она также значительно влияет на удобствоиспользования и эффективность ПО, которые, однако, сильно зависят и от реализации отдельныхкомпонентов. Значительно меньше влияние архитектуры на функциональность — обычнозаданную функциональность можно реализовать, использовав совершенно различныеархитектуры.Поэтому выбор между той или иной архитектурой определяется в большей степени именнонефункциональными требованиями и необходимыми свойствами ПО с точки зрения удобствасопровождения и переносимости.
При этом для построения хорошей архитектуры надо учитыватьвозможные противоречия между требованиями к различным характеристикам и уметь выбиратькомпромиссные решения, дающие приемлемые значения по всем показателям.Так, для повышения эффективности в общем случае выгоднее использовать монолитныеархитектуры, в которых выделено небольшое число компонентов (в пределе — единственныйкомпонент). Этим обеспечивается экономия как памяти, поскольку каждый компонент обычноимеет свои данные, а здесь число компонентов минимально, так и времени работы, посколькувозможность оптимизировать работу алгоритмов обработки данных имеется также только врамках одного компонента.С другой стороны, для повышения удобства сопровождения, наоборот, лучше разбить системуна большое число отдельных маленьких компонентов, с тем чтобы каждый из них решал своюнебольшую, но четко определенную часть общей задачи.
При этом, если возникают изменения втребованиях или проекте, их обычно можно свести к изменению в постановке одной, реже двухили трех таких подзадач и, соответственно, изменять только отвечающие за решение этихподзадач компоненты.С третьей стороны, для повышения надежности лучше использовать либо небольшой наборпростых компонентов, либо дублирование функций, т.е. сделать несколько компонентовответственными за решение одной подзадачи. Заметим, однако, что ошибки в ПО чаще всегоносят неслучайный характер.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
