17-10-2023
Архитектура системы — принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию[1].
Понятие архитектуры в значительной мере субъективно и имеет множество противоречивых толкований; в лучшем случае оно отображает общую точку зрения команды разработчиков на результаты проектирования системы.[2] Существует большое количество определений архитектуры. Коллекция определений, относящихся, в основном, к архитектуре программного обеспечения, собрана на сайте Института программной инженерии[en] Университета Карнеги — Меллона[3].
В настоящее время существует сильная тенденция рассматривать архитектурное и неархитектурное проектирование как различные виды деятельности; делаются попытки определить их как отдельные практики, однако эти виды проектирования в значительной мере «переплетены». Архитектурные решения в сравнении с обычными проектными решениями рассматриваются как более абстрактные, концептуальные и глобальные; они нацелены на успех всей миссии и на наиболее высокоуровневые структуры системы[4].
По мере роста сложности решаемых задач возникла необходимость структурирования систем. Однако практики нашли термин «структура» недостаточным для описания всех аспектов системы[4].
Термин «архитектура» в системной инженерии ввел профессор университета Южной Калифорнии Эберхард Речтин (англ. Eberhardt Rechtin) в начале 90-х годов XX-го века. Он считал, что по мере усложнения систем их «высокоуровневого проектирования» (или «концептуального проектирования»), как оно понималось в те годы, было недостаточно, чтобы приводить инженеров и проектировщиков к созданию точных и эффективных проектов. Он изучил архитектурные принципы в строительстве, чтобы понять, как создаются и разрабатываются сложные системы (например, здания)[6].
Речтин поясняет термин архитектура системы следующим образом:
Суть создания архитектуры — структурирование. Структурирование может означать превращение формы в функцию, извлечение порядка из хаоса, или преобразование частично сформированных идей клиента в пригодную для работы концептуальную модель[6].
Термины «архитектура» и «архитектурное проектирование» уже используются в течение приблизительно 30 лет, особенно интенсивно в программной инженерии и таких проблемных областях как ракетно-космическая отрасль[4].
Для более подробного описания принципов построения архитектуры стандарт ISO/IEC/IEEE 42010-2011 вводит следующие понятия[7].
Свод знаний по системной инженерии (SEBoK) делит архитектуру на логическую и физическую[4].
Логическая архитектура поддерживает функционирование системы на протяжении всего её жизненного цикла на логическом уровне. Она состоит из набора связанных технических концепций и принципов. Логическая архитектура представляется с помощью методов, соответствующих тематическим группам описаний, и как минимум, включает в себя функциональную архитектуру, поведенческую архитектуру и временную архитектуру.
Функциональная архитектура. Функциональная архитектура представляет собой набор функций и их подфункций, определяющих преобразования, осуществляемые системой при выполнении своего назначения.
Поведенческая архитектура. Поведенческая архитектура — соглашение о функциях и их подфункциях, а также интерфейсах (входы и выходы), которые определяют последовательность выполнения, условия для управления или потока данных, уровень производительности, необходимый для удовлетворения системных требований. Поведенческая архитектура может быть описана как совокупность взаимосвязанных сценариев, функций и/или эксплуатационных режимов.
Временная архитектура. Временная архитектура является классификацией функций системы, которая получена в соответствии с уровнем частоты её исполнения. Временная архитектура включает в себя определение синхронных и асинхронных аспектов функций. Мониторинг решений, который происходит внутри системы, следует той же временной классификации [4].
Цель проектирования физической архитектуры заключается в создании физического, конкретного решения, которое согласовано с логической архитектурой и удовлетворяет установленным системным требованиям.
После того, как логическая архитектура определена, должны быть идентифицированы конкретные физические элементы, которые поддерживают функциональные, поведенческие, и временные свойства, а также ожидаемые свойства системы, полученные из нефункциональных требований к системе.
Физическая архитектура является систематизацией физических элементов (элементов системы и физических интерфейсов), которые реализуют спроектированные решения для продукта, услуги или предприятия. Она предназначена для удовлетворения требований к системе и элементам логической архитектуры и реализуется через технологические элементы системы. Системные требования распределяются как на логическую, так и физическую архитектуру. Глобальная архитектура системы оценивается с помощью системного анализа и, после выполнения всех требований, становится основой для реализации системы[4].
Архитектура может быть зафиксирована с помощью полного архитектурного описания (АО) (см. рисунок). Стандарт ISO/IEC/IEEE 42010-2011 предписывает различать концептуальную архитектуру системы и одно из описаний данной архитектуры, являющееся конкретным продуктом или артефактом.
В сложных системах АО может разрабатываться не только для системы в целом, но и для компонентов системы. Два разных концептуальных АО могут включать группы описаний, которые будут соответствовать одному и тому же методу описания. Хотя системы, описываемые данными двумя группами описаний, будут соотноситься как целое и часть, это не пример множества групп описаний, соответствующих одному методу. Эти АО считаются отдельными, даже хотя они связаны через системы, которые они описывают[7].
Концептуальный подход определяет термины и понятия, относящиеся к содержанию и применению АО. На рисунке изображены основные понятия и их взаимосвязи. Все понятия определены в контексте архитектуры определенной системы и соответствующего архитектурного описания. Не нужно предполагать, что у системы существует лишь одна архитектура или что эта архитектура изображается лишь одним архитектурным описанием.
На рисунке прямоугольники изображают классы сущностей.
Линии, соединяющие прямоугольники, изображают связи между сущностями. Связь включает две роли (по одной в каждом направлении). Каждая роль может по желанию быть именована меткой. Роль, направленная от A к B, [помечена] ближе к B, и наоборот. Например, роли между «системой» и «средой» могут читаться: «„система“ живёт в „среде“» и «„среда“ влияет на „систему“». На рисунке роли обладают арностью 1:1, если не указано иное. Роль может обладать множественной арностью, например, роль, обозначенная как «1..*», применяется для обозначения многих, как в связях «один ко многим» или «многие к одному». Ромб (на конце линии связи) обозначает отношение части целого. Например, «группы описаний» являются частью «архитектурного описания». Эта нотация заимствована из UML.
Рассмотрим каждое составляющее концептуальной схемы подробнее. К контексте рассматриваемой схемы система распространяется на отдельные прикладные программные средства, системы в традиционном смысле, подсистемы, системы систем, продукты, семейства продукции, организации в целом и другие интересующие совокупности.
Система обитает в некоторой среде. Среда некоторой системы может влиять на данную систему. Её среда, или контекст, определяет обстановку и обстоятельства разработки, эксплуатации, политических и иных влияний на данную систему. Такая среда может включать другие системы, взаимодействующие с целевой системой, как напрямую через интерфейсы, так и косвенно иными путями. Такая среда определяет границы, определяющие предмет целевой системы по отношению к другим системам.
У каждой системы есть один или более стейкхолдеров. Каждый стейкхолдер обычно принимает участие в системе, или имеет интересы к данной системе. Интересы предполагают учёт таких аспектов системы как производительность, надежность, безопасность, распределённость и способность к эволюции.
Любая система существует для реализации в своей среде одной или более миссий.
В концептуальном подходе архитектурное описание организовано как одна или более архитектурных групп описаний.
Архитектурное описание выбирает для применения один или более подходящих методов описания. Выбор методов описания обычно основывается на соображениях и интересах заинтересованных сторон, которым адресовано это АО. Определение метода описания может возникать совместно с АО, а может быть определено отдельно. Метод описания, определенный отдельно от АО называется библиотечным методом описания.
Группа описаний может состоять из одного или более архитектурных описаний. Каждое такое архитектурное описание разрабатывается с применением установленных соответствующим ему методов архитектурного описания. Архитектурное описание может входить более чем в одну группу описаний[7].
Существует три типа группы описаний: функциональные, логические и физические. Каждая из групп предназначена для описания собственных точек зрения и соответствующего им уровня сложности[6].
Данная группа обеспечивает представление с точки зрения пользователей или операторов, которое включает продукты, относящиеся к фазам, сценариям и потокам задач операционной системы. Информационный поток может быть рассмотрен с пользовательского ракурса, также описываются и пользовательские интерфейсы. Примером продуктов, которые могут быть включены в это описание, будут функциональные данные или графики, сценарное описание (включая использование кейсов), блок-схемы задач, организационные диаграммы и схемы информационных потоков[6].
Данная группа обеспечивает представление с точки зрения руководителя или заказчика. Логическое представление включает продукты, которые определяют системные границы с её окружением и функциональные интерфейсы с внешними системами, также основные функции и поведение системы, потоки информации, внутренние и внешние наборы данных, внутренних и внешних пользователей, и внутренние функциональные интерфейсы. Примером продуктов могут быть блочные диаграммы функциональных потоков[en] (FFBD), контекстные диаграммы, N2-диаграммы[en], IDEF0-диаграммы, данные поточных диаграмм и различных стейкхолдеров — характерные продукты (в том числе бизнес-зависимые продукты)[6].
Данная группа обеспечивает представление с точки зрения проектировщиков. Включает в себя:
Продукт может включать в себя физические блок-схемы на довольно высоком уровне детализации, топологии базы данных, интерфейс управления документами и стандарты. Все из трёх типов групп должны присутствовать в каждом описании архитектуры[6].
Архитектурные описания в ходе жизненного цикла могут различно применяться всеми стейкхолдерами. Такие применения включают, но не ограничиваются, следующим:
Архитектура системы.
