ГОСТ Р ИСО/МЭК 10165-7-2003. Национальный стандарт Российской Федерации. Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 7. Общая модель взаимосвязи

(утв. и введен в действие Постановлением Госстандарта России от 18.12.2003 № 367-ст)

Утвержден и введен в действие Постановлением Госстандарта России

ОКС 35.100.70

Предисловие

1 РАЗРАБОТАН Государственным научно-исследовательским и конструкторско-технологическим институтом «ТЕСТ» Министерства Российской Федерации по связи и информатизации

2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 18 декабря 2003 г. № 367-ст

3 Настоящий стандарт представляет собой аутентичный текст международного стандарта ИСО/МЭК 10165-7:1996 «Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 7. Общая модель взаимосвязи»

4 ВВЕДЕН ВПЕРВЫЕ

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

Настоящий стандарт содержит:

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

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

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

г) руководство по разработке формы заявки о соответствии;

д) примеры определений.

Модель общей взаимосвязи определена в разделе 7. Средства обозначения специфицированы в приложении A. Родовая информация административного управления определена в разделе 8 и приложении B. Руководство по спецификации формы заявки о соответствии реализации (ГОСТ Р ИСО/МЭК 9646-1) дано в приложениях C и D. Иллюстрация методов представления и примеры определений приведены в приложениях E и F соответственно. Комментарии к тексту стандарта включены в приложение G.

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

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

2 Нормативные ссылки

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

ГОСТ Р ИСО/МЭК 7498-1-99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 1. Базовая модель

ГОСТ Р ИСО/МЭК 7498-4-99 Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 4. Основы административного управления

ГОСТ Р ИСО/МЭК 8824-1-2001 Информационная технология. Абстрактная синтаксическая нотация версии 1 (АСН.1). Часть 1. Спецификация основной нотации

ГОСТ Р ИСО/МЭК 9595-99 Информационная технология. Взаимосвязь открытых систем. Определение общих услуг информации административного управления

ГОСТ Р ИСО/МЭК 9646-1-93 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 1. Общие принципы

ГОСТ Р ИСО/МЭК 9646-2-93 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 2. Спецификация комплекта абстрактных тестов

ГОСТ Р ИСО/МЭК 10040-99 Информационная технология. Взаимосвязь открытых систем. Общее описание административного управления систем

ГОСТ Р ИСО/МЭК 10164-2-99 Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 2. Функция административного управления состояниями

ГОСТ Р ИСО/МЭК 10165-1-2001 Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 1. Модель информации административного управления

ГОСТ Р ИСО/МЭК 10165-2-2001 Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 2. Определение информации административного управления

ГОСТ Р ИСО/МЭК 10165-4-2001 Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 4. Руководство по определению управляемых объектов

ГОСТ Р ИСО/МЭК 10165-6-2003 Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 6. Требования и руководство по формам заявки о соответствии реализации, относящейся к административному управлению ВОС

ИСО/МЭК 9646-7-95 <*> Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 7. Заявки о соответствии реализации

ИСО/МЭК 10164-3-93 <*> Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 3. Функции административного управления взаимоотношениями

ИСО/МЭК 10164-9-95 <*> Информационная технология. Взаимосвязь открытых систем. Административное управление систем. Часть 9. Объекты и атрибуты для управления доступом

<*> Оригиналы стандартов ИСО/МЭК — во ВНИИКИ Госстандарта России.

3 Определения

В настоящем стандарте используют следующие термины.

3.1 Определения административного управления

В настоящем стандарте применен следующий термин, определенный в ГОСТ Р ИСО/МЭК 7498-4, — управляемый объект.

3.2 Определения административного управления системы

В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10040:

• класс управляемых объектов;
• управляющий;
• заявка о соответствии управляемого объекта (ЗСУО);
• форма ЗСУО;
• сообщение;

- операция (административного управления системы).

3.3 Определения услуг общей информации административного управления

В настоящем стандарте используют следующий термин, определенный в ГОСТ Р ИСО/МЭК 9595, — атрибут.

3.4 Определения модели информации административного управления

В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10165-1:

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

- старший объект.

3.5 Определения руководства по определению управляемых объектов

В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10165-4:

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

- шаблон.

3.6 Определения требований и руководства по формам заявки о соответствии реализации, относящейся к административному управлению ВОС

В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10165-6:

• сводка соответствия административного управления (ССАУ);
• форма ССАУ;
• заявка об определении информации административного управления (ЗОИУ);

- форма ЗОИУ.

3.7 Определения функции административного управления состоянием

В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10164-2:

• административное состояние;
• рабочее состояние;

- состояние использования.

3.8 Дополнительные определения

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

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

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

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

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

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

3.8.6 участник: Управляемый объект, исполняющий роль в управляемой взаимосвязи.

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

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

3.8.9 ограничение кардинального числа взаимосвязи: Множество значений, которыми ограничивается кардинальное число взаимосвязи.

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

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

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

3.8.13 ограничение кардинального числа роли: Множество значений, которыми ограничено кардинальное число данной роли.

3.8.14 спецификация отображения взаимосвязи: Поименованная спецификация отображения характеристик класса управляемых взаимосвязей в характеристики одного или нескольких классов управляемых объектов.

3.8.15 спецификация класса взаимосвязей: Поименованная спецификация характеристик управляемой взаимосвязи.

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

3.8.17 развязывание: Отсоединение управляемого объекта от данной роли в управляемой взаимосвязи.

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

4 Сокращения

В настоящем стандарте используют следующие сокращения:

АСН.1 — абстрактная синтаксическая нотация версии 1 (ГОСТ Р ИСО/МЭК 8824-1);

ВОС — взаимосвязь открытых систем (ГОСТ Р ИСО/МЭК 7498-1);

ЗОИУ — заявка об определении информации административного управления;

ЗСУО — заявка о соответствии управляемого объекта;

МИУ — модель информации (административного) управления;

ОМВ — общая модель взаимосвязи;

РОУО — руководство по определению управляемых объектов;

СИУ — структура информации (административного) управления;

ССАУ — сводка соответствия административного управления;

УОИУ — услуги общей информации (административного) управления.

5 Соглашения

В настоящем стандарте использованы полужирный и курсивный шрифты для выделения текста, в котором используются нотации АСН.1 и РОУО или обозначения, определенные в приложении A.

Обозначения настоящего стандарта специфицированы в соответствии с соглашениями, определенными в ГОСТ Р ИСО/МЭК 10165-4.

6 Требования

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

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

7 Модель

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

а) управляемый объект должен оставаться в рабочем состоянии для исполнения роли поставщика в управляемой взаимосвязи поставщик — потребитель;

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

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

Управляемые взаимосвязи являются дополнительными информационными моделирующими понятиями в структуре информации административного управления, но представляются и управляются существующими конструкциями модели информации административного управления (см. ГОСТ Р ИСО/МЭК 10165-1). Управляемые взаимосвязи, соответствующие одному и тому же определению, группируются в классы управляемых взаимосвязей; обозначения для классов управляемых взаимосвязей определены в приложении A.

В модели специально подчеркивается, что один и тот же класс управляемых взаимосвязей может быть представлен в модели информации административного управления разными способами; отображение взаимосвязи описывает конкретное представление. Подробнее отображение взаимосвязи рассмотрено в 7.4. Обозначения для спецификации отображения взаимосвязи определены в приложении A.

7.1 Управляемые взаимосвязи

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

7.1.1 Операции и сообщения административного управления взаимосвязью

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

Семантика этих операций и сообщений приведена в разделе 8.

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

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

7.1.2 Поведение управляемой взаимосвязи

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

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

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

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

7.1.3 Уточнение взаимосвязи

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

7.1.4 Роли

Каждый управляемый объект, связанный в управляемой взаимосвязи, является участником и исполняет в ней одну или несколько ролей. Роль устанавливает требования для участника и управляемой взаимосвязи. Участвующий управляемый объект обязан иметь определенные свойства для исполнения роли; управляемая взаимосвязь обязана подчиняться требованиям роли.

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

7.1.4.1 Свойства участника

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

<*> Понятие совместимости рассмотрено в МИУ (ГОСТ Р ИСО/МЭК 10165-1, 5.2)

7.1.4.2 Кардинальное число роли

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

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

7.1.4.3 Поддержка связывания и развязывания

Управляемая взаимосвязь на протяжении своего существования может поддерживать связывание (роль с ролью) и развязывание управляемых объектов. Такая управляемая взаимосвязь поддерживает операции административного управления взаимосвязью BIND и UNBIND.

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

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

7.1.4.4 Кардинальное число взаимосвязи

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

7.2 Отображения взаимосвязи

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

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

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

7.2.1 Указатели участников

Участники управляемой взаимосвязи и соответствующие им роли могут быть идентифицированы с помощью атрибутов «указатель участника». Значение атрибута «указатель участника» идентифицирует участвующий(е) управляемый(е) объект(ы), а тип атрибута указывает роль, исполняемую объектом(ами). Изменение значений этого атрибута операциями, ориентированными на атрибут или на объект, может использоваться для изменения участия управляемого объекта во взаимосвязи с учетом всех ограничений, относящихся к конкретной управляемой взаимосвязи или ее отображению. Определения указателей участников выводятся из определения атрибута participantPointer в приложении B.

7.2.2 Операции и сообщения административного управления взаимосвязью

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

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

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

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

7.2.3 Поведение

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

7.3 Неоднократно используемые спецификации

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

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

7.4 Представление и административное управление взаимосвязями

Управляемые взаимосвязи могут быть представлены следующими методами, основанными на определенных в МИУ (ГОСТ Р ИСО/МЭК 10165-1) конструкциях:

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

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

7.4.1 Представление и административное управление с помощью наименования

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

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

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

7.4.2 Представление и административное управление с помощью указателей участников

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

7.4.3 Представление и административное управление с помощью объекта взаимосвязи

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

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

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

в) «отображение взаимосвязи», который идентифицирует действующее отображение взаимосвязи.

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

У genericRelationshipObject имеется атрибутивная группа relationships (см. ИСО/МЭК 10164-3). Все атрибуты «указатель участника» могут быть включены в эту группу.

Операции административного управления взаимосвязью отображаются в ориентированные на объекты или атрибуты операции административного управления системы над объектом взаимосвязи. Возможные отображения приведены в таблице 3; отображения для конкретного представления моделируются ассоциированным отображением взаимосвязи.

Таблица 3

7.4.4 Представление и административное управление с помощью операций административного управления системы

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

8 Родовые определения

В настоящем стандарте определена семантика родовой информации административного управления и прототипы операций и сообщений административного управления взаимосвязью. Формальная спецификация синтаксиса родовой информации административного управления приведена в приложении B.

8.1 Операции и сообщения административного управления взаимосвязью

8.1.1 ESTABLISH

8.1.2 TERMINATE

8.1.3 BIND

8.1.4 UNBIND

8.1.5 QUERY

8.1.6 NOTIFY

8.1.7 Определенная пользователем

В настоящем стандарте семантика этого прототипа не устанавливается.

8.2 Класс управляемых объектов genericRelationshipObject

Все классы объектов взаимосвязи должны специализироваться из genericRelationshipObject, который содержит атрибуты relationshipMapping, relationshipClass и relationshipName. Класс объектов взаимосвязи для конкретного класса взаимосвязей должен для каждой роли, определенной в классе управляемых взаимосвязей, включать в себя атрибут, полученный из атрибута PARTICIPANTPOINTER.

8.3 Связывание имен genericRelationshipObject-system

Это связывание имен должно использоваться для наименования объектов взаимосвязей относительно управляемого объекта «система», используя атрибут relationshipName

8.4 Атрибуты

8.4.1 Атрибут relationshipName

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

8.4.2 Атрибут relationshipClass

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

8.4.3 Атрибут relationshipMapping

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

8.4.4 Атрибут participantPointer

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

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

8.5 Атрибутивная группа relationships

Эта атрибутивная группа определена в ИСО/МЭК 10164-3 и должна использоваться для объединения всех атрибутов «указатель участника».

8.6 Параметры

8.6.1 Параметр noSuchObject

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

8.6.2 Параметр roleCardinalityViolation

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

8.6.3 Параметр roleInstanceConflict

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

8.6.4 Параметр relationshipCardinalityViolation

Эта специфическая ошибка должна использоваться для сигнала о том, что операция связывания или развязывания административного управления взаимосвязью нарушила бы ограничение кардинального числа взаимосвязи. Значением этого параметра должно быть null.

A.1 Шаблон класса взаимосвязей

A.1.1 Обзор

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

а) наследование взаимосвязи;

б) уточнение взаимосвязи;

в) поведение взаимосвязи;

г) совместимость роли;

д) ограничения кардинального числа роли;

е) поддержку связывания и развязывания;

ж) ограничения кардинального числа взаимосвязи.

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

<метка-поведения>

<метка-класса>

<метка-атрибута>

идентификатор-объекта

указание-типа

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

идентификатор.

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

A.1.1.1 Наследование

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

A.1.1.2 Уточнение взаимосвязи

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

A.1.1.3 Поведение

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

A.1.1.4 Роли

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

A.1.1.5 Идентификатор класса управляемой взаимосвязи

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

A.1.2 Структура шаблона

A.1.3 Вспомогательные определения

A.1.3.1 DERIVED FROM <метка-класса-взаимосвязей> [ , <метка-класса-взаимосвязей> ] *

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

Спецификация характеристик, которые наследуются от других классов управляемых взаимосвязей, не должна повторяться в спецификации подкласса, если только не используется один из описанных в ГОСТ Р ИСО/МЭК 10165-4 методов для расширения унаследованной от суперкласса спецификации.

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

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

б) QUALIFIED BY: множества допустимых и обязательных значений диапазонов атрибутов не должны изменяться в подклассе.

в) BEHAVIOUR: поведение подкласса должно быть:

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

г) ROLE

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

Класс управляемых объектов, введенный в подклассе разделом COMPATIBLE-WITH, должен быть совместим <*> с классами, указанными в аналогичных разделах суперкласса(ов).

<*> Понятие совместимости рассмотрено в ГОСТ Р ИСО/МЭК 10165-1, 5.2.

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

Унаследованное значение REQUIRED-ROLE-CARDINALITY-CONSTRAINT роли, унаследованной от нескольких суперклассов, должно быть объединением множеств значений, заданных для роли в суперклассах, пересеченным с унаследованными ограничениями допустимых кардинальных чисел роли; любое ограничение множества обязательных кардинальных чисел роли, установленное в подклассе, должно быть подмножеством унаследованных ограничений обязательных кардинальных чисел роли (или должно ему равняться); специализированное ограничение обязательных кардинальных чисел роли должно быть объединением унаследованных значений и значений, специфицированных в подклассе, пересечением со специализированным ограничением допустимых кардинальных чисел роли.

В спецификации подкласса может быть добавлено BIND-SUPPORT.

В спецификации подкласса может быть добавлено UNBIND-SUPPORT.

Унаследованное значение PERMITTED-RELATIONSHIP-CARDINALITY-CONSTRAINT роли, унаследованной от нескольких суперклассов, должно быть пересечением множеств значений, заданных для роли в суперклассах; любое ограничение допустимых кардинальных чисел взаимосвязи, установленное в подклассе, должно быть подмножеством унаследованных ограничений кардинальных чисел взаимосвязей (или должно ему равняться); специализированное ограничение допустимых кардинальных чисел взаимосвязи должно быть пересечением множеств унаследованных значений и значений, специфицированных в подклассе.

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

A.1.3.2 BEHAVIOUR <метка-поведения> [ , <метка-поведения> ] *

Эта конструкция должна использоваться для спецификации независящего от представления поведения управляемой взаимосвязи. Оно должно быть установлено в терминах инварианта управляемой взаимосвязи, инварианта, пред- и постусловий сообщений и операций административного управления взаимосвязью. Конструкция ссылается на шаблоны поведения, как определено в ГОСТ Р ИСО/МЭК 10165-4.

A.1.3.3 SUPPORTS поддерживается [ , поддерживается ]*

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

• ESTABLISH [имя-операции],
• TERMINATE [имя-операции],
• QUERY [имя-операции],
• NOTIFY [имя-сообщения],
• USER DEFINED [имя-операции].

При необходимости имя-операции и имя-сообщения должны использоваться для:

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

A.1.3.4 QUALIFIED BY <метка-атрибута> [ , <метка-атрибута> *

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

A.1.3.5 ROLE имя-роли

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

A.1.3.5.1 COMPATIBLE-WITH <метка-класса>

Эта конструкция должна использоваться для спецификации характеристик, необходимых управляемому объекту для выполнения требований роли; характеристики должны быть заданы в терминах совместимых <*> классов управляемых объектов. Если эта конструкция отсутствует, то принимаются характеристики высшего класса (ГОСТ Р ИСО/МЭК 10165-2). Спецификация роли не зависит от метода представления.

<*> Понятие совместимости рассмотрено в ГОСТ Р ИСО/МЭК 10165-1, 5.2.

A.1.3.5.2 PERMITTED-ROLE-CARDINALITY-CONSTRAINT указание-типа

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

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

Если множество значений содержит 0, то роль является факультативной; однако факультативность роли не подразумевает поддержку операций связывания и развязывания. Если ограничение отсутствует, то по умолчанию должно использоваться унаследованное ограничение допустимых кардинальных чисел роли; если никакое ограничение не наследуется, то в качестве ограничения принимается множество значений INTEGER (O..MAX).

Множество значений PERMITTED-ROLE-CARDINALITY-CONSTRAINT должно быть супермножеством значений REQUIRED-ROLE-CARDINALITY-CONSTRAINT или должно равняться ему.

A.1.3.5.3 REQUIRED-ROLE-CARDINALITY-CONSTRAINT указание-типа

Эта конструкция должна использоваться для спецификации любых ограничений на количество управляемых объектов, которое управляемая взаимосвязь обязана поддерживать в указанной роли. Ограничение должно быть задано в терминах множества значений подтипа неотрицательных целых АСН.1. Например, если ограничение задает множество значений INTEGER (1, 3, 4), то управляемая взаимосвязь обязана поддерживать в данной роли один, три или четыре управляемых объекта, но не обязана поддерживать два или более четырех управляемых объектов. Реализация обязана соблюдать это ограничение.

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

Множество значений REQUIRED-ROLE-CARDINALITY-CONSTRAINT должно быть подмножеством значений PERMITTED-ROLE-CARDINALITY-CONSTRAINT или должно равняться ему.

A.1.3.5.4 BIND-SUPPORT [имя-операции]

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

При необходимости имя-операции должно использоваться для:

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

A.1.3.5.5 UNBIND-SUPPORT [имя-операции]

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

При необходимости имя-операции должно использоваться для:

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

A.1.3.5.6 PERMITTED-RELATIONSHIP-CARDINALITY-CONSTRAINT указание-типа

Эта конструкция должна использоваться для спецификации любых ограничений на число взаимосвязей данного класса, в которых может участвовать управляемый объект в данной роли. Ограничение должно быть задано в терминах множества значений подтипа неотрицательных целых АСН.1. Например, если ограничение задает множество значений INTEGER (0..3), то управляемому объекту разрешено участвовать в данной роли не более чем в трех экземплярах данного класса управляемых взаимосвязей. Реализация обязана соблюдать это ограничение. Если эта конструкция отсутствует, то по умолчанию должно использоваться унаследованное ограничение допустимых кардинальных чисел взаимосвязи; если никакое ограничение не наследуется, то в качестве ограничения принимается множество значений INTEGER (0..MAX).

A.1.3.5.7 REGISTERED AS идентификатор-объекта

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

A.1.3.6 REGISTERED AS идентификатор-объекта

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

A.2 Шаблон отображения взаимосвязи

A.2.1 Обзор

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

а) поведение отображения взаимосвязи;

б) объекты взаимосвязи;

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

г) методы представления;

д) уточняющие атрибуты;

е) отображения операций и сообщений.

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

В шаблоне отображения взаимосвязи используется следующее вспомогательное определение АСН.1:

идентификатор

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

A.2.1.1 Поведение

Шаблон отображения взаимосвязи специфицирует любое поведение, которое является особенностью определенного в шаблоне метода представления.

A.2.1.2 Методы представления

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

A.2.1.3 Роли

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

A.2.2 Структура шаблона

A.2.3 Вспомогательные определения

A.2.3.1 RELATIONSHIP CLASS <метка-класса-взаимосвязей>

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

A.2.3.2 BEHAVIOUR <метка-поведения> [ , <метка-поведения>] *

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

A.2.3.3 RELATIONSHIP OBJECT <метка-класса> [QUALIFIES <метка-атрибута> [ , <метка-атрибута>] *

Эта конструкция присутствует в шаблоне, который специфицирует представление управляемой взаимосвязи с использованием объекта взаимосвязи. <метка-класса> должна использоваться для указания класса объекта взаимосвязи; в фактической реализации класс объекта взаимосвязи должен быть классом, который указывает <метка-класса>, или его подклассом. Класс управляемых объектов, на который указывает <метка-класса>, должен быть подклассом genericRelationshipObject и иметь атрибуты указателей участников для каждой роли, заданной в соответствующем шаблоне класса управляемых взаимосвязей.

Конструкция QUALIFIES <метка-атрибута> [ , <метка-атрибута> ] * должна использоваться для спецификации уточняющих взаимосвязь атрибутов, определенных в указанном шаблоне класса взаимосвязей, которые должны быть реализованы объектом взаимосвязи.

A.2.3.4 ROLE имя-роли RELATED-CLASSES <метка-класса> [<метка-класса>] * [REPRESENTED-BY представление][QUALIFIES <метка-атрибута> [<метка-атрибута> ] * ]

Эта конструкция должна использоваться для идентификации классов-кандидатов управляемых объектов, указываемых конструкцией <метка-класса> [<метка-класса> ] *, которые могут исполнять роль, указанную именем-роли. Роль должна быть одной из специфицированных в указанном шаблоне класса управляемых взаимосвязей; классы должны быть совместимыми с указанными в разделе COMPATIBLE WITH указанного шаблона класса взаимосвязей. Для роли в экземпляре указанного класса управляемых взаимосвязей, использующего это отображение, допустимы только управляемые объекты классов, заданных в конструкции <метка-класса> [<метка-класса> ] *, и их подклассов.

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

• NAMING <метка-связывания-имен> USING старшийИлиПодчиненный: роль, указанная именем-роли, должна быть представлена объектом класса SURERIOR OBJECT CLASS или SUBORDINATE OBJECT CLASS, указанным в связывании имен <метка-связывания-имен>; раскрытие вспомогательной продукции старшийИлиПодчиненный (SURERIOR или SUBORDINATE) должно указывать на SURERIOR OBJECT CLASS или SUBORDINATE OBJECT CLASS соответственно;
• ATTRIBUTE <метка-атрибута>: тип атрибута, на который ссылается <метка-атрибута>, должен указывать роль; значение атрибута должно специфицировать участника(ов), исполняющего(их) эту роль;
• RELATIONSHIP-OBJECT-USING-POINTER <метка-атрибута>: тип атрибута, на который ссылается <метка-атрибута>, должен указывать роль; значение атрибута должно специфицировать участника(ов), исполняющего(их) эту роль;
• OPERATION: отображение операций административного управления взаимосвязью в операции административного управления системы должно быть специфицировано в конструкции OPERATIONS MAPPING.

Конструкция QUALIFIES <метка-атрибута> [<метка-атрибута>] * идентифицирует атрибуты уточнения взаимосвязи, определенные в указанном шаблоне класса взаимосвязей, которые должны быть реализованы указанными классами управляемых объектов.

A.2.3.5 OPERATIONS MAPPING операция-взаимосвязи отображается-в [ , операция-взаимосвязи отображается-в ] *

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

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

• ESTABLISH [имя-операции],
• TERMINATE [имя-операции],
• BIND [имя-операции] [имя-роли],
• UNBIND [имя-операции] [имя-роли],
• QUERY [имя-операции] [имя-роли],
• NOTIFY [имя-сообщения],
• USER DEFINED [имя-операции].

Заданное [имя-операции] или [имя-сообщения] должно быть одним из определенных в соответствующем шаблоне класса управляемых взаимосвязей и образовывать, при необходимости, связь между семантикой операций и сообщений административного управления взаимосвязью и их представлением в терминах операций и сообщений административного управления системы. Когда управляемая взаимосвязь определяет только одну роль, спецификация имя-роли является факультативной.

Вспомогательное определение отображается-в специфицирует следующую продукцию:

• MAPS-TO-OPERATION операция-управления-системы OF роль-или-объектВзаимосвязи

[операция-управления-системы OF роль-или-объектВзаимосвязи] *

Вспомогательное определение операция-управления-системы специфицирует выбор одной из следующих продукций, каждая из которых указывает соответствующую(ее) операцию (или сообщение) административного управления системы и относящуюся к ней (к нему) информацию административного управления системы; [<метка-параметра>] должна использоваться для спецификации любых параметров, которые должны быть связаны с операцией или сообщением административного управления системы:

• GET <метка-атрибута> [<метка-параметра>] *: атрибут, указанный <меткой-атрибута>, должен специфицировать, значение какого атрибута должно быть возвращено;
• REPLASE <метка-атрибута> [<метка-параметра>] *: атрибут, указанный <меткой-атрибута>, должен специфицировать, значение какого атрибута должно быть заменено;
• ADD <метка-атрибута> [<метка-параметра>] *: атрибут, указанный <меткой-атрибута>, должен специфицировать атрибут, к которому должно быть добавлено значение;
• REMOVE <метка-атрибута> [<метка-параметра>] *: атрибут, указанный <меткой-атрибута>, должен специфицировать атрибут, из которого должно быть исключено значение;
• GREATE [<метка-класса>] [<метка-параметра>] *: класс, указанный <меткой-класса>, должен специфицировать класс, к которому относится создаваемый управляемый объект;
• DELETE [<метка-параметра>] *;
• ACTION <метка-действия> [<метка-параметра>] *: действие, указанное <меткой-действия>, должно специфицировать производимое действие;
• NOTIFICATION <метка-сообщения> [<метка-параметра>] *: сообщение, указанное <меткой-сообщения>, должно специфицировать создаваемое сообщение.

Вспомогательное определение роль-или-объектВзаимосвязи специфицирует целевые или исходные управляемые объекты для указанное операции административного управления системы. Допустим выбор одной из следующих продукций, которая должна использоваться для спецификации либо управляемого объекта, играющего указанную в <имени-роли> роль, либо объект взаимосвязи соответственно:

• имя-роли,
• RELATIONSHIP-OBJECT.

A.2.3.6 REGISTERED AS идентификатор-объекта

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

B.1 Присвоение идентификаторов объектов

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

B.2 Определение классов управляемых объектов

B.3 Определение связывания имен

B.4 Определение атрибутов

B.5 Определение параметров

B.6 Определения абстрактных синтаксисов

Форма заявления о соответствии управляемой взаимосвязи (ЗСУВ) <*>

<*> Форма ЗСУВ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить и использовать эту форму.

C.1 Введение

Целью формы настоящего приложения является обеспечение такого руководства по форме заявления о соответствии управляемой взаимосвязи (ЗСУВ), что поставщик реализации, заявляющий о соответствии классу управляемых взаимосвязей, может предоставить информацию о соответствии в стандартном виде. Определенная в настоящем приложении форма является дополнением к форме, определенной в ГОСТ Р ИСО/МЭК 10165-6.

C.2 Инструкции по заполнению формы ЗСУВ

Приведенная в настоящем приложении форма ЗСУВ содержит информацию в табличном виде. Поставщик реализации должен отметить поддерживаемые позиции в таблицах C.1 - C.3 и, при необходимости, предоставить дополнительную информацию.

C.3 Символы, сокращения и термины

В столбцах статуса используются следующие общие обозначения, определенные в ГОСТ Р ИСО/МЭК 9646-2:

о — обязательно;

ф — факультативно;

у — условно;

x — запрещено;

• не применяется.

В столбцах обеспечения используются следующие общие обозначения, определенные в ГОСТ Р ИСО/МЭК 9646-2 и ИСО/МЭК 9646-7:

Д — реализовано;

Н — не реализовано;

• ответ не требуется;

Иг — Позиция игнорируется (т.е. обрабатывается синтаксически, но не семантически).

C.4 Обеспечение управляемой взаимосвязи

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

Таблица C.1 — Поддержка управляемой взаимосвязи

C.4.1 Поддержка роли

Для каждой роли, идентифицированной в отображении управляемой взаимосвязи, поставщик реализации должен указать поддержку, используя таблицу C.2.

Таблица C.2 — Поддержка ролей

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

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

Поставщик реализации должен указать поддерживаемые параметры, если они есть, специфицированные в шаблоне отображения взаимосвязи, используя таблицы поддержки параметров, приведенные в приложении D.

Таблица C.3 — Поддержка операций и сообщений административного управления взаимосвязью

C.4.2 Поддержка объекта взаимосвязи

Поставщик реализации должен указать поддержку класса объектов взаимосвязи, если он есть, специфицированного в шаблоне отображения взаимосвязи, используя форму ЗСУО, определенную в ГОСТ Р ИСО/МЭК 10165-6, и форму ЗОИУ, определенную в приложении D. Класс объектов взаимосвязи должен быть подклассом genericRelationshipObject.

Приложение D (обязательное)

Форма ЗОИУ (атрибутов) <*>

<*> Форма ЗОИВ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить и использовать эту форму.

D.1 Введение

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

D.2 Атрибуты

Таблица D.1 (продолжение) — Поддержка атрибутов

D.3 Параметры

См. таблицу D.2.

Таблица D.2 — Поддержка параметров

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

В настоящем приложении приведена графическая интерпретация компоновки и использования шаблонов класса и отображения взаимосвязи (см. рисунки E.1 и E.2).

- шаблон или вспомогательная продукция	CAPS — ключевое слово
- строка, подставляемая пользователем	{имя} — вариант ключевого слова

Приведенные в настоящем приложении примеры предназначены для иллюстрации понятий, идентифицированных в данном стандарте, и использования нотаций шаблонов RELATIONSHIP CLASS и RELATIONSHIP MAPPING. Эти примеры не дают определений, которые обязательно должны использоваться в реализациях.

F.1 Присвоение идентификаторов объектов

F.2 Пример симметричной взаимосвязи

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

F.2.1 Определение класса симметричных взаимосвязей

ESTABLISH establishSymmetricRelationship

TERMINATE terminateSymmetricRelationship

F.2.2 Симметричная взаимосвязь, представленная объектом взаимосвязи

F.3 Пример взаимосвязи зависимости

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

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

• родитель;
• сын;
• дочь.

F.3.1 Определение класса взаимосвязей зависимости

ESTABLISH establishDependency

BIND bindDependent

UNBIND unbindDependent

TERMINATE terminateDependency

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

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

Операции административного управления взаимосвязью ESTABLISH establishDependency и BIND bindDependent отображаются в создание участника в зависимой роли: различие состоит в том, что операция административного управления взаимосвязью ESTABLISH establishDependency используется, когда участник является первым, исполняющим зависимую роль, а операция административного управления взаимосвязью BIND bindDependent используется, когда в это время связан по крайней мере один участник в этой роли. После создания объекта класса bPerson с атрибутом parent, идентифицирующем объект класса aPerson, значение атрибута dependents объекта класса aPerson идентифицирует соответствующий объект класса bPerson.

Аналогично операции административного управления взаимосвязью TERMINATE terminate Dependency и UNBIND unbindDependent отображаются в удаление участника в зависимой роли: различие состоит в том, что операция административного управления взаимосвязью TERMINATE terminateDependency используется, только когда имеется только один участник, исполняющий зависимую роль, а операция административного управления взаимосвязью UNBIND unbindDependent используется, когда в момент удаления имеется несколько участников, исполняющих эту роль. При удалении объекта класса bPerson, играющего зависимую роль dependentRole, значение атрибута dependents объекта класса aPerson, играющего родительскую роль parentRole, изменяется: из него удаляется идентификация соответствующего объекта класса bPerson.

Операция административного управления QUERY queryDependents отображается в операцию GET атрибута dependents в объекте aPerson, играющем родительскую роль parentRole; операция административного управления QUERY queryParent отображается в операцию GET атрибута parent в объекте bPerson, играющем зависимую роль dependentRole.

Создание класса управляемых объектов bPerson (или его подкласса) приводит к установлению экземпляра взаимосвязи зависимости с отображением dependencyAttributeRepresentation RELATIONSHIP MAPPING, где значение атрибута parent в объекте bPerson устанавливается-при-создании равным экземпляру класса управляемых объектов aPerson, а атрибут dependents в объекте aPerson является непустым множеством.

Удаление управляемого объекта bPerson (или его подкласса) приводит к отвязыванию его от экземпляра зависимости взаимосвязи с отображением dependencyAttributeRepresentation RELATIONSHIP MAPPING, когда значение атрибута dependents в объекте aPerson остается непустым после удаления, и к соответствующему обновлению атрибута dependents.

Удаление управляемого объекта bPerson (или его подкласса) приводит к завершению экземпляра зависимости взаимосвязи с отображением dependencyAttributeRepresentation RELATIONSHIP MAPPING, когда значение атрибута dependents в объекте aPerson остается пустым после удаления, и к соответствующему обновлению атрибута dependents. «;»

F.3.3 Класс взаимосвязей зависимости, представленный с помощью объекта взаимосвязи

Это представление взаимосвязи зависимости использует объект взаимосвязи для представления экземпляра взаимосвязи и для связи участников. Операция административного управления взаимосвязью ESTABLISH establishDependency отображается в операцию создания CREATE объекта dependencyRelationshipObject, а операция административного управления взаимосвязью TERMINATE terminateDependency — в операцию удаления DELETE объекта dependencyRelationshipObject. Операция административного управления взаимосвязью BIND bindDependent отображается в операцию ADD над атрибутом dependents объекта dependencyRelationshipObject. Операция административного управления взаимосвязью UNBIND unbindDependent отображается в операцию REMOVE над атрибутом dependents объекта dependencyRelationshipObject.

Создание объекта dependencyRelationshipObject приводит к установлению взаимосвязи зависимости с dependencyRelationshipObject RELATIONSHIP MAPPING. Так как родительская роль не является динамической (т.е. для родительской роли не определены BIND-SUPPORT и UNBIND-SUPPORT), то атрибут parent в dependencyRelationshipObject должен быть установлен-при-создании равным ровно одному экземпляру объекта person, исполняющему parentRole роль; значение атрибута parent не может быть изменено во время операций зависимости.

Добавление значения, представляющего объект person, к атрибуту dependents объекта dependencyRelationshipObject приводит к связыванию объекта person с взаимосвязью, соответствующей объекту dependencyRelationshipObject, в роли dependentRole.

Удаление значения, представляющего объект person, из атрибута dependents объекта dependencyRelationshipObject приводит к отвязыванию объекта person от взаимосвязи, соответствующей объекту dependencyRelationshipObject.

Удаление объекта dependencyRelationshipObject приводит к завершению взаимосвязи зависимости с dependencyObjectRepresentation RELATIONSHIP MAPPING. «;»

F.3.4 Класс взаимосвязей зависимости, представленный с помощью наименования

Это представление взаимосвязи зависимости использует наименование для представления экземпляра взаимосвязи.

Операции административного управления взаимосвязью ESTABLISH establishDependency и BIND bindDependent отображаются в создание объекта-участника person (или его подкласса) в роли dependentRole, использующего связывание имен с объектом cPerson (или его подкласса) в качестве старшего объекта в роли parentRole. Различие между операциями состоит в следующем: операция административного управления взаимосвязью ESTABLISH establishDependency используется, когда предлагаемый участник в зависимой роли будет первым объектом в этой роли; операция административного управления взаимосвязью BIND bindDependent используется, когда на момент создания имеется по крайней мере один другой участник в зависимой роли.

Аналогично операции административного управления взаимосвязью TERMINATE terminateDependency и UNBIND unbindDependent отображаются в удаление участника в зависимой роли, а различие между ними состоит в том, что операция административного управления взаимосвязью TERMINATE terminateDependency используется, если участник является единственным исполняющим роль dependentRole, а операция административного управления взаимосвязью UNBIND unbind Dependent используется, если после удаления остается по крайней мере один участник, исполняющий зависимую роль.

Операция административного управления взаимосвязью QUERY queryDependents отображается в получение атрибута nameBinding с уровнем области действия объекта person в родительской роли для определения содержащихся в нем объектов person, которые имеют значение атрибута связывания имен, равное aNameBinding; такие объекты играют зависимые роли.

Операция административного управления взаимосвязью QUERY queryParent отображается в получение атрибута nameBinding подчиненного объекта для определения того, что его значение атрибута связывания имен равно aNameBinding; последующий анализ ООИ имени подчиненного объекта даст указание на родительский объект.

Создание управляемого объекта person (или его подкласса) в качестве подчиненного объекту cPerson (или его подкласса) со связыванием имен aNameBinding приводит к установлению экземпляра взаимосвязи зависимости с отображением dependencyNamingRepresentation RELATIONSHIP MAPPING, если нет других подчиненных объектов с этим связыванием имен.

Создание управляемого объекта person (или его подкласса) в качестве подчиненного объекту cPerson (или его подкласса) со связыванием имен aNameBinding приводит к привязыванию созданного объекта к взаимосвязи зависимости с отображением dependencyNamingRepresentation RELATIONSHIP MAPPING, если имеется по крайней мере один подчиненный объект с этим связыванием имен.

Удаление управляемого объекта person (или его подкласса), связанного в зависимой роли взаимосвязи зависимости с отображением dependencyNamingRepresentation RELATIONSHIPMAPPING, приводит к отвязыванию удаляемого объекта от этой зависимости, если после удаления будет существовать по крайней мере один другой зависимый объект со связыванием имен aNameBinding.

Удаление управляемого объекта person (или его подкласса), связанного в зависимой роли взаимосвязи зависимости с отображением dependencyNamingRepresentation RELATIONSHIP MAPPING, приводит к завершению этой зависимости, если после удаления не будет существовать других зависимых объектов со связыванием имен aNameBinding. « ;»

F.4 Пример родовой взаимосвязи композиции

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

ESTABLISH establishGeneralComposition

BIND bindComponent

UNBIND unbindComponent

TERMINATE terminateGeneralComposition

F.4.1 Подкласс родовой взаимосвязи композиции

Этот класс взаимосвязей уточняет, что обязательное кардинальное число роли компонентов класса generalCompositionRelationship должно находиться в диапазоне 1 — 5; все другие характеристики этого класса взаимосвязей наследуются от класса generalCompositionRelationship. « ; ;»

F.5 Пример области управления доступом

Этот класс взаимосвязей связывает управляемые объекты, которые являются субъектами управления доступом (memberObjectRole), с управляемыми объектами, представляющими функции принудительного доступа (aefRole) и функции решения о доступе (adfRole). « ; ;»

F.5.1 Взаимосвязь области управления доступом, представленная с помощью атрибутов и наименования

В данном отображении класса управляемых взаимосвязей accessControlDomain класс accessControlDomain (подкласс класса accessControlRules) участвует в роли adfRole, а класс notificationEmitter — в роли aefRole; любой управляемый объект может участвовать в роли memberObjectRole. Атрибут memberObjectAttribute в accessControlDomainObject идентифицирует участников в роли memberObjectRole, а связывание имен notificationEmitter-accessControlRules содержит участников в роли aefRole в пределах участника в роли adfRole.

Операция административного управления взаимосвязью QUERY queryAccessControlDomain отображается в две операции, а именно:

а) операцию GET над memberObjectAttribute объекта, исполняющего роль adfRole

б) с последующей операцией GET над атрибутом nameBinding с областью действия на уровне объекта, играющего роль adfRole, для определения содержащихся объектов, которые имеют значение атрибута связывания имен, равное «ITU-T Rec.X.741 | ISO/IEC 10164-9»: notificationEmitter-accessControlRules.»; ;

Членство в области управления доступом идентифицируются и изменяется операциями над атрибутом memberObjectAttribute. « ; ;»

ATTRIBUTES memberObjectAttribute GET-REPLACE ADD-REMOVE; ; ;

REGISTERED AS {GRMExample.grmEx-Object accessControlDomainObjectArc(1)} ;

F.5.2 Взаимосвязь области управления доступом, представленная с помощью объекта взаимосвязи

В данном отображении класса управляемых взаимосвязей accessControlDomain класс accessControlRules участвует в роли adfRole, а класс notificationEmitter — в роли aefRole; любой управляемый объект может участвовать в роли memberObjectRole. Взаимосвязь представляется объектом класса accessControlDomainCoordinator (подкласса genericRelationshipObject), используя атрибуты memberObjectAttribute, aefAttribute и adfAttribute.

Операция административного управления взаимосвязью QUERY queryAccessControlDomain отображается в три операции GET над объектом взаимосвязи, а именно:

а) GET memberObjectAttribute;

б) GET aefAttribute;

в) GET adfAttribute. «; ;»

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

КОММЕНТАРИИ

G.1 Введение

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

G.2 Зависимость между управляемыми объектами в управляемой взаимосвязи

Вопрос. Суть ОМВ состоит в том, что управляемые объекты, участвующие во взаимосвязи, влияют друг на друга; это выражается как инвариант свойств участников. Как этот инвариант должен быть специфицирован?

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

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

G.3 Согласованность представлений

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

Комментарий. К фундаментальным концепциям ОМВ относится то, что семантика управляемой взаимосвязи согласованно выражена в элементах реализации; другими словами, взаимосвязь управляет представлением. Таким образом, если в отображении взаимосвязи выбрано представление семантики участия управляемых объектов в виде сопряженных указателей в участвующих объектах, то реализация должна гарантировать, что указатели всегда будут согласованными. Более того, если в отображении взаимосвязи выбрано представление операции BIND в виде направленной на атрибуты операции addOperation для одного из пары сопряженных указателей участников, то требуется, чтобы реализация устанавливала другой указатель для поддержания согласованности. ОМВ только устанавливает требования к согласованности информации; она не специфицирует механизмы поддержания согласованности ни в единой управляемой системе, ни между несколькими управляемыми системами.

G.4 Выражение операций и сообщений административного управления взаимосвязью

Вопрос. Как выражаются операции и сообщения административного управления взаимосвязью и как они отображаются в операции административного управления системы?

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

G.5 Родовое управление

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

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

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

G.6 Осознание взаимосвязи

Вопрос. Как управляемый объект «узнает», что он находится в управляемой взаимосвязи?

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

G.7 Спецификация роли

Вопрос. Может ли роль быть специфицирована отдельно?

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

G.8 Повторно используемые спецификации

Вопрос. Повторно используемые спецификации являются важным моментом административного управления ВОС; как это реализовано в ОМВ?

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

G.9 AND SUBCLASSES

Вопрос. Раздел AND SUBCLASSES не выносится из шаблона связывания имен РОУО во вспомогательную продукцию role-mapping-specification шаблона RELATIONSHIP MAPPING.

Комментарий. Способность подкласса поддерживать роль рассматривается как фундаментальное свойство управляемого объекта и должно наследоваться безусловно.

G.10 Взаимосвязь между взаимосвязями

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

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

G.11 Область действия имен объектов взаимосвязей

Вопрос. Какой должна быть область действия имен объектов взаимосвязей?

Комментарий. Шла дискуссия относительно наименования всех объектов взаимосвязей управляемой системы в области действия единственного объекта конкретного класса, часто называемого классом якорного объекта, в частности, имея в виду возможность обнаружения всех объектов взаимосвязей в управляемой системе с помощью области действия УОИУ. Результатом этой дискуссии было заключение: так как существующие стандарты административного управления рассматривают структуру наименования как локальный вопрос, то было бы несоответствием со стороны ОМВ предписывать конкретную структуру.

G.12 Допустимые методы представления

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

Комментарий. Нет; для некоторых методов представления внутренне ограничены типы взаимосвязей, которые они могут представить. В таблице G.1 приведены типы взаимосвязей, которые могут быть представлены различными методами.