ГОСТ Р 57100—2016
У этого утверждения есть два важных следствия:
1) У каждой модели есть объект.
2) Модель может быть:
I) понятием «ментальная модель»;
ii) рабочим продуктом.
В настоящем стандарте термин «модель» использован двумя способами. Во-первых, в его обычном языко
вом смысле, как это объяснено выше. Во-вторых, в специальном смысле для определения основной части про
цесса архитектуриэации, воплощенной в термине «архитектурная модель» (см. 5.6).
В первом смысле термина существует несколько видов моделей, связанных с процессом архитектуриэации,
которые описаны в настоящем стандарте. Различие между 2i)и2)1)крайне важно для понимания в настоящем стан
дарте разницы между архитектурой иописанием архитектуры. В смысле 2I) архитектура — это концепция системы (т.
е ментальная модель), полезная для ответов на некоторые вопросы об этой системе. В смысле 2II)существует три
вида моделей, определенных в настоящем стандарте, реализуемых как рабочие продукты:
- описание архитектуры — это рабочий продукт, который моделирует архитектуру рассматриваемой систе
мы: его объект, отражающий вопросы определенных заинтересованных сторон обо всех определенных интересах
системы;
- архитектурное представление — это рабочий продукт; его объект — это специальное множество инте
ресов заинтересованной стороны, структурируемых главной точкой зрения.
- архитектурная модель — это рабочий продукт; его объект определяется с помощью его вида модели.
Рабочий продукт понимается в настоящем стандарте как «артефакт, связанный с выполнением процесса»
(ИСО/МЭК 15504-1.2004. пункт 3.55).
А.6 Связи
Всякий раз. когда множественные модели объекта разрабатываются, они могут оказаться несовместимыми.
В описаниях архитектуры одним из последствий использования множественных представлений является потреб
ность выражать и поддерживать согласованность между этими представлениями.
В ИИРЭ1471:2000 эта потребностьанализируется втерминахтребований, авыявленные несогласованности
регистрируются черезпредставления описаний архитектуры (см. 5.7.1). Втовремя не былоникакой известнойпрак
тики для систематизации согласно стандарту для выражения или предписания такой согласованности.
Настоящий стандарт вводит связи для выражения отношений между элементами описания архитектуры. У
связей имеется ряд применений. Они могут бытьприменены для выражения согласованности, прослеживаемости,
композиции, уточнения и преобразования моделей или зависимости любого типа, охватывающего более чем один
вид модели. В (2) приведен обзор применений отношений моделей совместно с таксономией и классификацией
механизмов отношения. Связи могут использоваться для удовлетворения требованиям (см. 5.7.1) по регистрации
согласованности и несогласованностей в представлении.
В конце настоящего подраздела представлены примеры связей и правил связи. Рассмотрены характеристи
ки механизма связи относительно подобных механизмов, описанных в литературе. Пример 1. приведенный ниже,
представляет простую модельную связь.
Пример 1— Рассматривает два представления системы S: представление аппаратных средств
HW (S) и представление компонента программных средств SC (S). Учитывая, что SC (S) включает
элементы программных средств. е1. ... еб. и HW ($) включает платформы аппаратных средств.
(Элемент) ExecutesON-
-Выполняется на (Платформе)
См. Правило: R1
е1р1,р4
е2р2, рЗ
еЗ
рЗ
еЛр4
Рисунок А.1 — Пример связи
19