В ряде предыдущих работ [2, 3, 6] был исследован семантический гиперграф как формализм представления декларативных знаний, а также аргументирована необходимость представления процедурных знаний в интеллектуальных системах управления знаниями. В работе [5] был предложен событийный подход к представлению процедурных знаний и управлению онтологиями. В данной работе приводится пример реализации событийного подхода к управлению системой продукционных правил для формализации процедурных знаний моделируемой системы.
В качестве значений свойств события могут быть использованы ссылки на один или несколько классов или их экземпляров. В таком случае семантическая связь этого свойства будет инцидента каждой вершине (или одной из вершин), указанной в его (свойства) значении. Графически обозначать такую семантической дугу предлагается с помощью контура вокруг всех вершин, указанных в значении свойства, к которому направлена стрелка от вершины-события (свойство которого и рассматривается), причем в месте соприкосновения контура и стрелки изображать окружность с вписанным в нее символом конъюнкции (дизъюнкции). В качестве символьной записи предлагается использовать следующую конструкцию: {&: v1, v2, …, vk}, где v1, v2, …, vk – множество вершин, записанных в значении свойства. Такие семантические дуги предлагается называть событийно-конъюнктивными (событийно-дизъюнктивными), а множества – событийно-конъюнктивными (событийно-дизъюнктивными) списками.
Событийно-конъюнктивные и событийно-дизъюнктивные дуги, являясь средствами представления недоопределенной, неполной, неточной информации, повышают выразительные возможности ИСУЗ [7].
Рассмотрим пример, основывающийся на следующей последовательной фактической ситуации с каузально связанными событиями.
Клиент заказывает у провайдера услугу предоставления доступа к SIP-телефонии, но на его лицевом счету недостаточно средств для оплаты этой услуги, поэтому доступ к ней блокируется. После оплаты клиентом стоимости услуги блокировка снимается, и клиент совершает исходящий звонок.
Для описания формализации последовательной событийной ситуации будет использоваться модель декларативных знаний, полученная в [4].
При допущении, что локальная сеть клиента подключена только к одному провайдеру, ее аппаратное обеспечение поддерживает услугу SIP-телефонии, а биллинговая система провайдера предоставляет возможность только авансового метода расчета, обобщенный набор событий, возникающих в системе, представлен ниже.
1. Заказ клиентом у провайдера услуги SIP-телефонии:
Объект: экземпляр класса service:SIP, семантически связанный с экземпляром класса isp, который в свою очередь семантически связан с экземпляром класса client, ассоциированным с клиентом Ивановым.
Субъект: экземпляр класса client, ассоциированный с клиентом Ивановым.
Правила:
a) семантическое связывание объекта и субъекта семантической дугой has_service.
2. Изменение прав доступа для клиента на оборудовании провайдера:
Объект: экземпляр класса interface, ассоциированный с портом доступа на оборудовании провайдера, к которому подключен клиент Иванов.
Субъект: объект класса isp, ассоциированный с провайдером, услугами которого пользуется клиент Иванов.
Правила:
a) изменение свойства destination объекта на trunk;
b) добавление к значению свойства service объекта ссылки на экземпляр класса service:SIP (объект события 1).
3. Конфигурирование абонентского оборудования:
Объект: 2 экземпляра класса interface, ассоциированных с интерфейсами пограничного устройства локальной сети клиента Иванова, подключенных к порту доступа оборудования провайдера и к SIP-телефону клиента Иванова.
Субъект: экземпляр класса client, ассоциированный с клиентом Ивановым.
Правила:
a) изменение свойства destination объекта 1 (ассоциированного с интерфейсом пограничного устройства локальной сети клиента Иванова, подключенным к оборудованию провайдера) на trunk;
b) изменение свойства state объекта 2 (ассоциированного с интерфейсом пограничного устройства локальной сети клиента Иванова, подключенным к SIP-телефону) на active;
c) изменение свойства destination объекта 2 на clientSIP.
4. Списание провайдером оплаты за услугу с лицевого счета клиента:
Объект: свойство personal_account экземпляра класса client, ассоциированного с клиентом Ивановым.
Субъект: объект класса isp, ассоциированный с провайдером, услугами которого пользуется клиент Иванов.
Правила:
a) изменение объекта в соответствии со значением свойства cost экземпляра класса service:SIP, ассоциированного с услугой, заказанной клиентом Ивановым.
4. Блокирование доступа клиента к сети передачи данных:
Объект: экземпляр класса interface, ассоциированный с портом доступа на оборудовании провайдера, к которому подключен клиент Иванов.
Субъект: объект класса isp, ассоциированный с провайдером, услугами которого пользуется клиент Иванов.
Правила:
a) если значение свойства personal_account экземпляра класса client, ассоциированного с клиентом Ивановым, меньше 0, то изменение свойства state объекта на blocked.
6. Зачисление денег на лицевой счет клиента:
Объект: свойство personal_account экземпляра класса client, ассоциированного с клиентом Ивановым.
Субъект: экземпляр класса client, ассоциированный с клиентом Ивановым.
Правила:
a) изменение объекта в соответствии с текущим и целевым его значениями.
7. Предоставление доступа клиента к сети передачи данных:
Объект: экземпляр класса interface, ассоциированный с портом доступа на оборудовании провайдера, к которому подключен клиент Иванов.
Субъект: объект класса isp, ассоциированный с провайдером, услугами которого пользуется клиент Иванов.
Правила:
a) изменение свойства state объекта на active.
8. Исходящий SIP-звонок клиента:
Объект: экземпляр класса service:SIP, семантически связанный с экземпляром класса isp, который в свою очередь семантически связан с экземпляром класса client, ассоциированным с клиентом Ивановым.
Субъект: экземпляр класса client, ассоциированный с клиентом Ивановым.
Правила:
a) изменение свойства personal_account субъекта в соответствии со значением свойства cost_call объекта.
Для события 1 нет необходимости указывать в качестве одного из дополнительных параметров провайдера, у которого заказывается услуга, т.к. заранее было оговорено, что клиент пользуется услугами только одного провайдера, в противном случае необходимо было бы предусмотреть процедуру определения провайдера, услугу у которого заказал клиент.
Для события 3 объектом являются 2 вершины-экземпляра класса interface. Формально объект события 3 представляется как семантически-конъюнктивный список.
Формально создание событий в терминах семантических гиперграфов выглядит следующим образом. Сначала необходимо создать сам класс event, экземпляры которого и будут являться событиями, описанными выше.
Ниже приведена формальная запись создания экземпляра класса event для первого события рассматриваемой ситуации. В качестве значения свойства evType используется название ситуации, в которую входит событие (в случае если событие входит в несколько ситуаций, значением данного свойства будет являться событийно-конъюнктивный список, элементами которого будут являться названия каждой из ситуаций).
По аналогии с вышеприведенным вариантом создаются остальные события.
После создания всех экземпляров класса event для задания порядка возникновения событий в модели необходимо произвести каузальное связывание созданных экземпляров.
Первое событие является начальным в рассматриваемой ситуации, причиной его возникновения могут являться события других ситуаций. Поскольку в данной работе они не рассматриваются, будем использовать это событие как стартовое. Для возникновения второго и третьего событий необходимо возникновение первого. Для возникновения четвертого события необходимо возникновение второго события. Для возникновения пятого события необходимо отрицательное значение объекта четвертого события. Представление такой связи невозможно с помощью каузальных дуг (реализовать это можно в ядре правил продукций или с помощью алгоритмических решений при проектировании ИСУЗ), поэтому будем считать, что для возникновения пятого события необходимо возникновение четвертого, а обработку логического условия возложим на правило продукции, связанное с пятым событием. Для возникновения шестого события необходимо возникновение пятого. По аналогии с причиной возникновения пятого события для возникновения седьмого необходимо возникновение шестого события. Для возникновения восьмого события необходимо возникновение второго, третьего и седьмого событий. Формально это записывается следующим образом:
Ниже формально записан спектр продукций с правилами модификации исходной модели. В качестве сферы применения продукций выступает название события, при возникновении которого данная продукция будет отнесена к фронту готовых продукций. В качестве антецедент продукций используются условия существования обрабатываемых продукцией вершин. Кроме того, в продукциях использованы названия переменных objecti и subjecti с индексами, которые обозначают объект и субъект i-го события соответственно.
В качестве условий применимости продукций использовано расширение активаторов логико-трансформационных правил [1] – ON_FINISHED(), предоставляющее возможность запуска продукционного правила по завершении события или продукции, указанных в скобках этого активатора.
В составе антецедент ядер продукций используется операция exist(), принимающая истинное значение в случае, если вершина, указанная в скобках, существует в модели, и ложное в противном случае.
(i1)
(i2)
(i3)
(i4)
(i5)
(i6)
(i7)
(i8)
(i9)
(i10)
(i11)
Вывод
В данной работе приведен пример проектирования последовательной фактической системы, описанной онтологией сети провайдера, знания в которой представлены с помощью объектно-ориентированного семантического гиперграфа. Практически доказана относительная несложность применения правил продукционного вывода для управления динамикой семантики модели системы.
Рецензенты:
Егоров С.И., д.т.н., доцент, профессор кафедры вычислительной техники, ФГБОУ «Юго-Западный государственный университет», г. Курск;
Ромм Я.Е., д.т.н., профессор, заведующий кафедрой информатики, ФГБОУ ВПО «ТГПИ имени А.П. Чехова», г. Таганрог.
Работа поступила в редакцию 19.07.2013.