ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

АЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

<ш> ГОСТ Р 57100— 2016/ISO/IEC/ IEEE 42010:2011

---

Системная и программная инженерия ОПИСАНИЕ АРХИТЕКТУРЫ

(ISO/IEC/IEEE 42010:2011, ЮТ)

Предисловие

1    ПОДГОТОВЛЕН Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 сентября 2016 г. № 1190-ст

4    Настоящий стандарт идентичен международному стандарту ISO/IEC/IEEE 42010:2011 «Системная и программная инженерия. Описание архитектуры» (ISO/IEC/IEEE 42010:2011 «Systems and software engineering — Architecture description», IDT)

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ. 2016

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

ГОСТ P 57100—2016

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

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

-    формулированием требований существования элементов описания архитектуры:

-    изменением свойств элементов описания архитектуры;

-    подключением анализа компромиссов для некоторых элементов описания архитектуры, включая иные решения и интересы, в которых имеют (могут иметь) место изменения;

-    порождением новых интересов.

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

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

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

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

4.3 Процесс архитектуризации в жизненном цикле

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

7

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

Настоящий стандарт не зависит, не предполагает и не предписывает какого-либо особенного жизненного цикла.

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

1)    любой процесс из ИСО/МЭК 12207 или ИСО/МЭК 15288 может быть расценен как выполнение по всему жизненному циклу;

2)    использование «архитектурного проектирования» в ИСО/МЭК 12207 и ИСО/МЭК 15288 является более узким, чем понятие «архитектуризация» в настоящем стандарте.

4.4 Применения описаний архитектуры

У описаний архитектуры существует много применений со стороны различных заинтересованных сторон по всему жизненному циклу системы. Описания архитектуры применяются, но не ограничиваются этим:

-    в качестве основы системного проекта системы и действий по разработке;

-    в качестве основы анализа и оценки альтернативных реализаций архитектуры;

-    в качестве документации в разработке и сопровождении;

-    для обеспечения документирования существенных аспектов системы, например таких, как:

-    намеченное использование и окружающая среда;

-    принципы, предположения и ограничения для проведения будущих изменений;

-    моменты для обеспечения гибкости или ограничений системы относительно будущих изменений;

-    решения архитектуры, их обоснования и последствия;

-    в качестве входов к автоматизированным инструментариям для моделирования, системной имитации и анализа;

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

-    для обеспечения связи между сторонами, вовлеченными в разработку, производство, развертывание, функционирование и сопровождение системы;

-    в качестве основы для подготовки документов приобретения (например таких, как запросы о предложении и описание работы);

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

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

-    при планировании передачи от устаревшей архитектуры к новой;

-    в качестве руководства к эксплуатационной и инфраструктурной поддержке и управлению конфигурацией;

-    для поддержки системного планирования и действий, связанных со сроками и бюджетом;

-для установления критериев при сертификации реализаций на соответствие архитектуре;

-    в качестве механизма согласования с внешней и проектной политикой и/или внутренней политикой организации (например, юридические основания, перекрывающие архитектурные принципы);

-    в качестве основы для ревизий, анализа и оценки системы в ее жизненном цикле;

-    в качестве основы анализа и оценки альтернативных архитектур;

-    при распространении изученных уроков и повторном использовании архитектурного знания через точки зрения, образцы и стили;

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

Примечание — В приложении С рассмотрено использование описаний архитектуры в контексте других стандартов.

8

ГОСТ P 57100—2016

4.5 Структуры архитектуры и языки описания архитектуры

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

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

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

Примечание — Структуры архитектуры часто охватывают условия для описания архитектуры и дополнительные практики процесса архитектуризации.

Примеры — Примерами структуры архитектуры в терминах настоящего стандарта являются: структура архитектуры Захмана для информационных систем [44], структура архитектуры британского Министерства обороны [27], структура архитектуры открытых групп (TOGAF) [41], модель представления Крухтона «4 ♦ 1» [23], четыре метода представлений Симонса [10], эталонная модель для открытой распределенной обработки (RM-ODP) [ИСО/МЭК10746] и обобщенная эталонная архитектура предприятия (GERA) [ISO 15704].

На рисунке 5 отображено содержание структуры архитектуры.

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

Рисунок 5 — Концептуальная модель структуры архитектуры

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

Язык описания архитектуры является некоторой формой выражения для применения в описаниях архитектуры.

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

9

автоматизированными инструментариями для сопровождения создания, использования и анализа его моделей.

Приборы — Примерами языка описания архитектуры о терминах настоящего стандарта являются Rapide [25], Wright [43], SysML [31], ArchiMate [40] и точка зрения на языки со стороны эталонной модели открытой распределенной обработки (RM-ODP) [ИСО/МЭК 10746].

На рисунке 6 отображено содержание языка описания архитектуры.

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

Рисунок 6 — Концептуальная модель языка описания архитектуры

Примечание — Требования к языку описания архитектуры определены в 6.3.

5 Описания архитектуры

5.1    Введение

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

-    определение описания архитектуры и обзорную информацию (см. 5.2);

-    определение заинтересованных сторон системы и их интересов (см. 5.3);

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

(см. 5.4);

-    представления архитектуры и архитектурных моделей для каждой используемой точки зрения на архитектуру (см. 5.5 и 5.6);

-    применимые правила связей в описании архитектуры, связи и регистрацию известных несогласованностей в требуемом содержании описаний архитектуры (см. 5.7);

-    выполненные обоснования для решений архитектуры (см. 5.8).

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

Примечания

1    Настоящий стандарт не определяет формат для описаний архитектуры.

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

5.2    Определение и обзор описания архитектуры

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

Детальное содержание идентификации и дополнительных информационных объектов должно быть задано организацией и/или проектом.

Ю

ГОСТ P 57100—2016

Примечание — Примерами идентификации и дополнительной информации в описании архитектуры являются дата выпуска и статус, авторы, рецензенты, утверждающие стороны, выпускающая организация; история изменений; резюме; область применения; контекст; глоссарий; информация контроля за версией; информация по управлению конфигурацией и ссылки. (См. (ИСО/МЭК 15289] или технический отчет [ИСО/МЭК 15504-6:2008. В. 1]).

Должны быть включены результаты любых оценок архитектуры или ее описания.

5.3    Определение заинтересованных сторон и интересов

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

В описании архитектуры должны быть учтены и, если применимо, определены следующие заинтересованные стороны:

-    пользователи системы:

-    операторы системы:

-    приобретающие стороны системы:

-    владельцы системы;

-    поставщики системы;

-    разработчики системы:

-    строители системы;

-    сопровождающие стороны системы.

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

В описании архитектуры должны быть учтены и, если применимо, определены следующие интересы:

-    цели системы;

-    приемлемость архитектуры для достижения целей системы;

-    выполнимость конструирования и развертывания системы;

-    потенциальные риски и воздействия системы на ее заинтересованные стороны на всем ее жизненном цикле;

-    сопровождаемость и развиваемость системы.

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

Примечания

1    В общем случае взаимоувязывание интересов с заинтересованными сторонами представляет собой соотношение «многие ко многим*.

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

5.4    Точки зрения на архитектуру

Описание архитектуры должно включать каждую используемую точку зрения на архитектуру.

Каждая учтенная точка зрения на архитектуру должна быть определена в соответствии с условиями раздела 7.

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

Примечания

1    Настоящий стандарт не требует использования каких-либо особенных точек зрения.

2    Приложения 8 и С содержат дополнительную информацию, имеющую отношение к точкам зрения на архитектуру.

5.5    Архитектурные представления

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

Каждое архитектурное представление должно придерживаться соглашений его главной точки зрения на архитектуру.

Каждое архитектурное представление должно включать:

a)    определение и дополнительную информацию, заданную организацией и/или проектом:

b)    определение главной точки зрения;

11

c)    архитектурные модели, которые обращаются ко всем интересам, структурируемых главной точкой зрения, и охватывают с той точки зрения систему в целом;

d)    регистрацию любых известных источников в пределах представления относительно его главной точки зрения.

Примечания

1    См. 5.2 для примеров определения и дополнительную информацию в перечислении а).

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

3    В перечислении d) «известные источники» включают нерешенные проблемы, исключения и отклонения от соглашений. Открытые источники могут привести к принятию решений. Исключения и отклонения могут быть зарегистрированы как результаты решения и его обоснование в 5.8.

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

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

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

Архитектурное представление должно быть составлено из одной или нескольких архитектурных моделей.

Каждая архитектурная модель должна включать идентификацию версии, как это задается организацией и/или проектом.

Каждая архитектурная модель должна определить свой основной вид модели и придерживаться соглашений этого вида (см. 5.4).

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

Примечания

1    Распределение архитектурных моделей между представлениями архитектуры разрешает описанию архитектуры структурировать различные связанные интересы без избыточности или повторения той же самой информации во множественных представлениях и уменьшает возможности для несогласованности. Распределение архитектурных моделей также разрешает обьектно-ориен тированный стиль описания архитектуры: архитектурные модели, распределенные по архитектурному представлению, могут использоваться для выражения архитектурных перспектив (см. [36]): архитектурные модели, распределенные в продолах архитектурного представления. могут использоваться для выражения архитектурных структур (см. [34]). Архитектурные модели могут использоваться как «контейнеры» для применения архитектурных образцов (см. [4]) или стилей архитектуры, чтобы выражать основные схемы (например, послойные, трехьярусные. децентрализованные схемы, схема «модель — представление — контроллер») в пределах представлений архитектуры.

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

5.7    Архитектурные отношения

5.7.1    Согласованность в пределах описания архитектуры

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

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

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

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

5.7.2    Связи

Каждая связь в описании архитектуры должна быть определена и описать участие элементов описания архитектуры.

12

ГОСТ P 57100—2016

Содержание

1    Область применения............................................1

2    Соответствие................................................1

3    Термины и определения..........................................1

4    Концептуальные основы..........................................2

4.1    Введение................................................2

4.2    Концептуальная модель описания архитектуры...........................2

4.3    Процесс архитектуризации в жизненном цикле...........................7

4.4    Применения описаний архитектуры.................................8

4.5    Структуры архитектуры и языки описания архитектуры......................9

5    Описания архитектуры..........................................10

5.1    Введение...............................................10

5.2    Определение и обзор описания архитектуры............................10

5.3    Определение заинтересованных сторон и интересов.......................11

5.4    Точки зрения на архитектуру.....................................11

5.5    Архитектурные представления...................................11

5.6    Архитектурные модели........................................12

5.7    Архитектурные отношения......................................12

5.8    Обоснование архитектуры......................................13

6    Структуры архитектуры и языки описания архитектуры........................14

6.1    Структуры архитектуры.......................................14

6.2    Соблюдение описания архитектуры относительно структуры..................14

6.3    Языки описания архитектуры....................................15

7    Точки зрения на архитектуру.......................................15

Приложение А (справочное) Примечания к терминам и понятиям...................16

Приложение В (справочное) Руководство к точкам зрения на архитектуру...............23

Приложение С (справочное) Взаимосвязь с другими стандартами...................26

Библиография................................................29

III

ГОСТ P 57100—2016

Введение

ИСО/МЭК/ИИЭР 42010 подготовлен Подкомитетом 7 «Системная и программная инженерия» совместного Технического комитета ИСО/МЭК СТК 1 «Информационные технологии» в сотрудничестве с комитетом по стандартам системной и программной инженерии Компьютерного общества ИИЭР в соответствии с соглашением о партнерском сотрудничестве в организации разработки стандартов между ИСО и ИИЭР.

Этот первый выпуск ИСО/МЭК/ИИЭР 42010 отменяет и заменяет ИСО/МЭК 42010:2007, который был технически пересмотрен.

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

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

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

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

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

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

Для улучшения восприятия онтологии, ее понятий и принципов настоящий стандарт рекомендует пользователям руководствоваться положениями раздела 4.

IV

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Системная и программная инженерия ОПИСАНИЕ АРХИТЕКТУРЫ

Systems and software engineering. Architecture description

Дата введения — 2017—09—01

1    Область применения

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

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

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

2    Соответствие

Требования настоящего стандарта приведены в разделах 5, 6, 7. Существуют четыре ситуации, при которых могут быть сделаны заявления о соответствии условиям настоящего стандарта:

1)    соответствие заявлено для описания архитектуры, заявление о соответствии должно продемонстрировать. что описание архитектуры отвечает требованиям, перечисленным в разделе 5:

2)    соответствие заявлено для точки зрения на архитектуру, заявление о соответствии должно продемонстрировать, что точка зрения на архитектуру отвечает требованиям, перечисленным в разделе 7;

3)    соответствие заявлено для структуры архитектуры, заявление о соответствии должно продемонстрировать. что структура архитектуры отвечает требованиям, перечисленным в 6.1;

4)    соответствие заявлено для языка описания архитектуры, заявление о соответствии должно продемонстрировать, что язык описания архитектуры отвечает требованиям, перечисленным в 6.3.

Требования настоящего стандарта выражены глаголом «должен». Рекомендации выражены глаголом «следует». Разрешения отмечены с помощью глагола «может». В случае рассогласований между нормативными числами и текстом приоритет имеет текст. Следует отмечать любые очевидные рассогласования.

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

3    Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

3.1 процесс архитектуризации (architecting): Процесс понимания, определения, выражения, документирования, взаимодействия, соответствующей сертификации при реализации, сопровождении и улучшении архитектуры в жизненном цикле системы.

Издание официальное

Примечание — Процесс архитектуризации имеет место в контексте организации (лицо или группа лиц и необходимых средств с распределением обязанностей, полномочий и взаимоотношений) и/или проекта (усилия с определенными датами начала и окончания, предпринятые для создания продукции или услуг в соответствии с заданными ресурсами и требованиями) [ИСО/МЭК 12207. ИСО/МЭК 15288).

3.2    архитектура (системы) (architecture): Основные понятия или свойства системы в окружающей среде, воплощенной в ее элементах, отношениях и конкретных принципах ее проекта и развития.

3.3    описание архитектуры (architecture description): Рабочий продукт, используемый для выражения архитектуры.

3.4    структура архитектуры (architecture framework): Условности, принципы и практики для описания архитектур, установленные в пределах заданной области применения и/или объединения заинтересованных сторон.

Примеры

1    Обобщенная стандартная архитектура предприятия и методологии (GERAM) [ИС015704] является некоторой структурой архитектуры.

2    Эталонная модель открытой распределенной обработки (RM-ODP) [ИСО/МЭК 10746] является некоторой структурой архитектуры.

3.5    архитектурное представление (architecture view): Рабочий продукт, выражающий архитектуру некоторой системы с точки зрения определенных системных интересов.

3.6    точка зрения на архитектуру (architecture viewpoint): Рабочий продукт, устанавливающий условности конструирования, интерпретации и использования архитектурного представления для структуризации определенных системных интересов.

3.7    интерес (системы) (concern): Польза или проблемы в системе, относящиеся к одной или нескольким заинтересованным сторонам.

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

3.8    окружающая среда (системы) (environment): Контекст, определяющий параметры и обстоятельства всех воздействий на систему.

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

3.9    вид модели (model kind): Условности для типа моделирования.

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

3.10    заинтересованная сторона, правообладатель (stakeholder): Индивидуум, команда, организация или их группы, имеющие интерес в системе.

4 Концептуальные основы

4.1    Введение

В настоящем разделе введены концептуальные основы описания архитектуры, включающие концептуальную модель описания архитектуры (см. 4.2), роль процесса архитектуризации в жизненном цикле (см. 4.3), использование описаний архитектуры (см. 4.4), языки структур и описания архитектуры (см. 4.5). Понятия, введенные в настоящем разделе, используются в разделах 5—7 для выражения требований.

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

4.2    Концептуальная модель описания архитектуры

4.2.1 Контекст описания архитектуры

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

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

2

ГОСТ P 57100—2016

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

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

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

-    программных продуктов и услуг, как описано в ИСО/МЭК 12207;

-    программных систем, как описано в ИИЭР 1471:2000: «любая система, где программные средства оказывают существенное влияние на проект, конструкцию, развертывание и развитие системы в целом», чтобы охватить «отдельные приложения, системы в традиционном смысле, подсистемы, системы систем, производственные линии, семейства продукции, целые предприятия и другие объединения интересов».

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

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

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

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

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

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

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

3

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

-    системным компонентам или элементам;

-    тому, как системные элементы устроены или взаимосвязаны:

-    принципам организации системы или проекта;

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

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

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

4.2.2 Архитектура и описания архитектуры

Описания архитектуры — это рабочие продукты процесса архитектуризации систем и программных средств.

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

Рисунок 2 — Концептуальная модель описания архитектуры

4

ГОСТ P 57100—2016

В настоящем стандарте термин «рассматриваемая система»(или просто, «система») относится к системе, архитектура которой находится на рассмотрении в подготовке описания архитектуры.

Формирование концептуальной модели описания архитектуры отражено в 4.2.

Примечания

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

2    Рисунок 3 содержит дополнительные детали соответствия и правил соответствия. Рисунок 4 обеспечивает дополнительные детали обоснования архитектуры.

Описание архитектуры выражает архитектуру рассматриваемой системы.

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

Настоящий стандарт не определяет какого-либо формата или средства массовой информации (СМИ) для регистрации описаний архитектуры. Стандарт применим для ряда подходов к описанию архитектуры, включая ориентированные на документирование модели и методики, связанные с репозиториями.

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

4.2.3    Заинтересованные стороны и интересы

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

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

4.2.4    Архитектурные представления и точки зрения

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

Архитектурное представление выражает архитектуру рассматриваемой системы в соответствии с архитектурной точкой зрения (или просто, точкой зрения). Точка зрения имеет два аспекта: интересы, которые структурно представляются для заинтересованных сторон, и условности, которые устанавливаются в представлениях.

Какая-либо архитектурная точка зрения структурирует¹) один или более интересов. Интерес может быть структурирован более, чем одной точкой зрения.

¹ 8 настоящем стандарте глагол «структурировать» используется в его обычном языковом смысле: для формулировки или конструирования в определенном стиле или языке; для приложения в структуре или условно о структуре; для окружения таким образом, чтобы создать четкое или привлекательное изображение.

5

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

На рисунке 2 показаны отношения между представлениями и точками зрения в пределах описания архитектуры.

Примечания

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

2    В разделе 7 определены требования с использованием точек зрения на архитектуру. В приложении В приведено представление об определении точек зрения.

4.2.5    Модели архитектуры

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

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

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

4.2.6    Элементы и связи в описании архитектуры

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

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

На рисунке 3 изображено понятие элементов описания архитектуры и связи.

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

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

Примечание — Требования при использовании связей и правил связи определены в 5.7. Примеры их использования приведены в А.6 (приложение А).

4.2.7    Архитектурные решения и обоснование

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

6