---

Керування, необхідне для реєстрації інформації, може змінюватися з часом. Крім того, у разі читання такої інформації з журналу реєстрації, менеджер повинен мати змогу визначати, чи записи були загублені, чи змінені.

Отже, можна сформулювати такі вимоги:

1. визначання гнучкої служби контролю журналу реєстрації, що дає змогу вибирати записи, за­реєстровані системою керування у приватному журналі реєстрацій;

2. можливість для зовнішніх систем змінювати критерій, використовуваний щодо реєстрації записів;

3. можливість для зовнішніх систем визначати, чи зареєстровані записи були змінені, чи ха­рактеристики запису реєстрацій були загублені;

4. специфікації механізму контролю часу реєстрації, наприклад, за допомогою припиняння і поновлювання реєстрації;

5. можливість для зовнішніх систем одержувати і видаляти записи реєстрації;

6. можливість для зовнішніх систем створювати і знищувати журнали реєстрацій.

С.2 Інформаційний погляд

Необхідна інформація про:

• зареєстровану інформацію (журнал реєстрацій і реєстраційні записи);

• керівні об’єкти, які моделюють джерело зареєстрованих подій.

На рисунку С.1 показано один з інформаційних поглядів на журнал реєстрацій.

Специфікація з використовуванням формальних нотацій також є частиною інформаційного по­гляду, але у прикладі не досліджується.

Рисунок С.1 — Приклад погляду на контроль реєстрації з використовуванням ОМТ-нотацїіС.З Обчислювальний погляд

З обчислювального погляду візуалізується інтерфейс операцій між обчислювальними об’єктами керування. У випадку контролю реєстрацій необхідні наступні обчислювальні об’єкти керування: журнал реєстрацій, запис реєстрації, об’єкт, що породжує сповіщення, та два об'єкти-менеджери. Доступні GDMO-специфікації (без обліку пакетів вимог) відносяться до інтерфейсу, ідентифікованого з обчис­лювального погляду.

Нижче наведено вихідний GDMO-шаблон класу керованого об’єкта log, взятий з ССІТТ Rec.X.721: log MANAGED OBJECT CLASS DERIVED FROM top;

CHARACTERIZED BY

— див.: ССІТТ Rec. X. 7351ISO/IEC 10164-6 для опису класів керованих об’єктів.

log Package PACKAGE BEHAVIOUR logBehaviour BEHAVIOUR

DEFINED AS "This managed object is used to store incoming event reports and local system notifications. Additional details are defined in ССІТТ Rec. X. 7351ISO/IEC 10164-6.

ATTRIBUTES logld GET, discriminatorConstruct GET-REPLACE,

administrativeState GET-REPLACE,

operationalState GET,

availabilityStatus PERMITTED VALUES Attribute-ASN1 Module.LogAvailability REQUIRED VALUES Attribute-ASN1 Module.UnscheduledLogAvailability GET, logFullAction GET-REPLACE;

NOTIFICATIONS

objectcreation, objectDeletion, attributeValueChange, statechange, processingErrorAlarm;;; REGISTERED AS {smi2MObjectClass 6};

На рисунку C.2 об'єкт Менеджері приймає сповіщення через серверний інтерфейс сповіщень nsl. Крім того, створюється об’єкт Запис реєстрації, який може прочитати об’єкт Менеджері з вико­ристанням клієнтського інтерфейсу керування операцій осі.

На рисунку С.З інший об’єкт Менеджер2 може читати об’єкт Журнал реєстрації, використовую­чи інтерфейс ос2, і об'єкт Запис реєстрації за допомогою осЗ.

Рисунок С.2 — Приклад обчислювального погляду на контроль реєстрації (звичайні операції)

Рисунок С.З — Приклад обчислювального погляду на контроль реєстрації (керування журналом реєстрації)

С.4 Інжиніринговий погляд

Для керування OSI-системами інжиніринговий погляд описує функціональність, необхідну для забезпечення комунікації між об’єктами в керівній ролі та об’єктами в ролі ресурсів з використан­ням CMISE і, наприклад, обробки транзакцій. На рисунку С.4 наведено приклад інжинірингового кон­тролю реєстрацій.

У прикладі журнал реєстрацій і об’єкт, який генерує події, існують на одному комунікаційному вузлі. Розташування сервера сповіщень не зрозуміле з рисунка, він може існувати як на тому само­му вузлі, так і на іншому. В останньому випадку йому потрібні власні комунікаційні канали.

Рисунок С.4 — Приклад інжинірингового погляду керування журналом реєстрацій

С.5 Залежності між поглядами

Примітка. У випадках узагальнення немає потреби однозначного відображення об’єктів з різних поглядів.

На рисунку С.5 використано познаки: ео — інжиніринговий об’єкт, eso — інжиніринговий об’єкт підтримування.

Рисунок С.5 — Залежності між поглядами

ДОДАТОК D

(довідковий)

ПРИКЛАД МОНІТОРИНГУ МЕТРИКИ

Мета цього прикладу — проілюструвати, спосіб подання клієнтського інтерфейсу операції ке­рування, та фактично повністю специфікувати його, використовуючи GDMO і GRM.

Примітка 1. Метод, наведений у цьому прикладі, не єдиний, який можна використовувати в ODMA.

Примітка 2. Серверний інтерфейс сповіщень можна розібрати аналогічно, однак він не долучений до прикладу.

Приклад базується на структурі простого керованого об’єкта monitorMetric, який визначено в ITU-T Rec. Х.739 IISO/IEC 10164-11. Формальну GRM-нотацію (ITU-T Rec. Х.725 | ISO/IEC 10165-7) використовують лише для специфікації відношень між серверним інтерфейсом операцій керування одного обчислювального об’єкта керування та серверним інтерфейсом операцій керування іншого обчислювального об’єкта керування (рисунок D.1).

Доволі просто подати клієнтський інтерфейс операцій керування як дзеркальне відображення серверного інтерфейсу цих операцій, який визначений з використанням GDMO і відповідає обме­женням, що накладаються специфікованим відношенням (рисунок D.2).

Досліджуваний об’єкт використовують винятково з метою ідентифікації клієнтського інтерфей­су операцій керування об’єкта моніторингу метрики.

Рисунок D.1 — Специфікація відношень

І / ОбчислювальХ І • j Обчислюваль-

і [ ний об'єкт І і і ний об’єкт, )

Серверний моніторингу у КЛІЄНТСЬКИЙ Серверний ' що спосте- І
Інтерфейс метрики J інтерфейс інтерфейс рігається

операцій операцій операцій

І відношення А А

Рисунок D.2 — Специфікація інтерфейсу керування

D.1 Визначення об’єктів метрики

Необхідні такі визначення:

• Клас відношень meanMonitorMetric подає обчислювальний об’єкт meanMonitorMetric, обчис­лювальний інтерфейс цього об’єкта інтерпретується як специфічні ролі, описані класом керованого об’єкта.

• Клас керованого об’єкта meanMonitorControl описує характеристики екземплярів керованих об’єктів, які можна використовувати для контролю meanMonitorMetric.

• Клас керованого об’єкта scanObservedObjectValue описує характеристики екземплярів керо­ваних об’єктів, за якими можна спостерігати, використовуючи meanMonitorMetric.

Клас керованого об’єкта qualityOfServiceAlarm описує характеристики екземплярів керованих об’єктів, які можуть генерувати сповіщення meanMonitorMetric.На рисунку D.3 це зображено графічно. Тут клієнт служби сповіщень — quality of service alarm client; сервер засобів контролю моніторингу — mean monitor control server, клієнт екземпляра об’єкта, який спостерігається — observed object instance client.

scanObservedObjectValue

observed object instance client

Рисунок D.3 — Обчислювальний об’єкт засобу моніторингу метрики

D.2 Визначення класу відношень

meanMonitorMetric RELATIONSHIP CLASS

BEHAVIOUR meanMonitorMetricBhv BEHAVIOUR DEFINED AS

«Обчислювальний об’єкт meanMonitorMetric ініціює операцію get екземпляра обчислювально­го об’єкта в ролі observedObjectlnstanceClient, для одержування значення активного атрибута, який спостерігають; якщо операція сканування не приводить до одержування значення об’єкта, який спо­стерігається, до початку наступного періоду деталізації, то таке сканування недійсне і його не вико­ристовують для метричного алгоритму процесу відновлювання»;;

ROLE meanMonitorControlServer COMPATIBLE WITH meanMonitorControl;

ROLE observedObjectlnstanceClient COMPATIBLE WITH scanObservedObjectValue;

ROLE quaiityOfServiceAlarmClient COMPATIBLE WITH qualityOfServiceAlarm;

REGISTERED AS {};

D.3 Визначення класів керованих об’єктів

meanMonitorControl MANAGED OBJECT CLASS

DERIVED FROM "CCITT Rec. X.721 | ISO/IEC 10165-2”:top;

CHARACTERIZED BY meanMonitorControlPkg PACKAGE

BEHAVIOUR meanMonitorControIBhv BEHAVIOUR DEFINED AS

«операції контролю повинні впливати на параметризовану поведінку метричного алгоритму ска­нування, виконуваного за установкою атрибутів»;

ATTRIBUTES

observedObjectlnstance GET-REPLACE,

observedAttributeld GET-REPLACE,

granularityPeriod GET-REPLACE.

movingTimePeriod GET-REPLACE,

derivedGauge GET-REPLACE

notificationTriggerThreshold GET-REPLACE,

re-armThreshold GET-REPLACE,

operationalState GET-REPLACE;;

REGISTERED AS {};

scanObservedObjectValue MANAGED OBJECT CLASS

DERIVED FROM "CCITT Rec. X.721 | ISO/IEC 10165-2":top;

CHARACTERIZED BY scanObservedObjectValuePkg PACKAGE

BEHAVIOUR scanObservedObjectValueBhv BEHAVIOUR DEFINED AS

«Сумісні класи конкретного класу керованого об’єкта повинні мати як мінімум один атрибут із синтаксисом величини типу integer чи real.»;;

REGISTERED AS {};

Примітка. Необхідно використовувати механізм емуляції, оскільки об’єкт метрики працює на довільних класах керованих об’єктів.

qualityOfServiceAlarm MANAGED OBJECT CLASS

DERIVED FROM "CCITT Rec. X.721 | ISO/IEC 10165-2":top;

CHARACTERIZED BY qualityOfServiceAlarmPkg PACKAGE

BEHAVIOUR qualityOfServiceAlarmBhv BEHAVIOUR DEFINED AS

«Сумісні класи конкретного класу керованих об'єктів матимуть потребу в qualityOfService AlarmNotification у випадку позитивного кросингу події для тригера сповіщень»;

NOTIFICATION

"ISO/IEC 10164-4":qua!ityOfServiceAlarmNotification;;;

REGISTERED AS {};

D.4 Приклад обчислювальних об’єктів метрики

На рисунку D.4 наведено приклад використання об’єкта метрики. Визначені:

• обчислювальний об’єкт observedObjectExample, поданий як клас відношень;

• відображення відношень metricObjectExample;

• клас керованого об’єкта fullMeanMonitorControl;

• клас керованого об’єкта observedObjectlnterfaceExample.

На рисунку D.4 використані позначення:

• засіб повного контролю моніторингу — full Mean Monitor Control;

• клієнт служби сповіщень — quality of Service Alarm Client;

• сервер засобів контролю моніторингу — mean Monitor Control Server;

• клієнт екземпляра спостеріганого об’єкта — observed Object Instance Client.

quality of observed observed

Service Object Object

Alarm Instance Instance

C lient Server —.

observed /observed

I Object J I Object I Interface 1 vExample

Example

Control Server

Рисунок D.4 — Приклад обчислювального об'єкта метрики

D.5 Приклад класу відношень observedObjectExample RELATIONSHIP CLASS BEHAVIOUR observedObjectExampleBhv;

ROLE observedObjectinstanceServer COMPATIBLE WITH observedObjectlnterfaceExample; REGISTERED AS {};

D.6 Приклад відображення відношень metricObjectExample RELATIONSHIP MAPPING RELATIONSHIP CLASS meanMonitorMetric;

RELATIONSHIP OBJECT fullMeanMonitorControl;

ROLE meanMonitoi-ControlServer RELATED CLASSES fullMeanMonitorControl;

ROLE observedObjectlnstanceClient RELATED CLASSES observedObjectlnterfaceExample REPRESENTED BY RELATIONSHIP-OBJECT-USING-POINTER observedObjectlnstance;

ROLE qualityOfServiceAlarmClient RELATED CLASSES fullMeanMonitorControl; REGISTERED AS {} ;

D.7 Приклад класів керованих об’єктів fullMeanMonitorControl MANAGED OBJECT CLASS DERIVED FROM meanMonitorControl, qualityOfServiceAlarm; REGISTERED AS {};

observedObjectlnterfaceExample MANAGED OBJECT CLASS

DERIVED FROM "CCITT Rec. X.721 | ISO/IEC 10165-2":top;

CHARACTERIZED BY observedObjectlnterfaceExamplePkg PACKAGE

BEHAVIOUR observedObjectlnterfaceExampleBhv;

ATTRIBUTES

observedValue GET-REPLACE;;

REGISTERED AS {};

ДОДАТОК E

(обов’язковий)

ПРИКЛАДИ ОБЧИСЛЮВАЛЬНИХ ШАБЛОНІВ

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

Примітка. Метод, наведений у додатку, не є єдиним методом, який можна використовувати в ODMA.

У описі операції з обчислювального погляду посилаються на схему інформаційного погляду, щоб визначити передумови, які система³^ повинна перевіряти для можливості виконання конкретної опе­рації, та постумови, які система повинна перевіряти після виконання операції. Клас відношень GRM специфікує ряд систем із забезпеченням:

• об’єктів, включених в усі екземпляри класу системи (через використання директиви <гоіе>),

• допустимих обмежень їхніх станів (через використання директиви <invariant>),

• відношень, включених до класу системи (через використання директиви <invariant>),

• допустимих обмежень на комбіновані стани, описані у відношеннях (через використання ди­рективи <invariant>).

За параметром операції буде вибрано екземпляр системи, який буде адресовано операцією в передумові і який буде подано як результат операції в постумові. Отже, поведінка повинна охоп­лювати:

• директиву передумови, яка посилається на клас системи специфікації інформаційного по­гляду.

• директиву постумови, яка посилається на клас системи специфікації інформаційного погляду.

• правила узгоджування параметрів для надання інформації про вибір.

У цьому прикладі наведено обчислювальний інтерфейс та одну з його операцій, яка забезпе­чує перехід від ssccNotConnected до ssccConnected серед простих підмережних з’єднань (тобто встановлює підмережне з’єднання між заданими а-кінцевою і z-кінцевою точками).

Посилання на мітки. У цьому додатку показано посилання на інформаційну статичну схему і ASN.1 процедури: