Класифікації діалогів і загальні принципи їх розробки

Як зазначалося в § 8.1, діалог - це процес обміну інформацією між користувачем і програмною системою, здійснюваний через інтерактивний термінал і за певними правилами. Розрізняють тип діалогу та його форму. Типи діалогу. Тип діалогу визначає, хто з «співрозмовників» управляє процесом обміну інформацією. Відповідно розрізняють два типи діалогу: керовані програмою і керовані користувачем. Діалог, керований програмою, передбачає наявність жорсткого, лінійного або деревовидного, тобто включає можливі альтернативні варіанти, сценарії діалогу, закладеного в програмне забезпечення. Такий діалог зазвичай супроводжують великою кількістю підказок, які уточнюють, яку інформацію необхідно вводити на кожному кроці. Діалог, керований користувачем, має на увазі, що сценарій діалогу залежить від користувача, який застосовує систему для виконання необхідних йому операцій. При цьому система забезпечує можливість реалізації різних користувальницьких сценаріїв. Форми діалогу. Ніякий діалог неможливий, якщо не існує мови, зрозумілої «співрозмовникам». Опис мови, на якому ведеться діалог, включає визначення його синтаксису - правил, що визначають припустимі конструкції (слова, речення) мови або його форму, і семантики - правил, що визначають зміст синтаксично коректних конструкцій мови або його зміст. Залежно від виду використовуваних в конкретному випадку синтаксису і семантики розрізняють три форми діалогу:

• фразову,

• директивну,

• табличну.

Фразова форма передбачає «спілкування» з користувачем на природній мові або його підмножині. Зміст діалогу в даній формі складають наказові, розповідні і питальні речення та відповіді на запитання. Спілкування може здійснюватися у вільному форматі, але можлива і фіксація окремих фраз. Організація діалогу на природній мові на сучасному рівні-задача не вирішена, оскільки природна мова вкрай складний і поки не вдається в достатній мірі формалізувати його синтаксис і семантику. Найчастіше використовують діалоги, що припускають односкладові відповіді, наприклад: Програма: Введіть свій вік (повних років): Користувач: 48. У цьому випадку програма містить обмежене опис як синтаксису, так і семантики використовуваного обмежено-природної мови. Для даного прикладу достатньо визначити синтаксис поняття «ціле позитивне число» і накласти обмеження на значення числа. Однак існує деякий досвід створення інтерфейсів на базі обмеженого підмножини речень природної мови в основному для інтелектуальних систем. Синтаксис і семантика мов діалогу, що реалізовуються в таких інтерфейсах, досить складні. При обробці фраз в цих випадках оперують поняттям словоформа. Словоформа - відрізок тексту між двома сусідніми пропусками або знаками пунктуації. Обробка словоформ поза зв'язку з контекстом називається морфологічним аналізом. Виділяють два методи морфологічного аналізу: • декларативний - припускає, що в словнику знаходяться всі можливі словоформи кожного слова, тоді аналіз зводиться до пошуку словоформи в словнику. Даний метод забезпечує можливість обробки повідомлень, складаються з малих і великих літер у довільній комбінації, при ніж як латинського, так і російської або інших алфавітів; • процедурний - припускає виділення в поточній словоформі основи, яку потім ідентифікують. Після розпізнавання словоформ здійснюють синтаксичний аналіз повідомлення, за результатами якого визначають його синтаксичну структуру, тобто виконують розбір пропозиції. Далі виконують семантичний аналіз, тобто визначають смислові відношення між словоформами. При цьому виявляють головні предикати, що визначають зміст речення. Таким чином, інтерфейс, який реалізує фразову форму діалогу, повинен: перетворювати повідомлення з природно-мовної форми у форму внутрішнього представлення і назад, виконувати аналіз і синтез повідомлень користувача і системи, відстежувати і запам'ятовувати пройдену частину діалогу. Основними недоліками фразової форми при використанні підмножини природної мови є:

• великі витрати ресурсів;

• відсутність гарантії однозначної інтерпретації формулювань;

• необхідність введення довгих граматично правильних фраз. Основна перевага фразової форми полягає у відносно сво Бодня спілкуванні з системою. Директивна форма припускає використання команд (директив) спеціально розробленого формальної мови. Командою в цьому випадку називають пропозицію цієї мови, що описує комбіновані дані, які включають ідентифікатор ініційованого процесу і, при необхідності, дані для нього. Команду можна вводити:

• у вигляді рядка тексту, спеціально розробленого формату, наприклад, команди MS DOS, що вводяться в командному рядку;

• натисканням деякої комбінації клавіш клавіатури, наприклад, кім бинации «швидкого доступу» сучасних Windows-додатків;

• за допомогою маніпулювання мишею, наприклад, «перетягуванням» піктограм;

• комбінацією другого і третього способів. Основними достоїнствами директивної форми є:

• порівняно невеликий обсяг введеної інформації;

• гнучкість - можливість вибору операції в даному випадку обмежені тільки набором допустимих команд;

• орієнтація на діалог, керований користувачем;

• використання мінімальної області екрану або невикористання її взагалі;

• можливість суміщення з іншими формами.

Недоліки директивної форми:

• практична відсутність підказок на екрані, що вимагає запам'ятовуючи ня вводяться команд і їх синтаксису;

• майже повна відсутність зворотного зв'язку про стан ініційованих процесів;

• необхідність навичок введення текстової інформації або маніпула ций мишею;

• відсутність можливості настройки користувачем.

Дослідження показали, що директивна форма зручна для користувача-професіонала, який зазвичай швидко запам'ятовує синтаксис часто використовуваних команди або комбінації клавіш. Основні достоїнства форми (гнучкість і хороші тимчасові характеристики) проявляються в цьому випадку особливо яскраво. Таблична форма припускає, що користувач вибирає відповідь із запропонованих програмою. Мова діалогу для табличної форми має найпростіший синтаксис і однозначну семантику, що досить легко реалізувати. Зручна ця форма і для користувача, так як вибрати завжди простіше, ніж згадати, що особливо істотно для користувача-непрофесіонала або користувача, рідко використовує конкретне програмне забезпечення. Однак застосування табличній форми можливо не завжди: її можна використовувати лише, якщо безліч можливих відповідей на конкретне питання звичайно. Причому, якщо кількість можливих відповідей велике (більше 20), то застосування табличній форми може виявитися недоцільним. Достоїнствами табличної форми є:

• наявність підказки, що зменшує навантаження на пам'ять користувача, так як дана форма орієнтована не на запам'ятовування, а на впізнавання;

• скорочення кількості помилок введення: користувач не вводить інфор мацію, а вказує на неї;

• скорочення часу навчання користувача;

• можливість суміщення з іншими формами;

• в деяких випадках можливість налаштування користувачем. До недоліків даної форми відносять:

• необхідність наявності навичок навігації по екрану;

• використання порівняно великої площі екрану для изображе ня візуальних компонентів;

• інтенсивне використання ресурсів комп'ютера, пов'язане з необ хідності постійного оновлення інформації на екрані.

Слід мати на увазі, що типи і форми діалогу вибирають незалежно один від одного: будь-яка форма застосовна для обох типів діалогів (рис. 8.10). Однак фразова форма, яка використовується в діалозі, керованому користувачем, як правило, передбачає більш складні синтаксис і семантику мови діалогу, так як програма повинна «розуміти» користувача. Рис. 8.10. Відповідність типів діалогів і його форм Складне програмне забезпечення зазвичай взаємодіє з користувачем за допомогою діалогів різних типів і форм в залежності від розв'язуваних завдань. Причому, крім діалогів, що відбуваються в процесі нормальної роботи програмного забезпечення і званих синхронними, передбачають діалоги, що виникають з ініціативи системи або користувача при порушенні сценарію нормального процесу. Такі діалоги називають асинхронними. Зазвичай їх використовують для видачі екстрених повідомлень від системи або користувача. Розробка діалогів. Процес проектування та реалізації діалогів можна розділити на наступні стадії:

• визначення безлічі необхідних діалогів, їх основних сообще ний і можливих сценаріїв - проектування абстрактних діалогів;

• визначення типу і форми кожного діалогу, а також синтаксису і се мантики використовуваних мов - проектування конкретних діалогів;

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

В основу абстрактних діалогів повинна закладатися ідеологія технологічного процесу, для автоматизації якого призначається програмний продукт. Саме аналізуючи складові автоматизируемого технологічного процесу, розробник визначає сценарії діалогів (див. § 6.2), які повинні бути передбачені в програмному забезпеченні. Крім сценаріїв, при проектуванні абстрактних діалогів використовують діаграми стані інтерфейсу або графи діалогу. Граф діалогу - орієнтований зважений граф, кожній вершині якого зіставлена ​​конкретна картинка на екрані {кадр) або певний стан діалогу, що характеризується набором доступних користувачеві дій. Дуги, що виходять з вершин, показують можливі зміни станів при виконанні користувачем зазначених дій. В якості ваг дуг вказують умови переходів зі стану в стан і операції, що виконуються під час переходу. Таким чином, кожен маршрут на графі відповідає можливого варіанту діалогу. Причому уявлення діалогу у вигляді графа в залежності від стадії розробки може виконуватися з різним ступенем деталізації. По суті граф діалогу - це граф станів кінцевого автомата, моделює поведінку програмного забезпечення при впливах користувача. Для представлення таких графів вже були введені дві нотації: нотація діаграм станів структурного підходу до розробки (див. рис. 4.3) і нотація діаграм станів UML (див. рис. 7.17). Причому нотація UML є більш потужною, так як дозволяє використовувати узагальнені стану. Тому, щоб не вводити нову нотацію для представлення графа діалогу, будемо використовувати позначення UML. Приклад 8.2. Розробити граф діалогу для системи вирішення комбінаторно-оптимізаційних задач. Так як діалог на верхньому рівні повинен забезпечувати реалізацію діаграми варіантів використання, вихідний варіант графа діалогу будуємо на основі аналізу цієї діаграми (див. мал. 6.4). Можна припустити, що користувач буде приймати рішення про збереження або видаленні результатів після їх перегляду, тому ці операції природно об'єднати в єдину групу. Крім того, в ту ж групу доцільно додати операцію друку результатів. Аналогічно перегляд даних доцільно об'єднати з їх видаленням або коректуванням. Операцію Нове завдання доцільно помістити в окрему групу (рис. 8.11). На верхньому рівні діалог очевидно повинен управлятися користувачем. Директивна і таблична форми можуть використовуватися альтернативно, за бажанням користувача, а застосування фразової форми недоцільно. Приклад 8.3. Деталізувати діалог Нове завдання. У § 6.2 приведений сценарій Виконання завдання, на базі якого можна запропонувати граф діалогу, керованого системою (рис. 8.12, а). Однак цей же діалог можна представити й у вигляді діалогу, керованого користувачем (рис. 8.12, о). Аналіз графів діалогу показує, що діалог, керований системою, в даному випадку сильно обмежує користувача у виборі варіантів дії, а діалог, керований користувачем, передбачає вибір дії після кожного кроку, хоча за змістом ці кроки найчастіше будуть виконуватися послідовно. Тому для реалізації краще використовувати комбінований варіант, який враховує наявність сценарію, але допускає відхилення від нього за бажанням користувача (рис. 8.13). Тепер необхідно визначити, які форми діалогу можна використовувати для кожного кроку діалогу. Перший крок - Вибір завдання включає три варіанти, тому має сенс використовувати табличну форму. Другий крок-Визначення даних не конкретизований, отже, уточнити його форму поки неможливо. Третій крок - Вибір алгоритму знову ж передбачає вибір, причому кількість варіантів невелика: доцільно використовувати табличну форму. В інших випадках також кращою виявляється саме ця форма. Останній етап проектування інтерфейсів - розробка конкретних операцій вводу-виводу для кожного діалогу з урахуванням специфіки форми ін-