1.2. Программный процесс и архитектурно-экономический цикл

Программным процессом, (software process) называются действия по организации, нормированию и управлению разработкой программного обеспечения. Какие операции направлены на создание программной архитектуры, ее применение для реализации проектного решения, а впоследствии — на реализацию или управление развитием целевой системы или приложения? Вот их перечень:

♦ создание экономической модели системы;

♦ выявление требований;

♦ создание новой или выбор существующей архитектуры;

♦ документирование и распространение сведений об архитектуре;

♦ анализ или оценка архитектуры;

♦ реализация системы на основе архитектуры;

♦ проверка соответствия реализации архитектуре.

Этапы разработки архитектуры

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

Создание экономической модели системы

Создание экономической модели не ограничивается оценкой потребности в системе на рынке. Этот этап исполняет существенную роль в контексте создания и сужения требований. Сколько должен стоить продукт? Каков целевой сегмент рынка? Насколько быстро продукт должен выйти на рынок? Должен ли он взаимодействовать с другими системами? Есть ли какие-нибудь системные ограничения, в рамках которых он должен существовать?

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

Выявление требований

Способов узнать, чего же, наконец, хотят заинтересованные лица, множество. В частности, в рамках объектно-ориентированного анализа для фиксации требований используются сценарии, или элементы Use Case. Для системы с повышенными требованиями к безопасности применяются более строгие методики — например, модели конечных автоматов и языки формальных спецификаций. В главе 4 («Атрибуты качества») мы разберем ряд сценариев атрибутов качества, обеспечивающих фиксацию требований к качеству системы.

Применительно к конструируемой системе необходимо принять центральное основополагающее решение — насколько в ней будут отражены другие, уже сконструированные системы. Поскольку в сегодняшних условиях найти систему, не имеющую сходств с другими системами, весьма непросто, методики выявления требований предполагают знание характеристик предшествующих систем. Архитектурное содержание линеек продуктов разбирается в главе 14 («Линейки продуктов. Повторное использование архитектурных средств»).

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

Вне зависимости от методики выявления требований желаемые атрибуты качества конструируемой системы обусловливают ее конечный вид. Для обеспечения отдельных атрибутов качества архитекторами уже давно применяются те или иные тактики. Многие из них рассматриваются в главе 5 («Реализация качества»). Архитектурные решения компромиссны, однако при специфицировании требований не все эти компромиссы очевидны. Со всей ясностью они проявляются только после создания архитектуры; тогда же принимаются решения относительно сортировки требований в соответствии с приоритетами.

Создание или выбор архитектуры

Фредерик Брукс (Fred Brooks) в своей знаменитой книге «Мифический человекомесяц» красноречиво и убедительно доказывает, что основным условием стабильного проектирования системы является соблюдение концептуальной целостности, а она может проявиться лишь в узком кругу людей, совместно работающих над проектированием ее архитектуры. Принципы реализации в ходе создания архитектуры требований по поведению и качеству демонстрируются в главах 5 («Реализация качества») и 7 («Создание архитектуры»).

Распространение сведений об архитектуре

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

Анализ или оценка архитектуры

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

Оценить архитектуру на предмет атрибутов качества, которые она обеспечивает, совершенно необходимо — без этого нельзя быть уверенным в том, что конечная система сможет удовлетворить все потребности заинтересованных лиц. Все большее распространение получают методики анализа, ориентированные на опенку сообщаемых системе архитектурой атрибутов качества. Сценарные методики обеспечивают наиболее универсальную и эффективную оценку архитектуры. Самая зрелая методическая бала характерна для метода анализа компромиссных архитектурных рехпе11ий (Architecture Tradeoff Analysis Method, АТАМ), рассматриваемого в главе И; метод анализа стоимости и эффективности (Cost Benefit Analysis Method, СВАМ, см. главу 12;, с другой стороны, предусматривает крайне пенную возможность увязки архитектурных решений с их экономическим содержанием.

Реализация на основе архитектуры

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

Проверка соответствия архитектуре

Когда архитектура составлена и задействована, наступает этап сопровождения. Для того чтобы обеспечить на этом этапе согласованность архитектуры и ее представления, нужно все время быть начеку. Область эта довольно молода, однако в последние годы в ней ведутся довольно интенсивные исследования. Современное состояние методик восстановления архитектуры исходя из существующей системы и проверки ее согласованности первоначальной архитектуре представлено в главе 10 ("Реконструкция программной архитектуры»).