НАУЧНАЯ РАБОТА

• 2002/03 уч.год. "Методы многокритериального выбора при согласовании оценок бизнеса".

• 2003/04 уч.год. 1 семестр. "Методы и алгоритмя учета неопределенности данных при оценке альтернатив инвестиционных проектов развития энергетических систем".

• 2003/04 уч.год. 2 семестр. "Выбор эффективного варианта инвестиционного решения путем анализа области неопределенности".

•  2004/05 уч.год. 1 семестр. "Инструментальная система для создания продукционных экспертных систем с четкой логикой в среде Delphi 7".

КУРСОВАЯ РАБОТА

• 2003/04 уч. г. 1 семестр,  Курсовой проект по предмету "СППР в  образовании".
•  2004/05 уч.г. 1 семестр, Курсовой проект по предмету "Проектирование ИС"
•  

ФОТОАЛЬБОМ

• Часть 1
• Часть 2
• Часть 3
• Часть 4
• Часть 5

Тема:

Инструментальная система для создания продукционных экспертных систем с четкой логикой в среде Delphi 7.0.

РЕФЕРАТ

Пояснительная записка: 66 с., 11 рис., 3 приложения.

Графическая документация: 16 л . А4

АВТОМАТИЗИРОВАННАЯ СИСТЕМА, ПРАВИЛО, ПЦР, ОЦР, КОНСУЛЬТАЦИЯ, ЧЕТКАЯ ЛОГИКА.

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

Средства позволяют проводить консультацию по методу «Включение одного правила» и «Выполнение определенного набора правил», а также выбирать алгебры объединения фактором уверенности (всего 16 алгебр) в различных ситуациях.

Система реализована в среде программирования Delphi 7.0 на базе реализации системы RulProc для операционной системы Windows 98/2000/XP.

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

СОДЕРЖАНИЕ

Введение......................................................................................................................4

1        Системотехническая часть..............................................................................................6

1.1  Анализ предметной области и постановка задачи проектирования.....................6

1.1.1        Анализ предметной области.........................................................................6

1.1.2        Обзор существующих программных продуктов.........................................8

1.1.3        Анализ требований к проектируемой системе............................................9

1.1.4        Выбор и обоснование архитектуры системы.............................................10

1.2  Разработка функциональной структуры проектируемой системы......................10

1.3  Структура, состав и взаимосвязь участников системы.........................................12

1.3.1        Краткие сведения о UML методологии. Rational Rose..............................12

1.3.2        Разработка диаграммы вариантов использования системы......................17

1.3.3        Сценарии работы системы...........................................................................19

1.4  Расчет требуемых ресурсов.....................................................................................33

1.4.1        Расчёт объёма ВЗУ.......................................................................................33

1.4.2        Расчёт объёма ОЗУ.......................................................................................33

1.4.3        Расчёт времени реакции системы...............................................................34

2        Конструкторско–технологическая часть......................................................................35

2.1  Обоснование выбора средства автоматизации......................................................35

2.2  Разработка программы и программных приложений...........................................37

2.2.1        Выбор формата представления данных......................................................37

2.2.2        Описание программных модулей................................................................41

2.2.2.1  Модуль команды консультации To Fire...............................................42

2.2.2.2  Модуль команды консультации To Execute.........................................43

2.2.3        Разработка диаграммы компонентов..........................................................45

2.2.4        Разработка диаграммы развертывания.......................................................47

3        Разработка интерфейса системы...................................................................................49

4        Разработка программы и методики испытаний...........................................................51

4.1  Программа и методика испытаний..........................................................................51

4.2  Описание контрольного примера............................................................................53

Заключение................................................................................................................65

Приложение А...........................................................................................................68

Приложение Б...........................................................................................................116

Приложение В...........................................................................................................133

ВВЕДЕНИЕ

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

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

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

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

-                     нелинейный контроль за процессами (производство);

-                      самообучающиеся системы (или классификаторы), исследование рисковых и критических ситуаций;

-                     распознавание образов;

-                     финансовый анализ (рынки ценных бумаг);

-                     исследование данных (корпоративные хранилища);

-                     искусственный интеллект;

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

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

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

1 СИСТЕМОТЕХНИЧЕСКАЯ ЧАСТЬ

1.1 Анализ предметной области и постановка задачи проектирования

1.1.1 Анализ предметной области

Интенсивные исследования по созданию систем искусственного интеллекта (СИИ) проводятся с начала 60-х годов. Основной целью являлась разработка математических и программных средств моделирования процессов человеческого мышления для автоматического решения различных прикладных и теоретических задач. К 80-м годам пришло понимание того, что эффективность систем такого рода зависит от знаний, которыми они обладают. Эти знания не только чисто эмпирические (полученные эмпирическим путем), но и эвристические - набор правил и рекомендаций, которыми следует пользоваться в той или иной ситуации, возникающей в данной предметной области. Такого рода эмпирические правила (эвристики) поставляются экспертами, в связи с чем системы и получили название экспертных систем (ЭС). В самом общем виде ЭС - это программная система, способная в данной предметной области вырабатывать решения, по эффективности конкурирующие с решениями эксперта. Задачи, которые целесообразно решать с помощью ЭС, могут быть охарактеризованы следующими свойствами:

-  невозможность алгоритмического решения (в силу плохой формализуемости задач или огромных затрат машинного времени);

-  противоречивость, неполнота, возможная ошибочность исходных данных и знаний в предметной области;

-  огромная размерность данных и знаний, плохо представимых в какой-либо наглядной форме;

-  динамически меняющийся состав данных и знаний (в силу постоянного их пополнения, изменения и развития);

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

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

Можно выделить следующие основные классы задач, решаемых экспертными системами:

·        диагностика,

·        прогнозирование,

·        идентификация,

·        управление,

·        проектирование,

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

Мощь и интуитивная простота ЭС гарантирует ее успешное использование во многих областях науки, а также значительно облегчит работу предприятия и фирм.

Основными функциями, реализованными в системе RulProc являются:

Консультация, выполняемая по методу «Включение одного правила» и консультация, выполняемая по методу «Выполнение определенного набора правил». Эти два способа тестирования набора правил являются одной из отличительных особенностей системы RulProc. Система RulProc предназначена для создания и отладки наборов правил (баз знаний) экспертных систем продукционного типа.

Система имеет свой язык описания знаний в предметной области и широкий набор средств для организации и контроля процесса логического вывода.

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

Система RulProc поддерживала два способа рассмотрения набора правил (логического вывода): прямая цепочка рассуждений, использующая весь набор правил (To Test); обратная цепочка рассуждений, использующая весь набор правил (To Seek). Были разработаны два дополнительных метода работы с правилами: включение одного правила (To Fire); рассмотрение определенного набора правил (To Execute). Эти функции не являются стандартными и отличают систему RulProc от имеющихся аналогов.

В существующем процессоре обработки правил было необходимо добавить два вида консультации: включение одного правила (To Fire) и работу с определенным набором правил (To Execute).

Описание команды консультации To Fire: Используя этот вариант команды, процессор правил разрешает условие в специфицированном правиле. Сначала процессор выполняет команды инициализации набора правил, при условии, что отсутствует запрос на продолжение процесса аргументации с помощью специфицированного правила. Правило рассматривается относительно всего набора переменных. При необходимости, пытаясь включить правило, процессор может использовать обратную аргументацию. Затем, чтобы завершить консультацию, выполняются команды завершения набора правил.

Описание команды консультации To Execute: Используя эту команду, процессор обработки правил начинает выполнять предписанную последовательность правил. Прежде всего выполняются команды инициализации набора правил. Затем процессор правил рассматривает каждое правило относительно всего набора переменных в порядке, который определен. Затем, чтобы завершить консультацию, выполняются команды завершения набора правил.

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

1.1.2 Обзор существующих программных продуктов

Задача выбора эффективного инструментального средства (ИС) для поддержки разработки ЭС является сама по себе экспертной. В настоящее время не существует строгого формального метода для выбора ИС. Единую классификацию всех существующих на сегодня ИС провести достаточно сложно, так как с одной стороны – можно выделить большое количество специфических характеристик ИС, а с другой – у разных авторов существуют значительные различия в терминологии обозначения одних и тех же вещей [15].

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

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

Интегрированная система разработки GURU, русскоязычная версия которой известна как ИНТЕР-ЭКСПЕРТ, получила широкое распространение в нашей стране. В отличие от ЭКО, данное ИС имеет более удобные средства реализации прямой стратегии рассуждений. ИНТЕР-ЭКСПЕРТ обладает целым рядом таких дополнительных возможностей (кроме средств проектирования ЭС), как реляционная СУБД с удобным языком запросов, электронные таблицы, генератор статистических данных, графические средства, генератор отчетов, средства телекоммуникации. Кроме того, данная ИС предлагает на выбор 16 видов алгебр для соединения факторов уверенности переменных и правил.

Комплексный инструментарий LEVEL5 OBJECT на сегодняшний день является новым ИС на российском рынке для создания и поддержки статических ЭС [15, 16]. Это ИС обладает следующими возможностями: содержит средства проектирования ЭС, поддерживает язык запросов SQL для доступа к большинству форматов баз данных, имеет мощные средства создания интерфейсов для всех категорий пользователей, содержит встроенные объяснения результата. База знаний прикладной ЭС, реализованной с помощью ИС LEVEL5 OBJECT, представляет собой совокупность правил и методов.

Явным преимуществом LEVEL5 OBJECT по сравнению с системами ЭКО и GURU является многооконный интерфейс, что значительно уменьшает время создания и отладки ЭС, а также повышает эффективность работы с ИС и созданными на его основе ЭС [16].

1.1.3 Анализ требований к проектируемой системе

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

Продукция – правило вида ЕСЛИ <условие> ТО <действие> ИНАЧЕ <действие>.

Язык описания знаний - это множество фраз (предложений), построенных по определенным правилам.

Файл набора правил – файл с расширением *.rul, содержащий список правил для преобразования его в системе RulProc в экспертную систему.

База знаний -  (БЗ) в ЭС предназначена для хранения долгосрочных данных, описывающих рассматриваемую область (а не текущих данных), и правил, описывающих целесообразные преобразования данных этой области [13].

Эксперт - определяет знания (данные и правила), характеризующие проблемную область, обеспечивает полноту и правильность введенных в ЭС знаний [13].

Экспертная система – прикладная система искусственного интеллекта, в которых база знаний представляет собой формализованные эмпирические знания высококвалифицированных специалистов (экспертов) в какой либо узкой предметной области [14, 16].

Выделим следующие основные требования к инструментальной системе:

1.      Поддержка четырех способов консультации.

2.      Поддержка работы с факторами уверенности.

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

4.      Работа в пределах автономного рабочего места.

5.      Дружественный интерфейс.

1.1.4 Выбор и обоснование архитектуры системы

На выбор архитектуры системы в первую очередь влияют требования, которые предъявляются к системе. С точки зрения архитектуры, важным является необходимость обеспечить автономную работу одного пользователя (эксперта или консультируемого). Также важным является требование работоспособности системы в условиях ограниченных вычислительных ресурсов, так как она создается с расчетом на обучение в ВУЗах, которые не всегда обладают самым современным оборудованием.

1.2 Разработка функциональной структуры проектируемой системы

С учетом требований к проектируемой системе была разработана следующая структура системы (см. рисунок 1.2.1):

1.   Центральным ядром системы является основной модуль для редактирования набора правил. Он обеспечивает интерфейс создания и редактирования наборов правил для экспертов. Выделение функций задания наборов правил в отдельный модуль позволяет решить следующие задачи:

a)                 произвольный выбор создания файлов с наборами правил;

b)                повышение скорости работы, за счет упрощения интерфейса;

2.   Модуль редактирования настроек среды. Этот модуль выделяется для решения следующих задач:

a)                 быстрый доступ к настройкам факторов уверенности, стратегий работы с правилами, опций среды;

b)                удобное расположение всех настроек на одной форме;

3.   Для работы с методами консультации в системе выделены четыре модуля: модуль обработки набора правил ПЦР (прямой цепочкой рассуждений), модуль обработки набора правил ОЦР (обратной цепочкой рассуждений), модуль включения одного правила, модуль выполнения определенного набора правил. Их выделение обеспечивает отдельный доступ к каждому методу консультации.

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

Рисунок 1.2.1 - Структура системы

1.3 Структура, состав и взаимосвязь участников системы

1.3.1 Краткие сведения о UML методологии. Rational Rose

История развития языка UML берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из Rational Software Corporation начали работу по унификации методов Booch и ОМТ. Хотя сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Румба сосредоточили усилия на полной унификации результатов своей работы. Проект так называемого унифицированного метода (Unified Method) версии 0.8 был подготовлен и опубликован в октябре 1995 года. Осенью того же года к ним присоединился А. Джекобсон, главный технолог из компании Objectory AB (Швеция).

Некоторые компании и организации видели в языке UML линию стратегических интересов для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. Статус языка UML определен как открытый для всех предложений по его доработке и совершенствованию. Язык UML ориентирован для применения в качестве языка моделирования различными пользователями и научными сообществами для решения широкого класса задач ООАП.

Назначение языка UML [1]:

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

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

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

4.                  Описание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАП.

5.                  Поощрять развитие рынка объектных инструментальных средств.

6.                  Способствовать распространению объектных технологий и соответствующих понятий ООАП.

1.                  Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

Диаграммы Rational Rose [5]:

Ø                              Диаграмма вариантов использования (use case diagram)

Базовые элементы:

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

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

Используются также примечания (notes) - в языке UML предназначены для включения в модель произвольной текстовой информации, имеющей непосредственное отношение к контексту разрабатываемого проекта.

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

·                     Отношение ассоциации (association relationship)

·                     Отношение расширения (extend relationship)

·                     Отношение обобщения (generalization relationship)

·                     Отношение включения (include relationship)

Ø                  Диаграмма классов (class diagram)

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

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

Операция (operation) - представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по определенному требованию.

Базовыми отношениями или связями являются:

·                     Отношение зависимости (dependency relationship)

·                     Отношение ассоциации (association relationship)

·                     Отношение обобщения (generalization relationship)

·                     Отношение реализации (realization relationship)

Ø                        Диаграмма состояний (statechart diagram)

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

Автомат (state machine) - в языке UML представляет собой некоторый формализм для моделирования поведения элементов модели и системы в целом.

Состояние (state) - абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия.

Событие - спецификация некоторого факта, имеющего место в пространстве и во времени.

Ø                              Диаграмма деятельности (activity diagram)

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

Состояние действия (action state) - является специальным случаем состояния с некоторым входным действием и, по крайней мере, одним выходящим из состояния переходом.

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

Ø                              Диаграмма последовательности (sequence diagram)

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

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

Линия жизни (object lifeline) - служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях.

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

Ø                              Диаграмма кооперации (collaboration diagram)

Кооперация может быть представлена на двух уровнях:

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

·                                                          На уровне примеров — указывает экземпляры и связи, образующие отдельные роли в кооперации.

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

Объект (object) - является отдельным экземпляром класса

Мультиобъект (multiobject) - представляет собой целое множество объектов на одном из концов ассоциации.

Активный объект (active object) - имеет свою собственную нить (thread) управления и может инициировать деятельность по управлению другими объектами.

Активный объект (active object) - имеет свою собственную нить (thread) управления и может инициировать деятельность по управлению другими объектами.

Связь (link) - является экземпляром или примером произвольной ассоциации.

Ø                              Диаграмма компонентов (component diagram)

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

Диаграмма компонентов разрабатывается для следующих целей:

·                     Визуализации общей структуры исходного кода программной системы.

·                     Спецификации исполнимого варианта программной системы.

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

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

Компонент (component) - реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели.

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

Ø                  Диаграмма развертывания (deployment diagram)

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма развертывания является единой для системы в целом, поскольку должна всецело отражать особенности ее реализации [6].

Узел (node) - представляет собой некоторый физически существующий элемент системы, обладающий некоторым вычислительным ресурсом.

1.3.2 Разработка диаграммы вариантов использования системы

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

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

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

-                    Редактировать существующий набор правил. После редактирования набора правил эксперт может откомпилировать или сохранить его.

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

Консультируемому доступны следующие варианты использования:

-                    Консультировать. Консультация включает в себя четыре способа: включение одного правила, выполнение определенного набора правил, применить ПЦР, применить ОЦР.

1.3.3        Сценарии работы системы

Имя варианта использования: Включение одного правила.

Краткое описание: Система просматривает определенное правило методом обратной цепочки рассуждений.

Актант: Консультируемый.

Предусловие: Варианты использования «Войти в систему» и «Консультировать» успешно завершены.

Основная последовательность:

1. Система запрашивает правило для включения.
2. Консультируемый выбирает правило для включения.
3. Система запрашивает целевую переменную.
4. Пользователь выбирает целевую переменную.
5. Пользователь выбирает прямую или обратную цепочку рассуждений для нахождения значения переменной.
6. В системе запускается алгоритм ПЦР с заданной целевой переменной.
7. Система проверяет выбранный определенный набор правил и выдает результат по заданной целевой переменной.

Альтернативы:

А1. Если в П1 Консультируемый нажал кнопку «Отмена», на экране появляется форма, настроенная на права Консультируемого.

А2. Если в П5 Консультируемый выбирает метод включения правила «ОЦР», то в системе запускается алгоритм ОЦР с заданной целевой переменной.

1.4 Расчёт требуемых ресурсов

1.4.1 Расчёт объёма ВЗУ

Проведём расчёт необходимой внешней памяти, воспользовавшись формулой:

V_ВП=V_ОС + V_{программы} + V_{данных,}

где V_ВП – объём необходимой внешней памяти;

V_ОС – объём внешней памяти, необходимый операционной системе;

Vпрограммы – объём внешней памяти, необходимый программе;

Vданных – объём внешней памяти для максимального заполнения файлов, требующихся для размещения данных.

Для расчёта примем, что программа функционирует в операционной системе Microsoft Windows 2000, которой необходимо 200 Мб внешней памяти. Объём внешней памяти, необходимый системе, складывается из размеров каждого из модулей, которые в сумме занимают 2,43 Мб. Объем памяти, необходимой данным, точно рассчитать нельзя, так как он зависит от размера файлов наборов правил. Для одного набора правил в среднем требуется от 3 до 5 Кб, в системе используется 3 файла с наборами правил.

V_ВП =200+2,43+3*0,005=  204,89 Мб

1.4.2        Расчёт объёма ОЗУ

Проведём расчёт необходимого объёма ОЗУ, воспользовавшись формулой:

V_ОЗУ=V_ОС+V_{программы} + V_данных,

где V_ОЗУ – объём необходимой оперативной памяти;

V_ОС – объём оперативной памяти, необходимый операционной системе;

V_{программы} – объём оперативной памяти, необходимый программе.

V_данных – объём оперативной памяти, необходимый данным.

V_ОС=120 Мб, V_{программы} =7 Мб, V_данных =20,489 Мб.

Таким образом, общий объём оперативной памяти, необходимый для нормального функционирования программы:

V_ОЗУ=120+7+20,489= 147,489 Мб

Рекомендуемый объем ОЗУ равен 256 Мб.

1.4.3 Расчёт времени реакции системы

Рассчитаем время реакции системы для случая выбора объекта для вычисления факторов уверенности при консультации.

 В этом случае, время реакции системы рассчитывается по формуле:

t_{реакции} =t_ввода +t_{вычисления} +t_{вывода на экран}

где t_ввода – время, затраченное на ввод, рассчитываемое по формуле:

t_ввода =k_оп*L_{символа}*t_{символа,}

k_оп – коэффициент оператора, характеризует степень опытности оператора. Обычно k_оп=1,5.

Т.к. пользователь производит выбор из списка, то L_{символа} = 1, выбор из списка по времени равен набору одного символа.

t_{символа} – время ввода символа вручную. Обычно t_{символа}=2с.

Итак, время, затраченное на ввод:

t_ввода=1,5*1*1=1,5с

t_{вычисления} =N_опер.*k₁/f,

где N_опер. – количество операторов. В нашем случае N_опер. »10⁷.

k₁ – среднее количество машинных команд, затрачиваемых на реализацию одного оператора. Обычно k₁=15.

f – тактовая частота процессора в герцах. В нашем случае f=10⁹ Герц.

Итак, время, затраченное на вычисления:

t_{вычисления} =10⁷*15/10⁹ +1,5=1,65 c

Время вывода на экран

t_{вывода на экран} »0,5 с

Итого время реакции системы составляет:

t_{реакции} =1,5 с+1,65 с+0,5 с=3,65 с

Полученное время реакции системы соответствует нормам времени для диалогового режима (до 30 с) и удовлетворяет требованиям к проектируемой системе (10 с).

2 КОНСТРУКТОРСКО-ТЕХНОЛОГИЧЕСКАЯ ЧАСТЬ

2.1 Обоснование выбора средства автоматизации

Для реализации проекта выберем язык программирования DELPHI 7.0 [3].

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

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

На стадии проектирования создаются и используются различные файлы. Основной частью программы является проект (в Borland/ Turbo Pascal эта часть называлась собственно программой). Файл, в котором размещается проект, имеет расширение .dpr. Как правило, эта часть, являющаяся собирательной частью всей программы, небольшая и формируется самой Delphi, хотя при необходимости сюда можно вносить свои изменения. Кроме этой части в программе используются различные модули, файлы которых имеют расширение .pas и из которых в программу включаются необходимые элементы. Многие из модулей написаны заранее и могут использоваться в любой программе (стандартные модули), другие формирует разработчик, полностью или частично. Модули, которые формирует разработчик, в свою очередь, можно разделить на модули, содержащие информацию о формах, и модули, не связанные непосредственно с формами (модули разработчика). Последние предназначены для размещения текста программы, связанного непосредственно с решением задачи, для которой она создается, размещения данных и т. д. Их можно рассматривать как модули собственных библиотек.

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

Цикл работы программы в этом случае выглядит следующим образом. Выполняется какая-то самостоятельная часть программы (например, инициализация), после чего выполнение программы прекращается и она дожидается какой-то реакции либо от операционной системы, либо от пользователя через средства ввода информации (например, через клавиатуру или посредством манипулирования мышью). Эта реакция представляет собой особым образом оформленную информацию – сообщение, которое содержит сведения о виде реакции (например, нажатие клавиши мыши или отпускание клавиши клавиатуры), и информацию, уточняющую эту реакцию (например, какая клавиша мыши нажата). Сообщение через операционную систему Windows передается программе. Программа должна отреагировать на то или иное сообщение событием, которое обработает передаваемую информацию, причем обработать эту информацию могут разные элементы программы: и конкретное окно (форма) этой программы, и та или иная компонента какого-либо окна. Для того чтобы какой-то элемент программы обработал информацию, ему следует написать специальную подпрограмму — обработчик событий, причем таких обработчиков может быть и не один, если элемент должен обрабатывать различные сообщения.

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

Delphi также предоставляет возможности по созданию dll библиотек, которые необходимы при реализации дипломного проекта.

Вышеперечисленные достоинства, повлияли на выбор языка и средства программирования в пользу Borland Delphi 7.0. Кроме того, выбор языка программирования обусловлен личными предпочтениями и большим опытом работы с этой средой.

2.2 Разработка программы и программных приложений

2.2.1 Выбор формата представления данных

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

a)                    Малый размер.

b)                    Удобство обработки.

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

Описание общей структуры набора правил (базы знаний) с учетом всех требований.

<база знаний> ::=

VARIABLES <объявление переменных> RULES <описание правил> END. |

VARIABLES <объявление переменных> IMPORT <описание внешних функций> RULES <описание правил> END. |

VARIABLES <объявление переменных> INITIAL <инициализация переменных> RULES <описание правил> END. |

VARIABLES <объявление переменных> IMPORT <описание внешних функций> INITIAL <инициализация переменных> RULES <описание правил> END.

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

Таблица 2.2.1.1 – Встроенные функции и операции языка описания знаний

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

Раздел VARIABLES

<объявление переменных> ::=

<объявление переменной> |

<объявление переменной> <объявление переменных>

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

<объявление переменной> ::=

<идентификатор>: <тип>; |

<идентификатор>: <тип> FROM [<список альтернатив>]; |

<идентификатор>: <тип> ASK <строка>; |

<идентификатор>: <тип> FROM [<список альтернатив>] ASK <строка>;

<тип> ::=

STRING | REAL | BOOLEAN | DATETIME

Раздел IMPORT

<описание внешних функций> ::=

<описание функций библиотеки> |

<описание функций библиотеки> <описание внешних функций>

Для описания импортируемых функций необходимо назвать название файла DLL-библиотеки внешних функций, имя функции, перечень типов параметров и тип возвращаемого результата. Имя файла имеет стандартные ограничения на имена файлов системы MS DOS (для обеспечения совместимости и переносимости файлов).

Раздел INITIAL

<инициализация переменных> ::=

<инициализация переменной> |

<инициализация переменной> <инициализация переменных>

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

<инициализация переменной> ::=

<идентификатор> := <значение> |

<идентификатор> := <значение> <фактор уверенности> 

Раздел RULES

<описание правил> ::=

<описание правила> |

<описание правила> <описание правил>

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

<описание правила> ::=

<заголовок правила> <тело правила> <конец правила>

<заголовок правила> ::=

RULE <идентификатор>: |

RULE <идентификатор> PRIORITY <приоритет>: |

RULE <идентификатор> NEEDS <необходимые переменные>: | RULE <идентификатор> PRIORITY <приоритет> NEEDS <необходимые переменные>:

<тело правила> ::=

IF <выражение> THEN <заключения> |

IF <выражение> THEN <заключения> ELSE <заключения>

<конец правила> ::=

ENDRULE; | COMMENT <текст> ENDRULE;

<приоритет> ::=

<цифра> | <цифра><цифра> | <цифра><цифра><цифра> |

<цифра><цифра><цифра><цифра>

<необходимые переменные> ::=

<идентификатор> |

<идентификатор>, <необходимые переменные>

<заключения> ::=

<заключение> | <заключение>; <заключения>

<заключение> ::=

<идентификатор> := <выражение> |

<идентификатор> := <выражение> <фактор уверенности>

<фактор уверенности> ::=

CF  <цифра> | CF  <цифра><цифра> |

CF  <цифра><цифра><цифра>

2.2.2 Описание программных модулей

Система RulProc состоит из следующих основных модулей:

·                   UnitMain. Главный модуль системы. Включает процедуры, обеспечивающие интерфейс пользователя.

·                   UAuth. Модуль, проверяющий правильность ввода пароля.

·                   UnitFPW. Модуль, проверяющий правильность ввода пароля файла.

·                   UnitAbt. Модуль формы вывода информации о программе.

·                   ReadExpr. Модуль, содержащий процедуры и функции, осуществляющие чтение логического условия.

·                   Grammatc. Модуль содержит процедуры чтения, анализа и компиляции текста набора правил.

·                   Fnctns. Модуль, содержащий процедуры и функции, осуществляющие работу с факторами уверенности.

·                   Declare. В этом модуле объявляются глобальные константы, типы, классы и переменные.

·                   Common. Модуль содержит процедуры общего пользования.

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

·                   UnitTrc. Модуль позволяет трассировать логический вывод.

·                   UnitRprt. Модуль содержит процедуры и функции для формирования отчета по консультации.

·                   UnitQuer. Модуль описывает форму для запроса значения переменной.

·                   UnitOne. Модуль содержит процедуры и функции для запуска прямой (ПЦР) или обратной (ОЦР) цепочки рассуждений.

·                   UnitAll. Модуль описывает форму для вывода всех результатов при консультации методом прямой цепочки рассуждений (ПЦР).

·                   UnitPCR. Модуль логического вывода по ПЦР.

·                   UnitOCR. Модуль логического вывода по ОЦР.

·                   UFire. Модуль описывает форму, процедуры и функции для тестирования одного правила.

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

2.2.2.1 Модуль команды консультации To Fire

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

Блок управления консультацией содержит возможность выбора ОЦР или ПЦР, реализованную на основе класса TRudioButton. Также модуль содержит управляющие кнопки на основе класса TButton для заполнения списка правил, списка переменных правил и запуска консультации. Консультация подразумевает запуск алгоритма ПЦР или ОЦР (см. Приложение А, UnitPCR, UnitOCR). Списки правил и переменных помещаются в объекты класса TComboBox. Полученное в результате значение целевой переменной помещается в объект класса TEdit.

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

Рис.2.2.2.1.1 - Интерфейс модуля команды консультации To Fire

(включение одного правила)

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

2.2.2.2 Модуль команды консультации To Execute

Модуль предназначен для выполнения определенного набора правила, который пользователь формирует сам, т.е. для рассмотрения всех переменных набора правил относительно данного набора правила. Интерфейс модуля включает в себя два поля для формирования определенного набора правил на основе компонента TCheckListBox. В объекте CheckListBox1 слева помещается список всех правил, присутствующих в наборе правил. Пользователь выбирает правила для добавления в новый набор правил и нажимает на кнопку «>>», которая является объектом класса TButton. Выбранные правила добавляются в поле объекта CheckListBox2 справа и формируется новый набор правил. В объект класса TComboBox добавляется список всех переменных набора правил. Кнопка «Консультировать» запускает алгоритм ПЦР (см. Приложение А, UnitPcr). Полученный результат тестирования переменной, т.е. ее значение отображается в поле «Значение переменной», которое является объектом класса TEdit (см. Рисунок 2.2.2.2.1).

Рис.2.2.2.2.1 - Интерфейс модуля команды консультации To Execute

(выполнение определенного набора правил)

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

2.2.3 Разработка диаграммы компонентов

Диаграмма компонентов системы RulProc состоит из следующих частей:

-         Главной программы RulProc.exe;

-         Интерфейса главной программы FormMain;

-         Подключаемой динамической библиотеки Expert.dll;

-         Подключаемых файлов с наборами правил: Field_1.rul, PcixoTip.rul и record.rul.

1.2.4        Разработка диаграммы развертывания

Диаграмма развертывания системы RulProc (см. Рисунок 2.2.4.1) состоит из следующих частей:

-         Процессора, который является автономным рабочим местом LocalMachine;

-         Устройства вывода на печать Printer;

LocalMachine включает следующие компоненты:

-         Главной программы RulProc.exe;

-         Интерфейса главной программы FormMain;

-         Подключаемой динамической библиотеки Expert.dll;

-         Подключаемых файлов с наборами правил: Field_1.rul, PcixoTip.rul и record.rul.

Рисунок 2.2.4.1 – Диаграмма развертывания

3 Разработка интерфейса системы

При разработке интерфейса системы учитывались следующие принципы:

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

2.      Уменьшение расстояния, на которое приходится перемещать мышь. С этой целью, кнопки навигации модулей находятся на близком расстоянии друг от друга (см. Рисунок 3.1).

Рисунок 3.1 – Особенности интерфейса модуля консультации

3.      Основное меню и дополнительное меню находится вверху главной формы, что облегчает управление системой (см. Рисунок 3.2).

Рисунок 3.2 - Расположение основного и дополнительного меню на главной форме.

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

5.      Параметры тематически сгруппированы на панели;

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

4 Разработка программы и методики испытаний

1.1  Программа и методика испытаний

Объектом испытаний являются инструментальные средства создания и отладки наборов правил продукционных экспертных систем.

Испытательная система состоит из следующих модулей:

-    модуль для настройки параметров работы процессора правил;

-    модуль консультации при прямой цепочке рассуждения;

-    модуль консультации при обратной цепочке рассуждения;

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

Целью испытаний является выявления правильности реализации пользовательского интерфейса.

Проверяемые функции и результаты проверки [4, 9, 12] представлены в Таблице 4.1.1.

Таблица 4.1.1 – Проверяемые функции, результаты проверки системы и рекомендации

1.1  Описание контрольного примера

Рассмотрим реализацию функций системы на основе создания набора правил «Система диагностики магнитофона». Предметной областью является система диагностики магнитофона.

Для создания набора правил необходимо выделить переменные. Переменными будут являться внешние неисправности и причины этих неисправностей. В процессе анализа предметной области выделили сочетание 7 внешних неисправностей (см. Таблица 4.2.1), которым сопоставляются 11 причин (Таблица 4.2.2).

Таблица 4.2.1 – Внешние неисправности

Таблица 4.2.2 – Причины внешних неисправностей

Были выделены следующие переменные:

  НетИндикацииПитания

  ЛентаНеДвижется

  ЗаписьНеРаботает

  ПрерывистыйЗвук

  ИскаженныйЗвук

  НестабильнаяСкорость

  ПовышенныйФон

  МагнитофонНеВключен

  НажатаПауза

  ЛентаЗаедает

  НеверноУстановленаКассета

  СломанПредохрВыступ

  ЗагрязненаГоловка

  ПотянутаЛента

  ПлохоеКачествоЗаписи

  НеисправенУсилитель

  ЗагрязненТонВал

Которые описаны в наборе правил следующим образом:

VARIABLES

  НетИндикацииПитания : STRING FROM ['Есть', 'Нет'] ASK 'Есть индикация питания ?';

  ЛентаНеДвижется : STRING FROM ['Движется', 'Не движется'] ASK 'Лента движется?';

  ЗаписьНеРаботает : STRING FROM ['Работает', 'Не работает'] ASK 'Запись работает?';

  ПрерывистыйЗвук : BOOLEAN ASK 'Звук прерывистый?';

  ИскаженныйЗвук : BOOLEAN ASK 'Звук искаженный?';

  НестабильнаяСкорость : STRING FROM ['Стабильная скорость', 'Не стабильная скорость'] ASK 'Какая скорость?';

  ПовышенныйФон : BOOLEAN ASK 'Фон повышенный?';

  МагнитофонНеВключен : STRING FROM ['Магнитофон не включен', 'Магнитофон включен'];

  НажатаПауза : STRING FROM ['Нажата кнопка PAUSE'];

  ЛентаЗаедает : STRING FROM ['Заедает лента', 'Лента не заедает'];

  НеверноУстановленаКассета : STRING FROM ['Кассета установлена неверно', 'Кассета установлена верно'];

  СломанПредохрВыступ : STRING FROM ['Сломан предохранительный выступ'];

  ЗагрязненаГоловка : STRING FROM ['Головка загрязнена', 'Головка не загрязнена'];

  ПотянутаЛента : STRING FROM ['Лента потянута', 'Лента не потянута'];

  ПлохоеКачествоЗаписи : STRING FROM ['Качество записи плохое', 'Качество записи плохое'];

  НеисправенУсилитель : STRING FROM ['Усилитель в порядке', 'Усилитель неисправен'];

  ЗагрязненТонВал : STRING FROM ['Тон-вал загрязнен', 'Тон-вал чистый'];

  ПлохойРекорд : STRING FROM ['Плохая запись', 'Хорошая запись'];

RULES

  RULE R1 :

    IF ( ЗаписьНеРаботает = 'Не работает' ) OR ( ПовышенныйФон = TRUE )

    THEN ПлохойРекорд := 'Плохая запись'

    ELSE ПлохойРекорд := 'Хорошая запись'

    COMMENT Если запись не работает или повышенный фон то плохая запись;

  ENDRULE;

  RULE R2 :

    IF ( ИскаженныйЗвук = TRUE ) AND ( НестабильнаяСкорость = 'Не стабильная скорость' )

    THEN ЗагрязненТонВал := 'Тон-вал загрязнен'

    ELSE ЗагрязненТонВал :=  'Тон-вал чистый'

    COMMENT Если искаженный звук и нестабильная скорость то тон-вал загрязнен;

  ENDRULE;

  RULE R3 :

    IF ( ИскаженныйЗвук = TRUE ) AND ( ПовышенныйФон = TRUE )

    THEN НеисправенУсилитель := 'Усилитель неисправен'

    ELSE НеисправенУсилитель := 'Усилитель в порядке'

    COMMENT Если искаженный звук и повышенный фон то усилитель неисправен;

  ENDRULE;

  RULE R4 :

    IF ( ПрерывистыйЗвук = TRUE ) OR ( ИскаженныйЗвук = TRUE ) OR ( ПовышенныйФон = TRUE )

    THEN ПлохоеКачествоЗаписи := 'Качество записи плохое'

    COMMENT Если прерывистый звук или искаженный звук или повышенный фон то качество записи плохое;

  ENDRULE;

  RULE R5 :

    IF ( ПрерывистыйЗвук = TRUE ) AND ( (НестабильнаяСкорость = 'Не стабильная скорость' ) OR (ИскаженныйЗвук = TRUE ) )

    THEN ПотянутаЛента := 'Лента потянута'

    ELSE ПотянутаЛента := 'Лента не потянута'

    COMMENT Если прерывистый звук и нестабильная скорость или искаженный звук то лента потянута;

  ENDRULE;

  RULE R6 :

    IF ( ПрерывистыйЗвук = FALSE ) OR ( ИскаженныйЗвук = FALSE )

    THEN ЗагрязненаГоловка := 'Головка не загрязнена'

    ELSE ЗагрязненаГоловка := 'Головка загрязнена'

    COMMENT Если звук не прерывистый или не искаженный то головка не загрязнена;

  ENDRULE;

RULE R7 :

    IF ( ЗаписьНеРаботает = 'Не работает' )

    THEN СломанПредохрВыступ := 'Сломан предохранительный выступ'

    COMMENT Если запись не работает то сломан предохранительный выступ;

  ENDRULE;

RULE R8 :

    IF ( ЛентаНеДвижется = 'Не движется' ) OR ( ПрерывистыйЗвук = TRUE ) OR ( СломанПредохрВыступ = 'Сломан предохранительный выступ' )

    THEN НеверноУстановленаКассета := 'Кассета установлена неверно'

    ELSE НеверноУстановленаКассета := 'Кассета установлена верно'

    COMMENT Если лента не движется или звук прерывистый или сломан предохранительный выступ то кассета установлена неверно;

  ENDRULE;

RULE R9 :

    IF ( ЛентаНеДвижется = 'Не движется' ) OR ( НестабильнаяСкорость = 'Не стабильная скорость' ) OR ( ЗаписьНеРаботает = 'Не работает' )

    THEN ЛентаЗаедает := 'Заедает лента'

    ELSE ЛентаЗаедает := 'Лента не заедает'

    COMMENT Если лента не движется или запись не работает или скорость не стабильная то лента заедает;

  ENDRULE;

RULE R10 :

    IF ( ЛентаНеДвижется = 'Не движется' ) AND ( ЗаписьНеРаботает = 'Не работает' )

    THEN НажатаПауза := 'Нажата кнопка PAUSE'

    COMMENT Если лента не движется и запись не работает то нажата кнопка пауза;

  ENDRULE;

RULE R11 :

    IF ( ЛентаНеДвижется = 'Не движется' ) AND ( ЗаписьНеРаботает = 'Не работает' ) OR ( НетИндикацииПитания = 'Нет' )

    THEN МагнитофонНеВключен := 'Магнитофон не включен'

    ELSE МагнитофонНеВключен := 'Магнитофон включен'

    COMMENT Если лента не работает и запись не работает или нет индикации питания то магнитофон не включен;

  ENDRULE;

END.

В наборе правил 11 правил, что соответствует 11 причинам неисправности магнитофона (см. Таблица 4.2.2).

Тестирование варианта консультации To Fire.

Рассмотрим вариант консультации To Fire – включение одного правила.

Выберем для тестирования правило №1:

  RULE R1 :

    IF ( ЗаписьНеРаботает = 'Не работает' ) OR ( ПовышенныйФон = TRUE )

    THEN ПлохойРекорд := 'Плохая запись'

    ELSE ПлохойРекорд := 'Хорошая запись'

    COMMENT Если запись не работает или повышенный фон то плохая запись;

  ENDRULE;

Тестирование методом ПЦР.

При рассмотрении каждой переменной относительно правила №1 получили следующие результаты (см. Рисунок 4.2.1, Таблицу 4.2.3):

Рисунок 4.2.1 – Результаты тестирования правила №1

Таблица 4.2.3 – Полученные значения переменных

По результатам тестирования (см. Таблицу 4.2.3) сработало правила №1, была определена переменная заключения правила ПлохойРекорд и ей присвоено значение: ПлохойРекорд =Плохая запись, что соответствует необходимой логике работы метода To Fire с применением алгоритма ПЦР.

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

Тестирование методом ОЦР.

При рассмотрении каждой переменной относительно правила №1 получили следующие результаты (см. Рисунок 4.2.2, Таблицу 4.2.4):

Рисунок 4.2.2 – Результаты тестирования правила №1

Таблица 4.2.4 – Полученные значения переменных

По результатам тестирования (см. Таблицу 4.2.4) сработало правила №1, была определена переменная заключения правила ПлохойРекорд и ей присвоено значение: ПлохойРекорд =Плохая запись, что соответствует необходимой логике работы метода To Fire с применением алгоритма ОЦР.

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

Тестирование варианта консультации To Execute.

Рассмотрим вариант консультации: выполнение определенного набора правил.

Выберем для рассмотрения правила № 1,3,7,9:

RULE R1 :

    IF ( ЗаписьНеРаботает = 'Не работает' ) OR ( ПовышенныйФон = TRUE )

    THEN ПлохойРекорд := 'Плохая запись'

    ELSE ПлохойРекорд := 'Хорошая запись'

    COMMENT Если запись не работает или повышенный фон то плохая запись;

  ENDRULE;

RULE R3 :

    IF ( ИскаженныйЗвук = TRUE ) AND ( ПовышенныйФон = TRUE )

    THEN НеисправенУсилитель := 'Усилитель неисправен'

    ELSE НеисправенУсилитель := 'Усилитель в порядке'

    COMMENT Если искаженный звук и повышенный фон то усилитель неисправен;

  ENDRULE;

RULE R7 :

    IF ( ЗаписьНеРаботает = 'Не работает' )

    THEN СломанПредохрВыступ := 'Сломан предохранительный выступ'

    COMMENT Если запись не работает то сломан предохранительный выступ;

  ENDRULE;

RULE R9 :

    IF ( ЛентаНеДвижется = 'Не движется' ) OR ( НестабильнаяСкорость = 'Не стабильная скорость' ) OR ( ЗаписьНеРаботает = 'Не работает' )

    THEN ЛентаЗаедает := 'Заедает лента'

    ELSE ЛентаЗаедает := 'Лента не заедает'

    COMMENT Если лента не движется или запись не работает или скорость не стабильная то лента заедает;

  ENDRULE;

При рассмотрении каждой переменной относительно набора правил №1,3,7,9 получили следующие результаты (см. Рисунок 4.2.3, Таблицу 4.2.5):

Рисунок 4.2.3 – Результаты тестирования набора правил, включающего правила №1,3,7,9

Таблица 4.2.5 – Полученные значения переменных

По результатам тестирования (см. Таблицу 4.2.5) сработали правила №1, 3, 7, 9, были определены переменные заключений правил:

ПлохойРекорд и ей присвоено значение: ПлохойРекорд = Плохая запись;

ЛентаЗаедает и ей присвоено значение: ЛентаЗаедает = Лента не заедает;

НеисправенУсилитель и ей присвоено значение: НеисправенУсилитель = Усилитель не исправен;

СломанПредохрВыступ и ей присвоено значение: СломанПредохрВыступ = Значение не определено, что соответствует необходимой логике работы метода To Execute.

ЗАКЛЮЧЕНИЕ

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

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

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

Список используемых источников.

1.                 Рамбо Д., Якобсон А., Буч Г. UML.специальный справочник. – СПб: Питер, 2002 - 652 с.

2.                 Хассан Гома. UML.Проектирование систем реального времени, распределенных и параллельных приложений. М: ДМК, 2002 - 698 с.

3.                 Гофман В., Хомоненко А. Delphi 6. Наиболее полное руководство в подлиннике. СПб: БХВ-Петербург, 2001 - 1152 с.

4.                 Котов С.Л.. Нормирование жизненного цикла программной продукции. М.: Юнити, 2002 - 143 с.

5.                 Трофимов С.А.. CASE-технологии. Практическая работа в Rational Rose. М.: Издательство БИНОМ, 2001 - 155 с.

6.                 Фаулер М., Скотт К. UML. Основы. Второе издание. СПб: Символ-Плюс, 2002 - 192 с.

7.                 ГОСТ 2.102-68 (СТ СЭВ 4768-84) ЕСКД. Виды и комплексность конструкторских документов. – М.: Издательство стандартов, 1968.

8.                  ГОСТ 19.101-77 (СТ СЭВ 1626-79) ЕСПД. Виды программ и программных документов. – М.: Издательство стандартов, 1977.

9.                 ГОСТ 19.301-79 (СТ СЭВ 3747-82) ЕСПД. Программа и методика испытаний. Требования к содержанию и оформлению. – М.: Издательство стандартов, 1979.

10.             ГОСТ 34.201-89 ЕСПД. Виды, комплектность и обозначение документов при создании автоматизированных систем. – М.: Издательство стандартов, 1989.

11.              ГОСТ 34.601-90 ЕСПД. Автоматизированные системы. Стадии создания. – М.: Издательство стандартов, 1990.

12.             ГОСТ 34.603-92 ЕСПД. Виды испытаний автоматизированных систем. – М.: Издательство стандартов, 1992.

Публикации в Интернет.

13.             Экспертные системы.

 http://khpi-iip.mipk.kharkiv.edu/library/ai/conspai/07.html.

14.             д.т.н., д.э.н. А. Киселенко. Введение в экспертные системы (обзор). (http://ib.komisc.ru/t/ru/ir/vt/00-33/02.html).

15.             Г.В. Рыбина, В.В. Максимкин, Е.В, Карманов, Р.Н. Фролов. Сравнительный анализ функциональных возможностей инструментальных средств ЭКО, GURU (Интер-Эксперт), LEVELS OBJECT. (http://nit7.artdesign.ru/sections/b/54.html).

16.             Гаврилов А. В., Новицкая Ю.В. Разработка экспертных систем. (http://ermak.cs.nstu.ru/site/students/ai1/chapter1.htm).