Процес розробки ПЗ та ЯП

Костін Г.В.

Все в цій книзі може виявитися помилкою.

Р. Бах. Ілюзії

Оскільки процес програмування є процес переносу думок від розробника до комп'ютера, ЯП виконує роль інтерфейсу, шлюзу між людиною і комп'ютером

Для початку введу поняття "карта". У психології "перцептивні карта реальності "визначено як індивідуальна модель сприйняття кожного людини, що є результатом його попереднього досвіду. Тобто що в людини в голові. Припустимо, стіл асоціюється у російськомовного людини зі словом стіл, у француза зі словом table, в англійця чи американця зі словом Desktop. Перекладаючи на мову комп'ютерів, картка - це вміст пам'яті комп'ютера. І людина і комп'ютер реагують на зовнішні події (тобто вхідну інформацію) в Відповідно до вмістом своєї картки. Припустимо, індонезієць слово "Кретин" сприйме як "кучерявий", а слово "сука" як "любити". Про фразах "Хуліана, підерас лас охуелас?" -- "Юля, ти попpосішь млинчиків?" і "Ун трахе негро пара ми Ньєто "-" Чорний костюм для мого племінника я вже не говорю. Аналогічно, компілятор C + +, зустрівши "(" сприйме її як початок логічного блоку, а компілятор Паскаля - як початок коментаря.

Для здійснення комунікації (тобто для передачі інформації) між двома суб'єктами (комп'ютери, люди ...) необхідно, щоб їх картки хоча б частково збігалися. частина як раз і є мова. Припустимо, комп'ютер під Windows може спілкуватися з NetWare сервером лише кажучи на його "мові" (інтерфейс IPX/SPX). Працюючи з Unix, ви не зможете використовувати команди Dos, а з Dos -- Unix. Аналогічно, спілкуватися з іноземцями Ви зможете лише на відомому обом мовою. Більш того для спілкування з професором і зі слюсарем Ви, ймовірно, теж виберете різні "інтерфейси". У психології підбір інтерфейсу під співрозмовника носить назви підстроювання. На ній заснований Еріксонівський гіпноз і НЛП.С допомогу ю її можна навести транс і вивести людину з коми.

Для здійснення ж не просто комунікації, а ефективної комунікації необхідно більш повний збіг карт. Якщо мова спілкування не буде рідним, то суб'єкт комунікації втрачатиме ресурси на "переклад". Припустимо сервер під ОС Linux емуліруя сервер WinNT буде показувати значно меншу продуктивність, ніж та на яку він здатний будь цей інтерфейс для нього рідним. Аналогічно програміст, спілкуючись з бухгалтером, буде витрачати час на переклад "проводок" в транзакції.

Процес розробки ПЗ та ЯП

На малюнку зображений процес розробки ПЗ з точки зору ЯП.

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

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

пунктирними лініями зображені рівні деталізації, такі як ЯП C + + або Технічне завдання. У процесі розробки програміст рухається справа наліво від користувача до комп'ютера. На малюнку розробник знаходиться приблизно на рівні проектування програми.

Деталізація проводиться або автоматично, наприклад, використання генерації коду за специфікаціям, припустимо, Corba IDL або генерація коду програми з графічним специфікаціям інтерфейсу в JBuilder, або вручну, наприклад, кодування в двійкових кодах підпрограми по специфікації на ЯПВУ або реалізація класу по специфікаціям.

Природно, перший варіант істотно підвищує продуктивність праці розробника. Тобто допустимо якщо розробник на рівні технічного завдання витрачає 5 хвилин то на рівні проектування йому буде потрібно 50, а на рівні реалізації 250. Саме тому еволюція ЯП та й програмування в цілому рухається в напрямку від комп'ютера до людини.

Я маю на увазі не всю тривалу і трудомістку стадію аналізу, а лише формальний опис вимог до ПЗ на його рівні. Тому наведені дані не слід розглядати як применшення значимості стадії аналізу.

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

Відносно мови:

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

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

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

Ширина прямокутника ( "горизонтальний розмір мови") означає широту засобів мови по рівнях абстракції. Поясню на прикладі. C + + - це мова з дуже великий "шириною": він взяв до себе кошти і від нізкоуровнего асемблера, і від ЯПВУ. На ньому можна реалізувати і драйвер, і АСУП. Притому в випадку, якщо в мову будуть вставлені високорівневі засоби створення інтерфейсу користувача, роботи з БД і т.д., як це пропонує Страуструп, то він стане ще "ширше". Java - мова значно більше "вузький". І драйвера на нього писати не вдасться. прямокутника ( "вертикальний розмір мови") означає широту засобів мови по областях застосування. Фактично спектр типів додатків, на які цю мову розрахований.

Поясню на прикладі - PL/1 і C + + однаково годяться і для розробки фінансового пакету, і для комп'ютерної гри. Вони мають велику "висоту" коштів.

MatLab, JavaScript мають маленьку "висоту". Їх можна ефективно використовувати лише в тієї єдиної області, для якої вони створені (у даному випадку математика та Web - скрипти).

Як відомо, довжина, помножена на ширину, дає площа. Це обсяг коштів мови.

Є думка, що складність і розмір мови повинні бути відповідні з розмірами завдання.

Хоча не всі фахівці та вчені згодні з тезою, що складність і розмір мови повинні бути відповідні з розмірами завдання. Приміром, Вірт розробив ОС Oberon на дуже простою мовою Oberon з мінімальними засобами.

Тут є два крайніх варіанти:

У ЯП слід включати тільки такі концепції і конструкти, без яких абсолютно неможливо обійтися. Яскравий приклад - Оберон

У ЯП слід включати все, що коли - небудь може знадобитися розробнику - яскравий приклад -- Ада. На практиці, як правило, використовується щось між цими двома полюсами.

Відносно складності ЯП зазначу таке:

Взагалі складність ЯП і складність його використання для тих чи інших завдань поняття різні і не завжди корелюють одна з одною. Спробуйте написати більше не менш складну програму на оригінальному Basic ...

Тут слід врахувати і людський фактор.

Простота використання невисока у високорівневих коштів лише для завдання для яких вони призначені. Приміром розробка простенькій БД в Accses значно простіше, ніж Delphi. Але розробка серйозного клієнт - серверного АРМ'а на Delphi може виявитися простіше.

Людський фактор у ЯП

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

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

Іноді розробники занижують рівень мови. Приміром, розробляють на C + + програму, яку можна було розробити на Perl за в кілька разів менший час

".. реагують на цю мою позицію з шаленством, що виходять за рамки відносин, які я вважаю доречними при обговоренні мови програмування. "Б'ярне Страуструп

Постійна приплив у сферу розробки ПЗ "програмістів з нагоди". Вони додають популярність і таких засобів, як Perl, TCL, 1C, PHP.

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

Не тільки ЯП формує мислення, але і мислення - мова і навіть "залізо".

Наведу приклад.

Контроль за виходом індексу меж масиву майже не уповільнює виконання програми, тому що перевірка у процесорів 80x86 реалізуються на апаратному рівні.

Таким чином, така особливість людської психіки, як неможливість безпомилкової роботи за коштами ЯП відбилася на залозі.

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

Стиль мислення.

Нагадаю, що "Мова формує наш спосіб мислення і визначає, про що ми можемо мислити.". Парадигми програмування є і парадигмами мислення програміста ".

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

Резюмуючи, зазначу, що різниця між людиною і комп'ютером дуже велика. Мова служить [проміжною ланкою] для подолання цієї різниці.

ЯП мови -- явище насамперед соціальне, а наукове. Умоглядні критерії та оцінки переваг та недоліків мов, щонайменше, непереконливі - основний критерій: практика масового використання.

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

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.bugtraq.ru/