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

Примечание – Рисунок 1 использует условности для класса диаграмм, определенные в ИСО/МЭК 19501.

Рисунок 1 — Контекст описания архитектуры

Термин «система» использован в настоящем стандарте для обращения к объектам (сущностям), архитектура которых рассматривается. Термин предназначен для того, чтобы охватить (но не ограничивается этим) объекты (сущности) в пределах следующих областей:

• системы, как описано в ИСО/МЭК 15288: «системы, которые созданы человеком и могут быть сконфигурированы из одного или более следующих компонентов: аппаратных и программных средств, данных, людей, процессов (например, процессов для обеспечения услуг пользователям), процедур (например, инструкций оператора), оборудования, материалов и естественно образующихся сущностей»;
• программных продуктов и услуг, как описано в ИСО/МЭК 12207;
• программных систем, как описано в IEEE 1471:2000: «любая система, где программные средства оказывают существенное влияние на проект, конструкцию, развертывание и развитие системы в целом», чтобы охватить «отдельные приложения, системы в традиционном смысле, подсистемы, системы систем, производственные линии, семейства продукции, целые предприятия и другие объединения интересов».

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

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

Заинтересованные стороны какой–либо системы – это стороны, имеющие интерес в этой системе. Интересы заинтересованных сторон выражены как польза или проблема (см. 4.2.3). Заинтересованные стороны формируют для системы различные цели. Цели являются одним из видов выражения интересов.

Примечание — Термин «цель», применяемый в настоящем стандарте, происходит из его определения в ИСО/МЭК 15288:2008, где система — это комбинация взаимодействующих элементов, организованных для достижения одной или нескольких поставленных целей.

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

Примечание — В настоящем стандарте окружающая среда системы ограничена и понимаема через определение и анализ заинтересованных сторон системы и их интересов (см. 4.2.3).

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

• системным компонентам или элементам;
• тому, как системные элементы устроены или взаимосвязаны;
• принципам организации системы или проекта;
• принципам, управляющим развитием системы в ее жизненном цикле.

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

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

[из 4.2.1 Контекст описания архитектуры ГОСТ Р 57100–2016]

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

Примеры – Примерами интересов в терминах настоящего стандарта являются функциональность, выполнимость, применимость, цели системы, характеристики системы, свойства системы, известные ограничения, структура, поведение, функционирование, использование ресурсов, надежность, безопасность, информационное обеспечение, сложность, развиваемость, открытость, параллелизм, автономность, стоимость, расписание, качество услуг, гибкость, динамичность, модифицируемость, модульность, управление, межпроцессная связь, взаимоблокировка, изменение состояния, интеграция подсистем, доступность данных, частная жизнь, соответствие требованиям регуляторов, гарантии, деловые цели и стратегии, опыт заказчика, сопровождаемость, приемлемость и утилизируемость. Прозрачность распределения, описанная в эталонной модели открытой распределенной обработки [ИСО/МЭК 10746–1], является интересом в терминах этого стандарта. Свойства программных средств, определенные в серии стандартов по оценке качества SQUARE [см. ИСО/МЭК 25010:2011, подраздел 4.2], определяют интересы в терминах настоящего стандарта [из 4.2.3 Заинтересованные стороны и интересы ГОСТ Р 57100–2016]

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

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

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

[из 4.2.5 Модели архитектуры ГОСТ Р 57100–2016]

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

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

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

На рисунке 4 отображены понятия, имеющие отношение к решениям архитектуры и их обоснованию.

Примечание — Рисунок использует условности для класса диаграмм, определенные в ИСО/МЭК 19501.

Рисунок 4 — Концептуальная модель решений архитектуры и обоснование

Примечание — Требования, необходимые для того, чтобы охватить решения и обоснование в пределах описания архитектуры, определены в 5.8.

[из 4.2.7 Архитектурные решения и обоснование ГОСТ Р 57100–2016]