Архитектурные методы

Итеративный и инкрементный подход

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

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

Определить цель архитектуры

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

Этот шаг включает в себя следующие действия -

Определите свои архитектурные цели с самого начала.
Определите потребителя нашей архитектуры.
Определите ограничения.

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

Ключевые сценарии

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

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

Обзор приложения

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

Определить тип приложения

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

Определить ограничения развертывания

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

Определите важные стили архитектурного дизайна

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

Определите соответствующие технологии

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

Ключевые проблемы или ключевые горячие точки

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

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

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

Возможные решения

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

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

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

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

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

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

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

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

Метод анализа архитектуры программного обеспечения (SAAM)

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

Метод анализа компромиссов в архитектуре (ATAM)

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

Обзор активного дизайна (ADR)

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

Активные обзоры промежуточных дизайнов (ARID)

Он сочетает в себе аспект ADR анализа незавершенной архитектуры с акцентом на наборе вопросов, а также подходы ATAM и SAAM анализа на основе сценариев, ориентированные на атрибуты качества.

Метод анализа затрат и выгод (CBAM)

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

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

Он оценивает модифицируемость архитектуры для бизнес-информационных систем (BIS).

Метод оценки семейной архитектуры (FAAM)

Он оценивает архитектуры семейств информационных систем на предмет взаимодействия и расширяемости.

Сообщение архитектурного дизайна

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

Существует несколько следующих хорошо известных методов описания архитектуры другим:

Модель 4 + 1

Этот подход использует пять представлений полной архитектуры. Среди них четыре вида (logical view, то process view, то physical view, и development view) описывают архитектуру с разных подходов. Пятый вид показывает сценарии и варианты использования программного обеспечения. Это позволяет заинтересованным сторонам видеть особенности архитектуры, которые их конкретно интересуют.

Язык описания архитектуры (ADL)

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

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

Гибкое моделирование

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

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

IEEE 1471

IEEE 1471 - это краткое название стандарта, официально известного как ANSI / IEEE 1471-2000, «Рекомендуемая практика для описания архитектуры программно-интенсивных систем». IEEE 1471 расширяет содержание описания архитектуры, в частности, придавая конкретное значение контексту, представлениям и точкам зрения.

Единый язык моделирования (UML)

Этот подход представляет собой три представления модели системы. Вfunctional requirements view (функциональные требования системы с точки зрения пользователя, включая варианты использования); the static structural view(объекты, атрибуты, отношения и операции, включая диаграммы классов); иdynamic behavior view (взаимодействие между объектами и изменение внутреннего состояния объектов, включая диаграммы последовательности, активности и состояний).