allgosts.ru35. ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ35.080. Программное обеспечение

ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры

Обозначение:
ГОСТ Р 57100-2016
Наименование:
Системная и программная инженерия. Описание архитектуры
Статус:
Действует
Дата введения:
09/01/2017
Дата отмены:
-
Заменен на:
-
Код ОКС:
35.080

Текст ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры

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

НАЦИОНАЛЬНЫЙ

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

ГОСТР

57100—

2016/ISO/IEC/ IEEE 42010:2011

Системная и программная инженерия

ОПИСАНИЕ АРХИТЕКТУРЫ

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

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

Москва

Стенда ртмнформ 2016

ГОСТ Р 57100—2016

Предисловие

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

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

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

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

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

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

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

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

ГОСТ Р 57100—2016

Содержание

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

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

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

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 Определение заинтересованных сторон и интересов.......................II

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ш

ГОСТ Р 57100—2016

Введение

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

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

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

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

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

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

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

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

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

IV

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

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

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

Systems end software engineering. Architecture description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1

ГОСТ Р 57100—2016

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

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

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

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

Примеры

1 Обобщеннаястандартнаяархитвктурапредприятияииетодолоеии(ОЕКАМ){ИСО 15704} является некоторой структурой архитектуры.

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 57100—2016

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

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 57100—2016

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

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

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

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

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

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

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

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

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

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

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

ГОСТ Р 57100—2016

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5

ГОСТ Р 57100—2016

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

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

Примечен и я

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6

ГОСТ Р 57100—2016

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

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

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

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

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

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

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

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

зависит от

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

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

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

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

7

ГОСТ Р 57100—2016

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8

ГОСТ Р 57100—2016

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

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

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

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

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

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

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

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

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

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

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

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

9

ГОСТ Р 57100—2016

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

Примеры — Примерами языка описания архитектуры в терминах настоящеао стандарта являются Raplde(25), Wright(43}, SysML (31), ArchIMate (40) и точка зрения на языки со стороны эталонной модели открытой распределенной обработки (RM-ODP) (ИС01МЭК 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 Определение и обзор описания архитектуры

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

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

Ю

ГОСТ Р 57100—2016

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

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

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

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

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

• пользователи системы;

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

• приобретающие стороны системы;

• владельцы системы:

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

• разработчики системы;

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

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

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

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

• цепи системы;

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

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

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

• сопровождаемость и раэвиваемость системы.

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

Примечания

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

и

ГОСТ Р 57100—2016

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

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

Примечаний

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

2 в перечислении с) требование того, что каждое архитектурное представление охватывает целую систему относительно интересов, структурируемых ее главной точкой зрения, является существенным к полному распределению интересов в пределах описания архитектуры. 8 пределахлредстввления может быть использована одна или более архитектурных моделей, чтобы выборочно представить части системы для выдвижения сути интересов на первый план, не нарушая самого требования (см. 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

ГОСТ Р 57100—2016

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

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

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

5.7.3 Правила связи

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

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

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

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

Примечания

1 Связи а настоящем стандарте разработаны таким обрезом, чтобы быть совместимыми со связями из представления в эталонной модели открытой распределенной обработки (RM-ODP) (ИСО/МЭК 10746 и ИСО/МЭК 19793] в соответствии с А.6 (приложение А).

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

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

5.8.1 Регистрация обоснования

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

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

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

5.8.2 Регистрация решения

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

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

• решения относительно архитектурно существенных требований:

• решения, требующие больших инвестиционных усилий или времени для их формирования, реализации или внедрения;

• решения, воздействующие на основные заинтересованные стороны или множество заинтересованных сторон;

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

• решения, которые очень чувствительны к изменениям:

• решения, которые могут быть дорогостоящими к изменениям;

13

ГОСТ Р 57100—2016

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

• решения, которые приводят к капиталовложениям или косвенным затратам.

При регистрации решений следует учитывать следующее:

. решение является уникальным:

• решение утверждается;

• решение связывается с интересами системы, к которым оно имеет отношение;

• для решения определяется владелец:

• решение связывается с элементами описания архитектуры, воздействующими на решение:

• делается обоснование, связанное с решением в соответствии с 5.8.1;

• определяются ограничения и предположения, которые влияют на решение:

• регистрируются альтернативы, которые были рассмотрены, и их потенциальные последствия:

• регистрируются последствия решения (касающиеся других решений);

• регистрируются временные отметки, когда решение было принято, когда было одобрено и когда было изменено;

• предоставляются цитаты по источникам дополнительной информации.

Примечен и я

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

2 Может оказаться полезным провести регистрацию взаимосвязей между решениями архитектуры. Примеры типов отношений: ограничения, воздействия, разрешения, инициации, усилия, категорирование, уточнения, «рассогласования с» и «совместимость с» (см. |2Э]. (44)).

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

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

Структура архитектуры должна включать:

a) информацию, определяющую структуру архитектуры;

b) определение одного или более интересов (см. 5.3);

c) определение одной или более заинтересованных сторон, имеющих эти интересы (см. 5.3):

d) одну или более точек зрения на архитектуру, которые структурируют эти интересы (см. раздел 7);

e) любые правила связи (см. 5.7).

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

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

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

- описание архитектуры, использующее структуру архитектуры AF1. должно определять заинтересованные стороны А. МиР. коада рассматриваемая система работает в пределах юрисдикции J;

- описание архитектуры, использующее структуру архитектуры AF2. разрешает пропустить точку зрения VI. если не определено никаких интересов системы реальное о времени:

- коада используется структура архитектуры AF3. для точки зрения VI может быть пропущен вид модели МК. если S является некоторой определенное заинтересованной стороной.

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

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

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

Описание архитектуры придерживается структуры архитектуры, когда:

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

- каждый применимый интерес, определенный в структуре архитектуры, учтен и определен в описании архитектуры (см. 5.3);

• каждая применимая точка зрения, заданная структурой архитектуры (см. 6.1). включена (см. 5.4) в описание архитектуры;

14

ГОСТ Р 57100—2016

• каждое применимое правило связи, заданное структурой архитектуры, включено в описание архитектуры (в 5.7.3);

• описание архитектуры соответствует требованиям раздела 5.

Термин «применимый* означает, что условия применимости (см. 6.1) соблюдены.

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

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

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

Язык описания архитектуры (ЯОА) должен задавать:

a) определение одного или бопее интересов, которые будут выражены ЯОА (см. 5.3);

b) определение одной или бопее заинтересованных сторон, имеющих эти интересы (см. 5.3);

c) виды моделей, реализованные ЯОА. которые структурируют эти интересы [см. раздел 7. перечисление d)j:

d) любые точки зрения на архитектуру согласно разделу 7.

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

e) правила связи (см. 5.7). связь видов модели согласно перечислению с).

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

Точка зрения на архитектуру должна задавать:

a) один или более интересов, структурируемых этой точкой зрения (см. 5.3);

b) характерные заинтересованные стороны для интересов, структурируемых этой точкой зрения (см. 5.3);

c) один или более видов модели, используемых в этой точке зрения;

d) для каждого вида модели, определенного в перечислении с), языки, нотации, соглашения, методики моделирования, аналитические методы и/или другие операции, которые будут использоваться на моделях этого вида;

e) ссылки на источники.

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

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

• правила связи, критерии и методы для проверки согласованности (см. 5.7.1) и полноты (см. 5.5. перечисление d)):

• методы оценки или анализа:

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

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

Примечания

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

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

1$

ГОСТ Р 57100—2016

Приложение А (справочное)

Примечания к терминам и понятиям

А.1 Введение

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

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

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

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

А.2 Системы и архитектура

8 настоящем стандарте термин ■архитектура» предназначен для того, чтобы передать суть или основные положения системы. Существует несколько основных аспектов определения архитектуры в нестоящем стандарте (см. 3.2). Приведенное определение было выбрано для охвата различных вариаций предыдущих использований термина «архитектуре» путем признания их основного общего содержания. Основной принцип — это потребность понять и управлять теми элементами рассматриваемой системы, которые влияют на ее полезность, стоимость. временные характеристики и риски в пределах ее окружающей среды. В некоторых случаях основными элементами являются физические или структурные компоненты системы и их отношения. Иногда основными элементами являются функциональные или логические элементы. В других случаях, если это является основным или существенным для понимания рассматриваемой системы, элементами могут быть ее всеобщие принципы или образцы. Определение архитектуры в настоящем стандарте предназначено для того, чтобы охватить эти различные. но связанные варианты применения, поощряя более строгие очертания того, что составляет архитектуру системы.

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

Эмпирические исследования обнаружили четыре модельных представления архитектуры в организациях (3d]:

• архитектура как проект;

• архитектура как литературе:

• архитектура как язык:

• архитектура как решение.

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

А.З Интересы

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

16

ГОСТ Р 57100—2016

Мотиваций для применения этого термине произошла от словосочетания «разделение интересов» из программной и системной инженерии (EOsger W. Dijkstra. 1974):

«Позвольте мне попытаться объяснить Вам. что по моему представлению характерно для всего интеллектуального мышления. Это то. что каждый желает глубоко изолированно изучить некоторый аспект предмета в интересах его собственной согласованности. все время осознавая, что он занимается лишь одним из аспектов. Мы знаем, что программа должна быть правильной, и можем изучить ее только с конкретной точки зрения: мы также знаем, что ей следует быть эффективной, и а другой раз мы можем изучить ее эффективность. 8 следующий раз мы можем спросить себя: «Почему программа востребована»? Но. занимаясь этими различными аспектами одновременно, ничего не получается — наоборот! Это именно то. что я иногда называл «разделением интересов», которое, даже если совершенно невозможно, все же является единственной приемлемой методикой для эффективного упорядочения намерений, о которых я знаю. Это то. что я подразумеваю под «сосредоточением внимания на некоторых аспектах», что не означает игнорирования других аспектов, а только оправдывает факт того, что с точки зрения этого аспекта другой является неактуальным. Это — одно- и многократное отслеживание, рассматриваемое одновременно» |7].

Как определено в настоящем стандарте, каждая точка зрения на архитектуру структурирует один или более интересов (см. S.4) так. чтобы представление, соответствующее точке зрения, обращалось к определенным известным интересам рассматриваемой системы. Отделение обработки интересов с помощью представлений позволяет заинтересованным сторонам сосредоточиваться не нескольких вопросах одновременно и предлагает средство для управления сложностью (см. 5.5). Литература в области системной и программной инженерии отражает большой набор таких интересов. Примеры приведены в 4.2.3.

Хотя интересы включают риски и опасности (см. S.3). этот термин не следует понимать как синоним *рисков» или «беспокойств», он должен пониматься как обращение к «любой» теме интересов.

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

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

Целью настоящего стандарта является охват существующих практик описания архитектур, обеспечивающих общую терминологию и понятия. Многие существующие практики выражают архитектуру через подборку моделей. Как правило, эти модели далее интегрируются в связные группы, называемые *предстевленияии». Единство группы моделей определяется в соответствии с интересами, к которым обращается эта группа моделей То. что упускалось в недавней практике. — это отличие термина для механизме формализации этих группирований от ссылки на соглашения, в соответствии с которыми сделаны эти модели В настоящем стандарте точке зрения ссылвется на соглашения для того, чтобы вырвзить архитектуру относительно ряда интересов:

Точка зрения — это способ взгляда на систему: представление — это результат применения точки зрения к конкретной рассматриваемой системе.

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

Наиболее ранние работы нвд важнейшими точками зрения проявились в структурном анализе (а методологии структурного анализа и проектирования SADT)e 1977 r.(3S). В инженерии требований точки зрения рассмотрены как важнейшие сущности со связанными атрибутами и операциями (29]. Эти работы способствовали формированию точек зрения на архитектуру так. какэтоолределено враэделе 7. Термин «точка зрения» был также выбран для совместимости с эталонной моделью открытой распределенной обработки (RM-OOP), которая использует этот термин следующим образом:

• точке зрения (на систему) является абстракцией, которая приводит к какой-то спецификации целой системы. связанной с конкретным множеством интересов. (ИСОГМЭК 10746-1:1996. пункт 6.2.2):

• точке зрения (на систему) — форма абстракции, достигнутой с использованием отобранного множества архитектурных конструкций и структурирования правил в порядке сосредоточения на конкретных интересах в пределах системы (ИСО/МЭК 10746-2:2009. пункт 3.2.7].

Однако там. где настоящий стандарт использует термин «архитектурное представление» для ссылки на применение точки зрения к конкретной системе, эталонная модельоткрытой распределенной обработки (RM-OOP) использует термин «спецификации точки зрения».

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

представление . точка зрения :. программа . язык программирования1*

'* Это должно быть прочитано так: «представление к точке зрения как программа к языку программирования».

17

ГОСТ Р 57100—2016

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

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

представление : точка зрения :: карта (связи): надпись.

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

Другой термин «тип представления», введенный в (5|. устанавливает категоризацию точек зрения в терминах настоящего стандарта. В указанной работе описаны три категории точек зрения: модуль, компонент и соединитель. а также распределение типов представления.

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

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

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

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

Из(38)известно.что:

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

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

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

А.5 Модели, рабочие продукты и архитектурные модели

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

М является моделью S. если М может использоваться для ответа на вопросы о S1'.

11 Это определение возникло в лаборатории электроники Массачусетского технологического института в 1960-е годы. Определение появилось в работе О.Т. Ross и М. Minsky, которые работали в этой лаборатории в тот период времени.

•Для наблюдателя в объект А* является моделью объекта А до такой степени, что в может использовать А*, чтобы ответить на вопросы, которые интересуют его об объекте А. М. Minsky. Суть, мнение и модели. 1968.

*М является моделью относительно множества вопросов О. если и только если М может использоваться, чтобы ответить на вопросы об объекте А в О в пределах приемлемости Г» О.Т. Ross. Технические основы характеризации. 1977.

18

ГОСТ Р 57100—2016

У этого утверждений есть две важных следствия:

1) У каждой модели есть объект.

2) Модель может быть:

I} понятием «ментальная модель»:

II) рабочий продуктом.

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

В первом смысле термина существует несколько видов моделей, связанных с процессом архигектуризации. которые описаны а настоящем стандарте. Различие между 2i) и 2И)крайне важно для понимания в настоящем стандарте разницы между архитектурой и описанием архитектуры. В смысле 21} архитектура — это концепция системы (т. е. ментальная модель), полезная для ответов на некоторые вопросы об этой системе. 8 смысле 2И) существует три айда моделей, определенных в настоящем стандарте, реализуемых как рабочие продукты:

• описание архитектуры — это рабочий продукт, который моделирует архитектуру рассматриваемой системы: его объект, отражающий вопросы определенных заинтересованных сторон обо всех определенных интересах системы:

- архитектурное представление — это рабочий продукт: его объект — это специальное множество интересов заинтересованной стороны, структурируемых главной точкой зрения:

• архитектурная модель — это рабочий продукт: его объект определяется с помощью его вида модели.

Рабочий продукт понимается а настоящем стандарте как «артефакт, связанный с выполнением процесса»

(ИСО/МЭК 15504-1:2004. пункт 3.55|.

А.6 Связи

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

В ИИРЭ14 71:2000 эта потребкостьанвлизируется а терминах требований, а выявленные несогласованности регистрируются черезпредставления описаний архитектуры (см. 5.7.1). В то время небыло никакой известной практики для систематизации согласно стандарту для выражения или предписания такой согласованности.

Настоящий стандарт вводит связи для выражения отношений между элементами описания архитектуры. У связей имеется ряд применений. Они могут быть применены для выражения согласованности, прослеживаемости, композиции, уточнения и преобразования моделей или зависимости любого типа, охватывающего более чем один вид модели, в [2] приведен обзор применений отношений моделей совместно с таксономией и классификацией механизмов отношения. Связи могут использоваться для удовлетворения требованиям (см. 5.7.1) по регистрации согласованности и несогласованностей в представлении.

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

Пример 1 — Рассматривает дев представления системы S: представление аппаратных средств HW (S) и представление компонента программных средств SC (5). Учитывая, что SC (S) включает »лементы программных средств. е1,... еб. и HW (S) включает платформы аппаратных средств.

(Элемент) ExecutesON-

-Выполняется на (Платформе) См. Правило: R1

е1

Р1.Р4

е2

р2, рЗ

еЗ

РЗ

е4

р4

Рисунок А.1 — Пример связи

19

ГОСТ Р 57100—2016

Пример 1 отвечает требованию S.7.2: есть уникальное имв (ExeculeaOn — «выполняется не»), определяются участвующие элементы (обозначаемые и pj) и дополнительное правило связи (R1).

Правило связи выражает ограничение для применения к связи. Пример 2 представляет простое правило

связи.

Пример 2 — Рассматривает dee тонко зрения: аппаратные средства и компоненты программного средства. Правило связи, связывающее эти точки зрения:

R1 — Каждый злемент программных средств el. как определено компонентами лроврвммноео средства, должен выполняться на одной или более платформах pj. как определено для аппаратных средств.

Связь Ехеси1е$Оп[«Выполняется не») из примера 1 нарушает правило R1 для примера 2. потому что некоторым элементам программных средств SC ($) (еб и еб) не предписано выполнение на какой-либо платформе.

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

Пример 3— Рассматривается следующее правило связи:

Задачи — Взаимодействия: у каждого случая вида модели «Задачи» должно быть уточнение к случаю вида модели «взаимодействия».

Это правило связи моделей может быть выполнено с помощью связи, показанной на рисунке А.2. где есть Пользователи. Операторы и Аудиторы. Каждая модель Задачи (иллюстрированная в виде треугольника), уточняется в модели взаимодействия (иллюстрированные как пятиугольники).

Рисунок А.2 — Пример связи, удовлетворяющей правилу «Задачи — Взаимодействия*

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

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

Пример 4 — Рассмотрим следующее правило связи моделей:

Представление — Версии: показатель Версии каждого представления должен быть более, чем в 1,5 раза выше, нежели до публикации.

20

ГОСТ Р 57100—2016

Термин «связь* был выбран для гармонизации с эталонной моделью открытой распределенной обработки (RM-ODP) Механизм связи спроектирован для совместимости с представлением связи в эталонной модели открытой распределенной обработки (RM-ODP) (ИСО/МЭК 19793); однако существует ряд отличий. Выявленные отличия состоят в следующем:

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

2) Связи представления эталонной модели открытой распределенной обработки (RM-ODP) — это бинарные отношения, тогда как связи модели в этом стандарте — это л-арные отношения.

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

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

Математически связь является л-арным отношением Правило связи является содержательным определением л-арного отношения. Отношения включают картографию 1-1 (изоморфизмы) и функции как специальные случви. и то. и другое являются слишком ограничительными для многих применений связей. У отношений имеются полезные свойства, которые разрешают композицию и обоснования и позволяют эффективное изображение и манипуляцию (см. [26]}. Пример S показывает некоторые из вышеупомянутых примеров, выраженных как отношения во множественных нотациях.

Пример 5 — ExecuteaOn (R1) • ((е1, pi), (el. p4). (e2, p2). (e2, рЗ), (еЗ, p3), (e4. p4)}.

Пользователи (Задачи—Взаимодействия) • {(Оператор Задачи. Оператор Взаимодействия), (Заказчик Задачи, Заказчик взаимодействия). (Аудитор Задачи. Аудитор взаимодействия)).

Последняя версия (Представление—-версия) ■ ((Представление^ Версия v2.0). (Представление!. версия v2.0). (Представление!, Версия v2.0), (Представление4. версия v2.0), (Представлениеб, Версия v2.0)f.

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

В системной и программной инженерии понятие структуры архитектуры относится к 1970-м годам (6|. [44]. Мотивацией для определения этого термина (см. 3.6} и его спецификаций (см. 6.1) в настоящем стандарте является выражение средств определения существующих и будущих структур архитектуры единообразным способом с тем. чтобы продвинуть обмен информацией о системвх. архитектурах и методиках описания архитектуры. При этом ожидается взаимодействие, которое позволит улучшить понимание и способность к интероперабельности между сообществами архитектуры, использующими различные концептуальные основы. Единообразное определение точек зрения архитектуры и скоординированные наборы таких точек зрения могут продвинуть повторное использование инструментариев и методик к сообществам, использующим эти структуры.

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

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

Ранние ЯОА рассматривались в (25| и (43). ЯОА сосредоточивались на структурных интересах: крупномасштабная организация системы, выраженная в терминах компонентов, соединителей и конфигураций и изменяющая поддержку структуризации поведенческих интересов. Позже широкий спектр ЯОА был разработан с поддержкой более широкого диапазона интересов. Они включают языки анализа и описания архитектуры (ЯАОА) [37]. язык моделирования систем |31| и язык ArchiMate [40]. Примеры 1 и 2. представленные ниже, описывают две современных ЯОА со ссылкой на их соотношение с концептуальной моделью, определенной в настоящем стандарте.

21

ГОСТ Р 57100—2016

Примеры

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

2 Язык моделирования систем (SyaUL) создал унифицированный язык моделирования (UML). Язык моделирования систем определяет несколько типов диаарамм: деятельность, последовательность, машину состояний, случай использования, определение блохе, внутренний блок, пакет, параметрические диаараммы и диаераммы требования. В терминах, приведенных в настоящем ствндврте. каждый тип диаараммы — это еидмодели. Язык моделирования систем обеспечивает важнейшие конструкции для заинтересованных сторон, интересов, представлений и точек зрения таким образом, чтобы пользователи моали создать новые точки зрения в соответствии с настоящим стандартом.

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

22

ГОСТ Р 57100—2016

Приложение В (справочное)

Руководство к точкам зрения на архитектуру

В.1 Введение

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

В.2 Шаблон для документирования точек зрения на архитектуру

В.2.1 Обзор шаблона

Представлен шаблон для точек зрения на архитектуру. Точка зрения на архитектуру, которая документируется в эту форму, удовлетворяет требованиям, указанным в разделе 7.

Шаблон состоит из ряда разделов или информационных объектов (см. 6.2.2—в.2.11). Каждый раздел определен наименованием (см. В.2. X — Наименование раздела), сопровождаемым кратким описанием его намеченного содержания. руководства для разработки содержания и в некоторых случаях подраздела. Не каждый раздел необходим для документирования каждой точки зрения. Этот шаблон основан на образце, предложенном в [9|.

В.2.2 Наименование точки зрения

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

В.2.3 Обзор точки зрения

Резюме или краткий обзор точки зрения и ее главных особенностей.

В.2.4 Интересы и «противоположные интересы»

Перечисление связанных с архитектурой интересов, которые будут структурированы этой точкой зрения, приведено в разделе 7. перечисление в). Для архитектора это является критичной информацией, т. к. она помогает решать, будет ли данная точка зрения полезна для рассматриваемой системы.

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

В.2.5 Типичные заинтересованные стороны

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

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

В.2.6 Виды моделей

В.2.6.1 Введение

Определяется каждый вид модели, заданный точкой зрения в перечислении с) раздела 7.

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

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

1) задание метамодели, которая определяет его основные конструкции:

2) обеспечение шаблона модели для заполнения пользователями.

3) через языковое определение или с помощью ссылки к существующему языку моделирования.

4) некоторую комбинацию этих методов.

Руководство для методов 1>—3) представлено ниже.

В.2.6.2 Вид модели: метамодель

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

• сущности (объекты): Каковы главные типы элементов, которые присутствуют в моделях этого айда?

• атрибуты: Какие свойства реализуют сущностные (объектовые) процессы в моделях этого вида?

23

ГОСТ Р 57100—2016

• отношения: Какие отношения определены среди сущностей (объектов) е моделях этого вида?

• ограничения. Какие виды ограничений существуют для сущностей (объектов), атрибутов и/или отношений а моделях этого вида?

Сущности (объекты), атрибуты, отношения и ограничения — это все элементы описания архитектуры, определенные в 3.4 (также см. 4.2.5 и 5.7).

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

8.2.6.3 вид модели, шаблон

Обеспечивается шаблон или форма. определяющиеформатиМли содержание моделей этого вида моделей.

8 2.6 4 вид модели: языки

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

в.2.6.5 вид модели: операции

Определяются операции, доступные на моделях этого вида. Содержание операций на представлениях изложено в В.2.8.

В.2.7 Правила связи

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

В.2.8 Операции на представлениях

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

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

• интерпретирующие методы — это средстве, с помощью которых представления становятся понятными заинтересованным сторонам системы и читателям:

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

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

в.2.9 Примеры

Этот раздел содержит примеры.

В.2.10 Примечания

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

В.2.11 Источники

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

В.З Аннотируемое руководство к точкам зрения не архитектуру

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

- СвНо-Апав. America. Avgenou «Определение точек зрения для большой и сложной программной системы» («Defining execution viewpoints for a large and complex software-intensive system») (4].

Документирует «каталог выполнения точки зрения» для того, чтобы понять выполнение сложных программных систем. Представлены четыре точки зрения, профиль выполнения, развертывание выполнения, использование ресурсов и параллелизм выполнения. Также включены правила связи между точками зрения:

- Clements и др . Документирование архитектур программных средств: представления и более (Documenting Software Architectures: views and beyond) (5).

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

- EeieswCtipps.Процесс ерхитектуризации программных средств (The Processof Software Architectmg)l&).

24

ГОСТ Р 57100—2016

Определяет процесс архитектуризации программных средста. используя а качестве основы модель ИИЭР 1471:2000. Обеспечивает шаблон точки зрения и каталог точек зрения, включая: требования, функционал, развертывание, валидацию, применение, инфраструктуру, управление системами, пригодность, функционирование. безопасность, а также для каждого — «рабочие продукты» (то есть виды моделей);

• Репозитарий точек зрения для ИСО/МЭК 42010 (42].

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

• Kruchten. «Модель представления архитектуры «4*1» (23).

Определяет точки зрения для логического представления, представления разработки, представления процессов и физического представления. Получающиеся представления объединяются через сценарии;

• Rozansky и Woods. Архитектура программных систем: работе с заинтересованными сторонами с испопьзоаанием точек зрения и перспективности {Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives) [36|.

Определяет каталог точек зрения; функционал, информация, параллелизм, разработка, эксплуатация и перспективы (см. примечание 1 к 5.6): безопасность, функционирование и масштабируемость, пригодность и стойкость. перспективы развития для программных систем.

25

ГОСТ Р 57100—2016

Приложение С (справочное)

Взаимосвязь с другими стандартами

С.1 Введение

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

С.2 Использование ИСО/МЭК 12207:2010

С.2.1 Общее

В ИСО/МЭК 12207:2010 определены два процесса, специально имеющие отношение к архитектуре: проектирование архитектуры системы (см. ИСО/МЭК 12207:2010. пункт 6.4.3) и проектирование архитектуры программных средств (см. ИСО/МЭК 12207:2010. пункт 7.1.3). Понятие архитектуры в настоящем стандарте совместимое процессами проектирования архитектуры в ИСО/МЭК 12207:2010. в ИСО/МЭК 1220:2010 приведены требования к описанию архитектуры в дополнение к таковым из настоящего стандарта. Специфично то. что проектирование архитектуры системы должно включать определение объектов аппаратных средств, программных средств и объектов ручных операций, включенных в систему и распределение системных требований по этим объектам. Проектирование архитектуры системы должно быть оценено на соответствие критериям прослеживаемости и согласованности с требованиями к системе, приемлемости стандартов и методов проектирования и выполнимости программных и ручных операций.

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

Процесс проектирования архитектуры программного средства согласно ИСО/МЭК 1220:2010 иллюстрирует декомпозиционный подход к архитектуре. Его первичная цель состоит в декомпозировании объектов программных средств системы в компоненты и последующем распределении требований по этим компонентам. Описание архитектуры системы и продукты других представлений в описании архитектуры могут способствовать этой деятельности и ее продуктам.

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

в С.2.2.

С.2.2 Точка зрения декомпозиции и распределения

Точка зрения декомпозиции и распределения структурирует следующие интересы:

• определение системных требований:

• декомпозицию системы на объекты:

• распределение требований по объектам.

• верификацию того, что все требования распределены по объектам.

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

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

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

В итоге начальной декомпозиции и распределения производится множество объектов с распределенными требованиями. Это описано в терминах процесса проектирования архитектуры системы (см. ИСО/МЭК 12207:2010, подпункт 6.4.Э.3.1).

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

26

ГОСТ Р 57100—2016

объектами и объектами ручного оперирования. Это описано в терминах проектирования архитектуры программных средств (см. ИСО/МЭК 12207:2010. подпункт 7.1.3.3 1).

С.З Использование ИСО/МЭК 15288:2008

С.3.1 Общее

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

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

Описание архитектуры может соответствовать настоящему стандарту и ИСО/МЭК 1S288. У общего подхода к к совместному соответствию* должнв быть точка зрения, которая слециапьно сосредотачивается на производстве архитектурной продукции согласно ИСО/МЭК 15288. Пример точки зрения для этой цели определен в С.3.2.

С.3.2 Декомпозиция и точка зрения распределения

Точка зрения декомпозиции и распределения структурирует следующие интересы.

• определение системных требований.

• декомпозицию системы на объекты;

• распределение требований по объектам.

• верификацию того, что все требования распределены по объектам.

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

Система декомпозируется во множество элементов. Также определяются взаимодействия между объектами.

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

В итоге начальной декомпозиции и распределения производится множество элементов с распределенными требованиями. Это определено в терминах архитектурного описания системы (см. ИСО/МЭК 15288:2008. подпункт 6.4.3.3. перечисление с)].

С.4 Использование со стандартами открытой распределенной обработки

С.4.1 Общее

Эталонная модель открытой распределенной обработки (RM-ODP) определяет структуру архитектуры для систем распределенной обработки; системы, «в которых дискретные компоненты могут быть расположены в различных местах, в связь между компонентами может иметь задержку или оказаться неудачной» (см. ИСО/МЭК 10746-2:2000).

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

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

Описание архитектуры, соответствующее настоящему стандарту и использующее ИСО/МЭК 10746-3, может включатьточки зрения, определенные ИСО/МЭК 10746-3. и представления о реализации этих точек зрения. Необязательно ограничиваться пятью точками зрения, определенными в ИСО/МЭК 10746-3 для соответствующего описания архитектуры. При необходимости описание архитектуры может включать дополнительные точки зрения и представления.

Элементы спецификации, опредепенкой для описаний архитектуры (такие как заинтересованные стороны), здесь опущены, так как они являются специально ориентированными не индивидуальные системы. Если это не отмечено, все содержание берется непрямую или цитируется согласно ИСО/МЭК 10746-3:1996 (ИСО/МЭК 10746-3:2001).

Примечание — ИСО/МЭК 19793 определяет профиль UML для спецификации систем открытой распределенной обработки, используя эти точки зрения.

С.4.2 Предпринимательская точка зрения

Предпринимательская точка зрения (точка зрения предприятия) структурирует следующие интересы:

• цель, область применения и политику для системы открытой распределенной обработки;

• роли, выполняемые системой:

27

ГОСТ Р 57100—2016

• действия, совершаемые системой;

• положения политики о системе.

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

• предпринимательских объектов (объектов предприятия), включающих сообщество.

• ролей, выполняемых каждым из этих объектов:

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

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

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

• политики, относящейся к контрактам по окружающей среде, управляющим системой.

Примечания

1 Роли ограничивают поведение объектов, их выполняющих.

2 Политики определены в терминах разрешений, обязательств и запрещений.

2 Предпринимательский язык (язык предприятия) определен в ИСО/МЭК 15414.

С.4.3 Информационная точка зрения

Информационная точка зрения структурирует интересы в виде семвнтик информации и обработки информации в системе открытой распределенной обработки.

Информационный язык определен в терминах трех схем:

• инвариантной схемы, предикаты на объектах, которые всегда должны быть всостоянии «верно» («true»);

• статической схемы: состояния одного или болев объектов а некоторый момент времени;

• динамической схемы: изменения допустимого состояния одного или более объектов.

С.4.4 Вычислительная точка зрения

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

Вычислительный язык охватывает понятия для определения:

• вычислительных объектов;

• интерфейсов для объектов и определения интерфейсов:

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

• неявных и явных связываний и объектов составного связывания.

C.4.S Инженерная точка зрения

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

Инженерный язык включает понятия для определения:

• конфигурации объектов инженерии в целях управления, включая узлы (для ресурсов), капсулы (для защиты) и кластеры (для срабатывания);

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

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

С.4.6 Технологическая точка зрения

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

Технологический язык включает понятия:

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

• выражения того, как реализованы спецификации для системы открытой распределенной обработки;

• оказания поддержки при испытаниях.

28

ГОСТ Р 57100—2016

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

[1] ANSI/IEEE Sid 1471-2000, IEEE Recommended Practice for Architectural Descnption of Software-Intensive Systems

[2] Воискё. N.. Composition and relations of architectural models supported by an architectural descnption language. Doctoral dissertation. Kathotleke Universlteit Leuven. October. 2009

[3] Buschmann F., R. Meunier. H. Rohnert. P. Sommerted and M Stal. Pattem-Onented Software Architecture: A System of Patterns, John Wiley & Sons. 1996

[4J Catlo-Arlas. T. В.. P. America, and P. Avgenou. Defining execution viewpoints for a large and complex software-intensive system. Proceedings of WICSA/ECSA 2009

[S| Clements P.. F. Bachmann. L. 8ass. D. Gsrlsn. j. Ivers. R. Little. R. Nord. and J. Stafford. Documenting Software Architectures: Views and Beyond. 8oston. Addlson-Wesley. 2002

(6| Darnton. O. and S. Giacoletto. Information in the Enterprise. Burlington. MA. Digital Press. 1992

[7| Dijkstra. E. W.. On the rote ol scientific thought. 1974.

. eduAisef&/EWD/transcnptions/EWD04xxZEWD447.html

[8] Eeles P. and P. Cnpps. The Process of Software Architecting. Addison Wesley. 2010

[9| Hilliard, R. «Viewpoint modelling*. First ICSE Workshop on Describing Software Architecture with UML. May 2001

(10] Hofmeister. C.. R. Nord. and D. Soni. Applied Software Architecture. Reading. MA: Addison-Weeley. 1999

(11] ISO/IEC 10746-1, Information technology — Open Distributed Processing — Reference model: Overview

(12] ISO/IEC 10746-2. Information technology — Open distributed processing — Reference model: Foundations

(13] ISO/IEC 10746-3. Information technology — Open dlstnbuted processing — Reference model: Architecture

(14] ISO/IEC 12207. Systems end software engineering — Software life cycle processes

(15] ISO/IEC 15288. Systems and software engineering — System life cycle processes

(16] ISO/IEC 15269, Systems and software engineenng — Content of systems and software hfe cycle process Information products (Documentation)

(17] ISO/IEC 15414:2006, Information technology — Open dlstnbuted processing — Reference model — Enterprise language

(16] ISO/IEC 15504-1:2004. Information technology — Process assessment— Part 1: Concepts and vocabulary

(19] ISO 15704. Industnal automation systems— Requirements for enterprise-reference architectures and methodologies

(20] ISO/IEC 19501:2005. information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2

(21] ISO/IEC 19793:2006. Information technology — Open Distributed Processing — Use of UML for ODP system specifications

(22] ISO/IEC 25010. Systems end software engineering—Systems and software Ouelity Requirements and Evaluation (SOuaRE) — System and software quality models

(23] Kruchten, P.B.. «The '4 * 1' View Model of Architecture*. IEEE Software. 12(6). 45—50. 1995

(24] Kruchten. P.B.. «An Ontology of Architectural Design Decisions m Software-Intensive Systems*. Proceedings of the 2nd Groningen Workshop on Software Variability, 54—61.2004

(25] Luckham.D.C.. J.J. Kenney. L.M. Augustin. J. Vera. D. Bryan and W. Mann. «Specification and analysis of system architecture using RAPIDE*. IEEE Transactions on Software Engineering. 21(4). 336—355. April 1995

(26] Maier. M.W. and E. Rechtin. The art of systems architecting. CRC Press. 2nd edition. 2000

(27] Ministry of Defence Architecture Framework (MODAF), http .//

[26] Muskens. J.. R.J. Bnl and M.R.V. Chaudron, «Generalizing consistency checking between software views*. Proceedings of the 5th Working IEEE/1FIP Conference on Software Architecture (WICSA‘05). 169—180. Washington. DC: IEEE Computer Society. 2005

[29] Nuseibeh. B.. J. Kramer and A. Finkelstem. «А framework for expressing the relationships between multiple views in requirements specification*. IEEE Transactions on Software Engineenng. 20(10). 760—773. 1994

[30] ОЬЫпк. H.. P.8. Kruchten. W. Ko2aczynski. R. Hilliard. A. Ran. H. Postema. D. Lutz. R. Kazman. W. Тгасг, and E. Kahane. Report on Software Architecture Review and Assessment (SARA). 2002.

[31] OMG formal/2008-11-01. Systems Modeling Language, version 1.1. November 2008

[32] Perry. D.E. and A.L. Wolf. «Foundations for the Study of Software Architecture*. ACM SlGSOFT Software Engineering Notes. 17(4), 1992

[33] Proakis. J.G.. Digital Communications. New York: McGraw-Hill. 1995

[34] Ran. A. «ARES Conceptual Framework tor Software Architecture*. M. Jazayen. A. Ran. and F. van der Linden (eds.). Software Architecture for Product Families Principles and Practice. 8oston. Addison-Westey. 1—29.2000

[35] Ross. D.T.. «Structured Analysis (SA>: a language for communicating Ideas*. IEEE Transactions on Software Engineering. SE-3(1). 16—34. 1977

29

ГОСТ Р 57100—2016

[36| Rozansky. N. end Е. Woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2005

[37] Society of Automotive Engineers. Architecture Analysts & Design Language, http ://

[38] Shaw. M. «Prospects for an engineering discipline of software». IEEE Software. November 1990

(39| Smolander, K.. «Four Metaphors of Architecture in Software Organizations: Finding out The Meanng of Architecture in Practice». Proceedings of the 2002 International Symposium on Empirical Software Engineering (ISESE’02)

(40| The Open Group. ArchiMate 1.0 Specification. February 2009. hnp://

(411 The Open Group Architecture Framework (TOGAF). . org/togaf/

(42| Viewpoints Repository for ISO/IEC 42010 nttp7/

[43] Wright ЯОА website,

(44| Zachman. J.A.. «А Framework for Information Systems Architecture». IBM Systems Journal. 26(3). 1987

(4S| Zimmermann O.. Koehler J.. Leymann F.. Polley R.. Schuster N.. «Managing Architectural Decision Models with Dependency Relations. Integrity Constraints, and Production Rules». The Journal of Systems and Software and Services. Special issue on Design Decisions and Rationale in Software Architecture Special Edition on Architectural Decisions. Elsevier. 2009

30

ГОСТ Р 57100—2016

УДК 004.4:006.354 ОКС 35.080

Ключевые слова: описание архитектуры, процесс архитектуриэации. структура архитектуры, точка зрения на архитектуру, язык описания архитектуры

31

Редактор К.в. Колесникове Технический редактор в.Ю. Фо/лиева Корректор М.С Хабашоаа Компьютерная верстка Н А. Напайкипой

Сдано я набор 26.09.2016. Подписано е печать 11.10.2016. Формат 60»84^. Гарнитура Ариел Уел. поч. л. 4.16. Уч.'Иад. п. 6.76. Тирам 33 экэ. За к 2466.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ*. 12399S Москва. Гранатный пер.. 4