<< Пред. стр. 1 (из 4) След. >>
Список литературы по разделу
Министерство образования Российской Федерации
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
им. Н.Э. БАУМАНА
Факультет "Информатика и системы управления"
Кафедра "Компьютерные системы и сети"
РАСЧЁТНО-ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к квалификационной работе бакалавра на тему:
БАЗА ЗНАНИЙ ПРЕДПРИЯТИЙ
Студент (Ганецкий М.А.)
Руководитель работы (Пугачёв Е.К.)
Консультант по конструкторской части (Пугачёв Е.К.)
Консультант по технологической части (Пугачёв Е.К.)
2002
АННОТАЦИЯ
В настоящей квалификационной работе разработана база знаний предприятий, являющаяся модулем управляющей гибридной экспертной системы распределения заказа. Разработана модель знаний, реализованы функции системы, выполнено технико-экономическое обоснование принятых решений.
THE SUMMARY
This work deals with develop of enterprises knowledgebase, which is part of order distribution hybrid expert system. Knowledge model is developed, program functions are realized, economic and technical basis is grounded.
РЕФЕРАТ
РПЗ 60 с., 35 рис., 7 ист., 2 прил.
БАЗА ЗНАНИЙ, ПРОГРАММИРОВАНИЕ, ЭКСПЕРТНАЯ СИСТЕМА, ФАКТ, КЛИЕНТ, СЕРВЕР
Цель квалификационной работы - база знаний предприятий, работающая в составе управляющей гибридной экспертной системы распределения заказа.
Для достижения цели были сформулированы следующие задачи:
Выбор модели знаний применительно к исследуемой предметной области;
Разработка модели знаний;
Разработка системы с помощью современного инструментального средства;
Обеспечение возможности ввода, коррекции и просмотра фактов;
Обеспечение проверки на полноту знаний;
Обеспечение возможности формирования отчетов.
Для достижения сформулированной цели используются методы технологии разработки программного обеспечения, в частности, методы баз данных, технологии визуального, структурного и объектного программирования.
Результатом работы стала база знаний предприятий, работающая в составе управляющей гибридной экспертной системы распределения заказа и обеспечивающая возможность хранения и модификации знаний о предприятиях, необходимых для работы экспертной системы.
Программный продукт состоит из клиентской и серверной частей, которые могут выполняться либо на одной машине, либо на разных машинах, взаимодействуя через сеть.
СОДЕРЖАНИЕ
ВВЕДЕНИЕ 5
I. ИССЛЕДОВАТЕЛЬСКАЯ ЧАСТЬ 6
1. АНАЛИЗ МЕТОДОВ РЕШЕНИЯ ЗАДАЧИ 6
2. ВЫБОР МОДЕЛИ ЗНАНИЙ ПРИМЕНИТЕЛЬНО К ИССЛЕДУЕМОЙ ПРЕДМЕТНОЙ ОБЛАСТИ 7
II. КОНСТРУКТОРСКАЯ ЧАСТЬ 9
1. РАЗРАБОТКА МОДЕЛИ ЗНАНИЙ 9
2. РАЗРАБОТКА ИНТЕРФЕЙСА СИСТЕМЫ 14
3. РАЗРАБОТКА ФУНКЦИЙ ОБРАБОТКИ ФАКТОВ 20
4. РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММНОГО ПРОДУКТА 26
5. РАЗРАБОТКА СЕРВЕРНОЙ ЧАСТИ 28
6. РАЗРАБОТКА КЛИЕНТСКОЙ ЧАСТИ 34
III. ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ 41
1. РАЗРАБОТКА ТЕСТОВ И ТЕСТОВЫХ ПРОГРАММ 41
IV. ЭКОНОМИЧЕСКАЯ ЧАСТЬ 49
1. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРИНЯТЫХ РЕШЕНИЙ 49
ЗАКЛЮЧЕНИЕ 51
СПИСОК ЛИТЕРАТУРЫ 52
ПРИЛОЖЕНИЕ 1. 53
РУКОВОДСТВО СИСТЕМНОГО АДМИНИСТРАТОРА 53
ПРИЛОЖЕНИЕ 2. 55
РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ 55
ВВЕДЕНИЕ
Программное обеспечение разрабатывается в рамках НИР НУК ИУ № работы 06.01.116 на основе данных, указанных в техническом задании.
Целью работы является программное обеспечение "База знаний предприятий", предназначенное для хранения и модификации базы знаний, необходимых для работы управляющей гибридной экспертной системы (ГЭС) распределения заказа.
Актуальность темы работы обусловлена тем, что в настоящее время отсутствуют завершенные средства, обеспечивающие решение сформулированной проблемы.
Вопросы оптимального распределения изделий специального назначения для их изготовления на предприятиях оборонного комплекса решаются в настоящее время экспертами. Количество предприятий, обеспечивающих изготовление специзделий, исчисляется десятками. Каждое изделие в плане его изготовления должно обладать набором своих уникальных свойств. В свою очередь, каждое предприятие имеет свою специфику и возможности: материальную базу, кадры, экономику, временные ресурсы и другие с точки зрения изготовления тех или иных специзделий. Ряд предприятий не имеет возможности изготовить ряд специзделий по разным причинам. Таким образом, формулируется проблема рационального распределения заказа специзделий на указанных предприятиях с учетом ряда ограничений. Обязательное требование - каждое изделие должно быть распределено.
Указанная проблема может быть решена только разработкой соответствующих специализированных средств, способных обрабатывать информацию в форме знаний.
В процессе разработки программного обеспечения решались следующие задачи: разработка модели знаний, разработка интерфейса системы, разработка функций обработки фактов, разработка структуры программного продукта, разработка алгоритмов программы, разработка тестов и тестовых программ.
I.
ИССЛЕДОВАТЕЛЬСКАЯ ЧАСТЬ
1. АНАЛИЗ МЕТОДОВ РЕШЕНИЯ ЗАДАЧИ
Результатом работы должна стать база знаний предприятий, являющаяся модулем управляющей гибридной экспертной системы распределения заказа (ГЭС). Структура ГЭС представлена на рис.1.
Рис. 1. Структура ГЭС.
В связи с необходимостью взаимодействия модуля базы знаний предприятий с другими модулями ГЭС, каждый из которых имеет сложную структуру и может требовать значительные ресурсы для своей работы, целесообразно иметь возможность размещать модуль базы знаний предприятий на отдельной вычислительной машине. Для достижения этих целей следует воспользоваться получившими широкое распространение и хорошо разработанными технологиями сетевых реляционных баз данных, так как, с одной стороны, они позволяют быстро реализовать многие функции, требуемые от разрабатываемого программного продукта, а с другой стороны позволят другим модулям экспертной системы взаимодействовать с разрабатываемым модулем. Такой подход обеспечивает ускорение и удешевление разработки, а также предоставляет большую гибкость по сравнению с размещением базы на локальной машине.
2. ВЫБОР МОДЕЛИ ЗНАНИЙ ПРИМЕНИТЕЛЬНО К ИССЛЕДУЕМОЙ ПРЕДМЕТНОЙ ОБЛАСТИ
В системах, основанных на знаниях, правила (или эвристики), по которым решаются проблемы в конкретной предметной области, хранятся в базе знаний /1/. Проблемы ставятся перед системой в виде совокупности фактов, описывающих некоторую ситуацию, и система с помощью базы знаний пытается вывести заключение из этих фактов. Эвристики представляют собой правила вывода, которые позволяют находить решения по известным фактам. Обобщенная схема функционирования системы, основанной на знаниях, представлена на рис. 2.
Рис. 2. Обобщенная схема функционирования системы, основанной на знаниях.
В общем случае знания в такой системе разделяются на три типа:
1) Декларативные знания (факты).
Этот вид знаний представляет собой факты конкретных ситуаций. Такие факты могут быть описаны заранее и включены в базу знаний на этапе создания экспертной системы (ЭС). К декларативным знаниям можно отнести факты, которые собираются в процессе диалога с пользователем непосредственно во время работы ЭС. Структура представления данного вида информации, а также способы ее обработки (считывание, модификация и т.п.) имеют большое значение для организации всех модулей ЭС.
2) Процедурные знания (правила).
Обычно эти знания собираются заранее путем опроса экспертов в конкретной предметной области и составляют ядро базы знаний. На их основе строится механизм логического вывода. Процедурные знания непосредственно связаны с декларативными, позволяют обрабатывать имеющиеся в базе знаний факты, а при необходимости генерировать новые факты.
3) Управляющие знания.
В ЭС должен быть предусмотрен некоторый набор стратегий, чтобы можно было рассматривать альтернативные возможности получения вывода во время работы, т.е. переходить при неудаче от одной стратегии к другой. Управляющие знания определяют, какие из процедурных правил следует использовать для получения вывода. По существу данные знания составляют основу механизма логического вывода.
Из вышеприведённых определений следует, что наиболее целесообразно оформить данные о предприятиях в виде фактов (декларативных знаний), так как понятие декларативных знаний наиболее полно соответствует требованиям, предъявляемым к программному продукту в техническом задании. Декларативный тип знаний позволяет достичь независимости знаний от применяемого в экспертной системе механизма логического вывода, тем самым не ограничивая разработчика механизма логического вывода в выборе методов реализации поставленной перед ним задачи.
II. КОНСТРУКТОРСКАЯ ЧАСТЬ
1. РАЗРАБОТКА МОДЕЛИ ЗНАНИЙ
В базе должны храниться следующие данные:
Данные о предприятии-исполнителе: название, адрес, телефон, специальный режим, материальная база, экономические показатели.
Данные об изделии: размеры, вид сборки, производственные ресурсы, стандартные решения.
Такие данные о предприятии-исполнителе, как название, адрес и телефон, следует поместить в одну таблицу, так как для каждого предприятия будет храниться по одному экземпляру данных такого типа. Кроме того, в таблицу следует добавить поле комментария о предприятии. Каждое предприятие характеризуется также уникальным ключом.
Экономические показатели следует вынести в отдельную таблицу, так как у одного предприятия может быть много экономических показателей. Каждый показатель характеризуется уникальным номером и двумя целочисленными значениями. Также в таблицу добавлено поле комментария для внесения заметок о показателе. Эта таблица по указанной выше причине связана с таблицей предприятий отношением "один ко многим".
Показатели материальной базы также выносятся в отдельную таблицу, так как у предприятия может быть много показателей материальной базы, причём их точное количество не определено. Каждый показатель характеризуется уникальным номером и двумя целочисленными значениями. Также для большей гибкости в таблицу введено поле комментария. Эта таблица также связана с таблицей предприятий отношением "один ко многим".
Такая структура таблиц экономических показателей и материальной базы продиктована соображениями универсализации структуры знаний. Эти таблицы могут обновляться, например, посредника, в базе данных которого устанавливается соответствие между хранящимися текстовыми описаниями параметров и их уникальными ключами, хранящимися в базе знаний.
Так как на предприятии может быть несколько режимов, то они вынесены в отдельную таблицу. Каждый режим характеризуется уникальным ключом и названием. Также к описанию режима добавлено поле комментария. Таблица режимов, как и описанные выше таблицы, связана с таблицей предприятий отношением "один ко многим".
Также в базе знаний должны содержаться сведения о производящихся предприятием в настоящий момент изделиях и производившихся ранее изделиях. Сведения о производившихся ранее изделиях (архив) нужны, например, для того, чтобы иметь возможность оценить, какой опыт в производстве изделий данного типа имеет предприятие.
Сведения о производимых ранее изделиях вынесены в отдельную таблицу, и содержат наименование изделия, количество заказов (в качестве характеристики востребованности изделия), комментарий и уникальный ключ. Эта таблица связана с таблицей предприятий отношением "один ко многим".
Сведения о производящихся в настоящий момент изделиях содержат наименование изделия, вид сборки, дату изготовления изделия, количество заказов изделия. Так как обычно предприятие производит не одно изделие, и точное количество их неизвестно, то сведения о них вынесены в отдельную таблицу, которая связана отношением "один ко многим" с таблицей предприятий.
Каждое производимое изделие также характеризуется размерами и заказчиками.
Сведения о размерах вынесены в отдельную таблицу, так как их может быть разное количество у разных изделий. Они содержат название размера, описание размера, а также его уникальный ключ. Таблица размеров связана с таблицей изделий отношением "один ко многим".
Так как заказчиков изделия может быть много, сведения о них содержатся в отдельной таблице. Они включают: наименование заказчика, адрес заказчика, телефон заказчика, комментарий, а также уникальный ключ заказчика. Эта таблица также связана с таблицей изделий отношением "один ко многим".
Получившаяся модель знаний представлена на рис. 3.
Рис. 3. Модель знаний.
Определим атрибуты каждой из сущностей.
Предприятия:
EntKey - уникальное ключевое поле;
Name - название предприятия;
Address - адрес предприятия;
Phone - телефон предприятия;
Comment - комментарий.
Экономические показатели:
Number - уникальное ключевое поле;
Value1 и Value2 - значения показателя;
Comment - комментарий;
EntKey - ключ предприятия-обладателя показателя.
Материальная база:
Number - уникальное ключевое поле;
Value1 и Value2 - значения показателя;
Comment - комментарий;
EntKey - ключ предприятия-обладателя показателя.
Режимы предприятия:
SecKey - уникальное ключевое поле;
Name - наименование режима;
Comment - комментарий;
EntKey - ключ предприятия-обладателя режима.
Архив:
Number - уникальное ключевое поле;
IzdName - наименование изделия;
KolZak - количество заказов изделия;
Comment - комментарий;
EntKey - ключ предприятия, производившего изделие.
Изделие:
IzdKey - уникальное ключевое поле;
Name - наименование изделия;
Vid_Sb - вид сборки изделия;
EntKey - ключ предприятия, производящего изделие;
IsgDate - дата первого изготовления изделия;
KolZak - количество заказов изделия.
Размеры:
SizeKey - уникальное ключевое поле;
Name - название размера;
Description - описание размера;
IzdKey - ключ изделия, к которому этот размер относится.
Заказчик:
EntKey - уникальный ключ заказчика;
Name - наименование заказчика;
Address - адрес заказчика;
Phone - телефон заказчика;
Comment - комментарий;
IzdKey - ключ заказанного изделия;
Ключом связи таблицы "Предприятия" с таблицами "Экономические показатели", "Материальная база", "Режимы предприятия", "Архив" и "Изделия" является поле EntKey. Ключом связи таблицы "Изделия" с таблицами "Размеры" и "Заказчик" является поле IzdKey.
Такая модель знаний позволяет:
Избежать избыточности;
Уменьшить место, занимаемое базой данных на диске;
Обеспечить простоту реализации;
Воспользоваться при реализации программного продукта стандартными, хорошо разработанными технологиями;
Снизить количество ошибок в программном продукте;
Снизить время разработки;
Снизить стоимость разработки.
2. РАЗРАБОТКА ИНТЕРФЕЙСА СИСТЕМЫ
Интерфейс системы должен соответствовать модели знаний, для того, чтобы пользователю было легче разобраться с системой.
Интерфейс главной формы приложения показан на рис. 4.
Рис. 4. Главная форма приложения.
На форме размещена таблица, в которой отображаются поля таблицы "Предприятия". Такой подход позволяет пользователю просматривать сразу несколько записей. Комментарий отображается в отдельном поле под основной таблицей. Также на форме расположен ряд кнопок, позволяющий перемещаться по данным, подключаться к серверу, отключаться от сервера, проводить изменения данных и печатать отчёты.
Из меню формы можно переходить к просмотру других таблиц, и вызвать функцию проверки базы знаний на полноту. Меню "Таблицы" показано на рис. 5.
Рис. 5. Меню "Таблицы".
Интерфейс формы ввода данных о предприятии показан на рис. 6.
Рис. 6. Форма ввода данных о предприятии (режим добавления новой записи).
На форме помещены поля ввода данных о предприятии: названия, адреса, телефона и комментария. Также здесь помещены кнопки: "Очистить" (очищает все поля ввода), "Добавить" (добавляет данные из полей ввода в базу), "Закрыть" (закрывает форму), "Сохранить".
Кнопка "Сохранить" недоступна в режиме добавления новой записи, а доступна только в режиме редактирования записи (рис. 7).
Рис. 7. Форма ввода данных о предприятии (режим редактирования записи).
При открытии формы в режиме редактирования в поля ввода автоматически заносится содержимое текущей записи. Эти данные можно отредактировать и сохранить в базе при нажатии кнопки "Сохранить". Кнопка "Добавить" в этом режиме недоступна.
Совмещение операций удаления и добавления на одной форме позволяет упростить освоение интерфейса программы пользователем, уменьшить объём кода программы, а, следовательно, занимаемый ею объём памяти.
Интерфейс формы поиска и фильтрации предприятий показан на рис. 8.
Рис. 8. Форма поиска и фильтрации.
Поиск предприятий осуществляется по названию при нажатии кнопки "Поиск". Если предприятие с введённым названием будет найдено, то курсор в таблице предприятий будет установлен на него.
Фильтрация также производится по названию предприятия. Отфильтровать предприятия с нужным названием можно, введя это название, пометив флажок "Фильтровать" и нажав кнопку "Применить". Содержимое, отображаемое в таблице предприятий, изменится, но содержимое набора данных останется прежним. Отказаться от фильтрации можно, сняв флажок "Фильтровать" и нажав кнопку "Применить". Фильтрацию можно проводить и по частично введённому названию предприятия. В этом случае отобразятся все предприятия с названиями, имеющими введённую последовательность символов.
Форма проверки базы знаний на полноту изображена на рис. 9.
Рис. 9. Форма проверки базы знаний на полноту.
Данная форма выводит результаты проверки базы знаний на полноту. Содержимое этой формы определяется структурой модели знаний. Результаты проверки выводятся в двух таблицах: "Предприятия" и "Изделия". Все случаи неполноты выделяются визуально.
На форме присутствуют кнопки:
"Получить статистику", при нажатии которой происходит получение от сервера сведений о количестве записей;
"Анализ статистики", при нажатии которой происходит анализ полученной с сервера статистики и выдаётся заключение о полноте базы знаний;
"Закрыть", при нажатии которой происходит закрытие формы проверки базы знаний на полноту;
"Перейти", при нажатии которых происходит переход на ту запись в таблицах предприятий или изделий, для которой существует неполнота базы знаний.
Содержимое таблицы предприятий можно распечатать. Окно предварительного просмотра отчёта, показанное на рис. 10 вызывается выбором пункта "Отчёт..." в меню "Файл" либо нажатием соответствующей кнопки на панели инструментов.
Рис. 10. Форма предварительного просмотра отчёта о предприятиях.
Из данной формы можно нажатием соответствующих кнопок настроить принтер, отправить отчёт на печать, масштабировать изображение страницы отчёта и перемещаться по страницам отчёта.
Форма отображения данных об экономических показателях изображена на рис. 11.
Рис. 11. Форма, отображающая экономические показатели предприятия.
Функциональность элементов у правления этой и остальных форм аналогична функциональности соответствующих форм, связанных с таблицей предприятий и рассмотренных ранее.
Форма, отображающая режимы предприятия, показана на рис. 12.
Рис. 12. Форма, отображающая режимы предприятия.
Форма, отображающая содержимое таблиц изделий, размеров и заказчиков показана на рис. 13.
Рис. 13. Форма, отображающая содержимое таблиц изделий, размеров и заказчиков.
Объединение средств просмотра трёх таблиц на одной форме избавляет пользователя от необходимости переключаться между формами, позволяя просматривать все сведения об изделии в одном окне.
Из этой формы можно обращаться к функциям редактирования записей об изделиях, их размерах и заказчиках, а также выводить эти сведения на печать.
3. РАЗРАБОТКА ФУНКЦИЙ ОБРАБОТКИ ФАКТОВ
Для того, чтобы обеспечить нормальную работу базы знаний, и чтобы база знаний удовлетворяла требованиям технического задания, необходимо реализовать следующие функции обработки фактов:
Ввод, коррекция и просмотр фактов;
Проверка на полноту знаний;
Поиск по различным ключам;
Сортировка по основному полю;
Формирование отчетов;
Хранение данных в течение длительного периода времени.
3.1. Ввод, коррекция и просмотр фактов.
Ввод, коррекция и просмотр фактов реализуются как серверной, так и клиентской частями системы. При этом клиентская часть реализует интерфейс пользователя, а серверная часть реализует непосредственно работу с базой фактов.
Просмотр осуществляется в клиентской части с помощью соответствующих таблиц, помещённых на формах. Клиентская часть выдаёт серверу запрос, и сервер пересылает необходимые данные.
Данные, которые необходимо ввести, вводятся в специальной форме клиентской части, которая формирует запрос и отправляет их серверу. На сервере выполняется специальная хранимая процедура, которая добавляет данные в базу.
Данные, которые необходимо отредактировать, исправляются в специальной форме клиентской части, которая формирует запрос и отправляет их серверу. Серверная часть записывает изменённые данные на место старых.
Удаление записи производится путём её выбора в таблице клиентской части пользователем. Клиентская часть формирует запрос, и серверная часть удаляет соответствующую запись из базы. После этого данные в таблице клиентской части обновляются. Если с удаляемой записью связаны записи в подчинённых таблицах, происходит автоматическое каскадное удаление этих записей из подчинённых таблиц.
3.2. Проверка на полноту знаний.
Под проверкой на полноту знаний понимается проверка наличия хотя бы одной записи в таблицах, подчинённых таблицам "Предприятия" и "Изделия", для каждой записи из этих двух таблиц. Такая проверка позволяет быстро и просто оценить полноту, так как база знаний очевидно не полна, если отсутствуют какие-либо сведения о предприятиях или изделиях.
По запросу клиентской части серверная часть выдаёт количество связанных записей в подчинённых таблицах для каждой записи главной таблицы. Клиентская часть обрабатывает эти сведения и выводит в удобном виде, а также выдаёт заключение, полна ли база знаний, или нет.
3.3. Поиск по различным ключам.
Поиск по различным ключам осуществляется в клиентской части. По запросу пользователя в текущем наборе данных проводится поиск записи с нужным содержимым.
Виды поиска в программе:
Для таблицы предприятий - по названию предприятия;
Для таблицы экономических показателей - по ключу экономического показателя;
Для таблицы материальной базы предприятия - по ключу показателя материальной базы;
Для таблицы режимов предприятия - по названию режима;
Для таблицы архива заказов - по названию изделия;
<< Пред. стр. 1 (из 4) След. >>
Список литературы по разделу