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

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

Решите, будет ли архитектура ссылочной, или она будет основана на других архитектурных шаблонах или других архитектурных ресурсах.

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

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

Например, при разработке систем электронного бизнеса требуется следующая информация:

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

Такая информация может быть собрана или в текстовом виде, или в виде Модели развертывания.

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

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

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

Наконец, решите в принципе, будет ли использоваться один или несколько ресурсов и обоснуйте в документе это решение.

Если внимание сосредоточено на начальном архитектурном синтезе, то этот шаг выполняется, начиная с этой задачи.

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

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

Более подробная информация о слоях находится в разделе Рекомендации по рабочему продукту: Разделение на слои.

Когда внимание сосредоточено на архитектурном синтезе, этот шаг выполняется для руководства разработчиком программного обеспечения в выборе ресурсов для проектирования Рабочий продукт: Архитектурный опытный образец и для поддержки образцов сценариев.

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

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

При определении ключевых абстракций необходимо также определить все взаимосвязи, которые существуют между классами. Представьте ключевые абстракции в одной или нескольких диаграммах классов, и создайте короткое описание для каждой из них.  В зависимости от предметной области и новизны системы шаблоны анализа, в которых собраны многие из ключевых абстракций, требуемых для моделирования системы, могут уже существовать. Использование этих шаблонов (которые должны быть уже успешно применены в этой предметной области) значительно облегчит определение важных концепций, которые должны быть представлены. В [FOW97a] представлены некоторые шаблоны анализа, которые полезны для моделирования систем бизнеса, но могут применяться и в других контекстах. Другим примером является Группа управления объектом (OMG), которая также пытается определить интерфейсы и протоколы для многих предметных областей посредством работы своего Комитета технологии предметной области и связанных задач. Эта работа неизбежно приводит к определению важных абстракций в предметной области.

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

Этот шаг выполняется только при выполнении задачи в отправной точке.

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

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

• пользователи (по расположениям), определенные в Профайлах пользователей (в Видении), и варианты использования (в Модели вариантов использования)
• организация бизнес-данных (в Модели анализа бизнеса и Модели проекта, когда она доступна)
• требования к уровню обслуживания (в Дополнительной спецификации)
• ограничения (в Дополнительных спецификациях, таких как требования к интерфейсу унаследованных систем)

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

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

Если внимание сосредоточено на начальном архитектурном синтезе, то этот шаг выполняется, начиная с этой задачи.

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

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

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

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

Более подробная информация находится в разделе Концепция: Механизмы анализа.

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

Более подробная информация об оценке результатов этой задачи находится в разделе Справочная таблица: Документ архитектуры программного обеспечения - Замечания об архитектурном анализе.