Представление знаний

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

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

Для реализации базы знаний экспертной системы «DK-PROJECT» было принято решение использовать фреймовую модель представления знаний.

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

Фрейм отличает наличие определённой структуры.

Фрейм состоит из имени и отдельных единиц, называемых слотами. Он имеет однородную структуру:

ИМЯ ФРЕЙМА

Имя 1-го слота: значение 1-го слота

Имя 2-го слота: значение 2-го слота

………………………………

Имя N -го слота: значение N -го слота.

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

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

В данной экспертной системе было разработано несколько фреймов. При этом на языке C# были реализованы соответствующие классы: _Event, _Tag, _Edge, _Date. Был разработан механизм для инициализации экземпляров данных классов с уникальными именами, заполнения их декларативными знаниями и объединения их в коллекции для удобство последующей работы. Данный механизм был реализован в методах EvilEvent(), EvilTag(), EvilEdge(), EvilDate соответственно.

Для класса _Event были написаны специальные методы: NewTags() - для формирования листа тегов с неповторяющимися элементами; DetermineEdge() - для формирования листа ребер тегов, соответствующих конкретному мероприятию; GetAllUV() - для определения конкретных неповторяющихся посетителей мероприятия; daysEq() - для определения потенциальной доходности мероприятия на заданные дни недели.

Для класса _Egde были написаны специальные методы: CompareTags() - для определения всех мероприятий имеющих в описании конкретное ребро тегов; GetInfo() - для определения списка уникальных посетителей конкретного ребра тегов и расчета соответствующих коэффициентов, необходимых для определения потенциальной доходности.

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