Анализ области решений

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

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

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

Таким образом, явно или неявно, проводится анализ области решений.

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

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

Архитектура программного обеспечения

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

Под компонентом в этом определении имеется в виду достаточно произвольный структурный элемент ПО, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает.

Архитектура программной системы похожа на набор карт некоторой территории.

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

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

Рассмотрим в качестве примера программное обеспечение авиасимулятора для командной тренировки пилотов.

Задачей такой системы в целом является контроль и выработка необходимых для безопасного управления самолетом навыков у команд летчиков. Кроме того, отрабатываются навыки поведения в особых ситуациях, связанных с авариями, частичной потерей управления самолетом, тяжелыми условиями полета, и т. д.

Симулятор должен:

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

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

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

Рис. 6.1. Набросок архитектуры такого авиасимулятора.

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

Пунктирные стрелки изображают потоки данных, передаваемых для протоколирования.

Список стандартов, регламентирующих описание архитектуры, которое является основной составляющей проектной документации на ПО, выглядит так:

• · IEEE 1016−1998 Recommended Practice for Software Design Descriptions [2] (рекомендуемые методы описаний проектных решений для ПО).
• · IEEE 1471−2000 Recommended Practice for Architectural Description of Software-Intensive Systems [3] (рекомендуемые методы описания архитектуры программных систем).

Стандарт IEEE 1471 определяет также представление архитектуры (architectural description) как согласованный набор документов, описывающий архитектуру с точки зрения определенной группы заинтересованных лиц с помощью набора моделей. Архитектура может иметь несколько представлений, отражающих интересы различных групп заинтересованных лиц.

Стандарт IEEE 1471 отмечает необходимость использования архитектуры системы для решения таких задач, как следующие:

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