CC BY
34
научных статей "Интернет-порталы: содержание и технологии". Выпуск 2. / Редкол.: А.Н. Тихонов (пред.) и др.; ГНИИ ИТТ "Информика". - М.: Просвещение, 2004. - С. 192-226.
7. OWL2 Web Ontology Language Structural Specification and Functional-Style Syntax. http://www.w3.org/2007/OWL/wiki/Synta
УДК 004.652.5
ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ МОДЕЛЬ ПРЕДСТАВЛЕНИЯ ДАННЫХ О ЦИФРОВОЙ ТРАНСПОРТНОЙ СЕТИ СВЯЗИ
Саенко Игорь Борисович, д.т.н., проф., ведущий научный сотрудник, Санкт-Петербургский институт информатики и автоматизации Российской академии наук, Россия, Санкт-Петербург,
Невров Алексей Александрович, к.т.н., научный сотрудник, Санкт-Петербургский институт информатики и автоматизации Российской академии наук, Россия, Санкт-Петербург Салами Мохамад Юнес, инженер-исследователь, Сирийская Арабская республика
Создание объектно-ориентированной модели представления данных о цифровой транспортной сети связи (ЦТСС) имеет цель разрешить противоречие между данными мониторинга связи на технологическом уровне и представлением состояния ЦТСС и ее элементов на оперативно-техническом уровне. Противоречие обусловлено различием информационных моделей, подлежащих учету на указанных уровнях. Разрешение этого противоречия в рамках объектного подхода связывается с реализацией базы данных (БД) ЦТСС на объектно-ориентированной концепции [1].
Основными требованиями к модели являются обеспечение согласования технологической и оперативно-технической информационных моделей, полный охват сетевых устройств и протоколов управления и расширяемость. Эффективность модели оценивается по возможности отображения объектов сети любой сложности без потери информативности о состоянии их элементов.
Исходными данными для моделирования являются множества типов объектов учета и контролируемых параметров для каждого типа, а также множество видов взаимосвязей между объектами.
Объектно-ориентированная модель представления данных о ЦТСС включает структурную, динамическую и функциональную части (модели).
Построение структурной модели ЦТСС включало этапы [2]: определение классов; составление словаря данных; определение зависимостей между классами; уточнение атрибутов; построение иерархии классов; исследование и усовершенствование модели.
При определении классов был проведен анализ технической документации по ЦТСС и предъявляемых к ней требований. Из общего списка возможных классов были исключены ненужные: избыточные, нерелевантные, нечетко определенные и т.д. Оставшиеся классы образовали множество базовых классов, родительских для классов-потомков.
При подготовке словаря данных было обращено внимание на то, чтобы он содержал четкие и недвусмысленные определения всех объектов (классов), атрибутов, операций, ролей и других сущностей, рассматриваемых в проекте.
При определении зависимостей между классами осуществлялось исключение атрибутов-ссылок на другие классы и их замена зависимостями. Имена возможных зависимостей были получены из глаголов или глагольных оборотов, встречающихся в документации. По предложенным критериям были убраны из общего списка ненужные или неправильные зависимости.
Выявление зависимостей, существующих между классами объектов ЦТСС, показало, что основными видами таких зависимостей являются (рис. 1):
1. "целое - часть целого", означающая, что объект может быть компонентом и/или контейнером для одного и более других объектов;
78
2. "ресурс - потребитель", означающая, что объект может предоставлять ресурсы/услуги другим объектам и, соответственно, использовать ресурсы/услуги других объектов;
3. "взаимодействие" (ассоциативная связь), означающая, что объект может взаимодействовать с другими объектами своего уровня иерархии.
Целями этапа уточнения атрибутов являлось выявление состава атрибутов классов. Атрибуты выражают свойства объектов рассматриваемого класса либо определяют их текущее состояние. Наряду с атрибутами объектов вводились атрибуты зависимостей (связей) между классами. В результате были выявлены следующие группы атрибутов для каждого класса объектов:
1. описания, включающие идентификатор объекта, его краткое и полное наименование (например, для класса "Узел связи" в эту группу включаются атрибуты "Позывной" и "Условный номер узла связи");
2. целеполагания, включающие реквизиты, задающие параметры его функционирования (например, "Номер канального интервала", "Условный номер системы передачи", "Код режима работы канала");
3. функционирования, отражающие функционирование объекта (например, "Битовая ошибка", "Джиттер" и т.д.);
4. указания зависимостей, отражающие взаимосвязи различных видов с другими объектами ("Список потребителей", "Список ресурсов" и т.д.);
5. отображения, предназначенные для отображения объекта в графическом интерфейсе (цвета, пиктограммы и т.д.).
При построении иерархии классов необходимо найти суперклассы для введенных классов, что не всегда осуществимо на этапе предварительного проектирования. Иерархия классов формируется после нескольких итераций усовершенствования модели. Правильно сформированная иерархия помогает упорядочить классы, что затем, при построении объектной модели, значительно упрощает ее реализацию на языке программирования.
В сформированной иерархии классов объектов ЦТСС можно выделить следующие группы классов:
1. классы, описывающие типы физических объектов ("Синхронный мультиплексор", "Блок питания переменного тока"), создание и удаление экземпляров таких классов происходит на основании учетных сведений об оборудовании сети;
2. классы порождаемых объектов ("Канал связи"), создание и удаление экземпляров объектов этих классов происходит на основе данных технологического мониторинга;
79
3. агрегатные классы, описывающие абстрактные сущности, логически объединяющие объекты ЦТСС в единый объект с целью вычисления его интегральных показателей.
Конечный уровень иерархии составляют классы, учитывающие и описывающие особенности конкретных типов оборудования, каналов, подсетей (например, "Синхронный мультиплексор уровня STM-1 FlexGain A-155").
Дальнейшее исследование и усовершенствование модели необходимо для ее отладки. Некоторые ошибки могут быть найдены при исследовании модели без компьютера, другие -при ее интерпретации на компьютере.
Динамическая модель ЦТСС представляет собой описание состояний сети, внешних событий, ее реакции на внешние события и порядок взаимодействия с другими объектами. Для описания динамической модели ЦТСС предлагается применить абстрактный автомат Мили. Автомат инкапсулируется в объект. Его функциональное наполнение описывается в непубликуемой секции объекта. В публикуемой секции в качестве свойства описывается его состояние. Значение свойства определяет состояние объекта.
Автомат Мили задается в виде кортежаA = ’Е’0’5’^), где S- конечное множество состояний автомата; Е - множество входных событий (алфавит входа); 0 - множество выходных событий (алфавит выхода); 5:S х Е ^S - отображение множества S хE в множество S (функция переходов); E-S х E ^Y - отображение множества S х Е в множество 0 (функция выходов). На вход автомата поступают события ее Е от взаимосвязанных объектов. В зависимости от типа события е и текущего состояния Sj е S автомат меняет свое состояние и генерирует выходное событие 0 е 0. Информация о нем передается связанным объектам.
При реализации автоматов на практике требуется выделение и задание начального состояния, в котором автомат находится по умолчанию при его создании. Функции переходов и выходов могут задаваться в виде таблицы, строки которой соответствуют входным сигналам, а столбцы - состояниям. Выявлено следующее множество состояний объектов, общее для объектов всех классов: "норма"; "авария"; "предупреждение"; "не используется"; "заблокировано"; "плановое ТО"; "ремонт"; "резерв".
Согласно принципу полиморфизма, в классах-потомках возможно как расширение, так и сокращение множества состояний.
В функциональной модели среди множества методов объекта целесообразно выделить следующие методы как наиболее важные:
1. Create - метод создания (конструктор) объекта. Задача этого метода заключается в резервировании памяти, построении внутренней структуры объекта, инициализации параметров объектов;
2. LoadFromDB - метод загрузки свойств из базы данных. Этот метод выполняет функции соединения с БД, поиск в базе требуемого сохраненного экземпляра объекта, заполнение свойств и методов объекта;
3. Evaluation - метод оценивания состояния объекта ЦТСС. Этот метод выполняет периодический мониторинг и на его основании делает вывод о смене состояния объекта;
4. StateChange - метод смены состояния объекта. Этот метод реализует функционал конечного автомата, изменяет текущее состояние автомата в зависимости от событий, поступающих на вход автомата;
5. SaveToDB - метод сохранения свойств объекта в БД. Этот метод сохраняет в базе изменившиеся параметры объекта с сохранением временной отметки и причина изменения;
6. Destroy - метод уничтожения (деструктор) объекта. Этот метод закрывает все открытые и незавершенные соединения объекта, уничтожает все свойства, являющиеся объектами, освобождает память, занимаемую объектом, устанавливает указатель объекта в NULL.
Качественный анализ разработанной объектно-ориентированной модели ЦТСС показал, что она позволяет объединить информационные модели технологического и
80
оперативно-технического уровней, в ней полностью учтены имеющиеся типы оборудования, а также имеется возможность расширения модели за счет добавления новых классов, соответствующих вновь создаваемым устройствам.
Учет видов взаимосвязей объектов, реализованный в рамках объектного подхода, позволяет учесть оценку состояния с учетом вида связи и применять различные подходы к оцениванию взаимосвязанных объектов. Это позволяет получить агрегатную оценку состояния для сложных объектов, имеющих связи "целое - часть целого" с объектами-частями. Декомпозиция сложных объектов на части, возможная в рамках объектного подхода, позволяет в деталях оценить состояние всех составляющих объекта-целого. Таким образом, разработанная модель удовлетворяет всем предъявляемым к ней требованиям.
Модель позволяет отображать информацию об объекте с требуемой степенью детализации. Возможно отображение агрегированной информации. Возможность применения различных моделей, реализуемая согласно принципу полиморфизма, позволяет минимизировать ошибку определения состояния при получении агрегированной оценки. Это позволяет утверждать, что разработанная модель эффективна по критерию возможности отображения в ней объектов сети любой сложности без потери информативности о состоянии составляющих при агрегированной оценке объекта.
Реализация объектно-ориентированной модели ЦТСС была ориентирована на платформу реляционной БД. Такой подход связан с созданием программной надстройки, не зависящей от ядра СУБД, и требует разделения свойств и методов объектов, так как реляционные СУБД не позволяют в полной мере сохранить поведенческий аспект объекта (рис. 2).
Рис. 2. Объектно-ориентированная надстройка над реляционной моделью данных
Хранение методов класса осуществляется в программном модуле (библиотеке). Хранение свойств осуществляется в таблицах реляционной БД.
Известен ряд работ, посвященных отображению реляционной модели на объектную [3,4]. В нашем случае необходимо отображение классов объектов ЦТСС в сущности реляционной БД. Для этого предлагается оригинальный подход, основанный на принципе инкапсуляции и предполагающий включение в класс методов, обеспечивающих создание таблиц в реляционной БД, сохранение значений свойств экземпляров объектов в таблицах и считывание значений свойств из таблиц реляционной БД.
Создание таблиц для хранения значений свойств определенного класса основывается на принципе соответствия имени класса имени основной таблицы, в которой хранятся
81
данные для этого класса. При создании экземпляра объекта выполняется проверка условия существования таблицы с именем класса экземпляра. Если таблица не существует, генерируется сценарий создания таблицы. Сценарий содержит секции задания имени таблицы, определения атрибутов и ключей таблицы. Сценарий передается на выполнение ядру СУБД. При этом трансляция свойств в атрибуты происходит согласно специально разработанным правилам.
Метод сохранения значений свойств экземпляра в реляционной таблице включает последовательный перебор свойств, анализ их типов, преобразование типов и модификацию данных в реляционной таблице. В случае, когда сохранение происходит впервые и экземпляру объекта не сопоставлена строка в основной таблице класса, производится операция добавления данных в таблицу. Также добавление производится для ссылок, если для ссылочного объекта не найдена соответствующая строка в таблице объекта по ссылке.
Метод загрузки значений свойств экземпляра из реляционных таблиц осуществляет поиск соответствующей строки в таблице класса, последовательный перебор свойств класса и заполнение свойств основных типов значениями из соответствующих полей таблицы. Для векторных типов требуется выполнение запроса (ряда запросов) на выборку данных из соответствующих таблиц и заполнение элементов массива значениями из выборки согласно индексу (индексам) массива. Для ссылочных типов происходит создание экземпляра соответствующего класса и рекурсивное заполнение его свойств, осуществляемое методом загрузки значений.
Описанный подход позволяет реализовать объектно-ориентированную модель ЦТСС на основе реляционной СУБД. При таком подходе значения свойств объектов хранятся в реляционных таблицах, методы хранятся в библиотеках программной надстройки, взаимосвязи экземпляров описанной выше объектной модели реализуются механизмом ссылок.
Литература
1. Avi Silberschatz, Mike Stonebraker, Jeff Ullman, editors. Database Research, Achievements and Opportunities Into the 21st Century. Stanford University, Stanford, CA, USA, Technical Report: CS-TR-96-1563, Year of Publication: 1996.
2. Гайсарян С.С. Объектно-ориентированные технологии проектирования прикладных программных систем. Центр Информационных Технологий. http://www.citforum.ru/ programming/oop rsis.
3. Andreas Behm, Andreas Geppert, Klaus R. Dittrich. On the Migration of Relation Schemas and Data to Object-Oriented Systems. Proc. of the 5th International Conference on Re-Technologies in Information Systems, Klagenfurt, Austria, December 1997.
4. M. Malki, A. Flory, M. K. Rahmouni. Extraction of Object-oriented Schemas from Existing Relational Databases: a Form-driven Approach. Informatika, 2002, Vol. 13, No. 1, 47-72.
УДК 004.891
ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ АНАЛИЗ И ПРОЕКТИРОВАНИЕ СИСТЕМЫ ОЦЕНКИ И ФОРМИРОВАНИЯ КОМПЕТЕНТНОСТИ ТЕХНИЧЕСКОГО ПЕРСОНАЛА ПРОМЫШЛЕННОГО ПРЕДПРИЯТИЯ
Горькавый Михаил Александрович, аспирант, Кафедра «Электропривод и автоматизация промышленных установок» Комсомольского-на-Амуре государственного технического университета
Россия, Комсомольск-на-Амуре, [email protected] Соловьев Вячеслав Алексеевич, д.т.н., проф., Заведующий кафедрой «Электропривод и автоматизация промышленных установок» Комсомольского-на-Амуре государственного технического университета, Россия, Комсомольск-на-Амуре, [email protected]
82
