Архитектурная модель программного обеспечения

Архитектурная модель программного обеспечения (англ. architectural model) — это совокупность диаграмм, отражающих статические или динамические (поведенческие) характеристики разрабатываемого программного обеспечения^[1][2][3]. Такие диаграммы отображают различные точки зрения на систему в выбранных областях анализа. Для их создания применяются существующие стандарты, основная задача которых — продемонстрировать конкретный набор компромиссов, заключённых в структуре и проектировании системы или экосистемы. Архитектор программного обеспечения использует архитектурные модели для облегчения коммуникации и получения отзывов коллег.

Ключевые элементы архитектурной модели программного обеспечения включают:

• Информативность: Для соответствующей точки зрения должна быть представлена достаточная информация для подробного описания рассматриваемой области. Информация не должна быть недостаточной или неопределённой. Главная цель — уменьшить недопонимание, а не способствовать ему. См. ниже раздел о «главном аспекте».
• Строгость: Архитектор использует определённую методологию для построения данной модели, и итоговая модель выглядит определённым образом. Проверкой строгости служит правило: если два архитектора из разных городов описывают одно и то же, их диаграммы будут почти идентичны (с возможным исключением только визуального расположения элементов).
• Диаграмма: В целом, модель — это любая абстракция, упрощающая предмет ради отражения определённой точки зрения. В данном контексте под архитектурными моделями понимаются только такие описания, которые представлены в виде диаграмм.
• Стандарты: Стандарты эффективны, когда ими пользуются все. Это существенно повышает уровень понимания по сравнению с ситуацией, когда каждая диаграмма строится по собственным правилам. Наиболее распространённый стандарт — Unified Modeling Language, UML.
• Главный аспект: Легко перегрузить диаграмму, пытаясь учесть разные потребности сразу. Лучше создавать отдельные диаграммы для каждой точки зрения, чем строить одну перегруженную. Аналогия: при проектировании зданий архитектор предоставляет множество различных схем (план перекрытий, электрики, отопления, водопровода и т. д.), каждая из которых содержит только необходимую узкому специалисту информацию.
• Иллюстрация: Модель создаётся ради общения и получения обратной связи. Диаграмма должна отвечать на конкретный вопрос и передаваться другим для:
  1. проверки согласия;
  2. направления их работы.
• Правило пальца: Формулируйте то, что хотите донести и на чью работу намерены повлиять.
• Набор компромиссов: Методология ATAM, Architecture Tradeoff Analysis Method описывает процесс экспертной оценки целесообразности архитектурных решений. Исходный принцип: не существует универсального проектного решения для всех случаев — почти всегда необходима адаптация под конкретные бизнес-требования. Архитектор должен осознанно продемонстрировать такие компромиссы в создаваемых диаграммах и быть готовым отметить их словесно.
• Компромиссы в структуре и проектировании: Например, компонент не является компромиссом как таковым, а компромиссы — это фундаментальные принципы, лежащие в основе проектных моделей. Для обоснования определённого технического выбора диаграмму можно использовать как иллюстрацию своей позиции.
• Система или экосистема: Моделирование архитектуры возможно на разных уровнях абстракции: как для отдельного приложения (с описанием компонентов и взаимодействий), так и для совокупности приложений, реализующих бизнес-процесс. При этом моделирование уровня компонентов и классов — задача скорее инженерного проектирования, чем архитектуры.