СОДЕРЖАНИЕ

Министерство образования Российской Федерации
МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
им. Н.Э. БАУМАНА
Факультет "Информатика и системы управления"
Кафедра "Компьютерные системы и сети"








РАСЧЁТНО-ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к квалификационной работе бакалавра на тему:

БАЗА ЗНАНИЙ ПРЕДПРИЯТИЙ




Студент (Ганецкий М.А.)
Руководитель работы (Пугачёв Е.К.)
Консультант по конструкторской части (Пугачёв Е.К.)
Консультант по технологической части (Пугачёв Е.К.)









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. Поиск по различным ключам.

Поиск по различным ключам осуществляется в клиентской части. По запросу пользователя в текущем наборе данных проводится поиск записи с нужным содержимым.
Виды поиска в программе:
­ Для таблицы предприятий - по названию предприятия;
­ Для таблицы экономических показателей - по ключу экономического показателя;
­ Для таблицы материальной базы предприятия - по ключу показателя материальной базы;
­ Для таблицы режимов предприятия - по названию режима;
­ Для таблицы архива заказов - по названию изделия;
­ Для таблицы изделий - по названию изделия;
­ Для таблицы размеров - по названию размера;
­ Для таблицы заказчиков - по названию заказчика.

3.4. Сортировка по основному полю.

В базе данные хранятся в несортированном виде. Сортировка производится в клиентской части при получении ей набора данных.
В программе производятся следующие сортировки:
­ Для таблицы предприятий - по названию предприятия и ключу предприятия;
­ Для таблицы экономических показателей - по ключу экономического показателя;
­ Для таблицы материальной базы предприятия - по ключу показателя материальной базы;
­ Для таблицы режимов предприятия - по названию режима;
­ Для таблицы архива заказов - по названию изделия;
­ Для таблицы изделий - по названию изделия;
­ Для таблицы размеров - по названию размера;
­ Для таблицы заказчиков - по названию заказчика и ключу заказчика.
3.5. Формирование отчётов.

Формирование отчётов производится средствами клиентской части. Всего в программе предусмотрено 9 различных отчётов.
Вид отчёта о предприятиях представлен на рис. 14.
Рис. 14. Отчёт о предприятиях.

Вид отчёта об экономических показателях представлен на рис. 15.
Рис. 15. Отчёт об экономических показателях.

Вид отчёта о показателях материальной базы предприятия представлен на рис. 16.
Рис. 16. Отчёт о показателях материальной базы предприятия.

Вид отчёта о режимах предприятия представлен на рис. 17.
Рис. 17. Отчёт о режимах предприятия.

Вид отчёта об архиве заказов предприятия представлен на рис. 18.
Рис. 18. Отчёт об архиве заказов предприятия.

Вид отчёта об изделиях предприятия представлен на рис. 19.
Рис. 19. Отчёт об изделиях предприятия.

Вид отчёта о размерах изделия представлен на рис. 20.
Рис. 20. Отчёт о размерах изделия.

Вид отчёта о заказчиках изделия представлен на рис. 21.
Рис. 21. Отчёт о заказчиках изделия.
Также можно распечатать составной отчёт об изделиях, включающий данные о собственно изделиях, их размерах и заказчиках.
Вид общего отчёта по изделиям представлен на рис. 22.
Рис. 22. Общий отчёт по изделиям.

3.6. Хранение данных в течение длительного времени.

Хранение данных в течение длительного времени обеспечивается свойствами выбранных средств (Delphi 6.0 и SQL-сервер InterBase 6.0). Сохранность данных может быть гарантирована их регулярным резервным копированием. Такая возможность предусмотрена сервером.

4. РАЗРАБОТКА СТРУКТУРЫ ПРОГРАММНОГО ПРОДУКТА

Для реализации программного продукта была выбрана модель "клиент-сервер" (рис. 23). Это означает, что программа состоит из клиентской и серверной частей, которые могут исполняться на отдельных машинах, объединённых в сеть. Клиентская часть реализована средствами среды разработки Borland Delphi 6, а серверная - средствами SQL-сервера баз данных InterBase 6.0.



Рис. 23. Модель "клиент-сервер".

Функциональная схема программного продукта изображена на рис. 24.
Рис. 24. Функциональная схема программного продукта.

База знаний предприятий состоит из следующих модулей:
­ Модуль базы фактов;
­ Модуль подсистемы наполнения базы фактов;
­ Модуль подсистемы формирования отчётов;
­ Модуль подсистемы проверки базы фактов;
­ Модуль ввода данных;
­ Модуль ввода запросов;

Клиентская часть обеспечивает интерфейс ввода данных, которые, после их ввода пользователем, в виде SQL-запроса пересылаются серверу. Сервер, обрабатывая запрос, производит запись данных в базу фактов.
Для того, чтобы вывести данные на экран и на печать, по запросу клиентской части производится выбор необходимых данных и пересылка. Затем клиентская часть производит форматирование данных и вывод их в отчёт, который затем можно распечатать.
Подсистема проверки базы фактов включает в себя проверку на полноту знаний. По запросу клиентской части сервер предоставляет данные о количестве записей. Клиентская часть анализирует эти данные, и, с помощью средств ввода данных, предоставляет пользователю возможность исправить обнаруженные недостатки.

5. РАЗРАБОТКА СЕРВЕРНОЙ ЧАСТИ

5.1. Общее описание.

Серверная часть программы, реализованная средствами сервера InterBase, состоит из 8 таблиц, 26 хранимых процедур, 8 генераторов.
Данные хранятся в таблицах в несортированном виде. Имеются следующие таблицы:
­ Таблица предприятий;
­ Таблица экономических показателей предприятия;
­ Таблица показателей материальной базы предприятия;
­ Таблица режимов предприятия;
­ Таблица архива заказов предприятия;
­ Таблица изделий;
­ Таблица размеров изделий;
­ Таблица заказчиков.

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


Реализованы следующие хранимые процедуры:
­ CHECK_FOR_FULL_ENTR - проверка на полноту таблиц, связанных с таблицей предприятий;
­ CHECK_FOR_FULL_IZD - проверка на полноту таблиц, связанных с таблицей изделий;
­ P_ARCHIVE_DELETE - удаление записей из таблицы "Архив заказов";
­ P_ARCHIVE_INSERT - добавление записей в таблицу "Архив заказов";
­ P_ARCHIVE_MODIFY - изменение записей в таблице "Архив заказов";
­ P_ECPARAMS_DELETE - удаление записей из таблицы "Экономические показатели";
­ P_ECPARAMS_INSERT - добавление записей в таблицу "Экономические показатели";
­ P_ECPARAMS_MODIFY - изменение записей в таблице "Экономические показатели";
­ P_ENTR_DELETE - удаление записей из таблицы "Предприятия";
­ P_ENTR_INSERT - добавление записей в таблицу "Предприятия";
­ P_ENTR_MODIFY - изменение записей в таблице "Предприятия";
­ P_IZDELIE_DELETE - удаление записей из таблицы "Изделия";
­ P_IZDELIE_INSERT - добавление записей в таблицу "Изделия";
­ P_IZDELIE_MODIFY - изменение записей в таблице "Изделия";
­ P_MATBASE_DELETE - удаление записей из таблицы "Материальная база";
­ P_MATBASE_INSERT - добавление записей в таблицу "Материальная база";
­ P_MATBASE_MODIFY - изменение записей в таблице "Материальная база";
­ P_SECURITY_DELETE - удаление записей из таблицы "Режимы предприятия";
­ P_SECURITY_INSERT - добавление записей в таблицу "Режимы предприятия";
­ P_SECURITY_MODIFY - изменение записей в таблице "Режимы предприятия";
­ P_SIZES_DELETE - удаление записей из таблицы "Размеры изделия";
­ P_SIZES_INSERT - добавление записей в таблицу "Размеры изделия";
­ P_SIZES_MODIFY - изменение записей в таблице "Размеры изделия";
­ P_ZAKAZCHIK_DELETE - удаление записей из таблицы "Заказчики";
­ P_ZAKAZCHIK_INSERT - добавление записей в таблицу "Заказчики";
­ P_ZAKAZCHIK_MODIFY - изменение записей в таблице "Заказчики";

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

Определим типы и размеры полей в таблицах:
Предприятия:
­ EntKey - INTEGER (4 байта);
­ Name - VARCHAR (60 байт);
­ Address - VARCHAR строка (60 байт);
­ Phone - VARCHAR строка (30 байт);
­ Comment - VARCHAR (300 байт).
Таким образом, объём одной записи равен 454 байта.

Экономические показатели:
­ Number - INTEGER (4 байта);
­ Value1 и Value2 - VARCHAR (30 байт);
­ Comment - VARCHAR (300 байт);
­ EntKey - INTEGER (4 байта).
Объём одной записи равен 368 байт.

Материальная база:
­ Number - INTEGER (4 байта);
­ Value1 и Value2 - VARCHAR (30 байт);
­ Comment - VARCHAR (300 байт);
­ EntKey - INTEGER (4 байта).
Объём одной записи равен 368 байт.

Режимы предприятия:
­ SecKey - INTEGER (4 байта);
­ Name - VARCHAR (20 байт);
­ Comment - VARCHAR (300 байт);
­ EntKey - INTEGER (4 байта).
Объём одной записи равен 328 байт.

Архив:
­ Number - INTEGER (4 байта);
­ IzdName - VARCHAR строка (60 байт);
­ KolZak - INTEGER (4 байта);
­ Comment - VARCHAR (300 байт);
­ EntKey - INTEGER (4 байта).
Объём одной записи равен 372 байта.

Изделие:
­ IzdKey - INTEGER (4 байта);
­ Name - VARCHAR (40 байт);
­ Vid_Sb - VARCHAR (30 байт);
­ EntKey - INTEGER (4 байта);
­ IsgDate - TIMESTAMP (8 байт);
­ KolZak - INTEGER (4 байта).
Объём одной записи равен 90 байт.

Размеры:
­ SizeKey - INTEGER (4 байта);
­ Name - VARCHAR (30 байт);
­ Description - VARCHAR (300 байт);
­ IzdKey - INTEGER (4 байта).
Объём одной записи равен 338 байт.

Заказчик:
­ EntKey - INTEGER (4 байта);
­ Name - VARCHAR (60 байт);
­ Address - VARCHAR (60 байт);
­ Phone - VARCHAR (30 байт);
­ Comment - VARCHAR (300 байт);
­ IzdKey - INTEGER (4 байта).
Объём одной записи равен 458 байт.

Видно, что при выбранных размерах полей объём ни одной записи не превышает 1 килобайта, что соответствует требованиям технического задания.
При заданном в техническом задании максимальном количестве записей 10000 штук в таблице максимальный объём данных равен:
(454+368+368+328+372+90+338+458)*10000 = 27760000 байт = 26.47 Мбайт

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

Также сервер InterBase предоставляет такие средства администрирования, как механизм управления пользовательскими полномочиями, средства резервного копирования, "сборки мусора" и т. д.

5.2. Типичные процедуры.

Хранимые процедуры представляют собой подпрограммы, реализованные на языке SQL.
Пример процедуры добавления данных для таблицы "Предприятия":
ALTER PROCEDURE P_ENTR_INSERT
(
PNAME VARCHAR(60) CHARACTER SET WIN1251, /*Название предприятия*/
PADDRESS VARCHAR(60) CHARACTER SET WIN1251, /*Адрес предприятия*/
PPHONE VARCHAR(30) CHARACTER SET WIN1251, /*Телефон предприятия*/
PCOMMENT VARCHAR(300) CHARACTER SET WIN1251 /*Комментарий*/
)
AS
BEGIN
INSERT INTO ENTERPRISES (NAME,ADDRESS,PHONE,COMMENT,ENTKEY) //добавление данных в таблицу
VALUES (:PNAME, :PADDRESS, :PPHONE, :PCOMMENT, 0);
END

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

Пример хранимой процедуры выдачи информации о количестве связанных записей с каждой записью таблицы "Предприятия", хранящихся в её подчинённых таблицах (т. е. выполняющей проверку на полноту):
ALTER PROCEDURE CHECK_FOR_FULL_ENTR
RETURNS
(
ENTK INTEGER, /*Ключ записи в таблице "Предприятия"*/
ECPARS INTEGER, /*Количество записей в таблице "Экономические показатели"*/
MBASE INTEGER, /*Количество записей в таблице "Материальная база"*/
SEC INTEGER, /*Количество записей в таблице "Режимы предприятия"*/
ARCH INTEGER, /*Количество записей в таблице "Архив"*/
IZD INTEGER /*Количество записей в таблице "Изделия"*/
)
AS
BEGIN
FOR SELECT ENTKEY FROM ENTERPRISES /*Для каждой записи из таблицы "Предприятия"...*/
INTO :ENTK /*Выдаём ключ*/
DO
BEGIN
SELECT COUNT(NUMBER) FROM ECONOMICPARAMS
WHERE ENTKEY=:ENTK /*Выдаём кол-во связанных записей в таблице "Экономические показатели"*/
INTO :ECPARS;
SELECT COUNT(NUMBER) FROM MATHERIALBASE
WHERE ENTKEY=:ENTK /*Выдаём кол-во связанных записей в таблице "Материальная база"*/
INTO :MBASE;
SELECT COUNT(SECKEY) FROM SECURITY
WHERE ENTKEY=:ENTK /*Выдаём кол-во связанных записей в таблице "Режимы предприятия"*/
INTO :SEC;
SELECT COUNT(NUMBER) FROM ARCHIVE
WHERE ENTKEY=:ENTK /*Выдаём кол-во связанных записей в таблице "Архив"*/
INTO :ARCH;
SELECT COUNT(IZDKEY) FROM IZDELIE
WHERE ENTKEY=:ENTK /*Выдаём кол-во связанных записей в таблице "Изделия"*/
INTO :IZD;
SUSPEND; /*Передаём параметры (т. е. строку таблицы) клиенту */
END
END

При обращении к процедуре для каждой записи таблицы предприятия производится подсчёт связанных с ней записей в подчинённых таблицах. На выходе процедуры - таблица с числовыми значениями.
Аналогично выполняется подсчёт в таблицах, связанных с таблицей "Изделия".

6. РАЗРАБОТКА КЛИЕНТСКОЙ ЧАСТИ

6.1. Общее описание.

Код клиентской части состоит из 33 модулей, из них 24 - формы различного назначения и 9 - отчёты.
Клиентская часть связывается с серверной посредством механизма Borland Database Engine (BDE). Этот механизм предоставляет стандартные средства взаимодействия с различными серверами баз данных, и позволяет сделать клиентскую часть максимально независимой от выбранного сервера. Для связи с сервером InterBase выбран драйвер SQL-links, так как он обеспечивает большую производительность по сравнению с драйвером интерфейса ODBC (Open Database Connectivity). Кроме того, можно менять расположение базы данных без необходимости перекомпиляции клиентского приложения. Достаточно только изменить путь в свойствах псевдонима BDE. Соединение клиентской части с серверной может проходить по протоколам TCP/IP, SPX, NetBEUI.
Все компоненты приложения, работающие с данными, для удобства вынесены в отдельный модуль приложения (EntrDataModule). Его вид представлен на рис. 25.


Рис. 25. Модуль данных клиентской части.

Компонент dbEnterprises обеспечивает связь с удалённой базой данных. Остальные компоненты, работающие с данными, взаимодействуют с базой с помощью этого компонента.
Компоненты в модуле:
­ EnterprisesQuery - обеспечивает взаимодействие с таблицей "Предприятия";
­ EntrModifyStoredProc, EntrDeleteStoredProc, EntrInsertStoredProc - обеспечивают модификацию данных в таблице "Предприятия", взаимодействуя с хранимыми процедурами на сервере;
­ - EnterprisesDataSource - обеспечивает интерфейс для вывода данных пользователю;
­ EcParamsQuery - обеспечивает взаимодействие с таблицей "Экономические параметры";
­ EcParamsModifyStoredProc, EcParamsDeleteStoredProc, EcParamsInsertStoredProc - обеспечивают модификацию данных в таблице "Экономические параметры", взаимодействуя с хранимыми процедурами на сервере;
­ EcParamsDataSource - обеспечивает интерфейс для вывода данных пользователю;
­ MatBaseQuery - обеспечивает взаимодействие с таблицей "Материальная база";
­ MatBaseModifyStoredProc, MatBaseDeleteStoredProc, MatBaseInsertStoredProc - обеспечивают модификацию данных в таблице "Материальная база", взаимодействуя с хранимыми процедурами на сервере;
­ MatBaseDataSource - обеспечивает интерфейс для вывода данных пользователю;
­ SecurityQuery - обеспечивает взаимодействие с таблицей "Режимы предприятия";
­ SecurityModifyStoredProc, SecurityDeleteStoredProc, SecurityInsertStoredProc - обеспечивают модификацию данных в таблице "Режимы предприятия", взаимодействуя с хранимыми процедурами на сервере;
­ SecurityDataSource - обеспечивает интерфейс для вывода данных пользователю;
­ ArchiveQuery - обеспечивает взаимодействие с таблицей "Архив";
­ ArchiveModifyStoredProc, ArchiveDeleteStoredProc, ArchiveInsertStoredProc - обеспечивают модификацию данных в таблице "Архив", взаимодействуя с хранимыми процедурами на сервере;
­ ArchiveDataSource - обеспечивает интерфейс для вывода данных пользователю;
­ IzdelieQuery - обеспечивает взаимодействие с таблицей "Изделия";
­ IzdelieModifyStoredProc, IzdelieDeleteStoredProc, IzdelieInsertStoredProc - обеспечивают модификацию данных в таблице "Изделия", взаимодействуя с хранимыми процедурами на сервере;
­ IzdelieDataSource - обеспечивает интерфейс для вывода данных пользователю;
­ SizesQuery - обеспечивает взаимодействие с таблицей "Размеры";
­ SizesModifyStoredProc, SizesDeleteStoredProc, SizesInsertStoredProc - обеспечивают модификацию данных в таблице "Размеры", взаимодействуя с хранимыми процедурами на сервере;
­ SizesDataSource - обеспечивает интерфейс для вывода данных пользователю;
­ ZakQuery - обеспечивает взаимодействие с таблицей "Заказчики";
­ ZakModifyStoredProc, ZakDeleteStoredProc, ZakInsertStoredProc - обеспечивают модификацию данных в таблице "Заказчики", взаимодействуя с хранимыми процедурами на сервере;
­ ZakDataSource - обеспечивает интерфейс для вывода данных пользователю;
­ CheckEntrQuery - обеспечивает взаимодействие с хранимой процедурой проверки количества записей в таблицах, связанных с таблицей "Предприятия";
­ CheckEntrDataSource - обеспечивает интерфейс для вывода данных пользователю;
­ CheckIzdQuery - обеспечивает взаимодействие с хранимой процедурой проверки количества записей в таблицах, связанных с таблицей "Изделия";
­ CheckIzdDataSource - обеспечивает интерфейс для вывода данных пользователю;

В формах проекта содержатся лишь компоненты, необходимые для взаимодействия с пользователем.
В проекте содержатся следующие формы:
1) MainForm - главная форма приложения;
2) InputEntrForm - форма ввода данных для занесения их в таблицу "Предприятия";
3) EntrViewForm - форма поиска и фильтрации в таблице "Предприятия";
4) EcParamsForm - форма отображения данных таблицы "Экономические показатели";
5) EcParamsInputForm - форма ввода данных для занесения их в таблицу "Экономические показатели";
6) EcParamsViewForm - форма поиска в таблице "Экономические показатели";
7) MatBaseForm - форма отображения данных таблицы "Материальная база";
8) MatBaseInputForm - форма ввода данных для занесения их в таблицу "Материальная база";
9) MatBaseViewForm - форма поиска в таблице "Материальная база";
10) SecurityForm - форма отображения данных таблицы "Режимы предприятия";
11) SecurityInputForm - форма ввода данных для занесения их в таблицу "Режимы предприятия";
12) SecurityViewForm - форма поиска в таблице "Режимы предприятия";
13) ArchiveForm - форма отображения данных таблицы "Архив заказов";
14) ArchiveInputForm - форма ввода данных для занесения их в таблицу "Архив заказов";
15) ArchiveViewForm - форма поиска в таблице "Архив заказов";
16) IzdelieForm - форма отображения данных таблиц "Изделия", "Размеры" и "Заказчики";
17) IzdelieInputForm - форма ввода данных для занесения их в таблицу "Изделия";
18) IzdelieViewForm - форма поиска в таблице "Изделия";
19) SizesInputForm - форма ввода данных для занесения их в таблицу "Размеры";
20) SizeViewForm - форма поиска в таблице "Размеры";
21) ZakInputForm - форма ввода данных для занесения их в таблицу "Заказчики";
22) ZakViewForm - форма поиска в таблице "Заказчики";
23) CheckForm - форма проверки базы знаний на полноту.

6.2. Типичные процедуры.

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

Пример обращения к процедуре добавления для таблицы "Предприятия":
//Ввели ли название предприятия?
if NameEdit.Text<>'' then
begin
//Если да, то заносим информацию в базу
//Занесение параметров...
EntrDataModule.EntrInsertStoredProc.ParamByName('PNAME').AsString:=NameEdit.Text;
EntrDataModule.EntrInsertStoredProc.ParamByName('PADDRESS').AsString:=AddressEdit.Text;
EntrDataModule.EntrInsertStoredProc.ParamByName('PPHONE').AsString:=PhoneEdit.Text;
EntrDataModule.EntrInsertStoredProc.ParamByName('PCOMMENT').AsString:=CommentMemo.Text;
EntrDataModule.EntrInsertStoredProc.Prepare;//Подготовка данных
EntrDataModule.EntrInsertStoredProc.ExecProc;//Обращение к хранимой процедуре добавления
end
else
//Сообщение "Введите название предприятия".
MessageDlg('Введите название предприятия.',mtInformation,[mbOk],0);

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

Пример обращения к процедуре удаления для таблицы "Предприятия":
// Запрос на подтверждение удаления
if MessageDlg('Вы уверены?',mtConfirmation,[mbYes,mbNo],0)=mrYes then
begin
//Если подтвердили, то удаляем.
EntrDataModule.EntrDeleteStoredProc.ParamByName('PENTKEY').AsString:=EntrDataModule.EnterprisesQuery.FieldValues['ENTKEY'];//Заносим параметр (ключ удаляемой записи)
EntrDataModule.EntrDeleteStoredProc.Prepare;//Подготовка параметра
EntrDataModule.EntrDeleteStoredProc.ExecProc;//Обращение к процедуре
RefreshEnterprisesTable;//После удаления обновляем информацию на экране
end;

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

Пример процедуры проверки на полноту знаний в таблицах, связанных с таблицей "Предприятия":
erez:=false;//Признак неполноты. Устанавливается в true, если нашли неполноту.
EntrDataModule.CheckEntrQuery.FindFirst;//Переходим на первую запись информации с сервера
repeat
j:=0;//Счётчик внутреннего цикла
repeat
if EntrDataModule.CheckEntrQuery.Fields[j].AsInteger=0 then
erez:=true;//Если нашли неполноту, устанавливаем признак.
inc(j);
until (j=EntrDataModule.CheckEntrQuery.FieldCount) or (erez=true);//Оканчиваем просмотр, если //просмотрели всю строку или нашли неполноту
if erez=false then //Если неполнота не найдена, переходим к следующей строке
EntrDataModule.CheckEntrQuery.FindNext;
until (EntrDataModule.CheckEntrQuery.RecNo=EntrDataModule.CheckEntrQuery.RecordCount-1) or (erez=true);//Заканчиваем работу, если просмотрели всю таблицу или нашли неполноту.

На вход процедуры проверки полноты знаний поступает информация с сервера, представленная в виде таблицы, в каждой строке которой занесено количество записей, связанных с записью таблицы "Предприятия", номер которой соответствует номеру строки, в каждой из подчинённых таблиц. Если присутствует нулевое значение, то в данном случае это означает, что о предприятии не занесены какие-либо данные, например, производимые изделия, режимы, экономические показатели или показатели материальной базы. Поэтому каждое нулевое значение обозначает неполноту, которую необходимо устранить для того, чтобы модуль логического вывода мог делать адекватные заключения, обращаясь к этой базе знаний.
III.
ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

1. РАЗРАБОТКА ТЕСТОВ И ТЕСТОВЫХ ПРОГРАММ

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

1.1. Тесты, проверяющие правильность работы программного продукта с данными.

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

Тест правильности добавления данных:
­ Добавление данных в таблицу;
­ Получение обновлённой информации с сервера

До проведения теста в таблице, с которой проводится тест, информации нет (рис. 26).

Рис. 26. Таблица "Экономические показатели" до проведения теста.

После выполнения процедуры добавления данных и обновления информации с сервера в таблице появились введённые данные (рис. 27). Следовательно, тест пройден успешно.

Рис. 27. Таблица "Экономические показатели" после добавления данных.

Также можно увидеть, что в поле "Ключ предприятия" было автоматически занесено верное значение.
Для проверки правильности процедуры модификации необходимо в таблицу добавить ещё несколько записей (рис. 28) для того, чтобы проверить изменяется ли именно та запись, которую необходимо модифицировать.

Рис. 28. Тестовый набор данных.

После добавления данных модифицируем показатель с ключом 13. После обновления данных с сервера видно, что запись правильно изменилась (рис. 29).

Рис. 29. Таблица "Экономические показатели" после модификации данных.
Теперь, для проверки правильности процедуры удаления, удалим эту запись. Результат процедуры удаления представлен на рис. 30.

Рис. 30. Таблица "Экономические показатели" после удаления показателя с ключом 13.

После обновления данных с сервера видно, что показатель действительно был удалён.
Для проверки процедуры каскадного удаления необходимо:
­ Добавить запись в главную таблицу ("Предприятия");
­ Добавить связанные с ней записи в подчинённые таблицы ("Экономические показатели", "Материальная база", "Режимы", "Архив", "Изделия");
­ Удалить запись в таблице "Предприятия";
­ Получить обновлённые данные с сервера.

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

Для проверки функционирования программного продукта при большом числе записей в таблице (порядка 10000) была создана специальная тестовая программа. Окно этой программы изображено на рис. 31.


Рис. 31. Тестовая программа.

Данная программа добавляет заданное количество записей. Данные заносятся во все поля записи. После занесения записей в таблицу, необходимо провести операции добавления данных, модификации и удаления для того, чтобы проверить:
­ Время реакции системы на запрос;
­ Правильность настроек псевдонима BDE.

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

1.2. Тесты, проверяющие правильность функционирования интерфейса пользователя.

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

Рис. 32. Состояние элементов управления пока клиентская часть не подключена к серверу.

Доступна только кнопка подключения, а также кнопка вывода отчёта, нажав на которую, можно настроить принтер, а также получить просматривать ранее сохранённые на диске отчёты.
Если в какую-либо таблицу ещё не внесены данные то кнопки модификации и удаления недоступны, а доступны только кнопка добавления и кнопка обновления данных с сервера, а также кнопка отчёта (рис. 33).

Рис. 33. Состояние элементов управления, если осуществлено подключение к серверу, но в таблицу ещё не внесены данные.

Если данные в таблице есть, то активируются все элементы управления.
При попытке удаления записи запрашивается подтверждение (рис. 34):

Рис. 34. Запрос подтверждения удаления.

Удаление производится только в том случае, если пользователь подтверждает своё желание.

При вводе данных отслеживается, корректные ли введены значения: например, некоторые поля не должны быть пустыми. Если поле пусто, то добавление записи не производится, и выводится сообщение о том, что поле не должно быть пусто (рис. 35).





Рис. 35. Сообщение, выдающееся, если при вводе данных в таблицу "Предприятия" поле названия предприятия пусто.
IV.
ЭКОНОМИЧЕСКАЯ ЧАСТЬ

1. ТЕХНИКО-ЭКОНОМИЧЕСКОЕ ОБОСНОВАНИЕ ПРИНЯТЫХ РЕШЕНИЙ

1.1. Обоснование выбора СУБД.

В качестве СУБД была выбрана InterBase фирмы Borland. Достоинствами данной СУБД по сравнению с конкурирующими (например, Microsoft SQL Server, Oracle) являются бесплатность, открытый исходный код, невысокие системные требования, приемлемая производительность при решении поставленных перед разрабатываемым программным продуктом задач. Также существуют версии InterBase для различных операционных систем.
Открытость исходного кода обеспечивает возможность самостоятельного исправления ошибок в данной СУБД независимо от её производителя, а также обуславливает наличие множество свободно распространяемых утилит и удобных средств администрирования, что позволяет снизить эксплуатационные расходы. Также открытость исходного кода позволяет обеспечить приемлемый уровень безопасности.
Невысокие системные требования позволяют использовать эту СУБД не только в локальных сетях, но и на локальных компьютерах.
Существование версий InterBase для различных операционных систем обеспечивает свободу в выборе операционной системы для компьютера, на котором данная СУБД будет работать.

1.2. Обоснование выбора языка программирования.

На сегодняшний день для семейства операционных систем Windows существует достаточно много средств разработки приложений (Borland Delphi, Microsoft Visual C++ и т. д.). Проведём краткий анализ наиболее распространённых из них.

1.2.1. Delphi.

Delphi разработана фирмой Borland, и является компонентной объектно-ориентированной средой быстрой разработки приложений.
Среди преимуществ можно отметить:
­ Широкие возможности среды;
­ Возможность быстро разрабатывать приложения;
­ Относительную простоту разработки приложений;
­ Мощную подсистему работы с базами данных;
­ Большое количество готовых компонентов;
­ Быстрый компилятор;
­ Возможность создания кроссплатформных приложений.

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

1.2.2. Visual C++.

Visual C++ разработан фирмой Microsoft, и, также как и Delphi, является объектно-ориентированной средой разработки приложений.
Среди преимуществ можно отметить:
­ Большие возможности при создании приложений по Windows;
­ Небольшой объём исполнимых файлов;
­ Большая скорость работы приложений по сравнению с приложениями, написанными на Delphi;
­ Более стабильная, чем у Delphi, среда разработки.

Основным недостатком является высокая трудоёмкость разработки приложения, и, как следствие, требуется большее время на разработку приложения, чем в Delphi.

1.2.3. Вывод.

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

ЗАКЛЮЧЕНИЕ

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

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

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


СПИСОК ЛИТЕРАТУРЫ

1) Пугачёв Е.К. Исследование методов представления и обработки знаний. Методические указания по выполнению лабораторных работ по дисциплине Системы искусственного интеллекта. - М.: МГТУ, 2000.- 35 с.
2) Представление и использование знаний /Под ред. У. Уэно, М. Исидзука. - М.: Мир, 1989. - 220 с.
3) Искусственный интеллект: Справочник в 3-х книгах. - М.: Радио и связь, 1990. Книга 2. Модели и методы /Под ред. Д.А. Поспелова. - 304 с.
4) Минский М. Фреймы для представления знаний. - М.: Энергия, 1979.- 51 с.
5) Гофман В.Э, Хомоненко А.Д. Delphi 6. - СПб.: БХВ-Петербург, 2002. - 1152 с.: ил.
6) Иванова Г.С., Ничушкина Т.Н. Проектирование программного обеспечения. Методическое пособие по выполнению и оформлению курсовых, дипломных и квалификационных работ. М.: МГТУ, 2002.- 128 с.
7) Тейксейра С., Пачеко К. Delphi 5. Руководство разработчика. Т. 2. Разработка компонентов и программирование баз данных: Пер. с англ. - М.: Вильямс, 2000. - 992 с.: ил.

ПРИЛОЖЕНИЕ 1.
РУКОВОДСТВО СИСТЕМНОГО АДМИНИСТРАТОРА

1. Требования программы.

Базе знаний требуется сервер InterBase 6.0, а также установленный на компьютере клиента BDE (входит в дистрибутив).

2. Установка программы.

Для установки программы нужно запустить Setup.exe и следовать инструкциям программы установки.
После завершения работы инсталлятора потребуется зарегистрировать базу на сервере InterBase. Для этого необходимо запустить сервер, подключиться к нему из программы IBConsole и выбрать пункт Register... из меню Database.
На компьютере, где установлен клиент, будет установлен также механизм BDE, в котором будет автоматически создан псевдоним MyBase. Здесь если это необходимо, должен быть внесён правильный путь к базе. Остальные настройки изменений не требуют.

3. Администрирование.

Администрирование базы осуществляется с помощью программы IBConsole, входящей в комплект сервера InterBase. Здесь можно управлять пользовательскими полномочиями, проводить резервное копирование данных, осуществлять "сборку мусора" из базы и т. п. За подробностями следует обратиться к документации сервера InterBase.
По умолчанию в базе существует учётная запись с именем SYSDBA и паролем masterkey. Она даёт пользователю, заходящему под этим именем, все привилегии. Эту учётную запись следует использовать только для первоначального доступа к базе, и сменить пароль администратора как можно скорее.

4. Удаление.

Для удаления базы с сервера следует удалить ссылку на неё из сервера InterBase, выбрав пункт Unregister из меню Database. Затем можно просто удалить файл с данными с сервера.
Для удаления клиентской части следует зайти в средство "Установка и удаление программ" панели управления и удалить программу "Enterprises Knowledge Base".

ПРИЛОЖЕНИЕ 2.
РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

1. Подключение к серверу.

После запуска появляется основное окно программы (рис. П2.1):

Рис. П2.1. Главная форма приложения.

Для того чтобы начать работу с базой знаний необходимо подключиться к ней. Подключение осуществляется путём выбора пункта "Подключиться" из меню "Подключение". Появится окно ввода пароля (рис. П2.2):

Рис. П2.2. Окно ввода пароля.

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

2. Работа с данными.

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

2.1. Добавление данных.

При нажатии на кнопку добавления появляется форма ввода данных (рис. П2.3):

Рис. П2.3. Форма ввода данных.

В поля следует ввести данные. Нажатие кнопки "Добавить" приведёт к сохранению данных в базе знаний. Нажатие кнопки "Очистить" приведёт к очистке полей формы. При нажатии на кнопку "Закрыть" форма закрывается.




2.2. Удаление данных.

Для удаления данных необходимо выбрать удаляемую запись и нажать кнопку удаления. Появится окно с запросом подтверждения на удаление (рис. П2.4):

Рис. П2.4. Запрос подтверждения на удаление.

После нажатия кнопки "Yes" запись будет удалена. При нажатии кнопки "No" запись удалена не будет.

2.3. Изменение данных.

Для изменения данных записи следует выделить запись и нажать на кнопку изменения. Появится форма изменения данных с уже введёнными данными записи (рис. П2.5):

Рис. П2.5. Форма изменения данных.
Данные можно изменить и сохранить в базе знаний путём нажатия на кнопку "Сохранить", либо не сохранять их, выйдя из формы нажатием кнопки "Закрыть".

2.4. Поиск и фильтрация данных.

При нажатии на кнопку поиска будет выведена форма поиска и фильтрации (рис. П2.6):

Рис. П2.6. Форма поиска и фильтрации.

Для поиска предприятия нужно ввести его название и нажать кнопку "Поиск". Если запись будет найдена, на неё будет произведён переход.
Для фильтрации предприятий по названию нужно ввести маску фильтрации, активировать флажок "Фильтровать" и нажать кнопку "Применить". Для отмены фильтрации нужно снять флажок "Фильтровать" и нажать кнопку "Применить".
Маской фильтрации служат первые буквы названия предприятия.

2.5. Перемещение по данным.

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




2.6. Вывод данных на печать.

При выборе пункта "Отчёт..." меню "Файл" будет выведено окно предварительного просмотра отчёта, из которого отчёт можно распечатать. В отчёт выводятся все видимые в таблице данные.

3. Проверка базы знаний на полноту.

После выбора пункта "Проверка на полноту БЗ" меню "Инструменты" главной формы появится форма проверки базы знаний на полноту (рис. П2.7):

Рис. П2.7. Форма проверки базы знаний на полноту.

После нажатия кнопки "Подсчитать статистику" будет выведено количество записей в подчинённых таблицах для каждой из записей главной таблицы (идентифицируются своим ключом в главной таблице; рис. П2.8):

Рис. П2.8. Статистика.

Каждое нулевое значение означает неполноту и отображается красным цветом на жёлтом фоне. При нажатии на кнопку "Анализ статистики" будет выдано заключение о полноте базы знаний, и, в случае неполноты, будет произведён переход на первое указание неполноты в статистических данных. Затем, при нажатии на кнопку "Перейти", будет произведён переход на запись, для которой существует неполнота.

4. Отключение от сервера.

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


??

??

??

??




2





СОДЕРЖАНИЕ