Это итеративный и поэтапный подход, состоящий из пяти основных этапов, который помогает генерировать подходящие решения. Это возможное решение может быть дополнительно улучшено путем повторения этих шагов и, наконец, создания архитектуры, которая лучше всего подходит для нашего приложения. В конце процесса мы можем проверить и сообщить нашу архитектуру всем заинтересованным сторонам.
Это только один из возможных подходов. Есть много других более формальных подходов, которые определяют, анализируют и передают вашу архитектуру.
Определить архитектурную цель
Определите цель архитектуры, которая формирует архитектуру и процесс проектирования. Безупречные и определенные цели подчеркивают архитектуру, решают правильные проблемы в дизайне и помогают определить, когда текущая фаза завершена, и готова перейти к следующей фазе.
Этот шаг включает в себя следующие действия —
- Определите ваши архитектурные цели с самого начала.
- Определите потребителя нашей архитектуры.
- Определите ограничения.
Примеры действий архитектуры включают в себя создание прототипа для получения обратной связи по пользовательскому интерфейсу обработки заказов для веб-приложения, создание приложения для отслеживания заказов клиентов, а также разработку архитектуры аутентификации и авторизации для приложения для выполнения проверки безопасности.
Ключевые сценарии
Этот шаг делает упор на дизайн, который имеет наибольшее значение. Сценарий — это обширное и охватывающее описание взаимодействия пользователя с системой.
Ключевые сценарии — это те сценарии, которые считаются наиболее важными для успеха вашего приложения. Это помогает принимать решения об архитектуре. Цель состоит в том, чтобы достичь баланса между потребностями пользователя, бизнеса и системы. Например, аутентификация пользователя является ключевым сценарием, потому что они представляют собой пересечение атрибута качества (безопасности) с важной функциональностью (как пользователь входит в вашу систему).
Обзор приложения
Создайте обзор приложения, что делает архитектуру более удобной, связывая ее с реальными ограничениями и решениями. Он состоит из следующих действий —
Определить тип приложения
Определите тип приложения, будь то мобильное приложение, многофункциональный клиент, многофункциональное интернет-приложение, служба, веб-приложение или некоторая комбинация этих типов.
Определить ограничения развертывания
Выберите подходящую топологию развертывания и разрешите конфликты между приложением и целевой инфраструктурой.
Определите важные стили дизайна архитектуры
Определите важные стили архитектуры, такие как клиент / сервер, многоуровневая структура, шина сообщений, проектирование на основе домена и т. Д., Чтобы улучшить разбиение и способствовать повторному использованию проекта, предоставляя решения для часто повторяющихся проблем. Приложения часто используют комбинацию стилей.
Определите соответствующие технологии
Определите соответствующие технологии, учитывая тип разрабатываемого нами приложения, наши предпочтительные варианты топологии развертывания приложений и архитектурные стили. Выбор технологий также будет зависеть от политики организации, ограничений инфраструктуры, навыков работы с ресурсами и так далее.
Ключевые проблемы или ключевые точки
При разработке приложения горячие точки — это зоны, где чаще всего допускаются ошибки. Определите ключевые проблемы на основе качественных признаков и сквозных проблем. Потенциальные проблемы включают появление новых технологий и критических требований бизнеса.
Атрибуты качества — это общие характеристики вашей архитектуры, которые влияют на поведение во время выполнения, проектирование системы и взаимодействие с пользователем. Пересекающиеся проблемы — это особенности нашего дизайна, которые могут применяться ко всем слоям, компонентам и уровням.
Это также области, в которых наиболее часто допускаются ошибки проектирования. Примерами сквозных проблем являются аутентификация и авторизация, связь, управление конфигурацией, управление и проверка исключений и т. Д.
Решения для кандидатов
После определения ключевых горячих точек создайте исходную базовую архитектуру или сначала высокоуровневый дизайн, а затем начните заполнять детали, чтобы сгенерировать подходящую архитектуру.
Кандидатская архитектура включает в себя тип приложения, архитектуру развертывания, архитектурный стиль, выбор технологий, атрибуты качества и общие проблемы. Если архитектура-кандидат является улучшением, она может стать основой, на которой можно создавать и тестировать новые архитектуры-кандидаты.
Прежде чем итеративно следовать циклу и улучшать проект, проверяйте возможный дизайн решения на соответствие ключевым сценариям и требованиям, которые уже определены.
Мы можем использовать архитектурные пики, чтобы обнаружить определенные области дизайна или подтвердить новые концепции. Архитектурные пики являются прототипом проекта, который определяет выполнимость конкретного пути проектирования, снижает риск и быстро определяет жизнеспособность различных подходов. Протестируйте архитектурные всплески по ключевым сценариям и горячим точкам.
Обзор архитектуры
Обзор архитектуры является наиболее важной задачей, чтобы снизить стоимость ошибок и как можно раньше найти и исправить архитектурные проблемы. Это хорошо зарекомендовавший себя экономически эффективный способ снижения стоимости проекта и шансов на провал проекта.
-
Часто пересматривайте архитектуру на основных этапах проекта и в ответ на другие значительные архитектурные изменения.
-
Основная цель обзора архитектуры состоит в том, чтобы определить выполнимость базовых и возможных архитектур, которые правильно проверяют архитектуру.
-
Связывает функциональные требования и атрибуты качества с предлагаемым техническим решением. Это также помогает выявить проблемы и выявить области для улучшения
Часто пересматривайте архитектуру на основных этапах проекта и в ответ на другие значительные архитектурные изменения.
Основная цель обзора архитектуры состоит в том, чтобы определить выполнимость базовых и возможных архитектур, которые правильно проверяют архитектуру.
Связывает функциональные требования и атрибуты качества с предлагаемым техническим решением. Это также помогает выявить проблемы и выявить области для улучшения
Оценки на основе сценариев являются доминирующим методом для анализа проекта архитектуры, который фокусируется на сценариях, наиболее важных с точки зрения бизнеса и оказывающих наибольшее влияние на архитектуру. Далее следуют распространенные методологии анализа —
Метод анализа архитектуры программного обеспечения (SAAM)
Первоначально он был разработан для оценки модифицируемости, но позже был расширен для анализа архитектуры в отношении атрибутов качества.
Метод анализа компромиссов в архитектуре (ATAM)
Это отточенная и улучшенная версия SAAM, в которой рассматриваются архитектурные решения с точки зрения требований к качественным атрибутам и того, насколько они соответствуют конкретным целям качества.
Активный дизайн обзора (ADR)
Он лучше всего подходит для незавершенных или незавершенных архитектур, в которых больше внимания уделяется набору проблем или отдельным частям архитектуры за раз, чем выполнению общего обзора.
Активные обзоры Intermediate Designs (ARID)
Он сочетает в себе аспект ADR при анализе текущей архитектуры с акцентом на ряд проблем, а подход ATAM и SAAM к анализу на основе сценариев фокусируется на атрибутах качества.
Метод анализа затрат и выгод (CBAM)
Основное внимание уделяется анализу затрат, выгод и сроков выполнения архитектурных решений.
Анализ модифицируемости на уровне архитектуры (ALMA)
Оценивает модифицируемость архитектуры для бизнес-информационных систем (BIS).
Метод оценки семейной архитектуры (FAAM)
Он оценивает архитектуры семейства информационных систем на предмет взаимодействия и расширяемости.
Общение архитектурного дизайна
После завершения проектирования архитектуры мы должны сообщить о проекте другим заинтересованным сторонам, в том числе команде разработчиков, системным администраторам, операторам, владельцам бизнеса и другим заинтересованным сторонам.
Существует несколько следующих известных методов описания архитектуры для других:
Модель 4 + 1
Этот подход использует пять представлений о полной архитектуре. Среди них четыре представления ( логическое представление, представление процесса, физическое представление и представление разработки ) описывают архитектуру с разных подходов. В пятом представлении показаны сценарии и варианты использования программного обеспечения. Это позволяет заинтересованным сторонам увидеть особенности архитектуры, которые их особенно интересуют.
Язык описания архитектуры (ADL)
Этот подход используется для описания архитектуры программного обеспечения до внедрения системы. В нем рассматриваются следующие проблемы — поведение, протокол и соединитель.
Основным преимуществом ADL является то, что мы можем проанализировать архитектуру на предмет полноты, согласованности, неоднозначности и производительности, прежде чем формально начать использовать проект.
Agile Modeling
Этот подход следует концепции «контент важнее представления». Он гарантирует, что созданные модели просты и понятны, достаточно точны, детализированы и последовательны.
Гибкие типовые документы нацелены на конкретного клиента (ов) и выполняют рабочие усилия этого клиента. Простота документа обеспечивает активное участие заинтересованных сторон в моделировании артефакта.
IEEE 1471
IEEE 1471 — это краткое название стандарта, официально известного как ANSI / IEEE 1471-2000, «Рекомендуемая практика для описания архитектуры программно-интенсивных систем». IEEE 1471 расширяет содержание описания архитектуры, в частности, придавая конкретное значение контексту , взгляды и точки зрения.
Унифицированный язык моделирования (UML)
Этот подход представляет три представления модели системы. Представление функциональных требований (функциональные требования системы с точки зрения пользователя, включая варианты использования); статическое структурное представление (объекты, атрибуты, отношения и операции, включая диаграммы классов); и динамическое представление поведения (взаимодействие между объектами и изменения внутреннего состояния объектов, включая диаграммы последовательности, активности и состояния).