МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ УКРАЇНИ
«КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ ІМЕНІ ІГОРЯ
СІКОРСЬКОГО»
С.І. Шаповалова
О.О. Мажара
ПРОГРАМНИЙ ІНСТРУМЕНТАРІЙ
РОЗРОБКИ ЕКСПЕРТНИХ СИСТЕМ
КОМП’ЮТЕРНИЙ ПРАКТИКУМ
Рекомендовано Методичною радою КПІ ім. Ігоря Сікорського
як навчальний посібник з підготовки докторів філософії,
які навчаються за спеціальністю
122 «Комп’ютерні науки
Київ
КПІ ім. Ігоря Сікорського
2021
Рецензент
Відповідальний
редактор
Безносик О.Ю., канд. техн. наук, доцент кафедри
системного проектування КПІ ім. Ігоря Сікорського
Аушева Н.М., док. техн. наук, доцент, професор
кафедри
автоматизації
проектування
енергетичних
процесів і систем КПІ ім. Ігоря Сікорського
Гриф надано Методичною радою КПІ ім. Ігоря Сікорського (протокол № 7 від 13.05.2021)
за поданням Вченої ради теплоенергетичного факультету (протокол № 11 від 26.04.2021)
Електронне мережне навчальне видання
Шаповалова Світлана Ігорівна, канд. техн. наук, доц.
Мажара Ольга Олександрівна, канд. техн. наук
ПРОГРАМНИЙ ІНСТРУМЕНТАРІЙ РОЗРОБКИ ЕКСПЕРТНИХ
СИСТЕМ
КОМП’ЮТЕРНИЙ ПРАКТИКУМ
Шаповалова С.І., Мажара О.О. Програмний інструментарій розробки експертних
систем: комп’ютерний практикум: навч. посіб. для здобувачів ступеня доктора філософії
зі спеціальності 122 Комп’ютерні науки /Електронні текстові дані (1 файл: 3,7 Мбайт).
Київ. КПІ ім. Ігоря Сікорського, 2021. – 56 с.
Посібник призначений для аспірантів, які навчаються за освітньою програмою
підготовки докторів філософії за спеціальністю 122 «Комп’ютерні науки», для якісної
організації комп’ютерного практикуму. Містить теоретичний матеріал, індивідуальні
завдання, а також забезпечує аспірантів необхідними прикладами виконання завдань,
запланованих впродовж семестру. Спрямований на формування умінь та досвіду розробки
експертних систем на основі продукційної оболонки CLIPS.
С.І. Шаповалова, О.О. Мажара, 2021
КПІ ім. Ігоря Сікорського, 2021
2
ЗМІСТ
ЗМІСТ.............................................................................................................. 3
ВСТУП............................................................................................................. 4
1. Реалізація продукційної системи..............................................................6
1.1. Концепція продукційної системи...................................................... 6
1.2. Обгортки продукційних систем.......................................................11
1.3. Обгортка продукційних систем CLIPS........................................... 13
1.3.1 Інформаційний ресурс CLIPS.................................................... 13
1.3.2 Базові конструкції мови..............................................................14
2. Робота в середовищі CLIPS.....................................................................21
2.3 Інтерфейс середовища....................................................................... 21
2.4 Приклади виконання програм...........................................................26
3. Компютерний практикум 1: Реалізація машини станів в CLIPS........ 31
3.1 Представлення машини станів..........................................................31
3.1.1 Реалізація компонентів машини станів.................................... 32
3.1.2 Реалізація переходів між станами............................................. 33
3.1.3 Компіляція та виконання............................................................35
3.2 Завдання комп’ютерного практикуму............................................. 41
4. Комп'ютерний практикум 2: Розв’язання задачі пошуку в просторі
станів в CLIPS......................................................................................................... 43
4.1 Представлення компонентів представлення пошуку в просторі
станів.................................................................................................................... 43
4.1.1 Представлення стану...................................................................43
4.1.2 Представлення переходів між станами.....................................45
4.1.3 Компіляція та виконання............................................................49
4.2 Завдання комп'ютерного практикуму.............................................. 51
ПЕРЕЛІК ПОСИЛАНЬ................................................................................ 54
3
ВСТУП
Навчальна
дисципліна
„Програмний
інструментарій
розробки
експертних систем” входить до циклу дисциплін вільного вибору підготовки
докторів філософії навчального плану спеціальності 122 „Комп`ютерні
науки”.
Актуальність
вивчення
зазначеної
дисципліни
визначається
подальшою інтелектуалізацією програмних систем в сучасному світі.
Вивчення кредитного модуля спирається на знання, отримані за
програмами підготовки бакалаврів і магістрів попередніх років навчання
галузі знань 12 „Інформаційні технології”
Викладання спрямоване на формування у студентів умінь та досвіду
розробки експертних систем.
В дисципліні вивчаються концепція формалізму подання знань за
продукційною моделлю; загальні підходи до проектування компонентів
прототипної експертної системи; стратегії логічного висновування, існуючі
середовища розробки продукційних систем.
Комп’ютерний практикум містить перелік завдань, в результаті
виконання яких PhD студенти отримають досвід застосування продукційної
обгортки CLIPS, а саме:
створення прототипних експертних систем;
обирання ефективної стратегії розв’язання конфліктів для поточної
задачі логічного висновування;
реалізації евристики для оптимізації виведення заключень.
розробки
автономних та вбудованих в програмні комплекси
продукційних систем.
Посібник містить як завдання комп’ютерного практикуму, так і
теоретичий матеріал для їх виконання.
Теоретичий матеріал структуровано таким чином, щоб аспіранти могли
ознайомитись з концепцією логічного виведення на основі продукційної
4
моделі представлення знань (підрозділ 1.1); програмним інструментрарієм
розробки експертних систем, реалізованим за цією моделлю (підрозділ 1.2);
базовими конструкціями обгортки продукційної системи CLIPS (підрозділ
1.3).
В другому розділі наведено інформацію, необхідну для початку роботи
в середовищі CLIPS.
Третій
та
четвертий
розділи
містять
завдання
комп’ютерного
практикуму, а також розв’язання та реалізацію програм типових прикладів
кожного з завдань.
Програмним засобом виконання завдань комп’ютерного практикуму є
остання версія
CLIPS 6.4 beta, випущена в 2019 році. Сучасність
підтримується одним з авторів цієї програмної обгортки - Gary Riley.
На теперішній час CLIPS вважається суспільним надбанням і вільно
розповсюджується.
В посібнику застосовуються такі виокремлення:
- жирний – назви конструкцій мови програмування CLIPS;
- жирний курсив – команди
- шрифт Arial 12 – приклади програмного коду, форма Бекуса-Наура опису
конструкцій.
Матеріал даної дисципліни може бути інструментальною основою для
підготовки дисертацій доктора філософії.
5
1. РЕАЛІЗАЦІЯ ПРОДУКЦІЙНОЇ СИСТЕМИ
1.1. Концепція продукційної системи
Продукційна модель представлення знань ґрунтується на основі
множини правил формату якщо – то (if - then), кожне з яких називається
продукцією. Вперше термін «продукція» був запропонований E. Post [1] .
Пост довів, що будь-яка система математики або логіки може бути
оформлена у вигляді системи продукційних правил.
Визначення продукційного правила - продукції, що наводяться в різних
джерелах, іноді суттєво відрізняються одне від одного. Проте, в загальному
випадку, будь-яка продукція визначає деяке правило перетворення вхідної
інформації в заданій предметній області.
Продукція складається з двох
структурних частин: антецеденту та консеквенту.
Антецедент продукції
(передумова, умова продукції, ліва частина, LHS – Left-hand side) –
комбінація умов (шаблонів), з’єднаних логічним зв’язуванням, яка визначає
можливість виконання консеквенту продукції. Консеквент (висновок,
наслідок продукції, права частина, RHS – Right-hand side) – опис дій, які
повинні бути виконані, у випадку доведення істинності антецеденту (рисунок
1.1).
Рисунок 1.1 – Схема продукційного правила
6
Продукції природним чином можна поділити на два непересічних
класи: однорідні та неоднорідні. Цей поділ визначається способом
представлення антецеденту та консеквенту. У першому випадку вони мають
схожу структуру (слова в деякому загальному алфавіті, числові значення,
логічні вислови й т. д.). До неоднорідних належать продукції, в яких ліва та
права частини інтерпретуються по різному. Наприклад, за форматом
антецедент-консеквент: умова - дія, стан середовища - перехід, стимул –
реакція або інші поєднання [2].
Системи, які використовують продукційну модель представлення знань,
називаються системами, які базуються на правилах (rule-based systems) або
продукційними системами (production systems). Доведено, що продукційна
система є логічною системою, еквівалентною машині Тюрінга, тобто
продукційні системи універсальні. Будь-яка формальна система, що оперує
символами, може бути реалізована в вигляді однієї з продукційних систем
Поста.
Продукційна система забезпечує керування процесом розв’язання
задачі за зразком і складається з наступних основних компонент [3]:
1) бази знань (rule base, KB – knowledge base) – множини
продукційних правил, які описують задану предметну область;
2) робочої пам’яті (work memory, WM) – множини фактів,
доведених на поточному кроці логічного висновування;
3) механізму логічного виведення, який визначає істинність
умовних частин антецеденту та забезпечує виконання обраних
правил.
Задача логічного висновування представляється у вигляді множини
заданих фактів, які заносяться до робочої пам’яті. В подальшому в робочу
пам'ять додаються нові факти, доведені на поточному кроці логічного
висновування. Факти додаються до робочої пам’яті як результат виконання
консеквенту активованого правила. Правило вважають активованим, якщо
вміст робочої пам'яті в повній мірі узгоджується зі зразками антецеденту.
7
В загальному випадку умовна (ліва) частина правила є логічною
зв’язкою
шаблонів.
Зразок
(або
шаблон)
є
атомарною
формулою,
аргументами якої є константи та незв’язані змінні. Логічний вираз
антецеденту відповідає логіці першого порядку. Факт є атомарною
формулою,
яка
містить
тільки
константи.
Факти
робочої
пам'яті
узгоджуються з шаблонами правила на основі співставлення відповідних
аргументів [4] . Якщо антецедент продукції є істинним, тобто може бути
доведеним на основі фактів робочої пам’яті, виконується дія продукційного
правила – консеквент. Дія полягає в тому, що додаються нові доведені факти
робочої пам’яті або видаляються ті, що вже не мають значення.
Існує два підходи до висновування в продукційних системах – прямий
(від фактів) та зворотній (від цілі). При побудові прямого ланцюга виведення
поставленої цілі відбувається шляхом послідовного застосування правил до
фактів робочої пам’яті. Під час зворотного висновування процес починається
з поставленої цілі. Якщо ця ціль узгоджується з консеквентом правила, то
антецедент приймається як підціль (гіпотеза). Цей процес продовжується до
того часу, доки не буде доведено відповідність гіпотези отриманими даними.
В даному посібнику розглядаються системи на основі прямого ланцюга
логічного виведення.
Висновування в продукційних системах відбувається ітераційно. На
кожній ітерації виконуються такі кроки:
1. Формування конфліктної множини – активація (activation) правил,
які можуть бути виконаними на поточному кроці.
2. Розв’язання конфлікту (conflict resolution) – вибір єдиного правила
для виконання.
3. Виконання правила (fire).
Правила,
які
можуть
бути
застосовані
на
поточному
кроці
висновування, формують конфліктну множину (conflict set). Продукцію з
даної множини
разом із фактами, що узгоджуються з її антецедентом,
називають екземпляром (instantiation).
8
Формування конфліктної множини відбувається шляхом узгодження
антецедентів правил бази знань з вмістом робочої пам’яті. Цей процес
називається співставленням зі зразком і є найбільш ресурсоємною частиною
логічного висновування за продукційною моделлю [5] .
Розв’язання конфлікту на основі сформованого набору правил
відбувається за обраною стратегією. Стратегія розв’язання конфлікту – це
підхід до вибору продукції з конфліктної множини на основі обраних
характеристик робочої пам’яті та/або антецеденту продукції.
Виділяють
п’ять
основних
принципів,
які
поділяють
стратегії
розв’язання конфліктів на класи [6] : сортування активацій за пріоритетами,
перевірка активацій на новизну, визначення специфічних взаємозв’язків між
продукціями, перевірка обраного правила на відмінності від попередньо
виконаних,
застосовують
надання
довільного
поєднання
пріоритету.
декількох
стратегій
На
практиці
вибору
зазвичай
продукцій
для
розв’язання конфлікту.
В залежності від призначення продукційні системи можуть містити
підсистеми для забезпечення додаткового функціоналу, взаємодії та
інтеграції. Структура такої загальної системи представлена на рисунку 1.2
[7] . Однак реалізація подібних підсистем лежить поза контекстом даного
посібника.
База даних може слугувати джерелом початкової інформації про
предметну область, а також для отримання додаткових фактів в процесі
виведення.
Підсистема
набуття
знань
створюються
для
випадків,
коли
передбачається навчання продукційної системи шляхом генерації нових
правил на основі результатів взаємодії з користувачем.
Підсистема пояснення зазвичай відображає процес висновування на
основі правил у форматі зручному для користувача. В загальному випадку
історія активацій продукцій та вмісту робочої пам’яті є достатніми даними
для пояснення поточного результату системи.
9
Для уникнення логічної невідповідності правил зазвичай формується
система тестування, яка дозволяє перевірити базу знань на консистентність
та повноту.
Інтерфейс користувача та програмний інтерфейси забезпечують
можливість взаємодії з продукційною системою. Програмний інтерфейс
також є засобом інтеграції з зовнішніми застосунками.
Продукційні системи знайшли широке застосування при проектуванні
експертних систем підтримки прийняття рішень, сервісів консультацій,
бізнес-застосунків та інших галузей, де необхідне експертне заключення [8].
10
1.2. Обгортки продукційних систем
Для створення експертних систем з розв’язання прикладних задач
застосовується спеціальний програмний інструментарій, який називається
обгорткою продукційної системи. Її обов’язковими компонентами є
незаповнена база знань з заданими параметрами представлення записів та
механізм виведення (рисунок 1.3). Задачею розробника продукційної системи
є наповнення бази знань
інформацією, необхідною для логічного
висновування в конкретній предметній області, та вибір стратегії розв’язання
конфлікту [9].
На сьогодні найбільшого поширення набув програмний інструментарій,
створений за концепціями однієї з історично перших обгорток CLIPS [10] .
До такого, зокрема, належать Jess [11] , Lisa [12] та ILOG [13] . Крім того
широкого прикладного застосування в сферах бізнес логіки набули Drools
[14], G2 (Gensym corp) [15], Blaze Advisor [16] та Exys Corvid [17].
11
Для підтримки двох парадигм представлення знань – логічної та
продукційної – в London Imperial college була розроблена мова LSP (Logical
production system) [18].
Наразі є два основні напрями застосування інструментів розробки
продукційних систем для реалізації:
1) бізнес-застосунків, яка потребує розширення парадигми
представлення знань;
2) експертних систем на портативних пристроях, що визначає
додаткові вимоги до ресурсоємності застосунку.
Для забезпечення ефективної інтеграції продукційних систем в
комплексні програмні засоби було створено стандарт jsr-94, який визначає
базові концепції та інтерфейси взаємодії [19] . Офіційна документація CLIPS
не зазначає підтримки цього стандарту, проте огляд представлених засобів
мови дає можливість стверджувати про відповідність вимогам.
На основі зазначених характеристик в таблиці 1 представлено
порівняння поширених обгорток продукційних систем, які застосовуються
для реалізації систем бізнес-правил.
Таблиця 1. Обгортки продукційних систем
Назва
Відкри-
обгортки тість
Під-
Наяв-
тримка ність
Наявність
Можливість
зворотного
використання
програм
стан-
редак- висновування портативних
ного
дарту
тору
коду
jsr-94
бази
на
пристроях
знань
Jess
-
+
+
+
Android (в версії
alpha 8)
Drools
+
+
+
+
Android
Blaze
-
+
+
+
-
12
Advisor
Exys
-
-
+
+
Лише з веб браузера
+
-
-
лише пряме
+ (як бібліотека)
Corvid
CLIPS
Наведений програмний інструментарій є найбільш використовуваним
для розробки прикладних продукційних систем. Якщо перші чотири
обгортки є здебільшого засобами бізнес-рішень, то обгортка CLIPS
використовується і як засіб розробки прикладних експертних систем, і як
засіб отримання навичок представлення задач за продукційною моделлю,
загальноприйнятий в університетах світу [20].
1.3. Обгортка продукційних систем CLIPS
1.3.1 Інформаційний ресурс CLIPS
Перший прототип оболонки продукційних систем CLIPS (C Language
Integrated Production System) було розроблено 1985 року в Космічному центрі
НАСА Johnson
[21] .
Метою розробки було створення ефективного
програмного інструментарію реалізації експертних систем для забезпечення
внутрішніх потреб відділу штучного інтелекту.
Створений за два місяці
прототип, доопрацьовували протягом року. Влітку 1986 року версію CLIPS
3.0 зробили доступною широкому загалу дослідників поза НАСА. Спершу
було заплановано лише реалізацію продукційної оболонки прямого логічного
виведення на основі Rete алгоритму співставлення зі зразком. Версія 5.0
CLIPS,
випущена
навесні
1991
року,
додала
дві
нові
парадигми:
процедурного та об'єктно-орієнтованого програмування. COOL (CLIPS
13
Object Oriented Language) - об'єктно-орієнтована мова програмування,
вбудована в CLIPS).
Основними розробниками проекту були Robert Savely, який виступав
ініціатором проекту і надавав загальне керівництво та підтримку; Chris
Calbert, який керував проектом, створив оригінальний довідковий посібник
CLIPS та розробив першу версію утиліти, на якій базувався CLIPS; Gary
Riley, який відповідав за розробку системи логічного виведення на основі
продукцій, став співавтором документації та інтерфейсів системи; Brian
Donnell, який створив об’єктно орієнтовану мову програмування COOL, Dr.
Joseph Giarratano, який написав посібник користувача та книгу з розробки
експертних систем на CLIPS; а також багато інших.
Наразі CLIPS
підтримується здебільшого Gary Riley та Brian Donnell. Середовище CLIPS
поширюється за вільною ліцензією з відкритим програмним кодом. Остання
доступна для завантаження версія CLIPS 6.4 бета.
Версія 6.4 CLIPS містить три основні удосконалення: оновлений
Інтерфейс програмування C-застосунку; класи-обгортки та приклади програм
для мов .NET та Java; інтегровані середовища розробки з підтримкою
Unicode для Windows і Java [22].
1.3.2 Базові конструкції мови
Програма, написана на CLIPS, складається з правил і фактів, які
відповідають концепції продукційної моделі, а також об'єктів. Механізм
логічного виведення визначає, які правила повинні виконуватися на
поточному кроці. Експертна система, написана на CLIPS, - це програма,
керована даними, де факти і об'єкти, є даними, які спрямовують виконання
через механізм виводу.
Існують три основні формати для представлення інформації в CLIPS:
факти, об'єкти і глобальні змінні.
14
1.3.2.1 Представлення фактів
Робоча пам'ять в системі CLIPS містить факти. Кожен факт fact є
частиною інформації, розміщеної в поточному списку фактів -
fact-list.
Факти є основною одиницею даних, що використовується правилами.
Факти можуть бути додані до списку фактів (assert), вилучені зі списку
фактів (retract), модифіковані (modify) або продубльовані (duplicate) через
явну взаємодію з розробником або в процесі виконання CLIPS програми.
До факту можна звернутися за допомогою індексу або за адресою.
Якщо факт додається в робочу пам’ять, йому надається унікальний
цілочисельний індекс, що називається fact-index. Індексація починається з
одного та збільшується на одиницю для кожного нового факту. При
модифікації факту його індекс залишається незмінним.
Адреса факту fact-address отримується як результат виконання команд,
які повертають адреси фактів (наприклад, assert, modify і duplicate) або
шляхом прив'язки змінної до адреси факту, який відповідає шаблону лівої
частини правила .
Факт зберігається в одному з двох форматів: впорядкований (створений
для
службової
інформації,
наприклад,
міток)
або
невпорядкований
(заздалегідь заданий структурою deftemplate).
Формат упорядкованого факту:
<ordered-RHS-pattern> := (<symbol >< RHS-field >+)
<RHS-field> ::= <variable> | <constant> | <function-call>
Упорядкований
факт
складаються
з
символу,
за
яким
йде
послідовність з нуля або більше полів, розділених пробілом. Поля (слоти) в
упорядкованому факті можуть бути будь-якого з примітивних типів даних (за
винятком першого поля, яке повинно бути символом). Упорядковані факти
кодують інформацію позиційно. Щоб отримати доступ до цієї інформації,
користувач повинен знати не тільки дані, які зберігаються в факті, але й
відповідне поле.
Деякі приклади впорядкованих фактів наведені нижче:
15
(father tom john)
(female Jane)
(male John)
(person-name John Do)
(person-name Jane Doe)
Невпорядковані факти надають користувачеві можливість створення
абстрактної структури факту шляхом присвоєння імен кожному полю факту.
Конструкція deftemplate використовується для створення шаблону, який
потім можна застосовувати для доступу до полів факту за назвою.
Конструкція deftemplate дозволяє визначити назву шаблону разом з
нулем або більше іменованих полів або слотів. На відміну від впорядкованих
фактів, слоти факту deftemplate можуть бути обмежені за типом, значенням і
числовим діапазоном. Крім того, для слоту може вказуватися значення за
замовчуванням.
Загальний формат конструкції визначається наступним чином [23]:
<deftemplate-construct>
::=
(deftemplate
<deftemplate-name>
[<optional-
comment>]) <slot-definition>*).
<slot-definition> ::= <single-slot-definition > | < multislot-definition >
< single-slot-definition> ::= (slot <slot-name> <template-attribute>*)
<multislot-definition> ::= (multislot <slot-name> <template-attribute>*)
<template-attribute> ::= <default-attribute> | <constant-attribute>
< default-attribute > ::= (default ?DERIVE | ?NONE | <expression>* | (defaultdynamic <expression>*)
Приклад опису конструкції для визначення персони може виглядати
наступним чином:
(deftemplate person "deftemplate example”
(slot name)
(slot age)
(slot eye-color)
(slot hair-color))
Або ж для визначення родинних зв’язків:
(deftemplate father-of
(slot father)
16
(slot child))
(deftemplate mother-of
(slot mother)
(slot child))
Зазвичай на практиці рекомендують користуватися невпорядкованими
фактами, оскільки завдяки наявності імен слотів
факти стають більш
зручними для читання, що полегшує роботу з ними [23] . В той же час
виокремлюють два випадки, в яких корисні впорядковані факти [23]:
1) факти,
які
містять
лише
ім’я
відношення,
можуть
використовуватися у вигляді міток та мають однаковий формат,
незалежно від того, чи було для них оголошено конструкцію
deftemplate. Наприклад, наступний факт може визначати, що
обробка вхідного рядку завершена:
(all-input-parsed)
2) для фактів, які містять лише один слот, ім’я слота зазвичай є
синонімом імені відношення, що описує даний факт. Наприклад:
(time 18:30)
(female Jane)
(male John)
Факти,
сформовані
на
основі
опису
конструкції
deftemplate,
визначаються наступним чином:
< template-RHS-pattern > ::= (deftemplate-name <RHS-slot>*)
<RHS-slot> ::= <single-field-RHS-slot> | <multifield-RHS-slot>
<single-field-RHS-slot> ::= (<<slot-name> <RHS-field>)
<multifield-RHS-slot> ::= (<<slot-name> <RHS-field>*)
Для початку логічного висновування в робочу пам’ять додаються
початкові факти, що визначають постановку задачі. Конструкція deffacts
дозволяє визначити набір апріорних або початкових знань у вигляді набору
фактів. Коли середовище CLIPS перезавантажується (використовуючи
команду reset), кожен факт вказаний в конструкті deffacts в базі знань CLIPS
додається до списку фактів. Синтаксис конструкції визначається наступним
чином:
17
(deffacts <deffacts-name> [<comment>]
<RHS-pattern>*)
Зв’язування значень одних і тих самих змінних, представлених в різних
фактах, реалізовано механізмом глобальних змінних. Конструкція defglobal
дозволяє визначати змінні, які є глобальними за масштабами всього
середовища CLIPS. Тобто глобальну змінну можна отримати в будь-якому
місці CLIPS і вона зберігає своє значення незалежно від інших конструкцій.
Опис конструкції визначається наступним чином:
<defglobal-construct> ::= (defglobal [<defmodule-name>] <global-assignment>*)
<global-assignment> ::=
<global-variable> = <expression>
<global-variable> ::= ?*<symbol>*
Таким чином визначаються базові конструкції представлення даних в
CLIPS.
1.3.2.2 Представлення правил
Одним з основних методів представлення знань у CLIPS є правило.
Правило - це множини умов і дій, які необхідно застосувати у випадку
виконання умов. Правила визначаються з використанням конструкції defrule.
Повний опис конструкції опису правила наведено в довіднику
користувача CLIPS
[10] . Наведемо загальний випадок представлення
правила :
<defrule-construct> ::= (defrule <<rule-name> [<comment>] [<declaration>]
<conditional-element>*
=> <action>)
<declaration> ::= (declare <<rule-property>+)
<<rule-property> ::= (salience <integer-expression>) | (auto-focus <booleansymbol>)
<boolean-symbol> ::= TRUE | FALSE
<conditional-element> ::= <pattern-CE> | <assigned-pattern-CE> | <not-CE> |
<and-CE> | <or-CE> | <logical-CE> | <test-CE> | <exists-CE> | <forall-CE>
<pattern-CE> :: =
<ordered-pattern-CE> | <template-pattern-CE> | <object-
pattern-CE>
<assigned-pattern-CE> ::= <single-field-variable> <- <pattern-CE>
18
<ordered-pattern-CE> ::= (<symbol> <constraint>*)
<template-pattern-CE> ::= (<deftemplate-name><LHS-slot>*)
<LHS-slot> ::= <single-field-LHS-slot> | <multifield-LHS-slot>
<single-field-LHS-slot> ::= (<slot-name> <constraint>)
<multifield-LHS-slot> ::= (<slot-name> <constraint>*)
<constraint> ::= ? | $? | <connected-constraint>
Правило CLIPS обов’язково має назву. Додатково можна додати
єдиний коментар заголовка правила, який вказується після імені правила і
перед першим шаблоном. Повторне додавання правила з тим самим ім’ям
призводить до того, що попереднє буде видалено, навіть якщо нове
визначення містить помилки.
Частина LHS складається з серії умовних елементів (condition elements
- СЕ), які зазвичай складаються з умовних елементів шаблону (або просто
шаблонів). За замовчанням умовні елементи лівої частини пов’язані логічним
зв’язком «і». Частина RHS містить перелік дій, які необхідно виконати, коли
LHS шаблони узгоджено.
Якщо LHS не містить умовних елементів, правило активується
автоматично.
1.3.2.3 Визначення модулів
CLIPS забезпечує підтримку модульної розробки та запуску баз знань.
Модулі визначаються за допомогою конструкції defmodule:
(defmodule <module-name> [<comment>] <port-specification>*)
<port-specification> ::= (export <port-item>) | (import <module-name> <portitem>)
<port-item> ::= ?ALL | ?NONE |<port-construct> ?ALL |<port-construct> ?NONE |
<port-construct> <construct-name>+
<port-construct> ::= deftemplate | defclass | defglobal | deffunction |defgeneric
Defmodule не можна перевизначити або видалити після його
оголошення (за винятком модулю MAIN, який можна перевизначити один
19
раз). Єдиний спосіб видалити модуль - це команда clear. Після запуску і після
clear команди CLIPS автоматично будує наступний модуль:
(defmodule MAIN).
Конструкції одного модуля не можуть використовуватися іншим, якщо
вони не експортовані або імпортовані з іншого модулю. Специфікація
експорту у визначенні defmodule використовується для позначення того, які
конструкції будуть доступні для інших модулів та які імпортуються з
поточного модулю. Дозволено експортувати лише конструкції deftemplates,
defclasses, defglobals, deffunctions , defgenerics.
Існують три типи експортних специфікацій. По-перше, модуль може
експортувати всі допустимі конструкції (ключове слово ALL). По-друге,
модуль може експортувати всі допустимі конструкції певного типу ( ключове
слово export з назвою типу конструкції, за яким вказується ключове слово
ALL). По-третє, модуль може експортувати конкретні конструкції (ключове
слово export з ім'ям типу конструкції, за яким вказується ім'я однієї або
декількох конструкцій зазначеного типу).
Специфікація імпорту в визначенні defmodule використовується для
позначення того, які конструкції модулю, що визначається, будуть
використовуватися
з
інших
модулів.
Дозволено
імпортувати
лише
конструкції deftemplates, defclasses, defglobals, deffunctions, defgenerics.
Специфікація доступу в імпорті аналогічна до експорту.
Таким чином модулі CLIPS дозволяють керувати доступом до блоків
бази знань. Для цього можна групувати конструкції deffacts, deftemplate,
defrule для явного обмеження доступу з інших модулів.
20
2.
РОБОТА В СЕРЕДОВИЩІ CLIPS
2.3
Інтерфейс середовища
Користувачі CLIPS мають можливістю користуватися середовищем
розробки (IDE) для операційних систем Windows, macOS. Користувачі Unix
систем можуть працювати з CLIPS з командного рядка. Для розробників Java
застосунків було розроблено Java Swing IDE. Детальну інформацію щодо
можливих графічних і програмних інтерфейсів взаємодії можна отримати в
довіднику [24] . В даному посібнику представлено приклади розробки для
операційної системи Windows.
На рисунку 2.1 представлено головне вікно програми з розгорнутим
пунктом меню File. На сьогодні це меню передбачає лише можливість
виходу з середовища розробки.
Рисунок 2.1 – Головне вікно CLIPS IDE
Подібне зменшення опцій в порівнянні з попередньою версією,
пов’язано
в
першу
чергу,
з
відмовою
від
застосування
власного
редактору .clp файлів. Наразі розробник може користуватися будь-яким
зручним йому текстовим редактором (наприклад Notepade++, Subline) для
створення файлів з конструкціями бази знань. В подальшому ці файли
можуть бути завантажені в середовище.
21
Меню Edit містить мінімально необхідний набір команд для
редагування конструкцій при роботі з командного рядка середовища
(рисунок 2.2).
Рисунок 2.2 – Можливості редагування
В меню Environment команди умовно поділяються на два блоки
(рисунок 2.3). Перший з них (на рисунку виокремлено синім кольором)
відповідає за завантаження конструкцій в систему та їх очищення за
необхідності.
Надається можливість завантаження конструкцій у вигляді
текстового файлу (команда Load Constructs) та у вигляді скрипту для
виконання (команда Load Batch).
Рисунок 2.3 – Команди керування завантаженням та виконанням
22
Команда Set Directory дозволяє встановити поточну директорію,
відносно якої будуть виконуватися всі інші команди середовища. Підменю
Clear
відповідає однойменній
команді CLlPS та забезпечує очищення
середовища від попередньо завантажених конструкцій.
Друга група команд меню виповідає за керування виконанням
програми в системі. Команди Reset та Run аналогічні
однойменним
функціям CLIPS. Команди Halt Rules та Halt Execution відповідають за
зупинку виконання програми. Відмінність між командами в тому, що Halt
Rules забезпечує зупинку системи після виконання поточного правила, тоді
як Halt Execution – за першої можливості.
Підменю Agenda Browser дозволяє відстежувати зміни в списку
активації в окремій панелі. Зеленою рамкою виокремлено команди
покрокового оновлення поточного стану конфліктного набору.
На рисунку 2.4 наведено підменю команд відстеження виконання
програми.
Рисунок 2.4 – Команди відстеження виконання програми
23
Помаранчевим кольором відзначено конструкції, які найчастіше
відстежуються в підменю Watch. Зеленим кольором відзначено підменю, яке
дозволяє обрати відстеження статистичних даних щодо процесу виконання.
Дана статистика передбачає надання інформації щодо швидкодії, кількості
активованих та виконаних правил в процесі висновування.
Користувач також може обрати опцію відстеження всієї інформації
(підпункт All) або ж - жодної (підпункт None). В останньому випадку на
екран буде виводитися мінімально необхідна кількість інформації у вигляді
умовних позначень (наприклад, щодо перебігу виконання компіляції).
На рисунку 2.5 відображено панель відстеження етапу активації при
виконанні програми визначення родинних зв’язків після запуску одного
правила.
Система
дозволяє
покрокове
виконання
правил
з
метою
відслідковування станів Agenda та Work memory.
Рисунок 2.5 – Відстеження списку активацій
Підменю Fact Browser (рисунок 2.6) дозволяє відстежувати додавання
та видалення фактів WM в процесі висновування. Початково задані
факти розподіллено за модулями. Надається можливість їх пошуку. Таким
24
чином дане підменю забезпечує моніторинг всіх фактів, як представлених в
програмі, так і задіяних в висовуванні.
Рисунок 2.6 – Відстеження списку фактів
Меню допомоги Help містить посилання не лише на офіційну
документацію, але й на форуми, де користувач може задати питання щодо
роботи системи або написання програмного коду (рисунок 2.7).
Рисунок 2.7 – Посилання на корисні джерела документації CLIPS
25
Варто зазначити, що на питання щодо системи найчастіше відповідає
саме її розробник – Garry Raily, надаючи детальні пояснення та додаткові
приклади
2.4
Приклади виконання програм
Необхідно створити базу знань, яка описує родинні зв’язки на основі
початкового набору впорядкованих фактів.
Правила, які задають відношення між членами родини на основі
впорядкованих фактів, можна представити наступним чином:
(defrule is_parent
(or (father ?x ?y) (mother ?x ?y))
=>
(assert (parent ?x ?y)))
(defrule is_grandparent
(and (parent ?x ?y) (parent ?y ?z))
=>
(assert (grandparent ?x ?z)))
(defrule is_grandfather
(and (father ?x ?y) (parent ?y ?z))
=>
(assert (grandfather ?x ?z)))
(defrule is_grandmother
(and (mother ?x ?y) (parent ?y ?z))
=>
(assert (grandmother ?x ?z)))
Рисунок 2.8 Фрагмент програми з визначення родинних зв’язків:
привила (файл family.cls)
Окрім правил необхідний початковий набір фактів. Нехай Richard є
батьком John, Jane матір’ю John, а Mark батьком Richard. Графічно такі
відношення можна представити наступним чином:
26
Mark
fath
er
Richard
Jane
mothe
fath
er
John
Рисунок 2.10 – Графічне представлення сімейних відносин
Очевидно, що Richard та Jane є батьками John, а Mark - його дідусем.
Початковий набір фактів:
(deffacts families
(father Richard John)
(mother Jane John)
(father Mark Richard))
Рисунок 2.9 – Фрагмент програми з визначення родинних зв’язків:
початковий набір фактів (файл family.cls)
Запуск програми можна здійснити без використання відстеження:
1) завантажується початковий файл:
(load family.cls)
2) оновлюється множина заданих фактів:
(reset)
3) запускається скомпільований файл:
(run)
Після цього отримується результат відповідно до відношень,
зазначених в правилах (рисунок 2.11).
Для отримання поточного списку
фактів з родинними зв’язками доцільно скористатися командою (facts).
27
Рисунок 2.11 – Результат визначення родинних зв’язків
Для відстеження процесу виконання до завантаження файлу необхідно
встановити в меню Debug => Watch спостереження за Compilation, Facts,
Rules, Statistics.
Рисунок 2.12 – Результат визначення родинних зв’язків з відстеженням
конструкцій програми
28
На останньому рисунку, на відміну від попереднього, зазначено факти
та конструкції, які було додано в середовище CLIPS.
Подальші дії аналогічні вищезазначеним етапам 2 (рисунок 2.12), 3
(рисунок 2.13).
Рисунок 2.13 – Результат виконання команди reset
На рисунку 2.14 наведено результат запуску з додатковою інформацією
відстеження. Якщо параметри Debug не були налаштовані, після цієї
команди не буде жодної інформації, тільки запрошення до вводу наступної
команди CLIPS.
Рисунок 2.14 – Відстеження виконання програми
Для визначення результату виконаємо команду:
(facts)
29
Результатом виконання програми є додавання в систему нових
доведених фактів (рисунок 2.15).
Рисунок 2.15 – Кінцевий стан робочої пам’яті
30
3. КОМПЮТЕРНИЙ ПРАКТИКУМ 1: РЕАЛІЗАЦІЯ МАШИНИ
СТАНІВ В CLIPS
Задача була запропонована в рамках курсу CPS 499-03: Emerging
Languages, Spring University of Dayton у 2017 році [25].
Наведемо приклад виконання завдання:
реалізувати машину станів, яка приймає рядки мови L, заданої
алфавітом {a, b}, лише у випадку, коли кількість літер a вхідного рядка
кратна 3.
3.1
Представлення машини станів
При реалізації машини станів першим етапом є побудова її графічного
відображення, що дозволяє наочно представити множину станів та переходів
між ними.
В даному завданні на вхід машини подається послідовність літер a, b.
Позначимо N кількість літер a в послідовності. Відповідно до значення N
передбачаються такі стани:
1. N = 0 (немає жодної літери a) або N mod 3 = 0 (кількість літер a
вхідного рядка кратна 3)
2. N =1 або N mod 3 = 1
3. N =2 або N mod 3 = 2
На рисунку 15 представлено відповідну машину станів, де позначки
вершин відповідають нумерації станів, а стрілки – переходам між станами
[26] . Початковий стан 1 є єдиним термінальним станом, який забезпечує
коректну обробку рядка. Всі решта станів відповідають некоректному
вхідному рядку, з кількістю літер a не кратній трьом.
31
Рисунок 3.1 – Машина станів
Якщо в послідовності поточною літерою є b, то вона пропускається і
стан залишається тим самим; якщо – a, то відбувається перехід до наступного
стану.
3.1.1 Реалізація компонентів машини станів
Вхідний рядок символів пропонується зберігати в глобальній змінній,
ініціалізованій пустим рядком (Рисунок 3.2, перший рядок). Для зчитування
вхідного рядка реалізовано правило, в якому відсутня ліва частина, тобто, яке
виконується за замовчуванням:
(defglobal ?*input* = "")
(defrule state_input
=>
(println crlf "Input String" crlf)
(bind ?*input* (read))
(assert (state 1)))
Рисунок 3.2 – Задання та зчитування вхідного рядку символів
Стани представимо впорядкованими фактами виду:
(state 1)
(state 2)
(state 3)
32
3.1.2 Реалізація переходів між станами
Задачу в CLIPS можна представити двома способами:
1) представлення кожного стану у вигляді окремого правила;
2) представлення єдиного правила переходів між станами.
Перший
підхід дозволяє спростити роботу з відстеження процесу
виконання програми та її тестування. Таким чином, в першій версії
отримуємо наступні три правила:
; ver.1
(defrule state_1
?current <- (state 1)
(test(not (eq ?*input* "")))
=>
(retract ?current)
(if (eq (sub-string 1 1 ?*input*) "a")
then (assert (state 2))
else (assert (state 1)))
(bind ?*input* (sub-string 2 (str-length ?*input*) ?*input*)))
(defrule state_2
?current <- (state 2)
(test(not (eq ?*input* "")))
=>
(retract ?current)
(if (eq (sub-string 1 1 ?*input*) "a")
then (assert (state 3))
else (assert (state 2)))
(bind ?*input* (sub-string 2 (str-length ?*input*) ?*input*)))
(defrule state_3
?current <- (state 3)
(test(not (eq ?*input* "")))
=>
(retract ?current)
(if (eq (sub-string 1 1 ?*input*) "a")
then (assert (state 1))
else (assert (state 3)))
(bind ?*input* (sub-string 2 (str-length ?*input*) ?*input*)))
Рисунок 3.3 – Правила переходів між станами при окремому
представленні кожного стану
33
Коректне завершення обробки вхідного рядка відповідає стану 1,
некоректне - станам 2 та 3. Ця інтерпретація знаходить відображення у
наступних правилах:
(defrule state_accept
(state 1)
(test(eq ?*input* ""))
=>
(println crlf "Accepted" crlf))
(defrule state_reject
(state 2|3)
(test(eq ?*input* ""))
=>
(println crlf "Rejected" crlf))
Рисунок 3.4 – Правила визначення кінцевого стану
В другій версії машина станів побудована лише на одному загальному
правилі для представлення станів та переходів:
; ver.2
(defrule state_machine
?current <- (state ?x)
(test(not (eq ?*input* "")))
=>
(retract ?current)
(if (eq (sub-string 1 1 ?*input*) "a")
then
(if (eq ?x 3)
then (assert (state 1))
else (assert (state (+ ?x 1))))
else (assert (state ?x)))
(bind ?*input* (sub-string 2
length ?*input*) ?*input*)))
(str-
Рисунок 3.5 – Єдине правило переходів між станами
Таке правило більш лаконічне, але дещо складніше для розуміння.
Відслідкуємо, яким чином відбуваються компіляція та виконання обох
версій програми.
34
3.1.3 Компіляція та виконання
Для запуску програми на виконання необхідно завантажити файл за
допомогою головного меню програми або викликавши функцію load з
командного рядку.
В результаті позитивного результату компіляції
представляється інформація щодо визначених конструкцій. В даному
випадку в системі знаходиться одна глобальна змінна та шість правил:
Рисунок 3.6 – Результат компіляції програми представлення машини
станів, ver.1
Для оновлення списку фактів необхідно скористатися командою reset.
Для запуску програми викликається команда run.
У
випадку
коректного
введення
рядка
користувач
отримує
повідомлення Accepted:
35
Рисунок 3.7 – Результати виконання програми представлення машини
станів, ver.1, для коректного вхідного рядка
Якщо кількість літер а не кратна трьом, на виході отримується
повідомлення Rejected.
Рисунок 3.8 – Результати виконання програми представлення машини
станів, ver.1, для некоректного вхідного рядка
Для відслідковування змін робочої пам’яті в процесі виконання
програми можна використовувати команду watch fact, яка доступна з
командного рядка або з меню опцій відстеження програми. Додавання факту
36
в робочу пам’ять позначається символом ==> та індексом. Видалення факту з
робочої пам’яті позначається символом <== та індексом.
Відстеження фактів дозволяє впевнитися, що для коректного рядка
останнім доданим фактом буде (state 1):
Рисунок 3.9 – Відстеження змін робочої пам’яті для коректного рядка
Після зчитування вхідного ряжка система перебуває в стані 1. Після
зчитування першої літери а вхідного рядка aaba, система переходить в стан 2,
що відповідає видаленню факту за індексом f-1 та додаванню факту f-2.
Обробка літери а в рядку aba зумовить перехід до стану 3 і видалення f-2 та
додавання f-3 відповідно. Обробка літери b не призводить до зміни стану,
однак факт f-3 видаляється з робочої пам’яті, а f-4 додається, щоб уникнути
зупинки
виведення
внаслідок
рефракції.
Рефракція
зазвичай
37
використовується для уникнення зациклення, коли правило повторно
активується тим самим фактом. Остання літера a призводить до переходу в
стан 1 з видаленням факту f-4 та додаванням факту f-5.
Для некоректного вхідного рядка “bba” останнім фактом, доданим до
робочої пам’яті, буде (state 2):
Рисунок 3.10 – Відстеження змін робочої пам’яті для некоректного
рядка
Таким чином, при заданні коректного вхідного рядку CLIPS завершує
роботу повідомленням «Accepted», в протилежному випадку – «Rejected».
Перед запуском другого варіанту програми бажано очистити систему
за допомогою команди clear, щоб впевнитися, що в ній не міститься жодних
фактів, крім початкового. Результат компіляції другої версії програми
підтверджує, що в системі визначено одну глобальну змінну та чотири
правила:
38
Рисунок 3.11 – Результат компіляції програми представлення машини
станів, ver.2
Результати виконання першої та другої версії очікувано однакові (для
коректного та некоректного вхідного рядка):
Рисунок 3.12 – Результати виконання програми представлення машини
станів, ver.2
39
Відстеження фактів робочої пам’яті на коректному вхідному рядку
показує результати аналогічні першій версії:
Рисунок 3.13 – Відстеження змін робочої пам’яті для коректного рядка,
ver.2
Змінивши некоректний вхідний рядок на “abba”, можна впевнитися,
що для кількості літер а, кратної двом, програма закінчує свою роботу у стані
3.
Таким чином, результати роботи обох програм є аналогічними. В той
же час, перший варіант є простішим для розуміння та безпосередньо
відповідає опису машини станів. Для кожного стану створюється окреме
правило, що забезпечує модульність та простоту модифікації. Друга версія
програми є більш загальною, використовує додаткові конструкції мови.
Реалізація такого підходу може потребувати більше часу, але й забезпечить
краще розуміння викладеного матеріалу.
40
Рисунок 3.14 – Відстеження змін робочої пам’яті для некоректного
рядка, ver.2
При
виконанні
індивідуального
завдання
достатньо
здійснити
реалізацію за одним зі зазначених способів.
3.2 Завдання комп’ютерного практикуму
Мета: навчитись роботі в середовищі CLIPS.
Завдання: побудувати машину станів.
1.
Побудувати машину станів, що приймає на вхід рядки з мови, заданої
алфавітом {a, b, c}, в яких кількість комбінацій “aa” кратна 2.
41
2.
Побудувати машину станів, що приймає на вхід рядки з мови, заданої
алфавітом {a, b, c, e}, в яких прийнятними є лише комбінації “abc”, “cba”,
“ea”, “abe”.
3.
Побудувати машину станів, що дозволяє локалізувати рядок “abba” в
мові, заданій алфавітом {a, b}
4.
Побудувати машину станів, що за мовою, заданою алфавітом {0, 1},
повертає А для вхідного рядка, що закінчується на 10, В - для вхідного рядка,
що закінчується на 11, та С - у всіх інших випадках.
5.
Побудувати машину станів, що за мовою, заданою алфавітом {a, b},
виводить 1 для кожного входження підрядка “aab”.
6.
Побудувати машину станів, що приймає на вхід рядки з мови, заданої
алфавітом {a, b, c}, в яких комбінація “abc” зустрічається не більше трьох
разів.
7.
Побудувати машину станів, що дозволяє локалізувати рядок “abb” в
мові, заданій алфавітом {a, b, c}
8.
Побудувати машину станів, що приймає на вхід рядки з мови, заданої
алфавітом {a, b, c}, в яких кількість комбінацій “abc” кратна 2.
9.
Побудувати машину станів, що приймає на вхід рядки з мови, заданої
алфавітом {a, b, c, e}, в яких прийнятними є лише комбінації “abce”, “cba”,
“ea”, “abe”.
10.
Побудувати машину станів, що за мовою, заданою алфавітом {0, 1},
повертає True для вхідного рядка, що закінчується на 01, False - для вхідного
рядка, що закінчується на 10, та Undefined - у всіх інших випадках.
42
4.
КОМП'ЮТЕРНИЙ ПРАКТИКУМ 2: РОЗВ’ЯЗАННЯ ЗАДАЧІ
ПОШУКУ В ПРОСТОРІ СТАНІВ В CLIPS
Задача пошуку в просторі станів є класичним методологічним
прикладом для отримання навичок представлення знань в продукційних
системах [3]
Наведемо приклад виконання завдання – задача фермера [27]:
якось фермер пішов на ринок та купив лисицю, козу і капусту. По
дорозі додому, фермер підійшов до річки і найняв човен для переправи. Але
у човен може поміститись він сам і лише одна із його покупок – лисиця, коза
або капуста. Якщо залишити їх самих, лисиця з'їсть козу, а коза – капусту.
Завдання фермера переправитись самому та перевезти всі свої покупки на
протилежний берег річки.
4.1
Представлення компонентів представлення пошуку в просторі
станів
Приклад вирішення цієї задачі наведено в репозиторії програмного
інструментарію CLIPS [28]
Пропонується визначити такі модулі:
MAIN - визначення станів системи та правил переходу між ними;
CONSTRAINTS -
визначення обмежень на правила переходів між
станами;
SOLUTION - для ідентифікації та виведення рішення.
4.1.1 Представлення стану
Для представлення формату стану доречно скористатися конструкцією
deftemplate:
43
(deftemplate MAIN::status
(slot
search-depth
(type
INTEGER)
(range
1 ?VARIABLE))
(slot parent (type FACT-ADDRESS SYMBOL) (allowedsymbols no-parent))
(slot farmer-location
(type SYMBOL) (allowed-symbols shore-1 shore-2))
(slot fox-location
(type SYMBOL) (allowed-symbols shore-1 shore-2))
(slot goat-location
(type SYMBOL) (allowed-symbols shore-1 shore-2))
(slot cabbage-location
(type SYMBOL) (allowed-symbols shore-1 shore-2))
(slot last-move
(type SYMBOL) (allowed-symbols no-move alone fox
goat cabbage)))
Рисунок 4.1 – Опис формату стану
Відповідно до заданого опису стан системи визначається поточною
глибиною пошуку, батьківським вузлом, визначенням останнього переходу
та поточним положенням фермера, кози, лисиці та капусти. Положення
визначається як один з двох берегів (shore-1 або shore-2). Передбачаються
наступні варіанти переміщень: залишитися на місці (no-move) - лише для
початкового стану, фермер їде один (alone) або з лисицею (fox ), або з козою
(goat), або з капустою (cabbage).
Початковий стан системи визначається наступним фактом:
(deffacts MAIN::initial-positions
(status (search-depth 1)
(parent no-parent)
(farmer-location shore-1)
(fox-location shore-1)
(goat-location shore-1)
(cabbage-location shore-1)
(last-move no-move)))
Рисунок 4.2 – Представлення початкового стану
44
Додатково для зручності додається факт, який визначає взаємне
розташування берегів:
(deffacts MAIN::opposites
(opposite-of shore-1 shore-2)
(opposite-of shore-2 shore-1))
Рисунок 4.3 – Визначення протилежного берега
Цільовий стан визначається аналогічно програмі з рисунку 4.2.
Рішенням вважається список переходів до стану, коли всі об’єкти
знаходяться на протилежному березі.
4.1.2 Представлення переходів між станами
Для кожного варіанту переміщення з берегу на берег доцільно
представити окреме правило переходу:
(defrule MAIN::move-alone
?node <- (status (search-depth ?num)
(farmer-location ?fs))
(opposite-of ?fs ?ns)
=>
(duplicate ?node (search-depth =(+ 1 ?num))
(parent ?node)
(farmer-location ?ns)
(last-move alone)))
Рисунок 4.4 – Правило переправи фермера без вантажу
Якщо фермер рухається один, то лише він змінює свої поточне
положення на протилежний берег. Батьківським вузлом стає попереднє
положення. Відповідно оновлюються також поля глибини пошуку та
останнього вантажу. Зверніть увагу, що в результаті виконання правила в
систему додається новий факт без видалення попереднього. Це дозволить
відслідкувати переміщення при виведенні кінцевого рішення, рухаючись у
зворотному напрямку від кінцевого факту до батьківських.
45
(defrule MAIN::move-with-fox
?node <- (status (search-depth ?num)
(farmer-location ?fs)
(fox-location ?fs))
(opposite-of ?fs ?ns)
=>
(duplicate ?node (search-depth =(+ 1 ?num))
(parent ?node)
(farmer-location ?ns)
(fox-location ?ns)
(last-move fox)))
(defrule MAIN::move-with-goat
?node <- (status (search-depth ?num)
(farmer-location ?fs)
(goat-location ?fs))
(opposite-of ?fs ?ns)
=>
(duplicate ?node (search-depth =(+ 1 ?num))
(parent ?node)
(farmer-location ?ns)
(goat-location ?ns)
(last-move goat)))
(defrule MAIN::move-with-cabbage
?node <- (status (search-depth ?num)
(farmer-location ?fs)
(cabbage-location ?fs))
(opposite-of ?fs ?ns)
=>
(duplicate ?node (search-depth =(+ 1 ?num))
(parent ?node)
(farmer-location ?ns)
(cabbage-location ?ns)
(last-move cabbage)))
Рисунок 4.5 – Правила переправи фермера з вантажем
У випадку, коли фермер переміщається з однією зі своїх покупок
відповідно додаються факти про зміну їх положення:
Для відстеження неприпустимих переміщень (коли хтось когось з’їдає)
та
переміщень,
які
призводять
до
зациклень,
створено
модуль
CONSTRAINTS.
46
У випадку неприпустимого переміщення відбувається автоматичне
фокусування на правилі, яке відтинає пошук за даним переходом:
(defmodule CONSTRAINTS
(import MAIN deftemplate status))
(defrule CONSTRAINTS::fox-eats-goat
(declare (auto-focus TRUE))
?node <- (status (farmer-location ?s1)
(fox-location ?s2&~?s1)
(goat-location ?s2))
=>
(retract ?node))
(defrule CONSTRAINTS::goat-eats-cabbage
(declare (auto-focus TRUE))
?node <- (status (farmer-location ?s1)
(goat-location ?s2&~?s1)
(cabbage-location ?s2))
=>
(retract ?node))
Рисунок 4.6 – Правила визначення неприпустимих станів
Для уникнення циклів сформовано правило видалення факту, що
призвів до переходу у стан, який зустрічався раніше:
(defrule CONSTRAINTS::circular-path
(declare (auto-focus TRUE))
(status (search-depth ?sd1)
(farmer-location ?fs)
(fox-location ?xs)
(goat-location ?gs)
(cabbage-location ?cs))
?node <- (status (search-depth ?sd2&:(< ?sd1 ?sd2))
(farmer-location ?fs)
(fox-location ?xs)
(goat-location ?gs)
(cabbage-location ?cs))
=>
(retract ?node))
Рисунок 4.7 – Правило уникнення зациклення
47
В модулі ідентифікації рішення SOLUTION представлено шаблон
кінцевого стану задачі:
(deftemplate SOLUTION::moves
(slot id (type FACT-ADDRESS SYMBOL) (allowed-symbols no-parent))
(multislot moves-list
(type SYMBOL) (allowed-symbols no-move alone fox goat cabbage)))
Рисунок 4.8 – Шаблон визначення кінцевого стану
Для
додавання факту за заданим шаблоном сформовано правило
розпізнавання рішення:
(defrule SOLUTION::recognize-solution
(declare (auto-focus TRUE))
?node <- (status (parent ?parent)
(farmer-location shore-2)
(fox-location shore-2)
(goat-location shore-2)
(cabbage-location shore-2)
(last-move ?move))
=>
(retract ?node)
(assert (moves (id ?parent) (moves-list ?move))))
Рисунок 4.9 – Правило розпізнання рішення
Для запису в багатозначний слот переходів, які призвели до кінцевого
стану, застосовується наступне правило:
(defrule SOLUTION::further-solution
?node <- (status (parent ?parent)
(last-move ?move))
?mv <- (moves (id ?node) (moves-list $?rest))
=>
(modify ?mv (id ?parent) (moves-list ?move ?rest)))
Рисунок 4.10 – Правило визначення списку переходів, які
призвели до рішення
48
Щойно першим значенням слоту переходів буде визначено початкове
положення no-move, система готова вивести рішення користувачу:
(defrule SOLUTION::print-solution
?mv <- (moves (id no-parent) (moves-list no-move $?m))
=>
(retract ?mv)
(println crlf "Solution found: " crlf)
(bind ?length (length$ ?m))
(bind ?i 1)
(bind ?shore shore-2)
(while (<= ?i ?length)
(bind ?thing (nth$ ?i ?m))
(if (eq ?thing alone)
then (println "Farmer moves alone to " ?shore ".")
else (println "Farmer moves with " ?thing " to " ?shore "."))
(if (eq ?shore shore-1)
then (bind ?shore shore-2)
else (bind ?shore shore-1))
(bind ?i (+ 1 ?i)))
(println))
Рисунок 4.11 – Виведення рішення користувачеві
Програми з рисунків 4.1 – 4.11 визначають постановку задачі фермера.
4.1.3 Компіляція та виконання
Після завантаження програми з заданим відстеженням компіляції
отримуємо перелік правил відповідно до модулів їх опису (рисунок 4.12).
В результаті компіляції в системі визначаються 3 модулі MAIN,
CONSTRAINTS
та
SOLUTION
з
відповідно
правилами
переходу,
виключення неприпустимих станів та визначення кінцевого стану. При
завантаженні програми система виведе попередження про повторне
оголошення модулю MAIN. Це пояснюється тим, що в системі CLIPS за
замовчуванням всі правила оголошуються саме в модулі MAIN. В головному
модулі також наведено шаблон опису стану задачі status та початковий стан
initial-state.
49
Рисунок 4.12 – Результат компіляції програми пошуку в просторі станів
Для запуску програми на виконання необхідно виконати команди reset
та run:
Рисунок 4.13 – Результат виконання пошуку в просторі станів
50
У результаті виконання програми було знайдено два рішення,
перевірка яких доводить коректність представлених правил переходу.
4.2
Мета:
Завдання комп'ютерного практикуму
навчитись
реалізовувати
пошук
у
просторі
станів,
використовуючи продукційну модель подання знань.
Завдання: знайти шлях між початковим та кінцевим станами.
1. Джентльменам і їхнім дружинам необхідно переправитися через річку
в човні, який вміщує не більше двох осіб. Кожен джентльмен може
залишити свою дружину на березі або на самоті, або в суспільстві
інших дам. Крім того після кожної переправи хтось повинен приганяти
човен назад, щоб ним могли скористатися ті, хто ще не встиг
переправитися. Яким чином здійснити переправу?
2. Фермер бажає переправити лева, лисицю, гусака і кукурудзу через
річку. В його розпорядженні є човен. В одну поїздку фермер може
взяти або одного пасажира, або гусака і кукурудзу, або лисицю і
кукурудзу. Кукурудза не може бути залишена з гусаком, лисиця - з
гусаком, а лев - з лисицею. Яким чином всі були переправлені через
річку? Вважати, що тварини не втечуть, якщо залишаться на самоті.
3. Чотири дівчинки, кожна зі своїм батьком, підійшли до річки і побажали
переправитися з одного берега на інший. У їх розпорядженні виявився
човен без весляра, який вміщує не більше двох осіб. Посеред річки є
острів, на якому можна висаджуватись. Як здійснити переправу так,
щоб ні на березі, ні на острові, ні в човні жодна дівчинка не перебувала
з чужим батьком без свого?
4. Завдання полягає в переміщенні пірамідки з 20 дисків з одного стрижня
на інший, з використанням двох допоміжних стрижнів. Переміщення
51
здійснюється за такими правилами: за один хід можна перенести лише
один диск, і більший диск не можна встановлювати на менший.
5. Три лицаря, кожен у супроводі зброєносця, з'їхалися на березі річки,
маючи намір переправитися на іншу сторону. Їм вдалося знайти
маленький двомісний човен, і переправа сталася б легко. Але всі
зброєносці навідріз відмовилися залишатися в суспільстві незнайомих
лицарів без своїх господарів. І все ж переправа відбулася, всі шестеро
людей перебралися на інший берег за допомогою одного двомісного
човна. При цьому дотримувалася умова, на якій наполягали зброєносці.
Як це було зроблено?
6. Три людини, велика мавпа і дві маленькі мавпочки хочуть
переправитися через річку. Тільки люди і велика мавпа можуть
керувати човном. У будь-який час кількість людей на березі річки
повинна бути більшою або рівною кількості мавп на тому ж березі.
(Інакше мавпи нападуть на людей!) Човен розрахована на двох
пасажирів. (Мавп або людей.)
7. У пакеті міститься 9 кг крупи. Необхідно за допомогою чашкових ваг з
гирями в 50 і 200 грамів розподілити всю крупу за двома пакетами: в
один - 2 кг, в іншій - 7 кг. Враховувати, що можна поділити навпіл без
використання гир.
8. Підійшли до річки англієць, француз та індіанець, кожен зі своєю
дружиною. Всім потрібно переправитися на інший берег. У їх
розпорядженні знаходиться один човен без весляра, здатний вмістити
двох. Але виявилось, що жодна з дружин не бажає переправлятися в
човні з чужим чоловіком або залишатися на березі в чоловічому
товаристві без свого чоловіка. Як вони зуміли переправитися?
9. Чотири лицаря, кожен у супроводі зброєносця, зібралися на березі
річки, маючи намір переправитися на іншу сторону. Їм вдалося знайти
маленький тримісний човен. Переправа сталася б легко, але все
зброєносці навідріз відмовилися залишатися в суспільстві незнайомих
52
лицарів без своїх господарів. І все ж переправа відбулася, всі вісім
чоловік перебралися на інший берег за допомогою одного тримісного
човна. При цьому дотримувалася умова, на якій наполягали зброєносці.
Як це було зроблено?
10. Під час повені п'ять подружніх пар виявилися відрізаними від суші
водою. У їх розпорядженні був один човен, який міг одночасно
вмістити тільки трьох осіб. Кожен чоловік був настільки ревнивий, що
не міг дозволити своїй дружині перебувати в човні або на будь-якому
березі з іншим чоловіком (або чоловіками) в його відсутність. Знайти
спосіб переправити цих чоловіків і їх дружин.
53
ПЕРЕЛІК ПОСИЛАНЬ
1. Post E. Formal reductions of the general combinatorical problem. Americal
Jornal of Mathematics. 1943. Nо. 65. pp. 197–268.
2. Субботін С. , Подання й обробка знань у системах штучного інтелекту та
підтримки прийняття рішень. Запоріжжя: ЗНТУ. 2008. 341 с.
3. Люгер Дж. Искусственный интеллект: стратегии и методы решения
сложных проблем, 4-е изд. Москва. Вильямс, 2004. 864 с.
4. Production System Models of Learning and Development / edited by D.
Klahr, P. W. Langley, R. T. Neches. MIT Press Cambridge. 1987. 492 c.
5. Forgy C. On the Efficient Implementation of Production System: Ph.D.
Dissertation. Carnegie Mellon University. 1979. 210 p.
6. McDermott J., Forgy C., Production Systems Conflict Resolution Strategies.
Patern-Directing inference system/ D.A. Waterman, F. Hayes-Roth. 1978. pp. 177
-199.
7. Шаповалова С.І., Мажара О.О. Середовище CLIPS розробки експертних
систем малого бізнесу для планшетів. Економічна безпека держави:
стратегія, енергетика, інформаційні технології: монографія / за наук. ред.
С.О. Лук’яненко, Н.В Караєвої. Київ, 2014. С. 424-432.
8. Logic
Production
Systems.
Imperial
College
London.
URL:
http://lps.doc.ic.ac.uk/.
9. Шаповалова С.І., Мажара О.О. Вибір та обґрунтування програмних засобів
розробки продукційних систем. Обчислювальний інтелект (результати,
проблеми, перспективи): матеріали ІІІ міжн. наук.-техн. конф. Черкаси. 2015.
С.406.
10. Riley
G.
CLIPS
Online
Documentation.
Sourceforge.
URL:
http://clipsrules.sourceforge.net/OnlineDocs.html.
11. Friedman-Hill E. The Rule Engine for the Java . URL: https://jessrules.com/.
12. Young D. E. Intelligent Agents for Lisp: The Lisa Project. Sourceforge. 2013.
URL: https://sourceforge.net/projects/lisa/
54
13. WebSphere ILOG Rules for .NET Business Rule Management System
(BRMS). ILOG. URL: http://www.acardia.co.uk/ibm/ibm-software/ibm-websphere
-experts/websphere-ilog-rules-for-net-business-rule-ma.html.
14. Drools Overview. Drools. URL: https://www.drools.org/.
15. Simulation, Process & Production Control Expert Systems: Gensym.
Ignitetech, URL: https://www.ignitetech.com/gensym/.
16. Decision
Rules
Management
System.
FICO.
URL:
https://www.fico.com/en/products/fico-blaze-advisor-decision-rules-managementsystem.
17. Exsys
Corvid:
Expert
System
Development
Tool.
Exsys.
URL:
http://www.exsys.com/exsyscorvid.html.
18. Logic
Production
Systems.
Imperial
College
London.
URL:
http://lps.doc.ic.ac.uk/.
19. Selman D. JSR 94: JavaRule Engine API. Java Community Process. 2004
URL: https://www.jcp.org/en/jsr/detail?id=94.
20. Reasoning: Goal Trees and Rule-Based Expert Systems: Lecture 3, Course
Description
6.034.
MIT
OPENCOURSEWARE.
URL:
https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-034artificial-intelligence-fall-2010/lecture-videos/lecture-3-reasoning-goal-trees-andrule-based-expert-systems/.
21. CLIPS - an expert system programming language. Ubuntu Manpage
Repository. URL: http://manpages.ubuntu.com/manpages/trusty/man1/clips.1.html.
22. Riley
G.
A
Tool
for
Building
Expert
Systems.
CLIPS.
URL:
http://www.clipsrules.net/CLIPS64.html.
23. Джарратано Дж., Райли Г. Экспертные системы: принципы разработки и
программирование. Москва. 2007. 1152с.
24. Riley
G.
Clips
Reference
Manual.
Sourceforge.
URL:
http://clipsrules.sourceforge.net/documentation/v640/ig.pdf.
25. Watkin J. L.
Systems:
The CLIPS Programming Language for Building Expert
lection.
2017.
University
of
Dayton.
URL:
55
https://www.youtube.com/watch?v=XX8Fxze6Np8.
26. Watkin J. L. An Introduction to the CLIPS Programming Languagee. CPS 499
-03: Emerging Languages, University of Dayton, Ohio 45469–0232 USA, Spring
2017,
4
pages.
URL:http://perugini.cps.udayton.edu/teaching/courses/Spring2017/cps499/Langua
ges/papers/CLIPS.pdf
27. Voolaid P. Carrying a wolf, a goat, and a cabbage across the stream.
Metamorphoses of ATU 1579. 2007.
Folklore. (Estonia) №35. DOI: 10.7592/FEJF2007.35.voolaid
28. CLIPS Rule Based Programming Language: Farmer's Dilemma Problem.
Sourceforge.
URL:
https://sourceforge.net/p/clipsrules/code/HEAD/tree/branches/63x/examples/dilem
ma1.clp.
29. Шаповалова С.І., Мажара О.О. Вибір стратегій розв’язання конфліктів в
продукційних системах Сучасні інформаційні та електронні технології
СИЭТ-2014: труди XV міжн. наук.-практ. конф.: Одеса, 26-30 травня 2014 р.
Одеса: Политехпериодика. 2014. Т.1. С.34-35.
30. CLIPS rule-based language. Silicon valley one. 2017. USA. URL:
http://www.siliconvalleyone.com/founder/clips/index.htm.
56
