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

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

Каждый из указанныхкомпонентов решает свои задачи, которые необходимы для работы всей системы. В совокупностиони решают все задачи системы в целом. Стрелками показаны потоки данных и управления междукомпонентами. Пунктирные стрелки изображают потоки данных, передаваемых дляпротоколирования.Архитектура определяет большинство характеристик качества ПО в целом.

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

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

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

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

Чем сильнее защищена система, тем больше проверок, процедуридентификации и пр. нужно проходить пользователям. Соответственно, тем менее удобна для нихработа с такой системой. При разработке реальных систем приходится искать некоторыйразумный компромисс, чтобы сделать систему достаточно защищенной и способной поставитьощутимую преграду для несанкционированного доступа к ее данным и, в то же время, неотпугнуть пользователей сложностью работы с ней.Список стандартов, регламентирующих описание архитектуры, которое является основнойсоставляющей проектной документации на ПО, выглядит так.• IEEE 1016-1998 Recommended Practice for Software Design Descriptions [2](рекомендуемые методы описаний проектных решений для ПО).• IEEE 1471-2000 Recommended Practice for Architectural Description of Software-IntensiveSystems [3] (рекомендуемые методы описания архитектуры программных систем).Основное содержание этого стандарта сводится к определению набора понятий, связанныхс архитектурой программной системы.Это, прежде всего, само понятие архитектуры как набора основополагающих принциповорганизации системы, воплощенных в наборе ее компонентов, связях их друг с другом имежду ними и окружением системы, а также принципов проектирования и развитиясистемы.Это определение, в отличие от данного в начале этой лекции, делает акцент не на набореструктур в основе архитектуры, а на принципах ее построения.Стандарт IEEE 1471 определяет также представление архитектуры (architecturaldescription) как согласованный набор документов, описывающий архитектуру с точкизрения определенной группы заинтересованных лиц с помощью набора моделей.Архитектура может иметь несколько представлений, отражающих интересы различныхгрупп заинтересованных лиц.Стандарт рекомендует для каждого представления фиксировать отраженные в нем взглядыи интересы, роли лиц, которые заинтересованы в таком взгляде на систему, причины,обуславливающие необходимость такого рассмотрения системы, несоответствия междуэлементами одного представления или между различными представлениями, а такжеразличную служебную информацию об источниках информации, датах созданиядокументов и пр.Стандарт IEEE 1471 отмечает необходимость использования архитектуры системы длярешения таких задач, как следующие.o Анализ альтернативных проектов системы.o Планирование перепроектирования системы, внесения изменений в ее организацию.o Общение по поводу системы между различными организациями, вовлеченными в ееразработку, эксплуатацию, сопровождение, приобретающими систему илипродающими ее.o Выработка критериев приемки системы при ее сдаче в эксплуатацию.o Разработка документации по ее использованию и сопровождению, включая обучающиеи маркетинговые материалы.o Проектирование и разработка отдельных элементов системы.o Сопровождение, эксплуатация, управление конфигурациями и внесение изменений ипоправок.o Планирование бюджета и использования других ресурсов в проектах, связанных сразработкой, сопровождением или эксплуатацией системы.o Проведение обзоров, анализ и оценка качества системы.Разработка и оценка архитектуры на основе сценариевПри проектировании архитектуры системы на основе требований, зафиксированных в видевариантов использования, первые возможные шаги состоят в следующем.• Выделение компонентовo Выбирается набор «основных» сценариев использования — наиболее существенных ивыполняемых чаще других.o Исходя из опыта проектировщиков, выбранного архитектурного стиля (см.

следующуюлекцию) и требований к переносимости и удобству сопровождения системыопределяются компоненты, отвечающие за определенные действия в рамках этихсценариев, т.е. за решение определенных подзадач.o Каждый сценарий использования системы представляется в виде последовательностиобмена сообщениями между полученными компонентами.o При возникновении дополнительных хорошо выделенных подзадач добавляются новыекомпоненты, и сценарии уточняются.• Определение интерфейсов компонентовo Для каждого компонента в результате выделяется его интерфейс — набор сообщений,которые он принимает от других компонентов и посылает им.o Рассматриваются «неосновные» сценарии, которые так же разбиваются напоследовательности обмена сообщениями с использованием, по возможности, ужеопределенных интерфейсов.o Если интерфейсы недостаточны, они расширяются.o Если интерфейс компонента слишком велик, или компонент отвечает за слишкоммногое, он разбивается на более мелкие.• Уточнение набора компонентовo Там, где это необходимо в силу требований эффективности или удобствасопровождения, несколько компонентов могут быть объединены в один.o Там, где это необходимо для удобства сопровождения или надежности, один компонентможет быть разделен на несколько.• Достижение нужных свойств.Все это делается до тех пор, пока не выполнятся следующие условия:o Все сценарии использования реализуются в виде последовательностей обменасообщениями между компонентами в рамках их интерфейсов.o Набор компонентов достаточен для обеспечения всей нужной функциональности,удобен для сопровождения или портирования на другие платформы и не вызываетзаметных проблем производительности.o Каждый компонент имеет небольшой и четко очерченный круг решаемых задач истрого определенный, сбалансированный по размеру интерфейс.На основе возможных сценариев использования или модификации системы возможен такжеанализ характеристик архитектуры и оценка ее пригодности для поставленных задач илисравнительный анализ нескольких архитектур.