CC BY
54
эффективности применения протоколов на основе RAP показан в работах [5, 6], где подчеркивалось, что открытым остается вопрос о скорости реакции протокола на изменения в утилизации сети и вопрос обеспечения стабильной регулировки скорости передачи при скачкообразных изменениях загрузки сети. Кроме того, нигде не исследовались возможности использования этих протоколов в компьютерных сетях с топологией «узкое горло». В то же время такая топология является наиболее типичной для большинства сетей.
В настоящей работе вскрыты недостатки метода RAP, предложен модифицированный по сравнению с [5] метод (RRAP), позволяющий улучшить характеристики качества реализации известного метода RAP [4]. Как показывают результаты имитационного моделирования, применение метода RRAP для протокола RAP позволило значительно снизить длительность переходного процесса T*, не ухудшая основных свойств исходного протокола.
Направление дальнейших исследований. Результаты, полученные в данной работе, касались лишь одного из аспектов улучшения работы протокола управления качеством передачи потока данных. В дальнейшем предполагается также исследовать вопросы совместимости протокола RRAP с различными технологиями управления очередями пакетов на узлах сети.
Литература: 1. Jehan-Francois Paris et al. A hybrid broadcasting protocol for video on demand // Multimedia Computing and Networking Conference. Р. 317-26, San Jose, CA, USA, January, 1999. 2. Shulzrinne H. et al. RTP: a transport protocol for real-time applications // RFC 1889, Internet Engineering Task Force, Jan, 1996. 3. Sally Floyd et al. Equation-Based Congestion Control for Unicast Applications // ACM SIGCOMM 2000, Stockholm, Aug,
2000. 4. Rejaie R. et al. RAP: An End-to-end Rate-based Congestion Control Mechanism for Realtime Streams in the Internet // IEEE Infocom’99, New York, March, 1999. 5. Rejaie
R. et al. Quality Adaptation for Congestion Controlled Video Playback over the Internet // IEEE Journal on Selected Areas of Communications (JSAC), Special issue on Internet QoS, Winter, 2000. 6.MohitTalwar. A Simulation Based Evaluation of RAP // T echnical Report, University of Southern California, Dec., 1998. http://netweb.usc.edu/reza/RAP/NewRAP/ report.ps. 7. Jacobson V. et al. Congestion Avoidance and Control // Computer Communication Review, Aug. 1988. Vol. 18, № 4. Р. 314-329. 8. Bajaj S. et al. Improving Simulation for Network Research. // Technical Report 99-702, University of Southern California, March, 1999. 9. Wang Z., Paganini F. Global Stability with Time Delay in Network Congestion Control // Proc. IEEE CDC. 2002. 10. Wang J, Wei D., Low
S. Modelling and Stability of FAST TCP // Proc. IEEE Infocom March, 2005. 11. Paganini F. et al. Congestion control for high performance, stability and fairness in general networks // IEEE/ACM Transactions on Networking, 13(1), February, 2005. 12. Треногин Н.Г., Соколов Д.Е. Фрактальные свойства сетевого трафика в клиент-серверной информационной системе // Вестник НИИ СУВПТ. Сборник научных трудов. Вып. 14. Красноярск. 2003. С. 163-172.
Поступила в редколлегию 20.10.2005 Рецензент: д-р техн. наук, проф. Кучеренко Е. И.
Саенко Владимир Иванович, канд. техн. наук, доц., проф. каф. информационных управляющих систем ХНУРЭ. Научные интересы: менеджмент компьютерных сетей. Увлечения и хобби: садоводство. Адрес: Украина, 61166, Харьков, пр. Ленина, 14.
Снурников Олег Михайлович, аспирант каф. информационных управляющих систем ХНУРЭ. Научные интересы: методы и технологии управления потоками в компьютерных сетях. Увлечения и хобби: домашний ремонт. Адрес: Украина, 61166, Харьков, пр. Ленина, 14.
УДК004.891
РЕАЛИЗАЦИЯ РЕШАТЕЛЯ И БАЗЫ ЗНАНИЙ ЭКСПЕРТНОЙ СИСТЕМЫ ДЛЯ ПЛАНИРОВАНИЯ ДЕЙСТВИЙ ПОЛЬЗОВАТЕЛЯ ПРИ РАЗРАБОТКЕ ПРОГРАММ
ПРИГОЖЕВ А.С.__________________________
Рассматриваются вопросы, связанные с реализацией подсистемы помощи для планирования действий пользователя при работе с вычислительной системой. Рассматриваются возможные режимы работы подсистемы, структура для различных режимов и особенности реализации. Такой подход позволяет снизить требование к уровню подготовки пользователей и ускорить процесс освоения способов работы с вычислительной системой.
1. Введение
Важной составной частью современных программных систем является подсистема помощи пользователю, позволяющая существенно упростить освоение сис-
1 1 0
темы. Подсистема помощи, как правило, включает набор справочников по возможностям программной системы в виде гипертекста, контекстно-зависимую помощь, поиск по ключевым словам.
Реализация системы помощи на базе набора справочников позволяет пользователю изучить основные концепции и команды в системе. Примерами такой реализации являются файлы помощи операционной системы Windows, man-файлы операционной системы Linux и т.д.
Контекстно-зависимая помощь даёт возможность получать контекстную информацию о функциях программной системы, основываясь на текущем отображаемом окне и/или введённых командах и данных.
Главным недостатком указанных выше подсистем помощи является слабое развитие или отсутствие средств, позволяющих помочь пользователю в решении определённой задачи. Чаще всего метод решения той или иной задачи описан в справочной системе. Однако это не даёт возможности проконтролировать действия пользователя при решении задач. Кроме того, справочная система, которая опи-
ВЕ, 2005, 1 4
сывает абсолютно все возможности программной системы, может быть достаточно большой и, как следствие, поиск в такого рода системе может быть существенно затруднён.
Одним из направлений развития и усовершенствования подсистем помощи является создание механизма демонстрации возможностей приложения без привлечения пользователя (так называемые Program Tutorials - демонстрационные программы). Основным недо-статко м таких систем является то, что непо дготовлен-ному пользователю достаточно сложно уследить за процессом демонстрации. Обычно в этом случае можно узнать, как решить задачу на конкретном примере, но трудно уяснить общие принципы и идеологию программной системы.
Для дальнейшего развития подсистем помощи предлагается решить задачу с планирующей экспертной системой. Такая подсистема помощи позволяла бы пользователю просматривать, какие задачи может решать система с разбиением на подзадачи, заранее планировать свои действия при работе с системой, а также имела бы возможность контроля действий и автоматизированного выполнения плана, составленного пользователем. Разработка такой подсистемы является целью этого исследования. Для решения поставленной задачи необходимо разработать формальную модель человеко-машинного взаимодействия, а также структуру и алгоритмы функционирования системы.
2. Принципы построения подсистемы помощи
При решении задач с использованием вычислительной системы пользователь взаимодействует с ней посредством пользовательского интерфейса. Любую решаемую в рамках вычислительной системы задачу можно разбить на подзадачи.
Формальная модель взаимодействия пользователя и вычислительной системы:
H = {T,N,C,A}, (1)
где T - множество задач, решаемых в вычислительной системе; N - множество имён задач, причём
(р : T ^ N - взаимно-однозначное отображение, которое ставит в соответствие каждой задаче её имя (имена задач будут использованы в дальнейшем при формулировке контекстных условий); С - множество команд вычислительной системы; A - множество сценариев.
Сценарий а є A, a = (t,S, <px, (p2, ^3), где t є T -задача, для решения которой создаётся сценарий, S ^ T - подмножество задач, которые могут понадобиться для решения задачи t (обязательные и необязательные). Задачи, которые входят во множество S , назовём подцелями для сценария a :
(р1 : S ^ Л - отображение из множества S во множество Л . Каждому элементу из S (подцели) ставится в соответствие контекстное условие;
(p2:S ^ {TRUE, FALSE} - отображение, определяющее, являются ли обязательными подцели для выполнения сценария (для решения задачи t );
(р3 : S ^ {TRUE,FALSE} - отображение, определяющие, сколько раз может выполниться подцель для сценария (TRUE - не более одного раза, FALSE -несколько раз);
Предложенная модель, как несложно видеть, задаёт иерархию на множестве задач: для решения одной задачи может понадобиться некоторое множество задач, для решения каждой из них, в свою очередь, также требуется решить некоторое множество задач. Для того чтобы формально определить эту иерархию, рассмотрим отношение инцидентности т (бинарное отношение на множестве T ).
Положим по определению, что (t1,t2) Є т , (t1,t2 є T ), если существует а є A, такое, что а = (ti,S,^i,^2,^3) и t2 Є S.
Таким образом, задан ориентированный граф, у которого вершины - элементы множества T (задачи), а рёбра заданы отношением инцидентности г - определяют вхождение задачи в сценарий, определённый другой задачей.
Потребуем, чтобы в графе не было ориентированных циклов, т.е. в графе не будет фрагментов, когда подцели разных сценариев указывают на один и тот же сценарий нижнего уровня.
Определим далее иерархию сценариев D для модели взаимодействия H .
D - это дерево, вершины которого взвешены сценариями, т. е. каждой вершине поставлен в соответствие некоторый сценарий а є A, удовлетворяющий условию: если вершина v1 является родительской для вершины v2, и сценарий, соответствующий v1 а1 = (t11,S11,^»11,^21,^31), а сценарий, соответствующий v2 - а2 = (t2,S2,^12,^22,^32), то задачи t1 и t2 должны находиться в отношении инцидентности т .
Каждое дерево D из множества сценариев A представляет собой иерархию сценариев, и корневая вершина этого дерева - это целевая задача, которая может быть решена с использованием этого дерева сценариев. Модель взаимодействия пользователя с вычислительной системой может включать несколько деревьев сценариев, каждый соответствующий своей целевой задаче верхнего уровня.
Введём язык л для описания контекстных условий. Алфавит L включает:
- логические операции AND, OR и NOT;
- имена функций IFEXECSUBP и COUNT;
- имена задач из множества N;
- служебные символы «(», «)», «True», «False», “,”;
BE, 2005, 1 4
1 1 1
Рассмотрим множество L* всех слов из алфавита L. Выделим из этого множества те слова, которые мы будем считать правильными и которые будут задавать контекстные условия. Назовём множество этих слов Л ^ L* и определим его по индукции:
1) TRUE, FALSE є Л.
2) IFEXECSUBP(n) є Л , где n є N; COUNT(n1,n2) є A, где n1,n2 є N.
3) Если u,vє Л , то u AND vє Л ; u OR vеЛ ; NOT uеЛ ; (u)еЛ .
Теперь зададим семантику языка Л, т.е. наделим слова из Л определённым смыслом.
Предположим, что задан сценарий a = (t1,S,^1,^2,^3) для решения задачи t1. Необходимо определить, какие последовательности действий (подцелей) из S приводят к решению задачи t1. Такую последовательность действий назовём планом решения задачи t1.
Рассмотрим последовательность (s1,s2,...,sn ) ^ S*. Она является планом, если выполняются три условия:
1) Vs є S такого, что ср (s) = TRUE Зі, что si = s.
Каждое s, которое является обязательным, должно входить в нашу последовательность (план).
2) Vs є S такого, что ^ (s) = TRUE, card{i | si = s} < 1.
Каждое s, которое может быть использовано не более одного раза, должно входить в нашу последовательность (план) не более одного раза.
3) Для того чтобы сформулировать третье условие, нам понадобится ввести отображение, которое будет характеризовать истинность контекстныхусловий для подцелей из нашей последовательности.
Зададим отображение
(р~х - это отображение имён подцелей в подцели. Последнее значит: TRUE, если задача с именем k встречается в нашей последовательности перед i:
p(i,COUNT(ni,n2)) =
TRUE,если card{k:k < і, ф-1(п) = Sk} =
=card{k:k <і,ф 1(m) = Sk} FALSE, иначе.
,i = 1,l;
TRUE, если количество выполнений подцели с номером n1 равно количеству выполнений подцели с номером n2 .
Пусть u,v є Л . Тогда
p(i,u AND v) =
[TRUE,если p(i,u) = TRUE и p(i,v) = TRUE — 1 ;i = 1,1;
I FALSE,иначе.
ц(іц ORv)=
[TRUE,если p(i,u)=TRUE или ^i,v)=TRUE —
1 ;i=1,1
[FALSEцначе.
P(i,(u)) = P(i,u)
^(i,NOTu)
TRUE,если ц(і, u) = FALSE —
;i = 1,1;
FALSE,иначе.
Сформулируем условие 3:
Vi = Ц ц(і,^(0) = TRUE.
В нашей последовательности S* (план) для каждой подцели si выполнено контекстное условие £1 (si) .
ц :{1,2,3....,1}x Л ^ {TRUE,FALSE},
ц - это отображение, которое зависит от двух переменных (от номера подзадачи в последовательности и от контекстного условия). Значение ц(і, X) равно TRUE, если контекстное условие X выполнено для подцели с номером i в нашей последовательности. В противном случае ц(і, X) = FALSE.
Формально отображения ц можно определить по индукции следующим образом:
ц(і, TRUE) = TRUE, і = ЇД ,
^i,FALSE) = FALSE,i = 1Д ,
ц(і, IFEXECSUBP(n)) =
TRUE, если 3k < і, что Sk =ф_1(п) . _ —
,i = U1,
FALSE, иначе.
3. Проектирование подсистемы помощи
Подсистему предлагается реализовать на базе планирующей экспертной системы с использованием сценариев, описанных в п. 2. Общая структура данной системы представлена на рис. 1: БЗ - база знаний, ЛБД - локальная база данных, ЭС - экспертная система. Подсистема помощи на основе планирующей экспертной системы состоит из следующих компонентов: загрузчика базы знаний, базы знаний в памяти, решателя, локальной базы данных и информационного окна ввода-вывода. База знаний для данной системы реализуется на основе сценариев [1]. На диске база знаний представлена в виде четырёх реляционных таблиц: «Сценарии», «Подцели», «Сценарии-подцели» и « Список команд». Реляционная структура БД детализирована в табл. 1 - 4. соответственно (ключевые поля таблиц подчеркнуты).
1 1 2
BE, 2005, 1 4
Рис. 1. Общая структура планирующей ЭС (режим 1)
Таблица 1
Структура таблицы «Сценарии»
Имя поля Тип поля Размер
Иденгификатоп сценапия Целое
Название сценария Текстовый 100
Результат выполнения Текстовый 100
Таблица 2
Структура таблицы «Подцели»
Имя поля Тип поля Размер
Идентификатор подцели Целое
Наименование подцели Числовой 50
Идентификатор списка команд подцели Текстовый 50
Контекстное условие Текстовый 255
Условие обязательности Текстовый 255
Сколько раз выполняется Логический
Словесная формулировка условия обязательности Текстовый 255
Словесная формулировка контекстного условия Текстовый 255
Идентификатор подчинённого сценария Целое
Таблица 3
Структура таблицы «Сценарии-подцели»
Имя поля Тип поля Размер
Идентификатор сценария Целое
Идентификатор подцели Целое
Таблица 4
Структура таблицы «Список команд»
Имя поля Тип поля Размер
Идентификатор списка команд Целое
Название команды Текстовый 255
Вес команды Вещественное
Таблица « Сценарии» и « Сценарии-подцели» связаны по полю «Идентификатор сценария» отношением «один ко многим». Таблица «Подцели» и «Сценарии-Подцели^) связаны по полю «Идентификатор подцели» отношением «один ко многим». Таблицы «Список команд» и «Подцели» связаны по полю «Идентификатор списка команд».
Таблицы « Сценарии» и «Подцели» реализуют объекты « Сценарий» и «Подцель» ER-модели. Поля «Идентификатор сценария» и «Идентификатор подцели» ключевые для таблиц «Сценарии» и «Подцели». Таблица « Сценарии-подцели» задаёт соответствие между сценариями и подцелями. Поле « Идентификатор подчинённого сценария» показывает, какой сценарий из таблицы «Сценарии» реализует выполнение указанной подцели. Поле «Идентификатор списка команд» в таблице «Подцели» содержит числовое значение, соответствующее одной или нескольким командам из таблицы «Список команд».
При запуске системы загрузчик базы знаний формирует представление базы знаний в памяти, которое базируется на нескольких основных объектах (рис. 2).
Рис. 2. Диаграмма классов
Объект «Сценарий» (Scenario) реализует в представлении один сценарий. Он содержит информацию о сценарии, такую как его название, результат и идентификатор. Кроме этого, в данном объекте хранятся указатели на список подцелей данного сценария, а также указатель на родительский сценарий. Последний хранится в целях упрощения алгоритма перехода вверх по сценариям.
Объект « Сценарий» содержит методы доступа к списку подцелей в сценарии для добавления подцели, удаления текущей подцели, поиска и изменения подцели, перемещения на первую, последнюю, следующую за текущей и предыдущую подцель.
BE, 2005, 1 4
1 1 3
Объект «Иерархия сценариев» (Scenario Hierarchy) реализует иерархию сценариев. В качестве данных он содержит три основных параметра: указатель на корневой сценарий, указатель на текущий сценарий и временный указатель на вновь созданный сценарий. В качестве методов данный объект содержит методы добавления дочернего сценария к текущей подцели, а также методы перемещения по подцелям в текущем сценарии.
Объект «База знаний» (KnowBase) содержит в качестве свойства ссылку на объект «Иерархия сценариев», а также ссылки на таблицы базы знаний на диске. В качестве методов данный объект содержит функции получения информации о контекстных условиях, а также функции поиска необходимого сценария и подцели.
Объект «Локальная база данных» (LocalDataBase) содержит методы, необходимые для ввода и вывода информации о выполненных подцелях, а также методы, при помощи которых происходит проверка плана (методы, реализующие решатель экспертной системы).
Предлагаемая экспертная система может работать в трёх режимах:
- автономный режим, при котором пользователь составляет план своих действий, используя дерево целей и подцелей, а экспертная система помогает ему и проверяет полученный план (режим 1);
- режим контроля за действиями пользователя во время его работы с программной системой. При этом экспертная система сравнивает команды, которые пользователь выполняет, со своей БЗ, и по желанию пользователя выдаёт предупреждения и ошибки (режим 2);
- режим автоматизированного выполнения команд программной системой при планировании. При этом пользователь составляет план своих действий, используя базу знаний сценариев, а по завершении и после проверки плана автоматизировано при участии пользователя выполняются команды программной системы (режим 3).
Структура дерева сценариев представлена в [1]. Любой сценарий из иерархии может быть невыполненным, частично выполненным либо полностью выполненным. Для реализации алгоритма решателя примем следующие обозначения для подцелей в локальной базе данных: если подцель не выполнена, то она не отмечена. Если подцель частично выполнена - то она отмечена n. Если подцель полностью выполнена - то она отмечается ь.
Если решатель работает в режиме 1, то пользователь в этом случае самостоятельно отмечает цели и подцели, включаемые в план. При этом, если из подцели не исходит сценарий, то в этом случае подцель не может быть частично выполненной, т.е. не может быть отмечена
n. В ходе работы с планирующей экспертной системой в режиме 1 пользователь отмечает подцели, а система выбирает тип отметки с учётом того, что если подцель имеет подчинённый сценарий и в нем не выполнены обязательные подцели, то в этом случае данная подцель отмечается n, в противном случае ставится отметка ь. В процессе работы пользователя с системой в первом режиме могут наступать следующие события: «Измене-
ние текущей подцели», «Выбор подцели», «Очистка всего плана», «Очистка вниз», «Проверка плана».
При наступлении события «Изменение текущей подцели» в окне ввода-вывода изменяется текущая подцель, а также выводятся для новой текущей подцели все параметры, связанные с данной подцелью: контекстные условия, условия обязательности, условие однократности выполнения и текущий сценарий.
Если пользователь вводит команду «Проверка плана», то наступает соответствующее событие, решатель просматривает дерево, начиная с корня, и проверяет сначала контекстные условия, затем условия обязательности и условие однократности выполнения действия. В случае нарушения контекстного условия (действие выполнено, но не разрешено) выдаётся ошибка. В случае нарушения условия обязательности (действие разрешено, обязательно, но не отмечено ь) выдаётся предупреждение.
Если пользователь выполняет команду «Очистка всего плана» или «Очистка плана вниз», то решатель либо снимает все отметки в плане (в случае если наступает событие « Очистка всего плана»), либо только у текущей подцели, и если есть, то у подчиненных сценариев.
Рассмотрим далее режим 2, когда подсистема помощи контролирует действия пользователя. Схема работы для второго режима представлена на рис. 3.
В этой схеме используется та же экспертная система, что и в первом режиме. Но в данном случае пользователь взаимодействует с программной системой, а мониторинг процесса взаимодействия осуществляется специальной программой-монитором.
Рис.3. Подсистема помощи на основе планирующей экспертной системы (режим 2)
1 1 4
BE, 2005, 1 4
Монитор перехватывает сообщения, передаваемые окну программной системы, и при выполнении некоторой команды передаёт её интерпретатору подцели. Интерпретатор «команда-подцель» имеет свой внутренний буфер, в который помещается переданная команда, после чего интерпретатор обращается к базе знаний на диске и ищет указанную команду в базе знаний. Если в результате поиска обнаруживается, что в базе знаний данной команде соответствует несколько подцелей, то в этом случае интерпретатор не отмечает подцель в ЛБД, а ожидает прихода следующей команды, после чего повторяет поиск. Если подцель в базе знаний найдена, и она единственна, то в этом случае решатель отмечает данную подцель в ЛБД и очищает свой внутренний буфер команд.
В режиме 2 предлагается собирать статистику о выполненных командах в целях передачи пользователю информации о наиболее часто используемых командах. В самом начале при создании базы знаний на каждую команду, соответствующую одной подцели, заводится счётчик. Начальное значение этого счётчика равно 0. В процессе работы в режиме 2 пользователь выполняет одну из команд, соответствующую данной подцели, после чего счётчик этой команды увеличивается на 1. Команды выводятся пользователю на основе анализа веса каждой конкретной команды в данный момент времени, который вычисляется по формуле:
k
W =____ком..
m
Ski (2)
i=1
Здесь kком - значение счётчика выполнения команды; m - количество команд для подцели. Значение W для команд по мере изменения сохраняется в базе знаний.
Рассмотрим теперь, каким образом происходит выдача сообщений об ошибочных командах. Это делается по желанию пользователя при нажатии на «горячую» клавишу.
1. Система проверяет, имеются ли в сценарии невыполненные обязательные подцели.
2. Если невыполненных обязательных подцелей в сценарии нет, то в этом случае пользователю выводится сообщение о корректности его действий.
3. Если невыполненные обязательные подцели в сценарии есть, то в этом случае пользователю выдается предупреждение и для каждой такой подцели выводится наиболее часто применяемые для реализации подцели команды, используя веса.
Структура системы в режиме автоматизированного выполнения команд (режим 3) представлена на рис. 4. При работе в этом режиме после проверки плана система может, по желанию пользователя, автоматизировано выполнить команды программной системы.
Это значит, что будут автоматически выполняться команды, соответствующие подцелям, входящим в план, а пользователь будет отслеживать выполнение и вводить необходимую информацию. В случае безошибочности плана экспертная система может его выполнить, используя специальные блоки: «Интерпретатор «подцель-команда»» и « Эмулятор команд». В задачу интерпретатора входит поиск команды, соответствующей подцели, которую передаёт ему экспертная система. При получении подцели интерпретатор «подцель-команда» обращается к базе знаний с запросом о том, какая команда соответствует данной подцели. При получении команды данный блок передаёт её эмулятору команд, который программным образом выполняет команду в программной системе. А пользователь участвует в выполнении плана, например, вводит названия объектов в диалоговых окнах и т.п.
4. Способы реализации экспертной системы. Для
всех трёх режимов работы используется одна и та же структура экспертной системы (рис. 1, 3, 4). Это позволяет сделать предположение о необходимости реализации этой экспертной системы на базе технологии компонентных объектов COM или CORBA [2, 3]. В состав такого компонента входят база знаний на диске, база знаний в памяти, загрузчик БЗ, решатель и окно ввода-вывода.
Рис. 4. Схема подсистемы помощи в режиме 3
BE, 2005, 1 4
1 1 5
Из приведенных в статье схем видно, что для реализации экспертной системы, используя данную технологию, необходимо разработать несколько программных интерфейсов для компонента, которые должны обеспечивать решение следующих задач:
- поддержка БЗ с помощью СУБЗ;
- обеспечение средств поиска необходимой информации внешними для компонента частями системы;
- обеспечение работы с окном, содержащим информацию о плане пользователя.
Решение данных задач позволяет получить достаточный контроль над экспертной системой для реализации всех трёх режимов её работы. Реализация блока экспертной системы на базе одной из компонентных моделей позволяет практически без перепрограммирования переводить экспертную систему в любой из трёх режимов работы при наличии программной реализации дополнительных компонент системы, необходимых для 2 и 3 режима. К этим компонентам относятся монитор, интерпретатор подцели, интерпретатор команд и исполнитель команд.
Если необходимо встроить систему помощи в готовую программную систему (режим 2), монитор может быть реализован в виде ловушки оконных сообщений [4]. В задачу ловушки входит мониторинг сообщений, посылаемых окну. Отслеживая параметры сообщения, монитор выделяет из этих параметров команды системы и передаёт их интерпретатору подцели (см.рис. 3).
Для нового программного обеспечения при разработке подсистемы помощи на базе представленной технологии программа-монитор встраивается в интерфейсную часть разрабатываемого программного продукта.
Интерпретатор команд (режим 3) и исполнитель команд (эмулятор) также реализуются в виде COM-
УДК 004.942
ДОСЛІДЖЕННЯ Y -СЕМАНТИК ДЛЯ МОДИФІКАЦІЙНИХ ПРЕДИКАТНИХ ЗАПИТІВ
ШЕКЕТА В.І.________________________________
Вводиться семантичний підхід для виконання категоріальної інтерпретації формально-логічного апарату модифікаційних предикатних запитів на основі денотаційних семантик в рамках теорії фіксованих значень, категоріальної дедукції і функторних інтерпретацій, які характеризуються повнотою істинності. Введені семантичні стратегії мають обгрунтовану істинність, а шари одержаної індексованої категорії є повними структурами, що відповідають категорійним дедукціям модифікаційних предикатних запитів.
компонентов. Так как они расположены на выходе экспертной системы, то для реализации третьего режима в компонент, реализующий экспертную систему, необходимо встроить процедуру, которая осуществляет поиск компонента в системе, и если он установлен, инициализирует его.
5. Заключение
Рассмотрены основные принципы и алгоритмы реализации подсистемы помощи пользователю на основе планирующей экспертной системы с использованием сценариев. Впервые предложена теоретико-множественная модель человеко-машинного взаимодействия. Это позволяет формализовать знания, необходимые для построения экспертных подсистем помощи. Практическое значение полученных результатов заключается в разработке структуры и алгоритмов функционирования экспертных подсистем помощи. Использование экспертных подсистем помощи позволяет снизить требование к уровню подготовки пользователей и ускорить процесс освоения способов работы с вычислительной системой. Для дальнейшего усовершенствования подсистемы помощи предлагается рассмотреть автоматизацию процесса получения знаний.
Литература: 1. Рувинская В.М., Пригожее А.С. Построение подсистемы помощи пользователю ПК с использованием сценариев // Искусственный интеллект. 2004. № 3. 2. Роджерсон Д. Основы COM - Microsoft Press 2000 3. Цымбал А.В. Технология CORBA для профессионалов. СПб.: «Питер», 2001. 4. Кайл Марщ Хуки в Win32- http:// www.rsdn.ru/article/baseserv/winhooks.xml.
Поступила в редколлегию 28.06.2005
Рецензент: д-р техн. наук Гогунский В.Д.
Пригожев Александр Сергеевич, аспирант кафедры системного программного обеспечения Одесского национального политехнического университета. Научные интересы: системы человеко-машинного взаимодействия. Адрес: Украина, 65029, Одесса, пер. Сеченова, 3, кв. 10 , тел. 717-30-44.
Вступ
Категорійні підходи до логічного програмування з’явилися разом із категорійним підходом до процедури уніфікації [1-9]. Основним результатом стало введення категоріальної формалізації для синтаксису логіки тверджень Хорна і її розширення на основі семантики теоретичних топосів. В [10], розвиваючи деякі базові ідеї, сформульовані в [11], виконано категоріальний аналіз логічних програм і побудову відповідних моделей на основі використання індексованих моно-їдних категорій.
Всі ці підходи зосереджені на побудові суто теорети-ко—операційних моделей. В той же час мало уваги приділяється застосуванню денотаційних семантик до побудови операторів на зразок оператора безпосереднього слідування, який є важливим з точки зору побудови логічних програм і дослідження їх семантик [12]. Більшість досліджень семантик логічних про-
1 1 6
BE, 2005, 1 4
