ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011. Национальный стандарт Российской Федерации. Системная и программная инженерия. Описание архитектуры

(утв. и введен в действие Приказом Росстандарта от 22.09.2016 № 1190-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р 57100-2016"]:::rst
  click n0 "https://bukva.ai/docs/gost-r-57100-2016" "ГОСТ Р 57100-2016. Национальный стандарт Российской Федерации. Системная и программная инженерия. Описание архитектуры (утв. и введен в действие Приказом Росстандарта от 22.09.2016"
  n1["ГОСТ Р 57100-2025"]:::doc
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

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

СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ

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

Systems and software engineering. Architecture description

(ISO/IEC/IEEE 42010:2011, IDT)

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

Предисловие

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

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

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

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

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

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

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

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

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

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

4.1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1. Введение

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

• определение описания архитектуры и обзорную информацию (см. 5.2);
• определение заинтересованных сторон системы и их интересов (см. 5.3);
• определение каждой точки зрения на архитектуру, используемой в описании архитектуры (см. 5.4);
• представления архитектуры и архитектурных моделей для каждой используемой точки зрения на архитектуру (см. 5.5 и 5.6);
• применимые правила связей в описании архитектуры, связи и регистрацию известных несогласованностей в требуемом содержании описаний архитектуры (см. 5.7);
• выполненные обоснования для решений архитектуры (см. 5.8).

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

Примечания

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

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

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

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

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

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

• пользователи системы;
• операторы системы;
• приобретающие стороны системы;
• владельцы системы;
• поставщики системы;
• разработчики системы;
• строители системы;
• сопровождающие стороны системы.

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

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

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

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

Примечания

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

• описание архитектуры, использующее структуру архитектуры AF1, должно определять заинтересованные стороны A, M и P, когда рассматриваемая система работает в пределах юрисдикции J;
• описание архитектуры, использующее структуру архитектуры AF2, разрешает пропустить точку зрения V1, если не определено никаких интересов системы реального времени;
• когда используется структура архитектуры AF3, для точки зрения V2 может быть пропущен вид модели MK, если S является некоторой определенной заинтересованной стороной.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• правила связи, критерии и методы для проверки согласованности (см. 5.7.1) и полноты [см. 5.5, перечисление d)];
• методы оценки или анализа;
• методы, эвристики, показатели, образцы, правила проектирования или руководящие принципы, лучшие практики и примеры для достижения целей в представлениях создания и синтеза.

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

Примечания

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

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

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

ПРИМЕЧАНИЯ К ТЕРМИНАМ И ПОНЯТИЯМ

A.1 Введение

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

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

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

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

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

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

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

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

• архитектура как проект;
• архитектура как литература;
• архитектура как язык;
• архитектура как решение.

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

A.3 Интересы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из [38] известно, что:

<1> Это определение возникло в лаборатории электроники Массачусетского технологического института в 1960-е годы. Определение появилось в работе D.T. Ross и M. Minsky, которые работали в этой лаборатории в тот период времени:

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

«M является моделью относительно множества вопросов Q, если и только если M может использоваться, чтобы ответить на вопросы об объекте A в Q в пределах приемлемости T». D.T. Ross, Технические основы характеризации, 1977.

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

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

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

i) понятием «ментальная модель»;

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

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

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

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

Рабочий продукт понимается в настоящем стандарте как «артефакт, связанный с выполнением процесса» [ИСО/МЭК 15504-1:2004, пункт 3.55].

A.6 Связи

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 5 — ExecutesOn (R1) = {(e1, p1), (e1, p4), (e2, p2), (e2, p3), (e3, p3), (e4, p4)}.

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

Последняя версия (Представление — -Версия) = {(Представление1, Версия v2.0), (Представление2, Версия v2.0), (Представление3, Версия v2.0), (Представление4, Версия v2.0), (Представление5, Версия v2.0)}.

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

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

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

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

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

Примеры

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

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

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

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

РУКОВОДСТВО К ТОЧКАМ ЗРЕНИЯ НА АРХИТЕКТУРУ

B.1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

B.2.9 Примеры

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

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

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

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

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

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

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

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

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

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

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

• Eeles и Cripps, Процесс архитектуризации программных средств (The Process of Software Architecting) [8].

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

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

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

• Kruchten. «Модель представления архитектуры „4 + 1“ [23].»

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

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

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

C.1 Введение

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

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

C.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. Пример точки зрения для этой цели определен в C.2.2.

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

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

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

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

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

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

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

Программные средства декомпозируются в зависимые компоненты. Требования, распределенные по каждому объекту программных средств, далее распределяются по одному или более компонентам. Описания интерфейса обеспечиваются между программными компонентами, между программными компонентами и аппаратными объектами и объектами ручного оперирования. Это описано в терминах проектирования архитектуры программных средств (см. ИСО/МЭК 12207:2010, подпункт 7.1.3.3.1).

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

C.3.1 Общее

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

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

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

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

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

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

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

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

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

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

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

C.4.1 Общее

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

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

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

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

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

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

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

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

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

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

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

Примечания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

БИБЛИОГРАФИЯ