ПІК / Перевод / перевод / НОВОЕ-В-ИНТЕРФЕЙСЕ / Chapt6

Розділ 6. ПЕРСПЕКТИВИ РОЗВИТКУ І РІВНІ КОРИСТУВАЛЬНИЦЬКОГО

ІНТЕРФЕЙСУ

Основні поняття глави: екранна метафора, віртуальний ма-

кет, принципи прямого маніпулювання, типи меню,

гіпертекст, рівні користувальницького інтерфейсу

6.1 Рівнобіжне проектування і користувальницький

інтерфейс.

Останнім часом придбала виразні обриси нова

рівнобіжна технологія проектування устаткування і програмного

забезпечення, що значно змінює вимоги до відповідного

програмним інструментальним засобам (ИС). Ми вже звикли до

того, що ИС придбали самостійне, а іноді навіть довлеющее на

процедури проектування вплив. Логіка дії з ИС початку сама

формувати етапи розробки проекту. Але в даному випадку ситуація

різко змінилася і як би повернулася до первісного

докомпьютерной стадії, коли ведучим був не комп'ютер. Усе

сказане відноситься до так називаного рівнобіжного

проектування. Розглянемо його передумови більш уважно.

Для традиційного послідовного проектування

характерний ряд логічно наступних один за іншим етапів: задум,

технічне завдання, ескізний проект, чорновий проект,

технологічний проект, макетування, іспити і т.д. У такій

послідовності є необхідна і достатня логіка, по

якій "віз не може випливати перед коня", тобто іспиту

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

і розумні. Однак такої послідовності присущи і недоліки. Зокрема

, якщо яка-небудь недоробка закралася на етапі

ескізного проекту і залишилася непоміченої, усувати її найчастіше

приходиться вже після іспитів. Подібних недоробок завжди буває

предосить, і утрати від їхнього усунення і перетворення всієї

документації виражаються значними сумами.

Ще один недолік послідовного проектування складається

в роз'єднаності і наступних звідси розходженнях з метою в різних

груп, що беруть участь у проекті. Конструктори, технологи і випробувачі

часто переслідують взаємовиключні цілі і говорять різними

мовами. У зазначених, а також багатьох інших недоліках

послідовного проектування таїться його значна

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

прискоренню процесу проектування устаткування.

Удосконалювання САПР традиційно реалізовувало

послідовну стратегію, прискорювало виконання кожного з етапів

на окремому робочому місці, і в цьому минулому досягнуті значні

успіхи.

Але кардинального ефекту удалося досягти лише при зміні

самої стратегії проектування, обумовленої проектуванням

рівнобіжним. Так наприклад, за даними Національного інституту

стандартів і технології США, об'єднання Thomas Group Іnc. і

інституту дослідження оборонних проблем (ІDA) рівнобіжне

проектування зменшує витрати часу проектування на 30-70%,

знижує обсяги усунення конструкційних недоліків на 65-90%,

прискорює час до виходу устаткування на ринок на 90%, підвищує

його якість на 200-600% (1).

Рівнобіжне проектування спирається на нову організацію

діяльності проектувальної, технологічної і испытательской

груп, нову методологію проектування і відповідні їм

програмні засоби автоматизації проектування.

Виходячи з того, що два перших напрямки не входять у поле

розгляду даного тексту, обмежимося лише вказівкою на

подібність даних змін на те, чим уже більш двадцяти років

займається у вітчизняній традиції група Г.П.Щедровицкого.

Багато підходів і проблеми рівнобіжного проектування

дивним образом нагадують метод

организационно-деятельностного проектування. Що ж стосується

програмних засобів і зокрема їхнього користувальницького інтерфейсу,

виділимо наступне.

1. Оскільки губиться поділ у часі етапів ескізного

проекту і розробки технології виробництва нового обладнання,

виникає необхідність майже із самого початку робіт відтворити

зовнішній і внутрішній вигляд проектованого виробу. Цьому

сприяють засобу комп'ютерного моделювання і графіки.

2. Об'єктивне чи представлення, іншими словами,

"віртуальний макет"виробу в стані відбивати більшість його

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

конкретизувати і фіксувати його запити.

3. Той же віртуальний макет дозволяє знизити

неоднозначності у взаємодії конструкторів і технологів,

швидше знаходити й усувати протиріччя в їхніх підходах до виробу.

4. Рівнобіжна робота різних фахівців над виробом

знаходить висвітлення в єдиних для всієї групи базі даних і базі

знань. Створюється свого роду загальний довідник розроблювачів, куди

автоматично заносяться всі нововведення і висновки, отримані

кожним із членів групи в ході роботи. Це створює новий рівень

"прозорості" засобів проектування.

5. Рівнобіжна робота різних фахівців веде до

об'єднання різних інструментальних програмних засобів, наприклад,

САПР і Засобів Автоматизації Економічної Оцінки: за даними (2),

уже практично об'єднані ИС електричного проектування,

проектування програмного забезпечення, замовлених

експериментальних засобів, проектування електронних блоків і

плат і підготовки технічної документації.

6. Проблема користувальницького інтерфейсу, що відображає

дані, активно трансформується в проблему інтерфейсу, що

відображає знання.

7. Використання єдиної системи фахівцями не тільки

різного профілю, але і різного рівня комп'ютерної підготовки

диктує нові вимоги до гнучкості й адаптивності

користувальницького інтерфейсу. Зокрема , це стосується

взаємозамінності різних типів представлення об'єкта і режимів

ведення діалогу з користувачем.

8. Нові вимоги пред'являються до розмаїтості видів

допомоги користувачу з боку комп'ютера, що вже саме по собі

повинно підсилювати інтелектуальну складову інструментальних

засобів. Повинна варіюватися й активність системи у веденні

діалогу.

Ми торкнемося кожного з виділених напрямків

удосконалювання ИС, почавши, проте , із загальних проблем

користувальницького інтерфейсу.

У 1983 році Бен Шнейдерман сформулював принципи прямого

маніпулювання при роботі сучасного інтерфейсу (3):

1) на його думку, прийшов час, коли коштує опосередковане

даними представлення про об'єкт проектування доповнити його

постійним візуальним представленням;

2) складний синтаксис при веденні діалогу варто замінити

очевидними фізичними діями, здійснюваними за допомогою

курсору, пристрою "миша", джойстика й інших периферійних

пристроїв;

3) варто домагатися оборотності дій і очевидності їхнього

впливу на об'єкт;

4) Різницю в комп'ютерній підготовці користувача можна

компенсувати спрощенням початкових дій з ИС і поступовим

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

Принципи прямого маніпулювання виявилися дуже коштовними і

зорієнтували розроблювачів інтерфейсів у напрямку предметної

представленості комп'ютерних процесів і засобів. Зазначені

принципи привели до появи поняття "метафора відображення", що

фіксує представлення на екрані дисплея цілісних логічно

закінчених ситуацій діяльності користувача. Наприклад, у (4)

указується на три найбільше що часто зустрічаються метафори:

"письмовий стіл", "робочий кабінет" і "креслярська дошка".

Природно, це далеко не повний перелік метафор. Фактично,

майже будь-яка ситуація в діяльності користувача може бути

предметно відбита на екрані дисплея. Так, Дж.Новеллино повідомляє про

пакет програм Vіewdac, що дозволяє будувати метафору, що

моделює панель керування (5). У віртуальній панелі можна

модифікувати "клавіатуру", навіть не перериваючи при цьому хід

обчислювального експерименту.

Усі метафори досить предметны, взаємодія з ними відповідно

до третього принципу Б.Шнейдермана приводить до

очевидних наслідків. Кнопки віртуальної панелі "натискаються",

як, наприклад, в інструментальному блоці Toolbar (6), а документи

переміщаються по робочому столі, як в інтерфейсах фірми Apple.

Розроблювачі інтерфейсів прагнуть до відображення реального

світу, а по деяких властивостях навіть перевершують можливості

реальності. Сказане можна віднести насамперед до відтворення

і моделювання процесу в часі. Це саме той випадок, коли

можливості комп'ютера в моделюванні перевершують можливості

моделювання реального. Пояснимо на прикладі. Компанія

Іnternatіonal/Mіcrocіrcuіts повідомила про створення комплексу ИС

(PC-Easy-Gate) для розробки програмного забезпечення, що

дозволяє відображати пряме і зворотне сканування

функціонування програм з метою пошуку помилок і прорахунків (7).

Інтерфейси більш багаті, чим реальність, з'являються й у

випадку так називаного комплексного представлення інформації,

коли інтегрується комп'ютерне і відеозображення, а також

виробляється озвучення інтерфейсу. Так, система Super Vіdeo

Wіndows відтворює зображення з рухом і стереозвуком з

камери, касетного видеоплеера, відеодисків, кабельного

телебачення у вікні будь-якого розміру й у заданій області екрана

дисплея. Розширилися і можливості маніпулювання цією

інформацією. Зокрема , зазначена система дозволяє реалізувати

наступні функції: масштабирование зображення, його обрізку в

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

текстове накладення на екран (8). Однак, таке багатство функцій

може не тільки не знадобитися користувачу, але в деяких

випадках і утрудняти його діяльність. Така думка цілком

традиційна і порівнянна з класичними

інженерно-психологічними вимогами до інформаційних моделей

(9). Відображатися повинні лише ті властивості, що приймають саму

особисту участь у діяльності користувача.

Сказане знайшло відображення в етапах проектування

користувальницького інтерфейсу, запропонованих у (10):

а) аналіз предметної області і побудова її концептуальної

моделі;

б) виділення з цієї моделі тієї частини, що повинна бути

доступна користувачу, і на її основі побудова моделі

прикладного інтерфейсу;

в) для складних моделей, що мають фрагменти з регулярною

структурою, вибір мови взаємодії, що дозволяє ефективно

будувати команди-пропозиції і передавати їх у модель інтерфейсу;

г) побудова объектно-ориентированного інтерфейсу, що

включає опис його поводження, візуалізацію і конфігурацію

полів і вікон.

Слід зазначити, що багато чого в змісті етапів

припускає имено обґрунтований вибір властивостей, що безпосередньо

беруть участь у діяльності користувача. При таких можливостях від

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

У зв'язку з цим приходить у голову відома опозиція

недопрограмованих і перепрограмованих комп'ютерних систем,

кожна з який має свої недоліки. Задача ж

проектувальника інтерфейсу часто складається в пошуку того оптимуму,

що дозволив би звільнитися від недоліків обох пологів.

Зрозуміло, що звільнитися від недоліків користувальницький

інтерфейс може лише в тому випадку, якщо процес його розробки і

настроювання перетвориться в технологію і буде оснащений власними

засобами автоматизації. Це може означати, що традиційна

архітектура користувальницького інтерфейсу доповниться новим шаром.

Загальноприйнято, нинішня його архітектура містить чотири шари

програмного забезпечення (11):

1) графічний інтерфейс для керування апаратурою дисплея;

2) інструментальні засоби (toolkіts) для побудови

стандартних компонентів інтерфейсу, що називають кубиками

(wіdgets);

3) сам набір кубиків;

4) програма інтерфейсу високого рівня для процедур з

операційним середовищем.

Ясно, що зазначені чотири шари дозволяють користувачу

видозмінювати інтерфейс у широких межах, змінювати колір, шрифт,

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

не може. Ця область формалізована ще недостатньо. Тому

п'ятим шаром архітектури інтерфейсу має шанс стати експертна

система, що містить досвід побудови користувальницьких інтерфейсів.

Утішно, що повідомлення про експертну систему такого роду, що

містить поки 200 правил, з'явилося у вітчизняній періодиці

(4). Є дані і про створення більш обмежених інструментальних

засобів, зокрема , в області проектування діалогового режиму

типу меню (12).

Технологія проектування користувальницького інтерфейсу

здобуває усе більше значення. За деякими оцінками (2), при

створенні нових інструментальних засобів на користувальницький

інтерфейс і модулі доступу до баз даних приходиться до 65%

трудомісткості робіт. Зрозуміло, що при цьому зазначені частини

програмного забезпечення розглядаються з набагато більш широких

позицій, чим це прийнято в нашій літературі. Розробка інтерфейсу

виходить далеко за рамки вибору режиму діалогу, розташування

елементів чи екрана його фарбування. Користувальницький інтерфейс у

сучасному змісті - це фактично сукупність

програмно-інструментальних засобів, що приймають участь у всій

діяльності користувача. Це комп'ютерна підтримка і навіть

удосконалення самої людської діяльності. Зрозуміло, що

при цьому розвитку піддаються і конкретні процедури проектування

інтерфейсу, у тому числі фарбування і розташування елементів екрана.

У зв'язку з вищевикладеним представляється доцільним

увести розрізнення двох рівнів користувальницького інтерфейсу і

відповідних чи поверхів напрямків його удосконалювання: мікрорівень і макрорівень інтерфейсу. Надалі ці рівні

будуть розглянуті роздільно.

6.2 Мікрорівень користувальницького інтерфейсу.

У вже згаданій книзі Р.Уаттса (13) зазначені шість режимів

ведення діалогу з користувачем:

- запит з позиційним вибором;

- відповідь-питання-відповідь;

- вибір з меню;

- заповнення бланків і відповіді з указівкою;

- команди системі і діалог природною мовою.

Кожний з режимів найбільш зручний при визначеному сполученні

умов, серед яких підготовленість користувача, час

освоєння режиму, його виразні властивості, характер переданої

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

умовою, що підкреслюється, зокрема , у (4), і з який

ми цілком згодні, є характер прийняття ініціативи в

діалозі. Відповідно до цієї умови всі режими діалогу можна

представити у виді типології.

Якщо ініціативу приймає на себе система, обмежуючи

синтаксис відповіді користувача, то такий режим - слідом за (14) -

можна назвати відповідною-відповідним-запитально-відповідним. Його варіантами є вибір з

меню, запит з позиційним вибором, відповідь-питання-відповідь, заповнення

бланків і відповіді з указівкою.

Якщо ініціатива віддається користувачу, і він більш вільний у

побудові висловлень на деякій командній мові, то такий

режим можна назвати директивним. Прикладами директивного режиму

є команди системі і діалог природною мовою.

Природно, що процес роботи із системою часто буває

неоднорідним у тім змісті, що задача користувача може

змінюватися від початку до кінця діалогу. Це означає, що ініціатива

може і повинна переходити "з рук у руки". Такий діалог

проектується з частин як відповідних-відповідної-запитально-відповідного, так і директивного

режимів і називається змішаним.

Багато вітчизняних розроблювачів програмного забезпечення

не бачать важливості правильного вибору режиму діалогу, обмежуючи

створенням одного режиму, найчастіше вибору з меню. Саме цей

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

задача вибору режиму діалогу не так елементарна і прямо

корелює з ймовірним тиражуванням створеної програми.

У зв'язку з надзвичайною поширеністю меню важливо,

наприклад, окреслити область застосування цього режиму. Такою

областю є винятково задачі так називаного

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

треба здійснювати вибір одного чи декількох з них.

За рівнем складності бувають меню трьох типів: просте,

багаторівневе і мережне (12). Простої меню - це список пунктів,

з кожним з який зв'язане визначена дія. Спроба

використовувати простої меню для організації вибору з більш ніж 5-9

об'єктів веде спочатку до психологічних складностей (тому що

губиться його основна властивість - простота і наочність), а потім

і до переповнення екрана. Тому в діалогових системах часто

використовується багаторівневе меню з деревоподібною структурою. При

цьому вершинами дерева служать прості меню, а перехід до його галузей

реалізується вибором одного з пунктів простого меню. Побудова

багаторівневих меню прямо зв'язано з проблемою "прозорості"

системи для користувача. Справа в тім, що в багаторівневому меню

можна просто "заблудитися". Тому найбільш зроблені системи

містять режим підказки, у якому користувачу демонструється

повна карта (дендрограмма) меню і його місце на ній у даний

момент.

Ще одна проблема складається у виборі рівня твердості

дендрограммы. Основне питання даної проблеми формулюється

в такий спосіб: " чизавжди щоб досягти визначеного пункту меню користувач повинний робити однакову послідовність виборів? І якщо ні, те чи не може він за допомогою якої-небудь процедури очутитися відразу в необхідній вершині?" Ця проблема знайшла

позитивне рішення за допомогою додаткового режиму

директивного влучення в необхідну вершину багаторівневого меню.

Третій тип меню - мережний - виявляє собою розвиток

багаторівневого меню, коли галузі дерева перетинаються, і

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

по різних маршрутах. Мережна структура меню відкриває перед

розроблювачами інтерфейсу і користувачами новий шар

можливостей. Зокрема , таке меню дозволяє вийти за рамки

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

довідкові і навчальні системи, побудовані на принципах

гіпертексту (15). У цьому випадку кожне простої меню,

представлене у виді фрагмента гіпертексту, містить ключові

слова, кожне з який є виходом в інше простої меню.

Це новий рівень пред'явлення довідкового тексту, на якому

користувач у залежності від власних потреб і знань

може самостійно будувати стратегію ознайомлення з довідковим

чи навчальним матеріалом. Звичайно, при цьому виникають і нові

проблеми. Зокрема , у порівнянні зі звичайною посторінковою

будівлею довідкового тексту, користувачу складніше будувати

його

цілісний образ. Однак, ця проблема також може бути вирішена на

основі більш развитой дендрограммы гіпертексту. На ній повинно

демонструватися не тільки актуальне положення користувача на

карті меню, але і прокреслена в даному сеансі траєкторія

переміщень, Бути може необхідна також і бібліотека всіх

переміщень користувача на кожнім сеансі роботи із системою. Крім

цього, потрібна і сумарна карта, що демонструє всі ті вершини і

галузі, з якими користувач вже ознайомився, і ті, де йому ще

не удалося побувати. У мережному меню переборюється його

підлегла, службова функція, воно саме стає коштовним

інструментальним засобом, що виконує самостійні задачі.

Тим більше це стосується ситуацій, що виникають у зв'язку з

рівнобіжним проектуванням. Адже об'єднання інструментальних

програмних засобів з різних етапів створення нових виробів

об'єктивно веде до значного збільшення числа різноманітних

режимів, файлів, розділів інформаційно-пошукової системи.

Дендрограмма меню може виявитися дуже складної, якщо не сказати

заплутаної - з петлями і тупиками. Очевидно, що вона буде

мати потребу в доповненні багатими режимами підказки і допомоги.

Просто відображення дендрограммы меню недостатньо.

Завжди

вважалося, що вже сама по собі візуалізація процесу може допомогти

його розумінню. Але от на підставі даних з (16) можна сказати,

що схемний опис об'єкта значної складності також починає

не спрацьовувати, якщо завдання користувача полягає в тім, щоб

визначити проблеми содержащиеся в схемі. Інтерфейс сам повинний

відображати, хоча б виділяти кольором, ті частини схеми, у яких

є яка-небудь відмінність від стандартного протікання процесу. Щось

подібне відбувається в сучасних системах упакування інформації на

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

файлів, затримок у виконанні процесу, виявлення дефектних

ділянок диска. Більш складний варіант відображення такого ж типу

реалізований в інструментальному засобі TeamWork/SІ компанії Carde

Technologіes Іnc. (17). У цілому дану процедуру можна віднести і до

САПР. Одна з її функцій - відображення моделі програмних

процесів на модель тих чи інших апаратних реалізацій.

Представлення користувачу враховує "змагання" апаратних

ресурсів, що дозволяє виявляти, які частини програмного

забезпечення виконуються повільніше через невдалий вибір

апаратних засобів. У дендрограмме меню може, наприклад,

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

Обкреслені проблеми режиму вибору з меню багато в чому

характерні для всіх запитально-відповідних діалогів. Новий шар

проблем відкривається в той момент, коли користувач від задач

навігаційного типу переходить до виконання розрахункових задач, уведенню

числових чи яких-небудь інших даних. Насамперед це стосується

режиму відповідей із вказівкою і заповненням бланків, а також запитів

за зразком з позиційним вибором. Часто такого роду діалог

використовується в базах даних чи тоді, коли інформація може бути

відображена у виді чи таблиці електронного бланка. Звичайно, такий

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

з меню. І ініціатива тут у більшому ступені розподілений між

ним і комп'ютером. Допомога користувачу при роботі з бланками і

таблицями відноситься насамперед до індикації місця, куди повинна

бути введена інформація, і місць, де відобразяться наслідки від її

введення. У тому випадку коли введення повинне бути здійснене в

кілька місць, відображенню підлягає також правильна

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

можуть бути дуже значними, не входити цілком на екран

дисплея. Тому важливим є також маніпулювання масштабом

бланка, його згортання і розтягання, деталізація, а також

побудова нових бланків. В даний час широке

поширення одержали так називані крупноформатные

електронні таблиці (КЭТ). Найсучаснішими вважаються Excel 4.0

пакет фірми Mіcrosoft (6) і пакет Lotus 1-2-3 фірми Lotus

Development (18). Розрахунки за допомогою цих пакетів крім числових

значень підтримуються гарними візуалізаціями результатів.

Наприклад, Lotus 1-2-3 дозволяє одержати шістьох видів графічних

зображень результатів розрахунку: лінії, стовпці, розташовані

поруч один з одним, стовпці друг на другу, двухкоординатные

графіки, кола з заштрихованими і знімними секторами.

При роботі із самої КЭТ пакет Lotus 1-2-3 надає ряд

нових функцій. Насамперед це:

а) скорочення довжини алгоритму введення, там, де в колишніх

версіях було потрібно кілька кроків, досить одного "натискання"

на віртуальній панелі керування;

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

зафіксований результат обчислення, але він сам може його вибрати за

допомогою процедури autosum;

в) реалізовані стиск і растяжка КЭТ, що дозволяє їх

розглядати з різним ступенем деталізації;

г) можуть бути об'єднані дані з різних КЭТ.

Окрему своєрідну сферу діалогових режимів представляють

командний режим і діалог природною мовою. Проблематика цих

режимів - по більшій частині психолингвистического властивості. Можна

сказати, що два названих режими являють собою свого роду

полюса шкали, при русі по який у напрямку природної

мови росте інтелектуальна складова користувальницького

інтерфейсу. При цьому росте також і частка програмно-апаратних

ресурсів, що ідуть на підтримку інтерфейсу. Що росте не дуже

значно - так це ефективність самого діалогу. На полюсі

діалогу природною мовою інтерфейс перетворюється у свого роду

іграшку, "пожираючу" масу ресурсів, але все-таки дає

користувачу обмежені переваги. Ті ж мети можуть

досягатися набагато меншими ресурсами. Тому останнім часом

лунають голоси, що негативно оцінюють перспективи широкого

поширення діалогу природною мовою. Перспективи ж

мови команд безхмарні. На описаній шкалі можна визначити

сприятливий відрізок, усередині якого може бути забезпечена як

компактність, легкість і логічність мови команд, так і мінімум

інтелектуального інструментарію, що забезпечує вживання

синонімів і інші природні для користувача властивості мови

діалогу.

Може виявитися, що природний діалог є черговою

ілюзією хоча б тому, що комп'ютер припускає діалог набагато

більш визуализированный, чим природне спілкування. І в такого

діалогу маса додаткових дуже зручних властивостей. Адже показати

іноді можна набагато більше, ніж розповісти.

6.3 Макрорівень користувальницького інтерфейсу.

Поняття макрорівня користувальницького інтерфейсу можна

ввести, продемонструвавши область явищ, у якій він

виявляється.

Уявимо собі традиційні засоби автоматизації

проектування програмно-апаратного комплексу. Розроблювачу

приходиться працювати як мінімум з чотирма середовищами проектування:

а) інструментальними засобами (ИС) побудови

архітектурної моделі;

б) ИС моделювання її функцій;

в) ИС визначення параметрів необхідного програмного

забезпечення;

г) засобами САПР програмного забезпечення.

Усі ці засоби досить могутні і сучасні, володіють

розвитими користувальницькими інтерфейсами. Однак робота з ними

вимагає переходу від етапу до етапу. Користувачем повинні

починатися визначені зусилля для забезпечення

інформаційного обміну при переході від більш раннього етапу

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

інтерфейси між різними середовищами проектування, якщо звичайно

інтерфейси є. Кожна із середовищ може мати власну базу

даних, порівняння яких також вимагає додаткових операцій.

Інакше кажучи, незважаючи на оптимальні діалогові режими, доречні

режими допомоги користувачу, чудеса візуалізації моделируемых

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

дій, а те й операцій. Природно, що логіка розвитку і

характер незадоволеності існуючими інструментальними