Пильов В.О., Шеховцов А.Ф. Двигуни внутрішнього згоряння: Серія підручників. Том 4. Основи САПР ДВЗ

Подождите немного. Документ загружается.

4.2.2. Класифікація мов за оперативністю взаємодії

користувача з ЕОМ

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

користувача з ЕОМ, поділяють на пасивні та діалогові.

Пасивні мови дозволя-

ють задавати послідовність

проектних операцій та сукуп-

ність вхідних даних для пода-

льшого їх використання в паке-

тному режимі роботи програм.

По закінченню виконання

про-

ектних операцій отримане про-

ектне рішення подається прое-

ктувальнику. Схему взаємодії

користувача з системою в та-

кому режимі роботи зображено

на рис.4.16.

Програма

або

пакет програм

Команда

або

набір команд

та дані

Результат

Перевірка

результату

ЕОМ

Користувач

исунок 4.16 – Пакетна технологія

(режим) проектування в САПР

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

ефективним. Він відповідає задачі створення комп’ютерних систем авто-

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

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

ти системи розрахунку робочого процесу ДВЗ та паливопостачання (див.

рис.1.9). Інший приклад подано на рис.4.14, де генерація графічної інфор-

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

експериментальних даних.

При використанні пакетного режиму роботи програм необхідно

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

проектних операцій.

Діалогові мови забезпечують взаємодію проектувальника з ЕОМ на

основі взаємного обміну повідомленнями. Це дозволяє оперативно отри-

мувати проміжні результати та керувати процесом проектування. За при-

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

або будови креслення.

200

Діалогові мови ви-

користовують для двох

режимів р боти програм:

діалогового та інтерак-

тивного.

В діалоговому ре-

жимі алгоритм процесу

проектування не є повні-

стю визначеним. Необ-

хідну інформацію проек-

тувальник вносить до

системи безпосередньо в

процесі проектування

залежно від отриманих

проміжних результатів.

Після прийнятого твор-

чого рішення знову ви-

конується часткова

об-

робка даних (рис.4.17).

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

та вводяться користувачем в об’ємі, що запитує система.

Рисунок 4.17 – Діалоговий режим роботи програм

Програма

Команда

з наданого

системою

набору та (або)

частина даних

Частковий

результат.

Запит на

виконання команди

з наданого набору

та (або) на

введення наступної

частини даних

Остаточний

результат

Перевірка

результату

Перевірка

часткового

результату

проектування

ЕОМ Користувач

Таким чином, вказаний режим дозволяє підтримувати процес проек-

тування з урахуванням проміжних результатів цього проектування.

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

алгоритмізації. В таких випадках проектувальнику надається суворо ви-

значений набір команд керування системою. Система сповіщає користува-

ча про свою готовність до їх виконання. Користувач вибирає потрібну ко-

манду та

сповіщає про це систему. Для виконання команди часто виникає

потреба у введенні певного набору даних, перелік яких запитує ЕОМ, або

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

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

щодо подальшого напрямку проектування та вибору нової команди

(рис.4.18).

201

В інтерактивному режимі система чекає від користувача

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

незалежно від попередньо виконаних команд

Користувач

ЕОМ

Програма

Команда

з відомого

набору та (або)

дані до неї

Результат

виконання

команди

Остаточний

результат

Перевірка

часткового

результату

проектування

Перевірка

результату

Найчастіше інтерактив-

ний режим в САПР використо-

вують для виконання креслень

та об’ємних моделей оригіна-

льних деталей. У даному випа-

дку маємо найменший рівень

автоматизації проектних робіт,

але найбільші можливості що-

до застосування творчих здіб-

ностей людини. З цього приво-

ду ще раз підкреслимо, що си-

нтез типових деталей об

’єкта

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

за більш прогресивною з точки

зору автоматизації робіт – па-

кетною технологією обробки

даних.

В процесі виконання

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

системи на команду користувача. В ідеальному випадку цей час стає насті-

льки малим, що його не приймають до уваги – команда

виконується прак-

тично миттєво і не створює перешкод робочому ритму проектувальника. У

зв’язку з цим ефективність роботи системи в значному ступені починає за-

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

исунок 4.18 – Інтерактивний режим

взаємодії користувача з системою

в процес і проектування

Найпростіший спосіб спілкування користувача з ЕОМ – це викорис-

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

вводиться,

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

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

них. Водночас цей спосіб має наступні значні недоліки:

• процес введення передбачає багаторазове натискання на клавіші,

що стримує робочий ритм проектування;

202

• не виключається вірогідність помилкових натискань;

• словниковий запас мови забувається та повністю не буває реалі-

зованим;

• синтаксис і семантика багатьох команд без роз’яснення не є одно-

значною.

Пояснимо лише останню тезу. Наприклад, система розрахунку

поршневого кільця задає запитання: “Введіть коефіцієнт корекції епюри

тиску поршневого кільця”. Зрозуміло, що ця

величина є змінною вздовж

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

чному вигляді. Тому без знань особливостей введення значення цього мов-

ного елемента команда не буде виконана.

Для усунення вказаних недоліків у САПР приймається низка наступ-

них заходів:

9 опис команд разом з роз’

ясненнями щодо їх можливого застосу-

вання зберігається в пам’яті ЕОМ та в разі необхідності виводиться на ек-

ран безпосередньо під час роботи системи;

9 допускається скорочення слів у командах;

9 кожна команда або дані після введення перевіряються на припус-

тимість (рис.4.19).

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

тання техніки

меню. Це поняття відповідає застосуванню засобів по вибо-

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

виборі команди суттєво скорочується час на її введення та зменшується кі-

лькість помилок при введенні.

Розрізняють два види меню: динамічне та планшетне.

Динамічне меню передбачає попереднє виведення на екран основно-

го

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

на екрані з’являється відповідне підменю зі своїм набором команд. Розгор-

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

сформується для однозначного виконання. Так на рис.4.20 послідовність

команд “Вставка”–“Элементы”–“Отверстие”–“Под крепеж…” дозволяє

виконати в деталі

різьбовий отвір.

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

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

зберігається в різноманітних форматах.

203

Повідомлення

про помилку

Виконання

команди

Введення команди

та (або) набору

даних

Відображення

результату

Розуміння

помилки

Визначення

змін

Осмислення

нової команди

та (або) набору

даних

Помилок

немає

помилки

Перевірка

ез

льтат

Помилок

немає

помилки

Перевірка

ип

стимості

ЕОМ

Користувач

исунок 4.19 – Алгоритм перевірки припустимості команд і даних у САПР

исунок 4.20 – Динамічне меню системи SolidWorks

204

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

ми. Такий спосіб вибору команди було розкрито при формуванні парамет-

ричних графічних елементів (див. рис.3.51). Принципово останній спосіб

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

Планшетне меню передбачає введення команд шляхом торкання

електронним олівцем певних клітинок (полів) спеціального пристрою, що

підключається до

ЕОМ – планшета. Найпростіший приклад планшетного

меню зображено на рис.4.21.

В даному випадку виконан-

ня будь-якої команди не по-

требує послідовного розгор-

тання вкладених меню на

екрані, а зображення об’єкта

проектування не перекрива-

ється вікнами динамічного

меню. Загальна кількість

полів планшетного меню

може знаходитись у межах

від 50 до 1000. Відповідне

ПЗ надає можливість про-

грамувати поля планшета.

исунок 4.21 – Зовнішній вигляд

найпростішого планшетного меню

Комфортні умови введення команд забезпечує техніка вільних сим-

волів, які “зображують” на планшеті електронним олівцем (рис.4.22). До

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

“символів”, які вводяться, командам, що потребують виконання. В даному

випадку навіть не виникає потреби в пошуку на планшеті клітинки,

яка по-

значає певну команду.

исунок 4.22 – Подання команди “Пряма” (а) та “Коло” (б)

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

205

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

форма, а й послідовність виконання “зображення”. Так, коли символ “Ко-

ло” задано рухом електронного олівця за годинниковою стрілкою, то сис-

тема не розпізнає цю команду в разі руху олівця в протилежному напрям-

ку. При цьому також важливо, що коли у використанні знаходиться

понад

30 символів, то починають з’являтись невірні тлумачення команд систе-

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

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

Близьким до планшетного меню є використання функціональної кла-

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

клавіші, яких може бути до 100.

Обов’язковим

засобом введення команд, що на сьогодні мають усі

сучасні підсистеми САПР, є використання панелей інструментів. Такі па-

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

на екрані. Ці кнопки імітують функціональну клавіатуру та дублюють ос-

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

чають піктограмами та поєднують в

панелі інструментів. Як приклад на

рис.4.23 подано панелі інструментів графічних систем КОМПАС та Solid-

Works.

исунок 4.23 – Приклади Панелей інструментів:

а – системи SolidWorks; б – системи КОМПАС

Розглянуті та інші кнопки керування вказаних систем також можна

побачити на рис.3.51, а; 3.53; 4.20. Аналогічні панелі системи створення

специфікацій SWR-Спецификация можна знайти на рис.3.59, графічних

систем MGI PhotoSuite SE, Paint та Rhinoceros – відповідно на рис.3.28,

206

3.33, 3.34, текстового процесора Microsoft Word – на рис.3.22, системи про-

грамування Visual Basic – на рис.3.14 тощо.

З метою підвищення ефективної роботи користувача панель інстру-

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

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

ної клавіатури (“гарячі клавіші”). Все вище вказане кваліфікують як ство-

рення дружнього інтерфейсу

системи.

Іншими основними рисами дружнього інтерфейсу є наступні:

9 усі системи мають однаковий або близький інтерфейс;

9 терміни, що використовуються в усіх системах, мають однакові

значення;

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

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

друкованої документації;

9 системи дозволяють відмовитись від усіх

екранних меню та кно-

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

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

екранне поле виведення проектної інформації.

В цілому усі перелічені програмно-технічні засоби використовують

для реалізації принципу оптимальності зв’язку проектувальника з ЕОМ.

4.2.3. Класифікація мов за переважним способом

подання інформації

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

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

фічні, голосові та змішані мови.

В алфавітно-цифрових мовах описи здійснюються у вигляді рядків

символів або у вигляді таблиць. У графічних мовах інформація подається у

вигляді креслень, графіків, діаграм та іншої нарисної інформації. І

ті, і інші

мови використовують в усіх функціональних підсистемах САПР ДВЗ. При

цьому зрозуміло, що внутрішні і проміжні мови завжди повинні бути ал-

фавітно-цифровими.

Для спілкування користувача з автоматизованою системою проекту-

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

що об’єми графічної інформації, якими оперує

конструктор, набагато пе-

207

ревищують об’єми цифрових даних та технічних описів. Водночас вибір

алфавітно-цифрової чи графічної мови визначається необхідною формою

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

узгодженості САПР.

Розробка голосових мов спілкування проектувальника з ЕОМ ґрун-

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

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

діалогових

мов проектування.

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

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

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

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

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

ристувача звукові

сигнали можуть бути відключені. В своїй сукупності

змішані мови сприяють підтримці дружнього інтерфейсу системи.

4.2.4. Класифікація мов проектування по їх зв’язку

з мовами програмування

Мови проектування в процесі опису даних та дій над ними повинні

відповідати якостям мов програмування: достатнім рівнем наочності, гну-

чкості, визначеності тощо. Ці вимоги передбачають:

•

використання існуючої математичної символіки та інших зобра-

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

• виконання описів команд і даних без зайвого їх ускладнення,

пов’язаного з недосконалістю зображувальних засобів;

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

Водночас у процесі будови мовних конструкцій головним є забезпе-

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

проектува-

льнику.

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

розширення та автономні.

Мови розширення будуються на основі граматики іншої мови або є

проблемно-орієнтованим доповненням останньої. Базою такого розширен-

ня найчастіше є алгоритмічні мови високого рівня. Цей підхід дозволяє ви-

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

даних,

208

що є в базовій мові.

Універсальні алгоритмічні мови високого рівня широко використо-

вуються для створення ПЗ САПР – вони мають достатньо розвинуті мож-

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

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

користуванні. Це пояснюється складністю формулювання, перевірки, реда-

гування

і виконання команд у середовищі систем програмування. Для такої

роботи необхідною є спеціальна підготовка користувачів САПР – спеціалі-

стів прикладної сфери. Засоби дружнього інтерфейса проектування тут від-

сутні.

Разом з цим ефективним шляхом використання мов розширення є їх

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

розв’язання задачі є

повністю визначеним. В такому випадку місце мови

розширення відповідає блоку 4 (див. рис.4.2). Видно, що текст програми на

цій мові генерується певною прикладною програмою (блок 3) автоматич-

но. При цьому компілятор певної мови програмування сприймає текст про-

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

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

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

ефективність автоматичного виконання завдання.

Автономні мови проектування є альтернативою до мов розширення.

Вони забезпечують вимогу проблемної орієнтації процедур взаємодії ко-

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

Впровадження автономних мов передбачає використання техніки меню,

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

засобів друж-

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

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

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

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

послідовність дій може бути записана в системі під певним ім’ям.

Послідовність дій, що записана під певним ім’ям, зветься

макросом.

Макроси найчастіше записують мовою програмування. Так, напри-

209