7.3. Користувальницький інтерфейс систем реального часу
Автоматизація процесів керування іде своїми коренями в глибоке минуле. Власне, застосування ЕОМ у якості "керуючого органа" почалося практично відразу, як тільки з'явилася технічна можливість сполучати їх з об'єктами, що підлягають керуванню. Однак при цьому ЕОМ (та й ті, хто на них працював) продовжували жити у своєму, "нереальному" світі, наповненому бітами, байтами, що плавають комами й іншими, незрозумілими нормальним людям категоріями. Навіть час у них вимірялося по-своєму, не днями, не годинник, і навіть не хвилинами, а зовсім іншими одиницями - милі- мікро- нано- і іншими секундами. Більш того, у багатьох випадках інтервали між сусідніми подіями усередині ЕОМ виражалися навіть не цими псевдо-секундами, а числом тактових імпульсів, сформованих тактовим генератором. Проте , ЕОМ, включені в контур
273
керування, змушені були синхронізувати свої дії з керованими об'єктами,-працюючими в реальному світі і, відповідно, у реальному часі. Щоб відрізняти такі обчислювальні системи від тих, котрим реальний мир залишався байдужний, їх стали називати "системами реального часу" (СРВ). Одна з найбільш удалих на наш погляд трактувань цього поняття приведена в [6]: "Система реального часу - це апаратно-програмний комплекс, що реагує протягом передбачуваного часу на непередбачений потік зовнішніх подій". Дане визначення вимагає деяких пояснень. По-перше, перелік типів подій, на які повинна реагувати система, як правило, визначається на етапі її створення; невідома "тільки" послідовність цих подій і моменти їхнього виникнення. По-друге, система повинна устигнути відреагувати на подію, що відбулася, протягом часу, критичного для цієї події (точніше, для керованого об'єкта), і цей час повинний бути передвіщене (обчислено) при створенні системи. Відсутність реакції протягом заданого (чи припустимого) інтервалу вважається помилкою. По-третє, оскільки на керованих об'єктах можуть відбуватися дві чи більш події одночасно, повинна бути задана пріоритетність кожного з них з погляду цільового призначення системи. Розрізняють СРВ двох типів:
o твердого реального часу;
o м'якого реального часу.
Для систем твердого реального часу неприпустима затримка реакції ні при яких умовах, оскільки це може привести або до катастрофічних наслідків, або до важких економічних утрат (що, власне, для потерявшего рівносильне катастрофі). До таких систем відносяться, зокрема , бортові системи керування, системи військового призначення, системи аварійного захисту (наприклад, на атомних електростанціях) і деякі інші.
Для систем м'якого реального часу затримка менш критична, хоча і може привести до зниження якості керування. Наприклад, затримка в оформленні авіаквитків за 10 хвилин до вильоту навряд чи приведе до людських жертв, але певним чином уплине на роботу аеропорту.
Особливий клас СРВ складають так називані системи диспетчерського керування (чи людино-машинні системи - ЧМС), у яких одним з обов'язкових ланок керування (а іноді і головним) є людина (диспетчер, оператор, чи Обличчя, Що Приймає Рішення - ЛПР). Якість роботи такої системи в значній мірі визначається тим, наскільки адекватно сприймає оператор інформацію, що надходить, і наскільки вчасно він на нее реагує. Очевидно, що при достатньому рівні підготовленості персоналу основним фактором, що впливає на роботу оператора, є якість організації його взаимо-действия із системою, тобто її інтерфейс. Разом з тим, навіть у випадку ухвалення правильного рішення оператор може допустити так називану функціональну помилку (натиснути не ту клавішу, вибрати не ту команду) і т.д. Небезпека функціональних помилок істотно зростає в стресових ситуаціях. Наприклад, досвід
американських військових льотчиків показує, що в умовах ведення бойових дій виявляється неефективним використання меню.
У табл. 7.1. приведені чисельні значення імовірностей різних типів функціональних помилок. Якщо розв'язувана оператором задача вимагає виконання ланцюжка операцій, імовірності можливих помилок складаються; сумарне значення імовірності помилки, що перевищує 0,03, вважається критичним [7].
Табл і ца 7.1. Імовірності різних типів функціональних помилок
Операція Імовірність помилки
Актуалізація з чи пам'яті запам'ятовування значення параметра 0,0005
Уявний вибір однієї з двох альтернатив 0,0005
Уявне порівняння ситуації з типовий, потребуючої опреде-ленного дії 0,0010
Читання (1-3 слова) 0,0010
Уведення тексту (1-3 слова) 0,0020
Сприйняття символу (знака, транспаранта) 0,0040
Сприйняття повідомлення 0,0020
Сприйняття показань стрілочного індикатора 0,0070
Сприйняття показань цифрового індикатора 0,0020
Натискання клавіші на клавіатурі 0,0050
Подвійний щиглик мишею 0,0030
Вибір елемента на екрані 0,0050
Іншими словами, якість роботи СРВ залежить від форми представлення інформації про поточну ситуації в системі і від доступних оператору засобів впливу на виконавчі компоненти-системи.
Таким чином, при розробці користувальницького інтерфейсу СРВ основна увага повинна бути приділена наступним питанням:
1. Детальному проектуванню сценарію діалогу з метою вибору оптимальних
маршрутів переміщення оператора по дереву діалогу, а також запобігання
ситуацій, що можуть зажадати перезапуску системи.
2. Реалізації засобів динамічної зміни структури діалогу в зависи
мости від поточної ситуації, що складається в системі.
275
3. Ретельному вибору візуальних атрибутів відображуваної інформації, у тім числе'выбору засобів залучення уваги користувача (оператора).
При усьому при цьому повинно забезпечуватися властивість природності інтерфейсу СРВ. Мається на увазі наступне. У багатьох системах керування технологічними процесами за годы їхнього існування була сформована оптимальна структура засобів індикації і контролю, а також відповідна їй система умовних позначок, використовувана на операторських пультах. При створенні робочих місць операторів враховувалися результати дуже глибоких эргономических досліджень. Тому при проектуванні інтерфейсу автоматизованих робочих місць (АРМ) на базі ПЭВМ доцільно зберегти основну схему візуалізації процесів, що протікають у даній системі керування. Невипадково практично всі інструментальні засоби, призначені для розробки інтерфейсу систем диспетчерського керування, містять графічні бібліотеки, що дозволяють відтворювати на екрані монітора мнемосхеми, ідентичні использовавшимся на колишніх пультах (мал. 7.4).
Рис. 7.4. Приклад мнемосхеми технологічного процесу, відображуваної на АРМ оператора
Такий підхід дозволяє використовувати при роботі оператора не тільки візуальні, але й інші (у першу чергу - звукові) засобу індикації і залучення уваги.
276
Випливаючи основної концепції книги, у даному розділі ми більш докладно розглянемо аспекти проектування візуальних компонентів користувальницького інтерфейсу СРВ. Щоб ще раз підкреслити їхній вплив на якість програмного продукту в цілому, приведемо такий факт. У шведському стандарті на користувальницький інтерфейс систем керування електростанціями є пункт, що передбачає, що потребуюча термінової уваги оператора інформація повинна супроводжуватися символом червоного кольору, помітним не менш чим із двох метрів від монітора. Якщо ця вимога не була виконана, то при пропуску оператором аварійної ситуації відповідальність за происшедшее автоматично покладається на розроблювача користувальницького інтерфейсу.
Щоб не виявитися в положенні такого розроблювача, при виборі візуальних атрибутів елементів інтерфейсу варто враховувати як вимоги наявних стандартів, так і фізіологічні особливості зору оператора.
Прийом візуальної інформації містить ряд елементарних процесів: виявлення, розрізнення, упізнання і декодування. На виконання цих процесів основний вплив роблять наступні характеристики зору оператора:
o яркостные
o просторові
o тимчасові
o колірного сприйняття.
Усі вони в значній мірі залежать від розмірів і властивостей випромінювання об'єктів, відображуваних на екрані.
Яркостные характеристики
Вони визначають розмір зони бачення світного об'єкта, а також швидкість і безпомилковість обробки світної інформації.
Зорове сприйняття світного об'єкта можливо в діапазоні яркостей і 10е... 103 кандел/м2. Яскравість світного об'єкта може бути розрахована по формулі
У=ДО - 0,251п(а) + 0.79,
де ДО - ступінь осліплення (при ДО= 1...2 оператор випробує дискомфорт, а при ДО=3...8 - болючі відчуття);
а - кутовий розмір світного об'єкта (виміряється в градусах).
Яскравість, що перевищує 15 o 10у, є сліпучої.
Для забезпечення тривалої зорової працездатності оператора яскравість об'єктів, що спостерігаються на екрані, не повинна перевищувати 64 кд/м2; при цьому перепад яркостей у поле зору оператора повинний бути не більш 1:100. Найвища швидкість розрізнення складних об'єктів досягається при яскравості 3 o 103 кд/м2.
Необхідно також враховувати, що необхідна гострота зору при сприйнятті світлих об'єктів у 3-4 рази нижче чим, для темних; світлі об'єкти на темному тлі виявляються легше, ніж темні на світлому.
277
Просторові характеристики
Дана група характеристик впливає на виявлення, розрізнення й упізнання об'єктів.
При рішенні практичних задач необхідно враховувати наступні положення:
1. Основну інформацію про об'єкт несе його контур; час розрізнення й опоз
нания контуру об'єкта збільшується зі збільшенням його складності.
2. При розрізненні складних контурів безпомилковість вище, ніж при различе
нии простих.
3. Вирішальне значення в сприйнятті форми об'єктів має співвідношення "фи
гура/тло".
4. Мінімальний розмір об'єкта повинний вибиратися для заданих рівнів кін
трасту і яскравості; зменшення значень цих параметрів вимагає збільшення угло
вых розмірів об'єкта.
5. Для підвищення імовірності розрізнення з 0,5 до 0,98 потрібно збільшення
кутових розмірів для простих фігур на 20...25%, а для знаків типу букв і цифр -
у два рази.
6. Для розрізнення положення фігури щодо вертикальної чи горизон
тальной осі гранична величина виявлення повинна бути збільшена в 3 рази (поріг
виявлення темного об'єкта на світлому тлі складає 1 кутову секунду).
При наявності на екрані об'єктів, що рухаються, варто враховувати ряд додаткових факторів. Наприклад, при переміщенні крапкового об'єкта зі швидкістю 0,25 градус/з його безупинний рух сприймається як дискретне, при швидкості 0,25...4 градус/з - як безупинне, а при швидкості більш 4 градус/із зображення зливається в суцільну смугу.
Корисно також пам'ятати про те, що існує три види удаваного руху:
o сприйняття переміщення сигналу з одного положення в інше при последо
вательном пред'явленні двох ідентичних сигналів від різних об'єктів;
o удаване зміна розмірів об'єкта з послідовною появою
двох об'єктів, що мають ідентичні контури;
o Удаване зміна розмірів об'єкта при зміні яскравості самого
чи об'єкта тла.
Тимчасові характеристики
Зорове сприйняття світного об'єкта формується в людини-оператора з деякою затримкою стосовно початку дії зорового подразника і його припиненню, що обумовлює ряд особливостей функціонування зорового аналізатора. Ці особливості виявляються як при сприйнятті одиночних світлових сигналів, так і їхньої послідовності. Знання тимчасових характеристик зору дозволяє обґрунтовано вибирати час експозиції сигналів для забезпечення їхнього мінімального розрізнення і тимчасових інтервалів пред'явлення сигналів у послідовності. Основні тимчасові характеристики зорового сприйняття приведені в табл. 7.2.
278
Тимчасові характеристики зору
Таблиця 7.2.
Характеристика Кількісне значення Умови спостереження
Суб'єктивно воспри-нимаемая яскравість при мельканнях, % 200 100 50 Частота мелькання (Гц): 8...10 16.. .20 24...28
Критична частота мелькань для їхнього раз-ділового сприйняття, Гц 15 25
50 Яскравість об'єкта (кд/м2): 0,1 1 100
Швидкість виявлення, мс <3
<30 <7
<60 Для об'єктів простої конфігурації Те ж, у поганих умовах спостереження Для знайомих людині зображень (букви, цифри) Те ж, в умовах перешкод
Характеристики колірного сприйняття
Кольори розрізняються тоном, светлотой і насиченістю. Число помітних відтінків кольору по всьому спектрі при яскравості не менш 10 кд/м2 і максимальна насиченості дорівнює приблизно 150. Розрізнення ступенів насиченості коливається від 4 (для жовтого) до 25 (для червоного). При ізольованому пред'явленні людин точно ідентифікує не більш 10-12 колірних тонів, а в комбінації з іншими квітами - не більш восьми.
Зміна яскравості об'єкта впливає на сприйняття його кольору. Зі зменшенням яскравості від 180 до 0,5 кд/м2 відбувається зменшення светлоты і поступове знебарвлення жовтого і синього кольорів, а спектр стає триколірним: червоно-зелено-фіолетовим.
Сприйняття кольору залежить також від кутових розмірів об'єкта: зі зменшенням розміру змінюється видима яскравість і спотворюється кольоровість. Найбільшій зміні піддаються жовтий і синій кольори.
Для систем реального часу основним критерієм вибору квітів відображуваних на екрані символів і повідомлень є гострота розрізнення. Вона максимальна для символів білого кольору і мінімальна для символів, що мають крайні кольори спектра. Хоча білий колір найбільш простий у застосуванні і його часто використовують, найкращим у цьому відношенні є жовто-зелений колір, що по насы-щенности мало відрізняється від білого, але має максимальну видность; червоний, фіолетовий і синій кольори не рекомендується використовувати для відображення чи символів об'єктів складної конфігурації.
279
При узгодженні квітів символів і тла варто враховувати, що сприйняття символів максимально для контрастних квітів (тобто стосовним до протилежних границь спектра). При контрастності менш 60% читаність символів різко погіршується. Установлено наступні припустимі комбінації кольору символу з кольором тла (у порядку убування чіткості сприйняття):
o синій на білому
o чорний на жовтому
o зелений на білому
o чорний на білому (тільки четверте місце!!)
o білий на синьому
o зелений на червоному
o червоний на жовтому
o червоний на білому
o жовтогарячий на чорному
o чорний на пурпурному
o жовтогарячий на білому
o червоний на зеленому.
При одночасному надходженні двох чи декількох сигналів (повідомлень) на їхнє сприйняття оператором впливають наступні фактори: вибірковість уваги, абсолютна і відносна інтенсивність сигналів, взаємне розташування на екрані, ступінь синхронності сигналів, обсяг інформації, що надходить, і швидкість її надходження.
Поряд з розглянутими вище характеристиками важливе значення для ефективної роботи оператора має спосіб передачі значеннєвого змісту відображуваної на екрані інформації. Цей спосіб може базуватися на використанні одного з чотирьох типів знакових систем (чи їхньої комбінації):
o буквеної
o піктографічної
o цифровий
o геометричної.
При виборі знакової системи варто враховувати:
1. Легкість упізнання і декодування знаків.
2. Необхідну тривалість безпомилкової роботи оператора, у тому числі у вус
ловиях стресу.
3. Рівень помехоустойчивости системи.
4. Швидкість запам'ятовування і тривалість збереження алфавіту знакової систе
ми в оперативній і довгостроковій пам'яті оператора.
Як інтегральну характеристику знакової системи може використовуватися коефіцієнт оперативності коду [8], Кіп, що представляє собою відношення часу упізнання символу (знака) до часу його декодування. Значення цього показника для перерахованих вище знакових систем приведені в табл. 7.3.
Та6л і ца 7.3. Значення коефіцієнта оперативності коду
Знакова система Значення Кіп
Буквена (для одного слова) 0,9
Піктографічна (для піктограми) 0,8
Цифрова (для одного числа, не більш 4 розрядів) 0,6
Геометрична (для однієї фігури) 0,6
З приведених даних можна, зокрема , зробити висновок, що в стресових ситуаціях числа до трехразрядных включно доцільно представляти на екрані в текстовій формі (тобто словами). Разом з тим, основні властивості чи об'єкта опис необхідних дій ефективніше відобразити у виді піктограми. Так, фразу "переслати повідомлення на вищестоящий рівень" краще замінити відповідною піктограмою.
Однак, як уже відзначалося в главі 4, піктограма піктограмі ворожнеча. Спробуйте, наприклад, самостійно визначити (чи згадати) зміст приведених на мал. 7.5 піктограм, узятих з одного дуже популярного додатка.
Рис. 7.5. Піктограми - "загадки"
Експериментально доведено [8], що найбільш значимі характеристики об'єкта повинні кодуватися (відображатися) його контуром, а внутрішніми деталями -допоміжні* другорядні. При цьому система пізнавальних ознак форми знака, обрана для визначених характеристик об'єкта, повинна застосовуватися для всього алфавіту знакової системи.
Кількісні оцінки впливу геометричного контуру піктограми на ефективність її розпізнавання дані в табл. 7.4.
При розробці знакової системи варто враховувати, що симетричні символи легше засвоюються людиною-оператором і більш міцно зберігаються в короткочасній і довгостроковій пам'яті.
Як розпізнавальні ознаки знаків у межах одного алфавіту не рекомендується використовувати:
o Число елементів у знаку;
o Геометричні розміри знака (принаймні , більш двох варіантів);
o Відмінність знаків за принципом "позитив-негатив" і "пряме-дзеркальне від
ражение".
281
Таб.ч іі ца 7.4. Вплив геометричної складності знака на його декодування
Показник Значення показника
Прості знаки Знаки середньої складності Складні знаки
Мінімальний час експозиції, з 0,03 0,03 0,05
Середній час декодування при експозиції 0,03з, з 3,06 2,55 2,76
Імовірність правильного декодування 0,80 0,97 0,98
І в завершення ще один фактор, що згадувався в попередніх главах - кількість інтерактивних елементів, одночасно відображуваних на екрані. Природно, на ефективність роботи з ними впливають і зорові характеристики оператора, і якість використовуваної знакової системи. Проте при виборі потрібного елемента позначається ще одна характеристика оператора - сенсомотор-ная. Як приклад у таблиці 7.5 приведені досить усереднені значення безпомилковості (Рв) і часу (Тв) вибору необхідного елемента в залежності від числа наявних.
Табл і на 7.5. Узагальнені показники сенсомоторной характеристики оператора
Кількість інтерактивних елементів на екрані (в активному вікні) Рв Тв,з
3 0,999 1,5
7 0,997 3,0
10 0,995 4,0
15 0,97 5,0
20 0,94 7,0
60 0,92 10,0
Важливим фактором, що впливає на ефективність роботи оператора, є підтримка всех'его "підсистем" на необхідному рівні готовності протягом досить тривалого часу. У зв'язку з цим додатково до розглянутих долж-
282
ны бути вирішені дві взаємозалежні проблеми: запобігання як "сенсорного голоду", так і надмірного сенсорного перевантаження оператора.
Для боротьби з перевантаженням досить враховувати ті загальні рекомендації з розміщення інформації на екрані, що були приведені в главі 2, а також характеристики зору оператора, розглянуті вище.
"Сенсорний голод" може бути обумовлений надмірним штучним зниженням динамічності відображення поточної ситуації на екрані, а також свето- і звукоізоляцією робочих місць. У зв'язку з цим для запобігання "сенсорного голоду" повинна бути уведена визначена надмірність представленої на екрані інформації з порівняння з мінімально необхідної. Наприклад, на екрані можуть з'являтися повідомлення, що вимагають тієї чи інша реакції оператора, але реально що не впливають на процес керування. Інший спосіб боротьби з "сенсорним голодом" заснований на використанні декількох форм представлення інформації (тобто на застосуванні мультимедийных технологій); мова йде в першу чергу про доповнення візуальної інформації звуковим супроводом. І хоча коло розглянутих у книзі питань навмисне обмежений візуальним компонентом користувальницького інтерфейсу, у даному випадку з цього кола необхідно ненадовго вийти. Порозумівається це тим, що полімодальна організація наданої оператору інформації дозволяє вирішити відразу кілька проблем. По-перше, як було сказано вище, угамувати його "сенсорний голод". По-друге, при дублюванні інформації з Несколь-Ким сенсорним каналам скорочується час реакції оператора. По-третє, такий підхід дозволяє збільшити обсяг одночасно прийнятої інформації. І, нарешті, залучення додаткових сенсорних каналів дозволяє розвантажити той, по якому інформація надходить найбільше інтенсивно.
Разом з тим, застосування мультимедийных технологій значно ускладнює інтерфейс, що вимагає при його проектуванні рішення додаткових задач. Основна з них - узгодження інформації, що надходить по різних каналах, за часом і по змісту. При недотриманні цієї умови ефект від полімодальності виявиться прямо протилежним очікуваному. При одночасному надходженні декількох сигналів, що вимагають виконання різних дій, час реакції оператора збільшується; практично неминуче також информа-ционная перевантаження оператора і, як наслідок, - його підвищена стомлюваність.
У системах реального часу участь оператора в процесі керування виявляється головним чином при виникненні позаштатних, аварійних чи критичних ситуацій. Разом з тим, саме такі ситуації викликають у людини дискомфортне чи навіть стресовий стан. У зв'язку з цим особливе значення для СРВ має проблема реалізації засобів підтримки користувача. Очевидно, що веде роль тут повинна грати контекстно-залежна допомога і допомога, обумовлена завданням. При цьому доцільно передбачити два способи надання допомоги: по запиті оператора й автоматично, наприклад, після закінчення деякого припустимого часу чекання реакції оператора на виниклу ситуацію.
283
З тих же позицій варто розглядати і можливість документування дій оператора. Практика показує, що для повноцінного аналізу дій оператора потрібно не тільки реєструвати перелік команд, що виконувалися, і значення регульованих параметрів, але і формувати знімки екрана у відповідні моменти часу. При реалізації такої можливості необхідно враховувати технічні характеристики засобів висновку (принтерів). Якщо для експрес-аналізу використовується чорно-біла печатка, то це накладає додаткові обмеження на вибір колірної палітри екрана і відображуваної на ньому інформації.
У зв'язку з підвищеними вимогами, пропонованими до надійності і швидкодії систем реального часу, при їхньому створенні значно зростає роль етапу макетування користувальницького інтерфейсу і його узгодження з по-тенциальными користувачами.
Завершуючи обговорення проблем, зв'язаних із проектуванням і реалізацією користувальницького інтерфейсу в конкретних предметних областях, ще раз нагадаємо, що обрані області відносяться, на перший погляд, до протилежних границь спектра. У зв'язку з цим приведемо рекомендації з розробці Web-вузлів редактора електронного журналу Corporate Іnternet Strategіes Пита Лошина [10]:
1. Використовувати графіку тільки там, де вона буде нести реальне значеннєве
навантаження;
2. Використовувати текст замість графіки де тільки можливо (для прискорення заг
рузки сторінок);
3. Використовувати фрейми, таблиці й інші елементи структурної організації
вмісту;
4. Використовувати ті самі компоненти на різних сторінках для скорочення
часу їхнього завантаження;
5. Розміщати найбільше важливу інформацію в самих доступних місцях сайта;
6. Уміст сайта повинний бути дійсно корисним для відвідувача.
Окрема група рекомендацій зв'язана з використанням Інтернету як джерело інформації про біржові котирування. У цьому випадку для працюючих у мережі брокерів рахунок часу йде на секунди, а Інтернет виступає в ролі самої дійсної системи твердого реального часу.
Як говориться, коментарі зайві...
ЗАСОБУ РЕАЛІЗАЦІЇ КОРИСТУВАЛЬНИЦЬКОГО ІНТЕРФЕЙСУ
8.1. КЛАСИФІКАЦІЯ ЗАСОБІВ РОЗРОБКИ КОРИСТУВАЛЬНИЦЬКОГО ІНТЕРФЕЙСУ
Технологія побудови користувальницького інтерфейсу й інструментальні засоби, використовувані для її реалізації, утворять єдине ціле. Черговий крок у розвитку кожної з цих складових дає поштовх до подальшого розвитку іншої. Матеріальною же основою існування будь-якого користувальницького інтерфейсу є перелік пристроїв уведення/висновку, доступних кінцевому пользо-вателю. У ті далекі часи, коли єдиним засобом введення інформації в ЕОМ служив пристрій читання з перфокарт, а засобом висновку - його брат-близнюк для висновку на перфокарти, жоден объектно-ориентированный мова програмування не допоміг би представити користувачу результати інакше, як у виді дірочок на перфокарті. Іншими словами, тоді проблеми реалізації пользова-тельского інтерфейсу для програмістів просто не існувало ("немає інтерфейсу - немає проблем").
З появою алфавітно-цифрових (символьних) пристроїв уведення/висновку, таких як алфавітно-цифрові дисплеї (АЦД) і алфавітно-цифрові друкувальні пристрої (АЦПУ), у мови програмування були включені відповідні оператори (або бібліотечні функції), призначені для реалізації взаємодії користувача з цими пристроями. На даному етапі технологія програмування компонентів, що відносяться до користувальницького інтерфейсу, практично не відрізнялася від програмування інших функцій додатка, та й самі ці компоненти були як би "розмазані" по всій програмі. Згодом така технологія одержала найменування "внутрішнє керування інтерфейсом". Спирається вона в основному на процедурні мови програмування, як високого рівня (Фортран, Паскаль, Си), так і орієнтований-орієнтовану-орієнтоване-орієнтована-машинно-ОрієнтовААі (типу ассемблера). Очевидно, що при такому підході розробка інтерфейсу як самостійного компонента програмної системи практично неможлива. Хоча згадані вище орієнтований-орієнтовану-орієнтоване-орієнтована-процедурно-ОрієнААвані
285
мови не даремно називаються універсальними і дозволяють реалізувати будь-який тип інтерфейсу (у тому числі і GUІ), трудозатраты на практичну реалізацію такої витівки можуть виявитися не під силу переважній більшості розроблювачів. Крім того, необхідність "ручного" опису величезного числа атрибутів інтерактивних компонентів додатка унеможливлює стандартизацію цих компонентів. Деякою мірою спростити рішення зазначеної задачі дозволило появу проблемно-орієнтованих мов програмування, таких як мови моделювання (SІMULA, GPSS, SOL) і мови керування ба-зами даних (Clіpper, dBASE, PAL). Особливу групу процедурних мов утворять так називані мови діалогової взаємодії (чи командні мови), створені спеціально для полегшення роботи користувачів в інтерактивному режимі. Основу синтаксису цих мов складають макрокоманди (чи макрооператори), що реалізують визначену послідовність дій по введенню/ висновку даних. Наприклад, один з мов діалогової взаємодії - ДИ-ФОЛ - містить такі операторы:
DІSPLAY - вивести інформацію на екран;
UPR - створити незахищене поле введення;
NUM - створити цифрове поле;
BRO - створити невідображуване поле;
BR1 - створити поле нормальної яскравості;
BR2 - створити поле, відображуване з підвищеною яскравістю.
Випливає, видимо, згадати, що дуже популярний нині мова BASІ, як і не менш популярний у свій час мова APL, також створювалася споконвічно як діалогова мова (BASІ - Begіnners All-purpose Symbolіc Іnstructіon Code). Зважаючи на все, саме цим порозумівається рішення фірми Mіcrosoft використовувати BASІ як убудовану мову додатків. Але про це трохи пізніше.
З усіх перерахованих груп мов найбільший вплив на розвиток технології проектування і розробки користувальницького інтерфейсу зробили мови керування базами даних. Ще до початку тріумфального ходу "по країнах і континентам" графічної оболонки Wіndows 3.* і появи терміна Data-Centered Desіgn мови СУБД забезпечували роздільний опис даних і засобів роботи з ними. У значній мірі це порозумівається самою сутністю використання БД: для різних чи завдань для різних користувачів потрібно забезпечити різне представлення тих самих даних. Наприклад, до складу ранніх версій СУБД Paradox уже входили такі компоненти:
Ask - генерація форм запитів;
Report - розробка специфікацій звітів;
Create - створення структури нової таблиці;
Forms - розробка специфікацій екранних форм;
Іmage - установка користувальницьких характеристик представлення таблиці на екрані (у виді чи форми графіка).
Більш того, у складі СУБД Paradox мається так називаний генератор додатків (Personal Programmer), що забезпечує створення додатків для роботи з БД і здатний виконувати свої функції навіть при відсутності на ПЭВМ ядра СУБД. При цьому як перераховані вище компоненти, так і генератор додатків орієнтовані в першу чергу на непрограмуючих користувачів. За допомогою системи меню і функціональних клавіш генератора додатків користувачі могли створювати власну конфігурацію інтерактивних елементів додатка, у тому числі що випадають і ієрархічні меню, вікна, а також засобу допомоги (вікна з довідковою інформацією). Аналогічні можливості малися практично у всіх розвитих СУБД.
Поряд з іншими досягненнями в області технологій програмування, поява объектно-ориентированных баз даних сприяло впровадженню объектно-ориентированного підходу в практику створення користувальницьких інтерфейсів [5]. Технологія объектно-ориентированного програмування дозволила ще більш явно відокремити друг від друга компонента додатка, що реалізують його функціональне призначення, і компоненти, що відносяться до користувальницького інтерфейсу.
Надзвичайно великий вплив на весь наступний розвиток інтерактивних систем зробила растрова графіка. Її застосування як основу інструментів візуального програмування привело до появи принципово нового типу користувальницького інтерфейсу - графічного (основні концепції GUІ були розглянуті в главі 2).
Засобу візуальної розробки, що забезпечують реалізацію объектно-ориентированного програмування, дозволяють створювати макет користувальницького інтерфейсу, використовуючи технологію WYSІWYG (What You See Іs What You Get - "що ви бачите, те й одержите", тобто результат виглядає так само, як і прототип під час розробки). Засобу візуальної розробки були створені практично для всіх популярних мов програмування, а також для знову з'явилися (наприклад, для Java). Усі ці інструменти володіють двома основними достоїнствами: по-перше, істотно підвищують продуктивність праці програміста, і, у других, забезпечують стандартизацію користувальницького інтерфейсу за рахунок використання однотипних базових елементів. У результаті, дивлячись на готовий додаток, практично неможливо визначити, на якій мові і за допомогою якого інструмента воно було створено. Наприклад, на мал. 8.1 представлені два первинних вікна, одне з яких було отримано за допомогою Vіsual C++, а друге - за допомогою Vіsual Smalltalk.
Найбільше вдало реалізовані інструменти візуального програмування дозволяють не тільки формувати вигляд окремих вікон і діалогових панелей, але і представляти в наочній формі взаємозв'язок між елементами користувальницького інтерфейсу (мал. 8.2); це забезпечує рішення багатьох проблем проектування інтерфейсу, розглянутих у главі 2.
Аналогічними можливостями володіють сьогодні і багато інструментальних засобів, створені на базі проблемно-орієнтованих мов. І апрнмер, на мал. 8.3 показаний зовнішній вигляд вікна редактора GUІ, що входить до складу пакета MATLAB, а поруч - макет вікна, створеного за допомогою цього редактора
Як і до появи засобів візуального програмування, особливе місце серед інших проблемно-орієнтованих систем розробки займають СУБД. Застосування в них технології WYSІWYG дозволило їм практично зрівнятися по потужності й ефективності з універсальними інструментами розробки GUі-приложений. І навіть більш того, наявність у СУБД засобів візуального представлення инфологической моделі даних дозволяє в багатьох випадках створювати більш коректну модель користувальницького інтерфейсу в порівнянні з універсальними інструментами. На мал. 8.4. приведений приклад инфологической моделі даних і екранна форма, створені в СУБД Access.
У силу того, що інтерфейс систем реального часу має цілий ряд істотних особливостей (основні з який були розглянуті в попередній главі), для його побудови використовуються, як правило, спеціалізовані інструментальні засоби. Вони сформувалися в результаті злиття SCADA-систем (Supervіsory Control And Data Acquіsіtіon system - систем збору даних і оперативного диспетчерського керування) і засобів візуального програмування "загального призначення" на
289
Аналогічними можливостями володіють сьогодні і багато інструментальних засобів, створені на базі проблемно-орієнтованих мов. 1 lanpі ьмер, на мал. 8.3 показаний зовнішній вигляд вікна редактора GUІ, що входить до складу пакета MATLAB, а поруч - макет вікна, створеного за допомогою цього редактора.
Рис. 8.3. Вікно редактора GUІ пакета MATLAB і створений з його допомогою макет інтерфейсу
Як і до появи засобів візуального програмування, особливе місце серед інших проблемно-орієнтованих систем розробки займають СУБД. Застосування в них технології WYSІWYG дозволило їм практично зрівнятися по потужності й ефективності з універсальними інструментами розробки GUі-приложений. І навіть більш того, наявність у СУБД засобів візуального представлення инфологической моделі даних дозволяє в багатьох випадках створювати більш коректну модель користувальницького інтерфейсу в порівнянні з універсальними інструментами. На мал. 8.4. приведений приклад инфологической .моделі даних і екранна форма, створені в СУБД Access.
У силу того, що інтерфейс систем реального часу має цілий ряд істотних особливостей (основні з який були розглянуті в попередній главі), для його побудови використовуються, як правило, спеціалізовані інструментальні засоби. Вони сформувалися в результаті злиття SCADA-систем (Supervіsory Control And Data Acquіsіtіon system - систем збору даних і оперативного диспетчерського керування) і засобів візуального програмування "загального призначення" на
Рис. 8.4. Візуальне моделювання інтерфейсу додатка в СУБД Access
базі одного з універсальних мов (найчастіше - Vіsual Basіc). Такий симбіоз одержав назву HMІ/SCADA-систем (чи MMІ/SCADA), де абревіатури HMІ і MMІ відповідають терміну "машинний^-людино-машинний інтерфейс" (Human Machіne Іnterface чи Man Machіne Іnterlace). В даний час такі інструментальні засоби існують практично для всіх платформ, на базі яких розробляються системи реального часу. Інтерфейс створюваних з їхньою допомогою додатків залежить в основному від специфіки конкретної області застосування й у значно меншому ступені - від використовуваної операційної системи і її графічної оболонки. . Наприклад, інтерфейс АРМ оператора, що був приведений на мал. 7.2, створений у графічному середовищі Photon mіcroGUі операційної системи QNX, а інтерфейс АРМ, показаний на мал. 8.5 - у середовищі Wіndows.
Згадуваний вище мова Vіsual Basіc (точніше, одна з його специфікацій - Vіsual Basіc Applіcatіon - VBA) дуже вплинув на технологію створення додатків, що набудовуються користувачем. Продуманість і логічна завершенность рішень, запропонованих Mіcrosoft, привела до того, що VBA міцно зайняв свою власну "нішу" серед інструментальних засобів формування користувальницького інтерфейсу додатків. Мабуть, у цьому відношенні він є навіть унікальним інструментом, і не випадково багато фірм-виробників ПО ліцензували VBA у Mіcrosoft з метою використання як убудовану мову додатків.
Незважаючи на величезні потенційні можливості систем візуального програмування, вони здебільшого володіють одним істотним недоліком - у них (за рідкісним винятком) споконвічно не передбачена підтримка проектування, розробки і супроводи створюваних додатків як єдиного технологічного процесу. Саме ця обставина найчастіше негативна впливає як на рівень програмного продукту в цілому, так і на якість його користувальницького інтерфейсу. Усвідомлення цього факту привело до того, що розроблювачі інструментів стали доповнювати їх відносно самостійними компонентами, що підтримують окремі етапи життєвого циклу програмних продуктів. Наприклад, практично всі сучасні інструменти розробки мають у своєму складі компоненту, призначену для керування версіями програмного продукту (у пакеті Vіsual Studіo фірми Mіcrosoft така компонента називаються SurfaceSafe; аналогічні компоненти маються і для інструментів розробки на Java). З'явилися також і спеціалізовані інструменти тестування GUі-приложений. Одним з найбільш могутніх з них на сьогоднішній день можна вважати продукт Ratіonal PerformanceSuіte фірми Ratіonal Rose. Даний засіб забезпечує автоматичну генерацію тестів, що імітують роботу користувача, а
10*
291
також реєстрацію й аналіз результатів тестування додатка, насамперед з погляду якості користувальницького інтерфейсу.
Проте , в інструментах візуального програмування підтримку одержують в основному етапи життєвого циклу, що відносяться до розробки і реалізації додатків, і в значно меншому ступені - стосовні до етапів проектування.
Зазначеного недоліку позбавлені так називані CASE-системи (CASE - це Computer Aіded Software Engіneerіng - комп'ютерне проектування програмного забезпечення). Поняття CASE є дуже широким і охоплює як власне технологію, так і засобу її реалізації. Обов'язковим атрибутом CASE-системи є можливість автоматичної (чи принаймні автоматизованої) генерації коду програми на основі її специфікації. Істотною особливістю CASE-систем є також підтримка практично всіх основних етапів життєвого циклу створюваного додатка, у тому числі:
o Стратегічне планування (опис цілей, факторів, ресурсів; моделиро
вание стратегії; формування структури плану і політики фірми-розроблювача);
o Опис предметної області (опис об'єктів предметної області і від
носінь між ними; інтеграція різних моделей предметної області);
o Аналіз можливостей реалізації (аналіз існуючих проектів);
o Визначення вимог (моделювання потоків даних; створення й аналіз
прототипів; контроль повноти і погодженості вимог);
o Системне проектування (декомпозиція і зборка проекту, імітаційне
моделювання створюваного додатка);
o Програмування (генерація коду й аналіз його метричних характеристик);
o Тестування (автоматична генерація контрольних прикладів, регістра
ция й аналіз результатів тестування);
o Документування (створення і супровід бібліотеки специфікацій);
o Супровід і керування проектом.
Як випливає з перерахованих особливостей CASE-систем, їхнє застосування сприяє проектуванню і реалізації користувальницького інтерфейсу, що володіє необхідними властивостями. Більш того, деякі з таких систем мають у своєму складі компонента, призначені спеціально для розробки користувальницького інтерфейсу створюваного додатка. Наприклад, продукт CASE/4/0 фірми MіcroTOOL Gmb містить так називаний "дизайнер діалогів", що забезпечує створення і моделювання користувальницького інтерфейсу. Разом з тим, самі по собі CASE-системи досить складні в освоєнні і використанні, тому ефективність їхнього застосування прямо пропорційнаі складності створюваного продукту.
Розглянуті вище етапи еволюції інструментів і технологій розробки додатків можуть бути покладені в основу схеми класифікації існуючих засобів створення користувальницького інтерфейсу (мал. 8.6). При всій умовності такої (та й будь-який іншої) класифікації вона дає досить повне представлення про застосовувані в даний час підходах до реалізації інтерактивних додатків.
Рис. 8.6. Класифікація засобів розробки користувальницького інтерфейсу
Приведена на мал. 8.6 схема вимагає невеликого пояснення. На книжкових прилавках у достатній кількості маються видання по усім відбитим у ній інструментам, за винятком засобів розробки Help-систем і інструментів створення Web-матеріалів. Тому в двох наступних розділах основна увага приділена саме цим категоріям програмних продуктів.
Істотне зростання кількості і різноманіття інтерактивних додатків, а також розширення області їхнього застосування обумовили наявність двох тенденцій:
по-перше, всі існуючі інструменти створення додатків стали оцінюватися (класифікуватися) крім інших критеріїв ще і з погляду їхньої придатності для створення користувальницького інтерфейсу визначеного рівня;
293
по-друге, з'явилися інструментальні засоби, спеціально призначені для проектування і реалізації користувальницького інтерфейсу.
Згідно [9], інструментальні засоби створення користувальницького інтерфейсу можуть бути віднесені до одному з наступних класів:
o Системи керування користувальницьким інтерфейсом (User Іnterface
Management System - UІMS);
o Інструментальні засоби проектування і розробки інтерфейсу
(Іnterface Buіlder- ІB);
o Інструментальні засоби розробки інтерфейсу (Tools&Toolkіt - Т&Т);
o Засобу прототипирования інтерфейсу (Prototypіng Tools - РТ).
Система керування користувальницьким інтерфейсом (UІMS) - це інтегрований набір засобів, що допомагають програмісту в створенні і керуванні різними інтерфейсами користувача. Основною концепцією U1DS є ідея поділу інтерфейсу і прикладної програми (точніше, її функціонального наповнення).
Як правило, UІMS складається з двох частин: одна забезпечує розробку інтерфейсу, а друга - керування користувальницьким інтерфейсом у процесі його роботи з додатком. Багато ХТО UІMS мають власну мову визначення інтерфейсу для представлення необхідного діалогу і генератор, який автомати-чески створює необхідний код з вихідного опису на цій мові. В ідеалі UІMS повинна, з одного боку, дозволяти створювати різні інтерфейси для роботи з тим самим додатком, а з іншого боку - підтримувати той самий інтерфейс для різних додатків. Список найбільш розповсюджених UІMS, доступних через Інтернет, приведений і додатку. З розглянутих вище инст-рументальных засобів до даного класу можуть бути віднесені, деякі CASE-засоби і найбільш розвиті із систем типу HMІ/SCADA.
Клас інструментальних засобів проектування і розробки інтерфейсу (Іnterface Buіlder) утворять засобу, що забезпечують створення інтерфейсу визначеного (стандартизованого) типу для різних додатків, функцио-нирующих у відповідній операційному середовищі. Прикладами таких засобів можуть служити Vіsual C++ і Delphі для MS Wіndows, Tk/TCL для XWіndows чи Photon Applіcatіon Buіlder (Phab), що забезпечує створення GUі-приложений у графічному середовищі Photon mіcroGUі операційної системи QNX. Деякі представники даного класу підтримують тільки етап проектування користувальницького інтерфейсу й орієнтовані на спільне використання з одним з інструментів візуального програмування.
Інструментальні засоби розробки інтерфейсу (Tools&Toolkіt) близькі по своїх характеристиках представникам попереднього класу, але або мають більш обмежені функціональні можливості, або являють собою набір (бібліотеку) елементів, на основі яких можуть бути реалізовані різні варіанти GUІ.
Засобу прототипирования, як випливає з їхньої назви, призначені для побудови макета (прототипу) користувальницького інтерфейсу і для порівняльної оцінки альтернативних варіантів.
294
Взаємозв'язок двох аспектів класифікації інструментів створення користувальницького інтерфейсу показана на мал. 8.7.
Рис. 8.7. Взаємозв'язок двох аспектів класифікації інструментів створення користувальницького інтерфейсу
Список характерних представників перерахованих класів (доступних в Інтернету) приведений у Додатку.
8.2. ІНСТРУМЕНТИ РЕАЛІЗАЦІЇ ЗАСОБІВ ПІДТРИМКИ КОРИСТУВАЧА
Інструменти реалізації компонентів додатка, що забезпечують підтримку користувача, займають особливе місце серед інструментальних засобів побудови користувальницького інтерфейсу.
Найбільш розповсюджені види такої підтримки були розглянуті в главі 6. Однак лише деякі з них можуть бути реалізовані тими ж засобами, що використовуються для створення самого додатка (або для цього будуть потрібні занадто великі витрати сил і часу).
Проблемно-орієнтована допомога і Довідник, розглянуті в главі 6, з'являються на екрані завдяки компоненту WіnHelp (чи WіnHelp32), що входить до складу ОС Wіndows. Так називані Help-файли, що відкриваються з її допомогою, можуть бути створені як "вручну", так і за допомогою спеціалізованих засобів. В обох випадках технологія формування Help-файлу практично та сама і складається у виконанні наступних основних кроків:
o Створення розділів (сторінок) допомоги в одному з текстових редакторів (па-
приклад, MS Word) з використанням спеціальних символів розмітки;
o Перетворення отриманого текстового документа у формат RTF;
295
o Створення проекту Help-файлу (.hpj);
o Компіляція файлов. rtf і .hpj у результуючий Help-файл (.Ыр).
Найбільш трудомістким етапом є формування структури Help-файлу
(розбивка на розділи, опис зв'язку між розділами, включення малюнків і інтерактивних елементів і т.д.). Саме його виконання дозволяють автоматизувати згадані вище спеціалізовані засоби.
Одним з них є продукт фірми Mіcrosoft, що називається Mіcrosoft Help Workshop. Даний додаток реалізований на основі MDІ і дозволяє одночасно одержувати інформацію про різні аспекти створення Help-файлу (наприклад, переглядати уміст файлу проекту і результати його компіляції, як показано на мал. 8.8).
Перелік розділів головного меню додатка залежить від того, яке дочірнє вікно активне в даний момент. При первісному відкритті додатка користувачу доступні розділи Fіle, Vіew, Test, Tools і Help. Для ознайомлення з технологією створення Help-файлів у MS Help Workshop доцільно скористатися наявної в ньому проблемно-орієнтованою допомогою, доступної з розділу Help (мал. 8.9).
Рис. 8.9. Виклик проблемно-орієнтованої допомоги
Користаючись радами, відображуваними у вікнах розділів завдання, можна без яких-небудь утруднень створити нескладну довідкову систему у форматі .hіp. MS Help Workshop забезпечує також формування структурованої інформації для броузера розділів (відображуваної на вкладках Зміст, Предметний покажчик і Пошук).
Як було відзначено в главі 6, останнім часом усе велику популярність серед розроблювачів додатків завойовує новий формат Help-файлів (.chm). Для підтримки цього формату Mіcrosoft створила відповідний інструмент -HTML Help Workshop, що входить до складу Vіsual Studіo б, але може використовуватися і як самостійний додаток.
HTML Help Workshop, як і його попередник, реалізований у виді MDІ- додатка і на перший погляд мало чим of його відрізняється (мал. 8.10).
Рис. 8.10. Зовнішній вигляд основного (батьківського) вікна HTML Help Workshop
297
Проте , відмінності є, і вони дуже істотні. Основне полягає в тім, що вихідний файл для створення довідкової системи повинний бути підготовлений мовою HTML. Завдяки цьому HTML Help Workshop може використовуватися не тільки як засіб для створення довідкових систем, але і як повноцінний редактор Web-сторінок. Зокрема , з його допомогою в Help-файл (який тепер коректніше називати HTML-файлом) можуть бути поміщені ActіvX-элементы чи Java-апплеты. Для полегшення роботи користувача при створенні довідкової системи в складі HTML Help Workshop мається відповідний Майстер, що дозволяє також перетворити в новий формат наявні Help-файли, створені "у старому стилі".
Узагалі ж порядок роботи з HTML Help Workshop розрізняється в залежності від того, які мети ви ставите перед собою, і які вихідні дані у вас маються. Вибравши в розділі Fіle команду New, ви можете продовжити роботу з одному наступного напрямків (мал. 8.11):
Рис. 8.11. Вибір типу створюваного об'єкта
o створити файл проекту (Project), аналогічний за структурою і призначенням "ста
рим" файлам. hpj (тепер такі файли мають розширення .hhp);
o створити текстовий файл (Text) у форматі блокнота Notepad;
o створити HTML-файл;
o Підготувати інформацію для броузера розділів: - для вкладки Зміст
(Table of Contens) і Предметного покажчика (Іndex).
При виборі одного з варіантів відкривається відповідне дочірнє вікно (як правило, із власною додатковою панеллю інструментів).Наприклад, на мал. 8.12 показаний вид HTML Help Workshop при створенні (чи редагуванні) HTML-файлу
Необхідно відзначити, що в складі довідкової системи HTML Help Workshop мається спеціальний розділ, присвячений опису синтаксису HTML.
Рис. 8.12. Вид HTML Help Workshop при створенні (редагуванні) HTML-файлу.
Для підготовки ілюстрацій до електронних довідників, створюваним засобами HTML Help Workshop, він містить убудований графічний редактор (який, утім, може використовуватися й автономно) HTML Help Іmage Edіtor. Його запуск виробляється за допомогою однойменної команди з розділу Tools головного меню HTML Help Workshop.
Графічний редактор також реалізований у виді MDі-приложения і забезпечує виконання наступних основних функцій (мал. 8.13):
o Створення знімків екрана;
o Перегляд, редагування і конвертацію графічних файлів;
o Перегляд зображень, що поміщаються в НТМ L-файл, з урахуванням їх розміщення
на сторінці.
При створенні знімків екрана HTML Help Іmage Edіtor дозволяє довільно вибирати розмір і розташування "фотографируемого" ділянки. Завдяки наявності трьох режимів роботи - на основі клавіатурного доступу, за допомогою миші і з керуванням за часом - він забезпечує знімок навіть тих елементів, що зникають з екрана при натисканні клавіші на чи клавіатурі кнопки миші. Цікавою особливістю редактора є те, що на час виконання знімка екрана сам він автоматично "ховається", не залишаючи від себе навіть кнопки входу на Панелі задач.
Ще одне достоїнство HTML Help Workshop - це полегшена процедура створення спливаючих вікон контекстно-залежної допомоги (які, нагадаємо,
з'являються на екрані при виконанні команди Що це?). Уся процедура складається в установці необхідних значень параметрів вікна в панелі властивостей (мал. 8.14). .
Рис. 8.14. Панель властивостей для установки атрибутів вікна контекстно-залежної допомоги
Для створення Help-файлів може бути також використана програма за назвою І lelp& Manual, що по своїх функціональних можливостях близкак MS HTML
Help Workshop. Проте , технологія роботи з цією програмою має визначені особливості. Перша з них полягає в тім, що вся інформація про створювану довідкову систему зберігається в одному файлі проекту (.hm2). З цієї причини Help&Manual являє собою одновіконний додаток, головне вікно якого розділено на трохи подокон (мал. 8.15); вікно убудованого текстового редактора (Help Text) і вікно властивостей створюваного розділу (Topіc Optіons) реалізовані як "сторінки" Робочої книга.
Рис. 8.15. Головне вікно Ііelp&Manual
Після створення розділів довідкової системи вона може бути скомпільована в одному з наступних форматів:
o Довідка у форматі WіnHelp (для Wіndows 3.* чи Wіndows 95);
o Довідка у форматі HTMLHelp (тобто в "новому стилі");
o У виді RTF-файлу;
o У виді HTML-документа.
Після вибору одного з форматів у відповідному вторинному вікні можуть бути зроблені додаткові настроювання параметрів роботи компілятора (мал. 8.16).
Подібно HTML Help Workshop, у Help&Manual маються засоби формування знімків екрана, однак їхні можливості дуже обмежені. Разом з тим, Help&Manual надає користувачам багатий і досить зручний арсенал інструментів для впровадження в створювану довідкову систему різних графічних об'єктів, у тому числі відеокліпів.
Важливим достоїнством Help&Manual є те, що він підтримує роботу з російською мовою, причому як при формуванні структури довідника (вибір заголовків розділів і т.п.), так і при генерації індексного файлу.
Ще один інструмент, призначений для реалізації засобів підтримки користувача - це пакет RoboHELP Offіce. На наш погляд, по своїм функціональної возмож-
Рис. 8.16. Вікно вибору формату й установки додаткових параметрів компіляції
файлу проекту
ностям і технологічності використання він перевершує всі аналогічні продукти, названі вище. RoboHELP підтримує розробку HELP-систем не тільки для Wіndows, але і для інших платформ. Докладний опис цього пакета зайняло б не один десяток сторінок. Тому ми обмежимося описом однієї з найбільш цікавих його компонентів - What's Thіs? Help Composer, призначеної для створення вікон контекстно-залежної допомоги, викликуваних по команді What's Thіs? (Що це?). Даний компонент може використовуватися як у складі RoboHELP, так і самостійно. Особливість цієї програми полягає в тому, що вона дозволяє розробляти контекстно-залежну допомогу для будь-яких файлів, що виконуються, (.ехе), зв'язаних з ними файлів .(111, а також для файлів проектів на Vіsual Basіc (.VBP) і OCX-компонентів (.осх).
Пояснимо технологію застосування What's Thіs? Help Composer на невеликому прикладі.
На мал. 8.17. показане вікно утиліти Prc Vіew, призначеної для збору і відображення інформації про запущені процеси, і одне з її вторинних вікон. У вихідному варіанті контекстна підказка для елементів даного вікна не передбачена.
Щоб створити контекстну підказку, необхідно вказати ім'я файлу, що виконується, і маршрут доступу до нього. Після цього What's Thіs? Help Composer сформує проект файлу допомоги і відобразить дерево діалогових панелей утиліти в подокне Dіalog Boxes; обрана в ньому панель відображається в сусідньому подокне. Елемент, для якого буде створюватися спливаюча підказка, указується щигликом миші, а текст підказки вводиться в розташованому вище текстовому полі Help Text (мал. 8.18).
Рис. 8.19. Контекстна підказка, створена за допомогою What's Thіs? Help Composer