Создание архитектуры решения

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

В этом разделе

• Создание элементов секционирования альтернативной архитектуры

• Развертывание системной архитектуры разработки

• Создание экспериментов

• Оценка альтернатив

• Выбор архитектуры

• Разработка модели производительности

Создание элементов секционирования альтернативной архитектуры

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

Создание схемы приложения

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

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

Определение критериев оценки

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

Выбор группы вероятных требований

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

Выбор группы вероятных сценариев

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

Сокращение группы кандидатов

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

Создание критериев секционирования

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

Системная архитектура разработки и развертывание

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

Создание системной модели

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

Системные схемы можно представить в Visual Studio одним из следующих способов.

• Схема вариантов использования. Основные пользовательские сценарии представляются как варианты использований, а крупные компоненты системы — как подсистемы. Каждый вариант использования можно поместить в соответствующую подсистему. Дополнительные сведения см. в разделе UML-схемы вариантов использования: правила работы.

• UML-схемы компонентов. Эти схемы позволяют показать каналы связи между компонентами, а не только зависимости. Кроме того, можно создать схемы классов, чтобы описать типы, видимые в интерфейсах компонентов, а также схемы последовательностей, чтобы показать их взаимодействие. Дополнительные сведения см. в разделах UML-схемы компонентов: правила работы, UML-схемы классов: правила работы и UML-схемы последовательностей: правила работы.

• Схемы слоев. Схема слоев описывает блоковую структуру приложения. На ней отображаются только компоненты и зависимости между ними. Одним из преимуществ этого типа схем является возможность проверки кода и зависимостей относительно схемы после создания кода. Дополнительные сведения см. в разделе Схемы слоев: рекомендации.

Для каждой подсистемы можно создать пакет, более подробно описывающий типы и поведение подсистемы. Дополнительные сведения см. в разделе Определение пакетов и пространств имен.

Создание экспериментов

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

Изучение рисков

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

Планирование подхода

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

Построение и запуск экспериментов

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

Оценка альтернатив

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

Создание служебного дерева

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

Создание оценочной матрицы

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

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

При этом необходимо учитывать следующие факторы.

• Затраты на разработку. Решение реализуется легко или сложно? Каково его влияние на другие области?

• Операционные затраты. Во время выполнения это решение работает без проблем или отрицательно сказывается на удобстве работы, производительности системы и т. д.?

• Риск. Это решение хорошо подходит для данного сценария или вероятны непредвиденные затраты? Это решение может негативно сказаться на возможностях команды реализовывать дополнительные требования в будущем?

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

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

Отправьте заполненную оценочную матрицу в портал проекта.

Выбор архитектуры

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

Подготовка к анализу

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

Анализ системной архитектуры и архитектуры развертывания

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

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

Создание эталонного решения

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

Разработка модели производительности

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

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

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

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

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

Разработка модели угроз.

Дополнительные сведения см. на странице Security Developer Center веб-сайта Майкрософт.