СОЗДАНИЕ АРХИТЕКТУРЫ

В части 1 книги мы сформулировали определение архитектурно-экономического цикла (Architecture Business Cycle, ABC) и разобрались с основными понятиями, необходимыми для дальнейшего изучения программной архитектуры. В частности, мы установили факторы влияния на архитектора, проявляющиеся на начальных стадиях производства систем, и выяснили, что требования к тем или иным атрибутам качества — будь то производительность или модифицируемость — во многих случаях обусловливаются коммерческими задачами компании-разработчика. Так что же собой представляет процесс создания архитектуры архитектором? Об этом речь пойдет в части 2. Поскольку успех системы в значительной степени определяется реализацией атрибутов качества, мы начнем с рассмотрения качества и тех средств, при помощи которых архитектор способен его обеспечить.

Перефразируя Бута Таркингтона (Booth Tarkington), скажем, что качество — в глазах смотрящего. Заказчики не обязаны принимать решения архитектора с бурным восторгом — у них, в конце концов, могут быть свои представления о качестве. Инструментом объективной оценки качества являются сценарии атрибутов качества. В главе 4 мы рассмотрим различные составляющие качества, которые в тех или иных обстоятельствах оказываются значимыми для архитектуры. Для всех шести важнейших атрибутов (готовность, модифицируемость, производительность, безопасность, контролепригодность и практичность) мы представим методики составления сценариев, отражающих требования по качеству. Эти сценарии определяют степень значимости конкретного атрибута качества в контексте данной системы, и именно исходя из этой его оценки архитекторы и заказчики должны выносить суждения о проекте.

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

Глава 6 отводится под второй в книге конкретный пример — систему, разработанную по заказу Федерального авиационного агентства США и предназначенную для реализации функций управления воздушным движением. Эта система, к которой в процессе проектирования предъявлялись очень высокие требования по готовности (ограничивавшие простой пятью минутами в год), иллюстрирует применение тактик, перечисленных в главе 5.

Сценарии атрибутов качества и архитектурные тактики — это лишь некоторые из инструментов архитектора. В главе 7 мы обсудим, как эти инструменты применяются при проектировании архитектуры и создании макета системы; кроме того, мы проанализируем влияние архитектуры на структуру компании-разработчика.

В главе 8 рассматривается третий конкретный пример — система моделирования условий полета. От подобного рода систем требуется производительность в реальном времени и удобство модифицирования. Мы раскроем механизмы реализации этих задач.

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

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