Всякий раз, когда множественные модели объекта разрабатываются, они могут оказаться несовместимыми. В описаниях архитектуры одним из последствий использования множественных представлений является потребность выражать и поддерживать согласованность между этими представлениями.
В 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]
