13.2. Інформаційна СППР «Super Finance»(«SF 2»)

Створення конкретних систем продукцій дало змогу сформувати деякі підходи до їх проектування і розробити набір методів реалізації окремих компонентів. Необхідність будування системи продукцій для нових ПРГ потребувала скорочення термінів реалізації конкретних систем. Тому наступним кроком у розробці стало використання технології блокового програмування, а саме: виділення стійкого набору модулів, їх ефективна реалізація і генерація проблемно-орієнтованих блоків за замовленням користувача з подальшим складанням їх у прикладну систему. Такий підхід сформувався у вигляді концепції «порожніх» експертних систем, або оболонок.

Розробки проблемно-орієнтованих систем продукцій (ПСП) надали деякий сумарний досвід, що дозволив порушити питання про формування загальної технологічної бази — пакета зі створення й настроювання спеціалізованих і таких, що настроюються систем продукцій, котрі оформляються у вигляді автономних програмних модулів ПСП.

Завдання створення пакета для виробництва потребує розроблення моделі модуля, виділення його основних складових, розгляду типів їх структури та можливих варіантів різних поєднань цих складових, котрі обумовлюють ту чи іншу функціональну орієнтацію кожної конкретної конфігурації ПСП.

Створення метамоделі ПСП дозволяє, з одного боку, розробити схему специфікації модуля, з другого — виділити систему «будівельних блоків», уточнивши спектр варіації кожного з них, і, з третього — визначити спосіб оформлення цих блоків, що забезпечує гнучкий і ефективний інтерфейс між ними. У даному розділі описано в загальному вигляді основні підсистеми ПСП, а потім детальніше розглянуто структуру кожної підсистеми.

У разі якщо розробників прикладної системи влаштовують проектні рішення, прийняті в оболонці, то її використання є одним з найшвидших способів реалізації майбутньої проблемноорієнтованої системи. Проте на практиці введені в оболонках обмеження часто виявляються дуже жорсткими.

Тому нині значного поширення набула ідея створення спеціального програмного оточення розробки систем продукцій (а в загальному випадку експертних систем). Такі системи називають інструментальними, або технологічними, пакетами (knowledge engineering environment, knowledge engineering tool kits). До таких систем відносять EXPERT, AGE, OPS, Super Finance та ін.

На сьогодні завоювали популярність системи підтримки інженерії знань другого покоління. До них відносять KEE, ART та ін. Ці системи використовують багатий спектр можливостей для подання знань і орієнтовані на могутні персональні комп’ютери з організацією «доброзичливого» інтерфейсу на основі багатовіконної графіки. Крім того, відбувається вироблення нової парадигми у розробленні засобів подання знань, коли модель визначає засоби специфікації, а ЕОМ проектується під клас моделей.

Одним зі шляхів руху до цієї нової парадигми є розвиток і впровадження технології розроблення машинних комплексів як пакетів спеціалізованих віртуальних машин. Віртуальна машина визначається як «ідеальна машина, що представляє модель, її структуру, специфічні для моделі типи даних, операції та характер процесу функціонування й обробки інформації».

При цьому все проектування розпочинається від моделі, і лише базові засоби віртуальних машин і їх модулі враховують характер конкретних механізмів реалізації, визначуваних апаратними компонентами системи. Нині технологія віртуальних машин використовується у розробленні бази сучасних систем програмування. Прикладом може служити технологія створення Prolog, Lisp-машин. У теперішній час технологія віртуальних машин використовується для конструювання модулів систем продукцій.

Система підтримки прийняття рішень «Super Finance 2» («SF 2») являє собою програмну оболонку загального користування, що призначена для проведення консультацій користувача в спроектованій БЗ (рис. 4.9). СППР «SF 2» базується на правилах, побудована у вигляді продукційної системи, та генерує граф пошуку. Оболонка системи запрограмована на мові Visual Prolog, та дозволяє реалізувати цільовий пошук відповідно до мети.

Експертна система — обчислювальна система, яка імітує поведінку людського експерта в деякій певній ПРГ. Ідея створення експертної системи полягає в тому, що це може надати можливість багатьом людям отримати вигоду із знання однієї людини

— експерта.

Забезпечуючи базою знань для певної ПРГ, «SF 2» може використовуватися, щоб створити експертну систему, тобто: SF + База знань = Експертна система.

Рис. 4.9. Вигляд інтерфейсу користувача системи «SF 2»

Кожна БЗ містить правила для певної ПРГ. Тому для експертної системи автомобільної діагностики несправностей БЗ міститиме правила, що пов’язують певні ознаки, як, наприклад, надмірні машинні вібрації або відсутність керування і велика швидкість до можливих поганих причин.

Фахівець з питань знань (експерт) спочатку забезпечує систему інформацією у вигляді БЗ залежно від галузі використання системи. Запис діалогу під час створення БЗ відтворюється у вікнах та записується у файл для подальшого користування та консультацій. Створена фахова консультація підключається через меню консультацій (рис. 4.10).

Рис. 4.10. Меню вибору консультаційної бази системи

Розроблена система перевірялася для аналізу та загальної оцінки деяких показників фінансового стану модельного підприємства, виявлення причин погіршення можливостей використання ресурсів, прискорення обігу засобів і зміцнення фінансового стану.

Основним джерелом даних для БЗ системи є звітний бухгалтерський баланс та додатки, звіт про фінансові результати, рух статутного капіталу, інші звітні форми, які деталізують зміст балансу, та дозволяють досліджувати чинники впливу на фінансові показники.

Функціональну структуру експертної системи «SF 2» зображено на рис. 4.11.

Рис. 4.11. Функціональна структура експертної системи «SF 2»

Діалог — це форма консультації з експертною системою «SF 2». На деякі питання користувач відповідає за допомогою вибору з меню, в інших випадках користувачеві необхідно надрукувати відповіді. Консультація завершується висновком, виданим системою, та поясненням послідовності висновку, що привела до цього твердження. Система розпізнає непорозуміння, що виникло через помилку на принциповій основі, та реагує відповідним чином на цю ситуацію. Наприклад, при введені перевіряється тип змінних. Система інтерфейсу використовує мовний інтерпретатор системи, діалоговий процесор та механізм висновку. Механізм висновку повертає знання, виведені з БЗ, та через інтерфейс передає їх назад користувачеві в зручній формі. Інтерфейс з користувачем та оболонка системи можуть розглядатись як «додаток» до БЗ.

Діалоговий процесор створює в системі питання для користувача та забезпечує обґрунтовані висновки системи, відповіді та необхідні конкретні пояснення результатів консультацій (рис. 4.12).

Рис. 4.12. Приклад поради діалогового процесора системи «SF 2»

Ядром експертної системи є БЗ, яка містить знання з аналізу та загальної оцінки деяких показників фінансового стану підприємства. База знань — центральна частина експертної системи, що складається з фактичних знань. Вона містить модель знань — правила, що описують відносини або явища, методи і знання для розв’язання задач з ПРГ системи.

Механізм висновку містить принципи і правила роботи та визначає, як використовувати БЗ так, щоб можна було одержувати висновки, котрі адекватно узгоджуються. Протягом консультації механізм висновку будує граф розв’язання задачі та визначає, які правила потрібно викликати, і організовує доступ до БЗ. Результат пошуку та прийняте рішення передається користувачеві.

База знань містить факти або твердження та правила. Факти є короткостроковою інформацією в тому плані, що вони можуть змінюватися, наприклад, після консультації. Правилами є більш довготривала інформація про те, як породжувати нові факти або гіпотези, враховуючи відомі факти.

Метод подання знань, що використовується в системі, об’єднує декларативне та процедурне подання знань. Декларативне подання знань описує власний логічний висновок. У зв’язку з цим декларативна частина знань володіє достатньою гнучкістю, дозволяє опи-

База знань консультацій є змінною частиною системи та може поповнюватися і модифікуватися. Спосіб подання знань — у вигляді конкретних фактів і правил, з яких можуть бути виведені нові, використовуючи меню системи. В простіших випадках факт виражається значенням параметра атрибута, або простим твердженням, яке може бути істинним або помилковим, наприклад: parameter koef коефіцієнт власного капіталу type text explanation завдяки цим пказникам можна передбачити банкрутство наперед rules бази рисунків параметрів графа бази знань

на початку року if vlast < 60, на кінець періоду if vlast >=60 and vlast < 100, question Ну як, згодні з отриманим результатом ? , invisible.

У базі даних pictures.dba зберігаються рисунки типів: метафайли Windows, залежні точкові малюнки (DDB) і незалежні точкові малюнки (DIB). Система використовує ім’я рисунка як посилання. База даних рисунків підтримує загальні функції БЗ: додавання, редагування, видалення (рис. 4.13). на кінець періоду if vlast >=60 and vlast < 100, question Ну як, згодні з отриманим результатом ? , invisible.

У базі даних pictures.dba зберігаються рисунки типів: метафайли Windows, залежні точкові малюнки (DDB) і незалежні точкові малюнки (DIB). Система використовує ім’я рисунка як посилання. База даних рисунків підтримує загальні функції БЗ: додавання, редагування, видалення (рис. 4.13). на початку року if vlast < 60, на кінець періоду if vlast >=60 and vlast < 100, question Ну як, згодні з отриманим результатом ? , invisible.

У базі даних pictures.dba зберігаються рисунки типів: метафайли Windows, залежні точкові малюнки (DDB) і незалежні точкові малюнки (DIB). Система використовує ім’я рисунка як посилання. База даних рисунків підтримує загальні функції БЗ: додавання, редагування, видалення (рис. 4.13).

Рис. 4.13. а) Меню редагування б) Меню редагування

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

Правила в БЗ призначені для подання евристичних знань, тобто неформальних правил міркування, що виробляються експертом на основі досвіду його діяльності. Дії, що входять до складу правил, можуть містити нові факти. При використанні таких правил ці факти стають відомі системі та стають робочою множиною.

Якщо система не може вивести деякий факт, істинність або помилковість якого необхідно встановити, система запитує про нього користувача. Факти в БЗ записуються у вершині графа у вигляді параметрів за допомогою меню (рис. 4.14), а висновки у вигляді правил: section manevr : розрахунок робочого капіталу

assign m1:=z1/p1 assign m2:=z2/p2 if m1>m2 advice ‘ На кінець звітного періоду запаси у & m2 & разів менше робочого капіталу if m1< m2 advice На кінець звітного періоду запаси у & m2 & разів більше робочого капіталу else … assign m2:=z2/p2 if m1>m2 advice ‘ На кінець звітного періоду запаси у & m2 & разів менше робочого капіталу if m1< m2 advice На кінець звітного періоду запаси у & m2 & разів більше робочого капіталу else … if m1>m2 advice ‘ На кінець звітного періоду запаси у & m2 & разів менше робочого капіталу if m1< m2 advice На кінець звітного періоду запаси у & m2 & разів більше робочого капіталу else … if m1< m2 advice На кінець звітного періоду запаси у & m2 & разів більше робочого капіталу else … assign m1:=z1/p1 assign m2:=z2/p2 if m1>m2 advice ‘ На кінець звітного періоду запаси у & m2 & разів менше робочого капіталу if m1< m2 advice На кінець звітного періоду запаси у & m2 & разів більше робочого капіталу else …

Рис. 4.14. Меню редагування правил графа бази знань Інтерпретатор системи «SF 2» — це модуль з багаторівневим лінгвістичним процесором, який складається з лексичного аналізатора, блоку визначення слів, чисел та констант, блоку трансляції у внутрішню формальну мову, використовує системні бібліотеки Visual Prolog, та призначений для моделювання діалогу користувача і системи.

Модель БЗ в «SF 2» має структуру у вигляді дерева — графа. Система автоматично малює граф БЗ та дозволяє підключати за необхідності модулі зовнішніх баз різних форматів у внутрішній формат програми, що робить систему гнучкою та незалежною від формату зовнішніх даних. Структура БЗ задається у вигляді на-

Рис. 4.15. Приклад структурного дерева бази знань

Процедури пошуку рішень залежать від особливостей ПРГ та вимог, які пред’являють користувачі до цих рішень. Фахова предметна експертна галузь характеризується розміром, мінливістю її в часі та просторі, повнотою моделі, визначеністю даних про поставлене завдання, кількістю необхідних рішень (одне застосовне, або всі допустимі), обмеженнями на результат та параметри, засобом його отримання.

Метод пошуку рішення в просторі станів визначаємо трійкою де

t SFS,,

0 ,

0 S — множина початкових станів системи (запит); F — множина операторів, що перетворюють одні стани на інші; t S — множина кінцевих цільових станів системи.

Процес консультації у системі — це визначення такої послідовності операторів F, які дозволять перетворити початковий стан системи на кінцевий. Процес консультації представляється у

вигляді графа G, де ми розуміємо пару YX,, де t xxxX...

10 = — множина вершин графа, кожна з яких пов’язана з певними стана() ji xx,, належить множині X. У системі ви() ji xx, є по-вигляді графа G, де ми розуміємо пару YX,, де () t xxxX...

10 = — множина вершин графа, кожна з яких пов’язана з певними станами. Y — множина пар () ji xx,, належить множині X. У системі використано орієнтований граф, тобто для кожної пари () ji xx, є по-

правленого графа (рис. 4.15), вузли якого — модулі обробки даних, а ребра задають напрям і послідовність пошуку відповіді.

Таким чином граф задає простір можливих станів ПРГ. Побудова простору консультацій здійснюється за допомогою «розкриття вершин»: береться деяка вершина з множини початкових станів і до неї застосовуються всі можливі оператори, що породжують дочірні вершини. Цей процес триває доти, поки не буде знайдено вершину, відповідну одному з цільових станів.

Пошук може здійснюватись або в глибину, або по горизонталі залежно від моделі знань. Процес розбиття задач на підзадачі представляється у вигляді орієнтованого графа. Кожна вершина графа є задачею або підзадачею і може бути кон’юнктивною («і»-вершиною) або диз’юнктивною («або»-вершиною). Кон’юнктивні вершини разом зі своїми дочірніми вершинами зводять розв’язок задачі до розв’язку всіх її підзадач, відповідних дочірнім вершинам.

У нових версіях системи з метою скорочення часу пошуку рішень передбачається використовувати евристичні методи пошуку та введення в БЗ системних правил. Системні правила можуть включати ступінь надійності, що забезпечує можливість евристичного пошуку рішення.

Для цього в кожній вершині передбачається використання евристичної інформації, яка перед розкриттям вершини дозволяє визначити ступінь її перспективності для реалізації певного запиту. Оцінка перспективності визначається на основі обраної функції оцінювання, в якій задаються різного роду семантичні обмеження.

Редактор БЗ, необхідний для підтримки БЗ, її доповнення, аналізу помилок програми, перевірки коректності синтаксису правил на несуперечність при змінах, автоматизує процеси редагування та придбання знань, що здійснюються користувачемекспертом, та записує базу у файл.

Редактор відображає граф моделі бази на екрані монітора, параметри вершин графа, надає користувачеві можливість ре-

рядок, а пара () ji xx, — це дуга. У цьому випадку пошук розв’язання задачі є шляхом на орієнтованому графі, де пари () jiji xx .1,? належать Y, який приводить з початкового стану до цільового. У системі дугам графа можна надати евристичні вагові характеристики, які відображають їх пріоритетність у процесі обробки запиту. В цьому випадку вибір шляху зводиться до мінімізації або максимізації суми вагових характеристик дуг, котрі створюють цей шлях: i j .

Модель БЗ в «SF 2» має структуру у вигляді дерева-графа. Система автоматично малює граф БЗ та дозволяє підключати бази різних форматів. Структура БЗ задається у вигляді направленого графа, вузли якого — модулі обробки даних, а ребра задають напрям і послідовність пошуку відповіді.

При створенні вершини графа редактор перевіряє синтаксис змінних, діагностує помилки, зберігає і трасує граф знань. Знання при цьому поділяються на декларативні та процедурні. Для запису декларативних та процедурних знань створення графа застосовано спеціалізовану внутрішню мову інтерпретатора системи «SF 2». Семантичні мовні інструкції та функції інтерпретатора «SF 2» наведені в таблиці 1:

Таблиця 1

abs	cf_not	do_section_of	log	question	system
and	cf_or	ending	ln	quit	sqrt
advice	chain	endst	max	range	startstr
arctan	clear_all	exit	min	restore_values	strlen
assign	clear_value	exp	not	rules	tan
boolean	concat	explanation	number	save_values	text
call	cos	false	or	section	true
category	description	hyperadvice	parameter	showpic	trunc
cf_add	display	If int	picture	sin	type
cf_and	do	known	power	sound	unknown

Редактор реалізовано у вигляді Windows-додатка. Головну форму додатка показано на рис. 4.16. «SF 2» має всі засоби, щоб написати правила, які складуть БЗ. Далі «SF 2» має машину висновку, яка може використовувати правила в БЗ, щоб визначити, яка порада має бути надана

дагувати програми, пов’язані з вершинами, та їх трансляцію. Трансляція початкової програми здійснюється в проміжний код, оскільки це дозволяє істотно прискорити логічний висновок у цілому.

Рис. 4.16. Редактор бази знань системи

Відокремлення контролю і частин висновку від БЗ — фундаментальна особливість експертної системи — «SF 2» використовується інженером по знанням, щоб створити БЗ, і користувачем системи, щоб консультуватися з БЗ.

Малюнки запам’ятовуються в базі рисунків з назвою pictures.DBA. Ім’я рисунку використовується як посилання. Тому рисунок можна включати як частину експертної системи.

База даних може підтримуватись із загальними використовуваними функціями БЗ, такими як додавання, редагування і видалення. Ви можете додати рисунок або імпортуванням його з файла, або за допомогою від буфера обміну. Всі формати растрового зображення і метафайли, обсягом більше, ніж 64 Кб, запам’ятовуються тільки для читання у файлах. Файл має розширення *.bmp, якщо картинка — точковий рисунок або *.emf, якщо рисунок — метафайл.

Використовучи вертикальні та горизонтальні смуги прокрутки, можна конкретизувати, де розмістити рисунок у вікні.

Система «SF 2» також містить редактор, що дозволяє конкретизувати обрані підполя в рисунку. Ця особливість використову-

споживачеві експертної системи або, щоб ініціювати інші дії. «SF 2» також мають здатність для користувача експертної системи одержати відповіді на запитання, як наприклад, «як» і, «чому», та ін.

Рисунок може використовуватися в «SF 2», як:

1. Стартова картинка для системи «SF 2».

2. Заголовок для БЗ.

3. Частина діалогу консультації, частина поради.

4. Частина actionlist у секції, showpic (рисунок).

Будь-який параметр складається з поля декларації і поля типу. Параметр може бути одним із таких чотирьох типів параметрів: булевий, текстовий, числовий, параметр категорії.

Будь-який параметр «SF 2» може набути значення в одній із таких подій:

• від відповіді до запитання;

• у результаті наступного деякого правила;

• призначення, що походить від позову довіреної особи.

Текст опису використовується, щоб назвати відповіді, коли користувач експертної системи використовує засіб «SF 2», аби запитати, «як?» — певне значення було встановлено, або «чому?»

— певна частина поради була надана. Інтерпретатор системи «SF 2» — це модуль з багаторівневим лінгвістичним процесором, який складається з лексичного аналізатора, блоку визначення слів, чисел та констант, блоку трансляції у внутрішню формальну мову, використовує системні бібліотеки Visual Prolog, та призначений для моделювання діалогу користувача і системи.

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

Таблиця 2

Математичні операції	Логічні операції
::= { _} ::= a b c ... x y z A B C ... X Y Z ::= 0 1 2 3 4 5 6 7 8 9 The syntax for a name is: ::= { _ } Example car michael a38 another_name_with_1_digit	< smaller than <= smaller than or equal to = equal to > greater than >= greater than or equal to <> different from мета- символи: { } Фігурнідужки вказують, що послідовність у дужках, можливо, повторюється. Квадратні дужки вказують , що послідовність у дужках необов’язкова. < > Імена, поміщені в дужки, синтаксичні елементи, як наприклад , , будуть зліва ::= символа правила — альтернативи

ється в союзі з параметрами категорії, в яких вибори відповідають полям у рисунку. Користувач експертної системи таким чином може зробити вибір, клацаючи по полю рисунка.

Продовження табл. 2

Математичні операції	Логічні операції
+ addition - subtraction * multiplication / division between reals div division between integers mod modulus ( )	section start ‘a very short section to illustrate assign’ assign n := 7 + 8 / 2 advice ‘evaluation of 7 + 8 / 2 gives ‘ n assign n := (7 + 8) / 2 advice ‘evaluation of (7 + 8) / 2 gives ‘ n ‘as / has higher priority than +.’ & ‘Notice that the parameter indeed did change the value’ parameter n ‘n’ type number
булевий параметр:	числовий параметр
::= and or not ( ) true false unknown known() ::= < > <= >= = <> parameter overweight ‘the person is	::= type number ::= range ::= ( ) ::= + — / * div mod

overweighted’

rules true if overweight_statement, false if not overweight_statement, height — 100 < weight /* This is not an official rule! */ parameter overweight_statement ‘the person is overweighted’ type boolean question ‘Are you overweight ?’ parameter gasoline_ok : ‘there is gasoline in your car’ type boolean explanation ‘Turn on the ignition and look at the fuel gauge’ question ‘Is there any gasoline in your car ?’ picture ‘gasoline’

parameter height ‘the height of the person in cm’ type number question ‘What is your height in cm? ‘ parameter weight ‘the weight of the person in kg’ type number question ‘What is your weight in kg? ‘ The syntax for the picture field is: ::= picture ‘‘ Examples picture car picture ‘sedan’

type boolean

Продовження табл. 2

Математичні операції	Логічні операції
Параметр категорії	текстовий параметр
::= type category ::= options — {, — }. Pictures Database Parameter car ‘the kind of car’ type category explanation ‘Identify your car with one of the listed types as closely as you can’ option ambulance policecar sedan — ‘car’ van. question ‘Which kind of car do you have?’ picture ‘cars’	::= type text parameter name ‘the name of the user’ type text question ‘What is your name ?’ parameter colour ‘a word describing the colour’ type text explanation ‘Humans normally use words to describe colours rather than specifying the frequency of the light wave. This parameter represents colours as red, blue, etc.’ rules ‘blue’ if frequency < 1000, ‘red’ if frequency > 2000 and frequency < 3000, ‘invisible’.
Побудова правил (rules)
Examples rules ‘blue’ if frequency < 1000, ‘orange’ if frequency >= 1000 and frequency < 2000, ‘red’ if frequency > 2000 and frequency < 3000, ‘invisible’. rules (height * (length + width)) * 2 if shape = box, height * width * width / 2 if shape = pyramid, 4 / 3 * 22 * radius * radius if shape = ball.	::= rules . ::= {,} ::= if For instance consider a rules field like this: rules if , if , if , .
The following parameter definition: parameter battery_dead ‘the battery is dead’ type boolean explanation ‘The battery is dead if none of the car’’s lights work’ question ‘Is the battery dead ?’	parameter marital_status ‘the people are married’ type category explanation ‘Marital status is determined by whether’ & ‘there exists a marriage certificate for’ & name ‘ and ‘ name_of_partner ‘ or not’ options married, unmarried. question ‘What is the marital status of ‘ name ‘ ?’

Закінчення табл. 2

Математичні операції	Логічні операції
Виклик функцій
::= call clear_all() call clear_value() call display() call hyperadvice(,) call restore_values() call save_values() call showpic() call sound(,) call system() hyperadvice(,) ::=	Examples call restore_values(‘c: setup.dat’) call save_values(‘c:setup.dat’) call showpic(‘cars’) sound(10,100) section brakes ‘problems with the brakes’ if brake_long_travel call hyperadvice(‘hypercar.hlp’,1) if brake_poor call hyperadvice(‘hypercar.hlp’,2) if brake_veer call hyperadvice(‘hypercar.hlp’,3) clear_all() очищає всі значенняпараметра в поточній базі знань

Boolean або логічні параметри використовуються, коли параметр обмежений до одного з істини значень, правильно чи неправильно — тобто, коли відповідь до питання — бути Або, Так, Ні, або Невідомо. За умовчанням «SF 2» автоматично проводить listbox, відповідний значенням: істина, неправильно і невідомо.

Якщо числовий параметр набуває свого значення від відповіді на запитання, «SF 2» покаже діалогове вікно, із запитанням і лінією редагування для відповіді. Вхідне значення буде перевірено автоматично на існування числа. Якщо поле параметра ряду вказане, значення крім того буде перевірено на існування в межах ряду (range 100 250).

Складні логічні вирази формуються, використовуючи логічні операції: І, Або і Ні та мають найвищий пріоритет, фактично навіть вищий, ніж математичні оператори.

Якщо параметр категорії набуває свого значення від відповіді до запитання, «SF 2» покаже діалогове вікно, з питанням і listbox з вибраними іменами або пояснювальними текстами, якщо вони надані. Споживач тоді вибирає відповідь від listbox. Як альтернатива, користувач може вибрати вибір, клацаючи по полю в рисунка. Щоб зробити це, поля в малюнка повинні бути визначені та прив’язані до вибору,

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

Пояснення в системі відповідає активному або останньому запитанню в сесії та консультації. Запитання завжди буде підказкою для значення параметра, чиє визначення містить запитання. Якщо визначення параметра також містить пояснення, ключового

Якщо текст запитання неповний, то «SF 2» виводить типовий текст, заснований на тексті опису від поля декларації, згідно з видом параметра. Якщо ім’я вже набуло значення, це значення буде вставлено за текстом запитання.