Графіка або текст: яку мову потрібен програмісту?

1. Інтерес до графічних засобів програмування пояснюється поширеною думкою про безумовну перевагу графіки...
2. Психологія запам'ятовування і критерії оцінки мови
3. Текст і графіка. Плюси і мінуси
4. Створення програм. Специфіка предметної області
5. Області застосування графіки і тексту
6. Висновок
7. література

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

Більшість програмістів вважає, що графічна форма подання інформації переважно будь-який інший. На ринку з'являються різноманітні мови візуального програмування. У назвах програмних продуктів і CASE-засобів, спочатку базуються на текстовій формі опису, виробники намагаються підкреслити орієнтацію на графіку (приклад - Visual C). Вже не можна уявити життя без засобів розробки категорії WYSIWYG, а переважна більшість програм для ПК реалізується відповідно до формули WIMP (window - icon - menu - pointing_device). Як епітетів для графічних засобів використовуються слова «дружній», «інтуїтивно зрозумілий», «простий», «привабливий». Часто графіка позиціонується як прогресивна альтернатива «застарілої» текстовій формі подання. Однак при спробах знайти суворе теоретичне або експериментальне обгрунтування подібних заяв виявляються вкрай неприємні для графіки факти. Ні теорія, ні експеримент не дозволяють говорити про безсумнівну перевагу графічної форми подання алгоритмів. Більш того, фахівці з ергономіки стверджують: нерідкі випадки, коли графічна форма запису менш зрозуміла, ніж звичайна текстова. Класичний приклад, який демонструє неоднозначність роботи з графікою, був виявлений при аналізі графічних мов LabView [1].

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

Психологія запам'ятовування і критерії оцінки мови

Давно помічено, що для успішної розробки мовних засобів і визначення критеріїв їх оцінки потрібні певні знання в області психології. Ця думка присутня в працях А. Єршова, В. Дала, Е. Дейкстри, К. Хоору. Дослідження в області психології програмування [2] показують, що використання наявних в психології методів дозволяє підвищити якісний рівень програмування, звільнившись від шкідливих помилок. Дійсно, програмування не може бути зведене до математичних формалізму: обгрунтування для існування ідентифікаторів, структуризації, мов високого рівня слід шукати в першу чергу в людській природі. На жаль, розглядаючи властивості мов, «людський фактор» або просто ігнорують, або проводять на непрофесійному рівні. Тим часом, навіть поверхове знання того, як функціонує людська пам'ять, дозволяє більш якісно оцінити виразні засоби.

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

Найбільший інтерес з точки зору розуміння когнітивних механізмів являє короткочасна пам'ять, що забезпечує динамічну роботу з інформативними сутностями. Короткочасна пам'ять вперше була описана в класичній праці Дж. Міллера «Магічне число сім - плюс або мінус два: межа людських здібностей обробляти інформацію». Основний висновок роботи - в її назві: короткочасна пам'ять накладає жорсткі обмеження на можливість людини обробляти дані. Однак Міллер допускає можливість подолання психологічних обмежень за рахунок розбиття інформації на незалежні частини, виділення незалежних ознак: «Краще знати небагато про що, ніж багато про небагато чому». Крім цього обмеження, людська пам'ять виявляє і ще одну неприємну властивість: використання короткочасної пам'яті вимагає від людини помітного напруги. Ось ми і намагаємося «вивантажити» інформацію, даючи собі відпочинок. Ця особливість роботи з короткочасною пам'яттю називається в психології проблемою закриття [2].

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

Текст і графіка. Плюси і мінуси

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

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

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

Графіка дозволяє використовувати метафору, тобто представлення нових або незвичайних для користувача явищ через інші явища, добре йому відомі з повсякденного життя [3]. Механізм роботи метафори з точки зору психології полягає в використанні вже існуючих у користувача знань - довготривалої пам'яті. Це надзвичайно спрощує освоєння нового продукту для новачків в програмуванні. Класичним прикладом такого підходу при створенні мовного кошти служить мову релейних схем (ladder diagram) зі складу міжнародного стандарту МЕК 61131. Алгоритм роботи пристрою на цій мові описується в вигляді з'єднаних реле, які широко застосовувалися в 60-х роках. Мова релейних схем був орієнтований на користувачів, знайомих з реле, і спрощував перехід управління з реле на мікроконтролери. Схожий за принципом побудови і мову функціональних блоків (function block diagram), описаний в тому ж стандарті. Алгоритм роботи деякого пристрою, виражений засобами цієї мови, нагадує функціональну схему електронного пристрою з елементами «логічне І», «логічне АБО» і т.п., з'єднаними лініями-провідниками. Однак уявна простота такого підходу таїть в собі «підводні камені»; навіть для відносно простих випадків дуже важко підібрати підходящу метафору, виразна сила метафоричної мови вкрай низька, існує небезпека виникнення «метафоричних артефактів», побічних аналогій в свідомості користувача [3]. Побудова дійсно корисною графіки є скоріше мистецтвом, ніж операцією, доступною будь-якому користувачеві.

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

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

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

Чітке усвідомлення і формулювання розробником, що необхідно зробити, допомагає відповісти на питання, як це зробити. Перехід від роботи з поданням завдання до подання рішення не повинен бути пов'язаний зі зміною структури та термінології - виразні засоби вирішення обох проблем повинні бути ментально еквівалентними. Крім цього, уявлення завдання і рішення не повинні порушувати закон Міллера, а для можливості виконання на комп'ютері рішення ще повинне бути і формалізовано - записано на одній з існуючих мов програмування. До подання алгоритму ставлять високі вимоги [5]: надійність, стійкість, верифіковані, сопровождаемость, які, в свою чергу, визначають необхідність забезпечення відсутності помилок, динамічний контроль коректності умов виконання, переносимість, модифицируемость, понимаемость і т.д.

Єдино ефективний напрямок роботи зі складними системами, здатне гарантувати виконання цього комплексу суперечливих вимог, ґрунтується на ієрархічному підході. Виявлення ієрархічної структури - «творчий процес, часто вимагає використання знань, які будуть отримані лише на більш пізній стадії конструювання системи. Таким чином, як не болісно сприймати цей факт програмісту, всяке проектування програмного забезпечення являє собою складний ітеративний процес, що включає реконструкцію та виправлення на кожній стадії розробки ». Час і сили, витрачені на етапі проектування, винагороджуються тим, що при вдалій декомпозиції кожен компонент можна програмувати і модифікувати незалежно або майже незалежно від решти системи [4]. Можна додати, що етап проектування передбачає велике навантаження на короткочасну пам'ять, що обумовлює гостру постановку проблеми закриття. Від розробника потрібна висока ступінь терпимості до невизначеності [2]. По завершенню етапу проектування розробник отримує структуроване уявлення про завдання, можливі шляхи її вирішення; може побіжно орієнтуватися в проблемі - інформація про завдання переміщається в довгострокову пам'ять.

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

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

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

Оскількі, як позначають, до програми пред'являється комплекс різноманітніх вимог, на етапі проектування вона розглядається в різніх ракурсах: з точки зору роботи з комерційними користувачем, з точки зору інтеграції в існуючу систему, з точки зору Даних, потоку управління и т.п. Необходимость таких напрацювань привела до з'явиться набору графічних ЗАСОБІВ багатоаспектності Специфікації - мови моделювання Unified Modeling Language. Такий «ракурсів» підхід обмежує Дану область, дозволяючі тимчасово усунуті часть деталей, что дает можлівість сконцентруваті Рамус на одній підпроблемі, знізіті НАВАНТАЖЕННЯ на короткочасну пам'ять и подолати проблему закриття. Час создания закінченої моделі скорочується. Основні побічні ефекти даного підходу такі: засобами UML неможливо поєднати розроблені ракурси воєдино і, отже, створити специфікацію, придатну для отримання з неї машинних кодів; зміст моделі, як правило, неформалізованих, непридатне для автоматичного отримання машинних програм.

Говорячи про UML, потрібно зробити ремарку про його недостатню ув'язці з більш ранніми напрацюваннями в галузі стандартизації. Викликає жаль явно невдала спроба дублювання стандартів ISO в частині створення засобів опису потоку управління (мова activity diagram) - коштів, добре відомих вітчизняному користувачу за Єдиною Системі Програмної Документації.

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

Області застосування графіки і тексту

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

Для складних завдань графіка, в силу обмежених структурирующих можливостей і проблем з формалізацією, не в змозі служити засобом кодування, однак добре задовольняє вимогам етапу проектування. Формалізація, без якої не можна обійтися на заключних етапах створення програми, спочатку не потрібно, а, отже, неможливість перетворити графіку в машинний код не є перешкодою. Більш того, відсутність вимоги повноти опису дозволяє створювати більш компактні специфікації. Відсутність дратівливих повідомлень від компілятора, що нагадують про можливі синтаксичних помилках, в значній мірі знімає психологічне навантаження від усвідомлення незавершеності проекту. На початковому етапі розробник спілкується ні з комп'ютером, а з самим собою, з колективом розробників. Що особливо важливо, графіка дозволяє розробнику знайти спільну мову з замовником і почати продуктивно спілкуватися з ним в термінах розв'язуваної задачі. Недолік формалізму в графіку, зрозуміло, може привести до того, що відчуття узгодженості буде ефемерним - кожна зі сторін буде розуміти проблему по-своєму. Однак ця ймовірна неузгодженість буде носити лише локальний характер, не загрожує глобальній переробкою структури постановки і (або) рішення вихідної задачі.

Можливість розгляду проблеми з різних ракурсів сприяє вибору правильної стратегії програмування завдання, але може привести і до виділення усередині завдання компонентів, що допускають застосування різних стратегій програмування. Наприклад, в системах управління в окремі компоненти часто виділяють: призначений для користувача інтерфейс (мови об'єктно-орієнтованого програмування), бази даних (мови СУБД), допоміжне програмне забезпечення, власне алгоритм управління (мови, орієнтовані на опис потоку управління). Виділені на етапі проектування компоненти потім програмуються з застосуванням адекватних мовних засобів. Останнє особливо важливо з урахуванням того, що універсально кращого запису не існує, і кожна структура записи виділяє лише деякий вид інформації за рахунок затемнення інформації інших типів [1]. На жаль, але психологи говорять про неможливість створення універсальної (і водночас ефективною з точки зору ергономіки) структури опису для довільної задачі.

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

Висновок про доцільність застосування графічного мови з нестрогой семантикою без можливості отримання виконуваних кодів узгоджується зі сформованою практикою. Аналіз пропонованого на ринку графічного програмного забезпечення засобів специфікацій показує, що більша частина з них орієнтована на розробників і не передбачає отримання машинного коду. Більшість існуючих графічних мов використовується тільки на початкових етапах проектування і виключно для специфікації. У рідкісних випадках такі засоби видають шаблон програми для подальшого заповнення. Багато мови не мають формального синтаксису. На етапі кодування використовуються хіба що мови групи стандарту МЕК 61131-3, орієнтовані на вузьке коло користувачів і клас щодо простих завдань. До слова, мови МЕК 61131-3 абсолютно не придатні для специфікацій.

Таким чином, при створенні складних програм значно підвищити ефективність можна за рахунок спільного використання графічних засобів розробки, наприклад, набору мов UML, і текстових засобів кодування, наприклад, Сі ++. До висновку про можливість застосування декількох мов при створенні програми приходять і інші автори. Наприклад, в [7] говориться: «На кожному кроці є свій рівень абстрактного представлення програмного продукту. Для кожного рівня програмістом використовуються свої, найбільш доцільні мовні засоби, які при переході до наступного рівня абстракції піддаються ускладнює їх перетворенням до тих пір, поки не буде отримано необхідну представлення програми (наприклад, на мові Фортран) ». Не слід змішувати спосіб створення програм з багатомовними програмуванням - використанням різних мов на одному рівні абстракції (кодуванні), що вкрай негативно позначається на надійності створюваного програмного забезпечення [2, 5]. Наприклад, одночасне використання Фортрана і Сі, як правило, призводить до «класичним» помилок, обумовленим різними принципами індексації масивів. У нашому ж випадку мова йде про використання різних мовних засобів програмування для різних рівнів абстракції.

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

Серйозні проблеми із забезпеченням безшовних можуть звести нанівець всі перераховані переваги. Графічна специфікація повинна бути картою, що полегшує орієнтацію в алгоритмі на етапі кодування. А інтелектуальні зусилля програміста на етапі кодування повинні бути спрямовані тільки на опис тонкощів машинної реалізації. Оскільки завдання програмування розпадаються на класи, не може бути запропонована універсальна пара графічного і текстового мов, що забезпечує безшовний перехід. Для кожного виділеного класу повинна бути виявлена ​​проблемно-орієнтована «графо-текстова» пара, для якої має бути показано існування безшовного переходу. Наприклад, для блок-схем і автоматних мов в разі опису керуючих алгоритмів існує просте перетворення з графіки в текст [8].

Висновок

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

література

1. Green TRG, Petre M. When Visual Programs are Harder to Read than Textual Programs. Human-Computer Interaction: Tasks and Organization, Proc. 6th European Conference on Cognitive Ergonomics. GC van der Veer, MJ Tauber, S. Bagnarola, M. Antavolits (Eds.), Rome, 1992.
2. Шнейдерман Б. Психологія програмування. М.: Радио и связь. 1984.
3. Авербух В.Л. Метафори візуалізації. Програмування, 2001 № 5.
4. У., Дейкстра Е., Хоор К. Структурний програмування. М .: Мир, 1975.
5. Review Guidelines on Software Languages ​​for Use in Nuclear Power Plant Safety Systems. Decker D., Dinsmore G., Graff S., Green W., Hecht H., Justice M., Koch S., Lin D., Ossia K., Pollard J., Shorki E., Sorkin A., Tai A ., Tso KS, Wendelboe D. NRC, 1997..
6. Хазін Б. Міст над прірвою. // Відкриті системи, 1996, № 1.
7. Шабалін О.М. Про зростання складності розробляється програми. // Програмування, 1988, № 6.
8. Зюбин В.Є. Графічні та текстові форми специфікації складних керуючих алгоритмів: непримиренна опозиція або кооперація? VIII Міжнародна конференція з електронним публікаціям (EL-Pub2003), Новосибірськ, 2003.

Володимир Зюбин ( [email protected] ) - старший науковий співробітник Інституту автоматики і електрометрії СО РАН (Новосибірськ).

Структура пам'яті людини

Графіка проти тексту

Специфіка графічних ознак

Випадки ефективного використання