Архитектура в контексте жизненного цикла

Любая организация, строящая процесс разработки программных продуктов на основе архитектуры, должна знать, какое место эта последняя занимает в жизненном цикле. В литературе имеют хождение несколько моделей жизненного цикла, но лишь в одной из них — изображенной на рис. 7.1 модели эволюционного жизненного цикла поставки (Evolutionary Delivery Life Cycle) — архитектура выводится на первый план. Назначение этой модели состоит в том, чтобы, во-первых, получить отзывы пользователей и заказчиков, а во-вторых, предварить конечный выпуск разработкой нескольких промежуточных. Кроме того, с каждой новой итерацией эта модель позволяет вводить в систему новые функции, а после завершения разработки соответствующего набора характеристик — поставлять ограниченные версии. (Дополнительные сведения об этой модели жизненного цикла содержатся в разделе «Дополнительная литература» далее в этой главе.)

Когда приступать к проектированию?

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

анализа требований. Действительно, как можно проектировать систему, не имея ни малейшего представления о выдвигаемых к ней требованиях? С другой стороны, для начала проектирования требуется знать не так уж много характеристик Любая архитектура «формируется» из некоей совокупности функциональных и коммерческих требований, а также требований по качеству. Эти требования обнаруживаемые, в частности, по конкретным примерам, мы называем архитектурными мотивами (architecture1 divers). Характеристики архитектуры системы А-7Е, рассмотренной в главе 3, обусловливаются требованиям по модифицируемости и производительности. Архитектура системы управления воздушным движением из главы б находится в зависимости от требований по готовности. Что же касается программы моделирования условий полета, представленной в главе 8, то для ее архитектуры определяющими являются требования по производительности и модифицируемости, в чем вы еще сможете убедиться и т. д.

Для того чтобы установить архитектурные мотивы, проще всего разобраться с наиболее значимыми коммерческими задачами. Таковых не может быть слишком много. Представьте эти задачи в виде сценариев атрибутов качества или элементов Use Case. Затем выберите те из них, которые потенциально способны оказать на архитектуру наибольшее влияние. Именно они и являются архитектурными мотивами, и их вряд ли окажется больше десяти. Метод анализа компромиссных архитектурных решений (architecture tradeoff analysis method, АТАМ), рассматриваемый в главе 11, предусматривает применение вспомогательного дерева (utility tree), которое помогает на основе разного рода коммерческих факторов выводить сценарии атрибутов качества.

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