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

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

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

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

Концептуальные основы настоящего стандарта не предполагают ни одного из этих модельных представлений; стандарт оптимально работает с любым из них. Существование этих множественных модельных представлений поддерживает центральный проектный принцип настоящего стандарта: архитектура неотъемлемо основана на множественных заинтересованных сторонах с множественными интересами в системе [из А.2 Системы и архитектура ГОСТ Р 57100–2016]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В приложениях В и С приведена дополнительная информация и ссылки, имеющие отношение к точкам зрения на архитектуру [из А.4 Архитектурное представление и точки зрения на архитектуру ГОСТ Р 57100–2016]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример 5 – ExecutesOn (R1) = {(е1, р1), (е1, р4), (е2, р2), (е2, рЗ), (еЗ, рЗ), (е4, р4)}.

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

Последняя версия (Представление – Версия) = {(Представление1, Версия v2.0), (Представление2, Версия v2.0), (ПредставлениеЗ, Версия v2.0), (Представление4, Версия v2.0), (Представление6, Версия V2.0)} [из А.6 Связи ГОСТ Р 57100–2016]