ГОСТ Р ИСО/МЭК 10165-6-2003
Группа П85
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ
СТРУКТУРА ИНФОРМАЦИИ АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ
Часть 6
Требования и руководство по формам заявки о соответствии реализации,
относящейся к административному управлению ВОС
Information technology. Open Systems Interconnection.
Structure of management information. Part 6. Requirements
and guidelines for implementation conformance statement
proformas associated with OSI management
ОКС 35.100.70
ОКСТУ 4002
Дата введения 2004-07-01
Предисловие
1 РАЗРАБОТАН Государственным научно-исследовательским и конструкторско-технологическим институтом "ТЕСТ" Министерства Российской Федерации по связи и информатизации
ВНЕСЕН Министерством Российской Федерации по связи и информатизации
2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 18 декабря 2003 г. N 367-ст
3 Настоящий стандарт представляет собой аутентичный текст международного стандарта ИСО/МЭК 10165-6:1997 "Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 6. Требования и руководство по формам заявки о соответствии реализации, относящейся к административному управлению ВОС"
4 ВВЕДЕН ВПЕРВЫЕ
1 Область применения
Настоящий стандарт предоставляет требования и руководство для форм сводки соответствия административного управления (ССАУ), заявки о соответствии информации административного управления (ЗСИУ), заявки о соответствии управляемого объекта (ЗСУО), заявки об определении информации административного управления (ЗОИУ), заявки о соответствии управляемой взаимосвязи (ЗСУВ) и для спецификации этих форм. Эти формы применимы для стандартов по административному управлению ВОС, включая определения управляемых объектов. Форма ССАУ предоставляет сводку форм ЗСРП, ЗСИУ, ЗСУО и ЗСУВ. ЗСРП является заявлением разработчика о соответствии спецификации протокола. ЗСИУ является заявлением разработчика о соответствии информации административного управления в роли управляющего. ЗСУО является заявлением разработчика о соответствии определению класса управляемых объектов. ЗСУВ является заявлением разработчика о соответствии определению управляемой взаимосвязи такой, как определение связывания имен.
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 Информационная технология. Взаимосвязь открытых систем. Общее описание административного управления систем
ГОСТ Р ИСО/МЭК 10165-1-2001 Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 1. Модель информации административного управления
ГОСТ Р ИСО/МЭК 10165-4-2001 Информационная технология. Взаимосвязь открытых систем. Структура информации административного управления. Часть 4. Руководство по определению управляемых объектов
ИСО/МЭК 9646-7-95* Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования. Часть 7. Заявки о соответствии реализации
_____________________
* Оригиналы стандартов ИСО/МЭК - во ВНИИКИ Госстандарта России.
3 Определения
В настоящем стандарте используют следующие термины.
3.1 Определения АСН.1
В настоящем стандарте используют следующий термин, определенный в ГОСТ Р ИСО/МЭК 8824-1, - идентификатор объекта.
3.2 Определения административного управления
В настоящем стандарте используют следующий термин, определенный в ГОСТ Р ИСО/МЭК 7498-4, - управляемый объект.
3.3 Определения методологии аттестационного тестирования
В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 9646-1:
- заявка о соответствии реализации протоколу (ЗСРП);
- форма ЗСРП;
- заявка о соответствии системы.
3.4 Определения административного управления системы
В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10040:
- класс управляемых объектов;
- заявка о соответствии управляемого объекта (ЗСУО);
- заявка о соответствии информации административного управления (ЗСИУ);
- форма ЗСИУ;
- форма ЗСУО;
- сообщение.
3.5 Определения услуг общей информации административного управления
В настоящем стандарте используют следующий термин, определенный в ГОСТ Р ИСО/МЭК 9595, - атрибут.
3.6 Определения модели информации административного управления
В настоящем стандарте используют следующие термины, определенные в ГОСТ Р ИСО/МЭК 10165-1:
- действие;
- фактический класс;
- атрибутивная группа;
- поведение;
- характеристика;
- условный пакет;
- реализация;
- связывание имен;
- пакет;
- параметр;
- суперкласс;
- нереализуемый класс управляемых объектов.
3.7 Определения руководства по определению управляемых объектов
В настоящем стандарте используют следующий термин, определенный в ГОСТ Р ИСО/МЭК 10165-4, - шаблон.
3.8 Определения заявки о соответствии реализации
В настоящем стандарте используют следующие термины, определенные в ИСО/МЭК 9646-7:
- позиция (ЗСР);
- вопрос (ЗСР);
- статус (значение);
- ответ (обеспечение).
3.9 Дополнительные определения
В настоящем стандарте используют следующие термины с соответствующими определениями:
3.9.1 заявка о соответствии управляемой взаимосвязи (ЗСУВ):
Заявление поставщика реализации управляемой взаимосвязи о реализованных свойствах и факультативных возможностях, а также о тех характеристиках, которые были опущены.
3.9.2 сводка соответствия административного управления (ССАУ):
Заявление поставщика, идентифицирующее реализацию и предоставляющее информацию о том, что реализация заявляет о соответствии перечисленному набору документов, которые специфицируют требования соответствия административному управлению ВОС.
3.9.3 форма заявки об определении информации административного управления (ЗОИУ): Документ в форме вопросника, который используется для построения формы ЗСУО.
3.9.4 форма ССАУ: Документ в форме вопросника, который после заполнения поставщиком реализации становится ССАУ.
3.9.5 форма ЗСУВ: Документ в форме вопросника, который после заполнения поставщиком реализации становится ЗСУВ.
3.9.6 спецификация формы: Стандартизированные процедуры построения вопросника, который после заполнения поставщиком становится заявлением о соответствии реализации.
4 Сокращения
В настоящем стандарте используют следующие сокращения:
АСН. 1 - абстрактная синтаксическая нотация версии 1;
ВОС - взаимосвязь открытых систем;
РОУО - руководство по определению управляемых объектов.
5 Требования и руководства по спецификации и заполнению форм
Спецификации форм должны следовать стилю, приведенному в приложениях к настоящему стандарту. Спецификации форм должны предоставлять информацию, требуемую настоящим стандартом. В случае необходимости для дополнительной информации в формы могут быть включены другие таблицы.
5.1 Структура форм
В приложениях к настоящему стандарту специфицированы форматы форм ССАУ, ЗСИУ, ЗСУО, ЗОИУ и ЗСУВ для связывания имен. Таким образом, спецификации форм обеспечиваются приложениями к настоящему стандарту. Форма ЗОИУ используется для построения формы ЗСУО. Поставщик реализации заполняет на бланке эти формы для получения ССАУ, ЗСИУ, ЗСУО, ЗОИУ и ЗСУВ для связывания имен. Кроме того, настоящий стандарт специфицирует формат формы ЗСУВ для связывания имен и то, что должно быть подытожено в форме ССАУ.
Установлены три уровня документов, относящихся к ССАУ, а именно:
а) средства руководств и стандартов для создания форм ССАУ;
б) форма ССАУ, связанная со стандартом, относящимся к административному управлению ВОС, которая должна быть заполнена поставщиком реализации, и после заполнения является ССАУ - см. ниже перечисление в):
в) ССАУ, подготовленная поставщиком реализации как часть заявления о соответствии стандартам, относящимся к административному управлению ВОС.
Перечисление а) является предметом настоящего стандарта. Предполагается, что формы ССАУ перечисления б) будут создаваться в соответствии со спецификацией формы ССАУ настоящего стандарта.
Установлены три уровня документов, относящихся к ЗСИУ, а именно:
а) средства руководств и стандартов для создания форм ЗСИУ;
б) форма ЗСИУ, связанная со стандартом, относящимся к административному управлению ВОС, которая должна быть заполнена поставщиком реализации, и после заполнения является ЗСИУ - см. ниже перечисление в);
в) ЗСИУ, подготовленная поставщиком реализации как часть заявления о соответствии стандартам, относящимся к административному управлению ВОС.
Перечисление а) является предметом настоящего стандарта. Предполагается, что формы ЗСИУ перечисления б) будут создаваться в соответствии со спецификацией формы ЗСИУ настоящего стандарта.
Аналогично установлены три уровня документов, относящихся к ЗСУО, а именно:
а) средства руководств и стандартов для создания форм ЗСУО;
б) форма ЗСУО, связанная с определением класса управляемых объектов, которая должна быть заполнена поставщиком реализации, и после заполнения является ЗСУО - см. ниже перечисление в);
в) ЗСУО, подготовленная поставщиком реализации как часть заявления о соответствии определению класса управляемых объектов.
Перечисление а) является предметом настоящего стандарта. Предполагается, что формы ЗСУО перечисления б) будут создаваться в соответствии со спецификацией формы ЗСУО настоящего стандарта. Для нереализуемых классов управляемых объектов не требуется форма ЗСУО.
Кроме того, установлены два уровня документов, относящихся к ЗОИУ, а именно:
а) средства руководств и стандартов для создания форм ЗОИУ;
б) форма ЗОИУ, которая используется для построения формы ЗСУО. Перечисление а) является предметом настоящего стандарта.
Предполагается, что формы ЗОИУ перечисления б) будут создаваться в соответствии со спецификацией формы ЗОИУ настоящего стандарта.
Установлены три уровня документов, относящихся к ЗСУВ для связывания имен, а именно:
а) средства руководств и стандартов при создании форм ЗСУВ для связывания имен;
б) форма ЗСУВ для связывания имен, относящаяся к определению связывания имен, которая должна быть заполнена поставщиком реализации, и после заполнения является ЗСУВ для связывания имен - см. ниже перечисление в);
в) ЗСУВ для связывания имен, подготовленная поставщиком реализации как часть заявления о соответствии определению связывания имен.
Перечисление а) является предметом настоящего стандарта. Предполагается, что формы ЗСУВ для связывания имен из перечисления б) будут создаваться в соответствии со спецификацией формы ЗСУВ для связывания имен настоящего стандарта.
5.2 Общие инструкции
Настоящий стандарт предоставляет инструкции для создания спецификаций форм ССАУ, ЗСИУ, ЗСУО, ЗОИУ и ЗСУВ для связывания имен. Приложения к настоящему стандарту содержат спецификации форм ССАУ, ЗСИУ, ЗСУО, ЗОИУ и ЗСУВ для связывания имен в табличном виде, в котором используются колонки статуса и обеспечения, а также нотация для заполнения этих колонок, определенная в ГОСТ Р ИСО/МЭК 9646-2.
Назначением форм ССАУ, ЗСИУ, ЗСУО, ЗОИУ и ЗСУВ для связывания имен является обеспечение метода, посредством которого поставщик реализации, включающей в себя административное управление ВОС, может предоставить информацию о соответствии в стандартном виде. Приложения А-R предоставляют руководства по спецификации форм.
Приложение А содержит форму для форм ССАУ. Приложение В содержит форму для форм ЗСУО. Приложения С-F содержат формы для форм ЗОИУ для атрибутов, атрибутивных групп, действий и сообщений, соответственно. Приложение G содержит форму для форм ЗСУВ для связывания имен. Приложения Н-L содержат форму для форм ЗСИУ для атрибутов, атрибутивных групп, действий, сообщений и создания/удаления соответственно. Приложение М содержит дополнительные указания по спецификации форм. Приложение N содержит дополнительные указания по заполнению форм. В приложении О приведен пример спецификации формы ССАУ, которая должна быть заполнена поставщиком реализации. В приложении Р приведен пример спецификации формы ЗСИУ. В приложении Q приведен пример спецификации формы ЗСУО, которая должна быть заполнена поставщиком реализации. В приложении R приведен пример спецификации формы ЗСУВ для связывания имен, которая должна быть заполнена поставщиком реализации.
В колонке значения статуса используется следующая общая нотация, определенная в ГОСТ Р ИСО/МЭК 9646-2 и ИСО/МЭК 9646-7:
о - обязательно,
ф - факультативно,
у - условно,
х - запрещено,
- не применяется или не рассматривается.
Примечания
1 Обозначения "у", "о", "ф" и "х" дополняются префиксом "у: ", когда являются вложенными в условную или факультативную позицию той же самой таблицы.
2 Обозначение "ф" может иметь суффикс ".n" (где "n" - уникальный номер) для кратных взаимоисключающих или выборочных опций из набора значений статуса. Требования для этого перенумерованного набора должны быть установлены явным образом, желательно в сноске к соответствующей таблице.
В колонке ответа об обеспечении используется следующая общая нотация, определенная в ГОСТ Р ИСО/МЭК 9646-2 и ИСО/МЭК 9646-7:
Д - реализовано,
Н - не реализовано,
- ответ не требуется,
И - позиция игнорируется (т.е. обрабатывается синтаксически, но не семантически).
В колонке статуса должны быть установлены статические требования. Статус имеет следующие значения:
о - для характеристик, содержащихся в обязательных пакетах или в условных пакетах, если условие РОУО всегда выполняется;
ф - для характеристик условных пакетов с условиями РОУО, которые указывают статический выбор, например "если реализация это обеспечивает";
уn - для всех условий, где "n" - уникальное целое число, а "уn" - ссылка на выражение условного статуса, определенная в ГОСТ Р ИСО/МЭК 9646-2 и ИСО/МЭК 9646-7. (Одна из возможных форм этого выражения условного статуса использует ответ на текстовый вопрос такой, как "Допускает ли реализация создание при {условии РОУО}?". Однако если может использоваться более точная нотация, то использование такой нотации не рекомендуется);
х - для характеристик, явно запрещенных в определении;
- для характеристик, которые не упоминаются в определении.
Когда статус для условного пакета равен или разрешается до "о", характеристики пакета должны быть реализованы; характеристики реализуются в соответствии с динамическими правилами, установленными в связанном с пакетом условии РОУО.
Колонки "Ограничения и значения" таблиц в приложениях (которые должны быть заполнены в спецификации формы) содержат ограничения и значения конкретной информации административного управления (например, связывания имен, атрибута, атрибутивной группы, действия, поля действия, сообщения и поля сообщения).
Колонки "Дополнительная информация" таблиц в приложениях (которые должны быть заполнены поставщиком реализации) содержат дополнительную информацию, необходимую при использовании таблиц, относящуюся к обеспечению конкретной информации административного управления (например, связывания имен, атрибута, атрибутивной группы, действия, поля действия, сообщения и поля сообщения). Эта информация может включать в себя:
а) любые ограничения, относящиеся к обеспечению информации административного управления;
б) конкретные обеспечиваемые значения;
в) информацию для ссылки на атрибуты, атрибутивные группы, действия и сообщения других ЗСУО, заполненных поставщиком реализации;
г) отображение значений информации административного управления (доступных на границе управляемого объекта) в значения, видимые другим интерфейсам с нижележащим ресурсом (абстракциями которых является информация административного управления);
д) пояснения, как удовлетворяются ограничения;
е) обеспечиваемые параметры;
ж) информацию, достаточную для ссылки на детали параметра(ов), если конкретный(е) параметр(ы) передается(ются) в поле действия или сообщения;
и) специфичные для реализации ограничения допустимых, обязательных и принимаемых по умолчанию значений и правила согласования для атрибутов;
к) специфичные для реализации ограничения допустимых и обязательных значений аргументов действий и сообщений;
л) идентификацию классов объектов, для которых обеспечивается операция административного управления (это относится к формам ЗСИУ);
м) любые ограничения поддержки для отображения операций административного управления на протокольные взаимодействия (это относится к формам ЗСИУ);
н) условия, при которых в ответ на получение сообщений осуществляются операции и предпринимаются действия (это относится к формам ЗСИУ).
Когда заявляется, что информация административного управления, доступная на границе управляемого объекта, соответствует информации, доступной через другой интерфейс, тогда одним из следующих способов должно быть указано, как связаны между собой эти два значения информации административного управления:
а) путем спецификации стандартов и указания в подстрочных примечаниях к позиции формы, а следовательно, как часть того, что поставщик реализации указывает как поддерживаемое при заполнении колонки обеспечения;
б) требованиями/рекомендациями стандартов, задаваемых поставщиком реализации; в таких случаях форма включает в себя подстрочное примечание к позиции, в которой поставщик реализации должен или может указать детали доступности в колонке "Дополнительная информация";
в) оставлено неопределенным в спецификации формы и поставщиком реализации.
Терминология, обозначения и понятия утверждений о соответствии установлены в ГОСТ Р ИСО/МЭК 9646-1, ГОСТ Р ИСО/МЭК 9646-2 и ИСО/МЭК 9646-7. Таблицы должны предоставлять подробности составных параметров до уровня детализации, исключающего двусмысленность в обеспечении подпараметров. Когда размер формы превышает размер страницы, таблица может быть представлена на развороте или разделена на несколько частей. Руководство по разделению таблиц приведено в приложении Н.
5.3 Инструкции по спецификации формы ССАУ
ССАУ идентифицирует реализацию и содержит сводку ЗСРП, ЗСУО и ЗСУВ, в которых заявляется о соответствии. Форма ССАУ создается путем копирования спецификации формы ССАУ из приложения А и расширения таблицы А.4; эта операция может включать в себя объединение информации из нескольких других форм ССАУ, несколько форм ССАУ могут быть объединены в одну форму (например, при построении формы на основе нескольких документов). Для охвата любых общих требований соответствия в спецификации рекомендуется включать в форму ССАУ дополнительные таблицы. Руководство по использованию этих дополнительных таблиц дано в приложении О.
Спецификация формы должна иметь колонки "Статус" для всех сводных таблиц, заполненные в соответствии с требованиями базовых спецификаций. Колонка "Статус" в этих сводных таблицах обеспечения используется для указания, обязан ли поставщик реализации заполнять указанные таблицы или позиции. Подробные требования соответствия специфицируются в указанных таблицах или позициях и не зависят от значения сводной колонки "Статус". При создании ССАУ из формы ССАУ поставщик реализации должен предоставить соответствующую информацию в выделенных для этого местах и заполнить колонки "Обеспечение" и, если нужно, "Дополнительная информация" в сводной таблице формы ССАУ. Поставщик реализации также должен привести номера заполненных таблиц, которые соответствуют номерам таблиц идентифицированного исходного документа, если эти номера различаются.
Инструкции по спецификации формы ЗСРП даны в ГОСТ Р ИСО/МЭК 9646-2. Инструкции по спецификации формы ЗСУО даны в 5.4, а ЗСУВ - в 5.6.
5.4 Инструкции по спецификации формы ЗСУО
Спецификация формы ЗСУО создается путем копирования приложения В, заполнения таблиц, за исключением колонок "Обеспечение" и "Дополнительная информация", и расширения таблиц для удовлетворения требованиям спецификации. ЗСУО для нескольких классов управляемых объектов не должны документироваться в одном и том же приложении, так как таблицы для каждого класса непрерывны и отделены от таблиц для других классов. Форма ЗСУО должна предоставлять таблицы для всех атрибутов, атрибутивных групп, действий, сообщений и параметров, которые входят в определение класса управляемых объектов, как полученных от суперклассов, так и добавленных при уточнении. Информация в форме ЗСУО получается из базовых стандартов, формы ЗОИУ и других форм ЗСУО. Инструкции по спецификации формы ЗОИУ приведены в 5.5.
Для создания ЗСУО из формы ЗСУО поставщик реализации должен заполнить колонки "Статус" и, при необходимости, "Дополнительная информация" всех таблиц в форме ЗСУО.
а) Таблица обеспечения класса управляемых объектов - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона класса управляемых объектов) и 3 (Значение идентификатора объекта для класса управляемых объектов). Поставщик реализации должен отметить в колонке 4 (Обеспечение всех обязательных характеристик), обеспечиваются или нет обязательные характеристики идентифицированного класса управляемых объектов, а в колонке 5 - является ли фактический класс тем самым классом управляемых объектов, о соответствии которому заявляется. Если ответом на вопрос о фактическом классе является "нет", то поставщик реализации должен заполнить предоставляемую таблицу обеспечения фактического класса.
б) Таблица обеспечения атрибутов - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона атрибута), 3 (Значение идентификатора объекта для атрибута), 5 (Статус установки при создании), 7 (Статус Get), 9 (Статус Replace), 11 (Статус Add), 13 (статус Remove), 15 (Статус установки умолчания) и, при необходимости, 4 (Ограничения и значения). Если поведение управляемого объекта специфицирует, что при создании значение атрибута не может быть установлено или задано обязательное начальное значение, то в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "х". В противном случае, если атрибут заменяемый или поведение управляемого объекта специфицирует, что атрибут является устанавливаемым при создании, то в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "о". В противном случае, если в определении класса управляемых объектов не указывается, устанавливается ли атрибут при создании, то в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "-". В противном случае в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "ф" или "уn" в соответствии с определением класса управляемых объектов. Поставщик реализации должен указать, обеспечиваются ли атрибуты, специфицированные всеми реализуемыми пакетами в определении класса управляемых объектов, а также - обеспечение каждой операции для каждого поддерживаемого атрибута, дав ответы в колонках 6 (Обеспечение установки при создании), 8 (Обеспечение Get), 10 (Обеспечение Replace), 12 (Обеспечение Add), 14 (Обеспечение Remove), 16 (Обеспечение установки умолчания) и, при необходимости, 17 (Дополнительная информация).
в) Таблица обеспечения атрибутивных групп - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона атрибутивной группы), 3 (Значение идентификатора объекта для атрибутивной группы), 5 (Статус Get), 7 (Статус установки умолчания) и, при необходимости, 4 (ограничения и значения). Поставщик реализации должен указать, обеспечиваются ли атрибутивные группы, специфицированные всеми реализуемыми пакетами в определении класса управляемых объектов, а также, обеспечивается ли каждая операция для каждой поддерживаемой атрибутивной группы, дав ответы в колонках 6 (Обеспечение Get), 8 (Обеспечение установки умолчания) и, при необходимости, 9 (Дополнительная информация).
г) Таблица обеспечения действий - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона действия), 3 (Значение идентификатора объекта для типа действия), 5 (Статус), 8 (Подиндекс), 9 (Метка имени поля действия), 11 (Статус) и, при необходимости, 4 (Ограничения и значения) и 10 (Ограничения и значения). Для каждого действия спецификация формы должна в строках с подиндексами устанавливать требования к каждому аргументу действия. Поставщик реализации должен указать, обеспечиваются ли действия, специфицированные всеми реализуемыми пакетами в управляемых объектах данного класса, дав ответы в колонках 6 (Обеспечение), 12 (Обеспечение) и, при необходимости, 7 (Дополнительная информация) и 13 (Дополнительная информация).
д) Таблица обеспечения сообщений - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона сообщения), 3 (Значение идентификатора объекта для типа сообщения), 5 (Статус), 9 (Подиндекс), 10 (Метка имени поля сообщения), 11 (Значение идентификатора объекта типа атрибута, связанного с полем), 13 (Статус), и, при необходимости, 4 (Ограничения и значения) и 12 (Ограничения и значения). Для каждого сообщения спецификация формы должна в строках с подиндексами устанавливать требования к каждому аргументу сообщения. Поставщик реализации должен указать, обеспечиваются ли сообщения, специфицированные всеми реализуемыми пакетами в управляемых объектах данного класса, дав ответы в колонках 6 (Обеспечение подтверждаемое), 7 (Обеспечение неподтверждаемое), 12 (Обеспечение) и, при необходимости, 8 (Дополнительная информация) и 13 (Дополнительная информация).
е) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Поставщик реализации должен указать, обеспечиваются ли параметры, специфицированные всеми реализуемыми пакетами в управляемых объектах данного класса, дав ответы в колонках 6 (Обеспечение) и, при необходимости, 7 (Дополнительная информация).
5.5 Инструкции по спецификации формы ЗОИУ
Форма ЗОИУ устанавливается для того, чтобы гарантировать согласованное использование родовой информации административного управления, которая является общей для многих классов управляемых объектов. Форма ЗОИУ обеспечивает определения того, что спецификации ЗСУО импортируют для согласованности с документом, устанавливающим форму ЗОИУ.
Значения статусов, установленные в формах ЗОИУ, указывают на то, что должно обеспечиваться для согласованности с родовым определением. Эти требования могут быть только усилены (например, факультативное может стать обязательным) при импорте в конкретную форму ЗСУО.
Сама форма ЗОИУ не специфицирует полное утверждение о соответствии реализации и, следовательно, не может быть использована поставщиком реализации для заявления о соответствии.
Ниже даны инструкции по спецификации форм ЗОИУ.
5.5.1 Инструкции по спецификации формы ЗОИУ для атрибутов
а) Таблица обеспечения атрибутов - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона атрибута), 3 (Значение идентификатора объекта для атрибута), 5 (Статус установки при создании), 7 (Статус Get), 9 (Статус Replace), 11 (Статус Add), 13 (Статус Remove), 15 (Статус установки умолчания) и, при необходимости, 4 (Ограничения и значения). Если поведение управляемого объекта специфицирует, что при создании значение атрибута не может быть установлено или задано обязательное начальное значение, то в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "х". В противном случае, если атрибут заменяемый или поведение управляемого объекта специфицирует, что атрибут является устанавливаемым при создании, то в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "о". В противном случае, если в определении класса управляемых объектов не указывается, устанавливается ли атрибут при создании, то в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "-". В противном случае в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "ф" или "уn" в соответствии с определением класса управляемых объектов. Прочие колонки остаются незаполненными.
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Прочие колонки остаются незаполненными.
5.5.2 Инструкции по спецификации формы ЗОИУ для атрибутивных групп
а) Таблица обеспечения атрибутивных групп - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона атрибутивной группы), 3 (Значение идентификатора объекта для атрибутивной группы), 5 (Статус Get), 7 (Статус установки умолчания) и, при необходимости, 4 (Ограничения и значения). Прочие колонки остаются незаполненными.
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Прочие колонки остаются незаполненными.
5.5.3 Инструкции по спецификации формы ЗОИУ для действий
а) Таблица обеспечения действий - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона действия), 3 (Значение идентификатора объекта для типа действия), 5(Статус), 8 (Подиндекс), 9 (Метка имени поля действия), 11 (Статус) и, при необходимости, 4 (Ограничения и значения) и 10 (Ограничения и значения). Для каждого действия спецификация формы должна в строках с подиндексами устанавливать требования к каждому аргументу действия. Прочие колонки остаются незаполненными.
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Прочие колонки остаются незаполненными.
5.5.4 Инструкции по спецификации формы ЗОИУ для сообщений
а) Таблица обеспечения сообщений - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона сообщения), 3 (Значение идентификатора объекта для типа сообщения), 5 (Статус), 9 (Подиндекс), 10 (Метка имени поля сообщения), 11 (Значение идентификатора объекта типа атрибута, связанного с полем), 13 (Статус) и, при необходимости, 4 (Ограничения и значения) и 12 (Ограничения и значения). Для каждого сообщения спецификация формы должна в строках с подиндексами устанавливать требования к каждому аргументу сообщения. Прочие колонки остаются незаполненными.
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметров), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Прочие колонки остаются незаполненными.
5.6 Инструкции по спецификации формы ЗСУВ для связывания имен
Спецификация формы ЗСУВ для связывания имен создается путем копирования приложения G, заполнения таблиц, за исключением колонок "Обеспечение" и "Дополнительная информация", и расширения таблиц для удовлетворения требованиям спецификации.
При создании ЗСУВ для связывания имен из формы ЗСУВ поставщик реализации должен заполнить колонки "Статус" и, при необходимости, "Дополнительная информация" всех таблиц в форме ЗСУВ.
а) Таблица обеспечения связываний имен - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона связывания имен), 3 (Значение идентификатора объекта для связывания имен), 5 (Статус), 8 (Подиндекс), 11 (Статус) и, при необходимости, 4 (Ограничения и значения) и 10 (Ограничения и значения). Поставщик реализации должен указать, какие связывания имен обеспечиваются. Для этого он должен заполнить колонки 6 (Обеспечение), 12 (Обеспечение) и, при необходимости, 7 (Дополнительная информация) и 13 (Дополнительная информация).
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения).
5.7 Инструкции по спецификации формы ЗСИУ
Форма ЗСИУ специфицируется с целью детально документировать требования соответствия к реализации роли управляющего и позволить поставщику реализации заявить о соответствии спецификации роли управляющего.
Значения статуса в формах ЗСИУ указывают, что необходимо обеспечить для соответствия спецификации.
Ниже даны инструкции по спецификации форм ЗСИУ.
5.7.1 Инструкции по спецификации формы ЗСИУ для атрибутов
Спецификация формы ЗСИУ для атрибутов создается путем копирования приложения Н, заполнения таблиц, за исключением колонок "Обеспечение" и "Дополнительная информация", и расширения таблиц для удовлетворения требованиям спецификации.
При создании ЗСИУ для атрибутов из формы ЗСИУ поставщик реализации должен заполнить колонки "Статус" и, при необходимости, "Дополнительная информация" всех таблиц в форме ЗСИУ.
а) Таблица обеспечения атрибутов - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона атрибута), 3 (Значение идентификатора объекта для атрибута), 5 (Статус установки при создании), 7 (Статус Get), 9 (Статус Replace), 11 (Статус Add), 13 (Статус Remove), 15 (Статус установки умолчания) и, при необходимости, 4 (Ограничения и значения).
Если поведение управляемого объекта специфицирует, что при создании значение атрибута не может быть установлено или задано обязательное начальное значение, то в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "х". В противном случае в спецификации формы для статуса в колонке "Статус установки при создании" должно быть задано "о", "ф" или "уn" согласно требованиям соответствия спецификации. Прочие колонки в форме ЗСИУ остаются незаполненными.
При создании ЗСИУ из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки 6, 8, 10, 12, 14, 16 (Обеспечение) и, при необходимости, 17 (Дополнительная информация). Дополнительная информация должна использоваться для указания любых ограничений в заявленном обеспечении операций, ориентированных на атрибуты.
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Прочие колонки в форме ЗСИУ остаются незаполненными.
При создании ЗСИУ из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки 6 (Обеспечение) и, при необходимости, 7 (Дополнительная информация).
5.7.2 Инструкции по спецификации формы ЗСИУ для атрибутивных групп
Спецификация формы ЗСИУ для атрибутивных групп создается путем копирования приложения I, заполнения таблиц, за исключением колонок "Обеспечение" и "Дополнительная информация", и расширения таблиц для удовлетворения требованиям спецификации.
При создании ЗСИУ для атрибутивных групп из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки "Статус" и, при необходимости, "Дополнительная информация" всех таблиц в форме ЗСИУ.
а) Таблица обеспечения атрибутивных групп - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона атрибутивной группы), 3 (Значение идентификатора объекта для атрибутивной группы), 5 (Статус Get), 7 (Статус установки умолчания) и, при необходимости, 4 (Ограничения и значения). Прочие колонки в форме ЗСИУ остаются незаполненными.
При создании ЗСИУ из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки 6, 8 (Обеспечение) и, при необходимости, 9 (Дополнительная информация). Дополнительная информация должна использоваться для указания любых ограничений в заявленном обеспечении операций, относящихся к атрибутивным группам.
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Прочие колонки в форме ЗСИУ остаются незаполненными.
При создании ЗСИУ из соответствующей формы СЗИУ поставщик реализации должен заполнить колонки 6 (Обеспечение) и, при необходимости, 7 (Дополнительная информация).
5.7.3 Инструкции по спецификации формы ЗСИУ для действий
Спецификация формы ЗСИУ для действий создается путем копирования приложения J, заполнения таблиц, за исключением колонок "Обеспечение" и "Дополнительная информация", и расширения таблиц для удовлетворения требованиям спецификации.
При создании ЗСИУ для действий из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки "Статус" и, при необходимости, "Дополнительная информация" всех таблиц в форме ЗСИУ.
а) Таблица обеспечения действий - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона действия), 3 (Значение идентификатора объекта для типа действия), 5 (Статус), 8 (Подиндекс), 9 (Метка имени поля действия), 11 (Статус) и, при необходимости, 4 (Ограничения и значения) и 10 (Ограничения и значения). Для каждого действия спецификация формы должна в строках с подиндексами устанавливать требования к каждому аргументу действия. Прочие колонки в форме ЗСИУ остаются незаполненными.
При создании ЗСИУ из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки 6, 12 (Обеспечение) и, при необходимости, 7, 13 (Дополнительная информация). Дополнительная информация должна использоваться для указания любых ограничений в заявленном обеспечении действий.
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Прочие колонки в форме ЗСИУ остаются незаполненными.
При создании ЗСИУ из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки 6 (Обеспечение) и, при необходимости, 7 (Дополнительная информация).
5.7.4 Инструкции по спецификации формы ЗСИУ для сообщений
Спецификация формы ЗСИУ для сообщений создается путем копирования приложения К, заполнения таблиц, за исключением колонок "Обеспечение" и "Дополнительная информация", и расширения таблиц для удовлетворения требованиям спецификации.
При создании ЗСИУ для сообщений из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки "Статус" и, при необходимости, "Дополнительная информация" всех таблиц в форме ЗСИУ.
а) Таблица обеспечения сообщений - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона сообщения), 3 (Значение идентификатора объекта для типа сообщения), 5 (Статус), 9 (Подиндекс), 10 (Метка имени поля сообщения), 11 (Значение идентификатора объекта типа атрибута, связанного с полем), 13 (Статус) и, при необходимости, 4 (Ограничения и значения) и 12 (Ограничения и значения). Для каждого сообщения спецификация формы должна в строках с подиндексами устанавливать требования к каждому аргументу сообщения. Прочие колонки в форме ЗСИУ остаются незаполненными.
При создании ЗСИУ из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки 6, 7, 14 (Обеспечение) и, при необходимости, 8, 15 (Дополнительная информация). Дополнительная информация должна использоваться для указания любых ограничений в заявленном обеспечении сообщений.
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Прочие колонки в форме ЗСИУ остаются незаполненными.
При создании ЗСИУ из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки 6 (Обеспечение) и, при необходимости, 7 (Дополнительная информация).
5.7.5 Инструкции по спецификации формы ЗСИУ для обеспечения создания и удаления
Спецификация формы ЗСИУ для создания и удаления получается путем копирования приложения L, заполнения таблиц, за исключением колонок "Обеспечение" и "Дополнительная информация", и расширения таблиц для удовлетворения требованиям спецификации.
При получении ЗСИУ для создания и удаления из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки "Статус" и, при необходимости, "Дополнительная информация" всех таблиц в форме ЗСИУ.
а) Таблица обеспечения создания и удаления - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Операция) - копируется из шаблона формы в приложении L, 4 (Статус) и, при необходимости, 3 (Ограничения и значения). Ограничения и значения могут быть использованы, например, для указания того, какие классы объектов требуется обеспечить.
Поставщик реализации должен заявить об обеспечении создания и удаления и заполнить колонки 5 (Обеспечение) и, при необходимости, 6 (Дополнительная информация). Дополнительная информация должна использоваться для указания любых ограничений в заявленном обеспечении операций создания и удаления. Поставщик реализации может использовать эту колонку для указания обеспечения установки конкретных атрибутов при создании, например, атрибута nameBinding и сослаться на таблицу атрибутов, где сделано заявление об обеспечении установки при создании.
б) Таблица обеспечения параметров - Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона параметра), 3 (Значение идентификатора объекта для параметра), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Прочие колонки в форме ЗСИУ остаются незаполненными.
При создании ЗСИУ из соответствующей формы ЗСИУ поставщик реализации должен заполнить колонки 6 (Обеспечение) и, при необходимости, 7 (Дополнительная информация).
6 Согласованность
Для согласованности с настоящим стандартом рекомендации и стандарты, устанавливающие требования соответствия для определений классов управляемых объектов, должны:
- содержать или ссылаться на форму ССАУ, построенную согласно 5.3;
- устанавливать, что реализации, заявляющие в ССАУ о соответствии определению класса управляемых объектов, должны сопровождать ее ЗСУО, которая получена в результате заполнения формы ЗСУО для этого класса управляемых объектов, построенной согласно 5.4.
Для согласованности с настоящим стандартом рекомендации и стандарты, устанавливающие требования соответствия для информации административного управления, должны:
- содержать или ссылаться на форму ЗОИУ, построенную согласно 5.5;
- устанавливать, что спецификации требований соответствия для определений классов управляемых объектов, которые используют эту информацию административного управления, должны включать требования формы ЗОУИ в формы ЗСУО для этих классов управляемых объектов.
Для согласованности с настоящим стандартом рекомендации и стандарты, устанавливающие требования соответствия для определений связывания имен, должны:
- содержать или ссылаться на форму ССАУ, построенную согласно 5.3;
- устанавливать, что реализации, заявляющие в ССАУ о соответствии определению связывания имен, должны сопровождать ее ЗСУВ, которая получена в результате заполнения формы ЗСУВ для этого определения связывания имен, построенной согласно 5.6.
ПРИЛОЖЕНИЕ А
(обязательное)
Форма ССАУ*
_________________
* Форма ССАУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ССАУ.
А.1 Введение
А.1.1 Назначение и структура
Сводка соответствия административного управления (ССАУ) является заявлением поставщика о том, чем идентифицирована реализация, и предоставляет информацию о ее соответствии набору перечисленных документов, устанавливающих требования соответствия административному управлению ВОС.
А.1.2 Инструкции по заполнению формы ССАУ для получения ССАУ
Поставщик реализации должен явным образом проставить ответы в каждой из оставленных для этого рамок. Конкретные инструкции приводятся в тексте, предшествующем каждой таблице.
А.2 Идентификация реализации
А.2.1 Дата заявления
Поставщик реализации должен проставить в приведенной ниже рамке дату настоящего заявления. Используется формат ДД-ММ-ГГГГ.
|
|
А.2.2 Идентификация реализации
Поставщик реализации должен в приведенной ниже рамке предоставить информацию, необходимую для однозначной идентификации реализации и систем(ы), в которых(ой) она может находиться.
А.2.3 Информация для контактов
Поставщик реализации должен в приведенной ниже рамке предоставить информацию о том, с кем нужно установить контакт при возникновении вопросов относительно содержания ССАУ.
А.3 Идентификация документа, в котором определена информация административного управления
Поставщик реализации должен в приведенной ниже рамке проставить название, номер и дату публикации документа, специфицирующего информацию административного управления, о соответствии которой заявляется.
|
|
А.3.1 Учтенные технические поправки
Поставщик реализации должен в приведенной ниже рамке проставить номера учтенных технических поправок, которые изменяют спецификацию указанного документа.
А.3.2 Учтенные дополнения
Поставщик реализации должен в приведенной ниже рамке проставить название и номера учтенных дополнений к указанному документу.
А.4 Сводка соответствия административного управления
Поставщик реализации должен предоставить информацию о том, что заявляет о соответствии реализации некоторому набору документов, предоставляющих реализацию в целом. Для каждого документа, о соответствии которому заявляет поставщик, должны быть заполнены или указаны заявки о соответствии. Поставщиком реализации должны быть заполнены колонки 7 (Обеспечение), 8 (Номера таблиц ЗСРП/ЗСИУ/ЗСУО/ЗСУВ) и 9 (Дополнительная информация).
В колонке значения статуса используется следующая общая нотация, определенная в ГОСТ Р ИСО/МЭК 9646-2 и ИСО/МЭК 9646-7:
о - обязательно,
ф - факультативно,
у - условно,
х - запрещено,
- не применяется или не рассматривается.
Примечания
1 Обозначения "у", "о", "ф" и "х" дополняются префиксом "у:", когда являются вложенными в условную или факультативную позицию той же самой таблицы.
2 Обозначение "ф" может иметь суффикс ". n" (где "n" - уникальный номер) для кратных взаимоисключающих или выборочных опций из набора значений статуса. Требования для этого перенумерованного набора должны быть установлены явным образом, желательно, в сноске к соответствующей таблице.
В колонке ответа об обеспечении используется следующая общая нотация, определенная в ГОСТ Р ИСО/МЭК 9646-2 и ИСО/МЭК 9646-7:
Д - реализовано,
Н - не реализовано,
- ответ не требуется,
И - позиция игнорируется (т.е. обрабатывается синтаксически, но не семантически).
В таблицах А.1-А.4 колонка статус используется для указания, должен ли поставщик реализации заполнять указанную таблицу или позицию. Требования соответствия установлены в указанных таблицах или позициях и не изменяются значениями колонки статуса ССАУ. Аналогично колонка обеспечения используется поставщиком реализации для отметки заполнения указанных таблиц и позиций.
Таблица А.1 - Сводка обеспечения ЗСРП
|
|
|
|
|
|
|
|
|
|
|
|
||||||||
|
|
Таблица А.2 - Сводка обеспечения ЗСУО
|
|
|
|
|
|
|
|
|
|
|
|
||||||||
|
|
Таблица А.3 - Сводка обеспечения ЗСУВ
|
|
|
|
|
|
|
|
|
|
Таблица А.4 - Сводка обеспечения ЗСИУ
|
|
|
|
|
|
|
|
|
|
Сводка обеспечения ЗСИУ в ССАУ содержит краткое изложение всей информации административного управления, которую определяет спецификация для роли управляющего, и идентифицирует требования соответствия (статус), относящиеся к этой информации административного управления.
ПРИЛОЖЕНИЕ В
(обязательное)
Форма ЗСУО*
___________________
* Форма ЗСУО защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ЗСУО.
В.1 Введение
Форма ЗСУО обеспечивает поставщику реализации средство заявления о соответствии классу управляемых объектов для предоставления информации соответствия в стандартном виде.
В.2 Инструкция по заполнению формы ЗСУО для получения ЗСУО
Поставщик реализации должен в приведенных ниже таблицах указать, какие позиции обеспечиваются и, при необходимости, привести дополнительную информацию
8.3 Заявление о соответствии классу управляемых объектов
Таблица В.1 - Обеспечение класса управляемых объектов
|
|
|
|
|
|
Если ответ на вопрос о фактическом классе в таблице В.1 отрицательный, то поставщик реализации должен заполнить таблицу В.2 обеспечения фактического класса.
Таблица В.2 - Обеспечение фактического класса
|
|
|
|
|
В.4 Атрибуты
Таблица В.3 - Обеспечение атрибутов
|
|
|
| |||||||
|
|
|
|
|
|
|
|
|
|
|
Окончание таблицы В.3 - Обеспечение атрибутов
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
В.5 Атрибутивные группы
Таблица В.4 - Обеспечение атрибутивных групп
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
В.6 Действия
Таблица В.5 - Обеспечение действий
|
|
|
|
|
|
|
|
Окончание таблицы В.5 - Обеспечение действий
|
|
|
|
|
|
|
|
В.7 Сообщения
Таблица В.6 - Обеспечение сообщений
|
|
|||||||
|
|
|
|
|
|
|
|
|
Окончание таблицы В.6 - Обеспечение сообщений
|
|
|
|
|
|
|
|
|
В.8 Параметры
Таблица В.7 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ С
(обязательное)
Форма ЗОИУ (атрибуты)*
___________________
* Форма ЗОИУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и опубликовать заполненную форму ЗОИУ.
С.1 Атрибуты
Таблица С.1 - Обеспечение атрибутов
|
|
|
| |||||||
|
|
|
|
|
|
|
|
|
|
|
Окончание таблицы С.1 - Обеспечение атрибутов
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
С.2 Параметры
Таблица С.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ D
(обязательное)
Форма ЗОИУ (атрибутивные группы)*
___________________
* Форма ЗОИУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и опубликовать заполненную форму ЗОИУ.
D.1 Атрибутивные группы
Таблица D.1 - Обеспечение атрибутивных групп
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
D.2 Параметры
Таблица D.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ Е
(обязательное)
Форма ЗОИУ (действия)*
___________________
* Форма ЗОИУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ЗОИУ.
Е.1 Действия
Таблица Е.1 - Обеспечение действий
|
|
|
|
|
|
|
|
Окончание таблицы Е.1 - Обеспечение действий
|
|
|
|
|
|
|
|
Е.2 Параметры
Таблица Е.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ F
(обязательное)
Форма ЗОИУ (сообщения)*
_________________
* Форма ЗОИУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ЗОИУ.
F.1 Сообщения
Таблица F.1 - Обеспечение сообщений
|
|
|||||||
|
|
|
|
|
|
|
|
|
Окончание таблицы F.1 - Обеспечение сообщений
|
|
|
|
|
|
|
|
|
F.2 Параметры
Таблица F.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ G
(обязательное)
Форма ЗСУВ для связывания имен*
____________________
* Форма ЗСУВ для связывания имен защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ЗСУВ для связывания имен.
G.1 Введение
Форма ЗСУВ для связывания имен обеспечивает поставщику реализации средство заявления о соответствии связыванию имен для предоставления информации соответствия в стандартном виде.
G.2 Инструкции по заполнению формы ЗСУВ для связывания имен
Поставщик реализации должен указать в таблицах G.1 и G.2, как позиции обеспечиваются и, при необходимости, привести дополнительную информацию.
G.3 Заявление о соответствии связыванию имен
Таблица G.1 - Обеспечение связывания имен
|
|
|
|
|
|
|
|
Окончание таблицы G.1 - Обеспечение связывания имен
|
|
|
|
|
|
|
|
|
Обеспечение создания |
||||||
|
Создание с указанием ссылки |
||||||
|
Создание с автоматическим наименованием экземпляра |
||||||
|
Обеспечение удаления |
||||||
|
Удаление только в случае, если нет вмещаемых объектов |
||||||
|
Удаление вмещаемых объектов |
G.4 Параметры
Таблица G.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ Н
(обязательное)
Форма ЗСИУ (атрибуты)*
_____________________
* Форма ЗСИУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ЗСИУ.
Н.1 Атрибуты
Таблица Н.1 - Обеспечение атрибутов
|
|
|
| |||||||
|
|
|
|
|
|
|
|
|
|
|
Окончание таблицы Н.1 - Обеспечение атрибутов
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
Н.2 Параметры
Таблица Н.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ I
(обязательное)
Форма ЗСИУ (атрибутивные группы)*
__________________
* Форма ЗСИУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ЗСИУ.
I.1 Атрибутивные группы
Таблица I.1 - Обеспечение атрибутивных групп
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
I.2 Параметры
Таблица I.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ J
(обязательное)
Форма ЗСИУ (действия)*
___________________
* Форма ЗСИУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ЗСИУ.
J.1 Действия
Таблица J.1 - Обеспечение действий
|
|
|
|
|
|
|
|
Окончание таблицы J.1 - Обеспечение действий
|
|
|
|
|
|
|
|
J.2 Параметры
Таблица J.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ К
(обязательное)
Форма ЗСИУ (сообщения)*
____________________
* Форма ЗСИУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ЗСИУ.
К.1 Сообщения
Таблица К.1 - Обеспечение сообщений
|
|
|
||||||
|
|
|
|
|
|
|
|
|
Окончание таблицы К.1 - Обеспечение сообщений
|
|
|
|
|
|
|
|
|
К.2 Параметры
Таблица К.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ L
(обязательное)
Форма ЗСИУ (создание и удаление)*
__________________
* Форма ЗСИУ защищена авторскими правами. Пользователи настоящего стандарта могут воспроизводить, использовать и публиковать заполненную форму ЗСИУ.
L.1 Обеспечение создания и удаления
Таблица L.1 - Форма ЗСИУ (создание и удаление)
|
|
|
|
|
|
|
|
1 |
Создание |
||||
|
1.1 |
С указываемым объектом |
||||
|
2 |
Удаление |
L.2 Параметры
Таблица L.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
ПРИЛОЖЕНИЕ М
(справочное)
Дополнительные указания по спецификации форм
М.1 Введение
В настоящем приложении приведены дополнительные указания по спецификации форм. Они соответствуют соглашениям ГОСТ Р ИСО/МЭК 9646-1, ГОСТ Р ИСО/МЭК 9646-2, ИСО/МЭК 9646-7 и повторены здесь для удобства.
М.2 Обозначения и индексы таблиц
Таблицы в документе нумеруют арабскими цифрами сквозной нумерацией, например "Таблица 1", "Таблица 2" и т.д. до "Таблица n". Таблицы каждого приложения обозначают отдельной нумерацией арабскими цифрами с добавлением перед цифрой обозначения приложения и точки. Например, таблицы в приложении X помечают как "Таблица Х.1", "Таблица Х.2" и т.д.
Индексы и подиндексы для строк таблиц обозначают в соответствии с ГОСТ Р ИСО/МЭК 9646-2, а именно, последовательными номерами. Например, таблица М.1 имеет строки 1, 2, 3.
Таблица М.1 - Пример индексов
|
|
|
|
1 |
|
|
2 |
|
|
3 |
|
Индексы для подстрок (строк внутри строк) являются индексом строки с последующей точкой и номером подстроки. Например, в таблице М.2 строка 1 имеет подстроки 1.1, 1.2, 1.3.
Таблица М.2 - Пример подиндексов
|
|
|
|
|
1 |
|
- |
|
1.1 |
- |
|
|
1.2 |
- |
|
|
1.3 |
- |
|
|
2 |
|
- |
М.3 Продолжения таблиц
Эта проблема возникает, когда информация в таблице не умещается на ширине страницы. Например, таблица М.3 не помещается на странице.
Таблица M.3 - Пример неформатной таблицы
|
|
|
|
|
|
|
|
1.1 |
? |
||||
|
1.2 |
? |
Допускается печатать таблицы на странице вертикально или разрывать на части по колонкам (графам) соответственно ширине страницы. Если строка или колонка выходят за формат страницы, то таблицу делят на блоки (части), помещая одну часть под другой или рядом. Номера индексов строк первого блока идентичны номерам индексов в первых колонках продолжения таблицы. Если таблица занимает несколько страниц, то в конце таблиц должен быть текст "продолжение на следующей странице".
Примечание - Продолжения таблицы должны иметь заголовок "Продолжение
|
таблицы Х - |
", а последняя часть - "Окончание таблицы X - |
". | ||
|
название таблицы |
название таблицы |
Таблица М.3, разделенная на три части, будет выглядеть как таблица М.4:
Таблица M.4 - Пример продолжения таблицы
|
|
|
|
|
|
1.1 |
|
||
|
1.2 |
|
Продолжение таблицы М.4 - Пример продолжения таблицы
|
|
|
|
|
|
1.1 |
|
||
|
1.2 |
|
Окончание таблицы М.4 - Пример окончания таблицы
|
|
|
|
|
|
1.1 |
|
||
|
1.2 |
|
Комментарии, описывающие построение таблицы, могут быть добавлены к предшествующему материалу. Например, к предшествующему тексту может быть добавлено:
х.х Формат таблицы
Некоторые таблицы разделены на части, так как содержащаяся в них информация не помещается по ширине таблицы. В таких случаях индексы строк первого блока являются индексами строк последующих блоков (частей) колонок. Полная таблица строится из последовательных частей следующим образом:
|
|
|
|
|
В документе последовательные части таблицы следуют друг за другом, начиная с первой.
Если таблица не помещается на странице по длине, то она продолжается на следующей странице. Номера индексов при этом продолжают возрастать. Продолжения таблицы имеют заголовок "Продолжение таблицы X -
|
| ||
|
название таблицы |
название таблицы | |
Если таблица очень длинная и широкая, то первый блок колонок должен быть завершен по длине до того, как начнется второй блок, и т.д. Части очень длинной и широкой таблицы должны располагаться в документе в следующем порядке:
|
a) Первый блок колонок, строки 1 - |
|
б) Первый блок колонок, строки ( |
|
в) Второй блок колонок, строки 1 - |
|
г) Второй блок колонок, строки ( |
Полная таблица реконструируется из составляющих следующим образом:
|
а) Первый блок колонок, строки 1 - |
в) Второй блок колонок, строки 1 - |
|
б) Первый блок колонок, строки ( |
г) Второй блок колонок, строки ( |
Напротив, очень широкая таблица с подстроками может быть сужена путем разделения информации в колонках; т.е. информацию для строк помещают в той же колонке, что и информацию для подстроек, а индекс указывает, относится эта информация к строке или подстроке. Например, приведенная выше таблица М.2 может быть сужена следующим образом:
|
|
|
|
1 |
|
|
1.1 |
|
|
1.2 |
|
|
1.3 |
|
|
2 |
|
М.4 Условные утверждения
Условия в таблицах относятся к обозначениям (уn), таким как y1 у2 и т.д., где "n" - уникальное целое число, а за меткой условия следует двоеточие ":". За условием должен следовать предикат (if then else). Например:
у1: if предикат then о else -
В данном случае если предикат имеет значение "истина", статусом является то, что следует за "then" (в данном случае "о"); если предикат имеет значение "ложь", статусом является то, что следует за "else" (в данном случае "-").
Предикатом может быть одно из следующих:
а) явная ссылка на ответ об обеспечении (в колонке "Обеспечение"); если ответ "Д", то предикат равен "истина", иначе - "ложь";
б) булевское выражение, содержащее другие предикаты, например p1 AND NOT p2.
Условия могут находиться в начале формы ЗСУО, если используются по всему тексту. В таком случае рекомендуется следующая форма:
х.х Обозначения, сокращения и термины
Следующие требования являются общими во всей форме ЗСУО:
y1: if A/10a then о else -
у2: if В/3 then о else -
Если условия используются только в одной таблице, то они располагаются в конце ее. Например:
Таблица М.5 - Пример условий
|
|
|
|
|
1 |
у1 |
|
|
2 |
у2 |
|
|
y1: if D/10a then o else - y2: if B/3 then о else - | ||
Примечание 1 - Если в колонке статуса "у", "о*, "ф" или "х" имеют префикс "у:", то это означает, что статус является вложенным для условного или факультативного элемента в той же самой таблице. Например:
Таблица М.6 - Пример вложенных условий
|
|
|
|
1 |
ф |
|
1.1 |
у:о |
|
1.2 |
у:ф |
|
1.2.1 |
у:ф |
Примечание 2 - В колонке статуса "ф" может иметь суффикс ".n" (где "n" - уникальное целое число) для взаимоисключающих или выборочных возможностей из набора значений статуса. Требования для этого перенумерованного набора должны быть установлены явно, желательно в сноске к той же самой таблице. Например, в следующей таблице описан набор взаимосвязанных возможностей:
Таблица М.7 - Пример группы взаимосвязанных возможностей
|
|
|
|
1 |
ф.5 |
|
2 |
ф.5 |
|
3 |
ф.5 |
|
4 |
ф.5 |
|
ф.5: должна обеспечиваться по крайней мере одна из возможностей | |
В предикате явная ссылка на ответ об обеспечении (в колонке "Обеспечение") задается следующей последовательностью:
а) ссылка на таблицу, содержащая нужный элемент, например С;
б) наклонная черта "/";
в) индекс или подиндекс строки, в которой содержится ответ;
г) только в том случае, когда идентифицированная ссылочным номером строка содержит несколько ответов об обеспечении, каждый возможный ответ неявно помечается буквами а, b, с и т.д. слева направо, и эта буква добавляется к последовательности.
Например, ссылка на ответ об обеспечении "А/10с" указывает на третий ответ об обеспечении в строке с индексом 10 в таблице А.
М.5 Отсутствие характеристики в определении класса управляемых объектов
Если определение класса управляемых объектов устанавливает отсутствие какой-либо характеристики, то это же должно быть сделано в форме; нельзя просто опускать соответствующий раздел. Это позволяет избежать возможных недоразумений для характеристик, которые обеспечиваются, но таблицы в документе отсутствуют.
Например, если класс управляемых объектов не поддерживает атрибутивные группы, то вместо таблицы обеспечения атрибутивных групп следует указать:
Х.4 Обеспечение атрибутивных групп
Атрибутивные группы не специфицированы для данного класса управляемых объектов.
М.6 Сокращения для идентификаторов объектов
В таблицах формы допускаются сокращения идентификаторов объектов. Эти сокращения должны быть специфицированы в форме ССАУ, если они используются в нескольких формах (например, ССАУ, ЗСУО, ЗОИУ), или в той форме, где они используются только в одной форме. Сокращения должны быть определены в отдельном разделе до их использования. Пример того, как могут быть сокращены идентификаторы объектов для атрибутов:
dmi-att joint-iso-itu-t ms (9) smi (3) part2 (2) attribute (7)
При использовании в таблицах идентификатор объекта для атрибута со значением 22 может быть задан как "dmi-att 22".
Дополнительные указания по сокращениям и терминам могут быть установлены в форме ССАУ, если они используются в нескольких формах (например, ССАУ, ЗСУО, ЗОИУ), или в той форме, где они используются только в одной форме.
М.7 Таблицы параметров
В форму ЗСУО могут быть включены одна или несколько таблиц обеспечения параметров. Статусы параметров всегда должны быть условными, а условие связано с обеспечением соответствующих характеристик административного управления. Соответствующая характеристика административного управления может быть указана с помощью номера индекса. Если имеется несколько таких характеристик, то для получения фактического условия для параметра, условия для характеристик комбинируются с помощью логической операции "OR". Например, условие обеспечения конкретного параметра ошибки, связанной с двумя действиями (Х/1.1 и Х/1.2), может быть записано как:
y11: if (Х/1.1 OR Х/1.2) then о else -
М.8 Метки имен полей сообщений и действий
Метки имен полей действий являются метками в синтаксисе АСН.1 информации действия и ответной информации действия. Метки имен полей сообщений являются метками в синтаксисе АСН.1 информации события и ответной информации сообщения. Эти метки обычно используются в таблицах отображения услуги, но в некоторых случаях их может не быть в используемом синтаксисе. В таких случаях, во избежание двусмысленности, метки должен присвоить разработчик формы. При этом принимаются следующие соглашения:
а) используются метки " field.n", где " n" - возрастающие номера индексов, например field.1, field.2, field.2.1 (если поле field.2 вырожденное) и т.д.;
б) используются метки "TypeReference.n", где "TypeReference" - ссылка на тип синтаксиса информации или синтаксиса ответа, а "n" - возрастающие номера индексов; например, для синтаксиса информации действия ActiveReply поля могут быть названы Active Reply.1, Active Reply.2, Active Reply.2.1 (если поле Active Reply.2 вырожденное) и т.д.;
в) используется синтаксис полей, например OperationalState, INTEGER, Otherlnfo, где OperationalState и Otherlnfo - ссылки на типы.
Примечание - Рекомендуется, чтобы разработчики управляемых объектов присваивали метки в синтаксисе АСН.1 для информации действия/сообщения и ответа.
М.9 Таблицы обеспечения пакетов
В форму ЗСУО может быть включена таблица 8, когда значения статусов для некоторых характеристик класса управляемых объектов могут быть упрощены за счет использования условного значения статуса, зависящего от обеспечения, указанного для условных пакетов:
Таблица М.8 - Таблицы обеспечения пакетов
|
|
|
|
|
|
|
|
Спецификация формы должна иметь заполненные колонки 1 (Индекс), 2 (Метка шаблона пакета), 3 (Значение идентификатора объекта для пакета), 5 (Статус) и, при необходимости, 4 (Ограничения и значения). Поставщик реализации должен указать, обеспечиваются или нет пакеты из определения класса управляемых объектов, и отметить обеспечение для каждого пакета, заполнив колонки 6 (Обеспечение) и, при необходимости, 7 (Дополнительная информация).
М.10 Условия использования различных форм
Все спецификации, которые включают в себя информацию административного управления, установленную в РОУО, должны предоставлять формы ЗСР для спецификации подробных требований соответствия и обеспечения заявлений о соответствии.
Ниже даны некоторые рекомендации, относящиеся к разным формам.
М.10.1 Форма ССАУ
В документ, устанавливающий информацию административного управления, должна быть включена одна форма ССАУ.
М.10.2 Форма ЗСИУ
Формы ЗСИУ требуются, если спецификация содержит требования соответствия к реализациям роли управляющего. В большинстве случаев спецификация с информацией административного управления включает в себя требования соответствия к реализациям роли управляющего. Формы ЗСИУ должны включать в себя все относящиеся к делу операции и сообщения.
М.10.3 Форма ЗСУО
Формы ЗСУО требуются, если спецификация определяет управляемые объекты (о соответствии которым может быть заявлено).
М.10.4 Форма ЗОИУ
Формы ЗОИУ приводят только в том случае, если спецификация определяет родовые атрибуты, атрибутивные группы, действия или сообщения. Форма ЗОИУ предназначена для разработчиков других форм ЗСР и не может использоваться для заявления о соответствии. Не обязательно включать форму ЗОИУ в спецификации.
М.10.5 Форма ЗСУВ
Формы ЗСУВ требуются, если спецификация определяет какие-либо взаимосвязи (включая связывание имен).
М.10.6 Форма ЗСРП
Форма ЗСРП требуется, если есть какой-либо протокол, относящийся к определениям спецификации, который не установлен как часть форм ЗСИУ и ЗСУО. Обычно форма ЗСРП не требуется в стандартах по административному управлению системами.
Форма ЗСРП для согласования прикладного контекста административного управления системами представлена в ГОСТ Р ИСО/МЭК 10164-1, приложение Е.
M.11 Минимальные требования соответствия
Любой документ, содержащий определения информации административного управления, должен понятно и явно указывать минимальные требования соответствия для ролей управляющего и агента. В стандартах это должно быть установлено в разделе о соответствии, а в форме ССАУ должны быть предоставлены таблицы, в которых перечислены определенные в стандарте элементы информации административного управления, о соответствии которым может быть заявлено в ролях управляющего и агента. Содержание таблиц минимальных требований соответствия определяется для каждого стандарта в зависимости от элементов информации административного управления, установленных в этом стандарте (т.е. управляемых объектов, родовых атрибутов, сообщений и действий).
Документ, содержащий информацию административного управления, может быть предназначен для использования в различных видах. Одна возможность состоит в том, что установленная информация административного управления предназначена для использования в других спецификациях в качестве "строительных блоков". Другая возможность - спецификация предназначена для (более или менее) идентифицированного приложения.
В зависимости от целей спецификации могут изменяться минимальные требования соответствия. Ниже даны рекомендации для различных ситуаций.
М.11.1 Спецификации "строительных блоков"
Документы, которые проектировались как родовые (т.е. предназначены для создания основных "строительных блоков", на которые будут ссылаться другие спецификации), должны как можно меньше требовать от соответствующих реализаций. Должна быть возможна (соответствующая) реализация любого подмножества спецификаций документа. Причина такого подхода заключается в том, что, если документ предназначен для использования его частей в качестве "строительных блоков" во многих различных приложениях, то в разных ситуациях будут использоваться разные подмножества спецификаций документа. В большинстве случаев невозможно определить подмножество, которое должно использоваться во всех ситуациях.
Например, в случае функционального стандарта, такого как функция административного управления состоянием, определяющего родовые атрибуты или сообщения, которые должны использоваться во многих определениях управляемых объектов, минимальное соответствие (в роли агента) может сводиться к одному какому-то атрибуту или сообщению. В других случаях минимальное соответствие может сводиться к одному из объектов или пакетов, определенных в функции.
Эти минимальные требования могут изменяться между системами в роли управляющего и в роли агента. Например, для системы в роли управляющего соответствие родовому атрибуту (такому, как атрибут "состояние") минимальное требование может быть ограничено по крайней мере одной операцией (например, Get) над атрибутом, тогда как для системы в роли агента минимальное требование может быть обеспечено для управляемого объекта, включающего в себя атрибут.
Хотя требование соответствия может быть очень ограниченным, заявление о соответствии (сделанное поставщиком) может содержать дополнительную информацию о том, как обеспечивается превышающая минимум поддержка.
М.11.1.1 Родовые определения в роли агента
Если спецификация содержит некоторые родовые определения, то для заявления о соответствии достаточно обеспечить один (одно, одну) из атрибутов, сообщений, атрибутивных групп или действий. Заявление о соответствии родовому атрибуту (в роли агента) должно сопровождаться ЗСУО (для подробного заявления о соответствии). Для этого в форме ССАУ в таблице минимальных требований соответствия для роли агента должна быть предусмотрена колонка "Ссылки на таблицы".
М.11.1.2 Управляемые объекты в роли агента
Если спецификация определяет (реализуемые) управляемые объекты, то для заявления о соответствии достаточно поддерживать по крайней мере один из этих управляемых объектов. Факультативно могут обеспечиваться любые связывания имен.
Если спецификация включает в себя как родовые определения, так и (реализуемые) управляемые объекты, то минимальным требованием к реализации роли агента может быть соответствие либо одному из родовых определений, либо одному из управляемых объектов.
М.11.1.3 Роль управляющего
Для заявления о соответствии достаточно поддерживать по крайней мере одну операцию (включая создание и удаление) или одно сообщение, определенное для любого управляемого объекта (или родовое определение). Это очень ограниченное требование, и другие спецификации должны определить, что фактически должна обеспечивать реализация.
М.11.2 Прикладные спецификации
Если спецификация предназначена для использования в конкретной области (а не как базовый "строительный блок"), то минимальные требования соответствия должны охватывать большую сферу, контролируемую самим приложением. В большинстве случаев минимальные требования соответствия для роли агента должны быть полностью основаны на приложении. Вероятно, обязательным частям приложения нужны обязательные части информации административного управления.
Минимальные требования соответствия к роли управляющего могут оставаться ограниченными. Любая конкретная реализация роли управляющего может обеспечивать подмножество определенных операций. Индивидуально в каждом случае должно определяться, какая часть спецификации должна включаться в минимальные требования соответствия.
М.11.3 Комбинированные спецификации
Наиболее сложным случаем является спецификация, написанная и как источник базовой информации административного управления, и как прикладная спецификация. В этом случае минимальные требования соответствия должны быть сформулированы для каждой ситуации. Это можно рассматривать как предоставление в спецификации некоторых полезных подмножеств "строительных блоков" и аналогично понятию профиля.
Примечание - Для этой цели во многих стандартах по функциям административного управления системами используются функциональные блоки.
М.12 Совместимые классы
Форма ЗСУО предназначена для использования в качестве заявления о соответствии классу управляемых объектов, определенному в документе, или некоторым совместимым классам объектов. При спецификации статусов для операций над атрибутами управляемого объекта следует обеспечить, чтобы расширенный класс мог заявить о соответствии в качестве совместимого класса, используя ту же форму ЗСУО. Это может быть сделано спецификацией условных утверждений для статуса, когда статус в подклассе может быть другим.
Для операций, которые не специфицированы явно как исключенные, форма ЗСР должна предоставить условный статус, который, например, устанавливает "if А.1/1b then x else -", где A.1/1b относится к ответу на вопрос: "Является ли фактический класс тем классом управляемых объектов, о соответствии которому заявляется?" Этот метод гарантирует, что форма ЗСР может быть использована для заявлений о соответствии спецификации, когда реализация поддерживает совместимый класс объектов.
М.13 Форма ЗСУО для нереализуемых классов
Минимальные требования соответствия в современных стандартах функций административного управления системами не содержат возможности заявить о соответствии какому-либо нереализуемому суперклассу. Следовательно, в формах ЗСР, относящихся к стандартам функций административного управления системами, не определены формы ЗСУО для нереализуемых суперклассов. В дальнейшем такие формы могут появиться.
Последующие стандарты функций могут допустить заявления о соответствии нереализуемым классам. Тогда должны быть предоставлены формы ЗСУО для таких классов объектов.
М.14 Наследуемые атрибуты
Статусы атрибутов, унаследованных с высшего уровня, должны быть согласованно задокументированы, если подкласс не изменяет и не расширяет их определения.
Для классов управляемых объектов, которые поддерживают создание операцией административного управления, статус "Установка при создании" должен быть "о" для атрибута objectClass и "ф" - для атрибутов nameBinding, packages и allomorphs.
Для классов управляемых объектов, которые поддерживают создание только системой-агентом (например, объекты записей), статус "Установка при создании" для этих атрибутов должен быть "х".
М.15 Интерпретация статуса "о"
Использование статуса "о" в колонке "Статус" форм ЗСР может привести к разным интерпретациям того, что требуется от реализации, в зависимости от типа формы ЗСР и того, относится ли форма ЗСР к реализации как к отправителю или к получателю.
Значение статуса "о" в колонке "Статус" применительно к получающей реализации используется как для указания требования "полной функциональности", так и требования совместимости при получении параметра (но не его дальнейшей обработки).
Для разъяснения этого различия смысла "о" в форме ЗСР должно быть приведено объяснение использования "о" в конкретной ЗСР. Этот текст должен быть включен в раздел "Обозначения, сокращения и термины" или помещен рядом с соответствующей таблицей.
М.16 Условные выражения
При использовании условных выражений в формах ЗСР:
- все условные выражения должны заканчиваться на точке ".";
- все номера в ф.N должны быть уникальными в пределах одного приложения (а желательно - и в пределах всего документа);
- все номера в yN должны быть уникальными в пределах одного приложения (а желательно - и в пределах всего документа);
- следует избегать, если это возможно, условных выражений с ссылками на другие приложения;
- если условное выражение сложное, то добавляется описательное примечание с разъяснениями.
М.17 Кратные формы ЗСИУ одного типа
В некоторых случаях требования соответствия в спецификации приводят к нескольким записям в форме ЗСИУ конкретного типа. Примером такой ситуации является требование обеспечения атрибута (в роли управляющего). Если один и тот же атрибут включен в несколько классов управляемых объектов, то результатом могут быть разные требования для одного и того же атрибута в зависимости от контекста. В форме ЗСИУ это может быть выражено двумя разными способами:
- для обеспечения атрибута предоставляется несколько форм ЗСИУ. Контекст каждой отдельной формы четко определен. Позиции в форме ССАУ (сводке обеспечения ЗСИУ) указывают поставщику реализации на нужные таблицы;
- для атрибутов используется одна форма ЗСИУ, но отдельные атрибуты включаются в несколько строк. Для указания контекста используется колонка "Ограничения и значения".
Аналогичные приемы можно использовать и для других типов форм ЗСИУ. Дополнительная информация о заполнении форм ЗСИУ приведена в приложении N.
М.18 Порядок форм ЗСР
Для согласованности между разными спецификациями и удобства пользователей рекомендуется следующий порядок ЗСР, связанных с административным управлением ВОС:
ССАУ, ЗСИУ, ЗСУО, ЗОИУ, ЗСУВ, ЗСРП.
Не все типы форм ЗСР входят во все спецификации. Форма ССАУ присутствует всегда, и важно, чтобы она была ранее других форм, так как предоставляет сводку требований соответствия для полной спецификации и ссылки на другие требуемые формы.
ПРИЛОЖЕНИЕ N
(справочное)
Дополнительные указания по заполнению форм
N.1 Введение
В настоящем приложении приведены дополнительные указания по заполнению форм. Они адресованы поставщикам реализаций, использующим формы ЗСР для заявлений о соответствии.
N.2 Использование таблиц сводки обеспечения для отображения номеров других таблиц
Таблицы сводки обеспечения в форме ССАУ предназначены для того, чтобы дать общий обзор всех форм ЗСР, входящих в конкретное заявление о соответствии. Колонка "Номера таблиц ЗСРП" может быть использована для идентификации конкретной ЗСР (и таблиц в ЗСР), относящейся к элементу, идентифицированному в таблице сводки обеспечения. Эта же колонка может быть использована для ссылки на конкретную ЗСР, когда используется несколько копий одной и той же формы ЗСР.
N.3 Обеспечение установки при создании в роли управляющего
Подробная спецификация того, как реализация роли управляющего обеспечивает установку при создании для различных атрибутов, приводится в форме ЗСИУ для атрибутов. В форму ЗСИУ для создания и удаления могут быть включены ссылки (в колонке "Дополнительная информация") для указания любых частных ограничений в заявленном соответствии.
N.4 Заявление об ограниченном обеспечении роли управляющего
В большинстве случаев форма ЗСИУ устанавливает требования соответствия спецификации в терминах операций и сообщений без каких-либо ограничений на то, с какими управляемыми объектами может работать система в роли управляющего. Если заявление о соответствии более ограничено, то существуют альтернативные способы сделать это заявление:
- может быть использована колонка "Дополнительная информация" для указания любых ограничений в обеспечении данной позиции. Например, может быть указано, что обеспечение ограничено операциями над экземплярами конкретных классов объектов вместе со списком всех таких классов;
- в заявление о соответствии может быть включено несколько копий одной и той же заполненной формы ЗСИУ. Контекст каждой заполненной копии формы ЗСИУ должен быть ясно специфицирован в заявлении. Особое внимание требуется в тех случаях, когда условные выражения ссылаются на другие формы ЗСР.
ПРИЛОЖЕНИЕ О
(справочное)
Пример формы ССАУ
О.1 Введение
В настоящем приложении приведен пример формы ССАУ, которая должна быть заполнена поставщиком реализации. Соответствующий пример формы ЗСУО для определения класса управляемых объектов (названного exampleObjectClass) приведен в приложении Q.
О.1.1 Объяснения
В настоящем подразделе приведены объяснения, относящиеся к таблицам примера.
1) Таблицы содержат вопросы об обеспечении роли управляющего и агента. Ответы на эти вопросы используются для условных выражений в большинстве последующих таблиц.
2) Если спецификация определяет функциональные блоки, то необходимо указать их обеспечение. Для отнесения этих блоков к обеспечению роли управляющего и агента использовано условное выражение. Такая таблица необходима только в том случае, когда в документе определены функциональные блоки (или другие группировки).
3) Требования к роли управляющего должны быть перечислены в одной таблице.
Эта таблица является лишь описанием "верхнего уровня" требований соответствия, относящихся к роли управляющего. Таблицы современных стандартов функций административного управления включают в себя позиции для отдельных родовых сообщений, одну позицию для всех родовых атрибутов и атрибутивных групп и одну позицию для "операций над управляемыми объектами". Рекомендуется, чтобы структура таблицы О.3 использовалась во всех стандартах по функциям административного управления. Если принять эту структуру, то минимальные требования соответствия могут быть легко выражены в форме ЗСИУ. Таблица О.3 не должна содержать список классов управляемых объектов стандарта (так как требования соответствия роли управляющего относятся, в общем случае, к операциям и сообщениям, а не к управляемым объектам).
Статус позиций в таблице О.3 может быть весьма сложным, если они относятся к обеспечению функциональных блоков и для некоторых функциональных блоков требуется поддержка определенных позиций таблицы О.3.
4) Требования к роли агента должны быть перечислены в одной таблице. В этой таблице должны быть приведены все элементы, о соответствии которым в роли агента может быть заявлено. В этой таблице могут быть позиции двух видов:
- родовая информация административного управления;
- реализуемые классы управляемых объектов.
Родовая информация административного управления включает в себя любые родовые сообщения, атрибуты, атрибутивные группы и действия, о соответствии которым может быть заявлено (в каждой спецификации должно быть установлено, следует ли рассматривать определение как родовое или нет).
Если таблица содержит любую родовую информацию, то требуется примечание, указывающее, что заявление о соответствии любому родовому определению должно включать в себя ссылку на ЗСУО (т.е. на заполненную форму ЗСУО), где декларированы детали соответствия.
В большинстве случаев сам документ не должен содержать форму ЗСУО, так как определение является родовым, предназначенным для импорта в другие спецификации. Фактическая ЗСУО, включенная в заявление, может использовать стандартную форму ЗСУО, определенную в стандарте, или быть специфичной для поставщика.
Управляемые объекты должны быть представлены в виде списка классов управляемых объектов, о соответствии которым может быть заявлено. В колонке "Ссылка на таблицу" для всех классов управляемых объектов должно стоять "-", так как в данном случае ссылка на нужную форму ЗСУО может быть найдена в таблице сводки обеспечения ЗСУО.
Третьим типом позиций в этой таблице может быть любой нереализуемый суперкласс, определенный в спецификации. Если заявление о соответствии спецификации допускает суперклассы, то они должны быть включены в эту таблицу.
5) Таблица с вопросами об обеспечении регистрации записей событий нужна, если спецификация определяет какие-либо регистрационные записи, родовые сообщения или другие классы управляемых объектов, порождающие сообщения. Эти вопросы используются для определения того, требуется ли обеспечение класса объектов регистрационных записей.
6) Таблица сводки обеспечения ЗСРП используется для того, чтобы дать ссылки на все формы ЗСРП, требуемые для полного заявления о соответствии спецификации. Обычно имеется только одна позиция (прикладной контекст административного управления системами). Указанные формы ЗСРП могут содержаться в том же самом документе или в других спецификациях.
7) Таблица сводки обеспечения ЗСУО должна содержать ссылки на все формы ЗСУО, относящиеся к заявлению о соответствии данной спецификации. Обычно в их число входят все определенные в спецификации (реализуемые) классы управляемых объектов и все регистрационные записи, связанные с сообщениями, исходящими от этих управляемых объектов.
Колонка статуса в сводке обеспечения ЗСУО используется для указания того, когда указанная форма ЗСУО должна быть включена в заявление о соответствии, т.е. когда поставщик реализации должен заполнять указанную форму ЗСУО. В большинстве случаев статус является обратной ссылкой на ответы в таблице О.4.
8) Таблица сводки обеспечения ЗСУВ должна содержать все относящиеся к делу связывания имен. Эти связывания имен могут быть определены в спецификации или указаны из других документов. Статусы связываний имен в большинстве случаев являются условными, зависящими от обеспечения подчиненных классов управляемых объектов. Обычно статус имеет вид "if <управляемый объект обеспечивается> then ф else - ". Обеспечение конкретного связывания имен обычно не является обязательным.
9) Таблица сводки обеспечения ЗСИУ должна содержать ссылки на все формы ЗСИУ, относящиеся к заявлению о соответствии данной спецификации. Статус в большинстве случаев является обратной ссылкой на обеспечение, заявленной в таблице О.3.
О.1.2 Назначение и структура
Сводка соответствия административного управления (ССАУ) является заявлением поставщика, которое идентифицирует реализацию и предоставляет информацию, указывающую, каким из перечисленных документов, специфицирующих требования соответствия административному управлению ВОС, заявляется реализация.
Форма ССАУ является документом в виде вопросника, который становится ССАУ после заполнения поставщиком реализации.
О.1.3 Инструкции по заполнению формы ССАУ
Поставщик реализации должен проставить явные ответы во всех оставленных для этого местах. Специфические инструкции по заполнению каждой таблицы приведены в тексте перед этой таблицей.
О.2 Идентификация реализации
О.2.1 Дата заявления
Поставщик реализации должен проставить в приведенной ниже рамке дату настоящего заявления. Используется формат ДД-ММ-ГГГГ.
|
|
О.2.2 Идентификация реализации
Поставщик реализации должен в приведенной ниже рамке предоставить информацию, необходимую для однозначной идентификации реализации и систем(ы), в которых(ой) она может находиться.
О.2.3 Информация для контактов
Поставщик реализации должен в приведенной ниже рамке предоставить информацию о том, с кем нужно установить контакт при возникновении вопросов относительно содержания ССАУ.
О.3 Идентификация документа, в котором определена информация административного управления
Поставщик реализации должен в приведенной ниже рамке проставить название, номер и дату публикации документа, специфицирующего информацию административного управления, о соответствии которой заявляется.
|
|
О.3.1 Учтенные технические поправки
Поставщик реализации должен в приведенной ниже рамке проставить номера учтенных технических поправок, которые изменяют спецификацию указанного документа.
О.3.2 Учтенные дополнения
Поставщик реализации должен в приведенной ниже рамке проставить названия и номера учтенных дополнений к указанному документу.
О.4 Сводка соответствия административного управления
Поставщик реализации должен предоставить информацию о том, что он заявляет о соответствии реализации некоторому набору документов, представляющих реализацию в целом. Для каждого документа, о соответствии которому заявляет поставщик, должны быть заполнены или указаны заявки о соответствии. Поставщиком реализации должны быть заполнены колонки 7 (Обеспечение), 8 (Номера таблиц ЗСРП/ЗСИУ/ЗСУО/ЗСУВ) и 9 (Дополнительная информация).
В колонке значения статуса используется следующая общая нотация, определенная в ГОСТ Р ИСО/МЭК 9646-2 и ИСО/МЭК 9646-7:
о - обязательно,
ф - факультативно,
у - условно,
х - запрещено,
- не применяется или не рассматривается.
Примечания
1 Обозначения "у", "о", "ф" и "х" дополняются префиксом "у:", когда являются вложенными в условную или факультативную позицию той же самой таблицы.
2 Обозначение "ф" может иметь суффикс ".
" (где "" - уникальный номер) для кратных взаимоисключающих или выборочных опций из набора значений статуса. Требования для этого перенумерованного набора должны быть установлены явным образом, желательно в сноске к соответствующей таблице.
В колонке ответа об обеспечении используется следующая общая нотация, определенная в ГОСТ Р ИСО/МЭК 9646-2 и ИСО/МЭК 9646-7:
Д - реализовано,
Н - не реализовано,
- ответ не требуется,
И - позиция игнорируется (т.е. обрабатывается синтаксически, но не семантически).
В таблице O.1 поставщик реализации должен указать обеспечиваемые роли.
Таблица О.1 - Роли
|
|
|
|
|
|
|
1 |
Обеспечение роли управляющего |
ф.1 |
||
|
2 |
Обеспечение роли агента |
ф.1 |
В таблице О.2 поставщик реализации должен указать обеспечение функциональных блоков административного управления системы.
Таблица О.2 - Функциональные блоки административного управления системы
|
|
|
|||||
|
|
|
|
|
|
|
|
|
1 |
Основной функциональный блок |
у1 |
у2 |
|||
|
2 |
Функциональный блок монитора |
у1 |
у2 |
|||
|
y1: if O.1/1a then ф else - . у2: if O.1/2a then ф else - . | ||||||
В таблице О.3 поставщик реализации должен указать обеспечение информации административного управления в роли управляющего.
Таблица О.3 - Минимальные требования соответствия в роли управляющего
|
|
|
|
|
|
|
1 |
Операции над управляемыми объектами |
у3 |
||
|
2 |
Сообщение об изменении состояния |
у4 |
||
|
3 |
Сообщение о создании объекта |
у4 |
||
|
4 |
Сообщение об удалении объекта |
у4 |
||
|
5 |
Сообщение об изменении значения атрибута |
у4 |
||
|
6 |
Сообщение Example |
у4 |
||
|
у/3: if O.2/1a then о else (if O.1/1a then ф.2 else - ). y4: if O.2/1a or O.2/2a then о else [if O.2/2a then ф else (if O.1/1a then ф.2 else - )]. | ||||
Примечание - Согласно минимальным требованиям соответствия в роли управляющего должна обеспечиваться по крайней мере одна позиция в таблице О.3. Обеспечение функциональных блоков, идентифицированных в таблице О.2, делает обязательным обеспечение некоторых из позиций данной таблицы. Условия у3 и у4 выражают оба эти требования.
В таблице О.4 поставщик реализации должен указать обеспечение информации административного управления в роли агента. Если обеспечиваются дополнительные подклассы регистрационных записей, то поставщик реализации должен перечислить эти классы в колонке "Дополнительная информация".
Таблица О.4 - Минимальные требования соответствия в роли агента
|
|
|
|
|
|
|
|
1 |
Класс объектов Example |
у5 |
- |
||
|
2 |
Подклассы регистрационных записей, связанных с создаваемыми сообщениями |
у6 |
- |
||
|
3 |
Сообщение Example |
у7 |
|||
|
у5: if O.2/1b then о else (if O.1/2a then ф.3 else - ). | |||||
Таблица О.5 - Регистрация записей событий
|
|
|
|
|
|
|
1 |
Обеспечивает ли реализация регистрацию записей событий в роли агента |
у8 |
||
|
у8: if O.1/2a then ф else - . | ||||
Поставщик реализации должен предоставить информацию о том, что он заявляет о соответствии реализации некоторому набору документов, представленному в таблицах О.6-О.9. Для каждого документа, о соответствии которому заявляет поставщик, должны быть заполнены или указаны заявки о соответствии. Поставщиком реализации должны быть заполнены "Обеспечение", "Номера таблиц" и "Дополнительная информация".
В таблицах О.6-О.9 колонка "Статус" используется для указания, должен ли поставщик реализации заполнять указанную таблицу или позицию. Требования соответствия установлены в указанных таблицах или позициях и не изменяются значениями колонки "Статус" ССАУ. Аналогично колонка "Обеспечение" используется поставщиком реализации для отметки заполнения указанных таблиц и позиций.
Таблица О.6 - Сводка обеспечения ЗСРП
|
|
|
|
|
|
|
|
|
|
Таблица О.7- Сводка обеспечения ЗСУО
|
|
|
|
|
|
|
|
|
|
|
1 |
Q.1-Q.7 |
example Object-Class |
Ф |
Таблица О.8 - Сводка обеспечения ЗСУВ
|
|
|
|
|
|
|
|
|
|
Таблица О.9 - Сводка обеспечения ЗСИУ
|
|
|
|
|
|
|
|
|
|
|
1 |
ГОСТ Р ИСО/МЭК 10165-6 |
Таблицы Р.2-Р.4 |
Операции административного управления |
- |
у12 |
|||
|
2 |
Таблица В.1 |
Сообщения objectCreation, objectDetetion, atributeValueChange |
- |
у13 |
||||
|
3 |
Таблица В.1 |
Сообщение stateChange |
- |
у14 |
||||
|
4 |
ГОСТ Р ИСО/МЭК 10165-6 |
Таблица В.1 |
Сообщение example |
- |
у15 |
|||
|
у12: if O.3/1a then о else - . у15: if О.3/6а then о else - . | ||||||||
ПРИЛОЖЕНИЕ Р
(справочное)
Пример формы ЗСИУ
Р.1 Введение
В настоящем приложении приведены примеры ЗСИУ различных типов. Формы ЗСИУ должны заполняться поставщиком реализации.
Р.2 Инструкции
Поставщик реализации должен в приведенных ниже таблицах указать, какие позиции обеспечены, и, при необходимости, предоставить дополнительную информацию.
Р.3 Пример
Р.3.1 Сообщение
Таблица Р.1 - Обеспечение сообщения
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
1 |
exampleNotification |
{not 1} |
- |
о |
|||
Окончание таблицы Р.1 - Обеспечение сообщения
|
|
|
|
|
|
|
|
|
|
1 |
1.1 |
sourcelndicator |
{dmi-att26} |
О-3 |
о |
||
|
1.2 |
attributeldentifierList |
{dmi-att8} |
- |
о |
|||
|
1.3 |
stateChangeDefinition |
{dmi-att28} |
- |
о |
|||
|
1.3.1 |
attributeld |
- |
- |
о |
|||
|
1.3.2 |
oldAttributeValue |
- |
- |
о |
|||
|
1.3.3 |
newAtlributeValue |
- |
- |
o |
|||
|
1.4 |
notificationldentifier |
{dmi-att16} |
INTEGER |
o |
|||
|
1.5 |
additionalText |
{dmi-att7} |
- |
o |
|||
|
1.6 |
additionallnformation |
{dmi-att6} |
- |
o |
Р.3.2 Атрибуты
Разработчик спецификации реализации роли управляющего, которая заявляет об обеспечении операций административного управления над атрибутами, определенными в настоящим документе, должен импортировать и заполнить копию таблицы Р.2.
Таблица Р.2 - Обеспечение атрибутов
|
|
| ||||||
|
|
|
|
|
|
|
|
|
|
1 |
objectClass |
{dmi-att65} |
- |
y1 |
ф.3 |
||
|
2 |
nameBinding |
{dmi-att63} |
- |
y1 |
ф.3 |
||
|
3 |
packages |
{dmi-att66} |
- |
y1 |
ф.3 |
||
|
4 |
allomorphs |
{dmi-att50} |
- |
y1 |
ф.3 |
||
|
5 |
logld |
{dmi-att2} |
- |
y1 |
ф.3 |
||
|
6 |
discriminatorConstruct |
{dmi-att56} |
- |
y1 |
ф.3 |
||
|
7 |
administrativeState |
{dmi-att31} |
- |
y1 |
ф.3 |
||
|
8 |
operationalState |
{dmi-att35} |
- |
- |
ф.3 |
||
|
9 |
availabilityStatus |
{dmi-att33} |
- |
- |
ф.3 |
||
|
10 |
logFullAction |
{dmi-att58} |
- |
y1 |
ф.3 |
||
|
11 |
maxLogSize |
{dmi-att62} |
- |
y1 |
ф.3 |
||
|
12 |
currentLogSize |
{dmi-att54} |
- |
- |
ф.3 |
||
|
13 |
numberOfRecords |
{dmi-att64} |
- |
y1 |
ф.3 |
||
|
14 |
capacityAlarmThreshold |
{dmi-att67} |
- |
y1 |
ф.3 |
||
|
15 |
startTime |
{dmi-att68} |
- |
y1 |
ф.3 |
||
|
16 |
stopTime |
{dmi-att69} |
- |
y1 |
ф.3 |
||
|
17 |
intervalsOfDay |
{dmi-att57} |
- |
y1 |
ф.3 |
||
|
18 |
weekMask |
{dmi-att71} |
- |
y1 |
ф.3 |
||
|
19 |
schedulerName |
{dmi-att67} |
- |
y1 |
ф.3 |
||
|
у: if P.4/1a then ф else - . | |||||||
Окончание таблицы Р.2 - Обеспечение атрибутов
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
|
|
1 |
- |
- |
- |
- |
|||||
|
2 |
- |
- |
- |
- |
|||||
|
3 |
- |
- |
- |
- |
|||||
|
4 |
- |
- |
- |
- |
|||||
|
5 |
- |
- |
- |
- |
|||||
|
6 |
ф.3 |
- |
- |
ф.3 |
|||||
|
7 |
ф.3 |
- |
- |
- |
|||||
|
8 |
- |
- |
- |
- |
|||||
|
9 |
- |
- |
- |
- |
|||||
|
10 |
ф.3 |
- |
- |
- |
|||||
|
11 |
ф.3 |
- |
- |
- |
|||||
|
12 |
- |
- |
- |
- |
|||||
|
13 |
- |
- |
- |
- |
|||||
|
14 |
ф.3 |
ф.3 |
ф.3 |
- |
|||||
|
15 |
ф.3 |
- |
- |
- |
|||||
|
16 |
ф.3 |
- |
- |
ф.3 |
|||||
|
17 |
ф.3 |
ф.3 |
ф.3 |
ф.3 |
|||||
|
18 |
ф.3 |
ф.3 |
ф.3 |
ф.3 |
|||||
|
19 |
- |
- |
- |
- |
|||||
Р.3.3 Действия
Разработчик спецификации реализации роли управляющего, которая заявляет об обеспечении действий над управляемыми объектами, определенными в настоящем документе, должен импортировать и заполнить копию таблицы Р.3.
Таблица Р.3 - Обеспечение действий
|
|
|
|
|
|
|
|
|
1.1 |
activateDynamicSimpleReport |
{summ-act 1} |
Инфор- мация |
ф |
||
|
1.2 |
activateDynamicSimpIeReport |
{summ-act 1} |
Ответ |
ф |
||
|
2.1 |
activateScanReport |
{summ-act 2} |
Инфор- мация (без синтаксиса) |
ф |
||
|
2.2 |
activateScanReport |
{summ-act 2} |
Ответ |
ф |
Окончание таблицы Р.3 - Обеспечение действий
|
|
|
|
|
|
|
|
|
1.1 |
1.1.1 |
scanAttributeldList |
- |
у:ф |
||
|
1.1.2 |
scopedSelection |
- |
у:ф |
|||
|
1.1.2.1 |
baseObject |
- |
у:ф.1 |
|||
|
1.1.2.1 |
distinguishedName |
- |
у:ф.1 |
|||
|
1.2 |
1.2.1 |
scanlnitiationTime |
- |
у:о |
||
|
1.2.2 |
additionalText |
- |
у:о |
|||
|
1.2.3 |
additionallnformation |
- |
у:о |
|||
|
2.2 |
2.2.1 |
scanlnitiationTime |
- |
у:о |
||
|
2.2.2 |
additionalText |
- |
у:о |
|||
|
2.2.3 |
additionallnformation |
- |
у:о |
Р.3.4 Операции создания и удаления
Разработчик спецификации реализации роли управляющего, которая заявляет об обеспечении операций административного управления создания и удаления управляемых объектов, определенных в настоящем документе, должен импортировать и заполнить копию таблицы Р.4.
Таблица Р.4 - Обеспечение создания и удаления
|
|
|
|
|
|
|
|
1 |
Создание |
ф.3 |
|||
|
1.1 |
С указываемым объектом |
у:ф |
|||
|
2 |
Удаление |
ф.3 |
ПРИЛОЖЕНИЕ Q
(справочное)
Пример формы ЗСУО
Q.1 Введение
В настоящем приложении приведен пример формы ЗСУО, которая должна быть заполнена поставщиком реализации. Пример определения класса управляемых объектов, названного exampIeObjectClass, приведен в ГОСТ Р ИСО/МЭК 10165-4, приложение А.
Форма ЗСУО обеспечивает поставщику реализации средство заявления о соответствии классу управляемых объектов для предоставления информации соответствия в стандартном виде.
Q.2 Инструкции по заполнению формы ЗСУО
Поставщик реализации должен в приведенных ниже таблицах указать, какие позиции обеспечены, и, при необходимости, предоставить дополнительную информацию.
Q.3 Заявление о соответствии классу управляемых объектов
Таблица Q.1 - Обеспечение класса управляемых объектов
|
|
|
|
|
|
|
1 |
exampleObjectClass |
{joint-iso-ccitt |
Если ответ на вопрос о фактическом классе в таблице Q.1 отрицательный, то поставщик реализации должен заполнить таблицу Q.2 обеспечения фактического класса.
Таблица Q.2 - Обеспечение фактического класса
|
|
|
|
|
Q.4 Атрибуты
Таблица Q.3 - Обеспечение атрибутов
|
|
| ||||||
|
|
|
|
|
|
|
|
|
|
1 |
оbjectClass |
{joint-iso-ccitt |
ф |
о |
|||
|
2 |
nameBinding |
{joint-iso-ccitt |
ф |
о |
|||
|
3 |
packages |
{joint-iso-ccitt |
- |
о |
|||
|
4 |
allomorphs |
{joint-iso-ccitt |
- |
у1 |
|||
|
5 |
objectName |
{joint-iso-ccitt |
- |
о |
|||
|
6 |
qOS-Error-Cause |
{joint-iso-ccitt |
- |
о |
|||
|
7 |
qOS-Error-Counter |
{joint-iso-ccitt |
- |
о |
|||
Окончание таблицы Q.3 - Обеспечение атрибутов
|
|
|
|
|
||||||
|
|
Статус |
Обес- пече- ние |
Статус |
Обес- пече- ние |
Статус |
Обес- пече- ние |
Статус |
Обес- пече- ние |
Дополнительная информация |
|
1 |
- |
- |
- |
- |
|||||
|
2 |
- |
- |
- |
- |
|||||
|
3 |
- |
- |
- |
- |
|||||
|
4 |
- |
- |
- |
- |
|||||
|
5 |
- |
- |
- |
- |
|||||
|
6 |
- |
- |
- |
- |
|||||
|
7 |
- |
- |
- |
- |
|||||
|
| |||||||||
Q.5 Атрибутивные группы
Таблица Q.4 - Обеспечение атрибутивных групп
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|
1 |
qOS-Group |
{joint-iso-ccitt |
о |
х |
||||
Q.6 Действия
Таблица Q.5 - Обеспечение действий
|
|
|
|
|
|
|
|
|
1 |
qOS-ResetAction |
{joint-iso-ccitt |
ф |
Окончание таблицы Q.5 - Обеспечение действий
|
|
|
|
|
|
|
|
|
1 |
1.1 |
- |
- |
Q.7 Сообщения
Таблица Q.6 - Обеспечение сообщений
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
1 |
protocolError |
{joint-iso-ccitt |
о |
||||
|
2 |
communicationError |
{joint-iso-ccitt |
ф |
||||
Продолжение таблицы Q.6 - Обеспечение сообщений
|
|
|
|
|
|
|
|
|
|
1 |
1.1 |
ProtocolError |
- |
о |
|||
|
2 |
2.1 |
ProbableCause |
{joint-iso-ccitt |
ф |
|||
|
2.1.1 |
globalValue |
- |
у:ф.1 |
||||
|
2.1.1 |
localValue |
- |
у:ф.1 |
||||
|
2.2 |
PerceivedSeverity |
{joint-iso-ccitt |
ф |
||||
|
2.3 |
Trendlndication |
{joint-iso-ccitt |
ф |
||||
|
2.4 |
BaskedUpStatus |
{joint-iso-ccitt |
ф |
||||
|
2.5 |
ProposedRepairActions |
{joint-iso-ccitt |
ф |
||||
|
2.6 |
Thresholdlnfo |
{joint-iso-ccitt |
ф |
||||
|
2.6.1 |
triggeredThreshold |
- |
у:о |
||||
|
2.6.2 |
observedValue |
- |
у:о |
||||
|
2.6.2.1 |
integer |
- |
у:ф.2 |
||||
|
2.6.2.2 |
real |
- |
у:ф.2 |
||||
|
2.6.3 |
thresholdLevel |
- |
у:ф |
||||
|
2.6.3.1 |
up |
- |
у:ф.3 |
||||
|
2.6.3.1.1 |
high |
- |
у:О |
||||
|
2.6.3.1.1.1 |
integer |
- |
у:ф.4 |
||||
|
2.6.3.1.1.2 |
real |
- |
у:ф.4 |
||||
|
2.6.3.1.2 |
low |
- |
у:ф |
||||
|
2.6.3.1.2.1 |
integer |
- |
у:ф.5 |
||||
|
2.6.3.1.2.1 |
real |
- |
у:ф.5 |
||||
|
2.6.3.2 |
down |
- |
у:ф.3 |
||||
|
2.6.3.2.1 |
high |
- |
у:о |
||||
|
2.6.3.2.1.1 |
integer |
- |
у:ф.6 |
||||
|
2.6.3.2.1.2 |
real |
- |
у:ф.6 |
||||
|
2.6.3.2.2 |
low |
- |
у:о |
||||
|
2.6.3.2.2 |
integer |
- |
у:ф.7 |
||||
|
2.6.3.2.2 |
real |
- |
у:ф.7 |
||||
|
2.6.4 |
armTime |
- |
у:ф |
||||
|
2.7 |
Otherlnfo |
- |
ф |
||||
|
2.8 |
ErrorResult |
- |
о |
Примечание - В таблице Q.6 обозначение "ф.n", например "ф.1", означает необходимость обеспечения, по крайней мере, одной из возможностей.
Q.8 Параметры
Таблица Q.7 - Обеспечение параметров
|
|
|
|
|
|
|
|
|
1 |
pDUHeader |
{joint-iso-ccitt |
o |
ПРИЛОЖЕНИЕ R
(справочное)
Пример формы ЗСУВ для связывания имен
R.1 Введение
В настоящем приложении приведен пример формы ЗСУВ для связывания имен, которая должна быть заполнена поставщиком реализации. Пример определения связывания имен, названного exampleNameBinding, приведен в ГОСТ Р ИСО/МЭК 10165-4, приложение А.
R.2 Инструкции по заполнению формы ЗСУВ
Поставщик реализации должен в приведенных ниже таблицах указать, какие позиции обеспечены, и, при необходимости, предоставить дополнительную информацию.
R.3 Заявление о соответствии связыванию имен
Таблица R.1 - Обеспечение связывания имен
|
|
|
|
|
|
|
|
|
1 |
exampleNameBinding |
{joint-iso-ccitt |
o |
Окончание таблицы R.1 - Обеспечение связывания имен
|
|
|
|
|
|
|
|
|
1 |
1.1 |
Обеспечение создания |
о |
|||
|
1.2 |
Создание с указанием ссылки |
- |
||||
|
1.3 |
Создание с автоматическим наименованием экземпляра |
о |
||||
|
1.4 |
Обеспечение удаления |
о |
||||
|
1.5 |
Удаление, только если нет вмещаемых объектов |
х |
||||
|
1.6 |
Удаление вмещаемых объектов |
о |
R.4 Параметры
Таблица R.2 - Обеспечение параметров
|
|
|
|
|
|
|
|
|
1 |
createErrorParameter |
{joint-iso-ccitt |
y1 |
|||
|
y1: if R.1/1 then о else - | ||||||
Текст документа сверен по:
официальное издание
М.: ИПК Издательство стандартов, 2004