Стр. 1
 

69 страниц

563.00 ₽

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

Официально распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль".

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

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

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

б) гарантирует разработку названных определений способом, совместимым со стандартами и рекомендациями стандартов по административному управлению ВОС;

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

Оглавление

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

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

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

4 Сокращения

5 Соглашения

6 Общие вопросы

7 Общие принципы определения управляемых объектов

8 Обозначения для определений управляемых объектов

9 Руководство по разработке эквивалентных модулей АС Н.1:1 9 94 и АСН.1:1990

10 Соглашения для АСН.1 и директив РОУО

Приложение А  Примеры

Приложение В Руководство по применению Z при формализации поведения управляемых объектов

Показать даты введения Admin

ГОСТ Р ИСО/МЭК 10165-4-2001

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ СТРУКТУРА ИНФОРМАЦИИ АДМИНИСТРАТИВНОГО УПРАВЛЕНИЯ

Ч а с т ь 4

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

Изданиеофициальное

БЗ 3-2001/47


ГОССТАНДАРТРОССИИ М о с к в а

Предисловие

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

ВНЕСЕНМинистерствомРоссийскойФедерациипосвязииинформатизации

2    ПРИНЯТИВВЕДЕН ВДЕЙСТВИЕПостановлениемГосстандартаРоссииотбсентября 2001г.№376-ст

3    Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК10165-4:1992«Информационнаятехнология.Взаимосвязьоткрытыхсистем.Структура информации административного управления. Часть 4. Руководство по определению управляемых объектов» с учетом Изменения № 1(1996г.)и Дополнений№ 1 (1996г.), №2(1998г.),№3 (1998г.)

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

©ИПК Издательство стандартов, 2001

Настоящий стандартне можетбыть полностью иличастичновоспроизведен, тиражирован и распространенвкачествеофициальногоизданиябезразрешенияГосстандартаРоссии

Содержание

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

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

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

4    Сокращения..............................4

5    Соглашения..............................4

6    Общие вопросы............................4

7Общиепринципыопределенияуправляемыхобъектов............................11

8Обозначениядляопределенийуправляемыхобъектов ..............................17

9РуководствопоразработкеэквивалентныхмодулейАСН.1:1994иАСН.1:1990..... 38

ЮСоглашениядляАСН.1идирективРОУО..................43

ПриложениеА Примеры.........................48

ПриложениеВ Руководствопоприменению2приформализацииповеденияуправляемых

объектов.........................52

Г О СУ ДА Р С Т В Е Н Н Ы Й СТА НДАР Т Р О С С И Й С К О Й Ф ЕД Е РА Ц И И

Информационнаятехнология

ВЗАИМОСВЯЗЬОТКРЫТЫХСИСТЕМ

СТРУКТУРАИНФОРМАЦИИАДМИНИСТРАТИВНОГОУПРАВЛЕНИЯ

Ч а с т ь 4

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

Informationtechnology.OpenSystemsInterconnection.Structureofmanagementinformation.

Guidelinesforthedefinitionofmanagedobjects

Дата введения2002—07—01

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

Настоящийстандартявляетсяруководствомдляразработчиковдругихстандартовирекомен-

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

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

б)гарантируетразработкуназванныхопределенийспособом,совместимымсостандартамии рекомендациямистандартовпоадминистративномууправлениюВОС;

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

Внастоящемстандартеопределены:

а)взаимосвязимеждустандартамиирекомендациями,относящимисякадминистративному управлениюВОС,иопределениямиклассовуправляемыхобъектов,атакжепринципыиспользова-нияэтихрекомендацийистандартоввопределенияхклассовуправляемыхобъектов;

б)методы,применяемыедляопределенияклассовуправляемыхобъектов,ихатрибутов,со-общений,действий и поведения, включая:

1)сводкувопросов,которыедолжныбытьотраженывопределении,

2)обозначения,которыерекомендуетсяиспользоватьвопределении,

3)руководствапосогласованности,которыммогутследоватьопределения;

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

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

Настоящийстандартприменяетсядляразработкилюбыхрекомендацийистандартов,опреде-

ляющих:

а)информациюадминистративногоуправления,котораядолжнабытьпереданаилиобрабо-танаспомощьюпротоколаадминистративногоуправленияВОС;

б)управляемыеобъекты,ккоторымотноситсяэтаинформация.

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

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

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

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

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

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

Издание официальное

ГОСТРИСО7498-3—97Информационнаятехнология.Взаимосвязьоткрытыхсистем.Базовая эталоннаямодель.Часть3.Присвоениеимениадресация

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

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

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

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

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

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

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

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

ИСО/МЭК9594-2—98*Информационнаятехнология.Взаимосвязьоткрытыхсистем.Справоч-ник.Часть2.Общееописаниепринципов,моделейиуслуг

ИСО/МЭК9596-1—98Информационнаятехнология.Взаимосвязьоткрытыхсистем.Протокол информацииадминистративногоуправления.Часть1.Спецификацияпротокола

ИСО/МЭК9834-1—93*Информационнаятехнология.Взаимосвязьоткрытыхсистем.Процеду-рыработыполномочныхоргановрегистрацииВОС.Часть1.Общиепроцедуры

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

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

ИСО/МЭК11587—96Информационнаятехнология.Взаимосвязьоткрытыхсистем.Примене-ниевконтекстесистемуправленияспроцессамитранзакции

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

3.1 Определения базовой эталонной модели

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

-(К)-соединение;

-    (К)-категория;

-(^-уровень;

-    (К)-пункт-доступа-к-услуге;

-    открытая система;

-административноеуправлениесистемы.

3.2 Определения наименования иадресации

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

7498-3:

-    (К)-селектор.

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

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

-управляемый объект;

-операция(К)-уровня.

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

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

-агент;

-родовыеопределения;

-    классуправляемых объектов;

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

-управляющий;

-протоколадминистративногоуправления(К)-уровня;

-сообщение;

-типсообщения;

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

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

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

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

-    действие;

-фактическийкласс;

-атрибутивнаягруппа;

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

-    тип атрибутов;

-    множество значений атрибута;

-поведение;

-    характеристика;

-условный пакет;

-вмещение;

-наследование;

-иерархиянаследования;

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

-реализация;

-    обязательный пакет;

-кратноенаследование;

-связывание имен;

-пакет;

-параметр;

-множестводопустимыхзначений;

-относительноеотличающееимя;

-множествотребуемых значений;

-специализация;

-подкласс;

-суперкласс;

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

-подчиненныйобъект.

3.6    ОпределениеУОИУ

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

а)    атрибут;

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

3


2*

3.7ОпределениеАСН.1ИСО/МЭК8824-1:

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

б)    тип «последовательность»;

в)    тип «последовательность—из»;

г)    тип множество;

д)    тип «множество—из»;

е)    подтип;

ж)    тип;

и) имя ссылки на тип; к) имяссылкиназначение.

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

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

3.8.2шаблон:Стандартныйформатдлядокументацииопределенияэлементаинформацииад-

министративногоуправления.

3.8.3класс объектов справочника: Классобъектов,определенныйвИСО/МЭК9594-2.

4 Сокращения

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

АСН.1—абстрактнаясинтаксическаянотацияверсии1;

БДУ—блокданныхуслуги;

ВОС—взаимосвязьоткрытыхсистем;

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

КУ—качествоуслуги;

МФО—методыформальногоопределения;

ООИ—относительноеотличающееимя;

ПБД—протокольныйблокданных;

ПДУ—пунктдоступакуслуге;

ПК—подкомитет;

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

РГ—рабочаягруппа;

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

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

СТК—совместныйтехническийкомитет;

УО—управляемыйобъект;

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

УОНЗ—управляемыйобъектначальныхзначений;

(М)-ПДУ—(М)-пункт-доступа-к-услуге;

5Соглашения

Внастоящемстандартешрифтом(полужирнымикурсивом)выделентекст,вкоторомисполь-зовананотацияАСН.1 илиопределеннаявразделе 8.

6 Общие вопросы

6.1    Целостностьвзаимосвязей

Приопределенииклассовуправляемыхобъектовважнорассмотретьситуации,когдаимеются

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

ситуации,когдаповедениеуправляемогообъектаограниченоправилами,зависящиминетолькоот

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

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

равляемыхобъектов.

Частным случаем, в котором определения, связанные с экземпляромуправляемого объекта, должныявнымобразомустанавливатьправиласогласования,являетсяоперацияудаления elete. Дляэтойоперациитакиеправиласогласованиязадаютсявсвязывании(иях)имен,ассоциирован-ном(ых)склассомуправляемыхобъектов.Результатоперацииeleteдолженбытьопределентаким образом,чтобыбылоясно,прикакихобстоятельствахудалениедопустимоикаковапоследователь-ностьудаления.Вчастности,связываниеимендолжноустанавливать,допустимолиудалениеэкзем-пляракласса,когдаещесуществуютсодержащиесявнемуправляемыеобъекты,икакие правила применяютсявслучаях,когдамеждуудаляемымипрочимиуправляемымиобъектамиестьдругие (неотносящиесяквмещению)взаимосвязи,какте,которыемогутсуществоватьвследствиенали-чияатрибутоввзаимосвязи(см.ИСО/МЭКЮ164-3).Применяемыедляудаленияправиласогласо-ванностидолжны быть такими, чтобы операция удаления не могла привести к несогласованным взаимосвязям.Хотяэтиправиласогласованностиопределяютсякакчастьсвязыванияимен,прави-ла,которыеприменяютсядляудаленияданногоуправляемогообъекта,устанавливаютсявмомент реализацииэтогоуправляемогообъекта.

6.2Наследуемыехарактеристики

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

6.3Факультативность

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

6.4 Регистрация

Процессопределенияклассовуправляемыхобъектовтребуетприсвоенияглобальнооднознач-ныхидентификаторов—идентификаторовобъектов—различнымсоставляющимклассауправляе-мыхобъектов,такимкакимяклассауправляемыхобъектов,типыатрибутовипр.Значенияэтих идентификаторовиспользуютвпротоколахадминистративногоуправлениядляоднозначнойиден-тификации различных сторон управляемыхобъектов и связанных с ними атрибутов, операций и сообщений.Следовательно,дляразработкиопределенияклассауправляемыхобъектовпредвари-тельнонеобходимо,чтобыорганыпостандартизацииилидругиеорганизацииидентифицировали илиустановилиподходящийметодрегистрации,позволяющийсоздаватьзначенияидентификато-ровобъектов.ИСО/МЭК8824-1устанавливаетструктуруидентификатораобъектаизначенияна-чальныхдуг;дальнейшаяинформацияобустановленииметодовиуполномоченныхпорегистрации приведенавИСО/МЭК9834-1.

Послетогокакэлементуинформацииадминистративногоуправлениябылоприсвоенозначе-

ниеидентификатораобъектатребуется,чтобыникакойпересмотропределенияэтогоэлементане

изменялсемантикуинформации.Напрактикеэтоозначает,чторедакционныеизменениязарегис-

трированныхопределенийинформацииадминистративногоуправлениддопускаются,ноопределе-

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

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

{joint-iso-ccitt ms(9)}

Распределениедугниже{|01п1-180-ее111 ms(9)}определяетсянастоящимстандартом. Ниже {joint-iso-ccitt ms (9)}дугираспределяютсянаосновестандартовпоадминистративномууправле-ниюсистемытак,какпоказановтаблице1.

Таблица1 — Распределениедугниже

Дуга

Стандарт

smo (0)

Основныеположенияадминистративногоуправлениясистемы,ГОСТ

РИСО/МЭК10040

cmip (1)

Протокол общей информации административного управления, ИСО/МЭК9596-1

function (2)

Функцииадминистративногоуправлениясистемы,ГОСТРИСО/МЭК

10164-1ипоследующиечастиэтогостандарта

smi (3)

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

РИСО/МЭКЮ165-1ипоследующиечастиэтогостандарта

applicationContext(4)

Прикладныеконтексты, ИСО/МЭК11587

Распределениедугнижеэтогоуровняопределенов6.4.1—6.4.5.Дуги,которыепотребуютсядля последующих стандартов по административному управлению системы, будут вводиться по мере необходимостиввидедополнениякнастоящемустандарту.

{joint-iso-ccitt ms(9)}


Примечание—Схемараспределениязначенийидентификаторовобъектов,описаннаявнастоящем подразделе,применяетсятолькодлязначенийидентификаторовобъектоввстандартахпоадминистративному управлениюсистемы,разработанныхсовместноРГ4ПК21СТК1ИСО/МЭКиМСЭ-Т.Еслидругиморганами организациямпо стандартизации необходимовходе разработки стандартов по административномууправле-нию системыраспределять значения идентификаторов объектов, они должны установитьсвои собственные схемыраспределениянижесоответствующегоуполномоченногопорегистрации.Структура,принятаяприраз-работке таких стандартов, может служить в качестве примера того, как устанавливается подходящая схема распределениязначений,нозаокончательныйвыборсхемыотвечаетсоответствующаяорганизация.Дляобес-печениячитаемостизначенийидентификаторовобъектоврекомендуетсяиспользоватьименнуюичисловую формыпредставлениязначенийидентификаторовобъектов,какопределеновИСО/МЭК8824-1.

6.4.1 Распределение идентификаторов объектов для основных положений административного управления системы

Примечание — Выделение этихдуг определяется основными положениями административного управлениясистемы.Здесьониприводятсятольковсправочныхцелях.

Ниже {joint-iso-ccitt ms (9) smo (0)} выделеныдугидлярегистрацииидентификаторовпри-кладныхконтекстов,абстрактныхсинтаксисовимодулейАСН.1,приведенныевтаблице.2.

{joint-iso-ccitt ms (9)smo (0)}


Таблица2 — Распределениедугниже

Дуга

Назначение

applicationContext (0)

Распределениеидентификаторовприкладныхконтекстов

negotiationAbstractSyntax(1)

Распределениеидентификаторовверсийдоговорныхабстрактныхсин-

таксисов

asn1Modules (2)

РаспределениеидентификаторовмодулейАСН.1

Н иже {joint-iso-ccittms(9)smo(0)applicationContext(0)}, как установлено в ГОСТ Р ИСО/МЭК 10040, выделены дуги для регистрации идентификаторов конкретных прикладных контекстов, приведенныевтаблице 3.

{joint-iso-ccitt ms (9)smo (0)applicationContext (0)}


Таблица3 — Распределениедугниже

Дуга

Назначение

systems-management (2)

Идентификацияприкладныхконтекстовадминистративногоуправле-

ниясистемы

н иже {joint-iso-ccittms(9)smo(0)negotiationAbstractSyntax(1)}, как установлено в ГОСТРИСО/МЭК10040,выделеныдугидлярегистрацииконкретныхверсийдоговорныхабстрак-тныхсинтаксисов,приведенныевтаблице4.

Таблица4 — Распределениедугниже

Дуга

Назначение

version (1)

Идентифицируетверсию1договорногоабстрактногосинтаксиса

Hиже{joint-iso-ccittms(9)smo(0)asn1Modules(2)},какустановленовГОСТРИСО/МЭК

{joint-iso-ccitt ms (9)smo (0)negotiationAbstractSyntax (1)}


10040,выделеныдугидлярегистрацииидентификаторовконкретныхмодулейАСН.1,приведенные

втаблице5.

{joint-iso-ccitt ms (9)smo (0)asn1Modules (2)}


Таблица5 — Распределениедугниже

Дуга

Назначение

negotiationefinitions (0)

РаспределениеидентификаторовверсийдлямодулейАСН.1,которые

содержатопределения,связанныесдоговорнымабстрактнымсинтакси-

сом

Hиже{joint-iso-ccitt ms(9)smo(0)asn1Modules(2)negotiationefinitions(0)},какустановле-

новГОСТРИСО/МЭК10040,выделеныдугидлярегистрацииконкретныхверсиймодулейАСН.1,

приведенныевтаблице6.

{joint-iso-ccitt ms (9)smo (0)asn1Modules (2)negotiationefinitions (0)}


Таблица6 — Распределениедугниже

Дуга

Назначение

version1 (1)

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

6.4.2Распределение идентификаторов объектов для ПОИУ

Примечание—ВыделениеэтихдугопределяетсяПОИУ.Здесьониприводятсятольковсправочных

целях.Версия1ПОИУустарелаизамененаверсией2.Версия1былаопределенаИСО/МЭК9596-1инеимела

аналогичнойрекомендацииМККТТ.

Hиже{joint-iso-ccittms(9)cmip(1)}выделеныдугидлякаждойверсииПОИУтак,какописа-

нов6.4.2.1и6.4.2.2.

6.4.2.1ПОИУверсии1

Ниже {joint-iso-ccitt ms (9) cmip (1)}выделеныдугидляверсии 1 ПОИУтак, какпоказанов таблице7.

{joint-iso-ccitt ms (9)cmip (1)}дляПОИУверсии1


Таблица7 — Распределениедугниже

Дуга

Назначение

version1 (1)

РаспределениеидентификаторовобъектовдляПОИУверсии!

Ниже {joint-iso-ccitt ms (9) cmip (1)version1 (1)}дляцелей,описанныхвИСО/МЭК9596-1, выделеныдугитак, какпоказановтаблице 8.

Таблица8 — Распределениедугниже

{joint-iso-ccitt ms (9)cmip (1)version1 (1)}

Дуга

aAssociateUser Info(1) aAbortUser Info (2) protocol (3) abstractSyntax(4)

6.4.2.2ПОИУверсии2

Ниже {joint-iso-ccitt ms (9)cmip (1)}выделеныдугидляверсии2ПОИУтак, какпоказанов таблице9.

Таблица9 — Распределениедугниже

{joint-iso-ccitt ms (9)cmip (1)}дляПОИУверсии2

Дуга

Назначение

modules (0)

РаспределениеидентификаторовобъектовдлямодулейАСН.1ПОИУ

cmip-pci (1)

Распределение идентификаторов объектов для управляющей инфор-мацииПОИУ

Ниже {joint-iso-ccitt ms (9) cmip (1) modules (0)}дляцелей, описанныхв ИСО/МЭК9596-1, выделеныдугитак,какпоказановтаблице10.

Таблица10 — Распределениедугниже

{joint-iso-ccitt ms (9)cmip (1)modules (0)}

Дуга

aAssociateUser Info (1) aAbortUser Info (2) protocol (3)

Ниже {joint-iso-ccitt ms (9)cmip (1) cmip-pci (1)}дляцелей,описанныхвИСО/МЭК9596-1, выделеныдугитак, какпоказано втаблице 11.

Таблица11 — Распределениедугниже

{joint-iso-ccitt ms (9)cmip (1)cmip-pci (1)}

Дуга

reserved1(1) reserved2 (2) reserved3 (3) abstractSyntax (4)

6.4.3Распределение идентификаторов объектов для стандартов функций

Ниже {joint-iso-ccitt ms (9)function (2)}выделеныдугидляидентификациистандартовфунк-цийтак, какпоказановтаблице 12.

8

Таблица 12 — Распределениедугниже

Дуга

Стандарт

partX(X)

(ГОСТР) ИСО/МЭК 10164-Х, гдеХ — номерчасти

Дугиниже {joint-iso-ccitt ms (9)function (2)partX(X)}показанывтаблице13.

{joint-iso-ccitt ms (9) function (2)}


{joint-iso-ccitt ms (9)function (2)partX(X)}


Таблица 13 — Распределениедугниже

Дуга

Назначение

standardSpecificExtension(0)

Специфическиедлястандартарасширениясхемыраспределения

functionalUnitPackage(1)

Распределениеидентификаторовпакетовфункциональныхблоков

asn1Modules (2)

РаспределениеидентификаторовмодулейАСН.1

managedbjectClass (3)

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

package (4)

Распределениеидентификаторовпакетов

parameter (5)

Распределениеидентификаторовпараметров

nameBinding (6)

Распределениеидентификаторовсвязыванийимен

attribute(7)

Распределениеидентификатороватрибутов

attributeGroup(8)

Распределениеидентификатороватрибутивныхгрупп

action (9)

Распределениетиповдействий

notification(10)

Распределениетиповсообщений

relationshipClass(11)

Распределениеидентификаторовклассовуправляемыхвзаимосвязей

relationshipMapping(12)

Распределениеидентификаторовотображенийвзаимосвязей

relationshipRole (13)

Распределениеидентификаторовролейвзаимосвязей

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

6.4.4 Распределение идентификаторов объектов для стандартов СИУ

Ниже {joint-iso-ccitt ms (9) smi (3)}выделеныдугидляидентификациистандартовСИУтак, какпоказановтаблице14.

{joint-iso-ccitt ms (9)smi (3)}


Таблица 14 — Распределениедугниже

Дуга

Стандарт

partX(X)

(ГОСТР) ИСО/МЭК 10165-Х, гдеХ — номерчасти

Дугиниже {joint-iso-ccitt ms (9)smi (3)partX(X)}показанывтаблице15.

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

Таблица 15 — Распределениедугниже

{joint-iso-ccitt ms (9)smi (3)partX(X)}

Дуга

Назначение

standardSpecificExtension (0)

Специфическиедлястандартарасширениясхемыраспределения

asn1Modules (2)

РаспределениеидентификаторовмодулейАСН.1

managedbjectClass (3)

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

package (4)

Распределениеидентификаторовпакетов

parameter (5)

Распределениеидентификаторовпараметров

nameBinding (6)

Распределениеидентификаторовсвязыванийимен

attribute(7)

Распределениеидентификатороватрибутов

attributeGroup (8)

Распределениеидентификатороватрибутивныхгрупп

action (9)

Распределениетиповдействий

notification(10)

Распределениетиповсообщений

relationshipClass(11)

Распределениеидентификаторовклассовуправляемыхвзаимосвязей

relationshipMapping (12)

Распределениеидентификаторовотображенийвзаимосвязей

relationshipRole (13)

Распределениеидентификаторовролейвзаимосвязей

6.4.5Идентификатор объектадля фактического класса

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

{joint-iso-ccitt ms (9)smi (3)part4 (4)managedbjectClass (3)actualClass (42)}

присвоенонастоящимстандартомдлявыражениясемантики«фактическийкласс»,определеннойв

ГОСТРИСО/МЭКЮ165-1.Когдаэтозначениеиспользованодляспецификациибазовогокласса

управляемыхобъектоввзапросеоперацииУОИУ,оноуказывает,чтополучательоперацииадмини-

стративногоуправлениясистемыдолженответитькакчленсвоегофактическогокласса.Управляе-

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

бута«классуправляемогообъекта».

6.5 Соответствие

Общиетребованиясоответствия,относящиесякстандартаминформацииадминистративного

управления,установленывГОСТРИСО/МЭК10040.

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

Впроцессемоделированиядолжнабытьминимизированасложностьопределенийуправляемых

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

ми,чемсоответствующиесвойстваучаствующейвоперациисредыВОС.

6.7 Созданиеиудалениеуправляемогообъекта

Созданиеиудалениеэкземпляровуправляемыхобъектовможетпроисходитьследующимиме-

тодами:

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

административногоуправления.Дляэтихцелейопределеныоперациисозданияиудаленияссоот-

ветствующейсемантикой;

-управляемыеобъектымогутбытьсозданыиудаленыврезультатеоперацийресурса,ккото-ромуониотносятся,обычно—протокольногоавтомата.Вэтомслучаеоперациисозданияиудале-ниянемогутбытьопределены.Примеромявляетсяпредставлениесоединенийдляцелейадминис-тративногоуправления;

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

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

сяотвыбораметодаудаления.

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

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

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

6.7.1Управляемые объекты начальных значений

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

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

Когдадля изменения атрибутовУОНЗ используются операции административного управле-ния,атрибутысозданныхранеесиспользованиемэтогоУОНЗуправляемыхобъектовнеизменяют-ся.Аналогичнооперацииадминистративногоуправления,осуществляемыенадатрибутамиуправ-ляемыхобъектов,созданныхсиспользованиемУОНЗ,невлияютнаатрибутыУОНЗ.

6.7.2Источники начальны х значений атрибутов

Начальныезначенияатрибутовуправляемыхобъектов,используемыевовремясоздания,по-лучаютсяизнесколькихисточников,какопределеновГОСТРИСО/МЭКЮ165-1.Когдаатрибут представляет конкретноезначение, котороедолжно быть согласованным с нижележащимресур-сом,этозначениеявляетсяобязательным.

7 Общие принципы определенияуправляемых объектов

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

7.1Общность

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

ватьвкачествеосновы:

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

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

10165-2.

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

7.2Задачиуправления

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

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

7.3Структурирование

Дляпредставленияструктурыуправляемыхобъектовимеетсярядспособов,позволяющихот-

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

своипреимуществаинедостатки;выборнаиболееподходящихспособовдляконкретнойспецифи-

кациизависитотрядаописанныхнижекритериев.

Способыструктурирования,описанныевГОСТРИСО/МЭК10165-1,включаютвсебя:

-атрибутивныегруппы;

-подклассы(специализацию);

-кратноенаследование;

-вмещаемыеуправляемыеобъекты;

-пакеты.

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

Однимизважныхкритериеввыбораспособаструктурированияявляетсястатическоеилиди-намическоеприсутствиегруппы.Eслиприсутствиегруппыфиксированонамоменгспецификации, топодходящимспособомможетоказатьсяиспользованиеатрибутивныхгрупп,подклассов,кратно-гонаследованияиливмещаемыхуправляемыхобъектов.Еслиприсутствиефиксированонамомент реализацииилиустановки,томожетоказатьсяподходящимиспользованиевмещаемыхуправляе-мыхобъектовилиусловныхпакетов.Еслиприсутствиегруппыможетизменятьсязавремяжизни вмещающих (или инкапсулирующих) управляемыхобъектов, то можетоказаться подходящимис-пользованиевмещаемыхуправляемыхобъектов,которыединамическисоздаютсяиуничтожаются.

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

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

использоватьсялюбойизпятиперечисленныхметодов.

7.4Управляемыеобъекты

7.4.1    Реализация суперклассов

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

Внекоторыхслучаях,вчастности,когдаподклассыопределяютсядляпересмотрастандарта,

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

7.4.2    Неограниченные суперклассы

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

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

-синтаксис(тип)каждогоатрибутаследуетопределятьтакимобразом,чтобывключитьвнего

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

рыеизэтихзначенийнеявляютсянемедленнонеобходимымиилижелательными;

-следуетобеспечиватьвозможностирасширениявкаждомопределениидействияилисообще-

ния;

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

-следуетопределятьконкретныеподклассыэтогонеограниченногосуперкласса,которыеус-

танавливаюттребуемыеограничениянаатрибуты,действияисообщения.

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

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

7.4.3 Ф актический класс

ОпределениеклассауправляемыхобъектовсостоитизшаблонаMANAGE BJECT CLASS (см.8.3),зарегистрированногосозначениемидентификатораобъектадляэтогокласса,наборашаб-лонов, накоторыессылаетсяданныйшаблон,ивсехшаблонов, накоторыессылаютсяшаблоны этогонабора.

Управляемыйобъектидентифицируетсвойфактическийклассспомощьюзначенияатрибута «классуправляемогообъекта»,котороеявляетсязначениемидентификатораобъекта,использован-ногодлярегистрацииегошаблонаMANAGE BJECT CLASS.Каждыйуправляемыйобъект:

-    обеспечивает все характеристики, определенные для его фактического класса, в соответ-ствиисприсутствующимипакетами;

обеспечиваеттолькотеоперации,которыеопределенывегофактическомкласседляприсут-

ствующихпакетов;

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

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

7.5Атрибуты

7.5.1 Множества значений атрибутов

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

Можетоказатьсянеобходимымопределитьвырожденныезначения(пи11)какдопустимыезна-чения атрибута или, в случае атрибутовУОНЗ, определить значения атрибута с присвоенной им конкретнойсемантикой,такойкак«создатьуправляемыйобъектсозначениемпи1]длясоответству-ющегоатрибута»или«игнорироватьэтотатрибуткакисточникначальногозначения».Методыопре-делениятакихзначенийвключаютвсебяопределениеабстрактногосинтаксисавыборочноготипа, когда один выбор определяет нормальное множество значений атрибута, а другой — значения с присвоеннойконкретнойсемантикой.

Определениемножествадопустимыхзначенийатрибутаможетбытьполученоразнымиспосо-

бами,включая:

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

-определениевторогоатрибута,значениекоторогоуказываетмножествозначений,которые

можетприниматьрассматриваемыйатрибут.

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

7.5.2 Типы атрибутов

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

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

7.6    Взаимосвязи значенийатрибутов

Значениеатрибутаможетбытьограниченонекоторымифункциямидругихзначенийатрибутов.

Всевзаимосвязитакогородадолжныбытьидентифицированы.

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

Когдазначениеатрибутаограниченодругимиатрибутамивразныхуправляемыхобъектах(если

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

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

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

ния,требованияреализуютсячерезвозможностьэлементарноймежобъектнойсинхронизацииУОИУ.

Общиепроблемысинхронизациимеждунесколькимиоперациямиуправления,междуразны-

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

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

7.7    МоделированиеПДУ

Существуетобщеетребование—представлятькакчастьсвязаннойсослоемструктурыуправ-ляемогообъекта,взаимосвязимежду(^-категориями,(^-селекторамии^+1)-категориями.Воз-можныразличныерешения,например:

-моделированиевзаимосвязикакинформации,содержащейсявуправляемыхобъектах^+1)-

уровня;

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

(М)-уровня;

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

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

Настоящимстандартомрекомендуетсявторойизперечисленныхподходов.Вчастности,

(М)-ПДУдолжныбытьпредставленыотдельнымиуправляемымиобъектами,которыеимеютвка-

чествеатрибутовадреса(идругуюинформацию),вместесвзаимозаменяемымиатрибутами,указы-

вающиминауправляемыеобъекты(М)-и(М+1)-категории,ассоциированныес(М)-ПДУ.Дляре-

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

ВОС,рекомендуется,чтобыуправляемыеобъекты(М)-ПДУсодержалисьвуправляемыхобъектах,

соответствующих(М)-категориям,скоторымионисвязаны.

П римечание — Названное выше требование согласованности состоит в том, что адрес (N)-категориивместес(М)-селекторомдолженоднозначноидентифицировать(М+1)-категорию(илинабор(М+1)-категорийодногоитогожетипа).Принимая,чтоэтотребованиеравносильнотребованиюоднозначностидля присвоениязначений(N)-селектороввконтекстеданной(N)-категории,обеспечениетребованиясогласован-ности может быть более просто достигнуто, если информация селектора обеспечивается (N)-, ане (N+1)-категорией.

7.8 Статистика

7.8.1    Согласованность

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

тистикойуровней,принимаяпринципыГОСТРИСО/МЭК7498-1;вчастности,понятие«регис-

трируемаяинформация»относитсякинформации,рассматриваемойприадминистративномуправ-

лениичерезуправляемыеобъекты,представляющиересурсы,ккоторымотноситсяинформация.

Кандидатамивхарактеристики(N)-слоя,статистикакоторыхможетрегистрироваться,отно-

сятся:

-локальныеошибки;

-успешныйравноправныйобмен;

-взаимныеотказы;

-отказывуслуге.

Например,применениеопределенныхвышепринциповксоединению,определенномувГОСТ РИСО/МЭК7498-1, приводиткидентификацииследующихосновныххарактеристик:

-числоустановленныхсоединений(N)-категорийсдругимипарнымикатегориями(N)-слоя; -числолокальныхотказовприустановленныхсоединениях(N)-категорий; -числоотказовпривзаимныхсогласованияхдлясоединений(N)-категорий; -числоотвергнутых^—1)-соединенийспоставщикаминижележащихуслуг. Этотнаборстатистическиххарактеристикобеспечиваетсогласованныйвзгляднато,чтопро-исходитнакаждомуровне (вслучае, ориентированномнасоединении) бездублированиясчет-чиков.

Примечание — Аналогичныемоделитребуютсядляошибок,разрывовсоединенийипр.

7.8.2    Счетчики ПБД

АвторыопределенийуправляемыхобъекговдолжныспецифицироватьсчетчикиПВД(N)-уровня (иоктетовПБД),ане БДУ (иоктетов БДУ).

Примечание—ВероятнотребуетсяподсчитыватьтолькочислооктетовПБДнаограниченномчисле

(N)-уровней.

7.8.3    Перекрытия

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

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

чиваяподсчетзапросовотправкипервогоПБДизапросовотправкиответногоПБД,необязательно

увеличиватьобасчетчикаодновременно.СуммаэтихсчетчиковвсегдаравнаобщейотправкеПБД.

7.8.4    Непереустанавливаемые счетчики

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

7.8.5    Счетчики событий

Должен быть обеспечен подсчет событий административно управляемого ресурса, которые приводятксозданиюсообщений,т.к.созданиеУОИУМ—EVENT—КБРОЯТможетбытьподавлено опережающимидискриминаторамисобытий.

7.9Счетчики

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

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

-модулиопределяютсясоответствующимиатрибутами;

-модулиопределяютсяреализациейиспецифицированывЗСУО.

Примечание—Дляклассовуправляемыхобъектов,определенныхСТК1 ИСО/МЭКдляуровней 1—4, принятподход, прикоторомсчетчикиникогданесбрасываются.

7.10 Таймеры

Преимуществамогутбытьполученыпринаследованииобщейспецификацииточности,ско-

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

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

Примечание—Дляклассовуправляемыхобъектов,определенныхСТК1 ИСО/МЭКдляуровней 1—4, с целью обеспечения достаточно большого диапазона без экстраординарной точности для выражения значенийтаймеровиспользованопредставлениесплавающейточкойсмантиссойдлиной16битиэкспонен-тойдлинойдо 16бит. (Этонеподразумевает,чтодолжнаиспользоватьсяарифметикасплавающейточкой). Системыдолжныбытьвсостояниисохранятьзначениясэтойточностью.Допускаядругиеограничения,дол-жнобытьпринятотребованиеустанавливатьатрибуттаймерасэтойточностью.

7.11Обновлениеатрибутов

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

7.12 Точностьатрибутов

Управляющаясистемаможетпопытатьсяустановитьзначениеатрибутасбольшейточностью,

чемобеспечиваетсяуправляемойсистемой.Такиевысокоточныезначениямогутбытьаппроксими-

рованыближайшимзначениемустановленнойточности.

7.13Идентификацияуправляемогообъекта

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

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

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

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

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

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

средивсехдругих,поименованныхтемжесамымстаршимобъектом.

Приудаленииуправляемогообъектазначение,присвоенноеегоименующемуатрибуту,ста-

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

создаваемыхвдальнейшемвтомжесамомстаршемобъекте.

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

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

7.14Сообщения

7.14.1    Отказ услуги

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

7.14.2    Сохранение информации

Сообщениясодержатинформациюособытии,котораяиначемоглабытьпотерена.Например:

-заголовокполяполученногоПБД,длякоторогобылаобнаруженаошибкапротокола;

-статистическиеданныеосоединении,котороедолжнобытьзавершено;

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

7.15 Использованиеопераций

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

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

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

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

г)еслинепосредственнымрезультатомявляетсяустановлениезначенийатрибутовуправляе-могообъектаравнымизначениямпоумолчанию(приусловии,чтотакиезначениябылиопределе-ны),тоиспользуетсяоперацияReplace—with—default—value;

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

е)еслинепосредственнымрезультатомявляетсяполучениеотуправляемогообъектазначений атрибутов,тоиспользуетсяоперацияGet—attribute—value;

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

1)невозможноопределитьтребуемуюоперациюнадмножествомуправляемыхобъектов с использованием области действия и фильтров вместе с операциями Get—attribute—value, Replace—attribute—value, Replace—with—default—value, Greate, elete, Add—member или Remove—member;

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

3)влияниеоказываетсянанесколькообъектовбезобщихатрибутов;

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

Понятия непосредственного ипобочного результатов рассмотренывГОСТРИСО/МЭК 10165-1.

8 Обозначения для определений управляемых объектов

8.1    Обзоробозначений

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

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

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

8.2    Соглашения,использованныевопределенияхшаблонов

Шаблонначинаетсясметки-шаблонаиименишаблонаТЕМРЬЛТЕ—NAME. Шаблон со-держитоднуилинесколькоконструкций, каждаяизкоторыхимеетимяCNSTRUCT—NAME и можетиметьаргумент-конструкции.Аргумент-конструкцииможетсостоятьизнесколькихэлемен-товдлявызоваизопределенияконкретнойконструкции.Длякаждогоиспользованияшаблонадек-ларируетсяуникальнаяметка-шаблона,спомощьюкоторойможноссылатьсяиздругихшаблонов наданныйэкземпляршаблона,и,еслиприсутствуетконструкцияREGISTERE ЛS,присваивает-сязначениеидентификатораобъектаАСН.1,подкоторымзарегистрированданныйэкземплярис-пользования шаблона. Символ «;» используется в качестве признака конца каждой конструкции (кромеREGISTERE AS и EFINE AS)иконцашаблона.

Дляупрощенияструктурышаблонов,например,когдаоднаитажесинтаксическаяструктура

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

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

supportingproductions

вконцеопределенияшаблонаисостоятизпродукцийвида

кметка-определения] -j ксинтаксическое-определение]

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

Определенияшаблоновоснованынаследующихсинтаксическихсоглашениях:

а)    все терминальные символы и ключевые слова, образующие часть определения шаблона, зависятотрегистра;

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

1)меткой-шаблонаи    TEMPLATE-NAME;

2)    TEMPLATE-NAME и CNSTRUCT-NAME;

3)    CNSTRUCT-NAME иаргументом -конструкции.

Междулюбойпаройэлементоввшаблонеможетбытьвставленодинилинесколькораздели-

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

в)пробелы,пустыестроки,комментариииконцыстрокимеютсмыслтолькокакраздели-

тели;

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

д)символ

долженотмечатьконецкаждойконструкциившаблоне(кромеREGISTERE ЛSи EFINE AS) и конец самого шаблона;

е)дляпредставленияидентификаторовобъектовдолжнаиспользоватьсянотация,определен-наявИСО/МЭК8824-1,напримерпродукция

идентификатор-объекта-j kbjectIdentifierValuej представляет продукции для всех определений шаблонов настоящего стандарта, а bjectIdentifierValueуказываетнасоответствующуюнотацию,определеннуювИСО/МЭК8824-1;

ж)    строки, ограниченные парой

[ ]

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

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

з)    строки, ограниченные парой

к j

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

использованияшаблона.Структураисмыслподставляемойстрокизависятотеетипа;

и)прописныестрокиобозначаютключевыеслова,которыеобязательнодолжныприсутство-ватьвкаждомслучаеиспользованияшаблона,еслионинезаключенывквадратныескобки

[ ]

дляуказанияихфакультативности; к) символ

I

используетсякакразделительальтернативныхстроквсинтаксических-определенияхобеспечиваю-

щихпродукцийsupportingproductions.Когдаобеспечивающаяпродукцияиспользуетсядляопреде-

ленияальтернативныхстрок,открывающимразделителемпервойальтернативыявляется-],символ

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

разделителемпоследнейальтернативыявляетсяпервыйконецстрокипослеееоткрывающегораз-

делителя;

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

Требование уникальностиметки-шаблонанезависитоттипапомечаемого шаблона. Например, еслиметкаlabellиспользованавдокументедляэкземпляраиспользованиянекоторогошабло-на,тонедопускаетсяпомечатьметкойlabellэкземпляриспользованияшаблонатогожесамогоили другоготипа.

Когда метка-шаблона объявлена в документе А и указывается из документа В, то ссылка в документеВдолжнаиметьвкачествепрефиксаглобальнооднозначноеимядокументаА.Вслучае документов,названныхмеждународнопризнаннымиуполномоченнымипонаименованиям,таки-микакМККТТилиИСО/МЭК,должныиспользоватьсявкачествеидентификаторовзарегистри-рованныеобозначениядокументов,такиекак«CCITT Rec.X.722 (1992)|IS/IEC 10165-4 :1992». Форматэтойстрокидолженбытьустановленуполномоченнымпонаименованиямдлярассматри-ваемогодокумента.КогдарассматриваемыйдокуменгсовместноразработаниопубликованМККТТ иИСО/МЭК,обозначениедокументадолжносодержатьобаобозначения,разделенныезнаком «|»,какпоказановприведенномпримере.Еслиглобальнооднозначноеимянесуществует,допус-кается присвоение указываемому документу значения идентификатора объекта и использование этогозначениявкачествеглобальнооднозначногоименидокумента.Определенныйвышесинтак-сисметки-шаблонавыглядитследующимобразом:

[идентификатор-документа:]кстрока-метки] идентификатор-документа—

«<имя-стандарта»|идентификатор-объекта

Строка-меткиможетвключатьвсебялюбоечислоследующихсимволов:

1)    прописные и строчные алфавитные символы;

2)    цифры 0—9;

3)    символ

4)    символ

/

в любом порядке, начиная со строчного алфавитного символа, за исключением того, что пара символов

недолжнапоявлятьсявстроке-метке.Например,следующаяметка-шаблона «CCITT Rec.X.722(1992)|IS/IEC 10165-4 : 1992» :examplebjectClass

являетсяглобальнооднозначнойметкойдляопределенияexamplebjectClassвприложенииА.

Ссылканаметкубезпрефиксаидентификатор-документауказываетнаметку,объявленнуюв

томжедокументе,чтоиссылка.

м)влюбомместешаблона,гдеметка-шаблонаприсутствуеткакуказаниенадругойшаблон,

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

используетсядлявсехэкземпляровметки-шаблонаиопределения-шаблона; н) когда необходимо сослаться из шаблона на определение значения или типа АСН.1, имя типаилизначенияАСН.1имеетвкачествепрефиксаимямодуляАСН.1,содержащегоопределение этого типа или значения. При этом принимается, что имя модуля относится к модулю АСН.1, находящемуся в том же самом документе, что и шаблон, из которого дается ссылка на тип или значение.Следовательно,обеспечивающиепродукции указание-типа- <имя-модуля .<имя-типа указание-значения- <имя-модуля .<имя-значения используютсядлявсехопределенийшаблонов,которыессылаютсянатипыилизначения АСН.1, гдеимя-модуля—имя,присвоенноемодулюАСН.1вдокументе,содержащемссылку,аимя-типа иимя-значения—имена, присвоенныеопределениямтиповилизначенийАСН.1, содержащимся в этом модуле. Если необходимо сослаться на определения типов или значений, содержащиеся в другихдокументах,тоэтоможносделатьспомощьюлокальногомодуляАСН.1,которыйиспользу-етутверждение!MР RTдляимпортасоответствующихопределенийтиповилизначений.(См.раз-дел 9.)

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

!"# S % л &    *    ’    ‘    ?@\

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

Следовательно, обеспечивающие продукции выделенная-строка-

разделитель-текста<текстовая-строкаразделитель-текста|<текстовая-строка разделитель-текста- !|"| <#|S|%|A|&|*|’|‘|    |    ? | @ | \

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

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

8.3 Шаблон классауправляемых объектов

8.3.1    Обзор

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

8.3.1.1    Наследование

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

8.3.1.2Обязательныепакеты

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

8.3.1.3Условныепакеты

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

8.3.1.4Наименованиекласса

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

8.3.2    Структура шаблона

<метка-класса    MANAGE BJECT CLASS

[ ERIVE FROM    <метка-класса

[,<метка-класса]*;

]

[CHARACTERIZEBY    <метка-пакета

[,<метка-пакета]*;

]

[CNITI NALPACKAGES< метка-пакета

PRESENTIFопределение-условия

[,<метка-пакета

PRESENTIFопределение-условия]*;

]

REGISTEREЛSидентификатор-объекта;

supporting productions

определение-условия-выделенная-строка

8.3.3    Обеспечивающие определения

8.3.3.1ERIVE FR M <метка-класса[,<метка-класса]*

Конструкция E RIV E F R Mдолжнаприсутствоватьвовсехопределенияхклассовуправля-емыхобъектов, кроме высшего. Следовательно, высшийявляетсясуперклассомдлявсехклассов управляемыхобъектов,кромесамогосебя.

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

Процесс наследования (специализации) требует, чтобы все характеристики суперкласса(ов) быливключенывопределениеподкласса.

Характеристики, которыенаследуютсяотсуперкласса, недолжныповторятьсявдокумента-цииподкласса,еслинеиспользуетсяниодинизописанныхвнастоящемстандартеметодоврасши-ренияиизмененияопределения,наследуемогоизсуперкласса.Следовательно,конструкция E RIV E F R Mподразумеваетавтоматическийимпортвсеххарактеристикизопределения(ий)суперкласса-(ов).Этихарактеристикимогутбытьрасширеныилиизмененыэлементами,определеннымивкон-струкцияхCHARACTERIZE BY и CNITINAL PACKAGES.

Примечание1—Переченьвсехклассовуправляемыхобъектов,характеристикикоторыхнаследует

определяемыйкласс,рекомендуетсяввидекомментариявключатьвдокументациюопределенияклассауправ-

ляемыхобъектов.

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

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

а) BEHAVIUR. Пакеты, включаемыевподкласс,расширяютнаследуемоеповедение. Пове-дениеклассауправляемыхобъектовдолжнобытьвыраженотакимобразом,чтобыучитыватьвоз-можноеприсутствиеилиотсутствиеусловныхпакетов.Когдаповедениерасширяется,тоустанов-ленныеилиподразумеваемыепредусловиямогутбытьтолькоослаблены(обязательныепредусловия должныоставатьсятемижеилиихчисломожетбытьуменьшено),установленныеилиподразумева-емыепостусловиямогутбытьтолькоусилены(должныудовлетворятьсятежепостусловияимогут удовлетворяться дополнительные), а установленные или подразумеваемые инварианты остаются неизменными,номогутбытьдобавленыновые(см.ГОСТРИСО/МЭКЮ165-1,5.2.2.6);

Примечание 2 — Принекоторыхобстоятельствахмогутбытьопределеныподклассы, которые не требуютопределениядополнительногоповедениясверхтого,котороенаследуетсяотсуперкласса(ов);

б)    ATTRIBUTES .Впакетах,включаемыхвопределениеподкласса,могутбытьспецифициро-ваны пакеты. Когда конструкция ATTRIBUTES в пакете идентифицирует атрибут, который неоднократноопределенвклассеуправляемыхобъектов,применяютсяследующиеправила:

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

2)результирующийсписок-свойствестьлогическоеили(    R )включенныхвподкласси наследуемыхсписков-свойств,заисключениемсвойствPERMITTEVЛLUES,длякоторого реализуемоемножестводопустимыхзначенийявляетсяпересечениемвсехспецификацийдо-пустимыхзначенийдляэтоготипаатрибута,иPEQUIRE VALUES, длякоторогореализуе-моемножествообязательныхзначенийявляетсяпересечениемреализуемогомножествадопу-стимыхзначенийсобъединениемвсехспецификацийобязательныхзначенийдля этого типа атрибута.EслидлясвойстваатрибутаEFЛULTVЛLUEили INITIAL VЛLUEвсовокупности определенийзаданыпротиворечивыезначения,товключаемыйвподкласспакетдолженраз-решатьэтотконфликт,

3)    параметры, связанные с данным атрибутом, являются объединением всех параметров, связанныхсшаблономатрибута, ивсехпараметров, связанныхсатрибутомвовсехтех пакетах, которыереализуются.

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

Примечание3—Атрибуты,используемыедлянаименования,могутбытьвыбраныизчислалюбых атрибутов, которые являются частью определения класса. В их число входят все атрибуты, наследуемые от суперклассовидобавленныекклассуврезультатеспециализации;

в)    ATTRIBUTE GRUPS. Для расширяемой атрибутивной группы множество ее членов в экземпляреподклассаявляетсяобъединениемвсехатрибутов,определенныхвшаблонеатрибутив-нойгруппыидобавленныхкэтойгруппевсуперклассе(ах)иливподклассе;

г)ЛCTINS.Вопределениеподклассамогутбытьвключеныдействия;этомогутбытьдействия вдополнениекнаследуемымотсуперклассов,илионимогутвключатьдополнительныепараметры длянаследуемыхдействий.Множествопараметров,связанныхсданнымдействием,являетсяобъе-динением всех параметров, связанных с шаблоном действия и с действием во всех тех пакетах, которыереализуются;

д)    NTIFICATI NS. В определение подкласса могут быть включены сообщения; это могут бытьсообщениявдополнениекнаследуемымотсуперклассовилионимогутвключатьдополни-тельныепараметрыдлянаследуемыхсообщений.Множествопараметров,связанныхсданнымсооб-щением,являетсяобъединениемвсехпараметров,связанныхсшаблономсообщенияиссообще-ниемвовсехтехпакетах,которыереализуются.

Еслипакетвключенвопределениеклассауправляемыхобъектовнесколькораз,путемнасле-дованияи(или)неоднократнымвключениемвшаблонклассауправляемыхобъектов,торезульти-рующееопределение-условия,связанноеспакетом,являетсялогическимИЛИвсехопределений-условий в совокупном множестве определений. Для этой цели пакеты, входящие в конструкции CHARACTERIZE BY (обязательные пакеты), рассматриваются как входящие в конструкцию C N ITI NAL PACKAGESсопределениемусловияPRESENTIF |TRUE|.

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

8.3.3.2CHARACTERIZE BY<метка-пакета[,<метка-пакета]*

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

8.3.3.3 CNITI NAL PACKAGES<метка-пакетаPRESENTIF определение-условия[,<метка-пакетаPRESENT IF определение-условия]*

Даннаяконструкцияприсутствует,есливклассдолжныбытьвключеныодинилинесколько условныхпакетов.Меткапакетаидентифицируетопределениетогопакета,которыйиспользуется. Определение-условия является описанием условия, которое, если оно истинное, требует, чтобы пакет был включен в экземпляр класса. Условие должно удовлетворять требованиям кусловным пакетам,установленнымвГОСТРИСО/МЭКЮ165-1.Например,

CNITINAL PACKAGES class-4-attributesPRESENT IF

соответствующаякатегорияпротоколаподдерживаетоперациюкласса4,определенную

вИСО/МЭКХХХХ’;

образуетдопустимуюдекларациюпакетаприусловии,чтооперациякласса4,определеннаявстан-

дартеИСО/МЭКХХХХ,являетсядопустимойфакультативнойхарактеристикойресурса.

Когда имеются специфичные условия, которые препятствуют реализации условного пакета, онидолжныбытьустановленывшаблонеBEHAVI UR.ИспользуемыйдляэтогошаблонBEHЛVIUR можетбытьвсамомусловномпакетеиливобязательномпакетекласса.Еслитакиеспецификации присутствуют в текстовых определениях поведения, то рекомендуется, чтобы абзац, содержащий этиспецификации,вводилсяконструкцией"<метка-пакетаPRESENT NLY IF:".

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

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

8.4 Шаблон пакета

8.4.1    Обзор

Данныйшаблонпозволяетопределитьпакет,состоящийизкомбинацииопределенийповеде-ния,атрибутов,атрибутивныхгрупп,операций,сообщенийипараметров,дляпоследующейвстав-кившаблонклассауправляемыхобъектоввконструкцияхCHЛRЛCTERIZEBYилиC N ITI NAL PACKAGES. Нижеописаныосновныеэлементыопределения.

8.4.1.1    Поведение

Определениепакетаобеспечиваетполнуюспецификациюповедения,входящеговпакет.Она

включаетвсебя:

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

ния;

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

-спецификациютого,какэкземплярыклассауправляемыхобъектоввзаимодействуютсдру-

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

-идентификациюлюбыхатрибутов,которыесоотносятсясинформациейвсообщениях.Это

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

илисамосозданиесообщений;

-спецификацию критериеввыбораУОНЗ,еслиониесть;

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

8.4.1.2Включаемыеатрибуты

Должнобытьопределеномножествоатрибутов,которыесодержатпакет.

8.4.1.3Операцииисообщения

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

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

Примечания

1 Операции, идентифицированные вопределении класса, относятсяктипамопераций, определенным в ГОСТР ИСО/МЭК 10165-1 (Get attribute value, Replace attribute value, Replace with default value и пр.). В случаеоперацийАсИошиМоййсаиоштребуютсядополнительныеопределениядляхарактеристикиихфунк-ций, как описано в 8.10 и 8.11. Операции Create и elete специфицируются какчасть шаблона связывания имен, описанного в 8.6, таккаксоздание иудалениеуправляемого объектаболеетесно связано с соотноше-ниемвмещениямеждустаршимиподчиненнымобъектами,чемсовсемиэкземплярамиклассауправляемых объектов.

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

8.4.2    Структура шаблона <метка-пакета PACKAGE

[BEHAVIUR    <метка-определения-поведения

[,<метка-определения-поведения]*;

]

[ATTRIBUTES    <метка-атрибутасписок-свойств[<метка-параметра]*

[,<метка-атрибутасписок-свойств[<метка-параметра]*]*;

]

[ATTRIBUTE GRUPS <метка-группы[<метка-атрибута]*

[,<метка-группы[<метка-атрибута]*]*;

]

[ACTINS    <метка-действия [<метка-параметра]*

[,<метка-действия[<метка-параметра]*]*;

]

[NTIFICATINS    <метка-сообщения[<метка-параметра]*

[,<метка-сообщения[<метка-параметра]*]*;

]

[REGISTEREЛSидентификатор-объекта]; supporting productions

список-свойств- [REPLACE-WITH-EFAULT]

[ EFAULTVALUE    спецификатор-значения]

[INITIALVALUE    спецификатор-значения]

[PERMITTEVALUES    указание-типа]

[REQUIREVALUES    указание-типа]

[получить-заменить]

[добавить-удалить]

[SET-BY-CREATE]

[ N -M IFY] спецификатор-значения-указание-значения|

ERIVATI N RULE^^ -определения-поведения получить-заменить    - GET |REPLACE |GET-REPLACE

добавит-удалить    - A | REM VE |A -REMVE

8.4.3    Обеспечивающие определения

8.4.3.1BEHAVI UR<метка -определения-поведения

[,<метка-определения-поведения ]*

КонструкцияBEHЛVI URпозволяетполностьюописатьповедение(семантику),связанноес пакетом.Этаконструкциясоотноситвнешниеаспектыуправляемогообъекта(егооперацииисооб-щениясеговнутреннимисостояниями.Метка-определения-поведенияидентифицируетэкземпляр использованияшаблонаповедения.Принекоторыхобстоятельствахмогугбытьопределеныпакеты, вкоторыхнетребуетсяспецификацияповедения.

8.4.3.2ATTRIBUTES<метка-атрибутасписок-свойств [<метка-параметра ]* [,<метка-атрибута список-свойств [<метка-параметра]*]*

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

СвойствоREPLACE-WITH-EFAULTвключается в определение, еслиатрибутимеетзначе-ние по умолчанию, которое может быть установлено с помощью операции Replace with default value.

Свойство EFAULTVALUEвключаетсявопределение,еслиатрибутимеетзначениепоумол-чанию, которое должно использоваться для обеспечения значения атрибута в операции Replace withdefaultvalueилидолжнозадаватьдляатрибутазначениепоумолчаниюприреализациипакета в соответствии с правилами, определенными в ГОСТ Р ИСО/МЭК 10165-1. Если значение по умолчанию не определено, а свойство REPLACE-WITH-EFAULT присутствует, то значение по умолчаниюопределяетсяспособами,локальнымидляуправляемойсистемы.Значениеможетбыть задано или с помощью указания-значения, или с помощью конструкции ERIVATIN RULE, котораяустанавливает,какможетбытьопределенозначениепоумолчанию.

Свойство INITIAL VALUE включается в определение, если атрибут имеет обязательное на-чальноезначение,котороедолжноиспользоватьсядляатрибутавмоментсоздания.Значениеможет бытьзадано с помощью илиуказателя-значения, или конструкции ERIVATI N RULE, которая устанавливает, какможетбытьопределенозначениепоумолчанию.

EслиприсутствуетсвойствоPERMITTE VALUES,тоуказание-типаспецифицируетограни-чения на допустимые значения, которые может принимать атрибут. Указываемая спецификация должнаиметьвидподтипасинтаксисаатрибута,определенногосиспользованиемнотацииАСН.1 дляподтипа.

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

Если присутствует свойство REQUIRE VALUES, то указание-типа специфицирует значе-ния,которыеатрибутдолженбытьспособенпринимать.Указываемаяспецификациядолжнаиметь вид подтипасинтаксисаатрибута,определенногосиспользованиемнотацииАСН.1 дляподтипа.

Примечание2 — Это свойство определяет множество значений, требуемое для соответствия. Например,управляемыйобъектмодемаможетиметьатрибутскоростипередачиданныхсдопустимымизна-чениямиот0до19,2К;однакосоответствиемодемастандартуможеттребоватьобеспеченияоднойконкретной скоростипередачиданныхизмножествадопустимыхзначений.КакивслучаесконструкциейPERMITTE VALUES,такоеограничениенамножествозначенийатрибутадолжноустанавливатьсятолькотогда,когдаоно основано наограничениинаследованиявсемантике атрибута, ане нанекоторыхпроизвольныхдопущениях относительнотого,чтоможетобразовыватьприемлемоемножествозначений.

СвойствоGETприсутствует,еслизначениеатрибутаможетбытьполученоспомощьюопера-ции Get attribute value.

СвойствоREPLACEприсутствует,еслиатрибутможетбытьустановленспомощьюопераций Set attributevalueиCreate.УстановкаспомощьюоперацииCreateприменяетсятолькотогда,когда этаоперацияподдерживаетсясвязываниемименэкземплярауправляемогообъекта.

СвойствоGET-REPLACE является обозначением того, что присутствуют каксвойство GET, такисвойство REPLACE.

Свойство A присутствует, если атрибут может быть установлен с помощью операции Add member.

СвойствоREM VEприсутствует,еслиатрибутможетбытьустановленспомощьюоперации Remove member.

СвойствоЛ -REM VEявляетсяобозначениемприсутствиякаксвойствA    ,такиREMVE.

Свойство SET-BY-CREATE присутствует, если атрибут может быть установлен с помощью операции Create. Это свойство имеет смысл только тогда, когда операция &eate поддерживается связыванием имен экземпляра управляемого объекта. Так как свойство REPLACE присутствует, еслиатрибутможетбытьустановленспомощьюоперацийSet attributevalue и Create, то свойство SET-BY-CREЛTEнедолжновключатьсявшаблон,еслиприсутствуетсвойствоREPLACE. Аналогично, свойство SET-BY-CREATE не должно включаться в шаблон, если присутствует свойство A , REM VE или A -REM V E. ДажекогдасвойствоSET-BY-CREATEотсутствует,попытка установитьзначениеспомощьюоперацииCreateможетоказатьсяуспешной.

ОтсутствиесвойстваREPLACEможетбытьиспользованодляспецификациитого,чтоатрибут неможетбытьизмененвэкземплярахкласса,ноегоотсутствиенеисключаетподклассов,вкото-рыхдобавленосвойствоREPLЛCE.СвойствоN - M IF Yприсутствуетдлятого,чтобыявноуста-новить, что атрибутне может быть изменен (доступен только для чтения) в классе, имеющемэто свойство,вовсехегоподклассахивовсехсовместимыхснимуправляемыхобъектах(т.е.управляе-мыхобъектах,ведущихсебяалломорфноэтомуклассу).Этосвойствонесовместимои,следователь-но,недолжноприсутствоватьвопределенииклассауправляемыхобъектов,котороеимеетдля тогожесамого атрибута любое из свойствREPLACE, GET-REPLACE, A , REMVE или A -REM VE.

Примечания

3    Свойство N - M I F Yможет быть совместимо со свойством REPLACE-WITH-EFAULT, т. к. эта операция часто используется в смысле «установить повторно», что может согласовываться с возможностями управляющегоконтролироватьзначенияатрибутов.

4    До того как свойство N - M I F Yбыло добавлено в РОУО, было принято специфицировать это свойствовшаблонахBEHAVI URилив документах, накоторыеэтишаблоныссылаются.

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

Метки-параметров, если они есть, идентифицируют специфичные для класса управляемых объектовпараметрыошибок,связанныесоперациямиуправлениянадэтиматрибутом.Сообщение онихприводятсякакошибкиобработки.Синтаксиспараметровошибокопределяетсявуказывае-мыхшаблонах.

8.4.3.3ATTRIBUTE GRUPS<метка-группы [<метка-атрибута]*

[,<метка-группы[<метка-атрибута]*]*

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

расширяемойатрибутивнойгруппыееисходноеопределениеможетбытьрасширенодобавлением

мегок-атрибутов.

8.4.3.4ACTI NS<метка-действия[<метка-параметра]*

[,<метка-действия [<метка-параметра]*]*

Метки-действий,еслиониесть,идентифицируютопределениядействий,которыевключают-

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

емыеобъекты.

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

8.4.3.5N TIFICATI NS<метка-сообщения[<метка-параметра]*

[,<метка-сообщения [<метка-параметра]*]*

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

Метки-параметров, если они есть, идентифицируют специфичную для класса управляемых объектов информацию сообщения или параметры ответа, или специфичные для классауправляе-мыхобъектовпараметрыошибок,связанныессообщением.Здесьмогутиспользоватьсядополни-тельныепараметры,напримердлязаполненияполядополнительнойинформациисообщения,оп-ределенноговИСО/МЭКЮ164-4.Синтаксиспараметровопределяетсявуказываемыхшаблонах.

8.4.3.6REGISTERE ЛSидентификатор-объекта

Значениеидентификатора-объекта,еслионоесть,обеспечиваетглобальнооднозначныйиден-тификатор определения пакета ирегистрацию определенного пакетом группирования поведения, атрибутов,атрибутивныхгрупп,действийисообщений.Значениеидентификатора-объектаявляет-ся тем значением, которое включается в атрибут Packages всех создаваемых экземпляров класса управляемыхобъектоввсоответствиисправилами,определеннымивГОСТРИСО/МЭКЮ165-1. Этаконструкцияобязательна,когданапакетссылаетсяконструкцияC N ITI NAL PACKAGES в шаблонеклассауправляемыхобъектов.

8.5 Шаблон параметра

8.5.1    Обзор

Данныйшаблонпозволяетспецифицироватьизарегистрироватьсинтаксиспараметраисоот-ветствующее поведение, которые могут быть связаны с конкретными атрибутами, операциями и сообщениямившаблонахпакета, атрибута, действияисообщения, определенныхв 8.4,8.7,8.10и 8.11. Тип, определенный в шаблоне параметра, используется для заполнения конструкции ANY EFINE B YxвПБДадминистративногоуправления,гдех—полеПБД,котороесодержитиденти-фикаторобъекта,присвоенныйпараметру.Этотметод применим, например, к:

-отказамобработки;

-параметрамзапросовиответовдействий;

-параметрамзапросовиответовсообщений.

Использованиешаблонавкаждомизэтихконтекстовописанов 8.5.3.

Основныеэлементыопределенияописаныниже.

8.5.1.1    Определениеконтекста

Шаблонспецифицируетконтекст,вкоторомприменяетсяпараметр,аименноонустанавли-вает,чтопередаетпараметрвконкретномполеПБД административного управления.

8.5.1.1.1    Информация/ответдействия, информация/ответ события,специфичнаяошибка

Когда контекст недвусмысленно идентифицируется ПБД административного управления, в которомпараметрпередан,этотконтекстможетбытьуказаноднимизпятиключевыхслов,опре-деленныхв8.5.3.1.КонтекстнедвусмысленноидентифицируетсяПБДадминистративногоуправле-ниятольковтомслучае,когдаконструкцияЛNY EFINE BYвстречаетсявэтомПБДровноодин раз.

8.5.1.1.2    Ключевоесловоконтекста

ЕсликонтекстнеидентифицируетсянедвусмысленноПБДадминистративногоуправления,в котором передается параметр, то этотконтекстдолжен быть специфицирован ключевым словом. КлючевоесловоконтекстадолжноидентифицироватьполевПБДадминистративногоуправления, вкоторомможетпередаватьсяпараметр.

8.5.1.1.3Использованиевдругихшаблонах

Втаблице16показано,гдедаютсяссылкинашаблонпараметра.

Таблица 16 — Использование шаблона параметра

Использование

Возможные контексты

КонструкцияATTRIBUTESв шаблоне пакета

SPECIFIC-ERRR

КонструкцияACTI NSвшаблонепакета

ключевое-слово-контекста,

SPECIFIC-ERRR,

ACTI N-INF,

ACTIN-REPLY

КонструкцияNTIFICATI NSвшаблонепакета

ключевое-слово-контекста, SPECIFIC-ERRR, EVENT-INF , EVENT-REPLY

КонструкцияCREATEвшаблонесвязыванияимен

SPECIFIC-ERRR

Конструкция ELETEв шаблоне связывания имен

SPECIFIC-ERRR

Шаблонатрибута

SPECIFIC-ERRR

Продолжениетаблицы16

Использование

Возможные контексты

Шаблондействия

ключевое-слово-контекста,

SPECIFIC-ERRR,

ACTIN-INF, ACTIN-REPLY

Шаблонсообщения

ключевое-слово-контекста, SPECIFIC-ERRR, EVENT-INF , EVENT-REPLY

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

8.5.1.2Определениесинтаксиса

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

8.5.1.3Указаниеатрибута

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

8.5.1.4Поведение

Шаблонопределяетлюбоеповедение,котороеприменяетсякиспользованию параметра. 8.5.2Структурашаблона <метка- параметраPARAMETER CNTEXT тип-контекста; выбор-синтаксиса-или-атрибута;

[BEHAVIUR    <метка-определения-поведения

[,<метка-определения-поведения]*;

]

[REGISTERE ЛSидентификатор-объекта]; supportingproductions

тип-контекста    -    ключевое-слово-контекста|

ACTI N-INF |

ACTIN-REPLY|

EVENT-INF |

EVENT-REPLY |

SPECIFIC-ERRR ключевое-слово-контекста    -    указание-типа.<идентификатор

выбор-синтаксиса-или-атрибута    -    WITH SYNTЛXуказание-типа|

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

8.5.3 Обеспечивающие определения

8.5.3.1CNTEXT™ -контекста

Эта конструкция определяет контекст, в котором используется параметр, следующим образом:

-ключевое-слово-контекста:—этотвыборявляетсяссылкойнаконтекст,определенныйдля шаблонавнешнимобразом.Структурассылкисостоитизуказания-типаспоследующимидентифи-катором,которыйявляетсяименемполявПБД административного управления, заданного указа-нием-типа. Следовательно, можетбытьиспользованассылканаконтекст,определенныйвдругом документе.Этоможноиспользовать,например,дляуказаниятого,чтопараметрприменяетсятоль-кодляконкретногополявпараметреинформациисобытияУОИУ(см.ИСО/МЭКЮ164-4)илив параметреответадействияУОИУ.Еслипараметрнеотображаетсявконкретноеимяполя (например, информация о событии, по определению, должна быть установлена в паре идентификатор параметра/значение параметра), то может быть задан один из перечисленных ниже более общих контекстов:

-    ACTI N-INF : — этот выбор определяет параметр как применяемый для представления параметров,которыемогутпередаватьинформациюдействияУОИУ;

-ACTIN-REPLY: — этот выбор определяет параметр какприменяемый для представления параметров,которыемогутпередаватьответдействияУОИУ;

-    EVENT-INF: — этот выбор определяет параметр как применяемый для представления параметров, которыемогутпередаватьинформациюсобытияУОИУ;

-    EVENT-REPLY: — этот выбор определяет параметр как применяемый для представления параметров,которыемогутпередаватьответсобытияУОИУ;

-SPECIFIC-ERRR:—этотвыборопределяетпараметркакприменяемыйдляпредставления илисозданиясообщенийобошибкахобработкиУОИУ.Когдаэтотвыбориспользуетсяспараметра-ми, которые применяются для атрибутов, то определение класса управляемых объектов должно специфицировать, должны ли изменяться другие атрибуты, указанные в одном запросе замены значений, если этаошибка происходит для одного атрибутав операции Replace atribute value или Replacewithdefaultvalue.

8.5.3.2WITH SYNTAXуказание-типа

Даннаяконструкция,еслионаприсутствует,идентифицируеттипАСН.1параметраприпере-

дачевпротоколе.

8.5.3.3ATTRIBUTE< метка-атрибута

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

8.5.3.4BEHAVI UR<метка -определения-поведения

[,<метка-определения-поведения]*

Данная конструкция, если она присутствует, позволяет специфицировать любое поведение илисемантику,связанныесданнымпараметром.ЕслииспользуетсяконструкцияАТ^1ВиТЕ,то рассматриваемаяконструкциянеизменяетповедениеатрибута.

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

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

8.6 Шаблон связывания имен

8.6.1 Обзор

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

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

Связыванияименнерассматриваютсякакчастьопределенияклассов,ккоторымониотносят-

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

связыванийимен.Множествосвязыванийименопределяетмножествовозможныхименующихвза-

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

реализовыватьсяподчиненныеобъекты.

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

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

8.6.2    Структура шаблона <метка-связывание-именNAMEBIN ING

SUB RINATE BJECT CLASS    <метка-класса[ANSUBCLASSES];

NAME BY SUPERIR BJECTCLASS< метка-класса [AN SUBCLASSES];

WITHATTRIBUTE    <метка-атрибута;

[BEHAVIUR    <метка-определения-поведения

[,<метка-определения-поведения]*;

]

[CREATE    [модификатор-создания[, модификатор-создания]]

[<метка-параметра]*;

]

[ELETE    [модификатор-удаления]

[<метка-параметра]*;

]

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

supporting productions

модификатор-создания    - WITH-REFERENCE-BJECT |

WITH-AUTMATIC-INSTANCE-NAMING

модификатор-удаления    - NLY-IF-N-CNTAINE-BJECTS |

ELETES-CNTAINE - BJECTS

8.6.3    Обеспечивающие определения

8.6.3.1SUBRINATE BJECTCLASS< метка-класса

[AN SUBCLASSES]

Конструкцияопределяетклассуправляемыхобъектов,экземплярамкоторогомогутприсваи-ватьсяименаэкземплярамиклассаобъектов,определенногоконструкциейNЛME BY SUPERI R BJECT CLASS.Имяэкземпляраэтогоподчиненногоклассаобъектовобразуетсясцеплениемотли-чающегоимениегостаршегообъектасотносительнымотличающимименемподчиненногообъекта. EслизаданоAN SUBCLЛSSES,тоэтосвязываниеименприменяетсяидлявсехподклассовзадан-ногоклассауправляемыхобъектов.

8.6.3.2NAME BY SUPERI R BJECT CLASS< метка-класса [ANSUBCLASSES]

Конструкция определяет класс управляемых объектов или класс других объектов, например класс объектов справочника, экземпляры которого могутприсваиватьименаэкземплярамкласса управляемыхобъектов,определенногоконструкциейSUB RINATE BJECT CLASS. Еслизадано ANSUBCLASSES , то этосвязываниеименприменяетсяидлявсехподклассовзаданного класса управляемыхобъектов.

8.6.3.3WITHATTRIBUTE<метка-атрибута

Этаконструкцияопределяетатрибут,которыйдолжениспользоватьсявконтекстерассматри-ваемогосвязыванияимендляпостроенияотносительного отличающего имениэкземпляракласса управляемыхобъектов, определенного конструкцией SUBRINATE BJECT CLASS. Значения этого атрибутадолжны представляться типом данных с единственным значением, удовлетворяю-щимограничениямГОСТРИСО/МЭК10165-1.Еслинетподходящегоатрибутадляиспользования вкачествеименующего,топроектировщикамуправляемыхобъектоврекомендуетсяобеспечивать управляющийатрибуттипаGraphicString.

8.6.3.4BEHAVI UR<метка -определения-поведения [,<метка-определения-поведения]*

Еслионаприсутствует,этаконструкцияпозволяетопределитьлюбыеконфликтыповедения,

возникающиевследствиесвязыванияимен.Метка-определения-поведенияидентифицируетрассмат-

риваемоеопределениеповедения.

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

8.6.3.5CREATE[модификатор-создания

[, модификатор-создания]][<метка-параметра]*

Конструкцияприсутствует,еслидопускаетсясозданиеновыхэкземпляровклассауправляемых объектов,указанногоконструкциейSUB RINATE BJECT CLASS, вконтекстеданногосвязы-ванияименспомощьюоперацииадминистративногоуправлениясистемы.Значениямодификато-ров-созданияспецифицируютопции,доступныеприсоздании.Допустимымизначениямиявляют-сяследующие:

-    WITH-REFERENCE-BJECT:присозданииможетбытьзаданассылканауправляемыйобъект какисточникзначенийпоумолчаниюидляспецификациивыбораусловныхпакетов;

-    WITH-ЛUTMЛTIC-INSTЛNCE-NЛMING:можноопуститьвзапросесозданияспецифика-циюимениэкземплярановогоуправляемогообъекта.

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

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

Метки-параметров,еслиониесть,идентифицируютпараметрыспецифичныхдлясвязывания

именошибок,связанныхсоперациейCreate.Онихсообщаетсякакоботказахвремениобработки.

Синтаксиспараметровошибокопределяетсяуказываемымишаблонами.

8.6.3.6ELETE[модификатор-удаления][<метка-параметра]*

Конструкцияприсутствует,еслидопускаетсяудалениеэкземпляровклассауправляемыхобъек-тов,указанногоконструкциейSUB RINATE BJECT CLASS, вконтекстеданногосвязывания имен.Модификатор-удаления,еслионесть,указываетповедениеприудаленииуправляемогообъекта этогокласса.Допустимымизначениямиявляютсяследующие:

-    NLY-IF-N-CNTAINE- BJECTS:всевмещаемыеуправляемыеобъектыдолжныбыть явноудаленыспомощьюоперацийадминистративногоуправлениядоудалениявмещающего управляемого объекта, т. е. запрос операции elete приведет к ошибке, если имеются вмещаемые управляемыеобъекты;

-ELETES-CNTAINE-BJECTS:еслиоперацияeleteприменяетсякуправляемомуобъекту, для которого задан этот модификатор, то запрос операции elete приведет к отказу, если какой-либопрямоиликосвенновмещаемыйуправляемыйобъектимеетмодификатор NLY-IF-N -CNTAINE - BJECTSисодержитуправляемыеобъекты;впротивномслучаеуспешный запросоперацииeleteприведеткудалениювсехвмещаемыхуправляемыхобъектов.

Другие правила, описывающие поведение относительно удаления вмещаемых управляемых объектов, могутбытьспецифицированывконструкцииBEHAVI UR.

Примечание—Учитывая,чтомодификаторELETES-C NTAINE- BJECTSдопускаетудаление управляемого объекта независимо оттого, содержит ли он другие управляемые объекты, предпочтительнее использовать модификатор NLY-IF-N-CNTAINE - BJECTS,если есть какие-либо сомнения относительно того, какой модификатор лучше подходит.

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

Метки-параметров,еслиониесть,идентифицируютпараметрыспецифичныхдлясвязывания

именошибок,связанныхсоперациейelete.Онихсообщаетсякакоботказахвремениобработки.

Синтаксиспараметровошибокопределяетсяуказываемымишаблонами.

8.6.3.7REGISTEREЛSидентификатор-объекта;

Значениеидентификатора-объекта,еслионоесть,обеспечиваетглобальнооднозначныйиден-

тификаторопределениясвязыванияимен.Данноезначениеиспользуетсядляидентификациисвя-

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

8.7 Шаблон атрибута

8.7.1    Обзор

Данныйшаблониспользуетсядляопределенияотдельныхтиповатрибутов.Этиопределения

могутбытьвдальнейшемобъединенывшаблонеатрибутивнойгруппы.Основныеэлементыопреде-

ленияописаныниже.

8.7.1.1    Получение

Определениетипаатрибутаможетизменять или ограничивать определение другого типа атрибута.

8.7.1.2    Синтаксис атрибута

Определениетипаатрибутадолжновключатьвсебяопределениесинтаксиса,которыйдолжен использоватьсядлявыражениязначенийатрибутавпротоколеадминистративногоуправления.Это достигаетсяспомощьюссылкинаопределениетипаАСН.1.Определениесинтаксисаатрибутаука-зывает,являетсялизначениеатрибутаодно-илимногозначным.Еслибазовымтипомявляется8ЕТ ОР,тотипатрибута—многозначный, впротивномслучае — однозначный.

8.7.1.3Согласованиезначений

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

8.7.1.4Поведение

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

8.7.1.5Идентификаторатрибута

Значениеидентификатораобъектадолжнобытьвыделенодлякаждогоатрибута,которыйдол-

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

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

8.7.1.6 Параметры

Определениеатрибутаможетидентифицироватьпараметрыспецифичныхдляатрибутаоши-

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

8.7.2    Структура шаблона

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

получен-из-или-синтаксис;

[MATCHES F Rквалификатор

[, квалификатор]*;

]

[BEHAVIUR <метка-определения-поведения

[,<метка-определения-поведения]*;

]

[PARAMETERS <метка-параметра

[,<метка-параметра]*;

]

[REGISTERE ЛSидентификатор-объекта];

supporting productions

квалификатор    - EQUALITY | RERING | SUBSTRINGS |

SET-CMPARISN |SET-INTERSECTIN

получен-из-или-синтаксис    - ERIVE FRM <метка-атрибута|

WITHЛTTRIBUTESYNTЛXуказание -типа

8.7.3    Обеспечивающие определения

8.7.3.1 ERIVE FR M< метка-атрибута

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

-    MATCHES FR: результирующий набор правил согласования является логическим ИЛИ правилсогласования,задаваемыхэтойконструкцией,совсемизаимствованнымиправиламисогла-сования;

-    BEHAVIUR:—расширяетлюбыезаимствованныеправиласогласования;

-    REGISTERE AS:—заменяетлюбуюзаимствованнуюрегистрацию.

Этотметодвыводаодногоатрибутаиздругогопозволяет:

-определятьатрибутнаосноведругогосуществующегоопределенияатрибута;

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

8.7.3.2 WITHATTRIBUTE SYNTAXуказание-типа

Этаконструкция,присутствующаятольковтомслучае,когдаотсутствуетконструкция ERIVE F R M,идентифицируеттипданныхАСH.1,которыйописывает,какэкземплярызначенийатри-бутапередаютсявпротоколе.

ТидданныхАСH.1такжеопределяеттидданныхсамогоатрибута.Eслибазовымтипомсинтак-сисаявляется«множество-из», то атрибутможетиметь несколько значений. Все остальные типы данныхАСН.1,включаятипы«множество»,«последовательность»и«последовательность-из»,оп-ределяюттипыатрибутовсединственнымзначением.

8.7.3.3MATCHES F Rквалификатор[,квалификатор]*

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

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

атрибутов.Всесогласованиядругихтипов,еслиэтаконструкцияотсутствует,неопределеныи,сле-

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

-    EQUALITY: —значениеатрибута,еслионоесть,можетбытьпроверенонаравенствозадан-номузначению;

-    R ERING: — значение атрибута, если оно есть, можно сравнить с заданным значением дляопределениябольшегоизних;

-    SUBSTRINGS: —значениеатрибута,еслионоесть,можносравнитьсзаданнымзначением дляопределения,входитоноилинетвзначениеатрибута;

-    SET-C MPARISN: —значениеатрибута,еслионоесть,можносравнитьсзаданнымзна-чениемдляопределениясоотношениясупермножество/подмножествомеждуэтимизначениями;

-    SET-INTERSECTIN: — значение атрибута, если оно есть, можно сравнить с заданным значениемдлянахождениянепустогопересеченияэтихдвухзначений.

8.7.3.4BEHAVI UR<метка -определения-поведения [,<метка-определения-поведения]*

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

8.7.3.5PARAMETERS<метка-параметра [,<метка-параметра]*

Метки-параметровпозволяютсвязатьпараметрысповедениемтипаатрибутадляопределения отказовобработки.Например,принекоторыхобстоятельствахтипатрибутаможетпродемонстриро-вать ошибку «нарушение ограничения». Параметр, дающий информацию отакойошибке, может бытьопределен,используяCNTEXT SPECIFIC-ERRRвшаблонепараметра,иуказанизшабло-наатрибута.

8.7.3.6REGISTERE ЛSидентификатор-объекта

Значениеидентификатора-объекта,еслионоесть,обеспечиваетглобальнооднозначныйиден-тификатор определения атрибута, которое включает в себя все элементы, прямо или косвенно указанные в конструкциях ERIVE FRM, WITH ATTRIBUTE SYNTAX, MATCHES FR и BEHAVIUR.Этозначениеиспользуетсявпротоколеадминистративногоуправления,когданеоб-ходимоидентифицироватьтипатрибута.Еслиэтаконструкцияопущена,тонаопределениеатрибу-танельзясослатьсявопределенииклассауправляемыхобъектов.Когдаопределениеатрибутавыво-дитсяизсуществующегоопределенияатрибута,котороесодержитконструкциюREGISTERE AS, значениеидентификатора-объекта,присвоенноесуществующемуопределению,неявляетсядопус-тимымидентификаторомдлявыводимогоопределения.Следовательно,конструкцияREGISTERE ЛSдолжнабытьвключенаввыводимоеопределение,еслинанегонужноссылатьсяизопределения классауправляемыхобъектов.

8.8 Шаблонатрибутивнойгруппы

8.8.1 Обзор

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

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

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

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

группа,товсеатрибуты,включенныевгруппу,должныприсутствоватьвпакете,которыйссылает-

сянагруппу.

8.8.2    Структура шаблона

<метка-группы    ATTRIBUTE GRUPS

[GROUP ELEMENTS <метка-атрибута

[,<метка-атрибута]*;

]

[FIXE;

]

[ESCRIPTI N    выделенная-строка;

]

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

8.8.3    Обеспечивающие определения

8.8.3.1GRUP ELEMENTS<метка-атрибута[,<метка-атрибута]*

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

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

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

8.8.3.2FIXE

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

рованная.

8.8.3.3ESCRIPTI №ыделенная -строка

Этаконструкцияпозволяетописатьсемантикугруппы,например:«Группавсехатрибутовсо-стояний управляемого объекта». Не устанавливается никаких ограничений на наборы символов, используемые вданнойконструкции,инеопределяетсякакая-либоструктуравнутриее.

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

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

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

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

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

8.9Шаблонповедения

8.9.1    Обзор

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

Примечания

1Шаблоныповедениядолжныиспользоватьсядлявыражениясемантики,котораянеполностьюописа-

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

тики.

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

8.9.2    Структура шаблона <метка-определения-поведенияBEHAVI UR

EFINE AS    выделенная-строка;

8.9.3    Обеспечивающие определения

8.9.3.1EFINE ASвь]деленная-строка

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

8.10 Шаблондействия

8.10.1 Обзор

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

8.10.1.1Поведение

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

8.10.1.2 Режимработы

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

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

8.10.1.3Абстрактныйсинтаксис

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

M-ACTI N,определеннойвГОСТРИСО/МЭК9595.Синтаксисыопределяютсяспомощьютипов данныхАСН.1.

Примечания

1Еслитольконетнамеренияспециальнопредотвратитьпоследующиерасширенияаргументовдействий, торекомендуется, чтобы синтаксисы информациииответадействияопределялисьрасширяемымобразом путемвключениявкачествефакультативногополятипаАСH.1SETF ManagementExtension(определенного вГОСТРИСО/МЭК10165-2).

2 Рекомендуется, чтобы базовым типом данных, выбранным для синтаксисов информации и ответа, былтип SEQUENCE.

8.10.1.4Идентификаторыдействий

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

8.10.1.5Параметры

Определениетипадействияможетидентифицироватьпараметрыинформациидействия,отве-

тадействияилиспецифичныхошибок,связанныхстипомдействия.

8.10.2    Структура шаблона

<метка-действияACTI N

[ BEHAVIUR <метка-определения-поведения

[,<метка-определения-поведения]*;

]

[ ME C NFIRME ;

]

[ PARAMETERS< метка-параметра

[,<метка-параметра]*;

]

[ WITH INF RMATIN SYNTAXуказание -типа;

]

[ WITH REPLYSYNTAXуказание-типа;

]

REGISTEREЛSидентификатор-объекта;

8.10.3    Обеспечивающие определения

8.10.3.1BEHAVI UR<метка-определения-поведения

[,<метка-определения-поведения]*

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

8.10.3.2M E C NFIRME

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

8.10.3.3PЛRAMETERS<метка-параметра[,<метка-параметра]*

Метки-параметров идентифицируют параметры информации или ответа действия, а также отказыобработки,связанныестипомдействия.Примерсм.вА.7.

8.10.3.4WITHINF RMATI N SYNTAXуказание -типа

Если эта конструкция присутствует, то указание-типа идентифицирует тип данных АСН.1, описывающийструктурупараметраинформациидействия,котораяпередаетсявпротоколеадми-нистративногоуправления.Еслиэтаконструкцияотсутствует,тонетникакойспецифичнойинфор-мации,связаннойсвызовомдействия.

8.10.3.5 WITHREPLYSYNTЛXуказание-типа

Если эта конструкция присутствует, то указание-типа идентифицирует тип данных АСН.1, описывающий структурупараметраответадействия,котораяпередаетсявпротоколеадминистра-тивногоуправления.Еслиэтаконструкцияотсутствует,тонетникакойспецифичнойинформации, связаннойсответомдействия.

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

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

8.11 Шаблонсообщения

8.11.1    Обзор

Данныйшаблониспользуетсядляопределенияповеденияисинтаксисов,связанныхсконк-ретнымтипомсообщения.Типысообщений,определенныеспомощьюэтогошаблона,могутпере-даваться в отчетахособытияхс помощью услугиM-EVENT-REPRT, определеннойв ГОСТ РИСО/МЭК9595.Нижеописаныосновныеэлементыопределения.

8.11.1.1Поведение

Определениетипасообщениядолжноспецифицироватьобстоятельства,прикоторыхсоздает-

сясообщениеданноготипа.

8.11.1.2Абстрактныйсинтаксис

Определениетипасообщениядолжноспецифицироватьвсеабстрактныесинтаксисы,которые могутиспользоватьсядлявыраженияпараметровинформациииответасобытиявуслугеM-EVENT-REP RT,определеннойвГОСТРИСО/МЭК9595.Шаблонтакжедопускаетраспределениезначе-нийатрибутовпополямсинтаксиса.

Примечания

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

2 Рекомендуется, чтобы базовым типом данных, выбранным для синтаксисов информации и ответа, былтип SEQUENCE.

8.11.1.3Имясообщения

Значениеидентификатораобъекта,связанногосопределениемсообщения,используетсядля

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

8.11.1.4Параметры

Определениетипасообщенияможетидентифицироватьпараметрыинформациисобытия,от-

ветасобытияилиспецифичныхошибок,связанныхстипомсообщения.

8.11.2    Структура шаблона

<метка-сообщения    NTIFICATIN

[BEHAVIUR <метка-определения-поведения

[,<метка-определения-поведения]*;

]

[PARAMETERS    <метка-параметра

[,<метка-параметра]*;

]

[ WITH INF RMATI N SYNTAXуказание-типа

[ AN ATTRIBUTE I S< имя-поля <метка-атрибута

[,<имя-поля<метка-атрибута]*

];

]

[WITH REPLY SYNTЛXуказание -типа;

]

REGISTEREЛSидентификатор-объекта;

8.11.3    Обеспечивающие определения

8.11.3.1BEHAVI UR<метка-определения-поведения

[,<метка-определения-поведения]*

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

8.11.3.2PARAMETERS<метка-параметра [,<метка-параметра]2

Метки-параметровидентифицируютпараметрыинформацииилиответасобытия,атакжеот-

казыобработки,связанныестипомсообщения.Примерсм.вА.8.

8.11.3.3 WITH INF RMATI N SYNTAXуказание-типа

[ AN ATTRIBUTE I S< имя-поля <метка-атрибута [,<имя-поля<метка-атрибута]*]

Если эта конструкция присутствует, то указание-типа идентифицирует тип данных АСН.1, описывающийструктурупараметраинформациисообщения,котораяпередаетсявпротоколеадми-нистративного управления, и позволяет связать идентификаторы атрибутов с именами полей в абстрактномсинтаксисе.Еслиэтаконструкцияотсутствует,тонетникакойспецифичнойинформа-ции,связаннойсвызовомсообщения. Если присутствует конструкция AN ATTRIBUTE I S, то имя-поля должно быть меткой, определенной в абстрактном синтаксисе, на который ссылается указание-типа.Типданных,помеченныйименем-поля,используетсядляпередачизначенийатри-бута,указанногометкой-атрибута.ТипданныхАСН.1атрибутадолженбытьтемже,чтоиуказан-ныйименем-поля.

HикакиеметкивнутритиповS E T FилиSEQUENCE Fнемогутиспользоватьсявкачестве имени-поля, таккакметкивнутри подобных повторяющихся конструкций не позволяютнедвус-мысленноссылатьсянаединичныеэкземплярытипаданных.Аналогичноникакиеметкикомпонен-тов типов CH ICE, SET или SEQUENCE не могут использоваться в качестве имени-поля, если помеченныекомпонентынеоднократновстречаютсявопределениитипа.

8.11.3.4WITH REPLY SYNTAXуказание-типа

Если эта конструкция присутствует, то указание-типа идентифицирует тип данных АСН.1, которыйописываетструктурупараметраответасообщения,котораяпередаетсявпротоколеадми-нистративногоуправления.Еслиэтаконструкцияотсутствует,тонетникакойспецифичнойинфор-мации, связанной с ответом сообщения.

Синтаксисответаиспользуется,когдасообщениеотправляетсявподтверждаемомрежимеус-луги УОИУM-EVENT-REP RT. Подтверждениесобытияневозвращаетсяуправляемомуобъекту. Решениеоботправкесообщениявподтверждаемомилинеподтверждаемомрежимеявляетсявопро-сом соответствующего агента, который принимаетрешение на основе политики, связанной с управляющим. Когда конструкция WITH REPLY SYNTAX опущена в определении сообщения, но сообщениеотправленовподтверждаемомрежиме,топодтверждениенебудетсодержатьинформа-цииответа.

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

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

9 Руководство по разработке эквивалентных модулей АСН.1:1994иАСН.1:1990

Возможнаразработкастандартовнаоснове АСН.1:1994 (ИСО/МЭК8824-1). Длятого чтобы можнобылоиспользоватьАСН.1:1994,рекомендуетсяразрабатыватьэквивалентныйнормативный модульАСН.1:1990 (ГОСТР ИСО/МЭК8824)соследующимисвойствами:

1)ондолжен    иметь тотжесамыйидентификаторобъекта,чтоимодульАСН.1:1994;

2)    он является нормативным, но стандарт устанавливает, что в случае несогласованности междумодулямиАСН.1:1990иАСН.1:1994,предпочтениеимеетпоследнийизних;

3)    стандарт устанавливает, что использование АСН.1:1990 сохраняется так долго, как это будетнеобходимо.

Примечание1 — ПравиламиИСО/МЭКСТК1/ПК21установленпериодический(одинразвгод) обзорсцельюобновлениямеждународныхстандартовАСН.1:1990*.Национальныморганампостандартиза-ции рекомендовано учитывать это при пересмотре стандартов АСН.1:1990. Тем самым обеспечивается, что стандартыАСН.1:1990будутсохранятьсятакдолго,какэто необходимо.

Дляуменьшенияколичестваошибокрекомендуется,чтобымодульАСН.1:1990генерировался в результате машинного преобразования АСН.1:1994, так как это преобразование легко осуще-ствитьавтоматически.

П римечание2 — Если для преобразования АСН.1:1994 в АСН.1:1990 желательно использовать коммерческое средство (например средство АСН.1 поставщика XXX), то рекомендуется в начале сгенериро-ванногокодадобавитькомментарий,которыйгласитприблизительноследующее:

-    - ИспользованосредствоХХХАСН.1 - -

-    - дляпреобразованияАСН.1:1994вАСН.1:1990- -и примечание:

«Примечание—ХотяИСОнеотдаетпредпочтениениодномупрограммномусредству,ХХХАСН.1

позволяетпреобразоватьАСН.1:1994вАСН.1:1990.»

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

9.1Руководство

Рекомендуетсяпридерживатьсяследующихправил.

1)МодулиАСН.1:1990иАСН.1:1994должныссылатьсянаодниитежедокументыадмини-стративногоуправлениясистемы.Требуется,чтобыданныймодульполностьюсоответствоваллибо АСН.1:1990,либоАСН.1:1994,адирективы,определенныевразделе10,используютсядляиденти-фикациитого,какаяверсиянотациииспользуетсявконкретноммодуле.

2)    Указания типов и значений могут быть импортированы в модуль АСН.1:1994 из модуля АСН.1:1990заследующимиисключениями:

а)АСH.1:1990MACROнеможетбытьимпортированавмодульАСH.1:1994;следователь-но,невозможносоздатьэкземплярMAC R вмодулеАСН.1:1994.

б)ИдентификаторызначенийSET,    SEQUENCE и CHICE.

3)    Указания типов и значений могут быть импортированы в модуль АСН.1:1990 из модуля АСН.1:1994заследующимисключением:

типыАСH.1:1994CHARACTERSTRING,BMPString,UniversalString, EMBE EPV немогугбытьимпортированы.ТаккаквАСH.1:1990нетэквивалентовдляэтихтиповАСH.1:1994, тоихиспользованиенерекомендуетсявтехмодуляхАСН.1:1994,длякоторыхтребуютсяэк-вивалентные модули АСН.1:1990. По тем же причинам запрещается использование типа АСН.1:1994 Tuple втех модулях АСН.1:1994, для которых требуются эквивалентные модули АСН.1:19903.

Примечание 1 — Если следовать предлагаемому руководству, то противоречия при импорте указанийтиповизначенийизоднойверсииАСН.1 в другую не возникает, т. к. эквивалентные конструкции существуютвлюбомслучае.

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

-    - < Модуль АСН.1 версии 1994годаSMModule

--< {joint-iso-itu-t ms (9)smi (1)part4 (4)asn1Module (2)2} - -SMModule {joint-iso-itu-t ms (9)smi (1)part4 (4)asn1Module (2)2}

EFINITI NS: : =BEGIN REGISTERE-AS : : = TYPE-IENTIFIER

-    - TYPE-IENTIFIER определен в ГОСТРИСО/МЭК8824 — 1, доступен в любом модуле без

-    -егоимпортаиопределенкак:

-    - TYPE-IENTIFIER : : = CLASS

-    - {

-    - &id BJECT IENTIFIERUNIQUE,

-    - &Type

-    - }

-    - WITH SYNTAX { &Type IENTIFIE BY &id}

INF-REPLY-IENTIFIER : : = CLASS

{

&Info PTI NAL,

&Reply PTI NAL,

&registeredAs BJECT IENTIFIER UNIQUE

}

WITH SYNTAX {INF&Info REPLY &Reply IENTIFIEBY&registeredAs} RegisteredAsTableREGISTRERE-AS: : = {...}

InfoReplyTableINF-REPLY-IENTIFIER: : = {...}

-    - RegisteredAsTableдолжнабытьзаполненашаблонамиРОУО

-    - ATTRIBUTE и PARAMETER.

--InfoReplyTable должнабытьзаполненашаблонамиРОУО --ACTIONиNOTIFICATION.

E N

5)    Модули АСН.1:1994 определяются какв следующем примере: --<МодульАСH.1версии1994годаExampleModule - -

ExampleModule^-здесьдолженбытьдопустимыйидентификаторобъекта--EFINITI NS: : =BEGIN IMP RTS REGISTERE-AS,

INF-REPLY-IENTIFIER,

RegisteredAsTable,

InfoReplyTable

FRM SMModule {joint-iso-itu-t ms (9)smi (1)part4 (4)asn1Module (2)2};

Foo : : =    SEQUENCE{

id1 REGISTERE - AS.&id({RegisteredAsTable}), syntax1REGISTERE -AS.&Type({RegisteredAsTable}{@.id1})}

Bar: : =    SEQUENCE{

id2REGISTERE - AS.&id({RegisteredAsTable}),

syntax2SEQUENCEFREGISTERE-AS.&Type({RegisteredAsTable}{@id2})} firstExtensionId BJECT IENTIFIER: : = {1317103101} firstExtensionInfo: : = PrintableString

--Иллюстрируетиспользованиесодержащегосяподтипа,ограничивающегооткрытыйтип.--FooBar: : =    Foo(WITHCMPNENTS{

id1 (firstExtensionId), syntax1 (FirstExtensionInfo)})

E N

ТаккакРОУОиспользуетсявместесклассоминформационныхобъектовАСH.1REGISTERE-AS, то FooBar является дублированием информации. А именно, спецификация РОУО плюс REGISTERE -ASАСH.1эквивалентныограничениювнутреннеготипавFoo.FooBamростоиллю-стрирует, что открытыйтип может быть ограничен до любого типа, а ANY/ANY EFINE BY не можетбытьограниченвАСH.1:1990дотипа,отличногоотANY/ANY EFINE BY.Этаконструк-ция показывает, как отображать ограниченный таким образом тип АСН.1:1994 в комментарии в АСН.1:1990.

6)МодулиАСН.1:1994преобразуютсявмодулиАСН.1:1990последующиминструкциям.

а)УдалитьчастьутвержденияIMP    RTS,ссылающуюсянамодуль SMModule. Это позволит избавитьсяотимпортированныхопределенийклассовинформационныхобъектовREGISTERE-AS и INF-REPLY-IEN-TIFIER.

б)ПреобразоватьвсессылкинаоткрытыетипыктипамANYили    ANY EFINE BY.Дляэтого преобразоватьвесьсинтаксисАСН.1следующимобразом:

во-первых, преобразовать

из

в

REGISTERE-AS.&id

BJECT IENTIFIER

Если «REGISTERE-AS.&Type » является компонентом SET или SEQUENCE и определен в тойже самой констрyкцииSET или SEQUENCE как «id», то преобразовать

из

в

REGISTERE-AS.&Type ({RegisteredAsTable} {@.id1}) REGISTERE-AS.&Type ({RegisteredAsTable} {@.id1})

ANY EFINE BY id ANY EFINE BY id

впротивномслучаепреобразовать

из

в

REGISTERE-AS.&Type ({RegisteredAsTable} {@.id1}) REGISTERE-AS.&Type ({RegisteredAsTable} {@.id1})

ANY

ANY

в)    Если для модуля АСН.1 действует AUTMATIC TAGS, то применить ИСО/МЭК 8824-1, пп.22.5—22.7,гдеописано,какдействyетавтоматическоетегированиенакомпонентытиповSET, SEQUENCE и CH ICE,иyдалитьконстрyкцию«AUTMATIC TЛGS»изпредложенияопределе-ниямодуля.

г)    Если открытый типограничен с использованием нотации подтипаТуреСот^аш^ то удалить ограничение,таккакANY и ANY EFINE BYнемогyтбытьограниченывАСH.1:1990до типа, отличного отANYилиЛNY EFINE BY.

д)    Если определение типа ENUMERATE использует синтаксис «identifier» для Епитега1юп11ет,тоегоследуетизменитьна<^епийег(питЬег).Например,изменить

ENUMERATE {a,b,c,d}

на

ENUMERATE {a(0),b (1),c (2),d (3)}

е)Удалитьвсемаркерырасширения(т.е.«...»).Например,изменить SEQUENCE{

i    IA5String,

b B LEAN,

}

на

SEQUENCE{

i    IA5String,

b B LEAN

}

ж)УдалитьизпредложенияопределениямодyлявсеконстрyкцииEXYENSIBILITYIMPLIE.

и) Удалить все символы пробелов и новой строки из hstring и bstring; удалить все символы

новойстрокиизс81п^.Например,изменить b BIT STRING : : = ’0001 1100 1101 0110 1110 0111 1101 0101’B o CTET STRING : : = ’8F3CE483 0192B3459325EF2 8AA3E700’ H p PrintableString: : = «Hello,

world|»

на

b BIT STRING : : = ’00011100110101101110011111010101’ B o CTET STRING : : = ’8F3CE4830192B3459325EF28AA3E700’ H p PrintableString : : = «Hello, world|»

к)ПреобразоватьвсенотацииCharacterStringListвэквивалентныеимcstring.Hапример,изме-

нить

name PrintableString : : = {«This is a long string,that is

spread across two lines»}

на

name PrintableString: : =

«This is a long string,that is spread across two lines»

л)Преобразоватьвсессылкинамножествазначенийвссылкинаограниченныетипы.Напри-мер, изменить

Ages INTEGER: : = {1 | 4 | 7 . .20}

на

Ages INTEGER: : = {1 | 4 | 7 . .20}

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

м)ПреобразоватьвсепоявлениятипаINSTANCE FвэквивалентныйтипSEQUENCE.Hа-пример, изменить

А: : = INSTANCE F REGISTERE - AS

на

A: : = SEQUENCE {

type-id    BJECT IENTIFIER,

value    [0] ANY EFINEBY type-id

}

н)Удалитьвсеидентификаторы«mantissa», «base» и «exponent»извсехзначенийтипаREЛL и заменитьвсевнyтренниеограничениятипаREALнакомментарий.Hапример,изменить ten REAL : : = {mantissa 1,base 10, exponent 1} ecimalReal : : = REAL (WITH C MPNENTS {. . . ,base 10})

на

ten REAL : : = {1, 10, 1}

ecimalReal : : = REAL--должнокодироватьсяпооснованию10

о) Заменить все случаи нотации значения EXTERNAL на эквивалентные ей в АСН.1:1990. Например, изменить

extern1990EXTERNAL: : = {

direct-reference    {12 3 4 5 6},

indirect-reference    3,

encoding    single-ASN1-type: IA5String: «hello»

}

на

extern1994EXTERNAL: : = {

identificationcontext-negotiation: { presentation-context-id 3, transfer-syntax    {12 3 4 5 6}

},

data-value notation : IA5String : «hello»

}

п)ЗаменитьвседопустимыеалфавитыАСН.1:1994наэквивалентныеимвАСН.1:1990.Напри-мер, изменить

UpperCaseAndSpacenly: : = PrintableString (FRM("A" . . "Z" |""))

и

UpperCaseAndSpacenly: : = PrintableString (FRM("A" | "B" |"C"|""|

"E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "" |

"P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ))

р) ИзменитьвсевыражениямножествАСН.1:1994,используемыевнотацииподтипа,наэк-вивалентныеимвАСН.1:1990.Например,изменить

PartNumber : : = NumericString(SIZE(8)AFRM("0" . . "9"))

на

PartNumber: : = NumericString(SIZE(8)) (FRM( "0" | "1" |"2" | "3" | "4" |

"5" | "6"|"7"|"8"|"9"))

с) Когда требование р) не может быть выполнено, так как результатом будет бесконечное множество,частьнотацииподтипаАСН.1:1994,котораяприводиткбесконечномумножеству,сле-дуетзаменитькомментарием.Например,изменить

AllButZeroToTen : : = INTEGER(ALLEXCEPT (0 . . 10))

на

AllButZeroToTen : : = INTEGER - -всецелыезначения,кроме0— 10

ПрименениеприведенныхвышеинстрyкцийкмодyлюАСH.1:1994ExampleModuleизперечис-ления 5) дает:

--<МодyльАСH.1версии1990годаExampleModule - -

ExampleModule^-здесьдолженбытьдопустимыйидентификаторобъекта-EFINITI NS: : =BEGIN Foo : : = SEQUENCE {

id1 BJECT IENTIFIER, syntax1ANY EFINE BY id1}

Bar : : = SEQUENCE {

id2 BJECT IENTIFIER, syntax2 ANY}

-    - В модуле АСН.1:1994 ExampleModule синтаксис syntax2 в Bar был определен как

-    - SEQUENCE F, анекакоткрытыйтип,и,такимобразом, немогбытьпреобразованв

-    - ANY EFINE BY.

firstExtensionId BJECT IENTIFIER: : = {13 17 103 10 1}

FirstExtensionInfo: : = PrintableString

-    - firstExtensionId и FirstExtensionInfoдолжныиспользоватьсявтипеFoo, где firstExtensionId --являетсязначениемid1 ( BJECT I ENTIFIER) ,котороеyказывает,чтоsyntax1имееттип

-    - синтаксисаFirstExtensionInfo(PrintableString).

E N

10 СоглашениядляАСН.1идиректив РОУО

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

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

-входныефайлысдирективами(т.е.модулямиАСН.1,библиотекамиРОУОипрочимидирек-

тивами)должныбытьпринятыкомпиляторамиАСН.1иРОУО,которыенераспознаютдиректив;

-входныефайлыбездирективдолжныбытьпринятыкомпиляторамиАСН.1иРОУО.

Примечание — Этисоглашениядопускаютрасширенияпутемиспользования специфичных для реализациидиректив.

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

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

-текст, набранныйжирнымшрифтом (например,--< илиASN1),долженвводитьсятак,как онприведен,бездобавленияпробеловилиизменениярегистра;

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

-факультативные элементы директив заключены в квадратные скобки (например, [операнды]);

-    заэлементом директивы, который может повторяться (произвольное число раз), стояттри точки(например, [операнды]...).

Общийформатдирективы:

--<директива--

гдедирективаесть

область_действия.ключевое_слово[операнд][,операнд]...

Такимобразом,директиваначинаетсядвумяпоследовательнымидефисамиизнаком«мень-ше,чем» (--<)изавершаетсязнаком «больше, чем» и двумя последовательными дефисами (--). Междудефисамиизнаками«меньше,чем»и«больше,чем»недолжнобытьпробелов.Врезультате компиляторами,которыенеподдерживаютэтидирективы,онитрактуютсякаккомментарииАСН.1 илиРОУО.ДирективанеможетсодержатькомментариевАСН.1.

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

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

воламикоторыхдолжныбытьдвадефиса(--).

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

10.1    СоглашениядлядирективАСН.1 Длядиректив АСН.1 принятыследующиесоглашения.

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

ДлядирективыАСH.1символомобласть-действияявляетсяASN1.Вдополнениекнемyмогyт быть определены (например, реализацией) другие символы область-действия. Ключевым-словомможетбытьследующее:

-Version.

Операндом, в общем случае, могутбыть:

-текстоваястрока(безпробелов,запятых,последовательнойпарыдефисовизнака«больше,

чем»);

-числоваястрока(безпробелов,запятых,последовательнойпарыдефисовизнака«больше,

чем»);

-    cstring («xxxxx»), занимающая однустроку;

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

-дрyгиеконстрyкцииАСH.1,напримерbstringилиhstring.

-текстоваястрока(безпробелов,запятых,последовательнойпарыдефисовизнака«больше,

чем»);

-числоваястрока(безпробелов,запятых,последовательнойпарыдефисовизнака«больше,

чем»);

-    cstring («xxxxx»), занимающая однустроку;

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

-дрyгиеконстрyкцииАСH.1,напримерbstringилиhstring.

10.1.1    Директива версии

ДирективаVersion используется для указания того, по какой версии написан модуль АСН.1: АСН.1:1990илиАСН.1:1994.

Директиваимеетследующийформат:

--<ASN1.Versionверсияимя_модуля [фио] -Элементы, выделенныежирнымшрифтом (например, ASN1.Version)пишyтсятак, какпоказано, аэлементы, набранные курсивом, заменяются следующимобразом: версия —либо 1990, либо1994, либо1990, 1994; имя_модуля—имямодуля АСН.1;

фио — факультативное значение идентификатора объекта АСН.1, используемое для недвус-мысленнойидентификациимодуляАСН.1.

Директива Version является единственной директивой для модуля АСН.1. Эта директива со значениемоперанда1990,1994означает,чтомодульАСН.1соответствуеткакверсииАСН.1:1990, такиверсииАСН.1:1994.Компиляторможетиспользоватьсвоисведенияолюбойизэтихверсий или об их общем подмножестве. Если директива версии для модуля АСН.1 не предоставлена, то реализацияможетиспользовать какой-либо иной способ для идентификации версии модуля, например, опциикоманднойстрокикомпилятораилираспознаваниесинтаксиса,специфичного для конкретнойверсии(какмакровАСН.1:1990илиинформационныеобъектывАСН.1:1994). Примеры:

--< ASN1.Version 1990Attribute-ASN1Module -- {joint-iso-itu-t ms (9)smi (3)part2 (2)asn1Module (2) 1} - ---< ASN1. Version 1994 SMModule

-- {joint-iso-itu-t ms (9)smi (3)part4 (4)asn1Module (2)2} - -

10.2 Соглашениядлядиректив РОУО

ДлядирективРОУОсуществуютследующиедополнительныесоглашения.

ДирективанеможетсодержатькомментариевАСН.1.

Директиваможетнаходитьсякаквфайле,отличномотсодержащегошаблонРОУО,ккоторо-муонаотносится,такивсамомфайле.Когдадирективанаходитсявтомжефайле,онаможетбыть вне области действия документа РОУО (доначалаилипослеего).Директиваможетнаходитьсяв теледокумента, влюбомместе, гдедопустимпробел.

Когдадирективанаходитсявнутридокумента,онадолжнарасполагатьсядошаблонаРОУО,к

которомуонаотносится.ДляконкретногошаблонаРОУОможетсуществоватьнеболееоднойди-

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

Hапример,наодинитотжешаблонмогyтссылатьсядирективыNicknameиWoгkingSet,нотолько

пооднойкаждоговида.ДлядрyгихэлементовАСH.1могyтсyществоватьдрyгиедирективыNickname.

Символомобласть_действияявляетсяОМО.Дополнительномогутбытьопределены(напри-мер, реализацией) другие символы область_действия. Ключевым_словомможетбытьодноизследующих:

-    Alias;

-    ocument;

-    Endocument;

-    Version.

Операндом, вобщемслучае, могутбыть:

-текстоваястрока(безпробелов,запятых,последовательнойпарыдефисовизнака«больше,

чем»);

-числоваястрока(безпробелов,запятых,последовательнойпарыдефисовизнака«больше,

чем»);

-    cstring («xxxxx»), занимающая однустроку;

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

-дрyгиеконстрyкцииАСH.1,напримерbstringилиhstring.

10.2.1 Директива альтернатив

ДирективаAliasиспользyетсядляпредоставленияальтернативныхилиалиасныхидентифика-торов документа РОУО. Эти алиасы используются для согласования ссылок междудокументами РОУО, когдаиспользуютсякороткие илипротиворечивые идентификаторы.

Форматдирективы:

--<G M .Лliasидентификатор_докyментаалиас_докyмента -- [,алиас_документа]... - -Элементы, выделенные жирным шрифтом (например G M .Alias) пишутся так, как показано, а элементы, набранныекурсивом (например идентификатор_документа), замеияютсятак, какопи-санониже.

Можетприсутствоватьнесколькоразделенныхзапятымиэлементовалиас_документа. -идентификатор_документа—идентификатордокументаРОУОввиделибостроки,взятойв кавычки("),либоидентификатораобъектавфигурныхскобках({});

-    алиас_документа — альтернативный идентификатор документа РОУО в виде либо строки, взятойвкавычки("),либоидентификатораобъектавфигурныхскобках({}).

Примеры:

--<GM.Alias "CCITT Rec.X.721 (1992) | IS/IEC 10165-2:1992"

--"Rec.X.721|IS/IEC 10165-2:1992",

--"CCITT Rec.X.721|IS/IEC 10165-2",

--"Rec.X.721|IS/IEC 10165-2",

--"CCITT Rec.X.721(1992)",

--"CCITT Rec.X.721 (1992)|IS/IEC 10165-2:1992",

--"MI" --

--<GM.Alias "Recomendation M.3100:1992"

-- "Rec.M.3100:1992",

--"M.3100:1992",

--"M. 3100" - -

10.2.2    Директивадокумента

ДирективаocumentобеспечиваетидентификатордокyментаРОУО,являющийсялибосим-вольной строкой, либо идентификатором объекта, либо тем и другим. Формат директивы может иметьоднуизследующихтрехформ:

--<G M . ocument строка_документа----<G M . ocument ИО-документа----<G M . ocumentстрока_документаИО-документа--Элементы,выделенныежирнымшрифтом(напримерG M . ocument)пишyтсятак,какпока-зано, а элементы, набранные курсивом (например строка_документа), заменяются следующим образом:

строка_документа—символьнаястрока,идентифицирующаядокументРОУО,вкавычках("); ИО-документа—идентификаторобъектаАСН.1,присвоенныйдокументу,вфигурныхскоб-ках({}).

ДирективаocumentдолжнанаходитьсядопервогошаблонаРОУОилимодyляАСH.1,обра-зующегодокумент.Такимобразом,документРОУОрассматриваетсякаксостоящийизвсехшабло-новРОУОимодyлейАСH.1отдирективыocumentдосоответствyющейдирективыEndocument, или до следующей директивы ocument, или до концафайла, содержащего этоттекст РОУО.

ДлясохранениявфайлахтекстовРОУО,имеющихсоответствующиедирективы, существуют следующиеправила:

-КаждыйдокyментРОУОдолжениметьдирективyocumentдляобеспечения«правильного» именидокумента. Еслиэтойдирективынет,тоимядокументанеопределеноилиобеспечивается каким-либодругимметодом.

-Директива ocument должна находиться в томже самом файле, что итекст РОУО, ккото-ромуонаприменяется.

ОдноитожеимядокyментаРОУОможетпоявитьсявнесколькихдирективахocumentпри-менительно кнескольким блокам текста РОУО, таким какразличные файлы. В этом случае весь текст РОУО в разных файлах рассматривается как часть одного и того же документа РОУО. Это аналогичнопространствуименвС++,котороепозволяетвнесколькихразныхфайлахзаголовков содержатьматериал,определенныйводномитомжепространствеимен.

В общем случае должен быть единственный документ РОУО на один входной файл. Файл можетсодержатьнесколькодокументовРОУОтольковтомслучае,когдаонсодержитнесколько согласованныхдирективocumentиEndocument.

Пропуски(одинилинесколькопоследовательныхпробеловидисимволовтабуляции)неучи-

тываютсявидентификаторе_документаивалиасе_документа.

Примеры:

--<GM.ocument"CCITT Rec.X.721(1992)|IS/IEC 10165-2:1992" - ---<GM.ocument "Recomendation M.3100:1992" - ---<G M.ocument "P1Library Vol.4" ---<G M . ocument {iso(1)2 124 360501 15 13 1} - -

--<GM.ocument"IIMCMIB Translation"{IS (1)2 124 360501 15 13 1} - -

10.2.3    Директива конца документа

ДирективаEndocumentотмечаетконец"докyмента"РОУО.Форматдирективыможетиметь

однуизследующихчетырехформ:

--< GM.Endocument ---<G M .End ocumentстрока_документа----<GM.End ocument ИО-документа----<G M .End ocumentстрока_документаИО-документа--Элементы,выделенныежирнымшрифтом(напримерG M .End ocument),пишутсятак,какпо-казано, а элементы, набранные курсивом (например строка_документа), заменяются следующим образом:

строка_документа—символьнаястрока,идентифицирующаядокументРОУО,вкавычках("); ИО-документа—идентификаторобъектаАСН.1,присвоенныйдокументу,вфигурныхскоб-ках({}).

ДокументРОУОрассматриваетсякаксостоящийизвсехшаблоновРОУОимодулейАСН.1от директивы ocumentдосоответствyющейдирективыEndocument,илидоследyющейдирективы ocument, или до конца файла, содержащего этот текст РОУО. Таким образом, использование директивы Endocument^ обязательно. Если же директива Endocument используется, то она должнаследоватьзапоследнимшаблономРОУОилимодулемАСН.1,образующемдокумент.Стро-ка_документаи (или) ИО-документа в директиве Endocument должна(ы) соответствовать пред-шествующейдирективе ocument.

Примеры

--<G M .Endocument" - -

--<GM.Endocument"CCITT Rec.X.721 (1992)|IS/IES 10165-2:1992" - ---<GM.Endocument "RecomendationM.3100:1992" - ---<G M.Endocument "P1 Library Vol. 4" - ---<G M.Endocument {iso(1)2 124 360501 15 13 1} - ---<GM.Endocument"IIMCMIBTranslation"{iso(1)2 124 360501 15 13 1} - -

10.2.4 Директива версии

ДирективаVersionиспользyетсядляyказаниятого,какаяверсияРОУОиспользованавдокy-

менте.Форматдирективыможетиметьоднуизследующихдвухформ:

--<GM.Versionверсия --

--<GM .Version версияидентификатор_документа -Элементы, выделенныежирным шрифтом (например G M .Version), пишутся так, как показано, аэлементы, набранные курсивом (например версия), заменяются следующим образом: -версия—номер, указывающийверсию РОУО, всоответствиисоследующейтаблицей:

Индекс

Определение версии

1

РОУО, 1992

1.1

Дополнение 1:констрyкцияSET-BY-CREATE

1.2

Дополнение2:констрyкцииN-M IFI,ASN.1:1994идирективы

1.3

Дополнение 3:использование2вповеденииклассауправляемыхобъектов

Новые версии определяются при каждом обновлении РОУО (т. е., пересмотре, поправках, дополнениях). Обеспечениеданнойверсииявляетсякумулятивным.Этозначит,чтолюбойдокумент РОУО, действительный для версии n, должен быть допустимым и для предшествующих версий. HапримерG M .Version 1.2указывает,документРОУОподдерживаетверсиюРОУО1992(версия

1),дополнениеконстрyкцииSET-BY-CREATE (версия1.1)идополнениеконстрyкцийNO-MOIFI, ASN.1:1994идиректив(версия 1.2).

-идентификатор_документа—идентификатордокументаРОУОввидесимвольнойстрокив кавычках(")илиидентификатораобъектаАСН.1вфигурныхскобках({}).

Первая форма директивы (без идентификатора_документа) может находиться в документе РОУО, но до любого шаблона РОУО.

Примеры

--<GM.Version 1"CCITTRec.X.721(1992)|IS/IEС 10165-2:1992" - ---<GM.Version 1.1"Recomendation M.3100" - ---<GM.Version 1.2 --

ПРИЛОЖЕНИЕА

(справочное)

Примеры

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

А.1 Определение классауправляемых объектов examplebjectClass MANAGE BJECT CLASS

ERIVE FRM"CCITT Rec.X.721 (1992) | IS/IEC 10165-2 : 1992" : top CHARACTERIZE BY examplePackage2;

CNITINALPACKAGES

examplePackage1 PACKAGE

aCtINS    q SResetAction,

activate ;

NTIFICATINS communicationError ;

REGISTEREAS {joint-iso-ccitt ms (9) smi (3) part4 (4)package (4) examplepack1 (0)};

PRESENT IF |применяетсякласссоответствия2нижележащегоресурса, описанныйвИСО/МЭКХХХХ| ;

REGISTEREAS {joint-iso-ccitt ms (9)smi (3) part4 (4)

managedbjectClass (3) exampleclass (0)};

Примечание — Этотшаблониспользуетвозможностьвстроенногодокументированияусловного пакета.

А.2 Определение связывания имен exampleNameBinding NAME BINING

SUBRINATE BJECT CLASSexamplebjectClass;

NAME BY

SUPERIR BJECT CLASS "CCITT Rec.X.721 (1992) | IS/ИС 10165-2 : 1992" :system; WITHATTRIBUTE objectName;

BEHAVIUR

containmentBehaviourBEHAVIUR

EFINE AS |Влюбомэкземпляре"CCITT Rec.X.721(1992)

| IS/IEС 10165-2 : 1992" : systemможетсодержаться неболеетрехэкземпляровexamplebjectClass |

;

CREATEWITH-AUTMATIC-INSTANCE-NAMING createErrorParameter;

ELETE ELETES-CNTAINE - BJECTS;

REGISTEREAS {joint-iso-ccitt ms (9) smi (3) part4 (4) nameBinding (6) examplenb (0)};

Примечание — Этотшаблониспользуетвозможностьвстроенногодокументированияповедения.

А.3 Определениепараметров pUHeader PARAMETER

CNTEXT    EVENT-INF;

WITH SYNTAX    ParameterModule.PUString;

BEHAVIUR

pUHeaderBehaviour BEHAVIUR EFINE AS |ЗаголовокПБД.

ПередаетсявполеПОИУeventInfo. |

REGISTEREAS {joint-iso-ccitt ms (9)smi (3) part4 (4) parameter (5) pduheaderparam (0)}; createErrorParameterPARAMETER

CNTEXT    SPECIFIC-ERRR;

WITH SYNTAX    ParameterModule.ErrorInfo1;

BEHAVIUR

createErrorBehaviour BEHAVIUR

EFINE Л S |Есливовмещающемуправляемомобъектесуществуетмаксимальновозможноечисло экземпляровexamplebjectClass,топопыткасозданиядополнительныхэкземпляров приведетквозвратусообщенияобошибкеПОИУ«Отказобработки»,вкоторомполе SpecificErrorInfo имеетвид SpecificErrorInfo: : = SEQUENCE { errorid BJECT IENTIFIER, errorinfoANY EFINE BY errorid }

BJECT IENTIFIER , передаваемый вerrorid,долженбытьзначениемпараметра, подкоторымонозарегистрировано.Тип,передаваемыйвerrormfo,долженбытьиден-тифицированнымконстрyкциейWITHSYNTAXэтогоопределенияпараметра.Значе-ние,передаваемоетипом,указываетчисло экземпляров этого классауправляемых объектов,которыевданныймоментсуществуютвовмещающемуправляемом объекте.|

REGISTEREAS {joint-iso-ccitt ms (9)smi (3)part4 (4)parameter (5)createrror (1)}; serviceProviderErrorResponseReason PARAMETER CNTEXT    ACTIN-REPLY;

WITH SYNTAX    ParameterModule.ServiceProviderErrorResponseReason;

BEHAVIUR

serviceProviderErrorResponseReasonBehaviour BEHAVIUR

EFINE AS|ВозвращаетсявполегesponsePARAMETERSПОИУactionReplyInfo,еслиresponceCode имееттекyщеезначениеserviceProviderErrorResponse. |

REGISTEREAS {joint-iso-ccitt ms (9)smi (3)part4 (4)parameter (5)sperrorrsp (2)};

Примечание — Этотшаблониспользуетвозможностьвстроенногодокументированияповедения.

А.4 Определениепакета examplePackage2 PACKAGE

BEHAVIUR    exampleClassBehaviour;

ATTRIBUTES    objectName

GET,

qS-Error-Cause

GET,

qS-Error-Counter

PERMITTERVALUESAttributeModule.QSCounterRange

REQUIREVALUESAttributeModule.QSCounterRange

GET;

ATTRIBUTE GRUPSqS-Group;

NTIFICATINS protocolError;

REGISTEREAS {joint-iso-ccitt ms (9) smi (3) part4 (4)package (4) examplepack2 (1)};

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

А.5 Определенияатрибутов objectName ATTRIBUTE

WITHATTRIBUTE SYNTAXAttributeModule.bjectName;

MATCHES FR    EQUALITY;

REGISTEREAS {joint-iso-ccitt ms (9) smi (3) part4 (4) attribute (7) objectname (0)}; qS-Error-CauseATTRIBUTE

WITHATTRIBUTE SYNTAXAttributeModule.QSErrorCause;

MATCHES FR    EQUALITY;

BEHAVIUR    qSErrorBehaviour;

REGISTEREAS {joint-iso-ccitt ms (9) smi (3) part4 (4) attribute (7) qoscause (1)}; qS-Error-CounterATTRIBUTE

WITHATTRIBUTESYNTAXAttributeModule.QSErrorCounter;

MATCHES FR    EQUALITY, RERING;

BEHAVIUR    qSCounterBehaviour;

REGISTEREAS {joint-iso-ccitt ms (9) smi (3) part4 (4)attribute (7) qoscount (2)};

А.6 Определение атрибутивной группы qS-GroupATTRIBUTE GRUP

GRUP ELEMENTSqS-Error-Cause,qS-Error-Counter;

ESCRIPTIN |Атрибутивнаягруппа,котораявключаетвсебявсеатрибуты, относящиесяккаче-ствууслугивклассеуправляемыхобъектов.|;

REGISTERE AS {joint-iso-ccitt ms (9)smi (3) part4 (4) attributeGroup (8) qosgroup (0)};

А.7 Определениядействий qSResetActionACTI N BEHAVIUR reset BEHAVI UR

EFINE AS | <Определениеповеденияresetиеговлияниянаработyyправляемогообъекта ит.п. |

ME C NFIRME ;

REGISTEREAS {joint-iso-ccitt ms (9)smi (3) part4 (4)action (9) reset (0)};

Примечание—Этоопределениедействияиспользуетвозможностьвстроенногодокументирования

поведения.Абстрактныесинтаксисыдлявывозаиответанеопределены.

activateACTIN

BEHAVIUR

activateBehaviour BEHAVIUR

EFINE AS | Делаетуправляемыйобъектдоступнымдляработы.Еслийдействиеуспешное, товозвращается значение successResponse в параметреresponseCode ПОИУ actionReplyInfo.Еслидействиенеyдачноеиз-запроблемспоставщикомнижесле-дyющихyслyг,тогesponseCodeyстанавливаетравнымseгviceProviderErrorResponse ивозвращаетсяпараметрserviceProviderErrorResponseReasonдляyказанияпричи-ныпроблемы.|

Me C NFIRME ;

PARAMETERS    serviceProviderErrorResponseReason;

WITH REPLY SYNTAX ActionModule.ActivateReply;

REGISTEREAS {joint-iso-ccitt ms (9)smi (3) part4 (4)action (9) activate (1)};

А.8 Определения сообщений communicationError NTIFICATIN

BEHAVIUR    communicationErrorBehaviour;

WITH INF RMATIN SYNTAX NotificationModule.ErrorInfo;

WITH REPLY SYNTAX    NotificationModule.ErrorResult;

REGISTEREAS {joint-iso-ccitt ms (9)smi (3) part4 (4)notification (10) commerror (0)}; protocolError NTIFICATIN BEHAVIUR protocolErrorBehaviour    BEHAVIUR

EFINE AS |Создается,когдапротокольныйобъектполучаетПБД,которыйявляетсянедо-пустимымилисодержитошибкупротокола.Сообщениевключаетвсебязаго-ловокполученногоПБД.|

PARAMETERS p UHeader;

WITH INFRMATINSYNTAX NotificationModule.ProtocolError;

REGISTEREAS {joint-iso-ccitt ms (9) smi (3)part4 (4)notification (10)protoerror (1)};

Примечание—Этотшаблониспользуетвозможностьвстроенногодокументированияповедения.

А.9 Определенияповедения qSCounterBehaviour BEHAVIUR

EFINE AS | АтрибyтqSErrorCounterявляетсясчетчиком,которыйyвеличиваетсянаединицyпри каждомпоявленииошибкиКУ.Егозначениеявляетсяположительнымцелым,диапазон которогоспецифицируетсявпакетах, ссылающихсянаэтоопределение. Когдасчетчик достигаетмаксимальногозначения,следующееувеличениевызываетвозвратзначенияк нулю. |;

qSErrorBehaviour BEHAVIUR

EFINE AS | АтрибyтqSErrorCauseyказывает причину отказа КУ, связанной с управляемым объектом.

Примечание — Взаимоотношениямеждудопустимымизначениямиатрибутаи работойсамогоуправляемогообъектаопределяютсяопределениямиповедения,связан-ногосопределениемклассауправляемыхобъектов.|; communicationErrorBehaviour BEHAVIUR

EFINE AS | Сообщение CommuшcationEггoгсоздаетсяклассомyправляемыхобъектов,когдаyп-равляемыйобъектобнаруживаетошибкукоммуникации.Сообщениеможетсодержать любyюкомбинациюпараметровProbableCause, Severity,TrendIndication,BackedUpStatus, iagnosticInfo,ProposedRepairAction,TresholdInfo, StateChange иtherInfo.

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

exampleClassBehaviourBEHAVIUR

EFINE AS | <...Описаниеповеденияклассауправляемыхобъектов,включаяописания: -какатрибутыполучаютконкретныезначенияикакойониимеютсмысл; -какиеобстоятельствавызываютсозданиесообщений;

- ит. п.. ;

А.10 МодулиАСН.1

AttributeModule {joint-iso-ccitt ms (9)smi (3)part4 (4)asn1Module (2) attributes (0)};

EFINITI NS: : = BEGIN bjectName: : = GraphicString QSErrorCause: : = INTEGER {

responceTimeExcessive    (0),

queueSizeExceeded    (1),

bandwidthReduced    (2),

retransmissionRateExcessive    (3) }

QSErrorCounter: : = INTEGER

QSCounterRange: : = QSErrorCounter {0 . . 4294967296}—Диапазон32бита.

E N

NotificationModule {joint-iso-ccitt ms (9)smi (3)part4 (4)asn1Module (2) notifications (1)};

EFINITI NS: : = BEGIN IMPRTS

ProbableCause, PerceivedSeverity, TrendIndication, BackedUpStatus, ProposedRepairActions, ThresholdInfo, ManagementExtension

FRM Attribute.ASN1Module {joint-iso-ccitt ms (9)smi (3)part2 (2) asn1Module (2) 1};

ErrorInfo: : = SET {

[0]ProbableCause    PTI    NAL,

[1]PerceivedSeverity    PTI    NAL,

[2]TrendIndication    PTI    NAL,

[3]BackedUpStatus    PTI    NAL,

[4]    ProposedRepairActions    PTI    NAL,

[5]ThresholdInfo    PTI    NAL,

[6]    therInfo    PTI    NAL }

ErrorResult: : = NULL

therInfo    : : = SETF ManagementExtension

ProtocolError    : : = SETF ManagementExtension

E N

ActionModule {joint-iso-ccitt ms (9) smi (3) part4 (4) asn1Module (2) actions (2)}

EFINITI NS: : = BEGIN IMPRTS

perationalState,ManagementExtension

FRM Attribute.ASN1Module {joint-iso-ccitt ms (9)smi (3)part2 (2) asn1Module (2) 1};

ActivateReply: : = SEQUENCE {

operationalStatus    [0] perationalState,

responseCode    [1] INTEGER{successResponse    (0),

serviceProviderErrorResponse    (1)},

responseParams    [2]    SET    F    ManagementExtension    pTiNAL    }

ParameterModule{joint-iso-ccitt ms (9)smi (3) part4 (4) asn1Module (2) parameters (3)} EFINITI NS: : = BEGIN ErrorInfo1: : = INTEGER

ServiceProviderErrorResponseReason: : = ENUMERATE{ insufficientResources    (0),

provideroesNotExist    (1),

providerNotAvailable    (2),

requiredServiceNotAvailable (3) }

PUString: : = CTETSTRING E N

ПРИЛОЖЕНИЕВ

(справочное)

Руководство по применению Z при формализацииповеденияуправляемых объектов

В.1 Введение

Настоящее приложение содержит техническое руководство по применению языка Z для определения поведенияуправляемыхобъектов,которыеподдерживаютадминистративноеуправлениевзаимодействиемВОС. Оно является справочным, а не нормативным. Оно не требует, чтобы для спецификации поведенияУО ис-пользовалисьметодыформальногоопределения(МФО).Еслитребуется,чтобыиспользовалисьМФО,тотем самымне требуется, чтобыиспользовалсяZ; могутиспользоваться другие языки, такие как SL. Даже когда должениспользоватьсяZ, возможныи другие способы спецификации поведенияУО.

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

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

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

Внастоящемприложениитермин«управляемыйобъект»(или«УО»)используетсядляопределенияклас-сауправляемыхобъектов, данныхс использованиемшаблонов РОУО.

В.2 Вопросы языка

HотацияZявляетсяформальноопределеннойнотацией,основаннойнатеориимножествиисчислении

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

ОднаковZнесyществyетпонятиеинкапсyляции.СпецификацияZобычносостоитизмоделинекото-

рогосостоянияисовокyпностиоперацийдляизмененияэтогосостояния.ВZнетметодовдляделениясосто-

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

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

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

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

ВовсехостальныхотношенияZподходитдлявыраженияотдельныхклассовyправляемыхобъектов.

В.3 Элементы,подлежащие преобразованию

Требуетсяпреобразоватьопределениеповедения(илиегочасть)изнеформальногоописаниявописание Z. Степень, в которой должны быть формализованы оставшиеся части шаблонов РОУО, зависит, главным образом, отпотребностейразрабочикаспецификации.

Шаблоны РОУО уже включают в себя полуформальные определения типов данных в АСН.1. Можно написатьспецификациюZ, используяэтиопределения АСН.1 вкачестве основы длятипов,используемыхв спецификацииZ, что сэкономитсущественнуючастьработы.

Однако если спецификация написана таким образом, то большой проблемой для разработчика стано-витсягарантияеесинтаксическойкорректности.ВспецификацияхZбезопределенийАСH.1можноисполь-зовать существующие средстваZ, которые обеспечивают поддержку проверки синтаксиса и статической се-мантикиспецификацииZ.

Таким образом, можно улучшить определения поведения, используя Z без переписывания типов дан-ныхАСН.1,носущественныепреимуществамогутбытьполученыприполномпреобразованиитиповданных АСH.1.вZ.Примерытого,какпреобразовываютсяосновныетипыАСH.1вZ,приведенывВ.7.1.

В.3.1 Преобразование из шаблонов РОУО в Z

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

Нижеперечисленынекоторыеосновныехарактеристикишаблонов,определенныхвнастоящемстандар-

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

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

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

В.3.2 Типы данных

Первым шагом является переписывание типов данных настоящего стандарта в виде типов Z. АСН.1 предоставляетполезныевозможностипосозданиютиповданных,ноихпостроениеориентированонаописа-ние потоков данных, передаваемыхмеждусистемами.

В АСН.1 построениетипаопределяется в виде списка. В Zтипыявляются множествами. Хотя можно моделировать построение типа АСН.1 в виде последовательности в Z, иногда бывает более естественным рассмотретьоперации,доступныенадтипамиАСН.1,иотобразитьихвтипы^,чтоболееясноописываетих стрyктyрy.ТипыАСH.1«последовательность»и«множество»могyтбытьотображенывтипZ«кортеж». Тип АСН.1 «последовательность-из» может быть отображен в тип Z «последовательность». ТипАСН.1 «множество-из»можетбытьотображенвтипZ «множество».

АСН.1 включаетвсебяспециальноеобеспечениекодирования,такоекакметкиизначенияпоумолча-нию.ОнинеобязательнодолжныбытьпредставленывZ,т.к.невлияютнаопределениеповедения.

ВпунктеВ.6.2приведенадополнительнаяинформацияопреобразованиитиповАСН.1.

В.3.3 Атрибуты УО

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

- простые типы атрибутов и

-типыатрибутовкаксхемы.

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

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

Трудно моделировать типANYАСH.1вZ.Внекоторыхслyчаяхможнодатьсписокзначенийатрибyта. Таким образомполнаяформальнаямодель, вероятно, потребyеткомбинациисвободноготипаZ сужеопре-деленнымитипамиатрибутов.ПримерыприведенывВ.6.1иВ.6.5.

Идентификаторыобъектовформальномоделируютсямножеством:

[OBJECTI]

В.3.4 Дру гие идентификаторы объектов

Многиеэлементы,кромеатрибутов,имеютидентификаторыобъектов.Удобноввестиихвсекакпосто-янныеваксиоматическиеопределения.Можноиспользоватьсоглашениеодополненииихсyффиксом«Oid». Такие постоянные будутнеобходимы для классов, пакетовисообщений.

Пример

packagesPackageOid: OBJECTI allomorphsPackageOid: OBJECTI topClassOid: OBJECTI

В.3.5 Наследование и совместимость

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

Таким образом Z может использоваться для удовлетворительного определения отдельных УО, но для того,чтобыможнобылоговоритьонаследованииисовместимости,необходимыдополнительныевозможно-стиязыка.

HаследованиенеподдерживаетсявZ.Ономожетбытьсмоделировановключениемсхемвсхемысостоя-

ния.

Определение наследованияУОтребует,чтобыподклассыбылисовместимы.Нонетребует,чтобыпод-классыбылиподтипамивZ.ОбычноУОможетсообщитьсвойфактическийкласс.Таккакатрибyт«фактичес-кий класс» всегдасодержитфактический класс объекта, топодкласс не можетсообщитькласс своего суперкласса. Следовательно, подкласс не может демонстрировать при возврате значения атрибута «фактический класс»тожесамоеповедение,чтоиегосуперкласс (т. е.ониневзаимозаменяемы), дажееслиихповедение алломорфно.Следовательно,подклассыyправляемыхобъектовнеэквивалентыподтипамвZ,гдеподтипбyдет демонстрироватьтожесамоеповедение,чтоисупертип.Однакоподклассдемонстрируеточеньмало«непод-ходящее»поведение.

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

В.3.6 Пакеты

Многие части функциональных возможностей класса могут присутствовать в одних конкретныхУО и отсутствоватьвдругих.Внастоящемстандартеэтоописываетсяспомощью группирования функциональных возможностейвyсловныепакеты.ТогдакаждыйУОреализyетподходящиепакеты.ВZфyнкциональныевоз-можностинемогутбытьпредоставленытакимспособом,номожносделатьповедениеУОзависящимоттого, какиепакетыреализованы.Этоможносделатьнепосредственнымобразомпотому,чтоУОдолженсодержать атрибутадминистративногоуправления,называемый«пакеты»,вкоторомперечисленыидентификаторыобъек-товфактическиреализованныхпакетов.Такимобразомдлямоделированияповеденияусловногопакетасамо поведениестановитсязависящимотприсутствияидентификаторапакетаватрибуте«пакеты».

В.3.7 Класс

Для определения класса УО необходимо представить его атрибуты и операции. Атрибуты становятся частьюсхемысостоянияZ,аоперациистановятсясхемамиоперацийZ.

В.3.7.1Атрибуты

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

которыйможетбытьтипом,объявленнымвчастиАСH.1шаблонаРОУОиливполнойформальноймоделиZ.

В.3.7.2 Операция Get

УправляющийможетзапроситьвыполнениеоперацииGetнадУО.ВопределенииУОИУМ-Getимеет многопараметров,нобольшинствоизнихотноситсякуправлениюдоступом,выборуобъектаит.п.Вконкрет-номэкземпляреGetможетбытьсмоделировананаграницеyправляемогообъекта,игнорирyяyказанныевоп-росы и заменяя единственную операцию Get несколькими операциями Get<имя, где <имя — единствен-ныйатрибут.

В.3.7.3 Операция GetAll

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

В.3.7.4ОперацияReplace

УстановкивконкретномУОзапрашиваютсяоперациейУОИУM-Set.Внастоящейспецификацииопера-ции Replace моделируются как видимые на границе УО. Эти операции относятся к установкам атрибутов, установкам значений по умолчанию, добавлению и удалению значений. Следовательно, для представления каждогоизэтихизмененийдолжнабытьспецифицированасхемаZ.

В.3.7.5Сообщения

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

ДанныевсообщениисостоятизтипасобытияEventType,которыйявляетсяидентификаторомобъекта его стандартного определения. Идентификатор объекта может быть определен как постоянная, конкретные данные—кактипсхемы.Поведениесообщениявключаетсявкаждыйобъект,которыйможетэтосообщение создавать.

В.3.7.6 Действия

Являютсяоперациями,осуществляемымиуправляющимнадУО.Ониестественнымобразомпредставля-

ютсяоперациямиZ.

В.3.8 Спецификация системы объектов

Воставшейсячастинастоящегоприложенияописанопредставлениеповеденияединичногообъекта.При

рассмотрениисозданияиудаленияобъектов,связыванияимен,вмещенияинаименованиянеобходимоопи-

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

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

намножествеобъектов.Наименованиеможетбытьопределеновтерминахэтогоотношения.

В.4 Пример

ВнастоящемподразделеприведенпримеропределенийвысшегоклассаУОиатрибутовадминистратив-

ногоуправления.Таккаквданномруководствеосновноевниманиеуделяетсямоделированиюповедения,тов

этомподразделенепоказаносозданиетиповZизтиповАСH.1.ПолноеформальноеопределениедановВ.7.

В.4.1 Класс top

Первымклассом,которыйдолженбытьопределен, является^, представляющийсобойосновногоро-дителя (в иерархии наследования) для всехУО.

Класс top имеет четыре атрибута административного управления: objectClass, packages, allomorphs и nameBinding.Ватрибyтеob/ectC/ass>фанитсяидентификаторобъектакласса,вpackages—идентификаторыобъектов реализованныхпакетов, вnameBinding—идентификаторобъектасвязыванияимен, использованного прире-ализации объекта, а в allomorphs — идентификаторы объектов классов, с которыми объект может быть алло-морфен.Таккакатрибутыадминистративногоуправлениямогутнаходитьсявпакетах,атрибуты,присутству-ющиевУОданногокласса,могyтизменяться.Этомоделирyетсявключениемдополнительногоатрибyтаatгribмtes, вкоторомхранятсяидентификаторыобъектоватрибутов,фактическиреализованныхвданномУО.Всеатрибу-ты, присутствующие в классе tor, фиксированынапротяжениижизниконкретногоУО.

ИнтерфейсывZне моделируются явно и, таким образом, не возможно формально определить, какие операциивызываютсявнутренне управляющим, какие — внешне:

TopState

allomorphs : FOBJECTI

objectClass : OBJECTI

nameBinding: OBJECTI

packages : FOBJECTI

attributes : FOBJECTI

{objectClassOid,nameBindingOid} с attributes

allomorphsPackageOid e packages ^ allomorphsOid e attributes

packagesPackageOid <£ packages

packages ф 0 ^ packagesOid e attributes

attributesявляетсянеатрибyтомУО,ановымкомпонентомсостояния,определеннымдляyдобства.Внем перечислены атрибуты, которые содержатся в УО. Следовательно, инвариант требует, чтобы он содержал идентификаторыобъектовподходящихатрибyтов,какописановВ.3.3(иопределеновВ.7.4).Атрибyтыob/ectClass и nameBindingявляютсяобязательными.Атрибyтpackagesприсyтствyеттольковтомслyчае,когдареализован любойзарегистрированныйпакет,отличныйотpackagesPackage. Впоследнемслучаеэтотатрибутобозначает allomorphsPackage.

ОперацияTopG!etA,ameBindingэпрашиваетУОивозвращаетзначениеатрибyтаnameBinding5езизменения TopState. Операция TopGetNameBindingвызываетсяyправляющим:

TopGetNameBinding

3 TopState result : OBJECTI

result:: nameBinding

ОперацияTopGetAllomorphs, TopGetObjectClass и TopGetPackagesздесьнеопределяются.Hетоперациидля полyченияattributes, так какattributes'WiявляетсяатрибутомУО,определеннымвшаблонеРОУО.

Операция TopGetAllполучетзначения атрибутов объекта. Онавсегдавозвращаетзначения objectClass и nameBinding.Еслиприсyтствyютyсловныепакетыилиалломорфизм,товозвращаютсяиони.ОперацияTopGetAll вызываетсяуправляющим:

TopGetAll

3 TopState

result : PAttributeValues

# attributes =# result|

ObjectClassValueobjectClass e result |

NameBindingValuenameBinding e result |

PackagesOid e attributes ^ packagesValuepackages e result |

AllomorphsOid e attributes ^ allomorphsValueallomorphs e result |

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

TopEventReport

3 TopState

notification : EventInfo

В.4.2 Класс StateManagement

Не отражает никакой конкретный класс УО. Он отражает поведение любого объекта, содержащего любойизстандартныхатрибyтовadministrativeState, operationalState и usageState. Врамкахданногоподхода он удобен для понимания включения этих атрибутов как наследования и не является примером для использования.

СхемасостояниявключаетвсебяопределенияTorStateипредикатыиспецифицирyетнекоторыедопол-

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

StateManagementState

TopState

administrativeState:

AdministrativeState operationalState : OperationalState usageState : UsageState

operationalState=disabled^ usageState=idle administrativeState =locked^ usageState =idle usageState=idle ^administrativeState ф shuttingown

КлассStateManagementнаследyетоперацииотTop.ХотянетспособавстроитьвZнаследованиеопера-ций,непосредственнымметодоммоделиванияявляетсяповторноеопределениеоперацийвтерминахнового состояния. Предикаты состояния StateManagement следуют из определения функции StateManagement в ГОСТР ИСО/МЭК 10165-2иГОСТРИСО/МЭК 10164-2.

МожетбытьлегкоопределенаоперацияSMGetNameBinding,таккаконанеоказываетдействиянановые переменные состояния, объявкеппыев StateManagementState. Определение TopGetNameBindingможет бытьис-пользованоповторно:

SMGetNameBinding

TopGetNameBinding 3 StateManagementState

Операции для получения других атрибутов StateManagementState также опущены в этом примере. Для операцийSMGetAllomorphs,SMGetObjectClass и SMGetPackagesмогyтбытьповторноиспользованыопределения из Тор, как для SMGetNameBinding. Необходимо определить новые операции GetSMAdministrativeState, GetSMOperationalStateuSMGetUsageState.МожnоповторnоиспокьзоватьSMEventReport.

СхемаSMGetAllгакжеиспользyетоперации,определенныевTopState.Онавключаетвсебяопределение TopGetAllиyсиленные постусловия:

SMGetAll

3 StateManagementState TopGetAll

administrativeStateOid e attributes

^ administrativeStateValueadministrativeState e result |

OperationalStateOid e attributes

^ operationalStateValueoperationalState e result |

UsageStateOid e attributes

^ usageStateValueusageState e result |

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

SMReplaceAdministrativeState

A,StateManagementState 3 TopState

input?: AdministrativeState administrativeState’ e IFusageState ф idle

THEN{ unlocked ^ unlocked,locked ^ locked,

shuttingown ^ locked,locked^ shuttingown, shuttingown ^ shuttingown} ({input?})

ELSE { unlocked ^ unlocked,locked ^ locked, shuttingown ^ locked} ({input?}) administrativeState’ e locked ^ usageState’ =idle administrativeState’ ф locked ^ usageState’ =usageState operationalState’ =operationalState

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

Существует ряд других операций, которые описывают поведение, специфичное для класса StateManagement.Этиоперациинеперечисленыздесь,ноприведенывВ.7.ВихчисловходятSMCapacityecrease, SMCapacityIncrease,SMisable,SMEnable,SMNewUseruSMUserQuit.

В.4.3 Реализуемые классы

Ниодинизописанныхвышеклассовнеможетбытьреализован.Использованнаяпроцедурапостроения классовможетбытьпродолжена.КлассStateManagemenгможноповторноиспользоватьдляопределенияклас-са, названного CIRCU7T,который,всвоюочередь,можетбытьиспользовандляопределенияклассаECIRCU7T и, следовательно, реализуемого классаActualECircuit. Эта часть работы не приведена в руководстве, так как процедураточнотакаяже, что иописаннаявыше, иповторение не добавитничего нового.

В.5 Нерассмотренные вопросы

Вданномподразделеперечисленыосновныевопросы,встречающиесяприпереводеспецификацийуп-

равляемыхобъектовРОУОвZ.ТакжеприведенапредлагаемаянеформальнаятрактовкатехотносящихсякZ

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

объекта.

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

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

В.5.2 Внутренние операции в Z

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

В.5.3 Абстрактные классы в Z

Иногдаполезноидентифицироватьабстрактныеклассы,т.е.классы,которыенеимеютсвоейсобствен-нойреализации.HекоторыеклассыУО(например,top)немогyтбытьреализованы.Былобыполезнопоказать, какиечастиспецификацииZпредставляютклассы,которыенемогyтбытьреализованы.Внастоящеевремяэто делается с помощью неформальной аннотации.

В.5.4 Семантика конструкции PARAMETERS

Включение семантики конструкции PARAMETERS в объекты не рассматривается в настоящем стандарте.

В.6 Преобразованиетипов данныхАСН.1в Z

НижерассмотренывопросыпереводаконструкцийАСН.1.

В.6.1 Простые типы

АСН.1включаетвсебянекоторыепростыетипы,которыеявляютсявстроенными.Ониимеютстандар-

тнуюструктуру,нообычноэтонепредставляетинтересавконтекстенастоящегостандартаиихследуетпред-

ставлятькакзаданныемножества.Имеетсябольшойнабортиповсимвольныхстрок:

[NUMERICSTRING, PRINTABLESTRING, TELETEXSTRING,

VIEOTEXSTRING, VISIBLESTRING, IA5STRING,

GRAPHICSTRING, GENERALSTRING]

Дваизнихимеютсинонимы:

T61STRING = = TELETEXSTRING ISO64STRING = = VISIBLESTRING

Из других простых типов целый может быть представлен как Z, а булевский и вырожденный — как свободныетипы:

Boolean : : = btrue | bfalse Null: : = null Этитритипаопределяютинотациюихзначений.

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

[REAL,BITSTRING, OCTETSTRING ]

Внастоящемстандартеописанещеодинспециальныйтип,которыйможетбытьпредставленкакзадан-

ноемножество:

[OBJECTI]

ОнпредставляетидентификаторобъектаАСН.1.

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

ВАСН.1определеноещенесколько«полезных»типов.Хотяонимогутбытьопределенывтерминахдругих

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

[GENERALIZETIME, UTCTIME, OBJECTESCRIPTOR, EXTERNAL]

ANY

ВАСH.1имеетсяспециальныйтипANY,которыйможетсодержатьАСH.1 любого другоготипа. Такой типнедопyстимвZибыло бытруднорасширитьэтотязыкдлявключенияподобноготипа. Однако, задавая некотороеизвестноемножествотипов,можноопределитьсвободныйтипZ,которыйможетвключатьвсебя любойизэтихтипов.Альтернативныйподходсостоитвтом,чтобыопределитьANYкакзаданноемножество дляцелейпроверкитипа.Этоприемлемодотехпор,покаснимненyжноделатьничегодрyгого.ТипAttributeValues обычно замещает ANY, что описано ниже.

В.6.2 Структурированные типы

ДругиетипыАСН.1строятсянаоснове конструкций.

Множество

Множества АСН.1 могут быть представлены в Z либо как кортежи, либо как схемы. Кортежи Z не позволяютименоватькомпоненты,ивэтомотношениибольшеподходятсхемы.ОднаконотациязначенийZ длясхемменееyдобна.ТегированиевZневозможноиненyжно,таккаккомпонентымножествавсегдамогyт бытьопознанылибопоихположениювкортеже,либопоименикомпонентавсхеме.

Компоненты этого идругихструктурированныхтиповмогутбытьфакультативными( OPTIONAL). Это можетбытьпредставленовZдополнениемтипафакyльтативногокомпонентаспециальнымзначением«отсyт-ствует».3наченияпоумолчанию EFAULT'tts могутбыть представленыудобнымобразомкаксвойстватипа данных.Можнопредставитьповедение,подразумеваемоеумолчанием,вовсехоперацияхнадэтимтипомдан-ных.

Последовательность

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

Множество-из

Множества-изАСH.1могyтмоделироватьсякакпоследовательностиZ.

Выбор

Выборочныетипы АСН.1 непосредственноявляютсяперечислениямиимогутмоделироватьсясвобод-нымитипамиZ.

Сэтимтипомсвязанасерьезнаяпроблемаобластидействия.ВАСН.1конструкциивпределахвыборочно-готипаявляютсялокальнымидляэтоготипа.Такимобразомодноитожеимяконструкцииможетиспользо-ватьсявнесколькихперечислениях.ВZименаявляютсяглобальнымиимогyгбытьповторноиспользованы.Эта проблема обычно может быть разрешена изменением имен конструкций, как правило, путем добавления к нимвкачествепрефиксаимениихтипа.

Аналогичная проблема возникает, когда создаются типы АСН.1, являющиеся синонимами, например целого, но с поименованными значениями. Эти поименованные значения являются локальными для типа-синонимавАСH.1,ноглобальнымисинонимамидляцелыхвZ.Дляразрешенияэтойпроблемытакжеможно изменитьименаконструкций.

В.6.3 Простые типы атрибутов

ПрощевсегопредставитьатрибyтвУОкакпеременнyюZссоответствyющимтипомданных.Потребyет-

сятакжеопределениепостоянной,представляющейOBJECT/этогоатрибyта.Когдадляатрибyтаопределе-

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

сования.

РассмотриматрибyтУОadministrativeState.Имеетсяопределениетипа:

AdministrativeState: : = unlocked | locked | shuttingown

Можетбытьопределенапостояннаядляпредставленияидентификатораобъектаатрибута:

administrativeStateOid: OBJECTI

Фактическоезначениеидентификатораможетбытьпредставленокакограничениенаэтоаксиоматичес-кое определение.

МожетбытьопределенапеременнаясостояниявУО:

MOState

| administrativeState: AdministrativeState_

Такоерешениеявляетсяпрямымиyдобным,нотребyетспискааксиоматическихопределенийOBJECT/. ОнотакжеделаетсвязьмеждyименематрибyтаиегоOBJECT/чистосинтаксической.Вэтомрешениибыло принятосоглашениеобиспользованиисуффикса Oid.

В.6.4 Типы атрибутов как схемы

Можновключитьвсеэтихарактеристикиатрибутаводинтипсхемы,которыйбудеттипомпеременной Z, моделирующей атрибутУО:

AdministrativeStateType

value: AdministrativeState Oid: OBJECTI

Oid=<4,3,19,27,1,3

Важно подставить именно здесь значение OBJECTI, так как необходимо гарантировать, что оно не можетбытьизменено.

Структура OBJECTI покане определена, нозапись OBJECTI = = seql N

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

MOState

administrativeState: AdministrativeStateType

Ссылка на его значение (или на его Oid) может быть сделана через выбор компонента, например administrativeState.value.

Этотметодудобнопередаетсемантикудлясвязимеждуатрибутомиего OBJECT/.Однакодлячитате-лей спецификации может показаться странным, что Oid присутствует в состоянии УО, хотя он и не может изменяться (ифактическиявляетсяглобальнойпостоянной,известнойнамоментспецификации).

В.6.5 ТипAttributeValues

Какyжеотмечалось,вZтрyдномоделироватьтипАСH.1ANY.Общимподходомявляетсязаданиеспис-

ковзначенийатрибyта.ТребyетсяопределениесвободноготипаZвкомбинациисyжеопределеннымитипами.

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

кации.Тогдарешениебудетвыглядетьприблизительнотак:

AttributeValues: : = administrativeStateValue«AdministrativeState | objectClassValue <<OBJECTI | nameBindingValue <<OBJECTI | packagesValue<< P OBJECTI | allomorphsValue<< P OBJECTI | operationalStateValue<<OperationalState | usageStateValue <<UsageState

В.7 Полный пример

В настоящем подразделе представлена полная формальная модель, на которой основан пример в В.4. Модель представлена в традиционном для Z стиле объявления до использования; а именно, определения типов, преобразованные из АСН.1, появляютсяв начале, аопределенияповедения —в конце.

Следует прокомментировать одно место в стиле спецификации. Определения AttributeValues и OBJECT/NST4NCEIвляютсявзаимнорекyрсивными.ВZэтотехническинедопyстимо,идлятого,чтобыдать определения, было сделано следующее. Тип AttributeValues был введен как заданное множество. Затем

OBJECTINST4NCE)ылопределенсиспользованиемзаданногомножестваAtributeValues.ОпределениеOBJECT-INSTANCE было использовано для введения ограничений того, что может принимать AttributeValues. Была выполненапроверкаограничениядлятого,чтобыпоказать,чтотакиемножествафактическисуществуют,но впримереэтонепоказано.

В.7.1 Основные типы АСН.1 [NUMERICSTRING,PRINTABLESTRING, TELETEXSTRING, VIEOTEXSTRING]

[ VISIBLESTRING,IA5STRING, GRAPHICSTRING, GENERALSTRING]

T61STRING = = TELETEXSTRING ISO64STRING = = VISIBLESTRING Boolean : : = btrue | bfalse Null: : = null

[REAL, BITSTRING, OCTETSTRING]

[OBJECTI ]

[ANY]

[ GENERALIZE TIME, UTCTIME, OBJECTESCRIPTOR, EXTERNAL]

В.7.2 Атрибуты У О

Следующеезаданноемножестворезервируетместодляболеесложногоиполногоопределениясвобод-

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

[AttributeValues]

AttributeValuesOptional: : = present<<AttributeValues | absent Relative istinguishedName = = AttributeValues RNSequence = = seqRelative istinguishedName istinguishedName = = RNSequence

OBJECTINSTANCE: : = distinguishedName<<istinguishedName | nonSpecificForm<<N

| localistinguishedName<<RNSequence

В.7.3 Сообщения ProbableCause = = OBJECTI

SpecificIdentifier: : = globalvalue< <OBJECTI | localValue<<N SpecificProblems = = PSpecificIdentifier

SpecificProblemsOptional: : = sPPresent<<SpecificProblems    | sPAbsent

PerceivedSeverity: : = indeterminate\critical\ major\minor |warning\cleared BackedUpStatus = = Boolean

BackedUpStatusOptional: : = bUSPresent<<BackedUpStatus | bUSAbsent ObjectInstanceOptional: : = oISPresent<<OBJECTINSTANCE | oIAbsent TrendIndication: : = lessSevere | noChange | moreSevere TrendIndicationOptional: : = tIPresent<< TrendIndication    | tIAbsent

ObservedValue: : = int< <N | real<<REAL

ObservedValueOptional: : =oVPresent<<ObservedValue    | oVAbsent

ThresholdLevelInd: : =

up<<ObservedValue■ ObservedValueOptional | down <<ObservedValue■ ObservedValueOptional ThresholdLevelIndOptional: : = tLIPresent<<ThresholdLevelInd|tLIAbsent ArmTimeOptional: : = aTPresent<<GENERALIZETIME|aTAbsent ThresholdInfo = =

OBJECTI■ ObservedValue■ ThresholdLevelIndOptional ■ ArmTimeOptional ThresholdInfoOptional: : = thIPresent<<ThresholdInfo|thIAbset NotificationIdentifier==N

NotificationIdentifierOptional: : = nIPresent<<NotificationIdentifier|nIAbsent CorrelatedNotifications = = P((P NotificationIdentifier) ■ ObjectInstanceOptional)

CorrelatedNotificationsOptional: : = cNPresent<<CorrelatedNotifications|cNAbset AttributeValueChangeefinition = =P(OBJECTI ■ AttributeValuesOptional ■ AttributeValues) AttributeValueChangeefinitionOptional: : =

aVCPresent<<AttributeValueChangeefinition |aVCAbsent MonitoredAttributes==P OBJECTI

MonitoredAttributesOptional: : = mAPresent<<MonitoredAttributes mAAbset ProposedRepairActions==PSpecificIdentifier

ProposedRepairActionsOptional: : = pRAPresent<<ProposedRepairActions ^RAAbsent AdditionalTextOptional: : = adTPresent<<GRAPHICSTRING^dTAbsent ManagementExtension = = OBJECTI ■ Boolean ■ ANY AdditionalInformation==PManagementExtension

AdditionalInformationOptional: : = aIPresent<<AdditionalInformation ^IAbsent SourceIndicator: : = resourceOperation|managementOperation|sIUnknown

SourceIndicatorOptional: : = sIPresent<<SourceIndicator ^IAbsent AttributeIdentifierList = = P OBJECTI

AttributeIdentifierListOptional: : = atIPresent<<AttributeIdentifierList|atIAbsent Attribute = = OBJECTI ■ AttributeValues AttributeList = = PAttribute

AttributeListOptional: : = aLPresent<<AttributeList|aLAbsent

AlarmInfo

probableCause:ProbableCause

specificProblems:SpecificProblemsOptional

perceivedSeverity:PerceivedSeverity

backedUpStatus:BackedUpStatusOptional

backUpObject: ObjectInstanceOptional

trendIndication:TrendIndicationOptional

thresholdInfo:ThresholdInfoOptional

notificationIdentifier:NotificationIdentifierOptional

correlatedNotifications:CorrelatedNotificationsOptional

stateChangeefinition:AttributeValueChangeefinitionOptional

monitoredAttributes:MonitoredAttributesOptional

proposedRepairActions:ProposedRepairActionsOptional

additionalText:AdditionalTextOptional

additionalInformation:AdditionalInformationOptional

AttributeValueChangeInfo

sourceIndicator:SourceIndicatorOptional

attributeIdentifierList:AttributeIdentifierListOptional

attributeValueChangeefinition:AttributeValueChangeefinitionOptional

notificationIdentifier:NotificationIdentifierOptional

correlatedNotifications:CorrelatedNotificationsOptional

additionalText:AdditionalTextOptional

additionalInformation:AdditionalInformationOptional

ObjectInfo

sourceIndicator:SourceIndicatorOptional

attributeList:AttributeListOptional

notificationIdentifier:NotificationIdentifierOptional

correlatedNotifications:CorrelatedNotificationsOptional

additionalText:AdditionalTextOptional

additionalInformation:AdditionalInformationOptional

RelationshipChangeInfo sourceIndicator:SourceIndicatorOptional attributeIdentifierList:AttributeIdentifierListOptional relationshipChangeefinition:AttributeValueChangeefinitionOptional notificationIdentifier:NotificationIdentifierOptional correlatedNotifications:CorrelatedNotificationsOptional additionalText:AdditionalTextOptional additionalInformation:AdditionalInformationOptional

SecurityAlarmInfo

notificationIdentifier:NotificationIdentifierOptional

correlatedNotifications:CorrelatedNotificationsOptional

additionalText:AdditionalTextOptional

additionalInformation:AdditionalInformationOptional

StateChangeInfo

sourceIndicator:SourceIndicatorOptional

attributeIdentifierList:AttributeIdentifierListOptional

stateChangeefinition:AttributeValueChangeefinitionOptional

notificationIdentifier:NotificationIdentifierOptional

correlatedNotifications:CorrelatedNotificationsOptional

additionalText:AdditionalTextOptional

additionalInformation:AdditionalInformationOptional

EventInfo: : = attributeValueChange<<AttributeValueChangeInfo | communicationsAlarm<<AlarmInfo | environmentalAlarm<<AlarmInfo | equipmentAlarm<<AlarmInfo | integrityViolation<<SecurityAlarmInfo | objectCreation<<ObjectInfo | objecteletion<<ObjectInfo | operationalViolation<<SecurityAlarmInfo | physicalViolation<<SecurityAlarmInfo | processingError<<AlarmInfo | qualityOfServiceAlarm<<AlarmInfo | relationshipChange<<RelationshipChangeInfo | securityServiceOrMechanismViolation<<SecurityAlarmInfo | stateChange<<StateChangeInfo | timeomainViolation<<SecurityAlarmInfo

В.7.4 «CCITT Rec.X.721 (1992)» | ISO/IEC 10165-2:1992:Top

allomorphsOid: OBJECTI nameBindingOid: OBJECTI objectClassOid: OBJECTI packagesOid: OBJECTI

allomorphsValue : (FOBJECTI) ^ AttributeValues nameBindingValue : OBJECTI ^ AttributeValues objectClassValue : OBJECTI^ AttributeValues packagesValue : (FOBJECTI) ^ AttributeValues

disjoint <ranallomorphsValue, rannameBindingValue, ranobjectClassValue,ranpackagesValue

packagesPackageOid: OBJECTI allomorphsPackageOid: OBJECTI

TorState

allomorphs : F OBJECTI objectClass : OBJECTI nameBinding: OBJECTI packages : FOBJECTI attributes : FOBJECTI

{objectClassOid,nameBindingOid} сattributes allomorphsPackageOid e packages ^ allomorphsOid e attributes packagesPackageOid <£ packages packages ф 0 ^packagesOid e attributes

TopGetNameBinding

3 TopState result : OBJECTI

result = nameBinding

TopGetAll

3TopState

result : PAttributeValues

# attributes =# result|

ObjectClassValueobjectClass e result | NameBindingValuenameBinding e result |

PackagesOid e attributes ^ packagesValuepackages e result | AllomorphsOid e attributes ^ allomorphsValueallomorphs e result |

TopEventReport

3 TopState

notification : EventInfo

В.7.5 Класс StateManagement

administrativeStateOid: OBJECTI operationalStateOid: OBJECTI usageStateOid: OBJECTI

AdministrativeState: : = unlocked^ocked | shuttingown OperationalState: : = enabled | disabled UsageState: : = idle | active | busy

administrativeStateValue:AdministrativeState^ AttributeValues operationalStateValue: OperationalState^ AttributeValues usageStateValue: UsageState^AttributeValues

disjoint < ranallomorphsValue,rannameBindingValue, r a nobjectClassValue,ranpackagesValue, r a nadministrativeStateValue, r a noperationalStateValue,ranusageStateValue

StateManagementState

TopState

administrativeState:

AdministrativeState operationalState:OperationalState usageState: UsageState

operationalState= disabled ^ usageState= idle administrativeState= locked ^ usageState= idle usageState= idle^ administrativeStateФ shuttingown

SMGetNameBinding

TopGetNameBinding 3 StateManagementState

SMEventReport

TopEventReport 3 StateManagementState

SMGetAll

3 StateManagementState TopGetAll

administrativeStateOid e attributes

^ administrativeStateValueadministrativeState e result | OperationalStateOid e attributes

^ operationalStateValueoperationalState e result | UsageStateOid e attributes

^ usageStateValueusageState e result |

SMCapacityecrease

A,StateManagementState 3 TopState

usageState=active^ usageState’ e {active,busy} usageStateФactives usageState’ = usageState administrativeState’ = administrativeState operationalState’ = operationalState

SMCapacityIncrease AStateManagementState 3 TopState

usageState =busy^ usageState’ = active usageStateФbusy^ usageState’ = usageState administrativeState’ = administrativeState operationalState’ = operationalState

SMisable AStateManagementState 3 TopState

administrativeState’ =

/F administrativeState = shuttingown THENlocked ELSEadministrativeState operationalState’ = disabled usageState’ = idle

SMEnable

AStateManagementState 3 TopState

operationalState = disabled operationalState’ = enabled administrativeState’ = administrativeState usageState’ = usageState

SMNewUser AStateManagementState

3 TopState

operationalState = enabled administrativeState= unlocked usageStatee {idle,active} usageState’ e {active,busy} administrativeState’ = administrativeState operationalState’ = operationalState

SMUserQuit

AStateManagementState

3 TopState

administrativeState = shuttingown usageState’ = idle

^ administrativeState’ = locked

administrativeState ф shuttingown] usageState’ ф idle

^ administrativeState’ = administrativeState

usageState e {active,busy}

usageState’ e {idle,active}

operationalState’ = operationalState

SMReplaceAdministrativeState AStateManagementState

3 TopState

administrativeState’ e /FusageState ф idle

THEN{ unlocked ^ unlocked,locked ^ locked,

shuttingown ^ locked,locked^ shuttingown, shuttingown ^ shuttingown} ({input?})

ELSE { unlocked ^ unlocked,locked ^ locked, shuttingown ^ locked} ({input?}) administrativeState’ = locked ^ usageState’ =idle administrativeState’ ф locked ^ usageState’ =usageState operationalState’ =operationalState

УДК 6 8 1.324:006.3 54    ОКС    3    5.1    00.70    П85    ОКСТУ 4002

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

Редактор В. П. Огурцов Техническийредактор#. С. Гришанова Корректор#. И. Гаврищук Компьютерная верстка Т. Ф. Кузнецовой

Изд.лиц.№02354от14.07.2000.Сдановнабор25.09.2001.Подписановпечать16.11.2001.Усл.печ.л.7,90.Уч.-изд.л.8,00.

Тираж429экз.С2811.3ак.2300

ИПК Издательство стандартов, 107076, Москва, Колодезный пер., 14. http://www.standards.ru e-mail:info@standards.ru Набрано в Калужскойтипографии стандартов на ПЭВМ.

Калужскаятипография стандартов, 248021, Калуга, ул. Московская, 256.

ПЛР№ 040138

1

Оригиналыипроектымеждународныхстандартов—воВНИИКИГосстандартаРоссии.

2

ИСО/МЭКСТК1ПК21подтвердилпродолжениедействиястандартовАСН.1:1990посоображениям

соответствияипереносимости.ПК21потребовалотсвоихрабочихгрупппродолжатьподдерживатьэтистан-

дарты.СоответствующаярезолюцияПК21будетприниматьсянакаждомзаседанииПК21(внастоящеевремя

—ежегодно).

3

TupleявляетсяименемдляпродукцииАСH.1:1994,котораяпозволяетвставлятьуправляющиесим-волывнотациюзначенияIA5String,чегонельзясделатьвАСH.1:1990.Hапример,...greetingsIA5String: : = {«hello», or, «there»} вставляет возврат каретки между «hello» и «there» (егимпортированоизмодуля,опреде-ленноговИСО/МЭК8824-1,иэквивалентнолитералу«возвраткаретки»).