Разработка системы поддержки принятия решений для корпоративной сети

Анализ существующих решений системы поддержки принятия решений для корпоративной сети. Многоагентная система. Разработка концептуальной модели. Структура базы знаний. Разработка модели многоагентной системы на базе сетей Петри. Методика тестирования.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык русский
Дата добавления 19.01.2017
Размер файла 5,1 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

СОДЕРЖАНИЕ

  • Введение
    • Анализ существующих решений СППР для корпоративной сети
  • Многоагентная система
    • Контролируемые параметры и требования к СППР
      • Разработка структурной схемы
  • Выбор средств разработки
  • Разработка концептуальной модели
  • Структура базы знаний и правила
  • Разработка структуры агентов СППР на базе сетей Петри
  • Разработка модели многоагентной системы на базе сетей Петри
  • Исследование модели многоагентной системы
  • Разработка методики тестирования
  • Анализ полученных результатов
  • Разработка методических указаний по работе с СППР
  • Заключение
  • Список использованных источников

ВВЕДЕНИЕ

В данное время структура корпоративных сетей все более усложняется, как по мониторингу трафика, так и по использованию разного оборудования.

Поэтому системному администратору трудно принять решение, так как он должен изучить массу данных о различных фактах порой не связанных друг с другом за короткий промежуток времени. Это привело к появлению систем поддержки принятия решений.

СППР помогает принимать решения некоторых задач, которые не имеют четкой структуры или имеют несколько критериев. Для создания СППР нужно изучить много дисциплин, таких как теории искусственного интеллекта, баз данных, методов имитационного моделирования и многое другое.

В данное время у определения СППР нет точного значения, так как структура СППР сильно зависит от разновидности задачи, для которой она создается. А так же от информации о ней и пользователей, для которых эта система разрабатывается.

Система поддержки принятия решений - это компьютерная автоматизированная система, цель которой помощь людям в сборе и анализе информации о предметной области.

Своевременность создания СППР подтверждается тем, что стоимость и ответственность принятия решений на руководящих должностях все время возрастает, а время на принятия этих решений постоянно уменьшается. Решением этой проблемы служит СППР., особенно полезно применение СППР при управлении опасными производственными объектами.

Об этом свидетельствует масштаб и количество техногенных аварий за прошедшее десятилетие, а так же тяжесть последствий после них. Кроме этого, важно учитывать информацию о надежности, износостойкости и старении материалов, которые используются на производстве. Так же надо учитывать человеческий фактор при работе со сложными системами, так как около 70% аварий происходят по вине лица принимающего решение.

В данное время развиваются новые направления в информационных технологиях. Появление интеллектуальных систем, распределительных технологий и многого другого вынуждают предприятий совершенствоваться.

Исходя из опыта, можно сказать, что улучшить эффективность СППР можно с помощью перехода к системам накопления знаний и ориентирования на прогнозирование.

Сложность разработки СППР для корпоративной сети определены тем, что появляется необходимость создания сложных баз знаний и баз данных.

Все это дает возможность сделать вывод, что разработки направленные на улучшение и автоматизацию производственных процессов через применение СППР актуальны.

АНАЛИЗ СУЩЕСТВУЮЩИХ РЕШЕНИЙ ДЛЯ КОРПОРАТИВНЫХ СЕТЕЙ

Для СППР не существует полной классификации, так как разные авторы не сходятся во мнениях.

По характеру управления СППР делятся на управляемые данными, сообщениями, документами, знаниями, моделями и знаниями.

Управляемые моделями предназначены в основном для доступа и манипуляции с математическими моделями (финансовыми, статистическими, имитационными, оптимизационными).

Управляемые сообщениями предназначены для пользователей, которые трудятся над решением коллективной задачи.

Ориентированные на работу с данными предназначены в основном на доступ и манипуляции с данными.

Управляемые документами предназначены для управления, осуществления поиска и манипуляции различной информацией, которая задана в разных форматах.

Управляемые знаниями предназначены для возможности решения задач в виде правил, фактов, процедур.

По характеру используемых данных СППР можно поделить на оперативные и стратегические. Оперативные СППР требуются для быстрого рассмотрения изменения ситуации. Стратегические СППР предназначены для анализа больших объемов смешанной информации, собираемой из разных источников.

По характеру использования СППР пользователем, они делятся на активные, кооперативные и пассивные СППР. Активная СППР делает предложение, какое решение лучше выбрать. Кооперативная дает возможность лицу, которое принимает решение, менять, пополнять или совершенствовать решения, которые были предложены системой, отправляя затем эти модификации в систему для проверки. Система меняет, пополняет или совершенствует эти решения и отправляет их опять пользователю. Эти процедуры выполняются до получения гармоничного решения. Пассивная СППР - это система, помогающая процессам принятия решения, но без возможности выбора лучшего решения.

Н уровне техники выделяют СППР всего предприятия и настольную СППР. Система, созданная для целого предприятия, обычно работает с большими хранилищами данных, а так же работает с большим количеством персонала. Настольная система предназначена для одного менеджера и одного компьютера. СППР так же можно разделить в зависимости от информации, с которой она работает. Существует система, работающая с оперативной информацией, которая нужна для быстрого реагирования на изменение ситуации. Такие СППР называют информационными и для них характерно:

· Отчеты от СППР выглядят удобно в виде графиков, таблиц и диаграмм и т.д.

· Ответ системы обычно строится на типовых для предприятия запросах, обычно количество их мало.

· Такие СППР предназначены для вертикального рынка такого, как управление ресурсами, финансы и т.п.

СППР для стратегической информации предназначены для изучения большого количества данных, которые берутся из разных источников. Задачей такой СППР является поиск наиболее верного решения с учетом разных факторов. Важной частью таких СППР являются правила, по которым пользователь системы может принять решение и уменьшить вероятность плохого исхода.

Для разработки СППР часто используются WEB-технологии. Такие системы можно разделить:

· Функциональные СППР. Такие системы просто реализовать по структуре, но они применимы только на предприятиях, где слабо развит уровень технического развития. В таких системах информация, которая находится в операционной системе, анализируется. У данной СППР есть несомненное преимущество в том, что система компактна, так как используется одна платформа, а так же эта система быстро реагирует из-за возможности не нагружать данные лишней информацией. Но у этой системы так же существуют недостатки в виде уменьшения возможностей, где можно применить данную СППР. Так же в системе нет автоматической очистки, что приведет к понижению качества и усилению нагрузки на операционную систему.

· СППР, в которой применяют независимые витрины данных. Они обычно применяются на больших предприятиях, где много отделов и есть свой отдел информационных технологий. Витрина предназначена для каждого отдела своя, направленна на решение определенной задачи, предназначена для определенного вида пользователей. Это позволяет улучшить производительность системы. Применение таких СППР обычно не вызывает сложностей. Но данная система имеет недостатки, данные повторяются, так как разные отделы могут использовать одни и те же данные. Это увеличивает цену создания и внедрения СППР, а так же становится сложно провести унификацию. Так же при заполнении эксперт испытывает сложность, так как приходится работать с множеством источников данных. На предприятии отсутствует общая структура представления.

· СППР с двухуровневым хранилищем данных. Обычно применяются для больших предприятий, где все отделы соединены в единую сеть. Что бы создать и поддерживать СППР для подобного предприятия обычно выделяют отдельную команду работников. Данная СППР не имеет недостатков предыдущей системы, но она не может объединять данные для разных групп работников. И такая система не может закрывать доступ к информации.

· СППР, в которой применяется трехуровневое хранилище данных. В такой системе используют хранилище данных, чтобы создавать витрины для разных групп работников, которые занимаются похожими задачами. В такой системе пользователь имеет доступ не только ко всей информации, но и к объединенной. Заполнение базы данных облегчается тем, что вся информация расположена в одном месте и строго структурирована. На таком предприятии четко выделена структура. Но минусом служит то, что повышаются требования к хранению данных. И такую систему сложно создать, так как надо согласовать структуру со всеми отделами предприятия.

Так же можно разделить СППР по распределённости.

Выделяют сосредоточенные СППР и распределенные. Первый вид обычно имеет одну экспертную систему, для одного пользователя и на одном компьютере. Такая СППР делится на несколько видов.

· СППР из одного узла. Обычно такие системы автоматически принимают решения. Эта система включает в себя компьютер и панель автоматического или ручного ввода данных. Так может выглядеть система пожаротушения на предприятии.

· СППР, где решение принимает работник на основе данных, которые предоставила система. Такая СППР обычно имеет средства оценки принятых решений, моделирующие системы, экспертные программы и т.п. Примером такой СППР служит система для помощи управления кораблём, которая предлагает варианты путей, а командир может выбрать один из них.

Второй вид распределенные СППР. Они могут быть пространственно или функционально распределены. Обычно они состоят из нескольких СППР связанных между собой, каждая из которых решает свой вид задачи, но чтобы решить общую проблему ни у одной из них не хватает данных или ресурсов. Чтобы решить общую проблему им нужно объединиться и соединить отдельно принятые решения.

Такие системы сейчас популярны по нескольким причинам.

· Так как вычислительная техника постоянно развивается, это позволяет соединить в одну сеть несколько компьютеров для выполнения параллельных разных вычислений, а так же иметь возможность обмениваться информацией.

· Почти все области, где используются СППР, уже распределены. Например, в медицине все распределено функционально.

· Системы, которые распределены, упрощают обмен информацией и работу специалистов, которые трудятся над решением одной задачи и работающих на крупном и сложном объекте.

· В таких СППР используется модульное построение, что позволяет делать системы на основе простых и автономных модулей, которые проще эксплуатировать.

Так же СППР можно разделить по уровням.

Существуют системы начального уровня. Обычно такие системы применяются в небольших фирмах. Например, это бухгалтерские или складские СППР. Эти системы имеют отличительные черты.

· Не требуется много ресурсов. Количество пользователей и такой системы от одного до нескольких десятков.

· Такие системы пользователь может установить самостоятельно.

Системы среднего уровня имеют более широкие возможности. Например, управление производством, планирование и т.д. Такие системы имеют возможность работать по всем направления, однако, обычно они создаются в усеченном виде. Такую систему пользователь уже не сможет установить самостоятельно, так как нужно настраивать большое количество параметров. Обычно такие системы дорогие, так как установка и настройка стоят очень дорого.

Однако нужно заметить, что польза от подобных систем зависит от успешного анализа бизнеса, в которые эту СППР будут внедрять.

СППР высшего класса. Такие системы позволяют контролировать все параметры предприятия, а так же позволяют совершать прогнозирование.

Но в связи с этим возрастает цена данного продукта. Для эксплуатации такой системы может потребоваться отдельные специалисты, что так же повысит цену СППР. Внедрение таких СППР часто приводит к реорганизации предприятия. Так же на предприятии потребуется отдельные отдел, который будет настраивать СППР под нужды предприятия.

МНОГОАГЕНТНАЯ СИСТЕМА

Многоагентная система - это такая система, в которой присутствуют несколько агентов. Такие системы обычно применяют для решения проблем, где один агент не справится. Например, это задачи чрезвычайных ситуаций, онлайн торговли.

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

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

Каждый агент в такой системе имеет несколько характеристик.

· Все агенты независимы, хотя бы частично.

· Ни у одного агента нет представления обо всей системе.

· Ни один агент не управляет всей системой

Обычно в мультиагентной системе применяются программные агенты, но так же в системе могут быть и роботы, и люди.

Обычно СППР работает через диспетчера, роль которого выполняет лицо принимающее решение.

Программный агент - это программа, которая взаимодействует с другой программой, человеком или роботом. Слово агент обозначает соглашение выполнять работу от имени кого-то другого.

Интеллектуальный агент - это программа, которая сама делает задание, которое ей задал пользователь. Обычно такие агенты используются для сбора информации или помощи пользователю.

Многоагентные системы используются для решения задач, где данные распределены, а поведение отдельных частей системы гораздо проще описать, чем всю систему.

Такие систему уже широко применяются в управлении и оптимизации производства.

КОНТРОЛИРУЕМЫЕ ПАРАМЕТРЫ И ТРЕБОВАНИЯ К СППР

Так как работа с вычитательной сетью сложна, администратору часто нужно решать проблему на основе данных, которые могут быть неточными или неполными. Из-за этого появляется необходимость разработки нового вида СППР для корпоративной сети.

Вычислительные сети часто содержат в себе много разных элементов, которые взаимодействуют между собой, и это влияет на систему в целом.

В ходе работы было принято решение контролировать функции обнаружения отказов, сканирование сети, проверки TCP, проверки HTTP.

Обнаружение отказов важная часть диагностирования системы так как, пользуясь большим количеством разных устройств (компьютеры, роутеры, сканеры, принтеры и др.), мы часто даже не подозреваем, какие еще устройства находятся в нашей сети, какие из них работают корректно, а с какими нужно поработать.

TCP - это один из основных протоколов передачи данных интернета. Он предназначен для управления трансляцией данных.

Устройство TCP выглядит как поток данных с уже установленным соединением, который выполняет повторный запрос, если данные исчезают, и может удалять те данные, которые будут получены дважды. Это дает гарантию, что все данные будут доставлены и при этом они будут полными и в единственном экземпляре.

HTTP - это протокол для прикладного уровня передачи данных. Этот протокол работает как технология клиент сервер. Существуют клиенты, которые посылают запрос и сервера, которые посылают ответ.

Для мониторинга компьютера будет использоваться протокол SNMP.

SNMP - это протокол сетевого управления. Этот протокол поддерживает маршрутизаторы, сервера, коммуникаторы, принтера, модемы, компьютеры и т.д. Этот протокол используют для управления устройствами, которые требуют администратора.

Функциональные требования

· Система дает большую скорость обработки запросов пользователей о ресурсах, которые им требуются;

· Появление полезной службы диагностики и оповещения пользователя в случае чрезвычайной ситуации;

· Программа должна делать сбор, хранение и отображение всех данных о состоянии системы в целом и так же о каждом устройстве отдельно;

При этом программа должна:

· Не мешать работе системы;

· Вести сбор информации;

· Создать единый центр обработки информации.

Технические требования

· Программа должна быть совместима с компьютерным оборудованием и программным обеспечением.

· Программа должна легко усваиваться.

· Должно присутствовать хорошая документация проекта.

· Система должна давать точные решения.

· Система должна давать оперативные решения.

РАЗРАБОТКА СТРУКТУРНОЙ СХЕМЫ

На основании анализа проведенного выше были выделены следующие функции системы.

· Обнаружение устройств.

· Мониторинг сети.

· Хранение данных мониторинга.

· Отображение данных мониторинга.

· Управление отказами.

· Оповещение о событиях

Для решения перечисленных выше задач выделены несколько типов агентов. Базовая архитектура агента представлена на рисунке 1.

Рисунок 1 - Базовая архитектура СППР

Агенты взаимодействуют друг с другом только посредством передачи сообщений, которое, в свою очередь, является наименьшей единицей передачи данных.

А1 - агент интерфейса.

А2 - агент администрирования (управления).

А3 - агент формирования отчетов.

А4 - агент хранения данных.

А5 - агент мониторинга.

ВЫБОР СРЕДСТ РАЗРАБОТКИ

Сети Петри - это такой математический аппарат, который помогает моделировать динамические дискретные системы. Первый кто описал подобный аппарат, был Карл Петри в 1962 году.

Сеть Петри - это двудольный ориентированный граф, который состоит из переходов и позиций. В таком графе вершины одного типа не могут быть соединены, а в позициях располагаются метки, которые способны двигаться по сети.

Событие - это срабатывание перехода, когда метки из выхода переходят на вход. Некоторые события могут произойти мгновенно, а некоторые разновременно это зависит от условий системы.

Эти сети подразумевались для работы с моделирование систем с параллельно взаимодействующими компонентами.

Сети Петри можно разделить на несколько видов:

· Временная сеть - это сеть, где каждый переход имеет вес, который определяет задержку - время срабатывания.

· Стохастическая сеть - это такая сеть, где время срабатывания случайная величина.

· Функциональная сеть - это такая сеть, где время срабатывания определяется некоторой функцией.

· Цветная сеть - это такая сеть, где каждая метка имеет определённый тип, который помечается цветом.

· Ингибиторная сеть - это такая сеть, где есть дуги с запрещающими переходами, если есть метка в соседней позиции.

· Иерархическая сеть - это сеть, которая содержит не мгновенные переходы, а вложенные.

Сети Петри имеют особые свойства:

· Число меток в позиции не может быть больше чем определенное число;

· Число меток, которые могут быть в позиции не меньше одного;

· Возможность перехода сети из одного состояния в другое;

· Переход может срабатывать, если есть возможность.

РАЗРАБОТКА КОНЦЕПТУАЛЬНОЙ МОДЕЛИ

При создании СППР в основе лежат подходы, которые характерны для некоторых исследований, таких как принятие решений, извлечение данных, отображение данных, построение систем, которые основаны на связи между человеком и машиной

Всему этому соответствует данная концептуальная модель.

Рисунок 2 - Концептуальная модель СППР

Блоки анализа проблем и принятия решений включают в себя процедуры и методы, позволяющие сформулировать поставленную проблему, с помощью баз данных (БД), моделей (БМ) и знаний (БЗ), проанализировать возможности ее решения и получить результат. В СППР включаются также средства для извлечения данных и знаний, построения моделей и манипулирования ими.

В данной работе используется СППР на основе нечеткого вывода.

СТРУКТУРА БАЗЫ ЗНАНИЙ И ПРАВИЛА

Нечеткий вывод занимает центральное место в нечеткой логике и системах нечеткого управления. Процесс нечеткого вывода представляет собой некоторую процедуру или алгоритм получения нечетких заключений на основе нечетких условий или предпосылок с использованием рассмотренных выше понятий нечеткой логики. Этот процесс соединяет в себе все основные концепции теории нечетких множеств: функции принадлежности, лингвистические переменные, нечеткие логические операции, методы нечеткой импликации и нечеткой композиции.

Системы нечеткого вывода предназначены для преобразования значений входных переменных процесса управления в выходные переменные на основе использования нечетких правил продукций. Для этого системы нечеткого вывода должны содержать базу правил нечетких продукций и реализовывать нечеткий вывод заключений на основе посылок или условий, представленных в форме нечетких лингвистических высказываний. Нечетким лингвистическим высказыванием считаются высказывания следующих видов:

1. Высказывание "в есть б", где (в - наименование лингвистической переменной, б - ее значение, которому соответствует отдельный лингвистический терм из базового терм-множества Т лингвистической переменной в.)

2. Высказывание "в есть б", где - модификатор, соответствующий таким словам, как: "ОЧЕНЬ", "БОЛЕЕ ИЛИ МЕНЕЕ", "МНОГО БОЛЬШЕ" и другим, которые могут быть получены с использованием процедур данной лингвистической переменной.

3. Составные высказывания, образованные из высказываний видов 1 и 2 и нечетких логических операций в форме связок: "И", "ИЛИ", "ЕСЛИ-ТО", "НЕ".

База правил

Если при сканировании сети обнаружены отказ порта, то перезапустить службу, отвечающую за этот порт.

Если при передаче файлов обнаружен отказ порта, то перезапустить службу, отвечающую за этот порт.

Если при передаче файла процент ошибки больше 5%, то снизить нагрузку.

Если при сканировании порта TCP результат открыт или соединение принято, то можно передавать или принимать файл.

Если при сканировании порта TCP результат закрыто, запрещено или не слушает, то передавать или принимать файлы запрещено.

Если при сканировании порта TCP результат заблокирован, отфильтрован, то от хоста не поступило ответа, воспользуйтесь другим.

Если пришел запрос на протокол HTTP то, послать ответ.

Если при отправке запроса не пришел результат, то послать повторно.

РАЗРАБОТКА СТРУКТУРЫ АГЕНТОВ СППР НА БАЗЕ СЕТЕЙ ПЕТРИ

А1-агент интерфейса (программный). Агент контроля используется для организации взаимодействия пользователя и системы. К функциям, реализуемым этим агентом, относятся: управление объектами системы; отображение данных мониторинга; представление пользователю отчетов по анализу данных моделирования, выработанных рекомендациях. В рамках взаимодействия с пользователем агент администрирования формирует задачи и передает им на выполнение другим агентам.

А2-агент администрирования (интеллектуальный). Его функцией является выработка комплекса организационно-технических мер, направленных на устранение отказов в сети или оптимизацию ее работы на основании данных мониторинга, моделирования, а также знаний заложенных в системе экспертами.

Рисунок 3 - Архитектура агента администрирования системы

А3-агент отчета (программный). В задачи агента формирования отчетов входит подготовка отчетов на основании данных, полученных от агентов хранения данных и агента поиска решения.

Рисунок 4 - Архитектура агента формирования отчетов

А4-агент хранения данных (программный). Агент хранения данных используется для хранения и предоставления по запросу результатов мониторинга контролируемых параметров элементов сети, учетных записей пользователей, списка объектов управления. Для повышения надежности и гибкости данный агент может реализовывать доступ к нескольким базам данных.

Рисунок 5 - Архитектура агента хранения данных

А5-агент мониторинга (программный). К задачам агента обнаружения относятся: сбор и контроль значений наблюдаемых параметров элементов сети; оповещение об отклонениях наблюдаемых параметров; передача управляющих воздействий на элемент сети. Собранные данные передаются агентам хранения данных.

Рисунок 6 - Архитектура агента мониторинга

РАЗРАБОТКА МОДЕЛИ МНОГОАГЕНТНОЙ СИСТЕМЫ НА БАЗЕ СЕТЕЙ ПЕТРИ

корпоративный сеть тестирование петри

Схема многоагентной системы на базе сетей Петри представлена на рисунке 7. Стоит отметить, что при создании системы агенты и связанные с ними подсистемы представлены одной позицией.

Рисунок 7 - Схема многоагентной системы на основе сетей Петри

Р1, Р2 - лицо принимающее решение.

Р3, Р4 - агент интерфейса.

Р17, Р18 - агент формирования отчетов.

Р19, Р20 - агент хранения данных.

Р13, Р14 - агент мониторинга.

Р15, Р16 - локально вычислительная сеть.

Р7 - Р12 - база правил.

Р5, Р6 - агент администрирования.

Р21-Р25 -база данных.

Т1 - ЛПР передает ответ ЛВС или запрос на отчет.

Т2 - ЛПР принимает сигнал от ЛВС или отчет.

Т3, Т17 - данные об отчете.

Т4, Т16 - запрос на отчет.

Т5, Т13 - ответ на запрос от ЛВС.

Т6, Т14 - запрос от ЛВС.

Т7 - передача данных.

Т8 - запрос на данные.

Т9, Т10, Т11, Т12 - база правил.

Т15, Т19-Т21 - база знаний.

Т18 - данные из ЛВС.

ИССЛЕДОВАНИЕ МОДЕЛИ МНОГОАГЕНТНОЙ СИСТЕМЫ

Опыт 1. В ходе работы было принято решение улучшить схему путем ускорения передачи сигнала от ЛПР к агенту мониторинга.

Рисунок 8 - Схема многоагентной системы на основе сетей Петри

Р1, Р6 - лицо принимающее решение.

Р3, Р4 - агент интерфейса.

Р2, Р5 - агент формирования отчетов.

Р7, Р8 - агент хранения данных.

Р23, Р24 - агент мониторинга.

Р25, Р26 - локально вычислительная сеть.

Р15 - Р20 - база правил.

Р21, Р22 - агент администрирования.

Р9-Р14 -база данных.

Т1 - ЛПР передает ответ ЛВС или запрос на отчет.

Т4 - ЛПР принимает сигнал от ЛВС или отчет.

Т2, Т5 - данные об отчете.

Т3, Т6 - запрос на отчет.

Т7 - передача данных из базы правил.

Т8 - передача данных в базу правил.

Т13 - ответ на запрос от ЛВС.

Т14 - запрос от ЛВС.

Т15-Т18- база правил.

Т9-Т12 - база знаний.

Т18 - данные из ЛВС.

Т19, Т23 - проверка данных через базу правил.

Т20 - данные проверенные через базу правил.

Т21 - отправка данных на хранение в базу знаний.

Т22 - сигнал ЛПР о нарушении базы правил.

Т24 - подача сигнала напрямую от ЛПР к ЛВС.

Данной схеме соответствует таблица, представленная на рисунке 9.

Рисунок 9 - Таблица моделирования сети.

На рисунке 10 представлен результат моделирования, который показывает, что все позиции и метки сработали корректно.

Рисунок 10 - Результат моделирования.

Вывод по опыту. Данное изменение позволит точно знать, сколько ответов и запросов на отчет послал ЛПР. Для моделирования входные позиции увеличили до 10 меток, а в выходные поместили 10 меток. Система работала 30 шагов. Согласно результатам моделирований ЛПР прислал 5 ответов на запрос (Переход Т24) и 5 запросов на отчет (позиция Р5). Через базу правил прошли все 10 меток.

Рисунок 11 - Вывод по опыту.

Опыт 2. Так же было принято решение поставить генераторы на входах и терминаторы на выходах системы для создания и поглощения меток. Это позволило моделировать систему проще.

Рисунок 12 - Схема многоагентной системы на основе сетей Петри

Р1, Р6 - лицо принимающее решение.

Р3, Р4 - агент интерфейса.

Р2, Р5 - агент формирования отчетов.

Р7, Р8 - агент хранения данных.

Р23, Р24 - агент мониторинга.

Р25, Р26 - локально вычислительная сеть.

Р15 - Р20 - база правил.

Р21, Р22 - агент администрирования.

Р9-Р14 -база данных.

Р27, Р28 - генератор сигналов от ЛВС.

Р29, Р30 - терминатор сигналов от ЛПР.

Р31, Р32 - терминатор сигналов от ЛВС

Р33, Р34 - генератор сигналов от ЛПР.

Т1 - ЛПР передает ответ ЛВС или запрос на отчет.

Т4 - ЛПР принимает сигнал от ЛВС или отчет.

Т2, Т5 - данные об отчете.

Т3, Т6 - запрос на отчет.

Т7 - передача данных из базы правил.

Т8 - передача данных в базу правил.

Т13 - ответ на запрос от ЛВС.

Т14 - запрос от ЛВС.

Т15-Т18- база правил.

Т9-Т12 - база знаний.

Т18 - данные из ЛВС.

Т19, Т23 - проверка данных через базу правил.

Т20 - данные проверенные через базу правил.

Т21 - отправка данных на хранение в базу знаний.

Т22 - сигнал ЛПР о нарушении базы правил.

Т24 - подача сигнала напрямую от ЛПР к ЛВС.

Данной схеме соответствует таблица, представленная на рисунке 13.

Рисунок 13 - Таблица моделирования сети.

На рисунке 14 представлен результат моделирования, который показывает, что все позиции и метки сработали корректно.

Рисунок 14 - Результат моделирования.

Вывод по опыту. Благодаря улучшению схемы, мы не может контролировать количество поступивших меток, это симулирует реальную ситуацию. Система может работать бесконечно, так как сигналы продолжат появляться на генераторах и поглощаться на терминаторах. За время работы системы в 50 шагов на генераторе запросов ЛПР было создано 26 меток (позиция Р1), 9 из которых пошли на запрос на отчет (позиция Р5) и 16 на ответ ЛВС.

Рисунок 15 - Вывод по опыту.

Опыт 3. Для улучшения схемы была переделана база правил. Была создана позиция накопитель и позиция счетчик, а так же переход который срабатывал только когда приходил сигнал от ЛПР.

Рисунок 16 - Схема многоагентной системы на основе сетей Петри

Р3, Р10 - лицо принимающее решение.

Р7, Р4 - агент интерфейса.

Р6, Р5 - агент формирования отчетов.

Р13- агент хранения данных.

Р21, Р22 - агент мониторинга.

Р23, Р24 - локально вычислительная сеть.

Р15 - Р20 - база правил.

Р14, Р29 - агент администрирования.

Р11, Р12 -база данных.

Р27, Р28 - генератор сигналов от ЛВС.

Р25, Р26 - терминатор сигналов от ЛПР.

Р1, Р2 - терминатор сигналов от ЛВС

Р8, Р9 - генератор сигналов от ЛПР.

Т12 - ЛПР передает ответ ЛВС или запрос на отчет.

Т3 - ЛПР принимает сигнал от ЛВС или отчет.

Т4- данные об отчете.

Т14- запрос на отчет.

Т26 - передача данных из базы правил.

Т24 - передача данных в базу правил.

Т18 - ответ на запрос от ЛВС.

Т19 - запрос от ЛВС.

Т6-Т9- база правил.

Т15, Т16- база знаний.

Т25 - данные из ЛВС.

Т24- проверка данных через базу правил.

Т26 - данные проверенные через базу правил.

Т17 - отправка данных на хранение в базу знаний.

Т27 - сигнал ЛПР о нарушении базы правил.

Т13 - подача сигнала напрямую от ЛПР к ЛВС.

Т5 - запрос на отчет.

Данной схеме соответствует таблица, представленная на рисунке 17.

Рисунок 17 - Таблица моделирования сети.

На рисунке 18 представлен результат моделирования, который показывает, что все позиции и метки сработали корректно.

Рисунок 18 - Результат моделирования.

Вывод по опыту. За 50 шагов было сгенерировано 25 сигналов из ЛВС, все из которых сохранились в базу для отчета.

Опыт 4. Для улучшения работы базы правил ее усовершенствовали до следующего вида.

Рисунок 19 - Схема многоагентной системы на основе сетей Петри

Р1-Р4 - генератор правил разного вида.

Р5-Р8 - генератор сигналов от ЛВС.

Р9 - выбор правила.

Р10 - выбор сигнала.

Р15, Р16 - выход сигналов разных видов.

Р11-Р14 - терминаторы сигналов.

Т1-Т4 - генератор правил.

Т5-Т8 - генератор сигналов от ЛВС.

Т13, Т14 - проверка совпадения сигнала и правила.

Т9-Т12 - терминатор.

Данной схеме соответствует таблица, представленная на рисунке 20.

Рисунок 20 - Таблица моделирования сети.

На рисунке 21 представлен результат моделирования, который показывает, что все позиции и метки сработали корректно.

Рисунок 21 - Результат моделирования.

Вывод по опыту. Каждый из генераторов создал по 26 сигналов, который пришли на позиции проверки. Там сигналы с разных позиций смогли пройти переходы. В результате на каждую позицию прибыло по 25 сигналов.

Рисунок 22 - Вывод по опыту.

Опыт 5. Так как правила постоянно изменяются, база правил должна обновляться.

Рисунок 23 - Схема многоагентной системы на основе сетей Петри

Р3, Р10 - лицо принимающее решение.

Р7, Р4 - агент интерфейса.

Р6, Р5 - агент формирования отчетов.

Р13- агент хранения данных.

Р21, Р22 - агент мониторинга.

Р23, Р24 - локально вычислительная сеть.

Р15 - Р20 - база правил.

Р14, Р29 - агент администрирования.

Р11, Р12 -база данных.

Р27, Р28 - генератор сигналов от ЛВС.

Р25, Р26 - терминатор сигналов от ЛПР.

Р1, Р2 - терминатор сигналов от ЛВС

Р8, Р9 - генератор сигналов от ЛПР.

Р30 - генератор правил.

Р31 - счетчик добавленных правил.

Т12 - ЛПР передает ответ ЛВС или запрос на отчет.

Т3 - ЛПР принимает сигнал от ЛВС или отчет.

Т4- данные об отчете.

Т14- запрос на отчет.

Т26 - передача данных из базы правил.

Т24 - передача данных в базу правил.

Т18 - ответ на запрос от ЛВС.

Т19 - запрос от ЛВС.

Т6-Т9- база правил.

Т15, Т16- база знаний.

Т25 - данные из ЛВС.

Т24- проверка данных через базу правил.

Т26 - данные проверенные через базу правил.

Т17 - отправка данных на хранение в базу знаний.

Т27 - сигнал ЛПР о нарушении базы правил.

Т13 - подача сигнала напрямую от ЛПР к ЛВС.

Т5 - запрос на отчет.

Т28 - контролирует периодичность добавления новых правил.

Данной схеме соответствует таблица, представленная на рисунке 24.

Рисунок 24 - Таблица моделирования сети.

На рисунке 25 представлен результат моделирования, который показывает, что все позиции и метки сработали корректно.

Рисунок 25 - Результат моделирования.

Вывод по опыту. За 50 шагов база правил обновилась 24 раза (позиций Р31) и возможных 40, которые были заложены в начальную позицию (позиция Р30). Вся остальная программа работала корректно.

Рисунок 26 - Вывод по опыту.

Опыт 6. Для удобства хранения была расширена база данных.

Рисунок 27 - Схема многоагентной системы на основе сетей Петри

Р3, Р10 - лицо принимающее решение.

Р7, Р4 - агент интерфейса.

Р6, Р5 - агент формирования отчетов.

Р13- агент хранения данных.

Р21, Р22 - агент мониторинга.

Р23, Р24 - локально вычислительная сеть.

Р15 - Р20 - база правил.

Р14, Р29 - агент администрирования.

Р11, Р12 -база данных 1.

Р27, Р28 - генератор сигналов от ЛВС.

Р25, Р26 - терминатор сигналов от ЛПР.

Р1, Р2 - терминатор сигналов от ЛВС

Р8, Р9 - генератор сигналов от ЛПР.

Р30, Р31 - база данных 2.

Т12 - ЛПР передает ответ ЛВС или запрос на отчет.

Т3 - ЛПР принимает сигнал от ЛВС или отчет.

Т4- данные об отчете.

Т14- запрос на отчет.

Т26 - передача данных из базы правил.

Т24 - передача данных в базу правил.

Т18 - ответ на запрос от ЛВС.

Т19 - запрос от ЛВС.

Т6-Т9- база правил.

Т15, Т16- база данных 1.

Т25 - данные из ЛВС.

Т24- проверка данных через базу правил.

Т26 - данные проверенные через базу правил.

Т17 - отправка данных на хранение в базу знаний.

Т27 - сигнал ЛПР о нарушении базы правил.

Т13 - подача сигнала напрямую от ЛПР к ЛВС.

Т5 - запрос на отчет.

Т28 - база данных 2.

Данной схеме соответствует таблица, представленная на рисунке 28.

Рисунок 28 - Таблица моделирования сети.

На рисунке 29 представлен результат моделирования, который показывает, что все позиции и метки сработали корректно.

Рисунок 29 - Результат моделирования

Вывод по опыту. За 50 шагов ЛВС подала 25 сигналов. В каждую из баз данных пошло по 12 сигналов (позиции Р26 и Р28).

Рисунок 30 - Вывод по опыту

РАЗРАБОТКА МЕТОДИКИ ТЕСТИРОВАНИЯ

Хотя обычно тестирование рассматривают в качестве заключительной фазы процесса разработки, тестирования СППР включается в каждую стадию. Разработка и тестирование должны выполняться параллельно. По аналогии с технологией тестирования традиционных программных систем можно интерпретировать процесс верификации (логического тестирования) как альфа-тестирование программной системы, а концептуальное тестирование - как этап бета-тестирования, хотя тестирование СППР принципиально отличается от тестирования традиционных систем. В то время как достаточно строгие предварительные спецификации традиционной системы позволяют программисту осуществлять эти работы (в особенности верификацию системы) самостоятельно, для тестирования СППР необходимо привлекать эксперта в данной предметной области.

Специалисты выделяют три аспекта тестирования экспертных систем:

· тестирование исходных данных;

· логическое тестирование базы знаний;

· концептуальное тестирование прикладной системы.

Тестирование исходных данных включает проверку фактографической информации, служащей основой для проведения экспертизы. Очевидно, что наборы данных, используемых при тестировании, должны покрывать область возможных ситуаций, распознаваемых экспертной системой.

Логическое тестирование базы знаний заключается в обнаружении логических ошибок в системе продукций, не зависящих от предметной области, таких, как избыточные, циклические и конфликтные правила; пропущенные и пересекающиеся правила; несогласуемые и терминальные клаузы (несогласуемые условия). Формальный характер этих ошибок позволяет автоматизировать процесс логического тестирования. Существует большое количество инструментальных средств для верификации наборов правил и базы знаний в целом. Однако в ряде случаев, когда цепочки правил, используемых в процессе вывода, небольшие (от 3 до 10 правил), целесообразно проводить процесс верификации вручную.

Концептуальное тестирование проводится для проверки общей структуры системы и учета в ней всех аспектов решаемой задачи. На этом этапе проведение тестирования невозможно без привлечения конечных пользователей прикладной системы.

При тестировании системы было выявлено, что при обрыве связи с ЛВС, сигналы не будут проходить через базу правил и сохраняться в базе данных, а так же не будут приходить к ЛПР. Но ЛПР будет пытаться доставить сигнал до ЛВС.

При обрыве связи с ЛПР, сигналы от ЛВС будут проходить сохраняться в базе знаний, но не будут доставлены к ЛПР в виде отчета. А так же не будет ответа от ЛПР на нарушение базы правил.

При сбое в работе базы правил, система не сможет проверять сигналы и отправлять их на хранение в базу знаний, а так же не сможет сообщить ЛПР о нарушении базы правил.

АНАЛИЗ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ

При исследовании полученной системы было выявлено, что при исправлении схемы, когда ЛПР напрямую передает данные к ЛВС, Система работает быстрее и точнее.

Рисунок 31 - График ЛВС на выходе

При внедрении в систему генераторов и терминаторов появилась возможность подавать неравномерно поступающие сигналы в неограниченном количестве.

Рисунок 32 - ЛВС на входе

При работе со стандартной базой сигналы проходили через нее. При улучшении базы данных Данные начали накапливаться в позиции. Для вывода данных был создан переход. Когда сигнал от ЛПР приходит на переход и одновременно с ним в базе данных присутствует информация, то переход срабатывает, а данные отчета отправляются к ЛПР. Все данные проходят через позицию - счетчик запросов, которая покажет количество запросов на отчеты, которые поступили от ЛПР. Графики загруженности покажут время пополнения базы знаний и извлечения данных для отчетов.

Рисунок 33 - График загруженности базы данных

Рисунок 34 - График загруженности позиции - счетчика количества отчетов

Так как системе свойственно меняться, она должна уметь добавлять или изменять правила. База обновляется неравномерно. В схеме предусмотрена позиция - счетчик, которая покажет количество обновлений базы правил. График нагрузки покажет время срабатывания обновлений.

Рисунок 35 - График загруженности позиции - счетчика поступивших правил

РАЗРАБОТКА МЕТОДИЧЕСКИХ УКАЗАНИЙ ПО РАБОТЕ С СППР

Разработка СППР имеет существенные отличия от разработки обычного программного продукта. Опыт создания СППР показал, что использование при их разработке методологии, принятой в традиционном программировании, либо чрезмерно затягивает процесс создания, либо вообще приводит к отрицательному результату.

При разработке СППР нужно первым делом изучит область применения и назначение системы. Проанализировать уже существующие решения данной проблемы. Выбрать более подходящий для себя метод. В данной работе была выбрана СППР на основе метода нечеткого вывода. В ходе создания СППР нужно выделить конкретные параметры и требования к системе. Нужно решить какие функции должна выполнять система. Данная СППР должна анализировать ЛВС, искать нарушения через базу правил, сохранять данные в базу данных, давать отчеты по требованию ЛПР, а также быть удобной в использовании. На основе данных функций можно выбрать агентов, которые могут потребоваться в вашей системе. В данной работе было выбрано пять видов агентов:

· агент интерфейса;

· агент администрирования;

· агент формирования отчетов;

· агент хранения данных;

· агент мониторинга.

После этого можно выбрать контролируемые параметры и разработать базу правил.

На основе всего этого нужно разработать структуру каждого агента и соединить всех агентов в единую систему.

Создать систему на основе сетей Петри можно с помощью программы MCYcP.exe. при открытии программы выйдет окно, которое позволяет выбрать режим ввода информации.

Рисунок 36 - Режим выбора работы программы

Для больших схем рекомендуется выбрать графический интерфейс.

В программе для создания позиций, переходов и связей нужно воспользоваться кнопками на панели инструментов. После создания схемы нужно дать имя всем переходам и позициям. Для этого на панели выбрать клавишу авто имя.

Для перехода на сети Петри каждый агент заменяется на 2 позиции: входную и выходную. Базы данных буду выглядеть как на рисунке.

Рисунок 37 - Представление базы данных

Для улучшения схемы для создания сигналов, которые идут от ЛПР или из внешней среды, можно добавить генераторы, которые в сети Петри выглядят так.

Рисунок 38 - Генератор сигналов

Для поглощения сигналов от ЛПР или из системы можно добавить терминаторов, которые выглядят так.

Рисунок 39 - Терминатор сигналов

После завершения создания схемы нужно провести тестирование. Для этого нужно нажать на клавишу таблицы и начать моделирование. После сохранения файла с начальными данными в текстовом формате, нужно открыть моделирование и выбрать нужное количество шагов.

В программе можно наглядно посмотреть движение меток по позициям.

Рисунок 40 - Движение меток в позициях

А так же можно посмотреть статистику по позициям, которая покажет, какие сработали позиции, максимальное количество меток в позиции, всего меток в позиции.

Рисунок 41 - Статистика по позициям

В программе можно посмотреть статистику по переходам, которая покажет, какие переходы сработали, максимальное количество срабатываний.

Рисунок 42 - Статистика по переходам

С помощью изменения параметров позиций и переходов можно изменять время срабатывания, а так же изменять схему.

ЗАКЛЮЧЕНИЕ

На данное время нет явно выделенного лидера в области построения СППР. Ни одна из фирм не может создать готовую программу, которую можно будет сразу использовать на предприятии. Каждую разработанную СППР нужно корректировать относительно среды, в которую ее внедряют. Не существует универсальной СППР даже если ее используют в похожей среде.

Разработка СППР включает в себя анализ всех данных и проектирования структуры предприятия относительно его потребностей и процессов, которые проходят на нем. Анализ предприятия - это очень сложная задача, которая бывает невозможной даже для профессионала. Если читывать размеры информации и ресурсов, которые нужно изучить для создания СППР, очевидно, что есть большой риск ошибки проектирования, которая заставит начинать всю работу сначала. Это приведет к высоким затратам на производство, а так же увеличит время потраченное на создание СППР. В ходе работы была разработана структура СППР для корпоративной сети, которая точно подчеркивала все процессы, проходящие в сети. На основе структуры была разработана схема, которая позволят моделировать ситуации, которые реально происходят каждый день в сети. Создание СППР позволило решить проблему, которая связана с человеческим фактором и предоставляет ЛПР решение, на основе которого пользователь тратит меньше времени на анализ существующей информации. В данной работе были разработаны модели работы СППР в разных ситуациях. На основе разработанных структур, были искусственно созданы ситуации, для моделирования реальной жизни. Данная СППР способна давать быстрое решение пользователю, на основе полной и оперативной информации, а так же давать отчет о состоянии системы в целом. Система автоматизировала поиск по базе правил и предоставляла ЛПР решение.

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Леохин, Ю.Л. Архитектура современных систем управления корпоративными сетями / Ю.Л. Леохин // «Качество. Инновации. Образование». - 2009. - №2. С.54-63

2. Данилюк, Ю.С. Система автоматического управления корпоративными вычислительными сетями / Ю.С. Данилюк, Ф.А. Попов // «Ползуновский вестник». - 2006. - №2. С.51-55

3. Леохин Ю.Л. Научные основы управления корпоративными вычислительными сетями: дис, … докт.техн. наук: 05.13.13/ Ю.Л. Леохин. - М., 2009. -334 с.

4. Ямалов И. У. Моделирование процессов управления и принятия решений в условиях чрезвычайных ситуаций / М.: Лаборатория базовых знаний, 2007. -273 с.

5. Рагозин Ю.Н. Информационная безопасность корпоративных ЛВС - проблема выбора оптимального решения. / Вестник академии промышленности и менеджмента. Выпуск 5. Москва 2006 г.

6. Рагозин Ю.Н. Принципы выбора и вербальной оценки компромиссных решений в системах комплексной защиты информации/ Безопасность информационных технологий. №1, Москва, МИФИ, ВНИИПВТИ, 2007 г.

7. Мясников Д. М. Многоагентный подход к разработке распределённой системы хранения данных//«Системы управления и информационные технологии» 2009. -№4(38). - с.59-62

8. Мясников Д. М., Суконщиков А.А. Разработка мультиагентной системы хранения данных //«Информационные технологии моделирования и управления» 2009.- №1. с. 133-139.

9. Мясников Д.М., Суконщиков А.А. Применение многоагентного подхода и пороговых схем к разработке систем хранения данных//«Информатизация процессов формирования открытых систем на основе СУБД, САПР, АСНИ и систем искусственного интеллекта: Мат. 5 МНТК.» - Вологда: ВоГТУ, 2009. -с. 195-200.

10. Голубков В.М., Методика построения распределенной многоагентной системы резервирования данных с применением СППР. [Текст] / Голубков В.М. // Материалы V Ежегодной научной сессии аспирантов и молодых ученых по отраслям наук - Вологда: ВоГТУ, 2011.- С.44-48.

11. Голубков В.М., Модернизированная многоагентная отказоустойчивая система резервирования данных [Текст] / Голубков В.М. // Информатизация процессов формирования открытых систем на основе СУБД, САПР, АСНИ и систем искусственного интеллекта (ИНФОС - 2011): Мат. 6-й межд. научн-техн. Конф. - Вологда: ВоГТУ, 2011.-т.1.- С.52-56.

Размещено на Allbest.ru


Подобные документы

  • Классификация систем поддержки принятия решений. Сравнительный анализ методик для оценки рисков розничного кредитования. Структура системы поддержки принятия решений, формирование начальной базы знаний. Проектирование базы данных информационной системы.

    дипломная работа [1,9 M], добавлен 10.07.2017

  • Основные модели представления знаний. Системы поддержки принятия решений. Диаграмма UseCase. Разработка базы данных на основе трех моделей: продукционные правила, семантическая сеть, фреймовая модель. Программная реализация системы принятия решений.

    курсовая работа [715,1 K], добавлен 14.05.2014

  • Обслуживание двух встречных потоков информации. Структура информационных систем. Разработка структуры базы данных. Режимы работы с базами данных. Четыре основных компонента системы поддержки принятия решений. Выбор системы управления баз данных.

    курсовая работа [772,0 K], добавлен 21.04.2016

  • Сущность системы поддержки принятия управленческих решений. Функции корпоративной системы SAP R3, выполнение регрессионного анализа в табличном процессоре Excel, создание в Access базы данных. Характеристика информационных служб в сети Интернет.

    контрольная работа [2,0 M], добавлен 18.02.2011

  • Концепция систем поддержки принятия решений. Диапазон применения Analytica 2.0. Программное обеспечение количественного моделирования. Графический интерфейс для разработки модели. Основные способы моделирования. Диаграмма влияния и дерево решений.

    контрольная работа [1,1 M], добавлен 08.09.2011

  • Методы решения проблем, возникающих на стадиях и этапах процесса принятия решений, их реализация в информационных системах поддержки принятия решений (СППР). Назначение СППР, история их эволюции и характеристика. Основные типы СППР, области их применения.

    реферат [389,3 K], добавлен 22.11.2016

  • Разработка алгоритмического и программного обеспечения для решения задачи поддержки принятия решений о выпуске новой продукции. Математическое обеспечение задачи поддержки принятия решений о выпуске новой продукции, основные входные и выходные данные.

    дипломная работа [943,0 K], добавлен 08.03.2011

  • Типы административных информационных систем: системы генерации отчетов, системы поддержки принятия решений, системы поддержки принятия стратегических решений. Сортировка и фильтрация списков в Microsoft Excel. Работа с базами данных в Microsoft Access.

    контрольная работа [6,0 M], добавлен 19.11.2009

  • Разработка и внедрение программного модуля поддержки принятия управленческих решений для информационной системы медицинского предприятия ООО "Центр эндохирургических технологий". Эффективность применения модуля, полученные с его помощью результаты.

    дипломная работа [1,9 M], добавлен 11.04.2013

  • Теоретические аспекты функционирования Business intelligence - систем в сфере логистики. Анализ условий для разработки системы поддержки принятия решений. Характеристика процесса создания программного продукта, применение аналитической платформы QlikView.

    курсовая работа [2,5 M], добавлен 09.09.2017

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.