CC BY
96
УДК 004.896
МУЛЬТИАГЕНТНАЯ СИСТЕМА ПОИСКА ИНФОРМАЦИИ НА ПРОМЫШЛЕННОМ ПРЕДПРИЯТИИ
А.Н. Швецов, д.т.н.; В.И. Летовальцев
(Вологодский государственный технический университет, smithv@mail.ru, LetovaltsevVictor@gmail.com)
Описывается архитектура мультиагентной системы для проведения поиска информации на промышленном предприятии. Перечисляются характерные черты такой системы и особенности ее реализации. Дано описание формального проектирования, результатами которого являются концептуальная модель и дерево интеллектуальных компонентов системы.
Ключевые слова: информационные поисковые системы, мулыпиагентные системы, концептуальная модель поиска, формальное описание.
Обеспечение эффективности основной деятельности - обязательное условие при разработке и совершенствовании системы управления предприятием. Более конкурентоспособными являются предприятия, максимально использующие свои ресурсы, в том числе и информацию. Поэтому в современной инфраструктуре предприятия резко возрастает роль информационно-аналитической системы (ИАС). Можно сказать, что основная функция ИАС - обеспечение реализации последовательностей работ, направленных на решение задач управления производством [1].
Важными условиями эффективного управления деятельностью являются возможность использования необходимой информации и обеспечение требований к содержанию и форме представления данных. Под документом в ИАС будем понимать формализованный информационный объект [2].
ИАС участвует в основных бизнес-процессах предприятия: сбор и структуризация исходной информации, хранение данных, формирование отчетов, планирование и анализ. Можно выделить три потока документов - входящие, исходящие и внутренние. В ИАС может входить информация как внутреннего, так и внешнего характера: организационные документы (приказы по предприятию, служебные записки, должностные инструкции и т.д.); производственные (технические регламенты, стандарты, рекомендации, описания техпроцессов); финансовые (бухгалтерские документы, отчеты, результаты экономического анализа); маркетинговые (анализ состояния рынков, уровня конкуренции и т.д.); юридические (законы, указы президента, постановления правительства, распоряжения министерств и ведомств, лицензии и т.д.).
Перевод документооборота предприятия в электронную форму дает возможность ускорить принятие решений и повысить эффективность управления производством. Информационные технологии позволяют перейти к полностью безбумажному документообороту, при использовании которого одной из важнейших проблем становится обеспечение сотрудников своевременной
информацией. Важным механизмом такого обеспечения является информационный поиск.
Информационный поиск в ИАС крупных предприятий имеет ряд особенностей. У каждого вида документов свой формат и принадлежность к определенной документной базе. Бухгалтерские документы принадлежат базам бухгалтерских систем (например, 1С или «Галактика»), юридические документы находятся в базах правовых систем (например, «Консультант Плюс» или «ГАРАНТ»), электронная почта - на почтовом сервере предприятия и т.д. Стоит учитывать и возможность разнородности аппаратных ресурсов и вычислительных платформ, на которых функционирует указанное ПО.
Существуют различные варианты решения проблемы информационного поиска. Первый вариант - реализация локальных поисковых подсистем в каждом информационном модуле ИАС предприятия. Достоинство такого подхода - простота реализации, недостатки - невозможность поиска по нескольким источникам из единой точки доступа, сложность модификации и обновления системы, высокая стоимость администрирования и настройки.
Необходима реализация системы, позволяющей организовать доступ к гетерогенным территориально распределенным источникам информации. Среди современных технологий построения корпоративных информационных систем с подобными характеристиками, по мнению авторов, стоит выделить сервисную и агентную архитектуру. Агентная архитектура имеет ряд преимуществ при решении подобного класса задач [3], поэтому для создания распределенной системы поиска информации в масштабах предприятия имеет смысл использовать именно агентный подход. Неформальная схема мультиагентной системы поиска информации представлена на рисунке 1.
Пользователь осуществляет взаимодействие с системой посредством персонального агента пользователя. Запросы пользователя перенаправляются поисковым агентам, реализующим конкретные алгоритмы поиска (на схеме рис. 1 это алгоритм
Лингвистические базы
Рис. 1
поиска на основе логики Монтегю [4] и алгоритм расширения запроса пользователя). Агент может осуществлять поиск как на основе индекса (посредством соответствующего агента), так и путем прямого доступа к информационному ресурсу. Ввиду специфичности обработки различных естественных языков необходимо выделение специального агента для обработки языковых данных. Фоновые знания о предметных областях предлагается хранить в виде формальных онтологий. Схема на рисунке 1 дает лишь общее представление о функционировании предлагаемой системы, для технической реализации необходимо более точное формальное описание.
Интегрированный подход к решению задач создания агентно-ориентированных систем предлагает методология проектирования мультиа-гентных интеллектуальных систем (МАИС) [5]. Данная методология основывается на теории информационных объектов и охватывает все основные этапы процесса создания распределенной интеллектуальной системы. Она имеет комплексный и завершенный характер, так как рассматривает построение систем такого класса на всех необходимых уровнях описания, начиная от обобщения концептуальной модели предметной области и заканчивая моделью информационного объекта, взаимодействующего с конкретным корпоративным приложением.
Предлагаемая методология проектирования МАИС включает следующие этапы: идентификация предметной области (ПрО), извлечение знаний о ПрО, структурирование знаний о ПрО, формализация, реализация, отладка и тестирование.
На этапе структурирования знаний о ПрО применяется подход, при котором структуры фреймов соединяются с конструкциями концептуальных графов, образуя концептуальную модель ПрО (КМПрО). Формально КМПрО определяется как
KM=(F, R, Ф, Ф), где F=^K} - множество
фрейм-концептов (ФК); |={M} - множество модулей концептуальных графов; R={KO} - множество концептуальных отношений; Ф - отображение FxR^F; Ф - отображение такое, что каждому ФК Fkij может быть поставлено в соответствие некоторое подмножество из множества | , то есть |-{Мь ..., М„}, |'С|.
ФК представляет собой фреймоподобную структуру вида FK=(ИФ, ТФ, ИП, ССП, ССЛ), где ИФ - имя фрейма; ТФ - тип фрейма; ИП - информация о применении (неформальное вербальное описание); ССП - структура сценариев поведения; ССЛ - структура слотов.
Динамическое поведение компонентов ПрО описывается структурой сценариев поведения фреймов, позволяющей формировать альтернативные пути поведения каждого фрейма.
Структура слотов представляет собой совокупность двух структур: ССЛ=(CK, CA), где СК -структура концептов; СА - структура атрибутов.
Структура концептов содержит список ФК, в некотором отношении вложенных или порожденных охватывающим ФК: ^={(ИК1, КО1), (ИК2, КО2), ..., (ИК„, КО„)}, где ИК, - имя концепта; КО, - тип концептуального отношения концепта ИК, к данному ФК.
Структура атрибутов представляет собой следующее множество: CА={(ИА1, МО1, ЗА 1), (ИА2, МО2, ЗА2), (ИАт, МОт, ЗА т)}, где ИАг - имя 1-го атрибута; МО, - область определения атрибута; ЗА, - значение атрибута.
Для установления логической организации ПрО ФК соединяются в структуры концептуальных графов, имеющие два типа вершин: вершины концептов и вершины концептуальных отношений.
На начальной стадии концептуализации строится сеть ФК по вложению концептов, принимающая во внимание только структурный аспект ПрО: KM(FK)=(F, R, Ф).
Логические взаимосвязи ФК КМПрО описываются концептуальным графом, в котором дуги связывают концептуальные отношения и ФК, входящие в них. Выделим следующие ФК в ПрО ин-
формационного поиска на промышленном предприятии.
ФК «Запрос» можно представить в следующем виде: FKзaпp=("Запрос", Query, "Запросданных",
0, (CKзапрос, СЛнастр)).
У него есть один атрибут СЛзапр={Текст, String, ЗН}.
Здесь и далее будем описывать схемы атрибутов, а не сами конкретные атрибуты. Поэтому в качестве значения используем обозначение ЗН, которое может быть заменено конкретным значением при заполнении соответствующего ФК.
Запрос состоит с множеством вложенных настроек в отношении Содержит:
СКзапрос={(Настройка1, Содержит), ..., (На-стройка1, Содержит)}.
Запрос может иметь множество вложенных настроек. При этом ФК «Настройка» имеет вид FКкacmp=("Насm^ойка", Setting, "Входныепара-
метры", 0, (0, СЛнастр)), СЛ„астр={(Св1, Binary, ЗН1), ..., (Свп, Binary, ЗНп)}, где Св1, ..., Свп -множество имен значений свойств настройки; Binary - множество бинарных объектов, типизация которых выполняется алгоритмом.
Ввиду многообразия языков представления знаний целесообразно выделить отдельный элемент обработки лингвистической информации. Назовем этот ФК «Лингвист». Важным параметром является множество языков, которые могут обрабатываться данным концептом. Формально концепт «Лингвист» определим так: FКшнг=("Лингвисm", Ling, "Обработка_языковых_
даННЫХ", СППЛинг, (0, САЛШг)), САЛинг={(Я31, Boolean, ЗН1), ..., (Язк, Boolean, ЗНь)}, СППлинг={МорфАнализ, СинАнализ}, где Яз1, ..., Язь - множество обозначений языков; Boolean -тип истинного значения; МорфАнализ - сценарий поведения, реализующий морфологический анализ; СинАнализ - сценарий поведения, реализующий синтаксический анализ. В качестве обозначений языков могут выступать их стандартизированные буквенные коды. При поддержке соответствующего языка логическое поле фрейма становится равным true. Результатами применения поведений МорфАнализ, СинАнализ могут представляться в различной форме.
ФК «Текст» имеет следующее формальное представление: FКmекcm=("Тексm", Text, "Текст_
на_ЕЯ', 0, (0, САтекст)), САтекст={(Название, String, ЗН1), Авт, (URI, String, ЗН2), (Содержание, String, ЗН3)}, Авт={(Автор1, String, ЗН1), ..., (Авторп, String, ЗНп)}.
В данном случае взят минимальный набор атрибутов текста. Для электронного документа такой набор может быть достаточно обширным.
Все тексты находятся в некотором информационном ресурсе, который представляется в данном
случае как ФК «Хранилище». Можно сказать, что хранилище находится в отношении Содержит к ФК «Текст»: FКхран=("Хранилище", Storage, "Ме-сто_хранения_текстов", СППхран, (СКхран, СА хран)), САхран={(Имя, String, ЗН1), (Tun, String, ЗН)}, СКхран={(Текст\, Содержит), ..., (Текстп, Содержит)}, ССПхран={ПолучитьТекст}, где Тип -строковое обозначение хранилища, используемое для определения способа доступа к нему; Полу-читьТекст - операция извлечения текста из хранилища на основе его URI
При организации поиска важное место отводится индексу. ФК «Индекс» может представлять собой произвольную структуру. К настоящему моменту известно множество методов построения индексов для разных целей. Если необходимая служебная информация содержится в индексе, то текст находится с этим индексом в бинарном отношении Индексирован. В данном случае представим ФК «Индекс» следующим образом: FKmd =("Индекс", Index, "Индекс_для_информационно-
гопоиска , 0, (СКинд, САин д)), САинд={(Имя, String, ЗН\), (Тип, String, ЗН2), (СлИнф\, Binary, ЗН3), ..., (СлИнфп, Binary, ЗН„+3)}, СКинд={(Текст\, Индексирован), ..., (Текстп, Индексирован)}, где СлИнфi - служебная информация в j-м индексе (в общем случае в бинарном виде), хранимая индексом для текста Текст„ причем 3 (Текст, Индексирован) е
е ckL .
Индекс используется определенным поисковым алгоритмом. «АлгоритмП» является ФК, инкапсулирующим конкретный способ поиска интересующих текстов. Один алгоритм может использовать несколько индексов и ФК лингвистической обработки. ФК «АлгоритмП» можно представить в следующем виде: FКалгП=("Алго-ритм", SearchAlg, "Алгоритмпоиска", СППалгП, (СКалгП, САалгп)), САалгП={(ИмЯ, String, ЗН)}, СКалгп={(Лингвист1, Использовать), ..., (Линг-вистk, Использовать), (Индексь Использовать), ..., (Индекст, Использовать)}, ССПалгП={Найти}, где Найти - сценарий поведения, реализуемый конкретным алгоритмом.
ФК «Пользователь» представляет пользователя поисковой системы. Пользователь должен иметь имя и идентификатор в системе. Имя используется для отображения в различных вариантах пользовательского интерфейса, идентификатор пользователя - для однозначного определения данного пользователя. Цели такого определения могут быть различными: проверка прав доступа, персонализация настроек, учет и отображение истории запросов и т.д. Для обоих атрибутов можно использовать строковый тип данных.
Формально ФК «Пользователь» представим в следующем виде: FКnольз=("Пользователь", User,
"Пользовательсистемы", 0, (СКпольз, САпольз)),
САпольз={(Ид, String, ЗН)}, СКпольз={(Запроси Фор-
мировать), ..., (Запросп, Формировать), (Алго-ритмП1, Выбирать), ..., (АлгоритмП, Выбирать)}.
ФК «Пользователь» состоит в отношении Формировать с ФК «Запрос». При формировании запроса пользователь изменяет настройки запроса (ФК «Настройка»), но эта связь не показана, чтобы не перегружать концептуальную модель.
КМПрО поиска информации на предприятии можно представить в графическом виде (рис. 2). На рисунке для наглядности приняты следующие упрощения. Показан вариант при использовании одного индекса и одного текстового хранилища. В общем случае один алгоритм может использовать несколько индексов, а индекс может хранить информацию о текстах, хранящихся в разных текстовых хранилищах.
Формализация представляет собой процесс трансляции КМПрО в логическую модель МАИС. В основе логической модели лежит дерево имен
концепта 1Ж, представляющее собой связный неориентированный граф без циклов, вершинами которого являются имена концепта МАИС (Ж,, ..., Ж, ..., Ж,...). Дуги графа соединяют имя концепта с другими именами концепта вышестоящего или нижестоящего уровней.
С каждым именем концепта связывается его формальная объектная структура: Ж,=(Жй, Жа, ..., Ж> 1А,1, 1А,2, ..., 1Ат; ОЛ, Oa, ..., Olí;), где Ж,
- интеллектуальный компонент; 1А , - интеллектуальный агент; Oi - интеллектуальный объект.
Информационный объект - это структура вида O=(NO, {А}, {O}, БЫ), где NO - имя объекта; {A}
- множество атрибутов объекта; {О} - множество объектов, структурно вложенных в данный объект; БЫ - модель поведения информационного объекта.
Атрибут информационного объекта определяется как А=^А, 8А, УА), где NA - имя атрибута; 8А - область определения; УА - значение атрибута.
Хранилище
СА
Имя
Тип
СК
Текст, Содержит
Текст; Содержит
СПП
ПолучитьТекст
Пользователь Алгоритм поиска
СА СА
Имя Имя
Ид СК
СК Лингвист Использовать
Запрос Формировать Индекс Использовать
АлгоритмП Выбирать СПП
Найти
Запрос Настройка1
СА СА
Текст Свойство11
СК
Настройка, Содержит Свойство],
Настройкап
Настройка „ Содержит
Лингвист
СА
Язык,
Языкр
СПП
МорфАнализ
СинАнализ
Текст1
СА
Название1
Автор1
Автор1т
URI1
Содержимое1
Индекс
СА
Имя
Тип
СлИнф1
СлИнф t
СК
Текст Индексирован
Текстt Индексирован
Текст
Рис. 2
Таким образом, дерево имен концепта является связующим звеном между логической и объектной структурами МАИС.
Процесс формализации заключается в выделении интеллектуальных компонентов, построении дерева имен концепта ТЖ, декомпозиции сети ФК по дереву имен концепта, трансляции дерева ФК в логическую модель МАИС (TFK в Т(Ж, 1А, Ю)) и построении БЗ имен концепта.
Задача выделения интеллектуальных компонентов состоит в декомпозиции КМПрО на связанные подобласти, которые будут представляться в логической модели интеллектуальными компонентами и их ФОС. Далее сеть ФК связывается с деревьями 1Ж - выполняется декомпозиция сети ФК по дереву имен концепта.
Корневым элементом дерева будет системный компонент, олицетворяющий поисковую систему
в целом: ЖсисП=(Жадм, 1Kанлиз, Жпоиск; 1Aдосm1,
1АдостМ; Оид1, Оид2, ..., Оидк), О ид =(ИстДанных', {Свойство, }, {£}, ПредоставитьРесурс).
Этот наиболее абстрактный уровень содержит описание фактически внешних по отношению к системе объектов, которыми являются источники данных Оид. Выделение источников данных необходимо именно на этом абстрактном уровне, так как они являются внешними по отношению к системе, но принимают непосредственное участие в ее функционировании. Источники данных имеют набор свойств Свойство, (в общем случае бинарных), которые интерпретируются при конкретных реализациях ресурсов. Информационный объект источника данных реализует лишь поведение по предоставлении конкретного ресурса. Информационные ресурсы, как уже отмечалось, могут быть разнородными по своей природе. Соответственно, будут разниться и интерфейсы доступа к ним. Для унификации доступа к произвольным ресурсам
вводятся интеллектуальные агенты доступа 1Адост, скрывающие специфические методы взаимодействия с ресурсом и предоставляющие общую функциональность для других агентов системы. В некоторых случаях выделение такого агента нецелесообразно, например, при доступе к ресурсам, уже реализующим некоторый общий интерфейс (в качестве веб-сервисов или агентных реализаций). Поэтому количество агентов доступа может отличаться от количества ресурсов. Агенты доступа могут выполнять и задачи протоколирования, профилирования и разграничения доступа.
Интеллектуальный компонент администрирования формально представим как Жадм=(0; 1Аадм,
..., 1АадмК; 0).
Это структурно наиболее простой интеллектуальный компонент, состоящий из агентов-администраторов, позволяющих настраивать различные параметры функционирования других компонентов. Компонент анализа состоит из лингвистической и индексирующей составляющих: Жансаиз=
=(ЖШнг, жтд; 0; 0).
Лингвистическая составляющая представляется следующим образом: Жшкг(0; 1АШнг; Обз_яз1, Обз яз2, ..., Обз язи), Обз яз = (База_языкаг, {Морф1, Синтаксис'}, 0, 0).
Лингвистический интеллектуальный компонент содержит информационные объекты для каждого языка. Такие объекты включают всю необходимую информацию о конкретных языках (об их морфологии и синтаксисе).
Индексирующий интеллектуальный компонент создает индексы для проведения информационного поиска на массивах текстовых данных: Жинд=
=(0; IAинд1, 1AиндS, Оинд1, Оинд2, ОиндК), Оинд =
=(Индекс', {Текст1, Имя_источника1}, 0, 0).
^ткт т О ид 1 - ^^ по 2? ■ ■ ■ - ^^ по к
1Киид 0 1АиИа 1, ..., 14ш1а ¡, Ои„а I, Оша2, ..., О,
ЖтшР 0 1Аттг 0Бз яз 1, 0Бз яз2.....Обз язк
1КпоисК 0 !Апомьз . . . , 1Апомьз ТАалгП 1Ааягп q 0
Рис. 3
По отношению к источнику данных индексы Оинд могут быть как внешними, так и внутренними. Если в качестве источника данных выступает БД с внутренними инструментами индексирования, то из соображений скорости поиска такой индекс логично сделать внутренним. Если же источник данных не предоставляет средства семантической индексации, индекс может быть внешним по отношению к ресурсу.
Интеллектуальный компонент поиска состоит
из двух объектов-агентов: 1К„оиск=(0; Аользи •••,
1А пользи 1А алгП1, 1А алгПQ).
Агенты пользователя 1Апольз реализуют пользовательский интерфейс для пользователя-человека. Агенты 1АалгП осуществляют поиск информации согласно соответствующему алгоритму поиска на основе индекса или без него.
Графически дерево имен концепта системы семантического поиска можно представить в виде схемы, изображенной на рисунке 3.
Предлагаемый вариант реализации поисковой системы для промышленного предприятия отли-
чается масштабируемостью, хорошей формализацией компонентов и небольшой стоимостью разработки. При этом система поиска может функционировать как самостоятельно, так и внутри корпоративных агентных сообществ и использоваться в большинстве существующих поисковых алгоритмов.
Литература
1. Костров А.В., Александров Д.В. Уроки информационного менеджмента. Практикум: учеб. пособие. М.: Финансы и статистика, 2005. 304 с.
2. Автоматизированные информационные технологии в экономике / М.И. Семенов [и др.]; [под общ. ред. И.Т. Труби-лина]. М.: Финансы и статистика, 2000. 416 с.
3. Летовальцев В.И., Швецов А.Н. Сравнение агентного и сервис-ориентированного подходов к созданию распределенных приложений // Информационные технологии в проектировании и производстве. 2009. № 2. С. 66-71.
4. Швецов А.Н., Летовальцев В.И. Семантическая обработка текста на основе интенсиональной логики для проведения информационного поиска / Интеллектуальные системы: тр. IX Междунар. симпоз.; [под ред. К.А. Пупкова]. М.: РУСАКИ, 2010. С. 146-150.
5. Швецов А.Н. Метаметодология построения мультиа-гентных интеллектуальных систем // Информационные технологии в проектировании и производстве. 2010. № 1. С. 28-33.
УДК 004.056.53
УЯЗВИМОСТЬ ЗАЩИТЫ ВЕБ-КОНТЕНТА ТИПА HTML GUARDIAN
Д.Г. Ермаков, к.ф.-м.н.
(Институт математики и механики УрО РАН, г. Екатеринбург, Ermak@imm.uran.ru)
Рассмотрена задача преодоления защиты информации от копирования, подобная ProtWare's HTML Guardian, стандартными средствами MS Windows - языка сценариев Windows PowerShell и браузера MS Internet Explorer. Показана невозможность защиты контента веб-страницы, так как браузер расшифровывает зашифрованный HTML-код и есть простой и быстрый способ получить этот незашифрованный код средствами PowerShell.
Ключевые слова: информационная безопасность, преодоление защиты, MS Windows PowerShell, MS Internet Explorer, .NET.
Обладатели авторских прав, размещающие свои произведения в Интернете, хотели бы ограничить возможность их несанкционированного копирования. Способы защиты от копирования информации с веб-сайтов хорошо известны (см., например, [1-3]). К ним относятся:
- запрет кеширования страницы;
- запрет копирования элементов страницы;
- отключение (блокирование) функции сохранения картинки;
- блокирование выпадающих меню;
- запрет копирования через стандартное сочетание клавиш Ог1+С;
- защита от копирования модальными окнами;
- шифрование исходного кода страницы и
использование продуктов типа HTML Protector, HTML Power, Encrypt HTML Pro, ProtWare's HTML Guardian.
Среди этих способов наиболее надежным считается шифрование исходного кода страницы и использование продуктов типа ProtWare's HTML Guardian [1].
Перечислим основные способы преодоления данного типа защиты, представленные в [1-3]:
- перепечатка текста, отображаемого браузером, вручную;
- фотографирование экрана, на котором отображается защищенный текст, и распознавание его аналогично тому, как это делается с отсканированным текстом;
- запуск браузера в дополнительном контей-
